On Tue, Dec 29, 2015 at 6:18 AM, Rostislav Pehlivanov
wrote:
> Wouldn't it be simpler to just check if the maximum codebook was 0 after
> calculating cost1 and skipping the rest of the code in the loop?
>
> On 29 December 2015 at 08:23, Claudio Freire
Hi,
On Tue, Dec 29, 2015 at 11:29 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Hi,
>
> On 29.12.2015 17:15, Ronald S. Bultje wrote:
> > On Tue, Dec 29, 2015 at 11:07 AM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >> On 29.12.2015 16:58, Ronald S.
Hi,
On Tue, Dec 29, 2015 at 12:25 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
> On Tue, Dec 29, 2015 at 02:12:44AM +, Rostislav Pehlivanov wrote:
> > +#define DAALAENT_PVQ_NOVAL(-2147483647-1)
>
> why is the 1 not already subtracted in the written value ?
I think it's
On Tue, Dec 29, 2015 at 3:04 AM, Stefano Sabatini wrote:
> On date Wednesday 2015-12-23 09:56:17 -0800, Ganesh Ajjanagadde encoded:
>> These are just for prefixes and may be hardcoded easily; see lavu/eval
>> for this approach.
>>
>> Signed-off-by: Ganesh Ajjanagadde
On 29.12.2015 03:12, Rostislav Pehlivanov wrote:
> Hmm, kinda odd.
> I've attached a v2 of the RFC Patch which does this:
> 1. Fixed some typos.
> 2. Fixed some missing newlines at the end of daalatab*
> 3. Moves the pix_fmt finding function inside the main decoder file.
>
> Try building now.
Tables are bit identical.
Sample benchmark (Haswell, GNU/Linux+gcc):
old:
814485 decicycles in dsd_ctables_tableinit, 512 runs, 0 skips
new:
356808 decicycles in dsd_ctable_tableinit, 512 runs, 0 skips
Binary size should essentially be identical, and is in fact identical on
On Tue, Dec 29, 2015 at 04:56:26PM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer niedermayer.cc> writes:
>
> > > https://drive.google.com/open?id=0B3_pEBoLs0faUlItWm9KaGJSTEE
> >
> > patch applied
>
> How exactly did you test this?
it is neccessary to also fix the decoder to test, this
On Tue, Dec 29, 2015 at 02:12:44AM +, Rostislav Pehlivanov wrote:
> Hmm, kinda odd.
> I've attached a v2 of the RFC Patch which does this:
> 1. Fixed some typos.
> 2. Fixed some missing newlines at the end of daalatab*
> 3. Moves the pix_fmt finding function inside the main decoder file.
[...]
On Tue, Dec 29, 2015 at 10:42 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Dec 29, 2015 at 12:25 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Tue, Dec 29, 2015 at 02:12:44AM +, Rostislav Pehlivanov wrote:
>> > +#define DAALAENT_PVQ_NOVAL
Hi,
On Tue, Dec 29, 2015 at 10:55 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> > +static av_always_inline void idct_1D_8(pixel *x, int xstride, const
> pixel y[16])
> > +{
> > +int t1h, t4h, t6h, t0 = y[0], t1 = y[1], t2 = y[2], t3 = y[3], t4 =
> y[4];
> > +int t5 =
This fixes crashes caused by out-of-bounds writes.
Signed-off-by: Andreas Cadhalpun
---
libavformat/oggparsedaala.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/oggparsedaala.c b/libavformat/oggparsedaala.c
index dda8d70..24567f9 100644
Hi,
On 29.12.2015 17:15, Ronald S. Bultje wrote:
> On Tue, Dec 29, 2015 at 11:07 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> On 29.12.2015 16:58, Ronald S. Bultje wrote:
>>> On Tue, Dec 29, 2015 at 10:55 AM, Andreas Cadhalpun <
>>> andreas.cadhal...@googlemail.com>
Michael Niedermayer niedermayer.cc> writes:
> > https://drive.google.com/open?id=0B3_pEBoLs0faUlItWm9KaGJSTEE
>
> patch applied
How exactly did you test this?
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Wed, Dec 23, 2015 at 3:29 PM, Hendrik Leppkes wrote:
> Am 23.12.2015 19:47 schrieb "Ganesh Ajjanagadde" :
>>
>> On Wed, Dec 23, 2015 at 10:02 AM, Hendrik Leppkes
> wrote:
>> > Am 23.12.2015 18:30 schrieb "Ganesh Ajjanagadde"
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 5
libavfilter/avf_showspectrum.c | 57 +++---
2 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index e1b3c69..adcbd58
Michael Niedermayer niedermayer.cc> writes:
> On Tue, Dec 29, 2015 at 04:56:26PM +, Carl Eugen Hoyos wrote:
> > Michael Niedermayer niedermayer.cc> writes:
> >
> > > > https://drive.google.com/open?id=0B3_pEBoLs0faUlItWm9KaGJSTEE
> > >
> > > patch applied
> >
> > How exactly did you test
Hi,
On Tue, Dec 29, 2015 at 11:49 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 29.12.2015 17:32, Ronald S. Bultje wrote:
> > On Tue, Dec 29, 2015 at 11:29 AM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >> On 29.12.2015 17:15, Ronald S. Bultje
On 29.12.2015 16:58, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Dec 29, 2015 at 10:55 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>>> +static av_always_inline void idct_1D_8(pixel *x, int xstride, const
>> pixel y[16])
>>> +{
>>> +int t1h, t4h, t6h, t0 = y[0], t1 =
Hi,
On Tue, Dec 29, 2015 at 11:07 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 29.12.2015 16:58, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, Dec 29, 2015 at 10:55 AM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >>> +static av_always_inline
On Mon, Dec 28, 2015 at 10:27 PM, Matt Oliver wrote:
> On 29 December 2015 at 11:51, Ganesh Ajjanagadde
> wrote:
>
>> On Mon, Dec 28, 2015 at 8:22 AM, Paul B Mahol wrote:
>> > On 12/27/15, Ganesh Ajjanagadde
The table is highly structured, so pow (or exp2 for that matter) can entirely
be avoided, yielding a ~ 40x speedup with no loss of accuracy.
sample benchmark (Haswell, GNU/Linux):
new:
4449 decicycles in init_pow2table(loop 1000), 254 runs, 2 skips
4411 decicycles in init_pow2table(loop
On 29.12.2015 17:57, Rostislav Pehlivanov wrote:
> LGTM,
Pushed.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 29.12.2015 17:32, Ronald S. Bultje wrote:
> On Tue, Dec 29, 2015 at 11:29 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>> On 29.12.2015 17:15, Ronald S. Bultje wrote:
>>> In that case, you likely need 64bit integers for 15bit math precision
>> (look at
>>> vp9 code), or
Previous commit has sped up dsd_tablegen, and now table generation takes
~ 40k cycles. Thus, these tables can always be generated at runtime.
Tested with/without --enable-hardcoded-tables.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/Makefile | 4 +---
LGTM,
Thanks
On 29 December 2015 at 16:09, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> This fixes crashes caused by out-of-bounds writes.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/oggparsedaala.c | 6 ++
> 1 file changed,
Also use uint32_t for the shift calculation, as 1 << 31 is undefined
for int32_t.
This fixes ubsan runtime error: shift exponent is too large for
32-bit type 'int'
Signed-off-by: Andreas Cadhalpun
---
libavformat/oggparsedaala.c | 7 ++-
1 file changed, 6
On 29.12.2015 22:27, Rostislav Pehlivanov wrote:
> oggparsetheora has the same bit of code to read the gpshift, so it would
> probably be a good idea to add it to this patch as well.
No, oggparsetheora only reads 5 bits for gpshift.
The only thing from this patch that also applies there is the
Michael Niedermayer niedermayer.cc> writes:
> > If you cannot test, how do you know it is correct?
>
> it works with the now available patch fixing the decoder and the
> Earth\ Spin\ 1-bit\ qtrle.mov
> file
Sorry, it seems I am very slow today:
What does "it works" mean here?
Carl Eugen
llowing:
$ git checkout b0e23f2a37b45e8fa7e9ae91301d0ef572e80181
$ wget
http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151229/c12907af/attachment.bin
$ md5sum attachment.bin
1656289c65333dab470046c3dc96 attachment.bin
$ patch -p1http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
am very slow today:
> > > What does "it works" mean here?
> >
> > its blue not black and white
>
> I tested the following:
> $ git checkout b0e23f2a37b45e8fa7e9ae91301d0ef572e80181
> $ wget
> http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/2015
On Tue, Dec 29, 2015 at 5:09 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Dec 29, 2015 at 6:54 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> Hi,
>>
>> On 29.12.2015 19:46, Ronald S. Bultje wrote:
>> > On Tue, Dec 29, 2015 at 11:49 AM, Andreas
://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151229/c12907af/attachment.bin
> $ md5sum attachment.bin
> 1656289c65333dab470046c3dc96 attachment.bin
> $ patch -p1 $ ./configure && make ffplay
> $ ffplay Earth\ Spin\ 1-bit\ qtrle.mov
>
> Looks black and white here,
On Tue, Dec 29, 2015 at 4:00 PM, Andreas Cadhalpun
wrote:
> On 29.12.2015 22:27, Rostislav Pehlivanov wrote:
>> oggparsetheora has the same bit of code to read the gpshift, so it would
>> probably be a good idea to add it to this patch as well.
>
> No,
Michael Niedermayer niedermayer.cc> writes:
> i tested with ffplay, and there it works
I tested the following:
$ git checkout b0e23f2a37b45e8fa7e9ae91301d0ef572e80181
$ wget
http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151229/c12907af/attachment.bin
$ md5sum attachme
Mats Peterson ffmpeg.org> writes:
> Below are links to sample files, which should now be
> displayed properly with bluish colors
Just to make sure:
Please do not apply this patch until above is clarified.
Carl Eugen
___
ffmpeg-devel mailing list
Signed-off-by: Ricardo Constantino
---
configure | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index c986aba..d639b8d 100755
--- a/configure
+++ b/configure
@@ -5396,7 +5396,6 @@ enabled avisynth && { {
On Wed, Dec 30, 2015 at 12:23 AM, Roger Pack wrote:
>> OK I had this great idea to capture the incoming MPEG2 transport
>> stream from the digital TV capture device. Kind of like "raw" stream,
>> so FFmpeg could have access to, for instance, all the audio stream.
>>
>> It
Hi,
On 29.12.2015 19:46, Ronald S. Bultje wrote:
> On Tue, Dec 29, 2015 at 11:49 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>> Do you have a sample causing overflows in the vp9 decoder?
>
>
> Nope, but I'm going to assume they're not hard to create, just use a few
> high
On 29.12.2015 22:34, Rostislav Pehlivanov wrote:
>> This is an infinite loop that can hang the decoder.
> Will try to get the upstream to accept a fix.
Thanks.
>> overflows in the entropy decoding system
> The assertions should be able to catch them, so they should be fine.
Are you talking
On 30.12.2015 01:04, Ganesh Ajjanagadde wrote:
> On Tue, Dec 29, 2015 at 4:00 PM, Andreas Cadhalpun
> wrote:
>> On 29.12.2015 22:27, Rostislav Pehlivanov wrote:
>>> oggparsetheora has the same bit of code to read the gpshift, so it would
>>> probably be a good
On Tue, Dec 29, 2015 at 09:28:34AM -0800, Ganesh Ajjanagadde wrote:
> The table is highly structured, so pow (or exp2 for that matter) can entirely
> be avoided, yielding a ~ 40x speedup with no loss of accuracy.
>
> sample benchmark (Haswell, GNU/Linux):
> new:
> 4449 decicycles in
The following patch fixes the lack of palettized display of 1-bit video
in the qtrle decoder. It is related to my previous patch of
lavf/qtpalette, which added 1-bit video to the "palettized video"
category. As far as I can see, everything works fine, but comments are
of course welcome.
Below
Mats Peterson ffmpeg.org> writes:
> Below are links to sample files, which should now be
> displayed properly with bluish colors
Sorry, I am not a native speaker:
Could you explain what "should" means in
above sentence?
Please trim your quotes, Carl Eugen
Mats Peterson ffmpeg.org> writes:
> On 12/29/2015 11:37 PM, Carl Eugen Hoyos wrote:
> > Mats Peterson ffmpeg.org> writes:
> >
> >> Below are links to sample files, which should now be
> >> displayed properly with bluish colors
> >
> > Sorry, I am not a native speaker:
> > Could you explain
On 12/29/2015 11:48 PM, Carl Eugen Hoyos wrote:
Could you explain what "should" means in
above sentence?
Please try to answer this question, do not
repeat things that all developers already
understood when you told us two weeks ago.
This is a whole different issue from the one I was
> OK I had this great idea to capture the incoming MPEG2 transport
> stream from the digital TV capture device. Kind of like "raw" stream,
> so FFmpeg could have access to, for instance, all the audio stream.
>
> It appears that the type coming out of the tuner is:
> MEDIATYPE_Stream
> with
On Tue, Dec 29, 2015 at 4:14 PM, Andreas Cadhalpun
wrote:
> On 30.12.2015 01:04, Ganesh Ajjanagadde wrote:
>> On Tue, Dec 29, 2015 at 4:00 PM, Andreas Cadhalpun
>> wrote:
>>> On 29.12.2015 22:27, Rostislav Pehlivanov wrote:
On 12/29/2015 11:54 PM, Carl Eugen Hoyos wrote:
Mats Peterson ffmpeg.org> writes:
Below are links to sample files, which should now be
displayed properly with bluish colors
Just to make sure:
Please do not apply this patch until above is clarified.
Carl Eugen
I'm not the one to apply
On Wed, Dec 30, 2015 at 12:33 AM, Hendrik Leppkes wrote:
> On Wed, Dec 30, 2015 at 12:23 AM, Roger Pack wrote:
>>> OK I had this great idea to capture the incoming MPEG2 transport
>>> stream from the digital TV capture device. Kind of like "raw"
On Tue, Dec 29, 2015 at 05:42:26PM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer niedermayer.cc> writes:
>
> > On Tue, Dec 29, 2015 at 04:56:26PM +, Carl Eugen Hoyos wrote:
> > > Michael Niedermayer niedermayer.cc> writes:
> > >
> > > > >
On Wed, Dec 30, 2015 at 12:00:20AM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer niedermayer.cc> writes:
>
> > > If you cannot test, how do you know it is correct?
> >
> > it works with the now available patch fixing the decoder and the
> > Earth\ Spin\ 1-bit\ qtrle.mov
> > file
>
>
Signed-off-by: Marton Balint
---
libavformat/concatdec.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index d21805f..d226e15 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@
Wait at most outpoint_interleave_delay at outpoint before considering it an
end of file condition.
Signed-off-by: Marton Balint
---
doc/demuxers.texi | 20
libavformat/concatdec.c | 13 ++---
2 files changed, 26 insertions(+), 7 deletions(-)
Hi,
On Tue, Dec 29, 2015 at 6:54 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Hi,
>
> On 29.12.2015 19:46, Ronald S. Bultje wrote:
> > On Tue, Dec 29, 2015 at 11:49 AM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >> Do you have a sample causing
ff_clz is faster, and uses an intrinsic (at the moment on GCC). exp2 is
a wasteful function for a simple integer exponentiation.
Untested.
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/af_sofalizer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
On 12/29/2015 06:42 PM, Carl Eugen Hoyos wrote:
Michael Niedermayer niedermayer.cc> writes:
On Tue, Dec 29, 2015 at 04:56:26PM +, Carl Eugen Hoyos wrote:
Michael Niedermayer niedermayer.cc> writes:
https://drive.google.com/open?id=0B3_pEBoLs0faUlItWm9KaGJSTEE
patch applied
How
On Tue, Dec 29, 2015 at 11:29 AM, Clément Bœsch wrote:
> On Tue, Dec 29, 2015 at 09:28:34AM -0800, Ganesh Ajjanagadde wrote:
>> The table is highly structured, so pow (or exp2 for that matter) can entirely
>> be avoided, yielding a ~ 40x speedup with no loss of accuracy.
>>
>> sample
Signed-off-by: Ricardo Constantino
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index e3b7904..6d41343 100755
--- a/configure
+++ b/configure
@@ -5396,7 +5396,7 @@ enabled avisynth && { { check_lib2
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/avf_ahistogram.c | 235 +++
3 files changed, 237 insertions(+)
create mode 100644 libavfilter/avf_ahistogram.c
diff
Le nonidi 9 nivôse, an CCXXIV, Ricardo Constantino a écrit :
> Signed-off-by: Ricardo Constantino
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index e3b7904..6d41343 100755
> --- a/configure
> +++
On 29 December 2015 at 22:17, Nicolas George wrote:
>
> This should be using libgcrypt-config, as per documentation:
>
> https://gnupg.org/documentation/manuals/gcrypt/Building-sources.html
>
> Otherwise, we have to duplicate the effort each time a dependency changes.
>
>
Hi,
Thanks for the feedback.
>This is an infinite loop that can hang the decoder.
Will try to get the upstream to accept a fix.
>overflows in the entropy decoding system
The assertions should be able to catch them, so they should be fine.
They'll trigger if there's a desync with the bitstream. I
> > > > +case MKTAG('e','n','c','v'):// encrypted video
> > > > +case MKTAG('e','n','c','a'):// encrypted audio
> > > > +id = mov_codec_id(st, format);
> > > > +st->codec->codec_id = id;
> > >
> > > this seems missing a check for st->codec->codec_id being
oggparsetheora has the same bit of code to read the gpshift, so it would
probably be a good idea to add it to this patch as well.
On 29 December 2015 at 17:55, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Also use uint32_t for the shift calculation, as 1 << 31 is undefined
>
Trying to use gcrypt-enabled FFmpeg with rtmpe returns a few errors:
Fatal: failed to create the RNG lock: Invalid argument
FATAL: failed to acquire the FSM lock in libgrypt: Invalid argument
This is probably not how or where this should be done, but it does fix the
problem for me.
You can test
On 12/29/2015 11:41 PM, Mats Peterson wrote:
On 12/29/2015 11:37 PM, Carl Eugen Hoyos wrote:
Mats Peterson ffmpeg.org> writes:
Below are links to sample files, which should now be
displayed properly with bluish colors
Sorry, I am not a native speaker:
Could you explain what "should" means
On Tue, Dec 29, 2015 at 6:55 PM, Andreas Cadhalpun
wrote:
> Also use uint32_t for the shift calculation, as 1 << 31 is undefined
> for int32_t.
>
> This fixes ubsan runtime error: shift exponent is too large for
> 32-bit type 'int'
>
> Signed-off-by: Andreas
On 12/29/2015 11:37 PM, Carl Eugen Hoyos wrote:
Mats Peterson ffmpeg.org> writes:
Below are links to sample files, which should now be
displayed properly with bluish colors
Sorry, I am not a native speaker:
Could you explain what "should" means in
above sentence?
Please trim your quotes,
Signed-off-by: Lou Logan
---
doc/filters.texi | 8
1 file changed, 8 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index e1b3c69..45e1338 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14823,6 +14823,14 @@ in a 1024x800 picture using
On Tue, Dec 29, 2015 at 7:13 PM, Rostislav Pehlivanov
wrote:
> I agree with BBB (Ronald), this project claims to have the fastest decoders
> available and we shouldn't sacrifice performance. Since basically the only
> input of the decoder goes through the entropy decoding
The log is anyway rounded to an integer, so one may use an frexp
based approach. Note that this may be made frexpf; if arguments are less than
2^24 there is no loss. Kept as double precision for simplicity; 2^32 is
exactly representable as a double.
Signed-off-by: Ganesh Ajjanagadde
On 12/30/2015 04:38 AM, Carl Eugen Hoyos wrote:
Michael Niedermayer niedermayer.cc> writes:
md5sum Earth\ Spin\ 1-bit\ qtrle.mov
2a73988ea94a1201a9cf477d71d3ff29 Earth Spin 1-bit qtrle.mov
Mats has indeed decided to offer different files
with the same name for download.
I suggest we test
On 12/30/2015 05:25 AM, Mats Peterson wrote:
On 12/30/2015 04:38 AM, Carl Eugen Hoyos wrote:
Michael Niedermayer niedermayer.cc> writes:
md5sum Earth\ Spin\ 1-bit\ qtrle.mov
2a73988ea94a1201a9cf477d71d3ff29 Earth Spin 1-bit qtrle.mov
Mats has indeed decided to offer different files
with
Solves an issue that will get triggered when gcc 20 rolls in.
Found-by: Hendrik Leppkes
Signed-off-by: Ganesh Ajjanagadde
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index
Michael Niedermayer niedermayer.cc> writes:
> md5sum Earth\ Spin\ 1-bit\ qtrle.mov
> 2a73988ea94a1201a9cf477d71d3ff29 Earth Spin 1-bit qtrle.mov
Mats has indeed decided to offer different files
with the same name for download.
I suggest we test the original unchanged file.
(Although it's of
On 12/30/2015 01:26 AM, Carl Eugen Hoyos wrote:
Michael Niedermayer niedermayer.cc> writes:
i tested with ffplay, and there it works
I tested the following:
$ git checkout b0e23f2a37b45e8fa7e9ae91301d0ef572e80181
$ wget
http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151229/c1290
The QuickTime File Format Specification states the following:
"Depth: A 16-bit integer that indicates the pixel depth of the
compressed image. Values of 1, 2, 4, 8 ,16, 24, and 32 indicate the
depth of color images. The value 32 should be used only if the image
contains an alpha channel. Values
On 12/30/2015 08:17 AM, Mats Peterson wrote:
When comparing the output in QuickTime and FFmpeg, I noticed that the
background is blue in FFmpeg, while it is white (or transparent, if you
will) in QuickTime. Hold your horses on this patch.
Mats
I noticed that the "alpha" component (there is
I agree with BBB (Ronald), this project claims to have the fastest decoders
available and we shouldn't sacrifice performance. Since basically the only
input of the decoder goes through the entropy decoding system occasionally
checking for overflows in a few performance sensitive parts there is
On 12/30/2015 05:19 AM, Mats Peterson wrote:
Carl, perhaps you missed to compile MPlayer using the very latest FFmpeg?
Mats
Forget that suggestion, I thought the patch was applied already. In any
case, I have patched qtrle.c in both FFmpeg and MPlayer here, and the
rotating earth movie is
On 12/30/2015 05:47 AM, Mats Peterson wrote:
The original .mov file has the grayscale bit set in the bit depth field
of the video sample description, but since that seemed highly illogical
to me, I cleared it for the purposes of this demonstration. For some
reason, QuickTime in Win or Mac
On 30 December 2015 at 03:15, Ganesh Ajjanagadde wrote:
> On Mon, Dec 28, 2015 at 10:27 PM, Matt Oliver
> wrote:
> > On 29 December 2015 at 11:51, Ganesh Ajjanagadde >
> > wrote:
> >
> >> On Mon, Dec 28, 2015 at 8:22 AM, Paul B
On 12/28/2015 1:58 PM, Rostislav Pehlivanov wrote:
> Not much to say about this other than "it works".
>
If this parser is needed to get the muxing code from patch 3/3 working then it
may be a good idea to commit the relevant functions from the decoder with this
first, assuming what it needs
On 12/30/2015 12:43 AM, Michael Niedermayer wrote:
it works with the now available patch fixing the decoder and the
Earth\ Spin\ 1-bit\ qtrle.mov
file
I dont know if bugs remain, if there are any bugs/issues left, they
should be fixed of course ...
I don't know what he's doing on his side.
On 12/29/2015 11:08 PM, Mats Peterson wrote:
The following patch fixes the lack of palettized display of 1-bit video
in the qtrle decoder. It is related to my previous patch of
lavf/qtpalette, which added 1-bit video to the "palettized video"
category. As far as I can see, everything works fine,
Wouldn't it be simpler to just check if the maximum codebook was 0 after
calculating cost1 and skipping the rest of the code in the loop?
On 29 December 2015 at 08:23, Claudio Freire wrote:
> Fixes an assertion error reported in #2686 that happens when
> using prediction
Fixes an assertion error reported in #2686 that happens when
using prediction (either explicitly or implicitly by setting
the AAC main profile), since prediction code would allow
creating new zeroes or removing existing ones, without
properly checking for SF delta violations.
This patch forbids
On Tue, Dec 29, 2015 at 07:38:04AM +0100, Mats Peterson wrote:
> I forgot some stuff. Patch description follows:
>
> This patch for qtpalette.c and qtpalette.h adds 1-bit video to the
> "palettized video" category, since if the video sample description
> contains a palette, the two colors in the
On Tue, Dec 29, 2015 at 02:12:44AM +, Rostislav Pehlivanov wrote:
> Hmm, kinda odd.
> I've attached a v2 of the RFC Patch which does this:
> 1. Fixed some typos.
> 2. Fixed some missing newlines at the end of daalatab*
> 3. Moves the pix_fmt finding function inside the main decoder file.
>
>
On date Tuesday 2015-06-16 17:28:17 -0500, Rodger Combs encoded:
> ---
> ffprobe.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/ffprobe.c b/ffprobe.c
> index 3e5324e..d54eb87 100644
> --- a/ffprobe.c
> +++ b/ffprobe.c
> @@ -2436,6 +2436,10 @@ static int show_format(WriterContext
On date Wednesday 2015-12-23 09:56:17 -0800, Ganesh Ajjanagadde encoded:
> These are just for prefixes and may be hardcoded easily; see lavu/eval
> for this approach.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> ffprobe.c | 27 +++
> 1 file
Reynaldo H. Verdejo Pinochet osg.samsung.com> writes:
> Looks good.
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, Dec 28, 2015 at 11:04:08PM -0800, Mark Harris wrote:
> get_ue_golomb() cannot decode values larger than 8190 (the maximum
> value that can be golomb encoded in 25 bits) and produces the error
> "Invalid UE golomb code" if a larger value is encountered. Use
> get_ue_golomb_long() instead
On 12/29/2015 11:56 AM, Michael Niedermayer wrote:
On Tue, Dec 29, 2015 at 07:38:04AM +0100, Mats Peterson wrote:
I forgot some stuff. Patch description follows:
This patch for qtpalette.c and qtpalette.h adds 1-bit video to the
"palettized video" category, since if the video sample
On Mon, Dec 21, 2015 at 08:45:34AM -0500, Joel Loeshelle wrote:
> I am trying to stream from a local SDP file that contains the information
> necessary for streaming from an IP camera on a separate network. The IP
> camera is behind a NAT router so I first need to send dummy packets to set
> up
On Mon, Dec 28, 2015 at 09:27:41PM +, Eran Kornblau wrote:
> > > +case MKTAG('e','n','c','v'):// encrypted video
> > > +case MKTAG('e','n','c','a'):// encrypted audio
> > > +id = mov_codec_id(st, format);
> > > +st->codec->codec_id = id;
> >
> > this
96 matches
Mail list logo