search

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

Other
5 stars 2 forks source link

Out-of-band sprop-vps/sprop-sps/sprop-pps #2

Closed aboba closed 1 year ago

aboba commented 1 year ago

From Jianlin Qiu:

For sprop-vps/sprop-sps/sprop-pps: The proposal suggests to ignore those params. My suggestion is to first look at in-band params, and if not existing, take those params from sdp. As WebRTC offerer in Chrome, we may opt to not signal them, but we should allow them to exist from a remote offerer,and we'd better honor them as we do in AVC.

aboba commented 1 year ago

Reply from Philip Eliasson:

I'm strongly in favor of not supporting out of band SPS/PPS/VPS. From my experience with H264, there were issues with the RTP spec of course (which is why we ended up with the non-standardized sps-pps-idr-in-keyframe fmtp), but there were also problems with the ecosystem of H264 encoders. Often we would find encoders that would not update the SPS/PPS ID, even if those parameter changed.

I don't know if the same is true for H265 encoders, but I rather not take the risk because if the size of SPS+PPS+VPS is similar to H264 SPS+PPS (~30-50 bytes) then the potential bandwidth saving is meaningless, even in very low bitrate scenarios.

fippo commented 1 year ago

https://www.rfc-editor.org/rfc/rfc7742#section-6.2 also says this must be signalled inband for H264 (but leaves it up to implementations to parse and interpret it)

Philipel-WebRTC commented 1 year ago

One more thing regarding SPS/PPS (and VPS). Any IDR sent must always be preceded by the relevant parameter sets sent in a packet (not necessarily a separate packet) with the same timestamp as the IDR.

aboba commented 1 year ago

AVTCORE VI slides are here: https://docs.google.com/presentation/d/1I944U1DmQ4C2f5r5_uEJiOm2N9s4x4B0c1-SPTPPuS0/edit#slide=id.g2473a55bcdf_0_48

Anything else we want to add?