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

wm4 nfxjfg at googlemail.com
Fri Apr 10 23:06:53 CEST 2015


On Fri, 10 Apr 2015 22:45:47 +0200
Gilles Chanteperdrix <gilles.chanteperdrix at xenomai.org> wrote:

> On Thu, Apr 09, 2015 at 10:59:24PM +0200, Lukasz Marek 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.
> > We have separation libavformat/libavdevice and most of patches I submitted
> > regarding libavdevice were complained by one person.
> > 
> > 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.
> > 
> > I don't want to be drama queen here, but the way author of this patch was
> > treated is bellow any level of dignity.
> 
> I assure you the author of this patch is not vexed or discouraged.

And you shouldn't.

> My main interest in using ffmpeg is an an RTSP client library (ok,
> maybe some say this should not be a demuxer either ?), the

Some network protocols are indeed rather close to what's reasonable,
and most network protocols in ffmpeg have weird issues because
libavformat was designed for on-disk files.

> youtube-dl thing would just have been a nice addition if it had been
> possible to have a quick solution, but this is nothing I care to
> spend to much time on. My main effort for free-software go to
> another project which has less maintainers, contributors and users
> than ffmpeg.
> 
> Now for the "high level API", if you mind the opinion of someone
> which has a rather new view on this project and is implementing a
> simplistic player, I believe what could be done relatively easy is
> to split ffplay into say libffplay which would implement a
> high-level API for players with calls such as open, play, pause,
> seek, close, and ffplay which would use this API and implement the
> human machine interface. This would make implementing a custom
> player relatively easy by using libffplay being free to use GTK or
> Qt, or whatever else for the GUI. Maybe the same goes for the ffmpeg
> tool.
> 

Just taking ffplay and turning it into a library would suck. For one,
such a library shouldn't require SDL or anything. But ffplay could use
such a high-level lib, and then it should just be a couple of lines or
so, ideally. Most importantly, the library should be able to return
decoded audio and video data in a format requested by the user, and
require a minimum of boilerplate for that. (If you want a more
"complete" solution, just use something like libvlc - there are a
couple or more lightweight ones too.)



More information about the ffmpeg-devel mailing list