Re: [FFmpeg-devel] Pull requests

[Bjorn Roche]

On Tue, Feb 27, 2018 at 5:47 AM, wm4  wrote:

> On Mon, 26 Feb 2018 17:15:26 -0500
> Bjorn Roche  wrote:
>
> > Okay, thanks Nicolas.
> >
> > I already submitted a patch to the mailing list a few months ago, I was
> > just hoping for an easier way to keep it fresh since it's gone stale,
> and I
> > had some more fixes for it.
>
> Just ping it a few times or resend it. It's pretty easy for patches to
> get lost/ignored, but we don't use the github mirror's PR system at
> all. Github merely doesn't let us disable it.


There was a fair bit of very helpful discussion, so it was not ignored, but
the relevant maintainer on that code never commented. I emailed him
privately and got nothing, nor have I seen him on the mailing list. I was
just hoping you guys now accepted PRs so it would be easier for us to keep
it fresh.

bjorn

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] Pull requests

[Paul B Mahol]

On 2/27/18, Bjorn Roche  wrote:
> On Tue, Feb 27, 2018 at 10:34 AM, Paul B Mahol  wrote:
>
>> On 2/27/18, Bjorn Roche  wrote:
>> > On Tue, Feb 27, 2018 at 5:47 AM, wm4  wrote:
>> >
>> >> On Mon, 26 Feb 2018 17:15:26 -0500
>> >> Bjorn Roche  wrote:
>> >>
>> >> > Okay, thanks Nicolas.
>> >> >
>> >> > I already submitted a patch to the mailing list a few months ago, I
>> was
>> >> > just hoping for an easier way to keep it fresh since it's gone stale,
>> >> and I
>> >> > had some more fixes for it.
>> >>
>> >> Just ping it a few times or resend it. It's pretty easy for patches to
>> >> get lost/ignored, but we don't use the github mirror's PR system at
>> >> all. Github merely doesn't let us disable it.
>> >
>> >
>> > There was a fair bit of very helpful discussion, so it was not ignored,
>> but
>> > the relevant maintainer on that code never commented. I emailed him
>> > privately and got nothing, nor have I seen him on the mailing list. I
>> > was
>> > just hoping you guys now accepted PRs so it would be easier for us to
>> keep
>> > it fresh.
>>
>> Please, keep pinging relevant patch. Current maintainer is very busy.
>>
>
> To be honest, I don't see the point if the one person who can approve is
> not going to look at it. It takes a fair bit of time to freshen and prepare
> these patches for email.

Ping does not mean to freshen patch.

>
> --
>
>
> Bjorn Roche
>
> Sr. Video Pipeline Engineer
>
> bj...@giphy.com
> ___
> 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] Pull requests

[Nicolas George]

Bjorn Roche (2018-02-27):
> According to Carl Eugen Hoyos: "This is Clément's code, he has to review
> your patch."

Then reply to Carl Eugen's mail to say "Clément does not seem to care
these days", to re-start the discussion.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Pull requests

[James Almer]

On 2/27/2018 1:28 PM, Bjorn Roche wrote:
> On Tue, Feb 27, 2018 at 10:34 AM, wm4  wrote:
> 
>> On Tue, 27 Feb 2018 10:25:17 -0500
>> Bjorn Roche  wrote:
>>
>>> On Tue, Feb 27, 2018 at 5:47 AM, wm4  wrote:
>>>
 On Mon, 26 Feb 2018 17:15:26 -0500
 Bjorn Roche  wrote:

> Okay, thanks Nicolas.
>
> I already submitted a patch to the mailing list a few months ago, I
>> was
> just hoping for an easier way to keep it fresh since it's gone stale,
 and I
> had some more fixes for it.

 Just ping it a few times or resend it. It's pretty easy for patches to
 get lost/ignored, but we don't use the github mirror's PR system at
 all. Github merely doesn't let us disable it.
>>>
>>>
>>> There was a fair bit of very helpful discussion, so it was not ignored,
>> but
>>> the relevant maintainer on that code never commented. I emailed him
>>> privately and got nothing, nor have I seen him on the mailing list. I was
>>> just hoping you guys now accepted PRs so it would be easier for us to
>> keep
>>> it fresh.
>>
>> The MAINTAINERS file is usually stale and outdated, so just ask whether
>> someone else can push it.
> 
> Jan 16
> 
> According to Carl Eugen Hoyos: "This is Clément's code, he has to review
> your patch."

He's on vacations, so that'd explain why he hasn't looked at it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] fftools/ffmpeg: fix progress log message in case pts is not available

[Michael Niedermayer]

On Tue, Feb 27, 2018 at 08:49:19AM +0100, Tobias Rapp wrote:
> On 27.02.2018 01:12, Michael Niedermayer wrote:
> >On Mon, Feb 26, 2018 at 05:09:04PM +0100, Tobias Rapp wrote:
> >>Move time string formatting into inline function. Also fixes out_time
> >>sign prefix for progress report.
> >>
> >>Signed-off-by: Tobias Rapp 
> >>---
> >>  fftools/ffmpeg.c | 48 +++-
> >>  1 file changed, 31 insertions(+), 17 deletions(-)
> >>
> >>diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >>index 32caa4b..0097a7d 100644
> >>--- a/fftools/ffmpeg.c
> >>+++ b/fftools/ffmpeg.c
> >>@@ -1518,6 +1518,27 @@ static int reap_filters(int flush)
> >>  return 0;
> >>  }
> >>+static inline char *pts_to_hms_str(char *buf, int64_t pts, unsigned int 
> >>digits)
> >
> >char buf[AV_TS_MAX_STRING_SIZE]
> >
> >or the buf size should be passed too, in fact this might be better anyway
> 
> Will change.
> 
> >>+{
> >>+const char *hours_sign;
> >>+int hours, mins;
> >>+double secs;
> >>+
> >>+if (pts == AV_NOPTS_VALUE) {
> >>+snprintf(buf, AV_TS_MAX_STRING_SIZE, "N/A");
> >>+} else {
> >>+hours_sign = (pts < 0) ? "-" : "";
> >>+secs = (double)FFABS(pts) / AV_TIME_BASE;
> >>+mins = (int)secs / 60;
> >>+secs = secs - mins * 60;
> >>+hours = mins / 60;
> >>+mins %= 60;
> >
> >This is not the same code, also with double it can produce inexact
> >results and results differing between platforms
> 
> I changed secs to double to handle the cases with different number of
> sub-second digits more easily. Would it be OK to output two digits after the
> decimal point in both cases? The progress report contains the precise
> out_time_ms value anyway.

iam not sure iam guessing correctly what you mean by "both cases"
you mean if its unneeded as in .00 ?
I guess that would be ok 

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Pull requests

[Bjorn Roche]

On Tue, Feb 27, 2018 at 10:34 AM, Paul B Mahol  wrote:

> On 2/27/18, Bjorn Roche  wrote:
> > On Tue, Feb 27, 2018 at 5:47 AM, wm4  wrote:
> >
> >> On Mon, 26 Feb 2018 17:15:26 -0500
> >> Bjorn Roche  wrote:
> >>
> >> > Okay, thanks Nicolas.
> >> >
> >> > I already submitted a patch to the mailing list a few months ago, I
> was
> >> > just hoping for an easier way to keep it fresh since it's gone stale,
> >> and I
> >> > had some more fixes for it.
> >>
> >> Just ping it a few times or resend it. It's pretty easy for patches to
> >> get lost/ignored, but we don't use the github mirror's PR system at
> >> all. Github merely doesn't let us disable it.
> >
> >
> > There was a fair bit of very helpful discussion, so it was not ignored,
> but
> > the relevant maintainer on that code never commented. I emailed him
> > privately and got nothing, nor have I seen him on the mailing list. I was
> > just hoping you guys now accepted PRs so it would be easier for us to
> keep
> > it fresh.
>
> Please, keep pinging relevant patch. Current maintainer is very busy.
>

To be honest, I don't see the point if the one person who can approve is
not going to look at it. It takes a fair bit of time to freshen and prepare
these patches for email.

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] compat: remove in-tree NVidia headers

[Nicolas George]

Timo Rothenpieler (2018-02-27):
> compat: remove in-tree NVidia headers

Unless I was mistaken, there was no consensus for that yet.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Timo Rothenpieler]

+cuda_deps="ffnvcodec">  cuda_deps_any="libdl LoadLibrary"
  cuvid_deps="cuda"
  d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext"
@@ -5811,6 +5812,9 @@ check_type "va/va.h va/va_enc_vp9.h"  
"VAEncPictureParameterBufferVP9"
  
  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
  
+check_pkg_config ffnvcodec "ffnvcodec >= 8.0" \


Instead of adding a new ffnvcodec module to configure, just use the
existing cuda one.



Indeed.
Changed to that, tested on Linux, Cygwin, MinGW and MSVC.
Fix for MSVC has been pushed to the headers repository.

Patch applied.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Pull requests

[Paul B Mahol]

On 2/27/18, Bjorn Roche  wrote:
> On Tue, Feb 27, 2018 at 5:47 AM, wm4  wrote:
>
>> On Mon, 26 Feb 2018 17:15:26 -0500
>> Bjorn Roche  wrote:
>>
>> > Okay, thanks Nicolas.
>> >
>> > I already submitted a patch to the mailing list a few months ago, I was
>> > just hoping for an easier way to keep it fresh since it's gone stale,
>> and I
>> > had some more fixes for it.
>>
>> Just ping it a few times or resend it. It's pretty easy for patches to
>> get lost/ignored, but we don't use the github mirror's PR system at
>> all. Github merely doesn't let us disable it.
>
>
> There was a fair bit of very helpful discussion, so it was not ignored, but
> the relevant maintainer on that code never commented. I emailed him
> privately and got nothing, nor have I seen him on the mailing list. I was
> just hoping you guys now accepted PRs so it would be easier for us to keep
> it fresh.

Please, keep pinging relevant patch. Current maintainer is very busy.

>
> bjorn
>
> --
>
>
> Bjorn Roche
>
> Sr. Video Pipeline Engineer
>
> bj...@giphy.com
> ___
> 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 v2 2/2] fftools/ffmpeg: update print_report to use AVBPrint API

[Nicolas George]

Tobias Rapp (2018-02-26):
> Signed-off-by: Tobias Rapp 
> ---
>  fftools/ffmpeg.c | 44 
>  1 file changed, 20 insertions(+), 24 deletions(-)

LGTM.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Pull requests

[wm4]

On Tue, 27 Feb 2018 10:25:17 -0500
Bjorn Roche  wrote:

> On Tue, Feb 27, 2018 at 5:47 AM, wm4  wrote:
> 
> > On Mon, 26 Feb 2018 17:15:26 -0500
> > Bjorn Roche  wrote:
> >  
> > > Okay, thanks Nicolas.
> > >
> > > I already submitted a patch to the mailing list a few months ago, I was
> > > just hoping for an easier way to keep it fresh since it's gone stale,  
> > and I  
> > > had some more fixes for it.  
> >
> > Just ping it a few times or resend it. It's pretty easy for patches to
> > get lost/ignored, but we don't use the github mirror's PR system at
> > all. Github merely doesn't let us disable it.  
> 
> 
> There was a fair bit of very helpful discussion, so it was not ignored, but
> the relevant maintainer on that code never commented. I emailed him
> privately and got nothing, nor have I seen him on the mailing list. I was
> just hoping you guys now accepted PRs so it would be easier for us to keep
> it fresh.

The MAINTAINERS file is usually stale and outdated, so just ask whether
someone else can push it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] compat: remove in-tree NVidia headers

[Hendrik Leppkes]

On Tue, Feb 27, 2018 at 4:24 PM, Nicolas George  wrote:
> Timo Rothenpieler (2018-02-27):
>> compat: remove in-tree NVidia headers
>
> Unless I was mistaken, there was no consensus for that yet.
>

The issue holding up the patch was fixed, so who was still objecting?

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

[FFmpeg-devel] [PATCH 2/2] avcodec/nuv: Check for minimum input size for uncomprssed and rtjpeg

[Michael Niedermayer]

Fixes: Timeout
Fixes: 
6297/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-4882404863901696

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/nuv.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/nuv.c b/libavcodec/nuv.c
index 15165ae3f5..32ed65899b 100644
--- a/libavcodec/nuv.c
+++ b/libavcodec/nuv.c
@@ -161,6 +161,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 int orig_size  = buf_size;
 int keyframe, ret;
 int size_change = 0;
+int minsize = 0;
 int result, init_frame = !avctx->frame_number;
 enum {
 NUV_UNCOMPRESSED  = '0',
@@ -209,6 +210,16 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 keyframe = 1;
 break;
 }
+switch (comptype) {
+case NUV_UNCOMPRESSED:
+minsize = c->width * c->height * 3 / 2;
+break;
+case NUV_RTJPEG:
+minsize = c->width/16 * (c->height/16) * 6;
+break;
+}
+if (buf_size < minsize / 4)
+return AVERROR_INVALIDDATA;
 retry:
 // Skip the rest of the frame header.
 buf   = [12];
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 1/2] avcodec/nuv: rtjpeg with dimensions less than 16 would result in no decoded pixels thus reject it

[Michael Niedermayer]

Fixes: Timeout
Fixes: 
6297/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-4882404863901696

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/nuv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/nuv.c b/libavcodec/nuv.c
index ad6c029e50..15165ae3f5 100644
--- a/libavcodec/nuv.c
+++ b/libavcodec/nuv.c
@@ -198,6 +198,9 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 case NUV_RTJPEG_IN_LZO:
 case NUV_RTJPEG:
 keyframe = !buf[2];
+if (c->width < 16 || c->height < 16) {
+return AVERROR_INVALIDDATA;
+}
 break;
 case NUV_COPY_LAST:
 keyframe = 0;
-- 
2.16.2

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

Re: [FFmpeg-devel] Pull requests

[Bjorn Roche]

On Tue, Feb 27, 2018 at 10:34 AM, wm4  wrote:

> On Tue, 27 Feb 2018 10:25:17 -0500
> Bjorn Roche  wrote:
>
> > On Tue, Feb 27, 2018 at 5:47 AM, wm4  wrote:
> >
> > > On Mon, 26 Feb 2018 17:15:26 -0500
> > > Bjorn Roche  wrote:
> > >
> > > > Okay, thanks Nicolas.
> > > >
> > > > I already submitted a patch to the mailing list a few months ago, I
> was
> > > > just hoping for an easier way to keep it fresh since it's gone stale,
> > > and I
> > > > had some more fixes for it.
> > >
> > > Just ping it a few times or resend it. It's pretty easy for patches to
> > > get lost/ignored, but we don't use the github mirror's PR system at
> > > all. Github merely doesn't let us disable it.
> >
> >
> > There was a fair bit of very helpful discussion, so it was not ignored,
> but
> > the relevant maintainer on that code never commented. I emailed him
> > privately and got nothing, nor have I seen him on the mailing list. I was
> > just hoping you guys now accepted PRs so it would be easier for us to
> keep
> > it fresh.
>
> The MAINTAINERS file is usually stale and outdated, so just ask whether
> someone else can push it.

Jan 16

According to Carl Eugen Hoyos: "This is Clément's code, he has to review
your patch."

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] compat: remove in-tree NVidia headers

[Timo Rothenpieler]

Am 27.02.2018 um 16:24 schrieb Nicolas George:

Timo Rothenpieler (2018-02-27):

compat: remove in-tree NVidia headers


Unless I was mistaken, there was no consensus for that yet.


From how I understood the discussion the only issue people had was that 
it was still not pushed, with MSVC holding it back. The MSVC issue is 
now fixed, the patches have been on the list since December.


The discussion about whether to keep or remove the nvidia headers from 
the tree has happened months ago and ended up with them to be moved to 
where they are now.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] compat: remove in-tree NVidia headers

[Nicolas George]

Hendrik Leppkes (2018-02-27):
> The issue holding up the patch was fixed, so who was still objecting?

You were still objecting. The fact that is was resolved had not been
made public when I posted my message.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/dashenc: Use HTTP DELETE for HTTP base proto

[Serhii Marchuk]

---
 libavformat/dashenc.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 83e0cff728..66f12d8d49 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1131,6 +1131,28 @@ static int update_stream_extradata(AVFormatContext *s, 
OutputStream *os,
 return 0;
 }
 
+static void dashenc_delete_file(AVFormatContext *s, char *filename) {
+DASHContext *c = s->priv_data;
+int http_base_proto = ff_is_http_proto(filename);
+
+if (http_base_proto) {
+AVIOContext *out = NULL;
+AVDictionary *http_opts = NULL;
+
+set_http_options(_opts, c);
+av_dict_set(_opts, "method", "DELETE", 0);
+
+if (dashenc_io_open(s, , filename, _opts) < 0) {
+av_log(s, AV_LOG_ERROR, "failed to delete %s\n", filename);
+}
+
+av_dict_free(_opts);
+dashenc_io_close(s, , filename);
+} else if (unlink(filename) < 0) {
+av_log(s, AV_LOG_ERROR, "failed to delete %s: %s\n", filename, 
strerror(errno));
+}
+}
+
 static int dash_flush(AVFormatContext *s, int final, int stream)
 {
 DASHContext *c = s->priv_data;
@@ -1215,7 +1237,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 for (j = 0; j < remove; j++) {
 char filename[1024];
 snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
os->segments[j]->file);
-unlink(filename);
+dashenc_delete_file(s, filename);
 av_free(os->segments[j]);
 }
 os->nb_segments -= remove;
@@ -1367,9 +1389,9 @@ static int dash_write_trailer(AVFormatContext *s)
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
 snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
os->initfile);
-unlink(filename);
+dashenc_delete_file(s, filename);
 }
-unlink(s->url);
+dashenc_delete_file(s, s->url);
 }
 
 return 0;
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/proresenc_anatoliy: change quantization scaling to floating point to utilize vectorization

[David Murmann]

On 2/27/2018 9:58 PM, Hendrik Leppkes wrote:
> On Tue, Feb 27, 2018 at 9:35 PM, David Murmann  
wrote:

>> Quantization scaling seems to be a slight bottleneck,
>> this change allows the compiler to more easily vectorize
>> the loop. This improves total encoding performance in my
>> tests by about 10-20%.
>>
>> Signed-off-by: David Murmann 
>> ---
>>   libavcodec/proresenc_anatoliy.c | 12 
>>   1 file changed, 8 insertions(+), 4 deletions(-)
>>
[...]
>> +for (j = 0; j < blocks_per_slice; j++) {
>> +for (i = 0; i < 64; i++) {
>> +block[i] = (float)in[(j << 6) + i] / (float)qmat[i];
>> +}
>> +
>> +for (i = 1; i < 64; i++) {
>> +int val = block[progressive_scan[i]];
>>   if (val) {
>>   encode_codeword(pb, run, run_to_cb[FFMIN(prev_run, 
15)]);

>
> Usually, using float is best avoided. Did you test re-factoring the
> loop structure without changing it to float?

Yes, the vector instructions don't have integer division, AFAIK, and the
compiler just generates a loop with idivs. This is quite a bit slower
than converting to float, dividing and converting back, if the compiler
uses vector instructions. In the general case this wouldn't be exact,
but since the input values are int16 they should losslessly fit into
float32. On platforms where this auto-vectorization fails this might
actually be quite a bit slower, but I have not seen that in my tests
(though I have only tested on x86_64).

--
David Murmann

da...@btf.de
Telefon +49 (0) 221 82008710
Fax +49 (0) 221 82008799

http://btf.de/

--
btf GmbH | Leyendeckerstr. 27, 50825 Köln | +49 (0) 221 82 00 87 10
Geschäftsführer: Philipp Käßbohrer & Matthias Murmann | HR Köln | HRB 74707
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC

[Nicolas George]

Hi, and welcome back.

Stephan Holljes (2018-02-26):
> seeing that people are already applying for projects, I think I should as 
> well.
> 
> My name is Stephan Holljes, on IRC I go by klaxa. Some may remember me
> from GSoC 2015 where I implemented the (how I later found out
> controversly debated) HTTP-Server API.
> 
> Since someone else already applied for the DICOM project, which I
> would also like to do, maybe instead I could work on an ffserver
> replacement, since it has been dropped recently. Maybe some have
> already seen my mkv-server (https://github.com/klaxa/mkvserver_mk2/)
> which was mentioned a few times on the ML. I think it could serve as a
> starting point, since it already only uses the public API.

I do not know what features you have in mind exactly for this project,
but it reminds me of a pet project that I have: a muxer that acts as a
multi-clients server.

It would work like the tee muxer: frames sent to the muxer are
duplicated and re-muxed into several slave muxers. The difference is be
that the list of slave muxers is not set at the beginning but evolves
when clients connect and disconnect.

I have not given much thought on the way of doing it expressive enough
so that it would not be just a toy. Using programs to allow the server
to provide different streams? Using attachments to send non-live files?

Anyway, if somebody wants to achieve anything in that direction within
the FFmpeg project, I am pretty sure it would require a big cleanup of
the inconsistent mess that is the network code currently.

Due to personal stuff, I do not feel up to offering mentoring this year
either, but I can share my thoughts on the issue and help as much as I
can.

The big but not-that-hard part of the issue would be to design and
implement a real event loop with enough features.

It needs to be able to run things in separate threads when they need to
react with low latency. That is the infamous "UDP thread". Note that a
single thread should be able to handle several low-latency network
streams, if it is not burdened by heavy computation at the same time.

It needs to be able to run things in separate threads to integrate
protocols that have not been integrated with it. Lightweight
collaborative threads could be used, but they do not seem to exist with
an up-to-date portable API.

Protocols that rely on sub-protocols (HTTP→TCP, RTP→UDP, etc.) need to
be updated to make use of the even loop instead of querying directly
their slaves. Protocols will probably need to be attached to an event
loop.

That means having an event loop will be mandatory when using the current
AVIO API: its implementation must be updated to create one on the fly as
needed. But they need to be deprecated too.

Some work need to be done on demuxers to make them non-blocking. I think
the best approach is to keep using the push/pull pattern: instead of
providing an AVIO to a demuxer, push it data as it arrives, and then try
to read the frames, or maybe rely on a callback.

Demuxers that have not been updated for that API and rely heavily on
blocking reads of the exact amount of data they need will probably need
to be run in separate threads (again, if we could have lightweight
threads…).

All this is only the skeleton of the ideas I have accumulated for these
issues. It would make very interesting and stimulating work.
Unfortunately, I do not have the time to work on it at the time. Nor do
I have the energy to fight all the negativity that such an endeavour
would elicit from some people. But if somebody is interested I would be
happy to share details about any part of the plan.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/g2meet: Check tile dimensions with av_image_check_size2()

[Michael Niedermayer]

On Thu, Feb 22, 2018 at 04:35:50AM +0100, Michael Niedermayer wrote:
> Fixes: OOM
> Fixes: 
> 6216/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-4983807968018432
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/g2meet.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

will apply patchset

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/exr: fix invalid shift in unpack_14()

[Michael Niedermayer]

On Wed, Feb 21, 2018 at 04:29:44AM +0100, Michael Niedermayer wrote:
> Fixes: 6154/clusterfuzz-testcase-minimized-5762231061970944
> Fixes: runtime error: shift exponent 63 is too large for 32-bit type 'int'
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/exr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/proresenc_anatoliy: change quantization scaling to floating point to utilize vectorization

[David Murmann]

Quantization scaling seems to be a slight bottleneck,
this change allows the compiler to more easily vectorize
the loop. This improves total encoding performance in my
tests by about 10-20%.

Signed-off-by: David Murmann 
---
 libavcodec/proresenc_anatoliy.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/libavcodec/proresenc_anatoliy.c 
b/libavcodec/proresenc_anatoliy.c

index 0516066163..8b296f6f1b 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -232,14 +232,18 @@ static const uint8_t lev_to_cb[10] = { 0x04, 0x0A, 
0x05, 0x06, 0x04, 0x28,

 static void encode_ac_coeffs(AVCodecContext *avctx, PutBitContext *pb,
 int16_t *in, int blocks_per_slice, int *qmat)
 {
+int16_t block[64];
 int prev_run = 4;
 int prev_level = 2;
  int run = 0, level, code, i, j;
-for (i = 1; i < 64; i++) {
-int indp = progressive_scan[i];
-for (j = 0; j < blocks_per_slice; j++) {
-int val = QSCALE(qmat, indp, in[(j << 6) + indp]);
+for (j = 0; j < blocks_per_slice; j++) {
+for (i = 0; i < 64; i++) {
+block[i] = (float)in[(j << 6) + i] / (float)qmat[i];
+}
+
+for (i = 1; i < 64; i++) {
+int val = block[progressive_scan[i]];
 if (val) {
 encode_codeword(pb, run, run_to_cb[FFMIN(prev_run, 15)]);
 -- 2.16.2


--
btf GmbH | Leyendeckerstr. 27, 50825 Köln | +49 (0) 221 82 00 87 10
Geschäftsführer: Philipp Käßbohrer & Matthias Murmann | HR Köln | HRB 74707
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Pull requests

[Bjorn Roche]

On Tue, Feb 27, 2018 at 11:55 AM, James Almer  wrote:

> On 2/27/2018 1:28 PM, Bjorn Roche wrote:
> > On Tue, Feb 27, 2018 at 10:34 AM, wm4  wrote:
> >
> > According to Carl Eugen Hoyos: "This is Clément's code, he has to review
> > your patch."
>
> He's on vacations, so that'd explain why he hasn't looked at it.
>

Thanks James. If no one else can look at it, I'll just resubmit when he
comes back.

bjorn

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] [PATCH] avcodec/proresenc_anatoliy: change quantization scaling to floating point to utilize vectorization

[Hendrik Leppkes]

On Tue, Feb 27, 2018 at 9:35 PM, David Murmann  wrote:
> Quantization scaling seems to be a slight bottleneck,
> this change allows the compiler to more easily vectorize
> the loop. This improves total encoding performance in my
> tests by about 10-20%.
>
> Signed-off-by: David Murmann 
> ---
>  libavcodec/proresenc_anatoliy.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c
> b/libavcodec/proresenc_anatoliy.c
> index 0516066163..8b296f6f1b 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -232,14 +232,18 @@ static const uint8_t lev_to_cb[10] = { 0x04, 0x0A,
> 0x05, 0x06, 0x04, 0x28,
>  static void encode_ac_coeffs(AVCodecContext *avctx, PutBitContext *pb,
>  int16_t *in, int blocks_per_slice, int *qmat)
>  {
> +int16_t block[64];
>  int prev_run = 4;
>  int prev_level = 2;
>   int run = 0, level, code, i, j;
> -for (i = 1; i < 64; i++) {
> -int indp = progressive_scan[i];
> -for (j = 0; j < blocks_per_slice; j++) {
> -int val = QSCALE(qmat, indp, in[(j << 6) + indp]);
> +for (j = 0; j < blocks_per_slice; j++) {
> +for (i = 0; i < 64; i++) {
> +block[i] = (float)in[(j << 6) + i] / (float)qmat[i];
> +}
> +
> +for (i = 1; i < 64; i++) {
> +int val = block[progressive_scan[i]];
>  if (val) {
>  encode_codeword(pb, run, run_to_cb[FFMIN(prev_run, 15)]);

Usually, using float is best avoided. Did you test re-factoring the
loop structure without changing it to float?

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

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

[王消寒]

Sure. Updated!

On Tue, Feb 27, 2018 at 2:38 AM, Michael Niedermayer  wrote:

> On Mon, Feb 26, 2018 at 10:37:51AM -0800, Xiaohan Wang (王消寒) wrote:
> > Thanks! Updated the patch. Please take a look again.
> >
> > On Sat, Feb 24, 2018 at 7:04 PM, Michael Niedermayer
>  > > wrote:
> >
> > > On Fri, Feb 23, 2018 at 05:12:05PM -0800, Xiaohan Wang (王消寒) wrote:
> > > > Michael: Dale and I dig into history a bit more and we don't
> understand
> > > why
> > > > the code is changed to the current state around memset. This new
> patch
> > > > reverted the change back to the previous state which we felt is much
> > > > cleaner. Please see the CL description for details and take a look
> at the
> > > > new patch. Thanks!
> > > >
> > > > On Wed, Feb 21, 2018 at 1:14 PM, Xiaohan Wang (王消寒) <
> xhw...@chromium.org
> > > >
> > > > wrote:
> > > >
> > > > > jstebbins: kindly ping!
> > > > >
> > > > > On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) <
> > > xhw...@chromium.org>
> > > > > wrote:
> > > > >
> > > > >> +jstebbins@ who wrote that code.
> > > > >>
> > > > >> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
> > > > >> mich...@niedermayer.cc> wrote:
> > > > >>
> > > > >>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒)
> wrote:
> > > > >>> >
> > > > >>>
> > > > >>> >  mov.c |3 ++-
> > > > >>> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
> > > > >>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
> > > > >>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17
> 00:00:00
> > > 2001
> > > > >>> > From: Xiaohan Wang 
> > > > >>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
> > > > >>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in
> > > > >>> mov_read_trun()
> > > > >>> >
> > > > >>> > The allocated size of sc->ctts_data is
> > > > >>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> > > > >>> >
> > > > >>> > The size to memset at offset sc->ctts_data + sc->ctts_count
> should
> > > be
> > > > >>> > (st->nb_index_entries + entries - sc->ctts_count) *
> > > > >>> sizeof(*sc->ctts_data))
> > > > >>> >
> > > > >>> > The current code missed |entries| I believe.
> > > > >>>
> > > > >>> shouldnt "entries" be read by this function later and so shouldnt
> > > need a
> > > > >>> memset?
> > > > >>> I didnt write this, but it looks a bit to me as if it was
> intended to
> > > > >>> only
> > > > >>> clear the area that would not be read later
> > > > >>>
> > > > >>
> > > > >> I thought we only had sc->ctts_count entries before
> av_fast_realloc,
> > > so
> > > > >> memset everything starting from sc->ctts_data + sc->ctts_count
> > > couldn't
> > > > >> go wrong. But I am not familiar with this code and that could
> totally
> > > be
> > > > >> wrong. I added jstebbins@ who wrote the code and hopefully we
> can get
> > > > >> expert opinion there.
> > > > >>
> > > > >>
> > > > >>> [...]
> > > > >>> --
> > > > >>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> > > 87040B0FAB
> > > > >>>
> > > > >>> No great genius has ever existed without some touch of madness.
> --
> > > > >>> Aristotle
> > > > >>>
> > > > >>> ___
> > > > >>> ffmpeg-devel mailing list
> > > > >>> ffmpeg-devel@ffmpeg.org
> > > > >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > >
> > > >  mov.c |5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > e5bbe55f0b1260f787f431b5c45e6ca49a7d2d1e
> 0001-Fix-memset-size-on-ctts_
> > > data-in-mov_read_trun-round-.patch
> > > > From f34b35ec5749c17b21f80665a0b8859bce3e84ab Mon Sep 17 00:00:00
> 2001
> > > > From: Xiaohan Wang 
> > > > Date: Fri, 23 Feb 2018 10:51:30 -0800
> > > > Subject: [PATCH] Fix memset size on ctts_data in mov_read_trun()
> (round
> > > 2)
> > > >
> > > > The allocated size of sc->ctts_data is
> > > > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> > > >
> > > > The size to memset at offset sc->ctts_data + sc->ctts_count should be
> > > > (st->nb_index_entries + entries - sc->ctts_count) *
> > > > sizeof(*sc->ctts_data))
> > > >
> > > > The current code missed |entries| I believe, which was introduced in
> > > > https://patchwork.ffmpeg.org/patch/5541/.
> > > >
> > > > However, after offline discussion, it seems the original code is much
> > > > more clear to read (before https://patchwork.ffmpeg.org/patch/5541/
> ).
> > > >
> > > > Hence this CL revert the memset logic to it's previous state by
> > > > remembering the |old_ctts_allocated_size|, and only memset the newly
> > > > allocated entries.
> > > > ---
> > > >  libavformat/mov.c | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > > index a3725692a7..f8d79c7b02 100644
> > > > --- 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/msmpeg4dec: Check for input end in msmpeg4v34_decode_mb()

[Michael Niedermayer]

On Mon, Feb 26, 2018 at 11:00:28PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 6276/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV1_fuzzer-5881196690014208
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/msmpeg4dec.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply patchset

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Super Resolution Filter development GSoC

[Swastik Haldar]

Hi everybody,
My name is Swastik Haldar. I am a third year undergrad at the Indian
Institute of Technology, Kharagpur. I would like to apply for image Super
Resolution Filter development for FFMPEG in GSoC '18.

I am currently working on the qualification task for this project. This
is my first involvement in an open source project so I am pretty excited
about this !

I go by the nick "basher666" on IRC. I can also be reached at my
alternate email - "swastik.hal...@iitkgp.ac.in".

Best Regards,
Swastik.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: support decoding up to 16 channels of xma

[Carl Eugen Hoyos]

2018-02-27 9:26 GMT+01:00 Maxton :
> I looked at the code in avcodec/wmaprodec.c and noticed that
> the maximum number of channels was set to 8, but I think this
> is a mistake as the number of channels should logically be
>
>   XMA_MAX_STREAMS * XMA_MAX_CHANNELS_STREAM

Doesn't your explanation indicate you should (move the definition
and) change "8" into this calculation?

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[wm4]

On Tue, 27 Feb 2018 12:27:10 +0100
Hendrik Leppkes  wrote:

> On Tue, Feb 27, 2018 at 12:13 PM, Nicolas George  wrote:
> > Hendrik Leppkes (2018-02-27):  
> >> Something works today, you want to refactor it, you get to keep it
> >> working. Its a simple rule.  
> >
> > It is a simple rule, but not one that must be followed blindly. Please
> > do not be dogmatic.
> >
> > Sometimes, we have to "break" an obscure case in order to make progress.  
> 
> I know you Linux people don't want to hear it, but Windows is not an
> "obscure" platform.

No, but using MSVC with FFmpeg is obscure. MinGW is preferred for
multiple reasons. I hear you don't even use it for production yourself,
only debugging occasionally. Also this is not about MSVC, but MSVC +
hardware specific API supported by 1 vendor only.

If someone really cares about nvenc with FFmpeg+MSVC, it'd get fixed in
no time anyway.

Sure, there's no time pressure, but if we don't do anything, it'll take
years, and we'll always hear "but nvidia has in-tree headers" from
various vendors of single-vendor hardware specific APIs.

It seems someone is actually looking into this now and trying this with
MSVC, so maybe this will be a non-issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[James Almer]

On 2/25/2018 9:20 PM, Marton Balint wrote:
> From: Timo Rothenpieler 
> 
> External headers are no longer welcome in the ffmpeg codebase because they
> increase the maintenance burden. However, in the NVidia case the vanilla
> headers need some modifications to be usable in ffmpeg therefore we still
> provide them, but in a separate repository.
> 
> The external headers can be found at
> https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
> 
> This patch squashes Timo's patches from Dec 4 last year, and also removes most
> part of compat/dynlink_loader.h because that was added to the headers repo as
> well.
> 
> Fate-source is updated because of the deleted files, and dynlink_loader.h
> license headers were updated with the standard FFmpeg headers.
> 
> Only compile tested and only on Linux.
> 
> Signed-off-by: Marton Balint 
> ---
>  Changelog  |2 +
>  compat/cuda/dynlink_cuda.h |   98 --
>  compat/cuda/dynlink_cuviddec.h |  886 ---
>  compat/cuda/dynlink_loader.h   |  273 +---
>  compat/cuda/dynlink_nvcuvid.h  |  356 -
>  compat/nvenc/nvEncodeAPI.h | 3324 
> 
>  configure  |6 +-
>  libavcodec/nvenc.h |2 +-
>  tests/ref/fate/source  |4 -
>  9 files changed, 27 insertions(+), 4924 deletions(-)
>  delete mode 100644 compat/cuda/dynlink_cuda.h
>  delete mode 100644 compat/cuda/dynlink_cuviddec.h
>  delete mode 100644 compat/cuda/dynlink_nvcuvid.h
>  delete mode 100644 compat/nvenc/nvEncodeAPI.h
> 

[...]

> diff --git a/configure b/configure
> index 1bdb7c1c2d..83bcb80283 100755
> --- a/configure
> +++ b/configure
> @@ -2675,6 +2675,7 @@ zmbv_encoder_deps="zlib"
>  
>  # hardware accelerators
>  crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
> +cuda_deps="ffnvcodec">  cuda_deps_any="libdl LoadLibrary"
>  cuvid_deps="cuda"
>  d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext"
> @@ -5811,6 +5812,9 @@ check_type "va/va.h va/va_enc_vp9.h"  
> "VAEncPictureParameterBufferVP9"
>  
>  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
>  
> +check_pkg_config ffnvcodec "ffnvcodec >= 8.0" \

Instead of adding a new ffnvcodec module to configure, just use the
existing cuda one.

> +"ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h 
> ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" ""
> +
>  check_cpp_condition windows.h 
> "!WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)" && enable winrt || 
> disable winrt
>  
>  if ! disabled w32threads && ! enabled pthreads; then
> @@ -6263,7 +6267,7 @@ fi
>  
>  enabled nvenc &&
>  check_cc -I$source_path < -#include "compat/nvenc/nvEncodeAPI.h"
> +#include 
>  NV_ENCODE_API_FUNCTION_LIST flist;
>  void f(void) { struct { const GUID guid; } s[] = { { NV_ENC_PRESET_HQ_GUID } 
> }; }
>  int main(void) { return 0; }
> diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h
> index ab6825f633..bff25dfc3c 100644
> --- a/libavcodec/nvenc.h
> +++ b/libavcodec/nvenc.h
> @@ -28,7 +28,7 @@
>  typedef void ID3D11Device;
>  #endif
>  
> -#include "compat/nvenc/nvEncodeAPI.h"
> +#include 
>  
>  #include "compat/cuda/dynlink_loader.h"
>  #include "libavutil/fifo.h"
> diff --git a/tests/ref/fate/source b/tests/ref/fate/source
> index 2def03495b..809c4632d4 100644
> --- a/tests/ref/fate/source
> +++ b/tests/ref/fate/source
> @@ -23,12 +23,8 @@ compat/avisynth/avs/types.h
>  compat/avisynth/avxsynth_c.h
>  compat/avisynth/windowsPorts/basicDataTypeConversions.h
>  compat/avisynth/windowsPorts/windows2linux.h
> -compat/cuda/dynlink_cuda.h
> -compat/cuda/dynlink_cuviddec.h
>  compat/cuda/dynlink_loader.h
> -compat/cuda/dynlink_nvcuvid.h
>  compat/float/float.h
>  compat/float/limits.h
> -compat/nvenc/nvEncodeAPI.h
>  Use of av_clip() where av_clip_uintp2() could be used:
>  Use of av_clip() where av_clip_intp2() could be used:
> 

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

Re: [FFmpeg-devel] Pull requests

[wm4]

On Mon, 26 Feb 2018 17:15:26 -0500
Bjorn Roche  wrote:

> Okay, thanks Nicolas.
> 
> I already submitted a patch to the mailing list a few months ago, I was
> just hoping for an easier way to keep it fresh since it's gone stale, and I
> had some more fixes for it.

Just ping it a few times or resend it. It's pretty easy for patches to
get lost/ignored, but we don't use the github mirror's PR system at
all. Github merely doesn't let us disable it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Hendrik Leppkes]

On Tue, Feb 27, 2018 at 11:45 AM, wm4  wrote:
> On Mon, 26 Feb 2018 22:15:04 +0100 (CET)
> Marton Balint  wrote:
>
>> On Mon, 26 Feb 2018, Timo Rothenpieler wrote:
>>
>> > The reason I haven't pushed this yet is because it breaks the build on
>> > MSVC, and I haven't gotten around to figuring out pkg-config for it.
>>
>> Right. I picked this up because I thought it would be nice if we could go
>> through with it before the upcoming release. I am not sure I can help with
>> MSVC though because I don't have an MSVC build enviroment at the moment.
>
> We could just leave it to whoever wants to use MSVC to build this.
> Somewhat justified IMHO, because it's an obscure hard to test
> configuration (using MSVC _and_ some hw/vendor specific driver).

Knowingly breaking working configurations is not acceptable.

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

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Hendrik Leppkes]

On Tue, Feb 27, 2018 at 12:13 PM, Nicolas George  wrote:
> Hendrik Leppkes (2018-02-27):
>> Something works today, you want to refactor it, you get to keep it
>> working. Its a simple rule.
>
> It is a simple rule, but not one that must be followed blindly. Please
> do not be dogmatic.
>
> Sometimes, we have to "break" an obscure case in order to make progress.

I know you Linux people don't want to hear it, but Windows is not an
"obscure" platform.

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

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

[Michael Niedermayer]

On Mon, Feb 26, 2018 at 10:37:51AM -0800, Xiaohan Wang (王消寒) wrote:
> Thanks! Updated the patch. Please take a look again.
> 
> On Sat, Feb 24, 2018 at 7:04 PM, Michael Niedermayer  > wrote:
> 
> > On Fri, Feb 23, 2018 at 05:12:05PM -0800, Xiaohan Wang (王消寒) wrote:
> > > Michael: Dale and I dig into history a bit more and we don't understand
> > why
> > > the code is changed to the current state around memset. This new patch
> > > reverted the change back to the previous state which we felt is much
> > > cleaner. Please see the CL description for details and take a look at the
> > > new patch. Thanks!
> > >
> > > On Wed, Feb 21, 2018 at 1:14 PM, Xiaohan Wang (王消寒)  > >
> > > wrote:
> > >
> > > > jstebbins: kindly ping!
> > > >
> > > > On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) <
> > xhw...@chromium.org>
> > > > wrote:
> > > >
> > > >> +jstebbins@ who wrote that code.
> > > >>
> > > >> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
> > > >> mich...@niedermayer.cc> wrote:
> > > >>
> > > >>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒) wrote:
> > > >>> >
> > > >>>
> > > >>> >  mov.c |3 ++-
> > > >>> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
> > > >>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
> > > >>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17 00:00:00
> > 2001
> > > >>> > From: Xiaohan Wang 
> > > >>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
> > > >>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in
> > > >>> mov_read_trun()
> > > >>> >
> > > >>> > The allocated size of sc->ctts_data is
> > > >>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> > > >>> >
> > > >>> > The size to memset at offset sc->ctts_data + sc->ctts_count should
> > be
> > > >>> > (st->nb_index_entries + entries - sc->ctts_count) *
> > > >>> sizeof(*sc->ctts_data))
> > > >>> >
> > > >>> > The current code missed |entries| I believe.
> > > >>>
> > > >>> shouldnt "entries" be read by this function later and so shouldnt
> > need a
> > > >>> memset?
> > > >>> I didnt write this, but it looks a bit to me as if it was intended to
> > > >>> only
> > > >>> clear the area that would not be read later
> > > >>>
> > > >>
> > > >> I thought we only had sc->ctts_count entries before av_fast_realloc,
> > so
> > > >> memset everything starting from sc->ctts_data + sc->ctts_count
> > couldn't
> > > >> go wrong. But I am not familiar with this code and that could totally
> > be
> > > >> wrong. I added jstebbins@ who wrote the code and hopefully we can get
> > > >> expert opinion there.
> > > >>
> > > >>
> > > >>> [...]
> > > >>> --
> > > >>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> > 87040B0FAB
> > > >>>
> > > >>> No great genius has ever existed without some touch of madness. --
> > > >>> Aristotle
> > > >>>
> > > >>> ___
> > > >>> ffmpeg-devel mailing list
> > > >>> ffmpeg-devel@ffmpeg.org
> > > >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >>>
> > > >>>
> > > >>
> > > >
> >
> > >  mov.c |5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > e5bbe55f0b1260f787f431b5c45e6ca49a7d2d1e  0001-Fix-memset-size-on-ctts_
> > data-in-mov_read_trun-round-.patch
> > > From f34b35ec5749c17b21f80665a0b8859bce3e84ab Mon Sep 17 00:00:00 2001
> > > From: Xiaohan Wang 
> > > Date: Fri, 23 Feb 2018 10:51:30 -0800
> > > Subject: [PATCH] Fix memset size on ctts_data in mov_read_trun() (round
> > 2)
> > >
> > > The allocated size of sc->ctts_data is
> > > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> > >
> > > The size to memset at offset sc->ctts_data + sc->ctts_count should be
> > > (st->nb_index_entries + entries - sc->ctts_count) *
> > > sizeof(*sc->ctts_data))
> > >
> > > The current code missed |entries| I believe, which was introduced in
> > > https://patchwork.ffmpeg.org/patch/5541/.
> > >
> > > However, after offline discussion, it seems the original code is much
> > > more clear to read (before https://patchwork.ffmpeg.org/patch/5541/).
> > >
> > > Hence this CL revert the memset logic to it's previous state by
> > > remembering the |old_ctts_allocated_size|, and only memset the newly
> > > allocated entries.
> > > ---
> > >  libavformat/mov.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index a3725692a7..f8d79c7b02 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -4713,6 +4713,7 @@ static int mov_read_trun(MOVContext *c,
> > AVIOContext *pb, MOVAtom atom)
> > >  st->index_entries= new_entries;
> > >
> > >  requested_size = (st->nb_index_entries + entries) *
> > sizeof(*sc->ctts_data);
> > > +unsigned int old_ctts_allocated_size = sc->ctts_allocated_size;
> >
> > this should possibly 

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[wm4]

On Tue, 27 Feb 2018 11:49:25 +0100
Hendrik Leppkes  wrote:

> On Tue, Feb 27, 2018 at 11:45 AM, wm4  wrote:
> > On Mon, 26 Feb 2018 22:15:04 +0100 (CET)
> > Marton Balint  wrote:
> >  
> >> On Mon, 26 Feb 2018, Timo Rothenpieler wrote:
> >>  
> >> > The reason I haven't pushed this yet is because it breaks the build on
> >> > MSVC, and I haven't gotten around to figuring out pkg-config for it.  
> >>
> >> Right. I picked this up because I thought it would be nice if we could go
> >> through with it before the upcoming release. I am not sure I can help with
> >> MSVC though because I don't have an MSVC build enviroment at the moment.  
> >
> > We could just leave it to whoever wants to use MSVC to build this.
> > Somewhat justified IMHO, because it's an obscure hard to test
> > configuration (using MSVC _and_ some hw/vendor specific driver).  
> 
> Knowingly breaking working configurations is not acceptable.

Just make it unsupported via configure.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Hendrik Leppkes]

On Tue, Feb 27, 2018 at 11:59 AM, wm4  wrote:
> On Tue, 27 Feb 2018 11:49:25 +0100
> Hendrik Leppkes  wrote:
>
>> On Tue, Feb 27, 2018 at 11:45 AM, wm4  wrote:
>> > On Mon, 26 Feb 2018 22:15:04 +0100 (CET)
>> > Marton Balint  wrote:
>> >
>> >> On Mon, 26 Feb 2018, Timo Rothenpieler wrote:
>> >>
>> >> > The reason I haven't pushed this yet is because it breaks the build on
>> >> > MSVC, and I haven't gotten around to figuring out pkg-config for it.
>> >>
>> >> Right. I picked this up because I thought it would be nice if we could go
>> >> through with it before the upcoming release. I am not sure I can help with
>> >> MSVC though because I don't have an MSVC build enviroment at the moment.
>> >
>> > We could just leave it to whoever wants to use MSVC to build this.
>> > Somewhat justified IMHO, because it's an obscure hard to test
>> > configuration (using MSVC _and_ some hw/vendor specific driver).
>>
>> Knowingly breaking working configurations is not acceptable.
>
> Just make it unsupported via configure.

And thats not breaking something that works today, how?

Something works today, you want to refactor it, you get to keep it
working. Its a simple rule.

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

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Nicolas George]

Hendrik Leppkes (2018-02-27):
> Something works today, you want to refactor it, you get to keep it
> working. Its a simple rule.

It is a simple rule, but not one that must be followed blindly. Please
do not be dogmatic.

Sometimes, we have to "break" an obscure case in order to make progress.
We cannot be 100% bug-compatible with older versions, except if we
completely stop development. We must make use of common sense, and
balance the benefit with the drawbacks. The drawbacks include how
frequent the use case is, and also how easy it is to fix.

I think it would be reasonable to set a three months warning in
configure:

./configure --enable-msvc --enable-nvidia
ERROR: support nVidia drivers with MSVC will be removed on 2018-06-01
unless somebody steps in to fix and test it.

./configure --enable-msvc --enable-nvidia --enable-nvidia-temporary
WARNING: support nVidia drivers with MSVC will be removed on 2018-06-01
unless somebody steps in to fix and test it.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/rscc: Skip empty frames (nb_tiles == 0)

[Michael Niedermayer]

On Mon, Feb 26, 2018 at 03:29:46AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 6266/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-5692431816196096
> 
> Its not known if nb_tiles is allowed so it is not treated as an error
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/rscc.c | 6 ++
>  1 file changed, 6 insertions(+)

patchset applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Nicolas George]

Hendrik Leppkes (2018-02-27):
> I know you Linux people don't want to hear it, but Windows is not an
> "obscure" platform.

Maybe. But I have to emphasize that you refused to give comment to the
practical part of my message. Does it means you do not have an
objection?

We can go ahead, then.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Nicolas George]

Hendrik Leppkes (2018-02-27):
> Your entire approach revolves around it being an obscure feature that
> noone is going to miss, so you can take that as an objection.
> 
> The original author never submitted his patch because he didn't finish
> it yet. Someone else finds it somewhere and sends it (which is odd
> enough as it is), and suddenly its the most crucial thing to get in?
> How is that common sense?

Fair enough. Then I suggest this: let us wait just one week. If nobody
posts a mail here to propose helping, it probes that not that many
people do care.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[wm4]

On Mon, 26 Feb 2018 22:15:04 +0100 (CET)
Marton Balint  wrote:

> On Mon, 26 Feb 2018, Timo Rothenpieler wrote:
> 
> > The reason I haven't pushed this yet is because it breaks the build on
> > MSVC, and I haven't gotten around to figuring out pkg-config for it.  
> 
> Right. I picked this up because I thought it would be nice if we could go 
> through with it before the upcoming release. I am not sure I can help with 
> MSVC though because I don't have an MSVC build enviroment at the moment.

We could just leave it to whoever wants to use MSVC to build this.
Somewhat justified IMHO, because it's an obscure hard to test
configuration (using MSVC _and_ some hw/vendor specific driver).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[wm4]

On Tue, 27 Feb 2018 12:01:48 +0100
Hendrik Leppkes  wrote:

> On Tue, Feb 27, 2018 at 11:59 AM, wm4  wrote:
> > On Tue, 27 Feb 2018 11:49:25 +0100
> > Hendrik Leppkes  wrote:
> >  
> >> On Tue, Feb 27, 2018 at 11:45 AM, wm4  wrote:  
> >> > On Mon, 26 Feb 2018 22:15:04 +0100 (CET)
> >> > Marton Balint  wrote:
> >> >  
> >> >> On Mon, 26 Feb 2018, Timo Rothenpieler wrote:
> >> >>  
> >> >> > The reason I haven't pushed this yet is because it breaks the build on
> >> >> > MSVC, and I haven't gotten around to figuring out pkg-config for it.  
> >> >>
> >> >> Right. I picked this up because I thought it would be nice if we could 
> >> >> go
> >> >> through with it before the upcoming release. I am not sure I can help 
> >> >> with
> >> >> MSVC though because I don't have an MSVC build enviroment at the 
> >> >> moment.  
> >> >
> >> > We could just leave it to whoever wants to use MSVC to build this.
> >> > Somewhat justified IMHO, because it's an obscure hard to test
> >> > configuration (using MSVC _and_ some hw/vendor specific driver).  
> >>
> >> Knowingly breaking working configurations is not acceptable.  
> >
> > Just make it unsupported via configure.  
> 
> And thats not breaking something that works today, how?
> 
> Something works today, you want to refactor it, you get to keep it
> working. Its a simple rule.

Well, AFAIK we've dropped entire platforms without notice before.

Anyway, someone has to test/adjust this on Windows (potentially needs
nvidia hardware too), but nobody seems to be unavailable. That means
it's unmaintained.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Hendrik Leppkes]

On Tue, Feb 27, 2018 at 12:29 PM, Nicolas George  wrote:
> Hendrik Leppkes (2018-02-27):
>> I know you Linux people don't want to hear it, but Windows is not an
>> "obscure" platform.
>
> Maybe. But I have to emphasize that you refused to give comment to the
> practical part of my message. Does it means you do not have an
> objection?
>

Your entire approach revolves around it being an obscure feature that
noone is going to miss, so you can take that as an objection.

The original author never submitted his patch because he didn't finish
it yet. Someone else finds it somewhere and sends it (which is odd
enough as it is), and suddenly its the most crucial thing to get in?
How is that common sense?

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

[FFmpeg-devel] Transcoding sample app for Resizing video

[Vittalprasad]

Hi All,

i tried transcoding sample application shared with examples. As i'm new to
video codecs didnot understand fully , how to scale a resolution of video
i.e if input of 720p trancode to 240p without changing video codec.

i tried to enhance transcoding sample with sws_scale(); i.e scaling api's
but not successful

please provide me correct examples/api  to achieve resizing of video

My intention is to use design own transcoding model using ffmpeg libraries.


Thanks & Regards
Vittal Prasad B R
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Transcoding sample app for Resizing video

[Tomas Härdin]

tis 2018-02-27 klockan 19:55 +0530 skrev Vittalprasad:
> Hi All,
> 
> i tried transcoding sample application shared with examples. As i'm
> new to
> video codecs didnot understand fully , how to scale a resolution of
> video
> i.e if input of 720p trancode to 240p without changing video codec.
> 
> i tried to enhance transcoding sample with sws_scale(); i.e scaling
> api's
> but not successful
> 
> please provide me correct examples/api  to achieve resizing of video
> 
> My intention is to use design own transcoding model using ffmpeg
> libraries.

This is not the list for questions like these - try libav-user. That
said, it's probably easiest to either use a script or execv() the
ffmpeg CLI

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

Re: [FFmpeg-devel] GSoC

[Stephan Holljes]

On Tue, Feb 27, 2018 at 8:13 PM, Nicolas George  wrote:
> Hi, and welcome back.

Thanks you, and thanks for the feedback.

>
> Stephan Holljes (2018-02-26):
>> seeing that people are already applying for projects, I think I should as 
>> well.
>>
>> My name is Stephan Holljes, on IRC I go by klaxa. Some may remember me
>> from GSoC 2015 where I implemented the (how I later found out
>> controversly debated) HTTP-Server API.
>>
>> Since someone else already applied for the DICOM project, which I
>> would also like to do, maybe instead I could work on an ffserver
>> replacement, since it has been dropped recently. Maybe some have
>> already seen my mkv-server (https://github.com/klaxa/mkvserver_mk2/)
>> which was mentioned a few times on the ML. I think it could serve as a
>> starting point, since it already only uses the public API.
>
> I do not know what features you have in mind exactly for this project,
> but it reminds me of a pet project that I have: a muxer that acts as a
> multi-clients server.

More protocols than HTTP (presumably RTP and/or RTMP although I cannot
guess how much work that would be) and/or HTTP-based protocols like
DASH or HLS? I recently discussed this with a friend too, who argued
that webservers already do a lot of optimization regarding connection
handling and that implementing it again would be somewhat reinventing
the wheel. So I'm not too sure about the usefulness of that.

>
> It would work like the tee muxer: frames sent to the muxer are
> duplicated and re-muxed into several slave muxers. The difference is be
> that the list of slave muxers is not set at the beginning but evolves
> when clients connect and disconnect.
>
> I have not given much thought on the way of doing it expressive enough
> so that it would not be just a toy. Using programs to allow the server
> to provide different streams? Using attachments to send non-live files?

In fact the project I posted already does that, while for the time
being only for video files and only for a single stream, but the
architecture allows for any number of streams to be served.

>
> Anyway, if somebody wants to achieve anything in that direction within
> the FFmpeg project, I am pretty sure it would require a big cleanup of
> the inconsistent mess that is the network code currently.

Since I have only had somewhat in-depth insight into http and tcp I'll
have to do quite some research on the other protocols.

>
> Due to personal stuff, I do not feel up to offering mentoring this year
> either, but I can share my thoughts on the issue and help as much as I
> can.
>
> The big but not-that-hard part of the issue would be to design and
> implement a real event loop with enough features.
>
> It needs to be able to run things in separate threads when they need to
> react with low latency. That is the infamous "UDP thread". Note that a
> single thread should be able to handle several low-latency network
> streams, if it is not burdened by heavy computation at the same time.
>
> It needs to be able to run things in separate threads to integrate
> protocols that have not been integrated with it. Lightweight
> collaborative threads could be used, but they do not seem to exist with
> an up-to-date portable API.
>
> Protocols that rely on sub-protocols (HTTP→TCP, RTP→UDP, etc.) need to
> be updated to make use of the even loop instead of querying directly
> their slaves. Protocols will probably need to be attached to an event
> loop.

I'm not sure I understand. So far I could implement everything just
using the public http api without any modifications.

>
> That means having an event loop will be mandatory when using the current
> AVIO API: its implementation must be updated to create one on the fly as
> needed. But they need to be deprecated too.

So far my project implements an event-loop, in which any number of
(pthreads-)threads can be used to process data transfer from the
server to the client. The state of each client transfer is stored in a
struct which is protected by pthread_mutex locks during modification.
Each of these worker threads is stateless and does work depending on
the state of the client structs. A separate thread handles accepting
the connection and sending the muxed header. Yet another separate
thread reads the input file.

>
> Some work need to be done on demuxers to make them non-blocking. I think
> the best approach is to keep using the push/pull pattern: instead of
> providing an AVIO to a demuxer, push it data as it arrives, and then try
> to read the frames, or maybe rely on a callback.
>
> Demuxers that have not been updated for that API and rely heavily on
> blocking reads of the exact amount of data they need will probably need
> to be run in separate threads (again, if we could have lightweight
> threads…).

Again I'll probably have to do quite some research on this. So far
things have worked pretty okay-ish with blocking calls, but I guess
that's also because threads are kind of a giant 

Re: [FFmpeg-devel] [PATCH] avcodec/proresenc_anatoliy: change quantization scaling to floating point to utilize vectorization

[Rostislav Pehlivanov]

On 27 February 2018 at 21:22, David Murmann  wrote:

>
> On 2/27/2018 9:58 PM, Hendrik Leppkes wrote:
> > On Tue, Feb 27, 2018 at 9:35 PM, David Murmann 
> wrote:
> >> Quantization scaling seems to be a slight bottleneck,
> >> this change allows the compiler to more easily vectorize
> >> the loop. This improves total encoding performance in my
> >> tests by about 10-20%.
> >>
> >> Signed-off-by: David Murmann 
> >> ---
> >>   libavcodec/proresenc_anatoliy.c | 12 
> >>   1 file changed, 8 insertions(+), 4 deletions(-)
> >>
> [...]
> >> +for (j = 0; j < blocks_per_slice; j++) {
> >> +for (i = 0; i < 64; i++) {
> >> +block[i] = (float)in[(j << 6) + i] / (float)qmat[i];
> >> +}
> >> +
> >> +for (i = 1; i < 64; i++) {
> >> +int val = block[progressive_scan[i]];
> >>   if (val) {
> >>   encode_codeword(pb, run, run_to_cb[FFMIN(prev_run,
> 15)]);
> >
> > Usually, using float is best avoided. Did you test re-factoring the
> > loop structure without changing it to float?
>
> Yes, the vector instructions don't have integer division, AFAIK, and the
> compiler just generates a loop with idivs. This is quite a bit slower
> than converting to float, dividing and converting back, if the compiler
> uses vector instructions. In the general case this wouldn't be exact,
> but since the input values are int16 they should losslessly fit into
> float32. On platforms where this auto-vectorization fails this might
> actually be quite a bit slower, but I have not seen that in my tests
> (though I have only tested on x86_64).
>
> --
> David Murmann
>
> da...@btf.de
> Telefon +49 (0) 221 82008710
> Fax +49 (0) 221 82008799
>
> http://btf.de/
>
> --
> btf GmbH | Leyendeckerstr. 27, 50825 Köln | +49 (0) 221 82 00 87 10
> Geschäftsführer: Philipp Käßbohrer & Matthias Murmann | HR Köln | HRB 74707
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

No, you're going about it the wrong way. Floats should most definitely be
avoided in encoders/decoders. Non-deterministic output on platforms is a
smaller issue to how they can obliterate performance if compilers emit an
actual div instruction.

Instead, here's what you can do to make it even faster: replace the
division with a multiply + a shift. Keeps the output identical too. I've
just sent an old patch of mine (for a different but similar codec) you can
work off of - just take the last bit of code there, run it at init to
generate the LUTs for all quantizers and then just multiply and shift by
looking into the tables you generate. Here's the link:
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225867.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] avformat/hlsenc: add reference stream index for split segment

[Steven Liu]

fix ticket: #7044
Get the first video stream to reference for split segment
when there have more than one video stream

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index ff064732a1..08fe0aa7a0 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -129,6 +129,7 @@ typedef struct VariantStream {
 int nb_entries;
 int discontinuity_set;
 int discontinuity;
+int reference_stream_index;
 
 HLSSegment *segments;
 HLSSegment *last_segment;
@@ -2141,7 +2142,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (vs->has_video) {
 can_split = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
 ((pkt->flags & AV_PKT_FLAG_KEY) || (hls->flags & 
HLS_SPLIT_BY_TIME));
-is_ref_pkt = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO;
+is_ref_pkt = (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) && 
(pkt->stream_index == vs->reference_stream_index);
 }
 if (pkt->pts == AV_NOPTS_VALUE)
 is_ref_pkt = can_split = 0;
@@ -2497,6 +2498,11 @@ static int hls_init(AVFormatContext *s)
 
 for (j = 0; j < vs->nb_streams; j++) {
 vs->has_video += vs->streams[j]->codecpar->codec_type == 
AVMEDIA_TYPE_VIDEO;
+/* Get one video stream to reference for split segments
+ * so use the first video stream index. */
+if ((vs->has_video == 1) && (vs->streams[j]->codecpar->codec_type 
== AVMEDIA_TYPE_VIDEO)) {
+vs->reference_stream_index = j;
+}
 vs->has_subtitle += vs->streams[j]->codecpar->codec_type == 
AVMEDIA_TYPE_SUBTITLE;
 }
 
-- 
2.15.1




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

Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: add reference stream index for split segment

[Jeyapal, Karthick]

On 2/28/18 10:18 AM, Steven Liu wrote:
> fix ticket: #7044
> Get the first video stream to reference for split segment
> when there have more than one video stream
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index ff064732a1..08fe0aa7a0 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -129,6 +129,7 @@ typedef struct VariantStream {
>  int nb_entries;
>  int discontinuity_set;
>  int discontinuity;
> +int reference_stream_index;
>  
>  HLSSegment *segments;
>  HLSSegment *last_segment;
> @@ -2141,7 +2142,7 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  if (vs->has_video) {
>  can_split = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
>  ((pkt->flags & AV_PKT_FLAG_KEY) || (hls->flags & 
> HLS_SPLIT_BY_TIME));
> -is_ref_pkt = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO;
> +is_ref_pkt = (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) && 
> (pkt->stream_index == vs->reference_stream_index);
>  }
>  if (pkt->pts == AV_NOPTS_VALUE)
>  is_ref_pkt = can_split = 0;
> @@ -2497,6 +2498,11 @@ static int hls_init(AVFormatContext *s)
>  
>  for (j = 0; j < vs->nb_streams; j++) {
>  vs->has_video += vs->streams[j]->codecpar->codec_type == 
> AVMEDIA_TYPE_VIDEO;
> +/* Get one video stream to reference for split segments
> + * so use the first video stream index. */
> +if ((vs->has_video == 1) && 
> (vs->streams[j]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)) {
> +vs->reference_stream_index = j;
> +}
>  vs->has_subtitle += vs->streams[j]->codecpar->codec_type == 
> AVMEDIA_TYPE_SUBTITLE;
>  }
>  
LGTM

Regards,
Karthick


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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add reference stream index for split segment

[Steven Liu]

2018-02-28 11:32 GMT+08:00 Jeyapal, Karthick :
>
>
> On 2/27/18 11:09 AM, Steven Liu wrote:
>> fix ticket: #7044
>> Get the first video stream to reference for split segment
>> when there have more than one video stream
>>
>> Signed-off-by: Steven Liu 
>> ---
>>  libavformat/hlsenc.c | 12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index ff064732a1..8567227885 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -129,6 +129,7 @@ typedef struct VariantStream {
>>  int nb_entries;
>>  int discontinuity_set;
>>  int discontinuity;
>> +int reference_stream_index;
>>
>>  HLSSegment *segments;
>>  HLSSegment *last_segment;
>> @@ -2155,8 +2156,10 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> * st->time_base.num / 
>> st->time_base.den;
>>  vs->dpp = (double)(pkt->duration) * st->time_base.num / 
>> st->time_base.den;
>>  } else {
>> -if (pkt->duration) {
>> -vs->duration += (double)(pkt->duration) * st->time_base.num 
>> / st->time_base.den;
>> +   if (pkt->duration) {
>> +if (pkt->stream_index == vs->reference_stream_index) {
>> +vs->duration += (double)(pkt->duration) * 
>> st->time_base.num / st->time_base.den;
>> +}
> Still the duration variable in other places is being set for all video 
> streams.
> Maybe it is better to restrict the “is_ref_pkt” to 1, only for 
> vs->reference_stream_index.
>>  } else {
>>  av_log(s, AV_LOG_WARNING, "pkt->duration = 0, maybe the hls 
>> segment duration will not precise\n");
>>  vs->duration = (double)(pkt->pts - vs->end_pts) * 
>> st->time_base.num / st->time_base.den;
>> @@ -2497,6 +2500,11 @@ static int hls_init(AVFormatContext *s)
>>
>>  for (j = 0; j < vs->nb_streams; j++) {
>>  vs->has_video += vs->streams[j]->codecpar->codec_type == 
>> AVMEDIA_TYPE_VIDEO;
>> +/* Get one video stream to reference for split segments
>> + * so use the first video stream index. */
>> +if (vs->has_video == 1) {
>> +vs->reference_stream_index = j;
>> +}
> This doesn’t look correct. Potentially vs->reference_stream_index could get 
> overwritten by audio and/or subtitle stream index.



Patch updated :D



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

Re: [FFmpeg-devel] [PATCH 5/9] sbc: implement SBC encoder (low-complexity subband codec)

[Aurelien Jacobs]

On Sat, Feb 24, 2018 at 09:31:30PM +, Rostislav Pehlivanov wrote:
> On 24 February 2018 at 12:01, Aurelien Jacobs  wrote:
> 
> > On Thu, Feb 22, 2018 at 06:18:48PM +, Rostislav Pehlivanov wrote:
> > > On 21 February 2018 at 22:37, Aurelien Jacobs  wrote:
> > >
> > > > This was originally based on libsbc, and was fully integrated into
> > ffmpeg.
> > > > ---
> > > >  doc/general.texi |   2 +-
> > > >  libavcodec/Makefile  |   1 +
> > > >  libavcodec/allcodecs.c   |   1 +
> > > >  libavcodec/sbcdsp.c  | 382 ++
> > > > +
> > > >  libavcodec/sbcdsp.h  |  83 ++
> > > >  libavcodec/sbcdsp_data.c | 329 +
> > > >  libavcodec/sbcdsp_data.h |  55 +++
> > > >  libavcodec/sbcenc.c  | 411 ++
> > > > +
> > > >  8 files changed, 1263 insertions(+), 1 deletion(-)
> > > >  create mode 100644 libavcodec/sbcdsp.c
> > > >  create mode 100644 libavcodec/sbcdsp.h
> > > >  create mode 100644 libavcodec/sbcdsp_data.c
> > > >  create mode 100644 libavcodec/sbcdsp_data.h
> > > >  create mode 100644 libavcodec/sbcenc.c
> > > >
> > > > +
> > > > +#define OFFSET(x) offsetof(SBCEncContext, x)
> > > > +#define AE AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
> > > > +static const AVOption options[] = {
> > > > +{ "joint_stereo", "use joint stereo",
> > > > +  OFFSET(joint_stereo), AV_OPT_TYPE_BOOL, { .i64 =  0 }, 0,   1,
> > AE },
> > > >
> > > +{ "dual_channel", "use dual channel",
> > > > +  OFFSET(dual_channel), AV_OPT_TYPE_BOOL, { .i64 =  0 }, 0,   1,
> > AE },
> > > >
> > >
> > > Erm those 2 things should be decided by the encoder, not by exposing them
> > > to the user. The encoder should decide which mode has lower distortion
> > for
> > > a given signal.
> >
> > See bellow.
> >
> > > > +{ "subbands", "number of subbands (4 or 8)",
> > > > +  OFFSET(subbands), AV_OPT_TYPE_INT,  { .i64 =  8 }, 4,   8,
> > AE },
> > > >
> > >
> > > The encoder doesn't check if the value isn't 4 or 8 so 5, 6 and 7 are all
> > > accepted. Similar issue to the previous option too.
> >
> > OK, fixed.
> >
> > > > +{ "bitpool",  "bitpool value",
> > > > +  OFFSET(bitpool),  AV_OPT_TYPE_INT,  { .i64 = 32 }, 0, 255,
> > AE },
> > > >
> > >
> > > This should be controlled by the bitrate setting. Either have a function
> > to
> > > translate bitrate to bitpool value or a table which approximately maps
> > > bitrate values supplied to bitpools. You could expose it directly as well
> > > as mapping it to a bitrate value by using the global_quality setting so
> > it
> > > shouldn't be a custom encoder option.
> >
> > Indeed, this is better this way, thanks for the suggestion.
> >
> > > > +{ "blocks",   "number of blocks (4, 8, 12 or 16)",
> > > > +  OFFSET(blocks),   AV_OPT_TYPE_INT,  { .i64 = 16 }, 4,  16,
> > AE },
> > > > +{ "snr",  "use SNR mode (instead of loudness)",
> > > > +  OFFSET(allocation),   AV_OPT_TYPE_BOOL, { .i64 =  0 }, 0,   1,
> > AE },
> > > >
> > >
> > > SNR mode too needs to be decided by the encoder rather than exposing it
> > as
> > > a setting.
> >
> > See bellow.
> >
> > > > +{ "msbc", "use mSBC mode (wideband speech mono SBC)",
> > > >
> > >
> > > Add a profile fallback setting for this as well, like in aac where
> > -aac_ltp
> > > turns LTP mode on and -profile:a aac_ltp does the same.
> >
> > Not sure of the benefits of having 2 redundant way to do this, but OK.
> >
> > > You don't have to make the encoder decide which stereo coupling mode or
> > > snr/loudness setting to use, you can implement that with a later patch.
> > > I think you should remove the "blocks" and "subbands" settings as well
> > and
> > > instead replace those with a single "latency" setting like the native
> > Opus
> > > encoder in milliseconds which would adjust both of them on init to set
> > the
> > > frame size. This would also allow the encoder to change them. Again, you
> > > don't have to do this now, you can send a patch which adds a "latency"
> > > option later.
> >
> > I can see the value in what you propose, and I think that indeed, it
> > would be great for the encoder to choose by itself the most appropriate
> > parameters by default.
> > But on the other hand, we are talking about a codec targetting some
> > hardware decoders (blutetooth speakers, headsets...), and all those
> > parameters have to be negotiated between the encoder and the hardware
> > decoder. So I think it is mandatory to keep all those parameters
> > accessible to be able to setup the encoder according to the target
> > hardware capabilities.
> >
> >
> Hardware isn't as limited as you might think it is, and there's also no
> negotiation happening between encoders and decoders IRL (except for modern
> streaming protocols which suck). While its true that we've had some issues
> with 

Re: [FFmpeg-devel] [PATCH] web/(old)download: Move 3.1 to olddownloads

[Michael Niedermayer]

On Mon, Feb 19, 2018 at 02:39:25AM +0100, Michael Niedermayer wrote:
> No currently maintained distro or app uses 3.1 on 
> https://trac.ffmpeg.org/wiki/Downstreams
> so it would help noone if we continue maintaining 3.1.*
> ---
>  src/download| 39 ---
>  src/olddownload | 39 +++
>  2 files changed, 39 insertions(+), 39 deletions(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vc2enc: replace quantization LUT with a smaller division LUT

[Rostislav Pehlivanov]

This commit replaces the huge and impractical LUT which converted coeffs
and a quantizer to bits to encode and instead uses a standard multiplication
and a shift to replace the division and then codes the values using the
regular golomb coding functions.
I was unable to see a performance difference on my machine but perhaps
someone else here can test. In any case, its better than the old one if
only because its smaller and less intrusive.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 118 ++--
 1 file changed, 31 insertions(+), 87 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index b7adcd3d36..74347b0b39 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -29,10 +29,6 @@
 #include "vc2enc_dwt.h"
 #include "diractab.h"
 
-/* Total range is -COEF_LUT_TAB to +COEFF_LUT_TAB, but total tab size is half
- * (COEF_LUT_TAB*DIRAC_MAX_QUANT_INDEX), as the sign is appended during 
encoding */
-#define COEF_LUT_TAB 2048
-
 /* The limited size resolution of each slice forces us to do this */
 #define SSIZE_ROUND(b) (FFALIGN((b), s->size_scaler) + 4 + s->prefix_bytes)
 
@@ -152,9 +148,8 @@ typedef struct VC2EncContext {
 uint8_t quant[MAX_DWT_LEVELS][4];
 int custom_quant_matrix;
 
-/* Coefficient LUT */
-uint32_t *coef_lut_val;
-uint8_t  *coef_lut_len;
+/* Division LUT */
+uint32_t qmagic_lut[116][2];
 
 int num_x; /* #slices horizontally */
 int num_y; /* #slices vertically */
@@ -229,37 +224,6 @@ static av_always_inline int count_vc2_ue_uint(uint32_t val)
 return ff_log2(topbit)*2 + 1;
 }
 
-static av_always_inline void get_vc2_ue_uint(int val, uint8_t *nbits,
- uint32_t *eval)
-{
-int i;
-int pbits = 0, bits = 0, topbit = 1, maxval = 1;
-
-if (!val++) {
-*nbits = 1;
-*eval = 1;
-return;
-}
-
-while (val > maxval) {
-topbit <<= 1;
-maxval <<= 1;
-maxval |=  1;
-}
-
-bits = ff_log2(topbit);
-
-for (i = 0; i < bits; i++) {
-topbit >>= 1;
-pbits <<= 2;
-if (val & topbit)
-pbits |= 0x1;
-}
-
-*nbits = bits*2 + 1;
-*eval = (pbits << 1) | 1;
-}
-
 /* VC-2 10.4 - parse_info() */
 static void encode_parse_info(VC2EncContext *s, enum DiracParseCodes pcode)
 {
@@ -557,7 +521,7 @@ static void encode_picture_start(VC2EncContext *s)
 encode_wavelet_transform(s);
 }
 
-#define QUANT(c, qf) (((c) << 2)/(qf))
+#define QUANT(c, mul, add, shift) ((mul * c + add) >> shift)
 
 /* VC-2 13.5.5.2 - slice_band() */
 static void encode_subband(VC2EncContext *s, PutBitContext *pb, int sx, int sy,
@@ -570,24 +534,17 @@ static void encode_subband(VC2EncContext *s, 
PutBitContext *pb, int sx, int sy,
 const int top= b->height * (sy+0) / s->num_y;
 const int bottom = b->height * (sy+1) / s->num_y;
 
-const int qfactor = ff_dirac_qscale_tab[quant];
-const uint8_t  *len_lut = >coef_lut_len[quant*COEF_LUT_TAB];
-const uint32_t *val_lut = >coef_lut_val[quant*COEF_LUT_TAB];
-
 dwtcoef *coeff = b->buf + top * b->stride;
+const uint64_t q_m = ((uint64_t)(s->qmagic_lut[quant][0])) << 2;
+const uint64_t q_a = s->qmagic_lut[quant][1];
+const int q_s = av_log2(ff_dirac_qscale_tab[quant]) + 32;
 
 for (y = top; y < bottom; y++) {
 for (x = left; x < right; x++) {
-const int neg = coeff[x] < 0;
-uint32_t c_abs = FFABS(coeff[x]);
-if (c_abs < COEF_LUT_TAB) {
-put_bits(pb, len_lut[c_abs], val_lut[c_abs] | neg);
-} else {
-c_abs = QUANT(c_abs, qfactor);
-put_vc2_ue_uint(pb, c_abs);
-if (c_abs)
-put_bits(pb, 1, neg);
-}
+uint32_t c_abs = QUANT(FFABS(coeff[x]), q_m, q_a, q_s);
+put_vc2_ue_uint(pb, c_abs);
+if (c_abs)
+put_bits(pb, 1, coeff[x] < 0);
 }
 coeff += b->stride;
 }
@@ -619,8 +576,9 @@ static int count_hq_slice(SliceArgs *slice, int quant_idx)
 SubBand *b = >plane[p].band[level][orientation];
 
 const int q_idx = quants[level][orientation];
-const uint8_t *len_lut = >coef_lut_len[q_idx*COEF_LUT_TAB];
-const int qfactor = ff_dirac_qscale_tab[q_idx];
+const uint64_t q_m = ((uint64_t)s->qmagic_lut[q_idx][0]) << 2;
+const uint64_t q_a = s->qmagic_lut[q_idx][1];
+const int q_s = av_log2(ff_dirac_qscale_tab[q_idx]) + 32;
 
 const int left   = b->width  * slice->x/ s->num_x;
 const int right  = b->width  *(slice->x+1) / s->num_x;
@@ -631,14 +589,9 @@ static int count_hq_slice(SliceArgs *slice, int quant_idx)
 
 for (y = top; y < bottom; y++) {
 for (x = left; x < right; x++) {
-   

Re: [FFmpeg-devel] [PATCH 1/2] doc/bitstream_filters: correct dump_extra bsfs docs.

[Jun Zhao]

ping

On 2018/2/23 15:12, Jun Zhao wrote:

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

Re: [FFmpeg-devel] [PATCH 02/10] avformat/mxfdec: fix essence_offset calculation

[Marton Balint]

On Thu, 22 Feb 2018, Paul B Mahol wrote:


On 2/22/18, Tomas Haerdin  wrote:

ons 2018-02-21 klockan 23:06 +0100 skrev Marton Balint:

On Wed, 21 Feb 2018, Tomas Haerdin wrote:

> loer 2018-02-17 klockan 22:45 +0100 skrev Marton Balint:
> > The reference point for a KAG is the first byte of the key of a
> > Partition Pack.
> >
> > Fixes ticket #2817.
> > Fixes ticket #5317.
> >
> > > Signed-off-by: Marton Balint 
> >
> > ---
> >  libavformat/mxfdec.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index fcae863ef4..95767ccba4 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -2875,8 +2875,8 @@ static int mxf_read_header(AVFormatContext *s)
> >   *   for OPAtom we still need the actual
> > essence_offset though (the KL's length can vary)
> >   */
> >  int64_t op1a_essence_offset =
> > -round_to_kag(mxf->current_partition->this_partition
> > +
> > - mxf->current_partition->pack_length,   
mxf->current_partition->kag_size)
> > +
> > +mxf->current_partition->this_partition +
> > +round_to_kag(mxf->current_partition->pack_length,   
mxf->current_partition->kag_size)
> > +
> >  round_to_kag(mxf->current_partition->header_byte_count,
> > mxf->current_partition->kag_size) +
> >  round_to_kag(mxf->current_partition->index_byte_count,  
mxf->current_partition->kag_size);
>
> This seems like a rather elemental miscalculation, that I wrote even. I
> took a look at S377m, it had this to say:
>
> > The first gridline in any partition is the first byte of the key of
> > the partition pack that defines that
> > partition.
>
> Each partition starts at ThisPartition (plus run-in) so this patch
> should be correct. What's perhaps more suspect is the calculation
> itself. It should *always* be possible to locate where Op1a essence
> starts, by scanning to the first essence KLV. MXF is flexible enough
> that having some sketchy calculation for where it *might* be is
> probably not correct. One is free to insert any amount of padding

The next patch more or less handles this by checking for a system item
key and explicitly setting the offset if that is found. An essence alone
however might not be the first essence, it is also possible that we
already skipped an unknown essence key, or an unknown system item key, so
I decided to keep the code as is if the first recognized essence is not a
system item.


Sounds reasonable I guess. I'm going to reiterate that I consider
continuing to maintain mxfdec is a mistake. A wrapper around
bmxlib/libMXF would be much easier to maintain


YOu are lazy and evil! People please ignore him!


I plan to apply the series soon, unless there are other comments :)

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

Re: [FFmpeg-devel] [PATCH 5/9] sbc: implement SBC encoder (low-complexity subband codec)

[Rostislav Pehlivanov]

On 27 February 2018 at 23:56, Aurelien Jacobs  wrote:

>
> So I've updated the patch with only a msbc and a delay option and
> I've added some sane parameters decisions, mainly based on the following
> study :
> https://pdfs.semanticscholar.org/1f19/561d03bc88b67728375566c95bbf77
> e730d5.pdf
> This seems to give pretty good results.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
I think you ought to use a float for this, like:

>{ "sbc_delay", "Maximum delay in milliseconds", offsetof(,
), AV_OPT_TYPE_FLOAT, { .dbl =  }, ,
, ,  },

Apart from that, what's up with the weird if (!sbc->init) { } block in the
main encoding function? Shouldn't that be done in sbc_encode_init()?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add reference stream index for split segment

[Jeyapal, Karthick]

On 2/27/18 11:09 AM, Steven Liu wrote:
> fix ticket: #7044
> Get the first video stream to reference for split segment
> when there have more than one video stream
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index ff064732a1..8567227885 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -129,6 +129,7 @@ typedef struct VariantStream {
>  int nb_entries;
>  int discontinuity_set;
>  int discontinuity;
> +int reference_stream_index;
>  
>  HLSSegment *segments;
>  HLSSegment *last_segment;
> @@ -2155,8 +2156,10 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> * st->time_base.num / 
> st->time_base.den;
>  vs->dpp = (double)(pkt->duration) * st->time_base.num / 
> st->time_base.den;
>  } else {
> -if (pkt->duration) {
> -vs->duration += (double)(pkt->duration) * st->time_base.num 
> / st->time_base.den;
> +   if (pkt->duration) {
> +if (pkt->stream_index == vs->reference_stream_index) {
> +vs->duration += (double)(pkt->duration) * 
> st->time_base.num / st->time_base.den;
> +}
Still the duration variable in other places is being set for all video streams. 
Maybe it is better to restrict the “is_ref_pkt” to 1, only for 
vs->reference_stream_index.
>  } else {
>  av_log(s, AV_LOG_WARNING, "pkt->duration = 0, maybe the hls 
> segment duration will not precise\n");
>  vs->duration = (double)(pkt->pts - vs->end_pts) * 
> st->time_base.num / st->time_base.den;
> @@ -2497,6 +2500,11 @@ static int hls_init(AVFormatContext *s)
>  
>  for (j = 0; j < vs->nb_streams; j++) {
>  vs->has_video += vs->streams[j]->codecpar->codec_type == 
> AVMEDIA_TYPE_VIDEO;
> +/* Get one video stream to reference for split segments
> + * so use the first video stream index. */
> +if (vs->has_video == 1) {
> +vs->reference_stream_index = j;
> +}
This doesn’t look correct. Potentially vs->reference_stream_index could get 
overwritten by audio and/or subtitle stream index.
>  vs->has_subtitle += vs->streams[j]->codecpar->codec_type == 
> AVMEDIA_TYPE_SUBTITLE;
>  }
>  



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

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Use HTTP DELETE for HTTP base proto

[Jeyapal, Karthick]

On 2/27/18 2:48 PM, Serhii Marchuk wrote:
> ---
>  libavformat/dashenc.c | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 83e0cff728..66f12d8d49 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1131,6 +1131,28 @@ static int update_stream_extradata(AVFormatContext *s, 
> OutputStream *os,
>  return 0;
>  }
>  
> +static void dashenc_delete_file(AVFormatContext *s, char *filename) {
> +DASHContext *c = s->priv_data;
> +int http_base_proto = ff_is_http_proto(filename);
> +
> +if (http_base_proto) {
> +AVIOContext *out = NULL;
> +AVDictionary *http_opts = NULL;
> +
> +set_http_options(_opts, c);
> +av_dict_set(_opts, "method", "DELETE", 0);
> +
> +if (dashenc_io_open(s, , filename, _opts) < 0) {
> +av_log(s, AV_LOG_ERROR, "failed to delete %s\n", filename);
> +}
> +
> +av_dict_free(_opts);
> +dashenc_io_close(s, , filename);
> +} else if (unlink(filename) < 0) {
> +av_log(s, AV_LOG_ERROR, "failed to delete %s: %s\n", filename, 
> strerror(errno));
> +}
> +}
> +
>  static int dash_flush(AVFormatContext *s, int final, int stream)
>  {
>  DASHContext *c = s->priv_data;
> @@ -1215,7 +1237,7 @@ static int dash_flush(AVFormatContext *s, int final, 
> int stream)
>  for (j = 0; j < remove; j++) {
>  char filename[1024];
>  snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
> os->segments[j]->file);
> -unlink(filename);
> +dashenc_delete_file(s, filename);
>  av_free(os->segments[j]);
>  }
>  os->nb_segments -= remove;
> @@ -1367,9 +1389,9 @@ static int dash_write_trailer(AVFormatContext *s)
>  for (i = 0; i < s->nb_streams; i++) {
>  OutputStream *os = >streams[i];
>  snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
> os->initfile);
> -unlink(filename);
> +dashenc_delete_file(s, filename);
>  }
> -unlink(s->url);
> +dashenc_delete_file(s, s->url);
>  }
>  
>  return 0;
Thanks for sending the patch. LGTM. 
But let me test it with some of existing servers before the final push, just to 
make sure no existing functionality is broken.



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