return of old bug in BD3D remux

[cob66]

The old remux 3D bug is back. After remux 3D BD structure, the movie plays in 4K (2D) instead of BD3D (2K). Months ago it was very similar - the bug was only in Win64bit (32 was ok). As usual, I checked build from 2022-09-25- everything is fine here :)

[jcdr428]

@cob66 there has been no change to AVC muxing lately. Can you please test 2022-10-18 release ?

[cob66]

I noticed that the "bug" is not repeatable, so maybe it's not software fault, but chinoppo or projector (jvc) fault. Remuxes on other versions are correct, and the one I reported happens once in several runs. I haven't found a rule. A similar issue #573 was noticed not only by me and repeated on different hardware.

[jcdr428]

@cob66 can you please do a byte for byte compare of the two muxes (09-25 and last release) and report if there is any difference ?

[cob66]

I think I already know everything;) There is no difference between 25-09 and 24-10 ... both generate the same issue- 3D playback in 2D (2160p) format. The bug occurs when 2 input files are muxed. I used 2 mpls from different BD structures to make a custom BD. Interestingly, remuxing (with any tsmuxer version) this bad "3D/2D" structure gives the correct 3D structure, which resulted in my earlier - wrong assumption that only the last tsmuxer made a bug.

[jcdr428]

@cob66 so is this a bug that needs resolution, or is this an error resulting from the way the output is created?

[cob66]

For me (but I'm not a specialist) this is a minor glitch due to the output data format. After all, re-remux solves the problem. The display (projector) probably does not get a mark (3d?) and recognizes the data, as is the default output set in my oppo, i.e. 4K.

[jcdr428]

@cob66 can you please test today's release.

[jcdr428]

Closing, can be re-opened upon request.

[cob66]

Sorry, I was on vacation :) I tested on Nightly build from 2022-11-09. Unfortunately, the error still exists :(

[jcdr428]

@cob66 can you please test latest release.

[cob66]

Unfortunately, the issue remains. I muxed in 2 variants: "Insert SEI..." and "Do not change SEI..."

[jcdr428]

@cob66 can you please share the muxed (faulty) 3D before the second remuxing, and the final 3D after the second remuxing ?

[cob66]

https://www.mediafire.com/file/1jp9e3n7qj7r2f6/1_mux_%252812-25_relase%2529.iso/file

https://www.mediafire.com/file/ikin6hdzgfe419v/2_mux_%2528remux_of_1_mux%2529.iso/file

[jcdr428]

@cob66 ok so the first mux is incorrectly muxed in Blu-ray V3 format. I guess the problem is corrected by unchecking the "Force BD-ROM V3 format" in the Blu-ray tab before muxing. The V3 is automatically selected when tsMuxer detects a HEVC or >1080p video stream. Is it the case with any of the two used input BDs ?

[cob66]

Yes, the second mpls file is from UHD BD but all video tracks have been removed. Unchecking the "Force BD-ROM V3 format" is the solution. Thank you :)

[jcdr428]

Ok then, closing. Edit for the record: tsMuxer assumes that when sources come from V3 Blu-ray, the output should also be V3. If this is not the intended behavior, the user can manually select V2. It could be improved by tsMuxerGUI checking whether there are still HEVC or >1080p video streams every time a stream is unchecked.