[FFmpeg-user] Corrupt audio when transcoding uncompressed avi

[Camara Caamaño, Xavier]

<mailto:gdiezp at gencat.cat>

Dear Carl Eugen,


I'm so sorry for the late reply, I didn't receive the reply in my server nor my own message, so, fortunately, I decided to check in the forum if it had been published.

Anyway, thanks for the reply. Please find my replies below:

> My institution has transformed an old SD telecine and added a 4K camera with a Decklink capture card.
> We are currently capturing Uncompressed avi.

What writes the uncompressed avi file?
The avi file is badly interleaved, while it is a bug in FFmpeg that it
mishandles the bad
interleaving, avi was not intended to write uncompressed 4k files...


The avi file is written by Blackmagic Media Express, the software that control the Blackmagic capture card.
The only options available are Uncompressed AVI or QT (the latter generating drops) or DPX (also generating drop).


 > After capture, the file plays correctly (both video and audio).

What application did you test playback with?


We tested on ffplay, VLC and Davinci Resolve.


> The problem comes when transcoding with ffmpeg (either transcoding to ffv1 or x264). After transcoding,
> the file plays incorrectly, with the sound playing only noise.

> We realized that if we start the transcoding a few seconds after the beginning, the ouput file comes out well.

Do you mean it works when seeking?

Yes! That's the odd thing. The problem dissapears if we transcode (-ss) seeking a few seconds after the start, the issue is gone.


> So, we are assuming the problem is the original file with a messed up timestamp (?)

No, if you compare the console output of older and newer FFmpeg, you see the
difference: Old versions correctly detected the bad interleaving and handled it
accordingly.

> The error it gives us is:
>
> Invalid PCM packet, data has size 4 but at least a size of 6 was expected

That is an additional regression on top of the interleaving detection:
Some FFmpeg versions do not create white noise, just eat a part of the output.

[...]

>   configuration:  --disable-autodetect ...

Just curious: Why do you need nvenc, openh264 and x264?
(Or where did you find this binary?)

It's a long story. We really don't need it. We did a manual build. Could that be the issue?


Thanks!


Xavier