Most active commenters
  • jcelerier(5)
  • globular-toast(3)

←back to thread

1113 points Bluestein | 16 comments | | HN request time: 0.817s | source | bottom
1. Agingcoder ◴[] No.41277899[source]
I didn’t know mplayer had been forked - this looks good to me. The primary reason why I used mplayer in the early 2000s was performance, both in terms of cpu and for lack of a better word ‘ smoothness ‘.

Basically all other players seemed to produce choppy videos ( including regular dvd players ) but mplayer didn’t ( and there was no motion interpolation). A friend of mine told me that mplayer was very accurate ( ie each frame lasted exactly the same duration), unlike most players on the market at the time and this explained the ‘smooth’ feeling.

Is this smoothness advantage still the case ? Would anyone know why it felt like that years ago ?

replies(3): >>41277955 #>>41278808 #>>41279401 #
2. jcelerier ◴[] No.41277955[source]
It's impossible for video players to be exactly accurate on normal monitors as most computer monitors don't handle movie frame rates. Either a frame gets skipped or elongated here and there, audio get resampled while video speed changes, etc. but there's definitely no silver bullet due to imperfect hardware not matching movie data formats
replies(4): >>41278206 #>>41278479 #>>41278498 #>>41278835 #
3. globular-toast ◴[] No.41278206[source]
A lot of monitors these days support a kind of variable refresh rate like Freesync, so this should be possible. I've never actually got it to work with AMD, Linux and mpv, though.
4. loeg ◴[] No.41278479[source]
It's relatively easy to get 100us level precision in CPU wait and mpv has 42ms (42,000us) to emit each frame (at 24fps). Nevermind that the monitor refresh is likely 60fps or better so each frame lasts for two+ monitor frames anyway. As long as it is consistent with each frame timing it should be very rare that a video frame is skipped or doubled up.
replies(2): >>41280846 #>>41282064 #
5. ac29 ◴[] No.41278498[source]
48hz support seems pretty common.
replies(1): >>41282053 #
6. Dylan16807 ◴[] No.41278808[source]
That can't be it. The circuit outputting video onto the wire triggers every 1/60th of a second, always the same duration.

There are situations where a player could time things so badly an entire frame has to be skipped, but that shouldn't happen often. And it should basically never happen on a regular DVD player. Any variations smaller than that disappear; whether a frame is ready 15ms before the deadline or 1ms before the deadline has no impact on the output.

7. Dylan16807 ◴[] No.41278835[source]
120Hz screens are good enough here that I'd call them a silver bullet.
8. lysace ◴[] No.41279401[source]
The primary reason that many of us still used MPlayer 20 years ago was that it did keyboard-based seeking really well. Nothing fancy, just look for the closest I-frame from the target time and move exactly there.

This art of quick seeking sort of got lost in time as the distance between UX people and people who understand H.264/265/etc in detail grew.

On Apple TV: At best it takes like 500 ms. At worst (the Max app), like 6000 ms.

MPlayer 20 years ago: 17 ms.

9. globular-toast ◴[] No.41280846{3}[source]
Frames shouldn't be skipped but if the monitor is at 60Hz and the video is at 24 then many frames will have to come early or late. That's what causes the stutter that is most apparent on slow planning scenes. It's like the reel in the projector is being fed through in a jerky manner so each from lines up with one of the monitor frames rather than going through at constant speed like it's supposed to. There's no way around this. However with 120Hz monitors you just display one frame every 5 frames and no jerky motion is required (except the fact that US releases are at 23.976fps, not 24, so a frame will have to be doubled every now and then I guess, or maybe the soundtrack is just pitched up to 24? Don't know).
replies(1): >>41282593 #
10. jcelerier ◴[] No.41282053{3}[source]
Is it ? I had dozens of monitors and never saw it
replies(1): >>41289944 #
11. jcelerier ◴[] No.41282064{3}[source]
The CPU computation time is definitely not a problem, the fact that 60/24 (or sometimes 23.97) is not an integer is
12. loeg ◴[] No.41282593{4}[source]
I don't think frames coming at most 8.3ms early/late are perceptible, much less "jerky."
replies(1): >>41284443 #
13. globular-toast ◴[] No.41284443{5}[source]
It is perceptible and it is jerky.
replies(1): >>41293467 #
14. namibj ◴[] No.41289944{4}[source]
Just set it, it works.
replies(1): >>41315105 #
15. jcelerier ◴[] No.41293467{6}[source]
I concur, it's definitely noticeable
16. jcelerier ◴[] No.41315105{5}[source]
doesn't work on the three monitors I tried, I get every time:

    $ xrandr -s 1280x1024 -r 48 
    Rate 48.00 Hz not available for this size