Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: use binary search in mxf_absolute_bodysid_offset

[Marton Balint]

On Sun, 4 Mar 2018, Tomas Härdin wrote:


tor 2018-03-01 klockan 22:41 +0100 skrev Marton Balint:

> Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index d4291f5dc7..70091e0dc9 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1347,24 +1347,30 @@ static int mxf_get_sorted_table_segments(MXFContext 
*mxf, int *nb_sorted_segment
  */
 static int mxf_absolute_bodysid_offset(MXFContext *mxf, int body_sid, int64_t 
offset, int64_t *offset_out)
 {
-int x;
 MXFPartition *last_p = NULL;
+int a, b, m, m0;
 
 if (offset < 0)
 return AVERROR(EINVAL);
 
-for (x = 0; x < mxf->partitions_count; x++) {
-MXFPartition *p = &mxf->partitions[x];
+a = -1;


I've got a bad feeling about this -1


There is an explicit check after the loop when we actually use the value 
of 'a' to see if it remained -1 or not. Other than that using this 
construct (a = -1, b = count) is also used in other places throughout the 
codebase for binary search.





+b = mxf->partitions_count;
 
-if (p->body_sid != body_sid)
-continue;
+while (b - a > 1) {
+m0 = m = (a + b) >> 1;


Could overflow with a specially crafted file. But I guess it would have
to be on the order of 1 TiB.


I guess we could limit the number of partitions to INT_MAX / 2, although 
it really needs a *huge* crafted file and parsing it would probably take 
ages for the demuxer anyway...




It also looks like this might behave incorrectly when a=-1, b=0


That can't happen as the loop condition would be false in that case.

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

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

[Kieran Kunhya]

On Sun, 4 Mar 2018 at 22:59 Michael Niedermayer 
wrote:

> On Sun, Mar 04, 2018 at 09:45:03AM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Mar 4, 2018 at 9:24 AM, Compn  wrote:
> >
> > > On Thu, 1 Mar 2018 06:59:45 -0500, "Ronald S. Bultje"
> > >  wrote:
> > > > Again, please: no advertising, no politics. It was fun while it
> lasted
> > > but
> > > > it's turning into something semi-permanent now, I really have
> significant
> > > > issues with this.
> > >
> > > this isnt advertising.
> > >
> > > what is your significant issue with the politics?
> >
> >
> > I'm so sick of everything being about politics, everything being
> > politicized, everything being presented about the end of the world, and
> > everything being pushed in my face and everyone being forced to
> > continuously pay attention, have an opinion and to care.
> >
> > Because it's just not true. It's just a spin. Sure, some things are
> > important. But the end of the world? Hardly. To put our reputation as a
> > prime, pristine, independent and unpartisan collection of multimedia
> tools
> > and experts on the line for an unlikely and minor moment of partisan gain
> > in a single country. Really? Why? I just don't get it.
> >
> > If you want to play politics, join a political movement or party, attend
> or
> > organize rallies, run for local, state or federal office, create a
> > politically motivated youtube channel or facebook group. But don't use
> our
> > website.
> >
> > My issue is this: this advertising turns FFmpeg into a political
> movement.
> > But I don't want FFmpeg to be a political movement, or to be political at
> > all. I would like FFmpeg to be an opensource (or free software) project
> > where people with various interests in multimedia can come together -
> > regardless of background - and create cool technical innovations.
>
> After reading todays IRC backlog, i think i understand your position.
> And i agree with you that FFmpeg should not take sides in politics.
> Where i disagree is not that. I understand the disadvnatges here and
> i understood them long before.
>
> First lets try to investigate if this actually is a issue with a side
> that is against it. Because IIRC noone expressed opposition to net
> neutrality here or in fact in any other technical environment that i
> read except as "devils advocate".
>
> If i search for net neutrality poll 2018 on google and pick
> the 1st and 2nd links
>
> http://variety.com/2018/politics/news/net-neutrality-fcc-democrats-1202711864/
>
> https://www.washingtonpost.com/news/the-switch/wp/2017/12/12/this-poll-gave-americans-a-detailed-case-for-and-against-the-fccs-net-neutrality-plan-the-reaction-among-republicans-was-striking/
>
> The first claims 72% of people claiming to understand net neutrality are
> in favor of it
> The second claims 83 percent of Americans do not approve of the FCC
> proposal. Just 16 percent said they approved.
> and "About one in five Republicans said they were in favor of the FCC's
> proposal."
>
> But the main reason why iam writing this mail is that the whole discussion
> seems to have missed a important point so far and that is
>
> By doing nothing at all, we take a political position as well.
> And its one that least represents us.
>
> The apolitical thing to do would be to write a apolitical news entry that
> informs our users about the facts, risks and arguments around net
> neutrality
> in relation to FFmpeg and multimedia.
>
> We also would tell our users if FFmpeg would become 5% slower or faster.
> We similarly should tell them about the use of FFmpeg in relation to
> network
> transmission in the future potentially costing x% more
>
> You want FFmpeg not to harm itself by taking side in politcal debate.
> I agree with this, it makes sense
>
> But i do not want us to be afraid to inform our users about things that
> could make their use of our tools more expensive or slower.
>
> My oppinion is that a news article should be written that everyone here
> is happy with. And that helps users better understand what effects
> net neutrality and its removial could have on them and multimedia and
> FFmpeg.
> That way they can better make an educated decission on what position to
> take
> if any. Or if they dont care they can just ignore the article, neither side
> would feel offended. And we would do the morally correct thing to inform
> our users about something that may affect their use of our software.
>
> Thanks
>
> [...]
>

Ladies and Gentleman I present you exhibit A, Michael continues to argue so
that people get bored of replying and he gets his way.
This has never ever ever happened in the history of FFmpeg.

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfdec: fix opAtom audio demuxing

[Marton Balint]

On Sun, 4 Mar 2018, Tomas Härdin wrote:


tor 2018-03-01 klockan 22:41 +0100 skrev Marton Balint:

Consider edit rate when determining edit_units_per_packet and also make sure
that checks are done in edit rate time base and not in stream time base.

Fixes some errors reported with the sample in ticket #5863.

> Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
@@ -2786,6 +2786,7 @@ static AVStream* mxf_get_opatom_stream(MXFContext *mxf)
 static void mxf_handle_small_eubc(AVFormatContext *s)
 {
 MXFContext *mxf = s->priv_data;
+MXFTrack *track;
 
 /* assuming non-OPAtom == frame wrapped
  * no sane writer would wrap 2 byte PCM packets with 20 byte headers.. */
@@ -2805,7 +2806,8 @@ static void mxf_handle_small_eubc(AVFormatContext *s)
 /* TODO: We could compute this from the ratio between the audio
  *   and video edit rates for 48 kHz NTSC we could use the
  *   1802-1802-1802-1802-1801 pattern. */
-mxf->edit_units_per_packet = 1920;
+track = st->priv_data;
+mxf->edit_units_per_packet = FFMAX(1, track->edit_rate.num / 
track->edit_rate.den / 25);
 }


That 25 looks a bit arbitrary. But I guess with OPAtom we don't have a
video edit rate to make use of


25 is selected to mimic existing behaviour (as in 48000/1/25 = 1920,
the edit_units_per_packet value which was used before).



Other than that, patch looks OK


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

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

[Jun Zhao]

On 2018/3/4 6:16, Michael Niedermayer wrote:
> On Sat, Mar 03, 2018 at 07:10:48PM -0300, James Almer wrote:
>> On 3/3/2018 6:41 PM, Michael Niedermayer wrote:
>>> On Fri, Mar 02, 2018 at 08:16:11AM +0800, Jun Zhao wrote:
  bitstream_filters.texi |   11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)
 27c05404d9fabe5065e418c4cc09629d53aee1a1  
 0001-doc-bitstream_filters-correct-dump_extra-bsfs-docs.patch
 From 0a0a10824511ef9d5b3c49ee652a918603841826 Mon Sep 17 00:00:00 2001
 From: Jun Zhao 
 Date: Fri, 23 Feb 2018 13:53:05 +0800
 Subject: [PATCH V2] doc/bitstream_filters: correct dump_extra bsfs docs.

 Update dump_extra bit stream filter docs to follow current
 code implement.

 Signed-off-by: Jun Zhao 
 Reviewed-by: Steven Liu 
 ---
  doc/bitstream_filters.texi | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)
>>> i  hoped a little that the a option could one day be
>>> cleanly restored in the implementation.
>>> but keeping the docs incorrect is not helping
>> You mean adding it as it's defined in the removed portion of the doxy
>> from this patch (local_header flag2)?
>> Sounds like a better idea, as it would help replace the
>> av_parser_change() call in ffmpeg.c with this bsf. I'll take a look.
> yes
Now, we can get specific help/option information for
decoder/encoder/demuxer/muxer/filter
like this:  ffmpeg -h encoder=libx264, how about implement specific bsf
help like
ffmpeg -h bsf=dump_filter? I think even if the guys forget update the
man-page, we
can get correct option information from cmd.

If is Ok, I will try to work for this. Thanks.
>
> [...]
>
>
> ___
> 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] ffmpeg: Initialize a potential gap in ctts_data in mov_build_index

[Michael Niedermayer]

On Fri, Mar 02, 2018 at 03:43:35PM -0800, Matthew Wolenetz wrote:
> 

>  mov.c |3 +++
>  1 file changed, 3 insertions(+)
> 6cffbdffaf318c72a8a3ea4d3c279c4126f5c0e2  
> 0001-ffmpeg-Initialize-a-potential-gap-in-ctts_data-in-mo.patch
> From c40925a0d3ec1397cd6ed7d29bae573c5bdf1ec2 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz 
> Date: Fri, 2 Mar 2018 15:12:41 -0800
> Subject: [PATCH] ffmpeg: Initialize a potential gap in ctts_data in
>  mov_build_index
> 
> mov_read_ctts ignores ctts entries having count <= 0. Generally, the
> aggregate of all ctts entries' count fields resulting from mov_read_ctts
> can be less than the corresponding sample_count.
> 
> mov_build_index attempts to normalize any existing ctts_data counts to
> be 1, to make a 1-1 mapping of a ctts_data entry to a sample.
> 
> That 1-1 mapping left a tail of uninitialized ctts_data entries when the
> aggregate, normalized ctts_count < sample_count.
> 
> Even more generally, later usage of ctts_data may depend on the entire
> ctts_allocated_size having been initialized.
> 
> This change memsets the entire allocation of the normalized ctts_data in
> mov_build_index, to prevent use of uninitialized data later.
> 
> BUG=816787
> 
> Change-Id: I7fd7db255e3aeed076ee32c90cb2df211741c052
> Reviewed-on: https://chromium-review.googlesource.com/947110
> Reviewed-by: Xiaohan Wang 

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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 Sun, Mar 04, 2018 at 09:45:03AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Mar 4, 2018 at 9:24 AM, Compn  wrote:
> 
> > On Thu, 1 Mar 2018 06:59:45 -0500, "Ronald S. Bultje"
> >  wrote:
> > > Again, please: no advertising, no politics. It was fun while it lasted
> > but
> > > it's turning into something semi-permanent now, I really have significant
> > > issues with this.
> >
> > this isnt advertising.
> >
> > what is your significant issue with the politics?
> 
> 
> I'm so sick of everything being about politics, everything being
> politicized, everything being presented about the end of the world, and
> everything being pushed in my face and everyone being forced to
> continuously pay attention, have an opinion and to care.
> 
> Because it's just not true. It's just a spin. Sure, some things are
> important. But the end of the world? Hardly. To put our reputation as a
> prime, pristine, independent and unpartisan collection of multimedia tools
> and experts on the line for an unlikely and minor moment of partisan gain
> in a single country. Really? Why? I just don't get it.
> 
> If you want to play politics, join a political movement or party, attend or
> organize rallies, run for local, state or federal office, create a
> politically motivated youtube channel or facebook group. But don't use our
> website.
> 
> My issue is this: this advertising turns FFmpeg into a political movement.
> But I don't want FFmpeg to be a political movement, or to be political at
> all. I would like FFmpeg to be an opensource (or free software) project
> where people with various interests in multimedia can come together -
> regardless of background - and create cool technical innovations.

After reading todays IRC backlog, i think i understand your position.
And i agree with you that FFmpeg should not take sides in politics.
Where i disagree is not that. I understand the disadvnatges here and
i understood them long before.

First lets try to investigate if this actually is a issue with a side
that is against it. Because IIRC noone expressed opposition to net
neutrality here or in fact in any other technical environment that i
read except as "devils advocate".

If i search for net neutrality poll 2018 on google and pick
the 1st and 2nd links
http://variety.com/2018/politics/news/net-neutrality-fcc-democrats-1202711864/
https://www.washingtonpost.com/news/the-switch/wp/2017/12/12/this-poll-gave-americans-a-detailed-case-for-and-against-the-fccs-net-neutrality-plan-the-reaction-among-republicans-was-striking/

The first claims 72% of people claiming to understand net neutrality are in 
favor of it
The second claims 83 percent of Americans do not approve of the FCC proposal. 
Just 16 percent said they approved.
and "About one in five Republicans said they were in favor of the FCC's 
proposal."

But the main reason why iam writing this mail is that the whole discussion
seems to have missed a important point so far and that is

By doing nothing at all, we take a political position as well.
And its one that least represents us.

The apolitical thing to do would be to write a apolitical news entry that
informs our users about the facts, risks and arguments around net neutrality
in relation to FFmpeg and multimedia.

We also would tell our users if FFmpeg would become 5% slower or faster.
We similarly should tell them about the use of FFmpeg in relation to network
transmission in the future potentially costing x% more

You want FFmpeg not to harm itself by taking side in politcal debate.
I agree with this, it makes sense

But i do not want us to be afraid to inform our users about things that
could make their use of our tools more expensive or slower.

My oppinion is that a news article should be written that everyone here
is happy with. And that helps users better understand what effects
net neutrality and its removial could have on them and multimedia and FFmpeg.
That way they can better make an educated decission on what position to take
if any. Or if they dont care they can just ignore the article, neither side
would feel offended. And we would do the morally correct thing to inform
our users about something that may affect their use of our software.

Thanks

[...]

-- 
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 2/3 v1.2] avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding

[Mark Thompson]

On 01/03/18 22:43, Mark Thompson wrote:
> On 01/03/18 08:07, Jerome Borsboom wrote:
>> v1.1->v1.2: Changed ifdefs around vc1_get_INTCOMPFIELD, vc1_get_LUMSCALE2,
>> and vc1_get_LUMSHIFT2 to av_unused.
>>
>> 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 | 163 
>> -
>>  1 file changed, 134 insertions(+), 29 deletions(-)
> 
> ...
> 
> As such, I'm happy to apply all of this as it is now.  Does anyone have any 
> further comments, especially about the VC-1 parts of this change?  If not, 
> I'll apply the whole set this weekend.

And applied.

Thank you for the patches!

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

Re: [FFmpeg-devel] [PATCH] parseutils: accept only full "ms" and "us" prefixes

[Rostislav Pehlivanov]

On 3 March 2018 at 20:19, Rostislav Pehlivanov  wrote:

> The commit which added those was pushed prematurely before anyone could
> object
> to illogical suffixes like just m for milliseconds. Without this, we'd be
> locked
> into never being able to implement the "m" suffix for minutes.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavutil/parseutils.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
> index 44c845577a..1b81757aab 100644
> --- a/libavutil/parseutils.c
> +++ b/libavutil/parseutils.c
> @@ -689,17 +689,15 @@ int av_parse_time(int64_t *timeval, const char
> *timestr, int duration)
>
>  if (duration) {
>  t = dt.tm_hour * 3600 + dt.tm_min * 60 + dt.tm_sec;
> -if (*q == 'm') {
> +if (q[0] == 'm' && q[1] == 's') {
>  suffix = 1000;
>  microseconds /= 1000;
> -q++;
> -} else if (*q == 'u') {
> +q += 2;
> +} else if (q[0] == 'u' && q[1] == 's') {
>  suffix = 1;
>  microseconds = 0;
> -q++;
> +q += 2;
>  }
> -if (*q == 's')
> -q++;
>  } else {
>  int is_utc = *q == 'Z' || *q == 'z';
>  int tzoffset = 0;
> --
> 2.16.2
>
>
I'll push this tomorrow if there are no objections
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: use binary search in mxf_absolute_bodysid_offset

[Tomas Härdin]

tor 2018-03-01 klockan 22:41 +0100 skrev Marton Balint:
> > Signed-off-by: Marton Balint 
> ---
>  libavformat/mxfdec.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index d4291f5dc7..70091e0dc9 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -1347,24 +1347,30 @@ static int mxf_get_sorted_table_segments(MXFContext 
> *mxf, int *nb_sorted_segment
>   */
>  static int mxf_absolute_bodysid_offset(MXFContext *mxf, int body_sid, 
> int64_t offset, int64_t *offset_out)
>  {
> -int x;
>  MXFPartition *last_p = NULL;
> +int a, b, m, m0;
>  
>  if (offset < 0)
>  return AVERROR(EINVAL);
>  
> -for (x = 0; x < mxf->partitions_count; x++) {
> -MXFPartition *p = &mxf->partitions[x];
> +a = -1;

I've got a bad feeling about this -1

> +b = mxf->partitions_count;
>  
> -if (p->body_sid != body_sid)
> -continue;
> +while (b - a > 1) {
> +m0 = m = (a + b) >> 1;

Could overflow with a specially crafted file. But I guess it would have
to be on the order of 1 TiB.

It also looks like this might behave incorrectly when a=-1, b=0

>  
> -if (p->body_offset > offset)
> -break;
> +while (m < b && mxf->partitions[m].body_sid != body_sid)
> +m++;
>  
> -last_p = p;
> +if (m < b && mxf->partitions[m].body_offset <= offset)
> +a = m;
> +else
> +b = m0;
>  }
>  
> +if (a >= 0)
> +last_p = &mxf->partitions[a];
> +
>  if (last_p && (!last_p->essence_length || last_p->essence_length > 
> (offset - last_p->body_offset))) {
>  *offset_out = last_p->essence_offset + (offset - 
> last_p->body_offset);
>  return 0;

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfdec: fix opAtom audio demuxing

[Tomas Härdin]

tor 2018-03-01 klockan 22:41 +0100 skrev Marton Balint:
> Consider edit rate when determining edit_units_per_packet and also make sure
> that checks are done in edit rate time base and not in stream time base.
> 
> Fixes some errors reported with the sample in ticket #5863.
> 
> > Signed-off-by: Marton Balint 
> ---
>  libavformat/mxfdec.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> @@ -2786,6 +2786,7 @@ static AVStream* mxf_get_opatom_stream(MXFContext *mxf)
>  static void mxf_handle_small_eubc(AVFormatContext *s)
>  {
>  MXFContext *mxf = s->priv_data;
> +MXFTrack *track;
>  
>  /* assuming non-OPAtom == frame wrapped
>   * no sane writer would wrap 2 byte PCM packets with 20 byte headers.. */
> @@ -2805,7 +2806,8 @@ static void mxf_handle_small_eubc(AVFormatContext *s)
>  /* TODO: We could compute this from the ratio between the audio
>   *   and video edit rates for 48 kHz NTSC we could use the
>   *   1802-1802-1802-1802-1801 pattern. */
> -mxf->edit_units_per_packet = 1920;
> +track = st->priv_data;
> +mxf->edit_units_per_packet = FFMAX(1, track->edit_rate.num / 
> track->edit_rate.den / 25);
>  }

That 25 looks a bit arbitrary. But I guess with OPAtom we don't have a
video edit rate to make use of

Other than that, patch looks OK

/Tomas
___
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 Sun, Mar 4, 2018, at 10:54 AM, Compn wrote:
>
> I still have not seen an argument for why politics should not be
> involved on ffmpeg. only some strawman argument about kittens on
> youtube.


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

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

[Compn]

On Sun, 4 Mar 2018 20:18:49 +0100, Hendrik Leppkes
 wrote:

> Everyone is entitled to their opinion and their own politics, but you
> should also be respectful of those that do not want politics involved
> in FFmpeg. Its not the place for it.

software patents directly affect ffmpeg, should we ignore that?

I still have not seen an argument for why politics should not be
involved on ffmpeg. only some strawman argument about kittens on
youtube.

> Do we add political statements about some internet-related happenings
> from other countries as well then? Why limit this to the US only? If
> we have one popup, we might as well have 5?

no one limited our website statements to US-only.   

There have only been two statements by ffmpeg on non-ffmpeg internet
items in the past 10+ years, looking at the news and archived news.

http://ffmpeg.org/archive.html

November 20, 2011
 FFmpeg supports the fight against American Internet censorship.

and then the widget we are discussing today.

I see some people complaining about so much politics, but two posts in
10 years ? that is what you are upset about ? 

please help me understand your problem with this.
Aside from these, which i think everyone is in agreement with.
1. popup ad is annoying , news entry would be better
2. no reason to have a popup page on the docs pages.

i'm not trying to be dismissive, i want to understand. please explain
the problem.

also no one has said why net neutrality is political at all. its a
technical problem, and ffmpeg is all about technical problems.

ssl heartbleed was a technical problem that was also posted to our news
page. i dont remember the vitriol about that ssl news post.

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

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

[Hendrik Leppkes]

On Sun, Mar 4, 2018 at 8:13 PM, Compn  wrote:
> On Sun, 04 Mar 2018 16:40:55 +, Kieran Kunhya
>  wrote:
>
>>
>> +1
>
> just you wait until net neutrality is really dead. your rival
> broadcast encoder vendors will pay the extra $5k and have your site
> slowed or de-listed from the internet, kieran.
>
> Then you can just pay the ISP $5k per year to get off the slow list.
>
> unless you think AT&T or Verizon will be fair.
>
> ffmpeg's reputation is based on its code.
> not its developers. not its website.
> not any of its activism or news entries.
> not any of us, not the mailing lists, not the irc, not the trac.
>
> or i could be wrong.
> any changes of internet policy are going to affect everyone in different
> ways. to ignore this is folly.
>

Everyone is entitled to their opinion and their own politics, but you
should also be respectful of those that do not want politics involved
in FFmpeg. Its not the place for it.
Do we add political statements about some internet-related happenings
from other countries as well then? Why limit this to the US only? If
we have one popup, we might as well have 5?

Getting into politics is a slippery slope, and its best to just stay out of it.


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

Re: [FFmpeg-devel] [PATCH] configure: rename cuda to ffnvcodec

[Compn]

On Sat,  3 Mar 2018 22:39:45 +0100, Timo Rothenpieler
 wrote:

> Right now, if someone configures ffmpeg with for example --enable-nvenc they 
> will
> get an error message complaining about missing cuda.
> This is very confusing and already has lead people into installing the CUDA 
> SDK,
> even though it's not what they need.
> 
> This will make it complain about ffnvcodec instead.

i'm not objecting.

but if you put a error message that explains what a person needs when
it errors , that might also be a good idea (and it would also only be
a one or two line change).

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

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

[Compn]

On Sun, 04 Mar 2018 16:40:55 +, Kieran Kunhya
 wrote:

> 
> +1

just you wait until net neutrality is really dead. your rival
broadcast encoder vendors will pay the extra $5k and have your site
slowed or de-listed from the internet, kieran.

Then you can just pay the ISP $5k per year to get off the slow list.

unless you think AT&T or Verizon will be fair.

ffmpeg's reputation is based on its code.
not its developers. not its website.
not any of its activism or news entries.
not any of us, not the mailing lists, not the irc, not the trac.

or i could be wrong.
any changes of internet policy are going to affect everyone in different
ways. to ignore this is folly.

-compn
___
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 Sun, Mar 4, 2018, at 5:45 AM, Ronald S. Bultje wrote:
>
> I'm so sick of everything being about politics, everything being
> politicized, everything being presented about the end of the world, and
> everything being pushed in my face and everyone being forced to
> continuously pay attention, have an opinion and to care.
> 
> Because it's just not true. It's just a spin. Sure, some things are
> important. But the end of the world? Hardly. To put our reputation as a
> prime, pristine, independent and unpartisan collection of multimedia tools
> and experts on the line for an unlikely and minor moment of partisan gain
> in a single country. Really? Why? I just don't get it.
> 
> If you want to play politics, join a political movement or party, attend or
> organize rallies, run for local, state or federal office, create a
> politically motivated youtube channel or facebook group. But don't use our
> website.
> 
> My issue is this: this advertising turns FFmpeg into a political movement.
> But I don't want FFmpeg to be a political movement, or to be political at
> all. I would like FFmpeg to be an opensource (or free software) project
> where people with various interests in multimedia can come together -
> regardless of background - and create cool technical innovations.
> 
> Ronald

+1 too.

I began writing something along the same lines when I wrote my earlier reply 
but never finished and it was much less well written.

I retract my acquiesced suggestion of a small banner. It was a compromise to 
try to find an acceptable solution to make everyone equally unhappy.

FFmpeg should be apolitical. We have enough technical things to spend out time 
on and argue over.

The majority do not want this thing on the website. I think this discussion 
should end here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Compn]

On Sun, 4 Mar 2018 09:45:03 -0500, "Ronald S. Bultje"
 wrote:

> Hi,
> 
> On Sun, Mar 4, 2018 at 9:24 AM, Compn  wrote:
> 
> > On Thu, 1 Mar 2018 06:59:45 -0500, "Ronald S. Bultje"
> >  wrote:
> > > Again, please: no advertising, no politics. It was fun while it lasted
> > but
> > > it's turning into something semi-permanent now, I really have significant
> > > issues with this.
> >
> > this isnt advertising.
> >
> > what is your significant issue with the politics?
> 
> 
> I'm so sick of everything being about politics, everything being
> politicized, everything being presented about the end of the world, and
> everything being pushed in my face and everyone being forced to
> continuously pay attention, have an opinion and to care.
> 
> Because it's just not true. It's just a spin. Sure, some things are
> important. But the end of the world? Hardly. To put our reputation as 

whats your opinion on software patents?

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

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

[Kieran Kunhya]

On Sun, 4 Mar 2018 at 14:50 Ronald S. Bultje  wrote:

> Hi,
>
> On Sun, Mar 4, 2018 at 9:24 AM, Compn  wrote:
>
> > On Thu, 1 Mar 2018 06:59:45 -0500, "Ronald S. Bultje"
> >  wrote:
> > > Again, please: no advertising, no politics. It was fun while it lasted
> > but
> > > it's turning into something semi-permanent now, I really have
> significant
> > > issues with this.
> >
> > this isnt advertising.
> >
> > what is your significant issue with the politics?
>
>
> I'm so sick of everything being about politics, everything being
> politicized, everything being presented about the end of the world, and
> everything being pushed in my face and everyone being forced to
> continuously pay attention, have an opinion and to care.
>
> Because it's just not true. It's just a spin. Sure, some things are
> important. But the end of the world? Hardly. To put our reputation as a
> prime, pristine, independent and unpartisan collection of multimedia tools
> and experts on the line for an unlikely and minor moment of partisan gain
> in a single country. Really? Why? I just don't get it.
>
> If you want to play politics, join a political movement or party, attend or
> organize rallies, run for local, state or federal office, create a
> politically motivated youtube channel or facebook group. But don't use our
> website.
>
> My issue is this: this advertising turns FFmpeg into a political movement.
> But I don't want FFmpeg to be a political movement, or to be political at
> all. I would like FFmpeg to be an opensource (or free software) project
> where people with various interests in multimedia can come together -
> regardless of background - and create cool technical innovations.
>
> Ronald
>

+1
___
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 Sun, Mar 4, 2018 at 9:24 AM, Compn  wrote:

> On Thu, 1 Mar 2018 06:59:45 -0500, "Ronald S. Bultje"
>  wrote:
> > Again, please: no advertising, no politics. It was fun while it lasted
> but
> > it's turning into something semi-permanent now, I really have significant
> > issues with this.
>
> this isnt advertising.
>
> what is your significant issue with the politics?


I'm so sick of everything being about politics, everything being
politicized, everything being presented about the end of the world, and
everything being pushed in my face and everyone being forced to
continuously pay attention, have an opinion and to care.

Because it's just not true. It's just a spin. Sure, some things are
important. But the end of the world? Hardly. To put our reputation as a
prime, pristine, independent and unpartisan collection of multimedia tools
and experts on the line for an unlikely and minor moment of partisan gain
in a single country. Really? Why? I just don't get it.

If you want to play politics, join a political movement or party, attend or
organize rallies, run for local, state or federal office, create a
politically motivated youtube channel or facebook group. But don't use our
website.

My issue is this: this advertising turns FFmpeg into a political movement.
But I don't want FFmpeg to be a political movement, or to be political at
all. I would like FFmpeg to be an opensource (or free software) project
where people with various interests in multimedia can come together -
regardless of background - and create cool technical innovations.

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

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

[Compn]

On Thu, 1 Mar 2018 06:59:45 -0500, "Ronald S. Bultje"
 wrote:

> Hi,
> 
> Again, please: no advertising, no politics. It was fun while it lasted but
> it's turning into something semi-permanent now, I really have significant
> issues with this.

this isnt advertising.

what is your significant issue with the politics?
could you share your opinion please?

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

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

[Compn]

On Thu, 1 Mar 2018 13:17:08 +0100, wm4  wrote:

> On Thu, 1 Mar 2018 11:49:16 +
> Ricardo Constantino  wrote:
> 
> > On 1 March 2018 at 01:19, Michael Niedermayer 
> > wrote:
> > 
> > > 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.
> > >  
> > 
> > 
> > Many people remove cookies from non-regular sites on closing the browser.
> > Why would people suddenly need to keep a cookie in order to not get nagged
> > on ffmpeg.org?
> > 
> > 
> > >
> > >  
> > > > but as a compromise I would not block a small, resized, temporary 
> > > > simple  
> > > image banner in the bottom of the menu:  
> > > >
> > > >  > > f6v>  
> > >
> > > 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.
> > >  
> > 
> > It seems a very welcome alternative. Banners are way less annoying than
> > fullscreen popups.
> > 
> > 
> > >
> > > 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
> > >  
> > 
> > You can link whatever's the campaign webpage in the banner and whoever
> > cares will go see it.
> > Don't assume people will care more if you plaster it in their face and
> > block what they were reading.
> > 
> > 
> > >
> > > 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.
> > >  
> > 
> > There's a lot more places where people can get their armchair politics
> > satisfied than ffmpeg.org.
> > A banner or a news post would make more sense.
> > 
> 
> Yeah, I agree a banner of some sort would be less intrusive and still
> get noticed. We'd also not have to run foreign JS (that already proved
> to be buggy before). Seems like the best choice.

I would prefer a static news post. Not because of security issues, I
just dont like popups. 

For security, any developers complaining in this thread about security
issues should be whitelisting javascript only, and disabling javascript
everywhere else. Complaining about a 3rd party javascript, in this day
and age, means you've already thrown in the towel on your browser
security.

or in lieu of a news post, make the widget only on ffmpeg.org/index ,
not on DOCS pages. I ran into the widget a few times too when it was
misbehaving.

I am not objecting outright, net neutrality is pretty important.

And yes, you foreigners should be helping the USA with this, as
THIS WILL affect the backbones. how many internet backbones are owned
by US companies? non-usa people can help in some ways:

1. ask friends in usa to help
2. post on your own blogs and websites, spread the word
3. contact your local political representatives to tell them how net
neutrality is important.

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

Re: [FFmpeg-devel] Win7 64b/mingw32 compilation fix

[Hendrik Leppkes]

On Sun, Mar 4, 2018 at 2:16 AM, James Almer  wrote:
> On 3/2/2018 7:39 AM, Pierre Chatelier wrote:
>> Hello,
>>
>> I had an issue to compile ffmpeg under Win7 64 bits/mingw32
>> Adding an include was the solution.
>>
>> Here is a patch
>>
>> Pierre Chatelier
>>
>> 0001-fix-compilation-under-Win7-64bits-with-mingw32-by-ad.patch
>>
>>
>> From 91f049a9424f80961a8bc3406dc60bccd1d516b9 Mon Sep 17 00:00:00 2001
>> From: Pierre Chatelier 
>> Date: Fri, 2 Mar 2018 11:28:48 +0100
>> Subject: [PATCH 1/1] fix compilation under Win7 64bits with mingw32 by added
>>   the EAI_MEMORY macro was mapped to ERROR_NOT_ENOUGH_MEMORY 
>> which
>>  was not defined
>>
>> ---
>>  libavformat/os_support.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/os_support.c b/libavformat/os_support.c
>> index 86d0b8f306..f9bd5d9970 100644
>> --- a/libavformat/os_support.c
>> +++ b/libavformat/os_support.c
>> @@ -36,6 +36,7 @@
>>  #endif /* HAVE_SYS_TIME_H */
>>  #if HAVE_WINSOCK2_H
>>  #include 
>> +#include 
>
> At least on mingw-w64, the header is called winerror.h, no capital letters.
>
> Can you be more specific about your toolchain? Is mingw32, mingw-w64?
> What version?
> This is the first time i see anyone having this issue and we have
> several people using different mingw and msvc tolchains.
>

winerror.h should never be manually included, its included through
windows.h - which os_support.h includes, so it should be present.
If your version of mingw does not do that, its probably faulty.

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