[FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
Input files in XYZ color space are incorrecly detected as RGB which results
in incorrect output colors.
This fixes pixel format detection order (in increasing bit depth to
match libopenjpeg_matches_pix_fmt) when color space provided by
libopenjepg is unknown.
---
libavcodec/libopenjpegdec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 1cd1b9b..489040e 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -77,7 +77,7 @@ static const enum AVPixelFormat libopenjpeg_yuv_pix_fmts[] =
{
YUV_PIXEL_FORMATS
};
static const enum AVPixelFormat libopenjpeg_all_pix_fmts[] = {
-RGB_PIXEL_FORMATS, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS, XYZ_PIXEL_FORMATS
+AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA, XYZ_PIXEL_FORMATS, AV_PIX_FMT_RGB48,
AV_PIX_FMT_RGBA64, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS
};
typedef struct LibOpenJPEGContext {
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] acvodec/lipopenjpeg: Fix pixel value shift for 12-bit pixel formats
This fixes pixel values not being properly shifted in
libopenjpeg_copyto16 and libopenjpeg_copy_to_packed16 methods.
Pixel formats like xyz12le need to be shifted by AVComponentDescriptor::shift
to get the correct values.
---
libavcodec/libopenjpegdec.c |6 [32m[m[31m--[m
1 file changed, 4 insertions(+), 2 deletions(-)
[1mdiff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c[m
[1mindex 02b1ceb..1cd1b9b 100644[m
[1m--- a/libavcodec/libopenjpegdec.c[m
[1m+++ b/libavcodec/libopenjpegdec.c[m
[36m@@ -184,10 +184,11 @@[m [mstatic inline void
libopenjpeg_copy_to_packed8(AVFrame *picture, opj_image_t *im[m
[m
static inline void libopenjpeg_copy_to_packed16(AVFrame *picture, opj_image_t
*image) {[m
uint16_t *img_ptr;[m
[32m+[m[32mconst AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(picture-format);[m
int index, x, y, c;[m
int adjust[4];[m
for (x = 0; x image-numcomps; x++)[m
[31m-adjust[x] =
FFMAX(FFMIN(av_pix_fmt_desc_get(picture-format)-comp[x].depth_minus1 + 1 -
image-comps[x].prec, 8), 0);[m
[32m+[m[32madjust[x] = FFMAX(FFMIN(desc-comp[x].depth_minus1 + 1 -
image-comps[x].prec, 8), 0) + desc-comp[x].shift;[m
[m
for (y = 0; y picture-height; y++) {[m
index = y * picture-width;[m
[36m@@ -220,10 +221,11 @@[m [mstatic inline void libopenjpeg_copyto8(AVFrame
*picture, opj_image_t *image) {[m
static inline void libopenjpeg_copyto16(AVFrame *picture, opj_image_t *image)
{[m
int *comp_data;[m
uint16_t *img_ptr;[m
[32m+[m[32mconst AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(picture-format);[m
int index, x, y;[m
int adjust[4];[m
for (x = 0; x image-numcomps; x++)[m
[31m-adjust[x] =
FFMAX(FFMIN(av_pix_fmt_desc_get(picture-format)-comp[x].depth_minus1 + 1 -
image-comps[x].prec, 8), 0);[m
[32m+[m[32madjust[x] = FFMAX(FFMIN(desc-comp[x].depth_minus1 + 1 -
image-comps[x].prec, 8), 0) + desc-comp[x].shift;[m
[m
for (index = 0; index image-numcomps; index++) {[m
comp_data = image-comps[index].data;[m
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
Input files in XYZ color space are incorrecly detected as RGB which results
in incorrect output colors.
This fixes pixel format detection order (in increasing bit depth to
match libopenjpeg_matches_pix_fmt) when color space provided by
libopenjepg is unknown.
---
libavcodec/libopenjpegdec.c |2 [32m+[m[31m-[m
1 file changed, 1 insertion(+), 1 deletion(-)
[1mdiff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c[m
[1mindex 1cd1b9b..489040e 100644[m
[1m--- a/libavcodec/libopenjpegdec.c[m
[1m+++ b/libavcodec/libopenjpegdec.c[m
[36m@@ -77,7 +77,7 @@[m [mstatic const enum AVPixelFormat
libopenjpeg_yuv_pix_fmts[] = {[m
YUV_PIXEL_FORMATS[m
};[m
static const enum AVPixelFormat libopenjpeg_all_pix_fmts[] = {[m
[31m-RGB_PIXEL_FORMATS, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS,
XYZ_PIXEL_FORMATS[m
[32m+[m[32mAV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA, XYZ_PIXEL_FORMATS,
AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS[m
};[m
[m
typedef struct LibOpenJPEGContext {[m
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mxfenc: Adjust product name when opatom muxer is used
On Mon, Mar 2, 2015 at 6:56 PM, Mark Reid mindm...@gmail.com wrote: On Mon, Mar 2, 2015 at 1:46 AM, Robert Krüger krue...@lesspain.de wrote: On Sun, Mar 1, 2015 at 10:43 PM, Mark Reid mindm...@gmail.com wrote: On Sun, Mar 1, 2015 at 4:06 AM, Robert Krüger krue...@lesspain.de wrote: Currently the product name that ends up in mxf files muxed using the new op atom muxer is OP1A muxer which is misleading. Attached patch changes that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel This will change the CRC for make fate-lavf-mxf_opatom So the regression test needs to be updated as well Ah, thank you. Didn't think of that. Is there any place where I can find docs on how to update fate hashes/crcs after a code change? I can see nothing at https://ffmpeg.org/fate.html or https://ffmpeg.org/developer.html https://ffmpeg.org/fate.html#Makefile-variables make GEN=1 fate-lavf-mxf_opatom Thanks. Updated patch attached. mxf_opatom_product_name.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC Decoder - fixed point implementation
On Fri, Nov 7, 2014 at 12:08 PM, Nedeljko Babic nedeljko.ba...@imgtec.com wrote: Hello, I am resending patch set with the implementation of fixed point AAC decoder. Our implementation of float emulation integrated in softfloat as requested. Patche set rebased to the newest code since there were some changes that conflicted with previous implementation. Patch with fate tests for aac fixed decoder added. Please have a look. Hi These patches need rebasing. If you post rebased patches I'll be happy to take a look. I tried applying them but got too many failures. Also, can you confirm that these patches are meant to apply on top of b1c99f4c5f8f3dc07264cf8011a9635cd3321cc6 ? I will do some automated tests on the patchset to evaluate their impact and I wouldn't want to be testing on the wrong commit. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port FFT domain filter.
On Tue, Mar 03, 2015 at 12:06:09PM +0530, arwa arif wrote:
I tried to change the name to fft, but it is conflicting with
libavcodec/fft. So, I am unable to change that. I have updated the patch,
adding support to coloured images.
yes, the names could conflict in configure indeed
[...]
+
+#include libavfilter/internal.h
+#include libavutil/common.h
+#include libavutil/imgutils.h
+#include libavutil/opt.h
+#include libavutil/pixdesc.h
+#include libavcodec/avfft.h
+#include libavutil/eval.h
+
+typedef struct {
+const AVClass *class;
+
+RDFTContext *rdft;
+int rdft_hbits[3];
+int rdft_vbits[3];
+size_t rdft_hlen[3];
+size_t rdft_vlen[3];
+FFTSample *rdft_hdata[3];
+FFTSample *rdft_vdata[3];
+
+int dc;
+char *lum_str;
+AVExpr *lum_expr;
+double *lum_data;
+
+} FFTFILTContext;
+
+static const char *const var_names[] = { X, Y, W, H,
NULL};
+enum { VAR_X, VAR_Y, VAR_W, VAR_H,
VAR_VARS_NB };
+
+#define OFFSET(x) offsetof(FFTFILTContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption fftfilt_options[] = {
+{ dc, adjust gain, OFFSET(dc), AV_OPT_TYPE_INT,
{.i64 = 0}, 0, 1000, FLAGS },
+{ lum, set luminance expression, OFFSET(lum_str),
AV_OPT_TYPE_STRING, {.str = 1}, CHAR_MIN, CHAR_MAX, FLAGS },
+{NULL},
The user should be able to set seperate dc / lum for teh 3 planes
that is if only the first dc and first exression is set then they
should be used for all 3 planes
otherwise, if teh user set 3 dc values and 3 expressions then each
plane should use the specific expression
[...]
+
+memset(fftfilt-rdft_hdata[plane] + i * fftfilt-rdft_hlen[plane], 0,
+ fftfilt-rdft_hlen[plane] *
sizeof(*fftfilt-rdft_hdata[plane]));
the memseting should ideally be replaced by mirroring, this leads
to better quality
for example
matrixbench_mpeg2.mpg -vf fftfilt=dc=128:lum='(1 / (1 +
exp(-(Y+X)/10.0+H/100.0)))'
results in a pink border due to this
that is instead of for each line
1 2 3 3 7 9 10 11 23
it should not be changed to:
1 2 3 3 7 9 10 11 23 0 0 0 0 0 0 0
but
1 2 3 3 7 9 10 11 23 23 11 10 x 3 2 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 10/12] mips: use float* to hold pointer instead of int
LGTM
- Nedeljko
Od: James Cowgill [james...@cowgill.org.uk]
Poslato: 26. februar 2015 14:42
Za: ffmpeg-devel@ffmpeg.org
Cc: Nedeljko Babic; James Cowgill
Tema: [PATCH 10/12] mips: use float* to hold pointer instead of int
This is obviously needed for 64-bit support.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aacdec_mips.c | 2 +-
libavcodec/mips/aacpsdsp_mips.c | 12 ++--
libavcodec/mips/sbrdsp_mips.c | 10 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/mips/aacdec_mips.c b/libavcodec/mips/aacdec_mips.c
index 5e0a83d..b6eec53 100644
--- a/libavcodec/mips/aacdec_mips.c
+++ b/libavcodec/mips/aacdec_mips.c
@@ -344,7 +344,7 @@ static void update_ltp_mips(AACContext *ac,
SingleChannelElement *sce)
if (ics-window_sequence[0] == EIGHT_SHORT_SEQUENCE) {
float *p_saved_ltp = saved_ltp + 576;
-int loop_end1 = (int)(p_saved_ltp + 448);
+float *loop_end1 = p_saved_ltp + 448;
float_copy(saved_ltp, saved, 512);
diff --git a/libavcodec/mips/aacpsdsp_mips.c b/libavcodec/mips/aacpsdsp_mips.c
index 1175918..b03cc3f 100644
--- a/libavcodec/mips/aacpsdsp_mips.c
+++ b/libavcodec/mips/aacpsdsp_mips.c
@@ -293,7 +293,7 @@ static void ps_decorrelate_mips(float (*out)[2], float
(*delay)[2],
float phi_fract1 = phi_fract[1];
float temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7, temp8, temp9;
-len = (int)((int*)p_delay + (len 1));
+float *p_delay_end = (p_delay + (len 1));
/* merged 2 loops */
__asm__ volatile(
@@ -369,7 +369,7 @@ static void ps_decorrelate_mips(float (*out)[2], float
(*delay)[2],
swc1%[temp3], 628(%[p_ap_delay]) \n\t
swc1%[temp5], -8(%[p_out]) \n\t
swc1%[temp6], -4(%[p_out]) \n\t
-bne %[p_delay],%[len],1b\n\t
+bne %[p_delay],%[p_delay_end],1b\n\t
swc1 %[temp6], -4(%[p_out]) \n\t
.setpop \n\t
@@ -380,7 +380,7 @@ static void ps_decorrelate_mips(float (*out)[2], float
(*delay)[2],
[p_Q_fract]+r(p_Q_fract), [p_t_gain]+r(p_t_gain),
[p_out]+r(p_out),
[ag0]=f(ag0), [ag1]=f(ag1), [ag2]=f(ag2)
: [phi_fract0]f(phi_fract0), [phi_fract1]f(phi_fract1),
- [len]r(len), [g_decay_slope]f(g_decay_slope)
+ [p_delay_end]r(p_delay_end), [g_decay_slope]f(g_decay_slope)
: memory
);
}
@@ -400,7 +400,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], float
(*r)[2],
float temp0, temp1, temp2, temp3;
float l_re, l_im, r_re, r_im;
-len = (int)((int*)l + (len 1));
+float *l_end = ((float *)l + (len 1));
__asm__ volatile(
.setpush \n\t
@@ -427,7 +427,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], float
(*r)[2],
swc1%[temp0], -8(%[l]) \n\t
swc1%[temp2], -8(%[r]) \n\t
swc1%[temp1], -4(%[l]) \n\t
-bne %[l], %[len],1b \n\t
+bne %[l], %[l_end], 1b \n\t
swc1 %[temp3], -4(%[r]) \n\t
.setpop \n\t
@@ -438,7 +438,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], float
(*r)[2],
[l_re]=f(l_re), [l_im]=f(l_im),
[r_re]=f(r_re), [r_im]=f(r_im)
: [hs0]f(hs0), [hs1]f(hs1), [hs2]f(hs2),
- [hs3]f(hs3), [len]r(len)
+ [hs3]f(hs3), [l_end]r(l_end)
: memory
);
}
diff --git a/libavcodec/mips/sbrdsp_mips.c b/libavcodec/mips/sbrdsp_mips.c
index 5c21749..9f2d827 100644
--- a/libavcodec/mips/sbrdsp_mips.c
+++ b/libavcodec/mips/sbrdsp_mips.c
@@ -665,14 +665,14 @@ static void sbr_hf_gen_mips(float (*X_high)[2], const
float (*X_low)[2],
static void sbr_hf_g_filt_mips(float (*Y)[2], const float (*X_high)[40][2],
const float *g_filt, int m_max, intptr_t ixh)
{
-float *p_y, *p_x, *p_g;
+const float *p_x, *p_g, *loop_end;
+float *p_y;
float temp0, temp1, temp2;
-int loop_end;
-p_g = (float*)g_filt[0];
+p_g = g_filt[0];
p_y = Y[0][0];
-p_x = (float*)X_high[0][ixh][0];
-loop_end = (int)((int*)p_g + m_max);
+p_x = X_high[0][ixh][0];
+loop_end = p_g + m_max;
__asm__ volatile(
.setpush\n\t
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 12/12] mips/aaccoder: use variables instead of using register names directly
LGTM
-Nedeljko
Od: James Cowgill [james...@cowgill.org.uk]
Poslato: 26. februar 2015 14:42
Za: ffmpeg-devel@ffmpeg.org
Cc: Nedeljko Babic; James Cowgill
Tema: [PATCH 12/12] mips/aaccoder: use variables instead of using register
names directly
On mips64, the registers t[4-7] do not exist. Instead of using a lot of #ifdef
or defines to handle differing register names, use variables and let GCC
allocate the registers automatically (like in the other mips assembly files).
In get_band_cost_ESC_mips, t4 and t5 were renamed to t6 and t7 to avoid a
variable name conflict.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aaccoder_mips.c | 929 +---
1 file changed, 477 insertions(+), 452 deletions(-)
diff --git a/libavcodec/mips/aaccoder_mips.c b/libavcodec/mips/aaccoder_mips.c
index 8595913..ea0bf31 100644
--- a/libavcodec/mips/aaccoder_mips.c
+++ b/libavcodec/mips/aaccoder_mips.c
@@ -221,6 +221,7 @@ static void quantize_and_encode_band_cost_SQUAD_mips(struct
AACEncContext *s,
for (i = 0; i size; i += 4) {
int curidx;
int *in_int = (int *)in[i];
+int t0, t1, t2, t3, t4, t5, t6, t7;
qc1 = scaled[i ] * Q34 + 0.4054f;
qc2 = scaled[i+1] * Q34 + 0.4054f;
@@ -235,31 +236,31 @@ static void
quantize_and_encode_band_cost_SQUAD_mips(struct AACEncContext *s,
slt%[qc2], $zero, %[qc2] \n\t
slt%[qc3], $zero, %[qc3] \n\t
slt%[qc4], $zero, %[qc4] \n\t
-lw $t0,0(%[in_int])\n\t
-lw $t1,4(%[in_int])\n\t
-lw $t2,8(%[in_int])\n\t
-lw $t3,12(%[in_int]) \n\t
-srl$t0,$t0,31 \n\t
-srl$t1,$t1,31 \n\t
-srl$t2,$t2,31 \n\t
-srl$t3,$t3,31 \n\t
-subu $t4,$zero, %[qc1] \n\t
-subu $t5,$zero, %[qc2] \n\t
-subu $t6,$zero, %[qc3] \n\t
-subu $t7,$zero, %[qc4] \n\t
-movn %[qc1], $t4,$t0 \n\t
-movn %[qc2], $t5,$t1 \n\t
-movn %[qc3], $t6,$t2 \n\t
-movn %[qc4], $t7,$t3 \n\t
+lw %[t0], 0(%[in_int])\n\t
+lw %[t1], 4(%[in_int])\n\t
+lw %[t2], 8(%[in_int])\n\t
+lw %[t3], 12(%[in_int]) \n\t
+srl%[t0], %[t0], 31 \n\t
+srl%[t1], %[t1], 31 \n\t
+srl%[t2], %[t2], 31 \n\t
+srl%[t3], %[t3], 31 \n\t
+subu %[t4], $zero, %[qc1] \n\t
+subu %[t5], $zero, %[qc2] \n\t
+subu %[t6], $zero, %[qc3] \n\t
+subu %[t7], $zero, %[qc4] \n\t
+movn %[qc1], %[t4], %[t0] \n\t
+movn %[qc2], %[t5], %[t1] \n\t
+movn %[qc3], %[t6], %[t2] \n\t
+movn %[qc4], %[t7], %[t3] \n\t
.set pop \n\t
: [qc1]+r(qc1), [qc2]+r(qc2),
- [qc3]+r(qc3), [qc4]+r(qc4)
+ [qc3]+r(qc3), [qc4]+r(qc4),
+ [t0]=r(t0), [t1]=r(t1), [t2]=r(t2), [t3]=r(t3),
+ [t4]=r(t4), [t5]=r(t5), [t6]=r(t6), [t7]=r(t7)
: [in_int]r(in_int)
-: t0, t1, t2, t3,
- t4, t5, t6, t7,
- memory
+: memory
);
curidx = qc1;
@@ -295,6 +296,7 @@ static void quantize_and_encode_band_cost_UQUAD_mips(struct
AACEncContext *s,
int *in_int = (int *)in[i];
uint8_t v_bits;
unsigned int v_codes;
+int t0, t1, t2, t3, t4;
qc1 = scaled[i ] * Q34 + 0.4054f;
qc2 = scaled[i+1] * Q34 + 0.4054f;
@@ -305,50 +307,51 @@ static void
quantize_and_encode_band_cost_UQUAD_mips(struct AACEncContext *s,
.set push \n\t
.set noreorder \n\t
-ori$t4,$zero, 2 \n\t
+ori%[t4], $zero, 2 \n\t
ori%[sign],$zero, 0 \n\t
-slt$t0,$t4,%[qc1] \n\t
-slt$t1,$t4,%[qc2] \n\t
-slt$t2,$t4,%[qc3] \n\t
-slt$t3,$t4,%[qc4] \n\t
-movn %[qc1], $t4,$t0 \n\t
-movn %[qc2], $t4,$t1 \n\t
-movn %[qc3], $t4,$t2 \n\t
-movn %[qc4], $t4,$t3 \n\t
-lw $t0,0(%[in_int])\n\t
-lw $t1,4(%[in_int])\n\t
-lw $t2,8(%[in_int])\n\t
-lw $t3,12(%[in_int])
Re: [FFmpeg-devel] [PATCH] fix VP9 packet decoder returning 0 instead of the used data size
On Tue, Mar 03, 2015 at 12:06:40PM +0100, Steve Lhomme wrote: See https://trac.videolan.org/vlc/ticket/14022#comment:6 --- libavcodec/vp9.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] ffplay: factorize subtitle rendering code to a private filter
On Tue, 3 Mar 2015 15:03:19 +0100 Lukasz Marek lukasz.m.lu...@gmail.com wrote: On 3 March 2015 at 14:16, wm4 nfx...@googlemail.com wrote: On Tue, 3 Mar 2015 13:17:12 +0100 Lukasz Marek lukasz.m.lu...@gmail.com wrote: On 17 February 2015 at 03:27, Marton Balint c...@passwd.hu wrote: On Sat, 14 Feb 2015, Clément Bœsch wrote: On Sat, Feb 14, 2015 at 02:08:15AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint c...@passwd.hu --- Makefile | 1 + doc/ffplay.texi | 4 + ffplay.c | 336 +- --- libavfilter/Makefile | 1 + libavfilter/vf_ffplay_subtitle.c | 347 ++ + libavfilter/vf_ffplay_subtitle.h | 38 + 6 files changed, 434 insertions(+), 293 deletions(-) create mode 100644 libavfilter/vf_ffplay_subtitle.c create mode 100644 libavfilter/vf_ffplay_subtitle.h This is not the correct way of doing it. The proper way is to integrate subtitles within lavfi. If you want to work toward this, feel free to ask for more details, but it's not trivial. (and no, this patch is not an improvement in the correct direction, sorry) What would be an improvement in the right direction? I see little chance that I will work on subtitles in lavfi, but if there is a better/preferred way to change ffplay to support subtitles in the filter chain without waiting for the whole subtitles-in-libavfilter infrastructure, I may be interested in working toward that. Just random guess, but for now you could implement this filter in ffplay_sub_filter.c (or something) and register it from ffplay. So code of ffplay itself is cleaner and libavfilter is not spoiled. When this all suff Clement is talking about is done then it can be pushed further. I like this patch because some time ago I ported ffplay to ios and removing this code was annoying. API users can't add new filters from the outside. Isn't it allowed (and enough) to call avfilter_register with own filter? If not then I,m surprised TBH. No. While the register function is public, you'd need to use private APIs to actually implement the filter. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] libx265: Return proper invalid data code
On Tue, Mar 03, 2015 at 04:26:46PM +0100, Alexander Strasser wrote: On 2015-02-17 22:15 +, Derek Buitenhuis wrote: On 2/17/2015 10:10 PM, James Almer wrote: Afaik, if the error is based on user input then EINVAL (Invalid argument) is correct. AVERROR_INVALIDDATA is when the error is in the bitstream/container and not an argument the user passed to the library. Right, I conflated the two. Patch dropped. Sorry to reply to this old'ish thread. Just wanted to say I find the distinction kind of superficial; why do we do it again? Invalid data is related to reading an unknown source, it's not exactly under user control. Invalid argument is a user specified parameter. The user is often responsible if this is triggered. They are not really related. -- Clément B. pgpYVSiPCE1eP.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] libx265: Return proper invalid data code
On 2015-02-17 22:15 +, Derek Buitenhuis wrote: On 2/17/2015 10:10 PM, James Almer wrote: Afaik, if the error is based on user input then EINVAL (Invalid argument) is correct. AVERROR_INVALIDDATA is when the error is in the bitstream/container and not an argument the user passed to the library. Right, I conflated the two. Patch dropped. Sorry to reply to this old'ish thread. Just wanted to say I find the distinction kind of superficial; why do we do it again? Alexander pgpn_hd5rbIA4.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fix VP9 packet decoder returning 0 instead of the used data size
See https://trac.videolan.org/vlc/ticket/14022#comment:6 --- libavcodec/vp9.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c index 2bb2432..c7f351b 100644 --- a/libavcodec/vp9.c +++ b/libavcodec/vp9.c @@ -3760,7 +3760,7 @@ static int vp9_decode_frame(AVCodecContext *ctx, void *frame, if ((res = av_frame_ref(frame, s-refs[ref].f)) 0) return res; *got_frame = 1; -return 0; +return pkt-size; } data += res; size -= res; @@ -3984,7 +3984,7 @@ static int vp9_decode_frame(AVCodecContext *ctx, void *frame, *got_frame = 1; } -return 0; +return pkt-size; } static void vp9_decode_flush(AVCodecContext *ctx) -- 2.2.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] optionally write QuickTime gama atom (was Re: Gamma function)
Updated to use lrint()
On Mon, Mar 2, 2015 at 12:54 PM, Kevin Wheatley
kevin.j.wheat...@gmail.com wrote:
Something like this - note this adds no tests, but fate still passes for me.
Kevin
From 794c8c3cf1e8506393fbcb4ddf1360042b0fc82f Mon Sep 17 00:00:00 2001
From: Kevin Wheatley kevin.j.wheat...@gmail.com
Date: Mon, 2 Mar 2015 12:50:53 +
Subject: [PATCH] Add 'gama' atom for .mov only, reuses pngenc.c gamma values by sharing
function in new color_utils.[ch] file.
Use lrint() instead of round()
Signed-off-by: Kevin Wheatley kevin.j.wheat...@gmail.com
---
libavcodec/pngenc.c | 29 +++--
libavformat/movenc.c| 35 +++
libavformat/movenc.h|2 +
libavutil/Makefile |2 +
libavutil/color_utils.c | 52 +++
libavutil/color_utils.h | 29 ++
6 files changed, 124 insertions(+), 25 deletions(-)
create mode 100644 libavutil/color_utils.c
create mode 100644 libavutil/color_utils.h
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 4e67ce2..fddcca4 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -28,6 +28,7 @@
#include libavutil/avassert.h
#include libavutil/libm.h
#include libavutil/opt.h
+#include libavutil/color_utils.h
#include zlib.h
@@ -277,31 +278,9 @@ static int png_get_chrm(enum AVColorPrimaries prim, uint8_t *buf)
static int png_get_gama(enum AVColorTransferCharacteristic trc, uint8_t *buf)
{
-double gamma;
-switch (trc) {
-case AVCOL_TRC_BT709:
-case AVCOL_TRC_SMPTE170M:
-case AVCOL_TRC_SMPTE240M:
-case AVCOL_TRC_BT1361_ECG:
-case AVCOL_TRC_BT2020_10:
-case AVCOL_TRC_BT2020_12:
-/* these share a segmented TRC, but gamma 1.961 is a close
- approximation, and also more correct for decoding content */
-gamma = 1.961;
-break;
-case AVCOL_TRC_GAMMA22:
-case AVCOL_TRC_IEC61966_2_1:
-gamma = 2.2;
-break;
-case AVCOL_TRC_GAMMA28:
-gamma = 2.8;
-break;
-case AVCOL_TRC_LINEAR:
-gamma = 1.0;
-break;
-default:
-return 0;
-}
+double gamma = get_gamma_from_trc(trc);
+if (gamma = 1e-6)
+return 0;
AV_WB32_PNG(buf, 1.0 / gamma);
return 1;
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e496ba4..7c10d0e 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -40,10 +40,12 @@
#include libavutil/avstring.h
#include libavutil/intfloat.h
#include libavutil/mathematics.h
+#include libavutil/libm.h
#include libavutil/opt.h
#include libavutil/dict.h
#include libavutil/pixdesc.h
#include libavutil/timecode.h
+#include libavutil/color_utils.h
#include hevc.h
#include rtpenc.h
#include mov_chan.h
@@ -65,6 +67,7 @@ static const AVOption options[] = {
{ frag_discont, Signal that the next fragment is discontinuous from earlier ones, 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_FRAG_DISCONT}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, movflags },
{ delay_moov, Delay writing the initial moov until the first fragment is cut, or until the first fragment flush, 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, movflags },
{ write_colr, Write colr atom, 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, movflags },
+{ write_gama, Write deprecated gama atom, 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, movflags },
FF_RTP_FLAG_OPTS(MOVMuxContext, rtp_flags),
{ skip_iods, Skip writing iods atom., offsetof(MOVMuxContext, iods_skip), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
{ iods_audio_profile, iods audio profile atom., offsetof(MOVMuxContext, iods_audio_profile), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 255, AV_OPT_FLAG_ENCODING_PARAM},
@@ -77,6 +80,7 @@ static const AVOption options[] = {
{ brand,Override major brand, offsetof(MOVMuxContext, major_brand), AV_OPT_TYPE_STRING, {.str = NULL}, .flags = AV_OPT_FLAG_ENCODING_PARAM },
{ use_editlist, use edit list, offsetof(MOVMuxContext, use_editlist), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, AV_OPT_FLAG_ENCODING_PARAM},
{ fragment_index, Fragment number of the next fragment, offsetof(MOVMuxContext, fragments), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
+{ mov_gamma, gamma value for gama atom, offsetof(MOVMuxContext, gamma), AV_OPT_TYPE_FLOAT, {.dbl = 0.0 }, 0.0, 10, AV_OPT_FLAG_ENCODING_PARAM},
{ NULL },
};
@@ -1519,6 +1523,31 @@ static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack *track)
return 16;
}
+static int mov_write_gama_tag(AVIOContext *pb, MOVTrack *track, double gamma)
+{
+uint32_t gama = 0;
+if (gamma = 0.0)
+{
+gamma =
Re: [FFmpeg-devel] [PATCH] mxfenc: Adjust product name when opatom muxer is used
On Tue, Mar 03, 2015 at 10:28:26AM +0100, Robert Krüger wrote: On Mon, Mar 2, 2015 at 6:56 PM, Mark Reid mindm...@gmail.com wrote: On Mon, Mar 2, 2015 at 1:46 AM, Robert Krüger krue...@lesspain.de wrote: On Sun, Mar 1, 2015 at 10:43 PM, Mark Reid mindm...@gmail.com wrote: On Sun, Mar 1, 2015 at 4:06 AM, Robert Krüger krue...@lesspain.de wrote: Currently the product name that ends up in mxf files muxed using the new op atom muxer is OP1A muxer which is misleading. Attached patch changes that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel This will change the CRC for make fate-lavf-mxf_opatom So the regression test needs to be updated as well Ah, thank you. Didn't think of that. Is there any place where I can find docs on how to update fate hashes/crcs after a code change? I can see nothing at https://ffmpeg.org/fate.html or https://ffmpeg.org/developer.html https://ffmpeg.org/fate.html#Makefile-variables make GEN=1 fate-lavf-mxf_opatom Thanks. Updated patch attached. libavformat/mxfenc.c |2 +- tests/ref/lavf/mxf_opatom |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) 5d594c92001f17e3844173908db5e195472bf86e mxf_opatom_product_name.patch From 7330ee95d9047707f774aa0f678ef5b3aede7b6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Robert=20Kr=C3=BCger?= krue...@lesspain.de Date: Sun, 1 Mar 2015 13:02:20 +0100 Subject: [PATCH 1/2] adjust product name when opatom muxer is used applied both patches, thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC and Outreachy
On Mon, Mar 2, 2015 at 10:39 PM, Michael Niedermayer michae...@gmx.at wrote: Hi all FFmpeg has been accepted in GSoC this year. Congratulations! You proved quite a few people wrong by this, I guess :-). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] optionally write QuickTime gama atom (was Re: Gamma function)
On Tue, Mar 03, 2015 at 11:10:54AM +, Kevin Wheatley wrote: Updated to use lrint() On Mon, Mar 2, 2015 at 12:54 PM, Kevin Wheatley kevin.j.wheat...@gmail.com wrote: Something like this - note this adds no tests, but fate still passes for me. Kevin libavcodec/pngenc.c | 29 +++--- libavformat/movenc.c| 35 libavformat/movenc.h|2 + libavutil/Makefile |2 + libavutil/color_utils.c | 52 libavutil/color_utils.h | 29 ++ 6 files changed, 124 insertions(+), 25 deletions(-) e5b12ceea12ce494d98c1bc30162a5e604c069c2 0001-Add-gama-atom-for-.mov-only-reuses-pngenc.c-gamma-va.patch From 794c8c3cf1e8506393fbcb4ddf1360042b0fc82f Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Mon, 2 Mar 2015 12:50:53 + Subject: [PATCH] Add 'gama' atom for .mov only, reuses pngenc.c gamma values by sharing function in new color_utils.[ch] file. Use lrint() instead of round() moving the code to a common place and adding gama atom support to mov should be 2 seperate patches also libavutils minor version should be bumped when new API is added to libavutil [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: Fix M/S stereo encoding
On Tue, Mar 03, 2015 at 03:51:48AM -0300, Claudio Freire wrote: This patch fixes a pointer arithmetic bug in adjust_frame_information that resulted in heavily corrupted audio when using M/S encoding. Also, a backup copy of untransformed coefficients has to be kept around or attempts at re-processing the frame (which happens when hevavily overspending bits during transients) will result in re-encoding of the coefficients and subsequent corruption of the resulting stream. A/B testing shows the bug as corrected, but still cannot prove that M/S coding is a win at least in numbers. Limited listening tests do show improvement on M/S encoded samples in lower bitrates, but they're hidden among the other artifacts that remain to be corrected in the encoder. Some of the regressions flagged in the report do show poor stereo image (but not buggy), so M/S encoding is clearly not good enough yet to be defaulted to auto. In numbers, Patched against Unpatched, stereo_mode auto: 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] [RFC][PATCH] ffplay: factorize subtitle rendering code to a private filter
On Tue, 3 Mar 2015 13:17:12 +0100 Lukasz Marek lukasz.m.lu...@gmail.com wrote: On 17 February 2015 at 03:27, Marton Balint c...@passwd.hu wrote: On Sat, 14 Feb 2015, Clément Bœsch wrote: On Sat, Feb 14, 2015 at 02:08:15AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint c...@passwd.hu --- Makefile | 1 + doc/ffplay.texi | 4 + ffplay.c | 336 +- --- libavfilter/Makefile | 1 + libavfilter/vf_ffplay_subtitle.c | 347 ++ + libavfilter/vf_ffplay_subtitle.h | 38 + 6 files changed, 434 insertions(+), 293 deletions(-) create mode 100644 libavfilter/vf_ffplay_subtitle.c create mode 100644 libavfilter/vf_ffplay_subtitle.h This is not the correct way of doing it. The proper way is to integrate subtitles within lavfi. If you want to work toward this, feel free to ask for more details, but it's not trivial. (and no, this patch is not an improvement in the correct direction, sorry) What would be an improvement in the right direction? I see little chance that I will work on subtitles in lavfi, but if there is a better/preferred way to change ffplay to support subtitles in the filter chain without waiting for the whole subtitles-in-libavfilter infrastructure, I may be interested in working toward that. Just random guess, but for now you could implement this filter in ffplay_sub_filter.c (or something) and register it from ffplay. So code of ffplay itself is cleaner and libavfilter is not spoiled. When this all suff Clement is talking about is done then it can be pushed further. I like this patch because some time ago I ported ffplay to ios and removing this code was annoying. API users can't add new filters from the outside. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port FFT domain filter.
On Tue, Mar 03, 2015 at 12:06:09PM +0530, arwa arif wrote:
I tried to change the name to fft, but it is conflicting with
libavcodec/fft. So, I am unable to change that. I have updated the patch,
adding support to coloured images.
doc/filters.texi | 22 +++
libavfilter/Makefile |1
libavfilter/allfilters.c |1
libavfilter/vf_fftfilt.c | 294
+++
4 files changed, 318 insertions(+)
1ad6ddaa83fe13ae3234b4e359c8c1d719047f30 0001-Add-FFT-domain-filter.patch
From 7b479d2236067e5599f6e4670f319be4a643 Mon Sep 17 00:00:00 2001
From: Arwa Arif arwaarif1...@gmail.com
Date: Tue, 24 Feb 2015 12:17:30 +0530
Subject: [PATCH] Add FFT domain filter.
[...]
+AVFilter ff_vf_fftfilt = {
+.name= fftfilt,
+.description = NULL_IF_CONFIG_SMALL(Adjust dc value and
luminance.),
something like
Apply arbitrary expressions to samples in frequency domain
maybe sounds better
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] optionally write QuickTime gama atom (was Re: Gamma function)
On Tue, 3 Mar 2015 11:10:54 +
Kevin Wheatley kevin.j.wheat...@gmail.com wrote:
From 794c8c3cf1e8506393fbcb4ddf1360042b0fc82f Mon Sep 17 00:00:00 2001
From: Kevin Wheatley kevin.j.wheat...@gmail.com
Date: Mon, 2 Mar 2015 12:50:53 +
Subject: [PATCH] Add 'gama' atom for .mov only, reuses pngenc.c gamma values
by sharing
function in new color_utils.[ch] file.
Use lrint() instead of round()
Signed-off-by: Kevin Wheatley kevin.j.wheat...@gmail.com
---
libavcodec/pngenc.c | 29 +++--
libavformat/movenc.c| 35 +++
libavformat/movenc.h|2 +
libavutil/Makefile |2 +
libavutil/color_utils.c | 52
+++
libavutil/color_utils.h | 29 ++
6 files changed, 124 insertions(+), 25 deletions(-)
create mode 100644 libavutil/color_utils.c
create mode 100644 libavutil/color_utils.h
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 4e67ce2..fddcca4 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -28,6 +28,7 @@
#include libavutil/avassert.h
#include libavutil/libm.h
#include libavutil/opt.h
+#include libavutil/color_utils.h
#include zlib.h
@@ -277,31 +278,9 @@ static int png_get_chrm(enum AVColorPrimaries prim,
uint8_t *buf)
static int png_get_gama(enum AVColorTransferCharacteristic trc, uint8_t *buf)
{
-double gamma;
-switch (trc) {
-case AVCOL_TRC_BT709:
-case AVCOL_TRC_SMPTE170M:
-case AVCOL_TRC_SMPTE240M:
-case AVCOL_TRC_BT1361_ECG:
-case AVCOL_TRC_BT2020_10:
-case AVCOL_TRC_BT2020_12:
-/* these share a segmented TRC, but gamma 1.961 is a close
- approximation, and also more correct for decoding content */
-gamma = 1.961;
-break;
-case AVCOL_TRC_GAMMA22:
-case AVCOL_TRC_IEC61966_2_1:
-gamma = 2.2;
-break;
-case AVCOL_TRC_GAMMA28:
-gamma = 2.8;
-break;
-case AVCOL_TRC_LINEAR:
-gamma = 1.0;
-break;
-default:
-return 0;
-}
+double gamma = get_gamma_from_trc(trc);
+if (gamma = 1e-6)
+return 0;
AV_WB32_PNG(buf, 1.0 / gamma);
return 1;
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e496ba4..7c10d0e 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -40,10 +40,12 @@
#include libavutil/avstring.h
#include libavutil/intfloat.h
#include libavutil/mathematics.h
+#include libavutil/libm.h
#include libavutil/opt.h
#include libavutil/dict.h
#include libavutil/pixdesc.h
#include libavutil/timecode.h
+#include libavutil/color_utils.h
#include hevc.h
#include rtpenc.h
#include mov_chan.h
@@ -65,6 +67,7 @@ static const AVOption options[] = {
{ frag_discont, Signal that the next fragment is discontinuous from
earlier ones, 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_FRAG_DISCONT},
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, movflags },
{ delay_moov, Delay writing the initial moov until the first fragment
is cut, or until the first fragment flush, 0, AV_OPT_TYPE_CONST, {.i64 =
FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM,
movflags },
{ write_colr, Write colr atom, 0, AV_OPT_TYPE_CONST, {.i64 =
FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM,
movflags },
+{ write_gama, Write deprecated gama atom, 0, AV_OPT_TYPE_CONST,
{.i64 = FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM, movflags },
FF_RTP_FLAG_OPTS(MOVMuxContext, rtp_flags),
{ skip_iods, Skip writing iods atom., offsetof(MOVMuxContext,
iods_skip), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
{ iods_audio_profile, iods audio profile atom.,
offsetof(MOVMuxContext, iods_audio_profile), AV_OPT_TYPE_INT, {.i64 = -1},
-1, 255, AV_OPT_FLAG_ENCODING_PARAM},
@@ -77,6 +80,7 @@ static const AVOption options[] = {
{ brand,Override major brand, offsetof(MOVMuxContext,
major_brand), AV_OPT_TYPE_STRING, {.str = NULL}, .flags =
AV_OPT_FLAG_ENCODING_PARAM },
{ use_editlist, use edit list, offsetof(MOVMuxContext,
use_editlist), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1,
AV_OPT_FLAG_ENCODING_PARAM},
{ fragment_index, Fragment number of the next fragment,
offsetof(MOVMuxContext, fragments), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
+{ mov_gamma, gamma value for gama atom, offsetof(MOVMuxContext,
gamma), AV_OPT_TYPE_FLOAT, {.dbl = 0.0 }, 0.0, 10,
AV_OPT_FLAG_ENCODING_PARAM},
{ NULL },
};
@@ -1519,6 +1523,31 @@ static int mov_write_pasp_tag(AVIOContext *pb,
MOVTrack *track)
return 16;
}
+static int mov_write_gama_tag(AVIOContext *pb, MOVTrack *track, double gamma)
+{
+uint32_t gama =
Re: [FFmpeg-devel] [PATCH v2] Interpretation of duration field in AVI super index chunk
On 26.02.2015 15:41, Michael Niedermayer wrote:
On Thu, Feb 26, 2015 at 02:14:33PM +0100, Tobias Rapp wrote:
On 26.02.2015 00:51, Michael Niedermayer wrote:
On Wed, Feb 25, 2015 at 05:35:33PM +0100, Tobias Rapp wrote:
[...]
@@ -511,7 +514,11 @@ static int avi_write_ix(AVFormatContext *s)
avio_skip(pb, 16 * avi-riff_id);
avio_wl64(pb, ix);/* qwOffset */
avio_wl32(pb, pos - ix); /* dwSize */
-avio_wl32(pb, avist-indexes.entry); /* dwDuration */
+ff_parse_specific_params(s-streams[i], au_byterate, au_ssize,
au_scale);
+if (au_ssize == 0)
+avio_wl32(pb, avist-indexes.entry); /* dwDuration (packet count)
*/
+else
+avio_wl32(pb, (avist-audio_strm_length -
avist-indexes.audio_strm_offset) / au_ssize); /* dwDuration (sample count) */
the rounding here is wrong
the index to be useable needs to have segments duration summable
as is this would lead to significangt errors if many of these
durations would be summed up
something like
avist-audio_strm_length / au_ssize - avist-indexes.audio_strm_offset /
au_ssize
might avoid that but ive not tested it
My assumption was that a stream packet contains only whole samples
for linear/uncompressed audio (PCM) and that only for linear audio
the expression au_ssize 0 evaluates to TRUE.
We try to use au_ssize = 0 for compressed audio but i think it can be
non zero in some stream copy cases, iam not 100% sure though
If that is not the case I can do the rounding as suggested or maybe
introduce some separate stream duration counter based on
AVPacket.duration?
i think best to keep it simple and maybe print a request for a sample/
testcase if some combination of parameters is found which we are
unsure about if it works correctly
Attached a new patch that calls avpriv_request_sample if the audio
segment size is no multiple of au_ssize. Tested different audio encoder
types (pcm_s16le, pcm_s24le, adpcm_ms, mp2, libmp3lame) with success.
Regards,
Tobias
From 89d3f13169e2ff183a1e60c9939263035ad83a0f Mon Sep 17 00:00:00 2001
From: Tobias Rapp t.r...@noa-audio.com
Date: Tue, 3 Mar 2015 13:29:05 +0100
Subject: [PATCH] libavformat/avienc: Fix duration of audio segment in OpenDML
master index
Fixes the duration field of the OpenDML master index indx chunk to
contain the number of samples instead of the number of packets for
(linear/PCM) audio streams.
This matches the OpenDML V1.02 standard text which states that the
duration field shall contain time span in stream ticks.
---
libavformat/avienc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 53c2fe7..3b5e5c4 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -49,6 +49,7 @@ typedef struct AVIIentry {
typedef struct AVIIndex {
int64_t indx_start;
+int64_t audio_strm_offset;
int entry;
int ents_allocated;
AVIIentry** cluster;
@@ -66,6 +67,7 @@ typedef struct AVIStream {
int packet_count;
int entry;
int max_size;
+int sample_requested;
int64_t last_dts;
@@ -91,6 +93,7 @@ static int64_t avi_start_new_riff(AVFormatContext *s,
AVIOContext *pb,
avi-riff_id++;
for (i = 0; i s-nb_streams; i++) {
AVIStream *avist = s-streams[i]-priv_data;
+avist-indexes.audio_strm_offset = avist-audio_strm_length;
avist-indexes.entry = 0;
}
@@ -476,6 +479,7 @@ static int avi_write_ix(AVFormatContext *s)
for (i = 0; i s-nb_streams; i++) {
AVIStream *avist = s-streams[i]-priv_data;
int64_t ix, pos;
+int au_byterate, au_ssize, au_scale;
avi_stream2fourcc(tag, i, s-streams[i]-codec-codec_type);
ix_tag[3] = '0' + i;
@@ -511,7 +515,16 @@ static int avi_write_ix(AVFormatContext *s)
avio_skip(pb, 16 * avi-riff_id);
avio_wl64(pb, ix);/* qwOffset */
avio_wl32(pb, pos - ix); /* dwSize */
-avio_wl32(pb, avist-indexes.entry); /* dwDuration */
+ff_parse_specific_params(s-streams[i], au_byterate, au_ssize,
au_scale);
+if (s-streams[i]-codec-codec_type == AVMEDIA_TYPE_AUDIO au_ssize
0) {
+uint32_t audio_segm_size = (avist-audio_strm_length -
avist-indexes.audio_strm_offset);
+if ((audio_segm_size % au_ssize 0) !avist-sample_requested) {
+avpriv_request_sample(s, OpenDML index duration for audio
packets with partial frames);
+avist-sample_requested = 1;
+}
+avio_wl32(pb, audio_segm_size / au_ssize); /* dwDuration (sample
count) */
+} else
+avio_wl32(pb, avist-indexes.entry); /* dwDuration (packet count)
*/
avio_seek(pb, pos, SEEK_SET);
}
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
[FFmpeg-devel] [PATCH] mov: write colr by default
This is based on an earlier patch by Derek that never went in because it was argumented earlier that api breakage is not acceptable. However, that was more or less relaxed after Michael noted that the replaced flag had never been part of a release and since a number of people seem to agree, this is the better default, I am submitting this patch now, to have it in before the upcoming release. Let me know if that will be accepted and I will modify the respective fate tests as well. mov_write_colr_by_default.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 1/2] libavformat/avio: added avio_put_str16be
On Mon, Mar 02, 2015 at 08:06:13PM -0800, Mark Reid wrote: --- doc/APIchanges| 3 +++ libavformat/avio.h| 6 ++ libavformat/aviobuf.c | 23 +++ libavformat/version.h | 4 ++-- 4 files changed, 30 insertions(+), 6 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port FFT domain filter.
On Tue, Mar 3, 2015 at 6:11 PM, Michael Niedermayer michae...@gmx.at
wrote:
On Tue, Mar 03, 2015 at 12:06:09PM +0530, arwa arif wrote:
I tried to change the name to fft, but it is conflicting with
libavcodec/fft. So, I am unable to change that. I have updated the patch,
adding support to coloured images.
yes, the names could conflict in configure indeed
[...]
+
+#include libavfilter/internal.h
+#include libavutil/common.h
+#include libavutil/imgutils.h
+#include libavutil/opt.h
+#include libavutil/pixdesc.h
+#include libavcodec/avfft.h
+#include libavutil/eval.h
+
+typedef struct {
+const AVClass *class;
+
+RDFTContext *rdft;
+int rdft_hbits[3];
+int rdft_vbits[3];
+size_t rdft_hlen[3];
+size_t rdft_vlen[3];
+FFTSample *rdft_hdata[3];
+FFTSample *rdft_vdata[3];
+
+int dc;
+char *lum_str;
+AVExpr *lum_expr;
+double *lum_data;
+
+} FFTFILTContext;
+
+static const char *const var_names[] = { X, Y, W, H,
NULL};
+enum { VAR_X, VAR_Y, VAR_W, VAR_H,
VAR_VARS_NB };
+
+#define OFFSET(x) offsetof(FFTFILTContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption fftfilt_options[] = {
+{ dc, adjust gain, OFFSET(dc),
AV_OPT_TYPE_INT,{.i64 = 0}, 0, 1000, FLAGS },
+{ lum, set luminance expression, OFFSET(lum_str),
AV_OPT_TYPE_STRING, {.str = 1}, CHAR_MIN, CHAR_MAX, FLAGS },
+{NULL},
The user should be able to set seperate dc / lum for teh 3 planes
that is if only the first dc and first exression is set then they
should be used for all 3 planes
otherwise, if teh user set 3 dc values and 3 expressions then each
plane should use the specific expression
[...]
+
+memset(fftfilt-rdft_hdata[plane] + i *
fftfilt-rdft_hlen[plane], 0,
+ fftfilt-rdft_hlen[plane] *
sizeof(*fftfilt-rdft_hdata[plane]));
the memseting should ideally be replaced by mirroring, this leads
to better quality
for example
matrixbench_mpeg2.mpg -vf fftfilt=dc=128:lum='(1 / (1 +
exp(-(Y+X)/10.0+H/100.0)))'
results in a pink border due to this
that is instead of for each line
1 2 3 3 7 9 10 11 23
it should not be changed to:
1 2 3 3 7 9 10 11 23 0 0 0 0 0 0 0
but
1 2 3 3 7 9 10 11 23 23 11 10 x 3 2 1
But, we want to clear the block of memory. Why do we want to mirror it?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
___
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 07/12] mips/aacdec: remove uses of mips32r2 specific ext instructions
On Tue, 2015-03-03 at 12:42 +, Nedeljko Babic wrote: Removing these removes the dependency of this code on mips32r2 which would allow it to be used on processors which have FPU instructions, but not r2 instructions (like the mips64el debian port for instance). I would be more comfortable if there were two instances of this code: one for mips32r2 and one for mips32 so advantages of using mips32r2 instructions (however small here) are left intact. On the other hand, since this doesn't change much number of instructions used (adding at maximum around 100 instructions overall if I am not mistaking) I am ok with this. Well I can't see how 'ext' can ever be faster than 'and' (it does more work) so most of these should be no slower anyway. For VMUL4S my version has 2 extra instructions in it so it could be a bit slower. Does this #if seem ok? --- a/libavcodec/mips/aacdec_mips.h +++ b/libavcodec/mips/aacdec_mips.h @@ -198,9 +198,18 @@ static inline float *VMUL4S_mips(float *dst, const float *v, unsigned idx, lwxc1 %[temp12], %[temp3](%[v])\n\t lwxc1 %[temp13], %[temp4](%[v])\n\t and %[temp1], %[sign], %[mask] \n\t +#if defined(__mips_isa_rev) __mips_isa_rev = 2 ext %[temp2], %[idx], 12, 1 \n\t ext %[temp3], %[idx], 13, 1 \n\t ext %[temp4], %[idx], 14, 1 \n\t +#else +srl %[temp2], %[idx], 12 \n\t +srl %[temp3], %[idx], 13 \n\t +srl %[temp4], %[idx], 14 \n\t +andi%[temp2], %[temp2], 1 \n\t +andi%[temp3], %[temp3], 1 \n\t +andi%[temp4], %[temp4], 1 \n\t +#endif sllv%[sign],%[sign], %[temp2]\n\t xor %[temp1], %[temp0], %[temp1]\n\t and %[temp2], %[sign], %[mask] \n\t Thanks, James ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 1/2] libavformat/avio: added avio_put_str16be
On Tue, Mar 3, 2015 at 9:25 AM, Michael Niedermayer michae...@gmx.at wrote: On Mon, Mar 02, 2015 at 08:06:13PM -0800, Mark Reid wrote: --- doc/APIchanges| 3 +++ libavformat/avio.h| 6 ++ libavformat/aviobuf.c | 23 +++ libavformat/version.h | 4 ++-- 4 files changed, 30 insertions(+), 6 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I'll need to resend part 2 of this patch series to update a regression test because this recent commit http://git.videolan.org/?p=ffmpeg.git;a=commit;h=618021ea58cda5ce294efa53ce5a69ce27420ef8 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] ffplay: factorize subtitle rendering code to a private filter
On Tue, Mar 03, 2015 at 04:04:09PM +0100, wm4 wrote: On Tue, 3 Mar 2015 15:03:19 +0100 Lukasz Marek lukasz.m.lu...@gmail.com wrote: On 3 March 2015 at 14:16, wm4 nfx...@googlemail.com wrote: On Tue, 3 Mar 2015 13:17:12 +0100 Lukasz Marek lukasz.m.lu...@gmail.com wrote: On 17 February 2015 at 03:27, Marton Balint c...@passwd.hu wrote: On Sat, 14 Feb 2015, Clément Bœsch wrote: On Sat, Feb 14, 2015 at 02:08:15AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint c...@passwd.hu --- Makefile | 1 + doc/ffplay.texi | 4 + ffplay.c | 336 +- --- libavfilter/Makefile | 1 + libavfilter/vf_ffplay_subtitle.c | 347 ++ + libavfilter/vf_ffplay_subtitle.h | 38 + 6 files changed, 434 insertions(+), 293 deletions(-) create mode 100644 libavfilter/vf_ffplay_subtitle.c create mode 100644 libavfilter/vf_ffplay_subtitle.h This is not the correct way of doing it. The proper way is to integrate subtitles within lavfi. If you want to work toward this, feel free to ask for more details, but it's not trivial. (and no, this patch is not an improvement in the correct direction, sorry) What would be an improvement in the right direction? I see little chance that I will work on subtitles in lavfi, but if there is a better/preferred way to change ffplay to support subtitles in the filter chain without waiting for the whole subtitles-in-libavfilter infrastructure, I may be interested in working toward that. Just random guess, but for now you could implement this filter in ffplay_sub_filter.c (or something) and register it from ffplay. So code of ffplay itself is cleaner and libavfilter is not spoiled. When this all suff Clement is talking about is done then it can be pushed further. I like this patch because some time ago I ported ffplay to ios and removing this code was annoying. API users can't add new filters from the outside. Isn't it allowed (and enough) to call avfilter_register with own filter? If not then I,m surprised TBH. No. While the register function is public, you'd need to use private APIs to actually implement the filter. yes and i really think we should do something about this IMHO API users should be able to define and register filters, codecs and formats [...] -- 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 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
On Tue, Mar 3, 2015 at 3:04 AM, Vilius Grigaliūnas vilius.grigaliu...@gmail.com wrote: On Tue, Mar 3, 2015 at 11:40 AM, Carl Eugen Hoyos ceho...@ag.or.at wrote: Doesn't this break rgb48 images? No, it does not break rgb48. They are not affected by this change. Due to the way libopenjpeg_matches_pix_fmt is implemented, rgb48 can match xyz12, but xyz12 can not match rgb48. So the order of formats matter, it should be in increasing depth. With the previous format order xyz12 was never checked, because rgb48 would have been incorrectly selected first. This line is the reason for this: 106: desc-comp[2].depth_minus1 + 1 = image-comps[2].prec Since 16 = 12, rgb48 matches and xyz12 is not even considered. I do not know, why = is used here instead of ==, but I do not want to change too much. = was used because some images can have a weird bit depth. For example, you can make a rgb image with 9 bits per component. ffmpeg doesn't support rgb27 (only rgb24/rgb48). So = was used so we can decode weird bit depths and stuff them into a frame without losing precision (so an rgb27 would get stuffed in an rgb48 frame). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] acvodec/lipopenjpeg: Improve XYZ color space detection
The reason for this change is that the native jpeg2000 decoder does not yet support 4K digital cinema files (#2586). The workaround for that is to use libopenjpeg decoder, which sort of works but incorrectly detects pixel format as rgb48le instead of xyz12le. This produces wrong colors in the output. This patch basically fixes the issue so that the correct output is produced when using libopenjpeg decoder. I should have included this in commit message. On Tue, Mar 3, 2015 at 12:49 AM, Michael Bradshaw mjbs...@gmail.com wrote: Is this really desirable, though? The most common case should be the default. If XYZ is the most common use case for ffmpeg/avcodec users, then sure, this is good. But I'm not convinced XYZ is more common than RGB. I believe RGB is more common than XYZ, and as such should remain the default. This only affects cases where openjpeg did not detect color space (CLRSPC_UNKNOWN) as it is most likely to be in XYZ. As far as I have figured out, openjpeg does not have proper detection for XYZ images, it decodes them all right, but the information coming from their API is just not there. When the image is in RGB, openjpeg should detect it as CLRSPC_SRGB and the behavior has not changed here. I have tested this with several files and the results were correct in all cases. This small cleanup/micro optimization is better in a different patch. It seems unrelated to testing XYZ before RGB. Same for the similar change to libopenjpeg_copyto16(). This is not an optimization, but a fix for a bug. It fixes the pixel value shift for xyz12le pixel format so that the values are properly aligned. It is not as much a detection issue, but the correct detection exposed it. I think there was no way to hit it before due to incorrect pixel format detection as rgb48le does not need bit shifts but xyz12le does. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
On Tue, Mar 3, 2015 at 1:19 AM, Vilius Grigaliūnas
vilius.grigaliu...@gmail.com wrote:
Input files in XYZ color space are incorrecly detected as RGB which results
in incorrect output colors.
This fixes pixel format detection order (in increasing bit depth to
match libopenjpeg_matches_pix_fmt) when color space provided by
libopenjepg is unknown.
---
libavcodec/libopenjpegdec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 1cd1b9b..489040e 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -77,7 +77,7 @@ static const enum AVPixelFormat
libopenjpeg_yuv_pix_fmts[] = {
YUV_PIXEL_FORMATS
};
static const enum AVPixelFormat libopenjpeg_all_pix_fmts[] = {
-RGB_PIXEL_FORMATS, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS,
XYZ_PIXEL_FORMATS
+AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA, XYZ_PIXEL_FORMATS,
AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS
That seems like the least intrusive fix, and the logic looks right to me. I
don't know if 8-bit per component XYZ will ever be supported in ffmpeg, but
if so then deciding between rgb24 and xyz8 will need a different method.
The mixing of AV_PIX_FMT_* enums and *_PIXEL_FORMATS macros looks
tedious/fragile.
I'd say the above patch is okay. Alternatively, something like the
following could be done, I think:
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 02b1ceb..da53e05 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -76,7 +76,23 @@ static const enum AVPixelFormat
libopenjpeg_gray_pix_fmts[] = {
static const enum AVPixelFormat libopenjpeg_yuv_pix_fmts[] = {
YUV_PIXEL_FORMATS
};
-static const enum AVPixelFormat libopenjpeg_all_pix_fmts[] = {
+// OpenJPEG currently doesn't support detecting xyz. If the file is
+// a JP2 file, then it should have the color space saved, and
+// OpenJPEG should be able to detect what it is. In the event that
+// the file is a JP2 and OpenJPEG can't detect what the color space
+// is, then we should try guessing xyz first, as that's the only
+// likely candidate (since OpenJPEG can detect gray/yuv/rgb, we can
+// effectively rule those out). If the file is a J2K codestream,
+// then the color format isn't known and must be guessed. In that
+// event, rgb should be guessed first, as it tends to be more
+// common. Hence, we have two arrays that prioritize search order
+// for pixel formats, based on the image type: for JP2 files,
+// libopenjpeg_jp2_all_pix_fmts; and for J2K files,
+// libopenjpeg_j2k_all_pix_fmts.
+static const enum AVPixelFormat libopenjpeg_jp2_all_pix_fmts[] = {
+XYZ_PIXEL_FORMATS, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS,
RGB_PIXEL_FORMATS
+};
+static const enum AVPixelFormat libopenjpeg_j2k_all_pix_fmts[] = {
RGB_PIXEL_FORMATS, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS,
XYZ_PIXEL_FORMATS
};
@@ -123,7 +139,7 @@ static inline int libopenjpeg_matches_pix_fmt(const
opj_image_t *image, enum AVP
return match;
}
-static inline enum AVPixelFormat libopenjpeg_guess_pix_fmt(const
opj_image_t *image) {
+static inline enum AVPixelFormat libopenjpeg_guess_pix_fmt(const
opj_image_t *image, int is_jp2) {
int index;
const enum AVPixelFormat *possible_fmts = NULL;
int possible_fmts_nb = 0;
@@ -142,8 +158,13 @@ static inline enum AVPixelFormat
libopenjpeg_guess_pix_fmt(const opj_image_t *im
possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_yuv_pix_fmts);
break;
default:
-possible_fmts= libopenjpeg_all_pix_fmts;
-possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_all_pix_fmts);
+if (is_jp2) {
+possible_fmts= libopenjpeg_jp2_all_pix_fmts;
+possible_fmts_nb =
FF_ARRAY_ELEMS(libopenjpeg_jp2_all_pix_fmts);
+} else {
+possible_fmts= libopenjpeg_j2k_all_pix_fmts;
+possible_fmts_nb =
FF_ARRAY_ELEMS(libopenjpeg_j2k_all_pix_fmts);
+}
break;
}
@@ -263,6 +284,7 @@ static int libopenjpeg_decode_frame(AVCodecContext
*avctx,
int width, height, ret;
int pixel_size = 0;
int ispacked = 0;
+int is_jp2;
int i;
*got_frame = 0;
@@ -272,12 +294,14 @@ static int libopenjpeg_decode_frame(AVCodecContext
*avctx,
(AV_RB32(buf + 4) == JP2_SIG_TYPE)
(AV_RB32(buf + 8) == JP2_SIG_VALUE)) {
dec = opj_create_decompress(CODEC_JP2);
+is_jp2 = 1;
} else {
/* If the AVPacket contains a jp2c box, then skip to
* the starting byte of the codestream. */
if (AV_RB32(buf + 4) == AV_RB32(jp2c))
buf += 8;
dec = opj_create_decompress(CODEC_J2K);
+is_jp2 = 0;
}
if (!dec) {
@@ -320,7 +344,7 @@ static int libopenjpeg_decode_frame(AVCodecContext
*avctx,
avctx-pix_fmt = AV_PIX_FMT_NONE;
if (avctx-pix_fmt == AV_PIX_FMT_NONE)
-
Re: [FFmpeg-devel] [PATCH 1/2] acvodec/lipopenjpeg: Fix pixel value shift for 12-bit pixel formats
On Tue, Mar 3, 2015 at 1:19 AM, Vilius Grigaliūnas
vilius.grigaliu...@gmail.com wrote:
This fixes pixel values not being properly shifted in
libopenjpeg_copyto16 and libopenjpeg_copy_to_packed16 methods.
Pixel formats like xyz12le need to be shifted by
AVComponentDescriptor::shift
to get the correct values.
---
libavcodec/libopenjpegdec.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 02b1ceb..1cd1b9b 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -184,10 +184,11 @@ static inline void
libopenjpeg_copy_to_packed8(AVFrame *picture, opj_image_t *im
static inline void libopenjpeg_copy_to_packed16(AVFrame *picture,
opj_image_t *image) {
uint16_t *img_ptr;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(picture-format);
int index, x, y, c;
int adjust[4];
for (x = 0; x image-numcomps; x++)
-adjust[x] =
FFMAX(FFMIN(av_pix_fmt_desc_get(picture-format)-comp[x].depth_minus1 + 1
- image-comps[x].prec, 8), 0);
+adjust[x] = FFMAX(FFMIN(desc-comp[x].depth_minus1 + 1 -
image-comps[x].prec, 8), 0) + desc-comp[x].shift;
for (y = 0; y picture-height; y++) {
index = y * picture-width;
@@ -220,10 +221,11 @@ static inline void libopenjpeg_copyto8(AVFrame
*picture, opj_image_t *image) {
static inline void libopenjpeg_copyto16(AVFrame *picture, opj_image_t
*image) {
int *comp_data;
uint16_t *img_ptr;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(picture-format);
int index, x, y;
int adjust[4];
for (x = 0; x image-numcomps; x++)
-adjust[x] =
FFMAX(FFMIN(av_pix_fmt_desc_get(picture-format)-comp[x].depth_minus1 + 1
- image-comps[x].prec, 8), 0);
+adjust[x] = FFMAX(FFMIN(desc-comp[x].depth_minus1 + 1 -
image-comps[x].prec, 8), 0) + desc-comp[x].shift;
for (index = 0; index image-numcomps; index++) {
comp_data = image-comps[index].data;
Overall, looks good to me. Maybe the + desc-comp[x].shift; part should
be moved inside the FFMIN macro? Seems okay as is, though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] acvodec/lipopenjpeg: Improve XYZ color space detection
On Tue, Mar 3, 2015 at 4:35 AM, Michael Bradshaw mjbs...@gmail.com wrote: You can use the -pix_fmt option to specify the pixel format of the source. The openjpeg decoder will try that pixel format first before iterating through its (prioritized) list of pixel formats. That should provide a way to work around this (until it's fixed). First thing I tried, did not work: Option pixel_format not found. On Tue, Mar 3, 2015 at 12:49 AM, Michael Bradshaw mjbs...@gmail.com That's a good point. The downside is that it breaks autodetecting RGB in J2K/JPC (which don't have the color space info stored in the file format). Perhaps XYZ should be tried first if the file is a JP2 file (since openjpeg should have detected if it was RGB otherwise, so we can assume it's not RGB), and RGB should be tried first if it's a J2K file (since RGB is more common). That way, autodetecting RGB in J2K is not broken, and detecting XYZ in JP2 should work. Thoughts from anyone on this? The problem with trying RGB before XYZ is that libopenjpeg_matches_pix_fmt matches rgb48le before xyz12le is even considered. But I see the problem with J2K files. Maybe I can improve libopenjpeg_guess_pix_fmt so it handles all cases correctly. Okay, but it should go in a separate patch. Also, instead of doing two shifts, just add desc-comp[index].shift to adjust[index] (before the big main loop) so only one shift is needed each iteration. OK, I will make this a separate patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4] libavformat/mxfenc: write package name metadata
---
libavformat/mxfenc.c | 88 +--
tests/ref/lavf/mxf| 6 ++--
tests/ref/lavf/mxf_d10| 2 +-
tests/ref/lavf/mxf_opatom | 2 +-
4 files changed, 82 insertions(+), 16 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7d35af4..d470ddc 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -624,14 +624,44 @@ static void mxf_write_preface(AVFormatContext *s)
}
/*
- * Write a local tag containing an ascii string as utf-16
+ * Returns the length of the UTF-16 string, in 16-bit characters, that would
result
+ * from decoding the utf-8 string.
+ */
+static uint64_t mxf_utf16len(const char *utf8_str)
+{
+const uint8_t *q = utf8_str;
+uint64_t size = 0;
+while (*q) {
+uint32_t ch;
+GET_UTF8(ch, *q++, goto invalid;)
+if (ch 0x1)
+size++;
+else
+size += 2;
+continue;
+invalid:
+av_log(NULL, AV_LOG_ERROR, Invaid UTF8 sequence in mxf_utf16len\n\n);
+}
+size += 1;
+return size;
+}
+
+/*
+ * Returns the calculated length a local tag containing an utf-8 string as
utf-16
+ */
+static uint64_t mxf_utf16_local_tag_length(const char *utf8_str)
+{
+return utf8_str? 4 + mxf_utf16len(utf8_str) * 2: 0;
+}
+
+/*
+ * Write a local tag containing an utf-8 string as utf-16
*/
static void mxf_write_local_tag_utf16(AVIOContext *pb, int tag, const char
*value)
{
-int i, size = strlen(value);
+int size = mxf_utf16len(value);
mxf_write_local_tag(pb, size*2, tag);
-for (i = 0; i size; i++)
-avio_wb16(pb, value[i]);
+avio_put_str16be(pb, value);
}
static void mxf_write_identification(AVFormatContext *s)
@@ -648,7 +678,9 @@ static void mxf_write_identification(AVFormatContext *s)
version = s-flags AVFMT_FLAG_BITEXACT ?
0.0.0 : AV_STRINGIFY(LIBAVFORMAT_VERSION);
-length = 84 + (strlen(company)+strlen(product)+strlen(version))*2; //
utf-16
+length = 72 + mxf_utf16_local_tag_length(company) +
+ mxf_utf16_local_tag_length(product) +
+ mxf_utf16_local_tag_length(version);
klv_encode_ber_length(pb, length);
// write uid
@@ -659,7 +691,6 @@ static void mxf_write_identification(AVFormatContext *s)
// write generation uid
mxf_write_local_tag(pb, 16, 0x3C09);
mxf_write_uuid(pb, Identification, 1);
-
mxf_write_local_tag_utf16(pb, 0x3C01, company); // Company Name
mxf_write_local_tag_utf16(pb, 0x3C02, product); // Product Name
mxf_write_local_tag_utf16(pb, 0x3C04, version); // Version String
@@ -1092,20 +1123,29 @@ static void
mxf_write_generic_sound_desc(AVFormatContext *s, AVStream *st)
mxf_write_generic_sound_common(s, st, mxf_generic_sound_descriptor_key, 0);
}
-static void mxf_write_package(AVFormatContext *s, enum MXFMetadataSetType type)
+static void mxf_write_package(AVFormatContext *s, enum MXFMetadataSetType
type, const char *package_name)
{
MXFContext *mxf = s-priv_data;
AVIOContext *pb = s-pb;
int i, track_count = s-nb_streams+1;
+uint64_t name_size = 0;
+
+if (package_name)
+name_size = mxf_utf16_local_tag_length(package_name);
+
+if (name_size = INT16_MAX){
+av_log(s, AV_LOG_WARNING, package name size %PRIx64 invalid (too
large), ignoring\n, name_size);
+name_size = 0;
+}
if (type == MaterialPackage) {
mxf_write_metadata_key(pb, 0x013600);
PRINT_KEY(s, Material Package key, pb-buf_ptr - 16);
-klv_encode_ber_length(pb, 92 + 16*track_count);
+klv_encode_ber_length(pb, 92 + name_size + (16*track_count));
} else {
mxf_write_metadata_key(pb, 0x013700);
PRINT_KEY(s, Source Package key, pb-buf_ptr - 16);
-klv_encode_ber_length(pb, 112 + 16*track_count); // 20 bytes length
for descriptor reference
+klv_encode_ber_length(pb, 112 + name_size + (16*track_count)); // 20
bytes length for descriptor reference
}
// write uid
@@ -1119,6 +1159,10 @@ static void mxf_write_package(AVFormatContext *s, enum
MXFMetadataSetType type)
mxf_write_umid(s, type == SourcePackage);
PRINT_KEY(s, package umid second part, pb-buf_ptr - 16);
+// package name
+if (name_size)
+mxf_write_local_tag_utf16(pb, 0x4402, package_name);
+
// package creation date
mxf_write_local_tag(pb, 8, 0x4405);
avio_wb64(pb, mxf-timestamp);
@@ -1187,11 +1231,33 @@ static int
mxf_write_essence_container_data(AVFormatContext *s)
static int mxf_write_header_metadata_sets(AVFormatContext *s)
{
+const char *material_package_name = NULL;
+const char *file_package_name = NULL;
+AVDictionaryEntry *entry = NULL;
+AVStream *st = NULL;
+int i;
+
+if (entry = av_dict_get(s-metadata, material_package_name, NULL, 0))
+ material_package_name = entry-value;
+
+if (entry = av_dict_get(s-metadata, file_package_name, NULL, 0)) {
Re: [FFmpeg-devel] [PATCH 1/2] acvodec/lipopenjpeg: Fix pixel value shift for 12-bit pixel formats
Overall, looks good to me. Maybe the + desc-comp[x].shift; part should be moved inside the FFMIN macro? Seems okay as is, though. I looked how it is implemented in jpeg200dec.c and there is no FFMIN there. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: write colr by default
On Tue, Mar 03, 2015 at 06:17:22PM +0100, Robert Krüger wrote: This is based on an earlier patch by Derek please mention this in the commit message that never went in because it was argumented earlier that api breakage is not acceptable. However, that was more or less relaxed after Michael noted that the replaced flag had never been part of a release and since a number of people seem to agree, this is the better default, I am submitting this patch now, to have it in before the upcoming release. Let me know if that will be accepted and I will modify the respective fate tests as well. have you tested the generated mov and mp4 files with some common software packages ? checking random files on my disk it seems more than half the mov files contain a colr atom but i found just a single mp4 with a colr atom, so especially testing the compatibility of the mp4 files would be optimal before this is changed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port FFT domain filter.
On Tue, Mar 03, 2015 at 10:50:09PM +0530, arwa arif wrote:
On Tue, Mar 3, 2015 at 6:11 PM, Michael Niedermayer michae...@gmx.at
wrote:
On Tue, Mar 03, 2015 at 12:06:09PM +0530, arwa arif wrote:
I tried to change the name to fft, but it is conflicting with
libavcodec/fft. So, I am unable to change that. I have updated the patch,
adding support to coloured images.
yes, the names could conflict in configure indeed
[...]
+
+#include libavfilter/internal.h
+#include libavutil/common.h
+#include libavutil/imgutils.h
+#include libavutil/opt.h
+#include libavutil/pixdesc.h
+#include libavcodec/avfft.h
+#include libavutil/eval.h
+
+typedef struct {
+const AVClass *class;
+
+RDFTContext *rdft;
+int rdft_hbits[3];
+int rdft_vbits[3];
+size_t rdft_hlen[3];
+size_t rdft_vlen[3];
+FFTSample *rdft_hdata[3];
+FFTSample *rdft_vdata[3];
+
+int dc;
+char *lum_str;
+AVExpr *lum_expr;
+double *lum_data;
+
+} FFTFILTContext;
+
+static const char *const var_names[] = { X, Y, W, H,
NULL};
+enum { VAR_X, VAR_Y, VAR_W, VAR_H,
VAR_VARS_NB };
+
+#define OFFSET(x) offsetof(FFTFILTContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption fftfilt_options[] = {
+{ dc, adjust gain, OFFSET(dc),
AV_OPT_TYPE_INT,{.i64 = 0}, 0, 1000, FLAGS },
+{ lum, set luminance expression, OFFSET(lum_str),
AV_OPT_TYPE_STRING, {.str = 1}, CHAR_MIN, CHAR_MAX, FLAGS },
+{NULL},
The user should be able to set seperate dc / lum for teh 3 planes
that is if only the first dc and first exression is set then they
should be used for all 3 planes
otherwise, if teh user set 3 dc values and 3 expressions then each
plane should use the specific expression
[...]
+
+memset(fftfilt-rdft_hdata[plane] + i *
fftfilt-rdft_hlen[plane], 0,
+ fftfilt-rdft_hlen[plane] *
sizeof(*fftfilt-rdft_hdata[plane]));
the memseting should ideally be replaced by mirroring, this leads
to better quality
for example
matrixbench_mpeg2.mpg -vf fftfilt=dc=128:lum='(1 / (1 +
exp(-(Y+X)/10.0+H/100.0)))'
results in a pink border due to this
that is instead of for each line
1 2 3 3 7 9 10 11 23
it should not be changed to:
1 2 3 3 7 9 10 11 23 0 0 0 0 0 0 0
but
1 2 3 3 7 9 10 11 23 23 11 10 x 3 2 1
But, we want to clear the block of memory. Why do we want to mirror it?
The idea is to clear it with the same data as is in the input picture
not with 0 bytes
so instead of
99900
99900
9..9..9..9900
99900
9.99.9900
9....9900
99900
99900
it is
9
9
9..9..9..
9
9.99.
9....
9
9
because when the image is filtered the additional outside padding
will affect the vissible area
consider:
9900 - 865100
vs
- 99
the vissible part is:
86
vs
99
or said differently the 0 padding gets smeared into the vissible
image, so the more similar it is to the input image the less artifacts
this creates
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] acvodec/lipopenjpeg: Improve XYZ color space detection
On Mon, Mar 2, 2015 at 11:56 PM, Vilius Grigaliūnas vilius.grigaliu...@gmail.com wrote: On Tue, Mar 3, 2015 at 4:35 AM, Michael Bradshaw mjbs...@gmail.com wrote: You can use the -pix_fmt option to specify the pixel format of the source. The openjpeg decoder will try that pixel format first before iterating through its (prioritized) list of pixel formats. That should provide a way to work around this (until it's fixed). First thing I tried, did not work: Option pixel_format not found. Dang, you're right. -pix_fmt only works for image files (that use the img2dec demuxer). The other demuxers don't support that option, despite the fact that the libopenjpeg decoder respects the requested pixel format. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: write colr by default
On Tue, Mar 03, 2015 at 09:24:17PM +0100, Robert Krüger wrote: On Tue, Mar 3, 2015 at 7:23 PM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Mar 03, 2015 at 06:17:22PM +0100, Robert Krüger wrote: This is based on an earlier patch by Derek please mention this in the commit message OK, I will change that that never went in because it was argumented earlier that api breakage is not acceptable. However, that was more or less relaxed after Michael noted that the replaced flag had never been part of a release and since a number of people seem to agree, this is the better default, I am submitting this patch now, to have it in before the upcoming release. Let me know if that will be accepted and I will modify the respective fate tests as well. have you tested the generated mov and mp4 files with some common software packages ? checking random files on my disk it seems more than half the mov files contain a colr atom but i found just a single mp4 with a colr atom, so especially testing the compatibility of the mp4 files would be optimal before this is changed OK, I will do some tests with VLC, Quicktime, Final Cut, Final Cut X, Premiere and After Effects and maybe something else I find. thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 10/12] mips: use float* to hold pointer instead of int
On Tue, Mar 03, 2015 at 12:44:01PM +, Nedeljko Babic wrote: LGTM applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 12/12] mips/aaccoder: use variables instead of using register names directly
On Tue, Mar 03, 2015 at 12:44:47PM +, Nedeljko Babic wrote: LGTM applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] GSOC2015
Hi all I am Krishna Gupta undergraduate Electronics and Communication student at IIIT hyd. I have gone through this year ideas and project from org's GSOC page and one project that interest me a lot is MPEG-4 ALS encoder. I have little bit of theoretical idea about this from my undergraduate study. I have done courses like Digital signal Processing, speech signals and done a fair amount of c,c++ coding. I want to explore about this project more, so if someone can guide me with initial steps. Thanks, Krishna Gupta ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
On Tue, Mar 03, 2015 at 10:19:48AM +0200, Vilius Grigaliūnas wrote: Input files in XYZ color space are incorrecly detected as RGB which results in incorrect output colors. This fixes pixel format detection order (in increasing bit depth to match libopenjpeg_matches_pix_fmt) when color space provided by libopenjepg is unknown. --- libavcodec/libopenjpegdec.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) this detects codestreams_profile0/p0_08.j2k as xyz, is this intended? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] Interpretation of duration field in AVI super index chunk
On Tue, Mar 03, 2015 at 02:45:24PM +0100, Tobias Rapp wrote: On 26.02.2015 15:41, Michael Niedermayer wrote: On Thu, Feb 26, 2015 at 02:14:33PM +0100, Tobias Rapp wrote: On 26.02.2015 00:51, Michael Niedermayer wrote: On Wed, Feb 25, 2015 at 05:35:33PM +0100, Tobias Rapp wrote: [...] @@ -511,7 +514,11 @@ static int avi_write_ix(AVFormatContext *s) avio_skip(pb, 16 * avi-riff_id); avio_wl64(pb, ix);/* qwOffset */ avio_wl32(pb, pos - ix); /* dwSize */ -avio_wl32(pb, avist-indexes.entry); /* dwDuration */ +ff_parse_specific_params(s-streams[i], au_byterate, au_ssize, au_scale); +if (au_ssize == 0) +avio_wl32(pb, avist-indexes.entry); /* dwDuration (packet count) */ +else +avio_wl32(pb, (avist-audio_strm_length - avist-indexes.audio_strm_offset) / au_ssize); /* dwDuration (sample count) */ the rounding here is wrong the index to be useable needs to have segments duration summable as is this would lead to significangt errors if many of these durations would be summed up something like avist-audio_strm_length / au_ssize - avist-indexes.audio_strm_offset / au_ssize might avoid that but ive not tested it My assumption was that a stream packet contains only whole samples for linear/uncompressed audio (PCM) and that only for linear audio the expression au_ssize 0 evaluates to TRUE. We try to use au_ssize = 0 for compressed audio but i think it can be non zero in some stream copy cases, iam not 100% sure though If that is not the case I can do the rounding as suggested or maybe introduce some separate stream duration counter based on AVPacket.duration? i think best to keep it simple and maybe print a request for a sample/ testcase if some combination of parameters is found which we are unsure about if it works correctly Attached a new patch that calls avpriv_request_sample if the audio segment size is no multiple of au_ssize. Tested different audio encoder types (pcm_s16le, pcm_s24le, adpcm_ms, mp2, libmp3lame) with success. Regards, Tobias avienc.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) 18613900301b05e351e2a1a5009e9f5801c20ffc 0001-libavformat-avienc-Fix-duration-of-audio-segment-in-.patch From 89d3f13169e2ff183a1e60c9939263035ad83a0f Mon Sep 17 00:00:00 2001 From: Tobias Rapp t.r...@noa-audio.com Date: Tue, 3 Mar 2015 13:29:05 +0100 Subject: [PATCH] libavformat/avienc: Fix duration of audio segment in OpenDML master index 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
Re: [FFmpeg-devel] [PATCH] ffplay: Switch to show waves mode if allocation/init of RDFT fails
On Mon, 2 Mar 2015, Michael Niedermayer wrote:
Fixes null pointer dereference
Found-by: Paweł pantrom...@gmail.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
ffplay.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/ffplay.c b/ffplay.c
index 8140dd9..94c7ed4 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -1247,7 +1247,10 @@ static void video_audio_display(VideoState *s)
s-rdft_bits = rdft_bits;
s-rdft_data = av_malloc_array(nb_freq, 4 *sizeof(*s-rdft_data));
}
-{
+if (!s-rdft || !s-rdft_data){
+av_log(NULL, AV_LOG_ERROR, Failed to allocate buffers for RDFT,
switching to waves display\n);
+s-show_mode = SHOW_MODE_WAVES;
+} else {
FFTSample *data[2];
for (ch = 0; ch nb_display_channels; ch++) {
data[ch] = s-rdft_data + 2 * nb_freq * ch;
--
1.7.9.5
LGTM, thanks.
Marton___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Post-processing filter Documentation
On Sat, Feb 7, 2015 at 6:23 AM, arwa arif arwaarif1...@gmail.com wrote: On Mon, Feb 2, 2015 at 10:23 AM, Michael Niedermayer michae...@gmx.at wrote: On Sat, Jan 31, 2015 at 02:30:29PM +0530, arwa arif wrote: On Thu, Jan 29, 2015 at 5:18 PM, Stefano Sabatini stefa...@gmail.com wrote: On date Thursday 2015-01-29 03:46:42 +0530, Arwa Arif encoded: I have updated the page with new images. http://trac.ffmpeg.org/wiki/Postprocessing I used this command to create the query image: ffmpeg -i matrixbench_mpeg2.mpg -b:v 200k matrixbench_mpeg2-lq.mpg The wiki page just says compressed to 200kbps, which is not nearly enough information. I was going to just update that in the wiki, but then ended up replacing a bunch of the earlier text. Before, it didn't even mention that modern codecs have built-in deblocking, and usually don't look better when you PP. Anyway, I rewrote a lot of stuff, and I think it's a lot more informative now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] acvodec/lipopenjpeg: Fix pixel value shift for 12-bit pixel formats
On Tue, Mar 03, 2015 at 12:54:43PM -0700, Michael Bradshaw wrote:
On Tue, Mar 3, 2015 at 1:19 AM, Vilius Grigaliūnas
vilius.grigaliu...@gmail.com wrote:
This fixes pixel values not being properly shifted in
libopenjpeg_copyto16 and libopenjpeg_copy_to_packed16 methods.
Pixel formats like xyz12le need to be shifted by
AVComponentDescriptor::shift
to get the correct values.
---
libavcodec/libopenjpegdec.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 02b1ceb..1cd1b9b 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -184,10 +184,11 @@ static inline void
libopenjpeg_copy_to_packed8(AVFrame *picture, opj_image_t *im
static inline void libopenjpeg_copy_to_packed16(AVFrame *picture,
opj_image_t *image) {
uint16_t *img_ptr;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(picture-format);
int index, x, y, c;
int adjust[4];
for (x = 0; x image-numcomps; x++)
-adjust[x] =
FFMAX(FFMIN(av_pix_fmt_desc_get(picture-format)-comp[x].depth_minus1 + 1
- image-comps[x].prec, 8), 0);
+adjust[x] = FFMAX(FFMIN(desc-comp[x].depth_minus1 + 1 -
image-comps[x].prec, 8), 0) + desc-comp[x].shift;
for (y = 0; y picture-height; y++) {
index = y * picture-width;
@@ -220,10 +221,11 @@ static inline void libopenjpeg_copyto8(AVFrame
*picture, opj_image_t *image) {
static inline void libopenjpeg_copyto16(AVFrame *picture, opj_image_t
*image) {
int *comp_data;
uint16_t *img_ptr;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(picture-format);
int index, x, y;
int adjust[4];
for (x = 0; x image-numcomps; x++)
-adjust[x] =
FFMAX(FFMIN(av_pix_fmt_desc_get(picture-format)-comp[x].depth_minus1 + 1
- image-comps[x].prec, 8), 0);
+adjust[x] = FFMAX(FFMIN(desc-comp[x].depth_minus1 + 1 -
image-comps[x].prec, 8), 0) + desc-comp[x].shift;
for (index = 0; index image-numcomps; index++) {
comp_data = image-comps[index].data;
Overall, looks good to me. Maybe the + desc-comp[x].shift; part should
be moved inside the FFMIN macro?
Seems okay as is, though.
applied
hopefully the intended thing, its a bit hard to follow this thread ;)
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/index: add News entry for GSoC 2015
--- src/index |8 1 file changed, 8 insertions(+) diff --git a/src/index b/src/index index bb60413..27cdbe5 100644 --- a/src/index +++ b/src/index @@ -36,6 +36,14 @@ News /h1 + a id=gsoc2015/ah3March 4, 2015, Google Summer of Code/h3 + p +FFmpeg has been accepted as a Google Summer of Code Project. If you wish to +participate as a student see our a href=https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015;project ideas page/a. +You can already get in contact with mentors and start working on qualification tasks. Registration +at google for students will open March 16th. Good luck! + /p + a id=clt2015/ah3March 1, 2015, Chemnitzer Linux-Tage/h3 p We happily announce that FFmpeg will be represented at Chemnitzer Linux-Tage -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add News entry for GSoC 2015
On Wed, 4 Mar 2015 01:03:05 +0100, Michael Niedermayer wrote: --- src/index |8 1 file changed, 8 insertions(+) LGTM. Some unimportant suggestions below. + a id=gsoc2015/ah3March 4, 2015, Google Summer of Code/h3 + p +FFmpeg has been accepted as a Google Summer of Code Project. If you wish to Maybe link Google Summer of Code to: http://www.google-melange.com/gsoc/homepage/google/gsoc2015 +participate as a student see our a href=https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015;project ideas page/a. +You can already get in contact with mentors and start working on qualification tasks. Registration +at google for students will open March 16th. Good luck! The at google seems superfluous. Or just capitalize Google if you want to keep it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: Switch to show waves mode if allocation/init of RDFT fails
On Wed, Mar 04, 2015 at 01:35:10AM +0100, Marton Balint wrote:
On Mon, 2 Mar 2015, Michael Niedermayer wrote:
Fixes null pointer dereference
Found-by: Paweł pantrom...@gmail.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
ffplay.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/ffplay.c b/ffplay.c
index 8140dd9..94c7ed4 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -1247,7 +1247,10 @@ static void video_audio_display(VideoState *s)
s-rdft_bits = rdft_bits;
s-rdft_data = av_malloc_array(nb_freq, 4
*sizeof(*s-rdft_data));
}
-{
+if (!s-rdft || !s-rdft_data){
+av_log(NULL, AV_LOG_ERROR, Failed to allocate buffers for
RDFT, switching to waves display\n);
+s-show_mode = SHOW_MODE_WAVES;
+} else {
FFTSample *data[2];
for (ch = 0; ch nb_display_channels; ch++) {
data[ch] = s-rdft_data + 2 * nb_freq * ch;
--
1.7.9.5
LGTM, thanks.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patch review: av_dict: add support for empty values
I've made some patches, and am finally getting around to sending them upstream. I'm trying out gmail for dealing with a high-traffic list like this one, instead of my usual mutt. Are the one-line-paragraph long lines it's probably going to produce an annoyance for anyone? I didn't notice anything about line lengths in emails in https://www.ffmpeg.org/developer.html I put in pull requests on github for 4 different branches. Should I send email to the list for each set of patches? Should I git-send-email, or is a mail with a URL for the github pull request enough? (Or is just a pull request enough? developer.html seems to say that sending a pull request is an alternative to mailing patches to the list.) Anyway, the av_dict change is the one that requires the most review, so I'll make this email focus on that set of changes. https://github.com/FFmpeg/FFmpeg/pull/118 Currently, -x264-params nocabac:ref=4:ssim isn't supported. You have to say nocabac=1:ref=4:ssim=1 (or cabac=0...). (and yes, I know about -preset, but superfast no-cabac is useful... anyway.) Also, libx265.c is very minimal, and needs a lot of things passed in -x265-params. I didn't fix that, but did make it support keys with no value. libx264 has two different ways of passing option strings (-x264-params and -x264opts), due to avconv gratuitously renaming things. The insane part is that the two strings were parsed differently. One was handled by av_dict, the other with some custom code that didn't support quoting. In my x26x-opts branch (which follows the av_dict branch), I add both option strings to the same av_dict. (x264opts and then x264-params, in that order, regardless of order on the command line, same as before). I don't think it's ever useful to use the same key multiple times. Tune only works as -tune ssim, not in x264-params, and you can use a comma-separated list for -tune animation,ssim. There was a previous attempt at keys with no value that didn't get merged: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-July/146329.html I should borrow the idea of adding a new flag for supporting NULL as a value, instead of the cumbersome empty-string method I went with to minimize changes to some parts of the code. Having a flag would make sure the behaviour didn't change for any callers that weren't expecting it. (i.e. it would still reject key:key). So are any of these changes useful? I assume I'll end up redoing the commits anyway after a review, so I didn't try to make a final ready-for-commit version yet. (For that, I would merge the bugfix changes into my original buggy commit.) For review, I'd suggest looking at the diff of master:av_dict. The 3 commits after that changing libx264.c and libx265.c should each stand on their own. (And actually the libx264.c one should be split into a couple commits.) Anyway, I wanted to post first and get some feedback before spending more time on it. Thanks, -- Peter Cordes pe...@cordes.ca ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add News entry for GSoC 2015
On Tue, Mar 03, 2015 at 03:17:04PM -0900, Lou Logan wrote: On Wed, 4 Mar 2015 01:03:05 +0100, Michael Niedermayer wrote: --- src/index |8 1 file changed, 8 insertions(+) LGTM. Some unimportant suggestions below. + a id=gsoc2015/ah3March 4, 2015, Google Summer of Code/h3 + p +FFmpeg has been accepted as a Google Summer of Code Project. If you wish to Maybe link Google Summer of Code to: http://www.google-melange.com/gsoc/homepage/google/gsoc2015 changed +participate as a student see our a href=https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015;project ideas page/a. +You can already get in contact with mentors and start working on qualification tasks. Registration +at google for students will open March 16th. Good luck! The at google seems superfluous. Or just capitalize Google if you want to keep it. capitalized applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC Decoder - fixed point implementation
Hi, On Fri, Nov 7, 2014 at 12:08 PM, Nedeljko Babic nedeljko.ba...@imgtec.com wrote: Hello, I am resending patch set with the implementation of fixed point AAC decoder. Our implementation of float emulation integrated in softfloat as requested. Patche set rebased to the newest code since there were some changes that conflicted with previous implementation. Patch with fate tests for aac fixed decoder added. Please have a look. Hi These patches need rebasing. If you post rebased patches I'll be happy to take a look. I tried applying them but got too many failures. Yes, this patches are few months old and I didn't work on this in the mintime. I'll do a rebase now and resubmit new patches for evaluation. Also, can you confirm that these patches are meant to apply on top of b1c99f4c5f8f3dc07264cf8011a9635cd3321cc6 ? I will do some automated tests on the patchset to evaluate their impact and I wouldn't want to be testing on the wrong commit. The last HEAD that I worked on was 79e0255956bc8fcdb143f39b2e45db77144ac017, so the patches should be applicable on top of b1c99f4c5f8f3dc07264cf8011a9635cd3321cc6 Thanks, Nedeljko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] ffplay: factorize subtitle rendering code to a private filter
On 3 March 2015 at 14:16, wm4 nfx...@googlemail.com wrote: On Tue, 3 Mar 2015 13:17:12 +0100 Lukasz Marek lukasz.m.lu...@gmail.com wrote: On 17 February 2015 at 03:27, Marton Balint c...@passwd.hu wrote: On Sat, 14 Feb 2015, Clément Bœsch wrote: On Sat, Feb 14, 2015 at 02:08:15AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint c...@passwd.hu --- Makefile | 1 + doc/ffplay.texi | 4 + ffplay.c | 336 +- --- libavfilter/Makefile | 1 + libavfilter/vf_ffplay_subtitle.c | 347 ++ + libavfilter/vf_ffplay_subtitle.h | 38 + 6 files changed, 434 insertions(+), 293 deletions(-) create mode 100644 libavfilter/vf_ffplay_subtitle.c create mode 100644 libavfilter/vf_ffplay_subtitle.h This is not the correct way of doing it. The proper way is to integrate subtitles within lavfi. If you want to work toward this, feel free to ask for more details, but it's not trivial. (and no, this patch is not an improvement in the correct direction, sorry) What would be an improvement in the right direction? I see little chance that I will work on subtitles in lavfi, but if there is a better/preferred way to change ffplay to support subtitles in the filter chain without waiting for the whole subtitles-in-libavfilter infrastructure, I may be interested in working toward that. Just random guess, but for now you could implement this filter in ffplay_sub_filter.c (or something) and register it from ffplay. So code of ffplay itself is cleaner and libavfilter is not spoiled. When this all suff Clement is talking about is done then it can be pushed further. I like this patch because some time ago I ported ffplay to ios and removing this code was annoying. API users can't add new filters from the outside. Isn't it allowed (and enough) to call avfilter_register with own filter? If not then I,m surprised TBH. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC Decoder - fixed point implementation
On Tue, Mar 3, 2015 at 10:58 AM, Nedeljko Babic nedeljko.ba...@imgtec.com wrote: On Fri, Nov 7, 2014 at 12:08 PM, Nedeljko Babic nedeljko.ba...@imgtec.com wrote: Hello, I am resending patch set with the implementation of fixed point AAC decoder. Our implementation of float emulation integrated in softfloat as requested. Patche set rebased to the newest code since there were some changes that conflicted with previous implementation. Patch with fate tests for aac fixed decoder added. Please have a look. Hi These patches need rebasing. If you post rebased patches I'll be happy to take a look. I tried applying them but got too many failures. Yes, this patches are few months old and I didn't work on this in the mintime. I'll do a rebase now and resubmit new patches for evaluation. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
On Tue, Mar 3, 2015 at 11:40 AM, Carl Eugen Hoyos ceho...@ag.or.at wrote: Doesn't this break rgb48 images? No, it does not break rgb48. They are not affected by this change. Due to the way libopenjpeg_matches_pix_fmt is implemented, rgb48 can match xyz12, but xyz12 can not match rgb48. So the order of formats matter, it should be in increasing depth. With the previous format order xyz12 was never checked, because rgb48 would have been incorrectly selected first. This line is the reason for this: 106: desc-comp[2].depth_minus1 + 1 = image-comps[2].prec Since 16 = 12, rgb48 matches and xyz12 is not even considered. I do not know, why = is used here instead of ==, but I do not want to change too much. Could you explain how I can reproduce your issue? There is a sample in https://trac.ffmpeg.org/ticket/2586 but it is black, so you wold not see the issue visually. But any digital cinema file would do, like the ones produced by OpenDCP or DCP-o-matic. The command line to reproduce is: ffmpeg -c:v libopenjpeg -i fdfcde74_excerpt_00-23.mxf Unpached ffmpeg displays pixel format as rgb48le, should be xyz12le. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
Vilius Grigaliūnas vilius.grigaliunas at gmail.com writes:
static const enum AVPixelFormat libopenjpeg_all_pix_fmts[] = {
-RGB_PIXEL_FORMATS, GRAY_PIXEL_FORMATS,
YUV_PIXEL_FORMATS, XYZ_PIXEL_FORMATS
+AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA, XYZ_PIXEL_FORMATS,
AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64,
GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS
Why don't you just move XYZ_PIXEL_FORMATS in front
of the list?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
On Tue, Mar 3, 2015 at 2:05 PM, Carl Eugen Hoyos ceho...@ag.or.at wrote: Why don't you just move XYZ_PIXEL_FORMATS in front of the list? Then the rgb24/rgba would not be detected correctly. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] ffplay: factorize subtitle rendering code to a private filter
On 17 February 2015 at 03:27, Marton Balint c...@passwd.hu wrote: On Sat, 14 Feb 2015, Clément Bœsch wrote: On Sat, Feb 14, 2015 at 02:08:15AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint c...@passwd.hu --- Makefile | 1 + doc/ffplay.texi | 4 + ffplay.c | 336 +- --- libavfilter/Makefile | 1 + libavfilter/vf_ffplay_subtitle.c | 347 ++ + libavfilter/vf_ffplay_subtitle.h | 38 + 6 files changed, 434 insertions(+), 293 deletions(-) create mode 100644 libavfilter/vf_ffplay_subtitle.c create mode 100644 libavfilter/vf_ffplay_subtitle.h This is not the correct way of doing it. The proper way is to integrate subtitles within lavfi. If you want to work toward this, feel free to ask for more details, but it's not trivial. (and no, this patch is not an improvement in the correct direction, sorry) What would be an improvement in the right direction? I see little chance that I will work on subtitles in lavfi, but if there is a better/preferred way to change ffplay to support subtitles in the filter chain without waiting for the whole subtitles-in-libavfilter infrastructure, I may be interested in working toward that. Just random guess, but for now you could implement this filter in ffplay_sub_filter.c (or something) and register it from ffplay. So code of ffplay itself is cleaner and libavfilter is not spoiled. When this all suff Clement is talking about is done then it can be pushed further. I like this patch because some time ago I ported ffplay to ios and removing this code was annoying. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/rv10: check size of s-mb_width * s-mb_height
On Mon, Mar 02, 2015 at 08:32:23PM +0100, Andreas Cadhalpun wrote: On 02.03.2015 19:37, Michael Niedermayer wrote: On Mon, Mar 02, 2015 at 07:18:10PM +0100, Andreas Cadhalpun wrote: So would you prefer using avpriv_report_missing_feature, returning an error and checking the return value in libavcodec/mpegvideo_enc.c? if you dont have easy access to the real networks binary decoder and noone else can check it either then failing with avpriv_report_missing_feature, might be safer OK, attached is a patch for this. Best regards, Andreas mpegvideo.h |2 +- mpegvideo_enc.c |7 +-- rv10enc.c |7 ++- 3 files changed, 12 insertions(+), 4 deletions(-) 1b5198d3bc1c5fca0241924ae60abe64c040bdaf 0001-avcodec-rv10-check-size-of-s-mb_width-s-mb_height.patch From 6fcb28f8c94b34d7169d3710f0cc3aef2b634b3b Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun andreas.cadhal...@googlemail.com Date: Mon, 2 Mar 2015 20:27:26 +0100 Subject: [PATCH] avcodec/rv10: check size of s-mb_width * s-mb_height If it doesn't fit into 12 bits it triggers an assertion. applied btw, it seems the real player (on linux) does not play these old files, not even files which originated from reals own encoder long ago also i suspect that more than 4096 MBs would break the 64k limit as well in reality so fixing this requires more things thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] acvodec/lipopenjpeg: Fix pixel value shift for 12-bit pixel formats
On Tue, Mar 3, 2015 at 10:19 AM, Vilius Grigaliūnas vilius.grigaliu...@gmail.com wrote: This fixes pixel values not being properly shifted in libopenjpeg_copyto16 and libopenjpeg_copy_to_packed16 methods. Pixel formats like xyz12le need to be shifted by AVComponentDescriptor::shift to get the correct values. The first patches had broken formatting, these last two are the good ones. As far as I have tested, this resolves all issues with XYZ color support in libopenjpeg decoder. RGB images should work as they did before without any regressions. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection
Vilius Grigaliūnas vilius.grigaliunas at gmail.com writes: Input files in XYZ color space are incorrecly detected as RGB which results in incorrect output colors. Doesn't this break rgb48 images? Could you explain how I can reproduce your issue? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
