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 3326A4549E for ; Mon, 30 Jan 2023 17:36:46 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 37E9A68BD6C; Mon, 30 Jan 2023 19:36:43 +0200 (EET) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 90C5A68B526 for ; Mon, 30 Jan 2023 19:36:37 +0200 (EET) Received: by mail-pf1-f179.google.com with SMTP id z1so5346069pfg.12 for ; Mon, 30 Jan 2023 09:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ZQG6p8k+m5gNFPOH8ct48DWAtJXoKXItOeOsGeaOwCU=; b=Jf0qFWjTdA2KYpzA8tZGVNDDo2KsZgiTHGG50wDHdE0e6pR4uHvSHU/dylY5c936fO osjE1eeqCc4VgjpILwTOLcafDXjhpEQZj+bdlEpP5RjUA/EcuIqtsYfETeyWO8OP+bnC CG8pNwspW2cqYzP5iWflJt7TtPqUhvA2OSLqgf5DHEh96pqDRw3Ax+SD+iBD1whmT/Kw tZCeoMAnyxALPkSXGkEdeVpDpg5V49shc7b2yd4E+000FckHxxnxQgrhRq3WCjOgLt6c nK2jHeYHTwVKhl3LwkIdTKcUmmh+mZV98kQsMOiuSeYKg5cHCAeGXc9XsFzjclsHGDuY vYGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=ZQG6p8k+m5gNFPOH8ct48DWAtJXoKXItOeOsGeaOwCU=; b=NO7xajMBg9nZDABQuyDrHr9MivHxi+BlBOPDR7Tr/Q/LrmFDhbGbS8QR2QiLXBW+6A GgH+3EYCeTvvJqQIIM936FhYOjiVYcM0+mk0CylB5YU6lt2G/HwA4HwC8yl9F0eg0S1a Rt2eG/Sidc9zYC/EUR/YwT3bJhjRefAF0jo9pKx4cadmRztfnLAJtYySd+CjSHc+hOy/ Eh0Usl7qeWPX9WVr3SoaOI+BXYlbMCeI06BrqWuEX9d/MFnLKEMTulVYI7psnkr4kPO3 54HCqpRvmtFhjufH05kTv2kWkGRM2duOPDk3cvMzXzepBUihEFULjbAS94j0U906SHTM IhLA== X-Gm-Message-State: AO0yUKUOUHh/atbs0fghL1EZuNlA7ymO2EGbzEV7Nwfq3xLUIoqJyZZy HMgBFGU5Jk72GawaH2OIIjeGYC85G5hJhXO39ayIbM3Ql5c= X-Google-Smtp-Source: AK7set8qrCvWJag8G4asE0htNVhAH1i+Tl/3IY3JcQK1KWWEUEY1SXo4I37SgILrGgbJR2lncuiU4K13nsqkTOWn7Ug= X-Received: by 2002:a65:6a49:0:b0:4da:18a2:4129 with SMTP id o9-20020a656a49000000b004da18a24129mr2555045pgu.121.1675100195261; Mon, 30 Jan 2023 09:36:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Coiner Date: Mon, 30 Jan 2023 12:36:24 -0500 Message-ID: To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc.c -- correctly re-emit extradata ahead of IDR pictures 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: Marton Balint wrote: > This does not look right, because AFAIK you always want to insert an AUD > unless it is already there. I guess that is why current code works as it > is, it assumes if an AUD is already present, then IDR-s are already > prefixed with SPS/PPS, and no magic is needed. I'm not sure if it should be valid to assume that an AUD implies that an SPS/PPS will follow, but this is how the above command makes that assumption go wrong: * The HLS muxer requests global headers as input: https://github.com/FFmpeg/FFmpeg/blob/2d202985b79630cd5056c4e32f8f77f22bf1067c/libavformat/hlsenc.c#L3194 * This sets the AV_CODEC_FLAG_GLOBAL_HEADER option for the codec: https://github.com/FFmpeg/FFmpeg/blob/2d202985b79630cd5056c4e32f8f77f22bf1067c/fftools/ffmpeg_mux_init.c#L599 * The libx264.c codec responds to this option by producing extradata, and also by configuring x264 not to repeat SPS and PPS in-band: https://github.com/FFmpeg/FFmpeg/blob/2d202985b79630cd5056c4e32f8f77f22bf1067c/libavcodec/libx264.c#L1044 * When x264 runs with its "aud" option, it emits AUDs. * The AUDs inhibit mpegtsenc.c from emitting the extradata, producing the buggy behavior. An alternative to changing the extradata "magic" in mpegtsenc would be for the HLS muxer to re-emit the extradata on its own. The HLS muxer has good context for this: it knows when new HLS media segments begin, and it knows that each one must begin with SPS and PPS if the encoder didn't already include them. It knows it's producing HLS. The mpegtsenc muxer doesn't know any of this. Would it be safer to fix in hlsenc.c and leave mpegtsenc alone? It's not clear to me that the mpegtsenc logic is verifiable or falsifiable to stronger than a "happens to work" standard; a fix in hlsenc.c could be. Cheers John _______________________________________________ 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".