[FFmpeg-devel] [PATCH] Fix crash in libx264 when rc_eq is not set

[Stefano Sabatini]

On date Wednesday 2008-08-27 14:38:15 -0600, Loren Merritt encoded:
> On Wed, 27 Aug 2008, Stefano Sabatini wrote:
> >
> > Well... I could use the X264_BUILD to do something as
> >
> > #if X264_BUILD < 61
> >    if (avctx->rc_eq)
> >        x4->params.rc.psz_rc_eq = avctx->rc_eq;
> > #else
> >        av_log(avctx, AV_LOG_WARNING, "Ignoring the rc_eq set, using the libx264 default one\n");
> > #endif
> >
> > the problem with this is that it won't work anyway if the *linked*
> > library isn't the same of the version of the header. Ideally if were
> > available a function such as x264_build() then the abovementioned
> > if/else could be performed run-time, lacking that I believe the best
> > approach is the simplest and the more robust, so I'm for eliminating
> > the rc_eq use, but to warn the user about that.
> 
> If the library version isn't the same as the header version, it breaks 
> anyway, since I make no attempt to keep struct offsets constant. 
> X264_BUILD is the .so version number too.
> If I were to make a x264_build(), it would instead be used as 
> assert(x264_build()==X264_BUILD) to catch inconsistent installs slightly 
> more cleanly than segfault.

Yes please implement that function so that we can provide a more
robust support for it.

BTW this seems to be a bug in libx264:
stefano at geppetto ~> 
ffmpeg -i ~/test.flv -vcodec libx264 -rc_eq "foo" -t 1.0 -y outfile.mp4
FFmpeg version SVN-r14865, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --prefix=/home/stefano --disable-shared --enable-libschroedinger --enable-libx264 --enable-libxvid --enable-pthreads --enable-gpl --enable-debug=3 --enable-libtheora --enable-libvorbis --enable-avfilter --enable-libamr-nb --enable-libamr-wb --enable-nonfree --enable-libfaad --enable-libfaac --enable-x11grab --enable-libmp3lame --disable-optimizations --disable-mmx
  libavutil     49.10. 0 / 49.10. 0
  libavcodec    51.68. 0 / 51.68. 0
  libavformat   52.20. 0 / 52.20. 0
  libavdevice   52. 1. 0 / 52. 1. 0
  libavfilter    0. 1. 0 /  0. 1. 0
  built on Aug 20 2008 17:53:40, gcc: 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)

Seems stream 0 codec frame rate differs from container frame rate: 1000.00 (1000/1) -> 25.00 (25/1)
Input #0, flv, from '/home/stefano/test.flv':
  Duration: 00:00:30.01, start: 0.000000, bitrate: 96 kb/s
    Stream #0.0: Video: vp6f, yuv420p, 320x240, 25.00 tb(r)
    Stream #0.1: Audio: mp3, 44100 Hz, mono, s16, 96 kb/s
Output #0, mp4, to 'outfile.mp4':
    Stream #0.0: Video: libx264, yuv420p, 320x240, q=2-31, 200 kb/s, 25.00 tb(c)
    Stream #0.1: Audio: libfaac, 44100 Hz, mono, s16, 64 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
[libx264 @ 0x8792da0]using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
Press [q] to stop encoding
Parser: missing ( in "foo"
fish: Job 1, ?ffmpeg -i ~/test.flv -vcodec libx264 -rc_eq "foo" -t 1.0 -y outfile.mp4? terminated by signal SIGSEGV (Address boundary error)


Since no other one else expressed other opinions on this, I'm
attaching the solution above, which seemed to me the best compromise,
since it keeps the feature for older versions and shouldn't break when
the rc_eq support in libx264 will be dropped (at the next bump I
guess).

I'll apply it on Saturday if I hear no objections.

Regards.
-- 
FFmpeg = Furious Furious Magic Purposeless Eager God
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-libx64-rc-eq-crash-03.patch
Type: text/x-diff
Size: 750 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080829/e931f393/attachment.patch>