[FFmpeg-trac] #1435(undetermined:new): FFmpeg 0.11.1 simple reproducable synchronisation bug with work around - non imput specific

[FFmpeg]

#1435: FFmpeg 0.11.1 simple reproducable synchronisation bug with work around -
non imput specific
-------------------------------------+-------------------------------------
             Reporter:  feelart      |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  0.11.1       |  undetermined
             Keywords:  avi desync   |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by feelart):

 >Why do you use -async 1?
 I tried just to see if it had a synchronisation influence, but with or
 without none.

 I have to add, that although with the -f options it produces a
 synchronised video, on all players and depending on the encoding video
 codec mpeg4, libx264 or libxvid, the resulting video, leads to problems at
 when reaching the end(I presume there is unclosed parameters). I tried
 with KMplayer(3.2.0.19), VLC(2.0.1) or SMPlayer(0.8.0); KMplayer
 particular throws errors when reaching the end of file.


 This bug(s) not only affects avi - with avi it's the worst case and
 visible - but with mkv or mp4 you have this fails to close bug.

 For instance,

 ffmpeg -i "2012-03 03Praha.mp4" -f mp4 -acodec copy -vcodec libx264 -b:v
 1000k outFF_libx264_f.mp4
 and
 ffmpeg -i "2012-03 03Praha.mp4" -acodec copy -vcodec libx264 -b:v 1000k
 outFF_libx264.mp4
 produces very different output in term of size


 I suspect 2 bugs:

 1/ Either the parser or the internal fails to recognize the right input
 container, that's why with the -f option it works.
 Seeing that converting input aac to mp3 leads to a synchronised video
 without the -f option, I would first look at an issue with aac.

 2/ Eventhough with the -f option, the resulting video is malformed at its
 end, I suspect some unclosed option.



 >Is this also reproducible with current git head?
 I used FFmpeg git-718607b 32-bit Static (Latest)
 Do you want me to upload the input video?


 >Do you believe this is a regression? (=Did it work with older versions of
 FFmpeg?)
 With 0.11.0 same issues, but possible, see
 https://ffmpeg.org/trac/ffmpeg/ticket/1341

 But I do believe, that other reported synchronisation bugs are linked and
 that by forcing -f option it makes a first incomplete work around.

 I tried to make a thorought bug brake down, because, I do believe that you
 will close a bunch of bug reports, for instance to name some:
 https://ffmpeg.org/trac/ffmpeg/ticket/1338
 https://ffmpeg.org/trac/ffmpeg/ticket/1417
 https://ffmpeg.org/trac/ffmpeg/ticket/1410
 https://ffmpeg.org/trac/ffmpeg/ticket/475

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1435#comment:2>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker