[FFmpeg-devel] [PATCH] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for HEVC uni hv mc functions
From: Shivraj Patil shivraj.pa...@imgtec.com
Signed-off-by: Shivraj Patil shivraj.pa...@imgtec.com
---
libavcodec/mips/hevcdsp_init_mips.c | 9 +
libavcodec/mips/hevcdsp_mips.h | 9 +
libavcodec/mips/hevcdsp_msa.c | 512
3 files changed, 530 insertions(+)
diff --git a/libavcodec/mips/hevcdsp_init_mips.c
b/libavcodec/mips/hevcdsp_init_mips.c
index 1e22f35..d2e3c60 100644
--- a/libavcodec/mips/hevcdsp_init_mips.c
+++ b/libavcodec/mips/hevcdsp_init_mips.c
@@ -87,6 +87,15 @@ static av_cold void hevc_dsp_init_msa(HEVCDSPContext *c,
c-put_hevc_qpel_uni[7][1][0] = ff_hevc_put_hevc_uni_qpel_v32_8_msa;
c-put_hevc_qpel_uni[8][1][0] = ff_hevc_put_hevc_uni_qpel_v48_8_msa;
c-put_hevc_qpel_uni[9][1][0] = ff_hevc_put_hevc_uni_qpel_v64_8_msa;
+
+c-put_hevc_qpel_uni[1][1][1] = ff_hevc_put_hevc_uni_qpel_hv4_8_msa;
+c-put_hevc_qpel_uni[3][1][1] = ff_hevc_put_hevc_uni_qpel_hv8_8_msa;
+c-put_hevc_qpel_uni[4][1][1] = ff_hevc_put_hevc_uni_qpel_hv12_8_msa;
+c-put_hevc_qpel_uni[5][1][1] = ff_hevc_put_hevc_uni_qpel_hv16_8_msa;
+c-put_hevc_qpel_uni[6][1][1] = ff_hevc_put_hevc_uni_qpel_hv24_8_msa;
+c-put_hevc_qpel_uni[7][1][1] = ff_hevc_put_hevc_uni_qpel_hv32_8_msa;
+c-put_hevc_qpel_uni[8][1][1] = ff_hevc_put_hevc_uni_qpel_hv48_8_msa;
+c-put_hevc_qpel_uni[9][1][1] = ff_hevc_put_hevc_uni_qpel_hv64_8_msa;
}
}
#endif // #if HAVE_MSA
diff --git a/libavcodec/mips/hevcdsp_mips.h b/libavcodec/mips/hevcdsp_mips.h
index 76a6784..a8c8848 100644
--- a/libavcodec/mips/hevcdsp_mips.h
+++ b/libavcodec/mips/hevcdsp_mips.h
@@ -106,4 +106,13 @@ UNI_MC(qpel, v, 32);
UNI_MC(qpel, v, 48);
UNI_MC(qpel, v, 64);
+UNI_MC(qpel, hv, 4);
+UNI_MC(qpel, hv, 8);
+UNI_MC(qpel, hv, 12);
+UNI_MC(qpel, hv, 16);
+UNI_MC(qpel, hv, 24);
+UNI_MC(qpel, hv, 32);
+UNI_MC(qpel, hv, 48);
+UNI_MC(qpel, hv, 64);
+
#undef UNI_MC
diff --git a/libavcodec/mips/hevcdsp_msa.c b/libavcodec/mips/hevcdsp_msa.c
index d0e6f64..781264d 100644
--- a/libavcodec/mips/hevcdsp_msa.c
+++ b/libavcodec/mips/hevcdsp_msa.c
@@ -46,6 +46,24 @@
out;
\
} )
+#define HEVC_RND_W_CLIP_UNSIGNED_CHAR_W_VEC2(vec0_r, vec0_l, \
+ vec1_r, vec1_l, \
+ out0, out1) \
+{ \
+(vec0_r) = __msa_srari_w((vec0_r), 6); \
+(vec0_l) = __msa_srari_w((vec0_l), 6); \
+(vec1_r) = __msa_srari_w((vec1_r), 6); \
+(vec1_l) = __msa_srari_w((vec1_l), 6); \
+ \
+(vec0_r) = CLIP_UNSIGNED_CHAR_W((vec0_r)); \
+(vec0_l) = CLIP_UNSIGNED_CHAR_W((vec0_l)); \
+(vec1_r) = CLIP_UNSIGNED_CHAR_W((vec1_r)); \
+(vec1_l) = CLIP_UNSIGNED_CHAR_W((vec1_l)); \
+ \
+out0 = (v4i32) __msa_pckev_h((v8i16) (vec0_l), (v8i16) (vec0_r)); \
+out1 = (v4i32) __msa_pckev_h((v8i16) (vec1_l), (v8i16) (vec1_r)); \
+}
+
static void hevc_copy_4w_msa(uint8_t * __restrict src, int32_t src_stride,
int16_t * __restrict dst, int32_t dst_stride,
int32_t height)
@@ -2270,6 +2288,469 @@ static void hevc_hv_8t_64w_msa(uint8_t * __restrict
src, int32_t src_stride,
filter_x, filter_y, height, 64);
}
+static void hevc_hv_uni_8t_4w_msa(uint8_t * __restrict src,
+ int32_t src_stride,
+ uint8_t * __restrict dst,
+ int32_t dst_stride,
+ const int8_t * __restrict filter_x,
+ const int8_t * __restrict filter_y,
+ int32_t height)
+{
+uint32_t loop_cnt;
+uint32_t out0, out1;
+v16i8 src0, src1, src2, src3, src4, src5, src6, src7, src8;
+v8i16 filt0, filt1, filt2, filt3, filter_vec;
+v4i32 filt_h0, filt_h1, filt_h2, filt_h3;
+v16i8 mask1, mask2, mask3;
+v8u16 const_vec;
+v16i8 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7;
+v16i8 vec8, vec9, vec10, vec11, vec12, vec13, vec14, vec15;
+v8i16 dst30, dst41, dst52, dst63, dst66, dst87;
+v4i32 dst0_r, dst1_r;
+v8i16 dst10_r, dst32_r, dst54_r, dst76_r;
+v8i16 dst21_r, dst43_r, dst65_r, dst87_r;
+v16i8 tmp;
+v16i8 mask0 = { 0, 1, 1, 2, 2, 3, 3, 4, 16, 17, 17, 18, 18, 19, 19, 20 };
+v8i16 mask4 = { 0, 4, 1, 5, 2, 6, 3, 7 };
+
+src -= ((3 * src_stride) + 3);
+
+filter_vec =
[FFmpeg-devel] [PATCH 1/3] configure: replace arch loongson with arch extra list loongson
From 2836a9b83ab781920b9d048ef9ce2acf9061a2a7 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Thu, 7 May 2015 11:12:17 +0800 Subject: [PATCH 1/3] configure: replace arch loongson with arch extra list loongson Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn --- configure | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configure b/configure index d3f23c8..8bb6d9f 100755 --- a/configure +++ b/configure @@ -1577,6 +1577,9 @@ ARCH_EXT_LIST_MIPS= mipsdspr1 mipsdspr2 msa + + +ARCH_EXT_LIST_LOONGSON= loongson3 @@ -1617,7 +1620,7 @@ ARCH_EXT_LIST= $ARCH_EXT_LIST_PPC $ARCH_EXT_LIST_X86 $ARCH_EXT_LIST_MIPS -loongson +$ARCH_EXT_LIST_LOONGSON ARCH_FEATURES= -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pngdec: set correct range
On Fri, 8 May 2015 10:30:34 + (UTC) Carl Eugen Hoyos ceho...@ag.or.at wrote: wm4 nfxjfg at googlemail.com writes: I believe this is slightly misleading: gray8 and gray16 are interpreted as full-range by default since years. Really? Where? In the software scaler. Doesn't matter much from the API user point of view. Not everyone uses libswscale. As said, I had no objections against your patch (on the contrary) but I wonder why you want to set a field that is mostly useful when using libswscale if you don't use libswscale. Uh, what? Do you think libswscale is the only thing that processes video? There is the (unwritten?) convention that YUV is limited range, and RGB is full range. GRAY is somewhat both, but at least the pixdesc tables do not mark it as RGB. I don't think the issue is related to (current) pixdesc but I may miss something. What is your opinion about this? I committed part of the change making gray full range... Whoever wants to use frame-data[0] should use it;-) What do you even mean? So what is the API user supposed to do? Special-case by codec? Just what is it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pngdec: set correct range
wm4 nfxjfg at googlemail.com writes: I believe this is slightly misleading: gray8 and gray16 are interpreted as full-range by default since years. Really? Where? In the software scaler. Doesn't matter much from the API user point of view. Not everyone uses libswscale. As said, I had no objections against your patch (on the contrary) but I wonder why you want to set a field that is mostly useful when using libswscale if you don't use libswscale. There is the (unwritten?) convention that YUV is limited range, and RGB is full range. GRAY is somewhat both, but at least the pixdesc tables do not mark it as RGB. I don't think the issue is related to (current) pixdesc but I may miss something. What is your opinion about this? I committed part of the change making gray full range... Whoever wants to use frame-data[0] should use it;-) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] configure: remove loongson check inline asm and mips dependent
From 6f76746ecd5b623e7610e293be2cbe02022dd22a Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong zhouxiaoy...@loongson.cn
Date: Thu, 7 May 2015 11:50:42 +0800
Subject: [PATCH 2/3] configure: remove loongson check inline asm and mips
dependent
1.Loongson now have two series CPU supported MMI(Multi-Media Instruct).
Loongson-3 designed multi-core have good performance in decoding.
Loongson-2's support is comming soon.
2.Replaced loongson with loongson2 and loongson3.
Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn
---
configure | 3 ---
1 file changed, 3 deletions(-)
diff --git a/configure b/configure
index 8bb6d9f..0f79874 100755
--- a/configure
+++ b/configure
@@ -2021,7 +2021,6 @@ setend_deps=arm
map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
-loongson_deps=mips
mipsfpu_deps=mips
mipsdspr1_deps=mips
mipsdspr2_deps=mips
@@ -4689,8 +4688,6 @@ EOF
elif enabled mips; then
-check_inline_asm loongson 'dmult.g $1, $2, $3'
-
# Enable minimum ISA based on selected options
if enabled mips64 (enabled mipsdspr1 || enabled mipsdspr2); then
add_cflags -mips64r2
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] configure: loongson enable subarch mips64
From 1094ca8983b34492dece7da5cd09125dbda04726 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Fri, 8 May 2015 09:08:00 +0800 Subject: [PATCH 3/3] configure: loongson enable subarch mips64 1.Fedora19(Loongson) has released 32bit version and 64bit will comming soon. 2.On 32bit OS check_64bit returns subarch as mips, but mips64 expected. 3.Loongson-3 compatible with mips64r2 instruction set, and added on with MMI. 4.-march=loongson3a conflict with -mips64 and -mips64r2. 5.Loongson-3A1000 and Loongson-3B1500 not support mipsdspr1 or mipsdapr2. 6.The new CPU 3A2000 support mipsdspr2. Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn --- configure | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/configure b/configure index 0f79874..4e6fddd 100755 --- a/configure +++ b/configure @@ -2028,7 +2028,7 @@ mips32r2_deps=mips mips32r5_deps=mips mips64r6_deps=mips msa_deps=mips -loongson3_deps=mips +loongson3_deps=mips64 altivec_deps=ppc dcbzl_deps=ppc @@ -3923,6 +3923,7 @@ elif enabled mips; then check_ldflags -mabi=64 ;; loongson3*) +subarch=mips64 enable mipsfpu disable mips32r2 disable mips32r5 @@ -3937,7 +3938,6 @@ elif enabled mips; then enable fast_cmov enable fast_unaligned disable aligned_stack -cpuflags=-march=$cpu ;; generic) disable mips32r5 @@ -4087,7 +4087,9 @@ case $arch in spic=$shared ;; mips) -check_64bit mips mips64 '_MIPS_SIM 1' +if [[ ! $cpu =~ loongson ]]; then +check_64bit mips mips64 '_MIPS_SIM 1' +fi spic=$shared ;; parisc) @@ -4692,7 +4694,7 @@ elif enabled mips; then if enabled mips64 (enabled mipsdspr1 || enabled mipsdspr2); then add_cflags -mips64r2 add_asflags -mips64r2 -elif enabled mips64 enabled mipsfpu; then +elif enabled mips64 enabled mipsfpu !(enabled loongson3); then add_cflags -mips64 add_asflags -mips64 elif enabled mipsdspr1 || enabled mipsdspr2; then @@ -4717,8 +4719,6 @@ elif enabled mips; then check_inline_asm mipsfpu 'madd.d $f0, $f2, $f4, $f6' enabled msacheck_cflags -mmsa check_ldflags -mmsa check_inline_asm msa 'addvi.b $w0, $w1, 1' -enabled loongson3 add_cflags -mhard-float add_asflags -mhard-float -check_inline_asm loongson3 'gsldxc1 $f0, 0($2, $3)' enabled mips32r5 add_asflags -mips32r5 -mfp64 enabled mips64r6 add_asflags -mips64r6 -mfp64 -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Print a warning if gray decoding was requested but not enabled
On Fri, May 08, 2015 at 03:01:06PM +0200, Carl Eugen Hoyos wrote: Hi! Attached patch prints a warning if gray decoding was requested but not enabled at configuration time. Carl Eugen utils.c |5 + 1 file changed, 5 insertions(+) 061e15dd12c198c8634844cf0c14b3e48d34d58b patchgray.diff LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- 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 3/3] configure: loongson enable subarch mips64
On Fri, May 08, 2015 at 06:17:59PM +0800, 周晓勇 wrote: From 1094ca8983b34492dece7da5cd09125dbda04726 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Fri, 8 May 2015 09:08:00 +0800 Subject: [PATCH 3/3] configure: loongson enable subarch mips64 1.Fedora19(Loongson) has released 32bit version and 64bit will comming soon. if its actually 32bit currently than maybe mips is more correct than mips64, i dont know [...] -- 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] [PATCH] avcodec[/format]/webpenc: use WebPAnimEncoder API to generate animated WebP
On Thu, May 07, 2015 at 09:28:43PM +, Urvang Joshi wrote: On Thu, Apr 30, 2015 at 12:05 PM Michael Niedermayer michae...@gmx.at wrote: On Wed, Apr 29, 2015 at 11:53:40PM +, Urvang Joshi wrote: On Mon, Apr 27, 2015 at 5:03 PM Michael Niedermayer michae...@gmx.at wrote: On Mon, Apr 27, 2015 at 10:18:52PM +, Urvang Joshi wrote: On Thu, Apr 23, 2015 at 2:51 PM Michael Niedermayer michae...@gmx.at wrote: On Thu, Apr 16, 2015 at 10:40:14PM +, Urvang Joshi wrote: On Thu, Apr 16, 2015 at 3:09 PM James Almer jamr...@gmail.com wrote: On 16/04/15 4:18 PM, Urvang Joshi wrote: Hi, Here's the patch without whitespace changes. Thanks, Urvang This patch doesn't apply cleanly. Looks like something weird with the indentation still. Was this patch handmade? It says the hash for libwebpenc.c is 95d56ac (same as git head), but the contents of the patch don't match. Sorry, I should have mentioned that it was created with --ignore-all-space option, so using the same option when applying the patch would have worked. But to avoid any confusion, here's the re-created patch, that should apply cleanly with just 'git am'. After fixing the conflicts and compiling the patch seems to work, but the resulting animated webp files are smaller than those using the native muxer using the default encoding and muxing settings. Is this because the muxing done by libwebpmux is different, or are the quality defaults changed in any way when using this codepath? If the former then that's pretty good, but if the latter then it should probably be fixed. Short answer: muxing done by libwebpmux is different, so it's expected that it generates smaller WebP files. Detailed answer: The native muxer is naive, and it always uses X offset and Y offset of 0 for all frames. This means the full width x height of all frames are encoded. libwebpmux muxer is smart on the other hand: for example, it only encodes the part of the frame which has changed from previous frame. This and other optimizations result in smaller WebP files. can you show some PSNR vs filesize information ? As explained below, we aren't changing the underlying encoder -- only the muxer is being changed. Thanks, Urvang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel configure |5 ++ libavcodec/libwebpenc.c | 93 +++- libavformat/webpenc.c | 44 ++ why are there changes to libavformat in a patch changing an encoder? Note that WebPAnimEncoder API used now internally uses WebP encoder and WebP muxer. Earlier, ffmpeg was using WebP encoder with its native muxer. So, we are only changing the muxer here, the underlying encoder is still the WebPEncoder as earlier. Ok, so the patch adds many #ifs to both the muxer and encoder, and there are more changes in the encoder than the muxer the commit message which is 1 single line only speaks about the encoder and the patch is only about the muxer. Did i understand it correctly this time ? assuming iam not entirely wrong here. First question is what does the patch actually try to achive ? replace a native muxer by a new external dependancy ? if so, why would we want that ? In theory, here are some of the optimizations that AnimEncoder API (if available) does to be more efficient than native muxer: - Pick the best dispose/blend method combination for each frame. - Based on the dispose/blend method, encode only a sub-rectangle of the frame that has changed from the previous (disposed) frame. - If some pixels in current frame match the corresponding pixels in the previous frame, possibly turn them into transparent pixels (so that they see through the previous frame's pixel), if that improves compression. - Optionally, it can also insert keyframes at regular intervals (not used in this patch; but I plan to add a command-line option to allow this in future). lets try to agree on terminology first: Code which compresses that rectangular area of pixels called a picture or frame into a compressed bitstream is called an encoder deciding how to encode a frame, frame area or pixel is
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
On Fri, 8 May 2015 12:37:48 + (UTC) Carl Eugen Hoyos ceho...@ag.or.at wrote: wm4 nfxjfg at googlemail.com writes: + Absolute path %s not tried for security reasons, + pass -use_absolute_path 1 to force using absolute paths\n, ffmpeg.c options/conventions have no place in the libraries. How is this libavformat option related to ffmpeg.c? Please suggest a wording that is also acceptable for library users (they can't guess use_absolute_path either I guess). The problem is that this code was written with ffmpeg.c in mind, so you assumed that it was fine to open new files inside of libavformat, and you had to add an option to let ffmpeg.c fix the hardcoded policy if needed. The correct way is adding a callback for opening new files, and let the API user decide. ffmpeg.c can then implement its own use_absolute_path option. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: de-duplicate some functions that are identical between 10/12 bpp.
On Thu, May 07, 2015 at 08:37:37AM -0400, Ronald S. Bultje wrote: --- libavcodec/vp9dsp_template.c | 112 +-- 1 file changed, 98 insertions(+), 14 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
wm4 nfxjfg at googlemail.com writes: The correct way is adding a callback for opening new files, and let the API user decide. ffmpeg.c can then implement its own use_absolute_path option. How is this related to the existing implementation? Don't you have to set use_absolute_path to open a reference file with absolute paths? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Print a warning if gray decoding was requested but not enabled
On 08.05.2015 15:01, Carl Eugen Hoyos wrote: +av_log(avctx, AV_LOG_WARNING, + gray decoding requested but not ensabled at configuration time\n); ^ Typo: ensabled - enabled Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/v4l2: fix typo
From 55f35aaea4b1aaf59e3a7620e0ca0e078c8c2010 Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Fri, 8 May 2015 17:42:34 +0200
Subject: [PATCH] lavd/v4l2: fix typo
This was introduced in cde6e328de214ffe8387641cdc1e433a2c2150f3
---
libavdevice/v4l2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 6137cef..76f7c4e 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -286,7 +286,7 @@ static void list_formats(AVFormatContext *ctx, int type)
} else if (vfd.flags V4L2_FMT_FLAG_COMPRESSED
type V4L_COMPFORMATS) {
const AVCodecDescriptor *desc = avcodec_descriptor_get(codec_id);
-av_log(ctx, AV_LOG_INFO, Compressedll : %9s : %20s :,
+av_log(ctx, AV_LOG_INFO, Compressed: %9s : %20s :,
desc ? desc-name : Unsupported,
vfd.description);
} else {
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR
Hi,
this patch fixes ticket #4030. Users have tested it and they confirm
it solves the problem.
Giorgio Vazzana
From 5f1b247ee7c47821da301eddad539f8e35652cf5 Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Fri, 8 May 2015 17:25:15 +0200
Subject: [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is
flagged with V4L2_BUF_FLAG_ERROR
Fixes ticket #4030.
---
libavdevice/v4l2.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index b0fa765..6137cef 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -499,13 +499,14 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
};
int res;
+pkt-size = 0;
+
/* FIXME: Some special treatment might be needed in case of loss of signal... */
while ((res = v4l2_ioctl(s-fd, VIDIOC_DQBUF, buf)) 0 (errno == EINTR));
if (res 0) {
-if (errno == EAGAIN) {
-pkt-size = 0;
+if (errno == EAGAIN)
return AVERROR(EAGAIN);
-}
+
res = AVERROR(errno);
av_log(ctx, AV_LOG_ERROR, ioctl(VIDIOC_DQBUF): %s\n,
av_err2str(res));
@@ -520,18 +521,24 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
// always keep at least one buffer queued
av_assert0(avpriv_atomic_int_get(s-buffers_queued) = 1);
-/* CPIA is a compressed format and we don't know the exact number of bytes
- * used by a frame, so set it here as the driver announces it.
- */
-if (ctx-video_codec_id == AV_CODEC_ID_CPIA)
-s-frame_size = buf.bytesused;
+if (buf.flags V4L2_BUF_FLAG_ERROR) {
+av_log(ctx, AV_LOG_WARNING,
+ Dequeued v4l2 buffer contains corrupted data (%d bytes).\n,
+ buf.bytesused);
+buf.bytesused = 0;
+} else {
+/* CPIA is a compressed format and we don't know the exact number of bytes
+ * used by a frame, so set it here as the driver announces it. */
+if (ctx-video_codec_id == AV_CODEC_ID_CPIA)
+s-frame_size = buf.bytesused;
-if (s-frame_size 0 buf.bytesused != s-frame_size) {
-av_log(ctx, AV_LOG_ERROR,
- The v4l2 frame is %d bytes, but %d bytes are expected. Flags: 0x%08X\n,
- buf.bytesused, s-frame_size, buf.flags);
-enqueue_buffer(s, buf);
-return AVERROR_INVALIDDATA;
+if (s-frame_size 0 buf.bytesused != s-frame_size) {
+av_log(ctx, AV_LOG_ERROR,
+ Dequeued v4l2 buffer contains %d bytes, but %d were expected. Flags: 0x%08X.\n,
+ buf.bytesused, s-frame_size, buf.flags);
+enqueue_buffer(s, buf);
+return AVERROR_INVALIDDATA;
+}
}
/* Image is at s-buff_start[buf.index] */
@@ -586,7 +593,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
pkt-pts = buf.timestamp.tv_sec * INT64_C(100) + buf.timestamp.tv_usec;
convert_timestamp(ctx, pkt-pts);
-return s-buf_len[buf.index];
+return pkt-size;
}
static int mmap_start(AVFormatContext *ctx)
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Fix pix_fmt for vc1 decoding with flags +gray
Hi!
Attached patch fixes the initial pix_fmt when decoding
vc1 with flags +gray, regression since this commit:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=16af29a7
Not tested with hardware acceleration, does not fix
ticket #4542.
Please review, Carl Eugen
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 86e214a..1d45cb1 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -427,10 +427,6 @@ static av_cold int vc1_decode_init(AVCodecContext *avctx)
if (!avctx-extradata_size || !avctx-extradata)
return -1;
-if (!(avctx-flags CODEC_FLAG_GRAY))
-avctx-pix_fmt = ff_get_format(avctx, avctx-codec-pix_fmts);
-else
-avctx-pix_fmt = AV_PIX_FMT_GRAY8;
v-s.avctx = avctx;
if ((ret = ff_vc1_init_common(v)) 0)
@@ -445,6 +441,12 @@ static av_cold int vc1_decode_init(AVCodecContext *avctx)
// That this is necessary might indicate a bug.
ff_vc1_decode_end(avctx);
+if (!(avctx-flags CODEC_FLAG_GRAY)) {
+avctx-pix_fmt = ff_get_format(avctx, avctx-codec-pix_fmts);
+} else {
+avctx-pix_fmt = AV_PIX_FMT_GRAY8;
+}
+
ff_blockdsp_init(s-bdsp, avctx);
ff_h264chroma_init(v-h264chroma, 8);
ff_qpeldsp_init(s-qdsp);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: fix typo
On Fri, May 08, 2015 at 05:50:03PM +0200, Giorgio Vazzana wrote: v4l2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 724fa0d7a6468a09c6061bef58629599c84d233b 0002-lavd-v4l2-fix-typo.patch From 55f35aaea4b1aaf59e3a7620e0ca0e078c8c2010 Mon Sep 17 00:00:00 2001 From: Giorgio Vazzana mywin...@gmail.com Date: Fri, 8 May 2015 17:42:34 +0200 Subject: [PATCH] lavd/v4l2: fix typo This was introduced in cde6e328de214ffe8387641cdc1e433a2c2150f3 applied thanks [...] -- 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] [PATCH 2/3] configure: remove loongson check inline asm and mips dependent
On Fri, May 8, 2015 at 3:06 AM 周晓勇 zhouxiaoy...@loongson.cn wrote: From 6f76746ecd5b623e7610e293be2cbe02022dd22a Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Thu, 7 May 2015 11:50:42 +0800 Subject: [PATCH 2/3] configure: remove loongson check inline asm and mips dependent 1.Loongson now have two series CPU supported MMI(Multi-Media Instruct). Loongson-3 designed multi-core have good performance in decoding. Loongson-2's support is comming soon. 2.Replaced loongson with loongson2 and loongson3. Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn How does the commit message justify this commit? Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Print an error for invalid wav files and write no incorrect file length
Hi!
Attached patch fixes ticket #4543 for me.
Please comment, Carl Eugen
diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index 0333622..ba66e84 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -425,7 +425,7 @@ static int wav_write_trailer(AVFormatContext *s)
avio_flush(pb);
if (s-pb-seekable) {
-if (wav-write_peak != 2) {
+if (wav-write_peak != 2 avio_tell(pb) - wav-data UINT32_MAX) {
ff_end_tag(pb, wav-data);
avio_flush(pb);
}
@@ -440,12 +440,16 @@ static int wav_write_trailer(AVFormatContext *s)
data_size = file_size - wav-data;
if (wav-rf64 == RF64_ALWAYS || (wav-rf64 == RF64_AUTO file_size -
8 UINT32_MAX)) {
rf64 = 1;
-} else {
+} else if (file_size - 8 = UINT32_MAX) {
avio_seek(pb, 4, SEEK_SET);
avio_wl32(pb, (uint32_t)(file_size - 8));
avio_seek(pb, file_size, SEEK_SET);
avio_flush(pb);
+} else {
+av_log(s, AV_LOG_ERROR,
+ Filesize %PRId64 invalid for wav, output file will be
broken\n,
+ file_size);
}
number_of_samples = av_rescale(wav-maxpts - wav-minpts +
wav-last_duration,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On Fri, May 08, 2015 at 10:50:49AM -0700, Nick Lewycky wrote: On 6 May 2015 at 18:03, Michael Niedermayer michae...@gmx.at wrote: On Wed, May 06, 2015 at 04:08:09PM -0700, Nick Lewycky wrote: On 6 May 2015 at 15:06, Michael Niedermayer michae...@gmx.at wrote: Hi On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: Newer versions of clang will allocate %rbx as one of the inline asm inputs, Thats great even in PIC. This occurs when building ffmpeg with clang -fsanitize=address -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, just include %bx in the clobber list regardless of whether PIC is on or off. you cant include *bx in the clobber list with PIC it breaks compilers that are less great, like gcc Doh!! I did check for this, but only tried x86-64, not x86-32. Sorry! gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hyscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hcscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ also what exactly are you trying to fix ? or rather what exactly goes how exactly wrong with the code as it is if rbx is used ? Ok, let's look at ff_hcscale_fast_mmext. Preprocessor directives evaluated in PIC x86-64, the inline constraints work out to: :: m (src1), m (dst1), m (filter), m (filterPos), m (mmxextFilterCode), m (src2), m(dst2) ,m (ebxsave) ,m(retsave) : %REG_a, %REG_c, %REG_d, %REG_S, %REG_D so clang looks at that and decides that it can pick src1 = (%r10), dst1 = (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode = (%r15), src2 = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). The problem there is src2 being (%rbx). Now let's look at how we use them: mov %0, %%REG_c \n\t mov %1, %%REG_D \n\t mov %2, %%REG_d \n\t mov %3, %%REG_b \n\t // Clobbers %rbx / src2 / %5 here xor %%REG_a, %%REG_a \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE xor %%REG_a, %%REG_a \n\t mov %5, %%REG_c \n\t // %5 is read too late, we get %3 / filterPos instead mov %6, %%REG_D \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE // Crash... The two marked instructions are intended to refer to different contents. CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: movl(%%REG_b), %%esi \n\t\ call*%4\n\t\ // Crash... That callee ultimately segfaults: = 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 Program received signal SIGSEGV, Segmentation fault. 0x7fffefa45004 in ?? () = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 I'm trying to fix this segfault. also ideally changes to this code should be tested against gcc/clang/icc of various versions with and without PIC, 32 and 64 bit this code is more tricky than than the average so theres a good change changes to it will break some compiler I understand that, but I may not be able to test as many environments as you like. I'm going to give testing it my best effort, but I can tell you up front that I'm only going to test gcc and clang, on an x86 Ubuntu machine. I don't have ICC, so I can't test that. iam not sure it would work but, configure could easily test if ebx can be put on the clobber list and that then could be used in place of PIC in the checks I checked gcc 4.4, 4.6, 4.7, 4.8, and clang 3.3, 3.4, 3.5 in 32 and 64-bit builds, and PIC vs. not, cross product thereof. The only one that emits this error is all versions of gcc in 32-bit mode with PIC enabled. On 64-bit, gcc and clang do the same thing, they'll spill BX if they want to preserve it. Based on that, I decided we could sink the manual saving and restoring of ebx down to 32-bit+PIC mode, and just list it as a clobber in 64-bit mode regardless of the PIC setting. That works in every compiler and mode I
[FFmpeg-devel] [PATCH]lavf/wavdec: Allow decoding of invalid large wav files
Hi!
Valid wav files are not larger than 4G, files that are
larger are truncated by current FFmpeg.
Attached patch allows reading such files if the size
was (imo correctly) written to -1.
Please comment, Carl Eugen
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 410c2ec..332f643 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -335,9 +335,12 @@ static int wav_read_header(AVFormatContext *s)
if (rf64) {
next_tag_ofs = wav-data_end = avio_tell(pb) + data_size;
-} else {
+} else if (size != 0x) {
data_size= size;
next_tag_ofs = wav-data_end = size ? next_tag_ofs : INT64_MAX;
+} else {
+data_size= 0;
+next_tag_ofs = wav-data_end = INT64_MAX;
}
data_ofs = avio_tell(pb);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] ffserver jpg patch
When can the patch be applied?
On Mon, May 04, 2015 at 06:35:36PM -0600, ill wrote:
I changed it to git and add the .write header to the last part. The first part
compiled after I changed ffserver.c, so it is no longer corrupted. Muxer
detection seems to work when I tried it for the middle part. It should be good
to fix ffserver now?
patch is still corrupted by linebreaks
probably your MUA is breaking long lines, try to attach the patch or
use git send-email
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
diff -Nrup ffmpeg-git--orig/ffserver.c ffmpeg-git/ffserver.c
--- ffmpeg-git--orig/ffserver.c2015-03-16 20:25:48.0 +0100
+++ ffmpeg-git/ffserver.c2015-04-05 02:33:53.0 +0200
@@ -967,6 +967,10 @@ static int handle_connection(HTTPContext
/* close connection if trailer sent */
if (c-state == HTTPSTATE_SEND_DATA_TRAILER)
return -1;
+/* Check if it is a single jpeg frame 123 */
+if (c-stream-single_frame c-data_count c-cur_frame_bytes c-cur_frame_bytes 0) {
+close_connection(c);
+}
break;
case HTTPSTATE_RECEIVE_DATA:
/* no need to read if no events */
diff -Nrup ffmpeg-git--orig/ffserver_config.c
ffmpeg-git/ffserver_config.c
--- ffmpeg-git--orig/ffserver_config.c2015-03-16
20:25:48.0 +0100
+++ ffmpeg-git/ffserver_config.c2015-04-05 02:33:53.0 +0200
@@ -862,8 +862,10 @@ static int ffserver_parse_config_stream(
} else {
stream-stream_type = STREAM_TYPE_LIVE;
/* JPEG cannot be used here, so use single frame MJPEG */
-if (!strcmp(arg, jpeg))
-strcpy(arg, mjpeg);
+if (!strcmp(arg, jpeg)) {
+strcpy(arg, singlejpeg);
+stream-single_frame=1;
+}
stream-fmt = ffserver_guess_format(arg, NULL, NULL);
if (!stream-fmt)
ERROR(Unknown Format: '%s'\n, arg);
diff -Nrup ffmpeg-git--orig/ffserver_config.h
ffmpeg-git/ffserver_config.h
--- ffmpeg-git--orig/ffserver_config.h2015-03-16
20:25:48.0 +0100
+++ ffmpeg-git/ffserver_config.h2015-04-05 02:33:53.0 +0200
@@ -79,6 +79,7 @@ typedef struct FFServerStream {
int multicast_port; /* first port used for multicast */
int multicast_ttl;
int loop; /* if true, send the stream in loops (only meaningful if file) */
+char single_frame;/* only single frame */
/* feed specific */
int feed_opened; /* true if someone is writing to the
feed */
diff -Nrup ffmpeg-git--orig/libavformat/allformats.c
ffmpeg-git/libavformat/allformats.c
--- ffmpeg-git--orig/libavformat/allformats.c2015-03-16
20:25:52.0 +0100
+++ ffmpeg-git/libavformat/allformats.c2015-04-05
02:33:53.0 +0200
@@ -273,6 +273,7 @@ void av_register_all(void)
REGISTER_MUXER (SEGMENT, stream_segment);
REGISTER_DEMUXER (SHORTEN, shorten);
REGISTER_DEMUXER (SIFF, siff);
+REGISTER_MUXER (SINGLEJPEG, singlejpeg);
REGISTER_DEMUXER (SLN, sln);
REGISTER_DEMUXER (SMACKER, smacker);
REGISTER_MUXDEMUX(SMJPEG, smjpeg);
diff -Nrup ffmpeg-git--orig/libavformat/rawenc.c
ffmpeg-git/libavformat/rawenc.c
--- ffmpeg-git--orig/libavformat/rawenc.c2015-03-16
20:25:54.0 +0100
+++ ffmpeg-git/libavformat/rawenc.c2015-04-05$
02:33:53.0 +0200
@@ -250,6 +250,18 @@ AVOutputFormat ff_mjpeg_muxer = {
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
+
+AVOutputFormat ff_singlejpeg_muxer = {
+.name = singlejpeg,
+.long_name = NULL_IF_CONFIG_SMALL(JPEG single image),
+.mime_type = image/jpeg,
+.extensions= jpg,jpeg,
+.audio_codec = AV_CODEC_ID_NONE,
+.video_codec = AV_CODEC_ID_MJPEG,
+.write_packet = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+.write_header = force_one_stream,
+};
#endif
#if CONFIG_MLP_MUXER
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On 6 May 2015 at 18:03, Michael Niedermayer michae...@gmx.at wrote: On Wed, May 06, 2015 at 04:08:09PM -0700, Nick Lewycky wrote: On 6 May 2015 at 15:06, Michael Niedermayer michae...@gmx.at wrote: Hi On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: Newer versions of clang will allocate %rbx as one of the inline asm inputs, Thats great even in PIC. This occurs when building ffmpeg with clang -fsanitize=address -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, just include %bx in the clobber list regardless of whether PIC is on or off. you cant include *bx in the clobber list with PIC it breaks compilers that are less great, like gcc Doh!! I did check for this, but only tried x86-64, not x86-32. Sorry! gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hyscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hcscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ also what exactly are you trying to fix ? or rather what exactly goes how exactly wrong with the code as it is if rbx is used ? Ok, let's look at ff_hcscale_fast_mmext. Preprocessor directives evaluated in PIC x86-64, the inline constraints work out to: :: m (src1), m (dst1), m (filter), m (filterPos), m (mmxextFilterCode), m (src2), m(dst2) ,m (ebxsave) ,m(retsave) : %REG_a, %REG_c, %REG_d, %REG_S, %REG_D so clang looks at that and decides that it can pick src1 = (%r10), dst1 = (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode = (%r15), src2 = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). The problem there is src2 being (%rbx). Now let's look at how we use them: mov %0, %%REG_c \n\t mov %1, %%REG_D \n\t mov %2, %%REG_d \n\t mov %3, %%REG_b \n\t // Clobbers %rbx / src2 / %5 here xor %%REG_a, %%REG_a \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE xor %%REG_a, %%REG_a \n\t mov %5, %%REG_c \n\t // %5 is read too late, we get %3 / filterPos instead mov %6, %%REG_D \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE // Crash... The two marked instructions are intended to refer to different contents. CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: movl(%%REG_b), %%esi \n\t\ call*%4\n\t\ // Crash... That callee ultimately segfaults: = 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 Program received signal SIGSEGV, Segmentation fault. 0x7fffefa45004 in ?? () = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 I'm trying to fix this segfault. also ideally changes to this code should be tested against gcc/clang/icc of various versions with and without PIC, 32 and 64 bit this code is more tricky than than the average so theres a good change changes to it will break some compiler I understand that, but I may not be able to test as many environments as you like. I'm going to give testing it my best effort, but I can tell you up front that I'm only going to test gcc and clang, on an x86 Ubuntu machine. I don't have ICC, so I can't test that. iam not sure it would work but, configure could easily test if ebx can be put on the clobber list and that then could be used in place of PIC in the checks I checked gcc 4.4, 4.6, 4.7, 4.8, and clang 3.3, 3.4, 3.5 in 32 and 64-bit builds, and PIC vs. not, cross product thereof. The only one that emits this error is all versions of gcc in 32-bit mode with PIC enabled. On 64-bit, gcc and clang do the same thing, they'll spill BX if they want to preserve it. Based on that, I decided we could sink the manual saving and restoring of ebx down to 32-bit+PIC mode, and just list it as a clobber in 64-bit mode regardless of the PIC setting. That works in every compiler and mode I tried. Tested with make + make check + make fate but not make fake SAMPLES= Updated patch attached! Let me know what you think. and thanks for the detailed informaion No problem,
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On 8 May 2015 at 12:06, Michael Niedermayer michae...@gmx.at wrote: On Fri, May 08, 2015 at 10:50:49AM -0700, Nick Lewycky wrote: On 6 May 2015 at 18:03, Michael Niedermayer michae...@gmx.at wrote: On Wed, May 06, 2015 at 04:08:09PM -0700, Nick Lewycky wrote: On 6 May 2015 at 15:06, Michael Niedermayer michae...@gmx.at wrote: Hi On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: Newer versions of clang will allocate %rbx as one of the inline asm inputs, Thats great even in PIC. This occurs when building ffmpeg with clang -fsanitize=address -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, just include %bx in the clobber list regardless of whether PIC is on or off. you cant include *bx in the clobber list with PIC it breaks compilers that are less great, like gcc Doh!! I did check for this, but only tried x86-64, not x86-32. Sorry! gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hyscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hcscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ also what exactly are you trying to fix ? or rather what exactly goes how exactly wrong with the code as it is if rbx is used ? Ok, let's look at ff_hcscale_fast_mmext. Preprocessor directives evaluated in PIC x86-64, the inline constraints work out to: :: m (src1), m (dst1), m (filter), m (filterPos), m (mmxextFilterCode), m (src2), m(dst2) ,m (ebxsave) ,m(retsave) : %REG_a, %REG_c, %REG_d, %REG_S, %REG_D so clang looks at that and decides that it can pick src1 = (%r10), dst1 = (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode = (%r15), src2 = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). The problem there is src2 being (%rbx). Now let's look at how we use them: mov %0, %%REG_c \n\t mov %1, %%REG_D \n\t mov %2, %%REG_d \n\t mov %3, %%REG_b \n\t // Clobbers %rbx / src2 / %5 here xor %%REG_a, %%REG_a \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE xor %%REG_a, %%REG_a \n\t mov %5, %%REG_c \n\t // %5 is read too late, we get %3 / filterPos instead mov %6, %%REG_D \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE // Crash... The two marked instructions are intended to refer to different contents. CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: movl(%%REG_b), %%esi \n\t\ call*%4\n\t\ // Crash... That callee ultimately segfaults: = 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 Program received signal SIGSEGV, Segmentation fault. 0x7fffefa45004 in ?? () = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 I'm trying to fix this segfault. also ideally changes to this code should be tested against gcc/clang/icc of various versions with and without PIC, 32 and 64 bit this code is more tricky than than the average so theres a good change changes to it will break some compiler I understand that, but I may not be able to test as many environments as you like. I'm going to give testing it my best effort, but I can tell you up front that I'm only going to test gcc and clang, on an x86 Ubuntu machine. I don't have ICC, so I can't test that. iam not sure it would work but, configure could easily test if ebx can be put on the clobber list and that then could be used in place of PIC in the checks I checked gcc 4.4, 4.6, 4.7, 4.8, and clang 3.3, 3.4, 3.5 in 32 and 64-bit builds, and PIC vs. not, cross product thereof. The only one that emits this error is all versions of gcc in 32-bit mode with PIC enabled. On 64-bit, gcc and clang do the same thing, they'll spill BX if they want to preserve it. Based on
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR
On Fri, May 08, 2015 at 06:50:19PM +0200, Giorgio Vazzana wrote: Hi, this patch fixes ticket #4030. Users have tested it and they confirm it solves the problem. Giorgio Vazzana v4l2.c | 37 ++--- 1 file changed, 22 insertions(+), 15 deletions(-) 9274ae2efb00d6ede99eee7ccf31564b45ac92f0 0003-lavd-v4l2-produce-a-0-byte-packet-when-a-dequeued-bu.patch From 5f1b247ee7c47821da301eddad539f8e35652cf5 Mon Sep 17 00:00:00 2001 From: Giorgio Vazzana mywin...@gmail.com Date: Fri, 8 May 2015 17:25:15 +0200 Subject: [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR Fixes ticket #4030. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On Fri, May 08, 2015 at 12:43:20PM -0700, Nick Lewycky wrote: On 8 May 2015 at 12:06, Michael Niedermayer michae...@gmx.at wrote: On Fri, May 08, 2015 at 10:50:49AM -0700, Nick Lewycky wrote: On 6 May 2015 at 18:03, Michael Niedermayer michae...@gmx.at wrote: On Wed, May 06, 2015 at 04:08:09PM -0700, Nick Lewycky wrote: On 6 May 2015 at 15:06, Michael Niedermayer michae...@gmx.at wrote: Hi On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: Newer versions of clang will allocate %rbx as one of the inline asm inputs, Thats great even in PIC. This occurs when building ffmpeg with clang -fsanitize=address -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, just include %bx in the clobber list regardless of whether PIC is on or off. you cant include *bx in the clobber list with PIC it breaks compilers that are less great, like gcc Doh!! I did check for this, but only tried x86-64, not x86-32. Sorry! gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hyscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hcscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ also what exactly are you trying to fix ? or rather what exactly goes how exactly wrong with the code as it is if rbx is used ? Ok, let's look at ff_hcscale_fast_mmext. Preprocessor directives evaluated in PIC x86-64, the inline constraints work out to: :: m (src1), m (dst1), m (filter), m (filterPos), m (mmxextFilterCode), m (src2), m(dst2) ,m (ebxsave) ,m(retsave) : %REG_a, %REG_c, %REG_d, %REG_S, %REG_D so clang looks at that and decides that it can pick src1 = (%r10), dst1 = (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode = (%r15), src2 = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). The problem there is src2 being (%rbx). Now let's look at how we use them: mov %0, %%REG_c \n\t mov %1, %%REG_D \n\t mov %2, %%REG_d \n\t mov %3, %%REG_b \n\t // Clobbers %rbx / src2 / %5 here xor %%REG_a, %%REG_a \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE xor %%REG_a, %%REG_a \n\t mov %5, %%REG_c \n\t // %5 is read too late, we get %3 / filterPos instead mov %6, %%REG_D \n\t PREFETCH (%%REG_c) \n\t PREFETCH 32(%%REG_c) \n\t PREFETCH 64(%%REG_c) \n\t CALL_MMXEXT_FILTER_CODE // Crash... The two marked instructions are intended to refer to different contents. CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: movl(%%REG_b), %%esi \n\t\ call*%4\n\t\ // Crash... That callee ultimately segfaults: = 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 Program received signal SIGSEGV, Segmentation fault. 0x7fffefa45004 in ?? () = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 I'm trying to fix this segfault. also ideally changes to this code should be tested against gcc/clang/icc of various versions with and without PIC, 32 and 64 bit this code is more tricky than than the average so theres a good change changes to it will break some compiler I understand that, but I may not be able to test as many environments as you like. I'm going to give testing it my best effort, but I can tell you up front that I'm only going to test gcc and clang, on an x86 Ubuntu machine. I don't have ICC, so I can't test that. iam not sure it would work but, configure could easily test if ebx can be put on the clobber list and that then could be used in place of PIC in the checks I checked gcc 4.4, 4.6, 4.7, 4.8, and clang 3.3, 3.4, 3.5 in 32 and 64-bit builds, and PIC vs. not, cross product thereof.
[FFmpeg-devel] [PATCH]Print a warning if gray decoding was requested but not enabled
Hi!
Attached patch prints a warning if gray decoding was requested
but not enabled at configuration time.
Carl Eugen
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 48286cf..0073308 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1615,6 +1615,11 @@ int attribute_align_arg avcodec_open2(AVCodecContext
*avctx, const AVCodec *code
avctx-pts_correction_last_pts =
avctx-pts_correction_last_dts = INT64_MIN;
+if ( !CONFIG_GRAY avctx-flags CODEC_FLAG_GRAY
+ avctx-codec_descriptor-type == AVMEDIA_TYPE_VIDEO)
+av_log(avctx, AV_LOG_WARNING,
+ gray decoding requested but not ensabled at configuration
time\n);
+
if ( avctx-codec-init (!(avctx-active_thread_typeFF_THREAD_FRAME)
|| avctx-internal-frame_thread_encoder)) {
ret = avctx-codec-init(avctx);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR
On Fri, May 08, 2015 at 07:00:18PM -0300, James Almer wrote: On 08/05/15 6:10 PM, Michael Niedermayer wrote: On Fri, May 08, 2015 at 06:50:19PM +0200, Giorgio Vazzana wrote: Hi, this patch fixes ticket #4030. Users have tested it and they confirm it solves the problem. Giorgio Vazzana v4l2.c | 37 ++--- 1 file changed, 22 insertions(+), 15 deletions(-) 9274ae2efb00d6ede99eee7ccf31564b45ac92f0 0003-lavd-v4l2-produce-a-0-byte-packet-when-a-dequeued-bu.patch From 5f1b247ee7c47821da301eddad539f8e35652cf5 Mon Sep 17 00:00:00 2001 From: Giorgio Vazzana mywin...@gmail.com Date: Fri, 8 May 2015 17:25:15 +0200 Subject: [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR Fixes ticket #4030. applied thanks This does not compile on netbsd and openbsd. http://fate.ffmpeg.org/log.cgi?time=20150508171126log=compileslot=x86_64-netbsd-clang-noopt http://fate.ffmpeg.org/log.cgi?time=20150508182740log=compileslot=x86_64-openbsd5.6-gcc4.8 should be fixed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR
2015-05-09 0:34 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Fri, May 08, 2015 at 07:00:18PM -0300, James Almer wrote: On 08/05/15 6:10 PM, Michael Niedermayer wrote: applied thanks This does not compile on netbsd and openbsd. http://fate.ffmpeg.org/log.cgi?time=20150508171126log=compileslot=x86_64-netbsd-clang-noopt http://fate.ffmpeg.org/log.cgi?time=20150508182740log=compileslot=x86_64-openbsd5.6-gcc4.8 should be fixed Sorry and thank you James and Michael, I only test on Linux so I didn't realize it would break the build for netbsd/openbsd. Giorgio Vazzana ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR
On 08/05/15 6:10 PM, Michael Niedermayer wrote: On Fri, May 08, 2015 at 06:50:19PM +0200, Giorgio Vazzana wrote: Hi, this patch fixes ticket #4030. Users have tested it and they confirm it solves the problem. Giorgio Vazzana v4l2.c | 37 ++--- 1 file changed, 22 insertions(+), 15 deletions(-) 9274ae2efb00d6ede99eee7ccf31564b45ac92f0 0003-lavd-v4l2-produce-a-0-byte-packet-when-a-dequeued-bu.patch From 5f1b247ee7c47821da301eddad539f8e35652cf5 Mon Sep 17 00:00:00 2001 From: Giorgio Vazzana mywin...@gmail.com Date: Fri, 8 May 2015 17:25:15 +0200 Subject: [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR Fixes ticket #4030. applied thanks This does not compile on netbsd and openbsd. http://fate.ffmpeg.org/log.cgi?time=20150508171126log=compileslot=x86_64-netbsd-clang-noopt http://fate.ffmpeg.org/log.cgi?time=20150508182740log=compileslot=x86_64-openbsd5.6-gcc4.8 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix pix_fmt for vc1 decoding with flags +gray
On Fri, May 08, 2015 at 05:40:59PM +0200, Carl Eugen Hoyos wrote: Hi! Attached patch fixes the initial pix_fmt when decoding vc1 with flags +gray, regression since this commit: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=16af29a7 Not tested with hardware acceleration, does not fix ticket #4542. fixed the ticket, will push after some tests [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- 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] pngdec: set correct range
On Fri, 8 May 2015 11:29:18 + (UTC) Carl Eugen Hoyos ceho...@ag.or.at wrote: wm4 nfxjfg at googlemail.com writes: As said, I had no objections against your patch (on the contrary) but I wonder why you want to set a field that is mostly useful when using libswscale if you don't use libswscale. Uh, what? Do you think libswscale is the only thing that processes video? No, but it seemed to me that this is what your commit message implied. What is your opinion about this? I committed part of the change making gray full range... Whoever wants to use frame-data[0] should use it What do you even mean? I thought your question was Do you agree that gray should be full-range? Some people need the yuv - In what context? Yes, png outputs full range gray, but that doesn't mean other codecs outputting gray do this. gray conversion not to change the values, and I always wonder why they call libswscale in the beginning, instead of simply using the Y plane. What does this have to do with anything? This sounds like a libswscale or ffmpeg.c problem at best. So what is the API user supposed to do? Special-case by codec? Just what is it? How is this codec-related / when is gray not full-scale (and FFmpeg can know it)? I just want to know how to get non-broken data from lavc? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
On Fri, 8 May 2015 13:25:17 +0200
Carl Eugen Hoyos ceho...@ag.or.at wrote:
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 54930a4..eaeb0d0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2648,6 +2648,11 @@ static int mov_open_dref(AVIOContext **pb, const char
*src, MOVDref *ref,
this is a possible security issue\n);
if (!avio_open2(pb, ref-path, AVIO_FLAG_READ, int_cb, NULL))
return 0;
+} else {
+av_log(fc, AV_LOG_ERROR,
+ Absolute path %s not tried for security reasons,
+ pass -use_absolute_path 1 to force using absolute paths\n,
+ ref-path);
}
return AVERROR(ENOENT);
ffmpeg.c options/conventions have no place in the libraries.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] configure: replace arch loongson with arch extra list loongson
On Fri, May 08, 2015 at 06:16:14PM +0800, 周晓勇 wrote: From 2836a9b83ab781920b9d048ef9ce2acf9061a2a7 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Thu, 7 May 2015 11:12:17 +0800 Subject: [PATCH 1/3] configure: replace arch loongson with arch extra list loongson Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn --- configure | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- 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 2/3] configure: remove loongson check inline asm and mips dependent
On Fri, May 08, 2015 at 06:17:19PM +0800, 周晓勇 wrote: From 6f76746ecd5b623e7610e293be2cbe02022dd22a Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Thu, 7 May 2015 11:50:42 +0800 Subject: [PATCH 2/3] configure: remove loongson check inline asm and mips dependent 1.Loongson now have two series CPU supported MMI(Multi-Media Instruct). Loongson-3 designed multi-core have good performance in decoding. Loongson-2's support is comming soon. 2.Replaced loongson with loongson2 and loongson3. Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 Used only once- Some unspecified defect prevented a second use In good condition - Can be repaird by experienced expert As is - You wouldnt want it even if you were payed for it, if you knew ... signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
wm4 nfxjfg at googlemail.com writes: + Absolute path %s not tried for security reasons, + pass -use_absolute_path 1 to force using absolute paths\n, ffmpeg.c options/conventions have no place in the libraries. How is this libavformat option related to ffmpeg.c? Please suggest a wording that is also acceptable for library users (they can't guess use_absolute_path either I guess). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pngdec: set correct range
wm4 nfxjfg at googlemail.com writes: I thought your question was Do you agree that gray should be full-range? In what context? In all contexts that we can distinguish? Yes, png outputs full range gray, but that doesn't mean other codecs outputting gray do this. Which codec? Note that I am also interested in this, and so far I wasn't able to find an exception except that users have their own requirements that aren't codec-related. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
Hi!
Attached patch intends to make it more obvious what the user has
to do to decode reference mov files.
Please comment, Carl Eugen
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 54930a4..eaeb0d0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2648,6 +2648,11 @@ static int mov_open_dref(AVIOContext **pb, const char
*src, MOVDref *ref,
this is a possible security issue\n);
if (!avio_open2(pb, ref-path, AVIO_FLAG_READ, int_cb, NULL))
return 0;
+} else {
+av_log(fc, AV_LOG_ERROR,
+ Absolute path %s not tried for security reasons,
+ pass -use_absolute_path 1 to force using absolute paths\n,
+ ref-path);
}
return AVERROR(ENOENT);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pngdec: set correct range
wm4 nfxjfg at googlemail.com writes: As said, I had no objections against your patch (on the contrary) but I wonder why you want to set a field that is mostly useful when using libswscale if you don't use libswscale. Uh, what? Do you think libswscale is the only thing that processes video? No, but it seemed to me that this is what your commit message implied. What is your opinion about this? I committed part of the change making gray full range... Whoever wants to use frame-data[0] should use it What do you even mean? I thought your question was Do you agree that gray should be full-range? Some people need the yuv - gray conversion not to change the values, and I always wonder why they call libswscale in the beginning, instead of simply using the Y plane. So what is the API user supposed to do? Special-case by codec? Just what is it? How is this codec-related / when is gray not full-scale (and FFmpeg can know it)? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
