[FFmpeg-devel] [PATCH v3] * mpegts demuxer recognizes private streams on demand
wl-chmw at gmx.de
Thu Jun 11 22:21:50 CEST 2015
Am Wed, 10 Jun 2015 23:28:19 +0200
schrieb Michael Niedermayer <michaelni at gmx.at>:
> On Wed, Jun 10, 2015 at 10:41:10PM +0200, Wolfgang Lorenz wrote:
> > No answers?
> > Well, I do have a question.
> > Am Thu, 4 Jun 2015 23:46:21 +0200
> > schrieb Wolfgang Lorenz <wl-chmw at gmx.de>:
> > > The option went into the MpegTSContext struct and can be addressed via
> > > dictionary:
> > >
> > > AVFormatContext * formatContext = NULL;
> > >
> > > /* enable mpeg-ts private stream recognition */
> > > AVDictionary * dict = NULL;
> > > av_dict_set_int(&dict, "mpegts_recognize_private_streams", 1, 0);
> > >
> > > /* open file */
> > > avformat_open_input(&formatContext, fileName, NULL, &dict);
> > >
> > > [...]
> > While I have used some kind of name scoping for the dictionary access,
> > to avoid name clashes, I've seen, that this is not done for the rest of
> > the formats. I think in most cases, this won't matter anyway. There are
> > many doubling names between different input formats, but these won't
> > make a problem, as one format context can only contain one input
> > format. I've seen one name clash between AVFormatContext and an input
> > format ("auto", mov.c), and "strict" seems to be declared twice for
> constants have a scope limited to their type and field to which they
> > AVFormatContext. So, here's my question: Is there any kind of
> > convention for naming options? And should I rename my option to
> > "recognize_private_streams", or something different, to get the patch
> > accepted? Recommendations are welcome.
> i have no oppinon on the name, either is fine
> what kept me from applying this is that i dont see why it has to
> break detection of streams for which reliable detection exists,
> it breaks at least fate-acodec-s302m and fate-dca-core
Yes, I see your point here, and I agree with you. The last patch was
meant to not touch the default behaviour, though, as a user would have
to explicitly, deliberately and proactively (the last one was somewhat
exaggerated) tell the mpegts demuxer to assign type and id for data
streams. I wouldn't have considered this a breaking change.
> This should be a fallback for private streams which are not
> identified by a strong probing method
I guess, that would be the best solution.
> ill post a patch which will do this in a moment, please comment/test
Thank you. I'll have a look.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the ffmpeg-devel