date:20140816

On 16.08.2014, at 03:48, Jean-Baptiste Kempf  wrote:
> On 16 Aug, Michael Niedermayer wrote :
>> I had not intended to come to VDD and reading this
>> https://lists.debian.org/debian-devel/2014/08/msg00478.html
>> 
>> I definitively will not come to VDD, as it would just be wasted time,
> 
> That's an easy excuse.

Unfortunately it is all too true as well, at least from the project merging 
aspect - though I very much think VDD is a great thing in all other ways (so 
Michael, I think your statement was - probably unintentionally - mean to the 
VDD organizers).
It just ends up with people repeating the same inflammatory remarks.
Whether it is "thieves" or whether it is "the top 18 people voted" (really? 
None of us here made it in the top 18 spot? Even if that was true in some kind 
of ranking it's hard not to be at least a bit insulted by such remarks).
Which is mostly why people avoid speaking to each other, at the least about 
anything close to the subject, so far the best that would happen is that 
everyone felt uncomfortable.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Invitation to VDD and registration

On 16 Aug, Michael Niedermayer wrote :
> On Sat, Aug 16, 2014 at 03:48:53AM +0200, Jean-Baptiste Kempf wrote:
> > On 16 Aug, Michael Niedermayer wrote :
> > > I had not intended to come to VDD and reading this
> > > https://lists.debian.org/debian-devel/2014/08/msg00478.html
> > > 
> > > I definitively will not come to VDD, as it would just be wasted time,
> > 
> > That's an easy excuse.
> 
> Is it ?

Yes, it is.

As you might have seen, it's named VideoLAN Dev Days, not FFmpeg Dev
Days or libav Dev Days. As you know very well, many multimedia projects
came, from KDE to GNOME, to gst, to MPlayer! folks and people came from all
around the world. Also big companies that are using the core multimedia
libraries. And it's always gone well, without any incident.

Maybe you should ask yourself why isn't FFmpeg the center of the
community, and why aren't people coming to the FFmpeg dev days, while it's
probably 10x more used than VideoLAN software.
And maybe you will start growing up and change your attitude.

The multimedia community does not evolve only around your forks, and
everybody from the multimedia open source community is ashamed of the
situation and your attitudes...

The VideoLAN Dev Days is done for people to speak about what the magic
they are doing on a technical level for the multimedia open source
community; magic that is used all around the world, all the time. It's
also done for people to meet each other. It's not done for, and it's never
been focused on your childish fights.

Your email is insulting and your attitude is disgusting.

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Invitation to VDD and registration

On 16 Aug, Reimar Döffinger wrote :
> Which is mostly why people avoid speaking to each other, at the least about 
> anything close to the subject, so far the best that would happen is that 
> everyone felt uncomfortable.

VDD is not about your projects fighting each other.
While you were fighting, a lot of things happened in the world...

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Small patch for someone to push please

2014-08-16 Thread JULIAN GARDNER








>
> From: Michael Niedermayer 
>To: FFmpeg development discussions and patches  
>Sent: Saturday, 16 August 2014, 1:42
>Subject: Re: [FFmpeg-devel] Small patch for someone to push please
> 
>
>On Fri, Aug 15, 2014 at 11:26:40AM +0100, JULIAN GARDNER wrote:
>> In libavfilter/lavfutils.c around line 77 the code is
>> 
>>     if (ret < 0 || !frame_decoded) {
>>     av_log(log_ctx, AV_LOG_ERROR, "Failed to decode image from file\n");
>>     goto end;
>>     }
>>     ret = 0;
>> 
>> Now this causes a problem if ret>=0 and frame_decoded==0 as you get dropped 
>> out of the routine with a failed decode and no width or height.
>> 
>> my changes
>> 
>>     if (ret < 0 || !frame_decoded) {
>>     av_log(log_ctx, AV_LOG_ERROR, "Failed to decode image from file\n");
>> +    ret = !frame_decoded ? -1:ret;
>>     goto end;
>>     }
>>     ret = 0;
>> 
>
>applied similar solution
>
>thanks
>
>[...]
>-- 
>Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>No human being will ever know the Truth, for even if they happen to say it
>by chance, they would not even known they had done so. -- Xenophanes
>

Thanks

Did you manage to have a quick look at my image loading code? would love to get 
this fixed.

joolz

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

Re: [FFmpeg-devel] [PATCH 4/7] avformat/thp: dont mix integers with pointers

2014-08-16 Thread Paul B Mahol

On 8/16/14, Michael Niedermayer  wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/thp.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/thp.c b/libavformat/thp.c
> index bc4f0daf..714cec6 100644
> --- a/libavformat/thp.c
> +++ b/libavformat/thp.c
> @@ -98,7 +98,7 @@ static int thp_read_header(AVFormatContext *s)
>
>  for (i = 0; i < thp->compcount; i++) {
>  if (thp->components[i] == 0) {
> -if (thp->vst != 0)
> +if (thp->vst)
>  break;
>
>  /* Video component.  */
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

[FFmpeg-devel] AECHO

2014-08-16 Thread Yamusani Vinay

Hi All,

I included aecho(aecho.c) filter in ffmpeg 2.3.4,I compiled the library and
so files are generated I included those so files in my android application
I added that filter and ran my application but the song is not playing can
anyone help me in solving this problem

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

Re: [FFmpeg-devel] Invitation to VDD and registration

On 16.08.2014, at 09:50, Jean-Baptiste Kempf  wrote:
> On 16 Aug, Reimar Döffinger wrote :
>> Which is mostly why people avoid speaking to each other, at the least about 
>> anything close to the subject, so far the best that would happen is that 
>> everyone felt uncomfortable.
> 
> VDD is not about your projects fighting each other.
> While you were fighting, a lot of things happened in the world...

I am not sure if you misunderstood me?
What you are saying is exactly why _I_ will be attending, I so appreciate you 
organizing this, and I wished I could attend every year!
However I believe some people wanted Michael to attend for all the wrong 
reasons, and the part I quoted was about that. Maybe you weren't aware of that, 
if so sorry for not making myself clearer.
Or am I now misunderstanding what you are saying?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

2014-08-16 Thread Christophe Gisquet

Hi,

2014-08-14 11:48 GMT+02:00 Christophe Gisquet :
> Hi,
>
> 2014-08-14 5:01 GMT+02:00 Michael Niedermayer :
>> On Wed, Aug 13, 2014 at 10:21:54AM +, Christophe Gisquet wrote:
>>>  case 50081:
>>> +avctx->pix_fmt = AV_PIX_FMT_BGR24;
>>> +break;
>>
>> this possibly breaks decoding of
>> checkerboard_1080p_nuke_bigendian_8bit_noalpha.dpx
>> the cross in the middle is displayed as cyan while the other samples
>> have it yellow
>
> And DLAD_8b_3c_big.dpx has the reverse :-(
>
> I don't know what additional information is missing to correctly
> decode them, nor if it's an encoder bug.
>
> Note: -1994 spec is marked as V1.0 and -2003 one as V2.0, but both
> specify the scan line boundary thing.

So I dug a bit more and tried to compare the data. In all cases, image
data starts at 0x2000.

In the following, XX is just a placeholder for alignment/readability purpose.
BE RGB24: 94 95 94 XX 95 94 95 XX 94 95 94 XX 95 94 95 XX 94 95 95 95
LE RGB24: 94 95 94 XX 95 94 95 XX 94 95 94 XX 95 95 95 XX 95 94 95 94
BE RGBA:  95 94 95 00 94 95 94 00 95 94 95 00 94 95 94 00
LE RGBA:  95 95 95 00 94 95 95 00 95 94 94 00 94 95 95 00

Are those files supposed to be the same data? The RGB24 and RGBA
versions do not match. When comparing a LE and a BE version, the
pixels do not seem to match either. How come BE/LE RGBA start with the
same data for 12 bytes, but then diverge, if they are of opposite
endianness?

Am I missing something or are those files somewhat broken anyway? Case
in point, the reading code doesn't account for endianness and always
goes through av_image_copy_plane, for all 4 images.

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

Re: [FFmpeg-devel] Invitation to VDD and registration

On Sat, Aug 16, 2014 at 09:48:18AM +0200, Jean-Baptiste Kempf wrote:
> On 16 Aug, Michael Niedermayer wrote :
> > On Sat, Aug 16, 2014 at 03:48:53AM +0200, Jean-Baptiste Kempf wrote:
> > > On 16 Aug, Michael Niedermayer wrote :
> > > > I had not intended to come to VDD and reading this
> > > > https://lists.debian.org/debian-devel/2014/08/msg00478.html
> > > > 
> > > > I definitively will not come to VDD, as it would just be wasted time,
> > > 
> > > That's an easy excuse.
> > 
> > Is it ?
> 
> Yes, it is.
> 
> As you might have seen, it's named VideoLAN Dev Days, not FFmpeg Dev
> Days or libav Dev Days. As you know very well, many multimedia projects
> came, from KDE to GNOME, to gst, to MPlayer! folks and people came from all
> around the world. Also big companies that are using the core multimedia
> libraries. And it's always gone well, without any incident.
> 
> Maybe you should ask yourself why isn't FFmpeg the center of the
> community, and why aren't people coming to the FFmpeg dev days, while it's
> probably 10x more used than VideoLAN software.
> And maybe you will start growing up and change your attitude.
> 
> The multimedia community does not evolve only around your forks, and
> everybody from the multimedia open source community is ashamed of the
> situation and your attitudes...
> 
> The VideoLAN Dev Days is done for people to speak about what the magic
> they are doing on a technical level for the multimedia open source
> community; magic that is used all around the world, all the time. It's
> also done for people to meet each other. It's not done for, and it's never
> been focused on your childish fights.
> 
> Your email is insulting and your attitude is disgusting.

Iam very confused by what you say. This is definitively not what i
meant.
VDD is a great thing for thouse who like meetings and conferences.
And iam very happy that you organize it and all the people from
different projects come there and have fun and talk with each other.
And i very much would want all multimedia developers to go there and
meet each other as well as people from FFmpeg, Videolan, libav and
all other projects if they like such meetings.

But iam not a conference / meeting / party / traveller guy. I really
dislike going to anything like that. That has nothing to do with it
being VDD or something entirely different.
It certainly doesnt revolve around FFmpeg and Libav but thats the
context in which ive been asked to come there by people.

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

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


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

Re: [FFmpeg-devel] [PATCH 4/7] avformat/thp: dont mix integers with pointers

On Sat, Aug 16, 2014 at 10:21:57AM +0200, Paul B Mahol wrote:
> On 8/16/14, Michael Niedermayer  wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/thp.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/thp.c b/libavformat/thp.c
> > index bc4f0daf..714cec6 100644
> > --- a/libavformat/thp.c
> > +++ b/libavformat/thp.c
> > @@ -98,7 +98,7 @@ static int thp_read_header(AVFormatContext *s)
> >
> >  for (i = 0; i < thp->compcount; i++) {
> >  if (thp->components[i] == 0) {
> > -if (thp->vst != 0)
> > +if (thp->vst)
> >  break;
> >
> >  /* Video component.  */
> > --
> > 1.7.9.5
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> ok

applied

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

[FFmpeg-devel] [PATCH]Fix remote ffprobe fate tests

2014-08-16 Thread Carl Eugen Hoyos


Hi!

I cannot really test but I hope attached patch fixes the remaining fate 
tests that don't work on remote fate targets.


Please review and push, Carl EugenFrom 5c2e7283bb1db659246da10d6f1f078123497207 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 16 Aug 2014 12:19:05 +0200
Subject: [PATCH] fate: Fix ffprobe tests with --target-path set.

---
 tests/Makefile | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/Makefile b/tests/Makefile
index dd015ed..07557f9 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -36,10 +36,14 @@ tests/data/vsynth2.yuv: tests/rotozoom$(HOSTEXESUF) | tests/data
 tests/data/vsynth3.yuv: tests/videogen$(HOSTEXESUF) | tests/data
 	$(M)$< $@ $(FATEW) $(FATEH)
 
-tests/data/ffprobe-test.nut: ffmpeg$(EXESUF) | tests/data
+tests/test.ffmeta: TAG = COPY
+tests/test.ffmeta:
+	$(M)cp -f $(SRC_PATH)/tests/test.ffmeta $(TARGET_PATH)/tests/test.ffmeta
+
+tests/data/ffprobe-test.nut: ffmpeg$(EXESUF) | tests/data tests/test.ffmeta
 	$(M)$(TARGET_EXEC) ./$< \
 -f lavfi -i "aevalsrc=sin(400*PI*2*t):d=0.125[out0]; testsrc=d=0.125[out1]; testsrc=s=100x100:d=0.125[out2]" \
--f ffmetadata -i $(SRC_PATH)/tests/test.ffmeta \
+-f ffmetadata -i $(TARGET_PATH)/tests/test.ffmeta \
 -flags +bitexact -map 0:0 -map 0:1 -map 0:2 -map_metadata 1 \
 -map_metadata:s:0 1:s:0 -map_metadata:s:1 1:s:1 \
 -vcodec rawvideo -acodec pcm_s16le \
-- 
1.8.4.5

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

Re: [FFmpeg-devel] [PATCH 3/4] dict.c: Free non-strduped av_dict_set arguments on error.

On Mon, Aug 11, 2014 at 10:11:59PM +0200, wm4 wrote:
> On Mon, 11 Aug 2014 21:17:18 +0200
> Reimar Döffinger  wrote:
> 
> > Unfortunately this was not explicitly documented and thus
> > might be very risky.
> > But basically all uses I saw in FFmpeg had a memleak in these
> > cases.
> 
> It's the more convenient behavior, although on the other hand it feels
> wrong to change the input data on error.
> 
> This makes me wonder, isn't AV_DICT_DONT_STRDUP_* too obscure and too
> much of a microoptimization, that we have to risk retro-guessing these
> subtle semantics?

That is kind of the point: With the behaviour I propose, it is actually
really convenient to use.
Because it means you can just push av_asprintf into it and forget about
it.
If we instead just removed AV_DICT_DONT_STRDUP_* you end up with having
to put it in a variable and then free it afterwards.
Which is what I have seen some code do (the only code that does not have
a memleak), and it's rather a lot of clutter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] dict.c: Free non-strduped av_dict_set arguments on error.

On Wed, Aug 13, 2014 at 01:57:56PM +0200, Michael Niedermayer wrote:
> On Mon, Aug 11, 2014 at 09:17:18PM +0200, Reimar Döffinger wrote:
> > Unfortunately this was not explicitly documented and thus
> > might be very risky.
> 
> yes
> 
> maybe a AV_DICT_FREE_ARGS_ON_ERROR could be used, but its not as
> convenient as getting the behavior by default

That would add a lot of clutter and make it more inconvenient to use
and likely to be forgotten.
I also honestly see no real use-case for not setting it.
One way to solve this would be to deprecate AV_DICT_DONT_STRDUP_KEY/
AV_DICT_DONT_STRDUP_VAL, warning that they fail to free on error
and then add new values, e.g. AV_DICT_OWN_KEY (better suggestions?)
with the new behaviour.
Will still be a bit of a pain to replace all uses in FFmpeg, but
manageable.
What do you think? Better suggestions?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

On Sat, Aug 16, 2014 at 11:39:44AM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2014-08-14 11:48 GMT+02:00 Christophe Gisquet :
> > Hi,
> >
> > 2014-08-14 5:01 GMT+02:00 Michael Niedermayer :
> >> On Wed, Aug 13, 2014 at 10:21:54AM +, Christophe Gisquet wrote:
> >>>  case 50081:
> >>> +avctx->pix_fmt = AV_PIX_FMT_BGR24;
> >>> +break;
> >>
> >> this possibly breaks decoding of
> >> checkerboard_1080p_nuke_bigendian_8bit_noalpha.dpx
> >> the cross in the middle is displayed as cyan while the other samples
> >> have it yellow
> >
> > And DLAD_8b_3c_big.dpx has the reverse :-(
> >
> > I don't know what additional information is missing to correctly
> > decode them, nor if it's an encoder bug.
> >
> > Note: -1994 spec is marked as V1.0 and -2003 one as V2.0, but both
> > specify the scan line boundary thing.
> 
> So I dug a bit more and tried to compare the data. In all cases, image
> data starts at 0x2000.
> 
> In the following, XX is just a placeholder for alignment/readability purpose.
> BE RGB24: 94 95 94 XX 95 94 95 XX 94 95 94 XX 95 94 95 XX 94 95 95 95
> LE RGB24: 94 95 94 XX 95 94 95 XX 94 95 94 XX 95 95 95 XX 95 94 95 94
> BE RGBA:  95 94 95 00 94 95 94 00 95 94 95 00 94 95 94 00
> LE RGBA:  95 95 95 00 94 95 95 00 95 94 94 00 94 95 95 00
> 
> Are those files supposed to be the same data? The RGB24 and RGBA

i did not create these files, so i dont know.
but theres a txt file that says this:

all the samples in this archive were created by the software Nuke from 
TheFoundry (http://www.thefoundry.co.uk/products/nuke/).
they cover all the possible variations of the following settings that Nuke 
offers:

- 8/10/12/16 bit
- big endian / little endian
- with alpha / without alpha

i offered those files to Georg Lippitsch in the thread "[PATCH] dpx: fix 
some stupid typos" on the ffmpeg-devel mailing list to help him work on the dpx 
decoder. but they will hopefully be useful for other developers, too.

in case of any issues/questions regarding this upload, just drop me a mail: 
hol...@celluloid-vfx.com

i added hoger to the CC


> versions do not match. When comparing a LE and a BE version, the
> pixels do not seem to match either. How come BE/LE RGBA start with the
> same data for 12 bytes, but then diverge, if they are of opposite
> endianness?
> 
> Am I missing something or are those files somewhat broken anyway? Case
> in point, the reading code doesn't account for endianness and always
> goes through av_image_copy_plane, for all 4 images.



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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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] dict.c: Free non-strduped av_dict_set arguments on error.

On Mon, Aug 11, 2014 at 09:17:18PM +0200, Reimar Döffinger wrote:
> Unfortunately this was not explicitly documented and thus
> might be very risky.
> But basically all uses I saw in FFmpeg had a memleak in these
> cases.

All others pushed, this one still needs some discussion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Invitation to VDD and registration

2014-08-16 Thread compn

On Sat, 16 Aug 2014 05:16:09 +0200
Michael Niedermayer  wrote:

> I do want to resolve this, and i think if for example libav developers
> and ffmpeg developers would each say "shit happened, we all made
> mistakes" thats a start from which i think projects could be reunited.

diego said those exact words to me during vdd13.
maybe its time to say those things publically ? 

> But from this, the best that one can get is some entertainment, the
> worst is depression, tears and further alieanated developers.

i think a lot of people have trouble moving forward from the past.

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

Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

2014-08-16 Thread Christophe Gisquet

Hi,

2014-08-16 12:51 GMT+02:00 Michael Niedermayer :
> On Sat, Aug 16, 2014 at 11:39:44AM +0200, Christophe Gisquet wrote:
[...]
> i added hoger to the CC

Yes, I read that file. I sent minutes after my previous mail inquiries
to various DPX users/developers I've seen through the
files/mails/bugreports. You should also have received this mail.

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

Re: [FFmpeg-devel] [PATCH 2/7] avcodec/dvdsubdec: Dont mix integers with pointers

On 2014-08-16 01:15, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dvdsubdec.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Fine, clearly a pointer.





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

Re: [FFmpeg-devel] [PATCH 3/7] avcodec/dvbsubdec: dont mix integers with pointers

On 2014-08-16 01:15, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dvbsubdec.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Fine, both pointers.




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

Re: [FFmpeg-devel] [PATCH 5/7] avformat/udp: dont mix integers with pointers

On 2014-08-16 01:15, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/udp.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index a8baa5b..8412eeb 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -313,7 +313,7 @@ static int udp_set_url(struct sockaddr_storage *addr,
>  int addr_len;
>  
>  res0 = udp_resolve_host(hostname, port, SOCK_DGRAM, AF_UNSPEC, 0);
> -if (res0 == 0) return AVERROR(EIO);
> +if (!res0) return AVERROR(EIO);
>  memcpy(addr, res0->ai_addr, res0->ai_addrlen);
>  addr_len = res0->ai_addrlen;
>  freeaddrinfo(res0);

fine

> @@ -332,7 +332,7 @@ static int udp_socket_create(UDPContext *s, struct 
> sockaddr_storage *addr,
>  family = ((struct sockaddr *) &s->dest_addr)->sa_family;
>  res0 = udp_resolve_host(localaddr[0] ? localaddr : NULL, s->local_port,
>  SOCK_DGRAM, family, AI_PASSIVE);
> -if (res0 == 0)
> +if (!res0)
>  goto fail;
>  for (res = res0; res; res=res->ai_next) {
>  udp_fd = ff_socket(res->ai_family, SOCK_DGRAM, 0);
> 

also fine.

Plus you might be able to get rid of the assignment to NULL at the start
of this function (I don't know what best coding practice says should be
done here).



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

Re: [FFmpeg-devel] [PATCH 6/7] avcodec/hevc_mvs: dont redundantly initialize ref_idx_curr

On 2014-08-16 01:15, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/hevc_mvs.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

fine




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

Re: [FFmpeg-devel] [PATCH 7/7] avcodec/mips/compute_antialias_float: remove unused variable

On 2014-08-16 01:15, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mips/compute_antialias_float.h |3 ---
>  1 file changed, 3 deletions(-)

It is unused so that is fine.





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

Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

2014-08-16 Thread Jean First


On Sat Aug 16 2014 13:57:16 GMT+0200 (CEST), Christophe Gisquet wrote:

Hi,

2014-08-16 12:51 GMT+02:00 Michael Niedermayer :

On Sat, Aug 16, 2014 at 11:39:44AM +0200, Christophe Gisquet wrote:

[...]

i added hoger to the CC

Yes, I read that file. I sent minutes after my previous mail inquiries
to various DPX users/developers I've seen through the
files/mails/bugreports. You should also have received this mail.


Hi,

I just created various dpx samples with the same settings in Nuke and 
added the source jpg as reference. I hope I got all the options right.


You can download them form 
https://www.dropbox.com/sh/xffmx9tmjhfew86/AAAqx0sxwsPyVSmTDcW6aEe9a


Maybe it is easier to see the difference in pixels, if the values are 
not too similar.


According to nuke, the first pixel should have a value of:
8 bit r: 197, g: 111, b: 76, a: 255
10 bit r: 790, g: 445, b: 305, a: 1023
12 bit r: 3164, g: 1783, b: 1220, a: 4095
16 bit r: 50629, g: 28527, b: 19532, a: 65535

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

Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing

2014-08-16 Thread Clément Bœsch

On Fri, Aug 15, 2014 at 06:49:39AM +, Carl Eugen Hoyos wrote:
[...]
> > But really that's insane, because I know you will 
> > end-up hardcoding all kind of linker flags to 
> > these fallback calls,
> 
> Yes, some external libraries that never have 
> additional dependencies currently depend on pkg-config.
> 
> > and this defeat completely the purpose of such 
> > simplified code.
> 
> I thought the purpose is to allow educated developers 
> to use pkg-config while (uneducated) users (like me) 
> will not understand how this is easier than using 
> configure parameters.

Yes, it's also simpler for the users.

> 
> > They will also almost never be tested,
> 
> I will care about the testing.

Well, you probably won't test static linking of random libs on various
platforms typically.

pkg-config makes possible to completely ignore that part since it moves
the responsibility away from us.

That said, if you want to support a fallback as I suggested above, it
won't work as you expect:if you want to link with your custom flags and be
sure not to have pkg-config taking over your parameters (basically linking
to the system package instead of the one you specified through custom link
flags).

[...]

-- 
Clément B.

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

Re: [FFmpeg-devel] [PATCH] mpegts: always parse pcr

2014-08-16 Thread Marton Balint



On Sun, 10 Aug 2014, Marton Balint wrote:


Previously pcr transmitted without payload but as part of the video stream was
not parsed.

Signed-off-by: Marton Balint 
---
libavformat/mpegts.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)



Hello Michael,

Please merge from my stable branch for this patch.

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

Re: [FFmpeg-devel] Invitation to VDD and registration

> do you think me, the rest of the FFmpeg and Libav developers sitting
> together and people accusing each other of theft and lies. Would lead
> to improved relations ?

You perhaps fail to realise since you've never done it before that
there's vastly less of these long, stupid historical tales when
speaking in person. This is mainly because everyone has heard both
sides of the story a trillion times and frankly would rather do
something productive than hear another persons account of history.

Look how many stories there are of FFmpeg and Libav people having
friendly conversation at VDD in this thread alone. Have you ever done
this before in the last 3 years? If you want to have this "shit
happens, let's move" on discussion, do you seriously think it can be
done online? Look at the monumental success of this thread...

If you actually want to act like a real leader and even move in the
right direction towards solving this issue the only way forward is for
you to be at VDD, whether you find it an enjoyable experience or not.
Do you think anyone likes sitting in a room with a lot of strong
personalities and discussing difficult topics? No, but they are
willing to come to the table unlike almost every attempt you make at
"compromise" which basically involves saying "do things my way". The
world doesn't work like that.

Whether you like it or not these problems are social issues (cf VDD11)
and they will require a social solution. You are the blocking factor
and everyone knows it and we say it every VDD.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/7] avcodec/dvdsubdec: Dont mix integers with pointers

On Sat, Aug 16, 2014 at 02:53:45PM +0200, James Darnley wrote:
> On 2014-08-16 01:15, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/dvdsubdec.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Fine, clearly a pointer.

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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 5/7] avformat/udp: dont mix integers with pointers

On Sat, Aug 16, 2014 at 03:00:32PM +0200, James Darnley wrote:
> On 2014-08-16 01:15, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/udp.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > index a8baa5b..8412eeb 100644
> > --- a/libavformat/udp.c
> > +++ b/libavformat/udp.c
> > @@ -313,7 +313,7 @@ static int udp_set_url(struct sockaddr_storage *addr,
> >  int addr_len;
> >  
> >  res0 = udp_resolve_host(hostname, port, SOCK_DGRAM, AF_UNSPEC, 0);
> > -if (res0 == 0) return AVERROR(EIO);
> > +if (!res0) return AVERROR(EIO);
> >  memcpy(addr, res0->ai_addr, res0->ai_addrlen);
> >  addr_len = res0->ai_addrlen;
> >  freeaddrinfo(res0);
> 
> fine
> 
> > @@ -332,7 +332,7 @@ static int udp_socket_create(UDPContext *s, struct 
> > sockaddr_storage *addr,
> >  family = ((struct sockaddr *) &s->dest_addr)->sa_family;
> >  res0 = udp_resolve_host(localaddr[0] ? localaddr : NULL, s->local_port,
> >  SOCK_DGRAM, family, AI_PASSIVE);
> > -if (res0 == 0)
> > +if (!res0)
> >  goto fail;
> >  for (res = res0; res; res=res->ai_next) {
> >  udp_fd = ff_socket(res->ai_family, SOCK_DGRAM, 0);
> > 
> 
> also fine.

applied


> 
> Plus you might be able to get rid of the assignment to NULL at the start
> of this function (I don't know what best coding practice says should be
> done here).

removed assignment

thx

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

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please


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/7] avcodec/dvbsubdec: dont mix integers with pointers

On Sat, Aug 16, 2014 at 02:55:44PM +0200, James Darnley wrote:
> On 2014-08-16 01:15, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/dvbsubdec.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Fine, both pointers.

applied

thx

[...]

-- 
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 7/7] avcodec/mips/compute_antialias_float: remove unused variable

On Sat, Aug 16, 2014 at 03:04:04PM +0200, James Darnley wrote:
> On 2014-08-16 01:15, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/mips/compute_antialias_float.h |3 ---
> >  1 file changed, 3 deletions(-)
> 
> It is unused so that is fine.

applied


thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] [PATCH 6/7] avcodec/hevc_mvs: dont redundantly initialize ref_idx_curr

On Sat, Aug 16, 2014 at 03:02:08PM +0200, James Darnley wrote:
> On 2014-08-16 01:15, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/hevc_mvs.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> 
> fine

applied

thx

[...]

-- 
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] Invitation to VDD and registration

On Sat, Aug 16, 2014 at 02:36:00PM +0100, Kieran Kunhya wrote:
> > do you think me, the rest of the FFmpeg and Libav developers sitting
> > together and people accusing each other of theft and lies. Would lead
> > to improved relations ?
> 
> You perhaps fail to realise since you've never done it before that
> there's vastly less of these long, stupid historical tales when
> speaking in person. This is mainly because everyone has heard both
> sides of the story a trillion times and frankly would rather do
> something productive than hear another persons account of history.
> 
> Look how many stories there are of FFmpeg and Libav people having
> friendly conversation at VDD in this thread alone. Have you ever done
> this before in the last 3 years? If you want to have this "shit
> happens, let's move" on discussion, do you seriously think it can be
> done online? Look at the monumental success of this thread...
> 
> If you actually want to act like a real leader and even move in the
> right direction towards solving this issue the only way forward is for
> you to be at VDD, whether you find it an enjoyable experience or not.
> Do you think anyone likes sitting in a room with a lot of strong
> personalities and discussing difficult topics? No, but they are
> willing to come to the table unlike almost every attempt you make at
> "compromise" which basically involves saying "do things my way". The
> world doesn't work like that.
> 
> Whether you like it or not these problems are social issues (cf VDD11)
> and they will require a social solution. You are the blocking factor
> and everyone knows it and we say it every VDD.

like i said, iam happy to resign, if that reunites the projects and
resolves the problems
how can my resignation not be enough, if as you say iam the blocking
factor ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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] dpx: fix endianess for RGB 8bits

On Sat, Aug 16, 2014 at 01:57:16PM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2014-08-16 12:51 GMT+02:00 Michael Niedermayer :
> > On Sat, Aug 16, 2014 at 11:39:44AM +0200, Christophe Gisquet wrote:
> [...]
> > i added hoger to the CC
> 
> Yes, I read that file. I sent minutes after my previous mail inquiries
> to various DPX users/developers I've seen through the
> files/mails/bugreports. You should also have received this mail.

yes, i hadnt looked at my inbox yet, when i wrote my reply

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

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


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

Re: [FFmpeg-devel] Invitation to VDD and registration

> like i said, iam happy to resign, if that reunites the projects and
> resolves the problems
> how can my resignation not be enough, if as you say iam the blocking
> factor ?

You impose conditions on your resignation.

And wow, you'd rather resign than meet in person...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Fix remote ffprobe fate tests

2014-08-16 Thread Paul B Mahol

On 8/16/14, Carl Eugen Hoyos  wrote:
> Hi!
>
> I cannot really test but I hope attached patch fixes the remaining fate
> tests that don't work on remote fate targets.
>
> Please review and push, Carl Eugen

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

Re: [FFmpeg-devel] Invitation to VDD and registration

2014-08-16 Thread Clément Bœsch

On Sat, Aug 16, 2014 at 02:36:00PM +0100, Kieran Kunhya wrote:
[...]
> Whether you like it or not these problems are social issues (cf VDD11)
> and they will require a social solution. You are the blocking factor
> and everyone knows it and we say it every VDD.

I'm too lazy to make a long mail to share my point on the subject, so I'll just
leave that here, I hope no one mind:

<@ubitux> kierank: i doubt michael going to a vdd or something will actually 
make any positive change
<@ubitux> i'm sure you'd love to have an oral fight, but it makes very little 
sense 
<@ubitux> libav people are very used to such thing (they are basically the 
people who represented ffmpeg in the past in real-life meetings)
<@ubitux> and even if you have the best neutral mediator in the fight, it makes 
no difference
<@ubitux> people not comfortable with "the oral medium" don't stand a chance, 
at all
<@ubitux> and even if it's the case, absolutely no additional information will 
be transmitted
<@ubitux> and only "feelings" will be remembered from that talk
<@ubitux> like "lol  totally clashed ", "it was an awesome discussion" or 
stuff like that
<@ubitux> on a personnal note, real life meetings are boring as hell, and IMO 
never actually helped much
<@ubitux> the only benefits i see to such things are: put faces on nicknames, 
and communicate with corp who are too clumsy (or whatever reason) to use IRC or 
mails
<+nevcairiel> most people that insist on them are those that know that they are 
more experienced and comfortable with them, and hope to win the argument that 
way
<@ubitux> and used it as an argument later "we made monty admit ogg sucks IRL!!"
<@ubitux> without any actual trace of anything
<@kurosu_> Michael attending would be a good thing, but he would already have 
if he hadn't a major issue with it
<@kurosu_> What if he is agoraphobic or anything that would make such a public 
event an actual pain to him ?
<@ubitux> you don't need to have social anxiety for seeing only threat in going 
to such place
<@kurosu_> He may also *not* want to speak about it
<@ubitux> real life is the land of hypocrisy ;)
<@kurosu_> yeah, I'm just stating that people are trying to get him to come, 
while his absence is not a ploy/laziness but a much more serious issue
<@kurosu_> *may not be
<@kurosu_> kierank, BBB: not blaming you at all for suggesting this, but please 
consider that other viewpoint (potentially rhetorical)
<@ubitux> libav banned him from irc & mails to avoid the most they can any 
communication with him
<+nevcairiel> i smiled at the comment in the mail thread about chatting happily 
until a certain libav developer came around
<@ubitux> it's obvious that requesting for a real-life meeting is interpreted 
as a ploy
<@ubitux> nevcairiel: hahaha i actually was there at that time
<@ubitux> i didn't really understood why people suddenly stopped talking first, 
but then as i really love awkward situation like this i made sure to stay silent
<@kurosu_> handling conflict face-to-face is difficult
<@ubitux> what kierank suggest is probably in the spirit of smoothing 
relationship with random talks
<@ubitux> but it's really boring as hell and makes absolutely no difference on 
the technical matters
<@ubitux> and for people who only care about that, it's an insane waste of time

This is extracted from #ffmpeg-devel log from Aug 13 2014

People with social issues such that they can't have a technical discussion
should just get over it, or use any group therapy they want. What matters for a
project and its users is the technical argument.  It shouldn't come as a
surprise that a leader prioritizes this over anything else. The social aspect
should IMO not overlap over the technical one.

Social people not having any empathy for non-social ones really is a joke.

-- 
Clément B.

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

Re: [FFmpeg-devel] Invitation to VDD and registration

On Sat, 16 Aug 2014 15:12:55 +0100
Kieran Kunhya  wrote:

> > like i said, iam happy to resign, if that reunites the projects and
> > resolves the problems
> > how can my resignation not be enough, if as you say iam the blocking
> > factor ?
> 
> You impose conditions on your resignation.

We probably had this a dozens of times, but which are these? Would be
nice if Michael could make this explicit.

> And wow, you'd rather resign than meet in person...

Not sure if these necessarily have to do with each other... and I'm
pretty damn sure Libav wouldn't ever accept a leadership by him.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Invitation to VDD and registration

> The social aspect
> should IMO not overlap over the technical one.

Problems with the way people behave are social problems...
In an ideal world yes, all the disagreements could be technical but in
reality they are sadly not all technical.

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

Re: [FFmpeg-devel] Invitation to VDD and registration

On Sat, Aug 16, 2014 at 04:29:13PM +0200, wm4 wrote:
> On Sat, 16 Aug 2014 15:12:55 +0100
> Kieran Kunhya  wrote:
> 
> > > like i said, iam happy to resign, if that reunites the projects and
> > > resolves the problems
> > > how can my resignation not be enough, if as you say iam the blocking
> > > factor ?
> > 
> > You impose conditions on your resignation.
> 
> We probably had this a dozens of times, but which are these? Would be
> nice if Michael could make this explicit.

in the end, there really are none.
FFmpeg is a project driven by its community, its that community which
must live with and under the conditions.

I just think that it would be bad if developers could block others
work and there was nothing that could deal with that.
one can say this in many different ways each havng a subtile different
effect, like
That authors and people actively maintaining some code cant be blocked
by people who are neither authors nor actively maintaining the code
in question.

Its all supposed to achive the same thing, ive no idea which, if any
makes most sense

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

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

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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
> Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
> can be configured to automatically invite the right people for review
> based on the changed path. We recently migrated to Gerrit at the
> Wireshark project and it helps a lot in coordinating the reviews.

I am afraid this discussion on "Gerrit" or other similar tools is pointless:
this is trying to solve a human problem with technical means: it never
works.

Actually, I believe all this peer-review business to be a red herring. On
the FFmpeg side, most patches except the very simple ones are sent to the
mailing-list for peer-review, even patches by people with commit rights
working on their own code; they do so not because a rule states they have
too but because this is the best thing to achieve good code. On the other
hand, I remember having seen patches somewhat rushed through the mandatory
review on libav-devel and applied when someone else still had remarks; I
have not kept tabs on that though.

The real issue between the mandatory peer-review on the mailing-list is,
IMHO, control of the project orientation. Not "is this patch correct?" but
"do we want this patch?".

If you are involved in the project, it is very obvious that both branches
have rather opposed views on the project orientation: libav has made a point
of trimming "unnecessary" features and rejecting new ones while FFmpeg kept
them and added some.

A few examples:

* Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
  message said "appears simpler to write a new replacement from scratch",
  but in the meantime, users are left without the feature.

* Libav removed the framerate detection code, FFmpeg built on it to handle
  it in filtering too. I do not find them right now, but I have found a few
  files that avconv wanted to encode at an insane frame rate while ffmpeg
  correctly guessed; and right now, -vf fps does not work alone with very
  common formats in avconv.

* Libav removed the keyboard interaction ("Press [q] to stop") while FFmpeg
  extended it.

Beyond these obvious cases, FFmpeg has gained quite a few features that, I
am pretty certain of it, would not have been accepted into libav: the concat
demuxer (has been called "hack" on the mailing-lists IIRC), the lavfi
sources made for testing, support for some obscure format through an
external library, subtitles hard-burning, etc.

The most galling in this issue is that there is no clear decision behind
this orientation. The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the commit rights are few and of a common mind, they can just give the cold
shoulder to proposed changes that do not suit their personal view of the
project.

Considering these differences in policy, I do not believe the fork can be
merged. Speaking as someone who proposed a few of these "unnecessary"
features, because they were fun or immediately useful, I would not like to
work on a project that would reject them by principle. But I can recognize,
for someone who needs "serious professional" software, the need of working
on something driven with a firmer hand.


Having a fork is not inherently bad, and it becomes necessary when people
have different views for the orientation of the projects.

It becomes bad when people not involved in the project start to suffer from
the consequences of the fork. This is what is happening here, for two
reasons:

* distributions adopting one side of the fork for non-technical reasons;

* one side of the fork not caring about compatibility with the other side.

Of course, these reasons are interconnected.

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] Invitation to VDD and registration

Le nonidi 29 thermidor, an CCXXII, Clément Bœsch a écrit :
> <+nevcairiel> most people that insist on them are those that know that
> they are more experienced and comfortable with them, and hope to win the
> argument that way

As someone not much at ease with socializing, I can only concur.

And do not forget the language barrier: when writing a mail, there is as
much time as necessary to find words. IRL, the people struggling to find
their words are at a clear disadvantage.

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] Invitation to VDD and registration

Le sextidi 26 thermidor, an CCXXII, Stefano Sabatini a écrit :
> anybody is planning to go there? I remember that the registration will
> close on August 20 (that is, the next week Wednesday), bye.

I intend to be there; I have already registered. I have not yet booked a
flight as I must wait for my work schedule; as I am not familiar with that
kind of procedure, any advice (for a flight from Paris) would be
appreciated.

See you there.

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] Reintroducing FFmpeg to Debian

Le septidi 27 thermidor, an CCXXII, Thomas Goirand a écrit :
>   If you guys could find a solution to try to work together
> again, and merge back both projects, that'd be best for everyone.

When people suggest that, I always wonder how they see that happening with
regard to the code.

In more than three years since the fork, development has continued on both
branches. Changes are continuously ported from libav to FFmpeg, but code was
also written for FFmpeg and never merged by libav. Some of this code, the
libav people have made very clear they specifically did not want it.

So what about the code? Shall the FFmpeg developers discard three years of
work and start working on libav? Or shall the libav developers accept to
work with the code from FFmpeg that they do not like?

I see neither as an option.

The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.

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] Reintroducing FFmpeg to Debian

2014-08-16 Thread Thomas Goirand

On 08/15/2014 11:53 PM, The Wanderer wrote:
> It's also something the Linux kernel is still doing, with apparent
> success.

Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using git-review and gerrit is so much better.

> I for one consider it to be a much more public, transparent, and
> discoverable way to let proposed patches and the review of same be open
> to public view, compared to the way various other projects seem to do
> it.
> 
> Making sure everything passes through the mailing list, and most if not
> all substantive discussion happens on the mailing list, is a lot better
> than having some discussion on the mailing lists and some on a bug
> tracker and some on IRC and some via private mail and so on. (The most
> ridiculously extreme example of this fragmentation that I know of is
> probably the Mozilla project.)

This reasoning may work when you have only a small amount of information
to read. When you are overwhelmed with it, having different places to do
different things is a much better approach. Sending patches to a list
simply doesn't scale.

Also, with a list, it's not convenient at all to point out a line in a
patch in a mailing list. You must extract the relevant lines, cut/past
them, and comment them. Instead, double clicking on the line of the
patch which is displayed on a web interface is much more convenient.

> There's nothing wrong with having discussion in those various areas, of
> course; it's probably inevitable, and it's even a good thing. It's just
> that it's a lot harder for someone not intimately involved with the
> project to follow discussion if it happens in such a variety of places,
> and there's value to be found in making sure that everything passes
> through one central (discussion-enabled) point before landing.

Lists are good tools for discussing where a project should go, release
goals, and so on. They aren't good tools to do patch reviews. I've used
both, and I'm convinced of that.

Thomas Goirand (zigo)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On Sat, 16 Aug 2014 23:29:56 +0800
Thomas Goirand  wrote:

> On 08/15/2014 11:53 PM, The Wanderer wrote:
> > It's also something the Linux kernel is still doing, with apparent
> > success.
> 
> Yes, the Linux kernel is a successful project. Does this mean using a
> list for reviewing patches is a good thing? No! The workflow with a list
> is simply horrible. Using git-review and gerrit is so much better.
> 
> > I for one consider it to be a much more public, transparent, and
> > discoverable way to let proposed patches and the review of same be open
> > to public view, compared to the way various other projects seem to do
> > it.
> > 
> > Making sure everything passes through the mailing list, and most if not
> > all substantive discussion happens on the mailing list, is a lot better
> > than having some discussion on the mailing lists and some on a bug
> > tracker and some on IRC and some via private mail and so on. (The most
> > ridiculously extreme example of this fragmentation that I know of is
> > probably the Mozilla project.)
> 
> This reasoning may work when you have only a small amount of information
> to read. When you are overwhelmed with it, having different places to do
> different things is a much better approach. Sending patches to a list
> simply doesn't scale.
> 
> Also, with a list, it's not convenient at all to point out a line in a
> patch in a mailing list. You must extract the relevant lines, cut/past
> them, and comment them. Instead, double clicking on the line of the
> patch which is displayed on a web interface is much more convenient.

What? Most patches are posted inline (with git-send-email).
 
> > There's nothing wrong with having discussion in those various areas, of
> > course; it's probably inevitable, and it's even a good thing. It's just
> > that it's a lot harder for someone not intimately involved with the
> > project to follow discussion if it happens in such a variety of places,
> > and there's value to be found in making sure that everything passes
> > through one central (discussion-enabled) point before landing.
> 
> Lists are good tools for discussing where a project should go, release
> goals, and so on. They aren't good tools to do patch reviews. I've used
> both, and I'm convinced of that.

What we need is solving the FFmpeg/Libav split, not "well-meant"
suggestions by outsiders how to change our development model.

> Thomas Goirand (zigo)
> ___
> 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] Reintroducing FFmpeg to Debian

2014-08-16 Thread Pau Garcia i Quiles

On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George  wrote:

> The only option is to make sure the users do not suffer from the fork, by
> making sure they can easily use the version that is most suited for their
> need without being sucked into the developers' disagreements.
>

Can we get back on topic?

With or without libav in Debian, there are solid technical reasons to have
ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although
they parted ways in a civilized way: different library names), and we
certainly have a ton of librarys which provide very similar features.

Since before the fork, the libav developers have been sabotaging ffmpeg as
much as possible, in every "combat field": library names, library versions,
taking distributions hostage (ffmpeg package that installs libav!?), etc.
This is not the way to fork anything. This is a fact. I don't care whether
Michael Nidermayer was a dictator or not. I don't care whether the
code-review rules in libav are better or worse. I don't care what the Linux
kernel does. The only thing I care about is Debian is shipping a
less-capable (i. e. less multimedia formats supported) distribution due to
this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will most
certainly cause binary problems.

If libav and ffmpeg maintainers cannot reach an agreement regarding library
names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian. E.
g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done
in the past.

And before someone mentions it: I don't think it's too late. It's getting
too late because nobody with the right to act is doing anything. In the
end, our users are the ones being harmed and we are left wondering why they
are increasingly moving to other distributions or Mac OS X.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Invitation to VDD and registration

> And do not forget the language barrier: when writing a mail, there is as
> much time as necessary to find words. IRL, the people struggling to find
> their words are at a clear disadvantage.

We can rotate between different languages every ten minutes =p
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] postproc: use av_freep() for saftey

Signed-off-by: Michael Niedermayer 
---
 libpostproc/postprocess.c |   22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
index 794cd30..397e4fb 100644
--- a/libpostproc/postprocess.c
+++ b/libpostproc/postprocess.c
@@ -931,17 +931,17 @@ void pp_free_context(void *vc){
 PPContext *c = (PPContext*)vc;
 int i;
 
-for(i=0; i<3; i++) av_free(c->tempBlurred[i]);
-for(i=0; i<3; i++) av_free(c->tempBlurredPast[i]);
-
-av_free(c->tempBlocks);
-av_free(c->yHistogram);
-av_free(c->tempDst);
-av_free(c->tempSrc);
-av_free(c->deintTemp);
-av_free(c->stdQPTable);
-av_free(c->nonBQPTable);
-av_free(c->forcedQPTable);
+for(i=0; i<3; i++) av_freep(&c->tempBlurred[i]);
+for(i=0; i<3; i++) av_freep(&c->tempBlurredPast[i]);
+
+av_freep(&c->tempBlocks);
+av_freep(&c->yHistogram);
+av_freep(&c->tempDst);
+av_freep(&c->tempSrc);
+av_freep(&c->deintTemp);
+av_freep(&c->stdQPTable);
+av_freep(&c->nonBQPTable);
+av_freep(&c->forcedQPTable);
 
 memset(c, 0, sizeof(PPContext));
 
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 2/2] avformat/movenchint: use av_freep() for saftey

Signed-off-by: Michael Niedermayer 
---
 libavformat/movenchint.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenchint.c b/libavformat/movenchint.c
index 2602254..006aa09 100644
--- a/libavformat/movenchint.c
+++ b/libavformat/movenchint.c
@@ -72,7 +72,7 @@ static void sample_queue_pop(HintSampleQueue *queue)
 if (queue->len <= 0)
 return;
 if (queue->samples[0].own_data)
-av_free(queue->samples[0].data);
+av_freep(&queue->samples[0].data);
 queue->len--;
 memmove(queue->samples, queue->samples + 1, sizeof(HintSample)*queue->len);
 }
@@ -85,7 +85,7 @@ static void sample_queue_free(HintSampleQueue *queue)
 int i;
 for (i = 0; i < queue->len; i++)
 if (queue->samples[i].own_data)
-av_free(queue->samples[i].data);
+av_freep(&queue->samples[i].data);
 av_freep(&queue->samples);
 queue->len  = 0;
 queue->size = 0;
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH]Fix remote ffprobe fate tests

On Sat, Aug 16, 2014 at 04:14:18PM +0200, Paul B Mahol wrote:
> On 8/16/14, Carl Eugen Hoyos  wrote:
> > Hi!
> >
> > I cannot really test but I hope attached patch fixes the remaining fate
> > tests that don't work on remote fate targets.
> >
> > Please review and push, Carl Eugen
> 
> Missing signed-off.

true, cant hurt to add but i think IMHO its not important here

signed-off is primarely important for things related to license
and copyright changes

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] mpegts: always parse pcr

On Sat, Aug 16, 2014 at 03:29:16PM +0200, Marton Balint wrote:
> 
> On Sun, 10 Aug 2014, Marton Balint wrote:
> 
> >Previously pcr transmitted without payload but as part of the video stream 
> >was
> >not parsed.
> >
> >Signed-off-by: Marton Balint 
> >---
> >libavformat/mpegts.c | 12 +---
> >1 file changed, 5 insertions(+), 7 deletions(-)
> >
> 
> Hello Michael,
> 
> Please merge from my stable branch for this patch.

merged

btw, if you want a git write account, send me your public ssh key

thanks

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

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


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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Ivan Kalvachev

On 8/16/14, Pau Garcia i Quiles  wrote:
> On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George  wrote:
>
>
>> The only option is to make sure the users do not suffer from the fork, by
>> making sure they can easily use the version that is most suited for their
>> need without being sucked into the developers' disagreements.
>>
>
> Can we get back on topic?
>
> With or without libav in Debian, there are solid technical reasons to have
> ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although
> they parted ways in a civilized way: different library names), and we
> certainly have a ton of librarys which provide very similar features.
>
> Since before the fork, the libav developers have been sabotaging ffmpeg as
> much as possible, in every "combat field": library names, library versions,
> taking distributions hostage (ffmpeg package that installs libav!?), etc.
> This is not the way to fork anything. This is a fact. I don't care whether
> Michael Nidermayer was a dictator or not. I don't care whether the
> code-review rules in libav are better or worse. I don't care what the Linux
> kernel does. The only thing I care about is Debian is shipping a
> less-capable (i. e. less multimedia formats supported) distribution due to
> this conflict.
>
> This has to stop.
>
> ffmpeg is not yet in Debian due to the filename clashing, which will most
> certainly cause binary problems.
>
> If libav and ffmpeg maintainers cannot reach an agreement regarding library
> names and it's not possible to simply use either ffmpeg or libav
> indistinctly due missing features binary compatibility, etc, the obvious
> solution is that BOTH libav and ffmpeg rename their libraries in Debian. E.
> g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use
> alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done
> in the past.

AFAIK, Andreas' package uses libavcodec-ffmpeg.so .

FFmpeg configure does have option --build-suffix="_ffmpeg" that would
append that suffix to library names and pkg-config files. Since
applications might have problem finding the ffmpeg libraries, the
pkg-config files should be with the old "common" names and this
creates a conflict in the -dev packages.

Libav and FFmpeg can coexist side by side.
There are no conflicts or overlap for binary users.

The current goal of FFmpeg is not replacing Libav.
The current goal is establishing a native presence in the most popular
distribution(s).

I'm quite sure the Security team is full of capable people who can
handle one more package.
FFmpeg takes security seriously.

The best scenario for everybody is:
1. Libav stays and all QA tested programs are not touched.
2. FFmpeg is included in a way that does not obstruct the rest of the ecosystem.
3. Optionally, programs that use _only_ FFmpeg could be included back
in Debian. Optionally.

The inclusion would allow for a real-life estimate to be done of the
FFmpeg performance, security, bug and feature wise.

Only after assessing real-life data, a final decision could be
reached, if there is still demand for such thing.

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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Bálint Réczey

Hi Nicolas,

2014-08-16 17:11 GMT+02:00 Nicolas George :
> L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
>> Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
>> can be configured to automatically invite the right people for review
>> based on the changed path. We recently migrated to Gerrit at the
>> Wireshark project and it helps a lot in coordinating the reviews.
>
> I am afraid this discussion on "Gerrit" or other similar tools is pointless:
> this is trying to solve a human problem with technical means: it never
> works.
I did not want to sell Gerrit over mailing-list discussion because the
work-flow is something which should be chosen by the development team
and not outsiders, but wanted to show that tools can help enforcing
some parts of the work-flow.

On the human problems vs. technical means questions I think we have
different opinions. Technical means are exceptionally great tools for
solving _some_ human problems. If the human problem is being not
satisfied with peers' behavior of not following a specific work-flow a
toll which enforces the work-flow would solve it. Making mistakes is
an other (mostly) human problem and we have lintian for example which
helps pointing them out.

>
> Actually, I believe all this peer-review business to be a red herring. On
> the FFmpeg side, most patches except the very simple ones are sent to the
> mailing-list for peer-review, even patches by people with commit rights
> working on their own code; they do so not because a rule states they have
> too but because this is the best thing to achieve good code. On the other
> hand, I remember having seen patches somewhat rushed through the mandatory
> review on libav-devel and applied when someone else still had remarks; I
> have not kept tabs on that though.
>
> The real issue between the mandatory peer-review on the mailing-list is,
> IMHO, control of the project orientation. Not "is this patch correct?" but
> "do we want this patch?".
>
> If you are involved in the project, it is very obvious that both branches
> have rather opposed views on the project orientation: libav has made a point
> of trimming "unnecessary" features and rejecting new ones while FFmpeg kept
> them and added some.
IMO the trimming/rejecting strategy is not something which would ever
make Libav popular among developers/users and this is how we ended in
the current situation. While Libav's communicated release strategy can
attract integrators and distributions like Debian, FFmpeg attracts
developers/users of software based on Libav/FFmpeg due to more
features.
Sticking to those core strategies the two forks will compete forever
until one of them give up - which I see unlikely to happen voluntarily
- and users will keep complaining about Libav's missing features to
distributions' maintainers where FFmpeg is not packaged.

I think the best way out of this situation would be relaxing the
review requirements on Libav's side and letting not-yet-proven of
FFmpeg features in through an experimental/staging phase. If FFmpeg
devs could collaborate with them this way the two forks could be
converged and finally merged and the combined team could maintain a
lot better media library than the current forks are separately.

Cheers,
Balint

>
> A few examples:
>
> * Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
>   message said "appears simpler to write a new replacement from scratch",
>   but in the meantime, users are left without the feature.
>
> * Libav removed the framerate detection code, FFmpeg built on it to handle
>   it in filtering too. I do not find them right now, but I have found a few
>   files that avconv wanted to encode at an insane frame rate while ffmpeg
>   correctly guessed; and right now, -vf fps does not work alone with very
>   common formats in avconv.
>
> * Libav removed the keyboard interaction ("Press [q] to stop") while FFmpeg
>   extended it.
>
> Beyond these obvious cases, FFmpeg has gained quite a few features that, I
> am pretty certain of it, would not have been accepted into libav: the concat
> demuxer (has been called "hack" on the mailing-lists IIRC), the lavfi
> sources made for testing, support for some obscure format through an
> external library, subtitles hard-burning, etc.
>
> The most galling in this issue is that there is no clear decision behind
> this orientation. The fork's manifesto stated that everyone was equal
> amongst equals, with or without commit rights, but the people who do have
> the commit rights are few and of a common mind, they can just give the cold
> shoulder to proposed changes that do not suit their personal view of the
> project.
>
> Considering these differences in policy, I do not believe the fork can be
> merged. Speaking as someone who proposed a few of these "unnecessary"
> features, because they were fun or immediately useful, I would not like to
> work on a project that would reject them by principle. But I can recognize,
> for

Re: [FFmpeg-devel] [PATCH] avformat/metadata: Implement AVFMT_FLAG_NO_META_CONV

On Mon, 11 Aug 2014 15:15:45 +0300
Mohammad Alsaleh  wrote:

>  Decoders/parsers run ff_metadata_conv() unconditionally. This makes
>  it impossible to retrieve or keep original metadata field names.
> 
>  If one wishes to skip ff_metadata_conv() calls at the decoding/parsing
>  stage. This patch implements AVFMT_FLAG_NO_META_CONV which is set by
>  the decoding fflag opt parameter 'nometaconv'.

Would it make more sense to add a new field to AVFormatContext, that
strictly contains the "original" metadata as stored in the file?

I have no strong feelings about it; just that the metadata replacement
is not always very helpful for some formats.

> Signed-off-by: Mohammad Alsaleh 
> ---
>  doc/APIchanges   |  3 +++
>  doc/formats.texi |  2 ++
>  libavformat/asfdec.c |  3 ++-
>  libavformat/avformat.h   |  1 +
>  libavformat/id3v2.c  | 17 -
>  libavformat/matroskadec.c|  4 +++-
>  libavformat/metadata.c   |  4 
>  libavformat/oggparsevorbis.c |  3 ++-
>  libavformat/options_table.h  |  1 +
>  libavformat/version.h|  2 +-
>  libavformat/wtvdec.c |  3 ++-
>  11 files changed, 33 insertions(+), 10 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index b7961ae..854563a 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2014-08-09
>  
>  API changes, most recent first:
>  
> +2014-08-xx - xxx - lavf 56.1.100 - avformat.h
> +  Add AVFMT_FLAG_NO_META_CONV.
> +
>  2014-04-xx - xxx - lavr 2.1.0 - avresample.h
>Add avresample_convert_frame() and avresample_config().
>  
> diff --git a/doc/formats.texi b/doc/formats.texi
> index 027510e..92c079d 100644
> --- a/doc/formats.texi
> +++ b/doc/formats.texi
> @@ -51,6 +51,8 @@ Discard corrupted frames.
>  Try to interleave output packets by DTS.
>  @item keepside
>  Do not merge side data.
> +@item nometaconv
> +Skip conversion of metadata field names.
>  @item latm
>  Enable RTP MP4A-LATM payload.
>  @item nobuffer
> diff --git a/libavformat/asfdec.c b/libavformat/asfdec.c
> index 5fc293e..13c7806 100644
> --- a/libavformat/asfdec.c
> +++ b/libavformat/asfdec.c
> @@ -862,7 +862,8 @@ static int asf_read_header(AVFormatContext *s)
>  }
>  }
>  
> -ff_metadata_conv(&s->metadata, NULL, ff_asf_metadata_conv);
> +if (!(s->flags & AVFMT_FLAG_NO_META_CONV))
> +ff_metadata_conv(&s->metadata, NULL, ff_asf_metadata_conv);
>  
>  return 0;
>  }
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index a4f7ed7..12fba94 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1287,6 +1287,7 @@ typedef struct AVFormatContext {
>  #define AVFMT_FLAG_SORT_DTS0x1 ///< try to interleave outputted 
> packets by dts (using this flag can slow demuxing down)
>  #define AVFMT_FLAG_PRIV_OPT0x2 ///< Enable use of private options by 
> delaying codec open (this could be made default once all code is converted)
>  #define AVFMT_FLAG_KEEP_SIDE_DATA 0x4 ///< Don't merge side data but 
> keep it separate.
> +#define AVFMT_FLAG_NO_META_CONV 0x8 ///< Skip conversion of metadata 
> field names.
>  
>  /**
>   * @deprecated deprecated in favor of probesize2
> diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> index fb89e83..c2bcbe0 100644
> --- a/libavformat/id3v2.c
> +++ b/libavformat/id3v2.c
> @@ -574,8 +574,11 @@ static void read_chapter(AVFormatContext *s, AVIOContext 
> *pb, int len, char *tta
>  len -= taglen;
>  }
>  
> -ff_metadata_conv(&chapter->metadata, NULL, ff_id3v2_34_metadata_conv);
> -ff_metadata_conv(&chapter->metadata, NULL, ff_id3v2_4_metadata_conv);
> +if (!(s->flags & AVFMT_FLAG_NO_META_CONV)) {
> +ff_metadata_conv(&chapter->metadata, NULL, 
> ff_id3v2_34_metadata_conv);
> +ff_metadata_conv(&chapter->metadata, NULL, ff_id3v2_4_metadata_conv);
> +}
> +
>  end:
>  av_free(dst);
>  }
> @@ -916,9 +919,13 @@ static void id3v2_read_internal(AVIOContext *pb, 
> AVDictionary **metadata,
>  avio_seek(pb, off, SEEK_SET);
>  }
>  } while (found_header);
> -ff_metadata_conv(metadata, NULL, ff_id3v2_34_metadata_conv);
> -ff_metadata_conv(metadata, NULL, id3v2_2_metadata_conv);
> -ff_metadata_conv(metadata, NULL, ff_id3v2_4_metadata_conv);
> +
> +if (!(s->flags & AVFMT_FLAG_NO_META_CONV)) {
> +ff_metadata_conv(metadata, NULL, ff_id3v2_34_metadata_conv);
> +ff_metadata_conv(metadata, NULL, id3v2_2_metadata_conv);
> +ff_metadata_conv(metadata, NULL, ff_id3v2_4_metadata_conv);
> +}
> +
>  merge_date(metadata);
>  }
>  
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 31ee456..347dbcd 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1377,7 +1377,9 @@ static void matroska_convert_tag(AVFormatContext *s, 
> EbmlList *list,
>  matroska_convert_tag(s, &tags[i].sub, meta

Re: [FFmpeg-devel] Invitation to VDD and registration

On 16 Aug, Michael Niedermayer wrote :
> VDD is a great thing for thouse who like meetings and conferences.

BS. It's exactly the opposite.

It's for people like us, who don't like conferences, but understand the
need to meet.

> But iam not a conference / meeting / party / traveller guy. I really

Almost none of us are. 90% of us are all akward uber-geeks, but they
still attend.


-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swresample: Add AVFrame based API

On Mon, Aug 11, 2014 at 01:49:19AM +0200, Michael Niedermayer wrote:
> From: Luca Barbato 
> 
> TODO:bump
> 
> Signed-off-by: Michael Niedermayer 

patch applied with all requested changes

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- 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 1/2] postproc: use av_freep() for saftey

2014-08-16 Thread Clément Bœsch

On Sat, Aug 16, 2014 at 07:54:24PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libpostproc/postprocess.c |   22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
> index 794cd30..397e4fb 100644
> --- a/libpostproc/postprocess.c
> +++ b/libpostproc/postprocess.c
> @@ -931,17 +931,17 @@ void pp_free_context(void *vc){
>  PPContext *c = (PPContext*)vc;
>  int i;
>  
> -for(i=0; i<3; i++) av_free(c->tempBlurred[i]);
> -for(i=0; i<3; i++) av_free(c->tempBlurredPast[i]);
> -
> -av_free(c->tempBlocks);
> -av_free(c->yHistogram);
> -av_free(c->tempDst);
> -av_free(c->tempSrc);
> -av_free(c->deintTemp);
> -av_free(c->stdQPTable);
> -av_free(c->nonBQPTable);
> -av_free(c->forcedQPTable);
> +for(i=0; i<3; i++) av_freep(&c->tempBlurred[i]);
> +for(i=0; i<3; i++) av_freep(&c->tempBlurredPast[i]);
> +
> +av_freep(&c->tempBlocks);
> +av_freep(&c->yHistogram);
> +av_freep(&c->tempDst);
> +av_freep(&c->tempSrc);
> +av_freep(&c->deintTemp);
> +av_freep(&c->stdQPTable);
> +av_freep(&c->nonBQPTable);
> +av_freep(&c->forcedQPTable);
>  
>  memset(c, 0, sizeof(PPContext));

Isn't it the goal of this memset?

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] postproc: use av_freep() for saftey

On Sat, Aug 16, 2014 at 10:02:50PM +0200, Clément Bœsch wrote:
> On Sat, Aug 16, 2014 at 07:54:24PM +0200, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libpostproc/postprocess.c |   22 +++---
> >  1 file changed, 11 insertions(+), 11 deletions(-)
> > 
> > diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
> > index 794cd30..397e4fb 100644
> > --- a/libpostproc/postprocess.c
> > +++ b/libpostproc/postprocess.c
> > @@ -931,17 +931,17 @@ void pp_free_context(void *vc){
> >  PPContext *c = (PPContext*)vc;
> >  int i;
> >  
> > -for(i=0; i<3; i++) av_free(c->tempBlurred[i]);
> > -for(i=0; i<3; i++) av_free(c->tempBlurredPast[i]);
> > -
> > -av_free(c->tempBlocks);
> > -av_free(c->yHistogram);
> > -av_free(c->tempDst);
> > -av_free(c->tempSrc);
> > -av_free(c->deintTemp);
> > -av_free(c->stdQPTable);
> > -av_free(c->nonBQPTable);
> > -av_free(c->forcedQPTable);
> > +for(i=0; i<3; i++) av_freep(&c->tempBlurred[i]);
> > +for(i=0; i<3; i++) av_freep(&c->tempBlurredPast[i]);
> > +
> > +av_freep(&c->tempBlocks);
> > +av_freep(&c->yHistogram);
> > +av_freep(&c->tempDst);
> > +av_freep(&c->tempSrc);
> > +av_freep(&c->deintTemp);
> > +av_freep(&c->stdQPTable);
> > +av_freep(&c->nonBQPTable);
> > +av_freep(&c->forcedQPTable);
> >  
> >  memset(c, 0, sizeof(PPContext));
> 
> Isn't it the goal of this memset?

right, change is redundant, patch droped


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Russ Allbery

Ivan Kalvachev  writes:

> I'm quite sure the Security team is full of capable people who can
> handle one more package.

One, no, this statement is not correct.  Not because the security team is
not capable -- they are very capable -- but because they are not *full*.
You imply that the security team has tons of resources and time to spare.
Let me assure you that this is far from the case.  This isn't even the
case for security teams consisting of full-time staff paid by commercial
Linux distributions, let alone volunteers for the Debian project.

Two, the security team has already said that FFmpeg is not just "one more
package," and that no, they can't handle the substantial incremental load
from adding FFmpeg without removing libav.  You may not think that should
be the case, but I'm afraid your opinion on the topic doesn't matter
unless you're finding a way to either reduce that work or add more
resources.

> FFmpeg takes security seriously.

I'm sure that it does.

The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient.  I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.

This isn't about anyone's good intentions.  It's about the reality of
past, very negative experience with FFmpeg's security track record.

It's clear that efforts are underway to improve that, such as through the
fuzz testing work that Google (among others) has been doing.  That's
great, but I'm sure you can also understand that the past track record has
been sufficiently bad that everyone will continue to be leery for a while.
To change that impression, FFmpeg is going to have to substantially
improve on its past security track record and then *maintain* that new
level of security for some period of time.

Note that all of the above statements also apply to libav.  As near as I
can tell, this is not a distinguishing characteristic between the two
projects.

-- 
Russ Allbery (r...@debian.org)   
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] A patch for gdigrab function

On Fri, Aug 08, 2014 at 05:08:46PM +0800, hlszl1...@163.com wrote:
> hi, all
> 
> I'm using gdigrab feature on windows, and found that the count of gdi objects 
> owned by ffmpeg.exe increasing endlessly...
>  
> Here is the patch, can someone commit it?
> --
> diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c 
> index bccfef2..e2bed14 100644 
> --- a/libavdevice/gdigrab.c 
> +++ b/libavdevice/gdigrab.c 
> @@ -451,6 +451,10 @@ static void paint_mouse_pointer(AVFormatContext *s1, 
> struct gdigrab *gdigrab) 
> icon = CopyCursor(LoadCursor(NULL, IDC_ARROW)); 
> } 
> 
> + /*Remarks 
> + *GetIconInfo creates bitmaps for the hbmMask and hbmColor members of 
> ICONINFO. 
> + *The calling application must manage these bitmaps and delete them when 
> they are no longer necessary. 
> + */ 
> if (!GetIconInfo(icon, &info)) { 
> CURSOR_ERROR("Could not get icon info"); 
> goto icon_error; 
> @@ -481,6 +485,10 @@ static void paint_mouse_pointer(AVFormatContext *s1, 
> struct gdigrab *gdigrab) 
> } 
> 
> icon_error: 
> + if (info.hbmMask) 
> + DeleteObject(info.hbmMask); 
> + if(info.hbmColor) 
> + DeleteObject(info.hbmColor); 
> if (icon) 
> DestroyCursor(icon); 
> } else {

the patch has been mangled, probably by your mail user agent

also CC-ing maintainer

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread compn

On Sat, 16 Aug 2014 11:59:20 -0700
Russ Allbery  wrote:

> Two, the security team has already said that FFmpeg is not just "one
> more package," and that no, they can't handle the substantial
> incremental load from adding FFmpeg without removing libav.  You may

> be leery for a while. To change that impression, FFmpeg is going to
> have to substantially improve on its past security track record and
> then *maintain* that new level of security for some period of time.

> Note that all of the above statements also apply to libav.  As near
> as I can tell, this is not a distinguishing characteristic between
> the two projects.


ah, you dusted off the classic debian mplayer rejection reason!

from 2003 even!
http://comments.gmane.org/gmane.linux.debian.devel.legal/9519

nice to see debian hasnt changed.

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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On Sat, 16 Aug 2014 11:59:20 -0700
Russ Allbery  wrote:

> The problem, however, is that taking security seriously, while possibly
> necessary, is not sufficient.  I'm glad that FFmpeg takes security
> seriously, but what FFmpeg needs is to *have fewer security bugs*.

That is very valuable advice. We'll get to work right away.

> Note that all of the above statements also apply to libav.  As near as I
> can tell, this is not a distinguishing characteristic between the two
> projects.

And that's an argument against switching to FFmpeg exactly how?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Derek Buitenhuis

On 8/16/2014 11:27 PM, wm4 wrote:
> That is very valuable advice. We'll get to work right away.

I've added it to my TODO:

* Don't write bugs.

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

Re: [FFmpeg-devel] [PATCH] ffprobe: add -show_data_hash option.

On Sun, May 04, 2014 at 04:39:01PM +0200, Nicolas George wrote:
> Signed-off-by: Nicolas George 
> ---
>  doc/ffprobe.texi |  4 
>  doc/ffprobe.xsd  |  2 ++
>  ffprobe.c| 39 +++
>  3 files changed, 45 insertions(+)
> 
> 
> This time with a list of ciphers in the error message.

whats the status of this patch ?
has it been forgotten ?

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

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

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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Andreas Cadhalpun

Hi,

On 16.08.2014 17:49, Pau Garcia i Quiles wrote:

On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George mailto:geo...@nsup.org>> wrote:

The only option is to make sure the users do not suffer from the
fork, by
making sure they can easily use the version that is most suited for
their
need without being sucked into the developers' disagreements.

Can we get back on topic?

Yes. I have now sent the pkg-config patches to the BTS [1].

With or without libav in Debian, there are solid technical reasons to
have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick
(although they parted ways in a civilized way: different library names),
and we certainly have a ton of librarys which provide very similar features.

This is also my point of view.

Since before the fork, the libav developers have been sabotaging ffmpeg
as much as possible, in every "combat field": library names, library
versions, taking distributions hostage (ffmpeg package that installs
libav!?), etc. This is not the way to fork anything. This is a fact.

It would be nice, if everyone, including you, would refrain from posting
such flamebaits on debian-devel.

Please try to follow Debian's code of conduct [2].

I don't care whether Michael Nidermayer was a dictator or not. I don't
care whether the code-review rules in libav are better or worse. I don't
care what the Linux kernel does. The only thing I care about is Debian
is shipping a less-capable (i. e. less multimedia formats supported)
distribution due to this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will
most certainly cause binary problems.

This is wrong, because the FFmpeg Debian packaging avoids filename
conflicts.

If libav and ffmpeg maintainers cannot reach an agreement regarding
library names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian.
E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc.

This is already done in the FFmpeg Debian packages.

Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been
done in the past.

This is not necessary, because the Libav binaries already have different
names, avconv, avplay and so on.

And before someone mentions it: I don't think it's too late. It's
getting too late because nobody with the right to act is doing anything.
In the end, our users are the ones being harmed and we are left
wondering why they are increasingly moving to other distributions or Mac
OS X.

Indeed it's getting late, because the FFmpeg package has been waiting in
the NEW queue for more than 3 months.

Best regards,
Andreas

1:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=andreas.cadhal...@googlemail.com

2: https://www.debian.org/code_of_conduct
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Russ Allbery

wm4  writes:
> Russ Allbery  wrote:

>> Note that all of the above statements also apply to libav.  As near as I
>> can tell, this is not a distinguishing characteristic between the two
>> projects.

> And that's an argument against switching to FFmpeg exactly how?

It's not.  Nor was I trying to make one.  This part of the thread was
discussing introducing FFmpeg into Debian alongside libav.

As I believe I mentioned previously, although the code base underlying
both projects has a bad past security track record, currently FFmpeg
appears to be doing somewhat better than libav.  I believe a member of the
security team made a similar observation.  So, when picking one, the
security argument seems to be at least partly in FFmpeg's favor.  That was
not my point; my point was that picking both of them is something that had
already been discussed and rejected for what to me feel like sound
reasons.

Security of course isn't the only consideration when picking one of the
two, and regardless I'm not the person who would be deciding anything.
Mostly I'm speaking up because it felt like people were going down blind
alleys arguing about things that aren't really at issue.

Note that experimental doesn't receive security support.  I may be missing
something (and here it's ftp-master that is the relevant decision-making
party), but I haven't seen any obvious reason why one shouldn't introduce
FFmpeg packages into experimental, particularly if people feel like
there's anything to be gained by seeing concrete packaging work, letting
people more easily experiment with the packages, and so forth.  Of course,
that by itself doesn't imply anything about the broader question of
replacing libav with FFmpeg or not.

-- 
Russ Allbery (r...@debian.org)   
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Russ Allbery

Derek Buitenhuis  writes:
> On 8/16/2014 11:27 PM, wm4 wrote:

>> That is very valuable advice. We'll get to work right away.

> I've added it to my TODO:

> * Don't write bugs.

That's a really bad way of avoiding security bugs.

I'm sure you know that and are just being flippant, but I have to say
that, as an outsider to the project who would like to use the software but
who cares a lot about not introducing security weaknesses, it's hard to
shake the feeling that this dismissive attitude is part of the problem.
There were earlier responses in the thread along the same lines, arguing
that the nature of FFmpeg means it will just inevitably have a bunch of
security bugs.  This sort of learned helplessness is really off-putting.

Thankfully, I get the impression from other research that I was doing
that it's *not* typical of FFmpeg as a whole, and that you all are, in
fact, doing exactly the sorts of things that I would recommend.  So this
is probably just one of those pointless Internet arguments where everyone
says things more aggressively than they actually mean them, and much heat
is created with little light.

But, for the record, what I was actually getting at is that the way to
avoid a bunch of security bugs is not to stop writing bugs, because no one
is going to achieve that.  It's to put in place supporting infrastructure
that makes it easier to write secure code and harder to write code where
bugs create security problems.  Trying to be closer to perfect in the code
you write is a horrible way to achieve security.  It doesn't work.  Adding
surrounding protective structure to the code so that the bugs do not
compromise security, and putting systems in place that let the computer do
lots more security sanity checking for you, are how other projects with
similar challenges have achieved considerable improvements in security bug
rates.

In case there's anyone reading this who doesn't have a feel for what this
looks like, the process the LibreSSL project is going through (regardless
of one's opinion on the desirability of an OpenSSL fork) is very
interesting.  I've personally learned quite a bit from it, have now
introduced reallocarray in my own code, and am planning on introducing
strtonum.

-- 
Russ Allbery (r...@debian.org)   
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] vidstab*: Remove accidentally exported av_2_vs_pixel_format()

2014-08-16 Thread Timothy Gu

Also correctly namespace other functions in vidstabutils, and decrease
difference from Libav.

Initial-patch-by: Vittorio Giovara 
Signed-off-by: Timothy Gu 
---

Does this need an FF_API_VIDSTAB?

 doc/APIchanges| 4 
 libavfilter/version.h | 2 +-
 libavfilter/vf_vidstabdetect.c| 5 +++--
 libavfilter/vf_vidstabtransform.c | 6 +++---
 libavfilter/vidstabutils.c| 8 
 libavfilter/vidstabutils.h| 4 ++--
 6 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 067f60f..fec36ff 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2014-08-09
 
 API changes, most recent first:
 
+2014-08-xx - xxx - lavfi 5.1.0
+  The accidentally exported and never exposed av_2_vs_pixel_format() is
+  removed.
+
 2014-08-xx - xxx - lavu 54.03.0 - mem.h
   Add av_strndup().
 
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 2003b76..6ebb1ce 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,7 +30,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVFILTER_VERSION_MAJOR  5
-#define LIBAVFILTER_VERSION_MINOR  0
+#define LIBAVFILTER_VERSION_MINOR  1
 #define LIBAVFILTER_VERSION_MICRO 100
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vf_vidstabdetect.c b/libavfilter/vf_vidstabdetect.c
index 9b4b20f..bf067af 100644
--- a/libavfilter/vf_vidstabdetect.c
+++ b/libavfilter/vf_vidstabdetect.c
@@ -63,7 +63,7 @@ AVFILTER_DEFINE_CLASS(vidstabdetect);
 static av_cold int init(AVFilterContext *ctx)
 {
 StabData *sd = ctx->priv;
-vs_set_mem_and_log_functions();
+ff_vs_init();
 sd->class = &vidstabdetect_class;
 av_log(ctx, AV_LOG_VERBOSE, "vidstabdetect filter: init %s\n", 
LIBVIDSTAB_VERSION);
 return 0;
@@ -106,7 +106,8 @@ static int config_input(AVFilterLink *inlink)
 VSFrameInfo fi;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
 
-vsFrameInfoInit(&fi, inlink->w, inlink->h, av_2_vs_pixel_format(ctx, 
inlink->format));
+vsFrameInfoInit(&fi, inlink->w, inlink->h,
+ff_av2vs_pixfmt(ctx, inlink->format));
 if (fi.bytesPerPixel != av_get_bits_per_pixel(desc)/8) {
 av_log(ctx, AV_LOG_ERROR, "pixel-format error: wrong bits/per/pixel, 
please report a BUG");
 return AVERROR(EINVAL);
diff --git a/libavfilter/vf_vidstabtransform.c 
b/libavfilter/vf_vidstabtransform.c
index 3ce4769..1bd43ff 100644
--- a/libavfilter/vf_vidstabtransform.c
+++ b/libavfilter/vf_vidstabtransform.c
@@ -107,7 +107,7 @@ AVFILTER_DEFINE_CLASS(vidstabtransform);
 static av_cold int init(AVFilterContext *ctx)
 {
 TransformContext *tc = ctx->priv;
-vs_set_mem_and_log_functions();
+ff_vs_init();
 tc->class = &vidstabtransform_class;
 av_log(ctx, AV_LOG_VERBOSE, "vidstabtransform filter: init %s\n", 
LIBVIDSTAB_VERSION);
 return 0;
@@ -151,9 +151,9 @@ static int config_input(AVFilterLink *inlink)
 VSFrameInfo fi_dest;
 
 if (!vsFrameInfoInit(&fi_src, inlink->w, inlink->h,
- av_2_vs_pixel_format(ctx, inlink->format)) ||
+ ff_av2vs_pixfmt(ctx, inlink->format)) ||
 !vsFrameInfoInit(&fi_dest, inlink->w, inlink->h,
- av_2_vs_pixel_format(ctx, inlink->format))) {
+ ff_av2vs_pixfmt(ctx, inlink->format))) {
 av_log(ctx, AV_LOG_ERROR, "unknown pixel format: %i (%s)",
inlink->format, desc->name);
 return AVERROR(EINVAL);
diff --git a/libavfilter/vidstabutils.c b/libavfilter/vidstabutils.c
index dd6486d..1f9f331 100644
--- a/libavfilter/vidstabutils.c
+++ b/libavfilter/vidstabutils.c
@@ -21,7 +21,7 @@
 #include "vidstabutils.h"
 
 /** convert AV's pixelformat to vid.stab pixelformat */
-VSPixelFormat av_2_vs_pixel_format(AVFilterContext *ctx, enum AVPixelFormat pf)
+VSPixelFormat ff_av2vs_pixfmt(AVFilterContext *ctx, enum AVPixelFormat pf)
 {
 switch (pf) {
 case AV_PIX_FMT_YUV420P:  return PF_YUV420P;
@@ -47,7 +47,7 @@ typedef struct {
 } VS2AVLogCtx;
 
 /** wrapper to log vs_log into av_log */
-static int vs_2_av_log_wrapper(int type, const char *tag, const char *format, 
...)
+static int vs2av_log(int type, const char *tag, const char *format, ...)
 {
 va_list ap;
 VS2AVLogCtx ctx;
@@ -66,7 +66,7 @@ static int vs_2_av_log_wrapper(int type, const char *tag, 
const char *format, ..
 }
 
 /** sets the memory allocation function and logging constants to av versions */
-void vs_set_mem_and_log_functions(void)
+void ff_vs_init(void)
 {
 vs_malloc  = av_malloc;
 vs_zalloc  = av_mallocz;
@@ -78,7 +78,7 @@ void vs_set_mem_and_log_functions(void)
 VS_INFO_TYPE  = AV_LOG_INFO;
 VS_MSG_TYPE   = AV_LOG_VERBOSE;
 
-vs_log   = vs_2_av_log_wrapper;
+vs_log   = vs2av_log;
 
 VS_ERROR = 0;
 VS_OK= 1;
diff --git a/libavfilter/vidstabutils.h b/libavfilter/vi

[FFmpeg-devel] [PATCH 2/3] vidstabutils: improve documentation

2014-08-16 Thread Timothy Gu

Signed-off-by: Timothy Gu 
---
 libavfilter/vidstabutils.h | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vidstabutils.h b/libavfilter/vidstabutils.h
index 93278f6..c6d6ced 100644
--- a/libavfilter/vidstabutils.h
+++ b/libavfilter/vidstabutils.h
@@ -25,12 +25,23 @@
 
 #include "avfilter.h"
 
-/* ** some conversions from avlib to vid.stab constants and functions *** */
+/* Conversion routines between libav* and vid.stab */
 
-/** converts the pixelformat of avlib into the one of the vid.stab library */
+/**
+ * Converts an AVPixelFormat to a VSPixelFormat.
+ *
+ * @param[in] ctx AVFilterContext used for logging
+ * @param[in] pf  AVPixelFormat
+ * @returna corresponding VSPixelFormat
+ */
 VSPixelFormat ff_av2vs_pixfmt(AVFilterContext *ctx, enum AVPixelFormat pf);
 
-/** sets the memory allocation function and logging constants to av versions */
+/**
+ * Initialize libvidstab
+ *
+ * Sets the memory allocation functions and logging constants to corresponding
+ * av* versions.
+ */
 void ff_vs_init(void);
 
 #endif
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 3/3] vidstabutils: fix indentation

2014-08-16 Thread Timothy Gu

Signed-off-by: Timothy Gu 
---
 libavfilter/vidstabutils.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavfilter/vidstabutils.c b/libavfilter/vidstabutils.c
index 1f9f331..13544cf 100644
--- a/libavfilter/vidstabutils.c
+++ b/libavfilter/vidstabutils.c
@@ -52,11 +52,11 @@ static int vs2av_log(int type, const char *tag, const char 
*format, ...)
 va_list ap;
 VS2AVLogCtx ctx;
 AVClass class = {
-  .class_name = tag,
-  .item_name  = av_default_item_name,
-  .option = 0,
-  .version= LIBAVUTIL_VERSION_INT,
-  .category   = AV_CLASS_CATEGORY_FILTER,
+.class_name = tag,
+.item_name  = av_default_item_name,
+.option = 0,
+.version= LIBAVUTIL_VERSION_INT,
+.category   = AV_CLASS_CATEGORY_FILTER,
 };
 ctx.class = &class;
 va_start(ap, format);
-- 
1.9.1

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

Re: [FFmpeg-devel] Invitation to VDD and registration