Patch ok
Mickael
Le mercredi 20 août 2014, James Almer a écrit :
> ~15% faster than sse2
>
> Signed-off-by: James Almer >
> ---
> libavcodec/x86/hevc_res_add.asm | 15 +++
> libavcodec/x86/hevcdsp.h| 4
> libavcodec/x86/hevcdsp_init.c | 4
> 3 files changed, 1
Ok.
Mickael
Le mercredi 20 août 2014, Timothy Gu a écrit :
> On Tue, Aug 19, 2014 at 6:49 PM, Michael Niedermayer > wrote:
> > Fixes memleak
> > Fixes CID1231989
> >
> > Signed-off-by: Michael Niedermayer >
> > ---
> > libavcodec/hevc_ps.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 de
Hi,
2014-08-20 4:55 GMT+02:00 James Almer :
> ~15% faster than sse2
[...]
> @@ -509,7 +509,11 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int
> bit_depth)
> if (ARCH_X86_64) {
> c->hevc_v_loop_filter_luma =
> ff_hevc_v_loop_filter_luma_8_avx;
>
hi,
attached patch fix input stream detection by Icecast that do not
understand chunked http input.
--
Maksym Veremeyenko
>From e733ea6b31d341d2850070e378c2c841ebec0e35 Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko
Date: Wed, 20 Aug 2014 12:15:14
Depending on the input and/or filters, you sometime have an input or
output pixel format like "rgb48le(12 bpc)". Unfortunately, most often,
the 12 bpc information is ignored or stripped. This patchset modify
some such cases, at the cost of increasing risks as patches go.
0001 is an actual bugfix t
It was added per pixel instead of per line.
---
libavcodec/dpxenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index 059d8c6..aca745b 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -159,11 +159,11 @@ static void
When input had 12 bits, it was invariably treated as packed RGB
with 12 bits per component.
---
libavcodec/dpxenc.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index aca745b..d02684b 100644
---
pnmdec currently respects the consign of rgb48 content. Instead, do not rescale
and make the bits_per_raw_sample valid and useful.
---
libavcodec/pnmdec.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
index c84b6eb..36bdfe7 100644
--- a/libavcod
This allows writing actual bitdepth in RGB48 when it isn't actually 16.
---
libavcodec/pnmenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/pnmenc.c b/libavcodec/pnmenc.c
index e6c3635..9198ddb 100644
--- a/libavcodec/pnmenc.c
+++ b/libavcodec/pnmenc.c
@@ -84,6 +84,8 @@ static
Thanks to av_get_pix_fmt_loss, we can determine more precisely if a
conversion will incur some kind of loss. If this loss doesn't modify
in particular bitdepth, the input bitdepth can be reused for the
output.
---
ffmpeg.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/ffmpeg.c b/ffm
Hi,
2014-08-20 10:10 GMT+02:00 Christophe Gisquet :
> +if (!(av_get_pix_fmt_loss(enc_ctx->pix_fmt,
> dec_ctx->pix_fmt, 0)
> + & (FF_LOSS_DEPTH|FF_LOSS_COLORSPACE|FF_LOSS_CHROMA))) {
If it was ever useful, this is probably wrong and should rather use
AVPixFmtD
Hi,
2014-08-20 10:10 GMT+02:00 Christophe Gisquet :
> One may argue that a proper solution is to reduce as often as possible
> references to bits_per_raw_sample and, instead, always use the
> colorspace information and to introduce new colorspaces as needed.
I'd prefer this solution although it's
On 08/19/2014 12:45 PM, Clément Bœsch wrote:
> See:
> http://fate.ffmpeg.org/
> http://coverage.ffmpeg.org/
The 2nd link to "coverage" (which should show the LCOV output, I guess)
seems to be broken:
I get a "404 Not Found" :(
Regards,
Pb
___
ffmpeg-dev
On 8/19/14, Clement Boesch wrote:
> From: Clement Boesch
>
> ---
> doc/filters.texi| 3 +++
> libavfilter/avf_showwaves.c | 14 ++
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg
On 8/19/14, Clement Boesch wrote:
> From: Clement Boesch
>
> ---
> libavfilter/avf_showwaves.c | 119
> +++-
> 1 file changed, 74 insertions(+), 45 deletions(-)
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@
On 2014-08-20 10:10, Christophe Gisquet wrote:
> It was added per pixel instead of per line.
> ---
> libavcodec/dpxenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
> index 059d8c6..aca745b 100644
> --- a/libavcodec/dpxenc
On Wed, Aug 20, 2014 at 11:05:05AM +0200, Peter B. wrote:
> On 08/19/2014 12:45 PM, Clément Bœsch wrote:
> > See:
> > http://fate.ffmpeg.org/
> > http://coverage.ffmpeg.org/
>
> The 2nd link to "coverage" (which should show the LCOV output, I guess)
> seems to be broken:
> I get a "404 Not Found"
On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote:
>
>
> Von meinem iPhone gesendet
>
> > Am 20.08.2014 um 03:16 schrieb Michael Niedermayer :
> >
> >> On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote:
> >> Hello,
> >>
> >> As a follow-up to my last patch I now fac
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 11:47 AM, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote:
>>
>>
>> Von meinem iPhone gesendet
>>
>>> Am 20.08.2014 um 03:16 schrieb Michael Niedermayer :
>>>
On Wed, Aug
On date Monday 2014-08-18 09:25:10 -0700, Timothy Gu encoded:
> On Mon, Aug 18, 2014 at 5:53 AM, Stefano Sabatini wrote:
> > ---
> > doc/filters.texi | 47 +--
> > 1 file changed, 45 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/filters.texi b/
Hi,
the goal is to have av_dlog output something for the recompiled files.
How are you doing it? I edit config.mak but when eg rebasing and
recompiling, this may cause a lot of files to have av_dlog active and
cause massive spamage.
If it's not easy, could it be something like:
rm
make MY_FFMPE
On Wed, Aug 20, 2014 at 11:54:08AM +0200, Daniel Oberhoff wrote:
>
> ---
> Daniel Oberhoff
> daniel.oberh...@gmail.com
>
>
>
> On Aug 20, 2014, at 11:47 AM, Michael Niedermayer wrote:
>
> > On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote:
> >>
> >>
> >> Von meinem iPhone
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 12:15 PM, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 11:54:08AM +0200, Daniel Oberhoff wrote:
>>
>> ---
>> Daniel Oberhoff
>> daniel.oberh...@gmail.com
>>
>>
>>
>> On Aug 20, 2014, at 11:47 AM, Michael Niederm
On Wed, Aug 20, 2014 at 10:16:25AM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-20 10:10 GMT+02:00 Christophe Gisquet :
> > One may argue that a proper solution is to reduce as often as possible
> > references to bits_per_raw_sample and, instead, always use the
> > colorspace information and
>> of course if someone wants to use the filter as a quick correction
>> for a random video downloaded somewhere thats likely in YUV space
>
> For me going to YUV made everyting around 4x faster..
And this is not for “random downloads” but a complete real-time video
broadcast/archival solution
On Wed, Aug 20, 2014 at 12:07:10PM +0200, Christophe Gisquet wrote:
> Hi,
>
> the goal is to have av_dlog output something for the recompiled files.
> How are you doing it? I edit config.mak but when eg rebasing and
> recompiling, this may cause a lot of files to have av_dlog active and
> cause ma
Hi,
2014-08-20 12:25 GMT+02:00 Michael Niedermayer :
> iam probably missing something but why not add
> #define DEBUG 1
> to the specific file or header for which to enable av_dlog() ?
That's a possibility, but an example is working on aac, where you need
to do this on around 4 files.
Having them
On date Tuesday 2014-08-19 01:29:42 +0200, Michael Niedermayer encoded:
> On Mon, Aug 18, 2014 at 02:53:45PM +0200, Stefano Sabatini wrote:
> > ---
> > libavfilter/af_apad.c | 29 +
> > 1 file changed, 17 insertions(+), 12 deletions(-)
>
> probably ok
With more change
On date Monday 2014-08-18 14:53:52 +0200, Stefano Sabatini encoded:
> ---
> doc/filters.texi | 47 +--
> 1 file changed, 45 insertions(+), 2 deletions(-)
Up.
--
FFmpeg = Fundamentalist & Fiendish Mega Powered Encoding/decoding Gorilla
>From 17eecedf1bc
Hi,
2014-08-20 12:19 GMT+02:00 Michael Niedermayer :
> iam happy with either, just please dont do and post both solutions
> as then i cannot apply either as i have to expect libav to apply
> the other causing conflicts
To summarize without aggravating anyone: I don't think I can manage
both proje
On Wed, Aug 20, 2014 at 12:20:06PM +0200, Daniel Oberhoff wrote:
>
> ---
> Daniel Oberhoff
> daniel.oberh...@gmail.com
>
>
>
> On Aug 20, 2014, at 12:15 PM, Michael Niedermayer wrote:
>
> > On Wed, Aug 20, 2014 at 11:54:08AM +0200, Daniel Oberhoff wrote:
> >>
> >> ---
> >> Daniel Oberhoff
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 12:51 PM, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 12:20:06PM +0200, Daniel Oberhoff wrote:
>>
>> ---
>> Daniel Oberhoff
>> daniel.oberh...@gmail.com
>>
>>
>>
>> On Aug 20, 2014, at 12:15 PM, Michael Niederm
On date Tuesday 2014-08-19 14:47:02 +0200, Clément Bœsch encoded:
> From: Clément Bœsch
>
> ---
> doc/filters.texi| 3 +++
> libavfilter/avf_showwaves.c | 24 +++-
> 2 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filter
On date Tuesday 2014-08-19 14:47:03 +0200, Clément Bœsch encoded:
> From: Clément Bœsch
>
> ---
> libavfilter/avf_showwaves.c | 119
> +++-
> 1 file changed, 74 insertions(+), 45 deletions(-)
[...]
LGTM as well.
--
FFmpeg = Freak and Fancy Monstrous Pow
On date Tuesday 2014-08-19 14:47:04 +0200, Clément Bœsch encoded:
> From: Clément Bœsch
>
> ---
> doc/filters.texi| 3 +++
> libavfilter/avf_showwaves.c | 14 ++
> 2 files changed, 13 insertions(+), 4 deletions(-)
LGTM, thanks.
(Please bump micro when pushing).
--
FFm
On date Monday 2014-08-18 18:03:39 +0200, Clément Bœsch encoded:
> From: Clément Bœsch
>
> ---
> Note: I didn't use FF_API_DEBUG_MV because it seems to overlap with all
> kind of other things and I couldn't test properly the conditional
> compilation.
>
> BTW, I could add a FATE test easily, but
---
libavfilter/vf_lenscorrection.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c
index f4b1676..048820c 100644
--- a/libavfilter/vf_lenscorrection.c
+++ b/libavfilter/vf_lenscorrec
there are some still left for 1 time initialization
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_lenscorrection.c | 45 ---
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrecti
The only remaining floats are in the user interface, they are left as they
should not cause a problem in practice
---
libavfilter/vf_lenscorrection.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.
On Wed, Aug 20, 2014 at 01:00:29PM +0200, Daniel Oberhoff wrote:
[...]
> >
> >
> >>
> >>> of course if someone wants to use the filter as a quick correction
> >>> for a random video downloaded somewhere thats likely in YUV space
> >>
> >> For me going to YUV made everyting around 4x faster..
>
So we prefer int64_t above float32? I assumed we stick with 32bits for
calculations. Did you test this with very large resolutions? I so
congratulation :). I am glad I could push you to finish what I failed to do :).
As I would still like to have interpolation, I assume I shall refactor the
int
On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote:
> So we prefer int64_t above float32?
well, its not exactly making me happy either but its just 2 32x32->64
operations per pixel which shouldnt be that bad when we need to do
16 multiplications for bicubic per sample
also at the exp
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 2:33 PM, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote:
>> So we prefer int64_t above float32?
>
> well, its not exactly making me happy either but its just 2 32x32->64
> opera
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 2:17 PM, Michael Niedermayer wrote:
> The only remaining floats are in the user interface, they are left as they
> should not cause a problem in practice
> ---
> libavfilter/vf_lenscorrection.c | 13 +++--
> 1 file
On Wed, Aug 20, 2014 at 02:42:35PM +0200, Daniel Oberhoff wrote:
>
> ---
> Daniel Oberhoff
> daniel.oberh...@gmail.com
>
>
>
> On Aug 20, 2014, at 2:17 PM, Michael Niedermayer wrote:
>
> > The only remaining floats are in the user interface, they are left as they
> > should not cause a pro
On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote:
>
> ---
> Daniel Oberhoff
> daniel.oberh...@gmail.com
>
>
>
> On Aug 20, 2014, at 2:33 PM, Michael Niedermayer wrote:
>
> > On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote:
> >> So we prefer int64_t above floa
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 2:54 PM, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 02:42:35PM +0200, Daniel Oberhoff wrote:
>>
>> ---
>> Daniel Oberhoff
>> daniel.oberh...@gmail.com
>>
>>
>>
>> On Aug 20, 2014, at 2:17 PM, Michael Niedermay
On Wed, Aug 20, 2014 at 09:26:56AM +0200, Mickaël Raulet wrote:
> Ok.
>
> Mickael
>
> Le mercredi 20 août 2014, Timothy Gu a écrit :
>
> > On Tue, Aug 19, 2014 at 6:49 PM, Michael Niedermayer > > wrote:
> > > Fixes memleak
> > > Fixes CID1231989
> > >
> > > Signed-off-by: Michael Niedermayer >
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 2:55 PM, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote:
>>
>> ---
>> Daniel Oberhoff
>> daniel.oberh...@gmail.com
>>
>>
>>
>> On Aug 20, 2014, at 2:33 PM, Michael Niedermay
On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote:
>
> ---
> Daniel Oberhoff
> daniel.oberh...@gmail.com
>
>
>
> On Aug 20, 2014, at 2:55 PM, Michael Niedermayer wrote:
>
> > On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote:
> >>
> >> ---
> >> Daniel Oberhoff
On Wed, Aug 20, 2014 at 12:43:22PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2014-08-19 01:29:42 +0200, Michael Niedermayer encoded:
> > On Mon, Aug 18, 2014 at 02:53:45PM +0200, Stefano Sabatini wrote:
> > > ---
> > > libavfilter/af_apad.c | 29 +
> > > 1 file c
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 3:11 PM, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote:
>>
>> ---
>> Daniel Oberhoff
>> daniel.oberh...@gmail.com
>>
>>
>>
>> On Aug 20, 2014, at 2:55 PM, Michael Niedermay
On Wed, Aug 20, 2014 at 03:48:39PM +0200, Daniel Oberhoff wrote:
>
> ---
> Daniel Oberhoff
> daniel.oberh...@gmail.com
>
>
>
> On Aug 20, 2014, at 3:11 PM, Michael Niedermayer wrote:
>
> > On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote:
> >>
> >> ---
> >> Daniel Oberhoff
On 20/08/14 4:29 AM, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-20 4:55 GMT+02:00 James Almer :
>> ~15% faster than sse2
> [...]
>> @@ -509,7 +509,11 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int
>> bit_depth)
>> if (ARCH_X86_64) {
>> c->hevc_v_loop_filt
Fixes CID1231992
Suggested-by: Timothy Gu
Signed-off-by: Michael Niedermayer
---
libavformat/matroskaenc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 7123ec6..98fe4af 100644
--- a/libavformat/matroskaenc
From: Marc-Antoine Arnaud
---
libavformat/utils.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index b4ca342..738d1f0 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2280,6 +2280,13 @@ static void
estimate_timings_from_bi
On Tue, Jun 17, 2014 at 11:05:39PM +0200, Clément Bœsch wrote:
> ---
> Changelog | 2 ++
> configure | 4 +---
> doc/encoders.texi | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index 40a7751..268205c 100644
> --- a/Changelog
>
Marc-Antoine Arnaud arkena.com> writes:
> +if (st->codec->rc_max_rate > 0) {
> +if (INT_MAX - st->codec->rc_max_rate < bit_rate) {
> +bit_rate = 0;
> +break;
> +}
> +bit_rate += st->codec->rc_max_r
Christophe Gisquet gmail.com> writes:
> Depending on the input and/or filters, you sometime
> have an input or output pixel format like "rgb48le(12
> bpc)". Unfortunately, most often, the 12 bpc
> information is ignored or stripped.
Could you explain what command line you are trying
to fix?
Fixes bitrate detection in CBR mpeg2
Fixes ticket3678
---
libavcodec/mpegvideo_parser.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 7aa3660..44bf26d 100644
--- a/libavcodec/mpegvideo_parser.c
+++ b/
On Wed, Aug 20, 2014 at 03:37:58PM +0200, Marc-Antoine Arnaud wrote:
> From: Marc-Antoine Arnaud
>
> ---
> libavformat/utils.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index b4ca342..738d1f0 100644
> --- a/libavformat/utils.c
On Tue, 19 Aug 2014 16:40:21 -0700, Timothy Gu wrote:
> OK, of course.
Thanks. Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi Carl,
Yes I test with the attached file.
The case is when the input video stream is in Mpeg2, the bitrate of the
stream was setup in rc_max_rate, not in bitrate
[https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpeg12dec.c#L1284].
For the remark you mean I can add an "else if (st->codec
Hi Michael,
I agreed how we can take the information in the wrapper if it's present. In
MXF case it can be done. But in other formats, this information is not
necessary present ...
The other possibility is to set the duration to -1 to disable print when we
can't known exactly the duration.
__
Hi,
2014-08-20 17:36 GMT+02:00 James Almer :
>> Does avx => ARCH_X86_64 (didn't know) ? Otherwise the reg count seems
>> fine, meaning the condition is unneeded.
>
> No, AVX does not imply x86_64. The reg count for these is currently 12 xmm
> regs,
> meaning x86_64 only.
> I'll send a patch to ge
Hi,
2014-08-20 20:26 GMT+02:00 Carl Eugen Hoyos :
> Christophe Gisquet gmail.com> writes:
>
>> Depending on the input and/or filters, you sometime
>> have an input or output pixel format like "rgb48le(12
>> bpc)". Unfortunately, most often, the 12 bpc
>> information is ignored or stripped.
>
> Co
On Sat, Aug 16, 2014 at 03:27:17PM +0200, Clément Bœsch wrote:
> On Fri, Aug 15, 2014 at 06:49:39AM +, Carl Eugen Hoyos wrote:
> [...]
> > > But really that's insane, because I know you will
> > > end-up hardcoding all kind of linker flags to
> > > these fallback calls,
> >
> > Yes, some ext
On 20/08/14 4:25 AM, Mickaël Raulet wrote:
> Patch ok
>
> Mickael
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 20/08/14 4:11 PM, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-20 17:36 GMT+02:00 James Almer :
>>> Does avx => ARCH_X86_64 (didn't know) ? Otherwise the reg count seems
>>> fine, meaning the condition is unneeded.
>>
>> No, AVX does not imply x86_64. The reg count for these is currently 12 xmm
On Wed, Aug 20, 2014 at 11:28:40AM +0200, Paul B Mahol wrote:
> On 8/19/14, Clement Boesch wrote:
> > From: Clement Boesch
> >
> > ---
> > libavfilter/avf_showwaves.c | 119
> > +++-
> > 1 file changed, 74 insertions(+), 45 deletions(-)
> >
>
> lgtm
Appl
On Wed, Aug 20, 2014 at 01:02:21PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2014-08-19 14:47:02 +0200, Clément Bœsch encoded:
> > From: Clément Bœsch
> >
> > ---
> > doc/filters.texi| 3 +++
> > libavfilter/avf_showwaves.c | 24 +++-
> > 2 files changed,
On Wed, Aug 20, 2014 at 11:27:23AM +0200, Paul B Mahol wrote:
> On 8/19/14, Clement Boesch wrote:
> > From: Clement Boesch
> >
> > ---
> > doc/filters.texi| 3 +++
> > libavfilter/avf_showwaves.c | 14 ++
> > 2 files changed, 13 insertions(+), 4 deletions(-)
> >
>
> lgt
On Wed, Aug 20, 2014 at 08:52:09PM +0200, Marc-Antoine ARNAUD wrote:
> Hi Michael,
>
>
> I agreed how we can take the information in the wrapper if it's present. In
> MXF case it can be done. But in other formats, this information is not
> necessary present ...
yes, and thus it cannot be done r
On Tue, 2014-08-19 at 07:44 -0600, Roger Pack wrote:
> OK I was able to reproduce the problem.
> Patch looks good, see attached, FWIW.
> Thanks!
> -roger-
I suppose this was probably my fault originally; it was my first time
programming the win32 api. ;)
Thanks for the fix.
--
Calvin Walton
On Wed, Aug 20, 2014 at 07:10:56AM +0700, Muhammad Faiz wrote:
[...]
> +static double r_func(void *p, double x)
> +{
> +x = av_clipd(x, 0.0, 1.0);
> +return (int)(x*255.0+0.5) << 16;
You can probably use lrint() here:
return lrint(av_clipd(x, 0.0, 1.0) * 255.0) << 16;
[...]
> +av_
On Mon, Aug 18, 2014 at 06:03:39PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> Note: I didn't use FF_API_DEBUG_MV because it seems to overlap with all
> kind of other things and I couldn't test properly the conditional
> compilation.
>
> BTW, I could add a FATE test easily, but
From: Clément Bœsch
The reasoning behind this addition is that various third party
applications are interested in getting some motion information out of a
video "for free" when it is available.
It was considered to export other information as well (such as the intra
information about the block,
On Wed, Aug 20, 2014 at 11:28:42PM +0200, Clément Bœsch wrote:
[...]
I'm tired. Please ignore. Sorry for the noise.
--
Clément B.
pgp3CzeayEKnJ.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mai
---
doc/APIchanges| 2 +-
libavutil/motion_vector.h | 8
libavutil/version.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 1bed107..1fbeb09 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,7 +15,7 @@ l
On Wed, Aug 20, 2014 at 11:30:27PM +0200, Clément Bœsch wrote:
> ---
> doc/APIchanges| 2 +-
> libavutil/motion_vector.h | 8
> libavutil/version.h | 2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 1bed10
On Wed, Aug 20, 2014 at 02:03:13AM +0200, Michael Niedermayer wrote:
patchset applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signa
* Reduced xmm register count to 7 (As such they are now enabled for x86_32).
* Removed four movdqa (affects the sse2 version only).
* pxor is now used to clear m0 only once.
~5% faster.
Signed-off-by: James Almer
---
libavcodec/x86/hevc_res_add.asm | 122
---
tests/fate/vcodec.mak| 4 +++-
tests/ref/vsynth/vsynth1-huffyuvbgra | 4
tests/ref/vsynth/vsynth2-huffyuvbgra | 4
tests/ref/vsynth/vsynth3-huffyuvbgra | 4
4 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/vsynth/vsynth1-huffyuvbgra
Commit deadcf5e broke it, and fate didn't catch it.
Christophe Gisquet (2):
fate: add test for old (v1) huffyuv and rgba
huffyuvdec: fix old (v1) rgba
libavcodec/huffyuvdec.c | 17 -
tests/fate/vcodec.mak| 4 +++-
tests/ref/vsynth/vsynth1-huffyuv
Commit deadcf5e misplaced a hunk.
Fixes ticket #3877.
---
libavcodec/huffyuvdec.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index e4e5ea0..bc5ad15 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/hu
Hi,
ticket #3872 is about a regression on decoding of hevc:
https://trac.ffmpeg.org/ticket/3872
The reason is a stricter validation is now performed since 5ec85c97.
The sequence seems invalid to me, as it seems the SPS was truncated or
corrupted somewhere in the VUI. But if we ignore the a prior
On Thu, Aug 21, 2014 at 3:49 AM, Clément Bœsch wrote:
> On Wed, Aug 20, 2014 at 07:10:56AM +0700, Muhammad Faiz wrote:
> [...]
> > +static double r_func(void *p, double x)
> > +{
> > +x = av_clipd(x, 0.0, 1.0);
> > +return (int)(x*255.0+0.5) << 16;
>
> You can probably use lrint() here:
>
On Wed, Aug 20, 2014 at 11:19:48PM +, Christophe Gisquet wrote:
> Commit deadcf5e misplaced a hunk.
>
> Fixes ticket #3877.
> ---
> libavcodec/huffyuvdec.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2
On Wed, Aug 20, 2014 at 11:19:47PM +, Christophe Gisquet wrote:
> ---
> tests/fate/vcodec.mak| 4 +++-
> tests/ref/vsynth/vsynth1-huffyuvbgra | 4
> tests/ref/vsynth/vsynth2-huffyuvbgra | 4
> tests/ref/vsynth/vsynth3-huffyuvbgra | 4
> 4 files changed, 15 insert
On Thu, 14 Aug 2014 13:58:07 +0200
Stefano Sabatini wrote:
> > If you trully want to mend ways, then you and your fellow FFmpeg
> > developers should stop this constant spreading of lies, this
> > defamation campaing against libav and its developers that has
> > been going on for the last 3 and a
On Thu, Aug 21, 2014 at 02:06:39AM +0200, Christophe Gisquet wrote:
> Hi,
>
> ticket #3872 is about a regression on decoding of hevc:
> https://trac.ffmpeg.org/ticket/3872
>
> The reason is a stricter validation is now performed since 5ec85c97.
>
> The sequence seems invalid to me, as it seems t
On Sat, 16 Aug 2014 17:11:29 +0200
Nicolas George wrote:
> The most galling in this issue is that there is no clear decision behind
> this orientation. The fork's manifesto stated that everyone was equal
> amongst equals, with or without commit rights, but the people who do have
> the commit righ
On Mon, 18 Aug 2014 13:42:36 +0200
Nicolas George wrote:
> The reason for switching from FFmpeg to libav in the first place just after
> the fork is much simpler than that.
Yes, the reason was that Reinhard, who was the maintainer of the
ffmpeg package back then, was on the libav side after the
Hi Attila,
I will do a small self-intro, as you most likely don't know me: I am a
high school student who mainly writes documentation for FFmpeg, but
sometimes do small code fixes and patch review (mainly related to
documentation), both for FFmpeg and Libav. I sent my first patch to
FFmpeg last ye
On Thu, Aug 21, 2014 at 12:01:51AM +0200, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 11:30:27PM +0200, Clément Bœsch wrote:
> > ---
> > doc/APIchanges| 2 +-
> > libavutil/motion_vector.h | 8
> > libavutil/version.h | 2 +-
> > 3 files changed, 6 insertions(+)
95 matches
Mail list logo
