[FFmpeg-devel] [PATCH] avformat: add AV1 RTP depacketizer and packetizer
Chris Hodges
Chris.Hodges at axis.com
Tue Nov 26 16:22:56 EET 2024
Hi Tristan,
On 11/25/24 18:47, Tristan Matthews via ffmpeg-devel wrote:
> I haven't done an in-depth review but I tested this locally and it's working well. I'm impressed you were able to implement the packetization without allocating scratch buffers.
I had to rewrite it a couple of times until I got all the cases correct.
> One nit I'd add is that since the RTP AV1 spec is still in draft (according to https://aomediacodec.github.io/av1-rtp-spec/) this feature should probably be marked experimental as is done for VP9 in RTP, see:
> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/f8e91ab05ff3d111626ab8a3b5d570865a934f07:/libavformat/rtpenc.c#l221
>
> in which case CLI users will have to add `-strict experimental` to their options.
That is a good point and I have added it. Thanks.
> For the keyframe detection issue I'm not sure if this is something missing in FFMPEG's RTP stack (e.g. I've noticed that both GStreamer and libwebrtc signal that a buffer contains a keyframe at a higher level), but if not could you set it if you're dealing with a FRAME OBU of type 0 (keyframe) or 2 (intra-only)? You'd need to parse the OBU to extract that however.
I have no problem parsing the few bits in OBU_FRAME and OBU_FRAME_HEADER
that are required to detect frame_type == KEY_FRAME instead of looking
for OBU_SEQUENCE_HEADER.
Note, that this might be a hit and miss, if (for whatever reasons) the
RTP packet size is (unrealistically) small so that the first RTP packet
is sent out with other OBUs before the OBU_FRAME[_HEADER] is being handled.
It does not become so unrealistic anymore if there are OBU_METADATAs
before the OBU_FRAME[_HEADER] that could contain arbitrary payloads (for
such purposes as for signed video). To solve that, all the OBUs in the
frame would need to be examined before starting to write the first RTP
packet -- which is of course possible. However, it makes questionable
how far you would want to go for a workaround instead of looking into
the root cause of why the keyframe information flag is currently missing
in the RTP state.
I would therefore look into the latter and see if I can pin-point and
fix that.
Thanks for your feedback, it is appreciated. I hope to collect more
reviews in the upcoming weeks and will come up with an updated patch.
--
Chris
More information about the ffmpeg-devel
mailing list