Jump to content

Issues with Transcoding 4K HEVC with VA API


bennycooly

Recommended Posts

bennycooly

Hi,

 

When I am trying to transcode 4K HEVC, I get the following error:

[AVHWFramesContext @ 0x7fc9e006fc00] Failed to read image from surface 0x19: 1 (operation failed).
Metadata:
[hevc @ 0x555e9355a680] Failed to transfer data to output frame: -5.
title : Chapter 5
Error while processing the decoded data for stream #0:0
Chapter #0:5: start 3008.964000, end 3781.778000
Conversion failed!

The appropriate ffmpeg command is:

/usr/bin/ffmpeg -ss 00:14:24.000 -hwaccel vaapi -hwaccel_output_format yuv420p -vaapi_device /dev/dri/renderD128 -i file:"input.mkv" -threads 0 -map 0:0 -map 0:1 -codec:v:0 h264_vaapi -filter_complex "[0:3]scale=3840:2160:force_original_aspect_ratio=decrease[sub];[0:0][sub]overlay,format=nv12|vaapi,hwupload" -b:v 134494486 -maxrate 134494486 -bufsize 268988972 -profile:v 578 -level 41 -force_key_frames "expr:if(isnan(prev_forced_t),eq(t,t),gte(t,prev_forced_t+3))" -copyts -vsync -1 -codec:a:0 libmp3lame -ac 2 -ab 384000 -af "volume=2" -f segment -max_delay 5000000 -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 -start_at_zero -segment_time 3 -segment_time_delta -864 -individual_header_trailer 0 -segment_format mpegts -segment_list_type m3u8 -segment_start_number 288 -segment_list "/var/lib/emby/transcoding-temp/eda42ffc9546dbc9de88c2f0307fc5a7.m3u8" -y "/var/lib/emby/transcoding-temp/eda42ffc9546dbc9de88c2f0307fc5a7%d.ts"

Now, interestingly, if I change the -hwaccel_output_format flag to "vaapi" instead of "yuv420p" and remove the -filter_complex flag, the transcoding works. I am wondering if Emby may need to modify the commands for transcoding HEVC content? I've also attached my ffmpeg log for reference. I am using a Radeon RX 560 with VA API.

 

Thanks!

ffmpeg-log.txt

emby-log.txt

Edited by bennycooly
Link to comment
Share on other sites

Well the filtercomplex is only there due to burning in subtitles. If you turn off the subtitles then that should go away, or mostly go away. But you're right, it is possible that when burning in subtitles, that the command line may need adjustment for VAAPI.

 

@@Waldonnis what do you think about that, as well as his decoder change?

Link to comment
Share on other sites

@@Waldonnis what do you think about that, as well as his decoder change?

 

Is that user in "secondary group" for dev? If not, he can not see this forum.

Link to comment
Share on other sites

Waldonnis

A lot of this is conjecture based on what I know about vaapi despite pretty much never using it here.  I'm unable to test any of it right now and can't boot to Linux due to a disc problem, though, so any changes would require someone else to do basic testing to confirm.  I also don't have a hardware HEVC decoder, so...yeah.

 

If the decoder output is using a hardware surface format (like vaapi), then any software filtering won't be possible, so just changing the hwaccel_output_format would break software filtering unless you did a hwdownload prior to the software scale/overlay/whatever filters.  You do have some options, though, one of which is the easiest: just use hwdownload prior to the scale (may need a format specified as well).  No matter what, though, you just need to ensure proper hwupload/hwdownload filter use when needed.  It really doesn't matter if you change hwaccel_output_format to vaapi since you'd need to immediately download/convert it from the surfaces before using software filtering.  That's not necessarily bad, but it's a change with no real effect...ultimately, the decoder output has to end up in system memory and it shouldn't matter if you do it as step 1 (setting it to yuv420p or whatever) or step 2 (hwdownload filter) since there's nothing done between those two steps.

 

Syntax aside...

 

The real question in this case is why the decoder output tosses an error when you try to copy a frame to system memory as yuv420p.  It's entirely possible that there is no conversion code for 10-bit hardware surface format to 8bit pixel formats (could be an ffmpeg or driver limitation), but who knows.  It's also possible that there's a decoding problem causing the output to be malformed (see note at the bottom).  If the former is true, then hwdownload may not work either, but is worth trying as an alternative in case it does something different on the back end than hwaccel_output_format yuv420p would do.  Another option would be to use something like nv12 rather than yuv420p since it's more "surface-friendly".  If the latter is true, however, that's a serious pain to work around (I'd hang a sign stating "abandon hope all ye who enter" on the issue and walk away since there's nothing Emby can do to fix that kind of issue, lol).

 

Since you seem to be okay with playing with ffmpeg a tad, give this a try to see what happens:

/usr/bin/ffmpeg -ss 00:14:24 -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/renderD128 -i file:"input.mkv" -map 0:0 -codec:v:0 h264_vaapi -filter_complex "[0:3]scale=3840:2160:force_original_aspect_ratio=decrease[sub];hwdownload,format=yuv420p[vid];[vid][sub]overlay,format=nv12|vaapi,hwupload" -hide_banner -f null -

Warning: there might be a typo or mistake in there since I can't test it here.  It should just do a similar operation as the original, but using a surface format for the decoder output and downloading it via a filter instead.  It only operates on the video stream (no audio), since there's no need to add in the rest of the options just to test hardware copy-back and filter operations.  If it does work, you can interrupt it after a dozen frames or so are processed (no need to encode the whole thing).  It won't write a file since that's not important either, but if it works and you want to see the results, just replace the -f null and trailing hyphen with a file name.  If it doesn't work, I have a few other things to try.

 

Side note: This looks a tad like the result of something that I've been wrestling with even doing software decoding: seeking in some HEVC files causes decoding errors due to ffmpeg marking all CRA frames as keyframes even though they may contain slices that need info from prior units.  Working around this requires a LOT of pre-parsing gymnastics or modifying ffmpeg to restrict keyframe detection to only two NAL unit types, neither of which is especially fun.  I thought about submitting a patch for it, but the behaviour isn't actually incorrect (decoders are expected to just discard the GOP/frame with missing slices, but it can be problematic when seeking/segmenting files for encoding - different use case than the spec expects).  Other tools seem to have the same psuedo-issue, so even using things like mkvmerge to seek/segment end up seeking to a frame that can't be decoded cleanly.  I wouldn't doubt that some hardware decoders may cough a bit in these scenarios too, although they may just discard the frame/GOP and move along.

 

Second side note: WHY IS ANYONE TRANSCODING HDR FILES TO H.264???  Killin' me over here....

Link to comment
Share on other sites

bennycooly

A lot of this is conjecture based on what I know about vaapi despite pretty much never using it here.  I'm unable to test any of it right now and can't boot to Linux due to a disc problem, though, so any changes would require someone else to do basic testing to confirm.  I also don't have a hardware HEVC decoder, so...yeah.

 

If the decoder output is using a hardware surface format (like vaapi), then any software filtering won't be possible, so just changing the hwaccel_output_format would break software filtering unless you did a hwdownload prior to the software scale/overlay/whatever filters.  You do have some options, though, one of which is the easiest: just use hwdownload prior to the scale (may need a format specified as well).  No matter what, though, you just need to ensure proper hwupload/hwdownload filter use when needed.  It really doesn't matter if you change hwaccel_output_format to vaapi since you'd need to immediately download/convert it from the surfaces before using software filtering.  That's not necessarily bad, but it's a change with no real effect...ultimately, the decoder output has to end up in system memory and it shouldn't matter if you do it as step 1 (setting it to yuv420p or whatever) or step 2 (hwdownload filter) since there's nothing done between those two steps.

 

Syntax aside...

 

The real question in this case is why the decoder output tosses an error when you try to copy a frame to system memory as yuv420p.  It's entirely possible that there is no conversion code for 10-bit hardware surface format to 8bit pixel formats (could be an ffmpeg or driver limitation), but who knows.  It's also possible that there's a decoding problem causing the output to be malformed (see note at the bottom).  If the former is true, then hwdownload may not work either, but is worth trying as an alternative in case it does something different on the back end than hwaccel_output_format yuv420p would do.  Another option would be to use something like nv12 rather than yuv420p since it's more "surface-friendly".  If the latter is true, however, that's a serious pain to work around (I'd hang a sign stating "abandon hope all ye who enter" on the issue and walk away since there's nothing Emby can do to fix that kind of issue, lol).

 

Since you seem to be okay with playing with ffmpeg a tad, give this a try to see what happens:

/usr/bin/ffmpeg -ss 00:14:24 -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/renderD128 -i file:"input.mkv" -map 0:0 -codec:v:0 h264_vaapi -filter_complex "[0:3]scale=3840:2160:force_original_aspect_ratio=decrease[sub];hwdownload,format=yuv420p[vid];[vid][sub]overlay,format=nv12|vaapi,hwupload" -hide_banner -f null -

Warning: there might be a typo or mistake in there since I can't test it here.  It should just do a similar operation as the original, but using a surface format for the decoder output and downloading it via a filter instead.  It only operates on the video stream (no audio), since there's no need to add in the rest of the options just to test hardware copy-back and filter operations.  If it does work, you can interrupt it after a dozen frames or so are processed (no need to encode the whole thing).  It won't write a file since that's not important either, but if it works and you want to see the results, just replace the -f null and trailing hyphen with a file name.  If it doesn't work, I have a few other things to try.

 

Side note: This looks a tad like the result of something that I've been wrestling with even doing software decoding: seeking in some HEVC files causes decoding errors due to ffmpeg marking all CRA frames as keyframes even though they may contain slices that need info from prior units.  Working around this requires a LOT of pre-parsing gymnastics or modifying ffmpeg to restrict keyframe detection to only two NAL unit types, neither of which is especially fun.  I thought about submitting a patch for it, but the behaviour isn't actually incorrect (decoders are expected to just discard the GOP/frame with missing slices, but it can be problematic when seeking/segmenting files for encoding - different use case than the spec expects).  Other tools seem to have the same psuedo-issue, so even using things like mkvmerge to seek/segment end up seeking to a frame that can't be decoded cleanly.  I wouldn't doubt that some hardware decoders may cough a bit in these scenarios too, although they may just discard the frame/GOP and move along.

 

Second side note: WHY IS ANYONE TRANSCODING HDR FILES TO H.264???  Killin' me over here....

Hey, thanks for the info as I have no idea how ffmpeg actually interacts with VA API. I tried the new command and get the following output:

[matroska,webm @ 0x5572ee757280] sub2video: using 3840x2160 canvas
[h264_vaapi @ 0x5572ee9ca300] B frames are not supported (0x1) by the underlying driver.
[h264_vaapi @ 0x5572ee9ca300] Warning: some packed headers are not supported (want 0xd, got 0).
Output #0, null, to 'pipe:':
 ...
[graph 0 input from stream 0:3 @ 0x5572eec23b00] Changing frame properties on the fly is not supported by all filters.
[AVHWFramesContext @ 0x7f2eec06fc00] Failed to read image from surface 0x19: 1 (operation failed).
[hwdownload @ 0x5572ee989d00] Failed to download frame: -5.
Error while filtering: Input/output error
Failed to inject frame into filter network: Input/output error
Error while processing the decoded data for stream #0:0
Conversion failed!

It seems like it's a similar error as before. Thanks for the help, and normally I don't transcode since I use direct play within my home network, but some of my friends and family who use my server from their own houses have been notifying me that some movies are stuttering way too much, and after investigation I found that all of the error-prone movies were indeed 4K HEVC files. I tried it myself to force transcode Ready Player One by using the web player and saw that my CPU was stuck at 100% even though I remember having enabled hardware transcoding with VA API. From there I just looked at the ffmpeg logs and found this error that wasn't happening with H.264 files.

Edited by bennycooly
Link to comment
Share on other sites

Waldonnis

Hey, thanks for the info as I have no idea how ffmpeg actually interacts with VA API. I tried the new command and get the following output:

[matroska,webm @ 0x5572ee757280] sub2video: using 3840x2160 canvas
[h264_vaapi @ 0x5572ee9ca300] B frames are not supported (0x1) by the underlying driver.
[h264_vaapi @ 0x5572ee9ca300] Warning: some packed headers are not supported (want 0xd, got 0).
Output #0, null, to 'pipe:':
 ...
[graph 0 input from stream 0:3 @ 0x5572eec23b00] Changing frame properties on the fly is not supported by all filters.
[AVHWFramesContext @ 0x7f2eec06fc00] Failed to read image from surface 0x19: 1 (operation failed).
[hwdownload @ 0x5572ee989d00] Failed to download frame: -5.
Error while filtering: Input/output error
Failed to inject frame into filter network: Input/output error
Error while processing the decoded data for stream #0:0
Conversion failed!

It seems like it's a similar error as before. Thanks for the help, and normally I don't transcode since I use direct play within my home network, but some of my friends and family who use my server from their own houses have been notifying me that some movies are stuttering way too much, and after investigation I found that all of the error-prone movies were indeed 4K HEVC files. I tried it myself to force transcode Ready Player One by using the web player and saw that my CPU was stuck at 100% even though I remember having enabled hardware transcoding with VA API. From there I just looked at the ffmpeg logs and found this error that wasn't happening with H.264 files.

 

Kinda figured that would happen.  Can you do the same command and try using nv12 instead of yuv420p in the filter (change the part that says hwdownload,format=yuv420p to hwdownload,format=nv12)?  I doubt it'll make a difference and may spit out a different error if it doesn't, but worth a shot.  Really, I think it just doesn't know how to copy the surface data from a larger gamut to a smaller one.  Worst case, we could probably just copy to yuv420p10le and do the gamut reduction after the copy-back operation.

 

Just to explain it with less technobabble, I think it's breaking down when trying to copy a frame with 10bit colour into an 8-bit colour destination format.  With software decoding, this is usually not a problem as it would automatically do the conversion (badly in most cases, but it would do it).  I'm starting to doubt that the same type of automatic conversion is available when downloading decoded frames from the GPU memory.  For that, we may have to use a 10bit colour format as a "destination" or at least one that is similar to the hardware format, then convert it down to 8bit in software/system memory.

 

Honestly, transcoding 4k HDR to 8-bit h.264 without tonemapping is rarely a good idea anyway (hence my WHY!?!? note at the end, lol), but may as well see if we can get it to work within the vaapi context.

Link to comment
Share on other sites

bennycooly

Kinda figured that would happen.  Can you do the same command and try using nv12 instead of yuv420p in the filter (change the part that says hwdownload,format=yuv420p to hwdownload,format=nv12)?  I doubt it'll make a difference and may spit out a different error if it doesn't, but worth a shot.  Really, I think it just doesn't know how to copy the surface data from a larger gamut to a smaller one.  Worst case, we could probably just copy to yuv420p10le and do the gamut reduction after the copy-back operation.

 

Just to explain it with less technobabble, I think it's breaking down when trying to copy a frame with 10bit colour into an 8-bit colour destination format.  With software decoding, this is usually not a problem as it would automatically do the conversion (badly in most cases, but it would do it).  I'm starting to doubt that the same type of automatic conversion is available when downloading decoded frames from the GPU memory.  For that, we may have to use a 10bit colour format as a "destination" or at least one that is similar to the hardware format, then convert it down to 8bit in software/system memory.

 

Honestly, transcoding 4k HDR to 8-bit h.264 without tonemapping is rarely a good idea anyway (hence my WHY!?!? note at the end, lol), but may as well see if we can get it to work within the vaapi context.

Ah, I see. Maybe it's best just to store a copy of the movies in 1080p or 720p for transcoding purposes instead of trying to transcode 4K on the fly? Or what would be the proper way of tonemapping and then saving the file, and would Emby know to use that file?

 

Using the command with format=nv12 fails with the same error unfortunately :/.

Link to comment
Share on other sites

Waldonnis

Ah, I see. Maybe it's best just to store a copy of the movies in 1080p or 720p for transcoding purposes instead of trying to transcode 4K on the fly? Or what would be the proper way of tonemapping and then saving the file, and would Emby know to use that file?

 

Using the command with format=nv12 fails with the same error unfortunately :/.

 

Yeah, storing two copies is usually better...and what I do here.  I even keep my 4k stuff in a separate library that only certain users have access to so that people like my mother (who only has a 1080p telly) won't accidentally pick the wrong version.  It's storage overkill, but until Emby knows how to transcode and tonemap 4k HDR->1080p Rec.709, it's the easier way to go for usability...and storage is cheaper than processor cycles for me.  I'm also not sure how Emby would pick which resolution to use as a source, given that I've seen a few threads where the 4k version was chosen and transcoded rather than picking a "closer to the target" resolution.  I've never tested it personally, though, so I just don't know.

 

And yeah, figured nv12 would be the same.  Hmmm, okay, let's see if one of the following works.  Neither can be used to actually output an easily-playable file (it would be Hi10P), but will tell me if it's a conversion issue or just a hardware copy-back problem:

/usr/bin/ffmpeg -ss 00:14:24 -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/renderD128 -i file:"input.mkv" -map 0:0 -codec:v:0 h264_vaapi -filter_complex "[0:3]scale=3840:2160:force_original_aspect_ratio=decrease[sub];hwdownload,format=yuv420p10le[vid];[vid][sub]overlay,format=nv12|vaapi,hwupload" -hide_banner -f null -

...or...

/usr/bin/ffmpeg -ss 00:14:24 -hwaccel vaapi -hwaccel_output_format yuv420p10le -vaapi_device /dev/dri/renderD128 -i file:"input.mkv" -map 0:0 -codec:v:0 h264_vaapi -filter_complex "[0:3]scale=3840:2160:force_original_aspect_ratio=decrease[sub];[0:0][sub]overlay,format=nv12|vaapi,hwupload" -hide_banner -f null -
Edited by Waldonnis
Link to comment
Share on other sites

bennycooly

 

Yeah, storing two copies is usually better...and what I do here.  I even keep my 4k stuff in a separate library that only certain users have access to so that people like my mother (who only has a 1080p telly) won't accidentally pick the wrong version.  It's storage overkill, but until Emby knows how to transcode and tonemap 4k HDR->1080p Rec.709, it's the easier way to go for usability...and storage is cheaper than processor cycles for me.  I'm also not sure how Emby would pick which resolution to use as a source, given that I've seen a few threads where the 4k version was chosen and transcoded rather than picking a "closer to the target" resolution.  I've never tested it personally, though, so I just don't know.

 

And yeah, figured nv12 would be the same.  Hmmm, okay, let's see if one of the following works.  Neither can be used to actually output an easily-playable file (it would be Hi10P), but will tell me if it's a conversion issue or just a hardware copy-back problem:

/usr/bin/ffmpeg -ss 00:14:24 -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/renderD128 -i file:"input.mkv" -map 0:0 -codec:v:0 h264_vaapi -filter_complex "[0:3]scale=3840:2160:force_original_aspect_ratio=decrease[sub];hwdownload,format=yuv420p10le[vid];[vid][sub]overlay,format=nv12|vaapi,hwupload" -hide_banner -f null -

...or...

/usr/bin/ffmpeg -ss 00:14:24 -hwaccel vaapi -hwaccel_output_format yuv420p10le -vaapi_device /dev/dri/renderD128 -i file:"input.mkv" -map 0:0 -codec:v:0 h264_vaapi -filter_complex "[0:3]scale=3840:2160:force_original_aspect_ratio=decrease[sub];[0:0][sub]overlay,format=nv12|vaapi,hwupload" -hide_banner -f null -

Oh nice, I didn't think of making a separate library just for 4K media...may have to do that now. I tested the two commands and the first one gave me this:

[matroska,webm @ 0x55db26cfa280] sub2video: using 3840x2160 canvas
[hwdownload @ 0x55db272d0c40] Invalid output format yuv420p10le for hwframe download.
[Parsed_hwdownload_1 @ 0x55db272c9880] Failed to configure output pad on Parsed_hwdownload_1
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:0
Conversion failed!

While the second command gave me this:

[hevc @ 0x55a6df2b9740] Failed to transfer data to output frame: -22.
Error while processing the decoded data for stream #0:0
Conversion failed!

Seems like ffmpeg and VA API really dislike 4K HDR content...

Link to comment
Share on other sites

Waldonnis

 

Oh nice, I didn't think of making a separate library just for 4K media...may have to do that now. I tested the two commands and the first one gave me this:

[matroska,webm @ 0x55db26cfa280] sub2video: using 3840x2160 canvas
[hwdownload @ 0x55db272d0c40] Invalid output format yuv420p10le for hwframe download.
[Parsed_hwdownload_1 @ 0x55db272c9880] Failed to configure output pad on Parsed_hwdownload_1
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:0
Conversion failed!

While the second command gave me this:

[hevc @ 0x55a6df2b9740] Failed to transfer data to output frame: -22.
Error while processing the decoded data for stream #0:0
Conversion failed!

Seems like ffmpeg and VA API really dislike 4K HDR content...

 

 

It probably likes it well enough, but getting the frames back out of the card's memory may not be supported that well (could be ffmpeg/libav's wrapper more than the driver).  Then again, I could also be me messing something up, since I can't test anything on Linux right now and don't have hevc decoding hardware locally either.

 

I suspect this is more of a driver/API problem than anything, though.  We could try more pixel formats (p010le would be another choice), but it seems to have issues translating the hardware surface format into something usable by the software filters.  If the decoded frame data was kept on the card and piped directly to the hardware encoder (like you did by eliminating the filter and changing the output format), then everything will work swimmingly, but if any software operation is needed, like sub overlays or scaling, it's going to fall apart because we can't get the decoded frames back out of memory.  Of course, the "nuclear option" would be to software decode, do the filtering, then hwupload the frames to the card for encoding, but you'd see a definite load impact as the decoding isn't as easy for 2160p HEVC compared to something like 1080p h.264.

 

I'll think about it, though.  In the meantime, think about the 4k-only library idea.  Even if transcoding 4k HDR videos worked well, it's probably still not something you would prefer to do unless you had no choice simply because of the system load involved.  Isolating the 4k videos to users/situations that know when (or when not) to choose 4k playback makes it easier to save people from themselves...and saves you some "why isn't this working???" calls.  The only quirk of a separate library is that you would see two entries for a movie (one 4k, one non) when browsing on an account with access to the 4k library.  With proper treatment of the poster image (via CoverArt or just doing it manually) and appending something like "(4k)" to the title, they're easy enough to differentiate, though.

Link to comment
Share on other sites

bennycooly

It probably likes it well enough, but getting the frames back out of the card's memory may not be supported that well (could be ffmpeg/libav's wrapper more than the driver).  Then again, I could also be me messing something up, since I can't test anything on Linux right now and don't have hevc decoding hardware locally either.

 

I suspect this is more of a driver/API problem than anything, though.  We could try more pixel formats (p010le would be another choice), but it seems to have issues translating the hardware surface format into something usable by the software filters.  If the decoded frame data was kept on the card and piped directly to the hardware encoder (like you did by eliminating the filter and changing the output format), then everything will work swimmingly, but if any software operation is needed, like sub overlays or scaling, it's going to fall apart because we can't get the decoded frames back out of memory.  Of course, the "nuclear option" would be to software decode, do the filtering, then hwupload the frames to the card for encoding, but you'd see a definite load impact as the decoding isn't as easy for 2160p HEVC compared to something like 1080p h.264.

 

I'll think about it, though.  In the meantime, think about the 4k-only library idea.  Even if transcoding 4k HDR videos worked well, it's probably still not something you would prefer to do unless you had no choice simply because of the system load involved.  Isolating the 4k videos to users/situations that know when (or when not) to choose 4k playback makes it easier to save people from themselves...and saves you some "why isn't this working???" calls.  The only quirk of a separate library is that you would see two entries for a movie (one 4k, one non) when browsing on an account with access to the 4k library.  With proper treatment of the poster image (via CoverArt or just doing it manually) and appending something like "(4k)" to the title, they're easy enough to differentiate, though.

 

Okay @@Waldonnis, I really appreciate your help and advice on this matter! So you're saying that this is probably related to an issue with the mesa VA API driver right? I will definitely use the 4k library idea, and I guess we'll see if hopefully sometime in the near future 4k hardware transcoding becomes more feasible.

Link to comment
Share on other sites

Waldonnis

Okay, I really appreciate your help and advice on this matter! So you're saying that this is probably related to an issue with the mesa VA API driver right? I will definitely use the 4k library idea, and I guess we'll see if hopefully sometime in the near future 4k hardware transcoding becomes more feasible.

 

That would be my guess, yes...at least in the absence of a thorough debugging session.  I've seen mentions of other Mesa limitations regarding HEVC decoding around the net, so it'll probably get sorted out in time as the implementation matures.  In my limited time with a Radeon-equipped machine recently, it seemed like AMD's API and de/encoding support was still rather basic even in Windows, so I'm sure they plan on expanding on it in the future to better compete with nVidia's and Intel's more flexible implementations.

Link to comment
Share on other sites

RanmaCanada

From what I've learned, 10bit 4k HEVC hardware transcoding on Intel processors requires a minimum of a Kabylake processor.  Even when downcoverting, due to the way it handles the decoding and encoding processes.

Link to comment
Share on other sites

Waldonnis

From what I've learned, 10bit 4k HEVC hardware transcoding on Intel processors requires a minimum of a Kabylake processor.  Even when downcoverting, due to the way it handles the decoding and encoding processes.

 

True, but that's only if you're using the models including the iGPU and trying to use their de/encoders.  You could still use a dGPU's de/encoders on older processors if you wanted, though.  That being said, this particular issue was about using a Radeon card's de/encoders with VA-API, so the CPU/iGPU capabilities are irrelevant in this case (it's all just memory copies to the CPU).

 

Where KL+ becomes important is when PlayReady 3.0 is required (DRM), but that's another issue altogether.

Link to comment
Share on other sites

RanmaCanada

It's very difficult to find any of this information on the web, as Intel doesn't exactly make it clear, so I do apologize if it appears I was thread jumping.  I wasn't sure what hardware OP was using for transcoding.

Link to comment
Share on other sites

Waldonnis

It's very difficult to find any of this information on the web, as Intel doesn't exactly make it clear, so I do apologize if it appears I was thread jumping.  I wasn't sure what hardware OP was using for transcoding.

 

No worries  :)   It is rather convoluted at first, since the hardware manufacturers and review sites seem to love just citing generic things like "HEVC" or only talking about the decoder side of things.  Probably the best way to tell what's supported is to work backwards from the video tech side (e.g. look up PureVideo for nVidia or QuickSync for Intel) and then try to match what generation of the hardware has the right feature set.  Really, using these hardware en/decoders this way isn't what they were primarily made for (usually decoding for watching video only and encoding for streaming game sessions), but they work well regardless.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...