x265 encoding error.

[Selur]

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.

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.

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.

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.

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.

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.

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.

-color_primaries bt2020 -color_trc smpte2084 -colorspace bt709

Mentions bt709 color matrix, bt2020 color primaries and smpte2084 color transfer.

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.

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.

Cu Selur

[murriato]

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.

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.

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.

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.

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.

-color_primaries bt2020 -color_trc smpte2084 -colorspace bt709

Mentions bt709 color matrix, bt2020 color primaries and smpte2084 color transfer.

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."


Greetings and thank you very much as always!

[Selur]

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.

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

for:

"C:\Program Files\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "C:\Users\cebol\Desktop\ENCODES\MapNLQ.avs" -an -sn -vf format=yuv420p10le,crop= 3840:2064:0:48,scale=1920:1032 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -sws_flags spline -f yuv4mpegpipe - | "C:\Program Files\Hybrid\64bit\x265.exe" --input - --fps 24000/1001 --output-depth 10 --y4m --profile main10 --level-idc 5.1 --qg-size 16 --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 4 --me star --subme 7 --limit-modes --max-merge 4 --no-early-skip --rskip 0 --no-open-gop --opt-ref-list-length-pps --min-keyint 23 --bframes 16 --weightb --ref 5 --rc-lookahead 60 --lookahead-slices 0 --crf 16.90 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --ipratio 1.30 --pbratio 1.20 --rd 4 --psy-rd 2.01 --rdoq-level 2 --psy-rdoq 2.01 --aq-mode 3 --no-cutree --vbv-maxrate 160000 --vbv-bufsize 160000 --hrd --vui-hrd-info --deblock=-3:-3 --no-sao --selective-sao 0 --no-mcstf --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --chromaloc 2 --hdr10 --hdr10-opt --sar 1:1 --output "C:\Users\cebol\Desktop\ENCODES\HYBRID\2024-09-17@14_43_08_5610_01.265"

=> seems like there is an unncessary space in the call generation.
I'll look at it after work today, should be easy to fix.

Cu Selur

[Selur]

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.

Cu Selur

[murriato]

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.

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

for:

"C:\Program Files\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "C:\Users\cebol\Desktop\ENCODES\MapNLQ.avs" -an -sn -vf format=yuv420p10le,crop= 3840:2064:0:48,scale=1920:1032 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -sws_flags spline -f yuv4mpegpipe - | "C:\Program Files\Hybrid\64bit\x265.exe" --input - --fps 24000/1001 --output-depth 10 --y4m --profile main10 --level-idc 5.1 --qg-size 16 --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 4 --me star --subme 7 --limit-modes --max-merge 4 --no-early-skip --rskip 0 --no-open-gop --opt-ref-list-length-pps --min-keyint 23 --bframes 16 --weightb --ref 5 --rc-lookahead 60 --lookahead-slices 0 --crf 16.90 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --ipratio 1.30 --pbratio 1.20 --rd 4 --psy-rd 2.01 --rdoq-level 2 --psy-rdoq 2.01 --aq-mode 3 --no-cutree --vbv-maxrate 160000 --vbv-bufsize 160000 --hrd --vui-hrd-info --deblock=-3:-3 --no-sao --selective-sao 0 --no-mcstf --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --chromaloc 2 --hdr10 --hdr10-opt --sar 1:1 --output "C:\Users\cebol\Desktop\ENCODES\HYBRID\2024-09-17@14_43_08_5610_01.265"

=> seems like there is an unncessary space in the call generation.
I'll look at it after work today, should be easy to fix.

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.


Thank you very much again!

[Selur]

Uploaded a new dev version, try whether that helps.

Cu Selur