Bug #5465
Vaapi hevc video transcoding via AMDGPU (Radeon) not working
0%
Description
Get only audio streams - no video stream (please see attached pictures -> VLC codec information + TVH transcode configuration):
2018-12-29 10:01:14.675 http: 192.168.x.x: using ticket fde4f6ab9983942dff17775f1f2ae0999252761c for /stream/channel/b5d1d3dbb632ec583e80b39723587dbd
2018-12-29 10:01:14.675 mpegts: 12265.5H in ASTRA - tuning on SAT>IP DVB-S Tuner #2 (192.168.x.x@UDP)
2018-12-29 10:01:14.675 subscription: 0009: "HTTP" subscribing on channel "ARD-alpha", weight: 100, adapter: "SAT>IP DVB-S Tuner #2 (192.168.x.x@UDP)", network: "ASTRA", mux: "12265.5H", provider: "ARD", service: "ARD-alpha", profile="hevc_vaapi", hostname="192.168.x.x", username="x", client="VLC/3.0.4 LibVLC/3.0.4"
2018-12-29 10:01:14.942 transcode: 0005: 01:MPEG2VIDEO: > Using profile hevc_vaapi
2018-12-29 10:01:14.942 transcode: 0005: 02:MPEG2AUDIO: > Copy
2018-12-29 10:01:14.942 transcode: 0005: 03:MPEG2AUDIO: > Copy
2018-12-29 10:01:14.942 transcode: 0005: 05:AC3: > Copy
2018-12-29 10:01:14.942 transcode: 0005: 06:DVBSUB: ==> Filtered out
2018-12-29 10:01:15.438 libav: AVCodecContext: Driver does not support some wanted packed headers (wanted 0xd, found 0).
2018-12-29 10:01:20.309 libav: AVFormatContext: Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
2018-12-29 10:01:20.310 libav: AVFormatContext: Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
2018-12-29 10:01:20.310 libav: AVFormatContext: Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
It also fails on h.264 encoded input streams.
FFMPEG spawn (actual snapshot) is working properly.
Please let me know how to provide more information.
Files
History
Updated by D. W. almost 6 years ago
Updated by The ffmpeg spawn call is:
/usr/bin/ffmpeg -vaapi_device /dev/dri/renderD128 -i pipe:0 -vf 'format=nv12,hwupload,scale_vaapi=w=1920:h=1080' -c:v hevc_vaapi -qp 25 -c:a ac3 -b:a 128k -f mpegts pipe:1
I have to define -f mpegts to get it working.
Updated by D. W. almost 6 years ago
- File tvh_transcode.log tvh_transcode.log added
Attached the trace of libav,transcode,vaapi.
I compared this log to one of functional h264_vaapi transcoding and found nothing exceptional...
From libav side the transcoding seems to work, but no stream is delivered...
Please have a look and come back to me.
Updated by D. W. almost 6 years ago
I traced a little bit more (parser,hevc,muxer,pass,mkv,libav,transcode,tsdebug,codec,vaapi) and saw the encoded frames get not muxed (using matroska/av-lib):
H.264 reading:
2019-01-03 18:36:00.799 [ TRACE]:parser: vparam 01: w=1280 h=720 d=1800 (old w=1280 h=720 d=1800 meta=0)
2019-01-03 18:36:00.799 [ TRACE]:parser: deliver (pkt stream 1 H264 type P pcr 5472905849 dts 5472954775 pts 5472963775 dur 1800 len 57701 err 0)
H.265 encoding:
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: nal_unit_type: 9, nal_ref_idc: 0
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: nal_unit_type: 6, nal_ref_idc: 0
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: nal_unit_type: 1, nal_ref_idc: 3
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: ct_type:0 pic_struct:0
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Param buffer (type 0, 672 bytes) is 0x4b.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Param buffer (type 1, 240 bytes) is 0x4c.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Slice 0 param buffer (3128 bytes) is 0x4d.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Slice 0 data buffer (57680 bytes) is 0x4e.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Decode to surface 0x1d.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Encode frame: 1280x720 (1024762).
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Pictures:
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: P (524/524)
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: P (525/525)
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext:
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Issuing encode for pic 525/525 as type P.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Refers to:
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: 524/524
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: .
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Input surface is 0x1e.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Recon surface is 0x47.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Output buffer is 0x4a.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Param buffer (23) is 0x4b.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Param buffer (24) is 0x4c.
2019-01-03 18:36:00.799 [ DEBUG]:libav: AVCodecContext: Sync to pic 525/525 (input surface 0x1e).
2019-01-03 18:36:00.808 [ DEBUG]:libav: AVCodecContext: Output buffer: 15968 bytes (status 00000000).
2019-01-03 18:36:00.808 [ DEBUG]:libav: AVCodecContext: Output read for pic 525/525.
Matroska muxing (example):
2019-01-03 18:36:00.818 [ DEBUG]:libav: AVFormatContext: Writing block at offset 15310, size 1792, pts 10902, dts 10902, duration 32, keyframe 1
I only get traces including audio packet sizes like size 1792 (input size = output size = copy).
No bigger blocks like 15968 bytes containing video data.
I compared this to working h264_vaapi transcoding traces and only found following difference in libav encoding trace:
H.265 encoding:
2019-01-03 18:36:00.808 [ DEBUG]:libav: AVCodecContext: Output buffer: 15968 bytes (status 00000000).
H.264 encoding:
2019-01-03 18:33:39.408 [ DEBUG]:libav: AVCodecContext: Output buffer: 84768 bytes (status 24000850).
Maybe this helps - please come back to me for helping to fix the issue.
Updated by Jaroslav Kysela almost 6 years ago
Updated by It seems that the problem is this:
libav: AVCodecContext: Driver does not support some wanted packed headers (wanted 0xd, found 0).
No ETA for a fix on my side.
Updated by D. W. almost 6 years ago
I'm not sure, if this is the problem, I also get a similar message when using h264_vaapi via transcoding and there is no video stream missing:
2019-01-08 17:04:36.083 transcode: 0002: 01:H264: > Using profile h264_vaapi
2019-01-08 17:04:36.083 transcode: 0002: 02:MPEG2AUDIO: > Copy
2019-01-08 17:04:36.083 transcode: 0002: 03:MPEG2AUDIO: > Copy
2019-01-08 17:04:36.083 transcode: 0002: 06:AC3: > Copy
2019-01-08 17:04:36.083 transcode: 0002: 05:DVBSUB: ==> Filtered out
2019-01-08 17:04:37.218 libav: AVCodecContext: B frames are not supported (0x1) by the underlying driver.
2019-01-08 17:04:37.218 libav: AVCodecContext: Warning: some packed headers are not supported (want 0xd, got 0).
2019-01-08 17:04:37.308 libav: AVFormatContext: Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Updated by Jaroslav Kysela almost 6 years ago
Ok, I tried to update to ffmpeg-4.1. Please, retest with the latest.
Updated by D. W. almost 6 years ago
Tried with with latest TVH master (ffmpeg-4.1) - no video stream.
Additionaly I compiled TVH with newest ffmpeg-snapshot and tried - no video stream.
Some days ago I had a look to the TVH parser_hevc.c and compared to the latest libav version of hevc.c (commit dc40e64adb1712b1209c018914a44f809bc32664) and patched the changes made there - also no video stream.
The problem is, no error seems to get thrown or given back, everything is looking fine, but no video stream....
Any suggestions where to have a closer look on for resolving ?
Updated by Evren Yurtesen about 5 years ago
Updated by I have the same problem I think.
https://tvheadend.org/boards/5/topics/39632
Did you ever get it to work?
Updated by D. W. about 5 years ago
No, I didn't.
Spawn is working, but TVH build in amdgpu vaapi hevc transcoding is not.
Updated by Stefan Dietzel about 5 years ago
Updated by 
You can build tvheadend with nonstatic ffmpeg and try if this works.
Parameters for nonstatic compilation:
--disable-ffmpeg_static --disable-libffmpeg_static --enable-libx264 --enable-libx265 --enable-vaapi --enable-libfdkaac --disable-libx264_static --disable-libx265_static --disable-libfdkaac_static --disable-libvorbis_static --disable-libtheora_static --disable-libvpx_static --disable-libopus_static
Updated by Evren Yurtesen about 5 years ago
Stefan, I already tried it. The version from Michael Marley's PPA for Ubuntu is compiled non-static. Then I tried to compile it static and it still did not work. See 2 posts above to link to my forum thread.
D.W. I have another problem with ffmpeg when I use VAAPI. It does change the Aspect Ratio (AR) of the video, or it removes the AR setting. When I playback the recorded stream, it looks strange as it plays with some default ratio. If I use libx265 with ffmpeg, then there is no problem. So... do I hate hardware encoding? Probably 
Are you not seeing the same problem?
Here are the relevant ffmpeg tickets about this problem.:
https://trac.ffmpeg.org/ticket/6276
https://trac.ffmpeg.org/ticket/8376
Unfortunately ffmpeg people seem to favor Nvidia based ticket. 
Updated by Evren Yurtesen about 5 years ago
Also I recently realized its not good idea to watch movie on same PC using KODI while FFMPEG is doing transcoding with spawn. It caused an endless stream of
[drm:amdgpu_cs_ioctl [amdgpu]] ERROR Failed to initialize parser -125!
errors...
Updated by Evren Yurtesen about 5 years ago
Jaroslav Kysela wrote:
No ETA for a fix on my side.
What can we do to help or motivate for a fix?
It looks like similar to this issue
https://github.com/ammen99/wf-recorder/issues/13
Here is solution leading to fix:
https://github.com/ammen99/wf-recorder/issues/13#issuecomment-494155345
Can it be related?