Quote:
Originally Posted by cartman0208
In the alternate output with intact video there's no such issues ... does that mean the metadata only fits to the original P, B and I-Frame sequence (or at least I-Frame interval)?
I guess, it's pretty hard to synchronize that in a reencode  |
It should be by scene, and a scene should always start with an i-frame. So my belief is that the sequence within that GOP (P & B frames) shouldn't matter.
In order to make sure the metadata matches the original i-frame positioning, BD-RB grabs the frame numbers of all i-frames in the original and uses them to force i-frames at the same position in the reencode (in the .CHP file).
That takes place for sure when creating a new BD structure. It's possible that I may be losing that when doing ALTERNATE output. It may be affected by the ability to create much longer GOP sequences in ALTERNATE files. For example, in a BD there is a limit as to how long a GOP can be (typically it's every 24 frames for a film source). But in ALTERNATE output you often (very often) see it expanded to 240 frames. That might play havoc with positioning of the metadata (just speculating)
The actual placement of the metadata in the newly encoded stream is done by X265 or NVENCC using a JSON file that was created from the original source.
This is all speculation until I look at the code and do some testing. I'll take a look and see what I can find. Unfortunately I'm no expert on HDR10+ and/or exactly how JSON files are applied. BD-RB uses 3rd party software to create the JSON and X265/NVENCC to apply it.
The downside is that the reason most people use GOP lengths of 240 is for encoding efficiency. If you have to keep the original i-frame positions, that goes out the window. Generally an encoder senses scene changes and inserts an i-frame when it changes -- that makes it even more complex. I believe the .CHP file overrides that, since it explicitly forces i-frames at certain points.
[Edit] Oh, and by the way, the --multipass option does seem to give better SSIM values in all the other modes. It's just in QUALITY mode that I saw that anomaly.
[Edit - again] I just scanned a JSON file, and there seems to be an entry in the file for every frame in the source. That would seem to imply that the scene change information would be kept correctly even if I didn't use the .CHP to force i-frames. Any experts out there want to chime in?