[AVTCORE] Re: Design question about the V3C codec

[Christer Holmberg <[e-mail]>]

Hi,

Even if the V3C-offerer decides to not send 2D video, it cannot prevent the V3C-ignorant-answerer from sending 2D video.

There are ways of performing the negotiation before anything is sent. I don't think the draft needs to mandate those, but it should at least make the readers aware of the issue.

Regards,

Christer


> -----Original Message-----
> From: Lauri Ilola (Nokia) <lauri.ilola=[e-mail]>
> Sent: Friday, 19 July 2024 3.59
> To: Lukasz Kondrad (Nokia) <[e-mail]>; Jonathan Lennox
> <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: [AVTCORE] Re: Design question about the V3C codec
> 
> 	You don't often get email from
> lauri.ilola=[e-mail]. Learn why this is important
> <https://aka.ms/LearnAboutSenderIdentification>
> 
> 
> 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.
> 
> 	a.	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:draft-ietf-avtcore-rtp-
> [e-mail]>  <[e-mail] <mailto:draft-ietf-avtcore-
> [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