Crash

[ToiletDuck]

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

Yes, i just have thought of that too..  The fps that is determined by the container differs from the fps of that of the video track ..  that's what you basically are saying right ?   
odd.. Usually a container automatically takes over the fps from the video track , right ?  Unless, you overwrite that and use custom container settings.. But in general, that ↑ should'nt happen..

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

i see ... 

Oh well, iam in no hurry..  A recode has pretty much solved it..  When i took the recoded file, and tried to recoded it again using the same restricted settings whit which it initially failed / crashed before, now succeeds and completes .  No more crashes..

So yeah, something is off about the source file regarding the video track.


Ta TA

---

Update:

The fps from the video track indeed had an odd framerate of 47 ish fps .. 

That is easily solved by doing a remux of the original source file and adjust the fps to match, instead of a recode.  
after doing that , i had no crashes anymore in hybrid.

A hybrid fix wasn't necessary perse , but i welcome it anyway 

Both methods do work on old and new revision of hybrid 


Ta Ta

[Selur]

So no more crashes with this, correct?

Cu Selur

[ToiletDuck]

So no more crashes with this, correct?

Cu Selur

Hybrid is in the clear now, so yes .. crashes .. NO MORE  

Crop feature however 🤔... 😏


Ta Ta

[Selur]

You ignore half of what I write, so don't expect me to spend time on it.
n8

[ToiletDuck]

You ignore half of what I write, so don't expect me to spend time on it.
n8

i never would ignore  My king 🫅

It's just that half of the time you don't make sense to me , as iam not making any sense to you most probebly .. and therefor are talking past each other.. ¯\_(ツ)_/¯
... But, for the other "half "of the time we do actually make progress and have a little bit more understanding☝️ 😄👌  

Think about the many many MANY fixes that are noted in the release logs of hybrid by now thanks to your humble servant Toilet-🐥
 


Taa..