-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tdarr_Plugin_bsh1_Boosh_FFMPEG_QSV_HEVC - Added AV1 encode support & HDR improvement #706
base: master
Are you sure you want to change the base?
Conversation
Fairly major revision. Been using this locally for months on HEVC & AV1 encodes and not had any issues currently. I can't verify if my 4k HDR & DoVi setups are 'actually' working for real but they seem to look correct & I've not had errors for encodes or on Plex. With AV1 support, admittedly this may be confusing since the plugin ID still specifies HEVC but I have updated the name. I didn't want to split this into a new plugin since the logic is pretty much exactly the same & I don't want to maintain two almost identical plugins) - Adding AV1 encode support, added as drop down selector (default is still hevc) - Logic should pick valid video profile for either encoder setting - HDR detection & encode improvement (Appears to work on my HDR content & DoVi) - Added target bitrate modifier so it's possible to tune the bitrate (useful for AV1 to crunch it down further) - Better bitrate detection, should error if it can't be found at all - Mac support is over. Doubt anyone was really using it on Mac but it's not worth touching further. Plugin should still use videotoolbox when on Mac but I won't be fixing up errors. - Cleaned up descriptions & info logs where reasonable to try and clarify what's happening - Tests updated & added new test for a fully loaded AV1 setup
Will mention that the options "hevc_max_bitrate" & "reconvert_hevc" now are named a little poorly due to av1 support, but I don't think I can re-name without settings being lost which I'd like to avoid. |
What HDR is output ? and can we use this method to make a flow generally preserver HDR in the general case... I can do it in the general case with I tried with this could net get QSV to work everything else HDR in came out HDR 10 out correctly
|
I've currently ensured the color data is pulled over correctly by just copying what the file reports. i.e just setting these on the encode cmd.
However on properly reviewing my HDR files I am noticing actual HDR metadata is missing. This method is likely 'ok' for bog standard HDR but Dolby vision is probably wrong. I'm actually reviewing this now, it might be ok. Something to note for your code, the video profiles on AV1 & HEVC are different. I'm assuming you're trying av1 due to being on this thread so; |
Ok so I have reviewed my test cases again & it appears metadata is in tact for the most part. The output HDR format seems to match what comes in (be that HDR, HDR10, dolby vision). i.e this is a converted file, dolby vision & HDR10 data appears to be intact & correct.
Mediainfo
Will be happy for the HDR logic to be reviewed if needs be, (lines 616-650). if (file.ffProbeData.streams[i].codec_type.toLowerCase() === 'video') {
// Check if codec of stream is mjpeg/png, if so then remove this "video" stream.
// mjpeg/png are usually embedded pictures that can cause havoc with plugins.
if (file.ffProbeData.streams[i].codec_name === 'mjpeg' || file.ffProbeData.streams[i].codec_name === 'png') {
extraArguments += `-map -0:v:${videoIdx} `;
} else { // Ensure to only do further checks if video stream is valid for use
// Check for HDR in files. Attempt to use same color
if ((file.ffProbeData.streams[i].color_space === 'bt2020nc'
|| file.ffProbeData.streams[i].color_space === 'bt2020n')
&& (file.ffProbeData.streams[i].color_transfer === 'smpte2084'
|| file.ffProbeData.streams[i].color_transfer === 'arib-std-b67')
&& file.ffProbeData.streams[i].color_primaries === 'bt2020') {
response.infoLog += '==WARNING== This looks to be a HDR file. HDR is supported but '
+ 'correct encoding is not guaranteed.\n';
extraArguments += `-color_primaries ${file.ffProbeData.streams[i].color_primaries} `
+ `-color_trc ${file.ffProbeData.streams[i].color_transfer} `
+ `-colorspace ${file.ffProbeData.streams[i].color_space} `;
hdrEnabled = true;
}
// Had at least one case where a file contained no evident HDR data but was marked as HDR content
// meaning transcode OR plex would butcher the file
if (hdrEnabled !== true) {
try {
if (typeof file.mediaInfo.track[i + 1].HDR_Format !== 'undefined') {
response.infoLog += '==ERROR== This file has Media data implying it is HDR '
+ `(${file.mediaInfo.track[i + 1].HDR_Format}), `
+ 'but no details about color space or primaries... '
+ 'Unable to convert and safely keep HDR data. Aborting!\n';
return response;
}
} catch (err) {
// Catch error - Ignore & carry on - If check can bomb out if tags don't exist...
}
} |
Done more testing & confirmed, dolby vision files are normally not converted properly so we'll filter these out now. The output usually doesn't have evident issues, it's only when tested on a Dolby vision TV that issues present & it's highly dependant on the source material. i.e I think if the file has the correct HDR10 fallback info then it will play fine on a Dolby vision TV (just can't play Dovi proper), but a lot of files I've had don't have this info & after conversion the Dovi TV will display a pink blown out version. It'll be better to just prevent Dovi conversions & I guess there's the question of why compress a Dovi file? I don't think it fits the work flow of a bitrate based re-encode.
Good thing HDR came up as I've done more testing & confirmed, so actually Dolby vision files are an issue so we'll filter these out now. Standard HDR is certainly correct, but still need some more testing on HDR10. So with Dolby vision, ffmpeg doesn't error but I don't think QSV supports native dolby vision encoding so dealing with those files will be tricky. The output will only show issue when tested on a Dolby vision TV. I think if the source file has the correct HDR fallback info then after encode it will play fine on a Dolby vision TV (just can't play Dovi proper), but I realised a bunch of files I have don't have this info & after conversion the Dovi TV will display a pink blown out version. |
Realised haven't accounted for HDR10+ which would also likely be affected by ffmpeg so we skip those too. Also some tidy up on comments Removed a map cmd that shouldn't be needed
Also updated now to account for HDR10+ which I had missed. It should now skip those too. |
Fairly major revision. Been using this locally for months on HEVC & AV1 encodes and not had any issues currently. I can't guarantee my 4K HDR & DoVi setups are 'actually' working for real but they seem to look correct & I've not had errors for encodes or on Plex.
All testing was done on an Unraid setup, 6.12.13, using a Arc 380. Custom firmware so Arc can be used. Should be using default Tdarr docker setup with current inbuilt ffmpeg.
With AV1 support, admittedly this may be confusing since the plugin ID still specifies HEVC but I have updated the name. I didn't want to split this into a new plugin since the logic is pretty much exactly the same & I don't want to maintain two almost identical plugins)