On Wed, Mar 09, 2016 at 02:20:35PM -0300, Claudio Freire wrote:
> On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde
> wrote:
> > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
> > wrote:
> > No idea about this. However, here is some info.
> > The regression in speed dates to: 01ecb7172b684f1c
On Wed, Mar 09, 2016 at 10:27:29AM -0800, NagaChaitanya Vellanki wrote:
> On Tue, Mar 8, 2016 at 5:33 PM, James Almer wrote:
>
> > On 3/8/2016 2:21 AM, NagaChaitanya Vellanki wrote:
> > > ---
> > > libavutil/Makefile | 1 +
> > > libavutil/hash.c | 42 +
On Wed, Mar 09, 2016 at 09:04:29PM +0100, Michael Niedermayer wrote:
> On Wed, Mar 09, 2016 at 07:32:29PM +0100, Reimar Döffinger wrote:
> > On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> > > On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wro
On 10.03.2016, at 03:06, Ganesh Ajjanagadde wrote:
> On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
> wrote:
>> On 08.03.2016, at 04:48, Ganesh Ajjanagadde wrote:
>>
>>> +nzl += expf(logf(s / ethresh) * nzslope);
>>
>> Shouldn
On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
> There is no reason for computing cbrtf at runtime; we have a table for
> this.
>
> Cruft needed due to the build system, the people who still like using
> hardcoded tables and need for single cbrt_tab across the code.
Could you please explain
On 10.03.2016, at 12:01, Ismail Donmez wrote:
> On Thu, Mar 10, 2016 at 12:04 PM, wm4 wrote:
>> On Thu, 10 Mar 2016 16:53:12 +0700
>> Muhammad Faiz wrote:
>>
>>> I use intrinsic because writing asm using nasm or inline asm
>>> is difficult task for me.
>>>
>>> [PATCH 1/3] configure: add x86 i
On 11.03.2016, at 03:48, Ganesh Ajjanagadde wrote:
> On Thu, Mar 10, 2016 at 3:12 AM, Reimar Döffinger
> wrote:
>> On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
>>
>>> There is no reason for computing cbrtf at runtime; we have a table for
>>> this.
&g
On 11.03.2016, at 05:16, Ganesh Ajjanagadde wrote:
> Code taken from the Julia project, licensed under MIT:
> https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn
> derived from: "The Ziggurat Method for generating random variables" -
> Marsaglia and Tsang.
>
> Paper and refere
void ff_cbrt_tableinit_fixed(void);
+av_cold void ff_cbrt_tableinit(void);
-for (i = 0; i < 1<<13; i++)
-cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]);
-}
-}
#endif /* CONFIG_HARDCODED_TABLES */
#endif /* AVCODEC_CBRT_TABLEGEN_H */
diff --git a/libavcodec/cbrt_ta
On Sat, Mar 12, 2016 at 11:11:32AM -0500, Ganesh Ajjanagadde wrote:
> On Sat, Mar 12, 2016 at 11:02 AM, Michael Niedermayer
> wrote:
> >> +static inline double ziggurat(AVLFG *lfg)
> >> +{
> >> +while (1) {
> >
> >> +uint64_t r = (((uint64_t)av_lfg_get(lfg) << 32) +
> >> av_lfg_get(lf
On Sat, Mar 12, 2016 at 12:09:13PM -0500, Ganesh Ajjanagadde wrote:
> And yes, for me the proof of the pudding is in the eating. In other
> words, if you or someone else sends a small, simple patch achieving
> the above one-line change, I will be very happy and will learn
> something.
Does that me
On Sat, Mar 12, 2016 at 12:09:13PM -0500, Ganesh Ajjanagadde wrote:
> And yes, for me the proof of the pudding is in the eating. In other
> words, if you or someone else sends a small, simple patch achieving
> the above one-line change, I will be very happy and will learn
> something.
I don't thin
Allows sharing and reusing the data between different files.
Signed-off-by: Reimar Döffinger
---
libavcodec/Makefile | 10 +-
libavcodec/aacdec.c | 2 +-
libavcodec/aacdec_fixed.c | 6 +++---
libavcodec/aacdec_template.c| 4
On Sun, Mar 13, 2016 at 12:24:25PM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger
> wrote:
> > for (i = 0; i < 1<<13; i++)
> > -cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]);
> > +AAC_RENAME(ff_c
On Sun, Mar 13, 2016 at 05:50:17PM +0100, Hendrik Leppkes wrote:
> On Sun, Mar 13, 2016 at 5:24 PM, Ganesh Ajjanagadde
> wrote:
> >> @@ -75,9 +66,8 @@ static av_cold void AAC_RENAME(cbrt_tableinit)(void)
> >> }
> >>
> >> for (i = 0; i < 1<<13; i++)
> >> -cbrt_tab[i]
On Sun, Mar 13, 2016 at 05:53:10PM +0100, Reimar Döffinger wrote:
> On Sun, Mar 13, 2016 at 05:50:17PM +0100, Hendrik Leppkes wrote:
> > On Sun, Mar 13, 2016 at 5:24 PM, Ganesh Ajjanagadde
> > wrote:
> > >> @@ -75,9 +66,8 @@ static av_cold void AAC_
On Sun, Mar 13, 2016 at 01:12:57PM -0400, Ganesh Ajjanagadde wrote:
> On Sun, Mar 13, 2016 at 12:49 PM, Reimar Döffinger
> wrote:
> > On Sun, Mar 13, 2016 at 12:24:25PM -0400, Ganesh Ajjanagadde wrote:
> >> On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger
> >> wro
On Sun, Mar 13, 2016 at 06:14:18PM +0100, Reimar Döffinger wrote:
> On Sun, Mar 13, 2016 at 01:12:57PM -0400, Ganesh Ajjanagadde wrote:
> > On Sun, Mar 13, 2016 at 12:49 PM, Reimar Döffinger
> > wrote:
> > > On Sun, Mar 13, 2016 at 12:24:25PM -0400, Ganesh Ajjanagadde wrot
On Sun, Mar 13, 2016 at 01:27:52PM -0400, Ganesh Ajjanagadde wrote:
> On Sun, Mar 13, 2016 at 1:21 PM, Reimar Döffinger
> wrote:
> >> > I don't understand the waste; the double init anyway needs to be done,
> >> > all tables are derived from it. This dates to
On 13.03.2016, at 19:11, Ganesh Ajjanagadde wrote:
> On Sun, Mar 13, 2016 at 1:46 PM, Reimar Döffinger
> wrote:
>>
>>>
>>> --enable-hardcoded-tables partially does that; it increases memory
>>> usage as tables are burnt into the library at some gains
On Tue, Mar 08, 2016 at 02:48:04PM +0200, Ismail Donmez wrote:
> This fixes cross-build on Linux with mingw-w64. Patch attached. This
> will not break MSVC because Windows is case-insensitive unlike Linux.
>
> Please review.
I see this:
libavformat/tls_schannel.c:#include
libavformat/tls_securet
On Tue, Mar 15, 2016 at 07:32:35PM +, Derek Buitenhuis wrote:
> On 3/15/2016 7:26 PM, Reimar Döffinger wrote:
> > I see this:
> > libavformat/tls_schannel.c:#include
> > libavformat/tls_securetransport.c:#include
> >
> > Are those different headers?
>
&g
On Sat, Mar 19, 2016 at 12:42:09PM +0100, Clément Bœsch wrote:
> On Fri, Mar 18, 2016 at 10:12:14PM -0700, Ganesh Ajjanagadde wrote:
> > -static inline void abs_pow34_v(float *av_restrict out, const float
> > *av_restrict in, const int size)
> > -{
> > -int i;
> > -for (i = 0; i < size; i+
On Tue, Mar 22, 2016 at 08:58:24AM -0400, Aaron Boxer wrote:
> On Tue, Mar 22, 2016 at 8:48 AM, Ismail Donmez wrote:
>
> > On Tue, Mar 22, 2016 at 2:44 PM, Aaron Boxer wrote:
> > > Hi Carl,
> > >
> > >
> > > On Tue, Mar 22, 2016 at 8:32 AM, Carl Eugen Hoyos
> > wrote:
> > >
> > >> Aaron Boxer
On Tue, Mar 22, 2016 at 11:14:49AM -0700, Ganesh Ajjanagadde wrote:
> > Are you sure that this speedup (and the other patch you posted) is real and
> > above the error? Did you do multiple runs to rule out that it was chance?
> > 0.04/0.05 second improvement on 5 seconds doesn't seem significant at
On Tue, Mar 22, 2016 at 11:43:50PM -0700, Chris Cunningham wrote:
> Hey Group,
>
> I'm seeing an interesting pattern [0][1] where we allocate 1 byte in places
> where I would expect no allocation to be necessary. Why is this being done?
Well, what else would you do?
None of the alternatives reall
On Wed, Mar 23, 2016 at 03:31:38PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 22, 2016 at 11:43:50PM -0700, Chris Cunningham wrote:
> > Hey Group,
> >
> > I'm seeing an interesting pattern [0][1] where we allocate 1 byte in places
> > where I would expect no allocation to be necessary. Why is
On Wed, Mar 23, 2016 at 03:24:47PM -0400, Aaron Boxer wrote:
> Hello Again,
>
> I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG for
> many years, and I would say at least 20% of the code in FFmpeg was either
> directly copied from OpenJPEG, or is very similar to OpenJPEG code.
On Wed, Mar 23, 2016 at 06:35:20PM -0400, Aaron Boxer wrote:
> On Wed, Mar 23, 2016 at 3:59 PM, Michael Bradshaw wrote:
>
> > On Wed, Mar 23, 2016 at 12:24 PM, Aaron Boxer wrote:
> > > Hello Again,
> > >
> > > I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG for
> > > many ye
On Wed, Mar 23, 2016 at 10:50:06PM -0400, Aaron Boxer wrote:
> On Wed, Mar 23, 2016 at 9:48 PM, Ricardo Constantino
> wrote:
>
> > On 23 March 2016 at 22:35, Aaron Boxer wrote:
> > > Back to my original point, what is the reasoning not to just switch to
> > > OpenJPEG?
> > Both OpenJPEG 1 and 2
On Thu, Mar 24, 2016 at 03:56:19AM -0400, Larry D. Fishel wrote:
> I think all I really need is to know how to get compiler/linker errors when
> building ffmpeg on a Linux platform rather than the beutified output that
> the makefiles seem to work so hard to present.
There is no special mangling o
This should demonstrate how well or badly the
minimal inflate fits into code designed around zlib.
I am not clear on whether the pngdec implementation
was done explicitly to save memory, some other reason,
or possibly for no good reason at all.
Signed-off-by: Reimar Döffinger
---
configure
GET_VLC and similar macros.
Signed-off-by: Reimar Döffinger
---
libavcodec/inflate.c | 279 +++
libavcodec/inflate.h | 54 ++
2 files changed, 333 insertions(+)
create mode 100644 libavcodec/inflate.c
create mode 100644 libavcodec
On Thu, Mar 24, 2016 at 08:35:19PM +0530, Suresh Kumar wrote:
> Hello,
>
> Currently i am integrating a third party video decoder to FFMPEG.
> I have an issue with my decoder. As it is giving multiple output frames for
> single packet/frame.
>
> I have tried the possible scenarios
> 1. If i retur
On Thu, Mar 24, 2016 at 05:14:49PM +0100, Hendrik Leppkes wrote:
> On Thu, Mar 24, 2016 at 4:33 PM, Reimar Döffinger
> wrote:
> > This should demonstrate how well or badly the
> > minimal inflate fits into code designed around zlib.
> > I am not clear on whether the pngde
On Fri, Mar 25, 2016 at 10:05:09AM +0100, Paul B Mahol wrote:
> On 3/25/16, Ganesh Ajjanagadde wrote:
> > { require libfdk_aac fdk-aac/aacenc_lib.h
> > aacEncOpen -lfdk-aac &&
> > warn "using libfdk without pkg-config"; }
> > }
> >
On Fri, Mar 25, 2016 at 07:50:22AM -0700, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 2:32 AM, Reimar Döffinger
> wrote:
> >> Big NO from me. Please refrain from doing such silly things.
> >> Either improve our implementation or do nothing.
> >
>
On Fri, Mar 25, 2016 at 09:11:10AM -0700, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 7:53 AM, Michael Niedermayer
> wrote:
> > On Thu, Mar 24, 2016 at 05:50:52PM -0700, Ganesh Ajjanagadde wrote:
> >> 1. The most important change is the addition of a permute call to ensure
> >> that the co
On Fri, Mar 25, 2016 at 09:29:56AM -0700, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 8:23 AM, Hendrik Leppkes wrote:
> > If performance is the only reason one might want an external library,
> > then its a much better idea to try to optimize the code we have, that
> > way more people auto
On Thu, Mar 24, 2016 at 01:40:07AM +0100, Carl Eugen Hoyos wrote:
> @@ -432,6 +432,8 @@ static int flic_decode_frame_8BPP(AVCodecContext *avctx,
> y_ptr += s->frame->linesize[0]) {
> bytestream2_get_buffer(&g2, &pixels[y_ptr],
>
On 26.03.2016, at 13:10, yukari yakumo wrote:
> Hi everyone!
> I'm Gentoo Linux user and currently I play with Clang as default compiler.
> And currently I tried to build ffmpeg 2.8.6 with Clang 3.9.0 and
> `-march=native` in C(XX)FLAGS (ffmpeg-2.8.6.ebuild automatically convert this
> to `--cpu
I don't have the binary decoder, and this is as far as I got
with pure guessing and only 2 samples.
Intra frames seem to work, and full-block inter updates work
as well. Partial/special coded blocks I could not figure out.
Samples:
http://samples.mplayerhq.hu/game-formats/la-san/jediknight-sith/
--
Fixes playback of
http://samples.mplayerhq.hu/game-formats/la-san/rebelassault2/01P01.SAN
Signed-off-by: Reimar Döffinger
---
libavcodec/sanm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index 2eb7e44..ce3c868 100644
--- a/libavcodec/sanm.c
Mostly (there are some artefacts) fixes samples in
http://samples.mplayerhq.hu/game-formats/la-san/fullthrottle-demo/
Signed-off-by: Reimar Döffinger
---
libavcodec/sanm.c | 42 +++---
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/libavcodec
Used for cockpit in
http://samples.mplayerhq.hu/game-formats/la-san/rebelassault/L8PLAY.ANM
Signed-off-by: Reimar Döffinger
---
libavcodec/sanm.c | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/libavcodec/sanm.c b/libavcodec
On 02.04.2016, at 16:27, Michael Niedermayer wrote:
> On Sat, Apr 02, 2016 at 02:29:46PM +0200, Reimar Döffinger wrote:
>> Used for cockpit in
>> http://samples.mplayerhq.hu/game-formats/la-san/rebelassault/L8PLAY.ANM
>
> iam probably missing some patch but this doesnt p
Hello,
I was looking at these:
http://samples.mplayerhq.hu/game-formats/la-snm/grimfandango/
http://samples.mplayerhq.hu/game-formats/la-snm/force-commander-znm/
and realized that they are perfectly supported, if you first
run them through gunzip.
However there are 2 issues here:
1) They are misdet
On Sat, Apr 02, 2016 at 07:25:46PM +0200, Nicolas George wrote:
> Le quartidi 14 germinal, an CCXXIV, Reimar Döffinger a écrit :
> > I was looking at these:
> > http://samples.mplayerhq.hu/game-formats/la-snm/grimfandango/
> > http://samples.mplayerhq.hu/game-formats/la-sn
On Sun, Apr 03, 2016 at 09:02:27AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Apr 2, 2016 at 12:29 PM, Reimar Döffinger
> wrote:
>
> > Hello,
> > I was looking at these:
> > http://samples.mplayerhq.hu/game-formats/la-snm/grimfandango/
> > http://s
On Sun, Apr 03, 2016 at 06:43:49PM +0200, wm4 wrote:
> On Sun, 3 Apr 2016 18:33:44 +0200
> Reimar Döffinger wrote:
> > > So probe and read_packet can optionally decompress and we're pretty much
> > > done. I don't see the issue, and this is at best a few lin
On Mon, Apr 04, 2016 at 10:51:23AM -0700, Timothy Gu wrote:
> On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:
> Also it should be made clear that if Grok is linked into FFmpeg, the resulting
> binary is a mixture of AGPL and GPL works. If --enable-gpl or
> --enable-version3 is not enab
On Mon, Apr 04, 2016 at 03:48:38PM -0400, Aaron Boxer wrote:
> On Mon, Apr 4, 2016 at 3:16 PM, Reimar Döffinger
> wrote:
>
> > The really huge, gigantic, elephant sized issue with AGPL for me is
> > that it is _completely_ unclear to me what you actually have to
> >
On Tue, Apr 05, 2016 at 09:54:45AM +, Carl Eugen Hoyos wrote:
> Aaron Boxer gmail.com> writes:
>
> > I still think the advantages (i.e. closing the application
> > server loophole)c outweigh this disadvantage.
>
> I believe the mistake you make here is the main reason for
> this whole frui
On 10.04.2016, at 20:00, Derek Buitenhuis wrote:
> On 4/10/2016 5:42 PM, Michael Niedermayer wrote:
>> this is not possible currently libfaac is twice as fast than the
>> native encoder.
>
> Twice as fast and produces crap output.
Someone like me almost certain doesn't notice that it's crap. I'
fer or not, it would be
of great help if you could make samples available (if you
can find any where you can get the ok to make available
publicly).
With such special formats regression testing is fairly
important, but cannot be done without public s
On Sun, Apr 17, 2016 at 01:18:42PM +0200, Andreas Weis wrote:
> Since av_log_format_line calls snprintf internally, that might be as
> trivial as just forwarding the return value from that call.
This probably wasn't done because snprintf isn't always
implemented 100% right in this regard (too smal
On Sun, Apr 17, 2016 at 05:54:00PM +, Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
> > What proves that the sample you have renders correctly now?
>
> Nothing.
>
> You think that it is more likely that the sample was
> intentionally made to fool the vlc developers than to
> help t
On Sun, Apr 17, 2016 at 06:38:12PM +, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
> > In particular, I have an uncomfortable suspicion that
> > PGS might be designed to match the movie's colour space,
> > in which case neither variant would give co
On Sun, Apr 17, 2016 at 09:41:32PM +0300, Jan Ekstrom wrote:
> On Sun, Apr 17, 2016 at 9:21 PM, Reimar Döffinger
> wrote:
> > In particular, I have an uncomfortable suspicion that
> > PGS might be designed to match the movie's colour space,
> > in which case neith
On Sun, Apr 17, 2016 at 09:49:58PM +0300, Jan Ekstrom wrote:
> On Sun, Apr 17, 2016 at 9:44 PM, wm4 wrote:
> >
> > Ah that's funny. This indeed ruins everything. It looks like subtitle
> > decoders should simply output YUV, and until we can fix it, a private
> > option could change between the col
On Sun, Apr 17, 2016 at 09:08:45PM +0200, Carl Eugen Hoyos wrote:
> -YUV_TO_RGB1(cb, cr);
> -YUV_TO_RGB2(r, g, b, y);
> +if (ctx->hdtv > 0) {
> +YUV_TO_RGB1_CCIR(cb, cr);
> +YUV_TO_RGB2_CCIR(r, g, b, y);
> +} else {
> +YUV_TO_RGB1(
On Sun, Apr 17, 2016 at 09:24:29PM +0200, Reimar Döffinger wrote:
> On Sun, Apr 17, 2016 at 09:08:45PM +0200, Carl Eugen Hoyos wrote:
> > -YUV_TO_RGB1(cb, cr);
> > -YUV_TO_RGB2(r, g, b, y);
> > +if (ctx->hdtv > 0) {
> > +
---
libavcodec/dvbsub.c | 4 ++--
libavfilter/drawutils.c | 8
libavfilter/vf_drawbox.c | 4 ++--
libavutil/colorspace.h | 8
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/dvbsub.c b/libavcodec/dvbsub.c
index 3cdbade..d2faef0 100644
--- a/lib
On 21.04.2016, at 06:02, Dave Yeo wrote:
> On 04/20/16 07:40 PM, Michael Niedermayer wrote:
>> On Thu, Apr 14, 2016 at 07:31:48PM -0700, Dave Yeo wrote:
>>> From a417fdf752bd7c704ed5ba0c94c5cea96e1a91ff Mon Sep 17 00:00:00 2001
>>> From: Dmitriy Kuminov
>>> Date: Thu, 14 Apr 2016 01:53:46 +0400
On 20.04.2016, at 23:59, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> ffplay.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/ffplay.c b/ffplay.c
> index 804bcbc..89a34d2 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -2578,12 +2578,17 @@ static int audio_open(void *
On 23.04.2016, at 13:21, wm4 wrote:
> On Sat, 23 Apr 2016 01:16:31 +0200
> Hendrik Leppkes wrote:
>
>> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
>> wrote:
>>> I've noticed that when CONFIG_W64_DEMUXER is defined to zero that ffmpeg
>>> compiles in a reference to ff_w64_guid_data but doesn'
On Sat, Apr 30, 2016 at 10:17:33PM +0200, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> ffplay.c | 7 +++
> 1 file changed, 7 insertions(+)
I have a nagging feeling someone with better knowledge
of ALSA and how we handle it might find a better solution,
but since I doubt someon
On 04.05.2016, at 17:01, "Felt, Patrick" wrote:
>
> On 5/4/16, 5:52 AM, "ffmpeg-devel on behalf of Clément Bœsch"
> wrote:
>
>>
>> [...]
>>> +/* libavfilter documentation says that filter init will be called only
>>> once. ffmpeg calls the init twice to enable it to validate
>>> + * the
On 07.05.2016, at 02:56, Hendrik Leppkes wrote:
> On Sat, May 7, 2016 at 2:02 AM, James Almer wrote:
>> On 5/6/2016 8:48 PM, Timothy Gu wrote:
>>> On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote:
Just to document it, this has caused build breakage in various
scena
On 11.05.2016, at 20:37, Michael Niedermayer wrote:
> On Wed, May 11, 2016 at 06:39:20PM +0200, Matthieu Bouron wrote:
>> From: Matthieu Bouron
>>
>> ---
>>
>> Hello,
>>
>> Here are some benchmark on a rpi2 of the attached patch.
>>
>> ./ffmpeg -f lavfi -i
>> sine=440,aformat=sample_fmts=
On 11.05.2016, at 14:03, Carl Eugen Hoyos wrote:
> 章军海 <243186085 qq.com> writes:
>
>> I wonder how you all test FATE on arm or arm64 hardware.
>
> To actually test fate on small devices like mobile phones,
> you have to use the configure option --target-exec and
> point it to ssh, you need
On 11.05.2016, at 17:00, Bruce Dawson
wrote:
> Microsoft is aware of the issue and is working on it. They might fix it.
> They might not, however, because regressions in non-standard behavior are
> not as serious. We will see.
>
> I'm committing a Chromium specific workaround because that allow
On 11.05.2016, at 21:09, James Almer wrote:
> On 5/11/2016 4:04 PM, Reimar Döffinger wrote:
>> otherwise there's a risk that enabling the recently discussed
>> -ftree-vecorize for that file specifically would give better results.
>
> Tree vectorize is enabled for x8
The old API did that just fine, and if we provide
a compatibility layer it should at least be compatible.
For the test-case (feeding AVParser output directly to
decoder, failing to discard 0-size packets) just discarding
0-size packets at the start works, but not sure if in some
cases we might want
On 03.07.2017, at 21:07, wm4 wrote:
> On Mon, 3 Jul 2017 20:57:21 +0200
> Reimar Döffinger wrote:
>
>> The old API did that just fine, and if we provide
>> a compatibility layer it should at least be compatible.
>> For the test-case (feeding AVParser output directl
On 03.07.2017, at 17:17, Derek Buitenhuis wrote:
> On 7/3/2017 2:18 AM, Michael Niedermayer wrote:
>> breaks fate
>
> I'll look into it tonight; busy today.
>
> .
> .
> .
>
> Aside:
>
> I'll just add, though, that these two word 'breaks fate' emails
> are kind of obnoxious when the test in qu
> +static int64_t find_size(AVIOContext * pb, FITSContext * fits)
> +{
> +int bitpix, naxis, dim_no, i, naxisn[999], groups=0;
> +int64_t header_size = 0, data_size=0, ret, pcount=0, gcount=1, d;
> +char buf[81], c;
This is more than 4kB of data on the stack.
Large stack arrays have a
On 04.07.2017, at 00:51, Nicolas George wrote:
> Hi. Nice to see you back.
>
> Le sextidi 16 messidor, an CCXXV, Reimar Döffinger a écrit :
>> This is more than 4kB of data on the stack.
>> Large stack arrays have a huge amount of security implications, please
>>
On 30.06.2017, at 20:06, Ricardo Constantino wrote:
> libvorbis comes with pkg-config files since at least v1.0.1, way back
> in 2003.
>
> The extra check is needed for shared builds, as the pkg-config file
> for vorbisenc doesn't include vorbis and ogg if --static isn't used.
If you still manu
On 28.06.2017, at 10:52, Timo Rothenpieler wrote:
> Am 27.06.2017 um 21:47 schrieb Michael Niedermayer:
>> 0.5% faster loop
>>
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavcodec/utvideodec.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/utv
On 04.07.2017, at 10:42, wm4 wrote:
> Not really comfortable with the current patch. Why does it even touch
> the compat_decode_partial_size handling path?
Because that is the code that gets utterly confused by 0-size packets and
breaks everything.
For ac3 what happens is that after the first 0-
On 04.07.2017, at 14:03, Ricardo Constantino wrote:
> On 4 July 2017 at 07:54, Reimar Döffinger wrote:
>> On 30.06.2017, at 20:06, Ricardo Constantino wrote:
>>
>>> libvorbis comes with pkg-config files since at least v1.0.1, way back
>>> in 2003.
>>>
I don't know what you are trying to achieve, but an encoder that just copies
things through makes no sense.
If it's just about validating or logging some kind of parser or
(bitstream-)filter probably makes more sense.
Even if doing it as encoder, why should it be a video encoder instead of
somet
On Sat, Jul 08, 2017 at 12:59:09PM +0200, Nicolas George wrote:
> Le sextidi 16 messidor, an CCXXV, Paras Chadha a écrit :
> > So, now should i do this ?
>
> Based on what you explained here, FITS seems like just an image format,
> without provisions for animations like GIF or PNG. Therefore, it s
On Tue, Jul 04, 2017 at 09:50:31PM +0530, Paras Chadha wrote:
> On Tue, Jul 4, 2017 at 4:12 AM, Reimar Döffinger
> wrote:
> > > +data_size *= naxisn[i];
> > > +if (data_size < 0)
> > > +return AVERROR_INVALIDDATA;
>
On 09.07.2017, at 02:52, "Ronald S. Bultje" wrote:
> On Sat, Jul 8, 2017 at 5:17 PM, Michael Niedermayer
> wrote:
>
>>
>> Does anyone object to this patch ?
>> Or does anyone have a better idea on how to fix this ?
>> if not id like to apply it
>
>
> I think Rostislav's point is: why fix it,
On 09.07.2017, at 13:09, Michael Niedermayer wrote:
> Hi all
>
> It does appear this regression affects alot of people, judging from
> the multiple different people in the ticket.
> Also people ask me about this, for example baptiste yesterday hit it
> too.
>
> I belive multiple people where in
On 09.07.2017, at 16:08, "Ronald S. Bultje" wrote:
> Hi,
>
> On Sun, Jul 9, 2017 at 4:39 AM, Reimar Döffinger
> wrote:
>
>> On 09.07.2017, at 02:52, "Ronald S. Bultje" wrote:
>>> On Sat, Jul 8, 2017 at 5:17 PM, Michael Niedermayer
>>
On 09.07.2017, at 22:37, Hendrik Leppkes wrote:
>
> Either extremely badly intereleaved streams or streams that just start
> super late in the file have always been very problematic for decoding,
> resulting in various hacks over the years to add "best-guess" default
> values so at least somethi
On 13.07.2017, at 14:10, "Geek.Song" wrote:
> On Wed, Jul 12, 2017 at 1:50 PM, Steven Liu wrote:
>> 2017-07-12 12:32 GMT+08:00 Geek.Song :
>>> In ffmpeg.c:
>>> //
>>> // @ static int process_input_packet(InputStream *ist, const AVPacket
>>> *pkt, int no_eof)
>>> //
>>> if (ret < 0) {
>>>
On 13.07.2017, at 16:49, Derek Buitenhuis wrote:
> On 7/13/2017 3:11 PM, wm4 wrote:
>> We definitely use some C99 constructs in FFmpeg, but normally we don't
>> use stdbool.h.
>
> Yeah, but we disallow others (like VLAs), so, yeah.
I think it's more of a case of "there is no really convincing u
On 14.07.2017, at 16:30, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
Probably not making myself popular with that request, but maybe you
could do a pass over the code and add comments for things that might
be useful for people to know?
If you need concrete examples I am thinking of qsort
On 14.07.2017, at 19:04, Paras Chadha wrote:
> +static int write_keyword_value(char * header, const char * keyword, int
> value)
> +{
> +int i, len, ret;
> +len = strlen(keyword);
> +for (i = 0; i < len; i++) {
> +header[i] = keyword[i];
> +}
would suggest memcpy (especi
On 16.07.2017, at 14:31, Paras Chadha wrote:
> +static int write_keyword_value(uint8_t **bytestream, const char * keyword,
> int value)
> +{
> +int len, ret;
> +uint8_t * header = * bytestream;
> +len = strlen(keyword);
> +
> +memcpy(header, keyword, len);
> +memset(header + l
On 16.07.2017, at 15:08, Nicolas George wrote:
> L'octidi 28 messidor, an CCXXV, Derek Buitenhuis a écrit :
>> Why is there no decoder?
>
> Because the decoder is in a separate patch, and the demuxer in yet
> another. And none of them can proceed until Paras Chadha starts deciding
> what is cons
On 18.07.2017, at 00:59, James Almer wrote:
> On 7/17/2017 7:49 PM, Moritz Barsnick wrote:
>> On Mon, Jul 10, 2017 at 13:53:02 +0300, Boris Pek wrote:
>>> Latest news about this topic:
>>> https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/FKXe-76GO8Y
>>
>> Ah, thanks, I neglected to
On 19.07.2017, at 12:03, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a écrit :
>
>> I think the image2 demuxer shouldn't handle this type of junk/useless data
>> filtering and would rather see a separate demuxer like the current patch
>> which deals with crap.
>
On 19.07.2017, at 12:03, Nicolas George wrote:
> What I do insist on, is this:
>
> Look at the find_size() function in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213076.html
>
> Then look at the fits_read_header() in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/
On 19.07.2017, at 18:48, Marton Balint wrote:
>
> On Wed, 19 Jul 2017, John Warburton wrote:
>
>> On Tue, Jul 18, 2017 at 6:10 PM, Marton Balint wrote:
>>> On Sat, 8 Jul 2017, Marton Balint wrote:
>>>
This also add supports for 4K DeckLink cards because they always output the
ancill
On 21.07.2017, at 16:26, Paras Chadha wrote:
> On Fri, Jul 21, 2017 at 3:27 AM, Carl Eugen Hoyos
> wrote:
>
>> 2017-07-20 21:46 GMT+02:00 Paras Chadha :
>>
>>> +case AV_PIX_FMT_RGB24:
>>> +case AV_PIX_FMT_RGBA:
>>> +for (k = 0; k < naxis3; k++) {
>>> +
201 - 300 of 794 matches
Mail list logo
