On Sat, Feb 20, 2016 at 05:01:03PM +1100, Matt Oliver wrote: > On 19 February 2016 at 09:20, Gerion Entrup <gerion.entrup.ff...@flump.de> > wrote: > > > On Donnerstag, 18. Februar 2016 21:02:09 CET wm4 wrote: > > > On Thu, 18 Feb 2016 20:41:29 +0100 > > > > > > Gerion Entrup <gerion.entrup.ff...@flump.de> wrote: > > > > On Donnerstag, 18. Februar 2016 20:10:47 CET wm4 wrote: > > > > > On Thu, 18 Feb 2016 18:27:45 +0100 > > > > > > > > > > Gerion Entrup <gerion.entrup.ff...@flump.de> wrote: > > > > > > Good day, > > > > > > > > > > > > I'm a master student and long term FFmpeg-user. I want to > > participate > > > > > > in > > > > > > > > the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to > > > > suggest some own ideas. It could be, that some of the mentioned things > > > > are wrong (because FFmpeg could do this already or it it much more > > > > difficult than I think). Please correct me if so. > > > > > > > > > > I'm excited to hear, what do you think about this ideas, if you > > think, > > > > > > > > they are suitable for GSoC and if you maybe are willing to mentor some > > of > > > > this. > > > > > > > > > > 1. *disc support > > > > > > > > > > > > What current FFmpeg could do: > > > > > > - Bluray support through protocol support with prefix "bluray:" and > > > > > > > > libbluray. The implemention is some kind of limited. There is missing > > > > chapter support. The "main movie" selection is simply the longest one. > > > > Menus are not supported. Afaik no metadata are transfered. > > > > > > > > > > - CD support through libavdevice and libcdio. Last time I tried > > it, it > > > > > > > > only works under some strange circumstances (I have to set the > > parameter > > > > "-ss 0"). I don't know if it is fixed right now. It recognizes a CD as > > > > one track with multiple chapters. Afaik CD-Text is not supported. > > > > > > > > > > - No DVD support at all. I saw, that Stefano ones write a patch [1] > > > > > > > > (protocol and libdvdnav based), which seems to work in principal, but > > was > > > > probably not ready to merge. > > > > > > > > > > Goal: > > > > > > - Implement an uniform solution for *disc support, that also > > support > > > > > > > > metadata. > > > > > > > > > > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for > > > > > > this > > > > > > > > atm, I think. Not sure how difficult it is. > > > > > > > > > > - Maybe (?): Try to change something on libdvdnav/libdvdread to > > make > > > > > > it > > > > > > > > more consistent (to libbluray ?). Similar idea from Flameeyes [2]. > > > > > > > > > Hm, I'm not sure if that's even possible in a reasonable way. Full > > > > > DVD/Bluray support requires menus, which are hard to get right, and > > > > > which would require non-trivial interactions between applications and > > > > > libavformat. > > > > > > > > > > Improving support for merely transcoding a DVD to a file might be not > > > > > so hard and potentially a good idea, though. > > > > > > > > > > > Qualification task: > > > > > > - Maybe (?): Add chapter support for the current Bluray > > implementation > > > > > > > > (get the chapters out of libbluray is fairly simple, I'm not sure how > > > > difficult it is to get them into the stream). > > > > > > > > > This sounds like a hard design issue: currently bluray is implemented > > > > > as avio protocol, which can not pass things like chapters to the > > higher > > > > > level (demuxer). This would require coming up with a mechanism for > > > > > transferring this metadata, which sounds hard. Just reading the > > bluray > > > > > chapters should indeed be simple. > > > > > > > > Just reading the chapters and print them is too simple to be a > > > > qualification task. > > > > > > > I to would be interested in better cd/bluray support as well as additional > dvd support. The big projects using ffmpeg already have their own > implementation but some of these are better than others and each can have > their own issues. So having a centralized implementation could be useful > (especially for new projects). > Interestingly cdio is currently part of avdevice while bluray is part of > avformat, perhaps moving bluray to be a device could alleviate some of the > issues around it being a protocol. > > You will probably get a different answer from each developer, but my advice > > is very much that I would like it if ffplay used libavdevice and if > > libavdevice was powerful enough for that. > > > > Having ffplay use avdevice in my mind would be an ideal solution. This way > it minimizes having separate code doing similar things. > > > > > In my personal opinion, audio/video output in libavdevice is an > > > abomination. It tries to force a muxer API to be used as API for > > > audio/video output, which is ridiculous and obviously has a bunch of > > > disadvantages. A real approach would realize such things as a separate > > > library with a proper API. > > There is already SDL(1) output in libavdevice. > > > > But libavdevice is just bad libavformat ripof API wise. > > There is no libavdevice API. And it is shame. > > > > I had idea to improve it but seems nobody likes such idea. > > I would be interested in such an idea as I think this would potentially > make avdevice much more usable. It would also provide a possible solution > to the above issues as well. An improved avdevice api would allow it to be > used in ffplay instead of sdl and if done right could also be made to allow > for cd/dvd/bluray support within avdevice. The current lib has basic > message passing functions for things like device disconnect callbacks and > the like, this could potentially be cleaned and extended to support > mouse/keyboard messages allowing for menu support as well (just an idea). > > I was recently writing up some additional devices for audio IO on windows > and potentially improving the existing output device for other OSs so I > would be interested in potentially helping out with a new avdevice api.
a potential GSoC project could be to write implementations in an API if a good API that everyone likes was existing at the time of the GSoC project. Not sure if that is possible or not in practice for this year. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
