How to crop mkv without losing quality?

[MalickT]

Hi. I like to crop 132 pix from top and bottom. How to do that without re-encoding? I tried MKV Merge GUI cropping method but this did not change anything and I read about it that MKV Merge cropping method hasa bug, thats why it does not work.

[Ghitulescu]

You can't. And if you searched this forum you have found also why not.

[hello_hello]

You'd think it'd only take 15 seconds longer to type the reason it doesn't work than it would to tell someone to search the forum and have them spending who knows how long trying to find the answer.

MalickT, I think the short answer is MKV's cropping feature isn't supported by many players, or maybe not properly supported at all. I tried a bit of experimenting with it a while back and VLC seems to support cropping from the top and bottom but not the sides (newer versions may be different) while I couldn't get it to work properly using MPC-HC at all not matter what combination of splitters and decoders I tried. The best it seemed to do is squish the sides of the video by the set cropping amount rather than actually crop it. I never even bothered testing for hardware player support.

At one stage (I think using MPC-HC, Haali splitter and ffdshow) when opening a "cropped" MKV the player would open to the "cropped" dimensions, pause for a second, then open to the full resolution and play the video without cropping. It's as though the cropping was supported by the splitter but then ignored by the decoder. Either way, I'd not bother trying to crop an MKV that way.

PS I do recall reading it's possible to add cropping parameters to a h264 video stream itself rather than at the container level, but I never got around to working out if there's a practical way to do it or whether it works.

[sneaker_ger]

PS I do recall reading it's possible to add cropping parameters to a h264 video stream itself rather than at the container level, but I never got around to working out if there's a practical way to do it or whether it works.

It can be done with roozhou's ffmpeg build, but it's limited to cropping between two mod-16 resolutions, max 14/15 pixels from the right and bottom. On the other hand it works in all players, unlike the Matroska cropping.
But it's also just a flag, so you won't save any bits.

[hello_hello]

Interesting, sneaker_ger.... thanks for the info.

Not that I'm probably ever likely to use it given the restrictions, but I'll file it away in the memory bank in case it comes in handy one day.

[QuantumRand]

Sorry to bump a solved problem, but I'm curious what use cropping would have without a re-encode. Without re-encoding it, it wouldn't save any file space, correct? And if it's something like 1920x816, you'd end up with black bars on a 1080p display whether or not you cropped it.

The only reasons I can think of to do it would be if you have a very unusual video file containing a 1080p movie but encoded at 1920x1200 and you wanted to play it on a 1080p display (something that can be remedied by using a player with custom zoom features). Alternatively, if you had a 16:9 movie and a 4:3 display, cropping the width would get rid of the black bars, but you'd lose most of the movie (which is far from ideal).

I wouldn't think either of those situations would come up often at all. Are there other situations that would benefit by cropping like that?

[Asmodian]

16:9 or wider encoded in 4:3 on a 16:9 or 16:10 display.

I use Zoom Player to do this but ffdshow works very well too.

[diogen]

Sorry to bump a solved problem, but I'm curious what use cropping would have without a re-encode. Without re-encoding it, it wouldn't save any file space, correct? And if it's something like 1920x816, you'd end up with black bars on a 1080p display whether or not you cropped it.I think it was Stacey Spears who said that 2.35 video within a 16:9 frame on a BD/HD encode wastes about 300kbps of bandwidth.

That is peanuts when compared to BD ABR, but can shave a couple hundred MB off of the final size reencode to fit onto a SL DVD...:)

Diogen.

[QuantumRand]

16:9 or wider encoded in 4:3 on a 16:9 or 16:10 display.

I use Zoom Player to do this but ffdshow works very well too.

Exactly. That's the only circumstance I can see it being useful. Other than that, I can't think of any other reason to do it.

I think it was Stacey Spears who said that 2.35 video within a 16:9 frame on a BD/HD encode wastes about 300kbps of bandwidth.

That is peanuts when compared to BD ABR, but can shave a couple hundred MB off of the final size reencode to fit onto a SL DVD...:)

Diogen.

But if all you're doing is cropping without re-encoding, it doesn't save the space. All of that data is still there, just not shown on screen.

[diogen]

But if all you're doing is cropping without re-encoding, it doesn't save the space.If this is possible, I dont know how.

Stacey Spears (sspears on AVS) is one of the VC1 creators and was talking from the BD/HD creation point of view.

Diogen.

[QuantumRand]

If this is possible, I dont know how.

Stacey Spears (sspears on AVS) is one of the VC1 creators and was talking from the BD/HD creation point of view.

Diogen.

I have no doubt that cropping can save a bit of space if you re-encode it.

From what Hello_Hello says, it is possible to do it via remux without having to re-encode, but most players don't support it. And as Sneaker_ger said, ffmpeg is potentially capable of doing it too.

I was just curious if there were other reasons to do it that I hadn't thought of.

[vrpatilisl]

cropping without reencode not possible yet.

[QuantumRand]

cropping without reencode not possible yet.

Sure it is.

http://quantumrand.net/misc/CropFilterSmall.png (http://quantumrand.net/misc/CropFilter.png)

I'm not so sure you can append those settings to the file itself though.

[Ghitulescu]

As ffdshow does what its name says what you do it's not cropping, it's "Pan & Scan" at playback, the file remains as it was.

[vrpatilisl]

@Quantum Rand
Hey that cropping is temporory. Not stored in video file.

[ramicio]

No, it's cropping. Pan and scan is done somewhat manually to crop out video that is wider than a screen...to keep the focus on what is important, not to crop out black bars from any source. What ffdshow does is cropping, as there are no other settings than just pixels to crop by.

I don't see how 300 kbps is minimal. It's 135 MB per hour. 30kbps is minimal...

[Ghitulescu]

No, it's cropping. Pan and scan is done somewhat manually to crop out video that is wider than a screen...to keep the focus on what is important, not to crop out black bars from any source. What ffdshow does is cropping, as there are no other settings than just pixels to crop by.

By definition, P&S defines a "window" that is supposed to be displayed from a much larger area. It is not necessary for P&S to crop left and right, although this is its most useful/used feature.

Try to define a P&S zone of say 240 scanlines from an eg DVD and see what happens :)

[Asmodian]

By definition, P&S defines a "window" that is supposed to be displayed from a much larger area. It is not necessary for P&S to crop left and right, although this is its most useful/used feature.

Try to define a P&S zone of say 240 scanlines from an eg DVD and see what happens :)

P&S (http://en.wikipedia.org/wiki/Pan_and_scan) implies a pan doesn't it? I think of P&S as a way to move the crop to follow the action better when going from widescreen to 4:3. I wouldn't really call a standard crop P&S. :rolleyes:

I guess you could use a pan and scan system to do a basic crop but that doesn't make all crops pan and scans does it?

[hello_hello]

By definition, P&S defines a "window" that is supposed to be displayed from a much larger area. It is not necessary for P&S to crop left and right, although this is its most useful/used feature.

By definition, Pan & Scan is the adjustment of a widescreen image in order to display it using a 4:3 aspect ratio. You could probably stretch the definition to include adjusting it to display using a 16:9 aspect ratio also, but other than that, cropping is just cropping.

[Ghitulescu]

P&S (http://en.wikipedia.org/wiki/Pan_and_scan) implies a pan doesn't it? I think of P&S as a way to move the crop to follow the action better when going from widescreen to 4:3. I wouldn't really call a standard crop P&S. :rolleyes:

I guess you could use a pan and scan system to do a basic crop but that doesn't make all crops pan and scans does it?
What you said is a pan. Where's the scan, then?

see also below.

By definition, Pan & Scan is the adjustment of a widescreen image in order to display it using a 4:3 aspect ratio. You could probably stretch the definition to include adjusting it to display using a 16:9 aspect ratio also, but other than that, cropping is just cropping.

I don't knowhere you get your information from, but as usual, like everything else you "mentally create" or search in google in a desperate need to contradict, is "unilateral".

P&S is not what someone, albeit well-intended, thinks, but what people that actually invented it think..
It#s like the other most common wrong definition - to rip, ripping, that means nothing else that to get the content out from a of a container. Its meaning changed today to include the conversion as well.

[QuantumRand]

Using mkvmerge GUI v5.2.1, I was able to crop without re-encoding; however, not all players cropped the resulting video. VLC player worked fine, but WMP simply played back the original video. I don't know if it was WMP itself, or if my codec/configurations need to be tweaked to make it work. Regardless, mkvmerge 5.2.1 can do it.

[Ghitulescu]

Using mkvmerge GUI v5.2.1, I was able to crop without re-encoding;

That's not cropping - cropping means to take away parts of an image - what you did is actually only to instruct the player not to display some parts of the image (a method called pan&scan). Nothing more. These parts remain in the file (thus no reencoding is performed).

In theory one can crop without reencoding those mattes, provided their black is constant and only with a MOD16 granularity. AFAIK this was not implement in any codec I know. A lot of work with little benefit for the endusers.

Cropping (as the A/V/P technology understands it) is therefore not possible without reencoding.

[QuantumRand]

That's not cropping - cropping means to take away parts of an image - what you did is actually only to instruct the player not to display some parts of the image (a method called pan&scan). Nothing more. These parts remain in the file (thus no reencoding is performed).

In theory one can crop without reencoding those mattes, provided their black is constant and only with a MOD16 granularity. AFAIK this was not implement in any codec I know. A lot of work with little benefit for the endusers.

Cropping (as the A/V/P technology understands it) is therefore not possible without reencoding.

Well if you want to use that definition of "cropping," then of course it's not possible without re-encoding. An x.264 video isn't like a bitmap where each pixel gets its own color assignment. It's more like a jpeg where all of the pixels reference each other. Cropping anything in that fashion without a re-encode would remove sections that other pixels rely on (I'm certain you already know all this, but I suppose I'm just posting it anyway in case another noob like myself stumbles upon the thread and is curious).

Obviously what the OP was after is the same result you'd get from cropping, but without the need to re-encode. I'm pretty sure that all he cares about is that it's cropped at playback, not the additional XXXMB you'd save get from removing black bars.

In answer to the OP's question (which I'm pretty sure someone already stated), the MKV Merge GUI (at least version 5.2.1) method of cropping does work, but not for all players/codec configurations.

[Ghitulescu]

Well if you want to use that definition of "cropping," then of course it's not possible without re-encoding.
A definition of a term must be used as it was given in that particular field or technology. And in audio-video-photo cropping means to take a pair of scissors and to cut some parts out. :) To "black" them means to matte them or matting. To show only a part of it is P&S or display view or viewport, sometimes, and only in a precise context, soft matting.

And a real crop is possible in particular conditions. But no SW I know does it.

[vrpatilisl]

consider i passthru both video and audio to output mkv from Dvd. Can it possible to crop those black border permenantly?

[QuantumRand]

consider i passthru both video and audio to output mkv from Dvd. Can it possible to crop those black border permenantly?

Yes, MKV Merge GUI can remove the black bars from showing up during playback, but I dare not call it cropping.

When you "crop" with MKV Merge (I put it in quotes because MKV Merge calls the setting "Cropping" even though that's apparently the wrong term for it), it doesn't remove any of the video data from the file. It simply adds a bit of information on how to display it. Keep in mind that not all players support this, though.

[vrpatilisl]

means black bar still there but flag doesnt allow to show then. Then what is the use space and bitrate not saving.

[Ghitulescu]

Who cares about space and bitrate savings? :)

[vrpatilisl]

sometime we have to care about it.

[QuantumRand]

means black bar still there but flag doesnt allow to show then. Then what is the use space and bitrate not saving.

That's kinda what I was asking in my first post in this thread. The only uses I've been able to think of are 16:9 videos that are encoded to 4:3 and you want to display it on a 16:9 display.

It just isn't possible to edit the frames of the video without re-encoding.

As a very basic example, pretend you have a 12x12 frame of a black ball. The top and bottom 2 rows are black bars, and the ball sits on a rainbow background. Imagine RGBY = Red, Green, Black, Yellow.

B B B B B B B B B B B B
B B B B B B B B B B B B
G Y R G Y R G Y R G Y R
Y R G Y R G Y R G Y R G
R G Y R G Y R G Y R G Y
G Y R G Y R G Y R G Y R
Y R G B B B Y R G Y R G
R G Y B B B R G Y R G Y
G Y R G Y R G Y R G Y R
Y R G Y R G Y R G Y R G
B B B B B B B B B B B B
B B B B B B B B B B B B

Let's pretend that the image is analysed and it's decided that the most efficient way to encode it is in defined blocks of:

B B B
B B B = 0
G Y R

Y R G
B B B = 1
B B B

G Y R
Y R G = 2
R G Y

The resulting frame would be encoded to:

0 0 0 0
2 2 2 2
2 0 2 2
1 1 1 1

If you wanted to try to crop the bars from that, you'd also be stripping away an additional row of the rainbow background. Instead, you have to re-encode it. Because once you remove any data, the reference data (represented by the "defined blocks") will change.

[Ghitulescu]

sometime we have to care about it.

You'll gain less than 1% by removing real black bars, and anywhere else except on a PC you'll have them added again.

[vrpatilisl]

@ QuantumRand
nice explain budy.

[hello_hello]

I don't knowhere you get your information from, but as usual, like everything else you "mentally create" or search in google in a desperate need to contradict, is "unilateral".

No, unlike you, I don't blatantly make stuff up and post it as fact.
Unfortunately Google doesn't seem to have a specific way of searching for Ghitulescu imaginings, so I have to go with the standard search results.

http://en.wikipedia.org/wiki/Pan_and_scan
"Pan and scan is a method of adjusting widescreen film images so that they can be shown within the proportions of a standard definition 4:3 aspect ratio television screen...."

http://www.audioholics.com/education/display-formats-technology/understanding-widescreen-letterboxed-and-pan-scan
"Pan and Scan
Movies encoded into 4:3 ratio by intelligently panning and scanning horizontally across the widescreen film to keep the action in the middle of the screen..."

http://www.thefreedictionary.com/pan-and-scan
"A method of printing movies for presentation on television that modifies the rectangular theater image by trimming the sides and focusing on significant action within the newly truncated image."

http://www.webopedia.com/TERM/P/pan_and_scan.html
"In the film and movie industry a term used to describe the method of adjusting a widescreen film to fit an ordinary television screen."

http://dictionary.reference.com/browse/pan+and+scan
"a technique for changing the aspect ratio of a wide-screen film, usually by selecting the significant section of a screen shot and cropping the sides, so that it can be transmitted for regular-format television."

P&S is not what someone, albeit well-intended, thinks, but what people that actually invented it think..

Exactly. It doesn't take on a different meaning to suite you.

It#s like the other most common wrong definition - to rip, ripping, that means nothing else that to get the content out from a of a container. Its meaning changed today to include the conversion as well.

That's funny. You must have a very short memory, because only a day ago you caused yet another thread to be closed by arguing a question regarding ripping couldn't imply conversion, while everyone else in the conversation assumed it probably would.
http://forum.doom9.org/showthread.php?p=1556740#post1556740

[hello_hello]

Well if you want to use that definition of "cropping," then of course it's not possible without re-encoding.

It's just a silly argument of semantics.
If cropping means to "take away parts of the image", and on playback you "took away parts of the image" then you cropped the image on playback.
Whether it's cropped before it's encoded or after it's encoded, it's still cropped.

[Ghitulescu]

No, unlike you, I don't blatantly make stuff up and post it as fact.
Unfortunately Google doesn't seem to have a specific way of searching for Ghitulescu imaginings, so I have to go with the standard search results.

All of you quoted is irrelevant, none of them is an authoritative source.

Unfortunately for you I am not allowed to give you details for P&S as they are, instead I'll point you to the pan & scan process that gave its name (remember, some definitions are not bijective, see below) - it's US3698806.

Of course, a guru like you probably never asked himself why so many parameters have been introduced both in picture_display_extension and in sequence_display_extension fields, when it would have sufficed to input only the ordinal number of the starting pixel (the height is known = 16:9 height, the width is also known - computed from 4:3).

As I said, pan&scan as defined in those free dictionaries is a particular example of the original process. What if all cars would have been called Benz instead of car or auto, just because a Benz is a car (the only one at that time), so a car is a Benz?

[hello_hello]

All of you quoted is irrelevant, none of them is an authoritative source.

Ghitulescu is hardly an authoritative source either.

Unfortunately for you I am not allowed to give you details for P&S as they are, instead I'll point you to the pan & scan process that gave its name (remember, some definitions are not bijective, see below) - it's US3698806.

LOL! Now Pan and Scan is some sort of state secret.
Yes, I read the patent, and I'll concede according to it pan and scan, while primarily designed for reproducing wide screen video in an aspect ratio suitable for television, is according to the patent, also a method of converting widescreen images to a different aspect ratio. (although I'd be keen to know if there's an example of it being used for anything else but TV conversion).
Now it's your turn to be an adult for once, read the patent, and concede there's no way simple cropping can constitute pan and scan.
http://www.patsnap.com/patents/view/US3698806.html

Of course, a guru like you probably never asked himself why so many parameters have been introduced both in picture_display_extension and in sequence_display_extension fields, when it would have sufficed to input only the ordinal number of the starting pixel (the height is known = 16:9 height, the width is also known - computed from 4:3).

Of course even a guru like me has no idea what you're on about there.

As I said, pan&scan as defined in those free dictionaries is a particular example of the original process. What if all cars would have been called Benz instead of car or auto, just because a Benz is a car (the only one at that time), so a car is a Benz?

And as I said, cropping is cropping, not Pan and Scan. That's why, to use your analogy, cropping a video isn't called panning and scanning.

[Ghitulescu]

Yes, I read the patent, and I'll concede according to it pan and scan, while primarily designed for reproducing wide screen video in an aspect ratio suitable for television, is according to the patent, also a method of converting widescreen images to a different aspect ratio. (although I'd be keen to know if there's an example of it being used for anything else but TV conversion).
Now it's your turn to be an adult for once, read the patent, and concede there's no way simple cropping can constitute pan and scan.

Divide your age by ten and you'll obtain your mental age.

The pan and scan process, as defined by people providing the technique and materials to Hollywood (in this case Technicolor) was defined in a public document, so even people relying entirely on google and wikipedia could access it for free to pretend they are smart, 10 years before 16:9 draft and 20 years before the very first 16:9 TV sets. The implementation of P&S is regulated by SMPTE, but I think you're too cheap to buy one of their standards.

Surprise me with another sophism, how could they use "improperly" the term/process of P&S, at least 10 years before the invention of 16:9..... because no film ever had a DAR of 16:9.

And vice versa, there are movies shot in academy (35mm normal) but pan&scanned at preprocessing stage to obtain a "widescreen" image.

In a few words: P&S selects an active part of the image to be displayed, in an non-destructive way. Cropping "destroys" the original, ie it cannot be "uncropped" back to its original state. It is however very common when preparing the sources for distribution that those P&S pointers be used for cropping the material.

The commoners do not have access to P&S beyond the settings in their DVD-player/SAT-receiver/etc, thus they interpreted P&S strictly as converting 16:9 into 4:3, which is only one facet. Also many SW programmers may confuse people in their terminology/options/settings.

PS: some of the best definitions I've found
Pan-Scan information is a set of data that is intended to guide professional video equipment in extracting an image to be presented in an aspect ratio that is different from that in which the material was produced or distributed. Independent parameters are provided for pan (horizontal displacement), tilt (vertical displacement), vertical size, horizontal size and output aspect ratio.
andCrop allows you to select an area of an image and discard everything outside this area

[hello_hello]

Divide your age by ten and you'll obtain your mental age.

You certainly can be childish at times.

The pan and scan process, as defined by people providing the technique and materials to Hollywood (in this case Technicolor) was defined in a public document, so even people relying entirely on google and wikipedia could access it for free to pretend they are smart, 10 years before 16:9 draft and 20 years before the very first 16:9 TV sets. The implementation of P&S is regulated by SMPTE, but I think you're too cheap to buy one of their standards.

Well provide a link to the publicly available document, or quote the part of the SMPTE standard you're not too cheap to buy, otherwise it's all yet another meaningless exercise in rhetoric.

Surprise me with another sophism, how could they use "improperly" the term/process of P&S, at least 10 years before the invention of 16:9..... because no film ever had a DAR of 16:9.

Well you didn't surprise me with another irrelevancy. I originally said the Pan and Scan process is a method of converting widescreen movies to display in a 4:3 format. What's 16:9 got to do with that?

And vice versa, there are movies shot in academy (35mm normal) but pan&scanned at preprocessing stage to obtain a "widescreen" image.

For example?

In a few words: P&S selects an active part of the image to be displayed, in an non-destructive way. Cropping "destroys" the original, ie it cannot be "uncropped" back to its original state. It is however very common when preparing the sources for distribution that those P&S pointers be used for cropping the material.

I don't accept cropping has to be destructive to the original any more than Pan and Scan does. In fact I think it's a ridiculous claim. If I take a video and crop it while converting it to another format, how is that more destructive to the original than pan and scan? The fact you admit cropping is part of the pan and scan process only shows it's just as destructive as cropping alone, if you want to keep arguing ridiculous semantics.
The only way your claim could be true is if every 4:3 pan and scan DVD actually contains the full widescreen image, only the player is instructed on a "window" to display. Obviously that's not the case so there's no "destructive" distinction to be made between pan and scan and simple cropping.

The commoners do not have access to P&S beyond the settings in their DVD-player/SAT-receiver/etc, thus they interpreted P&S strictly as converting 16:9 into 4:3, which is only one facet. Also many SW programmers may confuse people in their terminology/options/settings.

You left out forum posters such as yourself, who make up your own definitions as you go.

PS: some of the best definitions I've found

Without links to show you didn't just write them yourself.

"Crop allows you to select an area of an image and discard everything outside this area"

That's exactly what ffdshow's crop function does, while you claim it's really pan and scan.

"Pan-Scan information is a set of data that is intended to guide professional video equipment in extracting an image to be presented in an aspect ratio that is different from that in which the material was produced or distributed. Independent parameters are provided for pan (horizontal displacement), tilt (vertical displacement), vertical size, horizontal size and output aspect ratio."

Which is everything ffdshow's cropping function doesn't do, yet you claim it's really pan and scan.

[Ghitulescu]

I am totally wrong and the discussion ends here. And this will count for any other topic wherein you start again to comment my statements.

[hello_hello]

No need to be childish.
Look back through the thread. It was you commenting other people's statements on cropping which started the discussion. Nobody else here agreed with you, not just me.