I am very sorry, I didn't search for this thread because I thought the
patch was applied. I will send a patch addressing all the comments
mentioned by you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-dev
When OpenCL kernels are compiled, is_compiled flag is being set for each
kernel. But, in opencl uninit, this flag is not being cleared.
This causes an error when an OpenCL kernel is tried on different OpenCL
devices on same platform.
Here is the patch with a fix
---
libavutil/opencl.c | 3 +++
1
On date Friday 2015-02-20 01:11:40 +0100, Stefano Sabatini encoded:
> On date Thursday 2015-02-19 17:13:15 +0530, Arwa Arif encoded:
> > Updated the patch.
>
> > From 66a8c9d03995c9e7c6ccc05fb9b20756f51c17f4 Mon Sep 17 00:00:00 2001
> > From: Arwa Arif
> > Date: Thu, 19 Feb 2015 01:26:44 +0530
>
Thilo Borgmann mail.de> writes:
> >>> New, simpler patch attached.
> Please apply but check for CoreGraphics first, please.
I applied this patch.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/l
Paul B Mahol gmail.com> writes:
> > Attached patch fixes ticket #4349 for me.
> >
> > Please comment, Carl Eugen
> >
> probably ok.
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/l
On 04.03.2015 23:13, Luca Barbato wrote:
On 04/03/15 21:49, Andreas Cadhalpun wrote:
So what do you think about resurrecting this patch (add avformat_flush)?
I see no patch about it, my email client chewed it?
It has been a while ago [1]. It just adds a public API for ff_read_frame_flush.
While the native jpeg2000 decoder can determine pixel format correctly
from the codestream, libopenjpeg wrapper cannot. To make sure that
the output is correct when using libopenjpeg to decode digital
cinema files, we do detection from the metadata included in the MXF
wrapper.
If the container has
On Wed, Oct 01, 2014 at 07:59:12AM +0200, Reimar Döffinger wrote:
> 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 Tue, Sep 30, 2014 at 06:46:49PM +0200, wm4 wrote:
> TODO: add entry to APIchanges, bump minor version.
> ---
> Updated the doxygen.
> ---
> libavformat/avformat.h | 17 +
> libavformat/utils.c| 6 ++
> 2 files changed, 23 insertions(+)
applied
thanks
[...]
--
Michae
On Wed, 04 Mar 2015 20:35:51 +
Derek Buitenhuis wrote:
> On 3/4/2015 7:21 PM, Andreas Cadhalpun wrote:
> > Unfortunately XBMC is using these semi-private fields, so it gets broken by
> > this
> > change. Therefore I think it would be better to postpone this until after a
> > SOVERSION bump
On 3/4/15, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #4349 for me.
>
> Please comment, Carl Eugen
>
probably ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Mar 04, 2015 at 10:18:07PM +0100, Michael Niedermayer wrote:
> On Wed, Mar 04, 2015 at 09:59:35PM +0100, Nicolas George wrote:
> > Le quartidi 14 ventôse, an CCXXIII, Peter Cordes a écrit :
> > > - "n:%"PRId64" pts:%s pts_time:%s pos:%"PRId64" "
> > > + "n:%4"PRId64" pts
On Wed, 4 Mar 2015 22:33:57 +0100
Michael Niedermayer wrote:
> On Wed, Mar 04, 2015 at 09:49:17PM +0100, Andreas Cadhalpun wrote:
> > On 04.03.2015 21:14, wm4 wrote:
> > >On Wed, 4 Mar 2015 21:05:04 +0100
> > >Hendrik Leppkes wrote:
> > >>On Wed, Mar 4, 2015 at 8:59 PM, wm4 wrote:
> > >>>On Wed
---
libavformat/dashenc.c | 43 ---
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 25c699e..92b7d6c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -72,7 +72,6 @@ typedef
Students are coming on irc looking for help and guidance at all hours
of the day, so if anyone feels like helping out, that would be great!
Even just a few more people on irc to greet students would be nice.
Some students require simple things like help with getting git installed
or installing vdp
On Wed, Mar 04, 2015 at 09:49:17PM +0100, Andreas Cadhalpun wrote:
> On 04.03.2015 21:14, wm4 wrote:
> >On Wed, 4 Mar 2015 21:05:04 +0100
> >Hendrik Leppkes wrote:
> >>On Wed, Mar 4, 2015 at 8:59 PM, wm4 wrote:
> >>>On Wed, 04 Mar 2015 20:21:26 +0100
> >>>Andreas Cadhalpun wrote:
[...]
> >>Also,
On Wed, Mar 04, 2015 at 09:59:35PM +0100, Nicolas George wrote:
> Le quartidi 14 ventôse, an CCXXIII, Peter Cordes a écrit :
> > - "n:%"PRId64" pts:%s pts_time:%s pos:%"PRId64" "
> > + "n:%4"PRId64" pts:%7s pts_time:%-7s pos:%9"PRId64" "
>
> Unless I am wrong reading the printf
On Wed, Mar 04, 2015 at 02:19:36PM -0400, Peter Cordes wrote:
> On Wed, Mar 4, 2015 at 9:42 AM, Michael Niedermayer
> wrote:
>
> > On Wed, Mar 04, 2015 at 02:24:58PM +0100, Michael Niedermayer wrote:
> > > On Wed, Mar 04, 2015 at 02:11:42PM +0100, Michael Niedermayer wrote:
> > > > On Tue, Mar 03
Le quartidi 14 ventôse, an CCXXIII, Peter Cordes a écrit :
> - "n:%"PRId64" pts:%s pts_time:%s pos:%"PRId64" "
> + "n:%4"PRId64" pts:%7s pts_time:%-7s pos:%9"PRId64" "
Unless I am wrong reading the printf specifiers, this will print
"pts:902" instead of "pts:902". Some scri
On 04.03.2015 21:14, wm4 wrote:
On Wed, 4 Mar 2015 21:05:04 +0100
Hendrik Leppkes wrote:
On Wed, Mar 4, 2015 at 8:59 PM, wm4 wrote:
On Wed, 04 Mar 2015 20:21:26 +0100
Andreas Cadhalpun wrote:
Unfortunately XBMC is using these semi-private fields, so it gets broken by this
change. Therefore
On 3/4/2015 7:21 PM, Andreas Cadhalpun wrote:
> Unfortunately XBMC is using these semi-private fields, so it gets broken by
> this
> change. Therefore I think it would be better to postpone this until after a
> SOVERSION bump.
Why exactly should we care about a project that uses explicitly priv
---
libavformat/mxfenc.c | 97 +--
tests/ref/lavf/mxf| 6 +--
tests/ref/lavf/mxf_d10| 2 +-
tests/ref/lavf/mxf_opatom | 2 +-
4 files changed, 91 insertions(+), 16 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
changes since v4:
* added UINT16_MAX check in mxf_utf16_local_tag_length
and mxf_write_local_tag_utf16
Mark Reid (1):
libavformat/mxfenc: write package name metadata
libavformat/mxfenc.c | 97 +--
tests/ref/lavf/mxf| 6 +--
tests/ref/
On Wed, 4 Mar 2015 21:05:04 +0100
Hendrik Leppkes wrote:
> On Wed, Mar 4, 2015 at 8:59 PM, wm4 wrote:
> > On Wed, 04 Mar 2015 20:21:26 +0100
> > Andreas Cadhalpun wrote:
> >
> >> Hi,
> >>
> >> On 06.02.2015 14:53, wm4 wrote:
> >> > This is not an API change; the fields were explicitly declared
On Wed, Mar 4, 2015 at 8:59 PM, wm4 wrote:
> On Wed, 04 Mar 2015 20:21:26 +0100
> Andreas Cadhalpun wrote:
>
>> Hi,
>>
>> On 06.02.2015 14:53, wm4 wrote:
>> > This is not an API change; the fields were explicitly declared private
>> > before.
>>
>> Unfortunately XBMC is using these semi-private f
On Wed, 04 Mar 2015 20:21:26 +0100
Andreas Cadhalpun wrote:
> Hi,
>
> On 06.02.2015 14:53, wm4 wrote:
> > This is not an API change; the fields were explicitly declared private
> > before.
>
> Unfortunately XBMC is using these semi-private fields, so it gets broken by
> this
> change. Therefo
Hi!
Attached patch fixes ticket #4349 for me.
Please comment, Carl Eugen
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 14d143e..61b37f8 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -50,6 +50,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x
Hi,
On 06.02.2015 14:53, wm4 wrote:
This is not an API change; the fields were explicitly declared private
before.
Unfortunately XBMC is using these semi-private fields, so it gets broken by this
change. Therefore I think it would be better to postpone this until after a
SOVERSION bump.
Lo
On Wed, Mar 4, 2015 at 9:42 AM, Michael Niedermayer
wrote:
> On Wed, Mar 04, 2015 at 02:24:58PM +0100, Michael Niedermayer wrote:
> > On Wed, Mar 04, 2015 at 02:11:42PM +0100, Michael Niedermayer wrote:
> > > On Tue, Mar 03, 2015 at 10:51:01PM -0400, Peter Cordes wrote:
> > > [...]
> > > > Anyway
On Wed, Mar 04, 2015 at 05:07:17PM +0200, Vilius Grigaliūnas wrote:
> On Wed, Mar 4, 2015 at 4:48 PM, Michael Niedermayer wrote:
> > i did not mean to suggest to leave libopenjpeg broken.
>
> It is not technically broken, it just relies on guessing in some cases
> which might not always be correc
On Wed, Mar 4, 2015 at 4:07 AM, wrote:
> On 2015-03-03 05:06, Mark Reid wrote:
>
>> +/*
>> + * Returns the calculated length a local tag containing an utf-8
>> string as utf-16
>> + */
>> +static uint64_t mxf_utf16_local_tag_length(const char *utf8_str)
>> +{
>> +return utf8_str? 4 + mxf_utf1
On Wed, Mar 04, 2015 at 07:07:35PM +0100, Robert Krüger wrote:
> On Wed, Mar 4, 2015 at 6:57 PM, Michael Niedermayer
> wrote:
>
> > On Wed, Mar 04, 2015 at 06:19:19PM +0100, Robert Krüger wrote:
> > > On Wed, Mar 4, 2015 at 5:34 PM, Michael Niedermayer
> > > wrote:
> > >
> > > > On Wed, Mar 04,
On Wed, Mar 4, 2015 at 6:57 PM, Michael Niedermayer
wrote:
> On Wed, Mar 04, 2015 at 06:19:19PM +0100, Robert Krüger wrote:
> > On Wed, Mar 4, 2015 at 5:34 PM, Michael Niedermayer
> > wrote:
> >
> > > On Wed, Mar 04, 2015 at 03:40:09PM +0100, Robert Krüger wrote:
> > > > On Wed, Mar 4, 2015 at 1
On Wed, Mar 04, 2015 at 06:19:19PM +0100, Robert Krüger wrote:
> On Wed, Mar 4, 2015 at 5:34 PM, Michael Niedermayer
> wrote:
>
> > On Wed, Mar 04, 2015 at 03:40:09PM +0100, Robert Krüger wrote:
> > > On Wed, Mar 4, 2015 at 11:05 AM, Michael Niedermayer
> > > wrote:
> > >
> > > > On Wed, Mar 04,
On Wed, Mar 4, 2015 at 5:34 PM, Michael Niedermayer
wrote:
> On Wed, Mar 04, 2015 at 03:40:09PM +0100, Robert Krüger wrote:
> > On Wed, Mar 4, 2015 at 11:05 AM, Michael Niedermayer
> > wrote:
> >
> > > On Wed, Mar 04, 2015 at 10:22:26AM +0100, Robert Krüger wrote:
> > > > On Tue, Mar 3, 2015 at
On Wed, Mar 04, 2015 at 03:40:09PM +0100, Robert Krüger wrote:
> On Wed, Mar 4, 2015 at 11:05 AM, Michael Niedermayer
> wrote:
>
> > On Wed, Mar 04, 2015 at 10:22:26AM +0100, Robert Krüger wrote:
> > > On Tue, Mar 3, 2015 at 9:27 PM, Michael Niedermayer
> > > wrote:
> > >
> > > > On Tue, Mar 03,
On Wed, Mar 4, 2015 at 4:48 PM, Michael Niedermayer wrote:
> i did not mean to suggest to leave libopenjpeg broken.
It is not technically broken, it just relies on guessing in some cases
which might not always be correct. It think there should be a warning
that this is happening and a way to over
On Wed, Mar 4, 2015 at 11:05 AM, Michael Niedermayer
wrote:
> On Wed, Mar 04, 2015 at 10:22:26AM +0100, Robert Krüger wrote:
> > On Tue, Mar 3, 2015 at 9:27 PM, Michael Niedermayer
> > wrote:
> >
> > > On Tue, Mar 03, 2015 at 09:24:17PM +0100, Robert Krüger wrote:
> > > > On Tue, Mar 3, 2015 at
On Wed, Mar 04, 2015 at 04:10:39PM +0200, Vilius Grigaliūnas wrote:
> On Wed, Mar 4, 2015 at 10:08 AM, Vilius Grigaliūnas
> wrote:
> > On Wed, Mar 4, 2015 at 1:03 AM, Michael Niedermayer
> > wrote:
> >> this detects codestreams_profile0/p0_08.j2k as xyz, is this intended?
> >
> > No, this seems
On Tue, Mar 03, 2015 at 10:51:01PM -0400, Peter Cordes wrote:
> I've made some patches, and am finally getting around to sending them
> upstream.
>
> I'm trying out gmail for dealing with a high-traffic list like this one,
> instead of my usual mutt. Are the one-line-paragraph long lines it's
> p
On Wed, Mar 4, 2015 at 10:08 AM, Vilius Grigaliūnas
wrote:
> On Wed, Mar 4, 2015 at 1:03 AM, Michael Niedermayer wrote:
>> this detects codestreams_profile0/p0_08.j2k as xyz, is this intended?
>
> No, this seems to be a regression. At the moment there is not enough
> information in openjpeg data
On Wed, Mar 04, 2015 at 02:24:58PM +0100, Michael Niedermayer wrote:
> On Wed, Mar 04, 2015 at 02:11:42PM +0100, Michael Niedermayer wrote:
> > On Tue, Mar 03, 2015 at 10:51:01PM -0400, Peter Cordes wrote:
> > [...]
> > > Anyway, the av_dict change is the one that requires the most review, so
> > >
On Wed, Mar 04, 2015 at 02:11:42PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 03, 2015 at 10:51:01PM -0400, Peter Cordes wrote:
> [...]
> > Anyway, the av_dict change is the one that requires the most review, so
> > I'll make this email focus on that set of changes.
> > https://github.com/FFmp
On Tue, Mar 03, 2015 at 10:51:01PM -0400, Peter Cordes wrote:
[...]
> Anyway, the av_dict change is the one that requires the most review, so
> I'll make this email focus on that set of changes.
> https://github.com/FFmpeg/FFmpeg/pull/118
pull req #3, patch #1 review
> -char *ret = out, *
Hi Krishna!
Am 04.03.15 um 07:10 schrieb krishna gandhi:
> Hi all I am Krishna Gupta undergraduate Electronics and Communication
> student at IIIT hyd. I have gone through this year ideas and project from
> org's GSOC page and one project that interest me a lot is MPEG-4 ALS
> encoder. I have litt
On Tue, Mar 03, 2015 at 10:51:01PM -0400, Peter Cordes wrote:
> I've made some patches, and am finally getting around to sending them
> upstream.
>
> I'm trying out gmail for dealing with a high-traffic list like this one,
> instead of my usual mutt. Are the one-line-paragraph long lines it's
> p
On 2015-03-03 05:06, Mark Reid wrote:
+/*
+ * Returns the calculated length a local tag containing an utf-8
string as utf-16
+ */
+static uint64_t mxf_utf16_local_tag_length(const char *utf8_str)
+{
+return utf8_str? 4 + mxf_utf16len(utf8_str) * 2: 0;
Should return zero if mxf_utf16len()*2
Le tridi 13 ventôse, an CCXXIII, Michael Niedermayer a écrit :
> yes and i really think we should do something about this
> IMHO API users should be able to define and register filters, codecs
> and formats
For filters, now that they use AVFrame and the complex buffer management API
is gone, it se
On Wed, 2015-03-04 at 11:08 +, Nedeljko Babic wrote:
> >The assembly versions have a few problems
> >- They only work with mips32r2 enabled
> >- They don't work on 64-bits
> >- They're massive and complex
> >
> >So replace them with C implementations which solve these problems and let GCC
> >ma
On Sun, Mar 01, 2015 at 06:33:10PM -0800, Mark Reid wrote:
> hi,
> I was unsure whether this should be a function or a macro, I went with a
> function.
i think functions are better, especially when you try to read a
backtrace in gdb
then again i think macros are better when you wonder why gcc did
>>The assembly versions have a few problems
>>- They only work with mips32r2 enabled
>>- They don't work on 64-bits
>>- They're massive and complex
>>
>>So replace them with C implementations which solve these problems and let GCC
>>magically optimize for different platforms. All the functions are
>The assembly versions have a few problems
>- They only work with mips32r2 enabled
>- They don't work on 64-bits
>- They're massive and complex
>
>So replace them with C implementations which solve these problems and let GCC
>magically optimize for different platforms. All the functions are manuall
On Wed, 2015-03-04 at 11:52 +0100, Michael Niedermayer wrote:
> On Wed, Mar 04, 2015 at 10:10:15AM +, Nedeljko Babic wrote:
> > LGTM
>
> seems this does not apply cleanly on HEAD
> Applying: mips: port optimizations to mips n64
> error: patch failed: libavcodec/mips/acelp_filters_mips.c:82
> e
On Thu, Feb 26, 2015 at 01:55:48PM +, James Cowgill wrote:
> On Thu, 2015-02-26 at 13:51 +, Derek Buitenhuis wrote:
> > On 2/26/2015 1:42 PM, James Cowgill wrote:
> > > The assembly versions have a few problems
> > > - They only work with mips32r2 enabled
> > > - They don't work on 64-bits
On Wed, Mar 04, 2015 at 10:10:15AM +, Nedeljko Babic wrote:
> LGTM
seems this does not apply cleanly on HEAD
Applying: mips: port optimizations to mips n64
error: patch failed: libavcodec/mips/acelp_filters_mips.c:82
error: libavcodec/mips/acelp_filters_mips.c: patch does not apply
error: patc
LGTM
Thanks,
- Nedeljko
Od: James Cowgill [james...@cowgill.org.uk]
Poslato: 26. februar 2015 14:42
Za: ffmpeg-devel@ffmpeg.org
Cc: Nedeljko Babic; James Cowgill
Tema: [PATCH 09/12] mips: port optimizations to mips n64
This mainly consists of replacing all
On Wed, Mar 04, 2015 at 10:08:56AM +0200, Vilius Grigaliūnas wrote:
> On Wed, Mar 4, 2015 at 1:03 AM, Michael Niedermayer wrote:
> > this detects codestreams_profile0/p0_08.j2k as xyz, is this intended?
>
> No, this seems to be a regression. At the moment there is not enough
> information in open
>> >Removing these removes the dependency of this code on mips32r2 which would
>> >allow it to be used on processors which have FPU instructions, but not r2
>> >instructions (like the mips64el debian port for instance).
>> >
>>
>> I would be more comfortable if there were two instances of this cod
On Wed, Mar 04, 2015 at 10:22:26AM +0100, Robert Krüger wrote:
> On Tue, Mar 3, 2015 at 9:27 PM, Michael Niedermayer
> wrote:
>
> > On Tue, Mar 03, 2015 at 09:24:17PM +0100, Robert Krüger wrote:
> > > On Tue, Mar 3, 2015 at 7:23 PM, Michael Niedermayer
> > > wrote:
> > >
> > > > On Tue, Mar 03,
On Tue, Mar 3, 2015 at 9:27 PM, Michael Niedermayer
wrote:
> On Tue, Mar 03, 2015 at 09:24:17PM +0100, Robert Krüger wrote:
> > On Tue, Mar 3, 2015 at 7:23 PM, Michael Niedermayer
> > wrote:
> >
> > > On Tue, Mar 03, 2015 at 06:17:22PM +0100, Robert Krüger wrote:
> > >
> > > > This is based on a
On Wed, Mar 4, 2015 at 1:03 AM, Michael Niedermayer wrote:
> this detects codestreams_profile0/p0_08.j2k as xyz, is this intended?
No, this seems to be a regression. At the moment there is not enough
information in openjpeg data structures (opj_image_t specifically) to
reliably determine whether
61 matches
Mail list logo
