From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 27B964B27D for ; Thu, 1 Aug 2024 21:45:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 87D3A68C435; Fri, 2 Aug 2024 00:45:50 +0300 (EEST) Received: from mail-oo1-f51.google.com (mail-oo1-f51.google.com [209.85.161.51]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 033D868C435 for ; Fri, 2 Aug 2024 00:45:44 +0300 (EEST) Received: by mail-oo1-f51.google.com with SMTP id 006d021491bc7-5d5b986a806so1326758eaf.1 for ; Thu, 01 Aug 2024 14:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722548742; x=1723153542; darn=ffmpeg.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=esLdjHCA9kkNn60qRt8Iyvq4if7Hkb+yMjW76AMsz5o=; b=U9ZoPzfo0G+HxDjtJoExXPSkujKyzBv9NlsLDSd0RhNmHtjDrhCYPWyULzBdeOnQcG dYNBw15Pfrnos8UyNR29/f6lnYadANhHfsA3cuAR6CGTg//KBt+BexvC/RQo8yYLQQkT 0S1rLVOvPMPlxnCHoTcb7MlRocpE6WhAh3l8/q+GxOHH9KYr9devtHyhlrD/SWjjrLDn cRg+4PXdwzTrsSGI7wsS9a0WSeKeN4F9OXQFTuRXdgD5SbZ0Ah47TJoGJhhn5NbccyG+ CScl3hs0F8sPharUMEXzP9ttHcpEvpXA1O7mdjLMkMLPH/QGZdaMxzewXl1DHconh6G6 kOeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722548742; x=1723153542; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=esLdjHCA9kkNn60qRt8Iyvq4if7Hkb+yMjW76AMsz5o=; b=WFlXLD4JHEz5Egc4T61VyF2Uim5rnqBZ6VhWWHBZOcolP81/VKQj3cr0wQMcUG/J9x TV2PciHQYJOSfliKwoUJD4fD6/ZB2HjImdht4D5cb10KoHZaA3XyQWSgZKHE2z5+Jk+B iNii3f6Ehtn+pthI1mNQRF5eqhAx9V8r0KDp/vOv7ogNCivOkPSPSBf3KGC6la69Ylqm m3L6pTDDagNKjgfhskDGlXj0y4LANe3W43zmGiJ1aetPqkrxUrOv1jgYtQwwpoXWJLZd W/+m+rwsllBSvhI/wDg38zbSZTKGXvQKpO11Rx2vXcCM0+AQIk6O36IEWffaLBQ0iDsL xVEQ== X-Gm-Message-State: AOJu0YxLxE7gUELIBZldQvfijLFky2WSSbko9O/zLFZQz2tHGrjoIr8y 9av7SyoJTUE7qbrZBGJNwsYVqWDK96/ZMTDe8oxHRZcxKpMB3odvQzaTtKj4LsthWz+x21oXy42 ZPUku4p/TSoivqDkG3iliWe1XhD5uLh42 X-Google-Smtp-Source: AGHT+IFTJY65IgDRvVMoWWq+KVWKuPktrLD3ysqmefrs3QFIaOrRrsWBepF8moKt9sN+7cDdLt0SRg8BtkjIR7HcPYk= X-Received: by 2002:a05:6870:2189:b0:261:a04:2aad with SMTP id 586e51a60fabf-268877ada78mr1175309fac.6.1722548742039; Thu, 01 Aug 2024 14:45:42 -0700 (PDT) MIME-Version: 1.0 References: <20240709190547.99246-1-joshua.allmann@gmail.com> <172249913303.21344.17598597604771690214@lain.khirnov.net> In-Reply-To: <172249913303.21344.17598597604771690214@lain.khirnov.net> From: Josh Allmann Date: Thu, 1 Aug 2024 14:45:05 -0700 Message-ID: To: FFmpeg development discussions and patches , Josh Allmann Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Thu, 1 Aug 2024 at 00:58, Anton Khirnov wrote: > Thanks for the review. > Quoting Josh Allmann (2024-07-09 21:05:47) > > Encoders may emit a buffering period SEI without a corresponding > > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc. > > > > During Annex B conversion, this may result in the SPS/PPS being > > inserted *after* the buffering period SEI but before the IDR NAL. > > > > Since the buffering period SEI references the SPS, the SPS/PPS > > needs to come first. > > --- > > > > Notes: > > v2: Updated FATE test refs > > > > libavcodec/bsf/h264_mp4toannexb.c | 13 +++++++++++++ > > tests/ref/fate/h264-bsf-mp4toannexb | 2 +- > > tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +++++++++--------- > > tests/ref/fate/segment-mp4-to-ts | 12 ++++++------ > > 4 files changed, 29 insertions(+), 16 deletions(-) > > > > diff --git a/libavcodec/bsf/h264_mp4toannexb.c b/libavcodec/bsf/h264_mp4toannexb.c > > index 92af6a6881..6607f1e91a 100644 > > --- a/libavcodec/bsf/h264_mp4toannexb.c > > +++ b/libavcodec/bsf/h264_mp4toannexb.c > > @@ -363,6 +363,19 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *opkt) > > if (!new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] & 0x80)) > > new_idr = 1; > > > > + /* If this is a buffering period SEI without a corresponding sps/pps > > + * then prepend any existing sps/pps before the SEI */ > > + if (unit_type == H264_NAL_SEI && buf[1] == 0 && !sps_seen && !pps_seen) { > > That 0 should be SEI_TYPE_BUFFERING_PERIOD, right? > Yes - fixed > > + if (s->sps_size) { > > + count_or_copy(&out, &out_size, s->sps, s->sps_size, PS_OUT_OF_BAND, j); > > + sps_seen = 1; > > + } > > + if (s->pps_size) { > > + count_or_copy(&out, &out_size, s->pps, s->pps_size, PS_OUT_OF_BAND, j); > > + pps_seen = 1; > > + } > > Is there a reason to insert the PPS? IIUC only the SPS is needed. > I believe it would be needed if using this bsf with the segment muxer, and segmentation happens on a recovery point (with a buffering period), eg in the test fate-segment-mp4-to-ts . Granted it is kind of incidental that this patch actually fixes that specific case. I have never seen a SPS without a PPS though. Josh _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".