Re: [FFmpeg-devel] [PATCH v3 3/7] avcodec/mediacodecenc: use bsf to handle crop
ons 2022-12-21 klockan 15:17 +0800 skrev zhilizhao(赵志立): > > > > On Dec 21, 2022, at 02:24, Tomas Härdin wrote: > > > > tor 2022-12-15 klockan 01:37 +0800 skrev Zhao Zhili: > > > On Wed, 2022-12-14 at 18:08 +0100, Tomas Härdin wrote: > > > > > > > > > > > I think we might want something for this inside lavf somewhere, > > > > so > > > > that > > > > encoders can signal dimension alignment requirements. Some > > > > containers > > > > (MXF, MOV) support such cropping in a codec-agnostic manner. > > > > > > From my own experience, dimension mismatch between codec and > > > container > > > makes a lot of trouble. ISO base format specification specified > > > how > > > to > > > crop/scale after decoding clear, however, I don't think it has > > > been > > > widely supported, including FFmpeg. We can fix that inside of > > > FFmpeg, > > > but we should avoid such cases as much as we can. > > > > This is the difference between stored, sampled and display > > dimensions > > in MXF. For example 1080i video has StoredHeight = 544, > > SampledHeight = > > 540 and DisplayHeight = 540 (see AS-10). When you add VBLANK and > > HBLANK > > to the mix then all three dimensions are typically different. > > > > Anyway specifying at the NAL level whenever the essence isn't a > > multiple of 16x16 is obviously normal. The only complication I can > > think of is 4:2:2 and 4:4:4. Does MC require 16x16 also in those > > cases? > > I'd expect 16x8 and 8x8 respectively. > > It’s still 16x16. From H.264 specification: I stand corrected. I did give the spec a once-over a while back, but not everything sticks. /Tomas ___ 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] fftools/ffmpeg_ffplay_ffprobe_cmdutils:add -mask_url to replace the protocol address in the command with the asterisk (*)
I have modified the issues again. Please review it again. Thank you.
If the protocol address contains the user name and password, the ps -ef
command exposes plaintext. The -mask_url parameter option is added to
replace the protocol address in the command line with the asterisk (*).
Because other users can run the ps -ef command to view sensitive
information such as the user name and password in the protocol address,
which is insecure.
Signed-off-by: wujian_nanjing
---
doc/fftools-common-opts.texi | 11 +++
fftools/cmdutils.c | 75 ++--
fftools/cmdutils.h | 25 +++
fftools/ffmpeg.c | 10 +++---
fftools/ffplay.c | 9 --
fftools/ffprobe.c| 10 +++---
6 files changed, 126 insertions(+), 14 deletions(-)
diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index d914570..77b4e4a 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -363,6 +363,17 @@ for testing. Do not use it unless you know what you're
doing.
ffmpeg -cpucount 2
@end example
+@item -mask_url -i @var{url} (@emph{output})
+If the protocol address contains the user name and password, the ps -ef
+command exposes plaintext. The -mask_url parameter option is added to
+replace the protocol address in the command line with the asterisk (*).
+Because other users can run the ps -ef command to view sensitive
+information such as the user name and password in the protocol address,
+which is insecure.
+@example
+ffmpeg -mask_url -i rtsp://username:password-ip:port/stream/test
+@end example
+
@item -max_alloc @var{bytes}
Set the maximum size limit for allocating a block on the heap by ffmpeg's
family of malloc functions. Exercise @strong{extreme caution} when using
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index a1de621..08b6c28 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -61,6 +61,69 @@ AVDictionary *format_opts, *codec_opts;
int hide_banner = 0;
+void mask_param(int argc, char **argv)
+{
+int i, j;
+for (i = 1; i < argc; i++) {
+char *match = strstr(argv[i], "://");
+if (match) {
+int total = strlen(argv[i]);
+for (j = 0; j < total; j++) {
+argv[i][j] = '*';
+}
+}
+}
+}
+
+char **copy_argv(int argc, char **argv)
+{
+char **argv_copy;
+argv_copy = av_mallocz(argc * sizeof(char *));
+if (!argv_copy) {
+av_log(NULL, AV_LOG_FATAL, "argv_copy malloc failed\n");
+exit_program(1);
+}
+
+for (int i = 0; i < argc; i++) {
+int length = strlen(argv[i]) + 1;
+argv_copy[i] = av_mallocz(length * sizeof(char *));
+if (!argv_copy[i]) {
+av_log(NULL, AV_LOG_FATAL, "argv_copy[%d] malloc failed\n", i);
+exit_program(1);
+}
+memcpy(argv_copy[i], argv[i], length);
+}
+return argv_copy;
+}
+
+char **handle_arg_param(int argc, int mask_flag, char **argv)
+{
+char **argv_copy;
+argv_copy = copy_argv(argc, argv);
+if (mask_flag)
+mask_param(argc, argv);
+return argv_copy;
+}
+
+int get_mask_flag(int *argc, char ***argv)
+{
+if (*argc > 1 && !strcmp((*argv)[1], "-mask_url")) {
+(*argv)[1] = (*argv)[0];
+(*argc)--;
+(*argv)++;
+return 1;
+}
+
+return 0;
+}
+
+void free_argv_copy(int argc, char **argv)
+{
+for (int i = 0; i < argc; i++)
+av_free(argv[i]);
+av_free(argv);
+}
+
void uninit_opts(void)
{
av_dict_free(&swr_opts);
@@ -215,13 +278,13 @@ static void prepare_app_arguments(int *argc_ptr, char
***argv_ptr)
if (win32_argv_utf8) {
*argc_ptr = win32_argc;
*argv_ptr = win32_argv_utf8;
-return;
+goto end;
}
win32_argc = 0;
argv_w = CommandLineToArgvW(GetCommandLineW(), &win32_argc);
if (win32_argc <= 0 || !argv_w)
-return;
+goto end;
/* determine the UTF-8 buffer size (including NULL-termination symbols) */
for (i = 0; i < win32_argc; i++)
@@ -232,7 +295,7 @@ static void prepare_app_arguments(int *argc_ptr, char
***argv_ptr)
argstr_flat = (char *)win32_argv_utf8 + sizeof(char *) * (win32_argc +
1);
if (!win32_argv_utf8) {
LocalFree(argv_w);
-return;
+goto end;
}
for (i = 0; i < win32_argc; i++) {
@@ -246,6 +309,12 @@ static void prepare_app_arguments(int *argc_ptr, char
***argv_ptr)
*argc_ptr = win32_argc;
*argv_ptr = win32_argv_utf8;
+end:
+if (*argc_ptr > 1 && !strcmp((*argv_ptr)[1], "-mask_url")) {
+(*argv_ptr)[1] = (*argv_ptr)[0];
+(*argc_ptr)--;
+(*argv_ptr)++;
+}
}
#else
static inline void prepare_app_arguments(int *argc_ptr, char ***argv_ptr)
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 4496221..08c4da7 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -50,6 +50,31 @@ extern A
[FFmpeg-devel] [PATCH v7 2/2] avcodec/mjpegdec: add support for frame threading
In my tests, this lead to a notable speed increase with the amount
of threads used. Decoding a 720p sample gave the following results:
1 Thread: 1428 FPS
2 Threads: 2501 FPS
8 Threads: 7575 FPS
Automatic: 11326 FPS (On a 16 Core/32 Threads system)
---
libavcodec/jpeglsdec.c | 2 +-
libavcodec/mjpegdec.c | 11 ++-
libavcodec/sp5xdec.c | 4 ++--
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index ec163b8964..6e75c9b406 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -559,6 +559,6 @@ const FFCodec ff_jpegls_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(ff_mjpeg_decode_frame),
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index f33911e1a8..41d3f36940 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -54,6 +54,7 @@
#include "exif.h"
#include "bytestream.h"
#include "tiff_common.h"
+#include "thread.h"
static int init_default_huffman_tables(MJpegDecodeContext *s)
@@ -712,7 +713,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
s->avctx->pix_fmt,
AV_PIX_FMT_NONE,
};
-s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
+s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx, pix_fmts);
if (s->hwaccel_pix_fmt < 0)
return AVERROR(EINVAL);
@@ -728,7 +729,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
av_frame_unref(s->picture_ptr);
-if (ff_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) <
0)
+if (ff_thread_get_buffer(s->avctx, s->picture_ptr,
AV_GET_BUFFER_FLAG_REF) < 0)
return -1;
s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
s->picture_ptr->key_frame = 1;
@@ -2954,7 +2955,7 @@ const FFCodec ff_mjpeg_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(ff_mjpeg_decode_frame),
.flush = decode_flush,
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.p.priv_class = &mjpegdec_class,
.p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
@@ -2983,7 +2984,7 @@ const FFCodec ff_thp_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(ff_mjpeg_decode_frame),
.flush = decode_flush,
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
@@ -3062,7 +3063,7 @@ const FFCodec ff_smvjpeg_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(smvjpeg_receive_frame),
.flush = decode_flush,
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
FF_CODEC_CAP_SETS_PKT_DTS | FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
index dfed725500..af1b6400e1 100644
--- a/libavcodec/sp5xdec.c
+++ b/libavcodec/sp5xdec.c
@@ -103,7 +103,7 @@ const FFCodec ff_sp5x_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(sp5x_decode_frame),
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
@@ -119,7 +119,7 @@ const FFCodec ff_amv_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_DECODE_CB(sp5x_decode_frame),
.p.max_lowres = 3,
-.p.capabilities = AV_CODEC_CAP_DR1,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
#endif
--
2.34.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 v7 1/2] lavc: convert frame threading to the receive_frame() pattern
From: Anton Khirnov
Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls back into the generic decoding
code. This avoids duplicating the logic that wraps the decoder
invocation and will be useful in the following commits.
---
libavcodec/decode.c| 64 ++---
libavcodec/decode.h| 7 +
libavcodec/internal.h | 7 +
libavcodec/pthread_frame.c | 280 -
libavcodec/thread.h| 18 +--
5 files changed, 249 insertions(+), 127 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 3e5be501b9..d0b5293750 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -180,6 +180,11 @@ fail:
return ret;
}
+#if !HAVE_THREADS
+#define ff_thread_get_packet(avctx, pkt) (AVERROR_BUG)
+#define ff_thread_receive_frame(avctx, frame) (AVERROR_BUG)
+#endif
+
int ff_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt)
{
AVCodecInternal *avci = avctx->internal;
@@ -188,7 +193,14 @@ int ff_decode_get_packet(AVCodecContext *avctx, AVPacket
*pkt)
if (avci->draining)
return AVERROR_EOF;
-ret = av_bsf_receive_packet(avci->bsf, pkt);
+/* If we are a worker thread, get the next packet from the threading
+ * context. Otherwise we are the main (user-facing) context, so we get the
+ * next packet from the input filterchain.
+ */
+if (avctx->internal->is_frame_mt)
+ret = ff_thread_get_packet(avctx, pkt);
+else
+ret = av_bsf_receive_packet(avci->bsf, pkt);
if (ret == AVERROR_EOF)
avci->draining = 1;
if (ret < 0)
@@ -273,30 +285,25 @@ static inline int decode_simple_internal(AVCodecContext
*avctx, AVFrame *frame,
return AVERROR_EOF;
if (!pkt->data &&
-!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY ||
- avctx->active_thread_type & FF_THREAD_FRAME))
+!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
return AVERROR_EOF;
got_frame = 0;
-if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME) {
-ret = ff_thread_decode_frame(avctx, frame, &got_frame, pkt);
-} else {
-ret = codec->cb.decode(avctx, frame, &got_frame, pkt);
-
-if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
-frame->pkt_dts = pkt->dts;
-if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
-if(!avctx->has_b_frames)
-frame->pkt_pos = pkt->pos;
-//FIXME these should be under if(!avctx->has_b_frames)
-/* get_buffer is supposed to set frame parameters */
-if (!(avctx->codec->capabilities & AV_CODEC_CAP_DR1)) {
-if (!frame->sample_aspect_ratio.num)
frame->sample_aspect_ratio = avctx->sample_aspect_ratio;
-if (!frame->width)frame->width
= avctx->width;
-if (!frame->height) frame->height
= avctx->height;
-if (frame->format == AV_PIX_FMT_NONE) frame->format
= avctx->pix_fmt;
-}
+ret = codec->cb.decode(avctx, frame, &got_frame, pkt);
+
+if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
+frame->pkt_dts = pkt->dts;
+if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
+if(!avctx->has_b_frames)
+frame->pkt_pos = pkt->pos;
+//FIXME these should be under if(!avctx->has_b_frames)
+/* get_buffer is supposed to set frame parameters */
+if (!(avctx->codec->capabilities & AV_CODEC_CAP_DR1)) {
+if (!frame->sample_aspect_ratio.num) frame->sample_aspect_ratio =
avctx->sample_aspect_ratio;
+if (!frame->width)frame->width =
avctx->width;
+if (!frame->height) frame->height =
avctx->height;
+if (frame->format == AV_PIX_FMT_NONE) frame->format =
avctx->pix_fmt;
}
}
emms_c();
@@ -546,11 +553,11 @@ static int decode_simple_receive_frame(AVCodecContext
*avctx, AVFrame *frame)
return 0;
}
-static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+int ff_decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
{
AVCodecInternal *avci = avctx->internal;
const FFCodec *const codec = ffcodec(avctx->codec);
-int ret, ok;
+int ret;
av_assert0(!frame->buf[0]);
@@ -562,6 +569,17 @@ static int decode_receive_frame_internal(AVCodecContext
*avctx, AVFrame *frame)
if (ret == AVERROR_EOF)
avci->draining_done = 1;
+return ret;
+}
+
+static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+{
+int ret, ok;
+if (avctx->active_thread_type & FF_THREAD_FRAME)
+ret = ff_thread_receive_frame(avctx, frame);
+else
+ret = ff_decode_receive_frame_internal(avctx, frame);
+
/* preserve ret */
[FFmpeg-devel] [PATCH] avformat/segment: add option min_seg_duration
New option can be used to avoid creating very short segments with inputs
whose GOP size is variable or unharmonic with segment_time.
Only effective with segment_time.
---
doc/muxers.texi | 5 +
libavformat/segment.c | 12 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 4edbb22b00..ed5341be39 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2369,6 +2369,11 @@ Note that splitting may not be accurate, unless you
force the
reference stream key-frames at the given time. See the introductory
notice and the examples below.
+@item min_seg_duration @var{time}
+Set minimum segment duration to @var{time}, the value must be a duration
+specification. This prevents the muxer ending segments at a duration below
+this value. Only effective with @code{segment_time}. Default value is "0".
+
@item segment_atclocktime @var{1|0}
If set to "1" split at regular clock time intervals starting from 00:00
o'clock. The @var{time} value specified in @option{segment_time} is
diff --git a/libavformat/segment.c b/libavformat/segment.c
index c904e20708..c19c2a94ae 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -93,6 +93,7 @@ typedef struct SegmentContext {
int list_type; ///< set the list type
AVIOContext *list_pb; ///< list file put-byte context
int64_t time; ///< segment duration
+int64_t min_seg_duration; ///< minimum segment duration
int use_strftime; ///< flag to expand filename with strftime
int increment_tc; ///< flag to increment timecode if found
@@ -710,6 +711,10 @@ static int seg_init(AVFormatContext *s)
}
seg->clocktime_offset = seg->time - (seg->clocktime_offset %
seg->time);
}
+if (seg->min_seg_duration > seg->time) {
+av_log(s, AV_LOG_ERROR, "min_seg_duration cannot be greater than
segment_time\n");
+return AVERROR(EINVAL);
+}
}
if (seg->list) {
@@ -839,7 +844,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
{
SegmentContext *seg = s->priv_data;
AVStream *st = s->streams[pkt->stream_index];
-int64_t end_pts = INT64_MAX, offset;
+int64_t end_pts = INT64_MAX, offset, pkt_pts_avtb;
int start_frame = INT_MAX;
int ret;
struct tm ti;
@@ -890,11 +895,15 @@ calc_times:
pkt->flags & AV_PKT_FLAG_KEY,
pkt->stream_index == seg->reference_stream_index ?
seg->frame_count : -1);
+if (pkt->pts != AV_NOPTS_VALUE)
+pkt_pts_avtb = av_rescale_q(pkt->pts, st->time_base, AV_TIME_BASE_Q);
+
if (pkt->stream_index == seg->reference_stream_index &&
(pkt->flags & AV_PKT_FLAG_KEY || seg->break_non_keyframes) &&
(seg->segment_frame_count > 0 || seg->write_empty) &&
(seg->cut_pending || seg->frame_count >= start_frame ||
(pkt->pts != AV_NOPTS_VALUE &&
+ pkt_pts_avtb - seg->cur_entry.start_pts >= seg->min_seg_duration &&
av_compare_ts(pkt->pts, st->time_base,
end_pts - seg->time_delta, AV_TIME_BASE_Q) >= 0))) {
/* sanitize end time in case last packet didn't have a defined
duration */
@@ -1031,6 +1040,7 @@ static const AVOption options[] = {
{ "segment_clocktime_wrap_duration", "set segment clocktime wrapping
duration", OFFSET(clocktime_wrap_duration), AV_OPT_TYPE_DURATION, {.i64 =
INT64_MAX}, 0, INT64_MAX, E},
{ "segment_time", "set segment duration",
OFFSET(time),AV_OPT_TYPE_DURATION, {.i64 = 200}, INT64_MIN, INT64_MAX,
E },
{ "segment_time_delta","set approximation value used for the segment
times", OFFSET(time_delta), AV_OPT_TYPE_DURATION, {.i64 = 0}, 0, INT64_MAX, E },
+{ "min_seg_duration", "set minimum segment duration",
OFFSET(min_seg_duration), AV_OPT_TYPE_DURATION, {.i64 = 0}, 0, INT64_MAX, E },
{ "segment_times", "set segment split time points",
OFFSET(times_str),AV_OPT_TYPE_STRING,{.str = NULL}, 0, 0, E },
{ "segment_frames","set segment split frame numbers",
OFFSET(frames_str),AV_OPT_TYPE_STRING,{.str = NULL}, 0, 0, E },
{ "segment_wrap", "set number after which the index wraps",
OFFSET(segment_idx_wrap), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, E },
--
2.36.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] Would a crypto file be acceptable?
Hi, The ffmpeg crypto protocol handler [1] allows one to play encrypted media. The great thing here is that it allows playback of any media format that ffmpeg supports! Have a container format like mkv as an encrypted blob, no problem for the crypto plugin! I'm explicitly mentioning mkv (though there's many more) here because that isn't possible in HLS/MPD. While those streaming formats handle encryption too, they are very limited in terms of supported codecs and containers. Playback of encrypted data works like this: ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV While this works just fine, it's limited in use because the cryptography details have to be passed on the command line. Applications that might well support much of ffmpeg functionality can't easily hook into the crypto functionality. Take KODI for example, it allows playback of many of the formats ffmpeg supports but anything with crypto just isn't possible. In fact, anything that requires custom command line arguments isn't possible. [2] My idea is to make a new file format that would be implemented and specced within [1]. My proposed format would be: --- CRYPTO-VERSION:1 CRYPTO-KEY:URI:. CRYPTO-IV:URI:. encrypted_file --- The URI would be a format type identifier where you can choose between URI (to pass a URL to a key blob), BASE64URL (key encoded as base64url) or HEX. The above proposed format should be stored in a file with ".crypto" as extension. The crypto plugin [1] would then handle that file. The arguments would be filled based on the "properties" in the file. So for example the `decryption_key` argument would be populated with the blob returned from CRYPTO-KEY:URI:. Or with one of the other types. The "encrypted_file" would just be passed through ffmpeg's "ffurl_open_whitelist" like the crypto plugin currently does. Meaning that the file could be anything ffmpeg supports. Playing encrypted media would be as simple as: ffplay file.crypto With this mail I'm looking for a confirmation if the above concept would be allowed as a patch for ffmpeg? And if not, how can I achieve the same results in a way that would be acceptable? [3] Best regards, Mark Gaiser [1] https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/crypto.c [2] there are plugins to make it possible but then you have the extra requirement of a plugin []3 No, not HLS/MPD! They serve a different purpose. Extending them to serve my purpose is a lost goal to begin with so let's not even go there. ___ 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] Would a crypto file be acceptable?
On Wed, Dec 21, 2022 at 4:44 PM Mark Gaiser wrote: > Hi, > > The ffmpeg crypto protocol handler [1] allows one to play encrypted media. > > The great thing here is that it allows playback of any media format that > ffmpeg supports! > Have a container format like mkv as an encrypted blob, no problem for the > crypto plugin! > > I'm explicitly mentioning mkv (though there's many more) here because that > isn't possible in HLS/MPD. While those streaming formats handle encryption > too, they are very limited in terms of supported codecs and containers. > > Playback of encrypted data works like this: > ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV > To amend, a more accurate example of how it currently works is this: ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV > While this works just fine, it's limited in use because the cryptography > details have to be passed on the command line. Applications that might well > support much of ffmpeg functionality can't easily hook into the crypto > functionality. Take KODI for example, it allows playback of many of the > formats ffmpeg supports but anything with crypto just isn't possible. In > fact, anything that requires custom command line arguments isn't possible. > [2] > > My idea is to make a new file format that would be implemented and specced > within [1]. My proposed format would be: > > --- > CRYPTO-VERSION:1 > CRYPTO-KEY:URI:. > CRYPTO-IV:URI:. > encrypted_file > --- > > The URI would be a format type identifier where you can choose between URI > (to pass a URL to a key blob), BASE64URL (key encoded as base64url) or HEX. > > The above proposed format should be stored in a file with ".crypto" as > extension. The crypto plugin [1] would then handle that file. The arguments > would be filled based on the "properties" in the file. So for example the > `decryption_key` argument would be populated with the blob returned from > CRYPTO-KEY:URI:. Or with one of the other types. > > The "encrypted_file" would just be passed through ffmpeg's > "ffurl_open_whitelist" like the crypto plugin currently does. Meaning that > the file could be anything ffmpeg supports. > > Playing encrypted media would be as simple as: > ffplay file.crypto > To amend this too. The result should be no need to provide "crypto://". The ffmpeg file format detection should detect that ".crypto" should be handled by the crypto plugin. > > With this mail I'm looking for a confirmation if the above concept would > be allowed as a patch for ffmpeg? And if not, how can I achieve the same > results in a way that would be acceptable? [3] > > Best regards, > Mark Gaiser > > [1] https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/crypto.c > [2] there are plugins to make it possible but then you have the extra > requirement of a plugin > []3 No, not HLS/MPD! They serve a different purpose. Extending them to > serve my purpose is a lost goal to begin with so let's not even go there. > ___ 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 2/2] avcodec/mjpegdec: add support for frame threading
On Wed, Dec 21, 2022 at 03:22:56PM +0100, Timo Rothenpieler wrote: > In my tests, this lead to a notable speed increase with the amount > of threads used. Decoding a 720p sample gave the following results: > > 1 Thread: 1428 FPS > 2 Threads: 2501 FPS > 8 Threads: 7575 FPS > Automatic: 11326 FPS (On a 16 Core/32 Threads system) > --- > libavcodec/jpeglsdec.c | 2 +- > libavcodec/mjpegdec.c | 11 ++- > libavcodec/sp5xdec.c | 4 ++-- > 3 files changed, 9 insertions(+), 8 deletions(-) Changes output for: ./ffmpeg -an -i ~/tickets/1915/m_noint.avi -an -bitexact -f framecrc - will mail you the file as it seems its not on trac thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand 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] avcodec/sunrast: Fix maplength check
Fixes: out of bounds read
Found-by: Ibrahim Mohamed
Reviewed-by; Ibrahim Mohamed
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
index 45b29e4d72..3668d2be7f 100644
--- a/libavcodec/sunrast.c
+++ b/libavcodec/sunrast.c
@@ -19,6 +19,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include "libavutil/avassert.h"
#include "libavutil/common.h"
#include "libavutil/intreadwrite.h"
#include "avcodec.h"
@@ -75,6 +76,12 @@ static int sunrast_decode_frame(AVCodecContext *avctx,
AVFrame *p,
return AVERROR_PATCHWELCOME;
}
+if (maplength > 768) {
+av_log(avctx, AV_LOG_WARNING, "invalid colormap length\n");
+return AVERROR_INVALIDDATA;
+}
+
+// This also checks depth to be valid
switch (depth) {
case 1:
avctx->pix_fmt = maplength ? AV_PIX_FMT_PAL8 :
AV_PIX_FMT_MONOWHITE;
@@ -96,15 +103,23 @@ static int sunrast_decode_frame(AVCodecContext *avctx,
AVFrame *p,
return AVERROR_INVALIDDATA;
}
+// This checks w and h to be valid in the sense that bytes of a padded
bitmap are addressable with 32bit int
ret = ff_set_dimensions(avctx, w, h);
if (ret < 0)
return ret;
+// ensured by ff_set_dimensions()
+av_assert0(w <= (INT32_MAX - 7) / depth);
+
/* scanlines are aligned on 16 bit boundaries */
len = (depth * w + 7) >> 3;
alen = len + (len & 1);
-if (buf_end - buf < maplength + (len * h) * 3 / 256)
+// ensured by ff_set_dimensions()
+av_assert0(h <= INT32_MAX / (3 * len));
+
+// maplength is limited to 768 and the right term is limited to INT32_MAX
/ 256 so the add needs no check
+if (buf_end - buf < (uint64_t)maplength + (len * h) * 3 / 256)
return AVERROR_INVALIDDATA;
if ((ret = ff_get_buffer(avctx, p, 0)) < 0)
@@ -118,7 +133,7 @@ static int sunrast_decode_frame(AVCodecContext *avctx,
AVFrame *p,
} else if (maplength) {
unsigned int len = maplength / 3;
-if (maplength % 3 || maplength > 768) {
+if (maplength % 3) {
av_log(avctx, AV_LOG_WARNING, "invalid colormap length\n");
return AVERROR_INVALIDDATA;
}
--
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".
Re: [FFmpeg-devel] [PATCH v2 13/13] lavc/vaapi_hevc: Remove duplicate code
On Mon, 2022-12-05 at 14:09 +0800, Fei Wang wrote:
> Signed-off-by: Fei Wang
> ---
> libavcodec/vaapi_hevc.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
> index ca14052d56..b3ff2f7344 100644
> --- a/libavcodec/vaapi_hevc.c
> +++ b/libavcodec/vaapi_hevc.c
> @@ -538,12 +538,6 @@ static int
> vaapi_hevc_decode_slice(AVCodecContext *avctx,
> pic->last_slice_param.rext.ChromaOffsetL0[i][1] = sh-
> >chroma_offset_l0[i][1];
> }
>
> -for (i = 0; i < 15 && i < sh->nb_refs[L0]; i++) {
> -pic->last_slice_param.rext.luma_offset_l0[i] = sh-
> >luma_offset_l0[i];
> -pic->last_slice_param.rext.ChromaOffsetL0[i][0] = sh-
> >chroma_offset_l0[i][0];
> -pic->last_slice_param.rext.ChromaOffsetL0[i][1] = sh-
> >chroma_offset_l0[i][1];
> -}
> -
Confirmed locally, FATE test pass without any error.
Thanks
Fei
> if (sh->slice_type == HEVC_SLICE_B) {
> for (i = 0; i < 15 && i < sh->nb_refs[L1]; i++) {
> pic->last_slice_param.rext.luma_offset_l1[i] = sh-
> >luma_offset_l1[i];
___
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] libavformat/rtspdec.c: flush pes buffer while rtsp seek
Fixes ticket #9949.
Signed-off-by: t00660896
---
libavformat/mpegts.c| 20
libavformat/mpegts.h| 1 +
libavformat/rtpdec.c| 7 +++
libavformat/rtpdec.h| 2 ++
libavformat/rtpdec_mpegts.c | 11 +++
libavformat/rtspdec.c | 11 +++
6 files changed, 52 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index d97702fcd7..c82971af87 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -3419,6 +3419,26 @@ int avpriv_mpegts_parse_packet(MpegTSContext *ts,
AVPacket *pkt,
return len1 - len;
}
+void ff_mpegts_seek_flush(MpegTSContext *ts)
+{
+int i;
+/* flush pes buffer */
+for (i = 0; i < NB_PID_MAX; i++) {
+if (ts->pids[i]) {
+if (ts->pids[i]->type == MPEGTS_PES) {
+PESContext *pes = ts->pids[i]->u.pes_filter.opaque;
+av_buffer_unref(&pes->buffer);
+pes->data_index = 0;
+pes->state = MPEGTS_SKIP; /* skip until pes header */
+} else if (ts->pids[i]->type == MPEGTS_SECTION) {
+ts->pids[i]->u.section_filter.last_ver = -1;
+}
+ts->pids[i]->last_cc = -1;
+ts->pids[i]->last_pcr = -1;
+}
+}
+}
+
void avpriv_mpegts_parse_close(MpegTSContext *ts)
{
mpegts_free(ts);
diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index a48f14e768..ea6b5106a4 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -170,6 +170,7 @@ MpegTSContext *avpriv_mpegts_parse_open(AVFormatContext *s);
int avpriv_mpegts_parse_packet(MpegTSContext *ts, AVPacket *pkt,
const uint8_t *buf, int len);
void avpriv_mpegts_parse_close(MpegTSContext *ts);
+void ff_mpegts_seek_flush(MpegTSContext *ts);
typedef struct SLConfigDescr {
int use_au_start;
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index fa7544cc07..d688afd1c1 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -954,6 +954,13 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket *pkt,
return rv ? rv : has_next_packet(s);
}
+void ff_rtp_seek_flush(RTPDemuxContext *s)
+{
+ff_rtp_reset_packet_queue(s);
+if (s->handler && s->handler->seek_flush)
+s->handler->seek_flush(s->dynamic_protocol_context);
+}
+
void ff_rtp_parse_close(RTPDemuxContext *s)
{
ff_rtp_reset_packet_queue(s);
diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
index 5a02e72dc2..8d6d857e28 100644
--- a/libavformat/rtpdec.h
+++ b/libavformat/rtpdec.h
@@ -52,6 +52,7 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket *pkt,
void ff_rtp_parse_close(RTPDemuxContext *s);
int64_t ff_rtp_queued_packet_time(RTPDemuxContext *s);
void ff_rtp_reset_packet_queue(RTPDemuxContext *s);
+void ff_rtp_seek_flush(RTPDemuxContext *s);
/**
* Send a dummy packet on both port pairs to set up the connection
@@ -135,6 +136,7 @@ struct RTPDynamicProtocolHandler {
/** Parse handler for this dynamic packet */
DynamicPayloadPacketHandlerProc parse_packet;
int (*need_keyframe)(PayloadContext *context);
+void (*seek_flush)(PayloadContext *protocol_data);
};
typedef struct RTPPacket {
diff --git a/libavformat/rtpdec_mpegts.c b/libavformat/rtpdec_mpegts.c
index 405271f744..46c1d36021 100644
--- a/libavformat/rtpdec_mpegts.c
+++ b/libavformat/rtpdec_mpegts.c
@@ -47,6 +47,16 @@ static av_cold int mpegts_init(AVFormatContext *ctx, int
st_index,
return 0;
}
+static void mpegts_seek_flush(PayloadContext *data)
+{
+if (!data)
+return;
+memset(data->buf, 0, data->read_buf_size);
+data->read_buf_size = 0;
+if (data->ts)
+ff_mpegts_seek_flush(data->ts);
+}
+
static int mpegts_handle_packet(AVFormatContext *ctx, PayloadContext *data,
AVStream *st, AVPacket *pkt, uint32_t
*timestamp,
const uint8_t *buf, int len, uint16_t seq,
@@ -94,6 +104,7 @@ const RTPDynamicProtocolHandler ff_mpegts_dynamic_handler = {
.priv_data_size= sizeof(PayloadContext),
.parse_packet = mpegts_handle_packet,
.init = mpegts_init,
+.seek_flush= mpegts_seek_flush,
.close = mpegts_close_context,
.static_payload_id = 33,
};
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index bbabec7db8..22b08a4c56 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -36,6 +36,7 @@
#include "rdt.h"
#include "tls.h"
#include "url.h"
+#include "mpegts.h"
#include "version.h"
static const struct RTSPStatusMessage {
@@ -982,6 +983,16 @@ static int rtsp_read_seek(AVFormatContext *s, int
stream_index,
rt->state = RTSP_STATE_IDLE;
break;
}
+
+if (rt->cur_transport_priv && rt->transport == RTSP_TRANSPORT_RTP) {
+ff_rtp_seek_flush(rt->cur_transport_pr
