Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size
On 01.08.2017 17:01, Muhammad Faiz wrote: Fix Ticket6519. Signed-off-by: Muhammad Faiz --- libavfilter/vf_ssim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c index c3c204268f..dfd276e015 100644 --- a/libavfilter/vf_ssim.c +++ b/libavfilter/vf_ssim.c @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) for (i = 0; i < s->nb_components; i++) s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); +s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); if (!s->temp) return AVERROR(ENOMEM); s->max = (1 << desc->comp[0].depth) - 1; I confirm that the command doesn't crash anymore and the reports of "invalid read/write" in Valgrind are gone. However there are still some "use of uninitialized value" reports remaining. Maybe use av_mallocz_array? Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/7] lavf: add cue sheet demuxer
---
Changelog| 2 +
doc/demuxers.texi| 17
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/cuedec.c | 246 +++
libavformat/version.h| 2 +-
6 files changed, 268 insertions(+), 1 deletion(-)
create mode 100644 libavformat/cuedec.c
diff --git a/Changelog b/Changelog
index 187ae79..6701d30 100644
--- a/Changelog
+++ b/Changelog
@@ -29,6 +29,8 @@ version :
- limiter video filter
- libvmaf video filter
- Dolby E decoder and SMPTE 337M demuxer
+- Cue sheet demuxer
+
version 3.3:
- CrystalHD decoder moved to new decode API
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 29a23d4..04eaf27 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -244,6 +244,23 @@ file subdir/file-2.wav
@end example
@end itemize
+@section cue
+
+Cue sheet demuxer.
+
+This demuxer reads a cue sheet (text file) and exports its track listing in
+the form of AVChapters. Packet data is read from the file listed in the sheet,
+which must be in the same directory. To override the path the packet data is
+read from, use the @code{url} option.
+
+This demuxer currently only supports cue sheets with a single audio file.
+
+This demuxer can be used along with the segment muxer to split a cue+audio pair
+into individual files for the different tracks:
+@example
+ffmpeg -i input.cue -f segment -segment_chapters 1 '%02d $artist$ -
$title$.flac'
+@end example
+
@section flv, live_flv
Adobe Flash Video Format demuxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index b0ef82c..4381c42 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -130,6 +130,7 @@ OBJS-$(CONFIG_CDXL_DEMUXER) += cdxl.o
OBJS-$(CONFIG_CINE_DEMUXER) += cinedec.o
OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
+OBJS-$(CONFIG_CUE_DEMUXER) += cuedec.o
OBJS-$(CONFIG_DATA_DEMUXER) += rawdec.o
OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
OBJS-$(CONFIG_DASH_MUXER)+= dashenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 1ebc142..25afa8b 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -96,6 +96,7 @@ static void register_all(void)
REGISTER_DEMUXER (CINE, cine);
REGISTER_DEMUXER (CONCAT, concat);
REGISTER_MUXER (CRC, crc);
+REGISTER_DEMUXER (CUE, cue);
REGISTER_MUXER (DASH, dash);
REGISTER_MUXDEMUX(DATA, data);
REGISTER_MUXDEMUX(DAUD, daud);
diff --git a/libavformat/cuedec.c b/libavformat/cuedec.c
new file mode 100644
index 000..11b256d
--- /dev/null
+++ b/libavformat/cuedec.c
@@ -0,0 +1,246 @@
+/*
+ * Cue sheet demuxer
+ * Copyright (c) 2016 The FFmpeg Project
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Cue sheet demuxer
+ * @author Rodger Combs
+ */
+
+#include "avformat.h"
+#include "internal.h"
+#include "subtitles.h"
+#include "url.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+
+typedef struct CueDemuxContext {
+AVClass *class;
+char *url;
+AVFormatContext *avf;
+} CueDemuxContext;
+
+static int cue_probe(AVProbeData *p)
+{
+const unsigned char *ptr = p->buf;
+int has_file = 0, has_track = 0;
+
+if (AV_RB24(ptr) == 0xEFBBBF)
+ptr += 3; /* skip UTF-8 BOM */
+while (*ptr && (!has_file || !has_track)) {
+while (*ptr == ' ' || *ptr == '\t')
+ptr++;
+if (!strncmp(ptr, "FILE ", 5)) {
+ptr += 5;
+while (*ptr == ' ' || *ptr == '\t')
+ptr++;
+if (*ptr == '"')
+has_file = 1;
+} else if (!strncmp(ptr, "TRACK ", 6)) {
+ptr += 6;
+while (*ptr == ' ' || *ptr == '\t')
+ptr++;
+if (!av_isdigit(*ptr))
+return 0;
+while (av_isdigit(*ptr))
+ptr++;
+if (*ptr != ' ' && *ptr != '\t')
+return 0;
+while (*ptr == ' ' || *ptr == '\t')
+ptr++;
+
[FFmpeg-devel] [PATCH 4/7] lavf/segment: write attached pictures to all segments by default
---
doc/muxers.texi | 4
libavformat/segment.c | 40 +---
2 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 23ef2e7..93147e1 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1576,6 +1576,10 @@ argument must be a time duration specification, and
defaults to 0.
If enabled, write an empty segment if there are no packets during the period a
segment would usually span. Otherwise, the segment will be filled with the next
packet written. Defaults to @code{0}.
+
+@item dup_attached_pics @var{1|0}
+If enabled, attached-picture packets will be written to all segments, rather
+than only the first. Defaults to @code{1}.
@end table
@subsection Examples
diff --git a/libavformat/segment.c b/libavformat/segment.c
index ef0a915..632476e 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -119,6 +119,7 @@ typedef struct SegmentContext {
int reference_stream_index;
int break_non_keyframes;
int write_empty;
+int dup_attached_pics;
int use_rename;
char temp_list_filename[1024];
@@ -126,6 +127,8 @@ typedef struct SegmentContext {
SegmentListEntry cur_entry;
SegmentListEntry *segment_list_entries;
SegmentListEntry *segment_list_entries_end;
+
+AVPacket *attached_pics;
} SegmentContext;
static void print_csv_escaped_str(AVIOContext *ctx, const char *str)
@@ -193,16 +196,15 @@ static int replace_variables(AVFormatContext *oc)
{
char name[sizeof(oc->filename)];
char *p = name;
-char *out = oc->filename;
+AVBPrint bprint;
strncpy(name, oc->filename, sizeof(name));
+av_bprint_init_for_buffer(&bprint, oc->filename, sizeof(oc->filename));
while (*p) {
char c = *p++;
if (c == '$') {
if (*p == '$') {
-p++;
-goto append;
+av_bprint_chars(&bprint, c, 1);
} else {
-int len;
const char *val;
const AVDictionaryEntry *e;
int end = strcspn(p, "$");
@@ -211,18 +213,13 @@ static int replace_variables(AVFormatContext *oc)
p[end] = '\0';
e = av_dict_get(oc->metadata, p, NULL, 0);
val = e ? e->value : "(unknown)";
-len = strlen(val);
-strncpy(out, val, oc->filename + sizeof(oc->filename) - 1 -
out);
-out = FFMIN(oc->filename + sizeof(oc->filename) - 1, out +
len);
+av_bprint_append_data(&bprint, val, strlen(val));
p += end + 1;
}
} else {
-append:
-if (out - oc->filename < sizeof(oc->filename) - 1)
-*out++ = c;
+av_bprint_chars(&bprint, c, 1);
}
}
-*out = '\0';
return 0;
}
@@ -301,6 +298,7 @@ static int segment_start(AVFormatContext *s, int
write_header)
av_opt_set(oc->priv_data, "mpegts_flags", "+resend_headers", 0);
if (write_header) {
+int i;
AVDictionary *options = NULL;
av_dict_copy(&options, seg->format_options, 0);
av_dict_set(&options, "fflags", "-autobsf", 0);
@@ -308,6 +306,13 @@ static int segment_start(AVFormatContext *s, int
write_header)
av_dict_free(&options);
if (err < 0)
return err;
+for (i = 0; i < s->nb_streams; i++) {
+if (seg->dup_attached_pics &&
+s->streams[i]->disposition & AV_DISPOSITION_ATTACHED_PIC &&
+seg->attached_pics[i].data) {
+av_write_frame(oc, &seg->attached_pics[i]);
+}
+}
}
seg->segment_frame_count = 0;
@@ -680,6 +685,12 @@ static void seg_free(AVFormatContext *s)
ff_format_io_close(seg->avf, &seg->list_pb);
avformat_free_context(seg->avf);
seg->avf = NULL;
+if (seg->attached_pics) {
+int i;
+for (i = 0; i < s->nb_streams; i++)
+av_packet_unref(&seg->attached_pics[i]);
+av_freep(&seg->attached_pics);
+}
}
static int seg_init(AVFormatContext *s)
@@ -840,6 +851,9 @@ static int seg_init(AVFormatContext *s)
avpriv_set_pts_info(outer_st, inner_st->pts_wrap_bits,
inner_st->time_base.num, inner_st->time_base.den);
}
+if (seg->dup_attached_pics && !(seg->attached_pics =
av_calloc(s->nb_streams, sizeof(AVPacket
+return AVERROR(ENOMEM);
+
if (oc->avoid_negative_ts > 0 && s->avoid_negative_ts < 0)
s->avoid_negative_ts = 1;
@@ -905,6 +919,9 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
if (!seg->avf || !seg->avf->pb)
return AVERROR(EINVAL);
+if (seg->dup_attached_pics && st->disposition &
AV_DISPOSITION_ATTACHED_PIC)
+av_copy_packet(&seg->attached_pics[pkt->stream_index], pkt);
+
calc_times:
if (seg->times) {
end_pts = seg->segment_count < seg->nb_times ?
@@ -,6 +1128,7
[FFmpeg-devel] [PATCH 2/7] lavf/segment: add option to segment by chapter
---
doc/muxers.texi | 6 +
libavformat/segment.c | 65 +++
libavformat/version.h | 2 +-
3 files changed, 67 insertions(+), 6 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 94472ce..23ef2e7 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1538,6 +1538,12 @@ This option specifies to start a new segment whenever a
reference
stream key frame is found and the sequential number (starting from 0)
of the frame is greater or equal to the next value in the list.
+@item segment_chapters @var{1|0}
+Split each chapter into its own segment. Metadata from the chapters
+will be written to the corresponding segments. If this option is selected
+and the filename contains tokens in the format @code{$varname$}, they
+will be replaced by the corresponding metadata values.
+
@item segment_wrap @var{limit}
Wrap around segment index once it reaches @var{limit}.
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 0e8bcdd..590f62b 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -106,6 +106,8 @@ typedef struct SegmentContext {
int frame_count; ///< total number of reference frames
int segment_frame_count; ///< number of reference frames in the segment
+int split_chapters;///< split on chapter markers
+
int64_t time_delta;
int individual_header_trailer; /**< Set by a private option. */
int write_header_trailer; /**< Set by a private option. */
@@ -186,6 +188,43 @@ static int segment_mux_init(AVFormatContext *s)
return 0;
}
+static int replace_variables(AVFormatContext *oc)
+{
+char name[sizeof(oc->filename)];
+char *p = name;
+char *out = oc->filename;
+strncpy(name, oc->filename, sizeof(name));
+while (*p) {
+char c = *p++;
+if (c == '$') {
+if (*p == '$') {
+p++;
+goto append;
+} else {
+int len;
+const char *val;
+const AVDictionaryEntry *e;
+int end = strcspn(p, "$");
+if (p[end] == '\0')
+continue;
+p[end] = '\0';
+e = av_dict_get(oc->metadata, p, NULL, 0);
+val = e ? e->value : "(unknown)";
+len = strlen(val);
+strncpy(out, val, oc->filename + sizeof(oc->filename) - 1 -
out);
+out = FFMIN(oc->filename + sizeof(oc->filename) - 1, out +
len);
+p += end + 1;
+}
+} else {
+append:
+if (out - oc->filename < sizeof(oc->filename) - 1)
+*out++ = c;
+}
+}
+*out = '\0';
+return 0;
+}
+
static int set_segment_filename(AVFormatContext *s)
{
SegmentContext *seg = s->priv_data;
@@ -210,6 +249,9 @@ static int set_segment_filename(AVFormatContext *s)
return AVERROR(EINVAL);
}
+if (seg->split_chapters)
+replace_variables(oc);
+
/* copy modified name in list entry */
size = strlen(av_basename(oc->filename)) + 1;
if (seg->entry_prefix)
@@ -236,6 +278,8 @@ static int segment_start(AVFormatContext *s, int
write_header)
if ((err = segment_mux_init(s)) < 0)
return err;
oc = seg->avf;
+if (seg->split_chapters && seg->segment_count < s->nb_chapters && (err
= av_dict_copy(&oc->metadata, s->chapters[seg->segment_count]->metadata, 0)) <
0)
+return err;
}
seg->segment_idx++;
@@ -659,10 +703,14 @@ static int seg_init(AVFormatContext *s)
"you can use output_ts_offset instead of it\n");
}
-if (!!seg->time_str + !!seg->times_str + !!seg->frames_str > 1) {
+if (seg->segment_idx < 0)
+seg->segment_idx = seg->split_chapters;
+
+if (!!seg->time_str + !!seg->times_str + !!seg->frames_str +
!!seg->split_chapters > 1) {
av_log(s, AV_LOG_ERROR,
- "segment_time, segment_times, and segment_frames options "
- "are mutually exclusive, select just one of them\n");
+ "segment_time, segment_times, segment_frames, and "
+ "segment_chapters options are mutually exclusive; "
+ "select just one of them\n");
return AVERROR(EINVAL);
}
@@ -672,7 +720,7 @@ static int seg_init(AVFormatContext *s)
} else if (seg->frames_str) {
if ((ret = parse_frames(s, &seg->frames, &seg->nb_frames,
seg->frames_str)) < 0)
return ret;
-} else {
+} else if (!seg->split_chapters) {
/* set default value if not specified */
if (!seg->time_str)
seg->time_str = av_strdup("2");
@@ -739,6 +787,9 @@ static int seg_init(AVFormatContext *s)
if ((ret = segment_mux_init(s)) < 0)
return ret;
+if (seg->split_chapters && s->nb_chapters && (ret =
av_dict_copy(&seg->avf->metadata, s->chapters[0]->metadata, 0)) < 0)
+return ret;
+
[FFmpeg-devel] [PATCH 3/7] lavf/segment: copy stream dispositions in output
--- libavformat/segment.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/segment.c b/libavformat/segment.c index 590f62b..ef0a915 100644 --- a/libavformat/segment.c +++ b/libavformat/segment.c @@ -182,6 +182,7 @@ static int segment_mux_init(AVFormatContext *s) } st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio; st->time_base = s->streams[i]->time_base; +st->disposition = s->streams[i]->disposition; av_dict_copy(&st->metadata, s->streams[i]->metadata, 0); } -- 2.6.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/7] lavf/flacenc: avoid buffer overread with unexpected extradata sizes
---
libavformat/flacenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index 9768b6a..1906aee 100644
--- a/libavformat/flacenc.c
+++ b/libavformat/flacenc.c
@@ -322,7 +322,7 @@ static int flac_write_trailer(struct AVFormatContext *s)
if (!c->write_header || !streaminfo)
return 0;
-if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
+if (pb->seekable & AVIO_SEEKABLE_NORMAL && (c->streaminfo ||
s->streams[0]->codecpar->extradata_size == FLAC_STREAMINFO_SIZE)) {
/* rewrite the STREAMINFO header block data */
file_size = avio_tell(pb);
avio_seek(pb, 8, SEEK_SET);
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/7] lavf/flacenc: support writing attached pictures
---
libavformat/flacenc.c | 285 +++---
1 file changed, 250 insertions(+), 35 deletions(-)
diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index b894f9e..9768b6a 100644
--- a/libavformat/flacenc.c
+++ b/libavformat/flacenc.c
@@ -21,10 +21,13 @@
#include "libavutil/channel_layout.h"
#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
#include "libavcodec/flac.h"
#include "avformat.h"
#include "avio_internal.h"
#include "flacenc.h"
+#include "id3v2.h"
+#include "internal.h"
#include "vorbiscomment.h"
#include "libavcodec/bytestream.h"
@@ -33,8 +36,16 @@ typedef struct FlacMuxerContext {
const AVClass *class;
int write_header;
+int audio_stream_idx;
+AVPacket *pics;
+int nb_pics, waiting_pics;
+/* audio packets are queued here until we get all the attached pictures */
+AVPacketList *queue, *queue_end;
+
/* updated streaminfo sent by the encoder at the end */
uint8_t *streaminfo;
+
+unsigned attached_types;
} FlacMuxerContext;
static int flac_write_block_padding(AVIOContext *pb, unsigned int
n_padding_bytes,
@@ -74,31 +85,156 @@ static int flac_write_block_comment(AVIOContext *pb,
AVDictionary **m,
return 0;
}
-static int flac_write_header(struct AVFormatContext *s)
+static int flac_write_picture(struct AVFormatContext *s, AVPacket *pkt)
{
-int ret;
-int padding = s->metadata_header_padding;
-AVCodecParameters *par = s->streams[0]->codecpar;
-FlacMuxerContext *c = s->priv_data;
-
-if (!c->write_header)
+FlacMuxerContext *c = s->priv_data;
+AVIOContext *pb = s->pb;
+const AVPixFmtDescriptor *pixdesc;
+const CodecMime *mime = ff_id3v2_mime_tags;
+AVDictionaryEntry *e;
+const char *mimetype = NULL, *desc = "";
+const AVStream *st = s->streams[pkt->stream_index];
+int i, mimelen, desclen, type = 0;
+
+if (!pkt->data)
return 0;
-if (s->nb_streams > 1) {
-av_log(s, AV_LOG_ERROR, "only one stream is supported\n");
+while (mime->id != AV_CODEC_ID_NONE) {
+if (mime->id == st->codecpar->codec_id) {
+mimetype = mime->str;
+break;
+}
+mime++;
+}
+if (!mimetype) {
+av_log(s, AV_LOG_ERROR, "No mimetype is known for stream %d, cannot "
+ "write an attached picture.\n", st->index);
return AVERROR(EINVAL);
}
-if (par->codec_id != AV_CODEC_ID_FLAC) {
-av_log(s, AV_LOG_ERROR, "unsupported codec\n");
+mimelen = strlen(mimetype);
+
+/* get the picture type */
+e = av_dict_get(st->metadata, "comment", NULL, 0);
+for (i = 0; e && i < FF_ARRAY_ELEMS(ff_id3v2_picture_types); i++) {
+if (!av_strcasecmp(e->value, ff_id3v2_picture_types[i])) {
+type = i;
+break;
+}
+}
+
+if ((c->attached_types & (1 << type)) & 0x6) {
+av_log(s, AV_LOG_ERROR, "Duplicate attachment for type '%s'\n",
ff_id3v2_picture_types[type]);
+return AVERROR(EINVAL);
+}
+
+if (type == 1 && (st->codecpar->codec_id != AV_CODEC_ID_PNG ||
+ st->codecpar->width != 32 ||
+ st->codecpar->height != 32)) {
+av_log(s, AV_LOG_ERROR, "File icon attachment must be a 32x32 PNG");
return AVERROR(EINVAL);
}
+c->attached_types |= (1 << type);
+
+/* get the description */
+if ((e = av_dict_get(st->metadata, "title", NULL, 0)))
+desc = e->value;
+desclen = strlen(desc);
+
+avio_w8(pb, 0x06);
+avio_wb24(pb, 4 + 4 + mimelen + 4 + desclen + 4 + 4 + 4 + 4 + 4 +
pkt->size);
+
+avio_wb32(pb, type);
+
+avio_wb32(pb, mimelen);
+avio_write(pb, mimetype, mimelen);
+
+avio_wb32(pb, desclen);
+avio_write(pb, desc, desclen);
+
+avio_wb32(pb, st->codecpar->width);
+avio_wb32(pb, st->codecpar->height);
+if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
+avio_wb32(pb, av_get_bits_per_pixel(pixdesc));
+else
+avio_wb32(pb, 0);
+avio_wb32(pb, 0);
+
+avio_wb32(pb, pkt->size);
+avio_write(pb, pkt->data, pkt->size);
+return 0;
+}
+
+static int flac_finish_header(struct AVFormatContext *s)
+{
+FlacMuxerContext *c = s->priv_data;
+int i, ret, padding = s->metadata_header_padding;
if (padding < 0)
padding = 8192;
/* The FLAC specification states that 24 bits are used to represent the
* size of a metadata block so we must clip this value to 2^24-1. */
padding = av_clip_uintp2(padding, 24);
+for (i = 0; i < c->nb_pics; i++) {
+ret = flac_write_picture(s, &c->pics[i]);
+if (ret)
+return ret;
+}
+
+ret = flac_write_block_comment(s->pb, &s->metadata, !padding,
+ s->flags & AVFMT_FLAG_BITEXACT);
+if (ret)
+return ret;
+
+/* The command line flac encoder defaults to placing a seekpoint
+ * every 10s. So one
[FFmpeg-devel] [PATCH 7/7] lavf/flacenc: generate timestamps internally
---
libavformat/flacenc.c| 87 ++--
tests/ref/acodec/flac| 4 +-
tests/ref/acodec/flac-exact-rice | 4 +-
tests/ref/seek/acodec-flac | 36 -
4 files changed, 106 insertions(+), 25 deletions(-)
diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index 1906aee..39e5e2c 100644
--- a/libavformat/flacenc.c
+++ b/libavformat/flacenc.c
@@ -30,6 +30,7 @@
#include "internal.h"
#include "vorbiscomment.h"
#include "libavcodec/bytestream.h"
+#include "libavutil/crc.h"
typedef struct FlacMuxerContext {
@@ -46,6 +47,8 @@ typedef struct FlacMuxerContext {
uint8_t *streaminfo;
unsigned attached_types;
+
+uint64_t samples;
} FlacMuxerContext;
static int flac_write_block_padding(AVIOContext *pb, unsigned int
n_padding_bytes,
@@ -263,11 +266,17 @@ static int flac_write_header(struct AVFormatContext *s)
return ret;
}
+static const int32_t blocksize_table[16] = {
+ 0,192, 576<<0, 576<<1, 576<<2, 576<<3, 0, 0,
+256<<0, 256<<1, 256<<2, 256<<3, 256<<4, 256<<5, 256<<6, 256<<7
+};
+
static int flac_write_audio_packet(struct AVFormatContext *s, AVPacket *pkt)
{
FlacMuxerContext *c = s->priv_data;
uint8_t *streaminfo;
int streaminfo_size;
+char header[16];
/* check for updated streaminfo */
streaminfo = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
@@ -281,8 +290,77 @@ static int flac_write_audio_packet(struct AVFormatContext
*s, AVPacket *pkt)
memcpy(c->streaminfo, streaminfo, FLAC_STREAMINFO_SIZE);
}
-if (pkt->size)
-avio_write(s->pb, pkt->data, pkt->size);
+if (pkt->size) {
+uint8_t tmp;
+uint64_t pts = c->samples;
+int offset = 5;
+int headerlen = 4;
+int bscode, bs;
+int crc;
+if (pkt->size < FLAC_MIN_FRAME_SIZE)
+return AVERROR_INVALIDDATA;
+memcpy(header, pkt->data, 4);
+if (pkt->pts == AV_NOPTS_VALUE)
+pts = 0;
+if ((pkt->data[4] & 0xC0) == 0xC0)
+offset += ff_clz((unsigned char)~pkt->data[4]) - 25;
+else if (pkt->data[4] & 0x80)
+return AVERROR_INVALIDDATA;
+if (pkt->size <= offset + 1)
+return AVERROR_INVALIDDATA;
+
+// Forcing use of sample counts instead of block counts to avoid bs
+// mismatch issues
+header[1] |= 1;
+
+bscode = (unsigned char)header[2] >> 4;
+bs = blocksize_table[bscode];
+if (bscode == 0)
+return AVERROR_INVALIDDATA;
+if (bscode == 6) {
+if (pkt->size <= offset + 1)
+return AVERROR_INVALIDDATA;
+bs = pkt->data[offset] + 1;
+} else if (bscode == 7) {
+if (pkt->size <= offset + 2)
+return AVERROR_INVALIDDATA;
+bs = AV_RB16(&pkt->data[offset]) + 1;
+}
+
+c->samples += bs;
+
+PUT_UTF8(pts, tmp, header[headerlen++] = tmp;)
+if (headerlen > 11)
+return AVERROR_INVALIDDATA;
+if ((bscode & 0xE) == 0x6)
+header[headerlen++] = pkt->data[offset++];
+if (pkt->size <= offset + 1)
+return AVERROR_INVALIDDATA;
+if (bscode == 0x7)
+header[headerlen++] = pkt->data[offset++];
+if (pkt->size <= offset + 1)
+return AVERROR_INVALIDDATA;
+if ((header[2] & 0xC) == 0xC) {
+header[headerlen++] = pkt->data[offset++];
+if (pkt->size <= offset + 1)
+return AVERROR_INVALIDDATA;
+if ((header[2] & 0x3) == 0x3)
+return AVERROR_INVALIDDATA;
+else if (header[2] & 0x3) {
+header[headerlen++] = pkt->data[offset++];
+if (pkt->size <= offset + 1)
+return AVERROR_INVALIDDATA;
+}
+}
+header[headerlen] = av_crc(av_crc_get_table(AV_CRC_8_ATM), 0, header,
headerlen);
+headerlen++; offset++;
+crc = av_crc(av_crc_get_table(AV_CRC_16_ANSI), 0, header, headerlen);
+if (pkt->size < offset + 3)
+return AVERROR_INVALIDDATA;
+avio_write(s->pb, header, headerlen);
+avio_write(s->pb, pkt->data + offset, pkt->size - offset - 2);
+avio_wl16(s->pb, av_crc(av_crc_get_table(AV_CRC_16_ANSI), crc,
pkt->data + offset, pkt->size - offset - 2));
+}
return 0;
}
@@ -326,7 +404,10 @@ static int flac_write_trailer(struct AVFormatContext *s)
/* rewrite the STREAMINFO header block data */
file_size = avio_tell(pb);
avio_seek(pb, 8, SEEK_SET);
-avio_write(pb, streaminfo, FLAC_STREAMINFO_SIZE);
+avio_write(pb, streaminfo, 13);
+avio_w8(pb, (streaminfo[13] & 0xF0) | ((c->samples >> 32) & 0xF));
+avio_wb32(pb, c->samples);
+avio_write(pb, streaminfo + 18, FLAC_STREAMINFO_SIZE - 18);
avio_seek(pb, file_size, SEEK_SE
[FFmpeg-devel] version 3: V4L2 M2M codecs
The following patchset adds support for V4L2 mem2mem codecs.
This feature gives ffmpeg access to any hardware codec implementing the
V4L2 API. Since the number of hardware codecs implementing this API is
expected to increase, we believe it will be benefitial to all users to
integrate its support in the ffmpeg project.
These patches were originally posted by Alexis Ballier back in 2014
and since then they have been reviewed and tested further in different
platforms.
v2 -> v3:
rebased on ffmpeg/master [1193301758]
fixes make install
renames v4l2_* files
* [PATCHv3 1/4] Move lavd/v4l2-common.* to lavc
* [PATCHv3 2/4] libavcodec: v4l2: add pack_flags to the conversion tables
* [PATCHv3 3/4] libavcodec: v4l2: add codec formats
* [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
compat/v4l2/v4l2-common.h| 107
compat/v4l2/v4l2-controls.h | 987
+
compat/v4l2/videodev2.h | 2402
++
configure| 26 ++-
libavcodec/Makefile | 18 +-
libavcodec/allcodecs.c |9 +
libavcodec/v4l2_buffers.c| 614
libavcodec/v4l2_buffers.h| 226 +
libavcodec/{v4l2-common.c => v4l2_fmt.c} | 56 ---
libavcodec/{v4l2-common.h => v4l2_fmt.h} |8 +-
libavcodec/v4l2_m2m.c| 356
libavcodec/v4l2_m2m.h| 69
libavcodec/v4l2_m2m_avcodec.h| 32
libavcodec/v4l2_m2m_dec.c| 229 ++
libavcodec/v4l2_m2m_enc.c| 270 ++
libavdevice/v4l2.c |2 +-
libavdevice/v4l2enc.c|2 +
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3 1/4] Move lavd/v4l2-common.* to lavc
From: Alexis Ballier
In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez-Ortiz
---
configure | 6 ++-
libavcodec/Makefile | 1 +
libavcodec/v4l2-common.c | 105 ++
libavcodec/v4l2-common.h | 57 +
libavdevice/Makefile | 6 +--
libavdevice/v4l2-common.c | 105 --
libavdevice/v4l2-common.h | 61 ---
libavdevice/v4l2.c| 40 --
libavdevice/v4l2enc.c | 14 +--
9 files changed, 207 insertions(+), 188 deletions(-)
create mode 100644 libavcodec/v4l2-common.c
create mode 100644 libavcodec/v4l2-common.h
delete mode 100644 libavdevice/v4l2-common.c
delete mode 100644 libavdevice/v4l2-common.h
diff --git a/configure b/configure
index 66c7b94..ed94de0 100755
--- a/configure
+++ b/configure
@@ -1671,6 +1671,7 @@ SUBSYSTEM_LIST="
pixelutils
network
rdft
+v4l2
"
# COMPONENT_LIST needs to come last to ensure correct dependency checking
@@ -2268,6 +2269,7 @@ map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
loongson2_deps="mips"
loongson3_deps="mips"
+v4l2_deps_any="linux_videodev2_h sys_videoio_h"
mipsfpu_deps="mips"
mipsdsp_deps="mips"
mipsdspr2_deps="mips"
@@ -3041,8 +3043,8 @@ sdl2_outdev_deps="sdl2"
sndio_indev_deps="sndio"
sndio_outdev_deps="sndio"
v4l_indev_deps="linux_videodev_h"
-v4l2_indev_deps_any="linux_videodev2_h sys_videoio_h"
-v4l2_outdev_deps_any="linux_videodev2_h sys_videoio_h"
+v4l2_indev_select="v4l2"
+v4l2_outdev_select="v4l2"
vfwcap_indev_deps="vfw32 vfwcap_defines"
xcbgrab_indev_deps="libxcb"
xv_outdev_deps="X11_extensions_Xvlib_h XvGetPortAttribute"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b0c39ac..364aec9 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -101,6 +101,7 @@ OBJS-$(CONFIG_LZF) += lzf.o
OBJS-$(CONFIG_MDCT)+= mdct_fixed.o mdct_float.o
mdct_fixed_32.o
OBJS-$(CONFIG_ME_CMP) += me_cmp.o
OBJS-$(CONFIG_MEDIACODEC) += mediacodecdec_common.o
mediacodec_surface.o mediacodec_wrapper.o mediacodec_sw_buffer.o
+OBJS-$(CONFIG_V4L2)+= v4l2-common.o
OBJS-$(CONFIG_MPEG_ER) += mpeg_er.o
OBJS-$(CONFIG_MPEGAUDIO) += mpegaudio.o
OBJS-$(CONFIG_MPEGAUDIODSP)+= mpegaudiodsp.o\
diff --git a/libavcodec/v4l2-common.c b/libavcodec/v4l2-common.c
new file mode 100644
index 000..884101d
--- /dev/null
+++ b/libavcodec/v4l2-common.c
@@ -0,0 +1,105 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "v4l2-common.h"
+
+const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] = {
+//ff_fmt codec_id v4l2_fmt
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420 },
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420 },
+{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P },
+{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV},
+{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY},
+{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410 },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410 },
+{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555 },
+{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X },
+{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565 },
+{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X },
+{ AV_PIX_FMT_BGR24, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24 },
+{ AV_PIX_FMT_RGB24, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24 },
+{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32 },
+{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32 },
+{ AV_PIX_FMT_GRAY8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY},
+#ifdef V4L2_PIX_FMT_Y16
+{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWV
[FFmpeg-devel] [PATCHv3 3/4] libavcodec: v4l2: add codec formats
From: Alexis Ballier
In addition, enable the multi planar raw formats.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2-common.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavcodec/v4l2-common.c b/libavcodec/v4l2-common.c
index 815a5c4..13744fb 100644
--- a/libavcodec/v4l2-common.c
+++ b/libavcodec/v4l2-common.c
@@ -58,6 +58,36 @@ const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] =
{
{ AV_PIX_FMT_BAYER_GRBG8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_SGRBG8 ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
{ AV_PIX_FMT_BAYER_RGGB8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_SRGGB8 ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
#endif
+#ifdef V4L2_PIX_FMT_NV12M
+{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12M ,
FF_V4L_PACK_AVFRAME },
+#endif
+#ifdef V4L2_PIX_FMT_NV21M
+{ AV_PIX_FMT_NV21,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV21M ,
FF_V4L_PACK_AVFRAME },
+#endif
+#ifdef V4L2_PIX_FMT_YUV420M
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420M,
FF_V4L_PACK_AVFRAME },
+#endif
+#ifdef V4L2_PIX_FMT_NV16M
+{ AV_PIX_FMT_NV16,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV16M ,
FF_V4L_PACK_AVFRAME },
+#endif
+#ifdef V4L2_PIX_FMT_DV
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_DVVIDEO, V4L2_PIX_FMT_DV ,
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_H263
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_H263, V4L2_PIX_FMT_H263 ,
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_MPEG1
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG1VIDEO, V4L2_PIX_FMT_MPEG1,
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_MPEG2
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG2VIDEO, V4L2_PIX_FMT_MPEG2,
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_VC1_ANNEX_G
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_VC1, V4L2_PIX_FMT_VC1_ANNEX_G,
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_VP8
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_VP8, V4L2_PIX_FMT_VP8,
FF_V4L_PACK_AVPACKET },
+#endif
{ AV_PIX_FMT_NONE,AV_CODEC_ID_NONE, 0},
};
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3 2/4] libavcodec: v4l2: add pack_flags to the conversion tables
From: Alexis Ballier
Extend the mapping function to use the v4l2 conversion tables.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2-common.c | 63
libavcodec/v4l2-common.h | 7 +-
libavdevice/v4l2.c | 2 +-
libavdevice/v4l2enc.c| 2 +-
4 files changed, 40 insertions(+), 34 deletions(-)
diff --git a/libavcodec/v4l2-common.c b/libavcodec/v4l2-common.c
index 884101d..815a5c4 100644
--- a/libavcodec/v4l2-common.c
+++ b/libavcodec/v4l2-common.c
@@ -19,49 +19,49 @@
#include "v4l2-common.h"
const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] = {
-//ff_fmt codec_id v4l2_fmt
-{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420 },
-{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420 },
-{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P },
-{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV},
-{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY},
-{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P },
-{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410 },
-{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410 },
-{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555 },
-{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X },
-{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565 },
-{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X },
-{ AV_PIX_FMT_BGR24, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24 },
-{ AV_PIX_FMT_RGB24, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24 },
-{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32 },
-{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32 },
-{ AV_PIX_FMT_GRAY8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY},
+//ff_fmt codec_id v4l2_fmt
pack_flags
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420 ,
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420 ,
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P,
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P,
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410 ,
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410 ,
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555 ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565 ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_BGR24, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24 ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB24, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24 ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32 ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32 ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_GRAY8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY ,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
#ifdef V4L2_PIX_FMT_Y16
-{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16 },
+{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16,
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
#endif
-{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12},
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_MJPEG },
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_JPEG},
+{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12 ,
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_MJPEG ,
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_JPEG ,
FF_V4L_PACK_AVPACKET },
#ifdef V4L2_PIX_FMT_H264
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264},
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264 ,
FF_V4L_PACK_AVPACKET },
#endif
#ifdef V4L2_PIX_FMT_MPEG4
-{ AV_PIX_FMT_NONE,AV_CODEC_I
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: > From: Alexis Ballier > > This patchset enhances Alexis Ballier's original patch and validates > it using Qualcomm's Venus hardware (driver recently landed upstream > [1]). > > This has been tested on Qualcomm's DragonBoard 410c and 820c > > Tested decoders: >- h264 >- mpeg4 >- vp8 >- vp9 >- hevc > > Tested encoders: >-h264 >-h263 >-mpeg4 > > Tested transcoding (concurrent encoding/decoding) > > Some of the changes introduced: > - v4l2: code cleanup. > - v4l2: follow the decode api. > - v4l2: fix display size for NV12 output pool. > - v4l2: handle EOS. > - v4l2: vp8 and mpeg4 decoding. > - v4l2: hevc and vp9 support. > - v4l2: generate EOF on dequeue errors. > - v4l2: h264_mp4toannexb filtering. > - v4l2: import compat/v4l2 header files. > > [1] https://lwn.net/Articles/697956/ > > Reviewed-by: Jorge Ramirez > Reviewed-by: Alexis Ballier > Tested-by: Jorge Ramirez > --- > Changelog |3 +- > compat/v4l2/v4l2-common.h | 107 ++ > compat/v4l2/v4l2-controls.h | 987 + > compat/v4l2/videodev2.h | 2402 > + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. On a system with a recent enough kernel to run this, you would also have matching headers, so IMHO this should behave like any external library dependency and just check that the headers are recent enough to build our code, and just skip building the module otherwise. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add unpremultiply filter
On 01.08.2017 17:33, Paul B Mahol wrote: On 8/1/17, Tobias Rapp wrote: On 01.08.2017 15:31, Paul B Mahol wrote: On 8/1/17, Tobias Rapp wrote: On 01.08.2017 13:03, Paul B Mahol wrote: Signed-off-by: Paul B Mahol --- doc/filters.texi | 13 ++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_premultiply.c | 307 --- 4 files changed, 277 insertions(+), 45 deletions(-) diff --git a/doc/filters.texi b/doc/filters.texi index 4089135..a50696a 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -14532,6 +14532,19 @@ ffmpeg -i INPUT -vf trim=duration=1 @end itemize +@section unpremultiply +Apply alpha unpremultiply effect to input video stream using first plane +of second stream as alpha. + +Both streams must have same dimensions and same pixel format. + +The filter accepts the following option: + +@table @option +@item planes +Set which planes will be processed, unprocessed planes will be copied. +By default value 0xf, all planes will be processed. +@end table IMHO using a flags-like string "planes=rgb" would be more user-friendly than a bitmask. At least the documentation should tell which bit refers to what channel. It is directly related to pixel format. I'm just wondering whether I can apply the logic of AVPixFmtDescriptor.comp to the planes bitmask or not: /** * Parameters that describe how pixels are packed. * If the format has 1 or 2 components, then luma is 0. * If the format has 3 or 4 components: * if the RGB flag is set then 0 is red, 1 is green and 2 is blue; * otherwise 0 is luma, 1 is chroma-U and 2 is chroma-V. * * If present, the Alpha channel is always the last component. */ I mainly did it bitmask way because of additional code needed to handle cases when there is no r/g/b but y/u/v planes and user supplied r/g/b only. Indeed a bitmask is more generic. I'm not against it but think that there should be some more details in the user documentation on how to map the bits to planes. For example (in case the code comment above applies) something like: """ If the format has 1 or 2 components, then luma is bit 0. If the format has 3 or 4 components: for RGB formats bit 0 is red, bit 1 is green and bit 2 is blue; for YUV formats bit 0 is luma, bit 1 is chroma-U and bit 2 is chroma-V. If present, the alpha channel is always the last bit. """ Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] speedhq: fix behavior of single-field decoding
On Wed, Aug 02, 2017 at 03:18:49AM +0200, Michael Niedermayer wrote: > This seems to break a full "make fate" OK, removing the offending line and resending. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 1/3] speedhq: fix behavior of single-field decoding
The height convention for decoding frames with only a single field made sense
for compatibility with legacy decoders, but doesn't really match the convention
used by NDI, which is the primary (only?) user. Thus, change it to simply
assuming that if the two fields overlap, the frame is meant to be a single
field and the frame height matches the field height.
Also add simple FATE tests, based on output produced by the NDI SDK.
---
libavcodec/speedhq.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 60efb0222b..eca45beb67 100644
--- a/libavcodec/speedhq.c
+++ b/libavcodec/speedhq.c
@@ -448,12 +448,15 @@ static int speedhq_decode_frame(AVCodecContext *avctx,
frame->key_frame = 1;
if (second_field_offset == 4) {
-/*
- * Overlapping first and second fields is used to signal
- * encoding only a single field (the second field then comes
- * as a separate, later frame).
- */
-frame->height >>= 1;
+ /*
+* Overlapping first and second fields is used to signal
+* encoding only a single field. In this case, "height"
+* is ambiguous; it could mean either the height of the
+* frame as a whole, or of the field. The former would make
+* more sense for compatibility with legacy decoders,
+* but this matches the convention used in NDI, which is
+* the primary user of this trick.
+*/
if ((ret = decode_speedhq_field(s, buf, buf_size, frame, 0, 4,
buf_size, 1)) < 0)
return ret;
} else {
--
2.13.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 2/3] speedhq: add FATE tests
Also add simple FATE tests, based on output produced by the NDI SDK. --- tests/Makefile | 1 + tests/fate/vcodec.mak | 2 ++ tests/ref/fate/speedhq-422 | 6 ++ tests/ref/fate/speedhq-422-singlefield | 6 ++ 4 files changed, 15 insertions(+) create mode 100644 tests/ref/fate/speedhq-422 create mode 100644 tests/ref/fate/speedhq-422-singlefield diff --git a/tests/Makefile b/tests/Makefile index ab83ae855d..f9b9cf4188 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -164,6 +164,7 @@ include $(SRC_PATH)/tests/fate/qt.mak include $(SRC_PATH)/tests/fate/qtrle.mak include $(SRC_PATH)/tests/fate/real.mak include $(SRC_PATH)/tests/fate/screen.mak +include $(SRC_PATH)/tests/fate/speedhq.mak include $(SRC_PATH)/tests/fate/source.mak include $(SRC_PATH)/tests/fate/subtitles.mak include $(SRC_PATH)/tests/fate/utvideo.mak diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index 8c24510937..0a284ecbb9 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -386,6 +386,8 @@ fate-vsynth%-snow-hpel: ENCOPTS = -qscale 2 \ fate-vsynth%-snow-ll:ENCOPTS = -qscale .001 -pred 1 \ -flags +mv4+qpel +FATE_VCODEC-$(call ALLYES, SPEEDHQ_DECODER) += speedhq + FATE_VCODEC-$(call ENCDEC, SVQ1, MOV) += svq1 fate-vsynth%-svq1: ENCOPTS = -qscale 3 -pix_fmt yuv410p fate-vsynth%-svq1: FMT = mov diff --git a/tests/ref/fate/speedhq-422 b/tests/ref/fate/speedhq-422 new file mode 100644 index 00..7bb0d2388d --- /dev/null +++ b/tests/ref/fate/speedhq-422 @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 112x64 +#sar 0: 0/1 +0, 0, 0,1,14336, 0x9bb6dc6d diff --git a/tests/ref/fate/speedhq-422-singlefield b/tests/ref/fate/speedhq-422-singlefield new file mode 100644 index 00..343c52645c --- /dev/null +++ b/tests/ref/fate/speedhq-422-singlefield @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 112x32 +#sar 0: 0/1 +0, 0, 0,1, 7168, 0x75de4109 -- 2.13.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 3/3] Add myself as speedhq maintainer, per request.
--- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ae0e08d121..ce5e1dae08 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -233,6 +233,7 @@ Codecs: smvjpegdec.c Ash Hughes snow* Michael Niedermayer, Loren Merritt sonic.c Alex Beregszaszi + speedhq.c Steinar H. Gunderson srt* Aurelien Jacobs sunrast.c Ivo van Poorten svq3.cMichael Niedermayer @@ -598,6 +599,7 @@ Reynaldo H. Verdejo Pinochet 6E27 CD34 170C C78E 4D4F 5F40 C18E 077F 3114 452A Robert Swain EE7A 56EA 4A81 A7B5 2001 A521 67FA 362D A2FC 3E71 Sascha Sommer 38A0 F88B 868E 9D3A 97D4 D6A0 E823 706F 1E07 0D3C Stefano Sabatini 0D0B AD6B 5330 BBAD D3D6 6A0C 719C 2839 FC43 2D5F +Steinar H. Gunderson C2E9 004F F028 C18E 4EAD DB83 7F61 7561 7797 8F76 Stephan Hilb 4F38 0B3A 5F39 B99B F505 E562 8D5C 5554 4E17 8863 Tiancheng "Timothy" Gu9456 AFC0 814A 8139 E994 8351 7FE6 B095 B582 B0D4 Tim Nicholson 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 -- 2.13.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 1/4] Move lavd/v4l2-common.* to lavc
Le quintidi 15 thermidor, an CCXXV, Jorge Ramirez-Ortiz a écrit : > From: Alexis Ballier > > In preparation to support the integation of the V4L2 API for encoding > and decoding, move v4l2 related files to libavcodec. > > Signed-off-by: Alexis Ballier > Reviewed-by: Jorge Ramirez-Ortiz > --- > configure | 6 ++- > libavcodec/Makefile | 1 + > libavcodec/v4l2-common.c | 105 > ++ > libavcodec/v4l2-common.h | 57 + > libavdevice/Makefile | 6 +-- > libavdevice/v4l2-common.c | 105 > -- > libavdevice/v4l2-common.h | 61 --- > libavdevice/v4l2.c| 40 -- > libavdevice/v4l2enc.c | 14 +-- > 9 files changed, 207 insertions(+), 188 deletions(-) > create mode 100644 libavcodec/v4l2-common.c > create mode 100644 libavcodec/v4l2-common.h > delete mode 100644 libavdevice/v4l2-common.c > delete mode 100644 libavdevice/v4l2-common.h Maybe I misunderstood, I thought you were renaming the files at the same time. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpegtsenc add synchronous metadata - retry
Add synchronous metadata to mpegtsenc
* Added AV_CODEC_ID_SYNCHRONOUS_METADATA
* PMT will have metadata_descriptor and metadata_std_descriptor
in accordance with MISB ST 1402.2
* stream_type will be 0x15 metadata carried in PES packets
* stream_id will be 0xfc metadata stream
Users must supply Metadata Access Unit to the packet before writing.
---
libavcodec/avcodec.h| 1 +
libavformat/mpegtsenc.c | 22 ++
2 files changed, 23 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c594993..fe4e538 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -682,6 +682,7 @@ enum AVCodecID {
AV_CODEC_ID_DVD_NAV,
AV_CODEC_ID_TIMED_ID3,
AV_CODEC_ID_BIN_DATA,
+AV_CODEC_ID_SYNCHRONOUS_METADATA,
AV_CODEC_ID_PROBE = 0x19000, ///< codec_id is not known (like
AV_CODEC_ID_NONE) but lavf should attempt to identify it
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fdfa544..35907da 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -387,6 +387,7 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
stream_type = STREAM_TYPE_PRIVATE_DATA;
break;
case AV_CODEC_ID_TIMED_ID3:
+case AV_CODEC_ID_SYNCHRONOUS_METADATA:
stream_type = STREAM_TYPE_METADATA;
break;
default:
@@ -641,6 +642,27 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
*q++ = 'L';
*q++ = 'V';
*q++ = 'A';
+} else if (st->codecpar->codec_id ==
AV_CODEC_ID_SYNCHRONOUS_METADATA) {
+const char *tag = "KLVA";
+*q++ = 0x26; /* desctiptor_tag =
metadata_descriptor */
+*q++ = 9; /* desctiptor_length */
+put16(&q, 0x0100);/* metadata application format */
+*q++ = 0xff; /* metadata format */
+putstr8(&q, tag, 0);
+*q++ = 0;/* metadata service ID */
+*q++ = 0xF; /* decoder_config_flags|DSM-CC
flag|reserved */
+
+*q++ = 0x27; /* desctiptor_tag =
metadata_std_descriptor */
+*q++ = 9; /* desctiptor_length */
+*q++ = 0xc0;
+*q++ = 0x00;
+*q++ = 0x00;
+*q++ = 0xc0;
+*q++ = 0x00;
+*q++ = 0x00;
+*q++ = 0xc0;
+*q++ = 0x00;
+*q++ = 0x00;
} else if (st->codecpar->codec_id == AV_CODEC_ID_TIMED_ID3) {
const char *tag = "ID3 ";
*q++ = 0x26; /* metadata descriptor */
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 1/4] Move lavd/v4l2-common.* to lavc
On 08/02/2017 10:29 AM, Nicolas George wrote: Le quintidi 15 thermidor, an CCXXV, Jorge Ramirez-Ortiz a écrit : From: Alexis Ballier In preparation to support the integation of the V4L2 API for encoding and decoding, move v4l2 related files to libavcodec. Signed-off-by: Alexis Ballier Reviewed-by: Jorge Ramirez-Ortiz --- configure | 6 ++- libavcodec/Makefile | 1 + libavcodec/v4l2-common.c | 105 ++ libavcodec/v4l2-common.h | 57 + libavdevice/Makefile | 6 +-- libavdevice/v4l2-common.c | 105 -- libavdevice/v4l2-common.h | 61 --- libavdevice/v4l2.c| 40 -- libavdevice/v4l2enc.c | 14 +-- 9 files changed, 207 insertions(+), 188 deletions(-) create mode 100644 libavcodec/v4l2-common.c create mode 100644 libavcodec/v4l2-common.h delete mode 100644 libavdevice/v4l2-common.c delete mode 100644 libavdevice/v4l2-common.h Maybe I misunderstood, I thought you were renaming the files at the same time. ah sorry, the rename happened (globally) in the last commit of the series; since that commit imports v4l2-common.h from UAPI it kind of give me a good reason to rename the files and adopt the "_" along all other files... do you want these files to be renamed on this commit? Regards, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: From: Alexis Ballier This patchset enhances Alexis Ballier's original patch and validates it using Qualcomm's Venus hardware (driver recently landed upstream [1]). This has been tested on Qualcomm's DragonBoard 410c and 820c Tested decoders: - h264 - mpeg4 - vp8 - vp9 - hevc Tested encoders: -h264 -h263 -mpeg4 Tested transcoding (concurrent encoding/decoding) Some of the changes introduced: - v4l2: code cleanup. - v4l2: follow the decode api. - v4l2: fix display size for NV12 output pool. - v4l2: handle EOS. - v4l2: vp8 and mpeg4 decoding. - v4l2: hevc and vp9 support. - v4l2: generate EOF on dequeue errors. - v4l2: h264_mp4toannexb filtering. - v4l2: import compat/v4l2 header files. [1] https://lwn.net/Articles/697956/ Reviewed-by: Jorge Ramirez Reviewed-by: Alexis Ballier Tested-by: Jorge Ramirez --- Changelog |3 +- compat/v4l2/v4l2-common.h | 107 ++ compat/v4l2/v4l2-controls.h | 987 + compat/v4l2/videodev2.h | 2402 + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. Hi Hendrik, but what is wrong with convenience? as a matter of fact, this will not add any 'major' maintenance task. Only when the ffmpeg v4l2 support is modified to add a more recent call (or some new fourcc) these headers will have to be updated accordingly (ie do a copy paste for files that are easily avaialable) IMO, this seems much easier, less error prone - and consistent - than modifying configure every time looking for what needs to be checked before building. On a system with a recent enough kernel to run this, you would also have matching headers, so IMHO this should behave like any external library dependency and just check that the headers are recent enough to build our code, and just skip building the module otherwise. but what if the user is running of vendor trees with some hacked versions of these files in the rootfs? this way at least he'll know exactly what he is building. And if wishes some custom behavior, we are enforcing that he changes the UAPI v4l2 in the ffmpeg _tree_ Seems coherent to me. also notice, that having a recent enough kernel does allows the user to build, will not guarantee that we will be able to run these encoders/decoders (the user will need actual hardware support for that and the v4l2 driver in the kernel) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 02/08/17 08:32, Jorge Ramirez-Ortiz wrote: > From: Alexis Ballier > > This patchset enhances Alexis Ballier's original patch and validates > it using Qualcomm's Venus hardware (driver recently landed upstream > [1]). > > This has been tested on Qualcomm's DragonBoard 410c and 820c > > Tested decoders: >- h264 >- mpeg4 >- vp8 >- vp9 >- hevc > > Tested encoders: >-h264 >-h263 >-mpeg4 > > Tested transcoding (concurrent encoding/decoding) > > Some of the changes introduced: > - v4l2: code cleanup. > - v4l2: follow the decode api. > - v4l2: fix display size for NV12 output pool. > - v4l2: handle EOS. > - v4l2: vp8 and mpeg4 decoding. > - v4l2: hevc and vp9 support. > - v4l2: generate EOF on dequeue errors. > - v4l2: h264_mp4toannexb filtering. > - v4l2: import compat/v4l2 header files. > - v4l2: fixed make install and fate issues. > > [1] https://lwn.net/Articles/697956/ > > Reviewed-by: Jorge Ramirez > Reviewed-by: Alexis Ballier > Tested-by: Jorge Ramirez > --- > Changelog |3 +- > compat/v4l2/v4l2-common.h | 107 ++ > compat/v4l2/v4l2-controls.h | 987 + > compat/v4l2/videodev2.h | 2402 > + > configure | 26 +- > libavcodec/Makefile | 18 +- > libavcodec/allcodecs.c|9 + > libavcodec/v4l2-common.c | 136 --- > libavcodec/v4l2-common.h | 62 -- > libavcodec/v4l2_buffers.c | 614 +++ > libavcodec/v4l2_buffers.h | 226 > libavcodec/v4l2_fmt.c | 142 +++ > libavcodec/v4l2_fmt.h | 62 ++ > libavcodec/v4l2_m2m.c | 356 ++ > libavcodec/v4l2_m2m.h | 69 ++ > libavcodec/v4l2_m2m_avcodec.h | 32 + > libavcodec/v4l2_m2m_dec.c | 229 > libavcodec/v4l2_m2m_enc.c | 270 + > libavdevice/v4l2.c|2 +- > libavdevice/v4l2enc.c |2 +- > tests/ref/fate/source |3 + > 21 files changed, 5547 insertions(+), 210 deletions(-) > create mode 100644 compat/v4l2/v4l2-common.h > create mode 100644 compat/v4l2/v4l2-controls.h > create mode 100644 compat/v4l2/videodev2.h > delete mode 100644 libavcodec/v4l2-common.c > delete mode 100644 libavcodec/v4l2-common.h > create mode 100644 libavcodec/v4l2_buffers.c > create mode 100644 libavcodec/v4l2_buffers.h > create mode 100644 libavcodec/v4l2_fmt.c > create mode 100644 libavcodec/v4l2_fmt.h > create mode 100644 libavcodec/v4l2_m2m.c > create mode 100644 libavcodec/v4l2_m2m.h > create mode 100644 libavcodec/v4l2_m2m_avcodec.h > create mode 100644 libavcodec/v4l2_m2m_dec.c > create mode 100644 libavcodec/v4l2_m2m_enc.c Hi, Some general questions first; I'll try to do some detailed review later. Is the intent here only to really support software memory cases? That is, to only consider things on the user side and to copy with the CPU between different components. If not, I don't think the method with only user virtual pointers being visible externally is really the right approach. For example, mapping to DRM PRIME fds is going to be wanted by a number of use-cases (for import with EGL or other APIs, or display directly via modesetting), and needs the V4L2 buffer metadata for VIDIOC_EXPBUF to work. To that end, I think it might be better to have an opaque AV_PIX_FMT_V4L2 type carrying the buffer information and managed by the hwcontext API, which can then be mapped to user virtual memory as needed. Such a setup would support sharing between components inside lav* (e.g. transcode with copy) as well. Alternatively, it might be possible to use AV_PIX_FMT_DRM_PRIME directly (see the Rockchip codec patchset), though that would exclude drivers not using dma_buf inside the kernel which you suggested previously was a needed case. Are there more patches to follow? (Filtering?) I note that all of the buffer functions in the current version are tagged avpriv, but aren't used outside lavc. On devices, you mention it's tested on Qualcomm's DragonBoard 410c and 820c; is it expected to work with cores from other vendors? If I wanted to test this, what hardware would be easiest to use? Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size
On Wed, Aug 2, 2017 at 2:10 PM, Tobias Rapp wrote: > On 01.08.2017 17:01, Muhammad Faiz wrote: >> >> Fix Ticket6519. >> >> Signed-off-by: Muhammad Faiz >> --- >> libavfilter/vf_ssim.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >> index c3c204268f..dfd276e015 100644 >> --- a/libavfilter/vf_ssim.c >> +++ b/libavfilter/vf_ssim.c >> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >> for (i = 0; i < s->nb_components; i++) >> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >> sum; >> >> -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 >> + (desc->comp[0].depth > 8))); >> +s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >> if (!s->temp) >> return AVERROR(ENOMEM); >> s->max = (1 << desc->comp[0].depth) - 1; >> > > I confirm that the command doesn't crash anymore and the reports of "invalid > read/write" in Valgrind are gone. However there are still some "use of > uninitialized value" reports remaining. Maybe use av_mallocz_array? Changed locally with av_mallocz_array. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size
On 02.08.2017 12:31, Muhammad Faiz wrote: On Wed, Aug 2, 2017 at 2:10 PM, Tobias Rapp wrote: On 01.08.2017 17:01, Muhammad Faiz wrote: Fix Ticket6519. Signed-off-by: Muhammad Faiz --- libavfilter/vf_ssim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c index c3c204268f..dfd276e015 100644 --- a/libavfilter/vf_ssim.c +++ b/libavfilter/vf_ssim.c @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) for (i = 0; i < s->nb_components; i++) s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); +s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); if (!s->temp) return AVERROR(ENOMEM); s->max = (1 << desc->comp[0].depth) - 1; I confirm that the command doesn't crash anymore and the reports of "invalid read/write" in Valgrind are gone. However there are still some "use of uninitialized value" reports remaining. Maybe use av_mallocz_array? Changed locally with av_mallocz_array. LGTM then. Thanks for the fix. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size
Hi, On Wed, Aug 2, 2017 at 3:10 AM, Tobias Rapp wrote: > On 01.08.2017 17:01, Muhammad Faiz wrote: > >> Fix Ticket6519. >> >> Signed-off-by: Muhammad Faiz >> --- >> libavfilter/vf_ssim.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c >> index c3c204268f..dfd276e015 100644 >> --- a/libavfilter/vf_ssim.c >> +++ b/libavfilter/vf_ssim.c >> @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) >> for (i = 0; i < s->nb_components; i++) >> s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / >> sum; >> >> -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * >> (1 + (desc->comp[0].depth > 8))); >> +s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), >> sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); >> if (!s->temp) >> return AVERROR(ENOMEM); >> s->max = (1 << desc->comp[0].depth) - 1; >> >> > I confirm that the command doesn't crash anymore and the reports of > "invalid read/write" in Valgrind are gone. However there are still some > "use of uninitialized value" reports remaining. Maybe use av_mallocz_array? Wait wait, before we do that, which values are uninitialized and what are they used for? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Testing JPEG 2000 over MPEG TS
On Sun, Jul 23, 2017 at 6:16 PM, Carl Eugen Hoyos wrote: > 2017-07-22 15:39 GMT+02:00 Aaron Boxer : > > > GStreamer project now has a working muxer/demuxer for J2K over MPEG TS. > > Did you test it? > I have acquired a test capture of VSF TR1 video from a nevion VS902: http://s3.amazonaws.com/fox_misc/aperi_tr01_1s_pkts-C.cap.gz I tried reading it with FFMpeg but I got a number of warnings and errors. If anyone is interested in taking a look - grab it - I am not sure how long it will be up on Amazon. Aaron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size
On 02.08.2017 14:04, Ronald S. Bultje wrote: Hi, On Wed, Aug 2, 2017 at 3:10 AM, Tobias Rapp wrote: On 01.08.2017 17:01, Muhammad Faiz wrote: Fix Ticket6519. Signed-off-by: Muhammad Faiz --- libavfilter/vf_ssim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c index c3c204268f..dfd276e015 100644 --- a/libavfilter/vf_ssim.c +++ b/libavfilter/vf_ssim.c @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) for (i = 0; i < s->nb_components; i++) s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); +s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); if (!s->temp) return AVERROR(ENOMEM); s->max = (1 << desc->comp[0].depth) - 1; I confirm that the command doesn't crash anymore and the reports of "invalid read/write" in Valgrind are gone. However there are still some "use of uninitialized value" reports remaining. Maybe use av_mallocz_array? Wait wait, before we do that, which values are uninitialized and what are they used for? Reads into s->temp seem to use uninitialized values on x86-64 when vf_ssim.asm routines are used (-cpuflags all), see attached Valgrind report. When vf_ssim.asm is not used (-cpuflags 0) no "use of uninitialized value" is reported. The difference of the reported SSIM scores between my asm and non-asm test runs was <= 10^-6. Regards, Tobias valgrind-fate-ssim-rgb_7c04be7b.log.gz Description: application/gzip ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 12:16 PM, Mark Thompson wrote:
On 02/08/17 08:32, Jorge Ramirez-Ortiz wrote:
From: Alexis Ballier
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been tested on Qualcomm's DragonBoard 410c and 820c
Tested decoders:
- h264
- mpeg4
- vp8
- vp9
- hevc
Tested encoders:
-h264
-h263
-mpeg4
Tested transcoding (concurrent encoding/decoding)
Some of the changes introduced:
- v4l2: code cleanup.
- v4l2: follow the decode api.
- v4l2: fix display size for NV12 output pool.
- v4l2: handle EOS.
- v4l2: vp8 and mpeg4 decoding.
- v4l2: hevc and vp9 support.
- v4l2: generate EOF on dequeue errors.
- v4l2: h264_mp4toannexb filtering.
- v4l2: import compat/v4l2 header files.
- v4l2: fixed make install and fate issues.
[1] https://lwn.net/Articles/697956/
Reviewed-by: Jorge Ramirez
Reviewed-by: Alexis Ballier
Tested-by: Jorge Ramirez
---
Changelog |3 +-
compat/v4l2/v4l2-common.h | 107 ++
compat/v4l2/v4l2-controls.h | 987 +
compat/v4l2/videodev2.h | 2402 +
configure | 26 +-
libavcodec/Makefile | 18 +-
libavcodec/allcodecs.c|9 +
libavcodec/v4l2-common.c | 136 ---
libavcodec/v4l2-common.h | 62 --
libavcodec/v4l2_buffers.c | 614 +++
libavcodec/v4l2_buffers.h | 226
libavcodec/v4l2_fmt.c | 142 +++
libavcodec/v4l2_fmt.h | 62 ++
libavcodec/v4l2_m2m.c | 356 ++
libavcodec/v4l2_m2m.h | 69 ++
libavcodec/v4l2_m2m_avcodec.h | 32 +
libavcodec/v4l2_m2m_dec.c | 229
libavcodec/v4l2_m2m_enc.c | 270 +
libavdevice/v4l2.c|2 +-
libavdevice/v4l2enc.c |2 +-
tests/ref/fate/source |3 +
21 files changed, 5547 insertions(+), 210 deletions(-)
create mode 100644 compat/v4l2/v4l2-common.h
create mode 100644 compat/v4l2/v4l2-controls.h
create mode 100644 compat/v4l2/videodev2.h
delete mode 100644 libavcodec/v4l2-common.c
delete mode 100644 libavcodec/v4l2-common.h
create mode 100644 libavcodec/v4l2_buffers.c
create mode 100644 libavcodec/v4l2_buffers.h
create mode 100644 libavcodec/v4l2_fmt.c
create mode 100644 libavcodec/v4l2_fmt.h
create mode 100644 libavcodec/v4l2_m2m.c
create mode 100644 libavcodec/v4l2_m2m.h
create mode 100644 libavcodec/v4l2_m2m_avcodec.h
create mode 100644 libavcodec/v4l2_m2m_dec.c
create mode 100644 libavcodec/v4l2_m2m_enc.c
Hi,
Some general questions first; I'll try to do some detailed review later.
thanks! very much appreciated.
Alexis feel free to add your comments as well.
Is the intent here only to really support software memory cases? That is, to
only consider things on the user side and to copy with the CPU between
different components.
This commit adds a generic way of supporting v4l2 in ffmpeg
(V4L2_MEMORY_MMAP)
enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR = 2,
V4L2_MEMORY_OVERLAY = 3,
V4L2_MEMORY_DMABUF = 4,
};
You are right, this patch uses the CPU to copy the preprocessed/demuxed
bitstream to the v4l2 buffers and then as you said uses the pointers.
Extending it to support V4L2_MEMORY_DMABUF for performance is in the
todo list.
however I think (this is just my opinion) there is value today in
enabling the available v4l2 codecs present in many SoCs and bringing
them under ffmpeg.
And right after work on performance and incremental optimizations.
If not, I don't think the method with only user virtual pointers being visible
externally is really the right approach.
if by "right" you mean with the best performance possible yes I don't
disagree with you.
For example, mapping to DRM PRIME fds is going to be wanted by a number of
use-cases (for import with EGL or other APIs, or display directly via
modesetting), and needs the V4L2 buffer metadata for VIDIOC_EXPBUF to work. To
that end, I think it might be better to have an opaque AV_PIX_FMT_V4L2 type
carrying the buffer information and managed by the hwcontext API, which can
then be mapped to user virtual memory as needed.
yes I am looking at this WIP
https://github.com/LongChair/FFmpeg/commit/f852e3d6d89be3fcee90482971c3f769bdaa8e9c.
I think it is work like this that can be used later on with v4l2 for
optimal performance...thought I have to admit I still need to understand
how I would use it.
but I don't see why the v4l2 patchset can not be extended afterwards?
Yes we need to add VIDIOC_EXPBUF and then on dequeing cacpture we coud
either set the DRM plane or just pass the pointer.
Such a setup would support sharing between components inside lav* (e.g.
transcode with copy) as well. Alternatively, it might be possibl
[FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter
From: Ashish Singh
Signed-off-by: Ashish Singh
---
doc/filters.texi| 19 +++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_vmafmotion.c | 404
libavfilter/vmaf_motion.h | 42 +
5 files changed, 467 insertions(+)
create mode 100644 libavfilter/vf_vmafmotion.c
create mode 100644 libavfilter/vmaf_motion.h
diff --git a/doc/filters.texi b/doc/filters.texi
index 2324b96..ee1e884 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -15137,6 +15137,25 @@ vignette='PI/4+random(1)*PI/50':eval=frame
@end itemize
+@section vmafmotion
+
+Obtain the average vmaf motion score between two input videos.
+It is one of the component filters of VMAF.
+
+This filter takes two input videos.
+
+Both input videos must have the same resolution and pixel format.
+Also it assumes that both inputs have the same number of frames.
+
+The obtained average motion score is printed through the logging system.
+
+In the below example the input file @file{main.mpg} being processed is compared
+with the reference file @file{ref.mpg}.
+
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi vmafmotion -f null -
+@end example
+
@section vstack
Stack input videos vertically.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ee16361..771e434 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -322,6 +322,7 @@ OBJS-$(CONFIG_VFLIP_FILTER) += vf_vflip.o
OBJS-$(CONFIG_VIDSTABDETECT_FILTER) += vidstabutils.o
vf_vidstabdetect.o
OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER) += vidstabutils.o
vf_vidstabtransform.o
OBJS-$(CONFIG_VIGNETTE_FILTER) += vf_vignette.o
+OBJS-$(CONFIG_VMAFMOTION_FILTER) += vf_vmafmotion.o dualinput.o
framesync.o
OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
OBJS-$(CONFIG_WAVEFORM_FILTER) += vf_waveform.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b1c2d11..644ab44 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -333,6 +333,7 @@ static void register_all(void)
REGISTER_FILTER(VIDSTABDETECT, vidstabdetect, vf);
REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
REGISTER_FILTER(VIGNETTE, vignette, vf);
+REGISTER_FILTER(VMAFMOTION, vmafmotion, vf);
REGISTER_FILTER(VSTACK, vstack, vf);
REGISTER_FILTER(W3FDIF, w3fdif, vf);
REGISTER_FILTER(WAVEFORM, waveform, vf);
diff --git a/libavfilter/vf_vmafmotion.c b/libavfilter/vf_vmafmotion.c
new file mode 100644
index 000..8456939
--- /dev/null
+++ b/libavfilter/vf_vmafmotion.c
@@ -0,0 +1,404 @@
+/*
+ * Copyright (c) 2017 Ronald S. Bultje
+ * Copyright (c) 2017 Ashish Pratap Singh
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Calculate VMAF Motion score between two input videos.
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "dualinput.h"
+#include "drawutils.h"
+#include "formats.h"
+#include "internal.h"
+#include "vmaf_motion.h"
+#include "video.h"
+
+typedef struct VMAFMotionContext {
+const AVClass *class;
+FFDualInputContext dinput;
+const AVPixFmtDescriptor *desc;
+int filter[5];
+int width;
+int height;
+uint16_t *prev_blur_data;
+uint16_t *blur_data;
+uint16_t *temp_data;
+double motion_sum;
+uint64_t nb_frames;
+} VMAFMotionContext;
+
+#define MAX_ALIGN 32
+#define ALIGN_CEIL(x) ((x) + ((x) % MAX_ALIGN ? MAX_ALIGN - (x) % MAX_ALIGN :
0))
+
+static const AVOption vmafmotion_options[] = {
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(vmafmotion);
+
+static double image_sad(const uint16_t *img1, const uint16_t *img2, int w, int
h,
+ptrdiff_t img1_stride, ptrdiff_t img2_stride)
+{
+uint64_t sum = 0;
+int i, j;
+
+for (i = 0; i < h; i++) {
+for (j = 0; j < w; j++) {
+sum += abs(img1[i * img1_stride + j] - img2[i * img2_stride + j]);
+}
+}
+
+return (double) (sum * 1.0 / (w * h));
+}
+
+static in
Re: [FFmpeg-devel] [PATCH 6/7] lavf/flacenc: avoid buffer overread with unexpected extradata sizes
On Wed, Aug 02, 2017 at 01:30:44AM -0500, Rodger Combs wrote:
> ---
> libavformat/flacenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> index 9768b6a..1906aee 100644
> --- a/libavformat/flacenc.c
> +++ b/libavformat/flacenc.c
> @@ -322,7 +322,7 @@ static int flac_write_trailer(struct AVFormatContext *s)
> if (!c->write_header || !streaminfo)
> return 0;
>
> -if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
> +if (pb->seekable & AVIO_SEEKABLE_NORMAL && (c->streaminfo ||
> s->streams[0]->codecpar->extradata_size == FLAC_STREAMINFO_SIZE)) {
this looks a bit odd
uint8_t *streaminfo = c->streaminfo ? c->streaminfo :
s->streams[0]->codecpar->extradata;
...
> +if (pb->seekable & AVIO_SEEKABLE_NORMAL && (c->streaminfo ||
> s->streams[0]->codecpar->extradata_size == FLAC_STREAMINFO_SIZE)) {
isnt this just "&& c->streaminfo" ?
also is s->streams[0] correct ?
shouldnt this use c->audio_stream_idx ?
[...]
--
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] [PATCHv3 3/4] libavcodec: v4l2: add codec formats
On Wed, Aug 02, 2017 at 09:32:51AM +0200, Jorge Ramirez-Ortiz wrote: > From: Alexis Ballier > > In addition, enable the multi planar raw formats. > > Reviewed-by: Jorge Ramirez > Tested-by: Jorge Ramirez > --- > libavcodec/v4l2-common.c | 30 ++ > 1 file changed, 30 insertions(+) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: fix gbrap16 alpha channel issues
On Tue, Aug 01, 2017 at 02:46:22PM +0100, James Cowgill wrote:
> Fixes filter-pixfmts-scale test failing on big-endian systems due to
> alpSrc not being cast to (const int32_t**).
>
> Also fixes distortions in the output alpha channel values by copying the
> alpha channel code from the rgba64 case found elsewhere in output.c.
>
> Fixes ticket 6555.
>
> Signed-off-by: James Cowgill
> ---
> libswscale/output.c | 15 ---
> tests/ref/fate/filter-pixfmts-scale | 4 ++--
> 2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/libswscale/output.c b/libswscale/output.c
> index 9774e9f327..8e5ec0a256 100644
> --- a/libswscale/output.c
> +++ b/libswscale/output.c
> @@ -2026,17 +2026,18 @@ yuv2gbrp16_full_X_c(SwsContext *c, const int16_t
> *lumFilter,
> const int16_t **lumSrcx, int lumFilterSize,
> const int16_t *chrFilter, const int16_t **chrUSrcx,
> const int16_t **chrVSrcx, int chrFilterSize,
> -const int16_t **alpSrc, uint8_t **dest,
> +const int16_t **alpSrcx, uint8_t **dest,
> int dstW, int y)
> {
> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(c->dstFormat);
> int i;
> -int hasAlpha = (desc->flags & AV_PIX_FMT_FLAG_ALPHA) && alpSrc;
> +int hasAlpha = (desc->flags & AV_PIX_FMT_FLAG_ALPHA) && alpSrcx;
> uint16_t **dest16 = (uint16_t**)dest;
> const int32_t **lumSrc = (const int32_t**)lumSrcx;
> const int32_t **chrUSrc = (const int32_t**)chrUSrcx;
> const int32_t **chrVSrc = (const int32_t**)chrVSrcx;
> -int A = 0; // init to silence warning
> +const int32_t **alpSrc = (const int32_t**)alpSrcx;
> +int A = 0x << 14;
unused value
>
> for (i = 0; i < dstW; i++) {
> int j;
> @@ -2059,13 +2060,13 @@ yuv2gbrp16_full_X_c(SwsContext *c, const int16_t
> *lumFilter,
> V >>= 14;
>
> if (hasAlpha) {
> -A = 1 << 18;
> +A = -0x4000;
where does this value come from ?
it looks copy and pasted from luma, but alpha does not have a black
level offset as its not luminance
>
> for (j = 0; j < lumFilterSize; j++)
> A += alpSrc[j][i] * lumFilter[j];
>
> -if (A & 0xF800)
> -A = av_clip_uintp2(A, 27);
> +A >>= 1;
> +A += 0x20002000;
> }
>
> Y -= c->yuv2rgb_y_offset;
> @@ -2083,7 +2084,7 @@ yuv2gbrp16_full_X_c(SwsContext *c, const int16_t
> *lumFilter,
> dest16[1][i] = B >> 14;
> dest16[2][i] = R >> 14;
> if (hasAlpha)
> -dest16[3][i] = A >> 11;
> +dest16[3][i] = av_clip_uintp2(A, 30) >> 14;
why do you move the cliping code here, this seems unneeded
outside the removed if()
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/riff: remove useless tag correlation 'mpg2'->MPEG1VIDEO.
On Tue, Aug 01, 2017 at 02:50:27PM +0300, Александр Слободенюк wrote: > This is actually a bug, that just doesn't affect anything. > First of all, the logic of functions that work with ff_codec_bmp_tags > is "One tag -- one codec id", or "one codec id for one tag". > > Also if you write this tag as MPEG2VIDEO, and then read the header > (all by ffmpeg), it will interpret as MPEG1VIDEO: > > ffmpeg -i whatever -vcodec mpeg2video test.avi > && gdb ffprobe_g > > (gdb) break avi_read_header > (gdb) r -i test.avi > (gdb) finish > (gdb) p s->>streams[0]->codecpar->codec_id > > $1 = AV_CODEC_ID_MPEG1VIDEO > > > if you will write an mpeg1video , it will be created with tag > 'mpg1',not'mpg2'inall cases (because correlation > AV_CODEC_ID_MPEG1_VIDEO -- 'mpg1') stands before 'mpg2' tag in > ff_codec_bmp_tags: > > ffmpeg -i whatever -vcodec mpeg1video test.avi > (output) > ... > (output) > Stream #0:0: Video: mpeg1video (mpg1 / 0x3167706D), > > So, this patch does not affect on writing mpeg1video to riff files. > riff.c |1 - > 1 file changed, 1 deletion(-) > 7d4eaf028a197fd2aebdfe7c970de0da61a22055 > 0001-avformat-riff-remove-useless-tag-correlation-mpg2-MP.patch > From ab7eefb51eeec5ff0c10f571d468f61c82a84eeb Mon Sep 17 00:00:00 2001 > From: Aleksandr Slobodeniuk > Date: Tue, 1 Aug 2017 14:48:39 +0300 > Subject: [PATCH] avformat/riff: remove useless tag correlation > 'mpg2'->MPEG1VIDEO. applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/riff.h : remove unused function parameter "const AVCodecTag *tags" of "void ff_put_bmp_header()"
On Tue, Aug 01, 2017 at 02:55:31PM +0300, Александр Слободенюк wrote: > This patch was reviewed by Derek Buitenhuis last month and later ignored, no > idea > why. > > (archive: > http://ffmpeg-devel.ffmpeg.narkive.com/vnPIkBwh/patch-avformat-riff-h-remove-unused-function-parameter-const-avcodectag-tags-of-void-ff-put-bmp) > asfenc.c |2 +- > avienc.c |2 +- > matroskaenc.c |2 +- > riff.h|2 +- > riffenc.c |2 +- > wtvenc.c |2 +- > 6 files changed, 6 insertions(+), 6 deletions(-) > c205028e75e0b51dec7637513bab1a96b380070d > 0001-avformat-riff.h-remove-unused-function-parameter.patch > From f5f7d1b6e50fbcf565446dbdc2cc82ee79e4401f Mon Sep 17 00:00:00 2001 > From: Aleksandr Slobodeniuk > Date: Fri, 14 Jul 2017 14:03:20 +0300 > Subject: [PATCH] avformat/riff.h : remove unused function parameter "const > AVCodecTag *tags" of "void ff_put_bmp_header()" applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 02:43 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez wrote: On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: From: Alexis Ballier This patchset enhances Alexis Ballier's original patch and validates it using Qualcomm's Venus hardware (driver recently landed upstream [1]). This has been tested on Qualcomm's DragonBoard 410c and 820c Tested decoders: - h264 - mpeg4 - vp8 - vp9 - hevc Tested encoders: -h264 -h263 -mpeg4 Tested transcoding (concurrent encoding/decoding) Some of the changes introduced: - v4l2: code cleanup. - v4l2: follow the decode api. - v4l2: fix display size for NV12 output pool. - v4l2: handle EOS. - v4l2: vp8 and mpeg4 decoding. - v4l2: hevc and vp9 support. - v4l2: generate EOF on dequeue errors. - v4l2: h264_mp4toannexb filtering. - v4l2: import compat/v4l2 header files. [1] https://lwn.net/Articles/697956/ Reviewed-by: Jorge Ramirez Reviewed-by: Alexis Ballier Tested-by: Jorge Ramirez --- Changelog |3 +- compat/v4l2/v4l2-common.h | 107 ++ compat/v4l2/v4l2-controls.h | 987 + compat/v4l2/videodev2.h | 2402 + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. Hi Hendrik, but what is wrong with convenience? as a matter of fact, this will not add any 'major' maintenance task. Only when the ffmpeg v4l2 support is modified to add a more recent call (or some new fourcc) these headers will have to be updated accordingly (ie do a copy paste for files that are easily avaialable) IMO, this seems much easier, less error prone - and consistent - than modifying configure every time looking for what needs to be checked before building. You could bring that argument for every single external library/API we support, and that is just not something we should be doing. We require headers to be available in the system for practically every other external API/library with only very few exceptions which have extraordinary circumstances beyond "I don't want to maintain configure checks". but that is not a reason I have given - ie not wanting to maintain "configure", that is some interpretation of the conclusion.. (I think you got causation the other way around on this :)) The way I see it maintaining configure for V4L2 API just seems less efficient and more error prone - and more work for everyone with no real gains. Let me try highlighting some benefits IMHO of importing the V4L2 API (also notice that this is the linux kernel API - we are not talking about some HW vendor specs that we want to import through some backdoor, these files are well maintained) 1. reduction in the frequency of the maintenance tasks. When they need to be performed (ie new format or fourcc or whatever), the user will be updating for the future since it will import many other updates. -> You can't say the same about maintaining configure. 2. the build environment is always sane no matter where you build. This translates in more extensive testing since it enables building on more environments. -> You can't say the same about checking against whatever API was installed in the build environment (could be 8 years old) 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and execute them on a target running a recent kernel -> that can't be done the way you propose And since the kernel guarantees that will not break userspace, there is zero risk to the users if we import the V4L2 API just as other projects have done. So no, we should not be doing this. could you help me understand why what I am proposing is a no-go on ffmpeg? what are the benefits of 'configure' checking for the kernel API in the build environment? Anyhow, if this set in stone by the maintainers, just let me know and I will just update configure. I hate wasting people's time :) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez wrote: > On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: >> >> On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz >> wrote: >>> >>> From: Alexis Ballier >>> >>> This patchset enhances Alexis Ballier's original patch and validates >>> it using Qualcomm's Venus hardware (driver recently landed upstream >>> [1]). >>> >>> This has been tested on Qualcomm's DragonBoard 410c and 820c >>> >>> Tested decoders: >>> - h264 >>> - mpeg4 >>> - vp8 >>> - vp9 >>> - hevc >>> >>> Tested encoders: >>> -h264 >>> -h263 >>> -mpeg4 >>> >>> Tested transcoding (concurrent encoding/decoding) >>> >>> Some of the changes introduced: >>> - v4l2: code cleanup. >>> - v4l2: follow the decode api. >>> - v4l2: fix display size for NV12 output pool. >>> - v4l2: handle EOS. >>> - v4l2: vp8 and mpeg4 decoding. >>> - v4l2: hevc and vp9 support. >>> - v4l2: generate EOF on dequeue errors. >>> - v4l2: h264_mp4toannexb filtering. >>> - v4l2: import compat/v4l2 header files. >>> >>> [1] https://lwn.net/Articles/697956/ >>> >>> Reviewed-by: Jorge Ramirez >>> Reviewed-by: Alexis Ballier >>> Tested-by: Jorge Ramirez >>> --- >>> Changelog |3 +- >>> compat/v4l2/v4l2-common.h | 107 ++ >>> compat/v4l2/v4l2-controls.h | 987 + >>> compat/v4l2/videodev2.h | 2402 >>> + >> >> As commented on IRC before, I'm not a fan of importing Linux kernel >> headers for the only reason because its convenient to always have >> recent headers available. > > Hi Hendrik, > > but what is wrong with convenience? as a matter of fact, this will not add > any 'major' maintenance task. > Only when the ffmpeg v4l2 support is modified to add a more recent call (or > some new fourcc) these headers will have to be updated accordingly (ie do a > copy paste for files that are easily avaialable) > > IMO, this seems much easier, less error prone - and consistent - than > modifying configure every time looking for what needs to be checked before > building. > (Re-send because I didn't send it to the List by accident) You could bring that argument for every single external library/API we support, and that is just not something we should be doing. We require headers to be available in the system for practically every other external API/library with only very few exceptions which have extraordinary circumstances beyond "I don't want to maintain configure checks". So no, we should not be doing this. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter
Le quintidi 15 thermidor, an CCXXV, Ashish Pratap Singh a écrit : > +FFDualInputContext dinput; dualinput is about to be removed, please see the patch series two days ago. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size
Hi, On Wed, Aug 2, 2017 at 8:45 AM, Tobias Rapp wrote: > On 02.08.2017 14:04, Ronald S. Bultje wrote: > >> On Wed, Aug 2, 2017 at 3:10 AM, Tobias Rapp >> wrote: >> >>> On 01.08.2017 17:01, Muhammad Faiz wrote: >>> Fix Ticket6519. Signed-off-by: Muhammad Faiz --- libavfilter/vf_ssim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c index c3c204268f..dfd276e015 100644 --- a/libavfilter/vf_ssim.c +++ b/libavfilter/vf_ssim.c @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) for (i = 0; i < s->nb_components; i++) s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); +s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); if (!s->temp) return AVERROR(ENOMEM); s->max = (1 << desc->comp[0].depth) - 1; I confirm that the command doesn't crash anymore and the reports of >>> "invalid read/write" in Valgrind are gone. However there are still some >>> "use of uninitialized value" reports remaining. Maybe use >>> av_mallocz_array? >>> >> >> >> Wait wait, before we do that, which values are uninitialized and what are >> they used for? >> > > Reads into s->temp seem to use uninitialized values on x86-64 when > vf_ssim.asm routines are used (-cpuflags all), see attached Valgrind > report. When vf_ssim.asm is not used (-cpuflags 0) no "use of uninitialized > value" is reported. > > The difference of the reported SSIM scores between my asm and non-asm test > runs was <= 10^-6. Which function is causing the warnings? Isit dsp->ssim_4x4_line() or dsp->ssim_end_line()? (My gut feeling tells me it's ssim_4x4_line(), but I don't understand why, since the result should be unused in ssim_end_line().) It's really important to understand the source and implication of these warnings before we silence them - they may be causing actual inaccuracies in the result, which we don't want. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/3] speedhq: add FATE tests
On 8/2/2017 4:39 AM, Steinar H. Gunderson wrote: > Also add simple FATE tests, based on output produced by the NDI SDK. > --- > tests/Makefile | 1 + > tests/fate/vcodec.mak | 2 ++ > tests/ref/fate/speedhq-422 | 6 ++ > tests/ref/fate/speedhq-422-singlefield | 6 ++ > 4 files changed, 15 insertions(+) > create mode 100644 tests/ref/fate/speedhq-422 > create mode 100644 tests/ref/fate/speedhq-422-singlefield > > diff --git a/tests/Makefile b/tests/Makefile > index ab83ae855d..f9b9cf4188 100644 > --- a/tests/Makefile > +++ b/tests/Makefile > @@ -164,6 +164,7 @@ include $(SRC_PATH)/tests/fate/qt.mak > include $(SRC_PATH)/tests/fate/qtrle.mak > include $(SRC_PATH)/tests/fate/real.mak > include $(SRC_PATH)/tests/fate/screen.mak > +include $(SRC_PATH)/tests/fate/speedhq.mak This file is missing in the patch now. > include $(SRC_PATH)/tests/fate/source.mak > include $(SRC_PATH)/tests/fate/subtitles.mak > include $(SRC_PATH)/tests/fate/utvideo.mak > diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak > index 8c24510937..0a284ecbb9 100644 > --- a/tests/fate/vcodec.mak > +++ b/tests/fate/vcodec.mak > @@ -386,6 +386,8 @@ fate-vsynth%-snow-hpel: ENCOPTS = -qscale 2 > \ > fate-vsynth%-snow-ll:ENCOPTS = -qscale .001 -pred 1 \ > -flags +mv4+qpel > > +FATE_VCODEC-$(call ALLYES, SPEEDHQ_DECODER) += speedhq And you didn't remove this line. > + > FATE_VCODEC-$(call ENCDEC, SVQ1, MOV) += svq1 > fate-vsynth%-svq1: ENCOPTS = -qscale 3 -pix_fmt yuv410p > fate-vsynth%-svq1: FMT = mov > diff --git a/tests/ref/fate/speedhq-422 b/tests/ref/fate/speedhq-422 > new file mode 100644 > index 00..7bb0d2388d > --- /dev/null > +++ b/tests/ref/fate/speedhq-422 > @@ -0,0 +1,6 @@ > +#tb 0: 1/25 > +#media_type 0: video > +#codec_id 0: rawvideo > +#dimensions 0: 112x64 > +#sar 0: 0/1 > +0, 0, 0,1,14336, 0x9bb6dc6d > diff --git a/tests/ref/fate/speedhq-422-singlefield > b/tests/ref/fate/speedhq-422-singlefield > new file mode 100644 > index 00..343c52645c > --- /dev/null > +++ b/tests/ref/fate/speedhq-422-singlefield > @@ -0,0 +1,6 @@ > +#tb 0: 1/25 > +#media_type 0: video > +#codec_id 0: rawvideo > +#dimensions 0: 112x32 > +#sar 0: 0/1 > +0, 0, 0,1, 7168, 0x75de4109 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/7] lavf/flacenc: support writing attached pictures
On 8/2/2017 3:30 AM, Rodger Combs wrote:
> ---
> libavformat/flacenc.c | 285
> +++---
> 1 file changed, 250 insertions(+), 35 deletions(-)
>
> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> index b894f9e..9768b6a 100644
[...]
> @@ -166,23 +341,63 @@ static int flac_write_trailer(struct AVFormatContext *s)
> static int flac_write_packet(struct AVFormatContext *s, AVPacket *pkt)
> {
> FlacMuxerContext *c = s->priv_data;
> -uint8_t *streaminfo;
> -int streaminfo_size;
> +if (pkt->stream_index == c->audio_stream_idx) {
> +if (c->waiting_pics) {
> +/* buffer audio packets until we get all the pictures */
> +AVPacketList *pktl = av_mallocz(sizeof(*pktl));
> +int ret;
> +if (!pktl) {
> +ret = AVERROR(ENOMEM);
> +oom:
> +if (s->error_recognition & AV_EF_EXPLODE) {
> +av_free(pktl);
> +return ret;
> +}
> +av_log(s, AV_LOG_ERROR, "Out of memory in packet queue;
> skipping attached pictures\n");
> +c->waiting_pics = 0;
> +if ((ret = flac_queue_flush(s)) < 0)
> +return ret;
> +return flac_write_audio_packet(s, pkt);
> +}
> +
> +ret = av_packet_ref(&pktl->pkt, pkt);
> +if (ret < 0) {
> +av_freep(&pktl);
> +goto oom;
> +}
> +
> +if (c->queue_end)
> +c->queue_end->next = pktl;
> +else
> +c->queue = pktl;
> +c->queue_end = pktl;
> +} else {
> +return flac_write_audio_packet(s, pkt);
> +}
> +} else {
> +int ret, index = pkt->stream_index;
>
> -/* check for updated streaminfo */
> -streaminfo = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
> - &streaminfo_size);
> -if (streaminfo && streaminfo_size == FLAC_STREAMINFO_SIZE) {
> -av_freep(&c->streaminfo);
> +/* warn only once for each stream */
> +if (s->streams[pkt->stream_index]->nb_frames == 1) {
> +av_log(s, AV_LOG_WARNING, "Got more than one picture in stream
> %d,"
> + " ignoring.\n", pkt->stream_index);
> +}
> +if (!c->waiting_pics || s->streams[pkt->stream_index]->nb_frames >=
> 1)
> +return 0;
>
> -c->streaminfo = av_malloc(FLAC_STREAMINFO_SIZE);
> -if (!c->streaminfo)
> -return AVERROR(ENOMEM);
> -memcpy(c->streaminfo, streaminfo, FLAC_STREAMINFO_SIZE);
> +if (index > c->audio_stream_idx)
> +index--;
> +
> +if ((ret = av_copy_packet(&c->pics[index], pkt)) < 0)
Shouldn't this be av_packet_ref()?
And they should probably be unreferenced after being consumed in
flac_finish_header(), much like the audio packets are in flac_queue_flush().
Also, you don't seem to be freeing c->pics anywhere.
> +return ret;
> +c->waiting_pics--;
> +
> +/* flush the buffered audio packets */
> +if (!c->waiting_pics &&
> +(ret = flac_queue_flush(s)) < 0)
> +return ret;
> }
>
> -if (pkt->size)
> -avio_write(s->pb, pkt->data, pkt->size);
> return 0;
> }
>
> @@ -205,7 +420,7 @@ AVOutputFormat ff_flac_muxer = {
> .mime_type = "audio/x-flac",
> .extensions= "flac",
> .audio_codec = AV_CODEC_ID_FLAC,
> -.video_codec = AV_CODEC_ID_NONE,
> +.video_codec = AV_CODEC_ID_PNG,
> .write_header = flac_write_header,
> .write_packet = flac_write_packet,
> .write_trailer = flac_write_trailer,
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: fix gbrap16 alpha channel issues
Hi,
On 02/08/17 14:18, Michael Niedermayer wrote:
> On Tue, Aug 01, 2017 at 02:46:22PM +0100, James Cowgill wrote:
>> Fixes filter-pixfmts-scale test failing on big-endian systems due to
>> alpSrc not being cast to (const int32_t**).
>>
>> Also fixes distortions in the output alpha channel values by copying the
>> alpha channel code from the rgba64 case found elsewhere in output.c.
>>
>> Fixes ticket 6555.
>>
>> Signed-off-by: James Cowgill
>> ---
>> libswscale/output.c | 15 ---
>> tests/ref/fate/filter-pixfmts-scale | 4 ++--
>> 2 files changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/libswscale/output.c b/libswscale/output.c
>> index 9774e9f327..8e5ec0a256 100644
>> --- a/libswscale/output.c
>> +++ b/libswscale/output.c
>> @@ -2026,17 +2026,18 @@ yuv2gbrp16_full_X_c(SwsContext *c, const int16_t
>> *lumFilter,
>> const int16_t **lumSrcx, int lumFilterSize,
>> const int16_t *chrFilter, const int16_t **chrUSrcx,
>> const int16_t **chrVSrcx, int chrFilterSize,
>> -const int16_t **alpSrc, uint8_t **dest,
>> +const int16_t **alpSrcx, uint8_t **dest,
>> int dstW, int y)
>> {
>> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(c->dstFormat);
>> int i;
>> -int hasAlpha = (desc->flags & AV_PIX_FMT_FLAG_ALPHA) && alpSrc;
>> +int hasAlpha = (desc->flags & AV_PIX_FMT_FLAG_ALPHA) && alpSrcx;
>> uint16_t **dest16 = (uint16_t**)dest;
>> const int32_t **lumSrc = (const int32_t**)lumSrcx;
>> const int32_t **chrUSrc = (const int32_t**)chrUSrcx;
>> const int32_t **chrVSrc = (const int32_t**)chrVSrcx;
>> -int A = 0; // init to silence warning
>> +const int32_t **alpSrc = (const int32_t**)alpSrcx;
>
>> +int A = 0x << 14;
>
> unused value
The initial value of A is unused in the old code, but not in the new code.
>>
>> for (i = 0; i < dstW; i++) {
>> int j;
>> @@ -2059,13 +2060,13 @@ yuv2gbrp16_full_X_c(SwsContext *c, const int16_t
>> *lumFilter,
>> V >>= 14;
>>
>> if (hasAlpha) {
>> -A = 1 << 18;
>> +A = -0x4000;
>
> where does this value come from ?
> it looks copy and pasted from luma, but alpha does not have a black
> level offset as its not luminance
I confess I only know the basics of how these functions work. On the
basis that yuv2gbrp_full_X_c looks like it copies yuv2rgb_X_c_template,
and I would have thought the rgb and gbr cases should be similar, I
copied a number of things from yuv2rgba64_full_X_c_template into this
function. That value and all of the modifications inside the for loop
come from there.
>>
>> for (j = 0; j < lumFilterSize; j++)
>> A += alpSrc[j][i] * lumFilter[j];
>>
>> -if (A & 0xF800)
>> -A = av_clip_uintp2(A, 27);
>> +A >>= 1;
>> +A += 0x20002000;
>> }
>>
>> Y -= c->yuv2rgb_y_offset;
>> @@ -2083,7 +2084,7 @@ yuv2gbrp16_full_X_c(SwsContext *c, const int16_t
>> *lumFilter,
>> dest16[1][i] = B >> 14;
>> dest16[2][i] = R >> 14;
>> if (hasAlpha)
>> -dest16[3][i] = A >> 11;
>> +dest16[3][i] = av_clip_uintp2(A, 30) >> 14;
>
> why do you move the cliping code here, this seems unneeded
> outside the removed if()
This is where the clipping code in yuv2rgba64_full_X_c_template is, and
in that function, the value of A is not clipped - only the value stored
in dest.
Thanks,
James
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Wed, Aug 2, 2017 at 3:30 PM, Jorge Ramirez wrote: > On 08/02/2017 02:43 PM, Hendrik Leppkes wrote: >> >> On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez >> wrote: >>> >>> On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: > > From: Alexis Ballier > > This patchset enhances Alexis Ballier's original patch and validates > it using Qualcomm's Venus hardware (driver recently landed upstream > [1]). > > This has been tested on Qualcomm's DragonBoard 410c and 820c > > Tested decoders: > - h264 > - mpeg4 > - vp8 > - vp9 > - hevc > > Tested encoders: > -h264 > -h263 > -mpeg4 > > Tested transcoding (concurrent encoding/decoding) > > Some of the changes introduced: > - v4l2: code cleanup. > - v4l2: follow the decode api. > - v4l2: fix display size for NV12 output pool. > - v4l2: handle EOS. > - v4l2: vp8 and mpeg4 decoding. > - v4l2: hevc and vp9 support. > - v4l2: generate EOF on dequeue errors. > - v4l2: h264_mp4toannexb filtering. > - v4l2: import compat/v4l2 header files. > > [1] https://lwn.net/Articles/697956/ > > Reviewed-by: Jorge Ramirez > Reviewed-by: Alexis Ballier > Tested-by: Jorge Ramirez > --- >Changelog |3 +- >compat/v4l2/v4l2-common.h | 107 ++ >compat/v4l2/v4l2-controls.h | 987 + >compat/v4l2/videodev2.h | 2402 > + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. >>> >>> Hi Hendrik, >>> >>> but what is wrong with convenience? as a matter of fact, this will not >>> add >>> any 'major' maintenance task. >>> Only when the ffmpeg v4l2 support is modified to add a more recent call >>> (or >>> some new fourcc) these headers will have to be updated accordingly (ie do >>> a >>> copy paste for files that are easily avaialable) >>> >>> IMO, this seems much easier, less error prone - and consistent - than >>> modifying configure every time looking for what needs to be checked >>> before >>> building. >>> >> You could bring that argument for every single external library/API we >> support, and that is just not something we should be doing. >> We require headers to be available in the system for practically every >> other external API/library with only very few exceptions which have >> extraordinary circumstances beyond "I don't want to maintain configure >> checks". > > > but that is not a reason I have given - ie not wanting to maintain > "configure", that is some interpretation of the conclusion.. (I think you > got causation the other way around on this :)) The way I see it maintaining > configure for V4L2 API just seems less efficient and more error prone - and > more work for everyone with no real gains. > > Let me try highlighting some benefits IMHO of importing the V4L2 API (also > notice that this is the linux kernel API - we are not talking about some HW > vendor specs that we want to import through some backdoor, these files are > well maintained) > > 1. reduction in the frequency of the maintenance tasks. > When they need to be performed (ie new format or fourcc or whatever), the > user will be updating for the future since it will import many other > updates. > -> You can't say the same about maintaining configure. > > 2. the build environment is always sane no matter where you build. > This translates in more extensive testing since it enables building on more > environments. > -> You can't say the same about checking against whatever API was installed > in the build environment (could be 8 years old) > > 3. you can build encoders natively on a 14.04 server running a 3.3 kernel > and execute them on a target running a recent kernel > -> that can't be done the way you propose > > And since the kernel guarantees that will not break userspace, there is zero > risk to the users if we import the V4L2 API just as other projects have > done. > The key argument for me is: What makes V4L2 so special that it warrants doing this, while practically every other library or API on Linux did not propose importing its headers for "conevenience"? I do not see any reason that makes this any more special then any other API we support. All your reasons come down to the same conclusion for me - its just "easier" to not worry about it, which isn't really a reason to copy hundreds of lines of headers into our codebase. You yourself say that these files are well maintained, which is even less reason to import them, since the system is going to have this well-maintained version. All the three points you listed could be named for every other external library a
Re: [FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter
Hi, On Aug 2, 2017 19:18, "Nicolas George" wrote: Le quintidi 15 thermidor, an CCXXV, Ashish Pratap Singh a écrit : > +FFDualInputContext dinput; dualinput is about to be removed, please see the patch series two days ago. Regards, -- Ok Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 04:34 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 3:30 PM, Jorge Ramirez wrote: On 08/02/2017 02:43 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez wrote: On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: From: Alexis Ballier This patchset enhances Alexis Ballier's original patch and validates it using Qualcomm's Venus hardware (driver recently landed upstream [1]). This has been tested on Qualcomm's DragonBoard 410c and 820c Tested decoders: - h264 - mpeg4 - vp8 - vp9 - hevc Tested encoders: -h264 -h263 -mpeg4 Tested transcoding (concurrent encoding/decoding) Some of the changes introduced: - v4l2: code cleanup. - v4l2: follow the decode api. - v4l2: fix display size for NV12 output pool. - v4l2: handle EOS. - v4l2: vp8 and mpeg4 decoding. - v4l2: hevc and vp9 support. - v4l2: generate EOF on dequeue errors. - v4l2: h264_mp4toannexb filtering. - v4l2: import compat/v4l2 header files. [1] https://lwn.net/Articles/697956/ Reviewed-by: Jorge Ramirez Reviewed-by: Alexis Ballier Tested-by: Jorge Ramirez --- Changelog |3 +- compat/v4l2/v4l2-common.h | 107 ++ compat/v4l2/v4l2-controls.h | 987 + compat/v4l2/videodev2.h | 2402 + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. Hi Hendrik, but what is wrong with convenience? as a matter of fact, this will not add any 'major' maintenance task. Only when the ffmpeg v4l2 support is modified to add a more recent call (or some new fourcc) these headers will have to be updated accordingly (ie do a copy paste for files that are easily avaialable) IMO, this seems much easier, less error prone - and consistent - than modifying configure every time looking for what needs to be checked before building. You could bring that argument for every single external library/API we support, and that is just not something we should be doing. We require headers to be available in the system for practically every other external API/library with only very few exceptions which have extraordinary circumstances beyond "I don't want to maintain configure checks". but that is not a reason I have given - ie not wanting to maintain "configure", that is some interpretation of the conclusion.. (I think you got causation the other way around on this :)) The way I see it maintaining configure for V4L2 API just seems less efficient and more error prone - and more work for everyone with no real gains. Let me try highlighting some benefits IMHO of importing the V4L2 API (also notice that this is the linux kernel API - we are not talking about some HW vendor specs that we want to import through some backdoor, these files are well maintained) 1. reduction in the frequency of the maintenance tasks. When they need to be performed (ie new format or fourcc or whatever), the user will be updating for the future since it will import many other updates. -> You can't say the same about maintaining configure. 2. the build environment is always sane no matter where you build. This translates in more extensive testing since it enables building on more environments. -> You can't say the same about checking against whatever API was installed in the build environment (could be 8 years old) 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and execute them on a target running a recent kernel -> that can't be done the way you propose And since the kernel guarantees that will not break userspace, there is zero risk to the users if we import the V4L2 API just as other projects have done. The key argument for me is: What makes V4L2 so special that it warrants doing this, while practically every other library or API on Linux did not propose importing its headers for "conevenience"? I am probably not the best person to discuss why other libraries/codecs are managed the way they are(I lack the background and I would probably be spawning discussions that have been already had); If they use configure I _suppose_ it might be because those "apis" do not risk/benefit from being extended with every single kernel version (I used the word extended intentionally - API open for extension, closed for modification)...so they wont leverage the kernel's development cycle. Really I can only comment on why I think V4L2 should be handled the way I propose. And that is what I tried to justify. I am hoping the maintainers to provide me with a reason for not doing it this way. I do not see any reason that makes this any more special then any other API we support. All your reasons come down to the same conclusion for me - its just "easier" to not worry about it, which isn't rea
Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm
On Tue, Aug 1, 2017 at 11:46 PM, Ivan Kalvachev wrote:
> On 7/31/17, Henrik Gramner wrote:
>> Use rN instead of rNq for numbered registers (q suffix is used for
>> named args only due to preprocessor limitations).
>
> Is this documented?
Not sure, but there's probably a bunch small things like this that
aren't really well documented.
>> Use the same "standard" vertical alignment rules as most existing
>> code, e.g. instructions indented by 4 spaces and operands aligned on
>> the first comma.
>
> What do you mean operands aligned on the first comma?
> The longest operand I had is "xmm0" , counting comma and space
> I get 6 position alignment for operands.
> Now, with "xm7" i can lower this to 5 position. Should I do that?
> (I don't have "xm15" ).
>
1234_1234_1234_123
VBROADCASTSS ym1, xm1
BLENDVPS m1, m2, m3
is the most commonly used alignment.
>> Unless aligning every single loop entry helps a lot I'd avoid it since
>> it does waste a bit of icache.
>
> I'll redo my benchmarks, but I have placed these aligns for a reason.
> At some point removed debug instructions started making my code
> slower. So I've placed align to avoid random slowdowns.
Ok.
>> Explicitly using the carry flag as a branch condition is a bit weird.
>> Generally using jg/jl/jge/jle tends to be clearer.
>
> I use it to take advantage of the so called MacroFusion.
> It allows the merge of cmp and jxx, as long as the branch
> checks only one flag, so all signed branches are to be avoided
> (as stated by intel manual).
> The newer the cpu, the more opcodes (add/sub)
> could be merged and less limitations.
Every µarch that can do macro-op fusion with add/sub can do so with
both signed and unsigned branch conditions.
There's actually only a single µarch that can fuse cmp with unsigned
but not signed branch conditions and that's more than a decade old
(Conroe), but if you want to check if (unsigned)a < (unsigned)b 'jb'
is preferred of 'jc' (both produce the exact same opcode).
>> Assembler-specific ifdeffery should be avoided in individual files.
>> Something equivalent already exists in x86inc actually but I don't
>> remember if it was merged to FFmpeg from upstream (x264) yet.
>
> Definitely not merged.
>
> I hear a lot about the improved x86inc,
> maybe it is time for you to merge it in FFmpeg?
Now that I think about it I believe that part wasn't merged because
smartalign is broken on some older nasm versions (which is another
reason for avoiding things like this in individual files) and FFmpeg
doesn't enforce any specific version requirements. I guess it could be
worked around with some version checking ifdeffery if we know which
versions are affected.
>> Isn't this just an overly complicated way of expressing "dd 0*4, 1*4,
>> 2*4, 3*4, 4*4, 5*4, 6*4, 7*4"?
>
> Yes.
> Do you know a way that works with "times 8"?
> I've done it this way to make it easy to change the size of the constant.
>
> Do you request I change it?
I'd prefer just using that simple one-liner I posted. Replacing the
numbers if you want to change things later is trivial.
>> Is reordering moves for the non-AVX path worth the additional
>> complexity? Microoptimizations that only affect legacy hardware are
>> IMO a bit questionable.
>
> Yes, I'm on "legacy" hardware and the improvement is reliably measurable.
Ok, in that case you should also use shufps/addps instead of
vshufps/vaddps in the AVX branch for cosmetic reasons though (x86inc
performs automatic VEX-encoding).
>> The AVX1 integer warning is kind of silly and doesn't really serve any
>> purpose.
>
> As I've said in this thread before,
> If you use avx1 ymm with this macro
> you won't get any warning that avx2 opcode has been generated
> because x86inc does not overload avx2.
Sure, but using any other AVX2 instruction in AVX functions wont
result in any warnings either so it doesn't make much sense to do it
in this specific case.
>> Use the existing x86util VBROADCASTSS macro. Modify it if it's lacking
>> something.
>
> The x86util VBROADCASTSS macro implements only
> the avx1 variant that is memory to register.
> My variant emulates the avx2 variant,
> that also does reg to reg.
>
> My variant also avoids write dependency on "movss reg, reg".
> ("movss reg, mem" clears the other elements, but
> "movss reg, reg" preserves them. This creates dependency on the old
> values of the register.)
>
> And yes, I did ask if I should separate
> these macros in another file and
> if I should try to merge them in x86util.asm first.
>
> What do you think on the matter?
Add your improvements to the existing x86util macro (can be done in
the same patch) and then use that.
>> +%macro EMU_pbroadcastd 2 ; dst, src
>> +%if cpuflag(avx2)
>> + vpbroadcastd %1, %2
>> +%elif cpuflag(avx) && mmsize >= 32
>> +%error AVX1 does not support integer 256 bit ymm operations
>> +%else
>> + %ifnum sizeof%2 ; sse2 register
>> +pshufd %1, %2, q
>> + %else
[FFmpeg-devel] [PATCH v4 2/3] speedhq: add FATE tests
Also add simple FATE tests, based on output produced by the NDI SDK. --- tests/Makefile | 1 + tests/fate/speedhq.mak | 7 +++ tests/ref/fate/speedhq-422 | 6 ++ tests/ref/fate/speedhq-422-singlefield | 6 ++ 4 files changed, 20 insertions(+) create mode 100644 tests/fate/speedhq.mak create mode 100644 tests/ref/fate/speedhq-422 create mode 100644 tests/ref/fate/speedhq-422-singlefield diff --git a/tests/Makefile b/tests/Makefile index ab83ae855d..f9b9cf4188 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -164,6 +164,7 @@ include $(SRC_PATH)/tests/fate/qt.mak include $(SRC_PATH)/tests/fate/qtrle.mak include $(SRC_PATH)/tests/fate/real.mak include $(SRC_PATH)/tests/fate/screen.mak +include $(SRC_PATH)/tests/fate/speedhq.mak include $(SRC_PATH)/tests/fate/source.mak include $(SRC_PATH)/tests/fate/subtitles.mak include $(SRC_PATH)/tests/fate/utvideo.mak diff --git a/tests/fate/speedhq.mak b/tests/fate/speedhq.mak new file mode 100644 index 00..3394782809 --- /dev/null +++ b/tests/fate/speedhq.mak @@ -0,0 +1,7 @@ +FATE_SPEEDHQ = fate-speedhq-422 \ + fate-speedhq-422-singlefield \ + +fate-speedhq: $(FATE_SPEEDHQ) + +fate-speedhq-422: CMD = framecrc -flags +bitexact -f rawvideo -codec speedhq -vtag SHQ2 -video_size 112x64 -i $(TARGET_SAMPLES)/speedhq/progressive.shq2 -pix_fmt yuv422p +fate-speedhq-422-singlefield: CMD = framecrc -flags +bitexact -f rawvideo -codec speedhq -vtag SHQ2 -video_size 112x32 -i $(TARGET_SAMPLES)/speedhq/singlefield.shq2 -pix_fmt yuv422p diff --git a/tests/ref/fate/speedhq-422 b/tests/ref/fate/speedhq-422 new file mode 100644 index 00..7bb0d2388d --- /dev/null +++ b/tests/ref/fate/speedhq-422 @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 112x64 +#sar 0: 0/1 +0, 0, 0,1,14336, 0x9bb6dc6d diff --git a/tests/ref/fate/speedhq-422-singlefield b/tests/ref/fate/speedhq-422-singlefield new file mode 100644 index 00..343c52645c --- /dev/null +++ b/tests/ref/fate/speedhq-422-singlefield @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 112x32 +#sar 0: 0/1 +0, 0, 0,1, 7168, 0x75de4109 -- 2.13.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4 3/3] Add myself as speedhq maintainer, per request.
--- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ae0e08d121..ce5e1dae08 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -233,6 +233,7 @@ Codecs: smvjpegdec.c Ash Hughes snow* Michael Niedermayer, Loren Merritt sonic.c Alex Beregszaszi + speedhq.c Steinar H. Gunderson srt* Aurelien Jacobs sunrast.c Ivo van Poorten svq3.cMichael Niedermayer @@ -598,6 +599,7 @@ Reynaldo H. Verdejo Pinochet 6E27 CD34 170C C78E 4D4F 5F40 C18E 077F 3114 452A Robert Swain EE7A 56EA 4A81 A7B5 2001 A521 67FA 362D A2FC 3E71 Sascha Sommer 38A0 F88B 868E 9D3A 97D4 D6A0 E823 706F 1E07 0D3C Stefano Sabatini 0D0B AD6B 5330 BBAD D3D6 6A0C 719C 2839 FC43 2D5F +Steinar H. Gunderson C2E9 004F F028 C18E 4EAD DB83 7F61 7561 7797 8F76 Stephan Hilb 4F38 0B3A 5F39 B99B F505 E562 8D5C 5554 4E17 8863 Tiancheng "Timothy" Gu9456 AFC0 814A 8139 E994 8351 7FE6 B095 B582 B0D4 Tim Nicholson 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 -- 2.13.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4 1/3] speedhq: fix behavior of single-field decoding
The height convention for decoding frames with only a single field made sense
for compatibility with legacy decoders, but doesn't really match the convention
used by NDI, which is the primary (only?) user. Thus, change it to simply
assuming that if the two fields overlap, the frame is meant to be a single
field and the frame height matches the field height.
Also add simple FATE tests, based on output produced by the NDI SDK.
---
libavcodec/speedhq.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 60efb0222b..eca45beb67 100644
--- a/libavcodec/speedhq.c
+++ b/libavcodec/speedhq.c
@@ -448,12 +448,15 @@ static int speedhq_decode_frame(AVCodecContext *avctx,
frame->key_frame = 1;
if (second_field_offset == 4) {
-/*
- * Overlapping first and second fields is used to signal
- * encoding only a single field (the second field then comes
- * as a separate, later frame).
- */
-frame->height >>= 1;
+ /*
+* Overlapping first and second fields is used to signal
+* encoding only a single field. In this case, "height"
+* is ambiguous; it could mean either the height of the
+* frame as a whole, or of the field. The former would make
+* more sense for compatibility with legacy decoders,
+* but this matches the convention used in NDI, which is
+* the primary user of this trick.
+*/
if ((ret = decode_speedhq_field(s, buf, buf_size, frame, 0, 4,
buf_size, 1)) < 0)
return ret;
} else {
--
2.13.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
Le quintidi 15 thermidor, an CCXXV, Jorge Ramirez a écrit : Could at least one of you trim their mail once in a while please? > I am probably not the best person to discuss why other libraries/codecs are > managed the way they are(I lack the background and I would probably be > spawning discussions that have been already had); We could ask it the other way around: do you propose that every single application that wants to use v4l should duplicate its headers? And, for that matter, the headers of all the libraries it uses? > If they use configure I _suppose_ it might be because those "apis" do not > risk/benefit from being extended with every single kernel version (I used > the word extended intentionally - API open for extension, closed for > modification)...so they wont leverage the kernel's development cycle. If the new v4l APIs are so unstable that they break compatibility at every single kernel version, then maybe they are not yet mature enough for programs like FFmpeg. And if they are, we can just use the installed headers. > but sure, all my reasons lead to the same conclusion (isn't that how is > supposed to be in any coherent argument?). Exactly. And since the conclusions are obviously wrong, you can deduce the reasons are invalid. > but sure whatever system will have a well maintained version. > Only thing is, servers will have old copies of the API preventing users from > building (think kernel 3.13?) > > is this what the project wants? Only being able to build in a system that > "might" be able to run? It is better than duplicating the Universe. Regard, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
I am probably not the best person to discuss why other libraries/codecs are managed the way they are(I lack the background and I would probably be spawning discussions that have been already had); We could ask it the other way around: do you propose that every single application that wants to use v4l should duplicate its headers? And, for that matter, the headers of all the libraries it uses? how can I propose that "every single application duplicate headers" without knowing their use cases? that sort of generalization seems silly to me. there is no silver bullet to these kind of problems as you probably know. having said that, all the relevant applications that I know in fact do (ie, GStreamer, and other proprietary ones in the automotive industry) If they use configure I _suppose_ it might be because those "apis" do not risk/benefit from being extended with every single kernel version (I used the word extended intentionally - API open for extension, closed for modification)...so they wont leverage the kernel's development cycle. If the new v4l APIs are so unstable that they break compatibility at every single kernel version, then maybe they are not yet mature enough for programs like FFmpeg. nope, non sequitur. since when open for extension and closed for modification is unstable? is actually the opposite...and exactly the sort of thing I am asking that we take advantage of. And if they are, we can just use the installed headers. but sure, all my reasons lead to the same conclusion (isn't that how is supposed to be in any coherent argument?). Exactly. And since the conclusions are obviously wrong, you can deduce the reasons are invalid. :) why? I am still waiting for some actual reasoning on this matter. but sure whatever system will have a well maintained version. Only thing is, servers will have old copies of the API preventing users from building (think kernel 3.13?) is this what the project wants? Only being able to build in a system that "might" be able to run? It is better than duplicating the Universe. it depends...duplicating the Universe might serve its purpose (you seem to go blindly against duplication...dont you have two lungs?) anyway, if you and other maintainers want to simply use the "authority" card fine by me. lets save time and I will just modify configure (is a 5 minutes job) I just think is wrong and I am a bit surprised we could have no real argument on the matter. but please do confirm and I will amend the commit. Regard, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/examples/encode_video: add qsv encoder support
On 02/08/17 07:28, Nicolas George wrote: > L'octidi 8 thermidor, an CCXXV, Li, Zhong a écrit : >> It is similar to hw_device_match_type_in_name() in ffmpeg_hw.c: >> if (strstr(codec_name, type_name)) >>return type; > > I must say, I really do not like the idea of having an API example > making that terrible construct official. > > If testing the hw device type is really absolutely necessary in the API, > then we need some kind of avcodec_get_hw_type() function to do that > cleanly, before considering the API usable and documenting it. > > Testing the codec name in external code is a big no, testing part of it > for a three-letter substring even more so. Yes. The current API behaviour all assumes that the user knows what sort of device they want to supply for a given named codec. The use in ffmpeg is a temporary hack to avoid breaking existing devices while we decide how to express this properly in avcodec. A full solution would be something like adding a new public field to AVCodec with an array of possible device types and corresponding hardware pixfmts. The user can then supply a device of one of those types as AVCodecContext.hw_device_ctx, and see the matching pixfmt later in get_format() if it is supported. The qsv codecs would have AV_HWDEVICE_TYPE_QSV / AV_PIX_FMT_QSV in this field, hwaccelerable codecs could have multiple depending on the build configuration. (This is also solving the related problem that there isn't currently any way to know the matching pixfmt for a device type on a codec, hence for example the table in the hw_decode example.) I'll get around to finishing this off at some point in the not-too-distant future. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez wrote: > > I just think is wrong and I am a bit surprised we could have no real > argument on the matter. > I've asked for your arguments on why v4l2 is so special that it warrants special treatment above any other external library/headers, and I have not heard any that would differentiate v4l2 from anything else. If you can provide any, we can discuss those. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 07:40 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez wrote: I just think is wrong and I am a bit surprised we could have no real argument on the matter. I've asked for your arguments on why v4l2 is so special that it warrants special treatment above any other external library/headers, and I have not heard any that would differentiate v4l2 from anything else. If you can provide any, we can discuss those. [paste from previous exchange] 1. reduction in the frequency of the maintenance tasks. When they need to be performed (ie new format or fourcc or whatever), the user will be updating for the _future_ since it will import many other updates. -> You can't say the same about maintaining configure. 2. the build environment is always sane no matter where you build. This translates in more extensive testing since it enables building on more environments. -> You can't say the same about checking against whatever API was installed in the build environment (could be 8 years old) 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and execute them on a target running a recent kernel -> that can't be done the way you propose And since the kernel guarantees that will not break userspace, there is zero risk to the users if we import the V4L2 API just as other projects have done. (do you have this guarantee with all the other APIs that you are using?) - Hendrik ___ 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] Testing JPEG 2000 over MPEG TS
2017-08-02 14:07 GMT+02:00 Aaron Boxer : > On Sun, Jul 23, 2017 at 6:16 PM, Carl Eugen Hoyos wrote: > >> 2017-07-22 15:39 GMT+02:00 Aaron Boxer : >> >> > GStreamer project now has a working muxer/demuxer for >> > J2K over MPEG TS. >> >> Did you test it? > > I have acquired a test capture of VSF TR1 video from a nevion VS902: > > http://s3.amazonaws.com/fox_misc/aperi_tr01_1s_pkts-C.cap.gz What format is this? Could you provide the transport stream? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Testing JPEG 2000 over MPEG TS
On Wed, Aug 2, 2017 at 12:02 PM, Carl Eugen Hoyos wrote: > 2017-08-02 14:07 GMT+02:00 Aaron Boxer : > > On Sun, Jul 23, 2017 at 6:16 PM, Carl Eugen Hoyos wrote: > > > >> 2017-07-22 15:39 GMT+02:00 Aaron Boxer : > >> > >> > GStreamer project now has a working muxer/demuxer for > >> > J2K over MPEG TS. > >> > >> Did you test it? > > > > I have acquired a test capture of VSF TR1 video from a nevion VS902: > > > > http://s3.amazonaws.com/fox_misc/aperi_tr01_1s_pkts-C.cap.gz > > What format is this? > Could you provide the transport stream? > This is mpeg-ts (one second of video with no audio or other data) Video sub-stream is encoded with J2K. Is that what you meant about format ? Aaron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Testing JPEG 2000 over MPEG TS
Sorry, it looks like this is a packet capture of mpeg ts. On Wed, Aug 2, 2017 at 1:26 PM, Aaron Boxer wrote: > > > On Wed, Aug 2, 2017 at 12:02 PM, Carl Eugen Hoyos > wrote: > >> 2017-08-02 14:07 GMT+02:00 Aaron Boxer : >> > On Sun, Jul 23, 2017 at 6:16 PM, Carl Eugen Hoyos wrote: >> > >> >> 2017-07-22 15:39 GMT+02:00 Aaron Boxer : >> >> >> >> > GStreamer project now has a working muxer/demuxer for >> >> > J2K over MPEG TS. >> >> >> >> Did you test it? >> > >> > I have acquired a test capture of VSF TR1 video from a nevion VS902: >> > >> > http://s3.amazonaws.com/fox_misc/aperi_tr01_1s_pkts-C.cap.gz >> >> What format is this? >> Could you provide the transport stream? >> > > This is mpeg-ts (one second of video with no audio or other data) > Video sub-stream is encoded with J2K. > Is that what you meant about format ? > > Aaron > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [mov] Bail when invalid sample data is present.
2017-07-31 23:40 GMT+02:00 Dale Curtis : > [mov] Bail when invalid sample data is present. Could you provide such a sample? Could the patch stop demuxing samples that are supported so far? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 02.08.2017, at 19:53, Jorge Ramirez wrote: > On 08/02/2017 07:40 PM, Hendrik Leppkes wrote: >> On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez >> wrote: >>> I just think is wrong and I am a bit surprised we could have no real >>> argument on the matter. >>> >> I've asked for your arguments on why v4l2 is so special that it >> warrants special treatment above any other external library/headers, >> and I have not heard any that would differentiate v4l2 from anything >> else. >> If you can provide any, we can discuss those. > > [paste from previous exchange] > > 1. reduction in the frequency of the maintenance tasks. > When they need to be performed (ie new format or fourcc or whatever), the > user will be updating for the _future_ since it will import many other > updates. > -> You can't say the same about maintaining configure. Unless you know that the v4l2 headers never, ever, in any circumstance will have bug fixes, it is a HUGE maintenance effort: namely someone must continuously monitor upstream for such fixes and import them. Besides that I thought that importing files was commonly accepted to be a horrible practice. > 2. the build environment is always sane no matter where you build. > This translates in more extensive testing since it enables building on more > environments. > -> You can't say the same about checking against whatever API was installed > in the build environment (could be 8 years old) The flip side is it will be enabled and look to be available on systems where it CANNOT work. > 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and > execute them on a target running a recent kernel > -> that can't be done the way you propose Generally the solution is to have a proper cross-compile setup (or if you are really so lucky that everything else is close enough in versions, by adding an extra include path). > And since the kernel guarantees that will not break userspace, there is zero > risk to the users if we import the V4L2 API just as other projects have done. Only if the header is guaranteed bug-free. > (do you have this guarantee with all the other APIs that you are using?) Every library SHOULD have such guarantee as long as the major version is not being bumped, so in theory it's nothing special (though admittedly in practice most libraries are a lot more careless than kernel). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 10:51 PM, Reimar Döffinger wrote: On 02.08.2017, at 19:53, Jorge Ramirez wrote: On 08/02/2017 07:40 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez wrote: I just think is wrong and I am a bit surprised we could have no real argument on the matter. I've asked for your arguments on why v4l2 is so special that it warrants special treatment above any other external library/headers, and I have not heard any that would differentiate v4l2 from anything else. If you can provide any, we can discuss those. [paste from previous exchange] 1. reduction in the frequency of the maintenance tasks. When they need to be performed (ie new format or fourcc or whatever), the user will be updating for the _future_ since it will import many other updates. -> You can't say the same about maintaining configure. Unless you know that the v4l2 headers never, ever, in any circumstance will have bug fixes, it is a HUGE maintenance effort: namely someone must continuously monitor upstream for such fixes and import them. Besides that I thought that importing files was commonly accepted to be a horrible practice. well this is not the case. 2. the build environment is always sane no matter where you build. This translates in more extensive testing since it enables building on more environments. -> You can't say the same about checking against whatever API was installed in the build environment (could be 8 years old) The flip side is it will be enabled and look to be available on systems where it CANNOT work. unfortunately we will _always_ have that with the v4linux codecs. Only at runtime the user will discover if the codecs can be run in their platform 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and execute them on a target running a recent kernel -> that can't be done the way you propose Generally the solution is to have a proper cross-compile setup (or if you are really so lucky that everything else is close enough in versions, by adding an extra include path). sure but why not have it without requiring a cross compiler if we can get it for free... And since the kernel guarantees that will not break userspace, there is zero risk to the users if we import the V4L2 API just as other projects have done. Only if the header is guaranteed bug-free. ok, I feel like I am wasting everyones time (so I must be wrong then when this is so evident to everyone else...I must be getting old :) )...I will simply amend the commit and move on. thanks for you comments btw! (do you have this guarantee with all the other APIs that you are using?) Every library SHOULD have such guarantee as long as the major version is not being bumped, so in theory it's nothing special (though admittedly in practice most libraries are a lot more careless than kernel). ___ 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] [RFC]libswscale: Sanitize isRGBinInt() and isBGRinInt()
2017-07-25 21:27 GMT+02:00 Michael Niedermayer :
> On Mon, Jul 24, 2017 at 08:00:51PM +0200, Carl Eugen Hoyos wrote:
>> Attached is a PoC for a code simplification that imo makes a logic in
>> libswscale easier to read and also fixes the Big Endian fate failure.
>> If this approach is preferred, I will try to fix the five affected asm
>> functions.
>>
>> Please comment, Carl Eugen
>
> breaks: (blue faces)
> ./ffplay -i matrixbench_mpeg2.mpg
> -vf format=argb,scale=flags=16,format=rgb565
New PoC attached.
This breaks fate, if the change is wanted, 4158fba3
has to be reverted.
Please comment, Carl Eugen
diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c
index f7f8188..a974d64 100644
--- a/libswscale/rgb2rgb.c
+++ b/libswscale/rgb2rgb.c
@@ -133,8 +133,10 @@ void (*yuyvtoyuv422)(uint8_t *ydst, uint8_t *udst, uint8_t
*vdst,
av_cold void ff_sws_rgb2rgb_init(void)
{
rgb2rgb_init_c();
+/*
if (ARCH_X86)
rgb2rgb_init_x86();
+*/
}
void rgb32to24(const uint8_t *src, uint8_t *dst, int src_size)
@@ -142,16 +144,9 @@ void rgb32to24(const uint8_t *src, uint8_t *dst, int
src_size)
int i, num_pixels = src_size >> 2;
for (i = 0; i < num_pixels; i++) {
-#if HAVE_BIGENDIAN
-/* RGB32 (= A,B,G,R) -> BGR24 (= B,G,R) */
-dst[3 * i + 0] = src[4 * i + 1];
-dst[3 * i + 1] = src[4 * i + 2];
-dst[3 * i + 2] = src[4 * i + 3];
-#else
-dst[3 * i + 0] = src[4 * i + 2];
+dst[3 * i + 0] = src[4 * i + 0];
dst[3 * i + 1] = src[4 * i + 1];
-dst[3 * i + 2] = src[4 * i + 0];
-#endif
+dst[3 * i + 2] = src[4 * i + 2];
}
}
@@ -160,18 +155,10 @@ void rgb24to32(const uint8_t *src, uint8_t *dst, int
src_size)
int i;
for (i = 0; 3 * i < src_size; i++) {
-#if HAVE_BIGENDIAN
-/* RGB24 (= R, G, B) -> BGR32 (= A, R, G, B) */
-dst[4 * i + 0] = 255;
-dst[4 * i + 1] = src[3 * i + 0];
-dst[4 * i + 2] = src[3 * i + 1];
-dst[4 * i + 3] = src[3 * i + 2];
-#else
-dst[4 * i + 0] = src[3 * i + 2];
+dst[4 * i + 0] = src[3 * i + 0];
dst[4 * i + 1] = src[3 * i + 1];
-dst[4 * i + 2] = src[3 * i + 0];
+dst[4 * i + 2] = src[3 * i + 2];
dst[4 * i + 3] = 255;
-#endif
}
}
@@ -183,17 +170,10 @@ void rgb16tobgr32(const uint8_t *src, uint8_t *dst, int
src_size)
while (s < end) {
register uint16_t bgr = *s++;
-#if HAVE_BIGENDIAN
-*d++ = 255;
*d++ = ((bgr&0x001F)<<3) | ((bgr&0x001F)>> 2);
*d++ = ((bgr&0x07E0)>>3) | ((bgr&0x07E0)>> 9);
*d++ = ((bgr&0xF800)>>8) | ((bgr&0xF800)>>13);
-#else
-*d++ = ((bgr&0xF800)>>8) | ((bgr&0xF800)>>13);
-*d++ = ((bgr&0x07E0)>>3) | ((bgr&0x07E0)>> 9);
-*d++ = ((bgr&0x001F)<<3) | ((bgr&0x001F)>> 2);
*d++ = 255;
-#endif
}
}
@@ -258,17 +238,10 @@ void rgb15tobgr32(const uint8_t *src, uint8_t *dst, int
src_size)
while (s < end) {
register uint16_t bgr = *s++;
-#if HAVE_BIGENDIAN
-*d++ = 255;
*d++ = ((bgr&0x001F)<<3) | ((bgr&0x001F)>> 2);
*d++ = ((bgr&0x03E0)>>2) | ((bgr&0x03E0)>> 7);
*d++ = ((bgr&0x7C00)>>7) | ((bgr&0x7C00)>>12);
-#else
-*d++ = ((bgr&0x7C00)>>7) | ((bgr&0x7C00)>>12);
-*d++ = ((bgr&0x03E0)>>2) | ((bgr&0x03E0)>> 7);
-*d++ = ((bgr&0x001F)<<3) | ((bgr&0x001F)>> 2);
*d++ = 255;
-#endif
}
}
diff --git a/libswscale/rgb2rgb_template.c b/libswscale/rgb2rgb_template.c
index 499d25b..479474f 100644
--- a/libswscale/rgb2rgb_template.c
+++ b/libswscale/rgb2rgb_template.c
@@ -36,19 +36,11 @@ static inline void rgb24tobgr32_c(const uint8_t *src,
uint8_t *dst,
const uint8_t *end = s + src_size;
while (s < end) {
-#if HAVE_BIGENDIAN
-/* RGB24 (= R, G, B) -> RGB32 (= A, B, G, R) */
-*dest++ = 255;
*dest++ = s[2];
*dest++ = s[1];
*dest++ = s[0];
-s += 3;
-#else
-*dest++ = *s++;
-*dest++ = *s++;
-*dest++ = *s++;
*dest++ = 255;
-#endif
+s += 3;
}
}
@@ -60,19 +52,11 @@ static inline void rgb32tobgr24_c(const uint8_t *src,
uint8_t *dst,
const uint8_t *end = s + src_size;
while (s < end) {
-#if HAVE_BIGENDIAN
-/* RGB32 (= A, B, G, R) -> RGB24 (= R, G, B) */
-s++;
dest[2] = *s++;
dest[1] = *s++;
dest[0] = *s++;
dest+= 3;
-#else
-*dest++ = *s++;
-*dest++ = *s++;
-*dest++ = *s++;
s++;
-#endif
}
}
@@ -120,14 +104,14 @@ static inline void rgb16to15_c(const uint8_t *src,
uint8_t *dst, int src_size)
}
}
-static inline void rgb32to16_c(const uint8_t *src, uint8_t *dst, int src_size)
+static inline void rgb32tobgr16_c(const uint8_t *src, uint8_t *dst, int
src_size)
{
uint16_t *d= (uint16_t *)dst;
const uint8_t *s = src;
const uint8_t *end = s + src_size;
while (s <
Re: [FFmpeg-devel] [PATCH] swscale: fix gbrap16 alpha channel issues
On Wed, Aug 02, 2017 at 03:32:04PM +0100, James Cowgill wrote:
> Hi,
>
> On 02/08/17 14:18, Michael Niedermayer wrote:
> > On Tue, Aug 01, 2017 at 02:46:22PM +0100, James Cowgill wrote:
> >> Fixes filter-pixfmts-scale test failing on big-endian systems due to
> >> alpSrc not being cast to (const int32_t**).
> >>
> >> Also fixes distortions in the output alpha channel values by copying the
> >> alpha channel code from the rgba64 case found elsewhere in output.c.
> >>
> >> Fixes ticket 6555.
> >>
> >> Signed-off-by: James Cowgill
> >> ---
> >> libswscale/output.c | 15 ---
> >> tests/ref/fate/filter-pixfmts-scale | 4 ++--
> >> 2 files changed, 10 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/libswscale/output.c b/libswscale/output.c
> >> index 9774e9f327..8e5ec0a256 100644
> >> --- a/libswscale/output.c
> >> +++ b/libswscale/output.c
> >> @@ -2026,17 +2026,18 @@ yuv2gbrp16_full_X_c(SwsContext *c, const int16_t
> >> *lumFilter,
> >> const int16_t **lumSrcx, int lumFilterSize,
> >> const int16_t *chrFilter, const int16_t **chrUSrcx,
> >> const int16_t **chrVSrcx, int chrFilterSize,
> >> -const int16_t **alpSrc, uint8_t **dest,
> >> +const int16_t **alpSrcx, uint8_t **dest,
> >> int dstW, int y)
> >> {
> >> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(c->dstFormat);
> >> int i;
> >> -int hasAlpha = (desc->flags & AV_PIX_FMT_FLAG_ALPHA) && alpSrc;
> >> +int hasAlpha = (desc->flags & AV_PIX_FMT_FLAG_ALPHA) && alpSrcx;
> >> uint16_t **dest16 = (uint16_t**)dest;
> >> const int32_t **lumSrc = (const int32_t**)lumSrcx;
> >> const int32_t **chrUSrc = (const int32_t**)chrUSrcx;
> >> const int32_t **chrVSrc = (const int32_t**)chrVSrcx;
> >> -int A = 0; // init to silence warning
> >> +const int32_t **alpSrc = (const int32_t**)alpSrcx;
> >
> >> +int A = 0x << 14;
> >
> > unused value
>
> The initial value of A is unused in the old code, but not in the new code.
IIRC all uses are under hasAlpha and it is writen to in that case first
>
> >>
> >> for (i = 0; i < dstW; i++) {
> >> int j;
> >> @@ -2059,13 +2060,13 @@ yuv2gbrp16_full_X_c(SwsContext *c, const int16_t
> >> *lumFilter,
> >> V >>= 14;
> >>
> >> if (hasAlpha) {
> >> -A = 1 << 18;
> >> +A = -0x4000;
> >
> > where does this value come from ?
> > it looks copy and pasted from luma, but alpha does not have a black
> > level offset as its not luminance
>
> I confess I only know the basics of how these functions work. On the
> basis that yuv2gbrp_full_X_c looks like it copies yuv2rgb_X_c_template,
> and I would have thought the rgb and gbr cases should be similar, I
> copied a number of things from yuv2rgba64_full_X_c_template into this
> function. That value and all of the modifications inside the for loop
> come from there.
[...]
> This is where the clipping code in yuv2rgba64_full_X_c_template is, and
> in that function, the value of A is not clipped - only the value stored
> in dest.
hmm, ok, on a 2nd look this is probably correct
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [WIP] libcodec2 wrapper + de/muxer in FFmpeg
Hi Posting this to both [ffmpeg-devel] and [Freetel-codec2] in hopes of maximum feedback. I've been spending the last few days getting codec2 (http://freedv.org/ ) hooked up in libavcodec, and a set of muxers and demuxers for both raw codec2 streams and the recently created .c2 format. codec2 is very low bitrate (3200 bit/s down to 700 bit/s) speech codec developed for digital voice in amateur radio, but is now finding use in other applications where compressing large amounts of human speech is useful (audiobooks or podcasts for example) Sample: http://www.nivex.net/images/tmp/report2074.c2 With both the raw demuxer and the encoder you need to specify the desired mode, like this: # Transcode .wav to .c2 ffmpeg -i foo.wav -mode 700C out.c2 # Transcode raw codec2 stream to .wav ffmpeg -mode 700C -i bar.raw out.wav Decoding a .c2 file is straightforward however, thanks to the header: ffmpeg -i report2074.c2 out.wav There's one issue currently which I suspect is due to timestamping, where the demuxer seems to lose track of the block_align grid: $ ./ffmpeg -i report2074.c2 /tmp/out.wav ... Output #0, wav, to '/tmp/out.wav': Metadata: ISFT: Lavf57.77.100 Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 8000 Hz, mono, s16, 128 kb/s Metadata: encoder : Lavc57.103.100 pcm_s16le [libcodec2 @ 0x561d7bc4d1e0] Multiple frames in a packet [libcodec2 @ 0x561d7bc4d1e0] get_buffer() failed Error while decoding stream #0:0: Invalid argument [libcodec2 @ 0x561d7bc4d1e0] get_buffer() failed Error while decoding stream #0:0: Invalid argument [libcodec2 @ 0x7f59c0015840] Multiple frames in a packet. [libcodec2 @ 0x7f59c0015840] get_buffer() failed I plan on looking into this once I've had some sleep. Some remarks: * I had to make the ffmpeg CLI not complain about the 700 modes, since it thinks encoding at below 1 kbps is a user error * I have duplicated some minor functions in libcodec2 in libavcodec/codec2utils.*. This avoid having to link libcodec2 just for remuxing, and in case someone writes a native decoder for libavcodec * Not sure if codec2utils should go in libavutil, libavcodec felt good enough * The demuxer tries to read up to 0.1 seconds worth of frames to speed things up a little without making seeking too broken. 3 frames = 12 bytes for the 700 bit/s modes, which decode to 960 samples * The decoder is able to deal with multiple frames at a time, the encoder does not need to * The .c2 format is still fairly experimental, but the version bytes should be enough to deal with any potential future variants Feel free to bikeshed around whether extradata should be the entire .c2 header or just the mode byte. It really only matters if we go with RIFF or ISOM mappings (.wav .avi .mov and friends), which I decided to leave out for now. /TomasFrom 569a252536ea224bcd44f55f0f5102ce1aa4ec77 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Wed, 2 Aug 2017 22:17:19 +0200 Subject: [PATCH] Add codec2 muxers, demuxers and en/decoder via libcodec2 --- Changelog| 2 + configure| 12 +++ doc/general.texi | 13 +++ ffmpeg.c | 3 +- libavcodec/Makefile | 3 + libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h | 1 + libavcodec/codec2utils.c | 118 +++ libavcodec/codec2utils.h | 58 +++ libavcodec/codec_desc.c | 7 ++ libavcodec/libcodec2.c | 190 libavcodec/version.h | 2 +- libavformat/Makefile | 4 + libavformat/allformats.c | 2 + libavformat/codec2.c | 244 +++ libavformat/rawenc.c | 14 +++ libavformat/utils.c | 1 + libavformat/version.h| 2 +- 18 files changed, 674 insertions(+), 3 deletions(-) create mode 100644 libavcodec/codec2utils.c create mode 100644 libavcodec/codec2utils.h create mode 100644 libavcodec/libcodec2.c create mode 100644 libavformat/codec2.c diff --git a/Changelog b/Changelog index 187ae7950a..e28da7dcc4 100644 --- a/Changelog +++ b/Changelog @@ -29,6 +29,8 @@ version : - limiter video filter - libvmaf video filter - Dolby E decoder and SMPTE 337M demuxer +- codec2 en/decoding via libcodec2 +- muxer/demuxer for raw codec2 files and .c2 files version 3.3: - CrystalHD decoder moved to new decode API diff --git a/configure b/configure index 66c7b948e4..05af25cb22 100755 --- a/configure +++ b/configure @@ -220,6 +220,7 @@ External library support: --enable-libcaca enable textual display using libcaca [no] --enable-libcelt enable CELT decoding via libcelt [no] --enable-libcdio enable audio CD grabbing with libcdio [no] + --enable-libcodec2 enable codec2 en/decoding using libcodec2 [no] --enable-libdc1394 enable IIDC-1394 grabbing using libdc1394 and libraw1394 [no] --enable-
Re: [FFmpeg-devel] [WIP] libcodec2 wrapper + de/muxer in FFmpeg
2017-08-03 0:40 GMT+02:00 Tomas Härdin : > Decoding a .c2 file is straightforward however, thanks to the header: > > ffmpeg -i report2074.c2 out.wav The probe score is too high. I suspect you should also check for the major version, the score should be MAX/2 if the first 32bit are ok, significantly less for 24bit. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swscale/utils.c: Fix incorrect error when calling sws_setColorspaceDetails
Fixes: When converting yuv -> yuv and changing any of srcRange,
dstRange, brightness, contrast, or saturation the context would not be
re-initialized as required.
---
libswscale/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 17c9967..9071d3a 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -959,6 +959,9 @@ int sws_setColorspaceDetails(struct SwsContext *c, const
int inv_table[4],
srcRange, table, dstRange,
0, 1 << 16, 1 << 16);
return 0;
+} else if (!c->cascaded_context[0] && c->srcW && c->srcH && c->dstW &&
c->dstH) {
+int ret = sws_init_context(c, NULL, NULL);
+return ret;
}
return -1;
}
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 02/08/17 08:32, Jorge Ramirez-Ortiz wrote:
> ...
> diff --git a/compat/v4l2/v4l2-common.h b/compat/v4l2/v4l2-common.h
> diff --git a/compat/v4l2/videodev2.h b/compat/v4l2/videodev2.h
These are discussed in other threads. I don't really have any comment either
way.
> diff --git a/configure b/configure
> index ed94de0..650c8fb 100755
> --- a/configure
> +++ b/configure
> @@ -10,7 +10,6 @@
> # Prevent locale nonsense from breaking basic text processing.
> LC_ALL=C
> export LC_ALL
> -
Spurious change?
> # make sure we are running under a compatible shell
> # try to make this part work with most shells
>
> @@ -149,6 +148,7 @@ Component options:
>--disable-pixelutils disable pixel utils in libavutil
>
> Individual component options:
> + --disable-v4l2_m2m disable V4L2 mem2mem code [autodetect]
s/_/-/ here.
>--disable-everything disable all components listed below
>--disable-encoder=NAME disable encoder NAME
>--enable-encoder=NAMEenable encoder NAME
> @@ -1432,6 +1432,7 @@ AVCODEC_COMPONENTS="
>
> AVDEVICE_COMPONENTS="
> indevs
> +v4l2_m2m
> outdevs
> "
> AVFILTER_COMPONENTS="
> @@ -2269,11 +2270,12 @@ map 'eval ${v}_inline_deps=inline_asm'
> $ARCH_EXT_LIST_ARM
>
> loongson2_deps="mips"
> loongson3_deps="mips"
> -v4l2_deps_any="linux_videodev2_h sys_videoio_h"
> +v4l2_m2m_select="v4l2"
> mipsfpu_deps="mips"
> mipsdsp_deps="mips"
> mipsdspr2_deps="mips"
> mips32r2_deps="mips"
> +vc1_v4l2m2m_decoder_deps="v4l2_m2m"
> mips32r5_deps="mips"
> mips32r6_deps="mips"
> mips64r2_deps="mips"
> @@ -2284,6 +2286,9 @@ mmi_deps="mips"
> altivec_deps="ppc"
> dcbzl_deps="ppc"
> ldbrx_deps="ppc"
> +vp8_v4l2m2m_decoder_deps="v4l2_m2m"
> +vp8_v4l2m2m_encoder_deps="v4l2_m2m"
> +vp9_v4l2m2m_decoder_deps="v4l2_m2m"
These seem to be placed randomly in the file. There is a hardware codec
section at around line 2800, put all of these declarations there.
> ppc4xx_deps="ppc"
> vsx_deps="altivec"
> power8_deps="vsx"
> @@ -2437,15 +2442,22 @@ h261_decoder_select="mpegvideo"
> h261_encoder_select="aandcttables mpegvideoenc"
> h263_decoder_select="h263_parser h263dsp mpegvideo qpeldsp"
> h263_encoder_select="aandcttables h263dsp mpegvideoenc"
> +h263_v4l2m2m_decoder_deps="v4l2_m2m"
> +h263_v4l2m2m_encoder_deps="v4l2_m2m"
> h263i_decoder_select="h263_decoder"
> h263p_decoder_select="h263_decoder"
> h263p_encoder_select="h263_encoder"
> h264_decoder_select="cabac golomb h264chroma h264dsp h264parse h264pred
> h264qpel videodsp"
> h264_decoder_suggest="error_resilience"
> +h264_v4l2m2m_decoder_deps="v4l2_m2m"
> +h264_v4l2m2m_encoder_deps="v4l2_m2m"
> hap_decoder_select="snappy texturedsp"
> hap_encoder_deps="libsnappy"
> hap_encoder_select="texturedspenc"
> hevc_decoder_select="bswapdsp cabac golomb hevcparse videodsp"
> +hevc_encoder_select="hevc_v4l2m2m"
> +hevc_v4l2m2m_decoder_deps="v4l2_m2m"
> +hevc_v4l2m2m_encoder_deps="v4l2_m2m"
> huffyuv_decoder_select="bswapdsp huffyuvdsp llviddsp"
> huffyuv_encoder_select="bswapdsp huffman huffyuvencdsp llvidencdsp"
> iac_decoder_select="imc_decoder"
> @@ -2482,6 +2494,7 @@ mpc7_decoder_select="bswapdsp mpegaudiodsp"
> mpc8_decoder_select="mpegaudiodsp"
> mpeg_xvmc_decoder_deps="X11_extensions_XvMClib_h"
> mpeg_xvmc_decoder_select="mpeg2video_decoder"
> +mpeg1_v4l2m2m_decoder_deps="v4l2_m2m"
> mpegvideo_decoder_select="mpegvideo"
> mpeg1video_decoder_select="mpegvideo"
> mpeg1video_encoder_select="aandcttables mpegvideoenc h263dsp"
> @@ -2489,6 +2502,8 @@ mpeg2video_decoder_select="mpegvideo"
> mpeg2video_encoder_select="aandcttables mpegvideoenc h263dsp"
> mpeg4_decoder_select="h263_decoder mpeg4video_parser"
> mpeg4_encoder_select="h263_encoder"
> +mpeg4_v4l2m2m_decoder_deps="v4l2_m2m"
> +mpeg4_v4l2m2m_encoder_deps="v4l2_m2m"
> msa1_decoder_select="mss34dsp"
> mscc_decoder_select="zlib"
> msmpeg4v1_decoder_select="h263_decoder"
> @@ -3042,7 +3057,6 @@ qtkit_indev_select="qtkit"
> sdl2_outdev_deps="sdl2"
> sndio_indev_deps="sndio"
> sndio_outdev_deps="sndio"
> -v4l_indev_deps="linux_videodev_h"
> v4l2_indev_select="v4l2"
> v4l2_outdev_select="v4l2"
> vfwcap_indev_deps="vfw32 vfwcap_defines"
> @@ -3592,7 +3606,7 @@ done
> enable_weak audiotoolbox
>
> # Enable hwaccels by default.
> -enable_weak d3d11va dxva2 vaapi vda vdpau videotoolbox_hwaccel xvmc
> +enable_weak d3d11va dxva2 vaapi v4l2_m2m vda vdpau videotoolbox_hwaccel xvmc
> enable_weak xlib
>
> enable_weak cuda cuvid nvenc vda_framework videotoolbox videotoolbox_encoder
> @@ -6058,12 +6072,10 @@ pod2man --help > /dev/null 2>&1 && enable pod2man
> || disable pod2man
> rsync --help 2> /dev/null | grep -q 'contimeout' && enable rsync_contimeout
> || disable rsync_contimeout
>
> check_header linux/fb.h
> -check_header linux/videodev.h
> -check_header linux/videodev2.h
> -check_code cc linux/videodev2.h "struct v4l2_frmsizeenum vfse;
> vfse.discrete.width = 0;" && enable_safe struct_v4l2_frmivalenum_dis
Re: [FFmpeg-devel] [PATCH v4 2/3] speedhq: add FATE tests
On Wed, Aug 02, 2017 at 06:08:46PM +0200, Steinar H. Gunderson wrote: > Also add simple FATE tests, based on output produced by the NDI SDK. > --- > tests/Makefile | 1 + > tests/fate/speedhq.mak | 7 +++ > tests/ref/fate/speedhq-422 | 6 ++ > tests/ref/fate/speedhq-422-singlefield | 6 ++ > 4 files changed, 20 insertions(+) > create mode 100644 tests/fate/speedhq.mak > create mode 100644 tests/ref/fate/speedhq-422 > create mode 100644 tests/ref/fate/speedhq-422-singlefield doesnt work make -j12 fate-speedhq make: *** No rule to make target `fate-speedhq-422', needed by `fate-speedhq'. Stop. make fate-speedhq-422-singlefield make: *** No rule to make target `fate-speedhq-422-singlefield'. Stop. make fate-list | grep speedhq [...] > diff --git a/tests/fate/speedhq.mak b/tests/fate/speedhq.mak > new file mode 100644 > index 00..3394782809 > --- /dev/null > +++ b/tests/fate/speedhq.mak > @@ -0,0 +1,7 @@ > +FATE_SPEEDHQ = fate-speedhq-422 \ > + fate-speedhq-422-singlefield \ > + > +fate-speedhq: $(FATE_SPEEDHQ) > + > +fate-speedhq-422: CMD = framecrc -flags +bitexact -f rawvideo > -codec speedhq -vtag SHQ2 -video_size 112x64 -i > $(TARGET_SAMPLES)/speedhq/progressive.shq2 -pix_fmt yuv422p > +fate-speedhq-422-singlefield: CMD = framecrc -flags +bitexact -f rawvideo > -codec speedhq -vtag SHQ2 -video_size 112x32 -i > $(TARGET_SAMPLES)/speedhq/singlefield.shq2 -pix_fmt yuv422p a FATE_SAMPLES_FFMPEG += ... line probably should be in there [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size
On Wed, Aug 2, 2017 at 6:48 PM, Tobias Rapp wrote: > On 02.08.2017 12:31, Muhammad Faiz wrote: >> >> On Wed, Aug 2, 2017 at 2:10 PM, Tobias Rapp >> wrote: >>> >>> On 01.08.2017 17:01, Muhammad Faiz wrote: Fix Ticket6519. Signed-off-by: Muhammad Faiz --- libavfilter/vf_ssim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c index c3c204268f..dfd276e015 100644 --- a/libavfilter/vf_ssim.c +++ b/libavfilter/vf_ssim.c @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) for (i = 0; i < s->nb_components; i++) s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); +s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); if (!s->temp) return AVERROR(ENOMEM); s->max = (1 << desc->comp[0].depth) - 1; >>> >>> I confirm that the command doesn't crash anymore and the reports of >>> "invalid >>> read/write" in Valgrind are gone. However there are still some "use of >>> uninitialized value" reports remaining. Maybe use av_mallocz_array? >> >> >> Changed locally with av_mallocz_array. > > > LGTM then. Thanks for the fix. Seems that this doesn't fix all cases. It fails with width=344. Will post new patch. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: align temp size
On Wed, Aug 2, 2017 at 8:57 PM, Ronald S. Bultje wrote: > Hi, > > On Wed, Aug 2, 2017 at 8:45 AM, Tobias Rapp wrote: > >> On 02.08.2017 14:04, Ronald S. Bultje wrote: >> >>> On Wed, Aug 2, 2017 at 3:10 AM, Tobias Rapp >>> wrote: >>> On 01.08.2017 17:01, Muhammad Faiz wrote: > Fix Ticket6519. > > Signed-off-by: Muhammad Faiz > --- > libavfilter/vf_ssim.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c > index c3c204268f..dfd276e015 100644 > --- a/libavfilter/vf_ssim.c > +++ b/libavfilter/vf_ssim.c > @@ -402,7 +402,7 @@ static int config_input_ref(AVFilterLink *inlink) > for (i = 0; i < s->nb_components; i++) > s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / > sum; > > -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * > (1 + (desc->comp[0].depth > 8))); > +s->temp = av_malloc_array(FFALIGN(2 * inlink->w + 12, 64), > sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); > if (!s->temp) > return AVERROR(ENOMEM); > s->max = (1 << desc->comp[0].depth) - 1; > > > I confirm that the command doesn't crash anymore and the reports of "invalid read/write" in Valgrind are gone. However there are still some "use of uninitialized value" reports remaining. Maybe use av_mallocz_array? >>> >>> >>> Wait wait, before we do that, which values are uninitialized and what are >>> they used for? >>> >> >> Reads into s->temp seem to use uninitialized values on x86-64 when >> vf_ssim.asm routines are used (-cpuflags all), see attached Valgrind >> report. When vf_ssim.asm is not used (-cpuflags 0) no "use of uninitialized >> value" is reported. >> >> The difference of the reported SSIM scores between my asm and non-asm test >> runs was <= 10^-6. > > > Which function is causing the warnings? Isit dsp->ssim_4x4_line() or > dsp->ssim_end_line()? (My gut feeling tells me it's ssim_4x4_line(), but I > don't understand why, since the result should be unused in > ssim_end_line().) It's really important to understand the source and > implication of these warnings before we silence them - they may be causing > actual inaccuracies in the result, which we don't want. Because ssim_4x4_line never reads sums, I think the warnings are caused by ssim_end_line. Looking at the asm code: ssim_4x4_line writes to sums 32-bytes per loop, while ssim_end_line reads sum0/sum1 64-bytes per loop + 16-bytes overread Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 1/3] speedhq: fix behavior of single-field decoding
On Wed, Aug 02, 2017 at 06:08:28PM +0200, Steinar H. Gunderson wrote:
> The height convention for decoding frames with only a single field made sense
> for compatibility with legacy decoders, but doesn't really match the
> convention
> used by NDI, which is the primary (only?) user. Thus, change it to simply
> assuming that if the two fields overlap, the frame is meant to be a single
> field and the frame height matches the field height.
>
> Also add simple FATE tests, based on output produced by the NDI SDK.
this line belongs to the ther patch
> ---
> libavcodec/speedhq.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
> index 60efb0222b..eca45beb67 100644
> --- a/libavcodec/speedhq.c
> +++ b/libavcodec/speedhq.c
> @@ -448,12 +448,15 @@ static int speedhq_decode_frame(AVCodecContext *avctx,
> frame->key_frame = 1;
>
> if (second_field_offset == 4) {
> -/*
> - * Overlapping first and second fields is used to signal
> - * encoding only a single field (the second field then comes
> - * as a separate, later frame).
> - */
> -frame->height >>= 1;
> + /*
tabs are not allowed in ffmpeg git (except makefiles)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avfilter/vf_ssim: fix temp size calculation
Also use av_mallocz_array. Fix Ticket6519. Signed-off-by: Muhammad Faiz --- libavfilter/vf_ssim.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c index c3c204268f..d8c049177c 100644 --- a/libavfilter/vf_ssim.c +++ b/libavfilter/vf_ssim.c @@ -219,6 +219,8 @@ static float ssim_endn_8bit(const int (*sum0)[4], const int (*sum1)[4], int widt return ssim; } +#define SUM_LEN(w) (((w) >> 2) + 3) + static float ssim_plane_16bit(SSIMDSPContext *dsp, uint8_t *main, int main_stride, uint8_t *ref, int ref_stride, @@ -228,7 +230,7 @@ static float ssim_plane_16bit(SSIMDSPContext *dsp, int z = 0, y; float ssim = 0.0; int64_t (*sum0)[4] = temp; -int64_t (*sum1)[4] = sum0 + (width >> 2) + 3; +int64_t (*sum1)[4] = sum0 + SUM_LEN(width); width >>= 2; height >>= 2; @@ -256,7 +258,7 @@ static float ssim_plane(SSIMDSPContext *dsp, int z = 0, y; float ssim = 0.0; int (*sum0)[4] = temp; -int (*sum1)[4] = sum0 + (width >> 2) + 3; +int (*sum1)[4] = sum0 + SUM_LEN(width); width >>= 2; height >>= 2; @@ -402,7 +404,7 @@ static int config_input_ref(AVFilterLink *inlink) for (i = 0; i < s->nb_components; i++) s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); +s->temp = av_mallocz_array(2 * SUM_LEN(inlink->w), (desc->comp[0].depth > 8) ? sizeof(int64_t[4]) : sizeof(int[4])); if (!s->temp) return AVERROR(ENOMEM); s->max = (1 << desc->comp[0].depth) - 1; -- 2.13.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale/utils.c: Fix incorrect error when calling sws_setColorspaceDetails
On Thu, Aug 03, 2017 at 12:18:01AM +0100, Mark Boorer wrote: > Fixes: When converting yuv -> yuv and changing any of srcRange, > dstRange, brightness, contrast, or saturation the context would not be > re-initialized as required. > --- > libswscale/utils.c | 3 +++ > 1 file changed, 3 insertions(+) have you confirmed that with this patch these parameters also work ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support
On 30.07.2017 17:19, Marton Balint wrote:
[...]
Subject: [PATCH] lavd: implement NewTek NDI muxer/demuxer support
lavd: implement NewTek NDI input/output device support
fixed
[...]
- Dolby E decoder and SMPTE 337M demuxer
+- NewTek NDI muxer/demuxer
NewTek NDI input/output device
fixed
[...]
+@item wait_sources
+Override time to wait until the number of online sources have changed.
+Defaults to @option{50}.
Defaults to @option{0.5} sec.
By the way, is this enough? SDK warns that it might take a few seconds
to list all the sources. SDK example uses 5 second, shouldn't we us that
as well as the default?
we can increase it after... but from my tests it is enough. moreover, i
did some rework of /waiting process/
+@item max_frames_probe
+Maximum frames for probe input format.
+Defaults to @option{25}.
This option is no longer needed/used.
fixed
[...]
+NDI is very picky about the formats it supports. Pixel format is always
+uyvy422. Audio sample rate is always 48 kHz.
Is there a real limitation to 48 kHz? You might support anything unless
there
is a good reason to restrict it to 48 kHz.
no limitation:
[...]
sample_rate (int)
This is the current audio sample rate. For instance, this might be
44100, 48000 or 96000. It can, however, be any value.
[...]
i will drop any checks of sample rate
+int max_frames_probe;
no longer needed.
done
[...]
+const NDIlib_find_create_t find_create_desc = { true, NULL };
for readability you should name your set fields, e.g. find_create_desc =
{ .show_local_sources = true };
done
[...]
+NDIlib_find_destroy(ndi_find);
Probably you should not destroy this here, only in ndi_read_close after
freeing
ctx->recv, because as far as I see the found NDIlib_source_t is might be
freed
here as well which you would also like to use after returning from this
function.
i moved ndi_find to context and destroying it moved to ndi_read_close
[...]
+const NDIlib_tally_t tally_state = { true, false };
for readability you should name your set fields
done
[...]
+st->time_base = NDI_TIME_BASE_Q;
+av_stream_set_r_frame_rate(st, av_make_q(v->frame_rate_N,
v->frame_rate_D));
+
+st->sample_aspect_ratio = st->codecpar->sample_aspect_ratio =
+av_mul_q(av_d2q(v->picture_aspect_ratio, INT_MAX),
(AVRational){v->yres, v->xres});
Since the source aspect ratio is float, and there are some very inaccurate
representations of 16/9 in the include files and sdk (e.g. 16/9 = 1.778),
I suggest we drop some precision here as well because we don't want to get
134217729:134217728 kind of sample aspect ratios.
Something like:
tmp = av_mul_q(av_d2q(v->picture_aspect_ratio, INT_MAX),
(AVRational){v->yres, v->xres});
av_reduce(&st->sample_aspect_ratio.num, &st->sample_aspect_ratio.den,
tmp.num, tmp.den, 1000);
done
[...]
+
+st->codecpar->codec_type= AVMEDIA_TYPE_VIDEO;
+st->codecpar->width = v->xres;
+st->codecpar->height= v->yres;
+st->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO;
+st->codecpar->bit_rate = av_rescale(v->xres * v->yres *
16, st->time_base.den, st->time_base.num);
Here you probably want to use frame rate instead of time base.
fixed
+//avpriv_set_pts_info(st, 64, 1, a->sample_rate);
stale line which can be removed
done
[...]
+if (ctx->ndi_send) {
+if (ctx->last_avframe) {
+/* send NULL to flush equeued frame */
+NDIlib_send_send_video_async(ctx->ndi_send, NULL);
This line crashes for me under x86_64 linux, it seems to dereference the
null
pointer. SDK bug?
yes, it is SDK (libndi.so.1.0.1) bug. SDK provided by request (seems
betta, libndi.so.3.0.1) has no this bug.
Maybe you should simply do:
NDIlib_send_destroy(ctx->ndi_send);
av_frame_free(&ctx->last_avframe);
Although I don't know if this flushes (sends) the last frame, or simply
drops
it... Anyhow, better than crashing, if you can't fix the crash.
done
[...]
+: (void *)(avframe->data[0]);
As NDI has no way of signalling a flipped image, I think it is best if you
simply reject frames with negative linesize.
may be warning will be enough?
+if (c->sample_rate != 48000) {
+av_log(avctx, AV_LOG_ERROR, "Unsupported sample rate!"
+ " Only 48kHz is supported.\n");
+return AVERROR(EINVAL);
+}
As I mentioned earlier, you should consider supporting any sample rate.
done
+
+ctx->audio =
av_mallocz(sizeof(NDIlib_audio_frame_interleaved_16s_t));
+if (!ctx->audio)
+return AVERROR(ENOMEM);
+
+ctx->audio->sample_rate = c->sample_rate;
+ctx->audio->no_channels = c->channels;
+ctx->audio->reference_level = ctx->reference_level;
+
+avpriv_set_pts_info(st, 64, 1, NDI_TIME_BASE/*c->sample_rate*/);
stale comment
cleaned
[...]
+ctx->video->xres = c->width;
+ctx->video->yres = c->height;
+ctx->video->frame_rate_
[FFmpeg-devel] [PATCH] avfilter/vf_libvmaf: fix pre convert to framesync2 bugs
From: Ashish Singh
Hi, it fixes the errors while converting to framesync2.
libvmaf was changed recently, double *score variable is removed in the new
version since it's not used anywhere. This patch fixes all the warnings and
segmentation faults.
Signed-off-by: Ashish Singh
---
libavfilter/vf_libvmaf.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c
index 3345cad..f2a8c9a 100644
--- a/libavfilter/vf_libvmaf.c
+++ b/libavfilter/vf_libvmaf.c
@@ -24,7 +24,6 @@
* Calculate the VMAF between two input videos.
*/
-#include
#include
#include
#include "libavutil/avstring.h"
@@ -84,11 +83,10 @@ static const AVOption libvmaf_options[] = {
AVFILTER_DEFINE_CLASS(libvmaf);
#define read_frame_fn(type, bits)
\
-static int read_frame_##bits##bit(float *ref_data, float *main_data,
\
- float *temp_data, int stride,
\
- double *score, void *ctx)
\
+static int read_frame_##bits##bit(float *ref_data, float *main_data,
\
+ float *temp_data, int stride, void *ctx)
\
{
\
-LIBVMAFContext *s = (LIBVMAFContext *) ctx;
\
+LIBVMAFContext *s = (LIBVMAFContext *) ctx;
\
int ret;
\
\
pthread_mutex_lock(&s->lock);
\
@@ -150,7 +148,7 @@ read_frame_fn(uint16_t, 10);
static void compute_vmaf_score(LIBVMAFContext *s)
{
int (*read_frame)(float *ref_data, float *main_data, float *temp_data,
- int stride, double *score, void *ctx);
+ int stride, void *ctx);
if (s->desc->comp[0].depth <= 8) {
read_frame = read_frame_8bit;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_ssim: fix temp size calculation
On 03.08.2017 03:03, Muhammad Faiz wrote: Also use av_mallocz_array. Fix Ticket6519. Signed-off-by: Muhammad Faiz --- libavfilter/vf_ssim.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c index c3c204268f..d8c049177c 100644 --- a/libavfilter/vf_ssim.c +++ b/libavfilter/vf_ssim.c @@ -219,6 +219,8 @@ static float ssim_endn_8bit(const int (*sum0)[4], const int (*sum1)[4], int widt return ssim; } +#define SUM_LEN(w) (((w) >> 2) + 3) + static float ssim_plane_16bit(SSIMDSPContext *dsp, uint8_t *main, int main_stride, uint8_t *ref, int ref_stride, @@ -228,7 +230,7 @@ static float ssim_plane_16bit(SSIMDSPContext *dsp, int z = 0, y; float ssim = 0.0; int64_t (*sum0)[4] = temp; -int64_t (*sum1)[4] = sum0 + (width >> 2) + 3; +int64_t (*sum1)[4] = sum0 + SUM_LEN(width); width >>= 2; height >>= 2; @@ -256,7 +258,7 @@ static float ssim_plane(SSIMDSPContext *dsp, int z = 0, y; float ssim = 0.0; int (*sum0)[4] = temp; -int (*sum1)[4] = sum0 + (width >> 2) + 3; +int (*sum1)[4] = sum0 + SUM_LEN(width); width >>= 2; height >>= 2; @@ -402,7 +404,7 @@ static int config_input_ref(AVFilterLink *inlink) for (i = 0; i < s->nb_components; i++) s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] / sum; -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) * (1 + (desc->comp[0].depth > 8))); +s->temp = av_mallocz_array(2 * SUM_LEN(inlink->w), (desc->comp[0].depth > 8) ? sizeof(int64_t[4]) : sizeof(int[4])); if (!s->temp) return AVERROR(ENOMEM); s->max = (1 << desc->comp[0].depth) - 1; Fixes the crashing command and runs without reports in Valgrind. Thanks, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
