IPB

Welcome Guest ( Log In | Register )

4 Pages V  « < 2 3 4  
Reply to this topicStart new topic
Lossless Extensions for Opus (Backwards Compatible), How to embed lossless deltas inside an Opus stream
C.R.Helmrich
post Mar 29 2013, 15:10
Post #76





Group: Developer
Posts: 681
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



QUOTE (wswartzendruber @ Mar 29 2013, 04:37) *
I'm not going to stop until I see for myself that this will not work well.

This is an exemplary attitude! Sometimes I wish we had a bit more of this in the scientific and engineering world, since it's often the only way to achieve progress.

Honestly, good luck with your project. And please, do let us know about your findings.

Chris


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post
wswartzendruber
post Mar 30 2013, 22:58
Post #77





Group: Members
Posts: 85
Joined: 11-December 06
Member No.: 38563



I'll just use this thread as sort of a log.

Anyway, I've tested Monkey's Audio against Opus residuals at a variety of bitrates and it is proving to be competitive against OptimFROG. Given that I have no idea what lossless codec may eventually be used to compress the residuals, I need to redo the principles of operation to accommodate one that uses variable frame sizes (that is, other than 60 ms, which I have been assuming up until now). It is highly likely that there will be many Opus packets for each delta packet, and this ratio is likely to vary throughout a stream.
Go to the top of the page
+Quote Post
Dynamic
post Mar 31 2013, 10:54
Post #78





Group: Members
Posts: 793
Joined: 17-September 06
Member No.: 35307



With mention of an open lossy codec being a requirement, the other option is Ogg Vorbis, which supports specific sampling rates and isn't too far behind Opus in bitrate efficiency and is an open format that has fairly widespread support in the wild (main exception being Apple, despite Wikipedia's use of Vorbis). Then you have no worry about resampling consistently so that the hybrid remains lossless. You then just need to presumably place non-Vorbis packets in the Ogg stream that all Vorbis decoders (except your hybrid decoder) will ignore. Presumably it would also be easy to strip out only Vorbis packets from the Ogg stream to obtain a smaller lossy file.

The other option where sampling rate can be specified and still be expected to play is Xiph.org's CELT (forerunner to the CELT half of Opus you're thinking of), but plain CELT decoder support in the wild is very limited and will very likely remain so now Opus has superceded it, even though I believe Google's plugin for Chat/Hangouts uses CELT in its new Studio mode (click Learn More in this link) and will possibly implement Opus in due course, possibly piggybacking on WebRTC integration.

On the positive side for Opus, it's possible that being standardized by IETF with clearly specified open patent licensing, support will eventually surpass that of Vorbis.
Go to the top of the page
+Quote Post
Destroid
post Mar 31 2013, 11:55
Post #79





Group: Members
Posts: 544
Joined: 4-June 02
Member No.: 2220



Dynamic's suggestion is very interesting. In addition to the points mentioned there are a few other things I wanted rehearse here:

- former lossless Vorbis [q 10] discontinued;
- new iteration of Vorbis, possibly ditched due to Ghost/OPUS and the possibility of broken compatibility;
- the AoTuV project low-bitrate settings (q-1, q-2) sounded better to me than Speex at comparable bitrate, IMO.


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
wswartzendruber
post Mar 31 2013, 15:40
Post #80





Group: Members
Posts: 85
Joined: 11-December 06
Member No.: 38563



One of the main reasons for choosing Opus is because of the IETF standardization Dynamic mentioned. Also, Opus lets me extend it at the sub-container level. There should be no reason a lossless/hybrid stream can't be placed in any container that can handle standardized Opus. My hybrid encoder API so far is completely container agnostic.

This post has been edited by wswartzendruber: Mar 31 2013, 15:40
Go to the top of the page
+Quote Post
wswartzendruber
post Apr 1 2013, 22:52
Post #81





Group: Members
Posts: 85
Joined: 11-December 06
Member No.: 38563



Florin got back to me. He's just in a bit of a personal dilemma and estimates reviewing my comments in one week.

This post has been edited by wswartzendruber: Apr 1 2013, 22:52
Go to the top of the page
+Quote Post
wswartzendruber
post Apr 19 2013, 06:38
Post #82





Group: Members
Posts: 85
Joined: 11-December 06
Member No.: 38563



One week, right. I think he's in a bit more of a jam than he admitted.

Whatever. As soon as libopus-1.1 comes out, I'm gonna start gutting the tree until I have a fixed-point decoder and nothing else.
Go to the top of the page
+Quote Post
wswartzendruber
post Aug 9 2013, 22:24
Post #83





Group: Members
Posts: 85
Joined: 11-December 06
Member No.: 38563



QUOTE (wswartzendruber @ Apr 19 2013, 01:38) *
One week, right. I think he's in a bit more of a jam than he admitted.

Whatever. As soon as libopus-1.1 comes out, I'm gonna start gutting the tree until I have a fixed-point decoder and nothing else.

All right, now that I've graduated from college (Bachelor in Computer Science) and have myself a job, I can get back to the task at hand. After having thought about this for a while, I think the best answer may just be to implement my own Opus (CELT) decoder in fixed-point arithmetic. This is going to really suck, but I need stability with a base I understand. I also don't see myself needing the SILK parts of the reference implementation. I should know more this weekend after I've gone over the appropriate parts of the RFC.
Go to the top of the page
+Quote Post
wswartzendruber
post Nov 30 2013, 21:08
Post #84





Group: Members
Posts: 85
Joined: 11-December 06
Member No.: 38563



Florin finally got back to me! He's been all tied up with real-life stuff. Moving and whatnot. He still seems determined to help. I won't share what he told me because I don't have his permission to do so, but I'll share what I said to him:

QUOTE
Hi Florin,

I'm on my tablet so I won't type a lot. I have outlined some main points below.

1. Thank you for getting back to me.

2. I am in the United States (California).

3. I have determined that we should have our own implementations of Opus.

4. We only need the MDCT-based CELT layer.

5. I don't know how to do any of this, so I am learning from the ground up. I have just finished, as practice, my first FFT implementation, and then used that to create (from scratch) an FFT-based convolver that uses overlap-and-add. In the coming days I will move onto learn and implement the MDCT transform.

6. I hate Jean-Marc for trying to shoot this down so fast, but he has a point. Extension packets need to be standardized first.

7. I've lost the work I did, but it wasn't applicable anyway. I've since started using Git.

8. I still have every intention of making this happen.

9. You can track my learning progress here: https://github.com/wswartzendruber/logic/

-William
Go to the top of the page
+Quote Post

4 Pages V  « < 2 3 4
Reply to this 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: 17th April 2014 - 17:55