[Bug 105277] ffmpeg using radeonsi vaapi on Polaris21 RX560 creates h264 steams not playable by gstreamer & hw players

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 2975 bytes --]

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3920 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel