[FFmpeg-devel] GSoC 2016 own ideas

Paul B Mahol onemda at gmail.com
Thu Feb 18 20:48:03 CET 2016


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.


More information about the ffmpeg-devel mailing list