[Bug 105277] ffmpeg using radeonsi vaapi on Polaris21 RX560 creates h264 steams not playable by gstreamer & hw players
https://bugs.freedesktop.org/show_bug.cgi?id=105277
Bug ID: 105277 Summary: ffmpeg using radeonsi vaapi on Polaris21 RX560 creates h264 steams not playable by gstreamer & hw players Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: hojuruku@gmail.com QA Contact: dri-devel@lists.freedesktop.org
Created attachment 137664 --> https://bugs.freedesktop.org/attachment.cgi?id=137664&action=edit Royalty free big buck bunny 30 second video file corrupted by mesa-git ;)
This ticket relates to a comment on a closed bug: https://bugs.freedesktop.org/show_bug.cgi?id=104920#c3
Hardware required to replicate: RX560, sys-kernel/linux-firmware-20180213::gentoo, ATOM BIOS: 113-C98121-M01, amd-staging latest kernel & mesa-git.
There is some corruption when creating mkv,mp4 or any container in ffmpeg/ffmpeg-git using vaapi to encode. When I used libx264 with exactly the same settings as the encoder (no bframes, constrained baseline etc) the content is playable on hardware players and gstreamer, however when vaapi is used to use the encoding the content is scrambled on hardware players (TCL TV) and gstreamer's qtdemux can not parse the stream. vlc's player always skips the first two frames too.
The error exists regardless of the scale filter, I was originally testing on much higher bitrate source material.
Sample video file used: https://download.blender.org/peach/bigbuckbunny_movies/
What works with gstreamer/totem & hw players (x264 not relating to mesa) ffmpeg-git -hwaccel vaapi -hwaccel_output_format vaapi -t 30 -i big_buck_bunny_720p_surround.avi -vf scale_vaapi=w=1366:h=768,hwdownload,format=nv12 -c:v libx264 -b:v 2000k -coder:v 0 -bf 0 -profile:v baseline -level 3.1 -c:a aac -ac 2 -b:a 128k -ar 48000 -movflags +faststart -x264-params opencl x264test.mp4
What doesn't:
ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -t 30 -i big_buck_bunny_720p_surround.avi -vf scale_vaapi=w=1366:h=768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -profile:v constrained_baseline -movflags +faststart -quality:v 0 -level:v 3.1 -coder:v cavlc -c:a aac -ab 128k -ar 48000 -ac 2 vaapitest.mp4
Comparing the output of ffprobe -show_format -show_streams shows the files are nearly identical.
diff x264test.txt vaapitest.txt 27,28c27,28 < is_avc=true < nal_length_size=4 ---
is_avc=false nal_length_size=0
37c37 < bit_rate=2142956 ---
bit_rate=2153505
102c102 < filename=x264test.mp4 ---
filename=vaapitest.mp4
109,110c109,110 < size=8535782 < bit_rate=2274540 ---
size=8575301 bit_rate=2285071
I am using amd-gpu-staging-next from 2 days ago 4.15-rc4 after the old powerplay cleanup commit, and mesa-git from today.
https://bugs.freedesktop.org/show_bug.cgi?id=105277
Luke McKee hojuruku@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |x86-64 (AMD64) OS|All |Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=105277
--- Comment #1 from Julien Isorce julien.isorce@gmail.com --- Maybe related issue: https://bugzilla.gnome.org/show_bug.cgi?id=793836
https://bugs.freedesktop.org/show_bug.cgi?id=105277
--- Comment #2 from Luke McKee hojuruku@gmail.com --- I have just found out the source material being matroska avc stream going in is triggering the copyrighted content is required to replicate it. The big buck bunny transcoded file works fine on totem I just found out. I assumed it would be broken too. I'll attach 10 seconds of a my little pony blueray corrupted file I transcoded for my daughter that breaks totem / hardware players, and because it was created with x264/mkvmerge I'll include the source materials encoding settings below to replicate the defect. I think only 10 seconds would be fair use. Encoded with exactly the same parameters as above.
https://mega.nz/#!nqISgDLA!rvGIBMI8wCYBL7An4Fi9Az3VCINu3AvKxOMgj5f_gQo 2.6mb vaapitest2.mkv
General
Format : Matroska Format version : Version 4 / Version 2 File size : 4.37 GiB Duration : 1 h 39 min Overall bit rate : 6 302 kb/s Encoded date : UTC 2017-12-30 18:42:40 Writing application : mkvmerge v8.5.2 ('DiAMOND') 64bit Writing library : libebml v1.3.3 + libmatroska v1.4.4
Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings : CABAC / 5 Ref Frames Format settings, CABAC : Yes Format settings, ReFrames : 5 frames Codec ID : V_MPEG4/ISO/AVC Duration : 1 h 39 min Bit rate : 5 531 kb/s Width : 1 920 pixels Height : 808 pixels Display aspect ratio : 2.40:1 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.149 Stream size : 3.75 GiB (86%) Writing library : x264 core 152 r2851 ba24899 Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=24 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=5531 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00 Language : English Default : Yes Forced : No
Audio ID : 2 Format : DTS Format/Info : Digital Theater Systems Codec ID : A_DTS Duration : 1 h 39 min Bit rate mode : Constant Bit rate : 768 kb/s Channel(s) : 6 channels Channel positions : Front: L C R, Side: L R, LFE Sampling rate : 48.0 kHz Frame rate : 93.750 FPS (512 SPF) Bit depth : 24 bits Compression mode : Lossy Stream size : 545 MiB (12%) Language : English Default : Yes Forced : No
Text #1 ID : 3 Format : UTF-8 Codec ID : S_TEXT/UTF8 Codec ID/Info : UTF-8 Plain Text Title : English regular Language : English Default : No Forced : No
Text #2 ID : 4 Format : UTF-8 Codec ID : S_TEXT/UTF8 Codec ID/Info : UTF-8 Plain Text Title : English SDH Language : English Default : No Forced : No
https://bugs.freedesktop.org/show_bug.cgi?id=105277
--- Comment #3 from Luke McKee hojuruku@gmail.com --- (In reply to Julien Isorce from comment #1)
Maybe related issue: https://bugzilla.gnome.org/show_bug.cgi?id=793836
You may be right. That shows you gst can't play back content it encoded itself using vaapi on amd's. I was using ffmpeg. This shows the ball is in #drm-devel's court.
gst-play-1.0 vaapitest2.mp4 Press 'k' to see a list of keyboard shortcuts. Now playing /mnt/tmp/movies/vaapitest2.mp4 ERROR This file contains no playable streams. for file:///mnt/tmp/movies/vaapitest2.mp4 ERROR debug information: /var/tmp/portage/media-libs/gst-plugins-good-1.12.4/work/gst-plugins-good-1.12.4/gst/isomp4/qtdemux.c(703): gst_qtdemux_post_no_playable_stream_error (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0: no known streams found Reached end of play list
I'll try encoding with gstreamer-1.0 and update the ticket.
https://bugs.freedesktop.org/show_bug.cgi?id=105277
--- Comment #4 from Luke McKee hojuruku@gmail.com --- (In reply to Julien Isorce from comment #1)
Maybe related issue: https://bugzilla.gnome.org/show_bug.cgi?id=793836
No it's working fine here with gst-play-1.0 using omx (i hacked the priorities in gstreamer to use omx decoding over vaapi). (media-plugins/gst-plugins-omx-1.12.4)
So now more testing for good luck.....
<10 mins later>
I'll attach a gstreamer debug log for playing that file with omx,vaapi, and xv/ffmpeg if you are curious. That proves 100% this issue isn't related to that bug at all.
That ticket was a vaapi decoding issue. The test vector they uploaded also plays here without problems with gstreamer 1.12.4. totem seems to crash on it though but it's probably something to do with clutter and a very short file.
I made a longer file with this: gst-launch-1.0 videotestsrc pattern=blink num-buffers=30 ! video/x-raw, framerate=30/1 ! x264enc key-int-max=1 ! mp4mux faststart=true movie-timescale=300 trak-timescale=30 ! filesink location=i-frames-non-frag.mp4
https://bugs.freedesktop.org/show_bug.cgi?id=105277
Luke McKee hojuruku@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hojuruku@gmail.com
--- Comment #5 from Luke McKee hojuruku@gmail.com --- Created attachment 137670 --> https://bugs.freedesktop.org/attachment.cgi?id=137670&action=edit gst-play-1.0 debug log using VAAPI - gstreamer bug #793836 is not at play.
I also have similar logs for xv,omx - works fine here.
gst-plugins-vaapi here is of course merged without egl support btw, because I don't think that's working yet with amd & mesa.
https://bugs.freedesktop.org/show_bug.cgi?id=105277
--- Comment #6 from Luke McKee hojuruku@gmail.com --- #ffmpeg dev jkqxz suggested i check a few things.
ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -t 60 -i pony.mkv -map 0:0 -vf scale_vaapi=w=1366:h=768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -profile:v constrained_baseline -sn -quality:v 0 -level:v 3.1 -coder:v cavlc -an -sn vaapitest3-intermediate.h264; ffmpeg-git -i vaapitest3-intermediate.h264 -t 60 -i pony.mkv -map 0:0 -map 1:1 -vcodec copy -movflags +faststart -c:a aac -ab 128k -ar 48000 -ac 2 -sn vaapitest3.mp4
ffmpeg said this: "[mp4 @ 0x55a35c67acc0] Timestamps are unset in a packet for stream 0 (the video stream created by mesa-git vaapi). This is deprecated and will stop working in the future. Fix your code to set the timestamps properly"
^^^ Is this our problem?
This above creates an A/V file that is still broken. We let ffmpeg mux stream to a container after it is created to see if it was a container problem.
Another test: ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -ss 120 -t 10 -i rep-mylittleponythemovie.2017.1080p.bluray.x264.mkv -vf scale_vaapi=w=1366:h=768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -profile:v constrained_baseline -quality:v 0 -level:v 3.1 -coder:v cavlc -an vaapitest5-intermediate.h264; ffmpeg -i vaapitest5-intermediate.h264 -c:v copy vaapitest5.mp4
creates a file that is playable by gstreamer with no audio.
Now I've tested vaapitest[2,3,5].mp4 on a hardware player. The results are presently surprising for me. I've found a workaround for what I set out to achieve - to hardware encode for a tv with a usb socket. Now to set up a usb gadget mode on the router ;)
vaapitest2.mp4 (the mega.nz shared file) doesn't play on hardware player ""not supported" or gstreamer/totem. vappitest3.mp4 (plays on the hardware player! but not gstreamer!) vaapitest5.mp4 (plays on both, but hardware player prints warning about only one stream the whole time it's playing - no audio) All 3 are playable my ffmpeg / chromium.
I suggest the devs look into how timestamps are handled by the h264 stream and please keep up the good work towards getting h265 working!
This may also be a possible thing to check: "<jkqxz> The Mesa VAAPI implementation doesn't support packed headers, so you end up with no extradata in the file if you mux directly to mp4 or other format with global headers."
Please leave the ticket open. There is still something broken here, but this explains why this slipped through functional testing.
I have a haswell with integrated graphics so I will repeat the tests using intel's vaapi implementation with the same encoding settings to see if the intel vaapi encoded streams are broken too in the coming days.
https://bugs.freedesktop.org/show_bug.cgi?id=105277
--- Comment #7 from Luke McKee hojuruku@gmail.com --- Final note before I wash my hands of this matter and leave it to the devs to fix.
I also just tried this with the new main / high profile options and cabac enabled that is now available in the more bleeding edge amd kernels / mesa / libva / ffmpeg.
The breakage on the hardware player and gstermer qtdemux still applies.
new h265 vaapi support is dangerous too. https://bugs.freedesktop.org/show_bug.cgi?id=103953#c7
https://bugs.freedesktop.org/show_bug.cgi?id=105277
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #8 from GitLab Migration User gitlab-migration@fdo.invalid --- -- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1306.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org