search

ietf-wg-avtcore / draft-ietf-avtcore-hevc-webrtc

Other
5 stars 2 forks source link

PACI packet #12

Closed qwu16 closed 11 months ago

qwu16 commented 1 year ago

PACI packet is defined in RFC7798 ((https://datatracker.ietf.org/doc/html/rfc7798, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet.

In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically.

We may ignore payload type 50 in H265 depacketizer.

aboba commented 1 year ago

Virtual interm slide is here: https://docs.google.com/presentation/d/1I944U1DmQ4C2f5r5_uEJiOm2N9s4x4B0c1-SPTPPuS0/edit#slide=id.g2473a55bcdf_0_77

fippo commented 1 year ago

sent through RTP video header extension

Through the GFD (somewhat deprecated) and DD extensions?

taste1981 commented 1 year ago

yes. through GFD or DD depending on if it's perfectly layered according to spec.

fippo commented 1 year ago

https://notes.ietf.org/notes-ietf-interim-2023-avtcore-03-avtcore @JonathanLennox made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?

aboba commented 1 year ago

@fippo I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.

aboba commented 11 months ago

Closing. At IETF 118, the proposed text was presented, and there were no objections.