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 403739 - ffenc_mpeg1/2video segfaults
ffenc_mpeg1/2video segfaults
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.2
Other Linux
: Normal normal
: 0.10.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-02-02 22:03 UTC by Mark Nauwelaerts
Modified: 2007-03-02 15:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Possible fix (926 bytes, patch)
2007-02-02 22:11 UTC, Mark Nauwelaerts
none Details | Review

Description Mark Nauwelaerts 2007-02-02 22:03:21 UTC
The following pipeline segfaults:
gst-launch-0.10 videotestsrc ! ffenc_mpeg2video ! fakesink

It segfaults within ffmpeg, apparently it does not have a taste for its own default avcodec setting of intra_dc_precision (8 btw) 
(see also patch).
Comment 1 Mark Nauwelaerts 2007-02-02 22:11:05 UTC
Created attachment 81788 [details] [review]
Possible fix

Prevents segfault by providing a "better" default for intra_dc_precision in 2 ways:
* as a safe default in any case
* by including mpeg1/2video in the family of mpeg derivatives, thereby getting a default from the set of parameters configured for these
[btw; the defaults for these parameters pretty much correspond to those of mencoder]
Comment 2 Edward Hervey 2007-03-02 11:55:31 UTC
more ffmpeg mysteries...

The backtrace is the following:

Program received signal SIGSEGV, Segmentation fault.

Thread 1082132800 (LWP 7667)

  • #0 ff_set_qscale
    at h263.c line 2517
  • #1 encode_thread
    at mpegvideo.c line 4904
  • #2 avcodec_default_execute
    at utils.c line 422
  • #3 MPV_encode_picture
    at mpegvideo.c line 5697
  • #4 avcodec_encode_video
    at utils.c line 895
  • #5 gst_ffmpegenc_chain_video
    at gstffmpegenc.c line 592
  • #6 gst_pad_chain_unchecked
    at gstpad.c line 3472
  • #7 gst_pad_push
    at gstpad.c line 3638
  • #8 gst_base_src_loop
    at gstbasesrc.c line 1600
  • #9 gst_task_func
    at gsttask.c line 199
  • #10 g_thread_pool_thread_proxy
    at gthreadpool.c line 265
  • #11 g_thread_create_proxy
    at gthread.c line 591
  • #12 start_thread
    from /lib/libpthread.so.0
  • #13 clone
    from /lib/libc.so.6
  • #14 ??


Looking deeper I can't see the relationship between setting proper intra_dc_precision and the fact that s->y_dc_scale_table has bogus value (here 0x1).
Comment 3 Edward Hervey 2007-03-02 12:05:41 UTC
Also, you say setting a default of 0 for intra_dc_precision is what mencoder does. According to the mencoder man page, the default is 8 (ffmpeg default value):

      dc
              intra DC precision in bits (default: 8).  If you specify vcodec=mpeg2video this value can be 8, 9, 10 or 11.

I'm commiting only the first part of the patch, which states mpeg1video and mpeg2video are part of the mpeg family since that makes sense and gets rid of the segfault.

If you can come with proof that the second part of the patch is really needed, please open a new bug with the affected encoders.

2007-03-02  Edward Hervey  <edward@fluendo.com>

	* ext/ffmpeg/gstffmpegcfg.c: (gst_ffmpeg_cfg_init):
	Add mpeg1video and mpeg2video to the list of mpeg-derivatives for
	configuration settings.
	Renamed the mpeg4 category to mpeg.
	Fixes #403739

Comment 4 Mark Nauwelaerts 2007-03-02 15:29:48 UTC
Well, it's fixed, so this is mainly "for the record" ;-)

(In reply to comment #2)
> Looking deeper I can't see the relationship between setting proper
> intra_dc_precision and the fact that s->y_dc_scale_table has bogus value (here
> 0x1).

I am admittedly not particularly knowledgeable in lower levels of encoding,
but at least both dc coefficient (precision) and q scale affect quality;
and it is imaginable (?) that y__dc_scale__table (setup) is somehow affected
by the precision/bits of dc coefficient (in ffmpeg then at least apparently ;-))

(In reply to comment #3)
> Also, you say setting a default of 0 for intra_dc_precision is what mencoder
> does. According to the mencoder man page, the default is 8 (ffmpeg default
> value):
> 
>       dc
>               intra DC precision in bits (default: 8).  If you specify
> vcodec=mpeg2video this value can be 8, 9, 10 or 11.

From avcodec.h:
    /**
     * precision of the intra dc coefficient - 8.
     * - encoding: set by user
     * - decoding: unused
     */
     int intra_dc_precision;

So, due to the - 8 shift, the user level default of 8 does correspond to setting intra_dc_precision = 0 (ah, ffmpeg ..., and we now also know that ffmpeg does not really set it to a default of 0 aka 8 (?), or it would not segfault)

> I'm commiting only the first part of the patch, which states mpeg1video and
> mpeg2video are part of the mpeg family since that makes sense and gets rid of
> the segfault.
Yes, it will, because the first part is sort of a superset of the second part.
By including it in the MPEG-family, intra_dc_precision is then one of the many parameters that gets a default (of 0 aka 8) in this case.

> If you can come with proof that the second part of the patch is really needed,
> please open a new bug with the affected encoders.
Either part of the patch by itself would fix it.
The second part is/was there for additional safety;
if ever one would feel like "playing" with the categories so that intra_dc_precision does not get a safe default anymore, there would be segfault (danger) again.  Hence, a hard-coded default = mencoder was provided.
As such, it is not needed for MPEGx in (the now) present setting, and have no proof forthcoming for other encoders, but it is likely a safe(r) default given mencoder's practice.