Re: [FFmpeg-devel] have some major changes for nvenc support

[Roger Pack]

On 11/5/15, wm4  wrote:
> On Thu, 5 Nov 2015 16:23:04 +0800
> Agatha Hu  wrote:
>
>> 2) We use AVFrame::opaque field to store a customized ffnvinfo struture
>> to prevent expensive CPU<->GPU transferration. Without it, the workflow
>> will be like CPU AVFrame input-->copy to GPU-->do CUDA resizing-->copy
>> to CPU AVFrame-->copy to GPU-->NVENC encoding. And now it becomes:
>> CPU AVFrame input-->copy to GPU-->do CUDA resizing-->NVENC encoding.
>> Our strategy is to check whether AVFrame::opaque is not null AND its
>> first 128 bytes matches some particular GUID. If so, AVFrame::opaque is
>> a valid ffnvinfo struture and we read GPU address directly from it
>> instead of copying data from AVFrame.
>
> Please no, not another hack that makes the hw decoding API situation
> worse. Do this properly and coordinate with Gwenole Beauchesne, who
> plans improvements into this direction.

Which part are you referring to (though I'll admit putting some stuff
in libavutil seems a bit suspect).
It would be nice to have the nvresize filter available anyway, and it
looks like it mostly just deals with private context variables.
Cheers!
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[wm4]

On Fri, 8 Jan 2016 17:55:38 +1100
Jean-Yves Avenard  wrote:

> One of the issues we've faced was with our reftest tests , with pages
> creating hundreds of small video elements (the test change
> orientation, sizes, transparency and the like and check that there's
> no regression on how things are displayed).

Do I understand right that only your tests do this? And that there are
no real world sites which do this? And that you want us to change our
architecture so that your tests actually run?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

[Christophe Gisquet]

2016-01-08 17:41 GMT+01:00 Christophe Gisquet :
> On a side note, do you intend to do an avx version?

Just did that, need a tail processing, and no gain on a(n) Haswell
over a 7 minute sample.

The code for reference, over your set of patches.

-- 
Christophe


0001-x86-float_dsp-avx-version-of-butterflies_float.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

[James Almer]

On 1/8/2016 3:56 PM, Christophe Gisquet wrote:
> 2016-01-08 17:41 GMT+01:00 Christophe Gisquet :
>> > On a side note, do you intend to do an avx version?
> Just did that, need a tail processing, and no gain on a(n) Haswell
> over a 7 minute sample.

Then honestly i don't think it's worth it. Maybe if we could change the
alignment to 32 bytes and making len multiple of 8 or 16, but not sure
how feasible is that.

Anyway, patchset pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/libvpxenc: Improve documentation for cpu-used

[James Zern]

On Fri, Jan 8, 2016 at 1:58 AM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes ticket #5140 here, seems to match:
> https://github.com/webmproject/libvpx/commit/a16f07537501ac96531577d5af004ad0b591a705
>
> Please comment, Carl Eugen
>

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

Re: [FFmpeg-devel] [PATCH] configure: Use libgcrypt-config if available

[Michael Niedermayer]

On Tue, Dec 29, 2015 at 10:47:05PM +, Ricardo Constantino wrote:
> Signed-off-by: Ricardo Constantino 
> ---
>  configure | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)

applied

thanks

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH] configure: Use libgcrypt-config if available

[James Almer]

On 12/29/2015 7:47 PM, Ricardo Constantino wrote:
> Signed-off-by: Ricardo Constantino 
> ---
>  configure | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index c986aba..d639b8d 100755
> --- a/configure
> +++ b/configure
> @@ -5396,7 +5396,6 @@ enabled avisynth  && { { check_lib2 "windows.h" 
> LoadLibrary; } ||
>  enabled chromaprint   && require chromaprint chromaprint.h 
> chromaprint_get_version -lchromaprint
>  enabled decklink  && { check_header DeckLinkAPI.h || die "ERROR: 
> DeckLinkAPI.h header not found"; }
>  enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h 
> header not found"; }
> -enabled gcrypt&& require2 gcrypt gcrypt.h gcry_mpi_new -lgcrypt
>  enabled gmp   && require2 gmp gmp.h mpz_export -lgmp
>  enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h 
> gnutls_global_init
>  enabled ladspa&& { check_header ladspa.h || die "ERROR: ladspa.h 
> header not found"; }
> @@ -,6 +5554,17 @@ if enabled libdc1394; then
>  enable libdc1394_1; } ||
>  die "ERROR: No version of libdc1394 found "
>  fi
> +
> +if enabled gcrypt; then
> +GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
> +if "${GCRYPT_CONFIG}" --version > /dev/null 2>&1; then
> +gcrypt_libs=$("${GCRYPT_CONFIG}" --libs)
> +require2 gcrypt gcrypt.h gcry_mpi_new $gcrypt_libs

Shouldn't this also check libgcrypt-config --cflags? Assuming
the library is in an unusual path, the above will look for
the header in whatever include path configure was using by
then and either fail or include the wrong headers.

> +else
> +require2 gcrypt gcrypt.h gcry_mpi_new -lgcrypt
> +fi
> +fi
> +
>  if ! disabled sdl; then
>  SDL_CONFIG="${cross_prefix}sdl-config"
>  if check_pkg_config sdl SDL_events.h SDL_PollEvent; then
> 

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

[FFmpeg-devel] [PATCH 1/3] lavf: add AV_DISPOSITION_TIMED_THUMBNAILS

[Rodger Combs]

---
 ffprobe.c   |  1 +
 libavformat/avformat.h  | 12 +---
 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 ++--
 tests/ref/fate/ffprobe_compact  |  6 +++---
 tests/ref/fate/ffprobe_csv  |  6 +++---
 tests/ref/fate/ffprobe_default  |  3 +++
 tests/ref/fate/ffprobe_flat |  3 +++
 tests/ref/fate/ffprobe_ini  |  3 +++
 tests/ref/fate/ffprobe_json |  9 ++---
 tests/ref/fate/ffprobe_xml  |  6 +++---
 14 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index c352b44..20af969 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2326,6 +2326,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 PRINT_DISPOSITION(VISUAL_IMPAIRED,  "visual_impaired");
 PRINT_DISPOSITION(CLEAN_EFFECTS,"clean_effects");
 PRINT_DISPOSITION(ATTACHED_PIC, "attached_pic");
+PRINT_DISPOSITION(TIMED_THUMBNAILS, "timed_thumbnails");
 writer_print_section_footer(w);
 }
 
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 95a645b..eaf6270 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -824,11 +824,17 @@ typedef struct AVIndexEntry {
 #define AV_DISPOSITION_CLEAN_EFFECTS 0x0200  /**< stream without voice */
 /**
  * The stream is stored in the file as an attached picture/"cover art" (e.g.
- * APIC frame in ID3v2). The single packet associated with it will be returned
- * among the first few packets read from the file unless seeking takes place.
- * It can also be accessed at any time in AVStream.attached_pic.
+ * APIC frame in ID3v2). The first (usually only) packet associated with it
+ * will be returned among the first few packets read from the file unless
+ * seeking takes place. It can also be accessed at any time in
+ * AVStream.attached_pic.
  */
 #define AV_DISPOSITION_ATTACHED_PIC  0x0400
+/**
+ * The stream is sparse, and contains thumbnail images, often corresponding
+ * to chapter markers. Only ever used with AV_DISPOSITION_ATTACHED_PIC.
+ */
+#define AV_DISPOSITION_TIMED_THUMBNAILS  0x0800
 
 typedef struct AVStreamInternal AVStreamInternal;
 
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf 
b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
index 4caec5a..ea02091 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
@@ -1 +1 @@
-37b4a84fce71b3f8b129f8b866c5f55a 
*tests/data/fate/concat-demuxer-extended-lavf-mxf.ffprobe
+f668a81fcf0cf4ebc8fa26ce6a4b05cc 
*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 1965050..4b7b061 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
@@ -1 +1 @@
-2f5e935f86304c843be1454b1354a4b7 
*tests/data/fate/concat-demuxer-extended-lavf-mxf_d10.ffprobe
+e335a7dc83b776021bd3557928a3febd 
*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 c28db28..5fb044f 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|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
+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|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|0|0x060A2B340101010501010D001301
diff --git 

[FFmpeg-devel] [PATCH 2/3] lavf/mov: improve `tref/chap` chapter handling

[Rodger Combs]

3 parts:
- Supports multiple chapter streams
- Exports regular text chapter streams as opaque data. This prevents consumers
  from showing chapters as if they were regular subtitle streams.
- Exports video chapter streams as thumbnails, and provides the first one as
  an attached_pic.
---
 libavformat/isom.h |  3 ++-
 libavformat/mov.c  | 52 +---
 2 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index e07dc0e9..31f270e 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -200,7 +200,8 @@ typedef struct MOVContext {
 unsigned trex_count;
 int itunes_metadata;  ///< metadata are itunes style
 int handbrake_version;
-int chapter_track;
+int *chapter_tracks;
+unsigned int nb_chapter_tracks;
 int use_absolute_path;
 int ignore_editlist;
 int ignore_chapters;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 98c2f51..4040cf7 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3461,7 +3461,18 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 static int mov_read_chap(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
-c->chapter_track = avio_rb32(pb);
+unsigned i, num;
+av_free(c->chapter_tracks);
+
+num = atom.size / 4;
+if (!(c->chapter_tracks = av_malloc(num * 4)))
+return AVERROR(ENOMEM);
+
+c->nb_chapter_tracks = num;
+
+for (i = 0; i < num; i++)
+c->chapter_tracks[i] = avio_rb32(pb);
+
 return 0;
 }
 
@@ -4410,25 +4421,50 @@ static int mov_probe(AVProbeData *p)
 static void mov_read_chapters(AVFormatContext *s)
 {
 MOVContext *mov = s->priv_data;
-AVStream *st = NULL;
+AVStream *st;
 MOVStreamContext *sc;
 int64_t cur_pos;
-int i;
+int i, j;
+int chapter_track;
 
+for (j = 0; j < mov->nb_chapter_tracks; j++) {
+chapter_track = mov->chapter_tracks[j];
+st = NULL;
 for (i = 0; i < s->nb_streams; i++)
-if (s->streams[i]->id == mov->chapter_track) {
+if (s->streams[i]->id == chapter_track) {
 st = s->streams[i];
 break;
 }
 if (!st) {
 av_log(s, AV_LOG_ERROR, "Referenced QT chapter track not found\n");
-return;
+continue;
 }
 
-st->discard = AVDISCARD_ALL;
 sc = st->priv_data;
 cur_pos = avio_tell(sc->pb);
 
+if (st->codec->codec_type == AVMEDIA_TYPE_VIDEO) {
+st->disposition |= AV_DISPOSITION_ATTACHED_PIC | 
AV_DISPOSITION_TIMED_THUMBNAILS;
+if (st->nb_index_entries) {
+// Retrieve the first frame, if possible
+AVPacket pkt;
+AVIndexEntry *sample = >index_entries[0];
+if (avio_seek(sc->pb, sample->pos, SEEK_SET) != sample->pos) {
+av_log(s, AV_LOG_ERROR, "Failed to retrieve first frame\n");
+goto finish;
+}
+
+if (av_get_packet(sc->pb, , sample->size) < 0)
+goto finish;
+
+st->attached_pic  = pkt;
+st->attached_pic.stream_index = st->index;
+st->attached_pic.flags   |= AV_PKT_FLAG_KEY;
+}
+} else {
+st->codec->codec_type = AVMEDIA_TYPE_DATA;
+st->codec->codec_id = AV_CODEC_ID_BIN_DATA;
+st->discard = AVDISCARD_ALL;
 for (i = 0; i < st->nb_index_entries; i++) {
 AVIndexEntry *sample = >index_entries[i];
 int64_t end = i+1 < st->nb_index_entries ? 
st->index_entries[i+1].timestamp : st->duration;
@@ -4477,8 +4513,10 @@ static void mov_read_chapters(AVFormatContext *s)
 avpriv_new_chapter(s, i, st->time_base, sample->timestamp, end, title);
 av_freep();
 }
+}
 finish:
 avio_seek(sc->pb, cur_pos, SEEK_SET);
+}
 }
 
 static int parse_timecode_in_framenum_format(AVFormatContext *s, AVStream *st,
@@ -4770,7 +4808,7 @@ static int mov_read_header(AVFormatContext *s)
 av_log(mov->fc, AV_LOG_TRACE, "on_parse_exit_offset=%"PRId64"\n", 
avio_tell(pb));
 
 if (pb->seekable) {
-if (mov->chapter_track > 0 && !mov->ignore_chapters)
+if (mov->nb_chapter_tracks > 0 && !mov->ignore_chapters)
 mov_read_chapters(s);
 for (i = 0; i < s->nb_streams; i++)
 if (s->streams[i]->codec->codec_tag == AV_RL32("tmcd"))
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 3/3] lavf/mov: reindent

[Rodger Combs]

---
 libavformat/mov.c | 156 +++---
 1 file changed, 78 insertions(+), 78 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4040cf7..42a232f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4428,94 +4428,94 @@ static void mov_read_chapters(AVFormatContext *s)
 int chapter_track;
 
 for (j = 0; j < mov->nb_chapter_tracks; j++) {
-chapter_track = mov->chapter_tracks[j];
-st = NULL;
-for (i = 0; i < s->nb_streams; i++)
-if (s->streams[i]->id == chapter_track) {
-st = s->streams[i];
-break;
+chapter_track = mov->chapter_tracks[j];
+st = NULL;
+for (i = 0; i < s->nb_streams; i++)
+if (s->streams[i]->id == chapter_track) {
+st = s->streams[i];
+break;
+}
+if (!st) {
+av_log(s, AV_LOG_ERROR, "Referenced QT chapter track not found\n");
+continue;
 }
-if (!st) {
-av_log(s, AV_LOG_ERROR, "Referenced QT chapter track not found\n");
-continue;
-}
 
-sc = st->priv_data;
-cur_pos = avio_tell(sc->pb);
+sc = st->priv_data;
+cur_pos = avio_tell(sc->pb);
+
+if (st->codec->codec_type == AVMEDIA_TYPE_VIDEO) {
+st->disposition |= AV_DISPOSITION_ATTACHED_PIC | 
AV_DISPOSITION_TIMED_THUMBNAILS;
+if (st->nb_index_entries) {
+// Retrieve the first frame, if possible
+AVPacket pkt;
+AVIndexEntry *sample = >index_entries[0];
+if (avio_seek(sc->pb, sample->pos, SEEK_SET) != sample->pos) {
+av_log(s, AV_LOG_ERROR, "Failed to retrieve first 
frame\n");
+goto finish;
+}
 
-if (st->codec->codec_type == AVMEDIA_TYPE_VIDEO) {
-st->disposition |= AV_DISPOSITION_ATTACHED_PIC | 
AV_DISPOSITION_TIMED_THUMBNAILS;
-if (st->nb_index_entries) {
-// Retrieve the first frame, if possible
-AVPacket pkt;
-AVIndexEntry *sample = >index_entries[0];
-if (avio_seek(sc->pb, sample->pos, SEEK_SET) != sample->pos) {
-av_log(s, AV_LOG_ERROR, "Failed to retrieve first frame\n");
-goto finish;
-}
+if (av_get_packet(sc->pb, , sample->size) < 0)
+goto finish;
 
-if (av_get_packet(sc->pb, , sample->size) < 0)
-goto finish;
+st->attached_pic  = pkt;
+st->attached_pic.stream_index = st->index;
+st->attached_pic.flags   |= AV_PKT_FLAG_KEY;
+}
+} else {
+st->codec->codec_type = AVMEDIA_TYPE_DATA;
+st->codec->codec_id = AV_CODEC_ID_BIN_DATA;
+st->discard = AVDISCARD_ALL;
+for (i = 0; i < st->nb_index_entries; i++) {
+AVIndexEntry *sample = >index_entries[i];
+int64_t end = i+1 < st->nb_index_entries ? 
st->index_entries[i+1].timestamp : st->duration;
+uint8_t *title;
+uint16_t ch;
+int len, title_len;
+
+if (end < sample->timestamp) {
+av_log(s, AV_LOG_WARNING, "ignoring stream duration which 
is shorter than chapters\n");
+end = AV_NOPTS_VALUE;
+}
 
-st->attached_pic  = pkt;
-st->attached_pic.stream_index = st->index;
-st->attached_pic.flags   |= AV_PKT_FLAG_KEY;
-}
-} else {
-st->codec->codec_type = AVMEDIA_TYPE_DATA;
-st->codec->codec_id = AV_CODEC_ID_BIN_DATA;
-st->discard = AVDISCARD_ALL;
-for (i = 0; i < st->nb_index_entries; i++) {
-AVIndexEntry *sample = >index_entries[i];
-int64_t end = i+1 < st->nb_index_entries ? 
st->index_entries[i+1].timestamp : st->duration;
-uint8_t *title;
-uint16_t ch;
-int len, title_len;
-
-if (end < sample->timestamp) {
-av_log(s, AV_LOG_WARNING, "ignoring stream duration which is 
shorter than chapters\n");
-end = AV_NOPTS_VALUE;
-}
+if (avio_seek(sc->pb, sample->pos, SEEK_SET) != sample->pos) {
+av_log(s, AV_LOG_ERROR, "Chapter %d not found in file\n", 
i);
+goto finish;
+}
 
-if (avio_seek(sc->pb, sample->pos, SEEK_SET) != sample->pos) {
-av_log(s, AV_LOG_ERROR, "Chapter %d not found in file\n", i);
-goto finish;
-}
+// the first two bytes are the length of the title
+len = avio_rb16(sc->pb);
+if (len > sample->size-2)
+continue;
+title_len = 2*len + 1;
+if (!(title = av_mallocz(title_len)))
+goto finish;
+
+// The samples could 

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

[Christophe Gisquet]

Hi,

2016-01-08 20:16 GMT+01:00 James Almer :
> Then honestly i don't think it's worth it. Maybe if we could change the
> alignment to 32 bytes and making len multiple of 8 or 16, but not sure
> how feasible is that.

There could be a more specialized version, but of doubtful use (maybe dca2?)

The main customer, aacdec, does use multiple of 4 lengths, and
consequently, unaligned positions.

And I don't mind at all not applying that patch, it was foremostly to
write my first piece of avx code.

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

Re: [FFmpeg-devel] [PATCH 04/10] libavcodec/ccaption_dec: reap_screen after flipping on EOC

[Aman Gupta]

On Fri, Jan 8, 2016 at 2:50 AM, Anshul Maheshwari 
wrote:

>
>
> On Thu, Jan 7, 2016 at 6:14 AM, Aman Gupta  wrote:
>
>> Probably should have written a longer commit message here. The EOC
>> command stands for "end of caption" aka "display buffer". It's used with
>> POPON mode, where characters are written to an off-screen buffer and EOC
>> flips the buffers to display what has been written so far. Thus, it makes
>> sense to reap the screen *after* flipping the active screen, not *before*.
>>
>> The previous behavior was simply wrong, but masked by other bugs also
>> fixed in this patchset.
>>
>> Aman
>>
>> On Tue, Jan 5, 2016 at 11:41 PM, Aman Gupta  wrote:
>>
>>> From: Aman Gupta 
>>>
>>> ---
>>>  libavcodec/ccaption_dec.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
>>> index 9f17e77..5d4c568 100644
>>> --- a/libavcodec/ccaption_dec.c
>>> +++ b/libavcodec/ccaption_dec.c
>>> @@ -399,9 +399,9 @@ static void handle_erase(CCaptionSubContext *ctx,
>>> int n_screen)
>>>
>>>  static void handle_eoc(CCaptionSubContext *ctx)
>>>  {
>>> -reap_screen(ctx);
>>>  ctx->active_screen = !ctx->active_screen;
>>>  ctx->cursor_column = 0;
>>> +reap_screen(ctx);
>>>  }
>>>
>>>  static void handle_delete_end_of_row(CCaptionSubContext *ctx, char hi,
>>> char lo)
>>> --
>>> 2.5.3
>>>
>>>
>> I dont see it as bug, this problem comes because of change in 02/10 patch.
>
> handle_eoc always called handle_edm, am I missing some patch?
>

I removed the call to EDM from inside EOC, in "libavcodec/ccaption_dec:
reap_screen is not necessary when clearing screen or buffer"

Always calling EDM does not make sense, because the caption stream will
already send EDM when it is required. I think the EDM from EOC behavior was
a work around because previously "erase non-displayed memory" was not
implemented. See commit: libavcodec/ccaption_dec: implement "erase non
displayed memory"


>
> how does it matter, since this code has to be exectued sequentially? reap
> before or after I see them  at same instant or at same command.
>

This matters because reap_screen will look at active_screen. EOC means
"display buffer", so we must first flip the active screen to display the
off-screen buffer, and then reap it. If you reap first, you are reading
from the incorrect buffer.


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

Re: [FFmpeg-devel] [PATCH] configure: Use libgcrypt-config if available

[Ricardo Constantino]

On 8 January 2016 at 20:40, James Almer  wrote:

> Shouldn't this also check libgcrypt-config --cflags? Assuming
> the library is in an unusual path, the above will look for
> the header in whatever include path configure was using by
> then and either fail or include the wrong headers.


The issue was -lgpg-error wasn't being included, not that the libs were in
a unusual path.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Use libgcrypt-config if available

[James Almer]

On 1/8/2016 8:41 PM, Ricardo Constantino wrote:
> Like this?

Yes, pushed. Thank you.

> 
> 
> 0001-configure-Use-libgcrypt-config-s-cflags.patch
> 
> 
> From f4e0c96e41da606a5d83ebff1dbad718c8fa2485 Mon Sep 17 00:00:00 2001
> From: Ricardo Constantino 
> Date: Fri, 8 Jan 2016 23:40:50 +
> Subject: [PATCH] configure: Use libgcrypt-config's cflags
> 
> ---
>  configure | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 7cc0119..19898be 100755
> --- a/configure
> +++ b/configure
> @@ -5578,8 +5578,11 @@ fi
>  if enabled gcrypt; then
>  GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
>  if "${GCRYPT_CONFIG}" --version > /dev/null 2>&1; then
> +gcrypt_cflags=$("${GCRYPT_CONFIG}" --cflags)
>  gcrypt_libs=$("${GCRYPT_CONFIG}" --libs)
> -require2 gcrypt gcrypt.h gcry_mpi_new $gcrypt_libs
> +check_func_headers gcrypt.h gcry_mpi_new $gcrypt_cflags $gcrypt_libs 
> ||
> +die "ERROR: gcrypt not found"
> +add_cflags $gcrypt_cflags && add_extralibs $gcrypt_libs
>  else
>  require2 gcrypt gcrypt.h gcry_mpi_new -lgcrypt
>  fi
> -- 2.6.3


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

Re: [FFmpeg-devel] [PATCH] configure: Use libgcrypt-config if available

[Michael Niedermayer]

On Fri, Jan 08, 2016 at 09:02:34PM -0300, James Almer wrote:
> On 1/8/2016 8:41 PM, Ricardo Constantino wrote:
> > Like this?
> 
> Yes, pushed. Thank you.

thanks as well

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH 1/3] lavf: add AV_DISPOSITION_TIMED_THUMBNAILS

[Marton Balint]

On Fri, 8 Jan 2016, Rodger Combs wrote:

[...]

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 95a645b..eaf6270 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -824,11 +824,17 @@ typedef struct AVIndexEntry {
#define AV_DISPOSITION_CLEAN_EFFECTS 0x0200  /**< stream without voice */
/**
 * The stream is stored in the file as an attached picture/"cover art" (e.g.
- * APIC frame in ID3v2). The single packet associated with it will be returned
- * among the first few packets read from the file unless seeking takes place.
- * It can also be accessed at any time in AVStream.attached_pic.
+ * APIC frame in ID3v2). The first (usually only) packet associated with it
+ * will be returned among the first few packets read from the file unless
+ * seeking takes place. It can also be accessed at any time in
+ * AVStream.attached_pic.


Maybe you should clarify that if the stream contains multiple 
packets, what will happen to AVStream.attached_pic. Will it contain all 
packets? Or only the first? Or some random?



 */
#define AV_DISPOSITION_ATTACHED_PIC  0x0400
+/**
+ * The stream is sparse, and contains thumbnail images, often corresponding
+ * to chapter markers. Only ever used with AV_DISPOSITION_ATTACHED_PIC.
+ */
+#define AV_DISPOSITION_TIMED_THUMBNAILS  0x0800


I don't if it is better to use this flag along with attached pic 
instead of keeping it distinct from it.


Changing the semantics of attached pics streams (multiple packets, timed 
packets) seems quite a substantial change, so if it were up to me, I'd 
rather keep this new flag distinct.


Where do you benefit if you use ATTACHED_PIC for this as well?

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

Re: [FFmpeg-devel] [PATCH 1/3] lavf: add AV_DISPOSITION_TIMED_THUMBNAILS

[Rodger Combs]

> On Jan 8, 2016, at 18:30, Marton Balint  wrote:
> 
> On Fri, 8 Jan 2016, Rodger Combs wrote:
> 
> [...]
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index 95a645b..eaf6270 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -824,11 +824,17 @@ typedef struct AVIndexEntry {
>> #define AV_DISPOSITION_CLEAN_EFFECTS 0x0200  /**< stream without voice */
>> /**
>> * The stream is stored in the file as an attached picture/"cover art" (e.g.
>> - * APIC frame in ID3v2). The single packet associated with it will be 
>> returned
>> - * among the first few packets read from the file unless seeking takes 
>> place.
>> - * It can also be accessed at any time in AVStream.attached_pic.
>> + * APIC frame in ID3v2). The first (usually only) packet associated with it
>> + * will be returned among the first few packets read from the file unless
>> + * seeking takes place. It can also be accessed at any time in
>> + * AVStream.attached_pic.
> 
> Maybe you should clarify that if the stream contains multiple packets, what 
> will happen to AVStream.attached_pic. Will it contain all packets? Or only 
> the first? Or some random?
This does explain that (though it's awkwardly-worded so I can see why it'd be 
confusing). It contains the first packet.

> 
>> */
>> #define AV_DISPOSITION_ATTACHED_PIC  0x0400
>> +/**
>> + * The stream is sparse, and contains thumbnail images, often corresponding
>> + * to chapter markers. Only ever used with AV_DISPOSITION_ATTACHED_PIC.
>> + */
>> +#define AV_DISPOSITION_TIMED_THUMBNAILS  0x0800
> 
> I don't if it is better to use this flag along with attached pic instead of 
> keeping it distinct from it.
> 
> Changing the semantics of attached pics streams (multiple packets, timed 
> packets) seems quite a substantial change, so if it were up to me, I'd rather 
> keep this new flag distinct.
> 
> Where do you benefit if you use ATTACHED_PIC for this as well?
My goal there is to get existing consumers not to treat them as "normal" video 
streams, but I'd be OK with making this distinct instead.

> 
> Thanks,
> Marton
> ___
> 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] configure: Use libgcrypt-config if available

[Ricardo Constantino]

Like this?


0001-configure-Use-libgcrypt-config-s-cflags.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Use libgcrypt-config if available

[James Almer]

On 1/8/2016 6:39 PM, Ricardo Constantino wrote:
> On 8 January 2016 at 20:40, James Almer  wrote:
> 
>> Shouldn't this also check libgcrypt-config --cflags? Assuming
>> the library is in an unusual path, the above will look for
>> the header in whatever include path configure was using by
>> then and either fail or include the wrong headers.
> 
> 
> The issue was -lgpg-error wasn't being included, not that the libs were in
> a unusual path.

But what if they are? The current check will look at whatever include path
configure was using at that point. If gcrypt was installed elsewhere,
libgrypt-config --libs will give the correct library path but the check will
nonetheless use an incorrect include path, which as i said may contain
incorrect gcrypt headers (old version, host gcrypt instead of target, etc),
or no headers at all.

You need to use the output of libgrypt-config --cflags for the check, then add
it to cflags, like all the pkg-config checks do.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 04/10] libavcodec/ccaption_dec: reap_screen after flipping on EOC

[Anshul Maheshwari]

On Thu, Jan 7, 2016 at 6:14 AM, Aman Gupta  wrote:

> Probably should have written a longer commit message here. The EOC command
> stands for "end of caption" aka "display buffer". It's used with POPON
> mode, where characters are written to an off-screen buffer and EOC flips
> the buffers to display what has been written so far. Thus, it makes sense
> to reap the screen *after* flipping the active screen, not *before*.
>
> The previous behavior was simply wrong, but masked by other bugs also
> fixed in this patchset.
>
> Aman
>
> On Tue, Jan 5, 2016 at 11:41 PM, Aman Gupta  wrote:
>
>> From: Aman Gupta 
>>
>> ---
>>  libavcodec/ccaption_dec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
>> index 9f17e77..5d4c568 100644
>> --- a/libavcodec/ccaption_dec.c
>> +++ b/libavcodec/ccaption_dec.c
>> @@ -399,9 +399,9 @@ static void handle_erase(CCaptionSubContext *ctx, int
>> n_screen)
>>
>>  static void handle_eoc(CCaptionSubContext *ctx)
>>  {
>> -reap_screen(ctx);
>>  ctx->active_screen = !ctx->active_screen;
>>  ctx->cursor_column = 0;
>> +reap_screen(ctx);
>>  }
>>
>>  static void handle_delete_end_of_row(CCaptionSubContext *ctx, char hi,
>> char lo)
>> --
>> 2.5.3
>>
>>
> I dont see it as bug, this problem comes because of change in 02/10 patch.

handle_eoc always called handle_edm, am I missing some patch?

how does it matter, since this code has to be exectued sequentially? reap
before or after I see them  at same instant or at same command.

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

Re: [FFmpeg-devel] [PATCH v5] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Michael Niedermayer]

On Wed, Jan 06, 2016 at 04:32:25AM +0100, Mats Peterson wrote:
> In many older QuickTime files, the audio format, or "fourcc", is
> 0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
> states the following regarding this situation:
> 
> "This format descriptor should not be used, but may be found in some
> files. Samples are assumed to be stored in either 'raw ' or 'twos'
> format, depending on the sample size field in the sound description."
> 
> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
> not.
> 
> Mats
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  matroskadec.c |9 +
>  1 file changed, 9 insertions(+)
> a8ee382fbe551d1f6fc965e81d79066245333bcc  
> 0001-lavf-matroskadec-A_QUICKTIME-and-AV_CODEC_ID_NONE.patch
> From 9adba279d3ca9dada9774ff204e7fb4a255bfb9e Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Wed, 6 Jan 2016 04:13:47 +0100
> Subject: [PATCH v5] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE
> 
> In many older QuickTime files, the audio format, or "fourcc", is
> 0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
> states the following regarding this situation:
> 
> "This format descriptor should not be used, but may be found in some
> files. Samples are assumed to be stored in either 'raw ' or 'twos'
> format, depending on the sample size field in the sound description."
> 
> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
> not.
> 
> Mats
> 
> ---
>  libavformat/matroskadec.c |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 9de7cfb..440c9f9 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1869,6 +1869,15 @@ static int matroska_parse_tracks(AVFormatContext *s)
>  fourcc = AV_RL32(track->codec_priv.data);
>  codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
>  }
> +if (codec_id == AV_CODEC_ID_NONE) {
> +if (track->audio.bitdepth == 8) {
> +fourcc = MKTAG('r','a','w',' ');
> +codec_id = ff_codec_get_id(ff_codec_movaudio_tags, 
> fourcc);
> +} else if (track->audio.bitdepth == 16) {
> +fourcc = MKTAG('t','w','o','s');
> +codec_id = ff_codec_get_id(ff_codec_movaudio_tags, 
> fourcc);
> +}
> +}
>  } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&

where can i find a file to test this and the mov patch ?
also codec_id will be AV_CODEC_ID_NONE for any new fourcc that is
not supported not just fourcc == 0
does it work to check fourcc or the place that fourcc is stored
i addition or instead of codec_id ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH] x86/vf_w3fdif: 32-bit compatibility for w3fdif_simple_high

[Hendrik Leppkes]

On Thu, Jan 7, 2016 at 2:13 PM, Hendrik Leppkes  wrote:
> ---
>  libavfilter/x86/vf_w3fdif.asm| 35 +--
>  libavfilter/x86/vf_w3fdif_init.c |  2 +-
>  2 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
> index c3c73ea..52628c3 100644
> --- a/libavfilter/x86/vf_w3fdif.asm
> +++ b/libavfilter/x86/vf_w3fdif.asm
> @@ -102,14 +102,22 @@ cglobal w3fdif_complex_low, 4, 7, 8, 0, work_line, 
> in_lines_cur0, coef, linesize
>  REP_RET
>
>  %if ARCH_X86_64
> -
>  cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0, 
> in_lines_adj0, coef, linesize
> +%else
> +cglobal w3fdif_simple_high, 4, 7, 8, 0, work_line, in_lines_cur0, 
> in_lines_adj0, coef, linesize
> +%endif
>  movq  m2, [coefq]
> +%if ARCH_X86_64
>  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, in_lines_cur1, 
> linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
> +xor  offsetq, offsetq
> +%else
> +DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, in_lines_cur1, 
> in_lines_cur2, in_lines_adj1, in_lines_adj2
> +%define linesized r4mp
> +%endif
> +
>  pshufdm0, m2, q
>  SPLATWm2, m2, 2
>  pxor  m7, m7
> -mov  offsetq, 0
>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
>  mov   in_lines_cur1q, [in_lines_cur0q+gprsize]
>  mov   in_lines_cur0q, [in_lines_cur0q]
> @@ -117,8 +125,21 @@ cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, 
> in_lines_cur0, in_lines_adj0,
>  mov   in_lines_adj1q, [in_lines_adj0q+gprsize]
>  mov   in_lines_adj0q, [in_lines_adj0q]
>
> +%if ARCH_X86_32
> +sub in_lines_cur1q, in_lines_cur0q
> +sub in_lines_cur2q, in_lines_cur0q
> +sub in_lines_adj0q, in_lines_cur0q
> +sub in_lines_adj1q, in_lines_cur0q
> +sub in_lines_adj2q, in_lines_cur0q
> +%define offsetq in_lines_cur0q
> +%endif
> +
>  .loop:
> +%if ARCH_X86_64
>  movh   m3, [in_lines_cur0q+offsetq]
> +%else
> +movh   m3, [in_lines_cur0q]
> +%endif
>  movh   m4, [in_lines_cur1q+offsetq]
>  punpcklbw  m3, m7
>  punpcklbw  m4, m7
> @@ -143,15 +164,25 @@ cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, 
> in_lines_cur0, in_lines_adj0,
>  pmaddwdm6, m2
>  paddd  m3, m5
>  paddd  m4, m6
> +%if ARCH_X86_64
>  paddd  m3, [work_lineq+offsetq*4]
>  paddd  m4, [work_lineq+offsetq*4+mmsize]
>  mova   [work_lineq+offsetq*4], m3
>  mova[work_lineq+offsetq*4+mmsize], m4
> +%else
> +paddd  m3, [work_lineq]
> +paddd  m4, [work_lineq+mmsize]
> +mova [work_lineq], m3
> +mova  [work_lineq+mmsize], m4
> +addwork_lineq, mmsize*2
> +%endif
>  add   offsetq, mmsize/2
>  sub linesized, mmsize/2
>  jg .loop
>  REP_RET
>
> +%if ARCH_X86_64
> +
>  cglobal w3fdif_complex_high, 5, 13, 10, 0, work_line, in_lines_cur0, 
> in_lines_adj0, coef, linesize
>  movq  m0, [coefq+0]
>  movd  m4, [coefq+8]
> diff --git a/libavfilter/x86/vf_w3fdif_init.c 
> b/libavfilter/x86/vf_w3fdif_init.c
> index 72ea657..9bf06e8 100644
> --- a/libavfilter/x86/vf_w3fdif_init.c
> +++ b/libavfilter/x86/vf_w3fdif_init.c
> @@ -51,12 +51,12 @@ av_cold void ff_w3fdif_init_x86(W3FDIFDSPContext *dsp)
>
>  if (EXTERNAL_SSE2(cpu_flags)) {
>  dsp->filter_simple_low   = ff_w3fdif_simple_low_sse2;
> +dsp->filter_simple_high  = ff_w3fdif_simple_high_sse2;
>  dsp->filter_complex_low  = ff_w3fdif_complex_low_sse2;
>  dsp->filter_scale= ff_w3fdif_scale_sse2;
>  }
>
>  if (ARCH_X86_64 && EXTERNAL_SSE2(cpu_flags)) {
> -dsp->filter_simple_high  = ff_w3fdif_simple_high_sse2;
>  dsp->filter_complex_high = ff_w3fdif_complex_high_sse2;
>  }
>  }
> --
> 2.6.2.windows.1
>

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

Re: [FFmpeg-devel] [PATCH v5] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Mats Peterson]

On 01/08/2016 11:58 AM, Michael Niedermayer wrote:


where can i find a file to test this and the mov patch ?
also codec_id will be AV_CODEC_ID_NONE for any new fourcc that is
not supported not just fourcc == 0
does it work to check fourcc or the place that fourcc is stored
i addition or instead of codec_id ?

[...]



Ah, right, I didn't think of that. It's better to check the fourcc 
directly in the private data, of course. I'll fix that. I'll be back.


Here's one of many older QuickTime files with fourcc 0x, for the 
record:


https://drive.google.com/open?id=0B3_pEBoLs0faSjhuTk5ac0lXX28

Mats

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

Re: [FFmpeg-devel] have some major changes for nvenc support

[Andrey Turkin]

2016-01-08 20:25 GMT+03:00 Michael Niedermayer :

> Also slightly orthogonal but if you have 4 filters each written for a
> different hwaccel you can write a generic filter that passes its
> stuff to the appropriate one
> If theres not much shareale code between hw specific filters then this
> might be cleaner than throwing all hw specifc code in one filter
> directly
>
> such seperate filters could use the existing conditional compilation
> code, could be used directly if the user wants to force a specific
> hw type, ...
>
> So we'd have a default filter and then specific ones just in case anyone
needs them. That is a great idea.
Not sure which way is cleaner - to have proxy filter or to lump everything
together in one filter and add extra filter definitions to force specific
hwaccel. Would work either way.

That I'd looking for in the end, though, is to have more "intelligent"
ffmpeg wrt hardware acceleration. I'd much rather prefer to have it
automagically use hwaccel whether possible, in the optimal way, and not
have to describe every detail.
For example, this thread started because NVidia had a specific scenario and
they had to offload scaling to CUDA - and they had to concoct something
arguably messy to make it happen. There's very specialized filter with many
outputs, and you have to use complex_filter and you have to map filter
outputs to output files etc. It would be awesome if they could just do
ffmpeg -i input -s 1920x1080 -c:v nvenc_h264 hd1080.mp4 -s 1280x720 -c:v
nvenc_h264 hd720.mp4 ..., and it'd do scaling on GPU without explicit
instructions.

In my opinion (which might be totally wrong), it would take 4 changes to
make that happen:
- make ffmpeg use avfilter for scaling - i.e. connect scale filter to
filterchain output (unless it already does)
- add another pixelformat for CUDA, add its support to scale, and add it as
a input format for nvenc_h264
- adjust pixelformat negotiation logic in avfilter to make sure it would
select CUDA pixelformat for scale (maybe just preferring hwaccel formats
over software ones would work?)
- add interop filter to perform CPU-GPU and GPU-CPU data transfer - i.e.
convert between hwaccel and corresponding software formats; avfilter would
insert it in appropriate places when negotiating pixel formats (I think it
does something similar with scale). This might be tricky - e.g. in my
example single interop filter needs to be added and its output has to be
shared between all the scale filters. If, say, there were 2 GPUs used in
encoding then there would have to be 2 interop filters. On the plus side
all existing host->device copying code in encoders can be thrown out (or
rather moved in that filter); as well as existing device->host copying code
from ffmpeg_*.c. Also it would make writing new hwaccel-enable filters
easier.

Actually there is one more thing to do - filters would somehow have to
share hwaccel contexts with their neighbour filters as well as filterchain
inputs and outputs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpx: Support setting color range for vp9.

[Sasi Inguva]

Sorry for the delay on this. Was waiting for
https://chromium-review.googlesource.com/#/c/320116/ to be submitted. Sent
the new patch with decoder changes.

On Mon, Jan 4, 2016 at 12:26 PM, James Almer  wrote:

> On 1/4/2016 5:01 PM, Sasi Inguva wrote:
> > Would it be a lot easier and correct if I just update the
> IMAGE_ABI_VERSION to 4 in libvpx HEAD and check here in the decoder
> IMAGE_ABI_VERSION > 3  ?
>
> Yes, bumping any of the defines would probably be best. It will not apply
> to libvpxdec 1.5.0, though, but i guess it's better than bloating configure
> with checks for specific struct members.
>
> >
> > On Mon, Jan 4, 2016 at 11:03 AM, Ronald S. Bultje  > wrote:
> >
> > Hi,
> >
> > On Mon, Jan 4, 2016 at 1:48 PM, Sasi Inguva  > wrote:
> >
> > > Ping! I could not find any other fields for version other than the
> > > IMAGE_ABI_VERSION , CODEC_ABI_VERSION, DECODER_ABI_VERSION which
> remain
> > > unchanged .
> >
> >
> > So, add a version check? Or check for the existence of the
> appropriate
> > color range field in this struct in our configure script.
> >
> > Ronald
> > ___
> > 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libvpx: Support setting color range for vp9.

[Sasi Inguva]

Pass through color range to vp9 encoder. Parse color range in libvpxdec.c.

Signed-off-by: Sasi Inguva 
---
 libavcodec/libvpxdec.c |  6 ++
 libavcodec/libvpxenc.c | 26 ++
 2 files changed, 32 insertions(+)

diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index 698c546..de72be9 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -69,6 +69,12 @@ static int set_pix_fmt(AVCodecContext *avctx, struct 
vpx_image *img)
 AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED, 
AVCOL_SPC_RGB,
 };
 avctx->colorspace = colorspaces[img->cs];
+#if VPX_IMAGE_ABI_VERSION >= 4
+static const enum AVColorRange color_ranges[] = {
+AVCOL_RANGE_MPEG, AVCOL_RANGE_JPEG
+};
+avctx->color_range = color_ranges[img->range];
+#endif
 #endif
 if (avctx->codec_id == AV_CODEC_ID_VP8 && img->fmt != VPX_IMG_FMT_I420)
 return AVERROR_INVALIDDATA;
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 9cf32bf..ef531d5 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -125,6 +125,9 @@ static const char *const ctlidstr[] = {
 #if VPX_ENCODER_ABI_VERSION > 8
 [VP9E_SET_COLOR_SPACE] = "VP9E_SET_COLOR_SPACE",
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 11
+[VP9E_SET_COLOR_RANGE] = "VP9E_SET_COLOR_RANGE",
+#endif
 #endif
 };
 
@@ -368,6 +371,26 @@ static void set_colorspace(AVCodecContext *avctx)
 codecctl_int(avctx, VP9E_SET_COLOR_SPACE, vpx_cs);
 }
 #endif
+
+#if VPX_ENCODER_ABI_VERSION >= 11
+static void set_color_range(AVCodecContext *avctx)
+{
+enum vpx_color_range vpx_cr;
+switch (avctx->color_range) {
+case AVCOL_RANGE_UNSPECIFIED:
+case AVCOL_RANGE_MPEG:
+vpx_cr = VPX_CR_STUDIO_RANGE; break;
+case AVCOL_RANGE_JPEG:
+vpx_cr = VPX_CR_FULL_RANGE; break;
+default:
+av_log(avctx, AV_LOG_WARNING, "Unsupported color range (%d)\n",
+   avctx->color_range);
+return;
+}
+
+codecctl_int(avctx, VP9E_SET_COLOR_RANGE, vpx_cr);
+}
+#endif
 #endif
 
 static av_cold int vpx_init(AVCodecContext *avctx,
@@ -617,6 +640,9 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 #if VPX_ENCODER_ABI_VERSION > 8
 set_colorspace(avctx);
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 11
+set_color_range(avctx);
+#endif
 }
 #endif
 
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[wm4]

On Fri, 8 Jan 2016 09:42:52 + (UTC)
Carl Eugen Hoyos  wrote:

> wm4  googlemail.com> writes:
> 
> > On Fri, 8 Jan 2016 17:55:38 +1100
> > Jean-Yves Avenard  gmail.com> wrote:
> >   
> > > One of the issues we've faced was with our reftest 
> > > tests, with pages creating hundreds of small video 
> > > elements (the test change orientation, sizes, 
> > > transparency and the like and check that there's
> > > no regression on how things are displayed).  
> > 
> > Do I understand right that only your tests do this?  
> 
> I may have misunderstood myself but I believe the 
> issue actually only happens on Windows XP;-)

I suppose the larger memory usage would be considered a problem too,
and also can hit 32 bit boundaries even on non-XP.

Anyway, as another point I would argue:
- discouraging web devs from creating too many video elements, and
  introducing a static "reasonable" limit (maybe a dozen elements)
- not using MT for very small video (MT would probably make it slower
  anyway)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/libvpxenc: Improve documentation for cpu-used

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #5140 here, seems to match:
https://github.com/webmproject/libvpx/commit/a16f07537501ac96531577d5af004ad0b591a705

Please comment, Carl Eugen
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 9cf32bf..3740bdd 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -962,7 +962,6 @@ static int vp8_encode(AVCodecContext *avctx, AVPacket *pkt,
 #endif
 
 #define COMMON_OPTIONS \
-{ "cpu-used","Quality/Speed ratio modifier",   OFFSET(cpu_used),AV_OPT_TYPE_INT, {.i64 = 1},   -16, 16,  VE}, \
 { "auto-alt-ref","Enable use of alternate reference " \
  "frames (2-pass only)",   OFFSET(auto_alt_ref),AV_OPT_TYPE_BOOL, {.i64 = -1}, -1,  1,   VE}, \
 { "lag-in-frames",   "Number of frames to look ahead for " \
@@ -1003,6 +1002,7 @@ static int vp8_encode(AVCodecContext *avctx, AVPacket *pkt,
 #if CONFIG_LIBVPX_VP8_ENCODER
 static const AVOption vp8_options[] = {
 COMMON_OPTIONS
+{ "cpu-used","Quality/Speed ratio modifier",   OFFSET(cpu_used),AV_OPT_TYPE_INT, {.i64 = 1},   -16, 16,  VE},
 LEGACY_OPTIONS
 { NULL }
 };
@@ -1011,6 +1011,7 @@ static const AVOption vp8_options[] = {
 #if CONFIG_LIBVPX_VP9_ENCODER
 static const AVOption vp9_options[] = {
 COMMON_OPTIONS
+{ "cpu-used","Quality/Speed ratio modifier",   OFFSET(cpu_used),AV_OPT_TYPE_INT, {.i64 = 1},   -8, 8,  VE},
 { "lossless","Lossless mode",   OFFSET(lossless),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
 { "tile-columns","Number of tile columns to use, log2", OFFSET(tile_columns),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
 { "tile-rows",   "Number of tile rows to use, log2",OFFSET(tile_rows),   AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE},
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: check fclose return values

[wm4]

On Thu, 7 Jan 2016 16:01:14 -0800
Ganesh Ajjanagadde  wrote:

> On Thu, Jan 7, 2016 at 3:57 PM, Ganesh Ajjanagadde  wrote:
> > On Thu, Jan 7, 2016 at 2:18 PM, Michael Niedermayer
> >  wrote:  
> >> On Thu, Jan 07, 2016 at 11:16:27PM +0100, Michael Niedermayer wrote:  
> >>> On Thu, Jan 07, 2016 at 10:00:47AM -0800, Ganesh Ajjanagadde wrote:  
> >>> > On Thu, Jan 7, 2016 at 9:27 AM, Michael Niedermayer
> >>> >  wrote:  
> >>> > > On Wed, Jan 06, 2016 at 09:00:46PM -0800, Ganesh Ajjanagadde wrote:  
> >>> > >> In the spirit of commit a956840cbc. Simple method to reproduce:
> >>> > >> pass -vstats_file /dev/full to ffmpeg.
> >>> > >>
> >>> > >> All raw fclose usages in ffmpeg.c taken care of here.
> >>> > >>
> >>> > >> Signed-off-by: Ganesh Ajjanagadde 
> >>> > >> ---
> >>> > >>  ffmpeg.c | 13 ++---
> >>> > >>  1 file changed, 10 insertions(+), 3 deletions(-)  
> >>> > >
> >>> > > LGTM
> >>> > >
> >>> > > thanks  
> >>> >
> >>> > So there is actually a problem with the diagnostic obtained, a more
> >>> > accurate diagnostic is via errno, say strerror(errno) instead of
> >>> > av_err2str(ret).
> >>> > Comparison:
> >>> > Error closing vstats file, loss of information possible: Operation not 
> >>> > permitted
> >>> > vs
> >>> > Error closing vstats file, loss of information possible: No space left 
> >>> > on device
> >>> > for the provided /dev/full example.
> >>> >
> >>> > So there are a number of possiblities:
> >>> > 1. Have 2 separate av_log lines, one for each of these.
> >>> > 2. A single av_log line, using strerror(errno).
> >>> > 3. Leave as is.
> >>> >
> >>> > I prefer 2. Let me know your preference, and I will push later.  
> >>>
> >>> yes agree, 2.  
> >>
> >> probably should use av_err2str() instead of strerror() though  
> >
> > I thought strerror was C89? Your idea unfortunately causes problems
> > (suspect it is because appropriate error tag is missing):
> > Error closing vstats file, loss of information possible: Error number
> > 28 occurred.  
> 
> Did some digging, using strerror should be fine, see 984-989 of
> cmdutils.c for very similar usage.

strerror() is not thread-safe. There is absolutely no reason for it not
to be thread-safe, but C is full of idiocy like this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 03/10] libavcodec/ccaption_dec: add calculate_duration option

[Anshul Maheshwari]

On Fri, Jan 8, 2016 at 3:51 PM, Anshul Maheshwari 
wrote:

>
>
> On Thu, Jan 7, 2016 at 6:10 AM, Aman Gupta  wrote:
>
> > Aman Gupta  wrote:
>> > > --- a/libavcodec/ccaption_dec.c
>> > > +++ b/libavcodec/ccaption_dec.c
>> > > @@ -150,6 +150,7 @@ struct Screen {
>> > >
>> > >  typedef struct CCaptionSubContext {
>> > >  AVClass *class;
>> > > +int calculate_duration;
>> > >  struct Screen screen[2];
>> > >  int active_screen;
>> > >  uint8_t cursor_row;
>> > > @@ -545,8 +546,12 @@ static int decode(AVCodecContext *avctx, void
>> > *data, int *got_sub, AVPacket *avp
>> > >  continue;
>> > >  else
>> > >  process_cc608(ctx, *(bptr + i + 1) & 0x7f, *(bptr + i +
>> 2)
>> > & 0x7f);
>> > > -if (ctx->screen_changed)
>> > > -{
>> > > +
>> > > +if (!ctx->screen_changed)
>> > > +continue;
>> > > +ctx->screen_changed = 0;
>> > > +
>> > > +if (ctx->calculate_duration) {
>> > >  if (ctx->prev_string) {
>> > >  int start_time = av_rescale_q(ctx->prev_time,
>> > avctx->time_base, (AVRational){ 1, 100 });
>> > >  int end_time = av_rescale_q(avpkt->pts,
>> > avctx->time_base, (AVRational){ 1, 100 });
>> > > @@ -560,7 +565,12 @@ static int decode(AVCodecContext *avctx, void
>> > *data, int *got_sub, AVPacket *avp
>> > >  av_bprintf(>buffer, "\r\n");
>> > >  ctx->prev_string = av_strdup(ctx->buffer.str);
>> > >  ctx->prev_time = avpkt->pts;
>> > > -ctx->screen_changed = 0;
>> > > +} else {
>> > > +int start_time = av_rescale_q(avpkt->pts,
>> avctx->time_base,
>> > (AVRational){ 1, 100 });
>> > > +ret = ff_ass_add_rect_bprint(sub, >buffer,
>> start_time,
>> > -1);
>>
> Is it possible to check the length of buffer, and avoid empty frames.
>

No need, I did understood that they are needed.

>
> > > +if (ret < 0)
>> > > +return ret;
>> > > +sub->pts = av_rescale_q(avpkt->pts, avctx->time_base,
>> > AV_TIME_BASE_Q);
>> > >  }
>> > >  }
>> > >
>> > > @@ -568,7 +578,10 @@ static int decode(AVCodecContext *avctx, void
>> > *data, int *got_sub, AVPacket *avp
>> > >  return ret;
>> > >  }
>> > >
>> > > +#define OFFSET(x) offsetof(CCaptionSubContext, x)
>> > > +#define SD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
>> > >  static const AVOption options[] = {
>> > > +{ "calculate_duration", "Buffer closed captions to calculate
>> > durations.", OFFSET(calculate_duration), AV_OPT_TYPE_BOOL, { .i64 = 1
>> }, 0,
>> > 1, SD },
>> > >  {NULL}
>> > >  };
>> > >
>> >
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Andrey Turkin]

2016-01-08 12:42 GMT+03:00 Carl Eugen Hoyos :

>
> I may have misunderstood myself but I believe the
> issue actually only happens on Windows XP;-)
>
>
I've encountered this issue a while back when trying to do about 20
simultaneous transcodings with some video filters. It was on a high-end CPU
with a lot of cores so every codec and MT-enabled video filter would spawn
a lot of threads - can't remember exact number but hundreds of them. The
threads' stacks would eat up all of the process' address space causing OOM.
It was on Windows 7, and it's something you probably can call real-world
example. I ended up disabling MT everywhere I can to fix that (which was a
right thing to do anyway since my program was already multithreaded and it
could use all the cores anyway). This thread-pool idea sounds reasonable to
me; more reasonable than 8-16 threads per codec anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Carl Eugen Hoyos]

wm4  googlemail.com> writes:

> On Fri, 8 Jan 2016 17:55:38 +1100
> Jean-Yves Avenard  gmail.com> wrote:
> 
> > One of the issues we've faced was with our reftest 
> > tests, with pages creating hundreds of small video 
> > elements (the test change orientation, sizes, 
> > transparency and the like and check that there's
> > no regression on how things are displayed).
> 
> Do I understand right that only your tests do this?

I may have misunderstood myself but I believe the 
issue actually only happens on Windows XP;-)

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 03/10] libavcodec/ccaption_dec: add calculate_duration option

[Anshul Maheshwari]

On Thu, Jan 7, 2016 at 6:10 AM, Aman Gupta  wrote:

> > Aman Gupta  wrote:
> > > --- a/libavcodec/ccaption_dec.c
> > > +++ b/libavcodec/ccaption_dec.c
> > > @@ -150,6 +150,7 @@ struct Screen {
> > >
> > >  typedef struct CCaptionSubContext {
> > >  AVClass *class;
> > > +int calculate_duration;
> > >  struct Screen screen[2];
> > >  int active_screen;
> > >  uint8_t cursor_row;
> > > @@ -545,8 +546,12 @@ static int decode(AVCodecContext *avctx, void
> > *data, int *got_sub, AVPacket *avp
> > >  continue;
> > >  else
> > >  process_cc608(ctx, *(bptr + i + 1) & 0x7f, *(bptr + i + 2)
> > & 0x7f);
> > > -if (ctx->screen_changed)
> > > -{
> > > +
> > > +if (!ctx->screen_changed)
> > > +continue;
> > > +ctx->screen_changed = 0;
> > > +
> > > +if (ctx->calculate_duration) {
> > >  if (ctx->prev_string) {
> > >  int start_time = av_rescale_q(ctx->prev_time,
> > avctx->time_base, (AVRational){ 1, 100 });
> > >  int end_time = av_rescale_q(avpkt->pts,
> > avctx->time_base, (AVRational){ 1, 100 });
> > > @@ -560,7 +565,12 @@ static int decode(AVCodecContext *avctx, void
> > *data, int *got_sub, AVPacket *avp
> > >  av_bprintf(>buffer, "\r\n");
> > >  ctx->prev_string = av_strdup(ctx->buffer.str);
> > >  ctx->prev_time = avpkt->pts;
> > > -ctx->screen_changed = 0;
> > > +} else {
> > > +int start_time = av_rescale_q(avpkt->pts,
> avctx->time_base,
> > (AVRational){ 1, 100 });
> > > +ret = ff_ass_add_rect_bprint(sub, >buffer,
> start_time,
> > -1);
>
Is it possible to check the length of buffer, and avoid empty frames.

> > > +if (ret < 0)
> > > +return ret;
> > > +sub->pts = av_rescale_q(avpkt->pts, avctx->time_base,
> > AV_TIME_BASE_Q);
> > >  }
> > >  }
> > >
> > > @@ -568,7 +578,10 @@ static int decode(AVCodecContext *avctx, void
> > *data, int *got_sub, AVPacket *avp
> > >  return ret;
> > >  }
> > >
> > > +#define OFFSET(x) offsetof(CCaptionSubContext, x)
> > > +#define SD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
> > >  static const AVOption options[] = {
> > > +{ "calculate_duration", "Buffer closed captions to calculate
> > durations.", OFFSET(calculate_duration), AV_OPT_TYPE_BOOL, { .i64 = 1 },
> 0,
> > 1, SD },
> > >  {NULL}
> > >  };
> > >
> >
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/ccaption_dec: remove unnecessary buffering of closed caption packets

[Clément Bœsch]

On Fri, Jan 08, 2016 at 05:24:15PM +0530, Anshul wrote:
> 
> 
> On 6 January 2016 1:55:27 am IST, "Clément Bœsch"  wrote:
> >On Sun, Jan 03, 2016 at 01:07:15PM +0100, Clément Bœsch wrote:
> >[...]
> >> This indeed LGTM, but I'm not the maintainer.
> >> 
> >
> >OK I finally understood why it's done that way: validate_cc_data_pair()
> >alters the pkt data, but the decoder isn't supposed to do that.
> >
> >So this patch is actually incorrect in this state.
> 
> 
> I did not knew, what could be the disadvantage of changing pkt data, I
> changed it to save some CPU cycles.

The packet is considered read-only for the decoder. It appears not to be
marked as const for whatever bad reason.

But what CPU cycles would you be saving anyway here? I don't see what
operation you are saving.

[...]

-- 
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] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 23:27, wm4  wrote:
> Then don't create 30 threads.

This was just a silly example...

There are time when you do want to use multiple threads, because
someone is playing a single high-def video and a single thread
wouldn't cut it.
The conditions could change dynamically too:
Say you had a thread pool of 8 threads ; when you have a single video
to play, it can make full use of the processor. Something you can't
achieve if you didn't create any threads at all.

Now create a new decoder, they are still sharing the same pool, so about 4 each.

The point is that as your amount of decoders climb there aren't an
negative effect as opposed to not creating new thread, while when the
decoder count drops: improvements do kick in.

The advantages are so many that I'm even surprised I have to mention
it... It's so obvious.

Thread pools / task queues aren't messy. It's the modern approach
taken by almost all highly parallelised and efficient applications.

We certainly use them a lot in gecko (and webkit too)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[wm4]

On Fri, 8 Jan 2016 23:28:20 +1100
Jean-Yves Avenard  wrote:

> On 8 January 2016 at 23:24, wm4  wrote:
> >
> > A global thread pool sounds like an extremely messy and unclean
> > solution. The state of a library is not supposed to affect anything
> > else in the same process.  
> 
> The point of my message was to start a discussion, not to receive
> immediate answer ridiculing the idea and I have to say by someone who

Sorry, the problem you're trying to solve is just too ridiculous.
Threads might be the heaviest resource here, but no matter what you do,
having hundreds of objects active at the same time (bring back geocity
websites from the 90ies?) will cause a memory and CPU resource usage
problem. So what if it fails on Windows XP.

> clearly haven't done much work on highly parallelised application, and
> who fail to even consider the problem.

Maybe you're trying to argue from some sort of theoretical point of
view, but I'm thinking about practical issues, such as managing a
global thread pool. Regardless of "parallisation", for the problem at
this is also an overcomplicated and inefficient solution. Plus I didn't
even completely reject the idea of having some sort of thread pool.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] lavf/mov: Audio and fourcc 0x00000000

[Michael Niedermayer]

On Fri, Jan 08, 2016 at 01:03:58PM +0100, Mats Peterson wrote:
> In many older QuickTime files, the audio format, or "fourcc", is
> 0x. The QuickTime File Format Specification states the following
> regarding this situation:
> 
> "This format descriptor should not be used, but may be found in some
> files. Samples are assumed to be stored in either 'raw ' or 'twos'
> format, depending on the sample size field in the sound description."
> 
> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
> not.
> 
> Mats
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  mov.c |   16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> d5836fe68cf50aa82653253f0ffc3f345d1c066b  
> 0001-lavf-mov-Audio-and-fourcc-0x.patch
> From 640e12e8450a630f1569009094ac1bd51d8cfebf Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Fri, 8 Jan 2016 12:59:13 +0100
> Subject: [PATCH v3] lavf/mov: Audio and fourcc 0x
> 
> In many older QuickTime files, the audio format, or "fourcc", is
> 0x. The QuickTime File Format Specification states the following
> regarding this situation:
> 
> "This format descriptor should not be used, but may be found in some
> files. Samples are assumed to be stored in either 'raw ' or 'twos'
> format, depending on the sample size field in the sound description."
> 
> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
> not.
> 
> Mats
> 
> ---
>  libavformat/mov.c |   16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)

applied

simplified a bit

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Derek Buitenhuis]

On 1/8/2016 2:19 PM, Jean-Yves Avenard wrote:
> I will come on Monday if that's okay... could setup a time that works
> for you. I'm based in Melbourne Australia

Most of the channel is usually around during daytime GMT/CET hours.

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

Re: [FFmpeg-devel] have some major changes for nvenc support

[Andrey Turkin]

In my opinion this proliferation of various filters which do the same thing
in different way is a configuration headache. There's CPU filters: one for
scaling/format conversion, one for padding, one  for cropping, like 5
different filters for deinterlacing. And now there would be nvresize for
scaling, and we gotta add CUDA-based nvpad and nvdeint if we want to do
some transcoding. Maybe add overlaying too - so nvoverlay. Then there is
OpenCL which can do everything - so 4 more filters for that. And there is
quicksync which I think can do those things, so there would be qsvscale and
qsvdeint. And there is D3D11 video processor which can do those things too
(simultaneously in fact), so there's gotta be
d3d11vascaledeintpadcropoverlay. And then we've got a whole bunch of video
filters which can only do their job on a specific hwaccel platform. Want to
try different hwaccel? Rewrite damn filter string. Want to do something
generic that can be used over different platforms? Can't be done.
Maybe it's just my wishful thinking, but I was wondering for some time if
there can be one "smart" filter to do one specific thing? Say, single
deinterlace filter which can automatically use whichever hwaccel was used
on its input (or whichever will be used on its output)? We've already got
pixel formats which describe particular hwaccel - can't filters decide
which code path to use based on that? And it can have a configuration
option to choose which CPU-based fallback to use (in fact that option can
be used to tweak GPU-based algorithm for platforms which support it).
Same goes for encoders - can't there be "just" h264 encoder? This one's
tough though - you might have dxva decoder, cuda filters and nvenc encoder
and you probably want to keep them all on the same GPU. Or not - maybe you
do want to decode on qsv and encode on nvenc, or maybe vice versa. Probably
single-GPU case is more common so it should try to use same GPU what was
used for decoding and/or filtering, and allow to override with encoder
options (like nvenc allows to specify cuda device to use).
Interop will be a pain though (obviously we'd want to avoid device-host
frame transfers). I'm trying to share d3d11va-decoded frames (nv12 texture)
with OpenCL or CUDA right now,and I've been at it for days with no luck
whatsoever. My last resort now is to write a shader to "draw" (in fact just
copy pixels around) nv12 texture onto another texture in more "common"
format which can be used by OpenCL... There's got to be some easier way
(other than using cuvid to decode  the video), right?

Regards, Andrey

2016-01-08 11:29 GMT+03:00 Roger Pack :

> On 11/5/15, wm4  wrote:
> > On Thu, 5 Nov 2015 16:23:04 +0800
> > Agatha Hu  wrote:
> >
> >> 2) We use AVFrame::opaque field to store a customized ffnvinfo struture
> >> to prevent expensive CPU<->GPU transferration. Without it, the workflow
> >> will be like CPU AVFrame input-->copy to GPU-->do CUDA resizing-->copy
> >> to CPU AVFrame-->copy to GPU-->NVENC encoding. And now it becomes:
> >> CPU AVFrame input-->copy to GPU-->do CUDA resizing-->NVENC encoding.
> >> Our strategy is to check whether AVFrame::opaque is not null AND its
> >> first 128 bytes matches some particular GUID. If so, AVFrame::opaque is
> >> a valid ffnvinfo struture and we read GPU address directly from it
> >> instead of copying data from AVFrame.
> >
> > Please no, not another hack that makes the hw decoding API situation
> > worse. Do this properly and coordinate with Gwenole Beauchesne, who
> > plans improvements into this direction.
>
> Which part are you referring to (though I'll admit putting some stuff
> in libavutil seems a bit suspect).
> It would be nice to have the nvresize filter available anyway, and it
> looks like it mostly just deals with private context variables.
> Cheers!
> -roger-
> ___
> 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 v6] lavf/matroskadec: A_QUICKTIME and fourcc 0x00000000

[Mats Peterson]

In many older QuickTime files, the audio format, or "fourcc", is
0x. The QuickTime File Format Specification states the following
regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From d8507d9b0645585d2d27c614f1f7d3347edf8733 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 8 Jan 2016 12:55:59 +0100
Subject: [PATCH v6] lavf/matroskadec: A_QUICKTIME and fourcc 0x

In many older QuickTime files, the audio format, or "fourcc", is
0x. The QuickTime File Format Specification states the following
regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

---
 libavformat/matroskadec.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 9de7cfb..ea68c6a 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1869,6 +1869,15 @@ static int matroska_parse_tracks(AVFormatContext *s)
 fourcc = AV_RL32(track->codec_priv.data);
 codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
 }
+if (fourcc == 0) {
+if (track->audio.bitdepth == 8) {
+fourcc = MKTAG('r','a','w',' ');
+codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
+} else if (track->audio.bitdepth == 16) {
+fourcc = MKTAG('t','w','o','s');
+codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
+}
+}
 } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
(track->codec_priv.size >= 21)  &&
(track->codec_priv.data)) {
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH v3] lavf/mov: Audio and fourcc 0x00000000

[Mats Peterson]

In many older QuickTime files, the audio format, or "fourcc", is
0x. The QuickTime File Format Specification states the following
regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 640e12e8450a630f1569009094ac1bd51d8cfebf Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 8 Jan 2016 12:59:13 +0100
Subject: [PATCH v3] lavf/mov: Audio and fourcc 0x

In many older QuickTime files, the audio format, or "fourcc", is
0x. The QuickTime File Format Specification states the following
regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

---
 libavformat/mov.c |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 78081ce..f6462f7 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1812,9 +1812,16 @@ static void mov_parse_stsd_audio(MOVContext *c, AVIOContext *pb,
  AVStream *st, MOVStreamContext *sc)
 {
 int bits_per_sample, flags;
-uint16_t version = avio_rb16(pb);
+uint32_t format;
+uint16_t version;
 AVDictionaryEntry *compatible_brands = av_dict_get(c->fc->metadata, "compatible_brands", NULL, AV_DICT_MATCH_CASE);
 
+avio_seek(pb, -12, SEEK_CUR);
+format = avio_rb32(pb);
+avio_seek(pb, 8, SEEK_CUR);
+
+version = avio_rb16(pb);
+
 avio_rb16(pb); /* revision level */
 avio_rb32(pb); /* vendor */
 
@@ -1863,6 +1870,13 @@ static void mov_parse_stsd_audio(MOVContext *c, AVIOContext *pb,
 }
 }
 
+if (format == 0) {
+if (st->codec->bits_per_coded_sample == 8)
+st->codec->codec_id = mov_codec_id(st, MKTAG('r','a','w',' '));
+else if (st->codec->bits_per_coded_sample == 16)
+st->codec->codec_id = mov_codec_id(st, MKTAG('t','w','o','s'));
+}
+
 switch (st->codec->codec_id) {
 case AV_CODEC_ID_PCM_S8:
 case AV_CODEC_ID_PCM_U8:
-- 
1.7.10.4

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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 20:42, Carl Eugen Hoyos  wrote:
> I may have misunderstood myself but I believe the
> issue actually only happens on Windows XP;-)
>
> Carl Eugen

Well the issue is mostly important on 32 bits system, particularly on
windows where a user process can only use up to 2GB of RAM.

But regardless of the OS or platform. Potentially having to create
thousands of threads because you have lots of videos is a problem.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[wm4]

On Fri, 8 Jan 2016 23:15:11 +1100
Jean-Yves Avenard  wrote:

> On 8 January 2016 at 20:28, wm4  wrote:
> > Do I understand right that only your tests do this? And that there are
> > no real world sites which do this? And that you want us to change our
> > architecture so that your tests actually run?  
> 
> I thought I had explained the problem in rather plain words easy to
> understand. But obviously not :)

You did, but obviously I failed to express myself clearly.

> In FFmpeg, the default when you create a decoder is to create for
> *that* decoder as many threads as there are core.
> So on a quad-core machine, with hyper threading: that makes 8 threads.
> 
> So create two decoders: 16 threads. 3 decoders: 24 threads..
> 
> I can understand that the most common use of ffmpeg is to display
> *one* video at a given time. I so wish it was that easy.

All libavcodec decoders can be used in single threaded mode. That means
it will run on your own thread, and libavcodec will not create extra
threads.

> Now, as a web browser, our use is rather nowhere as simple. Their
> could be hundreds of videos. You find web site setting a video to play
> in the background that does nothing but change colours and give an
> ambiance.
> 
> And then you have dozens of animated icons: all made using simple
> video elements. Those web sites are found in the wild, it's not just
> an internal test page. Actually our tests are typically based on
> things actually found. Because noone is as good as a web developer to
> break things :)
> 
> So yes, the current threading architecture of ffmpeg is inadequate for
> our use. But it's not just *our* use. And as such, I wish we could
> make it better.
> 
> The use of global thread pool is a sane (and much better) approach regardless.

A global thread pool sounds like an extremely messy and unclean
solution. The state of a library is not supposed to affect anything
else in the same process.

Maybe one could expose thread pools as explicit API objects, and pass
them explicitly to each decoder.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/concatdec: do not access packet if av_read_frame returned error

[Nicolas George]

Le decadi 10 nivôse, an CCXXIV, Marton Balint a écrit :
> Signed-off-by: Marton Balint 
> ---
>  libavformat/concatdec.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 

LGTM, thanks, and sorry to have forgotten.

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 v6] lavf/matroskadec: A_QUICKTIME and fourcc 0x00000000

[Moritz Barsnick]

On Fri, Jan 08, 2016 at 14:51:53 +0100, Mats Peterson wrote:
> I can't see the applied patches at GitHub yet. Is a delay normal? Sorry 
> for a stupid question.

Yes, that is normal. videolan.org hosts the "original".

There was an explanation in this thread:
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180844.html

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

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[foo86]

On Thu, Jan 07, 2016 at 03:32:50PM +0100, Christophe Gisquet wrote:
> One commit implements "sum/diff decoding", introducing sumdiff_X
> functions, with X fixed or float.
> 
> I think those are the corresponding butterflies_X functions in the
> AV(Float|Fixed)DSPContext structures. But I haven't verified the
> alignment requirements.

Seems to be it, thanks for your suggestion. Changed the floating point
code to use butterflies_float. Core decoder doesn't use
AVFixedDSPContext currently, so I left an ad-hoc fixed point approach.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[James Almer]

On 1/8/2016 11:22 AM, compn wrote:
> does this also happen with webp ? e.g. if all images are vp8 webp and if
> you used libavcodec to decode them?

Firefox doesn't (yet) support webp. There's a very old bugzilla ticket
about it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 20:28, wm4  wrote:
> Do I understand right that only your tests do this? And that there are
> no real world sites which do this? And that you want us to change our
> architecture so that your tests actually run?

I thought I had explained the problem in rather plain words easy to
understand. But obviously not :)

In FFmpeg, the default when you create a decoder is to create for
*that* decoder as many threads as there are core.
So on a quad-core machine, with hyper threading: that makes 8 threads.

So create two decoders: 16 threads. 3 decoders: 24 threads..

I can understand that the most common use of ffmpeg is to display
*one* video at a given time. I so wish it was that easy.

Now, as a web browser, our use is rather nowhere as simple. Their
could be hundreds of videos. You find web site setting a video to play
in the background that does nothing but change colours and give an
ambiance.

And then you have dozens of animated icons: all made using simple
video elements. Those web sites are found in the wild, it's not just
an internal test page. Actually our tests are typically based on
things actually found. Because noone is as good as a web developer to
break things :)

So yes, the current threading architecture of ffmpeg is inadequate for
our use. But it's not just *our* use. And as such, I wish we could
make it better.

The use of global thread pool is a sane (and much better) approach regardless.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 23:24, wm4  wrote:
>
> A global thread pool sounds like an extremely messy and unclean
> solution. The state of a library is not supposed to affect anything
> else in the same process.

The point of my message was to start a discussion, not to receive
immediate answer ridiculing the idea and I have to say by someone who
clearly haven't done much work on highly parallelised application, and
who fail to even consider the problem.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6] lavf/matroskadec: A_QUICKTIME and fourcc 0x00000000

[Michael Niedermayer]

On Fri, Jan 08, 2016 at 01:03:05PM +0100, Mats Peterson wrote:
> In many older QuickTime files, the audio format, or "fourcc", is
> 0x. The QuickTime File Format Specification states the following
> regarding this situation:
> 
> "This format descriptor should not be used, but may be found in some
> files. Samples are assumed to be stored in either 'raw ' or 'twos'
> format, depending on the sample size field in the sound description."
> 
> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
> not.
> 
> Mats
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  matroskadec.c |9 +
>  1 file changed, 9 insertions(+)
> 7a07b5c37987840d43a2710c854316bb31c1  
> 0001-lavf-matroskadec-A_QUICKTIME-and-fourcc-0x.patch
> From d8507d9b0645585d2d27c614f1f7d3347edf8733 Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Fri, 8 Jan 2016 12:55:59 +0100
> Subject: [PATCH v6] lavf/matroskadec: A_QUICKTIME and fourcc 0x
> 
> In many older QuickTime files, the audio format, or "fourcc", is
> 0x. The QuickTime File Format Specification states the following
> regarding this situation:
> 
> "This format descriptor should not be used, but may be found in some
> files. Samples are assumed to be stored in either 'raw ' or 'twos'
> format, depending on the sample size field in the sound description."
> 
> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
> not.
> 
> Mats
> 
> ---
>  libavformat/matroskadec.c |9 +
>  1 file changed, 9 insertions(+)

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please


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

Re: [FFmpeg-devel] [PATCH] -cmdline_from_file new paramter

[Nicolas George]

Le septidi 17 nivôse, an CCXXIV, Procontrol Robert Kovacs a écrit :
> ---
>  cmdutils.c   | 186 
> +++
>  doc/fftools-common-opts.texi |  41 ++
>  2 files changed, 227 insertions(+)

I do not think that FFmpeg needs another shell-like parser with its own
variants of escaping rules and its own limitations. This is the task of a
shell, and shells do that very well, much better than this.

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/2] lavf/concatdec: add outpoint_interleave_delay option

[Nicolas George]

Le decadi 10 nivôse, an CCXXIV, Marton Balint a écrit :
> Wait at most outpoint_interleave_delay at outpoint before considering it an
> end of file condition.
> 
> Signed-off-by: Marton Balint 
> ---
>  doc/demuxers.texi   | 20 
>  libavformat/concatdec.c | 13 ++---
>  2 files changed, 26 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index fb1e4fb..b178195 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -137,8 +137,7 @@ may overlap between two concatenated files.
>  
>  @item @code{outpoint @var{timestamp}}
>  Out point of the file. When the demuxer reaches the specified decoding
> -timestamp in any of the streams, it handles it as an end of file condition 
> and
> -skips the current and all the remaining packets from all streams.
> +timestamp it drops the current and all the remaining packets in the stream.
>  
>  Out point is exclusive, which means that the demuxer will not output packets
>  with a decoding timestamp greater or equal to Out point.
> @@ -148,12 +147,25 @@ are tightly interleaved. For non-intra frame codecs you 
> will usually get
>  additional packets with presentation timestamp after Out point therefore the
>  decoded content will most likely contain frames after Out point too. If your
>  streams are not tightly interleaved you may not get all the packets from all
> -streams before Out point and you may only will be able to decode the earliest
> -stream until Out point.
> +streams before Out point, see @code{outpoint_interleave_delay}.
>  
>  The duration of the files (if not specified by the @code{duration}
>  directive) will be reduced based on their specified Out point.
>  
> +@item @code{outpoint_interleave_delay @var{dur}}
> +With this directive you can specify how long the demuxer should wait before 
> it
> +assumes that packets with timestamps before outpoint have appeared form all
> +streams, so there is no need to read the remaining packets from the input.
> +
> +If an Out point is specified and a packet timestamp is greater or equal to
> +@code{outpoint} plus the specified @code{outpoint_interleave_delay} in any of
> +the streams, the demuxer handles it as an end of file condition and skips the
> +current and all the remaining packets from all streams.
> +
> +The default value is 0. If your streams are not tightly interleaved, you 
> should
> +increase this, otherwise you will only be able to decode the earliest stream
> +until Out point.
> +
>  @item @code{file_packet_metadata @var{key=value}}
>  Metadata of the packets of the file. The specified metadata will be set for
>  each file packet. You can specify this directive multiple times to add 
> multiple
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index d226e15..afa822d 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -48,6 +48,7 @@ typedef struct {
>  int64_t inpoint;
>  int64_t outpoint;
>  AVDictionary *metadata;
> +int64_t outpoint_interleave_delay;
>  int nb_streams;
>  } ConcatFile;
>  
> @@ -378,7 +379,7 @@ static int concat_read_header(AVFormatContext *avf)
>  }
>  if ((ret = add_file(avf, filename, , _files_alloc)) < 0)
>  goto fail;
> -} else if (!strcmp(keyword, "duration") || !strcmp(keyword, 
> "inpoint") || !strcmp(keyword, "outpoint")) {
> +} else if (!strcmp(keyword, "duration") || !strcmp(keyword, 
> "inpoint") || !strcmp(keyword, "outpoint") || !strcmp(keyword, 
> "outpoint_interleave_delay")) {
>  char *dur_str = get_keyword();
>  int64_t dur;
>  if (!file) {
> @@ -397,6 +398,8 @@ static int concat_read_header(AVFormatContext *avf)
>  file->inpoint = dur;
>  else if (!strcmp(keyword, "outpoint"))
>  file->outpoint = dur;
> +else if (!strcmp(keyword, "outpoint_interleave_delay"))
> +file->outpoint_interleave_delay = dur;
>  } else if (!strcmp(keyword, "file_packet_metadata")) {
>  char *metadata;
>  if (!file) {
> @@ -567,9 +570,13 @@ static int concat_read_packet(AVFormatContext *avf, 
> AVPacket *pkt)
>  return ret;
>  }
>  if (packet_after_outpoint(cat, pkt)) {

> +int after_max_delay = av_compare_ts(pkt->dts, 
> cat->avf->streams[pkt->stream_index]->time_base,
> +cat->cur_file->outpoint + 
> cat->cur_file->outpoint_interleave_delay, AV_TIME_BASE_Q) >= 0;

I suggest to pre-compute cat->cur_file->outpoint +
cat->cur_file->outpoint_interleave_delay.

>  av_packet_unref(pkt);
> -if ((ret = open_next_file(avf)) < 0)
> -return ret;
> +if (after_max_delay) {
> +if ((ret = open_next_file(avf)) < 0)
> +return ret;
> +}

Unless I am mistaken, this logic will wait 

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Eli Kara]

Web applications are fast becoming more and more complex, it's no surprise. I 
do mainly sever side work but a bit client side. The amount of data in a web 
page's DOM can be huge.
Many applications use videos in several places, this isn't a theoretical 
problem. And with people having 30 tabs open this really adds up.

The demand for more complicated applications is getting larger as well, fast.
Let web devs fine tune their pages if they're too bloated or inefficient but 
the browser should be able to make the most out of the HW in a smart way, so 
threading should be controllable.

Threading should be determined by the client code. There should be an API to 
determine how many threads to use for a decoder or allow a thread pool with 
tasks for heavy intensive pages.

There's no doubt this is needed, it's just a question of how to introduce such 
an API in a smart way.

Sent from Eli's Nexus

On Jan 8, 2016 4:23 PM, compn  wrote:
On Fri, 8 Jan 2016 10:51:39 +0100
wm4  wrote:

> On Fri, 8 Jan 2016 09:42:52 + (UTC)
> Carl Eugen Hoyos  wrote:
>
> > wm4  googlemail.com> writes:
> >
> > > On Fri, 8 Jan 2016 17:55:38 +1100
> > > Jean-Yves Avenard  gmail.com> wrote:
> > >
> > > > One of the issues we've faced was with our reftest
> > > > tests, with pages creating hundreds of small video
> > > > elements (the test change orientation, sizes,
> > > > transparency and the like and check that there's
> > > > no regression on how things are displayed).
> > >
> > > Do I understand right that only your tests do this?
> >
> > I may have misunderstood myself but I believe the
> > issue actually only happens on Windows XP;-)
>
> I suppose the larger memory usage would be considered a problem too,
> and also can hit 32 bit boundaries even on non-XP.
>
> Anyway, as another point I would argue:
> - discouraging web devs from creating too many video elements, and

i think mozilla should share one test page with the hundred elements so
that we can see first hand the destruction.

does this also happen with webp ? e.g. if all images are vp8 webp and if
you used libavcodec to decode them?

because 100 images would be a real world test, and it would explain why
this is needed.

i've seen html pages with 100 videos, thats just a forum with a music
thread where people post youtube music videos. set forum to display 100
posts at a time and thats easily 100 video elements on one page,
although of course not playing at the same time.

free file hosting / porn websites also utilize multiple video ads at
the same time. easily using 16 video elements at the same time. i've
seen many websites slow the web browser down to nothing with flash
video (which is why i do not use firefox on many sites).

asking web developers to not show so many video ads is a bit
shortsighted imo.

-compn
___
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] Discussion related to the use of a global thread pool rather than the current threading model

[Michael Niedermayer]

On Fri, Jan 08, 2016 at 01:35:02PM +0300, Andrey Turkin wrote:
> 2016-01-08 12:42 GMT+03:00 Carl Eugen Hoyos :
> 
> >
> > I may have misunderstood myself but I believe the
> > issue actually only happens on Windows XP;-)
> >
> >
> I've encountered this issue a while back when trying to do about 20
> simultaneous transcodings with some video filters. It was on a high-end CPU
> with a lot of cores so every codec and MT-enabled video filter would spawn
> a lot of threads - can't remember exact number but hundreds of them. The
> threads' stacks would eat up all of the process' address space causing OOM.
> It was on Windows 7, and it's something you probably can call real-world
> example. I ended up disabling MT everywhere I can to fix that (which was a
> right thing to do anyway since my program was already multithreaded and it
> could use all the cores anyway). This thread-pool idea sounds reasonable to
> me; more reasonable than 8-16 threads per codec anyway.

I think this problem and the effects of the thread number should at
least be documented better. So other users running into this who
maybe are not as knowledgable know what to tweak

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[wm4]

On Fri, 8 Jan 2016 23:20:40 +1100
Jean-Yves Avenard  wrote:

> On 8 January 2016 at 20:51, wm4  wrote:
> > Anyway, as another point I would argue:
> > - discouraging web devs from creating too many video elements, and
> >   introducing a static "reasonable" limit (maybe a dozen elements)  
> 
> You're kidding right? So what, you just don't display the video
> because really it was a silly idea in creating such page?

This feels very weird. I'm complaining that you want web pages to
create hundreds of video elements, and then I'm asked whether I'm
kidding. Would you complain that a car doesn't move if you try to
load it with hundreds of tons of stuff?

Teach the web devs that some resources are just expensive, and
everything will be fine.

> The world is moving from Flash to HTML5. Those web sites exist
> *today*, they are moving to html5 progressively (and we want to make
> them move to html5)
> 
> 
> > - not using MT for very small video (MT would probably make it slower
> >   anyway)  
> 
> Even with one thread per decoder, it's still not enough. Even by your
> example, it would be silly to open 30 threads to play 30 videos when
> your processor is unable to handle all those thread concurrently
> anyway.

Then don't create 30 threads.

> A task queue would perform just as well with 4/30th of the RAM
> (assuming you created the thread pool with 4 threads).

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

Re: [FFmpeg-devel] [PATCH v3] lavf/mov: Audio and fourcc 0x00000000

[Mats Peterson]

On 01/08/2016 02:24 PM, Michael Niedermayer wrote:

applied

simplified a bit

thanks



I missed the fact that sc->format is available to the function. I'll 
make another patch that removes the redundant stuff that I added.


Mats

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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[compn]

On Fri, 8 Jan 2016 10:51:39 +0100
wm4  wrote:

> On Fri, 8 Jan 2016 09:42:52 + (UTC)
> Carl Eugen Hoyos  wrote:
> 
> > wm4  googlemail.com> writes:
> > 
> > > On Fri, 8 Jan 2016 17:55:38 +1100
> > > Jean-Yves Avenard  gmail.com> wrote:
> > >   
> > > > One of the issues we've faced was with our reftest 
> > > > tests, with pages creating hundreds of small video 
> > > > elements (the test change orientation, sizes, 
> > > > transparency and the like and check that there's
> > > > no regression on how things are displayed).  
> > > 
> > > Do I understand right that only your tests do this?  
> > 
> > I may have misunderstood myself but I believe the 
> > issue actually only happens on Windows XP;-)
> 
> I suppose the larger memory usage would be considered a problem too,
> and also can hit 32 bit boundaries even on non-XP.
> 
> Anyway, as another point I would argue:
> - discouraging web devs from creating too many video elements, and

i think mozilla should share one test page with the hundred elements so
that we can see first hand the destruction.

does this also happen with webp ? e.g. if all images are vp8 webp and if
you used libavcodec to decode them?

because 100 images would be a real world test, and it would explain why
this is needed.

i've seen html pages with 100 videos, thats just a forum with a music
thread where people post youtube music videos. set forum to display 100
posts at a time and thats easily 100 video elements on one page,
although of course not playing at the same time.

free file hosting / porn websites also utilize multiple video ads at
the same time. easily using 16 video elements at the same time. i've
seen many websites slow the web browser down to nothing with flash
video (which is why i do not use firefox on many sites).

asking web developers to not show so many video ads is a bit
shortsighted imo.

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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 23:43, wm4  wrote:
> Sorry, the problem you're trying to solve is just too ridiculous.

Welcome to the world wide web ! :)

> Threads might be the heaviest resource here, but no matter what you do,
> having hundreds of objects active at the same time (bring back geocity
> websites from the 90ies?) will cause a memory and CPU resource usage
> problem. So what if it fails on Windows XP.

You do know that people using a web browser typically have more than
one page or tab open at any given time.

I have about 75 opened as I'm writing this. Of course not all of them
have animated objects being displayed, but it's far from uncommon.

So have 30 video elements in one page, or 1 in 30 pages, it's kind of
the same issue.

Ever used facebook? see how many videos or animated objects you can
have in a discussion?

Luckily not everyone think it's a ridiculous problem to solve and just gave up.

Apple's VideoToolbox or Windows's WMF typically have a pool of
surfaces and threads they share internally.
I'm only suggesting that FFmpeg should consider doing the same,
because it has more potential use than old fashion media player that
only needed to worry about playing a single video at a time.

>
>> clearly haven't done much work on highly parallelised application, and
>> who fail to even consider the problem.
>
> Maybe you're trying to argue from some sort of theoretical point of
> view, but I'm thinking about practical issues, such as managing a
> global thread pool. Regardless of "parallisation", for the problem at
> this is also an overcomplicated and inefficient solution. Plus I didn't
> even completely reject the idea of having some sort of thread pool.

Have you ever used thread pools or task queue ? how could that ever be
over complicated or inefficient?
There are plenty of libraries providing them, heck you could use our
own XPCOM to do it.
As far as thread pools are concerned, it's very lightweight, far
easier to use than pthreads and extremely efficient (which I could say
the same for the rest of it).
You feed it with runnables and it run them as best as it can (either
sequentially or multiple at once if there are enough threads to
service them)

Please think about the problem more carefully, and reconsider.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[foo86]

On Thu, Jan 07, 2016 at 08:17:59PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 18:49, foo86 wrote:
> > +for (i = 0; i < spkr_remap_nsets; i++) {
> > +// Number of channels to be decoded for speaker remapping
> > +int nch_for_remaps = get_bits(>gb, 5) + 1;
> > +
> > +for (j = 0; j < nspeakers[i]; j++) {
> > +// Decoded channels to output speaker mapping mask
> > +int remap_ch_mask = get_bits(>gb, nch_for_remaps);
> 
> Here nch_for_remaps can be up to 32, so this has to use get_bits_long, as
> get_bits only supports reading 1-25 bits.

Missed this one, changed to get_bits_long.

> > +for (i = 0; i < s->nmixoutconfigs; i++) {
> > +for (j = 0; j < nchannels_dmix; j++) {
> > +// Mix output mask
> > +int mix_map_mask = get_bits(>gb, s->nmixoutchs[i]);
> 
> Here s->nmixoutchs[i] can be zero. If that should not happen, there needs
> to be an error check and otherwise it should use get_bitsz, because
> get_bits doesn't support reading 0 bits.

It doesn't seem that zero channel mask should normally happen, added an
error check earlier.

> Anyway, I still think the code is pretty robust. :-)

Thanks for testing!

> I'd be glad to increase fuzz-testing coverage further, but I'm lacking
> input examples. It would be great if you could share some (tiny) samples
> triggering the HEADER_XCH/HEADER_XXCH cases and/or *_down_mix functions.

As Hendrik pointed out, there are lidcadec test suite samples you can
use for this. To trigger all downmixing functions you may need to
provide -request_channel_layout 3 option.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/ccaption_dec: remove unnecessary buffering of closed caption packets

[Anshul]

On 8 January 2016 5:27:37 pm IST, "Clément Bœsch"  wrote:
>On Fri, Jan 08, 2016 at 05:24:15PM +0530, Anshul wrote:
>> 
>> 
>> On 6 January 2016 1:55:27 am IST, "Clément Bœsch"  wrote:
>> >On Sun, Jan 03, 2016 at 01:07:15PM +0100, Clément Bœsch wrote:
>> >[...]
>> >> This indeed LGTM, but I'm not the maintainer.
>> >> 
>> >
>> >OK I finally understood why it's done that way:
>validate_cc_data_pair()
>> >alters the pkt data, but the decoder isn't supposed to do that.
>> >
>> >So this patch is actually incorrect in this state.
>> 
>> 
>> I did not knew, what could be the disadvantage of changing pkt data,
>I
>> changed it to save some CPU cycles.
>
>The packet is considered read-only for the decoder. It appears not to
>be
>marked as const for whatever bad reason.
>
>But what CPU cycles would you be saving anyway here? I don't see what
>operation you are saving.
>
>[...]

Not much, just bitwise operations to discard parity bit, every time for 
conversion and comparison.

-Anshul

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6] lavf/matroskadec: A_QUICKTIME and fourcc 0x00000000

[Mats Peterson]

On 01/08/2016 02:12 PM, Michael Niedermayer wrote:

On Fri, Jan 08, 2016 at 01:03:05PM +0100, Mats Peterson wrote:

In many older QuickTime files, the audio format, or "fourcc", is
0x. The QuickTime File Format Specification states the following
regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  matroskadec.c |9 +
  1 file changed, 9 insertions(+)
7a07b5c37987840d43a2710c854316bb31c1  
0001-lavf-matroskadec-A_QUICKTIME-and-fourcc-0x.patch
 From d8507d9b0645585d2d27c614f1f7d3347edf8733 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 8 Jan 2016 12:55:59 +0100
Subject: [PATCH v6] lavf/matroskadec: A_QUICKTIME and fourcc 0x

In many older QuickTime files, the audio format, or "fourcc", is
0x. The QuickTime File Format Specification states the following
regarding this situation:

"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

---
  libavformat/matroskadec.c |9 +
  1 file changed, 9 insertions(+)


applied

thanks

[...]



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



I can't see the applied patches at GitHub yet. Is a delay normal? Sorry 
for a stupid question.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 9 January 2016 at 00:39, Derek Buitenhuis  wrote:
> This seems to be a rather contentious subject. Would you be amenable to
> perhaps joining #ffmpeg-devel to discuss in real time? In my experience,
> stuff gets cleared up a lot faster, and with few misunderstandings / large
> mailing list flames/threads, for subjects like these, in such a setting.
> That's just my 2 cents of course.

It's already Saturday here, and 1:20AM. So can't argue with much conviction :)

As mentioned on #opus, be it a global pool, or a call back , or
whatever context that can be shared across decoder, the end result is
the same: share of resources across all decoders.

I will come on Monday if that's okay... could setup a time that works
for you. I'm based in Melbourne Australia
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6] lavf/matroskadec: A_QUICKTIME and fourcc 0x00000000

[Mats Peterson]

On 01/08/2016 03:07 PM, Moritz Barsnick wrote:

On Fri, Jan 08, 2016 at 14:51:53 +0100, Mats Peterson wrote:

I can't see the applied patches at GitHub yet. Is a delay normal? Sorry
for a stupid question.


Yes, that is normal. videolan.org hosts the "original".

There was an explanation in this thread:
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180844.html

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



Yes, I just pulled the latest, and the changes are there alright. Thanks 
for the information.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/ccaption_dec: remove unnecessary buffering of closed caption packets

[Anshul]

On 6 January 2016 1:55:27 am IST, "Clément Bœsch"  wrote:
>On Sun, Jan 03, 2016 at 01:07:15PM +0100, Clément Bœsch wrote:
>[...]
>> This indeed LGTM, but I'm not the maintainer.
>> 
>
>OK I finally understood why it's done that way: validate_cc_data_pair()
>alters the pkt data, but the decoder isn't supposed to do that.
>
>So this patch is actually incorrect in this state.


I did not knew, what could be the disadvantage of changing pkt data, I changed 
it to save some CPU cycles.

But I can change it, if there is any disadvantage.

Over there I have just removed parity bit

-Anshul
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 20:51, wm4  wrote:
> Anyway, as another point I would argue:
> - discouraging web devs from creating too many video elements, and
>   introducing a static "reasonable" limit (maybe a dozen elements)

You're kidding right? So what, you just don't display the video
because really it was a silly idea in creating such page?

The world is moving from Flash to HTML5. Those web sites exist
*today*, they are moving to html5 progressively (and we want to make
them move to html5)


> - not using MT for very small video (MT would probably make it slower
>   anyway)

Even with one thread per decoder, it's still not enough. Even by your
example, it would be silly to open 30 threads to play 30 videos when
your processor is unable to handle all those thread concurrently
anyway.
A task queue would perform just as well with 4/30th of the RAM
(assuming you created the thread pool with 4 threads).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Kieran Kunhya]

On 8 January 2016 at 12:43, wm4  wrote:
> On Fri, 8 Jan 2016 23:28:20 +1100
> Jean-Yves Avenard  wrote:
>
>> On 8 January 2016 at 23:24, wm4  wrote:
>> >
>> > A global thread pool sounds like an extremely messy and unclean
>> > solution. The state of a library is not supposed to affect anything
>> > else in the same process.
>>
>> The point of my message was to start a discussion, not to receive
>> immediate answer ridiculing the idea and I have to say by someone who

I think the idea of a threadpool is a good idea - we have usecases
where we want to make a videowall of HD material with like 30 HD
sources that need to all be deinterlaced then scaled etc.

But it shouldn't be a global threadpool - it should be a generic
threadpool that could even be used by non-FFmpeg tasks. Presumably you
would attach it to a decoder and the decoder would use it (very
handwavy I know).

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

Re: [FFmpeg-devel] [PATCH v3] lavf/mov: Audio and fourcc 0x00000000

[Mats Peterson]

On 01/08/2016 02:56 PM, Mats Peterson wrote:

I missed the fact that sc->format is available to the function. I'll
make another patch that removes the redundant stuff that I added.


Ah sorry, it was already removed. Thanks for the edit, Michael.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] lavc/cbrt_tablegen: speed up tablegen

[Michael Niedermayer]

On Thu, Jan 07, 2016 at 05:20:55PM -0800, Ganesh Ajjanagadde wrote:
> On Thu, Jan 7, 2016 at 4:48 PM, Michael Niedermayer
>  wrote:
> > On Mon, Jan 04, 2016 at 06:33:59PM -0800, Ganesh Ajjanagadde wrote:
> >> This exploits an approach based on the sieve of Eratosthenes, a popular
> >> method for generating prime numbers.
> >>
> >> Tables are identical to previous ones.
> >>
> >> Tested with FATE with/without --enable-hardcoded-tables.
> >>
> >> Sample benchmark (Haswell, GNU/Linux+gcc):
> >> prev:
> >> 7860100 decicycles in cbrt_tableinit,   1 runs,  0 skips
> >> 490 decicycles in cbrt_tableinit,   2 runs,  0 skips
> >> [...]
> >> 7582339 decicycles in cbrt_tableinit, 256 runs,  0 skips
> >> 7563556 decicycles in cbrt_tableinit, 512 runs,  0 skips
> >>
> >> new:
> >> 2099480 decicycles in cbrt_tableinit,   1 runs,  0 skips
> >> 2044470 decicycles in cbrt_tableinit,   2 runs,  0 skips
> >> [...]
> >> 1796544 decicycles in cbrt_tableinit, 256 runs,  0 skips
> >> 1791631 decicycles in cbrt_tableinit, 512 runs,  0 skips
> >>
> >> Both small and large run count given as this is called once so small run
> >> count may give a better picture, small numbers are fairly consistent,
> >> and there is a consistent downward trend from small to large runs,
> >> at which point it stabilizes to a new value.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  libavcodec/aacdec_fixed.c   |  4 +--
> >>  libavcodec/aacdec_template.c|  2 +-
> >>  libavcodec/cbrt_tablegen.h  | 53 
> >> ++---
> >>  libavcodec/cbrt_tablegen_template.c | 12 -
> >>  4 files changed, 51 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
> >> index 396a874..f7b882b 100644
> >> --- a/libavcodec/aacdec_fixed.c
> >> +++ b/libavcodec/aacdec_fixed.c
> >> @@ -155,9 +155,9 @@ static void vector_pow43(int *coefs, int len)
> >>  for (i=0; i >>  coef = coefs[i];
> >>  if (coef < 0)
> >> -coef = -(int)cbrt_tab[-coef];
> >> +coef = -(int)cbrt_tab[-coef].i;
> >>  else
> >> -coef = (int)cbrt_tab[coef];
> >> +coef = (int)cbrt_tab[coef].i;
> >>  coefs[i] = coef;
> >>  }
> >>  }
> >> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> >> index d819958..1380510 100644
> >> --- a/libavcodec/aacdec_template.c
> >> +++ b/libavcodec/aacdec_template.c
> >> @@ -1791,7 +1791,7 @@ static int decode_spectrum_and_dequant(AACContext 
> >> *ac, INTFLOAT coef[1024],
> >>  v = -v;
> >>  *icf++ = v;
> >>  #else
> >> -*icf++ = cbrt_tab[n] | (bits & 
> >> 1U<<31);
> >> +*icf++ = cbrt_tab[n].i | (bits & 
> >> 1U<<31);
> >>  #endif /* USE_FIXED */
> >>  bits <<= 1;
> >>  } else {
> >> diff --git a/libavcodec/cbrt_tablegen.h b/libavcodec/cbrt_tablegen.h
> >> index 59b5a1d..e3d6634 100644
> >> --- a/libavcodec/cbrt_tablegen.h
> >> +++ b/libavcodec/cbrt_tablegen.h
> >> @@ -26,14 +26,13 @@
> >>  #include 
> >>  #include 
> >>  #include "libavutil/attributes.h"
> >> +#include "libavutil/intfloat.h"
> >>  #include "libavcodec/aac_defines.h"
> >>
> >> -#if USE_FIXED
> >> -#define CBRT(x) lrint((x).f * 8192)
> >> -#else
> >> -#define CBRT(x) x.i
> >> -#endif
> >> -
> >
> >> +union ff_int32float64 {
> >> +uint32_t i;
> >> +double   f;
> >> +};
> >>  #if CONFIG_HARDCODED_TABLES
> >>  #if USE_FIXED
> >>  #define cbrt_tableinit_fixed()
> >> @@ -43,20 +42,42 @@
> >>  #include "libavcodec/cbrt_tables.h"
> >>  #endif
> >>  #else
> >> -static uint32_t cbrt_tab[1 << 13];
> >> +static union ff_int32float64 cbrt_tab[1 << 13];
> >
> > this doubles the size of the cpu cache needed at runtime to store
> > the same number of elements
> 
> Yes, it does, and it was a tradeoff I made that I forgot to list. One
> can of course use floats; but this loses accuracy at significant
> levels.
> 
> So one could malloc and free a double precision array (for temporary
> storage) at costs of some code complexity, possible heap
> fragmentation, and the problem of possible failure (may be ok since
> anyway aac_decode_init is not guaranteed to succeed; it allocates
> memory for the dsp context). Malloc/free is AFAIK ~ 100's of cycles,
> dwarfed by the table generation cost.
> 
> The problem is that it is impossible to give an answer as to precisely
> what impact that will have on decoding/encoding performance, and
> results of course vary based on hardware. This is the same problem
> that plagues static/dynamic table performance analysis.
> 
> I don't have a measurable performance regression on my machine for aac
> decoding because of this. 

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 21:35, Andrey Turkin  wrote:
> example. I ended up disabling MT everywhere I can to fix that (which was a
> right thing to do anyway since my program was already multithreaded and it
> could use all the cores anyway). This thread-pool idea sounds reasonable to
> me; more reasonable than 8-16 threads per codec anyway.

Thank you ! :)

Yeah, Win7 32 bits dies when your process attempt to open about 730 threads.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Derek Buitenhuis]

On 1/8/2016 6:55 AM, Jean-Yves Avenard wrote:
> We originally had configured AVCodecContext::thread_count to 0, which
> on the machines running the tests would end up creating 8 threads per
> decoder.
> On windows 32 bits, that would amount in thousand of threads being
> created for that particular test which would typically fail with OOM
> (Windows XP would fail to create more than 1380 threads).

FWIW, I have run into this on x64_64 Linux, on transcoding machines,
at work, as well.

This seems to be a rather contentious subject. Would you be amenable to
perhaps joining #ffmpeg-devel to discuss in real time? In my experience,
stuff gets cleared up a lot faster, and with few misunderstandings / large
mailing list flames/threads, for subjects like these, in such a setting.
That's just my 2 cents of course.

Cheers,

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

[FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

[James Almer]

The function documentation explicitly mentions it needs to be a multiple of 4.

Signed-off-by: James Almer 
---
 libavutil/x86/float_dsp.asm | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavutil/x86/float_dsp.asm b/libavutil/x86/float_dsp.asm
index 87229d4..6ac2aa8 100644
--- a/libavutil/x86/float_dsp.asm
+++ b/libavutil/x86/float_dsp.asm
@@ -362,8 +362,6 @@ cglobal butterflies_float, 3,3,3, src0, src1, len
 %if ARCH_X86_64
 movsxdlenq, lend
 %endif
-test  lenq, lenq
-jz .end
 shl   lenq, 2
 add  src0q, lenq
 add  src1q, lenq
@@ -377,5 +375,4 @@ cglobal butterflies_float, 3,3,3, src0, src1, len
 mova[src0q + lenq], m0
 add   lenq, mmsize
 jl .loop
-.end:
 REP_RET
-- 
2.6.3

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

[FFmpeg-devel] [PATCH 2/3] x86/float_dsp: zero extend len from ff_butterflies_float_sse implicitly

[James Almer]

Signed-off-by: James Almer 
---
 libavutil/x86/float_dsp.asm | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/libavutil/x86/float_dsp.asm b/libavutil/x86/float_dsp.asm
index 6ac2aa8..743e1c1 100644
--- a/libavutil/x86/float_dsp.asm
+++ b/libavutil/x86/float_dsp.asm
@@ -359,10 +359,7 @@ cglobal scalarproduct_float, 3,3,2, v1, v2, offset
 ;-
 INIT_XMM sse
 cglobal butterflies_float, 3,3,3, src0, src1, len
-%if ARCH_X86_64
-movsxdlenq, lend
-%endif
-shl   lenq, 2
+shl   lend, 2
 add  src0q, lenq
 add  src1q, lenq
 neg   lenq
-- 
2.6.3

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

Re: [FFmpeg-devel] [PATCH] configure: Use libgcrypt-config if available

[Ricardo Constantino]

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

[FFmpeg-devel] [PATCH v3] lavf/matroskadec: Normalize noncompliant A_QUICKTIME/V_QUICKTIME private data

[Mats Peterson]

Incorrectly used ff_codec_movvideo_tags instead of codec_tags.
Description follows:

This patch adds a new static function get_qt_codec() that takes care of 
the initial retrieval of the fourcc and codec ID for A_QUICKTIME and 
V_QUICKTIME. It also normalizes noncompliant private data found in some 
older files that incorrectly starts with the fourcc by 
expanding/shifting the data by 4 bytes, and storing the data size at the 
start. This is important in order to make the private data work as 
expected and without false positives with the rest of the code in the 
A_QUICKTIME and V_QUICKTIME blocks (and most likely in other places as 
well).


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 3e4c8f4926b59b01cd945f3789dcc59b69f17bef Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 8 Jan 2016 17:57:27 +0100
Subject: [PATCH v3] lavf/matroskadec: Normalize noncompliant A_QUICKTIME/V_QUICKTIME private data

Incorrectly used ff_codec_movvideo_tags instead of codec_tags.
Description follows:

This patch adds a new static function get_qt_codec() that takes care of
the initial retrieval of the fourcc and codec ID for A_QUICKTIME and
V_QUICKTIME. It also normalizes noncompliant private data found in some
older files that incorrectly starts with the fourcc by expanding/shifting
the data by 4 bytes, and storing the data size at the start. This is
important in order to make the private data work as expected and without
false positives with the rest of the code in the A_QUICKTIME and
V_QUICKTIME blocks (and most likely in other places as well).

Mats

---
 libavformat/matroskadec.c |   49 +
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index be4e300..a80df41 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1708,6 +1708,34 @@ static void mkv_stereo_mode_display_mul(int stereo_mode, int *h_width, int *h_he
 }
 }
 
+static int get_qt_codec(MatroskaTrack *track, uint32_t *fourcc, enum AVCodecID *codec_id)
+{
+const AVCodecTag *codec_tags;
+
+codec_tags = track->type == MATROSKA_TRACK_TYPE_VIDEO ?
+ff_codec_movvideo_tags : ff_codec_movaudio_tags;
+
+*fourcc = AV_RL32(track->codec_priv.data + 4);
+*codec_id = ff_codec_get_id(codec_tags, *fourcc);
+
+/* Normalize noncompliant private data that starts with the fourcc
+ * by expanding/shifting the data by 4 bytes and storing the data
+ * size at the start. */
+if (ff_codec_get_id(codec_tags, AV_RL32(track->codec_priv.data))) {
+if (!(track->codec_priv.data = av_realloc(track->codec_priv.data,
+track->codec_priv.size + 4)))
+return AVERROR(ENOMEM);
+memmove(track->codec_priv.data + 4, track->codec_priv.data,
+track->codec_priv.size);
+track->codec_priv.size += 4;
+AV_WB32(track->codec_priv.data, track->codec_priv.size);
+*fourcc = AV_RL32(track->codec_priv.data + 4);
+*codec_id = ff_codec_get_id(codec_tags, *fourcc);
+}
+
+return 0;
+}
+
 static int matroska_parse_tracks(AVFormatContext *s)
 {
 MatroskaDemuxContext *matroska = s->priv_data;
@@ -1861,14 +1889,12 @@ static int matroska_parse_tracks(AVFormatContext *s)
 fourcc   = st->codec->codec_tag;
 extradata_offset = FFMIN(track->codec_priv.size, 18);
 } else if (!strcmp(track->codec_id, "A_QUICKTIME")
-   && (track->codec_priv.size >= 36)
+   /* Normally 36, but allow noncompliant private data */
+   && (track->codec_priv.size >= 32)
&& (track->codec_priv.data)) {
-fourcc = AV_RL32(track->codec_priv.data + 4);
-codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
-if (ff_codec_get_id(ff_codec_movaudio_tags, AV_RL32(track->codec_priv.data))) {
-fourcc = AV_RL32(track->codec_priv.data);
-codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
-}
+int ret = get_qt_codec(track, , _id);
+if (ret < 0)
+return ret;
 if (fourcc == 0) {
 if (track->audio.bitdepth == 8) {
 fourcc = MKTAG('r','a','w',' ');
@@ -1881,12 +1907,9 @@ static int matroska_parse_tracks(AVFormatContext *s)
 } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
(track->codec_priv.size >= 21)  &&
(track->codec_priv.data)) {
-fourcc   = AV_RL32(track->codec_priv.data + 4);
-codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
-if (ff_codec_get_id(ff_codec_movvideo_tags, AV_RL32(track->codec_priv.data))) {
-fourcc   = AV_RL32(track->codec_priv.data);
-codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
-

[FFmpeg-devel] [PATCH 3/3] x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse

[James Almer]

Signed-off-by: James Almer 
---
 libavutil/x86/float_dsp.asm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/x86/float_dsp.asm b/libavutil/x86/float_dsp.asm
index 743e1c1..021ff03 100644
--- a/libavutil/x86/float_dsp.asm
+++ b/libavutil/x86/float_dsp.asm
@@ -332,10 +332,10 @@ VECTOR_FMUL_REVERSE
 ; float scalarproduct_float_sse(const float *v1, const float *v2, int len)
 INIT_XMM sse
 cglobal scalarproduct_float, 3,3,2, v1, v2, offset
+shl   offsetd, 2
+add   v1q, offsetq
+add   v2q, offsetq
 neg   offsetq
-shl   offsetq, 2
-sub   v1q, offsetq
-sub   v2q, offsetq
 xorpsxmm0, xmm0
 .loop:
 movaps   xmm1, [v1q+offsetq]
-- 
2.6.3

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

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

[Christophe Gisquet]

Hi,

2016-01-08 16:22 GMT+01:00 James Almer :
> -test  lenq, lenq
> -jz .end
>  shl   lenq, 2
>  add  src0q, lenq
>  add  src1q, lenq
> @@ -377,5 +375,4 @@ cglobal butterflies_float, 3,3,3, src0, src1, len
>  mova[src0q + lenq], m0
>  add   lenq, mmsize
>  jl .loop
> -.end:
>  REP_RET

Can't recall why I did that. Ok then.

On a side note, do you intend to do an avx version?

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

Re: [FFmpeg-devel] have some major changes for nvenc support

[Michael Niedermayer]

On Fri, Jan 08, 2016 at 03:04:26PM +0300, Andrey Turkin wrote:
> In my opinion this proliferation of various filters which do the same thing
> in different way is a configuration headache. There's CPU filters: one for
> scaling/format conversion, one for padding, one  for cropping, like 5
> different filters for deinterlacing. And now there would be nvresize for
> scaling, and we gotta add CUDA-based nvpad and nvdeint if we want to do
> some transcoding. Maybe add overlaying too - so nvoverlay. Then there is
> OpenCL which can do everything - so 4 more filters for that. And there is
> quicksync which I think can do those things, so there would be qsvscale and
> qsvdeint. And there is D3D11 video processor which can do those things too
> (simultaneously in fact), so there's gotta be
> d3d11vascaledeintpadcropoverlay. And then we've got a whole bunch of video
> filters which can only do their job on a specific hwaccel platform. Want to
> try different hwaccel? Rewrite damn filter string. Want to do something
> generic that can be used over different platforms? Can't be done.
> Maybe it's just my wishful thinking, but I was wondering for some time if
> there can be one "smart" filter to do one specific thing? Say, single
> deinterlace filter which can automatically use whichever hwaccel was used
> on its input (or whichever will be used on its output)? We've already got
> pixel formats which describe particular hwaccel - can't filters decide
> which code path to use based on that? And it can have a configuration

Also slightly orthogonal but if you have 4 filters each written for a
different hwaccel you can write a generic filter that passes its
stuff to the appropriate one
If theres not much shareale code between hw specific filters then this
might be cleaner than throwing all hw specifc code in one filter
directly

such seperate filters could use the existing conditional compilation
code, could be used directly if the user wants to force a specific
hw type, ...

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Michael Niedermayer]

On Sat, Jan 09, 2016 at 03:10:48AM +1100, Jean-Yves Avenard wrote:
> On 9 January 2016 at 01:22, compn  wrote:
> 
> > i think mozilla should share one test page with the hundred elements so
> > that we can see first hand the destruction.
> 
> here is a simple one:
> http://people.mozilla.org/~cpearce/stress/
> 
> For our test page:
> http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video/object-fit-contain-webm-001.html
> it contains 21 tiny videos, but when displayed very quickly with all
> the ones found in
> http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video,
> you easily reach > 100 videos.
> 
> 
> >
> > does this also happen with webp ? e.g. if all images are vp8 webp and if
> > you used libavcodec to decode them?
> 
> we don't support webp, but it would be unlikely as we only need the
> decoder once to get the image. After that it can be shutdown.
> 
> >
> > because 100 images would be a real world test, and it would explain why
> > this is needed.
> >
> > i've seen html pages with 100 videos, thats just a forum with a music
> > thread where people post youtube music videos. set forum to display 100
> > posts at a time and thats easily 100 video elements on one page,
> > although of course not playing at the same time.
> 
> they are indeed very common.
> 
> Even more so in China. Lots of shiny, moving web sites there with
> animated smileys, buttons you name it.

at some low size and duration it would likely become more efficient
to decode the video and store all decoded frames instead of keeping
a decoder instance in memory to repeatly decode & cycle through the
frames

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

[FFmpeg-devel] [PATCH v2] lavf/matroskadec: Normalize noncompliant A_QUICKTIME/V_QUICKTIME private data

[Mats Peterson]

Changed the name of get_qt_priv_data() to the more appropriate
get_qt_codec(). Description follows:

This patch adds a new static function get_qt_codec() that takes care of 
the initial retrieval of the fourcc and codec ID for A_QUICKTIME and 
V_QUICKTIME. It also normalizes noncompliant private data found in some 
older files that incorrectly starts with the fourcc by 
expanding/shifting the data by 4 bytes, and storing the data size at the 
start. This is important in order to make the private data work as 
expected and without false positives with the rest of the code in the 
A_QUICKTIME and V_QUICKTIME blocks (and most likely in other places as 
well).


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 6031e4d9ca09aaa7befdf2f2d0e464965849547a Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 8 Jan 2016 17:22:52 +0100
Subject: [PATCH v2] lavf/matroskadec: Normalize noncompliant A_QUICKTIME/V_QUICKTIME data

Changed the name of get_qt_priv_data() to the more appropriate
get_qt_codec(). Description follows:

This patch adds a new static function get_qt_codec() that takes care of
the initial retrieval of the fourcc and codec ID for A_QUICKTIME and
V_QUICKTIME. It also normalizes noncompliant private data found in some
older files that incorrectly starts with the fourcc by expanding/shifting
the data by 4 bytes, and storing the data size at the start. This is
important in order to make the private data work as expected and without
false positives with the rest of the code in the A_QUICKTIME and
V_QUICKTIME blocks (and most likely in other places as well).

Mats

---
 libavformat/matroskadec.c |   49 +
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index be4e300..ff486c2 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1708,6 +1708,34 @@ static void mkv_stereo_mode_display_mul(int stereo_mode, int *h_width, int *h_he
 }
 }
 
+static int get_qt_codec(MatroskaTrack *track, uint32_t *fourcc, enum AVCodecID *codec_id)
+{
+const AVCodecTag *codec_tags;
+
+codec_tags = track->type == MATROSKA_TRACK_TYPE_VIDEO ?
+ff_codec_movvideo_tags : ff_codec_movaudio_tags;
+
+*fourcc = AV_RL32(track->codec_priv.data + 4);
+*codec_id = ff_codec_get_id(codec_tags, *fourcc);
+
+/* Normalize noncompliant private data that starts with the fourcc
+ * by expanding/shifting the data by 4 bytes and storing the data
+ * size at the start. */
+if (ff_codec_get_id(codec_tags, AV_RL32(track->codec_priv.data))) {
+if (!(track->codec_priv.data = av_realloc(track->codec_priv.data,
+track->codec_priv.size + 4)))
+return AVERROR(ENOMEM);
+memmove(track->codec_priv.data + 4, track->codec_priv.data,
+track->codec_priv.size);
+track->codec_priv.size += 4;
+AV_WB32(track->codec_priv.data, track->codec_priv.size);
+*fourcc = AV_RL32(track->codec_priv.data + 4);
+*codec_id = ff_codec_get_id(ff_codec_movvideo_tags, *fourcc);
+}
+
+return 0;
+}
+
 static int matroska_parse_tracks(AVFormatContext *s)
 {
 MatroskaDemuxContext *matroska = s->priv_data;
@@ -1861,14 +1889,12 @@ static int matroska_parse_tracks(AVFormatContext *s)
 fourcc   = st->codec->codec_tag;
 extradata_offset = FFMIN(track->codec_priv.size, 18);
 } else if (!strcmp(track->codec_id, "A_QUICKTIME")
-   && (track->codec_priv.size >= 36)
+   /* Normally 36, but allow noncompliant private data */
+   && (track->codec_priv.size >= 32)
&& (track->codec_priv.data)) {
-fourcc = AV_RL32(track->codec_priv.data + 4);
-codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
-if (ff_codec_get_id(ff_codec_movaudio_tags, AV_RL32(track->codec_priv.data))) {
-fourcc = AV_RL32(track->codec_priv.data);
-codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
-}
+int ret = get_qt_codec(track, , _id);
+if (ret < 0)
+return ret;
 if (fourcc == 0) {
 if (track->audio.bitdepth == 8) {
 fourcc = MKTAG('r','a','w',' ');
@@ -1881,12 +1907,9 @@ static int matroska_parse_tracks(AVFormatContext *s)
 } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
(track->codec_priv.size >= 21)  &&
(track->codec_priv.data)) {
-fourcc   = AV_RL32(track->codec_priv.data + 4);
-codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
-if (ff_codec_get_id(ff_codec_movvideo_tags, AV_RL32(track->codec_priv.data))) {
-fourcc   = AV_RL32(track->codec_priv.data);
-codec_id = 

Re: [FFmpeg-devel] [PATCH 2/3] x86/float_dsp: zero extend len from ff_butterflies_float_sse implicitly

[Christophe Gisquet]

Hi,

2016-01-08 16:22 GMT+01:00 James Almer :
>  INIT_XMM sse
>  cglobal butterflies_float, 3,3,3, src0, src1, len
> -%if ARCH_X86_64
> -movsxdlenq, lend
> -%endif
> -shl   lenq, 2
> +shl   lend, 2

All the more ok since, afaik, only WIN64 actually requires that.

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: check fclose return values

[Ganesh Ajjanagadde]

On Jan 8, 2016 1:59 AM, "wm4"  wrote:
>
> On Thu, 7 Jan 2016 16:01:14 -0800
> Ganesh Ajjanagadde  wrote:
>
> > On Thu, Jan 7, 2016 at 3:57 PM, Ganesh Ajjanagadde 
wrote:
> > > On Thu, Jan 7, 2016 at 2:18 PM, Michael Niedermayer
> > >  wrote:
> > >> On Thu, Jan 07, 2016 at 11:16:27PM +0100, Michael Niedermayer wrote:
> > >>> On Thu, Jan 07, 2016 at 10:00:47AM -0800, Ganesh Ajjanagadde wrote:
> > >>> > On Thu, Jan 7, 2016 at 9:27 AM, Michael Niedermayer
> > >>> >  wrote:
> > >>> > > On Wed, Jan 06, 2016 at 09:00:46PM -0800, Ganesh Ajjanagadde
wrote:
> > >>> > >> In the spirit of commit a956840cbc. Simple method to reproduce:
> > >>> > >> pass -vstats_file /dev/full to ffmpeg.
> > >>> > >>
> > >>> > >> All raw fclose usages in ffmpeg.c taken care of here.
> > >>> > >>
> > >>> > >> Signed-off-by: Ganesh Ajjanagadde 
> > >>> > >> ---
> > >>> > >>  ffmpeg.c | 13 ++---
> > >>> > >>  1 file changed, 10 insertions(+), 3 deletions(-)
> > >>> > >
> > >>> > > LGTM
> > >>> > >
> > >>> > > thanks
> > >>> >
> > >>> > So there is actually a problem with the diagnostic obtained, a
more
> > >>> > accurate diagnostic is via errno, say strerror(errno) instead of
> > >>> > av_err2str(ret).
> > >>> > Comparison:
> > >>> > Error closing vstats file, loss of information possible:
Operation not permitted
> > >>> > vs
> > >>> > Error closing vstats file, loss of information possible: No space
left on device
> > >>> > for the provided /dev/full example.
> > >>> >
> > >>> > So there are a number of possiblities:
> > >>> > 1. Have 2 separate av_log lines, one for each of these.
> > >>> > 2. A single av_log line, using strerror(errno).
> > >>> > 3. Leave as is.
> > >>> >
> > >>> > I prefer 2. Let me know your preference, and I will push later.
> > >>>
> > >>> yes agree, 2.
> > >>
> > >> probably should use av_err2str() instead of strerror() though
> > >
> > > I thought strerror was C89? Your idea unfortunately causes problems
> > > (suspect it is because appropriate error tag is missing):
> > > Error closing vstats file, loss of information possible: Error number
> > > 28 occurred.
> >
> > Did some digging, using strerror should be fine, see 984-989 of
> > cmdutils.c for very similar usage.
>
> strerror() is not thread-safe. There is absolutely no reason for it not
> to be thread-safe, but C is full of idiocy like this.

Thanks for the clarification. Note that ffserver has quite a few usages of
it ;).
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

sent from my phone
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/matroskadec: Normalize noncompliant, A_QUICKTIME/V_QUICKTIME private data

[Mats Peterson]

This patch adds a new static function get_qt_priv_data() that takes care 
of the initial retrieval of the fourcc and codec ID for A_QUICKTIME and 
V_QUICKTIME. It also normalizes noncompliant private data found in some 
older files that incorrectly starts with the fourcc by 
expanding/shifting the data by 4 bytes, and storing the data size at the 
start. This is important in order to make the private data work as 
expected and without false positives with the rest of the code in the 
A_QUICKTIME and V_QUICKTIME blocks (and most likely in other places as 
well).


Mats
>From 3dcdf6bb857587715868751eff61a484b3d65fdc Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 8 Jan 2016 16:07:14 +0100
Subject: [PATCH] lavf/matroskadec: Normalize noncompliant
 A_QUICKTIME/V_QUICKTIME private data

This patch adds a new static function get_qt_priv_data() that takes care
of the initial retrieval of the fourcc and codec ID for A_QUICKTIME and
V_QUICKTIME. It also normalizes noncompliant private data found in some
older files that incorrectly starts with the fourcc by expanding/shifting
the data by 4 bytes, and storing the data size at the start. This is
important in order to make the private data work as expected and without
false positives with the rest of the code in the A_QUICKTIME and
V_QUICKTIME blocks (and most likely in other places as well).

Mats

---
 libavformat/matroskadec.c |   49 +
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index be4e300..4f95566 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1708,6 +1708,34 @@ static void mkv_stereo_mode_display_mul(int stereo_mode, int *h_width, int *h_he
 }
 }
 
+static int get_qt_priv_data(MatroskaTrack *track, uint32_t *fourcc, enum AVCodecID *codec_id)
+{
+const AVCodecTag *codec_tags;
+
+codec_tags = track->type == MATROSKA_TRACK_TYPE_VIDEO ?
+ff_codec_movvideo_tags : ff_codec_movaudio_tags;
+
+*fourcc = AV_RL32(track->codec_priv.data + 4);
+*codec_id = ff_codec_get_id(codec_tags, *fourcc);
+
+/* Normalize noncompliant private data that starts with the fourcc
+ * by expanding/shifting the data by 4 bytes and storing the data
+ * size at the start. */
+if (ff_codec_get_id(codec_tags, AV_RL32(track->codec_priv.data))) {
+if (!(track->codec_priv.data = av_realloc(track->codec_priv.data,
+track->codec_priv.size + 4)))
+return AVERROR(ENOMEM);
+memmove(track->codec_priv.data + 4, track->codec_priv.data,
+track->codec_priv.size);
+track->codec_priv.size += 4;
+AV_WB32(track->codec_priv.data, track->codec_priv.size);
+*fourcc = AV_RL32(track->codec_priv.data + 4);
+*codec_id = ff_codec_get_id(ff_codec_movvideo_tags, *fourcc);
+}
+
+return 0;
+}
+
 static int matroska_parse_tracks(AVFormatContext *s)
 {
 MatroskaDemuxContext *matroska = s->priv_data;
@@ -1861,14 +1889,12 @@ static int matroska_parse_tracks(AVFormatContext *s)
 fourcc   = st->codec->codec_tag;
 extradata_offset = FFMIN(track->codec_priv.size, 18);
 } else if (!strcmp(track->codec_id, "A_QUICKTIME")
-   && (track->codec_priv.size >= 36)
+   /* Normally 36, but allow noncompliant private data */
+   && (track->codec_priv.size >= 32)
&& (track->codec_priv.data)) {
-fourcc = AV_RL32(track->codec_priv.data + 4);
-codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
-if (ff_codec_get_id(ff_codec_movaudio_tags, AV_RL32(track->codec_priv.data))) {
-fourcc = AV_RL32(track->codec_priv.data);
-codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
-}
+int ret = get_qt_priv_data(track, , _id);
+if (ret < 0)
+return ret;
 if (fourcc == 0) {
 if (track->audio.bitdepth == 8) {
 fourcc = MKTAG('r','a','w',' ');
@@ -1881,12 +1907,9 @@ static int matroska_parse_tracks(AVFormatContext *s)
 } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
(track->codec_priv.size >= 21)  &&
(track->codec_priv.data)) {
-fourcc   = AV_RL32(track->codec_priv.data + 4);
-codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
-if (ff_codec_get_id(ff_codec_movvideo_tags, AV_RL32(track->codec_priv.data))) {
-fourcc   = AV_RL32(track->codec_priv.data);
-codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
-}
+int ret = get_qt_priv_data(track, , _id);
+if (ret < 0)
+return ret;
 if (codec_id == AV_CODEC_ID_NONE && AV_RL32(track->codec_priv.data+4) 

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 9 January 2016 at 01:22, compn  wrote:

> i think mozilla should share one test page with the hundred elements so
> that we can see first hand the destruction.

here is a simple one:
http://people.mozilla.org/~cpearce/stress/

For our test page:
http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video/object-fit-contain-webm-001.html
it contains 21 tiny videos, but when displayed very quickly with all
the ones found in
http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video,
you easily reach > 100 videos.


>
> does this also happen with webp ? e.g. if all images are vp8 webp and if
> you used libavcodec to decode them?

we don't support webp, but it would be unlikely as we only need the
decoder once to get the image. After that it can be shutdown.

>
> because 100 images would be a real world test, and it would explain why
> this is needed.
>
> i've seen html pages with 100 videos, thats just a forum with a music
> thread where people post youtube music videos. set forum to display 100
> posts at a time and thats easily 100 video elements on one page,
> although of course not playing at the same time.

they are indeed very common.

Even more so in China. Lots of shiny, moving web sites there with
animated smileys, buttons you name it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse

[Christophe Gisquet]

Hi,

2016-01-08 16:22 GMT+01:00 James Almer :
> +shl   offsetd, 2
> +add   v1q, offsetq
> +add   v2q, offsetq
>  neg   offsetq
> -shl   offsetq, 2
> -sub   v1q, offsetq
> -sub   v2q, offsetq

Lucky that we never had any crash then.

OK.

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