Comment # 6
on bug 105277
from Luke McKee
#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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
