[FFmpeg-devel] [PATCH] ffmpeg_opt: set correct priv_data for feed stream

[Michael Niedermayer]

On Thu, Nov 06, 2014 at 09:27:45PM +0100, Lukasz Marek wrote:
> On 06.11.2014 01:32, Michael Niedermayer wrote:
> >On Thu, Nov 06, 2014 at 12:59:45AM +0100, Lukasz Marek wrote:
> >>new_output_stream creates a codec context with arbitraty picked codec.
> >>Later data is updated, but priv_data are left alone.
> >>There is a bit chance there is a mismatch between codecs.
> >>
> >>Signed-off-by: Lukasz Marek <lukasz.m.luki2 at gmail.com>
> >>---
> >>  ffmpeg_opt.c         | 16 ++++++++++++++++
> >>  libavformat/ffmdec.c |  6 ++++--
> >>  2 files changed, 20 insertions(+), 2 deletions(-)
> >
> >with this fate-lavf-ffm crashes
> >
> >==10836== Invalid write of size 8
> >==10836==    at 0x935442: decode_init (mpegaudiodec_template.c:419)
> >==10836==    by 0xA69226: avcodec_open2 (utils.c:1614)
> >==10836==    by 0x64CC5F: avformat_find_stream_info (utils.c:3053)
> >==10836==    by 0x41C2D7: open_input_file (ffmpeg_opt.c:886)
> >==10836==    by 0x42427A: open_files (ffmpeg_opt.c:2699)
> >==10836==    by 0x4243F8: ffmpeg_parse_options (ffmpeg_opt.c:2736)
> >==10836==    by 0x43762E: main (ffmpeg.c:3861)
> >==10836==  Address 0x10f072b0 is not stack'd, malloc'd or (recently) free'd
> >==10836==
> >==10836== Invalid write of size 8
> >==10836==    at 0xDC67D0: avpriv_float_dsp_init (float_dsp.c:120)
> >==10836==    by 0x93546B: decode_init (mpegaudiodec_template.c:421)
> >==10836==    by 0xA69226: avcodec_open2 (utils.c:1614)
> >==10836==    by 0x64CC5F: avformat_find_stream_info (utils.c:3053)
> >==10836==    by 0x41C2D7: open_input_file (ffmpeg_opt.c:886)
> >==10836==    by 0x42427A: open_files (ffmpeg_opt.c:2699)
> >==10836==    by 0x4243F8: ffmpeg_parse_options (ffmpeg_opt.c:2736)
> >==10836==    by 0x43762E: main (ffmpeg.c:3861)
> >==10836==  Address 0x10f072e8 is not stack'd, malloc'd or (recently) free'd
> >and pages more
> 
> I tried to debug it, but there is too much code to read to handle
> one very specific case and I'm not sure there is other, better
> solution.

> Probably, I haven't check, clear solution would be to clear
> priv_data in read_ffserver_streams right after copy_context, and set
> it to NULL, but I will need private data soon to support it in
> ffserver.

Maybe iam missing something but why does the ffm demuxer attempt to
setup a encoder instead of exporting the "recommanded" encoder
settings as name-value pairs (possibly in metadata) and ffmpeg then
sets up the encoder streams based on that instead of copying
contexts

Trying to set the encoder contexts up in a demuxer (which normally
would interface to decoders not encoders) seems odd to me
Though of course this is how it was designed before the patch already
...


[...]
> @@ -631,8 +636,23 @@ static int ffm_probe(AVProbeData *p)
>      return 0;
>  }
>  
> +#define OFFSET(x) offsetof(FFMContext, x)
> +#define ENC AV_OPT_FLAG_ENCODING_PARAM
> +static const AVOption options[] = {
> +    { "need_stream", "FFServer hack option, not to used by user", OFFSET(need_streams), AV_OPT_TYPE_INT, { .i64 = 0 }, INT_MIN, INT_MAX, ENC },

ENC should probably be 0 so as not to list the option in the
ffmpeg --help output and confuse users
if this is applied


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141106/7bdeaa5b/attachment.asc>