[FFmpeg-devel] [GSOC]Inquiry Regarding "Update SITI Filter to Match with Latest Specification" Project and Qualification Task

[Divyansh Khatri]

I hope this message finds you well. My name is Divyansh, and I am reaching
out to express my interest in the project titled "Update SITI Filter to
Match with Latest Specification" listed in Ideas list of FFmpeg 2024 GSOC(
link

).
I would appreciate a mentor's guidance regarding the qualification task
mentioned in the project description, I would like your advice on selecting
an appropriate bug to fix in the existing filter and how can I start
working on it for my GSOC proposal for FFmpeg?

Best regards
___
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 2024

[Thilo Borgmann via ffmpeg-devel]

Am 22.02.24 um 18:49 schrieb Matthias Dressel:

On 22.02.24 18:38, Thilo Borgmann via ffmpeg-devel wrote:

Am 02.01.24 um 22:47 schrieb Thilo Borgmann via ffmpeg-devel:

Hi,

the application period for GSoC 2024 begins on Jan 22nd.

Everyone interested in mentoring a project in 2024, please add your idea(s) to 
[1].



[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2024


we've been selected to participate again in GSoC 2024!

https://summerofcode.withgoogle.com/programs/2024/organizations/ffmpeg
links to the 2023 trac page.


No more!

Thanks,
Thilo

___
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 2024

[Matthias Dressel]

On 22.02.24 18:38, Thilo Borgmann via ffmpeg-devel wrote:

Am 02.01.24 um 22:47 schrieb Thilo Borgmann via ffmpeg-devel:

Hi,

the application period for GSoC 2024 begins on Jan 22nd.

Everyone interested in mentoring a project in 2024, please add your 
idea(s) to [1].



[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2024


we've been selected to participate again in GSoC 2024!

https://summerofcode.withgoogle.com/programs/2024/organizations/ffmpeg
links to the 2023 trac page.



Find all orgs at [2].

Cheers,
Thilo

[2] https://summerofcode.withgoogle.com/programs/2024/organizations

___
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 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 2024

[Thilo Borgmann via ffmpeg-devel]

Am 02.01.24 um 22:47 schrieb Thilo Borgmann via ffmpeg-devel:

Hi,

the application period for GSoC 2024 begins on Jan 22nd.

Everyone interested in mentoring a project in 2024, please add your idea(s) to 
[1].



[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2024


we've been selected to participate again in GSoC 2024!

Find all orgs at [2].

Cheers,
Thilo

[2] https://summerofcode.withgoogle.com/programs/2024/organizations

___
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 2024

[Thilo Borgmann via ffmpeg-devel]

Am 02.01.24 um 23:14 schrieb Thilo Borgmann via ffmpeg-devel:

Am 02.01.24 um 22:47 schrieb Thilo Borgmann via ffmpeg-devel:

Hi,

the application period for GSoC 2024 begins on Jan 22nd.

Everyone interested in mentoring a project in 2024, please add your idea(s) to 
[1].

The application deadline is February 6th, I will aim for sending an application 
Jan 1st.


Aiming for Feb 1st, obviously 0:-)


Reminder, add your GSoC project ideas soon if you want to do one.
Going to submit the application soon!

-Thilo

___
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 2024

[Thilo Borgmann via ffmpeg-devel]

Am 02.01.24 um 22:47 schrieb Thilo Borgmann via ffmpeg-devel:

Hi,

the application period for GSoC 2024 begins on Jan 22nd.

Everyone interested in mentoring a project in 2024, please add your idea(s) to 
[1].

The application deadline is February 6th, I will aim for sending an application 
Jan 1st.


Aiming for Feb 1st, obviously 0:-)

-Thilo

___
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] GSoC 2024

[Thilo Borgmann via ffmpeg-devel]

Hi,

the application period for GSoC 2024 begins on Jan 22nd.

Everyone interested in mentoring a project in 2024, please add your idea(s) to 
[1].

The application deadline is February 6th, I will aim for sending an application 
Jan 1st.

Thanks,
Thilo

[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2024
___
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] GSoC 2023 - Audio Overlay Filter

[Shivoy Arora]

Hey Everyone,

My name is Shivoy Arora, and I am thrilled to be here today to introduce
myself to you all. I am currently pursuing my Bachelor of Technology in
Computer Science and Applied Mathematics from Indraprastha Institute of
Information Technology, and I am in my second year of study.
I am interested in participating in the Google Summer of Code program and
working with your organisation. I have used FFmpeg a little before and I am
really passionate to use it more and learn its inner workings, while
contributing to this project.

I have been using Python, C, C++, Java, SwiftUI for the past five years,
and I have built several projects that incorporate OOPS and advanced
algorithms. In addition, I have studied Differential Equations, Discrete
Structures, Real Analysis,  Linear Algebra, Probability and Statistics,
Algorithm Design and Analysis, Data Structures and Algorithms, as a part of
my degree.

I am excited about the opportunity to work with your organisation and
contribute to your projects. I am confident that my programming skills,
coupled with my passion for learning, will enable me to excel in any task
that is assigned to me. I am eager to explore new concepts, collaborate
with others, and grow as a developer through this program.
I look forward to the opportunity to work with FFmpeg and am excited to
connect with new people who share the same motivation and interest in the
field.

I am interested in the project "Audio Overlay Filter", and I have already
started to study how to get started.
It would be really helpful if you could suggest some issues that I could
solve to get familiar with ffmpeg.

Thanks and regards
---

Shivoy Arora
Computer Science and Applied Mathematics
IIIT-D, Batch of '25
___
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 2023

[Thilo Borgmann]

Hi,

Am 15.12.22 um 15:42 schrieb Thilo Borgmann:
[...]


The application deadline is January 23rd, I will aim for sending an application 
mid January.



[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results
[2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023


we've been selected & announced to participate again!

Cheers,
Thilo


___
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 2023

[Nuo Mi]

On Mon, Jan 23, 2023 at 6:50 PM Thilo Borgmann 
wrote:

> Hi,
>
> sorry for delay, some thoughts:
>
> > Description: VVC is the successor to the well-known codec HEVC. The whole
> > video industry has high anticipation for  VVC. The goal of the ffvvc
> > project is to provide a VVC decoder for FFmpeg. We invite you to join us
> in> improving ffvvc. Depending on your background, you will help add
> > ALF/SAO/Predict assembly code or new features/tests for ffvvc.
> > Expected results: 500+ lines of code merged into the ffvvc project.
>
> The "We invite you..." sentence seems out of... our evil strictly
> technical style.
>
> I would avoid a background discussion and project definition talk with an
> interested student.
> Better do offer two distinct project ideas, one for assembly opts and one
> for features/tests.
> Possibly you could also split the testing into even a third project and
> make it the smallest project duration.
> It might even be extended to add tests in general... just VVC as the first
> to do.
>
> Also, we could only ask for one slot per project idea (which is meant to
> be taken by one individual).
> Means if you got more than one interested & capable students, you could
> not accept more than one.
>
>
> > Prerequisites: Good C and Assembly code, basic familiarity with Git, and
> > knowledge of codecs.
> >
> > Difficulty: Hard
> >
> > Qualification Task: Fix any issue on
> https://github.com/ffvvc/FFmpeg/issues
> > or any patch merged by ffvvc.
> >
> > Mentor: Nuo Mi (nuomi2021 at gmail dot com)
> >
> > Duration: 350 hours
>
>
> > Hi All,
> > It's more than welcome if somebody can do the co-mentor.  Please reply to
> > this if you are interested.
>
> This part will hardly be recognized by many, maybe sent another mail for
> that.
> It might be faster to ask once or twice on ffmpeg-devel IRC.
>
> For a testing project, you can add me as backup mentor.
> For the opts & features I would prefer someone else to do it - although I
> will if nobody else can be found.
>
> -Thilo
> ___
> 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".
>

Hi Thilo,
No worries.Especially when you have so detailed suggestions
Updated on https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023
Feel free to change it if something is not correct.

I ping IRC for backup mentors.

Thank you very much.
___
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 2023

[Thilo Borgmann]

Hi,

sorry for delay, some thoughts:


Description: VVC is the successor to the well-known codec HEVC. The whole
video industry has high anticipation for  VVC. The goal of the ffvvc
project is to provide a VVC decoder for FFmpeg. We invite you to join us in> 
improving ffvvc. Depending on your background, you will help add
ALF/SAO/Predict assembly code or new features/tests for ffvvc.
Expected results: 500+ lines of code merged into the ffvvc project.


The "We invite you..." sentence seems out of... our evil strictly technical 
style.

I would avoid a background discussion and project definition talk with an 
interested student.
Better do offer two distinct project ideas, one for assembly opts and one for 
features/tests.
Possibly you could also split the testing into even a third project and make it 
the smallest project duration.
It might even be extended to add tests in general... just VVC as the first to 
do.

Also, we could only ask for one slot per project idea (which is meant to be 
taken by one individual).
Means if you got more than one interested & capable students, you could not 
accept more than one.



Prerequisites: Good C and Assembly code, basic familiarity with Git, and
knowledge of codecs.

Difficulty: Hard

Qualification Task: Fix any issue on https://github.com/ffvvc/FFmpeg/issues
or any patch merged by ffvvc.

Mentor: Nuo Mi (nuomi2021 at gmail dot com)

Duration: 350 hours




Hi All,
It's more than welcome if somebody can do the co-mentor.  Please reply to
this if you are interested.


This part will hardly be recognized by many, maybe sent another mail for that.
It might be faster to ask once or twice on ffmpeg-devel IRC.

For a testing project, you can add me as backup mentor.
For the opts & features I would prefer someone else to do it - although I will 
if nobody else can be found.

-Thilo
___
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 2023

[Nuo Mi]

On Tue, Jan 17, 2023 at 11:22 PM Nuo Mi  wrote:

>
>
> On Mon, Jan 16, 2023 at 10:58 PM Jean-Baptiste Kempf 
> wrote:
>
>> On Mon, 16 Jan 2023, at 14:53, Nuo Mi wrote:
>> > Seems too hurried for this time.  Maybe next time
>>
>> I disagree: we can do (and should do) a small task for VVC dec in GSoC
>> 2023, like a fringe feature, not from the mainline.
>>
> Hi jb,
> Thank you for the suggestion. I love this idea. Let me prepare the
> description.
>
>
>>
>> jb
>>
>> --
>> Jean-Baptiste Kempf -  President
>> +33 672 704 734
>> ___
>> 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".
>>
>
Hi jb, Thilo,
How about this?

Description: VVC is the successor to the well-known codec HEVC. The whole
video industry has high anticipation for  VVC. The goal of the ffvvc
project is to provide a VVC decoder for FFmpeg. We invite you to join us in
improving ffvvc. Depending on your background, you will help add
ALF/SAO/Predict assembly code or new features/tests for ffvvc.
Expected results: 500+ lines of code merged into the ffvvc project.

Prerequisites: Good C and Assembly code, basic familiarity with Git, and
knowledge of codecs.

Difficulty: Hard

Qualification Task: Fix any issue on https://github.com/ffvvc/FFmpeg/issues
or any patch merged by ffvvc.

Mentor: Nuo Mi (nuomi2021 at gmail dot com)

Duration: 350 hours

Hi All,
It's more than welcome if somebody can do the co-mentor.  Please reply to
this if you are interested.

Thank you.
___
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 2023

[Nuo Mi]

On Mon, Jan 16, 2023 at 10:58 PM Jean-Baptiste Kempf 
wrote:

> On Mon, 16 Jan 2023, at 14:53, Nuo Mi wrote:
> > Seems too hurried for this time.  Maybe next time
>
> I disagree: we can do (and should do) a small task for VVC dec in GSoC
> 2023, like a fringe feature, not from the mainline.
>
Hi jb,
Thank you for the suggestion. I love this idea. Let me prepare the
description.


>
> jb
>
> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> ___
> 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 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 2023

[Jean-Baptiste Kempf]

On Mon, 16 Jan 2023, at 14:53, Nuo Mi wrote:
> Seems too hurried for this time.  Maybe next time

I disagree: we can do (and should do) a small task for VVC dec in GSoC 2023, 
like a fringe feature, not from the mainline.

jb

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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 2023

[Nuo Mi]

On Mon, Jan 16, 2023 at 6:18 AM Thilo Borgmann 
wrote:

> Am 15.01.23 um 15:28 schrieb Nuo Mi:
> > On Sun, Jan 15, 2023 at 9:27 PM Ronald S. Bultje 
> wrote:
> >
> >> Hi,
> >>
> >> On Sun, Jan 15, 2023 at 4:20 AM Nuo Mi  wrote:
> >>
> >>> Is it finalized?  Any chance to add some items in
> >>> https://github.com/ffvvc/FFmpeg/issues to the GSOC 2023?
> >>>
> >>
> >> It all depends on the student. And baseline ffvvc needs to be in already
> >> when the project starts. So it's not straightforward.
>
> Yet we are openand can add project proposals before the application
> deadline (Feb. 7th).
> Do not wait until the last day, especially that having VVC yet in review
> does not make it easier to describe/define.
> The project needs to extend the decoder, mere upstreaming should not be
> enough IIUC.
> Also yes, it is highly preferable to have something upstream before
> project start end of Mai.
>
>
> >> Are you proposing to be the student? Or what's your plan?
> >>
> > I am not so young. :)
> > Just want to get more exposure and resources to prepare a decent version
> > upstream.
>
> Most importantly define a valid project and find a mentor with the time
> and abilities needed.
> Having a (co-)mentor is also especially if you want to mentor it yourself.
>
> -Thilo
> ___
> 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".
>

Hi Thilo and Ronald,
Thank you for the detailed information.
Seems too hurried for this time.  Maybe next time
Or everything is smooth, we do need GSOC 2024 for VVC decoder :)
___
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 2023

[Thilo Borgmann]

Am 15.01.23 um 15:28 schrieb Nuo Mi:

On Sun, Jan 15, 2023 at 9:27 PM Ronald S. Bultje  wrote:


Hi,

On Sun, Jan 15, 2023 at 4:20 AM Nuo Mi  wrote:


Is it finalized?  Any chance to add some items in
https://github.com/ffvvc/FFmpeg/issues to the GSOC 2023?



It all depends on the student. And baseline ffvvc needs to be in already
when the project starts. So it's not straightforward.


Yet we are openand can add project proposals before the application deadline 
(Feb. 7th).
Do not wait until the last day, especially that having VVC yet in review does 
not make it easier to describe/define.
The project needs to extend the decoder, mere upstreaming should not be enough 
IIUC.
Also yes, it is highly preferable to have something upstream before project 
start end of Mai.



Are you proposing to be the student? Or what's your plan?


I am not so young. :)
Just want to get more exposure and resources to prepare a decent version
upstream.


Most importantly define a valid project and find a mentor with the time and 
abilities needed.
Having a (co-)mentor is also especially if you want to mentor it yourself.

-Thilo
___
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 2023

[Nuo Mi]

On Sun, Jan 15, 2023 at 9:57 PM Jean-Baptiste Kempf  wrote:

> On Sun, 15 Jan 2023, at 14:26, Ronald S. Bultje wrote:
> > Are you proposing to be the student? Or what's your plan?
>
> Be careful, GSoC is not only for students anymore.
>
You inspired me. Maybe I can create an open-source project. Mentor myself,
and get funding from gsoc every year.

>
> Best,
>
> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> ___
> 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 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 2023

[Nuo Mi]

On Sun, Jan 15, 2023 at 9:27 PM Ronald S. Bultje  wrote:

> Hi,
>
> On Sun, Jan 15, 2023 at 4:20 AM Nuo Mi  wrote:
>
> > Is it finalized?  Any chance to add some items in
> > https://github.com/ffvvc/FFmpeg/issues to the GSOC 2023?
> >
>
> It all depends on the student. And baseline ffvvc needs to be in already
> when the project starts. So it's not straightforward.
>
> Are you proposing to be the student? Or what's your plan?
>
I am not so young. :)
Just want to get more exposure and resources to prepare a decent version
upstream.


> Ronald
> ___
> 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 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 2023

[Jean-Baptiste Kempf]

On Sun, 15 Jan 2023, at 14:26, Ronald S. Bultje wrote:
> Are you proposing to be the student? Or what's your plan?

Be careful, GSoC is not only for students anymore.

Best,

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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 2023

[Ronald S. Bultje]

Hi,

On Sun, Jan 15, 2023 at 4:20 AM Nuo Mi  wrote:

> Is it finalized?  Any chance to add some items in
> https://github.com/ffvvc/FFmpeg/issues to the GSOC 2023?
>

It all depends on the student. And baseline ffvvc needs to be in already
when the project starts. So it's not straightforward.

Are you proposing to be the student? Or what's your plan?

Ronald
___
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 2023

[Nuo Mi]

On Mon, Dec 19, 2022 at 12:48 AM Thilo Borgmann 
wrote:

> Am 15.12.22 um 23:47 schrieb Pierre-Anthony Lemieux:
> > I have updated the page with the HTJ2K project.
>
> Cool, thanks!
>
>
> > This is a good opportunity to ask for help completing the review of
> > the patchset:
> >
> > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8078
> >
> > All known issues have been resolved and it would be good to merge
> > soon, i.e. beat the iron while it is hot.
> >
> > On Thu, Dec 15, 2022 at 6:47 AM Jean-Baptiste Kempf 
> wrote:
> >>
> >> Hello,
> >>
> >> Also, please don’t copy paste ideas from previous years. If the idea
> did not get picked up for years, it won’t be more useful this year.
> >>
> >> jb
>
> As if both of you wouldn't be aware that there shall be no top-posting
> here...
>
>
> -Thilo
>
> >> On Thu, 15 Dec 2022, at 15:42, Thilo Borgmann wrote:
> >>> Hi,
> >>>
> >>> as we figured during the last dev meeting on December 2nd we want to
> >>> apply again for GSoC 2023.
> >>>
> >>> I told mentors often enough already that it's a vital point in our
> >>> applications to have a properly filled results page from the last GSoC
> >>> we did.
> >>> Last time no mentor cared about this - we can be quite sure that our
> >>> application will fail if we don't have [1] up-to-date until we send our
> >>> application.
> >>>
> >>> Also vital for the application are already existing project ideas so
> >>> everyone interested in mentoring a project in 2023, please add your
> >>> idea(s) to [2].
> >>>
> >>> The application deadline is January 23rd, I will aim for sending an
> >>> application mid January.
> >>>
> >>> Thanks,
> >>> Thilo
> >>>
> >>> [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results
> >>> [2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023
> >>> ___
> >>> 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".
> >>
> >> --
> >> Jean-Baptiste Kempf -  President
> >> +33 672 704 734
> >> ___
> >> 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 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 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".
>

Hi Thilo, Ronald, Pierre, and all,
Is it finalized?  Any chance to add some items in
https://github.com/ffvvc/FFmpeg/issues to the GSOC 2023?

thank you
___
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 2023

[Thilo Borgmann]

Am 15.12.22 um 23:47 schrieb Pierre-Anthony Lemieux:

I have updated the page with the HTJ2K project.


Cool, thanks!



This is a good opportunity to ask for help completing the review of
the patchset:

https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8078

All known issues have been resolved and it would be good to merge
soon, i.e. beat the iron while it is hot.

On Thu, Dec 15, 2022 at 6:47 AM Jean-Baptiste Kempf  wrote:


Hello,

Also, please don’t copy paste ideas from previous years. If the idea did not 
get picked up for years, it won’t be more useful this year.

jb


As if both of you wouldn't be aware that there shall be no top-posting 
here...


-Thilo


On Thu, 15 Dec 2022, at 15:42, Thilo Borgmann wrote:

Hi,

as we figured during the last dev meeting on December 2nd we want to
apply again for GSoC 2023.

I told mentors often enough already that it's a vital point in our
applications to have a properly filled results page from the last GSoC
we did.
Last time no mentor cared about this - we can be quite sure that our
application will fail if we don't have [1] up-to-date until we send our
application.

Also vital for the application are already existing project ideas so
everyone interested in mentoring a project in 2023, please add your
idea(s) to [2].

The application deadline is January 23rd, I will aim for sending an
application mid January.

Thanks,
Thilo

[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results
[2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023
___
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".


--
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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 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 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 2023

[Pierre-Anthony Lemieux]

I have updated the page with the HTJ2K project.

This is a good opportunity to ask for help completing the review of
the patchset:

https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8078

All known issues have been resolved and it would be good to merge
soon, i.e. beat the iron while it is hot.

On Thu, Dec 15, 2022 at 6:47 AM Jean-Baptiste Kempf  wrote:
>
> Hello,
>
> Also, please don’t copy paste ideas from previous years. If the idea did not 
> get picked up for years, it won’t be more useful this year.
>
> jb
>
> On Thu, 15 Dec 2022, at 15:42, Thilo Borgmann wrote:
> > Hi,
> >
> > as we figured during the last dev meeting on December 2nd we want to
> > apply again for GSoC 2023.
> >
> > I told mentors often enough already that it's a vital point in our
> > applications to have a properly filled results page from the last GSoC
> > we did.
> > Last time no mentor cared about this - we can be quite sure that our
> > application will fail if we don't have [1] up-to-date until we send our
> > application.
> >
> > Also vital for the application are already existing project ideas so
> > everyone interested in mentoring a project in 2023, please add your
> > idea(s) to [2].
> >
> > The application deadline is January 23rd, I will aim for sending an
> > application mid January.
> >
> > Thanks,
> > Thilo
> >
> > [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results
> > [2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023
> > ___
> > 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".
>
> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> ___
> 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 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 2023

[Jean-Baptiste Kempf]

Hello,

Also, please don’t copy paste ideas from previous years. If the idea did not 
get picked up for years, it won’t be more useful this year.

jb

On Thu, 15 Dec 2022, at 15:42, Thilo Borgmann wrote:
> Hi,
>
> as we figured during the last dev meeting on December 2nd we want to 
> apply again for GSoC 2023.
>
> I told mentors often enough already that it's a vital point in our 
> applications to have a properly filled results page from the last GSoC 
> we did.
> Last time no mentor cared about this - we can be quite sure that our 
> application will fail if we don't have [1] up-to-date until we send our 
> application.
>
> Also vital for the application are already existing project ideas so 
> everyone interested in mentoring a project in 2023, please add your 
> idea(s) to [2].
>
> The application deadline is January 23rd, I will aim for sending an 
> application mid January.
>
> Thanks,
> Thilo
>
> [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results
> [2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023
> ___
> 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".

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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] GSoC 2023

[Thilo Borgmann]

Hi,

as we figured during the last dev meeting on December 2nd we want to apply 
again for GSoC 2023.

I told mentors often enough already that it's a vital point in our applications 
to have a properly filled results page from the last GSoC we did.
Last time no mentor cared about this - we can be quite sure that our 
application will fail if we don't have [1] up-to-date until we send our 
application.

Also vital for the application are already existing project ideas so everyone 
interested in mentoring a project in 2023, please add your idea(s) to [2].

The application deadline is January 23rd, I will aim for sending an application 
mid January.

Thanks,
Thilo

[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results
[2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023
___
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'22] Added Chromakey CUDA filter

[Timo Rothenpieler]

On 30.06.2022 02:01, mohamed Elhadidy wrote:

GSoC'22 GPU accelerated video filters
Added CUDA chromakeyfilter
libavfilter/vf_chromakey_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_chromakey_cuda.c: the C side that calls the kernel and gets user 
input
libavfilter/allfilters.c: added the filter to it
libavfilter/Makefile: added the filter to it
cuda/cuda_runtime.h: added two math CUDA functions that are used in the filter
---
  compat/cuda/cuda_runtime.h   |   2 +
  libavfilter/Makefile |   2 +
  libavfilter/allfilters.c |   1 +
  libavfilter/vf_chromakey_cuda.c  | 520 +++
  libavfilter/vf_chromakey_cuda.cu | 248 +++
  5 files changed, 773 insertions(+)
  create mode 100644 libavfilter/vf_chromakey_cuda.c
  create mode 100644 libavfilter/vf_chromakey_cuda.cu

diff --git a/compat/cuda/cuda_runtime.h b/compat/cuda/cuda_runtime.h
index 30cd085e48..5837c1ad37 100644
--- a/compat/cuda/cuda_runtime.h
+++ b/compat/cuda/cuda_runtime.h
@@ -181,7 +181,9 @@ static inline __device__ double trunc(double a) { return 
__builtin_trunc(a); }
  static inline __device__ float fabsf(float a) { return __builtin_fabsf(a); }
  static inline __device__ float fabs(float a) { return __builtin_fabsf(a); }
  static inline __device__ double fabs(double a) { return __builtin_fabs(a); }
+static inline __device__ float sqrtf(float a) { return __builtin_sqrtf(a); }
  
+static inline __device__ float __saturatef(float a) { return __nvvm_saturate_f(a); }

  static inline __device__ float __sinf(float a) { return 
__nvvm_sin_approx_f(a); }
  static inline __device__ float __cosf(float a) { return 
__nvvm_cos_approx_f(a); }
  static inline __device__ float __expf(float a) { return __nvvm_ex2_approx_f(a 
* (float)__builtin_log2(__builtin_exp(1))); }
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 22b0a0ca15..8aee10fc76 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -210,6 +210,8 @@ OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
  OBJS-$(CONFIG_CHROMABER_VULKAN_FILTER)   += vf_chromaber_vulkan.o 
vulkan.o vulkan_filter.o
  OBJS-$(CONFIG_CHROMAHOLD_FILTER) += vf_chromakey.o
  OBJS-$(CONFIG_CHROMAKEY_FILTER)  += vf_chromakey.o
+OBJS-$(CONFIG_CHROMAKEY_CUDA_FILTER) += vf_chromakey_cuda.o  
vf_chromakey_cuda.ptx.o framesync.o


This doesn't use framesync at all, does it?
Only the overlay filter does.


  OBJS-$(CONFIG_CHROMANR_FILTER)   += vf_chromanr.o
  OBJS-$(CONFIG_CHROMASHIFT_FILTER)+= vf_chromashift.o
  OBJS-$(CONFIG_CIESCOPE_FILTER)   += vf_ciescope.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ec70feef11..da1a96b23c 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -195,6 +195,7 @@ extern const AVFilter ff_vf_cas;
  extern const AVFilter ff_vf_chromaber_vulkan;
  extern const AVFilter ff_vf_chromahold;
  extern const AVFilter ff_vf_chromakey;
+extern const AVFilter ff_vf_chromakey_cuda;
  extern const AVFilter ff_vf_chromanr;
  extern const AVFilter ff_vf_chromashift;
  extern const AVFilter ff_vf_ciescope;
diff --git a/libavfilter/vf_chromakey_cuda.c b/libavfilter/vf_chromakey_cuda.c
new file mode 100644
index 00..822488d436
--- /dev/null
+++ b/libavfilter/vf_chromakey_cuda.c
@@ -0,0 +1,520 @@
+/*
+* Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.


This probably should be changed, there's basically none of the original 
code left.



+* Permission is hereby granted, free of charge, to any person obtaining a
+* copy of this software and associated documentation files (the "Software"),
+* to deal in the Software without restriction, including without limitation
+* the rights to use, copy, modify, merge, publish, distribute, sublicense,
+* and/or sell copies of the Software, and to permit persons to whom the
+* Software is furnished to do so, subject to the following conditions:
+*
+* The above copyright notice and this permission notice shall be included in
+* all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+* DEALINGS IN THE SOFTWARE.
+*/
+
+#include 
+#include 
+#include 
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/cuda_check.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+

[FFmpeg-devel] [GSoC'22] Added Chromakey CUDA filter

[mohamed Elhadidy]

From: Mohamed Khaled Mohamed 
<56936494+mohamedelhadidy0...@users.noreply.github.com>


GSoC'22 GPU accelerated video filters
Added CUDA chromakeyfilter
libavfilter/vf_chromakey_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_chromakey_cuda.c: the C side that calls the kernel and gets user 
input
libavfilter/allfilters.c: added the filter to it
libavfilter/Makefile: added the filter to it
cuda/cuda_runtime.h: added two math CUDA functions that are used in the filter
---
 compat/cuda/cuda_runtime.h   |   2 +
 libavfilter/Makefile |   2 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_chromakey_cuda.c  | 520 +++
 libavfilter/vf_chromakey_cuda.cu | 248 +++
 5 files changed, 773 insertions(+)
 create mode 100644 libavfilter/vf_chromakey_cuda.c
 create mode 100644 libavfilter/vf_chromakey_cuda.cu

diff --git a/compat/cuda/cuda_runtime.h b/compat/cuda/cuda_runtime.h
index 30cd085e48..5837c1ad37 100644
--- a/compat/cuda/cuda_runtime.h
+++ b/compat/cuda/cuda_runtime.h
@@ -181,7 +181,9 @@ static inline __device__ double trunc(double a) { return 
__builtin_trunc(a); }
 static inline __device__ float fabsf(float a) { return __builtin_fabsf(a); }
 static inline __device__ float fabs(float a) { return __builtin_fabsf(a); }
 static inline __device__ double fabs(double a) { return __builtin_fabs(a); }
+static inline __device__ float sqrtf(float a) { return __builtin_sqrtf(a); }
 
+static inline __device__ float __saturatef(float a) { return 
__nvvm_saturate_f(a); }
 static inline __device__ float __sinf(float a) { return 
__nvvm_sin_approx_f(a); }
 static inline __device__ float __cosf(float a) { return 
__nvvm_cos_approx_f(a); }
 static inline __device__ float __expf(float a) { return __nvvm_ex2_approx_f(a 
* (float)__builtin_log2(__builtin_exp(1))); }
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 22b0a0ca15..8aee10fc76 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -210,6 +210,8 @@ OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
 OBJS-$(CONFIG_CHROMABER_VULKAN_FILTER)   += vf_chromaber_vulkan.o vulkan.o 
vulkan_filter.o
 OBJS-$(CONFIG_CHROMAHOLD_FILTER) += vf_chromakey.o
 OBJS-$(CONFIG_CHROMAKEY_FILTER)  += vf_chromakey.o
+OBJS-$(CONFIG_CHROMAKEY_CUDA_FILTER) += vf_chromakey_cuda.o  
vf_chromakey_cuda.ptx.o framesync.o
+
 OBJS-$(CONFIG_CHROMANR_FILTER)   += vf_chromanr.o
 OBJS-$(CONFIG_CHROMASHIFT_FILTER)+= vf_chromashift.o
 OBJS-$(CONFIG_CIESCOPE_FILTER)   += vf_ciescope.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ec70feef11..da1a96b23c 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -195,6 +195,7 @@ extern const AVFilter ff_vf_cas;
 extern const AVFilter ff_vf_chromaber_vulkan;
 extern const AVFilter ff_vf_chromahold;
 extern const AVFilter ff_vf_chromakey;
+extern const AVFilter ff_vf_chromakey_cuda;
 extern const AVFilter ff_vf_chromanr;
 extern const AVFilter ff_vf_chromashift;
 extern const AVFilter ff_vf_ciescope;
diff --git a/libavfilter/vf_chromakey_cuda.c b/libavfilter/vf_chromakey_cuda.c
new file mode 100644
index 00..822488d436
--- /dev/null
+++ b/libavfilter/vf_chromakey_cuda.c
@@ -0,0 +1,520 @@
+/*
+* Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.
+*
+* Permission is hereby granted, free of charge, to any person obtaining a
+* copy of this software and associated documentation files (the "Software"),
+* to deal in the Software without restriction, including without limitation
+* the rights to use, copy, modify, merge, publish, distribute, sublicense,
+* and/or sell copies of the Software, and to permit persons to whom the
+* Software is furnished to do so, subject to the following conditions:
+*
+* The above copyright notice and this permission notice shall be included in
+* all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+* DEALINGS IN THE SOFTWARE.
+*/
+
+#include 
+#include 
+#include 
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/cuda_check.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+#include "cuda/load_helper.h"
+
+
+
+#define FIXNUM(x) lrint((x) * (1 << 10))
+#define RGB_TO_U(rgb) (((- FIXNUM(0.16874) * rgb[0] - 

Re: [FFmpeg-devel] [GSoC'22] Added Chromakey CUDA filter

[Timo Rothenpieler]

On 30.06.2022 00:42, mohamed Elhadidy wrote:

From: Mohamed Khaled Mohamed 
<56936494+mohamedelhadidy0...@users.noreply.github.com>

GSoC'22
Added CUDA chromakeyfilter
libavfilter/vf_chromakey_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_chromakey_cuda.c: the C side that calls the kernel and gets user 
input
libavfilter/allfilters.c: added the filter to it
libavfilter/Makefile: added the filter to it
cuda/cuda_runtime.h: added two math CUDA functions that are used in the filter
---
  compat/cuda/cuda_runtime.h   |   2 +
  libavfilter/Makefile |   2 +
  libavfilter/allfilters.c |   1 +
  libavfilter/vf_chromakey_cuda.c  | 520 +++
  libavfilter/vf_chromakey_cuda.cu | 248 +++
  5 files changed, 773 insertions(+)
  create mode 100644 libavfilter/vf_chromakey_cuda.c
  create mode 100644 libavfilter/vf_chromakey_cuda.cu

diff --git a/compat/cuda/cuda_runtime.h b/compat/cuda/cuda_runtime.h
index 30cd085e48..51eb99c2e8 100644
--- a/compat/cuda/cuda_runtime.h
+++ b/compat/cuda/cuda_runtime.h
@@ -181,7 +181,9 @@ static inline __device__ double trunc(double a) { return 
__builtin_trunc(a); }
  static inline __device__ float fabsf(float a) { return __builtin_fabsf(a); }
  static inline __device__ float fabs(float a) { return __builtin_fabsf(a); }
  static inline __device__ double fabs(double a) { return __builtin_fabs(a); }
+static inline __device__ double sqrtf(double a) { return __builtin_sqrtf(a); }
  
+static inline __device__ double __saturatef(double a) { return __saturatef(a); }


Don't have time for a full review right now, but this doesn't look 
right. That's building an infinite recursion.

It should be some __nvvm_... function like the rest.
___
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] [GSoC'22] Added Chromakey CUDA filter

[mohamed Elhadidy]

From: Mohamed Khaled Mohamed 
<56936494+mohamedelhadidy0...@users.noreply.github.com>

GSoC'22
Added CUDA chromakeyfilter
libavfilter/vf_chromakey_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_chromakey_cuda.c: the C side that calls the kernel and gets user 
input
libavfilter/allfilters.c: added the filter to it
libavfilter/Makefile: added the filter to it
cuda/cuda_runtime.h: added two math CUDA functions that are used in the filter
---
 compat/cuda/cuda_runtime.h   |   2 +
 libavfilter/Makefile |   2 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_chromakey_cuda.c  | 520 +++
 libavfilter/vf_chromakey_cuda.cu | 248 +++
 5 files changed, 773 insertions(+)
 create mode 100644 libavfilter/vf_chromakey_cuda.c
 create mode 100644 libavfilter/vf_chromakey_cuda.cu

diff --git a/compat/cuda/cuda_runtime.h b/compat/cuda/cuda_runtime.h
index 30cd085e48..51eb99c2e8 100644
--- a/compat/cuda/cuda_runtime.h
+++ b/compat/cuda/cuda_runtime.h
@@ -181,7 +181,9 @@ static inline __device__ double trunc(double a) { return 
__builtin_trunc(a); }
 static inline __device__ float fabsf(float a) { return __builtin_fabsf(a); }
 static inline __device__ float fabs(float a) { return __builtin_fabsf(a); }
 static inline __device__ double fabs(double a) { return __builtin_fabs(a); }
+static inline __device__ double sqrtf(double a) { return __builtin_sqrtf(a); }
 
+static inline __device__ double __saturatef(double a) { return __saturatef(a); 
}
 static inline __device__ float __sinf(float a) { return 
__nvvm_sin_approx_f(a); }
 static inline __device__ float __cosf(float a) { return 
__nvvm_cos_approx_f(a); }
 static inline __device__ float __expf(float a) { return __nvvm_ex2_approx_f(a 
* (float)__builtin_log2(__builtin_exp(1))); }
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 22b0a0ca15..8aee10fc76 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -210,6 +210,8 @@ OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
 OBJS-$(CONFIG_CHROMABER_VULKAN_FILTER)   += vf_chromaber_vulkan.o vulkan.o 
vulkan_filter.o
 OBJS-$(CONFIG_CHROMAHOLD_FILTER) += vf_chromakey.o
 OBJS-$(CONFIG_CHROMAKEY_FILTER)  += vf_chromakey.o
+OBJS-$(CONFIG_CHROMAKEY_CUDA_FILTER) += vf_chromakey_cuda.o  
vf_chromakey_cuda.ptx.o framesync.o
+
 OBJS-$(CONFIG_CHROMANR_FILTER)   += vf_chromanr.o
 OBJS-$(CONFIG_CHROMASHIFT_FILTER)+= vf_chromashift.o
 OBJS-$(CONFIG_CIESCOPE_FILTER)   += vf_ciescope.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ec70feef11..da1a96b23c 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -195,6 +195,7 @@ extern const AVFilter ff_vf_cas;
 extern const AVFilter ff_vf_chromaber_vulkan;
 extern const AVFilter ff_vf_chromahold;
 extern const AVFilter ff_vf_chromakey;
+extern const AVFilter ff_vf_chromakey_cuda;
 extern const AVFilter ff_vf_chromanr;
 extern const AVFilter ff_vf_chromashift;
 extern const AVFilter ff_vf_ciescope;
diff --git a/libavfilter/vf_chromakey_cuda.c b/libavfilter/vf_chromakey_cuda.c
new file mode 100644
index 00..822488d436
--- /dev/null
+++ b/libavfilter/vf_chromakey_cuda.c
@@ -0,0 +1,520 @@
+/*
+* Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.
+*
+* Permission is hereby granted, free of charge, to any person obtaining a
+* copy of this software and associated documentation files (the "Software"),
+* to deal in the Software without restriction, including without limitation
+* the rights to use, copy, modify, merge, publish, distribute, sublicense,
+* and/or sell copies of the Software, and to permit persons to whom the
+* Software is furnished to do so, subject to the following conditions:
+*
+* The above copyright notice and this permission notice shall be included in
+* all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+* DEALINGS IN THE SOFTWARE.
+*/
+
+#include 
+#include 
+#include 
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/cuda_check.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+#include "cuda/load_helper.h"
+
+
+
+#define FIXNUM(x) lrint((x) * (1 << 10))
+#define RGB_TO_U(rgb) (((- FIXNUM(0.16874) * rgb[0] - FIXNUM(0.33126) * rgb[1] 
+ FIXNUM(0.5) * 

Re: [FFmpeg-devel] GSoC 2022

[Thilo Borgmann]

Hi!


FFmpeg has been accepted for GSoC this year again!

Thanks to everyone who wants to mentor and proposed a project!

https://summerofcode.withgoogle.com/programs/2022/organizations/ffmpeg
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022


We've been granted two slots this year!

One project will be JPEG 2000 (HT) decoder and the other will be CPU (CUDA) 
accellerated video filters.

Thanks and good luck!
-Thilo
___
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 2022

[Michael Niedermayer]

Hi all

FFmpeg has been accepted for GSoC this year again! 

Thanks to everyone who wants to mentor and proposed a project!

https://summerofcode.withgoogle.com/programs/2022/organizations/ffmpeg
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


signature.asc
Description: PGP signature
___
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] GSoC 2022 ideas page

[Michael Niedermayer]

Hi all

CCing other admins and mentors on the page

Our ideas page is this year in exceptionally poor condition
I am not sure why this happened. I did actually intend to be just
backup admin for it this year. and that kind of worked last one.
But now today I get a warning from google about the page
And ive already started to clean it up a bit but if you have time
a 2nd pair of eyes surely is a good idea. Also if you are mentor this
year please check your entry.
And if you arent mentor, please ask yourself if maybe you want to
mentor, because we have relativly few ideas on the page compared to
previous years.
And we still need backup mentors!

The mail is below:

Hello GSoC 2022 Org Admin Applicants,

We are busy reviewing all the GSoC 2022 Org Apps and are finding a large
number of organizations that are missing information from their Ideas list.
Rather than individually emailing each org separately with issues I am
sending an email to all orgs that applied to ask you all to please look at
your ideas list and be sure you have done the following things:

1. Be sure to include whether the project is a 175 hour (medium sized) or
350 hour (large project). If it can be either please state that - per idea.
This is missing from about 25% of the org apps right now. Please use the
175 hour and 350 hour designations instead of full time, half time, large,
medium, or any other term.

2. Your Ideas Page URL should be accessible to all and not require login.
This is the same URL contributors will be using if your org is
selected. Test using Chrome Incognito or Firefox Private Browsing modes.

3. As we state in the Defining a Project Idea List

section of the Mentor guide, please provide the following information for
each idea:

a) a project title/description

b) more detailed description of the project (2-5+ sentences)

c) expected outcomes

d) skills required/preferred

e) possible mentors

f) expected size of project (175 or 350 hour)

g) an easy, medium or hard difficulty rating of each project.

4. Some of you are still working on your ideas.  Adding and refining ideas
is fine, but we are reviewing them between now and Monday. We can only make
decisions based on what we see when we review your application. For
example, if you only have 2 ideas when we review your org app, your org
will be rejected.

If you want to be selected this year I strongly suggest you make sure your
Project Ideas list meets the above requirements ASAP.




-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: PGP signature
___
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] GSoC 2022

[Thilo Borgmann]

Hi!

GSoC 2022 just started the org application phase. As usual, we'll send an 
application and need to gather project ideas for GSoC 2022.
There is the 2022 GSoC page in our wiki now [1], please add your project idea 
before the application deadline there or send it to the ML for discussion.

Application deadline is Feb. 21st. See the detailed timeline [2].

Furthermore, the project conditions as well as eligibility for contributors changed 
(again) this year. GSoC is not only for students anymore and project scope & 
schedule can be more freely choosen. See [3] for details!

Thanks,
Thilo

[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022
[2] https://developers.google.com/open-source/gsoc/timeline
[3] 
https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html
___
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 2021] about proposal

[kernel.bin]

Thanks! I will pay attention to it next time!
___
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 2021] about proposal

[Christopher Degawa]

You might want to check your email client as it has added a bunch of
`` which mangles your message when viewed
___
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] [GSoC 2021] about proposal

[kernel.bin]

To whom it may concern:
  May I ask if my GSoC proposal draft is visible,
  the name should be "FFmpeg Windows Screen Record via 
Desktop Duplication"
  Thanks! :)
___
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] GSOC 2021 project "Windows Screen Capture via Desktop Duplication".

[kernel.bin]

Hello everyone!


I'm He Yang, a college student from FuZhou University, China, now major in
Computer Science. I've been using ffmpeg for years, and I'm interested in 
the
GSoC idea "Windows Screen Capture via Desktop Duplication".


I've successfully attened GSoC as a student of ReactOS last year, and I've 
been
writing Win32 code for a long time. I've already found a few trivial bugs 
in
`libavdevice\gdigrab.c` and send a patch for fixing one of it few days before.


This idea is marked as unmentored projects, so I'd like to ask how can I 
find
a mentor and get a qualification task, and what to do next.


I would be very glad if a chance was given to me to contribute to FFmpeg.
Thanks!


Sincerely
He Yang
___
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 2021 project Guided Filter

[Steven Liu]

> 2021年3月16日 上午5:20，Shubham Sahoo  写道：
> 
> Hello Steven,
> 
> I have implemented the code for the Guided filter. Can you guide me with
> the next steps? And should I submit a patch?
Next step you should read GSoC rules careful, follow the rhythm of GSoC,
And read some documentations: 
https://ffmpeg.org/contact.html#MailingLists
https://ffmpeg.org/developer.html
https://ffmpeg.org/git-howto.html

Optimizing the Guided Filter performance and get performance data, and compare 
the data before and after optimization

I saw you always top-posting, maybe you have not read documentations yet.
> 
> 
> 
> *Regards*
> *Shubham*
> 
> 
> On Fri, Mar 12, 2021 at 4:36 PM Steven Liu  wrote:
> 
>> 
>> 
>>> 2021年3月12日 下午6:27，Shubham Sahoo  写道：
>>> 
>>> Hi everyone,
>>> 
>>> I'm Shubham Sahoo, an undergraduate student in Electronics and Electrical
>>> Communication Engineering from India. I would like to work on the project
>>> "Guided Filter" in GSOC 2021. Can anyone please guide me with the next
>>> steps, the qualification tasks, and the project information?
>> 1. You could try understand these rules under the link:
>> https://summerofcode.withgoogle.com/get-started/
>> 
>> 2. And understand Guided Filter Calculation:
>> For example: http://kaiminghe.com/eccv10/
>> 
>> 3. And try to implement a filter for that.
>> 
>> 
>>> 
>>> Thanks
>>> ___
>>> 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".
>> 
>> Thanks
>> 
>> Steven Liu
>> 
>> 
>> 
>> ___
>> 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 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".

Thanks

Steven Liu



___
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 2021 project Guided Filter

[Shubham Sahoo]

Hello Steven,

I have implemented the code for the Guided filter. Can you guide me with
the next steps? And should I submit a patch?


*Regards*
*Shubham*


On Fri, Mar 12, 2021 at 4:36 PM Steven Liu  wrote:

>
>
> > 2021年3月12日 下午6:27，Shubham Sahoo  写道：
> >
> > Hi everyone,
> >
> > I'm Shubham Sahoo, an undergraduate student in Electronics and Electrical
> > Communication Engineering from India. I would like to work on the project
> > "Guided Filter" in GSOC 2021. Can anyone please guide me with the next
> > steps, the qualification tasks, and the project information?
> 1. You could try understand these rules under the link:
> https://summerofcode.withgoogle.com/get-started/
>
> 2. And understand Guided Filter Calculation:
> For example: http://kaiminghe.com/eccv10/
>
> 3. And try to implement a filter for that.
>
>
> >
> > Thanks
> > ___
> > 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".
>
> Thanks
>
> Steven Liu
>
>
>
> ___
> 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 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 2021 project Guided Filter

[Steven Liu]

> 2021年3月12日 下午6:27，Shubham Sahoo  写道：
> 
> Hi everyone,
> 
> I'm Shubham Sahoo, an undergraduate student in Electronics and Electrical
> Communication Engineering from India. I would like to work on the project
> "Guided Filter" in GSOC 2021. Can anyone please guide me with the next
> steps, the qualification tasks, and the project information?
1. You could try understand these rules under the link:
https://summerofcode.withgoogle.com/get-started/

2. And understand Guided Filter Calculation:
For example: http://kaiminghe.com/eccv10/

3. And try to implement a filter for that.


> 
> Thanks
> ___
> 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".

Thanks

Steven Liu



___
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] GSOC 2021 project Guided Filter

[Shubham Sahoo]

Hi everyone,

I'm Shubham Sahoo, an undergraduate student in Electronics and Electrical
Communication Engineering from India. I would like to work on the project
"Guided Filter" in GSOC 2021. Can anyone please guide me with the next
steps, the qualification tasks, and the project information?

Thanks
___
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 2021

[Thilo Borgmann]

Hi!

> Most people probably already know but just to be sure everyone knows
> GSoC 2021 is 175h not 350h
> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1
> 
> Some project ideas may need to be adjusted accordingly

FFmpeg has been accepted for GSoC this year [1]!

Thanks to everyone who proposed a project! 
Please direct anyone interested to the ideas page [2].

Thanks,
Thilo

[1] https://summerofcode.withgoogle.com/organizations
[2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2021
___
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] GSoC 2020 results page

[Michael Niedermayer]

Hi all

If you mentored a project in 2020, please fill the results on the results page
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results

Its empty ATM and previous years it was filled

If you where a student of 2020 you can of course fill in your projects results 
too :)
also anyone who want to help fill this is of course welcome to help too!

Thank you

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



signature.asc
Description: PGP signature
___
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 2021

[Michael Niedermayer]

On Tue, Feb 02, 2021 at 10:48:13AM +0100, Michael Niedermayer wrote:
> Hi all
> 
> Most people probably already know but just to be sure everyone knows
> GSoC 2021 is 175h not 350h
> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1
> 
> Some project ideas may need to be adjusted accordingly

So far FFmpegs gsoc 2021 Project Ideas page list is quite long, it has 0 ideas.
Please help changing that, otherwise FFmpeg might be rejected by google this 
year.

For reference:
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2021

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: PGP signature
___
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 2021

[Nicolas George]

Steven Liu (12021-02-02):
> And I saw Nicolas make some RFC maybe can split some subproject for mentor 
> project?

As Michael pointed, they are more about design than about coding, which
makes it less suited for this kind of mentor program. They require a
more in depth knowledge of parts of the project as a whole and/or
creative programming, which we cannot expect from an intern.

Another point to consider: we should put the proposed ideas on review,
to avoid letting pass one that is not suitable for FFmpeg for some
reason that the person who proposed missed. It is unfair to the student
if we realize in the middle of the project that it is actually not
wanted.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
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 2021

[Thilo Borgmann]

Hi,


> Most people probably already know but just to be sure everyone knows
> GSoC 2021 is 175h not 350h
> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1
> 
> Some project ideas may need to be adjusted accordingly

we've started registering as an Org and I put up the project ideas page for 
everyone to propose a project:

https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2021

We're still looking for mentors/projects, please feel free to propose a project 
(175 working hours in size this year)

Thanks,
Thilo
___
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 2021

[Thilo Borgmann]

Hi,

>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Michael Niedermayer
>> Sent: 2021年2月2日 17:48
>> To: FFmpeg development discussions and patches 
>> Subject: [FFmpeg-devel] GSoC 2021
>>
>> Hi all
>>
>> Most people probably already know but just to be sure everyone knows GSoC
>> 2021 is 175h not 350h
>> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ
>> ?pli=1
>>
>> Some project ideas may need to be adjusted accordingly
> 
> hi, for your information.
> 
> just like last year, to get more chances for GSoC project, I proposed my idea 
> at https://01.org/linuxmedia/news/gsoc-2021-ideas, and also copy here for 
> your convenience.
> 
> Async support for TensorFlow backend in FFmpeg
> Description: FFmpeg DNN (deep neural network) module is to enable deep 
> learning based FFmpeg filters with OpenVINO, TensorFlow and Native as its 
> backends. The OpenVINO backend has supported async+batch execution for model 
> inference with commit e67b5d and 64ea15 etc, it shows good performance gain. 
> This project focuses on the async support for TensorFlow backend which 
> invokes TensorFlow C library for model loading and inference. The main 
> difference between the two backends is that OpenVINO API has async execution 
> function while TensorFlow C API does not expose async function, so we need to 
> support async execution by multiple threads within TensorFlow backend with 
> sync function TF_SessionRun. (it is a plus if batch mode is also supported.)
> Difficulty: Medium
> Skill Required: C, multiple threads, DNN knowledge, git

Thanks, see my other mail to have it on the ideas page!

-Thilo
___
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 2021

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: 2021年2月2日 17:48
> To: FFmpeg development discussions and patches 
> Subject: [FFmpeg-devel] GSoC 2021
> 
> Hi all
> 
> Most people probably already know but just to be sure everyone knows GSoC
> 2021 is 175h not 350h
> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ
> ?pli=1
> 
> Some project ideas may need to be adjusted accordingly

hi, for your information.

just like last year, to get more chances for GSoC project, I proposed my idea 
at https://01.org/linuxmedia/news/gsoc-2021-ideas, and also copy here for your 
convenience.

Async support for TensorFlow backend in FFmpeg
Description: FFmpeg DNN (deep neural network) module is to enable deep learning 
based FFmpeg filters with OpenVINO, TensorFlow and Native as its backends. The 
OpenVINO backend has supported async+batch execution for model inference with 
commit e67b5d and 64ea15 etc, it shows good performance gain. This project 
focuses on the async support for TensorFlow backend which invokes TensorFlow C 
library for model loading and inference. The main difference between the two 
backends is that OpenVINO API has async execution function while TensorFlow C 
API does not expose async function, so we need to support async execution by 
multiple threads within TensorFlow backend with sync function TF_SessionRun. 
(it is a plus if batch mode is also supported.)
Difficulty: Medium
Skill Required: C, multiple threads, DNN knowledge, git
___
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 2021

[Michael Niedermayer]

On Tue, Feb 02, 2021 at 07:02:00PM +0800, Steven Liu wrote:
> 
> 
> > 2021年2月2日 下午5:48，Michael Niedermayer  写道：
> > 
> > Hi all
> > 
> > Most people probably already know but just to be sure everyone knows
> > GSoC 2021 is 175h not 350h
> > https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1
> > 
> > Some project ideas may need to be adjusted accordingly
> 
> What about make some small/mini/tiny feature for mentor project?

yes, smaller projects are needed for this year


> And I saw Nicolas make some RFC maybe can split some subproject for mentor 
> project?

Projects should be small, self contained and accessible for someone who has no
prior knowledge of our codebase.
In that sense (re)design projects are a bad idea unless theres a FFmpeg 
developer
who qualifies as a GSoC Student and thus has prior knowledge.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: PGP signature
___
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 2021

[Steven Liu]

> 2021年2月2日 下午5:48，Michael Niedermayer  写道：
> 
> Hi all
> 
> Most people probably already know but just to be sure everyone knows
> GSoC 2021 is 175h not 350h
> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1
> 
> Some project ideas may need to be adjusted accordingly

What about make some small/mini/tiny feature for mentor project?
And I saw Nicolas make some RFC maybe can split some subproject for mentor 
project?

> 
> Thanks
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> I have never wished to cater to the crowd; for what I know they do not
> approve, and what they approve I do not know. -- Epicurus
> ___
> 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".

Thanks

Steven Liu



___
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] GSoC 2021

[Michael Niedermayer]

Hi all

Most people probably already know but just to be sure everyone knows
GSoC 2021 is 175h not 350h
https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1

Some project ideas may need to be adjusted accordingly

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


signature.asc
Description: PGP signature
___
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] [ffmpeg-devel][GSoC][PATCH 1/2] libavfilter/vf_colorconstancy.c : Cleanup code for new filter

[Yatendra Singh]

Signed-off-by: Yatendra Singh 
---
 libavfilter/vf_colorconstancy.c | 46 ++---
 1 file changed, 13 insertions(+), 33 deletions(-)

diff --git a/libavfilter/vf_colorconstancy.c b/libavfilter/vf_colorconstancy.c
index eae62204b5..d974317a48 100644
--- a/libavfilter/vf_colorconstancy.c
+++ b/libavfilter/vf_colorconstancy.c
@@ -552,32 +552,6 @@ static void normalize_light(double *light)
 }
 }
 
-/**
- * Redirects to corresponding algorithm estimation function and performs 
normalization
- * after estimation.
- *
- * @param ctx the filter context.
- * @param in frame to perfrom estimation on.
- *
- * @return 0 in case of success, a negative value corresponding to an
- * AVERROR code in case of failure.
- */
-static int illumination_estimation(AVFilterContext *ctx, AVFrame *in)
-{
-ColorConstancyContext *s = ctx->priv;
-int ret;
-
-ret = filter_grey_edge(ctx, in);
-
-av_log(ctx, AV_LOG_DEBUG, "Estimated illumination= %f %f %f\n",
-   s->white[0], s->white[1], s->white[2]);
-normalize_light(s->white);
-av_log(ctx, AV_LOG_DEBUG, "Estimated illumination after normalization= %f 
%f %f\n",
-   s->white[0], s->white[1], s->white[2]);
-
-return ret;
-}
-
 /**
  * Performs simple correction via diagonal transformation model.
  *
@@ -682,12 +656,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 int ret;
 int direct = 0;
 
-ret = illumination_estimation(ctx, in);
-if (ret) {
-av_frame_free();
-return ret;
-}
-
 if (av_frame_is_writable(in)) {
 direct = 1;
 out = in;
@@ -699,7 +667,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 }
 av_frame_copy_props(out, in);
 }
-chromatic_adaptation(ctx, in, out);
+
+if (!strcmp(ctx->filter->name, GREY_EDGE)) {
+ColorConstancyContext *s = ctx->priv;
+ret = filter_grey_edge(ctx, in);
+
+normalize_light(s->white);
+
+if (ret) {
+av_frame_free();
+return ret;
+}
+chromatic_adaptation(ctx, in, out);
+}
 
 if (!direct)
 av_frame_free();
-- 
2.20.1

___
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] [ffmpeg-devel][GSoC][PATCH 2/2] libavfilter/vf_colorconstancy.c : Adding weighted greyedge

[Yatendra Singh]

Signed-off-by: Yatendra Singh 
---
 doc/filters.texi|  36 ++
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_colorconstancy.c | 220 
 4 files changed, 258 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 85a511b205..2946b5b9e6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20250,6 +20250,42 @@ 
separatefields,select=eq(mod(n,4),0)+eq(mod(n,4),3),weave
 @end example
 @end itemize
 
+@section weighted_greyedge
+Apply the color constancy filter which estimates illumination and updates the
+image colors accordingly.
+
+It accepts the following options:
+
+@table @option
+@item minknorm
+The Minkowski parameter to be used for calculating the Minkowski distance. Must
+be chosen in the range [0,20] and default value is 1. Set to 0 for getting
+max value instead of calculating Minkowski distance.
+
+@item sigma
+The standard deviation of Gaussian blur to be applied on the scene. Must be
+chosen in the range [0,1024.0] and default value = 1. floor( @var{sigma} * 
break_off_sigma(3) )
+can't be equal to 0 if @var{difford} is greater than 0.
+
+@item min_err
+The error angle between the estimated illumination and white light at which 
the algorithm stops even
+if it hasn't reached the required number of iterations @code{max_iters}. Must 
be chosen in the range
+[0.02,PI] radians with default of 0.1.
+
+@item max_iters
+The number of iterations at which the algorithm stops even if it hasn't 
reached the required
+error angle between the estimated illumination and white light @code{min_err}. 
Must be chosen in the
+range [1,100] with a default value of 10.
+
+@item kappa
+The power which is applied to the spectral weights to change the impact of 
weights on illuminant 
+estimation @code{kappa}. Must be chosen in the range [1,25] with a default 
value of 10.
+@end table
+
+@example
+ffmpeg -i mondrian.tif -vf 
"weighted_greyedge=minknorm=0:sigma=1:max_iters=50:min_err=0.02:kappa=10" 
mondrian_out.tif
+@end example
+
 @section xbr
 Apply the xBR high-quality magnification filter which is designed for pixel
 art. It follows a set of edge-detection rules, see
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 994a4172a3..6973452f8d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -453,6 +453,7 @@ OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o 
framesync.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
 OBJS-$(CONFIG_WEAVE_FILTER)  += vf_weave.o
+OBJS-$(CONFIG_WEIGHTED_GREYEDGE_FILTER)  += vf_colorconstancy.o
 OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
 OBJS-$(CONFIG_XFADE_FILTER)  += vf_xfade.o
 OBJS-$(CONFIG_XFADE_OPENCL_FILTER)   += vf_xfade_opencl.o opencl.o 
opencl/xfade.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f2a44b0090..ad2e07f9c5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -432,6 +432,7 @@ extern AVFilter ff_vf_vstack;
 extern AVFilter ff_vf_w3fdif;
 extern AVFilter ff_vf_waveform;
 extern AVFilter ff_vf_weave;
+extern AVFilter ff_vf_weighted_greyedge;
 extern AVFilter ff_vf_xbr;
 extern AVFilter ff_vf_xfade;
 extern AVFilter ff_vf_xfade_opencl;
diff --git a/libavfilter/vf_colorconstancy.c b/libavfilter/vf_colorconstancy.c
index d974317a48..cd9d992fdd 100644
--- a/libavfilter/vf_colorconstancy.c
+++ b/libavfilter/vf_colorconstancy.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2018 Mina Sami
+ * Copyright (c) 2020 Yatendra Singh
  *
  * This file is part of FFmpeg.
  *
@@ -26,6 +27,14 @@
  *
  * @cite
  * J. van de Weijer, Th. Gevers, A. Gijsenij "Edge-Based Color Constancy".
+ *
+ * @cite
+ * J. van de Weijer, Th. Gevers, and J. Geusebroek,
+ * “Edge and corner detection by photometric quasi-invariants”.
+ *
+ * @cite
+ * A. Gijsenij, Th. Gevers, J. van de Weijer,
+ * "Improving Color Constancy by Photometric Edge Weighting".
  */
 
 #include "libavutil/imgutils.h"
@@ -40,8 +49,10 @@
 #include 
 
 #define GREY_EDGE "greyedge"
+#define WEIGHTED_GREY_EDGE "weighted_greyedge"
 
 #define SQRT3 1.73205080757
+#define NORMAL_WHITE 1/SQRT3
 
 #define NUM_PLANES3
 #define MAX_DIFF_ORD  2
@@ -77,12 +88,16 @@ typedef struct ColorConstancyContext {
 
 int difford;
 int minknorm; /**< @minknorm = 0 : getMax instead */
+int kappa;
 double sigma;
 
 int nb_threads;
 int planeheight[4];
 int planewidth[4];
 
+double min_err;
+int max_iters;
+
 int filtersize;
 double *gauss[MAX_DIFF_ORD+1];
 
@@ -608,6 +623,170 @@ static void chromatic_adaptation(AVFilterContext *ctx, 
AVFrame *in, AVFrame *out
 ctx->internal->execute(ctx, diagonal_transformation, , NULL, nb_jobs);
 }
 
+/**
+ * Slice function for weighted grey edge algorithm that does partial 
summing/maximizing
+ * of gaussian derivatives and applies the pixel wise 

Re: [FFmpeg-devel] [GSoC] [WIP] [RFC] FLIF Encoder & Decoder Project

[Jai Luthra]

Hi Kartik,

On Mon, Mar 30, 2020, at 4:50 AM, Kartik K. Khullar wrote:
> This is my WIP patch for GSoC and I worked on transformations involved 
> in encoding/decoding FLIF images. I have created a module under 
> libavcodec and as guided by my mentors I have tried to use pixel data 
> from AVFrame structs.
> Module covers all the chunks of code for YCoCg Transformation that will 
> be used in final encoder/decoder. Necessary structs and methods have 
> been made as suggested by my mentors. The module compiles/builds 
> successfully.
> Also I have attached a small code 'transformtest.c' which I wrote for 
> testing the implementation of pixel transformation.
> The variable AVFrame::data[] is of type uint8_t* and I was initially 
> unaware of this so I stored the YCoCg values in 'data'. So the negative 
> values which were the output of transformation of RGB -> YCoCg were not 
> stored properly and thats where the output is wrong.

I tested your code, and it is good for an initial attempt (ofc the negative 
values are overflowing the uint8_t range, which is wrong). 

Your understanding of the problem is correct, when we transform an RGB value 
that could lie in (0-255, 0-255, 0-255) it can result in a YCoCg value that 
could be anywhere between (0-255, -255-255, -255-255) and thus not fit within 
AVFrame.data which is uint8_t *

> Just wanted to ask, if I should be using some other structs for storing 
> the YCoCg values and not AVFrame, because AVFrame seems to be the 
> standard struct in FFmpeg where the raw media resides.

The YCoCg doesn't need to go in AVFrame as your testcase (RGB->YCoCg) is the 
encoding phase, which reads RGB values from **AVFrame** and ultimately should 
output binary encoded data (after entropy coding) into **AVPacket**. Sorry if 
this was not clear before.

It is OK if you use a bigger buffer with 16-bits per color value for the 
intermediate transform stages. The only invariant is that original frame will 
have 8-bit RGB values, and final encoder output will be binary data. What the 
encoder uses in the interim to represent pixel values doesn't matter to FFmpeg 
api.

But theoretically you will never use all the 16x16x16 bits with YCoCg, as the 
Co range is conditional on Y, and Cg range conditional on Y & Co. It is 
*crucial* for your project that you thoroughly understand the "new ranges" 
section in the spec [1]

Unlike YCbCr (and other common transforms) which goes from 0-255 to 0-255 (or 
even shorter), YCoCg works differently. If we know that Y value is very low or 
very high, it means color components are roughly equal and thus Co and Cg will 
definitely be in a small range. This is what the animation [2] in the spec is 
about. The Y/Luminance varies from 0-255 and the working range of CoCg is shown 
as the size of the square.

I.e. the transform may take a Co value to -255-255 but that will not happen for 
every value of Y. It will only happen when `origmax4-1 <= Y <= 3*origmax4 - 1`. 
Similar rules apply for Cg.

So your next steps should be:
1. Use uint16_t to store interim pixel values for all transformations (doesn't 
need to be part of AVFrame, is internal structure to decoder)
2. Figure out how to implement the crange functions/api as this will be crucial 
for the MANIAC encoder phase (it needs to know the conditional ranges to 
effectively do entropy coding of the pixel values)

> Attaching some testcases of RGB and its corresponding YCoCg values for 
> testing purposes.
> 
> Thanks
> Kartik K. Khullar

Cheers,
Jai

[1]: https://flif.info/spec.html#_new_ranges
[2]: https://www.youtube.com/watch?v=-v-xoKZBnhI
___
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] [GSOC] FLIF16 Decoder (and Encoder)

[Anamitra Ghorui]

Hello,

I have a question regerding the internal decoding/encoding API. There seems
to be two functions that may be alternatively called, on the basis of whether
they are defined or not, both defined in the AVCodec struct:
1. decode()
2. receive_frame()

From the comments above the definition of receive_frame():
"Decode API with decoupled packet/frame dataflow. This function is called to get
one output frame. It should call ff_decode_get_packet() to obtain input data."

From what I can see, if receive_frame() is not defined, a separate function is
called, decode_simple_receive_frame(), which in turn calls 
decode_receive_frame_internal(). 
*   receive_frame() therefore allows more "fine grained" control on how the 
frame generation and return values are handled, from what I can see.
*   But for most purposes defining decode() is enough.
*   receive_frame() takes priority over decode().

Is this correct?

---

I have gone through theory regarding arithmetic coding and have been able to
build my own arithmetic encoder. Range coding seems to differ 
from an arithmetic coder in only two cases, which is the renormalisation and 
ending the encoding/decoding process. Here's what I have managed to gather:

* The general process of renormalisation in an arithcoder is [2]:
(Here, `n` is initially 0)
While range is too small: (range < Quarter of original)
|If range is in first half of original range ("Upper" condition)
|Output a 0, and `n` number of 1's
|Else If range is in second half of original range: ("Lower" condidtion)
|Output a 1, and `n` number of 0's
|Else If range straddles the middle: ("Straddle" condition)
|Increment `n` by 1
|
|Blow up the range by multiplying `range` and `low` by 2 
|(or shifting left by 1)

The range-low notation (instead of the supposedly conventional high-low 
notation) is used in most of the rangecoder algorithms/implementations I have
seen.

* Whereas, in the range coder implementation of [1], the following happens:
(here, `buffer` is 1 byte in size, and `low`, `range` are 4 bytes in size)
(All arithmetic is in unsigned integers)
Upper bound of the range is 1 << 31, and lower bound is (upper bound >> 8)
(0x8000 and 0x0080 respectively)

While range is too small: (range < lower bound)
|   If  `low` is less than 0x7F80 (0xFF << 23)
|   Output `buffer`, and `n` number of 0xFF's
|   Put MSByte of `low` into `buffer`
|   Else if MSBit of `low` is 1 (The "Carry" bit)
|   Output (`buffer` + 1) and `n` number of 0x0's
|   Put MSByte of `low` into `buffer`
|   Else
|   Increment `n` by 1
|   
|   Left Shift range by 8
|   Left Shift low by 8
|   Clear the carry bit of `low`

So we can make out the limits to be as:
"Lower" half: low < 0x7F80
"Upper" half: low >= 0x8000 (Counting in the previous condition)
"Straddle" condition: `low` is greater than or eq. to 0x7F80, and the
number's carry bit is 0, i.e., 0x7F80 <= `low` < 0x8000. There isn't a
definitive "point" for the straddling but a range, from what I can see.

Note that 0x7F80 + 0x0080 = 0x8000.

The renormalisation used in the RAC FLIF uses [3] is much more simpler than the 
one described above. So more or less easily implementable. However, the upper
and lower limits used in ffmpeg's rangecoder implementation cannot be changed 
and would need some rewriting. Consequently, we will have to rewrite/change 
the code in any codec that uses the functions.

I will also add in an explanation regarding the range coder in the FLIF
specification, which is not present, using whatever I have understood.

The rangecoder implementation used in ffmpeg uses a very small range (0xFF00).
I do not know the exact rationale behind it since I think it will require more
frequent renormalisation, but it may have someting to do with the codecs it was
implemented for, or the probability model.

For now, I will implement the RAC in a secondary file without altering 
rangecoder.c/rangecoder.h.

However, in the FLIF sourcecode, src/maniac/chance.cpp [4] uses an almost
exact copy of the function in rangecoder.c for building the probability model
(libavcodec/rangcoder.c, ff_build_rac_states). Therefore we can reuse that.
It might also be possible that the original author copy pasted it there with
some modifications.

Dealing with the second header shouldn't be much of a problem now.

An interesting thing is that the uniform symbol coder (see 
src/maniac/symbol.hpp) [5] is implemented recursively, which might mean that the
recursion was written in mind that a stack overflow will not occur.

---

As for the pixel transformations, it will mostly consist of translating the
existing reference implementation into the ffmpeg API/C. About the same goes for
the MANIAC encoding.

---

In conclusion, I believe writing the decoder will involve a lot of "copying and
pasting" (or closely following) the FLIF reference implementation, which I 
really
don't want to 

Re: [FFmpeg-devel] [GSOC] FLIF16 Decoder (and Encoder)

[James Almer]

On 5/4/2020 3:26 PM, Anamitra Ghorui wrote:
> Hello,
> 
> I have a question regerding the internal decoding/encoding API. There seems
> to be two functions that may be alternatively called, on the basis of whether
> they are defined or not, both defined in the AVCodec struct:
> 1. decode()
> 2. receive_frame()
> 
> From the comments above the definition of receive_frame():
> "Decode API with decoupled packet/frame dataflow. This function is called to 
> get
> one output frame. It should call ff_decode_get_packet() to obtain input data."
> 
> From what I can see, if receive_frame() is not defined, a separate function is
> called, decode_simple_receive_frame(), which in turn calls 
> decode_receive_frame_internal(). 
> *   receive_frame() therefore allows more "fine grained" control on how the 
> frame generation and return values are handled, from what I can see.
> *   But for most purposes defining decode() is enough.
> *   receive_frame() takes priority over decode().
> 
> Is this correct?

Yes. For a simple decoder, using AVCodec.decode() is enough. It is also
currently required if you want to implement frame threading.

Calls to AVCodec.decode() will always include a new packet to process,
even if you don't currently need one because you for example have more
frames to output with the data you already processed, whereas calls to
AVCodec.receive_frame() let you requests packets when you need them
using ff_decode_get_packet().
___
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] [GSoC] [WIP] [RFC] FLIF Encoder & Decoder Project

[Kartik K. Khullar]

This is my WIP patch for GSoC and I worked on transformations involved in
encoding/decoding FLIF images. I have created a module under libavcodec and
as guided by my mentors I have tried to use pixel data from AVFrame structs.
Module covers all the chunks of code for YCoCg Transformation that will be
used in final encoder/decoder. Necessary structs and methods have been made
as suggested by my mentors. The module compiles/builds successfully.
Also I have attached a small code 'transformtest.c' which I wrote for
testing the implementation of pixel transformation.
The variable AVFrame::data[] is of type uint8_t* and I was initially
unaware of this so I stored the YCoCg values in 'data'. So the negative
values which were the output of transformation of RGB -> YCoCg were not
stored properly and thats where the output is wrong.
Just wanted to ask, if I should be using some other structs for storing the
YCoCg values and not AVFrame, because AVFrame seems to be the standard
struct in FFmpeg where the raw media resides.
Attaching some testcases of RGB and its corresponding YCoCg values for
testing purposes.

Thanks
Kartik K. Khullar
#include "transformflif16.h"

int process(Transform transform, AVFrame *frame, int p){
switch(transform.transform_number){
case 1: //Transform number for YCoCg transformation is 1 officially.
if(!transform.done){
			TransformYCoCg transformYCoCg = initYCoCg(frame, p);
if(!processYCoCg(frame))
	transform.done = 1;
return 0;
}
		break;

/*
Rest of the cases will be implemented here.
*/

default:
break;
}
return 0;
}

TransformYCoCg initYCoCg(AVFrame *frame, int p){
	TransformYCoCg transform;
	transform.num_planes = p;
	transform.ranges = getRanges(transform.num_planes, frame);
transform.origmax4 = max(transform.ranges[0].max, transform.ranges[1].max, transform.ranges[2].max)/4 -1;
for(p=0; pdata[0][r*width + c];
G = frame->data[1][r*width + c];
B = frame->data[2][r*width + c];

Y = (((R + B)>>1) + G)>>1;
Co = R - B;
Cg = G - ((R + B)>>1);

frame->data[0][r*width + c] = Y;
frame->data[1][r*width + c] = Co;
frame->data[2][r*width + c] = Cg;
}
}
	return 0;
}

int invProcessYCoCg(AVFrame *frame){
	int r, c;
ColorVal R,G,B,Y,Co,Cg;

//Assuming all the channels will have same width and height
	int height = frame[0].height;
int width = frame[0].width;

	for (r=0; rdata[0][r*width + c];
Co= frame->data[1][r*width + c];
Cg= frame->data[2][r*width + c];

R = Co + Y + ((1-Cg)>>1) - (Co>>1);
G = Y - ((-Cg)>>1);
B = Y + ((1-Cg)>>1) - (Co>>1);

frame->data[0][r*width + c] = R;
frame->data[1][r*width + c] = G;
frame->data[2][r*width + c] = B;
}
}
	return 0;
}

ColorRanges* getRanges(int p, AVFrame *frame){
ColorRanges ranges[p];
int i, c, r, width, height;
uint8_t min, max;

for(i=0; idata[p][0];
max = frame->data[p][0];
for(r=0; r frame->data[p][r*width + c])
min = frame->data[p][r*width + c];
if(max < frame->data[p][r*width + c])
max = frame->data[p][r*width + c];
}
}
ranges[p].min = min;
ranges[p].max = max;
}
return ranges;
}

int max(int a, int b, int c){
	if(a > b){
		if(a > c)
			return a;
		else
			return c;
	}
	else
		return b;
}

int min(int a, int b){
	if(a < b)
		return a;
	else
		return b;
}

int get_min_y(int origmax4){
	return 0;
}

int get_max_y(int origmax4){
	return 4*origmax4-1;
}

int get_min_co(int origmax4, int yval){
	int newmax = 4*origmax4 - 1;
	if (yval < origmax4-1)
	return -3 - 4*yval; 
	else if (yval >= 3*origmax4)
  	return 4*(yval - newmax);
else
  	return -newmax;
}

int get_max_co(int origmax4, int yval){
	int newmax = 4*origmax4 - 1;
	if (yval < origmax4-1)
	return 3 + 4*yval; 
	else if (yval >= 3*origmax4)
  	return 4*(newmax - yval);
else
  	return newmax;
}

int get_min_cg(int origmax4, int yval, int coval){
	int newmax = 4*origmax4 - 1;
	if (yval < origmax4-1)
	return -2 - 2*yval; 
	else if (yval >= 3*origmax4)
  	return -2*(newmax-yval) + 2*((abs(coval)+1)/2);
else{
  	return min(2*yval + 1, 2*newmax - 2*yval - 2*abs(coval)+1)/2;
	}
}

int get_max_cg(int origmax4, int yval, int coval){
	int newmax = 4*origmax4 - 1;
	if (yval < origmax4-1)
	return 1 + 2*yval - 2*(abs(coval)/2); 
	else if (yval >= 3*origmax4)
  	return 2 * (newmax-yval);
else
  	return min(2*(yval- newmax), -2*yval - 1 + 2*(abs(coval)/2));
}

int min_range_YCoCg(int p, int origmax4){
	switch(p){
		case 0:
			return 0;
case 1:
			return -4*origmax4+1;
case 2:
			return -4*origmax4+1;
		default:
			return 0;
			break;
	}
}

int 

[FFmpeg-devel] GSoC 2020:Audio tones source filter

[apk120]

Audio tones source filter to generate random audio tones using fluidsynth

diff --git a/Makefile b/Makefile
index 45a22b0cb3..44cf1b5710 100644
--- a/Makefile
+++ b/Makefile
@@ -111,7 +111,7 @@ else
 endif
 
 %$(PROGSSUF)_g$(EXESUF): $(FF_DEP_LIBS)
-   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS)
+   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS) 
-lfluidsynth
 
 VERSION_SH  = $(SRC_PATH)/ffbuild/version.sh
 GIT_LOG = $(SRC_PATH)/.git/logs/HEAD
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 750412da6b..b1f0c4be35 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -151,6 +151,7 @@ OBJS-$(CONFIG_FLITE_FILTER)  += asrc_flite.o
 OBJS-$(CONFIG_HILBERT_FILTER)+= asrc_hilbert.o
 OBJS-$(CONFIG_SINC_FILTER)   += asrc_sinc.o
 OBJS-$(CONFIG_SINE_FILTER)   += asrc_sine.o
+OBJS-$(CONFIG_ATONE_FILTER)  += asrc_atone.o
 
 OBJS-$(CONFIG_ANULLSINK_FILTER)  += asink_anullsink.o
 
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 501e5d041b..4d3efc7e15 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -145,6 +145,7 @@ extern AVFilter ff_asrc_flite;
 extern AVFilter ff_asrc_hilbert;
 extern AVFilter ff_asrc_sinc;
 extern AVFilter ff_asrc_sine;
+extern AVFilter ff_asrc_atone;
 
 extern AVFilter ff_asink_anullsink;
 
diff --git a/libavfilter/asrc_atone.c b/libavfilter/asrc_atone.c
new file mode 100644
index 00..e3703f5e4b
--- /dev/null
+++ b/libavfilter/asrc_atone.c
@@ -0,0 +1,244 @@
+/*
+ * 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
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/eval.h"
+#include "libavutil/opt.h"
+#include "libavutil/lfg.h"
+#include "libavutil/random_seed.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "internal.h"
+
+typedef struct AtoneContext
+{
+const AVClass* class;
+int64_t duration;
+int nb_samples;
+int sample_rate;
+int64_t pts;
+int infinite;
+
+fluid_settings_t* settings;
+fluid_synth_t* synth;
+char* sfont;///< soundfont file
+int sfont_id;
+int midi_chan; ///< midi channel number
+int velocity;  ///< velocity of key
+int changerate;///< get the frequency of changing tones
+float* left;   ///< store the left buffer
+float* right;  ///< store the right buffer
+AVLFG key;  
+}AtoneContext;
+
+#define CONTEXT AtoneContext
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+#define OPT_GENERIC(name, field, def, min, max, descr, type, deffield, ...) \
+{ name, descr, offsetof(CONTEXT, field), AV_OPT_TYPE_ ## type,  \
+  { .deffield = def }, min, max, FLAGS, __VA_ARGS__ }
+
+#define OPT_INT(name, field, def, min, max, descr, ...) \
+OPT_GENERIC(name, field, def, min, max, descr, INT, i64, __VA_ARGS__)
+
+#define OPT_DUR(name, field, def, min, max, descr, ...) \
+OPT_GENERIC(name, field, def, min, max, descr, DURATION, str, __VA_ARGS__)
+
+#define OPT_STR(name, field, def, min, max, descr, ...) \
+OPT_GENERIC(name, field, def, min, max, descr, STRING, str, __VA_ARGS__)
+
+static const AVOption atone_options[] = {
+OPT_INT("velocity",  velocity,   80,   
   0, INT_MAX, "set the velocity of key press",),
+OPT_INT("v", velocity,   80,   
   0, INT_MAX, "set the velocity of key press",),
+OPT_INT("sample_rate",   sample_rate,44100,
   1, INT_MAX, "set the sample rate",),
+OPT_INT("r", sample_rate,44100,
   1, INT_MAX, "set the sample rate",),
+OPT_DUR("duration",  duration,   0,
   0, INT64_MAX,   "set the audio duration",),
+OPT_DUR("d", duration,   0,
 

Re: [FFmpeg-devel] GSoC: Regarding Parsing and FLIF16 Frame Encoding

[Jai Luthra]

Hi Anamitra,

On Sat, Feb 29, 2020 at 04:50:23AM +, Anamitra Ghorui wrote:

Hello,
I have been reading through the parsing API and other things and here's what
I've managed to gather (I will be ignoring overruns in these functions for now).
Please tell me if I am right or wrong:

1. As long as the parse function determines next == END_NOT_FOUND,
  ff_combine_frame will keep increasing the AVParseContext index by buf_size.
  Once next is no longer END_NOT_FOUND, buf_size will be set to index + next.

  The bytes from the input chunks are copied into the buffer of AVParseContext
  during this process.

  while next == END_NOT_FOUND, and the thing being decoded is a video, we
  cannot really determine the end of frame, and hence poutbuf and poutbuf_size
  are set to zero by the function. However, this doesn't really matter for
  still images since they have a single frame.

2. av_parser_parse2 will look for whether poutbuf_size is greater than zero.
  If it is, the next frame start offset will be advanced, and the frame offset
  pointer will be set to the previous value of the next frame offset in
  AVCodecParserContext.

3. In https://ffmpeg.org/doxygen/trunk/decode_video_8c-example.html
  pkt->size will be set to zero as long as a frame has not been returned.
  Hence decode will not be triggered as long as a frame has not been found.


Yes this is all correct. Good work of looking at different parsers to 
understand this.




Now, Regarding FLIF16:
1. The pixels of the image are stored in this format (non interlaced):
(see https://flif.info/spec.html#_part_4_pixel_data)
 ___
| _ |
|| ___ ||
all  ||| _ |||
|||| 
||| f1 | x1 x2 x3 . xw   
|||| 
|| y1 ||_
| c1 ||...|||
||| _ |||
|||| 
||| fn | x1 x2 x3 . xw   
|||| 
||||_
|||   |||
|||___|||
|| ... ||
|| ___ ||
||| _ |||
|||| 
||| f1 | x1 x2 x3 . xw   
|||| 
|| yh ||_
|||   ... |||
||| _ |||
|||| 
||| fn | x1 x2 x3 . xw   
|||| 
||||_
|||   |||
|||___|||
||_||
|   |
|  ...  |
| cn|
|___|

where: ci: color channel
  yi: pixel row
  fi: frame number
  xi: individual pixel


Ah FLIF is a bit wacky. I can see why this might be helpful for decoding 
partial images on-the-fly, but I don't think it will be easy or even possible 
to do with the current AVFrame API.




The frames are not stored in a contiguous manner as observable. How should I be
getting the frame over here? It dosen't seem possible without either putting the
whole pixel data chunk in memory, or allocating space for all the frames at once
and then putting data in them.

I guess what the parser has to do in that case is that it will have to either
return the whole file length as the buffer to the decoder function, or make the
parser manage frames by itself through its own data structures and component
functions.

What should I be doing here?


For now go with the approach of reading all the data into a single AVPacket. 
This does mean that parser isn't splitting frames. We can figure out how to do 
progressive decoding like intended by FLIF later.




2. The FLIF format spec refers to a thing known as the 24 bit RAC. Is it an
  abbreviation for 24 bit RAnge Coding? 
(https://en.wikipedia.org/wiki/Range_encoding)
  What does the "24 bit" mean? Is it the size of each symbol that is processed
  by the range coder?



Yes RAC refers to Range Coding [1]. You can try to match what the reference 
codec does in [2] with the explanation in [1].


"24 

Re: [FFmpeg-devel] GSoC: Regarding Parsing and FLIF16 Frame Encoding

[Kartik K. Khullar]

It is just to remind that I am already working on Transformations involved
in FLIF and the functions which these transformations use like Symbol
Encoding @Anamitra. It would be helpful if someone could help me clear what
does RAC refer to in FLIF spec. It is mentioned under Symbol Encoding and
is being used repetitively.
Thanks

On Sat, Feb 29, 2020 at 4:52 PM Anamitra Ghorui  wrote:

> Oh, sorry about that.
>
> ___
> 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 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: Regarding Parsing and FLIF16 Frame Encoding

[Anamitra Ghorui]

Oh, sorry about that.

___
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] GSoC: Regarding Parsing and FLIF16 Frame Encoding

[Anamitra Ghorui]

Hello,
I have been reading through the parsing API and other things and here's what 
I've managed to gather (I will be ignoring overruns in these functions for now).
Please tell me if I am right or wrong:

1. As long as the parse function determines next == END_NOT_FOUND, 
   ff_combine_frame will keep increasing the AVParseContext index by buf_size.
   Once next is no longer END_NOT_FOUND, buf_size will be set to index + next.
   
   The bytes from the input chunks are copied into the buffer of AVParseContext
   during this process.
   
   while next == END_NOT_FOUND, and the thing being decoded is a video, we 
   cannot really determine the end of frame, and hence poutbuf and poutbuf_size
   are set to zero by the function. However, this doesn't really matter for
   still images since they have a single frame.

2. av_parser_parse2 will look for whether poutbuf_size is greater than zero.
   If it is, the next frame start offset will be advanced, and the frame offset
   pointer will be set to the previous value of the next frame offset in
   AVCodecParserContext.

3. In https://ffmpeg.org/doxygen/trunk/decode_video_8c-example.html
   pkt->size will be set to zero as long as a frame has not been returned.
   Hence decode will not be triggered as long as a frame has not been found.

Now, Regarding FLIF16:
1. The pixels of the image are stored in this format (non interlaced):
(see https://flif.info/spec.html#_part_4_pixel_data)
  ___
 | _ |
 || ___ ||
all  ||| _ |||
 |||| 
 ||| f1 | x1 x2 x3 . xw   
 |||| 
 || y1 ||_
 | c1 ||...|||
 ||| _ |||
 |||| 
 ||| fn | x1 x2 x3 . xw   
 |||| 
 ||||_
 |||   |||
 |||___|||
 || ... ||
 || ___ ||
 ||| _ |||
 |||| 
 ||| f1 | x1 x2 x3 . xw   
 |||| 
 || yh ||_
 |||   ... |||
 ||| _ |||
 |||| 
 ||| fn | x1 x2 x3 . xw   
 |||| 
 ||||_
 |||   |||
 |||___|||
 ||_||
 |   |
 |  ...  |
 | cn|
 |___|

where: ci: color channel
   yi: pixel row
   fi: frame number
   xi: individual pixel

The frames are not stored in a contiguous manner as observable. How should I be 
getting the frame over here? It dosen't seem possible without either putting the
whole pixel data chunk in memory, or allocating space for all the frames at once
and then putting data in them.

I guess what the parser has to do in that case is that it will have to either
return the whole file length as the buffer to the decoder function, or make the
parser manage frames by itself through its own data structures and component
functions.

What should I be doing here?

2. The FLIF format spec refers to a thing known as the 24 bit RAC. Is it an
   abbreviation for 24 bit RAnge Coding? 
(https://en.wikipedia.org/wiki/Range_encoding)
   What does the "24 bit" mean? Is it the size of each symbol that is processed
   by the range coder?

I started going through the reference implementation of FLIF. I'll see what I
can make out of it. The decoder by itself under the Apache lisence so we could
refer to it or borrow some things from it: https://github.com/FLIF-hub/FLIF.

Thanks

___
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 2020

[Thilo Borgmann]

Hi,

>>> please help fill the 2020 GSoC Ideas page
>>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
>>>
>>> (This page is key to being acccepted to GSoC)
>>
>> I guess everybody already noticed that FFmpeg had been accepted as a
>> mentoring Org in GSoC 2020! :D
> 
> Hi,
> 
> Just to save the chance for FFmpeg, I proposed one idea under
> 'Intel® Video and Audio for Linux' to tune performance of native layer conv2d,
> see https://01.org/linuxmedia/gsoc/gsoc-2020-ideas for detail.
> 
> I'll continue if no one objects. 

that's a good thing and thanks for letting us know!

-Thilo
___
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 Project: ABR for FFmpeg.

[Steven Liu]

> 2020年2月24日 下午10:09，tianchi huang  写道：
> 
> Hi,
> 
> I am interested in taking up a project with FFmpeg for GSOC’20. Specifically, 
> I found that the proposal called ‘ABR meets FFmpeg’ is extremely fit for me, 
> since:
> 
> i) I am proficient in c, c++, js, etc.  Especially, I really enjoy submitting 
> my work to and contributing to the open-source community. For instance, I 
> have submitted a work called ‘kurento-rtmp’, a module that can transcode the 
> WebRTC stream to the RTMP stream, to the Github. Till now, it has already 
> achieved 110 stars. (https://github.com/godka/kurento-rtmp). Meanwhile, I 
> have also contributed some work about ABR video streaming. For example, a 
> classical ABR method MPC (model predictive control) written in c++ 
> (https://github.com/thu-media/Comyco/blob/master/cpp-linux/mpc.cpp).
> 
> ii) I am in that area. Currently, I am a Ph.D. student in the Department of 
> Computer Science and Technology at Tsinghua University, advised by Prof. 
> Lifeng Sun.  My research work focuses on multimedia network streaming. In 
> recent years I have published several adaptive video streaming papers in the 
> *top conference*, including SIGCOMM, INFOCOM,  ACM Multimedia, etc. The full 
> publication list is shown in https://godka.github.io.
> 
> I have a plan for this work:
> Taking HLS (HTTP Live Streaming) as an example, I need to change most of the 
> code in `hls.c'. The previous algorithm fails to support ABR algorithms since 
> it directly implements adding_stream_to_programs after reading the playlist. 
> At the same time, the live streaming part is also relatively simple, setting 
> the clock directly as an infinite loop. To that end, the key idea is to 
> rewrite this part and add the concept of buffer occupancy, which is an 
> essential part of ABR algorithms. 
> Moreover, I also attempt to create a new module ‘abr.c’, which can support 
> various of ABR algorithms, such as MPC, HYB, BBA, and especially Pensieve and 
> Comyco (such state-of-the-art methods leverage *Neural Network* to make the 
> decision).
> 
> In general, can you please provide a chance to me for attending GSOC’20?
Sure,  welcome contribute to ffmpeg.
Reference the documents:
http://ffmpeg.org/documentation.html

Thanks

Steven

___
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] GSoc Project: ABR for FFmpeg.

[tianchi huang]

Hi,

I am interested in taking up a project with FFmpeg for GSOC’20. Specifically, I 
found that the proposal called ‘ABR meets FFmpeg’ is extremely fit for me, 
since:

i) I am proficient in c, c++, js, etc.  Especially, I really enjoy submitting 
my work to and contributing to the open-source community. For instance, I have 
submitted a work called ‘kurento-rtmp’, a module that can transcode the WebRTC 
stream to the RTMP stream, to the Github. Till now, it has already achieved 110 
stars. (https://github.com/godka/kurento-rtmp). Meanwhile, I have also 
contributed some work about ABR video streaming. For example, a classical ABR 
method MPC (model predictive control) written in c++ 
(https://github.com/thu-media/Comyco/blob/master/cpp-linux/mpc.cpp).

ii) I am in that area. Currently, I am a Ph.D. student in the Department of 
Computer Science and Technology at Tsinghua University, advised by Prof. Lifeng 
Sun.  My research work focuses on multimedia network streaming. In recent years 
I have published several adaptive video streaming papers in the *top 
conference*, including SIGCOMM, INFOCOM,  ACM Multimedia, etc. The full 
publication list is shown in https://godka.github.io.

I have a plan for this work:
Taking HLS (HTTP Live Streaming) as an example, I need to change most of the 
code in `hls.c'. The previous algorithm fails to support ABR algorithms since 
it directly implements adding_stream_to_programs after reading the playlist. At 
the same time, the live streaming part is also relatively simple, setting the 
clock directly as an infinite loop. To that end, the key idea is to rewrite 
this part and add the concept of buffer occupancy, which is an essential part 
of ABR algorithms. 
Moreover, I also attempt to create a new module ‘abr.c’, which can support 
various of ABR algorithms, such as MPC, HYB, BBA, and especially Pensieve and 
Comyco (such state-of-the-art methods leverage *Neural Network* to make the 
decision).

In general, can you please provide a chance to me for attending GSOC’20?

Best,
Tianchi Huang.
___
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 2020

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Thilo Borgmann
> Sent: Saturday, February 22, 2020 5:50 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] GSoC 2020
> 
> Hi,
> 
> > please help fill the 2020 GSoC Ideas page
> > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
> >
> > (This page is key to being acccepted to GSoC)
> 
> I guess everybody already noticed that FFmpeg had been accepted as a
> mentoring Org in GSoC 2020! :D

Hi,

Just to save the chance for FFmpeg, I proposed one idea under
'Intel® Video and Audio for Linux' to tune performance of native layer conv2d,
see https://01.org/linuxmedia/gsoc/gsoc-2020-ideas for detail.

I'll continue if no one objects. 

> 
> Thanks to all potential mentors!
> 
> -Thilo
> ___
> 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 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 2020

[Pedro Arthur]

Em sáb., 22 de fev. de 2020 às 06:43, Thilo Borgmann
 escreveu:
>
> Hi,
>
> >>> please help fill the 2020 GSoC Ideas page
> >>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
> >>
> >> It seems the 2020 results page [1] contains results from 2019.
> >>
> >> [1] - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results
> >
> > you mean the sample project ?
> > feel free to edit it to look nicer otherwise ill wait for thilo, who added
> > this to reply
>
> yes, it is just one of the results from 2019 kept as a template for this year.
> Can't see a nice option to look more obviously not to be a real finished 
> project (except for making it invisible). Feel free to make it more clear if 
> you wish for it.
>
I've updated it and include a link to last year result page, thanks!

> -Thilo
> ___
> 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 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 2020

[Thilo Borgmann]

Hi,

> please help fill the 2020 GSoC Ideas page
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
> 
> (This page is key to being acccepted to GSoC)

I guess everybody already noticed that FFmpeg had been accepted as a mentoring 
Org in GSoC 2020! :D

Thanks to all potential mentors!

-Thilo
___
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 2020

[Thilo Borgmann]

Hi,

>>> please help fill the 2020 GSoC Ideas page
>>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
>>
>> It seems the 2020 results page [1] contains results from 2019.
>>
>> [1] - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results
> 
> you mean the sample project ?
> feel free to edit it to look nicer otherwise ill wait for thilo, who added
> this to reply

yes, it is just one of the results from 2019 kept as a template for this year.
Can't see a nice option to look more obviously not to be a real finished 
project (except for making it invisible). Feel free to make it more clear if 
you wish for it.

-Thilo
___
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] GSOC Project 2020

[ibrahim anis]

Hello,
I am Ibrahim Anis CSE final year undergraduate student pursuing B.Tech from
Govt. College Ujjain.I am looking forward to participating GSOC 2020 and
contribute to ffmpeg community.
I am interested in working on the project 'Improvig color constancy video
filter'.I have knowledge of c programming language and I have worked on
machine learning.I think this suites me to work on this project.
I am a newbie here,so I don't know how should I start.I will really
appreciate it if you could guide me.
Regards,
Ibrahim anis
___
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 2020

[Michael Niedermayer]

On Fri, Feb 21, 2020 at 04:41:35PM -0300, Pedro Arthur wrote:
> Hi,
> 
> Em qui., 6 de fev. de 2020 às 19:59, Michael Niedermayer
>  escreveu:
> >
> > Hi all
> >
> > please help fill the 2020 GSoC Ideas page
> > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
> 
> It seems the 2020 results page [1] contains results from 2019.
> 
> [1] - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results

you mean the sample project ?
feel free to edit it to look nicer otherwise ill wait for thilo, who added
this to reply

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


signature.asc
Description: PGP signature
___
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 2020

[Pedro Arthur]

Hi,

Em qui., 6 de fev. de 2020 às 19:59, Michael Niedermayer
 escreveu:
>
> Hi all
>
> please help fill the 2020 GSoC Ideas page
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020

It seems the 2020 results page [1] contains results from 2019.

[1] - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results

>
> (This page is key to being acccepted to GSoC)
>
> Thank you
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> When the tyrant has disposed of foreign enemies by conquest or treaty, and
> there is nothing more to fear from them, then he is always stirring up
> some war or other, in order that the people may require a leader. -- Plato
> ___
> 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 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 2020

[Michael Niedermayer]

On Fri, Feb 07, 2020 at 10:55:07AM +0100, Thilo Borgmann wrote:
> Am 06.02.20 um 23:59 schrieb Michael Niedermayer:
> > Hi all
> > 
> > please help fill the 2020 GSoC Ideas page
> > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
> > 
> > (This page is key to being acccepted to GSoC)
> 
> please come up with ideas that you find useful and possible to do, even if 
> you don't plan to mentor them.

Also we need backup mentors, please help fill the backup mentor spots

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: PGP signature
___
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 2020

[Thilo Borgmann]

Am 06.02.20 um 23:59 schrieb Michael Niedermayer:
> Hi all
> 
> please help fill the 2020 GSoC Ideas page
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
> 
> (This page is key to being acccepted to GSoC)

please come up with ideas that you find useful and possible to do, even if you 
don't plan to mentor them.

Thanks,
Thilo
___
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] GSoC 2020

[Michael Niedermayer]

Hi all

please help fill the 2020 GSoC Ideas page
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020

(This page is key to being acccepted to GSoC)

Thank you

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


signature.asc
Description: PGP signature
___
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] [GSOC] [PATCH v2] avfilter: add panorama filter

[Eugene Lyapustin]

Add filter for conversion between various panorama formats.
Supported formats: equirectangular, cubemap 3x2, cubemap 6x1

Contributions:

doc/filters: add panorama filter description
unify remap calculation procedure
add option for interpolation method

Signed-off-by: Eugene Lyapustin 

---

use bilinear from cubemap to equirectangular
Change cube faces order to match Youtube's
avfilter: add convertion to/from cubemap 6x1

Signed-off-by: Hazem Ashmawy 

---

avfilter: add panorama filter

Signed-off-by: Paul B Mahol 

Signed-off-by: Eugene Lyapustin 
---
 doc/filters.texi  |  50 +++
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_panorama.c | 647 ++
 4 files changed, 699 insertions(+)
 create mode 100644 libavfilter/vf_panorama.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 867607d870..2e9bf81e12 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13382,6 +13382,56 @@ ffmpeg -i input.mkv -i palette.png -lavfi paletteuse 
output.gif
 @end example
 @end itemize
 
+@section panorama
+
+Convert panorama videos between various formats.
+
+The filter accepts the following options:
+
+@table @option
+@item input
+Set format of input video.
+@item output
+Set format of output video.
+
+Available formats:
+
+@table @samp
+@item e
+Equirectangular projection.
+@item c6x1
+Cubemap with 6x1 layout.
+@item c3x2
+Cubemap with 3x2 layout.
+
+@end table
+
+@item interp
+Set interpolation method.
+
+Available methods:
+
+@table @samp
+@item near
+Nearest neighbour
+@item line
+Bilinear interpolation
+@end table
+
+Default value is @samp{line}.
+
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Convert equirectangular video to cubemap with 3x2 layout using bilinear 
interpolation:
+@example
+ffmpeg -i input.mkv -vf panorama=e:c3x2:line output.mkv
+@end example
+@end itemize
+
 @section perspective
 
 Correct perspective of video not recorded perpendicular to the screen.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fef6ec5c55..3c272da7b2 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -307,6 +307,7 @@ OBJS-$(CONFIG_OWDENOISE_FILTER)  += 
vf_owdenoise.o
 OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
 OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
 OBJS-$(CONFIG_PALETTEUSE_FILTER) += vf_paletteuse.o framesync.o
+OBJS-$(CONFIG_PANORAMA_FILTER)   += vf_panorama.o
 OBJS-$(CONFIG_PERMS_FILTER)  += f_perms.o
 OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
 OBJS-$(CONFIG_PHASE_FILTER)  += vf_phase.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c51ae0f3c7..f49c0a40e0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -292,6 +292,7 @@ extern AVFilter ff_vf_owdenoise;
 extern AVFilter ff_vf_pad;
 extern AVFilter ff_vf_palettegen;
 extern AVFilter ff_vf_paletteuse;
+extern AVFilter ff_vf_panorama;
 extern AVFilter ff_vf_perms;
 extern AVFilter ff_vf_perspective;
 extern AVFilter ff_vf_phase;
diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
new file mode 100644
index 00..8fa0310349
--- /dev/null
+++ b/libavfilter/vf_panorama.c
@@ -0,0 +1,647 @@
+/*
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum Projections {
+EQUIRECTANGULAR,
+CUBEMAP_6_1,
+CUBEMAP_3_2,
+NB_PROJECTIONS,
+};
+
+enum InterpMethod {
+  NEAREST,
+  BILINEAR,
+  NB_INTERP_METHODS,
+};
+
+enum Faces {
+RIGHT,
+LEFT,
+TOP,
+DOWN,
+FRONT,
+BACK,
+};
+
+struct XYRemap {
+int vi, ui;
+int v2, u2;
+double a, b, c, d;
+};
+
+typedef struct PanoramaContext {
+const AVClass *class;
+int in, out;
+int interp;
+
+int planewidth[4], planeheight[4];
+int inplanewidth[4], inplaneheight[4];
+int nb_planes;
+
+struct XYRemap *remap[4];
+
+int (*panorama)(struct PanoramaContext 

Re: [FFmpeg-devel] [GSOC] [PATCH] avfilter: add panorama filter

[Eugene Lyapustin]

On 13.04.2019 19:30, Moritz Barsnick wrote:


On Sat, Apr 13, 2019 at 15:50:14 +0300, Eugene Lyapustin wrote:

+static inline int equal(double a, double b, double epsilon)
+{
+return fabs(a - b) < epsilon;
+}
+
+static inline int smaller(double a, double b, double epsilon)
+{
+return ((a - b) < 0.0) && (!equal(a, b, epsilon));
+}

If something comparable doesn't already exist, these could become
macros similar to FF_MAX/MIX et.al.


These functions are local, so that change should not make much 
difference. Correct me if I'm wrong :)


Thanks for comments,
Eugene Lyapustin

___
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] [PATCH] avfilter: add panorama filter

[Moritz Barsnick]

On Sat, Apr 13, 2019 at 15:50:14 +0300, Eugene Lyapustin wrote:
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_panorama.c | 637 ++

The documentation in doc/filters.texi also needs to be amended.

> +static const AVOption panorama_options[] = {
> +{"input", "set input projection", OFFSET(in), 
> AV_OPT_TYPE_INT,   {.i64=EQUIRECTANGULAR}, 0,NB_PROJECTIONS-1, FLAGS, 
> "in" },
> +{"e", "equirectangular",   0, 
> AV_OPT_TYPE_CONST, {.i64=EQUIRECTANGULAR}, 0,   0, FLAGS, 
> "in" },
> +{ "c6x1", "cubemap",   0, 
> AV_OPT_TYPE_CONST, {.i64=CUBEMAP_6_1}, 0,   0, FLAGS, 
> "in" },
> +{ "c3x2", "cubemap",   0, 
> AV_OPT_TYPE_CONST, {.i64=CUBEMAP_3_2}, 0,   0, FLAGS, 
> "in" },

These two options should get differing descriptions.
(BTW, though others may hate it, I find this formatting very well
readable!)

> +static inline int equal(double a, double b, double epsilon)
> +{
> +return fabs(a - b) < epsilon;
> +}
> +
> +static inline int smaller(double a, double b, double epsilon)
> +{
> +return ((a - b) < 0.0) && (!equal(a, b, epsilon));
> +}

If something comparable doesn't already exist, these could become
macros similar to FF_MAX/MIX et.al.

> +if (face == BACK) {
[...]
> +} else if (face == LEFT) {
[...]
> +} else if (face == FRONT) {
[...]

What about switch/case? Just wondering.

> +} else {
> +;
> +}

I'm not sure an empty else should be expressed. ;-)

(Both previous comments are valid for various sections in the code.)

I don't understand most of the code, so no further comments from me.

Cheers,
Moritz
___
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] [PATCH] avfilter: add panorama filter

[Paul B Mahol]

Hi,

On 4/13/19, Eugene Lyapustin  wrote:
> Add filter for conversion between various panorama formats.
> Supported formats: equirectangular, cubemap 3x2, cubemap 6x1
>
> Contributions:
>
> unify remap calculation procedure
> add option for interpolation method
>
> Signed-off-by: Eugene Lyapustin 
>
> ---
>
> use bilinear from cubemap to equirectangular
> Change cube faces order to match Youtube's
> avfilter: add convertion to/from cubemap 6x1
>
> Signed-off-by: Hazem Ashmawy 
>
> ---
>
> avfilter: add panorama filter
>
> Signed-off-by: Paul B Mahol 
>
> Signed-off-by: Eugene Lyapustin 

Looks OK, some idea to implement later:
 -Reordering of cube faces by option which sets them in order.
___
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] [GSOC] [PATCH] avfilter: add panorama filter

[Eugene Lyapustin]

Add filter for conversion between various panorama formats.
Supported formats: equirectangular, cubemap 3x2, cubemap 6x1

Contributions:

unify remap calculation procedure
add option for interpolation method

Signed-off-by: Eugene Lyapustin 

---

use bilinear from cubemap to equirectangular
Change cube faces order to match Youtube's
avfilter: add convertion to/from cubemap 6x1

Signed-off-by: Hazem Ashmawy 

---

avfilter: add panorama filter

Signed-off-by: Paul B Mahol 

Signed-off-by: Eugene Lyapustin 
---
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_panorama.c | 637 ++
 3 files changed, 639 insertions(+)
 create mode 100644 libavfilter/vf_panorama.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fef6ec5c55..3c272da7b2 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -307,6 +307,7 @@ OBJS-$(CONFIG_OWDENOISE_FILTER)  += 
vf_owdenoise.o
 OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
 OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
 OBJS-$(CONFIG_PALETTEUSE_FILTER) += vf_paletteuse.o framesync.o
+OBJS-$(CONFIG_PANORAMA_FILTER)   += vf_panorama.o
 OBJS-$(CONFIG_PERMS_FILTER)  += f_perms.o
 OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
 OBJS-$(CONFIG_PHASE_FILTER)  += vf_phase.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c51ae0f3c7..f49c0a40e0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -292,6 +292,7 @@ extern AVFilter ff_vf_owdenoise;
 extern AVFilter ff_vf_pad;
 extern AVFilter ff_vf_palettegen;
 extern AVFilter ff_vf_paletteuse;
+extern AVFilter ff_vf_panorama;
 extern AVFilter ff_vf_perms;
 extern AVFilter ff_vf_perspective;
 extern AVFilter ff_vf_phase;
diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
new file mode 100644
index 00..34f02b0fa3
--- /dev/null
+++ b/libavfilter/vf_panorama.c
@@ -0,0 +1,637 @@
+/*
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum Projections {
+EQUIRECTANGULAR,
+CUBEMAP_6_1,
+CUBEMAP_3_2,
+NB_PROJECTIONS,
+};
+
+enum InterpMethod {
+  NEAREST,
+  BILINEAR,
+  NB_INTERP_METHODS,
+};
+
+enum Faces {
+RIGHT,
+LEFT,
+TOP,
+DOWN,
+FRONT,
+BACK,
+};
+
+struct XYRemap {
+int vi, ui;
+int v2, u2;
+double a, b, c, d;
+};
+
+typedef struct PanoramaContext {
+const AVClass *class;
+int in, out;
+int interp;
+
+int planewidth[4], planeheight[4];
+int inplanewidth[4], inplaneheight[4];
+int nb_planes;
+
+struct XYRemap *remap[4];
+
+int (*panorama)(struct PanoramaContext *s,
+const uint8_t *src, uint8_t *dst,
+int width, int height,
+int in_linesize, int out_linesize,
+const struct XYRemap *remap);
+} PanoramaContext;
+
+#define OFFSET(x) offsetof(PanoramaContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption panorama_options[] = {
+{"input", "set input projection", OFFSET(in), AV_OPT_TYPE_INT, 
  {.i64=EQUIRECTANGULAR}, 0,NB_PROJECTIONS-1, FLAGS, "in" },
+{"e", "equirectangular",   0, 
AV_OPT_TYPE_CONST, {.i64=EQUIRECTANGULAR}, 0,   0, FLAGS, "in" 
},
+{ "c6x1", "cubemap",   0, 
AV_OPT_TYPE_CONST, {.i64=CUBEMAP_6_1}, 0,   0, FLAGS, "in" 
},
+{ "c3x2", "cubemap",   0, 
AV_OPT_TYPE_CONST, {.i64=CUBEMAP_3_2}, 0,   0, FLAGS, "in" 
},
+{   "output", "set output projection",   OFFSET(out), AV_OPT_TYPE_INT, 
  {.i64=CUBEMAP_3_2}, 0,NB_PROJECTIONS-1, FLAGS, "out" },
+{"e", "equirectangular",   0, 
AV_OPT_TYPE_CONST, {.i64=EQUIRECTANGULAR}, 0, 

[FFmpeg-devel] [GSOC] [PATCH] avfilter: add panorama filter

[Eugene Lyapustin]

Hello,

This patch is a qualification task on 360 video filter.
I took a filter originally written by Paul B Mahol, and which was modified last 
year by another student. The filter had a lot of hardcoded conversions between 
formats, and it would be a pain to extend it with new ones. So I unified the 
remap calculation procedure. Now all formats only need functions to convert 
format coordinates to cartesian coordinates and vice versa. 

Regards,
Eugene Lyapustin

-- 
2.21.0

___
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 2019

[Tomas Härdin]

tis 2019-02-26 klockan 18:24 +0100 skrev Thilo Borgmann:
> Hi,
> 
> FFmpeg has just been selected as a mentoring organization for Google
> Summer of Code 2019 [1]!
> 
> As usual, we are still looking for more interesting student projects
> and mentors from our community willing to mentor.
> So please feel free to suggest a project and volunteer as mentor or
> backup mentor - you're welcome to edit the wiki directly or post your
> suggestion here on the list.
> 
> Find our wiki page here:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2019
> 
> Any feedback and help is appreciated!

Since AVIF seems to be nearing finalization, maybe adding support for
it could be a good project?

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC 2019

[Martin Vignali]

Hello,

I don't have knowledge to mentor a project,

But two idea :

- Swscale improvement :
YAP8, YAP16 : useful to switch some decoder/encoder to planar
Float/half float pixel format support

- Open Exr Decoder :
Add DWA decoder
support 4:2:0 mode

Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] GSoC 2019

[Thilo Borgmann]

Hi,

FFmpeg has just been selected as a mentoring organization for Google Summer of 
Code 2019 [1]!

As usual, we are still looking for more interesting student projects and 
mentors from our community willing to mentor.
So please feel free to suggest a project and volunteer as mentor or backup 
mentor - you're welcome to edit the wiki directly or post your suggestion here 
on the list.

Find our wiki page here:
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2019

Any feedback and help is appreciated!

Thanks,
Thilo

[1] https://summerofcode.withgoogle.com/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC mentored project: derain filter

[Michael Niedermayer]

On Wed, Feb 20, 2019 at 06:35:22PM +0800, 孟学苇 wrote:
> Hi Dev-Community,
> 
> 
> 
> 
> I am Iris Meng from China. I’m a PhD student in Institute of Digital Media, 
> Peking University. I wish to contribute as a GSoC applicant this year.
> 
> I am interested in Deep Learning. I want to add a derain filter in ffmpeg. If 
> you have any suggestion or question, we can contact by email. My motivation 
> and plans are as follows.
> 
> 
> 
> 
>Motivation
> 
> Rain and fog are very common weather in actual life. However, it can affect 
> the visibility. Especially in heavy rain, rain streaks from various 
> directions accumulate and make the background scene misty, which will 
> seriously influence the accuracy of many computer vision systems, including 
> video surveillance, object detection and tracking in autonomous driving, etc. 
> Therefore, it is an important task to remove the rain and fog, and recover 
> the background from rain images. It can be used for image and video 
> processing to make them clearer and it can be a preprocessing method for many 
> computer vision systems.
> 
> 
> 
> 
>Proposed Idea
> 
> We propose to implement this technology in ffmpeg. For video [1][2], we can 
> utilize the relationship between frames to remove rain and fog. For single 
> image [3], we can use traditional methods, such as discriminative sparse 
> coding, low rank representation and the Gaussian mixture model. We can also 
> use some deep learning methods. We should investigate these methods, and 
> ultimately consider the effect of rain/fog removal and the complexity of the 
> algorithm, and choose the optimal scheme.
> 
> 
> 
> 
>Practical application
> 
> The derain and dehaze method can improve the subjective quality of videos and 
> images.
> 
> 
> 
> 
>   Development plan
> 

> I would like to start working on my qualification task and try to solve my 
> problems. Overall, I will follow the following steps to complete the project.
> 
> (1)Literature and algorithm investigation
> 
> (2)Data sets preparation
> 
> (3)Coding: Implement network, training code, inference code and so on
> 
> (4)Select the best method and transplantation it into ffmpeg

I would suggest to do the coding within FFmpeg from as early as possible, not
to implement things outside and transplant later. This should be less work and
avoids underestimating the work to transplant the code

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC mentored project: derain filter

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Liu Steven
> Sent: Wednesday, February 20, 2019 7:18 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Thilo Borgmann ; Liu Steven
> 
> Subject: Re: [FFmpeg-devel] GSoC mentored project: derain filter
> 
> 
> 
> > 在 2019年2月20日，下午6:35，孟学苇  写道：
> >
> > Hi Dev-Community,
> >
> >
> >
> >
> > I am Iris Meng from China. I’m a PhD student in Institute of Digital Media,
> Peking University. I wish to contribute as a GSoC applicant this year.
> >
> > I am interested in Deep Learning. I want to add a derain filter in ffmpeg. 
> > If
> you have any suggestion or question, we can contact by email. My
> motivation and plans are as follows.
> >
> >
> >
> >
> >   Motivation
> >
> > Rain and fog are very common weather in actual life. However, it can affect
> the visibility. Especially in heavy rain, rain streaks from various directions
> accumulate and make the background scene misty, which will seriously
> influence the accuracy of many computer vision systems, including video
> surveillance, object detection and tracking in autonomous driving, etc.
> Therefore, it is an important task to remove the rain and fog, and recover the
> background from rain images. It can be used for image and video processing
> to make them clearer and it can be a preprocessing method for many
> computer vision systems.
> >
> >
> >
> >
> >   Proposed Idea
> >
> > We propose to implement this technology in ffmpeg. For video [1][2], we
> can utilize the relationship between frames to remove rain and fog. For
> single image [3], we can use traditional methods, such as discriminative
> sparse coding, low rank representation and the Gaussian mixture model. We
> can also use some deep learning methods. We should investigate these
> methods, and ultimately consider the effect of rain/fog removal and the
> complexity of the algorithm, and choose the optimal scheme.
> >
> >
> >
> >
> >   Practical application
> >
> > The derain and dehaze method can improve the subjective quality of
> videos and images.
> >
> >
> >
> >
> >  Development plan
> >
> > I would like to start working on my qualification task and try to solve my
> problems. Overall, I will follow the following steps to complete the project.
> >
> > (1)Literature and algorithm investigation
> >
> > (2)Data sets preparation
> >
> > (3)Coding: Implement network, training code, inference code and so on
> >
> > (4)Select the best method and transplantation it into ffmpeg
> >
> >
> >
> >
> >  Reference
> >
> >  [1] Zhang X, Li H, Qi Y, et al. Rain removal in video by combining 
> > temporal
> and chromatic properties[C]//2006 IEEE International Conference on
> Multimedia and Expo. IEEE, 2006: 461-464.
> >
> >  [2] Tripathi A K, Mukhopadhyay S. Removal of rain from videos: a
> review[J]. Signal, Image and Video Processing, 2014, 8(8): 1421-1430.
> >
> >  [3] Li X, Wu J, Lin Z, et al. Recurrent squeeze-and-excitation context
> aggregation net for single image deraining[C]//Proceedings of the European
> Conference on Computer Vision (ECCV). 2018: 254-269.
> >
> >
> >
> I think this can reference libavflter/sr.c to implementation, maybe you can
> try two ways to implement it, one is native and the other is model.
> 

and currently, only TensorFlow model is supported via tensorflow C API, 
you can easily save the model file in python with function 
tf.graph_util.convert_variables_to_constants and tf.train.write_graph.

For the native mode (executed with CPU), two operations (CONV and 
DEPTH_TO_SPACE) are supported now, you might add more.

> 
> Thanks
> Steven
> 
> >
> >
> >
> >
> > Thanks,
> >
> > Regards,
> >
> > Iris Meng
> > ___
> > 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC mentored project: derain filter

[Liu Steven]

> 在 2019年2月20日，下午6:35，孟学苇  写道：
> 
> Hi Dev-Community,
> 
> 
> 
> 
> I am Iris Meng from China. I’m a PhD student in Institute of Digital Media, 
> Peking University. I wish to contribute as a GSoC applicant this year.
> 
> I am interested in Deep Learning. I want to add a derain filter in ffmpeg. If 
> you have any suggestion or question, we can contact by email. My motivation 
> and plans are as follows.
> 
> 
> 
> 
>   Motivation
> 
> Rain and fog are very common weather in actual life. However, it can affect 
> the visibility. Especially in heavy rain, rain streaks from various 
> directions accumulate and make the background scene misty, which will 
> seriously influence the accuracy of many computer vision systems, including 
> video surveillance, object detection and tracking in autonomous driving, etc. 
> Therefore, it is an important task to remove the rain and fog, and recover 
> the background from rain images. It can be used for image and video 
> processing to make them clearer and it can be a preprocessing method for many 
> computer vision systems.
> 
> 
> 
> 
>   Proposed Idea
> 
> We propose to implement this technology in ffmpeg. For video [1][2], we can 
> utilize the relationship between frames to remove rain and fog. For single 
> image [3], we can use traditional methods, such as discriminative sparse 
> coding, low rank representation and the Gaussian mixture model. We can also 
> use some deep learning methods. We should investigate these methods, and 
> ultimately consider the effect of rain/fog removal and the complexity of the 
> algorithm, and choose the optimal scheme.
> 
> 
> 
> 
>   Practical application
> 
> The derain and dehaze method can improve the subjective quality of videos and 
> images.
> 
> 
> 
> 
>  Development plan
> 
> I would like to start working on my qualification task and try to solve my 
> problems. Overall, I will follow the following steps to complete the project.
> 
> (1)Literature and algorithm investigation
> 
> (2)Data sets preparation
> 
> (3)Coding: Implement network, training code, inference code and so on
> 
> (4)Select the best method and transplantation it into ffmpeg
> 
> 
> 
> 
>  Reference
> 
>  [1] Zhang X, Li H, Qi Y, et al. Rain removal in video by combining 
> temporal and chromatic properties[C]//2006 IEEE International Conference on 
> Multimedia and Expo. IEEE, 2006: 461-464.
> 
>  [2] Tripathi A K, Mukhopadhyay S. Removal of rain from videos: a 
> review[J]. Signal, Image and Video Processing, 2014, 8(8): 1421-1430.
> 
>  [3] Li X, Wu J, Lin Z, et al. Recurrent squeeze-and-excitation context 
> aggregation net for single image deraining[C]//Proceedings of the European 
> Conference on Computer Vision (ECCV). 2018: 254-269.
> 
> 
> 
I think this can reference libavflter/sr.c to implementation, maybe you can try 
two ways to implement it, one is native and the other is model.


Thanks
Steven

> 
> 
> 
> 
> Thanks,
> 
> Regards,
> 
> Iris Meng
> ___
> 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] GSoC mentored project: derain filter

[孟学苇]

Hi Dev-Community,




I am Iris Meng from China. I’m a PhD student in Institute of Digital Media, 
Peking University. I wish to contribute as a GSoC applicant this year.

I am interested in Deep Learning. I want to add a derain filter in ffmpeg. If 
you have any suggestion or question, we can contact by email. My motivation and 
plans are as follows.




   Motivation

Rain and fog are very common weather in actual life. However, it can affect the 
visibility. Especially in heavy rain, rain streaks from various directions 
accumulate and make the background scene misty, which will seriously influence 
the accuracy of many computer vision systems, including video surveillance, 
object detection and tracking in autonomous driving, etc. Therefore, it is an 
important task to remove the rain and fog, and recover the background from rain 
images. It can be used for image and video processing to make them clearer and 
it can be a preprocessing method for many computer vision systems.




   Proposed Idea

We propose to implement this technology in ffmpeg. For video [1][2], we can 
utilize the relationship between frames to remove rain and fog. For single 
image [3], we can use traditional methods, such as discriminative sparse 
coding, low rank representation and the Gaussian mixture model. We can also use 
some deep learning methods. We should investigate these methods, and ultimately 
consider the effect of rain/fog removal and the complexity of the algorithm, 
and choose the optimal scheme.




   Practical application

The derain and dehaze method can improve the subjective quality of videos and 
images.




  Development plan

I would like to start working on my qualification task and try to solve my 
problems. Overall, I will follow the following steps to complete the project.

(1)Literature and algorithm investigation

(2)Data sets preparation

(3)Coding: Implement network, training code, inference code and so on

(4)Select the best method and transplantation it into ffmpeg




  Reference

  [1] Zhang X, Li H, Qi Y, et al. Rain removal in video by combining 
temporal and chromatic properties[C]//2006 IEEE International Conference on 
Multimedia and Expo. IEEE, 2006: 461-464.

  [2] Tripathi A K, Mukhopadhyay S. Removal of rain from videos: a 
review[J]. Signal, Image and Video Processing, 2014, 8(8): 1421-1430.

  [3] Li X, Wu J, Lin Z, et al. Recurrent squeeze-and-excitation context 
aggregation net for single image deraining[C]//Proceedings of the European 
Conference on Computer Vision (ECCV). 2018: 254-269.







Thanks,

Regards,

Iris Meng
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] GSoC 2018 mentor summit review

[Thilo Borgmann]

Hi folks,

last weekend we attended the annual GSoC mentor summit. This time, it was Pedro 
Arthur and myself going there. As usual, there have been a huge amount of 
interesting fellow open-source projects around and we've met a lot of 
interesting people.

There have been a lot of interesting sessions like last year. Of course, many 
topics have been quite similar and development/progress in some areas are not 
too fast. The usual suspects have been in the general audio/video/multimedia 
session (VideoLAN, Kodi, Mixxx, MuseScore, Apertus, and others). Apart from the 
usual chat, we ha a general discussion about multimedia apps in the future - in 
general about moving away from a bare desktop application to a more web and/or 
service based application. More of interest for the front-end applications than 
for us being a library, of course.

There has been a session about OSS licences again, I can't remember a severe 
change of information given compared to last year, so [1] should still be an 
excellent resource of more information.

The team from ScummVM is interested in improving one of the gaming codecs and 
maybe someone will be into this fun :) They should provide us some samples 
containing yet ignored side-data, used for sprite-like animation of decoded 
sprite content onto the output image/canvas (if I understood correctly, what 
they were explaining).

We also have an open offer for cooperation/support by Red Hen Lab [2]. They are 
recording and transcoding a massiva amount of TV broadcastsa around the world 
including more rare formats like DTMB (chineese TV) and ISDB (JP and southern 
american TV). They would be able to provide us with any samples we might find 
interesting. If anyone is interested, send me a mail.

There has been an announcement about an upcoming new Google program from 
Google's OSPO. There will be a "Season of Docs", aiming to reach out for 
technical writers to enhance documentation of open source programs. In contrast 
to GSoC, this shall not be a sponsored work but pro bono. More details yet to 
be disclosed!

Finally, a community driven overview of the sessions given and notes taken per 
session can be found here [3], for anyone interested in specifics of that or 
the corresponding notes.

It was my pleasure to come to know Pedro in person - maybe he has some more 
comments about the summit and hin impressions.

Cheers,
Thilo

[1] https://opensource.org/licenses/

[2] http://www.redhenlab.org/

[3] 
https://docs.google.com/document/d/1nNSud67RB_39HERpPdn-r6U3ANiC31VWHiFkKAoENBI/edit?ts=5bc91932#heading=h.lbox8n3en4ka
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC][PATCH 1/3] lavc/cfhd:3d transform decoding for both progressive and interlaced

[Michael Niedermayer]

On Thu, Sep 06, 2018 at 11:34:57AM +0530, Gagandeep Singh wrote:
> On Sat, Aug 18, 2018 at 1:47 AM Michael Niedermayer 
> wrote:
> 
> > On Fri, Aug 17, 2018 at 11:45:04AM +0530, Gagandeep Singh wrote:
> > [...]
> > >
> > > > [...]
> > > > > @@ -726,14 +814,15 @@ static int cfhd_decode(AVCodecContext *avctx,
> > void
> > > > *data, int *got_frame,
> > > > >  }
> > > > >  }
> > > > >  }
> > > > > -
> > > > > -if (!s->a_width || !s->a_height || s->a_format ==
> > AV_PIX_FMT_NONE ||
> > > > > -s->coded_width || s->coded_height || s->coded_format !=
> > > > AV_PIX_FMT_NONE) {
> > > >
> > > > > +//disabled to run mountain sample file
> > > > > +#if 0
> > > > > +if ((!s->a_width || !s->a_height || s->a_format ==
> > AV_PIX_FMT_NONE
> > > > ||
> > > > > +s->coded_width || s->coded_height || s->coded_format !=
> > > > AV_PIX_FMT_NONE) && s->sample_type != 1) {
> > > > >  av_log(avctx, AV_LOG_ERROR, "Invalid dimensions\n");
> > > > >  ret = AVERROR(EINVAL);
> > > > >  goto end;
> > > > >  }
> > > > > -
> > > > > +#endif
> > > >
> > > > please elaborate why this needs to be disabled
> > > > i presume this code was needed for something
> > > >
> > > I didn't need to disable this for any sample except one, where the image
> > > height and width data wasn't transfered in accordance to how it was in
> > the
> > > rest of the sample so the flow of code was just causing the decoder to
> > > crash. I can produce a more robust fix, though again will need to repost
> > > other patches as well, please comment.
> > >
> > > > also this decoder with the patches should be tested with a fuzzer to
> > > > reduce
> > > > the chance of bugs
> > > >
> > > > I don't know how to use 'fuzzer', sorry, though i can look into that.
> >
> > had missed this reply as its not quoted correctly
> > yes, please look into testing this with a fuzzer, we should make reasonable
> > sure we dont add anomalies
> >
> > thx
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Dictatorship naturally arises out of democracy, and the most aggravated
> > form of tyranny and slavery out of the most extreme liberty. -- Plato
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> Hi,
> patch updated to add back the check.

>  cfhd.c |  504 
> +
>  cfhd.h |   13 +
>  2 files changed, 450 insertions(+), 67 deletions(-)
> 67182ed6c7222c3a544f07d3501c072da16682ae  3d_transform_add.patch
> From f99726110a9e9e127fc2c7b4bbc3945764ecbfdd Mon Sep 17 00:00:00 2001
> From: Gagandeep Singh 
> Date: Thu, 6 Sep 2018 11:08:57 +0530
> Subject: [GSOC][PATCH 1/3] lavc/cfhd: 3d transform decoding added for both
>  progressive and interlaced samples
> 
> ---
>  libavcodec/cfhd.c | 504 --
>  libavcodec/cfhd.h |  13 +-
>  2 files changed, 450 insertions(+), 67 deletions(-)
> 
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 846d334b9b..3929b54f31 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -41,12 +41,15 @@
>  #define ALPHA_COMPAND_GAIN 9400
>  
>  enum CFHDParam {
> +TransformType=  10,
>  ChannelCount =  12,
>  SubbandCount =  14,
> +Pframe   =  19,
>  ImageWidth   =  20,
>  ImageHeight  =  21,
>  LowpassPrecision =  35,
>  SubbandNumber=  48,
> +EncodingMethod   =  52,
>  Quantization =  53,
>  ChannelNumber=  62,
>  SampleFlags  =  68,
> @@ -64,6 +67,7 @@ static av_cold int cfhd_init(AVCodecContext *avctx)
>  
>  avctx->bits_per_raw_sample = 10;
>  s->avctx   = avctx;
> +s->progressive = 0;
>  
>  return ff_cfhd_init_vlcs(s);
>  }
> @@ -84,6 +88,10 @@ static void init_peak_table_defaults(CFHDContext *s)
>  
>  static void init_frame_defaults(CFHDContext *s)
>  {
> +s->sample_type   = 0;
> +s->transform_type= 0;
> +s->pframe= 0;
> +s->first_wavelet = 0;
>  s->coded_width   = 0;
>  s->coded_height  = 0;
>  s->cropped_height= 0;
> @@ -97,14 +105,15 @@ static void init_frame_defaults(CFHDContext *s)
>  s->pshift= 1;
>  s->codebook  = 0;
>  s->difference_coding = 0;
> -s->progressive   = 0;
>  init_plane_defaults(s);
>  init_peak_table_defaults(s);
>  }
>  
>  /* TODO: merge with VLC tables or use LUT */
> -static inline int dequant_and_decompand(int level, int quantisation, int 
> codebook)
> +static inline int dequant_and_decompand(int level, int quantisation, int 
> codebook, int lossless)
>  {
> +if (lossless)
> +return level;
>  if (codebook == 0 || codebook == 1) {
>  int64_t abslevel = abs(level);
>  if (level < 264)
> @@ 

Re: [FFmpeg-devel] [GSOC][PATCH 1/3] lavc/cfhd:3d transform decoding for both progressive and interlaced

[Michael Niedermayer]

On Thu, Sep 06, 2018 at 11:50:12AM +0530, Gagandeep Singh wrote:
> On Thu, Sep 6, 2018 at 11:34 AM Gagandeep Singh 
> wrote:
> 
> >
> >
> > On Sat, Aug 18, 2018 at 1:47 AM Michael Niedermayer 
> > wrote:
> >
> >> On Fri, Aug 17, 2018 at 11:45:04AM +0530, Gagandeep Singh wrote:
> >> [...]
> >> >
> >> > > [...]
> >> > > > @@ -726,14 +814,15 @@ static int cfhd_decode(AVCodecContext *avctx,
> >> void
> >> > > *data, int *got_frame,
> >> > > >  }
> >> > > >  }
> >> > > >  }
> >> > > > -
> >> > > > -if (!s->a_width || !s->a_height || s->a_format ==
> >> AV_PIX_FMT_NONE ||
> >> > > > -s->coded_width || s->coded_height || s->coded_format !=
> >> > > AV_PIX_FMT_NONE) {
> >> > >
> >> > > > +//disabled to run mountain sample file
> >> > > > +#if 0
> >> > > > +if ((!s->a_width || !s->a_height || s->a_format ==
> >> AV_PIX_FMT_NONE
> >> > > ||
> >> > > > +s->coded_width || s->coded_height || s->coded_format !=
> >> > > AV_PIX_FMT_NONE) && s->sample_type != 1) {
> >> > > >  av_log(avctx, AV_LOG_ERROR, "Invalid dimensions\n");
> >> > > >  ret = AVERROR(EINVAL);
> >> > > >  goto end;
> >> > > >  }
> >> > > > -
> >> > > > +#endif
> >> > >
> >> > > please elaborate why this needs to be disabled
> >> > > i presume this code was needed for something
> >> > >
> >> > I didn't need to disable this for any sample except one, where the image
> >> > height and width data wasn't transfered in accordance to how it was in
> >> the
> >> > rest of the sample so the flow of code was just causing the decoder to
> >> > crash. I can produce a more robust fix, though again will need to repost
> >> > other patches as well, please comment.
> >> >
> >> > > also this decoder with the patches should be tested with a fuzzer to
> >> > > reduce
> >> > > the chance of bugs
> >> > >
> >> > > I don't know how to use 'fuzzer', sorry, though i can look into that.
> >>
> >> had missed this reply as its not quoted correctly
> >> yes, please look into testing this with a fuzzer, we should make
> >> reasonable
> >> sure we dont add anomalies
> >>
> >> thx
> >>
> >> [...]
> >> --
> >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >>
> >> Dictatorship naturally arises out of democracy, and the most aggravated
> >> form of tyranny and slavery out of the most extreme liberty. -- Plato
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> > Hi,
> > patch updated to add back the check.
> >
> 
> The work around for the check is just to not to check for the coded_width
> == 0 and coded_height == 0 as these are used to set a_width and a_height
> during buffer allocation (which are also being checked for non zero values.
> coded_width and coded_height  were later set to 0 for a loop exit (which
> has been taken care of in other way), and  since i needed to update
> coded_width and coded_height with some other data in case they were not
> available in the sample(we have a sample for the same), thus it
> necessitates that the unneeded check be removed.

tested with zzuf
it crashes:
make -j12 && zzuf -M -1 -r 0.1 -s 0:1000 ./ffmpeg -i 
fate-suite/cfhd/cfhd_odd.mov -f null -

zzuf[s=297,r=1e-05]: signal 11 (SIGSEGV)



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC][PATCH 2/3] lavc/cfhd:corrected decompanding for table 9 used in cfhd

[Michael Niedermayer]

On Thu, Sep 06, 2018 at 11:36:22AM +0530, Gagandeep Singh wrote:
> On Fri, Aug 17, 2018 at 11:34 AM Gagandeep Singh 
> wrote:
> 
> >
> >
> > On Thu, Aug 16, 2018 at 2:37 AM Kieran Kunhya  wrote:
> >
> >> On Tue, 14 Aug 2018 at 08:43 Gagandeep Singh 
> >> wrote:
> >>
> >> > Second patch for fixing decompanding in table 9.
> >> >
> >> > Gagandeep Singh
> >> >
> >>
> >> Seems ok
> >>
> >> Kieran
> >>
> >
> > Thanks!!
> >
> > Gagandeep Singh
> >
> 
> Hi,
> This patch is to be applied along with the other updated patches.
> 
> Thanks
> Gagandeep Singh
> 
> > ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >

>  cfhd.c |   25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 44fe9de4bb44ecd39071a9e543b7f8a718a41915  decompanding_fix.patch
> From 4f0c812aaf50738e579bde0bb12b9f2391eb15e5 Mon Sep 17 00:00:00 2001
> From: Gagandeep Singh 
> Date: Thu, 6 Sep 2018 11:12:16 +0530
> Subject: [GSOC][PATCH 2/3] lavc/cfhd: correct decompanding for old codebook 
> (table 9)
> 
> ---
>  libavcodec/cfhd.c | 25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 3929b54f31..e78fa81655 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -114,7 +114,30 @@ static inline int dequant_and_decompand(int level, int 
> quantisation, int codeboo
>  {
>  if (lossless)
>  return level;
> -if (codebook == 0 || codebook == 1) {
> +if (codebook == 0) {
> +if (level >= 40 && level < 264) {
> +if (level >= 54) {

> +level  -= 54;
> +level <<= 2;
> +level  += 54;

this can be simplified:
level = (level<<2) - 3*54;

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC][PATCH 1/3] lavc/cfhd:3d transform decoding for both progressive and interlaced

[Gagandeep Singh]

On Thu, Sep 6, 2018 at 11:34 AM Gagandeep Singh 
wrote:

>
>
> On Sat, Aug 18, 2018 at 1:47 AM Michael Niedermayer 
> wrote:
>
>> On Fri, Aug 17, 2018 at 11:45:04AM +0530, Gagandeep Singh wrote:
>> [...]
>> >
>> > > [...]
>> > > > @@ -726,14 +814,15 @@ static int cfhd_decode(AVCodecContext *avctx,
>> void
>> > > *data, int *got_frame,
>> > > >  }
>> > > >  }
>> > > >  }
>> > > > -
>> > > > -if (!s->a_width || !s->a_height || s->a_format ==
>> AV_PIX_FMT_NONE ||
>> > > > -s->coded_width || s->coded_height || s->coded_format !=
>> > > AV_PIX_FMT_NONE) {
>> > >
>> > > > +//disabled to run mountain sample file
>> > > > +#if 0
>> > > > +if ((!s->a_width || !s->a_height || s->a_format ==
>> AV_PIX_FMT_NONE
>> > > ||
>> > > > +s->coded_width || s->coded_height || s->coded_format !=
>> > > AV_PIX_FMT_NONE) && s->sample_type != 1) {
>> > > >  av_log(avctx, AV_LOG_ERROR, "Invalid dimensions\n");
>> > > >  ret = AVERROR(EINVAL);
>> > > >  goto end;
>> > > >  }
>> > > > -
>> > > > +#endif
>> > >
>> > > please elaborate why this needs to be disabled
>> > > i presume this code was needed for something
>> > >
>> > I didn't need to disable this for any sample except one, where the image
>> > height and width data wasn't transfered in accordance to how it was in
>> the
>> > rest of the sample so the flow of code was just causing the decoder to
>> > crash. I can produce a more robust fix, though again will need to repost
>> > other patches as well, please comment.
>> >
>> > > also this decoder with the patches should be tested with a fuzzer to
>> > > reduce
>> > > the chance of bugs
>> > >
>> > > I don't know how to use 'fuzzer', sorry, though i can look into that.
>>
>> had missed this reply as its not quoted correctly
>> yes, please look into testing this with a fuzzer, we should make
>> reasonable
>> sure we dont add anomalies
>>
>> thx
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Dictatorship naturally arises out of democracy, and the most aggravated
>> form of tyranny and slavery out of the most extreme liberty. -- Plato
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
> Hi,
> patch updated to add back the check.
>

The work around for the check is just to not to check for the coded_width
== 0 and coded_height == 0 as these are used to set a_width and a_height
during buffer allocation (which are also being checked for non zero values.
coded_width and coded_height  were later set to 0 for a loop exit (which
has been taken care of in other way), and  since i needed to update
coded_width and coded_height with some other data in case they were not
available in the sample(we have a sample for the same), thus it
necessitates that the unneeded check be removed.

Thanks
Gagandeep Singh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC][PATCH 1/3] lavc/cfhd:3d transform decoding for both progressive and interlaced

[Gagandeep Singh]

On Sat, Aug 18, 2018 at 1:47 AM Michael Niedermayer 
wrote:

> On Fri, Aug 17, 2018 at 11:45:04AM +0530, Gagandeep Singh wrote:
> [...]
> >
> > > [...]
> > > > @@ -726,14 +814,15 @@ static int cfhd_decode(AVCodecContext *avctx,
> void
> > > *data, int *got_frame,
> > > >  }
> > > >  }
> > > >  }
> > > > -
> > > > -if (!s->a_width || !s->a_height || s->a_format ==
> AV_PIX_FMT_NONE ||
> > > > -s->coded_width || s->coded_height || s->coded_format !=
> > > AV_PIX_FMT_NONE) {
> > >
> > > > +//disabled to run mountain sample file
> > > > +#if 0
> > > > +if ((!s->a_width || !s->a_height || s->a_format ==
> AV_PIX_FMT_NONE
> > > ||
> > > > +s->coded_width || s->coded_height || s->coded_format !=
> > > AV_PIX_FMT_NONE) && s->sample_type != 1) {
> > > >  av_log(avctx, AV_LOG_ERROR, "Invalid dimensions\n");
> > > >  ret = AVERROR(EINVAL);
> > > >  goto end;
> > > >  }
> > > > -
> > > > +#endif
> > >
> > > please elaborate why this needs to be disabled
> > > i presume this code was needed for something
> > >
> > I didn't need to disable this for any sample except one, where the image
> > height and width data wasn't transfered in accordance to how it was in
> the
> > rest of the sample so the flow of code was just causing the decoder to
> > crash. I can produce a more robust fix, though again will need to repost
> > other patches as well, please comment.
> >
> > > also this decoder with the patches should be tested with a fuzzer to
> > > reduce
> > > the chance of bugs
> > >
> > > I don't know how to use 'fuzzer', sorry, though i can look into that.
>
> had missed this reply as its not quoted correctly
> yes, please look into testing this with a fuzzer, we should make reasonable
> sure we dont add anomalies
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Hi,
patch updated to add back the check.
From f99726110a9e9e127fc2c7b4bbc3945764ecbfdd Mon Sep 17 00:00:00 2001
From: Gagandeep Singh 
Date: Thu, 6 Sep 2018 11:08:57 +0530
Subject: [GSOC][PATCH 1/3] lavc/cfhd: 3d transform decoding added for both
 progressive and interlaced samples

---
 libavcodec/cfhd.c | 504 --
 libavcodec/cfhd.h |  13 +-
 2 files changed, 450 insertions(+), 67 deletions(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334b9b..3929b54f31 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -41,12 +41,15 @@
 #define ALPHA_COMPAND_GAIN 9400
 
 enum CFHDParam {
+TransformType=  10,
 ChannelCount =  12,
 SubbandCount =  14,
+Pframe   =  19,
 ImageWidth   =  20,
 ImageHeight  =  21,
 LowpassPrecision =  35,
 SubbandNumber=  48,
+EncodingMethod   =  52,
 Quantization =  53,
 ChannelNumber=  62,
 SampleFlags  =  68,
@@ -64,6 +67,7 @@ static av_cold int cfhd_init(AVCodecContext *avctx)
 
 avctx->bits_per_raw_sample = 10;
 s->avctx   = avctx;
+s->progressive = 0;
 
 return ff_cfhd_init_vlcs(s);
 }
@@ -84,6 +88,10 @@ static void init_peak_table_defaults(CFHDContext *s)
 
 static void init_frame_defaults(CFHDContext *s)
 {
+s->sample_type   = 0;
+s->transform_type= 0;
+s->pframe= 0;
+s->first_wavelet = 0;
 s->coded_width   = 0;
 s->coded_height  = 0;
 s->cropped_height= 0;
@@ -97,14 +105,15 @@ static void init_frame_defaults(CFHDContext *s)
 s->pshift= 1;
 s->codebook  = 0;
 s->difference_coding = 0;
-s->progressive   = 0;
 init_plane_defaults(s);
 init_peak_table_defaults(s);
 }
 
 /* TODO: merge with VLC tables or use LUT */
-static inline int dequant_and_decompand(int level, int quantisation, int codebook)
+static inline int dequant_and_decompand(int level, int quantisation, int codebook, int lossless)
 {
+if (lossless)
+return level;
 if (codebook == 0 || codebook == 1) {
 int64_t abslevel = abs(level);
 if (level < 264)
@@ -193,16 +202,21 @@ static inline void filter(int16_t *output, ptrdiff_t out_stride,
 }
 }
 
-static inline void interlaced_vertical_filter(int16_t *output, int16_t *low, int16_t *high,
- int width, int linesize, int plane)
+static inline void inverse_temporal_filter(int16_t *output, int16_t *low, int16_t *high,
+ int width, int linesize, int temporal_for_highpass)
 {
 int i;
 int16_t even, odd;
 for (i = 0; i < width; i++) {
 even = (low[i] - high[i])/2;
 odd  = (low[i] + high[i])/2;
-

Re: [FFmpeg-devel] [GSOC][PATCH 3/3] lavc/cfhd:frame threading support for 3d transform progressive and interlaced samples

[Gagandeep Singh]

Hi,
The new patch is to applied on top of the new patches sent.

Thanks
Gagandeep Singh

On Tue, Aug 14, 2018 at 1:14 PM Gagandeep Singh 
wrote:

> Last patch adding frame thread support for ip samples in both progressive
> and interlaced versions.
>
> Gagandeep Singh
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC][PATCH 2/3] lavc/cfhd:corrected decompanding for table 9 used in cfhd

[Gagandeep Singh]

On Fri, Aug 17, 2018 at 11:34 AM Gagandeep Singh 
wrote:

>
>
> On Thu, Aug 16, 2018 at 2:37 AM Kieran Kunhya  wrote:
>
>> On Tue, 14 Aug 2018 at 08:43 Gagandeep Singh 
>> wrote:
>>
>> > Second patch for fixing decompanding in table 9.
>> >
>> > Gagandeep Singh
>> >
>>
>> Seems ok
>>
>> Kieran
>>
>
> Thanks!!
>
> Gagandeep Singh
>

Hi,
This patch is to be applied along with the other updated patches.

Thanks
Gagandeep Singh

> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
From 4f0c812aaf50738e579bde0bb12b9f2391eb15e5 Mon Sep 17 00:00:00 2001
From: Gagandeep Singh 
Date: Thu, 6 Sep 2018 11:12:16 +0530
Subject: [GSOC][PATCH 2/3] lavc/cfhd: correct decompanding for old codebook (table 9)

---
 libavcodec/cfhd.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 3929b54f31..e78fa81655 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -114,7 +114,30 @@ static inline int dequant_and_decompand(int level, int quantisation, int codeboo
 {
 if (lossless)
 return level;
-if (codebook == 0 || codebook == 1) {
+if (codebook == 0) {
+if (level >= 40 && level < 264) {
+if (level >= 54) {
+level  -= 54;
+level <<= 2;
+level  += 54;
+}
+level  -= 40;
+level <<= 2;
+level  += 40;
+} else if (level <= -40) {
+level = -level;
+if (level >= 54) {
+level  -= 54;
+level <<= 2;
+level  += 54;
+}
+level  -= 40;
+level <<= 2;
+level  += 40;
+level   = -level;
+}
+return level * quantisation;
+} else if (codebook == 1) {
 int64_t abslevel = abs(level);
 if (level < 264)
 return (abslevel + ((768 * abslevel * abslevel * abslevel) / (255 * 255 * 255))) *
-- 
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSOC Complete

[Shlomi Fish]

On Wed, 22 Aug 2018 14:33:52 +0530
Gagandeep Singh  wrote:

> Hi,
> 
> I would like to thank all the FFmpeg developers who have helped me in my 3
> months of project. durandal_1707 thanks for the last minute check on the
> file.
> 
> I also thank my mentor kierank, for his faith in me even though during the
> second month i was not feeling that i would be able to work on it anymore.
> 
> I would continue to be involved in FFmpeg development (in my capacity -
> only a B.Tech student here :\ ).
> 
> I also know that the project was comparatively easier and could have been
> finished sooner, so thanks for being patient with me.
> 

Thanks Gagandeep and all!

> Sincerely
> Gagandeep Singh
> GSOC 2018
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



-- 
-
Shlomi Fish   http://www.shlomifish.org/
http://shlomifishswiki.branchable.com/Self-Sufficiency/

There are no deletionists. Only Wikipedia articles which Chuck Norris allows
to live. (By: joeyadams)
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - http://shlom.in/reply .
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] GSOC Complete

[Gagandeep Singh]

Hi,

I would like to thank all the FFmpeg developers who have helped me in my 3
months of project. durandal_1707 thanks for the last minute check on the
file.

I also thank my mentor kierank, for his faith in me even though during the
second month i was not feeling that i would be able to work on it anymore.

I would continue to be involved in FFmpeg development (in my capacity -
only a B.Tech student here :\ ).

I also know that the project was comparatively easier and could have been
finished sooner, so thanks for being patient with me.

Sincerely
Gagandeep Singh
GSOC 2018
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC] [PATCH 1/2] lavfi/vf_colorconstancy: adding weighted_ greyedge

[Thilo Borgmann]

Am 14.08.18 um 21:00 schrieb Thilo Borgmann:
> Am 13.08.18 um 02:01 schrieb Mina:
>> Hi,
>>
>>   This patch introduces a new improved color constancy algorithm based on 
>> previously implemented greyedge algorithm.
> 
> LGTM since I looked at this during GSoC. I would appreciate someone to have a 
> second look.

Ping.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC][PATCH 1/3] lavc/cfhd:3d transform decoding for both progressive and interlaced

[Michael Niedermayer]

On Fri, Aug 17, 2018 at 11:45:04AM +0530, Gagandeep Singh wrote:
[...]
> 
> > [...]
> > > @@ -726,14 +814,15 @@ static int cfhd_decode(AVCodecContext *avctx, void
> > *data, int *got_frame,
> > >  }
> > >  }
> > >  }
> > > -
> > > -if (!s->a_width || !s->a_height || s->a_format == AV_PIX_FMT_NONE ||
> > > -s->coded_width || s->coded_height || s->coded_format !=
> > AV_PIX_FMT_NONE) {
> >
> > > +//disabled to run mountain sample file
> > > +#if 0
> > > +if ((!s->a_width || !s->a_height || s->a_format == AV_PIX_FMT_NONE
> > ||
> > > +s->coded_width || s->coded_height || s->coded_format !=
> > AV_PIX_FMT_NONE) && s->sample_type != 1) {
> > >  av_log(avctx, AV_LOG_ERROR, "Invalid dimensions\n");
> > >  ret = AVERROR(EINVAL);
> > >  goto end;
> > >  }
> > > -
> > > +#endif
> >
> > please elaborate why this needs to be disabled
> > i presume this code was needed for something
> >
> I didn't need to disable this for any sample except one, where the image
> height and width data wasn't transfered in accordance to how it was in the
> rest of the sample so the flow of code was just causing the decoder to
> crash. I can produce a more robust fix, though again will need to repost
> other patches as well, please comment.
> 
> > also this decoder with the patches should be tested with a fuzzer to
> > reduce
> > the chance of bugs
> >
> > I don't know how to use 'fuzzer', sorry, though i can look into that.

had missed this reply as its not quoted correctly
yes, please look into testing this with a fuzzer, we should make reasonable
sure we dont add anomalies

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel