Question concerning 264 & mvc files
Question concerning 264 & mvc files
I was poking around in the files and the norm (>>800 pages ) for some time...
but I was unable to really catch the item in one of the NALs present in the two files which would give away the info which is finally used to determine the "stereo mode" (left eye / right eye first) as it is used in a mkv file...
can somebody give me a hint, please?
thanks!
but I was unable to really catch the item in one of the NALs present in the two files which would give away the info which is finally used to determine the "stereo mode" (left eye / right eye first) as it is used in a mkv file...
can somebody give me a hint, please?
thanks!
Question concerning 264 & mvc files
DGDemux doesn't make any declarations about eye assignments, just demuxes main and dependent streams. Not enough experience here with 3D streams to advise you about conventions for eye assignments. May be better to ask at D9 or VH.
Question concerning 264 & mvc files
ok. No problem
Question concerning 264 & mvc files
Useful info here:
https://forum.makemkv.com/forum/viewtop ... 2&start=15
I will look into parsing the eye assignment and reporting it when opening a disk. If there is a tag in the MKV I can report that as well when opening an MKV.
https://forum.makemkv.com/forum/viewtop ... 2&start=15
I will look into parsing the eye assignment and reporting it when opening a disk. If there is a tag in the MKV I can report that as well when opening an MKV.
Question concerning 264 & mvc files
thank you for the link; indeed interesting info; I think the planes of the subs are covered nicely with the Tag-files;
I have scrolled through the MCV-SEI (and the others) as far I could manage it...
but have not found a clear indication from which data this right/left-issue could be resolved; also MediaInfo in the debug mode gave no hint...
maybe it can only be pulled from the BD itself;
I'm concocting a primitive mkv-wrapper to pack the 264 and mvc files into a mkv for later use with MKVToolnix; to know for sure the right/left would be nice; at the time being I have hardwired "left" (I think most are left; in the cases where this is wrong it can still be manually corrected with MKVToolnix);
if there is no "natural" place for it in one of the NALs then also an extra file (like an empty "right.txt") would be ok...
Thanks
I have scrolled through the MCV-SEI (and the others) as far I could manage it...
but have not found a clear indication from which data this right/left-issue could be resolved; also MediaInfo in the debug mode gave no hint...
maybe it can only be pulled from the BD itself;
I'm concocting a primitive mkv-wrapper to pack the 264 and mvc files into a mkv for later use with MKVToolnix; to know for sure the right/left would be nice; at the time being I have hardwired "left" (I think most are left; in the cases where this is wrong it can still be manually corrected with MKVToolnix);
if there is no "natural" place for it in one of the NALs then also an extra file (like an empty "right.txt") would be ok...
Thanks
Question concerning 264 & mvc files
Originally posted by jdobbs at Doom9 forum:
In the AppInfoPlayList() table of the MPLS file -- look for MVC_Base_view_R_flag. It is a 1 bit flag -- if it is set to 0 then the MVC base view is for the left eye. If it is set to 1 then the base view video stream is for the right eye.
Note: It is bit 4 of the byte located at offset 56 (0x38) of the MPLS file (with offset 0 being the first byte of the file).
OFFSET 0x38: 000X 0000
In the AppInfoPlayList() table of the MPLS file -- look for MVC_Base_view_R_flag. It is a 1 bit flag -- if it is set to 0 then the MVC base view is for the left eye. If it is set to 1 then the base view video stream is for the right eye.
Note: It is bit 4 of the byte located at offset 56 (0x38) of the MPLS file (with offset 0 being the first byte of the file).
OFFSET 0x38: 000X 0000
Question concerning 264 & mvc files
Please re-download 1.0.0.58 and update DGDemux.exe. When you open a 3D disk it will show the eye assignment on the streams list.
Do you need anything else?
Do you need anything else?
Question concerning 264 & mvc files
that looks good, Thanks !
I made a different observation in the context of looking closer into the 3D files..
for example with "the rise of Skywalker" the analysis of the playlist (00800) says 2 m2ts files:
00573.m2ts and 01051.m2ts;
but during ripping (after ~1% ) the tool reports 1042.m2ts and 1051.m2ts and then at the very end 1052.m2ts...
with my mkv wrapper I'm parsing from NAL to NAL (obviously) but this disc tripped the algorithm because around 1,5% progress, it encounters a NAL "0x00 00 01 0A" which I thought marks the end of file...
maybe there is some kind of "spill over" from those unexpected m2ts files causing this problem?
I have implemented a work around for this situation, so not overly critical (I hope).
So, thank you again for the update
I made a different observation in the context of looking closer into the 3D files..
for example with "the rise of Skywalker" the analysis of the playlist (00800) says 2 m2ts files:
00573.m2ts and 01051.m2ts;
but during ripping (after ~1% ) the tool reports 1042.m2ts and 1051.m2ts and then at the very end 1052.m2ts...
with my mkv wrapper I'm parsing from NAL to NAL (obviously) but this disc tripped the algorithm because around 1,5% progress, it encounters a NAL "0x00 00 01 0A" which I thought marks the end of file...
maybe there is some kind of "spill over" from those unexpected m2ts files causing this problem?
I have implemented a work around for this situation, so not overly critical (I hope).
So, thank you again for the update
Question concerning 264 & mvc files
Very interesting. Please provide a link to purchase that same disk.
Question concerning 264 & mvc files
Thank you. For future reference, place links within the url tag (use the link button) otherwise they will not appear.
Question concerning 264 & mvc files
ok;
shall I do it again, or did you manage somehow?
shall I do it again, or did you manage somehow?
Question concerning 264 & mvc files
I edited your post to add the missing url tag.
Question concerning 264 & mvc files
Disk ordered.
Question concerning 264 & mvc files
I tried the US version because the one you linked is 3 times the cost. But this one has different M2TS files than what you showed.
Can you please post a link to the MPLS file from your disk? Also, give your exact DGDemux command lines.
Finally why are your two displays different colors? Looks like you did something different between listing and demuxing.
Can you please post a link to the MPLS file from your disk? Also, give your exact DGDemux command lines.
Finally why are your two displays different colors? Looks like you did something different between listing and demuxing.
Question concerning 264 & mvc files
sorry for the delayed response; I was out of town;
the black background is the output of the cli in cmd.exe during ripping;
the white background is a txt file: I divert the mpls analysis into a file in order to parse it and to create a command line for DGDemux.exe;
I sent you the link via PM; its a zip with the mpls and the analysis txt where I have put in at the very end the complete command line for DGDemux;
the black background is the output of the cli in cmd.exe during ripping;
the white background is a txt file: I divert the mpls analysis into a file in order to parse it and to create a command line for DGDemux.exe;
I sent you the link via PM; its a zip with the mpls and the analysis txt where I have put in at the very end the complete command line for DGDemux;
Question concerning 264 & mvc files
Thank you. I also need the command line for the open MPLS listing.
Question concerning 264 & mvc files
you mean the command line creating the mpls analysis?...
I used:
apps\DGDemux\DGDemux.exe -i "G:\BDMV\PLAYLIST\00800.mpls"
I used:
apps\DGDemux\DGDemux.exe -i "G:\BDMV\PLAYLIST\00800.mpls"
Question concerning 264 & mvc files
Aha, noticed in the MPLS that it is a 3D disk, then I checked your streams listing and yes, it is. That's good because that means there is no problem. The M2TS list shows only the base stream files. When demuxing, however, after each base M2TS in the list it also demuxes the corresponding dependent stream file if enabled for demux. I can differentiate the two when displaying the names during demux.
Question concerning 264 & mvc files
good;
but why is there in the resulting H264 file a "0x00 00 01 0A" after ~1.5% of progress?
or am I wrong and this does not indicate "end of file" ?
but why is there in the resulting H264 file a "0x00 00 01 0A" after ~1.5% of progress?
or am I wrong and this does not indicate "end of file" ?
Question concerning 264 & mvc files
It is end of sequence. I cannot tell you why it is there. DGDecNV ignores them. I don't know what other software does with them.
Question concerning 264 & mvc files
ok, thank you;
I have covered it in my tool, so, I'm good.
I have covered it in my tool, so, I'm good.
Question concerning 264 & mvc files
If you re-download build 58 it will show base versus dependent when displaying the M2TS files being demuxed (for 3D disks).