[FFmpeg-user] confusion with "-vsync 1" / "-vsync cfr" and "-map" (to sync audio to video)
tracey at archive.org
Tue Jan 15 21:55:35 CET 2013
On Jan 13, 2013, at 2:23 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> tracey jaquith <tracey <at> archive.org> writes:
>> yes, I tried various -async options.
>> the "special" version of "-async 1" seemed to do fine
> Then please use it, documentation is in the filter
> section of the main documentation.
> Carl Eugen
ah, great, thanks -- I somehow hadn't found that extra-ish page before on the site.
I was about to say, "will do", but it turns out I had been using "-async" properly before,
but had various issues (especially came up with MPEG-TS with 5.1 audio that dropped
down to stereo and lower quality local affiliate commercials for us).
For completion / archiving / in hopes of helping someone else down the line,
as of now I am going with:
For some perspective, I am remaking ~250,000 .mp4 in our extensive TV archive now with "-vsync 1"
and the spot-testing I am doing is paying off very well. I won't say/suggest this is the Only or
One True Solution, because I'm clear there are many. But so far this is our best setup here.
I don't know if any of the main devs in ffmpeg would ever consider auto-flipping on something like
"-vsync 1" for "mpegts" input (because pseudo ports/clients like "mplayer" are certainly doing
something along these lines -- that is, they seem to almost never A/V drift by default) but I also
realize ffmpeg is a much more generic and awesome tool with a much wider goal and range of possibilities.
So, of course, it's just an idea I'm not attached to, but merely suggesting.
I've added a few notes/comments below.
Thanks for the awesome tool/product -- we've used it nearly exclusively at archive.org for 8 years!
Best and kind regards,
// **hopefully** the near ultimate fix for MPEG-TS A/V sync drifting!
// Make sure we use "-vsync" param.
// This came about from ~Dec 2012 "new" TV programs that were in HD with 5.1 audio,
// but recently started arriving with local affiliate SD commercials in stero audio.
// Those items became totally borked or sometimes just failed rest of .mp4 after that commercial set
// until came up with this new A/V PTS/DTS sync strategy
// A particularly helpful part in this was:
// Which basically advocates, pseudocode:
// $vsync = ( wmv ? 1 : 0 )
// if you get a "non monotonic timestamp" error, change $vsync to 1 (if it wasn't 1 already) and add "-r" arg
// however that made massive A/V slip for our output .mp4 for many shows inside a browser **flash plugin** (only), so
// went instead with (just) "-vsync 1", and add "-r" arg secondarily if the 1st try fails
const AV_ANTI_DRIFT = ' -vsync 1 '; //html5 *and* flash plugin works -- at some expense of possibly duping/nixing video frames to meet framerate!
// dead bodies:
//const AV_ANTI_DRIFT='-vsync 0'; //flash plugin (sometimes) has A/V drift
//const AV_ANTI_DRIFT='-vsync 0 -copyts'; //flash plugin (sometimes) has A/V drift
//const AV_ANTI_DRIFT='-vsync 0 -r xxx'; //flash plugin (sometimes) has A/V drift
//const AV_ANTI_DRIFT='-vsync 0 -fflags +genpts+igndts'; // [ditto above]
//const AV_ANTI_DRIFT='-async 1'; //only corrects the *start* per documentation, avoiding...
//const AV_ANTI_DRIFT='-muxdelay 5 -copyts -async 88200 -adrift_threshold 5 -dts_delta_threshold 5'; // prior 2012 way
//const AV_ANTI_DRIFT='-af aresample=8000'; //flail, works for small test cases; not enough testing; bad science; may have similar issues I suspect with prior
More information about the ffmpeg-user