Re: [FFmpeg-devel] [PATCH] ffmpeg: add option recast_media
Quoting Gyan Doshi (2021-07-13 11:12:19)
>
>
> On 2021-07-13 13:14, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2021-07-02 12:03:05)
> >> Allows forcing decoders of different media type.
> >> Needed to decode media data muxed as data streams.
> >> ---
> >> doc/ffmpeg.texi | 5 +
> >> fftools/ffmpeg_opt.c | 7 ++-
> >> 2 files changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >> index 7827291755..c1065086e5 100644
> >> --- a/doc/ffmpeg.texi
> >> +++ b/doc/ffmpeg.texi
> >> @@ -449,6 +449,11 @@ output file already exists.
> >> Set number of times input stream shall be looped. Loop 0 means no loop,
> >> loop -1 means infinite loop.
> >>
> >> +@item -recast_media (@emph{global})
> >> +Enable to allow forcing a decoder of a different media type than
> >> +the one detected or designated by the demuxer. Useful for decoding
> >> +media data muxed as data streams.
> >> +
> >> @item -c[:@var{stream_specifier}] @var{codec}
> >> (@emph{input/output,per-stream})
> >> @itemx -codec[:@var{stream_specifier}] @var{codec}
> >> (@emph{input/output,per-stream})
> >> Select an encoder (when used before an output file) or a decoder (when
> >> used
> >> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> >> index a63bed54cf..76a220c21c 100644
> >> --- a/fftools/ffmpeg_opt.c
> >> +++ b/fftools/ffmpeg_opt.c
> >> @@ -186,6 +186,7 @@ static int input_sync;
> >> static int input_stream_potentially_available = 0;
> >> static int ignore_unknown_streams = 0;
> >> static int copy_unknown_streams = 0;
> >> +static int recast_media = 0;
> >> static int find_stream_info = 1;
> >>
> >> static void uninit_options(OptionsContext *o)
> >> @@ -759,7 +760,7 @@ static const AVCodec *find_codec_or_die(const char
> >> *name, enum AVMediaType type,
> >> av_log(NULL, AV_LOG_FATAL, "Unknown %s '%s'\n", codec_string,
> >> name);
> >> exit_program(1);
> >> }
> >> -if (codec->type != type) {
> >> +if (codec->type != type && !recast_media) {
> >> av_log(NULL, AV_LOG_FATAL, "Invalid %s type '%s'\n",
> >> codec_string, name);
> >> exit_program(1);
> >> }
> >> @@ -774,6 +775,8 @@ static const AVCodec *choose_decoder(OptionsContext
> >> *o, AVFormatContext *s, AVSt
> >> if (codec_name) {
> >> const AVCodec *codec = find_codec_or_die(codec_name,
> >> st->codecpar->codec_type, 0);
> >> st->codecpar->codec_id = codec->id;
> >> +if (recast_media && st->codecpar->codec_type != codec->type)
> >> +st->codecpar->codec_type = codec->type;
> > The caller is not allowed to modify this struct for demuxing. This might
> > confuse demuxers that expect the values they put there to remain
>
> choose_decoder() is called from within add_input_streams().
>
> Near the end of this parent function, we have
>
> ret = avcodec_parameters_from_context(par, ist->dec_ctx);
>
> where par is
>
> AVCodecParameters *par = st->codecpar;
>
>
> avcodec_parameters_from_context(), starts with
> {
> codec_parameters_reset(par); --> sets codec_type to
> AVMEDIA_TYPE_UNKNOWN
>
> par->codec_type = codec->codec_type;
> ...
> }
>
> So it's already being done. I did an immediate recast to avoid some
> temporary variables as the media type is used in a few switch blocks
> after the decoder is set.
> But that way also works for me, if you insist.
Okay, I still consider this API abuse, but since it was there before it
is not your responsibility to fix it. Guess I'll add it to my todo list.
--
Anton Khirnov
___
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 v4] examples/decode_video: flush parser to fix missing frame
---
v4: break when error occured in fread, fix infinite loop introduced by v3
v3: check EOF by "eof = !data_size && feof(f);"
doc/examples/decode_video.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
index 18ee90a6c0..7238e38103 100644
--- a/doc/examples/decode_video.c
+++ b/doc/examples/decode_video.c
@@ -92,6 +92,7 @@ int main(int argc, char **argv)
uint8_t *data;
size_t data_size;
int ret;
+int eof;
AVPacket *pkt;
if (argc <= 2) {
@@ -150,15 +151,16 @@ int main(int argc, char **argv)
exit(1);
}
-while (!feof(f)) {
+do {
/* read raw data from the input file */
data_size = fread(inbuf, 1, INBUF_SIZE, f);
-if (!data_size)
+if (ferror(f))
break;
+eof = !data_size;
/* use the parser to split the data into frames */
data = inbuf;
-while (data_size > 0) {
+while (data_size > 0 || eof) {
ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
data, data_size, AV_NOPTS_VALUE,
AV_NOPTS_VALUE, 0);
if (ret < 0) {
@@ -170,8 +172,10 @@ int main(int argc, char **argv)
if (pkt->size)
decode(c, frame, pkt, outfilename);
+else if (eof)
+break;
}
-}
+} while (!eof);
/* flush the decoder */
decode(c, frame, NULL, outfilename);
--
2.31.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] avformat/libsrt: add mininputbw option
---
libavformat/libsrt.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 8dee6aa3f3..5113858d97 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -72,6 +72,9 @@ typedef struct SRTContext {
int ipttl;
int iptos;
int64_t inputbw;
+#if SRT_VERSION_VALUE >= 0x010403
+int64_t mininputbw;
+#endif
int oheadbw;
int64_t latency;
int tlpktdrop;
@@ -118,6 +121,9 @@ static const AVOption libsrt_options[] = {
{ "ipttl", "IP Time To Live",
OFFSET(ipttl),AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 255, .flags = D|E },
{ "iptos", "IP Type of Service",
OFFSET(iptos),AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 255, .flags = D|E },
{ "inputbw","Estimated input stream rate",
OFFSET(inputbw), AV_OPT_TYPE_INT64,{ .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
+#if SRT_VERSION_VALUE >= 0x010403
+{ "mininputbw", "Minimum value of the estimated input stream rate",
OFFSET(mininputbw), AV_OPT_TYPE_INT64,{ .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
+#endif
{ "oheadbw","MaxBW ceiling based on % over input stream rate",
OFFSET(oheadbw), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 100, .flags = D|E },
{ "latency","receiver delay (in microseconds) to absorb bursts of
missed packet retransmissions", OFFSET(latency),
AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
{ "tsbpddelay", "deprecated, same effect as latency option",
OFFSET(latency), AV_OPT_TYPE_INT64, { .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
@@ -297,6 +303,9 @@ static int libsrt_set_options_post(URLContext *h, int fd)
SRTContext *s = h->priv_data;
if ((s->inputbw >= 0 && libsrt_setsockopt(h, fd, SRTO_INPUTBW,
"SRTO_INPUTBW", &s->inputbw, sizeof(s->inputbw)) < 0) ||
+#if SRT_VERSION_VALUE >= 0x010403
+(s->mininputbw >= 0 && libsrt_setsockopt(h, fd, SRTO_MININPUTBW,
"SRTO_MININPUTBW", &s->mininputbw, sizeof(s->mininputbw)) < 0) ||
+#endif
(s->oheadbw >= 0 && libsrt_setsockopt(h, fd, SRTO_OHEADBW,
"SRTO_OHEADBW", &s->oheadbw, sizeof(s->oheadbw)) < 0)) {
return AVERROR(EIO);
}
@@ -560,6 +569,13 @@ static int libsrt_open(URLContext *h, const char *uri, int
flags)
if (av_find_info_tag(buf, sizeof(buf), "inputbw", p)) {
s->inputbw = strtoll(buf, NULL, 10);
}
+if (av_find_info_tag(buf, sizeof(buf), "mininputbw", p)) {
+#if SRT_VERSION_VALUE >= 0x010403
+s->mininputbw = strtoll(buf, NULL, 10);
+#else
+av_log(h, AV_LOG_WARNING, "mininputbw unsupported for libsrt
version %s\n", SRT_VERSION_STRING);
+#endif
+}
if (av_find_info_tag(buf, sizeof(buf), "oheadbw", p)) {
s->oheadbw = strtoll(buf, NULL, 10);
}
--
2.31.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 v4] examples/decode_video: flush parser to fix missing frame
---
v4: break when error occured in fread, fix infinite loop introduced by v3
v3: check EOF by "eof = !data_size && feof(f);"
doc/examples/decode_video.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
index 18ee90a6c0..7238e38103 100644
--- a/doc/examples/decode_video.c
+++ b/doc/examples/decode_video.c
@@ -92,6 +92,7 @@ int main(int argc, char **argv)
uint8_t *data;
size_t data_size;
int ret;
+int eof;
AVPacket *pkt;
if (argc <= 2) {
@@ -150,15 +151,16 @@ int main(int argc, char **argv)
exit(1);
}
-while (!feof(f)) {
+do {
/* read raw data from the input file */
data_size = fread(inbuf, 1, INBUF_SIZE, f);
-if (!data_size)
+if (ferror(f))
break;
+eof = !data_size;
/* use the parser to split the data into frames */
data = inbuf;
-while (data_size > 0) {
+while (data_size > 0 || eof) {
ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
data, data_size, AV_NOPTS_VALUE,
AV_NOPTS_VALUE, 0);
if (ret < 0) {
@@ -170,8 +172,10 @@ int main(int argc, char **argv)
if (pkt->size)
decode(c, frame, pkt, outfilename);
+else if (eof)
+break;
}
-}
+} while (!eof);
/* flush the decoder */
decode(c, frame, NULL, outfilename);
--
2.31.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 v4] examples/decode_video: flush parser to fix missing frame
---
v4: break when error occured in fread, fix infinite loop introduced by v3
v3: check EOF by "eof = !data_size && feof(f);"
doc/examples/decode_video.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
index 18ee90a6c0..7238e38103 100644
--- a/doc/examples/decode_video.c
+++ b/doc/examples/decode_video.c
@@ -92,6 +92,7 @@ int main(int argc, char **argv)
uint8_t *data;
size_t data_size;
int ret;
+int eof;
AVPacket *pkt;
if (argc <= 2) {
@@ -150,15 +151,16 @@ int main(int argc, char **argv)
exit(1);
}
-while (!feof(f)) {
+do {
/* read raw data from the input file */
data_size = fread(inbuf, 1, INBUF_SIZE, f);
-if (!data_size)
+if (ferror(f))
break;
+eof = !data_size;
/* use the parser to split the data into frames */
data = inbuf;
-while (data_size > 0) {
+while (data_size > 0 || eof) {
ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
data, data_size, AV_NOPTS_VALUE,
AV_NOPTS_VALUE, 0);
if (ret < 0) {
@@ -170,8 +172,10 @@ int main(int argc, char **argv)
if (pkt->size)
decode(c, frame, pkt, outfilename);
+else if (eof)
+break;
}
-}
+} while (!eof);
/* flush the decoder */
decode(c, frame, NULL, outfilename);
--
2.31.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 5/8] sws: add a new scaling API
Quoting Michael Niedermayer (2021-07-12 21:08:55) > On Mon, Jul 12, 2021 at 01:07:06PM +0200, Anton Khirnov wrote: > [...] > > diff --git a/libswscale/swscale.h b/libswscale/swscale.h > > index 50d6d46553..41eacd2dea 100644 > > --- a/libswscale/swscale.h > > +++ b/libswscale/swscale.h > > @@ -30,6 +30,7 @@ > > #include > > > > #include "libavutil/avutil.h" > > +#include "libavutil/frame.h" > > #include "libavutil/log.h" > > #include "libavutil/pixfmt.h" > > #include "version.h" > > @@ -218,6 +219,85 @@ int sws_scale(struct SwsContext *c, const uint8_t > > *const srcSlice[], > >const int srcStride[], int srcSliceY, int srcSliceH, > >uint8_t *const dst[], const int dstStride[]); > > > > +/** > > + * Scale source data from src and write the output to dst. > > + * > > + * This is merely a convenience wrapper around > > + * - sws_frame_start() > > + * - sws_send_slice(0, src->height) > > + * - sws_receive_slice(0, dst->height) > > + * - sws_frame_end() > > + * > > + * @param dst The destination frame. See documentation for > > sws_frame_start() for > > + *more details. > > + * @param src The source frame. > > + * > > + * @return 0 on success, a negative AVERROR code on failure > > + */ > > +int sws_scale_frame(struct SwsContext *c, AVFrame *dst, const AVFrame > > *src); > > + > > +/** > > + * Initialize the scaling process for a given pair of source/destination > > frames. > > + * Must be called before any calls to sws_send_slice() and > > sws_receive_slice(). > > + * > > + * This function will retain references to src and dst. > > + * > > + * @param dst The destination frame. > > + * > > + *The data buffers may either be already allocated by the > > caller or > > + *left clear, in which case they will be allocated by the > > scaler. > > + *The latter may have performance advantages - e.g. in certain > > cases > > + *some output planes may be references to input planes, rather > > than > > + *copies. > > + * > > + *Output data will be written into this frame in successful > > + *sws_receive_slice() calls. > > + * @param src The source frame. The data buffers must be allocated, but the > > + *frame data does not have to be ready at this point. Data > > + *availability is then signalled by sws_send_slice(). > > + * @return 0 on success, a negative AVERROR code on failure > > + * > > + * @see sws_frame_end() > > + */ > > +int sws_frame_start(struct SwsContext *c, AVFrame *dst, const AVFrame > > *src); > > + > > +/** > > + * Finish the scaling process for a pair of source/destination frames > > previously > > + * submitted with sws_frame_start(). Must be called after all > > sws_send_slice() > > + * and sws_receive_slice() calls are done, before any new sws_frame_start() > > + * calls. > > + */ > > +void sws_frame_end(struct SwsContext *c); > > + > > > +/** > > + * Indicate that a horizontal slice of input data is available in the > > source > > + * frame previously provided to sws_frame_start(). The slices may be > > provided in > > + * any order, but may not overlap. For vertically subsampled pixel > > formats, the > > + * slices must be aligned according to subsampling. > > + * > > + * @param slice_start first row of the slice > > + * @param slice_height number of rows in the slice > > + * > > + * @return 0 on success, a negative AVERROR code on failure. > > + */ > > +int sws_send_slice(struct SwsContext *c, unsigned int slice_start, > > + unsigned int slice_height); > > I suggest to use non 0 on success. Outright >0, or >= 0? > That could then be extended in the future for example to provide information > about how many lines have already been consumed and its memory be reused I will amend the patch. Are you satisfied with the API otherwise? -- Anton Khirnov ___ 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 v4] examples/decode_video: flush parser to fix missing frame
---
v4: break when error occured in fread, fix infinite loop introduced by v3
v3: check EOF by "eof = !data_size && feof(f);"
doc/examples/decode_video.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
index 18ee90a6c0..7238e38103 100644
--- a/doc/examples/decode_video.c
+++ b/doc/examples/decode_video.c
@@ -92,6 +92,7 @@ int main(int argc, char **argv)
uint8_t *data;
size_t data_size;
int ret;
+int eof;
AVPacket *pkt;
if (argc <= 2) {
@@ -150,15 +151,16 @@ int main(int argc, char **argv)
exit(1);
}
-while (!feof(f)) {
+do {
/* read raw data from the input file */
data_size = fread(inbuf, 1, INBUF_SIZE, f);
-if (!data_size)
+if (ferror(f))
break;
+eof = !data_size;
/* use the parser to split the data into frames */
data = inbuf;
-while (data_size > 0) {
+while (data_size > 0 || eof) {
ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
data, data_size, AV_NOPTS_VALUE,
AV_NOPTS_VALUE, 0);
if (ret < 0) {
@@ -170,8 +172,10 @@ int main(int argc, char **argv)
if (pkt->size)
decode(c, frame, pkt, outfilename);
+else if (eof)
+break;
}
-}
+} while (!eof);
/* flush the decoder */
decode(c, frame, NULL, outfilename);
--
2.31.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] avpacket: ABI bump additions
Quoting Lynne (2021-07-09 04:42:07) > > I can change the patch to either initialize it as an invalid value (which > would > signal the user to instead get the timebase elsewhere) or set its value > when the packet passes through the common demuxing function. > Having this field in does not imply it's used during muxing at all, and in > fact > makes it easier to figure out how to properly mux since we can add the info > to the comment (which we will have to, regardless of how we decide to > implement > the automatic method for timestamp rescaling, if we ever do decide to). I am generally in favor of having the timebase in the packets, but there are tricky compatibility issues to consider. E.g. consider a case where a user: 1 reads packets from an encoder 2 rescales them to the muxer timebase manually 3 submits them to the muxer If we change encoders to set packet timebase and the muxers to honor it, then step 2 above will break. There are some ways around it (e.g. adding honor_packet_tb options to each component that deals with AVPackets, then gradually making them on by default, then removing the options), but it's a long game. -- Anton Khirnov ___ 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/libsrt: add mininputbw option
On 2021-07-14 13:23, Zhao Zhili wrote:
---
libavformat/libsrt.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 8dee6aa3f3..5113858d97 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -72,6 +72,9 @@ typedef struct SRTContext {
int ipttl;
int iptos;
int64_t inputbw;
+#if SRT_VERSION_VALUE >= 0x010403
+int64_t mininputbw;
+#endif
int oheadbw;
int64_t latency;
int tlpktdrop;
@@ -118,6 +121,9 @@ static const AVOption libsrt_options[] = {
{ "ipttl", "IP Time To Live",
OFFSET(ipttl),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255,
.flags = D|E },
{ "iptos", "IP Type of Service",
OFFSET(iptos),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255,
.flags = D|E },
{ "inputbw","Estimated input stream rate",
OFFSET(inputbw), AV_OPT_TYPE_INT64,{ .i64 = -1 }, -1, INT64_MAX,
.flags = D|E },
+#if SRT_VERSION_VALUE >= 0x010403
+{ "mininputbw", "Minimum value of the estimated input stream rate",
OFFSET(mininputbw), AV_OPT_TYPE_INT64,{ .i64 = -1 }, -1, INT64_MAX,
.flags = D|E },
+#endif
{ "oheadbw","MaxBW ceiling based on % over input stream rate",
OFFSET(oheadbw), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 100,
.flags = D|E },
{ "latency","receiver delay (in microseconds) to absorb bursts of
missed packet retransmissions", OFFSET(latency),
AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
{ "tsbpddelay", "deprecated, same effect as latency option",
OFFSET(latency), AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, .flags
= D|E },
@@ -297,6 +303,9 @@ static int libsrt_set_options_post(URLContext *h, int fd)
SRTContext *s = h->priv_data;
if ((s->inputbw >= 0 && libsrt_setsockopt(h, fd, SRTO_INPUTBW, "SRTO_INPUTBW", &s->inputbw, sizeof(s->inputbw)) < 0) ||
+#if SRT_VERSION_VALUE >= 0x010403
+(s->mininputbw >= 0 && libsrt_setsockopt(h, fd, SRTO_MININPUTBW, "SRTO_MININPUTBW",
&s->mininputbw, sizeof(s->mininputbw)) < 0) ||
+#endif
(s->oheadbw >= 0 && libsrt_setsockopt(h, fd, SRTO_OHEADBW, "SRTO_OHEADBW",
&s->oheadbw, sizeof(s->oheadbw)) < 0)) {
return AVERROR(EIO);
}
@@ -560,6 +569,13 @@ static int libsrt_open(URLContext *h, const char *uri, int
flags)
if (av_find_info_tag(buf, sizeof(buf), "inputbw", p)) {
s->inputbw = strtoll(buf, NULL, 10);
}
+if (av_find_info_tag(buf, sizeof(buf), "mininputbw", p)) {
+#if SRT_VERSION_VALUE >= 0x010403
+s->mininputbw = strtoll(buf, NULL, 10);
+#else
+av_log(h, AV_LOG_WARNING, "mininputbw unsupported for libsrt version
%s\n", SRT_VERSION_STRING);
+#endif
+}
if (av_find_info_tag(buf, sizeof(buf), "oheadbw", p)) {
s->oheadbw = strtoll(buf, NULL, 10);
}
Update doc/protocols.texi as well.
Regards,
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] lavd/lavfi.c: Set time_base for 608 cc to container time_base.
Quoting Thilo Borgmann (2021-06-28 15:12:11)
> Hi,
>
> > when transcoding 608 cc, the cc stream frame pts is set to the same value
> > as its container frame's pts. However, the time_base is always set to
> > 1/9 (default) in the initialization stage. Which causes timing issues
> > when the container time_base is actually not 1/9.
>
> identical v2 attached that also includes updates to the FATE references
> affected by the patch (and failed with patchwork of course).
>
> -Thilo
>
> From 41b619e5d5083ca59a41cca9cb515190939d6573 Mon Sep 17 00:00:00 2001
> From: Yun Zhang
> Date: Mon, 28 Jun 2021 15:09:42 +0200
> Subject: [PATCH] lavd/lavfi.c: Set time_base for 608 cc to container
> time_base.
>
> Suggested-By: ffm...@fb.com
> ---
> libavdevice/lavfi.c| 3 +++
> tests/ref/fate/sub-cc | 4 ++--
> tests/ref/fate/sub-cc-realtime | 38 +++---
> 3 files changed, 13 insertions(+), 32 deletions(-)
>
> diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
> index 57d977e7ce..e07f20c872 100644
> --- a/libavdevice/lavfi.c
> +++ b/libavdevice/lavfi.c
> @@ -100,6 +100,7 @@ static int create_subcc_streams(AVFormatContext *avctx)
> LavfiContext *lavfi = avctx->priv_data;
> AVStream *st;
> int stream_idx, sink_idx;
> +AVRational *time_base;
>
> for (stream_idx = 0; stream_idx < lavfi->nb_sinks; stream_idx++) {
> sink_idx = lavfi->stream_sink_map[stream_idx];
> @@ -109,6 +110,8 @@ static int create_subcc_streams(AVFormatContext *avctx)
> return AVERROR(ENOMEM);
> st->codecpar->codec_id = AV_CODEC_ID_EIA_608;
> st->codecpar->codec_type = AVMEDIA_TYPE_SUBTITLE;
> +time_base = &avctx->streams[stream_idx]->time_base;
> +avpriv_set_pts_info(st, 64, time_base->num, time_base->den);
This look like an unnecessariily complicated way to write
st->time_base.{num,den}
--
Anton Khirnov
___
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] ffmpeg: add option recast_media
On 7/13/2021 6:12 AM, Gyan Doshi wrote:
On 2021-07-13 13:14, Anton Khirnov wrote:
Quoting Gyan Doshi (2021-07-02 12:03:05)
Allows forcing decoders of different media type.
Needed to decode media data muxed as data streams.
---
doc/ffmpeg.texi | 5 +
fftools/ffmpeg_opt.c | 7 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7827291755..c1065086e5 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -449,6 +449,11 @@ output file already exists.
Set number of times input stream shall be looped. Loop 0 means no
loop,
loop -1 means infinite loop.
+@item -recast_media (@emph{global})
+Enable to allow forcing a decoder of a different media type than
+the one detected or designated by the demuxer. Useful for decoding
+media data muxed as data streams.
+
@item -c[:@var{stream_specifier}] @var{codec}
(@emph{input/output,per-stream})
@itemx -codec[:@var{stream_specifier}] @var{codec}
(@emph{input/output,per-stream})
Select an encoder (when used before an output file) or a decoder
(when used
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index a63bed54cf..76a220c21c 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -186,6 +186,7 @@ static int input_sync;
static int input_stream_potentially_available = 0;
static int ignore_unknown_streams = 0;
static int copy_unknown_streams = 0;
+static int recast_media = 0;
static int find_stream_info = 1;
static void uninit_options(OptionsContext *o)
@@ -759,7 +760,7 @@ static const AVCodec *find_codec_or_die(const
char *name, enum AVMediaType type,
av_log(NULL, AV_LOG_FATAL, "Unknown %s '%s'\n",
codec_string, name);
exit_program(1);
}
- if (codec->type != type) {
+ if (codec->type != type && !recast_media) {
av_log(NULL, AV_LOG_FATAL, "Invalid %s type '%s'\n",
codec_string, name);
exit_program(1);
}
@@ -774,6 +775,8 @@ static const AVCodec
*choose_decoder(OptionsContext *o, AVFormatContext *s, AVSt
if (codec_name) {
const AVCodec *codec = find_codec_or_die(codec_name,
st->codecpar->codec_type, 0);
st->codecpar->codec_id = codec->id;
+ if (recast_media && st->codecpar->codec_type != codec->type)
+ st->codecpar->codec_type = codec->type;
The caller is not allowed to modify this struct for demuxing. This might
confuse demuxers that expect the values they put there to remain
choose_decoder() is called from within add_input_streams().
Near the end of this parent function, we have
ret = avcodec_parameters_from_context(par, ist->dec_ctx);
where par is
AVCodecParameters *par = st->codecpar;
avcodec_parameters_from_context(), starts with
{
codec_parameters_reset(par); --> sets codec_type to
AVMEDIA_TYPE_UNKNOWN
par->codec_type = codec->codec_type;
...
}
ist->dec_ctx is initialized as a copy of par, and its codec_type is
never changed.
In fact, for video, copying back to par doesn't seem needed to begin
with. And it could be looked how to remove it for audio and subtitles,
where channel_layout and dimensions respectively may be changed.
So it's already being done. I did an immediate recast to avoid some
temporary variables as the media type is used in a few switch blocks
after the decoder is set.
But that way also works for me, if you insist.
Regards,
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 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] avpacket: ABI bump additions
13 Jul 2021, 20:16 by an...@khirnov.net: > Quoting Lynne (2021-07-09 04:42:07) > >> >> I can change the patch to either initialize it as an invalid value (which >> would >> signal the user to instead get the timebase elsewhere) or set its value >> when the packet passes through the common demuxing function. >> Having this field in does not imply it's used during muxing at all, and in >> fact >> makes it easier to figure out how to properly mux since we can add the info >> to the comment (which we will have to, regardless of how we decide to >> implement >> the automatic method for timestamp rescaling, if we ever do decide to). >> > > I am generally in favor of having the timebase in the packets, but there > are tricky compatibility issues to consider. > > E.g. consider a case where a user: > 1 reads packets from an encoder > 2 rescales them to the muxer timebase manually > 3 submits them to the muxer > > If we change encoders to set packet timebase and the muxers to honor it, > then step 2 above will break. There are some ways around it (e.g. adding > honor_packet_tb options to each component that deals with AVPackets, > then gradually making them on by default, then removing the options), > but it's a long game. > We discussed this back in February, and I'm going for the long game, with a flag instead of an option. The flag won't be removed, there should still be an option for API users to not have our code touch timestamps. It'll just be made the default at some later bump, with a new flag introduced to restore old behaviour. ___ 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/2] avfilter/af_astats: Only print header lines when values are to be printed
On 08.04.2021 08:41, Tobias Rapp wrote: On 07.04.2021 19:25, Paul B Mahol wrote: Please ask someone else to apply it. I can technically commit the patches but would prefer if some second pair of eyes could take a look. So will apply them in a week from now if nobody objects. Applied this first part of the patch-set as it seemed non-controversial. Regards, Tobias ___ 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/2] mov: Pick up "com.apple.quicktime.artwork" as cover art
On 4/1/2021 12:51 PM, Martin Storsjö wrote: > --- > libavformat/mov.c | 22 -- > 1 file changed, 12 insertions(+), 10 deletions(-) OK. I would just push in the future after waiting so long. - Derek ___ 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] ffmpeg: add option recast_media
On 2021-07-14 00:35, James Almer wrote:
On 7/13/2021 6:12 AM, Gyan Doshi wrote:
On 2021-07-13 13:14, Anton Khirnov wrote:
Quoting Gyan Doshi (2021-07-02 12:03:05)
Allows forcing decoders of different media type.
Needed to decode media data muxed as data streams.
---
doc/ffmpeg.texi | 5 +
fftools/ffmpeg_opt.c | 7 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7827291755..c1065086e5 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -449,6 +449,11 @@ output file already exists.
Set number of times input stream shall be looped. Loop 0 means no
loop,
loop -1 means infinite loop.
+@item -recast_media (@emph{global})
+Enable to allow forcing a decoder of a different media type than
+the one detected or designated by the demuxer. Useful for decoding
+media data muxed as data streams.
+
@item -c[:@var{stream_specifier}] @var{codec}
(@emph{input/output,per-stream})
@itemx -codec[:@var{stream_specifier}] @var{codec}
(@emph{input/output,per-stream})
Select an encoder (when used before an output file) or a decoder
(when used
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index a63bed54cf..76a220c21c 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -186,6 +186,7 @@ static int input_sync;
static int input_stream_potentially_available = 0;
static int ignore_unknown_streams = 0;
static int copy_unknown_streams = 0;
+static int recast_media = 0;
static int find_stream_info = 1;
static void uninit_options(OptionsContext *o)
@@ -759,7 +760,7 @@ static const AVCodec *find_codec_or_die(const
char *name, enum AVMediaType type,
av_log(NULL, AV_LOG_FATAL, "Unknown %s '%s'\n",
codec_string, name);
exit_program(1);
}
- if (codec->type != type) {
+ if (codec->type != type && !recast_media) {
av_log(NULL, AV_LOG_FATAL, "Invalid %s type '%s'\n",
codec_string, name);
exit_program(1);
}
@@ -774,6 +775,8 @@ static const AVCodec
*choose_decoder(OptionsContext *o, AVFormatContext *s, AVSt
if (codec_name) {
const AVCodec *codec = find_codec_or_die(codec_name,
st->codecpar->codec_type, 0);
st->codecpar->codec_id = codec->id;
+ if (recast_media && st->codecpar->codec_type != codec->type)
+ st->codecpar->codec_type = codec->type;
The caller is not allowed to modify this struct for demuxing. This
might
confuse demuxers that expect the values they put there to remain
choose_decoder() is called from within add_input_streams().
Near the end of this parent function, we have
ret = avcodec_parameters_from_context(par, ist->dec_ctx);
where par is
AVCodecParameters *par = st->codecpar;
avcodec_parameters_from_context(), starts with
{
codec_parameters_reset(par); --> sets codec_type to
AVMEDIA_TYPE_UNKNOWN
par->codec_type = codec->codec_type;
...
}
ist->dec_ctx is initialized as a copy of par, and its codec_type is
never changed.
In fact, for video, copying back to par doesn't seem needed to begin
with. And it could be looked how to remove it for audio and subtitles,
where channel_layout and dimensions respectively may be changed.
Well, the underlying point is that the info available to the demuxer may
be wrong and/or incomplete.
Whatever sanitary correction is made here, fftools should be free to
apply automatic or user-requested adjustment for onward processing.
Unless it's easier to make allowances inside lavf.
Regards,
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 v2] avformat/libsrt: add mininputbw option
---
v2: add doc
It's useful when tlpktdrop=0&maxbw=0 and network bandwidth is smaller
than input stream rate. Without this option, the estimated input rate
can drop to near zero.
https://github.com/Haivision/srt/issues/2057
doc/protocols.texi | 4
libavformat/libsrt.c | 16
2 files changed, 20 insertions(+)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 726e5f1c44..f431c15fe4 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1414,6 +1414,10 @@ if @option{inputbw} is not set while @option{maxbw} is
set to
relative (0), the actual input rate is evaluated inside
the library. Default value is 0.
+@item mininputbw=@var{bytes/seconds}
+This option is effective only if both @option{maxbw} and @option{inputbw}
+are set to 0. It's the minimum value of the estimated input stream rate.
+
@item iptos=@var{tos}
IP Type of Service. Applies to sender only. Default value is 0xB8.
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 8dee6aa3f3..5113858d97 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -72,6 +72,9 @@ typedef struct SRTContext {
int ipttl;
int iptos;
int64_t inputbw;
+#if SRT_VERSION_VALUE >= 0x010403
+int64_t mininputbw;
+#endif
int oheadbw;
int64_t latency;
int tlpktdrop;
@@ -118,6 +121,9 @@ static const AVOption libsrt_options[] = {
{ "ipttl", "IP Time To Live",
OFFSET(ipttl),AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 255, .flags = D|E },
{ "iptos", "IP Type of Service",
OFFSET(iptos),AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 255, .flags = D|E },
{ "inputbw","Estimated input stream rate",
OFFSET(inputbw), AV_OPT_TYPE_INT64,{ .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
+#if SRT_VERSION_VALUE >= 0x010403
+{ "mininputbw", "Minimum value of the estimated input stream rate",
OFFSET(mininputbw), AV_OPT_TYPE_INT64,{ .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
+#endif
{ "oheadbw","MaxBW ceiling based on % over input stream rate",
OFFSET(oheadbw), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 100, .flags = D|E },
{ "latency","receiver delay (in microseconds) to absorb bursts of
missed packet retransmissions", OFFSET(latency),
AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
{ "tsbpddelay", "deprecated, same effect as latency option",
OFFSET(latency), AV_OPT_TYPE_INT64, { .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
@@ -297,6 +303,9 @@ static int libsrt_set_options_post(URLContext *h, int fd)
SRTContext *s = h->priv_data;
if ((s->inputbw >= 0 && libsrt_setsockopt(h, fd, SRTO_INPUTBW,
"SRTO_INPUTBW", &s->inputbw, sizeof(s->inputbw)) < 0) ||
+#if SRT_VERSION_VALUE >= 0x010403
+(s->mininputbw >= 0 && libsrt_setsockopt(h, fd, SRTO_MININPUTBW,
"SRTO_MININPUTBW", &s->mininputbw, sizeof(s->mininputbw)) < 0) ||
+#endif
(s->oheadbw >= 0 && libsrt_setsockopt(h, fd, SRTO_OHEADBW,
"SRTO_OHEADBW", &s->oheadbw, sizeof(s->oheadbw)) < 0)) {
return AVERROR(EIO);
}
@@ -560,6 +569,13 @@ static int libsrt_open(URLContext *h, const char *uri, int
flags)
if (av_find_info_tag(buf, sizeof(buf), "inputbw", p)) {
s->inputbw = strtoll(buf, NULL, 10);
}
+if (av_find_info_tag(buf, sizeof(buf), "mininputbw", p)) {
+#if SRT_VERSION_VALUE >= 0x010403
+s->mininputbw = strtoll(buf, NULL, 10);
+#else
+av_log(h, AV_LOG_WARNING, "mininputbw unsupported for libsrt
version %s\n", SRT_VERSION_STRING);
+#endif
+}
if (av_find_info_tag(buf, sizeof(buf), "oheadbw", p)) {
s->oheadbw = strtoll(buf, NULL, 10);
}
--
2.31.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] avcodec/h264_parser: remove key frame tagging heuristics
On 7/13/2021 9:28 AM, Anton Khirnov wrote: > Seems we need a better definition of what "keyframe" means in our APIs. Not one, but many. That there is a single notion of a "keyframe" is wrong in itself. - Derek ___ 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/h264_parser: remove key frame tagging heuristics
On 7/13/2021 1:22 AM, James Almer wrote: > Because it isn't something that should be marked as a keyframe as coded > bitstream in any kind of container, like it's the case of mp4 sync samples. It *is* something that should be specifically marked in MP4, though, which does vhae proper facilities for this stuff. The problem is our API has no concept of RAPs other than "is an IDR". Proper way to write e.g. intra-refresh streams is: * Write the 'sdtp' box. * Write the 'sgpd' and 'sbgp' boxes with a 'roll' sample grouping type and roll_distance properly set. Annex I of the MP4 spec is quite clear how all types of recover and sync points should be written. - Derek ___ 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 Delay
Is there an issue with the mailing list over the past couple of days? I've just received multiple messages over 12 hours old. And there have been no new messages in ffmpeg-user since the 12th, although that list is low traffic anyway. 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 v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: On Tue, Nov 3, 2020 at 7:47 PM Artem Galin wrote: Adding DX11 relevant device type checks and adjusting callbacks with proper MediaSDK pair type support. Extending structure for proper MediaSDK pair type support. Signed-off-by: Artem Galin . Patchset obviously closes the gap of DirectX 11 support and already checked with several apps that use FFMPEG. Any particular review comments should be yet expected? Changes seem to be straight forward and incorporate prev. comments. thank in advance regards Max There are some issues pointed out by Soft Works related to switching the default to DX11 breaking existing command lines with DX9, plus an OpenCL<->QSV interop regression this would introduce that according to him should be easy to fix. If those are addressed, the set should be good. ___ 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] Mailing List Delay
Gyan Doshi (12021-07-14): > Is there an issue with the mailing list over the past couple of days? > I've just received multiple messages over 12 hours old. Looking at the headers, it looks like the delay happens at Google before the mail arrives to the mailing-list. Yours arrived quickly. Mine will too, I guess. 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] [PATCH] avcodec/h264_parser: remove key frame tagging heuristics
On 7/12/2021 11:44 PM, Kieran Kunhya wrote: On Tue, 13 Jul 2021, 02:45 James Almer, wrote: On 7/12/2021 10:01 PM, Kieran Kunhya wrote: Because it isn't something that should be marked as a keyframe as coded bitstream in any kind of container, like it's the case of mp4 sync samples. MPEG-TS Random Access Indicator expects keyframes to be signalled like this. With intra-refresh and this code removed, there will be no random access points at all. If MPEG-TS wants to tag packets containing things other than IDR access units as RAPs, then it should analyze the bitstream itself in order to tag them itself as such in the output. This parser as is is generating invalid output for other containers that are strict about key frames, and signal recovery points (like those indicated by the use of this SEI) by other means. Why not just detect IDR in containers that only care about that (which is a mistake because if things like open gop)? Doing that's is relatively simple compared to adding bitstream parsing into MPEGTS. Both would require bitstream parsing in a muxer to look at what pictures are present within the AU in the packet, so I'm inclined to do it for the muxer that wants to tag more things than normal as keyframes instead of in every other muxer. I will keep tagging these packets as keyframes in the parser but behind a new flag that's disabled by default, then insert an internal instance of the parser to mpegtsenc with said flag enabled, and use that to mark mpegts RAPs. This has the added benefit of marking these packets as RAPs in mpegts on codec copy scenarios when the source is an mp4 or mkv and the generic code never uses an AVParser. Kieran ___ 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 1/2] mov: Pick up "com.apple.quicktime.artwork" as cover art
On Tue, 13 Jul 2021, Derek Buitenhuis wrote: On 4/1/2021 12:51 PM, Martin Storsjö wrote: --- libavformat/mov.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) OK. Thanks I would just push in the future after waiting so long. Sure, although in particular for patch 2/2 I kinda wanted someone else to doublecheck my reasoning... (I don't see a reply to that one although it might be stuck in mailing list delays.) // Martin ___ 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] mov: Don't export unknown/unhandled metadata types as if they were UTF8
On 4/1/2021 12:51 PM, Martin Storsjö wrote:
> +} else if (data_type > 1 && data_type != 4) {
> +// data_type can be 0 if not set at all above. data_type 1 means
> +// UTF8 and 4 means "UTF8 sort". For any other type (UTF16 or
> e.g.
> +// a picture), don't return it blindly in a string that is
> supposed
> +// to be UTF8 text.
> +av_log(c->fc, AV_LOG_WARNING, "Skipping unhandled metadata %s of
> type %d\n", key, data_type);
> +av_free(str);
> +return 0;
Should we add any UTF-8 validation on our end too?
- Derek
___
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] mov: Don't export unknown/unhandled metadata types as if they were UTF8
On Tue, 13 Jul 2021, Derek Buitenhuis wrote:
On 4/1/2021 12:51 PM, Martin Storsjö wrote:
+} else if (data_type > 1 && data_type != 4) {
+// data_type can be 0 if not set at all above. data_type 1 means
+// UTF8 and 4 means "UTF8 sort". For any other type (UTF16 or e.g.
+// a picture), don't return it blindly in a string that is supposed
+// to be UTF8 text.
+av_log(c->fc, AV_LOG_WARNING, "Skipping unhandled metadata %s of type
%d\n", key, data_type);
+av_free(str);
+return 0;
Should we add any UTF-8 validation on our end too?
(Ah, here the reply arrived from yesterday)
I guess we could - but I see that as a separate thing to do which could be
applied everywhere where we export metadata.
Here we have a flag that clearly identifies what kind of data it is
(although we only recognize some of them), and if a type is set, which
isn't utf8, we at least should bail out there.
For reference for myself and others, the types are defined here:
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/Metadata/Metadata.html#//apple_ref/doc/uid/TP4939-CH1-SW35
So 0 would mean unset/unknown/whatever, where we keep doing what we did
before. But for other values, like utf16, various endian integers, bmps,
whatever, just bail out.
// Martin
___
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] libavcodec/libx265: add user data unregistered SEI encoding
On 7/12/2021 9:24 AM, Brad Hards wrote: > MISB ST 0604 and ST 2101 require user data unregistered SEI messages > (precision timestamps and sensor identifiers) to be included. That > currently isn't supported for libx265. This patch adds support > for user data unregistered SEI messages in accordance with > ISO/IEC 23008-2:2020 Section D.2.7 > > The design is based on nvenc, with support finished up at > 57de80673cb > --- > libavcodec/libx265.c | 33 + > 1 file changed, 33 insertions(+) Should be OK. - Derek ___ 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] Mailing List Delay
On 7/14/2021 12:27 PM, Nicolas George wrote: > Looking at the headers, it looks like the delay happens at Google before > the mail arrives to the mailing-list. > > Yours arrived quickly. Mine will too, I guess. Sending from GMail, I have had anywhere from instantly, to 1.5 hours delay ever since moving to the "new" (Hungarian?) mailing list host. Especially when sending via git-send-email. I have been bringing this up consstently for years, and been told it's a "non-issue", but it is incredibly annoying. I am not sure if it's due to Google having issues (trust?) sending to out host, or the host having trouble receiving. I have also noticed, since switching to this 'new' mysertious mailing list host a few years back that a chunk of ffmpeg-devel traffic gets filed into spam consistently. Also very annoying - I have missed several patches this way. This is not specific to GMail, for me, so far. If it's a trust thing, sure, we can blame Google or whoever, but I think we should have a less cruddy experience for users of the largest email provider in the world, by default, rather just shrugging and saying "sucks to be you, don't use GMail". - Derek ___ 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] mov: Don't export unknown/unhandled metadata types as if they were UTF8
On 7/14/2021 1:32 PM, Martin Storsjö wrote: > I guess we could - but I see that as a separate thing to do which could be > applied everywhere where we export metadata. Yeah, true... we should probably have it in som upper/middle layer that checks all string-type exports or something. Patch should be OK. - Derek ___ 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] Mailing List Delay
Derek Buitenhuis (12021-07-14): > Sending from GMail, I have had anywhere from instantly, to 1.5 hours delay > ever since moving to the "new" (Hungarian?) mailing list host. Especially > when sending via git-send-email. > > I have been bringing this up consstently for years, and been told it's > a "non-issue", but it is incredibly annoying. The issue we discussed here only happened since yesterday, and apparently stopped happening. So it's not the same issue. > I am not sure if it's due to Google having issues (trust?) sending to > out host, or the host having trouble receiving. The headers in the transmitted mails should give some indication. 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] Mailing List Delay
On 7/14/2021 10:17 AM, Derek Buitenhuis wrote: On 7/14/2021 12:27 PM, Nicolas George wrote: Looking at the headers, it looks like the delay happens at Google before the mail arrives to the mailing-list. Yours arrived quickly. Mine will too, I guess. Sending from GMail, I have had anywhere from instantly, to 1.5 hours delay ever since moving to the "new" (Hungarian?) mailing list host. Especially when sending via git-send-email. I have been bringing this up consstently for years, and been told it's a "non-issue", but it is incredibly annoying. I am not sure if it's due to Google having issues (trust?) sending to out host, or the host having trouble receiving. I have also noticed, since switching to this 'new' mysertious mailing list host a few years back that a chunk of ffmpeg-devel traffic gets filed into spam consistently. Also very annoying - I have missed several patches this way. This is not specific to GMail, for me, so far. If it's a trust thing, sure, we can blame Google or whoever, but I think we should have a less cruddy experience for users of the largest email provider in the world, by default, rather just shrugging and saying "sucks to be you, don't use GMail". - Derek I'm mainly worried that yesterday was the second time in a month that the mail server apparently crashed and had to be restarted. No email seems to have been lost because of it, but it was an entire day in which nothing was sent. ___ 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] Mailing List Delay
On 7/14/2021 2:24 PM, Nicolas George wrote: > The issue we discussed here only happened since yesterday, and > apparently stopped happening. > > So it's not the same issue. Yeah, I know, but it seemed to be a good time to bring this up yet again. Sorry if that was unclear. >> I am not sure if it's due to Google having issues (trust?) sending to >> out host, or the host having trouble receiving. > > The headers in the transmitted mails should give some indication. Looking at a set of 3 patches I sent with git-send-email that had this issues, the mbox headers from patchwork show: * https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210220185050.508373-2-derek.buitenh...@gmail.com/ * Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id E4DB644ABCA for ; Sat, 20 Feb 2021 21:47:10 +0200 (EET) * Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ACBCC68A72F; Sat, 20 Feb 2021 21:47:10 +0200 (EET) * https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210220185050.508373-3-derek.buitenh...@gmail.com/ * Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id C722644A0BF for ; Sat, 20 Feb 2021 20:58:00 +0200 (EET) * Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A9B3D68A67C; Sat, 20 Feb 2021 20:58:00 +0200 (EET) * https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210220192355.509497-1-derek.buitenh...@gmail.com/ * Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id D029744A933 for ; Sat, 20 Feb 2021 21:24:12 +0200 (EET) * Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AA7D468A78A; Sat, 20 Feb 2021 21:24:12 +0200 (EET) These were sent as a single chain all at once, via git-send-email, but the received tim are wildly different. - Derek ___ 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] Mailing List Delay
On 7/14/2021 2:35 PM, ffmpegandmahanstreamer@lolcow.email wrote: >> I have been bringing this up consstently for years, and been told it's >> a "non-issue", but it is incredibly annoying. >> >> I am not sure if it's due to Google having issues (trust?) sending to >> out host, or the host having trouble receiving. >> > That's why i use this email provider and not my main Gmail for mailing > lists. Saying "don't use the largest email provider in the world because our list is janky" isn't a goo solution. > > It may be a good stopgap solution for some. > >> I have also noticed, since switching to this 'new' mysertious mailing >> list host a few years back that a chunk of ffmpeg-devel traffic gets >> filed into spam consistently. Also very annoying - I have missed >> several >> patches this way. This is not specific to GMail, for me, so far. >> > > That's because mail from "unknown" hosts might get into spam frequently. > You may have to explicitly whitelist the mailing list in your settings. Also not really an acceptable solution to tell every single person this, in my opinion. - Derek ___ 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] Mailing List Delay
On 7/14/2021 2:41 PM, Derek Buitenhuis wrote: > These were sent as a single chain all at once, via git-send-email, but the > received tim are wildly different. Apologies, ignore the third link - it was a 2 patch set. My mistake. The first two are enough to demonstrate the issue though. - Derek ___ 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/2] Fix double write of DASH manifest in streaming mode
Any feedback on this?
On Jun 24, 2021, 8:58 AM -0400, Kevin LaFlamme , wrote:
> When streaming mode is enabled, the DASH manifest is written on the
> first packet for the segment so that the segment can be advertised
> immediately to clients. It was also still writing the manifest at the
> end of the segment leading to two duplicate writes.
> ---
> libavformat/dashenc.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index e7a4a3d9e1..2b8fbcbe6e 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -2030,7 +2030,10 @@ static int dash_flush(AVFormatContext *s, int final,
> int stream)
>
> c->nr_of_streams_flushed = 0;
> }
> - ret = write_manifest(s, final);
> + // In streaming mode the manifest is written at the beginning
> + // of the segment instead
> + if (!c->streaming || final)
> + ret = write_manifest(s, final);
> }
> return ret;
> }
> @@ -2261,7 +2264,7 @@ static int dash_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> // in streaming mode, the segments are available for playing
> // before fully written but the manifest is needed so that
> // clients and discover the segment filenames.
> - if (c->streaming && os->segment_type == SEGMENT_TYPE_MP4) {
> + if (c->streaming) {
> write_manifest(s, 0);
> }
>
> --
> 2.31.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 2/3] avformat/mpegtsenc: use an AVParser for h264 streams
Use it to enable keyframe tagging heuristics to mark as many RAPs as possible.
Signed-off-by: James Almer
---
configure | 2 +-
libavformat/mpegtsenc.c | 45 +
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 2d2d125fd3..bbf0283a67 100755
--- a/configure
+++ b/configure
@@ -3378,7 +3378,7 @@ mp3_demuxer_select="mpegaudio_parser"
mp3_muxer_select="mpegaudioheader"
mp4_muxer_select="mov_muxer"
mpegts_demuxer_select="iso_media"
-mpegts_muxer_select="ac3_parser adts_muxer latm_muxer h264_mp4toannexb_bsf
hevc_mp4toannexb_bsf"
+mpegts_muxer_select="ac3_parser adts_muxer latm_muxer h264_parser
h264_mp4toannexb_bsf hevc_mp4toannexb_bsf"
mpegtsraw_demuxer_select="mpegts_demuxer"
mxf_muxer_select="golomb pcm_rechunk_bsf"
mxf_d10_muxer_select="mxf_muxer"
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 98dac17994..4e15f3da07 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -257,6 +257,10 @@ typedef struct MpegTSWriteStream {
int opus_queued_samples;
int opus_pending_trim_start;
+/* For H.264 */
+AVCodecParserContext *parser;
+AVCodecContext *parser_avctx;
+
DVBAC3Descriptor *dvb_ac3_desc;
} MpegTSWriteStream;
@@ -1216,6 +1220,21 @@ static int mpegts_init(AVFormatContext *s)
ts_st->payload_dts = AV_NOPTS_VALUE;
ts_st->cc = 15;
ts_st->discontinuity = ts->flags & MPEGTS_FLAG_DISCONT;
+if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
+ts_st->parser = av_parser_init(st->codecpar->codec_id);
+if (!ts_st->parser)
+return AVERROR(ENOMEM);
+ts_st->parser_avctx = avcodec_alloc_context3(NULL);
+if (!ts_st->parser_avctx)
+return AVERROR(ENOMEM);
+ret = avcodec_parameters_to_context(ts_st->parser_avctx,
st->codecpar);
+if (ret < 0)
+return ret;
+// We only want to parse frame headers
+ts_st->parser->flags |= PARSER_FLAG_COMPLETE_FRAMES;
+// And we want keyframe tagging heuristics
+ts_st->parser->flags |= PARSER_FLAG_USE_KEYFRAME_HEURISTICS;
+}
if (st->codecpar->codec_id == AV_CODEC_ID_AAC &&
st->codecpar->extradata_size > 0) {
AVStream *ast;
@@ -1832,6 +1851,7 @@ static int mpegts_write_packet_internal(AVFormatContext
*s, AVPacket *pkt)
const int64_t delay = av_rescale(s->max_delay, 9, AV_TIME_BASE) * 2;
const int64_t max_audio_delay = av_rescale(s->max_delay, 9,
AV_TIME_BASE) / 2;
int64_t dts = pkt->dts, pts = pkt->pts;
+int flags = pkt->flags;
int opus_samples = 0;
size_t side_data_size;
uint8_t *side_data = NULL;
@@ -1864,11 +1884,18 @@ static int mpegts_write_packet_internal(AVFormatContext
*s, AVPacket *pkt)
if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
const uint8_t *p = buf, *buf_end = p + size;
uint32_t state = -1;
-int extradd = (pkt->flags & AV_PKT_FLAG_KEY) ?
st->codecpar->extradata_size : 0;
+int extradd;
int ret = ff_check_h264_startcode(s, st, pkt);
if (ret < 0)
return ret;
+av_parser_parse2(ts_st->parser, ts_st->parser_avctx,
+ &buf, &size, pkt->data, pkt->size,
+ pkt->pts, pkt->dts, pkt->pos);
+if (ts_st->parser->key_frame)
+flags |= AV_PKT_FLAG_KEY;
+
+extradd = (flags & AV_PKT_FLAG_KEY) ? st->codecpar->extradata_size : 0;
if (extradd && AV_RB24(st->codecpar->extradata) > 1)
extradd = 0;
@@ -2106,7 +2133,7 @@ static int mpegts_write_packet_internal(AVFormatContext
*s, AVPacket *pkt)
av_assert0(!ts_st->payload_size);
// for video and subtitle, write a single pes packet
mpegts_write_pes(s, st, buf, size, pts, dts,
- pkt->flags & AV_PKT_FLAG_KEY, stream_id);
+ flags & AV_PKT_FLAG_KEY, stream_id);
ts_st->opus_queued_samples = 0;
av_free(data);
return 0;
@@ -2115,7 +2142,7 @@ static int mpegts_write_packet_internal(AVFormatContext
*s, AVPacket *pkt)
if (!ts_st->payload_size) {
ts_st->payload_pts = pts;
ts_st->payload_dts = dts;
-ts_st->payload_flags = pkt->flags;
+ts_st->payload_flags = flags;
}
memcpy(ts_st->payload + ts_st->payload_size, buf, size);
@@ -2184,6 +2211,9 @@ static void mpegts_deinit(AVFormatContext *s)
if (ts_st) {
av_freep(&ts_st->dvb_ac3_desc);
av_freep(&ts_st->payload);
+avcodec_free_context(&ts_st->parser_avctx);
+av_parser_close(ts_st->parser);
+ts_st->parser = NULL;
if (ts_st->amux) {
avformat_free_context(ts_st->amux);
ts_st->amux = NULL;
@@ -2207,8 +2237,15
[FFmpeg-devel] [PATCH 1/3] avcodec: add a parser flag to enable keyframe tagging heuristics
It will be used to allow parsers to be more liberal when tagging packets as
keyframes.
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 8b97895aeb..8e3d888266 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2809,6 +2809,7 @@ typedef struct AVCodecParserContext {
#define PARSER_FLAG_ONCE 0x0002
/// Set if the parser has a valid file offset
#define PARSER_FLAG_FETCHED_OFFSET0x0004
+#define PARSER_FLAG_USE_KEYFRAME_HEURISTICS 0x0008
#define PARSER_FLAG_USE_CODEC_TS 0x1000
int64_t offset; ///< byte offset from starting packet start
--
2.32.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 3/3] avcodec/h264_parser: use the keyframe heuristics flag
Tag only packets containing with IDR pictures as keyframes by default, same as
the decoder.
Fixes MP4 and Matroska muxers marking incorrect samples as Sync Samples in
scenarios where this AVParser is used.
Signed-off-by: James Almer
---
libavcodec/h264_parser.c | 16 ++--
tests/fate-run.sh | 4 ++--
tests/fate/ffmpeg.mak | 2 +-
tests/fate/lavf-container.mak | 12 ++--
tests/fate/matroska.mak| 2 +-
tests/ref/fate/copy-trac2211-avi | 2 +-
tests/ref/fate/matroska-h264-remux | 4 ++--
tests/ref/fate/segment-mp4-to-ts | 10 +-
tests/ref/lavf-fate/h264.mp4 | 4 ++--
9 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index d3c56cc188..532dc462b0 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -344,9 +344,11 @@ static inline int parse_nal_units(AVCodecParserContext *s,
get_ue_golomb_long(&nal.gb); // skip first_mb_in_slice
slice_type = get_ue_golomb_31(&nal.gb);
s->pict_type = ff_h264_golomb_to_pict_type[slice_type % 5];
-if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
-/* key frame, since recovery_frame_cnt is set */
-s->key_frame = 1;
+if (s->flags & PARSER_FLAG_USE_KEYFRAME_HEURISTICS) {
+if (p->sei.recovery_point.recovery_frame_cnt >= 0) {
+/* key frame, since recovery_frame_cnt is set */
+s->key_frame = 1;
+}
}
pps_id = get_ue_golomb(&nal.gb);
if (pps_id >= MAX_PPS_COUNT) {
@@ -370,9 +372,11 @@ static inline int parse_nal_units(AVCodecParserContext *s,
p->ps.sps = p->ps.pps->sps;
sps = p->ps.sps;
-// heuristic to detect non marked keyframes
-if (p->ps.sps->ref_frame_count <= 1 && p->ps.pps->ref_count[0] <=
1 && s->pict_type == AV_PICTURE_TYPE_I)
-s->key_frame = 1;
+if (s->flags & PARSER_FLAG_USE_KEYFRAME_HEURISTICS) {
+// heuristic to detect non marked keyframes
+if (p->ps.sps->ref_frame_count <= 1 && p->ps.pps->ref_count[0]
<= 1 && s->pict_type == AV_PICTURE_TYPE_I)
+s->key_frame = 1;
+}
p->poc.frame_num = get_bits(&nal.gb, sps->log2_max_frame_num);
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index ba437dfbb8..8680e35524 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -339,8 +339,8 @@ lavf_container_fate()
outdir="tests/data/lavf-fate"
file=${outdir}/lavf.$t
input="${target_samples}/$1"
-do_avconv $file -auto_conversion_filters $DEC_OPTS $2 -i "$input"
"$ENC_OPTS -metadata title=lavftest" -vcodec copy -acodec copy
-do_avconv_crc $file -auto_conversion_filters $DEC_OPTS -i
$target_path/$file $3
+do_avconv $file -auto_conversion_filters $DEC_OPTS $2 -i "$input"
"$ENC_OPTS -metadata title=lavftest" -vcodec copy -acodec copy $3
+do_avconv_crc $file -auto_conversion_filters $DEC_OPTS -i
$target_path/$file $4
}
lavf_image(){
diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 4dfb77d250..57d16fba6f 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -110,7 +110,7 @@ fate-copy-trac4914-avi: CMD = transcode mpegts
$(TARGET_SAMPLES)/mpeg2/xdcam8mp2
FATE_STREAMCOPY-$(call ALLYES, H264_DEMUXER AVI_MUXER) +=
fate-copy-trac2211-avi
fate-copy-trac2211-avi: $(SAMPLES)/h264/bbc2.sample.h264
fate-copy-trac2211-avi: CMD = transcode "h264 -r 14"
$(TARGET_SAMPLES)/h264/bbc2.sample.h264\
- avi "-c:a copy -c:v copy"
+ avi "-c:a copy -c:v copy -copyinkf"
FATE_STREAMCOPY-$(call ENCDEC, APNG, APNG) += fate-copy-apng
fate-copy-apng: fate-lavf-apng
diff --git a/tests/fate/lavf-container.mak b/tests/fate/lavf-container.mak
index 9e0eed4851..40250badc1 100644
--- a/tests/fate/lavf-container.mak
+++ b/tests/fate/lavf-container.mak
@@ -71,13 +71,13 @@ FATE_LAVF_CONTAINER_FATE =
$(FATE_LAVF_CONTAINER_FATE-yes:%=fate-lavf-fate-%)
$(FATE_LAVF_CONTAINER_FATE): REF =
$(SRC_PATH)/tests/ref/lavf-fate/$(@:fate-lavf-fate-%=%)
$(FATE_LAVF_CONTAINER_FATE): $(AREF) $(VREF)
-fate-lavf-fate-av1.mp4: CMD = lavf_container_fate
"av1-test-vectors/av1-1-b8-05-mv.ivf" "" "-c:v copy"
-fate-lavf-fate-av1.mkv: CMD = lavf_container_fate
"av1-test-vectors/av1-1-b8-05-mv.ivf" "" "-c:v copy"
-fate-lavf-fate-h264.mp4: CMD = lavf_container_fate "h264/intra_refresh.h264"
"" "-c:v copy"
+fate-lavf-fate-av1.mp4: CMD = lavf_container_fate
"av1-test-vectors/av1-1-b8-05-mv.ivf" "" "" "-c:v copy"
+fate-lavf-fate-av1.mkv: CMD = lavf_container_fate
"av1-test-vectors/av1-1-b8-05-mv.ivf" "" "" "-c:v copy"
+fate-lavf-fate-h264.mp4: CMD = lavf_container_fate "h264/intra_refresh.h264"
"" "-copyinkf" "-c:v copy -copyinkf"
fate-lavf-fate-vp3.ogg: CMD = lavf_con
Re: [FFmpeg-devel] [PATCH 2/2] Advertise current segment in streaming mode
On 6/24/21, 6:28 PM, "Kevin LaFlamme" wrote:
>In streaming mode when using a segment list, the current segment should
>be listed so that clients can immediately request it even before
>complete. Without this, even though the segment is being written in a
>way that it can be requested while still writing, clients won't know
>it's available.
>---
> libavformat/dashenc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>index 2b8fbcbe6e..901999324f 100644
>--- a/libavformat/dashenc.c
>+++ b/libavformat/dashenc.c
>@@ -706,6 +706,8 @@ static void output_segment_list(OutputStream *os,
>AVIOContext *out, >AVFormatCont
> Segment *seg = os->segments[i];
> avio_printf(out, "\t\t\t\t\t\n",
> seg->file);
> }
>+if (c->streaming)
>+avio_printf(out, "\t\t\t\t\t\n",
>os->filename);
As far as I understand the streaming mode is better supported only with
SegmentTemplate.
Adding the yet-to-be-completed segment in the SegmentList might break some
backward compatibility with clients that doesn't support low latency streaming.
After we added streaming support in ffmpeg, DASH-IF came up with a spec for low
latency streaming.
https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf. This spec also specifies
that SegmentTemplate is mandatory for low latency streaming.
> avio_printf(out, "\t\t\t\t\n");
> }
> if (!c->lhls || final) {
>--
>2.31.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 1/2] Fix double write of DASH manifest in streaming mode
On 7/14/21, 7:46 PM, "Kevin LaFlamme" wrote:
>Any feedback on this?
Thanks for the reminder. I have pushed this patch alone from this series.
I had some concerns on v2 of this series, to which I have replied separately.
Thanks and Regards,
Karthick
>On Jun 24, 2021, 8:58 AM -0400, Kevin LaFlamme , wrote:
>> When streaming mode is enabled, the DASH manifest is written on the
>> first packet for the segment so that the segment can be advertised
>> immediately to clients. It was also still writing the manifest at the
>> end of the segment leading to two duplicate writes.
>> ---
>> libavformat/dashenc.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index e7a4a3d9e1..2b8fbcbe6e 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -2030,7 +2030,10 @@ static int dash_flush(AVFormatContext *s, int final,
>> int stream)
>>
>> c->nr_of_streams_flushed = 0;
>> }
>> - ret = write_manifest(s, final);
>> + // In streaming mode the manifest is written at the beginning
>> + // of the segment instead
>> + if (!c->streaming || final)
>> + ret = write_manifest(s, final);
>> }
>> return ret;
>> }
>> @@ -2261,7 +2264,7 @@ static int dash_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> // in streaming mode, the segments are available for playing
>> // before fully written but the manifest is needed so that
>> // clients and discover the segment filenames.
>> - if (c->streaming && os->segment_type == SEGMENT_TYPE_MP4) {
>> + if (c->streaming) {
>> write_manifest(s, 0);
>> }
>>
>> --
>> 2.31.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 2/2] Advertise current segment in streaming mode
Ah I didn’t realize the SegmentTemplate was actually required in the spec for
streaming mode. This should be closed then, thanks.
On Jul 14, 2021, 10:45 AM -0400, Jeyapal, Karthick , wrote:
>
>
> On 6/24/21, 6:28 PM, "Kevin LaFlamme" wrote:
>
> > In streaming mode when using a segment list, the current segment should
> > be listed so that clients can immediately request it even before
> > complete. Without this, even though the segment is being written in a
> > way that it can be requested while still writing, clients won't know
> > it's available.
> > ---
> > libavformat/dashenc.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > index 2b8fbcbe6e..901999324f 100644
> > --- a/libavformat/dashenc.c
> > +++ b/libavformat/dashenc.c
> > @@ -706,6 +706,8 @@ static void output_segment_list(OutputStream *os,
> > AVIOContext *out, >AVFormatCont
> > Segment *seg = os->segments[i];
> > avio_printf(out, "\t\t\t\t\t\n", seg->file);
> > }
> > + if (c->streaming)
> > + avio_printf(out, "\t\t\t\t\t\n", os->filename);
> As far as I understand the streaming mode is better supported only with
> SegmentTemplate.
> Adding the yet-to-be-completed segment in the SegmentList might break some
> backward compatibility with clients that doesn't support low latency
> streaming.
> After we added streaming support in ffmpeg, DASH-IF came up with a spec for
> low latency streaming.
> https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf. This spec also specifies
> that SegmentTemplate is mandatory for low latency streaming.
> > avio_printf(out, "\t\t\t\t\n");
> > }
> > if (!c->lhls || final) {
> > --
> > 2.31.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 1/2] Fix double write of DASH manifest in streaming mode
Thanks! Yes I saw your comment on v2 and agree that patch can be closed/ignored.
On Jul 14, 2021, 10:47 AM -0400, Jeyapal, Karthick , wrote:
>
>
> On 7/14/21, 7:46 PM, "Kevin LaFlamme" wrote:
>
> > Any feedback on this?
> Thanks for the reminder. I have pushed this patch alone from this series.
> I had some concerns on v2 of this series, to which I have replied separately.
>
> Thanks and Regards,
> Karthick
> > On Jun 24, 2021, 8:58 AM -0400, Kevin LaFlamme , wrote:
> > > When streaming mode is enabled, the DASH manifest is written on the
> > > first packet for the segment so that the segment can be advertised
> > > immediately to clients. It was also still writing the manifest at the
> > > end of the segment leading to two duplicate writes.
> > > ---
> > > libavformat/dashenc.c | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > > index e7a4a3d9e1..2b8fbcbe6e 100644
> > > --- a/libavformat/dashenc.c
> > > +++ b/libavformat/dashenc.c
> > > @@ -2030,7 +2030,10 @@ static int dash_flush(AVFormatContext *s, int
> > > final, int stream)
> > >
> > > c->nr_of_streams_flushed = 0;
> > > }
> > > - ret = write_manifest(s, final);
> > > + // In streaming mode the manifest is written at the beginning
> > > + // of the segment instead
> > > + if (!c->streaming || final)
> > > + ret = write_manifest(s, final);
> > > }
> > > return ret;
> > > }
> > > @@ -2261,7 +2264,7 @@ static int dash_write_packet(AVFormatContext *s,
> > > AVPacket *pkt)
> > > // in streaming mode, the segments are available for playing
> > > // before fully written but the manifest is needed so that
> > > // clients and discover the segment filenames.
> > > - if (c->streaming && os->segment_type == SEGMENT_TYPE_MP4) {
> > > + if (c->streaming) {
> > > write_manifest(s, 0);
> > > }
> > >
> > > --
> > > 2.31.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".
[FFmpeg-devel] [PATCH] ffprobe: use quotation marks in the xml header output
xmllint (silently) replaces the ' with " when fixing and validating the output
of ffprobe in fate-ffprobe_xsd.
Signed-off-by: James Almer
---
fftools/ffprobe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 2d452c212e..94c73fd32c 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -1682,9 +1682,9 @@ static void xml_print_section_header(WriterContext *wctx)
wctx->section[wctx->level-1] : NULL;
if (wctx->level == 0) {
-const char *qual = "
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' "
-"xmlns:ffprobe='http://www.ffmpeg.org/schema/ffprobe' "
-"xsi:schemaLocation='http://www.ffmpeg.org/schema/ffprobe
ffprobe.xsd'";
+const char *qual = "
xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"; "
+"xmlns:ffprobe=\"http://www.ffmpeg.org/schema/ffprobe\"; "
+"xsi:schemaLocation=\"http://www.ffmpeg.org/schema/ffprobe
ffprobe.xsd\"";
printf("\n");
printf("<%sffprobe%s>\n",
--
2.32.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".
Re: [FFmpeg-devel] [PATCH 2/2] Advertise current segment in streaming mode
Any feedback on this?
On Jun 24, 2021, 8:58 AM -0400, Kevin LaFlamme , wrote:
> In streaming mode when using a segment list, the current segment should
> be listed so that clients can immediately request it even before
> complete. Without this, even though the segment is being written in a
> way that it can be requested while still writing, clients won't know
> it's available.
> ---
> libavformat/dashenc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 2b8fbcbe6e..901999324f 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -706,6 +706,8 @@ static void output_segment_list(OutputStream *os,
> AVIOContext *out, AVFormatCont
> Segment *seg = os->segments[i];
> avio_printf(out, "\t\t\t\t\t\n", seg->file);
> }
> + if (c->streaming)
> + avio_printf(out, "\t\t\t\t\t\n", os->filename);
> avio_printf(out, "\t\t\t\t\n");
> }
> if (!c->lhls || final) {
> --
> 2.31.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][libavcodec] Duckduckgo Truemotion 1 - some code cleanup and preparation for addition of sprite support
On 2021-07-04 17:58, ffmpegandmahanstreamer@lolcow.email wrote:
These are some cosmetic changes and also priming the decoder for
sprite support (which i plan on adding). This patch was mainly for me
to get used to the git email patch flow, if anything. Of course the
decoder still works as it was before (i tested it).
---
libavcodec/truemotion1.c | 41 +---
1 file changed, 17 insertions(+), 24 deletions(-)
diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..80946a405f 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -23,10 +23,10 @@
* @file
* Duck TrueMotion v1 Video Decoder by
* Alex Beregszaszi and
- * Mike Melanson (melan...@pcisys.net)
+ * Mike Melanson (m...@multimedia.cx)
*
* The TrueMotion v1 decoder presently only decodes 16-bit TM1 data
and
- * outputs RGB555 (or RGB565) data. 24-bit TM1 data is not supported
yet.
+ * outputs RGB555 (or RGB565) data.
*/
#include
@@ -360,8 +360,12 @@ static int
truemotion1_decode_header(TrueMotion1Context *s)
s->flags = FLAG_KEYFRAME;
if (s->flags & FLAG_SPRITE) {
+// https://wiki.multimedia.cx/index.php/Duck_TrueMotion_1
+header.xoffset = AV_RL16(&header_buffer[13]);
+header.yoffset = AV_RL16(&header_buffer[15]);
+header.width = AV_RL16(&header_buffer[17]);
+header.height = AV_RL16(&header_buffer[19]);
avpriv_request_sample(s->avctx, "Frame with sprite");
-/* FIXME header.width, height, xoffset and yoffset aren't
initialized */
return AVERROR_PATCHWELCOME;
} else {
s->w = header.xsize;
@@ -660,20 +664,15 @@ static void
truemotion1_decode_16bit(TrueMotion1Context *s)
case 0:
/* if macroblock width is 2, apply C-Y-C-Y; else
* apply C-Y-Y */
+APPLY_C_PREDICTOR();
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
if (s->block_width == 2) {
APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR();
OUTPUT_PIXEL_PAIR();
}
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
break;
case 1:
@@ -786,20 +785,14 @@ static void
truemotion1_decode_24bit(TrueMotion1Context *s)
case 0:
/* if macroblock width is 2, apply C-Y-C-Y; else
* apply C-Y-Y */
+APPLY_C_PREDICTOR_24();
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
if (s->block_width == 2) {
APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
}
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
break;
case 1:
ping
___
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/8] sws: add a new scaling API
On Tue, Jul 13, 2021 at 07:54:18PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2021-07-12 21:08:55) > > On Mon, Jul 12, 2021 at 01:07:06PM +0200, Anton Khirnov wrote: > > [...] > > > diff --git a/libswscale/swscale.h b/libswscale/swscale.h > > > index 50d6d46553..41eacd2dea 100644 > > > --- a/libswscale/swscale.h > > > +++ b/libswscale/swscale.h > > > @@ -30,6 +30,7 @@ > > > #include > > > > > > #include "libavutil/avutil.h" > > > +#include "libavutil/frame.h" > > > #include "libavutil/log.h" > > > #include "libavutil/pixfmt.h" > > > #include "version.h" > > > @@ -218,6 +219,85 @@ int sws_scale(struct SwsContext *c, const uint8_t > > > *const srcSlice[], > > >const int srcStride[], int srcSliceY, int srcSliceH, > > >uint8_t *const dst[], const int dstStride[]); > > > > > > +/** > > > + * Scale source data from src and write the output to dst. > > > + * > > > + * This is merely a convenience wrapper around > > > + * - sws_frame_start() > > > + * - sws_send_slice(0, src->height) > > > + * - sws_receive_slice(0, dst->height) > > > + * - sws_frame_end() > > > + * > > > + * @param dst The destination frame. See documentation for > > > sws_frame_start() for > > > + *more details. > > > + * @param src The source frame. > > > + * > > > + * @return 0 on success, a negative AVERROR code on failure > > > + */ > > > +int sws_scale_frame(struct SwsContext *c, AVFrame *dst, const AVFrame > > > *src); > > > + > > > +/** > > > + * Initialize the scaling process for a given pair of source/destination > > > frames. > > > + * Must be called before any calls to sws_send_slice() and > > > sws_receive_slice(). > > > + * > > > + * This function will retain references to src and dst. > > > + * > > > + * @param dst The destination frame. > > > + * > > > + *The data buffers may either be already allocated by the > > > caller or > > > + *left clear, in which case they will be allocated by the > > > scaler. > > > + *The latter may have performance advantages - e.g. in > > > certain cases > > > + *some output planes may be references to input planes, > > > rather than > > > + *copies. > > > + * > > > + *Output data will be written into this frame in successful > > > + *sws_receive_slice() calls. > > > + * @param src The source frame. The data buffers must be allocated, but > > > the > > > + *frame data does not have to be ready at this point. Data > > > + *availability is then signalled by sws_send_slice(). > > > + * @return 0 on success, a negative AVERROR code on failure > > > + * > > > + * @see sws_frame_end() > > > + */ > > > +int sws_frame_start(struct SwsContext *c, AVFrame *dst, const AVFrame > > > *src); > > > + > > > +/** > > > + * Finish the scaling process for a pair of source/destination frames > > > previously > > > + * submitted with sws_frame_start(). Must be called after all > > > sws_send_slice() > > > + * and sws_receive_slice() calls are done, before any new > > > sws_frame_start() > > > + * calls. > > > + */ > > > +void sws_frame_end(struct SwsContext *c); > > > + > > > > > +/** > > > + * Indicate that a horizontal slice of input data is available in the > > > source > > > + * frame previously provided to sws_frame_start(). The slices may be > > > provided in > > > + * any order, but may not overlap. For vertically subsampled pixel > > > formats, the > > > + * slices must be aligned according to subsampling. > > > + * > > > + * @param slice_start first row of the slice > > > + * @param slice_height number of rows in the slice > > > + * > > > + * @return 0 on success, a negative AVERROR code on failure. > > > + */ > > > +int sws_send_slice(struct SwsContext *c, unsigned int slice_start, > > > + unsigned int slice_height); > > > > I suggest to use non 0 on success. > > Outright >0, or >= 0? i meant >= 0 / non negative > > > That could then be extended in the future for example to provide information > > about how many lines have already been consumed and its memory be reused > > I will amend the patch. > > Are you satisfied with the API otherwise? yes the API in this patch looks nice. I havnt looked over all other code yet Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell 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] Mailing List Delay
On 2021-07-14 09:17, Derek Buitenhuis wrote: On 7/14/2021 12:27 PM, Nicolas George wrote: Looking at the headers, it looks like the delay happens at Google before the mail arrives to the mailing-list. Yours arrived quickly. Mine will too, I guess. Sending from GMail, I have had anywhere from instantly, to 1.5 hours delay ever since moving to the "new" (Hungarian?) mailing list host. Especially when sending via git-send-email. Oh, that's strange. All my emails always send instantly. Even when i was on cock.li which wasn't very reliable (read below). I have been bringing this up consstently for years, and been told it's a "non-issue", but it is incredibly annoying. I am not sure if it's due to Google having issues (trust?) sending to out host, or the host having trouble receiving. That's why i use this email provider and not my main Gmail for mailing lists. I used to use cock.li but they shut down signups. Plus the one i'm using (lolcow.email) has a nice threading interface on the web. I have a special email for every mailing list im in (FFmpeg, llvm, qemu, gstreamer, freebsd/linux etc..). The nice thing is that you can put them in the Gmail or Apple/Android mail app on your phone for easy reading. And it also helps stop SPAM mails which i have gotten by posting on mailing lists. It may be a good stopgap solution for some. I have also noticed, since switching to this 'new' mysertious mailing list host a few years back that a chunk of ffmpeg-devel traffic gets filed into spam consistently. Also very annoying - I have missed several patches this way. This is not specific to GMail, for me, so far. That's because mail from "unknown" hosts might get into spam frequently. You may have to explicitly whitelist the mailing list in your settings. If it's a trust thing, sure, we can blame Google or whoever, but I think we should have a less cruddy experience for users of the largest email provider in the world, by default, rather just shrugging and saying "sucks to be you, don't use GMail". - Derek ___ 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] Mailing List Delay
On 2021-07-14 09:43, Derek Buitenhuis wrote: On 7/14/2021 2:35 PM, ffmpegandmahanstreamer@lolcow.email wrote: I have been bringing this up consstently for years, and been told it's a "non-issue", but it is incredibly annoying. I am not sure if it's due to Google having issues (trust?) sending to out host, or the host having trouble receiving. That's why i use this email provider and not my main Gmail for mailing lists. Saying "don't use the largest email provider in the world because our list is janky" isn't a goo solution. I'm not against fixing the mailing list. No, not at all. It need to be fixed. But Google is big company and trying to figure out how to make their mail deliver successfully might be a problem. I think this was the reasoning behind alot of the major open source projects switching to Nongnu.org and Google Groups along with Github discussions. IIRC even the Alliance of Open Media has their patch mailing list on Groups.io and Google Groups now. But I'm not saying FFMPEG should. Just saying that other projects have been facing similar issues and fixed it by moving to a large mailing list hub. And libvpx uses Google mail servers for their patches as well. At the very least though, a mailign list manager with the ability to send posts via the web could also be useful. This i what Python does: https://mail.python.org/archives/list/python-...@python.org/ It may be a good stopgap solution for some. I have also noticed, since switching to this 'new' mysertious mailing list host a few years back that a chunk of ffmpeg-devel traffic gets filed into spam consistently. Also very annoying - I have missed several patches this way. This is not specific to GMail, for me, so far. That's because mail from "unknown" hosts might get into spam frequently. You may have to explicitly whitelist the mailing list in your settings. Also not really an acceptable solution to tell every single person this, in my opinion. You can have a banner on the mailing list subscribe page to whitelist the domain along with instructions maybe? - Derek ___ 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] Mailing List Delay
ffmpegandmahanstreamer@lolcow.email (12021-07-14): > I'm not against fixing the mailing list. No, not at all. It need to be > fixed. But Google is big company and trying to figure out how to make their > mail deliver successfully might be a problem. > > I think this was the reasoning behind alot of the major open source projects > switching to Nongnu.org and Google Groups along with Github discussions. > IIRC even the Alliance of Open Media has their patch mailing list on > Groups.io and Google Groups now. But I'm not saying FFMPEG should. Just > saying that other projects have been facing similar issues and fixed it by > moving to a large mailing list hub. And libvpx uses Google mail servers for > their patches as well. This discussion would be incomplete without reminding that Google and these large actors have, under the excuse of fighting spam, unilaterally changed the protocols they implement in ways that makes it harder for small actors to stay in the game. Therefore, the terms of the alternative are between choosing a solution that is seamless even for the clueless but at the same time that enables the monopolists and strengthen their position, or resisting the monopolists and bearing a few technical hurdles for people who use their services. Since FFmpeg is a major Libre Software project, and one that is quite technical at that, I think it should be obvious our side is the one of freedom and against the monopolists. Furthermore, FFmpeg has some importance for Google itself, which could give us weight in asking they fix their shit if they want their users to be able to contribute without hassle. That would benefit all projects who want to self-host their mailing-lists. Also, it is worth remembering that if lkml can self-host, so should we. And, in the wake of the GitHub Copilot scandal, I think it is pretty obvious we should definitely not choose solutions that are under singular private control. 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".
[FFmpeg-devel] [PATCH] ffmpeg-web/robots.txt: attempt to keep spiders out of dynamically generated git content
Signed-off-by: Michael Niedermayer --- htdocs/robots.txt | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/htdocs/robots.txt b/htdocs/robots.txt index eb05362..4bbc395 100644 --- a/htdocs/robots.txt +++ b/htdocs/robots.txt @@ -1,2 +1,13 @@ User-agent: * -Disallow: +Crawl-delay: 10 +Disallow: /gitweb/ +Disallow: /*a=search* +Disallow: /*/search/* +Disallow: /*a=blobdiff* +Disallow: /*/blobdiff/* +Disallow: /*a=commitdiff* +Disallow: /*/commitdiff/* +Disallow: /*a=snapshot* +Disallow: /*/snapshot/* +Disallow: /*a=blame* +Disallow: /*/blame/* -- 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] Mailing List Delay
On Wed, Jul 14, 2021 at 04:47:49PM +0530, Gyan Doshi wrote: > Is there an issue with the mailing list over the past couple of days? > I've just received multiple messages over 12 hours old. Some spiders where attracted by gitwebs and got entangled in it eventually the OOM killer freed them but in the blaze of holy linux kernel OOM fire grossd and named also where burnt ive updated grossds config to reduce its memory requirements a little and also posted a patch for robots.txt which might resolve this If someone has seen similar or has suggestions for more robots.txt lines please post them Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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] ffmpeg-web/robots.txt: attempt to keep spiders out of dynamically generated git content
On Wed, Jul 14, 2021 at 08:51:21PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > htdocs/robots.txt | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/htdocs/robots.txt b/htdocs/robots.txt > index eb05362..4bbc395 100644 > --- a/htdocs/robots.txt > +++ b/htdocs/robots.txt > @@ -1,2 +1,13 @@ > User-agent: * > -Disallow: > +Crawl-delay: 10 > +Disallow: /gitweb/ > +Disallow: /*a=search* > +Disallow: /*/search/* > +Disallow: /*a=blobdiff* > +Disallow: /*/blobdiff/* > +Disallow: /*a=commitdiff* > +Disallow: /*/commitdiff/* > +Disallow: /*a=snapshot* > +Disallow: /*/snapshot/* > +Disallow: /*a=blame* > +Disallow: /*/blame/* This is based on https://serverfault.com/questions/506613/ideal-robots-txt-for-a-gitweb-installation i will add this link to robots.txt [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. 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] Mailing List Delay
Derek Buitenhuis (12021-07-14): > Yeah, I know, but it seemed to be a good time to bring this up yet again. > Sorry if that was unclear. No problem. It is an important discussion, and now we are on the same page. > Looking at a set of 3 patches I sent with git-send-email that had this issues, > the mbox headers from patchwork show: > > * > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210220185050.508373-2-derek.buitenh...@gmail.com/ > * Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org > [79.124.17.100]) > by ffaux.localdomain (Postfix) with ESMTP id E4DB644ABCA > for ; Sat, 20 Feb 2021 21:47:10 > +0200 (EET) > * Received: from [127.0.1.1] (localhost [127.0.0.1]) > by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ACBCC68A72F; > Sat, 20 Feb 2021 21:47:10 +0200 (EET) You relevant part is: Received: by mail-lj1-f170.google.com with SMTP id v6so42989273ljh.9 for ; Sat, 20 Feb 2021 11:47:04 -0800 (PST) X-Received: by 2002:adf:8084:: with SMTP id 4mr14511157wrl.49.1613847064941; Sat, 20 Feb 2021 10:51:04 -0800 (PST) It shows that the mail spent approximatively one hour stuck between two relays that belong to Google. There is nothing under our control here. Now, the difference being close to one hour, it can probably be explained by the mail being temporarily rejected by the next relay, ours and queued by Google. Therefore, the information we need now to debug is what the logs of ffbox0-bg.mplayerhq.hu contains immediately after 20 Feb 2021 11:47:04 -0800. If it happens to you again, you can ask for the logs immediately, it will be more likely the admins can find what went wrong. Note that there is a possibility that the issue was a network issue, and therefore does not appear in our logs. We would need Google's logs for that. 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".
[FFmpeg-devel] [PATCH] avformat/utils: remove AVStreamInternal.orig_codec_id
It's a write only field.
Signed-off-by: James Almer
---
libavformat/internal.h | 2 --
libavformat/utils.c| 6 --
2 files changed, 8 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 240de9e289..4b7ab082e7 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -204,8 +204,6 @@ struct AVStreamInternal {
*/
int avctx_inited;
-enum AVCodecID orig_codec_id;
-
/* the context for extracting extradata in find_stream_info()
* inited=1/bsf=NULL signals that extracting is not possible (codec not
* supported) */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 998fddf270..efdb6f062f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -604,9 +604,6 @@ int avformat_open_input(AVFormatContext **ps, const char
*filename,
update_stream_avctx(s);
-for (i = 0; i < s->nb_streams; i++)
-s->streams[i]->internal->orig_codec_id =
s->streams[i]->codecpar->codec_id;
-
if (options) {
av_dict_free(options);
*options = tmp;
@@ -3614,9 +3611,6 @@ int avformat_find_stream_info(AVFormatContext *ic,
AVDictionary **options)
}
}
-if (st->codecpar->codec_id != st->internal->orig_codec_id)
-st->internal->orig_codec_id = st->codecpar->codec_id;
-
ret = avcodec_parameters_to_context(avctx, st->codecpar);
if (ret < 0)
goto find_stream_info_err;
--
2.32.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".
Re: [FFmpeg-devel] Mailing List Delay
On 7/14/2021 7:59 PM, Michael Niedermayer wrote: > Some spiders where attracted by gitwebs and got entangled in it > eventually the OOM killer freed them but in the blaze of holy > linux kernel OOM fire grossd and named also where burnt Are services not restarted automatically if they're killed? - Derek ___ 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] Mailing List Delay
On 7/14/2021 8:05 PM, Nicolas George wrote: > If it happens to you again, you can ask for the logs immediately, it will > be more likely the admins can find what went wrong. Who is admin here who I would ask? Michael? - Derek ___ 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] Mailing List Delay
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Wednesday, 14 July 2021 21:05 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] Mailing List Delay > > Derek Buitenhuis (12021-07-14): > > Yeah, I know, but it seemed to be a good time to bring this up yet again. > > Sorry if that was unclear. > > No problem. It is an important discussion, and now we are on the same page. > > > Looking at a set of 3 patches I sent with git-send-email that had this > > issues, the mbox headers from patchwork show: > > > > * > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210220185050.50837 > 3-2-derek.buitenh...@gmail.com/ > > * Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org > [79.124.17.100]) > > by ffaux.localdomain (Postfix) with ESMTP id E4DB644ABCA > > for ; Sat, 20 Feb 2021 21:47:10 > +0200 (EET) > > * Received: from [127.0.1.1] (localhost [127.0.0.1]) > > by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ACBCC68A72F; > > Sat, 20 Feb 2021 21:47:10 +0200 (EET) > > You relevant part is: > > Received: by mail-lj1-f170.google.com with SMTP id v6so42989273ljh.9 for > ; Sat, 20 Feb 2021 11:47:04 -0800 (PST) > > X-Received: by 2002:adf:8084:: with SMTP id > 4mr14511157wrl.49.1613847064941; Sat, 20 Feb 2021 10:51:04 -0800 (PST) > > It shows that the mail spent approximatively one hour stuck between two > relays that belong to Google. There is nothing under our control here. > > Now, the difference being close to one hour, it can probably be explained by > the mail being temporarily rejected by the next relay, ours and queued by > Google. > > Therefore, the information we need now to debug is what the logs of > ffbox0-bg.mplayerhq.hu contains immediately after 20 Feb 2021 11:47:04 - > 0800. Hi, I have a slightly different interpretation of the mail headers. I have looked at the exact same messages' headers as I have received them. >From my understanding, the delay is in the delivery from a google mail server to ffbox0-bg.mplayerhq.hu. The delay is exactly 70 minutes, and this looks to me very much like the result of retries in sending (e.g. 10, 20, 40 = 70 min). That would mean that Google retries and ffbox0-bg.mplayerhq.hu is not accepting for some reason (maybe it identifies the second mail as duplicate or flooding and blocks for 1h?). softworkz ___ 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] Mailing List Delay
On Wed, Jul 14, 2021 at 08:13:24PM +0100, Derek Buitenhuis wrote: > On 7/14/2021 7:59 PM, Michael Niedermayer wrote: > > Some spiders where attracted by gitwebs and got entangled in it > > eventually the OOM killer freed them but in the blaze of holy > > linux kernel OOM fire grossd and named also where burnt > > Are services not restarted automatically if they're killed? restarting everything automatically has its own risks. For example it makes some attacks easier as the attacker has unlimited retries. Also keep in mind AFAIK noone disabled any distribution default restarting of services. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu 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] ffmpeg-web/robots.txt: attempt to keep spiders out of dynamically generated git content
On Wed, Jul 14, 2021 at 04:00:53PM -0400, ffmpegandmahanstreamer@lolcow.email wrote: > On 2021-07-14 14:51, Michael Niedermayer wrote: > > Signed-off-by: Michael Niedermayer > > --- > > htdocs/robots.txt | 13 - > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/htdocs/robots.txt b/htdocs/robots.txt > > index eb05362..4bbc395 100644 > > --- a/htdocs/robots.txt > > +++ b/htdocs/robots.txt > > @@ -1,2 +1,13 @@ > > User-agent: * > > -Disallow: > > +Crawl-delay: 10 > > +Disallow: /gitweb/ > > +Disallow: /*a=search* > > +Disallow: /*/search/* > > +Disallow: /*a=blobdiff* > > +Disallow: /*/blobdiff/* > > +Disallow: /*a=commitdiff* > > +Disallow: /*/commitdiff/* > > +Disallow: /*a=snapshot* > > +Disallow: /*/snapshot/* > > +Disallow: /*a=blame* > > +Disallow: /*/blame/* > LGTM based on my own personal experiences. But the robots.txt has to be will apply > applied for git.ffmpeg.org as well, and not just ffmpeg.org. Or else they > will just do the same for git.ffmpeg since there are treated separately. was expecting this a bit ... i will look into that tomorrow or so unless someone else does before me thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: 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] web/security: Add CVE-2021-30123 (never affected a release)
On Mon, Jul 12, 2021 at 11:14:14PM +0200, Michael Niedermayer wrote: > Thanks to Jan Ekström for details > --- > src/security | 1 + > 1 file changed, 1 insertion(+) will apply [...] -- 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".
[FFmpeg-devel] [PATCH] configure: use pkg-config for xlib/Xv
--- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 2d2d125fd3..f5370b3ead 100755 --- a/configure +++ b/configure @@ -6194,7 +6194,7 @@ check_func_headers windows.h Sleep check_func_headers windows.h VirtualAlloc check_func_headers glob.h glob enabled xlib && -check_lib xlib "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute -lXv -lX11 -lXext +check_pkg_config xlib "xv" "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute check_headers direct.h check_headers dirent.h -- 2.25.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] configure: use pkg-config for xlib/Xv
On 7/14/2021 6:23 PM, Timo Rothenpieler wrote: --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 2d2d125fd3..f5370b3ead 100755 --- a/configure +++ b/configure @@ -6194,7 +6194,7 @@ check_func_headers windows.h Sleep check_func_headers windows.h VirtualAlloc check_func_headers glob.h glob enabled xlib && -check_lib xlib "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute -lXv -lX11 -lXext +check_pkg_config xlib "xv" "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute No need for quotes if you're just checking for xv. LGTM either way, but probably keep the existing check as fallback. check_headers direct.h check_headers dirent.h ___ 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] configure: use pkg-config for xlib/Xv
On 14.07.2021 23:28, James Almer wrote: On 7/14/2021 6:23 PM, Timo Rothenpieler wrote: --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 2d2d125fd3..f5370b3ead 100755 --- a/configure +++ b/configure @@ -6194,7 +6194,7 @@ check_func_headers windows.h Sleep check_func_headers windows.h VirtualAlloc check_func_headers glob.h glob enabled xlib && - check_lib xlib "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute -lXv -lX11 -lXext + check_pkg_config xlib "xv" "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute No need for quotes if you're just checking for xv. LGTM either way, but probably keep the existing check as fallback. Did libXv ever not have a .pc file? I had the old version as fallback first, but could not find a case where there was no xv.pc. smime.p7s Description: S/MIME Cryptographic 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] configure: use pkg-config for xlib/Xv
On 7/14/2021 6:54 PM, Timo Rothenpieler wrote: On 14.07.2021 23:28, James Almer wrote: On 7/14/2021 6:23 PM, Timo Rothenpieler wrote: --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 2d2d125fd3..f5370b3ead 100755 --- a/configure +++ b/configure @@ -6194,7 +6194,7 @@ check_func_headers windows.h Sleep check_func_headers windows.h VirtualAlloc check_func_headers glob.h glob enabled xlib && - check_lib xlib "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute -lXv -lX11 -lXext + check_pkg_config xlib "xv" "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute No need for quotes if you're just checking for xv. LGTM either way, but probably keep the existing check as fallback. Did libXv ever not have a .pc file? I had the old version as fallback first, but could not find a case where there was no xv.pc. It's about not breaking a currently working check on environments that lack pkg-config. I know, fringe case, but if keeping this line after a || prevents potential regressions, it costs nothing. New checks can be pkg-config only just fine, it's existing ones that we should keep in place as fallback when adding a pkg-config variant. ___ 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] configure: use pkg-config for xlib/Xv
On 15.07.2021 00:02, James Almer wrote: On 7/14/2021 6:54 PM, Timo Rothenpieler wrote: On 14.07.2021 23:28, James Almer wrote: On 7/14/2021 6:23 PM, Timo Rothenpieler wrote: --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 2d2d125fd3..f5370b3ead 100755 --- a/configure +++ b/configure @@ -6194,7 +6194,7 @@ check_func_headers windows.h Sleep check_func_headers windows.h VirtualAlloc check_func_headers glob.h glob enabled xlib && - check_lib xlib "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute -lXv -lX11 -lXext + check_pkg_config xlib "xv" "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute No need for quotes if you're just checking for xv. LGTM either way, but probably keep the existing check as fallback. Did libXv ever not have a .pc file? I had the old version as fallback first, but could not find a case where there was no xv.pc. It's about not breaking a currently working check on environments that lack pkg-config. I know, fringe case, but if keeping this line after a || prevents potential regressions, it costs nothing. New checks can be pkg-config only just fine, it's existing ones that we should keep in place as fallback when adding a pkg-config variant. Kept the old check as fallback and applied smime.p7s Description: S/MIME Cryptographic 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] Mailing List Delay
On 2021-07-14 14:55, Nicolas George wrote: ffmpegandmahanstreamer@lolcow.email (12021-07-14): I'm not against fixing the mailing list. No, not at all. It need to be fixed. But Google is big company and trying to figure out how to make their mail deliver successfully might be a problem. I think this was the reasoning behind alot of the major open source projects switching to Nongnu.org and Google Groups along with Github discussions. IIRC even the Alliance of Open Media has their patch mailing list on Groups.io and Google Groups now. But I'm not saying FFMPEG should. Just saying that other projects have been facing similar issues and fixed it by moving to a large mailing list hub. And libvpx uses Google mail servers for their patches as well. This discussion would be incomplete without reminding that Google and these large actors have, under the excuse of fighting spam, unilaterally changed the protocols they implement in ways that makes it harder for small actors to stay in the game. Therefore, the terms of the alternative are between choosing a solution that is seamless even for the clueless but at the same time that enables the monopolists and strengthen their position, or resisting the monopolists and bearing a few technical hurdles for people who use their services. While this is true, the goal of the FFmpeg project is to further multimedia. Not to fight against "the man", big corporations, or solve other problems. We've seen firsthand how "external influences" can creep up on a project, removing it from its goals. Just look at what happened with Gnome and Linux Foundation. The solution picked should be easy for even the "clueless" so they too can contribute and further the goals of the project. Since FFmpeg is a major Libre Software project, and one that is quite technical at that, I think it should be obvious our side is the one of freedom and against the monopolists. And the AOM/Python/other projects I mentioned aren't major and technical projects? They have chosen the "other" side. Furthermore, FFmpeg has some importance for Google itself, which could give us weight in asking they fix their shit if they want their users to be able to contribute without hassle. That would benefit all projects who want to self-host their mailing-lists. Also, it is worth remembering that if lkml can self-host, so should we. Linux kernel is 100x bigger than ffmpeg in terms of contributors, resources, and "clout". They can afford to self host. And, in the wake of the GitHub Copilot scandal, I think it is pretty obvious we should definitely not choose solutions that are under singular private control. The mailing list right now is under private control right now as well. Its just that the private control isn't Google or a big company. Rather, it is Fabrice Bellard. I do think something needs to be done about it, I just don't think this is the right place to do it. Regards, ___ 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] ffmpeg-web/robots.txt: attempt to keep spiders out of dynamically generated git content
On 2021-07-14 14:51, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer --- htdocs/robots.txt | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/htdocs/robots.txt b/htdocs/robots.txt index eb05362..4bbc395 100644 --- a/htdocs/robots.txt +++ b/htdocs/robots.txt @@ -1,2 +1,13 @@ User-agent: * -Disallow: +Crawl-delay: 10 +Disallow: /gitweb/ +Disallow: /*a=search* +Disallow: /*/search/* +Disallow: /*a=blobdiff* +Disallow: /*/blobdiff/* +Disallow: /*a=commitdiff* +Disallow: /*/commitdiff/* +Disallow: /*a=snapshot* +Disallow: /*/snapshot/* +Disallow: /*a=blame* +Disallow: /*/blame/* LGTM based on my own personal experiences. But the robots.txt has to be applied for git.ffmpeg.org as well, and not just ffmpeg.org. Or else they will just do the same for git.ffmpeg since there are treated separately. ___ 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][ffmpeg-web] Add Reddit fourm
This adds the Reddit subreddit to the forum section. It has over 7000 participants. Many of the developers on here, like Gyan and Paul, participate on there already. I also think Gyan is the moderator of that subreddit as well. And reddit is more popular than superuser. --- src/contact | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/contact b/src/contact index 4f75655..786 100644 --- a/src/contact +++ b/src/contact @@ -159,4 +159,7 @@ href="https://superuser.com/questions/tagged/ffmpeg";>FFmpeg at SuperUser + +href="https://reddit.com/r/ffmpeg";>FFmpeg at Reddit + -- ___ 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/isom_tags.c: add ipcm to list of tags
Fixes http://trac.ffmpeg.org/ticket/9219
---
libavformat/isom_tags.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
index 1666b9d4a5..e2e589b658 100644
--- a/libavformat/isom_tags.c
+++ b/libavformat/isom_tags.c
@@ -312,6 +312,8 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_PCM_S16LE, MKTAG('s', 'o', 'w', 't') },
{ AV_CODEC_ID_PCM_S16BE, MKTAG('l', 'p', 'c', 'm') },
{ AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
+{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'p', 'c', 'm') },
+{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'p', 'c', 'm') },
{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
{ AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
--
2.30.2
___
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/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin wrote: > > > > > Adding DX11 relevant device type checks and adjusting callbacks with > > > proper MediaSDK pair type support. > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > Signed-off-by: Artem Galin > > > . > > > > > > Patchset obviously closes the gap of DirectX 11 support > > and already checked with several apps that use FFMPEG. > > > > Any particular review comments should be yet expected? > > > > Changes seem to be straight forward > > and incorporate prev. comments. > > > > thank in advance > > > > regards > > Max > > There are some issues pointed out by Soft Works related to switching the > default to DX11 breaking existing command lines with DX9, plus an > OpenCL<->QSV interop regression this would introduce that according to > him should be easy to fix. > > If those are addressed, the set should be good. If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281778.html (qsvdec: add support for HW_DEVICE_CTX method) first, we should be able to use the common device stuff to initialize d3d11va device for QSV and needn't use child_device_type to specify child device. -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv@d3d11va Thanks Haihao > ___ > 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 v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
> -Original Message- > From: ffmpeg-devel On Behalf Of > Xiang, Haihao > Sent: Thursday, 15 July 2021 04:35 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > d3d11va support, added mfxhdlpair > > On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > wrote: > > > > > > > Adding DX11 relevant device type checks and adjusting callbacks > > > > with proper MediaSDK pair type support. > > > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > > > Signed-off-by: Artem Galin . > > > > > > > > > Patchset obviously closes the gap of DirectX 11 support and already > > > checked with several apps that use FFMPEG. > > > > > > Any particular review comments should be yet expected? > > > > > > Changes seem to be straight forward > > > and incorporate prev. comments. > > > > > > thank in advance > > > > > > regards > > > Max > > > > There are some issues pointed out by Soft Works related to switching > > the default to DX11 breaking existing command lines with DX9, plus an > > OpenCL<->QSV interop regression this would introduce that according to > > him should be easy to fix. > > > > If those are addressed, the set should be good. > > If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > June/281778.html > (qsvdec: add support for HW_DEVICE_CTX method) first, we should be able > to use the common device stuff to initialize d3d11va device for QSV and > needn't use child_device_type to specify child device. There's no doubt that the new method will be better, but the point is not to break existing command lines. From my experience, ffmpeg usually avoids to break established command line patterns, which is a good thing imo. Anything more official than my perception? Please feel free to chime in... ;-) softworkz 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".
Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On 7/15/2021 12:10 AM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Xiang, Haihao Sent: Thursday, 15 July 2021 04:35 To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: On Tue, Nov 3, 2020 at 7:47 PM Artem Galin wrote: Adding DX11 relevant device type checks and adjusting callbacks with proper MediaSDK pair type support. Extending structure for proper MediaSDK pair type support. Signed-off-by: Artem Galin . Patchset obviously closes the gap of DirectX 11 support and already checked with several apps that use FFMPEG. Any particular review comments should be yet expected? Changes seem to be straight forward and incorporate prev. comments. thank in advance regards Max There are some issues pointed out by Soft Works related to switching the default to DX11 breaking existing command lines with DX9, plus an OpenCL<->QSV interop regression this would introduce that according to him should be easy to fix. If those are addressed, the set should be good. If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- June/281778.html (qsvdec: add support for HW_DEVICE_CTX method) first, we should be able to use the common device stuff to initialize d3d11va device for QSV and needn't use child_device_type to specify child device. There's no doubt that the new method will be better, but the point is not to break existing command lines. From my experience, ffmpeg usually avoids to break established command line patterns, which is a good thing imo. Anything more official than my perception? Please feel free to chime in... ;-) That patch appears to attempt to maintain support for existing command lines for a deprecation period, something we've done before with other hwaccels like cuvid, so if it's really better, it's fine and acceptable. softworkz 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 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/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Thursday, 15 July 2021 05:21 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > d3d11va support, added mfxhdlpair > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> Xiang, Haihao > >> Sent: Thursday, 15 July 2021 04:35 > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > >> d3d11va support, added mfxhdlpair > >> > >> On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > >>> On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > >> wrote: > > > Adding DX11 relevant device type checks and adjusting callbacks > > with proper MediaSDK pair type support. > > > > Extending structure for proper MediaSDK pair type support. > > > > Signed-off-by: Artem Galin . > > > Patchset obviously closes the gap of DirectX 11 support and already > checked with several apps that use FFMPEG. > > Any particular review comments should be yet expected? > > Changes seem to be straight forward and incorporate prev. comments. > > thank in advance > > regards > Max > >>> > >>> There are some issues pointed out by Soft Works related to switching > >>> the default to DX11 breaking existing command lines with DX9, plus > >>> an OpenCL<->QSV interop regression this would introduce that > >>> according to him should be easy to fix. > >>> > >>> If those are addressed, the set should be good. > >> > >> If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > >> June/281778.html > >> (qsvdec: add support for HW_DEVICE_CTX method) first, we should be > >> able to use the common device stuff to initialize d3d11va device for > >> QSV and needn't use child_device_type to specify child device. > > > > There's no doubt that the new method will be better, but the point is not > to break existing command lines. From my experience, ffmpeg usually avoids > to break established command line patterns, which is a good thing imo. > > > > Anything more official than my perception? Please feel free to chime > > in... ;-) > > That patch appears to attempt to maintain support for existing command > lines for a deprecation period, something we've done before with other > hwaccels like cuvid, so if it's really better, it's fine and acceptable. ^ Hi James, "That patch" that preserves compatibility doesn't exist yet. We need to make sure that command lines using the '--child_device' parameter will continue to work, while Haihao's patch will be the "future way": > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv@d3d11va The new behaviour that is introduced by this patch is that an initialized hw device can now be applied to qsv decoders (currently only to filter graphs and qsv encoders). Additionally, the default should remain to be D3D9 (if none of the above is specified) as laid out earlier - again for maintaining compatibility but also for better robustness and performance. PS: Regarding the OpenCL regression you mentioned, I had already submitted the patch to Intel and they have added it to their staging-repo for ffmpeg patches: https://github.com/intel-media-ci/cartwheel-ffmpeg/commit/7456b1ac0d385acc6d2851470c1b04ab3780adf8 Kind regards, softworkz ___ 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] lavc/videotoolboxenc.c: Fix the trc support for iec61966-2-1 (sRGB)
--- libavcodec/videotoolboxenc.c | 4 1 file changed, 4 insertions(+) diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index 4eaabed5d8..61eb6e1921 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -990,6 +990,10 @@ static int get_cv_transfer_function(AVCodecContext *avctx, *gamma_level = CFNumberCreate(NULL, kCFNumberFloat32Type, &gamma); break; +case AVCOL_TRC_IEC61966_2_1: +*transfer_fnc = kCVImageBufferTransferFunction_sRGB; +break; + case AVCOL_TRC_BT2020_10: case AVCOL_TRC_BT2020_12: *transfer_fnc = compat_keys.kCVImageBufferTransferFunction_ITU_R_2020; -- 2.30.1 (Apple Git-130) ___ 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/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Thu, 2021-07-15 at 03:49 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > James Almer > > Sent: Thursday, 15 July 2021 05:21 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > d3d11va support, added mfxhdlpair > > > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Xiang, Haihao > > > > Sent: Thursday, 15 July 2021 04:35 > > > > To: ffmpeg-devel@ffmpeg.org > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > > > d3d11va support, added mfxhdlpair > > > > > > > > On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > > > > On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > > > > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > > > > > > > > wrote: > > > > > > > > > > > > > Adding DX11 relevant device type checks and adjusting callbacks > > > > > > > with proper MediaSDK pair type support. > > > > > > > > > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > > > > > > > > > Signed-off-by: Artem Galin . > > > > > > > > > > > > > > > > > > Patchset obviously closes the gap of DirectX 11 support and already > > > > > > checked with several apps that use FFMPEG. > > > > > > > > > > > > Any particular review comments should be yet expected? > > > > > > > > > > > > Changes seem to be straight forward and incorporate prev. comments. > > > > > > > > > > > > thank in advance > > > > > > > > > > > > regards > > > > > > Max > > > > > > > > > > There are some issues pointed out by Soft Works related to switching > > > > > the default to DX11 breaking existing command lines with DX9, plus > > > > > an OpenCL<->QSV interop regression this would introduce that > > > > > according to him should be easy to fix. > > > > > > > > > > If those are addressed, the set should be good. > > > > > > > > If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > > > > June/281778.html > > > > (qsvdec: add support for HW_DEVICE_CTX method) first, we should be > > > > able to use the common device stuff to initialize d3d11va device for > > > > QSV and needn't use child_device_type to specify child device. > > > > > > There's no doubt that the new method will be better, but the point is not > > > > to break existing command lines. From my experience, ffmpeg usually avoids > > to break established command line patterns, which is a good thing imo. > > > > > > Anything more official than my perception? Please feel free to chime > > > in... ;-) > > > > That patch appears to attempt to maintain support for existing command > > lines for a deprecation period, something we've done before with other > > hwaccels like cuvid, so if it's really better, it's fine and acceptable. > > ^ > > Hi James, > > "That patch" that preserves compatibility doesn't exist yet. We need to make > sure that command lines using the '--child_device' parameter will continue to > work, while Haihao's patch will be the "future way": > > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv@d3d11va > > The new behaviour that is introduced by this patch is that an initialized hw > device can now be applied to qsv decoders (currently only to filter graphs and > qsv encoders). '-init_hw_device qsv=qsv:hw,child_device=xxx' still works, e.g. /dev/dri/renderD129 is used for both qsv decoder and encoder on Linux when running the command below on a HW with multiple GPUs. $> ffmpeg -y -init_hw_device qsv=qsv:hw,child_device=/dev/dri/renderD129 -hwaccel qsv -c:v hevc_qsv -i input.265 -c:v hevc_qsv -f rawvideo out.h265 > > Additionally, the default should remain to be D3D9 (if none of the above is > specified) as laid out earlier - again for maintaining compatibility but also > for better robustness and performance. We may refine Artem's patch to make sure the default is D3D9 on Microsoft windows when both dxva2 and d3d11va are enabled if applying my patch first. Thanks Haihao > > PS: Regarding the OpenCL regression you mentioned, I had already submitted the > patch to Intel and they have added it to their staging-repo for ffmpeg > patches: > https://github.com/intel-media-ci/cartwheel-ffmpeg/commit/7456b1ac0d385acc6d2851470c1b04ab3780adf8 > > Kind regards, > softworkz > > > > ___ > 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 v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
> -Original Message- > From: ffmpeg-devel On Behalf Of > Xiang, Haihao > Sent: Thursday, 15 July 2021 07:43 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > d3d11va support, added mfxhdlpair > > On Thu, 2021-07-15 at 03:49 +, Soft Works wrote: > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > James Almer > > > Sent: Thursday, 15 July 2021 05:21 > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > > d3d11va support, added mfxhdlpair > > > > > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On > Behalf > > > > > Of Xiang, Haihao > > > > > Sent: Thursday, 15 July 2021 04:35 > > > > > To: ffmpeg-devel@ffmpeg.org > > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: > > > > > enabling d3d11va support, added mfxhdlpair > > > > > > > > > > On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > > > > > On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > > > > > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Adding DX11 relevant device type checks and adjusting > > > > > > > > callbacks with proper MediaSDK pair type support. > > > > > > > > > > > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > > > > > > > > > > > Signed-off-by: Artem Galin . > > > > > > > > > > > > > > > > > > > > > Patchset obviously closes the gap of DirectX 11 support and > > > > > > > already checked with several apps that use FFMPEG. > > > > > > > > > > > > > > Any particular review comments should be yet expected? > > > > > > > > > > > > > > Changes seem to be straight forward and incorporate prev. > comments. > > > > > > > > > > > > > > thank in advance > > > > > > > > > > > > > > regards > > > > > > > Max > > > > > > > > > > > > There are some issues pointed out by Soft Works related to > > > > > > switching the default to DX11 breaking existing command lines > > > > > > with DX9, plus an OpenCL<->QSV interop regression this would > > > > > > introduce that according to him should be easy to fix. > > > > > > > > > > > > If those are addressed, the set should be good. > > > > > > > > > > If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > > > > > June/281778.html > > > > > (qsvdec: add support for HW_DEVICE_CTX method) first, we should > > > > > be able to use the common device stuff to initialize d3d11va > > > > > device for QSV and needn't use child_device_type to specify child > device. > > > > > > > > There's no doubt that the new method will be better, but the point > > > > is not > > > > > > to break existing command lines. From my experience, ffmpeg usually > > > avoids to break established command line patterns, which is a good thing > imo. > > > > > > > > Anything more official than my perception? Please feel free to > > > > chime in... ;-) > > > > > > That patch appears to attempt to maintain support for existing > > > command lines for a deprecation period, something we've done before > > > with other hwaccels like cuvid, so if it's really better, it's fine and > acceptable. > > > > ^ > > > > Hi James, > > > > "That patch" that preserves compatibility doesn't exist yet. We need > > to make sure that command lines using the '--child_device' parameter > > will continue to work, while Haihao's patch will be the "future way": > > > > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv@d3d11va > > > > The new behaviour that is introduced by this patch is that an > > initialized hw device can now be applied to qsv decoders (currently > > only to filter graphs and qsv encoders). > > '-init_hw_device qsv=qsv:hw,child_device=xxx' still works, Sure - that needs to work anyway. What I meant is the -qsv_device parameter, which is a global-scope param and takes a device path on Linux or the D3D adapter ID on Windows. ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -c:v h264_qsv -i input.mp4 -c:v h264_qsv output.mp4 For my implementation I had added an additional global parameter (--qsv_use_dx11). When it is set, the -qsv_device parameter indicates a DXGI adapter id rather than a D3D adapter. But let's forget about that. The init_hw_device approach is much better, and -qsv_device should just keep working like before. I'm currently rebasing all our patches to the latest ffmpeg; probably tomorrow I'll check out your patch. > > Additionally, the default should remain to be D3D9 (if none of the > > above is > > specified) as laid out earlier - again for maintaining compatibility > > but also for better robustness and performance. > > We may refine Artem's patch to make sure the default is D3D9 on Microsoft > windows Sounds good. > when both dxva2 and d3d11va are enabled if applying my patch > first. Not sure what you mean by that. Kind regards, softwo
