Hi Selur,
Would it be possible to add MKV metadata/signaling support for crop and display AR?
I have some files with odd aspect ratios (non-1:1 PAR) and overscan that I want to preserve in the original full resolution, 4:3/16:9 capture form but I'd like to store the crop information and set the display aspect ratio for the player to interpret.
I think for the MKV DAR settings, the DisplayUnit parameter needs to be set to 3 & the DisplayWidth & DisplayHeight parameters take the aspect ratio.
Also, on a side note, the MKV transfer characteristic value of "4" seems to correspond to BT.470 System M...which would also be great to note!
Thanks!
Quote:Also, on a side note, the MKV transfer characteristic value of "4" seems to correspond to BT.470 System M...which would also be great to note!
Documentation says:
Quote: The transfer characteristics of the video.
Valid values and their meaning are:
0: reserved, 1: ITU-R BT.709, 2: unspecified, 3: reserved, 4: gamma 2.2 curve, 5: gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: linear, 9: log, 10: log sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 extended color gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1; 18: ARIB STD-B67 (HLG)
see:
https://mkvtoolnix.download/doc/mkvmerge.html
-> Shouldn't SMPTE 170M be BT.470?
Quote:Would it be possible to add MKV metadata/signaling support for crop and display AR?
Looking at the documentation, there is no DAR signaling. (Hybrid does already signal the PAR through '--aspect-ratio-factor'.)
Also not sure which players support the crop signaling. (last I checked only vlc supported it,...)
Quote:I have some files with odd aspect ratios (non-1:1 PAR) and overscan that I want to preserve in the original full resolution, 4:3/16:9 capture form but I'd like to store the crop information and set the display aspect ratio for the player to interpret.
DVD, DV,... all use anamorphic aspect ratios, so it was kind of the norm until internet streaming and Blu-rays (which still use anamorphic for quite a few resolutions).
Assuming the content you have has a proper set PAR (pixel aspect ratio) and is displayed properly before conversion, just setting the crop values should be the enough.
Assuming the content you have has a wrong PAR value and thus is displayer wrongly before conversion, why would you want to keep that wrong value?
-> I'll think about adding support for the crop values.
Cu selur
(18.07.2022, 04:33)Selur Wrote: [ -> ]see: https://mkvtoolnix.download/doc/mkvmerge.html
-> Shouldn't SMPTE 170M be BT.470?
SMPTE 170M is a late standard that doesn't correspond with most pre-1990's recordings, while BT-470(M) is a new name for the old FCC standard that has been used since the 1950's. White points, color coordinates, & gamma curve are surprisingly different... See: Wiki
https://en.wikipedia.org/wiki/RGB_color_spaces , the 470M standard
https://www.itu.int/rec/R-REC-BT.470-6-199811-S/en , and the SMPTE standard (which is part of BT.1700)
https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en
Different versions of Rec. 601 reference different chromaticities, with older ones (pre-1990s) using the FCC system & newer ones defining SMPTE 170M...
This is quite confusing and terrible. I've only really started understanding this the last few weeks myself. It doesn't help that the "Matrix" calls it FCC, "Transfer Matrix" calls it "Gamma 2.2" (which is kind of correct but...ugh), and the "Primaries" are referred to by BT.470M... However, they all are the 4th option in the list, probably for a reason. I wonder if a couple different, unrelated people wrote the documentation.
I'm not even sure if any players internally handle 170M and 470M differently, even though they should. I'd certainly like the information automatically stored in the file for my non-170M recordings...and maybe noting that these selections all are related to (the readily available standard) BT.470 might be most helpful.
Quote:Looking at the documentation, there is no DAR signaling. (Hybrid does already signal the PAR through '--aspect-ratio-factor'.)
Also not sure which players support the crop signaling. (last I checked only vlc supported it,...)
Please search for DisplayUnit here:
https://www.matroska.org/technical/elements.html
MKVToolNix does support it. I've used it a lot. They call it "Video display unit" under the Header editor or the Muliplexer lets you set DAR under the "Video properties tab" (called "Set aspect ratio")
...I haven't found a player that supports it crop signaling yet (I haven't even seen it work with VLC), but, once again, I'd certainly like the information stored in the file if possible...
Quote:DVD, DV,... all use anamorphic aspect ratios, so it was kind of the norm until internet streaming and Blu-rays (which still use anamorphic for quite a few resolutions).
Assuming the content you have has a proper set PAR (pixel aspect ratio) and is displayed properly before conversion, just setting the crop values should be the enough.
Assuming the content you have has a wrong PAR value and thus is displayer wrongly before conversion, why would you want to keep that wrong value?
Two edge cases!
- I work with early HD recordings (pre-1996) which are odd 1920x1035i @ 16:9 or ~1800x1035i @ 5:3. Modern capture equipment captures it all as 1920x1080i with an extended blanking period. It can't be cropped to 1035 since it's not divisible by two/four. Also, real cropping of interlaced content just hasn't been a great experience... It would be great to just crop and force to 16:9 or 5:3 in metadata for archival... It should all work together as a post processing effect assuming a player adds support one day! (Will put some feature requests in ) However, currently, I've been doing this manually when deinterlacing and actually cropping videos for YouTube...which always results in an odd aspect ratio. At that point I go into MKVToolNix and set the appropriate AR and, when uploaded to YT, YT respects the DAR. (Maybe others might exploit it for interesting wide effects?) I understand that this could be done via PAR but... it's less computationally intensive for me, more so for Youtube.
- Similarly, if I want to eliminate overscan/head switch noise on, say, VHS captures, I can still force it to display as 4:3 even with an odd crop. Almost all players respect DAR settings...
Quote:I'm not even sure if any players internally handle 170M and 470M differently
At least I don't know of any player that does.
About the display unit: unless there is an mkvmerge option for it, I won't support it. I'm not starting to add mkvpropedit options.
btw. send you a new link to a dev version which allows to add the mkv cropping tag.
Crop appears to work well! Thanks!
However, I've found that deinterlacing appears to be broken now. When I deinterlace, the resulting output file has a gamma level that is far too high for some reason. I recreated my profile and it didn't make a difference. Disabling deinterlacing results in perfect output. I have not tried deinterlacing since the old April dev version I was using previously so I'm not sure when it was broken.
Here is an input file, profile, and example output:
https://drive.google.com/file/d/1du3hp6v...sp=sharing
Simply load the profile and execute the black screen input file to get a gray output file! Disable deinterlacing to get the expected output.
Create a debug output if you want help.
Posting your profile is nice and all, but a debug output is way more important since the profile will change if I load it on my machine since I have different hardware and software available in Hybrid.
Also your profile uses Video = x264, while the output.mkv is ProRes, so the profile doesn't match the output you shared.
Cu Selur
Seems to be an issue with SourceMatch 2&3.
Your best bet to get this fixed it reporting it over at:
https://github.com/HomeOfVapourSynthEvolution/havsfunc
Only thing that is changed in the QTGMC Hybrid uses is that my mod supports using neo_fft3d.FFT3D instead of fft3dfilter.FFT3DFilter but that change is not the cause of your problem.
So for the time being using YUV422p10 doesn't seem to work properly while using SourceMatch > 1.
Quote:Also, does the mkvmerge function "--aspect-ratio TID:ratio|width/height" set the DAR?
I guess,... (Hybrid does use --aspect-ratio-factor. No clue why using the PAR instead of the DAR is an issue.)
Cu Selur
Hi Selur,
Thanks for your help. You are correct that simply reducing the source match or converting to YUV422p8 results in good output. I can convert to 8-bit in the mean time. Odd how this bug appeared... I'll write a bug report into the GIT, but is this about FFT3DFilter or QTGMC? I don't see references to QTGMC on that page... I could also be blind.
Quote:Quote:
Also, does the mkvmerge function "--aspect-ratio TID:ratio|width/height" set the DAR?
It helps when working with formats without digital resolution equivalents with defined PAR (pre-SMPTE 240M analog HD) or if I want to crop something arbitrary (i.e. head switching noise) and easily want the output video to appear in the same 4:3 or whatever window.