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(+)
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 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
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 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 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 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 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 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:
>
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
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
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
---
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
* 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
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
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
---
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: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
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 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
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 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 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 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 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: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 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 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 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
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
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 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 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
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
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
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/
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?
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
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
>
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
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
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
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
---
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 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
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
---
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 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: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 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
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
---
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
---
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
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
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 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..
>
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.
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
---
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
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
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 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: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
---
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 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
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 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
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
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 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
>> 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 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
---
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 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
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 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/
---
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 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
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 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 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 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 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
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
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
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
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
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
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
---
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
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
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;
>
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
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
95 matches
Mail list logo
