[FFmpeg-devel] GSoC 2016 own ideas

[Paul B Mahol]

On 2/18/16, Gerion Entrup <gerion.entrup.ffdev at flump.de> wrote:
> On Donnerstag, 18. Februar 2016 18:53:45 CET Paul B Mahol wrote:
>> Dana 18. 2. 2016. 18:27 osoba "Gerion Entrup"
>> <gerion.entrup.ffdev at flump.de>
>> napisala je:
>> >
>> > 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].
>> >
>> > 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).
>> >
>> > Comments:
>> > - I would try to orientate on VLC, mplayer and mpv implementation.
>> > - libdvdread/nav seem to do much less than libbluray, so the main work
>> would be the dvd support, I guess.
>> > - All kinds of discs normally contains more than one track. My idea for
>> > a
>> solution would be, that ffmpeg recognize the disc as multiinput and choose
>> the mainmovie as default.
>> >
>>
>> This is out of scope for project. And who will use it when everyone have
>> own solution.
> I have the impression, that DVD support is not trivial. Kodi e.g. fails on
> DVDs, that VLC can play. As an application programmer with already existent
> FFmpeg support I would be happy to see a simple solution.
>
> Also some new programs could arise, that do not have an own solution.
>
> Also some devs seem to want DVD support [1].

It could use dvdread/dvdnav library to just allow reading dvds, no
menus and other
stuf. Still not enough for GSoC task IMHO.

[...]

>> > 4. Usable analyse filter output for programs
>> > Not sure, if this is a real problem at all. Not sure if this is suitable
>> for GSoC at all.
>> >
>> > What current FFmpeg could do:
>> > - Receive (multiple) streams in filter and write back other streams.
>> > - The problem I see here, is that the output of analyse filters is hard
>> to process (needs some kind of subprocess and extended usage of grep/sed).
>> >     Examples: All filters that analyse some thing and then "print" it to
>> stdout, like cropdetect, volumedetect, blackframe, .... Some (not
>> implemented filter) like tonality, bpm detection, waveform analysis, ...
>> >
>> > Goal:
>> > - Rewrite the filtersystem, so that some function "receive_output"
>> exists, that could be called from the external API or another filter to
>> get
>> non multimedia data as the filter output, like an String for tonality, or
>> an index array for the wavform, etc.
>> >
>> > Comments:
>> > - Has the side effect, that a following filter in the chain could use
>> > the
>> output to do some other stuff.
>> > - Not sure, how hard (and wanted) this is.
>>
>> Already available via metadata.
> Is this in a standardized way? E.g. volumedetect has:
> static av_cold void uninit(AVFilterContext *ctx)
> {
>     print_stats(ctx);
> }
> And print_stats does a lot of av_log. I see no way to get the (integer and
> float) values out of the filter without av_log output parsing (and
> reconverting
> to int and float).

This is printed at end, but yes outputing this also as (graph?) metadata
should be nicer to the users, still not enough to be GSoC task.