I got some basic questions regarding the mkv format.
Overall I see blu-ray movies are ripped to this format. Let say a movie is 20 GB, but the mkv file will end up all between 8-12 GB.
Now I myself tested mkvmerge GUI, a tool used to make it from the original blu-ray format to mkv. I saw the output file more or less resembled the original file, both in size and quality. I'm not sure how much quality drop mkv conversion does.
One thing I noticed was the change in frame rate, if original frame rate was 29.970 I ended up with 30.000, what happened here?
The size was pretty much the same, so I wonder what is mkv for? As I mentioned movies uploaded are down scaled to 8-12 GB, what app does this job? And why are they first making a mkv file for then to down scale the size? Why not do it at once? Or is it just that mkvmerge can't do this...
What are the names of apps that scale down the size of a mkv?
+ Reply to Thread
Results 1 to 16 of 16
Frame rate should NOT change, regardless, unless the user (or app) doesn't set it correctly.
You are getting close to the truth when you say "more or less resembled".
Putting the same visual media (MPEG2, AVC, VC-1) into an MKV container doesn't do ANYTHING to either the size/bitrate or quality. Re-encoding does.
Going from AVC->lower bitrate AVC, or MPEG2->lower bitrate AVC or VC-1->lower bitrate AVC is how those re-encoding programs usually work and how they get their file savings.
Most times, they are using an x.264 encoder engine.
Don't know what you mean by "doing it first...do it at once". A lot of this depends on the app you've chosen. Most these days are just front-end GUIs to back-end CLI/DLL apps.
And you've got to remember there are 2 steps here: Ripping (disc->HDD, along w/decrypting) and Converting. Too many people around here get those confused. All BD movies are RIPPED to either ISO discimages or M2TS/SSIF (and accompanying) files in the BDMV folder structure. The conversion & re-encoding is the 2nd step where it can become MKV, MP4, AVI, etc.
edit: so the 1st stuff mentioned by Baldrick include apps that do RIPPING + REMuxing, not RIPPING + Converting. The 2nd, ripbot264 is the latter.
Last edited by Cornucopia; 6th Feb 2013 at 15:49. Reason: additional info
Another thing, can a m2ts file be ripped down in quality but still have the m2ts file output, resembling the original file but being ripped.
@MindController, the way I see it, most people fall into one of 4 categories:
1. Ripping 1:1 only (though possibly just "movie only" or specific streams, etc). Output is ISO or original streams in original containers, or original streams remuxed into containers that work with a specific playback device (MKV, MP4). The idea here is full, original quality & not doing much to change anything.
2. Ripping+Converting into a somewhat smaller monolithic file in a usually-different container, with the idea of maintaining decent remaining quality at a more portable & palatable size for the given output devices (usually more than 1).
3. Ripping+Converting into a smaller form, but re-authoring into a CE format that can play on BD and/or DVD players. The idea here is keeping what best quality is possible, while providing a format that is universal & sharable (particularly with old-school friends/family).
4. Ripping+Converting, like #2, but with quality taking a back seat to size & simplicity. This is mainly the jurisdiction of newbie fan/mass-collectors, or alternately of warez uploaders.
Each of these would have a different toolset. If you are more of a #4 than a #2 person, you won't do multiple tool steps that could have helped retain the quality. If you are more a #1 person, you only need a good ripper and accompanying demuxer/remuxers.
If you were using DVDFabHDDecrypter, and you wanted the BEST quality (but still at a lower size), rip to ISO or original M2TS folder structure and then use something like handbrake to optimize your bitrate-reduced conversion. No need to go to MKV in between.
@nicolani, an M2TS file is just a specific kind of MPEG2-TransportStream container. You can retain the original V+A streams in it, or you can re-encode to lower bitrate streams and remux into a similarly formatted container. If you go for bitrate reduction, you will HAVE to re-encode. That has accompanying lower filesizes, but also accompanying lower quality. How much lower quality is VERY DEPENDENT upon many factors, including the complexity of the image & its motions, and your encoding settings & encoder choice, so I can't give you any particulars right now. Get this clear though: what you would be doing is MUCH MORE than just ripping. Also, rarely do people re-encode BACK into a container similar to it's original setting, without re-authoring. What would the point be?
Know also that "just decrypting" without ripping is what you do when you are PLAYING the disc. If you want the contents separated/extracted from the disc and onto a HDD, etc., what you are doing then is RIPPING. For that, the 2 you mentioned are probably the 2 best RECENT apps to use (I still prefer to use DVDDecryptor for many discs, though).
Fortunately, the list of devices that support MKV is growing. Most standalone media players support it. Many Blu-ray players and HDTVs that play A/V files on USB storage devices support it. Unfortunately, there are a few high profile devices that don't support MKV. Like the PS3, Xbox 360, Apple TV.
Last edited by jagabo; 7th Feb 2013 at 06:40.
Reading this thread I got the feeling that MKV does an exact copy of the source file. Doing my own test and running mkvmerge with a blu-ray source file I could see that the output in the MKV file changed. And it's different changes for different sources, as I already pointed out in previous post, when my frame rate changed.
Source overall bitrate: 22.6, MKV 22.4.
Source BVOP: yes, MKV no.
Source codec id: 2, MKV V_MPEG2.
And stream size and pixel*frame differences.
A "container" is a standardized way of organizing data so different programs can access that data. So every programmer on earth doesn't store their data differently, making it inaccessible to everyone else.
Last edited by jagabo; 7th Feb 2013 at 15:42.
To understand why & how something is the way it is in a container, you kind of need to know the provenance of the file, too. You can't just make a singlehanded judgement about MKV vs. M2TS or something, there are too many variables.
It would be quite easy to show a M2TS which included, say VC-1 video & DTS audio and an MKV with the VERY SAME VC-1 video & DTS audio, where the only difference was filesize overhead between the 2 containers. It would be just as easy to show that same M2TS and a resulting MKV that had re-encoded to AVC video & AAC audio at 1/2 the bitrate, yet the framerate & samplerates were the same. 3rd, there could be a resulting MKV where someone tried to re-encode back to VC-1 & DTS but did a crap job, lowering the BR too much and also inadvertantly changing the framerate & samplerate to something that will crap out on lots of players. Happens all the time out in Internet-land.
If I remember correctly when working with M2TS files from my Hauppauge a couple of years ago, I had a hell of a time with out of sync videos when muxing with MKVmerge. Not sure but I believe the only way that I could reliably work with these files was with Videoredo. I know with DVDs, there are files in the DVD structure that tell the player when to start the audio and when to start the video. I assume that BD is the same and that Videoredo writes something to the file to tell it when to start the audio compared to the video and that MKVmerge is not capable of doing this on it's own. Just my assumption. If you knew how many seconds of delay that the audio had then you could manually fix it with a lot of trial and error but if you have a few files to process and don't want to deal with the headaches, it may be easier just to dish out $100 for Videoredo.
MediaInfo shouldn't have it's information taken as gospel. It does a lot of rounding and "guessing". The question is, have you tried doing it the other way around using an MKV as the source? If so, I think you'll find similar things will happen. I just opened an MKV containing MPEG2 video and AC3 audio. According to MediaInfo, the video in the MKV is 5008kb/s. After remuxing it as an m2ts file using tsmuxer, Mediainfo reported the bitrate as 4848kbps, yet it's the same video. The file size also increased from 1.5GB to 1.6GB due to m2ts files using more overhead than MKV.
I do like that the list of support is growing as well.
One thing I do dislike about .mkv though is I always seem to have trouble storing LPCM audio within it, where .m2ts will store it fine.
What jagabo said. It's a container, as in the system uses it to determine what type of video is contained in the file. Most mkv files use the h.264/x.264 codec. The .mp4 container/files can also use h.264 among other codecs. However, the .mkv container has more features.
There are some good guides here to codecs and containers. Check them out. The handbrake and avidemux doc sites are also very good.
Note that while h.264 is probably the best codec, there is no magic one that will automatically give you great results. I've seen quite large .mkv files that were awful. Just wretchedly encoded by someone using advanced tools they didn't have a clue how to use. I've seen much smaller xvid .avi's that were miles better.