IPB

Welcome Guest ( Log In | Register )

23 Pages V  « < 19 20 21 22 23 >  
Closed TopicStart new topic
IETF Opus codec now ready for testing, That's CELT 0.11
LoRd_MuldeR
post Nov 24 2012, 14:07
Post #501





Group: Members
Posts: 10
Joined: 24-April 11
Member No.: 90061



QUOTE (lvqcl @ Nov 24 2012, 03:30) *
Probably --rate 48000 will do the trick.


Does Opus really always use exactly 48.000 Hz internally, even for "speech" footage with input rates as low as 8.000 Hz? blink.gif

And, if so, does "--rate 48000" really ensure, under all circumstances, that the resampler won't get invoked? If so, maybe just make "--no-resample" and alias for "--rate 48000", for clarity.

Regards.

Go to the top of the page
+Quote Post
Caroliano
post Nov 24 2012, 14:31
Post #502





Group: Members
Posts: 67
Joined: 21-December 05
Member No.: 26559



As opus AWAYS resample to 48kHz, a "--no-resample" switch will certainly cause confusion for those who don't know that. I think there may be a better name. Maybe "--native-rate", "--rate internal", "--encoded-rate", or something like that.
Go to the top of the page
+Quote Post
LoRd_MuldeR
post Nov 24 2012, 16:58
Post #503





Group: Members
Posts: 10
Joined: 24-April 11
Member No.: 90061



QUOTE (Caroliano @ Nov 24 2012, 14:31) *
As opus AWAYS resample to 48kHz


Thanks for confirming.


QUOTE (Caroliano @ Nov 24 2012, 14:31) *
a "--no-resample" switch will certainly cause confusion for those who don't know that. I think there may be a better name. Maybe "--native-rate", "--rate internal", "--encoded-rate", or something like that.


Anything like that would be welcome.

This post has been edited by LoRd_MuldeR: Nov 24 2012, 17:36
Go to the top of the page
+Quote Post
lvqcl
post Nov 28 2012, 20:24
Post #504





Group: Developer
Posts: 3218
Joined: 2-December 07
Member No.: 49183



Current git version -- v1.0.1-154-g07418d9

This post has been edited by lvqcl: Dec 22 2012, 15:28
Go to the top of the page
+Quote Post
.alexander.
post Dec 5 2012, 09:01
Post #505





Group: Members
Posts: 73
Joined: 14-December 06
Member No.: 38681



Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz sample rate. Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax? Could this be related to transition between SILK and CELT modes? AAC syntax has very minor difference between 32 and 48KHz, basically it's all about mapping bark scale to scale factor bands. Header and side info overhead would be 1.5 times larger for up-sampled signal so it'd probably be better to encode 32KHz signal as 24KHz. What would you expect from OPUS in case it'd be configured for 24KHz to encode 32KHz?
Go to the top of the page
+Quote Post
Speckmade
post Dec 5 2012, 14:24
Post #506





Group: Members
Posts: 36
Joined: 15-February 05
Member No.: 19848



QUOTE (.alexander. @ Dec 5 2012, 10:01) *
Opus cannot encode 32KHz signals

Maybe this is the most frequent confusion with Opus. Try Google for more on this.
Short answer: Opus always works with 48 kHz internally, though it happily takes input and gives output of any rate you like through internal sampling rate conversion. Opus is a little different than other transform codecs and you should probably think of it as being rateless.
Go to the top of the page
+Quote Post
IgorC
post Dec 5 2012, 14:40
Post #507





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



QUOTE (.alexander. @ Dec 5 2012, 05:01) *
Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot ...

http://lmgtfy.com/?q=opus+32+kHz+%20webrtc
Go to the top of the page
+Quote Post
NullC
post Dec 5 2012, 16:31
Post #508





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (.alexander. @ Dec 5 2012, 01:01) *
Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz
Don't confuse the WebRTC standard and Google's legacy codebase. In the codebase IIRC existing usage of opus there just hooks up a resampler to front end it, but ultimately I presume their code will be fixed. I've prodded some people who are more involved with WebRTC to get an update on whats going on with the google codebase, as I haven't been following it.

QUOTE
sample rate. Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax? Could this be related to transition between SILK and CELT modes?
It's related to a couple things, primarily the ability to seamlessly switch between all supported modes and having no possibility of negotiation failure (e.g. remote end only supports 48kHz and your end only supports 32kHz) and also rom and ram size (no separate tables needed for other modes) and what works for computationally cheap internal resampling. It has the benefit that if you're playing a stream from one opus source and the source changes you can just switch to it without upsetting your audio pipeline... or if the network bandwidth changes the codec can make optimal use of whatever is available without a glitchful pipeline interruption.

If an application needs a specific rate for the codec it can always resample, and a reasonably well constructed resampler is perceptually lossless and also quite fast. If opus "supported" more rates thats all it would be doing in any case (and thats effectively what it does for the current supported rates— though they are chosen so that some especially inexpensive handling can be done internally)— as the codec itself doesn't really have a rate in the encoded form (except for the _frame rate_ of 25/50/100/200/400Hz). As far as bitstream bits go... There aren't any bits in the payload for any sampling rates _at all_, though are bits that signal the signals bandpass, which line up with the supported rates, though these can change on a frame by frame basis depending on the content. Bits aren't free, you know— especially when you can emit 400 frames per second in lower latency modes. tongue.gif

This post has been edited by NullC: Dec 5 2012, 16:41
Go to the top of the page
+Quote Post
derf_
post Dec 5 2012, 17:24
Post #509





Group: Developer
Posts: 9
Joined: 5-December 12
Member No.: 104986



QUOTE (.alexander. @ Dec 5 2012, 09:01) *
Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz sample rate.


Right, this is a limitation of the webrtc.org code. It's slowly being addressed, and eventually the whole stack should support 48 kHz.

QUOTE (.alexander. @ Dec 5 2012, 09:01) *
Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax?


As speckmade alluded to, Opus works somewhat differently than most codecs. Because of its focus on communications, it's designed to have no "negotiation failure", i.e., any encoded Opus packet can be decoded without having to know the settings the encoder was configured with. This includes sampling rate. In order to have this work in a relatively simple way, all of the rates it does support evenly divide 48 kHz (consider what would have to be done to make things work if one packet wanted 48 kHz and the next wanted 44.1 kHz, in a codec with MDCT's windowed overlap-adding).

We evaluated supporting 32 kHz very carefully, but in addition to the complexity a) it doesn't match the band layout of the MDCT layer very well (the cutoff lies in the middle of the highest band), and changing that band structure would have hurt the other audio bandwidths, and b) it doesn't save very many bits over just using fullband. Opus spends so few bits on the high bands at typical super-wideband bitrates that the savings is actually comparable to the overhead needed to signal it. Each packet must be independently decodable, so those "2 more bits" you ask for would have to be included in every one. Even if you omitted the highest band completely, at these rates we are usually only encoding its energy, and that is predicted from past frames and lower bands, so it typically only needs 1 to 1.5 bits/channel per packet to begin with.

QUOTE (.alexander. @ Dec 5 2012, 09:01) *
AAC syntax has very minor difference between 32 and 48KHz, basically it's all about mapping bark scale to scale factor bands.


Yes, and this is how Opus Custom (the old, more configurable CELT layer) works, but it gives up many of the other properties we wanted, and makes the implementation more complex (for example, the Rockbox people have started contributing decoder optimizations which simply wouldn't work with Opus Custom). For these and many other reasons, we don't recommend people actually use Opus Custom unless they have very specialized hardware that requires particular frame sizes or sampling rates, and don't have to interoperate with anyone else.

QUOTE (.alexander. @ Dec 5 2012, 09:01) *
Header and side info overhead would be 1.5 times larger for up-sampled signal so it'd probably be better to encode 32KHz signal as 24KHz. What would you expect from OPUS in case it'd be configured for 24KHz to encode 32KHz?


Given what I said above, I would recommend encoding a 32 kHz signal as fullband. I don't know what you mean by "header overhead"... the header sizes are independent of the audio bandwidth. Opus also does not include any per-sample side information and, as I said above, the actual extra rate required to go from 32 kHz to 48 kHz is pretty small. This is the approach taken to supporting Opus in the webrtc.org code until it gets full support for 48 kHz sampling rates. You can see that in the patch that is currently the first result of IgorC's link.
Go to the top of the page
+Quote Post
.alexander.
post Dec 10 2012, 10:50
Post #510





Group: Members
Posts: 73
Joined: 14-December 06
Member No.: 38681



Thanks! Opus design really benefits from lack of 32 KHz support. Though solutions that have jitter buffer as primary source of latency may not need 400 packets per second. Upsampling by 3 and 1.5 is almost the same, I looked into your code and gave up with impression that there is no explicit upsampling and inventing pruned MDCT to avoid some resampling latency is overkill. Do you have any expectations of change in average call duration with switch from ISAC to Opus? Design goals and subjective tests are good, but what if call duration would drop on a very big sample?
Go to the top of the page
+Quote Post
bawjaws
post Dec 11 2012, 12:53
Post #511





Group: Members
Posts: 173
Joined: 10-December 02
Member No.: 4043



QUOTE (.alexander. @ Dec 10 2012, 01:50) *
Design goals and subjective tests are good, but what if call duration would drop on a very big sample?


I can't find the link right now but I think Skype (who were involved in creating Opus) did this exact test and found it was a positive change (at least compared with previous codec, which might have been Silk alone, or their previous codec, not sure)
Go to the top of the page
+Quote Post
jossilint
post Dec 17 2012, 21:58
Post #512





Group: Members
Posts: 5
Joined: 2-August 12
Member No.: 101956



I tested and at least to me ffmpeg FDK-AAC(he-v2) 40Kbps vbr sounds better than opus(0.1.6) 40Kbps vbr ? any thoughts? can opus defeat aac-he-v2 at low bitrates, i even found one internet radio with opus test, if admins allow i post link here.

This post has been edited by jossilint: Dec 17 2012, 22:02
Go to the top of the page
+Quote Post
saratoga
post Dec 17 2012, 22:08
Post #513





Group: Members
Posts: 4718
Joined: 2-September 02
Member No.: 3264



QUOTE (jossilint @ Dec 17 2012, 16:58) *
I tested and at least to me ffmpeg FDK-AAC(he-v2) 40Kbps vbr sounds better than opus(0.1.6) 40Kbps vbr ? any thoughts?


How did you compare?
Go to the top of the page
+Quote Post
Seren
post Dec 17 2012, 22:22
Post #514





Group: Members
Posts: 48
Joined: 1-November 12
Member No.: 104244



I find you need to be over 48kb/s for opus for stereo music. HE seems to sound better just below that, though you can always drop the opus encode to mono and it'd sound better than the HE-AAC below 48kb/s. Well these are my findings based on a few listens, no real ABX'ing so it may be different for others.
Go to the top of the page
+Quote Post
Gainless
post Dec 22 2012, 12:36
Post #515





Group: Members
Posts: 169
Joined: 28-October 11
Member No.: 94764



New alpha version has been released:
Link

Can someone compile it?
Go to the top of the page
+Quote Post
Nekit1234007
post Dec 22 2012, 12:49
Post #516





Group: Members
Posts: 12
Joined: 26-February 12
Member No.: 97404



Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493
Go to the top of the page
+Quote Post
Seren
post Dec 22 2012, 15:00
Post #517





Group: Members
Posts: 48
Joined: 1-November 12
Member No.: 104244



QUOTE (Nekit1234007 @ Dec 22 2012, 19:49) *
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

Doesn't work on AMD Athlon x2. "opusenc has stopped working"
Go to the top of the page
+Quote Post
lvqcl
post Dec 22 2012, 15:31
Post #518





Group: Developer
Posts: 3218
Joined: 2-December 07
Member No.: 49183



MSVC compile; requires WinXP and SSE processor.

[obsolete; removed]

This post has been edited by lvqcl: Feb 13 2013, 23:01
Go to the top of the page
+Quote Post
jmvalin
post Dec 22 2012, 17:24
Post #519


Xiph.org Speex developer


Group: Developer
Posts: 473
Joined: 21-August 02
Member No.: 3134



For those interested, here's a blog post that describes what's in this alpha in more details.
Go to the top of the page
+Quote Post
Nick.C
post Dec 22 2012, 19:21
Post #520


lossyWAV Developer


Group: Developer
Posts: 1774
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



From the blog regarding the revised VBR constraints - does this mean that the output is tending towards constant quality rather than constant bitrate?

btw: I've been listening to 96kbit/s OPUS output on my RockBoxed Sansa Fuze and am very pleased with what I hear....


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
jmvalin
post Dec 22 2012, 19:55
Post #521


Xiph.org Speex developer


Group: Developer
Posts: 473
Joined: 21-August 02
Member No.: 3134



QUOTE (Nick.C @ Dec 22 2012, 13:21) *
From the blog regarding the revised VBR constraints - does this mean that the output is tending towards constant quality rather than constant bitrate?


Correct.
Go to the top of the page
+Quote Post
ErectX
post Dec 23 2012, 01:57
Post #522





Group: Members
Posts: 10
Joined: 8-September 10
Member No.: 83706



QUOTE (Seren @ Dec 22 2012, 06:00) *
QUOTE (Nekit1234007 @ Dec 22 2012, 19:49) *
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

Works for me on a Core2. Do you have a 64-bit OS?

1st Athlon x2 - Manchester:
MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit

Core2 Quad Kentsfield:
MMX, SSE, SSE2, SSE3, SSSE3, Enhanced Intel SpeedStep Technology (EIST), Intel 64, XD bit (an NX bit implementation), iAMT2 (Intel Active Management), Intel VT-x

I have noticed a glitchiness in otherwise stellar 32kbps stereo 24KHz on this build. With radio (voice plus occasional music behind talking), sometimes there will be pronounced audio glitches or popping in one channel, they stand out using headphones because of easy localization vs center voice (they appear to be in the audio stream as repeating the audio gives the same glitches, but I haven't extensively researched yet to verify it's not player-specific to Rockbox Clip+). Also transitions from mono to stereo with a bit of background stereo music in this mode are less then transparent.

I also noted in 1.0.1 (but haven't re-evaluated for improvement with 1.1A yet), that the stream predictor means that you don't get the same audio twice, not at all. Encoding a file with the same two minutes repeated gets you different encoding results two minutes later in the stream. Using 21kbps with -6dB voice there was about one minute of lowpass at 8KHz at the start of the file, when the audio repeated it had 12KHz bandwidth, very visible and audible. Increasing to 22kbps or increasing the source audio level altered the bandwidth allocations but still was quite different on repeated encoding depending on where in the file it was. Perhaps a two-pass encoding or a very large pre-skip, preloading the first minute to train the encoder, would help this.
Go to the top of the page
+Quote Post
Seren
post Dec 23 2012, 03:09
Post #523





Group: Members
Posts: 48
Joined: 1-November 12
Member No.: 104244



QUOTE (ErectX @ Dec 23 2012, 08:57) *
QUOTE (Seren @ Dec 22 2012, 06:00) *
QUOTE (Nekit1234007 @ Dec 22 2012, 19:49) *
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

Works for me on a Core2. Do you have a 64-bit OS?

1st Athlon x2 - Manchester:
MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit

Core2 Quad Kentsfield:
MMX, SSE, SSE2, SSE3, SSSE3, Enhanced Intel SpeedStep Technology (EIST), Intel 64, XD bit (an NX bit implementation), iAMT2 (Intel Active Management), Intel VT-x


Sorry, I kinda screwed that up, I meant "Athlon II" (x2 245 using MMX(+), 3DNow!(+), SSE(1,2,3,4A), x86-64, AMD-V)
Win7 x64.

This post has been edited by Seren: Dec 23 2012, 03:10
Go to the top of the page
+Quote Post
Gainless
post Dec 23 2012, 11:23
Post #524





Group: Members
Posts: 169
Joined: 28-October 11
Member No.: 94764



QUOTE (lvqcl @ Dec 22 2012, 15:31) *
MSVC compile; requires WinXP and SSE processor.

Thanks!

It seems like the new alpha version performs worse on certain stuff than Opus tools 0.1.6, e.g on the Muse Breaks and Sycho Active samples (can be found here and here), obvious glitches at 192 kbps, while OT is pretty much transparent there.

This post has been edited by Gainless: Dec 23 2012, 11:28
Go to the top of the page
+Quote Post
ErectX
post Dec 23 2012, 18:02
Post #525





Group: Members
Posts: 10
Joined: 8-September 10
Member No.: 83706



QUOTE (Seren @ Dec 22 2012, 06:00) *
QUOTE (Nekit1234007 @ Dec 22 2012, 19:49) *
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

It looks like the one instruction set missing is SSSE3 (http://en.wikipedia.org/wiki/SSSE3#CPUs_with_SSSE3) which is only on AMD Bulldozer+/Core2+. I don't have 64bit OS on my non-SSSE3 Intel (P4 Prescott MMX, SSE, SSE2, SSE3, Hyper-Threading, Intel 64, XD bit) to check this binary. Perhaps Nekit1234007 can detail what the "crazy parameters" were.

This build runs about 5% faster than Mozilla opus-tools, so no complaints.
Go to the top of the page
+Quote Post

23 Pages V  « < 19 20 21 22 23 >
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd April 2014 - 11:49