[MPlayer-dev-eng] offer to include gopher protocol support

[Alexander Strasser]

Hi Reimar!

On 2020-01-17 17:23 +0100, Reimar Döffinger wrote:
> On Tue, Jan 14, 2020 at 12:29:52AM +0100, Vincenzo Nicosia wrote:
> > On Mon, Jan 13, 2020 at 11:02:03PM +0100, Alexander Strasser wrote:
> > [cut]
> >
> > >
> > > Did you test it on some content? I didn't try playing media over gopher
> > > yet :)
> > >
> >
> > Yes, it works, but having to put the ffmpeg:// scheme before the actual
> > gopher:// URL is quite awful (and a bit annoying).
>
> Oooh, this is the background.
> My fault for working backwards.
> Please, any ffmpeg protocol support that you successfully tested just
> add it to the supported protocol list in stream_ffmpeg.c.

That's what I was missing! I somehow thought we never use FFmpeg at
the stream layer except when forced via ffmpeg:// .

So I guess the attached patch should be OK, right?


> That way you don't have to prepend the ffmpeg:// anymore.
> It is annoying on purpose because the idea is that "ffmpeg://" means
> "yes, use the ffmpeg protocol implementation even though I know it's
> not tested or might in fact even be known broken for MPlayer".
> Anyone testing more of the protocols FFmpeg supports and finding that
> they work fine, please do the same.
> At some point we'll hit the size limit of that array I guess, then we
> can consider increasing MAX_STREAM_PROTOCOLS or if that gets extreme
> just split it in multiple or some other way.

After looking at that list I noticed https is in there, since some time.
It makes sense as AFAIK we don't support it with MPlayer's http modules,
though it seems a bit unexpected from a user's end, that consuming a
stream, even the "same stream", via https will switch the underlying
implementation.


> Lastly, we could in theory even e.g. in configure check which protocols
> the FFmpeg copy supports, and auto-generate a dummy stream that just
> prints "hey, this protocol you specified? I see FFmpeg supports it,
> but we don't know if it will work in MPlayer. If you feel adventurous
> and want to try it out prefix ffmpeg:// and report any success to us".

Maybe we could use the avio_find_protocol_name function I mentioned in
the other thread, to determine that at run-time. I would prefer to
implement the message in stream.c , and only print it if no protocol
could be found. That would guarantee the message will be printed very
late and make it more likely that a user will read it.

The dummy stream version would also have its advantages, because the
message could also be printed when we support a protocol in MPlayer.
For me that's just to noisy though. I have been thinking MPlayer's
default output is too random and too noisy for almost forever. So that
would feel like a step in the wrong direction to me.


  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-stream_ffmpeg-Add-gopher-to-the-supported-protocols.patch
Type: text/x-diff
Size: 795 bytes
Desc: not available
URL: <https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20200118/667d69b9/attachment.patch>