[FFmpeg-devel] [PATCH V2] doc/spp: Update spp command options docs
From: Jun Zhao
Update spp command options docs
Suggested-by: Moritz Barsnick
Signed-off-by: Jun Zhao
---
doc/filters.texi |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 7f1f59b..aa7dad5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17323,9 +17323,9 @@ option may cause flicker since the B-Frames have often
larger QP. Default is
This filter supports the following commands:
@table @option
-@item level
-@item quality
-Same as quality option. And the command accepts the @code{max} same as the
@code{6}.
+@item quality, level
+Set quality level. The value @code{max} can be used to set the maximum level,
+currently @code{6}.
@end table
@section sr
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] doc/spp: Update spp command options docs
On 18-01-2020 01:41 pm, Jun Zhao wrote:
From: Jun Zhao
Update spp command options docs
Suggested-by: Moritz Barsnick
Signed-off-by: Jun Zhao
---
doc/filters.texi |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 7f1f59b..aa7dad5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17323,9 +17323,9 @@ option may cause flicker since the B-Frames have often
larger QP. Default is
This filter supports the following commands:
@table @option
-@item level
-@item quality
-Same as quality option. And the command accepts the @code{max} same as the
@code{6}.
+@item quality, level
+Set quality level. The value @code{max} can be used to set the maximum level,
+currently @code{6}.
@end table
@section sr
LGTM
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 25/25] avformat/matroskaenc: Redo handling of FlagDefault
Up until now, the Matroska muxer would mark a track as default if it had
the disposition AV_DISPOSITION_DEFAULT or if there was no track with
AV_DISPOSITION_DEFAULT set; in the latter case even more than one track
of a kind (audio, video, subtitles) was marked as default which is not
sensible.
This commit changes the logic used to mark tracks as default. There are
now three modes for this:
a) In the "infer" mode the first track of every type (audio, video,
subtitles) with default disposition set will be marked as default; if
there is no such track (for a given type), then the first track of this
type (if existing) will be marked as default. This behaviour is inspired
by mkvmerge. It ensures that the default flags will be set in a sensible
way even if the input comes from containers that lack the concept of
default flags. This mode is the default mode.
b) The "infer_no_subs" mode is similar to the "infer" mode; the
difference is that if no subtitle track with default disposition exists,
no subtitle track will be marked as default at all.
c) The "passthrough" mode: Here the track will be marked as default if
and only the corresponding input stream had disposition default.
This fixes ticket #8173 (the passthrough mode is ideal for this) as
well as ticket #8416 (the "infer_no_subs" mode leads to the desired
output).
Signed-off-by: Andreas Rheinhardt
---
Better naming suggestions than "infer_no_subs" welcome. Furthermore,
I'd appreciate suggestions on how to shorten the AVOption documentation
(without losing relevant information).
doc/muxers.texi | 19 +
libavformat/matroskaenc.c | 56 +--
2 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 521d99140c..48f3896146 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1341,6 +1341,25 @@ the end. A safe size for most use cases should be about
50kB per hour of video.
Note that cues are only written if the output is seekable and this option will
have no effect if it is not.
+@item default_mode
+This option controls how the FlagDefault of the output tracks will be set.
+It influences which tracks players should play by default. The default mode
+is @samp{infer}.
+@table @samp
+@item infer
+In this mode, for each type of track (audio, video or subtitle), if there is
+a track with disposition default of this type, then the first such track
+(i.e. the one with the lowest index) will be marked as default; if no such
+track exists, the first track of this type will be marked as default instead
+(if existing). This ensures that the default flag is set in a sensible way even
+if the input originated from containers that lack the concept of default
tracks.
+@item infer_no_subs
+This mode is the same as infer except that if no subtitle track with
+disposition default exists, no subtitle track will be marked as default.
+@item passthrough
+In this mode the FlagDefault is set if and only if the AV_DISPOSITION_DEFAULT
+flag is set in the disposition of the corresponding stream.
+@end table
@end table
@anchor{md5}
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 2331e21ff8..5065b2adbd 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -61,6 +61,12 @@
* Info, Tracks, Chapters, Attachments, Tags and Cues */
#define MAX_SEEKHEAD_ENTRIES 6
+enum {
+DEFAULT_MODE_INFER,
+DEFAULT_MODE_INFER_NO_SUBS,
+DEFAULT_MODE_PASSTHROUGH,
+};
+
typedef struct ebml_master {
int64_t pos;///< absolute offset in the containing
AVIOContext where the master's elements start
int sizebytes; ///< how many bytes were reserved for
the size
@@ -160,6 +166,7 @@ typedef struct MatroskaMuxContext {
int wrote_chapters;
int allow_raw_vfw;
+int default_mode;
} MatroskaMuxContext;
/** 2 bytes * 7 for EBML IDs, 7 1-byte EBML lengths, 6 1-byte uint,
@@ -1085,7 +1092,7 @@ static int mkv_write_stereo_mode(AVFormatContext *s,
AVIOContext *pb,
}
static int mkv_write_track(AVFormatContext *s, MatroskaMuxContext *mkv,
- int i, AVIOContext *pb, int default_stream_exists)
+ int i, AVIOContext *pb, int is_default)
{
AVStream *st = s->streams[i];
AVCodecParameters *par = st->codecpar;
@@ -1127,8 +1134,8 @@ static int mkv_write_track(AVFormatContext *s,
MatroskaMuxContext *mkv,
// The default value for TRACKFLAGDEFAULT is 1, so add element
// if we need to clear it.
-if (default_stream_exists && !(st->disposition & AV_DISPOSITION_DEFAULT))
-put_ebml_uint(pb, MATROSKA_ID_TRACKFLAGDEFAULT, !!(st->disposition &
AV_DISPOSITION_DEFAULT));
+if (!is_default)
+put_ebml_uint(pb, MATROSKA_ID_TRACKFLAGDEFAULT, 0);
if (st->disposition & AV_DISPOSITION_FORCED)
put_ebml_uint(pb, MATROSKA_ID_TRACKFLAGFORCED, 1);
@@ -1358,7 +1365,7 @@ static int mkv_write_tracks(
Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_normalize: add support for >8 depth
Will apply this set.
On 1/12/20, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_normalize.c | 121 -
> 1 file changed, 105 insertions(+), 16 deletions(-)
>
> diff --git a/libavfilter/vf_normalize.c b/libavfilter/vf_normalize.c
> index 6a8a7631bc..a008c14f3c 100644
> --- a/libavfilter/vf_normalize.c
> +++ b/libavfilter/vf_normalize.c
> @@ -73,6 +73,7 @@
> */
>
> #include "libavutil/imgutils.h"
> +#include "libavutil/intreadwrite.h"
> #include "libavutil/opt.h"
> #include "libavutil/pixdesc.h"
> #include "avfilter.h"
> @@ -82,12 +83,12 @@
> #include "video.h"
>
> typedef struct NormalizeHistory {
> -uint8_t *history; // History entries.
> -uint32_t history_sum; // Sum of history entries.
> +uint16_t *history; // History entries.
> +uint64_t history_sum; // Sum of history entries.
> } NormalizeHistory;
>
> typedef struct NormalizeLocal {
> -uint8_t in; // Original input byte value for this frame.
> +uint16_t in;// Original input byte value for this frame.
> float smoothed; // Smoothed input value [0,255].
> float out; // Output value [0,255]
> } NormalizeLocal;
> @@ -103,6 +104,9 @@ typedef struct NormalizeContext {
> float strength;
>
> uint8_t co[4]; // Offsets to R,G,B,A bytes respectively in each
> pixel
> +int depth;
> +int sblackpt[4];
> +int swhitept[4];
> int num_components; // Number of components in the pixel format
> int step;
> int history_len;// Number of frames to average; based on smoothing
> factor
> @@ -110,9 +114,9 @@ typedef struct NormalizeContext {
>
> // Per-extremum, per-channel history, for temporal smoothing.
> NormalizeHistory min[3], max[3]; // Min and max for each
> channel in {R,G,B}.
> -uint8_t *history_mem; // Single allocation for above history
> entries
> +uint16_t *history_mem; // Single allocation for above history
> entries
>
> -uint8_t lut[3][256];// Lookup table
> +uint16_t lut[3][65536];// Lookup table
>
> void (*find_min_max)(struct NormalizeContext *s, AVFrame *in,
> NormalizeLocal min[3], NormalizeLocal max[3]);
> void (*process)(struct NormalizeContext *s, AVFrame *in, AVFrame
> *out);
> @@ -207,6 +211,80 @@ static void process_planar(NormalizeContext *s, AVFrame
> *in, AVFrame *out)
> }
> }
>
> +static void find_min_max_16(NormalizeContext *s, AVFrame *in,
> NormalizeLocal min[3], NormalizeLocal max[3])
> +{
> +for (int c = 0; c < 3; c++)
> +min[c].in = max[c].in = AV_RN16(in->data[0] + 2 * s->co[c]);
> +for (int y = 0; y < in->height; y++) {
> +uint16_t *inp = (uint16_t *)(in->data[0] + y * in->linesize[0]);
> +for (int x = 0; x < in->width; x++) {
> +for (int c = 0; c < 3; c++) {
> +min[c].in = FFMIN(min[c].in, inp[s->co[c]]);
> +max[c].in = FFMAX(max[c].in, inp[s->co[c]]);
> +}
> +inp += s->step;
> +}
> +}
> +}
> +
> +static void process_16(NormalizeContext *s, AVFrame *in, AVFrame *out)
> +{
> +for (int y = 0; y < in->height; y++) {
> +uint16_t *inp = (uint16_t *)(in->data[0] + y * in->linesize[0]);
> +uint16_t *outp = (uint16_t *)(out->data[0] + y *
> out->linesize[0]);
> +for (int x = 0; x < in->width; x++) {
> +for (int c = 0; c < 3; c++)
> +outp[s->co[c]] = s->lut[c][inp[s->co[c]]];
> +if (s->num_components == 4)
> +// Copy alpha as-is.
> +outp[s->co[3]] = inp[s->co[3]];
> +inp += s->step;
> +outp += s->step;
> +}
> +}
> +}
> +
> +static void find_min_max_planar_16(NormalizeContext *s, AVFrame *in,
> NormalizeLocal min[3], NormalizeLocal max[3])
> +{
> +min[0].in = max[0].in = AV_RN16(in->data[2]);
> +min[1].in = max[1].in = AV_RN16(in->data[0]);
> +min[2].in = max[2].in = AV_RN16(in->data[1]);
> +for (int y = 0; y < in->height; y++) {
> +uint16_t *inrp = (uint16_t *)(in->data[2] + y * in->linesize[2]);
> +uint16_t *ingp = (uint16_t *)(in->data[0] + y * in->linesize[0]);
> +uint16_t *inbp = (uint16_t *)(in->data[1] + y * in->linesize[1]);
> +for (int x = 0; x < in->width; x++) {
> +min[0].in = FFMIN(min[0].in, inrp[x]);
> +max[0].in = FFMAX(max[0].in, inrp[x]);
> +min[1].in = FFMIN(min[1].in, ingp[x]);
> +max[1].in = FFMAX(max[1].in, ingp[x]);
> +min[2].in = FFMIN(min[2].in, inbp[x]);
> +max[2].in = FFMAX(max[2].in, inbp[x]);
> +}
> +}
> +}
> +
> +static void process_planar_16(NormalizeContext *s, AVFrame *in, AVFrame
> *out)
> +{
> +for (int y = 0; y < in->height; y++) {
> +uint16_t *inrp = (uint16_t *)(in->data[2] + y * in->linesize[2]);
> +uint16_t *ingp = (uint16_t *)(in->data[0] + y * in->linesize[0]);
> +
Re: [FFmpeg-devel] [PATCH] avfilter/asrc_anoisesrc: add velvet noise
will apply. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use bit-exact check for dnn_processing
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Carl Eugen Hoyos > Sent: Saturday, January 18, 2020 7:06 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use > bit-exact > check for dnn_processing > > Am Fr., 17. Jan. 2020 um 15:37 Uhr schrieb Guo, Yejun : > > > > the reason is that the tested models are in float format > > The two reference files are ~1MB together: Do we want / need that? > (No opinion here.) how about just keeping one test (for format rgb24) for vf_dnn_processing? The rgb format might be the most popular format for vf_dnn_processing. And the test has two materials: 1) fate-suite/dnn_processing/dnn_rgb_processing.model (can be renamed from halve_first_channel_float.model, 184 byte now) 2) fate-suite/filter-reference/dnn_rgb_processing.raw (can be renamed from dnn_processing-halve_first_channel_float.raw, 446KB now) When we support more models (the most effort is to add more dnn layers in native mode), I can update both dnn_rgb_processing.model (the file size will be increased bit by bit) and dnn_rgb_processing.raw (the file size will not change much). > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use bit-exact check for dnn_processing
> 在 2020年1月18日，21:33，Guo, Yejun 写道： > > > >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of >> Carl Eugen Hoyos >> Sent: Saturday, January 18, 2020 7:06 AM >> To: FFmpeg development discussions and patches >> Subject: Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use >> bit-exact >> check for dnn_processing >> >> Am Fr., 17. Jan. 2020 um 15:37 Uhr schrieb Guo, Yejun : >>> >>> the reason is that the tested models are in float format >> >> The two reference files are ~1MB together: Do we want / need that? >> (No opinion here.) > > how about just keeping one test (for format rgb24) for vf_dnn_processing? The > rgb format might be the most popular format for vf_dnn_processing. > > And the test has two materials: > 1) fate-suite/dnn_processing/dnn_rgb_processing.model (can be renamed from > halve_first_channel_float.model, 184 byte now) > 2) fate-suite/filter-reference/dnn_rgb_processing.raw (can be renamed from > dnn_processing-halve_first_channel_float.raw, 446KB now) > > When we support more models (the most effort is to add more dnn layers in > native mode), > I can update both dnn_rgb_processing.model (the file size will be increased > bit by bit) and dnn_rgb_processing.raw (the file size will not change much). What about compress them to bz2? Uncompress them when need them? > >> >> Carl Eugen >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/6] avformat: remove unneded avio_flush() calls before calling avio_close_dyn_buf()
> 在 2020年1月5日，21:14，Marton Balint 写道：
>
> avio_close_dyn_buf() also does avio_flush().
>
> Signed-off-by: Marton Balint
> ---
> libavformat/hlsenc.c | 2 --
> libavformat/oggenc.c | 1 -
> libavformat/rtpdec.c | 2 --
> 3 files changed, 5 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 561e3ff736..d130f03ea6 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -459,7 +459,6 @@ static int flush_dynbuf(VariantStream *vs, int
> *range_length)
>
> // flush
> av_write_frame(ctx, NULL);
> -avio_flush(ctx->pb);
>
> // write out to file
> *range_length = avio_close_dyn_buf(ctx->pb, &vs->temp_buffer);
> @@ -2548,7 +2547,6 @@ static int hls_write_trailer(struct AVFormatContext *s)
> if (!vs->init_range_length) {
> uint8_t *buffer = NULL;
> av_write_frame(oc, NULL); /* Flush any buffered data */
> -avio_flush(oc->pb);
>
> range_length = avio_close_dyn_buf(oc->pb, &buffer);
> avio_write(vs->out, buffer, range_length);
> diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
> index d3ae07351d..04f7813083 100644
> --- a/libavformat/oggenc.c
> +++ b/libavformat/oggenc.c
> @@ -133,7 +133,6 @@ static int ogg_write_page(AVFormatContext *s, OGGPage
> *page, int extra_flags)
> avio_write(pb, page->data, page->size);
>
> ogg_update_checksum(s, pb, crc_offset);
> -avio_flush(pb);
>
> size = avio_close_dyn_buf(pb, &buf);
> if (size < 0)
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> index e75a34cb93..3d5b200099 100644
> --- a/libavformat/rtpdec.c
> +++ b/libavformat/rtpdec.c
> @@ -415,7 +415,6 @@ void ff_rtp_send_punch_packets(URLContext *rtp_handle)
> avio_wb32(pb, 0); /* Timestamp */
> avio_wb32(pb, 0); /* SSRC */
>
> -avio_flush(pb);
> len = avio_close_dyn_buf(pb, &buf);
> if ((len > 0) && buf)
> ffurl_write(rtp_handle, buf, len);
> @@ -430,7 +429,6 @@ void ff_rtp_send_punch_packets(URLContext *rtp_handle)
> avio_wb16(pb, 1); /* length in words - 1 */
> avio_wb32(pb, 0); /* our own SSRC */
>
> -avio_flush(pb);
> len = avio_close_dyn_buf(pb, &buf);
> if ((len > 0) && buf)
> ffurl_write(rtp_handle, buf, len);
> --
> 2.16.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
LGTM
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/libx264: return error if unknown picture type encountered
On Sat, Jan 18, 2020 at 06:38:25AM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/libx264.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c > index ca8f6c0..4fef0be 100644 > --- a/libavcodec/libx264.c > +++ b/libavcodec/libx264.c > @@ -471,7 +471,8 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, > const AVFrame *frame, > pict_type = AV_PICTURE_TYPE_B; > break; > default: > -pict_type = AV_PICTURE_TYPE_NONE; > +av_log(ctx, AV_LOG_ERROR, "Unknown picture type encountered.\n"); > +return AVERROR_EXTERNAL; > } This builds now but it does not work ./ffmpeg -i mm-short.mpg -t 1 test.mp4 [libx264 @ 0x2d2c1c0] Unknown picture type encountered. Video encoding failed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/af_afir: add AArch64 SIMD for fcmul_add
./ffmpeg -threads 1 -f lavfi -i anoisesrc -f lavfi -t 30 -i anoisesrc -t 600
-lavfi afir -benchmark -f null -
Test results on Snapdragon 845:
Without SIMD:
size=N/A time=00:10:00.00 bitrate=N/A speed=32.2x
bench: utime=21.900s stime=1.000s rtime=18.607s
bench: maxrss=46708kB
With SIMD:
size=N/A time=00:10:00.00 bitrate=N/A speed=46.6x
bench: utime=16.150s stime=1.040s rtime=12.867s
bench: maxrss=46608kB
Test results on HiSilicon Kirin 970:
Without SIMD:
size=N/A time=00:10:00.00 bitrate=N/A speed=20.7x
bench: utime=32.292s stime=1.032s rtime=28.963s
bench: maxrss=42412kB
With SIMD:
size=N/A time=00:10:00.00 bitrate=N/A speed=27.6x
bench: utime=24.964s stime=0.952s rtime=21.703s
bench: maxrss=42368kB
---
libavfilter/aarch64/Makefile | 2 ++
libavfilter/aarch64/af_afir_init.c | 31 +
libavfilter/aarch64/af_afir_neon.S | 43 ++
libavfilter/af_afir.c | 2 ++
libavfilter/af_afir.h | 1 +
5 files changed, 79 insertions(+)
create mode 100644 libavfilter/aarch64/af_afir_init.c
create mode 100644 libavfilter/aarch64/af_afir_neon.S
diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
index b58daa3a3f..f52d7a4842 100644
--- a/libavfilter/aarch64/Makefile
+++ b/libavfilter/aarch64/Makefile
@@ -1,3 +1,5 @@
+OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/af_afir_init.o
OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
+NEON-OBJS-$(CONFIG_NLMEANS_FILTER) += aarch64/af_afir_neon.o
NEON-OBJS-$(CONFIG_NLMEANS_FILTER) += aarch64/vf_nlmeans_neon.o
diff --git a/libavfilter/aarch64/af_afir_init.c
b/libavfilter/aarch64/af_afir_init.c
new file mode 100644
index 00..db06536380
--- /dev/null
+++ b/libavfilter/aarch64/af_afir_init.c
@@ -0,0 +1,31 @@
+/*
+ * 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 "libavutil/aarch64/cpu.h"
+#include "libavfilter/af_afir.h"
+
+void ff_fcmul_add_neon(float *sum, const float *t, const float *c,
+ ptrdiff_t len);
+
+av_cold void ff_afir_init_aarch64(AudioFIRDSPContext *s)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags))
+s->fcmul_add = ff_fcmul_add_neon;
+}
diff --git a/libavfilter/aarch64/af_afir_neon.S
b/libavfilter/aarch64/af_afir_neon.S
new file mode 100644
index 00..60583f9591
--- /dev/null
+++ b/libavfilter/aarch64/af_afir_neon.S
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2020 Zhao Zhili
+ *
+ * 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 "libavutil/aarch64/asm.S"
+
+// void ff_fcmul_add_neon(float *sum, const float *t, const float *c,
ptrdiff_t len);
+function ff_fcmul_add_neon, export=1
+1:
+ ld2 {v0.4S, v1.4S}, [x1], #32 // load t
+ ld2 {v2.4S, v3.4S}, [x2], #32 // load c
+ ld2 {v4.4S, v5.4S}, [x0]// load sum
+ fmlav4.4S, v0.4S, v2.4S
+ fmlsv4.4S, v1.4S, v3.4S
+ fmlav5.4S, v0.4S, v3.4S
+ fmlav5.4S, v1.4S, v2.4S
+ st2 {v4.4S, v5.4S}, [x0], #32 // store sum
+ subsx3, x3, #4
+ b.ne1b
+ ldr s0, [x1]// load t
+ ldr s1, [x2]// load c
+ ldr s2, [x0]// load sum
+ fmuls0, s0, s1
+ fadds2, s2, s0
+ str s2, [x0]// store sum
+ ret
+endfunc
diff --git a/libavfilter/af_afir.c b/liba
Re: [FFmpeg-devel] [PATCH] avcodec/libx265: zero the padding bytes in extradata
On Fri, Jan 17, 2020 at 09:29:32PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/libx265.c | 1 + > 1 file changed, 1 insertion(+) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libx265: zero the padding bytes in extradata
On 1/18/2020 11:45 AM, Michael Niedermayer wrote: > On Fri, Jan 17, 2020 at 09:29:32PM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavcodec/libx265.c | 1 + >> 1 file changed, 1 insertion(+) > > LGTM > > thx Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/3] avfilter/vf_convolution: Add X86 SIMD optimizations for filter_column()
What is status of this? On 12/22/19, xuju...@sjtu.edu.cn wrote: > From: Xu Jun > > Performance improves about 10% compared to v1. > > Tested using this command: > ./ffmpeg_g -s 1280*720 -pix_fmt yuv420p -i test.yuv -vf convolution="1 2 3 4 > 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 > 9:1/45:1/45:1/45:1/45:1:2:3:4:column:column:column:column" -an -vframes 5000 > -f null /dev/null -benchmark > > after patch: > frame= 4317 fps=600 q=-0.0 Lsize=N/A time=00:02:52.68 bitrate=N/A speed= > 24x > video:2260kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB > muxing overhead: unknown > bench: utime=21.540s stime=2.091s rtime=7.197s > > before patch: > frame= 4317 fps=263 q=-0.0 Lsize=N/A time=00:02:52.68 bitrate=N/A > speed=10.5x > video:2260kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB > muxing overhead: unknown > bench: utime=74.377s stime=1.880s rtime=16.420s > > Signed-off-by: Xu Jun > --- > libavfilter/x86/vf_convolution.asm| 202 ++ > libavfilter/x86/vf_convolution_init.c | 9 ++ > 2 files changed, 211 insertions(+) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/cbs_av1: Check leb128 values read
On Fri, Dec 13, 2019 at 01:28:07AM +0100, Michael Niedermayer wrote: > "It is a requirement of bitstream conformance that the value returned from > the leb128 parsing process is less than or equal > to (1 << 32) - 1." > > Fixes: assertion failure > Fixes: > 19293/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5749508361420800 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/cbs_av1.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- 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: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/iff: Check input space before loop in decode_delta_d()
On Fri, Dec 13, 2019 at 01:28:06AM +0100, Michael Niedermayer wrote: > Fixes: Timeout (114sec ->108ms) > Fixes: > 19290/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5740598116220928 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/iff.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] avcodec/hevc_mp4toannexb_bsf: Avoid NULL memcpy()
On Fri, Dec 13, 2019 at 01:28:08AM +0100, Michael Niedermayer wrote: > Fixes: invalid memcpy use > Fixes: > 19299/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_MP4TOANNEXB_fuzzer-5169193398042624 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/hevc_mp4toannexb_bsf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/hevc_mp4toannexb_bsf: check that nalu size doesnt overflow
On Fri, Dec 13, 2019 at 03:09:25PM -0500, Andriy Gelman wrote:
> On Fri, 13. Dec 18:51, Michael Niedermayer wrote:
> > On Thu, Dec 12, 2019 at 07:36:50PM -0500, Andriy Gelman wrote:
> > > On Fri, 13. Dec 01:28, Michael Niedermayer wrote:
> > > > Fixes: Out of array access
> > > > Fixes:
> > > > 19299/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_MP4TOANNEXB_fuzzer-5169193398042624
> > > >
> > > > Found-by: continuous fuzzing process
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavcodec/hevc_mp4toannexb_bsf.c | 3 +--
> > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
> > > > b/libavcodec/hevc_mp4toannexb_bsf.c
> > > > index d0f1b94f0e..baa93628ed 100644
> > > > --- a/libavcodec/hevc_mp4toannexb_bsf.c
> > > > +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> > > > @@ -152,8 +152,7 @@ static int hevc_mp4toannexb_filter(AVBSFContext
> > > > *ctx, AVPacket *out)
> > > > extra_size= add_extradata * ctx->par_out->extradata_size;
> > > > got_irap |= is_irap;
> > > >
> > > > -if (SIZE_MAX - nalu_size < 4 ||
> > > > -SIZE_MAX - 4 - nalu_size < extra_size) {
> > > > +if (FFMIN(INT_MAX, SIZE_MAX) < 4ULL + nalu_size + extra_size) {
> > > > ret = AVERROR_INVALIDDATA;
> > > > goto fail;
> > > > }
> > > > --
> > > > 2.24.0
> > >
> > > I already sent a patch for this:
> > > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/253972.html
> >
> > yes but it depends on "distant" code behaving in specific ways. I prefer
> > a single self contained check. Because its more robust to someone changing
> > that distant code.
> > So i would prefer to apply some "dumb" check. Do you agree ?
>
> I agree it's more robust. I'll keep this in mind for future
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Never trust a computer, one day, it may think you are the virus. -- Compn
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/dtsdec: make S16LE discrimination sharper
On Tue, Dec 31, 2019 at 03:10:51PM +0100, Michael Niedermayer wrote: > Both S16LE as well as DTS can have lots of 0 bytes in silent segments > Using these results in error. Thus this patch skips 0 bytes in > comparission. > > Fixes Ticket6561 > > Signed-off-by: Michael Niedermayer > --- > libavformat/dtsdec.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: program_date_time and append_list flags conflict
Dear All, When program_date_time flag is present, in m3u8 playlist file each segment has a corresponding EXT-X-PROGRAM-DATE-TIME value. The initial program-date-time value is the actual current time at init and each new segment increments this value by its duration. When append_list flags is also present, existing playlist parsing by hls_append_segment treats existing segments as new segments regarding the program-date-time calculation. But it should not do that, because this way all the real new segments' EXT-X-PROGRAM-DATE-TIME values will be shifted erroneously by the sum duration of existing segments. Instead it should have decremented the initial program-date-time value by its duration. This would ensure that the first new segment's program-date-time value had the current time as it is expected. This patch corrects this behaviour and prevent existing segments to increment the value of initial_prog_date_time variable but decrements it. please review this patch! thank you in advance, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] avformat/mpeg: Don't use unintialized value
On Tue, Oct 22, 2019 at 3:17 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> vobsub_read_packet() didn't check whether an index in array of AVPackets
> was valid and therefore used uninitialized values.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Actually I only wanted to use Valgrind to check for memleaks...
>
> libavformat/mpeg.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
> index 73ade71d95..474afd06b9 100644
> --- a/libavformat/mpeg.c
> +++ b/libavformat/mpeg.c
> @@ -930,6 +930,10 @@ static int vobsub_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> FFDemuxSubtitlesQueue *tmpq = &vobsub->q[i];
> int64_t ts;
> av_assert0(tmpq->nb_subs);
> +
> +if (tmpq->current_sub_idx >= tmpq->nb_subs)
> +continue;
> +
> ts = tmpq->subs[tmpq->current_sub_idx].pts;
> if (ts < min_ts) {
> min_ts = ts;
> --
> 2.20.1
>
>
Ping.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: program_date_time and append_list flags conflict
sorry for missing patch file, here it is. Bela 2020.01.18. 18:56 keltezéssel, Bodecs Bela írta: Dear All, When program_date_time flag is present, in m3u8 playlist file each segment has a corresponding EXT-X-PROGRAM-DATE-TIME value. The initial program-date-time value is the actual current time at init and each new segment increments this value by its duration. When append_list flags is also present, existing playlist parsing by hls_append_segment treats existing segments as new segments regarding the program-date-time calculation. But it should not do that, because this way all the real new segments' EXT-X-PROGRAM-DATE-TIME values will be shifted erroneously by the sum duration of existing segments. Instead it should have decremented the initial program-date-time value by its duration. This would ensure that the first new segment's program-date-time value had the current time as it is expected. This patch corrects this behaviour and prevent existing segments to increment the value of initial_prog_date_time variable but decrements it. please review this patch! thank you in advance, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". From 7e10fcb0a150259bdb0bf01f3ded7e92ed1447b8 Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Sat, 18 Jan 2020 17:41:55 +0100 Subject: [PATCH] avformat/hlsenc: program_date_time and append_list flags conflict When program_date_time flag is present, in m3u8 playlist file each segment has a corresponding EXT-X-PROGRAM-DATE-TIME value. The intial program-date-time value is the actual current time at init and each new segment increments this value by its duration. When append_list flags is also present, existing playlist parsing by hls_append_segment treats existing segments as new segments regarding the program-date-time calculation. But it should not do that, because this way all real the new segments' EXT-X-PROGRAM-DATE-TIME values will be shifted erroneously by the sum duration of existing segments. Instead it should have decremented the initial program-date-time value by its duration. This would ensure that the first new segment's program-date-time value had the current time as it is expected. This patch corrects this behaviour and prevent existing segments to increment the value of initial_prog_date_time variable but decrements it. Signed-off-by: Bela Bodecs --- libavformat/hlsenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index 9884f74d51a..7eeb0df48ae 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -1130,6 +1130,7 @@ static int parse_playlist(AVFormatContext *s, const char *url, VariantStream *vs is_segment = 0; new_start_pos = avio_tell(vs->avf->pb); vs->size = new_start_pos - vs->start_pos; +vs->initial_prog_date_time -= vs->duration; // this is a previously existing segment ret = hls_append_segment(s, hls, vs, vs->duration, vs->start_pos, vs->size); if (ret < 0) goto fail; -- 2.20.1.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Vulkan hwcontext and filters
On 10/01/2020 21:05, Lynne wrote:
> From 2fefb0b7ff760f2fb019751da8c37cfd0578ef00 Mon Sep 17 00:00:00 2001
> From: Philip Langdale
> Date: Wed, 23 Oct 2019 18:01:52 -0700
> Subject: [PATCH 1/9] lavu/hwcontext: Add support for HW -> HW transfers
>
> We are beginning to consider scenarios where a given HW Context
> may be able to transfer frames to another HW Context without
> passing via system memory - this would usually be when two
> contexts represent different APIs on the same device (eg: Vulkan
> and CUDA).
>
> This is modelled as a transfer, as we have today, but where both
> the src and the dst are hardware frames with hw contexts. We need
> to be careful to ensure the contexts are compatible - particularly,
> we cannot do transfers where one of the frames has been mapped via
> a derived frames context - we can only do transfers for frames that
> were directly allocated by the specified context.
Why? A derived frames context should be mostly treatable as a normal frames
context in the mapped-to device, so I'm not seeing where this restriction is
coming from.
(Is there some particular case which doesn't work that this helps to avoid?)
>
> Additionally, as we have two hardware contexts, the transfer function
> could be implemented by either (or indeed both). To handle this
> uncertainty, we explicitly look for ENOSYS as an indicator to try
> the transfer in the other direction before giving up.
> ---
> libavutil/hwcontext.c | 53 +++
> 1 file changed, 43 insertions(+), 10 deletions(-)
>
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index f1e404ab20..3189391c07 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -444,21 +444,54 @@ int av_hwframe_transfer_data(AVFrame *dst, const
> AVFrame *src, int flags)
> if (!dst->buf[0])
> return transfer_data_alloc(dst, src, flags);
>
> -if (src->hw_frames_ctx) {
> -ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
> +/*
> + * Hardware -> Hardware Transfer.
> + * Unlike Software -> Hardware or Hardware -> Software, the transfer
> + * function could be provided by either the src or dst, depending on
> + * the specific combination of hardware.
> + */
> +if (src->hw_frames_ctx && dst->hw_frames_ctx) {
> +AVHWFramesContext *src_ctx =
> +(AVHWFramesContext*)src->hw_frames_ctx->data;
> +AVHWFramesContext *dst_ctx =
> +(AVHWFramesContext*)dst->hw_frames_ctx->data;
> +
> +if (src_ctx->internal->source_frames) {
> +av_log(src_ctx, AV_LOG_ERROR,
> + "A device with a derived frame context cannot be used as "
> + "the source of a HW -> HW transfer.");
> +return AVERROR(ENOSYS);
> +}
>
> -ret = ctx->internal->hw_type->transfer_data_from(ctx, dst, src);
> -if (ret < 0)
> -return ret;
> -} else if (dst->hw_frames_ctx) {
> -ctx = (AVHWFramesContext*)dst->hw_frames_ctx->data;
> +if (dst_ctx->internal->source_frames) {
> +av_log(src_ctx, AV_LOG_ERROR,
> + "A device with a derived frame context cannot be used as "
> + "the destination of a HW -> HW transfer.");
> +return AVERROR(ENOSYS);
> +}
>
> -ret = ctx->internal->hw_type->transfer_data_to(ctx, dst, src);
> +ret = src_ctx->internal->hw_type->transfer_data_from(src_ctx, dst,
> src);
> +if (ret == AVERROR(ENOSYS))
> +ret = dst_ctx->internal->hw_type->transfer_data_to(dst_ctx, dst,
> src);
> if (ret < 0)
> return ret;
> -} else
> -return AVERROR(ENOSYS);
> +} else {
> +if (src->hw_frames_ctx) {
> +ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
> +
> +ret = ctx->internal->hw_type->transfer_data_from(ctx, dst, src);
> +if (ret < 0)
> +return ret;
> +} else if (dst->hw_frames_ctx) {
> +ctx = (AVHWFramesContext*)dst->hw_frames_ctx->data;
>
> +ret = ctx->internal->hw_type->transfer_data_to(ctx, dst, src);
> +if (ret < 0)
> +return ret;
> +} else {
> +return AVERROR(ENOSYS);
> +}
> +}
> return 0;
> }
>
> --
> 2.25.0.rc2
>
This looks fine with the intent of the extra condition clarified.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Vulkan hwcontext and filters
On 10/01/2020 21:05, Lynne wrote:
> From e2d18e03e3a5fa8ef82159c68212b720198a9b91 Mon Sep 17 00:00:00 2001
> From: Philip Langdale
> Date: Wed, 23 Oct 2019 18:11:37 -0700
> Subject: [PATCH 3/9] lavfi/vf_hwupload: Add support for HW -> HW transfers
>
> As we find ourselves wanting a way to transfer frames between
> HW devices (or more realistically, between APIs on the same device),
> it's desirable to have a way to describe the relationship. While
> we could imagine introducing a `hwtransfer` filter, there is
> almost no difference from `hwupload`. The main new feature we need
> is a way to specify the target device. Having a single device
> for the filter chain is obviously insufficient if we're dealing
> with two devices.
>
> So let's add a way to specify the upload target device, and if none
> is specified, continue with the existing behaviour.
>
> We must also correctly preserve the sw_format on such a transfer.
> ---
> doc/filters.texi | 13 -
> libavfilter/vf_hwupload.c | 51 +-
> libavfilter/vf_hwupload_cuda.c | 10 ++-
> 3 files changed, 59 insertions(+), 15 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 6fb660b05a..d0a564c8e7 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -11938,7 +11938,18 @@ Upload system memory frames to hardware surfaces.
>
> The device to upload to must be supplied when the filter is initialised. If
> using ffmpeg, select the appropriate device with the
> @option{-filter_hw_device}
> -option.
> +option or with the @option{derive_device} option. The input and output
> devices
> +must be of different types and compatible - the exact meaning of this is
> +system-dependent, but typically it means that they must refer to the same
> +underlying hardware context (for example, refer to the same graphics card).
> +
> +The following additional parameters are accepted:
> +
> +@table @option
> +@item derive_device @var{type}
> +Rather than using the device supplied at initialisation, instead derive a new
> +device of type @var{type} from the device the input frames exist on.
> +@end table
Maybe make it a bit clearer that this can only apply to device-to-device
transfers?
>
> @anchor{hwupload_cuda}
> @section hwupload_cuda
> diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
> index 50bc7e10f6..7c5dd497b0 100644
> --- a/libavfilter/vf_hwupload.c
> +++ b/libavfilter/vf_hwupload.c
> @@ -32,10 +32,11 @@ typedef struct HWUploadContext {
> const AVClass *class;
>
> AVBufferRef *hwdevice_ref;
> -AVHWDeviceContext *hwdevice;
>
> AVBufferRef *hwframes_ref;
> AVHWFramesContext *hwframes;
> +
> +char *device_type;
> } HWUploadContext;
>
> static int hwupload_query_formats(AVFilterContext *avctx)
> @@ -46,17 +47,27 @@ static int hwupload_query_formats(AVFilterContext *avctx)
> AVFilterFormats *input_formats = NULL;
> int err, i;
>
> -if (!avctx->hw_device_ctx) {
> +if (ctx->hwdevice_ref) {
> +/* We already have a specified device. */
> +} else if (avctx->hw_device_ctx) {
> +if (ctx->device_type) {
> +err = av_hwdevice_ctx_create_derived(
> +&ctx->hwdevice_ref,
> +av_hwdevice_find_type_by_name(ctx->device_type),
> +avctx->hw_device_ctx, 0);
> +if (err < 0)
Add an error message here to say that the derivation went wrong so the user
knows what to check.
> +return err;
> +} else {
> +ctx->hwdevice_ref = av_buffer_ref(avctx->hw_device_ctx);
> +if (!ctx->hwdevice_ref)
> +return AVERROR(ENOMEM);
> +}
> +} else {
> av_log(ctx, AV_LOG_ERROR, "A hardware device reference is required "
> "to upload frames to.\n");
> return AVERROR(EINVAL);
> }
>
> -ctx->hwdevice_ref = av_buffer_ref(avctx->hw_device_ctx);
> -if (!ctx->hwdevice_ref)
> -return AVERROR(ENOMEM);
> -ctx->hwdevice = (AVHWDeviceContext*)ctx->hwdevice_ref->data;
> -
> constraints = av_hwdevice_get_hwframe_constraints(ctx->hwdevice_ref,
> NULL);
> if (!constraints) {
> err = AVERROR(EINVAL);
> @@ -127,7 +138,13 @@ static int hwupload_config_output(AVFilterLink *outlink)
> av_get_pix_fmt_name(inlink->format));
>
> ctx->hwframes->format= outlink->format;
> -ctx->hwframes->sw_format = inlink->format;
> +if (inlink->hw_frames_ctx) {
> +AVHWFramesContext *in_hwframe_ctx =
> +(AVHWFramesContext*)inlink->hw_frames_ctx->data;
> +ctx->hwframes->sw_format = in_hwframe_ctx->sw_format;
> +} else {
> +ctx->hwframes->sw_format = inlink->format;
> +}
> ctx->hwframes->width = inlink->w;
> ctx->hwframes->height= inlink->h;
>
> @@ -200,13 +217,21 @@ static av_cold void hwupload_uninit(AVFilterContext
> *avctx)
> av_buf
Re: [FFmpeg-devel] [PATCH] Vulkan hwcontext and filters
On 10/01/2020 21:05, Lynne wrote:
> From d5f1bbc61fab452803443511b1241931169359b7 Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Wed, 28 Aug 2019 21:58:10 +0100
> Subject: [PATCH 2/9] lavu: add Vulkan hwcontext code
>
> This commit adds the necessary code to initialize and use a Vulkan device
> within the hwcontext libavutil framework.
> Currently direct mapping to VAAPI and DRM frames is functional, and
> transfers to CUDA and native frames are supported.
>
> Lets hope the future Vulkan video decode extension fits well within this
> framework.
> ---
Yay!
> configure | 17 +-
> doc/APIchanges |4 +
> libavutil/Makefile |3 +
> libavutil/hwcontext.c |4 +
> libavutil/hwcontext.h |1 +
> libavutil/hwcontext_cuda.c | 121 ++
> libavutil/hwcontext_internal.h |1 +
> libavutil/hwcontext_vulkan.c | 2804
> libavutil/hwcontext_vulkan.h | 152 ++
> libavutil/pixdesc.c|4 +
> libavutil/pixfmt.h |7 +
> 11 files changed, 3112 insertions(+), 6 deletions(-)
> create mode 100644 libavutil/hwcontext_vulkan.c
> create mode 100644 libavutil/hwcontext_vulkan.h
The CUDA parts look like they could be split off into a separate commit? (It's
already huge.)
>
> diff --git a/configure b/configure
> index 46f2038627..3113ebfdd8 100755
> --- a/configure
> +++ b/configure
> @@ -309,6 +309,7 @@ External library support:
>--enable-openssl enable openssl, needed for https support
> if gnutls, libtls or mbedtls is not used [no]
>--enable-pocketsphinxenable PocketSphinx, needed for asr filter [no]
> + --enable-vulkan enable Vulkan code [no]
Alphabetical order.
>--disable-sndio disable sndio support [autodetect]
>--disable-schannel disable SChannel SSP, needed for TLS support on
> Windows if openssl and gnutls are not used
> [autodetect]
> @@ -1549,11 +1550,11 @@ require_cc(){
> }
>
> require_cpp(){
> -name="$1"
> -headers="$2"
> -classes="$3"
> -shift 3
> -check_lib_cpp "$headers" "$classes" "$@" || die "ERROR: $name not found"
> +log require_cpp "$@"
> +name_version="$1"
> +name="${1%% *}"
> +shift
> +check_lib_cpp "$name" "$@" || die "ERROR: $name_version not found"
> }
This change looks unrelated. (require_cpp isn't used in this patch at all.)
>
> require_headers(){
> @@ -1854,6 +1855,7 @@ HWACCEL_LIBRARY_LIST="
> mmal
> omx
> opencl
> +vulkan
> "
>
> DOCUMENT_LIST="
> @@ -3639,7 +3641,7 @@ avformat_deps="avcodec avutil"
> avformat_suggest="libm network zlib"
> avresample_deps="avutil"
> avresample_suggest="libm"
> -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32
> vaapi videotoolbox corefoundation corevideo coremedia bcrypt"
> +avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32
> vaapi vulkan videotoolbox corefoundation corevideo coremedia bcrypt"
> postproc_deps="avutil gpl"
> postproc_suggest="libm"
> swresample_deps="avutil"
> @@ -6626,6 +6628,9 @@ enabled vdpau &&
>
> enabled crystalhd && check_lib crystalhd "stdint.h
> libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd
>
> +enabled vulkan &&
> +require_pkg_config vulkan "vulkan >= 1.1.97" "vulkan/vulkan.h"
> vkCreateInstance
Presumably you have some specific requirement in mind which wants this version
- can you note it somewhere? (Either here or in the commit message.)
> +
> if enabled x86; then
> case $target_os in
> mingw32*|mingw64*|win32|win64|linux|cygwin*)
> ...
> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
> index f5a4b62387..f874af9f8f 100644
> --- a/libavutil/hwcontext.h
> +++ b/libavutil/hwcontext.h
> @@ -36,6 +36,7 @@ enum AVHWDeviceType {
> AV_HWDEVICE_TYPE_DRM,
> AV_HWDEVICE_TYPE_OPENCL,
> AV_HWDEVICE_TYPE_MEDIACODEC,
> +AV_HWDEVICE_TYPE_VULKAN,
> };
>
> typedef struct AVHWDeviceInternal AVHWDeviceInternal;
> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 30611b1912..18abb87bbd 100644
> --- a/libavutil/hwcontext_cuda.c
> +++ b/libavutil/hwcontext_cuda.c
> @@ -21,6 +21,9 @@
> #include "hwcontext.h"
> #include "hwcontext_internal.h"
> #include "hwcontext_cuda_internal.h"
> +#if CONFIG_VULKAN
> +#include "hwcontext_vulkan.h"
> +#endif
> #include "cuda_check.h"
> #include "mem.h"
> #include "pixdesc.h"
> @@ -42,6 +45,9 @@ static const enum AVPixelFormat supported_formats[] = {
> AV_PIX_FMT_YUV444P16,
> AV_PIX_FMT_0RGB32,
> AV_PIX_FMT_0BGR32,
> +#if CONFIG_VULKAN
> +AV_PIX_FMT_VULKAN,
> +#endif
Do all devices we can do CUDA on also support Vulkan? If not, this should
probably filter it out in get_constraints() to avoid exposing something which
can't possibly work.
> };
>
> #define CHECK_CU(x) FF_CUDA_CHECK_DL(device_
[FFmpeg-devel] [PATCH 2/2] avcodec/wmalosslessdec: Fix integer overflow with sliding in padding bits
Fixes: signed integer overflow: -53716100 * 256 cannot be represented in type
'int'
Fixes:
20143/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5716604000403456
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wmalosslessdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index 9b620377a9..f5961c72c0 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -991,7 +991,7 @@ static int decode_subframe(WmallDecodeCtx *s)
if (s->bits_per_sample == 16) {
*s->samples_16[c]++ = (int16_t) s->channel_residues[c][j] * (1
<< padding_zeroes);
} else {
-*s->samples_32[c]++ = s->channel_residues[c][j] * (256 <<
padding_zeroes);
+*s->samples_32[c]++ = s->channel_residues[c][j] * (256U <<
padding_zeroes);
}
}
}
--
2.24.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/wmalosslessdec: Fix loop in revert_acfilter()
Fixes: out of array read
Fixes:
20059/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5691776237305856
No testcase except the fuzzed one.
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wmalosslessdec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index b15f812d81..9b620377a9 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -822,8 +822,11 @@ static void revert_acfilter(WmallDecodeCtx *s, int
tile_size)
pred >>= scaling;
s->channel_residues[ich][i] += (unsigned)pred;
}
-for (j = 0; j < order; j++)
-prevvalues[j] = s->channel_residues[ich][tile_size - j - 1];
+for (j = order - 1; j >= 0; j--)
+if (tile_size <= j) {
+prevvalues[j] = prevvalues[j - tile_size];
+}else
+prevvalues[j] = s->channel_residues[ich][tile_size - j - 1];
}
}
--
2.24.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Segfault calling av_interleaved_write_frame
Hello,
I found I was getting sigsegv when calling av_interleaved_write_frame().
From a18f4cb5b86392c5c161878daea8e4b1204881eb Mon Sep 17 00:00:00 2001
From: jon noble
Date: Sat, 18 Jan 2020 21:33:11 +
Subject: [PATCH] libavformat/mux: prevent segfault in
compute_muxer_pkt_fields()
---
libavformat/mux.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 8ab5ea8c2b..ea79981fe8 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -598,9 +598,11 @@ static int compute_muxer_pkt_fields(AVFormatContext
*s, AVStream *st, AVPacket *
av_log(s, AV_LOG_WARNING, "Encoder did not produce proper pts,
making some up.\n");
warned = 1;
}
-pkt->dts =
-//pkt->pts= st->cur_dts;
-pkt->pts = st->internal->priv_pts->val;
+if (st->internal->priv_pts == NULL) {
+ av_log(s, AV_LOG_WARNING, "Null private stream data.\n");
+ return AVERROR(EINVAL);
+}
+pkt->dts = pkt->pts = st->internal->priv_pts->val;
}
//calculate dts from pts
--
2.25.0
Kind regards
Jon
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Segfault calling av_interleaved_write_frame
On Sat, Jan 18, 2020 at 10:40 PM Jonathan Noble
wrote:
> Hello,
>
> I found I was getting sigsegv when calling av_interleaved_write_frame().
>
> From a18f4cb5b86392c5c161878daea8e4b1204881eb Mon Sep 17 00:00:00 2001
> From: jon noble
> Date: Sat, 18 Jan 2020 21:33:11 +
> Subject: [PATCH] libavformat/mux: prevent segfault in
> compute_muxer_pkt_fields()
>
> ---
> libavformat/mux.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index 8ab5ea8c2b..ea79981fe8 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -598,9 +598,11 @@ static int compute_muxer_pkt_fields(AVFormatContext
> *s, AVStream *st, AVPacket *
> av_log(s, AV_LOG_WARNING, "Encoder did not produce proper pts,
> making some up.\n");
> warned = 1;
> }
> -pkt->dts =
> -//pkt->pts= st->cur_dts;
> -pkt->pts = st->internal->priv_pts->val;
> +if (st->internal->priv_pts == NULL) {
> + av_log(s, AV_LOG_WARNING, "Null private stream data.\n");
> + return AVERROR(EINVAL);
> +}
> +pkt->dts = pkt->pts = st->internal->priv_pts->val;
> }
>
> //calculate dts from pts
> --
> 2.25.0
>
> Can you give us the command line together with the necessary sample files
that allow to reproduce this segfault?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] doc/spp: Update spp command options docs
On Sat, Jan 18, 2020 at 16:11:01 +0800, Jun Zhao wrote:
> Suggested-by: Moritz Barsnick
You don't really need to do this. ;-) Especially as Gyan's suggestion
(which was better) is now in.
> +@item quality, level
> +Set quality level. The value @code{max} can be used to set the maximum level,
> +currently @code{6}.
Also fine by me.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Segfault calling av_interleaved_write_frame
Oh, it wasn't via ffmpeg. I was using the library. What is the correct dev
mailing list?
On Sat, 18 Jan 2020 at 21:45, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> On Sat, Jan 18, 2020 at 10:40 PM Jonathan Noble
> wrote:
>
> > Hello,
> >
> > I found I was getting sigsegv when calling av_interleaved_write_frame().
> >
> > From a18f4cb5b86392c5c161878daea8e4b1204881eb Mon Sep 17 00:00:00 2001
> > From: jon noble
> > Date: Sat, 18 Jan 2020 21:33:11 +
> > Subject: [PATCH] libavformat/mux: prevent segfault in
> > compute_muxer_pkt_fields()
> >
> > ---
> > libavformat/mux.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/mux.c b/libavformat/mux.c
> > index 8ab5ea8c2b..ea79981fe8 100644
> > --- a/libavformat/mux.c
> > +++ b/libavformat/mux.c
> > @@ -598,9 +598,11 @@ static int compute_muxer_pkt_fields(AVFormatContext
> > *s, AVStream *st, AVPacket *
> > av_log(s, AV_LOG_WARNING, "Encoder did not produce proper
> pts,
> > making some up.\n");
> > warned = 1;
> > }
> > -pkt->dts =
> > -//pkt->pts= st->cur_dts;
> > -pkt->pts = st->internal->priv_pts->val;
> > +if (st->internal->priv_pts == NULL) {
> > + av_log(s, AV_LOG_WARNING, "Null private stream data.\n");
> > + return AVERROR(EINVAL);
> > +}
> > +pkt->dts = pkt->pts = st->internal->priv_pts->val;
> > }
> >
> > //calculate dts from pts
> > --
> > 2.25.0
> >
> > Can you give us the command line together with the necessary sample files
> that allow to reproduce this segfault?
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Segfault calling av_interleaved_write_frame
Jonathan Noble (12020-01-18): > Oh, it wasn't via ffmpeg. I was using the library. What is the correct dev > mailing list? Probably. We would need to see the code with the sample, to be sure where the bug lies. > On Sat, 18 Jan 2020 at 21:45, Andreas Rheinhardt < > andreas.rheinha...@gmail.com> wrote: Top-posting is not allowed on this mailing-list. If you do not know what it means, look it up. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Segfault calling av_interleaved_write_frame
On Sat, Jan 18, 2020 at 11:18 PM Jonathan Noble wrote: > Oh, it wasn't via ffmpeg. I was using the library. What is the correct dev > mailing list? > > Your patch was for FFmpeg itself and so this is the right mailing list. But you should nevertheless give us enough information so that we can reproduce the problem. After all, the bug may be in a completely different part than the part where the segfault is triggered. (That being said, doing a separate allocation for priv_pts seems weird in general.) - Andreas PS: Please avoid top-posting on this list. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
On Wed, 15 Jan 2020, Marton Balint wrote: On Thu, 9 Jan 2020, Michael Niedermayer wrote: On Wed, Jan 01, 2020 at 08:10:06PM +0100, Marton Balint wrote: On Tue, 31 Dec 2019, Michael Niedermayer wrote: On Tue, Dec 31, 2019 at 12:37:02PM +0100, Nicolas George wrote: Marton Balint (12019-12-28): v2: simplified example Signed-off-by: Marton Balint --- doc/muxers.texi | 11 +++ libavformat/img2enc.c | 13 - 2 files changed, 23 insertions(+), 1 deletion(-) image2 is not the only demuxer that opens new streams. I think a generic solution would be preferable. i also had a slightly ungood feeling about the patch but didnt had time to think more about it. a more generic solution like with child AVClasses or something would be interresting but as said i didnt had time to think about this ... It looks like a big can of worms. In the AVFMT_NOFILE case there is no IO context, so options can only be passed using avformat_write_header/avformat_init_output. There is no way to determine which options the protocols will use without actually opening an IO context (protocol options are passed to the url_open method of each protocol), so we have to store all remaining options passed to avformat_write_header/avformat_init_output for possible nested IO use. In the normal case (non AVFMT_NOFILE) muxers can use nested contexts too, so avio_open should also store the original options, all of them, because the nested contexts might use different protocols. This alone is problematic, because avio_open should return the unrecognized options... Also it might make sense to specify different IO options for nested contexts than main contexts (or different options for some of the nested contexts) IMHO being able to specify the nested options separately is a clean solution, admittedly less user friendly, but I don't see how this can work automagically without some major redesign. ok, yes i agree it would need a too major redesign. Ok, I will apply in a few days if I receive no further comments. Applied. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/avio: move ff_rename implementation from internal.h to avio.c
On Thu, 9 Jan 2020, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/avio.c | 15 +++
libavformat/internal.h | 14 +-
2 files changed, 16 insertions(+), 13 deletions(-)
Ping, will apply the series soon.
Regards,
Marton
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 2dd2312296..8c2c85f171 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -26,6 +26,7 @@
#include "libavutil/avassert.h"
#include "os_support.h"
#include "avformat.h"
+#include "internal.h"
#if CONFIG_NETWORK
#include "network.h"
#endif
@@ -665,3 +666,17 @@ int ff_check_interrupt(AVIOInterruptCB *cb)
return cb->callback(cb->opaque);
return 0;
}
+
+int ff_rename(const char *oldpath, const char *newpath, void *logctx)
+{
+int ret = 0;
+if (rename(oldpath, newpath) == -1) {
+ret = AVERROR(errno);
+if (logctx) {
+char err[AV_ERROR_MAX_STRING_SIZE] = {0};
+av_make_error_string(err, AV_ERROR_MAX_STRING_SIZE, ret);
+av_log(logctx, AV_LOG_ERROR, "failed to rename file %s to %s:
%s\n", oldpath, newpath, err);
+}
+}
+return ret;
+}
diff --git a/libavformat/internal.h b/libavformat/internal.h
index ec9a29907a..da09983083 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -586,19 +586,7 @@ int ff_stream_encode_params_copy(AVStream *dst, const
AVStream *src);
* @param newpath destination path
* @return0 or AVERROR on failure
*/
-static inline int ff_rename(const char *oldpath, const char *newpath, void
*logctx)
-{
-int ret = 0;
-if (rename(oldpath, newpath) == -1) {
-ret = AVERROR(errno);
-if (logctx) {
-char err[AV_ERROR_MAX_STRING_SIZE] = {0};
-av_make_error_string(err, AV_ERROR_MAX_STRING_SIZE, ret);
-av_log(logctx, AV_LOG_ERROR, "failed to rename file %s to %s:
%s\n", oldpath, newpath, err);
-}
-}
-return ret;
-}
+int ff_rename(const char *oldpath, const char *newpath, void *logctx);
/**
* Allocate extradata with additional AV_INPUT_BUFFER_PADDING_SIZE at end
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavf/libsrt: nonblock enabling correction
On Thu, 16 Jan 2020, Anthony Delannoy wrote:
As written in https://github.com/Haivision/srt/blob/v1.4.1/docs/API.md,
the nonblock mode is activated if SRTO_SNDSYN and SRTO_RCVSYN, for
sending and receiving respectively, are set to 0.
---
libavformat/libsrt.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
Thanks, applied.
Regards,
Marton
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 16975b6d94..6e230c254b 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -152,12 +152,21 @@ static int libsrt_neterrno(URLContext *h)
return AVERROR_UNKNOWN;
}
+/*
+ * SRT functions can also work in blocking and non-blocking mode, for which
+ * there are two separate options for sending and receiving: SRTO_SNDSYN and
+ * SRTO_RCVSYN.
+ * Setting SRTO_{SND,RCV}SYN options to 1 enable blocking mode, setting them
+ * to 0 enable non-blocking mode.
+ */
static int libsrt_socket_nonblock(int socket, int enable)
{
-int ret = srt_setsockopt(socket, 0, SRTO_SNDSYN, &enable, sizeof(enable));
+int ret, blocking = enable ? 0 : 1;
+
+ret = srt_setsockopt(socket, 0, SRTO_SNDSYN, &blocking, sizeof(blocking));
if (ret < 0)
return ret;
-return srt_setsockopt(socket, 0, SRTO_RCVSYN, &enable, sizeof(enable));
+return srt_setsockopt(socket, 0, SRTO_RCVSYN, &blocking, sizeof(blocking));
}
static int libsrt_network_wait_fd(URLContext *h, int eid, int fd, int write)
--
2.24.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/libx264: return error if unknown picture type encountered
On Sat, Jan 18, 2020 at 03:27:12PM +0100, Michael Niedermayer wrote: > On Sat, Jan 18, 2020 at 06:38:25AM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/libx264.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c > > index ca8f6c0..4fef0be 100644 > > --- a/libavcodec/libx264.c > > +++ b/libavcodec/libx264.c > > @@ -471,7 +471,8 @@ static int X264_frame(AVCodecContext *ctx, AVPacket > > *pkt, const AVFrame *frame, > > pict_type = AV_PICTURE_TYPE_B; > > break; > > default: > > -pict_type = AV_PICTURE_TYPE_NONE; > > +av_log(ctx, AV_LOG_ERROR, "Unknown picture type encountered.\n"); > > +return AVERROR_EXTERNAL; > > } > > This builds now but it does not work > > ./ffmpeg -i mm-short.mpg -t 1 test.mp4 > > [libx264 @ 0x2d2c1c0] Unknown picture type encountered. > Video encoding failed Sorry, please ignore the patch, libx264 can return 0. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Republics decline into democracies and democracies degenerate into > despotisms. -- Aristotle > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Thanks, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use bit-exact check for dnn_processing
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Steven Liu > Sent: Saturday, January 18, 2020 9:52 PM > To: FFmpeg development discussions and patches > Cc: Steven Liu > Subject: Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use > bit-exact > check for dnn_processing > > > > > 在 2020年1月18日，21:33，Guo, Yejun 写道： > > > > > > > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of > >> Carl Eugen Hoyos > >> Sent: Saturday, January 18, 2020 7:06 AM > >> To: FFmpeg development discussions and patches > > >> Subject: Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use > bit-exact > >> check for dnn_processing > >> > >> Am Fr., 17. Jan. 2020 um 15:37 Uhr schrieb Guo, Yejun > : > >>> > >>> the reason is that the tested models are in float format > >> > >> The two reference files are ~1MB together: Do we want / need that? > >> (No opinion here.) > > > > how about just keeping one test (for format rgb24) for vf_dnn_processing? > The rgb format might be the most popular format for vf_dnn_processing. > > > > And the test has two materials: > > 1) fate-suite/dnn_processing/dnn_rgb_processing.model (can be renamed > from halve_first_channel_float.model, 184 byte now) > > 2) fate-suite/filter-reference/dnn_rgb_processing.raw (can be renamed > from dnn_processing-halve_first_channel_float.raw, 446KB now) > > > > When we support more models (the most effort is to add more dnn layers in > native mode), > > I can update both dnn_rgb_processing.model (the file size will be increased > bit by bit) and dnn_rgb_processing.raw (the file size will not change much). > What about compress them to bz2? Uncompress them when need them? thanks, and just one concern, since ffmpeg is used on many platforms, is there always an unzip program on every platform's default setup? > > > >> > >> Carl Eugen > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > Thanks > Steven > > > > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 1/2] doc/bsfs: h264_metadata: Update docs about display orientation SEI
On Sat, Jan 18, 2020 at 10:29 AM Andreas Rheinhardt wrote: > > On Sat, Jan 18, 2020 at 3:11 AM Jun Zhao wrote: > > > From: Jun Zhao > > > > Add docs about display orientation SEI. > > > > Signed-off-by: Jun Zhao > > --- > > doc/bitstream_filters.texi | 21 + > > 1 files changed, 21 insertions(+), 0 deletions(-) > > > > diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi > > index 8fe5b3a..ff5d027 100644 > > --- a/doc/bitstream_filters.texi > > +++ b/doc/bitstream_filters.texi > > @@ -276,6 +276,27 @@ insert the string ``hello'' associated with the given > > UUID. > > @item delete_filler > > Deletes both filler NAL units and filler SEI messages. > > > > +@item display_orientation > > +Pass, insert, remove or extract display orientation SEI. Default is pass. > > + > > +@table @samp > > +@item pass > > +@item insert > > +@item remove > > +@item extract > > +@end table > > + > > +@item rotate > > +Set rotation in display orientation SEI (anticlockwise angle in degrees) > > (from -360 to 360) > > + > > +@item flip > > +Set flip in display orientation SEI > > + > > +@table @samp > > +@item horizontal > > +@item vertical > > +@end table > > + > > @item level > > Set the level in the SPS. Refer to H.264 section A.3 and tables A-1 > > to A-5. > > -- > > 1.7.1 > > > If I am not mistaken, then the handling of display orientation SEI is buggy > (see [1]). It should be fixed before documenting it. > > - Andreas > > [1]: > https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2019-June/005804.html Will hold on the patch until the issue fix, thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
> -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Friday, January 17, 2020 05:36 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change > inline assembly into nasm code > > On Thu, Jan 16, 2020 at 07:27:05AM +, Fu, Ting wrote: > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Michael Niedermayer > > > Sent: Wednesday, January 15, 2020 05:55 AM > > > To: FFmpeg development discussions and patches > > > > > > Subject: Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: > > > Change inline assembly into nasm code > > > > > > On Fri, Jan 10, 2020 at 01:38:15AM +0800, Ting Fu wrote: > > > > Signed-off-by: Ting Fu > > > > --- > > > > V7: > > > > Fix compile issue when user configure with --disable-mmx. > > > > Fix issue when running ./ffmpeg with --cpuflags mmx/ssse3. > > > > Adjust the SIMD verify logic in libswscale/x86/yuv2rgb.c > > > > > > > > libswscale/x86/Makefile | 1 + > > > > libswscale/x86/swscale.c | 16 +- > > > > libswscale/x86/yuv2rgb.c | 66 ++--- > > > > libswscale/x86/yuv2rgb_template.c | 467 ++ > > > > libswscale/x86/yuv_2_rgb.asm | 270 + > > > > 5 files changed, 405 insertions(+), 415 deletions(-) create mode > > > > 100644 libswscale/x86/yuv_2_rgb.asm > > > > > > The commit message seems a bit terse I think it should say if the > > > sequence of instructions is unchanged and if it was benchmaked. If > > > its the same speed, when the code is run the commit message should > > > say that too > > > > > > the principle of this (inline -> nasm) is fine of course. > > > > > > > > [...] > > > > -static inline int RENAME(yuv420_rgb16)(SwsContext *c, const uint8_t > *src[], > > > > - int srcStride[], > > > > - int srcSliceY, int srcSliceH, > > > > - uint8_t *dst[], int dstStride[]) > > > > +static int RENAME(yuv420_rgb16)(SwsContext *c, const uint8_t *src[], > > > > + int srcStride[], > > > > + int srcSliceY, int > > > > srcSliceH, > > > > + uint8_t *dst[], > > > > +int > > > > +dstStride[]) > > > > > > maybe the removial of inline should be a seperate patch also there > > > is the question why these wraper functions exist These do change > > > from a a "free thing in inline asm" to a call overhead with C->NASM > > > > > Hi Michael, > > > > The wrapper functions initiate some variables and contain one 'for cycle'. > > The > variable initiation needs to access to the 'c->dstW', furthermore macro > SWS_MAX_ FILTER_SIZE is needed. Which means extra work and much more > NASM code. > > If you still prefer to do all the things in assembly, I can change from > > 'C->NASM' > to 'call NASM function directly' in another further patch( for current patch > easier > to review). > > Or in my opinion, the cost in C->NASM can be ignored, and the initiation > > work > looks clearer in C, just let it be what it is now. > > What do you think? > > it probably makes no sense if its hard to convert that code Hi Michael, You mean I still need to convert that code, did I get you right? Since NASM function will get only the address of SwsConext c ( in order to be compatible with yuv2rgb_c function in parameters), not the address of c->redDither nor the c->dstW. I have no way to get the value of c->dstW by using address offset. Do you have any suggestion for solving that problem? Thank you, Ting Fu > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If you fake or manipulate statistics in a paper in physics you will never get > a job > again. > If you fake or manipulate statistics in a paper in medicin you will get a job > for life > at the pharma industry. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] doc/spp: Update spp command options docs
On Sun, Jan 19, 2020 at 5:50 AM Moritz Barsnick wrote:
>
> On Sat, Jan 18, 2020 at 16:11:01 +0800, Jun Zhao wrote:
> > Suggested-by: Moritz Barsnick
>
> You don't really need to do this. ;-) Especially as Gyan's suggestion
> (which was better) is now in.
>
> > +@item quality, level
> > +Set quality level. The value @code{max} can be used to set the maximum
> > level,
> > +currently @code{6}.
>
> Also fine by me.
>
> Moritz
Pushed, thanks the comments and review
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec: add decoder for argonaut games' adpcm codec
Adds support for the ADPCM variant used by some Argonaut Games' games,
such as 'Croc! Legend of the Gobbos', and 'Croc 2'.
Signed-off-by: Zane van Iperen
---
Changelog | 2 +-
doc/general.texi| 1 +
libavcodec/Makefile | 1 +
libavcodec/adpcm_argo.c | 264
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/version.h| 2 +-
8 files changed, 277 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/adpcm_argo.c
diff --git a/Changelog b/Changelog
index 2ccd2645fc..e26320c0ce 100644
--- a/Changelog
+++ b/Changelog
@@ -30,7 +30,7 @@ version :
- MPEG-H 3D Audio support in mp4
- thistogram filter
- freezeframes filter
-
+- Argonaut Games ADPCM decoder
version 4.2:
- tpad filter
diff --git a/doc/general.texi b/doc/general.texi
index 4bd4b4f6b9..85db50462c 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1079,6 +1079,7 @@ following image formats are supported:
@item ACELP.KELVIN @tab @tab X
@item ADPCM 4X Movie @tab @tab X
@item APDCM Yamaha AICA @tab @tab X
+@item ADPCM Argonaut Games @tab @tab X
@item ADPCM CDROM XA @tab @tab X
@item ADPCM Creative Technology @tab @tab X
@tab 16 -> 4, 8 -> 4, 8 -> 3, 8 -> 2
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c1f35b40d8..526b3ce96b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -817,6 +817,7 @@ OBJS-$(CONFIG_ADPCM_ADX_ENCODER) += adxenc.o adx.o
OBJS-$(CONFIG_ADPCM_AFC_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_AGM_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_AICA_DECODER) += adpcm.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_ARGO_DECODER) += adpcm_argo.o
OBJS-$(CONFIG_ADPCM_CT_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_DTK_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_EA_DECODER) += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcm_argo.c b/libavcodec/adpcm_argo.c
new file mode 100644
index 00..d5b32e62ba
--- /dev/null
+++ b/libavcodec/adpcm_argo.c
@@ -0,0 +1,264 @@
+/*
+ * Argonaut Games ADPCM decoder
+ *
+ * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
+ *
+ * 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 "avcodec.h"
+#include "internal.h"
+#include "libavutil/avassert.h"
+
+/*
+ * Sanity Checks:
+ *
+ * ./ffmpeg -loglevel error -i OUTRO.ASF -map 0:a -f md5 -
+ * MD5=e0428a6c55382f48502f04b3a7f7b94b
+ *
+ * ./ffmpeg -loglevel error -i CBK2.asf -map 0:a -f md5 -
+ * MD5=589f3f3c518e5d58aa404b7576db5b70
+*/
+
+/**
+ * Decode a block of 4-bit ADPCM samples for a channel.
+ *
+ * @param c The shift amount - 2.
+ * @param dst A pointer to the buffer to write the decoded samples,
+ * @p stride elements apart.
+ * @param src A pointer to the first encoded sample.
+ * This should be `nsamples / 2` bytes.
+ * @param prev The two previous samples, with @p stride elements
+ * between each channel.
+ * @param nsamples The number of samples in the channel.
+ * @param strideThe difference in int16_t's between output samples.
+ * This is 0 for mono, 1 for stereo.
+ *
+ * @remark Each iteration does 2 samples at a time to avoid nasty
bit-twiddling.
+ */
+typedef int16_t *(*ADPCMDecoder) (
+uint8_t c,
+int16_t *dst,
+const uint8_t *src,
+const int16_t *prev,
+int nsamples,
+int stride
+);
+
+/*
+ * Decoder 1: (prev0 + (s << (c + 2)))
+ */
+static int16_t *adpcm_decoder_1(uint8_t c, int16_t *dst, const uint8_t *src,
+ const int16_t *prev_,
+ int nsamples, int stride)
+{
+int16_t prev;
+int8_t s;
+
+av_assert0(stride == 0 || stride == 1);
+++stride;
+
+prev = prev_[stride];
+
+c += 2;
+for (int i = 0; i < nsamples / 2; ++i, ++src) {
+s = (int8_t) ((*src & 0xF0u) << 0u);
+*dst = prev = ((prev << 6) + (s << c)) >> 6;
+dst += stride;
+
+s = (int8_t) ((*src & 0x0Fu) << 4u);
+*dst = prev = ((prev << 6) + (s << c)) >> 6;
+dst += stride;
+
[FFmpeg-devel] [PATCH 2/2] avformat: add demuxer for argonaut games' ASF format
Adds support for the custom ASF container used by some Argonaut Games'
games, such as 'Croc! Legend of the Gobbos', and 'Croc 2'.
Can also handle the sample files in:
https://samples.ffmpeg.org/game-formats/brender/part2.zip
Signed-off-by: Zane van Iperen
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/argo_asf.c | 254 +++
libavformat/version.h| 4 +-
5 files changed, 259 insertions(+), 2 deletions(-)
create mode 100644 libavformat/argo_asf.c
diff --git a/Changelog b/Changelog
index e26320c0ce..bc1593bfd1 100644
--- a/Changelog
+++ b/Changelog
@@ -31,6 +31,7 @@ version :
- thistogram filter
- freezeframes filter
- Argonaut Games ADPCM decoder
+- Argonaut Games ASF demuxer
version 4.2:
- tpad filter
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 52f29b1a6d..ba6ea8c4a6 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -99,6 +99,7 @@ OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
OBJS-$(CONFIG_APTX_HD_DEMUXER) += aptxdec.o rawdec.o
OBJS-$(CONFIG_APTX_HD_MUXER) += rawenc.o
OBJS-$(CONFIG_AQTITLE_DEMUXER) += aqtitledec.o subtitles.o
+OBJS-$(CONFIG_ARGO_ASF_DEMUXER) += argo_asf.o
OBJS-$(CONFIG_ASF_DEMUXER) += asfdec_f.o asf.o asfcrypt.o \
avlanguage.o
OBJS-$(CONFIG_ASF_O_DEMUXER) += asfdec_o.o asf.o asfcrypt.o \
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ff9bdb906f..fe74a32e47 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -60,6 +60,7 @@ extern AVOutputFormat ff_aptx_muxer;
extern AVInputFormat ff_aptx_hd_demuxer;
extern AVOutputFormat ff_aptx_hd_muxer;
extern AVInputFormat ff_aqtitle_demuxer;
+extern AVInputFormat ff_argo_asf_demuxer;
extern AVInputFormat ff_asf_demuxer;
extern AVOutputFormat ff_asf_muxer;
extern AVInputFormat ff_asf_o_demuxer;
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
new file mode 100644
index 00..ab8a0955ab
--- /dev/null
+++ b/libavformat/argo_asf.c
@@ -0,0 +1,254 @@
+/*
+ * Argonaut Games ASF demuxer
+ *
+ * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
+ *
+ * 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 "avformat.h"
+#include "internal.h"
+#include "libavutil/internal.h"
+#include "libavutil/bswap.h"
+#include "libavutil/avassert.h"
+
+#pragma pack(push, 1)
+typedef struct ArgoASFFileHeader {
+uint8_t magic[4]; /*< Magic Number, {'A', 'S', 'F', '\0'} */
+uint16_tversion_major; /*< File Major Version. */
+uint16_tversion_minor; /*< File Minor Version. */
+uint32_tnum_chunks; /*< No. chunks in the file. */
+uint32_tchunk_offset; /*< Offset to the first chunk from the start
of the file. */
+int8_t name[8];/*< Name. */
+} ArgoASFFileHeader;
+
+typedef struct ArgoASFChunkHeader {
+uint32_tnum_blocks; /*< No. blocks in the chunk. */
+uint32_tnum_samples;/*< No. samples per channel in a block. */
+uint32_tunk1; /*< Unknown */
+uint16_tsample_rate;/*< Sample rate. */
+uint16_tunk2; /*< Unknown. */
+uint32_tflags; /*< Stream flags. */
+} ArgoASFChunkHeader;
+#pragma pack(pop)
+
+enum {
+ASF_CF_BITS_PER_SAMPLE = (1 << 0), /*< 16-bit if set, 8 otherwise. */
+ASF_CF_STEREO = (1 << 1), /*< Stereo if set, mono otherwise. */
+ASF_CF_ALWAYS1_1= (1 << 2), /*< Unknown, always seems to be set. */
+ASF_CF_ALWAYS1_2= (1 << 3), /*< Unknown, always seems to be set. */
+
+ASF_CF_ALWAYS1 = ASF_CF_ALWAYS1_1 | ASF_CF_ALWAYS1_2,
+ASF_CF_ALWAYS0 = ~(ASF_CF_BITS_PER_SAMPLE | ASF_CF_STEREO |
ASF_CF_ALWAYS1)
+};
+
+typedef struct ArgoASFDemuxContext
+{
+ArgoASFFileHeader fhdr;
+ArgoASFChunkHeader ckhdr;
+uint32_tblocks_read;
+} ArgoASFDemuxContext;
+
+static void argo_asf_fix_header_endianness(ArgoASFFileHeader *hdr)
+{
+hdr->version_major = av_le2ne16(hdr->version_major);
+hdr->version_minor = av_le2ne16(hdr->version_minor);
+hdr->num_chunks
[FFmpeg-devel] [PATCH 0/2] Argonaut Games ASF and ADPCM decoding support
Hi all, This patchset adds support for the ASF container and ADPCM variant used by some Argonaut Software games such as 'Croc! Legend of the Gobbos' and 'Croc 2'. It has been tested against: - ANISOUND/*.ASFfrom Croc 1 - music/*.asf from Croc 2 - FIGHT/SOUND/*.ASF from https://samples.ffmpeg.org/game-formats/brender/part2.zip Zane Zane van Iperen (2): avcodec: add decoder for argonaut games' adpcm codec avformat: add demuxer for argonaut games' ASF format Changelog| 3 +- doc/general.texi | 1 + libavcodec/Makefile | 1 + libavcodec/adpcm_argo.c | 264 +++ libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h | 1 + libavcodec/codec_desc.c | 7 ++ libavcodec/version.h | 2 +- libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/argo_asf.c | 254 + libavformat/version.h| 4 +- 12 files changed, 536 insertions(+), 4 deletions(-) create mode 100644 libavcodec/adpcm_argo.c create mode 100644 libavformat/argo_asf.c -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V8 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
The original inline assembly and nasm code have the same fps when called by
command.
NASM code almost has no impact on the perfromance.
Signed-off-by: Ting Fu
---
V8:
Remove all reindention to make review easier.
Fix some improper indention.
Reserve the "inline" for next patch.
libswscale/x86/Makefile | 1 +
libswscale/x86/swscale.c | 16 +-
libswscale/x86/yuv2rgb.c | 26 +-
libswscale/x86/yuv2rgb_template.c | 392 +-
libswscale/x86/yuv_2_rgb.asm | 270
5 files changed, 351 insertions(+), 354 deletions(-)
create mode 100644 libswscale/x86/yuv_2_rgb.asm
diff --git a/libswscale/x86/Makefile b/libswscale/x86/Makefile
index f317d5dd9b..831d5359aa 100644
--- a/libswscale/x86/Makefile
+++ b/libswscale/x86/Makefile
@@ -12,3 +12,4 @@ X86ASM-OBJS += x86/input.o
\
x86/output.o \
x86/scale.o \
x86/rgb_2_rgb.o \
+ x86/yuv_2_rgb.o \
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 0eed4f18d5..e9d474a1e8 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -29,6 +29,14 @@
#include "libavutil/cpu.h"
#include "libavutil/pixdesc.h"
+const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
+0x0103010301030103LL,
+0x0200020002000200LL,};
+
+const DECLARE_ALIGNED(8, uint64_t, ff_dither8)[2] = {
+0x0602060206020602LL,
+0x0004000400040004LL,};
+
#if HAVE_INLINE_ASM
#define DITHER1XBPP
@@ -38,14 +46,6 @@ DECLARE_ASM_CONST(8, uint64_t, bFC)=
0xFCFCFCFCFCFCFCFCLL;
DECLARE_ASM_CONST(8, uint64_t, w10)= 0x0010001000100010LL;
DECLARE_ASM_CONST(8, uint64_t, w02)= 0x0002000200020002LL;
-const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
-0x0103010301030103LL,
-0x0200020002000200LL,};
-
-const DECLARE_ALIGNED(8, uint64_t, ff_dither8)[2] = {
-0x0602060206020602LL,
-0x0004000400040004LL,};
-
DECLARE_ASM_CONST(8, uint64_t, b16Mask)= 0x001F001F001F001FLL;
DECLARE_ASM_CONST(8, uint64_t, g16Mask)= 0x07E007E007E007E0LL;
DECLARE_ASM_CONST(8, uint64_t, r16Mask)= 0xF800F800F800F800LL;
diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
index 5e2f77c20f..c7668f487c 100644
--- a/libswscale/x86/yuv2rgb.c
+++ b/libswscale/x86/yuv2rgb.c
@@ -37,7 +37,7 @@
#include "libavutil/x86/cpu.h"
#include "libavutil/cpu.h"
-#if HAVE_INLINE_ASM
+#if HAVE_X86ASM
#define DITHER1XBPP // only for MMX
@@ -50,32 +50,31 @@ DECLARE_ASM_CONST(8, uint64_t, pb_03) =
0x0303030303030303ULL;
DECLARE_ASM_CONST(8, uint64_t, pb_07) = 0x0707070707070707ULL;
//MMX versions
-#if HAVE_MMX_INLINE && HAVE_6REGS
+#if HAVE_MMX
#undef RENAME
#undef COMPILE_TEMPLATE_MMXEXT
#define COMPILE_TEMPLATE_MMXEXT 0
#define RENAME(a) a ## _mmx
#include "yuv2rgb_template.c"
-#endif /* HAVE_MMX_INLINE && HAVE_6REGS */
+#endif /* HAVE_MMX */
// MMXEXT versions
-#if HAVE_MMXEXT_INLINE && HAVE_6REGS
+#if HAVE_MMXEXT
#undef RENAME
#undef COMPILE_TEMPLATE_MMXEXT
#define COMPILE_TEMPLATE_MMXEXT 1
#define RENAME(a) a ## _mmxext
#include "yuv2rgb_template.c"
-#endif /* HAVE_MMXEXT_INLINE && HAVE_6REGS */
+#endif /* HAVE_MMXEXT */
-#endif /* HAVE_INLINE_ASM */
+#endif /* HAVE_X86ASM */
av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
{
-#if HAVE_MMX_INLINE && HAVE_6REGS
+#if HAVE_X86ASM
int cpu_flags = av_get_cpu_flags();
-#if HAVE_MMXEXT_INLINE
-if (INLINE_MMXEXT(cpu_flags)) {
+if (EXTERNAL_MMXEXT(cpu_flags)) {
switch (c->dstFormat) {
case AV_PIX_FMT_RGB24:
return yuv420_rgb24_mmxext;
@@ -83,13 +82,12 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
return yuv420_bgr24_mmxext;
}
}
-#endif
-if (INLINE_MMX(cpu_flags)) {
+if (EXTERNAL_MMX(cpu_flags)) {
switch (c->dstFormat) {
case AV_PIX_FMT_RGB32:
if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
-#if HAVE_7REGS && CONFIG_SWSCALE_ALPHA
+#if CONFIG_SWSCALE_ALPHA
return yuva420_rgb32_mmx;
#endif
break;
@@ -97,7 +95,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
return yuv420_rgb32_mmx;
case AV_PIX_FMT_BGR32:
if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
-#if HAVE_7REGS && CONFIG_SWSCALE_ALPHA
+#if CONFIG_SWSCALE_ALPHA
return yuva420_bgr32_mmx;
#endif
break;
@@ -113,7 +111,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
return yuv420_rgb15_mmx;
}
}
-#endif /* HAVE_MMX_INLINE && HAVE_6REGS */
+#endif /* HAVE_X86ASM */
return NULL;
}
diff --git a/libswscale/x86/yuv2rgb_template.c
b/libswscale/x86/yuv2rgb_template.c
index acb78f
[FFmpeg-devel] [PATCH V8 2/2] libswscale/x86/yuv2rgb: add ssse3 version
Tested using this command:
/ffmpeg -pix_fmt yuv420p -s 1920*1080 -i ArashRawYuv420.yuv \
-vcodec rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null
The fps increase from 389 to 640 on Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
Signed-off-by: Ting Fu
---
libswscale/x86/yuv2rgb.c | 38 +
libswscale/x86/yuv_2_rgb.asm | 145 +++
2 files changed, 167 insertions(+), 16 deletions(-)
diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
index c7668f487c..c12e88cbb5 100644
--- a/libswscale/x86/yuv2rgb.c
+++ b/libswscale/x86/yuv2rgb.c
@@ -67,6 +67,15 @@ DECLARE_ASM_CONST(8, uint64_t, pb_07) =
0x0707070707070707ULL;
#include "yuv2rgb_template.c"
#endif /* HAVE_MMXEXT */
+//SSSE3 versions
+#if HAVE_SSSE3
+#undef RENAME
+#undef COMPILE_TEMPLATE_MMXEXT
+#define COMPILE_TEMPLATE_MMXEXT 0
+#define RENAME(a) a ## _ssse3
+#include "yuv2rgb_template.c"
+#endif
+
#endif /* HAVE_X86ASM */
av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
@@ -74,6 +83,35 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
#if HAVE_X86ASM
int cpu_flags = av_get_cpu_flags();
+if (EXTERNAL_SSSE3(cpu_flags)) {
+switch (c->dstFormat) {
+case AV_PIX_FMT_RGB32:
+if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
+#if CONFIG_SWSCALE_ALPHA
+return yuva420_rgb32_ssse3;
+#endif
+break;
+} else
+return yuv420_rgb32_ssse3;
+case AV_PIX_FMT_BGR32:
+if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
+#if CONFIG_SWSCALE_ALPHA
+return yuva420_bgr32_ssse3;
+#endif
+break;
+} else
+return yuv420_bgr32_ssse3;
+case AV_PIX_FMT_RGB24:
+return yuv420_rgb24_ssse3;
+case AV_PIX_FMT_BGR24:
+return yuv420_bgr24_ssse3;
+case AV_PIX_FMT_RGB565:
+return yuv420_rgb16_ssse3;
+case AV_PIX_FMT_RGB555:
+return yuv420_rgb15_ssse3;
+}
+}
+
if (EXTERNAL_MMXEXT(cpu_flags)) {
switch (c->dstFormat) {
case AV_PIX_FMT_RGB24:
diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
index a44ab1607b..e05bbb89f5 100644
--- a/libswscale/x86/yuv_2_rgb.asm
+++ b/libswscale/x86/yuv_2_rgb.asm
@@ -25,11 +25,18 @@
SECTION_RODATA
-pw_00ff: times 4 dw 255
-pb_f8: times 8 db 248
-pb_e0: times 8 db 224
-pb_03: times 8 db 3
-pb_07: times 8 db 7
+; below variables are named like mask_dwXY, which means to preserve dword No.X
& No.Y
+mask_dw036 : db -1, -1, 0, 0, 0, 0, -1, -1, 0, 0, 0, 0, -1, -1, 0, 0
+mask_dw147 : db 0, 0, -1, -1, 0, 0, 0, 0, -1, -1, 0, 0, 0, 0, -1, -1
+mask_dw25 : db 0, 0, 0, 0, -1, -1, 0, 0, 0, 0, -1, -1, 0, 0, 0, 0
+rgb24_shuf1: db 0, 1, 6, 7, 12, 13, 2, 3, 8, 9, 14, 15, 4, 5, 10, 11
+rgb24_shuf2: db 10, 11, 0, 1, 6, 7, 12, 13, 2, 3, 8, 9, 14, 15, 4, 5
+rgb24_shuf3: db 4, 5, 10, 11, 0, 1, 6, 7, 12, 13, 2, 3, 8, 9, 14, 15
+pw_00ff: times 8 dw 255
+pb_f8: times 16 db 248
+pb_e0: times 16 db 224
+pb_03: times 16 db 3
+pb_07: times 16 db 7
mask_1101: dw -1, -1, 0, -1
mask_0010: dw 0, 0, -1, 0
@@ -49,7 +56,11 @@ SECTION .text
;-
%macro MOV_H2L 1
-psrlq %1, 32
+%if mmsize == 8
+psrlq %1, 32
+%else ; mmsize == 16
+psrldq %1, 8
+%endif
%endmacro
%macro yuv2rgb_fn 3
@@ -77,6 +88,7 @@ psrlq %1, 32
%define m_blue m1
%endif
+%if mmsize == 8
%define time_num 1
%define reg_num 8
%define y_offset [pointer_c_ditherq + 8 * 8]
@@ -87,11 +99,45 @@ psrlq %1, 32
%define y_coff [pointer_c_ditherq + 3 * 8]
%define ub_coff [pointer_c_ditherq + 5 * 8]
%define vr_coff [pointer_c_ditherq + 4 * 8]
+%elif mmsize == 16
+%define time_num 2
+%if ARCH_X86_32
+%define reg_num 8
+%define my_offset [pointer_c_ditherq + 8 * 8]
+%define mu_offset [pointer_c_ditherq + 9 * 8]
+%define mv_offset [pointer_c_ditherq + 10 * 8]
+%define mug_coff [pointer_c_ditherq + 7 * 8]
+%define mvg_coff [pointer_c_ditherq + 6 * 8]
+%define my_coff [pointer_c_ditherq + 3 * 8]
+%define mub_coff [pointer_c_ditherq + 5 * 8]
+%define mvr_coff [pointer_c_ditherq + 4 * 8]
+%else ; ARCH_X86_64
+%define reg_num 16
+%define y_offset m8
+%define u_offset m9
+%define v_offset m10
+%define ug_coff m11
+%define vg_coff m12
+%define y_coff m13
+%define ub_coff m14
+%define vr_coff m15
+%endif ; ARCH_X86_32/64
+%endif ; coeff define mmsize == 8/16
cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
%if ARCH_X86_64
movsxd indexq, indexd
+%if mmsize == 16
+VBROADCASTSD y_offset, [pointer_c_ditherq + 8 * 8]
+VBROADCASTSD u_offset, [pointer_c_ditherq + 9 * 8]
+VBROADCASTSD v_offset, [pointer_c_ditherq + 10 * 8]
+VBROADCASTSD ug_coff, [pointer_c_ditherq + 7 * 8]
+VBROADCASTSD vg_coff, [pointer_c_ditherq + 6 * 8]
+VBROADCASTSD y_coff,
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add demuxer for argonaut games' ASF format
On Sun, Jan 19, 2020 at 4:12 AM Zane van Iperen
wrote:
> Adds support for the custom ASF container used by some Argonaut Games'
> games, such as 'Croc! Legend of the Gobbos', and 'Croc 2'.
>
> Can also handle the sample files in:
> https://samples.ffmpeg.org/game-formats/brender/part2.zip
>
> Signed-off-by: Zane van Iperen
> ---
> Changelog| 1 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/argo_asf.c | 254 +++
> libavformat/version.h| 4 +-
> 5 files changed, 259 insertions(+), 2 deletions(-)
> create mode 100644 libavformat/argo_asf.c
>
> diff --git a/Changelog b/Changelog
> index e26320c0ce..bc1593bfd1 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -31,6 +31,7 @@ version :
> - thistogram filter
> - freezeframes filter
> - Argonaut Games ADPCM decoder
> +- Argonaut Games ASF demuxer
>
> version 4.2:
> - tpad filter
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 52f29b1a6d..ba6ea8c4a6 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -99,6 +99,7 @@ OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
> OBJS-$(CONFIG_APTX_HD_DEMUXER) += aptxdec.o rawdec.o
> OBJS-$(CONFIG_APTX_HD_MUXER) += rawenc.o
> OBJS-$(CONFIG_AQTITLE_DEMUXER) += aqtitledec.o subtitles.o
> +OBJS-$(CONFIG_ARGO_ASF_DEMUXER) += argo_asf.o
> OBJS-$(CONFIG_ASF_DEMUXER) += asfdec_f.o asf.o asfcrypt.o \
> avlanguage.o
> OBJS-$(CONFIG_ASF_O_DEMUXER) += asfdec_o.o asf.o asfcrypt.o \
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index ff9bdb906f..fe74a32e47 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -60,6 +60,7 @@ extern AVOutputFormat ff_aptx_muxer;
> extern AVInputFormat ff_aptx_hd_demuxer;
> extern AVOutputFormat ff_aptx_hd_muxer;
> extern AVInputFormat ff_aqtitle_demuxer;
> +extern AVInputFormat ff_argo_asf_demuxer;
> extern AVInputFormat ff_asf_demuxer;
> extern AVOutputFormat ff_asf_muxer;
> extern AVInputFormat ff_asf_o_demuxer;
> diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
> new file mode 100644
> index 00..ab8a0955ab
> --- /dev/null
> +++ b/libavformat/argo_asf.c
> @@ -0,0 +1,254 @@
> +/*
> + * Argonaut Games ASF demuxer
> + *
> + * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
> + *
> + * 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 "avformat.h"
> +#include "internal.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/bswap.h"
> +#include "libavutil/avassert.h"
> +
> +#pragma pack(push, 1)
> +typedef struct ArgoASFFileHeader {
> +uint8_t magic[4]; /*< Magic Number, {'A', 'S', 'F', '\0'} */
> +uint16_tversion_major; /*< File Major Version. */
> +uint16_tversion_minor; /*< File Minor Version. */
> +uint32_tnum_chunks; /*< No. chunks in the file. */
> +uint32_tchunk_offset; /*< Offset to the first chunk from the
> start of the file. */
> +int8_t name[8];/*< Name. */
> +} ArgoASFFileHeader;
> +
> +typedef struct ArgoASFChunkHeader {
> +uint32_tnum_blocks; /*< No. blocks in the chunk. */
> +uint32_tnum_samples;/*< No. samples per channel in a block. */
> +uint32_tunk1; /*< Unknown */
> +uint16_tsample_rate;/*< Sample rate. */
> +uint16_tunk2; /*< Unknown. */
> +uint32_tflags; /*< Stream flags. */
> +} ArgoASFChunkHeader;
> +#pragma pack(pop)
> +
>
These pragmas should be removed.
> +enum {
> +ASF_CF_BITS_PER_SAMPLE = (1 << 0), /*< 16-bit if set, 8 otherwise.
> */
> +ASF_CF_STEREO = (1 << 1), /*< Stereo if set, mono
> otherwise. */
> +ASF_CF_ALWAYS1_1= (1 << 2), /*< Unknown, always seems to be
> set. */
> +ASF_CF_ALWAYS1_2= (1 << 3), /*< Unknown, always seems to be
> set. */
> +
> +ASF_CF_ALWAYS1 = ASF_CF_ALWAYS1_1 | ASF_CF_ALWAYS1_2,
> +ASF_CF_ALWAYS0 = ~(ASF_CF_BITS_PER_SAMPLE | ASF_CF_STEREO |
> ASF_CF_ALWAYS1)
> +};
> +
> +typedef struct ArgoASFDemuxContext
> +{
> +
Re: [FFmpeg-devel] [PATCH v3] avformat/rtpdec_rfc4175: support non-zero based line numbers
On Thu, Nov 07, 2019 at 10:35:25PM +0100, Michael Niedermayer wrote:
> On Thu, Nov 07, 2019 at 10:27:31PM +0800, Kah Goh wrote:
> > On Mon, Sep 30, 2019 at 09:27:20PM +0800, Kah Goh wrote:
> > > There are differing standards that define different starting line
> > > numbers. For example, VSF TR-03 says the line numbers starts at 1,
> > > whereas SMPTE 2110-20 says it should start at 0.
> > >
> > > This change adds support for non-zero based line numbers and addresses
> > > the following issues when it starts at 1:
> > > - The first scan line was being incorrectly interpreted as the second
> > > scan line. This means the first line in the frame was never being
> > > populated.
> > > - The last packet for the video frame would be treated as invalid
> > > because it would have been copied outside of the frame. Consequently,
> > > the packet would never be "finalized" and the next packet triggers a
> > > missed RTP marker ("Missed previous RTP marker" would keep being
> > > logged).
> > >
> > > VSF TR-03:
> > > http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf
> > >
> > > Co-Authored-By: Jacob Siddall
> > > Co-Authored-By: Kah Goh
> > > Signed-off-by: Kah Goh
> > > ---
> > > libavformat/rtpdec_rfc4175.c | 49 +---
> > > 1 file changed, 45 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> > > index e9c62c1389..47d5d23dd6 100644
> > > --- a/libavformat/rtpdec_rfc4175.c
> > > +++ b/libavformat/rtpdec_rfc4175.c
> > > @@ -25,6 +25,7 @@
> > > #include "rtpdec_formats.h"
> > > #include "libavutil/avstring.h"
> > > #include "libavutil/pixdesc.h"
> > > +#include
> > >
> > > struct PayloadContext {
> > > char *sampling;
> > > @@ -37,6 +38,12 @@ struct PayloadContext {
> > > unsigned int pgroup; /* size of the pixel group in bytes */
> > > unsigned int xinc;
> > >
> > > +/* The line number of the first line in the frame (usually either 0
> > > or 1). */
> > > +int first_line_number;
> > > +
> > > +/* This is set to true once the first line number is confirmed. */
> > > +bool first_line_number_known;
> > > +
> > > uint32_t timestamp;
> > > };
> > >
> > > @@ -136,6 +143,13 @@ static int rfc4175_finalize_packet(PayloadContext
> > > *data, AVPacket *pkt,
> > > return ret;
> > > }
> > >
> > > +static int rfc4175_initialize(AVFormatContext *s, int st_index,
> > > PayloadContext *data)
> > > +{
> > > +data->first_line_number = 0;
> > > +data->first_line_number_known = false;
> > > +return 0;
> > > +}
> > > +
> > > static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext
> > > *data,
> > > AVStream *st, AVPacket *pkt, uint32_t
> > > *timestamp,
> > > const uint8_t * buf, int len,
> > > @@ -188,7 +202,7 @@ static int rfc4175_handle_packet(AVFormatContext
> > > *ctx, PayloadContext *data,
> > >
> > > /* and now iterate over every scan lines */
> > > do {
> > > -int copy_offset;
> > > +int copy_offset, copy_to_line;
> > >
> > > if (payload_len < data->pgroup)
> > > return AVERROR_INVALIDDATA;
> > > @@ -199,17 +213,34 @@ static int rfc4175_handle_packet(AVFormatContext
> > > *ctx, PayloadContext *data,
> > > cont = headers[4] & 0x80;
> > > headers += 6;
> > >
> > > +if (line == 0) {
> > > +data->first_line_number = 0;
> > > +data->first_line_number_known = true;
> > > +}
> > > +
> > > if (length % data->pgroup)
> > > return AVERROR_INVALIDDATA;
> > >
> > > if (length > payload_len)
> > > length = payload_len;
> > >
> > > -/* prevent ill-formed packets to write after buffer's end */
> > > -copy_offset = (line * data->width + offset) * data->pgroup /
> > > data->xinc;
> > > -if (copy_offset + length > data->frame_size)
> > > +copy_to_line = line - data->first_line_number;
> > > +if (copy_to_line < 0)
> > > +/* This means the first line number we have calculated is
> > > too large, which indicates that we
> > > +may have received some bad data. */
> > > return AVERROR_INVALIDDATA;
> > >
> > > +/* prevent ill-formed packets to write after buffer's end */
> > > +copy_offset = (copy_to_line * data->width + offset) *
> > > data->pgroup / data->xinc;
> > > +if (copy_offset + length > data->frame_size) {
> > > +if (data->first_line_number_known)
> > > +return AVERROR_INVALIDDATA;
> > > +
> > > +// This would happen if the line numbering is 1 based. We
> > > still need to check for the RTP flag
> > > +// marker (as per after the while loop).
> > > +break;
> > > +}
> > > +
> > > dest = da
Re: [FFmpeg-devel] [PATCH] avfilter/pad: improve error check for w and h
On 18-01-2020 12:21 pm, Gyan wrote:
On 15-01-2020 09:25 pm, Gyan Doshi wrote:
Target dimensions have to cover entire input.
---
libavfilter/vf_pad.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
index 186d3f028d..e86292eaa2 100644
--- a/libavfilter/vf_pad.c
+++ b/libavfilter/vf_pad.c
@@ -178,14 +178,14 @@ static int config_input(AVFilterLink *inlink)
if (s->y < 0 || s->y + inlink->h > s->h)
s->y = var_values[VAR_Y] = (s->h - inlink->h) / 2;
+ s->w = ff_draw_round_to_sub(&s->draw, 0, -1, s->w);
+ s->h = ff_draw_round_to_sub(&s->draw, 1, -1, s->h);
/* sanity check params */
- if (s->w < 0 || s->h < 0) {
- av_log(ctx, AV_LOG_ERROR, "Negative values are not
acceptable.\n");
+ if (s->w < inlink->w || s->h < inlink->h) {
+ av_log(ctx, AV_LOG_ERROR, "Padded dimensions cannot be
smaller than input dimensions.\n");
return AVERROR(EINVAL);
}
- s->w = ff_draw_round_to_sub(&s->draw, 0, -1, s->w);
- s->h = ff_draw_round_to_sub(&s->draw, 1, -1, s->h);
s->x = ff_draw_round_to_sub(&s->draw, 0, -1, s->x);
s->y = ff_draw_round_to_sub(&s->draw, 1, -1, s->y);
s->in_w = ff_draw_round_to_sub(&s->draw, 0, -1, inlink->w);
Will push in a day.
Pushed as 4de2106fbf5301e0f504849f098abc3057f87599
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add demuxer for argonaut games' ASF format
19/1/20 2:18 pm, Andreas Rheinhardt пишет:
>
> On Sun, Jan 19, 2020 at 4:12 AM Zane van Iperen
> wrote:
>
>> Adds support for the custom ASF container used by some Argonaut Games'
>> games, such as 'Croc! Legend of the Gobbos', and 'Croc 2'.
>>
>> Can also handle the sample files in:
>> https://samples.ffmpeg.org/game-formats/brender/part2.zip
>>
>> Signed-off-by: Zane van Iperen
>> ---
>> Changelog| 1 +
>> libavformat/Makefile | 1 +
>> libavformat/allformats.c | 1 +
>> libavformat/argo_asf.c | 254 +++
>> libavformat/version.h| 4 +-
>> 5 files changed, 259 insertions(+), 2 deletions(-)
>> create mode 100644 libavformat/argo_asf.c
>>
>> diff --git a/Changelog b/Changelog
>> index e26320c0ce..bc1593bfd1 100644
>> --- a/Changelog
>> +++ b/Changelog
>> @@ -31,6 +31,7 @@ version :
>> - thistogram filter
>> - freezeframes filter
>> - Argonaut Games ADPCM decoder
>> +- Argonaut Games ASF demuxer
>>
>> version 4.2:
>> - tpad filter
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 52f29b1a6d..ba6ea8c4a6 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -99,6 +99,7 @@ OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
>> OBJS-$(CONFIG_APTX_HD_DEMUXER) += aptxdec.o rawdec.o
>> OBJS-$(CONFIG_APTX_HD_MUXER) += rawenc.o
>> OBJS-$(CONFIG_AQTITLE_DEMUXER) += aqtitledec.o subtitles.o
>> +OBJS-$(CONFIG_ARGO_ASF_DEMUXER) += argo_asf.o
>> OBJS-$(CONFIG_ASF_DEMUXER) += asfdec_f.o asf.o asfcrypt.o \
>> avlanguage.o
>> OBJS-$(CONFIG_ASF_O_DEMUXER) += asfdec_o.o asf.o asfcrypt.o \
>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>> index ff9bdb906f..fe74a32e47 100644
>> --- a/libavformat/allformats.c
>> +++ b/libavformat/allformats.c
>> @@ -60,6 +60,7 @@ extern AVOutputFormat ff_aptx_muxer;
>> extern AVInputFormat ff_aptx_hd_demuxer;
>> extern AVOutputFormat ff_aptx_hd_muxer;
>> extern AVInputFormat ff_aqtitle_demuxer;
>> +extern AVInputFormat ff_argo_asf_demuxer;
>> extern AVInputFormat ff_asf_demuxer;
>> extern AVOutputFormat ff_asf_muxer;
>> extern AVInputFormat ff_asf_o_demuxer;
>> diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
>> new file mode 100644
>> index 00..ab8a0955ab
>> --- /dev/null
>> +++ b/libavformat/argo_asf.c
>> @@ -0,0 +1,254 @@
>> +/*
>> + * Argonaut Games ASF demuxer
>> + *
>> + * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
>> + *
>> + * 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 "avformat.h"
>> +#include "internal.h"
>> +#include "libavutil/internal.h"
>> +#include "libavutil/bswap.h"
>> +#include "libavutil/avassert.h"
>> +
>> +#pragma pack(push, 1)
>> +typedef struct ArgoASFFileHeader {
>> +uint8_t magic[4]; /*< Magic Number, {'A', 'S', 'F', '\0'} */
>> +uint16_tversion_major; /*< File Major Version. */
>> +uint16_tversion_minor; /*< File Minor Version. */
>> +uint32_tnum_chunks; /*< No. chunks in the file. */
>> +uint32_tchunk_offset; /*< Offset to the first chunk from the
>> start of the file. */
>> +int8_t name[8];/*< Name. */
>> +} ArgoASFFileHeader;
>> +
>> +typedef struct ArgoASFChunkHeader {
>> +uint32_tnum_blocks; /*< No. blocks in the chunk. */
>> +uint32_tnum_samples;/*< No. samples per channel in a block. */
>> +uint32_tunk1; /*< Unknown */
>> +uint16_tsample_rate;/*< Sample rate. */
>> +uint16_tunk2; /*< Unknown. */
>> +uint32_tflags; /*< Stream flags. */
>> +} ArgoASFChunkHeader;
>> +#pragma pack(pop)
>> +
>>
>
> These pragmas should be removed.
>
>
Done.
>> +enum {
>> +ASF_CF_BITS_PER_SAMPLE = (1 << 0), /*< 16-bit if set, 8 otherwise.
>> */
>> +ASF_CF_STEREO = (1 << 1), /*< Stereo if set, mono
>> otherwise. */
>> +ASF_CF_ALWAYS1_1= (1 << 2), /*< Unknown, always seems to be
>> set. */
>> +ASF_CF_ALWAYS1_2= (1 << 3), /*< Unknown, always seems to be
>> set. */
>> +
>> +ASF
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add demuxer for argonaut games' ASF format
Zane van Iperen: > 19/1/20 2:18 pm, Andreas Rheinhardt пишет: >> >> On Sun, Jan 19, 2020 at 4:12 AM Zane van Iperen >> wrote: >> >>> Adds support for the custom ASF container used by some Argonaut Games' >>> games, such as 'Croc! Legend of the Gobbos', and 'Croc 2'. >>> >>> Can also handle the sample files in: >>> https://samples.ffmpeg.org/game-formats/brender/part2.zip >>> >>> Signed-off-by: Zane van Iperen ... >>> +score = 0; >>> +if (av_match_ext(p->filename, "asf")) >>> +score += AVPROBE_SCORE_EXTENSION; >>> + >>> +hdr = *(ArgoASFFileHeader*)p->buf; >>> +argo_asf_fix_header_endianness(&hdr); >>> + >>> >> >> You are modifying the probe buffer. I don't think you are supposed to do >> that (although the AVProbeData,buf is not a pointer to const uint8_t). >> Instead read what you need with AV_RL from the buffer. >> > hdr is a stack variable. I'm simply assigning it from the buffer, so > nothing's being changed. > It's a moot point anyway, since I've changed it to use AV_RL. > True. I only saw the cast and not the * before it. ... > > > Do I need to submit only the revised commit or do I resend the entire series > as a "v2"? > > Also, should I include any additional headers such as "Reviewed-by"? > The revised commit is enough. And you can add a "Reviewed-by". - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
