Re: [FFmpeg-devel] hi sir, where i can paste ffmpeg extract files on site. please help me.

[Lou Logan]

I do not understand what you are asking.

ffmpeg-devel is only for patch submissions and discussions related to
the development of FFmpeg.

Questions involving the FFmpeg command-line interface tools should be
asked at the ffmpeg-user mailing list.

Questions involving the FFmpeg libraries should be asked at the
libav-user mailing list.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] hi sir, where i can paste ffmpeg extract files on site. please help me.

[CHINNA Suresh]

-- 



Thanks & Regards.

*   "G.SURESH"*
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] matroskadec: prevent access of elements after freeing

[Schenk, Michael]

When using the decode interrupt feature of ffmpeg may causing crashes by 
accessing previous freed pointers in matroska_read_close.
The attached patch will reset nb_elem to zero after freeing the elements 
because ffmpeg normally tests for nb_elem.

Feedback for sure is warmly welcome.

Regards

Michael


---
Albis Technologies AG, Albisriederstrasse 199, CH-8047 Zürich, SWITZERLAND

Sitz der Gesellschaft / Domicile: Zürich
MWSt.-Nr. / VAT ID no.: CHE-114.433.653 MWST


ELCON Systemtechnik GmbH, Obere Hauptstrasse 10, D-09232 Hartmannsdorf, GERMANY

Sitz der Gesellschaft / Head office: Hartmannsdorf
Amtsgericht / County court: Chemnitz HRB 1 34 74
USt-ID-Nr. / VAT ID no.: DE 137 182 638
WEEE-Reg.-Nr. / WEEE Reg. no.: DE 35 781 658
Geschäftsführer / Managing director: Werner Neubauer, Markus Königshofer




Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das 
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht 
gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



0001-set-nb_elem-to-0-after-freeing-to-avoid-further-acce.patch
Description: 0001-set-nb_elem-to-0-after-freeing-to-avoid-further-acce.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Sun, Nov 27, 2016 at 05:31:39PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Nov 27, 2016 at 1:46 PM, Michael Niedermayer  > wrote:
> 
> > On Sun, Nov 27, 2016 at 07:30:24PM +0100, Clément Bœsch wrote:
> > > On Sun, Nov 27, 2016 at 06:49:35PM +0100, Michael Niedermayer wrote:
> > > > On Sun, Nov 27, 2016 at 04:57:36PM +0100, Clément Bœsch wrote:
> > > > > On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
> > > > > [...]
> > > > > > ffserver had 14 commits to it in about the last month
> > > > >
> > > > > That's also pretty close to the number of commits in the last years.
> > > > >
> > > > > Good will in the last weeks is not enough of a technical
> > > > > merit/justification to prevent the removal of junk code scheduled for
> > > > > deletion for a long time now.
> > > >
> > > > why do you call it junk ?
> > >
> > > because it's highly dependent on internal stuff, very limited, completely
> > > untested, unmaintained for several years but still contains a ton of
> > code.
> > >
> > > > and the sheduling for deletion was conditional on it not being fixed
> > > > IIRC.
> > > > Why the hurry to remove it while people work on fixing it ?
> > > > its not blocking anything ATM AFAIK
> > >
> > > There is no hurry, but piling up a bunch patches to fix small things just
> > > to use it as an argument to say "hey look now it's maintained" in order
> > to
> > > save it from being killed is really annoying. The people interested in it
> > > had years to act.
> > >
> >
> > > You can fix a ton of little things in it, but unless the fundamental
> > > problems are addressed (ZERO internal API usage + at least partial FATE
> > > coverage) it's pointless
> >
> > of course the goal is ZERO internal API usage + at least partial FATE
> > coverage.
> > Well in fact the lack of fate tests have been the primary reason
> > why i didnt fix some of the API issues years ago. I felt uneasy
> > changing it without regression tests
> >
> >
> > > and will be seen as yet another case of "KEEP
> > > EVERYTHING FOREVER" toxic mentality.
> >
> > The opposit is toxic too
> 
> 
> I'm perfectly fine with keeping the code, just not in the ffmpeg tree.
> Please move it to its own tree.
> 

> Everybody wants it out. Please follow majority.

Some people want it out yes, how many and what the majority want i do
not know.
Some people also wanted all tools treated equally and moved out (again
i dont know how many support that)

Spliting just ffserver out means more work for whoever maintains it
setting up seperate infrastructure, seperate coverity, coverage, fate,
...
theres a lot of work in all this, its long term continuous effort
and this is time that wont be spent on FFmpeg.

I dont know if people want me and reynaldo to spend less time on
FFmpeg, but time is a finite resource. If ffserver is maintained
externally it would mean a noticable hit in maintaince man hours of
FFmpeg. Now it might be that ffserver being pushed out would kill it.
But really as dumb as i am, i dont belive theres a majority who wants
to kill FFserver when there are people who actively work on it and
care about it.


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

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH] ffserver: Remove last use of AVStream size

[James Almer]

On 11/27/2016 7:29 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Nov 27, 2016 at 1:26 PM, Michael Niedermayer > wrote:
> 
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  ffserver.c | 18 --
>>  1 file changed, 4 insertions(+), 14 deletions(-)
>>
>> diff --git a/ffserver.c b/ffserver.c
>> index ded5149..9b1f6d5 100644
>> --- a/ffserver.c
>> +++ b/ffserver.c
>> @@ -2961,7 +2961,6 @@ static int prepare_sdp_description(FFServerStream
>> *stream, uint8_t **pbuffer,
>> struct in_addr my_ip)
>>  {
>>  AVFormatContext *avc;
>> -AVStream *avs = NULL;
>>  AVOutputFormat *rtp_format = av_guess_format("rtp", NULL, NULL);
>>  AVDictionaryEntry *entry = av_dict_get(stream->metadata, "title",
>> NULL, 0);
>>  int i;
>> @@ -2975,7 +2974,6 @@ static int prepare_sdp_description(FFServerStream
>> *stream, uint8_t **pbuffer,
>>  avc->oformat = rtp_format;
>>  av_dict_set(>metadata, "title",
>>  entry ? entry->value : "No Title", 0);
>> -avc->nb_streams = stream->nb_streams;
>>  if (stream->is_multicast) {
>>  snprintf(avc->filename, 1024, "rtp://%s:%d?multicast=1?ttl=%d",
>>   inet_ntoa(stream->multicast_ip),
>> @@ -2983,19 +2981,12 @@ static int prepare_sdp_description(FFServerStream
>> *stream, uint8_t **pbuffer,
>>  } else
>>  snprintf(avc->filename, 1024, "rtp://0.0.0.0");
>>
>> -avc->streams = av_malloc_array(avc->nb_streams,
>> sizeof(*avc->streams));
>> -if (!avc->streams)
>> -goto sdp_done;
>> -
>> -avs = av_malloc_array(avc->nb_streams, sizeof(*avs));
>> -if (!avs)
>> -goto sdp_done;
>> -
>>  for(i = 0; i < stream->nb_streams; i++) {
>> -avc->streams[i] = [i];
>> -avc->streams[i]->codec = stream->streams[i]->codec;
>> +AVStream *st = avformat_new_stream(avc, NULL);
>> +if (!st)
>> +goto sdp_done;
>>  avcodec_parameters_from_context(stream->streams[i]->codecpar,
>> stream->streams[i]->codec);
>> -avc->streams[i]->codecpar = stream->streams[i]->codecpar;
>> +unlayer_stream(st, stream->streams[i]);
>>  }
>>  #define PBUFFER_SIZE 2048
>>  *pbuffer = av_mallocz(PBUFFER_SIZE);
>> @@ -3007,7 +2998,6 @@ static int prepare_sdp_description(FFServerStream
>> *stream, uint8_t **pbuffer,
>>  av_freep(>streams);
>>  av_dict_free(>metadata);
>>  av_free(avc);
>> -av_free(avs);
>>
>>  return *pbuffer ? strlen(*pbuffer) : AVERROR(ENOMEM);
>>  }
>> --
>> 2.10.2
> 
> 
> I think you're sending this to the wrong repository, ffserver is not part
> of the ffmpeg tree anymore.
> 
> Ronald

If this is part of the attempts at making it standalone, then it's ok.

Lets try to at least not be passive aggressive towards efforts in that
direction.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/27/2016 8:53 PM, Andreas Cadhalpun wrote:
> On 28.11.2016 00:37, James Almer wrote:
>> On 11/27/2016 8:23 PM, Andreas Cadhalpun wrote:
>>> This can't happen while ffserver still uses internal API, and when it 
>>> doesn't
>>> making it standalone isn't really useful, in particular because a standalone
>>> version can't be tested with FATE.
>>
>> We don't care about testing it with FATE.
> 
> Who is "we"?

The majority of developers that waited years for someone to try and make this
thing usable and got tired of doing it.

> 
> On 27.11.2016 19:30, Clément Bœsch wrote:
>> unless the fundamental problems are addressed (ZERO internal API usage +
>> at least partial FATE coverage)

Re-read his email. That paragraph is about work aimed at fixing ffserver if
it were to remain in the tree. Which it wont.

> 
> Apparently Clément cares about FATE coverage and so do I.
> 
>> It appears to me that you still don't get that ffserver is being *dropped*.
>> It is, as discussed and announced, no longer part of the project.
> 
> The main reason for deciding to drop ffserver was that it uses internal APIs
> and thus blocks the library development. Should that get fixed, the decision
> needs to be re-evaluated.

No. It will not be reviewed just because one or two people came out of the
woodworks years after requests for help and maintainers flew by unheard and
right when the final decision to drop the whole thing was made.

If you were interested, you had *years* to make that known. That time is now
past.

> 
>>> Why do you think removing it has any benefit, if it doesn't come together
>>> with the library cleanup?
>>
>> The "benefit" would be finally following through with a project decision for
>> once, even if late, but at least not embarrassingly late.
> 
> Do I understand you correctly that there is no technical benefit?

It goes the other way around. There are no technical reasons that block the
removal something that has been decided must go. Or rather, must have been
gone weeks ago.

> The project decision can be followed by removing ffserver at the next major
> bump, if it still uses any of the internal APIs that will be made private 
> then.

No "if".

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Josh de Kock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016/11/27 23:56, Rostislav Pehlivanov wrote:
> On 27 November 2016 at 23:20, James Almer 
> wrote:
> 
>> On 11/26/2016 6:00 PM, Rostislav Pehlivanov wrote:
>>> On 26 October 2016 at 23:43, Rostislav Pehlivanov
>>> 
>>> 
>>> Since a month has passed, reynaldo still hasn't responded, I
>>> think it's long overdue to push this patch. I've attached a new
>>> version of the patch which only removes the ffserver program
>>> (without touching anything else), which had been OK'd by James
>>> Almer.
>>> 
>>> I'll push this on Tuesday next week, the 29th of November.
>> 
>> Since at least Michael is still working towards getting it
>> working as a standalone program it is acceptable to wait until
>> 3.3 is close to being branched from master.
>> 
>> It *must not* make it into that release, but until then being in
>> the tree or out of it will not hurt, and will make Michael's and
>> Reynaldo's efforts easier.
>> 
> 
> Yeah, let's not rush things, I wouldn't mind waiting until then
> either. And I agree that ffserver shouldn't be in the main repo in
> the 3.3 release.

I don't think anyone is rushing things, this has waited long enough.
We have an ultimatum, which is to push this on the 29th of November.
And it is important to stick to that now.

- -- 
Josh

PGP fingerprint: A93A602D7A6D3C5388D792BCD052D40DDEF9703D
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYO3M9AAoJENBS1A3e+XA9W+UP/1DPI48ETRG5frMPx0nW8x32
um/J7v6ZkmBKy1Jql3Ozm2yCvyUqq0GL/KIbfyd/ZfVifuqhHs43/F2XUoDXxvvK
4FfM4KDdINFFoZc1AaWexleN/W2rmLY/o0GzQ+Jc7wxbamsXz8a0f2D5XAa8b+CI
WHBvWXKLoO0dMi3mF6Ajlcu/3LcE11FX6WYHtImGL56+G/b/xA5+X9m/JZz+HwWG
4B2+wxBJ+xwKXzyQn+ohZi2dkjgbfbGaJvW5wY2TtDNSHkdUErDS0T8R/iGBrPi8
BCgl4Yac1EAkFq8s3Vu4WeTrPh+CCVLzvGNIsjuqqA5Zrd+PY1IxFLIzlvbhRyw1
wmWB4W8MzrOBzojQeskIMIMMWFjUf47xzOxnhPe+0Sfh+ZsTxo88bTh+0GMzPMeB
mjjqXU1zJXOV2b9oV8VjrKv2QpfL9aOoqRN6Yg017RJz/8B7jlhIjsGZZ1KetnsR
WF+GuITr8TxIDmW4v5Yp7NJiuqAS5q32+QzaxrCPFoTB9KWCY6wCDtVybffY8zXp
7GaMSO1O2lo20tvMgScu/zxqNXgD7Mpj7y5RAmrK5CDYcHNDnToJUnMaL4HLKn1c
acROvQYBQ9agyNbOFnUeYHjmutiuTqjKky5r5ssKipIRPcCkFvWKo4KpOXsoCIur
1LjuQmYodrl4xb2Wk4DV
=RUC9
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Rostislav Pehlivanov]

On 27 November 2016 at 23:20, James Almer  wrote:

> On 11/26/2016 6:00 PM, Rostislav Pehlivanov wrote:
> > On 26 October 2016 at 23:43, Rostislav Pehlivanov 
> > wrote:
> >
> >>
> >>
> >> On 26 October 2016 at 23:33, Andreas Cadhalpun <
> >> andreas.cadhal...@googlemail.com> wrote:
> >>
> >>> On 27.10.2016 00:16, Rostislav Pehlivanov wrote:
>  On 26 October 2016 at 22:48, James Almer  wrote:
> 
> > On 10/26/2016 6:19 PM, Rostislav Pehlivanov wrote:
> >> Also removes url_feof from libavformat.v which should have been
> >> removed long ago and changed the multipart jpeg boundary tag to
> >> ffmpeg rather than ffserver (it's arbitrary).
> >
> > [...]
> >
> >> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
> >> index c961cd8..47d5ddc 100644
> >> --- a/libavformat/libavformat.v
> >> +++ b/libavformat/libavformat.v
> >> @@ -1,19 +1,6 @@
> >>  LIBAVFORMAT_MAJOR {
> >>  global:
> >>  av*;
> >> -#FIXME those are for ffserver
> >> -ff_inet_aton;
> >> -ff_socket_nonblock;
> >> -ff_rtsp_parse_line;
> >> -ff_rtp_get_local_rtp_port;
> >> -ff_rtp_get_local_rtcp_port;
> >> -ffio_open_dyn_packet_buf;
> >> -ffio_set_buf_size;
> >> -ffurl_close;
> >> -ffurl_open;
> >> -ffurl_write;
> >> -#those are deprecated, remove on next bump
> >> -url_feof;
> >>  local:
> >>  *;
> >>  };
> >
> > No, this can't be done until the next major bump. url_feof is even
> >>> guarded
> > by an scheduled FF_API define.
> >
> > The rest should be ok, but anything that implies a library ABI break
> >>> can't
> > be done just yet. Wait for other comments and/or testing. This
> removes
> >>> a
> > lot of things after all.
> >
>  Fixed version attached without removing url_feof (apparently that's
> >>> meant
>  to go in the next bump, wasn't forgotten)
> >>>
> >>> No, none of the symbols can be removed without a major bump. The simple
> >>> reason
> >>> is that a ffserver built from the 3.1 branch still has to work with the
> >>> libavformat from the 3.2 branch.
> >>>
> >>> Best regards,
> >>> Andreas
> >>>
> >>> ___
> >>> ffmpeg-devel mailing list
> >>> ffmpeg-devel@ffmpeg.org
> >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>>
> >>
> >> Thanks for telling me,
> >> Attached patch will only remove the ffserver program and documentation
> >> relating to it.
> >> The ffm demuxer/muxer will be removed with the next bump like url_feof.
> >>
> >
> >
> > Since a month has passed, reynaldo still hasn't responded, I think it's
> > long overdue to push this patch. I've attached a new version of the patch
> > which only removes the ffserver program (without touching anything else),
> > which had been OK'd by James Almer.
> >
> > I'll push this on Tuesday next week, the 29th of November.
>
> Since at least Michael is still working towards getting it working as a
> standalone program it is acceptable to wait until 3.3 is close to being
> branched from master.
>
> It *must not* make it into that release, but until then being in the tree
> or out of it will not hurt, and will make Michael's and Reynaldo's efforts
> easier.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yeah, let's not rush things, I wouldn't mind waiting until then either. And
I agree that ffserver shouldn't be in the main repo in the 3.3 release.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] travis.yml: Whitelist "coverity" branch in preparation for Coverity integration

[Josh de Kock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016/11/27 23:47, Timothy Gu wrote:
> --- .travis.yml | 3 +++ 1 file changed, 3 insertions(+)
> 
> This patch will needed to be applied to all Git branches because of
> a Travis CI restriction: 
> https://docs.travis-ci.com/user/customizing-the-build#Building-Specifi
c-Branches
>
>
>
> 
diff --git a/.travis.yml b/.travis.yml index e541ee1..a50c46d
> 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,5 +1,8 @@ 
> language: c sudo: false +branches: +  only: +- coverity os: - 
> linux - osx
> 

There's no limit on travis org builds, as far as I know. And if Travis
is going to be added as a FATE client in the future then this commit
would have to be reverted.

- -- 
Josh

PGP fingerprint: A93A602D7A6D3C5388D792BCD052D40DDEF9703D
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYO3IvAAoJENBS1A3e+XA9/vgP/0SjBbMG6aMl66cjtLplScw8
hkQ/hwPXqQYkBT0NDEm83K7n5Fp2/LsFT8dmfwUSudzFS/kL8zXF4oOga3w2BBoQ
E984j7ivyE/893uAz0+Pxr8e6yocpKgK4ELCn2HI3wrMMrt22XtC1+3hvPh1yaAt
nyNv6opjrilClcQXvnZI+QobibAIgVuZXqfQckFcc+c+7jXX3bNEJpEkXVVYYVAw
rBdu6Ur5eeCWle+v1gW8phsRDmcYGBhwFgF/c8iq9faSr0QRLL5jB2lwQbvxfiK8
Hp9sGk4kMKQzKLcMlACvFXZe2fVmM37oJzp2iDFWzhJXucOrKV69LtxLRuXOYnnE
O3ApSlZ28M/Ki4w0fZRQb4AkMNbttVGErxCh94CcvZxDbad9woUe4PUKZTGoptH2
ZJ77LUNdB/tRHIExq18bZoPtIFUo/rQOuAe08Ze0rnL+C+KPDUBu3W+tsB6c/ap2
KNXY25OuO03hRLmHmi5trdB1KbRxL2NKsFO0MW7RJewzAqdF6wWO/43CNYg+4vN5
+Xd3kqgNzjoi/Ej8EcCeFwHjQL7jOHvgitEofTAwATmoGtQqQ+KzaEjIl+kgT522
JBvXNiNZs+eBxPb0RQQ6tG7aCvzivjvWCSlxXzS/98nqHaSSAQmhNAsrtme2K8sn
lMXB5542JQRsF/qems9X
=O8Fl
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Andreas Cadhalpun]

On 28.11.2016 00:37, James Almer wrote:
> On 11/27/2016 8:23 PM, Andreas Cadhalpun wrote:
>> This can't happen while ffserver still uses internal API, and when it doesn't
>> making it standalone isn't really useful, in particular because a standalone
>> version can't be tested with FATE.
> 
> We don't care about testing it with FATE.

Who is "we"?

On 27.11.2016 19:30, Clément Bœsch wrote:
> unless the fundamental problems are addressed (ZERO internal API usage +
> at least partial FATE coverage)

Apparently Clément cares about FATE coverage and so do I.

> It appears to me that you still don't get that ffserver is being *dropped*.
> It is, as discussed and announced, no longer part of the project.

The main reason for deciding to drop ffserver was that it uses internal APIs
and thus blocks the library development. Should that get fixed, the decision
needs to be re-evaluated.

>> Why do you think removing it has any benefit, if it doesn't come together
>> with the library cleanup?
> 
> The "benefit" would be finally following through with a project decision for
> once, even if late, but at least not embarrassingly late.

Do I understand you correctly that there is no technical benefit?
The project decision can be followed by removing ffserver at the next major
bump, if it still uses any of the internal APIs that will be made private then.

Best regards,
Andreas

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

[FFmpeg-devel] [PATCH] travis.yml: Whitelist "coverity" branch in preparation for Coverity integration

[Timothy Gu]

---
 .travis.yml | 3 +++
 1 file changed, 3 insertions(+)

This patch will needed to be applied to all Git branches because of a Travis CI
restriction:
https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches

diff --git a/.travis.yml b/.travis.yml
index e541ee1..a50c46d 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,5 +1,8 @@
 language: c
 sudo: false
+branches:
+  only:
+- coverity
 os:
   - linux
   - osx
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/27/2016 8:23 PM, Andreas Cadhalpun wrote:
> On 28.11.2016 00:14, James Almer wrote:
>> On 11/27/2016 7:32 PM, Andreas Cadhalpun wrote:
>>> On 26.11.2016 22:00, Rostislav Pehlivanov wrote:
 Since a month has passed, reynaldo still hasn't responded, I think it's
 long overdue to push this patch. I've attached a new version of the patch
 which only removes the ffserver program (without touching anything else),
 which had been OK'd by James Almer.
>>>
>>> I don't think this patch is a good idea.
>>> Removing ffserver now would be a regression for anyone using it, but on the
>>> other hand would have no benefit, since the library cleanup cannot happen
>>> before the next major bump.
>>> Thus this patch has a net-negative effect.
>>
>> With the efforts of making it standalone and thus available to anyone that
>> wishes to use it with an up to date git master, this point becomes null.
> 
> This can't happen while ffserver still uses internal API, and when it doesn't
> making it standalone isn't really useful, in particular because a standalone
> version can't be tested with FATE.

We don't care about testing it with FATE. It appears to me that you still don't
get that ffserver is being *dropped*. It is, as discussed and announced, no
longer part of the project.
This standalone attempt is something Reynaldo himself said he wanted to do, and
thus he was given time with ffserver still in the tree to make it easier.

> 
 I'll push this on Tuesday next week, the 29th of November.
>>>
>>> Why can't you wait for the next major bump?
>>
>> I'm still ok with waiting until 3.3 is close to be branched out, to give
>> Reynaldo or Michael more time if they are still working on making it
>> standalone, but nothing longer than that.
> 
> Why do you think removing it has any benefit, if it doesn't come together
> with the library cleanup?

The "benefit" would be finally following through with a project decision for
once, even if late, but at least not embarrassingly late.

> 
> Best regards,
> Andreas
> 
> 
> ___
> 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/2] lavfi: make filter_frame non-recursive.

[Andreas Cadhalpun]

On 28.11.2016 00:23, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
>> Sure, but that conflict should be easy to resolve.
> 
> Easy, yes. But it must be done at each rebase, that is annoying. Wasted
> time that can be better used.

I'm not sure I understand. Just do the rebase once, commit the deprecation
to git master and happily work on the other changes.

>> Worst case would be that if the deprecation isn't added before the next
>> release, this patch would need to be reverted.
> 
> There is no reason to revert at all.

Not if the deprecation gets added, and thus this ifdeffery in avfilter.h
is reduced to a temporary problem.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Andreas Cadhalpun]

On 28.11.2016 00:14, James Almer wrote:
> On 11/27/2016 7:32 PM, Andreas Cadhalpun wrote:
>> On 26.11.2016 22:00, Rostislav Pehlivanov wrote:
>>> Since a month has passed, reynaldo still hasn't responded, I think it's
>>> long overdue to push this patch. I've attached a new version of the patch
>>> which only removes the ffserver program (without touching anything else),
>>> which had been OK'd by James Almer.
>>
>> I don't think this patch is a good idea.
>> Removing ffserver now would be a regression for anyone using it, but on the
>> other hand would have no benefit, since the library cleanup cannot happen
>> before the next major bump.
>> Thus this patch has a net-negative effect.
> 
> With the efforts of making it standalone and thus available to anyone that
> wishes to use it with an up to date git master, this point becomes null.

This can't happen while ffserver still uses internal API, and when it doesn't
making it standalone isn't really useful, in particular because a standalone
version can't be tested with FATE.

>>> I'll push this on Tuesday next week, the 29th of November.
>>
>> Why can't you wait for the next major bump?
> 
> I'm still ok with waiting until 3.3 is close to be branched out, to give
> Reynaldo or Michael more time if they are still working on making it
> standalone, but nothing longer than that.

Why do you think removing it has any benefit, if it doesn't come together
with the library cleanup?

Best regards,
Andreas


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

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
> Sure, but that conflict should be easy to resolve.

Easy, yes. But it must be done at each rebase, that is annoying. Wasted
time that can be better used.

> Worst case would be that if the deprecation isn't added before the next
> release, this patch would need to be reverted.

There is no reason to revert at all.

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 2/2] lavfi: make filter_frame non-recursive.

[Andreas Cadhalpun]

On 28.11.2016 00:11, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
>> How would it conflict with this patch?
>> Unless I misunderstood something the deprecation should only affect the
>> public API, while this change should only affect the internal parts,
>> so the only possible conflict could be in avfilter.h, where it would be
>> easy to resolve.
> 
> Making the structure opaque involves moving its definition from the
> public header to a private one (first copying then removing after the
> deprecation delay). Including the lines that deal with the new internal
> fields.
> 
> A patch that adds lines and a patch that moves the surrounding code
> conflict, there is no way about it.

Sure, but that conflict should be easy to resolve.

Anyway, I'm not really thrilled by the idea of doing the deprecation
afterwards, but if you do it soon, it shouldn't be a problem in practice.

Worst case would be that if the deprecation isn't added before the next
release, this patch would need to be reverted.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/26/2016 6:00 PM, Rostislav Pehlivanov wrote:
> On 26 October 2016 at 23:43, Rostislav Pehlivanov 
> wrote:
> 
>>
>>
>> On 26 October 2016 at 23:33, Andreas Cadhalpun <
>> andreas.cadhal...@googlemail.com> wrote:
>>
>>> On 27.10.2016 00:16, Rostislav Pehlivanov wrote:
 On 26 October 2016 at 22:48, James Almer  wrote:

> On 10/26/2016 6:19 PM, Rostislav Pehlivanov wrote:
>> Also removes url_feof from libavformat.v which should have been
>> removed long ago and changed the multipart jpeg boundary tag to
>> ffmpeg rather than ffserver (it's arbitrary).
>
> [...]
>
>> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
>> index c961cd8..47d5ddc 100644
>> --- a/libavformat/libavformat.v
>> +++ b/libavformat/libavformat.v
>> @@ -1,19 +1,6 @@
>>  LIBAVFORMAT_MAJOR {
>>  global:
>>  av*;
>> -#FIXME those are for ffserver
>> -ff_inet_aton;
>> -ff_socket_nonblock;
>> -ff_rtsp_parse_line;
>> -ff_rtp_get_local_rtp_port;
>> -ff_rtp_get_local_rtcp_port;
>> -ffio_open_dyn_packet_buf;
>> -ffio_set_buf_size;
>> -ffurl_close;
>> -ffurl_open;
>> -ffurl_write;
>> -#those are deprecated, remove on next bump
>> -url_feof;
>>  local:
>>  *;
>>  };
>
> No, this can't be done until the next major bump. url_feof is even
>>> guarded
> by an scheduled FF_API define.
>
> The rest should be ok, but anything that implies a library ABI break
>>> can't
> be done just yet. Wait for other comments and/or testing. This removes
>>> a
> lot of things after all.
>
 Fixed version attached without removing url_feof (apparently that's
>>> meant
 to go in the next bump, wasn't forgotten)
>>>
>>> No, none of the symbols can be removed without a major bump. The simple
>>> reason
>>> is that a ffserver built from the 3.1 branch still has to work with the
>>> libavformat from the 3.2 branch.
>>>
>>> Best regards,
>>> Andreas
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> Thanks for telling me,
>> Attached patch will only remove the ffserver program and documentation
>> relating to it.
>> The ffm demuxer/muxer will be removed with the next bump like url_feof.
>>
> 
> 
> Since a month has passed, reynaldo still hasn't responded, I think it's
> long overdue to push this patch. I've attached a new version of the patch
> which only removes the ffserver program (without touching anything else),
> which had been OK'd by James Almer.
> 
> I'll push this on Tuesday next week, the 29th of November.

Since at least Michael is still working towards getting it working as a
standalone program it is acceptable to wait until 3.3 is close to being
branched from master.

It *must not* make it into that release, but until then being in the tree
or out of it will not hurt, and will make Michael's and Reynaldo's efforts
easier.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/27/2016 7:32 PM, Andreas Cadhalpun wrote:
> On 26.11.2016 22:00, Rostislav Pehlivanov wrote:
>> Since a month has passed, reynaldo still hasn't responded, I think it's
>> long overdue to push this patch. I've attached a new version of the patch
>> which only removes the ffserver program (without touching anything else),
>> which had been OK'd by James Almer.
> 
> I don't think this patch is a good idea.
> Removing ffserver now would be a regression for anyone using it, but on the
> other hand would have no benefit, since the library cleanup cannot happen
> before the next major bump.
> Thus this patch has a net-negative effect.

With the efforts of making it standalone and thus available to anyone that
wishes to use it with an up to date git master, this point becomes null.

> 
>> I'll push this on Tuesday next week, the 29th of November.
> 
> Why can't you wait for the next major bump?

I'm still ok with waiting until 3.3 is close to be branched out, to give
Reynaldo or Michael more time if they are still working on making it
standalone, but nothing longer than that.
And if we happen to bump major with it, then your request would have been
granted.

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

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
> How would it conflict with this patch?
> Unless I misunderstood something the deprecation should only affect the
> public API, while this change should only affect the internal parts,
> so the only possible conflict could be in avfilter.h, where it would be
> easy to resolve.

Making the structure opaque involves moving its definition from the
public header to a private one (first copying then removing after the
deprecation delay). Including the lines that deal with the new internal
fields.

A patch that adds lines and a patch that moves the surrounding code
conflict, there is no way about it.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

[Andreas Cadhalpun]

On 27.11.2016 17:08, Nicolas George wrote:
> Changed the private fields: directly in avfilter.h with discreet ifdef
> (preferred by Clément) with guarding reserved field (must urgent
> countermeasure).

Thanks.

> I made a few tests and it seems making AVFilterLink completely opaque would
> be really not much work, just a few accessor functions for buffersink and
> the corresponding change in ffmpeg*.c.
> 
> Still, it requires the whole deprecation dance, so it will not happen
> immediately. And it conflicts with this patch, si I would like to apply it
> before starting on it.

How would it conflict with this patch?
Unless I misunderstood something the deprecation should only affect the
public API, while this change should only affect the internal parts,
so the only possible conflict could be in avfilter.h, where it would be
easy to resolve.

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

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Philip Langdale]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlg7ZnwACgkQ+NaxlGp1aC7rHQCfeMtiAL4kPwIFd37da56aFtVY
eiEAn3Vh0A63CcNSu6MuGVuo8p5U/CJw
=eJcJ
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] pngdec: check if previous frame exists instead of trusting sequence_number

[Andreas Cadhalpun]

On 27.11.2016 04:07, Michael Niedermayer wrote:
> On Sat, Nov 26, 2016 at 11:36:48PM +0100, Andreas Cadhalpun wrote:
>>  pngdec.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 141d5230c97dbc47e0b291f660544cfe57abbf7c  
>> 0001-pngdec-check-if-previous-frame-exists-instead-of-tru.patch
>> From 84125e5f32fd4b9146d9926d2f8a4467da7c8557 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Fri, 25 Nov 2016 22:09:51 +0100
>> Subject: [PATCH] pngdec: check if previous frame exists instead of trusting
>>  sequence_number
>>
>> This fixes a segmentation fault caused by calling memcpy with NULL as
>> second argument in handle_p_frame_apng.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/pngdec.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Andreas Cadhalpun]

On 26.11.2016 22:00, Rostislav Pehlivanov wrote:
> Since a month has passed, reynaldo still hasn't responded, I think it's
> long overdue to push this patch. I've attached a new version of the patch
> which only removes the ffserver program (without touching anything else),
> which had been OK'd by James Almer.

I don't think this patch is a good idea.
Removing ffserver now would be a regression for anyone using it, but on the
other hand would have no benefit, since the library cleanup cannot happen
before the next major bump.
Thus this patch has a net-negative effect.

> I'll push this on Tuesday next week, the 29th of November.

Why can't you wait for the next major bump?

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

Re: [FFmpeg-devel] [PATCH] ffserver: Remove last use of AVStream size

[Ronald S. Bultje]

Hi,

On Sun, Nov 27, 2016 at 1:26 PM, Michael Niedermayer  wrote:

> Signed-off-by: Michael Niedermayer 
> ---
>  ffserver.c | 18 --
>  1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/ffserver.c b/ffserver.c
> index ded5149..9b1f6d5 100644
> --- a/ffserver.c
> +++ b/ffserver.c
> @@ -2961,7 +2961,6 @@ static int prepare_sdp_description(FFServerStream
> *stream, uint8_t **pbuffer,
> struct in_addr my_ip)
>  {
>  AVFormatContext *avc;
> -AVStream *avs = NULL;
>  AVOutputFormat *rtp_format = av_guess_format("rtp", NULL, NULL);
>  AVDictionaryEntry *entry = av_dict_get(stream->metadata, "title",
> NULL, 0);
>  int i;
> @@ -2975,7 +2974,6 @@ static int prepare_sdp_description(FFServerStream
> *stream, uint8_t **pbuffer,
>  avc->oformat = rtp_format;
>  av_dict_set(>metadata, "title",
>  entry ? entry->value : "No Title", 0);
> -avc->nb_streams = stream->nb_streams;
>  if (stream->is_multicast) {
>  snprintf(avc->filename, 1024, "rtp://%s:%d?multicast=1?ttl=%d",
>   inet_ntoa(stream->multicast_ip),
> @@ -2983,19 +2981,12 @@ static int prepare_sdp_description(FFServerStream
> *stream, uint8_t **pbuffer,
>  } else
>  snprintf(avc->filename, 1024, "rtp://0.0.0.0");
>
> -avc->streams = av_malloc_array(avc->nb_streams,
> sizeof(*avc->streams));
> -if (!avc->streams)
> -goto sdp_done;
> -
> -avs = av_malloc_array(avc->nb_streams, sizeof(*avs));
> -if (!avs)
> -goto sdp_done;
> -
>  for(i = 0; i < stream->nb_streams; i++) {
> -avc->streams[i] = [i];
> -avc->streams[i]->codec = stream->streams[i]->codec;
> +AVStream *st = avformat_new_stream(avc, NULL);
> +if (!st)
> +goto sdp_done;
>  avcodec_parameters_from_context(stream->streams[i]->codecpar,
> stream->streams[i]->codec);
> -avc->streams[i]->codecpar = stream->streams[i]->codecpar;
> +unlayer_stream(st, stream->streams[i]);
>  }
>  #define PBUFFER_SIZE 2048
>  *pbuffer = av_mallocz(PBUFFER_SIZE);
> @@ -3007,7 +2998,6 @@ static int prepare_sdp_description(FFServerStream
> *stream, uint8_t **pbuffer,
>  av_freep(>streams);
>  av_dict_free(>metadata);
>  av_free(avc);
> -av_free(avs);
>
>  return *pbuffer ? strlen(*pbuffer) : AVERROR(ENOMEM);
>  }
> --
> 2.10.2


I think you're sending this to the wrong repository, ffserver is not part
of the ffmpeg tree anymore.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Andreas Cadhalpun]

On 27.11.2016 19:36, Michael Niedermayer wrote:
> If somethig critical remains, please someone list exactly what that is.
> so reynaldo, i or others can go over the list and look into the issues

As far as I'm aware the following points are most problematic:
 * ffserver uses internal functions, see FIXME in libavformat/libavformat.v
 * ffserver uses the ffm format, which is incompatible with codecpar:
- It sets AVOptions of the stream->codec.
- It sets fields like qmin, which is not possible with codecpar.
 * There is no working FATE test, so developers not using ffserver
   can't really work on it for fear of breaking stuff.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Ronald S. Bultje]

Hi,

On Sun, Nov 27, 2016 at 1:46 PM, Michael Niedermayer  wrote:

> On Sun, Nov 27, 2016 at 07:30:24PM +0100, Clément Bœsch wrote:
> > On Sun, Nov 27, 2016 at 06:49:35PM +0100, Michael Niedermayer wrote:
> > > On Sun, Nov 27, 2016 at 04:57:36PM +0100, Clément Bœsch wrote:
> > > > On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
> > > > [...]
> > > > > ffserver had 14 commits to it in about the last month
> > > >
> > > > That's also pretty close to the number of commits in the last years.
> > > >
> > > > Good will in the last weeks is not enough of a technical
> > > > merit/justification to prevent the removal of junk code scheduled for
> > > > deletion for a long time now.
> > >
> > > why do you call it junk ?
> >
> > because it's highly dependent on internal stuff, very limited, completely
> > untested, unmaintained for several years but still contains a ton of
> code.
> >
> > > and the sheduling for deletion was conditional on it not being fixed
> > > IIRC.
> > > Why the hurry to remove it while people work on fixing it ?
> > > its not blocking anything ATM AFAIK
> >
> > There is no hurry, but piling up a bunch patches to fix small things just
> > to use it as an argument to say "hey look now it's maintained" in order
> to
> > save it from being killed is really annoying. The people interested in it
> > had years to act.
> >
>
> > You can fix a ton of little things in it, but unless the fundamental
> > problems are addressed (ZERO internal API usage + at least partial FATE
> > coverage) it's pointless
>
> of course the goal is ZERO internal API usage + at least partial FATE
> coverage.
> Well in fact the lack of fate tests have been the primary reason
> why i didnt fix some of the API issues years ago. I felt uneasy
> changing it without regression tests
>
>
> > and will be seen as yet another case of "KEEP
> > EVERYTHING FOREVER" toxic mentality.
>
> The opposit is toxic too


I'm perfectly fine with keeping the code, just not in the ffmpeg tree.
Please move it to its own tree.

Everybody wants it out. Please follow majority.

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

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Timo Rothenpieler]

> 3. Proprietary dependencies, which may or may not currently be an issue
> anymore. Philip and Timo, how easy is it to get cuda/nvenc/cuvid/npp to
> compile.
> 

cuda/cuvid/nvenc don't need any external dependencies to compile, only
to run.
libnpp needs proprietary and non-redistributable headers to compile, so
I'm not sure if it's possible at all to build it on public infrastructure.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Timothy Gu]

On Sun, Nov 27, 2016 at 1:52 PM Michael Niedermayer 
wrote:

> I dont want to give a automated travis_ci system any write or admin
> access, some of what i read hinted in that direction, some of what
> i read hinted that this was not needed though
> giving a automated system write access would be a security issue and
> we should not do that
>

You don't need to give Travis CI any privileges. The way it's going to work
is:

1. Set up a dedicated "coverity" branch
2. Set up Travis CI to only watch changes on that branch, and when there is
a new push compile the code with Coverity's custom wrappers, etc.
3. Set up a cronjob on a computer (doesn't matter who's) that pulls new
commits on master into coverity every |x| days

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

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Timothy Gu]

On Sun, Nov 27, 2016 at 1:13 PM Philip Langdale  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sun, 27 Nov 2016 21:26:13 +0100
> Michael Niedermayer  wrote:
>
> > On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > On Sat, 26 Nov 2016 23:55:17 +0100
> > > Michael Niedermayer  wrote:
> > >
> > > > Hi all
> > > >
> > > > The machine on which the coverity stuff is is old, both hw and OS.
> > > > the OS will no longer get security updates in a few months and
> > > > the hw does not always boot and its switched off most of the time.
> > > > and it has no other use anymore than running coverity. Ive tried
> > > > to find someone a while ago to take coverity testing over and i
> > > > thought timothy would maybe do it but he seems to not have had any
> > > > time to look into it ...
> > > > and de facto ive not run it regularly in the recent months.
> > > > So this is kinda a louder announcement that if you care about
> > > > coverity testing, you need to do something ...
> > > >
> > > > thx
> > > >
> > > > PS: work would involve installing every optional dependancy of
> > > > FFmpeg (and keep them updated as needed)
> > > > and regularly either manually or automatically git pull, build
> > > > with the coverity tools and upload Its not a huge amount of work
> > > > but it is work
> > > >
> > >
> > > Hi Michael,
> > >
> > > I think we could do this using travis-ci.
> > >
> > > https://scan.coverity.com/travis_ci
> > >
> > > travis can be directly connected to the github mirror and then we
> > > set up a coverity job as covered in this doc.
> > >
> > > It wouldn't even need to be configured to build - just run the
> > > coverity scan. I'd be happy to investigate this, but I'd need admin
> > > permissions on github to configure travis integration.
> >
> > The way coverity works is by wraping around the compiler or something
> > gether lots of info and that is then uploaded
> > so you need configure and build
> >
> > for coverity to check all optional code it needs all the headers
> > from nvidia, sdl, x11 to the most obscure.
> > if they arent installed coverity wouldnt be able to test these
> > components as the code would not be complete
> >
> > so in whatever envirnment this is done all optional dependancies
> > must be installed one way or another.
> >
> > i assume in the example on https://scan.coverity.com/travis_ci
> > build_command_prepend: ./configure
> > would be a very long command with many --enable*
> >
> > also therese that limit:
> > https://scan.coverity.com/faq#frequency
> > Up to 12 builds per week, with a maximum of 3 builds per day, for
> > projects with fewer than 100K lines of code Up to   8 builds per
> > week, with a maximum of 2 builds per day, for projects with 100K to
> > 500K lines of code Up to   4 builds per week, with a maximum of 1
> > build per day, for projects with 500K to 1 million lines of code Up
> > to   2 builds per week, with a maximum of 1 build per day, for
> > projects with more than 1 million lines of code
> >
> > so we cannot do coverity after every commit, a cronjob might be a
> > simpler choice that runs at the frequency that we can submit
> >
> > Is there still an advantage in travis ci / would that still be
> > preferred?
> >
> > [...]
>
> The recommended configuration on that page is to have it watch a branch
> and you push master to the branch when you want a scan. We can do that
> whenever we want - once a month or whatever. Right now you are doing it
> ad-hoc, and we could still do it ad-hoc. Equally, a cron job running
> somewhere could push to the branch on whatever frequency we want.
>
> The goal here is to remove the need for the dedicated build machine, not
> to improve any other part of the process - although there will be
> opportunities for that.
>
> I've looked at how you prepare a build environment in travis and it's
> simple to install dependencies; that won't be a problem.
>

Libav has had used Travis for a while now for FATE, and I personally have
attempted to set up the same for FFmpeg, without much success.

The problem with using Travis for Coverity (versus a local machine) is
still the issue of dependencies. While system-level deps like vdpau can be
installed easily, there are three classes of other deps that need to be
installed to make Coverity the most useful:

1. Dependencies very few people use, and therefore not packaged by Ubuntu
(e.g. libnut, libxavs, zimg)
2. Dependencies in active development, only the newest versions of which
are accepted by FFmpeg's build system (there currently isn't any examples
but it's not impossible to see this in the future)
3. Proprietary dependencies, which may or may not currently be an issue
anymore. Philip and Timo, how easy is it to get cuda/nvenc/cuvid/npp to
compile.

Timothy
___

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Michael Niedermayer]

On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sat, 26 Nov 2016 23:55:17 +0100
> Michael Niedermayer  wrote:
> 
> > Hi all
> > 
> > The machine on which the coverity stuff is is old, both hw and OS.
> > the OS will no longer get security updates in a few months and the hw
> > does not always boot and its switched off most of the time.
> > and it has no other use anymore than running coverity. Ive tried
> > to find someone a while ago to take coverity testing over and i
> > thought timothy would maybe do it but he seems to not have had any
> > time to look into it ...
> > and de facto ive not run it regularly in the recent months.
> > So this is kinda a louder announcement that if you care about coverity
> > testing, you need to do something ...
> > 
> > thx
> > 
> > PS: work would involve installing every optional dependancy of FFmpeg
> > (and keep them updated as needed)
> > and regularly either manually or automatically git pull, build with
> > the coverity tools and upload Its not a huge amount of work but it is
> > work
> > 
> 
> Hi Michael,
> 
> I think we could do this using travis-ci.
> 
> https://scan.coverity.com/travis_ci
> 
> travis can be directly connected to the github mirror and then we set
> up a coverity job as covered in this doc.
> 
> It wouldn't even need to be configured to build - just run the coverity
> scan. I'd be happy to investigate this, but I'd need admin permissions
> on github to configure travis integration.

what changes need to be done on github to make this work
if you tell me the settings for the webhook (assumig its one)
i can enable that.

I dont want to give a automated travis_ci system any write or admin
access, some of what i read hinted in that direction, some of what
i read hinted that this was not needed though
giving a automated system write access would be a security issue and
we should not do that

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Philip Langdale]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 27 Nov 2016 21:26:13 +0100
Michael Niedermayer  wrote:

> On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On Sat, 26 Nov 2016 23:55:17 +0100
> > Michael Niedermayer  wrote:
> >   
> > > Hi all
> > > 
> > > The machine on which the coverity stuff is is old, both hw and OS.
> > > the OS will no longer get security updates in a few months and
> > > the hw does not always boot and its switched off most of the time.
> > > and it has no other use anymore than running coverity. Ive tried
> > > to find someone a while ago to take coverity testing over and i
> > > thought timothy would maybe do it but he seems to not have had any
> > > time to look into it ...
> > > and de facto ive not run it regularly in the recent months.
> > > So this is kinda a louder announcement that if you care about
> > > coverity testing, you need to do something ...
> > > 
> > > thx
> > > 
> > > PS: work would involve installing every optional dependancy of
> > > FFmpeg (and keep them updated as needed)
> > > and regularly either manually or automatically git pull, build
> > > with the coverity tools and upload Its not a huge amount of work
> > > but it is work
> > >   
> > 
> > Hi Michael,
> > 
> > I think we could do this using travis-ci.
> > 
> > https://scan.coverity.com/travis_ci
> > 
> > travis can be directly connected to the github mirror and then we
> > set up a coverity job as covered in this doc.
> > 
> > It wouldn't even need to be configured to build - just run the
> > coverity scan. I'd be happy to investigate this, but I'd need admin
> > permissions on github to configure travis integration.  
> 
> The way coverity works is by wraping around the compiler or something
> gether lots of info and that is then uploaded
> so you need configure and build
> 
> for coverity to check all optional code it needs all the headers
> from nvidia, sdl, x11 to the most obscure.
> if they arent installed coverity wouldnt be able to test these
> components as the code would not be complete
> 
> so in whatever envirnment this is done all optional dependancies
> must be installed one way or another.
> 
> i assume in the example on https://scan.coverity.com/travis_ci
> build_command_prepend: ./configure
> would be a very long command with many --enable*
> 
> also therese that limit:
> https://scan.coverity.com/faq#frequency
> Up to 12 builds per week, with a maximum of 3 builds per day, for
> projects with fewer than 100K lines of code Up to   8 builds per
> week, with a maximum of 2 builds per day, for projects with 100K to
> 500K lines of code Up to   4 builds per week, with a maximum of 1
> build per day, for projects with 500K to 1 million lines of code Up
> to   2 builds per week, with a maximum of 1 build per day, for
> projects with more than 1 million lines of code
> 
> so we cannot do coverity after every commit, a cronjob might be a
> simpler choice that runs at the frequency that we can submit
> 
> Is there still an advantage in travis ci / would that still be
> preferred?
> 
> [...]

The recommended configuration on that page is to have it watch a branch
and you push master to the branch when you want a scan. We can do that
whenever we want - once a month or whatever. Right now you are doing it
ad-hoc, and we could still do it ad-hoc. Equally, a cron job running
somewhere could push to the branch on whatever frequency we want.

The goal here is to remove the need for the dedicated build machine, not
to improve any other part of the process - although there will be
opportunities for that.

I've looked at how you prepare a build environment in travis and it's
simple to install dependencies; that won't be a problem.

- --phil
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlg7TGAACgkQ+NaxlGp1aC6i4ACfRa1OR4OGIeOyaa9HBu5dFdSN
XsUAn0UOkiI1xTYPV/H3eCOOPLrx6SJi
=o6R4
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Josh de Kock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016/11/27 19:00, Philip Langdale wrote:
> On Sat, 26 Nov 2016 23:55:17 +0100 Michael Niedermayer
>  wrote:
> 
>> Hi all
> 
>> The machine on which the coverity stuff is is old, both hw and
>> OS. the OS will no longer get security updates in a few months
>> and the hw does not always boot and its switched off most of the
>> time. and it has no other use anymore than running coverity. Ive
>> tried to find someone a while ago to take coverity testing over
>> and i thought timothy would maybe do it but he seems to not have
>> had any time to look into it ... and de facto ive not run it
>> regularly in the recent months. So this is kinda a louder
>> announcement that if you care about coverity testing, you need to
>> do something ...
> 
>> thx
> 
>> PS: work would involve installing every optional dependancy of
>> FFmpeg (and keep them updated as needed) and regularly either
>> manually or automatically git pull, build with the coverity tools
>> and upload Its not a huge amount of work but it is work
> 
> 
> Hi Michael,
> 
> I think we could do this using travis-ci.
> 
> https://scan.coverity.com/travis_ci
> 
> travis can be directly connected to the github mirror and then we
> set up a coverity job as covered in this doc.
> 
> It wouldn't even need to be configured to build - just run the
> coverity scan. I'd be happy to investigate this, but I'd need admin
> permissions on github to configure travis integration.
> 
> --phil

I can help with Travis CI + GitHub, if any is needed, I have used it
extensively with other open-source projects.

- -- 
Josh

PGP fingerprint: A93A602D7A6D3C5388D792BCD052D40DDEF9703D
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYO0qrAAoJENBS1A3e+XA947MP/RZplh1BTM/Cn0suaCZygIFo
elJyY1uxMGUvABnC4QHvIxpuuq+SewEA9VzbqMrSWV3xSueFZo8wQQTifCnlc69O
oipwzqyaHjqXRSMiAxMpVPAzdEIvslB8aXwdWELKy9GcHkUVn2hEzitBOfi/qL7y
L3m80h5ZgH4UExSyZmqWniJcOgeC/MZWIvLhGmtdsAihGAVQkS2czQKAJtxSMiJT
hEppu6xHWNLEwN3QnTIhuQGvbVlEQUm9A6/C8x74JJe0lWG3YGpWc2I9OJt07I6Z
J6Rstzuk0EPoS/8CaFTjyMrEgc8v+QIpIjY9GCt0pgDsaUEtA8Cq03IL4wHruowi
nJ8ZSJq0uJQtIws0G/uc29bjKqjz3rHTRXS73uYPDFmfG0hp/pbWDF6UoOate2J7
vtwRfl6oDdZOJAXhg+Wr2DMFiwdSK7niboArYxf+z1mooco6RnCI2uthIGCtt3Gb
i4x89YK1jaSKsbBqTmhw3rCCmSIR318p4vdIiwcULJqm5ZaZc3KU/OYYNiOKxkxx
EwzstoGC7yjXwc1S7Ohmu5yPoFWISmFhL15d8zCvDjpAlUCN1Euc5WFdftT2OaEX
pE6nikt/q6KmPQhQsAGCBX/Nd3QeOwBzGKA9qx9cXLtEt8vssgdL93lFTBZM0m+J
dtbGnlFRnzMsCosrFUCL
=jyZO
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Michael Niedermayer]

On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sat, 26 Nov 2016 23:55:17 +0100
> Michael Niedermayer  wrote:
> 
> > Hi all
> > 
> > The machine on which the coverity stuff is is old, both hw and OS.
> > the OS will no longer get security updates in a few months and the hw
> > does not always boot and its switched off most of the time.
> > and it has no other use anymore than running coverity. Ive tried
> > to find someone a while ago to take coverity testing over and i
> > thought timothy would maybe do it but he seems to not have had any
> > time to look into it ...
> > and de facto ive not run it regularly in the recent months.
> > So this is kinda a louder announcement that if you care about coverity
> > testing, you need to do something ...
> > 
> > thx
> > 
> > PS: work would involve installing every optional dependancy of FFmpeg
> > (and keep them updated as needed)
> > and regularly either manually or automatically git pull, build with
> > the coverity tools and upload Its not a huge amount of work but it is
> > work
> > 
> 
> Hi Michael,
> 
> I think we could do this using travis-ci.
> 
> https://scan.coverity.com/travis_ci
> 
> travis can be directly connected to the github mirror and then we set
> up a coverity job as covered in this doc.
> 
> It wouldn't even need to be configured to build - just run the coverity
> scan. I'd be happy to investigate this, but I'd need admin permissions
> on github to configure travis integration.

The way coverity works is by wraping around the compiler or something
gether lots of info and that is then uploaded
so you need configure and build

for coverity to check all optional code it needs all the headers
from nvidia, sdl, x11 to the most obscure.
if they arent installed coverity wouldnt be able to test these
components as the code would not be complete

so in whatever envirnment this is done all optional dependancies
must be installed one way or another.

i assume in the example on https://scan.coverity.com/travis_ci
build_command_prepend: ./configure
would be a very long command with many --enable*

also therese that limit:
https://scan.coverity.com/faq#frequency
Up to 12 builds per week, with a maximum of 3 builds per day, for projects 
with fewer than 100K lines of code
Up to   8 builds per week, with a maximum of 2 builds per day, for projects 
with 100K to 500K lines of code
Up to   4 builds per week, with a maximum of 1 build per day, for projects 
with 500K to 1 million lines of code
Up to   2 builds per week, with a maximum of 1 build per day, for projects 
with more than 1 million lines of code

so we cannot do coverity after every commit, a cronjob might be a
simpler choice that runs at the frequency that we can submit

Is there still an advantage in travis ci / would that still be
preferred?

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] lavfi/ebur128: relicense to LGPL

[Clement Boesch]

On Sun, Nov 27, 2016 at 08:40:43PM +0100, Paul B Mahol wrote:
> On 11/26/16, Clement Boesch  wrote:
> > All copyright holders have agreed to the relicensing.
> >
> > Approved-by: Andreas Cadhalpun 
> > Approved-by: David Sedacca 
> > Approved-by: Ganesh Ajjanagadde 
> > Approved-by: Jean First 
> > Approved-by: Kyle Swanson 
> > Approved-by: Michael Niedermayer 
> > Approved-by: Nicolas George 
> > Approved-by: Paul B Mahol 
> > Approved-by: Thilo Borgmann 
> > ---
> > I plan to push this soon.
> >
> > Thanks to all contributors for agreeing to the relicensing.
> > ---
> >  LICENSE.md  |  1 -
> >  configure   |  1 -
> >  libavfilter/f_ebur128.c | 18 +-
> >  3 files changed, 9 insertions(+), 11 deletions(-)
> >
> 
> lgtm

applied, thanks

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/ebur128: relicense to LGPL

[Paul B Mahol]

On 11/26/16, Clement Boesch  wrote:
> All copyright holders have agreed to the relicensing.
>
> Approved-by: Andreas Cadhalpun 
> Approved-by: David Sedacca 
> Approved-by: Ganesh Ajjanagadde 
> Approved-by: Jean First 
> Approved-by: Kyle Swanson 
> Approved-by: Michael Niedermayer 
> Approved-by: Nicolas George 
> Approved-by: Paul B Mahol 
> Approved-by: Thilo Borgmann 
> ---
> I plan to push this soon.
>
> Thanks to all contributors for agreeing to the relicensing.
> ---
>  LICENSE.md  |  1 -
>  configure   |  1 -
>  libavfilter/f_ebur128.c | 18 +-
>  3 files changed, 9 insertions(+), 11 deletions(-)
>

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

[FFmpeg-devel] [PATCH] tools/coverity: Add models for av_mallocz and av_free

[Philip Langdale]

This should deal with some false positives, but might lead to
more of them depending on whether it realises that av_freep()
wraps av_free() or not.

Signed-off-by: Philip Langdale 
---
 tools/coverity.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/tools/coverity.c b/tools/coverity.c
index 80fc1c2..3cc248c 100644
--- a/tools/coverity.c
+++ b/tools/coverity.c
@@ -35,8 +35,30 @@
 void *av_malloc(size_t size) {
 int has_memory;
 __coverity_negative_sink__(size);
-if(has_memory)
-return __coverity_alloc__(size);
-else
+if (has_memory) {
+void *ptr = __coverity_alloc__(size);
+__coverity_mark_as_uninitialized_buffer__(ptr);
+__coverity_mark_as_afm_allocated__(ptr, "av_free");
+ return ptr;
+} else {
 return 0;
+}
+}
+
+void *av_mallocz(size_t size) {
+int has_memory;
+__coverity_negative_sink__(size);
+if (has_memory) {
+void *ptr = __coverity_alloc__(size);
+__coverity_writeall0__(ptr);
+__coverity_mark_as_afm_allocated__(ptr, "av_free");
+return ptr;
+} else {
+return 0;
+}
+}
+
+void *av_free(void *ptr) {
+__coverity_free__(ptr);
+__coverity_mark_as_afm_freed__(ptr, "av_free");
 }
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] coverity testing of FFmpeg

[Philip Langdale]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 26 Nov 2016 23:55:17 +0100
Michael Niedermayer  wrote:

> Hi all
> 
> The machine on which the coverity stuff is is old, both hw and OS.
> the OS will no longer get security updates in a few months and the hw
> does not always boot and its switched off most of the time.
> and it has no other use anymore than running coverity. Ive tried
> to find someone a while ago to take coverity testing over and i
> thought timothy would maybe do it but he seems to not have had any
> time to look into it ...
> and de facto ive not run it regularly in the recent months.
> So this is kinda a louder announcement that if you care about coverity
> testing, you need to do something ...
> 
> thx
> 
> PS: work would involve installing every optional dependancy of FFmpeg
> (and keep them updated as needed)
> and regularly either manually or automatically git pull, build with
> the coverity tools and upload Its not a huge amount of work but it is
> work
> 

Hi Michael,

I think we could do this using travis-ci.

https://scan.coverity.com/travis_ci

travis can be directly connected to the github mirror and then we set
up a coverity job as covered in this doc.

It wouldn't even need to be configured to build - just run the coverity
scan. I'd be happy to investigate this, but I'd need admin permissions
on github to configure travis integration.

- --phil
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlg7LUUACgkQ+NaxlGp1aC5q3QCgyRVxMRL80RSxDqRfj2zixL8D
rIkAn0s6o1bQr/lapHU+ZU2Y/+vWaYFt
=yig7
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Clément Bœsch]

On Sun, Nov 27, 2016 at 07:46:34PM +0100, Michael Niedermayer wrote:
[...]
> > You can fix a ton of little things in it, but unless the fundamental
> > problems are addressed (ZERO internal API usage + at least partial FATE
> > coverage) it's pointless
> 
> of course the goal is ZERO internal API usage + at least partial FATE
> coverage.

If you think you can manage this til the scheduled removal date, then
that's perfectly fine with me.

When is the due removal already? Next version?

Good luck.

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Sun, Nov 27, 2016 at 07:30:24PM +0100, Clément Bœsch wrote:
> On Sun, Nov 27, 2016 at 06:49:35PM +0100, Michael Niedermayer wrote:
> > On Sun, Nov 27, 2016 at 04:57:36PM +0100, Clément Bœsch wrote:
> > > On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
> > > [...]
> > > > ffserver had 14 commits to it in about the last month
> > > 
> > > That's also pretty close to the number of commits in the last years.
> > > 
> > > Good will in the last weeks is not enough of a technical
> > > merit/justification to prevent the removal of junk code scheduled for
> > > deletion for a long time now.
> > 
> > why do you call it junk ?
> 
> because it's highly dependent on internal stuff, very limited, completely
> untested, unmaintained for several years but still contains a ton of code.
> 
> > and the sheduling for deletion was conditional on it not being fixed
> > IIRC.
> > Why the hurry to remove it while people work on fixing it ?
> > its not blocking anything ATM AFAIK
> 
> There is no hurry, but piling up a bunch patches to fix small things just
> to use it as an argument to say "hey look now it's maintained" in order to
> save it from being killed is really annoying. The people interested in it
> had years to act.
> 

> You can fix a ton of little things in it, but unless the fundamental
> problems are addressed (ZERO internal API usage + at least partial FATE
> coverage) it's pointless

of course the goal is ZERO internal API usage + at least partial FATE
coverage.
Well in fact the lack of fate tests have been the primary reason
why i didnt fix some of the API issues years ago. I felt uneasy
changing it without regression tests


> and will be seen as yet another case of "KEEP
> EVERYTHING FOREVER" toxic mentality.

The opposit is toxic too

Thanks

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Sun, Nov 27, 2016 at 02:05:44PM +0100, Michael Niedermayer wrote:
> On Sat, Nov 26, 2016 at 09:00:41PM +, Rostislav Pehlivanov wrote:
> > On 26 October 2016 at 23:43, Rostislav Pehlivanov 
> > wrote:
> > 
> > >
> > >
> > > On 26 October 2016 at 23:33, Andreas Cadhalpun <
> > > andreas.cadhal...@googlemail.com> wrote:
> > >
> > >> On 27.10.2016 00:16, Rostislav Pehlivanov wrote:
> > >> > On 26 October 2016 at 22:48, James Almer  wrote:
> > >> >
> > >> >> On 10/26/2016 6:19 PM, Rostislav Pehlivanov wrote:
> > >> >>> Also removes url_feof from libavformat.v which should have been
> > >> >>> removed long ago and changed the multipart jpeg boundary tag to
> > >> >>> ffmpeg rather than ffserver (it's arbitrary).
> > >> >>
> > >> >> [...]
> > >> >>
> > >> >>> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
> > >> >>> index c961cd8..47d5ddc 100644
> > >> >>> --- a/libavformat/libavformat.v
> > >> >>> +++ b/libavformat/libavformat.v
> > >> >>> @@ -1,19 +1,6 @@
> > >> >>>  LIBAVFORMAT_MAJOR {
> > >> >>>  global:
> > >> >>>  av*;
> > >> >>> -#FIXME those are for ffserver
> > >> >>> -ff_inet_aton;
> > >> >>> -ff_socket_nonblock;
> > >> >>> -ff_rtsp_parse_line;
> > >> >>> -ff_rtp_get_local_rtp_port;
> > >> >>> -ff_rtp_get_local_rtcp_port;
> > >> >>> -ffio_open_dyn_packet_buf;
> > >> >>> -ffio_set_buf_size;
> > >> >>> -ffurl_close;
> > >> >>> -ffurl_open;
> > >> >>> -ffurl_write;
> > >> >>> -#those are deprecated, remove on next bump
> > >> >>> -url_feof;
> > >> >>>  local:
> > >> >>>  *;
> > >> >>>  };
> > >> >>
> > >> >> No, this can't be done until the next major bump. url_feof is even
> > >> guarded
> > >> >> by an scheduled FF_API define.
> > >> >>
> > >> >> The rest should be ok, but anything that implies a library ABI break
> > >> can't
> > >> >> be done just yet. Wait for other comments and/or testing. This removes
> > >> a
> > >> >> lot of things after all.
> > >> >>
> > >> > Fixed version attached without removing url_feof (apparently that's
> > >> meant
> > >> > to go in the next bump, wasn't forgotten)
> > >>
> > >> No, none of the symbols can be removed without a major bump. The simple
> > >> reason
> > >> is that a ffserver built from the 3.1 branch still has to work with the
> > >> libavformat from the 3.2 branch.
> > >>
> > >> Best regards,
> > >> Andreas
> > >>
> > >> ___
> > >> ffmpeg-devel mailing list
> > >> ffmpeg-devel@ffmpeg.org
> > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>
> > >
> > > Thanks for telling me,
> > > Attached patch will only remove the ffserver program and documentation
> > > relating to it.
> > > The ffm demuxer/muxer will be removed with the next bump like url_feof.
> > >
> > 
> > 
> > Since a month has passed, reynaldo still hasn't responded, I think it's
> > long overdue to push this patch. I've attached a new version of the patch
> > which only removes the ffserver program (without touching anything else),
> > which had been OK'd by James Almer.
> 
> IIUC reynaldo is very busy.
> 
> have you looked at ffserver ? I think helping reynaldo and updating
> ffserver so it doesnt violate the API would make alot more sense for
> FFmpeg than removing it. Its a long existing feature and tool.
> And i dont think its really that hard to update it, iam not the
> author of it iam not an expert on that code so i might be wrong or
> miss things but the big mess in it seems just moving parameters around
> between demuxers and muxers. and a few uses of network and rtp
> functions which should be used through some public API or made
> available through a new one everyone likes ...

the 4 patches i just posted fix all the AVStream issues i am aware of.
codec/codecpar issues seem no major ones left, just some close and copy
that would probably go away if the field is removed.

I think this solves the bulk of the problem that i was aware of

If somethig critical remains, please someone list exactly what that is.
so reynaldo, i or others can go over the list and look into the issues

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Clément Bœsch]

On Sun, Nov 27, 2016 at 06:49:35PM +0100, Michael Niedermayer wrote:
> On Sun, Nov 27, 2016 at 04:57:36PM +0100, Clément Bœsch wrote:
> > On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
> > [...]
> > > ffserver had 14 commits to it in about the last month
> > 
> > That's also pretty close to the number of commits in the last years.
> > 
> > Good will in the last weeks is not enough of a technical
> > merit/justification to prevent the removal of junk code scheduled for
> > deletion for a long time now.
> 
> why do you call it junk ?

because it's highly dependent on internal stuff, very limited, completely
untested, unmaintained for several years but still contains a ton of code.

> and the sheduling for deletion was conditional on it not being fixed
> IIRC.
> Why the hurry to remove it while people work on fixing it ?
> its not blocking anything ATM AFAIK

There is no hurry, but piling up a bunch patches to fix small things just
to use it as an argument to say "hey look now it's maintained" in order to
save it from being killed is really annoying. The people interested in it
had years to act.

You can fix a ton of little things in it, but unless the fundamental
problems are addressed (ZERO internal API usage + at least partial FATE
coverage) it's pointless and will be seen as yet another case of "KEEP
EVERYTHING FOREVER" toxic mentality.

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffserver: Remove last use of AVStream size

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 ffserver.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index ded5149..9b1f6d5 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -2961,7 +2961,6 @@ static int prepare_sdp_description(FFServerStream 
*stream, uint8_t **pbuffer,
struct in_addr my_ip)
 {
 AVFormatContext *avc;
-AVStream *avs = NULL;
 AVOutputFormat *rtp_format = av_guess_format("rtp", NULL, NULL);
 AVDictionaryEntry *entry = av_dict_get(stream->metadata, "title", NULL, 0);
 int i;
@@ -2975,7 +2974,6 @@ static int prepare_sdp_description(FFServerStream 
*stream, uint8_t **pbuffer,
 avc->oformat = rtp_format;
 av_dict_set(>metadata, "title",
 entry ? entry->value : "No Title", 0);
-avc->nb_streams = stream->nb_streams;
 if (stream->is_multicast) {
 snprintf(avc->filename, 1024, "rtp://%s:%d?multicast=1?ttl=%d",
  inet_ntoa(stream->multicast_ip),
@@ -2983,19 +2981,12 @@ static int prepare_sdp_description(FFServerStream 
*stream, uint8_t **pbuffer,
 } else
 snprintf(avc->filename, 1024, "rtp://0.0.0.0");
 
-avc->streams = av_malloc_array(avc->nb_streams, sizeof(*avc->streams));
-if (!avc->streams)
-goto sdp_done;
-
-avs = av_malloc_array(avc->nb_streams, sizeof(*avs));
-if (!avs)
-goto sdp_done;
-
 for(i = 0; i < stream->nb_streams; i++) {
-avc->streams[i] = [i];
-avc->streams[i]->codec = stream->streams[i]->codec;
+AVStream *st = avformat_new_stream(avc, NULL);
+if (!st)
+goto sdp_done;
 avcodec_parameters_from_context(stream->streams[i]->codecpar, 
stream->streams[i]->codec);
-avc->streams[i]->codecpar = stream->streams[i]->codecpar;
+unlayer_stream(st, stream->streams[i]);
 }
 #define PBUFFER_SIZE 2048
 *pbuffer = av_mallocz(PBUFFER_SIZE);
@@ -3007,7 +2998,6 @@ static int prepare_sdp_description(FFServerStream 
*stream, uint8_t **pbuffer,
 av_freep(>streams);
 av_dict_free(>metadata);
 av_free(avc);
-av_free(avs);
 
 return *pbuffer ? strlen(*pbuffer) : AVERROR(ENOMEM);
 }
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 1/3] ffserver: drop FeedData, its unused

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 ffserver.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index d40fe80..6b8eb2c 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -187,11 +187,6 @@ typedef struct HTTPContext {
 uint8_t *packet_buffer, *packet_buffer_ptr, *packet_buffer_end;
 } HTTPContext;
 
-typedef struct FeedData {
-long long data_count;
-float avg_frame_size;   /* frame size averaged over last frames with 
exponential mean */
-} FeedData;
-
 static HTTPContext *first_http_ctx;
 
 static FFServerConfig config = {
@@ -3533,7 +3528,6 @@ static AVStream *add_av_stream1(FFServerStream *stream,
  */
 fst->codec = codec;
 
-fst->priv_data = av_mallocz(sizeof(FeedData));
 fst->internal = av_mallocz(sizeof(*fst->internal));
 fst->internal->avctx = avcodec_alloc_context3(NULL);
 fst->codecpar = avcodec_parameters_alloc();
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 3/3] ffserver: Remove some deprecated API use related to codec/codecpar

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 ffserver.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index 1d8abd9..ded5149 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -2288,8 +2288,6 @@ static int http_prepare_data(HTTPContext *c)
 
 unlayer_stream(c->pfmt_ctx->streams[i], src); //TODO we no longer 
copy st->internal, does this matter?
 av_assert0(!c->pfmt_ctx->streams[i]->priv_data);
-/* XXX: should be done in AVStream, not in codec */
-c->pfmt_ctx->streams[i]->codec->frame_number = 0;
 }
 /* set output format parameters */
 c->pfmt_ctx->oformat = c->stream->fmt;
@@ -2387,7 +2385,7 @@ static int http_prepare_data(HTTPContext *c)
 AVStream *st = c->fmt_in->streams[source_index];
 pkt.stream_index = i;
 if (pkt.flags & AV_PKT_FLAG_KEY &&
-(st->codec->codec_type == AVMEDIA_TYPE_VIDEO ||
+(st->codecpar->codec_type == 
AVMEDIA_TYPE_VIDEO ||
  c->stream->nb_streams == 1))
 c->got_key_frame = 1;
 if (!c->stream->send_on_key || c->got_key_frame)
@@ -2395,7 +2393,6 @@ static int http_prepare_data(HTTPContext *c)
 }
 }
 } else {
-AVCodecContext *codec;
 AVStream *ist, *ost;
 send_it:
 ist = c->fmt_in->streams[source_index];
@@ -2416,13 +2413,11 @@ static int http_prepare_data(HTTPContext *c)
 av_packet_unref();
 break;
 }
-codec = ctx->streams[0]->codec;
 /* only one stream per RTP connection */
 pkt.stream_index = 0;
 } else {
 ctx = c->pfmt_ctx;
 /* Fudge here */
-codec = ctx->streams[pkt.stream_index]->codec;
 }
 
 if (c->is_packetized) {
@@ -2464,7 +2459,6 @@ static int http_prepare_data(HTTPContext *c)
 c->buffer_ptr = c->pb_buffer;
 c->buffer_end = c->pb_buffer + len;
 
-codec->frame_number++;
 if (len == 0) {
 av_packet_unref();
 goto redo;
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 2/3] ffserver: Remove use of AVStream as a intermediate to store parameters

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 ffserver.c| 91 +--
 ffserver_config.c |  6 ++--
 ffserver_config.h | 20 +++-
 3 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index 6b8eb2c..1d8abd9 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -235,7 +235,7 @@ static int rtp_new_av_stream(HTTPContext *c,
 /* utils */
 static size_t htmlencode (const char *src, char **dest);
 static inline void cp_html_entity (char *buffer, const char *entity);
-static inline int check_codec_match(AVStream *ccf, AVStream *ccs, int stream);
+static inline int check_codec_match(LayeredAVStream *ccf, AVStream *ccs, int 
stream);
 
 static const char *my_program_name;
 
@@ -254,6 +254,21 @@ static AVLFG random_state;
 
 static FILE *logfile = NULL;
 
+static void unlayer_stream(AVStream *st, LayeredAVStream *lst)
+{
+avcodec_free_context(>codec);
+avcodec_parameters_free(>codecpar);
+#define COPY(a) st->a = lst->a;
+COPY(index)
+COPY(id)
+COPY(codec)
+COPY(codecpar)
+COPY(time_base)
+COPY(pts_wrap_bits)
+COPY(sample_aspect_ratio)
+COPY(recommended_encoder_configuration)
+}
+
 static inline void cp_html_entity (char *buffer, const char *entity) {
 if (!buffer || !entity)
 return;
@@ -1864,7 +1879,7 @@ static inline void print_stream_params(AVIOContext *pb, 
FFServerStream *stream)
 int i, stream_no;
 const char *type = "unknown";
 char parameters[64];
-AVStream *st;
+LayeredAVStream *st;
 AVCodec *codec;
 
 stream_no = stream->nb_streams;
@@ -1984,7 +1999,7 @@ static void compute_status(HTTPContext *c)
 const char *video_codec_name_extra = "";
 
 for(i=0;inb_streams;i++) {
-AVStream *st = stream->streams[i];
+LayeredAVStream *st = stream->streams[i];
 AVCodec *codec = avcodec_find_encoder(st->codecpar->codec_id);
 
 switch(st->codecpar->codec_type) {
@@ -2256,14 +2271,12 @@ static int http_prepare_data(HTTPContext *c)
 return AVERROR(ENOMEM);
 c->pfmt_ctx = ctx;
 av_dict_copy(&(c->pfmt_ctx->metadata), c->stream->metadata, 0);
-c->pfmt_ctx->streams = av_mallocz_array(c->stream->nb_streams,
-  sizeof(AVStream *));
-if (!c->pfmt_ctx->streams)
-return AVERROR(ENOMEM);
 
 for(i=0;istream->nb_streams;i++) {
-AVStream *src;
-c->pfmt_ctx->streams[i] = av_mallocz(sizeof(AVStream));
+LayeredAVStream *src;
+AVStream *st = avformat_new_stream(c->pfmt_ctx, NULL);
+if (!st)
+return AVERROR(ENOMEM);
 
 /* if file or feed, then just take streams from FFServerStream
  * struct */
@@ -2273,14 +2286,14 @@ static int http_prepare_data(HTTPContext *c)
 else
 src = c->stream->feed->streams[c->stream->feed_streams[i]];
 
-*(c->pfmt_ctx->streams[i]) = *src;
-c->pfmt_ctx->streams[i]->priv_data = 0;
+unlayer_stream(c->pfmt_ctx->streams[i], src); //TODO we no longer 
copy st->internal, does this matter?
+av_assert0(!c->pfmt_ctx->streams[i]->priv_data);
 /* XXX: should be done in AVStream, not in codec */
 c->pfmt_ctx->streams[i]->codec->frame_number = 0;
 }
 /* set output format parameters */
 c->pfmt_ctx->oformat = c->stream->fmt;
-c->pfmt_ctx->nb_streams = c->stream->nb_streams;
+av_assert0(c->pfmt_ctx->nb_streams == c->stream->nb_streams);
 
 c->got_key_frame = 0;
 
@@ -2807,7 +2820,7 @@ static int http_receive_data(HTTPContext *c)
 }
 
 for (i = 0; i < s->nb_streams; i++) {
-AVStream *fst = feed->streams[i];
+LayeredAVStream *fst = feed->streams[i];
 AVStream *st = s->streams[i];
 avcodec_copy_context(fst->codec, st->codec);
 }
@@ -3424,19 +3437,16 @@ static int rtp_new_av_stream(HTTPContext *c,
 if (!st)
 goto fail;
 
-av_freep(>codec);
-av_freep(>info);
 st_internal = st->internal;
 
 if (!c->stream->feed ||
 c->stream->feed == c->stream)
-memcpy(st, c->stream->streams[stream_index], sizeof(AVStream));
+unlayer_stream(st, c->stream->streams[stream_index]);
 else
-memcpy(st,
-   c->stream->feed->streams[c->stream->feed_streams[stream_index]],
-   sizeof(AVStream));
-st->priv_data = NULL;
-st->internal = st_internal;
+unlayer_stream(st,
+   
c->stream->feed->streams[c->stream->feed_streams[stream_index]]);
+av_assert0(st->priv_data == NULL);
+av_assert0(st->internal == st_internal);
 
 /* build destination RTP address */
 ipaddr = inet_ntoa(dest_addr->sin_addr);
@@ -3504,15 +3514,15 @@ 

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Sun, Nov 27, 2016 at 04:57:36PM +0100, Clément Bœsch wrote:
> On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
> [...]
> > ffserver had 14 commits to it in about the last month
> 
> That's also pretty close to the number of commits in the last years.
> 
> Good will in the last weeks is not enough of a technical
> merit/justification to prevent the removal of junk code scheduled for
> deletion for a long time now.

why do you call it junk ?
and the sheduling for deletion was conditional on it not being fixed
IIRC.
Why the hurry to remove it while people work on fixing it ?
its not blocking anything ATM AFAIK

and why is this escalating in such a strange way, theres no need to
become aggressive.
Does the project really have too many developers?
If thats the case can you point me to someone to take over coverity
testing ? I cant find one ...

also reynaldo, has done alot for the project, not just through volunteer
work, but also by finding one of the very few sponsors who funded
students working in FFmpeg under the OPW as well as helping with GSoC
and OPW admin work.

For all i know reynaldo is not being paid to work on FFmpeg.
shouldnt you be a little nicer ...

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

[Nicolas George]

A lot of changes happen at the same time:

- Add a framequeue fifo to AVFilterLink.

- split AVFilterLink.status into status_in and status_out: requires
  changes to the few filters and programs that use it directly
  (f_interleave, split, filtfmts).

- Add a field ready to AVFilterContext, marking when the filter is ready
  and its activation priority.

- Add flags to mark blocked links.

- Change ff_filter_frame() to enqueue the frame.

- Change all filtering functions to update the ready field and the
  blocked flags.

- Update ff_filter_graph_run_once() to use the ready field.

- buffersrc: always push the frame immediately.

Signed-off-by: Nicolas George 
---
 libavfilter/avfilter.c | 457 ++---
 libavfilter/avfilter.h |  71 +--
 libavfilter/avfiltergraph.c|  53 ++---
 libavfilter/buffersink.c   |  21 +-
 libavfilter/buffersrc.c|   6 +-
 libavfilter/f_interleave.c |   8 +-
 libavfilter/internal.h |   6 +
 libavfilter/split.c|   5 +-
 libavfilter/tests/filtfmts.c   |   3 +
 libavfilter/vf_extractplanes.c |   6 +-
 10 files changed, 493 insertions(+), 143 deletions(-)


Changed the private fields: directly in avfilter.h with discreet ifdef
(preferred by Clément) with guarding reserved field (must urgent
countermeasure).

I made a few tests and it seems making AVFilterLink completely opaque would
be really not much work, just a few accessor functions for buffersink and
the corresponding change in ffmpeg*.c.

Still, it requires the whole deprecation dance, so it will not happen
immediately. And it conflicts with this patch, si I would like to apply it
before starting on it.

Please have a look at the rest of the code.


diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 662f933..56fb0be 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -34,6 +34,9 @@
 #include "libavutil/rational.h"
 #include "libavutil/samplefmt.h"
 
+#define FF_INTERNAL_FIELDS 1
+#include "framequeue.h"
+
 #include "audio.h"
 #include "avfilter.h"
 #include "formats.h"
@@ -135,6 +138,10 @@ int avfilter_link(AVFilterContext *src, unsigned srcpad,
 {
 AVFilterLink *link;
 
+av_assert0(src->graph);
+av_assert0(dst->graph);
+av_assert0(src->graph == dst->graph);
+
 if (src->nb_outputs <= srcpad || dst->nb_inputs <= dstpad ||
 src->outputs[srcpad]  || dst->inputs[dstpad])
 return AVERROR(EINVAL);
@@ -160,6 +167,7 @@ int avfilter_link(AVFilterContext *src, unsigned srcpad,
 link->type= src->output_pads[srcpad].type;
 av_assert0(AV_PIX_FMT_NONE == -1 && AV_SAMPLE_FMT_NONE == -1);
 link->format  = -1;
+ff_framequeue_init(>fifo, >graph->internal->frame_queues);
 
 return 0;
 }
@@ -170,6 +178,7 @@ void avfilter_link_free(AVFilterLink **link)
 return;
 
 av_frame_free(&(*link)->partial_buf);
+ff_framequeue_free(&(*link)->fifo);
 ff_video_frame_pool_uninit((FFVideoFramePool**)&(*link)->video_frame_pool);
 
 av_freep(link);
@@ -180,16 +189,46 @@ int avfilter_link_get_channels(AVFilterLink *link)
 return link->channels;
 }
 
+static void ff_filter_set_ready(AVFilterContext *filter, unsigned priority)
+{
+filter->ready = FFMAX(filter->ready, priority);
+}
+
+/**
+ * Clear frame_blocked_in on all outputs.
+ * This is necessary whenever something changes on input.
+ */
+static void filter_unblock(AVFilterContext *filter)
+{
+unsigned i;
+
+for (i = 0; i < filter->nb_outputs; i++)
+filter->outputs[i]->frame_blocked_in = 0;
+}
+
+
 void ff_avfilter_link_set_in_status(AVFilterLink *link, int status, int64_t 
pts)
 {
-ff_avfilter_link_set_out_status(link, status, pts);
+if (link->status_in == status)
+return;
+av_assert0(!link->status_in);
+link->status_in = status;
+link->status_in_pts = pts;
+link->frame_wanted_out = 0;
+link->frame_blocked_in = 0;
+filter_unblock(link->dst);
+ff_filter_set_ready(link->dst, 200);
 }
 
 void ff_avfilter_link_set_out_status(AVFilterLink *link, int status, int64_t 
pts)
 {
-link->status = status;
-link->frame_wanted_in = link->frame_wanted_out = 0;
-ff_update_link_current_pts(link, pts);
+av_assert0(!link->frame_wanted_out);
+av_assert0(!link->status_out);
+link->status_out = status;
+if (pts != AV_NOPTS_VALUE)
+ff_update_link_current_pts(link, pts);
+filter_unblock(link->dst);
+ff_filter_set_ready(link->src, 200);
 }
 
 void avfilter_link_set_closed(AVFilterLink *link, int closed)
@@ -370,10 +409,23 @@ int ff_request_frame(AVFilterLink *link)
 {
 FF_TPRINTF_START(NULL, request_frame); ff_tlog_link(NULL, link, 1);
 
-if (link->status)
-return link->status;
-link->frame_wanted_in = 1;
+if (link->status_out)
+return link->status_out;
+if (link->status_in) {
+if (ff_framequeue_queued_frames(>fifo)) {
+

[FFmpeg-devel] [PATCH 1/2] lavfi: add FFFrameQueue API.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavfilter/Makefile |   1 +
 libavfilter/framequeue.c | 123 +
 libavfilter/framequeue.h | 173 +++
 3 files changed, 297 insertions(+)
 create mode 100644 libavfilter/framequeue.c
 create mode 100644 libavfilter/framequeue.h


Unchanged.


diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index cdddb1b..35bf11b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -18,6 +18,7 @@ OBJS = allfilters.o   
  \
fifo.o   \
formats.o\
framepool.o  \
+   framequeue.o \
graphdump.o  \
graphparser.o\
opencl_allkernels.o  \
diff --git a/libavfilter/framequeue.c b/libavfilter/framequeue.c
new file mode 100644
index 000..debeab2
--- /dev/null
+++ b/libavfilter/framequeue.c
@@ -0,0 +1,123 @@
+/*
+ * Generic frame queue
+ * Copyright (c) 2016 Nicolas George
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "framequeue.h"
+
+static inline FFFrameBucket *bucket(FFFrameQueue *fq, size_t idx)
+{
+return >queue[(fq->tail + idx) & (fq->allocated - 1)];
+}
+
+void ff_framequeue_global_init(FFFrameQueueGlobal *fqg)
+{
+}
+
+static void check_consistency(FFFrameQueue *fq)
+{
+#if ASSERT_LEVEL >= 2
+uint64_t nb_samples = 0;
+size_t i;
+
+av_assert0(fq->queued == fq->total_frames_head - fq->total_frames_tail);
+for (i = 0; i < fq->queued; i++)
+nb_samples += bucket(fq, i)->frame->nb_samples;
+av_assert0(nb_samples == fq->total_samples_head - fq->total_samples_tail);
+#endif
+}
+
+void ff_framequeue_init(FFFrameQueue *fq, FFFrameQueueGlobal *fqg)
+{
+fq->queue = >first_bucket;
+fq->allocated = 1;
+}
+
+void ff_framequeue_free(FFFrameQueue *fq)
+{
+while (fq->queued) {
+AVFrame *frame = ff_framequeue_take(fq);
+av_frame_free();
+}
+if (fq->queue != >first_bucket)
+av_freep(>queue);
+}
+
+int ff_framequeue_add(FFFrameQueue *fq, AVFrame *frame)
+{
+FFFrameBucket *b;
+
+check_consistency(fq);
+if (fq->queued == fq->allocated) {
+if (fq->allocated == 1) {
+size_t na = 8;
+FFFrameBucket *nq = av_realloc_array(NULL, na, sizeof(*nq));
+if (!nq)
+return AVERROR(ENOMEM);
+nq[0] = fq->queue[0];
+fq->queue = nq;
+fq->allocated = na;
+} else {
+size_t na = fq->allocated << 1;
+FFFrameBucket *nq = av_realloc_array(fq->queue, na, sizeof(*nq));
+if (!nq)
+return AVERROR(ENOMEM);
+if (fq->tail + fq->queued > fq->allocated)
+memmove(nq + fq->allocated, nq,
+(fq->tail + fq->queued - fq->allocated) * sizeof(*nq));
+fq->queue = nq;
+fq->allocated = na;
+}
+}
+b = bucket(fq, fq->queued);
+b->frame = frame;
+fq->queued++;
+fq->total_frames_head++;
+fq->total_samples_head += frame->nb_samples;
+check_consistency(fq);
+return 0;
+}
+
+AVFrame *ff_framequeue_take(FFFrameQueue *fq)
+{
+FFFrameBucket *b;
+
+check_consistency(fq);
+av_assert1(fq->queued);
+b = bucket(fq, 0);
+fq->queued--;
+fq->tail++;
+fq->tail &= fq->allocated - 1;
+fq->total_frames_tail++;
+fq->total_samples_tail += b->frame->nb_samples;
+check_consistency(fq);
+return b->frame;
+}
+
+AVFrame *ff_framequeue_peek(FFFrameQueue *fq, size_t idx)
+{
+FFFrameBucket *b;
+
+check_consistency(fq);
+av_assert1(idx < fq->queued);
+b = bucket(fq, idx);
+check_consistency(fq);
+return b->frame;
+}
diff --git a/libavfilter/framequeue.h b/libavfilter/framequeue.h
new file mode 100644
index 000..558ea22
--- /dev/null

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Clément Bœsch]

On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
[...]
> ffserver had 14 commits to it in about the last month

That's also pretty close to the number of commits in the last years.

Good will in the last weeks is not enough of a technical
merit/justification to prevent the removal of junk code scheduled for
deletion for a long time now.

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Sun, Nov 27, 2016 at 02:33:54PM +0100, wm4 wrote:
> On Sun, 27 Nov 2016 14:05:44 +0100
> Michael Niedermayer  wrote:
> 
> > On Sat, Nov 26, 2016 at 09:00:41PM +, Rostislav Pehlivanov wrote:
> > > On 26 October 2016 at 23:43, Rostislav Pehlivanov 
> > > wrote:
> > >   
> > > >
> > > >
> > > > On 26 October 2016 at 23:33, Andreas Cadhalpun <  
> > > > andreas.cadhal...@googlemail.com> wrote:  
> > > >  
> > > >> On 27.10.2016 00:16, Rostislav Pehlivanov wrote:  
> > > >> > On 26 October 2016 at 22:48, James Almer  wrote:
> > > >> >  
> > > >> >> On 10/26/2016 6:19 PM, Rostislav Pehlivanov wrote:  
> > > >> >>> Also removes url_feof from libavformat.v which should have been
> > > >> >>> removed long ago and changed the multipart jpeg boundary tag to
> > > >> >>> ffmpeg rather than ffserver (it's arbitrary).  
> > > >> >>
> > > >> >> [...]
> > > >> >>  
> > > >> >>> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
> > > >> >>> index c961cd8..47d5ddc 100644
> > > >> >>> --- a/libavformat/libavformat.v
> > > >> >>> +++ b/libavformat/libavformat.v
> > > >> >>> @@ -1,19 +1,6 @@
> > > >> >>>  LIBAVFORMAT_MAJOR {
> > > >> >>>  global:
> > > >> >>>  av*;
> > > >> >>> -#FIXME those are for ffserver
> > > >> >>> -ff_inet_aton;
> > > >> >>> -ff_socket_nonblock;
> > > >> >>> -ff_rtsp_parse_line;
> > > >> >>> -ff_rtp_get_local_rtp_port;
> > > >> >>> -ff_rtp_get_local_rtcp_port;
> > > >> >>> -ffio_open_dyn_packet_buf;
> > > >> >>> -ffio_set_buf_size;
> > > >> >>> -ffurl_close;
> > > >> >>> -ffurl_open;
> > > >> >>> -ffurl_write;
> > > >> >>> -#those are deprecated, remove on next bump
> > > >> >>> -url_feof;
> > > >> >>>  local:
> > > >> >>>  *;
> > > >> >>>  };  
> > > >> >>
> > > >> >> No, this can't be done until the next major bump. url_feof is even  
> > > >> guarded  
> > > >> >> by an scheduled FF_API define.
> > > >> >>
> > > >> >> The rest should be ok, but anything that implies a library ABI 
> > > >> >> break  
> > > >> can't  
> > > >> >> be done just yet. Wait for other comments and/or testing. This 
> > > >> >> removes  
> > > >> a  
> > > >> >> lot of things after all.
> > > >> >>  
> > > >> > Fixed version attached without removing url_feof (apparently that's  
> > > >> meant  
> > > >> > to go in the next bump, wasn't forgotten)  
> > > >>
> > > >> No, none of the symbols can be removed without a major bump. The simple
> > > >> reason
> > > >> is that a ffserver built from the 3.1 branch still has to work with the
> > > >> libavformat from the 3.2 branch.
> > > >>
> > > >> Best regards,
> > > >> Andreas
> > > >>
> > > >> ___
> > > >> ffmpeg-devel mailing list
> > > >> ffmpeg-devel@ffmpeg.org
> > > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >>  
> > > >
> > > > Thanks for telling me,
> > > > Attached patch will only remove the ffserver program and documentation
> > > > relating to it.
> > > > The ffm demuxer/muxer will be removed with the next bump like url_feof.
> > > >  
> > > 
> > > 
> > > Since a month has passed, reynaldo still hasn't responded, I think it's
> > > long overdue to push this patch. I've attached a new version of the patch
> > > which only removes the ffserver program (without touching anything else),
> > > which had been OK'd by James Almer.  
> > 
> > IIUC reynaldo is very busy.
> > 
> > have you looked at ffserver ? I think helping reynaldo and updating
> > ffserver so it doesnt violate the API would make alot more sense for
> > FFmpeg than removing it. Its a long existing feature and tool.
> 
> Where does this come from? It seems never ever it happened that someone
> wanted to actually update and maintain ffserver. That's why we want to
> remove it. The reason for removal isn't going to change apparently.
> Basically nobody wants to touch it, and those who tried apparently
> failed. It's over.

ffserver had 14 commits to it in about the last month, thats far from
unmaintained, especially considering the maintainer has little time
currently

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[wm4]

On Sun, 27 Nov 2016 14:05:44 +0100
Michael Niedermayer  wrote:

> On Sat, Nov 26, 2016 at 09:00:41PM +, Rostislav Pehlivanov wrote:
> > On 26 October 2016 at 23:43, Rostislav Pehlivanov 
> > wrote:
> >   
> > >
> > >
> > > On 26 October 2016 at 23:33, Andreas Cadhalpun <  
> > > andreas.cadhal...@googlemail.com> wrote:  
> > >  
> > >> On 27.10.2016 00:16, Rostislav Pehlivanov wrote:  
> > >> > On 26 October 2016 at 22:48, James Almer  wrote:
> > >> >  
> > >> >> On 10/26/2016 6:19 PM, Rostislav Pehlivanov wrote:  
> > >> >>> Also removes url_feof from libavformat.v which should have been
> > >> >>> removed long ago and changed the multipart jpeg boundary tag to
> > >> >>> ffmpeg rather than ffserver (it's arbitrary).  
> > >> >>
> > >> >> [...]
> > >> >>  
> > >> >>> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
> > >> >>> index c961cd8..47d5ddc 100644
> > >> >>> --- a/libavformat/libavformat.v
> > >> >>> +++ b/libavformat/libavformat.v
> > >> >>> @@ -1,19 +1,6 @@
> > >> >>>  LIBAVFORMAT_MAJOR {
> > >> >>>  global:
> > >> >>>  av*;
> > >> >>> -#FIXME those are for ffserver
> > >> >>> -ff_inet_aton;
> > >> >>> -ff_socket_nonblock;
> > >> >>> -ff_rtsp_parse_line;
> > >> >>> -ff_rtp_get_local_rtp_port;
> > >> >>> -ff_rtp_get_local_rtcp_port;
> > >> >>> -ffio_open_dyn_packet_buf;
> > >> >>> -ffio_set_buf_size;
> > >> >>> -ffurl_close;
> > >> >>> -ffurl_open;
> > >> >>> -ffurl_write;
> > >> >>> -#those are deprecated, remove on next bump
> > >> >>> -url_feof;
> > >> >>>  local:
> > >> >>>  *;
> > >> >>>  };  
> > >> >>
> > >> >> No, this can't be done until the next major bump. url_feof is even  
> > >> guarded  
> > >> >> by an scheduled FF_API define.
> > >> >>
> > >> >> The rest should be ok, but anything that implies a library ABI break  
> > >> can't  
> > >> >> be done just yet. Wait for other comments and/or testing. This 
> > >> >> removes  
> > >> a  
> > >> >> lot of things after all.
> > >> >>  
> > >> > Fixed version attached without removing url_feof (apparently that's  
> > >> meant  
> > >> > to go in the next bump, wasn't forgotten)  
> > >>
> > >> No, none of the symbols can be removed without a major bump. The simple
> > >> reason
> > >> is that a ffserver built from the 3.1 branch still has to work with the
> > >> libavformat from the 3.2 branch.
> > >>
> > >> Best regards,
> > >> Andreas
> > >>
> > >> ___
> > >> ffmpeg-devel mailing list
> > >> ffmpeg-devel@ffmpeg.org
> > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>  
> > >
> > > Thanks for telling me,
> > > Attached patch will only remove the ffserver program and documentation
> > > relating to it.
> > > The ffm demuxer/muxer will be removed with the next bump like url_feof.
> > >  
> > 
> > 
> > Since a month has passed, reynaldo still hasn't responded, I think it's
> > long overdue to push this patch. I've attached a new version of the patch
> > which only removes the ffserver program (without touching anything else),
> > which had been OK'd by James Almer.  
> 
> IIUC reynaldo is very busy.
> 
> have you looked at ffserver ? I think helping reynaldo and updating
> ffserver so it doesnt violate the API would make alot more sense for
> FFmpeg than removing it. Its a long existing feature and tool.

Where does this come from? It seems never ever it happened that someone
wanted to actually update and maintain ffserver. That's why we want to
remove it. The reason for removal isn't going to change apparently.
Basically nobody wants to touch it, and those who tried apparently
failed. It's over.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] ffserver: Remove extract_mpeg4_header()

[wm4]

On Wed, 23 Nov 2016 14:39:06 -0500
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Wed, Nov 23, 2016 at 2:13 PM, Michael Niedermayer  > wrote:  
> 
> > This should not be needed, our AVParsers should do this
> > I do not have a testcase though, please help testing this and please
> > add fate tests if you can.  
> 
> 
> I thought we were going to remove ffserver?
> 
> Do I need to call for an official vote? What does it take for ffserver to
> finally go away?

You can't. FFmpeg's organization can't act effectively.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] Revert "ffserver: use AVStream.codecpar in open_input_stream()"

[Michael Niedermayer]

On Wed, Nov 23, 2016 at 08:13:04PM +0100, Michael Niedermayer wrote:
> Fixes null pointer dereference
> 
> Testcase is simply a ffmpeg instance sending a stream to ffserver while 
> another ffmpeg reads from it
> 
> This reverts commit 6f0a1710d77dde0d803861506a2157a23f08c14c.
> ---
>  ffserver.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

patchset applied

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Sat, Nov 26, 2016 at 09:00:41PM +, Rostislav Pehlivanov wrote:
> On 26 October 2016 at 23:43, Rostislav Pehlivanov 
> wrote:
> 
> >
> >
> > On 26 October 2016 at 23:33, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >> On 27.10.2016 00:16, Rostislav Pehlivanov wrote:
> >> > On 26 October 2016 at 22:48, James Almer  wrote:
> >> >
> >> >> On 10/26/2016 6:19 PM, Rostislav Pehlivanov wrote:
> >> >>> Also removes url_feof from libavformat.v which should have been
> >> >>> removed long ago and changed the multipart jpeg boundary tag to
> >> >>> ffmpeg rather than ffserver (it's arbitrary).
> >> >>
> >> >> [...]
> >> >>
> >> >>> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
> >> >>> index c961cd8..47d5ddc 100644
> >> >>> --- a/libavformat/libavformat.v
> >> >>> +++ b/libavformat/libavformat.v
> >> >>> @@ -1,19 +1,6 @@
> >> >>>  LIBAVFORMAT_MAJOR {
> >> >>>  global:
> >> >>>  av*;
> >> >>> -#FIXME those are for ffserver
> >> >>> -ff_inet_aton;
> >> >>> -ff_socket_nonblock;
> >> >>> -ff_rtsp_parse_line;
> >> >>> -ff_rtp_get_local_rtp_port;
> >> >>> -ff_rtp_get_local_rtcp_port;
> >> >>> -ffio_open_dyn_packet_buf;
> >> >>> -ffio_set_buf_size;
> >> >>> -ffurl_close;
> >> >>> -ffurl_open;
> >> >>> -ffurl_write;
> >> >>> -#those are deprecated, remove on next bump
> >> >>> -url_feof;
> >> >>>  local:
> >> >>>  *;
> >> >>>  };
> >> >>
> >> >> No, this can't be done until the next major bump. url_feof is even
> >> guarded
> >> >> by an scheduled FF_API define.
> >> >>
> >> >> The rest should be ok, but anything that implies a library ABI break
> >> can't
> >> >> be done just yet. Wait for other comments and/or testing. This removes
> >> a
> >> >> lot of things after all.
> >> >>
> >> > Fixed version attached without removing url_feof (apparently that's
> >> meant
> >> > to go in the next bump, wasn't forgotten)
> >>
> >> No, none of the symbols can be removed without a major bump. The simple
> >> reason
> >> is that a ffserver built from the 3.1 branch still has to work with the
> >> libavformat from the 3.2 branch.
> >>
> >> Best regards,
> >> Andreas
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> > Thanks for telling me,
> > Attached patch will only remove the ffserver program and documentation
> > relating to it.
> > The ffm demuxer/muxer will be removed with the next bump like url_feof.
> >
> 
> 
> Since a month has passed, reynaldo still hasn't responded, I think it's
> long overdue to push this patch. I've attached a new version of the patch
> which only removes the ffserver program (without touching anything else),
> which had been OK'd by James Almer.

IIUC reynaldo is very busy.

have you looked at ffserver ? I think helping reynaldo and updating
ffserver so it doesnt violate the API would make alot more sense for
FFmpeg than removing it. Its a long existing feature and tool.
And i dont think its really that hard to update it, iam not the
author of it iam not an expert on that code so i might be wrong or
miss things but the big mess in it seems just moving parameters around
between demuxers and muxers. and a few uses of network and rtp
functions which should be used through some public API or made
available through a new one everyone likes ...

Dont you think its better if some people work together for a few days
to update ffserver and have a cool feature more in FFmpeg, a cleaned
up ffserver with some more modernized features. And the people liking
ffserver be happy and thankfull
vs.
Discussions and eventually a vote about removing ffserver and then
whatever the outcome some people "loosing" and being unhappy

I know i should update ffserver myself if i care so much, but my
todo is getting longer and longer (from new coverity issues that need
checking to all the little things here and there like updating the git
sync script earlier today so it deletes a mistakly added branch and
doesnt spread it to one of our git mirrors at least ...)

Above said, this mail is not intended to block or veto anyones patch

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH] configure: check for stdatomic.h

[Michael Niedermayer]

On Wed, Nov 23, 2016 at 09:54:53PM -0800, Wan-Teh Chang wrote:
> From: Anton Khirnov 
> 
> Since this is a C11 feature, it requires -std=c11.
> 
> Not actually used for anything yet, that will be added in the following
> commits.
> 
> This merges libav commit 13f5d2bf75b95a0bfdb9940a5e359a719e242bed.
> 
> Signed-off-by: Wan-Teh Chang 
> ---
>  configure | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)

applied

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH] WIP: subtitles in AVFrame

[Nicolas George]

Le decadi 30 brumaire, an CCXXV, Clement Boesch a écrit :
> Right, I'll probably need that for the sub2video filter. I'll think about
> it unless you want to implement it yourself.

As always, for me, time is the limiting factor. For now, I believe the
only urgent thing to do is to decide what these heartbeat frames look
like: do they just have data[0] = NULL? format = -1?

> Ah, yeah, I discarded that idea. First, I think it's a too large change
> for now, and I just won't be able to finish this patchset ever if I start
> going that way. Second, apparently it's considered over engineering by the
> API users I talked with. They're fine using libass for markup or a simple
> freetype-like custom engine for when there is no markup.
> 
> If we later decide to export as an AST, we will add a field to that
> rectangle and that will do the trick. For now, this is already such as
> huge work that I'm not willing to stick that in (and probably won't ever
> TBH). It's already raising a ton of questions wrt design.

Ok.

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] lavfi/avfiltergraph: always reduce all_layouts to a single layout

[Nicolas George]

Le tridi 3 frimaire, an CCXXV, Marton Balint a écrit :
> I thought we are trying to move away from workarounds introduced only to be
> able to be compatible with libav API. So this is clearly libav dirving
> ffmpeg development, which is not fortunate IMHO.
> 
> I also think that the chance of an exploitable filter because of this is
> small. An audio filter with no query_formats is quite rare in itself. Even
> if such a filter got merged, making it work with unknown channel layouts is
> a feature which we would want anyway, becase ffmpeg does support unknown
> channel layouts.
> 
> Yes, it is not me who does the merges, but IMHO this does not add too much
> burden for the people who does it. Hendrik, Clement, what do you think?
> 
> And even if such an issue got in the codebase, isn't this something that
> coverity should be able to easily detect most of the times?

In principle, I think we would want to get rid of the work-ardounds and
have all filters support unknown layouts. But we also want our users to
have a working and reliable tool. Meeting both objectives requires
auditing and testing.

If we make unknown layouts the default and a filter that does not work
with them sneaks through, it will sometimes use 0 as the number of
channels. Depending on how much it does so, it can have several
unfortunate consequences, most probably either a generic error message
(probably "invalid argument" or "out of memory"), a corrupted output or
a crash (and unless proven otherwise, a crash must be assumed to be
exploitable).

Automated testing can not help us catching them. Neither FATE nor
coverity, the way they currently work.

On the other hand, detecting filters that do not work correctly is not
very hard in itself. The use of av_get_channel_layout_nb_channels() is a
very reliable condition. But it could be hidden in a call to an external
function. Making them work is usually rather easy too: replace
av_get_channel_layout_nb_channels() with the corresponding "channels"
field.

Here is, to the best of my knowledge, the current state of affairs. With
that information, we can decide to make unknown layouts the default. But
that is not my decision alone.

If it happens, I will try to help paying attention to new filters, but I
can not promise I will succeed catching them all.

Also, if we decide to proceed, I think we should not just make
all_counts the default: the all_counts / all_layouts logic is rather
complex, and with all_counts the default it becomes essentially dead
code. But the decision comes first.

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] [RFC]MAINTAINERS: Add developers who have git write access but are otherwise not listed

[Nicolas George]

Le sextidi 6 frimaire, an CCXXV, compn a écrit :
> if one wants to be worried about security issues, there are bigger fish
> to fry.

Hardly ever a valid argument.

> for one example, how about any and all patches applied to ffmpeg by
> various distros ?

> because this is a real threat to our users' security.

No, they are not our users, and therefore not our responsibility.

> has any developer come back from the proverbial "dead" , like say
> fabrice, to make a new commit? no.

Therefore, revoking the key is no problem.


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