Christophe Gisquet gmail.com> writes:
> 2014-08-20 20:26 GMT+02:00 Carl Eugen Hoyos:
> > Christophe Gisquet 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
> >> inform
On Sat, Aug 23, 2014 at 11:57:04AM -0300, James Almer wrote:
> On 23/08/14 8:37 AM, Hendrik Leppkes wrote:
> > On Sat, Aug 23, 2014 at 1:31 PM, Michael Niedermayer
> > wrote:
> >> On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote:
> >>> Derived from deflate code.
> >>> Requires liblzma.
On Sun, Aug 24, 2014 at 01:16:16AM +0200, Carl Eugen Hoyos wrote:
> On Sunday 24 August 2014 12:50:14 am Michael Niedermayer wrote:
> > On Sat, Aug 23, 2014 at 02:02:49PM +0200, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > I don't think showing "-1094995529" or similar makes much sense.
> > > The
On Sun, Jul 20, 2014 at 02:23:07PM -0700, Timothy Gu wrote:
> texi2html is deprecated by upstream in favor of makeinfo/texi2any. See:
>
> - https://www.gnu.org/software/texinfo/manual/texinfo/html_node/texi2html.html
> - https://wiki.debian.org/Texi2htmlTransition
> - https://lists.debian.org/debi
On Sunday 24 August 2014 12:50:14 am Michael Niedermayer wrote:
> On Sat, Aug 23, 2014 at 02:02:49PM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > I don't think showing "-1094995529" or similar makes much sense.
> > The calling application can still decide to show the error
> > string (as ffmpeg d
>
> From: JULIAN GARDNER
>To: FFmpeg development discussions and patches
>Sent: Monday, 18 August 2014, 19:51
>Subject: Re: [FFmpeg-devel] Filters
>
>
>
>>
>> From: Clément Bœsch
>>To: FFmpeg development discussions and pat
On Sat, Aug 23, 2014 at 02:02:49PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> I don't think showing "-1094995529" or similar makes much sense.
> The calling application can still decide to show the error
> string (as ffmpeg does).
>
> Please comment, Carl Eugen
> mov.c |2 +-
> 1 file change
On Sun, Aug 24, 2014 at 12:27:09AM +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
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 patches that will make API evolutions. So the projects can continue to
drop
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 patches that will make API evolutions. So the projects can continue to
drop
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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, do
> but either way, id like to suggest again, we move forward and
> rather discuss how we can improve the situation, do something about
> the split and move toward un-doing it!
We look forward to seeing you in Dublin then.
___
ffmpeg-devel mailing list
ffm
On 19.08.14 15:43, Carl Eugen Hoyos wrote:
Deti Fliegl fliegl.de> writes:
Minor update to propagate field dominance.
At least a Changelog entry and a libavdevice version
bump are still missing, but consider waiting for a
real review.
Well in the meantime I updated my patch once again to add
On Sat, Aug 23, 2014 at 07:40:22PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/aasc.c| 2 +-
> libavcodec/cinepak.c | 2 +-
> libavcodec/cyuv.c| 2 +-
> libavcodec/flicvideo.c | 2 +-
> libavcodec/idcinvideo.c | 2 +-
> li
On Sat, Aug 23, 2014 at 07:40:21PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/xan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/xan.c b/libavcodec/xan.c
> index 7489113..bb28916 100644
> --- a/libavcodec/xan.c
> +++ b/libav
Signed-off-by: Paul B Mahol
---
libavcodec/xan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/xan.c b/libavcodec/xan.c
index 7489113..bb28916 100644
--- a/libavcodec/xan.c
+++ b/libavcodec/xan.c
@@ -556,7 +556,7 @@ static int xan_decode_frame(AVCodecContext *avct
Signed-off-by: Paul B Mahol
---
libavcodec/aasc.c| 2 +-
libavcodec/cinepak.c | 2 +-
libavcodec/cyuv.c| 2 +-
libavcodec/flicvideo.c | 2 +-
libavcodec/idcinvideo.c | 2 +-
libavcodec/interplayvideo.c | 2 +-
libavcodec/libopencore-amr.c | 2 +-
libavc
---
This is 100% untested and probably doesn't even compile.
Can anyone with PPC/Altivec HW test or provide such access?
After the altivec optims are ported we can drop the duplicated version in
libavcodec entirely.
The fate-pixelutils tests should cover the alignment checks; there might be
some
Hi
On Thu, Aug 21, 2014 at 03:16:50AM +0200, Attila Kinali wrote:
> Servus,
>
> On Wed, 20 Aug 2014 18:43:18 +0900
> Norbert Preining wrote:
>
> > By continuing old fights, inspite of the very clearly friendly and
> > open offers and suggestions byu Michael, you and others from AV continue
> >
Hi,
On Aug 23, 2014 9:52 AM, "Michael Niedermayer" wrote:
>
> On Sat, Aug 23, 2014 at 03:13:50PM +0200, Andreas Cadhalpun wrote:
> > Is there a reason, why this patch hasn't been applied?
>
> the makeinfo available on our webserver is too old (4.13)
> a newer version (provided by timothy), did n
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 parameters functional.
Also make b_qfactor changeable by x26
On Sat, Aug 23, 2014 at 03:13:50PM +0200, Andreas Cadhalpun wrote:
> Hi,
>
> On 20.07.2014 23:23, Timothy Gu wrote:
> >texi2html is deprecated by upstream in favor of makeinfo/texi2any. See:
> >
> >-
> >https://www.gnu.org/software/texinfo/manual/texinfo/html_node/texi2html.html
> >- https://wiki
Hi,
2014-08-23 17:48 GMT+02:00 Mickaël Raulet :
> For avx2 I have some to push to the trunk, I did merge it yesterday with
> all recent changes. But I don t remember what those tables looks like.
Well, my point was hypothetical, but I guess this means some conflicts
are to be expected when either
For avx2 I have some to push to the trunk, I did merge it yesterday with
all recent changes. But I don t remember what those tables looks like.
For 10 and 12bits, ssse3 should slow down the decoding since it uses 4 more
instructions in the loop.
Le samedi 23 août 2014, Christophe Gisquet a
écrit
On 23/08/14 12:20 PM, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-23 17:16 GMT+02:00 James Almer :
>>> What do you mean by duplicated? That tables for 10 and 12 are?
> [...]
>> I was talking about the opt suffix since both the ssse3 and sse4 tables will
>> be the same.
>
> Oh ok, in case we have
On 23/08/14 8:31 AM, Michael Niedermayer wrote:
> On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote:
>> Derived from deflate code.
>> Requires liblzma.
>>
>> Signed-off-by: James Almer
>
> how can this be tested ?
> do you have a testcase / sample ?
libtiff can create lzma compressed f
On 23/08/14 12:15 PM, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-23 17:01 GMT+02:00 James Almer :
There's a PACK macro in lavfi/x86/yasm-16.asm that does this without
>>> intrinsics.
>>>
>>> You meant yadif-16, right?
>>>
>>> Timothy
>>
>> Oops, yes i meant that :P
>
> I expect it to be nee
Hi,
2014-08-23 17:16 GMT+02:00 James Almer :
>> What do you mean by duplicated? That tables for 10 and 12 are?
[...]
> I was talking about the opt suffix since both the ssse3 and sse4 tables will
> be the same.
Oh ok, in case we have to instantiate sse4 versions. Because at the
moment there are o
Hi,
2014-08-23 17:01 GMT+02:00 James Almer :
>>> There's a PACK macro in lavfi/x86/yasm-16.asm that does this without
>> intrinsics.
>>
>> You meant yadif-16, right?
>>
>> Timothy
>
> Oops, yes i meant that :P
I expect it to be needed for the weighted pred functions, so I'll
split it from yadif-1
On 23/08/14 12:11 PM, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-23 16:52 GMT+02:00 James Almer :
>>> -QPEL_TABLE 8, 8, b, sse4
>>> -QPEL_TABLE 10, 4, w, sse4
>>> -QPEL_TABLE 12, 4, w, sse4
>>> +QPEL_TABLE 8, 8, b, ssse3
>>> +QPEL_TABLE 10, 4, w, ssse3
>>> +QPEL_TABLE 12, 4, w, ssse3
>>
>> Do t
Hi,
2014-08-23 16:52 GMT+02:00 James Almer :
>> -QPEL_TABLE 8, 8, b, sse4
>> -QPEL_TABLE 10, 4, w, sse4
>> -QPEL_TABLE 12, 4, w, sse4
>> +QPEL_TABLE 8, 8, b, ssse3
>> +QPEL_TABLE 10, 4, w, ssse3
>> +QPEL_TABLE 12, 4, w, ssse3
>
> Do these need to be duplicated? You could just remove the suffix a
On 23/08/14 11:55 AM, Timothy Gu wrote:
> On Aug 23, 2014 7:47 AM, "James Almer" wrote:
>>
>> On 23/08/14 11:07 AM, Mickaël Raulet wrote:
>>> For 10bits and 12bits, they should stay sse4 as well because of
> packusdw. You need some instructions to convert it to ssse3 see below
>>>
>>>
>>> static a
On 23/08/14 8:37 AM, Hendrik Leppkes wrote:
> On Sat, Aug 23, 2014 at 1:31 PM, Michael Niedermayer wrote:
>> On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote:
>>> Derived from deflate code.
>>> Requires liblzma.
>>>
>>> Signed-off-by: James Almer
>>
>> how can this be tested ?
>> do yo
On Aug 23, 2014 7:47 AM, "James Almer" wrote:
>
> On 23/08/14 11:07 AM, Mickaël Raulet wrote:
> > For 10bits and 12bits, they should stay sse4 as well because of
packusdw. You need some instructions to convert it to ssse3 see below
> >
> >
> > static av_always_inline __m128i _MM_PACKUS_EPI32( __m1
On 23/08/14 10:22 AM, Christophe Gisquet wrote:
> 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,
On 23/08/14 11:07 AM, Mickaël Raulet wrote:
> For 10bits and 12bits, they should stay sse4 as well because of packusdw. You
> need some instructions to convert it to ssse3 see below
>
>
> static av_always_inline __m128i _MM_PACKUS_EPI32( __m128i a, __m128i b )
> {
> a = _mm_slli_epi32 (a, 1
For 10bits and 12bits, they should stay sse4 as well because of packusdw. You
need some instructions to convert it to ssse3 see below
static av_always_inline __m128i _MM_PACKUS_EPI32( __m128i a, __m128i b )
{
a = _mm_slli_epi32 (a, 16);
a = _mm_srai_epi32 (a, 16);
b = _mm_slli_epi
On Fri, Aug 22, 2014 at 07:47:09AM +0200, Reimar Döffinger wrote:
> On 22.08.2014, at 07:36, Reimar Döffinger wrote:
> > On 22.08.2014, at 04:06, Michael Niedermayer wrote:
> >> On Sat, Aug 16, 2014 at 02:43:46PM +0200, Reimar Döffinger wrote:
> >>> On Wed, Aug 13, 2014 at 01:57:56PM +0200, Micha
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
As far as I can see, the only reason those functions are SSE4 is because
of the pextrw needed for the following block widths:
- 2, used only by chroma;
- 6, used by chroma and indirectly by luma;
- 12, used by both.
The better solution would be to convert all chroma handling to NV12, but
it is vas
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
Hi,
On 20.07.2014 23:23, Timothy Gu wrote:
texi2html is deprecated by upstream in favor of makeinfo/texi2any. See:
- https://www.gnu.org/software/texinfo/manual/texinfo/html_node/texi2html.html
- https://wiki.debian.org/Texi2htmlTransition
- https://lists.debian.org/debian-devel/2013/05/msg0151
Hi,
On 25.07.2014 11:25, db0 company wrote:
Since the style in the release is the one generated from the website,
it has to be the same license. If we add a license to the css/less,
then it's better to have the same on the whole website.
I'll add one.
Did you choose a license already?
Best re
Hi!
I don't think showing "-1094995529" or similar makes much sense.
The calling application can still decide to show the error
string (as ffmpeg does).
Please comment, Carl Eugen
diff --git a/libavformat/mov.c b/libavformat/mov.c
index b3eb287..ae48c02 100644
--- a/libavformat/mov.c
+++ b/libav
On Sat, Aug 23, 2014 at 1:31 PM, Michael Niedermayer wrote:
> On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote:
>> Derived from deflate code.
>> Requires liblzma.
>>
>> Signed-off-by: James Almer
>
> how can this be tested ?
> do you have a testcase / sample ?
>
This image should be l
On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote:
> Derived from deflate code.
> Requires liblzma.
>
> Signed-off-by: James Almer
how can this be tested ?
do you have a testcase / sample ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst fo
Hi,
On 17.08.2014 00:49, Andreas Cadhalpun wrote:
I have now sent the pkg-config patches to the BTS [1].
I have found a simpler way to make it possible to link packages not
using pkg-config against FFmpeg in Debian:
The lib*-ffmpeg-dev packages now install symbolic links from the
standard li
On Sat, Aug 23, 2014 at 3:09 PM, Clément Bœsch wrote:
> Next time please send a git-format-patch (git commit ... && git
> format-patch -1, or use git send-email) instead, so it saves the committer
> the time to copy/paste the commit message and author.
>
> Thank's for the suggestion
Muhammad Fai
On Sun, Aug 17, 2014 at 01:51:13PM +0200, Michael Niedermayer wrote:
> On Thu, Aug 14, 2014 at 11:05:13PM +0200, Clément Bœsch wrote:
> > ~560 → ~500 decicycles
> >
> > This is following the comments from Michael in
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160599.html
> >
> > Usi
On Sat, Aug 23, 2014 at 05:51:31AM +0700, Muhammad Faiz wrote:
[...]
> Update patch to the latest master branch.
>
> Thank's.
>
> Muhammad Faiz
>
> ---
> doc/filters.texi | 26
> libavfilter/avf_showcqt.c | 102
> --
> libavfi
50 matches
Mail list logo
