[FFmpeg-devel] [PATCH] use reordered_opaque in ffmpeg.c

[Alexander Strange]

This changes ffmpeg.c to push PTS through the decoder using reordered_opaque instead of the old and not quite accurate thing it does now.
It fixes a problem where initial decoder delay was treated as dropped frames.

Contrived example:

http://astrange.ithinksw.net/ffmpeg/camp_mot_mbaff0_full.mp4
ffmpeg -strict 2 -i camp_mot_mbaff0_full.mp4 -y -an -f framecrc crc.txt

Unpatched: frame=   30 fps=  0 q=0.0 Lsize=       1kB time=1.00 bitrate=   6.9kbits/s dup=14 drop=14 
Patched: frame=   30 fps=  0 q=0.0 Lsize=       1kB time=1.00 bitrate=   6.9kbits/s    

The first frame is emitted 14 times without the patch, and the last 14 frames are lost.

This is rare on mainline, but required for it to support ffmpeg-mt which has increased decoder delay.

A few things I tested still have timestamp problems - files with inaccurate dts or packed B-frames have non-monotonic pts coming out of reordered_opaque, and the issue with start_time isn't fixed - but I haven't found any files with worse sync.

Tested make test, but not make fate since it fails immediately on 4xm even without any patching.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ffmpeg-Replace-EOF-test-with-equivalent-condition.patch
Type: application/octet-stream
Size: 3542 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100620/6e7b4652/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-ffmpeg-Send-decoded-frame-timestamps-through-reorder.patch
Type: application/octet-stream
Size: 3770 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100620/6e7b4652/attachment-0001.obj>