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

[Alexander Strasser]

Hi Vincenzo!

On 2020-01-16 14:33 +0100, Vincenzo Nicosia wrote:
> 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.

No disagreements here :)


> 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
> :)

I don't want to go in that direction at all!
Improving mplayer's UI is the reason I motivated you to send a patch :)


> > 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.

True of course.

> 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 ....

That's correct, but the users will only see the error message with
their exact typo and without "ffmpeg://" .


> > 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.

Maybe we can get away without validating by using this FFmpeg API:

    /**
     * Return the name of the protocol that will handle the passed URL.
     *
     * NULL is returned if no protocol could be found for the given URL.
     *
     * @return Name of the protocol or NULL.
     */
    const char *avio_find_protocol_name(const char *url);

IIRC that function would return the "file" protocol, for a parameter
that doesn't have a protocol part. So we should probably check if a
"://" is contained at all and if yes use that function.

Another way would be to not call open the second time if "file" is
returned. Therefore one could only use FFmpeg file protocol by
prepending "ffmpeg://" which would be OK with me.


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

To clarify what I meant here: I have no more ideas. Others might have
better ideas on how to tackle this.

It was in no way meant discouraging.


> 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.

Thanks for the patches. I would love to see another improved patch.
Your goal seems reasonable and reachable to me.


  Alexander