On 31.07.2015, at 17:47, Nicolas George wrote:
> I can propose the following middle term:
I do have on more proposal, but the problem is it needs someone to do the work.
For each removed feature, prepare documentation "a monkey could follow" on how
to replace it (you could call it a transition g
On 05.08.2015, at 21:31, Andreas Cadhalpun
wrote:
>> Btw. the magic option to enable compatibility is still somewhat useful as it
>> lists
>> and allows testing the specific changes that are coming up. But I agree it's
>> only
>> a minor help.
>
> The problem with such a magic option is that i
On Tue, Feb 03, 2015 at 02:57:56PM +0100, wm4 wrote:
> On Tue, 3 Feb 2015 01:10:11 +0100
> Reimar Döffinger wrote:
>
> > On Mon, Feb 02, 2015 at 06:49:11PM -0500, Ben Boeckel wrote:
> > > FLAC doesn't really support IDv3 tags, so warn if they are found at all.
&
On Tue, Feb 03, 2015 at 07:04:11PM +0100, wm4 wrote:
> This could overflow and crash at least on 32 bit systems.
> ---
> libavformat/mpc8.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mpc8.c b/libavformat/mpc8.c
> index a15dc25..d6ca338 100644
> --- a/liba
On Tue, Feb 03, 2015 at 07:04:12PM +0100, wm4 wrote:
> This can lead to an endless loop by seeking back a few bytes after each
> attempted chunk read. Assuming negative sizes are always invalid, this
> is easy to fix. Other code in this demuxer treats negative sizes as
> invalid as well.
>
> Fixes
On Tue, Feb 03, 2015 at 09:54:51PM +0100, wm4 wrote:
> On Tue, 3 Feb 2015 21:47:57 +0100
> Reimar Döffinger wrote:
>
> > On Tue, Feb 03, 2015 at 07:04:12PM +0100, wm4 wrote:
> > > This can lead to an endless loop by seeking back a few bytes after each
> > &g
On 03.02.2015, at 22:06, wm4 wrote:
> On Tue, 3 Feb 2015 22:00:11 +0100
> Reimar Döffinger wrote:
>
>> On Tue, Feb 03, 2015 at 09:54:51PM +0100, wm4 wrote:
>>> On Tue, 3 Feb 2015 21:47:57 +0100
>>> Reimar Döffinger wrote:
>>>
>>>&g
On Thu, Feb 05, 2015 at 11:06:40PM -0800, Timothy Gu wrote:
> ---
> libavformat/img2dec.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 1ab1309..8c5e9d5 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img
On Fri, Feb 06, 2015 at 04:07:36PM +, Timothy Gu wrote:
> On Fri Feb 06 2015 at 1:28:09 AM Carl Eugen Hoyos wrote:
>
> > Timothy Gu gmail.com> writes:
> >
> > > if (!i || !*val)
> > > return 0;
> > > }
> > > -
> > > -return 0;
> > > }
> >
> >
>
> > I fear tha
On Fri, Feb 06, 2015 at 09:49:17PM +0100, wm4 wrote:
> On Fri, 6 Feb 2015 20:57:50 +0100
> Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavutil/pixfmt.h |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavutil/pix
On 08.02.2015, at 10:32, Clément Bœsch wrote:
>> --- a/tests/fate-run.sh
>> +++ b/tests/fate-run.sh
>> @@ -38,7 +38,7 @@ target_path(){
>> # $1=value1, $2=value2, $3=threshold
>> # prints 0 if absolute difference between value1 and value2 is <= threshold
>> compare(){
>> -echo "scale=2; v = $1
On 07.02.2015, at 15:51, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 -
> libavcodec/allcodecs.c | 1 -
> libavcodec/avcodec.h| 1 -
> libavcodec/codec_desc.c | 7 ---
> libavcodec/vima.c | 10 --
> 5 files changed, 20 deletions(-)
On 13.02.2015, at 17:58, "zhaoxiu.zeng" wrote:
> From 7d782e106cf485ca9a44d4283a18402bf0a84fb9 Mon Sep 17 00:00:00 2001
> From: Zeng Zhaoxiu
> Date: Sat, 14 Feb 2015 00:44:39 +0800
> Subject: [PATCH] avcodec/golomb: simplify sign conversion
This may be faster, but IMHO the term "simplify" is com
On 13.02.2015, at 17:51, "zhaoxiu.zeng" wrote:
> From b08b4a38c87000fe5549de96f65de6ba77740b30 Mon Sep 17 00:00:00 2001
> From: Zeng Zhaoxiu
> Date: Fri, 13 Feb 2015 23:52:29 +0800
> Subject: [PATCH 2/3] avcodec/wmalosslessdec: optimize sign operation
>
> Signed-off-by: Zeng Zhaoxiu
> ---
> lib
On 12.02.2015, at 19:56, Gautier Pelloux-Prayer wrote:
> Hi list,
>
> I added an option to disable compiler warnings while building ffmpeg. Reason
> is that when integrating ffmpeg within another project, I would like to
> disable these warnings since I cannot fix them myself and having them
>
On 25.02.2015, at 19:29, "Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, Feb 25, 2015 at 1:21 PM, James Almer wrote:
>
>> On 25/02/15 2:58 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Wed, Feb 25, 2015 at 12:52 PM, James Almer wrote:
>>>
On 25/02/15 2:36 PM, Ronald S. Bultje wrote:
>
MPlayer for example.
Signed-off-by: Reimar Döffinger
---
libavcodec/pthread_frame.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 5a4ab84..b0d3469 100644
--- a/libavcodec/pthread_frame.c
On 26.02.2015, at 23:46, Hendrik Leppkes wrote:
> On Thu, Feb 26, 2015 at 11:21 PM, Reimar Döffinger
> wrote:
>> When ff_thread_get_format is called from the main thread, e.g.
>> during codec init it will access the thread_ctx as a PerThreadContext
>> even though it
On Thu, Feb 26, 2015 at 07:56:06PM +0100, Nicolas George wrote:
> Le septidi 7 ventôse, an CCXXIII, Michael Niedermayer a écrit :
> > i think the case i tested had HAVE_W32THREADS set
> > also theres HAVE_OS2THREADS
>
> I suspect my question was too vague.
>
> If I understand correctly,
>
> HAVE
On Tue, Feb 24, 2015 at 10:10:21AM +, Kevin Wheatley wrote:
> +if (track->vos_data && track->vos_len > 0x29) {
> +if (track->vos_data[0] == 0x00 &&
> +track->vos_data[1] == 0x00 &&
> +track->vos_data[2] == 0x02 &&
> +track->vos_data[3] == 0x80 &&
On 02.03.2015, at 00:41, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> tests/fate/acodec.mak |6 ++
> tests/ref/acodec/s302m |4
> 2 files changed, 10 insertions(+)
> create mode 100644 tests/ref/acodec/s302m
Should be fine, more tests are always welcome
state for this, signalling
that we are actually executing in the main thread and thus can
call get_format directly in all cases.
These fix multithreaded decoding in MPlayer for example.
Signed-off-by: Reimar Döffinger
---
libavcodec/pthread_frame.c | 22 +++---
1 file changed, 19
On 07.03.2015, at 16:51, Peter wrote:
> The issue is this patch
> https://github.com/FFmpeg/FFmpeg/commit/ca4d71b149ebe32aeaf617ffccf362624b9aafb1
> which uses a member of the FILE struct which is not available in the
> new C runtime (it's now just a struct with a void*).
>
> I do not quite know
Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
in my tests on a G4 7450.
Signed-off-by: Reimar Döffinger
---
libavutil/ppc/intreadwrite.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/ppc/intreadwrite.h b/libavutil/ppc/intreadwrite.h
index 1ec349e
On 08.03.2015, at 00:46, Peter wrote:
> Alright, I may have been really stupid, for some reason I always passed
> "input_handle" to read and WaitForSingleObject instead of stdin, no clue
> what happened there in my head.
>
> Turns out this actually works in my initial tests:
>
> https://github.c
Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
in my tests on a G4 7450.
Signed-off-by: Reimar Döffinger
---
libavutil/ppc/intreadwrite.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/ppc/intreadwrite.h b/libavutil/ppc/intreadwrite.h
index 7671676
On Sun, Mar 08, 2015 at 05:12:50PM +0100, Rainer Hochecker wrote:
> ---
> libavcodec/hevc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
> index fdbaa28..7c7f920 100644
> --- a/libavcodec/hevc.c
> +++ b/libavcodec/hevc.c
> @@ -307,
On Sun, Mar 08, 2015 at 01:21:20PM -0300, James Almer wrote:
> On 08/03/15 1:16 PM, Reimar Döffinger wrote:
> > Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
> > in my tests on a G4 7450.
> >
> > Signed-off-by: Reimar Döffinger
> > ---
>
On 08.03.2015, at 18:08, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>> I sent an alternative patch "pthread: Fix ff_thread_get_format issues
>> when called outside frame decode."
>
> right, I didn't see you patch not the other code path.
On 08.03.2015, at 19:15, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
> I tried this patch with Kodi but did not get very far.
>
> int ff_thread_can_start_frame(AVCodecContext *avctx)
> {
>PerThreadContext *p = avctx->internal->thread_ctx;
>
On 08.03.2015, at 19:34, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 05:16:43PM +0100, Reimar Döffinger wrote:
>> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
>> in my tests on a G4 7450.
>>
>> Signed-off-by: Reimar Döffinger
>
> b
On Sun, Mar 08, 2015 at 08:44:50PM +0100, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 07:43:29PM +0100, Reimar Döffinger wrote:
> > On 08.03.2015, at 19:34, Michael Niedermayer wrote:
> > > On Sun, Mar 08, 2015 at 05:16:43PM +0100, Reimar Döffinger wrote:
> > >
On Sun, Mar 08, 2015 at 10:37:53PM +0100, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 09:59:21PM +0100, Reimar Döffinger wrote:
> > On Sun, Mar 08, 2015 at 08:44:50PM +0100, Michael Niedermayer wrote:
> > > On Sun, Mar 08, 2015 at 07:43:29PM +0100, Reimar Döffinger
On 08.03.2015, at 22:56, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
>
> I have tested this with Kodi. Works with sw decoding. With DXVA it crashes,
> looks like heap corruption or the like.
> setting thread_safe_callbacks = 1 cures the issue but I get s
On 09.03.2015, at 07:38, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
>>
>> Any reason to believe this patch causes it?
>> Because I can't see how it would.
>> Maybe it's just a bug with DXVA and multithreading in the HEVC code?
>
On 9 March 2015 13:34:24 CET, Hendrik Leppkes wrote:
>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker
> wrote:
>> Reimar Döffinger gmx.de> writes:
>>
>>>
>>> Any reason to believe this patch causes it?
>>> Because I can't see how it would.
&
On 9 March 2015 15:28:48 CET, Hendrik Leppkes wrote:
>On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger
> wrote:
>> On 9 March 2015 13:34:24 CET, Hendrik Leppkes
>wrote:
>>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker
>>> wrote:
>>>> Reimar Dö
On Tue, Mar 10, 2015 at 12:57:57AM +0800, zhaoxiu.zeng wrote:
> 在 2015/3/8 20:14, Michael Niedermayer 写道:
> > On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
> >> From ab12e3081ba987c2e05d819be97cde96952f1c2a Mon Sep 17 00:00:00 2001
> >> From: Zeng Zhaoxiu
> >> Date: Sat, 7 Mar 2015
On Sun, Mar 08, 2015 at 10:32:03PM +0100, Michael Niedermayer wrote:
> On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng wrote:
> > From 47c997fa0623ab94a7a93b2d2e4cc4fa64c85d5f Mon Sep 17 00:00:00 2001
> > From: Zeng Zhaoxiu
> > Date: Sat, 7 Mar 2015 23:26:42 +0800
> > Subject: [PATCH 1/1] a
On Mon, Mar 09, 2015 at 10:05:03PM +0100, Clément Bœsch wrote:
> On Mon, Mar 09, 2015 at 10:01:20PM +0100, Reimar Döffinger wrote:
> > On Sun, Mar 08, 2015 at 10:32:03PM +0100, Michael Niedermayer wrote:
> > > On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng w
On 10.03.2015, at 12:10, wm4 wrote:
> On Mon, 09 Mar 2015 18:56:57 +0100
> Reimar Döffinger wrote:
>>>
>>> What I do is simply restart decoding with the packet that failed the
>>> hardware decoder. Don't need to buffer anything, you still have the
>>
On 11.03.2015, at 10:13, Florian Jacob wrote:
> 11.03.2015, 00:51:39 by Timothy Gu:
>> Does this patch change the default behavior in any way?
>
> No, at least it's not intended to change for users who don't have a
> ~/.ssh/config.
>
> If there are users who have a config lying around and expec
On 11.03.2015, at 11:00, Florian Jacob wrote:
> Am Mittwoch, 11. März 2015, 10:27:55 schrieb Reimar Döffinger:
>> On 11.03.2015, at 10:13, Florian Jacob
> wrote:
>> If so, should they default to disabling compression?
> I only use ffmpeg to play videos in already-comp
On 11.03.2015, at 11:15, Nicolas George wrote:
> I firmly believe in the following principles:
>
> 1. If the user made an explicit choice, the application must obey, even if
> the choice seems stupid.
>
> In the case of SSH: compression is disabled by default, so enabling it is
> an explic
On 11.03.2015, at 12:34, wm4 wrote:
> On Tue, 10 Mar 2015 18:02:12 +0100
> Reimar Döffinger wrote:
>>>> Also the buffering issue is the other way, when you try to go from
>>>> multithreading to HW decode, how do you handle that?
>>>> If it works wel
On 09.03.2015, at 15:54, Hendrik Leppkes wrote:
>
> Of course avcodec shouldn't crash when you use it, but a patch to
> disallow this combination would never be accepted by yourself and some
> others that "like" this cheap (albeit wrong) method for fallback.
I forgot to reply: of course I would
On 11.03.2015, at 13:05, Lukasz Marek wrote:
> On 11.03.2015 11:15, Nicolas George wrote:
>>
>>
>> I firmly believe in the following principles:
>>
>> 1. If the user made an explicit choice, the application must obey, even if
>>the choice seems stupid.
>>
>>In the case of SSH: compr
On 14.03.2015, at 20:08, Christophe Gisquet
wrote:
> 2015-03-14 20:06 GMT+01:00 Michael Niedermayer :
>>> So here's an updated patch.
>>
>> yes, but not in the email ;)
>
> Crap, I prepared the mail in advance, but forgot to attach the patch
> after the fate run.
I kind of object to making th
On 14.03.2015, at 12:48, Christophe Gisquet
wrote:
> It was set to 1 instead of sqrt(3)
> ---
> libavcodec/ac3dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index ce45186..ae4129f 100644
> --- a/libavcodec/ac3dec.c
> +++
On 17.03.2015, at 05:08, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Better name (av_zero_high_bits?) and doxygen welcome.
Maybe av_wrap_intp2? (to align with clip function naming)
Or av_mod_p2?
Essentially it does a modulo with a power of 2.
Otherwise "clear" high bits seems a more
On 23.03.2015, at 22:05, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/utils.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 6a0f666..6eec7a1 100644
> --- a/libavformat/utils.c
>
On Fri, Mar 20, 2015 at 04:06:56PM +0800, 周晓勇 wrote:
> The optimization mainly include libavcodec, libavutil, and mplayer's
> fast_memcpy.
Note that fast_memcpy for 720p and above really is only a bad workaround
against horrible libc implementations.
I can only strongly recommend to fix the libc
On Tue, Mar 24, 2015 at 08:07:28AM +, Simon Ferquel wrote:
> I have needed libavformat/libavcodec for a drone piloting app project
> targetting (among others) the Windows modern platform (Win81 modern, Windows
> Phone, and Xbox one in a near future).
>
> To make it easier to generate static
'll resubmit the patch
> when these issues are fixed.
> ________
> De : Reimar Döffinger<mailto:reimar.doeffin...@gmx.de>
> Envoyé : 24/03/2015 21:56
> À : FFmpeg development discussions and patches<mailto:ffmpeg-devel@ffmpeg.org>
> O
On Mon, Apr 13, 2015 at 09:59:57AM +, Marco Porsch wrote:
> Previously we had regular 16bit RAW that worked like a charm as input to
> FFmpeg. The naïve approach of upscaling the 12bit to 16bit destroys the
> compression efficiency of course...
I think there's your problem, that is not a "of
for malloc failure.
Probably both ought to be changed to AVERROR(ENOMEM).
Signed-off-by: Reimar Döffinger
---
libavfilter/dnn/dnn_backend_native.c | 10 +-
libavfilter/dnn/dnn_backend_native.h | 2 ++
libavfilter/dnn/dnn_backend_native_layer_conv2d.c
for malloc failure.
Probably both ought to be changed to AVERROR(ENOMEM).
Signed-off-by: Reimar Döffinger
---
libavfilter/dnn/dnn_backend_native.c | 10 +-
libavfilter/dnn/dnn_backend_native.h | 2 ++
libavfilter/dnn/dnn_backend_native_layer_conv2d.c
On Sun, Jul 05, 2020 at 06:18:20PM +0100, Kieran Kunhya wrote:
> On Sun, Jul 5, 2020 at 6:01 PM Kieran Kunhya wrote:
> >
> > Going back to the original point in hand.
> > Many patches aren't getting reviewed and pushed any more.
> >
> > In part this is because in 2020 whether we like it or not mai
On Sun, Jul 05, 2020 at 10:50:14PM +0200, Michael Niedermayer wrote:
> To Achieve this, we could try to
> * attract more developers doing reviews, i have generally suggested
> contributors to help review other peoples patches. Maybe i should
> take a step back and ask developers to ask develope
> On 26 Feb 2022, at 16:33, James Almer wrote:
>
> The module is now always compiled in.
Thanks, both patches in this series or the alternative patch are fine with me.
Only possible downside I could think of is if there is any use-case why someone
would want the matroska decoder to specifical
Hi!
> On 24 Jun 2023, at 21:14, Andreas Rheinhardt
> wrote:
>
> Michael Niedermayer:
>> Fixes: out of array access
>> Fixes: crash-0d640731c7da52415670eb47a2af701cbe2e1a3b
>>
>> Found-by: Catena cyber
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavcodec/parser.c | 2 +-
>> 1 file change
> On 27 Jul 2023, at 15:55, Rémi Denis-Courmont wrote:
>
> Hi,
>
> The use of RET vs BR also has microarchitectural side effects. AFAIU, RET
> should always be paired with an earlier BL/BLR to avoid interfering with
> branch prediction.
>
> So depending on the circumstances, either one of th
> On 26 Jul 2023, at 21:43, Martin Storsjö wrote:
>
> On Wed, 26 Jul 2023, reimar.doeffin...@gmx.de wrote:
>
>> From: Reimar Döffinger
>>
>> ret can be given an argument instead.
>> This is also consistent with how other assembler code
>> in FF
> On 23 Jul 2023, at 14:00, reimar.doeffin...@gmx.de wrote:
>
> From: Reimar Döffinger
>
> Change some internal APIs a bit to make it harder to make
> such mistakes.
> In particular, have the read chunk functions return an error
> when the result is incomplete.
>
> On 27 Jul 2023, at 19:33, Nicolas George wrote:
>
> reimar.doeffin...@gmx.de (12023-07-23):
>> From: Reimar Döffinger
>>
>> Change some internal APIs a bit to make it harder to make
>> such mistakes.
>> In particular, have the read chunk function
> On 28 Jul 2023, at 03:37, L. E. Segovia wrote:
>
> Updated for 6.0, any constructive feedback will be appreciated.
Using #if means the code will not even be compile tested if the
feature is disabled, this makes maintenance especially of rare
features much harder (nevermind code readability).
> On 28 Jul 2023, at 12:40, Reimar Döffinger wrote:
>
>
>> On 28 Jul 2023, at 03:37, L. E. Segovia wrote:
>>
>> Updated for 6.0, any constructive feedback will be appreciated.
>
> Using #if means the code will not even be compile tested if the
> feature
> On 27 Jul 2023, at 19:44, Nicolas George wrote:
>
> Reimar Döffinger (12023-07-27):
>> Thanks, sent a new version with that updated, plus a fix for a typo
>> in the commit message.
>
> If it is all you have changed, then I do not think I need to look at it
>
> On 26 Jul 2023, at 21:15, reimar.doeffin...@gmx.de wrote:
>
> From: Reimar Döffinger
>
> ret can be given an argument instead.
> This is also consistent with how other assembler code
> in FFmpeg does it.
Now pushed.
___
ffmp
On 06.07.2014, at 06:09, Timothy Gu wrote:
> This header is designed as a public header (with APIchanges entry and
> everything), but it is forgotten to put into the headers to be installed
> list.
Note I think that originally the API was considered bad and subject to change,
thus it wasn't inst
On Sun, Jul 13, 2014 at 08:38:44PM +0200, wm4 wrote:
> On Sun, 13 Jul 2014 19:32:56 +0100
> Derek Buitenhuis wrote:
>
> > mplayer-specifc hacks should not be in our codebase. mplayer should fix
> > it's own code. It is not our responsibility to work around their broken
> > code.
> >
> > This rev
Hi,
On Sun, Jul 13, 2014 at 07:32:56PM +0100, Derek Buitenhuis wrote:
> mplayer-specifc hacks should not be in our codebase. mplayer should fix
> it's own code. It is not our responsibility to work around their broken
> code.
As far as I can tell MPlayer is now no longer affected.
Unfortunately o
On 14.07.2014, at 04:55, Hanspeter Niederstrasser
wrote:
> The AVFoundation indev uses kCVPixelFormatType_OneComponent8, but that
> only exists on 10.8 and up. This puts it behind a #if.
It's not ideal. Maybe not worth the effort, but it would be better if a version
compiled for older OSX coul
On 14.07.2014, at 00:15, wm4 wrote:
> On Sun, 13 Jul 2014 22:17:44 +0200
> Reimar Döffinger wrote:
>
>> On Sun, Jul 13, 2014 at 08:38:44PM +0200, wm4 wrote
>>
>>> A project specific hack for
>>> something that used the API incorrectly. I surely hope mp
On 14.07.2014, at 15:21, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
>
>> In other words, I think the check should be about whether
>> the header provides that definition, not what minimum OSX
>> version we compile for.
>
> Isn't this e
On 15.07.2014, at 16:31, Michael Niedermayer wrote:
> Found-by: kriegero1
> Signed-off-by: Michael Niedermayer
Nit: iNdependent in commit message.
> +/* JFIF header */
> +put_marker(p, APP0);
> +put_bits(p, 16, 16);
> +avpriv_put_string(p, "JFIF", 1); /* this puts the trailin
On 15.07.2014, at 18:14, Andrey Utkin wrote:
> Thanks, with this change streaming HTTP MJPEG stream into browsers
> work (with inserting boundaries, which is easy for scripting).
oh, and please add an explanation like this (assuming this is the reason for
it) to the commit message.
_
On 16.07.2014, at 17:46, Andrey Utkin wrote:
> 2014-07-15 21:39 GMT+03:00 Andrey Utkin :
>> 2014-07-15 19:16 GMT+03:00 Nicolas George :
>>> Le septidi 27 messidor, an CCXXII, Andrey Utkin a écrit :
Thanks, with this change streaming HTTP MJPEG stream into browsers
work (with inserting bo
On Sun, Jul 20, 2014 at 10:43:30PM +0200, Andreas Cadhalpun wrote:
> On 12.06.2014 08:42, Christophe Gisquet wrote:
> >Hi,
> >
> >2014-06-11 21:29 GMT+02:00 Michael Niedermayer :
> >>-#define FF_INPUT_BUFFER_PADDING_SIZE 16
> >>+#define FF_INPUT_BUFFER_PADDING_SIZE 32
> >
> >So, following the discu
On Sun, Jul 27, 2014 at 01:23:34AM +0100, Kieran Kunhya wrote:
> ---
> libavcodec/opus.c| 11 +---
> libavcodec/opus.h|9 +++
> libavcodec/opus_parser.c | 139
> +-
> libavcodec/opusdec.c |1 +
> libavformat/mpegts.c |
On Mon, Jul 28, 2014 at 04:30:02AM +0200, Michael Niedermayer wrote:
> This works around ABI issues with applications which depend on libavutil
> internal values like sizeof(AVFrame)
> One such application is VLC 2.1.4 as well as 2.1.5
As you said yourself, we have been and will be relying on this
On Mon, Jul 28, 2014 at 08:33:14PM +0200, Hendrik Leppkes wrote:
> Am 28.07.2014 04:30 schrieb "Michael Niedermayer" :
> > diff --git a/libavutil/version.h b/libavutil/version.h
> > index 6d8d6f0..1deb6e4 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
> > @@ -138,7 +138,7 @@
> >
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 4d2a506..03f3df7 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -992,7 +992,7 @@ static const MXFCodecUL
Signed-off-by: Reimar Döffinger
---
libavformat/mov.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6a9af69..7b1dbb2 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -119,15 +119,13 @@ static int mov_metadata_gnre
Signed-off-by: Reimar Döffinger
---
libavutil/dict.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavutil/dict.c b/libavutil/dict.c
index 66a0773..2cd67e8 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -90,10 +90,9 @@ int av_dict_set(AVDictionary **pm
Unfortunately this was not explicitly documented and thus
might be very risky.
But basically all uses I saw in FFmpeg had a memleak in these
cases.
Signed-off-by: Reimar Döffinger
---
libavutil/dict.c | 9 +++--
libavutil/dict.h | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff
Ensure this is even the case if they are empty because
we failed adding the first entry.
Signed-off-by: Reimar Döffinger
---
libavutil/dict.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/dict.c b/libavutil/dict.c
index 2cd67e8..9063a57 100644
--- a/libavutil/dict.c
+++ b
Signed-off-by: Reimar Döffinger
---
libavutil/dict.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavutil/dict.c b/libavutil/dict.c
index 358958c..aea8910 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -90,10 +90,9 @@ int av_dict_set(AVDictionary **pm
This allows getting rid of the many, slightly differing, implementations
of basically the same thing.
Signed-off-by: Reimar Döffinger
---
doc/APIchanges | 3 +++
ffmpeg_opt.c | 12 +++-
ffplay.c | 2 +-
libavfilter
Unfortunately this was not explicitly documented and thus
might be very risky.
But basically all uses I saw in FFmpeg had a memleak in these
cases.
Signed-off-by: Reimar Döffinger
---
libavutil/dict.c | 9 +++--
libavutil/dict.h | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff
Ensure this is even the case if they are empty because
we failed adding the first entry.
Signed-off-by: Reimar Döffinger
---
libavutil/dict.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/dict.c b/libavutil/dict.c
index 2cd67e8..9063a57 100644
--- a/libavutil/dict.c
+++ b
On Tue, Jul 29, 2014 at 10:13:39PM +0200, Michael Niedermayer wrote:
> On Tue, Jul 29, 2014 at 09:26:48PM +0200, Reimar Döffinger wrote:
> > Unfortunately this was not explicitly documented and thus
> > might be very risky.
> > But basically all uses I saw in FFmpeg h
On Wed, Jul 30, 2014 at 08:38:06PM +0200, Reimar Döffinger wrote:
> This allows getting rid of the many, slightly differing, implementations
> of basically the same thing.
This one really can need a few extra eyes.
It's likely I missed a few places, and there's a risk I messed up
On Wed, Jul 30, 2014 at 09:22:27PM +0200, wm4 wrote:
> > /**
> > @@ -123,6 +125,12 @@ int av_dict_count(const AVDictionary *m);
> > int av_dict_set(AVDictionary **pm, const char *key, const char *value, int
> > flags);
> >
> > /**
> > + * Convenience wrapper for av_dict_set that converts the
701 - 794 of 794 matches
Mail list logo
