[FFmpeg-user] H264 VAAPI Encoder

[Andy Furniss]

Mark Thompson wrote:
>
> On 19/06/16 00:34, Andy Furniss wrote:
>> Mark Thompson wrote:

>> 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?

Yea I am still radeonsi as far as mesa is concerned.

There seems to be several different vce versions in the driver files
and in kernel vce 2 and 3 are separate files.

>> 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).

Yea, it's a bit strange as b frames do get mentioned in the driver code
I don't know why they don't work, but at least someone is working on it
again. While just looking I saw a TODO for b frames on my h/w in
combination with dual pipe which it seems tonga has.

Disabling b-frames does produce good output for me with cbr (though
the POC issue is there and it's not there with gstreamer vaapi.

With both ffmpeg and gstreamer cpq has issues. With ffmpeg depending
on source it may produce unplayable output. With gstreamer it seems to
use qp=0.


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

Yea strange - again in the code there is apparently provision to use more.

>> 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 :/

I tried using the ref decoder, so I can now see this :-)

I also found some code that controls it and learnt a bit playing.

search cabac in mesa/src/gallium/drivers/radeon/radeon_vce.c

and it's there waiting to be changed - there are 2 places depending
on whether enable_low_level_control is true. For vaapi this is the one
and defaults on. For gst-omx it hits the other one default off.

I guess omx using the other one may go some way to explain why it is
3x faster than vaapi. It does make strange files though = 1 I frame
per 1000.


>> 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.

Yea, again though the code seems to have provision for different levels
and wikipedia claims VCE 2.0 supports b-frames + 444, so maybe baseline
is just because the code is unfinished.