VOD feature

[akhilleusuggo]

I hope to see this feature on the future . Will be the most important thing to add probably for live-streams . This feature is from NGINX Plus , but there's open source for that https://github.com/kaltura/nginx-vod-module

This is a gamer-changer for live-streaming .

[DanielnetoDotCom]

If I understand correctly with this we do not need to encode the files anymore correctly?

If yes I guess it will consume a lot of CPU. If you have to many users at the same time you can be converting many files at the same time and you may need a huge CPU.

What is the best advanced you see here?

[akhilleusuggo]

NONO , it does not consume resources , that's the best of it ... Basically what it does , is save the videos on a location ( can be on the same rtmp server , and viewers can watch it from there ) , in our case we could host them on a modified version of YPT-Storage .

There's no need to convert files from , no cpu required , probably a bit of IO will be needed , but nothing else . It's the same codec . If you convert from m3u8 to mp4 , 0%cpu will be used , only IO . Same codecs: mp4a , mp4 etc

[DanielnetoDotCom]

I see.

Does the converted file will be cached or it does need to convert each request? is hard for me to see a transcoding/conversion process without a high CPU usage.

Yes, using it on the storage is a good idea, we just save one single video file and let the VOD-module convert it. but we must make/test Storage over Nginx. it may work already but I am not sure.

I guess the best goal here is if we can use it to upload MP4 files (maybe other formats too). and the script will convert to HLS.

Please confirm if that is your thought

[akhilleusuggo]

Does the converted file will be cached or it does need to convert each request? is hard for me to see a transcoding/conversion process without a high CPU usage.

Ok , go right now to any directory that you have videos converted into HLS . And type this command line : ffmpeg -allowed_extensions ALL -i index.m3u8 -c copy -movflags +faststart output.mp4

For example here :

If it's a video of 10mn , will be compiled in less then 5s , JUST BECAUSE of the -movflags +faststart , if you remove it , will be practically immediate .

I guess the best goal here is if we can use it to upload MP4 files (maybe other formats too). and the script will convert to HLS.

Please confirm if that is your thought

So the streams will be recorded on a location , for example /use/local/html/vod/test.mp4 ( could be .flv too ) The test.mp4 will be restreamed on hls fragments upon requests , same principles when we stream to rtmp-nginx with OBS , the stream got fragmented into HLS_fragments automatically ( and does not use CPU ) , is the same .

It is just the best way to save streams without the need to re-transcode them . The good thing about it is when your RTMP-Server does have adaptive stream activated , the stream is for example into 720/480/360 , all this transcoded files wont need more transcodes , will just be saved as transcoded , saving transcoding time wast and power .

This is what all this streaming platforms uses , Twitch ,Wowza etc etc .

[DanielnetoDotCom]

ffmpeg -allowed_extensions ALL -i index.m3u8 -c copy -movflags +faststart output.mp4

That is a sample of HLS to MP4, what about MP4 to HLS? is it fast too without consuming CPU?

next request to the same video, it will process again or will use a cached conversion?

also, you are saying we can transcode a live stream to only 1 resolution and use this to make adaptive bitrate (ABR) without consuming CPU?

[akhilleusuggo]

That is a sample of HLS to MP4, what about MP4 to HLS? is it fast too without consuming CPU?

Try this : ffmpeg -i output.mp4 -c copy -f hls -hls_time 6 -hls_list_size 0 output.ts ; video done in less then a second

next request to the same video, it will process again or will use a cached conversion?

I can not confirm , but will be some cache time or permanent conversion .

also, you are saying we can transcode a live stream to only 1 resolution and use this to make adaptive bitrate (ABR) without consuming CPU?

No , what I'm saying is , if your RTMP-Server does have adaptive livestream enabled , and the live-stream is transocded , then the VOD will be saved as transcoded ( 3 different files )

[DanielnetoDotCom]

ffmpeg -i output.mp4 -c copy -f hls -hls_time 6 -hls_list_size 0 output.ts ; video done in less then a second

I tried this, it really made the conversion really fast. but looks like it was the same resolution, and it was only .ts files without the m3u8 files and no encryption key for the HLS format. but this option still useful.

No, what I'm saying is, if your RTMP-Server does have adaptive livestream enabled, and the live-stream is transcoded , then the VOD will be saved as transcoded ( 3 different files )

I still do not get what is your idea, do you mean to use it to save the Livestream without need to encode?

Or maybe convert formats easily?

And, if that is the idea, why do I need the VOD-module if I can use FFMPEG?

[akhilleusuggo]

I tried this, it really made the conversion really fast. but looks like it was the same resolution, and it was only .ts files without the m3u8 files and no encryption key for the HLS format. but this option still useful.

Daniel I just gave you a small example , if you want all those options here you have it ( you wont need it , the VOD will do the job , not us ) , try this one out ! : ffmpeg -i input.mp4 -codec: copy -start_number 0 -hls_time 10 -hls_list_size 0 -f hls index.m3u8

The key incryption can be implemented with openSSL and just indicating on ffmpeg line the location of the key ; example : -hls_key_info_file encryption.key

I still do not get what is your idea, do you mean to use it to save the Livestream without need to encode?

Exactly ! You can save in multiple places , no need to re-encode them if they're already transcoded with adaptive stream mode

Each one of the transcoded files will not require a queue on the encoder each time , live-stream over , and that's it !!!!

The real goal , is that when the stream is over , you can re-watch it immediately .

Think about it like the DVR , but permanent . Here are all the options : https://libraries.io/github/kaltura/nginx-vod-module A lot of good stuff , give full control over the stream . Bandwidth limits , speeds etc etc .

[syldri]

Hello @akhilleusuggo to understand when the mode the adaptive flow mode is activated it consumes a lot of CPU

but it stranscode once because adaptive mode is enabled ?

when we use nginx-vod-module it will not transcode a second time ?

i just want to understand how the elements are transcode

if I follow your logic with nginx-vod-module install the videos no longer sound trancoder even live?

[akhilleusuggo]

@syldri No , the videos on the rtmp will still require transcode . But with the option AVideo have right now is limited . Because when the stream has finished , will be sent to the encoder to transcode it again ... With the VOD this sending to request transcoding ( once again ) will not required !

[syldri]

@akhilleusuggo that confirms my first thought it always takes a lot of CPU for the adaptive world

and if the adaptive world is not enabled, will the nginx-vod module work or not?

[akhilleusuggo]

Yes will work , will save the stream as it has been streamed , and no encode required and immediately add it to the video's platform .

[syldri]

with the explanation I confirm that it saves a lot of resources

[akhilleusuggo]

Ok , did some test ( not on AVideo ) , but as pure nginx-vod module on a VM 1core ( @2.6ghz ), 1GB RAM :

1 stream mp4 to hls ( 720p ) uses 12% cpu , 97mb RAM Basically a VPS with 2cores/2GB RAM will be able to convert on the fly around 20 streams constantly . ( that in case you have 20 people watching 20 different videos ) . In case 20 people are watching the same video , then only 12% cpu , 97mb RAM will be used .

[syldri]

hello @akhilleusuggo 12% of CPU the adaptive mode is activated, if you run 20 streams and each stream has 10 users who look at each stream, it gives you a total of 200 simultaneous users , the CPU will always stay at 12% or the server is too small ?

if we take the minimum of 12% because with 100 users, the CPU will be 72% always with the 20 streams hls ( 720p )

I just ask to understand I will test what you say to see

[akhilleusuggo]

Before asking , I think you should understand what this topic is about . You're missing too much things up . Try to find the difference between , RTMP-NGINX , Adaptive stream ( transcoder ) , and nginx-vod module. 3 different things that has nothing to do with each other and will operate separately .

[syldri]

@akhilleusuggo the bottom line of knowledge is to ask in order to understand

• I take the information you provided ( I took what you said to a bigger rung, )

• before attacking people learn to understand a person's explanation

• I know very well the difference between the 3

[akhilleusuggo]

@syldri I didn't attacked you , never was my intention to offend you . Sorry anyway . Just your message , is confusing .

hello @akhilleusuggo 12% of CPU the adaptive mode is activated, if you run 20 streams and each stream has 10 users who look at each stream, it gives you a total of 200 simultaneous users , the CPU will always stay at 12% or the server is too small ?

if we take the minimum of 12% because with 100 users, the CPU will be 72% always with the 20 streams hls ( 720p )

I just ask to understand I will test what you say to see

Running 20 stream requires 20 conversions , not 200 . The users are watching the same stream , the server will not convert for each of the the SAME stream .

I tested as I have stated above on a VM on 1 vCore . 12% is what is was in use white playing back the stream .

if we take the minimum of 12% because with 100 users, the CPU will be 72% always with the 20 streams hls ( 720p )

Each stream will consume 12% ( if multiple users are watching the same one , then will use 12% , is the same video ) Following your example , 20 DIFFERENT stream , will consume 12%*20 = 240% ( 2 cores ) , only in case 20 DIFFERENT stream are playing back at the same time .

Ofc , this is only to playback SAVED live-streams , the rest of the videos uploaded with the encoder will not be affected .

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.