[BUG] Incorrect range signalling

[r3dfx]

If you have "Config->MKV tagging" and "Config->MKV tagging->VUI->Range" enabled any detection and overwrite setting for luminance is ignored when muxing to mkv with mkvmerge, since you specifically said to signal XY for the mkv container.

No, I specifically avoided using that since I have to remember to check one more tab (in case I want to passthrough original tv luma)

[Selur]

Argh, made a message during the last upload.
=> uploaded a new dev
(going to bed now)

Cu Selur

[r3dfx]

Sorry, I've been busy lately( Will check new build soon. Do you want a default log of opening and processing a file?

[Selur]

That dev is long gone.
Use the latest dev, create a debug output containing:
a. the analysis of the source
b. the job creation
and write a step-by-step of what you are doing.

Cu Selur

[r3dfx]

Ok, will try soon. Btw, is there any way to do chunked encoding without frame detection? For example, I want to encode 3h file with QTGMC in 3 parts (so I don't lose speed)? I tried LosslessCut, but it causes audio desync on standard settings

[Selur]

Btw, is there any way to do chunked encoding without frame detection?

Not in the way it is usually done.
What you is usually done for chunked encoding is:

• detect the GOPs in the source (navigation to key frames is usually fast, and cutting on key frames is lossless)
  
• split the source into chunks (containing xy GOPs)
  
• encode each of these chunk separately
  
• merge chunks
  

(here it is assumed that key frames are mainly where it makes sense, so that a chunk ideally contain a whole scene)
Problems occur if your source has damaged/buggy in the time codes or the contained data.
vfr can be tricky if audio&video are processed at the same time.
If your video is cfr, contains 'proper' (= in meaningful places) key frames, you process audio and video separately and your source is not damaged, there should be no sync issues.

Downside of chunking, especially when using small chunks is that rate control can't be as good and you additionally may end up with 'pumping' effects (= quality jumps between junks).

For example, I want to encode 3h file with QTGMC in 3 parts (so I don't lose speed)?

lose speed? Compared to what? How?

Cu selur

[r3dfx]

Sorry if I'm not clear enough. I have source file with each frame being keyframe and I want to do chunked encoding.
QTGMC's encoding speed drops almost 3 times during encoding of 3h video (from ~280fps at the start to ~70fps at the end). Splitting&recombining files solves that problem, but I want to somehow automate this process

[Selur]

Ahhh,... different 'chunked encoding'.
Hmmm,...
First thought: one could abuse 'my' 'chunked encoding' by giving it a huge minimum chunk size and thus causing the tool to split into X huge chunks and encode them in parallel. (this probably is not supported in most tools, isn't in Hybrid; + the in parallel probably will cause problems)
Second thought: one could probably write some script or tool to do the whole thing. (split, encode, merge)
Third thought: maybe trying to figure out why the frame rate drops would be the better approach.
If you have a cpu with 'performance' and 'efficiency' cores, maybe looking into forcing the load on the performance or disabling the efficiency cores is the solution.
Could also be some network problem if the source, target or temp lies on a network drive.
Might also be a threading / memory handling issue.

Cu Selur

[r3dfx]

I tried LosslessCut, but even with disabled avoid_negative_ts I get some weird audio artifacts (a few ms missing)...
I have 0 idea what happens with QTGMC. I run encoding on Ryzen 7 3700X and cpu usage gradually drops as time passes

[Selur]

What does your script look like? (have you tried changing thread count or memory usage?)
Does the RAM usage stay constant?
Have you tested, that it is the script and not the encoding (leave out the encoding and try just with vspipe/avs2yuv) or handling of the source script?

Cu Selur