[FFmpeg-devel] [PATCH] Fallback to input timestamps for non-delay encoders.
Reimar.Doeffinger at gmx.de
Sun Jan 29 14:16:19 CET 2012
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
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
More information about the ffmpeg-devel