I’m trying to wrap my head around how media player websites work.

This might not be fully programming, but idk where else to post this question

Some video sharing sites uses blob objects to send the video in chunks, instead of letting the browser download in full. Usually there’s mpd or m3u8 files that we can use to download the whole video

But some sites don’t use those files. They send mp4 chunks, but those mp4s can’t be played and seem encrypted.

How is the webpage’s video player able to play the video? Is there a decrypter or something in the webpage/video player? Am i able to download all mp4 chunks and run them through some decrypter in the webpage served to me and create the whole video from it?

  • fubarx@lemmy.world
    7·
    18 hours ago

    The exact format depends on the source file format, the platform of the player, the duration of the clip, encryption, and whether it’s copyrighted material or not. Also, if it’s older software or fairly recent (the current schemes stand on the carcasses of a lot of old formats).

    If the source is a single file, it’s likely MP4 or WebM (or MOV on Apple and AVI on Windows). The video player can start downloading the whole thing in a background thread. When it has enough material buffered, it can start decoding and playback. However, if there is a network glitch, the video may start pausing and stuttering. This is typically how unprocessed video is served from a cloud file storage site.

    Many sites use HLS or MPEG-DASH (or their superset CMAF) to send the video in adaptive chunks. The user-experience is much better and has better server utilization. The manifest files describe which chunks to get depending on current bandwidth. Players can then up or downscale their next request based on network conditions to avoid stuttering. Overloaded servers can also downthrottle the chunk formats on-the-fly.

    Apple device native video players only support HLS/CMAF, and inside native appstore apps, files over 10 minutes must be HLS formatted. Non-Apple devices may use either format.

    Then there’s encryption. If a decryption key (often AES-128) is provided, the player can download it over https, then decrypt the stream on the fly. This is so anyone sniffing the stream only sees encrypted content.

    If the material is copyrighted, it may have DRM. On Apple devices this is likely FairPlay. On Windows it could be PlayReady, and on Android and for some browsers, it could be Widevine. Then there’s CENC, which use a common encryption format so the same stream can have PlayReady or Widevine.

    Most browsers support HLS, since it’s delivered over HTTP, it’s adaptive, and tools like ffmpeg or handbrake can generate all the files and chunks one time, once a video file is uploaded. The chunks can be hosted anywhere HTTP is served.

    This is all for one-way, one file, one viewer mode. If the video stream is meant to be two-way or multicast to lots of viewers, you’ll want to head into the world of WebRTC, RTMP, and RTSP.

    • JiminaMann@lemmy.worldOP
      1·
      10 hours ago

      Seems like its playready 4.0.0.0? According to the hex of one of the encrypted mp4

      Thanks, I’ll read through

  • bizdelnick@lemmy.ml
    5·
    22 hours ago

    Try to disable EME in your browser. Would such videos become unencrypted or just stop working at all?

    In Firefox it is the media.eme.enabled setting in about:config.

  • Alex@lemmy.ml
    2·
    19 hours ago

    Basically you need to hook into decryption engine being used and copy the unencrypted data before it gets sent to the hardware to play. I assume something like Widevine sends the data directly to the system codec for playback so you could look at the syscalls it makes for that.

    • JiminaMann@lemmy.worldOP
      2·
      19 hours ago

      Unfortunately, downloadhelper says that the download has failed, and it can’t download the video. It can find it tho