|
Hi guys,
just wondering if there's any difference in this workflow (other than efficiency of passes/typing/processing involved) for a BD title with a VC-1 video stream...
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?
I do notice this in the output of the 2nd step (again, if using the initial 2-step process):-
VC-1, 1080p24 /1.001 (16:9)
Muxing video to Matroska...
Added fps value to MKV header.
...so the .vc1 file must have retained some of the original attribute information in some way? I'm just not knowledgeable enough to know if there's going to be any difference between the methods here!
cheers,
m
|