[FFmpeg-devel] [PATCH] lavc/cfhd: added interlaced frame decoding
ticket #5522: interlaced frame required horizontal-temporal inverse
transform. though the output is not satisfactory yet.
---
libavcodec/cfhd.c | 102 --
libavcodec/cfhd.h | 3 +-
2 files changed, 85 insertions(+), 20 deletions(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index a064cd1599..b17c7c1dc5 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -50,8 +50,11 @@ enum CFHDParam {
ChannelWidth = 104,
ChannelHeight= 105,
PrescaleShift= 109,
+Progressive = 68,
};
+
+
static av_cold int cfhd_init(AVCodecContext *avctx)
{
CFHDContext *s = avctx->priv_data;
@@ -83,6 +86,7 @@ static void init_frame_defaults(CFHDContext *s)
s->wavelet_depth = 3;
s->pshift= 1;
s->codebook = 0;
+s->progressive = 0;
init_plane_defaults(s);
}
@@ -137,6 +141,28 @@ static inline void filter(int16_t *output, ptrdiff_t
out_stride,
}
}
+static inline void interlaced_vertical_filter(int16_t *output, int16_t *low,
int16_t *high,
+ int width, int linesize, int plane)
+{
+int i;
+int16_t even, odd;
+for (i = 0; i < width; i++) {
+
+
+ even = (*low - *high)/2;
+ odd = (*low + *high)/2;
+
+ if (even > 1023) even = 1023;
+ if (even < 0) even = 0;
+ if (odd > 1023) odd = 1023;
+ if (odd < 0) odd = 0;
+
+ output[i] = even;
+ output[i + linesize] = odd;
+ low++;
+ high++;
+}
+}
static void horiz_filter(int16_t *output, int16_t *low, int16_t *high,
int width)
{
@@ -277,6 +303,9 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
uint16_t data = bytestream2_get_be16(&gb);
if (abs_tag8 >= 0x60 && abs_tag8 <= 0x6f) {
av_log(avctx, AV_LOG_DEBUG, "large len %x\n", ((tagu & 0xff) <<
16) | data);
+} else if (tag == Progressive) {
+av_log(avctx, AV_LOG_DEBUG, "Progressive?%"PRIu16"\n", data);
+s->progressive = data;
} else if (tag == ImageWidth) {
av_log(avctx, AV_LOG_DEBUG, "Width %"PRIu16"\n", data);
s->coded_width = data;
@@ -766,36 +795,71 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
}
av_log(avctx, AV_LOG_DEBUG, "Level 3 plane %i %i %i %i\n", plane,
lowpass_height, lowpass_width, highpass_stride);
-
+if (s->progressive) {
+ low= s->plane[plane].subband[0];
+ high = s->plane[plane].subband[8];
+ output = s->plane[plane].l_h[6];
+ for (i = 0; i < lowpass_width; i++) {
+ vert_filter(output, lowpass_width, low, lowpass_width, high,
highpass_stride, lowpass_height);
+ low++;
+ high++;
+ output++;
+ }
+
+ low= s->plane[plane].subband[7];
+ high = s->plane[plane].subband[9];
+ output = s->plane[plane].l_h[7];
+ for (i = 0; i < lowpass_width; i++) {
+ vert_filter(output, lowpass_width, low, highpass_stride, high,
highpass_stride, lowpass_height);
+ low++;
+ high++;
+ output++;
+ }
+
+ dst = (int16_t *)pic->data[act_plane];
+ low = s->plane[plane].l_h[6];
+ high = s->plane[plane].l_h[7];
+ for (i = 0; i < lowpass_height * 2; i++) {
+ horiz_filter_clip(dst, low, high, lowpass_width, s->bpc);
+ low += lowpass_width;
+ high += lowpass_width;
+ dst += pic->linesize[act_plane] / 2;
+ }
+ }
+ else {
+
+av_log(avctx, AV_LOG_DEBUG, "interlaced frame ? %d",
pic->interlaced_frame);
+pic->interlaced_frame = 1;
low= s->plane[plane].subband[0];
-high = s->plane[plane].subband[8];
+high = s->plane[plane].subband[7];
output = s->plane[plane].l_h[6];
-for (i = 0; i < lowpass_width; i++) {
-vert_filter(output, lowpass_width, low, lowpass_width, high,
highpass_stride, lowpass_height);
-low++;
-high++;
-output++;
+for (i = 0; i < lowpass_height; i++) {
+horiz_filter(output, low, high, lowpass_width);
+low+= lowpass_width;
+high += lowpass_width;
+output += lowpass_width * 2;
}
-low= s->plane[plane].subband[7];
+low= s->plane[plane].subband[8];
high = s->plane[plane].subband[9];
output = s->plane[plane].l_h[7];
-for (i = 0; i < lowpass_width; i++) {
-vert_filter(output, lowpass_width, low, highpass_stride, high,
highpass_stride, lowpass_height);
-low++;
-high++;
-output++;
+for (i = 0; i < lowpass_height; i++) {
+horiz_filter(output, low, high, lowpass_width);
+low
Re: [FFmpeg-devel] [PATCH]avfilter/astreamslect: fixing activating in some cases
2018.03.14. 20:29 keltezéssel, Nicolas George írta: Bodecs Bela (2018-03-14): In case of some content, astreamselect filter remains in non active state. please review this pacth. I am not sure this is the right fix of this. I am not sure either. framesync was not designed for audio. I would like to investigate: can you share the failing case? Regards, ffmpeg -loglevel info -y \ -re -i a.mp4 \ -re -i b.mp4 \ -filter_complex "[0:a][1:a] astreamselect=inputs=2:map=1 [out_a]" \ -map "[out_a]" -vn \ -f framemd5 - a.mp4 and b.mp4 are available on these direct links: http://download.songo.hu/a.mp4 http://download.songo.hu/b.mp4 (they are 500k each) with my patch it works good. bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/cfhd: added interlaced frame decoding
2018-03-17 10:42 GMT+01:00, Gagandeep Singh :
> ticket #5522: interlaced frame required horizontal-temporal inverse
> transform. though the output is not satisfactory yet.
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index a064cd1599..b17c7c1dc5 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -50,8 +50,11 @@ enum CFHDParam {
> ChannelWidth = 104,
> ChannelHeight= 105,
> PrescaleShift= 109,
> +Progressive = 68,
I suspect this can be ordered better.
> };
>
> +
> +
Please do not add random cosmetic changes to your patch.
[...]
> +static inline void interlaced_vertical_filter(int16_t *output, int16_t
> *low, int16_t *high,
> + int width, int linesize, int plane)
> +{
> +int i;
> +int16_t even, odd;
Could the code be simplified by using an unsigned type?
Why not a standard type?
> +for (i = 0; i < width; i++) {
> +
> +
Maybe you disagree, but these empty lines make
reading the code more difficult imo.
> + even = (*low - *high)/2;
> + odd = (*low + *high)/2;
> +
> + if (even > 1023) even = 1023;
> + if (even < 0) even = 0;
> + if (odd > 1023) odd = 1023;
> + if (odd < 0) odd = 0;
FFMIN / FFMAX
[...]
> + }
> + else {
Please merge these lines.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] area changed:in cfhd height initialization was buggy for chroma plane
2018-03-17 7:05 GMT+01:00, Gagandeep Singh : > Thanks, sure will take care next time :) Next task for you is to find out what "top-posting" means and avoid it here;-) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter
2018-03-17 6:43 GMT+01:00, dylanf...@gmail.com : > From: drfer3 > --- /dev/null > +++ b/libavfilter/opencl/avgblur.cl > @@ -0,0 +1,60 @@ > +/* > + * Author: Dylan Fernando * Copyright (c) 2018 Dylan Fernando Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavu/hwcontext_vaapi: Only compile vaapi_unmap_to_drm if it will be used
Hi!
Attached patch is supposed to silence a warning on some systems (seen
on Debian logs).
Please test and review, Carl Eugen
From 841d9ed2db4f3e071ecc681e4f50ff61df2ea358 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 17 Mar 2018 12:42:07 +0100
Subject: [PATCH] lavu/hwcontext_vaapi: Only compile vaapi_unmap_to_drm if it
will be used.
Fixes a warning:
libavutil/hwcontext_vaapi.c:1064:13: warning: 'vaapi_unmap_to_drm' defined but not used
---
libavutil/hwcontext_vaapi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index af9a136..6cc641a 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1073,6 +1073,7 @@ static int vaapi_map_from_drm(AVHWFramesContext *src_fc, AVFrame *dst,
return 0;
}
+#if VA_CHECK_VERSION(1, 1, 0)
static void vaapi_unmap_to_drm(AVHWFramesContext *dst_fc,
HWMapDescriptor *hwmap)
{
@@ -1088,7 +1089,6 @@ static void vaapi_unmap_to_drm(AVHWFramesContext *dst_fc,
static int vaapi_map_to_drm(AVHWFramesContext *hwfc, AVFrame *dst,
const AVFrame *src, int flags)
{
-#if VA_CHECK_VERSION(1, 1, 0)
AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx;
VASurfaceID surface_id;
VAStatus vas;
@@ -1182,7 +1182,7 @@ static int vaapi_map_from(AVHWFramesContext *hwfc, AVFrame *dst,
const AVFrame *src, int flags)
{
switch (dst->format) {
-#if CONFIG_LIBDRM
+#if CONFIG_LIBDRM && VA_CHECK_VERSION(1, 1, 0)
case AV_PIX_FMT_DRM_PRIME:
return vaapi_map_to_drm(hwfc, dst, src, flags);
#endif
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avdevice/decklink: fix leak when listing devices and there is no memory
Fixes Coverity CID 1419523.
Signed-off-by: Marton Balint
---
libavdevice/decklink_common.cpp | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index da414ed5f8..b889033cf8 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -322,21 +322,14 @@ int ff_decklink_list_devices(AVFormatContext *avctx,
ret = AVERROR(ENOMEM);
goto next;
}
-new_device->device_name = av_strdup(displayName);
-if (!new_device->device_name) {
-ret = AVERROR(ENOMEM);
-goto next;
-}
+new_device->device_name = av_strdup(displayName);
new_device->device_description = av_strdup(displayName);
-if (!new_device->device_description) {
-av_freep(&new_device->device_name);
-ret = AVERROR(ENOMEM);
-goto next;
-}
-if ((ret = av_dynarray_add_nofree(&device_list->devices,
- &device_list->nb_devices,
new_device)) < 0) {
+if (!new_device->device_name ||
+!new_device->device_description ||
+av_dynarray_add_nofree(&device_list->devices,
&device_list->nb_devices, new_device) < 0) {
+ret = AVERROR(ENOMEM);
av_freep(&new_device->device_name);
av_freep(&new_device->device_description);
av_freep(&new_device);
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add to changelog
2018-03-17 3:26 GMT+01:00, Courtland Idstrom : > --- > Changelog | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Changelog b/Changelog > index 7969b414c4..32a93d916a 100644 > --- a/Changelog > +++ b/Changelog > @@ -47,7 +47,7 @@ version : > - native SBC encoder and decoder > - drmeter audio filter > - hapqa_extract bitstream filter > - > +- movenc option to write track title metadata Does not need a Changelog entry, should be part of the original commit and please leave the empty line. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] Add option -movflags write_track_title which will write track title metadata. This is useful in conjunction with the metadata flag to specify track title, especially for
2018-03-17 3:26 GMT+01:00, Courtland Idstrom : > Example: > ffmpeg -i in.mov -movflags write_track_title -metadata:s:a:0 > title="Eng-FullMix" Is this defined by the QuickTime specification? The commit message should be split so the first line is <80 chars. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: add channel label support
2018-03-17 3:29 GMT+01:00, Courtland Idstrom : > Adds the ability to support writing channel labels to mov files if the > layout_tag fails, instead of printing a warning and skipping the tag. This > fixes channels such as DL/DR, which will now write to LeftTotal/RightTotal Is this correct? > instead of omitting the channel tag. > --- > Changelog | 1 + > libavformat/mov_chan.c | 20 > libavformat/mov_chan.h | 8 > libavformat/movenc.c | 38 +++--- > 4 files changed, 60 insertions(+), 7 deletions(-) > > diff --git a/Changelog b/Changelog > index 32a93d916a..d9b46b6d78 100644 > --- a/Changelog > +++ b/Changelog > @@ -48,6 +48,7 @@ version : > - drmeter audio filter > - hapqa_extract bitstream filter > - movenc option to write track title metadata > +- mov: write channel labels if channel layout is not found No Changelog entry needed. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] MOV: center channel 'chan' metadata
2018-03-17 3:33 GMT+01:00, Courtland Idstrom : > Hi - > > I'm working with a post-production workflow to mux 5.1 wav audio into a mov > file (each channel specified as a separate track), with correct channel > assignments written as metadata. I'm able to get everything except for the > Center channel to appear correctly when viewed in Quicktime, however the > Center channel shows up as 'mono'. > > I'm using a command like this (other channels omitted for the sake of > brevity): > > ffmpeg -i input.mov \ > -i audio.wav \ > -filter_complex "[1:0]pan=FC|c0=c0[FC]" \ > -map 0:v \ > -map "[FC]" \ > -c:v copy \ > -c:a pcm_s24le \ > output.mov > > This ends up writing a 'chan' tag that indicates Mono content > (MOV_CH_LAYOUT_MONO). If I use a different channel, such as "FL", it writes > a value that Quicktime understands (layout=MOV_CH_LAYOUT_USE_BITMAP > bitmap=0). After some tracing, it appears that this configuration comes > from the layout defined in mov_ch_layout_map_1ch for a single center > channel. This seems like intended functionality and not a bug, but > unfortunately doesn't solve my issue. You could still send a patch that changes this mapping to get some feedback. (I am not a fan but if there is no other simple solution...) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V3 05/11] lavc/extract_extradata_bsf: support dump options.
On 3/14/2018 2:42 AM, Jun Zhao wrote:
>
> 0005-lavc-extract_extradata_bsf-support-dump-options.patch
>
>
> From 3d49b455b8bea2ee311b011fd9078e180c7bdf9a Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Thu, 8 Mar 2018 14:05:53 +0800
> Subject: [PATCH V3 05/11] lavc/extract_extradata_bsf: support dump options.
>
> support dump bit stream filter options
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/extract_extradata_bsf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/extract_extradata_bsf.c
> b/libavcodec/extract_extradata_bsf.c
> index 1c386becd7..007a6a71f5 100644
> --- a/libavcodec/extract_extradata_bsf.c
> +++ b/libavcodec/extract_extradata_bsf.c
> @@ -322,9 +322,10 @@ static const enum AVCodecID codec_ids[] = {
> };
>
> #define OFFSET(x) offsetof(ExtractExtradataContext, x)
> +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
> static const AVOption options[] = {
> { "remove", "remove the extradata from the bitstream", OFFSET(remove),
> AV_OPT_TYPE_INT,
> -{ .i64 = 0 }, 0, 1 },
> +{ .i64 = 0 }, 0, 1 , FLAGS},
> { NULL },
> };
Applied, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FIX: HLS Discontinuity / Non-Monotonous DTS
On Fri, 16 Mar 2018 15:51:26 -0400 Joe Koberg wrote: > I'm saying I don't think it needs it - MPEGTS does seem to handle the > discontinuous input fine if I just concatenate it. > > MPEG TS packets themselves do have a discontinuity flag in the > adaptation field, but again it looks like it might be working as-is > without explicit notification of them. (and probably should) > > The question remains: what is missing to allow the HLS format to > behave as MPEG-TS does right now? First off, from hearing past rants from some people trying to use the ffmpeg mpegts demuxer, it doesn't seem to handle these things fully correctly. Second, I'm talking about libavformat as a library, not whatever "apparently working" hacks ffmpeg.c applies on top of it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add a dca_core bitstream filter test
On 3/17/18, James Almer wrote: > Signed-off-by: James Almer > --- > tests/fate/dca.mak | 5 + > 1 file changed, 5 insertions(+) > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add a dca_core bitstream filter test
On 3/17/2018 12:31 PM, Paul B Mahol wrote: > On 3/17/18, James Almer wrote: >> Signed-off-by: James Almer >> --- >> tests/fate/dca.mak | 5 + >> 1 file changed, 5 insertions(+) >> > > lgtm Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/hap : add test for hap encoding
> > In that case we can let the test using "none" compression (bypass the > snappy part) > and remove only snappy1 and snappy16 test > Like in patch in attach. > > Pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add to changelog
Ok, thank you for the feedback, I'll do this in the future. Still getting the hang of submitting patches this way. Should I resubmit this patch (just part 1), and if I do so, what would be the best way to indicate on the mailing list that I'm submitting a new patch to replace the one(s) here? Thanks -Courtland On Sat, Mar 17, 2018 at 6:22 AM, Carl Eugen Hoyos wrote: > 2018-03-17 3:26 GMT+01:00, Courtland Idstrom : > > --- > > Changelog | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Changelog b/Changelog > > index 7969b414c4..32a93d916a 100644 > > --- a/Changelog > > +++ b/Changelog > > @@ -47,7 +47,7 @@ version : > > - native SBC encoder and decoder > > - drmeter audio filter > > - hapqa_extract bitstream filter > > - > > +- movenc option to write track title metadata > > Does not need a Changelog entry, should be part > of the original commit and please leave the empty line. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] fate/hapqa_extract : add test for hapqa_extract bsf
Hello, Patch in attach add test for the bsf filter test extract color and alpha with the three main kind of hap frame : - no snappy compression - snappy compression and one chunk - snappy compression and several chunks (16 here) like the bsf filter need to be used with vtag and encoder edition also test the information of the target mov for color and alpha Tested on Mac os 10.12 on x86_64 and x86_32 Martin 0001-fate-hapqa_extract-add-test-for-hapqa_extract-bsf.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] fate/vf_premultiply : add test for rgba inplace
Hello, Patch in attach add test for premultiply filter in inplace mode (use the alpha channel of the src) for 8 bits RGBA input. tested on X86_64 and x86_32 can be test with : make fate-filter-premultiply-rgba-8 SAMPLES=fate-suite Martin 0002-fate-vf_premultiply-add-test-for-rgba-8-bits-inplace.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avfilter/x86/vf_blend : add SIMD for more 16 bit blending mode
Hello Patch in attach add SIMD for 16 bit version of grainextract grainmerge average extremity negation 003 : modify DIFFERENCE macro to reduce line duplication 004 : add SIMD for grainextract, grainmerge, average, extremity, negation 005 : add checkasm test for grainextract, grainmerge, average, extremity, negation Checkasm result : grainextract_16_c: 11639.2 grainextract_16_sse4: 1047.2 grainextract_16_avx2: 546.4 grainmerge_16_c: 11719.9 grainmerge_16_sse4: 1045.7 grainmerge_16_avx2: 548.7 average_16_c: 7062.4 average_16_sse2: 479.6 average_16_avx2: 285.9 extremity_16_c: 8678.4 extremity_16_sse4: 1142.6 extremity_16_avx2: 536.4 negation_16_c: 8731.4 negation_16_sse4: 1280.4 negation_16_avx2: 587.6 Martin 0003-avfilter-x86-vf_blend-reorganize-DIFFERENCE-macro-to.patch Description: Binary data 0004-avfilter-x86-vf_blend-add-SIMD-for-16-bit-version-of.patch Description: Binary data 0005-checkasm-vf_blend-add-test-for-16-bit-version-of.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] Add option -movflags write_track_title which will write track title metadata. This is useful in conjunction with the metadata flag to specify track title, especially for
Hi -
Thanks for the feedback here. I'll fix that commit message. I believe this
is the most relevant reference material regarding the userdata ('udta') tag
for Quicktime:
https://developer.apple.com/library/content/documentation/QuickTime/Reference/QTRef_AtomsResources/Content/QTRef_AtomsResources4.html#//apple_ref/doc/uid/TP40004285-DontLinkChapterID_1--udta-
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-63839
From my reading of this, the 'udta' atom can appear as a child of a 'trak'
atom, and can have an optional child 'name', which is how this title is
being encoded. I've also verified that this is the method by which
Quicktime will encode titles if you set them per track using their user
interface.
Thanks,
-Courtland
On Sat, Mar 17, 2018 at 6:23 AM, Carl Eugen Hoyos
wrote:
> 2018-03-17 3:26 GMT+01:00, Courtland Idstrom :
> > Example:
> > ffmpeg -i in.mov -movflags write_track_title -metadata:s:a:0
> > title="Eng-FullMix"
>
> Is this defined by the QuickTime specification?
>
> The commit message should be split so the first line
> is <80 chars.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/hapqa_extract : add test for hapqa_extract bsf
On 3/17/2018 2:54 PM, Martin Vignali wrote: > Hello, > > Patch in attach add test for the bsf filter > > test extract color and alpha > with the three main kind of hap frame : > - no snappy compression > - snappy compression and one chunk > - snappy compression and several chunks (16 here) > > like the bsf filter need to be used with vtag and encoder edition > also test the information of the target mov for color and alpha > > > Tested on Mac os 10.12 on x86_64 and x86_32 > > > Martin > From fbcb71c562b893650f58730f774f17db5d082dd3 Mon Sep 17 00:00:00 2001 > From: Martin Vignali > Date: Sat, 17 Mar 2018 18:50:17 +0100 > Subject: [PATCH] fate/hapqa_extract : add test for hapqa_extract bsf > > test extract color and alpha > with the three main kind of hap frame : > - no snappy compression > - snappy compression and one chunk > - snappy compression and several chunks (16 here) > > like the bsf filter need to be used with vtag and encoder edition > also test the information of the target mov for color and alpha > --- > tests/fate/hap.mak | 43 + > .../hapqa-extract-nosnappy-to-hapalphaonly-mov | 73 > ++ > tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov | 73 > ++ > .../ref/fate/hapqa-extract-snappy1-to-hapalphaonly | 10 +++ > tests/ref/fate/hapqa-extract-snappy1-to-hapq | 10 +++ > .../fate/hapqa-extract-snappy16-to-hapalphaonly| 10 +++ > tests/ref/fate/hapqa-extract-snappy16-to-hapq | 10 +++ > 7 files changed, 229 insertions(+) > create mode 100644 tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov > create mode 100644 tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov > create mode 100644 tests/ref/fate/hapqa-extract-snappy1-to-hapalphaonly > create mode 100644 tests/ref/fate/hapqa-extract-snappy1-to-hapq > create mode 100644 tests/ref/fate/hapqa-extract-snappy16-to-hapalphaonly > create mode 100644 tests/ref/fate/hapqa-extract-snappy16-to-hapq > > diff --git a/tests/fate/hap.mak b/tests/fate/hap.mak > index 51673366f2..cd2838c7ce 100644 > --- a/tests/fate/hap.mak > +++ b/tests/fate/hap.mak > @@ -29,6 +29,49 @@ FATE_SAMPLES_AVCONV-$(call DEMDEC, MOV, HAP) += $(FATE_HAP) > fate-hap: $(FATE_HAP) > > > +#Test bsf conversion > +FATE_HAPQA_EXTRACT_BSF += fate-hapqa-extract-snappy1-to-hapq > +fate-hapqa-extract-snappy1-to-hapq: CMD = framemd5 -i > $(TARGET_SAMPLES)/hap/HAPQA_Snappy_1chunk_127x1.mov -c copy -bsf:v > hapqa_extract=texture=color -tag:v HapY -metadata:s:v:0 encoder="HAPQ" > + > +FATE_HAPQA_EXTRACT_BSF += fate-hapqa-extract-snappy16-to-hapq > +fate-hapqa-extract-snappy16-to-hapq: CMD = framemd5 -i > $(TARGET_SAMPLES)/hap/HAPQA_Snappy_16chunk_127x1.mov -c copy -bsf:v > hapqa_extract=texture=color -tag:v HapY -metadata:s:v:0 encoder="HAPQ" > + > +FATE_HAPQA_EXTRACT_BSF += fate-hapqa-extract-snappy1-to-hapalphaonly > +fate-hapqa-extract-snappy1-to-hapalphaonly: CMD = framemd5 -i > $(TARGET_SAMPLES)/hap/HAPQA_Snappy_1chunk_127x1.mov -c copy -bsf:v > hapqa_extract=texture=alpha -tag:v HapA -metadata:s:v:0 encoder="HAPAlphaOnly" > + > +FATE_HAPQA_EXTRACT_BSF += fate-hapqa-extract-snappy16-to-hapalphaonly > +fate-hapqa-extract-snappy16-to-hapalphaonly: CMD = framemd5 -i > $(TARGET_SAMPLES)/hap/HAPQA_Snappy_16chunk_127x1.mov -c copy -bsf:v > hapqa_extract=texture=alpha -tag:v HapA -metadata:s:v:0 encoder="HAPAlphaOnly" > + framecrc instead of framemd5 in all the above. It's faster. > + > +#Test bsf conversion and mov > +tests/data/hapq_nosnappy.mov: TAG = GEN > +tests/data/hapq_nosnappy.mov: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data > + $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \ > + -i $(TARGET_SAMPLES)/hap/HAPQA_NoSnappy_127x1.mov -c copy -bsf:v > hapqa_extract=texture=color \ -c:v copy Also add -nostdin > +-tag:v HapY -metadata:s:v:0 encoder="HAPQ" $(TARGET_PATH)/$@ -y > 2>/dev/null > + > +tests/data/hapalphaonly_nosnappy.mov: TAG = GEN > +tests/data/hapalphaonly_nosnappy.mov: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data > + $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \ > + -i $(TARGET_SAMPLES)/hap/HAPQA_NoSnappy_127x1.mov -c copy -bsf:v > hapqa_extract=texture=alpha \ > +-tag:v HapA -metadata:s:v:0 encoder="HAPAlpha Only" > $(TARGET_PATH)/$@ -y 2>/dev/null Same. > + > + > +FATE_HAPQA_EXTRACT_BSF_FFPROBE += fate-hapqa-extract-nosnappy-to-hapq-mov > +fate-hapqa-extract-nosnappy-to-hapq-mov: tests/data/hapq_nosnappy.mov > +fate-hapqa-extract-nosnappy-to-hapq-mov: CMD = run > ffprobe$(PROGSSUF)$(EXESUF) -show_packets -show_data_hash md5 -show_streams > -select_streams v -v 0 $(TARGET_PATH)/tests/data/hapq_nosnappy.mov > + > +FATE_HAPQA_EXTRACT_BSF_FFPROBE += > fate-hapqa-extract-nosnappy-to-hapalphaonly-mov > +fate-hapqa-extract-nosnappy-to-hapalphaonly-mov: > tests/data/hapalphaonly_nosnappy.mov > +fate-hapqa-extract-nosnappy-to-hapalphaonly-mov: CMD = run > ffprobe$(PROGSSUF)$(EXESUF) -show_packets -show_data_hash md5 -show_streams
Re: [FFmpeg-devel] [PATCH 1/2] Add option -movflags write_track_title which will write track title metadata. This is useful in conjunction with the metadata flag to specify track title, especially for
2018-03-17 19:57 GMT+01:00, Courtland Idstrom :
> Hi -
>
> Thanks for the feedback here. I'll fix that commit message. I believe this
> is the most relevant reference material regarding the userdata ('udta') tag
> for Quicktime:
>
> https://developer.apple.com/library/content/documentation/QuickTime/Reference/QTRef_AtomsResources/Content/QTRef_AtomsResources4.html#//apple_ref/doc/uid/TP40004285-DontLinkChapterID_1--udta-
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-63839
>
> From my reading of this, the 'udta' atom can appear as a child of a 'trak'
> atom, and can have an optional child 'name', which is how this title is
> being encoded. I've also verified that this is the method by which
> Quicktime will encode titles if you set them per track using their user
> interface.
Then why is it optional?
Please do not top-post here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] Add option -movflags write_track_title which will write track title metadata. This is useful in conjunction with the metadata flag to specify track title, especially for
> > > From my reading of this, the 'udta' atom can appear as a child of a > 'trak' > > atom, and can have an optional child 'name', > > Then why is it optional? > I've made this an optional movflag in attempt to be extra careful. I'm new to this code-base and am err-ing on the side of caution. I'd be more than happy to make it non-optional (perhaps by adding mode & MODE_MOV to the conditional), but I felt more comfortable suggesting this patch as functionality that would only take effect if you opted into it. Please advise. > Please do not top-post here, Carl Eugen Apologies! Hopefully this reply is better (using gmail). Thanks for the feedback! -Courtland ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: add channel label support
> > > fixes channels such as DL/DR, which will now write to > LeftTotal/RightTotal > Is this correct? To the best of my understanding, this is correct; however, I'm by no means an expert on this subject, so I'd love to know if I'm wrong here. The flip-side for reading MOVs is already implemented in ffmpeg (ffprobe will report LeftTotal, RightTotal mapping to DL/DR, see mov_get_channel_label in mov_chan.c). Thanks -Courtland ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input
Hello, Patch in attach change premultiply/unpremultiply filter for RGB input to process it at full range Avoid very strange result in unpremultiply mode To test : ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf unpremultiply=inplace=1 resStraight.png -y ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf format=gbrap16,unpremultiply=inplace=1 resStraight16.png -y Martin 0006-avfilter-vf_premultiply-use-full-range-for-RGB-input.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/vf_premultiply : add test for rgba inplace
2018-03-17 19:17 GMT+01:00 Martin Vignali : > Hello, > > Patch in attach add test for premultiply filter in inplace mode (use the > alpha channel of the src) > for 8 bits RGBA input. > > tested on X86_64 and x86_32 > > can be test with : > make fate-filter-premultiply-rgba-8 SAMPLES=fate-suite > > > Patch dropped I will send a new patch later, to test premultiply and unpremultiply, with more pix_fmt Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input
On 3/17/18, Martin Vignali wrote: > Hello, > > Patch in attach change premultiply/unpremultiply filter for RGB input > to process it at full range > > Avoid very strange result in unpremultiply mode > > To test : > ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf > unpremultiply=inplace=1 resStraight.png -y > > ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf > format=gbrap16,unpremultiply=inplace=1 resStraight16.png -y > > Martin > So you are basically removing support for limited RGB? Those checks are there for the reason, fix your samples. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/hapqa_extract : add test for hapqa_extract bsf
Thanks for the comments, New patch in attach Martin 0001-fate-hapqa_extract-add-test-for-hapqa_extract-bsf.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input
> > Those checks are there for the reason, fix your samples. > Same wrong output if i convert the sample to png, and run unpremultiply filter. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input
On 3/17/18, Martin Vignali wrote: >> >> Those checks are there for the reason, fix your samples. >> > > Same wrong output if i convert the sample to png, and run unpremultiply > filter. Two wrongs does not make something bad suddenly good. Obviously for whatever reason files are tagged as limited, when in fact they are full range. I couldn't find source of this bug. But your patch is wrong, as it ignores color_range if it is set to limited, even if such files are useless. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input
> > Obviously for whatever reason files are tagged as limited, when in fact > they are full range. > > I couldn't find source of this bug. But your patch is wrong, as it ignores > color_range if it is set to limited, even if such files are useless. > I think there is two problem here 1 - Frame tagged as limited instead of full 2 - Wrong calculation for rgb in unpremultiply offset Patch in attach, try to fix the second problem changing unpremultiply_offset, to avoid very wrong output with rgb input (8 bits or 16 bits) Not sure it's the best way to fix that. Martin 0002-avfilter-vf_premultiply-fix-unpremultiply_offset-for.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input
On 3/17/18, Martin Vignali wrote: >> >> Obviously for whatever reason files are tagged as limited, when in fact >> they are full range. >> >> I couldn't find source of this bug. But your patch is wrong, as it >> ignores >> color_range if it is set to limited, even if such files are useless. >> > > > I think there is two problem here > 1 - Frame tagged as limited instead of full > 2 - Wrong calculation for rgb in unpremultiply offset > > Patch in attach, try to fix the second problem > changing unpremultiply_offset, to avoid very wrong output with rgb input (8 > bits or 16 bits) > Not sure it's the best way to fix that. Patch looks ok. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [CLT2018] FFmpeg at Chemnitzer Linux-Tage
On 2018-03-15 17:38 +0100, Paul B Mahol wrote: > On 3/13/18, Thilo Borgmann wrote: > > Am 13.03.18 um 19:52 schrieb Paul B Mahol: > >> On 3/13/18, Thilo Borgmann wrote: > >>> Hi, > >>> > once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany! > This "Chemnitzer Linux Tage" will take place on 10th and 11th of March. > You can find more details on their homepage: > > https://chemnitzer.linux-tage.de/2018/en/ > > Thus once again, we will man a booth with our staff and are happily > waiting for > our users to get in touch with us! If you're a developer and want to > help > us or > just want to visit and check in at our booth, please let us know. > >>> > >>> we've returned from the CLT. This year has been the 20th anniversary of > >>> the > >>> CLT - so they'd put some additional effort into it to make it even a > >>> better > >>> pleasure for all the exhibitors. Most notably in terms of an updated > >>> Saturday dinner :) > >>> > >>> We presented our usual demo using motion vector overlay to attract people > >>> and Thomas and Alexander created a very nice new demo for visualization > >>> filters, command-line expressions and video output, randomly altered. We > >>> again had a lot of users coming by and Gerion also gave a workshop on > >>> command-line based filtering. > >> > >> Which filter where used? > > > > Alexander knows about the complete list, maybe he can answer to that in > > particular. > > Where is he at all? I'm here :) Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [CLT2018] FFmpeg at Chemnitzer Linux-Tage
On 3/17/18, Alexander Strasser wrote: > On 2018-03-15 17:38 +0100, Paul B Mahol wrote: >> On 3/13/18, Thilo Borgmann wrote: >> > Am 13.03.18 um 19:52 schrieb Paul B Mahol: >> >> On 3/13/18, Thilo Borgmann wrote: >> >>> Hi, >> >>> >> once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, >> Germany! >> This "Chemnitzer Linux Tage" will take place on 10th and 11th of >> March. >> You can find more details on their homepage: >> >> https://chemnitzer.linux-tage.de/2018/en/ >> >> Thus once again, we will man a booth with our staff and are happily >> waiting for >> our users to get in touch with us! If you're a developer and want to >> help >> us or >> just want to visit and check in at our booth, please let us know. >> >>> >> >>> we've returned from the CLT. This year has been the 20th anniversary >> >>> of >> >>> the >> >>> CLT - so they'd put some additional effort into it to make it even a >> >>> better >> >>> pleasure for all the exhibitors. Most notably in terms of an updated >> >>> Saturday dinner :) >> >>> >> >>> We presented our usual demo using motion vector overlay to attract >> >>> people >> >>> and Thomas and Alexander created a very nice new demo for >> >>> visualization >> >>> filters, command-line expressions and video output, randomly altered. >> >>> We >> >>> again had a lot of users coming by and Gerion also gave a workshop on >> >>> command-line based filtering. >> >> >> >> Which filter where used? >> > >> > Alexander knows about the complete list, maybe he can answer to that in >> > particular. >> >> Where is he at all? > > I'm here :) Then please answer what was used to promote our filters? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/hapqa_extract : add test for hapqa_extract bsf
On 3/17/2018 5:10 PM, Martin Vignali wrote: > Thanks for the comments, > > New patch in attach > > Martin Should be ok. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API
On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > This is a proof of concept for a dynamic size buffer pool API. > > For the purpose of easy testing and reviewing I replaced the current > linked list used to keep a pool of fixed size buffers with the tree > based pool that will be used to keep a pool of varying size buffers, > instead of adding a new set of functions exclusively for the new API. > The final committed work doesn't necessarely have to do the above, as > there's no real benefit using a tree when you only need a fixed size > buffer pool, other than simplying things. > > I'm open to suggestions about how to introduce this. Completely > separate set of functions and struct names? Sharing the struct and > init/uninit functions and only adding a new get() one like in this > patch? > Any preferences with function/struct naming, for that matter? > > libavutil/buffer.c | 98 > - > libavutil/buffer.h | 2 + > libavutil/buffer_internal.h | 6 ++- > 3 files changed, 85 insertions(+), 21 deletions(-) not sure its not intended but this causes differences in error concealment on many files an example would be something like this: ffmpeg -threads 1 -i 1069/green-block-artifacts-from-canon-100-hs.MOV test.avi [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API
On 3/17/2018 8:48 PM, Michael Niedermayer wrote: > On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> This is a proof of concept for a dynamic size buffer pool API. >> >> For the purpose of easy testing and reviewing I replaced the current >> linked list used to keep a pool of fixed size buffers with the tree >> based pool that will be used to keep a pool of varying size buffers, >> instead of adding a new set of functions exclusively for the new API. >> The final committed work doesn't necessarely have to do the above, as >> there's no real benefit using a tree when you only need a fixed size >> buffer pool, other than simplying things. >> >> I'm open to suggestions about how to introduce this. Completely >> separate set of functions and struct names? Sharing the struct and >> init/uninit functions and only adding a new get() one like in this >> patch? >> Any preferences with function/struct naming, for that matter? >> >> libavutil/buffer.c | 98 >> - >> libavutil/buffer.h | 2 + >> libavutil/buffer_internal.h | 6 ++- >> 3 files changed, 85 insertions(+), 21 deletions(-) > > not sure its not intended but this causes differences > in error concealment on many files Not intended by me, at least. And not sure how using a tree instead of a linked list to keep a pool of buffers could affect that. The way they are allocated or returned is not changed, and all the existing users are still only creating fixed sized buffers. Do you have an idea of what could be happening? The way the tree is being handled is afaik correct, judging by the doxy. Removing and adding one element at a time using a simple cmp() function and with no way to have races since it's all controlled by a mutex. > an example would be something like this: > > ffmpeg -threads 1 -i 1069/green-block-artifacts-from-canon-100-hs.MOV test.avi > > > [...] > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [CLT2018] FFmpeg at Chemnitzer Linux-Tage
On 2018-03-13 20:08 +0100, Thilo Borgmann wrote: > Am 13.03.18 um 19:52 schrieb Paul B Mahol: > > On 3/13/18, Thilo Borgmann wrote: > >> Hi, > >> > >>> once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany! > >>> This "Chemnitzer Linux Tage" will take place on 10th and 11th of March. > >>> You can find more details on their homepage: > >>> > >>> https://chemnitzer.linux-tage.de/2018/en/ > >>> > >>> Thus once again, we will man a booth with our staff and are happily > >>> waiting for > >>> our users to get in touch with us! If you're a developer and want to help > >>> us or > >>> just want to visit and check in at our booth, please let us know. > >> > >> we've returned from the CLT. This year has been the 20th anniversary of the > >> CLT - so they'd put some additional effort into it to make it even a better > >> pleasure for all the exhibitors. Most notably in terms of an updated > >> Saturday dinner :) > >> > >> We presented our usual demo using motion vector overlay to attract people > >> and Thomas and Alexander created a very nice new demo for visualization > >> filters, command-line expressions and video output, randomly altered. We > >> again had a lot of users coming by and Gerion also gave a workshop on > >> command-line based filtering. > > > > Which filter where used? > > Alexander knows about the complete list, maybe he can answer to that in > particular. Demo 1: ffmpeg -loglevel quiet -framerate 15 -video_size 640x480 -i /dev/video0 -q:v 2 -mbd 2 -g 600 -f m4v -r 8 - | ffplay -f m4v -loglevel quiet\ -flags2 +export_mvs -i - \ -vf codecview=mv=pf+bf+bb:mvt=fp+bp,hflip This is a traditional demo we show since the first time in Chemnitz. It's totally great to get visitors to stay for a while and most often ask a question or two. Demo 2: ffmpeg -stream_loop -1 -i media/Sintel.2010.720p.mkv \ -lavfi "[0:a]showwaves=mode=line:scale=log:size=1200x240[waves] ; [0:v]setpts=PTS-STARTPTS,split[a][b] ; [a]histogram[hist] ; [b]pad=iw+256:ih+240[padded] ; [padded][hist]overlay=W-w:0[x] ; [x][waves]overlay=0:H-h" -an ... This needed lots of fifos filters inserted in the past, but works fine without them using recent FFmpeg. Demo 3: ffmpeg -re -stream_loop -1 -framerate 1/3 -start_number 1 -i media/P-%d.JPG -vf ' split[a][b]; [b]zmq,hue=234, noise=alls=95:allf=t+u,negate,curves=vintage[b2]; [a][b2]hstack ' -an ... This builds on the idea of a demo Stefano once prepared for Linux-Tag in Berlin. It will slowly loop through a bunch of pictures applying the filters on them. In the background I am periodically randomly turning on/off the filters hue, noise, negate, and curves from another process using ZMQ. It also shows the original and filtered picture side by side, so visitors can spot the differences. I think a lot more can be added here, the question though will be how much value it really adds and if it would then need some other means to mix and match those filters instead of the stupid method I used so far. I also planned a 4th demo, but I wasn't satisfied with the results so I dropped it after investing a few hours. > > From older cases, they were not enough covered, causing users asking for > > filters > > which are already available. Thilo mostly replied to this one (see below). Though if you have any particular filters in mind, that people are often asking for, but that are already implemented, please tell me. I will try my best to get the word out. OT: Thank you Paul for adding and improving so many filters. I really appreciate your work and enjoy seeing filtering in FFmpeg getting richer and more mature. > Hmm.. I had not heard such comments or not to a high enough extend so that > this problem has made it into my memory. Just don't forget about two aspects > here, first, the complete list of filters is not what we aim to show, but to > give some examples to get people talking to us and asking questions (so a > question if we also have filter XY would be a good result of the demo), and > second, not all filters are presentable - most people seeing the demo have > untrained eyes looking at it and therefore a hardly recognizable filter might > result in their thought of what the hell we are doing at all there... and > that thought is to be avoided by a demo :) > > However, if you (or anyone) wants a particular thing to be included in our > demos, just give that remark early enough and we will happily include it. We > would like to have even more ideas next time! [...] Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/noise_bsf: move the reference in the bsf internal buffer
On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote: > There's no need to allocate a new packet for it. > > Signed-off-by: James Almer > --- > libavcodec/noise_bsf.c | 30 -- > 1 file changed, 8 insertions(+), 22 deletions(-) should be ok assumung the the packet from ff_bsf_get_packet_ref can be modified, this is not documented in bsf.h thx [...] -- 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 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API
On Sat, Mar 17, 2018 at 09:26:32PM -0300, James Almer wrote: > On 3/17/2018 8:48 PM, Michael Niedermayer wrote: > > On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote: > >> Signed-off-by: James Almer > >> --- > >> This is a proof of concept for a dynamic size buffer pool API. > >> > >> For the purpose of easy testing and reviewing I replaced the current > >> linked list used to keep a pool of fixed size buffers with the tree > >> based pool that will be used to keep a pool of varying size buffers, > >> instead of adding a new set of functions exclusively for the new API. > >> The final committed work doesn't necessarely have to do the above, as > >> there's no real benefit using a tree when you only need a fixed size > >> buffer pool, other than simplying things. > >> > >> I'm open to suggestions about how to introduce this. Completely > >> separate set of functions and struct names? Sharing the struct and > >> init/uninit functions and only adding a new get() one like in this > >> patch? > >> Any preferences with function/struct naming, for that matter? > >> > >> libavutil/buffer.c | 98 > >> - > >> libavutil/buffer.h | 2 + > >> libavutil/buffer_internal.h | 6 ++- > >> 3 files changed, 85 insertions(+), 21 deletions(-) > > > > not sure its not intended but this causes differences > > in error concealment on many files > > Not intended by me, at least. And not sure how using a tree instead of a > linked list to keep a pool of buffers could affect that. The way they > are allocated or returned is not changed, and all the existing users are > still only creating fixed sized buffers. > > Do you have an idea of what could be happening? The way the tree is is always the same buffer used as before ? a different buffer with different content could probably leak the content through into the output on some errors. > being handled is afaik correct, judging by the doxy. Removing and adding > one element at a time using a simple cmp() function and with no way to > have races since it's all controlled by a mutex. > > > an example would be something like this: > > > > ffmpeg -threads 1 -i 1069/green-block-artifacts-from-canon-100-hs.MOV > > test.avi > > > > > > [...] > > > > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/noise_bsf: move the reference in the bsf internal buffer
On 3/17/2018 10:28 PM, Michael Niedermayer wrote: > On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote: >> There's no need to allocate a new packet for it. >> >> Signed-off-by: James Almer >> --- >> libavcodec/noise_bsf.c | 30 -- >> 1 file changed, 8 insertions(+), 22 deletions(-) > > should be ok assumung the the packet from ff_bsf_get_packet_ref can be > modified, this is not documented in bsf.h Yes, ff_bsf_get_packet_ref() moves the reference from the internal bsf packet as stored by av_bsf_send_packet() to the already allocated packet passed by the caller, whereas ff_bsf_get_packet() hands a newly allocated packet with the reference to the caller. > > thx > > [...] > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API
On 3/17/2018 10:33 PM, Michael Niedermayer wrote: > On Sat, Mar 17, 2018 at 09:26:32PM -0300, James Almer wrote: >> On 3/17/2018 8:48 PM, Michael Niedermayer wrote: >>> On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote: Signed-off-by: James Almer --- This is a proof of concept for a dynamic size buffer pool API. For the purpose of easy testing and reviewing I replaced the current linked list used to keep a pool of fixed size buffers with the tree based pool that will be used to keep a pool of varying size buffers, instead of adding a new set of functions exclusively for the new API. The final committed work doesn't necessarely have to do the above, as there's no real benefit using a tree when you only need a fixed size buffer pool, other than simplying things. I'm open to suggestions about how to introduce this. Completely separate set of functions and struct names? Sharing the struct and init/uninit functions and only adding a new get() one like in this patch? Any preferences with function/struct naming, for that matter? libavutil/buffer.c | 98 - libavutil/buffer.h | 2 + libavutil/buffer_internal.h | 6 ++- 3 files changed, 85 insertions(+), 21 deletions(-) >>> >>> not sure its not intended but this causes differences >>> in error concealment on many files >> >> Not intended by me, at least. And not sure how using a tree instead of a >> linked list to keep a pool of buffers could affect that. The way they >> are allocated or returned is not changed, and all the existing users are >> still only creating fixed sized buffers. >> > >> Do you have an idea of what could be happening? The way the tree is > > is always the same buffer used as before ? Was thinking that, yes. The pool organized by the tree most assuredly orders the buffers in a different way than the linked list (Which i think is simply FIFO), so the h264 decoder or whatever is handling the pool here now gets a different buffer after calling av_buffer_pool_get(). This would mean the EC code is overreading bytes, and that the buffer is not zeroed after being requested. The former should probably be fixed. Fortunately not a bug from this patch/implementation, in that case. > a different buffer with different content could probably leak the content > through into the output on some errors. > > >> being handled is afaik correct, judging by the doxy. Removing and adding >> one element at a time using a simple cmp() function and with no way to >> have races since it's all controlled by a mutex. >> >>> an example would be something like this: >>> >>> ffmpeg -threads 1 -i 1069/green-block-artifacts-from-canon-100-hs.MOV >>> test.avi >>> >>> >>> [...] >>> >>> >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/noise_bsf: move the reference in the bsf internal buffer
On Sat, Mar 17, 2018 at 10:39:25PM -0300, James Almer wrote: > On 3/17/2018 10:28 PM, Michael Niedermayer wrote: > > On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote: > >> There's no need to allocate a new packet for it. > >> > >> Signed-off-by: James Almer > >> --- > >> libavcodec/noise_bsf.c | 30 -- > >> 1 file changed, 8 insertions(+), 22 deletions(-) > > > > should be ok assumung the the packet from ff_bsf_get_packet_ref can be > > modified, this is not documented in bsf.h > > Yes, ff_bsf_get_packet_ref() moves the reference from the internal bsf > packet as stored by av_bsf_send_packet() to the already allocated packet > passed by the caller, whereas ff_bsf_get_packet() hands a newly > allocated packet with the reference to the caller. what i meant is that the docs dont say that the caller can modify pkt->data without using some *make_writable() function also while ff_bsf_get_packet() documents freeing requirements, ff_bsf_get_packet_ref leaves this ambigous, from must over can to a must not. that is the docs should be made clearer assuming it is all correct [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/noise_bsf: move the reference in the bsf internal buffer
On 3/17/2018 10:54 PM, Michael Niedermayer wrote: > On Sat, Mar 17, 2018 at 10:39:25PM -0300, James Almer wrote: >> On 3/17/2018 10:28 PM, Michael Niedermayer wrote: >>> On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote: There's no need to allocate a new packet for it. Signed-off-by: James Almer --- libavcodec/noise_bsf.c | 30 -- 1 file changed, 8 insertions(+), 22 deletions(-) >>> >>> should be ok assumung the the packet from ff_bsf_get_packet_ref can be >>> modified, this is not documented in bsf.h >> >> Yes, ff_bsf_get_packet_ref() moves the reference from the internal bsf >> packet as stored by av_bsf_send_packet() to the already allocated packet >> passed by the caller, whereas ff_bsf_get_packet() hands a newly >> allocated packet with the reference to the caller. > > what i meant is that the docs dont say that the caller can > modify pkt->data without using some *make_writable() function Turns outs the packet passed to the caller is the same one with both functions. ff_bsf_get_packet() does tmp_pkt = av_packet_alloc(); if (!tmp_pkt) return AVERROR(ENOMEM); *pkt = ctx->internal->buffer_pkt; ctx->internal->buffer_pkt = tmp_pkt; Meaning it's not handing over a newly allocated packet but the buffered one instead. ff_bsf_get_packet_ref() in turn does av_packet_move_ref(pkt, ctx->internal->buffer_pkt); In both cases, ctx->internal->buffer_pkt is evidently expected to be writable by the time a bsf requests it, at least judging by how it's handled. See aac_adtstoasc, for example. I guess a make_writable() call in av_bsf_send_packet() would be a good idea to make sure that's effectively the case? Neither the doxy for av_bsf_send_packet() or ff_bsf_get_packet* mention anything about the writable status of this stored packet. > > also while ff_bsf_get_packet() documents freeing requirements, > ff_bsf_get_packet_ref leaves this ambigous, from must over can > to a must not. > > that is the docs should be made clearer assuming it is all correct > > [...] > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/noise_bsf: move the reference in the bsf internal buffer
On 3/17/2018 11:13 PM, James Almer wrote: > On 3/17/2018 10:54 PM, Michael Niedermayer wrote: >> On Sat, Mar 17, 2018 at 10:39:25PM -0300, James Almer wrote: >>> On 3/17/2018 10:28 PM, Michael Niedermayer wrote: On Fri, Mar 16, 2018 at 08:16:01PM -0300, James Almer wrote: > There's no need to allocate a new packet for it. > > Signed-off-by: James Almer > --- > libavcodec/noise_bsf.c | 30 -- > 1 file changed, 8 insertions(+), 22 deletions(-) should be ok assumung the the packet from ff_bsf_get_packet_ref can be modified, this is not documented in bsf.h >>> >>> Yes, ff_bsf_get_packet_ref() moves the reference from the internal bsf >>> packet as stored by av_bsf_send_packet() to the already allocated packet >>> passed by the caller, whereas ff_bsf_get_packet() hands a newly >>> allocated packet with the reference to the caller. >> >> what i meant is that the docs dont say that the caller can >> modify pkt->data without using some *make_writable() function > > Turns outs the packet passed to the caller is the same one with both > functions. > > ff_bsf_get_packet() does > > tmp_pkt = av_packet_alloc(); > if (!tmp_pkt) > return AVERROR(ENOMEM); > > *pkt = ctx->internal->buffer_pkt; > ctx->internal->buffer_pkt = tmp_pkt; > > Meaning it's not handing over a newly allocated packet but the buffered > one instead. > > ff_bsf_get_packet_ref() in turn does > > av_packet_move_ref(pkt, ctx->internal->buffer_pkt); > > In both cases, ctx->internal->buffer_pkt is evidently expected to be > writable by the time a bsf requests it, at least judging by how it's > handled. See aac_adtstoasc, for example. Actually no, aac_adtstoasc doesn't change the packet data, just the size and data pointer like many others, so nevermind. I'm dropping this patch, just in case. Sorry for the noise. > > I guess a make_writable() call in av_bsf_send_packet() would be a good > idea to make sure that's effectively the case? > Neither the doxy for av_bsf_send_packet() or ff_bsf_get_packet* mention > anything about the writable status of this stored packet. > >> >> also while ff_bsf_get_packet() documents freeing requirements, >> ff_bsf_get_packet_ref leaves this ambigous, from must over can >> to a must not. >> >> that is the docs should be made clearer assuming it is all correct >> >> [...] >> >> >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
