[FFmpeg-devel] GSoC Weekly Report (libswscale refactor)

Michael Niedermayer michaelni at gmx.at
Thu Jun 25 03:00:31 CEST 2015


On Wed, Jun 24, 2015 at 02:41:54PM -0300, Pedro Arthur wrote:
> Hi,
> 
> I'm working on the libswscale refactoring and Michael advised me to send
> the changes to the
> mailing list so that I can get more feedback about it. Thus I added the
> references [1] - [7] which
> are links to commits on my github fork of FFmpeg.
> 
> Last week I wrote the horizontal chroma scaling (patches [3]-[7]) code and
> spent some time
> ensuring it passes all tests.

it passes fate but seems to crash for example with:
./ffmpeg -i lena.pnm  -vf format=gbrp test.avi


> 
> 
> As we are approaching the midterm I'll also present my scheduling plans.
> 
>    - Line pool allocator for SwsSlice
>    - Implement ring buffer logic into SwsSlice
>    - Implement horizontal scaling (refactor)
>    - Implement vertical scaling (refactor)
>    - Measure refactor performance/overhead
>    - Document new code
> 

> The horizontal scaling is already working. I did some tests and initially
> the overhead of the new
> code is ~3% (measured only in the modified scaling code) which should be
> almost 0% for total
> program time execution.

how /over what did you meassure the 3% exactly ?
iam asking, so i understand if this performance chnage is irrelevant
or not.
for init code that runs once some speed loss is irrelevant but for
example the horizontal scale code as a whole should not become 3%
slower.
but i do not suggest to do non trivial optimization on this yet.
better get it all working first.


> 
> For the next week (or 2) I plan to implement the line pool allocator and
> the ring buffer logic.
> 
> Besides the scheduling list, with the new scaling design I think it is
> possible to remove the need
> for cascade SwsContexts and also work on some kind of parallelization of
> the scaling code. These I should work after finishing the scheduling.
> 
> [1] 7efb0fae8ed52b6f841d70c4d8981399da42e7bd
> <https://github.com/grandao/FFmpeg/commit/7efb0fae8ed52b6f841d70c4d8981399da42e7bd>
> [2] 0b955f28ab1cbba5188e0cbd44c250dc5b526d53
> <https://github.com/grandao/FFmpeg/commit/0b955f28ab1cbba5188e0cbd44c250dc5b526d53>
> [3] b577b4d388743e6f90f54e65fdb8edddbeaf17de
> <https://github.com/grandao/FFmpeg/commit/b577b4d388743e6f90f54e65fdb8edddbeaf17de>
> [4] f83a83e8ab97e0fcab2248e828d4fb5433e8bcfe
> <https://github.com/grandao/FFmpeg/commit/f83a83e8ab97e0fcab2248e828d4fb5433e8bcfe>
> [5] eaf6de8606b698baaeda1ecb9493a240d5b828e9
> <https://github.com/grandao/FFmpeg/commit/eaf6de8606b698baaeda1ecb9493a240d5b828e9>
> [6] b949d895da80979d44f6525de3a3f9a98118a0a6
> <https://github.com/grandao/FFmpeg/commit/b949d895da80979d44f6525de3a3f9a98118a0a6>
> [7] 353d20df59075d442e943f00c7fcb8bc7784089b
> <https://github.com/grandao/FFmpeg/commit/353d20df59075d442e943f00c7fcb8bc7784089b>

please always attach patches, that makes reviewing them with with
MUAs easy and also keeps them together with any discussions about
them. who knows if the github links will still work in 10 years if
someone tries to debug something and tried to look up old discussions
and patches ...

Thanks

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

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150625/c00d2276/attachment.asc>


More information about the ffmpeg-devel mailing list