Re: [Freetel-codec2] Updating the libcodec2 binding in FFmpeg, fixed-point decoding

2023-12-27 Thread glenlist
I would think, that a floating pt implementation  on a soft FPGA 
processor core with floating point would take less area that a purely 
FPGA fixed point HDL implementation. The reason is that the amount of 
work required to do (in terms of computations per cycle) does not really 
take advantage of the parallelism of an FPGA . and a basic soft core 
with an FPU can easily run fast enough on even the slowest FPGA fabric 
around


However, I suspect that codec2 could easily work within small fractional 
integer space (32 to 40 bit) without changes, and not have any scaling 
issues and be completely scaling free in a 64 bit fractional integer space.


My usual rule - if it can be run in a high level language in software, 
then don't do it in fpga fabric as HDL  ... probably applies.


I'm currently implementing codec2  for RISC-V (F) in floating point. In 
many RISC-V implementations, there is  the facility to generate in the 
HDL custom instructions that can be inserted into the code which can 
provide , for example, vector speedups.


In my opinion, There's a good reason though not to go too far from 
'reference C code' if possible, unless, for example there are struct 
power consumption limits- as changes to the mainline become slower 
and more difficult to propagate into different platforms if someone 
needs to spend the time to (heavily) optimize.


If the use of fixed point requires regular scaling, it probably becomes 
a pain to be linked to the mainline reference code unless the scaling 
requirements are scripted and automatic.  This breathes light for me 
into thinking about a purely 64bit fractional ALU fractional implementation.


In the RISCV -custom instruction support , one could add fractional ALU 
instructions that MACRO out the std asm to hide the shifts from the 
programmer and compiler.



-glen

On 28/12/2023 7:36 am, Mooneer Salem wrote:

Hi Tomas,

Someone did a FPGA implementation a while back for a university 
project. That's the closest we've gotten to a fixed-point 
implementation. Right now, there are no plans to port it officially 
but this may be revisited later.


Thanks,

-Mooneer K6AQ




___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2


Re: [Freetel-codec2] Updating the libcodec2 binding in FFmpeg, fixed-point decoding

2023-12-27 Thread david
Hi Tomas,

Thanks for that work.  1.2 was clean up of the Git repo, so nothing
much has changed in terms of functionality.  We have no plans for a
fixed point version.  The .c2 file format is a corner use-case (we
focus mainly on the HF radio use case), but we have no plans to change
it.

A road map of what is currently placed for the entire FreeDV project
(which includes Codec 2) is here:

https://freedv.org/2023/11/30/ardc-grant-project-plan/

Do you have any way of measuring how many people are using the Codec 2
option in FFmpeg?

We have been looking into the use of the freedv-gui application (which
uses libcodec2) in various repos and found no evidence of the packaged
versions of freedv-gui actually being used.  The number of package
maintainers seems to to outnumber the end users.

We are interested in auditing the use of freedv-gui and Codec 2 to best
direct our efforts.  For example there is no point supporting package
maintainers if no one is using the packages - best to direct our
limited resources elsewhere.

I find it interesting that package maintenance is such a popular hobby
- we get more correspondence/requests for help on this topic than say
the DSP side of Codec 2 (where I like to play).

Thanks,
David

On Wed, 2023-12-27 at 18:48 +0100, Tomas Härdin wrote:
> Hi
> 
> I see codec2 has now reached version 1.2.0. I'm working on updating
> the
> libcodec2 binding in libavformat in FFmpeg accordingly.
> 
> So far I've been conservative, only allowing major version 0 and
> requiring version to be >= 0.8. So in effect versions 0.8 to 0.255.
> Now
> that 1.X is out I'm updating libavformat accordingly. Fortunately the
> .c2 format hasn't changed, so this is more of a heads up to be
> careful
> not to make breaking changes to the format :)
> 
> In effect what I'm doing is allowing versions 0.8 through 1.255.
> 
> I'm also adding tests to FFmpeg's testing system FATE. So far these
> tests are quite basic, only checking metadata rather than the actual
> decoded audio. This because libcodec2 uses floating point arithmetic.
> At some time I'd like to improve that. Are there any plans to
> implement
> a fixed-point decoder? I remember seeing some chatter about that.
> 
> /Tomas
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2


Re: [Freetel-codec2] Updating the libcodec2 binding in FFmpeg, fixed-point decoding

2023-12-27 Thread Mooneer Salem
Hi Tomas,

Someone did a FPGA implementation a while back for a university project.
That's the closest we've gotten to a fixed-point implementation. Right now,
there are no plans to port it officially but this may be revisited later.

Thanks,

-Mooneer K6AQ

On Wed, Dec 27, 2023 at 10:11 AM Tomas Härdin  wrote:

> Hi
>
> I see codec2 has now reached version 1.2.0. I'm working on updating the
> libcodec2 binding in libavformat in FFmpeg accordingly.
>
> So far I've been conservative, only allowing major version 0 and
> requiring version to be >= 0.8. So in effect versions 0.8 to 0.255. Now
> that 1.X is out I'm updating libavformat accordingly. Fortunately the
> .c2 format hasn't changed, so this is more of a heads up to be careful
> not to make breaking changes to the format :)
>
> In effect what I'm doing is allowing versions 0.8 through 1.255.
>
> I'm also adding tests to FFmpeg's testing system FATE. So far these
> tests are quite basic, only checking metadata rather than the actual
> decoded audio. This because libcodec2 uses floating point arithmetic.
> At some time I'd like to improve that. Are there any plans to implement
> a fixed-point decoder? I remember seeing some chatter about that.
>
> /Tomas
>
>
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2


[Freetel-codec2] Updating the libcodec2 binding in FFmpeg, fixed-point decoding

2023-12-27 Thread Tomas Härdin
Hi

I see codec2 has now reached version 1.2.0. I'm working on updating the
libcodec2 binding in libavformat in FFmpeg accordingly.

So far I've been conservative, only allowing major version 0 and
requiring version to be >= 0.8. So in effect versions 0.8 to 0.255. Now
that 1.X is out I'm updating libavformat accordingly. Fortunately the
.c2 format hasn't changed, so this is more of a heads up to be careful
not to make breaking changes to the format :)

In effect what I'm doing is allowing versions 0.8 through 1.255.

I'm also adding tests to FFmpeg's testing system FATE. So far these
tests are quite basic, only checking metadata rather than the actual
decoded audio. This because libcodec2 uses floating point arithmetic.
At some time I'd like to improve that. Are there any plans to implement
a fixed-point decoder? I remember seeing some chatter about that.

/Tomas


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2