On Sat, 18 Mar 2017 13:39:34 +0700
Muhammad Faiz wrote:
> On Sat, Mar 18, 2017 at 5:31 AM, Carl Eugen Hoyos wrote:
> > 2017-03-17 19:46 GMT+01:00 James Almer :
> >> Signed-off-by: James Almer
> >> ---
> >> compat/atomics/gcc/stdatomic.h | 8
> >> 1 file changed, 4 insertions(+), 4 d
On Sat, Mar 18, 2017 at 5:31 AM, Carl Eugen Hoyos wrote:
> 2017-03-17 19:46 GMT+01:00 James Almer :
>> Signed-off-by: James Almer
>> ---
>> compat/atomics/gcc/stdatomic.h | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/compat/atomics/gcc/stdatomic.h b/compat/a
when use stream_loop to control the loop times, the seekable is
set to 0 default, and must set duration or inpoint and outpoint
into the concat list, now use this option can support use stream_loop
to control the loop times of the concat list
Signed-off-by: Steven Liu
---
doc/demuxers.texi
On Sat, 18 Mar 2017 00:15:53 -0300
James Almer wrote:
> On 3/17/2017 11:56 PM, wm4 wrote:
> > On Fri, 17 Mar 2017 23:47:26 -0300
> > James Almer wrote:
> >
> >> On 3/17/2017 11:38 PM, wm4 wrote:
> >>> On Fri, 17 Mar 2017 13:59:40 +0100
> >>> Hendrik Leppkes wrote:
> >>>
> On Fri,
On 3/17/2017 11:56 PM, wm4 wrote:
> On Fri, 17 Mar 2017 23:47:26 -0300
> James Almer wrote:
>
>> On 3/17/2017 11:38 PM, wm4 wrote:
>>> On Fri, 17 Mar 2017 13:59:40 +0100
>>> Hendrik Leppkes wrote:
>>>
On Fri, Mar 17, 2017 at 12:32 AM, Michael Niedermayer
wrote:
> On Thu, Mar
On Fri, 17 Mar 2017 23:47:26 -0300
James Almer wrote:
> On 3/17/2017 11:38 PM, wm4 wrote:
> > On Fri, 17 Mar 2017 13:59:40 +0100
> > Hendrik Leppkes wrote:
> >
> >> On Fri, Mar 17, 2017 at 12:32 AM, Michael Niedermayer
> >> wrote:
> >>> On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas Geo
On Fri, 17 Mar 2017 14:23:21 +0100
Michael Niedermayer wrote:
> On Fri, Mar 17, 2017 at 01:59:40PM +0100, Hendrik Leppkes wrote:
> > On Fri, Mar 17, 2017 at 12:32 AM, Michael Niedermayer
> > wrote:
> > > On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas George wrote:
> > >> Le sextidi 26 ven
On 3/17/2017 11:38 PM, wm4 wrote:
> On Fri, 17 Mar 2017 13:59:40 +0100
> Hendrik Leppkes wrote:
>
>> On Fri, Mar 17, 2017 at 12:32 AM, Michael Niedermayer
>> wrote:
>>> On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas George wrote:
Le sextidi 26 ventôse, an CCXXV, Michael Niedermayer a é
On Sat, 18 Mar 2017 01:51:39 +0100 (CET)
Marton Balint wrote:
> On Sat, 18 Mar 2017, wal...@free.fr wrote:
>
> > The logs: http://pastebin.com/1duYR0Ui
> >
>
> Log with video only (run ffplay with -an -sn) might show it more
> clearly, but even from the logs above it looks like the CrystalHD
On Fri, 17 Mar 2017 13:59:40 +0100
Hendrik Leppkes wrote:
> On Fri, Mar 17, 2017 at 12:32 AM, Michael Niedermayer
> wrote:
> > On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas George wrote:
> >> Le sextidi 26 ventôse, an CCXXV, Michael Niedermayer a écrit :
> >> > Applications which depend
On Fri, Mar 17, 2017 at 09:37:17PM +0100, Nicolas George wrote:
> Le septidi 27 ventôse, an CCXXV, Michael Niedermayer a écrit :
> > If your users problems are not your problem than you have the wrong
> > attitude to provide or design a service, API, lib, ... to users
>
> I was on a crappy phone v
On Fri, 17 Mar 2017, Matthias Hunstock wrote:
Signed-off-by: Matthias Hunstock
---
libavdevice/decklink_common.cpp | 17 +
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 5 +++--
libavdevice/decklink_dec_c.c| 1 +
libavdevice/decklink_enc_c.c|
On Sat, 18 Mar 2017, wal...@free.fr wrote:
The logs: http://pastebin.com/1duYR0Ui
Log with video only (run ffplay with -an -sn) might show it more clearly,
but even from the logs above it looks like the CrystalHD codec is
returning EAGAINs at the same time for both receive_frame and send_
The logs: http://pastebin.com/1duYR0Ui
Wallak.
- Mail original -
De: "Marton Balint"
À: "FFmpeg development discussions and patches"
Cc: wal...@free.fr
Envoyé: Vendredi 17 Mars 2017 23:38:31
Objet: Re: [FFmpeg-devel] [PATCH 2/3] ffplay: convert to new decode API
On Fri, 17 Mar 2017
On Fri, 17 Mar 2017, Matthias Hunstock wrote:
Signed-off-by: Matthias Hunstock
---
libavdevice/decklink_common.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 8b499c5..82b3a0c 100644
---
On Fri, 17 Mar 2017, wal...@free.fr wrote:
I tried the patch. Once av_assert0 test is removed, the crystalhd
decoder is running till send_packet triggers AVERROR(EAGAIN), now the
crystalhd buffer is likely overflowed, the video freezes. A few seconds
later the decoder displays a few frames a
2017-03-17 19:46 GMT+01:00 James Almer :
> Signed-off-by: James Almer
> ---
> compat/atomics/gcc/stdatomic.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/compat/atomics/gcc/stdatomic.h b/compat/atomics/gcc/stdatomic.h
> index 41caddec5c..2b64687437 100644
> ---
Le septidi 27 ventôse, an CCXXV, Michael Niedermayer a écrit :
> If your users problems are not your problem than you have the wrong
> attitude to provide or design a service, API, lib, ... to users
I was on a crappy phone virtual keyboard, I could not elaborate
comfortably.
Many many projects no
Signed-off-by: James Almer
---
compat/atomics/gcc/stdatomic.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/compat/atomics/gcc/stdatomic.h b/compat/atomics/gcc/stdatomic.h
index 41caddec5c..2b64687437 100644
--- a/compat/atomics/gcc/stdatomic.h
+++ b/compat/atomics/g
On 3/17/2017 12:47 PM, Vittorio Giovara wrote:
> These values are defined to be 32bit in the specification,
> so it makes more sense to store them as fixed width.
>
> Based on a patch by Micahel Niedermayer .
>
> Signed-off-by: Vittorio Giovara
> ---
> Hi,
> this is the version which applies cle
Since there are no comments since March 14, I assume this patch is good to go.
I tried to commit the patch and push it to the mirror on github.com, but was
denied access.
Can a developer please apply and commit this patch?
Thanks,- Dzung Hoang
From: Dzung Hoang
To: FFmpeg Development Di
Hi,
On Fri, Mar 17, 2017 at 11:43 AM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:
> On Tue, Mar 7, 2017 at 7:17 PM, Vittorio Giovara
> wrote:
> > This should address the mismatch between different archs
> > Please CC.
> > --
> > Vittorio
>
> ping
No objections issues after 24hrs mean
These values are defined to be 32bit in the specification,
so it makes more sense to store them as fixed width.
Based on a patch by Micahel Niedermayer .
Signed-off-by: Vittorio Giovara
---
Hi,
this is the version which applies cleanly to master and contains
changes requested by James.
Please CC
On Tue, Mar 7, 2017 at 7:17 PM, Vittorio Giovara
wrote:
> This should address the mismatch between different archs
> Please CC.
> --
> Vittorio
ping
Please CC.
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
I tried the patch. Once av_assert0 test is removed, the crystalhd decoder is
running till send_packet triggers AVERROR(EAGAIN), now the crystalhd buffer is
likely overflowed, the video freezes. A few seconds later the decoder displays
a few frames and the cycle goes on.
Im not sure how to prop
1.12x faster (638±12.7 vs. 568±4.3 decicycles) compared with mmxext
---
libavcodec/x86/h264_idct.asm | 11 +++
libavcodec/x86/h264dsp_init.c | 2 ++
2 files changed, 13 insertions(+)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index c4b6e55..a74e095 100644
-
1.01x faster (1069±1.9 vs. 1060±0.7 decicycles) compared with sse2
---
libavcodec/x86/h264_idct.asm | 5 +
libavcodec/x86/h264dsp_init.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index 24fb4d2..ca8ffdb 100644
--- a/libav
Broken FATE
1.02x faster (1580±4.8 vs. 1555±3.9 decicycles) compared with sse2
---
libavcodec/x86/h264_idct.asm | 43 +--
libavcodec/x86/h264dsp_init.c | 2 ++
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/libavcodec/x86/h264_idct.asm b/
A first draft of a patch set adding AVX functions for 8-bit H.264 IDCT.
Unfortunately they only provide a small speedup. 8-bit data isn't usually large
enough to take advantage of wider registers. Although I admit I might have
missed the places where only MMX code exists but 16-byte registers wou
---
libavcodec/x86/h264_idct.asm | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index 878ff02..dde40e9 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -846,7
---
libavcodec/x86/h264_idct.asm | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index dde40e9..bc4dce4 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -87,10 +87,
1.04x faster (521±1.7 vs. 501±1.1 decicycles) compared with mmxext
---
libavcodec/x86/h264_idct.asm | 21 +
libavcodec/x86/h264dsp_init.c | 2 ++
2 files changed, 23 insertions(+)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index ca8ffdb..c4b6e55
1.01x faster (2150±46.1 vs. 2118±29.0 decicycles) compared with sse2
---
libavcodec/x86/h264_idct.asm | 40 +++-
libavcodec/x86/h264dsp_init.c | 2 ++
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/
---
libavcodec/x86/h264_idct.asm | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index c36fea5..878ff02 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -695,7 +695,7 @@ cglo
1.00x faster (2884±63.9 vs. 2880±21.1 decicycles) compared with sse2
---
libavcodec/x86/h264_idct.asm | 60 +++
libavcodec/x86/h264dsp_init.c | 2 ++
2 files changed, 62 insertions(+)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.as
1.20x faster (658±0.8 vs. 547±0.2 decicycles) compared with mmxext
---
libavcodec/x86/h264_idct.asm | 33 -
libavcodec/x86/h264dsp_init.c | 3 +++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idc
On Fri, Mar 17, 2017 at 01:59:40PM +0100, Hendrik Leppkes wrote:
> On Fri, Mar 17, 2017 at 12:32 AM, Michael Niedermayer
> wrote:
> > On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas George wrote:
> >> Le sextidi 26 ventôse, an CCXXV, Michael Niedermayer a écrit :
> >> > Applications which depend
On Fri, Mar 17, 2017 at 01:45:40PM +0100, wm4 wrote:
> On Fri, 17 Mar 2017 13:32:40 +0100
> Michael Niedermayer wrote:
>
> > On Fri, Mar 17, 2017 at 11:48:18AM +0100, Nicolas George wrote:
> > > Le septidi 27 ventôse, an CCXXV, Michael Niedermayer a écrit :
> > > > Is this possible for every ap
On Fri, Mar 17, 2017 at 12:32 AM, Michael Niedermayer
wrote:
> On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas George wrote:
>> Le sextidi 26 ventôse, an CCXXV, Michael Niedermayer a écrit :
>> > Applications which depend on the current default would need
>>
>> ... to implement a correct structu
On Fri, 17 Mar 2017 13:32:40 +0100
Michael Niedermayer wrote:
> On Fri, Mar 17, 2017 at 11:48:18AM +0100, Nicolas George wrote:
> > Le septidi 27 ventôse, an CCXXV, Michael Niedermayer a écrit :
> > > Is this possible for every application using every framework ?
> >
> > Probably not. Not ou
On Fri, Mar 17, 2017 at 11:48:18AM +0100, Nicolas George wrote:
> Le septidi 27 ventôse, an CCXXV, Michael Niedermayer a écrit :
> > Is this possible for every application using every framework ?
>
> Probably not. Not our problem.
If your users problems are not your problem than you have the wron
On 11.03.2017 16:28, Michael Niedermayer wrote:
On Tue, Mar 07, 2017 at 03:39:18PM +0100, Tobias Rapp wrote:
Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.
Adds an internal helper function for bi
On 14.03.2017 13:43, Tobias Rapp wrote:
On 11.03.2017 16:07, Michael Niedermayer wrote:
On Tue, Mar 07, 2017 at 03:39:17PM +0100, Tobias Rapp wrote:
From: Anton Khirnov
(cherry picked from Libav commit
d10102d23c9467d4eb84f58e0cd12be284b982f6)
Signed-off-by: Tobias Rapp
---
ffmpeg.c | 2 ++
Am 17.03.2017 um 05:59 schrieb Konda Raju:
> Adding subject line.
>
> Thanks and regards,
> Konda Raju
>
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Konda Raju
> Sent: Friday, March 17, 2017 9:56 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc:
Le septidi 27 ventôse, an CCXXV, Michael Niedermayer a écrit :
> Is this possible for every application using every framework ?
Probably not. Not our problem.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
45 matches
Mail list logo