[MPlayer-dev-eng] [PATCH] unified timing patch for H264

[Pásztor Szilárd]

Hi,

(sorry for replying out of thread, my server is experiencing
difficulties.)
Since michaelni doesn't seem fond of changing ffmpeg because of
this mplayer-specific h264 problem, here comes a patch that does
it in mplayer according to this:

Reimar Döffinger:
> If not however, you can fix this while avoiding any issues by
> returning the "only one field" indication only for CODEC_ID_H264 and
> only if the packet size was not 0. 

Now codec is checked and return value is set accordingly. (Packet
size is already checked at start of function.)

Please review the patch if you can take the time.
It is working stable on all samples I could test. Main changes to
original sources:
* PTS reordering bug fixed. If correct-pts is set, now only the
PTS of "full frames" (or second fields) get buffered. It was buggy
before because all fields' timestamps were buffered but the buffer
length was checked and cut according to reported number of B-frames.
At most streams, it threw away half of the values, causing jerkiness.
* added stable time-based PTS recalculation for nocorrect-pts. PTS
are untouched until A-V sync gets close, then replacement starts at
the proper point where the calculated should-be PTS is practically
equal to what comes in the stream, finding frame accurate A-V sync
both after starting playback and seeking. This recalculation is
needed to prevent the A-V sync algorithm from trying to correct for
the jumpy B-frame PTS all the time.

The patch is not small but all parts depend on each other, so it
can't really be split into separate patches. I hope it's a clean
patch and covers all cases.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-2010-08-28-h264-timing.diff
Type: application/octet-stream
Size: 12019 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100829/e28b5934/attachment.obj>