[FFmpeg-devel] [PATCH] msrle: implement vertical offset in 4-bit RLE
The delta escape (2) is supposed to work the same in 4-bit RLE as in
8-bit RLE. This is documented in the MSDN Bitmap Compression page:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx
The unchecked modification of line is safe, since the loop condition
(line >= 0) will check it before any pixel data is written.
Fixes ticket #5153 (output now matches ImageMagick for the provided
sample).
Signed-off-by: Daniel Verkamp
---
libavcodec/msrledec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/msrledec.c b/libavcodec/msrledec.c
index 805802ae18..f0cbde67ff 100644
--- a/libavcodec/msrledec.c
+++ b/libavcodec/msrledec.c
@@ -63,7 +63,7 @@ static int msrle_decode_pal4(AVCodecContext *avctx, AVFrame
*pic,
stream_byte = bytestream2_get_byte(gb);
pixel_ptr += stream_byte;
stream_byte = bytestream2_get_byte(gb);
-avpriv_request_sample(avctx, "Unused stream byte %X",
stream_byte);
+line -= stream_byte;
} else {
// copy pixels from encoded stream
odd_pixel = stream_byte & 1;
--
2.11.0.rc2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Define ETIMEDOUT in fifo_muxer.c for MinGW/Windows fate build.
On Mon, Nov 28, 2016 at 1:22 PM, Gregory J. Wolfe wrote: > Fate failed to build in the MinGW/Windows environment because > macro ETIMEDOUT was undefined. When this condition is detected, > the code now includes <_ptw32.h>, which defines the symbol. > > Signed-off-by: Gregory J. Wolfe > --- > libavformat/tests/fifo_muxer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/tests/fifo_muxer.c b/libavformat/tests/fifo_muxer.c > index 9659198..b579e48 100644 > --- a/libavformat/tests/fifo_muxer.c > +++ b/libavformat/tests/fifo_muxer.c > @@ -25,6 +25,9 @@ > #include "libavutil/avassert.h" > #include "libavformat/avformat.h" > #include "libavformat/url.h" > +#ifndef ETIMEDOUT > +#include <_ptw32.h> > +#endif Should this maybe be including libavformat/network.h, which already has a workaround using the winsock definitions? My local MinGW-w64 installation doesn't have a _ptw32.h file. Thanks, -- Daniel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder
On Tue, Feb 7, 2017 at 10:54 AM, Ronald S. Bultje wrote: > Hi, > > On Tue, Feb 7, 2017 at 12:04 PM, wrote: > >> cinepak, rgb2419.7 (via the fast bilinear swscaler) >> cinepak, internal rgb565 6.0 > > > The reason that your decoder-integrated colorspace convertor is so much > faster than swscale is because swscale is converting internally to yuv420p > using a scaling filter, and then back to rgb565 using another scaling > filter. This is "easily" solved by adding a direct (possibly > x86-simd-accelerated) rgb24-to-rgb565 converter into > libswscale/swscale_unscaled.c, which would likely have nearly identical > performance to what you're seeing here. Possibly even faster, because > you're allowing for simd optimizations. There is already a rgb24-to-rgb565 path, but it does not get used by default because of the needsDither check in ff_get_unscaled_swscale(). If the scaling algorithm is set to fast_bilinear, needsDither is ignored and the RGB24 to RGB16 converter is used. (In either case, no actual scaling is performed, so the scaling algorithm is irrelevant aside from selecting dithering.) Looking at the mplayer docs, this is probably equivalent to '-sws 0'. e.g. ffmpeg -i -f null -c rawvideo -pix_fmt rgb565le -sws_flags fast_bilinear /dev/null Using matrixbench_mpeg2.mpg (720x567) encoded with ffmpeg into Cinepak using default settings, decoding on an i5 3570K, 3.4 GHz: bicubic (default): ~24x realtime fast_bilinear: ~65x realtime patch w/rgb565 override:~154x realtime As far as I can tell, this patch doesn't do any dithering for RGB565, so the fast_bilinear (non-dithering) swscale converter is a fair comparison. -- Daniel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Cross-origin resource error on fate.ffmpeg.org
Hi FFmpeg web folks, When visiting http://fate.ffmpeg.org/ using a browser that enforces CORS[1], loading the FontAwesome icon font causes this error: Font from origin 'https://ffmpeg.org' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://fate.ffmpeg.org' is therefore not allowed access. The fateserver commit that introduced this (b74b380b) includes this change: > diff --git a/index.cgi b/index.cgi > index 7204591..105cb86 100755 > --- a/index.cgi > +++ b/index.cgi > [...] > print "Content-type: text/html\r\n"; > +print "Access-Control-Allow-Origin: https://ffmpeg.org\r\n";; However, this won't help, since the Access-Control-Allow-Origin header needs to be on the requested resource (in this case, fontawesome-webfont.*), not the requester. To make fate.ffmpeg.org work correctly, the above header would need to be added to the web server configuration for the files in ffmpeg.org/fonts with http://fate.ffmpeg.org (or *) as the allowed origin. When testing, be sure to start with a fresh session (e.g. incognito window in Chrome) - if you visit ffmpeg.org first, the font will be cached and the icons on fate.ffmpeg.org will work by accident. Thanks, -- Daniel [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Cross-origin resource error on fate.ffmpeg.org
On Wed, Sep 17, 2014 at 12:59 PM, Michael Niedermayer wrote: > On Wed, Sep 17, 2014 at 11:33:32AM -0700, Daniel Verkamp wrote: >> Hi FFmpeg web folks, >> >> When visiting http://fate.ffmpeg.org/ using a browser that enforces >> CORS[1], loading the FontAwesome icon font causes this error: >> >> Font from origin 'https://ffmpeg.org' has been blocked from loading >> by Cross-Origin Resource Sharing policy: No >> 'Access-Control-Allow-Origin' header is present on the requested >> resource. Origin 'http://fate.ffmpeg.org' is therefore not allowed >> access. [...] > > as you seem to know this / have researched it already > can you post what i need to add to httpd.conf to make this work ? Something like this (untested) should work: Header set Access-Control-Allow-Origin "*" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ac3dsp: remove 3dnow version of float_to_fixed24
This implementation is only used in a very narrow set of circumstances:
it is not bitexact, and there is an SSE implementation, so the 3DNow
version would only get used on K6-II/K6-III/early (pre-XP) Athlon CPUs.
It is completely dead code in x86-64 builds.
Signed-off-by: Daniel Verkamp
---
libavcodec/x86/ac3dsp.asm| 29 -
libavcodec/x86/ac3dsp_init.c | 6 --
2 files changed, 35 deletions(-)
diff --git a/libavcodec/x86/ac3dsp.asm b/libavcodec/x86/ac3dsp.asm
index 675ade3..dbb5dab 100644
--- a/libavcodec/x86/ac3dsp.asm
+++ b/libavcodec/x86/ac3dsp.asm
@@ -212,35 +212,6 @@ AC3_SHIFT r, 32, psrad
; void ff_float_to_fixed24(int32_t *dst, const float *src, unsigned int len)
;-
-; The 3DNow! version is not bit-identical because pf2id uses truncation rather
-; than round-to-nearest.
-INIT_MMX 3dnow
-cglobal float_to_fixed24, 3, 3, 0, dst, src, len
-movq m0, [pf_1_24]
-.loop:
-movq m1, [srcq ]
-movq m2, [srcq+8 ]
-movq m3, [srcq+16]
-movq m4, [srcq+24]
-pfmul m1, m0
-pfmul m2, m0
-pfmul m3, m0
-pfmul m4, m0
-pf2id m1, m1
-pf2id m2, m2
-pf2id m3, m3
-pf2id m4, m4
-movq [dstq ], m1
-movq [dstq+8 ], m2
-movq [dstq+16], m3
-movq [dstq+24], m4
-add srcq, 32
-add dstq, 32
-sub lend, 8
-ja .loop
-femms
-RET
-
INIT_XMM sse
cglobal float_to_fixed24, 3, 3, 3, dst, src, len
movaps m0, [pf_1_24]
diff --git a/libavcodec/x86/ac3dsp_init.c b/libavcodec/x86/ac3dsp_init.c
index eea2736..f229f34 100644
--- a/libavcodec/x86/ac3dsp_init.c
+++ b/libavcodec/x86/ac3dsp_init.c
@@ -41,7 +41,6 @@ void ff_ac3_lshift_int16_sse2(int16_t *src, unsigned int len,
unsigned int shift
void ff_ac3_rshift_int32_mmx (int32_t *src, unsigned int len, unsigned int
shift);
void ff_ac3_rshift_int32_sse2(int32_t *src, unsigned int len, unsigned int
shift);
-void ff_float_to_fixed24_3dnow(int32_t *dst, const float *src, unsigned int
len);
void ff_float_to_fixed24_sse (int32_t *dst, const float *src, unsigned int
len);
void ff_float_to_fixed24_sse2 (int32_t *dst, const float *src, unsigned int
len);
@@ -206,11 +205,6 @@ av_cold void ff_ac3dsp_init_x86(AC3DSPContext *c, int
bit_exact)
c->ac3_lshift_int16 = ff_ac3_lshift_int16_mmx;
c->ac3_rshift_int32 = ff_ac3_rshift_int32_mmx;
}
-if (EXTERNAL_AMD3DNOW(cpu_flags)) {
-if (!bit_exact) {
-c->float_to_fixed24 = ff_float_to_fixed24_3dnow;
-}
-}
if (EXTERNAL_MMXEXT(cpu_flags)) {
c->ac3_exponent_min = ff_ac3_exponent_min_mmxext;
c->ac3_max_msb_abs_int16 = ff_ac3_max_msb_abs_int16_mmxext;
--
2.4.10
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ac3dsp: remove 3dnow version of float_to_fixed24
On Tue, Nov 17, 2015 at 12:00 AM, Daniel Verkamp wrote: > > This implementation is only used in a very narrow set of circumstances: > it is not bitexact, and there is an SSE implementation, so the 3DNow > version would only get used on K6-II/K6-III/early (pre-XP) Athlon CPUs. > It is completely dead code in x86-64 builds. This patch is more or less to "test the waters" for more 3DNow removal patches. The arguments in favor of removal: - Any CPU with 3DNow support but no SSE2 support is 10+ years old (Athlon 64 and the corresponding Opteron introduced SSE2 in 2003), and any with 3DNow but no SSE is going on 15 years old (Athlon XP added SSE in 2001). - Because of the above, nobody is testing this code, so it can easily bit-rot; I have been running a FATE client on an Athlon 64 machine (from 2005!) to help guard against this, but I'd like to toss it, since it's not doing anything else useful aside from heating up the room. (Additionally, this machine is actually *too new* and is being forced via CPUFLAGS to run 3DNow functions, rather than the supported SSE2, so its continued existence is not a proof of users of these optimizations.) - 64-bit builds are carrying this extra code that will never get used. This could be solved by compile-time checks for ARCH_X86_32, but I think that would be a waste of effort compared to just removing the code. - More code means higher maintenance burden when modifying the corresponding functions. Arguments against: - Keeping the existing optimizations has very low cost (but see maintenance and FATE arguments). - The few affected machines will presumably get slightly worse performance from the C/MMX fallbacks. If you do in fact use an affected machine to run FFmpeg, now is the time to speak up: if you post benchmarks proving these optimizations are in fact useful and used, they are less likely to be removed. Thanks, -- Daniel Verkamp ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
