Re: [FFmpeg-devel] [PATCH] Avoid integer to float point domain crossing penalties
Anyone interested in reviewing this patch ?
Thanks
-Adrian
On Mon, 24 Jun 2019 at 13:57, wrote:
> From: Adrian Tong
>
> On internal benchmark, I see a noisy-level difference (more likely to be
> an improvement) in ff_h264_decode_mb_cabac which calls this function.
> ---
> libavutil/x86/intreadwrite.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/x86/intreadwrite.h b/libavutil/x86/intreadwrite.h
> index 4061d19231..df0bf45ae1 100644
> --- a/libavutil/x86/intreadwrite.h
> +++ b/libavutil/x86/intreadwrite.h
> @@ -68,8 +68,8 @@ static av_always_inline void AV_COPY128(void *d, const
> void *s)
> {
> struct v {uint64_t v[2];};
>
> -__asm__("movaps %1, %%xmm0 \n\t"
> -"movaps %%xmm0, %0 \n\t"
> +__asm__("movdqa %1, %%xmm0 \n\t"
> +"movdqa %%xmm0, %0 \n\t"
> : "=m"(*(struct v*)d)
> : "m" (*(const struct v*)s)
> : "xmm0");
> --
> 2.20.1 (Apple Git-117)
>
>
___
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] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation
The previous calculation code did not account for the fact that the copy_offset for the start of the frame array is at index 0, yet the scan line number from the rfc4175 RTP header starts at 1. This caused 2 issues to appear: - The first scan line was being copied into the array where the second scan line should be. This caused the resulting video to have a green line at the top of it. - Since the packet containing the last scan line would fail the calculation, the packet with the RTP marker would not be processed which caused a log message saying "Missed previous RTP marker" to be outputted for each frame. Signed-off-by: Jacob Siddall --- Changes in v2: - Don't handle packet if the line number is less than 1 Section 12 in the VSF technical recommendation TR-03 specifies that the video scan line numbers should start at 1. http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf Changes in v3: - Changed the commit hash abbreviation in the patch file diff to be 10 characters in length rather than 7. This was causing the patch file to fail when it was applied. libavformat/rtpdec_rfc4175.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c index e9c62c1389..490db87520 100644 --- a/libavformat/rtpdec_rfc4175.c +++ b/libavformat/rtpdec_rfc4175.c @@ -205,8 +205,11 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data, if (length > payload_len) length = payload_len; +if (line < 1) +return AVERROR_INVALIDDATA; + /* prevent ill-formed packets to write after buffer's end */ -copy_offset = (line * data->width + offset) * data->pgroup / data->xinc; +copy_offset = ((line - 1) * data->width + offset) * data->pgroup / data->xinc; if (copy_offset + length > data->frame_size) return AVERROR_INVALIDDATA; -- 2.20.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 v2] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation
> git seems to not like the patch: > > Applying: avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation > Using index info to reconstruct a base tree... > error: patch failed: libavformat/rtpdec_rfc4175.c:205 > error: libavformat/rtpdec_rfc4175.c: patch does not apply > error: Did you hand edit your patch? > It does not apply to blobs recorded in its index. > Patch failed at 0001 avformat/rtpdec_rfc4175: Fix incorrect copy_offset > calculation I think I figured out what is causing my patches to not apply with git. When I initially cloned the ffmpeg git repository, I cloned it with "--depth 1". When the patch file was generated, the commit hash abbreviation is 7 characters long. I cloned a fresh copy of ffmpeg without the depth argument and the patch file that was generated has a hash abbreviation length of 10 characters. index e9c62c1..490db87 100644 vs index e9c62c1389..490db87520 100644 I'll send an updated patch file with this change in it and hopefully it works. ___ 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] hlsenc: Add option to set custom HTTP headers
Derek Buitenhuis 于2019年6月27日周四 上午1:04写道：
>
> Signed-off-by: Derek Buitenhuis
> ---
> Onward and upward with the never-ending quest to manually forward
> all the HTTP options to the subcontexts in every meta-muxer!
> ---
> doc/muxers.texi | 3 +++
> libavformat/hlsenc.c | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 6c5b4bb637..59c93bc687 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1089,6 +1089,9 @@ Set timeout for socket I/O operations. Applicable only
> for HTTP output.
> @item -ignore_io_errors
> Ignore IO errors during open, write and delete. Useful for long-duration
> runs with network output.
>
> +@item headers
> +Set custom HTTP headers, can override built in default headers. Applicable
> only for HTTP output.
> +
> @end table
>
> @anchor{ico}
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 9f5eee5491..37ae128f4f 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -237,6 +237,7 @@ typedef struct HLSContext {
> AVIOContext *sub_m3u8_out;
> int64_t timeout;
> int ignore_io_errors;
> +char *headers;
> int has_default_key; /* has DEFAULT field of var_stream_map */
> int has_video_m3u8; /* has video stream m3u8 list */
> } HLSContext;
> @@ -294,6 +295,8 @@ static void set_http_options(AVFormatContext *s,
> AVDictionary **options, HLSCont
> av_dict_set_int(options, "multiple_requests", 1, 0);
> if (c->timeout >= 0)
> av_dict_set_int(options, "timeout", c->timeout, 0);
> +if (c->headers)
> +av_dict_set(options, "headers", c->headers, 0);
> }
>
> static void write_codec_attr(AVStream *st, VariantStream *vs) {
> @@ -3029,6 +3032,7 @@ static const AVOption options[] = {
> {"http_persistent", "Use persistent HTTP connections",
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> {"timeout", "set timeout for socket I/O operations", OFFSET(timeout),
> AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
> {"ignore_io_errors", "Ignore IO errors for stable long-duration runs
> with network output", OFFSET(ignore_io_errors), AV_OPT_TYPE_BOOL, { .i64 = 0
> }, 0, 1, E },
> +{"headers", "set custom HTTP headers, can override built in default
> headers", OFFSET(headers), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
> { NULL },
> };
>
> --
> 2.20.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
Thanks
Steven
___
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, RFC, v2] lavc/phtread_frame: update context in child thread in multi-thread mode
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Thursday, June 27, 2019 00:29 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, RFC, v2] lavc/phtread_frame: update > context in child thread in multi-thread mode > > On Wed, Jun 26, 2019 at 04:24:52PM -0400, Linjie Fu wrote: > > Currently in ff_thread_decode_frame, context is updated from child > thread > > to main thread, and main thread releases the context in avcodec_close() > > when decode finishes. > > > > However, when resolution/format change in vp9, ff_get_format was called, > > and hwaccel_uninit() and hwaccel_init will be used to destroy and re- > create > > the context. Due to the async between main-thread and child-thread, > > main-thread updated its context from child earlier than the context was > > refreshed in child-thread. And it will lead to: > > 1. memory leak in child-thread. > > 2. double free in main-thread while calling avcodec_close(). > > > > Can be reproduced with a resolution change case in vp9, and use -vframes > > to terminate the decode between the dynamic resolution change frames: > > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v > > verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync > > passthrough -vframes 6 -y out.yuv > > > > Move update_context_from_thread from ff_thread_decode_frame(main > thread) > > to frame_worker_thread(child thread), update the context in child thread > > right after the context was updated to avoid the async issue. > > > > Signed-off-by: Linjie Fu > > --- > > Request for Comments, not quite familiar with the constraints. > > Thanks in advance. > > i dont think i fully understand the problem you are trying to fix but > this patch looks like it writes into the users context without any > lock while the user can access it. > Thats looks like a race condition unless I am missing something Yes that's what I'm concerned and seeking for advice. One possible way I thought is to add a new lock, and lock in both frame_worker_thread and submit_packet(user) wwhen it attmepts to update context from user to child thread. > What is very noticable though is that you seem to talk about vp9 > why is this vp9 specific and does not affect other codecs ? Actually it's not codec specific. It happens as long as context refreshed because of resolution/format change in child thread but failed to update in main thread correctly. Same issue exists in h264 as well if decode terminate during resolution changing (-vframes 45 in this example): ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose -i ./reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12 -f rawvideo -vsync passthrough -vframes 45 -y md5.yuv http://fate-suite.ffmpeg.org/h264/reinit-large_420_8-to-small_420_8.h264 And this patch fixed it as well. It seems I should not restrict this issue to vp9 in commit message. - Linjie ___ 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] lavf/vf_find_rect: add the dual input support function
From: Limin Wang
Please using the below command for the testing:
./ffmpeg -i input.ts -i ref.png -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover output.ts
I have updated the help document for the function change.
Signed-off-by: Limin Wang
---
doc/filters.texi | 12 +--
libavfilter/vf_find_rect.c | 172 +++--
2 files changed, 116 insertions(+), 68 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 2d9af46a6b..ceb66aba3d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10156,12 +10156,14 @@ Set color for pixels in fixed mode. Default is
@var{black}.
Find a rectangular object
+This filter takes in two video input, the first input is considered
+the "main" source and is passed unchanged to the output. The "second"
+input is used as a rectangular object for finding, now the "second"
+input will be auto converted to gray8 format.
+
It accepts the following options:
@table @option
-@item object
-Filepath of the object image, needs to be in gray8.
-
@item threshold
Detection threshold, default is 0.5.
@@ -10178,7 +10180,7 @@ Specifies the rectangle in which to search.
@item
Cover a rectangular object by the supplied image of a given video using
@command{ffmpeg}:
@example
-ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover
new.mkv
+ffmpeg -i file.ts -newref.pgm -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover new.mkv
@end example
@end itemize
@@ -10212,7 +10214,7 @@ Default value is @var{blur}.
@item
Cover a rectangular object by the supplied image of a given video using
@command{ffmpeg}:
@example
-ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover
new.mkv
+ffmpeg -i file.ts -newref.pgm -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover new.mkv
@end example
@end itemize
diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
index d7e6579af7..055d2d5f4a 100644
--- a/libavfilter/vf_find_rect.c
+++ b/libavfilter/vf_find_rect.c
@@ -18,13 +18,10 @@
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
-/**
- * @todo switch to dualinput
- */
-
#include "libavutil/avassert.h"
#include "libavutil/imgutils.h"
#include "libavutil/opt.h"
+#include "framesync.h"
#include "internal.h"
#include "lavfutils.h"
@@ -36,9 +33,9 @@ typedef struct FOCContext {
float threshold;
int mipmaps;
int xmin, ymin, xmax, ymax;
-char *obj_filename;
int last_x, last_y;
-AVFrame *obj_frame;
+FFFrameSync fs;
+
AVFrame *needle_frame[MAX_MIPMAPS];
AVFrame *haystack_frame[MAX_MIPMAPS];
} FOCContext;
@@ -46,7 +43,6 @@ typedef struct FOCContext {
#define OFFSET(x) offsetof(FOCContext, x)
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
static const AVOption find_rect_options[] = {
-{ "object", "object bitmap filename", OFFSET(obj_filename),
AV_OPT_TYPE_STRING, {.str = NULL}, .flags = FLAGS },
{ "threshold", "set threshold", OFFSET(threshold), AV_OPT_TYPE_FLOAT,
{.dbl = 0.5}, 0, 1.0, FLAGS },
{ "mipmaps", "set mipmaps", OFFSET(mipmaps), AV_OPT_TYPE_INT, {.i64 = 3},
1, MAX_MIPMAPS, FLAGS },
{ "xmin", "", OFFSET(xmin), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS
},
@@ -56,17 +52,32 @@ static const AVOption find_rect_options[] = {
{ NULL }
};
-AVFILTER_DEFINE_CLASS(find_rect);
+FRAMESYNC_DEFINE_CLASS(find_rect, FOCContext, fs);
static int query_formats(AVFilterContext *ctx)
{
-static const enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_YUVJ420P,
-AV_PIX_FMT_NONE
-};
+static const enum AVPixelFormat in_fmts[]= {AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE};
+static const enum AVPixelFormat obj_fmts[] = {AV_PIX_FMT_GRAY8,
AV_PIX_FMT_NONE};
+static const enum AVPixelFormat out_fmts[] = {AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE};
+int ret;
+AVFilterFormats *in= ff_make_format_list(in_fmts);
+AVFilterFormats *obj = ff_make_format_list(obj_fmts);
+AVFilterFormats *out = ff_make_format_list(out_fmts);
+
+if (!in || !obj || !out) {
+av_freep(&in);
+av_freep(&obj);
+av_freep(&out);
+return AVERROR(ENOMEM);
+}
+
+if ((ret = ff_formats_ref(in , &ctx->inputs[0]->out_formats)) < 0 ||
+(ret = ff_formats_ref(obj , &ctx->inputs[1]->out_formats)) < 0 ||
+(ret = ff_formats_ref(out , &ctx->outputs[0]->in_formats)) < 0)
+return ret;
+
+return 0;
-return ff_set_common_formats(ctx, ff_make_format_list(pix_fmts));
}
static AVFrame *downscale(AVFrame *in)
@@ -140,19 +151,54 @@ static float compare(const AVFrame *haystack, const
AVFrame *obj, int offx, int
return 1 - fabs(c);
}
-static int config_input(AVFilterLink *inlink)
+static int config_main_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+
+av_log(ctx, AV_LOG_D
Re: [FFmpeg-devel] [PATCH v2 5/9] lavc/qsvdec: Add VP9 decoder support
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of James Almer > Sent: Wednesday, June 26, 2019 10:19 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v2 5/9] lavc/qsvdec: Add VP9 decoder > support > > On 6/26/2019 3:00 AM, Li, Zhong wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > >> Of Li, Zhong > >> Sent: Tuesday, April 16, 2019 10:32 AM > >> To: FFmpeg development discussions and patches > >> > >> Subject: Re: [FFmpeg-devel] [PATCH v2 5/9] lavc/qsvdec: Add VP9 > >> decoder support > >> > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > >> Behalf > >>> Of Mark Thompson > >>> Sent: Tuesday, April 2, 2019 7:40 AM > >>> To: ffmpeg-devel@ffmpeg.org > >>> Subject: [FFmpeg-devel] [PATCH v2 5/9] lavc/qsvdec: Add VP9 decoder > >>> support > >>> > >>> From: Zhong Li > >>> > >>> VP9 decoder is supported on Intel kabyLake+ platforms with MSDK > >>> Version 1.19+ > >>> > >>> Signed-off-by: Zhong Li > >>> --- > >>> On 20/03/2019 14:41, Li, Zhong wrote: > Yes, QSV is a marketing name which is no equal to libmfx/MSDK. > But would be better to keep consistent with others, such as "Intel > >>> QSV-accelerated VP8 video decoding" in pervious changelog? > >>> > >>> I don't think so? VP9 decoding with the QSV hardware is already > >>> supported, this only adds the additional option of using libmfx to > >>> access the same thing as well. > >> > >> Ok, here are just some words description of changelog. I will be > >> happy to see this patch can be applied. > >> (As previous comment, the updated version of vp9 parser with pic_type > >> of key frame issue fixing LGTM.) > > > > Ping? > > > > If nobody against, I will merge it with cbs vp9 parser patch during one > week. > > Please, don't push a patchset written by Mark without his approval. I > reviewed a few other patches from this set and he will most likely submit a > new version for all of them. Thanks for your remind, James. Yes I saw your comment for av1, I thought the others should be ok but pending for a while. Anyway, will hold on and waiting for Mark's response. ___ 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] lavf/vf_find_rect: add the dual input support function
From: Limin Wang
Please using the below command for the testing:
./ffmpeg -i input.ts -i ref.png -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover output.ts
I have updated the help document for the function change.
Signed-off-by: Limin Wang
---
doc/filters.texi | 12 +--
libavfilter/vf_find_rect.c | 173 +++--
2 files changed, 117 insertions(+), 68 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 2d9af46a6b..ceb66aba3d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10156,12 +10156,14 @@ Set color for pixels in fixed mode. Default is
@var{black}.
Find a rectangular object
+This filter takes in two video input, the first input is considered
+the "main" source and is passed unchanged to the output. The "second"
+input is used as a rectangular object for finding, now the "second"
+input will be auto converted to gray8 format.
+
It accepts the following options:
@table @option
-@item object
-Filepath of the object image, needs to be in gray8.
-
@item threshold
Detection threshold, default is 0.5.
@@ -10178,7 +10180,7 @@ Specifies the rectangle in which to search.
@item
Cover a rectangular object by the supplied image of a given video using
@command{ffmpeg}:
@example
-ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover
new.mkv
+ffmpeg -i file.ts -newref.pgm -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover new.mkv
@end example
@end itemize
@@ -10212,7 +10214,7 @@ Default value is @var{blur}.
@item
Cover a rectangular object by the supplied image of a given video using
@command{ffmpeg}:
@example
-ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover
new.mkv
+ffmpeg -i file.ts -newref.pgm -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover new.mkv
@end example
@end itemize
diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
index d7e6579af7..dbfabbd7c6 100644
--- a/libavfilter/vf_find_rect.c
+++ b/libavfilter/vf_find_rect.c
@@ -18,13 +18,10 @@
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
-/**
- * @todo switch to dualinput
- */
-
#include "libavutil/avassert.h"
#include "libavutil/imgutils.h"
#include "libavutil/opt.h"
+#include "framesync.h"
#include "internal.h"
#include "lavfutils.h"
@@ -36,9 +33,9 @@ typedef struct FOCContext {
float threshold;
int mipmaps;
int xmin, ymin, xmax, ymax;
-char *obj_filename;
int last_x, last_y;
-AVFrame *obj_frame;
+FFFrameSync fs;
+
AVFrame *needle_frame[MAX_MIPMAPS];
AVFrame *haystack_frame[MAX_MIPMAPS];
} FOCContext;
@@ -46,7 +43,6 @@ typedef struct FOCContext {
#define OFFSET(x) offsetof(FOCContext, x)
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
static const AVOption find_rect_options[] = {
-{ "object", "object bitmap filename", OFFSET(obj_filename),
AV_OPT_TYPE_STRING, {.str = NULL}, .flags = FLAGS },
{ "threshold", "set threshold", OFFSET(threshold), AV_OPT_TYPE_FLOAT,
{.dbl = 0.5}, 0, 1.0, FLAGS },
{ "mipmaps", "set mipmaps", OFFSET(mipmaps), AV_OPT_TYPE_INT, {.i64 = 3},
1, MAX_MIPMAPS, FLAGS },
{ "xmin", "", OFFSET(xmin), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS
},
@@ -56,17 +52,32 @@ static const AVOption find_rect_options[] = {
{ NULL }
};
-AVFILTER_DEFINE_CLASS(find_rect);
+FRAMESYNC_DEFINE_CLASS(find_rect, FOCContext, fs);
static int query_formats(AVFilterContext *ctx)
{
-static const enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_YUVJ420P,
-AV_PIX_FMT_NONE
-};
+static const enum AVPixelFormat in_fmts[]= {AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE};
+static const enum AVPixelFormat obj_fmts[] = {AV_PIX_FMT_GRAY8,
AV_PIX_FMT_NONE};
+static const enum AVPixelFormat out_fmts[] = {AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE};
+int ret;
+AVFilterFormats *in= ff_make_format_list(in_fmts);
+AVFilterFormats *obj = ff_make_format_list(obj_fmts);
+AVFilterFormats *out = ff_make_format_list(out_fmts);
+
+if (!in || !obj || !out) {
+av_freep(&in);
+av_freep(&obj);
+av_freep(&out);
+return AVERROR(ENOMEM);
+}
+
+if ((ret = ff_formats_ref(in , &ctx->inputs[0]->out_formats)) < 0 ||
+(ret = ff_formats_ref(obj , &ctx->inputs[1]->out_formats)) < 0 ||
+(ret = ff_formats_ref(out , &ctx->outputs[0]->in_formats)) < 0)
+return ret;
+
+return 0;
-return ff_set_common_formats(ctx, ff_make_format_list(pix_fmts));
}
static AVFrame *downscale(AVFrame *in)
@@ -140,19 +151,55 @@ static float compare(const AVFrame *haystack, const
AVFrame *obj, int offx, int
return 1 - fabs(c);
}
-static int config_input(AVFilterLink *inlink)
+static int config_main_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+
+av_log(ctx, AV_LOG_DEBU
[FFmpeg-devel] [PATCH 3/4] avcodec/dxv: Check op_offset in both directions
Fixes: signed integer overflow: 61 + 2147483647 cannot be represented in type 'int' Fixes: 15311/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5742552826773504 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/dxv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c index 5fd1844094..3506775560 100644 --- a/libavcodec/dxv.c +++ b/libavcodec/dxv.c @@ -745,7 +745,7 @@ static int dxv_decompress_cocg(DXVContext *ctx, GetByteContext *gb, int skip0, skip1, oi0 = 0, oi1 = 0; int ret, state0 = 0, state1 = 0; -if (op_offset < 12) +if (op_offset < 12 || op_offset - 12 > bytestream2_get_bytes_left(gb)) return AVERROR_INVALIDDATA; dst = tex_data; -- 2.22.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 4/4] avcodec/h264_cavlc: Fix integer overflows with motion vector residual addition
Fixes: signed integer overflow: 14 + 2147483647 cannot be represented in type
'int'
Fixes:
14794/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5677380695228416
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_cavlc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index d82144e3c3..6481992e58 100644
--- a/libavcodec/h264_cavlc.c
+++ b/libavcodec/h264_cavlc.c
@@ -923,8 +923,8 @@ decode_intra_mb:
const int index= 4*i + block_width*j;
int16_t (* mv_cache)[2]= &sl->mv_cache[list][
scan8[index] ];
pred_motion(h, sl, index, block_width, list,
sl->ref_cache[list][ scan8[index] ], &mx, &my);
-mx += get_se_golomb(&sl->gb);
-my += get_se_golomb(&sl->gb);
+mx += (unsigned)get_se_golomb(&sl->gb);
+my += (unsigned)get_se_golomb(&sl->gb);
ff_tlog(h->avctx, "final mv:%d %d\n", mx, my);
if(IS_SUB_8X8(sub_mb_type)){
@@ -977,8 +977,8 @@ decode_intra_mb:
for (list = 0; list < sl->list_count; list++) {
if(IS_DIR(mb_type, 0, list)){
pred_motion(h, sl, 0, 4, list, sl->ref_cache[list][
scan8[0] ], &mx, &my);
-mx += get_se_golomb(&sl->gb);
-my += get_se_golomb(&sl->gb);
+mx += (unsigned)get_se_golomb(&sl->gb);
+my += (unsigned)get_se_golomb(&sl->gb);
ff_tlog(h->avctx, "final mv:%d %d\n", mx, my);
fill_rectangle(sl->mv_cache[list][ scan8[0] ], 4, 4, 8,
pack16to32(mx,my), 4);
@@ -1012,8 +1012,8 @@ decode_intra_mb:
unsigned int val;
if(IS_DIR(mb_type, i, list)){
pred_16x8_motion(h, sl, 8*i, list,
sl->ref_cache[list][scan8[0] + 16*i], &mx, &my);
-mx += get_se_golomb(&sl->gb);
-my += get_se_golomb(&sl->gb);
+mx += (unsigned)get_se_golomb(&sl->gb);
+my += (unsigned)get_se_golomb(&sl->gb);
ff_tlog(h->avctx, "final mv:%d %d\n", mx, my);
val= pack16to32(mx,my);
@@ -1050,8 +1050,8 @@ decode_intra_mb:
unsigned int val;
if(IS_DIR(mb_type, i, list)){
pred_8x16_motion(h, sl, i*4, list,
sl->ref_cache[list][ scan8[0] + 2*i ], &mx, &my);
-mx += get_se_golomb(&sl->gb);
-my += get_se_golomb(&sl->gb);
+mx += (unsigned)get_se_golomb(&sl->gb);
+my += (unsigned)get_se_golomb(&sl->gb);
ff_tlog(h->avctx, "final mv:%d %d\n", mx, my);
val= pack16to32(mx,my);
--
2.22.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 2/4] avcodec/4xm: Fix signed integer overflows in idct()
Fixes: signed integer overflow: 20242 * 121095 cannot be represented in type
'int'
Fixes:
15310/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5737051745419264
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/4xm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/4xm.c b/libavcodec/4xm.c
index 89120aa8fb..8382159bde 100644
--- a/libavcodec/4xm.c
+++ b/libavcodec/4xm.c
@@ -158,7 +158,7 @@ typedef struct FourXContext {
#define FIX_1_847759065 121095
#define FIX_2_613125930 171254
-#define MULTIPLY(var, const) (((var) * (const)) >> 16)
+#define MULTIPLY(var, const) ((int)((var) * (unsigned)(const)) >> 16)
static void idct(int16_t block[64])
{
--
2.22.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/4] avformat/vividas: Check for input length in get_v()
Fixes: out of array read
Fixes:
15286/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5658245101780992
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/vividas.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index 753328245d..350c7aa70a 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -178,12 +178,13 @@ static void decode_block(uint8_t *src, uint8_t *dest,
unsigned size,
}
}
-static uint32_t get_v(uint8_t *p)
+static uint32_t get_v(uint8_t *p, int len)
{
uint32_t v = 0;
+const uint8_t *end = p + len;
do {
-if (v >= UINT_MAX / 128 - *p)
+if (p >= end || v >= UINT_MAX / 128 - *p)
return v;
v <<= 7;
v += *p & 0x7f;
@@ -204,7 +205,7 @@ static uint8_t *read_vblock(AVIOContext *src, uint32_t
*size,
decode_block(tmp, tmp, 4, key, k2, align);
-n = get_v(tmp);
+n = get_v(tmp, 4);
if (n < 4)
return NULL;
@@ -241,13 +242,13 @@ static uint8_t *read_sb_block(AVIOContext *src, unsigned
*size,
k2 = *key;
decode_block(ibuf, sbuf, 8, *key, &k2, 0);
-n = get_v(sbuf+2);
+n = get_v(sbuf+2, 6);
if (sbuf[0] != 'S' || sbuf[1] != 'B' || (expected_size>0 && n !=
expected_size)) {
uint32_t tmpkey = recover_key(ibuf, expected_size);
k2 = tmpkey;
decode_block(ibuf, sbuf, 8, tmpkey, &k2, 0);
-n = get_v(sbuf+2);
+n = get_v(sbuf+2, 6);
if (sbuf[0] != 'S' || sbuf[1] != 'B' || expected_size != n)
return NULL;
*key = tmpkey;
--
2.22.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 2/2] avcodec/vc1_block: Fix invalid shifts in vc1_decode_i_blocks()
On Sat, Jun 22, 2019 at 04:55:47PM +0200, Paul B Mahol wrote:
> On 6/22/19, Michael Niedermayer wrote:
> > Fixes: left shift of negative value -9
> > Fixes:
> > 15299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSS2_fuzzer-5660922678345728
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/vc1_block.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
> > index 7e41791832..6137252580 100644
> > --- a/libavcodec/vc1_block.c
> > +++ b/libavcodec/vc1_block.c
> > @@ -2600,13 +2600,13 @@ static void vc1_decode_i_blocks(VC1Context *v)
> > if (v->rangeredfrm)
> > for (k = 0; k < 6; k++)
> > for (j = 0; j < 64; j++)
> > -v->block[v->cur_blk_idx][block_map[k]][j] <<=
> > 1;
> > +v->block[v->cur_blk_idx][block_map[k]][j] *= 2;
> > vc1_put_blocks_clamped(v, 1);
> > } else {
> > if (v->rangeredfrm)
> > for (k = 0; k < 6; k++)
> > for (j = 0; j < 64; j++)
> > -v->block[v->cur_blk_idx][block_map[k]][j] =
> > (v->block[v->cur_blk_idx][block_map[k]][j] - 64) << 1;
> > +v->block[v->cur_blk_idx][block_map[k]][j] =
> > (v->block[v->cur_blk_idx][block_map[k]][j] - 64) * 2;
> > vc1_put_blocks_clamped(v, 0);
> > }
> >
> > --
> > 2.22.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".
>
>
> This is much slower.
please provide your testcase and benchmarks or disassmbly
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
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] avcodec/utils: Check bits_per_coded_sample
On Wed, Jun 19, 2019 at 08:42:55PM +0200, Michael Niedermayer wrote: > This avoids the need for each decoder separately having to handle this case > > Fixes: shift exponent -100663046 is negative > Fixes: out of array access > Fixes: > 15270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5727829913763840 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/utils.c | 4 > 1 file changed, 4 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." 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] avcodec/videodsp_template: Fix overflow of addition
On Fri, Jun 21, 2019 at 09:07:38AM +0200, Reimar Döffinger wrote:
>
>
> On 18.06.2019, at 16:25, Michael Niedermayer wrote:
>
> > Fixes: addition of unsigned offset to 0x7f56fc26a9b6 overflowed to
> > 0x7f56fc26a8be*
> > Fixes:
> > clusterfuzz-testcase-minimized-mediasource_MP4_AVC1_pipeline_integration_fuzzer-4917949056679936
> >
> > Reported-by: Matt Wolenetz
> > Reviewed-by: Matt Wolenetz
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/videodsp_template.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/videodsp_template.c b/libavcodec/videodsp_template.c
> > index 94c1b7188d..eae2f1d51b 100644
> > --- a/libavcodec/videodsp_template.c
> > +++ b/libavcodec/videodsp_template.c
> > @@ -44,7 +44,7 @@ void FUNC(ff_emulated_edge_mc)(uint8_t *buf, const
> > uint8_t *src,
> > src_y = 1 - block_h;
> > }
> > if (src_x >= w) {
> > -src += (w - 1 - src_x) * sizeof(pixel);
> > +src -= (1 + src_x - w) * sizeof(pixel);
>
> This is really non-obvious and someone might be tempted to "simplify",
> especially since the old way matched the code a few lines below.
> I'd suggest adding a comment.
will apply with a comment
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
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 4/7] avcodec/alsdec: Fix invalid shift in multiply()
On Fri, Jun 21, 2019 at 12:47:18AM +0200, Michael Niedermayer wrote: > Fixes: shift exponent -24 is negative > Fixes: > 15292/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5768533318828032 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/alsdec.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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 7/7] avcodec/4xm: Fix vlc memleak
On Fri, Jun 21, 2019 at 12:47:21AM +0200, Michael Niedermayer wrote: > Fixes: memleak > Fixes: > 15297/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5746203548975104 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/4xm.c | 1 + > 1 file changed, 1 insertion(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. 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 1/6] avcodec/rv10: Avoid calculating undefined value that is unused
On Sun, Jun 16, 2019 at 07:48:45PM +0200, Michael Niedermayer wrote: > Fixes: shift exponent 64 is too large for 32-bit type 'int' > Fixes: > 15253/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV10_fuzzer-5671114300194816 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/rv10.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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] avcodec: add delayer bitstream filter
On 26.06.2019, at 13:15, Andreas Håkon wrote: > Hi Moritz, > >>> Wouldn't this be better if extended to be a BSF version of setpts? In >>> addition to delays, rescaling as well as other ops could be carried out >>> on TS. >> >> I second that notion, or at least the suggestion of a setpts bsf. >> >> IMO, there is probably some functionality in filters which could be >> implemented in bitstream filters, to allow it to apply to stream copy. > > I think it's a good idea. > > Just to say that from my point of view, it would be easier if another > developer took care of including the functionality of other filters, > because my knowledge of the project is not so deep. > Still, I feel that it would be best to incorporate this BSF as it is > and later on add more features. Minor note: I'd suggest a different name, "delayer" is too easily read as e.g. "de-layer". Could be something like add_delay for example. ___ 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 DICOM Support
On 6/26/19 4:37 PM, Michael Niedermayer wrote: On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote: On 6/26/19, Michael Niedermayer wrote: On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: On 6/25/19 2:12 AM, Michael Niedermayer wrote: On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: Hi! The code is to add DICOM Support. The patch is only for uncompressed dicom files using explicit value representation. I would extend it, once i clarify some doubts. As dicom image files contain lots of metadata about the patient. So, should i display that data while demuxing or should i ignore and only demux the image data ?. In the current patch, i have made an option "-metadata", which when used will print the data on the terminal while demuxing. metadata should be exported to be usable by applications. For teh API design a one test is that it should be possible to have a dicom file as input and a format with similar features as output and not loose any significant data. Printing to the terminal cannot achieve that easily. So, should i export it to a csv file ? does it fit into the metadata system we have ? To clarify, you mean frame metadata system? data that is specific to a frame would belong in the frame metadata data that is specific to a stream would belong into that streams metadata data that is specific to the container would belong to its metadata iam not sure if multiple streams or frames can be in a single dicom "container" / file. If they can then it should be clear what goes where if not then all 3 options would from the point of view of dicom be the same. And in that case what is most convenient for interoperation with other formats should be picked. That is lets introduce the least amount of differences to how similar data is handled in other formats Dicom files contain multiple frames, but number of streams is always one (video) like GIF,( I haven't done multiframe support yet i am working on it ), The data specific to image/frames/pixels can be fit in the three categories of our metadata system, but their is extradata in DICOM files like : patient_name, medical_device_name , medical_procedure_done, study_date i have downloaded many samples from internet, the average number of these extra tags in a file is ~80 so, should i skip this data while demuxing or to extract it from the file format and do something with it. also a complete list of DICOM tags is here: https://www.dicomlibrary.com/dicom/dicom-tags/ https://dicom.innolitics.com/ciods/ Thank You Shivam Goyal [...] ___ 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] libavformat/mux: Fix audio_preload
On Mon, Jun 24, 2019 at 11:16:18PM +0200, Andreas Rheinhardt wrote: > Commit 31f9032b added the audio_preload feature; its goal is to > interleave audio earlier than the rest. Unfortunately, it has never ever > worked, because the check for whether a packet should be interleaved > before or after another packet was completely wrong: When audio_preload > vanishes, interleave_compare_dts returns 1 if the new packet should be > interleaved earlier than the packet it is compared with and that is what > the rest of the code expects. But the codepath used when audio_preload is > set does the opposite. > > Also fixes potential undefined behaviour (namely signed integer > overflow). > > Signed-off-by: Andreas Rheinhardt > --- > avformat.h contains the following note about audio_preload: "not all > formats support this and unpredictable things may happen if it is used > when not supported." Has this been added because of unpredictable > results caused by the buggy check? This option seems to work fine as > long as audio_preload is not in the range of max_interleave_duration. audio preload will violate the spec of some containers which dont allow any preload. Thats what the note was for IIRC > > libavformat/mux.c | 22 ++ > libavformat/version.h | 2 +- > 2 files changed, 15 insertions(+), 9 deletions(-) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange 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".
[FFmpeg-devel] [PATCH] hlsenc: Add option to set custom HTTP headers
Signed-off-by: Derek Buitenhuis
---
Onward and upward with the never-ending quest to manually forward
all the HTTP options to the subcontexts in every meta-muxer!
---
doc/muxers.texi | 3 +++
libavformat/hlsenc.c | 4
2 files changed, 7 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6c5b4bb637..59c93bc687 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1089,6 +1089,9 @@ Set timeout for socket I/O operations. Applicable only
for HTTP output.
@item -ignore_io_errors
Ignore IO errors during open, write and delete. Useful for long-duration runs
with network output.
+@item headers
+Set custom HTTP headers, can override built in default headers. Applicable
only for HTTP output.
+
@end table
@anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 9f5eee5491..37ae128f4f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -237,6 +237,7 @@ typedef struct HLSContext {
AVIOContext *sub_m3u8_out;
int64_t timeout;
int ignore_io_errors;
+char *headers;
int has_default_key; /* has DEFAULT field of var_stream_map */
int has_video_m3u8; /* has video stream m3u8 list */
} HLSContext;
@@ -294,6 +295,8 @@ static void set_http_options(AVFormatContext *s,
AVDictionary **options, HLSCont
av_dict_set_int(options, "multiple_requests", 1, 0);
if (c->timeout >= 0)
av_dict_set_int(options, "timeout", c->timeout, 0);
+if (c->headers)
+av_dict_set(options, "headers", c->headers, 0);
}
static void write_codec_attr(AVStream *st, VariantStream *vs) {
@@ -3029,6 +3032,7 @@ static const AVOption options[] = {
{"http_persistent", "Use persistent HTTP connections",
OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
{"timeout", "set timeout for socket I/O operations", OFFSET(timeout),
AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
{"ignore_io_errors", "Ignore IO errors for stable long-duration runs with
network output", OFFSET(ignore_io_errors), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
1, E },
+{"headers", "set custom HTTP headers, can override built in default
headers", OFFSET(headers), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
{ NULL },
};
--
2.20.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, RFC, v2] lavc/phtread_frame: update context in child thread in multi-thread mode
On Wed, Jun 26, 2019 at 04:24:52PM -0400, Linjie Fu wrote: > Currently in ff_thread_decode_frame, context is updated from child thread > to main thread, and main thread releases the context in avcodec_close() > when decode finishes. > > However, when resolution/format change in vp9, ff_get_format was called, > and hwaccel_uninit() and hwaccel_init will be used to destroy and re-create > the context. Due to the async between main-thread and child-thread, > main-thread updated its context from child earlier than the context was > refreshed in child-thread. And it will lead to: > 1. memory leak in child-thread. > 2. double free in main-thread while calling avcodec_close(). > > Can be reproduced with a resolution change case in vp9, and use -vframes > to terminate the decode between the dynamic resolution change frames: > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v > verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync > passthrough -vframes 6 -y out.yuv > > Move update_context_from_thread from ff_thread_decode_frame(main thread) > to frame_worker_thread(child thread), update the context in child thread > right after the context was updated to avoid the async issue. > > Signed-off-by: Linjie Fu > --- > Request for Comments, not quite familiar with the constraints. > Thanks in advance. i dont think i fully understand the problem you are trying to fix but this patch looks like it writes into the users context without any lock while the user can access it. Thats looks like a race condition unless iam missing something What is very noticable though is that you seem to talk about vp9 why is this vp9 specific and does not affect other codecs ? thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" 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] print pts as min:sec
On 6/26/19, Ulf Zibis wrote: > > Am 26.06.19 um 12:26 schrieb Moritz Barsnick: >> This list is for the development *of* ffmpeg and its libraries. For the >> use of the libraries and the development *with* them, please turn to >> the mailing list "libav-user". > > Sorry, if I misunderstood. > > I'm in progress to develop a new filter and will provide a patch if I'm > ready. So I'm wrong on this list? Some questions due to question nature belong to different mailing list. Is this so hard to grasp? > >> Regarding your request, you can look at libavfilter/vf_showinfo.c. >> filter_frame() has an av_log() line which should show the calculation >> you are looking for: >> >> av_log(ctx, AV_LOG_INFO, >>"n:%4"PRId64" pts:%7s pts_time:%-7s pos:%9"PRId64" " >> [...] >> av_ts2str(frame->pts), av_ts2timestr(frame->pts, &inlink->time_base), >> frame->pkt_pos, > > Great! Much thanks! > > -Ulf > > ___ > 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 v2 5/9] lavc/qsvdec: Add VP9 decoder support
On 6/26/2019 3:00 AM, Li, Zhong wrote: > > >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Li, Zhong >> Sent: Tuesday, April 16, 2019 10:32 AM >> To: FFmpeg development discussions and patches >> >> Subject: Re: [FFmpeg-devel] [PATCH v2 5/9] lavc/qsvdec: Add VP9 decoder >> support >> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On >> Behalf >>> Of Mark Thompson >>> Sent: Tuesday, April 2, 2019 7:40 AM >>> To: ffmpeg-devel@ffmpeg.org >>> Subject: [FFmpeg-devel] [PATCH v2 5/9] lavc/qsvdec: Add VP9 decoder >>> support >>> >>> From: Zhong Li >>> >>> VP9 decoder is supported on Intel kabyLake+ platforms with MSDK >>> Version 1.19+ >>> >>> Signed-off-by: Zhong Li >>> --- >>> On 20/03/2019 14:41, Li, Zhong wrote: Yes, QSV is a marketing name which is no equal to libmfx/MSDK. But would be better to keep consistent with others, such as "Intel >>> QSV-accelerated VP8 video decoding" in pervious changelog? >>> >>> I don't think so? VP9 decoding with the QSV hardware is already >>> supported, this only adds the additional option of using libmfx to >>> access the same thing as well. >> >> Ok, here are just some words description of changelog. I will be happy to see >> this patch can be applied. >> (As previous comment, the updated version of vp9 parser with pic_type of >> key frame issue fixing LGTM.) > > Ping? > > If nobody against, I will merge it with cbs vp9 parser patch during one week. Please, don't push a patchset written by Mark without his approval. I reviewed a few other patches from this set and he will most likely submit a new version for all of them. ___ 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/2] avcodec/hevc_ps: Fix integer overflow with num_tile_rows and num_tile_columns
On 6/26/2019 9:41 AM, Michael Niedermayer wrote:
> On Tue, Jun 25, 2019 at 10:30:45AM -0300, James Almer wrote:
>> On 6/25/2019 5:55 AM, Michael Niedermayer wrote:
>>> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
>>> type 'int'
>>> Fixes:
>>> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
>>>
>>> Found-by: continuous fuzzing process
>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/hevc_ps.c | 23 +--
>>> libavcodec/hevc_ps.h | 4 ++--
>>> 2 files changed, 15 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>>> index 80df417e4f..07d220a5c8 100644
>>> --- a/libavcodec/hevc_ps.c
>>> +++ b/libavcodec/hevc_ps.c
>>> @@ -1584,22 +1584,25 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
>>> AVCodecContext *avctx,
>>> pps->entropy_coding_sync_enabled_flag = get_bits1(gb);
>>>
>>> if (pps->tiles_enabled_flag) {
>>> -pps->num_tile_columns = get_ue_golomb_long(gb) + 1;
>>> -pps->num_tile_rows= get_ue_golomb_long(gb) + 1;
>>> -if (pps->num_tile_columns <= 0 ||
>>> -pps->num_tile_columns >= sps->width) {
>>> +int num_tile_columns_minus1 = get_ue_golomb(gb);
>>> +int num_tile_rows_minus1= get_ue_golomb(gb);
>>> +
>>> +if (num_tile_columns_minus1 < 0 ||
>>
>> num_tile_columns_minus1 can never be < 0 for an int now that you're
>> using get_ue_golomb(gb). It returns values from 0 to 8190.
>> Add an av_assert0, at most. A value < 0 would mean there's a huge bug in
>> golomb.h, and not invalid bitstream data.
>>
>> And since you got rid of the "- 1" calculation below, which was your
>> original concern, you could also just make this unsigned. There's really
>> no need for an int at all.
>
> If you look at get_ue_golomb() in golomb.h
> static inline int get_ue_golomb(GetBitContext *gb)
> ...
> there is a case that does:
> return AVERROR_INVALIDDATA;
>
> That is a negative value an should be checked for before
> truncating to uint8_t. There is no gurantee that error codes
> when cast to uint8_t would not map to valid values.
I had not seen that. The doxy for the function mentioned the valid range
it can return, but made no mention of the chance for an AVERROR* value.
int is ok and the patch should be good, then. Sorry for the noise.
Any opinion about the struct field size? Is uint8_t enough? Your
original suggestion of uint16_t may be a safer bet, as i mentioned.
Looking at CBS Mark limited these fields to the max allowed value level
6.2 allows for them (20 and 22), but we're not doing that here, so
num_tile_[cols,rows}_minus1 could in theory and in some extreme cases go
beyond 255.
>
> also i belive that returning an error in cases that are
> outside 0 to 8190 is the correct thing to do, so the
> implementation which returns this appears to do the correct
> thing to me.
>
> 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 1/2] avcodec/hevc_ps: Fix integer overflow with num_tile_rows and num_tile_columns
On Tue, Jun 25, 2019 at 10:30:45AM -0300, James Almer wrote:
> On 6/25/2019 5:55 AM, Michael Niedermayer wrote:
> > Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
> > type 'int'
> > Fixes:
> > 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/hevc_ps.c | 23 +--
> > libavcodec/hevc_ps.h | 4 ++--
> > 2 files changed, 15 insertions(+), 12 deletions(-)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 80df417e4f..07d220a5c8 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1584,22 +1584,25 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> > AVCodecContext *avctx,
> > pps->entropy_coding_sync_enabled_flag = get_bits1(gb);
> >
> > if (pps->tiles_enabled_flag) {
> > -pps->num_tile_columns = get_ue_golomb_long(gb) + 1;
> > -pps->num_tile_rows= get_ue_golomb_long(gb) + 1;
> > -if (pps->num_tile_columns <= 0 ||
> > -pps->num_tile_columns >= sps->width) {
> > +int num_tile_columns_minus1 = get_ue_golomb(gb);
> > +int num_tile_rows_minus1= get_ue_golomb(gb);
> > +
> > +if (num_tile_columns_minus1 < 0 ||
>
> num_tile_columns_minus1 can never be < 0 for an int now that you're
> using get_ue_golomb(gb). It returns values from 0 to 8190.
> Add an av_assert0, at most. A value < 0 would mean there's a huge bug in
> golomb.h, and not invalid bitstream data.
>
> And since you got rid of the "- 1" calculation below, which was your
> original concern, you could also just make this unsigned. There's really
> no need for an int at all.
If you look at get_ue_golomb() in golomb.h
static inline int get_ue_golomb(GetBitContext *gb)
...
there is a case that does:
return AVERROR_INVALIDDATA;
That is a negative value an should be checked for before
truncating to uint8_t. There is no gurantee that error codes
when cast to uint8_t would not map to valid values.
also i belive that returning an error in cases that are
outside 0 to 8190 is the correct thing to do, so the
implementation which returns this appears to do the correct
thing to me.
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The smallest minority on earth is the individual. Those who deny
individual rights cannot claim to be defenders of minorities. - Ayn Rand
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 v10 1/2] lavf/vf_transpose: add exif orientation support
Jun Li 于2019年6月25日周二 上午9:26写道：
>
> On Mon, Jun 17, 2019 at 5:31 PM Jun Li wrote:
>
> >
> >
> > On Sat, Jun 15, 2019 at 7:09 PM Jun Li wrote:
> >
> >>
> >>
> >> On Tue, Jun 11, 2019 at 7:05 PM Jun Li wrote:
> >>
> >>>
> >>> On Sun, Jun 9, 2019 at 2:28 PM Jun Li wrote:
> >>>
> Add exif orientation support and expose an option.
> ---
> libavfilter/hflip.h| 2 +
> libavfilter/transpose.h| 14
> libavfilter/vf_hflip.c | 40 ++---
> libavfilter/vf_transpose.c | 168 -
> 4 files changed, 192 insertions(+), 32 deletions(-)
>
> diff --git a/libavfilter/hflip.h b/libavfilter/hflip.h
> index 204090dbb4..4e89bae3fc 100644
> --- a/libavfilter/hflip.h
> +++ b/libavfilter/hflip.h
> @@ -35,5 +35,7 @@ typedef struct FlipContext {
>
> int ff_hflip_init(FlipContext *s, int step[4], int nb_planes);
> void ff_hflip_init_x86(FlipContext *s, int step[4], int nb_planes);
> +int ff_hflip_config_props(FlipContext* s, AVFilterLink *inlink);
> +int ff_hflip_filter_slice(FlipContext *s, AVFrame *in, AVFrame *out,
> int job, int nb_jobs, int vlifp);
>
> #endif /* AVFILTER_HFLIP_H */
> diff --git a/libavfilter/transpose.h b/libavfilter/transpose.h
> index aa262b9487..5da08bddc0 100644
> --- a/libavfilter/transpose.h
> +++ b/libavfilter/transpose.h
> @@ -34,4 +34,18 @@ enum TransposeDir {
> TRANSPOSE_VFLIP,
> };
>
> +enum OrientationType {
> +ORIENTATION_AUTO_TRANSPOSE = -2,
> +ORIENTATION_AUTO_FLIP = -1,
> +ORIENTATION_NONE = 0,
> +ORIENTATION_NORMAL,
> +ORIENTATION_HFLIP,
> +ORIENTATION_ROTATE180,
> +ORIENTATION_VFLIP,
> +ORIENTATION_HFLIP_ROTATE270CW,
> +ORIENTATION_ROTATE90CW,
> +ORIENTATION_HFLIP_ROTATE90CW,
> +ORIENTATION_ROTATE270CW
> +};
> +
> #endif
> diff --git a/libavfilter/vf_hflip.c b/libavfilter/vf_hflip.c
> index b77afc77fc..d24ca5c2e7 100644
> --- a/libavfilter/vf_hflip.c
> +++ b/libavfilter/vf_hflip.c
> @@ -125,9 +125,8 @@ static void hflip_qword_c(const uint8_t *ssrc,
> uint8_t *ddst, int w)
> dst[j] = src[-j];
> }
>
> -static int config_props(AVFilterLink *inlink)
> +int ff_hflip_config_props(FlipContext* s, AVFilterLink *inlink)
> {
> -FlipContext *s = inlink->dst->priv;
> const AVPixFmtDescriptor *pix_desc =
> av_pix_fmt_desc_get(inlink->format);
> const int hsub = pix_desc->log2_chroma_w;
> const int vsub = pix_desc->log2_chroma_h;
> @@ -144,6 +143,12 @@ static int config_props(AVFilterLink *inlink)
> return ff_hflip_init(s, s->max_step, nb_planes);
> }
>
> +static int config_props(AVFilterLink *inlink)
> +{
> +FlipContext *s = inlink->dst->priv;
> +return ff_hflip_config_props(s, inlink);
> +}
> +
> int ff_hflip_init(FlipContext *s, int step[4], int nb_planes)
> {
> int i;
> @@ -170,14 +175,10 @@ typedef struct ThreadData {
> AVFrame *in, *out;
> } ThreadData;
>
> -static int filter_slice(AVFilterContext *ctx, void *arg, int job, int
> nb_jobs)
> +int ff_hflip_filter_slice(FlipContext *s, AVFrame *in, AVFrame *out,
> int job, int nb_jobs, int vflip)
> {
> -FlipContext *s = ctx->priv;
> -ThreadData *td = arg;
> -AVFrame *in = td->in;
> -AVFrame *out = td->out;
> uint8_t *inrow, *outrow;
> -int i, plane, step;
> +int i, plane, step, outlinesize;
>
> for (plane = 0; plane < 4 && in->data[plane] &&
> in->linesize[plane]; plane++) {
> const int width = s->planewidth[plane];
> @@ -187,19 +188,36 @@ static int filter_slice(AVFilterContext *ctx,
> void *arg, int job, int nb_jobs)
>
> step = s->max_step[plane];
>
> -outrow = out->data[plane] + start * out->linesize[plane];
> -inrow = in ->data[plane] + start * in->linesize[plane] +
> (width - 1) * step;
> +if (vflip) {
> +outrow = out->data[plane] + (height - start - 1)*
> out->linesize[plane];
> +outlinesize = -out->linesize[plane];
> +} else {
> +outrow = out->data[plane] + start * out->linesize[plane];
> +outlinesize = out->linesize[plane];
> +}
> +
> +inrow = in->data[plane] + start * in->linesize[plane] +
> (width - 1) * step;
> +
> for (i = start; i < end; i++) {
> s->flip_line[plane](inrow, outrow, width);
>
> inrow += in ->linesize[plane];
> -outrow += out->linesize[plane];
> +outrow += outli
Re: [FFmpeg-devel] [PATCH v2] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation
On Tue, Jun 25, 2019 at 06:47:30AM +, Jacob Siddall wrote: > The previous calculation code did not account for the fact that the > copy_offset for the start of the frame array is at index 0, yet the > scan line number from the rfc4175 RTP header starts at 1. > This caused 2 issues to appear: > - The first scan line was being copied into the array where the second > scan line should be. This caused the resulting video to have a green > line at the top of it. > - Since the packet containing the last scan line would fail the > calculation, the packet with the RTP marker would not be processed > which caused a log message saying "Missed previous RTP marker" to be > outputted for each frame. > > Signed-off-by: Jacob Siddall > --- > Changes in v2: > - Don't handle packet if the line number is less than 1 > > Section 12 in the VSF technical recommendation TR-03 specifies that the > video scan line numbers should start at 1. > http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf > > libavformat/rtpdec_rfc4175.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) git seems to not like the patch: Applying: avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation Using index info to reconstruct a base tree... error: patch failed: libavformat/rtpdec_rfc4175.c:205 error: libavformat/rtpdec_rfc4175.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. Patch failed at 0001 avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri 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".
[FFmpeg-devel] [PATCH] lavc/videotoolboxenc: add hdr10, linear, hlg color transfer function for videotoolboxenc
From: Limin Wang
Below is the testing ffmpeg command for the setting:
./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020 -colorspace
bt2020_ncl -color_trc smpte2084 smpte2048.ts
./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020 -colorspace
bt2020_ncl -color_trc linear linear.ts
./ffmpeg -i input.ts -c:v hevc_videotoolbox -color_primaries bt2020 -colorspace
bt2020_ncl -color_trc arib-std-b67 hlg.ts
Signed-off-by: Limin Wang
---
configure| 6 ++
libavcodec/videotoolboxenc.c | 16
2 files changed, 22 insertions(+)
diff --git a/configure b/configure
index 7cea9d4d73..0a5e940c0c 100755
--- a/configure
+++ b/configure
@@ -2260,6 +2260,9 @@ TOOLCHAIN_FEATURES="
TYPES_LIST="
kCMVideoCodecType_HEVC
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange
+kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ
+kCVImageBufferTransferFunction_ITU_R_2100_HLG
+kCVImageBufferTransferFunction_Linear
socklen_t
struct_addrinfo
struct_group_source_req
@@ -6044,6 +6047,9 @@ enabled videotoolbox && {
check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString
"-framework CoreServices"
check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_HEVC
"-framework CoreMedia"
check_func_headers CoreVideo/CVPixelBuffer.h
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange "-framework CoreVideo"
+check_func_headers CoreVideo/CVImageBuffer.h
kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ "-framework CoreVideo"
+check_func_headers CoreVideo/CVImageBuffer.h
kCVImageBufferTransferFunction_ITU_R_2100_HLG "-framework CoreVideo"
+check_func_headers CoreVideo/CVImageBuffer.h
kCVImageBufferTransferFunction_Linear "-framework CoreVideo"
}
check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index f8ccdea52d..0dc6eb4cf4 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -915,6 +915,22 @@ static int get_cv_transfer_function(AVCodecContext *avctx,
*transfer_fnc = kCVImageBufferTransferFunction_SMPTE_240M_1995;
break;
+#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_SMPTE_ST_2084_PQ
+case AVCOL_TRC_SMPTE2084:
+*transfer_fnc = kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ;
+break;
+#endif
+#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_LINEAR
+case AVCOL_TRC_LINEAR:
+*transfer_fnc = kCVImageBufferTransferFunction_Linear;
+break;
+#endif
+#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_ITU_R_2100_HLG
+case AVCOL_TRC_ARIB_STD_B67:
+*transfer_fnc = kCVImageBufferTransferFunction_ITU_R_2100_HLG;
+break;
+#endif
+
case AVCOL_TRC_GAMMA22:
gamma = 2.2;
*transfer_fnc = kCVImageBufferTransferFunction_UseGamma;
--
2.21.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] avcodec: add delayer bitstream filter
Hi Moritz, > > Wouldn't this be better if extended to be a BSF version of setpts? In > > addition to delays, rescaling as well as other ops could be carried out > > on TS. > > I second that notion, or at least the suggestion of a setpts bsf. > > IMO, there is probably some functionality in filters which could be > implemented in bitstream filters, to allow it to apply to stream copy. I think it's a good idea. Just to say that from my point of view, it would be easier if another developer took care of including the functionality of other filters, because my knowledge of the project is not so deep. Still, I feel that it would be best to incorporate this BSF as it is and later on add more features. Do you agree? Regards. A.H. --- ___ 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 DICOM Support
On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote: > On 6/26/19, Michael Niedermayer wrote: > > On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: > >> > >> On 6/25/19 2:12 AM, Michael Niedermayer wrote: > >> >On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: > >> >>Hi! > >> >> > >> >> The code is to add DICOM Support. The patch is only for > >> >> uncompressed > >> >>dicom files using explicit value representation. I would extend it, once > >> >> i > >> >>clarify some doubts. As dicom image files contain lots of metadata > >> >> about > >> >>the patient. So, should i display that data while demuxing or should i > >> >>ignore and only demux the image data ?. In the current patch, i have > >> >> made an > >> >>option "-metadata", which when used will print the data on the terminal > >> >>while demuxing. > >> >metadata should be exported to be usable by applications. > >> > > >> >For teh API design a one test is that it should be possible to have a > >> >dicom file as input and a format with similar features as output and not > >> >loose any significant data. > >> >Printing to the terminal cannot achieve that easily. > >> > >> So, should i export it to a csv file ? > > > > does it fit into the metadata system we have ? > > > > To clarify, you mean frame metadata system? data that is specific to a frame would belong in the frame metadata data that is specific to a stream would belong into that streams metadata data that is specific to the container would belong to its metadata iam not sure if multiple streams or frames can be in a single dicom "container" / file. If they can then it should be clear what goes where if not then all 3 options would from the point of view of dicom be the same. And in that case what is most convenient for interoperation with other formats should be picked. That is lets introduce the least amount of differences to how similar data is handled in other formats [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. 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] print pts as min:sec
Am 26.06.19 um 12:26 schrieb Moritz Barsnick: > This list is for the development *of* ffmpeg and its libraries. For the > use of the libraries and the development *with* them, please turn to > the mailing list "libav-user". Sorry, if I misunderstood. I'm in progress to develop a new filter and will provide a patch if I'm ready. So I'm wrong on this list? > Regarding your request, you can look at libavfilter/vf_showinfo.c. > filter_frame() has an av_log() line which should show the calculation > you are looking for: > > av_log(ctx, AV_LOG_INFO, >"n:%4"PRId64" pts:%7s pts_time:%-7s pos:%9"PRId64" " > [...] > av_ts2str(frame->pts), av_ts2timestr(frame->pts, &inlink->time_base), > frame->pkt_pos, Great! Much thanks! -Ulf ___ 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] print pts as min:sec
On Tue, Jun 25, 2019 at 23:13:51 +0200, Ulf Zibis wrote: > is there a functionality in the ffmpeg library to print AVFrame pts > values in respect to AVRational time_base in human readable form? This list is for the development *of* ffmpeg and its libraries. For the use of the libraries and the development *with* them, please turn to the mailing list "libav-user". Regarding your request, you can look at libavfilter/vf_showinfo.c. filter_frame() has an av_log() line which should show the calculation you are looking for: av_log(ctx, AV_LOG_INFO, "n:%4"PRId64" pts:%7s pts_time:%-7s pos:%9"PRId64" " [...] av_ts2str(frame->pts), av_ts2timestr(frame->pts, &inlink->time_base), frame->pkt_pos, Moritz ___ 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] avcodec: add delayer bitstream filter
On Wed, Jun 26, 2019 at 01:06:56 +0530, Gyan wrote: > Wouldn't this be better if extended to be a BSF version of setpts? In > addition to delays, rescaling as well as other ops could be carried out > on TS. I second that notion, or at least the suggestion of a setpts bsf. IMO, there is probably some functionality in filters which could be implemented in bitstream filters, to allow it to apply to stream copy. Moritz ___ 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, RFC] lavc/phtread_frame: update context in child thread in multi-thread mode
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Wednesday, June 26, 2019 15:12
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, RFC] lavc/phtread_frame: update
> context in child thread in multi-thread mode
>
> On Wed, Jun 26, 2019 at 9:06 AM Linjie Fu wrote:
> >
> > Currently in ff_thread_decode_frame, context is updated from child
> thread
> > to main thread, and main thread releases the context in avcodec_close()
> > when decode finishes.
> >
> > However, when resolution/format change in vp9, ff_get_format was called,
> > and hwaccel_uninit() and hwaccel_init will be used to destroy and re-
> create
> > the context. Due to the async between main-thread and child-thread,
> > main-thread updated its context from child earlier than the context was
> > refreshed in child-thread. And it will lead to:
> > 1. memory leak in child-thread.
> > 2. double free in main-thread while calling avcodec_close().
> >
> > Can be reproduced with a resolution change case in vp9, and use -vframes
> > to terminate the decode between the dynamic resolution change frames:
> >
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
> > verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync
> > passthrough -vframes 6 -y out.yuv
> >
> > Move update_context_from_thread from ff_thread_decode_frame(main
> thread)
> > to frame_worker_thread(child thread), update the context in child thread
> > right after the context was updated to avoid the async issue.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > Request for Comments, not quite familiar with the constraints.
> > Thanks in advance.
> >
> > libavcodec/internal.h | 5 ++
> > libavcodec/pthread_frame.c | 164 --
> ---
> > 2 files changed, 91 insertions(+), 78 deletions(-)
> >
> > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > index 5096ffa..9f4ed0b 100644
> > --- a/libavcodec/internal.h
> > +++ b/libavcodec/internal.h
> > @@ -162,6 +162,11 @@ typedef struct AVCodecInternal {
> >
> > void *thread_ctx;
> >
> > +/**
> > + * Main thread AVCodecContext pointer
> > + */
> > +void *main_thread;
> > +
> > DecodeSimpleContext ds;
> > DecodeFilterContext filter;
> >
> > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > index 36ac0ac..be42e98 100644
> > --- a/libavcodec/pthread_frame.c
> > +++ b/libavcodec/pthread_frame.c
> > @@ -159,82 +159,6 @@ static void async_unlock(FrameThreadContext
> *fctx)
> > }
> >
> > /**
> > - * Codec worker thread.
> > - *
> > - * Automatically calls ff_thread_finish_setup() if the codec does
> > - * not provide an update_thread_context method, or if the codec returns
> > - * before calling it.
> > - */
> > -static attribute_align_arg void *frame_worker_thread(void *arg)
> > -{
> > -PerThreadContext *p = arg;
> > -AVCodecContext *avctx = p->avctx;
> > -const AVCodec *codec = avctx->codec;
> > -
> > -pthread_mutex_lock(&p->mutex);
> > -while (1) {
> > -while (atomic_load(&p->state) == STATE_INPUT_READY && !p->die)
> > -pthread_cond_wait(&p->input_cond, &p->mutex);
> > -
> > -if (p->die) break;
> > -
> > -if (!codec->update_thread_context &&
> THREAD_SAFE_CALLBACKS(avctx))
> > -ff_thread_finish_setup(avctx);
> > -
> > -/* If a decoder supports hwaccel, then it must call
> > ff_get_format().
> > - * Since that call must happen before ff_thread_finish_setup(), the
> > - * decoder is required to implement update_thread_context() and
> > call
> > - * ff_thread_finish_setup() manually. Therefore the above
> > - * ff_thread_finish_setup() call did not happen and
> > hwaccel_serializing
> > - * cannot be true here. */
> > -av_assert0(!p->hwaccel_serializing);
> > -
> > -/* if the previous thread uses hwaccel then we take the lock to
> > ensure
> > - * the threads don't run concurrently */
> > -if (avctx->hwaccel) {
> > -pthread_mutex_lock(&p->parent->hwaccel_mutex);
> > -p->hwaccel_serializing = 1;
> > -}
> > -
> > -av_frame_unref(p->frame);
> > -p->got_frame = 0;
> > -p->result = codec->decode(avctx, p->frame, &p->got_frame, &p-
> >avpkt);
> > -
> > -if ((p->result < 0 || !p->got_frame) && p->frame->buf[0]) {
> > -if (avctx->internal->allocate_progress)
> > -av_log(avctx, AV_LOG_ERROR, "A frame threaded decoder did
> not "
> > - "free the frame on failure. This is a bug, please
> > report it.\n");
> > -av_frame_unref(p->frame);
> > -}
> > -
> > -if (atomic_load(&p->state) == STATE_SETTING_UP)
> > -ff_thread_finish_setup(avctx);
> > -
> > -if (p->hwaccel_serializing) {
> > -
[FFmpeg-devel] [PATCH, RFC, v2] lavc/phtread_frame: update context in child thread in multi-thread mode
Currently in ff_thread_decode_frame, context is updated from child thread
to main thread, and main thread releases the context in avcodec_close()
when decode finishes.
However, when resolution/format change in vp9, ff_get_format was called,
and hwaccel_uninit() and hwaccel_init will be used to destroy and re-create
the context. Due to the async between main-thread and child-thread,
main-thread updated its context from child earlier than the context was
refreshed in child-thread. And it will lead to:
1. memory leak in child-thread.
2. double free in main-thread while calling avcodec_close().
Can be reproduced with a resolution change case in vp9, and use -vframes
to terminate the decode between the dynamic resolution change frames:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync
passthrough -vframes 6 -y out.yuv
Move update_context_from_thread from ff_thread_decode_frame(main thread)
to frame_worker_thread(child thread), update the context in child thread
right after the context was updated to avoid the async issue.
Signed-off-by: Linjie Fu
---
Request for Comments, not quite familiar with the constraints.
Thanks in advance.
libavcodec/internal.h | 5 +
libavcodec/pthread_frame.c | 12 +---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 5096ffa..9f4ed0b 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -162,6 +162,11 @@ typedef struct AVCodecInternal {
void *thread_ctx;
+/**
+ * Main thread AVCodecContext pointer
+ */
+void *main_thread;
+
DecodeSimpleContext ds;
DecodeFilterContext filter;
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 36ac0ac..2730a8c 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -140,6 +140,8 @@ typedef struct FrameThreadContext {
#define THREAD_SAFE_CALLBACKS(avctx) \
((avctx)->thread_safe_callbacks || (avctx)->get_buffer2 ==
avcodec_default_get_buffer2)
+static int update_context_from_thread(AVCodecContext *dst, AVCodecContext
*src, int for_user);
+
static void async_lock(FrameThreadContext *fctx)
{
pthread_mutex_lock(&fctx->async_mutex);
@@ -157,7 +159,6 @@ static void async_unlock(FrameThreadContext *fctx)
pthread_cond_broadcast(&fctx->async_cond);
pthread_mutex_unlock(&fctx->async_mutex);
}
-
/**
* Codec worker thread.
*
@@ -200,6 +201,10 @@ static attribute_align_arg void *frame_worker_thread(void
*arg)
p->got_frame = 0;
p->result = codec->decode(avctx, p->frame, &p->got_frame, &p->avpkt);
+if (p->avctx->internal->main_thread)
+update_context_from_thread((AVCodecContext
*)p->avctx->internal->main_thread,
+
p->avctx, 1);
+
if ((p->result < 0 || !p->got_frame) && p->frame->buf[0]) {
if (avctx->internal->allocate_progress)
av_log(avctx, AV_LOG_ERROR, "A frame threaded decoder did not "
@@ -540,8 +545,6 @@ int ff_thread_decode_frame(AVCodecContext *avctx,
if (finished >= avctx->thread_count) finished = 0;
} while (!avpkt->size && !*got_picture_ptr && err >= 0 && finished !=
fctx->next_finished);
-update_context_from_thread(avctx, p->avctx, 1);
-
if (fctx->next_decoding >= avctx->thread_count) fctx->next_decoding = 0;
fctx->next_finished = finished;
@@ -728,6 +731,8 @@ int ff_frame_thread_init(AVCodecContext *avctx)
FrameThreadContext *fctx;
int i, err = 0;
+avctx->internal->main_thread = avctx;
+
if (!thread_count) {
int nb_cpus = av_cpu_count();
#if FF_API_DEBUG_MV
@@ -800,6 +805,7 @@ int ff_frame_thread_init(AVCodecContext *avctx)
*copy->internal = *src->internal;
copy->internal->thread_ctx = p;
copy->internal->last_pkt_props = &p->avpkt;
+copy->internal->main_thread = avctx;
if (!i) {
src = copy;
--
2.7.4
___
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 DICOM Support
On 6/26/19, Michael Niedermayer wrote: > On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: >> >> On 6/25/19 2:12 AM, Michael Niedermayer wrote: >> >On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: >> >>Hi! >> >> >> >> The code is to add DICOM Support. The patch is only for >> >> uncompressed >> >>dicom files using explicit value representation. I would extend it, once >> >> i >> >>clarify some doubts. As dicom image files contain lots of metadata >> >> about >> >>the patient. So, should i display that data while demuxing or should i >> >>ignore and only demux the image data ?. In the current patch, i have >> >> made an >> >>option "-metadata", which when used will print the data on the terminal >> >>while demuxing. >> >metadata should be exported to be usable by applications. >> > >> >For teh API design a one test is that it should be possible to have a >> >dicom file as input and a format with similar features as output and not >> >loose any significant data. >> >Printing to the terminal cannot achieve that easily. >> >> So, should i export it to a csv file ? > > does it fit into the metadata system we have ? > To clarify, you mean frame metadata system? ___ 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 DICOM Support
On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: > > On 6/25/19 2:12 AM, Michael Niedermayer wrote: > >On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: > >>Hi! > >> > >> The code is to add DICOM Support. The patch is only for uncompressed > >>dicom files using explicit value representation. I would extend it, once i > >>clarify some doubts. As dicom image files contain lots of metadata about > >>the patient. So, should i display that data while demuxing or should i > >>ignore and only demux the image data ?. In the current patch, i have made an > >>option "-metadata", which when used will print the data on the terminal > >>while demuxing. > >metadata should be exported to be usable by applications. > > > >For teh API design a one test is that it should be possible to have a > >dicom file as input and a format with similar features as output and not > >loose any significant data. > >Printing to the terminal cannot achieve that easily. > > So, should i export it to a csv file ? does it fit into the metadata system we have ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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] libavformat/mpegtsenc: new interlaced mux mode
Hi Marton,
> Ok. But I believe the correct term for this is "interleaved". I have
> never heard "interlaced" used for TS packets.
I feel you're right: the name "interleaved mux mode" is preferable.
Thank you for pointing it out!
> > > > +#define PES_START 1 /* 0001 /
> > > > +#define PES_FULL 2 / 0010 */
> > >
> > > > +#define UNUSED_FLAG_3 4 /* 0100 /
> > > > +#define UNUSED_FLAG_4 8 / 1000 /
> > > > +#define UNUSED_FLAG_5 16 / 0001 /
> > > > +#define UNUSED_FLAG_6 32 / 0010 /
> > > > +#define UNUSED_FLAG_7 64 / 0100 */
> > >
> > > Is it relevant to include these?
> >
> > No. It's not necessary. However, they make the code more compressible and
> > can be
> > used in the future for other flags.
>
> Don't include them if they are not needed. It would be also a good idea
> to name them xxx_FLAG if these are indeed flags. e.g.:
>
> PES_START_FLAG
> PES_FULL_FLAG
> PES_NEEDS_END_FLAG
OK. I agree.
> also I see no reason that PES_NEEDS_END is 128. Just make it 4.
Ummm... The reason for leaving values unused is for future improvements.
If another developer needs to use a new FLAG, it is mandatory to avoid
collisions.
Perhaps a simple comment like that is preferable:
/* Unused free flags: 4,8,16,32,64 */
> And keep the indentation pretty.
In the patch the identation is correct!
> > > > -ts_st->payload = av_mallocz(ts->pes_payload_size);
> > > > +ts_st->payload = av_mallocz(ts->parallel_mux ?
> > > > MAX_PES_PAYLOAD : ts->pes_payload_size);
> > >
> > > Could you clarify why this needs to be changed?
> >
> > Sure! Because when you write in parallel you're delaying the writing of the
> > PES packet.
> > So you need to save the entire PES packet. And the ts->pes_payload_size
> > it's defined to
> > a very small value (2734 Bytes only)... See at the top of the mpegtsenc.c
> > file:
> > #define DEFAULT_PES_HEADER_FREQ 16
> > #define DEFAULT_PES_PAYLOAD_SIZE ((DEFAULT_PES_HEADER_FREQ - 1) * 184 + 170)
>
> OK, but you shold override ts->pes_payload_size, and not the malloc, no?
> There is code in mpegts_init which sets pes_payload_size, you should force
> it to MAX_PES_PAYLOAD there before doing the round up.
No, no! If I override the ts->pes_payload_size then when not using the
interleaved some unused memory will be allocated. Please note that when using
the
sequential mode the payload is writed "directly" to the output stream. And this
is
true with PES packets with a size greater than pes_payload_size (i.e. video). So
the ts->pes_payload_size is used only to store small writes until a PES packet
is complete. However, when using the interleaved mode the entire PES packet
requires
to be saved until the last part is writed in the output stream. For this reason
the
malloc has different values.
> > > > + for (i = 0; i < ts->nb_services; i++) {
> > > > +service = ts->services[i];
> > > > ...
> > > > }
> > > >
> > >
> > > Why do you need the loop over the services here? It seems unrelated unless
> > > I missed something.
> >
> > I explained it in my original message...
> > The current code has a bug and it doesn't set correctly the value of the
> > service->pcr_pid. And this patch requires correct values of pcr_pid for each
> > program. Please note that this patch makes complete sense when mixing
> > multiple
> > video streams, such as when using multiple programs.
>
> This should be a separate patch then. I suggest implementing this before
> adding interleaving support.
Yes and not...
1. This interleaved mode requires correct value of the service->pcr_pid, as it
have
sense with multiple programs. So the "patch" here is mandatory. We can assume
that
it's part of the new mux mode.
2. With the sequential mode, the service->pcr_pid bug is hidden, because no one
uses
multiple programs. So a lot of work for me for an irrelevant fix.
So I'd prefer to just comment here, and make it all one single change.
> > > > + - NOTE: 'payload' contains a complete PES payload.
> > > > + - NOTE2: When 'mode' < -1 it writes the rest of the payload
> > > > (without header);
> > > > + - When 'mode' = -1 it writes the entire payload with the
> > > > header;
> > > > + - when 'mode' = 0 it writes only one TS packet with the
> > > > header;
> > > > + - when 'mode' > 0 it writes only one TS packet.
> > > >
> > >
> > > Enum for mode would make more sense to me
> >
> > Yes and not. The code is more compact in this case with numerical values,
> > as you
> > don't need to do checks when you call to the function.
>
> The code might be more compact, and tons of less readable. Use enums, or
> defines. You might also use flags for mode, if that makes the code more
> readable.
I'm sorry, no. In my opinion it's more legible and compact like that.
I accept all your comments, and I appreciate them. But in this case I do not
see the advantage.
> > > > +payload_size = 0; // Write one pa
Re: [FFmpeg-devel] [PATCH, RFC] lavc/phtread_frame: update context in child thread in multi-thread mode
On Wed, Jun 26, 2019 at 9:06 AM Linjie Fu wrote:
>
> Currently in ff_thread_decode_frame, context is updated from child thread
> to main thread, and main thread releases the context in avcodec_close()
> when decode finishes.
>
> However, when resolution/format change in vp9, ff_get_format was called,
> and hwaccel_uninit() and hwaccel_init will be used to destroy and re-create
> the context. Due to the async between main-thread and child-thread,
> main-thread updated its context from child earlier than the context was
> refreshed in child-thread. And it will lead to:
> 1. memory leak in child-thread.
> 2. double free in main-thread while calling avcodec_close().
>
> Can be reproduced with a resolution change case in vp9, and use -vframes
> to terminate the decode between the dynamic resolution change frames:
>
> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
> verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync
> passthrough -vframes 6 -y out.yuv
>
> Move update_context_from_thread from ff_thread_decode_frame(main thread)
> to frame_worker_thread(child thread), update the context in child thread
> right after the context was updated to avoid the async issue.
>
> Signed-off-by: Linjie Fu
> ---
> Request for Comments, not quite familiar with the constraints.
> Thanks in advance.
>
> libavcodec/internal.h | 5 ++
> libavcodec/pthread_frame.c | 164
> -
> 2 files changed, 91 insertions(+), 78 deletions(-)
>
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 5096ffa..9f4ed0b 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -162,6 +162,11 @@ typedef struct AVCodecInternal {
>
> void *thread_ctx;
>
> +/**
> + * Main thread AVCodecContext pointer
> + */
> +void *main_thread;
> +
> DecodeSimpleContext ds;
> DecodeFilterContext filter;
>
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 36ac0ac..be42e98 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -159,82 +159,6 @@ static void async_unlock(FrameThreadContext *fctx)
> }
>
> /**
> - * Codec worker thread.
> - *
> - * Automatically calls ff_thread_finish_setup() if the codec does
> - * not provide an update_thread_context method, or if the codec returns
> - * before calling it.
> - */
> -static attribute_align_arg void *frame_worker_thread(void *arg)
> -{
> -PerThreadContext *p = arg;
> -AVCodecContext *avctx = p->avctx;
> -const AVCodec *codec = avctx->codec;
> -
> -pthread_mutex_lock(&p->mutex);
> -while (1) {
> -while (atomic_load(&p->state) == STATE_INPUT_READY && !p->die)
> -pthread_cond_wait(&p->input_cond, &p->mutex);
> -
> -if (p->die) break;
> -
> -if (!codec->update_thread_context && THREAD_SAFE_CALLBACKS(avctx))
> -ff_thread_finish_setup(avctx);
> -
> -/* If a decoder supports hwaccel, then it must call ff_get_format().
> - * Since that call must happen before ff_thread_finish_setup(), the
> - * decoder is required to implement update_thread_context() and call
> - * ff_thread_finish_setup() manually. Therefore the above
> - * ff_thread_finish_setup() call did not happen and
> hwaccel_serializing
> - * cannot be true here. */
> -av_assert0(!p->hwaccel_serializing);
> -
> -/* if the previous thread uses hwaccel then we take the lock to
> ensure
> - * the threads don't run concurrently */
> -if (avctx->hwaccel) {
> -pthread_mutex_lock(&p->parent->hwaccel_mutex);
> -p->hwaccel_serializing = 1;
> -}
> -
> -av_frame_unref(p->frame);
> -p->got_frame = 0;
> -p->result = codec->decode(avctx, p->frame, &p->got_frame, &p->avpkt);
> -
> -if ((p->result < 0 || !p->got_frame) && p->frame->buf[0]) {
> -if (avctx->internal->allocate_progress)
> -av_log(avctx, AV_LOG_ERROR, "A frame threaded decoder did
> not "
> - "free the frame on failure. This is a bug, please
> report it.\n");
> -av_frame_unref(p->frame);
> -}
> -
> -if (atomic_load(&p->state) == STATE_SETTING_UP)
> -ff_thread_finish_setup(avctx);
> -
> -if (p->hwaccel_serializing) {
> -p->hwaccel_serializing = 0;
> -pthread_mutex_unlock(&p->parent->hwaccel_mutex);
> -}
> -
> -if (p->async_serializing) {
> -p->async_serializing = 0;
> -
> -async_unlock(p->parent);
> -}
> -
> -pthread_mutex_lock(&p->progress_mutex);
> -
> -atomic_store(&p->state, STATE_INPUT_READY);
> -
> -pthread_cond_broadcast(&p->progress_cond);
> -pthread_cond_signal(&p->output_cond);
> -pthread_mutex_unlock(&p->progress_mutex);
> -}
> -pthread_mutex_unlock(&p->mutex);
> -
> -return NULL;
Re: [FFmpeg-devel] [PATCH] avcodec: add delayer bitstream filter
Hi Gyan, > > > Example of use: > > > ffmpeg -f mpegts -i INPUT.ts -map i:101 -c:v copy -map i:102 -bsf:a > > > delayer=offset=3600 -c:a copy -f mpegts OUTPUT.ts > > > You can use it with VIDEO, AUDIO or DATA streams. > > > > What's the advantage over output_ts_offset? > > To answer that partially, this can be applied per-stream. Yes! That's the key point. You can (manually) resynchronize streams (video with audio, multiple video, audio tracks...) withtout any reencoding. > Wouldn't this be better if extended to be a BSF version of setpts? In > addition to delays, rescaling as well as other ops could be carried out > on TS. Maybe. But I prefer to include this "simple" SFB plugin first. I'm using it and it works like a charm. Regards. A.H. --- ___ 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] avcodec: add delayer bitstream filter
Hi, > - Andreas Rheinhardt: > > Example of use: > > ffmpeg -f mpegts -i INPUT.ts -map i:101 -c:v copy -map i:102 -bsf:a > > delayer=offset=3600 -c:a copy -f mpegts OUTPUT.ts > > The delay applied here depends on the timebase. Wouldn't it be more > user-friendly to let the user input the delay in (say) microseconds > and convert it appropriately? You can see that inside the TODO comments there is something similar pointed. In the future you will be able to use Frames, Seconds or Absolute values. However, the first step would be to include the plugin as it is, don't you think? > And ff_delayer_bsf isn't properly aligned. Now, I see it... sorry! Regards. A.H. ___ 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, RFC] lavc/phtread_frame: update context in child thread in multi-thread mode
Currently in ff_thread_decode_frame, context is updated from child thread
to main thread, and main thread releases the context in avcodec_close()
when decode finishes.
However, when resolution/format change in vp9, ff_get_format was called,
and hwaccel_uninit() and hwaccel_init will be used to destroy and re-create
the context. Due to the async between main-thread and child-thread,
main-thread updated its context from child earlier than the context was
refreshed in child-thread. And it will lead to:
1. memory leak in child-thread.
2. double free in main-thread while calling avcodec_close().
Can be reproduced with a resolution change case in vp9, and use -vframes
to terminate the decode between the dynamic resolution change frames:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync
passthrough -vframes 6 -y out.yuv
Move update_context_from_thread from ff_thread_decode_frame(main thread)
to frame_worker_thread(child thread), update the context in child thread
right after the context was updated to avoid the async issue.
Signed-off-by: Linjie Fu
---
Request for Comments, not quite familiar with the constraints.
Thanks in advance.
libavcodec/internal.h | 5 ++
libavcodec/pthread_frame.c | 164 -
2 files changed, 91 insertions(+), 78 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 5096ffa..9f4ed0b 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -162,6 +162,11 @@ typedef struct AVCodecInternal {
void *thread_ctx;
+/**
+ * Main thread AVCodecContext pointer
+ */
+void *main_thread;
+
DecodeSimpleContext ds;
DecodeFilterContext filter;
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 36ac0ac..be42e98 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -159,82 +159,6 @@ static void async_unlock(FrameThreadContext *fctx)
}
/**
- * Codec worker thread.
- *
- * Automatically calls ff_thread_finish_setup() if the codec does
- * not provide an update_thread_context method, or if the codec returns
- * before calling it.
- */
-static attribute_align_arg void *frame_worker_thread(void *arg)
-{
-PerThreadContext *p = arg;
-AVCodecContext *avctx = p->avctx;
-const AVCodec *codec = avctx->codec;
-
-pthread_mutex_lock(&p->mutex);
-while (1) {
-while (atomic_load(&p->state) == STATE_INPUT_READY && !p->die)
-pthread_cond_wait(&p->input_cond, &p->mutex);
-
-if (p->die) break;
-
-if (!codec->update_thread_context && THREAD_SAFE_CALLBACKS(avctx))
-ff_thread_finish_setup(avctx);
-
-/* If a decoder supports hwaccel, then it must call ff_get_format().
- * Since that call must happen before ff_thread_finish_setup(), the
- * decoder is required to implement update_thread_context() and call
- * ff_thread_finish_setup() manually. Therefore the above
- * ff_thread_finish_setup() call did not happen and hwaccel_serializing
- * cannot be true here. */
-av_assert0(!p->hwaccel_serializing);
-
-/* if the previous thread uses hwaccel then we take the lock to ensure
- * the threads don't run concurrently */
-if (avctx->hwaccel) {
-pthread_mutex_lock(&p->parent->hwaccel_mutex);
-p->hwaccel_serializing = 1;
-}
-
-av_frame_unref(p->frame);
-p->got_frame = 0;
-p->result = codec->decode(avctx, p->frame, &p->got_frame, &p->avpkt);
-
-if ((p->result < 0 || !p->got_frame) && p->frame->buf[0]) {
-if (avctx->internal->allocate_progress)
-av_log(avctx, AV_LOG_ERROR, "A frame threaded decoder did not "
- "free the frame on failure. This is a bug, please
report it.\n");
-av_frame_unref(p->frame);
-}
-
-if (atomic_load(&p->state) == STATE_SETTING_UP)
-ff_thread_finish_setup(avctx);
-
-if (p->hwaccel_serializing) {
-p->hwaccel_serializing = 0;
-pthread_mutex_unlock(&p->parent->hwaccel_mutex);
-}
-
-if (p->async_serializing) {
-p->async_serializing = 0;
-
-async_unlock(p->parent);
-}
-
-pthread_mutex_lock(&p->progress_mutex);
-
-atomic_store(&p->state, STATE_INPUT_READY);
-
-pthread_cond_broadcast(&p->progress_cond);
-pthread_cond_signal(&p->output_cond);
-pthread_mutex_unlock(&p->progress_mutex);
-}
-pthread_mutex_unlock(&p->mutex);
-
-return NULL;
-}
-
-/**
* Update the next thread's AVCodecContext with values from the reference
thread's context.
*
* @param dst The destination context.
@@ -313,6 +237,89 @@ FF_ENABLE_DEPRECATION_WARNINGS
return err;
}
+
+
+/**
+ * Codec worker thread.
+ *
+ * Automatically calls ff_thread_finish_setup()
