[FFmpeg-devel] mpegtsenc cbr mode pcr accuracy

[Timo Teras]

Hi,

While the pcr is accuracte, I was measuring the cbr pcr frequence with
opencaster suite's tspcmeasure tool, and it says that the frequency is
not that accurate. With default options (just muxrate specified) the
pcr should appear every 20ms. But it appears every 19-22.5ms (also
there some appearances with 1-18ms but those are probably the extra pcr
announces for key frames).

While in practice this is not too bad for me, I wondered how it should
be generated instead.

Seems that the period is calculated in mpegts_write_header():
  pcr_packet_period = mux_rate * pcr_period / (TS_PACKET_SIZE * 8 * 1000)

Which is the packet period over the whole mpeg ts stream. But the count
is actually incremented like mpegts_write_pes():
while (payload_size > 0) {
retransmit_si_info(s, force_pat, dts);
force_pat = 0;
write_pcr = 0;
if (ts_st->pid == ts_st->service->pcr_pid) {
if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on 
frames
ts_st->service->pcr_packet_count++;

The problem seems to be that only packets for pcr_pid are counted in
the pcr period. That's why the gap goes >20ms when there's other
streams muxed (usually audio) and depends on the other PES' bandwidth.
Same is true for sdt and pat - they drift very slightly, because they
don't count each other's packets.

I was wondering how to fix this. Would it be best to remove all
{sdt,pat,pcr}_packet_count variables, and replace it with single
packet_count counter that is incremented everytime a packet is sent
(in the four functions section_write_packet(),
mpegts_insert_null_packet(), mpegts_insert_pcr_only(),
mpegts_write_pes()) and then calculate just the next packet count when
to trigger resend. packet_count + {sdt,pat,pcr}_packet_period.

Another problem case is the inserting of null/pcr-only packets. If it's
a non-pcr stream PES packet triggering the stuffing, it should still
stuff pcr to the pcr_pid - not the pid of the stream triggering the
stuffing. Basically the strategy in cbr mode should be:
 1) Check / send SDT/PAT as currently
 2) Check if PCR needs to be sent
 3) If filler packets needed: a) send pcr on pcr_pid, OR b) send null
 4) If PCR send needed but ES PID != pcr pid: send PCR only on pcr_pid
 5) Proceed with sending ES on ES PID as regular

Does this reasoning / approach make sense?

Thanks,
Timo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/mpegaudio_tablegen: more dynamic initialization speedups

[Ganesh Ajjanagadde]

This further speeds up runtime initialization, with identical generated tables.

Sample benchmark (x86-64, Haswell, GNU/Linux):

old:
34441423 decicycles in mpegaudio_tableinit,8192 runs,  0 skips

new:
10776291 decicycles in mpegaudio_tableinit,8192 runs,  0 skips

Most low hanging fruit is taken care of here. For some idea, note that
83,064 array elements totalling 233,722 bytes need to be initialized.
Thus, with this patch, we average ~ 12.9 cycles per element or ~ 4.6
cycles per byte.

I personally consider this net ~ 10x and overall perf numbers sufficient
for using dynamic initialization all the time here, especially since the
tables are large.

Signed-off-by: Ganesh Ajjanagadde 
---
The reason this is being posted before pushing in the other one is that if
people agree to do dynamic initialization here, the introduction of 
avutil/tablegen
can be deferred to a future date.

Note that if one had a ~8000 element static lut for the pow_43 values,
one can bring down the cost slightly, to ~ 8-10 cycles per element but not more,
so definitely not an order of improvement like the current patches.
I personally do not like this "middle path" as I find it too complex for a 
slight
speed gain, while still having a large ~ 64,000 byte size cost.
---
 libavcodec/mpegaudio_tablegen.h | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/libavcodec/mpegaudio_tablegen.h b/libavcodec/mpegaudio_tablegen.h
index dd67a09..91b29cb 100644
--- a/libavcodec/mpegaudio_tablegen.h
+++ b/libavcodec/mpegaudio_tablegen.h
@@ -45,23 +45,28 @@ static float expval_table_float[512][16];
 static av_cold void mpegaudio_tableinit(void)
 {
 int i, value, exponent;
-double exp2_lut[4] = {
+static const double exp2_lut[4] = {
 1., /* 2 ^ (0 * 0.25) */
 1.18920711500272106672, /* 2 ^ (1 * 0.25) */
 M_SQRT2   , /* 2 ^ (2 * 0.25) */
 1.68179283050742908606, /* 2 ^ (3 * 0.25) */
 };
-double cbrt_lut[16];
+static double pow43_lut[16];
+double exp2_base = 
2.11758236813575084767080625169910490512847900390625e-22; // 2^(-72)
+double exp2_val;
+double pow43_val = 0;
 for (i = 0; i < 16; ++i)
-cbrt_lut[i] = cbrt(i);
+pow43_lut[i] = i * cbrt(i);
 
 for (i = 1; i < TABLE_4_3_SIZE; i++) {
-double value = i / 4;
 double f, fm;
 int e, m;
-f  = value / IMDCT_SCALAR * cbrt(value) * exp2_lut[i & 3];
+double value = i / 4;
+if (i % 4 == 0)
+pow43_val = value / IMDCT_SCALAR * cbrt(value);
+f  = pow43_val * exp2_lut[i & 3];
 fm = frexp(f, &e);
-m  = (uint32_t)(fm * (1LL << 31) + 0.5);
+m  = llrint(fm * (1LL << 31));
 e += FRAC_BITS - 31 + 5 - 100;
 
 /* normalized to FRAC_BITS */
@@ -69,8 +74,11 @@ static av_cold void mpegaudio_tableinit(void)
 table_4_3_exp[i]   = -e;
 }
 for (exponent = 0; exponent < 512; exponent++) {
+if (exponent && exponent % 4 == 0)
+exp2_base *= 2;
+exp2_val = exp2_base * exp2_lut[exponent % 4] / IMDCT_SCALAR;
 for (value = 0; value < 16; value++) {
-double f = value * cbrt_lut[value] * pow(2, (exponent - 400) * 
0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
+double f = pow43_lut[value] * exp2_val;
 expval_table_fixed[exponent][value] = (f < 0x ? llrint(f) 
: 0x);
 expval_table_float[exponent][value] = f;
 }
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mpegencts: Fix overflow in cbr mode period calculations

[Michael Niedermayer]

On Fri, Nov 27, 2015 at 09:25:52PM +0200, Timo Teräs wrote:
> ts->mux_rate is int (signed 32-bit) type. The period calculations
> will start to overflow when mux_rate > 5mbps. This fixes overflows
> by using av_rescale().
> 
> Fixes #5044.
> 
> Signed-off-by: Timo Teräs 
> ---
>  libavformat/mpegtsenc.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index 468bad4..8c0987c 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -852,12 +852,9 @@ static int mpegts_write_header(AVFormatContext *s)
>  ts_st = pcr_st->priv_data;
>  
>  if (ts->mux_rate > 1) {
> -service->pcr_packet_period = (ts->mux_rate * ts->pcr_period) /
> - (TS_PACKET_SIZE * 8 * 1000);
> -ts->sdt_packet_period  = (ts->mux_rate * SDT_RETRANS_TIME) /
> - (TS_PACKET_SIZE * 8 * 1000);
> -ts->pat_packet_period  = (ts->mux_rate * PAT_RETRANS_TIME) /
> - (TS_PACKET_SIZE * 8 * 1000);
> +service->pcr_packet_period = av_rescale(ts->pcr_period,   
> ts->mux_rate, TS_PACKET_SIZE * 8 * 1000);
> +ts->sdt_packet_period  = av_rescale(SDT_RETRANS_TIME, 
> ts->mux_rate, TS_PACKET_SIZE * 8 * 1000);
> +ts->pat_packet_period  = av_rescale(PAT_RETRANS_TIME, 
> ts->mux_rate, TS_PACKET_SIZE * 8 * 1000);

The previous code did round down ensuring that the period was
smaller than the requested limit if inexact
see av_rescale_rnd() or int64_t could be used too


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/5] lavf/lxfdec: use FFERROR_REDO instead of AVERROR(EAGAIN).

[Michael Niedermayer]

On Fri, Nov 27, 2015 at 07:16:09PM +0100, Nicolas George wrote:
> Signed-off-by: Nicolas George 
> ---
>  libavformat/lxfdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> Untested.

should be ok (but didnt test either unless it was part of fate which
i run with the whole patchset ...)

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavf: add FFERROR_REDO to let demuxer return no packet.

[Michael Niedermayer]

On Fri, Nov 27, 2015 at 07:16:06PM +0100, Nicolas George wrote:
> Signed-off-by: Nicolas George 
> ---
>  libavformat/internal.h | 6 ++
>  libavformat/utils.c| 5 +
>  2 files changed, 11 insertions(+)
> 
> 
> Apparently, the most unhappyness was caused by the error code in the public
> API. This is not the case here.
> 
> 
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index ee86094..0f684bd 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -516,4 +516,10 @@ int ff_copy_whitelists(AVFormatContext *dst, 
> AVFormatContext *src);
>  int ffio_open2_wrapper(struct AVFormatContext *s, AVIOContext **pb, const 
> char *url, int flags,
> const AVIOInterruptCB *int_cb, AVDictionary 
> **options);
>  
> +/**
> + * Returned by demuxers to indicate that data was consumed but discarded
> + * (ignored streams or junk data). The framework will re-call the demuxer.
> + */
> +#define FFERROR_REDO FFERRTAG( 'R','E','D','O')
> +
>  #endif /* AVFORMAT_INTERNAL_H */
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8cb7d38..83e2f73 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -680,6 +680,11 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
>  av_init_packet(pkt);
>  ret = s->iformat->read_packet(s, pkt);
>  if (ret < 0) {
> +/* Some demuxer (FLV, MPEG-PS) return FFERROR_REDO when they

i dont think specific demuxers should be listed here, the list
would become outdated

patch LGTM otherwise

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mxfdec: fix seeking before the first keyframe

[Marton Balint]

Regression since 53f2ef2c4afb1d49a679dea9163cb0e4671f3117.
Fixes ticket #5017.

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 429f46a..926d2a3 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -3181,6 +3181,16 @@ static int mxf_read_seek(AVFormatContext *s, int 
stream_index, int64_t sample_ti
 sample_time = FFMAX(sample_time, 0);
 
 if (t->fake_index) {
+/* The first frames may not be keyframes in presentation order, so
+ * we have to advance the target to be able to find the first
+ * keyframe backwards... */
+if (!(flags & AVSEEK_FLAG_ANY) &&
+(flags & AVSEEK_FLAG_BACKWARD) &&
+t->ptses[0] != AV_NOPTS_VALUE &&
+sample_time < t->ptses[0] &&
+(t->fake_index[t->ptses[0]].flags & AVINDEX_KEYFRAME))
+sample_time = t->ptses[0];
+
 /* behave as if we have a proper index */
 if ((sample_time = ff_index_search_timestamp(t->fake_index, 
t->nb_ptses, sample_time, flags)) < 0)
 return sample_time;
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Fix huffman table test

[Carl Eugen Hoyos]

Hi!

Jpeg over rtp requires standard huffman tables, but the test I implemented 
was too strict. Attached patch tries to improve this, related to ticket #3823.

Please comment, Carl Eugen
diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c
index a6f2b32..4bdfdda 100644
--- a/libavformat/rtpenc_jpeg.c
+++ b/libavformat/rtpenc_jpeg.c
@@ -36,6 +36,7 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t 
*buf, int size)
 int off = 0; /* fragment offset of the current JPEG frame */
 int len;
 int i;
+int default_huffman_tables = 0;
 
 s->buf_ptr   = s->buf;
 s->timestamp = s->cur_timestamp;
@@ -90,23 +91,50 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t 
*buf, int size)
 return;
 }
 } else if (buf[i + 1] == DHT) {
-if (   AV_RB16(&buf[i + 2]) < 418
-|| i + 420 >= size
-|| buf[i +   4] != 0x00
-|| buf[i +  33] != 0x01
-|| buf[i +  62] != 0x10
-|| buf[i + 241] != 0x11
-|| memcmp(buf + i +   5, avpriv_mjpeg_bits_dc_luminance   + 1, 
16)
-|| memcmp(buf + i +  21, avpriv_mjpeg_val_dc, 12)
-|| memcmp(buf + i +  34, avpriv_mjpeg_bits_dc_chrominance + 1, 
16)
-|| memcmp(buf + i +  50, avpriv_mjpeg_val_dc, 12)
-|| memcmp(buf + i +  63, avpriv_mjpeg_bits_ac_luminance   + 1, 
16)
-|| memcmp(buf + i +  79, avpriv_mjpeg_val_ac_luminance, 162)
-|| memcmp(buf + i + 242, avpriv_mjpeg_bits_ac_chrominance + 1, 
16)
-|| memcmp(buf + i + 258, avpriv_mjpeg_val_ac_chrominance, 
162)) {
-av_log(s1, AV_LOG_ERROR,
-   "RFC 2435 requires standard Huffman tables for jpeg\n");
-return;
+int dht_size = AV_RB16(&buf[i + 2]);
+if (i + dht_size > size)
+continue;
+default_huffman_tables |= 1 << 4;
+i += 3;
+dht_size -= 3;
+while (dht_size > 0)
+switch (buf[i + 1]) {
+case 0x00:
+if (   dht_size >= 28
+&& !memcmp(buf + i +  2, 
avpriv_mjpeg_bits_dc_luminance + 1, 16)
+&& !memcmp(buf + i + 18, avpriv_mjpeg_val_dc, 12))
+default_huffman_tables |= 1;
+i += 29;
+dht_size -= 28;
+break;
+case 0x01:
+if (   dht_size >= 28
+&& !memcmp(buf + i +  2, 
avpriv_mjpeg_bits_dc_chrominance + 1, 16)
+&& !memcmp(buf + i + 18, avpriv_mjpeg_val_dc, 12))
+default_huffman_tables |= 1 << 1;
+i += 29;
+dht_size -= 28;
+break;
+case 0x10:
+if (   dht_size >= 178
+&& !memcmp(buf + i +  2, 
avpriv_mjpeg_bits_ac_luminance   + 1, 16)
+&& !memcmp(buf + i + 18, 
avpriv_mjpeg_val_ac_luminance, 162))
+default_huffman_tables |= 1 << 2;
+i += 179;
+dht_size -= 178;
+break;
+case 0x11:
+if (   dht_size >= 178
+&& !memcmp(buf + i +  2, 
avpriv_mjpeg_bits_ac_chrominance + 1, 16)
+&& !memcmp(buf + i + 18, 
avpriv_mjpeg_val_ac_chrominance, 162))
+default_huffman_tables |= 1 << 3;
+i += 179;
+dht_size -= 178;
+break;
+default:
+i += dht_size + 1;
+dht_size = 0;
+continue;
 }
 } else if (buf[i + 1] == SOS) {
 /* SOS is last marker in the header */
@@ -119,6 +147,11 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t 
*buf, int size)
 break;
 }
 }
+if (default_huffman_tables && default_huffman_tables != 31) {
+av_log(s1, AV_LOG_ERROR,
+   "RFC 2435 requires standard Huffman tables for jpeg\n");
+return;
+}
 if (nb_qtables && nb_qtables != 2)
 av_log(s1, AV_LOG_WARNING,
"RFC 2435 suggests two quantization tables, %d provided\n",
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: get rid of hardcoded tables entirely

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 6:14 PM, Rostislav Pehlivanov
 wrote:
> On Fri, 2015-11-27 at 17:07 -0500, Ganesh Ajjanagadde wrote:
>> Commit 96786a12f6df26990bbe7c0ca4592b3731724469 makes runtime
>> initialization cheap.
>
> Leaves a lot of the cruft around. aac_tablegen.h and
> aac_tablegen_decl.h are now quite unnecessary. I suggest getting rid of
> aac_tablegen* entirely and just moving everything entirely to aactab.h.
> Just move the function as a normal function in aactab.c (or just define
> it as a static inline in aactab.h since it's used only twice), define
> the 2 tables there and you'd be done.

I never really spent time understanding the header file, source file,
static, and extern stuff in C, and essentially just hacked around to
get something that builds cleanly and passes FATE. Someday, I need to
do this. With this caveat, have posted v2.

> ___
> 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

[FFmpeg-devel] [PATCHv2] avcodec/aac_tablegen: get rid of hardcoded tables entirely

[Ganesh Ajjanagadde]

Commit 96786a12f6df26990bbe7c0ca4592b3731724469 makes runtime
initialization cheap.

Tested with FATE, with/without --enable-hardcoded-tables.

Reviewed-by: Rostislav Pehlivanov 
Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/Makefile|  7 ++--
 libavcodec/aac_tablegen.c  | 39 
 libavcodec/aac_tablegen.h  | 82 --
 libavcodec/aac_tablegen_decl.h | 38 
 libavcodec/aaccoder.c  |  1 -
 libavcodec/aaccoder_trellis.h  |  2 --
 libavcodec/aaccoder_twoloop.h  |  1 -
 libavcodec/aacenc_utils.h  |  2 +-
 libavcodec/aactab.c|  4 ++-
 libavcodec/aactab.h| 52 ++-
 10 files changed, 57 insertions(+), 171 deletions(-)
 delete mode 100644 libavcodec/aac_tablegen.c
 delete mode 100644 libavcodec/aac_tablegen.h
 delete mode 100644 libavcodec/aac_tablegen_decl.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 68a573f..d85215d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -920,7 +920,6 @@ SLIBOBJS-$(HAVE_GNU_WINDRES)   += avcodecres.o
 
 SKIPHEADERS+= %_tablegen.h  \
   %_tables.h\
-  aac_tablegen_decl.h   \
   fft-internal.h\
   tableprint.h  \
   tableprint_vlc.h  \
@@ -964,8 +963,7 @@ TESTOBJS = dctref.o
 
 TOOLS = fourcc2pixfmt
 
-HOSTPROGS = aac_tablegen\
-aacps_tablegen  \
+HOSTPROGS = aacps_tablegen  \
 aacps_fixed_tablegen\
 aacsbr_tablegen \
 aacsbr_fixed_tablegen   \
@@ -999,7 +997,7 @@ $(SUBDIR)%_tablegen$(HOSTEXESUF): HOSTCFLAGS += 
-DCONFIG_SMALL=0
 endif
 
 GEN_HEADERS = cbrt_tables.h cbrt_fixed_tables.h aacps_tables.h 
aacps_fixed_tables.h aacsbr_tables.h \
-  aacsbr_fixed_tables.h aac_tables.h dsd_tables.h dv_tables.h \
+  aacsbr_fixed_tables.h dsd_tables.h dv_tables.h \
   sinewin_tables.h sinewin_fixed_tables.h mpegaudio_tables.h 
motionpixels_tables.h \
   pcm_tables.h qdm2_tables.h
 GEN_HEADERS := $(addprefix $(SUBDIR), $(GEN_HEADERS))
@@ -1014,7 +1012,6 @@ $(SUBDIR)aacps_float.o: $(SUBDIR)aacps_tables.h
 $(SUBDIR)aacps_fixed.o: $(SUBDIR)aacps_fixed_tables.h
 $(SUBDIR)aacsbr.o: $(SUBDIR)aacsbr_tables.h
 $(SUBDIR)aacsbr_fixed.o: $(SUBDIR)aacsbr_fixed_tables.h
-$(SUBDIR)aactab.o: $(SUBDIR)aac_tables.h
 $(SUBDIR)aactab_fixed.o: $(SUBDIR)aac_fixed_tables.h
 $(SUBDIR)dsddec.o: $(SUBDIR)dsd_tables.h
 $(SUBDIR)dvenc.o: $(SUBDIR)dv_tables.h
diff --git a/libavcodec/aac_tablegen.c b/libavcodec/aac_tablegen.c
deleted file mode 100644
index 2d13211..000
--- a/libavcodec/aac_tablegen.c
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * Generate a header file for hardcoded AAC tables
- *
- * Copyright (c) 2010 Alex Converse 
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include 
-#define CONFIG_HARDCODED_TABLES 0
-#include "aac_tablegen.h"
-#include "tableprint.h"
-
-int main(void)
-{
-ff_aac_tableinit();
-
-write_fileheader();
-
-WRITE_ARRAY("const", float, ff_aac_pow2sf_tab);
-
-WRITE_ARRAY("const", float, ff_aac_pow34sf_tab);
-
-return 0;
-}
diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
deleted file mode 100644
index e7d96d5..000
--- a/libavcodec/aac_tablegen.h
+++ /dev/null
@@ -1,82 +0,0 @@
-/*
- * Header file for hardcoded AAC tables
- *
- * Copyright (c) 2010 Alex Converse 
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distribu

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: get rid of hardcoded tables entirely

[Rostislav Pehlivanov]

On Fri, 2015-11-27 at 17:07 -0500, Ganesh Ajjanagadde wrote:
> Commit 96786a12f6df26990bbe7c0ca4592b3731724469 makes runtime
> initialization cheap.

Leaves a lot of the cruft around. aac_tablegen.h and
aac_tablegen_decl.h are now quite unnecessary. I suggest getting rid of
aac_tablegen* entirely and just moving everything entirely to aactab.h.
Just move the function as a normal function in aactab.c (or just define
it as a static inline in aactab.h since it's used only twice), define
the 2 tables there and you'd be done.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] fate/concatdec: Use -bitexact

[Timothy Gu]

Fixes FATE failures on --enable-small builds.
---
 tests/fate-run.sh   | 4 ++--
 tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
 tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
 tests/ref/fate/concat-demuxer-simple1-lavf-mxf  | 4 ++--
 tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10  | 4 ++--
 tests/ref/fate/concat-demuxer-simple2-lavf-ts   | 4 ++--
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 03fa898..16087cb 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -262,10 +262,10 @@ concat(){
 awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
 
 if [ "$mode" = "md5" ]; then
-run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags 
keepside -safe 0 $extra_args $concatfile | tr -d '\r' > $packetfile
+run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -v 0 
-fflags keepside -safe 0 $extra_args $concatfile | tr -d '\r' > $packetfile
 do_md5sum $packetfile
 else
-run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -of 
compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
+run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -v 0 -of 
compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
 fi
 }
 
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf 
b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
index 536fba2..4caec5a 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
@@ -1 +1 @@
-aa6477bcaef182919ac0c08ed74b32a1 
*tests/data/fate/concat-demuxer-extended-lavf-mxf.ffprobe
+37b4a84fce71b3f8b129f8b866c5f55a 
*tests/data/fate/concat-demuxer-extended-lavf-mxf.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 
b/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
index ce68520..1965050 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
@@ -1 +1 @@
-651eca7722187ff6836f55826bb1d110 
*tests/data/fate/concat-demuxer-extended-lavf-mxf_d10.ffprobe
+2f5e935f86304c843be1454b1354a4b7 
*tests/data/fate/concat-demuxer-extended-lavf-mxf_d10.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-simple1-lavf-mxf 
b/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
index 754080e..c28db28 100644
--- a/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
@@ -120,5 +120,5 @@ 
audio|1|65280|1.36|65280|1.36|1920|0.04|N/A|N/A|3840|206848|K|1
 Strings Metadata|8
 video|0|37|1.48|34|1.36|1|0.04|N/A|N/A|24786|211456|K|1
 Strings Metadata|8
-0|mpeg2video|MPEG-2 
video|Main|video|1/50|[0][0][0][0]|0x|352|288|0|0|1|1:1|11:9|yuv420p|8|tv|unknown|unknown|unknown|left|00:00:00:00|1|N/A|25/1|25/1|1/25|N/A|N/A|N/A|N/A|N/A|104857200|N/A|N/A|N/A|51|0|0|0|0|0|0|0|0|0|0|0|0x060A2B340101010501010D001301
-1|pcm_s16le|PCM signed 16-bit 
little-endian|unknown|audio|1/48000|[0][0][0][0]|0x|s16|48000|1|unknown|16|N/A|0/0|0/0|1/48000|0|0.00|N/A|N/A|768000|N/A|N/A|N/A|N/A|50|0|0|0|0|0|0|0|0|0|0|0|0x060A2B340101010501010D001301
+0|mpeg2video|4|video|1/50|[0][0][0][0]|0x|352|288|0|0|1|1:1|11:9|yuv420p|8|tv|unknown|unknown|unknown|left|00:00:00:00|1|N/A|25/1|25/1|1/25|N/A|N/A|N/A|N/A|N/A|104857200|N/A|N/A|N/A|51|0|0|0|0|0|0|0|0|0|0|0|0x060A2B340101010501010D001301
+1|pcm_s16le|unknown|audio|1/48000|[0][0][0][0]|0x|s16|48000|1|unknown|16|N/A|0/0|0/0|1/48000|0|0.00|N/A|N/A|768000|N/A|N/A|N/A|N/A|50|0|0|0|0|0|0|0|0|0|0|0|0x060A2B340101010501010D001301
diff --git a/tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10 
b/tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10
index f573eae..3b6e3fe 100644
--- a/tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10
+++ b/tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10
@@ -78,5 +78,5 @@ 
video|0|34|1.36|34|1.36|1|0.04|N/A|N/A|15|1923072|K|1
 Strings Metadata|8
 audio|1|65280|1.36|65280|1.36|1920|0.04|N/A|N/A|7680|2073600|K|1
 Strings Metadata|8
-0|mpeg2video|MPEG-2 
video|4:2:2|video|1/50|[0][0][0][0]|0x|720|608|0|0|0|1:1|45:38|yuv422p|5|tv|unknown|unknown|unknown|topleft|00:00:00:00|1|N/A|25/1|25/1|1/25|0|0.00|N/A|N/A|3000|3000|N/A|N/A|N/A|35|0|0|0|0|0|0|0|0|0|0|0|0x060A2B340101010501010D001301
-1|pcm_s16le|PCM signed 16-bit 
little-endian|unknown|audio|1/48000|[0][0][0][0]|0x|s16|48000|2|unknown|16|N/A|0/0|0/0|1/48000|0|0.00|N/A|N/A|1536000|N/A|N/A|N/A|N/A|35|0|0|0|0|0|0|0|0|0|0|0|0x060A2B340101010501010D001301
+0|mpeg2video|0|video|1/50|[0][0][0][0]|0x|720|608|0|0|0|1:1|45:38|yuv422p|5|tv|unknown|unknown|unknown|topleft|00:00:00:00|1|N/A|25/1|25/1

[FFmpeg-devel] [PATCH 1/2] ffprobe: Do not print profile names in -bitexact

[Timothy Gu]

Instead, print "unknown" if it's unknown, or their numerical values if
they are known.
---

Addresses Nicholas's comment.

---
 ffprobe.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index c304a6d..7128083 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2148,10 +2148,16 @@ static int show_stream(WriterContext *w, 
AVFormatContext *fmt_ctx, int stream_id
 }
 }
 
-if (dec && (profile = av_get_profile_name(dec, dec_ctx->profile)))
+if (!do_bitexact && dec && (profile = av_get_profile_name(dec, 
dec_ctx->profile)))
 print_str("profile", profile);
-else
-print_str_opt("profile", "unknown");
+else {
+if (dec_ctx->profile != FF_PROFILE_UNKNOWN) {
+char profile_num[12];
+snprintf(profile_num, sizeof(profile_num), "%d", 
dec_ctx->profile);
+print_str("profile", profile_num);
+} else
+print_str_opt("profile", "unknown");
+}
 
 s = av_get_media_type_string(dec_ctx->codec_type);
 if (s) print_str("codec_type", s);
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 4:33 PM, Rostislav Pehlivanov
 wrote:
> On Fri, 2015-11-27 at 15:59 -0500, Ganesh Ajjanagadde wrote:
>> I get build failures starting with commit
>> 3d62e7a30fa552be52d12b31e3e0f79153aff891 under
>> --enable-hardcoded-tables.
>> @Rostislav: can you check, reproduce, and resolve this?
>
> Fixed, thanks for reporting it quickly. Problem was
> that ff_aac_tableinit() couldn't be used as an argument to
> ff_thread_once(pthread_once) as it was a macro in the case of hardcoded
> tables.

Thanks for the quick fix, posted a patch for removing associated
ifdefry in aac_tablegen, i.e always runtime initing these tables.

> ___
> 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

[FFmpeg-devel] [PATCH] avcodec/aac_tablegen: get rid of hardcoded tables entirely

[Ganesh Ajjanagadde]

Commit 96786a12f6df26990bbe7c0ca4592b3731724469 makes runtime
initialization cheap.

Tested with FATE, with/without --enable-hardcoded-tables.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/Makefile|  6 ++
 libavcodec/aac_tablegen.c  | 39 ---
 libavcodec/aac_tablegen.h  |  4 
 libavcodec/aac_tablegen_decl.h |  6 --
 4 files changed, 2 insertions(+), 53 deletions(-)
 delete mode 100644 libavcodec/aac_tablegen.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 68a573f..e4a6a38 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -964,8 +964,7 @@ TESTOBJS = dctref.o
 
 TOOLS = fourcc2pixfmt
 
-HOSTPROGS = aac_tablegen\
-aacps_tablegen  \
+HOSTPROGS = aacps_tablegen  \
 aacps_fixed_tablegen\
 aacsbr_tablegen \
 aacsbr_fixed_tablegen   \
@@ -999,7 +998,7 @@ $(SUBDIR)%_tablegen$(HOSTEXESUF): HOSTCFLAGS += 
-DCONFIG_SMALL=0
 endif
 
 GEN_HEADERS = cbrt_tables.h cbrt_fixed_tables.h aacps_tables.h 
aacps_fixed_tables.h aacsbr_tables.h \
-  aacsbr_fixed_tables.h aac_tables.h dsd_tables.h dv_tables.h \
+  aacsbr_fixed_tables.h dsd_tables.h dv_tables.h \
   sinewin_tables.h sinewin_fixed_tables.h mpegaudio_tables.h 
motionpixels_tables.h \
   pcm_tables.h qdm2_tables.h
 GEN_HEADERS := $(addprefix $(SUBDIR), $(GEN_HEADERS))
@@ -1014,7 +1013,6 @@ $(SUBDIR)aacps_float.o: $(SUBDIR)aacps_tables.h
 $(SUBDIR)aacps_fixed.o: $(SUBDIR)aacps_fixed_tables.h
 $(SUBDIR)aacsbr.o: $(SUBDIR)aacsbr_tables.h
 $(SUBDIR)aacsbr_fixed.o: $(SUBDIR)aacsbr_fixed_tables.h
-$(SUBDIR)aactab.o: $(SUBDIR)aac_tables.h
 $(SUBDIR)aactab_fixed.o: $(SUBDIR)aac_fixed_tables.h
 $(SUBDIR)dsddec.o: $(SUBDIR)dsd_tables.h
 $(SUBDIR)dvenc.o: $(SUBDIR)dv_tables.h
diff --git a/libavcodec/aac_tablegen.c b/libavcodec/aac_tablegen.c
deleted file mode 100644
index 2d13211..000
--- a/libavcodec/aac_tablegen.c
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * Generate a header file for hardcoded AAC tables
- *
- * Copyright (c) 2010 Alex Converse 
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include 
-#define CONFIG_HARDCODED_TABLES 0
-#include "aac_tablegen.h"
-#include "tableprint.h"
-
-int main(void)
-{
-ff_aac_tableinit();
-
-write_fileheader();
-
-WRITE_ARRAY("const", float, ff_aac_pow2sf_tab);
-
-WRITE_ARRAY("const", float, ff_aac_pow34sf_tab);
-
-return 0;
-}
diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
index e7d96d5..2032650 100644
--- a/libavcodec/aac_tablegen.h
+++ b/libavcodec/aac_tablegen.h
@@ -25,9 +25,6 @@
 
 #include "aac_tablegen_decl.h"
 
-#if CONFIG_HARDCODED_TABLES
-#include "libavcodec/aac_tables.h"
-#else
 #include "libavutil/mathematics.h"
 float ff_aac_pow2sf_tab[428];
 float ff_aac_pow34sf_tab[428];
@@ -77,6 +74,5 @@ av_cold void ff_aac_tableinit(void)
 t2_inc_prev = t2_inc_cur;
 }
 }
-#endif /* CONFIG_HARDCODED_TABLES */
 
 #endif /* AVCODEC_AAC_TABLEGEN_H */
diff --git a/libavcodec/aac_tablegen_decl.h b/libavcodec/aac_tablegen_decl.h
index ef86f85..5916971 100644
--- a/libavcodec/aac_tablegen_decl.h
+++ b/libavcodec/aac_tablegen_decl.h
@@ -25,14 +25,8 @@
 
 #define POW_SF2_ZERO200///< ff_aac_pow2sf_tab index corresponding to 
pow(2, 0);
 
-#if CONFIG_HARDCODED_TABLES
-#define ff_aac_tableinit()
-extern const float ff_aac_pow2sf_tab[428];
-extern const float ff_aac_pow34sf_tab[428];
-#else
 void ff_aac_tableinit(void);
 extern   float ff_aac_pow2sf_tab[428];
 extern   float ff_aac_pow34sf_tab[428];
-#endif /* CONFIG_HARDCODED_TABLES */
 
 #endif /* AVCODEC_AAC_TABLEGEN_DECL_H */
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Rostislav Pehlivanov]

On Fri, 2015-11-27 at 15:59 -0500, Ganesh Ajjanagadde wrote:
> I get build failures starting with commit
> 3d62e7a30fa552be52d12b31e3e0f79153aff891 under
> --enable-hardcoded-tables.
> @Rostislav: can you check, reproduce, and resolve this?

Fixed, thanks for reporting it quickly. Problem was
that ff_aac_tableinit() couldn't be used as an argument to
ff_thread_once(pthread_once) as it was a macro in the case of hardcoded
tables.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 1:00 PM, Rostislav Pehlivanov
 wrote:
> On Fri, 2015-11-27 at 18:50 +0100, Hendrik Leppkes wrote:
>> Note that the init is wrong for float as well. You use the same
>> condition for aacenc and aacdec, but they init different things.
>> aacdec inits much more, and if aacenc would init first for some
>> reason, it would leave aacdec without half its init.
>
> Yes, realized that. Partially reverted the patch. Now the aac encoder
> and decoder can init the table twice but this is less than an evil than
> the alternative. So I think it might just be better to leave things as
> they were and live with initializing it twice in case someone
> transcodes aac->aac using the native encoder.
>
>
> On Fri, 2015-11-27 at 18:37 +0100, wm4 wrote:
>> Such changes should be put up for review anyway.
>
> Was on the fence about whether to put it up for review but it seemed
> like a small patch.

I get build failures starting with commit
3d62e7a30fa552be52d12b31e3e0f79153aff891 under
--enable-hardcoded-tables.
@Rostislav: can you check, reproduce, and resolve this?

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mxfdec: Set width to actual coded_width for AVCI50

[Tomas Härdin]

On Thu, 2015-11-26 at 00:48 +0100, Carl Eugen Hoyos wrote:
> On Wednesday 25 November 2015 12:57:07 am Tomas Härdin wrote:
> > On Tue, 2015-11-24 at 12:02 +0100, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Attached patch fixes ticket #5029.
> > >
> > > Please comment, Carl Eugen
> >
> > Looks simple enough, but (ab)using MXFCodecUL like that 
> > has a slight stink to it.
> 
> It was abused for pix_fmts before, and I added a usage for 
> codec_tag in July. MXFCodecUL uses an int for the third 
> parameter which is exactly what is needed for width.
> 
> > Can we perhaps rename the struct to something that signals 
> > its more general use of mapping ULs to integers?
> 
> I will rename it if you make a suggestion...
> 
> > Another thing: don't we have some table like this for 
> > H.264 in MXF already?
> 
> There are tables that contain H.263 as codec_id but the 
> width is needed for this ticket.
> 
> Ok to apply?

Sure, we can take the renaming separately. Something that's been bugging
me for a while is this use of large tables without any thought to
optimization. Perhaps it is time to add some generic container code to
lavu or more preferrably: nicking some existing code (perhaps from the
kernel?)

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[wm4]

On Fri, 27 Nov 2015 15:14:54 -0500
Alex Agranovsky  wrote:

> 
> Hi - are there any additional corrections I need to address on this set of 
> patches, or is it good to go at this point?

Sorry, forgot about it, will look tomorrow.

Also, the quoting in your replies is completely messed up. I can't tell
what is text from others and what you have written.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[Alex Agranovsky]

On November 25, 2015 at 10:35:33 AM, Alex Agranovsky (a...@sighthound.com) 
wrote:

On November 24, 2015 at 6:06:36 PM, Michael Niedermayer (michae...@gmx.at) 
wrote:

On Tue, Nov 24, 2015 at 03:01:28PM -0500, Alex Agranovsky wrote: 
[...] 

> From 2c253d7978a6c9c2dc701d393eb5b9d68e831c98 Mon Sep 17 00:00:00 2001 
> From: Alex Agranovsky  
> Date: Tue, 24 Nov 2015 00:07:34 -0500 
> Subject: [PATCH 2/2] If available, use the actual boundary in HTTP response's 
> Content-Type header, to separate MIME parts in mpjpeg stream 
> 
> This code is disabled by default so not to break some fragile endpoints 
> sending invalid MIME, but can be enabled via AVOption 'strict_mime_boundary' 
> 
> Signed-off-by: Alex Agranovsky  
> --- 
> libavformat/mpjpegdec.c | 75 
> +++-- 
> 1 file changed, 72 insertions(+), 3 deletions(-) 
> 
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c 
> index b9093ea..b89f128 100644 
> --- a/libavformat/mpjpegdec.c 
> +++ b/libavformat/mpjpegdec.c 
> @@ -20,6 +20,7 @@ 
> */ 
>  
> #include "libavutil/avstring.h" 
> +#include "libavutil/opt.h" 
>  
> #include "avformat.h" 
> #include "internal.h" 
> @@ -28,9 +29,11 @@ 
>  
>  
> typedef struct MPJPEGDemuxContext { 
> + const AVClass *class; 
> char* boundary; 
> char* searchstr; 
> int searchstr_len; 
> + int strict_mime_boundary; 
> } MPJPEGDemuxContext; 
>  
>  
> @@ -245,6 +248,43 @@ static int parse_multipart_header(AVIOContext *pb, 
> } 
>  
>  
> +static char* mpjpeg_get_boundary(AVIOContext* pb) 
> +{ 
> + uint8_t *mime_type = NULL; 
> + uint8_t *start; 
> + uint8_t *end; 
> + uint8_t *res = NULL; 
> + int len; 
> + 
> + /* get MIME type, and skip to the first parameter */ 
> + av_opt_get(pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &mime_type); 
> + start = mime_type; 
> + while (start != NULL && *start != '\0') { 
> + start = strchr(start, ';'); 
> + if (start) 
> + start = start+1; 
> + 
> + while (av_isspace(*start)) 
> + start++; 
> + 
> + if (!av_strncasecmp(start, "boundary=", 9)) { 
> + start += 9; 
> + 
> + end = strchr(start, ';'); 
> + if (end) 
> + len = end - start - 1; 
> + else 
> + len = strlen(start); 
> + res = av_strndup(start, len); 
> + break; 
> + } 
> + } 
> + 
> + av_freep(&mime_type); 
> + return res; 
> +} 
> + 
> + 
> static int mpjpeg_read_packet(AVFormatContext *s, AVPacket *pkt) 
> { 
> int size; 
> @@ -252,8 +292,18 @@ static int mpjpeg_read_packet(AVFormatContext *s, 
> AVPacket *pkt) 
>  
> MPJPEGDemuxContext *mpjpeg = s->priv_data; 
> if (mpjpeg->boundary == NULL) { 
> - mpjpeg->boundary = av_strdup("--"); 
> - mpjpeg->searchstr = av_strdup("\r\n--"); 
> + uint8_t* boundary = NULL; 
> + if (mpjpeg->strict_mime_boundary) { 
> + boundary = mpjpeg_get_boundary(s->pb); 
> + } 
> + if (boundary != NULL) { 
> + mpjpeg->boundary = boundary; 
> + mpjpeg->searchstr = av_malloc(4+strlen(boundary)+1); 

> + sprintf( mpjpeg->searchstr, "\r\n%s\r\n", boundary ); 

please use snprintf() 


> + } else { 
> + mpjpeg->boundary = av_strdup("--"); 
> + mpjpeg->searchstr = av_strdup("\r\n--"); 
> + } 
> mpjpeg->searchstr_len = strlen(mpjpeg->searchstr); 
> if (!mpjpeg->boundary || !mpjpeg->searchstr) { 
> av_freep(&mpjpeg->boundary); 
> @@ -315,6 +365,22 @@ static int mpjpeg_read_packet(AVFormatContext *s, 
> AVPacket *pkt) 
> return ret; 
> } 
>  
> +#define OFFSET(x) offsetof(MPJPEGDemuxContext, x) 
> + 
> +#define DEC AV_OPT_FLAG_DECODING_PARAM 
> +const AVOption mpjpeg_options[] = { 
> + { "strict_mime_boundary", "require MIME boundaries match", 
> OFFSET(strict_mime_boundary), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, DEC }, 
> + { NULL } 
> +}; 
> + 
> + 

> +static const AVClass ff_mpjpeg_demuxer_class = { 

there should be no ff_ as its static 


> + .class_name = "MPJPEG demuxer", 
> + .item_name = av_default_item_name, 
> + .option = mpjpeg_options, 
> + .version = LIBAVUTIL_VERSION_INT, 
> +}; 
> + 
> AVInputFormat ff_mpjpeg_demuxer = { 
> .name = "mpjpeg", 
> .long_name = NULL_IF_CONFIG_SMALL("MIME multipart JPEG"), 
> @@ -324,5 +390,8 @@ AVInputFormat ff_mpjpeg_demuxer = { 
> .read_probe = mpjpeg_read_probe, 
> .read_header = mpjpeg_read_header, 
> .read_packet = mpjpeg_read_packet, 
> - .read_close = mpjpeg_read_close 
> + .read_close = mpjpeg_read_close, 
> + .priv_class = &ff_mpjpeg_demuxer_class 
> }; 
> + 
> + 
> -- 
> 2.4.9 (Apple Git-60) 
> 

> ___ 
> ffmpeg-devel mailing list 
> ffmpeg-devel@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB 

Awnsering whenever a program halts or runs forever is 
On a turing machine, in general impossible (turings halting problem). 
On any real computer, always possible as a real computer has a finite number 
of states N, and will either halt in less than N cycles or never halt. 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org

Re: [FFmpeg-devel] [PATCH] aac: prevent calling ff_aac_tableinit() twice during init

[Hendrik Leppkes]

On Fri, Nov 27, 2015 at 8:00 PM, Rostislav Pehlivanov
 wrote:
> This commit prevents the corner case where both the decoder and the
> encoder could call ff_aac_tableinit() twice during init (in case of
> transcoding aac-aac).
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/aacdec_template.c | 10 ++
>  libavcodec/aacenc.c  |  5 +
>  libavcodec/aactab.c  |  3 +++
>  libavcodec/aactab.h  |  3 +++
>  4 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index 620600c..a68ded6 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -1081,8 +1081,6 @@ static av_cold void aac_static_table_init(void)
>
>  AAC_RENAME(ff_aac_sbr_init)();
>
> -ff_aac_tableinit();
> -
>  INIT_VLC_STATIC(&vlc_scalefactors, 7,
>  FF_ARRAY_ELEMS(ff_aac_scalefactor_code),
>  ff_aac_scalefactor_bits,
> @@ -1103,14 +1101,18 @@ static av_cold void aac_static_table_init(void)
>  AAC_RENAME(cbrt_tableinit)();
>  }
>
> -static AVOnce aac_table_init = AV_ONCE_INIT;
> +static AVOnce aac_dec_tab_init_guard = AV_ONCE_INIT;
>
>  static av_cold int aac_decode_init(AVCodecContext *avctx)
>  {
>  AACContext *ac = avctx->priv_data;
>  int ret;
>
> -ret = ff_thread_once(&aac_table_init, &aac_static_table_init);
> +ret = ff_thread_once(&aactab_init_guard, &ff_aac_tableinit);
> +if (ret != 0)
> +return AVERROR_UNKNOWN;

I would just put this part inside aac_static_table_init, instead of
moving it here.
Nesting once calls shouldn't hurt, I don't think.

> +
> +ret = ff_thread_once(&aac_dec_tab_init_guard, &aac_static_table_init);
>  if (ret != 0)
>  return AVERROR_UNKNOWN;
>
> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> index e49cf4b..d58aff4 100644
> --- a/libavcodec/aacenc.c
> +++ b/libavcodec/aacenc.c
> @@ -29,7 +29,6 @@
>   * add sane pulse detection
>   ***/
>
> -#include "libavutil/thread.h"
>  #include "libavutil/float_dsp.h"
>  #include "libavutil/opt.h"
>  #include "avcodec.h"
> @@ -47,8 +46,6 @@
>
>  #include "psymodel.h"
>
> -static AVOnce aac_table_init = AV_ONCE_INIT;
> -
>  /**
>   * Make AAC audio config object.
>   * @see 1.6.2.1 "Syntax - AudioSpecificConfig"
> @@ -989,7 +986,7 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
>  if (HAVE_MIPSDSPR1)
>  ff_aac_coder_init_mips(s);
>
> -if ((ret = ff_thread_once(&aac_table_init, &ff_aac_tableinit)) != 0)
> +if ((ret = ff_thread_once(&aactab_init_guard, &ff_aac_tableinit)) != 0)
>  return AVERROR_UNKNOWN;
>
>  ff_af_queue_init(avctx, &s->afq);
> diff --git a/libavcodec/aactab.c b/libavcodec/aactab.c
> index dc9acc1..667b0ba 100644
> --- a/libavcodec/aactab.c
> +++ b/libavcodec/aactab.c
> @@ -27,12 +27,15 @@
>   * @author Maxim Gavrilov ( maxim.gavrilov gmail com )
>   */
>
> +#include "libavutil/thread.h"
>  #include "libavutil/mem.h"
>  #include "aac.h"
>  #include "aac_tablegen.h"
>
>  #include 
>
> +AVOnce aactab_init_guard = AV_ONCE_INIT;
> +
>  DECLARE_ALIGNED(32, float,  ff_aac_kbd_long_1024)[1024];
>  DECLARE_ALIGNED(32, float,  ff_aac_kbd_short_128)[128];
>  DECLARE_ALIGNED(32, int,ff_aac_kbd_long_1024_fixed)[1024];
> diff --git a/libavcodec/aactab.h b/libavcodec/aactab.h
> index 321c5d3..18c46a6 100644
> --- a/libavcodec/aactab.h
> +++ b/libavcodec/aactab.h
> @@ -30,6 +30,7 @@
>  #ifndef AVCODEC_AACTAB_H
>  #define AVCODEC_AACTAB_H
>
> +#include "libavutil/thread.h"
>  #include "libavutil/mem.h"
>  #include "aac.h"
>  #include "aac_tablegen_decl.h"
> @@ -40,6 +41,8 @@
>   * Tables in this file are shared by the AAC decoders and encoder
>   */
>
> +extern AVOnce aactab_init_guard; /* Protects ff_aac_tableinit() */
> +
>  /* @name ltp_coef
>   * Table of the LTP coefficients
>   */
> --
> 2.6.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

[Marton Balint]

On Fri, 27 Nov 2015, Nicolas George wrote:


I am not sure distinguishing the different cases (packet in a disabled
stream, utility data, corrupted data until a sync word) is very important.


I think it is, loss off sync means data loss, which is a severe error 
condition for some use cases. Anyway, as long as the error code you add 
now to replace EAGAIN-s remain private, this can be fixed later.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_dynaudnorm: remove pow2

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 2:24 PM, Paul B Mahol  wrote:
> On 11/27/15, Ganesh Ajjanagadde  wrote:
>> On Wed, Nov 25, 2015 at 10:36 AM, Ronald S. Bultje 
>> wrote:
>>> Hi,
>>>
>>> On Wed, Nov 25, 2015 at 8:00 AM, Ganesh Ajjanagadde
>>> 
>>> wrote:

 pow2 is being used for trivial squaring. Its name is not good: is this
 2^x or x^2?
>>>
>>>
>>> 2^x is exp2, not pow2. (I have no opinion on the patch itself.)
>>>
>>> Ronald
>>
>> @Paul: is this patch fine?
>
> You could add macro SQR.

I don't like macro for such things; in such a case I find pow2
superior. Patch dropped then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] mpegencts: Fix overflow in cbr mode period calculations

[Timo Teräs]

ts->mux_rate is int (signed 32-bit) type. The period calculations
will start to overflow when mux_rate > 5mbps. This fixes overflows
by using av_rescale().

Fixes #5044.

Signed-off-by: Timo Teräs 
---
 libavformat/mpegtsenc.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 468bad4..8c0987c 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -852,12 +852,9 @@ static int mpegts_write_header(AVFormatContext *s)
 ts_st = pcr_st->priv_data;
 
 if (ts->mux_rate > 1) {
-service->pcr_packet_period = (ts->mux_rate * ts->pcr_period) /
- (TS_PACKET_SIZE * 8 * 1000);
-ts->sdt_packet_period  = (ts->mux_rate * SDT_RETRANS_TIME) /
- (TS_PACKET_SIZE * 8 * 1000);
-ts->pat_packet_period  = (ts->mux_rate * PAT_RETRANS_TIME) /
- (TS_PACKET_SIZE * 8 * 1000);
+service->pcr_packet_period = av_rescale(ts->pcr_period,   
ts->mux_rate, TS_PACKET_SIZE * 8 * 1000);
+ts->sdt_packet_period  = av_rescale(SDT_RETRANS_TIME, 
ts->mux_rate, TS_PACKET_SIZE * 8 * 1000);
+ts->pat_packet_period  = av_rescale(PAT_RETRANS_TIME, 
ts->mux_rate, TS_PACKET_SIZE * 8 * 1000);
 
 if (ts->copyts < 1)
 ts->first_pcr = av_rescale(s->max_delay, PCR_TIME_BASE, 
AV_TIME_BASE);
-- 
2.6.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_dynaudnorm: remove pow2

[Paul B Mahol]

On 11/27/15, Ganesh Ajjanagadde  wrote:
> On Wed, Nov 25, 2015 at 10:36 AM, Ronald S. Bultje 
> wrote:
>> Hi,
>>
>> On Wed, Nov 25, 2015 at 8:00 AM, Ganesh Ajjanagadde
>> 
>> wrote:
>>>
>>> pow2 is being used for trivial squaring. Its name is not good: is this
>>> 2^x or x^2?
>>
>>
>> 2^x is exp2, not pow2. (I have no opinion on the patch itself.)
>>
>> Ronald
>
> @Paul: is this patch fine?

You could add macro SQR.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] aac: prevent calling ff_aac_tableinit() twice during init

[Rostislav Pehlivanov]

This commit prevents the corner case where both the decoder and the
encoder could call ff_aac_tableinit() twice during init (in case of
transcoding aac-aac).

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/aacdec_template.c | 10 ++
 libavcodec/aacenc.c  |  5 +
 libavcodec/aactab.c  |  3 +++
 libavcodec/aactab.h  |  3 +++
 4 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 620600c..a68ded6 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -1081,8 +1081,6 @@ static av_cold void aac_static_table_init(void)
 
 AAC_RENAME(ff_aac_sbr_init)();
 
-ff_aac_tableinit();
-
 INIT_VLC_STATIC(&vlc_scalefactors, 7,
 FF_ARRAY_ELEMS(ff_aac_scalefactor_code),
 ff_aac_scalefactor_bits,
@@ -1103,14 +1101,18 @@ static av_cold void aac_static_table_init(void)
 AAC_RENAME(cbrt_tableinit)();
 }
 
-static AVOnce aac_table_init = AV_ONCE_INIT;
+static AVOnce aac_dec_tab_init_guard = AV_ONCE_INIT;
 
 static av_cold int aac_decode_init(AVCodecContext *avctx)
 {
 AACContext *ac = avctx->priv_data;
 int ret;
 
-ret = ff_thread_once(&aac_table_init, &aac_static_table_init);
+ret = ff_thread_once(&aactab_init_guard, &ff_aac_tableinit);
+if (ret != 0)
+return AVERROR_UNKNOWN;
+
+ret = ff_thread_once(&aac_dec_tab_init_guard, &aac_static_table_init);
 if (ret != 0)
 return AVERROR_UNKNOWN;
 
diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index e49cf4b..d58aff4 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -29,7 +29,6 @@
  * add sane pulse detection
  ***/
 
-#include "libavutil/thread.h"
 #include "libavutil/float_dsp.h"
 #include "libavutil/opt.h"
 #include "avcodec.h"
@@ -47,8 +46,6 @@
 
 #include "psymodel.h"
 
-static AVOnce aac_table_init = AV_ONCE_INIT;
-
 /**
  * Make AAC audio config object.
  * @see 1.6.2.1 "Syntax - AudioSpecificConfig"
@@ -989,7 +986,7 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
 if (HAVE_MIPSDSPR1)
 ff_aac_coder_init_mips(s);
 
-if ((ret = ff_thread_once(&aac_table_init, &ff_aac_tableinit)) != 0)
+if ((ret = ff_thread_once(&aactab_init_guard, &ff_aac_tableinit)) != 0)
 return AVERROR_UNKNOWN;
 
 ff_af_queue_init(avctx, &s->afq);
diff --git a/libavcodec/aactab.c b/libavcodec/aactab.c
index dc9acc1..667b0ba 100644
--- a/libavcodec/aactab.c
+++ b/libavcodec/aactab.c
@@ -27,12 +27,15 @@
  * @author Maxim Gavrilov ( maxim.gavrilov gmail com )
  */
 
+#include "libavutil/thread.h"
 #include "libavutil/mem.h"
 #include "aac.h"
 #include "aac_tablegen.h"
 
 #include 
 
+AVOnce aactab_init_guard = AV_ONCE_INIT;
+
 DECLARE_ALIGNED(32, float,  ff_aac_kbd_long_1024)[1024];
 DECLARE_ALIGNED(32, float,  ff_aac_kbd_short_128)[128];
 DECLARE_ALIGNED(32, int,ff_aac_kbd_long_1024_fixed)[1024];
diff --git a/libavcodec/aactab.h b/libavcodec/aactab.h
index 321c5d3..18c46a6 100644
--- a/libavcodec/aactab.h
+++ b/libavcodec/aactab.h
@@ -30,6 +30,7 @@
 #ifndef AVCODEC_AACTAB_H
 #define AVCODEC_AACTAB_H
 
+#include "libavutil/thread.h"
 #include "libavutil/mem.h"
 #include "aac.h"
 #include "aac_tablegen_decl.h"
@@ -40,6 +41,8 @@
  * Tables in this file are shared by the AAC decoders and encoder
  */
 
+extern AVOnce aactab_init_guard; /* Protects ff_aac_tableinit() */
+
 /* @name ltp_coef
  * Table of the LTP coefficients
  */
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavf: add FFERROR_REDO to let demuxer return no packet.

[Clément Bœsch]

On Fri, Nov 27, 2015 at 07:16:06PM +0100, Nicolas George wrote:
> Signed-off-by: Nicolas George 
> ---
>  libavformat/internal.h | 6 ++
>  libavformat/utils.c| 5 +
>  2 files changed, 11 insertions(+)
> 
> 
> Apparently, the most unhappyness was caused by the error code in the public
> API. This is not the case here.
> 
> 
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index ee86094..0f684bd 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -516,4 +516,10 @@ int ff_copy_whitelists(AVFormatContext *dst, 
> AVFormatContext *src);
>  int ffio_open2_wrapper(struct AVFormatContext *s, AVIOContext **pb, const 
> char *url, int flags,
> const AVIOInterruptCB *int_cb, AVDictionary 
> **options);
>  
> +/**
> + * Returned by demuxers to indicate that data was consumed but discarded

"returned internally by demuxers" maybe

> + * (ignored streams or junk data). The framework will re-call the demuxer.
> + */
> +#define FFERROR_REDO FFERRTAG( 'R','E','D','O')

nit: space issue

> +
>  #endif /* AVFORMAT_INTERNAL_H */
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8cb7d38..83e2f73 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -680,6 +680,11 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
>  av_init_packet(pkt);
>  ret = s->iformat->read_packet(s, pkt);
>  if (ret < 0) {
> +/* Some demuxer (FLV, MPEG-PS) return FFERROR_REDO when they
> +   data and discard it (ignored streams, junk, extradata).

when they data?

[...]

otherwise this is fine with me that way

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_dynaudnorm: remove pow2

[Ganesh Ajjanagadde]

On Wed, Nov 25, 2015 at 10:36 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Nov 25, 2015 at 8:00 AM, Ganesh Ajjanagadde 
> wrote:
>>
>> pow2 is being used for trivial squaring. Its name is not good: is this
>> 2^x or x^2?
>
>
> 2^x is exp2, not pow2. (I have no opinion on the patch itself.)
>
> Ronald

@Paul: is this patch fine?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 1/3] avutil/tablegen: add tablegen compatibility hacks

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 9:43 AM, Clément Bœsch  wrote:
> On Fri, Nov 27, 2015 at 06:32:40AM -0500, Ganesh Ajjanagadde wrote:
>> On Fri, Nov 27, 2015 at 4:46 AM, Clément Bœsch  wrote:
>> > On Thu, Nov 26, 2015 at 11:58:10AM -0500, Ganesh Ajjanagadde wrote:
>> >> Reviewed-by: Ronald S. Bultje 
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  libavutil/tablegen.h | 33 +
>> >>  1 file changed, 33 insertions(+)
>> >>  create mode 100644 libavutil/tablegen.h
>> >>
>> >> diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
>> >> new file mode 100644
>> >> index 000..01c8eea
>> >> --- /dev/null
>> >> +++ b/libavutil/tablegen.h
>> >> @@ -0,0 +1,33 @@
>> >> +/*
>> >> + * This file is part of FFmpeg.
>> >> + *
>> >> + * FFmpeg is free software; you can redistribute it and/or
>> >> + * modify it under the terms of the GNU Lesser General Public
>> >> + * License as published by the Free Software Foundation; either
>> >> + * version 2.1 of the License, or (at your option) any later version.
>> >> + *
>> >> + * FFmpeg is distributed in the hope that it will be useful,
>> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> >> + * Lesser General Public License for more details.
>> >> + *
>> >> + * You should have received a copy of the GNU Lesser General Public
>> >> + * License along with FFmpeg; if not, write to the Free Software
>> >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
>> >> 02110-1301 USA
>> >> + */
>> >> +
>> >> +/**
>> >> + * @file
>> >> + * Compatibility libm for table generation files
>> >> + */
>> >> +
>> >> +#ifndef AVUTIL_TABLEGEN_H
>> >> +#define AVUTIL_TABLEGEN_H
>> >> +
>> >> +// we lack some functions on all host platforms, and we don't care about
>> >> +// performance as it's performed at build time
>> >> +#define cbrt(x)   pow(x, 1.0 / 3)
>> >
>> >> +#define llrint(x) floor((x) + 0.5)
>> >> +#define lrint(x)  floor((x) + 0.5)
>> >> +
>> >
>> > does it work for x < 0?
>>
>> Of course not exactly; I did recognize this. However, there are 2
>> reasons for this:
>> 1. The old tablegen code did exactly a floor(x + 0.5), suggesting that
>> it did not matter. Thus, this was done for simplicity, anyway these
>> are imperfect hacks. The hacks can be improved, but felt that belongs
>> in a separate patch - no matter how they are improved, they remain
>> hacks (see number 2).
>> 2. Even if one does the floor if x > 0, ceil if x < 0 trick, it has
>> issues with corner cases, I recall Michael mentioning something
>> regarding 0.4999 or something like that.
>>
>
> it's pretty fine with me to use a simple hack like this, but then i'd
> argue it's better if the global c namespace is not polluted with openly
> broken implementations: just name the macro differently (ffrint,
> simplerint, or whatever) to make sure someone doesn't end up using it in a
> different context where negative values matter (and where the issue won't
> get detected quickly)

Actually, how will this work? We need the same names as the standard
functions so that table generation works correctly. I think the
easiest thing to do since I anyway don't mind is to do a "less broken"
ceil if < 0, etc so that it is more reasonable.

And unless I am mistaken here, one does not need to use macros for
this, inline (not av_always_inline which depends on attributes.h)
functions should be fine and I prefer them.

I can repost, or push directly.

>
> --
> Clément B.
>
> ___
> 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

[FFmpeg-devel] [PATCH 5/5] lavf/mpegts: use AVERROR_INVALIDDATA instead of AVERROR(EINTR).

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavformat/mpegts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Untested. Offending commit was:

commit df8aa4598c7cc1c2f863f6fc6b2d4b3e6dc7345e
Author: Martin Storsjö 
Date:   2012-04-21 20:44:24 +0300

mpegts: Make sure we don't return uninitialized packets

This fixes crashes, where the demuxer could return 0 even
if the returned AVPacket isn't initialized at all. This
could happen if running into EOF or running out of probesize
with non-seekable sources.

Signed-off-by: Martin Storsjö 

Truncated input is usually treated as INVALIDDATA if not just EOF.
EINTR is wrong anyway.


diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index bc1e03e..c522c6d 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2670,7 +2670,7 @@ static int mpegts_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 }
 
 if (!ret && pkt->size < 0)
-ret = AVERROR(EINTR);
+ret = AVERROR_INVALIDDATA;
 return ret;
 }
 
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/5] lavf/lxfdec: use FFERROR_REDO instead of AVERROR(EAGAIN).

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavformat/lxfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Untested.


diff --git a/libavformat/lxfdec.c b/libavformat/lxfdec.c
index 7c3d065..696e112 100644
--- a/libavformat/lxfdec.c
+++ b/libavformat/lxfdec.c
@@ -305,7 +305,7 @@ static int lxf_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (stream > 1) {
 av_log(s, AV_LOG_WARNING,
"got packet with illegal stream index %"PRIu32"\n", stream);
-return AVERROR(EAGAIN);
+return FFERROR_REDO;
 }
 
 if (stream == 1 && s->nb_streams < 2) {
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/5] lavf/mpeg: use FFERROR_REDO instead of AVERROR(EAGAIN).

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavformat/mpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Problem can be observed with files containing large portions of junk, for
example:

{ ffmpeg -lavfi testsrc=d=60 -f vob -;
  head -c $[256*1024*1024] /dev/zero;
  ffmpeg -lavfi testsrc=d=60 -f vob - } > big.mpg
ffmpeg -i big.mpg -f null -

Observe the time getting stuck after 60 seconds.


diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index fb77d89..69685cf 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -256,7 +256,7 @@ redo:
 if (avio_feof(s->pb))
 return AVERROR_EOF;
 // FIXME we should remember header_state
-return AVERROR(EAGAIN);
+return FFERROR_REDO;
 }
 
 if (startcode == PACK_START_CODE)
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/5] lavf: add FFERROR_REDO to let demuxer return no packet.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavformat/internal.h | 6 ++
 libavformat/utils.c| 5 +
 2 files changed, 11 insertions(+)


Apparently, the most unhappyness was caused by the error code in the public
API. This is not the case here.


diff --git a/libavformat/internal.h b/libavformat/internal.h
index ee86094..0f684bd 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -516,4 +516,10 @@ int ff_copy_whitelists(AVFormatContext *dst, 
AVFormatContext *src);
 int ffio_open2_wrapper(struct AVFormatContext *s, AVIOContext **pb, const char 
*url, int flags,
const AVIOInterruptCB *int_cb, AVDictionary **options);
 
+/**
+ * Returned by demuxers to indicate that data was consumed but discarded
+ * (ignored streams or junk data). The framework will re-call the demuxer.
+ */
+#define FFERROR_REDO FFERRTAG( 'R','E','D','O')
+
 #endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8cb7d38..83e2f73 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -680,6 +680,11 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 av_init_packet(pkt);
 ret = s->iformat->read_packet(s, pkt);
 if (ret < 0) {
+/* Some demuxer (FLV, MPEG-PS) return FFERROR_REDO when they
+   data and discard it (ignored streams, junk, extradata).
+   We must re-call the demuxer to get the real packet. */
+if (ret == FFERROR_REDO)
+continue;
 if (!pktl || ret == AVERROR(EAGAIN))
 return ret;
 for (i = 0; i < s->nb_streams; i++) {
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/5] lavf/flvdec: use FFERROR_REDO instead of AVERROR(EAGAIN).

[Nicolas George]

Fix trac ticket #5041.

Signed-off-by: Nicolas George 
---
 libavformat/flvdec.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)


Problem can be observed by transcoding or remuxing a large FLV with both
audio and video with and without -an or -vn and observing the speed and CPU
usage.


diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index ca73969..c003e70 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -882,7 +882,7 @@ retry:
 }
 
 if (size == 0) {
-ret = AVERROR(EAGAIN);
+ret = FFERROR_REDO;
 goto leave;
 }
 
@@ -927,13 +927,13 @@ retry:
type, size, flags);
 skip:
 avio_seek(s->pb, next, SEEK_SET);
-ret = AVERROR(EAGAIN);
+ret = FFERROR_REDO;
 goto leave;
 }
 
 /* skip empty data packets */
 if (!size) {
-ret = AVERROR(EAGAIN);
+ret = FFERROR_REDO;
 goto leave;
 }
 
@@ -973,7 +973,7 @@ skip:
 || st->discard >= AVDISCARD_ALL
 ) {
 avio_seek(s->pb, next, SEEK_SET);
-ret = AVERROR(EAGAIN);
+ret = FFERROR_REDO;
 goto leave;
 }
 
@@ -1068,7 +1068,7 @@ retry_duration:
 if (st->codec->extradata) {
 if ((ret = flv_queue_extradata(flv, s->pb, stream_type, size)) 
< 0)
 return ret;
-ret = AVERROR(EAGAIN);
+ret = FFERROR_REDO;
 goto leave;
 }
 if ((ret = flv_get_extradata(s, st, size)) < 0)
@@ -1095,14 +1095,14 @@ retry_duration:
 }
 }
 
-ret = AVERROR(EAGAIN);
+ret = FFERROR_REDO;
 goto leave;
 }
 }
 
 /* skip empty data packets */
 if (!size) {
-ret = AVERROR(EAGAIN);
+ret = FFERROR_REDO;
 goto leave;
 }
 
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/libdcadec: require first public release

[James Almer]

Signed-off-by: James Almer 
---
 configure  | 4 +---
 libavcodec/libdcadec.c | 6 +++---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/configure b/configure
index 0198b75..5583358 100755
--- a/configure
+++ b/configure
@@ -1877,7 +1877,6 @@ TYPES_LIST="
 CONDITION_VARIABLE_Ptr
 socklen_t
 struct_addrinfo
-struct_dcadec_exss_info_matrix_encoding
 struct_group_source_req
 struct_ip_mreq_source
 struct_ipv6_mreq
@@ -5338,8 +5337,7 @@ enabled libcelt   && require libcelt celt/celt.h 
celt_decode -lcelt0 &&
  { check_lib celt/celt.h 
celt_decoder_create_custom -lcelt0 ||
die "ERROR: libcelt must be installed and 
version must be >= 0.11.0."; }
 enabled libcaca   && require_pkg_config caca caca.h caca_create_canvas
-enabled libdcadec && require_pkg_config dcadec libdcadec/dca_context.h 
dcadec_context_create &&
- check_struct libdcadec/dca_context.h "struct 
dcadec_exss_info" matrix_encoding
+enabled libdcadec && require_pkg_config "dcadec >= 0.1.0" 
libdcadec/dca_context.h dcadec_context_create
 enabled libfaac   && require2 libfaac "stdint.h faac.h" 
faacEncGetVersion -lfaac
 enabled libfdk_aac&& { use_pkg_config fdk-aac "fdk-aac/aacenc_lib.h" 
aacEncOpen ||
{ require libfdk_aac fdk-aac/aacenc_lib.h 
aacEncOpen -lfdk-aac &&
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index a0e34f9..e802076 100644
--- a/libavcodec/libdcadec.c
+++ b/libavcodec/libdcadec.c
@@ -42,7 +42,7 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void 
*data,
 {
 DCADecContext *s = avctx->priv_data;
 AVFrame *frame = data;
-av_unused struct dcadec_exss_info *exss;
+struct dcadec_exss_info *exss;
 int ret, i, k;
 int **samples, nsamples, channel_mask, sample_rate, bits_per_sample, 
profile;
 uint32_t mrk;
@@ -78,6 +78,8 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void 
*data,
  &sample_rate, &bits_per_sample, 
&profile)) < 0) {
 av_log(avctx, AV_LOG_ERROR, "dcadec_context_filter() failed: %d 
(%s)\n", -ret, dcadec_strerror(ret));
 return AVERROR_EXTERNAL;
+} else if (ret > 0) {
+av_log(avctx, AV_LOG_WARNING, "dcadec_context_filter() warning: %d 
(%s)\n", ret, dcadec_strerror(ret));
 }
 
 avctx->channels   = av_get_channel_layout_nb_channels(channel_mask);
@@ -129,7 +131,6 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void 
*data,
 } else
 avctx->bit_rate = 0;
 
-#if HAVE_STRUCT_DCADEC_EXSS_INFO_MATRIX_ENCODING
 if (exss = dcadec_context_get_exss_info(s->ctx)) {
 enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
 
@@ -158,7 +159,6 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void 
*data,
 (ret = ff_side_data_update_matrix_encoding(frame, 
matrix_encoding)) < 0)
 return ret;
 }
-#endif
 
 frame->nb_samples = nsamples;
 if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
-- 
2.6.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Rostislav Pehlivanov]

On Fri, 2015-11-27 at 18:50 +0100, Hendrik Leppkes wrote:
> Note that the init is wrong for float as well. You use the same
> condition for aacenc and aacdec, but they init different things.
> aacdec inits much more, and if aacenc would init first for some
> reason, it would leave aacdec without half its init.

Yes, realized that. Partially reverted the patch. Now the aac encoder
and decoder can init the table twice but this is less than an evil than
the alternative. So I think it might just be better to leave things as
they were and live with initializing it twice in case someone
transcodes aac->aac using the native encoder.


On Fri, 2015-11-27 at 18:37 +0100, wm4 wrote:
> Such changes should be put up for review anyway.

Was on the fence about whether to put it up for review but it seemed
like a small patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Hendrik Leppkes]

On Fri, Nov 27, 2015 at 6:40 PM, Rostislav Pehlivanov
 wrote:
> On Fri, 2015-11-27 at 09:08 -0800, Timothy Gu wrote:
>> On Fri, Nov 27, 2015 at 03:08:05PM +, Rostislav Pehlivanov wrote:
>> > I've just pushed a patch which makes the AAC encoder threadsafe, so
>> > now
>> > it should be safe to always generate that table at runtime.
>>
>> This commit seems to break FATE on a couple of platforms (not sure
>> about
>> Linux yet but probably). See:
>
> I'm on it. Freenode is dead for me ATM.
> It's the aac-fixed decoder again.

Note that the init is wrong for float as well. You use the same
condition for aacenc and aacdec, but they init different things.
aacdec inits much more, and if aacenc would init first for some
reason, it would leave aacdec without half its init.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Rostislav Pehlivanov]

On Fri, 2015-11-27 at 09:08 -0800, Timothy Gu wrote:
> On Fri, Nov 27, 2015 at 03:08:05PM +, Rostislav Pehlivanov wrote:
> > I've just pushed a patch which makes the AAC encoder threadsafe, so
> > now
> > it should be safe to always generate that table at runtime.
> 
> This commit seems to break FATE on a couple of platforms (not sure
> about
> Linux yet but probably). See:

I'm on it. Freenode is dead for me ATM.
It's the aac-fixed decoder again.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[wm4]

On Fri, 27 Nov 2015 09:08:38 -0800
Timothy Gu  wrote:

> On Fri, Nov 27, 2015 at 03:08:05PM +, Rostislav Pehlivanov wrote:
> > I've just pushed a patch which makes the AAC encoder threadsafe, so now
> > it should be safe to always generate that table at runtime.  
> 
> This commit seems to break FATE on a couple of platforms (not sure about
> Linux yet but probably). See:
> 
> http://fatebeta.ffmpeg.org/report/x86_64-freebsd8.2-gcc4.2.5/20151127162159#failed_tests
> http://fatebeta.ffmpeg.org/report/x86_64-msvc14-windows-native/20151127164917#failed_tests
> http://fatebeta.ffmpeg.org/report/x86-haiku-gcc-4.8/20151127170710#failed_tests

Such changes should be put up for review anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

[Ronald S. Bultje]

Hi,

On Thu, Nov 26, 2015 at 6:19 PM, Nicolas George  wrote:

> Le sextidi 6 frimaire, an CCXXIV, Marton Balint a écrit :
> > Maybe I am missing something, but the existing error AVERROR(EINTR)
> cannot
> > be used for this?
>
> It would be less broken than EAGAIN, since it is almost always treated like
> that by Unix code.
>
> But without the loop in utils.c (patch 2/3 in this series), the result is
> as
> bad or worse than EAGAIN, since the application sees it as an error code.
> And this is this loop that wm4 and Ronald are bikeshedding.


I give one comment, and I'm bikeshedding? Dude ...

We probably want the same thing, just with slightly different angles.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 12:08 PM, Timothy Gu  wrote:
> On Fri, Nov 27, 2015 at 03:08:05PM +, Rostislav Pehlivanov wrote:
>> I've just pushed a patch which makes the AAC encoder threadsafe, so now
>> it should be safe to always generate that table at runtime.
>
> This commit seems to break FATE on a couple of platforms (not sure about
> Linux yet but probably). See:
>
> http://fatebeta.ffmpeg.org/report/x86_64-freebsd8.2-gcc4.2.5/20151127162159#failed_tests
> http://fatebeta.ffmpeg.org/report/x86_64-msvc14-windows-native/20151127164917#failed_tests
> http://fatebeta.ffmpeg.org/report/x86-haiku-gcc-4.8/20151127170710#failed_tests

I like the UI of fatebeta, good work!

>
> Timothy
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Timothy Gu]

On Fri, Nov 27, 2015 at 03:08:05PM +, Rostislav Pehlivanov wrote:
> I've just pushed a patch which makes the AAC encoder threadsafe, so now
> it should be safe to always generate that table at runtime.

This commit seems to break FATE on a couple of platforms (not sure about
Linux yet but probably). See:

http://fatebeta.ffmpeg.org/report/x86_64-freebsd8.2-gcc4.2.5/20151127162159#failed_tests
http://fatebeta.ffmpeg.org/report/x86_64-msvc14-windows-native/20151127164917#failed_tests
http://fatebeta.ffmpeg.org/report/x86-haiku-gcc-4.8/20151127170710#failed_tests

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/aac_tablegen: speed up table initialization

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 9:37 AM, Clément Bœsch  wrote:
> On Fri, Nov 27, 2015 at 12:40:27PM +0100, Ganesh Ajjanagadde wrote:
> [...]
>> diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
>> index 8b223f9..85e189d 100644
>> --- a/libavcodec/aac_tablegen.h
>> +++ b/libavcodec/aac_tablegen.h
>> @@ -35,9 +35,46 @@ float ff_aac_pow34sf_tab[428];
>>  av_cold void ff_aac_tableinit(void)
>>  {
>>  int i;
>> +
>> +/* 2^(i/16) for 0 <= i <= 15 */
>> +const float exp2_lut[] = {
>
> sorry to notice only now; maybe add a static?

No problem, since it does not really matter much. Will push later today.

>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Rostislav Pehlivanov]

On Fri, 2015-11-27 at 09:16 -0500, Ganesh Ajjanagadde wrote:
> Ok, good. Let us proceed with this one step at a time. Here, I guess
> it really does not matter since the net size is ~ 3 kB. Nevertheless,
> it seems unnecessary now to do it at compile time, so unless AAC
> maintainers object, I will submit a patch to always do this at
> runtime.

I wouldn't mind at all, go ahead by all means. I've always thought that
for smaller tables hardcoding was kinda pointless and I see that most
other people agree as well.

I've just pushed a patch which makes the AAC encoder threadsafe, so now
it should be safe to always generate that table at runtime.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 1/3] avutil/tablegen: add tablegen compatibility hacks

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 9:43 AM, Clément Bœsch  wrote:
> On Fri, Nov 27, 2015 at 06:32:40AM -0500, Ganesh Ajjanagadde wrote:
>> On Fri, Nov 27, 2015 at 4:46 AM, Clément Bœsch  wrote:
>> > On Thu, Nov 26, 2015 at 11:58:10AM -0500, Ganesh Ajjanagadde wrote:
>> >> Reviewed-by: Ronald S. Bultje 
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  libavutil/tablegen.h | 33 +
>> >>  1 file changed, 33 insertions(+)
>> >>  create mode 100644 libavutil/tablegen.h
>> >>
>> >> diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
>> >> new file mode 100644
>> >> index 000..01c8eea
>> >> --- /dev/null
>> >> +++ b/libavutil/tablegen.h
>> >> @@ -0,0 +1,33 @@
>> >> +/*
>> >> + * This file is part of FFmpeg.
>> >> + *
>> >> + * FFmpeg is free software; you can redistribute it and/or
>> >> + * modify it under the terms of the GNU Lesser General Public
>> >> + * License as published by the Free Software Foundation; either
>> >> + * version 2.1 of the License, or (at your option) any later version.
>> >> + *
>> >> + * FFmpeg is distributed in the hope that it will be useful,
>> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> >> + * Lesser General Public License for more details.
>> >> + *
>> >> + * You should have received a copy of the GNU Lesser General Public
>> >> + * License along with FFmpeg; if not, write to the Free Software
>> >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
>> >> 02110-1301 USA
>> >> + */
>> >> +
>> >> +/**
>> >> + * @file
>> >> + * Compatibility libm for table generation files
>> >> + */
>> >> +
>> >> +#ifndef AVUTIL_TABLEGEN_H
>> >> +#define AVUTIL_TABLEGEN_H
>> >> +
>> >> +// we lack some functions on all host platforms, and we don't care about
>> >> +// performance as it's performed at build time
>> >> +#define cbrt(x)   pow(x, 1.0 / 3)
>> >
>> >> +#define llrint(x) floor((x) + 0.5)
>> >> +#define lrint(x)  floor((x) + 0.5)
>> >> +
>> >
>> > does it work for x < 0?
>>
>> Of course not exactly; I did recognize this. However, there are 2
>> reasons for this:
>> 1. The old tablegen code did exactly a floor(x + 0.5), suggesting that
>> it did not matter. Thus, this was done for simplicity, anyway these
>> are imperfect hacks. The hacks can be improved, but felt that belongs
>> in a separate patch - no matter how they are improved, they remain
>> hacks (see number 2).
>> 2. Even if one does the floor if x > 0, ceil if x < 0 trick, it has
>> issues with corner cases, I recall Michael mentioning something
>> regarding 0.4999 or something like that.
>>
>
> it's pretty fine with me to use a simple hack like this, but then i'd
> argue it's better if the global c namespace is not polluted with openly
> broken implementations: just name the macro differently (ffrint,
> simplerint, or whatever) to make sure someone doesn't end up using it in a
> different context where negative values matter (and where the issue won't
> get detected quickly)

ok, will change.

>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 1/3] avutil/tablegen: add tablegen compatibility hacks

[Clément Bœsch]

On Fri, Nov 27, 2015 at 06:32:40AM -0500, Ganesh Ajjanagadde wrote:
> On Fri, Nov 27, 2015 at 4:46 AM, Clément Bœsch  wrote:
> > On Thu, Nov 26, 2015 at 11:58:10AM -0500, Ganesh Ajjanagadde wrote:
> >> Reviewed-by: Ronald S. Bultje 
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  libavutil/tablegen.h | 33 +
> >>  1 file changed, 33 insertions(+)
> >>  create mode 100644 libavutil/tablegen.h
> >>
> >> diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
> >> new file mode 100644
> >> index 000..01c8eea
> >> --- /dev/null
> >> +++ b/libavutil/tablegen.h
> >> @@ -0,0 +1,33 @@
> >> +/*
> >> + * This file is part of FFmpeg.
> >> + *
> >> + * FFmpeg is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU Lesser General Public
> >> + * License as published by the Free Software Foundation; either
> >> + * version 2.1 of the License, or (at your option) any later version.
> >> + *
> >> + * FFmpeg is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> >> + * Lesser General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU Lesser General Public
> >> + * License along with FFmpeg; if not, write to the Free Software
> >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> >> 02110-1301 USA
> >> + */
> >> +
> >> +/**
> >> + * @file
> >> + * Compatibility libm for table generation files
> >> + */
> >> +
> >> +#ifndef AVUTIL_TABLEGEN_H
> >> +#define AVUTIL_TABLEGEN_H
> >> +
> >> +// we lack some functions on all host platforms, and we don't care about
> >> +// performance as it's performed at build time
> >> +#define cbrt(x)   pow(x, 1.0 / 3)
> >
> >> +#define llrint(x) floor((x) + 0.5)
> >> +#define lrint(x)  floor((x) + 0.5)
> >> +
> >
> > does it work for x < 0?
> 
> Of course not exactly; I did recognize this. However, there are 2
> reasons for this:
> 1. The old tablegen code did exactly a floor(x + 0.5), suggesting that
> it did not matter. Thus, this was done for simplicity, anyway these
> are imperfect hacks. The hacks can be improved, but felt that belongs
> in a separate patch - no matter how they are improved, they remain
> hacks (see number 2).
> 2. Even if one does the floor if x > 0, ceil if x < 0 trick, it has
> issues with corner cases, I recall Michael mentioning something
> regarding 0.4999 or something like that.
> 

it's pretty fine with me to use a simple hack like this, but then i'd
argue it's better if the global c namespace is not polluted with openly
broken implementations: just name the macro differently (ffrint,
simplerint, or whatever) to make sure someone doesn't end up using it in a
different context where negative values matter (and where the issue won't
get detected quickly)

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/aac_tablegen: speed up table initialization

[Clément Bœsch]

On Fri, Nov 27, 2015 at 12:40:27PM +0100, Ganesh Ajjanagadde wrote:
[...]
> diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
> index 8b223f9..85e189d 100644
> --- a/libavcodec/aac_tablegen.h
> +++ b/libavcodec/aac_tablegen.h
> @@ -35,9 +35,46 @@ float ff_aac_pow34sf_tab[428];
>  av_cold void ff_aac_tableinit(void)
>  {
>  int i;
> +
> +/* 2^(i/16) for 0 <= i <= 15 */
> +const float exp2_lut[] = {

sorry to notice only now; maybe add a static?

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

[Derek Buitenhuis]

On 11/27/2015 7:07 AM, Nicolas George wrote:
> So basically, the question boils down to what people consider the better
> design: adding a loop in every demuxer that needs it, or have the loop in
> the framework.

I'm erring on the latter approach, for one reason: This changes beavior, but
does not break API or ABI, which I think is quite evil.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: handle AVERROR_REDO.

[Clément Bœsch]

On Fri, Nov 27, 2015 at 01:10:29PM +0100, Nicolas George wrote:
> Le septidi 7 frimaire, an CCXXIV, Clement Boesch a écrit :
> > But then it's still exposed by the API, and someone looking at handling
> > every error code might be wondering how to handle it.
> 
> « Handling every error code » seems to me like an impossible and idiotic
> objective. What do you suggest, exactly?
> 

I don't know; I just don't really like the idea of such error code
"leaking" publicly in order to solve an issue internally. I don't have any
solution, I would just loop in the demuxer or use a FFERROR (but that
might be clumsy)

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 8:10 AM, wm4  wrote:
> On Fri, 27 Nov 2015 13:51:57 +0100
> Hendrik Leppkes  wrote:
>
>> On Fri, Nov 27, 2015 at 1:48 PM, Ganesh Ajjanagadde  wrote:
>> > On Fri, Nov 27, 2015 at 7:05 AM, wm4  wrote:
>> >> On Fri, 27 Nov 2015 06:42:21 -0500
>> >> Ganesh Ajjanagadde  wrote:
>> >>
>> >>> On Fri, Nov 27, 2015 at 5:35 AM, Rostislav Pehlivanov
>> >>>  wrote:
>> >>> > LGTM, but could you leave (just comment it out) the old code in there
>> >>> > so it's a little easier to follow?
>> >>> >> //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
>> >>> >> //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);
>> >>> >
>> >>> > The accuracy increase is always nice.
>> >>>
>> >>> Done and pushed. Thanks.
>> >>> BTW, do you or others think that the new performance figures are
>> >>> sufficient to justify getting rid of config_hardcoded_tables and
>> >>> associated ifdefry and C file here?
>> >>
>> >> I think this would be a very good goal. I never understood why there
>> >> has to be both, and the complication caused by it is terrible.
>> >
>> > I definitely agree that the complication is terrible, experiencing it
>> > first hand with some patches currently under review. I was initially
>> > skeptical of the need for both myself, but am now neutral about it,
>> > see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183932.html
>> > for some links about the rationale for this thing and my own thoughts
>> > on it - I am sure a computer systems person can explain it far better.
>> > However, for this to be valid, at least some basic tests need to be
>> > done, e.g what is the library size before and after
>> > --enable-hardcoded-tables?
>> >
>> > The trouble is that at the moment packagers and other clients (vlc,
>> > mpv, chromium?) have generally followed the defaults, so if we move to
>> > "hardcoded by default", clients can and perhaps should accuse us of
>> > library bloat. I hence personally prefer doing it all at runtime, but
>> > it will likely lead to bikeshedding. Maybe we can actually use our new
>> > "developer committee" for a poll on this. A simple library size test
>> > should be revealing in this respect.
>> >
>> >>
>> >> I'm not sure if dynamic generation was already the default, but in any
>> >> case the init call should be protected with ff_thread_once.
>> >
>> > Dynamic is in the sense that --enable-hardcoded-tables is not done by
>> > default. I got the numbers by running ffplay on some test file.
>
> Well, I meant switching each case that can be configured to either
> hardcoded or dynamic generation only, depending on its effect on file
> size.

Ok, good. Let us proceed with this one step at a time. Here, I guess
it really does not matter since the net size is ~ 3 kB. Nevertheless,
it seems unnecessary now to do it at compile time, so unless AAC
maintainers object, I will submit a patch to always do this at
runtime.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

[Nicolas George]

Le septidi 7 frimaire, an CCXXIV, wm4 a écrit :
> I still do not see how a potential flag to make the API user to be able
> to use this is better than running the demuxer in a thread. I'm talking
> about practice, not theory. Such a flag would work _sometimes_, with
> _some_ demuxers in _some_ very specific situations, and which will only
> be low latency if the AVIO behind it is also low-latency.

Try this on slow hardware:

ffmpeg -lavfi testsrc=s=hd1080 -c:v libx264 -preset veryslow -f null -

and when the encoding has really started (time > 0), press q.

You can observe that (1) at frame ~66, it stops (on the hardware I tried,
for 23 seconds), and when you press q, it stops again (35 seconds for me).
No indication that it is progressing, except high CPU load. This is not good
user experience.

With a best-effort low-latency mode, the codec would return every ~0.5-2
seconds, that would allow the application to print progress, or at least
show that it is not in an endless loop.

That is not perfect, but it is still way better than nothing.

As for running in a thread, I already gave the reasons: poor portability,
trickiness, cost.

> On the contrary, I see this (proposed, not even realized) feature,
> which will be half-broken at the moment of its inception, become yet

Best-effort, not half-broken.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

[wm4]

On Fri, 27 Nov 2015 13:53:33 +0100
Nicolas George  wrote:

> Le septidi 7 frimaire, an CCXXIV, wm4 a écrit :
> > I might not be familiar with flvdec in particular. Can you explain me
> > how Matroska could be switched to non-blocking?  
> 
> It can not, and this has NOTHING to do with the current discussion.
> Non-blocking mode requires the demuxer to be able to stop at ANY position in
> the octet stream, it is very hard to achieve.
> 
> What was evoked here was a low-latency mode, where the demuxer returns as
> soon as CONVENIENTLY possible.

Oh, ok.

I still do not see how a potential flag to make the API user to be able
to use this is better than running the demuxer in a thread. I'm talking
about practice, not theory. Such a flag would work _sometimes_, with
_some_ demuxers in _some_ very specific situations, and which will only
be low latency if the AVIO behind it is also low-latency.

On the contrary, I see this (proposed, not even realized) feature,
which will be half-broken at the moment of its inception, become yet
another feature that nobody uses and that bitrots as time goes.

Note that I'm not stopping you. I only questioned that the fix to the
flvdec issue was not minimal.

> I am not familiar enough with the Matroska demuxer, which seems rather
> convoluted, to tell how it could be changed.
> 
> > I'm trying to prevent that people add more complex special cases
> > libavformat/utils.c. One special case is not a tragedy, but millions of
> > special-cases interacting are an unmaintainable mess.  
> 
> I am not trying to add millions of special-cases, just one. Since you
> pretend you are not making a "slippery slope" fallacy, explain what these
> millions are about.

utils.c is full of special conditions that barely anyone knows what
they are about. This is not just my opinion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Hendrik Leppkes]

On Fri, Nov 27, 2015 at 2:10 PM, wm4  wrote:
> On Fri, 27 Nov 2015 13:51:57 +0100
> Hendrik Leppkes  wrote:
>
>> On Fri, Nov 27, 2015 at 1:48 PM, Ganesh Ajjanagadde  wrote:
>> > On Fri, Nov 27, 2015 at 7:05 AM, wm4  wrote:
>> >> On Fri, 27 Nov 2015 06:42:21 -0500
>> >> Ganesh Ajjanagadde  wrote:
>> >>
>> >>> On Fri, Nov 27, 2015 at 5:35 AM, Rostislav Pehlivanov
>> >>>  wrote:
>> >>> > LGTM, but could you leave (just comment it out) the old code in there
>> >>> > so it's a little easier to follow?
>> >>> >> //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
>> >>> >> //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);
>> >>> >
>> >>> > The accuracy increase is always nice.
>> >>>
>> >>> Done and pushed. Thanks.
>> >>> BTW, do you or others think that the new performance figures are
>> >>> sufficient to justify getting rid of config_hardcoded_tables and
>> >>> associated ifdefry and C file here?
>> >>
>> >> I think this would be a very good goal. I never understood why there
>> >> has to be both, and the complication caused by it is terrible.
>> >
>> > I definitely agree that the complication is terrible, experiencing it
>> > first hand with some patches currently under review. I was initially
>> > skeptical of the need for both myself, but am now neutral about it,
>> > see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183932.html
>> > for some links about the rationale for this thing and my own thoughts
>> > on it - I am sure a computer systems person can explain it far better.
>> > However, for this to be valid, at least some basic tests need to be
>> > done, e.g what is the library size before and after
>> > --enable-hardcoded-tables?
>> >
>> > The trouble is that at the moment packagers and other clients (vlc,
>> > mpv, chromium?) have generally followed the defaults, so if we move to
>> > "hardcoded by default", clients can and perhaps should accuse us of
>> > library bloat. I hence personally prefer doing it all at runtime, but
>> > it will likely lead to bikeshedding. Maybe we can actually use our new
>> > "developer committee" for a poll on this. A simple library size test
>> > should be revealing in this respect.
>> >
>> >>
>> >> I'm not sure if dynamic generation was already the default, but in any
>> >> case the init call should be protected with ff_thread_once.
>> >
>> > Dynamic is in the sense that --enable-hardcoded-tables is not done by
>> > default. I got the numbers by running ffplay on some test file.
>
> Well, I meant switching each case that can be configured to either
> hardcoded or dynamic generation only, depending on its effect on file
> size.
>
>> >
>> > As for the ff_thread_once, did not know that. I am not comfortable
>> > with threading, but if you send a patch for this, I can understand it
>> > better for future.
>> >
>>
>> aac init should already be thread safe, Derek sent patches to that effect.
>
> aacenc.c calls it unconditionally.

Then it needs to add the wrapper, aacdec does that anyway. This needs
to be done per-codec, not per-init-function.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[wm4]

On Fri, 27 Nov 2015 13:51:57 +0100
Hendrik Leppkes  wrote:

> On Fri, Nov 27, 2015 at 1:48 PM, Ganesh Ajjanagadde  wrote:
> > On Fri, Nov 27, 2015 at 7:05 AM, wm4  wrote:  
> >> On Fri, 27 Nov 2015 06:42:21 -0500
> >> Ganesh Ajjanagadde  wrote:
> >>  
> >>> On Fri, Nov 27, 2015 at 5:35 AM, Rostislav Pehlivanov
> >>>  wrote:  
> >>> > LGTM, but could you leave (just comment it out) the old code in there
> >>> > so it's a little easier to follow?  
> >>> >> //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
> >>> >> //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);  
> >>> >
> >>> > The accuracy increase is always nice.  
> >>>
> >>> Done and pushed. Thanks.
> >>> BTW, do you or others think that the new performance figures are
> >>> sufficient to justify getting rid of config_hardcoded_tables and
> >>> associated ifdefry and C file here?  
> >>
> >> I think this would be a very good goal. I never understood why there
> >> has to be both, and the complication caused by it is terrible.  
> >
> > I definitely agree that the complication is terrible, experiencing it
> > first hand with some patches currently under review. I was initially
> > skeptical of the need for both myself, but am now neutral about it,
> > see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183932.html
> > for some links about the rationale for this thing and my own thoughts
> > on it - I am sure a computer systems person can explain it far better.
> > However, for this to be valid, at least some basic tests need to be
> > done, e.g what is the library size before and after
> > --enable-hardcoded-tables?
> >
> > The trouble is that at the moment packagers and other clients (vlc,
> > mpv, chromium?) have generally followed the defaults, so if we move to
> > "hardcoded by default", clients can and perhaps should accuse us of
> > library bloat. I hence personally prefer doing it all at runtime, but
> > it will likely lead to bikeshedding. Maybe we can actually use our new
> > "developer committee" for a poll on this. A simple library size test
> > should be revealing in this respect.
> >  
> >>
> >> I'm not sure if dynamic generation was already the default, but in any
> >> case the init call should be protected with ff_thread_once.  
> >
> > Dynamic is in the sense that --enable-hardcoded-tables is not done by
> > default. I got the numbers by running ffplay on some test file.

Well, I meant switching each case that can be configured to either
hardcoded or dynamic generation only, depending on its effect on file
size.

> >
> > As for the ff_thread_once, did not know that. I am not comfortable
> > with threading, but if you send a patch for this, I can understand it
> > better for future.
> >  
> 
> aac init should already be thread safe, Derek sent patches to that effect.

aacenc.c calls it unconditionally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Nicolas George]

Le septidi 7 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> However, for this to be valid, at least some basic tests need to be
> done, e.g what is the library size before and after
> --enable-hardcoded-tables?

That is not terribly difficult to do:

-rwxr-xr-x 1 cigaes cigaes 15732448 Nov 27 14:01 ffmpeg* -> without
-rwxr-xr-x 1 cigaes cigaes 17488608 Nov 27 14:01 ffmpeg* -> with

(default options, no GPLed codecs)

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] QSV

[Ivan Uskov]

Hello All,

Friday, November 27, 2015, 11:34:52 AM, you wrote:

IU> Hello Michael,

IU> Thursday, November 26, 2015, 11:13:45 PM, you wrote:

MN>> Hi

MN>> are there any QSV patches which have been reviewed and have no
MN>> objections raised against them ?
MN>> that is patches i should apply/push for qsv ...
IU> Excluding two patches by Will Kelleher which were re-checked today only one
IU> small patch still not reviewed.
IU> It is the
IU> [PATCH] "libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame."
IU> at the September 9, please look. I can resend it if necessary.
*September 16*, sorry.



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

[Nicolas George]

Le septidi 7 frimaire, an CCXXIV, wm4 a écrit :
> I might not be familiar with flvdec in particular. Can you explain me
> how Matroska could be switched to non-blocking?

It can not, and this has NOTHING to do with the current discussion.
Non-blocking mode requires the demuxer to be able to stop at ANY position in
the octet stream, it is very hard to achieve.

What was evoked here was a low-latency mode, where the demuxer returns as
soon as CONVENIENTLY possible.

I am not familiar enough with the Matroska demuxer, which seems rather
convoluted, to tell how it could be changed.

> I'm trying to prevent that people add more complex special cases
> libavformat/utils.c. One special case is not a tragedy, but millions of
> special-cases interacting are an unmaintainable mess.

I am not trying to add millions of special-cases, just one. Since you
pretend you are not making a "slippery slope" fallacy, explain what these
millions are about.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Hendrik Leppkes]

On Fri, Nov 27, 2015 at 1:48 PM, Ganesh Ajjanagadde  wrote:
> On Fri, Nov 27, 2015 at 7:05 AM, wm4  wrote:
>> On Fri, 27 Nov 2015 06:42:21 -0500
>> Ganesh Ajjanagadde  wrote:
>>
>>> On Fri, Nov 27, 2015 at 5:35 AM, Rostislav Pehlivanov
>>>  wrote:
>>> > LGTM, but could you leave (just comment it out) the old code in there
>>> > so it's a little easier to follow?
>>> >> //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
>>> >> //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);
>>> >
>>> > The accuracy increase is always nice.
>>>
>>> Done and pushed. Thanks.
>>> BTW, do you or others think that the new performance figures are
>>> sufficient to justify getting rid of config_hardcoded_tables and
>>> associated ifdefry and C file here?
>>
>> I think this would be a very good goal. I never understood why there
>> has to be both, and the complication caused by it is terrible.
>
> I definitely agree that the complication is terrible, experiencing it
> first hand with some patches currently under review. I was initially
> skeptical of the need for both myself, but am now neutral about it,
> see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183932.html
> for some links about the rationale for this thing and my own thoughts
> on it - I am sure a computer systems person can explain it far better.
> However, for this to be valid, at least some basic tests need to be
> done, e.g what is the library size before and after
> --enable-hardcoded-tables?
>
> The trouble is that at the moment packagers and other clients (vlc,
> mpv, chromium?) have generally followed the defaults, so if we move to
> "hardcoded by default", clients can and perhaps should accuse us of
> library bloat. I hence personally prefer doing it all at runtime, but
> it will likely lead to bikeshedding. Maybe we can actually use our new
> "developer committee" for a poll on this. A simple library size test
> should be revealing in this respect.
>
>>
>> I'm not sure if dynamic generation was already the default, but in any
>> case the init call should be protected with ff_thread_once.
>
> Dynamic is in the sense that --enable-hardcoded-tables is not done by
> default. I got the numbers by running ffplay on some test file.
>
> As for the ff_thread_once, did not know that. I am not comfortable
> with threading, but if you send a patch for this, I can understand it
> better for future.
>

aac init should already be thread safe, Derek sent patches to that effect.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 7:05 AM, wm4  wrote:
> On Fri, 27 Nov 2015 06:42:21 -0500
> Ganesh Ajjanagadde  wrote:
>
>> On Fri, Nov 27, 2015 at 5:35 AM, Rostislav Pehlivanov
>>  wrote:
>> > LGTM, but could you leave (just comment it out) the old code in there
>> > so it's a little easier to follow?
>> >> //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
>> >> //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);
>> >
>> > The accuracy increase is always nice.
>>
>> Done and pushed. Thanks.
>> BTW, do you or others think that the new performance figures are
>> sufficient to justify getting rid of config_hardcoded_tables and
>> associated ifdefry and C file here?
>
> I think this would be a very good goal. I never understood why there
> has to be both, and the complication caused by it is terrible.

I definitely agree that the complication is terrible, experiencing it
first hand with some patches currently under review. I was initially
skeptical of the need for both myself, but am now neutral about it,
see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183932.html
for some links about the rationale for this thing and my own thoughts
on it - I am sure a computer systems person can explain it far better.
However, for this to be valid, at least some basic tests need to be
done, e.g what is the library size before and after
--enable-hardcoded-tables?

The trouble is that at the moment packagers and other clients (vlc,
mpv, chromium?) have generally followed the defaults, so if we move to
"hardcoded by default", clients can and perhaps should accuse us of
library bloat. I hence personally prefer doing it all at runtime, but
it will likely lead to bikeshedding. Maybe we can actually use our new
"developer committee" for a poll on this. A simple library size test
should be revealing in this respect.

>
> I'm not sure if dynamic generation was already the default, but in any
> case the init call should be protected with ff_thread_once.

Dynamic is in the sense that --enable-hardcoded-tables is not done by
default. I got the numbers by running ffplay on some test file.

As for the ff_thread_once, did not know that. I am not comfortable
with threading, but if you send a patch for this, I can understand it
better for future.

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

[wm4]

On Fri, 27 Nov 2015 13:32:30 +0100
Nicolas George  wrote:

> Le septidi 7 frimaire, an CCXXIV, wm4 a écrit :
> > Not really.  
> 
> EARGUMENTNOTFOUND.

Neither have I. In your posts.

Can you just try explaining what you want to achieve, instead of
writing lots of text with no content? I have no time for this.

I might not be familiar with flvdec in particular. Can you explain me
how Matroska could be switched to non-blocking?

> But please refrain from hindering efforts for people who do not want to use
> threads.

> PLEASE REFRAIN FROM HINDERING OUR WORK.

I'm trying to prevent that people add more complex special cases
libavformat/utils.c. One special case is not a tragedy, but millions of
special-cases interacting are an unmaintainable mess.

Also it's not like your 3 tiny patches are a lot of effort.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

[Nicolas George]

Le septidi 7 frimaire, an CCXXIV, wm4 a écrit :
> Not really.

EARGUMENTNOTFOUND.

> Well, unlike with peace in middle-east, everyone already figured out
> that threads are a good solution to I/O.

Argumentum ad numerum fallacy.

Experienced people figured out that threads are a BAD solution to I/O. I
explained why.

> Especially for an API that is blocking anyway.

We have a non-blocking API. It works only for a few demuxers, but we have
it. I will oppose any change that would make threads mandatory.

Basic sanity check: I hope you realize that a library can provide several
kinds of API. Or, in terms of logic:

A mandatory, B forbidden
A forbidden, B mandatory

-> there is also:
A authorized but not mandatory, B authorized but not mandatory

You like threads. Do threads. Nothing I propose prevents you from doing
threads.

But please refrain from hindering efforts for people who do not want to use
threads.

> Sorry, but this doesn't have to do with anything, especially not with
> my life. What's it with personal attacks on my life anyway?

This was not a personal attack, "make your life easier" is just an idiomatic
turn of speech. Did you not know it?

> also the libavformat API is already this way.

Untrue. It allows it, but it does not make it mandatory, at least
theoretically.


> What you suggest is adding a special-case for a single demuxer (and
> maybe 1 or 2 others? you didn't make it clear). And this special-case
> looks pretty unwarranted. All other demuxers follow the rule to read
> data until a packet is found, and then return that packet.

And many other demuxers could then be simplified using that infrastructure.

> I really don't understand your thinking here anyway. Didn't you say
> yourself that polling is bad?

This is not polling.

> I'd also like to hear from you how an application is supposed not to
> block its GUI without running the demuxer in a separate thread? (Please
> answer with a solution that does _not_ require rewriting every single
> demuxer and AVIO protocol.)

This is indeed not currently possible, but having a working non-blocking API
is a goal for many of us.

If you do not share that goal, fine, but once again:

PLEASE REFRAIN FROM HINDERING OUR WORK.

> Also, I'm not blocking your patch. I'm just suggesting that flvdec.c
> should handle this internally.

And I am saying that it is better design to share common code.

You may notice that it is already done when discarding is done by the
framework rather than the demuxer.

> This is not about "slippery slopes", it's about consistency. I.e.
> avoiding unnecessary special-cases, which is always good for an API.

My proposal does not add a special case in the API.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: handle AVERROR_REDO.

[Nicolas George]

Le septidi 7 frimaire, an CCXXIV, Clement Boesch a écrit :
> But then it's still exposed by the API, and someone looking at handling
> every error code might be wondering how to handle it.

« Handling every error code » seems to me like an impossible and idiotic
objective. What do you suggest, exactly?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[wm4]

On Fri, 27 Nov 2015 06:42:21 -0500
Ganesh Ajjanagadde  wrote:

> On Fri, Nov 27, 2015 at 5:35 AM, Rostislav Pehlivanov
>  wrote:
> > LGTM, but could you leave (just comment it out) the old code in there
> > so it's a little easier to follow?  
> >> //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
> >> //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);  
> >
> > The accuracy increase is always nice.  
> 
> Done and pushed. Thanks.
> BTW, do you or others think that the new performance figures are
> sufficient to justify getting rid of config_hardcoded_tables and
> associated ifdefry and C file here?

I think this would be a very good goal. I never understood why there
has to be both, and the complication caused by it is terrible.

I'm not sure if dynamic generation was already the default, but in any
case the init call should be protected with ff_thread_once.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 5:35 AM, Rostislav Pehlivanov
 wrote:
> LGTM, but could you leave (just comment it out) the old code in there
> so it's a little easier to follow?
>> //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
>> //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);
>
> The accuracy increase is always nice.

Done and pushed. Thanks.
BTW, do you or others think that the new performance figures are
sufficient to justify getting rid of config_hardcoded_tables and
associated ifdefry and C file here?

>
> On Thu, 2015-11-26 at 16:31 -0500, Ganesh Ajjanagadde wrote:
>> This speeds up aac_tablegen to a ludicruous degree (~97%), i.e to the
>> point
>> where it can be argued that runtime initialization can always be done
>> instead of
>> hard-coded tables. The only cost is essentially a trivial increase in
>> the stack size.
>>
>> Even if one does not care about this, the patch also improves
>> accuracy
>> as detailed below.
>>
>> Performance:
>> Benchmark obtained by looping 10^4 times over ff_aac_tableinit.
>>
>> Sample benchmark (x86-64, Haswell, GNU/Linux):
>> old:
>> 1295292 decicycles in ff_aac_tableinit, 512 runs,  0 skips
>> 1275981 decicycles in ff_aac_tableinit,1024 runs,  0 skips
>> 1272932 decicycles in ff_aac_tableinit,2048 runs,  0 skips
>> 1262164 decicycles in ff_aac_tableinit,4096 runs,  0 skips
>> 1256720 decicycles in ff_aac_tableinit,8192 runs,  0 skips
>>
>> new:
>> 25691 decicycles in ff_aac_tableinit, 505 runs,  7 skips
>> 25130 decicycles in ff_aac_tableinit,1016 runs,  8 skips
>> 25973 decicycles in ff_aac_tableinit,2036 runs, 12 skips
>> 25911 decicycles in ff_aac_tableinit,4078 runs, 18 skips
>> 25816 decicycles in ff_aac_tableinit,8154 runs, 38 skips
>>
>> Accuracy:
>> The previous code was resulting in needless loss of
>> accuracy due to the pow being called in succession. As an
>> illustration
>> of this:
>> ff_aac_pow34sf_tab[3]
>> old : 0.0007598092294225
>> new : 0.0007598091426864
>> real: 0.0007598091778545
>>
>> truncated to float
>> old : 0.0007598092294225
>> new : 0.0007598091426864
>> real: 0.0007598091426864
>>
>> showing that the old value was not correctly rounded. This affects a
>> large number of elements of the array.
>>
>> Patch tested with FATE.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/aac_tablegen.h | 38 -
>> -
>>  1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
>> index 8b223f9..255723b 100644
>> --- a/libavcodec/aac_tablegen.h
>> +++ b/libavcodec/aac_tablegen.h
>> @@ -35,9 +35,43 @@ float ff_aac_pow34sf_tab[428];
>>  av_cold void ff_aac_tableinit(void)
>>  {
>>  int i;
>> +
>> +/* 2^(i/16) for 0 <= i <= 15 */
>> +const double exp2_lut[] = {
>> +1.,
>> +1.04427378242741384032,
>> +1.09050773266525765921,
>> +1.13878863475669165370,
>> +1.18920711500272106672,
>> +1.24185781207348404859,
>> +1.29683955465100966593,
>> +1.35425554693689272830,
>> +1.41421356237309504880,
>> +1.47682614593949931139,
>> +1.54221082540794082361,
>> +1.61049033194925430818,
>> +1.68179283050742908606,
>> +1.75625216037329948311,
>> +1.83400808640934246349,
>> +1.91520656139714729387,
>> +};
>> +double t1 = 8.8817841970012523233890533447265625e-16; // 2^(-50)
>> +double t2 = 3.63797880709171295166015625e-12; // 2^(-38)
>> +int t1_inc_cur, t2_inc_cur;
>> +int t1_inc_prev = 0;
>> +int t2_inc_prev = 8;
>> +
>>  for (i = 0; i < 428; i++) {
>> -ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
>> -ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);
>> +t1_inc_cur = 4 * (i % 4);
>> +t2_inc_cur = (8 + 3*i) % 16;
>> +if (t1_inc_cur < t1_inc_prev)
>> +t1 *= 2;
>> +if (t2_inc_cur < t2_inc_prev)
>> +t2 *= 2;
>> +ff_aac_pow2sf_tab[i] = t1 * exp2_lut[t1_inc_cur];
>> +ff_aac_pow34sf_tab[i] = t2 * exp2_lut[t2_inc_cur];
>> +t1_inc_prev = t1_inc_cur;
>> +t2_inc_prev = t2_inc_cur;
>>  }
>>  }
>>  #endif /* CONFIG_HARDCODED_TABLES */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 1/3] avutil/tablegen: add tablegen compatibility hacks

[Ganesh Ajjanagadde]

On Fri, Nov 27, 2015 at 4:46 AM, Clément Bœsch  wrote:
> On Thu, Nov 26, 2015 at 11:58:10AM -0500, Ganesh Ajjanagadde wrote:
>> Reviewed-by: Ronald S. Bultje 
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/tablegen.h | 33 +
>>  1 file changed, 33 insertions(+)
>>  create mode 100644 libavutil/tablegen.h
>>
>> diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
>> new file mode 100644
>> index 000..01c8eea
>> --- /dev/null
>> +++ b/libavutil/tablegen.h
>> @@ -0,0 +1,33 @@
>> +/*
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>> + */
>> +
>> +/**
>> + * @file
>> + * Compatibility libm for table generation files
>> + */
>> +
>> +#ifndef AVUTIL_TABLEGEN_H
>> +#define AVUTIL_TABLEGEN_H
>> +
>> +// we lack some functions on all host platforms, and we don't care about
>> +// performance as it's performed at build time
>> +#define cbrt(x)   pow(x, 1.0 / 3)
>
>> +#define llrint(x) floor((x) + 0.5)
>> +#define lrint(x)  floor((x) + 0.5)
>> +
>
> does it work for x < 0?

Of course not exactly; I did recognize this. However, there are 2
reasons for this:
1. The old tablegen code did exactly a floor(x + 0.5), suggesting that
it did not matter. Thus, this was done for simplicity, anyway these
are imperfect hacks. The hacks can be improved, but felt that belongs
in a separate patch - no matter how they are improved, they remain
hacks (see number 2).
2. Even if one does the floor if x > 0, ceil if x < 0 trick, it has
issues with corner cases, I recall Michael mentioning something
regarding 0.4999 or something like that.

>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

[Rostislav Pehlivanov]

LGTM, but could you leave (just comment it out) the old code in there
so it's a little easier to follow?
>         //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
>         //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);

The accuracy increase is always nice.

On Thu, 2015-11-26 at 16:31 -0500, Ganesh Ajjanagadde wrote:
> This speeds up aac_tablegen to a ludicruous degree (~97%), i.e to the
> point
> where it can be argued that runtime initialization can always be done
> instead of
> hard-coded tables. The only cost is essentially a trivial increase in
> the stack size.
> 
> Even if one does not care about this, the patch also improves
> accuracy
> as detailed below.
> 
> Performance:
> Benchmark obtained by looping 10^4 times over ff_aac_tableinit.
> 
> Sample benchmark (x86-64, Haswell, GNU/Linux):
> old:
> 1295292 decicycles in ff_aac_tableinit, 512 runs,  0 skips
> 1275981 decicycles in ff_aac_tableinit,1024 runs,  0 skips
> 1272932 decicycles in ff_aac_tableinit,2048 runs,  0 skips
> 1262164 decicycles in ff_aac_tableinit,4096 runs,  0 skips
> 1256720 decicycles in ff_aac_tableinit,8192 runs,  0 skips
> 
> new:
> 25691 decicycles in ff_aac_tableinit, 505 runs,  7 skips
> 25130 decicycles in ff_aac_tableinit,1016 runs,  8 skips
> 25973 decicycles in ff_aac_tableinit,2036 runs, 12 skips
> 25911 decicycles in ff_aac_tableinit,4078 runs, 18 skips
> 25816 decicycles in ff_aac_tableinit,8154 runs, 38 skips
> 
> Accuracy:
> The previous code was resulting in needless loss of
> accuracy due to the pow being called in succession. As an
> illustration
> of this:
> ff_aac_pow34sf_tab[3]
> old : 0.0007598092294225
> new : 0.0007598091426864
> real: 0.0007598091778545
> 
> truncated to float
> old : 0.0007598092294225
> new : 0.0007598091426864
> real: 0.0007598091426864
> 
> showing that the old value was not correctly rounded. This affects a
> large number of elements of the array.
> 
> Patch tested with FATE.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/aac_tablegen.h | 38 -
> -
>  1 file changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
> index 8b223f9..255723b 100644
> --- a/libavcodec/aac_tablegen.h
> +++ b/libavcodec/aac_tablegen.h
> @@ -35,9 +35,43 @@ float ff_aac_pow34sf_tab[428];
>  av_cold void ff_aac_tableinit(void)
>  {
>  int i;
> +
> +/* 2^(i/16) for 0 <= i <= 15 */
> +const double exp2_lut[] = {
> +1.,
> +1.04427378242741384032,
> +1.09050773266525765921,
> +1.13878863475669165370,
> +1.18920711500272106672,
> +1.24185781207348404859,
> +1.29683955465100966593,
> +1.35425554693689272830,
> +1.41421356237309504880,
> +1.47682614593949931139,
> +1.54221082540794082361,
> +1.61049033194925430818,
> +1.68179283050742908606,
> +1.75625216037329948311,
> +1.83400808640934246349,
> +1.91520656139714729387,
> +};
> +double t1 = 8.8817841970012523233890533447265625e-16; // 2^(-50)
> +double t2 = 3.63797880709171295166015625e-12; // 2^(-38)
> +int t1_inc_cur, t2_inc_cur;
> +int t1_inc_prev = 0;
> +int t2_inc_prev = 8;
> +
>  for (i = 0; i < 428; i++) {
> -ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
> -ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);
> +t1_inc_cur = 4 * (i % 4);
> +t2_inc_cur = (8 + 3*i) % 16;
> +if (t1_inc_cur < t1_inc_prev)
> +t1 *= 2;
> +if (t2_inc_cur < t2_inc_prev)
> +t2 *= 2;
> +ff_aac_pow2sf_tab[i] = t1 * exp2_lut[t1_inc_cur];
> +ff_aac_pow34sf_tab[i] = t2 * exp2_lut[t2_inc_cur];
> +t1_inc_prev = t1_inc_cur;
> +t2_inc_prev = t2_inc_cur;
>  }
>  }
>  #endif /* CONFIG_HARDCODED_TABLES */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 1/3] avutil/tablegen: add tablegen compatibility hacks

[Clément Bœsch]

On Thu, Nov 26, 2015 at 11:58:10AM -0500, Ganesh Ajjanagadde wrote:
> Reviewed-by: Ronald S. Bultje 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/tablegen.h | 33 +
>  1 file changed, 33 insertions(+)
>  create mode 100644 libavutil/tablegen.h
> 
> diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
> new file mode 100644
> index 000..01c8eea
> --- /dev/null
> +++ b/libavutil/tablegen.h
> @@ -0,0 +1,33 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * Compatibility libm for table generation files
> + */
> +
> +#ifndef AVUTIL_TABLEGEN_H
> +#define AVUTIL_TABLEGEN_H
> +
> +// we lack some functions on all host platforms, and we don't care about
> +// performance as it's performed at build time
> +#define cbrt(x)   pow(x, 1.0 / 3)

> +#define llrint(x) floor((x) + 0.5)
> +#define lrint(x)  floor((x) + 0.5)
> +

does it work for x < 0?

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: handle AVERROR_REDO.

[Clément Bœsch]

On Thu, Nov 26, 2015 at 11:42:03PM +0100, Nicolas George wrote:
> Le sextidi 6 frimaire, an CCXXIV, Clement Boesch a écrit :
> > > An option can be added later to grant applications fine-grained control on
> > > the looping, but it can not be the default as it would be an API change, 
> > > and
> > > it probably should not be the default anyway.
> 
> > > +if (ret == AVERROR_REDO)
> > > +continue;
> > is the final user ever going to expect it somehow?
> 
> The final user does not see it at all, that is the whole point.
> 

But then it's still exposed by the API, and someone looking at handling
every error code might be wondering how to handle it.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

[wm4]

On Thu, 26 Nov 2015 21:21:08 +0100
Nicolas George  wrote:

> Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit :
> > I fail to see how letting such a workaround (required for flv) leak to  
> 
> ... and a few other demuxers...
> 
> > common code is more elegant.  
> 
> You fail to see, but I do, and I am not alone:
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180681.html
> 
> > eventually end up with dozens of special cases in utils.c.  
> 
> "Slippery slope" fallacy.
> 

Not really.

> > Such an application will have to run the demuxer in a thread.  
> 
> Can we use threads to get peace in the Middle East too? Threads seem to be
> your solution to almost everything, but you fail to realize they bring a
> whole lot of problems of their own, ranging from portability to trickiness
> and memory consumption.

Well, unlike with peace in middle-east, everyone already figured out
that threads are a good solution to I/O.

Especially for an API that is blocking anyway.

> If you want to use threads everywhere, fine, by all means do so. Bu please
> have the decency not to bikeshed proposals that make it easier NOT to use
> them when they do not make your life easier.

Sorry, but this doesn't have to do with anything, especially not with
my life. What's it with personal attacks on my life anyway? (I also
haven't heard yet whose life is supposed to get easier by letting the
user handle EREDO.)

As I've already said, using threads for I/O is commonly accepted, and
also the libavformat API is already this way. Why do you treat my
suggestion to use a thread with so much scorn?

What you suggest is adding a special-case for a single demuxer (and
maybe 1 or 2 others? you didn't make it clear). And this special-case
looks pretty unwarranted. All other demuxers follow the rule to read
data until a packet is found, and then return that packet. And if I/O
is slow or if a lot of data has to be read to find a packet, every
single demuxer blocks.

I really don't understand your thinking here anyway. Didn't you say
yourself that polling is bad?

I'd also like to hear from you how an application is supposed not to
block its GUI without running the demuxer in a separate thread? (Please
answer with a solution that does _not_ require rewriting every single
demuxer and AVIO protocol.)

And what exactly warrants handling flv differently, but not, say,
Matroska or AVI?

Also, I'm not blocking your patch. I'm just suggesting that flvdec.c
should handle this internally.

> > returning from the demuxer for a while because data is read is
> > perfectly ok because the API is inherently blocking. What are you going
> > to do if reading even a single packet takes milliseconds because the
> > data is e.g. shuffled over a slow HTTP link?  
> 
> Unrelated.
> 
> > I don't foresee that more demuxers will make use of AVERROR_REDO when
> > no new packet data is immediately available, only to appease to
> > applications with broken or less than ideal IO code.  
> 
> This block is fairly unclear, but the way I understand it, it is another
> "slippery slope" fallacy.

This is not about "slippery slopes", it's about consistency. I.e.
avoiding unnecessary special-cases, which is always good for an API.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] QSV

[Ivan Uskov]

Hello Michael,

Thursday, November 26, 2015, 11:13:45 PM, you wrote:

MN> Hi

MN> are there any QSV patches which have been reviewed and have no
MN> objections raised against them ?
MN> that is patches i should apply/push for qsv ...
Excluding two patches by Will Kelleher which were re-checked today only one
small patch still not reviewed.
It is the
[PATCH] "libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame."
at the September 9, please look. I can resend it if necessary.

MN> ivan, also it might make sense if you would be on IRC, so you and
MN> others could discuss any QSV issues or questions or patches or ...
MN> iam asking as it was asked on IRC a few days ago
MN> "Nov 22 18:51:46 *  Daemon404 wonders if "Ivan Uskov" is on irc"
Ok, I will try to connect to channel and be online.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel