Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_edgedetect: properly implement double_threshold()

performance. Maybe later I'll try to implement it in a generic way, but this is out of scope for this patch. Regards, Valery Kot ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link

Re: [FFmpeg-devel] [Patch] vf_edgedetect: properly implement double_threshold()

On Mon, Jun 22, 2020 at 4:56 PM Andriy Gelman wrote: > It should be enough to change the hashes in two files. > Please resend with these changes. > > diff --git a/tests/ref/fate/filter-edgedetect > b/tests/ref/fate/filter-edgedetect > index 23c9953e61..e49639afac 100644 > ---

[FFmpeg-devel] [PATCH v2] avfilter/vf_edgedetect: properly implement double_threshold()

=== Version 1 === vf_edgedetect video filter implements Canny algorithm (https://en.wikipedia.org/wiki/Canny_edge_detector) Important part of this algo is the double threshold step: pixels above "high" threshold being kept, pixels below "low" threshold dropped, pixels in between kept if they are

Re: [FFmpeg-devel] [Patch] vf_edgedetect: properly implement double_threshold()

On Mon, Jun 22, 2020 at 12:57 PM Moritz Barsnick wrote: > > On Mon, Jun 22, 2020 at 09:58:42 +0200, Valery Kot wrote: > > Thanks for feedback. Updating FATE tests is a bridge too far for me. I > > can't even build FFmpeg itself at the moment, say nothing about > > setting

Re: [FFmpeg-devel] [Patch] vf_edgedetect: properly implement double_threshold()

On Mon, Jun 22, 2020 at 12:54 PM Moritz Barsnick wrote: > > On Fri, Jun 19, 2020 at 17:15:06 +0200, Valery Kot wrote: > > -if ((!i || i == w - 1 || !j || j == h - 1) && > > +if (!(!i || i == w - 1 || !j || j == h - 1) && > >

Re: [FFmpeg-devel] [Patch] vf_edgedetect: properly implement double_threshold()

On Mon, Jun 22, 2020 at 7:58 AM Andriy Gelman wrote: > > Hi Valery, > > Thanks for the patch. > > Please also update the fate test: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/cagtf1mncx2joo-vmtucdkjcp76y5jslnhubzat4mf48c2hf...@mail.gmail.com/ Thanks for feedback. Updating FATE tests is

Re: [FFmpeg-devel] [Patch] vf_edgedetect: properly implement double_threshold()

> > > vf_edgedetect video filter implements Canny algorithm > > (https://en.wikipedia.org/wiki/Canny_edge_detector) > > > > Important part of this algo is the double threshold step: pixels above > > "high" threshold being kept, pixels below "low" threshold dropped, > > pixels in between kept if

[FFmpeg-devel] [Patch] vf_edgedetect: properly implement double_threshold()

vf_edgedetect video filter implements Canny algorithm (https://en.wikipedia.org/wiki/Canny_edge_detector) Important part of this algo is the double threshold step: pixels above "high" threshold being kept, pixels below "low" threshold dropped, pixels in between kept if they are attached to "high"

Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak

On Sat, Dec 22, 2018 at 6:33 PM Derek Buitenhuis wrote: > Can you add to the commit message to explain what exactly is > changed and why? 'Fix leak' isn't very useful. Submitted a patch (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238093.html) with updated commit message, Or is there

[FFmpeg-devel] [PATCH] avformat/hls.c: Properly free prev_segments dynarray after playlist parsing

Updated commit message for hls.c memory leak fix From 0bb8c4a17f9de7167f3aafc59fc309f581e00e0b Mon Sep 17 00:00:00 2001 From: vkot Date: Mon, 24 Dec 2018 10:19:55 +0100 Subject: [PATCH] avformat/hls.c: Properly free prev_segments dynarray after playlist parsing --- libavformat/hls.c | 1 + 1

Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak

Ping... Any maintainer willing to review/push straightforward one-liner patch? > Thus 59MB leak in an hour! And keeps growing... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak

I just verified that patch is working. Build FFmpeg master with and without patch, run HLS live stream from Youtube (extracted by youtube_dl for Euronews live). ffmpeg -i

[FFmpeg-devel] avformat/hls.c: Fix memory leak

Patch for https://trac.ffmpeg.org/ticket/7610 hls.c:933 free_segment_dynarray(prev_segments, prev_n_segments); cleans all elements of prev_segments, but does not frees prev_segments array itself. As a result, process slowly leaks memory every time it updates playlist. Added call to

Re: [FFmpeg-devel] [PATCH v2] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

On Mon, Nov 5, 2018 at 4:50 PM Mark Thompson wrote: > > LGTM, tested and applied. > > - Mark Thanks! Is it also possible to apply this patch on release/4.1 branch, so that it will end up in the next release? Valery ___ ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH v2] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

On Thu, Nov 1, 2018 at 1:55 PM Valery Kot wrote: > > > I think this would look nicer (and generate less code) as a table + loop > > rather than an if-ladder making each fraction structure inline? > > > > E.g. something like > > <http://git.videolan.o

Re: [FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

> I think this would look nicer (and generate less code) as a table + loop > rather than an if-ladder making each fraction structure inline? > > E.g. something like >

Re: [FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

> > Apparently there are no acrive maintainers and no devs (other than me) > > using libopenh264. What can be done to have this patch accepted? > > One possibility is that you send a patch that adds yourself > as maintainer. > > Carl Eugen Patch for MAINTAINERS list submitted, as you suggested.

[FFmpeg-devel] [PATCH] Adding Valery Kot as a maintainer for libopenh264*

: [PATCH 2/2] Adding Valery Kot as a maintainer for libopenh264* --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3dd26e374f..4e10f18f98 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -193,6 +193,7 @@ Codecs: libkvazaar.c

Re: [FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

Yet another ping... Apparently there are no acrive maintainers and no devs (other than me) using libopenh264. What can be done to have this patch accepted? On Wed, Oct 24, 2018 at 8:57 AM Valery Kot wrote: > > Another ping. > On Thu, Oct 18, 2018 at 10:46 AM Valery Kot wrote: > &g

Re: [FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

Another ping. I understand that there is still (or anymore) no active maintainer for this module. Could any of the developers please take a look at this patch and push it? I really need it in FFmpeg repo! On Thu, Oct 18, 2018 at 10:46 AM Valery Kot wrote: > > A gentl

Re: [FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

A gentle ping... On Fri, Oct 12, 2018 at 9:14 AM Valery Kot wrote: > > When using libx264 (GPL) encoder, sample aspect ratio gets stored on > both container and frame levels. For libopenh264 (LGPL) encoder, > aspect ratio on codec/frame level currently is ignored, which results > i

Re: [FFmpeg-devel] avcodec/libopenh264enc.c

I sent a (hopefully valid) patch along with a proper commit message. It resulted in a new thread, sorry. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

When using libx264 (GPL) encoder, sample aspect ratio gets stored on both container and frame levels. For libopenh264 (LGPL) encoder, aspect ratio on codec/frame level currently is ignored, which results in weird display aspect ratio for non-square pixels on some players. Proposed patch fixes

[FFmpeg-devel] avcodec/libopenh264enc.c

When using libx264 (GPL) encoder, sample aspect ratio gets stored on both container and frame levels. For libopenh264 (LGPL), aspect ratio on codec/frame level currently is ignored, which results in weird display aspect ratio for non-square pixels on some players. Proposed patch fixes that, if

[FFmpeg-devel] avcodec/libopenh264enc.c

When using libx264 (GPL) encoder, sample aspect ratio gets stored on both container and frame levels. For libopenh264 (LGPL), aspect ratio on codec/frame level currently is ignored, which results in weird display aspect ratio for non-square pixels on some players. Proposed patch fixes that, if

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

On Thu, Apr 5, 2018 at 9:02 PM, James Almer <jamr...@gmail.com> wrote: > On 4/5/2018 3:25 PM, Lou Logan wrote: >> On Sun, Mar 25, 2018, at 10:51 PM, Valery Kot wrote: >>> >>> Just wondering: is there an active maintainer for avcodec/libopenh264? >> >>

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

On Tue, Mar 20, 2018 at 9:21 AM, Valery Kot <valery@gmail.com> wrote: > On Fri, Mar 16, 2018 at 3:04 PM, Valery Kot <valery@gmail.com> wrote: >> >> Attached is an updated patch incorporating all feedback - only >> formatting for now. >> >> Fr

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

On Fri, Mar 16, 2018 at 3:04 PM, Valery Kot <valery@gmail.com> wrote: > > Attached is an updated patch incorporating all feedback - only > formatting for now. > > Friendly ping to maintainers to review and pull the patch. >

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

On Wed, Mar 14, 2018 at 2:12 PM, Moritz Barsnick wrote: > > On Mon, Mar 12, 2018 at 14:38:21 -0800, Lou Logan wrote: > > > But you don't necessarily need to make a new patch to address the > > minor whitespace issue. You can wait for other comments and include > > it with any

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

t_type To: <ffmpeg-devel@ffmpeg.org> On Mon, 5 Mar 2018 15:01:16 +0100 Valery Kot <valery@gmail.com> wrote: > From f95943165c91dac13a644365f775aff3dd9edb11 Mon Sep 17 00:00:00 2001 > From: vkot <valery@4cinsights.com> > Date: Mon, 5 Mar 2018 13:51:51 +0100 > Subjec

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

_ From: Derek Buitenhuis <derek.buitenh...@gmail.com> Sent: Monday, March 12, 2018 6:54 PM Subject: Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type To: <ffmpeg-devel@ffmpeg.org> On 3/12/2018 6:58 AM

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

, March 5, 2018, Valery Kot <valery@gmail.com> wrote: > libx264 encoder uses AVFrame.pict_type (if provided by user) to use this > frame as key frame. > > For openh264 encoder this functionality is missing, pict_type simply being > ignored. > > Attached

[FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

libx264 encoder uses AVFrame.pict_type (if provided by user) to use this frame as key frame. For openh264 encoder this functionality is missing, pict_type simply being ignored. Attached patch fixes it. Valery From f95943165c91dac13a644365f775aff3dd9edb11 Mon Sep 17 00:00:00 2001 From: vkot