Video files are directly accessible via HTML5 player

[cruurds]

While exploring the current player, I found a bug :- remote video files are directly accessible (without auth) via tracking network requests.

Only HTML5 file playback support, vunerability is access to files via tracking network requests. Implementation of VHS would rectify lack of unsupported prototcol within player, HLS would mitigate file download, player.js would assist in offiscating playback URL.

Via tracking network requests, download files directly.

HLS Playback issue. Insert HLS URL into URL field supported upload area for video asset. When attempting playback, playback fails due to lack of HLS support.

1. TODO Fork streama-player to understand mechanisms
2. TODO HLS.js https://github.com/video-dev/hls.js
3. TODO Merge request

Expected Behaviour

Video assets should not be accesable via network tracking. Assest need to be as secure as possible and not accesible to avoid unnecessary copyright legal infringements.

Video delivery should at a minimum be HLS and include AES128 encryption, tokening to avoid direct download.

Actual Behaviour

All files should only be accesible if enabled in functionaity settings, optional. Currently files are accesible whether download is enabled or disabled via network tracking.

Environment Information

Intellij IDE, Ubuntu 20.04 LTS

[dularion]

Hi, Thanks for pointing this out. So are you saying that I can access a video file directly without authentication? because I doubt that very much. Or are you saying that through network tracking, while a user plays the video and requests chunk after chunk, that the file is recreatable on the trackers host? and if so, is the latter even feasable? and what would happend if the user doesnt watch till the end, isnt it then a corrupt video file anyway? Please elaborate

[cruurds]

Hi Dularion, Thank you for the responce. I will dig deeper to confirm. see :- https://ibb.co/CPjs01r

[cruurds]

Hi Dularion, Hope this helps for all those people needing and requesting HLS support.

Method for Streama Video Player + HLS.js

Sources:

• https://github.com/streamaserver/streama-video-player
• https://github.com/video-dev/hls.js/

To integrate HLS.js into Streama Video Player:

1. clone https://github.com/streamaserver/streama-video-player

2. bower install

3. bower install hls.js

4. include hls.js dist file to player EXAMPLE -

   ...

Make sure the contentType is "contentType": "application/vnd.apple.mpegurl" or "contentType": "application/x-mpegurl" - note that application/x-mpegurl is more android friendly

---

I haven't check the complete video options nor any other settings from Streama Player, this is a basic integration of HLS on streama player

This will answer many requests for HLS playback in streama. Thanks Dularion :-)

[f1reflyyyylmao]

As far as I know it was never the goal of streama to prevent logged in users to download video files, which seems to be your complaint?

I don't quite understand how it would help with anything copyright-related to forbid access to the video files themselfes, while still allowing video streaming; either you stream your own content to your own devices, which would probably be legal, or you want to make it public, which would be illegal under many jurisdictions. Wether the user can download the file itself is not important for this.

In my eyes, the only thing this does is add another layer of complexity and another library when plain html5 video playback works just fine for the intended use of streama.

[cruurds]

streama-video-player-hls.zip Working Streama Player with HLS.js IMHO, scrubbing is improved and the auto adaptive bitrate works well. HLS is smooth across devices.

[interlifeisp]

Hi Dularion, hls.js incorporates functionalities for Safari 8+ for MacOS 10.10+ Safari for ipadOS 13+. That currently does not have a streama player. It would be good to incorporate the Streama player system with the contribution of cruurds ...

HLS.js is compatible with:

Chrome 39+ for Android Chrome 39+ for desktop Firefox 41+ for Android Firefox 42+ for desktop IE11 for Windows 8.1+ Edge for Windows 10+ Safari 8+ for MacOS 10.10+ Safari for ipadOS 13+

[cruurds]

serving HLS see https://github.com/arut/nginx-rtmp-module

For file preperation use ffmpeg example using FFMPEG NVIDIA, 3 adaptive rate 3M, 2M, 1M - h264

1) create a file called convert.sh in the original content folder ... #! /bin/bash for file in $( find ./ -iname "*.mp4" -o -iname "*.avi" -o -iname "*.mkv") do OIFS="$IFS" IFS=$'\n' ffmpeg -threads 1 -vsync 1 -hwaccel:v "cuvid" -hwaccel_output_format:v "cuda" -y -i "$file" \ -filter_complex \ "[0:v]split=3[v1][v2][v3]; \ [v1]scale=w=1920:h=1080[v1out]; [v2]scale=w=1280:h=720[v2out]; [v3]scale=w=640:h=360[v3out]" \ -map [v1out] -c:v:0 h264_nvenc -rc:v vbr_hq -rc-lookahead:v 32 -refs:v 16 -crf 18 -b:v:0 3M -maxrate:v:0 3M -minrate:v:0 3M -g 48 -sc_threshold 0 -keyint_min 48 \ -map [v2out] -c:v:1 h264_nvenc -rc:v vbr_hq -rc-lookahead:v 32 -refs:v 16 -crf 18 -b:v:1 2M -maxrate:v:1 2M -minrate:v:1 2M -g 48 -sc_threshold 0 -keyint_min 48 \ -map [v3out] -c:v:2 h264_nvenc -rc:v vbr_hq -rc-lookahead:v 32 -refs:v 16 -crf 18 -b:v:2 1M -maxrate:v:2 1M -minrate:v:2 1M -g 48 -sc_threshold 0 -keyint_min 48 \ -map a:0 -c:a:0 aac -b:a:0 128k -strict -2 \ -map a:0 -c:a:1 aac -b:a:1 96k -strict -2 \ -map a:0 -c:a:2 aac -b:a:2 48k -strict -2 \ -f "mp4" -movflags "+faststart" "/your_folder/${file%.*}.mp4" mv "$file" "/your_folder/source_files/${file%.*}.mp4" IFS="$OIFS" done ... 2) chmod to executable convert.sh 3) create the "your_folder" output folders 4) screen -d -m -S ./convert.sh (will run the sh in a background screen)

Note that these prepared .mp4 files are muxed. They will play in the non HLS, standard streama player at highest bitrate only. In the HLS version of streama player using HLS delivery (nginx-rtmp, flussonic, wowza) the prepared files will deliver in an adaptive HLS stream which by default will autoselect the best bitrate for enduser.

I hope this is useful to all requesting HLS fix for issue - Player does not work well in mobiles iOS and Android #629