Re: [FFmpeg-devel] [GSoC] Proof-of-concept HTTP Server

2015-03-22 Thread Nicolas George 
Le primidi 1er germinal, an CCXXIII, Stephan Holljes a écrit :
> Please comment.

As Michael pointed out, the patch was mangled at sending. That happens with
mail user agent that rely on "rich" text editor and do not let users control
the formatting finely. Using git send-email or attaching the file will solve
the problem. They also include authorship and date information.

> 
> Regards,
> Stephan Holljes
> 
> ---
>  libavformat/http.c |  113
> ++--
>  1 file changed, 83 insertions(+), 30 deletions(-)
> 
> diff --git a/libavformat/http.c b/libavformat/http.c
> index da3c9be..d61e4e2 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -96,8 +96,12 @@ typedef struct HTTPContext {
>  int send_expect_100;
>  char *method;
>  int reconnect;
> +int listen;
> +int fd;
> +int header_sent;
>  } HTTPContext;
> 
> +
>  #define OFFSET(x) offsetof(HTTPContext, x)
>  #define D AV_OPT_FLAG_DECODING_PARAM
>  #define E AV_OPT_FLAG_ENCODING_PARAM
> @@ -127,6 +131,7 @@ static const AVOption options[] = {
>  { "end_offset", "try to limit the request to bytes preceding this
> offset", OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D
> },
>  { "method", "Override the HTTP method", OFFSET(method),
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
>  { "reconnect", "auto reconnect after disconnect before EOF",
> OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
> +{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64
> = 0 }, 0, 1, D },
>  { NULL }
>  };
> 
> @@ -299,8 +304,10 @@ int ff_http_averror(int status_code, int
> default_averror)
>  static int http_open(URLContext *h, const char *uri, int flags,
>   AVDictionary **options)
>  {
> +struct addrinfo hints = { 0 }, *ai;
>  HTTPContext *s = h->priv_data;
> -int ret;
> +int ret = -1, fd;
> +char portstr[] = "8080"; // allow non-root users for now
> 
>  if( s->seekable == 1 )
>  h->is_streamed = 0;
> @@ -320,11 +327,39 @@ static int http_open(URLContext *h, const char *uri,
> int flags,
>  av_log(h, AV_LOG_WARNING,
> "No trailing CRLF found in HTTP header.\n");
>  }

> +if (s->listen) {
> +hints.ai_family = AF_UNSPEC;
> +hints.ai_socktype = SOCK_STREAM;
> +hints.ai_flags |= AI_PASSIVE;
> +ret = getaddrinfo(NULL, portstr, &hints, &ai);
> +if (ret) {
> +av_log(h, AV_LOG_ERROR, "borked");
> +return AVERROR(EIO);
> +}
> +fd = ff_socket(ai->ai_family,
> +   ai->ai_socktype,
> +   ai->ai_protocol);
> +if (fd < 0) {
> +ret = ff_neterrno();
> +freeaddrinfo(ai);
> +return -1;
> +}

This part looks copied from tcp.c. It would be much better to use the API
provided by TCP. In other words, just like the client part does:

err = ffurl_open(&s->hd, buf, AVIO_FLAG_READ_WRITE,
 &h->interrupt_callback, options);

you should do the same thing for creating the listening socket, just adding
the listen option. There are several reasons for doing that.

First, you avoid reimplementing all the interrupt_callback logic and cie,
which would be necessary for a complete implementation.

Second, this code with getaddrinfo is slightly wrong (wrt multi-protocol
hosts), so when it gets fixed in tcp.c, it would benefit to all the code.

> 
> -ret = http_open_cnx(h, options);
> -if (ret < 0)
> -av_dict_free(&s->chained_options);
> -return ret;
> +fd = ff_listen_bind(fd, ai->ai_addr, ai->ai_addrlen, -1, h);
> +if (fd < 0) {
> +freeaddrinfo(ai);
> +return fd;
> +}
> +h->is_streamed = 1;
> +s->fd = fd;
> +freeaddrinfo(ai);
> +return 0;
> +} else {
> +ret = http_open_cnx(h, options);
> +if (ret < 0)
> +av_dict_free(&s->chained_options);
> +return ret;
> +}
>  }
> 
>  static int http_getc(HTTPContext *s)
> @@ -1102,25 +1137,40 @@ static int http_write(URLContext *h, const uint8_t
> *buf, int size)
>  char temp[11] = "";  /* 32-bit hex + CRLF + nul */
>  int ret;
>  char crlf[] = "\r\n";
> +char header[] = "HTTP 200 OK\r\n\r\n";
>  HTTPContext *s = h->priv_data;
> +if (!s->listen) {
> +if (!s->chunked_post) {
> +/* non-chunked data is sent without any special encoding */
> +return ffurl_write(s->hd, buf, size);
> +}
> 
> -if (!s->chunked_post) {
> -/* non-chunked data is sent without any special encoding */
> -return ffurl_write(s->hd, buf, size);
> -}
> -
> -/* silently ignore zero-size data since chunk encoding that would
> - * signal EOF */
> -if (size > 0) {
> -/* upload data using chunked encoding */
> -snprintf(temp,

Re: [FFmpeg-devel] Patches For 2.6 Branch

2015-03-22 Thread Michael Niedermayer 
On Sun, Mar 22, 2015 at 02:25:07PM +1100, Micah Galizia wrote:
> Hi,
> 
> I had some code accepted on the master branch and I was wondering if
> they'd be suitable for inclusion in the 2.6 branch. I'd like them in
> the next version of xmbc. The commits were:
> 
> c59654d67d1afde3fac24021ef0fd9d18cf38455
> fca085187940a169b7a43d096009f7dac315f9ac
> 7859618affe574c9de7f240d2ddc016f917c37bd
> 

> Assuming they make sense (I'd view them as fixes, not features), do I
> just merge them into the 2.6 branch and resubmit?

yes you can
or you can just backport them in a public git repo and post a link
to the git branch to be merged.

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

[FFmpeg-devel] H264 cleanup performance effects

2015-03-22 Thread Michael Niedermayer 
Hi anton, everyone else

the "cosmetic" commits from yesterday
(665e0c10a63d31dd6c7b1fba14db074625d54614..fa7c08d5e192aea77fdfb7f52c44c196a3ba4452)
 /
(d8a45d2d49f54fde042b195f9d5859251252493d..c28ed1d743443e783537d279ae721be3bbdf7646)

cause a ~1% speed loss in the H.264 decoder which is probably the
most important decoder in the codebase

after the patchset:
-threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null -
utime=5.448s
utime=5.424s
utime=5.436s
utime=5.428s
utime=5.448s


before the patchset:
-threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null -
utime=5.360s
utime=5.328s
utime=5.356s
utime=5.376s
utime=5.360s

Testing has been done with a single thread as the results with
multiple threads where inconsistent/unstable

The speedloss is reproduceable with ffmpeg as well as libav

also in some of the commits there where hidden optimizations:
for example in a12d3188cbec15e22070e139fa5cc541da07e2c3 there was:

-for (list = 0; list < 2; list++) {
+for (list = 0; list < sl->list_count; list++) {

@@ -130,16 +130,20 @@ void ff_h264_direct_ref_list_init(const H264Context 
*const h, H264SliceContext *
 cur->mbaff = FRAME_MBAFF(h);

 sl->col_fieldoff = 0;
+
+if (sl->list_count != 2 || !sl->ref_count[1])
+return;
+

@@ -340,20 +340,24 @@ int ff_h264_decode_ref_pic_list_reordering(H264Context 
*h, H264SliceContext *sl)
 void ff_h264_fill_mbaff_ref_list(H264Context *h, H264SliceContext *sl)
 {
 int list, i, j;
-for (list = 0; list < 2; list++) { //FIXME try list_count
+for (list = 0; list < sl->list_count; list++) { //FIXME try list_count


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


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 an ignore_delay option to the gif demuxer

2015-03-22 Thread Carl Eugen Hoyos 
Carl Eugen Hoyos  ag.or.at> writes:

> Attached patch allows users to force a delay for an animated gif.

Ping.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]Add an ignore_delay option to the gif demuxer

2015-03-22 Thread Michael Niedermayer 
On Wed, Mar 18, 2015 at 08:43:30AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch allows users to force a delay for an animated gif.
> Related to ticket #4369 (I don't think there is a bug, if there 
> is a bug, it is reproducible with avi etc.)
> 
> Please comment, Carl Eugen

>  gifdec.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 68ec9bdb7f2898676129668fdf77a206a9699919  patchgifdelay.diff
> diff --git a/libavformat/gifdec.c b/libavformat/gifdec.c

LGTM iam not the maintainer of gifdec though

[...]

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

[FFmpeg-devel] [PATCH 1/2] avutil/timer: show histogram of cpu cycles each run took

2015-03-22 Thread Michael Niedermayer 
The new information is printed at verbose log level and can thus be switched on 
and off
through the log level

Signed-off-by: Michael Niedermayer 
---
 libavutil/timer.h |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavutil/timer.h b/libavutil/timer.h
index 13a3c8c..f17f76b 100644
--- a/libavutil/timer.h
+++ b/libavutil/timer.h
@@ -69,6 +69,8 @@
 static uint64_t tsum   = 0;   \
 static int tcount  = 0;   \
 static int tskip_count = 0;   \
+static int thistogram[32] = {0};  \
+thistogram[av_log2(tend - tstart)]++; \
 if (tcount < 2||  \
 tend - tstart < 8 * tsum / tcount ||  \
 tend - tstart < 2000) {   \
@@ -77,9 +79,13 @@
 } else\
 tskip_count++;\
 if (((tcount + tskip_count) & (tcount + tskip_count - 1)) == 0) { \
+int i;\
 av_log(NULL, AV_LOG_ERROR,\
-   "%"PRIu64" " FF_TIMER_UNITS " in %s, %d runs, %d skips\n",  
\
+   "%"PRIu64" " FF_TIMER_UNITS " in %s, %d runs, %d skips",
  \
tsum * 10 / tcount, id, tcount, tskip_count);  \
+for (i = 0; i < 32; i++)  \
+av_log(NULL, AV_LOG_VERBOSE, " %2d", 
av_log2(2*thistogram[i]));\
+av_log(NULL, AV_LOG_ERROR, "\n"); \
 } \
 }
 #else
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 2/2] avutil/timer: give each printed value of STOP_TIMER a fixed length

2015-03-22 Thread Michael Niedermayer 
this makes the result easier to read

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

diff --git a/libavutil/timer.h b/libavutil/timer.h
index f17f76b..e21f655 100644
--- a/libavutil/timer.h
+++ b/libavutil/timer.h
@@ -81,7 +81,7 @@
 if (((tcount + tskip_count) & (tcount + tskip_count - 1)) == 0) { \
 int i;\
 av_log(NULL, AV_LOG_ERROR,\
-   "%"PRIu64" " FF_TIMER_UNITS " in %s, %d runs, %d skips",
  \
+   "%7"PRIu64" " FF_TIMER_UNITS " in %s,%8d runs,%7d skips",   
   \
tsum * 10 / tcount, id, tcount, tskip_count);  \
 for (i = 0; i < 32; i++)  \
 av_log(NULL, AV_LOG_VERBOSE, " %2d", 
av_log2(2*thistogram[i]));\
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Allow muxing video codecs which are not explicitly supported by the muxer

2015-03-22 Thread Michael Niedermayer 
On Fri, Mar 06, 2015 at 03:31:50AM +0100, Michael Niedermayer wrote:
> This allows stream copying video codecs before they are explicitly
> supported. The same feature was in the past useful for audio codecs
> in flv
> 
> This partly reverts the changes from 735ab7c5e04e2316afbd56643c13de17a7ac89cd
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/flvenc.c |   13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)

applied


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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] H264 cleanup performance effects

2015-03-22 Thread wm4 
On Sun, 22 Mar 2015 15:12:04 +0100
Michael Niedermayer  wrote:

> Hi anton, everyone else

I appreciate that you contacted the author of these patches as well.

> the "cosmetic" commits from yesterday
> (665e0c10a63d31dd6c7b1fba14db074625d54614..fa7c08d5e192aea77fdfb7f52c44c196a3ba4452)
>  /
> (d8a45d2d49f54fde042b195f9d5859251252493d..c28ed1d743443e783537d279ae721be3bbdf7646)
> 
> cause a ~1% speed loss in the H.264 decoder which is probably the
> most important decoder in the codebase
> 
> after the patchset:
> -threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null -
> utime=5.448s
> utime=5.424s
> utime=5.436s
> utime=5.428s
> utime=5.448s
> 
> 
> before the patchset:
> -threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null -
> utime=5.360s
> utime=5.328s
> utime=5.356s
> utime=5.376s
> utime=5.360s
> 
> Testing has been done with a single thread as the results with
> multiple threads where inconsistent/unstable
> 
> The speedloss is reproduceable with ffmpeg as well as libav

At this point I'd argue that 1% speedloss in exchange for much cleaner
and saner code is not the world's end. Especially because ffmpeg is
probably already the fastest software decoder on x86, and cleaner code
may in fact help improving the decoder further. (But then I don't know
the h264 decoder, and may be talking out of my ass.)

> also in some of the commits there where hidden optimizations:
> for example in a12d3188cbec15e22070e139fa5cc541da07e2c3 there was:
> 
> -for (list = 0; list < 2; list++) {
> +for (list = 0; list < sl->list_count; list++) {
> 
> @@ -130,16 +130,20 @@ void ff_h264_direct_ref_list_init(const H264Context 
> *const h, H264SliceContext *
>  cur->mbaff = FRAME_MBAFF(h);
> 
>  sl->col_fieldoff = 0;
> +
> +if (sl->list_count != 2 || !sl->ref_count[1])
> +return;
> +
> 
> @@ -340,20 +340,24 @@ int ff_h264_decode_ref_pic_list_reordering(H264Context 
> *h, H264SliceContext *sl)
>  void ff_h264_fill_mbaff_ref_list(H264Context *h, H264SliceContext *sl)
>  {
>  int list, i, j;
> -for (list = 0; list < 2; list++) { //FIXME try list_count
> +for (list = 0; list < sl->list_count; list++) { //FIXME try list_count
> 
> 

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

Re: [FFmpeg-devel] H264 cleanup performance effects

2015-03-22 Thread Ivan Kalvachev 
On 3/22/15, wm4  wrote:
> On Sun, 22 Mar 2015 15:12:04 +0100
> Michael Niedermayer  wrote:
>
>> Hi anton, everyone else
>
> I appreciate that you contacted the author of these patches as well.
>
>> the "cosmetic" commits from yesterday
>> (665e0c10a63d31dd6c7b1fba14db074625d54614..fa7c08d5e192aea77fdfb7f52c44c196a3ba4452)
>> /
>> (d8a45d2d49f54fde042b195f9d5859251252493d..c28ed1d743443e783537d279ae721be3bbdf7646)
>>
>> cause a ~1% speed loss in the H.264 decoder which is probably the
>> most important decoder in the codebase
>>
>> after the patchset:
>> -threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null
>> -
>> utime=5.448s
>> utime=5.424s
>> utime=5.436s
>> utime=5.428s
>> utime=5.448s
>>
>>
>> before the patchset:
>> -threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null
>> -
>> utime=5.360s
>> utime=5.328s
>> utime=5.356s
>> utime=5.376s
>> utime=5.360s
>>
>> Testing has been done with a single thread as the results with
>> multiple threads where inconsistent/unstable
>>
>> The speedloss is reproduceable with ffmpeg as well as libav
>
> At this point I'd argue that 1% speedloss in exchange for much cleaner
> and saner code is not the world's end. Especially because ffmpeg is
> probably already the fastest software decoder on x86, and cleaner code
> may in fact help improving the decoder further. (But then I don't know
> the h264 decoder, and may be talking out of my ass.)

No, It won't help improve the decoder further. This code would never
be touched by anybody who can't navigate in it already.

Libav is the project that values pretty code.
I hope FFmpeg still values speed and durability.

Also, the speed loss is more like 2% and that's A LOT.

If anybody wants this cleanup included, then I recommend him to find a
clean way to compensate for this slowdown.

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

Re: [FFmpeg-devel] H264 cleanup performance effects

2015-03-22 Thread wm4 
On Sun, 22 Mar 2015 18:11:34 +0200
Ivan Kalvachev  wrote:

> On 3/22/15, wm4  wrote:
> > On Sun, 22 Mar 2015 15:12:04 +0100
> > Michael Niedermayer  wrote:
> >
> >> Hi anton, everyone else
> >
> > I appreciate that you contacted the author of these patches as well.
> >
> >> the "cosmetic" commits from yesterday
> >> (665e0c10a63d31dd6c7b1fba14db074625d54614..fa7c08d5e192aea77fdfb7f52c44c196a3ba4452)
> >> /
> >> (d8a45d2d49f54fde042b195f9d5859251252493d..c28ed1d743443e783537d279ae721be3bbdf7646)
> >>
> >> cause a ~1% speed loss in the H.264 decoder which is probably the
> >> most important decoder in the codebase
> >>
> >> after the patchset:
> >> -threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null
> >> -
> >> utime=5.448s
> >> utime=5.424s
> >> utime=5.436s
> >> utime=5.428s
> >> utime=5.448s
> >>
> >>
> >> before the patchset:
> >> -threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null
> >> -
> >> utime=5.360s
> >> utime=5.328s
> >> utime=5.356s
> >> utime=5.376s
> >> utime=5.360s
> >>
> >> Testing has been done with a single thread as the results with
> >> multiple threads where inconsistent/unstable
> >>
> >> The speedloss is reproduceable with ffmpeg as well as libav
> >
> > At this point I'd argue that 1% speedloss in exchange for much cleaner
> > and saner code is not the world's end. Especially because ffmpeg is
> > probably already the fastest software decoder on x86, and cleaner code
> > may in fact help improving the decoder further. (But then I don't know
> > the h264 decoder, and may be talking out of my ass.)
> 
> No, It won't help improve the decoder further. This code would never
> be touched by anybody who can't navigate in it already.
> 
> Libav is the project that values pretty code.
> I hope FFmpeg still values speed and durability.

I hope FFmpeg doesn't value speed over clean code. (Oh who am I
kidding, the worst abuse is ok if it makes it 1% faster!)

I can assure you, in the end simpler code wins, because it's actually
maintainable and hackable. Just generally speaking.

What's "durability" in this context even?

> Also, the speed loss is more like 2% and that's A LOT.
> 
> If anybody wants this cleanup included, then I recommend him to find a
> clean way to compensate for this slowdown.
> 
> Good Luck.
> ___
> 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] H264 cleanup performance effects

2015-03-22 Thread Ronald S. Bultje 
Hi,

On Sun, Mar 22, 2015 at 12:15 PM, wm4  wrote:

> I hope FFmpeg doesn't value speed over clean code. (Oh who am I
> kidding, the worst abuse is ok if it makes it 1% faster!)


I think this is unfair. Your statements suggests:
- that the slowdown is a direct effect of making the code cleaner;
- that any speedup to undo such slowdowns would automatically lead to ugly
code again.

You have no evidence for either statement. Anton posted a double-digit
patchset, and although I'm sure the end result is cleaner (I have no
opinion), you'd need to figure out _which_ patch(es) made things slower and
_why_ (cosmetics? or unrelated?), before you can prove #1. All you have
right now is apples and pears. #2 is impossible to prove.

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

Re: [FFmpeg-devel] H264 cleanup performance effects

2015-03-22 Thread wm4 
On Sun, 22 Mar 2015 13:07:09 -0400
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Sun, Mar 22, 2015 at 12:15 PM, wm4  wrote:
> 
> > I hope FFmpeg doesn't value speed over clean code. (Oh who am I
> > kidding, the worst abuse is ok if it makes it 1% faster!)
> 
> 
> I think this is unfair. Your statements suggests:
> - that the slowdown is a direct effect of making the code cleaner;
> - that any speedup to undo such slowdowns would automatically lead to ugly
> code again.
> 
> You have no evidence for either statement. Anton posted a double-digit
> patchset, and although I'm sure the end result is cleaner (I have no
> opinion), you'd need to figure out _which_ patch(es) made things slower and
> _why_ (cosmetics? or unrelated?), before you can prove #1. All you have
> right now is apples and pears. #2 is impossible to prove.

Yeah, sorry for jumping to conclusions.

And I suppose the correct way to call these commits is not "cosmetics"
but "refactoring".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [FFmpeg-Devel] [GSoC] [PATCH 1/4] created x86 directory in libpostproc for standalone asm files

2015-03-22 Thread Tucker DiNapoli 
From: Tucker DiNapoli 

This patch set contains implementations of various filters from libpostproc,
translated from inline asm (in postprocess_template.c) into seperate yasm files.
In addition support for sse2 and avx2 has been added via the use of the simd
abstraction layer from x86inc.asm. There are 4 assembly files added, one is a 
file of utility macros, one defines the layout of various structs used in 
libpostproc
using the yasm struc directive, one implements several deinterlacing filters 
and 
the last implements a deblocking filter. I am used to writing x86 asm for the
gnu assembler so I'm still somewhat new at using yasm features, so any advice
on how to better use yasm, better format my assembly, or any advice on my code
in general would be appricated.

I would like to submit these patches as my qualification task for the google
summer of code. It may be hard to test the code as it can't be use with 
libpostproc 
as is, this is because a significant part of the summer project is to modify
the C code to support differing vector sizes. I think trying to change the
library to interface with this new code is too much to ask for a qualification 
task,
but if this code alone isn't enough I can work on something else if need be.

I also put one file into the directory, which just defines the layout of
the structs used in libpostproc using the struc and endstruc macros.

diff --git a/libpostproc/x86/PPContext.asm b/libpostproc/x86/PPContext.asm
new file mode 100644
index 000..022dddb
--- /dev/null
+++ b/libpostproc/x86/PPContext.asm
@@ -0,0 +1,70 @@
+;*
+;* Definition of the PPContext and PPMode structs in assembly
+;* Copyright (C) 2015 Tucker DiNapoli (T.Dinapoli at gmail.com)
+;*
+;* 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
+;*
+%if ARCH_X86_64
+%define pointer resq
+%else
+%define pointer resd
+%endif
+struc PPMode
+.lum_mode: resd 1
+.chrom_mode: resd 1
+.error: resd 1
+.min_allowed_y: resd 1
+.max_allowed_y: resd 1
+.max_clipped_threshold: resd 1
+.max_tmp_noise: resd 3
+.base_dc_diff: resd 1
+.flatness_threshold: resd 1
+.forced_quant: resd 1
+endstruc
+
+struc PPContext
+.av_class pointer 1
+.temp_blocks pointer 1
+.y_historgam pointer 1
+alignb 8
+.packed_yoffset resq 1
+.packed_yscale resq 1; 8 byte aligned by default
+.temp_blurred pointer 3
+.temp_blurred_past pointer 3
+.temp_dst pointer 1
+.temp_src pointer 1
+.deint_temp pointer 1
+alignb 8
+.pQPb resq 1
+.pQPb2 resq 1
+;; These next fields & next alignment may need to be changed for 128/256 bit 
registers
+alignb 8
+.mmx_dc_offset resq 64
+.mmx_dc_threshold resq 64
+.std_QP_table pointer 1
+.non_BQP_table pointer 1
+.forced_QP_table pointer 1
+.QP resd 1
+.nonBQP resd 1
+.frame_num resd 1
+.cpu_caps resd 1
+.qp_stride resd 1
+.stride resd 1
+.h_chroma_subsample resd 1
+.v_chroma_subsample resd 1
+.ppMode resd PPMode_size
+endstruc
-- 
2.3.3

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

[FFmpeg-devel] [FFmpeg-Devel] [GSoC] [PATCH 2/4] Added asm file with some useful macros

2015-03-22 Thread Tucker DiNapoli 
From: Tucker DiNapoli 


diff --git a/libpostproc/x86/PPUtil.asm b/libpostproc/x86/PPUtil.asm
new file mode 100644
index 000..090ee18
--- /dev/null
+++ b/libpostproc/x86/PPUtil.asm
@@ -0,0 +1,116 @@
+;**
+;*
+;* Copyright (c) 2015 Tucker DiNapoli
+;*
+;* Utility code/marcos used in asm files for libpostproc
+;*
+;* 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"
+%include "PPContext.asm"
+;; Macros to simplify moving packed data
+
+;; copy low quadword to upper quadword(s)
+%macro dup_low_quadword 1
+%if cpuflag(sse2)
+pshufpd %1, %1, 0x00
+%elif cpuflag(avx2)
+vpermq %1, %1, 01010101b
+%endif
+%endmacro
+
+;; move the low half of the mmx/xmm/ymm register in %2 into %1
+;; %1 should be a memory location
+%macro mov_vector_low_half 2
+%if mmsize == 32
+vextractf128 %1, %2, 0x00
+%elif mmsize == 16
+movlpd %1, %2
+%elif mmsize == 8
+movd %1, %2
+%else
+%error "mmsize defined to unsupported value"
+%endif
+%endmacro
+;; move the high half of the mmx/xmm/ymm register in %2 into %1
+;; %1 should be a memory location
+%macro mov_vector_high_half 2-3 m0
+%if mmsize == 32
+vextractf128 %1, %2, 0x01
+%elif mmsize == 16
+movhpd %1, %2
+%elif mmsize == 8
+;; there's no instruction, pre sse4.1, to move the high 32 bits of an mmx
+;; register, so use the optional third argument as a temporary register
+;; shift it right by 32 bits and extract the low doubleword
+movq %3, %2
+psrl %3, 32
+movd %1, %3
+%else
+%error "mmsize defined to unsupported value"
+%endif
+%endmacro
+
+;; define packed conditional moves, of the form:
+;; pcmovXXS dst, src, arg1, arg2, tmp
+;; where XX is a comparision (eq,ne,gt,...) and S is a size(b,w,d,q)
+;; copy src to dest, then compare arg1 with arg2 and store
+;; the result in tmp, finally AND src with tmp.
+%macro do_simd_sizes 2
+%1 %2b
+%1 %2w
+%1 %2d
+%1 %2q
+%endmacro
+;; macro generating macro
+%macro gen_pcmovxx 1 
+%macro pcmov%1 4-6 ,%1 ;;dst, src, cmp1, cmp2, [tmp = cmp2]
+%if %0 == 5
+%ifnidn %5,%3
+mova %5,%3
+%endif
+%endif
+pcmp%6 %5,%4
+mova %1, %2
+pand %1, %5
+%endmacro
+%endmacro
+do_simd_sizes gen_pcmovxx,eq
+do_simd_sizes gen_pcmovxx,ne
+do_simd_sizes gen_pcmovxx,lt
+do_simd_sizes gen_pcmovxx,le
+do_simd_sizes gen_pcmovxx,gt
+do_simd_sizes gen_pcmovxx,ge
+
+;; Macros for defining simd constants
+%macro define_qword_vector_constant 5
+%if cpuflag(avx2)
+SECTION_RODATA 32
+%else
+SECTION_RODATA 16
+%endif
+%1: 
+dq %2
+%if cpuflag(sse2)
+dq %3
+%if cpuflag(avx2)
+dq %4
+dq %5
+%endif
+%endif
+SECTION_TEXT
+%endmacro
-- 
2.3.3

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

[FFmpeg-devel] [FFmpeg-Devel] [GSoC] [PATCH 3/4] Added asm implmentations of some deinterlace functions

2015-03-22 Thread Tucker DiNapoli 
From: Tucker DiNapoli 

I also added a makefile which assembles this file into libpostproc. I
haven't yet modified the c code to use these functions yet.

diff --git a/libpostproc/x86/Makefile b/libpostproc/x86/Makefile
new file mode 100644
index 000..06838ca
--- /dev/null
+++ b/libpostproc/x86/Makefile
@@ -0,0 +1 @@
+YASM-OBJS-$(CONFIG_POSTPROC) += x86/deinterlace.o
diff --git a/libpostproc/x86/deinterlace.asm b/libpostproc/x86/deinterlace.asm
new file mode 100644
index 000..6e669bb
--- /dev/null
+++ b/libpostproc/x86/deinterlace.asm
@@ -0,0 +1,167 @@
+;*
+;* DeInterlacing filters written using SIMD extensions
+;* Copyright (C) 2015 Tucker DiNapoli (T.Dinapoli at gmail.com)
+;*
+;* Adapted from inline assembly:
+;* Copyright (C) 2001-2002 Michael Niedermayer (michae...@gmx.at)
+;*
+;* 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 "PPUtil.asm"
+;; All deinterlace functions operate on N 8x8 blocks at a time, where N
+;; is the size (in bytes) of the simd registers being used divided
+;; by 8, so 2 for xmm, and 4 for ymm.
+
+;; NOTE: The function names are camel case for compatibility with existing 
+;; postprocessing code, eventually the names of postprocessing functions
+;; will be changed to use lowercase and underscores
+
+;; Deinterlace blocks using linear interpolation
+;; Set each line 2n+1 to (line 2n + line 2n+2)/2
+%macro gen_deinterlace_interpolate_linear 0
+cglobal deInterlaceInterpolateLinear, 2, 4, 2;, src, stride
+lea r1, [r1 + r2 * 4]
+lea r3, [r1 + r2]
+lea r4, [r3 + r2 * 4]
+mova m0, [r1]
+mova m1, [r3 + r2]
+pavgb m0,m1
+mova [r3], m0
+mova m0, [r1 + r2 * 4]
+pavgb m1,m0
+mova [r3 + r2 * 2],m1
+mova m1, [r4 + r2]
+pavgb m0,m1
+mova [r4], m0
+mova m1, [r1 + r2 * 8]
+pavgb m0,m1
+mova [r4 + r2 * 2], m0
+RET
+%endmacro
+;; Deinterlace blocks using cubic interpolation
+;; Line 2n+1 = (9(2n) + 9(2n+2) - (2n-2) - (2n+4))/16
+%macro gen_deinterlace_interpolate_cubic 0
+cglobal deInterlaceInterpolateCubic, 2, 5, 5;, src, stride
+lea r3, [r2 + r2 * 2]
+add r1,r3
+lea r3, [r1 + r2]
+lea r4, [r3 + r2 * 4]
+lea r5, [r4 + r2 * 4]
+pxor m4,m4
+%ifnmacro deint_cubic
+;; given 5 lines a,b,c,d,e: a = c-3, b = c-1, d = c+1, e = c + 2
+;; set c = (9b + 9d - a - b)/16
+%macro deint_cubic 5
+mova m0,%1
+mova m1,%2
+mova m2,%4
+mova m3,%5
+pavgb m1,m2 ;(b+d)/2
+pavgb m0,m3 ;(a+e)/2
+;; convert each byte into a word
+mova m2,m1
+punpcklbw m1, m4
+punpckhbw m2, m4
+mova m0,m3
+punpcklbw m0, m4
+punpckhbw m3, m4
+;; calculate the pixel values
+psubw m0, m1 ;L(a+e - (b+d))/2
+psubw m3, m2 ;H(a+e - (b+d))/2
+psraw m0, 3
+psraw m3, 3
+psubw m1, m0 ;L(9(b+d) - (a+e))/16
+psubw m3, m2 ;H(9(b+d) - (a+e))/16
+;; convert the words back into bytes using unsigned saturation
+packuswb m1, m3
+mova %3, m1
+%endmacro
+%endif
+deint_cubic [r1], [r3 + r2], [r3 + r2 *2],\
+[r1 + r2 *4], [r4 + r2]
+deint_cubic [r3 + r2], [r1 + r2 * 4], [r4],\
+[r4 + r2], [r1 + r2 * 8]
+deint_cubic [r1 + r2 * 4], [r4 + r2], [r4 + r2 * 2],\
+[r1 + r2 * 8], [r5]
+deint_cubic [r4 + r2], [r1 + r2 * 8], [r4 + r2 * 4],\
+[r5], [r5 + r2 * 2]
+RET
+%endmacro
+
+;; deinterlace blocks by seting every line n to (n-1 + 2n + n+1)/4
+%macro gen_deinterlace_blend_linear 0
+cglobal deInterlaceBlendLinear, 3, 5, 2 ;src, stride, tmp
+lea r1, [r1 + r2 * 4]
+lea r4, [r1 + r2]
+lea r5, [r4 + r2 * 4]
+mova m0, [r3] ;L0
+mova m1, [r4] ;L2
+mova m2, [r1] ;L1
+pavgb m0, m1 ;L0+L2
+pavgb m0, m2 ;L0 + 2L1 + L2 / 4
+mova [r1], m0
+mova m0, [r4 + r2 * 2] ;L3
+pavgb m2, m0
+pavgb m2, m1
+mova [r4], m2 ;L4
+mova m2, [r4 + r2 * 2]
+pavgb m1, m2
+pavgb m1, m0
+mova [r4+r2], m1 ;L5
+mova m1, [r1 + r2 * 4]
+pavgb m0, m1
+pavgb m0, m2
+mova [r4 + r2 * 2], m0 ;L6
+mova m0, [r5]
+pavgb m2, m0
+pavgb m2, m1
+mova [r1 + r2 * 4], m2 ;L7
+mova m2, [r5 + r2]
+pavgb m1, m2
+pavgb m1, m0
+mova [r5], m1
+mova m1, [r5 + r2 * 2]
+pavgb m0, m1
+pavgb m0, m2
+mova [r5 + r2], m0
+mova m0, [r1 +

[FFmpeg-devel] [FFmpeg-Devel] [GSoC] [PATCH 4/4] Added asm file for deblocking filter

2015-03-22 Thread Tucker DiNapoli 
From: Tucker DiNapoli 

I can't actually test it since there's a lot of work to be done in
interfacing the asm code to the c code, changing block sizes, changing
the way QP's are delt with, etc. But it assembles, there are warnings
for section redeclarations, and I'm not sure how to get rid of those,
but it shouldn't be a big deal.

diff --git a/libpostproc/x86/Makefile b/libpostproc/x86/Makefile
index 06838ca..391be37 100644
--- a/libpostproc/x86/Makefile
+++ b/libpostproc/x86/Makefile
@@ -1 +1,2 @@
 YASM-OBJS-$(CONFIG_POSTPROC) += x86/deinterlace.o
+YASM-OBJS-$(CONFIG_POSTPROC) += x86/deblock.o
diff --git a/libpostproc/x86/PPUtil.asm b/libpostproc/x86/PPUtil.asm
index 090ee18..2d96350 100644
--- a/libpostproc/x86/PPUtil.asm
+++ b/libpostproc/x86/PPUtil.asm
@@ -25,14 +25,34 @@
 ;; Macros to simplify moving packed data
 
 ;; copy low quadword to upper quadword(s)
+;; no-op for mmx
 %macro dup_low_quadword 1
 %if cpuflag(sse2)
 pshufpd %1, %1, 0x00
 %elif cpuflag(avx2)
-vpermq %1, %1, 01010101b
+vpermq %1, %1, 0x00
+%endif
+%endmacro
+;; copy low byte into all other bytes
+%macro dup_low_byte 1-2
+%if cpuflag(avx2)
+;; avx shuffle instructions generally act on the lower 128 and upper 128 bits
+;; independently, so we need to copy the lower 128 bits to the upper 128 bits
+vpermq %1,%1,0x00
+%endif
+%if cpuflag(ssse3)&& %0 == 2
+pxor %2,%2
+pshufb %1,%2
+%else
+punpcklbw %1, %1
+%if cpuflag(sse2)
+pshuflw %1,%1, 0x00
+pshufd %1,%2, 0x00
+%else ;; mmx
+pshufw %1,%1, 0x00
+%endif
 %endif
 %endmacro
-
 ;; move the low half of the mmx/xmm/ymm register in %2 into %1
 ;; %1 should be a memory location
 %macro mov_vector_low_half 2
@@ -114,3 +134,184 @@ SECTION_RODATA 16
 %endif
 SECTION_TEXT
 %endmacro
+;; Utility functions, maybe these should be macros for speed.
+
+;; void duplicate(uint8 *src, int stride)
+;; duplicate block_size pixels 5 times upwards
+cglobal duplicate, 2, 2, 1
+neg r2
+mova m0, [r1]
+mova [r1 + r2 * 4], m0
+add r1, r2
+mova [r1], m0
+mova [r1 + r2], m0
+mova [r1 + r2 * 2], m0
+mova [r1 + r2 * 4], m0
+neg r2
+RET
+;; void blockcopy(uint8_t *dst, int dst_stride, uint8_t *src, int src_stride,
+;;int level_fix, int64_t *packed_offset_and_scale)
+;; Copy src to dst, and possibly fix the brightness
+%macro gen_block_copy 0
+cglobal block_copy, 6, 6, 8
+test r5, r5
+jz .simple
+mova m5, [r6] ;;offset
+mova m6, [r6 + 32] ;;scale
+lea r6, [r3 + r4] ;;dst + dst_stride
+lea r5, [r1 + r2] ;;src + src_stride
+;; I don't know a ton about how to properly order instructions
+;; to maximize pipelining, so this might not be optimial
+%ifnmacro scaled_copy
+%macro scaled_copy 4
+mova m0, %1
+mova m1, m0
+mova m2, %2
+mova m3, m2
+%assign i 0
+%rep 4
+punpcklbw m%i,m%i
+pmulhuw m%i, m6
+psubw m%i, m5
+%assign i i+1
+%endrep
+packuswb m0, m1
+packuswb m2, m3
+mova [%3], m0
+mova [%4], m2
+%endmacro
+%endif
+scaled_copy [r1], [r1 + r2], [r3], [r3 + r4]
+scaled_copy [r1 + r2*2], [r5 + r2*2], [r3 + r4*2], [r6 + r4*2]
+scaled_copy [r1 + r2*4], [r5 + r2*4], [r3 + r4*4], [r6 + r4*4]
+lea r5, [r5 + r2*4] 
+lea r6, [r6 + r3*4]
+scaled_copy [r5 + r2], [r5 + r2*2], [r6 + r4], [r6 + r4*2]
+jmp .end
+.simple: ;;just a simple memcpy
+;;if there's a better way to do this feel free to change it
+;;Any necessary prefetching is done by the caller
+lea r5, [r1 + r2] ;;src + src_stride
+lea r6, [r5 + r2*4] ;;dst + dst_stride
+mova m0, [r1]
+mova m1, [r1 + r2]
+mova m2, [r1 + r2*2]
+mova m3, [r5 + r2*2]
+mova m4, [r1 + r2*4]
+mova m5, [r5 + r2*4]
+mova m6, [r6 + r2]
+mova m7, [r6 + r2*2]
+lea r5, [r3 + r4]
+lea r6, [r5 + r4*4]
+mova m0, [r3]
+mova [r3 + r4], m1
+mova [r3 + r4*2], m2
+mova [r5 + r4*2], m3
+mova [r3 + r4*4], m4
+mova [r5 + r4*4], m5
+mova [r6 + r4], m6
+mova [r6 + r4*2], m7
+.end:
+REP_RET
+%endmacro
+
+;; Macros to emulate the ptest instruction for pre-sse41 cpus
+;; Used to allow branching based on the values of simd registers
+;; set zf if dst & src == 0
+%macro ptest_neq 2-4 ;; dst, src, tmp1, tmp2 ; tmp1,2 are  general purpose 
registers
+%if cpuflag(sse4)
+ptest %1, %2
+%elif cpuflag(sse)
+pcmpeqb %1, %2
+pmovmskb %3, %1
+test %3, %3
+%else ;;mmx
+pand %1, %2
+movd %3, %1
+psrlq %1, 32
+movd %4, %1
+;; we just need to test if any of the bits are set so we can fold the
+;; two 32 bit halves together
+or %3, %4
+test %3, %3
+%endif
+%endmacro
+;; set cf if dst & ~src == 0 (i.e dst == src)
+%macro ptest_eq 2-4 ;;dst, src, tmp1, tmp1 ;tmp1,2 are general purpose 
registers
+%if cpuflag(sse4)
+ptest %1, %2
+%elif cpuflag(sse)
+pcmpeqb %1, %2
+pmovmskb %3, %1
+neg %3 ;;sets cf if operand is non-zero
+%else ;;mmx
+pand %1, %2
+movd %3, %1
+psrlq %1, 32
+movd %4, %1
+

[FFmpeg-devel] [PATCH] lavfi: add inverse telecine filter

2015-03-22 Thread Himangi Saraogi 
This is an exact inverse of the telecine filter unlike previously existing
pullup and fieldmatch ones.

Tested on few samples generated using the telecine filter. Documentation is
yet to be added. Added an additional parameter "start_frame" to allow using
the filter for a stream that was cut and improved pts handling.

---
 Changelog   |   2 +-
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_detelecine.c | 335 
 4 files changed, 338 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/vf_detelecine.c

diff --git a/Changelog b/Changelog
index 4950330..8733203 100644
--- a/Changelog
+++ b/Changelog
@@ -7,7 +7,7 @@ version :
 - DTS lossless extension (XLL) decoding (not lossless, disabled by default)
 - showwavespic filter
 - libdcadec wrapper
-
+- Detelecine filter
 
 version 2.6:
 - nvenc encoder
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 2cde029..73e7adf 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -112,6 +112,7 @@ OBJS-$(CONFIG_DECIMATE_FILTER)   += 
vf_decimate.o
 OBJS-$(CONFIG_DEJUDDER_FILTER)   += vf_dejudder.o
 OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
 OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
+OBJS-$(CONFIG_DETELECINE_FILTER) += vf_detelecine.o
 OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
 OBJS-$(CONFIG_DRAWGRID_FILTER)   += vf_drawbox.o
 OBJS-$(CONFIG_DRAWTEXT_FILTER)   += vf_drawtext.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0288082..6bc01c5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -128,6 +128,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(DEJUDDER,   dejudder,   vf);
 REGISTER_FILTER(DELOGO, delogo, vf);
 REGISTER_FILTER(DESHAKE,deshake,vf);
+REGISTER_FILTER(DETELECINE, detelecine, vf);
 REGISTER_FILTER(DRAWBOX,drawbox,vf);
 REGISTER_FILTER(DRAWGRID,   drawgrid,   vf);
 REGISTER_FILTER(DRAWTEXT,   drawtext,   vf);
diff --git a/libavfilter/vf_detelecine.c b/libavfilter/vf_detelecine.c
new file mode 100644
index 000..36d4e94
--- /dev/null
+++ b/libavfilter/vf_detelecine.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (c) 2015 Himangi Saraogi 
+ *
+ * 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
+ */
+
+/**
+ * @file detelecine filter.
+ */
+
+
+#include "libavutil/avstring.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct {
+const AVClass *class;
+int first_field;
+char *pattern;
+int start_frame;
+unsigned int pattern_pos;
+unsigned int nskip_fields;
+
+AVRational pts;
+int occupied;
+
+int nb_planes;
+int planeheight[4];
+int stride[4];
+
+AVFrame *frame;
+AVFrame *temp;
+} DetelecineContext;
+
+#define OFFSET(x) offsetof(DetelecineContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption detelecine_options[] = {
+{"first_field", "select first field", OFFSET(first_field), 
AV_OPT_TYPE_INT,   {.i64=0}, 0, 1, FLAGS, "field"},
+{"top","select top field first",0, AV_OPT_TYPE_CONST, 
{.i64=0}, 0, 0, FLAGS, "field"},
+{"t",  "select top field first",0, AV_OPT_TYPE_CONST, 
{.i64=0}, 0, 0, FLAGS, "field"},
+{"bottom", "select bottom field first", 0, AV_OPT_TYPE_CONST, 
{.i64=1}, 0, 0, FLAGS, "field"},
+{"b",  "select bottom field first", 0, AV_OPT_TYPE_CONST, 
{.i64=1}, 0, 0, FLAGS, "field"},
+{"pattern", "pattern that describe for how many fields a frame is to be 
displayed", OFFSET(pattern), AV_OPT_TYPE_STRING, {.str="23"}, 0, 0, FLAGS},
+{"start_frame", "position of first frame with respect to the pattern if 
stream is cut", OFFSET(start_frame), AV_OPT_TYPE_INT, {.i64=0}, 0, 13, FLAGS},
+{NULL}
+};
+
+AVFILTER_DEFINE_CLASS(detelecine);
+
+static av_cold int init(AVFilterContext *ctx)
+{
+DetelecineContext *s = ctx->priv

Re: [FFmpeg-devel] [FFmpeg-Devel] [GSoC] [PATCH 4/4] Added asm file for deblocking filter

2015-03-22 Thread Michael Niedermayer 
On Sun, Mar 22, 2015 at 03:48:15PM -0400, Tucker DiNapoli wrote:
> From: Tucker DiNapoli 
> 
> I can't actually test it since there's a lot of work to be done in
> interfacing the asm code to the c code, changing block sizes, changing
> the way QP's are delt with, etc. But it assembles, there are warnings
> for section redeclarations, and I'm not sure how to get rid of those,
> but it shouldn't be a big deal.

fails to build on x86_32


make libpostproc/x86/deblock.o
YASMlibpostproc/x86/deblock.o
libpostproc/x86/PPContext.asm:37: warning: section flags ignored on section 
redeclaration
libpostproc/x86/PPContext.asm:70: warning: section flags ignored on section 
redeclaration
libpostproc/x86/deblock.asm:27: warning: section flags ignored on section 
redeclaration
libpostproc/x86/deblock.asm:27: warning: section flags ignored on section 
redeclaration
libpostproc/x86/deblock.asm:29: warning: section flags ignored on section 
redeclaration
libpostproc/x86/deblock.asm:29: warning: section flags ignored on section 
redeclaration
libpostproc/x86/deblock.asm:494: error: undefined symbol `r7' (first use)
libpostproc/x86/deblock.asm:494: error:  (Each undefined symbol is reported 
only once.)
make: *** [libpostproc/x86/deblock.o] Error 1

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

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [FFmpeg-Devel] [GSoC] [PATCH 4/4] Added asm file for deblocking filter

2015-03-22 Thread James Almer 
On 22/03/15 4:48 PM, Tucker DiNapoli wrote:
> From: Tucker DiNapoli 

[...]

> +;; Utility functions, maybe these should be macros for speed.
> +
> +;; void duplicate(uint8 *src, int stride)
> +;; duplicate block_size pixels 5 times upwards
> +cglobal duplicate, 2, 2, 1
> +neg r2
> +mova m0, [r1]

First gprs is r0, not r1, which is why r7 failed on x86_32 as Michael pointed 
out (r7 on x86_32 would be 
the stack pointer so the %define is not created).

[...]

> +%macro gen_deblock 0
> +;; This is a version of do_a_deblock that should work for mmx,sse and avx
> +;; on x86 and x85_64.
> +cglobal do_a_deblock, 5, 7, 7 ;src, step, stride, ppcontext, mode
> +;;alignment check:
> +;; there might be a better way to do this
> +mov r6, mmsize
> +and r6, rsp
> +jz .aligned
> +sub rsp, r6
> +.aligned:
> +sub rsp, (22*mmsize)+gprsize
> +mov [rsp + 22*mmsize], r6

If you need to allocate space on stack to store stuff, write the amount of 
bytes you need as the fifth 
parameter for cglobal, after amount of xmm regs. x86inc will take care of 
updating the stack pointer and 
dealing with alignment on platforms it knows it's not guaranteed to be aligned 
(msvc for example).
For this case it could be "cglobal do_a_deblock, 5, 7, 7, 22*mmsize" or such.

Read the documentation about PROLOGUE and cglobal in x86inc.asm for more info 
and the constrains you'll 
have to keep in mind (Extra reg needed to store the original pointer if stack 
is not aligned, INIT_YMM 
forcing the usage of said reg regardless of platform since stack is only 
guaranteed to be 16-byte aligned 
by default, etc).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-Devel] [GSoC] [PATCH 1/4] created x86 directory in libpostproc for standalone asm files

2015-03-22 Thread Michael Niedermayer 
On Sun, Mar 22, 2015 at 03:48:12PM -0400, Tucker DiNapoli wrote:
> From: Tucker DiNapoli 
> 
> This patch set contains implementations of various filters from libpostproc,
> translated from inline asm (in postprocess_template.c) into seperate yasm 
> files.
> In addition support for sse2 and avx2 has been added via the use of the simd
> abstraction layer from x86inc.asm. There are 4 assembly files added, one is a 
> file of utility macros, one defines the layout of various structs used in 
> libpostproc
> using the yasm struc directive, one implements several deinterlacing filters 
> and 
> the last implements a deblocking filter. I am used to writing x86 asm for the
> gnu assembler so I'm still somewhat new at using yasm features, so any advice
> on how to better use yasm, better format my assembly, or any advice on my code
> in general would be appricated.
> 

> I would like to submit these patches as my qualification task for the google
> summer of code. It may be hard to test the code as it can't be use with 
> libpostproc 
> as is, this is because a significant part of the summer project is to modify
> the C code to support differing vector sizes. I think trying to change the
> library to interface with this new code is too much to ask for a 
> qualification task,
> but if this code alone isn't enough I can work on something else if need be.

ive refactored postproc a bit so the loop now works in groups of
4 blocks this should make adding in SSE2 and AVX2 easier

also dont hesitate to cleanup the code further (in clean well split
patches though please)

and yes getting some working and testable code in is a requirement for
qualification
i dont think factorizing the code is really that hard but then well
i know the code so things look kind of easier to me

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH] avutil: make AVFrameSideData buffers ref-counted.

2015-03-22 Thread Ronald S. Bultje 
---
 libavutil/frame.c | 171 +++---
 libavutil/frame.h |   1 +
 2 files changed, 98 insertions(+), 74 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 12fe0a6..4596927 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -115,7 +115,7 @@ static void free_side_data(AVFrameSideData **ptr_sd)
 {
 AVFrameSideData *sd = *ptr_sd;
 
-av_freep(&sd->data);
+av_buffer_unref(&sd->buf);
 av_dict_free(&sd->metadata);
 av_freep(ptr_sd);
 }
@@ -275,6 +275,91 @@ int av_frame_get_buffer(AVFrame *frame, int align)
 return AVERROR(EINVAL);
 }
 
+static int frame_copy_props(AVFrame *dst, const AVFrame *src, int force_copy)
+{
+int i;
+
+dst->key_frame  = src->key_frame;
+dst->pict_type  = src->pict_type;
+dst->sample_aspect_ratio= src->sample_aspect_ratio;
+dst->pts= src->pts;
+dst->repeat_pict= src->repeat_pict;
+dst->interlaced_frame   = src->interlaced_frame;
+dst->top_field_first= src->top_field_first;
+dst->palette_has_changed= src->palette_has_changed;
+dst->sample_rate= src->sample_rate;
+dst->opaque = src->opaque;
+#if FF_API_AVFRAME_LAVC
+dst->type   = src->type;
+#endif
+dst->pkt_pts= src->pkt_pts;
+dst->pkt_dts= src->pkt_dts;
+dst->pkt_pos= src->pkt_pos;
+dst->pkt_size   = src->pkt_size;
+dst->pkt_duration   = src->pkt_duration;
+dst->reordered_opaque   = src->reordered_opaque;
+dst->quality= src->quality;
+dst->best_effort_timestamp  = src->best_effort_timestamp;
+dst->coded_picture_number   = src->coded_picture_number;
+dst->display_picture_number = src->display_picture_number;
+dst->flags  = src->flags;
+dst->decode_error_flags = src->decode_error_flags;
+dst->color_primaries= src->color_primaries;
+dst->color_trc  = src->color_trc;
+dst->colorspace = src->colorspace;
+dst->color_range= src->color_range;
+dst->chroma_location= src->chroma_location;
+
+av_dict_copy(&dst->metadata, src->metadata, 0);
+
+memcpy(dst->error, src->error, sizeof(dst->error));
+
+for (i = 0; i < src->nb_side_data; i++) {
+const AVFrameSideData *sd_src = src->side_data[i];
+AVFrameSideData *sd_dst;
+if (   sd_src->type == AV_FRAME_DATA_PANSCAN
+&& (src->width != dst->width || src->height != dst->height))
+continue;
+if (force_copy) {
+sd_dst = av_frame_new_side_data(dst, sd_src->type,
+sd_src->size);
+if (!sd_dst) {
+wipe_side_data(dst);
+return AVERROR(ENOMEM);
+}
+memcpy(sd_dst->data, sd_src->data, sd_src->size);
+} else {
+sd_dst = av_frame_new_side_data(dst, sd_src->type, 0);
+if (!sd_dst) {
+wipe_side_data(dst);
+return AVERROR(ENOMEM);
+}
+sd_dst->buf = av_buffer_ref(sd_src->buf);
+if (!sd_dst->buf) {
+wipe_side_data(dst);
+return AVERROR(ENOMEM);
+}
+sd_dst->data = sd_dst->buf->data;
+sd_dst->size = sd_dst->buf->size;
+}
+av_dict_copy(&sd_dst->metadata, sd_src->metadata, 0);
+}
+
+dst->qscale_table = NULL;
+dst->qstride  = 0;
+dst->qscale_type  = 0;
+if (src->qp_table_buf) {
+dst->qp_table_buf = av_buffer_ref(src->qp_table_buf);
+if (dst->qp_table_buf) {
+dst->qscale_table = dst->qp_table_buf->data;
+dst->qstride  = src->qstride;
+dst->qscale_type  = src->qscale_type;
+}
+}
+
+return 0;
+}
+
 int av_frame_ref(AVFrame *dst, const AVFrame *src)
 {
 int i, ret = 0;
@@ -286,7 +371,7 @@ int av_frame_ref(AVFrame *dst, const AVFrame *src)
 dst->channel_layout = src->channel_layout;
 dst->nb_samples = src->nb_samples;
 
-ret = av_frame_copy_props(dst, src);
+ret = frame_copy_props(dst, src, 0);
 if (ret < 0)
 return ret;
 
@@ -462,72 +547,7 @@ int av_frame_make_writable(AVFrame *frame)
 
 int av_frame_copy_props(AVFrame *dst, const AVFrame *src)
 {
-int i;
-
-dst->key_frame  = src->key_frame;
-dst->pict_type  = src->pict_type;
-dst->sample_aspect_ratio= src->sample_aspect_ratio;
-dst->pts= src->pts;
-dst->repeat_pict= src->repeat_pict;
-dst->interlaced_frame   = src->interlaced_frame;
-dst->top_field_first= src->top_field_first;
-dst->palette_has_changed= src->palette_has_changed;
-dst->sample_rate= src->sample_rate;
-dst->op

Re: [FFmpeg-devel] [PATCH] lavfi: add inverse telecine filter

2015-03-22 Thread Michael Niedermayer 
On Mon, Mar 23, 2015 at 03:43:55AM +0530, Himangi Saraogi wrote:
> This is an exact inverse of the telecine filter unlike previously existing
> pullup and fieldmatch ones.
> 
> Tested on few samples generated using the telecine filter. Documentation is
> yet to be added. Added an additional parameter "start_frame" to allow using
> the filter for a stream that was cut and improved pts handling.

why does the filter not use the input pts?

./ffplay -vf telecine,detelecine matrixbench_mpeg2.mpg
shows AV desync

so does
./ffplay -vf detelecine matrixbench_mpeg2.mpg

and even
./ffplay -vf telecine matrixbench_mpeg2.mpg

i think its maybe best to add to both detelecine and telecine a
ts_mode argument that allows the user to select between
using the first input timestamp and then calculating the rest from
that point on / passing all timestamps through /
droping all and recreating like is now done


[...]
> +
> +frame->pts = outlink->frame_count * 
> av_q2d(av_inv_q(av_mul_q(outlink->frame_rate, outlink->time_base)));

floating point values should be avoided as they can lead to rounding
differences between platforms and cause regression tests to produce
differnt output

the same is true for vf_telecine

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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

[FFmpeg-devel] [PATCH 3/5] doc: More semantic markup using @samp and @var where appropriate

2015-03-22 Thread Timothy Gu 
---
 doc/ffprobe.texi  | 33 +
 doc/filters.texi  | 15 ---
 doc/metadata.texi | 26 +++---
 doc/utils.texi| 10 +-
 4 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/doc/ffprobe.texi b/doc/ffprobe.texi
index 0fdf45e..2024eed 100644
--- a/doc/ffprobe.texi
+++ b/doc/ffprobe.texi
@@ -447,17 +447,17 @@ writer).
 It can assume one of the following values:
 @table @option
 @item c
-Perform C-like escaping. Strings containing a newline ('\n'), carriage
-return ('\r'), a tab ('\t'), a form feed ('\f'), the escaping
-character ('\') or the item separator character @var{SEP} are escaped using 
C-like fashioned
-escaping, so that a newline is converted to the sequence "\n", a
-carriage return to "\r", '\' to "\\" and the separator @var{SEP} is
-converted to "\@var{SEP}".
+Perform C-like escaping. Strings containing a newline (@samp{\n}), carriage
+return (@samp{\r}), a tab (@samp{\t}), a form feed (@samp{\f}), the escaping
+character (@samp{\}) or the item separator character @var{SEP} are escaped
+using C-like fashioned escaping, so that a newline is converted to the
+sequence @samp{\n}, a carriage return to @samp{\r}, @samp{\} to @samp{\\} and
+the separator @var{SEP} is converted to @samp{\@var{SEP}}.
 
 @item csv
 Perform CSV-like escaping, as described in RFC4180.  Strings
-containing a newline ('\n'), a carriage return ('\r'), a double quote
-('"'), or @var{SEP} are enclosed in double-quotes.
+containing a newline (@samp{\n}), a carriage return (@samp{\r}), a double quote
+(@samp{"}), or @var{SEP} are enclosed in double-quotes.
 
 @item none
 Perform no escaping.
@@ -485,7 +485,7 @@ The description of the accepted options follows.
 Separator character used to separate the chapter, the section name, IDs and
 potential tags in the printed field key.
 
-Default value is '.'.
+Default value is @samp{.}.
 
 @item hierarchical, h
 Specify if the section name specification should be hierarchical. If
@@ -507,21 +507,22 @@ The following conventions are adopted:
 @item
 all key and values are UTF-8
 @item
-'.' is the subgroup separator
+@samp{.} is the subgroup separator
 @item
-newline, '\t', '\f', '\b' and the following characters are escaped
+newline, @samp{\t}, @samp{\f}, @samp{\b} and the following characters are
+escaped
 @item
-'\' is the escape character
+@samp{\} is the escape character
 @item
-'#' is the comment indicator
+@samp{#} is the comment indicator
 @item
-'=' is the key/value separator
+@samp{=} is the key/value separator
 @item
-':' is not used but usually parsed as key/value separator
+@samp{:} is not used but usually parsed as key/value separator
 @end itemize
 
 This writer accepts options as a list of @var{key}=@var{value} pairs,
-separated by ":".
+separated by @samp{:}.
 
 The description of the accepted options follows.
 
diff --git a/doc/filters.texi b/doc/filters.texi
index aea7272..8361a0a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -163,13 +163,13 @@ follow the same constraints order of the previous point. 
The following
 
 If the option value itself is a list of items (e.g. the @code{format} filter
 takes a list of pixel formats), the items in the list are usually separated by
-'|'.
+@samp{|}.
 
-The list of arguments can be quoted using the character "'" as initial
-and ending mark, and the character '\' for escaping the characters
+The list of arguments can be quoted using the character @samp{'} as initial
+and ending mark, and the character @samp{\} for escaping the characters
 within the quoted text; otherwise the argument string is considered
 terminated when the next special character (belonging to the set
-"[]=;,") is encountered.
+@samp{[]=;,}) is encountered.
 
 The name and arguments of the filter are optionally preceded and
 followed by a list of link labels.
@@ -4149,7 +4149,7 @@ If @option{expansion} is set to @code{none}, the text is 
printed verbatim.
 If @option{expansion} is set to @code{normal} (which is the default),
 the following expansion mechanism is used.
 
-The backslash character '\', followed by any character, always expands to
+The backslash character @samp{\}, followed by any character, always expands to
 the second character.
 
 Sequence of the form @code{%@{...@}} are expanded. The text between the
@@ -4181,8 +4181,9 @@ value.
 Evaluate the expression's value and output as formatted integer.
 
 The first argument is the expression to be evaluated, just as for the 
@var{expr} function.
-The second argument specifies the output format. Allowed values are 'x', 'X', 
'd' and
-'u'. They are treated exactly as in the printf function.
+The second argument specifies the output format. Allowed values are @samp{x},
+@samp{X}, @samp{d} and @samp{u}. They are treated exactly as in the
+@code{printf} function.
 The third parameter is optional and sets the number of positions taken by the 
output.
 It can be used to add padding with zeros from the left.
 
diff --git a/doc/me

[FFmpeg-devel] [PATCH 1/5] doc/fate: better formatting

2015-03-22 Thread Timothy Gu 
The initial spaces get ignored anyway so let's be consistent with other docs.
---
 doc/fate.texi | 64 +--
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/doc/fate.texi b/doc/fate.texi
index 73c603c..353443a 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -13,36 +13,36 @@
 
 @chapter Introduction
 
-  FATE is an extended regression suite on the client-side and a means
+FATE is an extended regression suite on the client-side and a means
 for results aggregation and presentation on the server-side.
 
-  The first part of this document explains how you can use FATE from
+The first part of this document explains how you can use FATE from
 your FFmpeg source directory to test your ffmpeg binary. The second
 part describes how you can run FATE to submit the results to FFmpeg's
 FATE server.
 
-  In any way you can have a look at the publicly viewable FATE results
+In any way you can have a look at the publicly viewable FATE results
 by visiting this website:
 
-  @url{http://fate.ffmpeg.org/}
+@url{http://fate.ffmpeg.org/}
 
-  This is especially recommended for all people contributing source
+This is especially recommended for all people contributing source
 code to FFmpeg, as it can be seen if some test on some platform broke
 with their recent contribution. This usually happens on the platforms
 the developers could not test on.
 
-  The second part of this document describes how you can run FATE to
+The second part of this document describes how you can run FATE to
 submit your results to FFmpeg's FATE server. If you want to submit your
 results be sure to check that your combination of CPU, OS and compiler
 is not already listed on the above mentioned website.
 
-  In the third part you can find a comprehensive listing of FATE makefile
+In the third part you can find a comprehensive listing of FATE makefile
 targets and variables.
 
 
 @chapter Using FATE from your FFmpeg source directory
 
-  If you want to run FATE on your machine you need to have the samples
+If you want to run FATE on your machine you need to have the samples
 in place. You can get the samples via the build target fate-rsync.
 Use this command from the top-level source directory:
 
@@ -51,11 +51,11 @@ make fate-rsync SAMPLES=fate-suite/
 make fate   SAMPLES=fate-suite/
 @end example
 
-  The above commands set the samples location by passing a makefile
+The above commands set the samples location by passing a makefile
 variable via command line. It is also possible to set the samples
 location at source configuration time by invoking configure with
-`--samples='. Afterwards you can
-invoke the makefile targets without setting the SAMPLES makefile
+@option{--samples=}. Afterwards you can
+invoke the makefile targets without setting the @var{SAMPLES} makefile
 variable. This is illustrated by the following commands:
 
 @example
@@ -64,7 +64,7 @@ make fate-rsync
 make fate
 @end example
 
-  Yet another way to tell FATE about the location of the sample
+Yet another way to tell FATE about the location of the sample
 directory is by making sure the environment variable FATE_SAMPLES
 contains the path to your samples directory. This can be achieved
 by e.g. putting that variable in your shell profile or by setting
@@ -85,7 +85,7 @@ To use a custom wrapper to run the test, pass 
@option{--target-exec} to
 
 @chapter Submitting the results to the FFmpeg result aggregation server
 
-  To submit your results to the server you should run fate through the
+To submit your results to the server you should run fate through the
 shell script @file{tests/fate.sh} from the FFmpeg sources. This script needs
 to be invoked with a configuration file as its first argument.
 
@@ -93,23 +93,23 @@ to be invoked with a configuration file as its first 
argument.
 tests/fate.sh /path/to/fate_config
 @end example
 
-  A configuration file template with comments describing the individual
+A configuration file template with comments describing the individual
 configuration variables can be found at @file{doc/fate_config.sh.template}.
 
 @ifhtml
-  The mentioned configuration template is also available here:
+The mentioned configuration template is also available here:
 @verbatiminclude fate_config.sh.template
 @end ifhtml
 
-  Create a configuration that suits your needs, based on the configuration
-template. The `slot' configuration variable can be any string that is not
+Create a configuration that suits your needs, based on the configuration
+template. The @env{slot} configuration variable can be any string that is not
 yet used, but it is suggested that you name it adhering to the following
-pattern ---. The configuration file
-itself will be sourced in a shell script, therefore all shell features may
-be used. This enables you to setup the environment as you need it for your
-build.
+pattern @samp{@var{arch}-@var{os}-@var{compiler}-@var{compiler version}}. The
+configuration file itsel

[FFmpeg-devel] [PATCH 2/5] Use @verbatim instead of @example for ASCII arts

2015-03-22 Thread Timothy Gu 
Partially fixes #3869.
---
 doc/ffmpeg.texi   | 20 ++--
 doc/ffserver.texi |  6 --
 doc/filters.texi  |  4 ++--
 3 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 1dde682..5a979d5 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -80,7 +80,7 @@ The format option may be needed for raw input files.
 The transcoding process in @command{ffmpeg} for each output can be described by
 the following diagram:
 
-@example
+@verbatim
  ___  __
 |   ||  |
 | input |  demuxer   | encoded data |   decoder
@@ -99,7 +99,7 @@ the following diagram:
 ||   |__|
 
 
-@end example
+@end verbatim
 
 @command{ffmpeg} calls the libavformat library (containing demuxers) to read
 input files and get packets containing encoded data from them. When there are
@@ -124,7 +124,7 @@ Simple filtergraphs are those that have exactly one input 
and output, both of
 the same type. In the above diagram they can be represented by simply inserting
 an additional step between decoding and encoding:
 
-@example
+@verbatim
  ___
 | |  |  |
 | decoded |  | encoded data |
@@ -136,19 +136,19 @@ an additional step between decoding and encoding:
 | frames   |
 |__|
 
-@end example
+@end verbatim
 
 Simple filtergraphs are configured with the per-stream @option{-filter} option
 (with @option{-vf} and @option{-af} aliases for video and audio respectively).
 A simple filtergraph for video can look for example like this:
 
-@example
+@verbatim
  _______
 |   |  | |  |   |  ||
 | input | ---> | deinterlace | ---> | scale | ---> | output |
 |___|  |_|  |___|  ||
 
-@end example
+@end verbatim
 
 Note that some filters change frame properties but not frame contents. E.g. the
 @code{fps} filter in the example above changes number of frames, but does not
@@ -161,7 +161,7 @@ processing chain applied to one stream. This is the case, 
for example, when the
 more than one input and/or output, or when output stream type is different from
 input. They can be represented with the following diagram:
 
-@example
+@verbatim
  _
 | |
 | input 0 |\__
@@ -179,7 +179,7 @@ input. They can be represented with the following diagram:
 | input 2 |/
 |_|
 
-@end example
+@end verbatim
 
 Complex filtergraphs are configured with the @option{-filter_complex} option.
 Note that this option is global, since a complex filtergraph, by its nature,
@@ -198,14 +198,14 @@ step for the specified stream, so it does only demuxing 
and muxing. It is useful
 for changing the container format or modifying container-level metadata. The
 diagram above will, in this case, simplify to this:
 
-@example
+@verbatim
  ___  __
 |   ||  |  ||
 | input |  demuxer   | encoded data |  muxer   | output |
 | file  | -> | packets  | ---> | file   |
 |___||__|  ||
 
-@end example
+@end verbatim
 
 Since there is no decoding or encoding, it is very fast and there is no quality
 loss. However, it might not work in some cases because of many factors. 
Applying
diff --git a/doc/ffserver.texi b/doc/ffserver.texi
index 336cec1..ad48f47 100644
--- a/doc/ffserver.texi
+++ b/doc/ffserver.texi
@@ -118,7 +118,8 @@ Multiple streams can be connected to the same feed.
 
 For example, you can have a situation described by the following
 graph:
-@example
+
+@verbatim
_   __
   | | |  |
 ffmpeg 1 -| feed 1  |-| stream 1 |
@@ -143,7 +144,8 @@ ffmpeg 2 -| feed 3  |-| stream 4 |
   | | |  |
   | file 1  |-| stream 5 |
   |_| |__|
-@end example
+
+@end verbatim
 
 @anchor{FFM}
 @section FFM, FFM2 formats
diff --git a/doc/filters.texi b/doc/filters.texi
index 0654531..aea7272 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8,13 +8,13 @@ outputs.
 To illustrate the sorts of things that are possible, we consider the
 following filtergraph.
 
-@example
+@verbatim
 [main]
 input --> split -> overlay --> output
 | ^
 |[tmp]  [flip]|
 +-> crop --> vflip ---+
-@end example
+@end verbatim
 
 This filtergraph splits the input stream in two streams, then sends one
 stream through the crop filter and the vflip filter, before merging it
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg

[FFmpeg-devel] [PATCH 4/5] doc: Use @lisp where appropriate

2015-03-22 Thread Timothy Gu 
---
 doc/developer.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index a5e9c99..d9ccf7b 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -228,7 +228,7 @@ autocmd InsertEnter * match ForbiddenWhitespace 
/\t\|\s\+\%#\@@http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 5/5] doc: Escape all backslashes needed to be escaped

2015-03-22 Thread Timothy Gu 
No, I do not want to do this, but a user requested it…

I think it is time for us to switch to a better documentation format.

Fixes #3867.
---
 doc/developer.texi |  4 ++--
 doc/encoders.texi  |  4 ++--
 doc/faq.texi   |  8 
 doc/ffmpeg.texi|  4 ++--
 doc/filters.texi   | 60 +++---
 doc/indevs.texi|  2 +-
 doc/metadata.texi  |  6 +++---
 doc/muxers.texi| 38 +-
 doc/protocols.texi |  2 +-
 doc/utils.texi |  8 
 10 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index d9ccf7b..fe8b0bf 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -222,9 +222,9 @@ set cinoptions=(0
 autocmd FileType make,automake set noexpandtab shiftwidth=8 softtabstop=8
 " Trailing whitespace and tabs are forbidden, so highlight them.
 highlight ForbiddenWhitespace ctermbg=red guibg=red
-match ForbiddenWhitespace /\s\+$\|\t/
+match ForbiddenWhitespace 
/@backslashchar{}s@backslashchar{}+$@backslashchar{}|@backslashchar{}t/
 " Do not highlight spaces at the end of line while typing on that line.
-autocmd InsertEnter * match ForbiddenWhitespace /\t\|\s\+\%#\@@ temp1.v < 
/dev/null &
 @{ ffmpeg -i input2.flv -an -f yuv4mpegpipe - < /dev/null | tail -n +2 > 
temp2.v ; @} &
 cat temp1.a temp2.a > all.a &
 cat temp1.v temp2.v > all.v &
-ffmpeg -f u16le -acodec pcm_s16le -ac 2 -ar 44100 -i all.a \
-   -f yuv4mpegpipe -i all.v \
+ffmpeg -f u16le -acodec pcm_s16le -ac 2 -ar 44100 -i all.a @backslashchar{}
+   -f yuv4mpegpipe -i all.v @backslashchar{}
-y output.flv
 rm temp[12].[av] all.[av]
 @end example
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 5a979d5..750b894 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1214,8 +1214,8 @@ proper support for subtitles.
 For example, to hardcode subtitles on top of a DVB-T recording stored in
 MPEG-TS format, delaying the subtitles by 1 second:
 @example
-ffmpeg -i input.ts -filter_complex \
-  '[#0x2ef] setpts=PTS+1/TB [sub] ; [#0x2d0] [sub] overlay' \
+ffmpeg -i input.ts -filter_complex @backslashchar{}
+  '[#0x2ef] setpts=PTS+1/TB [sub] ; [#0x2d0] [sub] overlay' @backslashchar{}
   -sn -map '#0x2dc' output.mkv
 @end example
 (0x2d0, 0x2dc and 0x2ef are the MPEG-TS PIDs of respectively the video,
diff --git a/doc/filters.texi b/doc/filters.texi
index 8361a0a..ac4c667 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -73,9 +73,9 @@ of the filtergraph.
 
 For example the sequence of commands:
 @example
-echo @var{GRAPH_DESCRIPTION} | \
-tools/graph2dot -o graph.tmp && \
-dot -Tpng graph.tmp -o graph.png && \
+echo @var{GRAPH_DESCRIPTION} | @backslashchar{}
+tools/graph2dot -o graph.tmp && @backslashchar{}
+dot -Tpng graph.tmp -o graph.png && @backslashchar{}
 display graph.png
 @end example
 
@@ -248,14 +248,14 @@ this is a 'string': may contain one, or more, special 
characters
 This string contains the @code{'} special escaping character, and the
 @code{:} special character, so it needs to be escaped in this way:
 @example
-text=this is a \'string\'\: may contain one, or more, special characters
+text=this is a @backslashchar{}'string@backslashchar{}'@backslashchar{}: may 
contain one, or more, special characters
 @end example
 
 A second level of escaping is required when embedding the filter
 description in a filtergraph description, in order to escape all the
 filtergraph special characters. Thus the example above becomes:
 @example
-drawtext=text=this is a \\\'string\\\'\\: may contain one\, or more\, special 
characters
+drawtext=text=this is a 
@backslashchar{}@backslashchar{}@backslashchar{}'string@backslashchar{}@backslashchar{}@backslashchar{}'@backslashchar{}@backslashchar{}:
 may contain one@backslashchar{}, or more@backslashchar{}, special characters
 @end example
 (note that in addition to the @code{\'} escaping special characters,
 also @code{,} needs to be escaped).
@@ -266,7 +266,7 @@ escaping rules of the adopted shell. For example, assuming 
that
 @code{\} is special and needs to be escaped with another @code{\}, the
 previous string will finally result in:
 @example
--vf "drawtext=text=this is a \\'string\\': may contain one\\, or 
more\\, special characters"
+-vf "drawtext=text=this is a 
@backslashchar{}@backslashchar{}@backslashchar{}@backslashchar{}@backslashchar{}@backslashchar{}'string@backslashchar{}@backslashchar{}@backslashchar{}@backslashchar{}@backslashchar{}@backslashchar{}'@backslashchar{}@backslashchar{}@backslashchar{}@backslashchar{}:
 may contain one@backslashchar{}@backslashchar{}, or 
more@backslashchar{}@backslashchar{}, special characters"
 @end example
 
 @chapter Timeline editing
@@ -2891,7 +2891,7 @@ boxblur=2:1:cr=0:ar=0
 @item
 Set the luma and chroma radii to a fraction of the video dimension:
 @example
-boxblur=luma_radius=min(h\,w)/10:luma_power=1:chroma_radius=min(cw\,ch)/10:chroma_power=1
+boxblur=luma_radius=min(h@backslashchar