FFV1 CUDA accelerated version

[lp35]

Hi,

Not sure I'm at the right place to ask this question, but I would like to know if there is any implementation of FFV1 available for CUDA.

If not, do you have any advice on the complexity/feasibility of porting FFV1 on CUDA platform? Is it highly parallelizable?

Don't hesitate to point me to other online resources/repo/person if I'm not at the right place!

Thanks for your time

[JeromeMartinez]

I would like to know if there is any implementation of FFV1 available for CUDA.

AFAIK there is no CUDA implementation but this is on my todo-list.
This is definitely something we need to do as HDTV or 2K are now used with FFV1 and basic CPU processing is not enough for current CPUs, even with multi-thread.

If not, do you have any advice on the complexity/feasibility of porting FFV1 on CUDA platform? Is it highly parallelizable?

I expect that it is highly parallelizable on lot of parts, but the range coder (which consumes the biggest part of the time) may be more tricky to parallelize, we'll know the gain only when it is implemented.

[retokromer]

We use an in-house implementation of FFV1 on CUDA (GeForce) on a daily basis since before the pandemic.

The parallelisation could be improved by modifying a little the bitstream syntax.

[lp35]

Thank you for your feedback!

@retokromer: Have you considered to put it in the public domain? If not, do you have an estimation of developper.hour for the development? Can you give a bit more details regarding what you are encoding (resolution/FPS) and which performance you get?

I'm also considering VC-2 as a codec, but FFV1 exists for a long time and seems to be de-facto standard in the video industry. However, VC-2 website provides a good overview of the performance/compression ratio that's achievable. Do you know where I can find such resource for FFV1?

[retokromer]

Have you considered to put it in the public domain?

Yes, that’s the plan. Yet no schedule is set, as I do this in my spare time.

Do you know where I can find such resource for FFV1?

I guess @pjotrek-b and @digitensions have some.

On my end, I did prepare figures for NTTW4 in 2019 at Budapest, but I could finally not attend, because of a date conflict. One of the aspects I did explore was the influence of the -slices flag on encoding time and file size.

[JeromeMartinez]

Do you know where I can find such resource for FFV1?

We compared FFV1 with JPEG-2000 in a study few years ago.

An old but still relevant study compares FFV1 with a couple of other more or less open lossless formats (but not VC-2/Dirac), here is an excerpt:

There is also a quick study including formats requiring royalties.

That said, we definitely lack of up to date comparison charts about speed and compression.

[lp35]

Have you considered to put it in the public domain?

Yes, that’s the plan. Yet no schedule is set, as I do this in my spare time.

We might put some resources internally on this project, is there anything we can do to make things happen?

On my end, I did prepare figures for NTTW4 in 2019 at Budapest, but I could finally not attend, because of a date conflict. One of the aspects I did explore was the influence of the -slices flag on encoding time and file size.

Great, do not hesitate to share, I will start experiementation with FFV1 next week :)

We compared FFV1 with JPEG-2000 in a study few years ago.

This document is gold, thank you for sharing your work! Maybe it can found its place in the Wiki section of this repo?

An old but still relevant study compares FFV1 with a couple of other more or less open lossless formats (but not VC-2/Dirac), here is an excerpt:

Found this one, but I guess every codec have evolved since then!

[pjotrek-b]

How exciting! 😄

@lp35: My performance stats @retokromer refers to can be found here:
http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/

Since they were generated for/during development of FFV1.2+, they're not only dated (2012) but also a bit hard to read.

In a nutshell:
They list compression gain for 2 different things:

1. Different encoding parameters (compared to uncompressed)
2. GOP=1 vs GOP=300

[dericed]

Have you considered to put it in the public domain?

Yes, that’s the plan. Yet no schedule is set, as I do this in my spare time.

Do you know where I can find such resource for FFV1?

I guess @pjotrek-b and @digitensions have some.

On my end, I did prepare figures for NTTW4 in 2019 at Budapest, but I could finally not attend, because of a date conflict. One of the aspects I did explore was the influence of the -slices flag on encoding time and file size.

Hi @retokromer, IIUC the FFV1 implementation that you authored is currently the only GPU accelerated version. Could you consider publishing your implementation with an open license. I think an open GPU based FFV1 encoder would be incredibly helpful, but want to prevent redundant work.

[retokromer]

Could you consider publishing your implementation with an open license.

@dericed That is indeed the plan! אַ גוט געבענטשט יאָר

[pjotrek-b]

Cool. 😎

[retokromer]

@dericed What is your deadline? Can this wait until February?

[dericed]

@retokromer could you share if your GPU based FFV1 encoder supports range coding or is it just golomb rice?

[retokromer]

@dericed I am actually a big fan of arithmetic coding, and indeed we have implemented range coding.

[dericed]

Hi @retokromer, with your implementation of range coding in GPU did you implement 10-16 bit coding? If so, did you notice any substantial change to the compression ratio? Did you adjust any technique in slice size to go about this?

[pjotrek-b]

@retokromer: cool. 😎
You've actually written your own FFV1-on-GPU code (patch for ffmpeg)?
Wow.