Re: [FFmpeg-devel] [PATCH 4/5] avformat/rmdec: remove unneeded memset() on packet allocation
On Mon, Nov 02, 2020 at 01:47:25AM +0100, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Signed-off-by: Michael Niedermayer > > --- > > libavformat/rmdec.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c > > index 9e954108f9..6a89143bc5 100644 > > --- a/libavformat/rmdec.c > > +++ b/libavformat/rmdec.c > > @@ -817,7 +817,6 @@ static int rm_assemble_video_frame(AVFormatContext *s, > > AVIOContext *pb, > > av_packet_unref(&vst->pkt); //FIXME this should be output. > > if ((ret = av_new_packet(&vst->pkt, vst->videobufsize)) < 0) > > return ret; > > -memset(vst->pkt.data, 0, vst->pkt.size); > > vst->videobufpos = 8*vst->slices + 1; > > vst->cur_slice = 0; > > vst->curpic_num = pic_num; > > > Sure that this does not lead to uninitialized padding? Maybe use > av_shrink_packet() in line 852 instead of directly setting the size. hmm, av_shrink_packet() is a good idea either way so ill use that thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] libavformat/aviobuf: Forward error from avio_read in ffio_read_size()
On Sat, Oct 31, 2020 at 03:18:26PM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Suggested-by: Andreas Rheinhardt
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/aviobuf.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> > index 80a5a565a4..3cc440e4e7 100644
> > --- a/libavformat/aviobuf.c
> > +++ b/libavformat/aviobuf.c
> > @@ -686,6 +686,8 @@ int avio_read(AVIOContext *s, unsigned char *buf, int
> > size)
> > int ffio_read_size(AVIOContext *s, unsigned char *buf, int size)
> > {
> > int ret = avio_read(s, buf, size);
> > +if (ret < 0 && ret != AVERROR_EOF)
> > +return ret;
> > if (ret != size)
> > return AVERROR_INVALIDDATA;
> > return ret;
> >
> Maybe first check for ret == size. After all, that is supposed to be the
> common case.
ok, will do
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
signature.asc
Description: 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/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
On Mon, Nov 02, 2020 at 09:42:21PM +0100, Marton Balint wrote: > > > On Mon, 2 Nov 2020, Michael Niedermayer wrote: > > > > > Please correct me if iam wrong but > > > > in cases where no audio is missing or damaged, this would also ignore > > > > how much > > > > audio is in each packet. So you could have lets say a timestamp > > > > difference > > > > of excatly 1 second between 2 packets while their is actually not > > > > exactly > > > > 1 second worth of audio samples between them. > > > > > > This is true, by using the frame counter (and the video time base) for > > > audio, we lose some audio packet timestamp precision inherently. However I > > > don't consider this a problem, audio timestamps do not have to be sample > > > accurate, for most formats they are not. > > > > > > > Also it is not practical to keep > > > track of how many samples are there in the packets, for example when you > > > do > > > seeking, obviously you can't read all the audio data before the seek point > > > to get a precise sample accurate timestamp. > > > > Its true that with seeking there is not enough information for sample > > precisse > > timestamps. But from packet to packet as long as no seek happened there is. > > And that timestamp can turn out to be wrong. If the audio clock is running > at little more than 48 kHz, there will be A-V desync because after some time > audio and video timestamps for packets coming from the same DV frame will > diverge significantly. > > > My concern was more about something like significant frame to frame > > differences in audio sample numbers. > > Because if some hw or sw generates this we would produce packets of > > identical duration which differ substantially in number of samples and > > that would not be handled well in any scenario that accepted the timestamps > > and durations as exact. > > In general, you can't assume that timestamps or packet durations are exact. > Consider you have a format which stores timestamps and durations in > miliseconds. Rounding errors will occur. sure, maybe the distinction of millisecond/rounded timebases and exact timebases needs a flag somewhere. > Also, for consumer equipment audio > and video is rarely locked together, and audio sample rates are rarely very > precise. sure, this case is maybe a bit more exceptional than this though we have "millisecond" based formats, rounded timestamps we have "exact" cases, maybe the timebase being 1 packet/frame per tick we have "high precission" where the timebase is so precisse it doesnt matter This here though is a bit an oddball, the size if 1 PCM frame is 1 sample The timebase is not a millisecond based one, its not 1 frame either nor is it exact nor high precission. Its 1 video frame, and whatever amount of audio there is in the container which IIUC can differ from 1 video frame even rounded. maybe this just doesnt occur and each frame has a count of samples always rounded to the closes integer count for the video frame. But if for example some hardware was using internally a 16 sample buffer and only put multiplies of 16 samples in frames this would introduce a considerable amount of jitter in the timestamps in relation to the actual duration. And using async to fix this without introducing more problems might require some care > > Maybe this never occurs and in that case your patch should be a good idea > > but if it does happen then some code would be needed to deal with that. > > It is detectable when sample counts do not match what is expected. > > Yeah, and we have tools to fix that, like -af aresample=async=1. > > > That said, i would consider a fix for #8762 to produce correct audio in > > all cases including wav/pcm/mov/... output and not just when the output > > can store "corrupted"/"sparse" audio. > > I think ffmpeg.c should be smarter about it, and be aware if unlocked or > sparse audio (or audio not starting at the same time as video) is supported > by certain muxers or not. And if it is not suppoted, then maybe -af async=1 > or similar should be used automagically. yes thx [] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange 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/nut: Store display matrix side data
On Tue, Nov 03, 2020 at 12:37:01AM +0100, Matthias Neugebauer wrote: > Am 03.11.2020 um 00:23 schrieb Michael Niedermayer : > > "st_sd_displaymatrix" is not listed in nut.txt > > that either needs to be added or if its a non standard field it needs a > > X- prefix > > Thanks for the feedback. > > Adding X- is not a problem, but what is the difference to "r_frame_rate“ > for storing the frame rate? Shouldn’t that be prefixed as well? you are correct I will suggest to add this to nut.txt, given that its already stored for a long time, it should be documented which should resolve this Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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 v4] Unbreak av_malloc_max(0) API/ABI
On Tue, Nov 03, 2020 at 02:38:52PM +0100, Andreas Rheinhardt wrote: > Timo Rothenpieler: > > Given the multitude of recent serious security issues in Chromium-Based > > Browsers, is this even still an issue? > > Anything not up to date enough to have already been fixed has serious > > security issues and should be updated ASAP, which also fixes this issue > > in turn. > > > > I'd rather see downstream users fix their stuff than introduce > > workarounds for broken downstreams into ffmpeg. > +1 I normally am in favor of helping downstreams but in this case I think there is maybe some risk of adding code which could somehow end up as part of an exploit. Asking for a more restrictive limit should not disable the limit, that feels a bit dangerous to me thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. signature.asc Description: 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 v4] Unbreak av_malloc_max(0) API/ABI
On Wed, 2020-11-04 at 10:51 +0100, Michael Niedermayer wrote: > > On Tue, Nov 03, 2020 at 02:38:52PM +0100, Andreas Rheinhardt wrote: > > Timo Rothenpieler: > > > Given the multitude of recent serious security issues in Chromium-Based > > > Browsers, is this even still an issue? > > > Anything not up to date enough to have already been fixed has serious > > > security issues and should be updated ASAP, which also fixes this issue > > > in turn. > > > > > > I'd rather see downstream users fix their stuff than introduce > > > workarounds for broken downstreams into ffmpeg. > > +1 > > I normally am in favor of helping downstreams but in this case > I think there is maybe some risk of adding code which could somehow > end up as part of an exploit. > Asking for a more restrictive limit should not disable the limit, > that feels a bit dangerous to me Not adding this forces apps to stay on known vulnerable ffmpeg Jocke ___ 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 v4] Unbreak av_malloc_max(0) API/ABI
On 04.11.2020 10:55, Joakim Tjernlund wrote: On Wed, 2020-11-04 at 10:51 +0100, Michael Niedermayer wrote: On Tue, Nov 03, 2020 at 02:38:52PM +0100, Andreas Rheinhardt wrote: Timo Rothenpieler: Given the multitude of recent serious security issues in Chromium-Based Browsers, is this even still an issue? Anything not up to date enough to have already been fixed has serious security issues and should be updated ASAP, which also fixes this issue in turn. I'd rather see downstream users fix their stuff than introduce workarounds for broken downstreams into ffmpeg. +1 I normally am in favor of helping downstreams but in this case I think there is maybe some risk of adding code which could somehow end up as part of an exploit. Asking for a more restrictive limit should not disable the limit, that feels a bit dangerous to me Not adding this forces apps to stay on known vulnerable ffmpeg No it doesn't. It forces them to upgrade away from a known vulnerable old Chromium version to one that does not have the issue. ___ 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] tls: Hook up the url_get_short_seek function in the TLS backends
On Thu, 29 Oct 2020, Andreas Rheinhardt wrote:
Martin Storsjö:
This makes sure that small seeks forward on https don't end up
doing new requests.
---
libavformat/tls_gnutls.c | 7 +++
libavformat/tls_libtls.c | 7 +++
libavformat/tls_mbedtls.c | 7 +++
libavformat/tls_openssl.c | 7 +++
libavformat/tls_schannel.c| 7 +++
libavformat/tls_securetransport.c | 7 +++
6 files changed, 42 insertions(+)
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index 0c4ef34f5f..f9d5af7096 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -269,6 +269,12 @@ static int tls_get_file_handle(URLContext *h)
return ffurl_get_file_handle(c->tls_shared.tcp);
}
+static int tls_get_short_seek(URLContext *h)
+{
+TLSContext *s = h->priv_data;
+return ffurl_get_short_seek(s->tls_shared.tcp);
+}
+
static const AVOption options[] = {
TLS_COMMON_OPTIONS(TLSContext, tls_shared),
{ NULL }
@@ -288,6 +294,7 @@ const URLProtocol ff_tls_protocol = {
.url_write = tls_write,
.url_close = tls_close,
.url_get_file_handle = tls_get_file_handle,
+.url_get_short_seek = tls_get_short_seek,
.priv_data_size = sizeof(TLSContext),
.flags = URL_PROTOCOL_FLAG_NETWORK,
.priv_data_class = &tls_class,
diff --git a/libavformat/tls_libtls.c b/libavformat/tls_libtls.c
index dff7f2d9fb..911c8094b0 100644
--- a/libavformat/tls_libtls.c
+++ b/libavformat/tls_libtls.c
@@ -181,6 +181,12 @@ static int tls_get_file_handle(URLContext *h)
return ffurl_get_file_handle(c->tls_shared.tcp);
}
+static int tls_get_short_seek(URLContext *h)
+{
+TLSContext *s = h->priv_data;
+return ffurl_get_short_seek(s->tls_shared.tcp);
+}
+
static const AVOption options[] = {
TLS_COMMON_OPTIONS(TLSContext, tls_shared),
{ NULL }
@@ -200,6 +206,7 @@ const URLProtocol ff_tls_protocol = {
.url_write = ff_tls_write,
.url_close = ff_tls_close,
.url_get_file_handle = tls_get_file_handle,
+.url_get_short_seek = tls_get_short_seek,
.priv_data_size = sizeof(TLSContext),
.flags = URL_PROTOCOL_FLAG_NETWORK,
.priv_data_class = &tls_class,
diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index 965adf1be4..aadf17760d 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -326,6 +326,12 @@ static int tls_get_file_handle(URLContext *h)
return ffurl_get_file_handle(c->tls_shared.tcp);
}
+static int tls_get_short_seek(URLContext *h)
+{
+TLSContext *s = h->priv_data;
+return ffurl_get_short_seek(s->tls_shared.tcp);
+}
+
static const AVOption options[] = {
TLS_COMMON_OPTIONS(TLSContext, tls_shared), \
{"key_password", "Password for the private key file", OFFSET(priv_key_pw),
AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
@@ -346,6 +352,7 @@ const URLProtocol ff_tls_protocol = {
.url_write = tls_write,
.url_close = tls_close,
.url_get_file_handle = tls_get_file_handle,
+.url_get_short_seek = tls_get_short_seek,
.priv_data_size = sizeof(TLSContext),
.flags = URL_PROTOCOL_FLAG_NETWORK,
.priv_data_class = &tls_class,
diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 002197fa76..e0616acbc8 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -351,6 +351,12 @@ static int tls_get_file_handle(URLContext *h)
return ffurl_get_file_handle(c->tls_shared.tcp);
}
+static int tls_get_short_seek(URLContext *h)
+{
+TLSContext *s = h->priv_data;
+return ffurl_get_short_seek(s->tls_shared.tcp);
+}
+
static const AVOption options[] = {
TLS_COMMON_OPTIONS(TLSContext, tls_shared),
{ NULL }
@@ -370,6 +376,7 @@ const URLProtocol ff_tls_protocol = {
.url_write = tls_write,
.url_close = tls_close,
.url_get_file_handle = tls_get_file_handle,
+.url_get_short_seek = tls_get_short_seek,
.priv_data_size = sizeof(TLSContext),
.flags = URL_PROTOCOL_FLAG_NETWORK,
.priv_data_class = &tls_class,
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 4bfaa85228..d4959f75fa 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -589,6 +589,12 @@ static int tls_get_file_handle(URLContext *h)
return ffurl_get_file_handle(c->tls_shared.tcp);
}
+static int tls_get_short_seek(URLContext *h)
+{
+TLSContext *s = h->priv_data;
+return ffurl_get_short_seek(s->tls_shared.tcp);
+}
+
static const AVOption options[] = {
TLS_COMMON_OPTIONS(TLSContext, tls_shared),
{ NULL }
@@ -608,6 +614,7 @@ const URLProtocol ff_tls_protocol = {
.url_write = tls_write,
.url_close = tls_close,
.url_get_file_handle = tls_get_file_handle,
+.url_get_short_seek = tls_get_short_seek,
.priv_data_size = sizeof(TLSContext),
.flags = URL_PROTOCOL_FLAG_NETWORK,
.priv_data_c
[FFmpeg-devel] [PATCH 1/6] avformat/rtsp: 16384 -> SDP_MAX_SIZE
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 49c2d52..1b876c9 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -696,7 +696,7 @@ int ff_sdp_parse(AVFormatContext *s, const char *content)
*
* The Vorbis FMTP line can be up to 16KB - see xiph_parse_sdp_line
* in rtpdec_xiph.c. */
-char buf[16384], *q;
+char buf[SDP_MAX_SIZE], *q;
SDPParseState sdp_parse_state = { { 0 } }, *s1 = &sdp_parse_state;
p = content;
--
1.8.3.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/6] avformat/rtspdec: use SDP_MAX_SIZE for sdp array
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtspdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index ef084a8..3abf34b 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -172,7 +172,7 @@ static int rtsp_read_announce(AVFormatContext *s)
{
RTSPState *rt = s->priv_data;
RTSPMessageHeader request = { 0 };
-char sdp[4096];
+char sdp[SDP_MAX_SIZE];
int ret;
ret = rtsp_read_request(s, &request, "ANNOUNCE");
--
1.8.3.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 4/6] avformat/rtsp: prefer to use variable instead of type
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 51a360f..3a1afa0 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1990,7 +1990,7 @@ static int udp_read_packet(AVFormatContext *s, RTSPStream
**prtsp_st,
int runs = rt->initial_timeout * 1000LL / POLLING_TIME;
if (!p) {
-p = rt->p = av_malloc_array(2 * rt->nb_rtsp_streams + 1, sizeof(struct
pollfd));
+p = rt->p = av_malloc_array(2 * rt->nb_rtsp_streams + 1, sizeof(*p));
if (!p)
return AVERROR(ENOMEM);
--
1.8.3.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 5/6] avformat/rtsp: check return value of ffurl_read_complete
From: Limin Wang Signed-off-by: Limin Wang --- libavformat/rtsp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c index 3a1afa0..fc32e97 100644 --- a/libavformat/rtsp.c +++ b/libavformat/rtsp.c @@ -1228,7 +1228,8 @@ start: content = av_malloc(content_length + 1); if (!content) return AVERROR(ENOMEM); -ffurl_read_complete(rt->rtsp_hd, content, content_length); +if (ffurl_read_complete(rt->rtsp_hd, content, content_length) != content_length) +return AVERROR(EIO); content[content_length] = '\0'; } if (content_ptr) -- 1.8.3.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 3/6] avformat/rtsp: move SDP_MAX_SIZE macro definition to header file
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtsp.c| 1 -
libavformat/rtsp.h| 1 +
libavformat/rtspenc.c | 1 -
3 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 1b876c9..51a360f 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -53,7 +53,6 @@
/* Default timeout values for read packet in seconds */
#define READ_PACKET_TIMEOUT_S 10
-#define SDP_MAX_SIZE 16384
#define RECVBUF_SIZE 10 * RTP_MAX_PACKET_LENGTH
#define DEFAULT_REORDERING_DELAY 10
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 2b37f5b..251ed86 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -78,6 +78,7 @@ enum RTSPControlTransport {
#define RTSP_DEFAULT_AUDIO_SAMPLERATE 44100
#define RTSP_RTP_PORT_MIN 5000
#define RTSP_RTP_PORT_MAX 65000
+#define SDP_MAX_SIZE 16384
/**
* This describes a single item in the "Transport:" line of one stream as
diff --git a/libavformat/rtspenc.c b/libavformat/rtspenc.c
index 97e3ef6..d505444 100644
--- a/libavformat/rtspenc.c
+++ b/libavformat/rtspenc.c
@@ -34,7 +34,6 @@
#include "libavutil/time.h"
#include "url.h"
-#define SDP_MAX_SIZE 16384
static const AVClass rtsp_muxer_class = {
.class_name = "RTSP muxer",
--
1.8.3.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 6/6] avformat/rtspdec: return proper error code
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtspdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 3abf34b..a4cd1f6 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -768,7 +768,7 @@ redo:
}
ret = ffurl_read_complete(rt->rtsp_hd, buf, 3);
if (ret != 3)
-return -1;
+return AVERROR(EIO);
id = buf[0];
len = AV_RB16(buf + 1);
av_log(s, AV_LOG_TRACE, "id=%d len=%d\n", id, len);
@@ -777,10 +777,10 @@ redo:
/* get the data */
ret = ffurl_read_complete(rt->rtsp_hd, buf, len);
if (ret != len)
-return -1;
+return AVERROR(EIO);
if (rt->transport == RTSP_TRANSPORT_RDT &&
-ff_rdt_parse_header(buf, len, &id, NULL, NULL, NULL, NULL) < 0)
-return -1;
+(ret = ff_rdt_parse_header(buf, len, &id, NULL, NULL, NULL, NULL)) < 0)
+return ret;
/* find the matching stream */
for (i = 0; i < rt->nb_rtsp_streams; i++) {
--
1.8.3.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/6] avformat/rtspdec: use SDP_MAX_SIZE for sdp array
On Wed, 4 Nov 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtspdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index ef084a8..3abf34b 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -172,7 +172,7 @@ static int rtsp_read_announce(AVFormatContext *s)
{
RTSPState *rt = s->priv_data;
RTSPMessageHeader request = { 0 };
-char sdp[4096];
+char sdp[SDP_MAX_SIZE];
int ret;
How can we use this define in this file, in patch 2/6, when it's only
available in rtsp.c and rtspenc.c at this stage (and it's moved to the
header in patch 3/6)?
// 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/argo_brp: remove block_align check for audio
Causes a divide-by-zero in the rare case where: - the file has an audio stream, - the first audio frame isn't within the first BRP_BASF_LOOKAHEAD frames, - an audio frame is encountered later, and - its chunk header (except num_blocks) contains all zeros (matching the uninitialised structure in the context) The decoder will discard any garbage data, so the check isn't really needed. Fixes: division by 0 Fixes: 26667/clusterfuzz-testcase-minimized-ffmpeg_dem_ARGO_BRP_fuzzer-5645146928185344.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Zane van Iperen --- libavformat/argo_brp.c | 3 --- 1 file changed, 3 deletions(-) Ping. Will apply tomorrow if no comments. ___ 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/6] avformat/rtspdec: use SDP_MAX_SIZE for sdp array
On Wed, Nov 04, 2020 at 03:44:22PM +0200, Martin Storsjö wrote:
> On Wed, 4 Nov 2020, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/rtspdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
> > index ef084a8..3abf34b 100644
> > --- a/libavformat/rtspdec.c
> > +++ b/libavformat/rtspdec.c
> > @@ -172,7 +172,7 @@ static int rtsp_read_announce(AVFormatContext *s)
> > {
> > RTSPState *rt = s->priv_data;
> > RTSPMessageHeader request = { 0 };
> > -char sdp[4096];
> > +char sdp[SDP_MAX_SIZE];
> > int ret;
>
> How can we use this define in this file, in patch 2/6, when it's only
> available in rtsp.c and rtspenc.c at this stage (and it's moved to the
> header in patch 3/6)?
Sorry, my fault, the patch order isn't right when I apply to the master.
will reformat them.
>
> // Martin
>
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] Unbreak av_malloc_max(0) API/ABI
On Wed, 2020-11-04 at 12:47 +0100, Timo Rothenpieler wrote: > > On 04.11.2020 10:55, Joakim Tjernlund wrote: > > On Wed, 2020-11-04 at 10:51 +0100, Michael Niedermayer wrote: > > > > > > On Tue, Nov 03, 2020 at 02:38:52PM +0100, Andreas Rheinhardt wrote: > > > > Timo Rothenpieler: > > > > > Given the multitude of recent serious security issues in > > > > > Chromium-Based > > > > > Browsers, is this even still an issue? > > > > > Anything not up to date enough to have already been fixed has serious > > > > > security issues and should be updated ASAP, which also fixes this > > > > > issue > > > > > in turn. > > > > > > > > > > I'd rather see downstream users fix their stuff than introduce > > > > > workarounds for broken downstreams into ffmpeg. > > > > +1 > > > > > > I normally am in favor of helping downstreams but in this case > > > I think there is maybe some risk of adding code which could somehow > > > end up as part of an exploit. > > > Asking for a more restrictive limit should not disable the limit, > > > that feels a bit dangerous to me > > > > Not adding this forces apps to stay on known vulnerable ffmpeg > > No it doesn't. It forces them to upgrade away from a known vulnerable > old Chromium version to one that does not have the issue. I was referring to what is out/released now. Eventually all SW will upgrade for one reason or another. Jocke ___ 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/rtpenc: add option to disable STAP for H.264
Use non-interleaved mode but disable STAP is a valid use case, for
example, the receiver doesn't support STAP.
---
libavformat/rtpenc.h | 2 ++
libavformat/rtpenc_h264_hevc.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtpenc.h b/libavformat/rtpenc.h
index 62dc9ab10a..931287cbb3 100644
--- a/libavformat/rtpenc.h
+++ b/libavformat/rtpenc.h
@@ -70,6 +70,7 @@ typedef struct RTPMuxContext RTPMuxContext;
#define FF_RTP_FLAG_SKIP_RTCP 4
#define FF_RTP_FLAG_H264_MODE0 8
#define FF_RTP_FLAG_SEND_BYE 16
+#define FF_RTP_FLAG_H264_NO_STAP 32
#define FF_RTP_FLAG_OPTS(ctx, fieldname) \
{ "rtpflags", "RTP muxer flags", offsetof(ctx, fieldname),
AV_OPT_TYPE_FLAGS, {.i64 = 0}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM,
"rtpflags" }, \
@@ -77,6 +78,7 @@ typedef struct RTPMuxContext RTPMuxContext;
{ "rfc2190", "Use RFC 2190 packetization instead of RFC 4629 for H.263",
0, AV_OPT_TYPE_CONST, {.i64 = FF_RTP_FLAG_RFC2190}, INT_MIN, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM, "rtpflags" }, \
{ "skip_rtcp", "Don't send RTCP sender reports", 0, AV_OPT_TYPE_CONST,
{.i64 = FF_RTP_FLAG_SKIP_RTCP}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM,
"rtpflags" }, \
{ "h264_mode0", "Use mode 0 for H.264 in RTP", 0, AV_OPT_TYPE_CONST, {.i64
= FF_RTP_FLAG_H264_MODE0}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM,
"rtpflags" }, \
+{ "h264_no_stap", "Disable single-time aggregation packet (STAP) for H.264
in RTP", 0, AV_OPT_TYPE_CONST, {.i64 = FF_RTP_FLAG_H264_NO_STAP}, INT_MIN,
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "rtpflags" }, \
{ "send_bye", "Send RTCP BYE packets when finishing", 0,
AV_OPT_TYPE_CONST, {.i64 = FF_RTP_FLAG_SEND_BYE}, INT_MIN, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM, "rtpflags" } \
void ff_rtp_send_data(AVFormatContext *s1, const uint8_t *buf1, int len, int
m);
diff --git a/libavformat/rtpenc_h264_hevc.c b/libavformat/rtpenc_h264_hevc.c
index 0c88fc2a23..faa550abb2 100644
--- a/libavformat/rtpenc_h264_hevc.c
+++ b/libavformat/rtpenc_h264_hevc.c
@@ -65,7 +65,7 @@ static void nal_send(AVFormatContext *s1, const uint8_t *buf,
int size, int last
if (codec == AV_CODEC_ID_H264) {
header_size = 1;
-skip_aggregate = s->flags & FF_RTP_FLAG_H264_MODE0;
+skip_aggregate = s->flags & (FF_RTP_FLAG_H264_MODE0 |
FF_RTP_FLAG_H264_NO_STAP);
} else {
header_size = 2;
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/nut: Store display matrix side data
On Wed, Nov 04, 2020 at 02:14:08AM +0100, Matthias Neugebauer wrote:
> Stream side data such as display matrix is currently lost when using NUT.
>
> Signed-off-by: Matthias Neugebauer
> ---
> libavformat/nutdec.c | 9 +
> libavformat/nutenc.c | 18 ++
> 2 files changed, 27 insertions(+)
>
> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> index 53a052503e..3747a74402 100644
> --- a/libavformat/nutdec.c
> +++ b/libavformat/nutdec.c
> @@ -589,6 +589,15 @@ static int decode_info_header(NUTContext *nut)
> continue;
> }
>
> +if (stream_id_plus1 && !strcmp(name, "X-st_sd_displaymatrix")) {
Is this FFmpeg specific or why is the X- prefix preferred over adding
this to nut.txt ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/7] avcodec/sonic: Don't hardcode sizeof(int) == 4
On Tue, Nov 03, 2020 at 06:57:31PM +0100, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/sonic.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/7] avcodec/sonic: Allocate several buffers together
On Tue, Nov 03, 2020 at 06:57:29PM +0100, Andreas Rheinhardt wrote: > It simplifies freeing them and reduces the amount of allocations. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/sonic.c | 48 -- > 1 file changed, 21 insertions(+), 27 deletions(-) probably ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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 v4] Unbreak av_malloc_max(0) API/ABI
Hi Joakim, On Tue, Nov 3, 2020 at 8:57 AM Joakim Tjernlund < joakim.tjernl...@infinera.com> wrote: > On Tue, 2020-11-03 at 14:38 +0100, Andreas Rheinhardt wrote: > > > > Timo Rothenpieler: > > > Given the multitude of recent serious security issues in Chromium-Based > > > Browsers, is this even still an issue? > > > Anything not up to date enough to have already been fixed has serious > > > security issues and should be updated ASAP, which also fixes this issue > > > in turn. > > > > > > I'd rather see downstream users fix their stuff than introduce > > > workarounds for broken downstreams into ffmpeg. > > +1 > > Chromium has fixed this issue(but not sure if released yet though). Then > this needs to trickle into > elektron and finally into MS Teams(as an example). Will take time so it > will be fixed at some point, not anytime soon though. For clarity, could you explain how releasing this fix would not have to go through the same release funnel in Chrome? Or is the Chrome dependency in elektron/teams not the same as the FFmpeg dependency? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/mss4: Fix memleaks upon allocation error
During init the mts2 decoder allocates several VLCs and then several
buffers in a loop; if one of the latter allocations fails, only the VLCs
are freed, not any buffers that might already have been successfully
allocated. This commit fixes this by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mss4.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mss4.c b/libavcodec/mss4.c
index 432df294d6..c421a07c5d 100644
--- a/libavcodec/mss4.c
+++ b/libavcodec/mss4.c
@@ -648,7 +648,6 @@ static av_cold int mss4_decode_init(AVCodecContext *avctx)
if (mss4_init_vlcs(c)) {
av_log(avctx, AV_LOG_ERROR, "Cannot initialise VLCs\n");
-mss4_free_vlcs(c);
return AVERROR(ENOMEM);
}
for (i = 0; i < 3; i++) {
@@ -656,16 +655,13 @@ static av_cold int mss4_decode_init(AVCodecContext *avctx)
c->prev_dc[i] = av_malloc_array(c->dc_stride[i],
sizeof(**c->prev_dc));
if (!c->prev_dc[i]) {
av_log(avctx, AV_LOG_ERROR, "Cannot allocate buffer\n");
-mss4_free_vlcs(c);
return AVERROR(ENOMEM);
}
}
c->pic = av_frame_alloc();
-if (!c->pic) {
-mss4_decode_end(avctx);
+if (!c->pic)
return AVERROR(ENOMEM);
-}
avctx->pix_fmt = AV_PIX_FMT_YUV444P;
@@ -682,4 +678,5 @@ AVCodec ff_mts2_decoder = {
.close = mss4_decode_end,
.decode = mss4_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
--
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 v4] Unbreak av_malloc_max(0) API/ABI
On Wed, 2020-11-04 at 13:38 -0500, Ronald S. Bultje wrote: > > Hi Joakim, > > On Tue, Nov 3, 2020 at 8:57 AM Joakim Tjernlund < > joakim.tjernl...@infinera.com> wrote: > > > On Tue, 2020-11-03 at 14:38 +0100, Andreas Rheinhardt wrote: > > > > > > Timo Rothenpieler: > > > > Given the multitude of recent serious security issues in Chromium-Based > > > > Browsers, is this even still an issue? > > > > Anything not up to date enough to have already been fixed has serious > > > > security issues and should be updated ASAP, which also fixes this issue > > > > in turn. > > > > > > > > I'd rather see downstream users fix their stuff than introduce > > > > workarounds for broken downstreams into ffmpeg. > > > +1 > > > > Chromium has fixed this issue(but not sure if released yet though). Then > > this needs to trickle into > > elektron and finally into MS Teams(as an example). Will take time so it > > will be fixed at some point, not anytime soon though. > > > For clarity, could you explain how releasing this fix would not have to go > through the same release funnel in Chrome? Or is the Chrome dependency in > elektron/teams not the same as the FFmpeg dependency? I don't understand what you are asking for... Jocke ___ 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/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
On Wed, 4 Nov 2020, Michael Niedermayer wrote: we have "millisecond" based formats, rounded timestamps we have "exact" cases, maybe the timebase being 1 packet/frame per tick we have "high precission" where the timebase is so precisse it doesnt matter This here though is a bit an oddball, the size if 1 PCM frame is 1 sample The timebase is not a millisecond based one, its not 1 frame either nor is it exact nor high precission. Its 1 video frame, and whatever amount of audio there is in the container which IIUC can differ from 1 video frame even rounded. maybe this just doesnt occur and each frame has a count of samples always rounded to the closes integer count for the video frame. The difference between the audio timestamp and the video timestamp for packets from the same DV frame is at most 0.3929636797*frame_duration as the specification says, as Dave quoted, so I don't see how the error can be bigger than this. It looks to me you are mixing timestamps coming from a demuxer, and timestamps you calculate by counting the number of demuxed/decoded audio samples or video frames. Synchronization is done using the former. But if for example some hardware was using internally a 16 sample buffer and only put multiplies of 16 samples in frames this would introduce a considerable amount of jitter in the timestamps in relation to the actual duration. And using async to fix this without introducing more problems might require some care. I still don't see why timestamp or duration jitter is a problem as long as the error is below frame_duration/2. You can safely use async with min_hard_comp set to frame_duration/2. In general, don't you find it problematic that the dv demuxer can return different timestamps if you read packets sequentially and if you seek to the end of a file? It looks like a huge bug which is not fixable if you insist on sample counting... Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/7] avformat/mpegts: Limit copied data to space
On Wed, 4 Nov 2020, Michael Niedermayer wrote:
Fixes: out of array access
Fixes:
26816/clusterfuzz-testcase-minimized-ffmpeg_dem_MPEGTSRAW_fuzzer-6282861159907328.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mpegts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index ebb09991dc..80d010db6c 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -3169,7 +3169,7 @@ static int mpegts_raw_read_packet(AVFormatContext *s,
AVPacket *pkt)
return ret;
}
if (data != pkt->data)
-memcpy(pkt->data, data, ts->raw_packet_size);
+memcpy(pkt->data, data, TS_PACKET_SIZE);
finished_reading_packet(s, ts->raw_packet_size);
if (ts->mpeg2ts_compute_pcr) {
/* compute exact PCR for each packet */
LGTM, thanks.
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] avformat/bintext: Check width in idf_read_header()
On Mon, Nov 02, 2020 at 01:21:28AM +0100, Michael Niedermayer wrote: > Fixes: division by 0 > Fixes: > 26802/clusterfuzz-testcase-minimized-ffmpeg_dem_IDF_fuzzer-5180591554953216.fuzz > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/bintext.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] avformat/iff: check size against INT64_MAX
On Wed, Oct 28, 2020 at 11:56:42PM +0100, Michael Niedermayer wrote: > Bigger sizes are misinterpreted as negative numbers by the API > Fixes: infinite loop > Fixes: > 26611/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-4890614975692800 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/iff.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/8] avformat/paf: Check for EOF in read_table()
On Sun, Oct 25, 2020 at 12:23:08AM +0200, Michael Niedermayer wrote: > Fixes: OOM > Fixes: > 26528/clusterfuzz-testcase-minimized-ffmpeg_dem_PAF_fuzzer-5081929248145408 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/paf.c | 20 +++- > 1 file changed, 15 insertions(+), 5 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avformat/vividas: improve extradata packing checks in track_header()
On Wed, Oct 28, 2020 at 11:56:43PM +0100, Michael Niedermayer wrote: > Fixes: out of array accesses > Fixes: > 26622/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-6581200338288640 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/vividas.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avformat/aiffdec: Check packet size
On Tue, Oct 27, 2020 at 05:21:16PM +0100, Michael Niedermayer wrote: > Fixes: Fixes infinite loop > Fixes: > 26575/clusterfuzz-testcase-minimized-ffmpeg_dem_AIFF_fuzzer-5727522236661760 > > Signed-off-by: Michael Niedermayer > --- > libavformat/aiffdec.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin 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 2/4] avformat/gxf: Check pkt_len
On Tue, Oct 27, 2020 at 05:21:17PM +0100, Michael Niedermayer wrote: > Fixes: Infinite loop > Fixes: > 26576/clusterfuzz-testcase-minimized-ffmpeg_dem_GXF_fuzzer-4823080360476672 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/gxf.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin 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] qsvenc: Value '0' is not a valid value for parameter GopOptFlag
The accepted values for GopOptFlag are MFX_GOP_CLOSED (1) and MFX_GOP_STRICT (2). Signed-off-by: Haihao Xiang --- libavcodec/qsvenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index 1ed8f5d973..62921e82a6 100644 --- a/libavcodec/qsvenc.c +++ b/libavcodec/qsvenc.c @@ -527,7 +527,7 @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q) q->param.mfx.GopPicSize = FFMAX(0, avctx->gop_size); q->param.mfx.GopRefDist = FFMAX(-1, avctx->max_b_frames) + 1; q->param.mfx.GopOptFlag = avctx->flags & AV_CODEC_FLAG_CLOSED_GOP ? - MFX_GOP_CLOSED : 0; + MFX_GOP_CLOSED : MFX_GOP_STRICT; q->param.mfx.IdrInterval= q->idr_interval; q->param.mfx.NumSlice = avctx->slices; q->param.mfx.NumRefFrame= FFMAX(0, avctx->refs); -- 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".
[FFmpeg-devel] [PATCH 1/2] qsvenc_hevc: allow user set more coding options
The SDK supports NalHrdConformance, RecoveryPointSEI and AUDelimiter for
hevc encoder, so we may allow user to set these coding options like as
what we did for h264_qsv encoder.
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc.c | 13 +
libavcodec/qsvenc_hevc.c | 2 ++
2 files changed, 15 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 1ed8f5d973..ee0005e9c1 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -290,6 +290,10 @@ static void dump_video_param(AVCodecContext *avctx,
QSVEncContext *q,
"NalHrdConformance: %s; SingleSeiNalUnit: %s;
VuiVclHrdParameters: %s VuiNalHrdParameters: %s\n",
print_threestate(co->NalHrdConformance),
print_threestate(co->SingleSeiNalUnit),
print_threestate(co->VuiVclHrdParameters),
print_threestate(co->VuiNalHrdParameters));
+} else if ((avctx->codec_id == AV_CODEC_ID_HEVC) &&
QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 28)) {
+av_log(avctx, AV_LOG_VERBOSE,
+ "NalHrdConformance: %s; VuiNalHrdParameters: %s\n",
+ print_threestate(co->NalHrdConformance),
print_threestate(co->VuiNalHrdParameters));
}
av_log(avctx, AV_LOG_VERBOSE, "FrameRateExtD: %"PRIu32"; FrameRateExtN:
%"PRIu32" \n",
@@ -686,6 +690,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
q->extco.RecoveryPointSEI = q->recovery_point_sei ?
MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF;
q->extco.MaxDecFrameBuffering = q->max_dec_frame_buffering;
q->extco.AUDelimiter = q->aud ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
+} else if (avctx->codec_id == AV_CODEC_ID_HEVC) {
+if (avctx->strict_std_compliance != FF_COMPLIANCE_NORMAL)
+q->extco.NalHrdConformance = avctx->strict_std_compliance >
FF_COMPLIANCE_NORMAL ?
+ MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
+
+if (q->recovery_point_sei >= 0)
+q->extco.RecoveryPointSEI = q->recovery_point_sei ?
MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF;
+
+q->extco.AUDelimiter = q->aud ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
}
q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
*)&q->extco;
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 347f30655e..aa02361d1d 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -246,6 +246,8 @@ static const AVOption options[] = {
{ "tile_cols", "Number of columns for tiled encoding",
OFFSET(qsv.tile_cols),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT16_MAX, VE },
{ "tile_rows", "Number of rows for tiled encoding",
OFFSET(qsv.tile_rows),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT16_MAX, VE },
+{ "recovery_point_sei", "Insert recovery point SEI messages",
OFFSET(qsv.recovery_point_sei), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 1, VE },
+{ "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
{ NULL },
};
--
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".
[FFmpeg-devel] [PATCH 2/2] qsvenc: allow AVC/HEVC encoder violate HRD conformance by default
User may get better PSNR for the given bitrate for most cases by default
and use option '-strict 1' to produce HRD conformant bitstream if
required
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc_h264.c | 1 +
libavcodec/qsvenc_hevc.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index ddafc45ec3..e224048442 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -177,6 +177,7 @@ static const AVCodecDefault qsv_enc_defaults[] = {
#if FF_API_PRIVATE_OPT
{ "b_strategy", "-1" },
#endif
+{ "strict", "-1" },
{ NULL },
};
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index aa02361d1d..825df8fbb6 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -272,6 +272,7 @@ static const AVCodecDefault qsv_enc_defaults[] = {
#if FF_API_PRIVATE_OPT
{ "b_strategy", "-1" },
#endif
+{ "strict", "-1" },
{ NULL },
};
--
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".
