[MPlayer-dev-eng] [PATCH] stream: add fallback to ffmpeg for unknown streams

[Vincenzo Nicosia]

On Wed, Jan 15, 2020 at 11:44:08PM +0100, Alexander Strasser wrote:

[cut]

> 
> *Don't care much about the cosmetic advice I have given at this point.*
> If we go with this approach we can get the cosmetics right just before
> committing...
>

Hi Alexander,

thanks for the comments. Let's sort the cosmetics out later, then :)

Just to add two words about the rationale behind this patch: it is a
pity that mplayer can support a variety of additional streams and
protocols through ffmpeg, and that this thing is not only a bit fiddly
to use (you have to prepend "ffmpeg://" to your url, which is quite
nasty for plumbing) but worse, it is not even mentioned in the manpage
or in the dev documentation.

You have to read the code, get to stream.c, find out that there is
some sort of support for ffmpeg streams, and try to understand by
yourself how it works. This is what I did, and still could not figure
out how it should be used the first time. And I concluded that mplayer
did not have support for gopher. And sent an email here a few days ago
:)

The net result is that an end-user tries "mplayer scheme://somefile"
and, if it does not work, will just think "oh shit, mplayer does not
support it" and go use mpv or vlc. As a user, I won't probably be
bothered to try opening a stream, see that it does not work, prepend
"ffmpeg://", and then if it does not work either, go to mpv or
vlc. I'd probably go use something else straight away.

I am fine with that if you prefer going in that direction, but I guess
that printing an additional info message is better than losing users
:)

> It builds and works for me, but I'm not sure about the exact approach.
> 
> The code will now also retry for every typoed filename to open with
> ffmpeg://typo_here . While that might not be as dangerous as it looks
> in the first place (not yet sure about it), it definitely adds noise
> by printing the messages and especially with the rewritten filename
> it might confuse users. Like why is mplayer trying to ffmpeg:// my
> local video file or dvd.

The problem is that there is no way to know whether the user has a
typo in their URL witout trying to open the stream. Even if we don't
fallback on ffmpeg, the user will still se just an error message
saying that the stream they are trying to open is not there ....

> 
> If we still decide to go with this approach, another thing to think
> about is what happens if the open_stream_full function is used to
> open an output stream. Do we want the ffmpeg:// extra try for those
> usages too?
>
> Maybe we should think about constraining the last resort ffmpeg://
> try more to usage with protocols specified with name:// . Maybe we
> could even test beforehand if the ffmpeg at hand has support for the
> given protocol if that's feasible.

It's relatively easy to test if "filename" is indeed a valid URL, and
fallback to ffmpeg only in that case (this should solve the issue with
output streams right?). I can easily add this check to the
patch. However, I don't know if there is a way to test if ffmpeg
supports a given scheme without actually trying to open it, and this
is what is currently done in open_stream_full.

> 
> No more better ideas from me at this moment. Maybe others have
> completely different and better ideas on how to implement this.

Just let me know what you think. I can put together a patch to check
for valid schemes, but I won't insist if you decide that this is not
what you want mplayer to do.

HND

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20200116/cdcf1ded/attachment.sig>