[FFmpeg-devel] [PATCH] avformat/libsrt: workaround conflict with ffmpeg cmdline option
Add 'srt_streamid' option as an alias for 'streamid'.
---
doc/protocols.texi | 3 +++
libavformat/libsrt.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 8371f83059..8b21ce046e 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1558,6 +1558,9 @@ This option doesn’t make sense in Rendezvous connection;
the result
might be that simply one side will override the value from the other
side and it’s the matter of luck which one would win
+@item srt_streamid=@var{string}
+Alias for @samp{streamid} to avoid conflict with ffmpeg command line option.
+
@item smoother=@var{live|file}
The type of Smoother used for the transmission for that socket, which
is responsible for the transmission and congestion control. The Smoother
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 6ea6c35c53..afbf01fc87 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -134,6 +134,7 @@ static const AVOption libsrt_options[] = {
{ "lossmaxttl", "Maximum possible packet reorder tolerance",
OFFSET(lossmaxttl), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, INT_MAX, .flags = D|E },
{ "minversion", "The minimum SRT version that is required from the
peer", OFFSET(minversion), AV_OPT_TYPE_INT, { .i64 =
-1 }, -1, INT_MAX, .flags = D|E },
{ "streamid", "A string of up to 512 characters that an Initiator
can pass to a Responder", OFFSET(streamid), AV_OPT_TYPE_STRING, { .str =
NULL }, .flags = D|E },
+{ "srt_streamid", "A string of up to 512 characters that an Initiator
can pass to a Responder", OFFSET(streamid), AV_OPT_TYPE_STRING, { .str =
NULL }, .flags = D|E },
{ "smoother", "The type of Smoother used for the transmission for
that socket", OFFSET(smoother), AV_OPT_TYPE_STRING, { .str =
NULL }, .flags = D|E },
{ "messageapi", "Enable message API",
OFFSET(messageapi), AV_OPT_TYPE_BOOL, { .i64 = -1 },
-1, 1, .flags = D|E },
{ "transtype", "The transmission type for the socket",
OFFSET(transtype),AV_OPT_TYPE_INT, { .i64 =
SRTT_INVALID }, SRTT_LIVE, SRTT_INVALID, .flags = D|E, "transtype" },
--
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 v2 1/2] avformat/libsrt: send message in order
From: Zhao Zhili
There is no good use case for out of order delivery of data. For live
streaming with TSBPD enabled by default, the receiver get data in order
based on the timestamps. However, if TSBPD is disabled, the data can
be delivered out of order.
---
libavformat/libsrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index afbf01fc87..5298725ad5 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -690,7 +690,7 @@ static int libsrt_write(URLContext *h, const uint8_t *buf,
int size)
return ret;
}
-ret = srt_sendmsg(s->fd, buf, size, -1, 0);
+ret = srt_sendmsg(s->fd, buf, size, -1, 1);
if (ret < 0) {
ret = libsrt_neterrno(h);
}
--
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 v2 2/2] avformat/libsrt: add tsbpd option
From: Zhao Zhili
---
v2: update doc
doc/protocols.texi | 5 +
libavformat/libsrt.c | 5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 8b21ce046e..d3095c88c6 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1610,6 +1610,11 @@ Default is -1. -1 means auto (off with 0 seconds in live
mode, on with 180
seconds in file mode). The range for this option is integers in the
0 - @code{INT_MAX}.
+@item tsbpd=@var{1|0}
+When true, use Timestamp-based Packet Delivery mode. The default behavior
+depends on the transmission type: enabled in live mode, disabled in file
+mode.
+
@end table
For more information see: @url{https://github.com/Haivision/srt}.
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 5298725ad5..d02b7a95ec 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -90,6 +90,7 @@ typedef struct SRTContext {
int messageapi;
SRT_TRANSTYPE transtype;
int linger;
+int tsbpd;
} SRTContext;
#define D AV_OPT_FLAG_DECODING_PARAM
@@ -141,6 +142,7 @@ static const AVOption libsrt_options[] = {
{ "live", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = SRTT_LIVE },
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
{ "file", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = SRTT_FILE },
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
{ "linger", "Number of seconds that the socket waits for unsent
data when closing", OFFSET(linger), AV_OPT_TYPE_INT, { .i64 = -1
}, -1, INT_MAX, .flags = D|E },
+{ "tsbpd", "Timestamp-based packet delivery",
OFFSET(tsbpd),AV_OPT_TYPE_BOOL, { .i64 = -1 },
-1, 1, .flags = D|E },
{ NULL }
};
@@ -356,7 +358,8 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
#endif
(s->messageapi >= 0 && libsrt_setsockopt(h, fd, SRTO_MESSAGEAPI,
"SRTO_MESSAGEAPI", &s->messageapi, sizeof(s->messageapi)) < 0) ||
(s->payload_size >= 0 && libsrt_setsockopt(h, fd, SRTO_PAYLOADSIZE,
"SRTO_PAYLOADSIZE", &s->payload_size, sizeof(s->payload_size)) < 0) ||
-((h->flags & AVIO_FLAG_WRITE) && libsrt_setsockopt(h, fd, SRTO_SENDER,
"SRTO_SENDER", &yes, sizeof(yes)) < 0)) {
+((h->flags & AVIO_FLAG_WRITE) && libsrt_setsockopt(h, fd, SRTO_SENDER,
"SRTO_SENDER", &yes, sizeof(yes)) < 0) ||
+(s->tsbpd >= 0 && libsrt_setsockopt(h, fd, SRTO_TSBPDMODE,
"SRTO_TSBPDMODE", &s->tsbpd, sizeof(s->tsbpd)) < 0)) {
return AVERROR(EIO);
}
--
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] libavformat/movenc: Support encryption of H265 stream in AnnexB format
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of ?
> ?
> Sent: Friday, June 4, 2021 9:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] libavformat/movenc: Support encryption of
> H265 stream in AnnexB format
>
>
> Ping.
>
> This change is quite simple and should be quick to review. Feel free to ask
> any questions
Looks good to me
Eran
> пн, 22 мар. 2021 г. в 11:29, Вадим Бездушный :
>
> > Ping.
> >
> > чт, 11 мар. 2021 г. в 10:14, Вадим Бездушный :
> >
> >> Ping.
> >>
> >> вт, 9 мар. 2021 г. в 00:05, Вадим Бездушный :
> >>
> >>> Ping.
> >>>
> >>> This change is quite simple and should be quick to review. Feel free
> >>> to ask any questions
> >>>
> >>> On Mon, 1 Mar 2021, 14:54 Vadym Bezdushnyi,
> >>>
> >>> wrote:
> >>>
> Add an ability to accept H265 AnnexB stream at encryption similar
> to how its done for H264 AnnexB stream.
>
> Steps to test:
>
> 1. Create h265 test files - mp4 and h265 AnnexB streams:
> ffmpeg -f lavfi -i testsrc=duration=10:size=640x480:rate=30 -c:v
> hevc
> input_h265.mp4
> ffmpeg -f lavfi -i testsrc=duration=10:size=640x480:rate=30 -c:v
> hevc -bsf:v hevc_mp4toannexb input_h265.h265
>
> 2. Encrypt and decrypt files. Put appropriate input file name here:
> input_h265.mp4 or input_h265.h265
> ffmpeg -i input_h265.h265 -vcodec copy -acodec copy
> -encryption_scheme cenc-aes-ctr \ -encryption_key
> -encryption_kid
> \
> encrypted_h265.mp4
> ffplay -i encrypted_h265.mp4 -decryption_key
>
>
> Signed-off-by: Vadym Bezdushnyi
> ---
> libavformat/movenc.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c index
> 545b0885ae..0433968cd2 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -5685,7 +5685,15 @@ int ff_mov_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> return ret;
> avio_write(pb, reformatted_data, size);
> } else {
> -size = ff_hevc_annexb2mp4(pb, pkt->data, pkt->size, 0,
> NULL);
> +if (trk->cenc.aes_ctr) {
> +size = ff_mov_cenc_avc_parse_nal_units(&trk->cenc,
> + pb,
> pkt->data, size);
> +if (size < 0) {
> +ret = size;
> +goto err;
> +}
> +} else {
> +size = ff_hevc_annexb2mp4(pb, pkt->data,
> + pkt->size, 0,
> NULL);
> +}
> }
> } else if (par->codec_id == AV_CODEC_ID_AV1) {
> if (trk->hint_track >= 0 && trk->hint_track <
> mov->nb_streams) { @@ -5727,6 +5735,9 @@ int
> ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
> if (par->codec_id == AV_CODEC_ID_H264 &&
> par->extradata_size > 4) {
> int nal_size_length = (par->extradata[4] & 0x3) + 1;
> ret = ff_mov_cenc_avc_write_nal_units(s,
> &trk->cenc, nal_size_length, pb, pkt->data, size);
> +} else if(par->codec_id == AV_CODEC_ID_HEVC &&
> par->extradata_size > 21) {
> +int nal_size_length = (par->extradata[21] & 0x3) + 1;
> +ret = ff_mov_cenc_avc_write_nal_units(s,
> + &trk->cenc,
> nal_size_length, pb, pkt->data, size);
> } else {
> ret = ff_mov_cenc_write_packet(&trk->cenc, pb,
> pkt->data, size);
> }
> @@ -6711,7 +6722,8 @@ static int mov_init(AVFormatContext *s)
>
> if (mov->encryption_scheme == MOV_ENC_CENC_AES_CTR) {
> ret = ff_mov_cenc_init(&track->cenc, mov->encryption_key,
> -track->par->codec_id == AV_CODEC_ID_H264, s->flags &
> AVFMT_FLAG_BITEXACT);
> +(track->par->codec_id == AV_CODEC_ID_H264 ||
> track->par->codec_id == AV_CODEC_ID_HEVC),
> +s->flags & AVFMT_FLAG_BITEXACT);
> if (ret)
> return ret;
> }
> --
> 2.30.0
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=04%7C01%7C%7C724744e3bfed40c5995508d92725c852%7C0c503748de3f4e2597e26819d53a42b6%7C1%7C1%7C637583865496478909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=l2rO0HEmDBCJ8RdN3keR0oGE1IZub2TZeN4o%2FdJKcfM%3D&reserved=0
>
> To unsubscribe, visit link above,
Re: [FFmpeg-devel] [PATCH] avdevice/avdevice: Deprecate AVDevice Capabilities API
Diederick C. Niehorster (12021-06-04): > Just sent the patch, it completes my push together with my other > patches of the last few days to make the dshow device fully > programmatically controllable and discoverable. > > By the way, each of these patch series applies to master, but not on > top of each other (there'd be massive conflicts). What is custom? > Should i instead send them all as one large patch series? I do not understand: you did send them as a large patch series. Twice, by the way, which is confusing. It is the way to do it: make clean commits in your Git tree, using rebase if necessary to make them really clean. Then let git format-patch or send-email make a patch series, with each patch stacking on top of the other. 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] avformat/flvdec: Ignore the first two data/subtitle streams.
On Thu, 13 May 2021, Josh Allmann wrote:
Previously, one or the other would have been ignored, but not both.
Since the probe terminates at three streams, it could exit
prematurely if both data and subtitles are present along with
slightly trailing media, usually video trailing audio.
Trailing media is common in RTMP, and encoders write strange metadata.
---
libavformat/flvdec.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4b9f46902b..1be8d98618 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -134,18 +134,32 @@ static void add_keyframes_index(AVFormatContext *s)
}
}
+static int is_ignorable(enum AVMediaType codec_type)
+{
+switch(codec_type) {
+case AVMEDIA_TYPE_SUBTITLE:
+case AVMEDIA_TYPE_DATA:
+return 1;
+}
+return 0;
+}
+
static AVStream *create_stream(AVFormatContext *s, int codec_type)
{
+int streams_to_ignore = 0, nb_streams = 0;
FLVContext *flv = s->priv_data;
AVStream *st = avformat_new_stream(s, NULL);
if (!st)
return NULL;
st->codecpar->codec_type = codec_type;
-if (s->nb_streams>=3 ||( s->nb_streams==2
- && s->streams[0]->codecpar->codec_type !=
AVMEDIA_TYPE_SUBTITLE
- && s->streams[1]->codecpar->codec_type !=
AVMEDIA_TYPE_SUBTITLE
- && s->streams[0]->codecpar->codec_type !=
AVMEDIA_TYPE_DATA
- && s->streams[1]->codecpar->codec_type !=
AVMEDIA_TYPE_DATA))
+
+if (s->nb_streams >= 1)
+streams_to_ignore += is_ignorable(s->streams[0]->codecpar->codec_type);
+if (s->nb_streams >= 2)
+streams_to_ignore += is_ignorable(s->streams[1]->codecpar->codec_type);
+
+nb_streams = s->nb_streams - streams_to_ignore;
+if (nb_streams >= 2)
s->ctx_flags &= ~AVFMTCTX_NOHEADER;
Overall, the idea of the patch seems sensible, but it could be done
slightly differently...
Instead of explicitly inspecting streams [0] and [1], wouldn't it be more
straightforward to just loop over all existing streams and count the ones
where is_ignorable returns 0? Otherwise, if you'd have e.g. the streams
{audio, data, subtitle}, you'd still end up with nb_streams = 2 which
probably isn't what you meant?
Separately, it'd be great if you could, while touching this code, write
some comments about what's happening here - it's rather non-obvious code
(especially with the double negations, in clearing the NOHEADER flag, and
what that flag implies).
// 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] avformat: Add parityfec and ulpfec protocol
Hi,
On Fri, 9 Apr 2021, Camille Gonnet wrote:
Parityfec (RFC 2733) and ulpfec (RFC 5109) generic FEC encoding for RTP streams.
Signed-off-by: Camille Gonnet
---
Changelog | 1 +
doc/general_contents.texi | 1 +
doc/protocols.texi| 106 +
libavformat/Makefile | 1 +
libavformat/fecrtp.c | 884 ++
libavformat/protocols.c | 1 +
libavformat/rtpproto.c| 2 +-
7 files changed, 995 insertions(+), 1 deletion(-)
create mode 100644 libavformat/fecrtp.c
I had a brief look at this... I'm not familiar with how fec protocols are
hooked up and all that, but it does seem to follow the existing practice
for the prompg protocol.
Stylistically, the code could adhere a bit more to the ffmpeg style (it
misses space around operators in many places, random example:
+mask_clear=1<<(s->span-1); // This one is not in the xor
+idx=s->last_idx+1; // circular -> go first
The bitrev16/32 functions have incorrect indentation and odd spacing
("return((x >> 8 ..."). I wonder if we have any existing function that do
the same - as av_bswap* only swap bytes - maybe not...
The code uses a number of commented out av_log calls, which isn't
stylistically great... As they already are added with a low enough debug
level (AV_LOG_DEBUG) couldn't they be left in the code (so that they end
up compiled and syntax checked)?
I didn't try following the whole algorithm, but I had a peek at some
comments which I didn't quite understand, e.g. this one:
+int size; // size of the bitstring, so the bigger input packet
size
Is that a typo in the comment, or just something I'd understand if I'd
read the code more thoroughly?
// 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] avdevice/avdevice: Deprecate AVDevice Capabilities API
Hi Nicolas, On Fri, Jun 4, 2021 at 11:06 AM Nicolas George wrote: > I do not understand: you did send them as a large patch series. Twice, > by the way, which is confusing. Yes, the first series got messed up, send it a second time correctly. I've cleaned up patchwork, it only shows the right ones. I have sent multiple patch series, all of which apply cleanly to master, but some of which heavily conflict with each other. E.g. https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4090, https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4088 and https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4100 implement different features, but each heavily edit overlapping code. Once one is merged, the others will conflict. Should i put these all in one large series implementing multiple features? > It is the way to do it: make clean commits in your Git tree, using > rebase if necessary to make them really clean. Then let git format-patch > or send-email make a patch series, with each patch stacking on top of > the other. Thanks! send-email I have made some mistakes with my first times here, sorry again for the double patches. Cheers, Dee ___ 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] fftools/ffmpeg: remove usage of internal timestamp AVStream fields
On 6/1/2021 12:48 PM, James Almer wrote:
They should not be accessed outside of libavformat.
Signed-off-by: James Almer
---
fftools/ffmpeg.c | 10 ++
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_opt.c | 1 +
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b3658d8f65..04ddc9e60b 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1168,7 +1168,7 @@ static void do_video_out(OutputFile *of,
if (frame_rate.num > 0 && frame_rate.den > 0)
duration = 1/(av_q2d(frame_rate) * av_q2d(enc->time_base));
-if(ist && ist->st->start_time != AV_NOPTS_VALUE && ist->st->first_dts != AV_NOPTS_VALUE && ost->frame_rate.num)
+if(ist && ist->st->start_time != AV_NOPTS_VALUE && ist->first_dts != AV_NOPTS_VALUE
&& ost->frame_rate.num)
duration = FFMIN(duration, 1/(av_q2d(ost->frame_rate) *
av_q2d(enc->time_base)));
if (!ost->filters_script &&
@@ -2625,9 +2625,11 @@ static int process_input_packet(InputStream *ist, const
AVPacket *pkt, int no_eo
avpkt = ist->pkt;
if (!ist->saw_first_ts) {
+ist->first_dts =
ist->dts = ist->st->avg_frame_rate.num ? - ist->dec_ctx->has_b_frames *
AV_TIME_BASE / av_q2d(ist->st->avg_frame_rate) : 0;
ist->pts = 0;
if (pkt && pkt->pts != AV_NOPTS_VALUE && !ist->decoding_needed) {
+ist->first_dts =
ist->dts += av_rescale_q(pkt->pts, ist->st->time_base,
AV_TIME_BASE_Q);
ist->pts = ist->dts; //unused but better to set it to a value
thats not totally wrong
}
@@ -3949,10 +3951,10 @@ static OutputStream *choose_output(void)
for (i = 0; i < nb_output_streams; i++) {
OutputStream *ost = output_streams[i];
-int64_t opts = ost->st->cur_dts == AV_NOPTS_VALUE ? INT64_MIN :
- av_rescale_q(ost->st->cur_dts, ost->st->time_base,
+int64_t opts = ost->last_mux_dts == AV_NOPTS_VALUE ? INT64_MIN :
+ av_rescale_q(ost->last_mux_dts, ost->st->time_base,
AV_TIME_BASE_Q);
-if (ost->st->cur_dts == AV_NOPTS_VALUE)
+if (ost->last_mux_dts == AV_NOPTS_VALUE)
av_log(NULL, AV_LOG_DEBUG,
"cur_dts is invalid st:%d (%d) [init:%d i_done:%d finish:%d] (this
is harmless if it occurs once at the start per stream)\n",
ost->st->index, ost->st->id, ost->initialized, ost->inputs_done,
ost->finished);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 606f2afe0c..e9d30fbd67 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -316,6 +316,7 @@ typedef struct InputStream {
/* predicted dts of the next packet read for this stream or (when there
are
* several frames in a packet) of the next frame in current packet (in
AV_TIME_BASE units) */
int64_t next_dts;
+int64_t first_dts; ///< dts of the first packet read for this stream
(in AV_TIME_BASE units)
int64_t dts; ///< dts of the last packet read for this stream
(in AV_TIME_BASE units)
int64_t next_pts; ///< synthetic pts for the next decode frame (in AV_TIME_BASE units)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 849d24b16d..a63bed54cf 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -809,6 +809,7 @@ static void add_input_streams(OptionsContext *o,
AVFormatContext *ic)
ist->discard = 1;
st->discard = AVDISCARD_ALL;
ist->nb_samples = 0;
+ist->first_dts = AV_NOPTS_VALUE;
ist->min_pts = INT64_MAX;
ist->max_pts = INT64_MIN;
Will apply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7] avcodec/nvenc: write out user data unregistered SEI
Pushed a very much refactored version of this patch and some more refactoring on top of it. It still shows the crash, but both the previous code and this code seem fine to me in that regard. 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] avcodec: Pass the HDR10+ metadata to the packet side data in VP9 encoder
Hi, On Wed, Jun 2, 2021 at 1:55 PM Valerii Zapodovnikov wrote: > > HDR10+ test bitstream https://www.webmproject.org/vp9/levels/ > > BTW, who knows what is Profile 4 VP9 (i.e. VP9.4)? > https://stackoverflow.com/questions/61413665 > This link is talking about a file with DRM. VP9 allows for 4 profiles, 0-3: https://www.webmproject.org/vp9/profiles/ It would be better to start another thread if you have questions around VP9 profiles and levels. webm-disc...@webmproject.org can be used for this. ___ 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] avdevice/avdevice: Deprecate AVDevice Capabilities API
Hi All, If instead of the various separate patch series i have sent the last few days, you would like to see one integrated series where all are applied on top of each other and conflicts resolves, please see all the commits ahead of master (currently 22) on the develop branch here: https://github.com/dcnieho/ffmpeg/tree/develop In making this branch, i have also done some small refactoring, and fixed some issues i came across in my implementation. As said before, I hope one of you can advise me on how to submit all this (one big series so it all applies cleanly?). The brunt is letting dshow provide more information about what video data it provides, and especially making it way more controllable programmatically/through the API. It is now at a point where i can use ffmpeg/dshow as a backend to flexible, reconfigurable use of e.g. a webcam. Exciting to me:) All the best, Dee On Fri, Jun 4, 2021 at 2:22 PM Diederick C. Niehorster wrote: > > Hi Nicolas, > > On Fri, Jun 4, 2021 at 11:06 AM Nicolas George wrote: > > I do not understand: you did send them as a large patch series. Twice, > > by the way, which is confusing. > > Yes, the first series got messed up, send it a second time correctly. > I've cleaned up patchwork, it only shows the right ones. > > I have sent multiple patch series, all of which apply cleanly to > master, but some of which heavily conflict with each other. E.g. > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4090, > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4088 and > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4100 > implement different features, but each heavily edit overlapping code. > Once one is merged, the others will conflict. Should i put these all > in one large series implementing multiple features? > > > It is the way to do it: make clean commits in your Git tree, using > > rebase if necessary to make them really clean. Then let git format-patch > > or send-email make a patch series, with each patch stacking on top of > > the other. > > Thanks! send-email I have made some mistakes with my first times here, > sorry again for the double patches. > > Cheers, > Dee ___ 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] avdevice/avdevice: Deprecate AVDevice Capabilities API
You may want to wait for at least some review and then of course, Andreas, for example, sometimes sends 200 patch series. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201203003628.778278-6-andreas.rheinha...@gmail.com/ ___ 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: Pass the HDR10+ metadata to the packet side data in VP9 encoder
Yeah, 0 to 3, but this is 4. We are counting from 0, not from 1. So that would be some kind of fifth profile. ___ 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] avfilter/vf_hqdn3d: fix left shift of negative numbers
пн, 24 мая 2021 г., 6:42 Valerii Zapodovnikov : > --- > libavfilter/vf_hqdn3d.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/vf_hqdn3d.c b/libavfilter/vf_hqdn3d.c > index 8d71ae316d..bd3eb2d01c 100644 > --- a/libavfilter/vf_hqdn3d.c > +++ b/libavfilter/vf_hqdn3d.c > @@ -179,7 +179,7 @@ static void precalc_coefs(double dist25, int depth, > int16_t *ct) > > gamma = log(0.25) / log(1.0 - FFMIN(dist25,252.0)/255.0 - 0.1); > > -for (i = -256< +for (i = -(256< double f = ((i<<(9-LUT_BITS)) + (1<<(8-LUT_BITS)) - 1) / 512.0; > // midpoint of the bin > simil = FFMAX(0, 1.0 - fabs(f) / 255.0); > C = pow(simil, gamma) * 256.0 * f; > -- > 2.30.2 > 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".
[FFmpeg-devel] [PATCH v2] lavc/aomdec: Allow RGB decoding
Yes, RGB is signalled by Identity matrix if and only if XYZ is not
in transfer. XYZ primaires are just normal primaries that can be
used for normal RGB, no problem, so I do not check for them.
No need to test for sRGB primaries (that is AVCOL_PRI_BT709), as
ffplay does not know what that is (is not color managed), but mpv
will do that automatically. This will also support other transfers
like DCI-P3 / DCI-D65 one, et cetera. See libvpxdec.c.
Also the default AV1 decoder is libdav1d, which is not affected.
For XYZ support someone should add correct pixel format in the code.
---
libavcodec/libaomdec.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 6e7324a832..156e644263 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -134,15 +134,27 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
aom_image *img)
case AOM_IMG_FMT_I444:
case AOM_IMG_FMT_I44416:
if (img->bit_depth == 8) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P;
+}
avctx->profile = FF_PROFILE_AV1_HIGH;
return 0;
} else if (img->bit_depth == 10) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP10;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
+}
avctx->profile = FF_PROFILE_AV1_HIGH;
return 0;
} else if (img->bit_depth == 12) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP12;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
+}
avctx->profile = FF_PROFILE_AV1_PROFESSIONAL;
return 0;
} else {
--
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] avcodec/ccaption_dec: Make real-time latency configurable v2
v2 is done by "git send-email -v2 -1" not what you did here. ___ 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] avcodec/nvenc: write out user data unregistered SEI
On Saturday, 5 June 2021 2:49:01 AM AEST Timo Rothenpieler wrote: > Pushed a very much refactored version of this patch and some more > refactoring on top of it. > > It still shows the crash, but both the previous code and this code seem > fine to me in that regard. Thanks for the work, and the guidance along the journey. Brad ___ 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/ccaption_dec: Make real-time latency configurable v2
On Fri, Jun 4, 2021 at 4:56 PM Valerii Zapodovnikov wrote: > v2 is done by "git send-email -v2 -1" not what you did here. > Thanks, I didn't know that. I am unclear -- do you want me to resubmit the patch? I can just apply and push it myself if there are no objections, although I am not the maintainer of ccaption_dec.c so IDK if that would be inappropriate. Pavel. ___ 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/matroskaenc: Allow changing the time stamp precision via option
Michael Fabian 'Xaymar' Dirks:
> On 2021-05-24 22:15, Andreas Rheinhardt wrote:
>> michael.di...@xaymar.com:
>>> From: Michael Fabian 'Xaymar' Dirks
>>>
>>> Adds "timestamp_precision" to the available options for Matroska muxing.
>>> The option enables users and developers to change the precision of the
>>> time stamps in the Matroska container up to 1 nanosecond, which can aid
>>> with the proper detection of constant and variable rate content.
>>>
>>> Work-around fix for: 259, 6406, 7927, 8909 and 9124.
>>>
>>> Signed-off-by: Michael Fabian 'Xaymar' Dirks
>>> ---
>>> doc/muxers.texi | 8
>>> libavformat/matroskaenc.c | 33 ++---
>>> 2 files changed, 34 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index e1c6ad0829..8655be94ff 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -1583,6 +1583,14 @@ bitmap is stored bottom-up. Note that this
>>> option does not flip the bitmap
>>> which has to be done manually beforehand, e.g. by using the vflip
>>> filter.
>>> Default is @var{false} and indicates bitmap is stored top down.
>>> +@item timestamp_precision
>>> +Sets the timestamp precision up to 1 nanosecond for Matroska/WebM,
>>> which can
>>> +improve detection of constant rate content in demuxers. Note that
>>> some poorly
>>> +implemented demuxers may require a timestamp precision of 1
>>> millisecond, so
>>> +increasing it past that point may result in playback issues. Higher
>>> precision
>>> +also reduces the maximum possible timestamp significantly.
>> This should mention that a too high precision will increase container
>> overhead.
> Good point.
>>
>>> +Default is @var{1/1000} (1 millisecond).
>>> +
>>> @end table
>>> @anchor{md5}
>>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>>> index 186a25d920..1b911a648c 100644
>>> --- a/libavformat/matroskaenc.c
>>> +++ b/libavformat/matroskaenc.c
>>> @@ -158,6 +158,8 @@ typedef struct MatroskaMuxContext {
>>> int default_mode;
>>> uint32_t segment_uid[4];
>>> +
>>> + AVRational time_base;
>>> } MatroskaMuxContext;
>>> /** 2 bytes * 7 for EBML IDs, 7 1-byte EBML lengths, 6 1-byte uint,
>>> @@ -1814,6 +1816,7 @@ static int mkv_write_header(AVFormatContext *s)
>>> const AVDictionaryEntry *tag;
>>> int ret, i, version = 2;
>>> int64_t creation_time;
>>> + int64_t time_base = 1;
>>> if (mkv->mode != MODE_WEBM ||
>>> av_dict_get(s->metadata, "stereo_mode", NULL, 0) ||
>>> @@ -1850,7 +1853,10 @@ static int mkv_write_header(AVFormatContext *s)
>>> return ret;
>>> pb = mkv->info.bc;
>>> - put_ebml_uint(pb, MATROSKA_ID_TIMECODESCALE, 100);
>>> + time_base = av_rescale_q(time_base, mkv->time_base,
>>> (AVRational){1, 10});
>>> + av_log(s, AV_LOG_DEBUG, "TimestampScale is: %" PRId64 " ns\n",
>>> time_base);
>>> + put_ebml_uint(pb, MATROSKA_ID_TIMECODESCALE, time_base);
>> There is a serious problem here: mkv->time_base is the time base that
>> the muxer uses; yet if mkv->time_base is not a multiple of 1/10,
>> then av_rescale_q will have to round a bit and then the demuxer will
>> read a different time base, leading to a drift of all timestamps. This
>> is not acceptable.
> This issue is already present in the current version of FFmpeg.
Matroska's timestamp imprecision currently lead to jitter, but not to
drift (this of course presumes that one actually uses the timestamps
as-is (instead of summing the durations)). But your patch as-is can lead
to drift (when using a wrong timebase), because it adds a whole new type
of error: One in which the demuxer and the muxer disagree about the
timebase that is in use. Consider a user using 1/75000 as timebase.
48kHz audio (with a timebase of 1/48000) can be converted accurately to
it, so that the muxer receives precise timestamps. Yet the muxer
actually writes that the timebase is 1/10 and that is what a
demuxer sees. This means that all timestamps (except those for which
Matroska uses "absolute timestamps" (Matroska-speak for a time/duration
that is always in 1/10 like default duration)) are skewed as-if
multiplied by 3/4.
> Unfortunately even if you tell me this, this is not something I can
> change: Matroska uses nanosecond precision, and nobody has agreed on
> what the way forward for timestamps is. You will have to bring up such
> nanosecond-precision problems with the Matroska specification
> maintainers itself, which are currently seeking IETF standardization:
> https://github.com/ietf-wg-cellar/matroska-specification/issues/422
>>
Already did so (I am mkver).
>>> +
>>> if ((tag = av_dict_get(s->metadata, "title", NULL, 0)))
>>> put_ebml_string(pb, MATROSKA_ID_TITLE, tag->value);
>>> if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
>>> @@ -1883,11 +1889,11 @@ static int mkv_write_header(AVFormatCon
Re: [FFmpeg-devel] [PATCH 4/4] examples: adding device_get_capabilities example
Diederick Niehorster: > Signed-off-by: Diederick Niehorster > --- > configure | 2 + > doc/examples/.gitignore| 1 + > doc/examples/Makefile | 47 > doc/examples/Makefile.example | 1 + > doc/examples/device_get_capabilities.c | 151 + > 5 files changed, 179 insertions(+), 23 deletions(-) > create mode 100644 doc/examples/device_get_capabilities.c > > diff --git a/configure b/configure > index 82367fd30d..5e9666d017 100755 > --- a/configure > +++ b/configure > @@ -1705,6 +1705,7 @@ EXAMPLE_LIST=" > decode_audio_example > decode_video_example > demuxing_decoding_example > +device_get_capabilities_example > encode_audio_example > encode_video_example > extract_mvs_example > @@ -3712,6 +3713,7 @@ avio_reading_deps="avformat avcodec avutil" > decode_audio_example_deps="avcodec avutil" > decode_video_example_deps="avcodec avutil" > demuxing_decoding_example_deps="avcodec avformat avutil" > +device_get_capabilities_example_deps="avdevice avformat avutil" > encode_audio_example_deps="avcodec avutil" > encode_video_example_deps="avcodec avutil" > extract_mvs_example_deps="avcodec avformat avutil" > diff --git a/doc/examples/.gitignore b/doc/examples/.gitignore > index 44960e1de7..256f33a600 100644 > --- a/doc/examples/.gitignore > +++ b/doc/examples/.gitignore > @@ -3,6 +3,7 @@ > /decode_audio > /decode_video > /demuxing_decoding > +/device_get_capabilities > /encode_audio > /encode_video > /extract_mvs > diff --git a/doc/examples/Makefile b/doc/examples/Makefile > index 81bfd34d5d..7988ed4226 100644 > --- a/doc/examples/Makefile > +++ b/doc/examples/Makefile > @@ -1,26 +1,27 @@ > -EXAMPLES-$(CONFIG_AVIO_LIST_DIR_EXAMPLE) += avio_list_dir > -EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE) += avio_reading > -EXAMPLES-$(CONFIG_DECODE_AUDIO_EXAMPLE) += decode_audio > -EXAMPLES-$(CONFIG_DECODE_VIDEO_EXAMPLE) += decode_video > -EXAMPLES-$(CONFIG_DEMUXING_DECODING_EXAMPLE) += demuxing_decoding > -EXAMPLES-$(CONFIG_ENCODE_AUDIO_EXAMPLE) += encode_audio > -EXAMPLES-$(CONFIG_ENCODE_VIDEO_EXAMPLE) += encode_video > -EXAMPLES-$(CONFIG_EXTRACT_MVS_EXAMPLE) += extract_mvs > -EXAMPLES-$(CONFIG_FILTER_AUDIO_EXAMPLE) += filter_audio > -EXAMPLES-$(CONFIG_FILTERING_AUDIO_EXAMPLE) += filtering_audio > -EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE) += filtering_video > -EXAMPLES-$(CONFIG_HTTP_MULTICLIENT_EXAMPLE) += http_multiclient > -EXAMPLES-$(CONFIG_HW_DECODE_EXAMPLE) += hw_decode > -EXAMPLES-$(CONFIG_METADATA_EXAMPLE) += metadata > -EXAMPLES-$(CONFIG_MUXING_EXAMPLE)+= muxing > -EXAMPLES-$(CONFIG_QSVDEC_EXAMPLE)+= qsvdec > -EXAMPLES-$(CONFIG_REMUXING_EXAMPLE) += remuxing > -EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE) += resampling_audio > -EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video > -EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac > -EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE) += transcoding > -EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode > -EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE) += vaapi_transcode > +EXAMPLES-$(CONFIG_AVIO_LIST_DIR_EXAMPLE) += avio_list_dir > +EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE) += avio_reading > +EXAMPLES-$(CONFIG_DECODE_AUDIO_EXAMPLE) += decode_audio > +EXAMPLES-$(CONFIG_DECODE_VIDEO_EXAMPLE) += decode_video > +EXAMPLES-$(CONFIG_DEMUXING_DECODING_EXAMPLE) += demuxing_decoding > +EXAMPLES-$(CONFIG_DEVICE_GET_CAPABILITIES_EXAMPLE) += > device_get_capabilities > +EXAMPLES-$(CONFIG_ENCODE_AUDIO_EXAMPLE) += encode_audio > +EXAMPLES-$(CONFIG_ENCODE_VIDEO_EXAMPLE) += encode_video > +EXAMPLES-$(CONFIG_EXTRACT_MVS_EXAMPLE) += extract_mvs > +EXAMPLES-$(CONFIG_FILTER_AUDIO_EXAMPLE) += filter_audio > +EXAMPLES-$(CONFIG_FILTERING_AUDIO_EXAMPLE) += filtering_audio > +EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE) += filtering_video > +EXAMPLES-$(CONFIG_HTTP_MULTICLIENT_EXAMPLE) += http_multiclient > +EXAMPLES-$(CONFIG_HW_DECODE_EXAMPLE) += hw_decode > +EXAMPLES-$(CONFIG_METADATA_EXAMPLE) += metadata > +EXAMPLES-$(CONFIG_MUXING_EXAMPLE)+= muxing > +EXAMPLES-$(CONFIG_QSVDEC_EXAMPLE)+= qsvdec > +EXAMPLES-$(CONFIG_REMUXING_EXAMPLE) += remuxing > +EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE) += resampling_audio > +EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video > +EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac > +EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE) += transcoding > +EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode > +EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE) += vaapi_transcode > Moving everything to
