I used eac3to on an mpls file (ripped blu-ray disc) to produce video, audio, and subtitle streams (H264, DTSMA, PGS formats). I then fed these raw files into mkvtoolnix GUI to remux into an MKV file, but also inserted timecodes into the "splitting" field under the "output" tab. My intention was to split in order to cut out the parts of the film I didn't want by simply deleting the relevant MKV files and re-merging the remaining MKVs using mkvtoolnix again.
Unfortunately I've noticed an issue with the resulting final product. At the points in the film where the mkv files were stitched together, the audio continues to play seamlessly but the video will pause for a few seconds before skipping ahead. The video and audio then remain in sync.
Any ideas what could be causing this?
Our website is made possible by displaying online advertisements to our visitors.
Please consider supporting us by disabling your ad blocker or buy a VSO converter software :)
Please consider supporting us by disabling your ad blocker or buy a VSO converter software :)
+ Reply to Thread
Results 1 to 30 of 48
It could be because the Blu-ray uses OpenGOP. Cutting can be problematic at non-IDR-I-frames. Or it is because the cuts are of different lengths (video can only be cut on keyframes). Can't say for sure without samples and knowing the exact procedures.
Many thanks for your reply.
Apologies, I'm quite a novice when it comes to the technical details. My understanding from your post is that your reference to the cuts being of different lengths means that the video and audio streams in a given file after the split are not equal in duration (that the audio is possibly longer than the video in each file), and that a possible explanation is that the timecodes specified for the splits do not correspond to the location of keyframes in the video stream. My understanding is that, when the split files are re-joined, at the split point the video essentially pauses (while the audio continues) until the next keyframe appears and the video then skips to and resumes at this point in the stream. Is this more or less a correct understanding?
However, as far as I'm aware, mkvmerge does not support splitting except at keyframes anyway, so if the timecodes I specified do not actually correspond correctly to keyframes wouldn't mkvtoolnix just ignore these timecodes and split at the closest keyframe instead?
Furthermore, if I try to play each of the individual split files separately before re-joining them they play fine. This includes the first few seconds of each file that is skipped when I try to re-join the ones I want together. If these first few seconds of each file didn't actually start with a keyframe, wouldn't playing them be impossible? I also tried repeating the process of rejoining the separate files but this time leaving out all audio and subtitle streams so that only the single video stream remains. The exact same issue persists however.
Last edited by Odaik; 19th Mar 2017 at 12:36.
The problem is that for mkvmerge a "keyframe" is a frame you can seek to. For H.264 video that is either an IDR frame or an I frame that's a recovery point. This is ok for playing back a complete file but not for editing. So editing using mkvmerge is not safe for these files. How these are played depends on the player. They may appear fine in one player but garbled or with pauses in a different one.
But without a sample I cannot say what the problem is.
Thanks again for the input.
I guess I can read into it a bit more and try and solve the issue myself, maybe after asking a few more specific questions on here. Until today I actually had no idea what I, P, and B frames were.
If I were to just upload a sample, any suggestions on the best method for this? Just a little concerned on the legal side too, as I'd be uploading a significant amount of footage extracted from a (copyrighted) blu-ray title.
In the meantime, can you recommend any programs that will allow me to edit mkv files in the way I wish (without re-encoding) and not encounter these issues?
EDIT: Sorry, posted before refreshing the page there and didn't see your post. Would uploading that footage give you enough information on how the tracks are mastered to determine what the issue could be, or would you also need the split files themselves?
I think I'm slowly getting my head around it all now. Assuming the issue is all down to not cutting in the right place, is there any software out there with a GUI that will allow me to analyse the video stream composition and determine the timecodes for where the IDR frames are?
By the way, am I correct in understanding that a GoP is a group of frames that can all be decoded together entirely without reference to frames outside of the GoP, and that therefore they must start with an IDR type I-frame?
Last edited by jagabo; 20th Mar 2017 at 19:50.
Thanks for the explanation, that clears it up a little for me.
Is there any easy way I can analyse the stream to determine these parameters? I.e whether cuts contain open/closed GOPs, location of IDR frames etc...
OK, so I used a trial of SolveigMM Video Splitter to analyse the video stream and re-attempt the cuts I did with mkvmerge originally.
By using the "Next K Frame" navigation feature, it seems that throughout the film keyframes occur every second or so. So that's 1 in 24 frames that are keyframes (I'm assuming in this case that this is synonymous with IDR type I frames).
Does this sound like a stream encoded with Open GoPs? 1 in 24 doesn't sound like a lot of keyframes.
I did try and cut out the parts I didn't want using this software and it worked fine. So it seems something is going wrong when I attempt to do the same in mkvmerge. I guess one option now is to copy the timecodes for keyframes identified in SolveigMM and use those to split in mkvmerge.
There does seem to be something else going on that SolveigMM is able to address and and that mkvmerge isn't, as you suggested. I tried simply taking the timecodes for the keyframes as found using SolveigMM and using that to split the MKV using mkvmerge, expecting the same seamless results.
Unfortunately I still get the exact same issue. Re-joining the split parts using tsmuxer instead (so exact same except end result is a m2ts container) also has the same problems at the same points in the film.
I would just stick to SolveigMM, except it doesn't seem to recognise my subtitle or audio streams and obviously is also fairly expensive after the evaluation period.
I am still hoping that the issue is simply to do with not cutting at keyframes and that maybe I am feeding the wrong timecodes to mkvmerge. My current process is to simply find the keyframes I want to split the file at (so the first keyframe of the scene I want to cut out and then the first keyframe of the scene right after - idea being everything in between can then be deleted). I then look at the time stamps for these frames. SolveigMM gives this in a HH:MM:SS,NN format; where NN are the two digits of an integer frame number in that second of video (if I've understood correctly). So 01:01:22,06 is the marker of the 6th frame of that second of footage. The way I get the exact timecode for mkvmerge is to take that stamp, copy the HH:MM:SS part, and as mkvmerge requires a decimal timecode (HH:MM:SS.nnnnnnn...) I consider the position of the exact frame as a fraction of a second. So for example the 6th frame in each second begins at ( 5 * (1/23.976) ), and I put this figure (less than 1) after the decimal point in HH:MM:SS.nnnnnn. So the 5th frame each second occurs at HH:MM:SS.208541875...
Does this sound like a correct workflow to achieve what I want, or am I missing something?
You can tamper with mkvmerge's timing as much as you want but it won't solve your problem. Like I explained earlier mkvmerge will only cut on "keyframes" (the next after the specified time so it does not have to be 100% exact, you could even set it a bit before) but there are two kinds of those (IDR and non-IDR). mkvmerge can only cut safely on IDR frames. A good encoder will put those on scene changes and deviate from the strict 1-in-24 pattern for that. A bad encoder would put only a single IDR frame in the entire movie. No luck cutting with mkvmerge, then.
You can use ffprobe (comes with ffmpeg) to see type type (and lots of others properties) of every frame. It displays frames in presentation order so you can differentiate open and closed GOPs by whether the frame before an I frame is a B frame (open GOP) or a P frame (closed GOP). After installing ffmpeg, put this in a batch file:
"G:\Program Files\ffmpeg\bin\ffprobe.exe" -print_format json -show_frames %1 > %1.txt
Many thanks again for the responses guys.
Jagabo that looks extremely useful, will try and get to grips with using ffmpeg more often. I did try to use the command you posted in a batch file (copy paste into text editor; changed directory to location of ffprobe.exe portable on my system; saved as .bat file), but it doesn't seem to do anything. I simply have the .bat file on my desktop, same as the mkv file, and drag the mkv onto the .bat file. Could it be something with the syntax?
The cmd window does flash up for a split second, but no file is written. I checked the task manager, and nothing significant is going on in terms of CPU resources.
Tried again, and managed to get something to happen although in a far less elegant way. I opened ffprobe using a cmd .exe and simply copied that command in, replacing the "%1" before and after the ">" with the mkv file location/name and output file name respectively. The output file (I called it frames.txt) has information but I'm struggling to interpret it.
I've added a -select_streams v:0 command to make the output file only show video stream info, however I can't quite follow the parameters used in the output.
Here is the output format:
Last edited by Odaik; 25th Mar 2017 at 23:04.
That's coded order vs display order. With b frames the frames need to be re-ordered.
Let's say you have in display order this:
I B P
The I frame is intra and doesn't need anything. The P frame uses the I frame to get information. The B frame uses both the I and the P frame to get information. Now to encode or decode the stream it doesn't work in this order. The decoder would decode the I frame first no problem. Then it would try to decode the B frame but that doesn't work because it needs information from the P frame which the decoder doesn't have yet. So the P frame is actually encoded/decoded first and everything gets stored in this coded order:
I P B
OK, I added the pause line and the error coming up is:
The filename, directory name, or volume label syntax is incorrect.
I don't know about "display_picture_number". Maybe that attribute does not apply to this video codec or container. But it doesn't matter. You know the display order because of the order of each element in the file (implicitly) and the pts/timestamps.
Ha, thanks - missed that. It was the missing quotation mark, putting it in fixed the issue. Works fine now. The directory is correct, that's just how the folder was downloaded from the videohelp website.
With regards to the display_picture_number parameter, the reason I need to know is so that I can specify exactly which frame to cut at when using video editors so that I can resolve the issue I started this thread for. For example, mkvmerge asks for frame numbers. Although I can see the display order per se in the text file, I would need an easy way to find out the specific frame number too. The only way I can do it from the text file at the moment is to count the number of paragraphs before the one relating to the frame that I want, so not doable when there are >200000 of them.
ffprobe as a tool to examine your original, cut, and joined videos to determine why you were having problems. For example, consider a 13 frame video with open GOPs (in display order):
Or maybe ffmpeg does something else. I don't know.
If you want to locate I frames you can use ffdshow as the decoder then enable the option to display frame types. I do it using DirectShowSource() in AviSynth, then opening the script with VirtualDub.
You can modify the ffprobe batch file to create a list of frame types using find.exe.
ffprobe.exe -print_format json -show_frames %1 > %1.txt find "pict_type" %1.txt >%1.frametypes.txt
Or you can pipe directly from ffprobe to find.exe:
ffprobe.exe -print_format json -show_frames %1 | find "pict_type" > %1.frametypes.txt