[FFmpeg-devel] [PATCH] H.264/AVCHD interlaced fixes
Ivan Schreter
schreter
Sun Feb 1 12:11:36 CET 2009
Hi,
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.
Regards,
Ivan
More information about the ffmpeg-devel
mailing list