[FFmpeg-devel] [PATCH 1/2] avformat: add AVFMT_FILE to allow demuxers to be used with and without files

[Michael Niedermayer]

On Fri, Sep 12, 2014 at 12:49:03PM +0200, wm4 wrote:
> On Fri, 12 Sep 2014 12:29:36 +0200
> Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> > Suggested-by: Benoit Fouet <benoit.fouet at free.fr>
> > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > ---
> >  doc/APIchanges         |    3 +++
> >  libavformat/avformat.h |    8 ++++++++
> >  libavformat/format.c   |    3 ++-
> >  libavformat/version.h  |    4 ++--
> >  4 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 6d214ef..45ed60a 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil:     2014-08-09
> >  
> >  API changes, most recent first:
> >  
> > +2014-09-xx - xxxxxxx - lavf 56.5.100 - avformat.h
> > +  Add AVFMT_FILE
> > +
> >  2014-08-xx - xxxxxxx - lavc 56.1.0 - avcodec.h
> >    Add AV_PKT_DATA_STEREO3D to export container-level stereo3d information.
> >  
> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > index b915148..a95d702 100644
> > --- a/libavformat/avformat.h
> > +++ b/libavformat/avformat.h
> > @@ -446,6 +446,14 @@ typedef struct AVProbeData {
> >  
> >  #define AVFMT_SEEK_TO_PTS   0x4000000 /**< Seeking is based on PTS */
> >  
> > +#define AVFMT_FILE          0x8000000 /**< demuxer can be used with a file, this
> > +                                           is default if AVFMT_NOFILE is not set.
> 
> It's default, but it's not set? That's very strange.
> 
> > +                                           If AVFMT_NOFILE and AVFMT_FILE is set
> > +                                           then the demuxer can be used with and
> > +                                           without a file (so this flag makes
> > +                                           only sense together with AVFMT_NOFILE)
> 
> Very confusing. Without knowing the context (hack for img2 stuff) I
> wouldn't know what this means.
> 

> I think I would prefer the previous patch, which just special-cases
> image2. image2 probing should be fixed eventually, and it'd be better
> not to add strange API artifacts just because we're not there yet.



> 
> Also, not sure if I understand issue 3901 correctly. But shouldn't he
> gif detection be pretty reliable, and just override the jpg image2 one?

yes but gif is basically a movie format due to animated gifs, and not
a image one. That makes it different from the image2 formats

so its more like avi vs jpeg
jpeg can be specified as image%d.jpeg for a sequence of images and
this makes it inevitably different from a imgage.avi which is a url
that can be opened and passed to format probe functions

A key question to understand the issue also is that if you have
image%d.jpeg as input, will you try to open that litterally or always
treat it as image sequence.
if its opened literrally and if successsfull its probe score would
be compared to  the image sequence of image0.jpeg, image1.jpeg, ...
you would have a hard to predict behavior for the end user as with
a image%d.jpeg locally the user couldnt know if that or the
corresponding image sequence would be opened / have a higher probe
score.
Thus we end up with treating image%d.jpeg always as image sequence
and require escaping or some comand line option for opening the
single file with the %d in it.

But then we happen to have a bug and that is that image2 demuxers
return high probe scores for cases that arent image sequences and
before there is any file content available for other probe functions
like jpeg or gif to have had a chance to return a high score
Fixing this is a one liner basically but it uncovered multiple other
issues like that image2 probe is not run when data has been read so
it would never be compared to a non NOFILE demuxer

This makes the whole issue a bit convoluted but thats just how it is
i think either of the patchsets should be fine to fix this

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20140912/f054a298/attachment.asc>