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

2020-06-29 Thread Valery Kot 
On Sun, Jun 28, 2020 at 12:03 AM Andriy Gelman  wrote:
>
> lgtm. I saw a small improvement when testing.
>
> Would be nice to allow weak edges that become strong to trigger neighboring 
> weak
> edges in the future.

Thanks for the comment.

You are right, ideally double_threshold should be recursive (seed from
each "high" peak and spread over "low" peaks). But then potentially we
may end up with width*height/2 recursion depth, which may lead to
stack overflow. So probably some recursion limit is needed, and hence
suboptimal solution.

Or iterative approach, running through the complete image again and
again checking if "low" peaks are touching already selected edge
pixels. Stop when no new pixels can be added to the edge. Better, but
still potentially width*height/2 iterations with width*height
operations each, completely killing 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 above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

2020-06-22 Thread Valery Kot 
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/filter-edgedetect
> +++ b/tests/ref/fate/filter-edgedetect
> @@ -1 +1 @@
> -edgedetect  93ceace33f6636bcdbeb037317c65745
> +edgedetect  04ff46bb35edff3dbad4102391516d25
> diff --git a/tests/ref/fate/filter-edgedetect-colormix 
> b/tests/ref/fate/filter-edgedetect-colormix
> index e828c6bd19..0df17344bc 100644
> --- a/tests/ref/fate/filter-edgedetect-colormix
> +++ b/tests/ref/fate/filter-edgedetect-colormix
> @@ -1 +1 @@
> -edgedetect-colormix 1b8658252e2f03fbae30e6d63dd24c7c
> +edgedetect-colormix 9f50c5586f899a8f5a10059154d64bde

Just submitted patch V2, please drop this one.

Thanks for the help Andriy, appreciated!

Valery
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

2020-06-22 Thread Valery Kot 
=== 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 attached to "high" pixels.

This is implemented in the double_threshold() function. However,
condition to start checking attached pixels, as it is now and as it
was in FFmpeg since 2012, only allows checking on the boundary, not
inside the video. It is a very lucky coincidence that those boundary
pixels are always 0, otherwise following lines would be reading
outside of the buffer.

As it is now, double_threshold() only implements "high" thresholding.
As a result, edges are either noisy or fragmented, depending on "high"
threshold selection; "low" threshold is simply ignored.

Attached one char patch fixes this.

=== Version 2 ===
- include avfilter/ in commit message
- update FATE tests
From 69bbe24bfe23efa3874448f28451b1abaa209d5d Mon Sep 17 00:00:00 2001
From: vkot 
Date: Fri, 19 Jun 2020 16:57:13 +0200
Subject: [PATCH] avfilter/vf_edgedetect: properly implement double_threshold()

---
 libavfilter/vf_edgedetect.c   | 2 +-
 tests/ref/fate/filter-edgedetect  | 2 +-
 tests/ref/fate/filter-edgedetect-colormix | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_edgedetect.c b/libavfilter/vf_edgedetect.c
index a5614ea63b..df8afbd532 100644
--- a/libavfilter/vf_edgedetect.c
+++ b/libavfilter/vf_edgedetect.c
@@ -294,7 +294,7 @@ static void double_threshold(int low, int high, int w, int 
h,
 continue;
 }
 
-if ((!i || i == w - 1 || !j || j == h - 1) &&
+if (!(!i || i == w - 1 || !j || j == h - 1) &&
 src[i] > low &&
 (src[-src_linesize + i-1] > high ||
  src[-src_linesize + i  ] > high ||
diff --git a/tests/ref/fate/filter-edgedetect b/tests/ref/fate/filter-edgedetect
index 23c9953e61..e49639afac 100644
--- a/tests/ref/fate/filter-edgedetect
+++ b/tests/ref/fate/filter-edgedetect
@@ -1 +1 @@
-edgedetect  93ceace33f6636bcdbeb037317c65745
+edgedetect  04ff46bb35edff3dbad4102391516d25
diff --git a/tests/ref/fate/filter-edgedetect-colormix 
b/tests/ref/fate/filter-edgedetect-colormix
index e828c6bd19..0df17344bc 100644
--- a/tests/ref/fate/filter-edgedetect-colormix
+++ b/tests/ref/fate/filter-edgedetect-colormix
@@ -1 +1 @@
-edgedetect-colormix 1b8658252e2f03fbae30e6d63dd24c7c
+edgedetect-colormix 9f50c5586f899a8f5a10059154d64bde
-- 
2.26.2.windows.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] vf_edgedetect: properly implement double_threshold()

2020-06-22 Thread Valery Kot 
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 up the test environment and finding out how it works. Could
> > you please do this update for me?
>
> Are you saying you analyzed this issue in the source code, but have
> not had a chance to check whether the change really fixes the output?
> [*]

I tested master build from Zeranoe to confirm that there is a bug
(modifying low threshold changes nothing in output). Then I modified
double_threshold() function and tested it locally in a unit test (in
my own testbed).

>
> Once you *do* understand how to build ffmpeg, you can follow the fate
> instructions here:
> https://ffmpeg.org/fate.html#Using-FATE-from-your-FFmpeg-source-directory
>
> You don't actually need to add a new fate test in this case, but submit
> the changed reference output with your patch (assuming that the changed
> output is really correct!).

I am working on Windows, and don't have build environment for FFmpeg
at this moment. As this is not a pressing issue for me, I don't want
to spend time on it. I was just developing my own Canny filter
implementation and noticed that FFmpeg edge detector is
underperforming (quality wise). I could've do nothing, or just sent a
bug report, but chose to send this patch as a contribution to the
community.

>
> Cheers,
> Moritz
>
> [*] I'm not saying that someone couldn't do that for you instead, if
> they are willing.
___
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] vf_edgedetect: properly implement double_threshold()

2020-06-22 Thread Valery Kot 
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 of a logical OR can be inverted, so this *may* be more readable as:
>if ((i && i != w - 1 && j && j != h - 1) &&
> or even drop the bracket
>if (i && i != w - 1 && j && j != h - 1 &&
>

Indeed, those three are equivalent. Complex logical conditions can be
written in different ways. I chose mine to minimize change, assuming
that there was just a typo in original algo implementation.
___
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] vf_edgedetect: properly implement double_threshold()

2020-06-22 Thread Valery Kot 
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 bridge too far for me. I
can't even build FFmpeg itself at the moment, say nothing about
setting up the test environment and finding out how it works. Could
you please do this update for me?

> Add an avfilter/ prefix to the commit title.

I will, if FATE issue can be solved

> Thanks,
> --
> Andriy
>
___
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] vf_edgedetect: properly implement double_threshold()

2020-06-19 Thread Valery Kot 
>
> > 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" pixels.
> >
> > This is implemented in the double_threshold() function. However,
> > condition to start checking attached pixels, as it is now and as it
> > was in FFmpeg since 2012, only allows checking on the boundary, not
> > inside the video. It is a very lucky coincidence that those boundary
> > pixels are always 0, otherwise following lines would be reading
> > outside of the buffer.
> >
> > As it is now, double_threshold() only implements "high" thresholding.
> > As a result, edges are either noisy or fragmented, depending on "high"
> > threshold selection; "low" threshold is simply ignored.
> >
> > Attached one char patch fixes this.
> >
> > Please review.
>
> Looks indeed like the condition is wrong.
>
> I say looks because I did only look and didn't do actual testing.
>
> I hope you will answer my question anyway: Does your patch completely
> fix the problem or is it sacrificing the treatment of the outer most
> pixels?
>

>
Hi Alexander,
Outer pixels are already set to 0 (line 333, memset(tmpbuf, 0, inlink->w

* inlink->h

);)
This  is correct, as it is not possible to properly calculate gradient
there.
Patch fixes handling of inner pixels and changes nothing for outer pixels.
___
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] vf_edgedetect: properly implement double_threshold()

2020-06-19 Thread Valery Kot 
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" pixels.

This is implemented in the double_threshold() function. However,
condition to start checking attached pixels, as it is now and as it
was in FFmpeg since 2012, only allows checking on the boundary, not
inside the video. It is a very lucky coincidence that those boundary
pixels are always 0, otherwise following lines would be reading
outside of the buffer.

As it is now, double_threshold() only implements "high" thresholding.
As a result, edges are either noisy or fragmented, depending on "high"
threshold selection; "low" threshold is simply ignored.

Attached one char patch fixes this.

Please review.

Valery
From b78f5960736de52d1c8e41bd598a465092c1de60 Mon Sep 17 00:00:00 2001
From: vkot 
Date: Fri, 19 Jun 2020 16:57:13 +0200
Subject: [PATCH] vf_edgedetect: properly implement double_threshold()

---
 libavfilter/vf_edgedetect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_edgedetect.c b/libavfilter/vf_edgedetect.c
index a5614ea63b..df8afbd532 100644
--- a/libavfilter/vf_edgedetect.c
+++ b/libavfilter/vf_edgedetect.c
@@ -294,7 +294,7 @@ static void double_threshold(int low, int high, int w, int 
h,
 continue;
 }
 
-if ((!i || i == w - 1 || !j || j == h - 1) &&
+if (!(!i || i == w - 1 || !j || j == h - 1) &&
 src[i] > low &&
 (src[-src_linesize + i-1] > high ||
  src[-src_linesize + i  ] > high ||
-- 
2.26.2.windows.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] avformat/hls.c: Fix memory leak

2018-12-24 Thread Valery Kot 
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 way to edit commit message
of an already sumitted patch?

Valery
___
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

2018-12-24 Thread Valery Kot 
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 file changed, 1 insertion(+)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 8ad08baaed..63e1abe789 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -931,6 +931,7 @@ static int parse_playlist(HLSContext *c, const char *url,
prev_start_seq_no, pls->start_seq_no);
 }
 free_segment_dynarray(prev_segments, prev_n_segments);
+av_freep(_segments);
 }
 if (pls)
 pls->last_load_time = av_gettime_relative();
-- 
2.15.1.windows.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-12-22 Thread Valery Kot 
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

2018-12-17 Thread Valery Kot 
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/ratebypass/yes/live/1/cmbypass/yes/goi/160/sgoap/gir%3Dyes%3Bitag%3D140/sgovp/gir%3Dyes%3Bitag%3D136/hls_chunk_host/r4---sn-5hnedn7e.googlevideo.com/ei/E2sXXOrRGdjGgAe_6abgBA/gcr/nl/playlist_type/DVR/initcwndbps/12170/mm/32/mn/sn-5hnedn7e/ms/lv/mv/m/pl/24/dover/11/keepalive/yes/mt/1545038545/disable_polymer/true/ip/80.255.245.45/ipbits/0/expire/1545060211/sparams/ip,ipbits,expire,id,itag,source,requiressl,ratebypass,live,cmbypass,goi,sgoap,sgovp,hls_chunk_host,ei,gcr,playlist_type,initcwndbps,mm,mn,ms,mv,pl/signature/517F67575565239FC2D7117212AB722FB68BA3A6.4A8F847C14BF8C702103AEC348C8AC553E812ECE/key/dg_yt0/playlist/index.m3u8
 -c copy -t 3 -f mpegts -y NUL 2 _out.txt

Checking process memory (private working set) in Task Manager
Both instances start at 27MB RAM footprint.
Patched version within a minute grows to 31 MB and then stable.
Unmodified master RAM keeps growing, and after one hour reaches 90MB.
Thus 59MB leak in an hour! And keeps growing...

Youtube updates variant playlists app. every 2 seconds, with 3600
fragments each. Means leak of 8(bytes)*3600(pointers in
prev_segments)*30*60(playlists per hour) = 54M - correlates with
experimental results.
Of course, youtube is an extreme case, but leak also degrades over
time any live HLS input.

Please review.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-12-14 Thread Valery Kot 
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(_segments)
From 90f3f7abd3561ef12404686dfac99940e8c5167e Mon Sep 17 00:00:00 2001
From: vkot 
Date: Fri, 14 Dec 2018 13:38:05 +0100
Subject: [PATCH] Fix memory leak in hls.c

---
 libavformat/hls.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 8ad08baaed..63e1abe789 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -931,6 +931,7 @@ static int parse_playlist(HLSContext *c, const char *url,
prev_start_seq_no, pls->start_seq_no);
 }
 free_segment_dynarray(prev_segments, prev_n_segments);
+av_freep(_segments);
 }
 if (pls)
 pls->last_load_time = av_gettime_relative();
-- 
2.15.1.windows.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-11-06 Thread Valery Kot 
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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-11-01 Thread Valery Kot 
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.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_metadata_bsf.c;h=bf37528234c7ab8bac56f773ad99f5a67f79db29;hb=HEAD#l95>.
>
> Thanks for the suggestion! Here is an updated patch.

Was too hurry to send a patch, sorry! Here is the correct one.
From 638277354338bf42020854e5bebec5fe61677135 Mon Sep 17 00:00:00 2001
From: vkot 
Date: Thu, 1 Nov 2018 14:15:11 +0100
Subject: [PATCH] Handle sample_aspect_ratio in libopenh264-encoder

---
 libavcodec/libopenh264enc.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 83c3f0ce20..b3ddb4609b 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -164,6 +164,47 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
 
+#if OPENH264_VER_AT_LEAST(1, 7)
+if (avctx->sample_aspect_ratio.num && avctx->sample_aspect_ratio.den) {
+// Table E-1.
+static const AVRational sar_idc[] = {
+{   0,  0 }, // Unspecified (never written here).
+{   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 }, // Last 3 are unknown to openh264: {   4,  3 }, {   
3,  2 }, {   2,  1 },
+};
+static const ESampleAspectRatio asp_idc[] = {
+ASP_UNSPECIFIED,
+ASP_1x1,  ASP_12x11,   ASP_10x11,   ASP_16x11,
+ASP_40x33,ASP_24x11,   ASP_20x11,   ASP_32x11,
+ASP_80x33,ASP_18x11,   ASP_15x11,   ASP_64x33,
+ASP_160x99,
+};
+int num, den, i;
+
+av_reduce(, , avctx->sample_aspect_ratio.num,
+  avctx->sample_aspect_ratio.den, 65535);
+
+for (i = 1; i < FF_ARRAY_ELEMS(sar_idc); i++) {
+if (num == sar_idc[i].num &&
+den == sar_idc[i].den)
+break;
+}
+if (i == FF_ARRAY_ELEMS(sar_idc)) {
+param.sSpatialLayers[0].eAspectRatio = ASP_EXT_SAR;
+param.sSpatialLayers[0].sAspectRatioExtWidth = num;
+param.sSpatialLayers[0].sAspectRatioExtHeight = den;
+} else {
+param.sSpatialLayers[0].eAspectRatio = asp_idc[i];
+}
+param.sSpatialLayers[0].bAspectRatioPresent = true;
+}
+else {
+param.sSpatialLayers[0].bAspectRatioPresent = false;
+}
+#endif
+
 if ((avctx->slices > 1) && (s->max_nal_size)) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid combination -slices %d and -max_nal_size %d.\n",
-- 
2.15.1.windows.2

___
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

2018-11-01 Thread Valery Kot 
> 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 
> .

Thanks for the suggestion! Here is an updated patch.
From 7af627f923530d51a51b7630919df0da92f8b71d Mon Sep 17 00:00:00 2001
From: vkot 
Date: Thu, 1 Nov 2018 13:32:21 +0100
Subject: [PATCH] Handle sample_aspect_ratio in libopenh264 encoder

---
 libavcodec/libopenh264enc.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 83c3f0ce20..c0ecdb2472 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -164,6 +164,47 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
 
+#if OPENH264_VER_AT_LEAST(1, 7)
+if (avctx->sample_aspect_ratio.num && avctx->sample_aspect_ratio.den) {
+// Table E-1.
+static const AVRational sar_idc[] = {
+{   0,  0 }, // Unspecified (never written here).
+{   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 }, // Last 3 are unknown to openh264: {   4,  3 }, {   
3,  2 }, {   2,  1 },
+};
+static const ESampleAspectRatio asp_idc[] = {
+ASP_UNSPECIFIED,
+ASP_1x1,  ASP_12x11,   ASP_10x11,   ASP_16x11,
+ASP_40x33,ASP_24x11,   ASP_20x11,   ASP_32x11,
+ASP_80x33,ASP_18x11,   ASP_15x11,   ASP_64x33,
+ASP_160x99,
+};
+int num, den, i;
+
+av_reduce(, , avctx->sample_aspect_ratio.num,
+  avctx->sample_aspect_ratio.den, 65535);
+
+for (i = 1; i < FF_ARRAY_ELEMS(sar_idc); i++) {
+if (num == sar_idc[i].num &&
+den == sar_idc[i].den)
+break;
+}
+if (i == FF_ARRAY_ELEMS(sar_idc)) {
+param.sSpatialLayers[0].eAspectRatio = ASP_EXT_SAR;
+param.sSpatialLayers[0].sAspectRatioExtWidth = 
avctx->sample_aspect_ratio.num;
+param.sSpatialLayers[0].sAspectRatioExtHeight = 
avctx->sample_aspect_ratio.den;
+} else {
+param.sSpatialLayers[0].eAspectRatio = asp_idc[i];
+}
+param.sSpatialLayers[0].bAspectRatioPresent = true;
+}
+else {
+param.sSpatialLayers[0].bAspectRatioPresent = false;
+}
+#endif
+
 if ((avctx->slices > 1) && (s->max_nal_size)) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid combination -slices %d and -max_nal_size %d.\n",
-- 
2.15.1.windows.2

___
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

2018-10-31 Thread Valery Kot 
> > 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-10-31 Thread Valery Kot 
On advise of Carl Eugen, I am asking to add me as a maintainer for
libopenh264 codec.
Apparently nobody else is maintainig it, and I am actively using and
patching it.
From d5d6b09d5adf3025614f69c3be4e108c9a42d387 Mon Sep 17 00:00:00 2001
From: vkot 
Date: Wed, 31 Oct 2018 15:06:14 +0100
Subject: [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  Arttu Ylä-Outinen
   libopenjpeg.c Jaikrishnan Menon
   libopenjpegenc.c  Michael Bradshaw
+  libopenh264*  Valery Kot
   libtheoraenc.cDavid Conrad
   libvorbis.c   David Conrad
   libvpx*   James Zern
-- 
2.15.1.windows.2

___
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

2018-10-31 Thread Valery Kot 
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:
> >
> > A gentle ping...
___
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

2018-10-24 Thread Valery Kot 
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 gentle ping...
___
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

2018-10-18 Thread Valery Kot 
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
> in weird display aspect ratio for non-square pixels on some players.
>
> Proposed patch fixes that, if FFmpeg being build against libopenh264
> 1.7 or newer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-10-12 Thread Valery Kot 
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

2018-10-12 Thread Valery Kot 
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, if FFmpeg being build against libopenh264
1.7 or newer.
From 2d22329e01b892576b856806c93d484c304f11d8 Mon Sep 17 00:00:00 2001
From: vkot 
Date: Fri, 12 Oct 2018 09:02:59 +0200
Subject: [PATCH] Handle sample_aspect_ratio in libopenh264 encoder

---
 libavcodec/libopenh264enc.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 83c3f0ce20..c630dff33c 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -164,6 +164,32 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
 
+#if OPENH264_VER_AT_LEAST(1, 7)
+if(avctx->sample_aspect_ratio.num == 0 || avctx->sample_aspect_ratio.den 
== 0)
+param.sSpatialLayers[0].bAspectRatioPresent = false;
+else {
+param.sSpatialLayers[0].bAspectRatioPresent = true;
+if  (!av_cmp_q(av_make_q( 1,  1), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_1x1;
+else if (!av_cmp_q(av_make_q(12, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_12x11;
+else if (!av_cmp_q(av_make_q(10, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_10x11;
+else if (!av_cmp_q(av_make_q(16, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_16x11;
+else if (!av_cmp_q(av_make_q(40, 33), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_40x33;
+else if (!av_cmp_q(av_make_q(24, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_24x11;
+else if (!av_cmp_q(av_make_q(20, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_20x11;
+else if (!av_cmp_q(av_make_q(32, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_32x11;
+else if (!av_cmp_q(av_make_q(80, 33), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_80x33;
+else if (!av_cmp_q(av_make_q(18, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_18x11;
+else if (!av_cmp_q(av_make_q(15, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_15x11;
+else if (!av_cmp_q(av_make_q(64, 33), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_64x33;
+else if (!av_cmp_q(av_make_q(160,99), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_160x99;
+else {
+param.sSpatialLayers[0].eAspectRatio = ASP_EXT_SAR;
+param.sSpatialLayers[0].sAspectRatioExtWidth = 
avctx->sample_aspect_ratio.num;
+param.sSpatialLayers[0].sAspectRatioExtHeight = 
avctx->sample_aspect_ratio.den;
+}
+}
+#endif
+
 if ((avctx->slices > 1) && (s->max_nal_size)) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid combination -slices %d and -max_nal_size %d.\n",
-- 
2.15.1.windows.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] avcodec/libopenh264enc.c

2018-10-11 Thread Valery Kot 
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 being build against libopenh264
1.7 or newer.

---
 libavcodec/libopenh264enc.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 83c3f0ce20..6d4d9e6192 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -164,6 +164,32 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;

+#if OPENH264_VER_AT_LEAST(1, 7)
+if(avctx->sample_aspect_ratio.num == 0 ||
avctx->sample_aspect_ratio.den == 0)
+param.sSpatialLayers[0].bAspectRatioPresent = false;
+else {
+param.sSpatialLayers[0].bAspectRatioPresent = true;
+if  (!av_cmp_q(av_make_q( 1,  1),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_1x1;
+else if (!av_cmp_q(av_make_q(12, 11),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_12x11;
+else if (!av_cmp_q(av_make_q(10, 11),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_10x11;
+else if (!av_cmp_q(av_make_q(16, 11),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_16x11;
+else if (!av_cmp_q(av_make_q(40, 33),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_40x33;
+else if (!av_cmp_q(av_make_q(24, 11),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_24x11;
+else if (!av_cmp_q(av_make_q(20, 11),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_20x11;
+else if (!av_cmp_q(av_make_q(32, 11),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_32x11;
+else if (!av_cmp_q(av_make_q(80, 33),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_80x33;
+else if (!av_cmp_q(av_make_q(18, 11),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_18x11;
+else if (!av_cmp_q(av_make_q(15, 11),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_15x11;
+else if (!av_cmp_q(av_make_q(64, 33),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_64x33;
+else if (!av_cmp_q(av_make_q(160,99),
avctx->sample_aspect_ratio))  param.sSpatialLayers[0].eAspectRatio =
ASP_160x99;
+else {
+param.sSpatialLayers[0].eAspectRatio = ASP_EXT_SAR;
+param.sSpatialLayers[0].sAspectRatioExtWidth =
avctx->sample_aspect_ratio.num;
+param.sSpatialLayers[0].sAspectRatioExtHeight =
avctx->sample_aspect_ratio.den;
+}
+}
+#endif
+
 if ((avctx->slices > 1) && (s->max_nal_size)) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid combination -slices %d and -max_nal_size %d.\n",
-- 
2.15.1.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] avcodec/libopenh264enc.c

2018-10-11 Thread Valery Kot 
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 being build against libopenh264
1.7 or newer.


0001-Set-sample-aspect-ratio-in-libopenh264-encoder.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-04-06 Thread Valery Kot 
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?
>>
>> Doesn't appear to be so.
>>
>>> If yes - can he or she please review my patch. If no - how does
>>> maintenance works for "orphaned" modules?
>>
>> Any developer simply decides to review, approve, and/or push it. Sorry for 
>> the wait, but I recommend pinging this thread once a week until so.
>>
>> If it has been a while make sure your patch still applies cleanly to the git 
>> master branch before pinging. Otherwise please provide an updated patch.
>
> Pushed it. It's been a month and with no maintainer and apparently no
> devs using this module it's clear nobody is going to look at it.

Thanks, appreciated!

If needed, I volunteer to be a maintainer for libopenh264*, as I am
actively using this codec.

Valery
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-03-26 Thread Valery Kot 
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.
>>
>> Friendly ping to maintainers to review and pull the patch.
>>
>> Valery
>
> Another ping.
Just wondering: is there an active maintainer for avcodec/libopenh264?
If yes - can he or she please review my patch. If no - how does
maintenance works for "orphaned" modules?
I really need my patch in.
PLEASE!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-03-20 Thread Valery Kot 
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.
>
> Valery

Another ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-03-16 Thread Valery Kot 
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 changes.
>
> Another whitespace nit:
>
> >  if (frame->pict_type==AV_PICTURE_TYPE_I) {
>
> Please use single spaces around operators, i.e.
>   if (frame->pict_type == AV_PICTURE_TYPE_I) {
>
> Moritz

Attached is an updated patch incorporating all feedback - only
formatting for now.

Friendly ping to maintainers to review and pull the patch.

Valery
From 8334dfcea924ac687783d2ad7685ad143a2f1a26 Mon Sep 17 00:00:00 2001
From: vkot 
Date: Fri, 16 Mar 2018 14:50:34 +0100
Subject: [PATCH v2] avcodec/openh264enc.c: generate IDR frame in response to I
 frame pict_type

Signed-off-by: vkot 
---
 libavcodec/libopenh264enc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index fdadb101f5..83c3f0ce20 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -246,6 +246,10 @@ static int svc_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 sp.iPicWidth  = avctx->width;
 sp.iPicHeight = avctx->height;
 
+if (frame->pict_type == AV_PICTURE_TYPE_I) {
+(*s->encoder)->ForceIntraFrame(s->encoder, true);
+}
+
 encoded = (*s->encoder)->EncodeFrame(s->encoder, , );
 if (encoded != cmResultSuccess) {
 av_log(avctx, AV_LOG_ERROR, "EncodeFrame failed\n");
-- 
2.15.1.windows.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-03-12 Thread Valery Kot 
Got it. Do I have to post an updated patch as a reply to this thread?

Valery
_
From: Lou Logan <l...@lrcd.com>
Sent: Monday, March 12, 2018 10:20 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 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
> Subject: [PATCH 3/3] avcodec/openh264enc.c: generate IDR frame in response to
> I frame pict_type
>
> ---
> libavcodec/libopenh264enc.c | 4 
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> index fdadb101f5..12e9ad49ed 100644
> --- a/libavcodec/libopenh264enc.c
> +++ b/libavcodec/libopenh264enc.c
> @@ -245,6 +245,10 @@ static int svc_encode_frame(AVCodecContext *avctx, 
> AVPacket *avpkt,
> }
> sp.iPicWidth = avctx->width;
> sp.iPicHeight = avctx->height;
> +

The above line has trailing whitespace which should be avoided. You can
use tools/patcheck to check, and git should provide a warning when
applying the patch.
___
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] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

2018-03-12 Thread Valery Kot 

_
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, Valery Kot wrote:
>> Could somebody please take a look into my patch? Or is it somehow invisible
>> / badly formatted?
>>
>> It allows for inducing key frames at proper moments by e.g.
>> -force_key_frames, while using openH264 codec. Thus accurate HLS with LGPL
>> license, which is important for us.

>Hi,

>> + if (frame->pict_type==AV_PICTURE_TYPE_I) {
>> + (*s->encoder)->ForceIntraFrame(s->encoder, true);
>> + }

> Does openh264 differentiate between I and IDR frames in its API, like libx264
> and libx265 do?

> - Derek

Hey, somebody is seeing my mails. Cool!

As far as I see, ForceIntraFrame() is the only API to set type for a particular 
frame. And (confusingly) description says that it will be an IDR frame. Fair 
enough: if there is only one possible type they allow, then IDR is the most 
user-wanted type.

API EncodeFrame() returns  pBsInf->eFrameType, which can be IDR, I, or P frame 
flag. So apparently internally openH264 makes a distinction between I frames 
and IDR. But this is an output parameter, and it’s original value set by user 
is ignored.

Valery
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-03-12 Thread Valery Kot 
Gents,

Could somebody please take a look into my patch? Or is it somehow invisible
/ badly formatted?

It allows for inducing key frames at proper moments by e.g.
-force_key_frames, while using openH264 codec. Thus accurate HLS with LGPL
license, which is important for us.

Valery

On Monday, 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 patch fixes it.
>
> Valery
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-03-05 Thread Valery Kot 
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: 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

---
 libavcodec/libopenh264enc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index fdadb101f5..12e9ad49ed 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -245,6 +245,10 @@ static int svc_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 }
 sp.iPicWidth  = avctx->width;
 sp.iPicHeight = avctx->height;
+
+if (frame->pict_type==AV_PICTURE_TYPE_I) {
+(*s->encoder)->ForceIntraFrame(s->encoder, true);
+}
 
 encoded = (*s->encoder)->EncodeFrame(s->encoder, , );
 if (encoded != cmResultSuccess) {
-- 
2.15.1.windows.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel