[x264-devel] does not link lavf support

[Steven Walters]

You sure are quick to point fingers and haze...

On Tue, Jun 21, 2011 at 5:53 AM, Erik Slagter <erik at slagter.name> wrote:
>> oh, and av_open_input_file still crashes even with that indicated change.
>> specifying --input-res for your input should workaround the issue for now...
>
> ... and that doesn't fix the segfault anymore as well ...
>
> I must say I am a bit p****d at the moment, because of the whole history
> of libavcodec vs. x264 problems the last two weeks. I am not blaming the
> x264 devels but the feeling remains nevertheless.
>
> First we had the sws_format_name() function disappearing from libav*,
> which they had every right to because it was not in the public api. I
> was told to switch from "ffmpeg" to "libav" because in that fork the
> function had been enabled again ("and 'everybody' was using libav now,
> anyway"). So I did, x264 compiled again and it broke my other uses of
> ffmpeg(!)

sws_format_name was originally used during the original implementation
because libavutil/pixdesc.h could not be included because it
originally included headers that
were private to libavutil and were not installed, so there was no
other way to access the names of pixel formats at that time.

>
> Now we have the issue of x264 segfaulting, probably in libswscale. The
> workaround using --input-res has been working for 1 or 2 days and now it
> doesn't help as well.

> So I switched back to the ffmpeg fork, and exactly the same problem
> appears (segfault in libswscale).

The crash in av_input_open_file was due to the fact that x264cli
supplied a NULL AVFormatParameters (which is perfectly legal).
In the process of the deprecating the function to use
avformat_open_input instead, they (accidentally?) caused
av_input_open_file to crash from
trying to access and read the NULL pointer, i.e. there was no NULL check on it.
specifying --input-res was a workaround to have x264cli not provide a
NULL pointer here to av_input_open_file.

this issue has already been fixed in libav and ffmpeg: (libav's commit
was http://git.libav.org/?p=libav.git;a=commit;h=dbafb0e06faa092f60e53d845957fbab7f2a3f2d
) and ffmpeg's was around the same time afaik.

this is the first time I've heard of a libswscale crash, and why are
you blaming x264 for this?
have you looked at the stack trace? have you absolutely discerned that
x264 is at fault?
how about instead of screaming your head off, you supply some useful
information, such as all the facts necessary to reproduce it!

ffmpeg and lavf are not stable, there will be regressions and there
will be crashes.
If you can not take this in stride, use only the official releases and
stay away from the repositories.

> I'd be fine with using ffmpeg (the cli) instead of x264, BUT I can't use
> it because it doesn't call libx264 properly regarding to interlacing
> (suggested by one of devels here...)
>
> So I am stuck now, can't encode.
>
> AFAIK x264 is the only program that segfaults on the av_open_input_file
> (emulation), so imho something has been wrong on the x264 side for a
> long time, but it hadn't appeared before.

no, ffms2 had the same issue, lavf and ffmpeg simply broke
compatibility with the API when they originally deprecated it.
stop being so quick to point fingers!

> So PLEASE can someone have a look at this issue? I don't really care
> whether it's a patch to x264 or ffmpeg or libav, btw.
>
> Please CC.
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
>