Re: [FFmpeg-devel] [PATCH 1/2] libavfilter/signature_lookup: fix possible division by zero
Am Dienstag, 7. Mai 2024, 19:46:28 MESZ schrieb Michael Niedermayer:
> On Mon, May 06, 2024 at 12:30:39AM +0200, Gerion Entrup wrote:
> > ---
> > libavfilter/signature_lookup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
> > index a0ca818a9b..b39a3e225b 100644
> > --- a/libavfilter/signature_lookup.c
> > +++ b/libavfilter/signature_lookup.c
> > @@ -128,7 +128,7 @@ static int get_jaccarddist(SignatureContext *sc,
> > CoarseSignature *first, CoarseS
> > int jaccarddist, i, composdist = 0, cwthcount = 0;
> > for (i = 0; i < 5; i++) {
> > if ((jaccarddist = intersection_word(first->data[i],
> > second->data[i])) > 0) {
> > -jaccarddist /= union_word(first->data[i], second->data[i]);
> > +jaccarddist /= FFMAX(union_word(first->data[i],
> > second->data[i]), 1);
> > }
>
> for which input data does this cause a division by 0 ?
Sorry for the late answer. I missed your mail somehow.
union_word counts the amount of one bits that are created when you are "or"ing
the course signatures. So, when the underlying videos are so different that all
bits of the created signatures are different, the "or"-operator will always
return 0 and so also its sum (I have not tested this).
Gerion
signature.asc
Description: This is a digitally signed message part.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] libavfilter/signature_lookup: fix possible division by zero
Am Freitag, 24. Mai 2024, 23:03:37 MESZ schrieb Michael Niedermayer:
> On Fri, May 24, 2024 at 12:33:11PM +0200, Gerion Entrup wrote:
> > Am Dienstag, 7. Mai 2024, 19:46:28 MESZ schrieb Michael Niedermayer:
> > > On Mon, May 06, 2024 at 12:30:39AM +0200, Gerion Entrup wrote:
> > > > ---
> > > > libavfilter/signature_lookup.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavfilter/signature_lookup.c
> > > > b/libavfilter/signature_lookup.c
> > > > index a0ca818a9b..b39a3e225b 100644
> > > > --- a/libavfilter/signature_lookup.c
> > > > +++ b/libavfilter/signature_lookup.c
> > > > @@ -128,7 +128,7 @@ static int get_jaccarddist(SignatureContext *sc,
> > > > CoarseSignature *first, CoarseS
> > > > int jaccarddist, i, composdist = 0, cwthcount = 0;
> > > > for (i = 0; i < 5; i++) {
> > > > if ((jaccarddist = intersection_word(first->data[i],
> > > > second->data[i])) > 0) {
> > > > -jaccarddist /= union_word(first->data[i], second->data[i]);
> > > > +jaccarddist /= FFMAX(union_word(first->data[i],
> > > > second->data[i]), 1);
> > > > }
> > >
> > > for which input data does this cause a division by 0 ?
> >
> > Sorry for the late answer. I missed your mail somehow.
> > union_word counts the amount of one bits that are created when you are
> > "or"ing
> > the course signatures. So, when the underlying videos are so different that
> > all
> > bits of the created signatures are different, the "or"-operator will always
> > return 0 and so also its sum (I have not tested this).
>
> the division only occurs if jaccarddist > 0
>
> basically what iam asking is for which A and B do we have
> (A&B) != 0 && (A|B) == 0
> or am i misreading the code ?
Hmm, valid point. Then, this patch should be unnecessary.
Should I send 2/2 again without 1/2 then?
Gerion
signature.asc
Description: This is a digitally signed message part.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavfilter/signature_lookup: fix jaccard distance
Actually, the jaccard distance is defined as D = 1 - intersect / union.
Additionally, the distance value is compared against a constant that
must be between 0 and 1, which is not the case here. Both facts together
has led to the fact, that the function always returned a matching course
signature. To leave the constant intact and to avoid floating point
computation, this commit multiplies with 1 << 16 making the constant
effectively 9000 / (1<<16) =~ 0.14.
Reported-by: Sachin Tilloo
Reviewed-by: Sachin Tilloo
Tested-by: Sachin Tilloo
---
libavfilter/signature_lookup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index b39a3e225b..b90b63f3f2 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -127,9 +127,10 @@ static int get_jaccarddist(SignatureContext *sc,
CoarseSignature *first, CoarseS
{
int jaccarddist, i, composdist = 0, cwthcount = 0;
for (i = 0; i < 5; i++) {
-if ((jaccarddist = intersection_word(first->data[i], second->data[i]))
> 0) {
+if ((jaccarddist = (1 << 16) * intersection_word(first->data[i],
second->data[i])) > 0) {
jaccarddist /= FFMAX(union_word(first->data[i], second->data[i]),
1);
}
+jaccarddist = (1 << 16) - jaccarddist;
if (jaccarddist >= sc->thworddist) {
if (++cwthcount > 2) {
/* more than half (5/2) of distances are too wide */
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavfilter/signature_lookup: fix jaccard distance
Actually, the jaccard distance is defined as D = 1 - intersect / union.
Additionally, the distance value is compared against a constant that
must be between 0 and 1, which is not the case here. Both facts together
has led to the fact, that the function always returned a matching course
signature. To leave the constant intact and to avoid floating point
computation, this commit multiplies with 1 << 16 making the constant
effectively 9000 / (1<<16) =~ 0.14.
Reported-by: Sachin Tilloo
Reviewed-by: Sachin Tilloo
Tested-by: Sachin Tilloo
---
Sorry, it should apply clean now.
libavfilter/signature_lookup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index a0ca818a9b..46602874de 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -127,9 +127,10 @@ static int get_jaccarddist(SignatureContext *sc,
CoarseSignature *first, CoarseS
{
int jaccarddist, i, composdist = 0, cwthcount = 0;
for (i = 0; i < 5; i++) {
-if ((jaccarddist = intersection_word(first->data[i], second->data[i]))
> 0) {
+if ((jaccarddist = (1 << 16) * intersection_word(first->data[i],
second->data[i])) > 0) {
jaccarddist /= union_word(first->data[i], second->data[i]);
}
+jaccarddist = (1 << 16) - jaccarddist;
if (jaccarddist >= sc->thworddist) {
if (++cwthcount > 2) {
/* more than half (5/2) of distances are too wide */
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
Am Mittwoch, 6. Februar 2019, 21:41:29 CET schrieb Werner Robitza:
> Dear all,
>
> Homebrew has, with its 2.0 release, removed all options for its core
> formulae [1], including ffmpeg. This means users can no longer add
> non-default dependencies that aren't included in the core formula [2].
> That creates a bit of a messy situation, as users are expecting to be
> able to build ffmpeg with additional libraries, including nonfree ones
> such as fdk-aac. This is no longer easily doable.
>
> The Homebrew maintainers suggest to provide an alternative third-party
> tap with an ffmpeg formula, such as this one created by another user
> [3].
>
> I propose that FFmpeg maintains its own ffmpeg formula under its
> GitHub organization at github.com/ffmpeg/homebrew-ffmpeg (or similar).
> This will ensure that there's one formula users will discover when
> they look for an alternative tap, thus improving discoverability and
> avoiding fragmentation. We could use the above link as a starting
> point.
>
> Homebrew's lead maintainer also noted that this repo ("tap") could be
> indexed [4] – he was reluctant to point to it in the official
> formula's caveat section though, as they will not endorse third-party
> taps.
>
> I am happy to maintain this formula – and maybe there are other
> community members who want to support this effort. The maintenance
> effort would basically be: bumping the formula everytime there's an
> official release, and testing its build.
>
> Please let me know your thoughts.
>
> Best regards,
> Werner
>
> [1] https://github.com/Homebrew/homebrew-core/issues/31510
> [2] https://github.com/Homebrew/homebrew-core/blob/master/Formula/ffmpeg.rb
> [3]
> https://github.com/varenc/homebrew-ffmpeg-with-options/blob/master/Formula/ffmpeg.rb
> [4] https://docs.brew.sh/Interesting-Taps-and-Forks
Hi,
do the dependencies of the options need to be maintained in the repo as well?
(BTW, the whole option concept seems to be quite similar to use flags in Gentoo
[1].)
Regards,
Gerion
[1]
https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/ffmpeg/ffmpeg-4.1.ebuild
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature
On Dienstag, 21. März 2017 00:12:52 CET Michael Niedermayer wrote: > On Mon, Mar 20, 2017 at 02:31:46PM -0800, Lou Logan wrote: > > On Mon, 20 Mar 2017 15:23:10 +0100 > > Paul B Mahol wrote: > > > > > Then wait until someone else appears and like to commit this code. > > > > It would be easier to do for a lazy commit monkey if it was rebased to > > current git master: > > > > error: patch failed: Changelog:12 > > error: Changelog: patch does not apply > > error: patch failed: libavfilter/version.h:30 > > error: libavfilter/version.h: patch does not apply > > applied > Thank you. I'm currently busy but I try to create a test as soon as I get some time (I already looked into it but don't get the right approach). Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Possible long(er?) term support
On Samstag, 27. August 2016 23:37:09 CEST Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 27 August 2016 at 12:48, Michael Niedermayer wrote: > > which other distros use 2.8 ? (that is distro releases which will not/ > > cannot upgrade to 3.*) > > I can see 2.8.6 in Gentoo (marked as stable, with 3.x as testing). Note that the 3.x version are masked (similar to unstable, indicating that they break other things). See here [1] and here [2] for details. If all bugs are fixed, 3.x will be stabilized, I think. Gerion [1] https://packages.gentoo.org/packages/media-video/ffmpeg [2] https://bugs.gentoo.org/show_bug.cgi?id=574788 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [German] Workshop bei der OpenRheinRuhr
Hello/Hallo, I'll write the rest of the mail in German, because the subject is the German Conference OpenRheinRuhr. Ich wollte auf der OpenRheinRuhr wieder einen Workshop zu der Benutzung von FFmpeg halten, diesmal aber mit Fokus auf Filtern (ich habe vor einem Jahr auf den Chemnitzer Linuxtagen ebenfalls einen Workshop gehalten). Hier würde ich gerne kurz die Formulierung diskutieren. Einsendeschluss ist der 23.09.: Titel: "FFmpeg: Effekte mit Filtern" Untertitel: "Multimediadateien analysieren und verarbeiten" Art: Workshop, Dauer: 3h Text: FFmpeg ist eine freie Bibliothek um so gut wie jede Art von Multimediadaten zu dekodieren, zu manipulieren und zu erzeugen. Bekannte Player wie z.B. VLC, mplayer, mpv, Kodi benutzen FFmpeg im Hintergrund um Filme und Musik abzuspielen. FFmpeg bietet zusätzlich dazu noch ein Kommandozeilenprogramm, das die direkte Manipulation von Multimediadaten erlaubt. In diesem Workshop soll das Kommandozeilenprogramm "ffmpeg" vorgestellt und vor allem auf die umfangreichen Filterfunktionen eingegangen werden. Der erste Teil des Workshops (etwa die erste Stunde) wird sich mit der Installation und dem grundlegenden Aufbau von Multimediadaten beschäftigen. Der zweite Teil behandelt dann verschiedene Filter und den Aufbau von komplexen Filtergraphen. Diejenigen, die FFmpeg bereits installiert haben (wichtig ist die Ausgabe "the FFmpeg developers" bei der Eingabe von ffmpeg) und denen Begriffe wie Container, Codec, Matroska, Encoder, Videoformat vertraut sind, können ohne Probleme erst zum zweiten Teil kommen. Grundlegende Erfahrung mit dem Terminal wird vorausgesetzt. - Ich bitte um Kommentare. Die Trennung habe ich deswegen gewählt, da sehr viele auf dem letzten Workshop ffmpeg nicht installiert hatten oder die LibAV- Version, denen man dann einzeln helfen musste usw.. Generell sollte das jetzt durch die Versionen in Ubuntu und Debian besser sein. Ich hoffe aber trotzdem, dass durch die ausdrückliche Trennung weniger Langeweile aufkommt. 2 Stunden für Filter könnte schon eher knapp werden. Vielleicht wären auch 3 Stunden für den zweiten Teil besser. Viele Grüße, Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [German] Workshop bei der OpenRheinRuhr
On Mittwoch, 21. September 2016 11:00:56 CEST Thilo Borgmann wrote: > Hi Gerion, > > > I'll write the rest of the mail in German, because the subject is the > > German > > Conference OpenRheinRuhr. > > I suggest you discuss this in a private mail addressing the german developers > you already know, maybe asking for adding devs to CC who might have interest. > > I'm sorry, but for this list discussion of workshop details seem to be > off-topic > and for all non-german speakers it could just be considered spam. > > -Thilo Ok, you've got mail. Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] GSoC 2016 own ideas
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. 2. treelike metadata What current FFmpeg could do: - Metadata is always an AVDictionary (string based afaik). - Some metadata systems like the one of Matroska use a treelike structure (xml in mkv), so you can specify the charatername given an actor or define more than on actor, see example at the end of the mail. Goal: Rewrite the FFmpeg metadata system, to support extended tags. In Detail: - Support for more than one value per key. - Support for more key/value pairs as value. Qualification task: No idea. Comments: Not sure, if this task is GSoC suitable. 3. Vector graphic support What current FFmpeg could do: - No support at all, afaik. Goal: - Extend FFmpeg to support vector graphics (without converting to pixel graphics). - Write an SVG decoder for this. - Write an vector to pixel image converter/filter. Qualification task: No idea. Comments: I think, this could be a very hard task. Could you comment, whether you find this suitable? I have no experience with SVG. Maybe it could be based on cairo. 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. Other ideas, but imho not suitable for GSoC: - Jack output support (too simple for GSoC) - Python bindings - merge of ffmpeg and ffplay (call ffmpeg without output reacts like ffplay). Maybe this idea is fairly naive. thank you, Gerion [1] https://gitorious.org/ffmpeg/sastes-ffmpeg/commit/716c1f7b2ad02a906ad1e47182492554b668f3dc?p=ffmpeg:sastes-ffmpeg.git;a=blob;f=libavformat/dvdproto.c;h=72ed431c6a47c87e30e4876587c6bb97215517cf;hb=4ed59d83a6e9fb45c3134bb67267e9b05927125c [2] https://blog.flameeyes.eu/2013/02/it-s-that-time-of-the-year-again example tags from matroska: ... ACTOR Matthew McConaughey und 1 CHARACTER Jake Tyler Brigance und 1 ACT
Re: [FFmpeg-devel] GSoC 2016 own ideas
On Donnerstag, 18. Februar 2016 18:53:45 CET Paul B Mahol wrote: > Dana 18. 2. 2016. 18:27 osoba "Gerion Entrup" > 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]. > > > > > 2. treelike metadata > > > > What current FFmpeg could do: > > - Metadata is always an AVDictionary (string based afaik). > > - Some metadata systems like the one of Matroska use a treelike structure > (xml in mkv), so you can specify the charatername given an actor or define > more than on actor, see example at the end of the mail. > > > > Goal: > > Rewrite the FFmpeg metadata system, to support extended tags. In Detail: > > - Support for more than one value per key. > > - Support for more key/value pairs as value. > > > > Qualification task: > > No idea. > > > > Comments: > > Not sure, if this task is GSoC suitable. > > Trivial and out of scope. > > > > > > > 3. Vector graphic support > > > > What current FFmpeg could do: > > - No support at all, afaik. > > > > Goal: > > - Extend FFmpeg to support vector graphics (without converting to pixel > graphics). > > - Write an SVG decoder for this. > > - Write an vector to pixel image converter/filter. > > > > Qualification task: > > No idea. > > > > Comments: > > I think, this could be a very hard task. Could you comment, whether you > find this suitable? I have no experience with SVG. Maybe it could be based > on cairo. > > Out of scope. > > > > > > > 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 f
Re: [FFmpeg-devel] GSoC 2016 own ideas
On Donnerstag, 18. Februar 2016 20:10:47 CET wm4 wrote: > On Thu, 18 Feb 2016 18:27:45 +0100 > Gerion Entrup 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. > > > 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. > > > > > > 2. treelike metadata > > > > What current FFmpeg could do: > > - Metadata is always an AVDictionary (string based afaik). > > - Some metadata systems like the one of Matroska use a treelike structure (xml in mkv), so you can specify the charatername given an actor or define more than on actor, see example at the end of the mail. > > > > Goal: > > Rewrite the FFmpeg metadata system, to support extended tags. In Detail: > > - Support for more than one value per key. > > - Support for more key/value pairs as value. > > > > Qualification task: > > No idea. > > > > Comments: > > Not sure, if this task is GSoC suitable. > > > > Includes API design, which is better avoided for a gsoc. I'm also not > sure if we really need such metadata, but I guess this is debatable. > > > > > 3. Vector graphic support > > > > What current FFmpeg could do: > > - No support at all, afaik. > > > > Goal: > > - Extend FFmpeg to support vector graphics (without converting to pixel graphics). > > - Write an SVG decoder for this. > > - Write an vector to pixel image converter/filter. > > > > That sounds not only very hard, but also very out of scope for ffmpeg. > The problem with SVG is that nothing seems to support it correctly :) > and > entirely, so it's a good way to get hurt. Ok, thank you for the evaluation. > > > Qual
Re: [FFmpeg-devel] GSoC 2016 own ideas
On Donnerstag, 18. Februar 2016 21:02:09 CET wm4 wrote: > On Thu, 18 Feb 2016 20:41:29 +0100 > > Gerion Entrup wrote: > > On Donnerstag, 18. Februar 2016 20:10:47 CET wm4 wrote: > > > On Thu, 18 Feb 2016 18:27:45 +0100 > > > > > > Gerion Entrup 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. > > Indeed. > > By the way, your mail client is making it very hard to distinguish > quoted text from your replies. It doesn't add a ">" on the next line > when line-breaking the quoted text. I see it myself in the received mail. I found out, what causes it. It is clearly a bug, but I hopefully can circumvent it, sorry. > > > > > 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. > > > > > > 2. treelike metadata > > > > > > > > What current FFmpeg could do: > > > > - Metadata is always an AVDictionary (string based afaik). >
[FFmpeg-devel] Subtitles for GSoC
Hello, my own ideas seems not to be suitable for GSoC, so I looked again on the ideas page, because I have high interest to do something for FFmpeg this summer. The project, that I find most interesting, unfortunately is a unmentored one, the subtitle support. Is someone willing to mentor this? On the ideas page the mentioned subtitle for the qualification task is Spruce subtitle. It seems, it is already supported, so I would try to implement the corepart of usf. I know it is not widely used, but very powerful with similar features as SSA, if I get it right. Do you think, that is suitable? And then another question. You mentioned as ultimate goal the libavfilter integration. If I get it right, ATM no rendering is implemented, and libavfilter would allow an (automatic) rendering from SSA to e.g. dvdsub. Would the rendering itself part of the project (because this is very extensive, I think)? regards, Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Subtitles for GSoC
On Dienstag, 8. März 2016 20:42:39 CET Clément Bœsch wrote:
> On Tue, Mar 08, 2016 at 06:21:12PM +0100, Gerion Entrup wrote:
> > Hello,
> >
>
> Hi,
Thank you for your answer.
>
> > my own ideas seems not to be suitable for GSoC, so I looked again on the
> > ideas page,
> > because I have high interest to do something for FFmpeg this summer.
> >
> > The project, that I find most interesting, unfortunately is a unmentored
> > one, the subtitle
> > support. Is someone willing to mentor this?
> >
>
> I added this task for previous OPW (and maybe GSoC, can't remember). I'm
> unfortunately not available for mentoring (too much time, energy and
> responsibility). Though, I can provide standard help as a developer.
>
> The main issue with this task is that it involves API redesign, which is
> often not a good idea for a GSoC task.
>
> That said, a bunch of core limitations have been solved in the past so
> it's starting to be comfortable to work on top of the current stack.
>
> I'm summarizing the current state at the end of this mail, which can be
> useful for any potential mentor and eventually student.
>
> > On the ideas page the mentioned subtitle for the qualification task is
> > Spruce subtitle. It
> > seems, it is already supported, so I would try to implement the corepart of
> > usf. I know
> > it is not widely used, but very powerful with similar features as SSA, if I
> > get it right. Do you
> > think, that is suitable?
> >
>
> Spruce has indeed been added in last OPW as a qualification task. USF is
> more painful but a basic support could be a potential qualification task
> indeed. You might be able to figure out something playing with the
> ff_smil_* functions for the demuxing part.
>
> So basically you would have to:
>
> - an USF demuxer which extracts the timing and text (with its markup) of
> every event, and put them into an AVPacket
>
> - introduce an USF codec and write a decoder that will transform the
> xml-like markup into ASS markup (see below)
This would be more less exactly the task I have tought of / expected.
>
> Again, I'm not a mentor, so you need confirmation from someone else.
>
> > And then another question. You mentioned as ultimate goal the libavfilter
> > integration.
> > If I get it right, ATM no rendering is implemented, and libavfilter would
> > allow an (automatic)
> > rendering from SSA to e.g. dvdsub. Would the rendering itself part of the
> > project (because
> > this is very extensive, I think)?
> >
>
> So, yeah, currently the subtitles are decoded into an AVSubtitle
> structure, which hold one or several AVSubtitleRect (AVSubtitle.rects[N]).
>
> For graphic subtitles, each rectangle contains a paletted buffer and its
> position, size, ...
>
> For text subtitles, the ass field contains the text in ASS markup: indeed,
> we consider the ASS markup to be the best/least worst superset supporting
> almost every style of every other subtitles formats have, so it's used as
> the "decoded" form for all text subtitles. For example, the SubRip (the
> "codec", or markup you find in SRT files) decoder will transform
> "foo" into "{\i1}foo{\i0}".
I personally find the syntax a little unfamiliar (most styled text subtitles
seem
to use html), but ASS seems to be the most used text subtitle format with
(advanced)
styling capabilities.
As a sidenode (not necessary related to this gsoc task): If someday a renderer
is available,
the renderer has to parse and interprete it. My naive approuch would then be
some kind
of tree based structure (because all markup languages I know are tree based).
Would it
be an idea, to parse on the decoder side already and let the internal structure
be not text,
but a tree (independent of the subtitleformat)?
>
> So far so good. Unfortunately, this is not sufficient, because the
> AVSubtitle* structs are old and not convenient for several reasons:
>
> - they are allocated on the stack by the users, so we can't extend them
> (add fields) without breaking the ABI (= angry users).
>
> - they are defined in libavcodec, and we do not want libavfilter to
> depend on libavcodec for a core feature (we have a few filters
> depending on it, but that's optional). As such, libavutil is a much
> better place for this, which already contains the AVFrame.
>
> - the graphic subtitles are kind of limited (palette only, can't hold YUV
> or RGB32 pixel formats for instance)
>
> - the handling of the timing is inconsistent: pts is in AV_TIME_BASE and
> start/end display time are relative and in
[FFmpeg-devel] [PATCH][RFC] Simple USF support
Hello,
I've tried to implement the USF demuxer and decoder. This work is heavily based
on the SAMI demuxer and decoder. It only supports the very basic features.
Supporting more features based on this code would be very hard. I think, it
would
be better to use an external xmllib.
I've not configured my send-mail chain, yet. So I attached the patches.
Moreover the
official sample file is attached, so one can test the code (and see what is
missing).
regards Gerion>From 372698e8467eb0683d318c3606f8d75cc70e629c Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Thu, 10 Mar 2016 17:44:42 +0100
Subject: [PATCH 1/2] add simple usf decoder
- supports only parsing of text strings and basic formatting
- no support for styles
- no support for positioning
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +++
libavcodec/usfdec.c | 126
5 files changed, 136 insertions(+)
create mode 100644 libavcodec/usfdec.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ee9a962..0b73c08 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -530,6 +530,7 @@ OBJS-$(CONFIG_TTA_ENCODER) += ttaenc.o ttadata.o
OBJS-$(CONFIG_TWINVQ_DECODER) += twinvqdec.o twinvq.o
OBJS-$(CONFIG_TXD_DECODER) += txd.o
OBJS-$(CONFIG_ULTI_DECODER)+= ulti.o
+OBJS-$(CONFIG_USF_DECODER) += usfdec.o ass.o htmlsubtitles.o
OBJS-$(CONFIG_UTVIDEO_DECODER) += utvideodec.o utvideo.o
OBJS-$(CONFIG_UTVIDEO_ENCODER) += utvideoenc.o utvideo.o
OBJS-$(CONFIG_V210_DECODER)+= v210dec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 3a59d13..7cd3ec6 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -558,6 +558,7 @@ void avcodec_register_all(void)
REGISTER_DECODER(SUBVIEWER, subviewer);
REGISTER_DECODER(SUBVIEWER1,subviewer1);
REGISTER_ENCDEC (TEXT, text);
+REGISTER_DECODER(USF, usf);
REGISTER_DECODER(VPLAYER, vplayer);
REGISTER_ENCDEC (WEBVTT,webvtt);
REGISTER_ENCDEC (XSUB, xsub);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d676c57..cc7687ec 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -527,6 +527,7 @@ enum AVCodecID {
AV_CODEC_ID_PJS,
AV_CODEC_ID_ASS,
AV_CODEC_ID_HDMV_TEXT_SUBTITLE,
+AV_CODEC_ID_USF,
/* other specific kind of codecs (generally used for attachments) */
AV_CODEC_ID_FIRST_UNKNOWN = 0x18000, ///< A dummy ID pointing at the start of various fake codecs.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 672bf3f..5f06f8b 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2831,6 +2831,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("HDMV Text subtitle"),
.props = AV_CODEC_PROP_TEXT_SUB,
},
+{
+.id= AV_CODEC_ID_USF,
+.type = AVMEDIA_TYPE_SUBTITLE,
+.name = "usf",
+.long_name = NULL_IF_CONFIG_SMALL("Universal subtitle format"),
+.props = AV_CODEC_PROP_TEXT_SUB,
+},
/* other kind of codecs and pseudo-codecs */
{
diff --git a/libavcodec/usfdec.c b/libavcodec/usfdec.c
new file mode 100644
index 000..37cf331
--- /dev/null
+++ b/libavcodec/usfdec.c
@@ -0,0 +1,126 @@
+/*
+ * Copyright (c) 2016 Gerion Entrup
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Universal subtitle decoder
+ * @see http://www.titlevision.dk/usf.htm
+ */
+
+#include "ass.h"
+#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
+#include "htmlsubtitles.h"
+
+typedef struct {
+AVBPrint content;
+AVBPrint encoded_content;
+int readorder;
+} USFContext;
+
+static int usf_paragraph_to_ass(AVCodecContext *avctx, const char *src)
+{
+USFContext *usf = avctx->priv_data;
+int ret = 0;
+char *dupsrc = av_strdup(src);
+char *end, *p = dupsrc;
+AVBPrint *dst_content = &
Re: [FFmpeg-devel] Subtitles for GSoC
On Dienstag, 8. März 2016 20:42:39 CET Clément Bœsch wrote:
> On Tue, Mar 08, 2016 at 06:21:12PM +0100, Gerion Entrup wrote:
> > Hello,
> >
>
> Hi,
>
> > my own ideas seems not to be suitable for GSoC, so I looked again on the
> > ideas page,
> > because I have high interest to do something for FFmpeg this summer.
> >
> > The project, that I find most interesting, unfortunately is a unmentored
> > one, the subtitle
> > support. Is someone willing to mentor this?
> >
>
> I added this task for previous OPW (and maybe GSoC, can't remember). I'm
> unfortunately not available for mentoring (too much time, energy and
> responsibility). Though, I can provide standard help as a developer.
>
> The main issue with this task is that it involves API redesign, which is
> often not a good idea for a GSoC task.
>
> That said, a bunch of core limitations have been solved in the past so
> it's starting to be comfortable to work on top of the current stack.
>
> I'm summarizing the current state at the end of this mail, which can be
> useful for any potential mentor and eventually student.
>
> > On the ideas page the mentioned subtitle for the qualification task is
> > Spruce subtitle. It
> > seems, it is already supported, so I would try to implement the corepart of
> > usf. I know
> > it is not widely used, but very powerful with similar features as SSA, if I
> > get it right. Do you
> > think, that is suitable?
> >
>
> Spruce has indeed been added in last OPW as a qualification task. USF is
> more painful but a basic support could be a potential qualification task
> indeed. You might be able to figure out something playing with the
> ff_smil_* functions for the demuxing part.
>
> So basically you would have to:
>
> - an USF demuxer which extracts the timing and text (with its markup) of
> every event, and put them into an AVPacket
>
> - introduce an USF codec and write a decoder that will transform the
> xml-like markup into ASS markup (see below)
I've implement such a demuxer and decoder, based on SAMI (see other mail).
But XML parsing with the builtin tools is a real pain and hard to extend later.
If the GSoC project come off, please let me change this and maybe the SAMI code
into code based on a xmllib. Header parsing should be doable then as well.
>
> Again, I'm not a mentor, so you need confirmation from someone else.
>
> > And then another question. You mentioned as ultimate goal the libavfilter
> > integration.
> > If I get it right, ATM no rendering is implemented, and libavfilter would
> > allow an (automatic)
> > rendering from SSA to e.g. dvdsub. Would the rendering itself part of the
> > project (because
> > this is very extensive, I think)?
> >
>
> So, yeah, currently the subtitles are decoded into an AVSubtitle
> structure, which hold one or several AVSubtitleRect (AVSubtitle.rects[N]).
>
> For graphic subtitles, each rectangle contains a paletted buffer and its
> position, size, ...
>
> For text subtitles, the ass field contains the text in ASS markup: indeed,
> we consider the ASS markup to be the best/least worst superset supporting
> almost every style of every other subtitles formats have, so it's used as
> the "decoded" form for all text subtitles. For example, the SubRip (the
> "codec", or markup you find in SRT files) decoder will transform
> "foo" into "{\i1}foo{\i0}".
>
> So far so good. Unfortunately, this is not sufficient, because the
> AVSubtitle* structs are old and not convenient for several reasons:
>
> - they are allocated on the stack by the users, so we can't extend them
> (add fields) without breaking the ABI (= angry users).
>
> - they are defined in libavcodec, and we do not want libavfilter to
> depend on libavcodec for a core feature (we have a few filters
> depending on it, but that's optional). As such, libavutil is a much
> better place for this, which already contains the AVFrame.
>
> - the graphic subtitles are kind of limited (palette only, can't hold YUV
> or RGB32 pixel formats for instance)
>
> - the handling of the timing is inconsistent: pts is in AV_TIME_BASE and
> start/end display time are relative and in ms.
>
> When these issues are sorted out, we can finally work on the integration
> within libavfilter, which is yet another topic where other developers
> might want to comment. Typically, I'm not sure what is the state of
> dealing with the sparse property of the subtitles. Nicolas may know :)
>
> Anyway, there are multiple ways of dealing with the
Re: [FFmpeg-devel] Subtitles for GSoC
On Donnerstag, 10. März 2016 20:20:20 CET Derek Buitenhuis wrote: > On 3/10/2016 8:11 PM, wm4 wrote: > > Since XML libraries are apparently always broken, bloated, insecure, and > > hard to use, that has always been a point of contention. Although it > > would be the right approach. > > You're not going to find an XML library that is not annoying/hard to use > because XML is annoying/hard to use correctly. I have never used a C XML library, but Java and Python. Both are much simpler to use than manual parsing and are escpecially consistent. For example, what if the string for the tag is in a comment (something like ). I guess then both demuxers with the current approach would fail. Of course some could fix this case with a lot of ifs, but I guess, without proper parsing the code becomes unreadable soon. So maybe we could say, a library is less annoying than manual parsing. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Subtitles for GSoC
On Donnerstag, 10. März 2016 22:47:38 CET Clément Bœsch wrote: > On Thu, Mar 10, 2016 at 06:12:57PM +0100, Gerion Entrup wrote: > [...] > > > > - an USF demuxer which extracts the timing and text (with its markup) of > > > > > > every event, and put them into an AVPacket > > > > > > - introduce an USF codec and write a decoder that will transform the > > > > > > xml-like markup into ASS markup (see below) > > > > I've implement such a demuxer and decoder, based on SAMI (see other mail). > > But XML parsing with the builtin tools is a real pain and hard to extend > > later. > > > > If the GSoC project come off, please let me change this and maybe the SAMI > > code into code based on a xmllib. Header parsing should be doable then as > > well. > I don't mind that much, but keep in mind that SAMI is typically an old > broken mutant HTML based format, with unclosed tags and various other > insanities. And aside from the madness of the specifications, you have no > idea how broken the files in the wild can be. If you want to pick a > library, you have to make sure it's able to fallback on its feet when > getting unexpected input. Doing a memory search for the timing marker is > often the most reliable thing to do when dealing with subtitles, in > general. > > [...] Combining this with the idea of Nicolas could work. To specify, write a (generic) xml parser, but add the ability to say, the tag XY is more important than other tags and also could not be nested. A parser then could parse the XML file normally up to point where the file is broken (closing tag not reached etc.) outputs a warning, but search for the next "important" tag. But back to GSoC. I'm assuming that sadly noone is willing to mentor this project (have waited quite a time). So I'm thinking to look for another task and therefore a question: What do you think will be the (mentored) task, that will bring the innermost understanding of the framework? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] add signature filter for MPEG7 video signature
Good day,
I attached the patch. The MPEG7 video signature is a method to calculate a
fingerprint of a video and to compare two or more of this fingerprints. Most of
the standard is implemented. I've done this work as part of my bachelor
thesis.
The method is designed mainly for fast caculation of the fingerprint, so it is
blockbased and not very robust to some geometric modification.
Further details can be found at
http://epubs.surrey.ac.uk/531590/1/MPEG-7%20Video%20Signature%20Author%27s
%20Copy.pdf
kind regards,
Gerion
>From 6eeb0a8b4fce06d98265ce2cf1936ff092de137b Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Sun, 20 Mar 2016 11:10:31 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- binary output
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
doc/filters.texi | 50
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 569
libavfilter/signature_lookup.c | 518 +
libavfilter/version.h | 4 +-
libavfilter/vf_signature.c | 636 +
8 files changed, 1778 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/signature.h
create mode 100644 libavfilter/signature_lookup.c
create mode 100644 libavfilter/vf_signature.c
diff --git a/Changelog b/Changelog
index 1f57f5e..7c1316a 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
version :
+- MPEG-7 Video Signature filter
- DXVA2-accelerated HEVC Main10 decoding
- fieldhint filter
- loop video filter and aloop audio filter
diff --git a/doc/filters.texi b/doc/filters.texi
index c093927..22d6326 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11444,6 +11444,56 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
@end example
@end itemize
+@anchor{signature}
+@section signature
+
+Calculates the MPEG-7 Video Signature. The filter could handle more than one input. In this case the matching between the inputs could be calculated. The filter passthrough the first input. The output is written in XML.
+
+It accepts the following options:
+
+@table @option
+@item mode
+Enable the calculation of the matching. The option value must be 0 (to disable or 1 (to enable). Optionally you can set the mode to 2. Then the detection ends, if the first matching sequence it reached. This should be slightly faster. Per default the detection is disabled.
+
+@item nb_inputs
+Set the number of inputs. The option value must be a non negative interger. Default value is 1.
+
+@item filename
+Set the path to witch the output is written. If there is more than one input, the path must be a prototype, i.e. must contain %d or %0nd (where n is a positive integer), that will be replaced with the input number. If no filename is specified, no output will be written. This is the default.
+
+@item th_d
+Set threshold to detect one word as similar. The option value must be an integer greater than zero. The default value is 9000.
+
+@item th_dc
+Set threshold to detect all words as similar. The option value must be an integer greater than zero. The default value is 6.
+
+@item th_xh
+Set threshold to detect frames as similar. The option value must be an integer greater than zero. The default value is 116.
+
+@item th_di
+Set the minimum length of a sequence in frames to recognize it as matching sequence. The option value must be a non negative integer value. The default value is 0.
+
+@item th_it
+Set the minimum relation, that matching frames to all frames must have. The option value must be a double value between 0 and 1. The default value is 0.5.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+To calculate the signature of an input video and store it in signature.xml:
+@example
+ffmpeg -i input.mkv -vf signature=filename=signature.xml -map 0:v -c rawvideo -f null /dev/null
+@end example
+
+@item
+To detect whether two videos matches and store the signatures in signature0.xml and signature1.xml:
+@example
+ffmpeg -i input1.mkv -i input2.mkv -filter_complex "[0:0][1:0] signature=nb_inputs=2:detectmode=1signature%d.xml" -map 0:v -map 1:v -c rawvideo -f null /dev/null
+@end example
+
+@end itemize
+
@anchor{smartblur}
@section smartblur
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 956a077..f48eeaf 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -245,6 +245,7 @@ OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
OBJS-$(CONFIG_SHUFFLEFRAMES_FILTER) += vf_shuffleframes.o
OBJS-$(CONFIG_SHUFFLEPLANES_FILTER) += vf_shuffleplanes.o
OBJS-$(CONFIG_
Re: [FFmpeg-devel] [PATCH] add signature filter for MPEG7 video signature
On Sonntag, 20. März 2016 12:57:33 CET Michael Niedermayer wrote:
> On Sun, Mar 20, 2016 at 12:00:13PM +0100, Gerion Entrup wrote:
> [...]
>
> > +++ b/libavfilter/signature.h
> > @@ -0,0 +1,569 @@
> > +/*
> > + * Copyright (c) 2016 Gerion Entrup
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > along
> > + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > + */
> > +
> > +/**
> > + * @file
> > + * MPEG-7 video signature calculation and lookup filter
> > + */
> > +
> > +#include
> > +#include "libavutil/opt.h"
> > +#include "libavutil/timestamp.h"
> > +#include "avfilter.h"
> > +#include "internal.h"
> > +#include
> > +
> > +#define ELEMENT_COUNT 10
> > +#define SIGELEM_SIZE 380
> > +#define DIFFELEM_SIZE 348 /* SIGELEM_SIZE - elem_a1 - elem_a2 */
> > +#define COURSE_SIZE 90
> > +
> > +typedef struct {
> > +int x;
> > + int y;
> > +} Point;
> > +
> > +typedef struct {
> > +Point up;
> > +Point to;
> > +} Block;
>
> missing standard duplicate inclusion guards
>
> [...]
Fixed. Also put { in a seperate line for functions.
>From bf27c15e003ce57d986989da3ca6f16d7798f6bb Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Sun, 20 Mar 2016 11:10:31 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- binary output
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
doc/filters.texi | 50
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 574
libavfilter/signature_lookup.c | 527 +
libavfilter/version.h | 4 +-
libavfilter/vf_signature.c | 639 +
8 files changed, 1795 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/signature.h
create mode 100644 libavfilter/signature_lookup.c
create mode 100644 libavfilter/vf_signature.c
diff --git a/Changelog b/Changelog
index 1f57f5e..7c1316a 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
version :
+- MPEG-7 Video Signature filter
- DXVA2-accelerated HEVC Main10 decoding
- fieldhint filter
- loop video filter and aloop audio filter
diff --git a/doc/filters.texi b/doc/filters.texi
index c093927..22d6326 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11444,6 +11444,56 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
@end example
@end itemize
+@anchor{signature}
+@section signature
+
+Calculates the MPEG-7 Video Signature. The filter could handle more than one input. In this case the matching between the inputs could be calculated. The filter passthrough the first input. The output is written in XML.
+
+It accepts the following options:
+
+@table @option
+@item mode
+Enable the calculation of the matching. The option value must be 0 (to disable or 1 (to enable). Optionally you can set the mode to 2. Then the detection ends, if the first matching sequence it reached. This should be slightly faster. Per default the detection is disabled.
+
+@item nb_inputs
+Set the number of inputs. The option value must be a non negative interger. Default value is 1.
+
+@item filename
+Set the path to witch the output is written. If there is more than one input, the path must be a prototype, i.e. must contain %d or %0nd (where n is a positive integer), that will be replaced with the input number. If no filename is specified, no output will be written. This is the default.
+
+@item th_d
+Set threshold to detect one word as similar. The option value must be an integer greater than zero. The default value is 9000.
+
+@item th_dc
+Set threshold to detect all words as similar. The option va
Re: [FFmpeg-devel] [PATCH] add signature filter for MPEG7 video signature
On Sonntag, 20. März 2016 15:46:12 CET Gerion Entrup wrote:
> On Sonntag, 20. März 2016 12:57:33 CET Michael Niedermayer wrote:
> > On Sun, Mar 20, 2016 at 12:00:13PM +0100, Gerion Entrup wrote:
> > [...]
> >
> > > +++ b/libavfilter/signature.h
> > > @@ -0,0 +1,569 @@
> > > +/*
> > > + * Copyright (c) 2016 Gerion Entrup
> > > + *
> > > + * This file is part of FFmpeg.
> > > + *
> > > + * FFmpeg is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + *
> > > + * FFmpeg is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU General Public License
> > > along
> > > + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> > > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > > + */
> > > +
> > > +/**
> > > + * @file
> > > + * MPEG-7 video signature calculation and lookup filter
> > > + */
> > > +
> > > +#include
> > > +#include "libavutil/opt.h"
> > > +#include "libavutil/timestamp.h"
> > > +#include "avfilter.h"
> > > +#include "internal.h"
> > > +#include
> > > +
> > > +#define ELEMENT_COUNT 10
> > > +#define SIGELEM_SIZE 380
> > > +#define DIFFELEM_SIZE 348 /* SIGELEM_SIZE - elem_a1 - elem_a2 */
> > > +#define COURSE_SIZE 90
> > > +
> > > +typedef struct {
> > > +int x;
> > > +int y;
> > > +} Point;
> > > +
> > > +typedef struct {
> > > + Point up;
> > > +Point to;
> > > +} Block;
> >
> > missing standard duplicate inclusion guards
> >
> > [...]
>
> Fixed. Also put { in a seperate line for functions.
On Sonntag, 20. März 2016 12:39:53 CET Paul B Mahol wrote:
> If this is supposed to be GPL only, you need to modify other files.
This was my intention. I've added the missing configure line (sorry for double
mail).
>From 40a2bd689abe8873a9844d79ec59b2b7bb3fba30 Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Sun, 20 Mar 2016 11:10:31 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- binary output
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 50
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 574
libavfilter/signature_lookup.c | 527 +
libavfilter/version.h | 4 +-
libavfilter/vf_signature.c | 639 +
9 files changed, 1796 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/signature.h
create mode 100644 libavfilter/signature_lookup.c
create mode 100644 libavfilter/vf_signature.c
diff --git a/Changelog b/Changelog
index 1f57f5e..7c1316a 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
version :
+- MPEG-7 Video Signature filter
- DXVA2-accelerated HEVC Main10 decoding
- fieldhint filter
- loop video filter and aloop audio filter
diff --git a/configure b/configure
index e5de306..757b180 100755
--- a/configure
+++ b/configure
@@ -2953,6 +2953,7 @@ showspectrum_filter_deps="avcodec"
showspectrum_filter_select="fft"
showspectrumpic_filter_deps="avcodec"
showspectrumpic_filter_select="fft"
+signature_filter_deps="gpl"
smartblur_filter_deps="gpl swscale"
sofalizer_filter_deps="netcdf avcodec"
sofalizer_filter_select="fft"
diff --git a/doc/filters.texi b/doc/filters.texi
index c093927..22d6326 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11444,6 +11444,56 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
@end example
@end itemize
+@anchor{signature}
+@section signature
+
+Calculates the MPEG-7 Video Signature. The filter could handle more than one input. In this case th
Re: [FFmpeg-devel] [PATCH] add signature filter for MPEG7 video signature
On Sonntag, 20. März 2016 17:01:17 CET Thilo Borgmann wrote: > > On Sun, Mar 20, 2016 at 12:00:13PM +0100, Gerion Entrup wrote: > [...] > > > This filter does not implement all features of MPEG7. Missing features: > > > > - binary output > > - compression of signature files > > I assume these features are optional? Compression is optional (could be set as flag in the binary representation). I have not found, whether binary output is optional. It is definitely possible to only work with the XML-Files. > > > - work only on (cropped) parts of the video > > How useful is this then? Has fingerprint computed only on (cropped) parts of > the video any value outside of FFmpeg itself - does this comply to the spec > so that it can be compared with any other software generating it? To clarify, the filter does not crop anything. The standard defines an optional cropping to, I guess, concentrate on specific video parts (this is not implemented). Assuming someone is recording a monitor, then e.g. the unrelated part of the video could be cropped out. Beside that, the signature itself is invariant to cropping up to a certain limit. The cropping values (upper left and bottom right position are specified in the xml, so another software could either crop the same way or compare only with the cropped input. (The fact, that ffmpeg has a cropping filter, would make such a feature some kind of redundant.) The XML is standard compliant. The signature is not bitexact. 3-4 (ternary) values in the framesignature differ from the signature of the sample files, but the conformence tests [1] allow up to 15 ternaryerrors. I'm not exactly sure why the difference occur, I guess, this are floating point issues, because my implementation calculates the values with a slightly different method than the reference software. Currently, I don't have the sample files anymore. If there is interest, I will try to get them again. [1] https://www.itscj.ipsj.or.jp/sc29/open/29view/29n11696t.doc ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add signature filter for MPEG7 video signature
On Sonntag, 20. März 2016 16:52:36 CET Clément Bœsch wrote: > On Sun, Mar 20, 2016 at 12:00:13PM +0100, Gerion Entrup wrote: > > Good day, > > > > I attached the patch. The MPEG7 video signature is a method to calculate a > > fingerprint of a video and to compare two or more of this fingerprints. > > Most of the standard is implemented. I've done this work as part of my > > bachelor thesis. > > > > The method is designed mainly for fast caculation of the fingerprint, so > > it is blockbased and not very robust to some geometric modification. > > > > > > Further details can be found at > > http://epubs.surrey.ac.uk/531590/1/MPEG-7%20Video%20Signature%20Author%27s > > %20Copy.pdf > > use a @see in the code (typically in the @file section) Wrap the url, too? > > +Calculates the MPEG-7 Video Signature. The filter could handle more than one input. In this case the matching between the inputs could be calculated. The filter passthrough the first input. The output is written in XML. > > + > > please wrap the text, same below Also wrap the commands in the example section? > > > > diff --git a/libavfilter/signature.h b/libavfilter/signature.h > > new file mode 100644 > > index 000..6f0584b > > --- /dev/null > > +++ b/libavfilter/signature.h > > @@ -0,0 +1,569 @@ > > +/* > > + * Copyright (c) 2016 Gerion Entrup > > + * > > + * This file is part of FFmpeg. > > + * > > + * FFmpeg is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * FFmpeg is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License > > along > > + * with FFmpeg; if not, write to the Free Software Foundation, Inc., > > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > > + */ > > + > > GPL? This is intended. > > +/** > > + * @file > > + * MPEG-7 video signature calculation and lookup filter > > + */ > > + > > +#include > > +#include "libavutil/opt.h" > > +#include "libavutil/timestamp.h" > > +#include "avfilter.h" > > +#include "internal.h" > > > > +#include > > please no, use ints. Done. For interest, why? This is not related to performance, I guess. I find bools a lot of more readable. Updated patch attached. > > [...] > > I'll eventually make a more complete review at the next iteration. >From 026a2194c8b622d70bf38fa67c741882e09edbc3 Mon Sep 17 00:00:00 2001 From: Gerion Entrup Date: Sun, 20 Mar 2016 11:10:31 +0100 Subject: [PATCH] add signature filter for MPEG7 video signature This filter does not implement all features of MPEG7. Missing features: - binary output - compression of signature files - work only on (cropped) parts of the video --- Changelog | 1 + configure | 1 + doc/filters.texi | 66 + libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/signature.h| 573 libavfilter/signature_lookup.c | 527 + libavfilter/version.h | 4 +- libavfilter/vf_signature.c | 639 + 9 files changed, 1811 insertions(+), 2 deletions(-) create mode 100644 libavfilter/signature.h create mode 100644 libavfilter/signature_lookup.c create mode 100644 libavfilter/vf_signature.c diff --git a/Changelog b/Changelog index 1f57f5e..5b76607 100644 --- a/Changelog +++ b/Changelog @@ -12,6 +12,7 @@ version : - ciescope filter - protocol blacklisting API - MediaCodec H264 decoding +- MPEG-7 Video Signature filter version 3.0: diff --git a/configure b/configure index e5de306..757b180 100755 --- a/configure +++ b/configure @@ -2953,6 +2953,7 @@ showspectrum_filter_deps="avcodec" showspectrum_filter_select="fft" showspectrumpic_filter_deps="avcodec" showspectrumpic_filter_select="fft" +signature_filter_deps="gpl" smartblur_filter_deps="gpl swscale" sofalizer_filter_deps="netcdf avcodec" sofalizer_filter_select="fft" diff --git a/doc/filters.texi b/doc/filters.texi index c093927..65a7eab 100644 --- a/doc/filt
Re: [FFmpeg-devel] [PATCH] add signature filter for MPEG7 video signature
On Montag, 21. März 2016 11:53:27 CET Thilo Borgmann wrote: > Am 21.03.16 um 00:14 schrieb Gerion Entrup: > > On Sonntag, 20. März 2016 17:01:17 CET Thilo Borgmann wrote: > >>> On Sun, Mar 20, 2016 at 12:00:13PM +0100, Gerion Entrup wrote: > >> [...] > >> > >>> This filter does not implement all features of MPEG7. Missing features: > >>> > >>> - binary output > >>> - compression of signature files > >> > >> I assume these features are optional? > > > > Compression is optional (could be set as flag in the binary > > representation). I have not found, whether binary output is optional. > > > > It is definitely possible to only work with the XML-Files. > > Of course, but having an unspecified XML output is almost useless if binary > output is not optional. So I think it is crucial to know what the spec says > about output. The spec defines the XML output my filter do atm and specifies a binary output additional. > > >>> - work only on (cropped) parts of the video > >> > >> How useful is this then? Has fingerprint computed only on (cropped) parts > >> of the video any value outside of FFmpeg itself - does this comply to > >> the spec so that it can be compared with any other software generating > >> it? > > > > To clarify, the filter does not crop anything. The standard defines an > > optional cropping to, I guess, concentrate on specific video parts (this > > is not implemented). Assuming someone is recording a monitor, then e.g. > > the unrelated part of the video could be cropped out. Beside that, the > > signature itself is invariant to cropping up to a certain limit. > > > > The cropping values (upper left and bottom right position are specified in > > the xml, so another software could either crop the same way or compare > > only with the cropped input. > > (The fact, that ffmpeg has a cropping filter, would make such a feature > > some kind of redundant.) > > If I understand it correctly, the filter should not crop the image but only > use the pixel information within the specified area or the whole image. > Making it a filter option is useful, because the fingerprint of a part of > the image can be used in a filter chain continuing with the entire image > (no actual crop is required). Of course it would be great, if the filter would support it. It needs some modification to the summed area table. Once the binary output is ready, I will try to do it. > > > The XML is standard compliant. > > So XML output is compliant to the spec? Or is the XML itself just valid XML? The XML output is compliant to the spec. The whole format is specified there. > > The signature is not bitexact. 3-4 (ternary) > > values in the framesignature differ from the signature of the sample > > files, but the conformence tests [1] allow up to 15 ternaryerrors. > > Bitexact compared to what? The institute, where I write the filter, owns the sample files mentioned in the doc together with the correspondent binary and XML signatures (so I could compare it). > Does it allow up to 15 ternary errors for assume two inputs are equal enough > to be the same image or does it state that the fingerprint itself may > differ for 15 ternary errors for the very same image? The 15 tenary errors are valid between the sample signature and the reimplementation for the same sample. But ok, you seem to be right, the binary representation seems to be necessary. I quote (out of the linked doc): "The number of dimensions whose ternary values differ between the test and the reference video signatures shall be less than or equal to 15 out of 380, if the FrameConfidence values of both the test and the reference video signatures are greater than or equal to 4. The ternary values of the frame signature shall be decoded from the binary representation according to Table E.1." At the moment the XML output of my filter comparing to the given XML output of the sample file fulfills the condition (except of the last sentence of course). I'll try to implement the binary output as well, controlled by a flag. > > > I'm not exactly sure > > why the difference occur, I guess, this are floating point issues, because > > my implementation calculates the values with a slightly different method > > than the reference software. Currently, I don't have the sample files > > anymore. If there is interest, I will try to get them again. > > > > [1] https://www.itscj.ipsj.or.jp/sc29/open/29view/29n11696t.doc > > Being compliant to the reference output is crucial, otherwise we calculate > just some fingerprint but not the MPEG7
Re: [FFmpeg-devel] [PATCH] add signature filter for MPEG7 video signature
On Montag, 21. März 2016 11:55:47 CET Clément Bœsch wrote: > On Mon, Mar 21, 2016 at 12:27:13AM +0100, Gerion Entrup wrote: > > On Sonntag, 20. März 2016 16:52:36 CET Clément Bœsch wrote: > > > On Sun, Mar 20, 2016 at 12:00:13PM +0100, Gerion Entrup wrote: > > > > Good day, > > > > > > > > I attached the patch. The MPEG7 video signature is a method to > > > > calculate a > > > > fingerprint of a video and to compare two or more of this > > > > fingerprints. > > > > Most of the standard is implemented. I've done this work as part of my > > > > bachelor thesis. > > > > > > > > The method is designed mainly for fast caculation of the fingerprint, > > > > so > > > > it is blockbased and not very robust to some geometric modification. > > > > > > > > > > > > Further details can be found at > > > > http://epubs.surrey.ac.uk/531590/1/MPEG-7%20Video%20Signature%20Author > > > > %27s > > > > %20Copy.pdf > > > > > > use a @see in the code (typically in the @file section) > > > > Wrap the url, too? > > What do you mean? The URL is longer than 80 chars, so it could be wanted that it is wrapped in the source. But because of your enquiry, I guess, this is not necessary. > > > > > +Calculates the MPEG-7 Video Signature. The filter could handle more > > > > than > > > > one input. In this case the matching between the inputs could be > > calculated. The filter passthrough the first input. The output is written > > in XML.> > > > > + > > > > > > please wrap the text, same below > > > > Also wrap the commands in the example section? > > Not the verbatim/pre/blockcode, just the text > > > > > diff --git a/libavfilter/signature.h b/libavfilter/signature.h > > > > new file mode 100644 > > > > index 000..6f0584b > > > > --- /dev/null > > > > +++ b/libavfilter/signature.h > > > > @@ -0,0 +1,569 @@ > > > > +/* > > > > + * Copyright (c) 2016 Gerion Entrup > > > > + * > > > > + * This file is part of FFmpeg. > > > > + * > > > > + * FFmpeg is free software; you can redistribute it and/or modify > > > > + * it under the terms of the GNU General Public License as published > > > > by > > > > + * the Free Software Foundation; either version 2 of the License, or > > > > + * (at your option) any later version. > > > > + * > > > > + * FFmpeg is distributed in the hope that it will be useful, > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > > + * GNU General Public License for more details. > > > > + * > > > > + * You should have received a copy of the GNU General Public License > > > > along > > > > + * with FFmpeg; if not, write to the Free Software Foundation, Inc., > > > > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > > > > + */ > > > > + > > > > > > GPL? > > > > This is intended. > > don't forget to update the LICENSE file. I'll do it in the next iteration. > > > > > +/** > > > > + * @file > > > > + * MPEG-7 video signature calculation and lookup filter > > > > + */ > > > > + > > > > +#include > > > > +#include "libavutil/opt.h" > > > > +#include "libavutil/timestamp.h" > > > > +#include "avfilter.h" > > > > +#include "internal.h" > > > > > > > > +#include > > > > > > please no, use ints. > > > > Done. For interest, why? This is not related to performance, I guess. > > I find bools a lot of more readable. > > first, because we don't use it anywhere else in the code, so for > consistency at least. There is also risk of incompatibility. And then you > end up using bool in various places assuming you know the size, where it > could actually be platform dependant. So typically using it with > AV_OPT_TYPE_BOOL could actually lead to invalid size writing/reading > (similar issue as with using enum instead of ints). > > [...] Ok, understood. Thank you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add signature filter for MPEG7 video signature
On Montag, 21. März 2016 15:00:52 CET Thilo Borgmann wrote: > Am 21.03.16 um 14:15 schrieb Gerion Entrup: > > On Montag, 21. März 2016 11:53:27 CET Thilo Borgmann wrote: > >> Am 21.03.16 um 00:14 schrieb Gerion Entrup: > >>> On Sonntag, 20. März 2016 17:01:17 CET Thilo Borgmann wrote: > >>>>> On Sun, Mar 20, 2016 at 12:00:13PM +0100, Gerion Entrup wrote: > >>>> [...] > >>>> > >>>>> This filter does not implement all features of MPEG7. Missing > >>>>> features: > >>>>> > >>>>> - binary output > >>>>> - compression of signature files > >>>> > >>>> I assume these features are optional? > >>> > >>> Compression is optional (could be set as flag in the binary > >>> representation). I have not found, whether binary output is optional. > >>> > >>> It is definitely possible to only work with the XML-Files. > >> > >> Of course, but having an unspecified XML output is almost useless if > >> binary > >> output is not optional. So I think it is crucial to know what the spec > >> says > >> about output. > > > > The spec defines the XML output my filter do atm and specifies a binary > > output additional. > > > >>>>> - work only on (cropped) parts of the video > >>>> > >>>> How useful is this then? Has fingerprint computed only on (cropped) > >>>> parts > >>>> of the video any value outside of FFmpeg itself - does this comply to > >>>> the spec so that it can be compared with any other software generating > >>>> it? > >>> > >>> To clarify, the filter does not crop anything. The standard defines an > >>> optional cropping to, I guess, concentrate on specific video parts (this > >>> is not implemented). Assuming someone is recording a monitor, then e.g. > >>> the unrelated part of the video could be cropped out. Beside that, the > >>> signature itself is invariant to cropping up to a certain limit. > >>> > >>> The cropping values (upper left and bottom right position are specified > >>> in > >>> the xml, so another software could either crop the same way or compare > >>> only with the cropped input. > >>> (The fact, that ffmpeg has a cropping filter, would make such a feature > >>> some kind of redundant.) > >> > >> If I understand it correctly, the filter should not crop the image but > >> only > >> use the pixel information within the specified area or the whole image. > >> Making it a filter option is useful, because the fingerprint of a part of > >> the image can be used in a filter chain continuing with the entire image > >> (no actual crop is required). > > > > Of course it would be great, if the filter would support it. It needs some > > modification to the summed area table. Once the binary output is ready, I > > will try to do it. > > > >>> The XML is standard compliant. > >> > >> So XML output is compliant to the spec? Or is the XML itself just valid > >> XML?> > > The XML output is compliant to the spec. The whole format is specified > > there.> > >>> The signature is not bitexact. 3-4 (ternary) > >>> values in the framesignature differ from the signature of the sample > >>> files, but the conformence tests [1] allow up to 15 ternaryerrors. > >> > >> Bitexact compared to what? > > > > The institute, where I write the filter, owns the sample files mentioned > > in the doc together with the correspondent binary and XML signatures (so > > I could compare it). > > > >> Does it allow up to 15 ternary errors for assume two inputs are equal > >> enough to be the same image or does it state that the fingerprint itself > >> may differ for 15 ternary errors for the very same image? > > > > The 15 tenary errors are valid between the sample signature and the > > reimplementation for the same sample. > > > > But ok, you seem to be right, the binary representation seems to be > > necessary. I quote (out of the linked doc): > > > > "The number of dimensions whose ternary values differ between the test and > > the reference video signatures shall be less than or equal to 15 out of > > 380, if the FrameConfidence values of both the test and the reference > > video signatures are great
[FFmpeg-devel] GSoC again
Good day, my previous attempts for GSoC aren't very successful. I talked with Carl Eugen about GSoC. He advise me to choose a project with clear aims that fits clearly into the scope of the framework. Such a thing would be MPEG DASH demuxing [1] , so I want to bring it up as suggestion. DASH is a streaming format for adaptively choose various bitrates and formats. The content is therefore splitted in segments, that could be switched. All relevant data are found in a XML-based MPD file (sample [2]). Currently FFmpeg supports DASH muxing and in the mov demuxer was some work for fragments (correct me if I'm wrong). Beside that, FFmpeg could handle HLS, which is a similar m3u based format. My work in the GSoC could be: 1. Implement a robust (to errors) generic XML-Parser. 2. Implement a MPD demuxer, that could handle the parsing and the segments. 3. Implement adaptive switching. A note to the 3rd point. I'm absolutely not sure, what amount of work this is (maybe you could comment it) and what the best place would be to implement this (including whether this whole feature is meaningful). I would say, this could be either in the demuxer itself or in ffplay (can decide a muxer such a thing, like bandwidth?). Personal benefits: I hope to learn something about (beside DASH as format): - the protocol handling and the connection between demuxer and protocol - ffplay - obviously the demuxer functions My qualification task could be: 1. Write a simple demuxer (as a draft!), that could handle the mpd file [2], so that the first stream is recognized. The orientation points I would work with are the already existing hls demuxer, the specification [3] and maybe libdash [4] (C++ library). The biggest problem with this task is a missing mentor :). Maybe someone is excited about this feature and willing to support me. kind regards, Gerion [1] https://trac.ffmpeg.org/ticket/5269 [2] http://dash.edgesuite.net/dash264/TestCases/1a/netflix/exMPD_BIP_TC1.mpd [3] http://standards.iso.org/ittf/PubliclyAvailableStandards/c065274_ISO_IEC_23009-1_2014.zip [4] https://github.com/bitmovin/libdash ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
Attached improved version of patch.
Differences to last time:
- reduce amount of errors in the signature (the last patch included some int
foo = a/b). This version replaces this with a rational.
- implement binary output.
- fixes in configure, some typos
I have found the conformance testfiles [1]. Both the binary and the xml output
passes the conformance test but are not bitexact. I wrote some python script
to prove this (see attachment). I don't see why this happens. If someone want
to help, the correspondent reference code is in the file
"ExtractionUtilities/VideoSignatureExtraction.cpp" beginning with line 1615,
that could be found here [2].
Then a few questions:
- The timebase of the testfiles is 9. In the binary output unfortunately
there
is only place for a 16 bit number, so this don't fit. Currently the code simply
crop
remaining bits. Is there a better solution (devide with some number etc)?
- I try to use put_bits32 where it is possible, because I thought is is faster.
Then
I saw it internally uses put_bits as well. Does it have a performance impact to
replace it with put_bits(..., 8, ...) (would simplify the code a lot)?
Gerion
[1]
http://standards.iso.org/ittf/PubliclyAvailableStandards/c057047_ISO_IEC_15938-7_2003_Amd_6_2011_Conformance_Testing.zip
[2]
http://standards.iso.org/ittf/PubliclyAvailableStandards/c056735_ISO_IEC_15938-6_2003_Amd_4_2011_Electronic_inserts.zip>From c81db6a999694f01335ee0d88483f276f2d10d3f Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Sun, 20 Mar 2016 11:10:31 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 70
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 574 ++
libavfilter/signature_lookup.c | 527
libavfilter/version.h | 4 +-
libavfilter/vf_signature.c | 774 +
9 files changed, 1951 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/signature.h
create mode 100644 libavfilter/signature_lookup.c
create mode 100644 libavfilter/vf_signature.c
diff --git a/Changelog b/Changelog
index 1f57f5e..5b76607 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
- ciescope filter
- protocol blacklisting API
- MediaCodec H264 decoding
+- MPEG-7 Video Signature filter
version 3.0:
diff --git a/configure b/configure
index e5de306..372b847 100755
--- a/configure
+++ b/configure
@@ -2953,6 +2953,7 @@ showspectrum_filter_deps="avcodec"
showspectrum_filter_select="fft"
showspectrumpic_filter_deps="avcodec"
showspectrumpic_filter_select="fft"
+signature_filter_deps="gpl avcodec avformat"
smartblur_filter_deps="gpl swscale"
sofalizer_filter_deps="netcdf avcodec"
sofalizer_filter_select="fft"
diff --git a/doc/filters.texi b/doc/filters.texi
index c093927..feb9c7a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11444,6 +11444,76 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
@end example
@end itemize
+@anchor{signature}
+@section signature
+
+Calculates the MPEG-7 Video Signature. The filter could handle more than one
+input. In this case the matching between the inputs could be calculated. The
+filter passthrough the first input. The output is written in XML.
+
+It accepts the following options:
+
+@table @option
+@item mode
+Enable the calculation of the matching. The option value must be 0 (to disable
+or 1 (to enable). Optionally you can set the mode to 2. Then the detection ends,
+if the first matching sequence it reached. This should be slightly faster.
+Per default the detection is disabled.
+
+@item nb_inputs
+Set the number of inputs. The option value must be a non negative interger.
+Default value is 1.
+
+@item filename
+Set the path to witch the output is written. If there is more than one input,
+the path must be a prototype, i.e. must contain %d or %0nd (where n is a positive
+integer), that will be replaced with the input number. If no filename is
+specified, no output will be written. This is the default.
+
+@item xml
+Choose the output format. If set to 1 the filter will write XML, if set to 0
+the filter will write binary output. The default is 0.
+
+@item th_d
+Set threshold to detect one word as similar. The option value must be an integer
+greater than zero. The default value is 9000.
+
+@item th_dc
+Set threshold to detect all words as similar. The option value must be an integer
+greater than zero. The default value is 6.
+
+@item th_xh
+Set threshold to detect frames as similar. The option value must
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Mittwoch, 30. März 2016 15:29:27 CEST Michael Niedermayer wrote:
> On Wed, Mar 30, 2016 at 01:57:24PM +0200, Gerion Entrup wrote:
> > Attached improved version of patch.
> >
> > Differences to last time:
> > - reduce amount of errors in the signature (the last patch included some int
> > foo = a/b). This version replaces this with a rational.
> > - implement binary output.
> > - fixes in configure, some typos
> >
> > I have found the conformance testfiles [1]. Both the binary and the xml
> > output
> > passes the conformance test but are not bitexact. I wrote some python script
> > to prove this (see attachment). I don't see why this happens. If someone
> > want
> > to help, the correspondent reference code is in the file
> > "ExtractionUtilities/VideoSignatureExtraction.cpp" beginning with line 1615,
> > that could be found here [2].
> >
> > Then a few questions:
> > - The timebase of the testfiles is 9. In the binary output
> > unfortunately there
> > is only place for a 16 bit number, so this don't fit. Currently the code
> > simply crop
> > remaining bits. Is there a better solution (devide with some number etc)?
> >
> > - I try to use put_bits32 where it is possible, because I thought is is
> > faster. Then
> > I saw it internally uses put_bits as well. Does it have a performance
> > impact to
> > replace it with put_bits(..., 8, ...) (would simplify the code a lot)?
> >
> > Gerion
> >
> > [1]
> > http://standards.iso.org/ittf/PubliclyAvailableStandards/c057047_ISO_IEC_15938-7_2003_Amd_6_2011_Conformance_Testing.zip
> > [2]
> > http://standards.iso.org/ittf/PubliclyAvailableStandards/c056735_ISO_IEC_15938-6_2003_Amd_4_2011_Electronic_inserts.zip
>
> > Changelog |1
> > configure |1
> > doc/filters.texi | 70 +++
> > libavfilter/Makefile |1
> > libavfilter/allfilters.c |1
> > libavfilter/signature.h| 574 ++
> > libavfilter/signature_lookup.c | 527 +++
> > libavfilter/version.h |4
> > libavfilter/vf_signature.c | 774
> > +
> > 9 files changed, 1951 insertions(+), 2 deletions(-)
> > 18a73574782a4e5e576bed3857fd283a009ff532
> > 0001-add-signature-filter-for-MPEG7-video-signature.patch
> > From c81db6a999694f01335ee0d88483f276f2d10d3f Mon Sep 17 00:00:00 2001
> > From: Gerion Entrup
> > Date: Sun, 20 Mar 2016 11:10:31 +0100
> > Subject: [PATCH] add signature filter for MPEG7 video signature
> >
> > This filter does not implement all features of MPEG7. Missing features:
> > - compression of signature files
> > - work only on (cropped) parts of the video
> > ---
> > Changelog | 1 +
> > configure | 1 +
> > doc/filters.texi | 70
> > libavfilter/Makefile | 1 +
> > libavfilter/allfilters.c | 1 +
> > libavfilter/signature.h| 574 ++
> > libavfilter/signature_lookup.c | 527
> > libavfilter/version.h | 4 +-
> > libavfilter/vf_signature.c | 774
> > +
> > 9 files changed, 1951 insertions(+), 2 deletions(-)
> > create mode 100644 libavfilter/signature.h
> > create mode 100644 libavfilter/signature_lookup.c
> > create mode 100644 libavfilter/vf_signature.c
> >
> > diff --git a/Changelog b/Changelog
> > index 1f57f5e..5b76607 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -12,6 +12,7 @@ version :
> > - ciescope filter
> > - protocol blacklisting API
> > - MediaCodec H264 decoding
> > +- MPEG-7 Video Signature filter
> >
> >
> > version 3.0:
> [...]
>
> > +typedef struct {
> > +int x;
> > +int y;
> > +} Point;
> > +
> > +typedef struct {
> > +Point up;
> > +Point to;
> > +} Block;
>
> these are used for tables of small values, int which is 32bit
> would waste quite some space, can uint8_t be used too ?
Yes, all Points are < 32 .
>
>
> [...]
> > +/* bitcount[index] = amount of ones in (binary) index */
> > +static const int bitcount[256] =
> > +{
> > + 0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4,
> > + 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
> > + 1, 2, 2, 3, 2, 3, 3, 4,
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup wrote:
> Add improved patch.
Rebased to master.
>From 9646ed6f0cf78356cf2914a60705c98d8f21fe8a Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Sun, 20 Mar 2016 11:10:31 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 70
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 554 ++
libavfilter/signature_lookup.c | 550 ++
libavfilter/version.h | 4 +-
libavfilter/vf_signature.c | 741 +
9 files changed, 1921 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/signature.h
create mode 100644 libavfilter/signature_lookup.c
create mode 100644 libavfilter/vf_signature.c
diff --git a/Changelog b/Changelog
index 7b0187d..8a2b7fd 100644
--- a/Changelog
+++ b/Changelog
@@ -18,6 +18,7 @@ version :
- coreimage filter (GPU based image filtering on OSX)
- libdcadec removed
- bitstream filter for extracting DTS core
+- MPEG-7 Video Signature filter
version 3.0:
- Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/configure b/configure
index e550547..fe29827 100755
--- a/configure
+++ b/configure
@@ -2979,6 +2979,7 @@ showspectrum_filter_deps="avcodec"
showspectrum_filter_select="fft"
showspectrumpic_filter_deps="avcodec"
showspectrumpic_filter_select="fft"
+signature_filter_deps="gpl avcodec avformat"
smartblur_filter_deps="gpl swscale"
sofalizer_filter_deps="netcdf avcodec"
sofalizer_filter_select="fft"
diff --git a/doc/filters.texi b/doc/filters.texi
index 5d6cf52..a95f5a7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11559,6 +11559,76 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
@end example
@end itemize
+@anchor{signature}
+@section signature
+
+Calculates the MPEG-7 Video Signature. The filter could handle more than one
+input. In this case the matching between the inputs could be calculated. The
+filter passthrough the first input. The output is written in XML.
+
+It accepts the following options:
+
+@table @option
+@item mode
+Enable the calculation of the matching. The option value must be 0 (to disable
+or 1 (to enable). Optionally you can set the mode to 2. Then the detection ends,
+if the first matching sequence it reached. This should be slightly faster.
+Per default the detection is disabled.
+
+@item nb_inputs
+Set the number of inputs. The option value must be a non negative interger.
+Default value is 1.
+
+@item filename
+Set the path to witch the output is written. If there is more than one input,
+the path must be a prototype, i.e. must contain %d or %0nd (where n is a positive
+integer), that will be replaced with the input number. If no filename is
+specified, no output will be written. This is the default.
+
+@item xml
+Choose the output format. If set to 1 the filter will write XML, if set to 0
+the filter will write binary output. The default is 0.
+
+@item th_d
+Set threshold to detect one word as similar. The option value must be an integer
+greater than zero. The default value is 9000.
+
+@item th_dc
+Set threshold to detect all words as similar. The option value must be an integer
+greater than zero. The default value is 6.
+
+@item th_xh
+Set threshold to detect frames as similar. The option value must be an integer
+greater than zero. The default value is 116.
+
+@item th_di
+Set the minimum length of a sequence in frames to recognize it as matching
+sequence. The option value must be a non negative integer value.
+The default value is 0.
+
+@item th_it
+Set the minimum relation, that matching frames to all frames must have.
+The option value must be a double value between 0 and 1. The default value is 0.5.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+To calculate the signature of an input video and store it in signature.xml:
+@example
+ffmpeg -i input.mkv -vf signature=filename=signature.xml -map 0:v -c rawvideo -f null -
+@end example
+
+@item
+To detect whether two videos matches and store the signatures in
+signature0.xml and signature1.xml:
+@example
+ffmpeg -i input1.mkv -i input2.mkv -filter_complex "[0:0][1:0] signature=nb_inputs=2:detectmode=1signature%d.xml" -map 0:v -map 1:v -c rawvideo -f null -
+@end example
+
+@end itemize
+
@anchor{smartblur}
@section smartblur
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b6e1999..9cd0d22 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -246,6 +246,7 @@ OBJS-$(CONFIG_SHOWPALETTE_FILTER)
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Mittwoch, 30. März 2016 23:02:36 CEST Gerion Entrup wrote: > On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup wrote: > > Add improved patch. > > Rebased to master. Bump. Can I help someway. Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Donnerstag, 7. April 2016 00:35:25 CEST Michael Niedermayer wrote:
> On Wed, Mar 30, 2016 at 11:02:36PM +0200, Gerion Entrup wrote:
> > On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup wrote:
> > > Add improved patch.
> >
> > Rebased to master.
> >
>
> > Changelog |1
> > configure |1
> > doc/filters.texi | 70 +++
> > libavfilter/Makefile |1
> > libavfilter/allfilters.c |1
> > libavfilter/signature.h| 554 ++
> > libavfilter/signature_lookup.c | 550 ++
> > libavfilter/version.h |4
> > libavfilter/vf_signature.c | 741
> > +
> > 9 files changed, 1921 insertions(+), 2 deletions(-)
> > 9192f27ded45c607996b4e266b6746f807c9a7fd
> > 0001-add-signature-filter-for-MPEG7-video-signature.patch
> > From 9646ed6f0cf78356cf2914a60705c98d8f21fe8a Mon Sep 17 00:00:00 2001
> > From: Gerion Entrup
> > Date: Sun, 20 Mar 2016 11:10:31 +0100
> > Subject: [PATCH] add signature filter for MPEG7 video signature
> >
> > This filter does not implement all features of MPEG7. Missing features:
> > - compression of signature files
> > - work only on (cropped) parts of the video
> > ---
> > Changelog | 1 +
> > configure | 1 +
> > doc/filters.texi | 70
> > libavfilter/Makefile | 1 +
> > libavfilter/allfilters.c | 1 +
> > libavfilter/signature.h| 554 ++
> > libavfilter/signature_lookup.c | 550 ++
> > libavfilter/version.h | 4 +-
> > libavfilter/vf_signature.c | 741
> > +
> > 9 files changed, 1921 insertions(+), 2 deletions(-)
> > create mode 100644 libavfilter/signature.h
> > create mode 100644 libavfilter/signature_lookup.c
> > create mode 100644 libavfilter/vf_signature.c
> >
> > diff --git a/Changelog b/Changelog
> > index 7b0187d..8a2b7fd 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -18,6 +18,7 @@ version :
> > - coreimage filter (GPU based image filtering on OSX)
> > - libdcadec removed
> > - bitstream filter for extracting DTS core
> > +- MPEG-7 Video Signature filter
> >
> > version 3.0:
> > - Common Encryption (CENC) MP4 encoding and decoding support
> > diff --git a/configure b/configure
> > index e550547..fe29827 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2979,6 +2979,7 @@ showspectrum_filter_deps="avcodec"
> > showspectrum_filter_select="fft"
> > showspectrumpic_filter_deps="avcodec"
> > showspectrumpic_filter_select="fft"
> > +signature_filter_deps="gpl avcodec avformat"
> > smartblur_filter_deps="gpl swscale"
> > sofalizer_filter_deps="netcdf avcodec"
> > sofalizer_filter_select="fft"
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 5d6cf52..a95f5a7 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -11559,6 +11559,76 @@ saturation maximum:
> > %@{metadata:lavfi.signalstats.SATMAX@}
> > @end example
> > @end itemize
> >
> > +@anchor{signature}
> > +@section signature
> > +
> > +Calculates the MPEG-7 Video Signature. The filter could handle more than
> > one
> > +input. In this case the matching between the inputs could be calculated.
> > The
> > +filter passthrough the first input. The output is written in XML.
> > +
> > +It accepts the following options:
> > +
> > +@table @option
> > +@item mode
>
> > +Enable the calculation of the matching. The option value must be 0 (to
> > disable
> > +or 1 (to enable). Optionally you can set the mode to 2. Then the detection
> > ends,
> > +if the first matching sequence it reached. This should be slightly faster.
> > +Per default the detection is disabled.
>
> these shuld probably support named identifers not (only) 0/1/2
done
>
>
> > +
> > +@item nb_inputs
> > +Set the number of inputs. The option value must be a non negative interger.
> > +Default value is 1.
> > +
> > +@item filename
> > +Set the path to witch the output is written. If there is more than one
> > input,
> > +the path must be a prototype, i.e. must contain %d or %0nd (wh
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Montag, 11. April 2016 12:57:17 CEST Michael Niedermayer wrote:
> On Mon, Apr 11, 2016 at 04:25:28AM +0200, Gerion Entrup wrote:
> > On Donnerstag, 7. April 2016 00:35:25 CEST Michael Niedermayer wrote:
> > > On Wed, Mar 30, 2016 at 11:02:36PM +0200, Gerion Entrup wrote:
> > > > On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup wrote:
> > > > > Add improved patch.
> > > >
> > > > Rebased to master.
> > > >
> > >
> > > > Changelog |1
> > > > configure |1
> > > > doc/filters.texi | 70 +++
> > > > libavfilter/Makefile |1
> > > > libavfilter/allfilters.c |1
> > > > libavfilter/signature.h| 554 ++
> > > > libavfilter/signature_lookup.c | 550 ++
> > > > libavfilter/version.h |4
> > > > libavfilter/vf_signature.c | 741
> > > > +
> > > > 9 files changed, 1921 insertions(+), 2 deletions(-)
> > > > 9192f27ded45c607996b4e266b6746f807c9a7fd
> > > > 0001-add-signature-filter-for-MPEG7-video-signature.patch
> > > > From 9646ed6f0cf78356cf2914a60705c98d8f21fe8a Mon Sep 17 00:00:00 2001
> > > > From: Gerion Entrup
> > > > Date: Sun, 20 Mar 2016 11:10:31 +0100
> > > > Subject: [PATCH] add signature filter for MPEG7 video signature
> > > >
> > > > This filter does not implement all features of MPEG7. Missing features:
> > > > - compression of signature files
> > > > - work only on (cropped) parts of the video
> > > > ---
> > > > Changelog | 1 +
> > > > configure | 1 +
> > > > doc/filters.texi | 70
> > > > libavfilter/Makefile | 1 +
> > > > libavfilter/allfilters.c | 1 +
> > > > libavfilter/signature.h| 554 ++
> > > > libavfilter/signature_lookup.c | 550 ++
> > > > libavfilter/version.h | 4 +-
> > > > libavfilter/vf_signature.c | 741
> > > > +
> > > > 9 files changed, 1921 insertions(+), 2 deletions(-)
> > > > create mode 100644 libavfilter/signature.h
> > > > create mode 100644 libavfilter/signature_lookup.c
> > > > create mode 100644 libavfilter/vf_signature.c
> > > >
> > > > diff --git a/Changelog b/Changelog
> > > > index 7b0187d..8a2b7fd 100644
> > > > --- a/Changelog
> > > > +++ b/Changelog
> > > > @@ -18,6 +18,7 @@ version :
> > > > - coreimage filter (GPU based image filtering on OSX)
> > > > - libdcadec removed
> > > > - bitstream filter for extracting DTS core
> > > > +- MPEG-7 Video Signature filter
> > > >
> > > > version 3.0:
> > > > - Common Encryption (CENC) MP4 encoding and decoding support
> > > > diff --git a/configure b/configure
> > > > index e550547..fe29827 100755
> > > > --- a/configure
> > > > +++ b/configure
> > > > @@ -2979,6 +2979,7 @@ showspectrum_filter_deps="avcodec"
> > > > showspectrum_filter_select="fft"
> > > > showspectrumpic_filter_deps="avcodec"
> > > > showspectrumpic_filter_select="fft"
> > > > +signature_filter_deps="gpl avcodec avformat"
> > > > smartblur_filter_deps="gpl swscale"
> > > > sofalizer_filter_deps="netcdf avcodec"
> > > > sofalizer_filter_select="fft"
> > > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > > index 5d6cf52..a95f5a7 100644
> > > > --- a/doc/filters.texi
> > > > +++ b/doc/filters.texi
> > > > @@ -11559,6 +11559,76 @@ saturation maximum:
> > > > %@{metadata:lavfi.signalstats.SATMAX@}
> > > > @end example
> > > > @end itemize
> > > >
> > > > +@anchor{signature}
> > > > +@section signature
> > > > +
> > > > +Calculates the MPEG-7 Video Signature. The filter could handle more
> > > > than one
> > > > +input. In this case the matching between the inputs could be
> > > > calculated. The
> > > &
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Montag, 11. April 2016 14:54:57 CEST Michael Niedermayer wrote: > On Mon, Apr 11, 2016 at 02:30:37PM +0200, Gerion Entrup wrote: > > On Montag, 11. April 2016 12:57:17 CEST Michael Niedermayer wrote: > > > On Mon, Apr 11, 2016 at 04:25:28AM +0200, Gerion Entrup wrote: > > > > On Donnerstag, 7. April 2016 00:35:25 CEST Michael Niedermayer wrote: > > > > > On Wed, Mar 30, 2016 at 11:02:36PM +0200, Gerion Entrup wrote: > > > > > > On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup wrote: > > > > > > > Add improved patch. > > > > > > > > > > > > Rebased to master. > > > > > > > > > > > > Changelog |1 > > > > > > configure |1 > > > > > > doc/filters.texi | 70 +++ > > > > > > libavfilter/Makefile |1 > > > > > > libavfilter/allfilters.c |1 > > > > > > libavfilter/signature.h| 554 > > > > > > ++ > > > > > > libavfilter/signature_lookup.c | 550 > > > > > > ++ > > > > > > libavfilter/version.h |4 > > > > > > libavfilter/vf_signature.c | 741 > > > > > > + 9 files changed, 1921 > > > > > > insertions(+), 2 deletions(-) > > > > > > > > > > > > 9192f27ded45c607996b4e266b6746f807c9a7fd > > > > > > 0001-add-signature-filter-for-MPEG7-video-signature.patch From > > > > > > 9646ed6f0cf78356cf2914a60705c98d8f21fe8a Mon Sep 17 00:00:00 2001 > > > > > > From: Gerion Entrup > > > > > > Date: Sun, 20 Mar 2016 11:10:31 +0100 > > > > > > Subject: [PATCH] add signature filter for MPEG7 video signature > > > > > > > > > > > > This filter does not implement all features of MPEG7. Missing > > > > > > features: > > > > > > - compression of signature files > > > > > > - work only on (cropped) parts of the video > > > > > > --- > > > > > > > > > > > > Changelog | 1 + > > > > > > configure | 1 + > > > > > > doc/filters.texi | 70 > > > > > > libavfilter/Makefile | 1 + > > > > > > libavfilter/allfilters.c | 1 + > > > > > > libavfilter/signature.h| 554 > > > > > > ++ > > > > > > libavfilter/signature_lookup.c | 550 > > > > > > ++ > > > > > > libavfilter/version.h | 4 +- > > > > > > libavfilter/vf_signature.c | 741 > > > > > > + 9 files changed, 1921 > > > > > > insertions(+), 2 deletions(-) > > > > > > create mode 100644 libavfilter/signature.h > > > > > > create mode 100644 libavfilter/signature_lookup.c > > > > > > create mode 100644 libavfilter/vf_signature.c > > > > > > > > > > > > diff --git a/Changelog b/Changelog > > > > > > index 7b0187d..8a2b7fd 100644 > > > > > > --- a/Changelog > > > > > > +++ b/Changelog > > > > > > > > > > > > @@ -18,6 +18,7 @@ version : > > > > > > - coreimage filter (GPU based image filtering on OSX) > > > > > > - libdcadec removed > > > > > > - bitstream filter for extracting DTS core > > > > > > > > > > > > +- MPEG-7 Video Signature filter > > > > > > > > > > > > version 3.0: > > > > > > - Common Encryption (CENC) MP4 encoding and decoding support > > > > > > > > > > > > diff --git a/configure b/configure > > > > > > index e550547..fe29827 100755 > > > > > > --- a/configure > > > > > > +++ b/configure > > > > > > @@ -2979,6 +2979,7 @@ showspectrum_filter_deps="avcodec" > > > > > > > > > > > > showspectrum_filter_select="fft" > > > > > > showspectrumpic_filter_deps="avcodec" > > > &g
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Donnerstag, 14. April 2016 19:52:46 CEST Michael Niedermayer wrote: > On Thu, Apr 14, 2016 at 07:06:29PM +0200, Gerion Entrup wrote: > > On Montag, 11. April 2016 14:54:57 CEST Michael Niedermayer wrote: > > > On Mon, Apr 11, 2016 at 02:30:37PM +0200, Gerion Entrup wrote: > > > > On Montag, 11. April 2016 12:57:17 CEST Michael Niedermayer wrote: > > > > > On Mon, Apr 11, 2016 at 04:25:28AM +0200, Gerion Entrup wrote: > > > > > > On Donnerstag, 7. April 2016 00:35:25 CEST Michael Niedermayer > > > > > > wrote: > > > > > > > On Wed, Mar 30, 2016 at 11:02:36PM +0200, Gerion Entrup wrote: > > > > > > > > On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup wrote: > > > > > > > > > Add improved patch. > > > > > > > > > > > > > > > > Rebased to master. > > > > > > > > > > > > > > > > Changelog |1 > > > > > > > > configure |1 > > > > > > > > doc/filters.texi | 70 +++ > > > > > > > > libavfilter/Makefile |1 > > > > > > > > libavfilter/allfilters.c |1 > > > > > > > > libavfilter/signature.h| 554 > > > > > > > > ++ > > > > > > > > libavfilter/signature_lookup.c | 550 > > > > > > > > ++ > > > > > > > > libavfilter/version.h |4 > > > > > > > > libavfilter/vf_signature.c | 741 > > > > > > > > + 9 files changed, 1921 > > > > > > > > insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > 9192f27ded45c607996b4e266b6746f807c9a7fd > > > > > > > > 0001-add-signature-filter-for-MPEG7-video-signature.patch From > > > > > > > > 9646ed6f0cf78356cf2914a60705c98d8f21fe8a Mon Sep 17 00:00:00 > > > > > > > > 2001 > > > > > > > > From: Gerion Entrup > > > > > > > > Date: Sun, 20 Mar 2016 11:10:31 +0100 > > > > > > > > Subject: [PATCH] add signature filter for MPEG7 video signature > > > > > > > > > > > > > > > > This filter does not implement all features of MPEG7. Missing > > > > > > > > features: > > > > > > > > - compression of signature files > > > > > > > > - work only on (cropped) parts of the video > > > > > > > > --- > > > > > > > > > > > > > > > > Changelog | 1 + > > > > > > > > configure | 1 + > > > > > > > > doc/filters.texi | 70 > > > > > > > > libavfilter/Makefile | 1 + > > > > > > > > libavfilter/allfilters.c | 1 + > > > > > > > > libavfilter/signature.h| 554 > > > > > > > > ++ > > > > > > > > libavfilter/signature_lookup.c | 550 > > > > > > > > ++ > > > > > > > > libavfilter/version.h | 4 +- > > > > > > > > libavfilter/vf_signature.c | 741 > > > > > > > > + 9 files changed, 1921 > > > > > > > > insertions(+), 2 deletions(-) > > > > > > > > create mode 100644 libavfilter/signature.h > > > > > > > > create mode 100644 libavfilter/signature_lookup.c > > > > > > > > create mode 100644 libavfilter/vf_signature.c > > > > > > > > > > > > > > > > diff --git a/Changelog b/Changelog > > > > > > > > index 7b0187d..8a2b7fd 100644 > > > > > > > > --- a/Changelog > > > > > > > > +++ b/Changelog > > > > > > > > > > > > > > > > @@ -18,6 +18,7 @@ version : > > > > > > > > - coreimage filter (GPU based image filtering on OSX) > > > > > > > > - libdcadec removed > > > > > > > >
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Samstag, 16. April 2016 05:16:04 CEST Michael Niedermayer wrote: > On Sat, Apr 16, 2016 at 12:07:27AM +0200, Gerion Entrup wrote: > > On Donnerstag, 14. April 2016 19:52:46 CEST Michael Niedermayer wrote: > > > On Thu, Apr 14, 2016 at 07:06:29PM +0200, Gerion Entrup wrote: > > > > On Montag, 11. April 2016 14:54:57 CEST Michael Niedermayer wrote: > > > > > On Mon, Apr 11, 2016 at 02:30:37PM +0200, Gerion Entrup wrote: > > > > > > On Montag, 11. April 2016 12:57:17 CEST Michael Niedermayer wrote: > > > > > > > On Mon, Apr 11, 2016 at 04:25:28AM +0200, Gerion Entrup wrote: > > > > > > > > On Donnerstag, 7. April 2016 00:35:25 CEST Michael Niedermayer > > > > > > > > wrote: > > > > > > > > > On Wed, Mar 30, 2016 at 11:02:36PM +0200, Gerion Entrup wrote: > > > > > > > > > > On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup > > > > > > > > > > wrote: > > > > > > > > > > > Add improved patch. > > > > > > > > > > > > > > > > > > > > Rebased to master. > > > > > > > > > > > > > > > > > > > > Changelog |1 > > > > > > > > > > configure |1 > > > > > > > > > > doc/filters.texi | 70 +++ > > > > > > > > > > libavfilter/Makefile |1 > > > > > > > > > > libavfilter/allfilters.c |1 > > > > > > > > > > libavfilter/signature.h| 554 > > > > > > > > > > ++ > > > > > > > > > > libavfilter/signature_lookup.c | 550 > > > > > > > > > > ++++++++++ > > > > > > > > > > libavfilter/version.h |4 > > > > > > > > > > libavfilter/vf_signature.c | 741 > > > > > > > > > > + 9 files changed, > > > > > > > > > > 1921 > > > > > > > > > > insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > 9192f27ded45c607996b4e266b6746f807c9a7fd > > > > > > > > > > 0001-add-signature-filter-for-MPEG7-video-signature.patch > > > > > > > > > > From > > > > > > > > > > 9646ed6f0cf78356cf2914a60705c98d8f21fe8a Mon Sep 17 > > > > > > > > > > 00:00:00 2001 > > > > > > > > > > From: Gerion Entrup > > > > > > > > > > Date: Sun, 20 Mar 2016 11:10:31 +0100 > > > > > > > > > > Subject: [PATCH] add signature filter for MPEG7 video > > > > > > > > > > signature > > > > > > > > > > > > > > > > > > > > This filter does not implement all features of MPEG7. > > > > > > > > > > Missing > > > > > > > > > > features: > > > > > > > > > > - compression of signature files > > > > > > > > > > - work only on (cropped) parts of the video > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > Changelog | 1 + > > > > > > > > > > configure | 1 + > > > > > > > > > > doc/filters.texi | 70 > > > > > > > > > > libavfilter/Makefile | 1 + > > > > > > > > > > libavfilter/allfilters.c | 1 + > > > > > > > > > > libavfilter/signature.h| 554 > > > > > > > > > > ++ > > > > > > > > > > libavfilter/signature_lookup.c | 550 > > > > > > > > > > ++ > > > > > > > > > > libavfilter/version.h | 4 +- > > > > > > > > > > libavfilter/vf_signature.c | 741 > > > > > > > > > > + 9
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Samstag, 16. April 2016 05:16:04 CEST Michael Niedermayer wrote: > On Sat, Apr 16, 2016 at 12:07:27AM +0200, Gerion Entrup wrote: > > On Donnerstag, 14. April 2016 19:52:46 CEST Michael Niedermayer wrote: > > > On Thu, Apr 14, 2016 at 07:06:29PM +0200, Gerion Entrup wrote: > > > > On Montag, 11. April 2016 14:54:57 CEST Michael Niedermayer wrote: > > > > > On Mon, Apr 11, 2016 at 02:30:37PM +0200, Gerion Entrup wrote: > > > > > > On Montag, 11. April 2016 12:57:17 CEST Michael Niedermayer wrote: > > > > > > > On Mon, Apr 11, 2016 at 04:25:28AM +0200, Gerion Entrup wrote: > > > > > > > > On Donnerstag, 7. April 2016 00:35:25 CEST Michael Niedermayer > > > > > > > > wrote: > > > > > > > > > On Wed, Mar 30, 2016 at 11:02:36PM +0200, Gerion Entrup wrote: > > > > > > > > > > On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup > > > > > > > > > > wrote: > > > > > > > > > > > Add improved patch. > > > > > > > > > > > > > > > > > > > > Rebased to master. > > > > > > > > > > > > > > > > > > > > Changelog |1 > > > > > > > > > > configure |1 > > > > > > > > > > doc/filters.texi | 70 +++ > > > > > > > > > > libavfilter/Makefile |1 > > > > > > > > > > libavfilter/allfilters.c |1 > > > > > > > > > > libavfilter/signature.h| 554 > > > > > > > > > > ++ > > > > > > > > > > libavfilter/signature_lookup.c | 550 > > > > > > > > > > ++++++++++ > > > > > > > > > > libavfilter/version.h |4 > > > > > > > > > > libavfilter/vf_signature.c | 741 > > > > > > > > > > + 9 files changed, > > > > > > > > > > 1921 > > > > > > > > > > insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > 9192f27ded45c607996b4e266b6746f807c9a7fd > > > > > > > > > > 0001-add-signature-filter-for-MPEG7-video-signature.patch > > > > > > > > > > From > > > > > > > > > > 9646ed6f0cf78356cf2914a60705c98d8f21fe8a Mon Sep 17 > > > > > > > > > > 00:00:00 2001 > > > > > > > > > > From: Gerion Entrup > > > > > > > > > > Date: Sun, 20 Mar 2016 11:10:31 +0100 > > > > > > > > > > Subject: [PATCH] add signature filter for MPEG7 video > > > > > > > > > > signature > > > > > > > > > > > > > > > > > > > > This filter does not implement all features of MPEG7. > > > > > > > > > > Missing > > > > > > > > > > features: > > > > > > > > > > - compression of signature files > > > > > > > > > > - work only on (cropped) parts of the video > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > Changelog | 1 + > > > > > > > > > > configure | 1 + > > > > > > > > > > doc/filters.texi | 70 > > > > > > > > > > libavfilter/Makefile | 1 + > > > > > > > > > > libavfilter/allfilters.c | 1 + > > > > > > > > > > libavfilter/signature.h| 554 > > > > > > > > > > ++ > > > > > > > > > > libavfilter/signature_lookup.c | 550 > > > > > > > > > > ++ > > > > > > > > > > libavfilter/version.h | 4 +- > > > > > > > > > > libavfilter/vf_signature.c | 741 > > > > > > > > > > + 9
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
%d %d %d %d %d %d %d ", (n & 0x80) >> 7,
(n & 0x40) >> 6,
(n & 0x20) >> 5,
@@ -446,24 +449,24 @@ static int xml_export(AVFilterContext *ctx, StreamContext *sc, const char* filen
}
/* finesignatures */
-for(fs = sc->finesiglist; fs; fs = fs->next){
+for (fs = sc->finesiglist; fs; fs = fs->next) {
fprintf(f, "\n");
fprintf(f, " %" PRIu64 "\n", fs->pts);
/* confidence */
fprintf(f, " %d\n", fs->confidence);
/* words */
fprintf(f, " ");
-for (i=0; i< 5; i++){
+for (i = 0; i < 5; i++) {
fprintf(f, "%d ", fs->words[i]);
-if (i < 4){
+if (i < 4) {
fprintf(f, " ");
}
}
fprintf(f, "\n");
/* framesignature */
fprintf(f, " ");
-for (i=0; i< SIGELEM_SIZE/5; i++){
-if (i>0) {
+for (i = 0; i< SIGELEM_SIZE/5; i++) {
+if (i > 0) {
fprintf(f, " ");
}
fprintf(f, "%d ", fs->framesig[i] / pot3[0]);
@@ -500,8 +503,11 @@ static int binary_export(AVFilterContext *ctx, StreamContext *sc, const char* fi
f = fopen(filename, "wb");
if (!f) {
-av_log(ctx, AV_LOG_ERROR, "cannot open file %s\n", filename);
-return AVERROR(EINVAL);
+int err = AVERROR(EINVAL);
+char buf[128];
+av_strerror(err, buf, sizeof(buf));
+av_log(ctx, AV_LOG_ERROR, "cannot open file %s: %s\n", filename, buf);
+return err;
}
init_put_bits(&buf, buffer, len);
@@ -520,15 +526,15 @@ static int binary_export(AVFilterContext *ctx, StreamContext *sc, const char* fi
put_bits32(&buf, 0x & sc->courseend->last->pts); /* EndMediaTimeOfSpatialRegion */
put_bits32(&buf, numofsegments); /* NumOfSegments */
/* coursesignatures */
-for(cs = sc->coursesiglist; cs; cs = cs->next){
+for (cs = sc->coursesiglist; cs; cs = cs->next) {
put_bits32(&buf, cs->first->index); /* StartFrameOfSegment */
put_bits32(&buf, cs->last->index); /* EndFrameOfSegment */
put_bits(&buf, 1, 1); /* MediaTimeFlagOfSegment */
put_bits32(&buf, 0x & cs->first->pts); /* StartMediaTimeOfSegment */
put_bits32(&buf, 0x & cs->last->pts); /* EndMediaTimeOfSegment */
-for (i=0; i < 5; i++){
+for (i = 0; i < 5; i++) {
/* put 243 bits ( = 7 * 32 + 19 = 8 * 28 + 19) into buffer */
-for (j=0; j < 30; j++){
+for (j = 0; j < 30; j++) {
//TODO is it faster to use put_bits32 and shift?
put_bits(&buf, 8, cs->data[i][j]);
}
@@ -537,15 +543,15 @@ static int binary_export(AVFilterContext *ctx, StreamContext *sc, const char* fi
}
/* finesignatures */
put_bits(&buf, 1, 0); /* CompressionFlag, only 0 supported */
-for(fs = sc->finesiglist; fs; fs = fs->next){
+for (fs = sc->finesiglist; fs; fs = fs->next) {
put_bits(&buf, 1, 1); /* MediaTimeFlagOfFrame */
put_bits32(&buf, 0x & fs->pts); /* MediaTimeOfFrame */
put_bits(&buf, 8, fs->confidence); /* FrameConfidence */
-for (i=0; i< 5; i++){
+for (i = 0; i < 5; i++) {
put_bits(&buf, 8, fs->words[i]); /* Words */
}
/* framesignature */
-for (i=0; i< SIGELEM_SIZE/5; i++){
+for (i = 0; i < SIGELEM_SIZE/5; i++) {
put_bits(&buf, 8, fs->framesig[i]);
}
}
@@ -637,14 +643,14 @@ static av_cold int init(AVFilterContext *ctx)
sc->coursecount = 0;
sc->midcourse = 0;
-if ((ret = ff_insert_inpad(ctx, i, &pad)) < 0){
+if ((ret = ff_insert_inpad(ctx, i, &pad)) < 0) {
av_freep(&pad.name);
return ret;
}
}
/* check filename */
-if (sic->nb_inputs > 1 && strlen(sic->filename) > 0 && av_get_frame_filename(tmp, sizeof(tmp), sic->filename, 0) == -1){
+if (sic->nb_inputs > 1 && strlen(sic->filename) > 0 && av_get_frame_filename(tmp, sizeof(tmp), sic->filename, 0) == -1) {
av_log(ctx, AV_LOG_ERROR, "The filename must contain %%d or %%0nd, if you have more than one input.\n");
return AVERROR(EINVAL);
}
@@ -677,21 +683,21 @@ static av_cold void uninit(
[FFmpeg-devel] [PATCH] make debug output for bitrate more meaningful
Currently on audio tracks:
Applying option b:a (video bitrate (please use -b:v)) with argument 240k.
but b:a is the recommendation:
Applying option ab (audio bitrate (please use -b:a)) with argument 240k.
Feel free to change the new string.
Gerion>From ddc4a7af0b355a03775ea76fa192004028cead27 Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Fri, 22 Apr 2016 18:37:41 +0200
Subject: [PATCH] make debug output for bitrate more meaningful
Currently the b:v hint appears also on audiotracks.
---
ffmpeg_opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 00d91c8..7700f8d 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -3341,7 +3341,7 @@ const OptionDef options[] = {
{ "ab", OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,{ .func_arg = opt_bitrate },
"audio bitrate (please use -b:a)", "bitrate" },
{ "b",OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,{ .func_arg = opt_bitrate },
-"video bitrate (please use -b:v)", "bitrate" },
+"set the bitrate", "bitrate" },
{ "hwaccel", OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT |
OPT_SPEC | OPT_INPUT, { .off = OFFSET(hwaccels) },
"use HW accelerated decoding", "hwaccel name" },
--
2.7.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Sonntag, 24. April 2016 01:44:51 CEST Michael Niedermayer wrote:
> On Tue, Apr 19, 2016 at 04:37:16PM +0200, Gerion Entrup wrote:
> > On Dienstag, 19. April 2016 13:25:53 CEST Moritz Barsnick wrote:
> > +static int request_frame(AVFilterLink *outlink)
> > +{
> > +AVFilterContext *ctx = outlink->src;
> > +SignatureContext *sc = ctx->priv;
> > +int i, ret;
> > +
> > +for (i = 0; i < sc->nb_inputs; i++){
> > +ret = ff_request_frame(ctx->inputs[i]);
> > +// TODO handle this in a better way?
> > +// Problem is the following:
> > +// Assuming two inputs, inputA with 50 frames, inputB with 100
> > frames
> > +// simply returning ret when < 0 would result in not filtering
> > inputB
> > +// after 50 frames anymore, not wanted
> > +// only returning ret at the end would result in only respecting
> > the error
> > +// values of the last input, please comment
> > +if (ret < 0 && ret != AVERROR_EOF)
> > +return ret;
> > +}
> > +return ret;
> > +}
>
> i dont know what exactly you want to happen when the inputs mismatch
> but handling it like other dualinput filters might be an option
vf_decimate, vf_fieldmatch: a main input exists, that dominates
vf_mergeplanes, vf_stack, f_streamselect: return value of
ff_framesync_request_frame is used
af_amerge, af_join: as soon as one inputstream end, the filter quits, other
said, the first error is returned
af_amix: AVERROR_EOF is catched and things happen, could be a possible
solution, but is audio related
af_ladspa: beside other things, with multiinput the return value of
ff_request_frame is returned
avf_concat, f_interleave: only values except AVERROR_EOF are handled, in some
way similar like my current solution but without the <0 check
I see not an analog usecase with any of these filters. If the inputs mismatch
absolutely nothing should happen.
The filter (the algorithm) does not require inputs of same length.
>
>
> [...]
> > +static av_cold void uninit(AVFilterContext *ctx)
> > +{
> > +SignatureContext *sic = ctx->priv;
> > +StreamContext *sc, *sc2;
> > +void* tmp;
> > +FineSignature* finsig;
> > +CourseSignature* cousig;
> > +MatchingInfo match;
> > +int i,j;
> > +
> > +//TODO export and especially lookup_signature can have a return value
> > to show some error etc.
> > +//How could this be handled in this function?
>
> why does it need to happen in uninit ?
> EOF could be detected before uninit if it doesnt work here
What would be another good place to call export and lookup? The process chart
would be something like:
[input1]-->[signature_computation with loop over all frames]-->[export]-.
-->[lookup]
[input2]-->[signature_computation with loop over all frames]-->[export]-`
ATM signature_computation is done in filter_frame and export and lookup are in
uninit.
Gerion
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] make debug output for bitrate more meaningful
On Freitag, 22. April 2016 19:09:02 CEST Gerion Entrup wrote: > Currently on audio tracks: > Applying option b:a (video bitrate (please use -b:v)) with argument 240k. > > but b:a is the recommendation: > Applying option ab (audio bitrate (please use -b:a)) with argument 240k. > > Feel free to change the new string. > > Gerion Bump ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] add signature filter for MPEG7 video signature
On Dienstag, 3. Mai 2016 19:01:51 CEST Gerion Entrup wrote:
> On Sonntag, 24. April 2016 01:44:51 CEST Michael Niedermayer wrote:
> > On Tue, Apr 19, 2016 at 04:37:16PM +0200, Gerion Entrup wrote:
> > > On Dienstag, 19. April 2016 13:25:53 CEST Moritz Barsnick wrote:
> > > +static int request_frame(AVFilterLink *outlink)
> > > +{
> > > +AVFilterContext *ctx = outlink->src;
> > > +SignatureContext *sc = ctx->priv;
> > > +int i, ret;
> > > +
> > > +for (i = 0; i < sc->nb_inputs; i++){
> > > +ret = ff_request_frame(ctx->inputs[i]);
> > > +// TODO handle this in a better way?
> > > +// Problem is the following:
> > > +// Assuming two inputs, inputA with 50 frames, inputB with 100
> > > frames
> > > +// simply returning ret when < 0 would result in not filtering
> > > inputB
> > > +// after 50 frames anymore, not wanted
> > > +// only returning ret at the end would result in only respecting
> > > the error
> > > +// values of the last input, please comment
> > > +if (ret < 0 && ret != AVERROR_EOF)
> > > +return ret;
> > > +}
> > > +return ret;
> > > +}
> >
> > i dont know what exactly you want to happen when the inputs mismatch
> > but handling it like other dualinput filters might be an option
> vf_decimate, vf_fieldmatch: a main input exists, that dominates
> vf_mergeplanes, vf_stack, f_streamselect: return value of
> ff_framesync_request_frame is used
> af_amerge, af_join: as soon as one inputstream end, the filter quits, other
> said, the first error is returned
> af_amix: AVERROR_EOF is catched and things happen, could be a possible
> solution, but is audio related
> af_ladspa: beside other things, with multiinput the return value of
> ff_request_frame is returned
> avf_concat, f_interleave: only values except AVERROR_EOF are handled, in some
> way similar like my current solution but without the <0 check
>
> I see not an analog usecase with any of these filters. If the inputs mismatch
> absolutely nothing should happen.
> The filter (the algorithm) does not require inputs of same length.
>
>
> >
> >
> > [...]
> > > +static av_cold void uninit(AVFilterContext *ctx)
> > > +{
> > > +SignatureContext *sic = ctx->priv;
> > > +StreamContext *sc, *sc2;
> > > +void* tmp;
> > > +FineSignature* finsig;
> > > +CourseSignature* cousig;
> > > +MatchingInfo match;
> > > +int i,j;
> > > +
> > > +//TODO export and especially lookup_signature can have a return
> > > value to show some error etc.
> > > +//How could this be handled in this function?
> >
> > why does it need to happen in uninit ?
> > EOF could be detected before uninit if it doesnt work here
> What would be another good place to call export and lookup? The process chart
> would be something like:
>
> [input1]-->[signature_computation with loop over all frames]-->[export]-.
>
> -->[lookup]
> [input2]-->[signature_computation with loop over all frames]-->[export]-`
>
> ATM signature_computation is done in filter_frame and export and lookup are
> in uninit.
>
> Gerion
>
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On Sonntag, 29. Mai 2016 16:45:26 CEST Ronald S. Bultje wrote: > Hi, > > On Sun, May 29, 2016 at 3:25 PM, Thilo Borgmann > wrote: > > > Am 29.05.16 um 01:32 schrieb Michael Niedermayer: > > > Hi > > > > > > It was suggested in the IRC meeting today that i start a vote to > > > resolve if AVClass & AVOption should be added to AVCodecParameters > > > This question needs to be awnsered before the next release because > > > the ABI would be broken if its added afterwards > > > the lack of any decission blocks the release which is worse than > > > either decission, otherwise a vote might be silly for such technical > > > question but eve a bad decission is better than no decission here > > > > > > > > > The disadvanatges are: > > > 1 more field in the struct > > > a high level API that some feel is unneeded for AVCodecParameters > > > it could be confusing to some that there are 2 different ways to > > > access the fields > > > people might use it as av_log() context when they intended to use a > > > different context for it > > > There are probably more please help fill the list if you know more > > > > > > The advanatges are: > > > More consistent availability of AVOptions and AVClass in public > > > structs > > > Makes supporting multiple FFmpeg versions and distros easier and > > > cleaner for applications. (reduces lists of #if version checks) > > > Provides default/min/max values, allows basic validity checking within > > > min/max > > > Avoids mysterious crashes if an application uses avoption functions > > > on AVCodecParameters > > > Introspection > > > Serialization support that may be usefull for ffserver or an application > > > replacing ffserver > > > > > > > > > An application that doesnt want to use AVOptions or AVClass can > > > completey ignore them. > > > > > > Please state clearly if you agree to add AVClass&AVOption to > > > AVCodecParameters or if you disagree about adding it or if you dont > > > care either way > > > > I'm in favor of adding them. > > > And you are not in the list either [1]... Let me make a suggestion. I'm a member of several university commitees. I have not always voting rights in this commitees but nevertheless could say what is my opinion and be involved in the discussion. So eventually do here. Everybody could say, what is his/her opinion, but only count (when the vote ends) the votes of the committee members. This could represent the comprehensive opinion maybe better, but defines also a definite voting mechanism. Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature
Hi,
I made a new thread because of the delay between this mail and my last one.
Attached is the next iteration of the patch (rebased to current master).
Main change is, that I've moved the writing and lookup code from uninit to
request_frame (thank you for the suggestion). Please comment.
Kind regards,
Gerion>From 01d96a18deaf6904cf140858e653195d50bc8fb2 Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Mon, 2 Jan 2017 02:08:57 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 89 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 569 ++
libavfilter/signature_lookup.c | 573 ++
libavfilter/version.h | 2 +-
libavfilter/vf_signature.c | 768 +
9 files changed, 2004 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/signature.h
create mode 100644 libavfilter/signature_lookup.c
create mode 100644 libavfilter/vf_signature.c
diff --git a/Changelog b/Changelog
index aff9ab0..687131c 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
- 16.8 floating point pcm decoder
- 24.0 floating point pcm decoder
- Apple Pixlet decoder
+- MPEG-7 Video Signature filter
version 3.2:
- libopenmpt demuxer
diff --git a/configure b/configure
index f035f35..3e68a44 100755
--- a/configure
+++ b/configure
@@ -3126,6 +3126,7 @@ showspectrum_filter_deps="avcodec"
showspectrum_filter_select="fft"
showspectrumpic_filter_deps="avcodec"
showspectrumpic_filter_select="fft"
+signature_filter_deps="gpl avcodec avformat"
smartblur_filter_deps="gpl swscale"
sofalizer_filter_deps="netcdf avcodec"
sofalizer_filter_select="fft"
diff --git a/doc/filters.texi b/doc/filters.texi
index 42cdd2e..8174b5b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12543,6 +12543,95 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
@end example
@end itemize
+@anchor{signature}
+@section signature
+
+Calculates the MPEG-7 Video Signature. The filter could handle more than one
+input. In this case the matching between the inputs could be calculated. The
+filter passthrough the first input. The signature of each stream could be written
+into a file.
+
+It accepts the following options:
+
+@table @option
+@item detectmode
+Enable or disable the matching process.
+
+Available values are:
+
+@table @samp
+@item off
+Disable the calculation of a matching (default).
+@item full
+Calculate the mathing for the whole video and output whether the whole video
+matches or only parts.
+@item fast
+Calculate as long as a matching is found or the video ends. Should be faster in
+some cases.
+@end table
+
+@item nb_inputs
+Set the number of inputs. The option value must be a non negative integer.
+Default value is 1.
+
+@item filename
+Set the path to which the output is written. If there is more than one input,
+the path must be a prototype, i.e. must contain %d or %0nd (where n is a positive
+integer), that will be replaced with the input number. If no filename is
+specified, no output will be written. This is the default.
+
+@item format
+Choose the output format.
+
+Available values are:
+
+@table @samp
+@item binary
+Use the specified binary representation (default).
+@item xml
+Use the specified xml representation.
+@end table
+
+@item th_d
+Set threshold to detect one word as similar. The option value must be an integer
+greater than zero. The default value is 9000.
+
+@item th_dc
+Set threshold to detect all words as similar. The option value must be an integer
+greater than zero. The default value is 6.
+
+@item th_xh
+Set threshold to detect frames as similar. The option value must be an integer
+greater than zero. The default value is 116.
+
+@item th_di
+Set the minimum length of a sequence in frames to recognize it as matching
+sequence. The option value must be a non negative integer value.
+The default value is 0.
+
+@item th_it
+Set the minimum relation, that matching frames to all frames must have.
+The option value must be a double value between 0 and 1. The default value is 0.5.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+To calculate the signature of an input video and store it in signature.bin:
+@example
+ffmpeg -i input.mkv -vf signature=filename=signature.bin -map 0:v -f null -
+@end example
+
+@item
+To detect whether two videos matches and store the signatures in XML format in
+signature0.xml and signature1.xml:
+@example
+ffmpeg -i input1.mkv -i input2.mkv -filter_complex "[0:v][1:v] signature=nb_inputs=2:detectm
Re: [FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature
On Dienstag, 3. Januar 2017 11:33:48 CET Moritz Barsnick wrote:
> On Mon, Jan 02, 2017 at 23:52:58 +0100, Gerion Entrup wrote:
> > +Calculates the MPEG-7 Video Signature. The filter could handle more than
> > one
> > +input. In this case the matching between the inputs could be calculated.
> > The
> > +filter passthrough the first input. The signature of each stream could be
> > written
> > +into a file.
>
> "Could" means "könnte" in German (I assume that's you first language),
> and that's probably not you intent here. I don't even understand what
> you man. "Can" (and "could") implies optional. What does it really do?
>
> You also need to fix some verbs. Language-wise, this could be correct,
> but it still does not tell what really happens and what is optional:
>
> Calculates the MPEG-7 Video Signature. The filter can handle more
> than one input. In this case the matching between the inputs is
> calculated. The filter passes through the first input. The signature
> of each stream can be written into a file.
The matching is not calculated automatically but with a commandline switch.
I've tried
to reformulate it in a better way.
> > +Calculate the mathing for the whole video and output whether the whole
> > video
> ^matching
> > +Calculate as long as a matching is found or the video ends. Should be
> > faster in
> > +some cases.
>
> "as long as" or "only until"? It sounds like you mean the latter.
>
> > +@item filename
> > +Set the path to which the output is written. If there is more than one
> > input,
> > +the path must be a prototype, i.e. must contain %d or %0nd (where n is a
> > positive
> > +integer), that will be replaced with the input number. If no filename is
> > +specified, no output will be written. This is the default.
>
> Question: Is this path technically (in ffmpeg terms) a URL/URI? If so,
> that might need to be mentioned.
I don't understand fully what your question is.
The output path is either a standard filepath or (if muliple inputs exist)
similar to
the path specification in other parts of FFmpeg (e.g. the image2 muxer).
> > +typedef struct CourseSignature{
>
> The English opposite of "fine" is "coarse", not "course". :)
Oops.
> > +{ "format", "set output format, possible values: binary (default),
> > xml",
>^ possible values and default are
> automatically documented for you,
> see "ffmpeg -h
> filter=filtername".
Nice.
> > +{ "th_d", "set threshold to detect one word as similar",
> > +{ "th_dc", "set threshold to detect all words as similar",
> > +{ "th_xh", "set threshold to detect frames as similar",
>
> You can probably omit the word "set" here, that's what options are for
> anyway.
Done in most cases.
> > +typedef struct MatchingInfo{
>
> Bracket style.
>
> > +int i,j,tmp_i,tmp_j,count;
>
> Add some spaces, please.
>
> > +int x0,y0,x1,y1;
>
> Spaces.
>
> > +}else if(x0-1 >= 0){
> > +}else if(y0-1 >= 0){
> > +}else{
>
> Bracket style (spaces).
>
> > +/* return if unexspected error occurs in input stream */
> ^ unexpected
> > +if (ret == AVERROR_EOF){
>
> Bracket style.
Hopefully fixed the spaces and brackets in all cases.
Thank you for the suggestions. Attached the new patch and diff to the last
patch.
Gerion
>From a444bf7e2ba4f583ccd63cbdaef24a1bb3a9f6c5 Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Mon, 2 Jan 2017 02:08:57 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 89 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 569 ++
libavfilter/signature_lookup.c | 573 ++
libavfilter/version.h | 2 +-
libavfilter/vf_signature.c | 768 +
9 files changed, 2004 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/signature.h
create mode 100
Re: [FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature
if (!sc->curcoarsesig2)
return AVERROR(ENOMEM);
-sc->curcoursesig2->first = fs;
-sc->curcoursesig1->next = sc->curcoursesig2;
-sc->courseend = sc->curcoursesig2;
+sc->curcoarsesig2->first = fs;
+sc->curcoarsesig1->next = sc->curcoarsesig2;
+sc->coarseend = sc->curcoarsesig2;
}
for (i = 0; i < 5; i++) {
-set_bit(sc->curcoursesig1->data[i], fs->words[i]);
+set_bit(sc->curcoarsesig1->data[i], fs->words[i]);
}
/* assuming the actual frame is the last */
-sc->curcoursesig1->last = fs;
-if (sc->midcourse) {
+sc->curcoarsesig1->last = fs;
+if (sc->midcoarse) {
for (i = 0; i < 5; i++) {
-set_bit(sc->curcoursesig2->data[i], fs->words[i]);
+set_bit(sc->curcoarsesig2->data[i], fs->words[i]);
}
-sc->curcoursesig2->last = fs;
+sc->curcoarsesig2->last = fs;
}
-sc->coursecount = (sc->coursecount+1)%90;
+sc->coarsecount = (sc->coarsecount+1)%90;
/* debug printing finesignature */
if (av_log_get_level() == AV_LOG_DEBUG) {
@@ -412,11 +412,11 @@ static int xml_export(AVFilterContext *ctx, StreamContext *sc, const char* filen
fprintf(f, "%d\n", sc->time_base.den / sc->time_base.num);
fprintf(f, "\n");
fprintf(f, " 0\n");
-fprintf(f, " %" PRIu64 "\n", sc->courseend->last->pts);
+fprintf(f, " %" PRIu64 "\n", sc->coarseend->last->pts);
fprintf(f, "\n");
-/* coursesignatures */
-for (cs = sc->coursesiglist; cs; cs = cs->next) {
+/* coarsesignatures */
+for (cs = sc->coarsesiglist; cs; cs = cs->next) {
fprintf(f, "\n");
fprintf(f, " %" PRIu32 "\n", cs->first->index);
fprintf(f, " %" PRIu32 "\n", cs->last->index);
@@ -494,7 +494,7 @@ static int binary_export(AVFilterContext *ctx, StreamContext *sc, const char* fi
uint32_t numofsegments = (sc->lastindex + 44)/45;
int i, j;
PutBitContext buf;
-/* buffer + header + coursesignatures + finesignature */
+/* buffer + header + coarsesignatures + finesignature */
int len = (512 + 6 * 32 + 3*16 + 2 +
numofsegments * (4*32 + 1 + 5*243) +
sc->lastindex * (2 + 32 + 6*8 + 608)) / 8;
@@ -524,10 +524,10 @@ static int binary_export(AVFilterContext *ctx, StreamContext *sc, const char* fi
put_bits(&buf, 16, 0x & (sc->time_base.den / sc->time_base.num)); /* MediaTimeUnit */
put_bits(&buf, 1, 1); /* MediaTimeFlagOfSpatialRegion */
put_bits32(&buf, 0); /* StartMediaTimeOfSpatialRegion */
-put_bits32(&buf, 0x & sc->courseend->last->pts); /* EndMediaTimeOfSpatialRegion */
+put_bits32(&buf, 0x & sc->coarseend->last->pts); /* EndMediaTimeOfSpatialRegion */
put_bits32(&buf, numofsegments); /* NumOfSegments */
-/* coursesignatures */
-for (cs = sc->coursesiglist; cs; cs = cs->next) {
+/* coarsesignatures */
+for (cs = sc->coarsesiglist; cs; cs = cs->next) {
put_bits32(&buf, cs->first->index); /* StartFrameOfSegment */
put_bits32(&buf, cs->last->index); /* EndFrameOfSegment */
put_bits(&buf, 1, 1); /* MediaTimeFlagOfSegment */
@@ -670,13 +670,13 @@ static av_cold int init(AVFilterContext *ctx)
return AVERROR(ENOMEM);
sc->curfinesig = NULL;
-sc->coursesiglist = av_mallocz(sizeof(CoarseSignature));
-if (!sc->coursesiglist)
+sc->coarsesiglist = av_mallocz(sizeof(CoarseSignature));
+if (!sc->coarsesiglist)
return AVERROR(ENOMEM);
-sc->curcoursesig1 = sc->coursesiglist;
-sc->courseend = sc->coursesiglist;
-sc->coursecount = 0;
-sc->midcourse = 0;
+sc->curcoarsesig1 = sc->coarsesiglist;
+sc->coarseend = sc->coarsesiglist;
+sc->coarsecount = 0;
+sc->midcoarse = 0;
if ((ret = ff_insert_inpad(ctx, i, &pad)) < 0) {
av_freep(&pad.name);
@@ -710,7 +710,7 @@ static av_cold void uninit(AVFilterContext *ctx)
for (i = 0; i < sic->nb_inputs; i++) {
sc = &(sic->streamcontexts[i]);
finsig = sc->finesiglist;
-cousig = sc->coursesiglist;
+cousig = sc->coarsesiglist;
while (finsig) {
tmp = finsig;
@@ -724,7 +724,7 @@ static av_cold void uninit(AVFilterContext *ctx)
cousig = cousig->next;
av_freep(&tmp);
Re: [FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature
On Donnerstag, 5. Januar 2017 02:26:23 CET Michael Niedermayer wrote:
> On Wed, Jan 04, 2017 at 05:05:41PM +0100, Gerion Entrup wrote:
> > On Dienstag, 3. Januar 2017 16:58:32 CET Moritz Barsnick wrote:
> > > > > The English opposite of "fine" is "coarse", not "course". :)
> > > > Oops.
> > >
> > > You still have a few "courses". (The actual variables, not the types. I
> > > don't care *too* much, but might be better for consistency.)
> > You're right. Fixed version attached.
> >
> >
> > > From my side - mostly style and docs - it looks fine. Technically, I
> > > can't judge too much. You went through a long review cycle already, so
> > > I assume it's fine for those previous reviewers. They have the last
> > > call anyway.
> >
> > What about FATE? I'm willing to write a test, but don't know the best way.
> > There are official conditions, whether the signature is standard compliant.
> > I've
> > written a python script to proof that (see previous emails). Nevertheless
> > the
> > checks take relatively long and need 3GB inputvideo, so I assume this is
> > not
> > usable for FATE.
>
> yes, a 3gb reference is not ok for fate
>
>
> >
> > One way would be, to take a short input video, take the calculated
> > signature
> > and use this as reference, but the standard allow some bitflips and my code
> > has some of them in comparison to the reference signatures.
>
> then the fate test could/should compare and pass if its within what
> we expect of our code. (which may be stricter than the reference
> allowance)
> there are already tests that do similar for comparing PCM/RAW
Ok, will try to create a test the next days.
> > +#define OFFSET(x) offsetof(SignatureContext, x)
>
> > +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM
>
> should contin also AV_OPT_FLAG_FILTERING_PARAM
Done.
> > +static int export(AVFilterContext *ctx, StreamContext *sc, int input)
> > +{
> > +SignatureContext* sic = ctx->priv;
> > +char filename[1024];
> > +
> > +if (sic->nb_inputs > 1) {
>
> > +/* error already handled */
> > +av_get_frame_filename(filename, sizeof(filename), sic->filename,
> > input);
>
> its more robust to use a av_assert*() on the return code if its assumed
> to be never failing than just a comment as a comment cannot be
> automatcially checked for validity currently.
I chose av_assert0 because the check is done only nb_inputs times.
The attached patch also fixes the file writing for every frame the one input is
longer than the other.
Gerion>From 09aa2cf7c89bae45cadd15754e70404dbdc31303 Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Mon, 2 Jan 2017 02:08:57 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 89 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 569 ++
libavfilter/signature_lookup.c | 573 ++
libavfilter/version.h | 2 +-
libavfilter/vf_signature.c | 767 +
9 files changed, 2003 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/signature.h
create mode 100644 libavfilter/signature_lookup.c
create mode 100644 libavfilter/vf_signature.c
diff --git a/Changelog b/Changelog
index aff9ab0..687131c 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
- 16.8 floating point pcm decoder
- 24.0 floating point pcm decoder
- Apple Pixlet decoder
+- MPEG-7 Video Signature filter
version 3.2:
- libopenmpt demuxer
diff --git a/configure b/configure
index f035f35..3e68a44 100755
--- a/configure
+++ b/configure
@@ -3126,6 +3126,7 @@ showspectrum_filter_deps="avcodec"
showspectrum_filter_select="fft"
showspectrumpic_filter_deps="avcodec"
showspectrumpic_filter_select="fft"
+signature_filter_deps="gpl avcodec avformat"
smartblur_filter_deps="gpl swscale"
sofalizer_filter_deps="netcdf avcodec"
sofalizer_filter_select="fft"
diff --git a/doc/filters.texi b/doc/filters.texi
index 42cdd2e..1722d65 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12543,6 +12543,95 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
@end example
@end itemize
+@anchor{signature}
+@sectio
Re: [FFmpeg-devel] SSL certificate for ffmpeg.org website is not valid anymore
Am Dienstag, 18. Juli 2017, 01:52:53 CEST schrieb Reimar Döffinger: > On 18.07.2017, at 00:59, James Almer wrote: > > > On 7/17/2017 7:49 PM, Moritz Barsnick wrote: > >> On Mon, Jul 10, 2017 at 13:53:02 +0300, Boris Pek wrote: > >>> Latest news about this topic: > >>> https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/FKXe-76GO8Y > >> > >> Ah, thanks, I neglected to report this, because I thought it was an > >> issue with my Opera Developer (48), which uses the Chrome engine. Opera > >> (like Chrome) recently reports ffmpeg.org's certificate as revoked, but > >> I found no tool which could verify this... > > > > The cert is by StartCom. Afaik everyone blacklisted certs issued by them > > after a certain date, and now some, like Google, are also blacklisting > > certs issued before that date as well. > > Mozilla hasn't done the latter yet, so Firefox doesn't complain about > > it, but i guess a new cert is overdue. > > New certs are already being generated, but nobody had the time to do the > transition, there is a risk of the automation failing > (I think the web server needs to be made to reload the certificate, which is > problematic as an ordinary user and there is no way I'd ever run any of that > letsencrypt stuff as root), This seems to work as cronjob: ``` #!/bin/sh su -c "certbot renew 2>/dev/null | grep 'No renewals' >/dev/null" letsencrypt -s /bin/bash if [ $? -eq 1 ]; then service nginx reload fi ``` Gerion > it is also a step backwards as the letsencrypt one is a domain-only > certificate, and due to TLS's idiotic design decisions it's not possible to > just deliver both certificates... > Thus the current situation. > Lack of time for proper testing being the biggest issue though... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] SSL certificate for ffmpeg.org website is not valid anymore
Am Sonntag, 23. Juli 2017, 09:27:06 CEST schrieb Reimar Döffinger: > On 21.07.2017, at 15:31, Ricardo Constantino wrote: > > > On 18 July 2017 at 02:12, Gerion Entrup > > wrote: > >> Am Dienstag, 18. Juli 2017, 01:52:53 CEST schrieb Reimar Döffinger: > >>> On 18.07.2017, at 00:59, James Almer wrote: > >>> > >>>> On 7/17/2017 7:49 PM, Moritz Barsnick wrote: > >>>>> On Mon, Jul 10, 2017 at 13:53:02 +0300, Boris Pek wrote: > >>>>>> Latest news about this topic: > >>>>>> https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/FKXe-76GO8Y > >>>>> > >>>>> Ah, thanks, I neglected to report this, because I thought it was an > >>>>> issue with my Opera Developer (48), which uses the Chrome engine. Opera > >>>>> (like Chrome) recently reports ffmpeg.org's certificate as revoked, but > >>>>> I found no tool which could verify this... > >>>> > >>>> The cert is by StartCom. Afaik everyone blacklisted certs issued by them > >>>> after a certain date, and now some, like Google, are also blacklisting > >>>> certs issued before that date as well. > >>>> Mozilla hasn't done the latter yet, so Firefox doesn't complain about > >>>> it, but i guess a new cert is overdue. > >>> > >>> New certs are already being generated, but nobody had the time to do the > >>> transition, there is a risk of the automation failing > >>> (I think the web server needs to be made to reload the certificate, which > >>> is problematic as an ordinary user and there is no way I'd ever run any > >>> of that letsencrypt stuff as root), > >> This seems to work as cronjob: > >> ``` > >> #!/bin/sh > >> > >> su -c "certbot renew 2>/dev/null | grep 'No renewals' >/dev/null" > >> letsencrypt -s /bin/bash > >> if [ $? -eq 1 ]; then > >>service nginx reload > >> fi > >> ``` > > This is what scares me most: people running things as horrible as certbot > (written by people who think it is ok to download and install a compiler > without even asking before on a web server) AS ROOT. If this is related to the above lines. certbot is not run as root here and the whole webserver handling can be done by nginx. Cron and the init system of course run as root. Anyway, if you're concerned of certbot, there are solutions like acme-tiny [1]. To quote: "This script must stay under 200 lines of code to ensure it can be easily audited by anyone who wants to run it." Gerion [1] https://github.com/diafygi/acme-tiny/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] web: News about FFmpeg in Debian
Am Freitag 10 Oktober 2014, 12:57:21 schrieb Alexander Strasser: > On 2014-10-07 08:13 -0700, Timothy Gu wrote: > > On Oct 6, 2014 3:23 PM, "Alexander Strasser" wrote: > [...] > > > > I have locally changed all other things requested by Timothy > > > > > > and Carl Eugen. I do not think the Libav deprecation message > > > should be part of this news article. Probably putting it in the > > > FAQ/other place on the homepage or writing another news article > > > would be helpful. Though I am not volunteering for that ATM. > > > > > > I will wait another day or two. So if you do have objections > > > > > > voice them soon please. > > > > With the changes I requested, the patch LGTM. > > Changed and pushed. > > Also fixed the URL of the link as described here: > http://www.htmlhelp.com/tools/validator/problems.html#amp > > > Alexander Maybe it would be a good idea to describe somewhere, how to install ffmpeg from sid in testing: 1. Make testing your default. Write this somewhere in /etc/apt/apt.conf or /etc/apt/apt.conf.d/*: APT::Default-Release "testing"; or APT::Default-Release "jessie"; The name here must match with the release name in sources.list. 2. Edit your sources.list file and add sid to it, e.g.: deb http://http.debian.net/debian/ sid main contrib non-free 3. Update and install ffmpeg: apt-get update && apt-get install -t sid ffmpeg (untested commands, because I don't have a debian machine atm). Cheers, Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libavfilter/signature_lookup: fix jaccard distance
Actually, the jaccard distance is defined as D = 1 - intersect / union.
Additionally, the distance value is compared against a constant that
must be between 0 and 1, which is not the case here. Both facts together
has led to the fact, that the function always returned a matching course
signature. To leave the constant intact and to avoid floating point
computation, this commit multiplies with 1 << 16 making the constant
effectively 9000 / (1<<16) =~ 0.14.
Reported-by: Sachin Tilloo
Reviewed-by: Sachin Tilloo
Tested-by: Sachin Tilloo
---
libavfilter/signature_lookup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index b39a3e225b..b90b63f3f2 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -127,9 +127,10 @@ static int get_jaccarddist(SignatureContext *sc,
CoarseSignature *first, CoarseS
{
int jaccarddist, i, composdist = 0, cwthcount = 0;
for (i = 0; i < 5; i++) {
-if ((jaccarddist = intersection_word(first->data[i], second->data[i]))
> 0) {
+if ((jaccarddist = (1 << 16) * intersection_word(first->data[i],
second->data[i])) > 0) {
jaccarddist /= FFMAX(union_word(first->data[i], second->data[i]),
1);
}
+jaccarddist = (1 << 16) - jaccarddist;
if (jaccarddist >= sc->thworddist) {
if (++cwthcount > 2) {
/* more than half (5/2) of distances are too wide */
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] libavfilter/signature_lookup: fix possible division by zero
---
libavfilter/signature_lookup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index a0ca818a9b..b39a3e225b 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -128,7 +128,7 @@ static int get_jaccarddist(SignatureContext *sc,
CoarseSignature *first, CoarseS
int jaccarddist, i, composdist = 0, cwthcount = 0;
for (i = 0; i < 5; i++) {
if ((jaccarddist = intersection_word(first->data[i], second->data[i]))
> 0) {
-jaccarddist /= union_word(first->data[i], second->data[i]);
+jaccarddist /= FFMAX(union_word(first->data[i], second->data[i]),
1);
}
if (jaccarddist >= sc->thworddist) {
if (++cwthcount > 2) {
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Converting build to CMake
Am Montag, 29. August 2022, 01:31:12 CEST schrieb Gonzalo Garramuño: > > On 28/8/22 20:17, Jaime Rios wrote: > > Sorry if this has been asked before in the past. > > > > I am wondering if there has been any conversation around changing the > > current build setup of ffmpeg to CMake. > > > > The reason I ask is that I am not a fan of having to install MinGW just to > > build on Windows, and my experience so far with CMake has been a pleasant > > one, when having to build on multiple platforms (Windows/Linux/macOS). > > > > If there has been conversation about moving to CMake, where can I find the > > thread? > > I would love that to happen myself too. The main issue is all the > dependencies that ffmpeg has to take care of. You need to have > FindLib*.cmake and/or BuldLib*cmake, plus you need to take care of which > libraries are open source, BSD, GPL, etc. and whether you need to locate > them with pkgconfig. > > It is overall a lot of work, so something would need to get paid to do > so fulltime. > > I have to wonder, as I only have Windows 8.1 so far, doesn't Windows 10 > WSL2 solve the compilation issues by having the lib be compiled on an > Ubuntu distro? There is a (maintained) fork of FFMpeg with Meson (similar to CMake): https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg However, this has nothing to do with the original project (AFAIK). Best, Gerion signature.asc Description: This is a digitally signed message part. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSoC 2016
On Mittwoch, 27. Januar 2016 12:56:32 CET Lou Logan wrote: > On Wed, 27 Jan 2016 22:03:32 +0100, Michael Niedermayer wrote: > > > Hi all > > > > Is there anyone who wants to be (backup) admin for GSoC 2016 ? > > also the GSoC page on the wiki needs to be put into shape for it > > > > Stefano, Reynaldo, you did it last year IIRC, are you available again ? > > someone else ? > > > > we should ideally have at least 3 admins > > > > https://developers.google.com/open-source/gsoc/timeline > > I'll consider it, but I'm not particularly excited about it. > > As for the wiki, perhaps a rolling, generic ProjectIdeas page would be > easier to manage and keep up to date than copying stuff from > year-to-year and various project-to-project. It can be considered to be > the "git master branch" of the sponsored project ideas. +1 . Unrelated to GSOC and other project, this makes some kind of TODO list public, but say at the same time: "We know about some features, but this features are so complex, that it is unlikely, that someone implements it just for fun." Such a page is a benefit for users, who want this features, to understand why they are missing. Maybe it reduces questions like: "When will feature xy be available? Do you even know about it?" > I occasionally > think "that may make a good project", then forgetting because there is > no central location, or if there is I'm ignorant of it. Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] libx265: Add crf private option
I guess, this is based on the irc talk. Thank you again!
Cheers,
Gerion
Am Dienstag 17 Februar 2015, 17:02:31 schrieb Derek Buitenhuis:
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/libx265.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index c35f6c2..0d546d8 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -25,6 +25,7 @@
> #endif
>
> #include
> +#include
>
> #include "libavutil/internal.h"
> #include "libavutil/common.h"
> @@ -39,6 +40,7 @@ typedef struct libx265Context {
> x265_encoder *encoder;
> x265_param *params;
>
> +float crf;
> char *preset;
> char *tune;
> char *x265_opts;
> @@ -138,7 +140,15 @@ static av_cold int libx265_encode_init(AVCodecContext
> *avctx) break;
> }
>
> -if (avctx->bit_rate > 0) {
> +if (ctx->crf >= 0) {
> +char crf[6];
> +
> +snprintf(crf, sizeof(crf), "%2.2f", ctx->crf);
> +if (x265_param_parse(ctx->params, "crf", crf) ==
> X265_PARAM_BAD_VALUE) { +av_log(avctx, AV_LOG_ERROR, "Invalid
> crf: %2.2f.\n", ctx->crf); +return AVERROR_INVALIDDATA;
> +}
> +} else if (avctx->bit_rate > 0) {
> ctx->params->rc.bitrate = avctx->bit_rate / 1000;
> ctx->params->rc.rateControlMode = X265_RC_ABR;
> }
> @@ -294,6 +304,7 @@ static av_cold void libx265_encode_init_csp(AVCodec
> *codec) #define OFFSET(x) offsetof(libx265Context, x)
> #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
> static const AVOption options[] = {
> +{ "crf", "set the x265 crf",
> OFFSET(crf), AV_OPT_TYPE_FLOAT, { .dbl = -1
> }, -1, FLT_MAX, VE }, { "preset", "set the x265 preset",
> OFFSET(preset),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE }, { "tune","set the x265 tune
> parameter", OFFSET(tune),
>AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE }, { "x265-params", "set the x265
> configuration using a :-separated list of key=value parameters",
> OFFSET(x265_opts), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Project orientation
Hi, Am Donnerstag, 9. Juli 2020, 02:56:28 CEST schrieb Manolis Stamatogiannakis: > On Tue, 7 Jul 2020 at 16:27, Nicolas George wrote: > > > Is tree threading that important? A PR is essentially a single thread of > > > discussion. > > > > It is a single thread of discussion until the discussion becomes complex > > and has branches. > > > > This doesn't sound like the common case. > But it should be straightforward to get some statistics on that from the > list archives when a transition is officially discussed. This whole current discussion here would be a lot more confusing without branches. Maybe you like the Gentoo approach: Do the majority of changes in pull requests, in Gentoo this are changes of packages, here it would be changes on codecs/demuxers/filters/etc. And then do all changes of the framework itself and discussions via mailinglist. In Gentoo this are changes of eclasses (i.e. code libraries for packages). For FFmpeg it would be the introduction of new API, API changes, decoupling or merging of libraries etc. The first is likely to produce no to little (conflicting) discussion, has a huge benefit from CI, is the part where most of the newcomers begin development and includes a lot of easy tasks. Here by far the most developments happens. The latter is likely to produce huge discussions, needs deep knowledge of the libraries, so it is not likely done by newcomers and has little gain from CI since it adds e.g. something completely new. Here happens not so much development in terms of frequency or code lines but the impact is much higher. Just a suggestion, since I follow both projects... Regards, Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] git and signing commits and tags
Hi, Am Montag, 8. August 2022, 21:26:52 CEST schrieb Lynne: > Aug 8, 2022, 16:50 by mich...@niedermayer.cc: > > > Given the recent server issues, i wonder if we should suggest/recommand > > and document signing commits and tags > > > > i tried to push such commit to github and it nicely says "verified" > > https://github.com/michaelni/FFmpeg/commit/75f196acd16fb0c0ca7a94f0c66072e7c6f736bf > > > > Ive generated a new gpg key for this experiment as i dont have my > > main key on the box used for git development and also using more > > modern eliptic curve stuff (smaller keys & sigs) > > i will upload this key to the keyservers in case it becomes the > > one i use for git. > > > > I sign all of my commits, I think it should be recommended but > not required. > > One downside is that you can sign commits from others with your > own key (for instance when pushing a patch from someone along > with your commits, and signing all at once via rebase), which can be > misleading, so it takes some work to reorder commits or push them > in stages so this doesn't happen. It makes sense that it's the > committer who's signing it, but git or github don't make a distinction > when it comes to signing. Since Git is kind of a blockchain (it includes the hash of the predecessor commits) you technically sign the entire tree anyways not just the individual commit. Especially in a rebase, the original author signs the original commit hash (which changes in a rebase), so it is not possible to use the same signature again. But I understand that a direct mapping between author and singing person would be nice. For releases, I think that the attacker model is important. The typical scenario is that one clones the repository, than checkouts a tag and compiles FFmpeg. For that one wants to know that the code is not manipulated by a third party (a person not trusted by the FFmpeg project). If the last commit is signed then, the user know that they can trust the entire code. If they checkout a random commit that is not signed, they cannot be sure that the set of changes up to the next signed commit of an FFmpeg author comes from a person trusted by FFmpeg. But for that it doesn't matter which of the devs has signed the commit. So I think for end users a signed release commit is most valuable, individual commits are valuable, too, and it's important that the signature must always come from a person trusted by the FFmpeg project. Best, Gerion > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > signature.asc Description: This is a digitally signed message part. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] A few filter questions
Good day, I'm currently working on a video signature filter for ffmpeg. This allows you to fingerprint videos. This fingerprint is built up of 9mb/s of bits or 2-3 mb/s bits compressed. In this context a few questions come into my mind: - Should I print this whole bitstream to stdout/stderr at the end? Is it maybe a better choice to made an own stream out of this. But which type of stream this is? (btw, the video signature algorithm needs 90 following frames, so I can theoretically write every 90 frames something somewhere.) - If I print the whole bitstream to stdout/stderr (my current implementation), is there a possibility to use this later in an external program? The only other globally analyze filter I found is volumedetect. This filter at the end prints per print_stats the calculated results to the console. Is there a possibility within the API for an external program to use these values or do I have to grep the output? A similar example is AcousticID (a fingerprinting technique for audio). Currently chromaprint (the AcousticID library) provides an executable (fpcalc) to calculate AcousticID. It therefore uses FFmpeg to decode the audio and then its own library to calculate the fingerprint. The better way I think would be to have an ffmpeg filter for this. But is it possibly to use the calculated number in an external program without grepping the output? Another thing that came into my mind: Can filter force other filters to go into the filterchain? I see it, when I force GREY_8 only in my filter, it automatically enables the scale filter, too. The reason I asked is the lookup for my filter. Currently my filter analyzes a video and then produces a lot of numbers. To compare two videos and decide, wheather they match or not, these numbers has to be compared. I see three possibilities: 1. Write an VV->V filter. Reimplement (copy) the code from the V->V signature filter and give a boolean as output (match or match not). 2. Take the V->V filter and write a python (or whatever) script that fetch the output and calculates then the rest. 3. Write an VV->V filter, but enforce, that the normal signature filter is executed first to both streams, use the result and then calculate the matching type. Unfortunately I have no idea, how to do this and whether it is possible at all. Can you give me an advice? The last possibility also would allow something like twopass volume normalisation. Currently there is a volumedetect and volume filter. To normalize once could run volumedetect, then fetch the output, and put the values into the volume filter, but I currently don't see a way to do this automatically directly in ffmpeg. (Once the filter is in a good state, I will try to bring it upstream.) Best, Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] A few filter questions
Am Donnerstag 17 Juli 2014, 13:00:13 schrieb Clément Bœsch: > On Thu, Jul 17, 2014 at 12:33:41PM +0200, Gerion Entrup wrote: > > Good day, > > > > I'm currently working on a video signature filter for ffmpeg. This allows > > you to fingerprint videos. > > Oh, nice. > > > This fingerprint is built up of 9mb/s of bits or 2-3 mb/s bits compressed. Argh, fail, sorry. I meant: 9mb per hour of video (and 2-3 mb per hour). > > > > In this context a few questions come into my mind: > > - Should I print this whole bitstream to stdout/stderr at the end? Is it > > maybe a better choice to made an own stream out of this. But which type > > of stream this is? > > How does the fingerprint looks like? Could it make sense as a gray video > output fractal, or maybe some kind of audio signal? There a finesignatures per frame and coursesignatures per 90 finesignatures. coursesignature are binarized histograms (0 or 1 possible as count). finesignature is mainly a vector of 380 difference values between -128 and 127 which are ternarized into 0 1 or 2. (See the MPEG-7 Standard for more details). I doubt, this is a good video or audio stream. Definitely, interpreting this as video make sense in some way, but metadata looks more useful. > > Also, you still have the string metadata possibility (git grep SET_META > libavfilter). Hmm, thank you, I will take a look at it. If I see it right, it is used to fill a dictionary per frame with some kind of data? > > > (btw, the video signature algorithm needs 90 following frames, so I can > > > > theoretically write every 90 frames something somewhere.) > > Do you cache all these frames or just update your caches/stats & drop > them? ATM I don't cache the frames, but the whole signature. As said above, the coursesignatures (the part, which needs the 90 frames) is calculated only from the finesignatures (the finesignatures are cached, anyway). > > > - If I print the whole bitstream to stdout/stderr (my current > > implementation), is there a possibility to use this later in an external > > program? The only other globally analyze filter I found is volumedetect. > > This filter at the end prints per print_stats the calculated results to > > the console. Is there a possibility within the API for an external > > program to use these values or do I have to grep the output? > > stdout/stderr really isn't a good thing. Using metadata is way better > because you can output them from ffprobe, and parse them according to > various outputs (XML, CSV, JSON, ...). Sounds good… > > Another solution I can now think of is to simply pass an output file as > option to the filter. That's typically how we do the 2-pass thing with > vidstab filter. I don't like output files. If you want to write a program, that performs a lookup to signatures somewhere stored in a database and this program uses ffmpeg internally and then always has to write a file and read it again, it's not that elegant. (btw, an example for such a program is Musicbrainz Picard, but for AcousticID ;)) > > [...] > > > Another thing that came into my mind: Can filter force other filters to go > > into the filterchain? I see it, when I force GREY_8 only in my filter, it > > automatically enables the scale filter, too. > > Some filter are inserted automatically for conversion & constraints, but > that's not decided by the filters but the framework itself. > > > The reason I asked is the > > lookup > > > > for my filter. Currently my filter analyzes a video and then produces a > > lot of numbers. To compare two videos and decide, wheather they match or > > not, these numbers has to be compared. I see three possibilities: > > 1. Write an VV->V filter. Reimplement (copy) the code from the V->V > > signature filter and give a boolean as output (match or match not). > > 2. Take the V->V filter and write a python (or whatever) script that fetch > > the output and calculates then the rest. > > 3. Write an VV->V filter, but enforce, that the normal signature filter is > > executed first to both streams, use the result and then calculate the > > matching type. Unfortunately I have no idea, how to do this and whether > > it is possible at all. Can you give me an advice? > > So if you output a file in the filter itself: > ffmpeg -i video -vf fingerprint=video.sig -f null - > ffmpeg -i another -vf fingerprint=video.sig:check=1 -f null - > > Or if you save the signature "stream" in a video (in gray8 for instance): > ffmpeg -i video -vf fingerpr
Re: [FFmpeg-devel] A few filter questions
Am Donnerstag 17 Juli 2014, 17:24:35 schrieb Clément Bœsch:
> On Thu, Jul 17, 2014 at 04:56:08PM +0200, Gerion Entrup wrote:
> [...]
>
> > > Also, you still have the string metadata possibility (git grep SET_META
> > > libavfilter).
> >
> > Hmm, thank you, I will take a look at it. If I see it right, it is used to
> > fill a dictionary per frame with some kind of data?
>
> Strings only, so you'll have to find a serialization somehow. Maybe simply
> an ascii hex string or something. But yeah, it just allows you to map some
> key → value string couples to the frames passing by in the filter.
>
> How huge is the information to store per frame?
82 byte per frame for the finesignature
(Could be split again in three parts: An one byte confidence, a 5 byte words
vector, and a 76 byte framesignature, something like:
struct finesignature{
uint8_t confidence;
uint8_t words[5];
uint8_t framesignature[76]
})
152 byte per 90 frames for the coursesignature
(Note, that there are 2 coursesignatures with an offset of 45 frames:
0-89
45-134
90-179
...)
If I see it right, there are two possibilies:
Write as chars in the output (looks crappy, but needs the same amount of
memory).
Write as ascii hex in the output (looks nice, but needs twice as much memory).
>
> [...]
>
> > > stdout/stderr really isn't a good thing. Using metadata is way better
> > > because you can output them from ffprobe, and parse them according to
> > > various outputs (XML, CSV, JSON, ...).
> >
> > Sounds good…
>
> tools/normalize.py make use of such feature if you want examples (that's
> the -of option of ffprobe)
Ok.
>
> [...]
>
> > > Am I understanding right your wondering?
> >
> > No ;), but anyway thanks for your answer. In your 2nd method your filter
> > is a VV->V filter? Am I right, that this filter then also can take only
> > one stream? Said in another way: Can a VV->V filter also behave as a V->V
> > filter?
> Yes, fieldmatch is a (complex) example of this. But typically it's simply
> a filter with dynamic inputs, based on the user input. The simplest
> example would be the split filter. Look at it for an example of dynamic
> allocation of the number of inputs based on the user input (-vf split=4 is
> a V-> filter)
Hmm, interesting code, thank you.
>
> [...]
>
> > > Check tools/normalize.py, it's using ebur128 and the metadata system.
> >
> > Thats what I mean. Someone has to write an external script, which calls
> > ffmpeg/ffprobe two times, parse stdout of the first call and pass it to
> > the
> > filteroptions of the second call. As I see, there is no direct way.
> > Something like:
> > ffmpeg -i foo -f:a volume=mode=autodetect normalized.opus
>
> We add a discussion several time for real time with that filter. If we do
> a 2-pass, that's simply because it's "more efficient". Typically, doing
> some live normalization can be done easily (we had patches for this):
> ebur128 already attaches some metadata to frames, so a following filter
> such as volume could reuse them, something like -filter_complex
> ebur128=metadata=1,volume=metadata.
>
> [...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Recommendation for ffmpeg.org background color change
Am Montag 28 Juli 2014, 07:00:12 schrieb Frantisek Korbel: > Good day to all, > congratulation to ffmpeg.org new website, now information is better > structured and users can find data easily. > One question is a dark background - initially I also used it on my web, > because it is easier to read when ambient light is low and also it > saves energy - monitor powers much less pixels on the screen. Maybe as a solution: Let the user choose. The website is mainly to inform and impress the user. So make a poll on the website, which color is the best. I personally also would like a bright color (not because I have arguments, just because I would like it). Cheers, Gerion > But later I found 3 main reasons why not to use it: > - All most visited webs like Facebook, Google, Wikipedia, Yahoo etc. > use black text on white background: http://www.alexa.com/topsites > - Some sensitive people can avoid to visit ffmpeg.org only because > of its black background > - Dark background often use warez and other illegal webs, so some > visitors can get questions about the site contents. > For this reasons I strongly recommend to set the white background > please try it from the 1st August. > Best wishes, > Frantisek Korbel, Zend Certified Engineer > http://www.zend.com/en/yellow-pages/ZEND012386 > > _ > Conserve wilderness with a click (free!) and get your own EcologyFund.net > email (free!) at http://www.ecologyfund.com. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] add m4b to list of ipod playable files
m4b is the extension used by iDevices to detect audiobooks.
---
libavformat/movenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 4b9a4f1..2bb6be1 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -895,8 +895,10 @@ static int ipod_get_codec_tag(AVFormatContext *s,
MOVTrack *track)
tag == MKTAG('t', 'e', 'x', 't'
tag = ff_codec_get_tag(codec_ipod_tags, track->enc->codec_id);
-if (!av_match_ext(s->filename, "m4a") && !av_match_ext(s->filename, "m4v"))
-av_log(s, AV_LOG_WARNING, "Warning, extension is not .m4a nor .m4v "
+if (!av_match_ext(s->filename, "m4a") &&
+!av_match_ext(s->filename, "m4b") &&
+!av_match_ext(s->filename, "m4v"))
+av_log(s, AV_LOG_WARNING, "Warning, extension is not .m4a, .m4v nor
.m4b "
"Quicktime/Ipod might not play the file\n");
return tag;
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc: add very basic libcdio documentation
---
doc/indevs.texi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 4ca12ff..e0e7e67 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -483,6 +483,21 @@ ffplay -f lavfi
"movie=test.avi[out0];amovie=test.wav[out1]"
@end itemize
+@section libcdio
+
+Audio-CD input device based on cdio.
+
+To enable this input device during configuration you need libcdio
+installed on your system.
+
+This device allows playing and grabbing from an Audio-CD.
+
+For example to copy with @command{ffmpeg} the entire Audio-CD in /dev/sr0,
+you may run the command:
+@example
+ffmpeg -f libcdio -i /dev/sr0 cd.wav
+@end example
+
@section libdc1394
IIDC1394 input device, based on libdc1394 and libraw1394.
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc: add very basic libcdio documentation
Am Mittwoch 30 Juli 2014, 01:53:32 schrieb Gerion Entrup:
> ---
> doc/indevs.texi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/doc/indevs.texi b/doc/indevs.texi
> index 4ca12ff..e0e7e67 100644
> --- a/doc/indevs.texi
> +++ b/doc/indevs.texi
> @@ -483,6 +483,21 @@ ffplay -f lavfi
> "movie=test.avi[out0];amovie=test.wav[out1]"
>
> @end itemize
>
> +@section libcdio
> +
> +Audio-CD input device based on cdio.
> +
> +To enable this input device during configuration you need libcdio
> +installed on your system.
> +
> +This device allows playing and grabbing from an Audio-CD.
> +
> +For example to copy with @command{ffmpeg} the entire Audio-CD in /dev/sr0,
> +you may run the command:
> +@example
> +ffmpeg -f libcdio -i /dev/sr0 cd.wav
> +@end example
> +
> @section libdc1394
>
> IIDC1394 input device, based on libdc1394 and libraw1394.
If you apply this patch, please use my t-online address.
cheers,
Gerion
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] AVDictionary2
Am Dienstag, 8. April 2025, 22:29:37 Mitteleuropäische Sommerzeit schrieb Michael Niedermayer: > On Tue, Apr 08, 2025 at 11:10:21AM -0500, Romain Beauxis wrote: > > Le mar. 8 avr. 2025 à 05:20, Michael Niedermayer > > a écrit : >> [...] > > * Any interest in storing multiple values for the same key? This seems > > like a niche case but, as you pointed out in another thread, typically > > vorbis metadata do allow multiple key/values for the same field. > > For a single key multiple values should not be stored > You can do > Author1=Eve > Author2=Adam > or > Author=Adam and Eve > > But dont do > Author=Eve > Author=Adam > because if you do that and then you get later a > Author=Lilith > what does that mean? that its now 1 Author or 3 Authors > or 2 and if 2 then which 2 ? > > Or said another way, you cant have multiple identical keys like that AND > allow updates. AFAIK, Matroska also has Metadata that are explicitly a tree and can have the same key. A good example is the ACTOR tag: Most movies have more than one actor, the CHARACTER should be a subtag of ACTOR [1]. Currently, FFmpeg just seem to ignore keys with multiple values and display the first. Best Gerion > [...] [1] https://www.matroska.org/technical/tagging.html (search for ACTOR) signature.asc Description: This is a digitally signed message part. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Am Mittwoch, 1. November 2023, 23:07:16 CET schrieb Jean-Baptiste Kempf: > Hey, > > On Wed, 1 Nov 2023, at 18:19, Michael Niedermayer wrote: > > Please provide the list of email addresses OR peoples names who > > should have received a mail for voting > > I don't think listing emails on this mailing list is a good idea, or even > legal (GDPR, for example). Not sure how similar the two lists are but http://ffmpeg.org/pipermail/ffmpeg-devel/2023-October/316062.html (same thread) already contains exactly such a list. Best, Gerion signature.asc Description: This is a digitally signed message part. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
