1920x1088 in mkv/mp4

[Vincent Vega]

what is the correct/recommended way to remux a 1920x1088 (h264/vc-1/mpeg2) BD stream into mkv/mp4? do i need to use like "format specific options" for video in mmg, like aspect ratio/cropping? for example
- specify cropping of 8 pixels, for the remaining 1920x1080 to be displayed 16:9; in this case which side to crop?
- or without cropping, explicitly specify 1920x1088 aspect setting). //Edit

or maybe there is really no need for any of this and any decoder will automatically detect/take care of it?


Thanks

[CarlEdman]

Are you positive that your content actually is 1088 pixels tall? I've never seen anything like that on blu-ray or broadcast HD content. Perhaps the stream was encoded by someone who took the x264 dimensions must be mod16 MUCH TOO SERIOUSLY and just added 8 pixels of black space on top or bottom. That is a silly and harmful thing to do. Ideally content is mod16, but the efficiency impact of using mod8 or mod4 dimensional content is, in my experience, much, much smaller than adding an extra sharp black edge to the content.

In fact, a lot of nominally 1080p content actually is only 1072 pixels (which is mod16) tall with a black edge on top or bottom. In that case, you should just crop that black edge off. In fact, even if the black edge does not turn out to be enough to get you to mod16, I'd still crop it off before encoding with x264.

To see what your content is like, have a look at it in a tool like dgindex and see what the various cropping settings would take off. Alternatively, you can use avisynth filters like autocrop (which is actually highly reliable if you tell it to use enough sample points which is fairly cheap performance-wise) or experiment with manual cropping using the crop filter.

[Ghitulescu]

1088 is the default format for HD broadcasting :)

[CarlEdman]

I'm surprised, but thanks for the info!

Whenever I pull one of my HD shows off my TiVo, it will only be 1080 nominal (and usually 1072 actual) pixels high, but all of those shows are cable (Verizon FIOS). Maybe things are different in broadcast than on cable.

Of course, if your show really has 1088 pixels of actual content (rather than an 8 or 16 pixel black band), by all means encode in that.

[Vincent Vega]

for all of my m2ts files dgindexnv reports: 1920x1088+"stream specifies cropping", mediainfo just says 1920x1080. i suppose both are correct, only mediainfo reports the final result (after the intended 8 px deduction).

so i just want to understand whether i need to worry about potential aspect ratio issues during playback of such streams in mkv/mp4. for example coreavc has a setting for this "crop 1088 to 1080", ok good, but what about other decoders/players (DS and non-DS), or hardware players?. are there any container-level settings that will guarantee correct handling of 1920x1088 by any player?

[CarlEdman]

Vincent,

such a stream I would just think of as a 1920x1080 stream with a 1:1 SAR. Junk which is supposed to be cropped anyway, I'd not bother reencoding. But I'll bow to the superior knowledge of Ghitulescu as regards broadcast streams.

[Vincent Vega]

Thanks, though i never meant a possibility of actual reencoding here, i am simply remuxing a BD stream from m2ts to mkv/mp4. the cropping mentioned above is only a setting in mkv header to be read/used by decoding chain (see File->Header editor in mmg).

so no reencoding, i just want to figure out optimal muxing settings.

[Ghitulescu]

Of course, if your show really has 1088 pixels of actual content (rather than an 8 or 16 pixel black band), by all means encode in that.

The last 8 lines are anyway black and automatically cropped when transferred through HDMI, as people know this issue. I mean actually, this is how is this supposed to work :) I don't know for US/Japan.

[CarlEdman]

In that case, I would not worry overmuch. Just check that the final mp4/mkv identifies the correct 1920x1080 of actual image information, rather than get confused and somehow switch to 1088. But even in the worst case, that would throw off the SAR by less than 1% which is not noticeable to most (almost all?) people. A more annoying artifact would be the display of junk information in that extra 8 pixel margin, but that should be immediately noticeable. So I'd recommend just using the mkv/mp4 tool set as you ordinarily would and ask again if the final output shows any defects.

[Vincent Vega]

thanks guys, i get all that

though i would also like to hear from sw/hw player developers, what kind of behavior to expect if i throw a 1920x1088 stream at them and it is NOT in (native) m2ts, but in mkv/mp4 and container does not specify anything else. i can think of various things like:
-one smart player will crop the 8 px and display 1920x1080 covering the full 16:9 screen (best case);
-another player might not crop, though still preserve the 1920x1088 aspect, so in full screen it'll be like 1906x1080 with two thin paddings on the sides (i dont like this option already)
-yet another player, some even buggier, might want, dont know, to just "fix" aspect and stretch 1920x1088 to 16:9 (thats what i dread the most, ratio gets distorted)

so i am just looking for wise muxing settings to avoid all such uncertainty

[Ghitulescu]

I put directly 1088i streams from HD SAT on a BDR (with tsmuxer) and it played in all the players I've tested IIRC.

[Vincent Vega]

i mean surely it'll play anyways, the only difference might be just the barely noticeable flaws like possibilities i just mentioned. though to me such things still matter, i wouldnt want any of that to be affecting my files

[CarlEdman]

Fair enough. I wish I could give you more specific advice, but I do all my archiving in mp4 rather than using mkv(*), so my advice on mkv setting would be less helpful than that of many other members of this forum could offer.

(*) It's a decision made a long time ago which works fairly well with the right tools and awareness of their idiosyncrasies, but one I would have to think long and hard about if I were making it from scratch now.
MKV pluses: +Open format independent of Apple's inscrutable whims +Decent, less buggy tool set +Slightly better support for some features.
MP4 pluses: +Better Windows/Mac compatibility +Perhaps, slightly better hardware player compatibility +Compatibility with iTunes/iDevices (this is a big one for me--I can just plain copy/stream my movies to my iPhone/iPad without transcoding or remuxing)

[Vincent Vega]

right, though this question is just as much about mp4 as mkv, or any other container geared toward hd.. basically i could just rephrase topic again: if i am putting a 1920x1088 standard BD resolution stream into any other container apart from m2ts, do i need to take any additional steps to "explain" to playback how to handle it correctly, or no such action is required during muxing because all decoders know how to present such streams.

i really hope someone will clarify this once and for all.

[sneaker_ger]

You don't have to take care of any cropping on the container level (i.e. for mkvmerge or mp4box) for Blu-Ray sources as the H.264 bitstream already contains this cropping information and H.264 players must (and do in practice) respect that.

[Vincent Vega]

ok thanks man, thats h.264.

i also have 1920x1088 vc-1, mpeg-2 blu rays, is cropping info also already embedded in the video streams/subsequently used by decoders?

[sneaker_ger]

Yes, also in those two.