Re: [FFmpeg-devel] Export display matrix mirroring info as part of the rotate API
On Thu, May 16, 2019 at 7:38 PM Vittorio Giovara
wrote:
> On Thu, May 16, 2019 at 9:32 PM Jun Li wrote:
>
> > On Thu, May 16, 2019 at 4:34 PM Ted Meyer <
> > tmathmeyer-at-google@ffmpeg.org> wrote:
> >
> > > Right now ffmpeg doesn't export a mirroring status when checking the
> > > display matrix for rotation.
> > > Here is an example video: https://files.tedm.io/flip.mp4
> > > -Ted
> > > ___
> > > 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".
> >
> >
> > There is a patch but not merged into master, quality not guaranteed :)
> > Hope this helps.
> > https://patchwork.ffmpeg.org/patch/13130/
> >
>
> hey i just noticed this patch
>
> +if (CONV_FP(m[0]) * CONV_FP(m[4]) < CONV_FP(m[1]) *
> CONV_FP(m[3])) {+*hflip = 1;+av_display_matrix_flip(m,
> 1, 0);+}
>
> the long if is basically computing the determinant of the matrix, but you
> only need the fact whether it's positive or negative, you can discard the
> result so you can avoid converting to CONV_FP, and just cast to int64_t
>
+return av_display_rotation_get(m);
>
> don't you need to set vertical flip only if det < 0 and rot = 180?
>
I think it should be fine and not need to check. Because vlip could be
represented as hflip+rotation, the cross product (Michael's brilliant idea)
m[0] * m[4] - m[1]*[3] cannot reflect it is horizontal or vertical flip.
It all depends how we want to represents the transform, it could be
"rotation+hflip" or "rotation+vlip".Any combination of rotation+flip
can be represented by either one.
> beside that small point, this patch introduces an api that basically
> supersedes the normal av_display_rotation_get(), and does many more things,
> I'd be tempted to deprecate any other use, and what do you think? in that
> case you could just call it av_display_rotation_get2() like is tradition
I can't find the other patches from the set to review, would you be able to
> send an updated version?
>
Thanks Vittorio, I updated the version as suggested:
https://patchwork.ffmpeg.org/patch/13181/
The original patch includes two part, but I am going to abandon it after
discussing with Nicolas.
The patches were for per frame flip/mirror and rotation. Basically it
checks every frame's meta-data and address flip or rotation or both.
I think it also covers stream level flip, addressed in ffmpeg_filter.c
(correct me if I am wrong).
https://patchwork.ffmpeg.org/patch/13131/
https://patchwork.ffmpeg.org/patch/13130/
Best Regards,
Jun
> thanks
> --
> Vittorio
> ___
> 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 v3 2/2] fftools/ffmpeg: add support for per frame rotation and flip
On Thu, May 16, 2019 at 9:21 PM Andriy Gelman
wrote:
> On Thu, 16. May 18:28, Jun Li wrote:
> > On Thu, May 16, 2019 at 12:54 PM Andriy Gelman
> > wrote:
> >
> > > Hi Jun,
> > >
> > > On Thu, 16. May 00:12, Jun Li wrote:
> > > > Fix #6945
> > > > Current implementaion for autorotate works fine for stream
> > > > level rotataion but no support for frame level operation
> > > > and frame flip. This patch is for adding flip support and
> > > > per frame operations.
> > > > ---
> > > > fftools/cmdutils.c | 9 ++---
> > > > fftools/cmdutils.h | 2 +-
> > > > fftools/ffmpeg.c| 21 ++-
> > > > fftools/ffmpeg.h| 2 +
> > > > fftools/ffmpeg_filter.c | 81
> ++---
> > > > fftools/ffplay.c| 28 +++---
> > > > 6 files changed, 126 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> > > > index 9cfbc45c2b..b8bb904419 100644
> > > > --- a/fftools/cmdutils.c
> > > > +++ b/fftools/cmdutils.c
> > > > @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size,
> int
> > > *size, int new_size)
> > > > return array;
> > > > }
> > > >
> > > > -double get_rotation(AVStream *st)
> > > > +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
> > > > {
> > > > -uint8_t* displaymatrix = av_stream_get_side_data(st,
> > > > -
> > > AV_PKT_DATA_DISPLAYMATRIX, NULL);
> > > > double theta = 0;
> > > > -if (displaymatrix)
> > > > -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> > > > +
> > > > +if (display_matrix)
> > > > +theta = -av_display_rotation_hflip_get(display_matrix,
> hflip);
> > > >
> > > > theta -= 360*floor(theta/360 + 0.9/360);
> > > >
> > > > diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> > > > index 6e2e0a2acb..dce44ed6e1 100644
> > > > --- a/fftools/cmdutils.h
> > > > +++ b/fftools/cmdutils.h
> > > > @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int
> > > *size, int new_size);
> > > > char name[128];\
> > > > av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
> > > >
> > > > -double get_rotation(AVStream *st);
> > > > +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
> > > >
> > > > #endif /* FFTOOLS_CMDUTILS_H */
> > > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > > > index 01f04103cf..9ea1aaa930 100644
> > > > --- a/fftools/ffmpeg.c
> > > > +++ b/fftools/ffmpeg.c
> > > > @@ -2126,6 +2126,24 @@ static int
> > > ifilter_has_all_input_formats(FilterGraph *fg)
> > > > return 1;
> > > > }
> > > >
> > > > +static int ifilter_display_matrix_need_from_frame(InputFilter
> *ifilter,
> > > AVFrame* frame)
> > > > +{
> > > > +int32_t* stream_matrix =
> > > (int32_t*)av_stream_get_side_data(ifilter->ist->st,
> > > > +
> > > AV_PKT_DATA_DISPLAYMATRIX, NULL);
> > > > +// if we already have display matrix from stream, use it
> instead of
> > > extracting
> > > > +// from frame.
> > > > +if (stream_matrix) {
> > > > +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
> > > > +return 0;
> > > > +}
> > > > +
> > > > +// cleanup the display matrix, may be from last frame
> > > > +memset(ifilter->display_matrix, 0, 4 * 9);
> > > > +av_display_rotation_set(ifilter->display_matrix, 0);
> > > > +
> > > > +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> > > > +}
> > > > +
> > > > static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
> > > > {
> > > > FilterGraph *fg = ifilter->graph;
> > > > @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter
> > > *ifilter, AVFrame *frame)
> > > > ifilter->channel_layout !=
> frame->channel_layout;
> > > > break;
> > > > case AVMEDIA_TYPE_VIDEO:
> > > > -need_reinit |= ifilter->width != frame->width ||
> > > > +need_reinit |=
> ifilter_display_matrix_need_from_frame(ifilter,
> > > frame) ||
> > > > + ifilter->width != frame->width ||
> > > > ifilter->height != frame->height;
> > > > break;
> > > > }
> > > > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > > > index eb1eaf6363..8331720663 100644
> > > > --- a/fftools/ffmpeg.h
> > > > +++ b/fftools/ffmpeg.h
> > > > @@ -251,6 +251,8 @@ typedef struct InputFilter {
> > > > int channels;
> > > > uint64_t channel_layout;
> > > >
> > > > +int32_t display_matrix[9];
> > > > +
> > > > AVBufferRef *hw_frames_ctx;
> > > >
> > > > int eof;
> > > > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > > > index 72838de1e2..1894f30561 100644
> > > > --- a/fftools/ffmpeg_filter.c
> > > > +++ b/fftools/ffmpeg_filter.c
> > > > @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg,
> > > AVFilterInOut *in)
> > > > fg->inputs[fg->nb_inputs - 1]->format = -1;
> > > > fg->inputs[fg->nb_inputs - 1]->
Re: [FFmpeg-devel] [PATCH]
On 16-05-2019 06:29 PM, Werner Robitza wrote: On Wed, May 15, 2019 at 11:23 PM Michael Niedermayer wrote: On Wed, May 15, 2019 at 11:13:57PM +0200, Werner Robitza wrote: On Wed, May 15, 2019 at 4:55 PM Gyan wrote: On 15-05-2019 05:06 PM, Werner Robitza wrote: On Wed, May 15, 2019 at 11:36 AM Gyan wrote: Which lines in the CLI help? SWScaler AVOptions: -sws_flags E..V. scaler flags (default bicubic) ... -src_formatE..V. source format (default yuv420p) -dst_formatE..V. destination format (default yuv420p) -src_range E..V. source is full range (default false) -dst_range E..V. destination is full range (default false) I don't see any constants set in the AVOptions struct. Can you share a command line where you could set this option using a string? I was just going by the help printed above, including the default. If a string is not valid, which values are? The help function fetches the string name for the default value but the user has to input an integer. The pixel formats are declared in an enum in libavutil/pixfmt.h. The integers correspond to their index in that list. That seems very bad in terms of usability. Is there a particular reason why the "-pix_fmt" option can parse these values, but swscaler not? In fact, most (if not all) other options that accept a finite set of arguments don't use numbers in that way, but strings. I can add the integers to the documentation as a lookup table, but it feels weird doing so. where exactly is a end user facing interface using integers for pix_fmt in place of named identifers, can you show an example command line ? I checked again, and when you try this, this is printed: Directly using swscale dimensions/format options is not supported, please use the -s or -pix_fmt options Error parsing option 'src_format' with argument 'yuv420p'. So this should actually be removed from the CLI options entirely, or? (And the documentation.) Strictly speaking, the doc page isn't for CLI use only. A note has been added to indicate which options are API only. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] fftools/ffmpeg: add support for per frame rotation and flip
Please unsubscribe me from this mailing list. It is filling up my inbox. Or
at least switch me to getting a daily digest from the mailing list. The way
it is set up now, I'm getting an email for every post, and my inbox is
cluttered.
On Thu, May 16, 2019 at 12:21 AM Jun Li wrote:
> Fix #6945
> Current implementaion for autorotate works fine for stream
> level rotataion but no support for frame level operation
> and frame flip. This patch is for adding flip support and
> per frame operations.
> ---
> fftools/cmdutils.c | 9 ++---
> fftools/cmdutils.h | 2 +-
> fftools/ffmpeg.c| 21 ++-
> fftools/ffmpeg.h| 2 +
> fftools/ffmpeg_filter.c | 81 ++---
> fftools/ffplay.c| 28 +++---
> 6 files changed, 126 insertions(+), 17 deletions(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 9cfbc45c2b..b8bb904419 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size)
> return array;
> }
>
> -double get_rotation(AVStream *st)
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
> {
> -uint8_t* displaymatrix = av_stream_get_side_data(st,
> -
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
> double theta = 0;
> -if (displaymatrix)
> -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> +
> +if (display_matrix)
> +theta = -av_display_rotation_hflip_get(display_matrix, hflip);
>
> theta -= 360*floor(theta/360 + 0.9/360);
>
> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> index 6e2e0a2acb..dce44ed6e1 100644
> --- a/fftools/cmdutils.h
> +++ b/fftools/cmdutils.h
> @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size);
> char name[128];\
> av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
>
> -double get_rotation(AVStream *st);
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
>
> #endif /* FFTOOLS_CMDUTILS_H */
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 01f04103cf..9ea1aaa930 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2126,6 +2126,24 @@ static int
> ifilter_has_all_input_formats(FilterGraph *fg)
> return 1;
> }
>
> +static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter,
> AVFrame* frame)
> +{
> +int32_t* stream_matrix =
> (int32_t*)av_stream_get_side_data(ifilter->ist->st,
> +
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
> +// if we already have display matrix from stream, use it instead of
> extracting
> +// from frame.
> +if (stream_matrix) {
> +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
> +return 0;
> +}
> +
> +// cleanup the display matrix, may be from last frame
> +memset(ifilter->display_matrix, 0, 4 * 9);
> +av_display_rotation_set(ifilter->display_matrix, 0);
> +
> +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> +}
> +
> static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
> {
> FilterGraph *fg = ifilter->graph;
> @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter *ifilter,
> AVFrame *frame)
> ifilter->channel_layout != frame->channel_layout;
> break;
> case AVMEDIA_TYPE_VIDEO:
> -need_reinit |= ifilter->width != frame->width ||
> +need_reinit |= ifilter_display_matrix_need_from_frame(ifilter,
> frame) ||
> + ifilter->width != frame->width ||
> ifilter->height != frame->height;
> break;
> }
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index eb1eaf6363..8331720663 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -251,6 +251,8 @@ typedef struct InputFilter {
> int channels;
> uint64_t channel_layout;
>
> +int32_t display_matrix[9];
> +
> AVBufferRef *hw_frames_ctx;
>
> int eof;
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 72838de1e2..1894f30561 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg,
> AVFilterInOut *in)
> fg->inputs[fg->nb_inputs - 1]->format = -1;
> fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
> fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in, 1);
> +av_display_rotation_set(fg->inputs[fg->nb_inputs -
> 1]->display_matrix, 0);
>
> fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 *
> sizeof(AVFrame*));
> if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
> @@ -807,22 +808,43 @@ static int configure_input_video_filter(FilterGraph
> *fg, InputFilter *ifilter,
> last_filter = ifilter->filter;
>
> if (ist->autorotate) {
> -double theta = get_rotation(ist->st);
> +int hflip = 0;
> +double theta = get_rotation_hf
Re: [FFmpeg-devel] [PATCH v3 2/2] fftools/ffmpeg: add support for per frame rotation and flip
On 17-05-2019 01:17 PM, Ben Hutchinson wrote: Please unsubscribe me from this mailing list. It is filling up my inbox. Or at least switch me to getting a daily digest from the mailing list. The way it is set up now, I'm getting an email for every post, and my inbox is cluttered. ... ___ 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". See above. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use all Closed Captions side data
On 5/17/19, Mathieu Duponchelle wrote: > There isn't one, as I said the added indentation is because of the new loop! To get this committed to tree you need to comply to review requests. > > On 5/13/19 3:39 PM, Carl Eugen Hoyos wrote: >> Am Mi., 10. Apr. 2019 um 13:26 Uhr schrieb Mathieu Duponchelle >> : >> >>> No problem >> I don't see an updated patch. >> >> Carl Eugen >> ___ >> 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". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add apitch filter
On 5/15/19, Paul B Mahol wrote: > On 5/12/19, Paul B Mahol wrote: >> On 5/12/19, Michael Niedermayer wrote: >>> On Sun, May 12, 2019 at 11:00:51PM +0200, Nicolas George wrote: Marton Balint (12019-05-12): > Yeah, you are right, what I had in mind was this: > > apitch === asetrate,aresample,atempo Exactly. And reciprocally, atempo = apitch+asetrate+aresample. Furthermore, since it works with the spectrum, the filter that does the hard work can probably easily output at any sample rate, at a cost much lower than resampling afterwards. Therefore, it makes most sense to have a single filter with all three parameters (sample rate, speed adjustment and pitch adjustment). >>> >>> and if thats done in our resampler than that can also be combined with >>> changing the channel order, layout, sample type and so on. >>> Iam not sure its a good idea but purely technically it should be more >>> efficient to do it all together. >>> Also swresample already supports an external FFT resampler so it might >>> actually fit in there nicely and it might even allow us to remove an >>> external >>> dependancy without loosing a feature. (assuming the new FFT resampler >>> would be equally good) >>> >>> >> >> To make it work dynamically, filter must resample audio internally. >> > > Can I get testers? > Because lack of testers, I will apply this patch as is. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add apitch filter
Paul B Mahol (12019-05-17): > Because lack of testers, I will apply this patch as is. Absolutely not. The consensus was to have a single filter, and even possibly make it part of lswr. This is what is currently discussed. -- Nicolas George ___ 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] tools/target_dec_fuzzer: Limit error concealment on pixels instead of just frames
This should reduce the amount of timeout issues overall
Fixes: Timeout (34->10sec)
Fixes:
14682/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV2_fuzzer-5728608414334976
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 2a6d525b73..4f51b70b65 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -137,6 +137,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
const uint8_t *last = data;
const uint8_t *end = data + size;
uint32_t it = 0;
+uint64_t ec_pixels = 0;
int (*decode_handler)(AVCodecContext *avctx, AVFrame *picture,
int *got_picture_ptr,
const AVPacket *avpkt) = NULL;
@@ -244,7 +245,8 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
av_frame_unref(frame);
int ret = decode_handler(ctx, frame, &got_frame, &avpkt);
-if (it > 20)
+ec_pixels += ctx->width * ctx->height;
+if (it > 20 || ec_pixels > 4 * ctx->max_pixels)
ctx->error_concealment = 0;
if (ret <= 0 || ret > avpkt.size)
--
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".
[FFmpeg-devel] [PATCH] libavdevice/gdigrab: fix ffmpeg -devices doesn't show gdigrab
From: Jun Zhao
missed the category AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT lead to
ffmpeg -devices doesn't show gdigrab as a input device
FIx #7848
Found-by: dangibson
Signed-off-by: Jun Zhao
---
libavdevice/gdigrab.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index b226bd0..f40 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -647,6 +647,7 @@ static const AVClass gdigrab_class = {
.item_name = av_default_item_name,
.option = options,
.version= LIBAVUTIL_VERSION_INT,
+.category = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
};
/** gdi grabber device demuxer declaration */
--
1.7.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]
On Fri, May 17, 2019 at 9:41 AM Gyan wrote: > Strictly speaking, the doc page isn't for CLI use only. A note has been > added to indicate which options are API only. That definitely clears things up, thanks. But coming back to what you wrote initially: > Sure, if the option name was is_src_range_full. But src_range allows you > to specify a range. So, even though there are only two, better to > mention the allowed values and their meaning. Changed the patch now. Please have a look. Werner 0001-doc-swscaler-explain-values-for-src_range-dst_range.patch Description: Binary data ___ 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]
On 17-05-2019 02:29 PM, Werner Robitza wrote:
On Fri, May 17, 2019 at 9:41 AM Gyan wrote:
Strictly speaking, the doc page isn't for CLI use only. A note has been
added to indicate which options are API only.
That definitely clears things up, thanks.
But coming back to what you wrote initially:
Sure, if the option name was is_src_range_full. But src_range allows you
to specify a range. So, even though there are only two, better to
mention the allowed values and their meaning.
Changed the patch now. Please have a look.
One change, from,
If value is set to @code{1}, enable full range for source. Default
value is @code{0}, which enables limited range.
to
If value is set to @code{1}, indicates source is full range.
Default value is @code{0}, which indicates source as limited range.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat
On Wed, May 15, 2019 at 12:13:07PM -0700, Adam Richter wrote: > On Tue, May 14, 2019 at 6:48 PM myp...@gmail.com wrote: > > > > On Wed, May 15, 2019 at 7:01 AM Hendrik Leppkes wrote: > > > > > > On Tue, May 14, 2019 at 11:25 PM Adam Richter > > > wrote: [...] > > > > > > > > Also after this, I may take a look at adding a branch hint to the > > > > av_assertN > > > > macros if nobody objects. > > > > > > > > > > Please don't, we don't do branch hints anywhere, and this is a bad > > > place to start. > > > If an assert is truely performance sensitive (as in, it makes a > > > measurable difference), it should probably be moved from assert0 to > > > assert1, and as such is only enabled in testing builds. > > > > > If assert0 or assert1 lead to performance drop, we need some profiling > > data, then try to fix it. > > The above comments by Hendrick and you does not identify a cost to > adding a branch hint to assert. There would be a downside in the form of > a few lines of code complexity in libavutil/avassert.h. If that is > your concern, > I guess our disagreement is that I see reducing the cost of assert so that > perhaps CPU usage with and without would be a tiny bit more similar for > reproducing problems and maybe (I'm not saying it's likely) it might tip a > trade-off in favor of keeping an assert enabled in some borderline > circumstance. I'd take that trade (add the branch prediction). > > If you want to educate me on some other reason why I may be wrong, > about adding the branch prediction for assertion checks, I'd been keen > to know, but I realize everyone's time is limited, and if I haven't > convinced you and also created consensus in favor of adding the > branch prediction to assertion checking, then I don't expect to advocate > further on this list for merging such a change into your tree at this time. I think a key question here would be if a speedeffect or code generation improvment can be shown to have actually occured. Instead of assuming that it could. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad 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] Support for Multiview Video Coding (MVC)
On Thu, May 16, 2019, 18:49 qunming peng wrote: > Hi, > May I know if there is a plan to integrate MVC into ffmpeg? > Thanks, > Brook > Hello there, To the best of my knowledge, specific encoders (and hwaccel backends) have support for H.264 MVC encoding, namely VAAPI (using the i965 driver) and the x264 encoder (which requires a separate license, need to confirm if this is the case to date). NVENC, from Maxwell Gen 1 (GM10x series) also exposes support for MVC profiles, and proprietary software such as Cyberlink's Power director can take advantage of this. Whether this is exposed in FFmpeg, through private codec options or global libav options is what I cannot confirm at the present. Will get back to you when I have more info. > ___ 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/2] avcodec/nvenc: add master display and light level sei data for hdr10
From: Limin Wang
---
libavcodec/nvenc.c | 73 +
libavcodec/nvenc.h | 1 +
libavcodec/nvenc_hevc.c | 2 ++
3 files changed, 76 insertions(+)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 77eb9918a4..55547d4246 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -22,6 +22,9 @@
#include "config.h"
#include "nvenc.h"
+#include "cbs_h265.h"
+#include "hevc_sei.h"
+#include "put_bits.h"
#include "libavutil/hwcontext_cuda.h"
#include "libavutil/hwcontext.h"
@@ -30,6 +33,7 @@
#include "libavutil/avassert.h"
#include "libavutil/mem.h"
#include "libavutil/pixdesc.h"
+#include "libavutil/mastering_display_metadata.h"
#include "internal.h"
#define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, dl_fn->cuda_dl, x)
@@ -2110,6 +2114,75 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
}
}
+if (ctx->hdr) {
+AVFrameSideData *sd = av_frame_get_side_data(frame,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+
+if (sd) {
+AVMasteringDisplayMetadata *mdm = (AVMasteringDisplayMetadata
*)sd->data;
+// HEVC uses a g,b,r ordering, which we convert to a more
natural r,g,b
+const int mapping[3] = {2, 0, 1};
+const int chroma_den = 5;
+const int luma_den = 1;
+
+if (mdm->has_primaries && mdm->has_luminance) {
+H265RawSEIMasteringDisplayColourVolume smd;
+
+for (i = 0; i < 3; i++) {
+const int j = mapping[i];
+smd.display_primaries_x[i] = chroma_den *
av_q2d(mdm->display_primaries[j][0]);
+smd.display_primaries_y[i] = chroma_den * av_q2d(
mdm->display_primaries[j][1]);
+}
+
+smd.white_point_x = chroma_den *
av_q2d(mdm->white_point[0]);
+smd.white_point_y = chroma_den *
av_q2d(mdm->white_point[1]);
+smd.max_display_mastering_luminance = luma_den *
av_q2d(mdm->max_luminance);
+smd.min_display_mastering_luminance = luma_den *
av_q2d(mdm->min_luminance);
+
+sei_data[sei_count].payloadSize =
sizeof(H265RawSEIMasteringDisplayColourVolume);
+sei_data[sei_count].payloadType =
HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
+sei_data[sei_count].payload =
av_mallocz(sei_data[sei_count].payloadSize);
+if (sei_data[sei_count].payload) {
+PutBitContext pb;
+
+init_put_bits(&pb, sei_data[sei_count].payload,
sei_data[sei_count].payloadSize);
+for (i = 0; i < 3; i++) {
+put_bits(&pb, 16, smd.display_primaries_x[i]);
+put_bits(&pb, 16, smd.display_primaries_y[i]);
+}
+put_bits(&pb, 16, smd.white_point_x);
+put_bits(&pb, 16, smd.white_point_y);
+put_bits(&pb, 32, smd.max_display_mastering_luminance);
+put_bits(&pb, 32, smd.min_display_mastering_luminance);
+flush_put_bits(&pb);
+
+sei_count ++;
+}
+}
+}
+
+sd = av_frame_get_side_data(frame,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+if (sd) {
+AVContentLightMetadata *clm = (AVContentLightMetadata
*)sd->data;
+H265RawSEIContentLightLevelInfo clli;
+
+clli.max_content_light_level = FFMIN(clm->MaxCLL, 65535);
+clli.max_pic_average_light_level = FFMIN(clm->MaxFALL, 65535);
+
+sei_data[sei_count].payloadSize =
sizeof(H265RawSEIContentLightLevelInfo);
+sei_data[sei_count].payloadType =
HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO;
+sei_data[sei_count].payload =
av_mallocz(sei_data[sei_count].payloadSize);
+if (sei_data[sei_count].payload) {
+PutBitContext pb;
+
+init_put_bits(&pb, sei_data[sei_count].payload,
sei_data[sei_count].payloadSize);
+put_bits(&pb, 16, clli.max_content_light_level);
+put_bits(&pb, 16, clli.max_pic_average_light_level);
+flush_put_bits(&pb);
+
+sei_count ++;
+}
+}
+}
nvenc_codec_specific_pic_params(avctx, &pic_params, sei_data,
sei_count);
} else {
pic_params.encodePicFlags = NV_ENC_PIC_FLAG_EOS;
diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h
index ddd6168409..952e691147 100644
--- a/libavcodec/nvenc.h
+++ b/libavcodec/nvenc.h
@@ -192,6 +192,7 @@ typedef struct NvencContext
int coder;
int b_ref_mode;
int a53_cc;
+int hdr;
} NvencContext;
int
[FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: add more sei data support
From: Limin Wang
---
libavcodec/nvenc.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 3fe64bba8b..77eb9918a4 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1705,7 +1705,8 @@ static int nvenc_upload_frame(AVCodecContext *avctx,
const AVFrame *frame,
static void nvenc_codec_specific_pic_params(AVCodecContext *avctx,
NV_ENC_PIC_PARAMS *params,
-NV_ENC_SEI_PAYLOAD *sei_data)
+NV_ENC_SEI_PAYLOAD *sei_data,
+int sei_count)
{
NvencContext *ctx = avctx->priv_data;
@@ -1715,9 +1716,9 @@ static void
nvenc_codec_specific_pic_params(AVCodecContext *avctx,
ctx->encode_config.encodeCodecConfig.h264Config.sliceMode;
params->codecPicParams.h264PicParams.sliceModeData =
ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData;
-if (sei_data) {
+if (sei_count > 0) {
params->codecPicParams.h264PicParams.seiPayloadArray = sei_data;
-params->codecPicParams.h264PicParams.seiPayloadArrayCnt = 1;
+params->codecPicParams.h264PicParams.seiPayloadArrayCnt =
sei_count;
}
break;
@@ -1726,9 +1727,9 @@ static void
nvenc_codec_specific_pic_params(AVCodecContext *avctx,
ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode;
params->codecPicParams.hevcPicParams.sliceModeData =
ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData;
-if (sei_data) {
+if (sei_count > 0) {
params->codecPicParams.hevcPicParams.seiPayloadArray = sei_data;
-params->codecPicParams.hevcPicParams.seiPayloadArrayCnt = 1;
+params->codecPicParams.hevcPicParams.seiPayloadArrayCnt =
sei_count;
}
break;
@@ -2023,8 +2024,9 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
NVENCSTATUS nv_status;
NvencSurface *tmp_out_surf, *in_surf;
int res, res2;
-NV_ENC_SEI_PAYLOAD *sei_data = NULL;
-size_t sei_size;
+NV_ENC_SEI_PAYLOAD sei_data[8];
+int sei_count = 0;
+int i;
NvencContext *ctx = avctx->priv_data;
NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
@@ -2093,18 +2095,22 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
pic_params.inputTimeStamp = frame->pts;
if (ctx->a53_cc && av_frame_get_side_data(frame,
AV_FRAME_DATA_A53_CC)) {
-if (ff_alloc_a53_sei(frame, sizeof(NV_ENC_SEI_PAYLOAD),
(void**)&sei_data, &sei_size) < 0) {
+void *a53_data = NULL;
+size_t a53_size = 0;
+
+if (ff_alloc_a53_sei(frame, 0, (void**)&a53_data, &a53_size) < 0) {
av_log(ctx, AV_LOG_ERROR, "Not enough memory for closed
captions, skipping\n");
}
-if (sei_data) {
-sei_data->payloadSize = (uint32_t)sei_size;
-sei_data->payloadType = 4;
-sei_data->payload = (uint8_t*)(sei_data + 1);
+if (a53_data) {
+sei_data[sei_count].payloadSize = (uint32_t)a53_size;
+sei_data[sei_count].payloadType = 4;
+sei_data[sei_count].payload = (uint8_t*)a53_data;
+sei_count ++;
}
}
-nvenc_codec_specific_pic_params(avctx, &pic_params, sei_data);
+nvenc_codec_specific_pic_params(avctx, &pic_params, sei_data,
sei_count);
} else {
pic_params.encodePicFlags = NV_ENC_PIC_FLAG_EOS;
ctx->encoder_flushing = 1;
@@ -2115,7 +2121,9 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
return res;
nv_status = p_nvenc->nvEncEncodePicture(ctx->nvencoder, &pic_params);
-av_free(sei_data);
+
+for ( i = 0; i < sei_count; i++)
+av_freep(&sei_data[i].payload);
res = nvenc_pop_context(avctx);
if (res < 0)
--
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] [PATCHv3] VP4 video decoder
On Thu, May 16, 2019 at 08:52:39PM +0200, Reimar Döffinger wrote:
> On Thu, May 16, 2019 at 08:00:55PM +0200, Reimar Döffinger wrote:
> > On Thu, May 16, 2019 at 09:35:00PM +1000, Peter Ross wrote:
> > > +static int read_mb_value(GetBitContext *gb)
> > > +{
> > > +int v = 1;
> > > +int size;
> > > +OPEN_READER(re, gb);
> > > +
> > > +do {
> > > +int bit;
> > > +size = 0;
> > > +
> > > +UPDATE_CACHE(re, gb);
> > > +bit = SHOW_UBITS(re, gb, 1);
> > > +SKIP_BITS(re, gb, 1);
> > > +if (!bit)
> > > +break;
> > > +
> > > +do {
> > > +bit = SHOW_UBITS(re, gb, 1);
> > > +SKIP_BITS(re, gb, 1);
> > > +if (!bit)
> > > +break;
> > > +size++;
> > > +} while (size < 8);
> > > +
> > > +v += 1 << size;
> > > +
> > > +} while (size == 8);
> > > +
> > > +if (size) {
> > > +v += SHOW_UBITS(re, gb, size);
> > > +LAST_SKIP_BITS(re, gb, size);
> > > +}
> > > +
> > > +CLOSE_READER(re, gb);
> > > +return v;
> > > +}
> >
> > I meant that you should do something like
> > (could maybe be made less messy, and not
> > sure it's really necessary to use the macro
> > version, I think it'd prefer the plain
> > show_bits etc)
> >
>
> So many bugs in the previous version, this
> one is at least a bit more correct...
ah, i see what you did there! it works perfectly, just missing
UPDATE_CACHE at the start and in the loop.
test results on i7 decoding 3 minute long 4k video with vp4.
vp4 patch v3:
bench: utime=113.439s stime=0.414s rtime=30.161s
bench: utime=113.406s stime=0.403s rtime=30.123s
bench: utime=113.533s stime=0.310s rtime=30.104s
bench: utime=113.691s stime=0.414s rtime=30.148s
bench: utime=113.414s stime=0.435s rtime=30.102s
bench: utime=113.449s stime=0.370s rtime=30.138s
bench: utime=113.277s stime=0.470s rtime=30.139s
your patch + UPDATE_CACHE:
bench: utime=113.373s stime=0.386s rtime=30.109s
bench: utime=113.284s stime=0.378s rtime=30.122s
bench: utime=113.314s stime=0.414s rtime=30.125s
bench: utime=113.369s stime=0.378s rtime=30.130s
bench: utime=113.309s stime=0.394s rtime=30.108s
bench: utime=113.285s stime=0.435s rtime=30.048s
bench: utime=113.506s stime=0.362s rtime=30.182s
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
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] [PATCHv3] VP4 video decoder
On Thu, May 16, 2019 at 10:49:41AM -0300, James Almer wrote: > On 5/16/2019 8:35 AM, Peter Ross wrote: > > --- > > > > what's changed: > > * reordered AV_CODEC_ID_VP4 > > * minor read_mb_values improvement (reproducible 0.5% speedup) > > * configure/Makefile fix > > * squished data tables to fill 80 columns. > > > > UNCHECKED_BITSTREAM_READER doesn't give any performance improvement > > on my i7, even with unrealisticly huge 4k vp4 video files. > > I hope that was a typo and you tested CACHED_BITSTREAM_READER, not > UNCHECKED_BITSTREAM_READER :p > > In any case, I wouldn't bother. Ricing a VP4 decoder is hardly worth > anyone's time. oops, yes. and i agree. > > @@ -2825,6 +2825,7 @@ vc1image_decoder_select="vc1_decoder" > > vorbis_decoder_select="mdct" > > vorbis_encoder_select="audio_frame_queue mdct" > > vp3_decoder_select="hpeldsp vp3dsp videodsp" > > +vp4_decoder_select="hpeldsp vp3dsp videodsp" > > Theora enables the vp3 decoder instead of only the related modules > because by compiling vp3.c it's already compiling the entirety of the > vp3 decoder, so might as well have it enabled and available. IMO for vp4 > you should do the same. > > Also, big vp4 specific functions and big chunks of code within shared > functions should ideally be wrapped inside CONFIG_VP4_DECODER checks. thanks for spotting these. fixed and fixed. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) 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] libavdevice/gdigrab: fix ffmpeg -devices doesn't show gdigrab
On 5/17/19, Jun Zhao wrote:
> From: Jun Zhao
>
> missed the category AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT lead to
> ffmpeg -devices doesn't show gdigrab as a input device
>
> FIx #7848
>
> Found-by: dangibson
> Signed-off-by: Jun Zhao
> ---
> libavdevice/gdigrab.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
> index b226bd0..f40 100644
> --- a/libavdevice/gdigrab.c
> +++ b/libavdevice/gdigrab.c
> @@ -647,6 +647,7 @@ static const AVClass gdigrab_class = {
> .item_name = av_default_item_name,
> .option = options,
> .version= LIBAVUTIL_VERSION_INT,
> +.category = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
> };
>
> /** gdi grabber device demuxer declaration */
> --
> 1.7.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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add apitch filter
On 5/17/19, Nicolas George wrote: > Paul B Mahol (12019-05-17): >> Because lack of testers, I will apply this patch as is. > > Absolutely not. The consensus was to have a single filter, and even > possibly make it part of lswr. This is what is currently discussed. You are proposing even more absurd things. It can not be part of lswr at all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add apitch filter
On 5/17/19, Paul B Mahol wrote: > On 5/17/19, Nicolas George wrote: >> Paul B Mahol (12019-05-17): >>> Because lack of testers, I will apply this patch as is. >> >> Absolutely not. The consensus was to have a single filter, and even >> possibly make it part of lswr. This is what is currently discussed. > > You are proposing even more absurd things. > > It can not be part of lswr at all. > If you or anyone does not propose some reasonable alternative solution in due time, I gonna apply this patch. ___ 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] [FFMPEG DEVEL] [PATCH v2] fftools/ffprobe: Add S12M Timecode output as side data (such as SEI TC)
Thanks in advance.
---
fftools/ffprobe.c | 8
1 file changed, 8 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index dea489d02e..4763ce6d98 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2199,6 +2199,14 @@ static void show_frame(WriterContext *w, AVFrame *frame,
AVStream *stream,
char tcbuf[AV_TIMECODE_STR_SIZE];
av_timecode_make_mpeg_tc_string(tcbuf, *(int64_t *)(sd->data));
print_str("timecode", tcbuf);
+} else if (sd->type == AV_FRAME_DATA_S12M_TIMECODE && sd->size >=
8) {
+uint32_t *tc = (uint32_t*)sd->data;
+for (int j = 1; j <= tc[0]; j++) {
+char tcbuf[AV_TIMECODE_STR_SIZE];
+av_timecode_make_smpte_tc_string(tcbuf, tc[j], 0);
+print_str("timecode", tcbuf);
+}
+break;
} else if (sd->type == AV_FRAME_DATA_MASTERING_DISPLAY_METADATA) {
AVMasteringDisplayMetadata *metadata =
(AVMasteringDisplayMetadata *)sd->data;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add apitch filter
Paul B Mahol (12019-05-17): > If you or anyone does not propose some reasonable alternative solution > in due time, I gonna apply this patch. As already said: a single filter named atempo with compatibility options, or it is rejected. And see with Michael about lswr. -- Nicolas George 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] avfilter: add apitch filter
On 5/17/19, Nicolas George wrote: > Paul B Mahol (12019-05-17): >> If you or anyone does not propose some reasonable alternative solution >> in due time, I gonna apply this patch. > > As already said: a single filter named atempo with compatibility > options, or it is rejected. Says who? You are last person to be asked about this. > > And see with Michael about lswr. > I already rejected such idea. > -- > Nicolas George > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add apitch filter
Paul B Mahol (12019-05-17): > Says who? You are last person to be asked about this. Another ad-hominem attack. > I already rejected such idea. No, since you did not give any argument. I will not reply again if you continue your rudeness, your ad-hominem attacks or just your lack of arguments. Just revert if you try to go against the policy. -- Nicolas George 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] avfilter: add apitch filter
On 5/17/19, Nicolas George wrote: > Paul B Mahol (12019-05-17): >> Says who? You are last person to be asked about this. > > Another ad-hominem attack. I really stopped counting, how many times you feel "attacked". > >> I already rejected such idea. > > No, since you did not give any argument. There was no valid argument to do it via swr. How you are supposed to dynamically change pitch that way? > > I will not reply again if you continue your rudeness, your ad-hominem > attacks or just your lack of arguments. Just revert if you try to go > against the policy. > I will call ban on your presense in this project. ___ 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]
On Fri, May 17, 2019 at 11:16 AM Gyan wrote:
> One change, from,
>
> If value is set to @code{1}, enable full range for source. Default
> value is @code{0}, which enables limited range.
>
> to
>
> If value is set to @code{1}, indicates source is full range.
> Default value is @code{0}, which indicates source as limited range.
Fixed and wrapped text at 80 chars.
Werner
0001-doc-swscaler-explain-values-for-src_range-dst_range.patch
Description: Binary data
___
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]
On 17-05-2019 08:24 PM, Werner Robitza wrote:
On Fri, May 17, 2019 at 11:16 AM Gyan wrote:
One change, from,
If value is set to @code{1}, enable full range for source. Default
value is @code{0}, which enables limited range.
to
If value is set to @code{1}, indicates source is full range.
Default value is @code{0}, which indicates source as limited range.
Fixed and wrapped text at 80 chars.
Pushed as b99c73abf4b9931d0790cfbcb46aa8b799ac244b
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avformat/vivo: improve probing of some files
On Thu, May 16, 2019 at 11:43:05AM +0200, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavformat/vivo.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) LGTM thx [...] -- 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".
Re: [FFmpeg-devel] [PATCHv3] VP4 video decoder
On Fri, May 17, 2019 at 08:09:45PM +1000, Peter Ross wrote: > ah, i see what you did there! it works perfectly, just missing > UPDATE_CACHE at the start and in the loop. > > test results on i7 decoding 3 minute long 4k video with vp4. Looks fairly close to noise to me, though for me it seemed a bit more obvious how the encoding works from it (which was the primary reason to suggest it). If one really wanted to optimize it for performance the arrangement of the conditions can probably be improved, e.g. the 0x1ff check is now the very first one even though it is the least likely one (but avoids duplicating code or needing crazy goto or loop constructs and thus is more readable), and depending on probabilities doing the range checks in a more tree-like structure might also be better. But as said, optimizing this has probably at most curiosity value :) > vp4 patch v3: > bench: utime=113.439s stime=0.414s rtime=30.161s > bench: utime=113.406s stime=0.403s rtime=30.123s > bench: utime=113.533s stime=0.310s rtime=30.104s > bench: utime=113.691s stime=0.414s rtime=30.148s > bench: utime=113.414s stime=0.435s rtime=30.102s > bench: utime=113.449s stime=0.370s rtime=30.138s > bench: utime=113.277s stime=0.470s rtime=30.139s > > your patch + UPDATE_CACHE: > bench: utime=113.373s stime=0.386s rtime=30.109s > bench: utime=113.284s stime=0.378s rtime=30.122s > bench: utime=113.314s stime=0.414s rtime=30.125s > bench: utime=113.369s stime=0.378s rtime=30.130s > bench: utime=113.309s stime=0.394s rtime=30.108s > bench: utime=113.285s stime=0.435s rtime=30.048s > bench: utime=113.506s stime=0.362s rtime=30.182s ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop
Hi Thomas,
> On May 14, 2019, at 2:54 PM, Thomas Mundt wrote:
>
> Hi Baptiste,
>
> Am Di., 14. Mai 2019 um 18:59 Uhr schrieb Baptiste Coudurier
> mailto:baptiste.coudur...@gmail.com>>:
> ---
> libavformat/Makefile | 2 +-
> libavformat/avc.c| 186 +
> libavformat/avc.h| 15 +++
> libavformat/hevc.c | 36 +---
> libavformat/mxf.h| 1 +
> libavformat/mxfenc.c | 213 ++-
> 6 files changed, 372 insertions(+), 81 deletions(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 99be60d184..df87c54a58 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER) += musx.o
> OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
> OBJS-$(CONFIG_MVI_DEMUXER) += mvi.o
> OBJS-$(CONFIG_MXF_DEMUXER) += mxfdec.o mxf.o
> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
> avc.o
> OBJS-$(CONFIG_MXG_DEMUXER) += mxg.o
> OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
> OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index ec50033a04..a041e84357 100644
> --- a/libavformat/avc.c
> +++ b/libavformat/avc.c
> @@ -21,6 +21,7 @@
>
> #include "libavutil/intreadwrite.h"
> #include "libavcodec/h264.h"
> +#include "libavcodec/get_bits.h"
> #include "avformat.h"
> #include "avio.h"
> #include "avc.h"
> @@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t
> *start,
>
> return start + res;
> }
> +
> +uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
> + uint32_t *dst_len, int header_len)
> +{
> +uint8_t *dst;
> +uint32_t i, len;
> +
> +dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!dst)
> +return NULL;
> +
> +/* NAL unit header */
> +i = len = 0;
> +while (i < header_len && i < src_len)
> +dst[len++] = src[i++];
> +
> +while (i + 2 < src_len)
> +if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
> +dst[len++] = src[i++];
> +dst[len++] = src[i++];
> +i++; // remove emulation_prevention_three_byte
> +} else
> +dst[len++] = src[i++];
> +
> +while (i < src_len)
> +dst[len++] = src[i++];
> +
> +memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
> +*dst_len = len;
> +return dst;
> +}
> +
> +static const AVRational avc_sample_aspect_ratio[17] = {
> +{ 0, 1 },
> +{ 1, 1 },
> +{ 12, 11 },
> +{ 10, 11 },
> +{ 16, 11 },
> +{ 40, 33 },
> +{ 24, 11 },
> +{ 20, 11 },
> +{ 32, 11 },
> +{ 80, 33 },
> +{ 18, 11 },
> +{ 15, 11 },
> +{ 64, 33 },
> +{ 160, 99 },
> +{ 4, 3 },
> +{ 3, 2 },
> +{ 2, 1 },
> +};
> +
> +static inline int get_ue_golomb(GetBitContext *gb) {
> +int i;
> +for (i = 0; i < 32 && !get_bits1(gb); i++)
> +;
> +return get_bitsz(gb, i) + (1 << i) - 1;
> +}
> +
> +static inline int get_se_golomb(GetBitContext *gb) {
> +int v = get_ue_golomb(gb) + 1;
> +int sign = -(v & 1);
> +return ((v >> 1) ^ sign) - sign;
> +}
> +
> +H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
> +{
> +int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
> +int num_ref_frames_in_pic_order_cnt_cycle;
> +int delta_scale, lastScale = 8, nextScale = 8;
> +int sizeOfScalingList;
> +H264SequenceParameterSet *sps = NULL;
> +GetBitContext gb;
> +uint8_t *rbsp_buf;
> +
> +rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, &rbsp_size, 0);
> +if (!rbsp_buf)
> +return NULL;
> +
> +ret = init_get_bits8(&gb, rbsp_buf, rbsp_size);
> +if (ret < 0)
> +goto end;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +goto end;
> +
> +sps->profile_idc = get_bits(&gb, 8);
> +sps->constraint_set_flags |= get_bits1(&gb) << 0; // constraint_set0_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 1; // constraint_set1_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 2; // constraint_set2_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 3; // constraint_set3_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 4; // constraint_set4_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 5; // constraint_set5_flag
> +skip_bits(&gb, 2); // reserved_zero_2bits
> +sps->level_idc = get_bits(&gb, 8);
> +sps->id = get_ue_golomb(&gb);
> +
> +if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
> +sps->profile_idc == 122 || sps->profile_idc == 244 ||
> sps->profile_idc == 44 ||
> +sps->profile_idc == 83 || sps->profile_idc =
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
Dňa št 16. 5. 2019, 12:04 Daniel Kučera napísal(a): > > > Dňa st 15. 5. 2019, 11:14 Daniel Kučera > napísal(a): > >> > >> > Ping. >> > >> > -- >> > >> > S pozdravom / Best regards >> > Daniel Kucera. >> >> Ping. >> >> -- >> >> S pozdravom / Best regards >> Daniel Kucera. >> > > Ping. > Ping. ___ 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] [DECISION] Ban Nicolas George from project
Hi, $subject. He is constantly against my patches, and derailing it with other things to just block them. He is also misguiding other fellow developers with unreasonable and impossible refactoring task, see that frame rotating patch set. libavfilter does not allow dynamic changing of frame parameters. And he know it very well. ___ 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] [DECISION] Ban Nicolas George from project
On 5/17/2019 4:25 PM, Paul B Mahol wrote: > Hi, > > $subject. > > He is constantly against my patches, and derailing it with other things > to just block them. > > He is also misguiding other fellow developers with unreasonable and > impossible refactoring task, see that frame rotating patch set. > > libavfilter does not allow dynamic changing of frame parameters. > And he know it very well. You didn't set a deadline, and even if you had done it, something like this requires at the bare minimum some examples to back your argument about blocking/derailing in the form of links or similar. Also, this requires some discussion first, you know? No one is going to touch such a sudden and extreme call for vote with a ten foot pole otherwise. And I'd very much like a peaceful weekend. Please. ___ 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/2] avcodec/vmnc: Check available space against chunks before reget_buffer()
Fixes: Timeout (16sec -> 60ms)
Fixes:
14673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMNC_fuzzer-5640217517621248
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vmnc.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vmnc.c b/libavcodec/vmnc.c
index 30b1414e49..e273043311 100644
--- a/libavcodec/vmnc.c
+++ b/libavcodec/vmnc.c
@@ -333,11 +333,15 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
uint8_t *outptr;
int dx, dy, w, h, depth, enc, chunks, res, size_left, ret;
+bytestream2_init(gb, buf, buf_size);
+bytestream2_skip(gb, 2);
+chunks = bytestream2_get_be16(gb);
+if (12LL * chunks > bytestream2_get_bytes_left(gb))
+return AVERROR_INVALIDDATA;
+
if ((ret = ff_reget_buffer(avctx, c->pic)) < 0)
return ret;
-bytestream2_init(gb, buf, buf_size);
-
c->pic->key_frame = 0;
c->pic->pict_type = AV_PICTURE_TYPE_P;
@@ -369,8 +373,7 @@ static int decode_frame(AVCodecContext *avctx, void *data,
int *got_frame,
}
}
}
-bytestream2_skip(gb, 2);
-chunks = bytestream2_get_be16(gb);
+
while (chunks--) {
if (bytestream2_get_bytes_left(gb) < 12) {
av_log(avctx, AV_LOG_ERROR, "Premature end of data!\n");
--
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".
[FFmpeg-devel] [PATCH 1/2] avcodec/pafvideo: Clear frame buffer later
This way the clearing can be skipped in case of some errors.
Fixes: Timeout (11sec -> 344ms)
Fixes:
14670/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PAF_VIDEO_fuzzer-5769534503387136
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pafvideo.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pafvideo.c b/libavcodec/pafvideo.c
index 7bfd6815df..323c662c59 100644
--- a/libavcodec/pafvideo.c
+++ b/libavcodec/pafvideo.c
@@ -293,9 +293,6 @@ static int paf_video_decode(AVCodecContext *avctx, void
*data,
return ret;
if (code & 0x20) { // frame is keyframe
-for (i = 0; i < 4; i++)
-memset(c->frame[i], 0, c->frame_size);
-
memset(c->pic->data[1], 0, AVPALETTE_SIZE);
c->current_frame = 0;
c->pic->key_frame = 1;
@@ -332,6 +329,10 @@ static int paf_video_decode(AVCodecContext *avctx, void
*data,
c->pic->palette_has_changed = 1;
}
+if (code & 0x20)
+for (i = 0; i < 4; i++)
+memset(c->frame[i], 0, c->frame_size);
+
switch (code & 0x0F) {
case 0:
/* Block-based motion compensation using 4x4 blocks with either
--
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] [DECISION] Ban Nicolas George from project
Voting is not yet another mobbing tool for when you get tired of other ways. If you wish for an end to that feud, you can ask other developers to try and help, but you've kept this going for years and usually responded somewhere between dismissive and insulting to any such attempts. If you wish to keep the feud going, please deal with the consequences yourself and stop dragging the whole project into your self-created messes. Sorry for the bluntness and my excuses if I ruined the chances for a peaceful weekend. Best regards, Reimar Döffinger. On 17.05.2019, at 21:25, Paul B Mahol wrote: > Hi, > > $subject. > > He is constantly against my patches, and derailing it with other things > to just block them. > > He is also misguiding other fellow developers with unreasonable and > impossible refactoring task, see that frame rotating patch set. > > libavfilter does not allow dynamic changing of frame parameters. > And he know it very well. > ___ > 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] libavdevice/gdigrab: fix ffmpeg -devices doesn't show gdigrab
On Fri, May 17, 2019 at 7:33 PM Paul B Mahol wrote:
>
> On 5/17/19, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > missed the category AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT lead to
> > ffmpeg -devices doesn't show gdigrab as a input device
> >
> > FIx #7848
> >
> > Found-by: dangibson
> > Signed-off-by: Jun Zhao
> > ---
> > libavdevice/gdigrab.c |1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
> > index b226bd0..f40 100644
> > --- a/libavdevice/gdigrab.c
> > +++ b/libavdevice/gdigrab.c
> > @@ -647,6 +647,7 @@ static const AVClass gdigrab_class = {
> > .item_name = av_default_item_name,
> > .option = options,
> > .version= LIBAVUTIL_VERSION_INT,
> > +.category = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
> > };
> >
> > /** gdi grabber device demuxer declaration */
> > --
> > 1.7.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
Pushed， 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".
