After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 786433 - vaapih264enc: invalid VUI depending on input resolution
vaapih264enc: invalid VUI depending on input resolution
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
1.10.4
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-08-17 16:29 UTC by blaxar.waldarax
Modified: 2017-08-18 07:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description blaxar.waldarax 2017-08-17 16:29:42 UTC
When using vaapih264enc, the VUI descriptor in the resulting stream may be invalid depending on the input image resolution.

Let's consider the following command line:
$ gst-launch-1.0 videotestsrc num-buffers=60 ! video/x-raw, width=1280, height=720 ! vaapipostproc ! vaapih264enc ! mp4mux ! filesink location=test.mp4

Then, if we use ffprobe on the resulting mp4 file:
$ ffprobe test.mp4

We get the error "[h264 @ 0x12e3d40] Overread VUI by 8 bits"

However, with:
$ gst-launch-1.0 videotestsrc num-buffers=60 ! video/x-raw, width=640, height=360 ! vaapipostproc ! vaapih264enc ! mp4mux ! filesink location=test.mp4

We only get a warning from ffprobe: "[h264 @ 0x1388d40] Truncated VUI"

And finally, if we go full 1080p:
gst-launch-1.0 videotestsrc num-buffers=60 ! video/x-raw, width=1920, height=1080 ! vaapipostproc ! vaapih264enc ! mp4mux ! filesink location=test.mp4

We get no error or warning.

I've tried encoding videos using x264enc in comparison, I get no such issue.

While many video players seem to tolerate an invalid VUI descriptor, it's worth noting that others don't (like the Safari video player on iPad).
Comment 1 Hyunjun Ko 2017-08-18 00:33:09 UTC
Seems that this is same as #bug 778750
It's fixed since 1.12 :)
Comment 2 Víctor Manuel Jáquez Leal 2017-08-18 06:10:06 UTC
Confirmed, it is fixed in release 1.12

Please upgrade. A possible workaround for 1.10 is to use h264parse after the vaapih264enc.
Comment 3 blaxar.waldarax 2017-08-18 07:38:56 UTC
I'm taking note, thanks :)