[AVTCORE] Re: Design question about the V3C codec

["Lukasz Kondrad (Nokia)" <[e-mail]>]

Dear Jonathan,
Thank you very much for the review.

When a V3C-capable offerer sends an offer to a V3C-ignorant answerer, the answerer will ignore the V3C atlas codec and V3C-related parameters, but as you wrote it will likely try negotiating the video streams.

I would think it is to the implementation of the V3C-capable offerer, it could:

  *   say I do not provide alternative 2D version of the content so if answerer do not support atlas then I do not send him anything
  *   say I provide alternative 2D version so I can send him one 2D video representation of the content

May you elaborate what/where in the draft the codec’s signaling would need to change.

Br,
Lukasz

From: Jonathan Lennox <[e-mail]>
Date: Monday, 24. June 2024 at 21:38
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Design question about the V3C codec

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi all — I’ve read over the latest V3C codec draft, as I promised at the interim.

My biggest question about the draft is a design question, about how backward compatibility in offer/answer should be supported.

As the draft is currently written, when a V3C-capable offerer sends an offer to a V3C-ignorant answerer, the answerer will ignore the V3C atlas codec and V3C-related parameters, but it can (and likely will) negotiate the video streams as 2D streams without any volumetric component, thus establishing a call with 2D video.

Is this what you want?  Or would you rather define the payload such that a V3C-ignorant answerer will completely ignore the volumetric m-lines, and negotiate something with a cleaner fallback (e.g. audio-only, rejecting the call entirely, etc.)

If the latter is what you want, the codec’s signaling will need changes.

Jonathan Lennox
As an individual