[FFmpeg-devel] ByteIOContext probe + img2 patch

[Justin Foutts]

I found that if you create a test to read a .png via a custom AVIOContext wrapper around normal read, write, seek, it will fail.  This patch will make this test succeed on OSX or Linux.
The utils.c changes init_input() to use filename information with av_probe_input_format() first, then fall back to av_probe_input_buffer(), because av_probe_input_buffer() alone will fail to identify .png from its filedata. (An alternative is to swap the fallback order)
The img2.c changes are because the !s->is_pipe logic will always make filesystem calls. I tried changing the NOFILE logic and my .png's appeared!  However only .png's under 4096 bytes.  In img2.c I tried changing the 4096 constant to the avio_size() of the recently assigned f[0].  This happened to result in the rest of the images loading.
I must admit I don't know what I'm doing!  Some lucky guesses happened to work. I hope that someone who better understands this code will use this patch to increase the testing and support for custom AVIOContext's and img2's relation to same.  Thanks!

--- On Sun, 9/4/11, Michael Niedermayer <michaelni at gmx.at> wrote:

From: Michael Niedermayer <michaelni at gmx.at>
Subject: Re: [FFmpeg-devel] ByteIOContext probe + img2 patch
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>, "Justin Foutts" <jmfoutts at yahoo.com>
Date: Sunday, September 4, 2011, 8:44 PM

On Sun, Sep 04, 2011 at 08:09:21PM -0700, Justin Foutts wrote:
> Update: Sorry!  The previous patch was wrong.  I have attached a new patch.
> I ended up downgrading to a ffmpeg version that still uses av_open_input_stream and av_open_input_file, while applying an equivalent patch to img2.c.  I use av_open_input_file on windows,linux,osx,iphone and av_open_input_stream with a custom ByteIOContext on android.  I'm not sure why I can't get a custom ByteIOContext to work on all platforms.

Can you explain what your patch fixes and how it does it?
some of the changes in there look odd like trying to get the file
size of a pipe

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.