Pause near start of saved selections

[Cantoris]

I have an MP4 (details attached) that I'm trying to save chunks out of (otherwise unedited) using the default profile:
MP4 - Match Source - MP4 - Intelligent

Unfortunately, each resultant MP4's video pauses very briefly within the first few seconds, stutters slgihtly and then continues on. The rest of the video is fine and the audio does not get interrupted or go out sync.
I'm guessing this may be something to do with not cutting on keyframes?

Thanks for any help you can offer. I've just upgraded from v5 to v6.60.10.816 so was rather disappointed to have this happen.

Edited mp4 tested in both MPC and VLC.

 

[jmc]

First off do a "QuickStream Fix" on the MP4 and see if that smooths anything out.
If that does not help you may have a file with errors in it.

 

[Cantoris]

Thanks for your reply.
I ran a QuickFix against the source MP4 and then used the saved file from that as my new source file.
I set Start and End timecodes of a selection, add it, and then save it out and it still does the same. If I play from the same start timecode directly within VideoReDo, there is NO pause.
I've saved out various extracts from different start points and they all behave the same way: The brief pause is within the first second or two and the video is fine there onwards.

 

[Dan203]

It's possible we're not able to match the source stream exactly. If that's the case then the recoded frames for the cut will have slightly different parameters than the rest of the file which can trip up some players and cause a slight pause like you're describing. This is rare, but does happen. Unfortunately the only way to completely fix it for all players would be to do a full recode.

 

[Winnewup]

Hello Cantoris,

I also have sometimes these effects doing cuts (mostly on I-frames). In these rare cases it helps to make the cut in two steps. First with overlapping scenes (e.g. four frames on both sides). Then in the resulting stream you just cut out the overlapping frames (in the example 8 frames). If both of the two runs result in recoding the cut, everything is good and you won't see anything worse.

Regards
Frank

 

[jmc]

There is the "Trim and Copy Source File" Option in Tools.
Don't think there is any recoding going on there but getting exactly the part you want saved off can be very very tricky.

 

[Otter]

It's probably due how your original file is encoded and the way you are cutting it. MP4 is merely the container for the audio and video, not a type of video encoding. Some raw recordings have very large referance areas or too many B frames. VRD is pretty good at letting you cut anywhere you like and it will stitch it all together, but there are limits to what it can cope with. When you cut, VRD can't bridge the gap and stitch the remaining frames seamlessly.

I agree with Winnewup. Edit and encode the problem segments individually to your final parameters - make cuts with lots of frames before and after what you eventually want to keep - this gives VRD plenty of reference frames when recoding the cuts.
Then take the several fully encoded segments, mark out what you don't want from each segment and add them to a JOINER job. Create a file from the job with Fast Recode.
This should handle any references to missing frames causing your freezing.

 

[Dan203]

There is the "Trim and Copy Source File" Option in Tools.
Don't think there is any recoding going on there but getting exactly the part you want saved off can be very very tricky.

This doesn't work for MP4 files. Trim & copy only works for files with continuously repeated headers like TS and PS files. Files like MP4, MKV and WTV all have static headers and the files will be damaged if you attempt to use trim & copy.

 

[Cantoris]

Many thanks for all this info. I've discovered that the files I was creating, though they had a stutter in VLC Player and Media Player Classic, they do play smoothly in Windows Media Player. I suspect I'll probably just have to ensure I do the cuts on a keyframe. I'd prefer a slightly clumsy cut than a re-encode.
Thanks again.

 

[Winnewup]

Hello Cantoris,
this would result in cutting on IDR-frames, because on I-frames you will get the unwanted effect in rare cases. This would probably produce really clumsy cuts.

If I do cuts I always check the result of the cuttings in VLC (very sensitive on small stream-errors like some technical equipment, such as receivers or TVs) and use the detailed method only if there are problems.
The method with overlapping frames described above only re-encodes twice a very small part around the cut. If you do this with high quality you won't see anything worse. The result is really good. But make sure, that frames (near the cutting point) you want to keep in the final stream have been re-encoded in booth steps. I prefer something around 4 frames on both side, this will persuade VRD in most times to re-encode even those frames you want to keep in the second step. The cause of the stuttering or pixelation is in most times the attached part (mostly if I-frame), which sometimes won't be re-encoded if there are to many frames before. But to get a smooth result it is best to re-encode some frames on both sides of the cut.

Regards
Frank

 

[Dan203]

Yeah H.264 can be a bit tricky. Only IDR frames are safe to cut on. It's possible for an I frame to also be safe to cut on, and there is suppose to be a flag so we can tell the difference, but what we've found is that broadcasters set the safe entry point flag on all I frames regardless of whether they're actually safe because it allows their tuners to display a picture sooner even if it's slightly pixelated for a few seconds. So it's not actually possible for us to accurately determine real safe I frames.

By default we use a method of cutting where we seek back 5 seconds and look for an IDR frame. We then recode from that point to the actual cut point to ensure compatibility. If there isn't an IDR frame in that 5 seconds though we fall back to using I frames, and that can potentially cause the issue you're seeing. In v5 we changed this a little bit to refactor the encoding in this situation to match the source better, but it's still not 100%. As I said above there is simply no encoder in existence that has every possible combination of parameters available. So in rare cases we can't match the source exactly and that can trip up some players.