Re: [FFmpeg-devel] [PATCH] avfilter/avf_concat: add next command

[Bodecs Bela]

ping


2018.02.25. 17:07 keltezéssel, Bodecs Bela írta:

Dear All,

this patch makes it possible to dinamically close the current segment
and step to the next one by introducing command handling capabilities
into the filter. This new feature is very usefull when working with
real-time sources or live streams as source. Combinig usage with zmqsend
tool you can interactively end the current segment and step to next one.

it is very usefull in case of event streaming when sending an intro 
then a
live section and then an outro and you want to start and stop the live 
event manually.


example:

ffmpeg -re -i very_long_intro.mp4 -i  -re -i 
very_long_outro.mp4
    -filter_complex   '[0:v][0:a] [1:v][1:a] [2:v][2:a] 
concat=n=3:v=1:a=1 [v] [a];
          [v] 
zmq=b=tcp\\:\\/\\/127.0.0.1\\:  [v_out]'

    -map '[v_out]' -map '[a]'  

When you you want to start the live event, issue in another window:
echo "Parsed_concat_0 next" | zmqsend  -b tcp://127.0.0.1:

When you want to end the live session:
echo "Parsed_concat_0 next" | zmqsend  -b tcp://127.0.0.1:


Please review this patch. Thank you in advance.

Bela Bodecs




___
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 1/2] fftools/ffmpeg: fix progress log message in case pts is not available

[Tobias Rapp]

On 27.02.2018 19:03, Michael Niedermayer wrote:

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(-)


[...]

+{
+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


There are two places within print_report() that output 
hour/minute/seconds-formatted time. One is using HH:MM:SS.ZZ format and 
the other one is using HH:MM:SS.ZZ format. Would it be OK to output 
HH:MM:SS.ZZ (two digits after the decimal separator) in both places like 
in the attached patch version?


Regards,
Tobias

From d2141a259d733e9ff8e76f0e33b3e2e449adde14 Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Mon, 26 Feb 2018 16:58:24 +0100
Subject: [PATCH v3] fftools/ffmpeg: fix progress log message in case pts is
 not available

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 3a45f43..f3598ff 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, size_t buf_size, int64_t pts)
+{
+const char *hours_sign;
+int hours, mins, secs, usecs;
+
+if (pts == AV_NOPTS_VALUE) {
+snprintf(buf, buf_size, "N/A");
+} else {
+hours_sign = (pts < 0) ? "-" : "";
+secs = FFABS(pts) / AV_TIME_BASE;
+usecs = FFABS(pts) % AV_TIME_BASE;
+mins = secs / 60;
+secs %= 60;
+hours = mins / 60;
+mins %= 60;
+snprintf(buf, buf_size, "%s%02d:%02d:%02d.%02d",
+ hours_sign, hours, mins, secs, (100 * usecs) / AV_TIME_BASE);
+}
+return buf;
+}
+
 static void print_final_stats(int64_t total_size)
 {
 uint64_t video_size = 0, audio_size = 0, extra_size = 0, other_size = 0;
@@ -1649,7 +1670,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 int64_t pts = INT64_MIN + 1;
 static int64_t last_time = -1;
 static int qp_histogram[52];
-int hours, mins, secs, us;
+char buf_pts[AV_TS_MAX_STRING_SIZE] = {0};
 int ret;
 float t;
 
@@ -1751,25 +1772,15 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 nb_frames_drop += ost->last_dropped;
 }
 
-secs = FFABS(pts) / AV_TIME_BASE;
-us = FFABS(pts) % AV_TIME_BASE;
-mins = secs / 60;
-secs %= 60;
-hours = mins / 60;
-mins %= 60;
-
 bitrate = pts && total_size >= 0 ? total_size * 8 / (pts / 1000.0) : -1;
 speed = t != 0.0 ? (double)pts / AV_TIME_BASE / t : -1;
 
 if (total_size < 0) snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf),
- "size=N/A time=");
+ "size=N/A ");
 elsesnprintf(buf + strlen(buf), sizeof(buf) - strlen(buf),
- "size=%8.0fkB time=", total_size / 1024.0);
-if (pts < 0)
-snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), "-");
+ "size=%8.0fkB ", total_size / 1024.0);
 snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf),
- "%02d:%02d:%02d.%02d ", hours, mins, secs,
- (100 * us) / AV_TIME_BASE);
+ "time=%s ", pts_to_hms_str(buf_pts, sizeof(buf_pts), pts));
 
 if (bitrate < 0) {
 snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf),"bitrate=N/A");
@@ -1781,9 +1792,12 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 
 if (total_size < 0) av_bprintf(&buf_script, "total_size=N/A\n");
 elseav_bprintf(&buf_script, "total_s

[FFmpeg-devel] [PATCH] doc/outdevs: Add declink signal generator example

[Mike Goins]

Signed-off-by: Mike Goins 
---
 doc/outdevs.texi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index daf7b1ae62..1ca81ba139 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -180,6 +180,13 @@ Play video clip with non-standard framerate or video size:
 ffmpeg -i test.avi -f decklink -pix_fmt uyvy422 -s 720x486 -r 24000/1001 
'DeckLink Mini Monitor'
 @end example
 
+@item
+Signal Generator mode:
+@example
+ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=3/1000" -f lavfi -i 
"sine=frequency=1000:sample_rate=48000" 
+-ac 2 -acodec pcm_s16le -pix_fmt uyvy422 -format_code Hi30 -f decklink 
'DeckLink Studio 2'
+@end example
+
 @end itemize
 
 @section libndi_newtek
-- 
2.16.2

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

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

[Steven Liu]

> On 28 Feb 2018, at 08:26, Jun Zhao  wrote:
> 
> ping
> 
> On 2018/2/23 15:12, Jun Zhao wrote:
> 

Signed-off-by: Jun Zhao 
---
 doc/bitstream_filters.texi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 5efb8e0ee8..9c7d86eb39 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -50,19 +50,20 @@ DTS-HD.
 
 Add extradata to the beginning of the filtered packets.
 
+@table @option
+@item freq
 The additional argument specifies which packets should be filtered.
 It accepts the values:
 @table @samp
-@item a
-add extradata to all key packets, but only if @var{local_header} is
-set in the @option{flags2} codec context field
-
 @item k
+@item keyframe
 add extradata to all key packets
 
 @item e
+@item all
 add extradata to all packets
 @end table
+@end table
 
 If not specified it is assumed @samp{k}.
 
-- 
2.14.1



LGTM


Thanks
Steven





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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_concat: add next command

[Liu Steven]

> 在 2018年2月28日，下午4:10，Bodecs Bela  写道：
> 
> ping

LGTM
> 
> 
> 2018.02.25. 17:07 keltezéssel, Bodecs Bela írta:
>> Dear All,
>> 
>> this patch makes it possible to dinamically close the current segment
>> and step to the next one by introducing command handling capabilities
>> into the filter. This new feature is very usefull when working with
>> real-time sources or live streams as source. Combinig usage with zmqsend
>> tool you can interactively end the current segment and step to next one.
>> 
>> it is very usefull in case of event streaming when sending an intro then a
>> live section and then an outro and you want to start and stop the live event 
>> manually.
>> 
>> example:
>> 
>> ffmpeg -re -i very_long_intro.mp4 -i  -re -i 
>> very_long_outro.mp4
>> -filter_complex   '[0:v][0:a] [1:v][1:a] [2:v][2:a] concat=n=3:v=1:a=1 
>> [v] [a];
>>   [v] zmq=b=tcp\\:\\/\\/127.0.0.1\\:  
>> [v_out]'
>> -map '[v_out]' -map '[a]'  
>> 
>> When you you want to start the live event, issue in another window:
>> echo "Parsed_concat_0 next" | zmqsend  -b tcp://127.0.0.1:
>> 
>> When you want to end the live session:
>> echo "Parsed_concat_0 next" | zmqsend  -b tcp://127.0.0.1:
>> 
>> 
>> Please review this patch. Thank you in advance.
>> 
>> Bela Bodecs
>> 
>> 
>> 
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [PATCH 2/3 v1.1] avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding

[Jerome Borsboom]

On 25/02/18 19:12, Jerome Borsboom wrote:

avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding

Pass necessary bitstream elements to the VAAPI VC-1 decoder in order
to start doing interlaced decoding in hardware.

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vaapi_vc1.c | 167 -
 1 file changed, 138 insertions(+), 29 deletions(-)

diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
index 525376790e..a137979dd4 100644
--- a/libavcodec/vaapi_vc1.c
+++ b/libavcodec/vaapi_vc1.c
@@ -44,7 +44,8 @@ static inline int vc1_has_MVTYPEMB_bitplane(const VC1Context 
*v)




 
+#if VA_CHECK_VERSION(1, 1, 0)


IMO it would be preferable not to guard this function with the libva version 
check - it doesn't depend on anything about libva (it's only the use of it that 
does), so it would be better if it's always built and the compiler can 
eliminate it later.

(Mark them with av_unused to avoid the warning.)



OK. Will change and resubmit.


+static inline int vc1_get_INTCOMPFIELD(const VC1Context *v)
+{
+if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
+v->fcm == ILACE_FIELD &&
+v->mv_mode == MV_PMODE_INTENSITY_COMP)
+switch (v->intcompfield) {
+case 1: return 1;
+case 2: return 2;
+case 3: return 0;
+}
+return 0;
+}
+#endif
+


>


Is this expected to pass the two fate tests for VC-1 interlaced, 
fate-vc1_sa10143 and fate-vc1_ilaced_twomv?  (It doesn't on my system, all 
output frames are different.)  If not, could you explain why not?

Thanks,

- Mark


I have a feeling that the software decoder in FFmpeg is not fully 
compliant with the VC-1 spec. The loopfilter, as currently implemented, 
may be wrong for interlaced content. I am still investigating this issue.


As far as I can see, there are no visual differences between the output 
of the software decoded and the hardware decoded images.



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

Re: [FFmpeg-devel] [PATCH v3] avformat/pcm: decrease delay when reading PCM streams.

[Philipp M. Scholl]

Anything holding this patch back from being applied?

cheers,
 -phil

On Fri, Feb 16, 2018 at 02:13:16PM +0100, Tomas Härdin wrote:
> On 2018-02-16 14:04, Philipp M. Scholl wrote:
> > Version 3 of the PCM delay patch with further feedback included.
> > 
> > Still not sure about the ramifications of smaller blocksizes in fate. Hence 
> > the
> > tests are also changed.
> 
> Code looks good. Can't say anything about the tests however
> 
> /Tomas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Eingebettete Systeme - Universität Freiburg
https://es.informatik.uni-freiburg.de
Tel: +49 761 203-98-587


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

Re: [FFmpeg-devel] [PATCH v3] avformat/pcm: decrease delay when reading PCM streams.

[Tomas Härdin]

On 2018-02-28 17:37, Philipp M. Scholl wrote:

Anything holding this patch back from being applied?

cheers,
  -phil

On Fri, Feb 16, 2018 at 02:13:16PM +0100, Tomas Härdin wrote:

On 2018-02-16 14:04, Philipp M. Scholl wrote:

Version 3 of the PCM delay patch with further feedback included.

Still not sure about the ramifications of smaller blocksizes in fate. Hence the
tests are also changed.

Code looks good. Can't say anything about the tests however

/Tomas


Might want someone with a better grasp over FATE to chime in

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

Re: [FFmpeg-devel] [PATCH 2/3 v1.1] avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding

[Hendrik Leppkes]

On Wed, Feb 28, 2018 at 9:48 AM, Jerome Borsboom
 wrote:
>> Is this expected to pass the two fate tests for VC-1 interlaced,
>> fate-vc1_sa10143 and fate-vc1_ilaced_twomv?  (It doesn't on my system, all
>> output frames are different.)  If not, could you explain why not?
>>
>> Thanks,
>>
>> - Mark
>
>
> I have a feeling that the software decoder in FFmpeg is not fully compliant
> with the VC-1 spec. The loopfilter, as currently implemented, may be wrong
> for interlaced content. I am still investigating this issue.
>
> As far as I can see, there are no visual differences between the output of
> the software decoded and the hardware decoded images.
>
>

If you have the ability, you could compare the test hash output to
D3D11/DXVA2 decoding on Windows.
Or I could post those frame hashes later when I get back home for
comparison purposes.

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

[FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Michael Niedermayer]

The widget has new content.

This reverts commit 9275cd54eddb83faf5bd40ffaccb5717de8b798d.
---
 src/template_head2 | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/template_head2 b/src/template_head2
index a0b11ab..71daf07 100644
--- a/src/template_head2
+++ b/src/template_head2
@@ -3,6 +3,29 @@
   
   
 

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Ricardo Constantino]

On 28 February 2018 at 17:17, Michael Niedermayer 
wrote:

> The widget has new content.
>

Does it shut itself up when the time's passed now?
Or check if the visitor's IP isn't from USA?


>
> This reverts commit 9275cd54eddb83faf5bd40ffaccb5717de8b798d.
> ---
>  src/template_head2 | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/src/template_head2 b/src/template_head2
> index a0b11ab..71daf07 100644
> --- a/src/template_head2
> +++ b/src/template_head2
> @@ -3,6 +3,29 @@
>
>
>  

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[wm4]

On Wed, 28 Feb 2018 18:17:42 +0100
Michael Niedermayer  wrote:

> The widget has new content.
> 
> This reverts commit 9275cd54eddb83faf5bd40ffaccb5717de8b798d.
> ---
>  src/template_head2 | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/src/template_head2 b/src/template_head2
> index a0b11ab..71daf07 100644
> --- a/src/template_head2
> +++ b/src/template_head2
> @@ -3,6 +3,29 @@
>
>
>  

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Michael Niedermayer]

On Wed, Feb 28, 2018 at 06:28:44PM +, Ricardo Constantino wrote:
> On 28 February 2018 at 17:17, Michael Niedermayer 
> wrote:
> 
> > The widget has new content.
> >
> 

> Does it shut itself up when the time's passed now?

we can disable it manually easily if it does not


> Or check if the visitor's IP isn't from USA?

that is not always possible nor is the IP of the computer
neccessarily from the same contry as the nationality of
the human using the computer.

Raising a bit awareness about this even if it does not YET affect
people outside the USA doesnt seem to be that bad to me.
Because if net neutrality falls in the US, others will
(try to) copy it. The EU has a history of copying dumb decissions
even if they where corrected already from the US ... id like to
put a smily here but its just not funny from my point of view
from the EU ...

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Ricardo Constantino]

On 28 February 2018 at 19:13, Michael Niedermayer 
wrote:

> On Wed, Feb 28, 2018 at 06:28:44PM +, Ricardo Constantino wrote:
> > On 28 February 2018 at 17:17, Michael Niedermayer  >
> > wrote:
> >
> > > The widget has new content.
> > >
> >
>
> > Does it shut itself up when the time's passed now?
>
> we can disable it manually easily if it does not
>
>
> > Or check if the visitor's IP isn't from USA?
>
> that is not always possible nor is the IP of the computer
> neccessarily from the same contry as the nationality of
> the human using the computer.
>
> Raising a bit awareness about this even if it does not YET affect
> people outside the USA doesnt seem to be that bad to me.
> Because if net neutrality falls in the US, others will
> (try to) copy it. The EU has a history of copying dumb decissions
> even if they where corrected already from the US ... id like to
> put a smily here but its just not funny from my point of view
> from the EU ...
>

That still doesn't fix the issue that non-US people can't affect it or do
any action other than tell about it on social media, which worked well
enough for the US election.

What about the fact that the time's past? Or is it another date?


>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you think the mosad wants you dead since a long time then you are either
> wrong or dead since a long time.
>
> ___
> 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 v3] avformat/pcm: decrease delay when reading PCM streams.

[Marton Balint]

On Wed, 28 Feb 2018, Philipp M. Scholl wrote:


Anything holding this patch back from being applied?


It does not pass fate for me. Are you sure you updated the fate test 
results in the patch after your changes?


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

Re: [FFmpeg-devel] [PATCH v3] avformat/pcm: decrease delay when reading PCM streams.

[Marton Balint]

On Wed, 28 Feb 2018, Marton Balint wrote:



On Wed, 28 Feb 2018, Philipp M. Scholl wrote:


Anything holding this patch back from being applied?


It does not pass fate for me. Are you sure you updated the fate test 
results in the patch after your changes?


And if you are preparing a new patch, please update the name of your 
AVCodecParameters * variable to "codecpar" or "par" instead of "codec".


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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Michael Niedermayer]

On Wed, Feb 28, 2018 at 07:39:23PM +0100, wm4 wrote:
> On Wed, 28 Feb 2018 18:17:42 +0100
> Michael Niedermayer  wrote:
> 
> > The widget has new content.
> > 
> > This reverts commit 9275cd54eddb83faf5bd40ffaccb5717de8b798d.
> > ---
> >  src/template_head2 | 23 +++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/src/template_head2 b/src/template_head2
> > index a0b11ab..71daf07 100644
> > --- a/src/template_head2
> > +++ b/src/template_head2
> > @@ -3,6 +3,29 @@
> >
> >
> >  

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Jan Ekström]

On Wed, Feb 28, 2018 at 7:17 PM, Michael Niedermayer
 wrote:
> +https://widget.battleforthenet.com/widget.js"; 
> async>

Please use 
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
. That way this third-party entity will only get loaded if the content
matches a known checksum. Even better, host it locally.

(I have not checked if ffmpeg.org loads other sub-resources, but they
should get a similar treatment in general)

Personally, looking at the last year's fiasco of it not remembering
that you had already closed it, as well as showing up after the
"event" I am against this. But if someone thinks this is absolutely
necessary, we should at least take minimal steps to keep sub-resource
contamination at bay.

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Michael Niedermayer]

On Wed, Feb 28, 2018 at 07:17:25PM +, Ricardo Constantino wrote:
> On 28 February 2018 at 19:13, Michael Niedermayer 
> wrote:
> 
> > On Wed, Feb 28, 2018 at 06:28:44PM +, Ricardo Constantino wrote:
> > > On 28 February 2018 at 17:17, Michael Niedermayer  > >
> > > wrote:
> > >
> > > > The widget has new content.
> > > >
> > >
> >
> > > Does it shut itself up when the time's passed now?
> >
> > we can disable it manually easily if it does not
> >
> >
> > > Or check if the visitor's IP isn't from USA?
> >
> > that is not always possible nor is the IP of the computer
> > neccessarily from the same contry as the nationality of
> > the human using the computer.
> >
> > Raising a bit awareness about this even if it does not YET affect
> > people outside the USA doesnt seem to be that bad to me.
> > Because if net neutrality falls in the US, others will
> > (try to) copy it. The EU has a history of copying dumb decissions
> > even if they where corrected already from the US ... id like to
> > put a smily here but its just not funny from my point of view
> > from the EU ...
> >
> 
> That still doesn't fix the issue that non-US people can't affect it or do
> any action other than tell about it on social media, which worked well
> enough for the US election.

yes, if you have a better idea, the place to discuss this would be someplace
related to the widget. Maybe a issue on its github page

Discussing this here wont help many no matter what the outcome

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Michael Niedermayer]

On Wed, Feb 28, 2018 at 09:52:19PM +0200, Jan Ekström wrote:
> On Wed, Feb 28, 2018 at 7:17 PM, Michael Niedermayer
>  wrote:
> > +https://widget.battleforthenet.com/widget.js"; 
> > async>
> 
> Please use 
> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
> . That way this third-party entity will only get loaded if the content
> matches a known checksum. Even better, host it locally.

As the widget is activly developed, this is not easy
for example there where multiple commits to its repository in the last
24h


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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

[FFmpeg-devel] [PATCH][RFC] Improve and fix put_vc2_ue_uint() function.

[Ivan Kalvachev]

Replace two bit handling loops and internal conditional branch
with simple formula using few logical operations.

The old function would generate wrong output
if the input does not fit into 15 bits.

Fix this by using 64 bit math and put_bits64().
This case should be quite rare, since the bug
has not asserted itself.

---
It's attempt for speed optimization, but in the
process it turned out it needs also bugfixing.

I only tested the old case of the code,
to confirm i've implemented the correct function.

Haven't done any benchmarks or run fate.

It should be faster, especially because currently coefficients bellow
2048 are written using lookup table and bypass this function.

If you like it, use it.

Best Regards
   Ivan Kalvachev.
From 1f7fd38fcb6c64281bc458c09c711fc567b3ef0f Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Wed, 28 Feb 2018 17:48:40 +0200
Subject: [PATCH] Improve and fix put_vc2_ue_uint() function.

Replace two bit handling loops and internal conditional branch
with simple formula using few logical operations.

The old function would generate wrong output
if the input does not fit into 15 bits.

Fix this by using 64 bit math and put_bits64().
This case should be quite rare, since the bug
has not asserted itself.

Signed-off-by: Ivan Kalvachev 
---
 libavcodec/vc2enc.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index b7adcd3d36..b2f1611ea3 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -187,28 +187,33 @@ typedef struct VC2EncContext {
 
 static av_always_inline void put_vc2_ue_uint(PutBitContext *pb, uint32_t val)
 {
-int i;
-int pbits = 0, bits = 0, topbit = 1, maxval = 1;
+int bits = 0;
+uint64_t pbits = 0;
 
 if (!val++) {
 put_bits(pb, 1, 1);
 return;
 }
 
-while (val > maxval) {
-topbit <<= 1;
-maxval <<= 1;
-maxval |=  1;
-}
+bits = ff_log2(val);
 
-bits = ff_log2(topbit);
+if (bits > 15) {
+pbits = val;
 
-for (i = 0; i < bits; i++) {
-topbit >>= 1;
-pbits <<= 2;
-if (val & topbit)
-pbits |= 0x1;
+pbits = ((pbits<<16)|pbits)&0xULL;
+pbits = ((pbits<< 8)|pbits)&0x00FF00FF00FF00FFULL;
+pbits = ((pbits<< 4)|pbits)&0x0F0F0F0F0F0F0F0FULL;
+pbits = ((pbits<< 2)|pbits)&0xULL;
+pbits = ((pbits<< 1)|pbits)&0xULL;
+
+put_bits64(pb, bits*2 + 1, (pbits << 1) | 1);
+return;
 }
+ // ' ' ponm'lkji hgfe'dcba
+val = ( (val << 8) | val ) & 0x00FF00FF; // ' ponm'lkji ' hgfe'dcba
+val = ( (val << 4) | val ) & 0x0F0F0F0F; // 'ponm 'lkji 'hgfe 'dcba
+val = ( (val << 2) | val ) & 0x; // __po'__nm __lk'__ji __hg'__fe __dc'__ba
+val = ( (val << 1) | val ) & 0x; // _p_o'_n_m _l_k'_j_i _h_g'_f_e _d_c'_b_a
 
 put_bits(pb, bits*2 + 1, (pbits << 1) | 1);
 }
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[wm4]

On Wed, 28 Feb 2018 21:00:27 +0100
Michael Niedermayer  wrote:

> On Wed, Feb 28, 2018 at 07:17:25PM +, Ricardo Constantino wrote:
> > On 28 February 2018 at 19:13, Michael Niedermayer 
> > wrote:
> >   
> > > On Wed, Feb 28, 2018 at 06:28:44PM +, Ricardo Constantino wrote:  
> > > > On 28 February 2018 at 17:17, Michael Niedermayer 
> > > >  > > >
> > > > wrote:
> > > >  
> > > > > The widget has new content.
> > > > >  
> > > >  
> > >  
> > > > Does it shut itself up when the time's passed now?  
> > >
> > > we can disable it manually easily if it does not
> > >
> > >  
> > > > Or check if the visitor's IP isn't from USA?  
> > >
> > > that is not always possible nor is the IP of the computer
> > > neccessarily from the same contry as the nationality of
> > > the human using the computer.
> > >
> > > Raising a bit awareness about this even if it does not YET affect
> > > people outside the USA doesnt seem to be that bad to me.
> > > Because if net neutrality falls in the US, others will
> > > (try to) copy it. The EU has a history of copying dumb decissions
> > > even if they where corrected already from the US ... id like to
> > > put a smily here but its just not funny from my point of view
> > > from the EU ...
> > >  
> > 
> > That still doesn't fix the issue that non-US people can't affect it or do
> > any action other than tell about it on social media, which worked well
> > enough for the US election.  
> 
> yes, if you have a better idea, the place to discuss this would be someplace
> related to the widget. Maybe a issue on its github page
> 
> Discussing this here wont help many no matter what the outcome

If they don't listen to our requests, but you insist on using their
code, then I can't accept this patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Jan Ekström]

On Wed, Feb 28, 2018 at 10:10 PM, Michael Niedermayer
 wrote:
> On Wed, Feb 28, 2018 at 09:52:19PM +0200, Jan Ekström wrote:
>> On Wed, Feb 28, 2018 at 7:17 PM, Michael Niedermayer
>>  wrote:
>> > +https://widget.battleforthenet.com/widget.js"; 
>> > async>
>>
>> Please use 
>> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
>> . That way this third-party entity will only get loaded if the content
>> matches a known checksum. Even better, host it locally.
>
> As the widget is activly developed, this is not easy
> for example there where multiple commits to its repository in the last
> 24h
>

Looking at how much it got updated the last time when it misbehaved
shows really well how that worked the last time. Sorry if I sound
facetious, but I do use ffmpeg-all.html a lot and it got /really/
irritating.

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Ronald S. Bultje]

Hi,

On Wed, Feb 28, 2018 at 12:17 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> The widget has new content.


Could you elaborate on what the new content is? What political campaign
will we as project members support by applying this patch?

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Michael Niedermayer]

On Wed, Feb 28, 2018 at 03:25:51PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Feb 28, 2018 at 12:17 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> 
> > The widget has new content.
> 
> 
> Could you elaborate on what the new content is? 

yes, of course


> What political campaign
> will we as project members support by applying this patch?

Its the same goal as previous, to protect net neutrality
ATM IIUC one more vote is needed in the senate
Its certainly imaginable that in a few days something else will be
suggested by the widget to protect net neutrality as the situation
changes ...

Thats also why its not usfull at all to copy this widget locally or
to use a checksum on it. It has to be able to adapt to changes in the
political situation surrounding net neutrality

Thanks


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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Ricardo Constantino]

On 28 February 2018 at 20:41, Michael Niedermayer 
wrote:

> On Wed, Feb 28, 2018 at 03:25:51PM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Feb 28, 2018 at 12:17 PM, Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> >
> > > The widget has new content.
> >
> >
> > Could you elaborate on what the new content is?
>
> yes, of course
>
>
> > What political campaign
> > will we as project members support by applying this patch?
>
> Its the same goal as previous, to protect net neutrality
> ATM IIUC one more vote is needed in the senate
> Its certainly imaginable that in a few days something else will be
> suggested by the widget to protect net neutrality as the situation
> changes ...
>

Except most of the information in
https://www.battleforthenet.com/onemorevote/ only mentions yesterday's date.
So what's the point of adding this now?


>
> Thats also why its not usfull at all to copy this widget locally or
> to use a checksum on it. It has to be able to adapt to changes in the
> political situation surrounding net neutrality
>
> Thanks
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Asymptotically faster algorithms should always be preferred if you have
> asymptotical amounts of data
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] In a stream, is there a way to wait some time before playing next packet after the previous one ended?

[kprz]

Hi FFmpeg team   Is there a way to force FFmpeg not to play next packet right 
after the previous one ended, but wait set amount of time before playing next 
packet instead?   Real-life example follows:  Recently I found certain 
IFF-files containing both audio and video data. Current releases of FFmpeg 
playing only one of the streams (which in itself would constitute a bug, I 
suppose, but it is out of scope of this post), so I decided to attempt at 
fixing it. Until now I was able to rewrite libavformat/iff.c to:  1. correctly 
identify and create both audio and video streams  2. split contents into 
distinct packets assigned to correct streams  3. play both streams alongside  
However, one issue still remains.  Video stream in the files is, should I say, 
continuous. That is, video packets are decoded and played in given order, 
without any gaps and pauses. Thus video stream defines the duration of the 
clip. On the other hand, audio stream is not continuous. Instead, audio samples 
(sounds) are supposed to be played only at points in time defined in video 
frames. Most importantly, there are periods in video playback with no audio 
sample assigned - no audio at all should be played.  The expected result would 
be periods of silence between audio packets, when only video is being played. 
The actual result is that as soon as the playback of the file starts, all audio 
packets are played in correct order, but one after the other, with no pauses 
inbetween.   I experimented with setting audio packet pts manually, but it did 
not resolve the issue. The result remained the same.   Best regards   kprz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Lou Logan]

On Wed, Feb 28, 2018, at 11:25 AM, Jan Ekström wrote:
> 
> Looking at how much it got updated the last time when it misbehaved
> shows really well how that worked the last time. Sorry if I sound
> facetious, but I do use ffmpeg-all.html a lot and it got /really/
> irritating.

+1.

I object to the patch. The widget is annoyingly intrusive, but as a compromise 
I would not block a small, resized, temporary simple image banner in the bottom 
of the menu:


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

Re: [FFmpeg-devel] [PATCH][RFC] Improve and fix put_vc2_ue_uint() function.

[Michael Niedermayer]

On Wed, Feb 28, 2018 at 10:14:15PM +0200, Ivan Kalvachev wrote:
> Replace two bit handling loops and internal conditional branch
> with simple formula using few logical operations.
> 
> The old function would generate wrong output
> if the input does not fit into 15 bits.
> 
> Fix this by using 64 bit math and put_bits64().
> This case should be quite rare, since the bug
> has not asserted itself.
> 
> ---
> It's attempt for speed optimization, but in the
> process it turned out it needs also bugfixing.
> 
> I only tested the old case of the code,
> to confirm i've implemented the correct function.
> 
> Haven't done any benchmarks or run fate.

fate fails:

make fate-vsynth1-vc2-420p 
TESTvsynth1-vc2-420p
--- ./tests/ref/vsynth/vsynth1-vc2-420p 2018-02-27 23:48:20.527608799 +0100
+++ tests/data/fate/vsynth1-vc2-420p2018-02-28 23:16:02.250764645 +0100
@@ -1,4 +1,2 @@
-fb8fffcfc17558c87dd11a67ccb0f615 *tests/data/fate/vsynth1-vc2-420p.mov
+f24243a627788000de7147d38880d019 *tests/data/fate/vsynth1-vc2-420p.mov
 1155415 tests/data/fate/vsynth1-vc2-420p.mov
-387696707c79cf1a6c9aeff4024226b9 *tests/data/fate/vsynth1-vc2-420p.out.rawvideo
-stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  7603200/   760320
Test vsynth1-vc2-420p failed. Look at tests/data/fate/vsynth1-vc2-420p.err for 
details.
make: *** [fate-vsynth1-vc2-420p] Error 69


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] In a stream, is there a way to wait some time before playing next packet after the previous one ended?

[Carl Eugen Hoyos]

2018-02-28 21:53 GMT+01:00 kprz :
> 1. correctly identify and create both audio and video streams

If you send this as a patch made with "git format-patch" to this
mailing list, it may be easier to test and answer your questions.

For some use-cases, setting time-stamps will be enough, for
most cases, inserting silence (which should not be hard) will
be necessary.

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

Re: [FFmpeg-devel] [PATCH 2/3 v1.1] avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding

[Carl Eugen Hoyos]

2018-02-28 9:48 GMT+01:00 Jerome Borsboom :

>> Is this expected to pass the two fate tests for VC-1 interlaced,
>> fate-vc1_sa10143 and fate-vc1_ilaced_twomv?  (It doesn't on
>> my system, all output frames are different.)  If not, could you
>> explain why not?

They are expected to change for compliant decoders.

> I have a feeling that the software decoder in FFmpeg is not
> fully compliant with the VC-1 spec.

Your suspicion is correct, the software decoder is not compliant,
fate tests are not relevant for this use-case.

I believe the mailing list archive contains the correct values
but it is simpler to wait for Hendrik to confirm.

> The loopfilter, as currently implemented, may be wrong
> for interlaced content. I am still investigating this issue.

This also sounds correct, could be checked with the
reference decoder and -skip_loop_filter.

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

[FFmpeg-devel] Adding a new output device

[Philip Prindeville]

Hi,

I’m working on network test and measurement and I’ve been tasked to write a 
test suite for streaming video performance.

This will run inside headless embedded devices (i.e. routers, probes, etc) so 
has no hardware to render to.  It’s the streaming itself and the end-to-end 
network transport that I’m interested in, observing jitter, stalls, etc.

To that end, I wanted to write an output device that I can select as the output 
driver to which the stream will be parsed and synchronized to the appropriate 
frame rate, collect statistics for CBR/VBR/ABR, etc. but which doesn’t actually 
do any rendering.

Whatever I write I’ll upstream, but it seems like it might be generically 
useful.

I’m a network head and I’ve hacked DVB-S, so I’m vaguely familiar with MPEG-4 
AVC stream format.  I want to inspect enough of the stream to be able to ensure 
synchronization with the frame rate, correctness of the stream, etc. but not 
the expensive/unnecessary parts.

Any guidance for someone jumping into this for the first time?

Thanks,

-Philip

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

Re: [FFmpeg-devel] Adding a new output device

[Nicolas George]

Philip Prindeville (2018-02-28):
> I’m working on network test and measurement and I’ve been tasked to
> write a test suite for streaming video performance.
> 
> This will run inside headless embedded devices (i.e. routers, probes,
> etc) so has no hardware to render to.  It’s the streaming itself and
> the end-to-end network transport that I’m interested in, observing
> jitter, stalls, etc.
> 
> To that end, I wanted to write an output device that I can select as
> the output driver to which the stream will be parsed and synchronized
> to the appropriate frame rate, collect statistics for CBR/VBR/ABR,
> etc. but which doesn’t actually do any rendering.
> 
> Whatever I write I’ll upstream, but it seems like it might be
> generically useful.
> 
> I’m a network head and I’ve hacked DVB-S, so I’m vaguely familiar with
> MPEG-4 AVC stream format.  I want to inspect enough of the stream to
> be able to ensure synchronization with the frame rate, correctness of
> the stream, etc. but not the expensive/unnecessary parts.
> 
> Any guidance for someone jumping into this for the first time?

Quick answer: look if "ffmpeg -i ... -f framecrc -" could be a good base
for your project; and look at -f null for the wrapped-frame
optimization. If you work at the muxer level, you do not need to know
anything about the bitstream format.

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 5/9] sbc: implement SBC encoder (low-complexity subband codec)

[Aurelien Jacobs]

On Wed, Feb 28, 2018 at 12:59:40AM +, Rostislav Pehlivanov wrote:
> 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.
> >
> >
> I think you ought to use a float for this, like:
> 
> >{ "sbc_delay", "Maximum delay in milliseconds", offsetof(,
> ), AV_OPT_TYPE_FLOAT, { .dbl =  }, ,
> , ,  },

Why would I want to use float for this ??
AV_OPT_TYPE_DURATION is more appropriate for this. It has microsecond
precision which is more than enough, and you can still use a "float"
string as a parameter (eg. -sbc_delay 0.0035 for a 3.5 ms maximum delay).

> 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()?

I seem to remember there was a good reason for this initially, but the
code went thru quite some refactoring since then, and there is no good
reason for this anymore.
I've now cleaned up and simplified this init code.
>From 64ee3867bf8f90d51734d1ee2de4b09f471308b4 Mon Sep 17 00:00:00 2001
From: Aurelien Jacobs 
Date: Sun, 17 Dec 2017 19:59:30 +0100
Subject: [PATCH 5/9] sbc: implement SBC encoder (low-complexity subband codec)

This was originally based on libsbc, and was fully integrated into ffmpeg.
---
 doc/general.texi   |   2 +-
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/avcodec.h   |   2 +
 libavcodec/options_table.h |   1 +
 libavcodec/profiles.c  |   5 +
 libavcodec/profiles.h  |   1 +
 libavcodec/sbcdsp.c| 382 +
 libavcodec/sbcdsp.h|  83 ++
 libavcodec/sbcdsp_data.c   | 329 ++
 libavcodec/sbcdsp_data.h   |  55 +++
 libavcodec/sbcenc.c| 361 ++
 12 files changed, 1222 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

diff --git a/doc/general.texi b/doc/general.texi
index 5827af3841..de13a7695e 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1142,7 +1142,7 @@ following image formats are supported:
 @tab Real low bitrate AC-3 codec
 @item RealAudio Lossless @tab @tab  X
 @item RealAudio SIPR / ACELP.NET @tab @tab  X
-@item SBC (low-complexity subband codec) @tab @tab  X
+@item SBC (low-complexity subband codec) @tab  X  @tab  X
 @tab Used in Bluetooth A2DP
 @item Shorten@tab @tab  X
 @item Sierra VMD audio   @tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 01bc15d9b7..ff6c9f8b2c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -588,6 +588,7 @@ OBJS-$(CONFIG_SUNRAST_DECODER) += sunrast.o
 OBJS-$(CONFIG_SUNRAST_ENCODER) += sunrastenc.o
 OBJS-$(CONFIG_LIBRSVG_DECODER) += librsvgdec.o
 OBJS-$(CONFIG_SBC_DECODER) += sbcdec.o sbcdec_data.o sbc.o
+OBJS-$(CONFIG_SBC_ENCODER) += sbcenc.o sbc.o sbcdsp.o sbcdsp_data.o
 OBJS-$(CONFIG_SVQ1_DECODER)+= svq1dec.o svq1.o svq13.o h263data.o
 OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o  h263data.o  \
   h263.o ituh263enc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4ddf92f006..71719595c6 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -453,6 +453,7 @@ extern AVCodec ff_ra_144_encoder;
 extern AVCodec ff_ra_144_decoder;
 extern AVCodec ff_ra_288_decoder;
 extern AVCodec ff_ralf_decoder;
+extern AVCodec ff_sbc_encoder;
 extern AVCodec ff_sbc_decoder;
 extern AVCodec ff_shorten_decoder;
 extern AVCodec ff_sipr_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 769f210c07..a8322fb62a 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2926,6 +2926,8 @@ typedef struct AVCodecContext {
 #define FF_PROFILE_MJPEG_HUFFMAN_LOSSLESS0xc3
 #define FF_PROFILE_MJPEG_JPEG_LS 0xf7
 
+#define FF_PROFILE_SBC_MSBC 1
+
 /**
  * level
  * - encoding: Set by user.
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index ac9ce4b301..5a5eae65fb 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -300,6 +300,7 @@ static const AVOption avcodec_options[] = {
 {"mpeg4_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_MAIN }, INT_MIN, INT_MAX, V|E, "profile"},
 {"mpeg4_asp",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_ADVANCED_SIMPLE }, INT_MIN, INT_MAX, V|E, "profile"},
 {"main10",  NULL, 0, AV_

Re: [FFmpeg-devel] Adding a new output device

[Philip Prindeville]

> On Feb 28, 2018, at 4:12 PM, Nicolas George  wrote:
> 
> Philip Prindeville (2018-02-28):
>> I’m working on network test and measurement and I’ve been tasked to
>> write a test suite for streaming video performance.
>> 
>> This will run inside headless embedded devices (i.e. routers, probes,
>> etc) so has no hardware to render to.  It’s the streaming itself and
>> the end-to-end network transport that I’m interested in, observing
>> jitter, stalls, etc.
>> 
>> To that end, I wanted to write an output device that I can select as
>> the output driver to which the stream will be parsed and synchronized
>> to the appropriate frame rate, collect statistics for CBR/VBR/ABR,
>> etc. but which doesn’t actually do any rendering.
>> 
>> Whatever I write I’ll upstream, but it seems like it might be
>> generically useful.
>> 
>> I’m a network head and I’ve hacked DVB-S, so I’m vaguely familiar with
>> MPEG-4 AVC stream format.  I want to inspect enough of the stream to
>> be able to ensure synchronization with the frame rate, correctness of
>> the stream, etc. but not the expensive/unnecessary parts.
>> 
>> Any guidance for someone jumping into this for the first time?
> 
> Quick answer: look if "ffmpeg -i ... -f framecrc -" could be a good base
> for your project; and look at -f null for the wrapped-frame
> optimization. If you work at the muxer level, you do not need to know
> anything about the bitstream format.
> 
> Regards,
> 
> -- 
>  Nicolas George


Thanks, I’ll look at it shortly.

Will that level (muxer) give me visibility into synchronization so I can pace 
playback to 1:1 rate?

-Philip


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

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

[Michael Niedermayer]

On Tue, Feb 27, 2018 at 11:12:33PM +, Rostislav Pehlivanov wrote:
> 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(-)
[...]

> @@ -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)

This needs more () otherwise this will misbehave with many
expressions, for example a+b in mul would be a+b*c not (a+b)*c

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [mpegaudio_parser] Skip trailing junk data when flushing parser.

[Dale Curtis]

On Mon, Feb 26, 2018 at 3:07 PM, Michael Niedermayer  wrote:
>
> The way parsers are intended to work (that is years ago and i dont remember
> that there was a proposal to change this)
> is to never drop data. Thats how the stuff was intended to work.
>
> On top of that it was sometimes convenient to just drop data in a Parser,
> or
> a Parser was sloppy implemented and unintentionally looses data.
>
> To awnser the above question, i dont think the mp3 parser can just be
> changed
> alone. As other code like for example muxers depend on some tags being
> discarded.
> So any change has to be done with some care.
>
> not specific to just mp3 but all parsers,
> droping data the parser does not understand is bad though.
> it can be an extension that some decoders could use
> it can be damaged data that a decoder can partly recover and improve the
> output
> it can be some data that is invalid in that location (like midstream
> metadata
> changes in some formats) but that still contains valuable data and that
> would
> be lost even if the components downstream in a player are able to
> interpret it.
>
> Thus for me droping data in a parser is something that i prefer to avoid.
> Unless "not droping" would cause noticably more problems ...
>
>
Thanks for the information. I agree that seems reasonable, but is a
significant API change to the current system that, as you note, extends
beyond just the mp3 parser. It's certainly outside of the scope of things I
can sign up for at this time. While I feel my patch is a strict improvement
(more consistent) that fits with the current design, we can maintain this
in Chromium if you'd rather not accept it.

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Ronald S. Bultje]

Hi,

On Wed, Feb 28, 2018 at 3:41 PM, Michael Niedermayer  wrote:

> ATM IIUC one more vote is needed in the senate


Yikes. I would prefer if we don't meddle into politics like this.

You ignore the fact that any legislation needs to go through the US House
of Representatives, and then it should be signed (or conversely, can be
vetoed) by the president. The situation in the US Senate is the most
straightforward, because the Dems seat deficit is smallest (49 vs. 51).
That doesn't mean that after that hurdle is taken, it's a done deal. Quite
the contrary.

We are a project concerned with multimedia software. We are not an American
political organization. Please don't make us one; please reconsider this
patch.

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Michael Niedermayer]

On Wed, Feb 28, 2018 at 12:33:55PM -0900, Lou Logan wrote:
> On Wed, Feb 28, 2018, at 11:25 AM, Jan Ekström wrote:
> > 
> > Looking at how much it got updated the last time when it misbehaved
> > shows really well how that worked the last time. Sorry if I sound
> > facetious, but I do use ffmpeg-all.html a lot and it got /really/
> > irritating.
> 
> +1.
> 
> I object to the patch. The widget is annoyingly intrusive, 

How is it intrusive if it is displayed once and never shows
again for 60 days (which is how its configured) if you close it ?

It will show again if you delete the cookie it uses to keep track of
you closing it i think. But MANY webpages will display silly first time
notes if you loose cookies regularly.


> but as a compromise I would not block a small, resized, temporary simple 
> image banner in the bottom of the menu:
> 
> 

If you put this there, its of course better than nothing 
but i dont know if this is wise as a replacement for the widget.

As a user i much rather would want to be told that theres a problem in the
future straight in the face and how i might be able to help fight against it. 
Instead of a banner i wont realize is there and wont click on and wont realize
what it is about before iam hit with slower speed or increased fees from
an ISP or increased fees from random companies who need to pay for fast lanes
to keep operating

Its in fact a slightly sinister scheme, people could end up paying alot more
for their internet connection without realizing that they do. That is if they
end up paying all the companies who in the future may have to pay for their
connections not to be slowed down. The end user pays, the ISPs get the money
but the path is not neccesarily direct.

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


signature.asc
Description: PGP signature
___
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 28 February 2018 at 23:34, Aurelien Jacobs  wrote:

> On Wed, Feb 28, 2018 at 12:59:40AM +, Rostislav Pehlivanov wrote:
> > 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.
> > >
> > >
> > I think you ought to use a float for this, like:
> >
> > >{ "sbc_delay", "Maximum delay in milliseconds", offsetof(,
> > ), AV_OPT_TYPE_FLOAT, { .dbl =  },
> ,
> > , ,  },
>
> Why would I want to use float for this ??
> AV_OPT_TYPE_DURATION is more appropriate for this. It has microsecond
> precision which is more than enough, and you can still use a "float"
> string as a parameter (eg. -sbc_delay 0.0035 for a 3.5 ms maximum delay).
>
>
The unit is the issue. AV_OPT_TYPE_DURATION expects a duration in seconds,
but all codecs (except .ape) have frame sizes expressible in a (near)
integer amount of milliseconds, this included. Take a look at both Opus
encoders, they both use a unit of milliseconds in their avopts to set frame
durations. Having a codec which uses seconds unlike everything else isn't
right (and we the same issue just a month ago with a timeout option).
You don't have to use a float, you can use an int as well as long as frame
sizes are an integer number of milliseconds.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] Improve and fix put_vc2_ue_uint() function.

[Ivan Kalvachev]

On 3/1/18, Michael Niedermayer  wrote:
> On Wed, Feb 28, 2018 at 10:14:15PM +0200, Ivan Kalvachev wrote:
>> Replace two bit handling loops and internal conditional branch
>> with simple formula using few logical operations.
>>
>> The old function would generate wrong output
>> if the input does not fit into 15 bits.
>>
>> Fix this by using 64 bit math and put_bits64().
>> This case should be quite rare, since the bug
>> has not asserted itself.
>>
>> ---
>> It's attempt for speed optimization, but in the
>> process it turned out it needs also bugfixing.
>>
>> I only tested the old case of the code,
>> to confirm i've implemented the correct function.
>>
>> Haven't done any benchmarks or run fate.
>
> fate fails:
>

Well, the good news is that
it compiles and doesn't crash.

The change of generated files is expected.
The old code would write up to 63 bits
with regular put_bits() that is limited to 31 bits.

Are av_assert2() enabled during fate runs?
(That's how put_bits() checks for bit length.)


I'd like to know if my code is correct/incorrect
before attempting to changing fate checksums.

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

[Michael Niedermayer]

On Wed, Feb 28, 2018 at 07:52:56PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Feb 28, 2018 at 3:41 PM, Michael Niedermayer  > wrote:
> 
> > ATM IIUC one more vote is needed in the senate
> 
> 
> Yikes. I would prefer if we don't meddle into politics like this.
> 
> You ignore the fact that any legislation needs to go through the US House
> of Representatives, and then it should be signed (or conversely, can be
> vetoed) by the president. The situation in the US Senate is the most
> straightforward, because the Dems seat deficit is smallest (49 vs. 51).
> That doesn't mean that after that hurdle is taken, it's a done deal. Quite
> the contrary.
> 
> We are a project concerned with multimedia software. We are not an American
> political organization. Please don't make us one; please reconsider this
> patch.

I dont disagree about the things you say above but you are ignoring 
an important detail here.

multimedia being high bandwidth (and sometimes also low latency) could be
one of the main areas of internet traffic hit by a loss of net neutrality.
If thats the case, it could affect some if not many of our users.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH][RFC] Improve and fix put_vc2_ue_uint() function.

[Michael Niedermayer]

On Thu, Mar 01, 2018 at 03:52:10AM +0200, Ivan Kalvachev wrote:
> On 3/1/18, Michael Niedermayer  wrote:
> > On Wed, Feb 28, 2018 at 10:14:15PM +0200, Ivan Kalvachev wrote:
> >> Replace two bit handling loops and internal conditional branch
> >> with simple formula using few logical operations.
> >>
> >> The old function would generate wrong output
> >> if the input does not fit into 15 bits.
> >>
> >> Fix this by using 64 bit math and put_bits64().
> >> This case should be quite rare, since the bug
> >> has not asserted itself.
> >>
> >> ---
> >> It's attempt for speed optimization, but in the
> >> process it turned out it needs also bugfixing.
> >>
> >> I only tested the old case of the code,
> >> to confirm i've implemented the correct function.
> >>
> >> Haven't done any benchmarks or run fate.
> >
> > fate fails:
> >
> 
> Well, the good news is that
> it compiles and doesn't crash.
> 
> The change of generated files is expected.
> The old code would write up to 63 bits
> with regular put_bits() that is limited to 31 bits.
> 

> Are av_assert2() enabled during fate runs?
> (That's how put_bits() checks for bit length.)

add --assert-level=2 if you want it checked


> 
> 
> I'd like to know if my code is correct/incorrect
> before attempting to changing fate checksums.

the fate test looked like it did not decode the encoded data as
half the checksums where gone instead of changed IIRC


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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] Callable version of ffplay with callbacks for graphics overlay and video control

[Kerry Imming]

I submitted a proposal a few days ago about including an enhanced 
version of fftools/ffplay.
Here's a link to it in the archives: 
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225807.html


I believe my framework/example would be useful for other users of your 
library.

Is this something you would consider including as part of FFmpeg?
Is there anything else I can or should provide?

Thanks,
- Kerry Imming

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

[FFmpeg-devel] [PATCH] lavc/qsvenc: disable h264 look_ahead by default

[Zhong Li]

Look_ahead can provide quality improvements, but would better disable it by 
default due to some reasons:
1. It is only available for some codecs (e.g. HEVC is not supported) on Intel
   Haswell and plus platforms. Thus means it will be failed on some platforms.
2. It significantly increases encoding latency and memory consumption.
3. It may overwrite some other options such as CBR and CAVLC.

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc_h264.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 09e4c0e..e01a2a3 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -109,7 +109,7 @@ static const AVOption options[] = {
 { "max_dec_frame_buffering", "Maximum number of frames buffered in the 
DPB", OFFSET(qsv.max_dec_frame_buffering), AV_OPT_TYPE_INT, { .i64 = 0 },   0, 
UINT16_MAX, VE },
 
 #if QSV_HAVE_LA
-{ "look_ahead",   "Use VBR algorithm with look ahead",
OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
+{ "look_ahead",   "Use VBR algorithm with look ahead",
OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
 { "look_ahead_depth", "Depth of look ahead in number frames", 
OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 100, VE },
 #endif
 #if QSV_HAVE_LA_DS
-- 
1.8.3.1

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