[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 FFm

[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 FFm

[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 that

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

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] [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

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

[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

> > 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. __

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 >

[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 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

[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 av_freep(&pre

[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] [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 the

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 a

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) && > > NOT

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 > > se

[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 a

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 > --- a/tests/ref/fate/fil

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

ance. 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

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 https://manifest.googlevideo.com/api/manifest/hls_playlist/id/V2E-jOUVsd4.1/itag/95/source/yt_live_broadcast/requiressl/yes/ra

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

[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 fi

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 a

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

, March 5, 2018, Valery Kot 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 patch

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

_ From: Derek Buitenhuis 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: On 3/12/2018 6:58 AM, Valery Kot wrote: >> Could somebody please take a look i

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

2018 15:01:16 +0100 Valery Kot wrote: > From f95943165c91dac13a644365f775aff3dd9edb11 Mon Sep 17 00:00:00 2001 > From: vkot > Date: Mon, 5 Mar 2018 13:51:51 +0100 > Subject: [PATCH 3/3] avcodec/openh264enc.c: generate IDR frame in response to > I frame pict_type >

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 other requested chang

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 wrote: > > Attached is an updated patch incorporating all feedback - only > formatting for now. > > Friendly ping to maintainers to review and pull the patch. > > Valery Another ping. ___

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 wrote: > On Fri, Mar 16, 2018 at 3:04 PM, Valery Kot wrote: >> >> Attached is an updated patch incorporating all feedback - only >> formatting for now. >> >> Friendly ping to maintainers to review and pull the patch. &g

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 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? >> >> Doesn't appear to

[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 Date