AC3 passthrough failing for .mov files in 1.2.2 and 1.2.3

[auburn3020]

I've been using Perian with Graham's settings for AC3 and DTS passthrough in Quicktime and Front Row for several years. After updating to Perian 1.2.3 recently (I don't recall whether I went directly from 1.2.1 or had 1.2.2 installed in between, but the same failure now happens with 1.2.2), AC3 passthrough has stopped working for .mov files in both Front Row and Quicktime Player 7. I get the familiar noise chatter instead of actual audio. DTS passthrough still works fine for .movs (yes, DTS in a .mov is out of spec, but it does work), and AC3 passthrough also works fine when playing back DVDs under either DVD Player or Front Row.

To ensure that I wasn't seeing random conflicts from other software, I backed up my Mini and then wiped the drive. Same behavior on clean installs of both 10.5.8 and 10.6.7 for Perian 1.2.2 and 1.2.3. Downgrading to Perian 1.2.1 does fix the AC3 problem under 10.6.7. I haven't tried it yet under 10.5.8, but will test that after I recover to my previous install later today.

I've tested with two different Pioneer receivers, a VSX-815 and a newer VSX-921. Same behavior in both cases, and both receivers worked with AC3 passthrough previously. Passthrough settings are per the standard instructions ( http://www.cod3r.com/2008/02/the-correc ... quicktime/). For both receivers, DTS is immediately recognized per the front display; AC3 (Dolby Digital on the display) is recognized for DVD playback only. AC3 is not recognized at all when playing back .movs.

System specs: Mac mini Intel Core2Duo 2.0 (original form factor), OS X 10.5.8 or 10.6.7. Given the long and painful history of the AC3 passthrough hack, I've held off on submitting a formal bug report for the time being; I wanted to check in here first.

Appreciate any thoughts and/or suggestions; thanks to a Hauppauge HD-PVR, I have a large library of .mov files with AC3 audio. Transcoding all of them would not be my first choice. Be glad to attach file samples upon request.

To answer a likely suggestion: Yes, I've tried Plex; no, I don't like it...

[gbooker]

I have my suspicions on what this could be, but before I say them, I'd like to confirm it. Do you have a small file which you can provide us for testing? BTW, if you are looking for an upload site to use, we tend to prefer mediafire, but dropbox hosting or any other web page hosting is fine.

[auburn3020]

No problem. Here you go: http://www.mediafire.com/?v4hre2h25b96c1b

Plenty more where that came from, if needed. Thanks...

Incidentally, downgrading to Perian 1.2.1 does fix the AC3 issue even in my messy old 10.5.8 install (it also kills all the 1.2.2 and 1.2.3 functionality, of course).

[gbooker]

This is a direct response of Apple refusing to do the right thing. They've continually decided to violate their own documentation and use the wrong channel layout for AC3 and not even use the layout themselves. I've given up and introduced yet another hack to work around their inadequacy. It appears this hack hit you.

Anyway, A52Codec from 1.2.2 on attempts to detect which layout is being used: the one that's been used for years before Apple decided to meddle, or the one that Apple invented and never used themselves except to set in the file format. It's detecting that your files are Apple's layout, which is: L C R Ls Rs LFE

If you change the layout to the above, passthrough works. Did you changed the layout in your files or did they "come" that way?

P.S. We are joining that conference next year; I'm afraid we will have loosing seasons in the SEC West for many years though. Also, did that play stand or did the penalty take it back? I couldn't see why the flag was thrown in that clip.

[auburn3020]

Short answer: they come that way.

Longer answer: the HD-PVR generates an .m2ts file, which is converted by Steven Toth's HDPVRCapture app to an .mp4, which is subsequently edited (by me in this case) in MPEG Streamclip and saved as a .mov. At no point in that process are either the audio or video streams re-encoded, so what winds up in the final .mov should be the exact same AC3 data that was initially recorded by the Hauppauge box. But I can ask Steve about how his software handles the AC3 layout if that would help (I agree with you, obviously, Apple's implementation makes no sense whatsoever). Far as I can tell, all these files use the standard L, R, C, LFE, Ls, Rs for their AC3 assignment order.

Would swapping the container to .mp4 make any difference? I'd just as soon not use .mkv as long as I'm sticking with Front Row/QT, but those days are obviously numbered in the long run.

I think that play was called back, but it didn't matter in the end (65 points... that Newton guy is pretty good).

It would surprise me if the divisions for 2012 aren't temporary. I strongly suspect Slive is looking to go to a 16-team conference with four 4-team divisions before too terribly much longer. And besides, Missouri in the East makes even less sense than Apple's AC3 layout...

[gbooker]

Ok, if I had to guess, I'd say it was MPEG Streamclip that's the culprit. My dad has an HD-PVR as well, so I was curious as to the workflow. I ran into audio sync issues with a few files using some of the file format conversion techniques (stream copy, not transcode).

Anyway, the AC3 stream is not the issue at all. AC3 stores which channels are present; the channel ordering is explicitly mentioned in the documentation to be negotiated between the codec and the playback mechanism (this is where Apple failed). The mp4 file only has a dac3 atom which contain part of the AC3 header, indicating which channels are present. The mp4 file cannot contain a channel ordering atom as it's not allowed in the spec. The mov file may contain a channel ordering atom, which is likely inserted by MPEG Streamclip. If this is the case, it likely should remove the dac3 atom as it is a strict subset of the information in the channel ordering. The A52Codec keys on the presence of the dac3 atom to determine if the channel ordering is Apple's or not; since I tend to see this in MP4 and M4V files, but not others. I do see a dac3 atom in your Sample.mov as well as a "chan' atom containing the ordering (if I'm reading it correctly). BTW, the channel ordering atom is not given to the codec, otherwise I would have use it instead!

Using an MP4 container would likely solve it, as it shouldn't have the channel ordering but the presence of the dac3 atom will tell A52Codec that it should use the ordering that Apple's mp4 container reader assumes.

I was curious as to the result of the play, having watched it several times in a row If the SEC is redone, I wonder who TAMU (my alma mater) will get to play each year. Given it's proximity, it's likely many of the best teams in the conference.

[auburn3020]

Interesting. I wonder if there's a way to strip the dac3 atom from an existing file?

I can upload a pre-Streamclip .mp4 this evening (raw output from the HDPVR Capture app) if you'd like to take a look at that.

Really, Auburn should have been bumped to the East to make room for Mizzou in the new lineup, but that caused too much consternation in the SEC office this time around.

[gbooker]

It may be possible with Dumpster (.mov atom editor). I'm not on a mac ATM, so I can't check. Testing the pre-Streamclip .mp4 would certainly be a good test to make sure my assessment is correct. I would expect it to have no issues as it should have the dac3 atom, but not have the channel layout (since it's not allowed in .mp4).

[auburn3020]

To my surprise, same behavior with an untouched .mp4 file. Here's a sample: http://www.mediafire.com/?a7yb59qink473de

[gbooker]

Interesting.... The mp4 has a chan atom as well. I could have sworn that it was illegal in the mp4 file format. So, given this information, the culprit is likely HDPVR Capture, not Streamclip. This makes a first mp4 that I've seen with a chan atom.

[auburn3020]

Okay, I've sent a note to the HDPVR Capture dev, hopefully he'll have a look and weigh in. Really appreciate the help here.

Any suggestions on a work-around in the meantime, other than manually switching Perian versions? I guess I could try rigging an Automater applet to do that...

[auburn3020]

I checked with Steven Toth, the HDPVR Capture dev... Steve says this:

FFMPEG does the conversion from M2TS to MP4.

Strictly speak, for reasons that elude me, I have to pass "-f mov" to
ffmpeg but force the output filename to blah.mp4. This (as best I
recall) allowed for the maximum amount of flexibility when working
with QuickTime. It's been like this since basically day one. I suspect
the mp4's don't/didn't play natively in QuickTime and this was likely
a hack from the 10.5 days. This needs to be revisited

(Quick test with 1280x720 and 1920x1080 and 2 channel aac/ac3 with the
current build on 10.7 shows that removing the -f mov doesn't seem to
negatively impact QuickTime playback)

I'd expect the atoms to be different given the switch from MOV to MP4.

My concern at this point is that I don't specifically set the atoms,
it's up to ffmpeg. I do go back manually and adjust the AC3 channel
ordering to:

trackChannelLayout->mChannelDescriptions[0].mChannelLabel =
kAudioChannelLabel_Left;
trackChannelLayout->mChannelDescriptions[1].mChannelLabel =
kAudioChannelLabel_Right;
trackChannelLayout->mChannelDescriptions[2].mChannelLabel =
kAudioChannelLabel_Center;
trackChannelLayout->mChannelDescriptions[3].mChannelLabel =
kAudioChannelLabel_LFEScreen;
trackChannelLayout->mChannelDescriptions[4].mChannelLabel =
kAudioChannelLabel_LeftSurround;
trackChannelLayout->mChannelDescriptions[5].mChannelLabel =
kAudioChannelLabel_RightSurround;

I'd need to find a solution that works well for all users on 10.5
onwards that doesn't introduce breakage. Regardless of whether the
channel re-ordering is changed, the ffmpeg args are changed or the
atoms are manually adjusted after the fact with something like Atomic
Parsley.

[gbooker]

If compatibility is desired, perhaps removing the dac3 atom would be the trick. A52Codec uses this to key on whether to use Apple's wrong layout, or to use the one that's been used for years before them. Then, the layout is statically assigned using the channel layout to what A52Codec would expect when the dac3 atom is not present.

Technically, this is all invalid as far as the MP4 spec is concerned, but Apple has left us little choice in the matter.

[auburn3020]

So if A52Codec were to encounter a .mov with no dac3 atom at all, it would default to the standard channel configuration (not Apple's)?

[gbooker]

Yes. Since it is never told the channel layout, nor does it seem like it is possible for it to find out what layout is in use, I used the presence of the dac3 atom to attempt to determine which layout was in used. Before your clips, I had not encountered a file that had a dac3 atom as well as a channel layout.

[auburn3020]

Yep, using HexEdit to change "dac3" to "dxxx" fixes the issue. Here's a copy of the HexEdited version, same file as the original .mov above with just the dac3 atom changed to dxxx:

http://www.mediafire.com/?ya5j1cnu0nrmffe

Both versions play fine under Perian 1.2.1, but only the HexEdit version plays audio under 1.2.3. I didn't test 1.2.2.

Now to figure out how to repair the atoms on (I'm guessing here, I have a big library) hundreds of previously-recorded .movs... and their backups. Oy, vey...

[gbooker]

I'll look at the file to see if there's anything else that the codec can key off of to determine which layout is in use. I don't have high hopes as Apple seems to have intended for codecs to not know the layout.

[auburn3020]

Steve is adding a tool to HDPVR Capture that will strip the dac3 atom from existing .movs or .mp4s. I've successfully tested a beta version, and I'll post a couple of sample files I've run the dac3 stripper (uh huh huh) routine on later. They might be useful to you going forward.

Thanks again for all the help here.

EDIT: Here are two "fixed" test files:

http://www.mediafire.com/?lid5nggega58ce1

http://www.mediafire.com/?iay87wdl0ed9yod

[gbooker]

I looked at these files. Unfortunately, there isn't anything that the codec can use to key on which layout to use aside from the dac3 atom. It looks like fixing the files is the only route forward that doesn't break compatibility with a majority of files with these atoms.

[auburn3020]

I looked at these files. Unfortunately, there isn't anything that the codec can use to key on which layout to use aside from the dac3 atom. It looks like fixing the files is the only route forward that doesn't break compatibility with a majority of files with these atoms.

That's fine. The file fix is easy, and Steve had the foresight to idiot-proof the code; the tool ignores and leaves untouched any file that doesn't have the dac3 atom. Crazy that Apple just completely ignores the overall AC3 issue (if I remember correctly, even Apple doesn't use the layout that's in their own spec), but this is a benign-enough work around.

Thanks again.