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

[Lukasz Marek]

On 6 November 2014 22:55, Michael Niedermayer <michaelni at gmx.at> wrote:

> 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
>

Probably you are not mistaken.
After sending I had second thoughts, probably it would be better to do one
of the followings:
- add option to muxer instead to control context should be read/write from
file (now is always written)
- export parsing function that is major part of read_header so ffmpeg can
pass its own context and params will be read. This has disadvantage that
ffmpeg would need ffm's private header. Already present in ffserver though.
- your solution


> 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
>

Yes, but maybe its time to clean hack and not to add new one. In new patch
I just clear possibly incorrect priv_data.
I will come back to during the weekend when I want to finish private
options handling in ffserver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ffmpeg_opt-free-incorrect-priv_data-for-feed-stream.patch
Type: text/x-patch
Size: 1152 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141107/af140a25/attachment.bin>