View Single Post
Old 6th February 2009, 19:42   #8154  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by honai View Post
I'm trying to remux an MKV I created with an earlier version of eac3to which still contains pulldown information.

However, demuxing with -demux works and eac3to correctly identifies the video as VC-1.

Is this a bug or intentional misbehavior?
Support for such older VC-1 MKVs will come in a future version.

Quote:
Originally Posted by Snowknight26 View Post
Madshi, though you say you plan on adding chapter and subtitle demuxing from mkvs, you didn't mention attachments. Any plans for those?
In the long run, yes. In theory it's really easy to extract MKV attachments. However, making the eac3to infrastructure understand that there are not only "video", "audio" and "subtitle" tracks, but also "attachments" is quite a lot of work. So it might take a while until I find the time to implement that. Don't know...

Quote:
Originally Posted by Snowknight26 View Post
Also, doing anything with eac3to over a network share seems to be really slow. I'm remuxing an mkv and eac3to uses 0% CPU usage 90% of the time. It spikes up to about 10% for a fraction of a second... same with the network usage graph.
Anyone else having similar problems? It seems to work fine for me. Did older versions work better?

Quote:
Originally Posted by Snowknight26 View Post
Wonder why most can't be parsed while a few odd ones (like this first one) can
Because some of them have sequence headers in the stream and some don't.

Quote:
Originally Posted by Snowknight26 View Post
And finally, a small observation. Analysing mkvs with FLAC audio tracks takes far longer than ones with AC3 or DTS. Weird how that happens.
That's because eac3to actually decodes the FLAC track during analyzation. I guess I can optimize that...

Quote:
Originally Posted by tebasuna51 View Post
I suggest to madshi don't put the bitdepth of the source with standard DTS and DTS HR because this data is misunderstand (and irrelevant).
Might be a good idea, at least to get rid of all these annoying "is it really necessary that eac3to patches it to 24bit?" questions. Will think about it.

Quote:
Originally Posted by magic144 View Post
Up until now, I've just been using:-

eac3to L: 1) -demux, followed by
eac3to video.vc1 video.mkv

to demux and then put/house the demuxed .vc1 'raw' output into a more useful .mkv container for graphedit to use for frameserving (via Haali Media Splitter, WMVideo Decoder DMO)

however, I'm curious to know if that would produce *exactly* the same video result (frame-for-frame) as, e.g. (assuming track 2 is the video in question):-
eac3to L: 1) 2: video.mkv

would the first 2-step method lose/discard any important information (frame-rate, etc) that the original container used to define the .vc1 stream?
I have read that a raw .vc1 stream is somewhat dependent on its container to fully specify it, so I'm worried that a 2-step process would be lossy in some way?
Both methods should produce similar results, as long as there are no gaps/overlaps in the video track (which is really rare). VC-1 does not depend on the container.

Quote:
Originally Posted by odin24 View Post
Is it possible that eac3to reports the wrong information in regards to 1080p or 1080i? I have a BD that says 1080i on the back... which is odd, however eac3to and tsMuxeR both report 1080p. I trust eac3to more than what's on the back cover.
eac3to reports two different things: In the track listing (e.g. if you do "eac3to BluRayFolder") eac3to shows what the Blu-Ray information records say without actually looking at the video data itself. This information *should* be reliable, more so than the back cover, but it could theoretically be wrong. If you actually let eac3to parse the movie file, it checks out the video bitstream. This should be even more reliable (unless there's a bug in eac3to). In your specific case it seems that the back cover is simply wrong.

Quote:
Originally Posted by Blue_MiSfit View Post
Here's another silly sample for you, Madshi (20mb cut of source AC3)

This one is the 3.1ch 640kbps AC3 track from the BluRay release of Bubble. eac3to complains about encoding it down to a 2ch AC3
eac3to currently can't downmix funny channel configurations. It's on my to do list to add support for that, but it doesn't have top priority right now...

Quote:
Originally Posted by idbirch2 View Post
I just demuxed Eight Below, purely to see the subtitle information and if the english SUPs contained any forced captions and there's a discrepency between the subtitle track numbers displayed at the beginning of the log and those used at the end to display forced caption info.
Thanks, looks like a clear bug.

Quote:
Originally Posted by pihug12 View Post
Why can't I demux a MKV file in an another output folder (ex: eac3to.exe video.mkv temp -demux) ?
You can't just invent your own command line commands. You'll have to live with what eac3to understands. What you could do is "eac3to video.mkv temp\video.*". That will demux into the MKV into a folder named "temp", if that's what you want.

Quote:
Originally Posted by laserfan View Post
Today I looked at my new Vantage Point BD and eac3to reported 51 chapters. This movie has 16 chapters so on a hunch went back to an earlier version of eac3to and sure enough, got 16 chapters. After trying subsequent versions I found that it broke going from v2.65 to v2.66
Can you please upload the CLIPINF and PLAYLIST folders? Zipped that should only be a few KBs.
madshi is offline