Machine Learning for Audio Coding (mlcodec) Working Group
MLCODEC @ IETF 121 in Dublin, Ireland
15:30-17:00 GMT Friday, November 8, 2024 in room Liffey MR2, 1st floor
Chairs: Greg Maxwell, Mo Zanaty
Area Director: Murray Kucherawy
Note Taker: Jonathan Lennox
Join Meeting: https://meetings.conf.meetecho.com/ietf121/?session=33539
Onsite Tool :
https://meetings.conf.meetecho.com/onsite121/?session=33539
Take Notes : https://notes.ietf.org/notes-ietf-121-mlcodec
Chat Room : https://zulip.ietf.org/#narrow/stream/mlcodec
Add Calendar: https://datatracker.ietf.org/meeting/121/session/33539.ics
Agenda
Administrivia - Chairs, 5 min
Note well, agenda bash, draft status
Opus extension mechanism - Timothy Terriberry, 15 min
draft-ietf-mlcodec-opus-extension
Jonathan Lennox: I'm in favor of these proposed changes
Jean-Marc Valin: The only reason not to do this is if there are
middleboxes that need to parse extensions. Generally I'm in favor. It's
not useful for DRED alone but it would be for other extensions.
Jonathan: If middleboxes need to parse extensions they can copy the
libopus code.
Mo: Go ahead and merge the change
Deep REDundancy - Jean-Marc Valin, 15 min
draft-ietf-mlcodec-opus-dred
Jonathan: Suggest all files be archived at IETF/RFC-Editor, not relying
on third parties. (Weights would be Normative, training data would be
Informative.)
Suggest having SHA-256 hashes of all the files in the RFC.
Suggest having script that verifies that weights are stable in the RFC
alongside the scripts that create the weights
Magnus Westerlund: Suggest talking to AD, there are other things that
need megabyte-level storage
Murray: Your AD has the same question
Magnus: It came out of Carsten's work
Speech coding enhancements - Jan Buethe, 30 min
draft-buethe-opus-speech-coding-enhancement
Mo: What are these files in these tests?
Jan: For every one of these samples, you test your decoder vs. the
reference decoder, with the modified opus compare, you cannot increase
your distortion more than a certain amount vs. the reference
implementation
Jonathan: We still need to get the details right, but it seems like it's
in the scope of what the WG should do
Mo: Will this be in libopus 1.6?
Jan: I hope so
Jean-Marc: The reason this is framed as requirements is not because we
want to keep it to ourselves, but rather not to say that what we're
doing now is the be-all end-all, we'll probably be much better in 10
years and don't want to keep having to come back to the IETF
Mo: The WG should take things on to see benefits, if we're going to take
on the requirements we want to see the benefit
Jonathan: I see this as permission to do enhancements, and then let
people do enhancements to the best of their ability
No objection to doing the work, Mo will take it to the list to confirm
adoption
Scalable quality extension - Jean-Marc Valin, 15 min
charter-ietf-mlcodec deliverable #4 new work proposal
Tim: This is a layering mechanism, would more than one layer be
possible?
Jean-Marc: Right now one, more would be possible but a headache, would
only do if there was a demand.
Tim: Will this scale to lossless, or is this out of scope?
Jean-Marc: Scales to 48 lossless, not 96 lossless, and not 24-bit
lossless.
Mo: This would use Tim's extension mechanism?
Jean-Marc: Yes
Jean-Marc will bring a draft to the WG
Optional simplifications - Jean-Marc Valin, 10 min
charter-ietf-mlcodec new deliverable #5 proposal
Jonathan: Would these changes pass Jan's draft earlier?
Jean-Marc: No, probably not, those are mostly for SILK this is for CELT
Jonathan: It seems like it would be better to define this as relaxed
conformance tests than relaxed features per se?
Jean-Marc: This would be hard to do.
Mo: Do you plan to make these things normative changes in the
bitstream?
Jean-Marc: No
Mo: This seems somewhat like a constrained profile
Jean-Marc: Only partially; in other standards, if you don't conform to
the profile, things break. That wouldn't happen here. But signaling for
it might be a good idea.
Mo: Are you asking anything of the working group?
Jean-Marc: I'm asking if I submitted a draft along these lines, would
people support it?
Jonathan: I'd like to see it well-integrated with the conformance
tests, how do I test if I have a conformant Opus decoder if I implement
these simplifications?