[FFmpeg-devel] [PATCH] Fallback to input timestamps for non-delay encoders.

[Reimar Döffinger]

On Sun, Jan 29, 2012 at 02:08:04PM +0100, Reimar Döffinger wrote:
> On Sun, Jan 29, 2012 at 11:24:53AM +0100, Reimar Döffinger wrote:
> > On 29 Jan 2012, at 01:06, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > On Sat, Jan 28, 2012 at 10:43:54PM +0100, Reimar Döffinger wrote:
> > >> Causes FFmpeg to pass through the correct pts values,
> > >> instead of clobbering all to AV_NOPTS_VALUE (the av_init_packet
> > >> default) to then make up new ones based on only fps when muxing.
> > >> Included are also the related FATE ref changes, which all
> > >> some reasonable on quick investigation.
> > >> Also set all H.264 references to us -vsync drop to reduce the
> > >> diff for the ref files.
> > >> Otherwise almost all H.264 references need to change, mostly due
> > >> to now starting with negative pts values.
> > >> About 20 additional H.264 conformance tests needed -vsync
> > >> drop anyway because they create pts values that are out of
> > >> order and thus not possible to mux otherwise.
> > > 
> > > should be ok if you tried the changed files with ffplay and they
> > > didnt get worse
> > 
> > Any chance someone else can test?
> > I probably can avoid it with some SDL environment variables hack, but ffplay currently just crashes X for me (I suspect some issue with XVideo with ATI drivers).
> 
> Setting SDL_VIDEO_YUV_HWACCEL to 0 worked, they still looked fine.
> But now I am wondering, the only code change is ffmpeg.c, there's no
> way ffplay could be affected?!?

And now I confirmed that the patch fixes massive A-V desync with this
command:
ffmpeg -threads 1 -thread_type frame+slice -i fate-suite/bethsoft-vid/ANIM0001.VID -pix_fmt rgb24 -vcodec rawvideo -pix_fmt rgb24 -acodec pcm_u8 -f matroska test.mkv

The transcoded file now plays the same as the original with FFmpeg,
before video was played about 4x as fast as it should with the
transcoded file.