That post of yours, is trash. It's a pain to read. Too many layers of quotes, which contain only already said data.
You answered inside quotes.
=> please, keep your posts more readable or I will not try to read them.
Quote:That's very interesting. So if I just manually set the option here as Rec.2020ncl it would be all correct?
Yes, that should work.
Quote:I tried to test the Auto crop option to see if it now works with avs scripts, but I can't use it.
The option appears disabled and you can't interact with it. And this happens all the time, both with avs scripts and MKV files.
It's disabled since you enabled 'Crop/Resize->Misc->On Source Change->Auto Crop' which disables the controls and only triggers the crop detection on a source change. If you enable it after a source already has been loaded, it only disables the controls.
Quote:And also the avs script works correctly without the need to read dependencies, as it was always the case in older versions.
This was due to a bug which I re-introduced, this might change in the future, so I would recommend to not rely on it.
Quote:There is one strange thing though:
As I told you days ago, when I open in Hybrid an avs script that has already inside a resize to 1080 then Hybrid reported that it cannot find color matrix and then it assumes it is bt709 since the video size is larger than 720*576.
Yes, Hybrid does always try to guess the color matrix based on the resolution, if the source does contain the necessary info.
Quote:And now obviously the same thing is still happening, but the strange thing is that even though this happens (Hybrid assumes the color as bt709) if I make an encode and then open it in MediaInfo it turns out that the encode is bt2020 anyway.
That is, it doesn't matter if Hybrid assumes that the matrix color is bt709 or bt2020ncl, because anyway it always generates a resulting encode that is 2020.
Is this normal?
That depends on your setting, if you tell Hybrid to flag the content as bt2020 it will even if the content it has is bt709.
Quote:It should be noted that there is a strange thing that keeps happening as I explained in previous messages, and I do not understand why.
And that is that I have checked the text of the logs after doing encodes and it still continues to appear many times the text "709" by numerous places, despite the fact that I am encoding 2020.
Is this a bit strange? Or is it normal and nothing to worry about?
Tagging the content is independent of the processing of the content.
Mentions bt709 color matrix, bt2020 color primaries and smpte2084 color transfer.
Quote:I attach several debug outputs of some encode tests, in which you can search and find many "709":
- HybridDebugOutput - MKV (4K): Encode of a 4K MKV (the input is a normal mkv, not an avs script).
- HybridDebugOutput - avs script (4K): Encode of an avs script (the original 4K is kept, without resizing to 1080)
- HybridDebugOutput - avs script (4K resize to 1080): Encode of an avs script (resize to 1080 within the avs script itself)
Okay, not sure what to do with that. Since I'm unsure what you want to know about them.
Quote:By the way, when I encode in this version of Hybrid the result ends up with 2 files (.265 and .mkv) instead of only .mkv as it has always happened to me.
I guess it's because this option is disabled as well as the Auto crop option. And I have always chosen MKV in this option but now I can't choose anything, and I guess this is the cause of this problem, but I don't know.
No clue why this happens. Deinstall Hybrid, delete your settings, install latest dev, try if it still happens with that version.
If it does write a step-by-step on how to reproduce the problem and I can try to look into it.
No clue, why the 'Default container' combo box is empty on your screenshot, can't reproduce that here.
(17.09.2024, 03:56)Selur Wrote: That post of yours, is trash. It's a pain to read. Too many layers of quotes, which contain only already said data.
You answered inside quotes.
=> please, keep your posts more readable or I will not try to read them.
Thank you very much again Mr. Selur.
And sorry, you are right, my message is a bit confusing with so much text and so many quotes. Sorry for that!
I will try to do it in a cleaner way and I will try not to respond inside quotes.
(17.09.2024, 03:56)Selur Wrote:
Quote:By the way, when I encode in this version of Hybrid the result ends up with 2 files (.265 and .mkv) instead of only .mkv as it has always happened to me.
I guess it's because this option is disabled as well as the Auto crop option. And I have always chosen MKV in this option but now I can't choose anything, and I guess this is the cause of this problem, but I don't know.
No clue why this happens. Deinstall Hybrid, delete your settings, install latest dev, try if it still happens with that version.
If it does write a step-by-step on how to reproduce the problem and I can try to look into it.
No clue, why the 'Default container' combo box is empty on your screenshot, can't reproduce that here.
I have done what you indicated (reinstall and clean) and now it works correctly.
I guess when I installed it days ago something was installed wrong or it was missing configuration files or something strange happened, I don't know.
(17.09.2024, 03:56)Selur Wrote:
Quote:I tried to test the Auto crop option to see if it now works with avs scripts, but I can't use it.
The option appears disabled and you can't interact with it. And this happens all the time, both with avs scripts and MKV files.
It's disabled since you enabled 'Crop/Resize->Misc->On Source Change->Auto Crop' which disables the controls and only triggers the crop detection on a source change. If you enable it after a source already has been loaded, it only disables the controls.
I did not know that this option existed.
Actually I did not enable that option, it would have been enabled by default when installing Hybrid. I suppose it has something to do with the previous point, that is to say that Hybrid must not have been installed correctly.
In the new current installation this option is no longer enabled by default and the Auto crop option no longer appears disabled and I can activate it without problems.
I have tested with Auto crop and I will tell you my results:
The option works perfect, I press the button and it detects well the amount of pixels to crop.
But there is a problem:
If you then try to encode (I mean with the Crop set) it gives error during the encoding process.
Although it should be noted that if the input is an MKV it works fine and does not give error, but if the input is an avs script it gives error.
And the content of the avs script is indifferent and that is not a problem, simply if it is an avs script the encoding process always fails.
I also want to say that obviously I have tried to make those same encodes but unchecking the picture crop option and it works perfectly and does not give any error. It only fails if the crop option is activated.
I attach a debug output in case it is useful to you.
(17.09.2024, 03:56)Selur Wrote:
Quote:And now obviously the same thing is still happening, but the strange thing is that even though this happens (Hybrid assumes the color as bt709) if I make an encode and then open it in MediaInfo it turns out that the encode is bt2020 anyway.
That is, it doesn't matter if Hybrid assumes that the matrix color is bt709 or bt2020ncl, because anyway it always generates a resulting encode that is 2020.
Is this normal?
That depends on your setting, if you tell Hybrid to flag the content as bt2020 it will even if the content it has is bt709.
Yes, it makes sense and I suppose that this behavior is the correct one.
But I wanted to comment it because I was surprised because in previous versions of Hybrid this did not happen, in this same situation the previous versions of Hybrid generated me encodes with Matrix coefficients BT.709.
And now Hybrid generates the encodes correctly as Matrix coefficients BT.2020 non-constant, even though Hybrid has assumed the color as bt709 (since the video size is larger than 720*57).
Previously this did not happen and in that situation Hybrid generated encodes with Matrix coefficients BT.709.
(17.09.2024, 03:56)Selur Wrote:
Quote:It should be noted that there is a strange thing that keeps happening as I explained in previous messages, and I do not understand why.
And that is that I have checked the text of the logs after doing encodes and it still continues to appear many times the text "709" by numerous places, despite the fact that I am encoding 2020.
Is this a bit strange? Or is it normal and nothing to worry about?
Tagging the content is independent of the processing of the content.
Mentions bt709 color matrix, bt2020 color primaries and smpte2084 color transfer.
Quote:I attach several debug outputs of some encode tests, in which you can search and find many "709":
- HybridDebugOutput - MKV (4K): Encode of a 4K MKV (the input is a normal mkv, not an avs script).
- HybridDebugOutput - avs script (4K): Encode of an avs script (the original 4K is kept, without resizing to 1080)
- HybridDebugOutput - avs script (4K resize to 1080): Encode of an avs script (resize to 1080 within the avs script itself)
Okay, not sure what to do with that. Since I'm unsure what you want to know about them.
Yes, that is precisely what I am referring to.
According to the log it seems that the video input is always being read as bt709 instead of being read as bt2020nc/bt2020_ncl (although then the output is correctly written as bt2020ncl). This I think always happens with mkv input or avs script input.
Wouldn't it be better and more appropriate for the ffmpeg command to be -colorspace bt2020nc/bt2020_ncl instead of -colorspace bt709?
I say this because I am concerned that this might cause what I explained to you in previous messages:
"But I'm worried because reading this text fragment in the log I get the feeling (or at least that's what my logic says) that the source is being read as 709 instead of 2020 (although the output is correctly written as 2020)... and in case this is really happening then it will be forming a kind of funnel/bottleneck causing a part of the color spectrum to be lost, since 2020 encompasses a wider breadth and range of colors than 709."
Quote: Wouldn't it be better and more appropriate for the ffmpeg command to be -colorspace bt2020nc/bt2020_ncl instead of -colorspace bt709?
Yes, if you upscale, it would be better to also use a color matrix conversion to bt2020.
Quote:And now Hybrid generates the encodes correctly as Matrix coefficients BT.2020 non-constant, even though Hybrid has assumed the color as bt709 (since the video size is larger than 720*57).
Previously this did not happen and in that situation Hybrid generated encodes with Matrix coefficients BT.709.
If no color matrix is given, Hybrid uses:
if (m_currentWidth[variable] > 1920 || m_currentHeight[variable] > 1080) {
if (VsFilter::m_videoFormat == QString("ULH0")) {
sendMessage(HDEBUGSYNTH, QString("Unknown color matrix '%1' -> using '709', since input format is UHLH0").arg(inMatrix));
return QString("709");
}
return QString("2020ncl");
}
if (m_currentWidth[variable] > 720 || m_currentHeight[variable] > 576) {
sendMessage(HDEBUGSYNTH, QString("Unknown color matrix '%1' -> using '709'").arg(inMatrix));
return QString("709");
}
sendMessage(HDEBUGSYNTH, QString("Unknown color matrix '%1' -> using '470bg'").arg(inMatrix));
return QString("470bg");
to guess an input color matrix, which in my eyes seems correct.
------------
About the crash, the debug out complains about:
Error initializing the muxer for 3840:2064:0:48,scale=1920:1032: Invalid argument
Error opening output files: Invalid argument
Couldn't reproduce the problem here that Hybrid adds a space after the 'crop='.
I adjusted the code a bit to:
a. add some additional debug output where I suspect this .
b. do an additional check where the crop part is computed.
=> please try the latest dev and if it still fails, share another debug output.
Quote: Wouldn't it be better and more appropriate for the ffmpeg command to be -colorspace bt2020nc/bt2020_ncl instead of -colorspace bt709?
Yes, if you upscale, it would be better to also use a color matrix conversion to bt2020.
Yes, I think so too. That's why I wanted to try not to let that happen.
And do you know why the ffmpeg command contains bt709? How could I solve it?
It's just that checking the debug logs the ffmpeg command always contains bt709. Even if Hybrid detects the input as 2020 then in the encoding debug log you see the ffmpeg commands with bt709. And even if I use a 2160p MKV input instead of an avs script, the same thing happens. I don't know what to do.
(18.09.2024, 05:21)Selur Wrote: About the crash, the debug out complains about:
Error initializing the muxer for 3840:2064:0:48,scale=1920:1032: Invalid argument
Error opening output files: Invalid argument
=> seems like there is an unncessary space in the call generation.
I'll look at it after work today, should be easy to fix.
(18.09.2024, 18:08)Selur Wrote: Couldn't reproduce the problem here that Hybrid adds a space after the 'crop='.
I adjusted the code a bit to:
a. add some additional debug output where I suspect this .
b. do an additional check where the crop part is computed.
=> please try the latest dev and if it still fails, share another debug output.
I have tried the new dev version and I still get the same problem.
I attach a debug output.
(19.09.2024, 05:25)Selur Wrote: Uploaded a new dev version, try whether that helps.
Cu Selur
Hello again Mr. Selur, sorry for the delay I've been a little busy.
I confirm that the encoding with Auto crop is now working correctly, both with MKV sources and avs scripts.
Thank you very much for your efforts!
I would like to comment again what I wrote the previous days, since the same thing is still happening and I don't know if it is my problem or Hybrid's problem or Hybrid's configuration problem or what.
I mean this:
(19.09.2024, 01:29)murriato Wrote:
(18.09.2024, 05:21)Selur Wrote:
(18.09.2024, 01:48)murriato Wrote:
(17.09.2024, 03:56)Selur Wrote:
(16.09.2024, 23:50)murriato Wrote: It should be noted that there is a strange thing that keeps happening as I explained in previous messages, and I do not understand why.
And that is that I have checked the text of the logs after doing encodes and it still continues to appear many times the text "709" by numerous places, despite the fact that I am encoding 2020.
Is this a bit strange? Or is it normal and nothing to worry about?
Mentions bt709 color matrix, bt2020 color primaries and smpte2084 color transfer.
Yes, that is precisely what I am referring to.
According to the log it seems that the video input is always being read as bt709 instead of being read as bt2020nc/bt2020_ncl (although then the output is correctly written as bt2020ncl). This I think always happens with mkv input or avs script input.
Wouldn't it be better and more appropriate for the ffmpeg command to be -colorspace bt2020nc/bt2020_ncl instead of -colorspace bt709?
I say this because I am concerned that this might cause what I explained to you in previous messages:
"But I'm worried because reading this text fragment in the log I get the feeling (or at least that's what my logic says) that the source is being read as 709 instead of 2020 (although the output is correctly written as 2020)... and in case this is really happening then it will be forming a kind of funnel/bottleneck causing a part of the color spectrum to be lost, since 2020 encompasses a wider breadth and range of colors than 709."
Yes, if you upscale, it would be better to also use a color matrix conversion to bt2020.
Yes, I think so too. That's why I wanted to try not to let that happen.
And do you know why the ffmpeg command contains bt709? How could I solve it?
It's just that checking the debug logs the ffmpeg command always contains bt709. Even if Hybrid detects the input as 2020 then in the encoding debug log you see the ffmpeg commands with bt709. And even if I use a 2160p MKV input instead of an avs script, the same thing happens. I don't know what to do.
In my previous messages I already attached several debug outputs about this, but well I have now made again some new debug outputs with the latest dev version although it happens exactly the same as before.
But now I wanted to try to do it using the options you told me (I didn't know before that those options existed), I mean the options to force the input color, this: "Filtering->Misc->Overwrite input".
I have activated these 2 options:
- Overwrite input luminance: tv
- Overwrite input color matrix: rec.2020ncl
But even if I activate these options, exactly the same thing still happens.
In the logs it appears on numerous occasions that the video input is always being read/decoded/etc as bt709 instead of being read as bt2020nc/bt2020_ncl (although then the output is correctly written as bt2020ncl). And this happens all the time, and no matter what the source is, it happens with both mkv and avs scripts.
I attach 2 debug outputs, one is made with a MKV 4K HDR input and the other with an avs script also 4K HDR.
And as I said before, this time they are made with the 2 "Overwrite input" options activated, but in previous occasions I did it without them and the same thing happened.
In the logs you will find references to 709 on many occasions.
-color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv
has no influence on the output, since y4m does not support it, so no reason to worry.
Ok, thank you very much.
Although you quoted me only avs script, so there is no reason to worry only in avs script and in MKV there is reason to worry? Or in MKV input there is also no reason to worry?
I was concerned because days ago I asked about this and you gave me the reason and told me that yes it would be more advisable and appropriate and better to use bt2020. So that is why I was still concerned. Perhaps we misunderstood each other.
But anyway I guess there is no way for the user to change this, as Hybrid always makes the calls to ffmpeg with bt709 no matter what input video you use or what settings you use.
So I guess there is simply nothing I can do and no way to change it.