Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

[compn]

On Fri, 20 May 2016 01:55:15 +0200
Lukasz Marek  wrote:

> On 19 May 2016 at 15:18, Derek Buitenhuis 
> wrote:
> 
> > On 5/19/2016 2:12 PM, Michael Niedermayer wrote:
> > > if derek still wants to leave in 2 weeks then so be it, its his
> > > choice but i really hope things can be resolved in a way that
> > > everyone stays and works together and is happy
> >
> > I will wait 2 weeks.
> >
> 
> Is Derek revoked to commit or what? Couldn't he just commit this
> patch and leave? :P  I was a problem for some people, but I see they

derek and all other devs still have commit access. no one has been
banned, removed, sanctioned or anything. derek said he
unsubscribed from the mailing lists, himself.

nothing stopping him from committing this himself.

i would hope developers could work, if not together, at least
tolerate each other. i understand some devels have had disagreements
for years now.

i'd hate to see anyone leave, but i also am not a fan of arguments in
every thread either. i ignore comments most times and stick to
the code.

imo i wouldnt call any discussions in the past years "toxic". a few
gripes, snarks or passive agressive comments from a few developers,
sure. 

show me one software project that doesnt have conflicts between
developers.


if any of my mail has offended anyone, please read it with the most
gracious and open tone, i am not trying to be insulting.

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

Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to openh264 1.6

[Ricardo Constantino]

On 2 April 2016 at 11:29, Stefano Sabatini  wrote:
> On date Monday 2016-03-07 18:05:30 +0100, Stefano Sabatini encoded:
>> In particular, the slice mode API was changed in commit:
>>
>> commit 33c378f7b791310e4cb64b53e2bb8f3f3bded105
>> Author: sijchen 
>> Date:   Tue Nov 10 09:50:06 2015 -0800
>>
>> change API for slicing part for easier usage (the UseLoadBalancing flag 
>> is still under working)
>>
>> This fixes compilation with latest version of openh264.
>> ---
>>  configure   |  2 +-
>>  doc/encoders.texi   | 25 ++-
>>  libavcodec/libopenh264enc.c | 48 
>> ++---
>>  libavcodec/version.h|  2 +-
>>  4 files changed, 42 insertions(+), 35 deletions(-)
>
> Ping.

Confirm this fixes compilation with openh264 git master.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Vote] Code of Conduct

[Michael Niedermayer]

On Wed, May 18, 2016 at 08:40:07PM +0200, Michael Niedermayer wrote:
> This is the version i had in my pending branch and should be the last 
> version of the Code of Conduct from march, IIRC there where no further 
> comments on the last version, so iam calling everyone to vote on this.
> Everyone because it should be binding to everyone.
> 
> Kieran and Thilo asked for a formal vote and i agree that this needs
> a vote.
> 
> I wanted to send this earlier, but was always busy with other things
> 
> Please state clearly if you agree to the text or if not.
> we can extend and tune it later and do another vote if there are more
>  suggestions

for completeness and as timothy asked
the vote will end 1 week after its start and a majority that is more
yes than no votes will be consiered as adopting the CoC

of course the vote committee can override or this
iam just stating something so we arent stuck

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Timothy Gu]

Hi,

On Mon, Mar 28, 2016 at 03:39:22PM +0200, Michael Niedermayer wrote:
> On Mon, Mar 28, 2016 at 12:34:05PM +, Kieran Kunhya wrote:
> > On Mon, 28 Mar 2016 at 11:58 Moritz Barsnick  wrote:
> > 
> > > On Mon, Mar 28, 2016 at 02:18:32 +0200, Michael Niedermayer wrote:
> > > > +it is malice its rarely good to start with that as initial assumption.
> > >^
> > >, it's
> > >
> > > > +The goal of Software development is to create technical excellence, not
> > > for any
> > >^ s
> > >
> > >
> > Let's compare this to the VLC code of conduct:
> > https://wiki.videolan.org/Code_of_Conduct/
> > 
> > Note how it has a list of specific violations, instead of vague things like
> > "Be excellent" that the FFmpeg one has.
> > Note how it has a huge section on disciplinary procedures.
> 
> i dont mind at all to be more specific, do people want a more specific
> list similar to vlc ?
> I thought it wasnt neccessary to write it as a strict "law" as if
> theres a nation of criminals that needs precissely worded laws.
> But rather a nation of good meaning people who all want to work
> together.

I have to agree with Kieran here. I believe that as a community, we definitely
_want_ to assume good faith, etc. But conflict resolution requires strict,
codified consequences for violations of the CoC, to ensure fairness. The
language needs to be made more serious so that people actually take it in the
way it is intended.

In addition to VLC, many other popular open-source guidelines, such as:

- Citizen Code of Conduct: http://citizencodeofconduct.org/
- Contributor Covenant: http://contributor-covenant.org/version/1/4/
- Node.js: https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md
- Ruby: https://www.ruby-lang.org/en/conduct/
- etc.

all have consequences of unwelcomed behavior and/or a specific definition of
an unwelcomed behavior.

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

Re: [FFmpeg-devel] [Vote] Code of Conduct

[Timothy Gu]

On Wed, May 18, 2016 at 08:40:07PM +0200, Michael Niedermayer wrote:
> This is the version i had in my pending branch and should be the last 
> version of the Code of Conduct from march, IIRC there where no further 
> comments on the last version, so iam calling everyone to vote on this.
> Everyone because it should be binding to everyone.
> 
> Kieran and Thilo asked for a formal vote and i agree that this needs
> a vote.

What are we looking for? A unanimous vote? ⅔ majority? ½? A vote can't be
formal if such basic mechanism is not defined.

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

Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

[Lukasz Marek]

On 19 May 2016 at 15:18, Derek Buitenhuis 
wrote:

> On 5/19/2016 2:12 PM, Michael Niedermayer wrote:
> > if derek still wants to leave in 2 weeks then so be it, its his choice
> > but i really hope things can be resolved in a way that everyone
> > stays and works together and is happy
>
> I will wait 2 weeks.
>

Is Derek revoked to commit or what? Couldn't he just commit this patch and
leave? :P  I was a problem for some people, but I see they still have
problems. Let people with problems go away with they problems.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Tee improvement - discussion

[Marton Balint]

On Thu, 19 May 2016, Nicolas George wrote:


Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :

My current idea is to create queue for each output (as Marton suggested) and
process each output in separate thread. I was also considering using just
single queue, but since the AVPackets are referenced counted, the memory
overhead is negligible and using multiple queues will simplify the code.
Apart from getting advantage of non-blocking processing with multiple slave
muxers, error handling will also be improved.



Another question is what to do when some of the queues becomes full,
discussed options were so far:
- Block write_packet call until the queue frees - this might be useful
when producer is faster than consumer, and we don't want to drop any packets
when recording to file.
- Drop some yet unprocessed packets (until next keyframe, or free some
portion of queue) to free the queue - this might be useful for network
outputs.


I must say, I am not very happy with the direction this project takes.

Non-blocking muxers (and demuxers, and protocols) is a white whale for our
API: we really really want it, but it huge and very hard to catch.

It is something that needs to be implemented globally with a very careful
design. Definitely not something that can be added in a corner of an obscure
muxer. We already went down that path twice, with the thread for the UDP
protocol and with running demuxer in threads in FFmpeg. Both did lead to
endless complications: bugs, inconsistencies, portability trouble.


What caused these complications? Do you have some references?



If you want to work on that (in order to bring these enhancements to the tee
muxer, fitting the topic of the GSoC project), you probably can. But I
expect this to be very hard. It has been rejected as a proposal for a GSoC
project in the past on the basis that it is probably too hard for a random
student. Also, I am not sure that Marton, your official mentor, would want
such a huge shift in the project's goals.


The only way this can work if someone steps up and helps both designing 
the generic API and co-mentoring Jan.


If that not happens, I would like to stick to the original plan. We can 
only hope that we will learn something valuable which can be used 
later when somebody takes the time and effort to actually redesign the 
API.


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

Re: [FFmpeg-devel] [PATCH] web: remove myself from consulting

[Lou Logan]

On Thu, 19 May 2016 08:37:23 +0200, Clément Bœsch wrote:

> I get too much mails, on a mailbox I forget to check, about issues I'm
> most of the time not willing to address. And I feel bad about not
> answering anymore lately.
> ---
>  src/consulting | 39 ---
>  1 file changed, 12 insertions(+), 27 deletions(-)

Pushed, although the message won't appear in ffmpeg-cvslog ML because it
ended up in the queue and I accidentally purged it.

It was in the queue because I temporarily disabled messages from
ffmpeg-cvslog@ffmpeg due to spam. I'll re-enable it, but the occasional
spam may appear.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Push hls_ts_options to every chunks (fix #5525)

[ffmpeg]

Owh, sorry, just wanted to share a fix to my issue.

On 15/05/2016 15:50, Hendrik Leppkes wrote:
> On Sun, May 15, 2016 at 2:10 PM,   wrote:
>> resend_headers seems to be only related to PAT/PMT stuff
>> Calling avformat_write_header multiple times do not seems that creepy to
>> me, because we are handling multiples ts chunks (so, basically, multiple
>> headers must be written)
>>
>> Pushing the 'system_b' options to every mpegts chunks through
>> resend_header means that system_b implies PAT/PMT for every chunks (the
>> current 'resend_headers' behavior), with is not a good solution
>>
> 
> calling avformat_write_headers on every chunk without actually
> creating a new muxer seems like an ugly kludge and not a fix (and
> likely to blow up at some point).
> 
> Please don't top post on this ML:
> 
> - Hendrik
> ___
> 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 3/4] lavf/concat: switch to new BSF API.

[Michael Niedermayer]

On Thu, May 19, 2016 at 10:54:39PM +0200, Nicolas George wrote:
> Le primidi 1er prairial, an CCXXIV, Michael Niedermayer a écrit :
> > is the overhead from the null filter insiginicant ?
> 
> I have not actually made a benchmark, but I believe it is. Look in
> libavcodec/bsf.c: the overhead is limited to a few checks and a
> av_packet_move_ref().

can you do a quick time ffmpeg ... with -codec copy just to double
check ? theres no major effect


[...]


-- 
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 3/4] lavf/concat: switch to new BSF API.

[Nicolas George]

Le primidi 1er prairial, an CCXXIV, Michael Niedermayer a écrit :
> is the overhead from the null filter insiginicant ?

I have not actually made a benchmark, but I believe it is. Look in
libavcodec/bsf.c: the overhead is limited to a few checks and a
av_packet_move_ref().

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] lavf/mpegtsenc: add special case for handling timed ID3 packets

[Michael Niedermayer]

On Thu, May 19, 2016 at 06:45:41PM +0200, Stefano Sabatini wrote:
> Set the stream_id to 0xbd (private_stream_id_1). Tools seem to assume
> that value, and this is consistent with MPEG TS (ITU-T H.222.0) section
> 2.12.3.
> ---
>  libavformat/mpegtsenc.c | 3 +++
>  1 file changed, 3 insertions(+)

should be ok

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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: cleanup unused checks for symver

[Michael Niedermayer]

On Thu, May 19, 2016 at 04:55:29PM +0200, Natanael Copa wrote:
> Nothing uses symvers since commit d63443b9 (lavc: drop the
> av_fast_{re,m}alloc compatibility wrappers).
> 
> Signed-off-by: Natanael Copa 
> ---
>  configure | 21 -
>  1 file changed, 21 deletions(-)

this causes pages of warnings:

CC  libavfilter/f_reverse.o
CC  libavfilter/f_select.o
CC  libavfilter/f_sendcmd.o
CC  libavfilter/f_streamselect.o
CC  libavfilter/fifo.o
In file included from ./libavutil/common.h:467:0,
 from ./libavutil/avutil.h:288,
 from ./libavutil/opt.h:31,
 from libavfilter/f_reverse.c:21:
./libavutil/internal.h:196:5: warning: "HAVE_SYMVER_ASM_LABEL" is not defined 
[-Wundef]
./libavutil/internal.h:200:7: warning: "HAVE_SYMVER_GNU_ASM" is not defined 
[-Wundef]
In file included from ./libavutil/common.h:467:0,
 from ./libavutil/avutil.h:288,
 from ./libavutil/eval.h:29,
 from libavfilter/f_select.c:27:
./libavutil/internal.h:196:5: warning: "HAVE_SYMVER_ASM_LABEL" is not defined 
[-Wundef]
./libavutil/internal.h:200:7: warning: "HAVE_SYMVER_GNU_ASM" is not defined 
[-Wundef]
In file included from ./libavutil/common.h:467:0,
 from ./libavutil/avutil.h:288,
 from ./libavutil/file.h:24,
 from libavfilter/f_sendcmd.c:28:


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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] avcodec/adpcm: pick correct step_index for IMA AMV

[Michael Niedermayer]

On Thu, May 19, 2016 at 04:43:08PM +0200, Paul B Mahol wrote:
> Hi,
> 
> patch attached.

>  adpcm.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 21c3c45dec713439666197c9a6d6a01dc8da6aab  
> 0001-avcodec-adpcm-pick-correct-step_index-for-IMA-AMV.patch
> From 78dc1f23509f59e64adbc0a4ecf2e6b77581e375 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Thu, 19 May 2016 16:40:07 +0200
> Subject: [PATCH] avcodec/adpcm: pick correct step_index for IMA AMV
> 
> Fixes #5538
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/adpcm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 4/4] fate: remove "-v 0" from ffprobe tests.

[Michael Niedermayer]

On Thu, May 19, 2016 at 09:47:12AM +0200, Nicolas George wrote:
> The FATE scripts separate stdout from stderr.
> Having a first idea about what went wrong in the log file
> is more convenient.
> 
> Signed-off-by: Nicolas George 
> ---
>  tests/fate-run.sh | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

still looks good

[...]
-- 
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] lavf: add textdata virtual demuxer and demuxer

[Moritz Barsnick]

On Thu, May 19, 2016 at 18:45:22 +0200, Stefano Sabatini wrote:

> [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

demuxer and *muxer* !?

> +Store a data stream to an output file:
> +@example
> +ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd

Would this mean it could also dump timed_id3 to fftd, or would that not
work because timed_id3 cannot be demuxed yet? (I will just try, I don't
have the time right now though.)

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

Re: [FFmpeg-devel] [PATCH] lavf/mpegts: add 0x15 (metadata) entry to the ISO_types array

[Stefano Sabatini]

On date Thursday 2016-04-07 23:02:30 +0200, Michael Niedermayer encoded:
> On Thu, Apr 07, 2016 at 08:43:40PM +0200, Stefano Sabatini wrote:
> > On date Saturday 2016-04-02 15:56:55 +0200, Michael Niedermayer encoded:
> > > On Sat, Apr 02, 2016 at 12:46:57PM +0200, Stefano Sabatini wrote:
> > > > This allows to recognize ID3 packets from the stream type.
> > > > ---
> > > >  libavformat/mpegts.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > 
> > > breaks tickets/2579/old_klv_data_stream.mpg
> > > 
> > > "breaks" in the sense of detecting the klv stuff as id3
> > 
> > Previous patch was indeed broken. New patch attached.
> > -- 
> > FFmpeg = Fiendish & Faithful Magical Problematic Educated Gymnast
> 
> >  mpegts.c |1 +
> >  1 file changed, 1 insertion(+)
> > f0cbe8e9df6ab2e3fb3306a2049f2b31d94aa664  
> > 0003-lavf-mpegts-add-ID3-entry-to-the-REGD_types-array.patch
> > From a756486700d520d7c1e50128c731a59177cc3545 Mon Sep 17 00:00:00 2001
> > From: Stefano Sabatini 
> > Date: Thu, 7 Apr 2016 20:40:52 +0200
> > Subject: [PATCH] lavf/mpegts: add ID3 entry to the REGD_types array
> > 
> > This allows to recognize ID3 packets from their corresponding descriptor
> > tag.
> > ---
> >  libavformat/mpegts.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > index e44da1f..1258913 100644
> > --- a/libavformat/mpegts.c
> > +++ b/libavformat/mpegts.c
> > @@ -739,6 +739,7 @@ static const StreamType REGD_types[] = {
> >  { MKTAG('D', 'T', 'S', '3'), AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_DTS   },
> >  { MKTAG('H', 'E', 'V', 'C'), AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC  },
> >  { MKTAG('K', 'L', 'V', 'A'), AVMEDIA_TYPE_DATA,  AV_CODEC_ID_SMPTE_KLV 
> > },
> > +{ MKTAG('I', 'D', '3', ' '), AVMEDIA_TYPE_DATA,  AV_CODEC_ID_TIMED_ID3 
> > },
> >  { MKTAG('V', 'C', '-', '1'), AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_VC1   },
> >  { MKTAG('O', 'p', 'u', 's'), AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_OPUS  },
> >  { 0 },
> 
> ok

Applied, thanks.
-- 
FFmpeg = Fancy and Fundamental MultiPurpose Extended Glue
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mpegtsenc: move putstr8 definition up

[Stefano Sabatini]

This allows to use the function in a future commit.
---
 libavformat/mpegtsenc.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 93cbac1..5f22032 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -253,6 +253,23 @@ static void mpegts_write_pat(AVFormatContext *s)
   data, q - data);
 }
 
+/* NOTE: !str is accepted for an empty string */
+static void putstr8(uint8_t **q_ptr, const char *str)
+{
+uint8_t *q;
+int len;
+
+q = *q_ptr;
+if (!str)
+len = 0;
+else
+len = strlen(str);
+*q++ = len;
+memcpy(q, str, len);
+q += len;
+*q_ptr = q;
+}
+
 static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service)
 {
 MpegTSWrite *ts = s->priv_data;
@@ -635,23 +652,6 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 return 0;
 }
 
-/* NOTE: !str is accepted for an empty string */
-static void putstr8(uint8_t **q_ptr, const char *str)
-{
-uint8_t *q;
-int len;
-
-q = *q_ptr;
-if (!str)
-len = 0;
-else
-len = strlen(str);
-*q++ = len;
-memcpy(q, str, len);
-q += len;
-*q_ptr = q;
-}
-
 static void mpegts_write_sdt(AVFormatContext *s)
 {
 MpegTSWrite *ts = s->priv_data;
-- 
1.9.1

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

[FFmpeg-devel] [PATCH] lavf/mpegtsenc: write metadata descriptor for timed ID3 packets

[Stefano Sabatini]

This is required since some softwares are not able to correctly recognize
the metadata.
---
 libavformat/mpegtsenc.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 5f22032..4b9e71b 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -254,7 +254,7 @@ static void mpegts_write_pat(AVFormatContext *s)
 }
 
 /* NOTE: !str is accepted for an empty string */
-static void putstr8(uint8_t **q_ptr, const char *str)
+static void putstr8(uint8_t **q_ptr, const char *str, int write_len)
 {
 uint8_t *q;
 int len;
@@ -264,7 +264,8 @@ static void putstr8(uint8_t **q_ptr, const char *str)
 len = 0;
 else
 len = strlen(str);
-*q++ = len;
+if (write_len)
+*q++ = len;
 memcpy(q, str, len);
 q += len;
 *q_ptr = q;
@@ -626,12 +627,15 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 *q++ = 'V';
 *q++ = 'A';
 } else if (st->codecpar->codec_id == AV_CODEC_ID_TIMED_ID3) {
-*q++ = 0x5; /* MPEG-2 registration descriptor */
-*q++ = 4;
-*q++ = 'I';
-*q++ = 'D';
-*q++ = '3';
-*q++ = ' ';
+const char *tag = "ID3 ";
+*q++ = 0x26; /* metadata descriptor */
+*q++ = 13;
+put16(, 0x);/* metadata application format */
+putstr8(, tag, 0);
+*q++ = 0xff;/* metadata format */
+putstr8(, tag, 0);
+*q++ = 0;/* ID */
+*q++ = 0xF;
 }
 break;
 }
@@ -676,8 +680,8 @@ static void mpegts_write_sdt(AVFormatContext *s)
 desc_len_ptr = q;
 q++;
 *q++ = ts->service_type;
-putstr8(, service->provider_name);
-putstr8(, service->name);
+putstr8(, service->provider_name, 1);
+putstr8(, service->name, 1);
 desc_len_ptr[0] = q - desc_len_ptr - 1;
 
 /* fill descriptor length */
-- 
1.9.1

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

[FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

This format is useful to inject custom user data into streams.
---
 doc/demuxers.texi   |  40 +
 doc/muxers.texi |  31 +++
 libavformat/Makefile|   2 +
 libavformat/allformats.c|   1 +
 libavformat/fftextdatadec.c | 212 
 libavformat/fftextdataenc.c | 103 +
 6 files changed, 389 insertions(+)
 create mode 100644 libavformat/fftextdatadec.c
 create mode 100644 libavformat/fftextdataenc.c

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e34f8b3..9fc58eb 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -254,6 +254,46 @@ This demuxer is used to demux FLV files and RTMP network 
streams.
 Allocate the streams according to the onMetaData array content.
 @end table
 
+@anchor{fftextdata}
+@section fftextdata, fftd
+
+FFmpeg text data demuxer.
+
+This special demuxer allows to read serialized data base64-encoded and
+remux it. It is especially useful for injecting opaque data streams.
+
+The fftextdata bytestream consists of a sequence of packets. Each
+packet starts with a timestamps expressed in a format recognized by
+FFmpeg (see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils})
+followed by a sequence of spaces and the base64 encoded data for the
+packet, terminated by ";". The data representation may contain
+interleaved space characters (a space, a tab, or a newline) which are
+ignored.
+
+At the moment a single stream can be represented by an fftextdata
+bytestream.
+
+If an input filename is "fftextdata" or "fftd" then the file format is
+recognized as fftextdata.
+
+@subsection Options
+@table @option
+@item codec_name
+Set the codec name for the packets data.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Inject timed_id3 packed data stored into the data.fftd file into the
+output file.
+@example
+ffmpeg -i input.mp4 -codec_name timed_id3 -f fftextdata -i data.fftd -y -map 0 
-map 1 -c copy output.ts
+@end example
+@end itemize
+
 @section libgme
 
 The Game Music Emu library is a collection of video game music file emulators.
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c62d4b5..df5ec08 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -129,6 +129,37 @@ and the input video converted to MPEG-2 video, use the 
command:
 ffmpeg -i INPUT -c:a pcm_u8 -c:v mpeg2video -f crc -
 @end example
 
+@section fftextdata, fftd
+
+FFmpeg text data muxer.
+
+The fftextdata bytestream consists of a sequence of packets. Each
+packet starts with a timestamps expressed in a format recognized by
+FFmpeg (see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils})
+followed by a sequence of spaces and the base64 encoded data for the
+packet, terminated by ";". The data representation may contain
+interleaved space characters (a space, a tab, or a newline) which are
+ignored.
+
+At the moment only a single stream can be represented by an fftextdata
+bytestream.
+
+This muxer can be used to reinject the stream (e.g. a data stream) in
+a different output, or to provide serialized data of the encoded data.
+
+The output can then be read using the fftextdata demuxer.
+
+@subsection Examples
+
+@itemize
+@item
+Store a data stream to an output file:
+@example
+ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd
+@end example
+@end itemize
+
 @anchor{framecrc}
 @section framecrc
 
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 742aff5..4effccd 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -162,6 +162,8 @@ OBJS-$(CONFIG_FFM_DEMUXER)   += ffmdec.o
 OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
 OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
 OBJS-$(CONFIG_FFMETADATA_MUXER)  += ffmetaenc.o
+OBJS-$(CONFIG_FFTEXTDATA_DEMUXER)+= fftextdatadec.o
+OBJS-$(CONFIG_FFTEXTDATA_MUXER)  += fftextdataenc.o
 OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
 OBJS-$(CONFIG_FILMSTRIP_MUXER)   += filmstripenc.o
 OBJS-$(CONFIG_FLAC_DEMUXER)  += flacdec.o rawdec.o \
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e6ee8d6..7657f94 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -124,6 +124,7 @@ void av_register_all(void)
 REGISTER_MUXER   (F4V,  f4v);
 REGISTER_MUXDEMUX(FFM,  ffm);
 REGISTER_MUXDEMUX(FFMETADATA,   ffmetadata);
+REGISTER_MUXDEMUX(FFTEXTDATA,   fftextdata);
 REGISTER_MUXDEMUX(FILMSTRIP,filmstrip);
 REGISTER_MUXDEMUX(FLAC, flac);
 REGISTER_DEMUXER (FLIC, flic);
diff --git a/libavformat/fftextdatadec.c b/libavformat/fftextdatadec.c
new file mode 100644
index 000..9516559
--- /dev/null
+++ b/libavformat/fftextdatadec.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2016 Stefano Sabatini
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you 

Re: [FFmpeg-devel] [PATCH] lavf/mpegtsenc: set metadata stream type and write descriptor for ID3 packets

[Stefano Sabatini]

On date Saturday 2016-04-02 20:29:42 +0200, Michael Niedermayer encoded:
> On Sat, Apr 02, 2016 at 12:46:50PM +0200, Stefano Sabatini wrote:
> > This allow to remux data packets which are then recognized as ID3 packets.
> > ---
> >  libavformat/mpegts.h|  1 +
> >  libavformat/mpegtsenc.c | 10 ++
> >  2 files changed, 11 insertions(+)
> 
> this is probably ok but please wait a bit before applying so others
> can comment too

Applied.
-- 
FFmpeg = Formidable and Faithless Mega Pitiful Elitist Genius
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: cleanup unused checks for symver

[Natanael Copa]

Nothing uses symvers since commit d63443b9 (lavc: drop the
av_fast_{re,m}alloc compatibility wrappers).

Signed-off-by: Natanael Copa 
---
 configure | 21 -
 1 file changed, 21 deletions(-)

diff --git a/configure b/configure
index 2dede36..fb52482 100755
--- a/configure
+++ b/configure
@@ -356,7 +356,6 @@ Toolchain options:
 Advanced options (experts only):
   --malloc-prefix=PREFIX   prefix malloc and related names with PREFIX
   --custom-allocator=NAME  use a supported custom allocator
-  --disable-symver disable symbol versioning
   --enable-hardcoded-tables use hardcoded tables instead of runtime generation
   --disable-safe-bitstream-reader
disable buffer boundary checking in bitreaders
@@ -1779,7 +1778,6 @@ BUILTIN_LIST="
 "
 HAVE_LIST_CMDLINE="
 inline_asm
-symver
 yasm
 "
 
@@ -1953,8 +1951,6 @@ TOOLCHAIN_FEATURES="
 inline_asm_nonlocal_labels
 pragma_deprecated
 rsync_contimeout
-symver_asm_label
-symver_gnu_asm
 vfp_args
 xform_asm
 xmm_clobbers
@@ -2257,7 +2253,6 @@ fast_unaligned_if_any="aarch64 ppc x86"
 simd_align_16_if_any="altivec neon sse"
 
 # system capabilities
-symver_if_any="symver_asm_label symver_gnu_asm"
 valgrind_backtrace_deps="!optimizations valgrind_valgrind_h"
 
 # threading support
@@ -4570,7 +4565,6 @@ case $target_os in
 enabled shared && add_ldflags -Wl,-brtl
 ;;
 android)
-disable symver
 enable section_data_rel_ro
 SLIB_INSTALL_NAME='$(SLIBNAME)'
 SLIB_INSTALL_LINKS=
@@ -4598,13 +4592,11 @@ case $target_os in
 SLIB_CREATE_DEF_CMD='$(Q)perl 
$(SRC_PATH)/compat/solaris/make_sunver.pl $$(filter %.ver,$$^) $(OBJS) | grep 
-v @ > $(SUBDIR)lib$(NAME).ver-sol2'
 ;;
 netbsd)
-disable symver
 oss_indev_extralibs="-lossaudio"
 oss_outdev_extralibs="-lossaudio"
 enabled gcc || check_ldflags -Wl,-zmuldefs
 ;;
 openbsd|bitrig)
-disable symver
 SHFLAGS='-shared'
 SLIB_INSTALL_NAME='$(SLIBNAME).$(LIBMAJOR).$(LIBMINOR)'
 SLIB_INSTALL_LINKS=
@@ -4612,7 +4604,6 @@ case $target_os in
 oss_outdev_extralibs="-lossaudio"
 ;;
 dragonfly)
-disable symver
 ;;
 freebsd)
 ;;
@@ -4695,7 +4686,6 @@ case $target_os in
 fi
 ;;
 win32|win64)
-disable symver
 if enabled shared; then
 # Link to the import library instead of the normal static library
 # for shared libs.
@@ -6006,15 +5996,6 @@ elif test_ldflags -Wl,-M,$TMPV; then
 append SHFLAGS '-Wl,-M,\$(SUBDIR)lib\$(NAME).ver-sol2'
 fi
 
-check_cc 

Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

[Derek Buitenhuis]

On 5/19/2016 2:12 PM, Michael Niedermayer wrote:
> if derek still wants to leave in 2 weeks then so be it, its his choice
> but i really hope things can be resolved in a way that everyone
> stays and works together and is happy

I will wait 2 weeks.

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

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

[Kyle Swanson]

>
> Pushed. Waiting for libebur128 removal as dependency.

Thanks. Working on porting libebur128 to FFmpeg now. Hopefully I can
find some time to finish that patch soon.

>
> Can anything be done to make this filter faster?

Probably, I'll do some profiling. The true peak limiter requires
upsampling everything to 192kHz which is always going to be expensive.
On my machine, a stereo file processes with a speed of about 16x.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/adpcm: pick correct step_index for IMA AMV

[Paul B Mahol]

On 5/19/16, James Almer  wrote:
> On 5/19/2016 11:43 AM, Paul B Mahol wrote:
>> Hi,
>>
>> patch attached.
>>
>>
>> 0001-avcodec-adpcm-pick-correct-step_index-for-IMA-AMV.patch
>>
>>
>> From 78dc1f23509f59e64adbc0a4ecf2e6b77581e375 Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol 
>> Date: Thu, 19 May 2016 16:40:07 +0200
>> Subject: [PATCH] avcodec/adpcm: pick correct step_index for IMA AMV
>>
>> Fixes #5538
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/adpcm.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
>> index 0b6b92e..ac74318 100644
>> --- a/libavcodec/adpcm.c
>> +++ b/libavcodec/adpcm.c
>> @@ -1310,8 +1310,8 @@ static int adpcm_decode_frame(AVCodecContext *avctx,
>> void *data,
>>  break;
>>  case AV_CODEC_ID_ADPCM_IMA_AMV:
>>  c->status[0].predictor = sign_extend(bytestream2_get_le16u(),
>> 16);
>> -c->status[0].step_index = bytestream2_get_le16u();
>> -bytestream2_skipu(, 4);
>> +c->status[0].step_index = bytestream2_get_byteu();
>> +bytestream2_skipu(, 5);
>>  if (c->status[0].step_index > 88u) {
>>  av_log(avctx, AV_LOG_ERROR, "ERROR: step_index = %i\n",
>> c->status[0].step_index);
>
> No fate change? Coverage shows this code is tested.

Yes, fate passes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/adpcm: pick correct step_index for IMA AMV

[James Almer]

On 5/19/2016 11:43 AM, Paul B Mahol wrote:
> Hi,
> 
> patch attached.
> 
> 
> 0001-avcodec-adpcm-pick-correct-step_index-for-IMA-AMV.patch
> 
> 
> From 78dc1f23509f59e64adbc0a4ecf2e6b77581e375 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Thu, 19 May 2016 16:40:07 +0200
> Subject: [PATCH] avcodec/adpcm: pick correct step_index for IMA AMV
> 
> Fixes #5538
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/adpcm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
> index 0b6b92e..ac74318 100644
> --- a/libavcodec/adpcm.c
> +++ b/libavcodec/adpcm.c
> @@ -1310,8 +1310,8 @@ static int adpcm_decode_frame(AVCodecContext *avctx, 
> void *data,
>  break;
>  case AV_CODEC_ID_ADPCM_IMA_AMV:
>  c->status[0].predictor = sign_extend(bytestream2_get_le16u(), 16);
> -c->status[0].step_index = bytestream2_get_le16u();
> -bytestream2_skipu(, 4);
> +c->status[0].step_index = bytestream2_get_byteu();
> +bytestream2_skipu(, 5);
>  if (c->status[0].step_index > 88u) {
>  av_log(avctx, AV_LOG_ERROR, "ERROR: step_index = %i\n",
> c->status[0].step_index);

No fate change? Coverage shows this code is tested.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Add AVClass to AVCodecParameters

[James Almer]

On 5/19/2016 11:38 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, May 19, 2016 at 8:14 AM, Michael Niedermayer > wrote:
> 
>> On Thu, May 19, 2016 at 12:08:25PM +0200, Nicolas George wrote:
>>> Le nonidi 29 floréal, an CCXXIV, Michael Niedermayer a écrit :
 there where and are accessor functions:
 git grep MAKE_ACCESSORS
>>>
>>> Yes, and they should have been the only way of avoiding ABI compatibility
>>> issues.
>>
>> applications which supported both libav and ffmpeg cannot use symbols
>> that exist in only one of the forks as it would break linking.
> 
> 
> Didn't we drop support for this?
> 
> Ronald

Yeah, we dropped support starting with the latest major bump. It was barely
used if at all and in any case nobody afaik bothered to actually do some
testing to corroborate ffmpeg libs were truly api/abi compatible, so some
suspected it probably stopped working some years down the line.

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

[FFmpeg-devel] [PATCH] avcodec/adpcm: pick correct step_index for IMA AMV

[Paul B Mahol]

Hi,

patch attached.
From 78dc1f23509f59e64adbc0a4ecf2e6b77581e375 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Thu, 19 May 2016 16:40:07 +0200
Subject: [PATCH] avcodec/adpcm: pick correct step_index for IMA AMV

Fixes #5538

Signed-off-by: Paul B Mahol 
---
 libavcodec/adpcm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 0b6b92e..ac74318 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -1310,8 +1310,8 @@ static int adpcm_decode_frame(AVCodecContext *avctx, void *data,
 break;
 case AV_CODEC_ID_ADPCM_IMA_AMV:
 c->status[0].predictor = sign_extend(bytestream2_get_le16u(), 16);
-c->status[0].step_index = bytestream2_get_le16u();
-bytestream2_skipu(, 4);
+c->status[0].step_index = bytestream2_get_byteu();
+bytestream2_skipu(, 5);
 if (c->status[0].step_index > 88u) {
 av_log(avctx, AV_LOG_ERROR, "ERROR: step_index = %i\n",
c->status[0].step_index);
-- 
2.5.0

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

Re: [FFmpeg-devel] [PATCH] avcodec: Add AVClass to AVCodecParameters

[Ronald S. Bultje]

Hi,

On Thu, May 19, 2016 at 8:14 AM, Michael Niedermayer  wrote:

> On Thu, May 19, 2016 at 12:08:25PM +0200, Nicolas George wrote:
> > Le nonidi 29 floréal, an CCXXIV, Michael Niedermayer a écrit :
> > > there where and are accessor functions:
> > > git grep MAKE_ACCESSORS
> >
> > Yes, and they should have been the only way of avoiding ABI compatibility
> > issues.
>
> applications which supported both libav and ffmpeg cannot use symbols
> that exist in only one of the forks as it would break linking.


Didn't we drop support for this?

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

Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Add a G.729 muxer

[Clément Bœsch]

On Wed, May 18, 2016 at 02:46:34PM +0100, Derek Buitenhuis wrote:
> On 5/18/2016 2:32 PM, Carl Eugen Hoyos wrote:
> > I should probably add that this is an interesting comment 
> > coming from somebody who breaks FFmpeg with nearly every 
> > commit and not only absolutely refuses to work on fixes but 
> > even blocks fixes if others want to help him.
> 
> Frankly, this is nothing nothing but an ad hominem attack.
> 
> I am tired of it. This happens constantly, and the community
> is always silent[1], and far too accepting of such toxic behavior.
> 
> It has given me far too much unneeded stress and sourness. The
> complete inability of the community to address such behavior and
> individuals is appalling.
> 
> I've had enough. I've already distanced myself from the Libav
> community recently for similar behavior, and I will be doing
> so for the FFmpeg community as well now.
> 
> Both are toxic communities. As of this email, I am unsubscribing
> from both ffmpeg-devel and libav-devel.
> 
> I hope both communities enjoy their little out of touch bubbles.
> 

It seems I'm late to the party again...

As some people like to remind me, I'm indeed guilty and staying silent
when I should raise arms against the devil. But just like you, I assume
many people here are also very tired of the fighting (be it "between" or
"within" projects) and as a result don't feel like getting more involved
in this.

So, just like others in this thread, yes of course you have my support
against sanctions wrt the non respect of the common technical workflow,
and indeed more into to the other issue, the heated crap following.

One thing I don't understand though, this kind of situation happens from
time to time, and every single time there is like a hand of developers
spouting hatred at a single or two individuals, and complaining along the
lines "the project doesn't do shit about $issue", followed by a tendency
to shift the blame onto the other people who might not give much of a
thought about that particular issue, or simply don't necessarily want to
be involved in.

So instead of these explosive and abrasive behaviours (which I'm not even
condemning), I'd suggest the people who are really unhappy about it to
bring potential ways out of it. Why was it needed for Michael to step in
with a code of conduct even though we know he is much more efficient at
non political or writing stuff, and has/had a delicate position in the
matter?

Paul suggested an IRC meeting, which is probably a step in the good
direction, but I think Kieran, wm4, or you Derek (maybe missing others),
should have been the first to send a draft for a code of conduct +
sanctions things, or whatever other plan you had in mind. You think
someone else is going to take responsibility for this? Don't fool
yourself, it's unlikely to happen.

I understand the anger, I really do. But shouting about a 3rd fork,
getting angry at Carl or leaving slamming the door does not look like it's
going to help (this last sentence is not directly aimed at you, but more
at the group looking for changes).

It's sad to see all this anger energy not be transformed in something more
constructive, and it will be another loss to see you leave.

-- 
Clément B.


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

Re: [FFmpeg-devel] IRC meeting

[Clément Bœsch]

On Wed, May 18, 2016 at 10:33:23PM +0200, Paul B Mahol wrote:
> Hi,
> 
> I want to propose to have an FFmpeg IRC meeting on
> the Saturday of the next week, Saturday May 28,
> UTC 17.
> 
> Candidate topics of the day:
>  - Code of Conduct and policy around it
>  - technical development issues
>  - misc topics
> 

Sure, fine with me.

Might want to add infrastructure (the conclusion will likely be that we
lack someone to handle it though)

-- 
Clément B.


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

Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

[Kieran Kunhya]

On Thu, 19 May 2016 at 14:15 Michael Niedermayer 
wrote:

> On Thu, May 19, 2016 at 02:47:48PM +0200, wm4 wrote:
> > He asked to forward this patch, so here it is.
>
> >  MAINTAINERS |6 --
> >  1 file changed, 6 deletions(-)
> > 20f379abeae676c2c0423b96afe38532e33b764f  remove.patch
> > From 53a4cafd64b008ad446a8866eaed622aeb320d3b Mon Sep 17 00:00:00 2001
> > From: Derek Buitenhuis 
> > Date: Thu, 19 May 2016 13:27:08 +0100
> > Subject: [PATCH] MAINTAINERS: Remove myself
> >
> > Signed-off-by: Derek Buitenhuis 
>
> i object to this
> please wait a week or 2
>
> if derek still wants to leave in 2 weeks then so be it, its his choice
> but i really hope things can be resolved in a way that everyone
> stays and works together and is happy
>
> [...]
>

It's not up to you.

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

Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

[Michael Niedermayer]

On Thu, May 19, 2016 at 02:47:48PM +0200, wm4 wrote:
> He asked to forward this patch, so here it is.

>  MAINTAINERS |6 --
>  1 file changed, 6 deletions(-)
> 20f379abeae676c2c0423b96afe38532e33b764f  remove.patch
> From 53a4cafd64b008ad446a8866eaed622aeb320d3b Mon Sep 17 00:00:00 2001
> From: Derek Buitenhuis 
> Date: Thu, 19 May 2016 13:27:08 +0100
> Subject: [PATCH] MAINTAINERS: Remove myself
> 
> Signed-off-by: Derek Buitenhuis 

i object to this
please wait a week or 2

if derek still wants to leave in 2 weeks then so be it, its his choice
but i really hope things can be resolved in a way that everyone
stays and works together and is happy

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] Tee improvement - discussion

[Jan Sebechlebsky]

Hello Nicolas,

On 05/19/2016 12:44 PM, Nicolas George wrote:

Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :

My current idea is to create queue for each output (as Marton suggested) and
process each output in separate thread. I was also considering using just
single queue, but since the AVPackets are referenced counted, the memory
overhead is negligible and using multiple queues will simplify the code.
Apart from getting advantage of non-blocking processing with multiple slave
muxers, error handling will also be improved.



Another question is what to do when some of the queues becomes full,
discussed options were so far:
 - Block write_packet call until the queue frees - this might be useful
when producer is faster than consumer, and we don't want to drop any packets
when recording to file.
 - Drop some yet unprocessed packets (until next keyframe, or free some
portion of queue) to free the queue - this might be useful for network
outputs.

I must say, I am not very happy with the direction this project takes.

Non-blocking muxers (and demuxers, and protocols) is a white whale for our
API: we really really want it, but it huge and very hard to catch.
Does this objection apply to the non-blocking full queue handling stated 
above or the whole project (using threads in tee)?

It is something that needs to be implemented globally with a very careful
design. Definitely not something that can be added in a corner of an obscure
muxer. We already went down that path twice, with the thread for the UDP
protocol and with running demuxer in threads in FFmpeg. Both did lead to
endless complications: bugs, inconsistencies, portability trouble.

If you want to work on that (in order to bring these enhancements to the tee
muxer, fitting the topic of the GSoC project), you probably can. But I
expect this to be very hard. It has been rejected as a proposal for a GSoC
project in the past on the basis that it is probably too hard for a random
student. Also, I am not sure that Marton, your official mentor, would want
such a huge shift in the project's goals.
I must accept that for now I may lack the complete overview over 
the project to see the potential problems which this could introduce.
However in the proposed project there is enough time to do proper 
testing and eliminate the found issues and the solution described in 
proposal could still be a benefit (if the ideal solution is too hard). 
Also I thing the proposed changes will not bring too much complexity to 
the project regarding thread handling.
I don't mind changing the plans and implementing it in other way if 
it is better and achievable - but you might be right this may be too hard.
Anyway if you give me some directions, (what are the requirements for 
the more general solution, what are the particular problems in the 
proposed one) I can at least try to dive more into it (getting more 
familiar with the project will be only a benefit).
I don't know how such changes are handled in GSoC (since I probably 
wouldn't be able meet milestone if the solution would require the 
complex global changes first).



Regards,



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

Thanks,

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

[FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

[wm4]

He asked to forward this patch, so here it is.>From 53a4cafd64b008ad446a8866eaed622aeb320d3b Mon Sep 17 00:00:00 2001
From: Derek Buitenhuis 
Date: Thu, 19 May 2016 13:27:08 +0100
Subject: [PATCH] MAINTAINERS: Remove myself

Signed-off-by: Derek Buitenhuis 
---
 MAINTAINERS | 6 --
 1 file changed, 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 52c30ed..8137d67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -159,7 +159,6 @@ Codecs:
   cinepakenc.c  Rl / Aetey G.T. AB
   ccaption_dec.cAnshul Maheshwari
   cljr  Alex Beregszaszi
-  cllc.cDerek Buitenhuis
   cook.c, cookdata.hBenjamin Larsson
   cpia.cStephan Hilb
   crystalhd.c   Philip Langdale
@@ -177,7 +176,6 @@ Codecs:
   exif.c, exif.hThilo Borgmann
   ffv1* Michael Niedermayer
   ffwavesynth.c Nicolas George
-  fic.c Derek Buitenhuis
   flac* Justin Ruggles
   flashsv*  Benjamin Larsson
   flicvideo.c   Mike Melanson
@@ -215,7 +213,6 @@ Codecs:
   libvorbis.c   David Conrad
   libvpx*   James Zern
   libx264.c Mans Rullgard, Jason Garrett-Glaser
-  libx265.c Derek Buitenhuis
   libxavs.c Stefan Gehrer
   libzvbi-teletextdec.c Marton Balint
   loco.cKostya Shishkov
@@ -273,9 +270,7 @@ Codecs:
   ttaenc.c  Paul B Mahol
   txd.c Ivo van Poorten
   ulti* Kostya Shishkov
-  v410*.c   Derek Buitenhuis
   vb.c  Kostya Shishkov
-  vble.cDerek Buitenhuis
   vc1*  Kostya Shishkov, Christophe Gisquet
   vc2*  Rostislav Pehlivanov
   vcr1.cMichael Niedermayer
@@ -302,7 +297,6 @@ Codecs:
   xl.c  Kostya Shishkov
   xvmc.cIvan Kalvachev
   xwd*  Paul B Mahol
-  zerocodec.c   Derek Buitenhuis
   zmbv* Kostya Shishkov
 
 Hardware acceleration:
-- 
1.8.3.1


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

Re: [FFmpeg-devel] [PATCH] avcodec/bitstream_filter: Check return code of av_opt_set_from_string()

[Michael Niedermayer]

On Thu, May 19, 2016 at 02:28:40PM +0200, Hendrik Leppkes wrote:
> On Thu, May 19, 2016 at 1:29 PM, Michael Niedermayer
>  wrote:
> > Fixes CID1361965
> >
> > Iam not 100% sure this doesnt break some case, if it does please
> > tell me. Ill fix it
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/bitstream_filter.c |2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
> > index 02878e3..4459bbb 100644
> > --- a/libavcodec/bitstream_filter.c
> > +++ b/libavcodec/bitstream_filter.c
> > @@ -123,6 +123,8 @@ int av_bitstream_filter_filter(AVBitStreamFilterContext 
> > *bsfc,
> >  shorthand[0] = opt->name;
> >
> >  ret = av_opt_set_from_string(priv->ctx->priv_data, bsfc->args, 
> > shorthand, "=", ":");
> > +if (ret < 0)
> > +return ret;
> >  }
> >
> 
> I don't think erroring out here is really needed, its not like broken
> options would result in fatal failures later on.

ok, dismissed the CID in coverity as "intentional" with reference to
this thread


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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH] avcodec/bitstream_filter: Check return code of av_opt_set_from_string()

[Hendrik Leppkes]

On Thu, May 19, 2016 at 1:29 PM, Michael Niedermayer
 wrote:
> Fixes CID1361965
>
> Iam not 100% sure this doesnt break some case, if it does please
> tell me. Ill fix it
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/bitstream_filter.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
> index 02878e3..4459bbb 100644
> --- a/libavcodec/bitstream_filter.c
> +++ b/libavcodec/bitstream_filter.c
> @@ -123,6 +123,8 @@ int av_bitstream_filter_filter(AVBitStreamFilterContext 
> *bsfc,
>  shorthand[0] = opt->name;
>
>  ret = av_opt_set_from_string(priv->ctx->priv_data, bsfc->args, 
> shorthand, "=", ":");
> +if (ret < 0)
> +return ret;
>  }
>

I don't think erroring out here is really needed, its not like broken
options would result in fatal failures later on.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Add AVClass to AVCodecParameters

[Michael Niedermayer]

On Thu, May 19, 2016 at 12:08:25PM +0200, Nicolas George wrote:
> Le nonidi 29 floréal, an CCXXIV, Michael Niedermayer a écrit :
> > there where and are accessor functions:
> > git grep MAKE_ACCESSORS
> 
> Yes, and they should have been the only way of avoiding ABI compatibility
> issues.

applications which supported both libav and ffmpeg cannot use symbols
that exist in only one of the forks as it would break linking.

the same AVOption based code works with both forks though

using accessors 2 different pieces of code would be needed and thus
also different binaries


Also with just accessors and no entry in AVOption
ffmpeg.c, ffplay.c and ffprobe.c would have needed explicit support
for each individual parameter instead of just generically exposing
the whole set of options


> 
> Another point against AVClass: FFmpeg is mostly in C, C has static typing
> and static typing is good.
> 
> That means that almost everywhere where AVClass is used, we know the type of
> the structure we are handling, and therefore we know what AVClass we should
> use. It could be an explicit parameter instead of an implicit parameter
> hidden in the first field of the structure. The only case where we need it
> is for private context for dynamic typing.

Theres the case ronald raised, that is the huge mess of options in
AVCodecContext and AVFormatContext
the type of these structures is known generally but not which of
the options apply to the codec at hand

A user application and the user want to know what options are relevant
to the codec at hand
is thebit_rate_tolerance going to be honored, is the gop_size,
the max_b_frames, the intra_matrix or the block align value ?

an AVClass in the first element of AVCodecContext with its AVOption
list can give an application this precisse list of
which of the options work on the actual used codec

C tells you about the fields that where listed at build time in the
included header, that are all fields that any codec could use from
AVCodecContext. Like ronald said that is a mess from the user
applications point of view
AVClass could provide your application with a list of what
the actually linked lib at runtime with the actually selected codec
supports

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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

[FFmpeg-devel] [PATCH] avcodec/bitstream_filter: Check return code of av_opt_set_from_string()

[Michael Niedermayer]

Fixes CID1361965

Iam not 100% sure this doesnt break some case, if it does please
tell me. Ill fix it

Signed-off-by: Michael Niedermayer 
---
 libavcodec/bitstream_filter.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
index 02878e3..4459bbb 100644
--- a/libavcodec/bitstream_filter.c
+++ b/libavcodec/bitstream_filter.c
@@ -123,6 +123,8 @@ int av_bitstream_filter_filter(AVBitStreamFilterContext 
*bsfc,
 shorthand[0] = opt->name;
 
 ret = av_opt_set_from_string(priv->ctx->priv_data, bsfc->args, 
shorthand, "=", ":");
+if (ret < 0)
+return ret;
 }
 
 ret = av_bsf_init(priv->ctx);
-- 
1.7.9.5

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

Re: [FFmpeg-devel] why ffmpeg reports error when decoding rm or rmvb files

[Moritz Barsnick]

On Tue, May 17, 2016 at 12:17:30 +0800, qw wrote:
> Thanks for your reply. What does 'the thread went OT' mean?

I pointed out that the thread which should have been discussing the
posted patch discussed a different matter.

> How to know whether my presented question has been resolved, if
> someone has sent some solution on ffmpeg forum, like
> 'http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194083.html'?

Have you looked at the linked message? It contains a patch. If you
apply that patch to the ffmpeg source code and rebuild, your problem
may be solved.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Add AVClass to AVCodecParameters

[Nicolas George]

Le nonidi 29 floréal, an CCXXIV, Michael Niedermayer a écrit :
> there where and are accessor functions:
> git grep MAKE_ACCESSORS

Yes, and they should have been the only way of avoiding ABI compatibility
issues.

Another point against AVClass: FFmpeg is mostly in C, C has static typing
and static typing is good.

That means that almost everywhere where AVClass is used, we know the type of
the structure we are handling, and therefore we know what AVClass we should
use. It could be an explicit parameter instead of an implicit parameter
hidden in the first field of the structure. The only case where we need it
is for private context for dynamic typing.

Therefore, I am rather strongly against adding AVClass fields to new
structures. I will not object in this instance if that fits the current
normal use of AVOption: if a patch series can make it so that dash-option on
the ffmpeg command-line reaches AVCodecParameters and does something useful,
then ok. But adding it just in case, no.

Note that I am easily convinced this is actually useful: if an option of
AVCodecParameters parameter could replace all the "video_size", "framerate",
etc., private options of rawvideodec, image2dec, etc., then adding the
fields is certainly a good idea. Still, there probably was a reason to make
these private options instead of accessing the codec fields directly like it
used to work. I do not remember what this reason was, and I have not yet
looked closely enough at AVCodecParameters to know if it can work that way.

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] lavc/mediacodec: add missing MediaCodec.Get{Input, Output}Buffer() checks

[Matthieu Bouron]

On Tue, May 17, 2016 at 03:20:54PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ---
>  libavcodec/mediacodec_wrapper.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 8ce3b32..5c047ea 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -1056,6 +1056,10 @@ FFAMediaCodec* ff_AMediaCodec_createCodecByName(const 
> char *name)
>  goto fail;
>  }
>  
> +if (codec->jfields.get_input_buffer_id && 
> codec->jfields.get_output_buffer_id) {
> +codec->has_get_i_o_buffer = 1;
> +}
> +
>  JNI_DETACH_ENV(attached, codec);
>  
>  return codec;
> @@ -1178,6 +1182,10 @@ FFAMediaCodec* 
> ff_AMediaCodec_createEncoderByType(const char *mime)
>  goto fail;
>  }
>  
> +if (codec->jfields.get_input_buffer_id && 
> codec->jfields.get_output_buffer_id) {
> +codec->has_get_i_o_buffer = 1;
> +}
> +
>  JNI_DETACH_ENV(attached, NULL);
>  
>  return codec;

I will push both patch in one day if there is no objection.

Matthieu

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

Re: [FFmpeg-devel] IRC meeting

[Paul B Mahol]

On 5/19/16, Michael Niedermayer  wrote:
> On Wed, May 18, 2016 at 10:33:23PM +0200, Paul B Mahol wrote:
>> Hi,
>>
>> I want to propose to have an FFmpeg IRC meeting on
>> the Saturday of the next week, Saturday May 28,
>> UTC 17.
>>
>> Candidate topics of the day:
>
>>  - Code of Conduct and policy around it
>
> does this affect the current vote ?
> i mean should we set the end date for the current vote before the
> meeting to have some agreed basis to start from OR
> should we wait for the meeting first, which could cause
> delays in having any CoC, if we restart the process and do more rounds
> of changes and comments, each requiring to wait to give people time
> to comment before a final vote
> what do people prefer ?

This one is more about what if Code of Conduct is violated and actions
to be taken after that.
Until now there where no rules at all and everyone could do anything
if he/she wanted and where virtually no consequences if one did permanent
damage to the project.

>
>
>>  - technical development issues
>>  - misc topics
>>
>> Feel free to propose other topics.
>
> Iam not sure but
> Ideas about encouraging people to work on bugs and especially
> regressions.
>
> FFmpeg funding/donations, whats the current status, can we fund some
> developers to do important work, and if needed ideas to increase funds
> & donations (i think its needed)

That one is interesting to have.

>
> AVClass, I need to know if [3.1 - 4.0[ should have a AVClass in
> AVCodecParameters or not, as its a question that must be awnsered
> before the next release and cant be added afterwards

IIRC some devs appears to be against it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Tee improvement - discussion

[Nicolas George]

Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
> My current idea is to create queue for each output (as Marton suggested) and
> process each output in separate thread. I was also considering using just
> single queue, but since the AVPackets are referenced counted, the memory
> overhead is negligible and using multiple queues will simplify the code.
> Apart from getting advantage of non-blocking processing with multiple slave
> muxers, error handling will also be improved.

> Another question is what to do when some of the queues becomes full,
> discussed options were so far:
> - Block write_packet call until the queue frees - this might be useful
> when producer is faster than consumer, and we don't want to drop any packets
> when recording to file.
> - Drop some yet unprocessed packets (until next keyframe, or free some
> portion of queue) to free the queue - this might be useful for network
> outputs.

I must say, I am not very happy with the direction this project takes.

Non-blocking muxers (and demuxers, and protocols) is a white whale for our
API: we really really want it, but it huge and very hard to catch.

It is something that needs to be implemented globally with a very careful
design. Definitely not something that can be added in a corner of an obscure
muxer. We already went down that path twice, with the thread for the UDP
protocol and with running demuxer in threads in FFmpeg. Both did lead to
endless complications: bugs, inconsistencies, portability trouble.

If you want to work on that (in order to bring these enhancements to the tee
muxer, fitting the topic of the GSoC project), you probably can. But I
expect this to be very hard. It has been rejected as a proposal for a GSoC
project in the past on the basis that it is probably too hard for a random
student. Also, I am not sure that Marton, your official mentor, would want
such a huge shift in the project's goals.

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] IRC meeting

[Michael Niedermayer]

On Wed, May 18, 2016 at 10:33:23PM +0200, Paul B Mahol wrote:
> Hi,
> 
> I want to propose to have an FFmpeg IRC meeting on
> the Saturday of the next week, Saturday May 28,
> UTC 17.
> 
> Candidate topics of the day:

>  - Code of Conduct and policy around it

does this affect the current vote ?
i mean should we set the end date for the current vote before the
meeting to have some agreed basis to start from OR
should we wait for the meeting first, which could cause
delays in having any CoC, if we restart the process and do more rounds
of changes and comments, each requiring to wait to give people time
to comment before a final vote
what do people prefer ?


>  - technical development issues
>  - misc topics
> 
> Feel free to propose other topics.

Iam not sure but
Ideas about encouraging people to work on bugs and especially
regressions.

FFmpeg funding/donations, whats the current status, can we fund some
developers to do important work, and if needed ideas to increase funds
& donations (i think its needed)

AVClass, I need to know if [3.1 - 4.0[ should have a AVClass in
AVCodecParameters or not, as its a question that must be awnsered
before the next release and cant be added afterwards


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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Nicolas George]

Le decadi 30 floréal, an CCXXIV, Michael Niedermayer a écrit :
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/developer.texi |   29 +
>  1 file changed, 29 insertions(+)

I agree to the code of conduct.

But: I am not sure I should vote anyway, IIRC we did not finalize the voting
process rules nor the list of people who have authority. Still, voting yes
costs nothing. Also: it probably lacks a conflict resolution mechanism. But
it is a good start.

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] doc/developer.texi: Add a code of conduct

[Benoit Fouet]

Hi,

Le 18 mai 2016 20:40:08 GMT+02:00, Michael Niedermayer  
a écrit :
>Signed-off-by: Michael Niedermayer 
>---
> doc/developer.texi |   29 +
> 1 file changed, 29 insertions(+)
>
>diff --git a/doc/developer.texi b/doc/developer.texi
>index 6db93ce..4d3a7ae 100644
>--- a/doc/developer.texi
>+++ b/doc/developer.texi
>@@ -403,6 +403,35 @@ finding a new maintainer and also don't forget to
>update the @file{MAINTAINERS}
> 
> We think our rules are not too hard. If you have comments, contact us.
> 
>+@section Code of conduct
>+
>+Be friendly and respectful towards others and third parties.
>+Treat others the way you yourself want to be treated.
>+
>+Be considerate. Not everyone shares the same viewpoint and priorities
>as you do.
>+Different opinions and interpretations help the project.
>+Looking at issues from a different perspective assists development.
>+
>+Do not assume malice for things that can be attributed to
>incompetence. Even if
>+it is malice, it's rarely good to start with that as initial
>assumption.
>+
>+Stay friendly even if someone acts contrarily. Everyone has a bad day
>+once in a while.
>+If you yourself have a bad day or are angry then try to take a break
>and reply
>+once you are calm and without anger if you have to.
>+
>+Try to help other team members and cooperate if you can.
>+
>+The goal of software development is to create technical excellence,
>not for any
>+individual to be better and "win" against the others. Large software
>projects
>+are only possible and successful through teamwork.
>+
>+If someone struggles do not put them down. Give them a helping hand
>+instead and point them in the right direction.
>+
>+Finally, keep in mind the immortal words of Bill and Ted,
>+"Be excellent to each other."
>+
> @anchor{Submitting patches}
> @section Submitting patches
> 

FWIW, fine by me too.

-- 
Ben 


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

[FFmpeg-devel] [PATCH 3/4] lavf/concat: switch to new BSF API.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavformat/concatdec.c | 165 ++--
 1 file changed, 76 insertions(+), 89 deletions(-)


Unchanged.


diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index b3a430e..bbea158 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -34,7 +34,7 @@ typedef enum ConcatMatchMode {
 } ConcatMatchMode;
 
 typedef struct ConcatStream {
-AVBitStreamFilterContext *bsf;
+AVBSFContext *bsf;
 AVCodecContext *avctx;
 int out_stream_index;
 } ConcatStream;
@@ -58,6 +58,7 @@ typedef struct {
 ConcatFile *cur_file;
 unsigned nb_files;
 AVFormatContext *avf;
+ConcatStream *active_bsf;
 int safe;
 int seekable;
 int eof;
@@ -195,39 +196,54 @@ static int detect_stream_specific(AVFormatContext *avf, 
int idx)
 {
 ConcatContext *cat = avf->priv_data;
 AVStream *st = cat->avf->streams[idx];
+AVStream *ost;
 ConcatStream *cs = >cur_file->streams[idx];
-AVBitStreamFilterContext *bsf;
+AVBSFContext *bsf = NULL;
+const AVBitStreamFilter *filter;
+const char *filter_name = NULL;
 int ret;
 
-if (cat->auto_convert && st->codecpar->codec_id == AV_CODEC_ID_H264 &&
-(st->codecpar->extradata_size < 4 || AV_RB32(st->codecpar->extradata) 
!= 1)) {
-av_log(cat->avf, AV_LOG_INFO,
-   "Auto-inserting h264_mp4toannexb bitstream filter\n");
-if (!(bsf = av_bitstream_filter_init("h264_mp4toannexb"))) {
-av_log(avf, AV_LOG_ERROR, "h264_mp4toannexb bitstream filter "
-   "required for H.264 streams\n");
-return AVERROR_BSF_NOT_FOUND;
-}
-cs->bsf = bsf;
-
-cs->avctx = avcodec_alloc_context3(NULL);
-if (!cs->avctx)
-return AVERROR(ENOMEM);
-
-/* This really should be part of the bsf work.
-   Note: input bitstream filtering will not work with bsf that
-   create extradata from the first packet. */
-av_freep(>codecpar->extradata);
-st->codecpar->extradata_size = 0;
+if (cs->out_stream_index < 0)
+return 0;
+ost = avf->streams[cs->out_stream_index];
 
-ret = avcodec_parameters_to_context(cs->avctx, st->codecpar);
-if (ret < 0) {
-avcodec_free_context(>avctx);
-return ret;
-}
+if (cat->auto_convert && st->codecpar->codec_id == AV_CODEC_ID_H264 &&
+(st->codecpar->extradata_size < 4 || AV_RB32(st->codecpar->extradata) 
!= 1))
+filter_name = "h264_mp4toannexb";
 
+if (filter_name)
+av_log(cat->avf, AV_LOG_INFO,
+   "Auto-inserting %s bitstream filter\n", filter_name);
+else
+filter_name = "null";
+
+filter = av_bsf_get_by_name(filter_name);
+if (!filter) {
+av_log(avf, AV_LOG_ERROR,
+   "%s bitstream filter required for %s streams\n",
+   filter_name, avcodec_get_name(st->codecpar->codec_id));
+return AVERROR_BSF_NOT_FOUND;
 }
+ret = av_bsf_alloc(filter, );
+if (ret < 0)
+return ret;
+ret = avcodec_parameters_copy(bsf->par_in, st->codecpar);
+if (ret < 0)
+goto fail;
+bsf->time_base_in = st->time_base;
+ret = av_bsf_init(bsf);
+if (ret < 0)
+goto fail;
+ret = avcodec_parameters_copy(ost->codecpar, bsf->par_out);
+if (ret < 0)
+goto fail;
+ost->time_base = bsf->time_base_out;
+cs->bsf = bsf;
 return 0;
+
+fail:
+av_bsf_free();
+return ret;
 }
 
 static int match_streams_one_to_one(AVFormatContext *avf)
@@ -368,8 +384,7 @@ static int concat_read_close(AVFormatContext *avf)
 for (j = 0; j < cat->files[i].nb_streams; j++) {
 if (cat->files[i].streams[j].avctx)
 avcodec_free_context(>files[i].streams[j].avctx);
-if (cat->files[i].streams[j].bsf)
-av_bitstream_filter_close(cat->files[i].streams[j].bsf);
+av_bsf_free(>files[i].streams[j].bsf);
 }
 av_freep(>files[i].streams);
 av_dict_free(>files[i].metadata);
@@ -518,62 +533,6 @@ static int open_next_file(AVFormatContext *avf)
 return open_file(avf, fileno);
 }
 
-static int filter_packet(AVFormatContext *avf, ConcatStream *cs, AVPacket *pkt)
-{
-AVStream *st = avf->streams[cs->out_stream_index];
-AVBitStreamFilterContext *bsf;
-AVPacket pkt2;
-int ret;
-
-av_assert0(cs->out_stream_index >= 0);
-for (bsf = cs->bsf; bsf; bsf = bsf->next) {
-pkt2 = *pkt;
-
-ret = av_bitstream_filter_filter(bsf, cs->avctx, NULL,
- , ,
- pkt->data, pkt->size,
- !!(pkt->flags & AV_PKT_FLAG_KEY));
-if (ret < 0) {
-av_packet_unref(pkt);
-return ret;
-}
-
-if (cs->avctx->extradata_size > 

[FFmpeg-devel] [PATCH 4/4] fate: remove "-v 0" from ffprobe tests.

[Nicolas George]

The FATE scripts separate stdout from stderr.
Having a first idea about what went wrong in the log file
is more convenient.

Signed-off-by: Nicolas George 
---
 tests/fate-run.sh | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)


Unchanged.


diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 3d58080..4b31b62 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -84,7 +84,7 @@ runecho(){
 }
 
 probefmt(){
-run ffprobe${PROGSUF} -show_entries format=format_name -print_format 
default=nw=1:nk=1 -v 0 "$@"
+run ffprobe${PROGSUF} -show_entries format=format_name -print_format 
default=nw=1:nk=1 "$@"
 }
 
 runlocal(){
@@ -93,24 +93,24 @@ runlocal(){
 }
 
 probeframes(){
-run ffprobe${PROGSUF} -show_frames -v 0 "$@"
+run ffprobe${PROGSUF} -show_frames "$@"
 }
 
 probechapters(){
-run ffprobe${PROGSUF} -show_chapters -v 0 "$@"
+run ffprobe${PROGSUF} -show_chapters "$@"
 }
 
 probegaplessinfo(){
 filename="$1"
 shift
-run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries 
format=start_time,duration:stream=index,start_pts,duration_ts -v 0 "$filename" 
"$@"
+run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries 
format=start_time,duration:stream=index,start_pts,duration_ts "$filename" "$@"
 pktfile1="${outdir}/${test}.pkts"
 framefile1="${outdir}/${test}.frames"
 cleanfiles="$cleanfiles $pktfile1 $framefile1"
-run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
-count_packets -show_entries packet=pts,dts,duration:stream=nb_read_packets -v 
0 "$filename" "$@" > "$pktfile1"
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
-count_packets -show_entries packet=pts,dts,duration:stream=nb_read_packets 
"$filename" "$@" > "$pktfile1"
 head -n 8 "$pktfile1"
 tail -n 9 "$pktfile1"
-run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
-count_frames -show_entries 
frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames
 -v 0 "$filename" "$@" > "$framefile1"
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
-count_frames -show_entries 
frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames
 "$filename" "$@" > "$framefile1"
 head -n 8 "$framefile1"
 tail -n 9 "$framefile1"
 }
@@ -306,10 +306,10 @@ concat(){
 awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
 
 if [ "$mode" = "md5" ]; then
-run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -v 0 
-fflags keepside -safe 0 $extra_args $concatfile | tr -d '\r' > $packetfile
+run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -fflags 
keepside -safe 0 $extra_args $concatfile | tr -d '\r' > $packetfile
 do_md5sum $packetfile
 else
-run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -v 0 -of 
compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
+run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -of 
compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
 fi
 }
 
-- 
2.8.1

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

[FFmpeg-devel] [PATCH 2/4] lavc/bsf: add a null bitstream filter.

[Nicolas George]

It passes packets unchanged with a very low overhead.
Using it allows to have the same code path when bitstream filtering
is not used, making the code simpler and avoiding bitroting.
The filter can not be disabled so that applications can rely on it.
It is added out of alphabetical order to keep the regularity.

TODO: minor bump.
Signed-off-by: Nicolas George 
---
 libavcodec/bitstream_filters.c |  3 +++
 libavcodec/bsf.c   | 16 
 2 files changed, 19 insertions(+)


Updated to the new list format.

Name unchanged, already explained.


diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 6d58233..b7e786c 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -24,6 +24,8 @@
 #include "avcodec.h"
 #include "bsf.h"
 
+extern const AVBitStreamFilter /* hardcoded, hidden from configure */ 
ff_null_bsf;
+
 extern const AVBitStreamFilter ff_aac_adtstoasc_bsf;
 extern const AVBitStreamFilter ff_chomp_bsf;
 extern const AVBitStreamFilter ff_dump_extradata_bsf;
@@ -42,6 +44,7 @@ extern const AVBitStreamFilter ff_text2movsub_bsf;
 extern const AVBitStreamFilter ff_vp9_superframe_bsf;
 
 static const AVBitStreamFilter *bitstream_filters[] = {
+_null_bsf,
 #include "libavcodec/bsf_list.c"
 NULL
 };
diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index 88b7f29..cd82f5e 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -217,3 +217,19 @@ int ff_bsf_get_packet(AVBSFContext *ctx, AVPacket **pkt)
 
 return 0;
 }
+
+static int null_filter(AVBSFContext *ctx, AVPacket *out)
+{
+AVPacket *in;
+int ret = ff_bsf_get_packet(ctx, );
+if (ret < 0)
+return ret;
+av_packet_move_ref(out, in);
+av_packet_free();
+return 0;
+}
+
+const AVBitStreamFilter ff_null_bsf = {
+.name   = "null",
+.filter = null_filter,
+};
-- 
2.8.1

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

[FFmpeg-devel] [PATCH 1/4] configure and al.: remove declarations from generated files.

[Nicolas George]

Files containing lists generated from enabled components were:

static Type *var[] = {
generated list,
NULL };

and included as is in the file using them.
This commit removes the "static Type *var[] = {" declaration
and the final "NULL };" from the generated list and moves them
to the including code.

This means the generated files are no longer self-contained C
statements, but it is not a property that was being used.
It also means less shellized-C code in configure.

Signed-off-by: Nicolas George 
---
 configure  | 11 ---
 libavcodec/bitstream_filters.c |  3 +++
 libavformat/protocols.c|  3 +++
 3 files changed, 10 insertions(+), 7 deletions(-)


This is necessary to add the null bsf unconditionally (I already explained
my reasons for wanting it that way), but I think this is also a good change
by itself because of the last sentence. For example, we may want to tweak
the implementation of one of the lists (remove the final NULL and use
FF_ARRAY_ELEMS for example) but not both.


diff --git a/configure b/configure
index cc2c9e7..2547bb1 100755
--- a/configure
+++ b/configure
@@ -6650,19 +6650,16 @@ fi
 # generate the lists of enabled components
 print_enabled_components(){
 file=$1
-struct_name=$2
-name=$3
-shift 3
-echo "static const $struct_name *$name[] = {" > $TMPH
+shift
+printf "" > $TMPH
 for c in $*; do
 enabled $c && printf "_%s,\n" $c >> $TMPH
 done
-echo "NULL };" >> $TMPH
 cp_if_changed $TMPH $file
 }
 
-print_enabled_components libavcodec/bsf_list.c AVBitStreamFilter 
bitstream_filters $BSF_LIST
-print_enabled_components libavformat/protocol_list.c URLProtocol url_protocols 
$PROTOCOL_LIST
+print_enabled_components libavcodec/bsf_list.c $BSF_LIST
+print_enabled_components libavformat/protocol_list.c $PROTOCOL_LIST
 
 # build pkg-config files
 
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 840bb43..6d58233 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -41,7 +41,10 @@ extern const AVBitStreamFilter ff_remove_extradata_bsf;
 extern const AVBitStreamFilter ff_text2movsub_bsf;
 extern const AVBitStreamFilter ff_vp9_superframe_bsf;
 
+static const AVBitStreamFilter *bitstream_filters[] = {
 #include "libavcodec/bsf_list.c"
+NULL
+};
 
 const AVBitStreamFilter *av_bsf_next(void **opaque)
 {
diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 124010c..477948c 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -69,7 +69,10 @@ extern const URLProtocol ff_librtmpte_protocol;
 extern const URLProtocol ff_libssh_protocol;
 extern const URLProtocol ff_libsmbclient_protocol;
 
+static const URLProtocol *url_protocols[] = {
 #include "libavformat/protocol_list.c"
+NULL
+};
 
 const AVClass *ff_urlcontext_child_class_next(const AVClass *prev)
 {
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH] web: remove myself from consulting

[Thilo Borgmann]

Am 19.05.16 um 08:56 schrieb Clément Bœsch:
> On Thu, May 19, 2016 at 08:51:24AM +0200, Thilo Borgmann wrote:
>> Hi,
>>
>> Am 19.05.16 um 08:37 schrieb Clément Bœsch:
>>> I get too much mails, on a mailbox I forget to check, about issues I'm
>>> most of the time not willing to address. And I feel bad about not
>>> answering anymore lately.
>>> ---
>>>  src/consulting | 39 ---
>>>  1 file changed, 12 insertions(+), 27 deletions(-)
>>
>> when I added myself someone edited my entry to start a new row... so maybe 
>> this
>> patch also needs a reordering in terms of tabular appearance of the remaining
>> entries, too.
>>
> 
> I dropped the last row and moved you at the end of the same row I was in
> order to keep the diff relatively small. Would you prefer a full shift of
> all the entries below?

All is good if you've had this in mind :)

-Thilo

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

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Tobias Rapp]

On 18.05.2016 20:40, Michael Niedermayer wrote:

Signed-off-by: Michael Niedermayer 
---
 doc/developer.texi |   29 +
 1 file changed, 29 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index 6db93ce..4d3a7ae 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -403,6 +403,35 @@ finding a new maintainer and also don't forget to update 
the @file{MAINTAINERS}

 We think our rules are not too hard. If you have comments, contact us.

+@section Code of conduct
+
+Be friendly and respectful towards others and third parties.
+Treat others the way you yourself want to be treated.
+
+Be considerate. Not everyone shares the same viewpoint and priorities as you 
do.
+Different opinions and interpretations help the project.
+Looking at issues from a different perspective assists development.
+
+Do not assume malice for things that can be attributed to incompetence. Even if
+it is malice, it's rarely good to start with that as initial assumption.
+
+Stay friendly even if someone acts contrarily. Everyone has a bad day
+once in a while.
+If you yourself have a bad day or are angry then try to take a break and reply
+once you are calm and without anger if you have to.
+
+Try to help other team members and cooperate if you can.
+
+The goal of software development is to create technical excellence, not for any
+individual to be better and "win" against the others. Large software projects
+are only possible and successful through teamwork.
+
+If someone struggles do not put them down. Give them a helping hand
+instead and point them in the right direction.
+
+Finally, keep in mind the immortal words of Bill and Ted,
+"Be excellent to each other."
+
 @anchor{Submitting patches}
 @section Submitting patches



I agree to the code of conduct and welcome its addition.

Regards,
Tobias Rapp

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

Re: [FFmpeg-devel] [PATCH] web: remove myself from consulting

[Clément Bœsch]

On Thu, May 19, 2016 at 08:51:24AM +0200, Thilo Borgmann wrote:
> Hi,
> 
> Am 19.05.16 um 08:37 schrieb Clément Bœsch:
> > I get too much mails, on a mailbox I forget to check, about issues I'm
> > most of the time not willing to address. And I feel bad about not
> > answering anymore lately.
> > ---
> >  src/consulting | 39 ---
> >  1 file changed, 12 insertions(+), 27 deletions(-)
> 
> when I added myself someone edited my entry to start a new row... so maybe 
> this
> patch also needs a reordering in terms of tabular appearance of the remaining
> entries, too.
> 

I dropped the last row and moved you at the end of the same row I was in
order to keep the diff relatively small. Would you prefer a full shift of
all the entries below?

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] web: remove myself from consulting

[Thilo Borgmann]

Hi,

Am 19.05.16 um 08:37 schrieb Clément Bœsch:
> I get too much mails, on a mailbox I forget to check, about issues I'm
> most of the time not willing to address. And I feel bad about not
> answering anymore lately.
> ---
>  src/consulting | 39 ---
>  1 file changed, 12 insertions(+), 27 deletions(-)

when I added myself someone edited my entry to start a new row... so maybe this
patch also needs a reordering in terms of tabular appearance of the remaining
entries, too.

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

[FFmpeg-devel] [PATCH] web: remove myself from consulting

[Clément Bœsch]

I get too much mails, on a mailbox I forget to check, about issues I'm
most of the time not willing to address. And I feel bad about not
answering anymore lately.
---
 src/consulting | 39 ---
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/src/consulting b/src/consulting
index 0b03806..dfa0576 100644
--- a/src/consulting
+++ b/src/consulting
@@ -85,19 +85,6 @@ E.g.:
 
   
 
-  Clément Bœsch
-  
-Clément is located in France and is available for contracting work.
-He has worked on FFmpeg since 2011 and has been a maintainer since 
2011.
-He has experience with subtitles, filters and all kinds of random
-things across the codebase.
-You can contact him by email at
-mailto:ubitux%20at%20gmail%20dot%20com;>ubitux at gmail dot 
com.
-  
- 
-   
-  
-
   Michael Niedermayer
   
 Michael is located in Vienna, Austria and is available for contracting 
work.
@@ -118,6 +105,18 @@ E.g.:
   
  

+  
+
+  Thilo Borgmann
+  
+Thilo is located in Berlin, Germany and is available for contract work.
+He has worked on FFmpeg since 2009 and has been a maintainer since 
2010.
+He has special expertise with decoders, metadata, input devices and
+filters. You can contact him by email at
+mailto:thilo.borgm...@mail.de;>thilo.borgm...@mail.de.
+  
+ 
+   
  
 
   
@@ -157,17 +156,3 @@ E.g.:
  

  
-
-  
-
-  Thilo Borgmann
-  
-Thilo is located in Berlin, Germany and is available for contract work.
-He has worked on FFmpeg since 2009 and has been a maintainer since 
2010.
-He has special expertise with decoders, metadata, input devices and
-filters. You can contact him by email at
-mailto:thilo.borgm...@mail.de;>thilo.borgm...@mail.de.
-  
- 
-   
- 
-- 
2.8.2

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