Christian König wrote:
Am 18.10.2016 um 15:42 schrieb Andy Furniss:
Andy Furniss wrote:
Christian König wrote:
Am 18.10.2016 um 11:19 schrieb Andy Furniss: wrote:
From: Boyuan Zhang <>

cabac is only supported in the h264 main and higher

So shouldn't there be code allows it if the user space
doesn't set baseline?

I don't know how in gstreamer as it seems to try to use
b-frames if you use other than baseline which doesn't work.

With avconv it is possible to call main/high and set b-frames
to 0.

I know it's technically correct spec wise, but seems a shame
as it costs a fair bit in "free" efficiency.

On Windows the raptor game recording app produces files
flagged as high with cabac - but without b-frames.

The problem is that it can easily break decoders. CABAC is
simply not allowed in a stream flagged as baseline compliant.

But with ffmpeg/avconv I can make a stream flagged as main/high
even if it's really baseline + CABAC. I guess Windows may vary
but the test I did seems to take this pragmatic approach, as it
seems do other h/w encoders eg. smartphone output.

It's a pity that we don't support B-frames any more.

Anymore? Now I am curious, seems to work with omx (cqp single

With that in place we could easily advertise support for
mainline profile.


Sorry if that came over as being pedantic, silly as I think
pragmatism is the way to go and I know intel advertise main/high,
but doubt they do interlaced.

Exactly, I mean we are talking about features to support encoding
into interlaced format. Is anybody still actively doing that?

Well, broadcasters, but I guess "users" never did anyway.

But even then, it's not so much of a problem advertising mainline
profile and then not using MBAFF/PAFF.

But when you advertise B-frames and then can't encode it you got a
serious problem because your frames are not in the right order any
more :)

Yea, it's a shame - was there a reason that b-frame support was abandoned?

In fact vce vaapi is currently advertising them as well (I did
mention it in some thread). Good for letting ffmpeg flag as such
while not using b-frames, not so good for gstreamer as they have
changed the default to high so old command lines will not
explicitly fail, but will produce junk.

I see va.h has a cabac switch and gstreamer exposes it - though
it's not read by the driver. Maybe if that were hooked up then
users could turn it on and profit :-).

Yeah, but again turning it on while the SPS/PPS only advertise the
stream to be baseline compliant is a clear violation of the codec
standard. (Is that actually encodeable in the stream? or does the
encoder switch to some higher level automatically if you use it?).

I was wrong about va.h having a switch, it was something different.

gst-inspect-1.0 vaapih264enc shows it has one - I don't what if anything
it actually does.

I am not trying to say here that flagging as constrained baseline and
using CABAC is in any way correct/legal. It just seems a shame to loose
CABAC = 10-20% less bitrate "for ever".

Looking at phone vids and vce from windows they get to use CABAC while
not using b-frames by flagging as main/high. It would be good if there
were a way to allow Linux vce to be the same.

I don't know how - if you can only advertise baseline, other than user
apps quirking their behavior depending on driver name, which I guess
some do any way.

Regards, Christian.


Signed-off-by: Boyuan Zhang <> ---
src/gallium/state_trackers/va/picture.c | 1 - 1 file
changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c index
eae5dc4..db08a3c 100644 ---
a/src/gallium/state_trackers/va/picture.c +++
b/src/gallium/state_trackers/va/picture.c @@ -110,7 +110,6
@@ getEncParamPreset(vlVaContext *context)
context->desc.h264enc.motion_est.enc_ime2_search_range_y =

//pic control preset -
context->desc.h264enc.pic_ctrl.enc_cabac_enable =
context->desc.h264enc.pic_ctrl.enc_constraint_set_flags =

//rate control

_______________________________________________ mesa-dev
mailing list

mesa-dev mailing list

Reply via email to