search

AOMediaCodec / av1-rtp-spec

Current draft (HTML): https://aomediacodec.github.io/av1-rtp-spec/
Other
63 stars 24 forks source link

Should Profile Negotiation be specified as hierarchical? #194

Closed StephenBotzko closed 3 years ago

StephenBotzko commented 3 years ago

Currently the offer-answer signalling for profile is hierarchical in section 7.2.3 That is, if the profile the answerer supports for receiving is high, then the profile used in the offerer-to-answerer direction can be either main or high.

This is consistent with currently defined profiles in AV1. However, the AV1 specification itself doesn't mandate that future profiles be hierarchical. If a non-hierarchical profile were to be defined in the future, we would need to revise our current specification.

murillo128 commented 3 years ago

If the values are asymmetric and refers to the receiver capability, why is the answerer value need to be less than the offered value? more over, what happen if the offer direction is send only (I.e, it doesn't have any receiver)?

El lun., 9 nov. 2020 15:06, StephenBotzko notifications@github.com escribió:

Currently the offer-answer signalling for profile is hierarchical in section 7.2.3 That is, if the profile the answerer supports for receiving is high, then the profile used in the offerer-to-answerer direction can be either main or high.

This is consistent with currently defined profiles in AV1. However, the AV1 specification itself doesn't mandate that future profiles be hierarchical. If a non-hierarchical profile were to be defined in the future, we would need to revise our current specification.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AOMediaCodec/av1-rtp-spec/issues/194, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIFN4YXQMV2E4ZHFAT24KTSO7ZOLANCNFSM4TPMJI4A .

StephenBotzko commented 3 years ago

The send only case is specified in a different section, and in that case it defines the stream properties.

We could adjust the text to require the answerer profile value to match the offerer value - that of course is a question we need to discuss (and why I opened the issue).

Note there are some use cases where the SDP parameter might be high or professional, but the profile_seq in the bitstream might be main. Ad insertion is one of those cases. I don't think we need text to cover such cases, but we should confirm that. The same use cases occur with H.264 and H.265.

murillo128 commented 3 years ago

El lun., 9 nov. 2020 15:58, StephenBotzko notifications@github.com escribió:

The send only case is specified in a different section, and in that case it defines the stream properties.

I was referring sdp o/a with sendonly direction , no declarative sdp as in rtsp.

IMO profile/levels should refer to what the client is able to receive and not be negotiated. That is, offered may send main and answer may send high.

In case a client is send only, it just can ommit the profile/level.

StephenBotzko commented 3 years ago

That is, offered may send main and answer may send high. Agreed.

The question I meant to raise in this issue is whether the signaling the ability to receive profile X includes the ability to receive all profiles less than X. While this is true for existing profiles, it might not be true for future profiles.

In case a client is send only, it just can ommit the profile/level. It can with my proposed IANA pull request, but if it does that the receiver will infer that the profile is main, and the level is 3.1.

StephenBotzko commented 3 years ago

We decided to keep the current hierarchical signaling.