Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: exhale - Open Source USAC encoder (Read 311540 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: exhale - Open Source USAC encoder

Reply #902 –
deleted

Re: exhale - Open Source USAC encoder

Reply #903 –
Quote from: kode54 on
Quote from: nu774 on
I don't think GMMP can support xHE-AAC with libfdk-aac:
https://hydrogenaud.io/index.php?topic=118888.msg985925#msg985925
Do what I do, and link libFDK-AAC directly, and not give a shit about licensing or patents until the jackboots are pressed directly to my throat.

Here is for linux if i understand
Maybe open one dedicated topic for users helps to make this ?

Re: exhale - Open Source USAC encoder

Reply #904 –
Hi, everyone! Tried coding xHE with poikosoft - WOW. At low bitrate - so nice results in compare with old HE.
I want to test EXHALE with  Live Streaming! But seems that codec have no support stdout... Any possibilities to add it? That codec would be very interesting for low bitrate live streaming. Wanna test it on my radio stream.
Seems that it is able to read from stdin (required to accept live audio data) but it does not yet have the ability to write the encoded data to stdout (required to send it to a server).  Please, Please! add stdout =)

Re: exhale - Open Source USAC encoder

Reply #905 –
See the last part of www.ecodis.de/exhale/release.htm for a brief explanation why exhale currently doesn't support stdout.

I have no experience with live encoding. Can you summarize your workflow (from microphone to streaming server), i.e. your software toolchain when you do live streaming e.g. using HE-AAC?

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #906 –
I think USAC is not very well suited for MPEG-DASH or HLS.
Basically, each fragment/segment has to start with key frame in these formats. Since most audio codecs don't have a concept of key frames, MPEG-DASH multiplexers usually have to take only video track into account for fragmentation.
However, USAC also requires that fragments start with IPF. This complicates things... and it should be possible only when video/audio encoder are tightly coupled, and can emit key frames in synchronized manner.

As for RTP based streaming, I think it should be possible with MP4A-LATM RTP mapping defined in rfc6416.
However, I guess virtually nothing supports USAC in MP4A-LATM in RTP, currently.

As for supporting stdout output, I think LATM is the only viable option for exhale.

Re: exhale - Open Source USAC encoder

Reply #907 –
Quote from: C.R.Helmrich on
I have no experience with live encoding. Can you summarize your workflow (from microphone to streaming server), i.e. your software toolchain when you do live streaming e.g. using HE-AAC?
i want to try exhale with Breakaway One audio processor (dynamic processor for radiostations and streaming), it can support custom encoders with external exe file, but encoder must support stdin stdout like other encoders do (opusenc.exe, twolame.exe, oggenc2.exe, flac.exe, lame.exe) It would be very interesting to test this codec on the radio stream with proper audio processing before coding (look ahead limiting for example).
radiostations typicaly are not using RTP for internet broadcasting... they are use icecast\shoutcast stream type.

p.s. i wrote to the author on Breakaway (Leif Claesson). He probably can add exhale for testing purposes, but codec should support things that i wrote above. http://www.breakawayone.com/downloads
 

Re: exhale - Open Source USAC encoder

Reply #908 –
Quote from: C.R.Helmrich on
Can you summarize your workflow (from microphone to streaming server), i.e. your software toolchain when you do live streaming e.g. using HE-AAC?
well.. BaOne like Edcast, Butt and other streaming software (BaOne is also audio processor) just pucks up mixed signal (ready onair audio, for example mix of music and microphone, like you can do with any external mixer console or cheap audio interface with loopback feature like audient evo4) , encode that audio with selected codec and bitrate and stream to icecast\shoutcast server. that's all

Re: exhale - Open Source USAC encoder

Reply #909 –
Quote from: nu774 on
I think USAC is not very well suited for MPEG-DASH or HLS.
What makes you think that? One of the primary use cases for xHE-AAC is adaptive streaming, see e.g. https://www.iis.fraunhofer.de/en/ff/amm/broadcast-streaming/xheaac.html and Netflix's use of xHE-AAC.

By the way, when the audio is at 48 kHz, it's possible to perfectly align the xHE-AAC I-frames (IPFs) with those of modern video codecs, which typically use an I-frame every N pictures, where N is an integer multiple of a power of two. For example, if the video is at 50 fps and uses I-frames every 96 pictures (i.e. every 1.92 seconds), then exhale can use an IPF every 45 audio frames. Similarly, if the video is at 60 fps and has an I-frame every 64 or 128 pictures (i.e. every 1.067 or 2.133 seconds), then exhale can write an IPF every 25 or 50 audio frames.

The most important question is which container format the streaming server (Icecast or Shoutcast, I guess) expects from the compressed audio data written to stdout. Is it LATM? (Update: OK, based on this product specification page it seems that ADTS is the container format of choice for Icecast/Shoutcast. Can anyone confirm this?) I thought that's deprecated and fragmented MP4FF should be used. Fraunhofer's web page linked to above probably contains more detailed guidelines, but I haven't read everything there yet.

multimaxfm, can you point me to a manual describing exactly what container format your streaming software of choice expects? Or asked differently: how do you configure your existing HE-AAC encoder executable so that it writes the correctly formatted AAC audio data to stdout? Or does your streaming software already support encoding to HE-AAC out of the box?

Edit: I found this DIY article, which describes how to use FFmpeg to encode a microphone (or line) input to stdout for subsequent live streaming through an Icecast server:

So it seems that everything would become easier if someone integrated exhale or some other xHE-AAC encoder into FFmpeg. I don't have time to do that myself, though.

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #910 –
Quote from: C.R.Helmrich on
how do you configure your existing HE-AAC encoder executable so that it writes the correctly formatted AAC audio data to stdout? Or does your streaming software already support encoding to HE-AAC out of the box?
Here is an example how mp3 lame codec do that thing: "lame.exe -r -s 44100 --alt-preset cbr 128 -q 0 -x - - "

They have documented that function:
LAME 32bits version 3.100 (http://lame.sf.net)
usage: lame.exe [options] <infile> [outfile]
<infile> and/or <outfile> can be "-", which means stdin/stdout.

Other encoders do work almost the same way:
That what i use for aac he encoding: "enc_aacPlus.exe - - --br 64000 --he --pns --silent --rawpcm 48000 2 16"
And Opus Codec also can do this: "opusenc.exe --quiet --bitrate 80.000 --raw --raw-bits 16 --raw-rate 48000 --raw-chan 2 - -"
p.s. All of those codecs accept 16-bit stereo from stdin.

Re: exhale - Open Source USAC encoder

Reply #911 –
Quote from: C.R.Helmrich on
What makes you think that? One of the primary use cases for xHE-AAC is adaptive streaming, see e.g. https://www.iis.fraunhofer.de/en/ff/amm/broadcast-streaming/xheaac.html and Netflix's use of xHE-AAC.
As I've said, xHE-AAC requires IPFs exactly aligned to key frames of video track for fragmentation to work.
Of course I'm not saying it's impossible, but it is still a requirement, and needs specially crafted pipelines not necessary for other audio codecs.
For example, current ffmpeg implementation only takes care of key frames in video track when making fragments in fMP4 (even though it does follow sync samples of audio track when seeking). Nor it does provide a way to align key frames of video / audio tracks.

Re: exhale - Open Source USAC encoder

Reply #912 –
I reconsidered about this, and well, I noticed I was taking things unnecessarily difficult.
I was under an impression that key frame interval of video is not generally static, so I thought dynamic insertion of IPFs on USAC side is necessary to make them in sync.
Indeed, --keyint of x264/x264 usually doesn't make key frame interval static, unless key frame insertion on scene changes is completely disabled.
However I found that ffmpeg supports -force_key_frames option exactly for this.
If key frame interval of video is static, things are much simpler. We just need to pick appropriate intervals for video/audio, and it's done.


Re: exhale - Open Source USAC encoder

Reply #913 –
Exactly. It shouldn't be a problem when the video encoder adds additional key frames, e.g. at scene cuts as you say, as long as key frames are forced at a fixed periodic interval which the audio encoder (here, exhale) can synchronize with.

By the way, if you want to play around with the independency frame interval (i.e. equivalent of the key frame interval in video coding) that exhale uses, you can use the following undocumented "expert" command-line since version 1.1.6:

exhale.exe # s 42 input.wav output.m4a

where # is the usual CVBR mode and 42 is the independency frame interval in number of frames (values between 10 and 99 are allowed). Note that the IPF interval is exactly twice the independency frame interval in exhale.

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #914 –
Quote from: C.R.Helmrich on
So it seems that everything would become easier if someone integrated exhale or some other xHE-AAC encoder into FFmpeg. I don't have time to do that myself, though.
i don't think that ffmpeg is popular for radio broadcast streaming... so it is no easy to make pipeline stdou in exhale?

Re: exhale - Open Source USAC encoder

Reply #915 –
The last time I looked at Exhale, the command line tool, I observed that it isn't really suited to streaming input or output. The encoder library it includes and uses internally may be suited for such, though.

The command line tool seeks around files, and also hand constructs the MP4 container specific to the files it encodes, and again uses seeking to fix up header fields after it finishes encoding.

Re: exhale - Open Source USAC encoder

Reply #916 –
Correct, and I don't see any way around this approach. Writing some data to stdout is easy. Writing fully standard compliant non-MP4 xHE-AAC data to stdout in a way which can be read and played by all xHE-AAC capable decoders is hard.

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #917 –
OK, in my latest commit to exhale's repository I added

- a minor SBR related fix for 22050 Hz input sampling rate (not recommended to use exhale that way, though, use an input sampling rate of 44.1 or 48 kHz for best possible audio quality) and
- the code necessary for writing the xHE-AAC data to stdout (inside a LATM/LOAS container, which aside from fragmented MP4FF is the only allowed format for streaming applications AFAIK).

The stdout capability, however, is still disabled by default since loudness leveling is missing,* only SBR and stereo coding is supported that way, and I have absolutely no means to test the generated streams for correctness. If you have a software player supporting xHE-AAC inside LATM/LOAS, please let me know.

If you want to test the stdout stuff, compile exhale with #define ENABLE_STDOUT_LOAS 1 set at the top of file src/app/exhaleApp.cpp (around line 76, or send me a PM for assistance), and use the following command-line:

exhale.exe a s 42 input.wav -

where 'a' is any SBR preset (a - g), '42' is the I-frame interval as described in my previous post, and '-' signals writing to stdout instead of a file. Under Windows you can append
> output.bin (with a space before the >) to save the result to a file. Also, removing the input.wav from the command-line will trigger reading of the WAVE PCM data from stdin.

* Edit: automatic loudness leveling of the input to -23 LUFS in case of writing to stdout has been added now in a follow-up commit.
Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #919 –
e72c4b1d
SBR  Sounds good.
EZ CD Audio Converter / FLAC or WavPack

Re: exhale - Open Source USAC encoder

Reply #920 –
I'm glad to hear that, but please don't post encodings of entire songs longer than 30 seconds. That's a violation of TOS #9 and, since I don't think you're the copyright holder of that song, several national laws.

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #921 –
ignore / delete post
fixed issue

Re: exhale - Open Source USAC encoder

Reply #924 –
Compiles now at Rarewares with #define ENABLE_STDOUT_LOAS 1 set.