Crash

[Selur]

yes.
i assume the x264 problem is fixed to.

[ToiletDuck]

yes.
i assume the x264 problem is fixed to.

I thought i have wrote that   , yes x264 is solved.

About the other thing i have wrote you about..  So, it seems hybrid does use and cut the exact piece i have selected to encode instead of converting the whole media file by chapter selection.

BUT, i didn't let hybrid complete because , the realtime info i received from hybrid implied that it wos doing the entire mediafile you know   !!  While the output file wos exactly what it is supposed to be you know!?

Some one else did created a thread and posted about that misinformation before.  Like hybrid reporting past the 100% notifications for certain tasks..  yep, exactly that kind of misinformation iam talking about !
Like by judging, the filesize, time untill completion etc.. are wrong and seemed like hybrid wos/is doing the entire media file .. while infact it's encoding the selected range..

So , now i know better   ..

Ta TA

[Selur]

No clue what 'other thing' you are referring to.
No time trying to guess what those sentences from you could mean.
Going to bed now.
n8

Cu Selur

[ToiletDuck]

No clue what 'other thing' you are referring to.
No time trying to guess what those sentences from you could mean.
Going to bed now.
n8

Cu Selur

Simply put.  Hybrid is lying through his binary teeth  L L  

My majesty, when i start the task/job in hybrid ..  It tells me it needs the filesize of that of THAT exact same entire media file *Hint Hint 1 / STrike 1*
It tells me the wrong completion time *Hint Hint → STRIKE 2*  And so and on and on..

does diz broad duck (° ^ °') makes sense to you now , my benevolent royal majesty KING SELUR ?

My king .. MY king , a horse for thou king (°^ °') !

Epic Edit: Apparantly...  the x264 issue still persists   !  

Now it doesn't crash at the 1st pass (like right away), but crashes at the 2nd pass instead ¯\_(ツ)_/¯
Fun fact (have tested this), apparantly timecode settings + Bluray hardware restricted settings in x264 combo = crash !

When turning of Bluray strict settings, and using my own custom settings everything works hunky-dory again ^^


Epic Edit n°2

So i double checked, and redid the media file using another x264 profile (ultrafast), the same thing happends using strict bluray settings in x264 + all time code settings.
Why do i mentioning this bit of info ↑?

Because, using a media file with SD content, no matter what settings i use, hybrid doesn't crash !

So something is afoot using 1080p content + the mentioned settings that leads to the dreadful CRAHS Bandicoots   

So in a nutshel = RECAP :

a. using all timecode settings in x264 -minus strict bluray settings results in a succesfull encode = V check
b. using all timecode settings in x264 +plus strict bluray settings is a no go show = X Fail
c. enable "force input to be handled as constant framerate" and leave "input time codes" unchecked + Strict bluray settings = V YaY   
d. last but not least, using any of the above combo settings for SD content alway's completes the task using the good lad hybrid     
 
Note: remember, all tests are done with a 2-pass (fast 1st pass) method in hybrid.

I guess i have posted a "wee bit" of feedback to puth ur teeth in , have fun 

ta Ta

[Selur]

My majesty, when i start the task/job in hybrid .. It tells me it needs the filesize of that of THAT exact same entire media file

Since no debug output is included: What is the exact error message?

It tells me the wrong completion time *Hint Hint → STRIKE 2* And so and on and on..

not really helpful

Fun fact (have tested this), apparantly timecode settings + Bluray hardware restricted settings in x264 combo = crash !

Wild guess: might be that the output frame rate x264 chooses is not compatible with blu-ray restrictions.
Or the option in itself is not supported for blu-ray restrictions in x264.

When turning of Bluray strict settings, and using my own custom settings everything works hunky-dory again ^^

Sadly, without knowing what 'using my own custom settings' entails that does not help at all.

So i double checked, and redid the media file using another x264 profile (ultrafast), the same thing happends using strict bluray settings in x264 + all time code settings.
Why do i mentioning this bit of info ↑?

Because, using a media file with SD content, no matter what settings i use, hybrid doesn't crash !

So something is afoot using 1080p content + the mentioned settings that leads to the dreadful CRAHS Bandicoot

Sounds like with the other settings you are running into level/profile restrictions or similar.

Since I don't have a debug output of the problem I got no clue what x264 might be complaining about.
Since the Blu-ray standard is rather strict Hybrid tries to verify the settings.
Since you fed x264 with time codes and told it to create cfr content, but x264 does not support requesting a specific frame rate when time codes are fed as input there is no way for Hybrid to verify most of the restrictions.
So it's up to the user to verify the restrictions.
From the looks of it, my guess is that the profile&level and blu-ray restrictions are in conflict with the settings x264 ends up with when input time codes are used.

=> don't see how I can help

In case that, you:
a. can re-create the issue with a small sample.
b. can share such a small sample
c. share a detailed step-by-step guide on how to reproduce the problem
I could try to look at the problem when I return from work this evening or tomorrow evening after work.


Cu Selur

[ToiletDuck]

Since no debug output is included: What is the exact error message?


not really helpful

No errors, nor have i found anything suspicious in debug that would explain that behaviour  ¯\_(ツ)_/¯
Also, if i do a chapter selection of prox 2 min, and hybrid tells me it will complete in 1 hour on a Ryzen x5900 / 4070ti system !  That pretty much at least tells you that the estimates are epic wrong, how does that not help you in the slightest bit ?


But if you insist, i want to create and post a debug (again), because i have adressed this before !
 

So i double checked, and redid the media file using another x264 profile (ultrafast), the same thing happends using strict bluray settings in x264 + all time code settings.
Why do i mentioning this bit of info ↑?

Because, using a media file with SD content, no matter what settings i use, hybrid doesn't crash !

So something is afoot using 1080p content + the mentioned settings that leads to the dreadful CRAHS Bandicoot

Sounds like with the other settings you are running into level/profile restrictions or similar.

Since I don't have a debug output of the problem I got no clue what x264 might be complaining about.
Since the Blu-ray standard is rather strict Hybrid tries to verify the settings.
Since you fed x264 with time codes and told it to create cfr content, but x264 does not support requesting a specific frame rate when time codes are fed as input there is no way for Hybrid to verify most of the restrictions.
So it's up to the user to verify the restrictions.
From the looks of it, my guess is that the profile&level and blu-ray restrictions are in conflict with the settings x264 ends up with when input time codes are used.

=> don't see how I can help

In case that, you:
a. can re-create the issue with a small sample.
b. can share such a small sample
c. share a detailed step-by-step guide on how to reproduce the problem
I could try to look at the problem when I return from work this evening or tomorrow evening after work.


Cu Selur

In both cases the SD & FHD content were created using solely the x264 presets (nothing customized by myself!), yet SD succeeded whereas HD didn't !
So, how is it that the very same settings works for SD but not for FHD   

Yes, with the timecode settings enabled, because there lies the catch as well !

Iam refering to the same enabled BD strict settings + one of the x264 encode profiles/presets .

No, i have noticed that something is going wrong in the 2nd pass of the encode, every encode (hd content) fails at the 2nd pass !

i have attached a sample for my KING    .. and ONLY for thou Royal Majesty 

AGAIn, i do WANT to EMphasize that the Crash only occur when doing an 2-pass encode, for some reason 1-pass or 2-pass - 1st pass / 2nd pass setting succeeds !?


Ta TA

[Selur]

Frame rate                               : 23.976 (24000/1001) FPS
Original frame rate                      : 47.952 (48000/1001) FPS

Container indicates 23.976 and stream indicates 47.952.
Wouldn't the right approach be to ignore all time coes and simply encode the stream as 23.976 (24000/1001) fps ?

Will look at it some more tomorrow after work, to groggy today.

Cu Selur

[ToiletDuck]

Frame rate                               : 23.976 (24000/1001) FPS
Original frame rate                      : 47.952 (48000/1001) FPS

Container indicates 23.976 and stream indicates 47.952.
Wouldn't the right approach be to ignore all time coes and simply encode the stream as 23.976 (24000/1001) fps ?

You are right, just double checked that.. it reports as 47.952 ..

fps differs from original Fps  , what does that even means, how is that possible  ?

Duplicated frames, wrong meta, → timing codes , or better yet a error during a decode / encode process ?

Anyway, once i recode the file with the "timecode input box unchecked in x264 settings", i get a solid & valid media file .. just have checked and compared the output file with the original.

[Selur]

Mediainfo reports the frame rate flag of the container as "Frame rate".
Mediainfo reports the frame rate flag of the input as "Original frame rate". (this is only mentioned if container and stream frame rate indication differs)
Your example happens if one for example captures the video at 48000/1001 fps and then muxes the video into a container while specifying 24000/1001 as frame rate.
In Hybrid, one can tell Hybrid whether it should prefer the stream or the container flag through "Config->Internals->Prefer Original".

Trying to reproduce your problem:

• I started Hybrid
  
• enabled 'Config->Automation->On Load->Always extract time codes from input'
  
• change x264->Base->General Settings->Bitrate to 10000 to be sure the file would be > 1MB
  
• enabled "x264->Restriction Setting->Hardware' and set ot to 'Blu-ray/AVCHD'
  
• enabled "x264->Misc->Timecodes->From input'
  
• enabled "x264->Misc->Timecodes->Force input to be handled as constatn frame rate'
  
• loaded your source (test2.mkv)
  
• set an output file
  
• started the job creation.
  This created 2 video calls:
  
  ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "C:\Users\Selur\Desktop\test2.mkv" -map 0:0 -an -sn -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv  -pix_fmt yuv420p -vsync 0 -f rawvideo - | x264 --preset veryfast --pass 1 --bitrate 10000 --profile high --level 4.1 --bluray-compat --keyint 48 --min-keyint 1 --b-pyramid strict --direct auto --b-adapt 0 --sync-lookahead 48 --qcomp 0.50 --rc-lookahead 24 --qpmax 51 --mvrange 511 --aq-mode 0 --nal-hrd vbr --sar 1:1 --non-deterministic --range tv --stats "J:\tmp\2024-04-02@18_53_22_4010\test2_new_new_1_2024-04-02@18_53_22_4010_02.stats" --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --tcfile-in "J:\tmp\2024-04-02@18_53_22_4010\timecodeV2_2024-04-02@18_53_22_4010.tc" --output-depth 8 --output NUL -
  and
  
  ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "C:\Users\Selur\Desktop\test2.mkv" -map 0:0 -an -sn -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv  -pix_fmt yuv420p -vsync 0 -f rawvideo - | x264 --preset veryfast --pass 2 --bitrate 10000 --profile high --level 4.1 --bluray-compat --ref 3 --keyint 48 --min-keyint 1 --b-pyramid strict --direct auto --b-adapt 0 --sync-lookahead 48 --qcomp 0.50 --rc-lookahead 24 --qpmax 51 --partitions i4x4,p8x8,b8x8 --no-fast-pskip --mvrange 511 --subme 5 --aq-mode 0 --vbv-maxrate 40000 --vbv-bufsize 30000 --nal-hrd vbr --sar 1:1 --non-deterministic --range tv --colormatrix bt709 --stats "J:\tmp\2024-04-02@18_53_22_4010\test2_new_new_1_2024-04-02@18_53_22_4010_02.stats" --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --tcfile-in INPUTTIMECODES --output-depth 8 --output "J:\tmp\2024-04-02@18_53_22_4010\2024-04-02@18_53_22_4010_03.264" -

=> problem is tha the INPUTTIMECODES were not replaced in the second call which is why it fails.
like I wrote I'll try to look into it further, but I doubt using tcfile-in is the correct way to handle this source.


Cu Selur

[Selur]

did a quick fix (untested), send you a link for testing