[FFmpeg-devel] [PATCH v3] * mpegts demuxer recognizes private streams on demand

[Wolfgang Lorenz]

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

> thanks
> 
> 
> [...]
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150611/510b5871/attachment.asc>