This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Feature request: new mkv tags
#1
Hello Selur,

   It could be useful, to add the possibility to include in a mkv container the script used by Hybrid (if any) to generate the movie.
   x265 is already doing this, are missing the parameters used by other encoders (like nvenc) and the script.
   What do you think ?  

Dan
Reply
#2
x264 and x265 (optional) write their encoding settings into the SEI infos of the video stream, other encoder do not.
Under which tag (see: https://www.matroska.org/technical/tagging.html) should these be added?
(ENCODER_SETTINGS ?)

Cu Selur

Ps.: Going to bed now, but I'll think about it.
PPs.: no clue who tools like mediainfo will show this tag isn't just a one-liner, i.e. contains a script.
Reply
#3
Hybrid is already able to produce a report of all the encoding process (including the script): Config->Internals->Create report file.
It should be enough to add the option to add it as attachment in the mkv container.

Optionally (if it is not too complex).
It could be useful to fill the tags:

ENCODER [UTF-8] : The software used to encode the video
ENCODER_SETTINGS [UTF-8] : A list of the settings used for encoding the video (could be just the list of parameter passed to encoder)

Thanks,
Dan
Reply
#4
ENCODER would always be Hybrid.
And like I wrote the ENCODER_SETTINGS might just be output in a single long string by tools like mediainfo,..
Small test, showed as expected:
Encoding settings                        : VAPOURRSYNTH SCRIPT USED: / # Imports / import vapoursynth as vs / # getting Vapoursynth core / import sys / import os / core = vs.core / # Import scripts folder / scriptPath = 'f:/Hybrid/64bit/vsscripts' / sys.path.insert(0, os.path.abspath(scriptPath)) / # loading plugins / core.std.LoadPlugin(path="f:/Hybrid/64bit/vsfilters/Support/fmtconv.dll") / core.std.LoadPlugin(path="f:/Hybrid/64bit/vsfilters/MiscFilter/MiscFilters/MiscFilters.dll") / core.std.LoadPlugin(path="f:/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/LSMASHSource.dll") / # Import scripts / import validate / # Source: 'D:\PProjects\colormnet\tests\thing2.mp4' / # Current color space: YUV420P8, bit depth: 8, resolution: 384x280, frame rate: 25fps, scanorder: progressive, yuv luminance scale: limited, matrix: 709, format: AVC / # Loading D:\PProjects\colormnet\tests\thing2.mp4 using LWLibavSource / clip = core.lsmas.LWLibavSource(source="thing2.mp4", format="YUV420P8", stream_index=0, cache=0, fpsnum=25, prefer_hw=0) / frame = clip.get_frame(0) / # setting color matrix to 709. / clip = core.std.SetFrameProps(clip, _Matrix=vs.MATRIX_BT709) / # setting color transfer (vs.TRANSFER_BT601), if it is not set. / if validate.transferIsInvalid(clip): /   clip = core.std.SetFrameProps(clip=clip, _Transfer=vs.TRANSFER_BT601) / # setting color primaries info (to vs.PRIMARIES_BT470_BG), if it is not set. / if validate.primariesIsInvalid(clip): /   clip = core.std.SetFrameProps(clip=clip, _Primaries=vs.PRIMARIES_BT470_BG) / # setting color range to TV (limited) range. / clip = core.std.SetFrameProps(clip=clip, _ColorRange=vs.RANGE_LIMITED) / # making sure frame rate is set to 25fps / clip = core.std.AssumeFPS(clip=clip, fpsnum=25, fpsden=1) / # making sure the detected scan type is set (detected: progressive) / clip = core.std.SetFrameProps(clip=clip, _FieldBased=vs.FIELD_PROGRESSIVE) # progressive / # changing range from limited to full range for vsDeOldify / clip = core.resize.Bicubic(clip, range_in_s="limited", range_s="full") / # setting color range to PC (full) range. / clip = core.std.SetFrameProps(clip=clip, _ColorRange=vs.RANGE_FULL) / # adjusting color space from YUV420P8 to RGB24 for vsDeOldify / clip = core.resize.Bicubic(clip=clip, format=vs.RGB24, matrix_in_s="709", range_s="full") / # adding colors using DeOldify / from vsdeoldify import HAVC_deepex / clip = HAVC_deepex(clip=clip, method=4, ref_merge=0, dark=True, smooth=False, max_memory_frames=8, /
   sc_framedir="ref", ex_model=0, encode_mode=1) / # changing range from full to limited range for vsDeOldify / clip = core.resize.Bicubic(clip, range_in_s="full", range_s="limited") / # no resizing since resolution is already archived / # adjusting output color from: RGB24 to YUV420P10 for x265Model / clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10, matrix_s="709", range_s="limited") / # set output frame rate to 25fps (progressive) / clip = core.std.AssumeFPS(clip=clip, fpsnum=25, fpsden=1) / # output / clip.set_output()
So may be adding a tag might not be the best choice.
Quote:Optionally (if it is not too complex).
Not really complex, just not really usable int the output.

Quote:It should be enough to add the option to add it as attachment in the mkv container.
Adding the report to the mkv as an attachment is probably easy.
--attachment-description "Hybrids report file" \
  --attachment-mime-typetext/plain \
  --attach-file "PATH to reportfile"

n8

Cu Selur
Reply
#5
I understood, I do agree that adding the report file as attachment it is the best option.

Thanks,
Dan
Reply
#6
Okay, this is more complicated than I would have thought, since I didn't think about what this would require.
Message processing is separated from job processing and all the other stuff.
So DebugOutput and Report creation are independent of job processing.
(Both can be turned off and on during job processing, without influencing the job processing.)
Adding the report isn't possible without major changes, which would break 'separation of concern' in the code, which I will not do.
(Hybrid's internal logic and dependencies are complicated/bad enough as they are; ~250k lines of code.)

So Hybrid would need to create a separate file before the muxing call, which includes all the wanted data and that could be added to the muxing call.
But have you ever checked how normal media players handle unknown mkv text attachments?
And how do you plan to look at the attachment?
The only thing that pops into my mind would be to extract the file with mkvextract and then look at it, but then simply using the report file as a separate file is probably more convenient.

=> atm. keeping the normal report file seems to be the most sensible solution.

Cu Selur
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)