AC3-in-MP4

[dynaflash]

http://trac.handbrake.fr/changeset/1286 automatically changes the file extension to .m4v for mp4's with AC3 audio in them for the macgui to help avoid confusion.

[dynaflash]

Just to confirm the new "hybrid" audio ( I get tired of typing AAC + AC3 surround passthru) *does* play the enabled aac dpl2 track in vlc, however gets a

Code: Select all

main: no suitable decoder module for fourcc `ac-3'. 
VLC probably does not support this sound or video format.

error when trying to enable the AC-3 track. Not unexpected as qt doesnt play it either by itself.

Note: currently both tracks are broken in the vlc git repository.

[ajv]

Sorry in advance if this isn't the appropriate place to post. Edgyg is the man for getting this working. It would be incredibly useful to the appletv community if we could make use of this patch in other tools besides HandBrake. The mpeg4ip library has a command line tool called mp4creator under the server directory. Would he be interested in enhancing mp4creator to be able to mux aac+ac3 tracks using his patch as well?

[ragboy]

Sorry in advance if this isn't the appropriate place to post. Edgyg is the man for getting this working. It would be incredibly useful to the appletv community if we could make use of this patch in other tools besides HandBrake. The mpeg4ip library has a command line tool called mp4creator under the server directory. Would he be interested in enhancing mp4creator to be able to mux aac+ac3 tracks using his patch as well?

for the record, if someone wants to do this, and give me a reasonable fee, I will pay for the time. Just PM me.

[dynaflash]

VLC doesn't know what to do with the AC3. VLC needs an update to understand these new changes.

As of http://trac.videolan.org/vlc/changeset/25416 VLC plays the the AC3 in mp4 perfectly. Just tried it out.

Link to vlc commit for ac3 in an mp4 in the new git repository:
http://git.videolan.org/?p=vlc.git;a=co ... 92ae68842c

[gbooker]

Looks like there are issues with anything that doesn't use a 384kb/s bitrate like Apple's sample.

Been trying to decipher the AC3 atom data...

In an effort to reduce some of the hackiness of this, I thought I'd share my discoveries yesterday.

1. The AC3 atom isn't special. It is just a version 0 sound description, and as such below is the meaning of the values.
2. The bitrate isn't special. I tested this with a 450kb/s file.
3. All that's needed is a track with correctly packetized AC-3 data, meaning a sample must begin with an AC-3 frame

Meaning of the existing AC-3 atom (from here):

Code: Select all

-----------------------------
0x00                        | Reserved, must be 0
0x00                        |
0x00                        |
0x00                        |
0x00                        |
0x00                        |
----------------------------|
0x00                        | Data reference index: 1
0x01                        |
----------------------------|
0x00                        | Version: 0
0x00                        |
----------------------------|
0x00                        | Revision Level, must be 0
0x00                        |
----------------------------|
0x00                        | Vendor, must be 0
0x00                        |
0x00                        |
0x00                        |
----------------------------|
0x00                        | Number of Channels: 2
0x02                        |
----------------------------|
0x00                        | Sample size: 16 bit samples
0x10                        |
----------------------------|
0x00                        | Compression id, must be 0 for version 0
0x00                        |
----------------------------|
0x00                        | Packet size, must be 0
0x00                        |
----------------------------|
0xBB                        | Sample rate: 48000 (fixed point, 16bit integer, 16bit fractional)
0x80                        |
0x00                        |
0x00                        |
----------------------------|
0x00                        | Atom size of sub atom: 11 bytes total
0x00                        |
0x00                        |
0x0b                        |
----------------------------|
0x64                        | Atom type: dac3
0x61                        |
0x63                        |
0x33                        |
----------------------------|
0x10                        | 3 byte payload, who knows wth this is
0x3d                        |
0x40                        |
-----------------------------

The dac3 atom isn't necessary. I can do passthrough without it. In addition, I did passthrough by providing a version 2 sample description on a different bitrate. Also, the name isn't necessary either. The sample description provided by the AC3MovieImporter (which is version 2, and has the correct channel count/layout) works with passthrough (I tacked it onto some video because the ATV doesn't like playing audio only mov files).

[eddyg]

Well done on figuring that out.

So what do we want/need to change?

What I did up front was admittedly hacky, so I see some benefits in constructing the atom at a finer level than at present. However given that the atom appears to be pretty much a constant what benefit do we get?

Cheers, Ed.

[gbooker]

First, I'd suggest setting the sample rate correctly. Admittedly, most DVDs are 48KHz, but this isn't a requirement in the DVD spec IIRC.

Second, I'd suggest changing it to a sound description version 2 atom. Then, you can use a channel count greater than 2, set the channel layout, etc... This is useful for cases when someone is not passing through, but connected the computer to 6 discrete speakers. Then, if they have Perian installed, they can get surrounds sound here as well. I assume you are using this for AAC.

Third, I might eliminate the dac3 atom. Doesn't seem to do anything other than muddle the mess.

[van]

First, I'd suggest setting the sample rate correctly. Admittedly, most DVDs are 48KHz, but this isn't a requirement in the DVD spec IIRC.

I completely agree with setting the sample rate correctly & not hardwiring 48KHz but I'm pretty sure 48KHz AC-3 is mandated by the DVD spec. My understanding is that the AC-3 in MPEG-2 containers standard was developed by ATSC & they mandated 48KHz because it can be locked to the 27MHz MPEG-2 System Clock (44.1KHz can't) which is required by the way A/V sync is specified in the Standard Target Decoder. This is the paragraph from ATSC A/53 Part 5 (2007) section 5.2:

5.2 Sampling Frequency
The system conveys digital audio sampled at a frequency of 48 kHz, locked to the 27 MHz
system clock. The 48 kHz audio sampling clock is defined as:

48 kHz audio sample rate = ( 2 ÷1125 ) × ( 27 MHz system clock )

If analog signal inputs are employed the A/D converters should sample at 48 kHz. If digital
inputs are employed, the input sampling rate shall be 48 kHz, or the audio encoder shall contain
sampling rate converters which convert the sampling rate to 48 kHz.

[gbooker]

van,
You are right in the spec. I just didn't look it up. Although, it does allow 24 bit audio, so there is a reason for setting that field at least. Although it doesn't seem to be mentioned in the spec, there is nothing limiting DVDs from using 24KHz sampling

[eddyg]

First, I'd suggest setting the sample rate correctly. Admittedly, most DVDs are 48KHz, but this isn't a requirement in the DVD spec IIRC.

Second, I'd suggest changing it to a sound description version 2 atom. Then, you can use a channel count greater than 2, set the channel layout, etc... This is useful for cases when someone is not passing through, but connected the computer to 6 discrete speakers. Then, if they have Perian installed, they can get surrounds sound here as well. I assume you are using this for AAC.

Third, I might eliminate the dac3 atom. Doesn't seem to do anything other than muddle the mess.

Makes sense, I'll try to get some time to take a look - new baby - so not much time.

Cheers, Ed.

[dynaflash]

As of http://trac.handbrake.fr/changeset/1435 the macgui will only allow you to select a track in the audio tab if the previous tracks are set to anything other than None.

[gbooker]

A quick tip for anyone playing with it, setting mFramePerPacket to anything breaks the AC3 passthrough. Makes no sense if you ask me, but it should remain 0.
http://trac.perian.org/changeset/905

[eddyg]

A quick tip for anyone playing with it, setting mFramePerPacket to anything breaks the AC3 passthrough. Makes no sense if you ask me, but it should remain 0.
http://trac.perian.org/changeset/905

Hi,

I'm not clear on how this applies to HandBrake. I assume this is referring to driving ffmpeg. However I don't see mFramePerPacket in any of the ffmpeg APIs, and besides, ffmpeg is not involved in our AC3 pass through.

Cheers, Ed.

[gbooker]

Ed,

mFramePerPacket has nothing to do with ffmpeg, it's a field in the sound description in the m4v/mp4/mov file. If you switch to using a version 2 sound descriptor, since it makes the AC3 a bit more useful, I was just saying that make sure the mFramePerPacket is 0. If it's not 0, passthrough does not work.

[eddyg]

Got you - thanks.

[csdesigns]

by dynaflash
http://trac.handbrake.fr/changeset/1286 automatically changes the file extension to .m4v for mp4's with AC3 audio in them for the macgui to help avoid confusion.

It appears that this is broken in the latest SVN snapshots (1457 and 1477). If I use a VOB and select AppleTV w/ AC-3 Pass-Thru, the output is .MP4 and not .M4V on G5. Not a big deal though as remembering to change the ext isn't too difficult.

BTW, does anyone here have the dolby draft spec for AC-3 inclusion in ISO MP4? This spec is getting a lot of play with the big content distributors in HW right now for some projects that should launch before the end of the year (BIG projects, ie they are likely to have a lot of interest for many HB users, if the response after enabling AppleTV AC-3 was any indication). Its just something to be on the lookout for. Sorry I have to be so vague...

[Ritsuka]

The annex f of the ETSI TS 102 366 v1.2.1 specification contains more information on how to mux an ac-3 track in an iso base media file format. It explains the meaning of the dac3 atom too.
It's a free download from the ETSI web site http://pda.etsi.org/pda/home.asp?wki_id ... 8EBA7EAy,5 .

edit: after playing some minutes with an hex editor I found that quicktime honors the value in the dac3 atom. So we should set them right.

[eddyg]

What part of the dac3 atom do you think is important?

It looks like this, all of which we could get from liba52, if we were also decoding the AC-3 as well as passing through.

Code: Select all

AC3SpecificBox (){ 
 BoxHeader.Size...................................................32  
 BoxHeader.Type ..................................................32 
 fscod.............................................................2 
 bsid .............................................................5 
 bsmod.............................................................3 
 acmod.............................................................3 
 lfeon.............................................................1 
 bit_rate_code ....................................................5 
 reserved..........................................................5 
} 

Given that we must support pass-through with no Ac-3 decoding within HB all of the above must be gleaned from the scan, and I'm not sure how much of that is possible.

Modifying mpeg4ip to write the correct data is easy - it's just finding the correct data within HB and making it available in the MP4 muxer that is harder.

Cheers, Ed.

[van]

We're already getting all this info during scan but currently throw it away (it's happening in routine deca52BSInfo). There's a 32 bit audio format specific 'flags' field already in the audio config (audio->config.flags.ac3) that's currently unused. We could easily stash this info there so it would be available to the muxer. We don't need to touch liba52 for this -- it's all in bytes 4-6 of the bit stream & just needs some minor re-arranging (see p.23 of ETSI TS-102-366).