[FFmpeg-user] H264 VAAPI Encoder

[Mark Thompson]

On 19/06/16 00:34, Andy Furniss wrote:
> Mark Thompson wrote:
>>
>> So, I also went and built mesa with the encode patches and had a go.  With the changes above, it does get to actually trying to encode, but that nuked my GPU to the point of requiring reboot.
> 
> Same here, I need both patches then it does encode but there are issues.
> 
>> With the linked patch you should be able to have a go too: if it works for you then I'm interested in what your setup is.  If it nukes your GPU then, well, you had some warning at least.  I think I'll wait until it's a bit more stable before pursuing this further.
> 
> I am using an R9 285 Tonga GPU. This uses the amdgpu kernel driver and is still not totally stable for uvd/vce.
> 
> The instability revolves around powerplay (which IIRC isn't enabled by default yet). I have test cases that will lock vce, but can avoid by not
> letting powerplay vary clocks = force them high.
> 
> What h/w is yours?

R7 360 (Bonaire, a Sea Island), so yours is one generation newer.  I am therefore using radeonsi, though I believe the back-end parts talking to UVD/VCE here are actually in common between the two drivers so it shouldn't be relevant?

> Below is output of a run  that produces corrupt video - I guess this is due to trying to use b frames
> but may be totally wrong :-)

Yeah.  The attempt to use B frames when they aren't supported means the frame referencing is all messed up.  When I tried with "-bf 0", it made a stream which decoded with no obvious artifacts (though somewhat weird, as noted previously).

> The same input OK encoded with gstreamer vaapi. In theory my card should
> do UHD, but there's a bug so I am limited smaller - older cards probably wouldn't even do this res.
> 
> The results are the same testing with normal SD input + format=nv12.

I only tried 1080p, and it was happy.  I believe that generation won't be able to do a bigger stream like the one you tested anyway.

> Here's what it looks like -
> 
> https://drive.google.com/file/d/0BxP5-S1t9VEEUDR4V01Rblp2dlk/view?usp=sharing
> 
> andy [vce-tests]$ time ffm -loglevel debug  -vaapi_device :0 -f rawvideo -framerate 50 -s 2560x1440 -pix_fmt nv12 -i /mnt/ramdisk/ducks-2560x1440.nv12 -vframes 20 -vf 'hwupload' -c:v h264_vaapi -profile:v 66 -b:v 40M  -y /mnt/ramdisk/out.mp4

Looks very similar to the streams I got, modulo the funniness around B frames.  I guess that's reassuring that it's not wildly different with different GPUs, at least.

On ref frames, it has max_ref_frames = 3 but only ever uses 1.  Unsure what to read into that.


On 19/06/16 00:43, Andy Furniss wrote:
> Mark Thompson wrote:
>> Ok, I tried a bit more (including a few power cycles), and it does work.  The critical extra step is to disable B-frames (that should probably happen automatically for baseline profile).  It then works with input uploaded from the CPU or from a decode on the GPU.
>>
>> For example: "./avconv -v 55 -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 66 -bf 0 -b 10M out.mp4".
>>
>> The bitstream it outputs does work in ffmpeg, but it's very weird.  It has CABAC enabled (not allowed in baseline), and the POC seems to only advance on every second frame (as if they were actually fields of an interlaced stream, except it isn't).
>>
>> So, yeah.  I think there is a lot more work to do before this is generally usable, but it is certainly working and I will keep testing it as more versions turn up.
>
> Ahh, good - I hadn't seen this mail before preparing/sending the other one :-(
>
> The cabac thing is interesting - I have previously noticed that mediainfo
> showed gstreamer vaapi as constrained but yes for cabac - but it also said 2 for ref frames when ffprobe called one.
>
> gstreamer omx files said no to cabac - I failed to find a way with ffmpeg/ffprobe to see if cabac was off/on - is there one??

Not that I know of.  I test this sort of thing by feeding streams into the reference decoder with trace enabled and reading the bitstream trace :/

> Also windows files get called as high, but I don't see any b frames
> though the only windows files I have were made with a game recording app that comes with the driver (raptr).

It will be the driver (or something further out) writing the headers rather than the hardware, so I don't regard it as surprising that the labelling of the profile is confused.


- Mark