[FFmpeg-user] confusion with "-vsync 1" / "-vsync cfr" and "-map" (to sync audio to video)

[tracey jaquith]

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:
   -vsync 1

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,
-Tracey



  // **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:
  //   https://ffmpeg.org/trac/ffmpeg/ticket/187#comment:6
  //
  // 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