[libav-bugs] [Bug 811] avconv fails to remux MOV with H.264 and Raw 16-bit PCM audio (sowt)

bugzilla at aruru.libav.org bugzilla at aruru.libav.org
Fri Feb 20 21:36:55 CET 2015


https://bugzilla.libav.org/show_bug.cgi?id=811

Alex Converse <alex.converse at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alex.converse at gmail.com

--- Comment #7 from Alex Converse <alex.converse at gmail.com> ---
So here's the history:

We ran into a number of issues with supporting ADPCM in mov,
especially in a remuxing context, especially WRT block_align.

We were hitting so many landmines in the stsd v1 case that we were
losing patience and confidence in our ability to actually write a
robust solution here. At some point I was fairly convinced that the
current [at the time] version of the QTFF spec was underspecified or
wrong. Meanwhile it became apparent that stsd v2 (which had debuted
in QuickTime 7) allowed us to handle ADPCM without any special cases,
bit counting, block align hacks, etc.

I think [but I'm not sure on this one, maybe justin can weigh in] that
linear pcm just came along for the ride.

See the historical threads:
[PATCH] Don't write an illegal stsz when sample size is larger than
sample count.
[PATCH] Fix ADPCM MS in mov muxing
[PATCH 1/2] In mov muxer, mux adpcm_ms and adpcm_ima_wav the way
quicktime supports it. In mov demuxer, set adpcm_ms and adpcm_ima_wav
frame size to stsd samples per packet.
and in general search the archives for [adpcm mov]

For testing purposes I recommend the following cases:
Verify that {mono, stereo} {AV_CODEC_ID_ADPCM_MS,
AV_CODEC_ID_ADPCM_IMA_WAV, AV_CODEC_ID_ILBC} all can do the following:
1. Encode with us and decode with {libav, QuickTime}
2. Transmux from {MOV written by QuickTime, MOV written by our current
code, MOV written by the proposed new code, WAV, AVI, AVI written by
VirtualDub, MKV} with us and decode with {libav, QuickTime}

All combinations. Yeah I know it kind of explodes, and the quicktime
ones aren't fateable.

Then do enc/dec/qtdec testing for all the "primitive" PCM codecs. [s8,
u8, s16le, s16be, s24*, s32*, f32*, f64*]

I used two archives while working on this project:

quicktime_audio.tar.xz is a set of files created with quicktime for RE
and testing purposes. Make sure they work as transmux sources.
avconv-no-wave-enda.tar.xz was a set of files created by us for
testing on QuickTime. It is evidence that both endian versions of all
[Well f64 is missing, not sure if bug] the multibyte LPCM formats play
on QuickTime. Since LPCM doesn't have all the weird metadata issues
that ADPCM does, they are probably less useful for testing.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libav.org/pipermail/libav-bugs/attachments/20150220/2f826223/attachment-0001.html>


More information about the libav-bugs mailing list