On Mon, Jul 23, 2012 at 06:45:17PM -0400, Derek Buitenhuis wrote:
> From: Carl Eugen Hoyos
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/v410dec.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
> index d7660e
Hi,
On Mon, Jul 23, 2012 at 7:45 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Jul 23, 2012 at 5:37 PM, Daniel Kang wrote:
>> On Mon, Jul 23, 2012 at 5:21 PM, Diego Biurrun wrote:
>>>
>>> On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
>>> > From: Daniel Kang
>>> >
>>> > The only
Hi,
On Mon, Jul 23, 2012 at 5:37 PM, Daniel Kang wrote:
> On Mon, Jul 23, 2012 at 5:21 PM, Diego Biurrun wrote:
>>
>> On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
>> > From: Daniel Kang
>> >
>> > The only CPUs that have 3dnow and don't have mmxext are 12 years old.
>> > ---
>> >
On Tue, Jul 24, 2012 at 02:03:00AM +0200, Diego Biurrun wrote:
>
> I took the Git server offline in roundabout a minute, so hopefully
> nothing should have picked up the stray commits. The repo is fixed
> now and HEAD is pointing to the commit that it should point to.
> Mail notifications for the
On Mon, Jul 23, 2012 at 08:56:55PM -0400, Derek Buitenhuis wrote:
> On 23/07/2012 8:54 PM, Uoti Urpala wrote:
> > No, the MP3 decoder is already "MP3 (MPEG audio layer 3)", matching what
> > I suggested changing AAC to. The name you quoted above is from the
> > libavformat _demuxer_. Thus this make
On Tue, 2012-07-24 at 01:48 +0100, Måns Rullgård wrote:
> Derek Buitenhuis writes:
>
> > On 23/07/2012 8:15 PM, Diego Biurrun wrote:
> >> Most people know the codec as "AAC" and not "Advanced Audio Coding".
> >> ---
> >> libavcodec/aacdec.c |2 +-
> >> 1 files changed, 1 insertions(+), 1 del
On 23/07/2012 8:54 PM, Uoti Urpala wrote:
> No, the MP3 decoder is already "MP3 (MPEG audio layer 3)", matching what
> I suggested changing AAC to. The name you quoted above is from the
> libavformat _demuxer_. Thus this makes the audio codecs more consistent,
> but there is already an inconsistenc
On Mon, 2012-07-23 at 20:43 -0400, Derek Buitenhuis wrote:
> On 23/07/2012 8:15 PM, Diego Biurrun wrote:
> > Most people know the codec as "AAC" and not "Advanced Audio Coding".
> > ---
> > libavcodec/aacdec.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
>
> OK. But, should we
On 23/07/2012 8:48 PM, Måns Rullgård wrote:
>> OK. But, should we not change e.g. MP3?
> MP3 is not an official designation whatsoever.
I was going by the rationale of this patch.
"Most people will recognize 'MP3'."
Merely a musing.
- Derek
___
libav-
On 23/07/2012 8:30 PM, Derek Buitenhuis wrote:
> How to reproduce:
> This error is exposed when we build the ffmpeg using Intel C++ Compiler,
> IPO+PGO optimization. Crashed when decoding an MJPEG video.
Forgot to remove the first occurrence. Woops. Amended locally,
pending further review.
Derek Buitenhuis writes:
> On 23/07/2012 8:15 PM, Diego Biurrun wrote:
>> Most people know the codec as "AAC" and not "Advanced Audio Coding".
>> ---
>> libavcodec/aacdec.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> OK. But, should we not change e.g. MP3?
MP3 is not an o
On 23/07/2012 8:15 PM, Diego Biurrun wrote:
> Most people know the codec as "AAC" and not "Advanced Audio Coding".
> ---
> libavcodec/aacdec.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
OK. But, should we not change e.g. MP3?
It is currently: "MPEG audio layer 2/3"
- Derek
__
On Mon, Jul 23, 2012 at 5:21 PM, Diego Biurrun wrote:
> On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
> > From: Daniel Kang
> >
> > The only CPUs that have 3dnow and don't have mmxext are 12 years old.
> > ---
> > libavcodec/x86/dsputil_mmx.c |9 -
> > libavcodec/x8
On Mon, Jul 23, 2012 at 05:15:15PM -0700, Diego Elio Pettenò wrote:
> Il 23/07/2012 17:03, Diego Biurrun ha scritto:
> > I'm not entirely sure if I should have
> > expected that or not.
>
> You should. That's why it's best to work on a branch and only add to
> master when you intend to push it.
From: Yang Wang
In ff_put_pixels_clamped_mmx(), there are two assembly code blocks.
In the first block (in the unrolled loop), the instructions
"movq 8%3, %%mm1 \n\t", and so forth, have problems.
From above instruction, it is clear what the programmer wants: a load from
p + 8. But this assembly
On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
> From: Daniel Kang
>
> The only CPUs that have 3dnow and don't have mmxext are 12 years old.
> ---
> libavcodec/x86/dsputil_mmx.c |9 -
> libavcodec/x86/h264_qpel_mmx.c |4
> 2 files changed, 0 insertions(+), 13
On Mon, Jul 23, 2012 at 08:13:20PM -0400, Derek Buitenhuis wrote:
> On 23/07/2012 7:32 PM, Diego Biurrun wrote:
> > Please don't undo the prettyprinting I applied to that file.
>
> I don't see a way to keep it pretty short of re-indenting the
> whole block, which should be a 2nd commit.
Have a lo
Most people know the codec as "AAC" and not "Advanced Audio Coding".
---
libavcodec/aacdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 4be5255..76d4120 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -284
Il 23/07/2012 17:03, Diego Biurrun ha scritto:
> I'm not entirely sure if I should have
> expected that or not.
You should. That's why it's best to work on a branch and only add to
master when you intend to push it.
Since your master tracks origin/master both ways, a git push to origin
_will_ p
From: Daniel Kang
The only CPUs that have 3dnow and don't have mmxext are 12 years old.
---
libavcodec/x86/dsputil_mmx.c |9 -
libavcodec/x86/h264_qpel_mmx.c |4
2 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/libavcodec/x86/dsputil_mmx.c b/libavcodec/x86/d
On 23/07/2012 7:32 PM, Diego Biurrun wrote:
> Please don't undo the prettyprinting I applied to that file.
I don't see a way to keep it pretty short of re-indenting the
whole block, which should be a 2nd commit.
- Derek
___
libav-devel mailing list
lib
Ahem, it seems to be the brown paperbag season again...
So, I slipped up and accidentally pushed some ongoing work I had on
my master branch to origin/master, namely the following commits:
0abed1d13fdc0fb04873a7763e7a765ba621d66a
aacps: Drop some function argument const qualifiers to silence
On 7/24/12 12:45 AM, Derek Buitenhuis wrote:
From: Carl Eugen Hoyos
Signed-off-by: Derek Buitenhuis
---
libavcodec/v410dec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
index d7660ee..93545ab 100644
--- a/libavcodec/
On 7/24/12 12:52 AM, Måns Rullgård wrote:
And snow.c doesn't?
Apparently I'm the one wanting to preserve it, if we manage to get dirac
inside we might drop snow.
I'd rather drop it once it is completely surpassed by dirac though =/
lu
___
libav-
On Mon, Jul 23, 2012 at 11:52:17PM +0100, Måns Rullgård wrote:
> Diego Biurrun writes:
> > On Mon, Jul 23, 2012 at 04:54:57PM +0100, Måns Rullgård wrote:
> >> Diego Biurrun writes:
> >>
> >> > ---
> >> > configure|1 -
> >> > doc/general.texi |1 -
> >> > doc/pro
On Mon, Jul 23, 2012 at 07:09:06PM -0400, Derek Buitenhuis wrote:
> From: Yang Wang
>
> This error was fixed in the second block of the assembly code, but not in
> the unrolled loop.
>
> How to reproduce:
> This error is exposed when we build the ffmpeg using Intel C++ Compiler,
> IPO+PG
From: Yang Wang
In ff_put_pixels_clamped_mmx(), there are two assembly code blocks.
In the first block (in the unrolled loop), the instructions
"movq 8%3, %%mm1 \n\t", and so forth, have problems.
From above instruction, it is clear what the programmer wants: a load from
p + 8. But this assembly
On 07/24/2012 12:17 AM, Diego Biurrun wrote:
On Mon, Jul 23, 2012 at 11:45:33PM +0200, Benjamin Larsson wrote:
There are Gopher implementations in other places.
The same is true for http. Anyway you have some points and I don't
really care that much I just wanted to state that I am against rem
Diego Biurrun writes:
> On Mon, Jul 23, 2012 at 04:54:57PM +0100, Måns Rullgård wrote:
>> Diego Biurrun writes:
>>
>> > ---
>> > configure|1 -
>> > doc/general.texi |1 -
>> > doc/protocols.texi |4 --
>> > libavformat/Makefile |1 -
>> > liba
From: Carl Eugen Hoyos
Signed-off-by: Derek Buitenhuis
---
libavcodec/v410dec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
index d7660ee..93545ab 100644
--- a/libavcodec/v410dec.c
+++ b/libavcodec/v410dec.c
@@ -30,10 +3
I messed up while adding Kostya's sugegsted log text change.
Here's the fix.
Carl Eugen Hoyos (1):
Fix typo in v410 decoder.
libavcodec/v410dec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.7.10.4
___
libav-devel mailing lis
I don't see a point in removing it as long as it's not a big maintenance
burden.
Especially not since it's been added so recently.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Sun, Jul 22, 2012 at 1:16 PM, Ronald S. Bultje wrote:
> From: "Ronald S. Bultje"
>
> This completes the conversion of h264dsp to yasm; note that h264 also
> uses some dsputil functions, most notably qpel. Performance-wise, the
> yasm-version is ~10 cycles faster (182->172) on x86-64, and ~8 cy
On Mon, Jul 23, 2012 at 11:45:33PM +0200, Benjamin Larsson wrote:
> If you remove this then you can drop the ra14.4 encoder also. It has
> the same usability factor. I am opposed to removing things unless it
> becomes a maintenance burden.
You cannot compare one with the other. libavcodec is the
On Mon, Jul 23, 2012 at 04:54:57PM +0100, Måns Rullgård wrote:
> Diego Biurrun writes:
>
> > ---
> > configure|1 -
> > doc/general.texi |1 -
> > doc/protocols.texi |4 --
> > libavformat/Makefile |1 -
> > libavformat/allformats.c |1 -
> >
On Mon, 23 Jul 2012, Diego Biurrun wrote:
The ffrtmpcrypt protocol depends on external libraries, which are
also required to compile the header file.
---
libavformat/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index
The ffrtmpcrypt protocol depends on external libraries, which are
also required to compile the header file.
---
libavformat/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index d8fe448..dbf1057 100644
--- a/libavformat/
On Mon, Jul 23, 2012 at 12:16:42AM +0100, Mans Rullgard wrote:
> This allows non-standard replacements for the -c compiler flag.
> Some compilers use other flags or no flag at all in place of
> the usual one.
LGTM
Diego
___
libav-devel mailing list
liba
If you remove this then you can drop the ra14.4 encoder also. It has the
same usability factor. I am opposed to removing things unless it becomes
a maintenance burden.
MvH
Benjamin Larsson
___
libav-devel mailing list
libav-devel@libav.org
https://lis
On Mon, Jul 23, 2012 at 06:47:51PM +0300, Martin Storsjö wrote:
> On Mon, 23 Jul 2012, Diego Biurrun wrote:
>
> >Some of the rtmp* dependencies are in shambles.
> >libavformat/rtmpproto.c unconditionally uses all the symbols from
> >libavformat/rtmpcrypt.c, but does not depend on it.
> >
> >I susp
On 7/23/12 5:13 PM, Derek Buitenhuis wrote:
Try and decode broken files, but still fail if explode
mode is enabled.
Signed-off-by: Derek Buitenhuis
---
libavcodec/v410dec.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Looks good, thank you.
lu
___
On 7/23/12 6:53 PM, Josh Allmann wrote:
On 23 March 2012 12:40, Luca Barbato wrote:
---
libavformat/avformat.h |1 +
libavformat/options.c |1 +
libavformat/utils.c| 13 -
3 files changed, 10 insertions(+), 5 deletions(-)
The commit message probably should men
On Mon, Jul 23, 2012 at 9:20 AM, Kieran Kunhya wrote:
>
> ---
> libavcodec/libfdk-aacenc.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
> index f2c3fbd..4d7aa7b 100644
> --- a/libavcodec/libfdk-a
On 23 March 2012 12:40, Luca Barbato wrote:
> ---
> libavformat/avformat.h |1 +
> libavformat/options.c |1 +
> libavformat/utils.c| 13 -
> 3 files changed, 10 insertions(+), 5 deletions(-)
>
The commit message probably should mention this affects only the
stream ana
On Mon, 23 Jul 2012, Kieran Kunhya wrote:
---
libavcodec/libfdk-aacenc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..4d7aa7b 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/li
---
libavcodec/libfdk-aacenc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..4d7aa7b 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -33,6 +33,8 @@ typedef str
On Mon, 23 Jul 2012, Derek Buitenhuis wrote:
On 23/07/2012 11:47 AM, Diego Biurrun wrote:
---
configure|1 -
doc/general.texi |1 -
doc/protocols.texi |4 --
libavformat/Makefile |1 -
libavformat/allformats.c |1 -
libavformat/gopher.c
Diego Biurrun writes:
> ---
> configure|1 -
> doc/general.texi |1 -
> doc/protocols.texi |4 --
> libavformat/Makefile |1 -
> libavformat/allformats.c |1 -
> libavformat/gopher.c | 125
> -
On 23/07/2012 11:47 AM, Diego Biurrun wrote:
> ---
> configure|1 -
> doc/general.texi |1 -
> doc/protocols.texi |4 --
> libavformat/Makefile |1 -
> libavformat/allformats.c |1 -
> libavformat/gopher.c | 125
>
---
configure|1 -
doc/general.texi |1 -
doc/protocols.texi |4 --
libavformat/Makefile |1 -
libavformat/allformats.c |1 -
libavformat/gopher.c | 125 --
6 files changed, 0 insertions(+), 133
On Mon, 23 Jul 2012, Diego Biurrun wrote:
Some of the rtmp* dependencies are in shambles.
libavformat/rtmpproto.c unconditionally uses all the symbols from
libavformat/rtmpcrypt.c, but does not depend on it.
I suspect all of the rtmp hackers have the dependencies for ffrtmpcrypt
protocol instal
On 7/20/12 3:33 PM, Luca Barbato wrote:
From: Michael Bradshaw
Based on FFmpeg version from
commit 3275981207e30e140cffaea334ac390f1a04266a
---
libavcodec/libopenjpegdec.c | 297 +++
1 files changed, 246 insertions(+), 51 deletions(-)
Ping.
___
On Mon, Jul 23, 2012 at 5:36 PM, Diego Biurrun wrote:
> Some of the rtmp* dependencies are in shambles.
> libavformat/rtmpproto.c unconditionally uses all the symbols from
> libavformat/rtmpcrypt.c, but does not depend on it.
>
> I suspect all of the rtmp hackers have the dependencies for ffrtmpcr
On 7/21/12 10:24 PM, Diego Biurrun wrote:
On Sat, Jul 21, 2012 at 09:20:59PM +0100, Måns Rullgård wrote:
Diego Biurrun writes:
On Sat, Jul 21, 2012 at 10:13:11PM +0200, Diego Biurrun wrote:
Fixes compilation for compilers that do not support gcc inline Assembly.
---
This is Ronald's set of
Some of the rtmp* dependencies are in shambles.
libavformat/rtmpproto.c unconditionally uses all the symbols from
libavformat/rtmpcrypt.c, but does not depend on it.
I suspect all of the rtmp hackers have the dependencies for ffrtmpcrypt
protocol installed and thus never noticed, but at least one
On 7/21/12 10:13 PM, Diego Biurrun wrote:
From: Ronald S. Bultje
Fixes compilation for compilers that do not support gcc inline Assembly.
Signed-off-by: Diego Biurrun
---
This is Ronald's set of three patches squashed into one.
The patches are very short and similar, no need to clutter the lo
On 23/07/2012 11:30 AM, Kostya Shishkov wrote:
> I'd add ", continuing anyway" in the second case but patch LGTM without that
> change too.
Done.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-d
On Mon, Jul 23, 2012 at 11:13:16AM -0400, Derek Buitenhuis wrote:
> Try and decode broken files, but still fail if explode
> mode is enabled.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/v410dec.c |8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/liba
On Wed, 4 Jul 2012, Jordi Ortiz wrote:
This code allows receiving a stream from a client with the PUBLISH command.
---
libavformat/rtmpproto.c | 470 ---
1 file changed, 449 insertions(+), 21 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavfo
On 23/07/2012 6:40 AM, Luca Barbato wrote:
> Mind adding support for explode mode?
>
> We have people that would rather know their files are broken.
Done & sent.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailma
Try and decode broken files, but still fail if explode
mode is enabled.
Signed-off-by: Derek Buitenhuis
---
libavcodec/v410dec.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
index a6f236b..f26ff82 100644
--- a/libavcod
On 3/24/12 2:50 AM, Luca Barbato wrote:
On 23/03/12 15:46, Martin Storsjö wrote:
On Fri, 23 Mar 2012, Luca Barbato wrote:
---
libavformat/avformat.h |1 +
libavformat/options.c |1 +
libavformat/utils.c| 13 -
3 files changed, 10 insertions(+), 5 deletions(-)
diff --gi
On Wed, 4 Jul 2012, Jordi Ortiz wrote:
---
libavformat/rtmppkt.c | 38 ++
libavformat/rtmppkt.h | 37 +
2 files changed, 75 insertions(+)
diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
index 4ce238d..3251b71 1
On 7/23/12 4:54 PM, Martin Storsjö wrote:
I'm not too familiar off-hand with this section of code right now, but I
think it might be reasonable like this. I guess Luca knows it better.
Luca, is this one ok?
I'd rather have message response tracking implemented fully, but can be
done later.
T
On Fri, 20 Jul 2012, Samuel Pitoiset wrote:
These messages are Adobe-specific historical artifacts that some RTMP
servers do not support. It is safer to ignore their failure. This fixes
publishing streams to crtmpserver and it fixes Bugzilla bug #309.
---
libavformat/rtmpproto.c | 30 +++
On 23/07/2012 10:12 AM, Ronald S. Bultje wrote:
> Ping.
>From what I can tell, it looks OK, so long as you've
tested each possibility + FATE.
Someone better acquainted with (Y)ASM should look, though.
- Derek
___
libav-devel mailing list
libav-devel@l
On 7/23/12 2:39 PM, Martin Storsjö wrote:
From: Adriano Pallavicino
If using a different sample rate or number of channels, use a dynamic
payload type instead, where the parameters are passed in the SDP.
G722 is a special case where the normal rules don't apply.
---
libavformat/rtp.c | 14
Hi,
On Mon, Jul 23, 2012 at 7:29 AM, Luca Barbato wrote:
> From: "Ronald S. Bultje"
>
> Write out the NAL decoding loops in full so that they are easier
> to parse for a preprocessor without it having to be aware of macros
> or other such things in C code.
>
> This also makes the code more reada
On 7/23/12 3:41 PM, Martin Storsjö wrote:
The rtmpts protocol uses https implicitly, via the ffrtmphttp
protocol, but the ffrtmphttp protocol is also useable for plain
rtmpt without https, so the dependency needs to be added here instead.
---
configure |2 +-
1 file changed, 1 insertion(+)
On Mon, 23 Jul 2012, Kieran Kunhya wrote:
---
libavcodec/libfdk-aacenc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..8c819a3 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libf
On Mon, Jul 23, 2012 at 09:27:03AM -0500, Kieran Kunhya wrote:
> ---
> libavcodec/libfdk-aacenc.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
LGTM though formatting probably could be better
___
libav-devel mailing list
libav-
From: "Ronald S. Bultje"
Write out the NAL decoding loops in full so that they are easier
to parse for a preprocessor without it having to be aware of macros
or other such things in C code.
This also makes the code more readable.
Signed-off-by: Luca Barbato
---
libavcodec/h264.c | 42 ++
---
libavcodec/libfdk-aacenc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..8c819a3 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -33,6 +33,8 @@ typedef struc
On Mon, Jul 23, 2012 at 07:16:53AM -0700, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Jul 23, 2012 at 7:14 AM, Kostya Shishkov
> wrote:
> > On Mon, Jul 23, 2012 at 07:11:49AM -0700, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun wrote:
> >> > On Sun, Jul
Kostya Shishkov writes:
> On Mon, Jul 23, 2012 at 07:11:49AM -0700, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun wrote:
>> > On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
>> >> From: "Ronald S. Bultje"
>> >>
>> >> Write out the NAL dec
Hi,
On Mon, Jul 23, 2012 at 7:14 AM, Kostya Shishkov
wrote:
> On Mon, Jul 23, 2012 at 07:11:49AM -0700, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun wrote:
>> > On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
>> >> From: "Ronald S. Bultje"
On Mon, Jul 23, 2012 at 07:11:49AM -0700, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun wrote:
> > On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
> >> From: "Ronald S. Bultje"
> >>
> >> Write out the NAL decoding loops in full so that they ar
Hi,
On Sun, Jul 22, 2012 at 1:16 PM, Ronald S. Bultje wrote:
> From: "Ronald S. Bultje"
>
> This completes the conversion of h264dsp to yasm; note that h264 also
> uses some dsputil functions, most notably qpel. Performance-wise, the
> yasm-version is ~10 cycles faster (182->172) on x86-64, and
Hi,
On Sun, Jul 22, 2012 at 2:38 PM, Ronald S. Bultje wrote:
> From: "Ronald S. Bultje"
>
> Mixing yasm and inline asm is a bad idea, since if either yasm or inline
> asm is not supported by your toolchain, all of the asm stops working.
> Thus, better to use either one or the other alone.
> ---
Hi,
On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun wrote:
> On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
>> From: "Ronald S. Bultje"
>>
>> Write out the NAL decoding loops in full so that they are easier to
>> parse for a preprocessor without it having to be aware of macros
On Thu, 19 Jul 2012, Samuel Pitoiset wrote:
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
new file mode 100644
index 000..8ddc5fc
--- /dev/null
+++ b/libavformat/rtmpdh.c
@@ -0,0 +1,329 @@
+/*
+ * RTMP Diffie-Hellmann utilities
+ * Copyright (c) 2012 Samuel Pitoiset
+ *
+ * This f
On 7/23/2012 8:39 AM, Derek Buitenhuis wrote:
On 22/07/2012 10:22 PM, Mashiat Sarker Shakkhar wrote:
OK
PING
Thanks to Anton, the sample is in FATE now.
Ran through FATE locally and pushed. It's been on the fate-suite
servers for ~2 days now, so it should be synched everywhere.
Thanks a l
The rtmpts protocol uses https implicitly, via the ffrtmphttp
protocol, but the ffrtmphttp protocol is also useable for plain
rtmpt without https, so the dependency needs to be added here instead.
---
configure |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/conf
On Fri, 20 Jul 2012, Samuel Pitoiset wrote:
---
Changelog| 1 +
configure| 1 +
doc/general.texi | 2 +-
doc/protocols.texi | 8
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rtmpcrypt.c | 33 ++
From: Adriano Pallavicino
If using a different sample rate or number of channels, use a dynamic
payload type instead, where the parameters are passed in the SDP.
G722 is a special case where the normal rules don't apply.
---
libavformat/rtp.c | 14 +++---
1 file changed, 11 insertions
On Tue, 17 Jul 2012, Adriano Pallavicino wrote:
---
libavformat/rtp.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtp.c b/libavformat/rtp.c
index 6516779..dab8216 100644
--- a/libavformat/rtp.c
+++ b/libavformat/rtp.c
@@ -110,9 +110,10 @@ int ff_rtp_g
On 07/22/2012 03:11 PM, Diego Biurrun wrote:
> ---
> These are baseline suggestions for things that everybody should have.
> Further ideas for things to add more than welcome.
Looks good.
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
_
On 07/23/2012 06:47 AM, Derek Buitenhuis wrote:
> On 23/07/2012 12:37 AM, Kostya Shishkov wrote:
>> Ahem, why?
>
> I think the reasoning was something along the lines of:
>
> "We should try our very bestest to decode broken files."
>
Mind adding support for explode mode?
We have people that wo
On Mon, Jul 23, 2012 at 10:45:46AM +0100, Måns Rullgård wrote:
> Diego Biurrun writes:
> > On Sun, Jul 22, 2012 at 02:04:10AM +0200, Luca Barbato wrote:
> >> On 07/22/2012 12:17 AM, Diego Biurrun wrote:
> >> > All other GPLed internal components that are not glue code for external
> >> > libraries
Diego Biurrun writes:
> On Sun, Jul 22, 2012 at 02:04:10AM +0200, Luca Barbato wrote:
>> On 07/22/2012 12:17 AM, Diego Biurrun wrote:
>> > All other GPLed internal components that are not glue code for external
>> > libraries are not special-cased either.
>> > ---
>> > configure | 12 -
On Sun, Jul 22, 2012 at 02:04:10AM +0200, Luca Barbato wrote:
> On 07/22/2012 12:17 AM, Diego Biurrun wrote:
> > All other GPLed internal components that are not glue code for external
> > libraries are not special-cased either.
> > ---
> > configure | 12
> > 1 files changed, 4 ins
"Ronald S. Bultje" writes:
> Hi,
>
> On Sun, Jul 22, 2012 at 5:35 PM, Måns Rullgård wrote:
>> Diego Biurrun writes:
>>
>>> On Mon, Jul 23, 2012 at 01:16:07AM +0100, Måns Rullgård wrote:
Diego Biurrun writes:
> On Mon, Jul 23, 2012 at 12:16:41AM +0100, Mans Rullgard wrote:
>
On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
> From: "Ronald S. Bultje"
>
> Write out the NAL decoding loops in full so that they are easier to
> parse for a preprocessor without it having to be aware of macros or
> other such things in C code.
>
> This also makes the code m
On Mon, Jul 23, 2012 at 10:17:02AM +0200, Diego Biurrun wrote:
> On Mon, Jul 23, 2012 at 12:47:06AM -0400, Derek Buitenhuis wrote:
> > On 23/07/2012 12:37 AM, Kostya Shishkov wrote:
> > > Ahem, why?
> >
> > I think the reasoning was something along the lines of:
> >
> > "We should try our very be
On Mon, Jul 23, 2012 at 01:35:06AM +0100, Måns Rullgård wrote:
> Diego Biurrun writes:
> > On Mon, Jul 23, 2012 at 01:16:07AM +0100, Måns Rullgård wrote:
> >> Diego Biurrun writes:
> >> > On Mon, Jul 23, 2012 at 12:16:41AM +0100, Mans Rullgard wrote:
> >> >> This allows using non-standard flags f
On Mon, Jul 23, 2012 at 12:47:06AM -0400, Derek Buitenhuis wrote:
> On 23/07/2012 12:37 AM, Kostya Shishkov wrote:
> > Ahem, why?
>
> I think the reasoning was something along the lines of:
>
> "We should try our very bestest to decode broken files."
Do such files exist?
Diego
_
96 matches
Mail list logo
