strange behaviour when seeking in mkv's.

[liquidskin76]

Hi,

I see a really strange thing when seeking in mkv's that contain h264 vid (original from backed up blu-ray and re-encoded). When seeking, there is pause, then the vid plays in fast forward for a few seconds, then resumes at normal speed. The audio plays fine during this.

At first i thought it was a bug in mpc's matroska splitter however i see the same in the new smm splitter, and to a lesser degree in haali. Happens when using dxva and software decoding. Also, it doesn't seem to matter what vid decoder i use (mpc, ffdshow, or coreavc).

I've done a comparison test using the vc1 original and converted/re-encoded mkv of a blu-ray backup and the vc1 was ok.

It doesn't happen on all seeks, however the seek positions that it happens on (mainly seen on mkv chapters) are consistent.

Any ideas? Could it be a splitter bug? I don't see on m2ts's containing the exact same files. I've had a few other people say they have seen the same.

Thanks

[liquidskin76]

Forgot to say... i've only seen this behaviour on HD vids. SD behaves ok.

[Ghitulescu]

time codes (bad ripping???)

[liquidskin76]

They have been backed up with anydvd hd, then cleaned with tsmuxer. Vid is then re-encoded using ripbot. Then mux the lot to mkv using mkvmerge.

I see the same if i skip the re-encoding.

I suppose i can do a test using makemkv trial and see if i get the same by bypassing tsmuxer, etc.

[Blue_MiSfit]

I see this all the time, and here's how I understand it (take this with a grain of salt as it makes sense to me, but I'm not low level enough to understand what's "really" happening under the hood):

This is normal when using typical 10 second max GOP sizes, in my experience. Basically, you're seeking to a non IDR frame, so the decoder has to start decoding at the previous IDR, and catch up. The audio starts, but you might have to decode up to 10 seconds of video to catch up, plus the time actually spent decoding (while audio is still free-running!!).

Depending on how the player handles it, these decoded frames can be presented very rapidly once a buffer of them accumulates, or it may just discard them, and start displaying frames once it can resume synchronized playback.

If the seek performance bothers you, reduce x264's --keyint parameter. If you bring it down to a second or two you will insert a lot more keyframes. This always fixes it for me, but of course implies a compression penalty since IDR frames are HUGE relative to P and B frames.

Derek

[liquidskin76]

Cheers Derek, will give it a go. Good man!

[liquidskin76]

What the best way to change that setting, bearing in mind I use ripbot and have no experience of avisynth!

Is it poss to change in ripbot?

Thanks

[liquidskin76]

Guess i would just mod the profile within ripbot. Is this correct to add... --keyint 24 --min-keyint 2? Got that from the ripbot thread!

Cheers

[setarip_old]

@liquidskin76

Hi!

Unless I missed it, you haven't said which player(s) you've used (and which you haven't used) that displayed this behavior?

[liquidskin76]

Hey setarip_old,

Any player that i use these splitters with. Like Blue_MiSfit said, i think it's more to do with how i'm encoding the vid.

[liquidskin76]

Just found this... seeking lag... thats the bloody word i've been trying to think of!

GOP Size (Min/Max):

Description: This option sets the minimum and maximum number of frames before a key frame has to be inserted by x264. For example, a minimum setting that is the same as the framerate of the video (eg. 24/25/30) will prevent the encoded video from having two subsequent key frames within a second of each other, which only aims to increase file size without any noticeable quality improvements.

Similarly, a maximum setting ensures that a key frame is inserted at least every X number of frames. A video without key frames will have lower quality and there will be problem with seeking (if you try to skip to a part of the video without a key frame, there won't be any video until the next key frame is reached, also known as "seeking lag"). A recommend setting, as with DivX/XviD encoding, is to set this as 10 times the framerate, which equates to 10 seconds of video between key frames (ensures "seeking lag" is at most 10 seconds).
Command Line: --keyint m --min-keyint n
(where 'm' and 'n' are the max and min GOP size values)

[setarip_old]

Hey setarip_old,
Any player that i use these splitters with. Like Blue_MiSfit said, i think it's more to do with how i'm encoding the vid.Since not all players are created equal, I'll ask you specifically if you've tried:

1) "Splash Lite"

2) "VLC" v.1.1.0

[Blue_MiSfit]

I'm not deeply familiar with Ripbot264, but it should allow you to customize a given profile. Basically, you're correct in assming that you should add --keyint x to your command line, where x is something less than 250 (the default), but probably more than 24 or 48 (assuming 24p here).

Derek

[liquidskin76]

Going on what i've read, does this look ok...?

--keyint 48 --min-keyint 24

--keyint 48 to give a max of 2 seconds lag at most (based on 2x frame rate), and --min-keyint 24 based on frame rate?

Do i need both or just --keyint?

Thanks!

[liquidskin76]

Tested the mkv's in questions with xbmc's default internal player (dvdplayer, not dsplayer), and the behaviour doesn't happen. It's perfect. Guess it's how the internal splitter handles the GOP Size?

[setarip_old]

As I said previously, not all players are created equal...

[liquidskin76]

Ok, so by encoding with --keyint 24, it has pretty much sorted the problem. With --keyint 48 the problem was still slightly visable. The file size it slighty up however i can live with that!

Cheers Derek for your guidance!

[Blue_MiSfit]

Yeah. Don't set --min-keyint!!!! It's fine to adjust --keyint :)

Larger GOPs will improve compression, but reduce seek performance.

Ask yourself "how often will this file need to seek?" and set --keyint accordingly :)