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 701513 - x264 encoder plugins uses uninitialised frame number
x264 encoder plugins uses uninitialised frame number
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
1.0.7
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-06-03 12:13 UTC by bilva
Modified: 2013-06-04 08:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description bilva 2013-06-03 12:13:46 UTC 
In gstx264enc.c :
function : gst_x264_enc_encode_frame()
a local variable is defined :

x264_picture_t pic_out;

After this definition, pic_out is passed to x264 encoder :

encoder_return = x264_encoder_encode (encoder->x264enc,
      &nal, i_nal, pic_in, &pic_out);

After this, pic_out is used is following line :

 frame = gst_video_encoder_get_frame (GST_VIDEO_ENCODER (encoder),
      GPOINTER_TO_INT (pic_out.opaque));

The X264 encoder doesn't touch the opaque data structure, so it remains uninitialised.
So, why are we trying to extract frame number from the uninitialised "opaque" member of pic_out?

It gives some garbage number.
Comment 1 Nicolas Dufresne (ndufresne) 2013-06-03 15:28:00 UTC 
(In reply to comment #0)
> The X264 encoder doesn't touch the opaque data structure, so it remains
> uninitialised.
> So, why are we trying to extract frame number from the uninitialised "opaque"
> member of pic_out?

x264_encoder_encode() is suppose to copy the opaque_pointer from the origin input structure. I've fixed this bug once in 0.10, so I'm wondering why we get that again. Last time, libx264 was at fault, so be increased the minmum required version.

The opaque pointer should always be initialize in the first place. This frame number is to match with locally stored frames (thus timestamps). The encoder do reordering, this is the reason we need that ID dance. Bug #701517 is most likely a duplicate.
Comment 2 bilva 2013-06-04 05:10:42 UTC 
Thank you for the explaination.
Due to some mis-configuartion older X264 version 119 was getting used in my setup.
I fixed that & now the issue is resolved.
Thanks again.
Comment 3 Tim-Philipp Müller 2013-06-04 08:07:06 UTC 
Thanks for confirming.

(Also, please don't mark bugs as 'blocker', that is something that should be left up to the release managers to decide.)