[FFmpeg-devel] GSoC 2016 own ideas

[Michael Niedermayer]

On Sat, Feb 20, 2016 at 05:01:03PM +1100, Matt Oliver wrote:
> On 19 February 2016 at 09:20, Gerion Entrup <gerion.entrup.ffdev at 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.ffdev at 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.ffdev at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160221/9b3adbaf/attachment.sig>