[FFmpeg-devel] GSoC 2016 own ideas

[Matt Oliver]

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.