On Fri, Sep 12, 2014 at 12:49:03PM +0200, wm4 wrote:
> On Fri, 12 Sep 2014 12:29:36 +0200
> Michael Niedermayer <michae...@gmx.at> wrote:
>
> > Suggested-by: Benoit Fouet <benoit.fo...@free.fr>
> > Signed-off-by: Michael Niedermayer <michae...@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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
