[FFmpeg-devel] [PATCH V5 4/5] lavfi/dnn_backend_native_layer_depth2space.h: Documentation
Add documentation for Depth to Space Layer
Signed-off-by: Shubhanshu Saxena
---
.../dnn_backend_native_layer_depth2space.h| 30 +++
1 file changed, 30 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_depth2space.h
b/libavfilter/dnn/dnn_backend_native_layer_depth2space.h
index ef59394443..2792a33ebe 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_depth2space.h
+++ b/libavfilter/dnn/dnn_backend_native_layer_depth2space.h
@@ -34,7 +34,37 @@ typedef struct DepthToSpaceParams{
int block_size;
} DepthToSpaceParams;
+/**
+ * @brief Load the Depth to Space Layer.
+ *
+ * It assigns the depth to space layer with DepthToSpaceParams
+ * after parsing from the model file context.
+ *
+ * @param layer pointer to the DNN layer instance
+ * @param model_file_context pointer to model file context
+ * @param file_size model file size to check if data is read
+ * correctly from the model file
+ * @param operands_num operand count of the whole model to
+ * check if data is read correctly from the model file
+ * @return number of bytes read from the model file
+ * @retval 0 if an error occurs or out of memory
+ */
int ff_dnn_load_layer_depth2space(Layer *layer, AVIOContext
*model_file_context, int file_size, int operands_num);
+
+/**
+ * @brief Execute the Depth to Space Layer.
+ *
+ * It rearranges the input data from depth into spatial
+ * form by applying Depth to Space transformation.
+ *
+ * @param operands all operands for the model
+ * @param input_operand_indexes input operand indexes for this layer
+ * @param output_operand_index output operand index for this layer
+ * @param parameters depth to space layer parameters
+ * @param ctx pointer to Native model context for logging
+ * @retval 0 if the execution succeeds
+ * @retval DNN_ERROR if the execution fails
+ */
int ff_dnn_execute_layer_depth2space(DnnOperand *operands, const int32_t
*input_operand_indexes,
int32_t output_operand_index, const void
*parameters, NativeContext *ctx);
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V5 5/5] lavfi/dnn_backend_native_layer_mathunary.h: Documentation
Add documentation for Unary Math Layer
Signed-off-by: Shubhanshu Saxena
---
.../dnn/dnn_backend_native_layer_mathunary.h | 30 +++
1 file changed, 30 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
b/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
index 151a73200a..ed79947896 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
@@ -54,7 +54,37 @@ typedef struct DnnLayerMathUnaryParams{
DNNMathUnaryOperation un_op;
} DnnLayerMathUnaryParams;
+/**
+ * @brief Load the Unary Math Layer.
+ *
+ * It assigns the unary math layer with DnnLayerMathUnaryParams
+ * after parsing from the model file context.
+ *
+ * @param layer pointer to the DNN layer instance
+ * @param model_file_context pointer to model file context
+ * @param file_size model file size to check if data is read
+ * correctly from the model file
+ * @param operands_num operand count of the whole model to
+ * check if data is read correctly from the model file
+ * @return number of bytes read from the model file
+ * @retval 0 if out of memory or an error occurs
+ */
int ff_dnn_load_layer_math_unary(Layer *layer, AVIOContext
*model_file_context, int file_size, int operands_num);
+
+/**
+ * @brief Execute the Unary Math Layer.
+ *
+ * It applies the unary operator parsed while
+ * loading to the given input operands.
+ *
+ * @param operands all operands for the model
+ * @param input_operand_indexes input operand indexes for this layer
+ * @param output_operand_index output operand index for this layer
+ * @param parameters unary math layer parameters
+ * @param ctx pointer to Native model context for logging
+ * @retval 0 if the execution succeeds
+ * @retval DNN_ERROR if the execution fails
+ */
int ff_dnn_execute_layer_math_unary(DnnOperand *operands, const int32_t
*input_operand_indexes,
int32_t output_operand_index, const void
*parameters, NativeContext *ctx);
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V5 2/5] lavfi/dnn_backend_native_layer_conv2d.h: Documentation
Add documentation for 2D Convolution Layer
Signed-off-by: Shubhanshu Saxena
---
.../dnn/dnn_backend_native_layer_conv2d.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_conv2d.h
b/libavfilter/dnn/dnn_backend_native_layer_conv2d.h
index 03ca795c61..446f48f608 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_conv2d.h
+++ b/libavfilter/dnn/dnn_backend_native_layer_conv2d.h
@@ -34,7 +34,34 @@ typedef struct ConvolutionalParams{
float *biases;
} ConvolutionalParams;
+/**
+ * @brief Load the 2D Convolution Layer.
+ *
+ * It assigns the 2D convolution layer with ConvolutionalParams
+ * after parsing from the model file context.
+ *
+ * @param layer pointer to the DNN layer instance
+ * @param model_file_context pointer to model file context
+ * @param file_size model file size to check if data is read
+ * correctly from the model file
+ * @param operands_num operand count of the whole model to
+ * check if data is read correctly from the model file
+ * @return number of bytes read from the model file
+ * @retval 0 if out of memory or an error occurs
+ */
int ff_dnn_load_layer_conv2d(Layer *layer, AVIOContext *model_file_context,
int file_size, int operands_num);
+
+/**
+ * @brief Execute the 2D Convolution Layer.
+ *
+ * @param operands all operands for the model
+ * @param input_operand_indexes input operand indexes for this layer
+ * @param output_operand_index output operand index for this layer
+ * @param parameters convolution parameters
+ * @param ctx pointer to Native model context for logging
+ * @retval 0 if the execution succeeds
+ * @retval DNN_ERROR if the execution fails
+ */
int ff_dnn_execute_layer_conv2d(DnnOperand *operands, const int32_t
*input_operand_indexes,
int32_t output_operand_index, const void
*parameters, NativeContext *ctx);
#endif
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V4 2/5] lavfi/dnn_backend_native_layer_conv2d.h: Documentation
On Fri, May 14, 2021 at 7:23 AM Guo, Yejun wrote: > > typo for 'average pooling parameters' in patch 2 to patch 5. > > will push patch 1 soon. > > Corrected ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V5 3/5] lavfi/dnn_backend_native_layer_dense.h: Documentation
Add documentation for Dense Layer
Signed-off-by: Shubhanshu Saxena
---
.../dnn/dnn_backend_native_layer_dense.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_dense.h
b/libavfilter/dnn/dnn_backend_native_layer_dense.h
index 86248856ae..0488b03cc3 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_dense.h
+++ b/libavfilter/dnn/dnn_backend_native_layer_dense.h
@@ -31,7 +31,34 @@ typedef struct DenseParams{
float *biases;
} DenseParams;
+/**
+ * @brief Load the Densely-Connected Layer.
+ *
+ * It assigns the densely connected layer with DenseParams
+ * after parsing from the model file context.
+ *
+ * @param layer pointer to the DNN layer instance
+ * @param model_file_context pointer to model file context
+ * @param file_size model file size to check if data is read
+ * correctly from the model file
+ * @param operands_num operand count of the whole model to
+ * check if data is read correctly from the model file
+ * @return number of bytes read from the model file
+ * @retval 0 if out of memory or an error occurs
+ */
int ff_dnn_load_layer_dense(Layer *layer, AVIOContext *model_file_context, int
file_size, int operands_num);
+
+/**
+ * @brief Execute the Densely-Connected Layer.
+ *
+ * @param operands all operands for the model
+ * @param input_operand_indexes input operand indexes for this layer
+ * @param output_operand_index output operand index for this layer
+ * @param parameters dense layer parameters
+ * @param ctx pointer to Native model context for logging
+ * @retval 0 if the execution succeeds
+ * @retval DNN_ERROR if the execution fails
+ */
int ff_dnn_execute_layer_dense(DnnOperand *operands, const int32_t
*input_operand_indexes,
int32_t output_operand_index, const void
*parameters, NativeContext *ctx);
#endif
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Encode user data unregistered SEI (H.264/H.265)
On Fri, 14 May 2021, Brad Hards wrote: On Friday, 14 May 2021 1:59:13 AM AEST Marton Balint wrote: On Tue, 11 May 2021, Brad Hards wrote: On Saturday, 1 May 2021 12:23:00 PM AEST Brad Hards wrote: MISB ST 0604 and ST 2101 require user data unregistered SEI messages (precision timestamps and sensor identifiers) to be included. That currently isn't supported. This series adds encoding for libx264, libx265, hevc_nvenc and h264_nvenc. v2 removes the API addition, modifies nvenc to use a dynamic array, and corrects formatting. Any comments on v2? As far as I see it is consistently missing allocation checks for realloc_array all over the place. I will investigate and resolve as part of v3 (subject to advice below). Is it realistic that more than e.g. 16 SEI data is needed? If not, then maybe static allocation for SEI data and limiting the number to 16 or so should be simpler. I don't think there is likely to be more than 16, but there is probably some case where it could occur. Also, the review comments from v1 requested a dynamic array, when I'd previously used the existing static allocation: http://ffmpeg.org/pipermail/ffmpeg-devel/2021-May/279857.html I can do it either way. Please advise. Ah, OK, keep the dynamic allocation then. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Segmentation fault when running vulkan
When running vulkan on arch linux, I get a segmentation fault. Command: ffmpeg -v verbose -init_hw_device vulkan=gpu:0.0 -filter_hw_device gpu -i atm.mp4 -filter_complex hwupload,avgblur_vulkan,hwdownload atmvulk.mp4 -loglevel debug Output: ffmpeg version N-102515-g175f675f7b Copyright (c) 2000-2021 the FFmpeg developers built with gcc 10.2.0 (GCC) configuration: --enable-opencl --enable-vulkan --enable-libglslang libavutil 57. 0.100 / 57. 0.100 libavcodec 59. 1.100 / 59. 1.100 libavformat59. 0.101 / 59. 0.101 libavdevice59. 0.100 / 59. 0.100 libavfilter 8. 0.101 / 8. 0.101 libswscale 6. 0.100 / 6. 0.100 libswresample 4. 0.100 / 4. 0.100 Splitting the commandline. Reading option '-v' ... matched as option 'v' (set logging level) with argument 'verbose'. Reading option '-init_hw_device' ... matched as option 'init_hw_device' (initialise hardware device) with argument 'vulkan=gpu:0.0'. Reading option '-filter_hw_device' ... matched as option 'filter_hw_device' (set hardware device used when filtering) with argument 'gpu'. Reading option '-i' ... matched as input url with argument 'atm.mp4'. Reading option '-filter_complex' ... matched as option 'filter_complex' (create a complex filtergraph) with argument 'hwupload,avgblur_vulkan=10,hwdownload'. Reading option 'atmvulk.mp4' ... matched as output url. Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'. Finished splitting the commandline. Parsing a group of options: global . Applying option v (set logging level) with argument verbose. [AVHWDeviceContext @ 0x563094799c80] GPU listing: [AVHWDeviceContext @ 0x563094799c80] 0: NVIDIA GeForce RTX 2070 SUPER (discrete) (0x1e84) [AVHWDeviceContext @ 0x563094799c80] Using queue family 0 (total queues: 16) for graphics [AVHWDeviceContext @ 0x563094799c80] QF 0 flags: (graphics) (compute) (transfers) (sparse) [AVHWDeviceContext @ 0x563094799c80] Using queue family 2 (total queues: 8) for compute [AVHWDeviceContext @ 0x563094799c80] QF 2 flags: (compute) (transfers) (sparse) [AVHWDeviceContext @ 0x563094799c80] Using queue family 1 (total queues: 2) for transfers [AVHWDeviceContext @ 0x563094799c80] QF 1 flags: (transfers) (sparse) [AVHWDeviceContext @ 0x563094799c80] Using device extension "VK_KHR_external_memory_fd" [AVHWDeviceContext @ 0x563094799c80] Using device extension "VK_KHR_external_semaphore_fd" [AVHWDeviceContext @ 0x563094799c80] Using device extension "VK_EXT_external_memory_host" [AVHWDeviceContext @ 0x563094799c80] Using device extension "VK_KHR_push_descriptor" [AVHWDeviceContext @ 0x563094799c80] Using device extension "VK_EXT_host_query_reset" [AVHWDeviceContext @ 0x563094799c80] Using device extension VK_KHR_external_memory_fd [AVHWDeviceContext @ 0x563094799c80] Using device extension VK_KHR_external_semaphore_fd [AVHWDeviceContext @ 0x563094799c80] Using device extension VK_EXT_external_memory_host [AVHWDeviceContext @ 0x563094799c80] Using device extension VK_KHR_push_descriptor [AVHWDeviceContext @ 0x563094799c80] Using device extension VK_EXT_host_query_reset [AVHWDeviceContext @ 0x563094799c80] Using device: NVIDIA GeForce RTX 2070 SUPER [AVHWDeviceContext @ 0x563094799c80] Alignments: [AVHWDeviceContext @ 0x563094799c80] optimalBufferCopyRowPitchAlignment: 1 [AVHWDeviceContext @ 0x563094799c80] minMemoryMapAlignment: 64 [AVHWDeviceContext @ 0x563094799c80] minImportedHostPointerAlignment: 4096 Successfully parsed a group of options. Parsing a group of options: input url atm.mp4. Successfully parsed a group of options. Opening an input file: atm.mp4. [NULL @ 0x563094a2a3c0] Opening 'atm.mp4' for reading [file @ 0x563094a2ac00] Setting default whitelist 'file,crypto,data' [mov,mp4,m4a,3gp,3g2,mj2 @ 0x563094a2a3c0] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x563094a2a3c0] ISO: File Type Major Brand: mp42 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x563094a2a3c0] Unknown dref type 0x206c7275 size 12 Last message repeated 1 times [mov,mp4,m4a,3gp,3g2,mj2 @ 0x563094a2a3c0] Before avformat_find_stream_info() pos: 23751465 bytes read:74604 seeks:1 nb_streams:2 [h264 @ 0x563094a33c00] nal_unit_type: 7(SPS), nal_ref_idc: 3 [h264 @ 0x563094a33c00] nal_unit_type: 8(PPS), nal_ref_idc: 3 [h264 @ 0x563094a33c00] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x563094a33c00] nal_unit_type: 6(SEI), nal_ref_idc: 0 Last message repeated 1 times [h264 @ 0x563094a33c00] nal_unit_type: 5(IDR), nal_ref_idc: 3 [h264 @ 0x563094a33c00] Format yuv420p chosen by get_format(). [h264 @ 0x563094a33c00] Reinit context to 1024x576, pix_fmt: yuv420p [h264 @ 0x563094a33c00] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x563094a33c00] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 3 [h264 @ 0x563094a33c00] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x563094a33c00] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc
Re: [FFmpeg-devel] [PATCH 12/12] lavf/framecrcenc: do not hash side data
Quoting Michael Niedermayer (2021-05-10 16:06:01)
> On Sun, Apr 25, 2021 at 09:03:20AM +0200, Anton Khirnov wrote:
> > There are no guarantees that all side data types have the same
> > representation on all platforms.
>
> > @@ -65,63 +51,6 @@ static int framecrc_write_packet(struct AVFormatContext
> > *s, AVPacket *pkt)
> > pkt->stream_index, pkt->dts, pkt->pts, pkt->duration,
> > pkt->size, crc);
> > if (pkt->flags != AV_PKT_FLAG_KEY)
> > av_strlcatf(buf, sizeof(buf), ", F=0x%0X", pkt->flags);
> > -if (pkt->side_data_elems) {
> > -int i;
> > -av_strlcatf(buf, sizeof(buf), ", S=%d", pkt->side_data_elems);
>
> The number and type of the side data elements should not be affected
> by the problem described.
> Maybe we could leave that. Bugs could manifest as the absence or addition
> of side data, seeing that in framecrc_write_packet() output may be usefull
No strong opinion here - patches welcome I guess.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/flvdec: normalize exporting date metadata
Quoting Alexander Strasser (2021-05-12 01:04:28)
> From 3fd6c8f81baacace49e0a6cc431295dc56a077bc Mon Sep 17 00:00:00 2001
> From: Alexander Strasser
> Date: Wed, 12 May 2021 00:46:54 +0200
> Subject: [PATCH] lavf/flvdec: metadata date: respect timezone information if
> present
>
> If the timezone data of an AMF 0 date type is non-zero, include that
> information as UTC offset in hours and minutes.
> ---
> libavformat/flvdec.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index ddaceaafe4..c941e62e23 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -688,9 +688,21 @@ static int amf_parse_object(AVFormatContext *s, AVStream
> *astream,
> time = date.milliseconds / 1000; // to seconds
> gmtime_r(&time, &t);
>
> -// timezone is ignored, since there is no easy way to offset the
> UTC
> -// timestamp into the specified timezone
> -strftime(datestr, sizeof(datestr), "%Y-%m-%dT%H:%M:%SZ", &t);
> +strftime(datestr, sizeof(datestr), "%Y-%m-%dT%H:%M:%S", &t);
> +
> +if (date.timezone) {
> +int off_tz = date.timezone; // offset in minutes
> +char ch_sign = '+';
> +if (off_tz < 0) {
> +off_tz = -off_tz;
> +ch_sign = '-';
> +}
> +if (off_tz > 99*60 + 59)
> +off_tz = 99*60 + 59;
> +
> +av_strlcatf(datestr, sizeof(datestr), "%c%02d%02d", ch_sign,
> off_tz / 60, off_tz % 60);
I still believe this is wrong, since the spec says the timestamp is in
UTC. The code you quoted seems to conform to that.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 00/22] clean-up QSV filters
'lavf' means libavformat, 'lavfi' is used for libavfilter -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: enhance parsing timestamps
Quoting Marton Balint (2021-05-12 20:55:45)
> Take into account timezone. Use millisecond precision. Maybe we could also use
> nanosecond, but there were some float rounding concerns.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/flvdec.c | 13 ++---
> tests/ref/fate/flv-demux | 2 +-
> 2 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index ddaceaafe4..3791687072 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -28,6 +28,7 @@
> #include "libavutil/channel_layout.h"
> #include "libavutil/dict.h"
> #include "libavutil/opt.h"
> +#include "libavutil/internal.h"
> #include "libavutil/intfloat.h"
> #include "libavutil/mathematics.h"
> #include "libavutil/time_internal.h"
> @@ -682,17 +683,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream
> *astream,
> } else if (amf_type == AMF_DATA_TYPE_STRING) {
> av_dict_set(&s->metadata, key, str_val, 0);
> } else if (amf_type == AMF_DATA_TYPE_DATE) {
> -time_t time;
> -struct tm t;
> -char datestr[128];
> -time = date.milliseconds / 1000; // to seconds
> -gmtime_r(&time, &t);
> -
> -// timezone is ignored, since there is no easy way to offset the
> UTC
> -// timestamp into the specified timezone
> -strftime(datestr, sizeof(datestr), "%Y-%m-%dT%H:%M:%SZ", &t);
> -
> -av_dict_set(&s->metadata, key, datestr, 0);
> +avpriv_dict_set_timestamp(&s->metadata, key, -date.timezone *
> 6000LL + 1000 * (int64_t)date.milliseconds);
This is wrong -- date.milliseconds is in UTC, if you add the timezone
offset it will no longer be in UTC.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] lavfi/drawbox: refine code
Extract common code of filter_frame() and drawgrid_filter_frame() to
draw_region().
Signed-off-by: Ting Fu
---
libavfilter/vf_drawbox.c | 160 ++-
1 file changed, 58 insertions(+), 102 deletions(-)
diff --git a/libavfilter/vf_drawbox.c b/libavfilter/vf_drawbox.c
index 2794fc2520..95e26191bd 100644
--- a/libavfilter/vf_drawbox.c
+++ b/libavfilter/vf_drawbox.c
@@ -85,6 +85,61 @@ typedef struct DrawBoxContext {
static const int NUM_EXPR_EVALS = 5;
+typedef int (*PixelBelongsToRegion)(DrawBoxContext *s, int x, int y);
+
+#define ASSIGN_THREE_CHANNELS\
+row[0] = frame->data[0] + y * frame->linesize[0]; \
+row[1] = frame->data[1] + (y >> ctx->vsub) * frame->linesize[1]; \
+row[2] = frame->data[2] + (y >> ctx->vsub) * frame->linesize[2];
+
+#define ASSIGN_FOUR_CHANNELS \
+ASSIGN_THREE_CHANNELS \
+row[3] = frame->data[3] + y * frame->linesize[3];
+
+static void draw_region(AVFrame *frame, DrawBoxContext *ctx, int left, int
top, int right, int down,
+PixelBelongsToRegion pixel_belongs_to_region)
+{
+unsigned char *row[4];
+int x, y;
+if (ctx->have_alpha && ctx->replace) {
+for (y = top; y < down; y++) {
+ASSIGN_FOUR_CHANNELS
+if (ctx->invert_color) {
+for (x = left; x < right; x++)
+if (pixel_belongs_to_region(ctx, x, y))
+row[0][x] = 0xff - row[0][x];
+} else {
+for (x = left; x < right; x++) {
+if (pixel_belongs_to_region(ctx, x, y)) {
+row[0][x ] = ctx->yuv_color[Y];
+row[1][x >> ctx->hsub] = ctx->yuv_color[U];
+row[2][x >> ctx->hsub] = ctx->yuv_color[V];
+row[3][x ] = ctx->yuv_color[A];
+}
+}
+}
+}
+} else {
+for (y = top; y < down; y++) {
+ASSIGN_THREE_CHANNELS
+if (ctx->invert_color) {
+if (pixel_belongs_to_region(ctx, x, y))
+row[0][x] = 0xff - row[0][x];
+} else {
+for (x = left; x < right; x++) {
+double alpha = (double)ctx->yuv_color[A] / 255;
+
+if (pixel_belongs_to_region(ctx, x, y)) {
+row[0][x ] = (1 - alpha) * row[0][x
] + alpha * ctx->yuv_color[Y];
+row[1][x >> ctx->hsub] = (1 - alpha) * row[1][x >>
ctx->hsub] + alpha * ctx->yuv_color[U];
+row[2][x >> ctx->hsub] = (1 - alpha) * row[2][x >>
ctx->hsub] + alpha * ctx->yuv_color[V];
+}
+}
+}
+}
+}
+}
+
static av_cold int init(AVFilterContext *ctx)
{
DrawBoxContext *s = ctx->priv;
@@ -217,58 +272,9 @@ static av_pure av_always_inline int
pixel_belongs_to_box(DrawBoxContext *s, int
static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
{
DrawBoxContext *s = inlink->dst->priv;
-int plane, x, y, xb = s->x, yb = s->y;
-unsigned char *row[4];
-
-if (s->have_alpha && s->replace) {
-for (y = FFMAX(yb, 0); y < frame->height && y < (yb + s->h); y++) {
-row[0] = frame->data[0] + y * frame->linesize[0];
-row[3] = frame->data[3] + y * frame->linesize[3];
-
-for (plane = 1; plane < 3; plane++)
-row[plane] = frame->data[plane] +
- frame->linesize[plane] * (y >> s->vsub);
-
-if (s->invert_color) {
-for (x = FFMAX(xb, 0); x < xb + s->w && x < frame->width; x++)
-if (pixel_belongs_to_box(s, x, y))
-row[0][x] = 0xff - row[0][x];
-} else {
-for (x = FFMAX(xb, 0); x < xb + s->w && x < frame->width; x++)
{
-if (pixel_belongs_to_box(s, x, y)) {
-row[0][x ] = s->yuv_color[Y];
-row[1][x >> s->hsub] = s->yuv_color[U];
-row[2][x >> s->hsub] = s->yuv_color[V];
-row[3][x ] = s->yuv_color[A];
-}
-}
-}
-}
-} else {
-for (y = FFMAX(yb, 0); y < frame->height && y < (yb + s->h); y++) {
-row[0] = frame->data[0] + y * frame->linesize[0];
-for (plane = 1; plane < 3; plane++)
-row[plane] = frame->data[plane] +
- frame->linesize[plane] * (y >> s->vsub);
-
-if (s->invert_color) {
-for (x = FFMAX(xb, 0); x < xb + s->w && x < frame->width; x++)
-if (pixel_belongs_to_box(s, x, y))
-row[0][x] = 0xff - row[0][x];
-} else {
-
[FFmpeg-devel] [PATCH 2/3] libavfilter: vf_drawbox filter support draw box with detection bounding boxes in side_data
This feature can be used with dnn detection by setting vf_drawbox's
option box_source=side_data_detection_bboxes, for example:
./ffmpeg -i face.jpeg -vf
dnn_detect=dnn_backend=openvino:model=face-detection-adas-0001.xml:\
input=data:output=detection_out:labels=face-detection-adas-0001.label,\
drawbox=box_source=side_data_detection_bboxes -y face_detect.jpeg
Signed-off-by: Ting Fu
---
doc/filters.texi | 8 +++
libavfilter/vf_drawbox.c | 52 ++--
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a218289ddd..f2ac8c4cc8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10356,6 +10356,14 @@ The x and y offset coordinates where the box is drawn.
@item h
The width and height of the drawn box.
+@item box_source
+Box source can be set as side_data_detection_bboxes if you want to use box
data in
+detection bboxes of side data.
+
+If @var{box_source} is set, the @var{x}, @var{y}, @var{width} and @var{height}
will be ignored and
+still use box data in detection bboxes of side data. So please do not use this
parameter if you were
+not sure about the box source.
+
@item t
The thickness of the drawn box.
diff --git a/libavfilter/vf_drawbox.c b/libavfilter/vf_drawbox.c
index 95e26191bd..fff78862e9 100644
--- a/libavfilter/vf_drawbox.c
+++ b/libavfilter/vf_drawbox.c
@@ -31,6 +31,7 @@
#include "libavutil/eval.h"
#include "libavutil/pixdesc.h"
#include "libavutil/parseutils.h"
+#include "libavutil/detection_bbox.h"
#include "avfilter.h"
#include "formats.h"
#include "internal.h"
@@ -79,8 +80,10 @@ typedef struct DrawBoxContext {
char *x_expr, *y_expr; ///< expression for x and y
char *w_expr, *h_expr; ///< expression for width and height
char *t_expr; ///< expression for thickness
+char *box_source_string; ///< string for box data source
int have_alpha;
int replace;
+enum AVFrameSideDataType box_source;
} DrawBoxContext;
static const int NUM_EXPR_EVALS = 5;
@@ -140,11 +143,30 @@ static void draw_region(AVFrame *frame, DrawBoxContext
*ctx, int left, int top,
}
}
+static enum AVFrameSideDataType box_source_string_parse(const char
*box_source_string)
+{
+av_assert0(box_source_string);
+if (!strcmp(box_source_string, "side_data_detection_bboxes")) {
+return AV_FRAME_DATA_DETECTION_BBOXES;
+} else {
+// will support side_data_regions_of_interest next
+return AVERROR(EINVAL);
+}
+}
+
static av_cold int init(AVFilterContext *ctx)
{
DrawBoxContext *s = ctx->priv;
uint8_t rgba_color[4];
+if (s->box_source_string) {
+s->box_source = box_source_string_parse(s->box_source_string);
+if ((int)s->box_source < 0) {
+av_log(ctx, AV_LOG_ERROR, "Error box source:
%s\n",s->box_source_string);
+return AVERROR(EINVAL);
+}
+}
+
if (!strcmp(s->color_str, "invert"))
s->invert_color = 1;
else if (av_parse_color(rgba_color, s->color_str, -1, ctx) < 0)
@@ -272,9 +294,34 @@ static av_pure av_always_inline int
pixel_belongs_to_box(DrawBoxContext *s, int
static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
{
DrawBoxContext *s = inlink->dst->priv;
+const AVDetectionBBoxHeader *header = NULL;
+const AVDetectionBBox *bbox;
+AVFrameSideData *sd;
+int loop = 1;
+
+if (s->box_source == AV_FRAME_DATA_DETECTION_BBOXES) {
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_DETECTION_BBOXES);
+if (sd) {
+header = (AVDetectionBBoxHeader *)sd->data;
+loop = header->nb_bboxes;
+} else {
+av_log(s, AV_LOG_WARNING, "No detection bboxes.\n");
+return ff_filter_frame(inlink->dst->outputs[0], frame);
+}
+}
-draw_region(frame, s, FFMAX(s->x, 0), FFMAX(s->y, 0), FFMIN(s->x + s->w,
frame->width),
-FFMIN(s->y + s->h, frame->height), pixel_belongs_to_box);
+for (int i = 0; i < loop; i++) {
+if (header) {
+bbox = av_get_detection_bbox(header, i);
+s->y = bbox->y;
+s->x = bbox->x;
+s->h = bbox->h;
+s->w = bbox->w;
+}
+
+draw_region(frame, s, FFMAX(s->x, 0), FFMAX(s->y, 0), FFMIN(s->x +
s->w, frame->width),
+FFMIN(s->y + s->h, frame->height), pixel_belongs_to_box);
+}
return ff_filter_frame(inlink->dst->outputs[0], frame);
}
@@ -329,6 +376,7 @@ static const AVOption drawbox_options[] = {
{ "thickness", "set the box thickness",
OFFSET(t_expr),AV_OPT_TYPE_STRING, { .str="3" }, 0, 0, FLAGS },
{ "t", "set the box thickness",
OFFSET(t_expr),AV_OPT_TYPE_STRING, { .str="3" }, 0, 0, FLAGS },
{ "replace", "replace color & alpha",
OFFSET(replace), AV_OPT_TYPE_BOOL, { .i64=0 }, 0, 1, FLAGS },
+
[FFmpeg-devel] [PATCH 3/3] libavfilter: vf_drawtext filter support draw text with detection bounding boxes in side_data
This feature can be used with dnn detection by setting vf_drawtext's option
text_source=side_data_detection_bboxes, for example:
./ffmpeg -i face.jpeg -vf
dnn_detect=dnn_backend=openvino:model=face-detection-adas-0001.xml:\
input=data:output=detection_out:labels=face-detection-adas-0001.label,drawbox=box_source=
side_data_detection_bboxes,drawtext=text_source=side_data_detection_bboxes:fontcolor=green:\
fontsize=40, -y face_detect.jpeg
Please note, the default fontsize of vf_drawtext is 12, which may be too
small to be seen clearly.
Signed-off-by: Ting Fu
---
doc/filters.texi | 8
libavfilter/vf_drawtext.c | 77 ---
2 files changed, 79 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index f2ac8c4cc8..d10e6de03d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10788,6 +10788,14 @@ parameter @var{text}.
If both @var{text} and @var{textfile} are specified, an error is thrown.
+@item text_source
+Text source should be set as side_data_detection_bboxes if you want to use
text data in
+detection bboxes of side data.
+
+If text source is set, @var{text} and @var{textfile} will be ignored and still
use
+text data in detection bboxes of side data. So please do not use this parameter
+if you are not sure about the text source.
+
@item reload
If set to 1, the @var{textfile} will be reloaded before each frame.
Be sure to update it atomically, or it may be read partially, or even fail.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 7ea057b812..382d589e26 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -55,6 +55,7 @@
#include "libavutil/time_internal.h"
#include "libavutil/tree.h"
#include "libavutil/lfg.h"
+#include "libavutil/detection_bbox.h"
#include "avfilter.h"
#include "drawutils.h"
#include "formats.h"
@@ -199,6 +200,8 @@ typedef struct DrawTextContext {
int tc24hmax; ///< 1 if timecode is wrapped to 24 hours,
0 otherwise
int reload; ///< reload text file for each frame
int start_number; ///< starting frame number for n/frame_num
var
+char *text_source_string; ///< the string to specify text data source
+enum AVFrameSideDataType text_source;
#if CONFIG_LIBFRIBIDI
int text_shaping; ///< 1 to shape the text before drawing it
#endif
@@ -246,6 +249,7 @@ static const AVOption drawtext_options[]= {
{ "alpha", "apply alpha while rendering", OFFSET(a_expr),
AV_OPT_TYPE_STRING, { .str = "1" }, .flags = FLAGS },
{"fix_bounds", "check and fix text coords to avoid clipping",
OFFSET(fix_bounds), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
{"start_number", "start frame number for n/frame_num variable",
OFFSET(start_number), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, FLAGS},
+{"text_source", "the source of text", OFFSET(text_source_string),
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS },
#if CONFIG_LIBFRIBIDI
{"text_shaping", "attempt to shape text before drawing",
OFFSET(text_shaping), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS},
@@ -690,6 +694,16 @@ out:
}
#endif
+static enum AVFrameSideDataType text_source_string_parse(const char
*text_source_string)
+{
+av_assert0(text_source_string);
+if (!strcmp(text_source_string, "side_data_detection_bboxes")) {
+return AV_FRAME_DATA_DETECTION_BBOXES;
+} else {
+return AVERROR(EINVAL);
+}
+}
+
static av_cold int init(AVFilterContext *ctx)
{
int err;
@@ -731,9 +745,28 @@ static av_cold int init(AVFilterContext *ctx)
s->text = av_strdup("");
}
+if (s->text_source_string) {
+s->text_source = text_source_string_parse(s->text_source_string);
+if ((int)s->text_source < 0) {
+av_log(ctx, AV_LOG_ERROR, "Error text source: %s\n",
s->text_source_string);
+return AVERROR(EINVAL);
+}
+}
+
+if (s->text_source == AV_FRAME_DATA_DETECTION_BBOXES) {
+if (s->text) {
+av_log(ctx, AV_LOG_WARNING, "Multiple texts provided, will use
text_source only\n");
+av_free(s->text);
+}
+s->text = av_mallocz(AV_DETECTION_BBOX_LABEL_NAME_MAX_SIZE *
+ (AV_NUM_DETECTION_BBOX_CLASSIFY + 1));
+if (!s->text)
+return AVERROR(ENOMEM);
+}
+
if (!s->text) {
av_log(ctx, AV_LOG_ERROR,
- "Either text, a valid file or a timecode must be provided\n");
+ "Either text, a valid file, a timecode or text source must be
provided\n");
return AVERROR(EINVAL);
}
@@ -1440,10 +1473,15 @@ continue_on_invalid2:
s->var_values[VAR_LINE_H] = s->var_values[VAR_LH] = s->max_glyph_h;
-s->x = s->var_values[VAR_X] = av_expr_eval(s->x_pexpr, s->var_values,
&s->prng);
-s->y = s->var_values[VAR_Y] = av_expr_eval(s->y_pexpr, s->var_values,
&s->prng);
Re: [FFmpeg-devel] [FFmpeg-cvslog] GSoC: Support fast guided filter.
Quoting Xuewei Meng (2021-05-13 05:59:34) > ffmpeg | branch: master | Xuewei Meng | Mon May 10 > 21:42:31 2021 +0800| [43d70feb788318b124418c5c666f2120ee5ca930] | committer: > Steven Liu > > GSoC: Support fast guided filter. This does not conform to our rules for commit messages. "GSoC" has no place there at all - it doesn't matter if the code was produces as a part of gsoc or wherever else. And the module prefix is missing. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] GSoC: Support fast guided filter.
> 2021年5月14日 下午5:12，Anton Khirnov 写道： > > Quoting Xuewei Meng (2021-05-13 05:59:34) >> ffmpeg | branch: master | Xuewei Meng | Mon May 10 >> 21:42:31 2021 +0800| [43d70feb788318b124418c5c666f2120ee5ca930] | committer: >> Steven Liu >> >> GSoC: Support fast guided filter. > > This does not conform to our rules for commit messages. > > "GSoC" has no place there at all - it doesn't matter if the code was > produces as a part of gsoc or wherever else. > And the module prefix is missing. Ah, my mistake, need revert and re-commit? > > -- > Anton Khirnov > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > Thanks Steven Liu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] GSoC: Support fast guided filter.
Quoting Steven Liu (2021-05-14 11:15:23) > > > > 2021年5月14日 下午5:12，Anton Khirnov 写道： > > > > Quoting Xuewei Meng (2021-05-13 05:59:34) > >> ffmpeg | branch: master | Xuewei Meng | Mon May 10 > >> 21:42:31 2021 +0800| [43d70feb788318b124418c5c666f2120ee5ca930] | > >> committer: Steven Liu > >> > >> GSoC: Support fast guided filter. > > > > This does not conform to our rules for commit messages. > > > > "GSoC" has no place there at all - it doesn't matter if the code was > > produces as a part of gsoc or wherever else. > > And the module prefix is missing. > Ah, my mistake, need revert and re-commit? No need to revert IMO, but please avoid this in the future. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add optional NIT table generation
Hi Marton, Il 2021-05-12 19:18 Marton Balint ha scritto: On Wed, 12 May 2021, Ubaldo Porcheddu wrote: Hi Marton, +} + +//private data +desc_len += 6 + 2; +*q++ = 0x5F; +*q++ = 4; +*q++ = 0x00; +*q++ = 0x00; +put16(&q, 40); What are these? I didn't find any official document about it but this seems to be the way many national (FR,IT,UK) broadcasters are writing the virtual channel private data header and the one recognized by many popular tv on the market. But this looks like a separate descriptor from the virtual channels (logical_channel_descriptor). I think it is better to remove it until it is more clear what it does, or maybe we add an extra mpegts flag like "nit_lcn_extra" ? logical_channel_descriptor() is documented for example here: https://forums.mediaspy.org/uploads/short-url/2wA2rGhOkh2yjlbcWMtcQizBv8L.pdf So you should use the terminology that is used in the document above. Ok, rewritten accordly. +ts->nit_period = av_rescale(ts->nit_period_us, PCR_TIME_BASE, AV_TIME_BASE); if (ts->mux_rate == 1) av_log(s, AV_LOG_VERBOSE, "muxrate VBR, "); @@ -1154,12 +1237,14 @@ static int mpegts_init(AVFormatContext *s) "sdt every %"PRId64" ms, pat/pmt every %"PRId64" ms\n", av_rescale(ts->sdt_period, 1000, PCR_TIME_BASE), av_rescale(ts->pat_period, 1000, PCR_TIME_BASE)); +if (ts->nit_enable > 0) +av_log(s, AV_LOG_VERBOSE, "nit every %"PRId64" ms\n", av_rescale(ts->nit_period, 1000, PCR_TIME_BASE)); Maybe you should continue the last log line which already describes the interval of various tables, and not start a new line. The idea is to have the NIT emission optional so I don't know if is a good idea to stat its periodical transmission on the same line, when disabled? I meant something like: av_log(s, AV_LOG_VERBOSE, "sdt every %"PRId64" ms, pat/pmt every %"PRId64" ms", av_rescale(ts->sdt_period, 1000, PCR_TIME_BASE), av_rescale(ts->pat_period, 1000, PCR_TIME_BASE)); if (nit_enabled) av_log(s, AV_LOG_VERBOSE, ", nit every %"PRId64" ms") av_log(s, AV_LOG_VERBOSE, "\n") Ok, clear now :) Also docs/muxers.texi update is missing for the new feature. is there any guide on what an how to add it? :) No guide, but should be straightforward based on the existing documentation of the mpegts muxer. You mean something like this (I am changing "nit_enable" option with "nit_emit" flag): --- ffmpeg.old/doc/muxers.texi 2021-05-09 18:20:04.0 +0200 +++ ffmpeg.new/doc/muxers.texi 2021-05-12 16:52:38.368198223 +0200 @@ -1876,6 +1876,8 @@ Conform to System B (DVB) instead of System A (ATSC). @item initial_discontinuity Mark the initial packet of each stream as discontinuity. +@item nit_emit +Emit NIT table. @end table ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/3] vf_guided patches
These patches address some issues in this filter; I initially wanted to nuke it after having found out that it runs into the av_assert1() in ff_filter_activate() (it seems that generic timeline support together with .activate is not supported, but I don't know what is wrong with it), but decided against it after having found out that more filters suffer from this (namely remap, afftdn and sidechaingate), so that support for this needs to be implemented. Needless to say this issue would have been found ages ago if these filters were covered by FATE. Even after this patchset, some more issues remain open: 1. This filter should probably use FRAMESYNC_DEFINE_CLASS() and add the corresponding .preinit; right now, the framesync options are unreachable. 2. If I am not mistaken, there is no guarantee for ff_framesync_dualinput_get() to return a ref_frame on success; so maybe one should check for this before ff_get_video_buffer() and just "return ff_filter_frame(outlink, main_frame);" in this scenario. 3. This filter allocates and frees quite a lot of buffers per frame (and duplicates this code); this should be avoided. Andreas Rheinhardt (3): avfilter/vf_guided: Don't free frame we don't own avfilter/vf_guided: Fix leak of frames avfilter/vf_guided: Don't needlessly copy properties, fix potential NPD libavfilter/vf_guided.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) -- 2.27.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avfilter/vf_guided: Don't needlessly copy properties, fix potential NPD
ref_frame is owned by the framesync structure and should therefore not
be modified; furthermore, these properties that are copied don't seem to
be used at all, so copying is unnecessary. Finally copying when the
destination frame is NULL gives a guaranteed segfault.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_guided.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
index ce78507eb6..35c518320c 100644
--- a/libavfilter/vf_guided.c
+++ b/libavfilter/vf_guided.c
@@ -333,10 +333,6 @@ static int process_frame(FFFrameSync *fs)
}
av_frame_copy_props(out_frame, main_frame);
-if (ctx->is_disabled || !ref_frame) {
-av_frame_copy_props(ref_frame, main_frame);
-}
-
for (int plane = 0; plane < s->nb_planes; plane++) {
if (!(s->planes & (1 << plane))) {
av_image_copy_plane(out_frame->data[plane],
out_frame->linesize[plane],
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avfilter/vf_guided: Don't free frame we don't own
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_guided.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
index e7c689e7be..e10d397f2e 100644
--- a/libavfilter/vf_guided.c
+++ b/libavfilter/vf_guided.c
@@ -329,7 +329,6 @@ static int process_frame(FFFrameSync *fs)
out_frame = ff_get_video_buffer(outlink, outlink->w, outlink->h);
if (!out_frame) {
av_frame_free(&main_frame);
-av_frame_free(&ref_frame);
return AVERROR(ENOMEM);
}
av_frame_copy_props(out_frame, main_frame);
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/metadata: add intuitive labels for metadata values
---
doc/filters.texi | 4 ++--
libavfilter/f_metadata.c | 8 ++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index ed0ffe91fc..1a8843fe4f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -25296,10 +25296,10 @@ The expression is evaluated through the eval API and
can contain the following
constants:
@table @option
-@item VALUE1
+@item VALUE1, FRAMEVAL
Float representation of @code{value} from metadata key.
-@item VALUE2
+@item VALUE2, USERVAL
Float representation of @code{value} as supplied by user in @code{value}
option.
@end table
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index 5fec7c3c56..e7c7b00118 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -61,12 +61,16 @@ enum MetadataFunction {
static const char *const var_names[] = {
"VALUE1",
"VALUE2",
+"FRAMEVAL",
+"USERVAL",
NULL
};
enum var_name {
VAR_VALUE1,
VAR_VALUE2,
+VAR_FRAMEVAL,
+VAR_USERVAL,
VAR_VARS_NB
};
@@ -172,8 +176,8 @@ static int parse_expr(MetadataContext *s, const char
*value1, const char *value2
if (sscanf(value1, "%lf", &f1) + sscanf(value2, "%lf", &f2) != 2)
return 0;
-s->var_values[VAR_VALUE1] = f1;
-s->var_values[VAR_VALUE2] = f2;
+s->var_values[VAR_VALUE1] = s->var_values[VAR_FRAMEVAL] = f1;
+s->var_values[VAR_VALUE2] = s->var_values[VAR_USERVAL] = f2;
return av_expr_eval(s->expr, s->var_values, NULL);
}
--
2.30.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avfilter/vf_guided: Fix leak of frames
Signed-off-by: Andreas Rheinhardt --- libavfilter/vf_guided.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c index e10d397f2e..ce78507eb6 100644 --- a/libavfilter/vf_guided.c +++ b/libavfilter/vf_guided.c @@ -353,6 +353,7 @@ static int process_frame(FFFrameSync *fs) s->planewidth[plane], s->planeheight[plane], main_frame->linesize[plane] / 2, ref_frame->linesize[plane] / 2, out_frame->linesize[plane] / 2, (1 << s->depth) - 1.f); } +av_frame_free(&main_frame); return ff_filter_frame(outlink, out_frame); } -- 2.27.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/guided: simplify subsampling assignment.
On 2021-05-14 09:18, Steven Liu wrote:
2021年5月14日 上午11:43，Gyan Doshi 写道：
Reduce option ranges to effective values.
---
Will reindent after this is applied.
libavfilter/vf_guided.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
index e7c689e7be..88bae5ab19 100644
--- a/libavfilter/vf_guided.c
+++ b/libavfilter/vf_guided.c
@@ -61,10 +61,10 @@ typedef struct GuidedContext {
static const AVOption guided_options[] = {
{ "radius", "set the box radius",
OFFSET(radius), AV_OPT_TYPE_INT, {.i64 = 3}, 1, 20, FLAGS },
{ "eps","set the regularization parameter (with square)",
OFFSET(eps),AV_OPT_TYPE_FLOAT, {.dbl = 0.01 }, 0.0,1, FLAGS },
-{ "mode", "set filtering mode (0: basic mode; 1: fast mode)", OFFSET(mode),
AV_OPT_TYPE_INT, {.i64 = BASIC}, 0, NB_MODES - 1, FLAGS, "mode" },
+{ "mode", "set filtering mode (0: basic mode; 1: fast mode)", OFFSET(mode),
AV_OPT_TYPE_INT, {.i64 = BASIC}, BASIC, NB_MODES - 1, FLAGS, "mode" },
{ "basic", "basic guided filter", 0,
AV_OPT_TYPE_CONST, {.i64 = BASIC}, 0,0, FLAGS, "mode" },
{ "fast", "fast guided filter", 0,
AV_OPT_TYPE_CONST, {.i64 = FAST }, 0,0, FLAGS, "mode" },
-{ "sub","subsampling ratio",
OFFSET(sub),AV_OPT_TYPE_INT, {.i64 = 1}, 1, 64, FLAGS },
+{ "sub","subsampling ratio for fast mode",
OFFSET(sub),AV_OPT_TYPE_INT, {.i64 = 4}, 2, 64, FLAGS },
{ "planes", "set planes to filter",
OFFSET(planes), AV_OPT_TYPE_INT, {.i64=1 }, 0, 0xF, FLAGS },
{ NULL }
};
@@ -160,24 +160,14 @@ static int config_input(AVFilterLink *inlink)
}
if (s->mode == BASIC) {
-if (s->sub != 1) {
-av_log(ctx, AV_LOG_WARNING, "Subsampling ratio is 1 in basic
mode.\n");
-s->sub = 1;
-}
+s->sub = 1;
}
else if (s->mode == FAST) {
-if (s->sub == 1) {
-av_log(ctx, AV_LOG_WARNING, "Subsampling ratio is larger than 1 in fast
mode.\n");
-s->sub = 4;
-}
-if (s->radius >= s->sub)
-s->radius = s->radius / s->sub;
-else {
-s->radius = 1;
-}
-}
-else {
-return AVERROR_BUG;
+ if (s->radius >= s->sub)
+ s->radius = s->radius / s->sub;
+ else {
+ s->radius = 1;
+ }
}
s->depth = desc->comp[0].depth;
--
2.30.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe”.
lgtm
Applied as 93ddb9b6177ab668cae92f9b117a91b05cde386f
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_guided: add null pointer check of ref_frame and main_frame
Steven Liu:
> fix CID: 1484785
> check ref_frame and main_frame before use them
> Ignore previous patch please, this should better than that.
>
> Signed-off-by: Steven Liu
> ---
> libavfilter/vf_guided.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
> index e7c689e7be..0868b9cd4f 100644
> --- a/libavfilter/vf_guided.c
> +++ b/libavfilter/vf_guided.c
> @@ -334,7 +334,7 @@ static int process_frame(FFFrameSync *fs)
> }
> av_frame_copy_props(out_frame, main_frame);
>
> -if (ctx->is_disabled || !ref_frame) {
> +if (ctx->is_disabled && ref_frame && main_frame) {
> av_frame_copy_props(ref_frame, main_frame);
> }
>
>
1. "Ignore previous patch please, this should better than that." does
not belong in the commit message.
2. Checking for main_frame is unnecessary, as that is always set on
success of ff_framesync_dualinput_get().
3. Checking for ctx->is_disabled should be unnecessary, as this filter
has the AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC (and not
AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL) set, which means that this
function is not called if this filter is disabled.
4. We actually do not own ref_frame, so it is doubtful whether we are
allowed to modify it.
5. Why are these properties copied at all? They seem unused.
As you probably already guessed, I looked at this myself, which resulted
in this patchset:
http://ffmpeg.org/pipermail/ffmpeg-devel/2021-May/280293.html (Notice
that I am not very well versed in libavfilter APIs.).
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/libx264: Fix redundant setting of caps_internal
Exists since 8a129077cc37202a00dd666bd5365c3f61ea2e80.
Fixes a -Winitializer-overrides warning when building with Clang.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libx264.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 22c91d8df7..1c27f7b441 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -1153,7 +1153,6 @@ AVCodec ff_libx264_encoder = {
.close= X264_close,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
-.caps_internal= FF_CODEC_CAP_AUTO_THREADS,
.priv_class = &x264_class,
.defaults = x264_defaults,
#if X264_BUILD < 153
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add optional NIT table generation
Hi, > Hi Marton, > > Il 2021-05-12 19:18 Marton Balint ha scritto: > > On Wed, 12 May 2021, Ubaldo Porcheddu wrote: > > > >> Hi Marton, > >> > +} > + > +//private data > +desc_len += 6 + 2; > +*q++ = 0x5F; > +*q++ = 4; > +*q++ = 0x00; > +*q++ = 0x00; > +put16(&q, 40); > >>> > >>> What are these? > >> > >> I didn't find any official document about it but this seems to be the > >> way many national (FR,IT,UK) broadcasters are writing the virtual > >> channel private data header and the one recognized by many popular tv > >> on the market. > > > > But this looks like a separate descriptor from the virtual channels > > (logical_channel_descriptor). > > I think it is better to remove it until it is more clear what it does, > or maybe we add an extra mpegts flag like "nit_lcn_extra" ? > The private data specifier descriptor is needed for the TV to correctly process the LCN descriptor. When it is needed, you have to include both or none. Also, in the Scandinavian countries, that use the NORDIG spec, the LCN descriptor has a different format, though I think the European format may still be understood. Specs can be found here for NORDIG : https://nordig.org/wp-content/uploads/2017/03/NorDig-Unified_ver_2_6.pdf Specs for the European LCN can be found here, it's the French spec, but the rest are the same: https://www.csa.fr/web/index.php/content/download/253685/723620/version/1/file/CSA-Signalling-Profilev3.4.pdf Specs for the Australian LCN descriptor can be found here: https://www.freetv.com.au/wp-content/uploads/2019/08/OP-41-LCN-Descriptor-Issue-8-July-2016.pdf The rules, as far as I know them are: NORDIG --> Private Data Specifier = 0x0029, LCN Descriptor Tag = 0x83 (legacy), 0x87 (Nordig version) United Kingdom --> Private Data Specifier = 0x233A, LCN Descriptor Tag = 0x83 Rest of Europe + Most of the World --> Private Data Specifier = 0x0028, LCN Descriptor Tag = 0x83 Australia --> _Do_not_include_Private_data_specifier_descriptor_ , LCN Descriptor Tag = 0x83 My suggestion would be to add an "LCN_mode" parameters, with values: NO_LCN, Australia,UK,Nordig, etc Regards David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avfilter/vf_guided: Don't free frame we don't own
> 2021年5月14日 下午6:18，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/vf_guided.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
> index e7c689e7be..e10d397f2e 100644
> --- a/libavfilter/vf_guided.c
> +++ b/libavfilter/vf_guided.c
> @@ -329,7 +329,6 @@ static int process_frame(FFFrameSync *fs)
> out_frame = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> if (!out_frame) {
> av_frame_free(&main_frame);
> -av_frame_free(&ref_frame);
> return AVERROR(ENOMEM);
> }
> av_frame_copy_props(out_frame, main_frame);
> --
> 2.27.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
Looks simply after patchset, lgtm
Thanks
Steven Liu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 12/12] lavf/framecrcenc: do not hash side data
On 5/14/2021 5:01 AM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2021-05-10 16:06:01)
On Sun, Apr 25, 2021 at 09:03:20AM +0200, Anton Khirnov wrote:
There are no guarantees that all side data types have the same
representation on all platforms.
@@ -65,63 +51,6 @@ static int framecrc_write_packet(struct AVFormatContext *s,
AVPacket *pkt)
pkt->stream_index, pkt->dts, pkt->pts, pkt->duration, pkt->size,
crc);
if (pkt->flags != AV_PKT_FLAG_KEY)
av_strlcatf(buf, sizeof(buf), ", F=0x%0X", pkt->flags);
-if (pkt->side_data_elems) {
-int i;
-av_strlcatf(buf, sizeof(buf), ", S=%d", pkt->side_data_elems);
The number and type of the side data elements should not be affected
by the problem described.
Maybe we could leave that. Bugs could manifest as the absence or addition
of side data, seeing that in framecrc_write_packet() output may be usefull
No strong opinion here - patches welcome I guess.
I can do it, but it will be a "breaking" change, assuming there are
parsers that read the output of this muxer.
Right now you removed all the trailing properties, which while also
breaking, a sane parser made for the old output can simply assume that
the line was truncated. But if we re-add the side data amount and sizes
for each of them without the hashes, things can get parsed the wrong way.
Namely, it used to be:
0, 0, 0, 16,57008, 0x43416399, S=2,8,
0x08e5014f, 88, 0xd65a04db
And now it will be something like:
0, 0, 0, 16,57008, 0x43416399, S=2,8,
88
So the question is, do we care about this? The framehash/framemd5 muxer
prints a version number, which lets us make breaking additions parsers
can then properly handle. Should we then just consider that parsing
framecrc output is not a supported scenario?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] ffprobe as library rather than CLI
On 12.05.2021 15:52, Timo Rothenpieler wrote: On 12.05.2021 15:19, Samuel Marks wrote: Started hacking around to make it work. So I changed the `main` to a: extern int ffprobe(int argc, char **argv); Then I added a header with a prototype of the same, and started messing with vcpkg + CMake to try and get it to build correctly. That's not going to work. The whole thing is not designed to be called more than once, and you can be close to certain that it's going to fail miserably and in unexpected ways. Use the libraries if you want to integrate ffmpeg functionality into your own application. Another alternative would be to run ffprobe as a separate process using fork() and execv() on Linux, or CreateProcessW() on Windows. Optionally you can use pipes to redirect the stdout of ffprobe to your parent application. A quick online search finds this code example for C (have not tested it but the general concept looks fine to me): https://stackoverflow.com/a/83456 Good luck, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add optional NIT table generation
Hola David,
thank you for clarifying it, maybe we leave 0x28 by default and add a
"nit_private" option for: none, NorDig, UK ?
Here is the function so far:
+static void mpegts_write_nit(AVFormatContext *s)
+{
+int i, lcn_count=0;
+MpegTSWrite *ts = s->priv_data;
+uint8_t data[SECTION_LENGTH], *q, *desc_len_ptr, *loop_len_ptr,
*lcn_len_ptr;
+AVDictionaryEntry *logical_channel;
+AVProgram *program;
+
+q = data;
+
+//network name
+put16(&q, 0xf000 | ts->provider_name[0]);
+*q++ = 0x40;
+putbuf(&q, ts->provider_name, ts->provider_name[0]+1);
+
+//TS loop
+loop_len_ptr = q;
+q += 2;
+put16(&q, ts->transport_stream_id);
+put16(&q, ts->original_network_id);
+
+//transport descriptor
+desc_len_ptr = q;
+q += 2;
+
+//service list descriptor
+*q++ = 0x41;
+*q++ = 3 * ts->nb_services;
+for(i = 0; i < ts->nb_services; i++) {
+put16(&q, ts->services[i]->sid);
+*q++ = ts->service_type;
+program = s->programs[i];
+if (av_dict_get(program->metadata, "logical_channel_number",
NULL, 0))
+lcn_count++;
+}
+
+if (lcn_count > 0) {
+//logical channel descriptor
+*q++ = 0x83;
+lcn_len_ptr = q++;
+for (i = 0; i < ts->nb_services; i++) {
+program = s->programs[i];
+logical_channel = av_dict_get(program->metadata,
"logical_channel_number", NULL, 0);
+if (logical_channel) {
+put16(&q, ts->services[i]->sid);
+put16(&q, 0xfc00 | atoi(logical_channel->value));
+}
+}
+*lcn_len_ptr = lcn_count * 4;
+//private data specifier descriptor
+*q++ = 0x5F;
+*q++ = 0x04;
+put16(&q, 0x00);
+put16(&q, 0x28);
+}
+
+//calculate lengths
+put16(&desc_len_ptr, 0xf000 | q - (desc_len_ptr+2));
+put16(&loop_len_ptr, 0xf000 | q - (loop_len_ptr+2));
+
+mpegts_write_section1(&ts->nit, NIT_TID, ts->original_network_id,
ts->tables_version, 0, 0,
+ data, q - data);
+}
Hi,
Hi Marton,
Il 2021-05-12 19:18 Marton Balint ha scritto:
> On Wed, 12 May 2021, Ubaldo Porcheddu wrote:
>
>> Hi Marton,
>>
+}
+
+//private data
+desc_len += 6 + 2;
+*q++ = 0x5F;
+*q++ = 4;
+*q++ = 0x00;
+*q++ = 0x00;
+put16(&q, 40);
>>>
>>> What are these?
>>
>> I didn't find any official document about it but this seems to be the
>> way many national (FR,IT,UK) broadcasters are writing the virtual
>> channel private data header and the one recognized by many popular tv
>> on the market.
>
> But this looks like a separate descriptor from the virtual channels
> (logical_channel_descriptor).
I think it is better to remove it until it is more clear what it does,
or maybe we add an extra mpegts flag like "nit_lcn_extra" ?
The private data specifier descriptor is needed for the TV to
correctly process the LCN descriptor. When it is needed, you have to
include both or none.
Also, in the Scandinavian countries, that use the NORDIG spec, the LCN
descriptor has a different format, though I think the European format
may still be understood.
Specs can be found here for NORDIG :
https://nordig.org/wp-content/uploads/2017/03/NorDig-Unified_ver_2_6.pdf
Specs for the European LCN can be found here, it's the French spec,
but the rest are the same:
https://www.csa.fr/web/index.php/content/download/253685/723620/version/1/file/CSA-Signalling-Profilev3.4.pdf
Specs for the Australian LCN descriptor can be found here:
https://www.freetv.com.au/wp-content/uploads/2019/08/OP-41-LCN-Descriptor-Issue-8-July-2016.pdf
The rules, as far as I know them are:
NORDIG --> Private Data Specifier = 0x0029, LCN Descriptor Tag =
0x83 (legacy), 0x87 (Nordig version)
United Kingdom --> Private Data Specifier = 0x233A, LCN
Descriptor Tag = 0x83
Rest of Europe + Most of the World --> Private Data Specifier =
0x0028, LCN Descriptor Tag = 0x83
Australia --> _Do_not_include_Private_data_specifier_descriptor_ , LCN
Descriptor Tag = 0x83
My suggestion would be to add an "LCN_mode" parameters, with values:
NO_LCN, Australia,UK,Nordig, etc
Regards
David
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 12/12] lavf/framecrcenc: do not hash side data
On Fri, May 14, 2021 at 09:42:10AM -0300, James Almer wrote:
> On 5/14/2021 5:01 AM, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2021-05-10 16:06:01)
> > > On Sun, Apr 25, 2021 at 09:03:20AM +0200, Anton Khirnov wrote:
> > > > There are no guarantees that all side data types have the same
> > > > representation on all platforms.
> > >
> > > > @@ -65,63 +51,6 @@ static int framecrc_write_packet(struct
> > > > AVFormatContext *s, AVPacket *pkt)
> > > >pkt->stream_index, pkt->dts, pkt->pts, pkt->duration,
> > > > pkt->size, crc);
> > > > if (pkt->flags != AV_PKT_FLAG_KEY)
> > > > av_strlcatf(buf, sizeof(buf), ", F=0x%0X", pkt->flags);
> > > > -if (pkt->side_data_elems) {
> > > > -int i;
> > > > -av_strlcatf(buf, sizeof(buf), ", S=%d", pkt->side_data_elems);
> > >
> > > The number and type of the side data elements should not be affected
> > > by the problem described.
> > > Maybe we could leave that. Bugs could manifest as the absence or addition
> > > of side data, seeing that in framecrc_write_packet() output may be usefull
> >
> > No strong opinion here - patches welcome I guess.
>
> I can do it, but it will be a "breaking" change, assuming there are parsers
> that read the output of this muxer.
does anyone know of such parsers ?
or does anyone have an idea what such parser could be used for ?
> Right now you removed all the trailing properties, which while also
> breaking, a sane parser made for the old output can simply assume that the
> line was truncated. But if we re-add the side data amount and sizes for each
> of them without the hashes, things can get parsed the wrong way.
>
> Namely, it used to be:
> > 0, 0, 0, 16,57008, 0x43416399, S=2,8,
> > 0x08e5014f, 88, 0xd65a04db
>
> And now it will be something like:
> > 0, 0, 0, 16,57008, 0x43416399, S=2,8,
> > 88
>
> So the question is, do we care about this? The framehash/framemd5 muxer
> prints a version number, which lets us make breaking additions parsers can
> then properly handle. Should we then just consider that parsing framecrc
> output is not a supported scenario?
the version should probably be increased
we also could leave the checksum in there but pick one that does not change
when 0 padding is added or endian changes, an example would be a sum of all
bytes. But in the strictest interpretation i guess that still would not be
platform independant.
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 12/12] lavf/framecrcenc: do not hash side data
On 5/14/2021 3:16 PM, Michael Niedermayer wrote:
On Fri, May 14, 2021 at 09:42:10AM -0300, James Almer wrote:
On 5/14/2021 5:01 AM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2021-05-10 16:06:01)
On Sun, Apr 25, 2021 at 09:03:20AM +0200, Anton Khirnov wrote:
There are no guarantees that all side data types have the same
representation on all platforms.
@@ -65,63 +51,6 @@ static int framecrc_write_packet(struct AVFormatContext *s,
AVPacket *pkt)
pkt->stream_index, pkt->dts, pkt->pts, pkt->duration,
pkt->size, crc);
if (pkt->flags != AV_PKT_FLAG_KEY)
av_strlcatf(buf, sizeof(buf), ", F=0x%0X", pkt->flags);
-if (pkt->side_data_elems) {
-int i;
-av_strlcatf(buf, sizeof(buf), ", S=%d", pkt->side_data_elems);
The number and type of the side data elements should not be affected
by the problem described.
Maybe we could leave that. Bugs could manifest as the absence or addition
of side data, seeing that in framecrc_write_packet() output may be usefull
No strong opinion here - patches welcome I guess.
I can do it, but it will be a "breaking" change, assuming there are parsers
that read the output of this muxer.
does anyone know of such parsers ?
No, it's hypothetical.
or does anyone have an idea what such parser could be used for ?
Users that can't or don't want to write programs using the libraries and
find it easier to write perl scripts that parse the output of CLI like
ffmpeg and ffprobe.
Technically speaking, many of our regression tests do exactly that.
Right now you removed all the trailing properties, which while also
breaking, a sane parser made for the old output can simply assume that the
line was truncated. But if we re-add the side data amount and sizes for each
of them without the hashes, things can get parsed the wrong way.
Namely, it used to be:
0, 0, 0, 16,57008, 0x43416399, S=2,8,
0x08e5014f, 88, 0xd65a04db
And now it will be something like:
0, 0, 0, 16,57008, 0x43416399, S=2,8,
88
So the question is, do we care about this? The framehash/framemd5 muxer
prints a version number, which lets us make breaking additions parsers can
then properly handle. Should we then just consider that parsing framecrc
output is not a supported scenario?
the version should probably be increased
framemd5/framehash != framecrc. The former is versioned, but the latter,
which this discussion is about, is not, so we should decide if that
means its output is to be considered fixed or not.
I'm inclined to say it shouldn't. There's framehash for a versioned
output that's guaranteed to not change, which also supports adler32 (the
algorithm used by framecrc).
we also could leave the checksum in there but pick one that does not change
when 0 padding is added or endian changes, an example would be a sum of all
bytes. But in the strictest interpretation i guess that still would not be
platform independant.
Thanks
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: enhance parsing timestamps
On Fri, 14 May 2021, Anton Khirnov wrote:
Quoting Marton Balint (2021-05-12 20:55:45)
Take into account timezone. Use millisecond precision. Maybe we could also use
nanosecond, but there were some float rounding concerns.
Signed-off-by: Marton Balint
---
libavformat/flvdec.c | 13 ++---
tests/ref/fate/flv-demux | 2 +-
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index ddaceaafe4..3791687072 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -28,6 +28,7 @@
#include "libavutil/channel_layout.h"
#include "libavutil/dict.h"
#include "libavutil/opt.h"
+#include "libavutil/internal.h"
#include "libavutil/intfloat.h"
#include "libavutil/mathematics.h"
#include "libavutil/time_internal.h"
@@ -682,17 +683,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream
*astream,
} else if (amf_type == AMF_DATA_TYPE_STRING) {
av_dict_set(&s->metadata, key, str_val, 0);
} else if (amf_type == AMF_DATA_TYPE_DATE) {
-time_t time;
-struct tm t;
-char datestr[128];
-time = date.milliseconds / 1000; // to seconds
-gmtime_r(&time, &t);
-
-// timezone is ignored, since there is no easy way to offset the
UTC
-// timestamp into the specified timezone
-strftime(datestr, sizeof(datestr), "%Y-%m-%dT%H:%M:%SZ", &t);
-
-av_dict_set(&s->metadata, key, datestr, 0);
+avpriv_dict_set_timestamp(&s->metadata, key, -date.timezone *
6000LL + 1000 * (int64_t)date.milliseconds);
This is wrong -- date.milliseconds is in UTC, if you add the timezone
offset it will no longer be in UTC.
Indeed, I misunderstood the specs... MediaInfo also ignores the time zone.
Will send a v2.
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: Restore DTS correction for VP9 copies
Hi, On Wed, May 12, 2021 at 8:33 PM Danny Wu wrote: > > > Shouldn't google not produce invalid files? Also, can you link one of > > these videos to test this issue? > I filed a bug for this (b/188197059). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/flvdec: use milisecond precision for parsing timestamps
Also use helper function to set the timestamp. Maybe we could also use
nanosecond precision, but there were some float rounding concerns.
Signed-off-by: Marton Balint
---
libavformat/flvdec.c | 11 ++-
tests/ref/fate/flv-demux | 2 +-
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index ddaceaafe4..6bd6c8c944 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -28,6 +28,7 @@
#include "libavutil/channel_layout.h"
#include "libavutil/dict.h"
#include "libavutil/opt.h"
+#include "libavutil/internal.h"
#include "libavutil/intfloat.h"
#include "libavutil/mathematics.h"
#include "libavutil/time_internal.h"
@@ -682,17 +683,9 @@ static int amf_parse_object(AVFormatContext *s, AVStream
*astream,
} else if (amf_type == AMF_DATA_TYPE_STRING) {
av_dict_set(&s->metadata, key, str_val, 0);
} else if (amf_type == AMF_DATA_TYPE_DATE) {
-time_t time;
-struct tm t;
-char datestr[128];
-time = date.milliseconds / 1000; // to seconds
-gmtime_r(&time, &t);
-
// timezone is ignored, since there is no easy way to offset the
UTC
// timestamp into the specified timezone
-strftime(datestr, sizeof(datestr), "%Y-%m-%dT%H:%M:%SZ", &t);
-
-av_dict_set(&s->metadata, key, datestr, 0);
+avpriv_dict_set_timestamp(&s->metadata, key, 1000 *
(int64_t)date.milliseconds);
}
}
diff --git a/tests/ref/fate/flv-demux b/tests/ref/fate/flv-demux
index 827b56ea09..09451c11e9 100644
--- a/tests/ref/fate/flv-demux
+++ b/tests/ref/fate/flv-demux
@@ -605,4 +605,4 @@
packet|codec_type=audio|stream_index=1|pts=11656|pts_time=11.656000|dts=11656|dt
packet|codec_type=video|stream_index=0|pts=11678|pts_time=11.678000|dts=11678|dts_time=11.678000|duration=33|duration_time=0.033000|size=1190|pos=510794|flags=__|data_hash=CRC32:a0206c90
stream|index=0|codec_name=h264|profile=77|codec_type=video|codec_tag_string=[0][0][0][0]|codec_tag=0x|width=426|height=240|coded_width=426|coded_height=240|closed_captions=0|has_b_frames=1|sample_aspect_ratio=1:1|display_aspect_ratio=71:40|pix_fmt=yuv420p|level=21|color_range=unknown|color_space=unknown|color_transfer=unknown|color_primaries=unknown|chroma_location=left|field_order=progressive|refs=1|is_avc=true|nal_length_size=4|id=N/A|r_frame_rate=3/1001|avg_frame_rate=30/1|time_base=1/1000|start_pts=0|start_time=0.00|duration_ts=N/A|duration=N/A|bit_rate=393929|max_bit_rate=N/A|bits_per_raw_sample=8|nb_frames=N/A|nb_read_frames=N/A|nb_read_packets=351|extradata_hash=CRC32:07b85ca9|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnail
s=0|disposition:captions=0|disposition:descriptions=0|disposition:metadata=0|disposition:dependent=0|disposition:still_image=0
stream|index=1|codec_name=aac|profile=1|codec_type=audio|codec_tag_string=[0][0][0][0]|codec_tag=0x|sample_fmt=fltp|sample_rate=22050|channels=2|channel_layout=stereo|bits_per_sample=0|id=N/A|r_frame_rate=0/0|avg_frame_rate=0/0|time_base=1/1000|start_pts=0|start_time=0.00|duration_ts=N/A|duration=N/A|bit_rate=67874|max_bit_rate=N/A|bits_per_raw_sample=N/A|nb_frames=N/A|nb_read_frames=N/A|nb_read_packets=252|extradata_hash=CRC32:d039c029|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnails=0|disposition:captions=0|disposition:descriptions=0|disposition:metadata=0|disposition:dependent=0|disposition:still_image=0
-format|filename=Enigma_Principles_of_Lust-part.flv|nb_streams=2|nb_programs=0|format_name=flv|start_time=0.00|duration=210.20|size=512000|bit_rate=19485|probe_score=100|tag:hasKeyframes=true|tag:hasMetadata=true|tag:datasize=11970544|tag:hasVideo=true|tag:canSeekToEnd=false|tag:lasttimestamp=210|tag:lastkeyframetimestamp=210|tag:audiosize=1791332|tag:hasAudio=true|tag:audiodelay=0|tag:videosize=10176110|tag:metadatadate=2011-02-27T11:00:33Z|tag:metadatacreator=inlet
media FLVTool2 v1.0.6 -
http://www.inlet-media.de/flvtool2|tag:hasCuePoints=false
+format|filename=Enigma_Principles_of_Lust-part.flv|nb_streams=2|nb_programs=0|format_name=flv|start_time=0.00|duration=210.20|size=512000|bit_rate=19485|probe_score=100|tag:hasKeyframes=true|tag:hasMetadata=true|tag:datasize=11970544|tag:hasVideo=true|tag:canSeekToEnd=false|tag:lasttimestamp=210|tag:lastkeyframetimestamp=210|tag:audiosize=1791332|tag:hasAudio=true|tag:audiodelay=0|tag:videosize=10176110|tag:metadatadate=2011-02-27T11:00:33.125
[FFmpeg-devel] [PATCH] avformat/hls Implement support for using AVSEEK_FLAG_BACKWARD when seeking
Before, seeking in hls streams would always seek to the next keyframe after the
given timestamp.
With this fix, if AVSEEK_FLAG_BACKWARD is set, seeking will be to the first
keyframe of the
segment containing the given timestamp. This fixes #6850.
---
libavformat/hls.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 8fc6924c90..3f1fd2cb70 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2199,10 +2199,15 @@ static int hls_read_packet(AVFormatContext *s, AVPacket
*pkt)
tb = get_timebase(pls);
ts_diff = av_rescale_rnd(pls->pkt->dts, AV_TIME_BASE,
-tb.den, AV_ROUND_DOWN) -
-pls->seek_timestamp;
-if (ts_diff >= 0 && (pls->seek_flags & AVSEEK_FLAG_ANY ||
-pls->pkt->flags & AV_PKT_FLAG_KEY)) {
+ tb.den, AV_ROUND_DOWN) -
+ pls->seek_timestamp;
+/* If AVSEEK_FLAG_BACKWARD set and not AVSEEK_FLAG_ANY,
+ * we return the first keyframe encountered */
+if ((pls->seek_flags & AVSEEK_FLAG_BACKWARD &&
+ !(pls->seek_flags & AVSEEK_FLAG_ANY) &&
+ pls->pkt->flags & AV_PKT_FLAG_KEY) ||
+(ts_diff >= 0 && (pls->seek_flags & AVSEEK_FLAG_ANY ||
+ pls->pkt->flags & AV_PKT_FLAG_KEY)))
{
pls->seek_timestamp = AV_NOPTS_VALUE;
break;
}
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 12/12] lavf/framecrcenc: do not hash side data
James Almer:
> On 5/14/2021 3:16 PM, Michael Niedermayer wrote:
>> On Fri, May 14, 2021 at 09:42:10AM -0300, James Almer wrote:
>>> On 5/14/2021 5:01 AM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2021-05-10 16:06:01)
> On Sun, Apr 25, 2021 at 09:03:20AM +0200, Anton Khirnov wrote:
>> There are no guarantees that all side data types have the same
>> representation on all platforms.
>
>> @@ -65,63 +51,6 @@ static int framecrc_write_packet(struct
>> AVFormatContext *s, AVPacket *pkt)
>> pkt->stream_index, pkt->dts, pkt->pts,
>> pkt->duration, pkt->size, crc);
>> if (pkt->flags != AV_PKT_FLAG_KEY)
>> av_strlcatf(buf, sizeof(buf), ", F=0x%0X", pkt->flags);
>> - if (pkt->side_data_elems) {
>> - int i;
>> - av_strlcatf(buf, sizeof(buf), ", S=%d",
>> pkt->side_data_elems);
>
> The number and type of the side data elements should not be affected
> by the problem described.
> Maybe we could leave that. Bugs could manifest as the absence or
> addition
> of side data, seeing that in framecrc_write_packet() output may be
> usefull
No strong opinion here - patches welcome I guess.
>>>
>>> I can do it, but it will be a "breaking" change, assuming there are
>>> parsers
>>> that read the output of this muxer.
>>
>> does anyone know of such parsers ?
>
> No, it's hypothetical.
>
>> or does anyone have an idea what such parser could be used for ?
>
> Users that can't or don't want to write programs using the libraries and
> find it easier to write perl scripts that parse the output of CLI like
> ffmpeg and ffprobe.
>
> Technically speaking, many of our regression tests do exactly that.
>
>>
>>
>>> Right now you removed all the trailing properties, which while also
>>> breaking, a sane parser made for the old output can simply assume
>>> that the
>>> line was truncated. But if we re-add the side data amount and sizes
>>> for each
>>> of them without the hashes, things can get parsed the wrong way.
>>>
>>> Namely, it used to be:
0, 0, 0, 16, 57008, 0x43416399,
S=2, 8, 0x08e5014f, 88, 0xd65a04db
>>>
>>> And now it will be something like:
0, 0, 0, 16, 57008, 0x43416399,
S=2, 8, 88
>>>
>>> So the question is, do we care about this? The framehash/framemd5 muxer
>>> prints a version number, which lets us make breaking additions
>>> parsers can
>>> then properly handle. Should we then just consider that parsing framecrc
>>> output is not a supported scenario?
>>
>> the version should probably be increased
>
> framemd5/framehash != framecrc. The former is versioned, but the latter,
> which this discussion is about, is not, so we should decide if that
> means its output is to be considered fixed or not.
>
> I'm inclined to say it shouldn't. There's framehash for a versioned
> output that's guaranteed to not change, which also supports adler32 (the
> algorithm used by framecrc).
>
framehash btw uses it properly, whereas framecrc initializes the adler32
checksum to zero (it should be one). Last time I checked, switching FATE
to framehash (or making framecrc initialize the checksum to 1) would
amount to a diff of about 7 lines, so I didn't do it.
Of course, framehash has the same problems with side-data hashing, but
it has a version option so that we can make changes.
If we decide to switch FATE to framehash, we should probably deprecate
framecrc. I could make this change.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 12/12] lavf/framecrcenc: do not hash side data
Quoting James Almer (2021-05-14 14:42:10)
> On 5/14/2021 5:01 AM, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2021-05-10 16:06:01)
> >> On Sun, Apr 25, 2021 at 09:03:20AM +0200, Anton Khirnov wrote:
> >>> There are no guarantees that all side data types have the same
> >>> representation on all platforms.
> >>
> >>> @@ -65,63 +51,6 @@ static int framecrc_write_packet(struct
> >>> AVFormatContext *s, AVPacket *pkt)
> >>>pkt->stream_index, pkt->dts, pkt->pts, pkt->duration,
> >>> pkt->size, crc);
> >>> if (pkt->flags != AV_PKT_FLAG_KEY)
> >>> av_strlcatf(buf, sizeof(buf), ", F=0x%0X", pkt->flags);
> >>> -if (pkt->side_data_elems) {
> >>> -int i;
> >>> -av_strlcatf(buf, sizeof(buf), ", S=%d", pkt->side_data_elems);
> >>
> >> The number and type of the side data elements should not be affected
> >> by the problem described.
> >> Maybe we could leave that. Bugs could manifest as the absence or addition
> >> of side data, seeing that in framecrc_write_packet() output may be usefull
> >
> > No strong opinion here - patches welcome I guess.
>
> I can do it, but it will be a "breaking" change, assuming there are
> parsers that read the output of this muxer.
Imo frame* muxers are for testing purposes only and should not be
considered stable.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 12/12] lavf/framecrcenc: do not hash side data
On 5/14/2021 5:28 PM, Anton Khirnov wrote:
Quoting James Almer (2021-05-14 14:42:10)
On 5/14/2021 5:01 AM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2021-05-10 16:06:01)
On Sun, Apr 25, 2021 at 09:03:20AM +0200, Anton Khirnov wrote:
There are no guarantees that all side data types have the same
representation on all platforms.
@@ -65,63 +51,6 @@ static int framecrc_write_packet(struct AVFormatContext *s,
AVPacket *pkt)
pkt->stream_index, pkt->dts, pkt->pts, pkt->duration,
pkt->size, crc);
if (pkt->flags != AV_PKT_FLAG_KEY)
av_strlcatf(buf, sizeof(buf), ", F=0x%0X", pkt->flags);
-if (pkt->side_data_elems) {
-int i;
-av_strlcatf(buf, sizeof(buf), ", S=%d", pkt->side_data_elems);
The number and type of the side data elements should not be affected
by the problem described.
Maybe we could leave that. Bugs could manifest as the absence or addition
of side data, seeing that in framecrc_write_packet() output may be usefull
No strong opinion here - patches welcome I guess.
I can do it, but it will be a "breaking" change, assuming there are
parsers that read the output of this muxer.
Imo frame* muxers are for testing purposes only and should not be
considered stable.
Agree for framecrc as i mentioned in my other email, but framehash is
versioned, so that one is stable.
Will send a patch to re-add side data amount of sizes to framecrc, then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/framecrcenc: print basic side data information again
This partially reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.
Signed-off-by: James Almer
---
libavformat/framecrcenc.c | 8 +
tests/ref/fate/copy-trac3074 | 2 +-
tests/ref/fate/cover-art-mp3-id3v2-remux | 2 +-
tests/ref/fate/gapless-mp3| 6 +-
tests/ref/fate/id3v2-priv-remux | 2 +-
.../fate/matroska-mastering-display-metadata | 4 +-
tests/ref/fate/matroska-spherical-mono-remux | 4 +-
tests/ref/fate/matroska-vp8-alpha-remux | 14 +-
tests/ref/fate/mov-cover-image| 2 +-
tests/ref/fate/mxf-d10-user-comments | 2 +-
tests/ref/fate/segment-mp4-to-ts | 250 +-
tests/ref/fate/webm-webvtt-remux | 24 +-
12 files changed, 164 insertions(+), 156 deletions(-)
diff --git a/libavformat/framecrcenc.c b/libavformat/framecrcenc.c
index 68ca9d8a9e..c300702d55 100644
--- a/libavformat/framecrcenc.c
+++ b/libavformat/framecrcenc.c
@@ -51,6 +51,14 @@ static int framecrc_write_packet(struct AVFormatContext *s,
AVPacket *pkt)
pkt->stream_index, pkt->dts, pkt->pts, pkt->duration, pkt->size,
crc);
if (pkt->flags != AV_PKT_FLAG_KEY)
av_strlcatf(buf, sizeof(buf), ", F=0x%0X", pkt->flags);
+if (pkt->side_data_elems) {
+av_strlcatf(buf, sizeof(buf), ", S=%d", pkt->side_data_elems);
+
+for (int i = 0; i < pkt->side_data_elems; i++) {
+av_strlcatf(buf, sizeof(buf), ", %8"SIZE_SPECIFIER,
+pkt->side_data[i].size);
+}
+}
av_strlcatf(buf, sizeof(buf), "\n");
avio_write(s->pb, buf, strlen(buf));
return 0;
diff --git a/tests/ref/fate/copy-trac3074 b/tests/ref/fate/copy-trac3074
index eea30be03d..e541af03da 100644
--- a/tests/ref/fate/copy-trac3074
+++ b/tests/ref/fate/copy-trac3074
@@ -6,7 +6,7 @@ da6122873fb83ce4340cf5d0ab8d475e
*tests/data/fate/copy-trac3074.mp4
#sample_rate 0: 48000
#channel_layout 0: 3
#channel_layout_name 0: stereo
-0, 0, 0, 1536, 512, 0x2beaf79f
+0, 0, 0, 1536, 512, 0x2beaf79f, S=1,4
0, 1536, 1536, 1536, 512, 0x29ddf9d6
0, 3072, 3072, 1536, 512, 0xba0afa79
0, 4608, 4608, 1536, 512, 0xe019f394
diff --git a/tests/ref/fate/cover-art-mp3-id3v2-remux
b/tests/ref/fate/cover-art-mp3-id3v2-remux
index d7aae5544d..457f1d5a08 100644
--- a/tests/ref/fate/cover-art-mp3-id3v2-remux
+++ b/tests/ref/fate/cover-art-mp3-id3v2-remux
@@ -21,7 +21,7 @@ c1b55a9a92226cd72d3f53ccd830d127
*tests/data/fate/cover-art-mp3-id3v2-remux.mp3
#codec_id 3: png
#dimensions 3: 263x263
#sar 3: 1/1
-0,-353590,-353590, 368640, 417, 0x15848290
+0,-353590,-353590, 368640, 417, 0x15848290, S=1, 10
1, 0, 0,0,15760, 0x71d5c418
2, 0, 0,0, 208350, 0x291b44d1
3, 0, 0,0, 165671, 0x7c1c8070
diff --git a/tests/ref/fate/gapless-mp3 b/tests/ref/fate/gapless-mp3
index 66a765ce7b..0b4937792a 100644
--- a/tests/ref/fate/gapless-mp3
+++ b/tests/ref/fate/gapless-mp3
@@ -1,5 +1,5 @@
-7b72a1f069386ca934a9537e7fcd63aa *tests/data/fate/gapless-mp3.out-1
+77ef234e382c15b8afc416ca9c80024b *tests/data/fate/gapless-mp3.out-1
c96c3ae7bd3300fd2f4debac222de5b7
-31eddf7f5dbee1a4f35f2110e35007cc *tests/data/fate/gapless-mp3.out-2
+c594be833fb94ae91f2734bcba56c359 *tests/data/fate/gapless-mp3.out-2
c96c3ae7bd3300fd2f4debac222de5b7
-3836e06e588f6222597dae4b11d2fcf8 *tests/data/fate/gapless-mp3.out-3
+5a285806cad6524a3d6184775e097d24 *tests/data/fate/gapless-mp3.out-3
diff --git a/tests/ref/fate/id3v2-priv-remux b/tests/ref/fate/id3v2-priv-remux
index aea6ee9a5f..a30f68a256 100644
--- a/tests/ref/fate/id3v2-priv-remux
+++ b/tests/ref/fate/id3v2-priv-remux
@@ -6,7 +6,7 @@ bb2816e3a05ce136e9ac14479c1ebe24
*tests/data/fate/id3v2-priv-remux.mp3
#sample_rate 0: 48000
#channel_layout 0: 4
#channel_layout_name 0: mono
-0,-155528,-155528, 338688, 192, 0x3774510e
+0,-155528,-155528, 338688, 192, 0x3774510e, S=1, 10
0, 183160, 183160, 338688, 192, 0x856c5b02
0, 521848, 521848, 338688, 192, 0xb86e557f
0, 860536, 860536, 338688, 192, 0x3b6c5cb7
diff --git a/tests/ref/fate/matroska-mastering-display-metadata
b/tests/ref/fate/matroska-mastering-display-metadata
index 6eb4a3d515..8f5d7b6a22 100644
--- a/tests/ref/fate/matroska-mastering-display-metadata
+++ b/tests/ref/fate/matroska-mastering-display-metadata
@@ -24,9 +24,9 @@
#codec_id 3: ffv1
#dimensions 3: 1280x720
#sar 3: 1/1
-0, 0, 0, 16,57008, 0x43416399
+0, 0, 0, 16,57008, 0x43416399, S=2,8,
88
1, 0, 0, 16, 2403, 0xaa818522
-3, 0, 0, 16, 274117, 0xc439610f
+3, 0, 0,
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: Ignore the first two data/subtitle streams.
On Thu, 13 May 2021 at 16:38, Josh Allmann wrote: > > Previously, one or the other would have been ignored, but not both. > Since the probe terminates at three streams, it could exit > prematurely if both data and subtitles are present along with > slightly trailing media, usually video trailing audio. > > Trailing media is common in RTMP, and encoders write strange metadata. > --- Here's a trac ticket with some more context: https://trac.ffmpeg.org/ticket/9241 And a sample that exhibits the problem: https://trac.ffmpeg.org/attachment/ticket/9241/flv-probe-missing-streams.flv 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-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Encode user data unregistered SEI (H.264/H.265)
MISB ST 0604 and ST 2101 require user data unregistered SEI messages (precision timestamps and sensor identifiers) to be included. That currently isn't supported. This series adds encoding for libx264, libx265, hevc_nvenc and h264_nvenc. v2 removed the API addition, modifies nvenc to use a dynamic array, and corrects formatting. v3 removes the example, and improves memory allocation handling. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/3] libavcodec: write out user data unregistered SEI for x264
Signed-off-by: Brad Hards
---
libavcodec/libx264.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 1c27f7b441..feee8f8ee6 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -31,6 +31,7 @@
#include "internal.h"
#include "packet_internal.h"
#include "atsc_a53.h"
+#include "sei.h"
#if defined(_MSC_VER)
#define X264_API_IMPORTS 1
@@ -303,6 +304,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
int64_t wallclock = 0;
X264Opaque *out_opaque;
AVFrameSideData *sd;
+int total_unreg_sei = 0;
x264_picture_init( &x4->pic );
x4->pic.img.i_csp = x4->params.i_csp;
@@ -316,6 +318,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
x4->pic.img.i_plane = avfmt2_num_planes(ctx->pix_fmt);
if (frame) {
+void *sei_data_a53_cc;
for (i = 0; i < x4->pic.img.i_plane; i++) {
x4->pic.img.plane[i]= frame->data[i];
x4->pic.img.i_stride[i] = frame->linesize[i];
@@ -349,28 +352,50 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
reconfig_encoder(ctx, frame);
if (x4->a53_cc) {
-void *sei_data;
size_t sei_size;
-ret = ff_alloc_a53_sei(frame, 0, &sei_data, &sei_size);
+ret = ff_alloc_a53_sei(frame, 0, &sei_data_a53_cc, &sei_size);
if (ret < 0) {
av_log(ctx, AV_LOG_ERROR, "Not enough memory for closed
captions, skipping\n");
-} else if (sei_data) {
+} else if (sei_data_a53_cc) {
x4->pic.extra_sei.payloads =
av_mallocz(sizeof(x4->pic.extra_sei.payloads[0]));
if (x4->pic.extra_sei.payloads == NULL) {
av_log(ctx, AV_LOG_ERROR, "Not enough memory for closed
captions, skipping\n");
-av_free(sei_data);
+av_free(sei_data_a53_cc);
} else {
x4->pic.extra_sei.sei_free = av_free;
x4->pic.extra_sei.payloads[0].payload_size = sei_size;
-x4->pic.extra_sei.payloads[0].payload = sei_data;
+x4->pic.extra_sei.payloads[0].payload = sei_data_a53_cc;
x4->pic.extra_sei.num_payloads = 1;
x4->pic.extra_sei.payloads[0].payload_type = 4;
}
}
}
+for (int j = 0; j < frame->nb_side_data; j++)
+if (frame->side_data[j]->type == AV_FRAME_DATA_SEI_UNREGISTERED)
+total_unreg_sei++;
+if (total_unreg_sei > 0) {
+x264_sei_t *sei = &(x4->pic.extra_sei);
+sei->payloads = av_realloc_array(sei->payloads,
+ sei->num_payloads +
total_unreg_sei,
+ sizeof(x264_sei_payload_t));
+if (!sei->payloads) {
+av_log(ctx, AV_LOG_ERROR, "Not enough memory for unregistered
SEI, skipping\n");
+av_free(sei_data_a53_cc);
+sei->num_payloads = 0;
+} else
+for (int j = 0; j < frame->nb_side_data; j++)
+if (frame->side_data[j]->type ==
AV_FRAME_DATA_SEI_UNREGISTERED) {
+x264_sei_payload_t *payload =
&(sei->payloads[sei->num_payloads]);
+payload->payload = frame->side_data[j]->data;
+payload->payload_size = frame->side_data[j]->size;
+payload->payload_type =
SEI_TYPE_USER_DATA_UNREGISTERED;
+sei->num_payloads++;
+}
+}
+
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_REGIONS_OF_INTEREST);
if (sd) {
if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 2/3] libavcodec: write out user data unregistered SEI for x265
Signed-off-by: Brad Hards
---
libavcodec/libx265.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index a1bd205201..e21eb8828d 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -484,6 +484,7 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
int nnal;
int ret;
int i;
+int total_unregistered_sei;
ctx->api->picture_init(ctx->params, &x265pic);
@@ -515,6 +516,27 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
memcpy(x265pic.userData, &pic->reordered_opaque,
sizeof(pic->reordered_opaque));
}
+for (int j = 0; j < pic->nb_side_data; j++)
+if (pic->side_data[j]->type == AV_FRAME_DATA_SEI_UNREGISTERED)
+total_unregistered_sei++;
+if (total_unregistered_sei > 0) {
+x265_sei *sei = &(x265pic.userSEI);
+sei->payloads = av_realloc_array(sei->payloads,
+ sei->numPayloads +
total_unregistered_sei,
+ sizeof(x265_sei_payload));
+if (!sei->payloads) {
+av_log(ctx, AV_LOG_ERROR, "Not enough memory for unregistered
SEI, skipping\n");
+sei->numPayloads = 0;
+} else
+for (int j = 0; j < pic->nb_side_data; j++)
+if (pic->side_data[j]->type ==
AV_FRAME_DATA_SEI_UNREGISTERED) {
+x265_sei_payload *payload =
&(sei->payloads[sei->numPayloads]);
+payload->payload = pic->side_data[j]->data;
+payload->payloadSize = pic->side_data[j]->size;
+payload->payloadType = USER_DATA_UNREGISTERED;
+sei->numPayloads++;
+}
+}
}
ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 3/3] libavcodec: write out user data unregistered SEI for nvenc
Signed-off-by: Brad Hards
---
libavcodec/nvenc.c | 64 ++
1 file changed, 53 insertions(+), 11 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 0dcd93a99c..9bf2728cba 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -2170,9 +2170,10 @@ static int nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
NVENCSTATUS nv_status;
NvencSurface *tmp_out_surf, *in_surf;
int res, res2;
-NV_ENC_SEI_PAYLOAD sei_data[8];
+NV_ENC_SEI_PAYLOAD *sei_data = 0;
int sei_count = 0;
int i;
+int total_unregistered_sei = 0;
NvencContext *ctx = avctx->priv_data;
NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
@@ -2185,6 +2186,8 @@ static int nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
return AVERROR(EINVAL);
if (frame && frame->buf[0]) {
+void *a53_data = NULL;
+void *tc_data = NULL;
in_surf = get_free_frame(ctx);
if (!in_surf)
return AVERROR(EAGAIN);
@@ -2230,7 +2233,6 @@ static int nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
pic_params.inputTimeStamp = frame->pts;
if (ctx->a53_cc && av_frame_get_side_data(frame,
AV_FRAME_DATA_A53_CC)) {
-void *a53_data = NULL;
size_t a53_size = 0;
if (ff_alloc_a53_sei(frame, 0, (void**)&a53_data, &a53_size) < 0) {
@@ -2238,15 +2240,21 @@ static int nvenc_send_frame(AVCodecContext *avctx,
const AVFrame *frame)
}
if (a53_data) {
-sei_data[sei_count].payloadSize = (uint32_t)a53_size;
-sei_data[sei_count].payloadType = 4;
-sei_data[sei_count].payload = (uint8_t*)a53_data;
-sei_count ++;
+sei_data = av_realloc_array(sei_data, sei_count + 1,
sizeof(NV_ENC_SEI_PAYLOAD));
+if (!sei_data) {
+av_log(ctx, AV_LOG_ERROR, "Not enough memory for closed
captions SEI, skipping\n");
+av_free(a53_data);
+sei_count = 0;
+} else {
+sei_data[sei_count].payloadSize = (uint32_t)a53_size;
+sei_data[sei_count].payloadType = 4;
+sei_data[sei_count].payload = (uint8_t*)a53_data;
+sei_count ++;
+}
}
}
if (ctx->s12m_tc && av_frame_get_side_data(frame,
AV_FRAME_DATA_S12M_TIMECODE)) {
-void *tc_data = NULL;
size_t tc_size = 0;
if (ff_alloc_timecode_sei(frame, avctx->framerate, 0,
(void**)&tc_data, &tc_size) < 0) {
@@ -2254,13 +2262,46 @@ static int nvenc_send_frame(AVCodecContext *avctx,
const AVFrame *frame)
}
if (tc_data) {
-sei_data[sei_count].payloadSize = (uint32_t)tc_size;
-sei_data[sei_count].payloadType = SEI_TYPE_TIME_CODE;
-sei_data[sei_count].payload = (uint8_t*)tc_data;
-sei_count ++;
+sei_data = av_realloc_array(sei_data, sei_count + 1,
sizeof(NV_ENC_SEI_PAYLOAD));
+if (!sei_data) {
+av_log(ctx, AV_LOG_ERROR, "Not enough memory for timecode
SEI, skipping\n");
+av_free(a53_data);
+av_free(tc_data);
+sei_count = 0;
+} else {
+sei_data[sei_count].payloadSize = (uint32_t)tc_size;
+sei_data[sei_count].payloadType = SEI_TYPE_TIME_CODE;
+sei_data[sei_count].payload = (uint8_t*)tc_data;
+sei_count ++;
+}
}
}
+for (int j = 0; j < frame->nb_side_data; j++)
+if (frame->side_data[j]->type == AV_FRAME_DATA_SEI_UNREGISTERED)
+total_unregistered_sei++;
+if (total_unregistered_sei > 0) {
+sei_data = av_realloc_array(sei_data,
+sei_count + total_unregistered_sei,
+sizeof(NV_ENC_SEI_PAYLOAD));
+if (!sei_data) {
+av_log(ctx, AV_LOG_ERROR, "Not enough memory for unregistered
SEI, skipping\n");
+av_free(a53_data);
+av_free(tc_data);
+sei_count = 0;
+} else
+for (int j = 0; j < frame->nb_side_data; j++) {
+AVFrameSideData *side_data = frame->side_data[j];
+if (side_data->type == AV_FRAME_DATA_SEI_UNREGISTERED) {
+sei_data[sei_count].payloadSize = side_data->size;
+sei_data[sei_count].payloadType =
SEI_TYPE_USER_DATA_UNREGISTERED;
+sei_data[sei_count].payload =
av_memdup(side_data->data, side_data->size);
+if (sei_data[sei_count].payload)
+
[FFmpeg-devel] [PATCH] avfilter/vf_palettegen: add protection against potential divide by zero
In libavfilter/vf_palettegen.c, the function get_avg_color requires
that box->len greater than zero to avoid dividing by zero. However,
the call sequence filter_frame -> get_palette_frame -> get_avg_color
may not satisfy this precondition. The bug is detailed in the bug
tracker:https://trac.ffmpeg.org/ticket/9222.
Signed-off-by: Yiyuan GUO
---
libavfilter/vf_palettegen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
index ef8bc18..73ec3c7 100644
--- a/libavfilter/vf_palettegen.c
+++ b/libavfilter/vf_palettegen.c
@@ -489,7 +489,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
if (s->stats_mode == STATS_MODE_DIFF_FRAMES) {
av_frame_free(&s->prev_frame);
s->prev_frame = in;
-} else if (s->stats_mode == STATS_MODE_SINGLE_FRAMES) {
+} else if (s->stats_mode == STATS_MODE_SINGLE_FRAMES && s->nb_refs) {
AVFrame *out;
int i;
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
