On Fri, 10 Apr 2015 22:45:47 +0200 Gilles Chanteperdrix <gilles.chanteperd...@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.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. 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.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
