[Libav-user] strange H264 audio sync behavior
d3ck0r at gmail.com
Mon Jun 23 13:20:41 CEST 2014
VLC has a pretty good logic for tracking audio/video sync... the logic for
handling where audio is and where video is, is really up to the application
(if it's ffmpeg, the code is in the ffmpeg player, not the library)...
Quicktime is probably tracking them separately where VLC is doing something
different with where things are scheduled.
The input file I have most problems with is MKV with a quicktime MOV in
it... audio and video get horribly mis-synched... in my player I was
working to add a advance/retard knob... but then I figured some better
logic that obsoleted that idea.
On Mon, Jun 23, 2014 at 3:49 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Marco Sieber <l-spy at ...> writes:
> > I switched now to 2.2 or the trunk Version, i have
> > to test it with that.
> Please understand that only current FFmpeg git head
> is supported on this mailing list.
> > >If you really need "-r 25" this indicates a problem
> > >and it would explain why your application (if it
> > >does sane things with timestamps) cannot work.
> > If im right -r indicates a constant framerate? Why
> > should it not work
> I believe there are three possibilities:
> Your input file could be broken and contain random
> timestamps, in this case you need -r 25
> FFmpeg might be unable to read the timestamps from
> your file correctly, in this case -r 25 is a
> Or the timestamps in your file are correct and
> FFmpeg can read them, in this case you should
> not use -r 25
> Iirc, you have to read the time_base you set for
> a stream after setting it, FFmpeg might have
> changed it.
> Carl Eugen
> Libav-user mailing list
> Libav-user at ffmpeg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libav-user