From patchwork Sun Sep 13 10:26:18 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Jan_Ekstr=C3=B6m?= X-Patchwork-Id: 22332 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id 6ECEF44ADCD for ; Sun, 13 Sep 2020 13:33:10 +0300 (EEST) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4D54668BBF5; Sun, 13 Sep 2020 13:33:10 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5B1B768BBF2 for ; Sun, 13 Sep 2020 13:33:03 +0300 (EEST) Received: by mail-lj1-f176.google.com with SMTP id k25so16105020ljk.0 for ; Sun, 13 Sep 2020 03:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=MSNkJDyCHTWeUjdPXmEc1LDksEQ19+yX1xZxzETFZUQ=; b=p/iZJIkSZeI+0ONVQ/eZlcxl45+b1iMH41abgW5D7qNyL/CvMWcQAPxLGqKFpBCtIT dpAkmVNcV9zk7QagUOQM5dIYFWh+1QQKwSTfe0B7/ExTv+KumCV68d8whiZRQRzHrqVf qUZP3LJ+0JdrLvOwuPFJhoqL8oZL/da9aFSa2kGBwz4aFNU4L4yJ2siIJiuXRyy6KOSb 2yYevbRO4QQNTinOZN1pOM5NmbbKhIHIazWS2E7sBvot12eAoVD4P4kdZq+y/Hdr14KS 5DVOSXfX+yrfyUXDpzm6pQWfPHDl/Z/fVdbuoMpTerDzxHjutU0BA5A0/jIiHnE5Ogop 5C1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=MSNkJDyCHTWeUjdPXmEc1LDksEQ19+yX1xZxzETFZUQ=; b=rkTKDtoQCVF87EhqQEnypAURCGlvhT/tuzXSIL5nUD4qQkM8ttuq+t9dlEl5gsKfgc 2edu75zETA8TLAGxxKKfNN17+2VXRNxUCeV8dxIjvd96jSvpKHIMbRq/dD4V/XpJ881c S0m6aEbwDHWr1lKqzT2ypFM0+hZ/TWMeglfGTk2upjOSfcY1hVIqOR0CeX85P0kI7h5K QcqVsWZpMkkb6Q+EITDoIr1jTRWPs+KrVRo+AEfFmgpfFYcH/EDV4CrxcpnDmSPOuGlR amzD+Y8/c6IP7k/nUdD+7LLZWrZwkbpKI5t7wgdY1v2nOkqlzTHA3JJCD6eG4Ce+Uy7T dAxw== X-Gm-Message-State: AOAM531Fu5aQ4Oy1wRHdjXIebGjjhPq4FWmAPxvCGx725PNDHCi8DMwh o3WIj1SeJpE8tMyPxd7jx+d3Alf/WQU= X-Google-Smtp-Source: ABdhPJz1F3vRbEfBtVM0ToZ/URl5oU846OMuVX/TaPEDGbiNhpw+dIxtsGRoAXNg8dJrNOTYmZnWuA== X-Received: by 2002:a19:dd5:: with SMTP id 204mr2686748lfn.579.1599992784756; Sun, 13 Sep 2020 03:26:24 -0700 (PDT) Received: from localhost.localdomain (91-159-194-103.elisa-laajakaista.fi. [91.159.194.103]) by smtp.gmail.com with ESMTPSA id n3sm2674790ljj.59.2020.09.13.03.26.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Sep 2020 03:26:24 -0700 (PDT) From: =?utf-8?q?Jan_Ekstr=C3=B6m?= To: ffmpeg-devel@ffmpeg.org Date: Sun, 13 Sep 2020 13:26:18 +0300 Message-Id: <20200913102622.168011-1-jeebjp@gmail.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 0/4 v2] ffmpeg: late A/V encoder init, AVFrame metadata usage X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 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 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" This patch set started with a very simple wish to not have to set color related values manually each time when utilizing ffmpeg.c. As of the second iteration, this patch set passes FATE on both of my machines. Only the MXF muxer tests actually needed changing, as the MXF muxer can now write the configured color range as it is no longer unspecified (in this case, limited range as flagged by the AVFrame). Unfortunately, audio still needs two locations where the encoder is initialized, due to how avfilter_graph_request_oldest peeks and already puts one AVFrame to be available from the filter graph (which is then utilized as-is as an early return inside both av_buffersink_get_frame_flags and av_buffersink_get_samples). If this would be improved in lavfi (or the call to avfilter_graph_request_oldest removed), we could at least remove one of these. Currently limited to using values for video and started with the basic values, more can be added later if needed. This probably fixes some trac issues, but with a quick look I couldn't find anything that explicitly was due to lack of video color metadata passthrough. Jan Example 1: I have an RGB 3-D render, which I would like to encode into BT.709 YCbCr. The video filter I'm generally using for this (zscale) does flag the matrix in the output AVFrame. Yet to have the video encoder have the correct metadata set, I have to set the value(s) manually. With this patch set, the value(s) from the first AVFrame fed to do_video_out will be utilized. Example 2: I have an input video that sets one or more of the following: matrix/primaries/transfer function/range/chroma location. I just want to re-encode it. All of this metadata gets stripped. With this patch set, the value(s) from the first AVFrame fed to do_video_out will be utilized. Example 3: I have a video which has incorrect metadata tagged. Before, I had to set the correct data data manually. With this patch set, since ffmpeg.c takes color related options as dictionary keys, the AVFrame values will only be utilized if the user has not set the option for a given stream. Thus, this use case still works. Jan Ekström (4): ffmpeg: deduplicate init_output_stream usage logic ffmpeg: move AVFrame time base adjustment into a function ffmpeg: move A/V non-streamcopy initialization to a later point ffmpeg: pass decoded or filtered AVFrame to output stream initialization fftools/ffmpeg.c | 215 +++++++++++++++++++++++++----------- tests/ref/lavf/mxf_d10 | 2 +- tests/ref/lavf/mxf_dv25 | 2 +- tests/ref/lavf/mxf_dvcpro50 | 2 +- tests/ref/lavf/mxf_opatom | 2 +- 5 files changed, 155 insertions(+), 68 deletions(-)