eac3to + 50-80mbps MPEG-PS = wierdness

[Blue_MiSfit]

Hi All,

I'm having some problems with eac3to and some very large MPEG program streams.

My sources are 50-80mbps CBR MPEG-2, 1080p or 1080i, both 4:2:2 and 4:2:0. Typically audio is muxed in as 2ch MP2 or 6ch AC3.

As such, I imagine the program stream muxing is somewhat exotic, or at least unusual.

eac3to usually works beautifully on these sources, but some are problematic.

For example, on one title eac3to complains:

C:\>eac3to d:\141622\OUTLAW_16X9_2007.mpg
This track is not clean. Processing aborted.
Please clean the track with delaycut and then retry eac3to.
EVO, 1 video track, 1:44:48
1: MPEG2, 1080p24 /1.001 (16:9)


This source actually has 640kbps AC3, which will extract perfecly with DGIndex, plus the source plays fine in Media Player Classic.

Here's the first 20 seconds:
http://www.mediafire.com/?sharekey=32d600f0ab3cb846d2db6fb9a8902bda

I'm guessing this has something to do with how the program stream was muxed, given that it has a massive bitrate.

I'm hoping madishi (or someone equally savvy) can help me work through this issue. Only one of my encoding houses is actually delivering problematic files, and even then - some are fine. Many other houses are able to deliver 50mbps or 80mbps program streams that eac3to handles with ease.


~MiSfit

[Blue_MiSfit]

Quick update - I updated eac3to to the latest version, and now it doesn't complain about the track not being clean, it simply doesn't see an audio track - period :)

~MiSfit

[Blue_MiSfit]

Another oddity - when I run this source through MPEG2Cut2 with its default parsing options enabled, things work perfectly fine (!)

I was curious, so I just remuxed the whole title with MPEG2Cut2, and not only did everything work perfectly, I also got MUCH faster speed when encoding the stream (42fps in the first pass, versus 11fps previously (!!!))

This is turning into less of an audio encoding question, and more of an MPEG Program Stream structure question, but I think my original motive stands.

How the heck can I make eac3to get audio out of these streams (without remuxing them all, since I have hundreds to work with every week)

~MiSfit

[madshi]

I'm confused. You say you get much better speed when "encoding the stream". What do you mean with "encoding the stream"? And the better speed is better compared to what? You didn't talk about encoding before in your other posts.

About eac3to not listing the audio source: Can you create a little sample for me? Probably just the first 50MB of the EVO file would do. I'm just now downloading the sample you already uploaded. Maybe that will already help me reproduce the problem here? Generally I can quickly tell you why eac3to behaves the way it behaves for any samples you make available to me.

Big bitrates are generally not a problem at all. The one thing which eac3to absolutely hates is corrupted source files. That can be corruption in the container. Or corruption in the video or audio tracks. eac3to currently doesn't handle such files well. AC3 tracks are very extensively checked by eac3to. If any AC3 frame is broken, eac3to will abort processing (or not list the audio track to begin with). Or if there are any dummy bytes between the AC3 frames, eac3to will also abort processing (or not list the audio track). Only one wrong bit will be enough for eac3to to refuse to handle the track. AC3 frames are completely protected by a CRC (unlike most other video and audio tracks), so eac3to will find any bit of corruption.

[madshi]

Checked that sample you uploaded. There's a bug in eac3to which will be fixed in the next build (probably out Sunday). It will make the AC3 track in this specific sample work. Hopefully it will also fix the other problems you encountered. If not, let me know.

[Blue_MiSfit]

Thanks for taking the time to look at my sample! Much appreciated!

For the record, this isn't an EVO, it's a vanilla MPEG-PS (at least according to the folks who supplied it).

Also, regarding encoding, I was referring to x264 encoding using very fast settings through this workflow:

MPG -> Haali splitter -> MPC-HC's MPEG-2 Decoder -> AviSynth -> x264.

Using the original source, I got ~12fps, and less than full CPU usage, so it seemed like a decoder, avisynth, or disk bottleneck.

After remuxing with MPEG2Cut2, I got 42fps(!)

My guess is that MPEG2Cut2 does something with interleaving / buffer sizes, but I know nothing of how MPEG Program Streams work :)

~MiSfit

[madshi]

For the record, this isn't an EVO, it's a vanilla MPEG-PS (at least according to the folks who supplied it).
"MPEG program stream" is the format VOBs and EVOs are stored in. eac3to checks whether an "MPEG-PS" file is a DVD. If so, it's reported as "VOB", otherwise it's reported as "EVO".

Also, regarding encoding, I was referring to x264 encoding using very fast settings through this workflow:

MPG -> Haali splitter -> MPC-HC's MPEG-2 Decoder -> AviSynth -> x264.

Using the original source, I got ~12fps, and less than full CPU usage, so it seemed like a decoder, avisynth, or disk bottleneck.

After remuxing with MPEG2Cut2, I got 42fps(!)

My guess is that MPEG2Cut2 does something with interleaving / buffer sizes, but I know nothing of how MPEG Program Streams work :)
I guess the Haali splitter likes the modified file better. Don't know why.

Anyway, the original problem should be fixed now in the latest eac3to build:

http://madshi.net/eac3to.zip (v2.71)

[Blue_MiSfit]

Thank you so much Madshi!