search

pseudosavant / player.html

One file drop-in media player web app for using video and audio files served using basic HTTP directory listing
MIT License
216 stars 39 forks source link

Response to progress-bar click is slow #19

Closed VisImage closed 3 weeks ago

VisImage commented 2 years ago

Environment: windows 10, with i7 CPU; Chrome and MS Edge;

Action: click on the progress bar (time line of the video), forward (and backward) of the current time. Expected behavior: video will start play at the time point clicked in real-time without obvious waiting. actual behavior: video starts to play in 2~4 seconds on my computer, varying from time to time. The wait time is not obviously changed after changing the settings on Animate Thumbnails; Generating Thumbnails.

When turning off the additional features, it should be fast to start playing the video at any point of time when it is downloaded. Where is a good place to make improvement?. Is it straight forward to make changes. Thank you

pseudosavant commented 2 years ago

Hi @VisImage, can you check in your browser dev tools, on the network tab, to see if there are other files being transferred on that page other than the playing video? If thumbnails are off, the only thing you should see downloading while playing is your one video file.

What version of player.html are you on? It can be found in the <head> of the player.html HTML <meta name='version' content='x.y.z'>

Lastly, what happens if you try to play, and seek in, that video in a blank tab? If the seek times are similar to what you see in player.html, then the only thing you can improve would be on the server side (more bandwidth, faster VM, etc).

VisImage commented 2 years ago

Hi Paul, Thank you for the reply and suggestions. Have been working on other project ... Checked the network tab, a screenshot is here: image No other file is downloading. but seems the same video file is touched multiply times. Is it normal?

I have walked around this issue for my need by the following modification:

    updateRate: { // Limit UI update rates in ms
     // timeupdate: 1000/5, // video playback `timeupdate` events
     // trickHover: 1000/10 // Seeking on trickplay hover overlay
      timeupdate: 1000/2, // video playback `timeupdate` events
      trickHover: 1000/2 // Seeking on trickplay hover overlay
    }
pseudosavant commented 2 years ago

@VisImage Yes, it is normal for it to appear like there are multiple downloads of the same file. Each HTTP request for a piece of the video file is its own line. I'd be more concerned if there were many other files also being downloaded at the same time.

Changing the UI update rate improved your playback experience?

Are all the problematic files you are trying to stream from an iOS device? The default video bitrates for mobile devices can be quite high. They are not optimized for space/streaming.

On my iPhone 8+, on the low end 1080p@30fps is about 8mbps, and 4K@60fps is >50mbps. Many devices are higher than this. I don't know what uplink speed you have for the server hosting player.html, or what the downlink speed is for the client device, but you will have a slower playback experience on unoptimized files like that.

I re-encode files I want to stream using Handbrake. I generally keep my 1080p videos at or under 5mbps - using a constant quality factor (usually 22 @ 1080p). Using NVEnc (if you have a recent nVidia GPU) or the Apple hardware encoder (for ARM-based Macs) will give you very good quality (as good as or better than software encoding) results with very fast encoding times. Use the software x264/x265 encoders for other hardware.