Inconsistent x264enc in 1.1.4

Olivier Crête olivier.crete at collabora.com
Wed Sep 18 13:19:28 PDT 2013


Hi,

On Wed, 2013-09-18 at 11:54 +0200, Peter Maersk-Moller wrote:

> RAWVIDEO='video/x-raw, bpp=(int)32, depth=(int)32,
> endianness=(int)4321, format=(string)BGRA, red_mask=(int)65280,
> green_mask=(int)16711680, blue_mask=(int)-16777216, width=(int)1280,
> height=(int)720, framerate=(fraction)25/1,
> pixel-aspect-ratio=(fraction)1/1, interlaced=(boolean)false'

Just a side-note, the *_mask, bpp and depth don't exist anymore in 1.0,
this info is all contained in the format.


> All though it works, the similar pipeline for gstreamer-0.10 would
> encode main profile level 3.1 H.264 stream based on I420 input. Now
> with 1.1.4 the pipeline will by default for this setup encode the
> profile high-4:4:4, which is quite different. This is quite
> unexpected, but technically it may not be considered an error, but
> rather an annoyance. However it is a complexity that for sure will
> generate some problems for many because high-4:4:4 will not be
> supported on many players. High-4:4:4 is a rather advanced and complex
> little used (in the past) format. Furthermore, it is a bit unclear
> which high-4:4:4 profile this actually is, but more on that later.

Doing high-4:4:4 is voluntary, it tries to do the best profile it can
(see bug #708036 for discussion).

> gst-launch-1.0 -v videotestsrc is-live=true !\
>     $RAWVIDEO !\
>     videoconvert !\
>     x264enc tune=zerolatency !\
>     'video/x-h264, profile=(string)main' !\
>     fakesink

This failing is definitely a bug and a regression, I filed a blocker bug
for it.

https://bugzilla.gnome.org/show_bug.cgi?id=708326


-- 
Olivier Crête
olivier.crete at collabora.com



More information about the gstreamer-devel mailing list