Is encoding a video split into scenes/shots CRF = encoding entire video CRF??

[singhkays]

I was wondering how to raise parallelism on a many core system (32+) using x265.

One of the ideas I had if I could split the video into separate shots/scenes and encode individual and then merge them back into the entire file. Would that have the same result quality wise versus encoding the same entire file without splitting.

The x265 parameters/CRF value would be constant between the two scenarios.

Workflow would look something like this

1 input file ===> Split into individual scenes/shots ===> encode all scenes ===> Combine all files

What kind of issues could I run into with this?

[Atak_Snajpera]

In practice CRF is 100% safe in this scenario.
However 2-pass mode requires some adjustments.
BTW. If you are using windows you can use ripbot264 for this task. (Distributed Encoding mode)
http://i.cubeupload.com/e8JoyV.png

[singhkays]

In practice CRF is 100% safe in this scenario.
However 2-pass mode requires some adjustments.
BTW. If you are using windows you can use ripbot264 for this task. (Distributed Encoding mode)
http://i.cubeupload.com/e8JoyV.png

What kind of changes would you make for 2-pass?

I'm aware of Ripbot264. Fantastic tool! The only one I think that can do distributed encoding :) However, I can't use it for my purpose as I want to automate the workflow through a CLI and try scaling to 100s of instances. Btw, what drives the max 16 server limitation in RipBot264?

[benwaggoner]

In practice CRF is 100% safe in this scenario.
However 2-pass mode requires some adjustments.
BTW. If you are using windows you can use ripbot264 for this task. (Distributed Encoding mode)
http://i.cubeupload.com/e8JoyV.png
Well, you do run the risk of VBV issues at the stitch point.

More likely lowered quality at the start of a difficult to encode shot due to default buffer fullness than a VBV overflow.

Systems like CineVision's VC-1 encoder would break up the encode across multiple systems, and then reencode a few seconds around each stitch point to align I-frames with scene changes and smooth out VBV (and thus sudden quality changes).

[MeteorRain]

For desktop playing purpose I don't think that has much difference.
I personally use my own x265 gop patch and combine-mux gops together when completed.
If you are concerned about joint part vbv issue, you can encode a few more frames (bleeding) before and after, and cut them afterwards before joining.

[Atak_Snajpera]

What kind of changes would you make for 2-pass?
I analyze complexity of chunks and then increase/decrease bitrate budget for each chunk
Screenshot from older version
http://i.cubeupload.com/KuwPsh.png

what drives the max 16 server limitation in RipBot264?
Common sense? Why would you need more? According to your test 16 servers + 4k x265 veryslow could utilize even up to 1024 cores! I doubt that typical ripbot264 user has access to super computers with thousands of cores/threads ;)

[singhkays]

I analyze complexity of chunks and then increase/decrease bitrate budget for each chunk
Screenshot from older version
http://i.cubeupload.com/KuwPsh.png

Looks like I misunderstood Distributed Encoding mode. Is there more deatail on how this work i.e. how the work is split amongst different servers? I checked the tool thread but didn't find any detail in the first post https://forum.doom9.org/showthread.php?t=127611

Common sense? Why would you need more? According to your test 16 servers + 4k x265 veryslow could utilize even up to 1024 cores! I doubt that typical ripbot264 user has access to super computers with thousands of cores/threads ;)

Got it, makes sense :)