[FFmpeg-devel] [PATCH] H.264/AVCHD interlaced fixes

Ivan Schreter schreter
Sun Feb 1 12:11:36 CET 2009


Laurent Aimar wrote:
> [...]
>> I'm not claiming all cases are handled. I just want to help support 
>> AVCHD camcorders finally.
>> As for the timestamps, I and P "frames" must declare both PTS/DTS in 
>> H.222.0 stream. B "frames" don't have to (although in my sample files 
>> they do).
>  I don't think so. The only things mandatory are (from memory):
>  - a pts at least every 700ms.
>  - if the dts is written, the pts must be written too.
>  - if a pts is written but not the dts, then dts == pts.
> Sor for a GOP of about 500ms, you could have a pts/dts only on the I/key frame.
Correct. I was mistaken there.

>> Correct computation of PTS/DTS is already handled in libavformat.
>  For example, With classic H264 B pyramid, I am not sure the parser does it,
> but I have not checked it.
OK, correct only for frame-coded videos with MPEG2-like GOPs. For 
field-coded or "crazily" reordered pictures, it's by long way not 
correct :-)

> [...]
>  Well, for example you could encode every top as a P picture, and every bottom
> as B picture. I do not think it is brain-damaged, and this stream will not have
> consecutive top and bottom .
>  Now again, I do not think such stream exists in the wild. It was just an example.
Hm... I didn't think about this example, but you are right... If one can 
do I-slice for top and P-slice for bottom field, one can as well do 
B-slices for bottom fields and reorder them accordingly.

>  I will try to find one that I can share. It exits only for SD video (as HD
> is always(?) top field first.
Yeah, that question mark :-)
Do you have some better indices/proof about it? I'd namely like to know 
for sure.



More information about the ffmpeg-devel mailing list