[FFmpeg-devel] [PATCH 3/3] avformat: add youtube-dl based demuxer

[wm4]

On Thu, 09 Apr 2015 22:59:24 +0200
Lukasz Marek <lukasz.m.luki2 at gmail.com> wrote:

> On 09.04.2015 13:50, Kieran Kunhya wrote:
> > On 9 April 2015 at 12:17, Rodger Combs <rodger.combs at gmail.com> wrote:
> >> Agreed, this belongs in a higher layer. I think it'd be reasonable for FFmpeg to have a higher-layer library handling things like playlists and this, but that's another conversation.
> >
> > +1
> 
> So instead of complaining and spamming with "+1", prepare a patch and 
> submit it? Community will discuss it and do what's the best for the 
> project (and yes, project is not single person who has their wishes). 
> Personally I woulnt complain about that separation if done properly, but 
> just don't see a reason for it. Most of the stuff you don't need/like 
> you can disable at compilation level.

Most people here are fundamentally disagreeing with the idea that
something like youtube support belongs into a low level demuxer
library. As I've said before, the low level libs have tons of issues
(many of them on the conceptual level) which makes using them hard. And
saving the user a few lines of codes to call youtube-dl isn't the
biggest of them. Which makes this whole discussion ridiculous.

> We have separation libavformat/libavdevice and most of patches I 
> submitted regarding libavdevice were complained by one person.

libavdevice also is a terrible hack. Device reading does not belong
into a low level demuxer library. But I guess this hack has been
"grandfathered". But I find it disturbing that some people think video
output and such things should be in a low level muxer library. This is
just nonsense. No really, just think about it.

Yes, maybe ffmpeg should have device reading, simply because it's
useful to some. But it should be a separate kind of component, and not
a demuxer. But demuxers are the only thing that exists in ffmpeg and
that vaguely appears to match the API, so they are demuxers. Because
someone wanted them, not because it was a good idea.

> Sometimes I have a feeling that ffmpeg is an open source project to feed 
> wm4's project. Everything he doesn't need is "retarded", "rotten", 
> "dumb", etc, etc.

Sometimes I have a feeling that ffmpeg is an open source project to feed
Lukasz' project. Why else would we have several APIs which are likely
used by only 1 person, the same person who added them? I doubt anyone
else e.g. uses libavdevice for serious video output.

It seems like you chose ffmpeg as your multimedia framework. And some
things were missing, so you decided to add them to ffmpeg, no matter
what. Screw the fact that the APIs are not a good match for what you
need to do, it must be added somehow!

Note that I did something similar with my project (mpv). It's a mplayer
fork, and my goal was/is to remove as much mplayer code as possible and
to replace it with ffmpeg or such. But I know where I have to stop, and
don't use ffmpeg as a code dump for whatever custom code I still need.

Actually, I would like if there was a higher level open source
multimedia framework, that is not gstreamer (which I think is bloated,
duplicates a lot of ffmpeg functionality unnecessarily, and is under
the curse of glib and its "gchar" and C OOP madness). I don't think
ffmpeg can be this in its current form. The existing libs are all too
low level. The idea of a certain other dev to turn libavfilter into a
generic multimedia framework (because it can do filer graphs, duh) is
too short sighted and will lead to terrible design.

Really, most of the ffmpeg API suckage can be reduced to the habit of
coercing whatever devs want to do into the existing APIs, even if it
means forcing a square peg into a round hole.

I think this is because ffmpeg consists of a single repo. It hinders
experimentation and trying entirely new things. If you add something to
the big ffmpeg repo, it has to be there forever and needs approval
from the whole community. You can't just try to make something new and
experimental and have the ffmpeg eco-system use it; either you add it
to the main repo, or it may as well not exist. Compare this to
plugin-driven frameworks, where people can create something without
having to argue with others - and anyone who wants can try to use it.

Why does the repo contain 9 sub directories starting with lib...
anyway? Why are they not separate repos? (Many others have been saying
for years that splitting the repos would benefit the project.)

Another huge factor is IMHO that ffmpeg just forces a set of fixed
APIs upon everything. There is no way to provide a demuxer outside
of libavformat. It boils down to ffmpeg being monolithic and
plugin-hostile. Not because libavformat doesn't allow registering
custom demuxers, but because it requires custom demuxers going through
libavformat in the first place, instead of just providing a common
interface for demuxing anyone can reasonably implement.

Anyway, while I'd actually like ffmpeg to be a light-weight multimedia
framework, it's something different for most developers using it. My
guess is that it's mostly used for decoding and transcoding. High level
features just hinder maintenance (of which ffmpeg needs a lot). So I'm
not sure why you are surprised that things like youtube support are not
overly popular.

One could argue that a generic media framework should be built on top
of ffmpeg, instead of as part of ffmpeg. This is probably true, and with
the current single-repo with its specialized low level APIs, it's
the only sane thing to say.

> I don't want to be drama queen here,

Too late.

> but the way author of this patch 
> was treated is bellow any level of dignity. FFmpeg has more to offer 
> that show how many douches is subscribed to the mailing list.

Sorry if I was rude. I will probably be rude again. It's hard to express
feelings over the internet, and most time it does not seem to work. So
when in real life you would express your disapproval in a more subtle
and friendly way, it turns to flamewars on the internet.

> Unless these things are handled don't treat me as member of this 
> "community" anymore.

OK.