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

←back to thread

1113 points Bluestein | 13 comments | | HN request time: 1.767s | source | bottom
Show context
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 #
1. 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 #
2. 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.
3. 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 #
4. ac29 ◴[] No.41278498[source]
48hz support seems pretty common.
replies(1): >>41282053 #
5. Dylan16807 ◴[] No.41278835[source]
120Hz screens are good enough here that I'd call them a silver bullet.
6. globular-toast ◴[] No.41280846[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 #
7. jcelerier ◴[] No.41282053[source]
Is it ? I had dozens of monitors and never saw it
replies(1): >>41289944 #
8. jcelerier ◴[] No.41282064[source]
The CPU computation time is definitely not a problem, the fact that 60/24 (or sometimes 23.97) is not an integer is
9. loeg ◴[] No.41282593{3}[source]
I don't think frames coming at most 8.3ms early/late are perceptible, much less "jerky."
replies(1): >>41284443 #
10. globular-toast ◴[] No.41284443{4}[source]
It is perceptible and it is jerky.
replies(1): >>41293467 #
11. namibj ◴[] No.41289944{3}[source]
Just set it, it works.
replies(1): >>41315105 #
12. jcelerier ◴[] No.41293467{5}[source]
I concur, it's definitely noticeable
13. jcelerier ◴[] No.41315105{4}[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