VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors.
Please consider supporting us by disabling your ad blocker or buy PlayOn (record Netflix) :)
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 45
Thread
  1. Hello

    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?

    Thanks

    Odai.
    Quote Quote  
  2. 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.
    Quote Quote  
  3. 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.
    Quote Quote  
  4. 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.
    Quote Quote  
  5. 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.
    Quote Quote  
  6. Just cut about 30 to 60 seconds from the beginning of the first m2ts using e.g. DGSplit or TSMuxer.
    Quote Quote  
  7. 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?
    Quote Quote  
  8. Good question. I actually don't know. Usually, you'd find the IDR frames and only cut at those, at least for the GOPs you want to keep (beginning of a segment). Otherwise try mp4box or SolveigMM Video Splitter.
    Quote Quote  
  9. 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?
    Quote Quote  
  10. Originally Posted by Odaik View Post
    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...?
    What you are describing is a "closed GOP". As was mentioned earlier there are also "open GOPs" that require frames of the next GOP to decode the last few frames of the GOP.
    Last edited by jagabo; 20th Mar 2017 at 19:50.
    Quote Quote  
  11. 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...
    Quote Quote  
  12. l-smash muxer and mp4box will show number of IDR vs "just" I frames during mux. That should give a strong hint about how source was encoded. Other than that you need some kind of stream analyzer like Zond.
    Quote Quote  
  13. 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.
    Quote Quote  
  14. Originally Posted by Odaik View Post
    Does this sound like a stream encoded with Open GoPs? 1 in 24 doesn't sound like a lot of keyframes.
    1 in 24 is quite a bit and common on Blu-ray due to its specifications. For example x264 uses 1 in 250 by default.

    Originally Posted by Odaik View Post
    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.
    SolveigMM Video Splitter has smart re-encoding. You may find it working on cuts mkvmerge does not.
    Quote Quote  
  15. 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?
    Quote Quote  
  16. 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.
    Quote Quote  
  17. 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:

    Code:
    "G:\Program Files\ffmpeg\bin\ffprobe.exe" -print_format json -show_frames %1 > %1.txt
    Change the path to ffprobe to reflect where it is on your system. You can then drag/drop any file onto the batch file and it will generate a log of all the frames. The log filename will be the same as the video filename except ".txt" is added to the end. So "video.mkv" becomes "video.mkv.txt". If you use this on your source video, the split videos, and the re-joined video you should be able to tell if any frames are missing or duplicated.
    Quote Quote  
  18. 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.
    Quote Quote  
  19. 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:

    "media_type": "video",
    "stream_index": 3,
    "key_frame": 0,
    "pkt_pts": 83,
    "pkt_pts_time": "0.083000",
    "pkt_dts": 83,
    "pkt_dts_time": "0.083000",
    "best_effort_timestamp": 83,
    "best_effort_timestamp_time": "0.083000",
    "pkt_duration": 41,
    "pkt_duration_time": "0.041000",
    "pkt_pos": "30801",
    "pkt_size": "147",
    "width": 1920,
    "height": 1080,
    "pix_fmt": "yuv420p",
    "sample_aspect_ratio": "1:1",
    "pict_type": "P",
    "coded_picture_number": 1,
    "display_picture_number": 0,
    "interlaced_frame": 0,
    "top_field_first": 0,
    "repeat_pict": 0
    Out of those, I'm struggling to understand the ones beginning with "pkt" and "best effort". "best_effort_timestamp_time" seems to correlate to time stamp of that particular frame, but there's one thing puzzling me. It seems to contradict "coded_picture_number" (which I understand to be the frame number) - "coded_picture_number" 1 has a bigger (later) timestamp than "coded_picture_number" 2. How can the third frame of the video have an earlier time stamp than the second one?
    Last edited by Odaik; 25th Mar 2017 at 23:04.
    Quote Quote  
  20. 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
    Quote Quote  
  21. Originally Posted by Odaik View Post
    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.
    Add a second line to the batch file with "pause". That will prevent the CMD window from closing until you press a key. You'll then be able to read any error messages.

    Code:
    "G:\Program Files\ffmpeg\bin\ffprobe.exe" -print_format json -show_frames %1 > %1.txt
    pause
    Quote Quote  
  22. OK, I added the pause line and the error coming up is:

    The filename, directory name, or volume label syntax is incorrect.
    .bat file reads:

    C:\Users\Odai\Desktop\ffmpeg-3.2.4-win64-static\ffmpeg-3.2.4-win64-static\bin\ffprobe.exe" -print_format json -show_frames %1 > C:\Users\Odai\Desktop\frames.txt
    pause
    Sneaker, thanks for that explanation. I can now understand why there is sometimes a difference between the two, but in that case why does the text file produced show a frame "display_picture_number" of 0 for every single frame? The "coded_picture_number" steadily increments up to 202431 (202432 frames in the film, I'm assuming it therefore starts counting at 0), but the display number parameter stays at 0 all the way through the text file. Shouldn't it increment by 1 for each "paragraph" of frame properties in the text file, all the way from 0 to 202431?
    Quote Quote  
  23. Originally Posted by Odaik View Post
    OK, I added the pause line and the error coming up is:

    The filename, directory name, or volume label syntax is incorrect.
    .bat file reads:

    C:\Users\Odai\Desktop\ffmpeg-3.2.4-win64-static\ffmpeg-3.2.4-win64-static\bin\ffprobe.exe" -print_format json -show_frames %1 > C:\Users\Odai\Desktop\frames.txt
    pause
    Are you sure that path name is correct? "ffmpeg-3.2.4-win64-static" appears twice.
    Quote Quote  
  24. 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.
    Quote Quote  
  25. You also have a quotation mark after ffprobe.exe at the end of first path name but not one at the beginning.
    Quote Quote  
  26. Originally Posted by davejavu View Post
    You also have a quotation mark after ffprobe.exe at the end of first path name but not one at the beginning.
    You're right. I missed that.
    Quote Quote  
  27. 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.
    Quote Quote  
  28. Originally Posted by Odaik View Post
    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
    I suggested using 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):

    Code:
    IBBPBBIBBPBBI
    In order to cut that into two pieces that are both fully playable both pieces have to include the middle I frame:

    Code:
    IBBPBBI IBBPBBI
    If you join those two videos the middle I frame is repeated, giving 14 frames:

    Code:
    IBBPBBIIBBPBBI
    Or maybe ffmpeg doesn't even try to retain the last two B frames of the first GOP (because, in coded order, they appear after the second I frame. So maybe it cuts as:

    Code:
    IBBP IBBPBBI
    which leaves two frames missing when you join them.

    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.
    Quote Quote  
  29. Originally Posted by Odaik View Post
    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.
    You could either cut down the paragraphs to single lines using regex or look at e.g. "best_effort_timestamp_time": "0.083000". Timestamp is a multiple of 1000ms / (video fps). So if you divide it you get the frame number.
    Quote Quote  
  30. You can modify the ffprobe batch file to create a list of frame types using find.exe.
    Code:
    ffprobe.exe -print_format json -show_frames %1 > %1.txt
    find "pict_type" %1.txt >%1.frametypes.txt
    That will produce a list of frame types -- one line per frame. You can use the line number of the text file quickly calculate the frame number (frame number = line number - 3). Or just delete the first 3 lines and (frame number = line number).

    Or you can pipe directly from ffprobe to find.exe:
    Code:
    ffprobe.exe -print_format json -show_frames %1 | find "pict_type" > %1.frametypes.txt
    to get just a list of frame types.
    Quote Quote  



Similar Threads