[FFmpeg-devel] [RFC] ac3enc: how do I force ac3 encoder to output frames with the same size?

[Michael Niedermayer]

On Tue, Dec 25, 2012 at 01:20:58PM +0100, Piotr Bandurski wrote:
> Hi,
> 
> The problem is that RealPlayer does not play correctly ac3 files with frequencies
> 11025/22050/44100Hz generated by FFmpeg, while 8000/16000/32000Hz files plays correctly.
> 
> I belive it maybe be because for 11025/22050/44100Hz FFmpeg uses not constant ac3 frame
> sizes, while for 8000/16000/32000 it uses.
> 
> RealEncoder uses constant ac3 frame sizes for all of the frequenties.
> 
> Here is the output (whit attached patch) from the files generated by RealEncoder:
> 
> $ ffmpeg -i re_8.rm -f null -
> Input #0, rm, from 're_8.rm':
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> 
> $ ffmpeg -i re_11.rm -f null -
> 
> Input #0, rm, from 're_11.rm':
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> 
> and the output from the files created with FFmpeg:
> 
> ffmpeg -i input.wav -ar 8000 -ac 1 -ab 8000 ff_8.rm
> 
> ffmpeg -i input.wav -ar 11025 -ac 1 -ab 16000 ff_11.rm
> 
> $ ffmpeg -i ff_8.rm -f null -
> Input #0, rm, from 'ff_8.rm':
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 192
> 
> $ ffmpeg -i ff_11.rm -f null -
> Input #0, rm, from 'ff_11.rm':
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 280
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 280
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 280
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 278
> [ac3 @ 018ecba0] hdr.bitstream_id: 10
> [ac3 @ 018ecba0] hdr.frame_size: 280
> 
> So the question is how do I force ac3 encoder to output constant ac3 frame sizes
> for 11025/22050/44100 frequencies to match the output from RealEncoder?

one way is to use a bitrate that produces an integer size
(like 65536) and apply

diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index de8defc..b4acea2 100644
--- a/libavcodec/ac3enc.c
+++ b/libavcodec/ac3enc.c
@@ -2210,7 +2210,7 @@ static av_cold int validate_options(AC3EncodeContext *s)
             if (!best_diff)
                 break;
         }
-        avctx->bit_rate    = best_br;
+//         avctx->bit_rate    = best_br;
         s->frame_size_code = best_code << 1;
         s->frame_size_min  = 2 * ff_ac3_frame_size_tab[s->frame_size_code][s->bit_alloc.sr_code];
         s->num_blks_code   = 0x3;


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121225/aed6cecf/attachment.asc>