Re: [FFmpeg-devel] [PATCH] ffmpeg: check value of write syscall
On Sat, 25 Jul 2015 00:20:01 -0400
Ganesh Ajjanagadde wrote:
> This makes code slightly more robust and fixes a -Wunused-result
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> ffmpeg.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 751c7d3..aab53e8 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -322,13 +322,15 @@ static int main_return_code = 0;
> static void
> sigterm_handler(int sig)
> {
> +ssize_t num_write;
> received_sigterm = sig;
> received_nb_signals++;
> term_exit_sigsafe();
> if(received_nb_signals > 3) {
> -write(2/*STDERR_FILENO*/, "Received > 3 system signals, hard
> exiting\n",
> +num_write = write(2/*STDERR_FILENO*/, "Received > 3 system signals,
> hard exiting\n",
> strlen("Received > 3 system signals, hard
> exiting\n"));
> -
> +if(num_write < 0)
> +perror("write");
> exit(123);
> }
> }
perror isn't async signal safe, so this makes the code less correct.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
Hello Michael,
Friday, July 24, 2015, 11:24:30 PM, you wrote:
MN> it should be possible to add a parameter (passed through args)
MN> which disables extradata mangling to h264_mp4toannexb_bsf
I'm sorry, I do not see this possibility.
The h264_extradata_to_annexb() into h264_mp4toannexb_bsf replaces
extradata unconditionally.
This function calls by h264_mp4toannexb_filter() under simple
condition:
if (!ctx->extradata_parsed) {
ret = h264_extradata_to_annexb(ctx, avctx,
FF_INPUT_BUFFER_PADDING_SIZE);
<...>
ctx->extradata_parsed = 1;
}
Looks like no any parameters to avoid extradata substitution by
h264_mp4toannexb_bsf.
--
Best regards,
Ivanmailto:ivan.us...@nablet.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
On Sat, Jul 25, 2015 at 12:37:25PM +0300, Ivan Uskov wrote:
> Hello Michael,
>
> Friday, July 24, 2015, 11:24:30 PM, you wrote:
>
>
> MN> it should be possible to add a parameter (passed through args)
> MN> which disables extradata mangling to h264_mp4toannexb_bsf
>
> I'm sorry, I do not see this possibility.
> The h264_extradata_to_annexb() into h264_mp4toannexb_bsf replaces
> extradata unconditionally.
>
> This function calls by h264_mp4toannexb_filter() under simple
> condition:
> if (!ctx->extradata_parsed) {
> ret = h264_extradata_to_annexb(ctx, avctx,
> FF_INPUT_BUFFER_PADDING_SIZE);
> <...>
> ctx->extradata_parsed = 1;
> }
>
> Looks like no any parameters to avoid extradata substitution by
> h264_mp4toannexb_bsf.
yes, h264_mp4toannexb_bsf needs to be changed to optionally support
not doing that.
One way is to use the args for that and for example check for a
specific keyword like "skip_extradata"
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
Hello Michael, Saturday, July 25, 2015, 12:51:36 PM, you wrote: >> Looks like no any parameters to avoid extradata substitution by >> h264_mp4toannexb_bsf. MN> yes, h264_mp4toannexb_bsf needs to be changed to optionally support MN> not doing that. MN> One way is to use the args for that and for example check for a MN> specific keyword like "skip_extradata" Ok, I will think about it, thank you. -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
On Fri, Jul 24, 2015 at 1:34 PM, Ivan Uskov wrote: > Hello All, > > The current implementation of libavcodec/qsvdec_h264.c does not store > original extradata buffer. At the same time the > \libavcodec\h264_mp4toannexb_bsf filter does modify extradata buffer > inplace and fails to process it next time if decoder reinitializes. > So it is not possible to decode mp4 or mkv container using ffmpeg > command line with h264_qsv decoder. > The attached patch solves this issue. The corresponded code was taken > from \libavcodec\crystalhd.c which also uses the h264_mp4toannexb_bsf > filter. > I'm slightly confused by the entire concept here. - Why does the decoder need to re-init anyway? - You want the bsf to convert the bitstream to annexb, but not the extradata? Why not? - Ideally, a decoder should support both bitstream syntax without the bsf, since the bsf is a hack for re-muxing, and many playback applications do not use the bsf since practically no decoder otherwise needs them. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/aacpsdsp: add SSE and SSE3 optimized functions
On Fri, Jul 24, 2015 at 11:00:55PM -0300, James Almer wrote:
> Between 1.5 and 2.5 times faster
>
> Signed-off-by: James Almer
> ---
> There's a couple missing, like ps_stereo_interpolate_ipdopd which i wanted to
> write
> but couldn't test because it was not used by any of the samples i tried.
>
> libavcodec/aacps.c | 4 +-
> libavcodec/aacpsdsp.h | 1 +
> libavcodec/aacpsdsp_template.c | 2 +
> libavcodec/x86/Makefile| 6 +-
> libavcodec/x86/aacpsdsp.asm| 212
> +
> libavcodec/x86/aacpsdsp_init.c | 55 +++
> 6 files changed, 276 insertions(+), 4 deletions(-)
> create mode 100644 libavcodec/x86/aacpsdsp.asm
> create mode 100644 libavcodec/x86/aacpsdsp_init.c
>
> diff --git a/libavcodec/aacps.c b/libavcodec/aacps.c
> index bf60475..eec6e30 100644
> --- a/libavcodec/aacps.c
> +++ b/libavcodec/aacps.c
> @@ -936,8 +936,8 @@ static void stereo_processing(PSContext *ps, INTFLOAT
> (*l)[32][2], INTFLOAT (*r)
> H22[0][e+1][b] = h22;
> }
> for (k = 0; k < NR_BANDS[is34]; k++) {
> -INTFLOAT h[2][4];
> -INTFLOAT h_step[2][4];
> +LOCAL_ALIGNED_16(INTFLOAT, h, [2], [4]);
> +LOCAL_ALIGNED_16(INTFLOAT, h_step, [2], [4]);
> int start = ps->border_position[e];
> int stop = ps->border_position[e+1];
> INTFLOAT width = Q30(1.f) / (stop - start);
> diff --git a/libavcodec/aacpsdsp.h b/libavcodec/aacpsdsp.h
> index 9e3c5aa..c194bbe 100644
> --- a/libavcodec/aacpsdsp.h
> +++ b/libavcodec/aacpsdsp.h
> @@ -52,5 +52,6 @@ typedef struct PSDSPContext {
> void AAC_RENAME(ff_psdsp_init)(PSDSPContext *s);
> void ff_psdsp_init_arm(PSDSPContext *s);
> void ff_psdsp_init_mips(PSDSPContext *s);
> +void ff_psdsp_init_x86(PSDSPContext *s);
>
> #endif /* LIBAVCODEC_AACPSDSP_H */
> diff --git a/libavcodec/aacpsdsp_template.c b/libavcodec/aacpsdsp_template.c
> index bfec828..3049ce8 100644
> --- a/libavcodec/aacpsdsp_template.c
> +++ b/libavcodec/aacpsdsp_template.c
> @@ -224,5 +224,7 @@ av_cold void AAC_RENAME(ff_psdsp_init)(PSDSPContext *s)
> ff_psdsp_init_arm(s);
> if (ARCH_MIPS)
> ff_psdsp_init_mips(s);
> +if (ARCH_X86)
> +ff_psdsp_init_x86(s);
> #endif /* !USE_FIXED */
> }
> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> index a515ebd..c403770 100644
> --- a/libavcodec/x86/Makefile
> +++ b/libavcodec/x86/Makefile
> @@ -38,7 +38,8 @@ OBJS-$(CONFIG_VP8DSP) += x86/vp8dsp_init.o
> OBJS-$(CONFIG_XMM_CLOBBER_TEST)+= x86/w64xmmtest.o
>
> # decoders/encoders
> -OBJS-$(CONFIG_AAC_DECODER) += x86/sbrdsp_init.o
> +OBJS-$(CONFIG_AAC_DECODER) += x86/aacpsdsp_init.o \
> + x86/sbrdsp_init.o
> OBJS-$(CONFIG_ADPCM_G722_DECODER) += x86/g722dsp_init.o
> OBJS-$(CONFIG_ADPCM_G722_ENCODER) += x86/g722dsp_init.o
> OBJS-$(CONFIG_APNG_DECODER)+= x86/pngdsp_init.o
> @@ -130,7 +131,8 @@ YASM-OBJS-$(CONFIG_VP8DSP) += x86/vp8dsp.o
> \
>x86/vp8dsp_loopfilter.o
>
> # decoders/encoders
> -YASM-OBJS-$(CONFIG_AAC_DECODER)+= x86/sbrdsp.o
> +YASM-OBJS-$(CONFIG_AAC_DECODER)+= x86/aacpsdsp.o\
> + x86/sbrdsp.o
> YASM-OBJS-$(CONFIG_ADPCM_G722_DECODER) += x86/g722dsp.o
> YASM-OBJS-$(CONFIG_ADPCM_G722_ENCODER) += x86/g722dsp.o
> YASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
> diff --git a/libavcodec/x86/aacpsdsp.asm b/libavcodec/x86/aacpsdsp.asm
> new file mode 100644
> index 000..d416944
> --- /dev/null
> +++ b/libavcodec/x86/aacpsdsp.asm
> @@ -0,0 +1,212 @@
> +;**
> +;* SIMD optimized MPEG-4 Parametric Stereo decoding functions
> +;*
> +;* Copyright (C) 2015 James Almer
> +;*
> +;* 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 "libavutil/x86/x86util.asm"
> +
> +SECTION_RODATA
> +
> +ps_p1m1p1m1: dd 0, 0x80
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
Hello Hendrik, Saturday, July 25, 2015, 3:13:38 PM, you wrote: HL> I'm slightly confused by the entire concept here. HL> - Why does the decoder need to re-init anyway? Each time when I launch a command line like: ./ffmpeg -c:v h264_qsv -i hd.mp4 -y result.yuv I can see that: 1. decoder opens, 2. decoding until stream detect performs, 3. decoder closes, 4. decoder opens, 5. normal decoding begins. I still not big ffmpeg expert but I suspecting this behavior is by design. HL> - You want the bsf to convert the bitstream to annexb, but not the HL> extradata? Why not? qsv* modules does not touch extradata at all. But at step #5 above the bsf bumped to converted extradata which product of bsf by itself at step #2. So at step #5 bsf confuses and fails. So no mkv and mp4 decoding by h264_qsv at all currently. HL> - Ideally, a decoder should support both bitstream syntax without the HL> bsf, since the bsf is a hack for re-muxing, and many playback HL> applications do not use the bsf since practically no decoder otherwise HL> needs them. Intel's QSV decoder does require annex-b stream, it is documented in SDK reference. I can implement necessary functions to generate annex-b prefixes just into libavcodec/qsvdec_h264.c if Michael will agree this way. -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: check value of write syscall
On Sat, Jul 25, 2015 at 5:16 AM, wm4 wrote:
> On Sat, 25 Jul 2015 00:20:01 -0400
> Ganesh Ajjanagadde wrote:
>
>> This makes code slightly more robust and fixes a -Wunused-result
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> ffmpeg.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index 751c7d3..aab53e8 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -322,13 +322,15 @@ static int main_return_code = 0;
>> static void
>> sigterm_handler(int sig)
>> {
>> +ssize_t num_write;
>> received_sigterm = sig;
>> received_nb_signals++;
>> term_exit_sigsafe();
>> if(received_nb_signals > 3) {
>> -write(2/*STDERR_FILENO*/, "Received > 3 system signals, hard
>> exiting\n",
>> +num_write = write(2/*STDERR_FILENO*/, "Received > 3 system signals,
>> hard exiting\n",
>> strlen("Received > 3 system signals, hard
>> exiting\n"));
>> -
>> +if(num_write < 0)
>> +perror("write");
>> exit(123);
>> }
>> }
>
> perror isn't async signal safe, so this makes the code less correct.
Ok. How about making this errno set by write (if any) become part of
the exit code, e.g by or'ing?
As it stands, the 123 in the exit status sounds quite arbitrary, so
this should be ok,
and gives the parent a chance to distinguish between the two cases.
> ___
> 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] ffmpeg: check value of write syscall
Le septidi 7 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
> >> -write(2/*STDERR_FILENO*/, "Received > 3 system signals, hard
> >> exiting\n",
> >> +num_write = write(2/*STDERR_FILENO*/, "Received > 3 system
> >> signals, hard exiting\n",
> >> strlen("Received > 3 system signals, hard
> >> exiting\n"));
> >> -
> >> +if(num_write < 0)
> >> +perror("write");
> Ok. How about making this errno set by write (if any) become part of
> the exit code, e.g by or'ing?
> As it stands, the 123 in the exit status sounds quite arbitrary, so
> this should be ok,
> and gives the parent a chance to distinguish between the two cases.
IMHO, you are wasting your time here: this error message is not important,
it is only for people who did not notice they had the elbow on the Ctrl key
while their cat was pawing the C key.
More seriously: this message is for informing human users that the reason
for stopping is three signals. The 123 return code is for informing the
parent process of the same condition. They are entirely redundant
(especially with a good shell that has an option to print the error code of
a failed command), and the exit code can not fail. Therefore, we really do
not care if writing the error message fails.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: check value of write syscall
On Sat, Jul 25, 2015 at 10:31 AM, Nicolas George wrote:
> Le septidi 7 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
>> >> -write(2/*STDERR_FILENO*/, "Received > 3 system signals, hard
>> >> exiting\n",
>> >> +num_write = write(2/*STDERR_FILENO*/, "Received > 3 system
>> >> signals, hard exiting\n",
>> >> strlen("Received > 3 system signals, hard
>> >> exiting\n"));
>> >> -
>> >> +if(num_write < 0)
>> >> +perror("write");
>
>> Ok. How about making this errno set by write (if any) become part of
>> the exit code, e.g by or'ing?
>> As it stands, the 123 in the exit status sounds quite arbitrary, so
>> this should be ok,
>> and gives the parent a chance to distinguish between the two cases.
>
> IMHO, you are wasting your time here: this error message is not important,
> it is only for people who did not notice they had the elbow on the Ctrl key
> while their cat was pawing the C key.
>
> More seriously: this message is for informing human users that the reason
> for stopping is three signals. The 123 return code is for informing the
> parent process of the same condition. They are entirely redundant
> (especially with a good shell that has an option to print the error code of
> a failed command), and the exit code can not fail. Therefore, we really do
> not care if writing the error message fails.
The reason I attempted a fix is because books on C/systems programming
are often full of advice like "always check the return value of a
syscall, as they can fail".
I guess this is part of GCC's rationale for -Wunused-result.
The explanation above makes sense, so above advice ought to be "almost always".
Thanks.
>
> Regards,
>
> --
> Nicolas George
>
> ___
> 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
[FFmpeg-devel] [PATCH] QSV MPEG-2 video decoder has been added.
Hello all, The attached patch adding the QSV-based MPEG2 video decoder. Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-QSV-MPEG-2-video-decoder-has-been-added.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/8] lavf/http: Implement server side network code.
Le septidi 7 thermidor, an CCXXIII, Stephan Holljes a écrit :
> Attached patch fixes a bug where a oneshot server would not finish a
> handshake, because s->handshake_finish was not set.
Thanks for the patch series. I have no remarks about 1-5 and 7, except for
one point of API that I will discuss with my comments on patch 8.
> From fb3cc42c64cc4f9e26dc305e2a3f6aacd6f7a001 Mon Sep 17 00:00:00 2001
> From: Stephan Holljes
> Date: Fri, 3 Jul 2015 02:28:56 +0200
> Subject: [PATCH 6/8] lavf/http: Implement server side network code.
>
> add http_accept,
> add http_handshake and move handshake logic there,
> handle connection closing.
>
> Signed-off-by: Stephan Holljes
> ---
> libavformat/http.c | 185
> ++---
> 1 file changed, 162 insertions(+), 23 deletions(-)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 676bfd5..0a2662a 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -25,6 +25,7 @@
> #include
> #endif /* CONFIG_ZLIB */
>
> +#include "libavutil/avassert.h"
> #include "libavutil/avstring.h"
> #include "libavutil/opt.h"
>
> @@ -44,6 +45,11 @@
> * path names). */
> #define BUFFER_SIZE MAX_URL_SIZE
> #define MAX_REDIRECTS 8
> +#define HTTP_SINGLE 1
> +#define HTTP_MUTLI2
> +#define LOWER_PROTO 0
> +#define READ_HEADERS 1
> +#define FINISH2
At this point, you should probably use enums.
Also, I find the names a bit misleading:
- LOWER_PROTO -> we are doing the lower protocol handshake;
- READ_HEADERS -> we are reading the (request line and) headers;
-> FINISH -> we are about to write the reply status line and headers.
I suggest naming the last one something like "WRITE_REPLY_HEADERS", for
consistency. And also adding a fourth value, maybe "FINISHED" or "DONE", see
below and my next mail.
>
> typedef struct HTTPContext {
> const AVClass *class;
> @@ -97,6 +103,11 @@ typedef struct HTTPContext {
> char *method;
> int reconnect;
> int listen;
> +char *resource;
> +int reply_code;
> +int is_multi_client;
> +int handshake_step;
> +int handshake_finish;
> } HTTPContext;
>
> #define OFFSET(x) offsetof(HTTPContext, x)
> @@ -128,7 +139,10 @@ 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 or set the expected HTTP method
> from a client", OFFSET(method), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D
> | 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 | E },
> +{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 =
> 0 }, 0, 2, D | E },
> +{ "resource", "The resource requested by a client", OFFSET(resource),
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
> +{ "reply_code", "The http status code to return to a client",
> OFFSET(reply_code), AV_OPT_TYPE_INT, { .i64 = 200}, INT_MIN, 599, E},
> +{ "handshake_finish", "Indicate that the protocol handshake is to be
> finished", OFFSET(handshake_finish), AV_OPT_TYPE_INT, { .i64 = 0}, 0, 1, E},
Can you explain why this option is needed? I can see a few corner cases
where it would be useful, but nothing important that warrants worrying about
it now.
Also, I suspect 1 would be a better default value.
> { NULL }
> };
>
> @@ -299,51 +313,152 @@ int ff_http_averror(int status_code, int
> default_averror)
> return default_averror;
> }
>
> +static int http_write_reply(URLContext* h, int status_code)
> +{
> +int ret, body = 0, reply_code;
> +const char *reply_text, *content_type;
> +HTTPContext *s = h->priv_data;
> +char message[BUFFER_SIZE];
> +static const char bad_request[] = "Bad Request";
> +static const char forbidden[] = "Forbidden";
> +static const char not_found[] = "Not Found";
> +static const char internal_server_error[] = "Internal server error";
> +static const char ok[] = "OK";
> +static const char oct[] = "application/octet-stream";
> +static const char text[] = "text/plain";
All these constants are used only once: you could write the strings directly
in place, it produces the same result.
> +content_type = text;
> +
> +if (status_code < 0)
> +body = 1;
> +switch (status_code) {
> +case AVERROR_HTTP_BAD_REQUEST:
> +case 400:
> +reply_code = 400;
> +reply_text = bad_request;
> +break;
> +case AVERROR_HTTP_FORBIDDEN:
> +case 403:
> +reply_code = 403;
> +reply_text = forbidden;
> +break;
> +case AVERROR_HTTP_NOT_FOUND:
> +case 404:
> +reply_code = 404;
> +reply_text = not_found;
> +break;
> +case 200:
> +
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
On Sat, Jul 25, 2015 at 04:41:46PM +0300, Ivan Uskov wrote: > Hello Hendrik, > > Saturday, July 25, 2015, 3:13:38 PM, you wrote: > > HL> I'm slightly confused by the entire concept here. > > HL> - Why does the decoder need to re-init anyway? > Each time when I launch a command line like: > ./ffmpeg -c:v h264_qsv -i hd.mp4 -y result.yuv > I can see that: > 1. decoder opens, > 2. decoding until stream detect performs, > 3. decoder closes, > 4. decoder opens, > 5. normal decoding begins. > I still not big ffmpeg expert but I suspecting this behavior is by design. the first opening comes from avformat_find_stream_info() > > HL> - You want the bsf to convert the bitstream to annexb, but not the > HL> extradata? Why not? > qsv* modules does not touch extradata at all. > But at step #5 above the bsf bumped to converted extradata which product of > bsf by itself at step #2. So at step #5 bsf confuses and fails. > So no mkv and mp4 decoding by h264_qsv at all currently. > > HL> - Ideally, a decoder should support both bitstream syntax without the > HL> bsf, since the bsf is a hack for re-muxing, and many playback > HL> applications do not use the bsf since practically no decoder otherwise > HL> needs them. > Intel's QSV decoder does require annex-b stream, it is documented in > SDK reference. > I can implement necessary functions to generate annex-b prefixes just into > libavcodec/qsvdec_h264.c if Michael will agree this way. would this be faster ? avoid a copy/malloc ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/8] doc/example: Add http multi-client example code
Le septidi 7 thermidor, an CCXXIII, Stephan Holljes a écrit :
> Signed-off-by: Stephan Holljes
> ---
> doc/examples/Makefile | 1 +
> doc/examples/http_multiclient.c | 163
>
> 2 files changed, 164 insertions(+)
> create mode 100644 doc/examples/http_multiclient.c
> Changes since last version:
> - Changed license
> - Use simpler code to communicate with the library.
>
> diff --git a/doc/examples/Makefile b/doc/examples/Makefile
> index 9699f11..8c9501b 100644
> --- a/doc/examples/Makefile
> +++ b/doc/examples/Makefile
> @@ -18,6 +18,7 @@ EXAMPLES= avio_list_dir \
> extract_mvs\
> filtering_video\
> filtering_audio\
> +http_multiclient \
> metadata \
> muxing \
> remuxing \
> diff --git a/doc/examples/http_multiclient.c b/doc/examples/http_multiclient.c
> new file mode 100644
> index 000..84fc739
> --- /dev/null
> +++ b/doc/examples/http_multiclient.c
> @@ -0,0 +1,163 @@
> +/*
> + * Copyright (c) 2015 Stephan Holljes
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +/**
> + * @file
> + * libavformat multi-client network API usage example.
> + *
> + * @example http_multiclient.c
> + * This example will serve a file without decoding or demuxing it over http.
> + * Multiple clients can connect and will receive the same file.
> + */
> +
> +#include
> +#include
> +#include
> +
> +void process_client(AVIOContext *client, const char *in_uri)
> +{
> +AVIOContext *input = NULL;
> +uint8_t buf[1024];
> +int ret, n, reply_code;
> +char *resource = NULL;
> +while ((ret = avio_handshake(client)) > 0) {
> +av_log(client, AV_LOG_TRACE, "checking for resource\n");
> +av_opt_get(client, "resource", AV_OPT_SEARCH_CHILDREN, &resource);
> +if (resource && strlen(resource)) {
> +resource++;
> +av_log(client, AV_LOG_TRACE, "got resource: %s (%lu)\n",
> resource, strlen(resource));
> +break;
> +}
> +}
> +
> +if (ret < 0)
> +goto end;
> +
> +if (strcmp(resource, in_uri)) {
Nit: at this point, you can not be sure that resource is not null, unless
you trust the library to never set it to the empty string.
And, nit: you accept unintended resources, for example "invalid" for
"/nvalid".
To fix both issues at once, and IMHO make the code a little bit simpler, you
can move the handling outside the loop: in the loop, just
"if (resource) break;", and after the loop, to test the resource, something
like that:
if (!(resource && resource[0] == '/' && !strcmp(resource, in_uri)))
> +reply_code = AVERROR_HTTP_NOT_FOUND;
> +} else {
> +reply_code = 200;
> +}
> +if ((ret = av_opt_set_int(client, "reply_code", reply_code,
> AV_OPT_SEARCH_CHILDREN)) < 0) {
> +av_log(client, AV_LOG_ERROR, "Failed to set reply_code: %s.\n",
> av_err2str(ret));
> +goto end;
> +}
> +av_log(client, AV_LOG_TRACE, "Set reply code to %d\n", reply_code);
> +
> +if ((ret = av_opt_set_int(client, "handshake_finish", 1,
> AV_OPT_SEARCH_CHILDREN)) < 0) {
As stated earlier, this should be the default.
> +av_log(client, AV_LOG_ERROR, "Failed to set handshake_finish:
> %s.\n", av_err2str(ret));
> +goto end;
> +}
> +
> +while ((ret = avio_handshake(client)) > 0);
There is a small API issue here: if for some reason resource never gets set
(for example someone changes the code to use another protocol than HTTP
where it is optional), then the code is calling avio_handshake() extraneous
times.
For that reason, I think it should b
Re: [FFmpeg-devel] [PATCH] QSV MPEG-2 video decoder has been added.
On Sat, Jul 25, 2015 at 05:48:24PM +0300, Ivan Uskov wrote: > Hello all, > > The attached patch adding the QSV-based MPEG2 video decoder. > Please review. > > > -- > Best regards, > Ivan mailto:ivan.us...@nablet.com > Changelog |1 > configure |4 + > libavcodec/Makefile |1 > libavcodec/allcodecs.c|2 > libavcodec/qsvdec_mpeg2.c | 95 > ++ > libavformat/version.h |4 - > 6 files changed, 105 insertions(+), 2 deletions(-) > 12645ad5e9a0fc68fa137643765352aceb30c090 > 0001-QSV-MPEG-2-video-decoder-has-been-added.patch > From 8ec8da115a157bea491c0f9c0573626e6cdec608 Mon Sep 17 00:00:00 2001 > From: Ivan Uskov > Date: Sat, 25 Jul 2015 10:45:20 -0400 > Subject: [PATCH] QSV MPEG-2 video decoder has been added. applied btw, if qsv_decode_init/qsv_decode_flush arent intended to be used in the future they can be removed and the function pointers left at NULL thanks [...] -- 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] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
Hello Michael, Saturday, July 25, 2015, 6:14:20 PM, you wrote: >> I can implement necessary functions to generate annex-b prefixes just into >> libavcodec/qsvdec_h264.c if Michael will agree this way. MN> would this be faster ? MN> avoid a copy/malloc ? If it implemented inside libavcodec/qsvdec_h264.c then it will use about same code like current bsf implementation uses but with using of private buffer for sps/pps instead public extradata buf using. Here can be the trick to write SPS/PPS directly to QSVContext::input_fifo which implemented recently into qsvdec. It will not solve memory copying necessity but it will solve possible twice memory copying issue when packet re-allocation perform into mp4toannexb filter then data copies again into input_fifo since qsv decoder did not consume previous packet in full. What do you think? -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] QSV MPEG-2 video decoder has been added.
Hello Michael, Saturday, July 25, 2015, 6:30:14 PM, you wrote: MN> btw, if qsv_decode_init/qsv_decode_flush arent intended to be used MN> in the future they can be removed and the function pointers left at MN> NULL Ok, thank. -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/aacpsdsp: add SSE and SSE3 optimized functions
Between 1.5 and 2.5 times faster
Signed-off-by: James Almer
---
libavcodec/aacps.c | 4 +-
libavcodec/aacpsdsp.h | 1 +
libavcodec/aacpsdsp_template.c | 2 +
libavcodec/x86/Makefile| 6 +-
libavcodec/x86/aacpsdsp.asm| 215 +
libavcodec/x86/aacpsdsp_init.c | 55 +++
6 files changed, 279 insertions(+), 4 deletions(-)
create mode 100644 libavcodec/x86/aacpsdsp.asm
create mode 100644 libavcodec/x86/aacpsdsp_init.c
diff --git a/libavcodec/aacps.c b/libavcodec/aacps.c
index 664330d..1165d9b 100644
--- a/libavcodec/aacps.c
+++ b/libavcodec/aacps.c
@@ -936,8 +936,8 @@ static void stereo_processing(PSContext *ps, INTFLOAT
(*l)[32][2], INTFLOAT (*r)
H22[0][e+1][b] = h22;
}
for (k = 0; k < NR_BANDS[is34]; k++) {
-INTFLOAT h[2][4];
-INTFLOAT h_step[2][4];
+LOCAL_ALIGNED_16(INTFLOAT, h, [2], [4]);
+LOCAL_ALIGNED_16(INTFLOAT, h_step, [2], [4]);
int start = ps->border_position[e];
int stop = ps->border_position[e+1];
INTFLOAT width = Q30(1.f) / (stop - start);
diff --git a/libavcodec/aacpsdsp.h b/libavcodec/aacpsdsp.h
index 9e3c5aa..c194bbe 100644
--- a/libavcodec/aacpsdsp.h
+++ b/libavcodec/aacpsdsp.h
@@ -52,5 +52,6 @@ typedef struct PSDSPContext {
void AAC_RENAME(ff_psdsp_init)(PSDSPContext *s);
void ff_psdsp_init_arm(PSDSPContext *s);
void ff_psdsp_init_mips(PSDSPContext *s);
+void ff_psdsp_init_x86(PSDSPContext *s);
#endif /* LIBAVCODEC_AACPSDSP_H */
diff --git a/libavcodec/aacpsdsp_template.c b/libavcodec/aacpsdsp_template.c
index bfec828..3049ce8 100644
--- a/libavcodec/aacpsdsp_template.c
+++ b/libavcodec/aacpsdsp_template.c
@@ -224,5 +224,7 @@ av_cold void AAC_RENAME(ff_psdsp_init)(PSDSPContext *s)
ff_psdsp_init_arm(s);
if (ARCH_MIPS)
ff_psdsp_init_mips(s);
+if (ARCH_X86)
+ff_psdsp_init_x86(s);
#endif /* !USE_FIXED */
}
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index a515ebd..c403770 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -38,7 +38,8 @@ OBJS-$(CONFIG_VP8DSP) += x86/vp8dsp_init.o
OBJS-$(CONFIG_XMM_CLOBBER_TEST)+= x86/w64xmmtest.o
# decoders/encoders
-OBJS-$(CONFIG_AAC_DECODER) += x86/sbrdsp_init.o
+OBJS-$(CONFIG_AAC_DECODER) += x86/aacpsdsp_init.o \
+ x86/sbrdsp_init.o
OBJS-$(CONFIG_ADPCM_G722_DECODER) += x86/g722dsp_init.o
OBJS-$(CONFIG_ADPCM_G722_ENCODER) += x86/g722dsp_init.o
OBJS-$(CONFIG_APNG_DECODER)+= x86/pngdsp_init.o
@@ -130,7 +131,8 @@ YASM-OBJS-$(CONFIG_VP8DSP) += x86/vp8dsp.o
\
x86/vp8dsp_loopfilter.o
# decoders/encoders
-YASM-OBJS-$(CONFIG_AAC_DECODER)+= x86/sbrdsp.o
+YASM-OBJS-$(CONFIG_AAC_DECODER)+= x86/aacpsdsp.o\
+ x86/sbrdsp.o
YASM-OBJS-$(CONFIG_ADPCM_G722_DECODER) += x86/g722dsp.o
YASM-OBJS-$(CONFIG_ADPCM_G722_ENCODER) += x86/g722dsp.o
YASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
diff --git a/libavcodec/x86/aacpsdsp.asm b/libavcodec/x86/aacpsdsp.asm
new file mode 100644
index 000..d4dfd5b
--- /dev/null
+++ b/libavcodec/x86/aacpsdsp.asm
@@ -0,0 +1,215 @@
+;**
+;* SIMD optimized MPEG-4 Parametric Stereo decoding functions
+;*
+;* Copyright (C) 2015 James Almer
+;*
+;* 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 "libavutil/x86/x86util.asm"
+
+SECTION_RODATA
+
+ps_p1m1p1m1: dd 0, 0x8000, 0, 0x8000
+
+SECTION_TEXT
+
+;*
+;void ff_ps_add_squares_(float *dst, const float (*src)[2], int n);
+;*
+%macro PS_ADD_SQUARES 1
+cglobal ps_add_squares, 3, 3, %1, dst, src, n
+.loop:
+movaps m0, [srcq]
+movaps m1, [srcq+mmsize]
+mulps m0, m0
+mulps m1, m1
+%if cpuflag(sse3)
+
[FFmpeg-devel] [PATCH] avcodec: Add QSV VC-1 video decoder.
Hello all, This patch adds QSV-based VC-1 video decoder. Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-avcodec-Add-QSV-VC-1-video-decoder.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
On Sat, Jul 25, 2015 at 07:00:00PM +0300, Ivan Uskov wrote: > Hello Michael, > > Saturday, July 25, 2015, 6:14:20 PM, you wrote: > > >> I can implement necessary functions to generate annex-b prefixes just into > >> libavcodec/qsvdec_h264.c if Michael will agree this way. > > MN> would this be faster ? > MN> avoid a copy/malloc ? > If it implemented inside libavcodec/qsvdec_h264.c then it will use > about same code like current bsf implementation uses but with using of > private buffer for sps/pps instead public extradata buf using. > > Here can be the trick to write SPS/PPS directly to > QSVContext::input_fifo which implemented recently into qsvdec. > It will not solve memory copying necessity but it will solve possible twice > memory > copying issue when packet re-allocation perform into mp4toannexb filter then > data copies again into input_fifo since qsv decoder did not consume > previous packet in full. What do you think? does this affect a large memcpy() on a common path ? if it avoids just a rare or small case then its not worth it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
Hello Michael, Saturday, July 25, 2015, 8:21:44 PM, you wrote: >> MN> would this be faster ? >> MN> avoid a copy/malloc ? >> If it implemented inside libavcodec/qsvdec_h264.c then it will use >> about same code like current bsf implementation uses but with using of >> private buffer for sps/pps instead public extradata buf using. >> >> Here can be the trick to write SPS/PPS directly to >> QSVContext::input_fifo which implemented recently into qsvdec. >> It will not solve memory copying necessity but it will solve possible twice >> memory >> copying issue when packet re-allocation perform into mp4toannexb filter then >> data copies again into input_fifo since qsv decoder did not consume >> previous packet in full. What do you think? MN> does this affect a large memcpy() on a common path ? MN> if it avoids just a rare or small case then its not worth it I believe this trick will no give visible improvement in performance. Just small win in some rare cases. -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Add QSV VC-1 video decoder.
On Sat, Jul 25, 2015 at 07:31:33PM +0300, Ivan Uskov wrote:
> Hello all,
>
> This patch adds QSV-based VC-1 video decoder.
> Please review.
>
>
> --
> Best regards,
> Ivan mailto:ivan.us...@nablet.com
> Changelog |1
> configure |4 ++
> libavcodec/Makefile |1
> libavcodec/allcodecs.c |2 +
> libavcodec/qsvdec_vc1.c | 88
>
> libavcodec/version.h|2 -
> 6 files changed, 97 insertions(+), 1 deletion(-)
> a8ae16fe126453683b69752e769b922daa1448ee
> 0001-avcodec-Add-QSV-VC-1-video-decoder.patch
> From ac28512c10972b3ce1477d81201055b09efe857a Mon Sep 17 00:00:00 2001
> From: Ivan Uskov
> Date: Sat, 25 Jul 2015 12:28:11 -0400
> Subject: [PATCH] avcodec: Add QSV VC-1 video decoder.
applied
thanks
[..]
> +AVCodec ff_vc1_qsv_decoder = {
> +.name = "vc1_qsv",
> +.long_name = NULL_IF_CONFIG_SMALL("VC-1 video (Intel Quick Sync
> Video acceleration)"),
> +.priv_data_size = sizeof(QSVVC1Context),
> +.type = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_VC1,
> +.init = NULL,
PS: you could ommit these, as global variables are always 0/NULL
initialized
but thats not important
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
On Sat, Jul 25, 2015 at 09:02:55PM +0300, Ivan Uskov wrote: > Hello Michael, > > Saturday, July 25, 2015, 8:21:44 PM, you wrote: > >> MN> would this be faster ? > >> MN> avoid a copy/malloc ? > >> If it implemented inside libavcodec/qsvdec_h264.c then it will use > >> about same code like current bsf implementation uses but with using of > >> private buffer for sps/pps instead public extradata buf using. > >> > >> Here can be the trick to write SPS/PPS directly to > >> QSVContext::input_fifo which implemented recently into qsvdec. > >> It will not solve memory copying necessity but it will solve possible > >> twice memory > >> copying issue when packet re-allocation perform into mp4toannexb filter > >> then > >> data copies again into input_fifo since qsv decoder did not consume > >> previous packet in full. What do you think? > > MN> does this affect a large memcpy() on a common path ? > > MN> if it avoids just a rare or small case then its not worth it > I believe this trick will no give visible improvement in performance. > Just small win in some rare cases. then its better to avoid duplicating the bitstream filter [...] -- 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] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
Hello Michael, Saturday, July 25, 2015, 9:11:34 PM, you wrote: >> MN> if it avoids just a rare or small case then its not worth it >> I believe this trick will no give visible improvement in performance. >> Just small win in some rare cases. MN> then its better to avoid duplicating the bitstream filter So, the preferred way is modification the existing bsf to have an optional mode when bsf does not touch context extradata, correct? -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] libavutil/softfloat: Add functions.
On Thu, Apr 30, 2015 at 01:51:37PM +0200, Nedeljko Babic wrote: > Functions av_gt_sf, av_sqrt_sf and av_sincos_sf added to softfloat > > Signed-off-by: Nedeljko Babic > --- > libavutil/softfloat.h| 93 +++- > libavutil/softfloat_tables.h | 260 > +++ > 2 files changed, 352 insertions(+), 1 deletion(-) > create mode 100644 libavutil/softfloat_tables.h [...] > +/** > + * Rounding-to-nearest used. > + */ > +static av_always_inline void av_sincos_sf(int a, int *s, int *c) this function seems to be buggy the sine values are very accurate but the cosine values are not look: (tested with libavutil/softfloat-test and tightened up thresholds) sincos FAIL 8 0.642788 0.766263 0.642788 0.766044 sincos FAIL 14 0.939693 0.342220 0.939693 0.342020 sincos FAIL 15 0.965926 0.259066 0.965926 0.258819 sincos FAIL 16 0.984808 0.173942 0.984808 0.173648 sincos FAIL 17 0.996195 0.087495 0.996195 0.087156 sincos FAIL 24 0.866025 -0.499779 0.866025 -0.50 sincos FAIL 25 0.819152 -0.573332 0.819152 -0.573576 sincos FAIL 26 0.766044 -0.642526 0.766044 -0.642788 sincos FAIL 44 -0.642788 -0.766263 -0.642788 -0.766044 sincos FAIL 50 -0.939693 -0.342220 -0.939693 -0.342020 sincos FAIL 51 -0.965926 -0.259066 -0.965926 -0.258819 sincos FAIL 52 -0.984808 -0.173942 -0.984808 -0.173648 sincos FAIL 53 -0.996195 -0.087495 -0.996195 -0.087156 sincos FAIL 60 -0.866025 0.499779 -0.866025 0.50 sincos FAIL 61 -0.819152 0.573332 -0.819152 0.573576 sincos FAIL 62 -0.766044 0.642526 -0.766044 0.642788 sincos FAIL 80 0.642788 0.766263 0.642788 0.766044 sincos FAIL 86 0.939693 0.342220 0.939693 0.342020 sincos FAIL 87 0.965926 0.259066 0.965926 0.258819 sincos FAIL 88 0.984808 0.173942 0.984808 0.173648 sincos FAIL 89 0.996195 0.087495 0.996195 0.087156 sincos FAIL 96 0.866025 -0.499779 0.866025 -0.50 sincos FAIL 97 0.819152 -0.573332 0.819152 -0.573576 sincos FAIL 98 0.766044 -0.642526 0.766044 -0.642788 sincos FAIL 116 -0.642788 -0.766263 -0.642788 -0.766044 sincos FAIL 122 -0.939693 -0.342220 -0.939693 -0.342020 sincos FAIL 123 -0.965926 -0.259066 -0.965926 -0.258819 sincos FAIL 124 -0.984808 -0.173942 -0.984808 -0.173648 sincos FAIL 125 -0.996195 -0.087495 -0.996195 -0.087156 sincos FAIL 132 -0.866025 0.499779 -0.866025 0.50 sincos FAIL 133 -0.819152 0.573332 -0.819152 0.573576 sincos FAIL 134 -0.766044 0.642526 -0.766044 0.642788 [...] -- 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] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.
On Sat, Jul 25, 2015 at 09:21:58PM +0300, Ivan Uskov wrote: > Hello Michael, > > Saturday, July 25, 2015, 9:11:34 PM, you wrote: > > >> MN> if it avoids just a rare or small case then its not worth it > >> I believe this trick will no give visible improvement in performance. > >> Just small win in some rare cases. > > MN> then its better to avoid duplicating the bitstream filter > So, the preferred way is modification the existing bsf to have an > optional mode when bsf does not touch context extradata, correct? it seems a possible solution i dont know what is the best solution [...] -- 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 7/8] tests: Add aac_fixed decoder test
Hi On Sat, Jul 25, 2015 at 05:37:56AM +0200, Michael Niedermayer wrote: > On Mon, Jul 20, 2015 at 01:36:21PM +0200, Nedeljko Babic wrote: > > Signed-off-by: Nedeljko Babic > > --- > > tests/fate/aac.mak | 58 > > +- > > 1 file changed, 57 insertions(+), 1 deletion(-) > > these tests fail on clang with -ftrapv > see > http://fate.ffmpeg.org/report.cgi?time=20150723144015&slot=x86_64-freebsd10-clang33-ftrapv i fixed one ftrapv issue but a 2nd remains, it seems the code filters uninitialized and then not used data. Please fix this unless someone else does before also SBR seems to fails on ARM http://fate.ffmpeg.org/report.cgi?time=20150725003242&slot=armv7l-panda-gcc4.6-armv5 it does pass under qemu ARM though it seems i did test your code on qemu arm not actual arm before i pushed, didnt thought that would make a difference [...] -- 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
[FFmpeg-devel] [PATCH 1/2] libavcodec/h264_mp4toannexb_bsf.c: Optional argument "private_spspps_buf" to avoid extradata modification.
Hello all, This patch implements optional mode which disables context extradata modification by bsf. The modification of extradata become an issue when bsf restarts (after stream detection for example). Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-libavcodec-h264_mp4toannexb_bsf.c-Optional-argument-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libavcodec/qsvdec_h264.c: using "private_spspps_buf" argument for av_bitstream_filter_filter() to avoid failure after decoder re-initialization.
Hello All This patch uses new "private_spspps_buf" argument of h264_mp4toannexb_bsf.c. This allow to fix bug when the qsvdec_h264.c decoder is not able to decode mp4 and mkv. Please review. -- Best regards, Ivanmailto:ivan.us...@nablet.com 0002-libavcodec-qsvdec_h264.c-using-private_spspps_buf-ar.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/h264_mp4toannexb_bsf.c: Optional argument "private_spspps_buf" to avoid extradata modification.
On Sun, Jul 26, 2015 at 12:04:30AM +0300, Ivan Uskov wrote: > Hello all, > > This patch implements optional mode which disables context > extradata modification by bsf. The modification of extradata become > an issue when bsf restarts (after stream detection for example). > Please review. > > > -- > Best regards, > Ivan mailto:ivan.us...@nablet.com > h264_mp4toannexb_bsf.c | 41 ++--- > 1 file changed, 34 insertions(+), 7 deletions(-) > b4749c51f00935721478223c2cee2e75cd0f286d > 0001-libavcodec-h264_mp4toannexb_bsf.c-Optional-argument-.patch > From 84ab7152c51728ffd19af82210d61da6b8caa6fa Mon Sep 17 00:00:00 2001 > From: Ivan Uskov > Date: Sat, 25 Jul 2015 16:11:30 -0400 > Subject: [PATCH 1/2] libavcodec/h264_mp4toannexb_bsf.c: Optional argument > "private_spspps_buf" to avoid extradata modification. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/qsvdec_h264.c: using "private_spspps_buf" argument for av_bitstream_filter_filter() to avoid failure after decoder re-initialization.
On Sun, Jul 26, 2015 at 12:07:05AM +0300, Ivan Uskov wrote: > Hello All > > This patch uses new "private_spspps_buf" argument of > h264_mp4toannexb_bsf.c. This allow to fix bug when the qsvdec_h264.c > decoder is not able to decode mp4 and mkv. > Please review. > > -- > Best regards, > Ivanmailto:ivan.us...@nablet.com > qsvdec_h264.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > d680802d3fcda587a0b8bf8a80d6784c98493f45 > 0002-libavcodec-qsvdec_h264.c-using-private_spspps_buf-ar.patch > From 75f769ef468249859c2bd2f63c9099eb131d3e82 Mon Sep 17 00:00:00 2001 > From: Ivan Uskov > Date: Sat, 25 Jul 2015 15:56:08 -0400 > Subject: [PATCH 2/2] libavcodec/qsvdec_h264.c: using "private_spspps_buf" > argument for av_bitstream_filter_filter() to avoid failure after decoder > re-initialization. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/texturedsp: fix undefined shift
On 25/07/15 12:59 AM, Michael Niedermayer wrote: > On Fri, Jul 24, 2015 at 10:14:00PM -0300, James Almer wrote: >> Silences warnings when using -Wshift-overflow (GCC 6+) >> >> Signed-off-by: James Almer >> --- >> libavcodec/texturedsp.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > LGTM > > thanks Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Webvtt in hls muxer
On Thu, Jun 04, 2015 at 01:33:35PM +0530, Anshul wrote: > Hello > > New patch to remove merge conflicts. > > -Anshul > hlsenc.c | 202 > +++ > 1 file changed, 192 insertions(+), 10 deletions(-) > 3bf30e70251b47f644cc999e23c0b237e9952c08 0001-Add-WebVtt-support-in-hls.patch > From 4433686fdc62f9aebe23937b51b641febacfa2fe Mon Sep 17 00:00:00 2001 > From: Anshul Maheshwari > Date: Thu, 4 Jun 2015 13:25:52 +0530 > Subject: [PATCH] Add WebVtt support in hls > > Signed-off-by: Anshul Maheshwari applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
