[FFmpeg-devel] [PATCH]Fix AC3-in-avi for the remaining cases

[Michael Niedermayer]

On Sat, Jan 01, 2011 at 10:41:15PM -0500, Justin Ruggles wrote:
> On 01/01/2011 10:14 PM, Michael Niedermayer wrote:
> 
> > On Sat, Jan 01, 2011 at 03:52:07PM -0500, Justin Ruggles wrote:
> >> On 01/01/2011 03:03 PM, Carl Eugen Hoyos wrote:
> >>
> >>> Hi!
> >>>
> >>> Current svn produces avi files that don't playback on any player when muxing 
> >>> AC3 with 32kHz/320kB, 32kHz/384kB and 44.1kHz/384kB.
> >>> I believe Justin suggested to set blkalign to maximum frame size (first 
> >>> patch).
> >>> An alternative is to just fix the failing cases (second patch).
> >>>
> >>> Opinions?
> >>>
> >>> Please comment, Carl Eugen
> >>>
> >>>
> >>
> >>> Index: libavformat/riff.c
> >>> ===================================================================
> >>> --- libavformat/riff.c	(revision 26183)
> >>> +++ libavformat/riff.c	(working copy)
> >>> @@ -370,12 +370,10 @@
> >>>          av_log(enc, AV_LOG_WARNING, "requested bits_per_coded_sample (%d) and actually stored (%d) differ\n", enc->bits_per_coded_sample, bps);
> >>>      }
> >>>  
> >>> -    if (enc->codec_id == CODEC_ID_MP2 || enc->codec_id == CODEC_ID_MP3 || enc->codec_id == CODEC_ID_AC3) {
> >>> +    if (enc->codec_id == CODEC_ID_MP2 || enc->codec_id == CODEC_ID_MP3) {
> >>>          blkalign = enc->frame_size; //this is wrong, but it seems many demuxers do not work if this is set correctly
> >>>          //blkalign = 144 * enc->bit_rate/enc->sample_rate;
> >>> -        //For high bitrate AC-3, set blkalign to maximum bytes per frame value
> >>> -        //to allow playback on WMP and MPlayer
> >>> -        if (enc->bit_rate > 384000)
> >>> +    } else if (enc->codec_id == CODEC_ID_AC3) {
> >>>              blkalign = 3840;
> >>>      } else if (enc->codec_id == CODEC_ID_ADPCM_G726) { //
> >>>          blkalign = 1;
> >>
> >>
> >> I like this version better.
> >>
> >> Regarding the other patch, if it would be better for some reason to use
> >> a more accurate value for AC-3 we could do:
> > 
> > being exact when there is exactly just 1 packet size is nice, beyond that its
> > a hack either way
> 
> Well, there is such thing as VBR AC-3 so using the maximum value for the
> given sample rate is at least less of a hack.

Just keep in mind making it twice as big for VBR likely wont make a difference
making it 1 byte too small for one packet will break AV sync
so i dont feel comfortable about this "make it as tight as possible" at all
especially if one muxer/encoder adds a padding byte for whatever reasons or such


> The exact value can be
> calculated if it is CBR.

IIRC that only works for some cases of AC3 CBR as some dont have exactly
matching packet size for the target rate & sample rate ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110102/08bfec14/attachment.pgp>