[FFmpeg-devel] [PATCH] AVCHD/H.264 parser: determination of frame type, question about timestamps

[Michael Niedermayer]

On Mon, Jan 19, 2009 at 09:22:27PM +0100, Ivan Schreter wrote:
[...]
> However, there is still problem with timestamps in case of *interlaced* 
> video. Namely, currently every second half-frame comes without DTS/PTS. 
> Thus, compute_pkt_fields() tries to assign DTS/PTS to it, but it does it 
> incorrectly and also IMHO has no way to do it really correctly with current 
> information.
>
> Michael Niedermayer wrote:
>> read the specs: H264 & H222
>>   
> Unfortunately, H.264 spec which I found in internet doesn't mention much 
> detail about how interlaced frames are to be timed. H.222 is supposedly 
> superseded with H.221, but again, no information about interlacing there.
>
> H.264 spec only says: "The two fields of an interlaced frame are separated 
> in capture time while the two fields of a progressive frame share the same 
> capture time". That means, I was essentially correct in my assumption - the 
> half-frames without DTS/PTS in interlaced AVCHD which represent the second 
> half of interlaced picture have to be offset by 1/2 of 25fps frame duration 
> or by 1 50fps frame duration from first half-frame. I.e., it looks like for 
> interlaced videos ffmpeg works with wrong frame duration in 
> compute_pkt_fields().

You need to read the spec more throughout
* the 2 fields AFAIK do not have to be consecutive in the bitstream (we might
  attempt to ignore this as it seems not done by anyone)
* fields and frames can be mixed


>
> A workaround by simply not assigning PTS/DTS in compute_pkt_fields() at all 
> in utils.c like this:

we need an implementation of what is described in H.222 not
some workarounds for your H.264 files from your cammera.
"2.7.5 Conditional coding of timestamps"
is one of several parts you should read


[...]
>
> Should the frame rate be actually 50 instead of 25 for 50i videos?

probably


[...]

>
> Further, with av_read_frame, we are actually reading a half-frame for 
> interlaced video, right? At least it seems to return 50 times per second 
> for AVCHD 50i. Then, of course, decoding will create 25 interlaced pictures 
> per second.
>

> Regarding the seeking problem of AVCHD streams, I'll open a new thread when 
> the parsing works correctly. If you care, you can give me some pointers as 
> to where to look in h264 code. Seems like h264 codec doesn't "forget" some 
> old frames in buffers when seeking to random location, which causes 
> additional artefacts and essentially prevents seeking. Also, it seems it 
> doesn't restart correctly at an I-frame after seeking.

I dont know about the exact problem you describe but i do know we are missing
Recovery point SEI message handling which is possibly a prerequesite for
fixing this (that is without it any fix of the problem might break other
streams thus would not be approved)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090123/1762c324/attachment.pgp>