Opened 13 months ago

Last modified 13 months ago

#6478 new defect

Intel QSV: H.264 level is ignored

Reported by: alexpigment Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: intel, qsv, level, h264_qsv, h.264
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

For the h264_qsv encoder, specifying an H.264 level is quietly accepted (no errors or warnings) but not honored. Instead, the level is always automatically assigned.

Using Staxrip as a comparison, the Intel H.264 encoder does appear to support user-specified levels.

How to reproduce:

% ffmpeg -f lavfi -i smptebars -c:v h264_qsv -s 1920x1080 -aspect 16:9 -profile:v high -r 29.97 -t 5 -look_ahead 0 -level 4.1 output.mp4

See that the resulting video is reported as Level 4 in MediaInfo? rather than Level 4.1.

ffmpeg version N-86330-gbd1179e
built on 2017-06-01

Change History (5)

comment:1 Changed 13 months ago by heleppkes

The level is mostly a function of the bitrate and some other stream properties anyway, why do you specifically want to override it anyway?

comment:2 Changed 13 months ago by alexpigment

It's less about overriding it and more about enforcing it for hardware player compatibility. Ideally it would also cause bitrate limits to be enforced, but short of that, it's good to be able to set it since it's a supported feature of the encoder.

I do realize this is a very minor issue, but I'd like to see QSV be as feature-rich as libx264, and little things like this are all part of getting it to that level (in my opinion, anyway).

comment:3 Changed 13 months ago by DeHackEd

You have it backwards. The -level parameter is to constrain the parameters to meet a maximum, not to raise the parameters to meet a minimum. This is the "enforcement" of which you speak.

comment:4 in reply to: ↑ description Changed 13 months ago by jkqxz

From the code at <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/qsvenc.c;h=5eb506fb76224d48e19bc66d3dc67fe9a5c86184;hb=HEAD#l361> it looks like this works, though I've no idea whether libmfx will actually respect the level you pass in for encode.

However:

-level 4.1

This wants the level_idc value rather than the human-readable string name: try 41.

comment:5 Changed 13 months ago by alexpigment

jkqxz: I didn't realize it was looking for that sort of string. Thank you very much for point this out. Perhaps it should recognize 4.1 as well so that that people could use the same syntax from encoder to encoder.

DeHackEd?: No, that was my understanding as well. I realize that it was picking 4.0 in my case because it's not hitting a bitrate that would cause it to move into 4.1. I was just saying that ideally there would be bitrate limits tied to whatever level you choose, which unfortunately I hadn't been able to test until jkqxz clued me into the level_idc value thing. I can now confirm, however, that the bitrate limits don't seem to be in effect. The same is true for libx264 of course.

Note: See TracTickets for help on using tickets.