Hi Rostislav et all, The IETF document has just been moved to a working group last call.
Do you think it would it be possible to land this patch under an experimental flag? Cheers, Drew On Mon, Apr 23, 2018 at 12:28 PM Rostislav Pehlivanov <atomnu...@gmail.com> wrote: > On 23 April 2018 at 17:02, Drew Allen <bitllama-at-google....@ffmpeg.org> > wrote: > > > We have spent the past 2 years with the draft relatively unchanged aside > > from minor edits on the draft. It is headed to a working group for > > finalization very soon and no one has yet raised a single issue regarding > > any proposed changes that this patch introduces. I wrote the > > OpusProjection* API and it has been adopted in all Opus-related xiph > master > > branches. > > > > Good to hear. I know the IETF can take an extraordinarily long amount of > time to publish a draft and make it an RFC and wish you all the luck on > getting it completed quickly. > > > I worked closely with Jean-Marc Valin to design the API in Opus 1.3 to his > > specification. Opus 1.3 beta already contains this new API and upon > > release, I have 100% assurance from Jean-Marc that the OpusProjection* > API > > will be supported in 1.3 RC. > > > > ...hidden behind a configure flag and not enabled by default. No one will > enable it until its ready and becomes accepted, which is why it isn't > enabled by default. > > > > > I disagree that a filter or some other layer of abstraction is necessary > > here. OpusProjection* does not code the ambisonic channels directly. > > Instead, they are mixed using a mixing matrix that minimizes coding > > artifacts over the sphere. The demixing matrix on the decoder is vital in > > order to get back the original ambisonic channels and > OpusProjectionDecoder > > handles this automatically. > > > > Ah, okay. In which case what we need still is an API to signal the > ambisonics order and any other metadata needed. We can't just say "here's a > frame with a bunch of channels, based on their numer you could probably > figure its some ambisonics" and clients shouldn't use heuristics like "this > frame has 16 channels, its probably ambisonics". This information needs to > be indicated properly. > > > I completely disagree. The IETF draft has been stable for over a year and > > these same changes to support the new API are already present in Opus, > > libopusenc, opusfile and opus-tools. > > > Stable != accepted. The option to enable the API is still hidden behind a > configure flag for libopus. And it will remain like this until it becomes > an RFC, just like the previous RFC which butc... updated the codec with > some fixes. > > If libopus had the new API enabled by default I wouldn't mind this patch at > all and would apply it, since I'd be sure it wouldn't change. But as it > stands, both it and the signalling changes in the RFC can change at any > time despite being stable by yourself. > > Also your mail client stripped the quote marks and made things confusing. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
