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

[Michael Niedermayer]

On Sat, Jan 17, 2009 at 08:33:15PM +0100, Ivan Schreter wrote:
[...]
>
> As for the timestamps, there is a complicated algorithm guessing
> timestamps for frames which are missing DTS/PTS timestamps in
> libavformat/utils.c. IMHO this can be done much easier and more elegant
> in compute_pkt_fields() in about this form:
>
>     if (pkt->dts == AV_NOPTS_VALUE)
>     {
>         if(pkt->pts != AV_NOPTS_VALUE) {
>             // set DTS same as PTS
>             pkt->dts = pkt->pts;

this case either doesnt exist or is wrong depending on how you see it.
the demuxer sets both or neither.
If something else filled in pts somewhere that does not mean dts is equal
to that


>         } else if (st->last_IP_pts != AV_NOPTS_VALUE) {
>             // second half-frame of interlaced picture, same DTS/PTS
>             pkt->pts = st->last_pts;
>             pkt->dts = st->last_dts;

and that is supposed to be what? it surely is not correct, neither pts
nor dts will be equal to the "last" in general, except for progressive
video coded as fields.


>         }
>     }
>     ...
>     st->last_pts = pkt->pts;
>     st->last_dts = pkt->dts;
>
> In any case, when I activate this workaround and also change calculation
> of current DTS in compute_pkt_fields() to not offset it by frame
> duration, then I can decode interlaced AVCHD video without skips and
> dups (footage from my camcorder as well as Canon and Sony AVCHD
> camcorders). I believe this algorithm must work always, given AVCHD
> constraints on DTS/PTS requirements in headers. I checked resulting
> transcoded video on frame-by-frame basis, it seems to be correct (and
> lip-synced as well).

what a broken hack, this really has nothing to do with h264 timestamps


>
> What I found quite funny, AVCHD camcorders obviously produce two
> separate half-frames per frame of interlaced video. For an I-frame, they
> actually produce an I-frame with DTS/PTS set followed by a P-frame with
> no DTS/PTS. Then, 4 B-frames follow, two pairs, each pair with the first
> half-frame with just a DTS and the second half-frame without DTS/PTS.
> Then, two P-frames follow, first one having both DTS/PTS set, second one
> having nothing set.
>
> So it looks like the camcorders really code half-pictures at double
> frame rate. I'm wondering, though, what is correct: should those second
> half-pictures have exactly same DTS/PTS or one offset by half the frame
> duration against first half-picture? 

> Anyone knows?

The standards are publically available, you should maybe read them before
trying to implement what they describe.


> IMHO it should be
> offset (in the example above it's not), but as I'm no expert on MPEG
> format, I don't know. Further, should those frames carry frame duration
> of 1/25th second or also halved duration of 1/50th second (depending on
> frame rate, of course)? Anybody cares to elaborate?

read the specs: H264 & H222

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

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- 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/20090119/24384549/attachment.pgp>