Commen=
t # 6
on bug 10527=
7
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=3Dw=3D1366:h=3D768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -pro=
file: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 strea=
m 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"
^^^=20
Is this our problem?
This above creates an A/V file that is still broken. We let ffmpeg mux stre=
am
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=3Dw=3D1366:h=3D768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -pro=
file:v
constrained_baseline -quality:v 0 -level:v 3.1 -coder:v cavlc -an
vaapitest5-intermediate.h264; ffmpeg -i vaapitest5-intermediate.h264 -c:v c=
opy
vaapitest5.mp4=20
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 &q=
uot;"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 he=
aders, so you
end up with no extradata in the file if you mux directly to mp4 or other fo=
rmat
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.