Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: treat quant_cof as a signed value
On 3/5/16, Umair Khan wrote:
> Signed-off-by: Umair Khan
> ---
> libavcodec/alsdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
> index ebd364e..0043512 100644
> --- a/libavcodec/alsdec.c
> +++ b/libavcodec/alsdec.c
> @@ -729,7 +729,7 @@ static int read_var_block_data(ALSDecContext *ctx,
> ALSBlockData *bd)
> quant_cof[k] = decode_rice(gb, rice_param) + offset;
> if (quant_cof[k] < -64 || quant_cof[k] > 63) {
> av_log(avctx, AV_LOG_ERROR,
> - "quant_cof %"PRIu32" is out of range.\n",
> + "quant_cof %"PRId32" is out of range.\n",
> quant_cof[k]);
> return AVERROR_INVALIDDATA;
> }
> --
> 2.5.0
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Original TOON.AVI with xxpc chunks
Speaking of toon.avi, here's the original from Sierra's King's Quest VI which contains xxpc chunks that aren't even detected by FFmpeg's demuxer. Probably some incorrect formatting of that AVI file, I don't know. https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] New versioning (was: version.sh: Always use latest tag for generated version number)
On 06.03.2016, at 02:50, Timothy Gu wrote: > To Michael and all release makers: after this patchset when making a > release in a release branch, please do ALL of the following in the > following order. Been absent a while from the list, but this sounds like we do not have documentation on the release process? Might be a good idea to add one then. Apart from that it would be nicer if we didn't need both RELEASE and VERSION files, in particular avoid constantly adding and removing them which breaks git log on them... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/utils: Add debug messages to ff_get_packet_palette()
Might be useful.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From e959e17d2cd770e1bb6280c07910a085af624bc1 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 6 Mar 2016 10:57:24 +0100
Subject: [PATCH] lavf/utils: Add debug messages to ff_get_packet_palette()
---
libavformat/utils.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 5f48de1..47659a6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4800,6 +4800,7 @@ int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t *
side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
if (side_data) {
+av_log(s, AV_LOG_DEBUG, "Palette in side data\n");
if (size != AVPALETTE_SIZE) {
av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
return AVERROR_INVALIDDATA;
@@ -4810,6 +4811,7 @@ int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t *
if (ret == CONTAINS_PAL) {
int i;
+av_log(s, AV_LOG_DEBUG, "Palette in packet\n");
for (i = 0; i < AVPALETTE_COUNT; i++)
palette[i] = AV_RL32(pkt->data + pkt->size - AVPALETTE_SIZE + i*4);
return 1;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/avf_showcqt: add performance debugging log
for easier development
Signed-off-by: Muhammad Faiz
---
libavfilter/avf_showcqt.c | 64 +++
libavfilter/avf_showcqt.h | 9 +++
2 files changed, 68 insertions(+), 5 deletions(-)
diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index f3fc782..2af44d7 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -25,6 +25,7 @@
#include "libavutil/xga_font_data.h"
#include "libavutil/eval.h"
#include "libavutil/pixdesc.h"
+#include "libavutil/time.h"
#include "avfilter.h"
#include "internal.h"
#include "lavfutils.h"
@@ -90,7 +91,33 @@ AVFILTER_DEFINE_CLASS(showcqt);
static void common_uninit(ShowCQTContext *s)
{
int k;
-
+int level = AV_LOG_DEBUG;
+int64_t plot_time;
+
+if (s->fft_time)
+av_log(s->ctx, level, "fft_time = %16.3f s.\n", s->fft_time *
1e-6);
+if (s->cqt_time)
+av_log(s->ctx, level, "cqt_time = %16.3f s.\n", s->cqt_time *
1e-6);
+if (s->process_cqt_time)
+av_log(s->ctx, level, "process_cqt_time = %16.3f s.\n",
s->process_cqt_time * 1e-6);
+if (s->update_sono_time)
+av_log(s->ctx, level, "update_sono_time = %16.3f s.\n",
s->update_sono_time * 1e-6);
+if (s->alloc_time)
+av_log(s->ctx, level, "alloc_time = %16.3f s.\n", s->alloc_time
* 1e-6);
+if (s->bar_time)
+av_log(s->ctx, level, "bar_time = %16.3f s.\n", s->bar_time *
1e-6);
+if (s->axis_time)
+av_log(s->ctx, level, "axis_time= %16.3f s.\n", s->axis_time *
1e-6);
+if (s->sono_time)
+av_log(s->ctx, level, "sono_time= %16.3f s.\n", s->sono_time *
1e-6);
+
+plot_time = s->fft_time + s->cqt_time + s->process_cqt_time +
s->update_sono_time
+ + s->alloc_time + s->bar_time + s->axis_time + s->sono_time;
+if (plot_time)
+av_log(s->ctx, level, "plot_time= %16.3f s.\n", plot_time *
1e-6);
+
+s->fft_time = s->cqt_time = s->process_cqt_time = s->update_sono_time
+= s->alloc_time = s->bar_time = s->axis_time = s->sono_time =
0;
/* axis_frame may be non reference counted frame */
if (s->axis_frame && !s->axis_frame->buf[0]) {
av_freep(s->axis_frame->data);
@@ -961,25 +988,52 @@ static int plot_cqt(AVFilterContext *ctx, AVFrame
**frameout)
{
AVFilterLink *outlink = ctx->outputs[0];
ShowCQTContext *s = ctx->priv;
+int64_t last_time, cur_time;
+
+#define UPDATE_TIME(t) \
+cur_time = av_gettime(); \
+t += cur_time - last_time; \
+last_time = cur_time
+
+last_time = av_gettime();
memcpy(s->fft_result, s->fft_data, s->fft_len * sizeof(*s->fft_data));
av_fft_permute(s->fft_ctx, s->fft_result);
av_fft_calc(s->fft_ctx, s->fft_result);
s->fft_result[s->fft_len] = s->fft_result[0];
+UPDATE_TIME(s->fft_time);
+
s->cqt_calc(s->cqt_result, s->fft_result, s->coeffs, s->cqt_len,
s->fft_len);
+UPDATE_TIME(s->cqt_time);
+
process_cqt(s);
-if (s->sono_h)
+UPDATE_TIME(s->process_cqt_time);
+
+if (s->sono_h) {
s->update_sono(s->sono_frame, s->c_buf, s->sono_idx);
+UPDATE_TIME(s->update_sono_time);
+}
+
if (!s->sono_count) {
AVFrame *out = *frameout = ff_get_video_buffer(outlink, outlink->w,
outlink->h);
if (!out)
return AVERROR(ENOMEM);
-if (s->bar_h)
+UPDATE_TIME(s->alloc_time);
+
+if (s->bar_h) {
s->draw_bar(out, s->h_buf, s->rcp_h_buf, s->c_buf, s->bar_h);
-if (s->axis_h)
+UPDATE_TIME(s->bar_time);
+}
+
+if (s->axis_h) {
s->draw_axis(out, s->axis_frame, s->c_buf, s->bar_h);
-if (s->sono_h)
+UPDATE_TIME(s->axis_time);
+}
+
+if (s->sono_h) {
s->draw_sono(out, s->sono_frame, s->bar_h + s->axis_h,
s->sono_idx);
+UPDATE_TIME(s->sono_time);
+}
out->pts = s->next_pts;
s->next_pts += PTS_STEP;
}
diff --git a/libavfilter/avf_showcqt.h b/libavfilter/avf_showcqt.h
index 82025b1..b945f49 100644
--- a/libavfilter/avf_showcqt.h
+++ b/libavfilter/avf_showcqt.h
@@ -79,6 +79,15 @@ typedef struct {
void(*draw_axis)(AVFrame *out, AVFrame *axis, const
ColorFloat *c, int off);
void(*draw_sono)(AVFrame *out, AVFrame *sono, int off, int
idx);
void(*update_sono)(AVFrame *sono, const ColorFloat *c, int
idx);
+/* performance debugging */
+int64_t fft_time;
+int64_t cqt_time;
+int64_t process_cqt_time;
+int64_t update_sono_time;
+int64_t alloc_time;
+int64_t bar_time;
+int64_t axis_time;
+int64_t sono_time;
/* option */
int width, height;
AVRational rate;
--
2.5.0
___
ffmpeg-devel m
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
Le quintidi 15 ventôse, an CCXXIV, Timothy Gu a écrit : > The date is considered to be "good" but perhaps not as necessary. I think the date should be present too, it is the only information that can be parsed without any previous knowledge. > - It should also be gitrevisions(7)-compatible Extra information can be added in a separate chunk: version gitrevisions-compatible (extra details) compn: the date is the date of the latest commit, not the build date. A three-years-old version will have a three-years-old latest commit. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] bitstream.c: improve init_vlc error messages.
Makes it far easier to spot the issue if e.g. caused by a typo in the code table. Signed-off-by: Reimar Döffinger --- libavcodec/bitstream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/bitstream.c b/libavcodec/bitstream.c index 1acb7a3..9344175 100644 --- a/libavcodec/bitstream.c +++ b/libavcodec/bitstream.c @@ -317,7 +317,7 @@ int ff_init_vlc_sparse(VLC *vlc_arg, int nb_bits, int nb_codes, } \ GET_DATA(buf[j].code, codes, i, codes_wrap, codes_size);\ if (buf[j].code >= (1LL
Re: [FFmpeg-devel] [PATCH] tests/gapless: add gapless aac tests
On Fri, 4 Mar 2016, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 10:46:33PM +0100, Marton Balint wrote: On Thu, 3 Mar 2016, Michael Niedermayer wrote: On Thu, Mar 03, 2016 at 02:27:52AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint --- tests/fate/gapless.mak | 3 +++ tests/ref/fate/gapless-aac | 5 + 2 files changed, 8 insertions(+) create mode 100644 tests/ref/fate/gapless-aac seems to fail on x86-32 --- ffmpeg/tests/ref/fate/gapless-aac 2016-03-03 03:06:35.306048679 +0100 +++ tests/data/fate/gapless-aac 2016-03-03 03:11:56.286055441 +0100 @@ -1,5 +1,5 @@ 9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-1 -d3c3c4ea121b3f3b8a346a168d2fec0e +d00bed4d4a83ce1addb92c075b2fcaaf 9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-2 -d3c3c4ea121b3f3b8a346a168d2fec0e +d00bed4d4a83ce1addb92c075b2fcaaf 63dd86b78c8fbd22a99bf88583256bfe *tests/data/fate/gapless-aac.out-3 Test gapless-aac failed. Look at tests/data/fate/gapless-aac.err for details. make: *** [fate-gapless-aac] Error 1 Hmm, it seems there is a tiny difference in the 145th sample of the first decoded frame. I thought this is not supposed to happen with the fixed point decoder. Anybody has any ideas? in absence of better ideas 1:pepper the code with printf() run on both x86-32 and 64 and diff to find te first difference if that explains the problem then you are done else goto 1 Okay, it seems that there are some architecture-dependant float-double rounding errors at compile time and the sinewin tables are generated at runtime, so as far as I see this will no be bitexact on all platforms... I think I'll just come up with another test which does not involve the actual data, only the frame metadata, that should be enough for checking gapless results. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
On Sat, Mar 05, 2016 at 06:38:40PM +0100, Michael Niedermayer wrote: > diff --git a/libavformat/avienc.c b/libavformat/avienc.c > index 0cfffb7..357dd34 100644 > --- a/libavformat/avienc.c > +++ b/libavformat/avienc.c > @@ -306,8 +306,7 @@ static int avi_write_header(AVFormatContext *s) > avio_wl32(pb, enc->codec_tag); > else > avio_wl32(pb, 1); > -if (enc->codec_type == AVMEDIA_TYPE_VIDEO && pb->seekable) > -avist->strh_flags_offset = avio_tell(pb); > +avist->strh_flags_offset = avio_tell(pb); > avio_wl32(pb, 0); /* flags */ > avio_wl16(pb, 0); /* priority */ > avio_wl16(pb, 0); /* language */ > @@ -369,8 +368,7 @@ static int avi_write_header(AVFormatContext *s) > && enc->pix_fmt == AV_PIX_FMT_RGB555LE > && enc->bits_per_coded_sample == 15) > enc->bits_per_coded_sample = 16; > -if (pb->seekable) > -avist->pal_offset = avio_tell(pb) + 40; > +avist->pal_offset = avio_tell(pb) + 40; > ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0); > pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi, >enc->bits_per_coded_sample); Looks fine to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: avoid double in quantize_bands.
On Wed, Mar 02, 2016 at 07:33:31PM +, Rostislav Pehlivanov wrote:
> On 1 March 2016 at 21:55, Reimar Döffinger wrote:
> > I cannot see any point whatsoever to use
> > double here instead of float.
> > Using float allows for use of SIMD.
> > ---
> > libavcodec/aacenc_utils.h | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
> > index cb5bc8d..571b1e6 100644
> > --- a/libavcodec/aacenc_utils.h
> > +++ b/libavcodec/aacenc_utils.h
> > @@ -66,10 +66,9 @@ static inline void quantize_bands(int *out, const float
> > *in, const float *scaled
> >const float rounding)
> > {
> > int i;
> > -double qc;
> > for (i = 0; i < size; i++) {
> > -qc = scaled[i] * Q34;
> > -out[i] = (int)FFMIN(qc + rounding, (double)maxval);
> > +float qc = scaled[i] * Q34;
> > +out[i] = (int)FFMIN(qc + rounding, (float)maxval);
> > if (is_signed && in[i] < 0.0f) {
> > out[i] = -out[i];
> > }
> > --
> >
>
> You could just avoid the whole need for qc and just do "FFMIN((scaled[i] *
> Q34) + rounding, (float)maxval));". We have plenty of space and I think it
> would look neater.
I don't like it much because FFMIN is a macro and I don't trust the
compiler's subexpression elimination too much...
> But up to you to decide, either way it looks good to me, doesn't change
> anything. Feel free to push if you can.
Done.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
On Sun, Mar 06, 2016 at 11:53:27AM +0100, Reimar Döffinger wrote: > On Sat, Mar 05, 2016 at 06:38:40PM +0100, Michael Niedermayer wrote: > > diff --git a/libavformat/avienc.c b/libavformat/avienc.c > > index 0cfffb7..357dd34 100644 > > --- a/libavformat/avienc.c > > +++ b/libavformat/avienc.c > > @@ -306,8 +306,7 @@ static int avi_write_header(AVFormatContext *s) > > avio_wl32(pb, enc->codec_tag); > > else > > avio_wl32(pb, 1); > > -if (enc->codec_type == AVMEDIA_TYPE_VIDEO && pb->seekable) > > -avist->strh_flags_offset = avio_tell(pb); > > +avist->strh_flags_offset = avio_tell(pb); > > avio_wl32(pb, 0); /* flags */ > > avio_wl16(pb, 0); /* priority */ > > avio_wl16(pb, 0); /* language */ > > @@ -369,8 +368,7 @@ static int avi_write_header(AVFormatContext *s) > > && enc->pix_fmt == AV_PIX_FMT_RGB555LE > > && enc->bits_per_coded_sample == 15) > > enc->bits_per_coded_sample = 16; > > -if (pb->seekable) > > -avist->pal_offset = avio_tell(pb) + 40; > > +avist->pal_offset = avio_tell(pb) + 40; > > ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0); > > pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi, > >enc->bits_per_coded_sample); > > Looks fine to me. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
On 03/06/2016 11:53 AM, Reimar Döffinger wrote: On Sat, Mar 05, 2016 at 06:38:40PM +0100, Michael Niedermayer wrote: diff --git a/libavformat/avienc.c b/libavformat/avienc.c index 0cfffb7..357dd34 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -306,8 +306,7 @@ static int avi_write_header(AVFormatContext *s) avio_wl32(pb, enc->codec_tag); else avio_wl32(pb, 1); -if (enc->codec_type == AVMEDIA_TYPE_VIDEO && pb->seekable) -avist->strh_flags_offset = avio_tell(pb); +avist->strh_flags_offset = avio_tell(pb); avio_wl32(pb, 0); /* flags */ avio_wl16(pb, 0); /* priority */ avio_wl16(pb, 0); /* language */ @@ -369,8 +368,7 @@ static int avi_write_header(AVFormatContext *s) && enc->pix_fmt == AV_PIX_FMT_RGB555LE && enc->bits_per_coded_sample == 15) enc->bits_per_coded_sample = 16; -if (pb->seekable) -avist->pal_offset = avio_tell(pb) + 40; +avist->pal_offset = avio_tell(pb) + 40; ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0); pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi, enc->bits_per_coded_sample); Looks fine to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Why aren't they needed? Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/aactab: do not use floats for constants
This may improve precision for some compilers and architectures.
Signed-off-by: Marton Balint
---
libavcodec/aactab.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavcodec/aactab.h b/libavcodec/aactab.h
index b48e7da..a0d44a2 100644
--- a/libavcodec/aactab.h
+++ b/libavcodec/aactab.h
@@ -92,8 +92,8 @@ static inline void ff_aac_tableinit(void)
* Table of the LTP coefficients
*/
static const INTFLOAT ltp_coef[8] = {
-Q30(0.570829f), Q30(0.696616f), Q30(0.813004f), Q30(0.911304f),
-Q30(0.984900f), Q30(1.067894f), Q30(1.194601f), Q30(1.369533f),
+Q30(0.570829), Q30(0.696616), Q30(0.813004), Q30(0.911304),
+Q30(0.984900), Q30(1.067894), Q30(1.194601), Q30(1.369533),
};
/* @name tns_tmp2_map
@@ -103,24 +103,24 @@ static const INTFLOAT ltp_coef[8] = {
* @{
*/
static const INTFLOAT tns_tmp2_map_1_3[4] = {
-Q31(0.f), Q31(-0.43388373f), Q31(0.64278758f), Q31(0.34202015f),
+Q31(0.), Q31(-0.43388373), Q31(0.64278758), Q31(0.34202015),
};
static const INTFLOAT tns_tmp2_map_0_3[8] = {
-Q31(0.f), Q31(-0.43388373f), Q31(-0.78183150f), Q31(-0.97492790f),
-Q31(0.98480773f), Q31( 0.86602539f), Q31( 0.64278758f), Q31( 0.34202015f),
+Q31(0.), Q31(-0.43388373), Q31(-0.78183150), Q31(-0.97492790),
+Q31(0.98480773), Q31( 0.86602539), Q31( 0.64278758), Q31( 0.34202015),
};
static const INTFLOAT tns_tmp2_map_1_4[8] = {
-Q31(0.f), Q31(-0.20791170f), Q31(-0.40673664f), Q31(-0.58778524f),
-Q31(0.67369562f), Q31( 0.52643216f), Q31( 0.36124167f), Q31( 0.18374951f),
+Q31(0.), Q31(-0.20791170), Q31(-0.40673664), Q31(-0.58778524),
+Q31(0.67369562), Q31( 0.52643216), Q31( 0.36124167), Q31( 0.18374951),
};
static const INTFLOAT tns_tmp2_map_0_4[16] = {
-Q31( 0.f), Q31(-0.20791170f), Q31(-0.40673664f), Q31(-0.58778524f),
-Q31(-0.74314481f), Q31(-0.86602539f), Q31(-0.95105654f), Q31(-0.99452192f),
-Q31( 0.99573416f), Q31( 0.96182561f), Q31( 0.89516330f), Q31( 0.79801720f),
-Q31( 0.67369562f), Q31( 0.52643216f), Q31( 0.36124167f), Q31( 0.18374951f),
+Q31( 0.), Q31(-0.20791170), Q31(-0.40673664), Q31(-0.58778524),
+Q31(-0.74314481), Q31(-0.86602539), Q31(-0.95105654), Q31(-0.99452192),
+Q31( 0.99573416), Q31( 0.96182561), Q31( 0.89516330), Q31( 0.79801720),
+Q31( 0.67369562), Q31( 0.52643216), Q31( 0.36124167), Q31( 0.18374951),
};
static const INTFLOAT * const tns_tmp2_map[4] = {
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: optimize cost cache.
On Wed, Mar 02, 2016 at 07:19:08PM +, Rostislav Pehlivanov wrote: > > -entry->cb = cb; > > -entry->rtz = rtz; > > + cb, 1.0f, INFINITY, &entry->bits, > > &entry->energy, 0); > > +*cache_state = cb; > > } > > -if (bits) > > -*bits = entry->bits; > > -if (energy) > > -*energy = entry->energy; > > +*bits = entry->bits & 0xff; > > +*energy = entry->energy; > > return entry->rd; > > } > > > > > The whole point of the function was to be a universal caching system for > every single scalefactor band which could be used in other parts of the > code (e.g. intensity stereo, mid/side, prediction, pns, etc.). Granted, > caching hasn't been implemented there yet. But by reducing the number of > arguments and assuming everything uses the same value for lambda and uplim > removes any possibility of the caching system being used anywhere outside. Which is a reason why such design considerations really should be in a comment near the relevant code, because otherwise the code as-is doesn't make any sense and looks pointlessly obfuscated to anyone reading it. That said, those changes are mostly a left-over from experiments as I couldn't figure out why the code is so slow. I can look into it, but it might be worth for someone to look more closely into how this implementation can be made more CPU-cache-efficient as I only optimized the cost of clearing but not the CPU cache hit rates when we actually have a match. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/sinewin_tablegen: use sin instead of sinf to improve precision
Signed-off-by: Marton Balint
---
libavcodec/sinewin_tablegen.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/sinewin_tablegen.h b/libavcodec/sinewin_tablegen.h
index 4432135..438cd1a 100644
--- a/libavcodec/sinewin_tablegen.h
+++ b/libavcodec/sinewin_tablegen.h
@@ -66,7 +66,7 @@ SINETABLE_CONST INTFLOAT * const
AAC_RENAME(ff_sine_windows)[] = {
av_cold void AAC_RENAME(ff_sine_window_init)(INTFLOAT *window, int n) {
int i;
for(i = 0; i < n; i++)
-window[i] = SIN_FIX(sinf((i + 0.5) * (M_PI / (2.0 * n;
+window[i] = SIN_FIX(sin((i + 0.5) * (M_PI / (2.0 * n;
}
av_cold void AAC_RENAME(ff_init_ff_sine_windows)(int index) {
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] bitstream.c: improve init_vlc error messages.
On Sun, Mar 06, 2016 at 11:46:23AM +0100, Reimar Döffinger wrote: > Makes it far easier to spot the issue if e.g. > caused by a typo in the code table. > > Signed-off-by: Reimar Döffinger > --- > libavcodec/bitstream.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] lavf/avienc: Store palette at keyframes if it differs from the global one
Michael, I've modified your patch to work with stream copy as well.
Also, I've simplified it a bit in one place. It seems to produce
identical files, but I might have missed something.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 02868156345edf572c3c3cdd3fd916e5130c607c Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 6 Mar 2016 12:21:39 +0100
Subject: [PATCH v2] lavf/avienc: Store palette at keyframes if it differs from the global one
---
libavformat/avienc.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 0cfffb7..8e0ed64 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -84,6 +84,7 @@ typedef struct AVIStream {
uint32_t palette[AVPALETTE_COUNT];
uint32_t old_palette[AVPALETTE_COUNT];
+uint32_t global_palette[AVPALETTE_COUNT];
int64_t pal_offset;
} AVIStream;
@@ -696,7 +697,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
if (ret2 < 0)
return ret2;
-if (ret2) {
+if (ret2 || (pkt->flags & AV_PKT_FLAG_KEY)) {
int pal_size = 1 << enc->bits_per_coded_sample;
int pc_tag, i;
@@ -711,9 +712,13 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
}
avio_seek(pb, cur_offset, SEEK_SET);
memcpy(avist->old_palette, avist->palette, pal_size * 4);
+memcpy(avist->global_palette, avist->palette, pal_size * 4);
avist->pal_offset = 0;
}
-if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+if (memcmp(avist->palette, avist->old_palette, pal_size * 4) ||
+(memcmp(avist->palette, avist->global_palette, pal_size * 4) &&
+(pkt->flags & AV_PKT_FLAG_KEY))
+) {
avi_stream2fourcc(tag, stream_index, enc->codec_type);
tag[2] = 'p'; tag[3] = 'c';
pc_tag = ff_start_tag(pb, tag);
--
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/aactab: do not use floats for constants
On Sun, Mar 06, 2016 at 12:18:48PM +0100, Marton Balint wrote:
> This may improve precision for some compilers and architectures.
>
> Signed-off-by: Marton Balint
> ---
> libavcodec/aactab.h | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/aactab.h b/libavcodec/aactab.h
> index b48e7da..a0d44a2 100644
> --- a/libavcodec/aactab.h
> +++ b/libavcodec/aactab.h
> @@ -92,8 +92,8 @@ static inline void ff_aac_tableinit(void)
> * Table of the LTP coefficients
> */
> static const INTFLOAT ltp_coef[8] = {
> -Q30(0.570829f), Q30(0.696616f), Q30(0.813004f), Q30(0.911304f),
> -Q30(0.984900f), Q30(1.067894f), Q30(1.194601f), Q30(1.369533f),
> +Q30(0.570829), Q30(0.696616), Q30(0.813004), Q30(0.911304),
> +Q30(0.984900), Q30(1.067894), Q30(1.194601), Q30(1.369533),
I haven't tested it, but you might need to add a cast then
to the float variant (or have the macro append the f).
Some compilers don't like when you initialize a float variable
with a value not representable as float.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] bitstream.c: improve init_vlc error messages.
On Sun, Mar 06, 2016 at 12:21:30PM +0100, Michael Niedermayer wrote: > On Sun, Mar 06, 2016 at 11:46:23AM +0100, Reimar Döffinger wrote: > > Makes it far easier to spot the issue if e.g. > > caused by a typo in the code table. > > > > Signed-off-by: Reimar Döffinger > > --- > > libavcodec/bitstream.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > LGTM Thanks, pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] lavf/avienc: Store palette at keyframes if it differs from the global one
Minor fix.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 10faea5eccb02a6e971b6733412d3c41a6d46f5f Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 6 Mar 2016 12:41:07 +0100
Subject: [PATCH v3] lavf/avienc: Store palette at keyframes if it differs from the global one
---
libavformat/avienc.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 0cfffb7..937303e 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -84,6 +84,7 @@ typedef struct AVIStream {
uint32_t palette[AVPALETTE_COUNT];
uint32_t old_palette[AVPALETTE_COUNT];
+uint32_t global_palette[AVPALETTE_COUNT];
int64_t pal_offset;
} AVIStream;
@@ -696,7 +697,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
if (ret2 < 0)
return ret2;
-if (ret2) {
+if (ret2 || ((pkt->flags & AV_PKT_FLAG_KEY) && !avist->pal_offset)) {
int pal_size = 1 << enc->bits_per_coded_sample;
int pc_tag, i;
@@ -711,9 +712,13 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
}
avio_seek(pb, cur_offset, SEEK_SET);
memcpy(avist->old_palette, avist->palette, pal_size * 4);
+memcpy(avist->global_palette, avist->palette, pal_size * 4);
avist->pal_offset = 0;
}
-if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+if (memcmp(avist->palette, avist->old_palette, pal_size * 4) ||
+(memcmp(avist->palette, avist->global_palette, pal_size * 4) &&
+(pkt->flags & AV_PKT_FLAG_KEY))
+) {
avi_stream2fourcc(tag, stream_index, enc->codec_type);
tag[2] = 'p'; tag[3] = 'c';
pc_tag = ff_start_tag(pb, tag);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
On 03/06/2016 12:09 PM, Michael Niedermayer wrote: Once again, why are these tests unneeded? Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
On 03/06/2016 12:51 PM, Mats Peterson wrote: On 03/06/2016 12:09 PM, Michael Niedermayer wrote: Once again, why are these tests unneeded? Mats avio_tell() won't work on an unseekable stream, since it uses avio_seek(), as far as I know. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: treat quant_cof as a signed value
On Sun, Mar 06, 2016 at 09:00:47AM +0100, Paul B Mahol wrote:
> On 3/5/16, Umair Khan wrote:
> > Signed-off-by: Umair Khan
> > ---
> > libavcodec/alsdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
> > index ebd364e..0043512 100644
> > --- a/libavcodec/alsdec.c
> > +++ b/libavcodec/alsdec.c
> > @@ -729,7 +729,7 @@ static int read_var_block_data(ALSDecContext *ctx,
> > ALSBlockData *bd)
> > quant_cof[k] = decode_rice(gb, rice_param) + offset;
> > if (quant_cof[k] < -64 || quant_cof[k] > 63) {
> > av_log(avctx, AV_LOG_ERROR,
> > - "quant_cof %"PRIu32" is out of range.\n",
> > + "quant_cof %"PRId32" is out of range.\n",
> > quant_cof[k]);
> > return AVERROR_INVALIDDATA;
> > }
> > --
> > 2.5.0
>
> LGTM
applied
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] Support seek in encrypted MP4
Ping Thanks Eran 0001-mov-support-seek-in-encrypted-mp4.patch Description: 0001-mov-support-seek-in-encrypted-mp4.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 1/2] avcodec/aactab: do not use floats for constants
This may improve the precision of the fixed point decoder for some compilers
and architectures.
Signed-off-by: Marton Balint
---
libavcodec/aac_defines.h | 6 +++---
libavcodec/aactab.h | 22 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavcodec/aac_defines.h b/libavcodec/aac_defines.h
index eff63b3..c12dc2f 100644
--- a/libavcodec/aac_defines.h
+++ b/libavcodec/aac_defines.h
@@ -89,9 +89,9 @@ typedef float AAC_FLOAT;
typedef unsignedAAC_SIGNE;
#define FIXR(x) ((float)(x))
#define FIXR10(x) ((float)(x))
-#define Q23(x) x
-#define Q30(x) x
-#define Q31(x) x
+#define Q23(x) ((float)(x))
+#define Q30(x) ((float)(x))
+#define Q31(x) ((float)(x))
#define RANGE15(x) (32768.0 * (x))
#define GET_GAIN(x, y) powf((x), -(y))
#define AAC_MUL16(x, y) ((x) * (y))
diff --git a/libavcodec/aactab.h b/libavcodec/aactab.h
index b48e7da..a0d44a2 100644
--- a/libavcodec/aactab.h
+++ b/libavcodec/aactab.h
@@ -92,8 +92,8 @@ static inline void ff_aac_tableinit(void)
* Table of the LTP coefficients
*/
static const INTFLOAT ltp_coef[8] = {
-Q30(0.570829f), Q30(0.696616f), Q30(0.813004f), Q30(0.911304f),
-Q30(0.984900f), Q30(1.067894f), Q30(1.194601f), Q30(1.369533f),
+Q30(0.570829), Q30(0.696616), Q30(0.813004), Q30(0.911304),
+Q30(0.984900), Q30(1.067894), Q30(1.194601), Q30(1.369533),
};
/* @name tns_tmp2_map
@@ -103,24 +103,24 @@ static const INTFLOAT ltp_coef[8] = {
* @{
*/
static const INTFLOAT tns_tmp2_map_1_3[4] = {
-Q31(0.f), Q31(-0.43388373f), Q31(0.64278758f), Q31(0.34202015f),
+Q31(0.), Q31(-0.43388373), Q31(0.64278758), Q31(0.34202015),
};
static const INTFLOAT tns_tmp2_map_0_3[8] = {
-Q31(0.f), Q31(-0.43388373f), Q31(-0.78183150f), Q31(-0.97492790f),
-Q31(0.98480773f), Q31( 0.86602539f), Q31( 0.64278758f), Q31( 0.34202015f),
+Q31(0.), Q31(-0.43388373), Q31(-0.78183150), Q31(-0.97492790),
+Q31(0.98480773), Q31( 0.86602539), Q31( 0.64278758), Q31( 0.34202015),
};
static const INTFLOAT tns_tmp2_map_1_4[8] = {
-Q31(0.f), Q31(-0.20791170f), Q31(-0.40673664f), Q31(-0.58778524f),
-Q31(0.67369562f), Q31( 0.52643216f), Q31( 0.36124167f), Q31( 0.18374951f),
+Q31(0.), Q31(-0.20791170), Q31(-0.40673664), Q31(-0.58778524),
+Q31(0.67369562), Q31( 0.52643216), Q31( 0.36124167), Q31( 0.18374951),
};
static const INTFLOAT tns_tmp2_map_0_4[16] = {
-Q31( 0.f), Q31(-0.20791170f), Q31(-0.40673664f), Q31(-0.58778524f),
-Q31(-0.74314481f), Q31(-0.86602539f), Q31(-0.95105654f), Q31(-0.99452192f),
-Q31( 0.99573416f), Q31( 0.96182561f), Q31( 0.89516330f), Q31( 0.79801720f),
-Q31( 0.67369562f), Q31( 0.52643216f), Q31( 0.36124167f), Q31( 0.18374951f),
+Q31( 0.), Q31(-0.20791170), Q31(-0.40673664), Q31(-0.58778524),
+Q31(-0.74314481), Q31(-0.86602539), Q31(-0.95105654), Q31(-0.99452192),
+Q31( 0.99573416), Q31( 0.96182561), Q31( 0.89516330), Q31( 0.79801720),
+Q31( 0.67369562), Q31( 0.52643216), Q31( 0.36124167), Q31( 0.18374951),
};
static const INTFLOAT * const tns_tmp2_map[4] = {
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
On 03/06/2016 12:55 PM, Mats Peterson wrote: On 03/06/2016 12:51 PM, Mats Peterson wrote: On 03/06/2016 12:09 PM, Michael Niedermayer wrote: Once again, why are these tests unneeded? Mats avio_tell() won't work on an unseekable stream, since it uses avio_seek(), as far as I know. Mats In that respect (that it won't work on an unseekable stream), it's similar to ftell(). Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
Hi Mats, On Sun, Mar 6, 2016 at 6:51 AM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: > On 03/06/2016 12:09 PM, Michael Niedermayer wrote: > > Once again, why are these tests unneeded? You shouldn't send the same message 5x within 2 seconds. Please be patient. Why are they unneeded? Imagine this situation: int a; if (condition) a = create_a(); [..] if (condition) do_something_with_a(a); versus: int a = create_a(); [..] if (condition) do_something_with_a(a); Oddly, both codes do exactly the same thing, assuming they don't change global state. In this case, avio_tell() shouldn't change global state, that is, we're assuming that it will not cause bitstream corruption simply because it's unseekable, which is a fair assumption. On the positive side, with that assumption, code fragment #2 is much simpler than #1, which is why the patch is net positive. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
On Sun, Mar 06, 2016 at 01:15:33PM +0100, Mats Peterson wrote: > On 03/06/2016 12:55 PM, Mats Peterson wrote: > >On 03/06/2016 12:51 PM, Mats Peterson wrote: > >>On 03/06/2016 12:09 PM, Michael Niedermayer wrote: > >> > >>Once again, why are these tests unneeded? > >> > >>Mats > >> > > > >avio_tell() won't work on an unseekable stream, since it uses > >avio_seek(), as far as I know. > > In that respect (that it won't work on an unseekable stream), it's similar > to ftell(). First, it doesn't fail as there is no reason for it to fail. Unseekable doesn't mean a avio_seek will fail on principle, that would be pointlessly constraint, it just means it can and in certain cases is likely to fail. As the result isn't used it doesn't matter whether it fails anyway though, as long as it is guaranteed to not corrupt stream state, which it is. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
On 03/06/2016 01:29 PM, Ronald S. Bultje wrote: Hi Mats, On Sun, Mar 6, 2016 at 6:51 AM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: On 03/06/2016 12:09 PM, Michael Niedermayer wrote: Once again, why are these tests unneeded? You shouldn't send the same message 5x within 2 seconds. Please be patient. Why are they unneeded? Imagine this situation: int a; if (condition) a = create_a(); [..] if (condition) do_something_with_a(a); versus: int a = create_a(); [..] if (condition) do_something_with_a(a); Oddly, both codes do exactly the same thing, assuming they don't change global state. In this case, avio_tell() shouldn't change global state, that is, we're assuming that it will not cause bitstream corruption simply because it's unseekable, which is a fair assumption. On the positive side, with that assumption, code fragment #2 is much simpler than #1, which is why the patch is net positive. Ronald ___ ffmpeg-devel mailing list Well, that part I understand. It's for simplification purposes. By the way, I just noticed that avio_tell() (and avio_seek() will work on stdout as well. That's the part I *don't* understand: How can they work on an "officially" unseekable stream like stdout, when ftell() and lseek() won't? Is it due to the buffering in FFmpeg? And where's the limit where a normally "unseekable stream" like stdout is no longer seekable with avio_seek()? Hope you understand what I mean. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4] lavf/avienc: Store palette at keyframes if it differs from the global one
Another fix for non-seekable streams. Once again, Michael, this is your
patch modified to work with stream copy.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From cdbb72a0ef1f061b32f56dd390584db4122ec84b Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 6 Mar 2016 14:04:57 +0100
Subject: [PATCH v4] lavf/avienc: Store palette at keyframes if it differs from the global palette
---
libavformat/avienc.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 357dd34..d67dc4f 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -84,6 +84,7 @@ typedef struct AVIStream {
uint32_t palette[AVPALETTE_COUNT];
uint32_t old_palette[AVPALETTE_COUNT];
+uint32_t global_palette[AVPALETTE_COUNT];
int64_t pal_offset;
} AVIStream;
@@ -694,7 +695,9 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
if (ret2 < 0)
return ret2;
-if (ret2) {
+if (ret2 || ((pkt->flags & AV_PKT_FLAG_KEY) &&
+ (!avist->pal_offset || !pb->seekable))
+) {
int pal_size = 1 << enc->bits_per_coded_sample;
int pc_tag, i;
@@ -709,9 +712,13 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
}
avio_seek(pb, cur_offset, SEEK_SET);
memcpy(avist->old_palette, avist->palette, pal_size * 4);
+memcpy(avist->global_palette, avist->palette, pal_size * 4);
avist->pal_offset = 0;
}
-if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+if (memcmp(avist->palette, avist->old_palette, pal_size * 4) ||
+(memcmp(avist->palette, avist->global_palette, pal_size * 4) &&
+(pkt->flags & AV_PKT_FLAG_KEY))
+) {
avi_stream2fourcc(tag, stream_index, enc->codec_type);
tag[2] = 'p'; tag[3] = 'c';
pc_tag = ff_start_tag(pb, tag);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] lavf/avienc: Store palette at keyframes if it differs from the global one
On 03/06/2016 02:07 PM, Mats Peterson wrote: Another fix for non-seekable streams. Once again, Michael, this is your patch modified to work with stream copy. Mats Now, *seeking* in AVI files with xxpc chunks (at least with FFplay) still leaves a lot to be desired. It only works so-so. Are xxpc chunks supported in MPlayer yet? I haven't done any checkout in some days. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
Hi, On Sun, Mar 6, 2016 at 7:37 AM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: > On 03/06/2016 01:29 PM, Ronald S. Bultje wrote: > >> Hi Mats, >> >> On Sun, Mar 6, 2016 at 6:51 AM, Mats Peterson < >> matsp888-at-yahoo@ffmpeg.org> wrote: >> >> On 03/06/2016 12:09 PM, Michael Niedermayer wrote: >>> >>> Once again, why are these tests unneeded? >>> >> >> >> You shouldn't send the same message 5x within 2 seconds. Please be >> patient. >> >> Why are they unneeded? Imagine this situation: >> >> >> int a; >> >> if (condition) >> a = create_a(); >> >> [..] >> >> if (condition) >> do_something_with_a(a); >> >> >> versus: >> >> >> int a = create_a(); >> >> [..] >> >> if (condition) >> do_something_with_a(a); >> >> >> Oddly, both codes do exactly the same thing, assuming they don't change >> global state. In this case, avio_tell() shouldn't change global state, >> that >> is, we're assuming that it will not cause bitstream corruption simply >> because it's unseekable, which is a fair assumption. >> >> On the positive side, with that assumption, code fragment #2 is much >> simpler than #1, which is why the patch is net positive. >> >> Ronald >> ___ >> ffmpeg-devel mailing list >> > > > Well, that part I understand. It's for simplification purposes. > > By the way, I just noticed that avio_tell() (and avio_seek() will work on > stdout as well. That's the part I *don't* understand: How can they work on > an "officially" unseekable stream like stdout, when ftell() and lseek() > won't? Is it due to the buffering in FFmpeg? And where's the limit where a > normally "unseekable stream" like stdout is no longer seekable with > avio_seek()? Hope you understand what I mean. See the implementation [1]. If not seekable, and the seek is forward, it fills buffer until it reaches that position. If not seekable and seek is backward but fits in buffer, it works as expected by changing buffer index. Etc. See also avio_tell [2]. Line 230 of avio_seek tells you the shortcut that makes this all work without calls to fseek/ftell. Ronald [1] https://ffmpeg.org/doxygen/trunk/aviobuf_8c_source.html#l00209 [2] https://ffmpeg.org/doxygen/trunk/avio_8h_source.html#l00447 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests
"Ronald S. Bultje" skrev: (6 mars 2016 14:37:25 CET) >Hi, > >On Sun, Mar 6, 2016 at 7:37 AM, Mats Peterson < >matsp888-at-yahoo@ffmpeg.org> wrote: > >> On 03/06/2016 01:29 PM, Ronald S. Bultje wrote: >> >>> Hi Mats, >>> >>> On Sun, Mar 6, 2016 at 6:51 AM, Mats Peterson < >>> matsp888-at-yahoo@ffmpeg.org> wrote: >>> >>> On 03/06/2016 12:09 PM, Michael Niedermayer wrote: Once again, why are these tests unneeded? >>> >>> >>> You shouldn't send the same message 5x within 2 seconds. Please be >>> patient. >>> >>> Why are they unneeded? Imagine this situation: >>> >>> >>> int a; >>> >>> if (condition) >>> a = create_a(); >>> >>> [..] >>> >>> if (condition) >>> do_something_with_a(a); >>> >>> >>> versus: >>> >>> >>> int a = create_a(); >>> >>> [..] >>> >>> if (condition) >>> do_something_with_a(a); >>> >>> >>> Oddly, both codes do exactly the same thing, assuming they don't >change >>> global state. In this case, avio_tell() shouldn't change global >state, >>> that >>> is, we're assuming that it will not cause bitstream corruption >simply >>> because it's unseekable, which is a fair assumption. >>> >>> On the positive side, with that assumption, code fragment #2 is much >>> simpler than #1, which is why the patch is net positive. >>> >>> Ronald >>> ___ >>> ffmpeg-devel mailing list >>> >> >> >> Well, that part I understand. It's for simplification purposes. >> >> By the way, I just noticed that avio_tell() (and avio_seek() will >work on >> stdout as well. That's the part I *don't* understand: How can they >work on >> an "officially" unseekable stream like stdout, when ftell() and >lseek() >> won't? Is it due to the buffering in FFmpeg? And where's the limit >where a >> normally "unseekable stream" like stdout is no longer seekable with >> avio_seek()? Hope you understand what I mean. > > >See the implementation [1]. If not seekable, and the seek is forward, >it >fills buffer until it reaches that position. If not seekable and seek >is >backward but fits in buffer, it works as expected by changing buffer >index. >Etc. See also avio_tell [2]. Line 230 of avio_seek tells you the >shortcut >that makes this all work without calls to fseek/ftell. > >Ronald > >[1] https://ffmpeg.org/doxygen/trunk/aviobuf_8c_source.html#l00209 >[2] https://ffmpeg.org/doxygen/trunk/avio_8h_source.html#l00447 >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel OK, thanks. -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC] proof-of-concept minimal inflate.
Hi, On Sat, Mar 5, 2016 at 5:34 PM, Reimar Döffinger wrote: > FFmpeg currently lacks a fallback inflate algorithm > when zlib is not available. > This wouldn't be the first time we NIH'ed something, so that by itself isn't a sufficiently good reason to not use it :) We have a lot of infrastructure for it already available > though, like VLC code reading (though only in libavcodec, > not libavutil). > This is a hackish quick-and-dirty version. > It certainly is not optimized, and I would want it to > be mostly small/simple, not necessarily fast anyway > as it would at most be a fallback. > Is there interest in me cleaning up the code and > integrating it as fallback, or are you all happy > with zlib and I should drop it? Well, you skim over performance, it'd be nice to get some figures of how much faster/slower it is. Binary size may also be a factor in some situations (if zlib is included static). How often is zlib not available? I mean, afaik, it's even present on MSVC builds or iPhone/Android builds. I think we sort of have to quantify how much of an issue this really is. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v5] lavf/avienc: Store palette in keyframes if it differs from the global one
Restored your code at the place where I had "simplified it". It's
obviously needed.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From fdc1b9d1c22417993a1295fc10904901d2a1269a Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 6 Mar 2016 14:54:30 +0100
Subject: [PATCH v5] lavf/avienc: Store palette in keyframes if it differs from the global one
---
libavformat/avienc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 357dd34..d120a6c 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -84,6 +84,7 @@ typedef struct AVIStream {
uint32_t palette[AVPALETTE_COUNT];
uint32_t old_palette[AVPALETTE_COUNT];
+uint32_t global_palette[AVPALETTE_COUNT];
int64_t pal_offset;
} AVIStream;
@@ -694,7 +695,9 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
if (ret2 < 0)
return ret2;
-if (ret2) {
+if (ret2 || ((pkt->flags & AV_PKT_FLAG_KEY) &&
+ (!avist->pal_offset || !pb->seekable))
+) {
int pal_size = 1 << enc->bits_per_coded_sample;
int pc_tag, i;
@@ -709,9 +712,15 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
}
avio_seek(pb, cur_offset, SEEK_SET);
memcpy(avist->old_palette, avist->palette, pal_size * 4);
+memcpy(avist->global_palette, avist->palette, pal_size * 4);
avist->pal_offset = 0;
}
-if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+if (memcmp(avist->palette, avist->old_palette, pal_size * 4) ||
+(memcmp(avist->palette, avist->global_palette, pal_size * 4) ||
+ avist->strh_flags_offset == 0 ||
+ !pb->seekable
+) && (pkt->flags & AV_PKT_FLAG_KEY)
+) {
avi_stream2fourcc(tag, stream_index, enc->codec_type);
tag[2] = 'p'; tag[3] = 'c';
pc_tag = ff_start_tag(pb, tag);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC] proof-of-concept minimal inflate.
On Sun, Mar 06, 2016 at 08:43:15AM -0500, Ronald S. Bultje wrote: > Hi, > > On Sat, Mar 5, 2016 at 5:34 PM, Reimar Döffinger > wrote: > > > FFmpeg currently lacks a fallback inflate algorithm > > when zlib is not available. > > > > This wouldn't be the first time we NIH'ed something, so that by itself > isn't a sufficiently good reason to not use it :) > > We have a lot of infrastructure for it already available > > though, like VLC code reading (though only in libavcodec, > > not libavutil). > > This is a hackish quick-and-dirty version. > > It certainly is not optimized, and I would want it to > > be mostly small/simple, not necessarily fast anyway > > as it would at most be a fallback. > > Is there interest in me cleaning up the code and > > integrating it as fallback, or are you all happy > > with zlib and I should drop it? > > > Well, you skim over performance, it'd be nice to get some figures of how > much faster/slower it is. Binary size may also be a factor in some > situations (if zlib is included static). > > How often is zlib not available? I mean, afaik, it's even present on MSVC > builds or iPhone/Android builds. I think we sort of have to quantify how > much of an issue this really is. its probably missing in some self made cross build/testing environments. having our own should mean that some fate clients could test more code also there was at least one case with some memory debugger where i had to rebuild zlib to use it, i dont remember which that was though [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5] lavf/avienc: Store palette in keyframes if it differs from the global one
Mats Peterson skrev: (6 mars 2016 14:56:04 CET) >Restored your code at the place where I had "simplified it". It's >obviously needed. A question: Do we need to add keyframe xxpc chunks when doing stream copy? It would be semantically wrong in a way. I'm ambivalent about it. If this is not needed, we might as well use your original patch. -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC] proof-of-concept minimal inflate.
On Sun, Mar 06, 2016 at 08:43:15AM -0500, Ronald S. Bultje wrote: > We have a lot of infrastructure for it already available > > though, like VLC code reading (though only in libavcodec, > > not libavutil). > > This is a hackish quick-and-dirty version. > > It certainly is not optimized, and I would want it to > > be mostly small/simple, not necessarily fast anyway > > as it would at most be a fallback. > > Is there interest in me cleaning up the code and > > integrating it as fallback, or are you all happy > > with zlib and I should drop it? > > Well, you skim over performance, it'd be nice to get some figures of how > much faster/slower it is. Binary size may also be a factor in some > situations (if zlib is included static). Problem with performance is that to be honest gzip is so simple it's not trivial to measure. When I tried I got about 160 MB/s (compressed side). Which probably is like 1/4th of the speed of zlib. But it will very strongly depend on content. It could be optimized by using the GET_VLC macro instead of get_vlc2, which is quite inefficient for long stretches of purely Huffman coded symbols. It's not so slow it should cause actual problems though IMO... As to size, it is 6 to 9 kB (depends on -Os vs. -O3), but as said depends on the FFmpeg bitstream infrastructure. For zlib, the absolute minimum would be inflate.o (18kB) and probably a few others like inftrees.o (4 kB). Might be up to 40 kB, expect I'd have to actually write a test program to be sure what is needed or not. > How often is zlib not available? I mean, afaik, it's even present on MSVC > builds or iPhone/Android builds. I think we sort of have to quantify how > much of an issue this really is. What do you mean by "present"? Yes, you can compile zlib for almost anything. It's not a real issue in that way. It doesn't follow along with MSVC though, but is part of Android NDK. For me it's mostly a pain when cross-compiling for qemu-user, whether ARM (not Android), PPC, ... when I have to either compile and munge in zlib or I can't even run the png FATE tests (and surprisingly many others)... While it's only a fallback it won't help for that, but I am also every time annoyed by zlib's lack of const-correctness and simple API (it only has the stream based thing, and needs at least 3 calls to decompress anything, and don't ask me about that alloc/free interface magic we are doing in our png decoder, I could not find documentation why we're doing that). Then there is also the academic interest in writing inflate in terms compatible with FFmpeg's bitstream primitives. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Support seek in encrypted MP4
On Sun, Mar 06, 2016 at 12:07:37PM +, Eran Kornblau wrote: > Ping > > Thanks > > Eran > isom.h |3 ++ > mov.c | 94 > + > 2 files changed, 97 insertions(+) > 395b2cf334ec76f21376f52709b5a9caeeb39d9d > 0001-mov-support-seek-in-encrypted-mp4.patch > From 769c0ad4369051157e7151c1b6d8d382d8bca9bb Mon Sep 17 00:00:00 2001 > From: erankor > Date: Mon, 22 Feb 2016 16:41:06 +0200 > Subject: [PATCH] mov - support seek in encrypted mp4 applied can you create a fate test for this ? maybe seek-test could be simply used? thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacenc: use generational cache instead of resetting.
Approximately 11% faster transcoding from mp3 with
default settings.
Signed-off-by: Reimar Döffinger
---
libavcodec/aacenc.c | 9 -
libavcodec/aacenc.h | 5 +++--
libavcodec/aacenc_quantization_misc.h | 3 ++-
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 5a70da1..023260a 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -78,11 +78,10 @@ static void put_audio_specific_config(AVCodecContext *avctx)
void ff_quantize_band_cost_cache_init(struct AACEncContext *s)
{
-int sf, g;
-for (sf = 0; sf < 256; sf++) {
-for (g = 0; g < 128; g++) {
-s->quantize_band_cost_cache[sf][g].bits = -1;
-}
+++s->quantize_band_cost_cache_generation;
+if (s->quantize_band_cost_cache_generation == 0) {
+memset(s->quantize_band_cost_cache, 0,
sizeof(s->quantize_band_cost_cache));
+s->quantize_band_cost_cache_generation = 1;
}
}
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 2252e29..63e7893 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -84,10 +84,10 @@ extern AACCoefficientsEncoder ff_aac_coders[];
typedef struct AACQuantizeBandCostCacheEntry {
float rd;
float energy;
-int bits; ///< -1 means uninitialized entry
+int bits;
char cb;
char rtz;
-char padding[2]; ///< Keeps the entry size a multiple of 32 bits
+uint16_t generation;
} AACQuantizeBandCostCacheEntry;
/**
@@ -126,6 +126,7 @@ typedef struct AACEncContext {
DECLARE_ALIGNED(16, int, qcoefs)[96]; ///< quantized coefficients
DECLARE_ALIGNED(32, float, scoefs)[1024];///< scaled coefficients
+uint16_t quantize_band_cost_cache_generation;
AACQuantizeBandCostCacheEntry quantize_band_cost_cache[256][128]; ///<
memoization area for quantize_band_cost
struct {
diff --git a/libavcodec/aacenc_quantization_misc.h
b/libavcodec/aacenc_quantization_misc.h
index eaa71c9..28676ca 100644
--- a/libavcodec/aacenc_quantization_misc.h
+++ b/libavcodec/aacenc_quantization_misc.h
@@ -36,11 +36,12 @@ static inline float quantize_band_cost_cached(struct
AACEncContext *s, int w, in
AACQuantizeBandCostCacheEntry *entry;
av_assert1(scale_idx >= 0 && scale_idx < 256);
entry = &s->quantize_band_cost_cache[scale_idx][w*16+g];
-if (entry->bits < 0 || entry->cb != cb || entry->rtz != rtz) {
+if (entry->generation != s->quantize_band_cost_cache_generation ||
entry->cb != cb || entry->rtz != rtz) {
entry->rd = quantize_band_cost(s, in, scaled, size, scale_idx,
cb, lambda, uplim, &entry->bits,
&entry->energy, rtz);
entry->cb = cb;
entry->rtz = rtz;
+entry->generation = s->quantize_band_cost_cache_generation;
}
if (bits)
*bits = entry->bits;
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/dca: clear X96 channels if nothing was decoded
On Wed, Mar 02, 2016 at 10:31:10PM +0300, foo86 wrote: > The first X96 channel set can have more channels than core, causing X96 > decoding to be skipped. Clear the number of decoded X96 channels to zero > in this rudimentary case. > --- > libavcodec/dca_core.c | 1 + > 1 file changed, 1 insertion(+) applied thanks PS: for anything that can be tested with a small input file, you can add a test to fate, ican upload any needed sample to the fatesamples [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
Approximately 10% faster transcode from mp3 to aac
with default settings.
Signed-off-by: Reimar Döffinger
---
libavcodec/aacenc_utils.h | 47 ++-
1 file changed, 38 insertions(+), 9 deletions(-)
diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
index b9bd6bf..1639021 100644
--- a/libavcodec/aacenc_utils.h
+++ b/libavcodec/aacenc_utils.h
@@ -36,15 +36,29 @@
#define ROUND_TO_ZERO 0.1054f
#define C_QUANT 0.4054f
+#define ABSPOW(inv, outv) \
+do { \
+float a = (inv); \
+a = fabsf(a); \
+(outv) = sqrtf(a * sqrtf(a)); \
+} while(0)
+
static inline void abs_pow34_v(float *out, const float *in, const int size)
{
int i;
-for (i = 0; i < size; i++) {
-float a = fabsf(in[i]);
-out[i] = sqrtf(a * sqrtf(a));
+for (i = 0; i < size - 3; i += 4) {
+ABSPOW(in[i], out[i]);
+ABSPOW(in[i+1], out[i+1]);
+ABSPOW(in[i+2], out[i+2]);
+ABSPOW(in[i+3], out[i+3]);
+}
+for (; i < size; i++) {
+ABSPOW(in[i], out[i]);
}
}
+#undef ABSPOW
+
static inline float pos_pow34(float a)
{
return sqrtf(a * sqrtf(a));
@@ -61,20 +75,35 @@ static inline int quant(float coef, const float Q, const
float rounding)
return sqrtf(a * sqrtf(a)) + rounding;
}
+
+#define Q(scv, inv, outv) \
+do { \
+float qc = (scv) * Q34; \
+int tmp = (int)FFMIN(qc + rounding, (float)maxval); \
+if (is_signed && (inv) < 0.0f) { \
+tmp = -tmp; \
+} \
+(outv) = tmp; \
+} while(0)
+
static inline void quantize_bands(int *out, const float *in, const float
*scaled,
int size, float Q34, int is_signed, int
maxval,
const float rounding)
{
int i;
-for (i = 0; i < size; i++) {
-float qc = scaled[i] * Q34;
-out[i] = (int)FFMIN(qc + rounding, (float)maxval);
-if (is_signed && in[i] < 0.0f) {
-out[i] = -out[i];
-}
+for (i = 0; i < size - 3; i += 4) {
+Q(scaled[i], in[i], out[i]);
+Q(scaled[i+1], in[i+1], out[i+1]);
+Q(scaled[i+2], in[i+2], out[i+2]);
+Q(scaled[i+3], in[i+3], out[i+3]);
+}
+for (; i < size; i++) {
+Q(scaled[i], in[i], out[i]);
}
}
+#undef Q
+
static inline float find_max_val(int group_len, int swb_size, const float
*scaled)
{
float maxval = 0.0f;
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
On Sun, Mar 06, 2016 at 07:35:58PM +0100, Reimar Döffinger wrote: > Approximately 10% faster transcode from mp3 to aac > with default settings. Note to anyone wanting to optimize it further: There is almost 25% on the table if you can replace the pow() and cos() function uses by something more efficient. Unfortunately that won't be possible to do without changing the output at least a bit, so I don't dare to do it, plus one option, accessing the approximations that may be available as CPU instructions, might not be possible without using assembler. Beyond that, optimizations would probably have to attack search_for_quantizers_twoloop in a way that makes it lower quality but faster (it stands for another 25%, not including subfunctions it calls). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
On 3/6/2016 3:35 PM, Reimar Döffinger wrote:
> Approximately 10% faster transcode from mp3 to aac
> with default settings.
>
> Signed-off-by: Reimar Döffinger
> ---
> libavcodec/aacenc_utils.h | 47
> ++-
> 1 file changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
> index b9bd6bf..1639021 100644
> --- a/libavcodec/aacenc_utils.h
> +++ b/libavcodec/aacenc_utils.h
> @@ -36,15 +36,29 @@
> #define ROUND_TO_ZERO 0.1054f
> #define C_QUANT 0.4054f
>
> +#define ABSPOW(inv, outv) \
> +do { \
> +float a = (inv); \
> +a = fabsf(a); \
> +(outv) = sqrtf(a * sqrtf(a)); \
> +} while(0)
> +
> static inline void abs_pow34_v(float *out, const float *in, const int size)
> {
> int i;
> -for (i = 0; i < size; i++) {
> -float a = fabsf(in[i]);
> -out[i] = sqrtf(a * sqrtf(a));
> +for (i = 0; i < size - 3; i += 4) {
> +ABSPOW(in[i], out[i]);
> +ABSPOW(in[i+1], out[i+1]);
> +ABSPOW(in[i+2], out[i+2]);
> +ABSPOW(in[i+3], out[i+3]);
> +}
Are you sure this wasn't vectorized already? I remember i checked and it mostly
was, at least on gcc 5.3 mingw-w64 with default settings.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
On Sun, Mar 06, 2016 at 03:49:00PM -0300, James Almer wrote:
> On 3/6/2016 3:35 PM, Reimar Döffinger wrote:
> > Approximately 10% faster transcode from mp3 to aac
> > with default settings.
> >
> > Signed-off-by: Reimar Döffinger
> > ---
> > libavcodec/aacenc_utils.h | 47
> > ++-
> > 1 file changed, 38 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
> > index b9bd6bf..1639021 100644
> > --- a/libavcodec/aacenc_utils.h
> > +++ b/libavcodec/aacenc_utils.h
> > @@ -36,15 +36,29 @@
> > #define ROUND_TO_ZERO 0.1054f
> > #define C_QUANT 0.4054f
> >
> > +#define ABSPOW(inv, outv) \
> > +do { \
> > +float a = (inv); \
> > +a = fabsf(a); \
> > +(outv) = sqrtf(a * sqrtf(a)); \
> > +} while(0)
> > +
> > static inline void abs_pow34_v(float *out, const float *in, const int size)
> > {
> > int i;
> > -for (i = 0; i < size; i++) {
> > -float a = fabsf(in[i]);
> > -out[i] = sqrtf(a * sqrtf(a));
> > +for (i = 0; i < size - 3; i += 4) {
> > +ABSPOW(in[i], out[i]);
> > +ABSPOW(in[i+1], out[i+1]);
> > +ABSPOW(in[i+2], out[i+2]);
> > +ABSPOW(in[i+3], out[i+3]);
> > +}
>
> Are you sure this wasn't vectorized already? I remember i checked and it
> mostly
> was, at least on gcc 5.3 mingw-w64 with default settings.
Then it would hardly get 10% faster, would it (though
I admit I didn't test the two parts separately)?
But I am fairly sure that before the patch it only
used sqrtss instructions and not sqrtps.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add tests for functions in hash.c
Please review the patch. NagaChaitanya Vellanki (1): Add tests for functions in hash.c libavutil/Makefile | 1 + libavutil/hash.c | 41 + tests/fate/libavutil.mak | 4 tests/ref/fate/hash | 45 + 4 files changed, 91 insertions(+) create mode 100644 tests/ref/fate/hash -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add tests for functions in hash.c
---
libavutil/Makefile | 1 +
libavutil/hash.c | 41 +
tests/fate/libavutil.mak | 4
tests/ref/fate/hash | 45 +
4 files changed, 91 insertions(+)
create mode 100644 tests/ref/fate/hash
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 934564f..58df75a 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -186,6 +186,7 @@ TESTPROGS = adler32
\
file\
fifo\
float_dsp \
+hash\
hmac\
lfg \
lls \
diff --git a/libavutil/hash.c b/libavutil/hash.c
index 7037b0d..3515e7f 100644
--- a/libavutil/hash.c
+++ b/libavutil/hash.c
@@ -237,3 +237,44 @@ void av_hash_freep(AVHashContext **ctx)
av_freep(&(*ctx)->ctx);
av_freep(ctx);
}
+
+#ifdef TEST
+// LCOV_EXCL_START
+
+int main(int argc, char *argv[])
+{
+ struct AVHashContext *ctx = NULL;
+ int i, j;
+ for(i = 0; i < NUM_HASHES; i++) {
+ uint8_t src[64], dst[64];
+ memset(src, 0, 64);
+ memset(dst, 0, 64);
+ if(av_hash_alloc(&ctx, av_hash_names(i)) == 0) {
+ av_hash_init(ctx);
+ av_hash_update(ctx, src, 64);
+ av_hash_final_hex(ctx, dst, 64);
+ printf("%s hex: %s\n", av_hash_names(i), dst);
+
+ memset(dst, 0, 64);
+ av_hash_final_bin(ctx, dst, 64);
+ printf("%s bin: ", av_hash_names(i));
+ for(j = 0; j < av_hash_get_size(ctx); j++) {
+ printf("%#x ", dst[j]);
+ }
+ printf("\n");
+
+ memset(dst, 0, 64);
+ av_hash_final_b64(ctx, dst, 64);
+ printf("%s b64: %s\n", av_hash_names(i), dst);
+ av_hash_freep(&ctx);
+ }
+ }
+
+ if(av_hash_alloc(&ctx, "FOO") != AVERROR(EINVAL)) {
+ printf("Invalid hash type 'FOO'\n");
+ }
+ return 0;
+}
+
+// LCOV_EXCL_STOP
+#endif
diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
index a89bc1d..5d8e0e2 100644
--- a/tests/fate/libavutil.mak
+++ b/tests/fate/libavutil.mak
@@ -75,6 +75,10 @@ fate-float-dsp: CMD = run libavutil/float_dsp-test
$(CPUFLAGS:%=-c%)
fate-float-dsp: CMP = null
fate-float-dsp: REF = /dev/null
+FATE_LIBAVUTIL += fate-hash
+fate-hash: libavutil/hash-test$(EXESUF)
+fate-hash: CMD = run libavutil/hash-test
+
FATE_LIBAVUTIL += fate-hmac
fate-hmac: libavutil/hmac-test$(EXESUF)
fate-hmac: CMD = run libavutil/hmac-test
diff --git a/tests/ref/fate/hash b/tests/ref/fate/hash
new file mode 100644
index 000..0a40a6d
--- /dev/null
+++ b/tests/ref/fate/hash
@@ -0,0 +1,45 @@
+MD5 hex: 3b5d3c7d207e37dceeedd301e35e2e58
+MD5 bin: 0x90 0x2c 0xb9 0x4f 0xf1 0x89 0xc5 0x50 0x92 0x30 0xa9 0x67 0xeb 0xd9
0x2f 0xe2
+MD5 b64: VSrlzoSomOWmBL6fzSKY3w==
+murmur3 hex: 6e484695e1d7b4e37d838791cc263395
+murmur3 bin: 0x6e 0x48 0x46 0x95 0xe1 0xd7 0xb4 0xe3 0x7d 0x83 0x87 0x91 0xcc
0x26 0x33 0x95
+murmur3 b64: bkhGleHXtON9g4eRzCYzlQ==
+RIPEMD128 hex: 082bfa9b829ef3a9e220dcc54e4c6383
+RIPEMD128 bin: 0x9f 0x6a 0xaf 0xf2 0x15 0x23 0x5e 0x3b 0x1b 0xf3 0x5c 0x27
0x97 0x8c 0x1c 0xa9
+RIPEMD128 b64: +E5c8OVnvwZuSxwl1dvm1g==
+RIPEMD160 hex: 9b8ccc2f374ae313a914763cc9cdfb47bfe1c229
+RIPEMD160 bin: 0xb5 0x1a 0x86 0x4e 0x27 0x4d 0xd0 0xe1 0x81 0x4d 0x83 0xce
0xd2 0x87 0x76 0xfc 0x95 0xed 0x8e 0x19
+RIPEMD160 b64: KQ4zIlTgLSLuYI370iB7aPaE7vs=
+RIPEMD256 hex: 26ba693759787f275f47dd5ab16e78c2fcd763b004fd05fc554e354223d6eab
+RIPEMD256 bin: 0x6e 0x9 0xbc 0x95 0xf2 0x4a 0xe 0x47 0xe7 0x2 0x2e 0xf3 0x5e
0xc1 0x2e 0x92 0xaa 0xfc 0xb6 0x97 0xd9 0xf8 0x1 0xb7 0xdd 0x90 0xde 0x48 0x78
0xc1 0x70 0xe2
+RIPEMD256 b64: SYuOSwaw29uyTVH17HBmsmHszKbjR/1LkfqRg0kgaZA=
+RIPEMD320 hex: 409a3111ffd3d4c8058ff5c231401c1d47210a5d22e6c90bf95d45c1c95c528
+RIPEMD320 bin: 0x6b 0x2a 0x54 0x88 0x49 0x24 0xf6 0x66 0xc3 0x5c 0xad 0x9c
0x22 0xd1 0x68 0x9c 0xfc 0x36 0xe6 0x37 0x22 0x53 0x7 0xa 0x1c 0xd9 0x3f 0x67
0x5 0x91 0xcd 0x49 0x3f 0xed 0x5b 0xda 0x1b 0x2d 0xff 0x9e
+RIPEMD320 b64: DdHUsKRNZwkUcZeoLAUQL5eYXmVA/kWAVJg5m3K6h890A/5qEZA90Q==
+SHA160 hex: c8d7d0ef0eedfa82d2ea1aa592845b9a6d4b02b7
+SHA160 bin: 0xf3 0xce 0x87 0xc9 0x60 0x2e 0xbf 0xcc 0x2b 0x8b 0xf2 0xbd 0x23
0xff 0x71 0x51 0x5a 0xb4 0xc8 0xeb
+SHA160 b64: Df5J/BOWO6TxCM/jjnilhVr2Rg8=
+SHA224 hex: 750d81a39c18d3ce27ff3e5ece30b0088f12d8fd0450fe435326294b
+SHA224 bin: 0xdb 0x15 0x26 0xe7 0x50 0xa9 0x3a 0x17 0xe3 0x39 0x80 0xd 0x78
0x1b 0xea 0xdd 0x3a 0xd3 0xad 0xf2 0x21 0xa2 0x93 0x1e 0x5e 0xf0 0xaf 0xeb
+SHA224 b64: eKAYArOrj3lSGq6JuHuz2mA7n/6br5IS4
Re: [FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
On 3/6/2016 4:14 PM, Reimar Döffinger wrote:
> On Sun, Mar 06, 2016 at 03:49:00PM -0300, James Almer wrote:
>> On 3/6/2016 3:35 PM, Reimar Döffinger wrote:
>>> Approximately 10% faster transcode from mp3 to aac
>>> with default settings.
>>>
>>> Signed-off-by: Reimar Döffinger
>>> ---
>>> libavcodec/aacenc_utils.h | 47
>>> ++-
>>> 1 file changed, 38 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
>>> index b9bd6bf..1639021 100644
>>> --- a/libavcodec/aacenc_utils.h
>>> +++ b/libavcodec/aacenc_utils.h
>>> @@ -36,15 +36,29 @@
>>> #define ROUND_TO_ZERO 0.1054f
>>> #define C_QUANT 0.4054f
>>>
>>> +#define ABSPOW(inv, outv) \
>>> +do { \
>>> +float a = (inv); \
>>> +a = fabsf(a); \
>>> +(outv) = sqrtf(a * sqrtf(a)); \
>>> +} while(0)
>>> +
>>> static inline void abs_pow34_v(float *out, const float *in, const int size)
>>> {
>>> int i;
>>> -for (i = 0; i < size; i++) {
>>> -float a = fabsf(in[i]);
>>> -out[i] = sqrtf(a * sqrtf(a));
>>> +for (i = 0; i < size - 3; i += 4) {
>>> +ABSPOW(in[i], out[i]);
>>> +ABSPOW(in[i+1], out[i+1]);
>>> +ABSPOW(in[i+2], out[i+2]);
>>> +ABSPOW(in[i+3], out[i+3]);
>>> +}
>>
>> Are you sure this wasn't vectorized already? I remember i checked and it
>> mostly
>> was, at least on gcc 5.3 mingw-w64 with default settings.
>
> Then it would hardly get 10% faster, would it (though
> I admit I didn't test the two parts separately)?
> But I am fairly sure that before the patch it only
> used sqrtss instructions and not sqrtps.
Without your patch, GCC 5.3 mingw-w64 x86_64 default settings.
$ make libavcodec/aacenc_ltp.o && objdump -d -M intel libavcodec/aacenc_ltp.o |
grep sqrtps
CC libavcodec/aacenc_ltp.o
1029: 0f 51 c8sqrtps xmm1,xmm0
102f: 0f 51 c0sqrtps xmm0,xmm0
161d: 0f 51 c8sqrtps xmm1,xmm0
1623: 0f 51 c0sqrtps xmm0,xmm0
1ccf: 0f 51 c8sqrtps xmm1,xmm0
1cd5: 0f 51 c0sqrtps xmm0,xmm0
2745: 0f 51 c8sqrtps xmm1,xmm0
274b: 0f 51 c0sqrtps xmm0,xmm0
34e4: 0f 51 c8sqrtps xmm1,xmm0
34ea: 0f 51 c0sqrtps xmm0,xmm0
42f7: 0f 51 c8sqrtps xmm1,xmm0
42fd: 0f 51 c0sqrtps xmm0,xmm0
44ac: 0f 51 c8sqrtps xmm1,xmm0
44b2: 0f 51 c0sqrtps xmm0,xmm0
With your patch
11fd: 0f 51 c8sqrtps xmm1,xmm0
1203: 0f 51 c0sqrtps xmm0,xmm0
12cb: 0f 51 c8sqrtps xmm1,xmm0
12d1: 0f 51 c0sqrtps xmm0,xmm0
1d43: 0f 51 c8sqrtps xmm1,xmm0
1d49: 0f 51 c0sqrtps xmm0,xmm0
1e21: 0f 51 c8sqrtps xmm1,xmm0
1e27: 0f 51 c0sqrtps xmm0,xmm0
2964: 0f 51 c8sqrtps xmm1,xmm0
296a: 0f 51 c0sqrtps xmm0,xmm0
2a3c: 0f 51 c8sqrtps xmm1,xmm0
2a42: 0f 51 c0sqrtps xmm0,xmm0
35f3: 0f 51 c8sqrtps xmm1,xmm0
35f9: 0f 51 c0sqrtps xmm0,xmm0
36bc: 0f 51 c8sqrtps xmm1,xmm0
36c2: 0f 51 c0sqrtps xmm0,xmm0
457b: 0f 51 c8sqrtps xmm1,xmm0
4581: 0f 51 c0sqrtps xmm0,xmm0
464c: 0f 51 c8sqrtps xmm1,xmm0
4652: 0f 51 c0sqrtps xmm0,xmm0
54b3: 0f 51 c8sqrtps xmm1,xmm0
54b9: 0f 51 c0sqrtps xmm0,xmm0
558f: 0f 51 c8sqrtps xmm1,xmm0
5595: 0f 51 c0sqrtps xmm0,xmm0
56e4: 0f 51 c8sqrtps xmm1,xmm0
56ea: 0f 51 c0sqrtps xmm0,xmm0
Didn't bench but it seems to help GCC vectorize more efficiently so this patch
is probably ok, especially if in your case it made your compiler actually be
able to vectorize at all.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
On Sun, Mar 06, 2016 at 04:46:08PM -0300, James Almer wrote: > On 3/6/2016 4:14 PM, Reimar Döffinger wrote: > > On Sun, Mar 06, 2016 at 03:49:00PM -0300, James Almer wrote: > >> On 3/6/2016 3:35 PM, Reimar Döffinger wrote: > >> Are you sure this wasn't vectorized already? I remember i checked and it > >> mostly > >> was, at least on gcc 5.3 mingw-w64 with default settings. > > > > Then it would hardly get 10% faster, would it (though > > I admit I didn't test the two parts separately)? > > But I am fairly sure that before the patch it only > > used sqrtss instructions and not sqrtps. > > Without your patch, GCC 5.3 mingw-w64 x86_64 default settings. > [...] > > Didn't bench but it seems to help GCC vectorize more efficiently so this patch > is probably ok, especially if in your case it made your compiler actually be > able to vectorize at all. Actually, I retract that patch. It might cause a very minor speedup (maybe 1.5%) due to what you saw, which is basically that gcc now also uses SIMD in the unaligned input path. However the big speedup comes from a different change I by accident mixed into this one. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacenc_utils: Use temporary variable.
This ensures gcc does not create unnecessary
loads or stores and possibly even does not vectorize
the negation.
Speeds up mp3 to aac transcoding with default settings
by 10% when using "gcc (Debian 5.3.1-10) 5.3.1 20160224".
Signed-off-by: Reimar Döffinger
---
libavcodec/aacenc_utils.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
index b9bd6bf..41a6296 100644
--- a/libavcodec/aacenc_utils.h
+++ b/libavcodec/aacenc_utils.h
@@ -68,10 +68,11 @@ static inline void quantize_bands(int *out, const float
*in, const float *scaled
int i;
for (i = 0; i < size; i++) {
float qc = scaled[i] * Q34;
-out[i] = (int)FFMIN(qc + rounding, (float)maxval);
+int tmp = (int)FFMIN(qc + rounding, (float)maxval);
if (is_signed && in[i] < 0.0f) {
-out[i] = -out[i];
+tmp = -tmp;
}
+out[i] = tmp;
}
}
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Support seek in encrypted MP4
> > can you create a fate test for this ? > maybe seek-test could be simply used? > Sure, can you point me to some existing test that is similar enough for me to use as a reference ? I read the Wiki page about adding a test, but not quite sure how to apply it here > thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > Thanks Eran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/img2dec: Use jpeg constants in jpeg_probe()
Michael Niedermayer niedermayer.cc> writes: > > 1 file changed, 37 insertions(+), 36 deletions(-) > > 82bb95da87139860c2e09731e375420e2733392e patchjpegconstants.diff > > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c > > LGTM > > thx Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c
On 3/6/2016 4:28 PM, NagaChaitanya Vellanki wrote:
> ---
> libavutil/Makefile | 1 +
> libavutil/hash.c | 41 +
> tests/fate/libavutil.mak | 4
> tests/ref/fate/hash | 45 +
> 4 files changed, 91 insertions(+)
> create mode 100644 tests/ref/fate/hash
>
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 934564f..58df75a 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -186,6 +186,7 @@ TESTPROGS = adler32
> \
> file\
> fifo\
> float_dsp \
> +hash\
> hmac\
> lfg \
> lls \
> diff --git a/libavutil/hash.c b/libavutil/hash.c
> index 7037b0d..3515e7f 100644
> --- a/libavutil/hash.c
> +++ b/libavutil/hash.c
> @@ -237,3 +237,44 @@ void av_hash_freep(AVHashContext **ctx)
> av_freep(&(*ctx)->ctx);
> av_freep(ctx);
> }
> +
> +#ifdef TEST
> +// LCOV_EXCL_START
> +
> +int main(int argc, char *argv[])
I don't see arguments being used anywhere.
> +{
> + struct AVHashContext *ctx = NULL;
> + int i, j;
> + for(i = 0; i < NUM_HASHES; i++) {
> + uint8_t src[64], dst[64];
Move src outside the for statement, init it with { 0 } instead of memset and
make it static
const.
And for dst you should use AV_HASH_MAX_SIZE. Or rather, a value derived from
it. See below.
> + memset(src, 0, 64);
> + memset(dst, 0, 64);
> + if(av_hash_alloc(&ctx, av_hash_names(i)) == 0) {
if (!av_hash_alloc(&ctx, av_hash_names(i))) {
Alternatively you could do
if(av_hash_alloc(&ctx, av_hash_names(i)) < 0)
return 1;
> + av_hash_init(ctx);
> + av_hash_update(ctx, src, 64);
> + av_hash_final_hex(ctx, dst, 64);
64 bytes (current value of AV_HASH_MAX_SIZE) is not enough to write the hex
digest of
algorithms like SHA512. Notice in the ref file that the digest of SHA256,
SHA384 and SHA512
are the same length, because the latter two got truncated.
You need a bigger dst buffer.
> + printf("%s hex: %s\n", av_hash_names(i), dst);
Use av_hash_get_name(ctx) here and below to also test that function while at it.
> +
> + memset(dst, 0, 64);
> + av_hash_final_bin(ctx, dst, 64);
As you probably noticed in the ref file, calling a final() function twice
doesn't output the
same digest with most algorithms. Ideally you'd reinit then recalculate the
digest before
every final() call.
> + printf("%s bin: ", av_hash_names(i));
> + for(j = 0; j < av_hash_get_size(ctx); j++) {
> + printf("%#x ", dst[j]);
> + }
> + printf("\n");
> +
> + memset(dst, 0, 64);
> + av_hash_final_b64(ctx, dst, 64);
Same as hex, AV_HASH_MAX_SIZE is not enough for base64.
> + printf("%s b64: %s\n", av_hash_names(i), dst);
> + av_hash_freep(&ctx);
> + }
> + }
> +
> + if(av_hash_alloc(&ctx, "FOO") != AVERROR(EINVAL)) {
> + printf("Invalid hash type 'FOO'\n");
av_hash_alloc() may return ENOMEM, so this error message could be misleading.
Also, I'm not sure about the usefulness of this check to being with.
> + }
> + return 0;
> +}
> +
> +// LCOV_EXCL_STOP
> +#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Support seek in encrypted MP4
On Sun, Mar 06, 2016 at 08:35:41PM +, Eran Kornblau wrote: > > > > can you create a fate test for this ? > > maybe seek-test could be simply used? > > > Sure, can you point me to some existing test that is similar enough for me to > use as a reference ? > I read the Wiki page about adding a test, but not quite sure how to apply it > here check tests/fate/seek.mak also you can pass parameters to seek-test see fate-seek-cache-pipe i dont know if there is anything else special needed for this [...] -- 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] [PATCHv2 1/2] avcodec/aactab: do not use floats for constants
On Sun, Mar 06, 2016 at 01:10:48PM +0100, Marton Balint wrote: > This may improve the precision of the fixed point decoder for some compilers > and architectures. > > Signed-off-by: Marton Balint > --- > libavcodec/aac_defines.h | 6 +++--- > libavcodec/aactab.h | 22 +++--- > 2 files changed, 14 insertions(+), 14 deletions(-) should be ok i think if it fixes something [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c
On Sun, Mar 06, 2016 at 11:27:59AM -0800, NagaChaitanya Vellanki wrote: > Please review the patch. > > NagaChaitanya Vellanki (1): > Add tests for functions in hash.c btw, if this is a qualification task for GSoC or Outreachy then please add yourself to https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis [...] -- 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] avformat/ftp: Support response code 125 for STOR and RETR commands
On Thu, Jan 07, 2016 at 10:38:06AM +0100, Raymond Hilseth wrote: > This fixes a problem where ffmpeg would hang if there is already an open > data connection, and the server sends a 125 response code in reply to a > STOR or RETR command. > > Signed-off-by: Raymond Hilseth > --- > libavformat/ftp.c | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) applied thx [...] -- 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] rtp: Fix play multiple multicast streams with the same port
On Wed, Jan 13, 2016 at 09:11:13AM +0800, Zhao Zhili wrote:
> ping？
applied
sorry for the delay, i had hoped thomas would review
thanks
>
> On Fri, Jan 8, 2016 at 9:15 AM, Zhao Zhili wrote:
>
> > Sorry, I work hard to cross the Great Fire Wall to send this patch and
> > cannot send it as plaintext.
> > Now send it as attachment.
> >
> > On Fri, Jan 8, 2016 at 1:52 AM, Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> >
> >> On Thu, Jan 07, 2016 at 06:58:49PM +0800, Zhao Zhili wrote:
> >> > I made a mistake that rtp and rtcp cannot be the same port. A new patch
> >> is
> >> > appended.
> >> >
> >> > From: Zhao Zhili
> >> > Date: Thu, 7 Jan 2016 18:55:50 +0800
> >> > Subject: [PATCH] rtp: Fix play multiple multicast streams with the same
> >> port
> >> >
> >> > We cannot play multiple multicast streams with the same port at the
> >> > same time. This is because both rtp and rtcp port are opened in
> >> > read-write mode, so they will not bind to the multicast address. Try
> >> > to make rtp port as read-only by default to solve this bug.
> >> >
> >> > Signed-off-by: Zhao Zhili
> >> > ---
> >> > libavformat/rtpproto.c | 6 --
> >> > libavformat/rtsp.c | 2 +-
> >> > 2 files changed, 5 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/libavformat/rtpproto.c b/libavformat/rtpproto.c
> >> > index e0aa23e..04a40ea 100644
> >> > --- a/libavformat/rtpproto.c
> >> > +++ b/libavformat/rtpproto.c
> >> > @@ -323,6 +323,7 @@ static int rtp_open(URLContext *h, const char *uri,
> >> int
> >> > flags)
> >> > char path[1024];
> >> > const char *p;
> >> > int i, max_retry_count = 3;
> >> > +int rtcpflags;
> >> >
> >> > av_url_split(NULL, 0, NULL, 0, hostname, sizeof(hostname),
> >> &rtp_port,
> >> > path, sizeof(path), uri);
> >> > @@ -387,12 +388,13 @@ static int rtp_open(URLContext *h, const char
> >> *uri,
> >> > int flags)
> >> > s->local_rtpport = -1;
> >> > continue;
> >> > }
> >> > +rtcpflags = flags | AVIO_FLAG_WRITE;
> >> > if (s->local_rtcpport < 0) {
> >> > s->local_rtcpport = s->local_rtpport + 1;
> >> > build_udp_url(s, buf, sizeof(buf),
> >> >hostname, s->rtcp_port, s->local_rtcpport,
> >> >sources, block);
> >> > -if (ffurl_open(&s->rtcp_hd, buf, flags,
> >> > &h->interrupt_callback, NULL) < 0) {
> >> > +if (ffurl_open(&s->rtcp_hd, buf, rtcpflags,
> >> > &h->interrupt_callback, NULL) < 0) {
> >>
> >> the patch is corrupted by linebreaks
> >>
> >> attaching it usually fixes that
> >>
> >> [...]
> >> --
> >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >>
> >> Old school: Use the lowest level language in which you can solve the
> >> problem
> >> conveniently.
> >> New school: Use the highest level language in which the latest
> >> supercomputer
> >> can solve the problem without the user falling asleep waiting.
> >>
> >> ___
> >> 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
--
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
[FFmpeg-devel] [PATCH 1/3] lavf/segment: style nit
---
libavformat/segment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index dd3b092..818c0c9 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -809,7 +809,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
(seg->cut_pending || seg->frame_count >= start_frame ||
(pkt->pts != AV_NOPTS_VALUE &&
av_compare_ts(pkt->pts, st->time_base,
-end_pts-seg->time_delta, AV_TIME_BASE_Q) >= 0))) {
+end_pts - seg->time_delta, AV_TIME_BASE_Q) >= 0))) {
/* sanitize end time in case last packet didn't have a defined
duration */
if (seg->cur_entry.last_duration == 0)
seg->cur_entry.end_time = (double)pkt->pts * av_q2d(st->time_base);
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] lavf/segment: slight refactor to seg_write_packet
This reduces some code duplication, and ensures that cur_entry.last_duration is
always set.
---
libavformat/segment.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 818c0c9..6ad991f 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -824,11 +824,13 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
seg->cur_entry.index = seg->segment_idx + seg->segment_idx_wrap *
seg->segment_idx_wrap_nb;
seg->cur_entry.start_time = (double)pkt->pts * av_q2d(st->time_base);
seg->cur_entry.start_pts = av_rescale_q(pkt->pts, st->time_base,
AV_TIME_BASE_Q);
-seg->cur_entry.end_time = seg->cur_entry.start_time +
-pkt->pts != AV_NOPTS_VALUE ? (double)(pkt->pts + pkt->duration) *
av_q2d(st->time_base) : 0;
-} else if (pkt->pts != AV_NOPTS_VALUE && pkt->stream_index ==
seg->reference_stream_index) {
-seg->cur_entry.end_time =
-FFMAX(seg->cur_entry.end_time, (double)(pkt->pts + pkt->duration)
* av_q2d(st->time_base));
+seg->cur_entry.end_time = seg->cur_entry.start_time;
+}
+
+if (pkt->stream_index == seg->reference_stream_index) {
+if (pkt->pts != AV_NOPTS_VALUE)
+seg->cur_entry.end_time =
+FFMAX(seg->cur_entry.end_time, (double)(pkt->pts +
pkt->duration) * av_q2d(st->time_base));
seg->cur_entry.last_duration = pkt->duration;
}
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
On Sun, Mar 6, 2016 at 1:43 PM, Reimar Döffinger wrote: > On Sun, Mar 06, 2016 at 07:35:58PM +0100, Reimar Döffinger wrote: >> Approximately 10% faster transcode from mp3 to aac >> with default settings. > > Note to anyone wanting to optimize it further: > There is almost 25% on the table if you can replace > the pow() and cos() function uses by something more > efficient. So I did try one thing, namely in lavc/aacenc_utils, replace powf in find_form_factor by a conditional checking for 2.0f, squaring if it is, powf otherwise (see lavc/aaccoder_twoloop for the calls, one is with 2.0f, other without), but it yields essentially nothing. Likewise, an even more trivial one is line 125 of aaccoder_twoloop: powf can be replaced here by sqrtf(sqrtf()), but this also yields nothing. Can you be more specific, and are you sure about this? [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] lavf/segment: add option to write empty filler segments as needed
---
doc/muxers.texi | 5 +
libavformat/segment.c | 8 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f2ad7fe..700ec88 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1224,6 +1224,11 @@ muxers/codecs. It is set to @code{0} by default.
@item initial_offset @var{offset}
Specify timestamp offset to apply to the output packet timestamps. The
argument must be a time duration specification, and defaults to 0.
+
+@item write_empty_segments @var{1|0}
+If enabled, write an empty segment if there are no packets during the period a
+segment would usually span. Otherwise, the segment will be filled with the next
+packet written. Defaults to @code{0}.
@end table
@subsection Examples
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 6ad991f..df1514f 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -116,6 +116,7 @@ typedef struct SegmentContext {
char *reference_stream_specifier; ///< reference stream specifier
int reference_stream_index;
int break_non_keyframes;
+int write_empty;
int use_rename;
char temp_list_filename[1024];
@@ -774,6 +775,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
if (!seg->avf)
return AVERROR(EINVAL);
+calc_times:
if (seg->times) {
end_pts = seg->segment_count < seg->nb_times ?
seg->times[seg->segment_count] : INT64_MAX;
@@ -805,7 +807,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
if (pkt->stream_index == seg->reference_stream_index &&
(pkt->flags & AV_PKT_FLAG_KEY || seg->break_non_keyframes) &&
-seg->segment_frame_count > 0 &&
+(seg->segment_frame_count > 0 || seg->write_empty) &&
(seg->cut_pending || seg->frame_count >= start_frame ||
(pkt->pts != AV_NOPTS_VALUE &&
av_compare_ts(pkt->pts, st->time_base,
@@ -825,6 +827,9 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
seg->cur_entry.start_time = (double)pkt->pts * av_q2d(st->time_base);
seg->cur_entry.start_pts = av_rescale_q(pkt->pts, st->time_base,
AV_TIME_BASE_Q);
seg->cur_entry.end_time = seg->cur_entry.start_time;
+
+if (seg->times || (!seg->frames && !seg->use_clocktime) &&
seg->write_empty)
+goto calc_times;
}
if (pkt->stream_index == seg->reference_stream_index) {
@@ -956,6 +961,7 @@ static const AVOption options[] = {
{ "write_header_trailer", "write a header to the first segment and a
trailer to the last one", OFFSET(write_header_trailer), AV_OPT_TYPE_BOOL, {.i64
= 1}, 0, 1, E },
{ "reset_timestamps", "reset timestamps at the begin of each segment",
OFFSET(reset_timestamps), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, E },
{ "initial_offset", "set initial timestamp offset",
OFFSET(initial_offset), AV_OPT_TYPE_DURATION, {.i64 = 0}, -INT64_MAX,
INT64_MAX, E },
+{ "write_empty_segments", "allow writing empty 'filler' segments",
OFFSET(write_empty), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, E },
{ NULL },
};
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add tests for functions in hash.c
---
libavutil/Makefile | 1 +
libavutil/hash.c | 45 +
tests/fate/libavutil.mak | 4
tests/ref/fate/hash | 45 +
4 files changed, 95 insertions(+)
create mode 100644 tests/ref/fate/hash
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 934564f..58df75a 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -186,6 +186,7 @@ TESTPROGS = adler32
\
file\
fifo\
float_dsp \
+hash\
hmac\
lfg \
lls \
diff --git a/libavutil/hash.c b/libavutil/hash.c
index 7037b0d..ac35e88 100644
--- a/libavutil/hash.c
+++ b/libavutil/hash.c
@@ -237,3 +237,48 @@ void av_hash_freep(AVHashContext **ctx)
av_freep(&(*ctx)->ctx);
av_freep(ctx);
}
+
+#ifdef TEST
+// LCOV_EXCL_START
+#define SRC_BUF_SIZE 64
+#define DST_BUF_SIZE 512
+
+int main(void)
+{
+ struct AVHashContext *ctx = NULL;
+ int i, j;
+ static const uint8_t src[SRC_BUF_SIZE] = { 0 };
+ uint8_t dst[DST_BUF_SIZE];
+ for(i = 0; i < NUM_HASHES; i++) {
+ if(av_hash_alloc(&ctx, av_hash_names(i)) < 0) {
+ return 1;
+ }
+
+ av_hash_init(ctx);
+ av_hash_update(ctx, src, SRC_BUF_SIZE);
+ memset(dst, 0, DST_BUF_SIZE);
+ av_hash_final_hex(ctx, dst, DST_BUF_SIZE);
+ printf("%s hex: %s\n", av_hash_get_name(ctx), dst);
+
+ av_hash_init(ctx);
+ av_hash_update(ctx, src, SRC_BUF_SIZE);
+ memset(dst, 0, DST_BUF_SIZE);
+ av_hash_final_bin(ctx, dst, DST_BUF_SIZE);
+ printf("%s bin: ", av_hash_get_name(ctx));
+ for(j = 0; j < av_hash_get_size(ctx); j++) {
+ printf("%#x ", dst[j]);
+ }
+ printf("\n");
+
+ av_hash_init(ctx);
+ av_hash_update(ctx, src, SRC_BUF_SIZE);
+ memset(dst, 0, DST_BUF_SIZE);
+ av_hash_final_b64(ctx, dst, DST_BUF_SIZE);
+ printf("%s b64: %s\n", av_hash_get_name(ctx), dst);
+ av_hash_freep(&ctx);
+ }
+ return 0;
+}
+
+// LCOV_EXCL_STOP
+#endif
diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
index a89bc1d..5d8e0e2 100644
--- a/tests/fate/libavutil.mak
+++ b/tests/fate/libavutil.mak
@@ -75,6 +75,10 @@ fate-float-dsp: CMD = run libavutil/float_dsp-test
$(CPUFLAGS:%=-c%)
fate-float-dsp: CMP = null
fate-float-dsp: REF = /dev/null
+FATE_LIBAVUTIL += fate-hash
+fate-hash: libavutil/hash-test$(EXESUF)
+fate-hash: CMD = run libavutil/hash-test
+
FATE_LIBAVUTIL += fate-hmac
fate-hmac: libavutil/hmac-test$(EXESUF)
fate-hmac: CMD = run libavutil/hmac-test
diff --git a/tests/ref/fate/hash b/tests/ref/fate/hash
new file mode 100644
index 000..6e5a580
--- /dev/null
+++ b/tests/ref/fate/hash
@@ -0,0 +1,45 @@
+MD5 hex: 3b5d3c7d207e37dceeedd301e35e2e58
+MD5 bin: 0x3b 0x5d 0x3c 0x7d 0x20 0x7e 0x37 0xdc 0xee 0xed 0xd3 0x1 0xe3 0x5e
0x2e 0x58
+MD5 b64: O108fSB+N9zu7dMB414uWA==
+murmur3 hex: 6e484695e1d7b4e37d838791cc263395
+murmur3 bin: 0x6e 0x48 0x46 0x95 0xe1 0xd7 0xb4 0xe3 0x7d 0x83 0x87 0x91 0xcc
0x26 0x33 0x95
+murmur3 b64: bkhGleHXtON9g4eRzCYzlQ==
+RIPEMD128 hex: 082bfa9b829ef3a9e220dcc54e4c6383
+RIPEMD128 bin: 0x8 0x2b 0xfa 0x9b 0x82 0x9e 0xf3 0xa9 0xe2 0x20 0xdc 0xc5 0x4e
0x4c 0x63 0x83
+RIPEMD128 b64: CCv6m4Ke86niINzFTkxjgw==
+RIPEMD160 hex: 9b8ccc2f374ae313a914763cc9cdfb47bfe1c229
+RIPEMD160 bin: 0x9b 0x8c 0xcc 0x2f 0x37 0x4a 0xe3 0x13 0xa9 0x14 0x76 0x3c
0xc9 0xcd 0xfb 0x47 0xbf 0xe1 0xc2 0x29
+RIPEMD160 b64: m4zMLzdK4xOpFHY8yc37R7/hwik=
+RIPEMD256 hex: 26ba693759787f275f47dd5ab16e78c2fcd763b004fd05fc554e354223d6eab5
+RIPEMD256 bin: 0x26 0xba 0x69 0x37 0x59 0x78 0x7f 0x27 0x5f 0x47 0xdd 0x5a
0xb1 0x6e 0x78 0xc2 0xfc 0xd7 0x63 0xb0 0x4 0xfd 0x5 0xfc 0x55 0x4e 0x35 0x42
0x23 0xd6 0xea 0xb5
+RIPEMD256 b64: JrppN1l4fydfR91asW54wvzXY7AE/QX8VU41QiPW6rU=
+RIPEMD320 hex:
409a3111ffd3d4c8058ff5c231401c1d47210a5d22e6c90bf95d45c1c95c528463c69ce4bff3b884
+RIPEMD320 bin: 0x40 0x9a 0x31 0x11 0xff 0xd3 0xd4 0xc8 0x5 0x8f 0xf5 0xc2 0x31
0x40 0x1c 0x1d 0x47 0x21 0xa 0x5d 0x22 0xe6 0xc9 0xb 0xf9 0x5d 0x45 0xc1 0xc9
0x5c 0x52 0x84 0x63 0xc6 0x9c 0xe4 0xbf 0xf3 0xb8 0x84
+RIPEMD320 b64: QJoxEf/T1MgFj/XCMUAcHUchCl0i5skL+V1FwclcUoRjxpzkv/O4hA==
+SHA160 hex: c8d7d0ef0eedfa82d2ea1aa592845b9a6d4b02b7
+SHA160 bin: 0xc8 0xd7 0xd0 0xef 0xe 0xed 0xfa 0x82 0xd2 0xea 0x1a 0xa5 0x92
0x84 0x5b 0x9a 0x6d 0x4b 0x2 0xb7
+SHA160 b64: yNfQ7w7t+oLS6hqlkoRbmm1LArc=
+SHA224 hex: 750d81a39c18d3ce27ff3e5ece30b0088f12d8fd0450fe435326294b
+SHA224 bin: 0x75 0xd 0x81 0xa3 0x9c
[FFmpeg-devel] [PATCH] Add tests for functions in hash.c
Made changes as suggested by James Almer. NagaChaitanya Vellanki (1): Add tests for functions in hash.c libavutil/Makefile | 1 + libavutil/hash.c | 45 + tests/fate/libavutil.mak | 4 tests/ref/fate/hash | 45 + 4 files changed, 95 insertions(+) create mode 100644 tests/ref/fate/hash -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/contact: add IRC web-client link
Ran into some glitches when I initially tried accessing IRC through my browser; in particular the Firefox default of "mibbit" does not work: https://blog.freenode.net/2009/06/new-freenode-webchat-and-why-to-use-it/. Signed-off-by: Ganesh Ajjanagadde --- src/contact | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/contact b/src/contact index 22c1e11..e84367b 100644 --- a/src/contact +++ b/src/contact @@ -102,6 +102,8 @@ IRC network. Both channels are open and unmoderated. Developers with commit rights have operator status, contributors with patches in FFmpeg have voice in the channels. + https://webchat.freenode.net/";>freenode webchat is a web + client for these channels. -- 2.7.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/contact: add IRC web-client link
On Sun, 6 Mar 2016 22:33:30 -0500, Ganesh Ajjanagadde wrote: > Ran into some glitches when I initially tried accessing IRC through my > browser; in particular the Firefox default of "mibbit" does not work: > https://blog.freenode.net/2009/06/new-freenode-webchat-and-why-to-use-it/. > > Signed-off-by: Ganesh Ajjanagadde > --- > src/contact | 2 ++ > 1 file changed, 2 insertions(+) LGTM and pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Opus in MP4 support
Hi,
The attached patch adds basic mux/demux support for the Opus audio codec in MP4.
Mozilla have expressed interest in shipping support for this in:
https://groups.google.com/d/msg/mozilla.dev.platform/mdDZ-nBr_jM/MaLi2BDOAgAJ
Comments welcome!
Basic Opus in MP4 mux/demux support based on the draft spec.
Draft spec: https://www.opus-codec.org/docs/opus_in_isobmff.html
Signed-off-by: Matthew Gregan
---
libavformat/isom.c | 2 ++
libavformat/mov.c| 38
libavformat/movenc.c | 82 ++--
3 files changed, 119 insertions(+), 3 deletions(-)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 2ca1265..6d92a93 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -61,6 +61,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
{ AV_CODEC_ID_DTS , 0xA9 }, /* mp4ra.org */
{ AV_CODEC_ID_TSCC2 , 0xD0 }, /* non standard, camtasia uses it */
{ AV_CODEC_ID_VORBIS , 0xDD }, /* non standard, gpac uses it */
+{ AV_CODEC_ID_OPUS, 0xDE }, /* non standard */
{ AV_CODEC_ID_DVD_SUBTITLE, 0xE0 }, /* non standard, see unsupported-embedded-subs-2.mp4 */
{ AV_CODEC_ID_QCELP , 0xE1 },
{ AV_CODEC_ID_MPEG4SYSTEMS, 0x01 },
@@ -323,6 +324,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_WMAV2, MKTAG('W', 'M', 'A', '2') },
{ AV_CODEC_ID_EVRC,MKTAG('s', 'e', 'v', 'c') }, /* 3GPP2 */
{ AV_CODEC_ID_SMV, MKTAG('s', 's', 'm', 'v') }, /* 3GPP2 */
+{ AV_CODEC_ID_OPUS,MKTAG('O', 'p', 'u', 's') }, /* non-standard */
{ AV_CODEC_ID_NONE, 0 },
};
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 752bc12..a6b896e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1534,6 +1534,43 @@ static int mov_read_svq3(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return mov_read_extradata(c, pb, atom, AV_CODEC_ID_SVQ3);
}
+static int mov_read_dops(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+size_t size;
+
+if (c->fc->nb_streams < 1)
+return 0;
+st = c->fc->streams[c->fc->nb_streams-1];
+
+if ((uint64_t)atom.size > (1<<30) || atom.size < 11)
+return AVERROR_INVALIDDATA;
+
+// Check OpusSpecificBox version.
+if (avio_r8(pb) != 0)
+return AVERROR_INVALIDDATA;
+
+// OpusSpecificBox size plus magic header for OggOpus header.
+size = atom.size + 16;
+
+st->codec->extradata = av_mallocz(size + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!st->codec->extradata)
+return AVERROR(ENOMEM);
+st->codec->extradata_size = size;
+
+AV_WL32(st->codec->extradata, MKTAG('O','p','u','s'));
+AV_WL32(st->codec->extradata + 4, MKTAG('H','e','a','d'));
+AV_WB8(st->codec->extradata + 8, 1); // OggOpus version
+avio_read(pb, st->codec->extradata + 9, size - 17);
+
+// OpusSpecificBox is stored in big-endian, but OpusHead is
+// little-endian; they're otherwise identical.
+AV_WL16(st->codec->extradata + 10, AV_RB16(st->codec->extradata + 10));
+AV_WL32(st->codec->extradata + 12, AV_RB32(st->codec->extradata + 12));
+AV_WL16(st->codec->extradata + 16, AV_RB16(st->codec->extradata + 16));
+return 0;
+}
+
static int mov_read_wave(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
AVStream *st;
@@ -4308,6 +4345,7 @@ static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('f','r','m','a'), mov_read_frma },
{ MKTAG('s','e','n','c'), mov_read_senc },
{ MKTAG('s','a','i','z'), mov_read_saiz },
+{ MKTAG('d','O','p','s'), mov_read_dops },
{ 0, NULL }
};
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cb125d8..e5698b4 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -649,6 +649,25 @@ static int mov_write_wfex_tag(AVIOContext *pb, MOVTrack *track)
return update_size(pb, pos);
}
+static int mov_write_dops_tag(AVIOContext *pb, MOVTrack *track)
+{
+int64_t pos = avio_tell(pb);
+avio_wb32(pb, 0);
+ffio_wfourcc(pb, "dOps");
+avio_w8(pb, 0); // OpusSpecificBox version.
+if (track->enc->extradata_size < 19)
+ return AVERROR_INVALIDDATA;
+// Write the part of a OggOpus header matching the OpusSpecificBox layout.
+// Skipping OggOpus magic (8 bytes) and version (1 byte).
+avio_w8(pb, AV_RB8(track->enc->extradata + 9)); // OuputChannelCount
+avio_wb16(pb, AV_RL16(track->enc->extradata + 10)); // PreSkip
+avio_wb32(pb, AV_RL32(track->enc->extradata + 12)); // InputSampleRate
+avio_wb16(pb, AV_RL16(track->enc->extradata + 16)); // OutputGain
+// Write the rest of the header out as-is.
+avio_write(pb, track->enc->extradata + 18, track->enc->extradata_size - 18);
+return update_size(pb, pos);
+}
+
static int mov_write_chan_tag(AVIOContext *pb, MOVTrack *track)
{
uint32_t layout_tag, bitmap;
@@ -958,14 +977,20 @@ static int mov_write_audio_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr
Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c
On 3/7/2016 12:26 AM, NagaChaitanya Vellanki wrote:
> ---
> libavutil/Makefile | 1 +
> libavutil/hash.c | 45 +
> tests/fate/libavutil.mak | 4
> tests/ref/fate/hash | 45 +
> 4 files changed, 95 insertions(+)
> create mode 100644 tests/ref/fate/hash
>
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 934564f..58df75a 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -186,6 +186,7 @@ TESTPROGS = adler32
> \
> file\
> fifo\
> float_dsp \
> +hash\
> hmac\
> lfg \
> lls \
> diff --git a/libavutil/hash.c b/libavutil/hash.c
> index 7037b0d..ac35e88 100644
> --- a/libavutil/hash.c
> +++ b/libavutil/hash.c
> @@ -237,3 +237,48 @@ void av_hash_freep(AVHashContext **ctx)
> av_freep(&(*ctx)->ctx);
> av_freep(ctx);
> }
> +
> +#ifdef TEST
> +// LCOV_EXCL_START
> +#define SRC_BUF_SIZE 64
> +#define DST_BUF_SIZE 512
You should use AV_HASH_MAX_SIZE for dst. If someone goes and adds a new
algorithm
with a digest bigger than 64 bytes that value will change and the dst buffer
here
may not be enough anymore.
AV_HASH_MAX_SIZE*4 should do it i think.
> +
> +int main(void)
> +{
> + struct AVHashContext *ctx = NULL;
> + int i, j;
> + static const uint8_t src[SRC_BUF_SIZE] = { 0 };
> + uint8_t dst[DST_BUF_SIZE];
> + for(i = 0; i < NUM_HASHES; i++) {
Nit: Space after for.
> + if(av_hash_alloc(&ctx, av_hash_names(i)) < 0) {
Nit: Space after if, and no need for brackets.
> + return 1;
> + }
> +
> + av_hash_init(ctx);
> + av_hash_update(ctx, src, SRC_BUF_SIZE);
> + memset(dst, 0, DST_BUF_SIZE);
memset (or even zero initializing dst) is probably not needed at all.
hash.h doxy says hex and b64 digests are always 0-terminated, and you never
read more than av_hash_get_size(ctx) for the binary digest.
> + av_hash_final_hex(ctx, dst, DST_BUF_SIZE);
> + printf("%s hex: %s\n", av_hash_get_name(ctx), dst);
> +
> + av_hash_init(ctx);
> + av_hash_update(ctx, src, SRC_BUF_SIZE);
> + memset(dst, 0, DST_BUF_SIZE);
> + av_hash_final_bin(ctx, dst, DST_BUF_SIZE);
> + printf("%s bin: ", av_hash_get_name(ctx));
> + for(j = 0; j < av_hash_get_size(ctx); j++) {
Nit: Space after for.
> + printf("%#x ", dst[j]);
Indentation should be four spaces.
> + }
> + printf("\n");
> +
> + av_hash_init(ctx);
> + av_hash_update(ctx, src, SRC_BUF_SIZE);
> + memset(dst, 0, DST_BUF_SIZE);
> + av_hash_final_b64(ctx, dst, DST_BUF_SIZE);
> + printf("%s b64: %s\n", av_hash_get_name(ctx), dst);
> + av_hash_freep(&ctx);
> + }
> + return 0;
> +}
> +
> +// LCOV_EXCL_STOP
> +#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
On 07.03.2016, at 04:04, Ganesh Ajjanagadde wrote: > On Sun, Mar 6, 2016 at 1:43 PM, Reimar Döffinger > wrote: >> On Sun, Mar 06, 2016 at 07:35:58PM +0100, Reimar Döffinger wrote: >>> Approximately 10% faster transcode from mp3 to aac >>> with default settings. >> >> Note to anyone wanting to optimize it further: >> There is almost 25% on the table if you can replace >> the pow() and cos() function uses by something more >> efficient. > > So I did try one thing, namely in lavc/aacenc_utils, replace powf in > find_form_factor by a conditional checking for 2.0f, squaring if it > is, powf otherwise (see lavc/aaccoder_twoloop for the calls, one is > with 2.0f, other without), but it yields essentially nothing. > > Likewise, an even more trivial one is line 125 of aaccoder_twoloop: > powf can be replaced here by sqrtf(sqrtf()), but this also yields > nothing. Probably those cases are already optimized by the implementation. > Can you be more specific, and are you sure about this? Just run your favourite performance analysis tool and you'll see. As it is non-inlined libc code I'm fairly sure the numbers are accurate enough. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
