Re: [FFmpeg-devel] [PATCH v3] ffprobe: Add bits_per_component to stream output

2014-09-04 Thread Tobias Rapp

On 04.09.2014 17:39, wm4 wrote:

diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
index 41e81db..f8af18f 100644
--- a/libavutil/pixdesc.h
+++ b/libavutil/pixdesc.h
@@ -251,6 +251,13 @@ int av_get_bits_per_pixel(const AVPixFmtDescriptor 
*pixdesc);
  int av_get_padded_bits_per_pixel(const AVPixFmtDescriptor *pixdesc);

  /**
+ * Return the number of bits per component (bit depth) for the pixel format
+ * described by pixdesc or 0 if the pixel format has unknown or non-uniform
+ * bit depth.
+ */
+int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc);
+
+/**
   * @return a pixel format descriptor for provided pixel format or NULL if
   * this pixel format is unknown.
   */



Does something such highly specialized really warrant its own API
function? There are several ways how to handle the case if the
component bit depths are not uniform, or even how the term "bit depth"
is to be interpreted, so IMO this should just be internal to ffprobe.


That would also be fine for me. Do you suggest to put it directly in 
ffprobe.c or cmdutils.c or some other file?



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Reimar Döffinger
On 05.09.2014, at 03:46, Reinhard Tartler  wrote:
> On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer  wrote:
>>> At the end of the day, I need a source tarball that contains
>>> maintained sources of a stand-alone libpostproc. I don't care too much
>>> how it is created, as long as it doesn't result in code-duplication
>>> with existing sources in Debian.
>> 
>> would it work if libpostproc could be build and installed
>> standalone from ffmpeg git / ffmpeg release tarballs?
> 
> That would be exactly the code-duplication I referred to in the text
> you've quoted.

Combined with a release script doing rm of libav*?
I think the problem is that libpostproc just isn't a viable stand-alone 
program, mostly due to complete lack of stand-alone testability not to mention 
test infrastructure.
Keeping the separate git up-to-date certainly is an option but involves extra 
effort (though a lot less than making libpostproc testable stand-alone).
I don't see a good way to split the libraries into separate repositories that 
does not involve either at least maintaining configure in each or seriously 
harming bisecting/regression testing.
Release scripts that generate multiple tarballs seems more realistic than 
splitting the repository, in case that sounds like helpful to anyone...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] add silenceremove filter

2014-09-04 Thread Michael Niedermayer
On Mon, Sep 01, 2014 at 10:34:34AM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi   |  69 ++
>  libavfilter/Makefile   |   1 +
>  libavfilter/af_silenceremove.c | 480 
> +
>  libavfilter/allfilters.c   |   1 +
>  4 files changed, 551 insertions(+)
>  create mode 100644 libavfilter/af_silenceremove.c

patch probably ok

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Reinhard Tartler
On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer  wrote:
>> At the end of the day, I need a source tarball that contains
>> maintained sources of a stand-alone libpostproc. I don't care too much
>> how it is created, as long as it doesn't result in code-duplication
>> with existing sources in Debian.
>
> would it work if libpostproc could be build and installed
> standalone from ffmpeg git / ffmpeg release tarballs?

That would be exactly the code-duplication I referred to in the text
you've quoted.

Best,
Reinhard
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Michael Niedermayer
On Thu, Sep 04, 2014 at 07:42:00PM -0400, Reinhard Tartler wrote:
> On Thu, Sep 4, 2014 at 7:27 AM, Michael Niedermayer  wrote:
> > Hi Reinhard
> >
> > On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote:
> >> On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer  
> >> wrote:
> >> > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
> >> >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer  
> >> >> wrote:
> >> >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
> >> >> >> Hi,
> >> >> >>
> >> >> >> as discussed in IRC, I was trying to minimal-invasively port
> >> >> >> libpostproc (the Debian source package) to x32¹. I could not
> >> >> >> test it (for lack of a stand-alone test program) yet, but at
> >> >> >> least I got it to build.
> >> >> >
> >> >> > you could try to test by buiding ffmpeg as a whole but disable asm
> >> >> > everywhere except libpostproc
> >> >> > that might allow "easy" testing though fate or ffmpeg with libavfilter
> >> >>
> >> >> Is http://git.videolan.org/?p=libpostproc.git still maintained?
> >> >
> >> > AFAIK, no, it seems the last commit is 2 years ago
> >> >
> >> >
> >> >>
> >> >> The Debian package tracks that repository, and ideally we could
> >> >> collect the postproc patches there.
> >> >
> >> > libpostproc was and is maintained in
> >> > git://source.ffmpeg.org/ffmpeg.git
> >>
> >> So the promise given in
> >> https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
> >> doesn't hold anymore?
> >
> > Can you be a bit more specific ? what "promise" by whom exactly do
> > you speak of ?
> >
> 
> The promise of having a maintained stand-alone libpostproc.
> 
> >>
> >> Any chance to make you reconsider reviving the standalone libpostproc.git?
> >
> > From what i remember there where some problems with that repository
> > so actually maintaining it would probably imply first recreating it
> >
> > for example try to build a old revission:
> >
> > git checkout a792a836e3d9ef6f1f311604b38095e587282ca7
> > (this is libpostproc/master~20 ATM)
> > ./configure
> > -bash: ./configure: No such file or directory
> >
> > this is a problem for anyone maintaining the code as for example
> > git bisect
> > would not be usable at all
> >
> > or if you do a git show
> > commit a792a836e3d9ef6f1f311604b38095e587282ca7
> > Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c
> >
> > Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6
> > ancestors
> >
> > So really, if someone wants to maintain or use libpostproc.git, first
> > these things need to be fixed
> >
> > but i dont understand why you dont just take libpostproc
> > from where its developed, tested and used ?
> >
> > but if it helps i guess we could copy the libpostproc from FFmpeg
> > over the one in libpostproc.git (which is what reimar suggested)
> > libpostproc.git was only intended to be a copy of FFmpeg with libs
> > other than libpostproc removed anyway.
> >
> > Would this help you ?
> 
> At the end of the day, I need a source tarball that contains
> maintained sources of a stand-alone libpostproc. I don't care too much
> how it is created, as long as it doesn't result in code-duplication
> with existing sources in Debian.

would it work if libpostproc could be build and installed
standalone from ffmpeg git / ffmpeg release tarballs?

i havent really investigated it but it seems with the 2 line patch
below one can achive that with
./configure --enable-gpl --disable-all --enable-shared --enable-postproc  && 
make

(it also would need changing #includes "..." to <...> to use system
installed libavutil headers)

this seems a easier path than maintaining libpostproc.git if it
would work for debian, if not iam sure we will find another solution
like updating libpostproc.git.


diff --git a/Makefile b/Makefile
index 57f6a91..63423bf 100644
--- a/Makefile
+++ b/Makefile
@@ -48,7 +48,7 @@ FFLIBS-$(CONFIG_POSTPROC)   += postproc
 FFLIBS-$(CONFIG_SWRESAMPLE) += swresample
 FFLIBS-$(CONFIG_SWSCALE)+= swscale

-FFLIBS := avutil
+FFLIBS-$(CONFIG_AVUTIL) += avutil

 DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset) 
$(SRC_PATH)/doc/ffprobe.xsd
 EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) 
$(SRC_PATH)/doc/examples/Makefile $(SRC_PATH)/doc/examples/README
diff --git a/configure b/configure
index 7de07c3..7a3764f 100755
--- a/configure
+++ b/configure
@@ -2614,7 +2614,7 @@ avdevice_deps="avformat avcodec avutil"
 avfilter_deps="avutil"
 avformat_deps="avcodec avutil"
 avresample_deps="avutil"
-postproc_deps="avutil gpl"
+postproc_deps="gpl"
 swresample_deps="avutil"
 swscale_deps="avutil"



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/

Re: [FFmpeg-devel] [PATCH 2/6] x86inc: Make ym# behave the same way as xm#

2014-09-04 Thread Michael Niedermayer
On Fri, Sep 05, 2014 at 12:13:34AM +0200, James Darnley wrote:
> From: Henrik Gramner 
> 
> This makes more sense for future implementations of templates with zmm 
> registers.
> ---
>  libavutil/x86/x86inc.asm |8 
>  1 files changed, 4 insertions(+), 4 deletions(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Reinhard Tartler
On Thu, Sep 4, 2014 at 11:23 AM, wm4  wrote:

> And in general, it's a good idea to move optional libraries out of
> ffmpeg.git. (In fact, ffmpeg.git should be split into several git
> repos, one for each lib.)

That idea seems very interesting to me. If coordinated and implemented
well, it could pave a way out of the mess caused by the split.

-- 
regards,
Reinhard
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Reinhard Tartler
On Thu, Sep 4, 2014 at 7:27 AM, Michael Niedermayer  wrote:
> Hi Reinhard
>
> On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote:
>> On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer  wrote:
>> > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
>> >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer  
>> >> wrote:
>> >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
>> >> >> Hi,
>> >> >>
>> >> >> as discussed in IRC, I was trying to minimal-invasively port
>> >> >> libpostproc (the Debian source package) to x32¹. I could not
>> >> >> test it (for lack of a stand-alone test program) yet, but at
>> >> >> least I got it to build.
>> >> >
>> >> > you could try to test by buiding ffmpeg as a whole but disable asm
>> >> > everywhere except libpostproc
>> >> > that might allow "easy" testing though fate or ffmpeg with libavfilter
>> >>
>> >> Is http://git.videolan.org/?p=libpostproc.git still maintained?
>> >
>> > AFAIK, no, it seems the last commit is 2 years ago
>> >
>> >
>> >>
>> >> The Debian package tracks that repository, and ideally we could
>> >> collect the postproc patches there.
>> >
>> > libpostproc was and is maintained in
>> > git://source.ffmpeg.org/ffmpeg.git
>>
>> So the promise given in
>> https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
>> doesn't hold anymore?
>
> Can you be a bit more specific ? what "promise" by whom exactly do
> you speak of ?
>

The promise of having a maintained stand-alone libpostproc.

>>
>> Any chance to make you reconsider reviving the standalone libpostproc.git?
>
> From what i remember there where some problems with that repository
> so actually maintaining it would probably imply first recreating it
>
> for example try to build a old revission:
>
> git checkout a792a836e3d9ef6f1f311604b38095e587282ca7
> (this is libpostproc/master~20 ATM)
> ./configure
> -bash: ./configure: No such file or directory
>
> this is a problem for anyone maintaining the code as for example
> git bisect
> would not be usable at all
>
> or if you do a git show
> commit a792a836e3d9ef6f1f311604b38095e587282ca7
> Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c
>
> Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6
> ancestors
>
> So really, if someone wants to maintain or use libpostproc.git, first
> these things need to be fixed
>
> but i dont understand why you dont just take libpostproc
> from where its developed, tested and used ?
>
> but if it helps i guess we could copy the libpostproc from FFmpeg
> over the one in libpostproc.git (which is what reimar suggested)
> libpostproc.git was only intended to be a copy of FFmpeg with libs
> other than libpostproc removed anyway.
>
> Would this help you ?

At the end of the day, I need a source tarball that contains
maintained sources of a stand-alone libpostproc. I don't care too much
how it is created, as long as it doesn't result in code-duplication
with existing sources in Debian.


-- 
regards,
Reinhard
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 5/6] x86inc: free up variable name "n" in global namespace

2014-09-04 Thread Michael Niedermayer
On Fri, Sep 05, 2014 at 12:13:37AM +0200, James Darnley wrote:
> From: Loren Merritt 
> 
> ---
>  libavutil/x86/x86inc.asm |   18 +-
>  1 files changed, 9 insertions(+), 9 deletions(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: add ff_hevc_transform_add32_8_avx2

2014-09-04 Thread James Almer
On 04/09/14 5:18 PM, Michael Niedermayer wrote:
> On Sun, Aug 31, 2014 at 11:46:13PM -0300, James Almer wrote:
>> ~20% faster than AVX.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/x86/hevc_res_add.asm | 31 +++
>>  libavcodec/x86/hevcdsp.h|  2 ++
>>  libavcodec/x86/hevcdsp_init.c   |  2 ++
>>  3 files changed, 31 insertions(+), 4 deletions(-)
> 
> LGTM
> 
> thanks

Pushed.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/6] x264asm: warn when inappropriate instruction used in function with specified cpuflags

2014-09-04 Thread Michael Niedermayer
On Fri, Sep 05, 2014 at 12:49:10AM +0200, James Darnley wrote:
> On 2014-09-05 00:13, James Darnley wrote:
> > From: Anton Mitrofanov 
> > 
> > ---
> >  libavutil/x86/x86inc.asm |  581 
> > +++---
> >  1 files changed, 295 insertions(+), 286 deletions(-)
> 
> If I didn't make it clear, this has not yet been added to x264's x86inc.
>  It is awaiting reviews and later the irregular push to x264's repository.

then its probably best we wait until x264s reviews are finished and
apply it then with any potential changes resulting out of such reviews

[...]

-- 
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


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/6] x264asm: warn when inappropriate instruction used in function with specified cpuflags

2014-09-04 Thread James Darnley
On 2014-09-05 00:13, James Darnley wrote:
> From: Anton Mitrofanov 
> 
> ---
>  libavutil/x86/x86inc.asm |  581 
> +++---
>  1 files changed, 295 insertions(+), 286 deletions(-)

If I didn't make it clear, this has not yet been added to x264's x86inc.
 It is awaiting reviews and later the irregular push to x264's repository.




signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avutil/md5: workaround clang 3.5 #20849

2014-09-04 Thread Michael Niedermayer
On Fri, Sep 05, 2014 at 12:36:29AM +0200, James Darnley wrote:
> On 2014-09-05 00:31, Michael Niedermayer wrote:
> > This avoids several failures on fate.ffmpeg.org, and thus makes real
> > bugs easier to spot
> 
> A good reason.
> 
> > +volatile uint8_t in[1000]; // volatile to workaround 
> > http://llvm.org/bugs/show_bug.cgi?id=20849
> 
> Perhaps add a FIXME to the comment so it could be found more easily
> later, perhaps when the bug is fixed.

added

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/6] lavc/x86/v210: give cpuflag to INIT macro

2014-09-04 Thread Michael Niedermayer
On Fri, Sep 05, 2014 at 12:13:35AM +0200, James Darnley wrote:
> This lets the cglobal macro automatically append a suffix to the function 
> name.
> This means that INIT_XMM avx must be used rather than INIT_AVX.
> ---
>  libavcodec/x86/v210.asm |   22 --
>  1 files changed, 12 insertions(+), 10 deletions(-)

applied

thanks


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avutil/md5: workaround clang 3.5 #20849

2014-09-04 Thread James Darnley
On 2014-09-05 00:31, Michael Niedermayer wrote:
> This avoids several failures on fate.ffmpeg.org, and thus makes real
> bugs easier to spot

A good reason.

> +volatile uint8_t in[1000]; // volatile to workaround 
> http://llvm.org/bugs/show_bug.cgi?id=20849

Perhaps add a FIXME to the comment so it could be found more easily
later, perhaps when the bug is fixed.




signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avutil/md5: workaround clang 3.5 #20849

2014-09-04 Thread Michael Niedermayer
This avoids several failures on fate.ffmpeg.org, and thus makes real
bugs easier to spot

Signed-off-by: Michael Niedermayer 
---
 libavutil/md5.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/md5.c b/libavutil/md5.c
index 63fc37d..32c5c27 100644
--- a/libavutil/md5.c
+++ b/libavutil/md5.c
@@ -218,7 +218,7 @@ static void print_md5(uint8_t *md5)
 int main(void){
 uint8_t md5val[16];
 int i;
-uint8_t in[1000];
+volatile uint8_t in[1000]; // volatile to workaround 
http://llvm.org/bugs/show_bug.cgi?id=20849
 
 for (i = 0; i < 1000; i++)
 in[i] = i * i;
-- 
1.7.9.5

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] vfi/x86/vf_idet: fix incorrect use of paddq

2014-09-04 Thread James Darnley
paddq is an SSE2 instruction so it cannot be used for MMX.

This was probably just a typo because the sums are dwords anyway.
---

We should have picked this up in review but we didn't...

 libavfilter/x86/vf_idet.asm |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavfilter/x86/vf_idet.asm b/libavfilter/x86/vf_idet.asm
index fb29804..0eb974b 100644
--- a/libavfilter/x86/vf_idet.asm
+++ b/libavfilter/x86/vf_idet.asm
@@ -70,7 +70,7 @@ cglobal idet_filter_line, 4, 5, 0, a, b, c, width, index
 
 mova  m0, m_sum
 psrlq m_sum, 0x20
-paddq m0, m_sum
+paddd m0, m_sum
 movd  eax, m0
 RET
 %endmacro
-- 
1.7.9

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 6/6] x86inc: Make INIT_CPUFLAGS support an arbitrary number of cpuflags

2014-09-04 Thread James Darnley
From: Henrik Gramner 

Previously there was a limit of two cpuflags.
---
 libavutil/x86/x86inc.asm |   41 ++---
 1 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 4cc6b0e..fa6a6ab 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -99,9 +99,6 @@
 %endif
 %endmacro
 
-; Always use long nops (reduces 0x90 spam in disassembly on x86_32)
-CPUNOP amdnop
-
 ; Macros to eliminate most code duplication between x86_32 and x86_64:
 ; Currently this works only for leaf functions which load all their arguments
 ; into registers at the start, and make no other use of the stack. Luckily that
@@ -759,19 +756,26 @@ SECTION .note.GNU-stack noalloc noexec nowrite progbits
 %definecpuflag(x) ((cpuflags & (cpuflags_ %+ x)) == (cpuflags_ %+ x))
 %define notcpuflag(x) ((cpuflags & (cpuflags_ %+ x)) != (cpuflags_ %+ x))
 
-; Takes up to 2 cpuflags from the above list.
+; Takes an arbitrary number of cpuflags from the above list.
 ; All subsequent functions (up to the next INIT_CPUFLAGS) is built for the 
specified cpu.
 ; You shouldn't need to invoke this macro directly, it's a subroutine for 
INIT_MMX &co.
-%macro INIT_CPUFLAGS 0-2
-CPUNOP amdnop
+%macro INIT_CPUFLAGS 0-*
+%xdefine SUFFIX
+%undef cpuname
+%assign cpuflags 0
+
 %if %0 >= 1
-%xdefine cpuname %1
-%assign cpuflags cpuflags_%1
-%if %0 >= 2
-%xdefine cpuname %1_%2
-%assign cpuflags cpuflags | cpuflags_%2
-%endif
+%rep %0
+%ifdef cpuname
+%xdefine cpuname cpuname %+ _%1
+%else
+%xdefine cpuname %1
+%endif
+%assign cpuflags cpuflags | cpuflags_%1
+%rotate 1
+%endrep
 %xdefine SUFFIX _ %+ cpuname
+
 %if cpuflag(avx)
 %assign avx_enabled 1
 %endif
@@ -782,16 +786,15 @@ SECTION .note.GNU-stack noalloc noexec nowrite progbits
 %endif
 %if cpuflag(aligned)
 %define movu mova
-%elifidn %1, sse3
+%elif cpuflag(sse3) && notcpuflag(ssse3)
 %define movu lddqu
 %endif
-%if notcpuflag(sse2)
-CPUNOP basicnop
-%endif
+%endif
+
+%if cpuflag(sse2)
+CPUNOP amdnop
 %else
-%xdefine SUFFIX
-%undef cpuname
-%undef cpuflags
+CPUNOP basicnop
 %endif
 %endmacro
 
-- 
1.7.9

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 4/6] lavu/x86/x86inc: deprecate INIT_AVX

2014-09-04 Thread James Darnley
The same can be done with INIT_XMM avx
---
 libavutil/x86/x86inc.asm |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 65a23d8..c028c0b 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -853,14 +853,6 @@ SECTION .note.GNU-stack noalloc noexec nowrite progbits
 INIT_CPUFLAGS %1
 %endmacro
 
-; FIXME: INIT_AVX can be replaced by INIT_XMM avx
-%macro INIT_AVX 0
-INIT_XMM
-%assign avx_enabled 1
-%define PALIGNR PALIGNR_SSSE3
-%define RESET_MM_PERMUTATION INIT_AVX
-%endmacro
-
 %macro INIT_YMM 0-1+
 %assign avx_enabled 1
 %define RESET_MM_PERMUTATION INIT_YMM %1
-- 
1.7.9

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 5/6] x86inc: free up variable name "n" in global namespace

2014-09-04 Thread James Darnley
From: Loren Merritt 

---
 libavutil/x86/x86inc.asm |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index c028c0b..4cc6b0e 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -821,12 +821,12 @@ SECTION .note.GNU-stack noalloc noexec nowrite progbits
 %assign %%i 0
 %rep 8
 CAT_XDEFINE m, %%i, mm %+ %%i
-CAT_XDEFINE nmm, %%i, %%i
+CAT_XDEFINE nnmm, %%i, %%i
 %assign %%i %%i+1
 %endrep
 %rep 8
 CAT_UNDEF m, %%i
-CAT_UNDEF nmm, %%i
+CAT_UNDEF nnmm, %%i
 %assign %%i %%i+1
 %endrep
 INIT_CPUFLAGS %1
@@ -847,7 +847,7 @@ SECTION .note.GNU-stack noalloc noexec nowrite progbits
 %assign %%i 0
 %rep num_mmregs
 CAT_XDEFINE m, %%i, xmm %+ %%i
-CAT_XDEFINE nxmm, %%i, %%i
+CAT_XDEFINE nnxmm, %%i, %%i
 %assign %%i %%i+1
 %endrep
 INIT_CPUFLAGS %1
@@ -917,7 +917,7 @@ INIT_XMM
 %endrep
 %rep %0/2
 %xdefine m%1 %%tmp%2
-CAT_XDEFINE n, m%1, %1
+CAT_XDEFINE nn, m%1, %1
 %rotate 2
 %endrep
 %endmacro
@@ -935,16 +935,16 @@ INIT_XMM
 %xdefine %%tmp m%1
 %xdefine m%1 m%2
 %xdefine m%2 %%tmp
-CAT_XDEFINE n, m%1, %1
-CAT_XDEFINE n, m%2, %2
+CAT_XDEFINE nn, m%1, %1
+CAT_XDEFINE nn, m%2, %2
 %rotate 1
 %endrep
 %endmacro
 
 %macro SWAP_INTERNAL_NAME 2-*
-%xdefine %%args n %+ %1
+%xdefine %%args nn %+ %1
 %rep %0-1
-%xdefine %%args %%args, n %+ %2
+%xdefine %%args %%args, nn %+ %2
 %rotate 1
 %endrep
 SWAP_INTERNAL_NUM %%args
@@ -971,7 +971,7 @@ INIT_XMM
 %assign %%i 0
 %rep num_mmregs
 CAT_XDEFINE m, %%i, %1_m %+ %%i
-CAT_XDEFINE n, m %+ %%i, %%i
+CAT_XDEFINE nn, m %+ %%i, %%i
 %assign %%i %%i+1
 %endrep
 %endif
-- 
1.7.9

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/6] x86inc: Make ym# behave the same way as xm#

2014-09-04 Thread James Darnley
From: Henrik Gramner 

This makes more sense for future implementations of templates with zmm 
registers.
---
 libavutil/x86/x86inc.asm |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 87f3af7..65a23d8 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -796,9 +796,9 @@ SECTION .note.GNU-stack noalloc noexec nowrite progbits
 %endmacro
 
 ; Merge mmx and sse*
-; m# is a simd regsiter of the currently selected size
-; xm# is the corresponding xmmreg (if selcted xmm or ymm size), or mmreg (if 
selected mmx)
-; ym# is the corresponding ymmreg (if selcted xmm or ymm size), or mmreg (if 
selected mmx)
+; m# is a simd register of the currently selected size
+; xm# is the corresponding xmm register if mmsize >= 16, otherwise the same as 
m#
+; ym# is the corresponding ymm register if mmsize >= 32, otherwise the same as 
m#
 ; (All 3 remain in sync through SWAP.)
 
 %macro CAT_XDEFINE 3
@@ -892,7 +892,7 @@ INIT_XMM
 %define xmmxmm%1 xmm%1
 %define xmmymm%1 xmm%1
 %define y%1   mm%1
-%define ymmxmm%1 ymm%1
+%define ymmxmm%1 xmm%1
 %define ymmymm%1 ymm%1
 %define xm%1 xmm %+ m%1
 %define ym%1 ymm %+ m%1
-- 
1.7.9

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 1/6] x264asm: warn when inappropriate instruction used in function with specified cpuflags

2014-09-04 Thread James Darnley
From: Anton Mitrofanov 

---
 libavutil/x86/x86inc.asm |  581 +++---
 1 files changed, 295 insertions(+), 286 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 1cfb055..87f3af7 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1052,15 +1052,16 @@ INIT_XMM
 %endmacro
 
 ;%1 == instruction
-;%2 == 1 if float, 0 if int
-;%3 == 1 if non-destructive or 4-operand (xmm, xmm, xmm, imm), 0 otherwise
-;%4 == 1 if commutative (i.e. doesn't matter which src arg is which), 0 if not
-;%5+: operands
-%macro RUN_AVX_INSTR 5-8+
-%ifnum sizeof%6
+;%2 == minimal instruction set
+;%3 == 1 if float, 0 if int
+;%4 == 1 if non-destructive or 4-operand (xmm, xmm, xmm, imm), 0 otherwise
+;%5 == 1 if commutative (i.e. doesn't matter which src arg is which), 0 if not
+;%6+: operands
+%macro RUN_AVX_INSTR 6-9+
+%ifnum sizeof%7
+%assign __sizeofreg sizeof%7
+%elifnum sizeof%6
 %assign __sizeofreg sizeof%6
-%elifnum sizeof%5
-%assign __sizeofreg sizeof%5
 %else
 %assign __sizeofreg mmsize
 %endif
@@ -1069,325 +1070,333 @@ INIT_XMM
 %xdefine __instr v%1
 %else
 %xdefine __instr %1
-%if %0 >= 7+%3
+%if %0 >= 8+%4
 %assign __emulate_avx 1
 %endif
 %endif
+%ifnidn %2, fnord
+%ifdef cpuname
+%if notcpuflag(%2)
+%error use of ``%1'' %2 instruction in cpuname function: 
current_function
+%endif
+%endif
+%endif
 
 %if __emulate_avx
-%xdefine __src1 %6
-%xdefine __src2 %7
-%ifnidn %5, %6
-%if %0 >= 8
-CHECK_AVX_INSTR_EMU {%1 %5, %6, %7, %8}, %5, %7, %8
+%xdefine __src1 %7
+%xdefine __src2 %8
+%ifnidn %6, %7
+%if %0 >= 9
+CHECK_AVX_INSTR_EMU {%1 %6, %7, %8, %9}, %6, %8, %9
 %else
-CHECK_AVX_INSTR_EMU {%1 %5, %6, %7}, %5, %7
+CHECK_AVX_INSTR_EMU {%1 %6, %7, %8}, %6, %8
 %endif
-%if %4 && %3 == 0
-%ifnid %7
+%if %5 && %4 == 0
+%ifnid %8
 ; 3-operand AVX instructions with a memory arg can only 
have it in src2,
 ; whereas SSE emulation prefers to have it in src1 (i.e. 
the mov).
 ; So, if the instruction is commutative with a memory arg, 
swap them.
-%xdefine __src1 %7
-%xdefine __src2 %6
+%xdefine __src1 %8
+%xdefine __src2 %7
 %endif
 %endif
 %if __sizeofreg == 8
-MOVQ %5, __src1
-%elif %2
-MOVAPS %5, __src1
+MOVQ %6, __src1
+%elif %3
+MOVAPS %6, __src1
 %else
-MOVDQA %5, __src1
+MOVDQA %6, __src1
 %endif
 %endif
-%if %0 >= 8
-%1 %5, __src2, %8
+%if %0 >= 9
+%1 %6, __src2, %9
 %else
-%1 %5, __src2
+%1 %6, __src2
 %endif
-%elif %0 >= 8
-__instr %5, %6, %7, %8
+%elif %0 >= 9
+__instr %6, %7, %8, %9
+%elif %0 == 8
+__instr %6, %7, %8
 %elif %0 == 7
-__instr %5, %6, %7
-%elif %0 == 6
-__instr %5, %6
+__instr %6, %7
 %else
-__instr %5
+__instr %6
 %endif
 %endmacro
 
 ;%1 == instruction
-;%2 == 1 if float, 0 if int
-;%3 == 1 if non-destructive or 4-operand (xmm, xmm, xmm, imm), 0 otherwise
-;%4 == 1 if commutative (i.e. doesn't matter which src arg is which), 0 if not
-%macro AVX_INSTR 1-4 0, 1, 0
-%macro %1 1-9 fnord, fnord, fnord, fnord, %1, %2, %3, %4
+;%2 == minimal instruction set
+;%3 == 1 if float, 0 if int
+;%4 == 1 if non-destructive or 4-operand (xmm, xmm, xmm, imm), 0 otherwise
+;%5 == 1 if commutative (i.e. doesn't matter which src arg is which), 0 if not
+%macro AVX_INSTR 1-5 fnord, 0, 1, 0
+%macro %1 1-10 fnord, fnord, fnord, fnord, %1, %2, %3, %4, %5
 %ifidn %2, fnord
-RUN_AVX_INSTR %6, %7, %8, %9, %1
+RUN_AVX_INSTR %6, %7, %8, %9, %10, %1
 %elifidn %3, fnord
-RUN_AVX_INSTR %6, %7, %8, %9, %1, %2
+RUN_AVX_INSTR %6, %7, %8, %9, %10, %1, %2
 %elifidn %4, fnord
-RUN_AVX_INSTR %6, %7, %8, %9, %1, %2, %3
+RUN_AVX_INSTR %6, %7, %8, %9, %10, %1, %2, %3
 %elifidn %5, fnord
-RUN_AVX_INSTR %6, %7, %8, %9, %1, %2, %3, %4
+RUN_AVX_INSTR %6, %7, %8, %9, %10, %1, %2, %3, %4
 %else
-RUN_AVX_INSTR %6, %7, %8, %9, %1, %2, %3, %4, %5
+RUN_AVX_INSTR %6, %7, %8, %9, %10, %1, %2, %3, %4, %5
 %endif
 %endmacro
 %endmacro
 
 ; Instructions with both VEX and non-VEX encodings
 ; Non-destructive instru

[FFmpeg-devel] [PATCH 3/6] lavc/x86/v210: give cpuflag to INIT macro

2014-09-04 Thread James Darnley
This lets the cglobal macro automatically append a suffix to the function name.
This means that INIT_XMM avx must be used rather than INIT_AVX.
---
 libavcodec/x86/v210.asm |   22 --
 1 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/libavcodec/x86/v210.asm b/libavcodec/x86/v210.asm
index 6554a43..400a1f3 100644
--- a/libavcodec/x86/v210.asm
+++ b/libavcodec/x86/v210.asm
@@ -31,10 +31,10 @@ v210_chroma_shuf: db 0,1,8,9,6,7,-1,-1,2,3,4,5,12,13,-1,-1
 
 SECTION .text
 
-%macro v210_planar_unpack 2
+%macro v210_planar_unpack 1
 
 ; v210_planar_unpack(const uint32_t *src, uint16_t *y, uint16_t *u, uint16_t 
*v, int width)
-cglobal v210_planar_unpack_%1_%2, 5, 5, 7
+cglobal v210_planar_unpack_%1, 5, 5, 7
 movsxdifnidn r4, r4d
 lear1, [r1+2*r4]
 addr2, r4
@@ -73,16 +73,18 @@ cglobal v210_planar_unpack_%1_%2, 5, 5, 7
 REP_RET
 %endmacro
 
-INIT_XMM
-v210_planar_unpack unaligned, ssse3
+INIT_XMM ssse3
+v210_planar_unpack unaligned
+
 %if HAVE_AVX_EXTERNAL
-INIT_AVX
-v210_planar_unpack unaligned, avx
+INIT_XMM avx
+v210_planar_unpack unaligned
 %endif
 
-INIT_XMM
-v210_planar_unpack aligned, ssse3
+INIT_XMM ssse3
+v210_planar_unpack aligned
+
 %if HAVE_AVX_EXTERNAL
-INIT_AVX
-v210_planar_unpack aligned, avx
+INIT_XMM avx
+v210_planar_unpack aligned
 %endif
-- 
1.7.9

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 0/6] Miscellaneous x86inc patches

2014-09-04 Thread James Darnley
There was quite a difference building up between FFmpeg's x86inc.asm file and
x264's so I spent a little time merging  some of the easy patches into our copy.

I have also included Anton's patch which adds a little checking on instructions
used and whether they are supported by the instruction set we have tried to
make a function for.

To the people at Libav, you won't be getting the two patches by me (I hope I do
this CC properly) as your tree doesn't need them.

Anton Mitrofanov (1):
  x264asm: warn when inappropriate instruction used in function with
specified cpuflags

Henrik Gramner (2):
  x86inc: Make ym# behave the same way as xm#
  x86inc: Make INIT_CPUFLAGS support an arbitrary number of cpuflags

James Darnley (2):
  lavc/x86/v210: give cpuflag to INIT macro
  lavu/x86/x86inc: deprecate INIT_AVX

Loren Merritt (1):
  x86inc: free up variable name "n" in global namespace

 libavcodec/x86/v210.asm  |   22 +-
 libavutil/x86/x86inc.asm |  656 +++---
 2 files changed, 342 insertions(+), 336 deletions(-)

-- 
1.7.9

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 1/4] libavutil/error: fix build with musl toolchain

2014-09-04 Thread Jörg Krause


On 09/04/2014 05:27 PM, Hendrik Leppkes wrote:

On Wed, Sep 3, 2014 at 11:53 AM, Jörg Krause  wrote:

Add the feature test macro which is required for building with the
musl toolchain.

The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
version of strerror_r().

[..]

  _XOPEN_SOURCE 600 is set as a compiler parameter for all other
toolchains that need it, including glibc and whatnot.
We should really do the same for musl here, using special treatment is weird.

Detect musl in configure, add a new libc block, set
-D_XOPEN_SOURCE=600 in the cflags, and it would be consistent with
everything else.


We had a discussion about this issue here at the mailing list.

Detecting musl in configure is not possible. There is no __MUSL__ like 
__GLIBC__ in . The maintainers of musl prefer that the 
library is tested for the exposed feature set.


Another approach is to set the desired feature test macro at source 
level, which is the recommation of the GNU C Library Reference Manual, 
instead of setting it with -D.


If we follow this approach, we have constintency for glibc, uclibc, and 
musl. And we do not need a libc block for them in configure (at least 
not for setting any feature test macro with -D).

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2 5/6] avformat/srtdec: speed up probing

2014-09-04 Thread wm4
---
As suggested by ubitux. Note that the change to ff_subtitles_read_line()
already cuts down the probing time a lot, so maybe this is not needed.
---
 libavformat/srtdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
index b63d344..f5f3933 100644
--- a/libavformat/srtdec.c
+++ b/libavformat/srtdec.c
@@ -43,6 +43,7 @@ static int srt_probe(AVProbeData *p)
 if (ff_subtitles_read_line(&tr, buf, sizeof(buf)) < 0)
 break;
 if ((num == i || num + 1 == i)
+&& buf[0] >= '0' && buf[1] <= '9' && strstr(buf, " --> ")
 && sscanf(buf, "%*d:%*2d:%*2d%*1[,.]%*3d --> 
%*d:%*2d:%*2d%*1[,.]%3d", &v) == 1)
 return AVPROBE_SCORE_MAX;
 num = atoi(buf);
-- 
2.1.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2 6/6] avformat/subtitles: guess UTF-16 if no BOM present

2014-09-04 Thread wm4
---
Follows reimar's suggestion for detecting UTF-16. If the detection goes
wrong, probing the format won't succeed, so this should not break
anything.

I didn't use ffio_ensure_seekback), because this apparently reallocates
the buffer - which we certainly don't want, because the probe API
doesn't allow this.

Probably too messy, feel free to drop.
---
 libavformat/subtitles.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 3069477..7d6a93c 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -26,6 +26,7 @@
 
 void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
 {
+int can_seekback_2_bytes = pb->buf_end - pb->buf_ptr >= 2;
 int i;
 r->pb = pb;
 r->buf_pos = r->buf_len = 0;
@@ -38,6 +39,14 @@ void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
 } else if (strncmp("\xFE\xFF", r->buf, 2) == 0) {
 r->type = FF_UTF16BE;
 r->buf_pos += 2;
+} else if (can_seekback_2_bytes && r->buf[0] && !r->buf[1]) {
+r->type = FF_UTF16LE; // with high probability
+r->pb->buf_ptr -= 2;
+r->buf_pos = r->buf_len = 0;
+} else if (can_seekback_2_bytes && !r->buf[0] && r->buf[1]) {
+r->type = FF_UTF16BE; // with high probability
+r->pb->buf_ptr -= 2;
+r->buf_pos = r->buf_len = 0;
 } else {
 r->buf[r->buf_len++] = avio_r8(r->pb);
 if (strncmp("\xEF\xBB\xBF", r->buf, 3) == 0) {
-- 
2.1.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2 3/6] avformat/samidec: UTF-16 support

2014-09-04 Thread wm4
ff_smil_extract_next_chunk() is still used by RealText.
---
No changes.
---
 libavformat/samidec.c   | 17 ++---
 libavformat/subtitles.c | 15 ---
 libavformat/subtitles.h |  5 +
 3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/libavformat/samidec.c b/libavformat/samidec.c
index 1a12eca..4dbf2cf 100644
--- a/libavformat/samidec.c
+++ b/libavformat/samidec.c
@@ -38,11 +38,12 @@ typedef struct {
 
 static int sami_probe(AVProbeData *p)
 {
-const unsigned char *ptr = p->buf;
+char buf[6];
+FFTextReader tr;
+ff_text_init_buf(&tr, p->buf, p->buf_size);
+ff_text_read(&tr, buf, sizeof(buf));
 
-if (AV_RB24(ptr) == 0xEFBBBF)
-ptr += 3;  /* skip UTF-8 BOM */
-return !strncmp(ptr, "", 6) ? AVPROBE_SCORE_MAX : 0;
+return !strncmp(buf, "", 6) ? AVPROBE_SCORE_MAX : 0;
 }
 
 static int sami_read_header(AVFormatContext *s)
@@ -52,6 +53,8 @@ static int sami_read_header(AVFormatContext *s)
 AVBPrint buf, hdr_buf;
 char c = 0;
 int res = 0, got_first_sync_point = 0;
+FFTextReader tr;
+ff_text_init_avio(&tr, s->pb);
 
 if (!st)
 return AVERROR(ENOMEM);
@@ -62,10 +65,10 @@ static int sami_read_header(AVFormatContext *s)
 av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
 av_bprint_init(&hdr_buf, 0, AV_BPRINT_SIZE_UNLIMITED);
 
-while (!avio_feof(s->pb)) {
+while (!ff_text_eof(&tr)) {
 AVPacket *sub;
-const int64_t pos = avio_tell(s->pb) - (c != 0);
-int is_sync, n = ff_smil_extract_next_chunk(s->pb, &buf, &c);
+const int64_t pos = ff_text_pos(&tr) - (c != 0);
+int is_sync, n = ff_smil_extract_next_text_chunk(&tr, &buf, &c);
 
 if (n == 0)
 break;
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 05d52c3..d650504 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -272,20 +272,20 @@ void ff_subtitles_queue_clean(FFDemuxSubtitlesQueue *q)
 q->nb_subs = q->allocated_size = q->current_sub_idx = 0;
 }
 
-int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
+int ff_smil_extract_next_text_chunk(FFTextReader *tr, AVBPrint *buf, char *c)
 {
 int i = 0;
 char end_chr;
 
 if (!*c) // cached char?
-*c = avio_r8(pb);
+*c = ff_text_r8(tr);
 if (!*c)
 return 0;
 
 end_chr = *c == '<' ? '>' : '<';
 do {
 av_bprint_chars(buf, *c, 1);
-*c = avio_r8(pb);
+*c = ff_text_r8(tr);
 i++;
 } while (*c != end_chr && *c);
 if (end_chr == '>') {
@@ -295,6 +295,15 @@ int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint 
*buf, char *c)
 return i;
 }
 
+int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
+{
+FFTextReader tr;
+tr.buf_pos = tr.buf_len = 0;
+tr.type = 0;
+tr.pb = pb;
+return ff_smil_extract_next_text_chunk(&tr, buf, c);
+}
+
 const char *ff_smil_get_attr_ptr(const char *s, const char *attr)
 {
 int in_quotes = 0;
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index d70c9ef..3ef0bfc 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -150,6 +150,11 @@ void ff_subtitles_queue_clean(FFDemuxSubtitlesQueue *q);
 int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c);
 
 /**
+ * As ff_smil_extract_next_chunk(), but with FFTextReader.
+ */
+int ff_smil_extract_next_text_chunk(FFTextReader *tr, AVBPrint *buf, char *c);
+
+/**
  * SMIL helper to point on the value of an attribute in the given tag.
  *
  * @param sSMIL tag ("<...>")
-- 
2.1.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2 2/6] avformat/srtdec: UTF-16 support

2014-09-04 Thread wm4
---
ff_subtitles_read_line() now returns an error if a 0 byte is
encountered. This is faster and could be considered more correct.
It also handles UTF recode errors better.
---
 libavformat/srtdec.c| 25 +---
 libavformat/subtitles.c | 51 +++--
 libavformat/subtitles.h | 36 +++---
 3 files changed, 96 insertions(+), 16 deletions(-)

diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
index 53182cd..b63d344 100644
--- a/libavformat/srtdec.c
+++ b/libavformat/srtdec.c
@@ -31,20 +31,21 @@ typedef struct {
 
 static int srt_probe(AVProbeData *p)
 {
-const unsigned char *ptr = p->buf;
 int i, v, num = 0;
+FFTextReader tr;
 
-if (AV_RB24(ptr) == 0xEFBBBF)
-ptr += 3;  /* skip UTF-8 BOM */
+ff_text_init_buf(&tr, p->buf, p->buf_size);
 
-while (*ptr == '\r' || *ptr == '\n')
-ptr++;
+while (ff_text_peek_r8(&tr) == '\r' || ff_text_peek_r8(&tr) == '\n')
+ff_text_r8(&tr);
 for (i=0; i<2; i++) {
+char buf[128];
+if (ff_subtitles_read_line(&tr, buf, sizeof(buf)) < 0)
+break;
 if ((num == i || num + 1 == i)
-&& sscanf(ptr, "%*d:%*2d:%*2d%*1[,.]%*3d --> 
%*d:%*2d:%*2d%*1[,.]%3d", &v) == 1)
+&& sscanf(buf, "%*d:%*2d:%*2d%*1[,.]%*3d --> 
%*d:%*2d:%*2d%*1[,.]%3d", &v) == 1)
 return AVPROBE_SCORE_MAX;
-num = atoi(ptr);
-ptr += ff_subtitles_next_line(ptr);
+num = atoi(buf);
 }
 return 0;
 }
@@ -79,6 +80,8 @@ static int srt_read_header(AVFormatContext *s)
 AVBPrint buf;
 AVStream *st = avformat_new_stream(s, NULL);
 int res = 0;
+FFTextReader tr;
+ff_text_init_avio(&tr, s->pb);
 
 if (!st)
 return AVERROR(ENOMEM);
@@ -88,11 +91,11 @@ static int srt_read_header(AVFormatContext *s)
 
 av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
 
-while (!avio_feof(s->pb)) {
-ff_subtitles_read_chunk(s->pb, &buf);
+while (!ff_text_eof(&tr)) {
+ff_subtitles_read_text_chunk(&tr, &buf);
 
 if (buf.len) {
-int64_t pos = avio_tell(s->pb);
+int64_t pos = ff_text_pos(&tr);
 int64_t pts;
 int duration;
 const char *ptr = buf.str;
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index cebd453..05d52c3 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -86,6 +86,23 @@ void ff_text_read(FFTextReader *r, char *buf, size_t size)
 *buf++ = ff_text_r8(r);
 }
 
+int ff_text_eof(FFTextReader *r)
+{
+return r->buf_pos >= r->buf_len && (!r->pb || avio_feof(r->pb));
+}
+
+int ff_text_peek_r8(FFTextReader *r)
+{
+int c;
+if (r->buf_pos < r->buf_len)
+return r->buf[r->buf_pos];
+c = ff_text_r8(r);
+r->buf_pos = 0;
+r->buf_len = 1;
+r->buf[0] = c;
+return c;
+}
+
 AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue *q,
 const uint8_t *event, int len, int merge)
 {
@@ -303,7 +320,7 @@ static inline int is_eol(char c)
 return c == '\r' || c == '\n';
 }
 
-void ff_subtitles_read_chunk(AVIOContext *pb, AVBPrint *buf)
+void ff_subtitles_read_text_chunk(FFTextReader *tr, AVBPrint *buf)
 {
 char eol_buf[5], last_was_cr = 0;
 int n = 0, i = 0, nb_eol = 0;
@@ -311,7 +328,7 @@ void ff_subtitles_read_chunk(AVIOContext *pb, AVBPrint *buf)
 av_bprint_clear(buf);
 
 for (;;) {
-char c = avio_r8(pb);
+char c = ff_text_r8(tr);
 
 if (!c)
 break;
@@ -344,3 +361,33 @@ void ff_subtitles_read_chunk(AVIOContext *pb, AVBPrint 
*buf)
 n++;
 }
 }
+
+void ff_subtitles_read_chunk(AVIOContext *pb, AVBPrint *buf)
+{
+FFTextReader tr;
+tr.buf_pos = tr.buf_len = 0;
+tr.type = 0;
+tr.pb = pb;
+ff_subtitles_read_text_chunk(&tr, buf);
+}
+
+ptrdiff_t ff_subtitles_read_line(FFTextReader *tr, char *buf, size_t size)
+{
+size_t cur = 0;
+if (!size)
+return 0;
+while (cur + 1 < size) {
+unsigned char c = ff_text_r8(tr);
+if (!c)
+return AVERROR_INVALIDDATA;
+if (c == '\r' || c == '\n')
+break;
+buf[cur++] = c;
+buf[cur] = '\0';
+}
+if (ff_text_peek_r8(tr) == '\r')
+ff_text_r8(tr);
+if (ff_text_peek_r8(tr) == '\n')
+ff_text_r8(tr);
+return cur;
+}
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index 317e40a..d70c9ef 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -22,6 +22,7 @@
 #define AVFORMAT_SUBTITLES_H
 
 #include 
+#include 
 #include "avformat.h"
 #include "libavutil/bprint.h"
 
@@ -82,6 +83,18 @@ int64_t ff_text_pos(FFTextReader *r);
 int ff_text_r8(FFTextReader *r);
 
 /**
+ * Return non-zero if EOF was reached.
+ */
+int ff_text_eof(FFTextReader *r);
+
+/**
+ * Like ff_text_r8(), but don't remove the byte from the buffer.
+ *
+ * @note ff_text_eof might

[FFmpeg-devel] [PATCH v2 4/6] avformat/realtextdec: UTF-16 support

2014-09-04 Thread wm4
Also remove ff_smil_extract_next_chunk - this was the last user of it.
---
No changes.
---
 libavformat/realtextdec.c | 17 ++---
 libavformat/subtitles.c   |  9 -
 libavformat/subtitles.h   |  5 -
 3 files changed, 10 insertions(+), 21 deletions(-)

diff --git a/libavformat/realtextdec.c b/libavformat/realtextdec.c
index e1225d5..19af108 100644
--- a/libavformat/realtextdec.c
+++ b/libavformat/realtextdec.c
@@ -37,11 +37,12 @@ typedef struct {
 
 static int realtext_probe(AVProbeData *p)
 {
-const unsigned char *ptr = p->buf;
+char buf[7];
+FFTextReader tr;
+ff_text_init_buf(&tr, p->buf, p->buf_size);
+ff_text_read(&tr, buf, sizeof(buf));
 
-if (AV_RB24(ptr) == 0xEFBBBF)
-ptr += 3;  /* skip UTF-8 BOM */
-return !av_strncasecmp(ptr, "pb);
 
 if (!st)
 return AVERROR(ENOMEM);
@@ -72,10 +75,10 @@ static int realtext_read_header(AVFormatContext *s)
 
 av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
 
-while (!avio_feof(s->pb)) {
+while (!ff_text_eof(&tr)) {
 AVPacket *sub;
-const int64_t pos = avio_tell(s->pb) - (c != 0);
-int n = ff_smil_extract_next_chunk(s->pb, &buf, &c);
+const int64_t pos = ff_text_pos(&tr) - (c != 0);
+int n = ff_smil_extract_next_text_chunk(&tr, &buf, &c);
 
 if (n == 0)
 break;
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index d650504..3069477 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -295,15 +295,6 @@ int ff_smil_extract_next_text_chunk(FFTextReader *tr, 
AVBPrint *buf, char *c)
 return i;
 }
 
-int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
-{
-FFTextReader tr;
-tr.buf_pos = tr.buf_len = 0;
-tr.type = 0;
-tr.pb = pb;
-return ff_smil_extract_next_text_chunk(&tr, buf, c);
-}
-
 const char *ff_smil_get_attr_ptr(const char *s, const char *attr)
 {
 int in_quotes = 0;
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index 3ef0bfc..b1608bf 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -147,11 +147,6 @@ void ff_subtitles_queue_clean(FFDemuxSubtitlesQueue *q);
  *
  * @param c cached character, to avoid a backward seek
  */
-int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c);
-
-/**
- * As ff_smil_extract_next_chunk(), but with FFTextReader.
- */
 int ff_smil_extract_next_text_chunk(FFTextReader *tr, AVBPrint *buf, char *c);
 
 /**
-- 
2.1.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2 1/6] avformat/assdec: UTF-16 support

2014-09-04 Thread wm4
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It also can work on a static buffer, needed for
format probing. The FFTextReader wrapper now also takes care of skipping
the UTF-8 BOM.
---
Now uses an enum for UTF types.
---
 libavformat/assdec.c| 19 +--
 libavformat/subtitles.c | 63 +
 libavformat/subtitles.h | 57 
 3 files changed, 132 insertions(+), 7 deletions(-)

diff --git a/libavformat/assdec.c b/libavformat/assdec.c
index bb953c7..a5f792a 100644
--- a/libavformat/assdec.c
+++ b/libavformat/assdec.c
@@ -33,10 +33,13 @@ typedef struct ASSContext {
 
 static int ass_probe(AVProbeData *p)
 {
-const char *header = "[Script Info]";
+char buf[13];
+FFTextReader tr;
+ff_text_init_buf(&tr, p->buf, p->buf_size);
 
-if (!memcmp(p->buf, header, strlen(header)) ||
-!memcmp(p->buf + 3, header, strlen(header)))
+ff_text_read(&tr, buf, sizeof(buf));
+
+if (!memcmp(buf, "[Script Info]", 13))
 return AVPROBE_SCORE_MAX;
 
 return 0;
@@ -66,13 +69,13 @@ static int read_ts(const uint8_t *p, int64_t *start, int 
*duration)
 return -1;
 }
 
-static int64_t get_line(AVBPrint *buf, AVIOContext *pb)
+static int64_t get_line(AVBPrint *buf, FFTextReader *tr)
 {
-int64_t pos = avio_tell(pb);
+int64_t pos = ff_text_pos(tr);
 
 av_bprint_clear(buf);
 for (;;) {
-char c = avio_r8(pb);
+char c = ff_text_r8(tr);
 if (!c)
 break;
 av_bprint_chars(buf, c, 1);
@@ -88,6 +91,8 @@ static int ass_read_header(AVFormatContext *s)
 AVBPrint header, line;
 int header_remaining, res = 0;
 AVStream *st;
+FFTextReader tr;
+ff_text_init_avio(&tr, s->pb);
 
 st = avformat_new_stream(s, NULL);
 if (!st)
@@ -102,7 +107,7 @@ static int ass_read_header(AVFormatContext *s)
 av_bprint_init(&line,   0, AV_BPRINT_SIZE_UNLIMITED);
 
 for (;;) {
-int64_t pos = get_line(&line, s->pb);
+int64_t pos = get_line(&line, &tr);
 
 if (!line.str[0]) // EOF
 break;
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index fce2bf1..cebd453 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -20,9 +20,72 @@
 
 #include "avformat.h"
 #include "subtitles.h"
+#include "avio_internal.h"
 #include "libavutil/avassert.h"
 #include "libavutil/avstring.h"
 
+void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
+{
+int i;
+r->pb = pb;
+r->buf_pos = r->buf_len = 0;
+r->type = FF_UTF_8;
+for (i = 0; i < 2; i++)
+r->buf[r->buf_len++] = avio_r8(r->pb);
+if (strncmp("\xFF\xFE", r->buf, 2) == 0) {
+r->type = FF_UTF16LE;
+r->buf_pos += 2;
+} else if (strncmp("\xFE\xFF", r->buf, 2) == 0) {
+r->type = FF_UTF16BE;
+r->buf_pos += 2;
+} else {
+r->buf[r->buf_len++] = avio_r8(r->pb);
+if (strncmp("\xEF\xBB\xBF", r->buf, 3) == 0) {
+// UTF8
+r->buf_pos += 3;
+}
+}
+}
+
+void ff_text_init_buf(FFTextReader *r, void *buf, size_t size)
+{
+memset(&r->buf_pb, 0, sizeof(r->buf_pb));
+ffio_init_context(&r->buf_pb, buf, size, 0, NULL, NULL, NULL, NULL);
+ff_text_init_avio(r, &r->buf_pb);
+}
+
+int64_t ff_text_pos(FFTextReader *r)
+{
+return avio_tell(r->pb) - r->buf_len + r->buf_pos;
+}
+
+int ff_text_r8(FFTextReader *r)
+{
+uint32_t val;
+uint8_t tmp;
+if (r->buf_pos < r->buf_len)
+return r->buf[r->buf_pos++];
+if (r->type == FF_UTF16LE) {
+GET_UTF16(val, avio_rl16(r->pb), return 0;)
+} else if (r->type == FF_UTF16BE) {
+GET_UTF16(val, avio_rb16(r->pb), return 0;)
+} else {
+return avio_r8(r->pb);
+}
+if (!val)
+return 0;
+r->buf_pos = 0;
+r->buf_len = 0;
+PUT_UTF8(val, tmp, r->buf[r->buf_len++] = tmp;)
+return r->buf[r->buf_pos++]; // buf_len is at least 1
+}
+
+void ff_text_read(FFTextReader *r, char *buf, size_t size)
+{
+for ( ; size > 0; size--)
+*buf++ = ff_text_r8(r);
+}
+
 AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue *q,
 const uint8_t *event, int len, int merge)
 {
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index b5a96ec..317e40a 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -30,6 +30,63 @@ enum sub_sort {
 SUB_SORT_POS_TS,///< sort by position, then timestamps
 };
 
+enum ff_utf_type {
+FF_UTF_8,   // or other 8 bit encodings
+FF_UTF16LE,
+FF_UTF16BE,
+};
+
+typedef struct {
+int type;
+AVIOContext *pb;
+unsigned char buf[8];
+int buf_pos, buf_len;
+AVIOContext buf_pb;
+} FFTextReader;
+
+/**
+ * Initialize the FFTextReader from the given AVIOContext. This function will
+ * read som

Re: [FFmpeg-devel] [PATCH] SSE2 version of vf_idet's filter_line()

2014-09-04 Thread Michael Niedermayer
On Wed, Sep 03, 2014 at 02:04:43PM -0700, Pascal Massimino wrote:
> Clément
> 
> On Wed, Sep 3, 2014 at 12:37 PM, Clément Bœsch  wrote:
> 
> > On Wed, Sep 03, 2014 at 07:05:48PM +0200, Pascal Massimino wrote:
> > [...]
> > > > > +punpcklbw m3, m_zero
> > > > > +punpckhbw m4, m_zero
> > > > > +
> > > > > +paddswm0, m3
> > > > > +paddswm1, m4
> > > > > +
> > > > > +movq  m3, [bq+indexq*1]
> > > > > +movq  m4, m3
> > > > > +punpcklbw m3, m_zero
> > > > > +punpckhbw m4, m_zero
> > > > > +
> > > > > +paddw m3, m3
> > > > > +paddw m4, m4
> > > > > +psubswm0, m3
> > > > > +psubswm1, m4
> > > > > +
> > > >
> > > > > +ABS1  m0, m5
> > > > > +ABS1  m1, m5
> > > >
> > > > ABS2?
> > > >
> > >
> > > ABS2 requires the two tmp registers to be different (can't use m5 for
> > both).
> > >
> >
> > Aren't m3 and m4 available at that point?
> >
> 
> Indeed. We can actually get rid of m5 use totally.
> 
> >
> > (ABS2 has the benefit of doing some pairing so is faster than doing two
> > ABS1)
> >
> > >
> > > >
> > > > > +paddw m0, m1
> > > > > +movq  m1, m0
> > > > > +punpcklwd m0, m_zero
> > > > > +punpckhwd m1, m_zero
> > > > > +paddd m0, m1
> > > > > +paddd m_sum, m0
> > > > > +
> > > > > +add   indexq, 0x8
> > > >
> > > > > +CMP   widthq, indexq
> > > >
> > > > Someone needs to confirm this, but I think you'll need to make width a
> > > > ptrdiff_t and not an int
> > > >
> > >
> > > changed to widthd/indexd, that's enough.
> > >
> >
> > Hopefully...
> >
> > >
> > > >
> > > > Also... stupid question but what's CMP?
> > > >
> > >
> > > it's equivalent to 'cmp DWORD' here iirc.
> > >
> >
> > I believe you can keep it lowercase. I thought it was a macro but didn't
> > see anything like this.
> >
> 
> In any case, it doesn't compile here with lowercase here (yasm 1.3.0).
> Not sure why. Any idea welcome...
> 
> 
> > >
> > >
> > [...]
> > > diff --git a/libavfilter/x86/vf_idet.asm b/libavfilter/x86/vf_idet.asm
> > > new file mode 100644
> > > index 000..19b7f3b
> > > --- /dev/null
> > > +++ b/libavfilter/x86/vf_idet.asm
> > > @@ -0,0 +1,116 @@
> > > +;;
> > *
> > > +;; * x86-optimized functions for idet filter
> > > +;; *
> > > +;; * This file is part of FFmpeg.
> > > +;; *
> > > +;; * FFmpeg is free software; you can redistribute it and/or modify
> > > +;; * it under the terms of the GNU General Public License as published
> > by
> > > +;; * the Free Software Foundation; either version 2 of the License, or
> > > +;; * (at your option) any later version.
> > > +;; *
> > > +;; * FFmpeg is distributed in the hope that it will be useful,
> > > +;; * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > +;; * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > +;; * GNU General Public License for more details.
> > > +;; *
> > > +;; * You should have received a copy of the GNU General Public License
> > along
> > > +;; * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> > > +;; * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > > +;;
> > **
> > > +
> > > +%include "libavutil/x86/x86util.asm"
> > > +
> > > +SECTION_TEXT
> > > +
> > > +; Implementation that does 8-bytes at a time using single-word
> > operations.
> > > +%macro IDET_FILTER_LINE 0
> >
> > > +cglobal idet_filter_line, 4, 8, 6, a, b, c, width, index
> >
> > Shouldn't this be 4,5,8? 4 args, 5 regs (4 args + 1 local var), 8 xmm
> > (m0..m7)
> 
> 
> > And BTW, you don't seem to use m2, so you can have 4,5,7 ; you probably
> > want to define m_zero on m2 to avoid any confusion.
> >
> 
> Actually, m5 m6 and m7 are now unused, so it's 4,5,6 now, eventually.
> 
> 
> > Now, this macro is only used for MMX, so you can probably do 4,5,0 (no XMM
> > reg). If you do 4,5,0, please move the INIT_MMX into the macro:
> >
> > %macro IDET_FILTER_LINE_MMX 1
> > INIT_MMX %1
> > ...
> > %end macro
> >
> 
> all done.
> 
> 
> >
> > ...
> >
> > INIT_MMX mmx
> > INIT_MMX mmxext
> >
> >
> > > +xor   indexq, indexq
> > > +%define   m_zero m7
> > > +%define   m_sum  m6
> > > +pxor  m_sum, m_sum
> > > +pxor  m_zero, m_zero
> > > +
> > > +.loop:
> > > +movu  m0, [aq+indexq*1]
> > > +punpckhbw m1, m0, m_zero
> > > +punpcklbw m0, m_zero
> > > +
> > > +movu  m3, [cq+indexq*1]
> > > +punpckhbw m4, m3, m_zero
> > > +punpcklbw m3, m_zero
> > > +
> > > +paddswm1, m4
> > > +paddswm0, m3
> > > +
> > > +movu  m3, [bq+indexq*1]
> > > +punpckhbw m4, m3, m_zero
> > > +punpcklbw m3, m_zero
> > > +
> > > +paddw m4, m4
> > > +paddw m3, m3
> > > +psubswm1, m4
> > > +psubswm0, m3
> > > +
> > > +ABS1  m1

[FFmpeg-devel] [PATCH] doc/filters.texi: fix time duration references

2014-09-04 Thread Mark Harris
Make time duration references consistent, using @ref links, and
eliminate incorrect syntax [-]HH[:MM[:SS[.m...]]].
---
 doc/filters.texi | 68 
 1 file changed, 29 insertions(+), 39 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4ae5b4f..d13278e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -517,27 +517,21 @@ volume as the input audio, at the end of the fade-out 
transition
 the output audio will be silence. Default is 44100.
 
 @item start_time, st
-Specify time for starting to apply the fade effect. Default is 0.
-The accepted syntax is:
-@example
-[-]HH[:MM[:SS[.m...]]]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
-If set this option is used instead of @var{start_sample} one.
+Specify the start time of the fade effect. Default is 0.
+The value must be specified as a time duration; see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
+If set this option is used instead of @var{start_sample}.
 
 @item duration, d
-Specify the duration for which the fade effect has to last. Default is 0.
-The accepted syntax is:
-@example
-[-]HH[:MM[:SS[.m...]]]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
+Specify the duration of the fade effect. See
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
 At the end of the fade-in effect the output audio will have the same
 volume as the input audio, at the end of the fade-out transition
 the output audio will be silence.
-If set this option is used instead of @var{nb_samples} one.
+By default the duration is determined by @var{nb_samples}.
+If set this option is used instead of @var{nb_samples}.
 
 @item curve
 Set curve for fade transition.
@@ -1120,9 +1114,9 @@ The number of the first sample that should be output.
 The number of the first sample that should be dropped.
 @end table
 
-@option{start}, @option{end}, @option{duration} are expressed as time
-duration specifications, check the "Time duration" section in the
-ffmpeg-utils manual.
+@option{start}, @option{end}, and @option{duration} are expressed as time
+duration specifications; see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}.
 
 Note that the first two sets of the start/end options and the @option{duration}
 option look at the frame timestamp, while the _sample options simply count the
@@ -1637,9 +1631,9 @@ Set the number of samples per channel per each output 
frame, default
 is 1024. Only used if plugin have zero inputs.
 
 @item duration, d
-Set the minimum duration of the sourced audio. See the function
-@code{av_parse_time()} for the accepted format, also check the "Time duration"
-section in the ffmpeg-utils manual.
+Set the minimum duration of the sourced audio. See
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
 Note that the resulting duration may be greater than the specified duration,
 as the generated audio is always cut at the end of a complete frame.
 If not specified, or the expressed duration is negative, the audio is
@@ -2189,8 +2183,9 @@ Set the channel layout. The number of channels in the 
specified layout
 must be equal to the number of specified expressions.
 
 @item duration, d
-Set the minimum duration of the sourced audio. See the function
-@code{av_parse_time()} for the accepted format.
+Set the minimum duration of the sourced audio. See
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
 Note that the resulting duration may be greater than the specified
 duration, as the generated audio is always cut at the end of a
 complete frame.
@@ -8546,9 +8541,10 @@ The number of the first frame that should be passed to 
the output.
 The number of the first frame that should be dropped.
 @end table
 
-@option{start}, @option{end}, @option{duration} are expressed as time
-duration specifications, check the "Time duration" section in the
-ffmpeg-utils manual.
+@option{start}, @option{end}, and @option{duration} are expressed as time
+duration specifications; see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
 
 Note that the first two sets of the start/end options and the @option{duration}
 option look at the frame timestamp, while the _frame variants simply count the
@@ -9459,12 +9455,9 @@ number or a valid video frame rate abbreviation. The 
default value is
 "25".
 
 @item duration, d
-Set the video duration of the sourced video. The accepted syntax is:
-@example
-[-]HH:MM:SS[.m...]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
+Set the duration of the sourced video. See
+@ref{time duration synta

Re: [FFmpeg-devel] [PATCH] doc/filters.texi: remove incorrect duration syntax

2014-09-04 Thread Mark Harris
Stefano Sabatini wrote:
> What about:
>
> Specify time for starting to apply the fade effect. Default is 0.
> The value must be specified as a time duration, see
> @ref{date syntax,,the Date section in the ffmpeg-utils(1) 
> manual,ffmpeg-utils}.
>
> Same below.

Ok, I am sending a new patch, replacing this one, to make all of the
time duration references consistent.

 - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: add ff_hevc_transform_add32_8_avx2

2014-09-04 Thread Michael Niedermayer
On Sun, Aug 31, 2014 at 11:46:13PM -0300, James Almer wrote:
> ~20% faster than AVX.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/x86/hevc_res_add.asm | 31 +++
>  libavcodec/x86/hevcdsp.h|  2 ++
>  libavcodec/x86/hevcdsp_init.c   |  2 ++
>  3 files changed, 31 insertions(+), 4 deletions(-)

LGTM

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Fix vf_cropdetect returning negative rectangles

2014-09-04 Thread Michael Niedermayer
On Tue, Sep 02, 2014 at 02:20:40PM -0700, hjiodjf 97xgw46 wrote:
> The cropdetect filter is prone to reporting negative-sized rectangles,
> particularly for dark images. This patch adjusts the limits of the
> filter loops, preventing the left/right and top/bottom offsets from
> crossing each other, so that such a zero-sized rectangle is reported
> instead of a negative one. This improves the reliability of using
> cropdetect to find a maximum bounding rectangle.

why would this improve the reliability of using the values ?

i think its mostly a question if when no rectangle is found
negative w/h is returned or 0,0 with a random x/y
i dont know which is better but this patch also reduces the amount
of computations in that case so i tend toward applying it


>  vf_cropdetect.c |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 07877d20186041d6ad44359d10c2c079ba954d06  
> 0001-Prevent-vf_cropdetect-from-returning-negative-rectan.patch
> From 971e0ec056e6200064598dbca49c18b8653e08d4 Mon Sep 17 00:00:00 2001
> From: tue46wsdgxfjrt 
> Date: Tue, 2 Sep 2014 13:57:45 -0700
> Subject: [PATCH] Prevent vf_cropdetect from returning negative rectangle
>  sizes.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 1/4] libavutil/error: fix build with musl toolchain

2014-09-04 Thread Jörg Krause


On 09/04/2014 05:24 PM, wm4 wrote:

On Thu, 04 Sep 2014 10:07:19 +0200
Jörg Krause  wrote:


On 09/03/2014 08:12 PM, Michael Niedermayer wrote:

On Wed, Sep 03, 2014 at 11:53:39AM +0200, Jörg Krause wrote:

Add the feature test macro which is required for building with the
musl toolchain.

The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
version of strerror_r().

Signed-off-by: Jörg Krause 
---
Changes v1 -> v2:
- fixed wrong macro name
- add a comment
---
   libavutil/error.c | 1 +
   1 file changed, 1 insertion(+)

applied

Many thanks! There are some more fixes necessary for supporting the musl
C library. I will prepare a series of patches in a couple of days. I
will follow the suggestion to add the feature test macros on source
level as described in the GNU C library reference manual.

I think I said this already, but there are people who have compiled
ffmpeg on musl without patches months ago...


You did. I already replied to your mail: 
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/162437.html. 
Did they set CPPFLAGS from command line?


Do you have some information about how they build it so I can reproduce it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add SUP (raw BluRay PGS subtitle) muxer

2014-09-04 Thread Reimar Döffinger
On Thu, Sep 04, 2014 at 10:19:05AM +0200, Hendrik Leppkes wrote:
> On Fri, Aug 29, 2014 at 12:31 PM, Petri Hintukainen  
> wrote:
> > +static int sup_write_packet(AVFormatContext *s, AVPacket *pkt)
> > +{
> > +/* header */
> > +avio_wb16(s->pb, SUP_PGS_MAGIC);
> > +avio_wb32(s->pb, (uint64_t)pkt->pts);
> > +avio_wb32(s->pb, (uint64_t)pkt->dts);
> > +
> 
> All the timestamp talk in the demuxer thread made me think about this part.
> What if no dts or pts is set (ie. its AV_NOPTS_VALUE), I doubt writing
> that as-is is going to fly over well with other tools (especially
> because its value is > 32-bit anyway)
> 
> Should you write 0? Should you write dts=pts if only pts is set, and
> dts is unset?

Others have given their opinion, but if you want to be
conservative you could just disallow this case and refuse to
mux such data.
At least if you have no examples to test such behaviour.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.

2014-09-04 Thread Dave Rice

On Sep 4, 2014, at 10:44 AM, Deron  wrote:

> On 9/4/14 8:06 AM, Roger Pack wrote:
>> Do you have some instructions on how to get the headers to make this
>> download work? Any links to some device to exercise the code, like on
>> amazon [cheaper better LOL].
>> 
> The DeckLink headers/sdk/libraries can be found at blackmagicdesign.com. The 
> last copy I downloaded was 
> http://software.blackmagicdesign.com/DesktopVideo/Blackmagic_Desktop_Video_Linux_10.1.1.tar.gz.
>  A more recent version may be available.

Yes 
http://software.blackmagicdesign.com/DesktopVideo/Blackmagic_Desktop_Video_Linux_10.1.4.tar.gz
 is available.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add SUP (raw BluRay PGS subtitle) muxer

2014-09-04 Thread wm4
On Thu, 04 Sep 2014 15:24:52 +0300
Petri Hintukainen  wrote:

> On to, 2014-09-04 at 10:19 +0200, Hendrik Leppkes wrote:
> > On Fri, Aug 29, 2014 at 12:31 PM, Petri Hintukainen  
> > wrote:
> > > From: Petri Hintukainen 
> > >
> > > Fixes ticket #2208
> > > ---
> > >  libavformat/Makefile |  1 +
> > >  libavformat/allformats.c |  1 +
> > >  libavformat/supenc.c | 61 
> > > 
> > >  3 files changed, 63 insertions(+)
> > >  create mode 100644 libavformat/supenc.c
> > >
> > > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > > index 3d124fb..e3cc653 100644
> > > --- a/libavformat/Makefile
> > > +++ b/libavformat/Makefile
> > > @@ -405,6 +405,7 @@ OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
> > >  OBJS-$(CONFIG_STR_DEMUXER)   += psxstr.o
> > >  OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
> > >  OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
> > > +OBJS-$(CONFIG_SUP_MUXER) += supenc.o
> > >  OBJS-$(CONFIG_SWF_DEMUXER)   += swfdec.o swf.o
> > >  OBJS-$(CONFIG_SWF_MUXER) += swfenc.o swf.o
> > >  OBJS-$(CONFIG_TAK_DEMUXER)   += takdec.o apetag.o img2.o 
> > > rawdec.o
> > > diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> > > index 8f70c4b..a1a55f7 100644
> > > --- a/libavformat/allformats.c
> > > +++ b/libavformat/allformats.c
> > > @@ -280,6 +280,7 @@ void av_register_all(void)
> > >  REGISTER_DEMUXER (STR,  str);
> > >  REGISTER_DEMUXER (SUBVIEWER1,   subviewer1);
> > >  REGISTER_DEMUXER (SUBVIEWER,subviewer);
> > > +REGISTER_MUXER   (SUP,  sup);
> > >  REGISTER_MUXDEMUX(SWF,  swf);
> > >  REGISTER_DEMUXER (TAK,  tak);
> > >  REGISTER_MUXER   (TEE,  tee);
> > > diff --git a/libavformat/supenc.c b/libavformat/supenc.c
> > > new file mode 100644
> > > index 000..3447f76
> > > --- /dev/null
> > > +++ b/libavformat/supenc.c
> > > @@ -0,0 +1,61 @@
> > > +/*
> > > + * SUP muxer
> > > + * Copyright (c) 2014 Petri Hintukainen 
> > > + *
> > > + * This file is part of FFmpeg.
> > > + *
> > > + * FFmpeg is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU Lesser General Public
> > > + * License as published by the Free Software Foundation; either
> > > + * version 2.1 of the License, or (at your option) any later version.
> > > + *
> > > + * FFmpeg is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > + * Lesser General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU Lesser General Public
> > > + * License along with FFmpeg; if not, write to the Free Software
> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > > 02110-1301 USA
> > > + */
> > > +
> > > +#include "avformat.h"
> > > +#include "internal.h"
> > > +
> > > +
> > > +#define SUP_PGS_MAGIC 0x5047 /* "PG", big endian */
> > > +
> > > +static int sup_write_packet(AVFormatContext *s, AVPacket *pkt)
> > > +{
> > > +/* header */
> > > +avio_wb16(s->pb, SUP_PGS_MAGIC);
> > > +avio_wb32(s->pb, (uint64_t)pkt->pts);
> > > +avio_wb32(s->pb, (uint64_t)pkt->dts);
> > > +
> > 
> > All the timestamp talk in the demuxer thread made me think about this part.
> > What if no dts or pts is set (ie. its AV_NOPTS_VALUE), I doubt writing
> > that as-is is going to fly over well with other tools (especially
> > because its value is > 32-bit anyway)
> >
> >Should you write 0?
>  
> It writes only 32 lowest bits, so AV_NOPTS_VALUE is written as 0.
> 
> Also looks like cast to uint64_t is not necessary ?

Maybe it would be nicer to do this explicitly? It's also conceivable
that AV_NOPTS_VALUE could change its representation in the far future
(although unlikely).

> If timestamp does not fit to 32 bits, highest bits are dropped when
> converting to 32 bits. I don't see any better way to handle this, the
> format can only store 32 bits.
> 
> I'm more worried with the possibility that ffmpeg may modify the
> timestamps (like, to start from 0). I noticed that if I demux only
> single PGS stream from .m2ts, timestamps have different starting point
> than if I demux also the video track. This requires extra work when
> syncing subtitles with the video (sync is lost).
> 
> Now, I don't know if the timestamps in .sup should be the original
> timestamps from .m2ts, or re-positioned so that start of the movie is at
> 0. Probably other tools expect it to start from 0, automatic conversions
> between formats would be difficult otherwise (PGS streams are sparse,
> and start time of the stream is not stored in .sup file). Also those
> eac3to samples seem to confirm this.
> If this is true, I'm not very worried abo

Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Michael Niedermayer
On Thu, Sep 04, 2014 at 05:23:12PM +0200, wm4 wrote:
> On Thu, 4 Sep 2014 16:30:14 +0200
> Michael Niedermayer  wrote:
> 
> > On Thu, Sep 04, 2014 at 03:53:55PM +0200, wm4 wrote:
> > > On Wed, 3 Sep 2014 23:33:48 -0400
> > > Reinhard Tartler  wrote:
[...]
> > 
> > Iam not saying iam against it, just that it seems very strange to me
> > 
> > If people want we could revive libpostproc.git, it just seemed easier
> > to me if people use libpostproc from FFmpeg
> > 
> > [...]
> 
> Feel free to create your own separate libpostproc git repo based on
> ffmpeg.

If people are happy with libpostproc.git as it is, i surely can try to
remember to cherry pick changes into it, but i dont know how to
test it beyond build testing, also i dont volunteer to work on commits
which dont apply cleanly or dont work when applied

ATM, theres some version.h related commit that doesnt apply, that
would need to be ported

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 1/4] libavutil/error: fix build with musl toolchain

2014-09-04 Thread wm4
On Thu, 4 Sep 2014 17:27:48 +0200
Hendrik Leppkes  wrote:

> On Wed, Sep 3, 2014 at 11:53 AM, Jörg Krause  wrote:
> > Add the feature test macro which is required for building with the
> > musl toolchain.
> >
> > The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
> > version of strerror_r().
> >
> > Signed-off-by: Jörg Krause 
> > ---
> > Changes v1 -> v2:
> >   - fixed wrong macro name
> >   - add a comment
> > ---
> >  libavutil/error.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavutil/error.c b/libavutil/error.c
> > index bd66354..dd1fb30 100644
> > --- a/libavutil/error.c
> > +++ b/libavutil/error.c
> > @@ -17,6 +17,7 @@
> >   */
> >
> >  #undef _GNU_SOURCE
> > +#define _XOPEN_SOURCE 600 /* XSI-compliant version of strerror_r */
> >  #include "avutil.h"
> >  #include "avstring.h"
> >  #include "common.h"
> > --
> > 2.1.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
>  _XOPEN_SOURCE 600 is set as a compiler parameter for all other
> toolchains that need it, including glibc and whatnot.
> We should really do the same for musl here, using special treatment is weird.
> 
> Detect musl in configure, add a new libc block, set
> -D_XOPEN_SOURCE=600 in the cflags, and it would be consistent with
> everything else.

musl makes itself undetectable to prevent exactly that:
http://openwall.com/lists/musl/2013/03/29/13
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v3] ffprobe: Add bits_per_component to stream output

2014-09-04 Thread wm4
On Thu, 04 Sep 2014 16:31:45 +0200
Tobias Rapp  wrote:

> From 4a2290540ae0761c6ea2a5f12326ad8dd1257e57 Mon Sep 17 00:00:00 2001
> From: Tobias Rapp 
> Date: Thu, 4 Sep 2014 16:25:22 +0200
> Subject: [PATCH] ffprobe: Add bits_per_component to stream output
> 
> Adds bits_per_component (bit depth) output for video streams.
> ---
>  doc/ffprobe.xsd|  1 +
>  ffprobe.c  |  6 ++
>  libavutil/pixdesc.c| 15 +++
>  libavutil/pixdesc.h|  7 +++
>  tests/ref/fate/ffprobe_compact |  4 ++--
>  tests/ref/fate/ffprobe_csv |  4 ++--
>  tests/ref/fate/ffprobe_default |  2 ++
>  tests/ref/fate/ffprobe_flat|  2 ++
>  tests/ref/fate/ffprobe_ini |  2 ++
>  tests/ref/fate/ffprobe_json|  2 ++
>  tests/ref/fate/ffprobe_xml |  4 ++--
>  11 files changed, 43 insertions(+), 6 deletions(-)
> 



> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index 154392a..1dfcf0f 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -1980,6 +1980,21 @@ int av_get_padded_bits_per_pixel(const 
> AVPixFmtDescriptor *pixdesc)
>  return bits >> log2_pixels;
>  }
>  
> +int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc)
> +{
> +int c, bits, first_bits = 0;
> +
> +for (c = 0; c < pixdesc->nb_components; c++) {
> +bits = pixdesc->comp[c].depth_minus1 + 1;
> +if (c == 0)
> +first_bits = bits;
> +else if (bits != first_bits)
> +return 0;
> +}
> +
> +return first_bits;
> +}
> +
>  char *av_get_pix_fmt_string(char *buf, int buf_size,
>  enum AVPixelFormat pix_fmt)
>  {
> diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
> index 41e81db..f8af18f 100644
> --- a/libavutil/pixdesc.h
> +++ b/libavutil/pixdesc.h
> @@ -251,6 +251,13 @@ int av_get_bits_per_pixel(const AVPixFmtDescriptor 
> *pixdesc);
>  int av_get_padded_bits_per_pixel(const AVPixFmtDescriptor *pixdesc);
>  
>  /**
> + * Return the number of bits per component (bit depth) for the pixel format
> + * described by pixdesc or 0 if the pixel format has unknown or non-uniform
> + * bit depth.
> + */
> +int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc);
> +
> +/**
>   * @return a pixel format descriptor for provided pixel format or NULL if
>   * this pixel format is unknown.
>   */


Does something such highly specialized really warrant its own API
function? There are several ways how to handle the case if the
component bit depths are not uniform, or even how the term "bit depth"
is to be interpreted, so IMO this should just be internal to ffprobe.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 1/4] libavutil/error: fix build with musl toolchain

2014-09-04 Thread Hendrik Leppkes
On Wed, Sep 3, 2014 at 11:53 AM, Jörg Krause  wrote:
> Add the feature test macro which is required for building with the
> musl toolchain.
>
> The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
> version of strerror_r().
>
> Signed-off-by: Jörg Krause 
> ---
> Changes v1 -> v2:
>   - fixed wrong macro name
>   - add a comment
> ---
>  libavutil/error.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/error.c b/libavutil/error.c
> index bd66354..dd1fb30 100644
> --- a/libavutil/error.c
> +++ b/libavutil/error.c
> @@ -17,6 +17,7 @@
>   */
>
>  #undef _GNU_SOURCE
> +#define _XOPEN_SOURCE 600 /* XSI-compliant version of strerror_r */
>  #include "avutil.h"
>  #include "avstring.h"
>  #include "common.h"
> --
> 2.1.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

 _XOPEN_SOURCE 600 is set as a compiler parameter for all other
toolchains that need it, including glibc and whatnot.
We should really do the same for musl here, using special treatment is weird.

Detect musl in configure, add a new libc block, set
-D_XOPEN_SOURCE=600 in the cflags, and it would be consistent with
everything else.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 1/4] libavutil/error: fix build with musl toolchain

2014-09-04 Thread wm4
On Thu, 04 Sep 2014 10:07:19 +0200
Jörg Krause  wrote:

> 
> On 09/03/2014 08:12 PM, Michael Niedermayer wrote:
> > On Wed, Sep 03, 2014 at 11:53:39AM +0200, Jörg Krause wrote:
> >> Add the feature test macro which is required for building with the
> >> musl toolchain.
> >>
> >> The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
> >> version of strerror_r().
> >>
> >> Signed-off-by: Jörg Krause 
> >> ---
> >> Changes v1 -> v2:
> >>- fixed wrong macro name
> >>- add a comment
> >> ---
> >>   libavutil/error.c | 1 +
> >>   1 file changed, 1 insertion(+)
> > applied
> 
> Many thanks! There are some more fixes necessary for supporting the musl 
> C library. I will prepare a series of patches in a couple of days. I 
> will follow the suggestion to add the feature test macros on source 
> level as described in the GNU C library reference manual.

I think I said this already, but there are people who have compiled
ffmpeg on musl without patches months ago...

> > btw, if you are interrested in setting up a musl fate client to
> > regularly test ffmpeg, see http://ffmpeg.org/fate.html
> 
> Interesting, I will give it a try.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread wm4
On Thu, 4 Sep 2014 16:30:14 +0200
Michael Niedermayer  wrote:

> On Thu, Sep 04, 2014 at 03:53:55PM +0200, wm4 wrote:
> > On Wed, 3 Sep 2014 23:33:48 -0400
> > Reinhard Tartler  wrote:
> > 
> > > On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer  
> > > wrote:
> > > > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
> > > >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer  
> > > >> wrote:
> > > >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
> > > >> >> Hi,
> > > >> >>
> > > >> >> as discussed in IRC, I was trying to minimal-invasively port
> > > >> >> libpostproc (the Debian source package) to x32¹. I could not
> > > >> >> test it (for lack of a stand-alone test program) yet, but at
> > > >> >> least I got it to build.
> > > >> >
> > > >> > you could try to test by buiding ffmpeg as a whole but disable asm
> > > >> > everywhere except libpostproc
> > > >> > that might allow "easy" testing though fate or ffmpeg with 
> > > >> > libavfilter
> > > >>
> > > >> Is http://git.videolan.org/?p=libpostproc.git still maintained?
> > > >
> > > > AFAIK, no, it seems the last commit is 2 years ago
> > > >
> > > >
> > > >>
> > > >> The Debian package tracks that repository, and ideally we could
> > > >> collect the postproc patches there.
> > > >
> > > > libpostproc was and is maintained in
> > > > git://source.ffmpeg.org/ffmpeg.git
> > > 
> > > So the promise given in
> > > https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
> > > doesn't hold anymore?
> > > 
> > > Any chance to make you reconsider reviving the standalone libpostproc.git?
> > 
> > Yes, let me add my protest against this bullshit of still maintaining
> > libpostproc as part of ffmpeg.git in FFmpeg.
> 
> Can you elaborate / explain why 14496-2 Part 2: Visual Annex F.3
> "Postprocessing for Coding Noise Reduction"
> (which is about half of what libpostproc is)
> 
> Aka a part of the implementation of the MPEG4 ASP video specification
> is insane to maintain in the same git repository as the
> MPEG4 ASP video decoder and encoder ?

Even if it somehow implements part of that spec, the decoders don't
actually use libpostproc. I don't know anyone except you and maybe some
MPlayer+FFmpeg devs who consider libpostproc an important component.

And in general, it's a good idea to move optional libraries out of
ffmpeg.git. (In fact, ffmpeg.git should be split into several git
repos, one for each lib.)

> 
> Iam not saying iam against it, just that it seems very strange to me
> 
> If people want we could revive libpostproc.git, it just seemed easier
> to me if people use libpostproc from FFmpeg
> 
> [...]

Feel free to create your own separate libpostproc git repo based on
ffmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Derek Buitenhuis
On 9/4/2014 4:33 AM, Reinhard Tartler wrote:
> So the promise given in
> https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
> doesn't hold anymore?
> 
> Any chance to make you reconsider reviving the standalone libpostproc.git?

Guilty party here.

I kinda just neglected it because 0 people care about.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.

2014-09-04 Thread Deron

On 9/4/14 8:06 AM, Roger Pack wrote:

Do you have some instructions on how to get the headers to make this
download work? Any links to some device to exercise the code, like on
amazon [cheaper better LOL].

The DeckLink headers/sdk/libraries can be found at blackmagicdesign.com. 
The last copy I downloaded was 
http://software.blackmagicdesign.com/DesktopVideo/Blackmagic_Desktop_Video_Linux_10.1.1.tar.gz. 
A more recent version may be available. If you are using this on a 
desktop installation it should be pretty easy to install, but if you are 
installing this on a headless remote server like I do you will have more 
difficulty. Especially if you could not find the SDK to begin with.


What I did to test capture capabilities was use two decklink devices and 
connect them together. To test output, I happen to have an HD-SDI 
capable monitor. Good luck, I've not had any luck with the "official" 
ffmpeg decklink driver.


Deron

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v3] ffprobe: Add bits_per_component to stream output

2014-09-04 Thread Tobias Rapp

On 04.09.2014 15:38, Dave Rice wrote:

Attached patch adds bits_per_component (bit depth) output for video streams.


Adding an element to the ffprobe output requires a change to ffprobe.xsd as 
well.


Indeed. Attached patch version 3 now includes the update to ffprobe.xsd.

Regards,
Tobias
>From 4a2290540ae0761c6ea2a5f12326ad8dd1257e57 Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Thu, 4 Sep 2014 16:25:22 +0200
Subject: [PATCH] ffprobe: Add bits_per_component to stream output

Adds bits_per_component (bit depth) output for video streams.
---
 doc/ffprobe.xsd|  1 +
 ffprobe.c  |  6 ++
 libavutil/pixdesc.c| 15 +++
 libavutil/pixdesc.h|  7 +++
 tests/ref/fate/ffprobe_compact |  4 ++--
 tests/ref/fate/ffprobe_csv |  4 ++--
 tests/ref/fate/ffprobe_default |  2 ++
 tests/ref/fate/ffprobe_flat|  2 ++
 tests/ref/fate/ffprobe_ini |  2 ++
 tests/ref/fate/ffprobe_json|  2 ++
 tests/ref/fate/ffprobe_xml |  4 ++--
 11 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index 32afa62..27a5118 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -163,6 +163,7 @@
   
   
   
+  
   
   
   
diff --git a/ffprobe.c b/ffprobe.c
index 2d48070..9b0a87d 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2031,6 +2031,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 AVRational sar, dar;
 AVBPrint pbuf;
 const AVCodecDescriptor *cd;
+const AVPixFmtDescriptor *pix_desc;
 int ret = 0;
 
 av_bprint_init(&pbuf, 1, AV_BPRINT_SIZE_UNLIMITED);
@@ -2096,6 +2097,11 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 s = av_get_pix_fmt_name(dec_ctx->pix_fmt);
 if (s) print_str("pix_fmt", s);
 else   print_str_opt("pix_fmt", "unknown");
+pix_desc = av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+if (pix_desc)
+print_int("bits_per_component", 
av_get_bits_per_component(pix_desc));
+else
+print_str_opt("bits_per_component", "N/A");
 print_int("level",   dec_ctx->level);
 if (dec_ctx->color_range != AVCOL_RANGE_UNSPECIFIED)
 print_str("color_range", dec_ctx->color_range == 
AVCOL_RANGE_MPEG ? "tv": "pc");
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 154392a..1dfcf0f 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1980,6 +1980,21 @@ int av_get_padded_bits_per_pixel(const 
AVPixFmtDescriptor *pixdesc)
 return bits >> log2_pixels;
 }
 
+int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc)
+{
+int c, bits, first_bits = 0;
+
+for (c = 0; c < pixdesc->nb_components; c++) {
+bits = pixdesc->comp[c].depth_minus1 + 1;
+if (c == 0)
+first_bits = bits;
+else if (bits != first_bits)
+return 0;
+}
+
+return first_bits;
+}
+
 char *av_get_pix_fmt_string(char *buf, int buf_size,
 enum AVPixelFormat pix_fmt)
 {
diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
index 41e81db..f8af18f 100644
--- a/libavutil/pixdesc.h
+++ b/libavutil/pixdesc.h
@@ -251,6 +251,13 @@ int av_get_bits_per_pixel(const AVPixFmtDescriptor 
*pixdesc);
 int av_get_padded_bits_per_pixel(const AVPixFmtDescriptor *pixdesc);
 
 /**
+ * Return the number of bits per component (bit depth) for the pixel format
+ * described by pixdesc or 0 if the pixel format has unknown or non-uniform
+ * bit depth.
+ */
+int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc);
+
+/**
  * @return a pixel format descriptor for provided pixel format or NULL if
  * this pixel format is unknown.
  */
diff --git a/tests/ref/fate/ffprobe_compact b/tests/ref/fate/ffprobe_compact
index ad646af..0863b6f 100644
--- a/tests/ref/fate/ffprobe_compact
+++ b/tests/ref/fate/ffprobe_compact
@@ -27,6 +27,6 @@ 
frame|media_type=video|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12|pkt_dts=61
 
packet|codec_type=video|stream_index=2|pts=6144|pts_time=0.12|dts=6144|dts_time=0.12|duration=2048|duration_time=0.04|convergence_duration=N/A|convergence_duration_time=N/A|size=3|pos=1024801|flags=K
 
frame|media_type=video|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12|pkt_dts=6144|pkt_dts_time=0.12|best_effort_timestamp=6144|best_effort_timestamp_time=0.12|pkt_duration=2048|pkt_duration_time=0.04|pkt_pos=1024801|pkt_size=3|width=100|height=100|pix_fmt=rgb24|sample_aspect_ratio=1:1|pict_type=I|coded_picture_number=0|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0
 
stream|index=0|codec_name=pcm_s16le|profile=unknown|codec_type=audio|codec_time_base=1/44100|codec_tag_string=PSD[16]|codec_tag=0x10445350|sample_fmt=s16|sample_rate=44100|channels=1|channel_layout=unknown|bits_per_sample=16|id=N/A|r_frame_rate=0/0|avg_frame_rat

Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Michael Niedermayer
On Thu, Sep 04, 2014 at 03:53:55PM +0200, wm4 wrote:
> On Wed, 3 Sep 2014 23:33:48 -0400
> Reinhard Tartler  wrote:
> 
> > On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer  
> > wrote:
> > > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
> > >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer  
> > >> wrote:
> > >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
> > >> >> Hi,
> > >> >>
> > >> >> as discussed in IRC, I was trying to minimal-invasively port
> > >> >> libpostproc (the Debian source package) to x32¹. I could not
> > >> >> test it (for lack of a stand-alone test program) yet, but at
> > >> >> least I got it to build.
> > >> >
> > >> > you could try to test by buiding ffmpeg as a whole but disable asm
> > >> > everywhere except libpostproc
> > >> > that might allow "easy" testing though fate or ffmpeg with libavfilter
> > >>
> > >> Is http://git.videolan.org/?p=libpostproc.git still maintained?
> > >
> > > AFAIK, no, it seems the last commit is 2 years ago
> > >
> > >
> > >>
> > >> The Debian package tracks that repository, and ideally we could
> > >> collect the postproc patches there.
> > >
> > > libpostproc was and is maintained in
> > > git://source.ffmpeg.org/ffmpeg.git
> > 
> > So the promise given in
> > https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
> > doesn't hold anymore?
> > 
> > Any chance to make you reconsider reviving the standalone libpostproc.git?
> 
> Yes, let me add my protest against this bullshit of still maintaining
> libpostproc as part of ffmpeg.git in FFmpeg.

Can you elaborate / explain why 14496-2 Part 2: Visual Annex F.3
"Postprocessing for Coding Noise Reduction"
(which is about half of what libpostproc is)

Aka a part of the implementation of the MPEG4 ASP video specification
is insane to maintain in the same git repository as the
MPEG4 ASP video decoder and encoder ?

Iam not saying iam against it, just that it seems very strange to me

If people want we could revive libpostproc.git, it just seemed easier
to me if people use libpostproc from FFmpeg

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.

2014-09-04 Thread Roger Pack
Do you have some instructions on how to get the headers to make this
download work? Any links to some device to exercise the code, like on
amazon [cheaper better LOL].


On Tue, Sep 2, 2014 at 3:26 AM, Deti Fliegl  wrote:

> On 30.08.14 01:22, Michael Niedermayer wrote:
>
>> moving code from (like from decklink_enc.cpp to decklink_common.cpp)
>> should be in a seperate patch
>>
> Done. Both patches are attached to this mail.
>
>
>  If you want to maintain this code, please add yourself to the
>> MAINTAINERs file
>>
> Added.
>
>
>  non static functions should have a ff_ prefix (or av if they are
>> public but that isnt)
>>
> Done, except for CreateDeckLinkIteratorInstance which is a function that
> is part of the DeckLink Mac OS X & Linux API and which is not available
> under Windows. So it has to be recoded to enable code sharing between Mac
> OS X, Linux and Windows.
>
>
>  also i dont really know windows & decklink stuff, so iam not the
>> ideal one to review ...
>>
> Well basically it all should be the same. It compiles and works under
> Windows too, but most people would use the direct show input support of
> ffmpeg for capturing from a DeckLink device.
>
> Deti
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

2014-09-04 Thread Michael Niedermayer
On Thu, Sep 04, 2014 at 03:36:03PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 03, 2014 at 07:30:49PM +0200, Michael Niedermayer wrote:
> > On Thu, Aug 28, 2014 at 01:28:18PM +0200, Andreas Cadhalpun wrote:
> > > On 28.08.2014 04:36, Michael Niedermayer wrote:
> > > >On Wed, Aug 27, 2014 at 05:21:18PM -0800, Lou Logan wrote:
> > > >>On Tue, 26 Aug 2014 13:41:42 +0200, Michael Niedermayer wrote:
> > > >>
> > > >>>Signed-off-by: Michael Niedermayer 
> > > >>>---
> > > >>>  tests/Makefile |5 -
> > > >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >>>
> > > >>>diff --git a/tests/Makefile b/tests/Makefile
> > > >>>index 07557f9..2f095df 100644
> > > >>>--- a/tests/Makefile
> > > >>>+++ b/tests/Makefile
> > > >>>@@ -24,13 +24,16 @@ $(VREF): tests/videogen$(HOSTEXESUF) | 
> > > >>>tests/vsynth1
> > > >>>  $(AREF): tests/audiogen$(HOSTEXESUF) | tests/data
> > > >>>   $(M)./$< $@
> > > >>>
> > > >>>+$(SRC_PATH)/tests/lena.pnm:
> > > >>>+  wget -O $@  http://samples.ffmpeg.org/image-samples/lena.pnm
> > > >>
> > > >>I feel like I'm missing something, but what about this suggestion from
> > > >>Nicolas?
> > > >>
> > > ffmpeg -f data -i http://samples.ffmpeg.org/image-samples/lena.pnm -c 
> > > copy -f data -map 0 -y lena.pnm
> > > >>
> > > >>From:
> > > >>
> > > >
> > > >possible
> > > >
> > > >but would this make andreas / debian happy ?
> > > 
> > > No.
> > > 
> > > >IIRC theres no net access from the build deamons and andreas wants
> > > >to run the subset of tests that dont need fate samples or at least
> > > >thats how i understood it ...
> > > >andreas, please correct me if iam wrong
> > > 
> > > That's correct.
> > > But I'm fine with moving lena.pnm to the FATE samples, which are
> > > downloaded with 'make fate-rsync'.
> > > Attached patch removes tests/lena.pnm and adapts the tests, assuming
> > > lena.pnm would be added to the top-level of the SAMPLES directory.
> > 
> > in absence of better ideas ill apply this patch soon
> 
> no other ideas it seems ...
> applied

also note, we can improve on top of this solution if people have
ideas / patches

i just didnt want to leave a potentially LGPL incompatible file
in git master even if its de facto free to use and distribute for
what we use it for

IANAL

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread wm4
On Wed, 3 Sep 2014 23:33:48 -0400
Reinhard Tartler  wrote:

> On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer  wrote:
> > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
> >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer  
> >> wrote:
> >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
> >> >> Hi,
> >> >>
> >> >> as discussed in IRC, I was trying to minimal-invasively port
> >> >> libpostproc (the Debian source package) to x32¹. I could not
> >> >> test it (for lack of a stand-alone test program) yet, but at
> >> >> least I got it to build.
> >> >
> >> > you could try to test by buiding ffmpeg as a whole but disable asm
> >> > everywhere except libpostproc
> >> > that might allow "easy" testing though fate or ffmpeg with libavfilter
> >>
> >> Is http://git.videolan.org/?p=libpostproc.git still maintained?
> >
> > AFAIK, no, it seems the last commit is 2 years ago
> >
> >
> >>
> >> The Debian package tracks that repository, and ideally we could
> >> collect the postproc patches there.
> >
> > libpostproc was and is maintained in
> > git://source.ffmpeg.org/ffmpeg.git
> 
> So the promise given in
> https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
> doesn't hold anymore?
> 
> Any chance to make you reconsider reviving the standalone libpostproc.git?

Yes, let me add my protest against this bullshit of still maintaining
libpostproc as part of ffmpeg.git in FFmpeg.

> > please use that for the debian package
> 
> I fear that's not feasible at this point.
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] ffprobe: Add bits_per_component to stream output

2014-09-04 Thread Dave Rice

On Sep 4, 2014, at 8:39 AM, Tobias Rapp  wrote:

> Attached patch adds bits_per_component (bit depth) output for video streams.

Adding an element to the ffprobe output requires a change to ffprobe.xsd as 
well.
Dave Rice

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

2014-09-04 Thread Michael Niedermayer
On Wed, Sep 03, 2014 at 07:30:49PM +0200, Michael Niedermayer wrote:
> On Thu, Aug 28, 2014 at 01:28:18PM +0200, Andreas Cadhalpun wrote:
> > On 28.08.2014 04:36, Michael Niedermayer wrote:
> > >On Wed, Aug 27, 2014 at 05:21:18PM -0800, Lou Logan wrote:
> > >>On Tue, 26 Aug 2014 13:41:42 +0200, Michael Niedermayer wrote:
> > >>
> > >>>Signed-off-by: Michael Niedermayer 
> > >>>---
> > >>>  tests/Makefile |5 -
> > >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > >>>
> > >>>diff --git a/tests/Makefile b/tests/Makefile
> > >>>index 07557f9..2f095df 100644
> > >>>--- a/tests/Makefile
> > >>>+++ b/tests/Makefile
> > >>>@@ -24,13 +24,16 @@ $(VREF): tests/videogen$(HOSTEXESUF) | tests/vsynth1
> > >>>  $(AREF): tests/audiogen$(HOSTEXESUF) | tests/data
> > >>> $(M)./$< $@
> > >>>
> > >>>+$(SRC_PATH)/tests/lena.pnm:
> > >>>+wget -O $@  http://samples.ffmpeg.org/image-samples/lena.pnm
> > >>
> > >>I feel like I'm missing something, but what about this suggestion from
> > >>Nicolas?
> > >>
> > ffmpeg -f data -i http://samples.ffmpeg.org/image-samples/lena.pnm -c 
> > copy -f data -map 0 -y lena.pnm
> > >>
> > >>From:
> > >>
> > >
> > >possible
> > >
> > >but would this make andreas / debian happy ?
> > 
> > No.
> > 
> > >IIRC theres no net access from the build deamons and andreas wants
> > >to run the subset of tests that dont need fate samples or at least
> > >thats how i understood it ...
> > >andreas, please correct me if iam wrong
> > 
> > That's correct.
> > But I'm fine with moving lena.pnm to the FATE samples, which are
> > downloaded with 'make fate-rsync'.
> > Attached patch removes tests/lena.pnm and adapts the tests, assuming
> > lena.pnm would be added to the top-level of the SAMPLES directory.
> 
> in absence of better ideas ill apply this patch soon

no other ideas it seems ...
applied

thanks

> 
> we can still add another image later if wanted
> 
> 
> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]refine the flv tagtype read for check as spec

2014-09-04 Thread Michael Niedermayer
On Thu, Sep 04, 2014 at 08:23:19PM +0800, Steven Liu wrote:
> from the flv spec, the flvtag define the tagtype as one byte,
> the spec desc is:
> Reserved  UB[2] Reserved for FMS, should be 0
> FilterUB[1] Indicates if packets are filtered.
> 0 = No pre-processing required.
> 1 = Pre-processing (such as decryption) of the packet is
> required before it can be rendered.
> Shall be 0 in unencrypted files, and 1 for encrypted
> tags.
> See Annex F. FLV Encryption for the use of filters.
> TagType   UB[5] Type of contents in this tag. The following types are
> defined:
> 8 = audio
> 9 = video
> 18 = script data
> 
> Signed-off-by: Steven Liu 
> ---
>  libavformat/flvdec.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 8d9ed8b..a0550b4 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -777,7 +777,7 @@ static int flv_read_packet(
> AVFormatContext *s, AVPacket *pkt)
>  /* pkt size is repeated at end. skip it */
>  for (;; avio_skip(s->pb, 4)) {
>  pos  = avio_tell(s->pb);
> -type = avio_r8(s->pb);
> +type = (avio_r8(s->pb) & 0x1F);
>  size = avio_rb24(s->pb);
>  dts  = avio_rb24(s->pb);
>  dts |= avio_r8(s->pb) << 24;

patch applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2] ffprobe: Add bits_per_component to stream output

2014-09-04 Thread Tobias Rapp
Previous patch did contain an obsolete line in function 
av_get_bits_per_component. New patch file attached.


Regards,
Tobias
>From 2271a50358e9d464dd53ed9936581e11b28e5940 Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Thu, 4 Sep 2014 14:47:14 +0200
Subject: [PATCH] ffprobe: Add bits_per_component to stream output

Adds bits_per_component (bit depth) output for video streams.
---
 ffprobe.c  |  6 ++
 libavutil/pixdesc.c| 15 +++
 libavutil/pixdesc.h|  7 +++
 tests/ref/fate/ffprobe_compact |  4 ++--
 tests/ref/fate/ffprobe_csv |  4 ++--
 tests/ref/fate/ffprobe_default |  2 ++
 tests/ref/fate/ffprobe_flat|  2 ++
 tests/ref/fate/ffprobe_ini |  2 ++
 tests/ref/fate/ffprobe_json|  2 ++
 tests/ref/fate/ffprobe_xml |  4 ++--
 10 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index 2d48070..9b0a87d 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2031,6 +2031,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 AVRational sar, dar;
 AVBPrint pbuf;
 const AVCodecDescriptor *cd;
+const AVPixFmtDescriptor *pix_desc;
 int ret = 0;
 
 av_bprint_init(&pbuf, 1, AV_BPRINT_SIZE_UNLIMITED);
@@ -2096,6 +2097,11 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 s = av_get_pix_fmt_name(dec_ctx->pix_fmt);
 if (s) print_str("pix_fmt", s);
 else   print_str_opt("pix_fmt", "unknown");
+pix_desc = av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+if (pix_desc)
+print_int("bits_per_component", 
av_get_bits_per_component(pix_desc));
+else
+print_str_opt("bits_per_component", "N/A");
 print_int("level",   dec_ctx->level);
 if (dec_ctx->color_range != AVCOL_RANGE_UNSPECIFIED)
 print_str("color_range", dec_ctx->color_range == 
AVCOL_RANGE_MPEG ? "tv": "pc");
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 154392a..1dfcf0f 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1980,6 +1980,21 @@ int av_get_padded_bits_per_pixel(const 
AVPixFmtDescriptor *pixdesc)
 return bits >> log2_pixels;
 }
 
+int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc)
+{
+int c, bits, first_bits = 0;
+
+for (c = 0; c < pixdesc->nb_components; c++) {
+bits = pixdesc->comp[c].depth_minus1 + 1;
+if (c == 0)
+first_bits = bits;
+else if (bits != first_bits)
+return 0;
+}
+
+return first_bits;
+}
+
 char *av_get_pix_fmt_string(char *buf, int buf_size,
 enum AVPixelFormat pix_fmt)
 {
diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
index 41e81db..f8af18f 100644
--- a/libavutil/pixdesc.h
+++ b/libavutil/pixdesc.h
@@ -251,6 +251,13 @@ int av_get_bits_per_pixel(const AVPixFmtDescriptor 
*pixdesc);
 int av_get_padded_bits_per_pixel(const AVPixFmtDescriptor *pixdesc);
 
 /**
+ * Return the number of bits per component (bit depth) for the pixel format
+ * described by pixdesc or 0 if the pixel format has unknown or non-uniform
+ * bit depth.
+ */
+int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc);
+
+/**
  * @return a pixel format descriptor for provided pixel format or NULL if
  * this pixel format is unknown.
  */
diff --git a/tests/ref/fate/ffprobe_compact b/tests/ref/fate/ffprobe_compact
index ad646af..0863b6f 100644
--- a/tests/ref/fate/ffprobe_compact
+++ b/tests/ref/fate/ffprobe_compact
@@ -27,6 +27,6 @@ 
frame|media_type=video|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12|pkt_dts=61
 
packet|codec_type=video|stream_index=2|pts=6144|pts_time=0.12|dts=6144|dts_time=0.12|duration=2048|duration_time=0.04|convergence_duration=N/A|convergence_duration_time=N/A|size=3|pos=1024801|flags=K
 
frame|media_type=video|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12|pkt_dts=6144|pkt_dts_time=0.12|best_effort_timestamp=6144|best_effort_timestamp_time=0.12|pkt_duration=2048|pkt_duration_time=0.04|pkt_pos=1024801|pkt_size=3|width=100|height=100|pix_fmt=rgb24|sample_aspect_ratio=1:1|pict_type=I|coded_picture_number=0|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0
 
stream|index=0|codec_name=pcm_s16le|profile=unknown|codec_type=audio|codec_time_base=1/44100|codec_tag_string=PSD[16]|codec_tag=0x10445350|sample_fmt=s16|sample_rate=44100|channels=1|channel_layout=unknown|bits_per_sample=16|id=N/A|r_frame_rate=0/0|avg_frame_rate=0/0|time_base=1/44100|start_pts=0|start_time=0.00|duration_ts=N/A|duration=N/A|bit_rate=705600|max_bit_rate=N/A|nb_frames=N/A|nb_read_frames=6|nb_read_packets=6|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=

[FFmpeg-devel] [PATCH] ffprobe: Add bits_per_component to stream output

2014-09-04 Thread Tobias Rapp

Attached patch adds bits_per_component (bit depth) output for video streams.
>From ea0e6884d42d3fe9e16565920b2c06c89015ff09 Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Thu, 4 Sep 2014 14:16:29 +0200
Subject: [PATCH] ffprobe: Add bits_per_component to stream output

Adds bits_per_component (bit depth) output for video streams.
---
 ffprobe.c  |  6 ++
 libavutil/pixdesc.c| 16 
 libavutil/pixdesc.h|  7 +++
 tests/ref/fate/ffprobe_compact |  4 ++--
 tests/ref/fate/ffprobe_csv |  4 ++--
 tests/ref/fate/ffprobe_default |  2 ++
 tests/ref/fate/ffprobe_flat|  2 ++
 tests/ref/fate/ffprobe_ini |  2 ++
 tests/ref/fate/ffprobe_json|  2 ++
 tests/ref/fate/ffprobe_xml |  4 ++--
 10 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index 2d48070..9b0a87d 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2031,6 +2031,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 AVRational sar, dar;
 AVBPrint pbuf;
 const AVCodecDescriptor *cd;
+const AVPixFmtDescriptor *pix_desc;
 int ret = 0;
 
 av_bprint_init(&pbuf, 1, AV_BPRINT_SIZE_UNLIMITED);
@@ -2096,6 +2097,11 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 s = av_get_pix_fmt_name(dec_ctx->pix_fmt);
 if (s) print_str("pix_fmt", s);
 else   print_str_opt("pix_fmt", "unknown");
+pix_desc = av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+if (pix_desc)
+print_int("bits_per_component", 
av_get_bits_per_component(pix_desc));
+else
+print_str_opt("bits_per_component", "N/A");
 print_int("level",   dec_ctx->level);
 if (dec_ctx->color_range != AVCOL_RANGE_UNSPECIFIED)
 print_str("color_range", dec_ctx->color_range == 
AVCOL_RANGE_MPEG ? "tv": "pc");
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 154392a..5ecb53a 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1980,6 +1980,22 @@ int av_get_padded_bits_per_pixel(const 
AVPixFmtDescriptor *pixdesc)
 return bits >> log2_pixels;
 }
 
+int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc)
+{
+int c, bits, first_bits = 0;
+int log2_pixels = pixdesc->log2_chroma_w + pixdesc->log2_chroma_h;
+
+for (c = 0; c < pixdesc->nb_components; c++) {
+bits = pixdesc->comp[c].depth_minus1 + 1;
+if (c == 0)
+first_bits = bits;
+else if (bits != first_bits)
+return 0;
+}
+
+return first_bits;
+}
+
 char *av_get_pix_fmt_string(char *buf, int buf_size,
 enum AVPixelFormat pix_fmt)
 {
diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
index 41e81db..f8af18f 100644
--- a/libavutil/pixdesc.h
+++ b/libavutil/pixdesc.h
@@ -251,6 +251,13 @@ int av_get_bits_per_pixel(const AVPixFmtDescriptor 
*pixdesc);
 int av_get_padded_bits_per_pixel(const AVPixFmtDescriptor *pixdesc);
 
 /**
+ * Return the number of bits per component (bit depth) for the pixel format
+ * described by pixdesc or 0 if the pixel format has unknown or non-uniform
+ * bit depth.
+ */
+int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc);
+
+/**
  * @return a pixel format descriptor for provided pixel format or NULL if
  * this pixel format is unknown.
  */
diff --git a/tests/ref/fate/ffprobe_compact b/tests/ref/fate/ffprobe_compact
index ad646af..0863b6f 100644
--- a/tests/ref/fate/ffprobe_compact
+++ b/tests/ref/fate/ffprobe_compact
@@ -27,6 +27,6 @@ 
frame|media_type=video|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12|pkt_dts=61
 
packet|codec_type=video|stream_index=2|pts=6144|pts_time=0.12|dts=6144|dts_time=0.12|duration=2048|duration_time=0.04|convergence_duration=N/A|convergence_duration_time=N/A|size=3|pos=1024801|flags=K
 
frame|media_type=video|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12|pkt_dts=6144|pkt_dts_time=0.12|best_effort_timestamp=6144|best_effort_timestamp_time=0.12|pkt_duration=2048|pkt_duration_time=0.04|pkt_pos=1024801|pkt_size=3|width=100|height=100|pix_fmt=rgb24|sample_aspect_ratio=1:1|pict_type=I|coded_picture_number=0|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0
 
stream|index=0|codec_name=pcm_s16le|profile=unknown|codec_type=audio|codec_time_base=1/44100|codec_tag_string=PSD[16]|codec_tag=0x10445350|sample_fmt=s16|sample_rate=44100|channels=1|channel_layout=unknown|bits_per_sample=16|id=N/A|r_frame_rate=0/0|avg_frame_rate=0/0|time_base=1/44100|start_pts=0|start_time=0.00|duration_ts=N/A|duration=N/A|bit_rate=705600|max_bit_rate=N/A|nb_frames=N/A|nb_read_frames=6|nb_read_packets=6|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|di

Re: [FFmpeg-devel] [PATCH] Add SUP (raw BluRay PGS subtitle) muxer

2014-09-04 Thread Petri Hintukainen
On to, 2014-09-04 at 10:19 +0200, Hendrik Leppkes wrote:
> On Fri, Aug 29, 2014 at 12:31 PM, Petri Hintukainen  
> wrote:
> > From: Petri Hintukainen 
> >
> > Fixes ticket #2208
> > ---
> >  libavformat/Makefile |  1 +
> >  libavformat/allformats.c |  1 +
> >  libavformat/supenc.c | 61 
> > 
> >  3 files changed, 63 insertions(+)
> >  create mode 100644 libavformat/supenc.c
> >
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index 3d124fb..e3cc653 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -405,6 +405,7 @@ OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
> >  OBJS-$(CONFIG_STR_DEMUXER)   += psxstr.o
> >  OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
> >  OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
> > +OBJS-$(CONFIG_SUP_MUXER) += supenc.o
> >  OBJS-$(CONFIG_SWF_DEMUXER)   += swfdec.o swf.o
> >  OBJS-$(CONFIG_SWF_MUXER) += swfenc.o swf.o
> >  OBJS-$(CONFIG_TAK_DEMUXER)   += takdec.o apetag.o img2.o 
> > rawdec.o
> > diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> > index 8f70c4b..a1a55f7 100644
> > --- a/libavformat/allformats.c
> > +++ b/libavformat/allformats.c
> > @@ -280,6 +280,7 @@ void av_register_all(void)
> >  REGISTER_DEMUXER (STR,  str);
> >  REGISTER_DEMUXER (SUBVIEWER1,   subviewer1);
> >  REGISTER_DEMUXER (SUBVIEWER,subviewer);
> > +REGISTER_MUXER   (SUP,  sup);
> >  REGISTER_MUXDEMUX(SWF,  swf);
> >  REGISTER_DEMUXER (TAK,  tak);
> >  REGISTER_MUXER   (TEE,  tee);
> > diff --git a/libavformat/supenc.c b/libavformat/supenc.c
> > new file mode 100644
> > index 000..3447f76
> > --- /dev/null
> > +++ b/libavformat/supenc.c
> > @@ -0,0 +1,61 @@
> > +/*
> > + * SUP muxer
> > + * Copyright (c) 2014 Petri Hintukainen 
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > 02110-1301 USA
> > + */
> > +
> > +#include "avformat.h"
> > +#include "internal.h"
> > +
> > +
> > +#define SUP_PGS_MAGIC 0x5047 /* "PG", big endian */
> > +
> > +static int sup_write_packet(AVFormatContext *s, AVPacket *pkt)
> > +{
> > +/* header */
> > +avio_wb16(s->pb, SUP_PGS_MAGIC);
> > +avio_wb32(s->pb, (uint64_t)pkt->pts);
> > +avio_wb32(s->pb, (uint64_t)pkt->dts);
> > +
> 
> All the timestamp talk in the demuxer thread made me think about this part.
> What if no dts or pts is set (ie. its AV_NOPTS_VALUE), I doubt writing
> that as-is is going to fly over well with other tools (especially
> because its value is > 32-bit anyway)
>
>Should you write 0?
 
It writes only 32 lowest bits, so AV_NOPTS_VALUE is written as 0.

Also looks like cast to uint64_t is not necessary ?

If timestamp does not fit to 32 bits, highest bits are dropped when
converting to 32 bits. I don't see any better way to handle this, the
format can only store 32 bits.

I'm more worried with the possibility that ffmpeg may modify the
timestamps (like, to start from 0). I noticed that if I demux only
single PGS stream from .m2ts, timestamps have different starting point
than if I demux also the video track. This requires extra work when
syncing subtitles with the video (sync is lost).

Now, I don't know if the timestamps in .sup should be the original
timestamps from .m2ts, or re-positioned so that start of the movie is at
0. Probably other tools expect it to start from 0, automatic conversions
between formats would be difficult otherwise (PGS streams are sparse,
and start time of the stream is not stored in .sup file). Also those
eac3to samples seem to confirm this.
If this is true, I'm not very worried about the timestamp wrap after 32
bits (that would require ~ 13 hours movie).

>Should you write dts=pts if only pts is set, and dts is unset?

I'd leave DTS to 0 if it is unset. Setting it to PTS would be wrong (no
time allocated for decoding, also PTS is not monotonic => DTS wouldn't
be either). I also think incorrect DTS is harder to detect than missing
DTS.

It wouldn't be impossible to re-generate valid DTS based on PTS, but I
think 

[FFmpeg-devel] [PATCH]refine the flv tagtype read for check as spec

2014-09-04 Thread Steven Liu
from the flv spec, the flvtag define the tagtype as one byte,
the spec desc is:
Reserved  UB[2] Reserved for FMS, should be 0
FilterUB[1] Indicates if packets are filtered.
0 = No pre-processing required.
1 = Pre-processing (such as decryption) of the packet is
required before it can be rendered.
Shall be 0 in unencrypted files, and 1 for encrypted
tags.
See Annex F. FLV Encryption for the use of filters.
TagType   UB[5] Type of contents in this tag. The following types are
defined:
8 = audio
9 = video
18 = script data

Signed-off-by: Steven Liu 
---
 libavformat/flvdec.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 8d9ed8b..a0550b4 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -777,7 +777,7 @@ static int flv_read_packet(
AVFormatContext *s, AVPacket *pkt)
 /* pkt size is repeated at end. skip it */
 for (;; avio_skip(s->pb, 4)) {
 pos  = avio_tell(s->pb);
-type = avio_r8(s->pb);
+type = (avio_r8(s->pb) & 0x1F);
 size = avio_rb24(s->pb);
 dts  = avio_rb24(s->pb);
 dts |= avio_r8(s->pb) << 24;
@@ -940,7 +940,7 @@ retry_duration:
 if (st->codec->codec_id == AV_CODEC_ID_AAC ||
 st->codec->codec_id == AV_CODEC_ID_H264 ||
 st->codec->codec_id == AV_CODEC_ID_MPEG4) {
-int type = avio_r8(s->pb);
+type = avio_r8(s->pb);
 size--;
 if (st->codec->codec_id == AV_CODEC_ID_H264 || st->codec->codec_id
== AV_CODEC_ID_MPEG4) {
 // sign extension
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] doc/filters.texi: remove incorrect duration syntax

2014-09-04 Thread Stefano Sabatini
On date Thursday 2014-09-04 01:17:16 -0700, Mark Harris encoded:
> The actual duration syntax with optional hours can be found in the
> ffmpeg-utils doc, but mention only seconds for filter options because
> ":" is an option separator (at least on the command line).

But you can escape ":" or you could want to set an HH:MM:SS.m... value
programmatically.

> ---
>  doc/filters.texi | 36 
>  1 file changed, 8 insertions(+), 28 deletions(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 4ae5b4f..afac010 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -517,27 +517,17 @@ volume as the input audio, at the end of the fade-out 
> transition
>  the output audio will be silence. Default is 44100.
>  
>  @item start_time, st
> -Specify time for starting to apply the fade effect. Default is 0.
> -The accepted syntax is:
> -@example
> -[-]HH[:MM[:SS[.m...]]]
> -[-]S+[.m...]
> -@end example
> -See also the function @code{av_parse_time()}.
> -If set this option is used instead of @var{start_sample} one.

> +Specify the start time of the fade effect, in seconds.
> +By default the start is determined by @var{start_sample}.
> +If set this option is used instead of @var{start_sample}.

What about:

Specify time for starting to apply the fade effect. Default is 0.
The value must be specified as a time duration, see
@ref{date syntax,,the Date section in the ffmpeg-utils(1) manual,ffmpeg-utils}.

Same below.

[...]
-- 
FFmpeg = Freak Fascinating Mysterious Perfectionist Extravagant Gnome
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/1] libavdevice/v4l2: fix descriptors leak on error paths

2014-09-04 Thread Michael Niedermayer
On Wed, Sep 03, 2014 at 03:46:03PM +0400, xe-l...@yandex.ru wrote:
> From: Dmitry Volyntsev 
> 
> Signed-off-by: Dmitry Volytnsev 

applied

thanks to all

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avdevice/x11grab: fix error handling in pixel formats

2014-09-04 Thread Michael Niedermayer
On Thu, Sep 04, 2014 at 10:27:34AM +0200, Benoit Fouet wrote:
> Hi,
> 
> - Mail original -
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavdevice/x11grab.c |5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavdevice/x11grab.c b/libavdevice/x11grab.c
> > index 120f754..e0d1dfa 100644
> > --- a/libavdevice/x11grab.c
> > +++ b/libavdevice/x11grab.c
> > @@ -181,6 +181,8 @@ static int pixfmt_from_image(AVFormatContext *s,
> > XImage *image, int *pix_fmt)
> > image->blue_mask,
> > image->bits_per_pixel);
> >  
> > +*pix_fmt = AV_PIX_FMT_NONE;
> > +
> >  switch (image->bits_per_pixel) {
> >  case 8:
> >  *pix_fmt =  AV_PIX_FMT_PAL8;
> > @@ -214,7 +216,8 @@ static int pixfmt_from_image(AVFormatContext *s,
> > XImage *image, int *pix_fmt)
> >  *pix_fmt = AV_PIX_FMT_0RGB32;
> >  }
> >  break;
> > -default:
> > +}
> > +if (*pix_fmt == AV_PIX_FMT_NONE) {
> >  av_log(s, AV_LOG_ERROR,
> > "XImages with RGB mask 0x%.6lx 0x%.6lx 0x%.6lx and
> > depth %i "
> > "are currently not supported.\n",
> 
> LGTM

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] patch for x32 for libpostproc

2014-09-04 Thread Michael Niedermayer
Hi Reinhard

On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote:
> On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer  wrote:
> > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
> >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer  
> >> wrote:
> >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
> >> >> Hi,
> >> >>
> >> >> as discussed in IRC, I was trying to minimal-invasively port
> >> >> libpostproc (the Debian source package) to x32¹. I could not
> >> >> test it (for lack of a stand-alone test program) yet, but at
> >> >> least I got it to build.
> >> >
> >> > you could try to test by buiding ffmpeg as a whole but disable asm
> >> > everywhere except libpostproc
> >> > that might allow "easy" testing though fate or ffmpeg with libavfilter
> >>
> >> Is http://git.videolan.org/?p=libpostproc.git still maintained?
> >
> > AFAIK, no, it seems the last commit is 2 years ago
> >
> >
> >>
> >> The Debian package tracks that repository, and ideally we could
> >> collect the postproc patches there.
> >
> > libpostproc was and is maintained in
> > git://source.ffmpeg.org/ffmpeg.git
> 
> So the promise given in
> https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
> doesn't hold anymore?

Can you be a bit more specific ? what "promise" by whom exactly do
you speak of ?


> 
> Any chance to make you reconsider reviving the standalone libpostproc.git?

From what i remember there where some problems with that repository
so actually maintaining it would probably imply first recreating it

for example try to build a old revission:

git checkout a792a836e3d9ef6f1f311604b38095e587282ca7
(this is libpostproc/master~20 ATM)
./configure
-bash: ./configure: No such file or directory

this is a problem for anyone maintaining the code as for example
git bisect
would not be usable at all

or if you do a git show
commit a792a836e3d9ef6f1f311604b38095e587282ca7
Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c

Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6
ancestors

So really, if someone wants to maintain or use libpostproc.git, first
these things need to be fixed

but i dont understand why you dont just take libpostproc
from where its developed, tested and used ?

but if it helps i guess we could copy the libpostproc from FFmpeg
over the one in libpostproc.git (which is what reimar suggested)
libpostproc.git was only intended to be a copy of FFmpeg with libs
other than libpostproc removed anyway.

Would this help you ?


> 
> > please use that for the debian package
> 
> I fear that's not feasible at this point.

Why ?


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/1] libavdevice/v4l2: fix descriptors leak on error paths

2014-09-04 Thread Giorgio Vazzana
2014-09-03 13:46 GMT+02:00  :
> From: Dmitry Volyntsev 
>
> Signed-off-by: Dmitry Volytnsev 
> ---
>  libavdevice/v4l2.c |   37 -
>  1 file changed, 20 insertions(+), 17 deletions(-)

LGTM too, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert

2014-09-04 Thread Dmitry Volyntsev
Yes, I could confirm that patch is LGTM. Successfully checked it on
one day long run.

On Tue, Sep 2, 2014 at 11:35 AM, Giorgio Vazzana  wrote:
> 2014-09-02 2:07 GMT+02:00 Michael Niedermayer :
>> should i apply the previous patch or wait ?
>
> Let's wait some days so that Dmitry can test the patch if he wants to
> and give us some feedback.
>
>> also if you want, you can add yourself to the v4l2 maintainers in the
>> MAINTAINERs file, as you seem to be doing a signifiant part of its
>> maintaince already
>
> OK.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



-- 
Be happy,
Best regards,
Dmitry Volyntsev
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avdevice/x11grab: fix error handling in pixel formats

2014-09-04 Thread Benoit Fouet
Hi,

- Mail original -
> Signed-off-by: Michael Niedermayer 
> ---
>  libavdevice/x11grab.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavdevice/x11grab.c b/libavdevice/x11grab.c
> index 120f754..e0d1dfa 100644
> --- a/libavdevice/x11grab.c
> +++ b/libavdevice/x11grab.c
> @@ -181,6 +181,8 @@ static int pixfmt_from_image(AVFormatContext *s,
> XImage *image, int *pix_fmt)
> image->blue_mask,
> image->bits_per_pixel);
>  
> +*pix_fmt = AV_PIX_FMT_NONE;
> +
>  switch (image->bits_per_pixel) {
>  case 8:
>  *pix_fmt =  AV_PIX_FMT_PAL8;
> @@ -214,7 +216,8 @@ static int pixfmt_from_image(AVFormatContext *s,
> XImage *image, int *pix_fmt)
>  *pix_fmt = AV_PIX_FMT_0RGB32;
>  }
>  break;
> -default:
> +}
> +if (*pix_fmt == AV_PIX_FMT_NONE) {
>  av_log(s, AV_LOG_ERROR,
> "XImages with RGB mask 0x%.6lx 0x%.6lx 0x%.6lx and
> depth %i "
> "are currently not supported.\n",

LGTM

-- 
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add SUP (raw BluRay PGS subtitle) muxer

2014-09-04 Thread Hendrik Leppkes
On Fri, Aug 29, 2014 at 12:31 PM, Petri Hintukainen  wrote:
> From: Petri Hintukainen 
>
> Fixes ticket #2208
> ---
>  libavformat/Makefile |  1 +
>  libavformat/allformats.c |  1 +
>  libavformat/supenc.c | 61 
> 
>  3 files changed, 63 insertions(+)
>  create mode 100644 libavformat/supenc.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 3d124fb..e3cc653 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -405,6 +405,7 @@ OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
>  OBJS-$(CONFIG_STR_DEMUXER)   += psxstr.o
>  OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
>  OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
> +OBJS-$(CONFIG_SUP_MUXER) += supenc.o
>  OBJS-$(CONFIG_SWF_DEMUXER)   += swfdec.o swf.o
>  OBJS-$(CONFIG_SWF_MUXER) += swfenc.o swf.o
>  OBJS-$(CONFIG_TAK_DEMUXER)   += takdec.o apetag.o img2.o rawdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 8f70c4b..a1a55f7 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -280,6 +280,7 @@ void av_register_all(void)
>  REGISTER_DEMUXER (STR,  str);
>  REGISTER_DEMUXER (SUBVIEWER1,   subviewer1);
>  REGISTER_DEMUXER (SUBVIEWER,subviewer);
> +REGISTER_MUXER   (SUP,  sup);
>  REGISTER_MUXDEMUX(SWF,  swf);
>  REGISTER_DEMUXER (TAK,  tak);
>  REGISTER_MUXER   (TEE,  tee);
> diff --git a/libavformat/supenc.c b/libavformat/supenc.c
> new file mode 100644
> index 000..3447f76
> --- /dev/null
> +++ b/libavformat/supenc.c
> @@ -0,0 +1,61 @@
> +/*
> + * SUP muxer
> + * Copyright (c) 2014 Petri Hintukainen 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "avformat.h"
> +#include "internal.h"
> +
> +
> +#define SUP_PGS_MAGIC 0x5047 /* "PG", big endian */
> +
> +static int sup_write_packet(AVFormatContext *s, AVPacket *pkt)
> +{
> +/* header */
> +avio_wb16(s->pb, SUP_PGS_MAGIC);
> +avio_wb32(s->pb, (uint64_t)pkt->pts);
> +avio_wb32(s->pb, (uint64_t)pkt->dts);
> +

All the timestamp talk in the demuxer thread made me think about this part.
What if no dts or pts is set (ie. its AV_NOPTS_VALUE), I doubt writing
that as-is is going to fly over well with other tools (especially
because its value is > 32-bit anyway)

Should you write 0? Should you write dts=pts if only pts is set, and
dts is unset?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] doc/filters.texi: remove incorrect duration syntax

2014-09-04 Thread Mark Harris
The actual duration syntax with optional hours can be found in the
ffmpeg-utils doc, but mention only seconds for filter options because
":" is an option separator (at least on the command line).
---
 doc/filters.texi | 36 
 1 file changed, 8 insertions(+), 28 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4ae5b4f..afac010 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -517,27 +517,17 @@ volume as the input audio, at the end of the fade-out 
transition
 the output audio will be silence. Default is 44100.
 
 @item start_time, st
-Specify time for starting to apply the fade effect. Default is 0.
-The accepted syntax is:
-@example
-[-]HH[:MM[:SS[.m...]]]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
-If set this option is used instead of @var{start_sample} one.
+Specify the start time of the fade effect, in seconds.
+By default the start is determined by @var{start_sample}.
+If set this option is used instead of @var{start_sample}.
 
 @item duration, d
-Specify the duration for which the fade effect has to last. Default is 0.
-The accepted syntax is:
-@example
-[-]HH[:MM[:SS[.m...]]]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
+Specify the duration of the fade effect, in seconds.
 At the end of the fade-in effect the output audio will have the same
 volume as the input audio, at the end of the fade-out transition
 the output audio will be silence.
-If set this option is used instead of @var{nb_samples} one.
+By default the duration is determined by @var{nb_samples}.
+If set this option is used instead of @var{nb_samples}.
 
 @item curve
 Set curve for fade transition.
@@ -9459,12 +9449,7 @@ number or a valid video frame rate abbreviation. The 
default value is
 "25".
 
 @item duration, d
-Set the video duration of the sourced video. The accepted syntax is:
-@example
-[-]HH:MM:SS[.m...]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
+Set the duration of the sourced video, in seconds.
 
 If not specified, or the expressed duration is negative, the video is
 supposed to be generated forever.
@@ -9726,12 +9711,7 @@ number or a valid video frame rate abbreviation. The 
default value is
 Set the sample aspect ratio of the sourced video.
 
 @item duration, d
-Set the video duration of the sourced video. The accepted syntax is:
-@example
-[-]HH[:MM[:SS[.m...]]]
-[-]S+[.m...]
-@end example
-Also see the the @code{av_parse_time()} function.
+Set the duration of the sourced video, in seconds.
 
 If not specified, or the expressed duration is negative, the video is
 supposed to be generated forever.
-- 
2.1.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 1/4] libavutil/error: fix build with musl toolchain

2014-09-04 Thread Jörg Krause


On 09/03/2014 08:12 PM, Michael Niedermayer wrote:

On Wed, Sep 03, 2014 at 11:53:39AM +0200, Jörg Krause wrote:

Add the feature test macro which is required for building with the
musl toolchain.

The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
version of strerror_r().

Signed-off-by: Jörg Krause 
---
Changes v1 -> v2:
   - fixed wrong macro name
   - add a comment
---
  libavutil/error.c | 1 +
  1 file changed, 1 insertion(+)

applied


Many thanks! There are some more fixes necessary for supporting the musl 
C library. I will prepare a series of patches in a couple of days. I 
will follow the suggestion to add the feature test macros on source 
level as described in the GNU C library reference manual.



btw, if you are interrested in setting up a musl fate client to
regularly test ffmpeg, see http://ffmpeg.org/fate.html


Interesting, I will give it a try.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/1] libavdevice/v4l2: fix descriptors leak on error paths

2014-09-04 Thread Benoit Fouet
Hi,

- Mail original -
> From: Dmitry Volyntsev 
> 
> Signed-off-by: Dmitry Volytnsev 
> ---
>  libavdevice/v4l2.c |   37 -
>  1 file changed, 20 insertions(+), 17 deletions(-)
> 
> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> index 9f9f944..7b9e2f3 100644
> --- a/libavdevice/v4l2.c
> +++ b/libavdevice/v4l2.c


[...]

> @@ -956,6 +955,10 @@ static int v4l2_read_header(AVFormatContext *s1)
>  st->codec->bit_rate = s->frame_size *
>  av_q2d(st->avg_frame_rate) * 8;
>  
>  return 0;
> +
> +fail:
> +v4l2_close(s->fd);
> +return res;
>  }
>  
>  static int v4l2_read_packet(AVFormatContext *s1, AVPacket *pkt)

This is not really a 'fail' path when it is reached after listing the formats 
or the standards.
LGTM anyway.

-- 
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel