tsMuxer icon indicating copy to clipboard operation
tsMuxer copied to clipboard

return of old bug in BD3D remux

Open cob66 opened this issue 3 years ago • 6 comments

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 :)

cob66 avatar Oct 25 '22 21:10 cob66

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

jcdr428 avatar Oct 26 '22 08:10 jcdr428

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.

cob66 avatar Oct 26 '22 12:10 cob66

@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 ?

jcdr428 avatar Oct 26 '22 13:10 jcdr428

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.

cob66 avatar Oct 26 '22 21:10 cob66

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

jcdr428 avatar Oct 27 '22 06:10 jcdr428

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.

cob66 avatar Oct 27 '22 10:10 cob66

@cob66 can you please test today's release.

jcdr428 avatar Nov 05 '22 08:11 jcdr428

Closing, can be re-opened upon request.

jcdr428 avatar Nov 10 '22 09:11 jcdr428

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

cob66 avatar Nov 11 '22 21:11 cob66

@cob66 can you please test latest release.

jcdr428 avatar Dec 25 '22 14:12 jcdr428

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

cob66 avatar Dec 26 '22 12:12 cob66

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

jcdr428 avatar Dec 26 '22 13:12 jcdr428

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

cob66 avatar Dec 26 '22 20:12 cob66

@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 ?

jcdr428 avatar Dec 27 '22 13:12 jcdr428

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 :)

cob66 avatar Dec 27 '22 16:12 cob66

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.

jcdr428 avatar Dec 27 '22 17:12 jcdr428