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.co...@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.
My main interest in using ffmpeg is an an RTSP client library (ok,
maybe some say this should not be a demuxer either ?), the
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.
--
Gilles.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
