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

[Reimar Döffinger]

Hello! 

On 16 January 2020 14:33:45 CET, Vincenzo Nicosia <katolaz at freaknet.org> 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.

Hmm. From my point of view your patch does not really specifically adress this case but acts much more broadly, and I am not sure that is a good idea (and Alexander commented on a specific case of that, but it will be even more annoying with network protocols where failing now takes twice the time). 
I had assumed that you actually WANTED it to try the FFmpeg implementation even if MPlayer has support for that protocol itself but it failed.
There is also the opposite problem: it will try to use FFmpeg even for protocols where that will not work in MPlayer (not entirely sure about the status, but some protocols can only work with the matching FFmpeg demuxer, and MPlayer might not instantiate that one). 
Just to be clear it's not a misunderstanding:
There is no need to add ffmpeg:// for FFmpeg protocols, only those that nobody tested and added to list of the ones the FFmpeg one supports.
I am somewhat tempted to suggest that explicit listing those we know to work would be the better solution.
I have a feeling that we might actually want something like your patch at some point, but I'm not sure exactly what and I think maybe not as first step.