Doom9's Forum - View Single Post - eac3to

mkver · 18th October 2018, 09:32

@arrgh: The only way to store Dolby Vision data in Matroska is if it is embedded in the video stream and is copied with the video stream into the Matroska file by the muxer. (I don't know how Dolby Vision is stored in the video stream if it is stored in the video stream so I don't know if the Dolby data looks like invalid/garbage data and is therefore likely filtered out by muxers.) Even if the data ends up in the file, no indication of this would be stored at the container level, there is no header element saying "This track contains Dolby Vision data". I don't think that this can be meaningfully extracted as a separate track (if it is shown as a separate track, then it is likely not stored in the video stream, so it has its own PID and one could "extract the track by using a PID filter).
@Justnobody:
1. Your samples are not very informative. You should have given us files before you remuxed them so that we can analyze its sync. (This wouldn't work with the iTunes file because if Dulus_No
2. That the "delay" value changes when you extract a part of a file is (as sneaker_ger already said) a result of audio and video frames having different durations. Here is an easy example: You have an AC-3 track (duration of a each audio frame: 32ms) and a PAL 25p video (duration of each frame 40ms). If both audio and video start at 0:00 (and don't have any gaps) and there is a keyframe at 1s and you cut everything before 1s away, then your new file will have a delay of 24ms: The first video frame that will be kept was at 1s and is now at 0:00, the first audio frame that will be kept was at 1024ms and is now at 24ms.
This effect also implies that if you want to upload remuxed files and not the original files for us to analyze, you should upload the beginning of the file, not something in the midle (checking with a subtitle for the movie this scene is at 28:26 (if the subtitles and your movie have the same fps)).
3. But one can nevertheless say something meaningful about your second sample. NTSC DVDs were designed to work with old analog 6/1.001 i TVs and so they had to output 60/1.001 i, but this doesn't mean that they had to use this format internally. One can store 24/1.001p material as progressive on a NTSC DVD by using repeat-field-flags. The typical way to do this is by using a 2:3 pulldown: One frame will be the basis for two fields and therefore shown 2/(60/1.001)s (about 33ms) long, the next frame will be the basis for three fields and therefore shown 3/(60/1.001) s long. Of course, the natural framerate for such material is 24/1.001fps and that's how modern equipment will play it.
Your second sample "beginning sample Ibitsu [720x480][H264][AAC] (1) (1).mkv" before extraction and remuxing is actually 24/1.001p although the default duration in the header says 30/1.001fps. Here is my guess to what happened: You remuxed this file and the remuxing tool just used the frame rate info the bitstream signalled (one should keep in mind that this is not wrong -- the "default duration" is not intended to be the reciprocal of the frame rate) and wrote 30/1.001fps into the Matroska header. But lateron you used a tool to reencode it to H.264 that is smart in the sense that it noticed that this is just a cfr movie that has been subjected to a 2:3 pulldown and that therefore created 24/1.001p output pictures, but unfortunately it still wrote 30/1.001 fps in the Matroska header and it gave the bitstream a timebase of 60/1.001 (but didn't set the fixed_frame_rate_flag). When mkvmerge remuxd the video elemetary stream, the only timing information the bitstream contained suggested 30/1.001fps and that is how mkvmerge remuxed it. The result is totally out of sync and there is no video for the last few seconds of audio. The asynchronity in this case has nothing to do ith an initial audio delay, instead it is a result of mismatched framerates and as such gets gradually worse.
4. Actually, the VOB/Program Stream demultiplexer and the MPEG-2 module of mkvmerge have some bugs, but the developer of mkvmerge considers MPEG-2 obsolete and doesn't want to spend time on this. One should not really use mkvmerge to remux DVDs, use MakeMKV instead (it can also parse the ifo files so that one gets the correct DVD color palette and the chapters).

18th October 2018, 09:32	#14718 \| Link
mkver Registered User Join Date: May 2016 Posts: 197	@arrgh: The only way to store Dolby Vision data in Matroska is if it is embedded in the video stream and is copied with the video stream into the Matroska file by the muxer. (I don't know how Dolby Vision is stored in the video stream if it is stored in the video stream so I don't know if the Dolby data looks like invalid/garbage data and is therefore likely filtered out by muxers.) Even if the data ends up in the file, no indication of this would be stored at the container level, there is no header element saying "This track contains Dolby Vision data". I don't think that this can be meaningfully extracted as a separate track (if it is shown as a separate track, then it is likely not stored in the video stream, so it has its own PID and one could "extract the track by using a PID filter). @Justnobody: 1. Your samples are not very informative. You should have given us files before you remuxed them so that we can analyze its sync. (This wouldn't work with the iTunes file because if Dulus_No 2. That the "delay" value changes when you extract a part of a file is (as sneaker_ger already said) a result of audio and video frames having different durations. Here is an easy example: You have an AC-3 track (duration of a each audio frame: 32ms) and a PAL 25p video (duration of each frame 40ms). If both audio and video start at 0:00 (and don't have any gaps) and there is a keyframe at 1s and you cut everything before 1s away, then your new file will have a delay of 24ms: The first video frame that will be kept was at 1s and is now at 0:00, the first audio frame that will be kept was at 1024ms and is now at 24ms. This effect also implies that if you want to upload remuxed files and not the original files for us to analyze, you should upload the beginning of the file, not something in the midle (checking with a subtitle for the movie this scene is at 28:26 (if the subtitles and your movie have the same fps)). 3. But one can nevertheless say something meaningful about your second sample. NTSC DVDs were designed to work with old analog 6/1.001 i TVs and so they had to output 60/1.001 i, but this doesn't mean that they had to use this format internally. One can store 24/1.001p material as progressive on a NTSC DVD by using repeat-field-flags. The typical way to do this is by using a 2:3 pulldown: One frame will be the basis for two fields and therefore shown 2/(60/1.001)s (about 33ms) long, the next frame will be the basis for three fields and therefore shown 3/(60/1.001) s long. Of course, the natural framerate for such material is 24/1.001fps and that's how modern equipment will play it. Your second sample "beginning sample Ibitsu [720x480][H264][AAC] (1) (1).mkv" before extraction and remuxing is actually 24/1.001p although the default duration in the header says 30/1.001fps. Here is my guess to what happened: You remuxed this file and the remuxing tool just used the frame rate info the bitstream signalled (one should keep in mind that this is not wrong -- the "default duration" is not intended to be the reciprocal of the frame rate) and wrote 30/1.001fps into the Matroska header. But lateron you used a tool to reencode it to H.264 that is smart in the sense that it noticed that this is just a cfr movie that has been subjected to a 2:3 pulldown and that therefore created 24/1.001p output pictures, but unfortunately it still wrote 30/1.001 fps in the Matroska header and it gave the bitstream a timebase of 60/1.001 (but didn't set the fixed_frame_rate_flag). When mkvmerge remuxd the video elemetary stream, the only timing information the bitstream contained suggested 30/1.001fps and that is how mkvmerge remuxed it. The result is totally out of sync and there is no video for the last few seconds of audio. The asynchronity in this case has nothing to do ith an initial audio delay, instead it is a result of mismatched framerates and as such gets gradually worse. 4. Actually, the VOB/Program Stream demultiplexer and the MPEG-2 module of mkvmerge have some bugs, but the developer of mkvmerge considers MPEG-2 obsolete and doesn't want to spend time on this. One should not really use mkvmerge to remux DVDs, use MakeMKV instead (it can also parse the ifo files so that one gets the correct DVD color palette and the chapters).