From: Shivraj Patil
Signed-off-by: Shivraj Patil
---
Makefile | 2 +-
arch.mak | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index ca2ce59..fe0e02f 100644
--- a/Makefile
+++ b/Makefile
@@ -80,7 +80,7 @@ SUBDIR_VARS := CLEANFILES EXAMPLES FFLIBS HOSTPRO
From: Shivraj Patil
Signed-off-by: Shivraj Patil
---
libavcodec/hevcdsp.c|2 +
libavcodec/hevcdsp.h|1 +
libavcodec/mips/Makefile|2 +
libavcodec/mips/hevcdsp_init_mips.c | 54 ++
libavcodec/mips/hevcdsp_mips.h | 49 ++
libavcodec
LGTM.
Thanks,
Nedeljko
Od: ffmpeg-devel-boun...@ffmpeg.org [ffmpeg-devel-boun...@ffmpeg.org] u ime
korisnika Shivraj Patil
Poslato: 17. april 2015 15:12
Za: ffmpeg-devel@ffmpeg.org
Cc: Shivraj Patil
Tema: [FFmpeg-devel] [PATCH 1/2] Makefile: Add support fo
LGTM
Thanks,
Nedeljko
Od: ffmpeg-devel-boun...@ffmpeg.org [ffmpeg-devel-boun...@ffmpeg.org] u ime
korisnika Shivraj Patil
Poslato: 17. april 2015 15:12
Za: ffmpeg-devel@ffmpeg.org
Cc: Shivraj Patil
Tema: [FFmpeg-devel] [PATCH 2/2] avcodec/mips: MSA (MIPS-S
On 17.04.2015 02:01, Luca Barbato wrote:
> On 16/04/15 20:19, Andreas Cadhalpun wrote:
>> On 16.04.2015 19:41, Claudio Freire wrote:
>>> It should be if band->thr > 0.0f, all divisions by zero return
>>> something that casts into an ~1:
>
> is band->thr = 0.0f a valid value?
Come to think of it,
Signed-off-by: Paul B Mahol
---
libavcodec/g729dec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/g729dec.c b/libavcodec/g729dec.c
index 6eb057f..e97677b 100644
--- a/libavcodec/g729dec.c
+++ b/libavcodec/g729dec.c
@@ -421,7 +421,7 @@ static int decode_fram
Signed-off-by: Paul B Mahol
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 440a36b..0f98422 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -405,6 +405,7 @@ const AVCodecTag ff_codec_wav_tags[] = {
{ AV_COD
On Fri, Apr 17, 2015 at 02:37:32PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/g729dec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the RIAA has be
On Fri, Apr 17, 2015 at 02:37:33PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/riff.c | 1 +
> 1 file changed, 1 insertion(+)
LGTM
where can i find such sample ?
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptot
Removing a bunch of questionable hacks makes it work. These hacks
apparently try to make concatenated mp3s with Lame headers seekable,
which doesn't make too much sense anyway. The main change is that we
trust the Xing header file size field now (the same field is used for
seeking with Xing TOC). N
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index c68c389..f1afebb 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -236,7 +236,7 @@ gapless(){
do_md5sum $decfile1
# test decoded (and cut) data
---
I had too many issues with this difference.
---
tests/fate/gapless.mak | 3 ++-
tests/ref/fate/gapless-mp3-notoc | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/gapless-mp3-notoc
diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.m
---
This is somewhat different from seeking to start. Seeking to start
should give exactly the same result as not seeking at all, while
seeking to the middle does not set skip metadata for the first
packet.
---
tests/fate-run.sh | 6 +-
tests/ref/fate/gapless-mp3 | 1 +
2 files change
On 4/17/15, Michael Niedermayer wrote:
> On Fri, Apr 17, 2015 at 02:37:33PM +, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavformat/riff.c | 1 +
>> 1 file changed, 1 insertion(+)
>
> LGTM
>
> where can i find such sample ?
MyTest.wav in incoming.
>
> Thanks
>
> [...]
>
On Fri, Apr 17, 2015 at 01:58:36PM +, Nedeljko Babic wrote:
> LGTM.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything
On Fri, Apr 17, 2015 at 01:58:54PM +, Nedeljko Babic wrote:
> LGTM
applied
thanks
>
> Thanks,
> Nedeljko
>
> Od: ffmpeg-devel-boun...@ffmpeg.org [ffmpeg-devel-boun...@ffmpeg.org] u ime
> korisnika Shivraj Patil
> Poslato: 17. april 2015 15:12
> Za:
On Fri, Apr 17, 2015 at 05:27:00PM +0200, wm4 wrote:
> Removing a bunch of questionable hacks makes it work. These hacks
> apparently try to make concatenated mp3s with Lame headers seekable,
> which doesn't make too much sense anyway. The main change is that we
> trust the Xing header file size fi
On Fri, Apr 17, 2015 at 05:27:01PM +0200, wm4 wrote:
> ---
> tests/fate-run.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
DNS cache poisoning attacks, popular search engine, Google int
On Fri, Apr 17, 2015 at 05:27:02PM +0200, wm4 wrote:
> ---
> This is somewhat different from seeking to start. Seeking to start
> should give exactly the same result as not seeking at all, while
> seeking to the middle does not set skip metadata for the first
> packet.
> ---
> tests/fate-run.sh
On Fri, Apr 17, 2015 at 05:27:03PM +0200, wm4 wrote:
> ---
> I had too many issues with this difference.
> ---
> tests/fate/gapless.mak | 3 ++-
> tests/ref/fate/gapless-mp3-notoc | 5 +
> 2 files changed, 7 insertions(+), 1 deletion(-)
> create mode 100644 tests/ref/fate/gapless-mp
This could be made optional if preferred
---
libavcodec/mpegaudiodec_template.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/mpegaudiodec_template.c
b/libavcodec/mpegaudiodec_template.c
index 2326a90..70c17a1 100644
--- a/libavcodec/mpegaudiodec_template.c
+++ b/libavc
On Fri, 17 Apr 2015 19:04:02 +0200
Michael Niedermayer wrote:
> This could be made optional if preferred
> ---
> libavcodec/mpegaudiodec_template.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/mpegaudiodec_template.c
> b/libavcodec/mpegaudiodec_template.c
> ind
On Fri, Apr 17, 2015 at 07:21:23PM +0200, wm4 wrote:
> On Fri, 17 Apr 2015 19:04:02 +0200
> Michael Niedermayer wrote:
>
> > This could be made optional if preferred
> > ---
> > libavcodec/mpegaudiodec_template.c |7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/libavcode
On Fri, 17 Apr 2015 19:47:50 +0200
Michael Niedermayer wrote:
> On Fri, Apr 17, 2015 at 07:21:23PM +0200, wm4 wrote:
> > On Fri, 17 Apr 2015 19:04:02 +0200
> > Michael Niedermayer wrote:
> >
> > > This could be made optional if preferred
> > > ---
> > > libavcodec/mpegaudiodec_template.c |
On Sun, Apr 12, 2015 at 03:28:15PM +0200, Michael Niedermayer wrote:
> This is what one would expect from the help text
>
> Signed-off-by: Michael Niedermayer
> ---
> tests/tiny_psnr.c |3 +++
> 1 file changed, 3 insertions(+)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6
On Thu, 16 Apr 2015 13:47:20 +0200
wm4 wrote:
> Apparently, some live streams can delete segments too early, maybe
> because the client is too far behind. In this case, it's better to skip
> the segment, instead of returning EOF. (Yes, the HLS demuxer actually
> returns AVERROR_EOF if opening the
This affects a bunch of demuxers, including raw h264.
---
libavformat/rawdec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rawdec.h b/libavformat/rawdec.h
index a464bbb..959dc6e 100644
--- a/libavformat/rawdec.h
+++ b/libavformat/rawdec.h
@@ -67,7 +67,7 @@ AVInp
On Fri, Apr 17, 2015 at 09:59:36PM +0200, wm4 wrote:
> This affects a bunch of demuxers, including raw h264.
> ---
> libavformat/rawdec.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
this breaks fate-hevc-paramchange-yuv420p-yuv420p10
[...]
--
Michael GnuPG fingerprint: 9FF2128B
On Fri, 17 Apr 2015 22:52:07 +0200
Michael Niedermayer wrote:
> On Fri, Apr 17, 2015 at 09:59:36PM +0200, wm4 wrote:
> > This affects a bunch of demuxers, including raw h264.
> > ---
> > libavformat/rawdec.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> this breaks fate-hevc-par
On Thu, Apr 16, 2015 at 01:47:20PM +0200, wm4 wrote:
> Apparently, some live streams can delete segments too early, maybe
> because the client is too far behind. In this case, it's better to skip
> the segment, instead of returning EOF. (Yes, the HLS demuxer actually
> returns AVERROR_EOF if openin
On 17.04.2015 23:39, Luca Barbato wrote:
> On 17/04/15 16:08, Andreas Cadhalpun wrote:
>> On 17.04.2015 02:01, Luca Barbato wrote:
>>> is band->thr = 0.0f a valid value?
>>
>> Come to think of it, that's probably invalid.
I retract that, it seems band->thr = 0.0f is valid.
>> It can happen if coe
On Fri, Apr 17, 2015 at 11:24:41PM +0200, wm4 wrote:
> On Fri, 17 Apr 2015 22:52:07 +0200
> Michael Niedermayer wrote:
>
> > On Fri, Apr 17, 2015 at 09:59:36PM +0200, wm4 wrote:
> > > This affects a bunch of demuxers, including raw h264.
> > > ---
> > > libavformat/rawdec.h | 2 +-
> > > 1 file
Signed-off-by: James Almer
---
libavcodec/dcaenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/dcaenc.c b/libavcodec/dcaenc.c
index d57d658..c8a215c 100644
--- a/libavcodec/dcaenc.c
+++ b/libavcodec/dcaenc.c
@@ -847,8 +847,7 @@ static void put_subframe_samples
Signed-off-by: James Almer
---
libavcodec/wavpackenc.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
index c174950..87f1445 100644
--- a/libavcodec/wavpackenc.c
+++ b/libavcodec/wavpackenc.c
@@ -2143,7 +2143,6 @@ s
Signed-off-by: James Almer
---
libavcodec/aaccoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
index f07e523..2929f3a 100644
--- a/libavcodec/aaccoder.c
+++ b/libavcodec/aaccoder.c
@@ -210,7 +210,7 @@ static av_always_inline
Hi,
On Fri, Apr 17, 2015 at 10:29 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/wavpackenc.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
> index c174950..87f1445 100644
> --- a/li
On Sat, Apr 18, 2015 at 12:55:08AM +0200, Andreas Cadhalpun wrote:
> On 17.04.2015 23:39, Luca Barbato wrote:
> > On 17/04/15 16:08, Andreas Cadhalpun wrote:
> >> On 17.04.2015 02:01, Luca Barbato wrote:
> >>> is band->thr = 0.0f a valid value?
> >>
> >> Come to think of it, that's probably invalid
On Wed, Apr 8, 2015 at 8:15 PM, Michael Niedermayer
wrote:
> On Wed, Apr 08, 2015 at 07:58:19PM +0200, Mariusz SzczepaĆczyk wrote:
> > On Wed, Apr 8, 2015 at 6:33 PM, Michael Niedermayer
> > wrote:
> >
> > > Hi
> > >
> > > Some people on IRC asked about the uses of the AVIODir* API and it
> > >
Signed-off-by: James Almer
---
libavcodec/dca_xll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
index 9e1085c..98fd4c8 100644
--- a/libavcodec/dca_xll.c
+++ b/libavcodec/dca_xll.c
@@ -393,7 +393,7 @@ static void dca_xll_inv_a
Signed-off-by: James Almer
---
libavcodec/adpcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 1c3fdc4..56d1660 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -1498,7 +1498,7 @@ static int adpcm_decode_frame(AVCodec
40 matches
Mail list logo