On Fri, Nov 07, 2014 at 09:12:03AM +0100, Lukasz Marek wrote: > On 6 November 2014 22:55, Michael Niedermayer <michae...@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.lu...@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
> ffmpeg_opt.c | 4 ++++ > 1 file changed, 4 insertions(+) > e5b2af2c3acface30f9c71a326ffb7d907353b6b > 0001-ffmpeg_opt-free-incorrect-priv_data-for-feed-stream.patch > From 9d3188dd3fadfad47ef4cbe2073604d4cd7ebdc2 Mon Sep 17 00:00:00 2001 > From: Lukasz Marek <lukasz.m.lu...@gmail.com> > Date: Fri, 7 Nov 2014 09:05:41 +0100 > Subject: [PATCH] ffmpeg_opt: free incorrect priv_data for feed stream > > 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.lu...@gmail.com> applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
