Goal: Low power cluster capable of serving 24+ streams of 4KHDR60 source transcodes while consuming no more than 100W at peak and idling at less than 10W
MIT License
25
stars
1
forks
source link
Parcing of host arguments to node appropriate, HWaccelerated variants #9
One of the requirements to pull this whole thing together will be the ability to parse arguments requested from the host and change to hardware accelerated versions.
for example, if the host requests a command like:
ffmpeg -i 1080p_HEVC_source -vf scale:1280:h -c:v libx264 -b:v 5M output
we need to parse a few things and change some others
first, we know that the source is HEVC and that HEVC can be HW accelerated. to do this we need to specify to use HW decoding. however, unlike normal cuda filters, the jocover transcode filters do not specify the hardware. they can do this !!!only!!! because it's a known target platform.
therefore, the beginning of our command looks like for hevc and you change to h264 instead if the source is H264. ffmpeg
-c:v hevc_nvmpi -i 1080p_HEVC_source -vf scale:1280:h -c:v libx264 -b:v 5M output
Now, this is still going to be super slow because the scaling and encode is on cpu. in this case, we then change to include the encoder as before (pretty much always go to h264, so output can be locked to -c:v h264_nvpmi -"requested bit rate" ). we also need to use the cuda_scale filter. This involves adding the cuda selector and looks like
ffmpeg -y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 -vf scale_cuda=1280:720
Rinse and repeat as needed for different arguments. One of the special cases will be adding in tonemaping if the source is HDR. There's a few ways to do this, but I'm planning on something simple like
char source = ffprobe "input.mp4" | grep "pixel format" \n switch (case): etc.
where you insert the tonemapping filter if/when needed.
One of the requirements to pull this whole thing together will be the ability to parse arguments requested from the host and change to hardware accelerated versions. for example, if the host requests a command like:
ffmpeg -i 1080p_HEVC_source -vf scale:1280:h -c:v libx264 -b:v 5M outputwe need to parse a few things and change some others first, we know that the source is HEVC and that HEVC can be HW accelerated. to do this we need to specify to use HW decoding. however, unlike normal cuda filters, the jocover transcode filters do not specify the hardware. they can do this !!!only!!! because it's a known target platform. therefore, the beginning of our command looks like for hevc and you change to h264 instead if the source is H264. ffmpeg
-c:v hevc_nvmpi -i 1080p_HEVC_source -vf scale:1280:h -c:v libx264 -b:v 5M outputNow, this is still going to be super slow because the scaling and encode is on cpu. in this case, we then change to include the encoder as before (pretty much always go to h264, so output can be locked to -c:v h264_nvpmi -"requested bit rate" ). we also need to use the cuda_scale filter. This involves adding the cuda selector and looks likeffmpeg -y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 -vf scale_cuda=1280:720Rinse and repeat as needed for different arguments. One of the special cases will be adding in tonemaping if the source is HDR. There's a few ways to do this, but I'm planning on something simple likechar source = ffprobe "input.mp4" | grep "pixel format" \n switch (case): etc.where you insert the tonemapping filter if/when needed.