Media players lag when skipping

Dgameman1 · 2016-10-29 00:27:23

Hey guys! I'm using Arch Linux 64 bit.

I've tried this on VLC and Mplayer and MPlayer-gnome

The video file I'm running is a .mkv

The videos loads up and plays perfectly fine, but the second I skip anywhere in the video player, the sound and video freeze for a few seconds, and then the audio starts playing but the video is all pixelated gray.

Any idea on how to fix this?

mpan · 2016-10-29 02:01:50

There is nothing to fix there, this is the expected behaviour. Alternative would be disabling audio and video output completely until the next video frame is found — I doubt you want that.

Dgameman1 · 2016-10-29 07:53:11

mpan wrote:

There is nothing to fix there, this is the expected behaviour. Alternative would be disabling audio and video output completely until the next video frame is found — I doubt you want that.

Uhh, how is that expected behavior?

I mean it's definitely not supposed to be doing that.

And a google search shows it doesn't happen as often as you make it seem like it does.

Also, I don't recall it happening on other distros I was using. It doesn't happen in Windows either

V1del · 2016-10-29 08:44:29

It depends on the video codec, hardware acceleration might cause the same effect. What is the video codec in use? Have you tried with/without hardware decoding? Which output module do you use? VLC has that issue with VDPAU output here using GLX instead works.

seth · 2016-10-29 14:52:41

Most important question is whether that affects *every* video or only some (one).
You describe an issue to find the next iframe what can happen if the mkv consist out of several incompatible streams patched into a row.

Use eg. youtube-dl to fetch an mp4 from youtube and play that. Same issue?

mpan · 2016-10-30 13:34:20

Dgameman1 wrote:

Also, I don't recall it happening on other distros I was using. It doesn't happen in Windows either

So you’re saying that other distros and Windows create non-existent I-frames out of thin air? Sorry, that’s how the things work — don’t deny the obvious: you can’t have video if there is no I-frame found to be displayed on seeking. The two solutions are:

Applying non-I-frames to the previously rendered image. This produces the described effect.
Outputting nothing until an I-frame is found. This produces an irritating lag.

The first of these two is the best-effort solution, which allows at least some of the streams to be played. Whichever is applied, you have to wait for the next I-frame.

If you haven’t seen this effect earlier, it’s probably because you have used files with more densely packed I-frames, or it has just happened that I-frames were at the positions to which you were seeking.

Last edited by mpan (2016-10-30 13:37:35)

seth · 2016-10-30 13:52:25

Could also be a caching issue if it's slow media (network, optical) and large files or a bad (non-streaming oriented) container. We lack details on the actual problem.

Dgameman1 · 2016-10-31 07:20:26

V1del wrote:

It depends on the video codec, hardware acceleration might cause the same effect. What is the video codec in use? Have you tried with/without hardware decoding? Which output module do you use? VLC has that issue with VDPAU output here using GLX instead works.

I am currently using hardware acceleration but I shall try it without and let you know.

I'm honestly not sure how to find out which video codec I use

seth wrote:

Most important question is whether that affects *every* video or only some (one).
You describe an issue to find the next iframe what can happen if the mkv consist out of several incompatible streams patched into a row.
Use eg. youtube-dl to fetch an mp4 from youtube and play that. Same issue?

Weird, I do NOT get that same issue

So then it's just the video then? Guess not much I can do then lol
Thanks though!

mpan wrote:

Dgameman1 wrote:
Also, I don't recall it happening on other distros I was using. It doesn't happen in Windows either
So you’re saying that other distros and Windows create non-existent I-frames out of thin air? Sorry, that’s how the things work — don’t deny the obvious: you can’t have video if there is no I-frame found to be displayed on seeking. The two solutions are:
Applying non-I-frames to the previously rendered image. This produces the described effect.
Outputting nothing until an I-frame is found. This produces an irritating lag.
The first of these two is the best-effort solution, which allows at least some of the streams to be played. Whichever is applied, you have to wait for the next I-frame.
If you haven’t seen this effect earlier, it’s probably because you have used files with more densely packed I-frames, or it has just happened that I-frames were at the positions to which you were seeking.

What I'm saying is that I don't get gray pixelated artifacts when I seek a random spot in the video on other distros.

seth · 2016-10-31 13:46:22

Is the video in question publically available?

V1del · 2016-10-31 21:04:22

Dgameman1 wrote:

I'm honestly not sure how to find out which video codec I use

In VLC Extras -> Media Codecs or similar mplayer should output it on console as well IIRC

mpan · 2016-11-01 02:59:48

Dgameman1 wrote:

I'm honestly not sure how to find out which video codec I use

Using:

ffprobe -i your-file

This should give you full information on streams and codecs in the file.

Dgameman1 wrote:

What I'm saying is that I don't get gray pixelated artifacts when I seek a random spot in the video on other distros.

You do. Maybe you missed it before for some reason, but this is something related to the way video is encoded. You can’t avoid it. The only alternative a player has is to display nothing at all until it has data in all streams, causing serious freeze on each seek. Maybe the ones you have been using previously do it this way. I doubt that, as it’s the worse solution from user’s point of view, but — well — maybe.

Just to be sure: is the effect manifesting itself exactly as you have described it? You seek and immedietly get gray/random pixelated things? There is no single frame displayed beforehead? See the comparison — does it look like in the top or the bottom example? Notice what happens just after the seek. You have described the second option, but if you actually observe the first one it’s a different thing. The first one is caused by dropping frames. This usually happens spontaneously if the computer is not powerful enough or too loaded to load them in time. Since seeking is relatively expensive operation, it may cause a spike in load and one or few frames after the seek may be dropped, causing mangled output.

I second seth’s suggestion to provide us with the sample.

Dgameman1 · 2016-11-01 08:06:50

mpan wrote:

Dgameman1 wrote:
I'm honestly not sure how to find out which video codec I use
Using:
ffprobe -i your-file
This should give you full information on streams and codecs in the file.
Dgameman1 wrote:
What I'm saying is that I don't get gray pixelated artifacts when I seek a random spot in the video on other distros.
You do. Maybe you missed it before for some reason, but this is something related to the way video is encoded. You can’t avoid it. The only alternative a player has is to display nothing at all until it has data in all streams, causing serious freeze on each seek. Maybe the ones you have been using previously do it this way. I doubt that, as it’s the worse solution from user’s point of view, but — well — maybe.
Just to be sure: is the effect manifesting itself exactly as you have described it? You seek and immedietly get gray/random pixelated things? There is no single frame displayed beforehead? See the comparison — does it look like in the top or the bottom example? Notice what happens just after the seek. You have described the second option, but if you actually observe the first one it’s a different thing. The first one is caused by dropping frames. This usually happens spontaneously if the computer is not powerful enough or too loaded to load them in time. Since seeking is relatively expensive operation, it may cause a spike in load and one or few frames after the seek may be dropped, causing mangled output.
I second seth’s suggestion to provide us with the sample.

Oh! that's actually kind of interesting. You learn something everyday.

It's actually the second example.

And the video wasn't exactly obtained legally. (Arggg)

But I looked in the comments and apparently I'm not the only one that experiences it on this video.

But yeah, I checked and it does also sometimes happen occasionally on Windows. But I never tried this video file when I had windows so that's why I wasn't able to tell.

Thanks again!

mpan · 2016-11-01 09:00:24

No need to quote whole post you answer to, if it’s just above your answer.

You may try to use another container format. Matroska demuxer is known to require more processing power than ones for other popular containers. If codecs are compatible, you don’t have any fancy streams/metadata in your movie and licensing is fine for you, you may try MP4. If you need only one video and one audio stream, and codecs will not cause problems, consider AVI — the demuxer itself will run damn fast even on very old computers.

Do not take this as a proof that Matroska is bad. Modern things require more processing power, because they provide more things, and we just have to deal with it.

For MP4:

ffmpeg -i your_video.mkv -acodec copy -vcodec copy -scodec copy your_video.mp4

For AVI:

ffmpeg -i your_video.mkv -acodec copy -vcodec copy -map VIDEO_STREAM_ID -map AUDIO_STREAM_ID your_video.avi

VIDEO_STREAM_ID and AUDIO_STREAM_ID are identifiers of the streams you may get from ffprobe (these in form “0:n”).

Last edited by mpan (2016-11-01 09:06:30)

Arch Linux

#1 2016-10-29 00:27:23

Media players lag when skipping

#2 2016-10-29 02:01:50

Re: Media players lag when skipping

#3 2016-10-29 07:53:11

Re: Media players lag when skipping

#4 2016-10-29 08:44:29

Re: Media players lag when skipping

#5 2016-10-29 14:52:41

Re: Media players lag when skipping

#6 2016-10-30 13:34:20

Re: Media players lag when skipping

#7 2016-10-30 13:52:25

Re: Media players lag when skipping

#8 2016-10-31 07:20:26

Re: Media players lag when skipping

#9 2016-10-31 13:46:22

Re: Media players lag when skipping

#10 2016-10-31 21:04:22

Re: Media players lag when skipping

#11 2016-11-01 02:59:48

Re: Media players lag when skipping

#12 2016-11-01 08:06:50

Re: Media players lag when skipping

#13 2016-11-01 09:00:24

Re: Media players lag when skipping

Board footer