Re: offer to include gopher protocol support

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

_______________________________________________
MPlayer-dev-eng mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

From d28bef17949ed62ac46b183a49356bfa15d6b2c8 Mon Sep 17 00:00:00 2001
From: Alexander Strasser <[email protected]>
Date: Sat, 18 Jan 2020 20:50:15 +0100
Subject: [PATCH] stream_ffmpeg: Add gopher to the supported protocols

Thanks to Vincenzo Nicosia for bringing up the topic and testing
gopher via stream_ffmpeg.
---
 stream/stream_ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stream/stream_ffmpeg.c b/stream/stream_ffmpeg.c
index 57d45e409..cfb8e607f 100644
--- a/stream/stream_ffmpeg.c
+++ b/stream/stream_ffmpeg.c
@@ -158,7 +158,7 @@ const stream_info_t stream_info_ffmpeg = {
   "",
   "",
   open_f,
-  { "ffmpeg", "rtmp", "rtsp", "https", NULL },
+  { "ffmpeg", "rtmp", "rtsp", "https", "gopher", NULL },
   NULL,
   1 // Urls are an option string
 };
--