Re: [FFmpeg-devel] [PATCH] swscale/output: Altivec-optimize float yuv2plane1
On Sun, 16 Dec 2018 00:22:00 +0100
Michael Niedermayer wrote:
> On Sat, Dec 15, 2018 at 06:32:31PM +0200, Lauri Kasanen wrote:
> > Tested on POWER8 LE. Testing on earlier ppc and/or BE appreciated.
> >
> > libswscale/ppc/swscale_altivec.c | 139
> > ++-
> > 1 file changed, 137 insertions(+), 2 deletions(-)
>
> breaks build:
> src/libswscale/ppc/swscale_altivec.c: In function ‘yuv2plane1_float_altivec’:
> src/libswscale/ppc/swscale_altivec.c:158:80: error: expected declaration
> specifiers or ‘...’ before ‘(’ token
> const vector float vzero = (vector float) {0, 0, 0, 0};
Thanks for testing. I missed the vzero define at the top, I wonder why
my gcc did not break. Patch v2 coming.
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize float yuv2plane1
This function wouldn't benefit from VSX instructions, so I put it
under altivec.
./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt grayf32le
\
-f null -vframes 100 -v error -nostats -
3743 UNITS in planar1, 65495 runs, 41 skips
-cpuflags 0
23511 UNITS in planar1, 65530 runs, 6 skips
grayf32be
4647 UNITS in planar1, 65449 runs, 87 skips
-cpuflags 0
28608 UNITS in planar1, 65530 runs, 6 skips
The native speedup is 6.28133, and the bswapping one 6.15623.
Fate passes, each format tested with an image to video conversion.
Signed-off-by: Lauri Kasanen
---
Tested on POWER8 LE. Testing on earlier ppc and/or BE appreciated.
v2: Added #undef vzero, that define broke the build on older gcc. Thanks Michael
libswscale/ppc/swscale_altivec.c | 141 ++-
1 file changed, 139 insertions(+), 2 deletions(-)
diff --git a/libswscale/ppc/swscale_altivec.c b/libswscale/ppc/swscale_altivec.c
index 1d2b2fa..d72ed1e 100644
--- a/libswscale/ppc/swscale_altivec.c
+++ b/libswscale/ppc/swscale_altivec.c
@@ -31,7 +31,8 @@
#include "yuv2rgb_altivec.h"
#include "libavutil/ppc/util_altivec.h"
-#if HAVE_ALTIVEC && HAVE_BIGENDIAN
+#if HAVE_ALTIVEC
+#if HAVE_BIGENDIAN
#define vzero vec_splat_s32(0)
#define GET_LS(a,b,c,s) {\
@@ -102,7 +103,137 @@
#include "swscale_ppc_template.c"
#undef FUNC
-#endif /* HAVE_ALTIVEC && HAVE_BIGENDIAN */
+#undef vzero
+
+#endif /* HAVE_BIGENDIAN */
+
+#define output_pixel(pos, val, bias, signedness) \
+if (big_endian) { \
+AV_WB16(pos, bias + av_clip_ ## signedness ## 16(val >> shift)); \
+} else { \
+AV_WL16(pos, bias + av_clip_ ## signedness ## 16(val >> shift)); \
+}
+
+static void
+yuv2plane1_float_u(const int32_t *src, float *dest, int dstW, int start)
+{
+static const int big_endian = HAVE_BIGENDIAN;
+static const int shift = 3;
+static const float float_mult = 1.0f / 65535.0f;
+int i, val;
+uint16_t val_uint;
+
+for (i = start; i < dstW; ++i){
+val = src[i] + (1 << (shift - 1));
+output_pixel(&val_uint, val, 0, uint);
+dest[i] = float_mult * (float)val_uint;
+}
+}
+
+static void
+yuv2plane1_float_bswap_u(const int32_t *src, uint32_t *dest, int dstW, int
start)
+{
+static const int big_endian = HAVE_BIGENDIAN;
+static const int shift = 3;
+static const float float_mult = 1.0f / 65535.0f;
+int i, val;
+uint16_t val_uint;
+
+for (i = start; i < dstW; ++i){
+val = src[i] + (1 << (shift - 1));
+output_pixel(&val_uint, val, 0, uint);
+dest[i] = av_bswap32(av_float2int(float_mult * (float)val_uint));
+}
+}
+
+static void yuv2plane1_float_altivec(const int32_t *src, float *dest, int dstW)
+{
+const int dst_u = -(uintptr_t)dest & 3;
+const int shift = 3;
+const int add = (1 << (shift - 1));
+const int clip = (1 << 16) - 1;
+const float fmult = 1.0f / 65535.0f;
+const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
+const vector uint32_t vshift = (vector uint32_t) vec_splat_u32(shift);
+const vector uint32_t vlargest = (vector uint32_t) {clip, clip, clip,
clip};
+const vector float vmul = (vector float) {fmult, fmult, fmult, fmult};
+const vector float vzero = (vector float) {0, 0, 0, 0};
+vector uint32_t v;
+vector float vd;
+int i;
+
+yuv2plane1_float_u(src, dest, dst_u, 0);
+
+for (i = dst_u; i < dstW - 3; i += 4) {
+v = vec_ld(0, (const uint32_t *) &src[i]);
+v = vec_add(v, vadd);
+v = vec_sr(v, vshift);
+v = vec_min(v, vlargest);
+
+vd = vec_ctf(v, 0);
+vd = vec_madd(vd, vmul, vzero);
+
+vec_st(vd, 0, &dest[i]);
+}
+
+yuv2plane1_float_u(src, dest, dstW, i);
+}
+
+static void yuv2plane1_float_bswap_altivec(const int32_t *src, uint32_t *dest,
int dstW)
+{
+const int dst_u = -(uintptr_t)dest & 3;
+const int shift = 3;
+const int add = (1 << (shift - 1));
+const int clip = (1 << 16) - 1;
+const float fmult = 1.0f / 65535.0f;
+const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
+const vector uint32_t vshift = (vector uint32_t) vec_splat_u32(shift);
+const vector uint32_t vlargest = (vector uint32_t) {clip, clip, clip,
clip};
+const vector float vmul = (vector float) {fmult, fmult, fmult, fmult};
+const vector float vzero = (vector float) {0, 0, 0, 0};
+const vector uint32_t vswapbig = (vector uint32_t) {16, 16, 16, 16};
+const vector uint16_t vswapsmall = vec_splat_u16(8);
+vector uint32_t v;
+vector float vd;
+int i;
+
+yuv2plane1_float_bswap_u(src, dest, dst_u, 0);
+
+for (i = dst_u; i < dstW - 3; i += 4) {
+v = vec_ld(0, (const uint32_t *) &src[i]);
+v = vec_add(v, vadd);
+v = vec_sr(v, vshift);
+v = vec_min(v, vlargest);
+
+vd = vec_ctf(v, 0);
+vd = vec_madd(vd, vmul, vzero);
+
+vd = (vector fl
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/rasc: Check that the number of moves is less than or equal the number of pixels
On Sat, Dec 15, 2018 at 09:31:21AM +0100, Paul B Mahol wrote: > On 12/15/18, Michael Niedermayer wrote: > > Fixes: OOM > > Fixes: > > 10307/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RASC_fuzzer-5393974559244288 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/rasc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/rasc.c b/libavcodec/rasc.c > > index 67351dfd19..1b607ac31e 100644 > > --- a/libavcodec/rasc.c > > +++ b/libavcodec/rasc.c > > @@ -215,7 +215,7 @@ static int decode_move(AVCodecContext *avctx, > > bytestream2_skip(gb, 8); > > compression = bytestream2_get_le32(gb); > > > > -if (nb_moves > INT32_MAX / 16) > > +if (nb_moves > INT32_MAX / 16 || nb_moves > avctx->width * > > avctx->height) > > return AVERROR_INVALIDDATA; > > > > uncompressed_size = 16 * nb_moves; > > -- > > 2.19.2 > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > OK will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp7: Check for end of input in vp78_decode_mv_mb_modes()
On Sat, Dec 15, 2018 at 01:21:52PM +1100, Peter Ross wrote:
> On Sat, Dec 15, 2018 at 02:44:43AM +0100, Michael Niedermayer wrote:
> > Fixes: Timeout
> > Fixes:
> > 10313/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP7_fuzzer-5637719389110272
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/vp8.c | 21 ++---
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> > index a06692c476..ba79e5fdab 100644
> > --- a/libavcodec/vp8.c
> > +++ b/libavcodec/vp8.c
> > @@ -2268,7 +2268,7 @@ void filter_mb_simple(VP8Context *s, uint8_t *dst,
> > VP8FilterStrength *f,
> >
> > #define MARGIN (16 << 2)
> > static av_always_inline
> > -void vp78_decode_mv_mb_modes(AVCodecContext *avctx, VP8Frame *curframe,
> > +int vp78_decode_mv_mb_modes(AVCodecContext *avctx, VP8Frame *curframe,
> > VP8Frame *prev_frame, int is_vp7)
> > {
> > VP8Context *s = avctx->priv_data;
> > @@ -2285,6 +2285,10 @@ void vp78_decode_mv_mb_modes(AVCodecContext *avctx,
> > VP8Frame *curframe,
> >
> > s->mv_bounds.mv_min.x = -MARGIN;
> > s->mv_bounds.mv_max.x = ((s->mb_width - 1) << 6) + MARGIN;
> > +
> > +if (vpX_rac_is_end(&s->c)) {
> > +return AVERROR_INVALIDDATA;
> > +}
> > for (mb_x = 0; mb_x < s->mb_width; mb_x++, mb_xy++, mb++) {
>
> ok.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/nutenc: Document trailer index assert better
On Fri, Dec 14, 2018 at 09:59:25PM +0100, Paul B Mahol wrote:
> On 12/14/18, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/nutenc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> > index a92ff55c01..e9a3bb49db 100644
> > --- a/libavformat/nutenc.c
> > +++ b/libavformat/nutenc.c
> > @@ -1172,7 +1172,7 @@ static int nut_write_trailer(AVFormatContext *s)
> >
> > ret = avio_open_dyn_buf(&dyn_bc);
> > if (ret >= 0 && nut->sp_count) {
> > -av_assert1(nut->write_index);
> > +av_assert1(nut->write_index); // sp_count should be 0 if no index
> > is going to be written
> > write_index(nut, dyn_bc);
> > put_packet(nut, bc, dyn_bc, 1, INDEX_STARTCODE);
> > }
> > --
> > 2.19.2
>
> Yea, figured it later, patch is fine.
will apply
[...]
--
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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: ensure only one tkhd per trak
On Sat, Dec 15, 2018 at 11:48:27AM -0800, Baptiste Coudurier wrote: > Hi Chris, > > > On Dec 14, 2018, at 3:12 PM, Chris Cunningham > > wrote: > > > >> > >> from a quick look, i did not find a file this breaks > >> > > > > Woot. Baptiste, I'm happy with this last patch if you are. > > Yes, looks great. ok, will apply thx > > Thanks a lot! > > — > Baptiste Coudurier > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/fft_template: reindent after the previous commit
Signed-off-by: Steven Liu
---
libavcodec/fft_template.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
index 2d97534505..657f07b487 100644
--- a/libavcodec/fft_template.c
+++ b/libavcodec/fft_template.c
@@ -262,25 +262,25 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int
inverse)
fft_perm_avx(s);
} else {
if (s->revtab) {
-for(i=0; ifft_permutation == FF_FFT_PERM_SWAP_LSBS)
-j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
-k = -split_radix_permutation(i, n, s->inverse) & (n-1);
+for(i=0; ifft_permutation == FF_FFT_PERM_SWAP_LSBS)
+j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
+k = -split_radix_permutation(i, n, s->inverse) & (n-1);
s->revtab[k] = j;
+}
}
-}
-if (s->revtab32) {
-for(i=0; ifft_permutation == FF_FFT_PERM_SWAP_LSBS)
-j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
-k = -split_radix_permutation(i, n, s->inverse) & (n-1);
+if (s->revtab32) {
+for(i=0; ifft_permutation == FF_FFT_PERM_SWAP_LSBS)
+j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
+k = -split_radix_permutation(i, n, s->inverse) & (n-1);
s->revtab32[k] = j;
}
-}
+}
}
return 0;
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/fft_template: improve performance of the ff_fft_init in fft_template
move the two if condition out of the loop, that can less n-1 times than
condition
in loop.
Signed-off-by: Steven Liu
---
libavcodec/fft_template.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
index 762c014bc8..2d97534505 100644
--- a/libavcodec/fft_template.c
+++ b/libavcodec/fft_template.c
@@ -261,17 +261,26 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int
inverse)
if (s->fft_permutation == FF_FFT_PERM_AVX) {
fft_perm_avx(s);
} else {
+if (s->revtab) {
for(i=0; ifft_permutation == FF_FFT_PERM_SWAP_LSBS)
j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
k = -split_radix_permutation(i, n, s->inverse) & (n-1);
-if (s->revtab)
s->revtab[k] = j;
-if (s->revtab32)
-s->revtab32[k] = j;
}
+}
+if (s->revtab32) {
+for(i=0; ifft_permutation == FF_FFT_PERM_SWAP_LSBS)
+j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
+k = -split_radix_permutation(i, n, s->inverse) & (n-1);
+s->revtab32[k] = j;
+}
+}
}
return 0;
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/fft_template: improve performance of the ff_fft_init in fft_template
On Sun, Dec 16, 2018 at 21:19:17 +0800, Steven Liu wrote:
> move the two if condition out of the loop, that can less n-1 times than
> condition
> in loop.
[...]
> k = -split_radix_permutation(i, n, s->inverse) & (n-1);
> -if (s->revtab)
> s->revtab[k] = j;
> -if (s->revtab32)
> -s->revtab32[k] = j;
> }
Does this really improve performance? You only save one if-check per
loop (as only one of s->revtab and s->revtab32 is defined). Benchmarks?
> +if (s->revtab32) {
> +for(i=0; i +int k;
> +j = i;
> +if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)
> +j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
> +k = -split_radix_permutation(i, n, s->inverse) &
> (n-1);
> +s->revtab32[k] = j;
> +}
> +}
On the other hand, all the code is duplicated. Is there a more elegant
way to do this?
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/fft_template: improve performance of the ff_fft_init in fft_template
> On Dec 16, 2018, at 21:47, Moritz Barsnick wrote:
>
> On Sun, Dec 16, 2018 at 21:19:17 +0800, Steven Liu wrote:
>> move the two if condition out of the loop, that can less n-1 times than
>> condition
>> in loop.
> [...]
>> k = -split_radix_permutation(i, n, s->inverse) & (n-1);
>> -if (s->revtab)
>> s->revtab[k] = j;
>> -if (s->revtab32)
>> -s->revtab32[k] = j;
>> }
>
> Does this really improve performance? You only save one if-check per
> loop (as only one of s->revtab and s->revtab32 is defined). Benchmarks?
>
>> +if (s->revtab32) {
>> +for(i=0; i> +int k;
>> +j = i;
>> +if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)
>> +j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
>> +k = -split_radix_permutation(i, n, s->inverse) &
>> (n-1);
>> +s->revtab32[k] = j;
>> +}
>> +}
>
> On the other hand, all the code is duplicated. Is there a more elegant
> way to do this?
Hi Moritz,
For example:
Original logic:
int n = 32;
for (i = 0 ; i < n; i++) {
if (check1) do_something;
if (check2) do_something;
}
If check1 is true and check2 is false, this loop 32 times, check condition 64
times;
After this patch:
int n = 32;
if (check1)
for (i = 0 ; i < n; i++) {
do_something;
}
if (check2)
for (i = 0 ; i < n; i++) {
do_something;
}
If check1 is true and check2 is false, this loop 32 times, check condition 2
times
And there should only one of the two condition is true,
because the s->revtab or s->revtab32 is allocation at begin of ff_fft_init,
and if nbits <= 16 the s->revtab maybe true else s->revtab32 is true.
So i modify it here.
I think maybe have more elegant way to do this if this logic is ok.
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/g723_1: add support for stereo files
2018-12-15 13:24 GMT+01:00, Paul B Mahol : [...] Can you share an existing sample? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/g723_1: add support for stereo files
On 12/16/18, Carl Eugen Hoyos wrote: > 2018-12-15 13:24 GMT+01:00, Paul B Mahol : > > [...] > > Can you share an existing sample? I'm afraid not. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/g723_1: add support for stereo files
2018-12-16 16:02 GMT+01:00, Paul B Mahol : > On 12/16/18, Carl Eugen Hoyos wrote: >> 2018-12-15 13:24 GMT+01:00, Paul B Mahol : >> >> [...] >> >> Can you share an existing sample? > > I'm afraid not. Which product encodes / decodes such files? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/g723_1: add support for stereo files
On 12/16/18, Carl Eugen Hoyos wrote: > 2018-12-16 16:02 GMT+01:00, Paul B Mahol : >> On 12/16/18, Carl Eugen Hoyos wrote: >>> 2018-12-15 13:24 GMT+01:00, Paul B Mahol : >>> >>> [...] >>> >>> Can you share an existing sample? >> >> I'm afraid not. > > Which product encodes / decodes such files? One of Verint call center stuff that also records screen. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/af_apad: add pad_dur and whole_dur options
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 18 +++---
libavfilter/af_apad.c | 23 +--
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index e3415630ec..ac4c9b44d8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1776,11 +1776,23 @@ Set the minimum total number of samples in the output
audio stream. If
the value is longer than the input audio length, silence is added to
the end, until the value is reached. This option is mutually exclusive
with @option{pad_len}.
+
+@item pad_dur
+Specify the duration of samples of silence to add. See
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1)
manual,ffmpeg-utils}
+for the accepted syntax. Used only if set to non-zero value.
+
+@item whole_dur
+Specify the minimum total duration in the output audio stream. See
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1)
manual,ffmpeg-utils}
+for the accepted syntax. Used only if set to non-zero value. If the value is
longer than
+the input audio length, silence is added to the end, until the value is
reached.
+This option is mutually exclusive with @option{pad_dur}
@end table
-If neither the @option{pad_len} nor the @option{whole_len} option is
-set, the filter will add silence to the end of the input stream
-indefinitely.
+If neither the @option{pad_len} nor the @option{whole_len} nor @option{pad_dur}
+nor @option{whole_dur} option is set, the filter will add silence to the end of
+the input stream indefinitely.
@subsection Examples
diff --git a/libavfilter/af_apad.c b/libavfilter/af_apad.c
index f7a4199c64..fbcf6d1349 100644
--- a/libavfilter/af_apad.c
+++ b/libavfilter/af_apad.c
@@ -41,6 +41,8 @@ typedef struct APadContext {
int packet_size;
int64_t pad_len, pad_len_left;
int64_t whole_len, whole_len_left;
+int64_t pad_dur;
+int64_t whole_dur;
} APadContext;
#define OFFSET(x) offsetof(APadContext, x)
@@ -50,6 +52,8 @@ static const AVOption apad_options[] = {
{ "packet_size", "set silence packet size",
OFFSET(packet_size), AV_OPT_TYPE_INT, { .i64 = 4096 }, 0, INT_MAX, A },
{ "pad_len", "set number of samples of silence to add",
OFFSET(pad_len), AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, A },
{ "whole_len", "set minimum target number of samples in the audio
stream", OFFSET(whole_len), AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX,
A },
+{ "pad_dur", "set duration of silence to add",
OFFSET(pad_dur), AV_OPT_TYPE_DURATION, { .i64 = 0 }, 0, INT64_MAX, A },
+{ "whole_dur", "set minimum target duration in the audio stream",
OFFSET(whole_dur), AV_OPT_TYPE_DURATION, { .i64 = 0 }, 0, INT64_MAX, A },
{ NULL }
};
@@ -64,8 +68,6 @@ static av_cold int init(AVFilterContext *ctx)
av_log(ctx, AV_LOG_ERROR, "Both whole and pad length are set, this is
not possible\n");
return AVERROR(EINVAL);
}
-s->pad_len_left = s->pad_len;
-s->whole_len_left = s->whole_len;
return 0;
}
@@ -131,6 +133,22 @@ static int request_frame(AVFilterLink *outlink)
return ret;
}
+static int config_output(AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+APadContext *s = ctx->priv;
+
+if (s->pad_dur)
+s->pad_len = av_rescale(s->pad_dur, outlink->sample_rate,
AV_TIME_BASE);
+if (s->whole_dur)
+s->whole_len = av_rescale(s->whole_dur, outlink->sample_rate,
AV_TIME_BASE);
+
+s->pad_len_left = s->pad_len;
+s->whole_len_left = s->whole_len;
+
+return 0;
+}
+
static const AVFilterPad apad_inputs[] = {
{
.name = "default",
@@ -144,6 +162,7 @@ static const AVFilterPad apad_outputs[] = {
{
.name = "default",
.request_frame = request_frame,
+.config_props = config_output,
.type = AVMEDIA_TYPE_AUDIO,
},
{ NULL }
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/g723_1: add support for stereo files
2018-12-16 16:37 GMT+01:00, Paul B Mahol : > On 12/16/18, Carl Eugen Hoyos wrote: >> 2018-12-16 16:02 GMT+01:00, Paul B Mahol : >>> On 12/16/18, Carl Eugen Hoyos wrote: 2018-12-15 13:24 GMT+01:00, Paul B Mahol : [...] Can you share an existing sample? >>> >>> I'm afraid not. >> >> Which product encodes / decodes such files? > > One of Verint call center stuff that also records screen. Consider mentioning this in the commit message. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/id3v2: fail read_apic on EOF reading mimetype
fre 2018-12-14 klockan 13:44 -0800 skrev chcunningham:
> avio_read may return EOF, leaving the mimetype array unitialized.
> fail
> early when this occurs to avoid using the array in an unitialized
> state.
> ---
> libavformat/id3v2.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> index f7de26a1d8..5fe055b591 100644
> --- a/libavformat/id3v2.c
> +++ b/libavformat/id3v2.c
> @@ -590,7 +590,7 @@ static void read_apic(AVFormatContext *s,
> AVIOContext *pb, int taglen,
> int isv34)
> {
> int enc, pic_type;
> -char mimetype[64];
> +char mimetype[64] = {0};
> const CodecMime *mime = ff_id3v2_mime_tags;
> enum AVCodecID id = AV_CODEC_ID_NONE;
> ID3v2ExtraMetaAPIC *apic = NULL;
> @@ -612,7 +612,9 @@ static void read_apic(AVFormatContext *s,
> AVIOContext *pb, int taglen,
> if (isv34) {
> taglen -= avio_get_str(pb, taglen, mimetype,
> sizeof(mimetype));
> } else {
> -avio_read(pb, mimetype, 3);
> +if (avio_read(pb, mimetype, 3) < 0)
> +goto fail;
> +
Looks good to me
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/rpza: Move frame allocation to a later point
This will allow performing some fast checks before the slow allocation
Signed-off-by: Michael Niedermayer
---
libavcodec/rpza.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/rpza.c b/libavcodec/rpza.c
index b71ebd1cbe..cffbfe4416 100644
--- a/libavcodec/rpza.c
+++ b/libavcodec/rpza.c
@@ -73,13 +73,12 @@ typedef struct RpzaContext {
static int rpza_decode_stream(RpzaContext *s)
{
int width = s->avctx->width;
-int stride = s->frame->linesize[0] / 2;
-int row_inc = stride - 4;
+int stride, row_inc, ret;
int chunk_size;
uint16_t colorA = 0, colorB;
uint16_t color4[4];
uint16_t ta, tb;
-uint16_t *pixels = (uint16_t *)s->frame->data[0];
+uint16_t *pixels;
int row_ptr = 0;
int pixel_ptr = 0;
@@ -106,6 +105,12 @@ static int rpza_decode_stream(RpzaContext *s)
/* Number of 4x4 blocks in frame. */
total_blocks = ((s->avctx->width + 3) / 4) * ((s->avctx->height + 3) / 4);
+if ((ret = ff_reget_buffer(s->avctx, s->frame)) < 0)
+return ret;
+pixels = (uint16_t *)s->frame->data[0];
+stride = s->frame->linesize[0] / 2;
+row_inc = stride - 4;
+
/* Process chunk data */
while (bytestream2_get_bytes_left(&s->gb)) {
uint8_t opcode = bytestream2_get_byte(&s->gb); /* Get opcode */
@@ -256,9 +261,6 @@ static int rpza_decode_frame(AVCodecContext *avctx,
bytestream2_init(&s->gb, avpkt->data, avpkt->size);
-if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
-return ret;
-
ret = rpza_decode_stream(s);
if (ret < 0)
return ret;
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/fic: Fail on invalid slice size/off
Fixes: Timeout
Fixes:
11486/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FIC_fuzzer-5677133863583744
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/fic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/fic.c b/libavcodec/fic.c
index dcf0777674..3e36346358 100644
--- a/libavcodec/fic.c
+++ b/libavcodec/fic.c
@@ -380,6 +380,8 @@ static int fic_decode_frame(AVCodecContext *avctx, void
*data,
slice_h = FFALIGN(avctx->height - ctx->slice_h * (nslices -
1), 16);
} else {
slice_size = AV_RB32(src + tsize + FIC_HEADER_SIZE + slice * 4 +
4);
+if (slice_size < slice_off)
+return AVERROR_INVALIDDATA;
}
if (slice_size < slice_off || slice_size > msize)
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/rpza: Check that there is enough data for all the blocks
Fixes: Timeout Fixes: 11547/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RPZA_fuzzer-5678435842654208 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/rpza.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/rpza.c b/libavcodec/rpza.c index cffbfe4416..8e1efa2445 100644 --- a/libavcodec/rpza.c +++ b/libavcodec/rpza.c @@ -105,6 +105,9 @@ static int rpza_decode_stream(RpzaContext *s) /* Number of 4x4 blocks in frame. */ total_blocks = ((s->avctx->width + 3) / 4) * ((s->avctx->height + 3) / 4); +if (total_blocks / 32 > bytestream2_get_bytes_left(&s->gb)) +return AVERROR_INVALIDDATA; + if ((ret = ff_reget_buffer(s->avctx, s->frame)) < 0) return ret; pixels = (uint16_t *)s->frame->data[0]; -- 2.19.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vividas demuxer
lör 2018-12-15 klockan 20:06 +0100 skrev Paul B Mahol:
> > Signed-off-by: Paul B Mahol
> +
> +static void put_v(uint8_t *p, int v)
This should take unsigned
> +{
> +if (v>>28)
> +*p++ = ((v>>28)&0x7f)|0x80;
> +if (v>>21)
> +*p++ = ((v>>21)&0x7f)|0x80;
> +if (v>>14)
> +*p++ = ((v>>14)&0x7f)|0x80;
> +if (v>>7)
> +*p++ = ((v>>7)&0x7f)|0x80;
> +}
> +
> +static unsigned int recover_key(unsigned char sample[4], int expected_size)
this too
> +{
> +unsigned char plaintext[8] = { 'S', 'B' };
> +
> +put_v(plaintext+2, expected_size);
> +
> +return (sample[0]^plaintext[0])|
> +((sample[1]^plaintext[1])<<8)|
> +((sample[2]^plaintext[2])<<16)|
> +((sample[3]^plaintext[3])<<24);
> +}
> +
> +static void xor_block(void *p1, void *p2, int size, int key, int *key_ptr)
here as well
> +{
> +int *d1 = p1;
> +int *d2 = p2;
> +int k = *key_ptr;
> +
> +size >>= 2;
> +
> +while (size--) {
> +*d2 = *d1 ^ k;
> +k += key;
> +d1++;
> +d2++;
> +}
> +
> +*key_ptr = k;
> +}
> +
> +static void decode_block(uint8_t *src, uint8_t *dest, int size,
> + uint32_t key, uint32_t *key_ptr,
> + int align)
and here
> +{
> +int s = size;
> +char tmp[4];
> +int a2;
> +
> +if (!size)
> +return;
> +
> +align &= 3;
> +a2 = (4 - align) & 3;
> +
> +if (align) {
> +uint32_t tmpkey = *key_ptr - key;
> +memcpy(tmp + align, src, a2);
> +xor_block(tmp, tmp, 4, key, &tmpkey);
> +memcpy(dest, tmp + align, a2);
> +s -= a2;
> +}
> +
> +if (s >= 4) {
> +if (!align)
> +align = 4;
> +xor_block(src + a2, dest + a2, s & ~3,
> + key, key_ptr);
> +s &= 3;
> +}
> +
> +if (s) {
> +size -= s;
> +memcpy(tmp, src + size, s);
> +xor_block(&tmp, &tmp, 4, key, key_ptr);
> +memcpy(dest + size, tmp, s);
> +}
> +}
> +
Becuse:
> +static uint32_t get_v(uint8_t *p)
> +{
> +uint32_t v = 0;
> +
> +do {
> +if (v >= UINT_MAX / 128 - *p)
> +return v;
> +v <<= 7;
> +v += *p & 0x7f;
> +} while (*p++ & 0x80);
> +
> +return v;
This may return values between INT_MAX+1 and UINT_MAX...
> +}
> +
> +static uint8_t *read_vblock(AVIOContext *src, uint32_t *size,
> +uint32_t key, uint32_t *k2, int align)
> +{
> +uint8_t tmp[4];
> +uint8_t *buf;
> +unsigned n;
> +
> +if (avio_read(src, tmp, 4) != 4)
> +return NULL;
> +
> +decode_block(tmp, tmp, 4, key, k2, align);
> +
> +n = get_v(tmp);
> +if (!n)
> +return NULL;
> +
> +buf = av_malloc(n);
> +if (!buf)
> +return NULL;
> +
> +*size = n;
> +n -= 4;
> +
> +memcpy(buf, tmp, 4);
> +
> +if (avio_read(src, buf + 4, n) == n) {
> +decode_block(buf + 4, buf + 4, n, key, k2, align + 4);
which get passed in here ^
leading to undefined behavior
> +} else {
> +av_free(buf);
> +buf = NULL;
> +}
> +
> +return buf;
> +}
> +
> +static uint8_t *read_sb_block(AVIOContext *src, unsigned *size,
> + uint32_t *key, int expected_size)
expected_size should be unsigned too.. And so on, I think you get the
picture
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/vorbiscomment: add support for writing chapters
Signed-off-by: Paul B Mahol
---
libavformat/flacenc.c | 4 +--
libavformat/matroskaenc.c | 4 +--
libavformat/oggenc.c| 22 +++---
libavformat/vorbiscomment.c | 59 +++--
libavformat/vorbiscomment.h | 8 +++--
5 files changed, 78 insertions(+), 19 deletions(-)
diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index 617bccdc84..a07260f426 100644
--- a/libavformat/flacenc.c
+++ b/libavformat/flacenc.c
@@ -65,7 +65,7 @@ static int flac_write_block_comment(AVIOContext *pb,
AVDictionary **m,
ff_metadata_conv(m, ff_vorbiscomment_metadata_conv, NULL);
-len = ff_vorbiscomment_length(*m, vendor);
+len = ff_vorbiscomment_length(*m, vendor, NULL, 0);
if (len >= ((1<<24) - 4))
return AVERROR(EINVAL);
p0 = av_malloc(len+4);
@@ -75,7 +75,7 @@ static int flac_write_block_comment(AVIOContext *pb,
AVDictionary **m,
bytestream_put_byte(&p, last_block ? 0x84 : 0x04);
bytestream_put_be24(&p, len);
-ff_vorbiscomment_write(&p, m, vendor);
+ff_vorbiscomment_write(&p, m, vendor, NULL, 0);
avio_write(pb, p0, len+4);
av_freep(&p0);
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index aed83aef70..f0e4c60b93 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -693,7 +693,7 @@ static int put_flac_codecpriv(AVFormatContext *s,
snprintf(buf, sizeof(buf), "0x%"PRIx64, par->channel_layout);
av_dict_set(&dict, "WAVEFORMATEXTENSIBLE_CHANNEL_MASK", buf, 0);
-len = ff_vorbiscomment_length(dict, vendor);
+len = ff_vorbiscomment_length(dict, vendor, NULL, 0);
if (len >= ((1<<24) - 4))
return AVERROR(EINVAL);
@@ -707,7 +707,7 @@ static int put_flac_codecpriv(AVFormatContext *s,
AV_WB24(data + 1, len);
p = data + 4;
-ff_vorbiscomment_write(&p, &dict, vendor);
+ff_vorbiscomment_write(&p, &dict, vendor, NULL, 0);
avio_write(pb, data, len + 4);
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index 10c4eda062..06021c4f4b 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -291,7 +291,8 @@ static int ogg_buffer_data(AVFormatContext *s, AVStream *st,
}
static uint8_t *ogg_write_vorbiscomment(int64_t offset, int bitexact,
-int *header_len, AVDictionary **m, int
framing_bit)
+int *header_len, AVDictionary **m, int
framing_bit,
+AVChapter **chapters, unsigned int
nb_chapters)
{
const char *vendor = bitexact ? "ffmpeg" : LIBAVFORMAT_IDENT;
int64_t size;
@@ -299,7 +300,7 @@ static uint8_t *ogg_write_vorbiscomment(int64_t offset, int
bitexact,
ff_metadata_conv(m, ff_vorbiscomment_metadata_conv, NULL);
-size = offset + ff_vorbiscomment_length(*m, vendor) + framing_bit;
+size = offset + ff_vorbiscomment_length(*m, vendor, chapters, nb_chapters)
+ framing_bit;
if (size > INT_MAX)
return NULL;
p = av_mallocz(size);
@@ -308,7 +309,7 @@ static uint8_t *ogg_write_vorbiscomment(int64_t offset, int
bitexact,
p0 = p;
p += offset;
-ff_vorbiscomment_write(&p, m, vendor);
+ff_vorbiscomment_write(&p, m, vendor, chapters, nb_chapters);
if (framing_bit)
bytestream_put_byte(&p, 1);
@@ -342,7 +343,7 @@ static int ogg_build_flac_headers(AVCodecParameters *par,
bytestream_put_buffer(&p, par->extradata, FLAC_STREAMINFO_SIZE);
// second packet: VorbisComment
-p = ogg_write_vorbiscomment(4, bitexact, &oggstream->header_len[1], m, 0);
+p = ogg_write_vorbiscomment(4, bitexact, &oggstream->header_len[1], m, 0,
NULL, 0);
if (!p)
return AVERROR(ENOMEM);
oggstream->header[1] = p;
@@ -373,7 +374,7 @@ static int ogg_build_speex_headers(AVCodecParameters *par,
AV_WL32(&oggstream->header[0][68], 0); // set extra_headers to 0
// second packet: VorbisComment
-p = ogg_write_vorbiscomment(0, bitexact, &oggstream->header_len[1], m, 0);
+p = ogg_write_vorbiscomment(0, bitexact, &oggstream->header_len[1], m, 0,
NULL, 0);
if (!p)
return AVERROR(ENOMEM);
oggstream->header[1] = p;
@@ -385,7 +386,8 @@ static int ogg_build_speex_headers(AVCodecParameters *par,
static int ogg_build_opus_headers(AVCodecParameters *par,
OGGStreamContext *oggstream, int bitexact,
- AVDictionary **m)
+ AVDictionary **m, AVChapter **chapters,
+ unsigned int nb_chapters)
{
uint8_t *p;
@@ -401,7 +403,7 @@ static int ogg_build_opus_headers(AVCodecParameters *par,
bytestream_put_buffer(&p, par->extradata, par->extradata_size);
/* second packet: VorbisComment */
-p = ogg_write_vorbiscomment(8, bitexact, &oggstream->header_len[1], m, 0);
+p = ogg_write_vorbiscomment(8, bite
[FFmpeg-devel] [PATCH] avformat: add vividas demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/vividas.c| 715 +++
3 files changed, 717 insertions(+)
create mode 100644 libavformat/vividas.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 0e43a12df5..c42ceb40c5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -522,6 +522,7 @@ OBJS-$(CONFIG_VC1_DEMUXER) += rawdec.o
vc1dec.o
OBJS-$(CONFIG_VC1_MUXER) += rawenc.o
OBJS-$(CONFIG_VC1T_DEMUXER) += vc1test.o
OBJS-$(CONFIG_VC1T_MUXER)+= vc1testenc.o
+OBJS-$(CONFIG_VIVIDAS_DEMUXER) += vividas.o
OBJS-$(CONFIG_VIVO_DEMUXER) += vivo.o
OBJS-$(CONFIG_VMD_DEMUXER) += sierravmd.o
OBJS-$(CONFIG_VOBSUB_DEMUXER)+= subtitles.o # mpeg demuxer is in
the dependencies
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index df83b04484..399625fd78 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -422,6 +422,7 @@ extern AVInputFormat ff_vc1_demuxer;
extern AVOutputFormat ff_vc1_muxer;
extern AVInputFormat ff_vc1t_demuxer;
extern AVOutputFormat ff_vc1t_muxer;
+extern AVInputFormat ff_vividas_demuxer;
extern AVInputFormat ff_vivo_demuxer;
extern AVInputFormat ff_vmd_demuxer;
extern AVInputFormat ff_vobsub_demuxer;
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
new file mode 100644
index 00..61eb9e1cf0
--- /dev/null
+++ b/libavformat/vividas.c
@@ -0,0 +1,715 @@
+/*
+ * Vividas VIV format Demuxer
+ * Copyright (c) 2012 Krzysztof Klinikowski
+ * Copyright (c) 2010 Andrzej Szombierski
+ * based on vivparse Copyright (c) 2007 Måns Rullgård
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * @brief Vividas VIV (.viv) file demuxer
+ * @author Andrzej Szombierski [qq at kuku eu org] (2010-07)
+ * @sa http://wiki.multimedia.cx/index.php?title=Vividas_VIV
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avio_internal.h"
+#include "avformat.h"
+
+#define MAX_AUDIO_SUBPACKETS 100
+
+typedef struct VIV_SB_block {
+int size, n_packets;
+int64_t byte_offset;
+int64_t packet_offset;
+} VIV_SB_block;
+
+typedef struct VIV_SB_entry {
+int size, flag;
+} VIV_SB_entry;
+
+typedef struct VIV_AudioSubpacket {
+int start, pcm_bytes;
+} VIV_AudioSubpacket;
+
+typedef struct VividasDemuxContext {
+int n_sb_blocks;
+VIV_SB_block *sb_blocks;
+
+uint32_t sb_key;
+int64_t sb_offset;
+
+int current_sb, current_sb_entry;
+uint8_t *sb_buf;
+AVIOContext *sb_pb;
+int n_sb_entries;
+VIV_SB_entry *sb_entries;
+
+int n_audio_subpackets;
+int current_audio_subpacket;
+
+int64_t audio_sample;
+
+VIV_AudioSubpacket audio_subpackets[MAX_AUDIO_SUBPACKETS];
+} VividasDemuxContext;
+
+static int viv_probe(AVProbeData *p)
+{
+if (memcmp(p->buf, "vividas03", 9))
+return 0;
+
+return AVPROBE_SCORE_MAX;
+}
+
+static const unsigned short keybits[32] = {
+ 163, 416, 893, 82, 223, 572, 1137, 430,
+ 659, 1104, 13, 626, 695, 972, 1465, 686,
+ 843, 1216, 317, 1122, 1383, 92, 513, 1158,
+1243, 48, 573, 1306, 1495, 396, 1009, 350,
+};
+
+static uint32_t decode_key(uint8_t *buf)
+{
+uint32_t key = 0;
+
+for (int i = 0; i < 32; i++) {
+unsigned p = keybits[i];
+key |= !!(buf[p>>3] & (1<<(p&7))) << i;
+}
+
+return key;
+}
+
+static void put_v(uint8_t *p, unsigned v)
+{
+if (v>>28)
+*p++ = ((v>>28)&0x7f)|0x80;
+if (v>>21)
+*p++ = ((v>>21)&0x7f)|0x80;
+if (v>>14)
+*p++ = ((v>>14)&0x7f)|0x80;
+if (v>>7)
+*p++ = ((v>>7)&0x7f)|0x80;
+}
+
+static unsigned recover_key(unsigned char sample[4], unsigned expected_size)
+{
+unsigned char plaintext[8] = { 'S', 'B' };
+
+put_v(plaintext+2, expected_size);
+
+return (sample[0]^plaintext[0])|
+((sample[1]^plaintext[1])<<8)|
+((sample[2]^plaintext[2])<<16)|
+((sample[3]^plaintext[3])<<24);
+}
+
+static void xor_block(void *p1, void *p2, unsigned size, int key, int *key_ptr)
+{
+int *d1 = p1;
+int *d2 = p2;
+int k = *key_ptr;
+
+size >>= 2;
+
+
Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize float yuv2plane1
2018-12-16 10:06 GMT+01:00, Lauri Kasanen : > This function wouldn't benefit from VSX instructions, so I put it > under altivec. > > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt > grayf32le \ > -f null -vframes 100 -v error -nostats - > > 3743 UNITS in planar1, 65495 runs, 41 skips > > -cpuflags 0 > > 23511 UNITS in planar1, 65530 runs, 6 skips > > grayf32be > > 4647 UNITS in planar1, 65449 runs, 87 skips > > -cpuflags 0 > > 28608 UNITS in planar1, 65530 runs, 6 skips > > The native speedup is 6.28133, and the bswapping one 6.15623. > Fate passes I wonder a little how, given that grayf32 already breaks fate as-is... Note that this function / this pix_fmt currently has no real use-case afaict. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/fft_template: improve performance of the ff_fft_init in fft_template
2018-12-16 14:19 GMT+01:00, Steven Liu : > move the two if condition out of the loop, that can less > n-1 times than condition in loop. Please add some benchmarks to the commit message. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: Default to clang for Android
2018-12-07 3:06 GMT+01:00, Carl Eugen Hoyos : > I believe the Android documentation indicates that gcc will be removed > from ndk. Attached patch changes the default to "clang" for > --target-os=android. > > Now with patch. Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavc/options_table: Change some options location in opt table.
On Sun, Dec 16, 2018 at 8:03 AM Michael Niedermayer wrote: > > On Sat, Dec 15, 2018 at 07:31:35PM +0800, Jun Zhao wrote: > > Change the some options location in avcodec_options to make code more > > readable. > > > > Signed-off-by: Jun Zhao > > --- > > libavcodec/options_table.h | 48 > > ++-- > > 1 files changed, 24 insertions(+), 24 deletions(-) > > breaks fate: > > ... > > @@ -196,14 +197,9 @@ > aspect=180/180 > sar=180/180 > debug=0x > -cmp=0 > -subcmp=0 > -mbcmp=0 > -ildctcmp=8 > dia_size=0 > last_pred=0 > preme=0 > -precmp=0 > pre_dia_size=0 > subq=8 > me_range=0 > @@ -215,7 +211,6 @@ > sc_threshold=0 > nr=0 > rc_init_occupancy=0 > -flags2=0x > threads=1 > dc=0 > nssew=8 > @@ -228,6 +223,11 @@ > skip_factor=0 > skip_exp=0 > skipcmp=13 > +cmp=0 > +subcmp=0 > +mbcmp=0 > +ildctcmp=8 > +precmp=0 > mblmin=236 > mblmax=3658 > mepc=256 > Test api-png-codec-param failed. Look at > tests/data/fate/api-png-codec-param.err for details. > make: *** [fate-api-png-codec-param] Error 1 > make: *** Waiting for unfinished jobs > Test api-mjpeg-codec-param failed. Look at > tests/data/fate/api-mjpeg-codec-param.err for details. > make: *** [fate-api-mjpeg-codec-param] Error 1 > fixed in V2 version, tks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer wrote: > > On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote: > > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström wrote: > > > > > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström wrote: > > > > > > > > From: Rodger Combs > > > > > > > > These are registered identifiers at the MPEG-4 RA, which are > > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that > > > > are not correctly presentable by standards-compliant AVC/HEVC players. > > > > > > > > According to the Dolby Vision specification for ISOBMFF, these sample > > > > entry codes are specified to have the standard AVC or HEVC decoder > > > > configuration box in addition to the Dolby custom DOVIConfigurationBox. > > > > This is what enables us to decode the streams without custom parsing. > > > > > > > > For correct presentation information from the DOVIConfigurationBox > > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement > > > > layer). > > > > --- > > > > > > Gentle Ping? > > > > > > Jan > > > > Ping^2? > > > > And if nobody really cares, I will reverse the comments on the AVC > > entries (since I seem to have gotten them the wrong way around when > > adding the comments and commit message late at night) and apply the > > set tomorrow morning. These additional identifiers and the comment > > should not be affecting existing FATE samples. > > probably ok, if tested and it works > > thx The specification so far has matched reality: 1. Custom MPEG-4 RA registered ID is used 2. Standard AVC or HEVC initialization data box is used (so in that sense an implementation does not need to implement additional parsing just to get the streams decoded) 3. Video stream itself contains no metadata, but additional Dolby-specific box (DOVIConfigurationBox) specified in the specification contains the actual colorimetry utilized. These custom identifiers are mostly utilized for profile 5 of Dolby Vision, so we cannot properly *present* the video without figuring out how ICtCt+PQ has been mangled for Dolby Vision (which is why at this point I wouldn't mention tickets being "fixed" by these identifiers). 4. Both VLC and Chromium added and utilize these same identifiers, as I've posted links to them before in previous versions of this patch set. So as far as it's been possible to test this, that's been done and we're just implementing things according to the specification - which is how other projects seem to have done it as well. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
2018-12-17 1:58 GMT+01:00, Jan Ekström : > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer > wrote: >> >> On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote: >> > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström wrote: >> > > >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström wrote: >> > > > >> > > > From: Rodger Combs >> > > > >> > > > These are registered identifiers at the MPEG-4 RA, which are >> > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that >> > > > are not correctly presentable by standards-compliant AVC/HEVC >> > > > players. >> > > > >> > > > According to the Dolby Vision specification for ISOBMFF, these >> > > > sample >> > > > entry codes are specified to have the standard AVC or HEVC decoder >> > > > configuration box in addition to the Dolby custom >> > > > DOVIConfigurationBox. >> > > > This is what enables us to decode the streams without custom >> > > > parsing. >> > > > >> > > > For correct presentation information from the DOVIConfigurationBox >> > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or >> > > > enhancement >> > > > layer). >> > > > --- >> > > >> > > Gentle Ping? >> > > >> > > Jan >> > >> > Ping^2? >> > >> > And if nobody really cares, I will reverse the comments on the AVC >> > entries (since I seem to have gotten them the wrong way around when >> > adding the comments and commit message late at night) and apply the >> > set tomorrow morning. These additional identifiers and the comment >> > should not be affecting existing FATE samples. >> >> probably ok, if tested and it works >> >> thx > > The specification so far has matched reality: > 1. Custom MPEG-4 RA registered ID is used > 2. Standard AVC or HEVC initialization data box is used (so in that > sense an implementation does not need to implement additional parsing > just to get the streams decoded) > 3. Video stream itself contains no metadata, but additional > Dolby-specific box (DOVIConfigurationBox) specified in the > specification contains the actual colorimetry utilized. These custom > identifiers are mostly utilized for profile 5 of Dolby Vision, so we > cannot properly *present* the video without figuring out how ICtCt+PQ > has been mangled for Dolby Vision (which is why at this point I > wouldn't mention tickets being "fixed" by these identifiers). > 4. Both VLC and Chromium added and utilize these same identifiers, as > I've posted links to them before in previous versions of this patch > set. > > So as far as it's been possible to test this, that's been done Could you point me to a dva1 sample? > and we're just implementing things according to the specification > - which is how other projects seem to have done it as well. But isn't this exactly the issue? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lsws/utils: Split "emms_c(); " call in two lines
Hi! Attached patch fixes a useless warning when compiling with clang on arm. Please comment, Carl Eugen From b2773d1ca9473380b99400c2bbd5a6729622f51a Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Mon, 17 Dec 2018 02:12:13 +0100 Subject: [PATCH] lsws/utils: Split "emms_c();" in two lines. Silences a clang warning when not compiling for x86: libswscale/utils.c:345:13: warning: while loop has empty body --- libswscale/utils.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libswscale/utils.c b/libswscale/utils.c index df68bcc..de64694 100644 --- a/libswscale/utils.c +++ b/libswscale/utils.c @@ -342,7 +342,8 @@ static av_cold int initFilter(int16_t **outFilter, int32_t **filterPos, const int64_t fone = 1LL << (54 - FFMIN(av_log2(srcW/dstW), 8)); int ret= -1; -emms_c(); // FIXME should not be required but IS (even for non-MMX versions) +emms_c() // FIXME should not be required but IS (even for non-MMX versions) +; // NOTE: the +3 is for the MMX(+1) / SSE(+3) scaler which reads over the end FF_ALLOC_ARRAY_OR_GOTO(NULL, *filterPos, (dstW + 3), sizeof(**filterPos), fail); -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *
Hi!
The Opus struct RawBitsContext is used in both the decoder and the encoder.
The fact that *position is const avoids warnings in the decoder where
it points into the bitstream. The encoder writes into the same
pointer, attached cast silences the warning on targets where AV_WB32()
does not internally cast the qualifier away.
It is also possible to use a union if anybody prefers this:
diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
index 627f832..baad4ce 100644
--- a/libavcodec/opus_rc.h
+++ b/libavcodec/opus_rc.h
@@ -37,9 +37,19 @@ typedef struct RawBitsContext {
uint32_t cacheval;
} RawBitsContext;
+typedef struct RawBitsEncContext {
+uint8_t *position;
+uint32_t bytes;
+uint32_t cachelen;
+uint32_t cacheval;
+} RawBitsEncContext;
+
typedef struct OpusRangeCoder {
GetBitContext gb;
-RawBitsContext rb;
+union {
+RawBitsContext rb;
+RawBitsEncContext rbe;
+};
uint32_t range;
uint32_t value;
uint32_t total_bits;
and use rbe in ff_opus_rc_put_raw().
Please comment, Carl Eugen
From 2fe5044a4532f061ef4090fd46f1ec1a3af067b0 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 17 Dec 2018 02:36:26 +0100
Subject: [PATCH] lavc/opus_rc: Cast a const pointer to uint8_t *.
Silences a warning with clang on arm:
libavcodec/opus_rc.c:170:17: warning: passing 'const uint8_t *' (aka 'const unsigned char *') to parameter of type 'void *' discards qualifiers
---
libavcodec/opus_rc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/opus_rc.c b/libavcodec/opus_rc.c
index 3972bb0..c432eb9 100644
--- a/libavcodec/opus_rc.c
+++ b/libavcodec/opus_rc.c
@@ -167,7 +167,7 @@ void ff_opus_rc_put_raw(OpusRangeCoder *rc, uint32_t val, uint32_t count)
rc->rb.cachelen = (rc->rb.cachelen + to_write) % 32;
if (!rc->rb.cachelen && count) {
-AV_WB32(rc->rb.position, rc->rb.cacheval);
+AV_WB32((uint8_t *)rc->rb.position, rc->rb.cacheval);
rc->rb.bytes+= 4;
rc->rb.position -= 4;
rc->rb.cachelen = count - to_write;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/fft_template: improve performance of the ff_fft_init in fft_template
Carl Eugen Hoyos 于2018年12月17日周一 上午8:29写道：
>
> 2018-12-16 14:19 GMT+01:00, Steven Liu :
> > move the two if condition out of the loop, that can less
> > n-1 times than condition in loop.
>
> Please add some benchmarks to the commit message.
Hi Folks,
I tested the performance of the modify,
before the patch:
MacBook:dash StevenLiu$ bash get_performance.sh
3921
after the patch:
MacBook:dash StevenLiu$ bash get_performance.sh
3723
MacBook:dash StevenLiu$ cat get_performance.sh
get 10 times data of the speed, and compute an average value, the
script as is bellow:
#!/usr/bin/bash
DURATION=0
for((i=0;i<10;i++)) do
./libavcodec/tests/fft -n 15 &>output
T_DURATION=`grep "duration" output | awk -F"=" '{ print $2}'`
DURATION=`expr $DURATION + $T_DURATION`
done
TOTAL=`expr $DURATION / 10`
echo $TOTAL
>
> Carl Eugen
> ___
> 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] libavformat/hlsenc: fix broken -hls_flags +temp_file
Aleksey Skripka 于2018年12月14日周五 下午10:58写道：
>
>
> From e85edcc4d8b0312c7871f78ed0859ec7436be460 Mon Sep 17 00:00:00 2001
> From: Aleksey Skripka
> Date: Fri, 14 Dec 2018 14:48:31 +
> Subject: [PATCH] libavformat/hlsenc: fix broken -hls_flags +temp_file
>
> 1. fix addressing '->flags' while assigning 'use_temp_file'.
> 2. before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 playlist file was always
> created via .tmp for 'file' proto, now not. keep old behavior.
> 3. rename logic in hls_write_packet() incorrectly placed (in fMP4-only code),
> thus not renaming files for mpegts.
> 4. needless av_free() call.
> ---
> libavformat/hlsenc.c | 23 +++
> 1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index bdd2a11..70eee19 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1358,7 +1358,7 @@ static int hls_window(AVFormatContext *s, int last,
> VariantStream *vs)
> char temp_filename[1024];
> int64_t sequence = FFMAX(hls->start_sequence, vs->sequence -
> vs->nb_entries);
> const char *proto = avio_find_protocol_name(s->url);
> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
> HLS_TEMP_FILE);
> +int use_temp_file = proto && !strcmp(proto, "file");
> static unsigned warned_non_file;
> char *key_uri = NULL;
> char *iv_string = NULL;
> @@ -1478,7 +1478,7 @@ static int hls_start(AVFormatContext *s, VariantStream
> *vs)
> AVFormatContext *vtt_oc = vs->vtt_avf;
> AVDictionary *options = NULL;
> const char *proto = avio_find_protocol_name(s->url);
> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
> HLS_TEMP_FILE);
> +int use_temp_file = proto && !strcmp(proto, "file") && (c->flags &
> HLS_TEMP_FILE);
> char *filename, iv_string[KEYSIZE*2 + 1];
> int err = 0;
>
> @@ -2143,7 +2143,7 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> int stream_index = 0;
> int range_length = 0;
> const char *proto = avio_find_protocol_name(s->url);
> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
> HLS_TEMP_FILE);
> +int use_temp_file = proto && !strcmp(proto, "file") && (hls->flags &
> HLS_TEMP_FILE);
> uint8_t *buffer = NULL;
> VariantStream *vs = NULL;
> AVDictionary *options = NULL;
> @@ -2266,7 +2266,6 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> if (hls->flags & HLS_SINGLE_FILE) {
> ret = flush_dynbuf(vs, &range_length);
> if (ret < 0) {
> -av_free(old_filename);
> return ret;
> }
> vs->size = range_length;
> @@ -2284,20 +2283,12 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> return ret;
> }
> ff_format_io_close(s, &vs->out);
> -
> -// rename that segment from .tmp to the real one
> -if (use_temp_file && oc->url[0]) {
> -hls_rename_temp_file(s, oc);
> -av_free(old_filename);
> -old_filename = av_strdup(vs->avf->url);
> -
> -if (!old_filename) {
> -return AVERROR(ENOMEM);
> -}
> -}
> }
> }
>
> +if (use_temp_file && oc->url[0] && !(hls->flags & HLS_SINGLE_FILE))
> +hls_rename_temp_file(s, oc);
> +
> old_filename = av_strdup(vs->avf->url);
> if (!old_filename) {
> return AVERROR(ENOMEM);
> @@ -2367,7 +2358,7 @@ static int hls_write_trailer(struct AVFormatContext *s)
> AVFormatContext *vtt_oc = NULL;
> char *old_filename = NULL;
> const char *proto = avio_find_protocol_name(s->url);
> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
> HLS_TEMP_FILE);
> +int use_temp_file = proto && !strcmp(proto, "file") && (hls->flags &
> HLS_TEMP_FILE);
> int i;
> int ret = 0;
> VariantStream *vs = NULL;
> --
> 1.8.3.1
>
> --
> Aleksey Skripka
>
>
>
> > On 14 Dec 2018, at 17:21, Steven Liu wrote:
> >
> >
> >
> >> On Dec 14, 2018, at 19:23, Aleksey Skripka wrote:
> >>
> >>>
> >>> On 14 Dec 2018, at 13:10, Liu Steven wrote:
> >>>
> >>>
> >>>
> 在 2018年12月14日，下午5:27，Aleksey Skripka 写道：
>
> greetings!
>
> fixed version.
> thanks.
> >>> Is this patch create by git format-patch ?
> >> no.
> >> diff -up fileA fileB
> > https://ffmpeg.org/developer.html#Submitting-patches-1
> > This is the rule for make a patch, I think your code is ok. :D
> >
> >>
>
> ---
> --- libavformat/hlsenc.c.orig 2018-12-14 09:25:06.541809226 +
> +++ libavformat/hlsenc.c2018-12-14 09:19:16.129377384 +
> @@ -1348,7 +1348,7 @@ static int hls_window(AVFormatContext *s
> char temp_filenam
Re: [FFmpeg-devel] [PATCH 1/2] configure: use custom allocator extralibs when testing memalign and posix_memalign
On Sun, Dec 09, 2018 at 09:27:54AM +1100, Peter Ross wrote: > the memalign and posix_memalign tests currently fail when using a custom > allocator, > because configure does not include the custom allocator library. is any one using custom allocators? should i just apply these? -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Added support for Low-latency HLS(Experimental)
On 12/12/18 9:50 PM, Karthick J wrote:
> Apple doesn't have an official spec for LHLS. Meanwhile hls.js player folks
> are
> trying to standardize a open LHLS spec. The draft spec is available in
> https://github.com/video-dev/hlsjs-rfcs/blob/lhls-spec/proposals/0001-lhls.md
> This option will also try to comply with the above open spec, till Apple's
> spec officially supports it.
> Applicable only when @var{streaming} and @var{hls_playlist} options are
> enabled.
> ---
> doc/muxers.texi | 8
> libavformat/dashenc.c | 37 +
> 2 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 809f88662e..4ed46a2220 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -305,6 +305,14 @@ If this flag is set, the dash segment files will be in
> in WebM format.
> @item -ignore_io_errors @var{ignore_io_errors}
> Ignore IO errors during open and write. Useful for long-duration runs with
> network output.
>
> +@item -lhls @var{lhls}
> +Enable Low-latency HLS(LHLS). Adds #EXT-X-PREFETCH tag with current
> segment's URI.
> +Apple doesn't have an official spec for LHLS. Meanwhile hls.js player folks
> are
> +trying to standardize a open LHLS spec. The draft spec is available in
> https://github.com/video-dev/hlsjs-rfcs/blob/lhls-spec/proposals/0001-lhls.md
> +This option will also try to comply with the above open spec, till Apple's
> spec officially supports it.
> +Applicable only when @var{streaming} and @var{hls_playlist} options are
> enabled.
> +This is an experimental feature.
> +
> @end table
>
> @anchor{framecrc}
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index f797b7bd1c..cfd0f601d4 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -139,6 +139,7 @@ typedef struct DASHContext {
> char *format_options_str;
> SegmentType segment_type_option; /* segment type as specified in
> options */
> int ignore_io_errors;
> +int lhls;
> } DASHContext;
>
> static struct codec_string {
> @@ -418,7 +419,8 @@ static void get_start_index_number(OutputStream *os,
> DASHContext *c,
> }
>
> static void write_hls_media_playlist(OutputStream *os, AVFormatContext *s,
> - int representation_id, int final) {
> + int representation_id, int final,
> + char *prefetch_url) {
> DASHContext *c = s->priv_data;
> int timescale = os->ctx->streams[0]->time_base.den;
> char temp_filename_hls[1024];
> @@ -431,6 +433,11 @@ static void write_hls_media_playlist(OutputStream *os,
> AVFormatContext *s,
> int i, start_index, start_number;
>
> get_start_index_number(os, c, &start_index, &start_number);
> +
> +if (!c->hls_playlist || start_index >= os->nb_segments ||
> +os->segment_type != SEGMENT_TYPE_MP4)
> +return;
> +
> get_hls_playlist_name(filename_hls, sizeof(filename_hls),
>c->dirname, representation_id);
>
> @@ -468,6 +475,9 @@ static void write_hls_media_playlist(OutputStream *os,
> AVFormatContext *s,
> }
> }
>
> +if (prefetch_url)
> +avio_printf(c->m3u8_out, "#EXT-X-PREFETCH:%s\n", prefetch_url);
> +
> if (final)
> ff_hls_write_end_list(c->m3u8_out);
>
> @@ -594,9 +604,8 @@ static void output_segment_list(OutputStream *os,
> AVIOContext *out, AVFormatCont
> }
> avio_printf(out, "\t\t\t\t\n");
> }
> -if (c->hls_playlist && start_index < os->nb_segments && os->segment_type
> == SEGMENT_TYPE_MP4)
> -{
> -write_hls_media_playlist(os, s, representation_id, final);
> +if (!c->lhls || final) {
> +write_hls_media_playlist(os, s, representation_id, final, NULL);
> }
>
> }
> @@ -1054,6 +1063,21 @@ static int dash_init(AVFormatContext *s)
> c->seg_duration = c->min_seg_duration;
> }
> #endif
> +if (c->lhls && s->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
> +av_log(s, AV_LOG_ERROR,
> + "LHLS is experimental, Please set -strict experimental in
> order to enable it.\n");
> +return AVERROR_EXPERIMENTAL;
> +}
> +
> +if (c->lhls && !c->streaming) {
> +av_log(s, AV_LOG_WARNING, "LHLS option will be ignored as streaming
> is not enabled\n");
> +c->lhls = 0;
> +}
> +
> +if (c->lhls && !c->hls_playlist) {
> +av_log(s, AV_LOG_WARNING, "LHLS option will be ignored as
> hls_playlist is not enabled\n");
> +c->lhls = 0;
> +}
>
> av_strlcpy(c->dirname, s->url, sizeof(c->dirname));
> ptr = strrchr(c->dirname, '/');
> @@ -1635,6 +1659,10 @@ static int dash_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> if (ret < 0) {
> return handle_io_open_error(s, ret, os->temp_path);
> }
> +if (c->lhls) {
> +char *prefetch_ur
Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos 2018-12-17 1:58 GMT+01:00, Jan Ekström : > > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer > > wrote: > >> > >> On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote: > >> > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström wrote: > >> > > > >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström > wrote: > >> > > > > >> > > > From: Rodger Combs > >> > > > > >> > > > These are registered identifiers at the MPEG-4 RA, which are > >> > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that > >> > > > are not correctly presentable by standards-compliant AVC/HEVC > >> > > > players. > >> > > > > >> > > > According to the Dolby Vision specification for ISOBMFF, these > >> > > > sample > >> > > > entry codes are specified to have the standard AVC or HEVC decoder > >> > > > configuration box in addition to the Dolby custom > >> > > > DOVIConfigurationBox. > >> > > > This is what enables us to decode the streams without custom > >> > > > parsing. > >> > > > > >> > > > For correct presentation information from the DOVIConfigurationBox > >> > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or > >> > > > enhancement > >> > > > layer). > >> > > > --- > >> > > > >> > > Gentle Ping? > >> > > > >> > > Jan > >> > > >> > Ping^2? > >> > > >> > And if nobody really cares, I will reverse the comments on the AVC > >> > entries (since I seem to have gotten them the wrong way around when > >> > adding the comments and commit message late at night) and apply the > >> > set tomorrow morning. These additional identifiers and the comment > >> > should not be affecting existing FATE samples. > >> > >> probably ok, if tested and it works > >> > >> thx > > > > The specification so far has matched reality: > > 1. Custom MPEG-4 RA registered ID is used > > 2. Standard AVC or HEVC initialization data box is used (so in that > > sense an implementation does not need to implement additional parsing > > just to get the streams decoded) > > 3. Video stream itself contains no metadata, but additional > > Dolby-specific box (DOVIConfigurationBox) specified in the > > specification contains the actual colorimetry utilized. These custom > > identifiers are mostly utilized for profile 5 of Dolby Vision, so we > > cannot properly *present* the video without figuring out how ICtCt+PQ > > has been mangled for Dolby Vision (which is why at this point I > > wouldn't mention tickets being "fixed" by these identifiers). > > 4. Both VLC and Chromium added and utilize these same identifiers, as > > I've posted links to them before in previous versions of this patch > > set. > > > > So as far as it's been possible to test this, that's been done > > Could you point me to a dva1 sample? > I have not seen any dolby vision samples with avc in the wild. You can ask Vittorio if he has some as he noted about possibly being able to ask for some before. > > and we're just implementing things according to the specification > > > - which is how other projects seem to have done it as well. > > But isn't this exactly the issue? > How is implementing things according to a specification "the issue"? Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize float yuv2plane1
On Mon, 17 Dec 2018 01:03:36 +0100 Carl Eugen Hoyos wrote: > 2018-12-16 10:06 GMT+01:00, Lauri Kasanen : > > This function wouldn't benefit from VSX instructions, so I put it > > under altivec. > > > > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt > > grayf32le \ > > -f null -vframes 100 -v error -nostats - > > > > 3743 UNITS in planar1, 65495 runs, 41 skips > > > > -cpuflags 0 > > > > 23511 UNITS in planar1, 65530 runs, 6 skips > > > > grayf32be > > > > 4647 UNITS in planar1, 65449 runs, 87 skips > > > > -cpuflags 0 > > > > 28608 UNITS in planar1, 65530 runs, 6 skips > > > > The native speedup is 6.28133, and the bswapping one 6.15623. > > > Fate passes > > I wonder a little how, given that grayf32 already breaks fate as-is... Are the tests for it disabled? fate.ffmpeg.org reports 100% success for many platforms. > Note that this function / this pix_fmt currently has no real use-case > afaict. Is there a list of which pix fmts are useful? Of course I don't want to waste both my and reviewers' time, if the format is considered for removal or otherwise broken. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
On Mon, Dec 17, 2018, 08:58 Jan Ekström > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos >> 2018-12-17 1:58 GMT+01:00, Jan Ekström : >> > On Mon, Dec 10, 2018 at 12:13 AM Michael Niedermayer >> > wrote: >> >> >> >> On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote: >> >> > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström wrote: >> >> > > >> >> > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström >> wrote: >> >> > > > >> >> > > > From: Rodger Combs >> >> > > > >> >> > > > These are registered identifiers at the MPEG-4 RA, which are >> >> > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that >> >> > > > are not correctly presentable by standards-compliant AVC/HEVC >> >> > > > players. >> >> > > > >> >> > > > According to the Dolby Vision specification for ISOBMFF, these >> >> > > > sample >> >> > > > entry codes are specified to have the standard AVC or HEVC >> decoder >> >> > > > configuration box in addition to the Dolby custom >> >> > > > DOVIConfigurationBox. >> >> > > > This is what enables us to decode the streams without custom >> >> > > > parsing. >> >> > > > >> >> > > > For correct presentation information from the >> DOVIConfigurationBox >> >> > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or >> >> > > > enhancement >> >> > > > layer). >> >> > > > --- >> >> > > >> >> > > Gentle Ping? >> >> > > >> >> > > Jan >> >> > >> >> > Ping^2? >> >> > >> >> > And if nobody really cares, I will reverse the comments on the AVC >> >> > entries (since I seem to have gotten them the wrong way around when >> >> > adding the comments and commit message late at night) and apply the >> >> > set tomorrow morning. These additional identifiers and the comment >> >> > should not be affecting existing FATE samples. >> >> >> >> probably ok, if tested and it works >> >> >> >> thx >> > >> > The specification so far has matched reality: >> > 1. Custom MPEG-4 RA registered ID is used >> > 2. Standard AVC or HEVC initialization data box is used (so in that >> > sense an implementation does not need to implement additional parsing >> > just to get the streams decoded) >> > 3. Video stream itself contains no metadata, but additional >> > Dolby-specific box (DOVIConfigurationBox) specified in the >> > specification contains the actual colorimetry utilized. These custom >> > identifiers are mostly utilized for profile 5 of Dolby Vision, so we >> > cannot properly *present* the video without figuring out how ICtCt+PQ >> > has been mangled for Dolby Vision (which is why at this point I >> > wouldn't mention tickets being "fixed" by these identifiers). >> > 4. Both VLC and Chromium added and utilize these same identifiers, as >> > I've posted links to them before in previous versions of this patch >> > set. >> > >> > So as far as it's been possible to test this, that's been done >> >> Could you point me to a dva1 sample? >> > > I have not seen any dolby vision samples with avc in the wild. You can ask > Vittorio if he has some as he noted about possibly being able to ask for > some before. > > >> > and we're just implementing things according to the specification >> >> > - which is how other projects seem to have done it as well. >> >> But isn't this exactly the issue? >> > > How is implementing things according to a specification "the issue"? > Also I would feel some worry if there were zero samples of it at all in the wild. But there are samples and those follow the specification. The fact that major projects in consumer space such as Chromium/Android implemented this, and that the identifier was registered properly at mpeg-4 ra means that if this thing changes then it will be an inconveniece for a lot of people. And if that happens it will be similar to the change in lossless predictive mode of H.264, since specs can change. Any spec. Although so far there have been zero signs of this possibly happening. Jan > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
