[AVTCORE] Re: Design question about the V3C codec

["Lauri Ilola (Nokia)" <[e-mail]>]

Hi Jonathan, all,

Thanks for the review and question. I would agree with what Lukasz outlines below. It’s perhaps an implementation detail that don’t need additional restrictions. There are alternative implementation designs that will depend on the way the sender is setup, how the encoder is configured and the level of ignorance of the receiver.


  1.  Fully ignorant V3C receiver probably doesn’t want to receive any V3C specific media lines.
     *   But there may be scenarios, where the receiver will regardless want to see what the media lines contain. As these are just video, a receiver can indeed inspect the contents of these.
  2.  Partially ignorant (incompatible profile for example), could decide to receive part of the videos depending on its capabilities.
  3.  There could be also a scenario, where the media description contains a pre-rendered 2D viewport of the volumetric information.

Should we clarify these designs for the specification or leave the freedom for implementers?

Kind Regards,
-Lauri

From: Lukasz Kondrad (Nokia) <[e-mail]>
Sent: Tuesday, July 9, 2024 4:34 PM
To: Jonathan Lennox <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: Design question about the V3C codec

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]<mailto:[e-mail]>>
Date: Monday, 24. June 2024 at 21:38
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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