On Sun, Nov 16, 2014 at 09:54:14PM +0100, Michael Niedermayer wrote:
> On Sat, Nov 15, 2014 at 07:02:44PM +0100, Reimar Döffinger wrote:
> > As far as I can tell the value can never go outside
> > the int16_t type.
> > And especially the cost of the initialization is
>
On 20.11.2014, at 09:48, Jesse Jiang wrote:
> Hi Reimar,
> Because of Windows RT cannot use CryptographicBuffer or _beginthreadex API,
> so I try to use rand() instead of it, or we need to write own function
> instead of it. If we use WinRT api to instead of these apis, it will cause
> more bug
On 21.11.2014, at 07:44, Jesse Jiang wrote:
> Now, I find a function get_generic_seed()
> So, I use this function will work fine?
It is already used as fallback so I don't see why you'd have to change the code
at all.
> uint32_t av_get_random_seed(void){uint32_t seed;
> #if HAVE_CRYPTGENRAN
On 20 November 2014 08:34:54 CET, Jesse Jiang
wrote:
>Add WinRT API supports
At least 2 fairly major issues:
1) using rand() basically never is correct. Use the appropriate
CryptographicBuffer function (yes, that means you need some C++ code
unfortunately).
2) CreateTh
On Mon, Nov 17, 2014 at 09:52:31AM +0100, bzk0...@aol.com wrote:
> The problem with 4:2:0 (which we are currently using
> for most content) is that it is still too heavy on the
> CPU load to make streaming of many videos in parallel
> completely smooth, which is our primary requirement.
>
> Simply
On 17.11.2014, at 02:37, Michael Niedermayer wrote:
> On Sat, Nov 15, 2014 at 06:16:03PM +0100, Reimar Döffinger wrote:
>> 11674 -> 10877 decicycles on my Phenom II.
>> Overall speedup was unfortunately within measurement error.
>
> here its 10153 ->10135
I suspect i
As far as I can tell the value can never go outside
the int16_t type.
And especially the cost of the initialization is
reduced quite a bit by making it smaller.
Overall decoding speedup not measurable though.
Signed-off-by: Reimar Döffinger
---
libavcodec/h264_mb.c | 4 ++--
1 file changed, 2
11674 -> 10877 decicycles on my Phenom II.
Overall speedup was unfortunately within measurement error.
Signed-off-by: Reimar Döffinger
---
libavcodec/x86/h264_i386.h | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/libavcodec/x86/h264_i386.
On Fri, Nov 14, 2014 at 08:59:45PM +0100, Reimar Döffinger wrote:
> On Fri, Nov 14, 2014 at 08:43:25PM +0100, Reimar Döffinger wrote:
> > On Fri, Nov 14, 2014 at 08:37:47PM +0100, Reimar Döffinger wrote:
> > > On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote:
&
On Fri, Nov 14, 2014 at 08:43:25PM +0100, Reimar Döffinger wrote:
> On Fri, Nov 14, 2014 at 08:37:47PM +0100, Reimar Döffinger wrote:
> > On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote:
> > > Dear ffmpeg developers,
> > >
> > > is there any
On Fri, Nov 14, 2014 at 08:38:39PM +0100, Michael Niedermayer wrote:
> On Fri, Nov 14, 2014 at 07:59:17PM +0100, Reimar Döffinger wrote:
> > On Fri, Nov 14, 2014 at 02:39:46PM +0100, Michael Niedermayer wrote:
> > > Signed-off-by: Michael Niedermayer
> > > ---
> &
On Fri, Nov 14, 2014 at 08:37:47PM +0100, Reimar Döffinger wrote:
> On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote:
> > Dear ffmpeg developers,
> >
> > is there any (planned) support for the Hap video codec in ffmpeg?
> >
> > https://g
On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote:
> Dear ffmpeg developers,
>
> is there any (planned) support for the Hap video codec in ffmpeg?
>
> https://github.com/vidvox/hap
>
> The implementation for Windows and Mac is available freely under a
> permissive license.
Where i
On Fri, Nov 14, 2014 at 02:39:46PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/nellymoserdec.c |9 ++---
> libavcodec/nellymoserenc.c | 17 +++--
> 2 files changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/ne
On 03.11.2014, at 17:36, "Ronald S. Bultje" wrote:
> Hi,
>
> On Mon, Nov 3, 2014 at 7:02 AM, Nicolas George wrote:
>
>> Le duodi 12 brumaire, an CCXXIII, Reimar Döffinger a écrit :
>>> Configures it as x86_64 with assembler disabled.
>>
>>
On Sun, Nov 02, 2014 at 10:02:50AM +, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
>
> > Are there still objections?
>
> I just wanted to know if we shouldn't always set ASP?
> Or at least for everything != SP?
I am unsure. It seemed to me this w
On Sun, Nov 02, 2014 at 10:44:43AM +0100, Reimar Döffinger wrote:
> Configures it as x86_64 with assembler disabled.
> Does not pass "make fate" though, e.g. fate-vc1_ilaced_twomv fails.
Sorry, it actually does pass.
I forgot to rsync the samples first.
Note that if you leave asm
Configures it as x86_64 with assembler disabled.
Does not pass "make fate" though, e.g. fate-vc1_ilaced_twomv fails.
Signed-off-by: Reimar Döffinger
---
configure | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure b/configure
index e79b34d..c9008ba 100755
--- a/confi
On 01.11.2014, at 13:45, Reimar Döffinger wrote:
> This is a regression, previous code did not require
> users to set the profile to use VDPAU.
> In addition, ASP is a superset of SP, so there is not
> even a good reason to require it.
Are there still objections?
As said, to my kno
On Sat, Nov 01, 2014 at 01:15:46PM +, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
>
> > -.priv_data_size = sizeof(MpegEncContext),
> > +.priv_data_size = sizeof(Mpeg4DecContext),
>
> Please commit.
Pushed.
_
On Sat, Nov 01, 2014 at 01:52:17PM +0100, wm4 wrote:
> On Sat, 1 Nov 2014 13:45:46 +0100
> Reimar Döffinger wrote:
>
> > This is a regression, previous code did not require
> > users to set the profile to use VDPAU.
>
> It still doesn't...?
It does if you wa
On Sat, Nov 01, 2014 at 02:18:06PM +0100, Jean-Baptiste Kempf wrote:
> On 01 Nov, Reimar Döffinger wrote :
> > This is a regression, previous code did not require
> > users to set the profile to use VDPAU.
>
> If you don't set the profile, how can you know that
This is a regression, previous code did not require
users to set the profile to use VDPAU.
In addition, ASP is a superset of SP, so there is not
even a good reason to require it.
---
libavcodec/vdpau_mpeg4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/vdpau_mpeg4.c b/libavcodec/
---
libavcodec/mpeg4videodec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 47ac523..846b691 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -2795,7 +2795,7 @@ AVCodec ff_mpeg4_vdpau_de
On Wed, Oct 29, 2014 at 12:17:34PM +0100, Christophe Gisquet wrote:
> Hi,
>
> 2014-10-25 13:29 GMT+02:00 Reimar Döffinger :
> > Maybe as a patch that puts it into tools?
> > I don't know if that's the right place, but I would kind of prefer to
> > have thes
On Mon, Oct 27, 2014 at 05:16:53PM +0100, Michael Niedermayer wrote:
> On Mon, Oct 27, 2014 at 09:23:59PM +0530, greeshma wrote:
> > Hi,
> >
> > thanks,
> > I am trying to convert .raw/.pcm file to .mlp file using mlp encoder.I want
> > the command line options to be used for the conversion.
>
>
On 26.10.2014, at 02:32, James Almer wrote:
> __sync built-ins are considered legacy and will be deprecated.
> These new memory model aware built-ins have been available since GCC 4.7.0
To me this sounds like "except for tsan, these new functions are worse in every
aspect, and that's with gcc 4.
On Sat, Oct 25, 2014 at 05:35:37PM +0200, Christophe Gisquet wrote:
> 2014-10-25 13:35 GMT+02:00 Reimar Döffinger :
> > Could you maybe add e.g. a FATE test that clearly shows the before-after
> > improvements?
>
> I've tried for a small while, by swapping fields on lena
On Sat, Oct 25, 2014 at 03:08:10PM +0200, wm4 wrote:
> On Sat, 25 Oct 2014 14:43:39 +0200
> Nicolas George wrote:
> > That would not be heavy-weight, that would be outright irresponsible:
> > ioctl() opcodes are not globally unique. An opcode that maps to a harmless
> > probe on v4l devices can tr
On Sat, Oct 25, 2014 at 12:35:11PM +, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
>
> > It should be possible to override the other way via
> > file:///dev/video/... I believe?
>
> Of course.
>
> Could the original patch please be applied?
On Sat, Oct 25, 2014 at 02:15:47PM +0200, wm4 wrote:
> > I admittedly just assumed that v4l2:///dev/video/... would work
> > currently. If not, that sounds like something that can and should
> > be fixed.
> > However as a convenience feature, I think it is good that /dev/video
> > just ends up pick
On Sat, Oct 25, 2014 at 01:40:11PM +0200, wm4 wrote:
> On Sat, 25 Oct 2014 13:14:26 +0200
> Reimar Döffinger wrote:
> > wm4, if you have a simple way of doing this check, please explain it.
> > Otherwise I think EXTENSION score is good enough to signal "well, we
>
On Sat, Oct 25, 2014 at 11:19:23AM +, Christophe Gisquet wrote:
> The coefficients must be in the appropriate zigzag scan order.
> Also fix their values at the same time, as they were pretty wrong.
>
> Fixes ticket #2970.
Could you maybe add e.g. a FATE test that clearly shows the before-afte
On Sat, Oct 25, 2014 at 11:19:21AM +, Christophe Gisquet wrote:
> ---
> libavcodec/dv.c | 4 ++--
> libavcodec/dvdata.c | 12 ++--
> libavcodec/dvdata.h | 12 ++--
> 3 files changed, 14 insertions(+), 14 deletions(-)
Looks good to me.
I think in all places the uint16_t wi
On Sat, Oct 25, 2014 at 01:21:47PM +0200, Christophe Gisquet wrote:
> 2014-10-25 13:19 GMT+02:00 Christophe Gisquet :
> > Patch #3 uses mathematically more correct values, which happens to match
> > another dv implementation (cedocida). It does not seem to affect that
> > much the decoded output, a
On Sat, Oct 25, 2014 at 01:10:20PM +0200, wm4 wrote:
> On Sat, 25 Oct 2014 11:43:12 +0200
> Nicolas George wrote:
>
> > Le tridi 3 brumaire, an CCXXIII, Timothy Gu a écrit :
> > > Those URLs are very explicit, while `/dev/` can mean anything,
> > > including `/dev/stdin`.
> >
> > Andrey quoted t
On 21.10.2014, at 12:15, Stefano Sabatini wrote:
> On date Monday 2014-10-20 23:57:01 +0200, Lukasz Marek encoded:
>> Signed-off-by: Lukasz Marek
>> ---
>> ffserver.c|6 +
>> ffserver_config.c | 1138
>> ++---
>> ffserver_config.h |7
On 20.10.2014, at 10:40, Matt Oliver wrote:
> FYI VDA and VDPAU etc. wont compile with mingw as the system headers
> (vdpau.h etc) are missing by default. Which is why these headers error on
> Windows as they include other headers that just are not available on that
> platform.
vdpau.h is not a s
On 19.10.2014, at 20:53, Matt Oliver wrote:
> This stops headers based on disabled functionality from being installed.
> Things like VDA and VDPAU dont work on windows etc. So any attempt to use
> these headers will result in compilation errors so best not to install them
> to avoid confusion. Als
On 19.10.2014, at 13:39, Lukasz Marek wrote:
> Signed-off-by: Lukasz Marek
> ---
> libavdevice/libavdevice.v | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavdevice/libavdevice.v b/libavdevice/libavdevice.v
> index 663af85..d7c86ba 100644
> --- a/libavdevice/libavdev
Signed-off-by: Reimar Döffinger
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 9306cc6..f916d01 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2442,7 +2442,7 @@ static int
On Tue, Oct 14, 2014 at 04:30:39PM -0400, Michael Lynch wrote:
> This patch fixes a crash in ff_rtsp_read_reply that can occur when the
> Content Length field of the RTSP reply message is very high (e.g. near
> INT_MAX) and causes av_malloc to return NULL.
>
> Thanks,
> Michael
>
> commit 1e085fa
On 13.10.2014, at 09:04, "rongyan" wrote:
> Hi,
> We present this patch to fix the bug in 'configure' file to make sure that
> the HAVE_VSX is only enabled when HAVE_ALTIVEC is enabled on POWER LE, and
> disabled when HAVE_ALTIVEC is disabled.
Sorry if my question makes no sense (I am fairly cl
On 13.10.2014, at 09:22, Thilo Borgmann wrote:
> Am 13.10.14 03:49, schrieb Michael Niedermayer:
>> Hi all
>>
>> does any mentor want to be added to the opw@ffmpeg alias if so, tell me
>> and ill add you
>
> add me please - thanks!
Me too, I got a few questions though I have not yet answered al
On 11.10.2014, at 16:19, Nicolas George wrote:
>> +if (str_size > sizeof(str)-1) { // free buffer for long data field
>> +av_freep(&pstr);
>
> I think "if (pstr != str)" would be more robust.
Uh, wouldn't that be undefined behaviour?
You're not allowed to compare pointers fro
On 7 October 2014 08:41:09 CEST, Peter Ross wrote:
>> > +for (k = 0; k < 256; k++) {
>> > +int v = 0;
>> > +for (l = 0; l < total; l++)
>> > +v += (((k >> l) & 1) * 2 - 1) *
>fsets->coeff[i][j * 8 + l];
>>
>> Is this faster in a rele
On 8 October 2014 04:39:20 CEST, rongyan wrote:
>Reimar,
>Sorry for late response.
>'HAVE_VSX' is automatically enabled only when HAVE_ALTIVECT is enabled
>and the CPU is little endian. So if the altivec implementation is
>broken in little endian, the HAVE_VSX will not be enabled.
That will make
On 02.10.2014, at 03:38, Michael Niedermayer wrote:
> On Tue, Sep 30, 2014 at 07:51:38PM +0200, Reimar Döffinger wrote:
>> On Tue, Sep 30, 2014 at 03:51:55PM +0800, rongyan wrote:
>>> Hi,
>>> I present 4 patches to fix bugs for POWER8 little endian.
>>> I will
On 30.09.2014, at 22:25, wm4 wrote:
> On Tue, 30 Sep 2014 08:06:16 +0200
> Reimar Döffinger wrote:
>
>> On 29.09.2014, at 22:02, Michael Niedermayer wrote:
>>> On Mon, Sep 29, 2014 at 08:34:44PM +0200, wm4 wrote:
>>>> On Mon, 29 Sep 2014 20:25:47 +
On Tue, Sep 30, 2014 at 07:41:08PM +0200, Michael Niedermayer wrote:
> + * @param list ',' seperated list of entities to register, the list used must
> + * have a sufficient lifetime so future calls to
> avcodec_register_list()
> + * can access it for comparission.
I think you can avo
On Tue, Sep 30, 2014 at 05:21:20PM +0200, Michael Niedermayer wrote:
> > with no
> > global mutable state.
>
> i disagree, applications that care about security must
> restrict used entities globally, thus by definition want to change
> global state. maybe not the way its done in this patch yes, i
On Tue, Sep 30, 2014 at 11:42:20PM +1000, Peter Ross wrote:
> +/**
> + * Calculate FS44 ratio
> + */
> +#define DSD_FS44(sample_rate) (sample_rate / 44100)
> +
> +/**
> + * Calculate DST frame size
> + * @return samples per frame (1-bit samples)
> + */
> +#define DST_SAMPLES_PER_FRAME(sample_rate)
Hello,
I didn't see any real issues either.
On Tue, Sep 30, 2014 at 11:01:17AM +0300, phint...@gmail.com wrote:
> +static int sup_write_packet(AVFormatContext *s, AVPacket *pkt)
> +{
> +uint8_t *data = pkt->data;
const uint8_t *
would be a bit nicer though, to make sure nobody gets any bad id
On Tue, Sep 30, 2014 at 03:51:55PM +0800, rongyan wrote:
> Hi,
> I present 4 patches to fix bugs for POWER8 little endian.
> I will send 4 patches in 4 different email. This is the first.
> The fate test result after merge these 4 patches can be found on
> http://fate.ffmpeg.org/ by search "ibmc
On 29.09.2014, at 22:02, Michael Niedermayer wrote:
> On Mon, Sep 29, 2014 at 08:34:44PM +0200, wm4 wrote:
>> On Mon, 29 Sep 2014 20:25:47 +0200
>> Michael Niedermayer wrote:
>>
>>> On Mon, Sep 29, 2014 at 07:41:28PM +0200, wm4 wrote:
Useful for Bluray and DVD, since the libraries used to r
On Sun, Sep 28, 2014 at 03:50:20PM +0200, wm4 wrote:
> > > The only "hack" about this is that libavformat doesn't provide a proper
> > > flush function. It could be easily added.
> >
> > Do you volunteer? :-)
>
> Sure. I was already wondering how to implement it. One issue is with
> which formats
On Sun, Sep 28, 2014 at 01:52:45PM +0200, wm4 wrote:
> On Sun, 28 Sep 2014 13:37:59 +0200
> Reimar Döffinger wrote:
> > > That's not how the libavformat seeking API works. If you want a
> > > different layer, use something from the different layer. E.g. seek avio
On Sun, Sep 28, 2014 at 10:15:51AM +0200, wm4 wrote:
> On Sun, 21 Sep 2014 10:17:16 +0100
> Reimar Döffinger wrote:
> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > index 3434341..c04e156 100644
> > --- a/libavformat/mpegts.c
> > +++ b/libavformat/mp
On 28.09.2014, at 11:05, wm4 wrote:
> On Sun, 28 Sep 2014 10:40:18 +0200
> Reimar Döffinger wrote:
>
>> On Sun, Sep 28, 2014 at 10:15:51AM +0200, wm4 wrote:
>>> On Sun, 21 Sep 2014 10:17:16 +0100
>>> Reimar Döffinger wrote:
>>>> @@ -2680,6
On 28.09.2014, at 11:12, Matt Oliver wrote:
> On 28 September 2014 18:49, Reimar Döffinger
> wrote:
>
>> On Sun, Sep 21, 2014 at 10:17:15AM +0100, Reimar Döffinger wrote:
>>> Allows 32 bit version of FFmpeg to use up to 4 GB of RAM
>>> instead of just 2 GB on
On Sun, Sep 21, 2014 at 10:17:15AM +0100, Reimar Döffinger wrote:
> Allows 32 bit version of FFmpeg to use up to 4 GB of RAM
> instead of just 2 GB on Windows if the OS can provide it.
Any other comments?
Note the documentation for that option:
> The /LARGEADDRESSAWARE option tells t
On Sun, Sep 28, 2014 at 10:15:51AM +0200, wm4 wrote:
> On Sun, 21 Sep 2014 10:17:16 +0100
> Reimar Döffinger wrote:
> > @@ -2680,6 +2687,7 @@ AVInputFormat ff_mpegtsraw_demuxer = {
> > .read_packet= mpegts_raw_read_packet,
> > .read_close
On Sun, Sep 28, 2014 at 08:06:40AM +, Carl Eugen Hoyos wrote:
> > > biSize must be calculated so that it points to the
> > > palette, so if you have both extradata and palette
> > > you absolutely need to add the extradata size:
>
> This is wrong afaict.
>
> Or do we misunderstand each othe
On Sun, Sep 28, 2014 at 03:50:11AM +0200, Michael Niedermayer wrote:
> On Sun, Sep 21, 2014 at 10:17:16AM +0100, Reimar Döffinger wrote:
> > Should should fix seeking in some blurays in combination with
> > e.g. MPlayer.
> > Not yet tested due to no bluray at hand.
> >
On Sun, Sep 28, 2014 at 09:50:43AM +0200, Reimar Döffinger wrote:
> On Sat, Sep 27, 2014 at 10:51:25AM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch is one of two patches necessary to fix ticket #1304.
> > The MSDN documentation indicates that the
On Sat, Sep 27, 2014 at 10:51:25AM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch is one of two patches necessary to fix ticket #1304.
> The MSDN documentation indicates that the palette is not part of the
> bitmapinfoheader but the bitmapinfoheader is part of the bitmapinfo
> structure
On Thu, Sep 25, 2014 at 08:08:20PM +0200, Michael Niedermayer wrote:
> On Thu, Sep 25, 2014 at 07:43:53PM +0200, Reimar Döffinger wrote:
> > I am willing to mentor anyone who doesn't mind that I won't be on IRC.
> > I don't mind being available via an kind of IM that
On Thu, Sep 25, 2014 at 01:39:36PM +0200, Thilo Borgmann wrote:
> Am 25.09.14 13:32, schrieb Michael Niedermayer:
> > On Thu, Sep 25, 2014 at 12:28:19PM +0200, Thilo Borgmann wrote:
> >> Hi,
> >>
> I volunteer as co-mentor becuase my time is very limited currently.
> However, I'm willing
On 23.09.2014, at 23:36, Christophe Gisquet
wrote:
> They have little to no benefit (none speedwise) and could be altogether
> dropped. I'm still submitting them to give them a chance before that.
I consider code cleanup to have more than just "little to no benefit".
But I don't know the code so
On 23.09.2014, at 02:27, Michael Niedermayer wrote:
> On Tue, Sep 23, 2014 at 01:01:26AM +0200, Reimar Döffinger wrote:
>> On Tue, Sep 23, 2014 at 12:42:53AM +0200, Michael Niedermayer wrote:
>>> Signed-off-by: Michael Niedermayer
>>>
>>
>> Mayb
On Mon, Sep 22, 2014 at 03:07:39PM -0700, Pascal Massimino wrote:
> Hi,
>
> as discussed on the other thread...
Why not just always allocate and 0-initialize pal->frame with width 256?
I haven't yet checked which if any is the easiest way to make
av_frame_get_buffer
do that while still having th
On Tue, Sep 23, 2014 at 12:42:53AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> configure | 33 ++---
> 1 file changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/configure b/configure
> index 12b2da5..f674a06 100755
> --- a
On 21 September 2014 10:46:33 GMT+01:00, wm4 wrote:
>On Sun, 21 Sep 2014 10:17:15 +0100
>Reimar Döffinger wrote:
>
>> Allows 32 bit version of FFmpeg to use up to 4 GB of RAM
>> instead of just 2 GB on Windows if the OS can provide it.
>>
>> Signed-off-by: Reima
Allows 32 bit version of FFmpeg to use up to 4 GB of RAM
instead of just 2 GB on Windows if the OS can provide it.
Signed-off-by: Reimar Döffinger
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 2c6db81..dec1cfc 100755
--- a/configure
+++ b
Signed-off-by: Reimar Döffinger
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index cabdbc2..2c6db81 100755
--- a/configure
+++ b/configure
@@ -4500,6 +4500,7 @@ EOF
fi
check_ldflags -Wl,--as-needed
+check_ldflags -Wl,-z,noexecstack
if check_func
Should should fix seeking in some blurays in combination with
e.g. MPlayer.
Not yet tested due to no bluray at hand.
Signed-off-by: Reimar Döffinger
---
libavformat/mpegts.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 3434341
On 19 September 2014 07:34:11 CEST, Pascal Massimino
wrote:
>Hi Reimar,
>while i don't necessarily disagree with the above generally speaking
>[*],
>let me repeat that
>this is a pragmatic choice. I'm not going to give up on the speed-up i
>have
>right now for
>some hypothetical decoder later.
I
On 18.09.2014, at 17:26, Michael Niedermayer wrote:
> On Thu, Sep 18, 2014 at 04:22:27PM +0200, Jörg Krause wrote:
>> glibc, uclibc, and musl uses feature test macros to expose definitions
>> conforming to the standards ISO C, POSIX and extensions. According to
>> which feature test macros are de
On 18 September 2014 10:55:00 CEST, Pascal Massimino
wrote:
>Hi Reimar,
>
>On Thu, Sep 18, 2014 at 9:33 AM, Reimar Döffinger
>
>wrote:
>
>> On 18.09.2014, at 08:45, Pascal Massimino
>
>> wrote:
>> > Hi,
>> >
>> > the webp loss
On 18.09.2014, at 08:45, Pascal Massimino wrote:
> Hi,
>
> the webp lossless doc was unclear regarding palette index falling out of
> range.
> See issue #206 [1] for the bug report.
> The solution retained was to treat out-of-range index as color 0x,
> so we could keep the speed-up in lib
On 16.09.2014, at 22:35, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch allows using libopenjpeg 2.x (tested with 2.1) here.
Doesn't it make sense to prefer the newest version, i.e. we should check for
this first and not last?
___
ffmpeg-devel maili
On Thu, Sep 11, 2014 at 04:48:00PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
Isn't that potentially a bit confusing?
EINVAL sounds to me like I would expect a programming error,
inputting something I should have known to be invalid.
That's not quite the case for out-o
On Sun, Sep 07, 2014 at 02:03:08PM +0200, Reimar Döffinger wrote:
> Also adds a lot of infrastructure necessary for it.
> Some of it is a bit ugly though.
> Increases binary size for hardcoded tables by about 12 kB,
> which is about 15 kB from qdm2_table minus data and code
> save
Also adds a lot of infrastructure necessary for it.
Some of it is a bit ugly though.
Increases binary size for hardcoded tables by about 12 kB,
which is about 15 kB from qdm2_table minus data and code
saved that was only used for creating it.
Signed-off-by: Reimar Döffinger
---
libavcodec/qdm2
Also adds a lot of infrastructure necessary for it.
Some of it is a bit ugly though.
Increases binary size for hardcoded tables by about 12 kB,
which is about 15 kB from qdm2_table minus data and code
saved that was only used for creating it.
Signed-off-by: Reimar Döffinger
---
libavcodec/qdm2
Patchset pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Sep 03, 2014 at 10:49:38PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 03, 2014 at 09:40:56PM +0200, Reimar Döffinger wrote:
> > Signed-off-by: Reimar Döffinger
> > ---
> > libavcodec/huffyuvdec.c | 19 +--
> > 1 file changed, 13
This avoids several issue like calculating sum/maxcoef
incorrectly due to adding up matrix entries that will
be overwritten, as well as out-of-range writes to
s->matrix if the maximum allowed number of channels is used.
Signed-off-by: Reimar Döffinger
---
libswresample/rematrix.c |
We only actually need to use a tiny part of it.
Unfortunately we seem to have no real test coverage on
the code, so this is a bit risky.
Signed-off-by: Reimar Döffinger
---
libswresample/rematrix.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libswresample
A branch to avoid some calculation seems unlikely to have any benefits.
Signed-off-by: Reimar Döffinger
---
libswresample/rematrix.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index 62662f8..5da3056 100644
--- a
On Wed, Sep 03, 2014 at 10:48:38PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 03, 2014 at 09:40:55PM +0200, Reimar Döffinger wrote:
> > We only actually need to use a tiny part of it.
> > Unfortunately we seem to have no real test coverage on
> > the code, s
On Sat, Sep 06, 2014 at 12:13:30PM +0200, Andreas Cadhalpun wrote:
> -Effectively this allows to add padding with zeros from the left.
> +Effectively this allows one to add padding with zeros from the left.
Huh? I don't think the second is more correct, and it sure sounds worse.
What is this tryin
On 06.09.2014, at 00:23, wm4 wrote:
> On Sat, 6 Sep 2014 00:00:10 +0200
> Michael Niedermayer wrote:
>
>> On Thu, Sep 04, 2014 at 10:40:27PM +0200, wm4 wrote:
>>> ---
>>> Follows reimar's suggestion for detecting UTF-16. If the detection goes
>>> wrong, probing the format won't succeed, so this
On Thu, Sep 04, 2014 at 11:27:49PM +0200, Jörg Krause wrote:
>
> On 09/04/2014 05:27 PM, Hendrik Leppkes wrote:
> >On Wed, Sep 3, 2014 at 11:53 AM, Jörg Krause wrote:
> >>Add the feature test macro which is required for building with the
> >>musl toolchain.
> >>
> >>The feature test macro _XOPEN_
On 05.09.2014, at 03:46, Reinhard Tartler wrote:
> On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer wrote:
>>> At the end of the day, I need a source tarball that contains
>>> maintained sources of a stand-alone libpostproc. I don't care too much
>>> how it is created, as long as it doesn't re
On Thu, Sep 04, 2014 at 10:19:05AM +0200, Hendrik Leppkes wrote:
> On Fri, Aug 29, 2014 at 12:31 PM, Petri Hintukainen
> wrote:
> > +static int sup_write_packet(AVFormatContext *s, AVPacket *pkt)
> > +{
> > +/* header */
> > +avio_wb16(s->pb, SUP_PGS_MAGIC);
> > +avio_wb32(s->pb, (uin
On 04.09.2014, at 05:33, Reinhard Tartler wrote:
> On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer wrote:
>> On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
>>> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer
>>> wrote:
On Tue, Sep 02, 2014 at 10:06:10PM +, Th
On 03.09.2014, at 22:09, Michael Niedermayer wrote:
> On Wed, Sep 03, 2014 at 08:46:04PM +0200, Reimar Döffinger wrote:
>> On 03.09.2014, at 18:49, Michael Niedermayer wrote:
>>> This allows using fs/ from the directory where ffmpeg
>>> was build
>
On Wed, Sep 03, 2014 at 07:36:32AM +0200, Reimar Döffinger wrote:
> On 03.09.2014, at 06:28, Michael Niedermayer wrote:
> > On Wed, Sep 03, 2014 at 12:01:54AM +0200, Reimar Döffinger wrote:
> >> We only actually use a tiny part of it.
> >>
> >
On Wed, Sep 03, 2014 at 07:34:37AM +0200, Reimar Döffinger wrote:
> On 03.09.2014, at 00:49, wm4 wrote:
> > On Wed, 3 Sep 2014 00:01:53 +0200
> > Reimar Döffinger wrote:
> >
> >> Signed-off-by: Reimar Döffinger
> >> ---
> >> libavcodec/huffyuvd
501 - 600 of 794 matches
Mail list logo
