-c:v copy renders audio and video out of sync

[Hadmut Danisch]

Hi,

after upgrading from ubuntu 16.04 with avconv to 18.04 with ffmpeg I noticed that under certain conditions ffmpeg creates videos where the video and audio get severely out of sync. It happens when using -c:v copy and -ss before -i. See the attached Makefile to have a demonstration of the problem.

As far as I can see this is releated to a new feature recently invented in ffmpeg, where the precise jump should work as good as a skip.

Please notice: -ss before -i means seek in the source file, which is fast, but said to be not working exact, but this was meant to be fixed, and it meant that you don't get a precise cut, but audio + video still in sync. It's extremely fast.

-ss after -i means to decode the source completely and to skip what's not needed, which can become very slow. If you want to skip to a position at 2:00:00 you have to decode full two hours of video.

I tried to report the problem upstream, but they replied that a) they ignore all bug reports not targeted to their git head version, and b) with their head version they could not reproduce the problem. So it seems to be fixed in newer version.

regards

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ffmpeg 7:3.4.2-2
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: LXDE
Date: Wed Jul 18 11:17:20 2018
InstallationDate: Installed on 2018-04-30 (78 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: ffmpeg
UpgradeStatus: No upgrade log present (probably fresh install)

[Hadmut Danisch (hadmut)]

Makefile for Ubuntu 18.04 to demonstrate the problem.

[Hadmut Danisch (hadmut)]

Please note that the two working methods shown in the Makefile have severe disadvantages.

the first method (producing good.mp4) needs to decode and re-encode the video, thus slow and loss of quality.

the second method (producing good2.mp4) needs to decode the video and thus is slow.

[James Cowgill (jcowgill)]

I can't seem to reproduce this. What player are you using for testing? I notice that in bad.mp4, there is about a second of extra video at the start of the stream with a negative timestamp. Maybe your video player doesn't handle this properly?

If you have the link to the upstream bug, that might be useful.

[Hadmut Danisch (hadmut)]

mplayer

[Hadmut Danisch (hadmut)]

Upstream: https://trac.ffmpeg.org/ticket/7299

[Carl Eugen Hoyos (cehoyos)]

When I set the resolution to "worksforme", I meant that I couldn't reproduce with FFmpeg 3.4, I would have set it to "invalid" if the issue were fixed.
Are you searching for the MPlayer option "-mc 100"?

[Hadmut Danisch (hadmut)]

I currently do not see why this is not reproducible.

I ran this on three different computers, all with 18.04, all producing the same result.

I just tried this -mc 100 option.

It works, although not from the very first frame. It starts out of sync, but then jumps, and then synchronizes more or less correctly. But I don't see it as a solution if it takes special options and some jumping effect to watch the video.

[Carl Eugen Hoyos (cehoyos)]

It is a known limitation of MPlayer that it needs audio for A/V sync, it therefore cannot "wait" for audio as FFplay should be able to.

[Hadmut Danisch (hadmut)]

So is this still a valid and commonly usable video?

[Carl Eugen Hoyos (cehoyos)]

That is what I believe, you could test with vlc, totem, ffplay (wmp and qt).

[Hadmut Danisch (hadmut)]

Just because _some_ of these programs can use it, it does not necessarily mean they are correct mp4 files.

[Carl Eugen Hoyos (cehoyos)]

Which players fail?

[Hadmut Danisch (hadmut)]

At least mplayer.

But I didn't check all those tablets and mobiles and smart TVs out there.

[Carl Eugen Hoyos (cehoyos)]

As said, this is a known limitation of MPlayer, the interesting question is if other players show A/V desync.