[FFmpeg-user] Reversed order of video audio after audio merging (0:0 audio, 0:1 video)
christophgerstbauer at gmail.com
Mon Jun 2 13:51:57 CEST 2014
> Seeking in large files with WMP fails sometimes,
> indicating that (afaict) something is wrong with
> the ODML index.
Yes, this bug I know:
The problem happens every time when the AUDIO DATA in the AVI is bigger
than 2 Gigabytes -> like the same problem with 2GB WAV files
In the AVI file, the Chunk(LIST) for the audio stream (auds) has wrong
length values if the audio data in it is bigger than 2GB.
The Chunk(LIST) for the video stream has correct values (based on frames).
We made huge tests with AVI files with audio data bigger than 2GB (e.g
32minutes files with 8ch audio). And as I saw it, which ffmpeg version
2.1 the problem is gone.
Can you verify that I am talking from the same problem, and that the
problem is debugged?
> (This might be the only known problem, I just
> wanted to make sure you realize avi is an
> extremely outdated container that cannot contain
> all kind of modern codecs. Note that I had not
> realized you can actually use it with ffv1 and
> external applications.)
Yes we know that AVI is outdated, but it is STILL a container which
EVERY editing tool or transcoder is able to read because it is so common.
We only want to use AVI for ffv1, huffyuv oder ffvhuff. Not more.
If standard transcoders (carbon, mainconcept, etc) would support MKV....
we would not use AVI ;).
Yes, we could use MKV, but if we did, we would need to grab the archive
file, recapsulatel it to AVI and then give it to the transcoders... that
is one step too much.
Content ordering from the archive should work as fast as possible. Thats
why we use AVI.
So, to get the things straight,
the main bugs are:
1.) ODML index wrong (when audio is bigger than 2gb?)
2.) Interlaced Flag is always set to progressive
And There is no bug which will cause loosing video or audio information
(content damage). Is that correct?
More information about the ffmpeg-user