On 24.08.2014, at 14:02, Christophe Gisquet
wrote:
> Hi,
>
> I think a first point must be cleared, seeing your reaction to my
> pnmdec comment. Here' are the opinions:
> - Mine: bits_per_raw_sample should indicate the dynamics of the signal
> when it is different from the colorspace bitdepth
>
Hello,
On Sun, Aug 24, 2014 at 9:39 PM, Clément Bœsch wrote:
>> $ make fate-pixelutils
>> TESTpixelutils
>> --- ./tests/ref/fate/pixelutils 2014-08-24 12:18:09.0 +0200
>> +++ tests/data/fate/pixelutils 2014-08-24 14:20:02.0 +0200
>> @@ -1,7 +1,7 @@
>> [OK] [UU] SAD [random]
On Sun, Aug 24, 2014 at 12:21:38PM +, Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
> > +OBJS-$(CONFIG_PIXELUTILS) += ppc/pixelutils_init.o
> > +
> > ALTIVEC-OBJS += ppc/float_dsp_altivec.o \
> > +ALTIVEC-OBJS-$(CONFIG_PIXELUTILS) += ppc/pixelutils
On Wed, Aug 20, 2014 at 06:47:02PM +0200, Michael Niedermayer wrote:
> Fixes CID1231992
>
> Suggested-by: Timothy Gu
> Signed-off-by: Michael Niedermayer
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place
On Sun, Aug 24, 2014 at 07:37:59PM +0200, Clément Bœsch wrote:
> On Wed, Aug 13, 2014 at 02:11:26PM -0300, James Almer wrote:
> > On 13/08/14 1:52 PM, Reimar Döffinger wrote:
> > > On 13.08.2014, at 12:48, "Ronald S. Bultje" wrote:
> > >>
> > >>>
> > >>> Might it be useful to add some of those spe
On Sun, 24 Aug 2014 19:35:28 +0200
Michael Niedermayer wrote:
> On Sun, Aug 24, 2014 at 02:54:19PM +0200, wm4 wrote:
> > On Sun, 24 Aug 2014 00:28:56 +0200
> > Clément Bœsch wrote:
> >
> > > Hi,
> > >
> > > Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list
> > > between t
Ported from avresample
Code by: Mans Rullgard, Janne Grunau, Martin Storsjo
Signed-off-by: Michael Niedermayer
---
libswresample/aarch64/Makefile |5 +
libswresample/aarch64/audio_convert_init.c | 67 +
libswresample/aarch64/audio_convert_neon.S | 363
On Wed, Aug 13, 2014 at 02:11:26PM -0300, James Almer wrote:
> On 13/08/14 1:52 PM, Reimar Döffinger wrote:
> > On 13.08.2014, at 12:48, "Ronald S. Bultje" wrote:
> >>
> >>>
> >>> Might it be useful to add some of those special samples to fate?
> >>
> >>
> >> Probably. The first 10 frames of the s
On Sun, Aug 24, 2014 at 02:54:19PM +0200, wm4 wrote:
> On Sun, 24 Aug 2014 00:28:56 +0200
> Clément Bœsch wrote:
>
> > Hi,
> >
> > Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list
> > between the two projects to start communicating again in sane terms.
> >
> > The proposi
On Sat, Aug 23, 2014 at 08:59:41PM +0800, Hii wrote:
> Currently -b_qfactor and -chromaoffset have no effect in libx264,
> the attached patch is an attempt to fix the issue.
>
> Move the corresponding lines after x264_param_default_preset() to
> prevent them being overwritten by it, make the two p
On Sun, 24 Aug 2014 08:57:04 -0800
Lou Logan wrote:
> On Sat, Aug 23, 2014, at 02:28 PM, Clément Bœsch wrote:
> > On the technical side, we potentially need a neutral party to setup
> > such mailing-list. Is anyone willing to do that?
>
> The neutral party should also be willing to regularly par
On Sat, Aug 23, 2014, at 02:28 PM, Clément Bœsch wrote:
> On the technical side, we potentially need a neutral party to setup such
> mailing-list. Is anyone willing to do that?
The neutral party should also be willing to regularly parse the pending
moderator requests for valid messages from unsubs
On Mon, Aug 18, 2014 at 07:26:32PM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-18 13:40 GMT+02:00 Carl Eugen Hoyos :
> > Christophe Gisquet gmail.com> writes:
> > If a profile was set, the automatic setting should
> > probably not overwrite it.
> > (If this is possible.)
> >
> > But I cons
On Wed, Aug 20, 2014 at 01:37:23PM +0200, Stefano Sabatini wrote:
[...]
> > -{"vismv", "visualize motion vectors (MVs)", OFFSET(debug_mv),
> > AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT }, 0, INT_MAX, V|D, "debug_mv"},
> > +#if FF_API_VISMV
> > +{"vismv", "visualize motion vectors (MVs) (deprecated)", OFF
On Wed, Aug 20, 2014 at 10:54:55PM +0200, Michael Niedermayer wrote:
> 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 proper
On Sun, 24 Aug 2014 00:28:56 +0200
Clément Bœsch wrote:
> Hi,
>
> Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list
> between the two projects to start communicating again in sane terms.
>
> The proposition would be a mailing-list where the 2 projects would send
> the patc
Clément Bœsch pkh.me> writes:
> +OBJS-$(CONFIG_PIXELUTILS) += ppc/pixelutils_init.o
> +
> ALTIVEC-OBJS += ppc/float_dsp_altivec.o \
> +ALTIVEC-OBJS-$(CONFIG_PIXELUTILS) += ppc/pixelutils_altivec.o \
Something is wrong here, I suspect the "\" have
to be
Christophe Gisquet gmail.com> writes:
> - ffmpeg's and yours (if I'm not mistaken): the signal
> bitdepth should always match the colorspace one, and
> bits_per_raw_sample should indicate the original bitdepth
I believe that my opinion is mostly irrelevant
but that FFmpeg's opinion is the onl
Hi,
I think a first point must be cleared, seeing your reaction to my
pnmdec comment. Here' are the opinions:
- Mine: bits_per_raw_sample should indicate the dynamics of the signal
when it is different from the colorspace bitdepth
- ffmpeg's and yours (if I'm not mistaken): the signal bitdepth sho
On Sun, Aug 24, 2014 at 01:29:50PM +0200, Thilo Borgmann wrote:
> Am 24.08.14 00:23, schrieb Michael Niedermayer:
> > On Sat, Aug 23, 2014 at 09:24:33PM +0200, Clément Bœsch wrote:
> >> --- This is 100% untested and probably doesn't even compile.
> >
> > it does compile, but i dont have a ppc so i
Am 24.08.14 00:23, schrieb Michael Niedermayer:
> On Sat, Aug 23, 2014 at 09:24:33PM +0200, Clément Bœsch wrote:
>> --- This is 100% untested and probably doesn't even compile.
>
> it does compile, but i dont have a ppc so i cant say if it would work
I can test that later today.
'make test' is w
Christophe Gisquet gmail.com> writes:
>
> Hi,
>
> 2014-08-24 12:48 GMT+02:00 Carl Eugen Hoyos ag.or.at>:
> >> I think "[PATCH 2/5] pnmenc: use bits_per_raw_sample"
> >> is wrong then
> >
> > Definitely, I still wonder how you tested it.
>
> ljpeg 36bits from #2966 and having the actual
> bit
On Sun, Jul 20, 2014 at 02:22:37PM -0700, Timothy Gu wrote:
> Signed-off-by: Timothy Gu
> ---
> README| 12 +---
> generate-doc.sh | 41 +
> src/template_doctitle | 1 -
> 3 files changed, 42 insertions(+), 12 deletions(-)
>
Hi,
2014-08-24 12:48 GMT+02:00 Carl Eugen Hoyos :
>> I think "[PATCH 2/5] pnmenc: use bits_per_raw_sample"
>> is wrong then
>
> Definitely, I still wonder how you tested it.
ljpeg 36bits from #2966 and having the actual bits_per_raw_sample value
What this situation underlines is that bits_per_ra
Carl Eugen Hoyos ag.or.at> writes:
> Attached patch fixes pnm encoding for me if
> bits_per_raw_sample is set to a value different
> from the pix_fmt's native value.
I should have mentioned that this was planned as
a [RFC] since I am not completely convinced we
want this but current git head
Christophe Gisquet gmail.com> writes:
> Otherwise, this shift would undo scaling performed
> elsewhere or actually remove bits from the actual
> value, which would be incorrect.
It would undo the shift done in the decoder because we
(luckily!!) do not have PIX_FMT_RGB12 and PIX_FMT_GRAY12
(a
Christophe Gisquet gmail.com> writes:
> > -if( avctx->bits_per_raw_sample )
> > +if ( avctx->bits_per_raw_sample
> > +&&
> > av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 > 7)
> > maxdepth = (1 << avctx->bits_per_raw_sample) - 1;
>
> So bit
Hi,
2014-08-24 12:13 GMT+02:00 Carl Eugen Hoyos :
[...]
> -if( avctx->bits_per_raw_sample )
> +if ( avctx->bits_per_raw_sample
> +&& av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 > 7)
> maxdepth = (1 << avctx->bits_per_raw_sample) - 1;
So bit
On Sun, Aug 24, 2014 at 08:46:32AM +, Christophe Gisquet wrote:
> ---
> libavcodec/x86/hevcdsp.h | 8 +++-
> libavcodec/x86/hevcdsp_init.c | 4 ++--
> 2 files changed, 5 insertions(+), 7 deletions(-)
this seems to break build for x86-32
libavcodec/x86/hevcdsp_init.c: In function ‘ff
Christophe Gisquet gmail.com> writes:
> The sanest thing to do (and that you are hinting at)
> is to just drop it.
I thought that 2/5 is not correct (but wasn't sure).
Patch sent, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
Hi!
Attached patch fixes pnm encoding for me if bits_per_raw_sample is set to a
value different from the pix_fmt's native value.
Please comment, Carl Eugen
diff --git a/libavcodec/pnmenc.c b/libavcodec/pnmenc.c
index 9198ddb..8f74459 100644
--- a/libavcodec/pnmenc.c
+++ b/libavcodec/pnmenc.c
@@
On Sun, Aug 24, 2014 at 08:46:30AM +, Christophe Gisquet wrote:
> In some cases, 2 or 3 calls are performed to functions for unusual
> widths. Instead, perform 2 calls for different widths to split the
> workload.
>
> The 8+16 and 4+8 widths for respectively 8 and more than 8 bits can't
> be p
On Sun, Aug 24, 2014 at 08:46:31AM +, Christophe Gisquet wrote:
> ---
> libavcodec/x86/hevc_mc.asm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fau
On Sun, Aug 24, 2014 at 10:16:37AM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-20 10:10 GMT+02:00 Christophe Gisquet :
> > This allows writing actual bitdepth in RGB48 when it isn't actually 16.
>
> irrespective of its patchset, I think this patch has merit, if
> bits_per_raw_sample is cor
*pel values below are decicyle timings, hevc* are object sizes
for Win64.
qpelepel hevc_mc hevcdsp_init
SSSE3: 68702 14469 116624 185388
SSE4: 65907 13811 121312 300996
Note: without 10 and 12bits, the object sizes are respectively:
hevc_mc hevcdsp_init
SS
---
libavcodec/x86/hevcdsp.h | 8 +++-
libavcodec/x86/hevcdsp_init.c | 4 ++--
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/libavcodec/x86/hevcdsp.h b/libavcodec/x86/hevcdsp.h
index 839e052..df49269 100644
--- a/libavcodec/x86/hevcdsp.h
+++ b/libavcodec/x86/hevcdsp.h
@@
In some cases, 2 or 3 calls are performed to functions for unusual
widths. Instead, perform 2 calls for different widths to split the
workload.
The 8+16 and 4+8 widths for respectively 8 and more than 8 bits can't
be processed that way without modifications: some calls use unaligned
buffers, and h
The only sse4 instruction is pextrw, which is used on rather minor
functions for small blocks. Therefore use whichever GPR is available
to extract the output word.
Before (sse4), for block_w == 6:
4627 decicycles in epel_uni, 16377 runs, 7 skips
7422 decicycles in epel_bi, 65501 runs, 35 skips
Af
---
libavcodec/x86/hevc_mc.asm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm
index e2236ec..9ce6bd1 100644
--- a/libavcodec/x86/hevc_mc.asm
+++ b/libavcodec/x86/hevc_mc.asm
@@ -890,7 +890,7 @@ cglobal hevc_put_hevc_uni_q
Since last iteration:
- PACKUSWD macro to support both sse4 and ssse3;
- Instanciate SSE4 functions for WP;
- Various side cleanups.
The first 3 patches I think don't have any caveat.
However, the last one shows that we have issues in the current code:
instead of having actual instances for every
Hi,
2014-08-20 10:10 GMT+02:00 Christophe Gisquet :
> This allows writing actual bitdepth in RGB48 when it isn't actually 16.
irrespective of its patchset, I think this patch has merit, if
bits_per_raw_sample is correct.
We are currently marking 12 bits as 16 bits, and when e.g. the decoder
read
Hi,
2014-08-24 3:00 GMT+02:00 Carl Eugen Hoyos :
> If you believe this is a real-world issue, is
> can easily be fixed afaict.
Let's summarize this patchset here: opportunities of doing lossless
processing are missed. But no user (as in real-world) actually has
expressed concern or interest beyon
On Sun, Aug 24, 2014 at 09:00:40AM +0200, Clément Bœsch wrote:
> On Sun, Aug 24, 2014 at 12:06:46AM +0100, JULIAN GARDNER wrote:
> [...]
> > I tried your suggestion of splitting the "-map [vid[0:a]" into "-map [vid]
> > -map [0:a] and I get the following error message
> >
> > Output with label '0
On Sun, Aug 24, 2014 at 12:06:46AM +0100, JULIAN GARDNER wrote:
[...]
> I tried your suggestion of splitting the "-map [vid[0:a]" into "-map [vid]
> -map [0:a] and I get the following error message
>
> Output with label '0:a' does not exist in any defined filter graph, or is
> already used elsew
44 matches
Mail list logo
