[MPlayer-dev-eng] offer to include gopher protocol support
eclipse7 at gmx.net
Sat Jan 18 23:04:41 EET 2020
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 795 bytes
Desc: not available
More information about the MPlayer-dev-eng