[FFmpeg-devel] [PATCH v4 1/2] libavformat/sdp.c: add LE16 format(pcm The least significant byte)
From: weishao Signed-off-by: weishao --- libavformat/sdp.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libavformat/sdp.c b/libavformat/sdp.c index 95f3fbb876..484d30af1b 100644 --- a/libavformat/sdp.c +++ b/libavformat/sdp.c @@ -585,6 +585,12 @@ static char *sdp_write_media_attributes(char *buff, int size, AVStream *st, int payload_type, p->sample_rate, p->channels); break; +case AV_CODEC_ID_PCM_S16LE: +if (payload_type >= RTP_PT_PRIVATE) +av_strlcatf(buff, size, "a=rtpmap:%d LE16/%d/%d\r\n", + payload_type, + p->sample_rate, p->channels); +break; case AV_CODEC_ID_PCM_S24BE: if (payload_type >= RTP_PT_PRIVATE) av_strlcatf(buff, size, "a=rtpmap:%d L24/%d/%d\r\n", -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 2/2] libavformat/rtp.c: update rtp_payload_types
From: weishao
Signed-off-by: weishao
---
libavformat/rtp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/rtp.c b/libavformat/rtp.c
index 38e234391b..86c839aaa4 100644
--- a/libavformat/rtp.c
+++ b/libavformat/rtp.c
@@ -57,6 +57,8 @@ static const struct {
{16, "DVI4", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 11025, 1},
{17, "DVI4", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 22050, 1},
{18, "G729", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 8000, 1},
+ {20, "LE16", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_PCM_S16LE, 44100, 2},
+ {21, "LE16", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_PCM_S16LE, 44100, 1},
{25, "CelB", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_NONE, 9, -1},
{26, "JPEG", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MJPEG, 9, -1},
{28, "nv", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_NONE, 9, -1},
--
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 4/7] avformat/nistspheredec: Check bits_per_coded_sample and channels
Quoting Michael Niedermayer (2021-01-19 19:00:47) > On Mon, Jan 18, 2021 at 09:06:10PM +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2021-01-17 00:07:26) > > > Fixes: signed integer overflow: 80 * 92233009 cannot be represented in > > > type 'int' > > > Fixes: > > > 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_NISTSPHERE_fuzzer-6669100654919680 > > > > > > Found-by: continuous fuzzing process > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavformat/nistspheredec.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c > > > index 079369929f..fec5c88892 100644 > > > --- a/libavformat/nistspheredec.c > > > +++ b/libavformat/nistspheredec.c > > > @@ -80,7 +80,9 @@ static int nist_read_header(AVFormatContext *s) > > > > > > avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate); > > > > > > -st->codecpar->block_align = > > > st->codecpar->bits_per_coded_sample * st->codecpar->channels / 8; > > > +if (st->codecpar->bits_per_coded_sample * > > > (uint64_t)st->codecpar->channels / 8 > INT_MAX) > > > +return AVERROR_INVALIDDATA; > > > +st->codecpar->block_align = > > > st->codecpar->bits_per_coded_sample * (uint64_t)st->codecpar->channels / > > > 8; > > > > > > if (avio_tell(s->pb) > header_size) > > > return AVERROR_INVALIDDATA; > > > -- > > > 2.17.1 > > > > Both bits_per_coded_sample and channels seem to be arbitrary ints, so > > you are assuming sizeof(int) < sizeof(int64) > > I wonder if we shouldnt limit these 2 fields in a platform independant way > But if we dont then the change below should do more correct checks I would be in favor of limiting them both to 16 bits, that should be way beyond anything needed by any reasonable use case. > > @@ -80,7 +80,11 @@ static int nist_read_header(AVFormatContext *s) > > avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate); > > -st->codecpar->block_align = st->codecpar->bits_per_coded_sample > * st->codecpar->channels / 8; > +if (st->codecpar->bits_per_coded_sample < 0 || > st->codecpar->channels <= 0 || > +st->codecpar->bits_per_coded_sample > UINT64_MAX / > st->codecpar->channels || > +st->codecpar->bits_per_coded_sample * > (uint64_t)st->codecpar->channels / 8 > INT_MAX) > +return AVERROR_INVALIDDATA; > +st->codecpar->block_align = st->codecpar->bits_per_coded_sample > * (uint64_t)st->codecpar->channels / 8; > > if (avio_tell(s->pb) > header_size) > return AVERROR_INVALIDDATA; This looks ok. Though it would be even better to sanity-check each value for zero/negative right after the sscanf() that reads it (not insisting you do it). -- 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] ?==?utf-8?q? ?==?utf-8?q? [PATCH] avformat/libsrt: rename streamid
On Wednesday, September 30, 2020 07:24 BST, raghavendra
wrote:
Rename streamid to avoid name clashes.
Signed-off-by: raghavendra
---
libavformat/libsrt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 4025b24976..a490a386e6 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -134,7 +134,7 @@ static const AVOption libsrt_options[] = {
{ "rcvbuf", "Receive buffer size (in bytes)", OFFSET(rcvbuf), AV_OPT_TYPE_INT,
{ .i64 = -1 }, -1, INT_MAX, .flags = D|E },
{ "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" },
@@ -599,7 +599,7 @@ static int libsrt_open(URLContext *h, const char *uri, int
flags)
if (av_find_info_tag(buf, sizeof(buf), "minversion", p)) {
s->minversion = strtol(buf, NULL, 0);
}
- if (av_find_info_tag(buf, sizeof(buf), "streamid", p)) {
+ if (av_find_info_tag(buf, sizeof(buf), "srt_streamid", p)) {
av_freep(&s->streamid);
s->streamid = av_strdup(buf);
if (!s->streamid) {
--
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".
Hello There,
Could you please let me know the upstream staus of this patch?
Best Regards,
Raghavendra
___
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] ?==?utf-8?q? ?==?utf-8?q? [PATCH v4]?==?utf-8?q? avformat/libsrt: print streamid at client
On Tuesday, October 06, 2020 08:18 BST, raghavendra
wrote:
Print the SRT streamid at the client.
Logged to info.
Signed-off-by: raghavendra
---
libavformat/libsrt.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 4025b24976..eed48c11cf 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -359,6 +359,13 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
return 0;
}
+static void libsrt_dump_streamid(URLContext *h, int fd)
+{
+ char streamid[512];
+ int optlen = sizeof(streamid);
+ if (!libsrt_getsockopt(h, fd, SRTO_STREAMID, "SRTO_STREAMID", streamid,
&optlen))
+ av_log(h, AV_LOG_INFO, "srt_streamid : %s\n", streamid);
+}
static int libsrt_setup(URLContext *h, const char *uri, int flags)
{
@@ -442,6 +449,8 @@ static int libsrt_setup(URLContext *h, const char *uri, int
flags)
goto fail1;
listen_fd = fd;
fd = ret;
+ // dump srt streamid at client
+ libsrt_dump_streamid(h, fd);
} else {
if (s->mode == SRT_MODE_RENDEZVOUS) {
ret = srt_bind(fd, cur_ai->ai_addr, cur_ai->ai_addrlen);
--
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".
Hello There,
Could you please let me know the upstream status of this patch?
Best Regards,
Ragahvendra
___
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] libavdevice: Add KMS/DRM output device
James Almer (12021-01-19): > On 1/19/2021 4:04 PM, Nicolas George wrote: > > Anton Khirnov (12021-01-19): > > > > (Note that I would argue against adding more general display output > > > > devices which are already present, like fb and xv, because they are > > > > of essentially no value to libavdevice users. Removing legacy code > > > > is harder, though.) > > > IMO libavdevice output devices are worse than useless and should all be > > > removed. Libavformat API is barely passable for input, but it really is > > > NOT something you should use to drive outputs. > > > > I use libavdevice in my projects, and these output devices have a lot of > > value to me. > > > > With this kind of user-hostile attitude where you disregard everybody's > > use case except those you deem valuable, you almost killed the project > > once. It was ten years ago, time to try again? > > This entire paragraph was absolutely unnecessary and uncalled for as a reply > to a personal opinion. > The first one alone was more than enough to let him and Mark know output > devices have active users. The first paragraph was enough to reply to Mark's interrogation about the usefulness of these devices. The second paragraph was needed to let Anton know my displeasure at seeing other people's work and effort, including mine, insulted by being called "worse than useless". It would not have been necessary if you had called Anton out for the insult. And this is the tip of the iceberg. If we do not want FFmpeg to go the way of libav, to become a mere wrapper library, forever following and slowly falling into relevance, some things that are taboo here will need to be said, especially about a certain unspoken exigence for purity. 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] libavdevice: Add KMS/DRM output device
Mark Thompson (12021-01-19): > Can you explain in more detail your use of libavdevice here? > > My general sense is that while they might sometimes be convenient to > use if you are already working in a libav* context, they are so > limited (by both the API and the implementation) that most users who > want video output to a screen will turn more full-featured players to > implement this. > > (To be clear here, I am talking specifically about outputs to a screen > like fbdev/xv, not about output to non-screen-like devices such as > v4l2 which certainly do have other use-cases.) For starter, since libavcodec and libavformat are supposed to be the preferred way of dealing with audio and video, we should assume that people who develop projects about it will likely have their data already in AVFrame and AVPacket format, so the fact that these devices work with the same kind of API is a huge plus. Second, even though they are limited, they do the work, and for a lot of projects that is plenty enough. Their existence in libavdevices avoids reinventing the wheel, and their common API makes it easy to switch, getting us portability for cheap. Also, I will turn the board on you: why do YOU object to these components? Clearly, somebody found them valuable enough to work at implementing them. Clearly, somebody found them valuable enough to work at reviewing and applying the patches. If you do not see their usefulness, compile with --disable-libavdevice, fine. But why do you spend your time arguing about it? Note that FFmpeg is frequently called "the Swiss army knife of audio-video". Well, Swiss army knives have half a dozen blades that you have no idea what they are for, and neither do mine, and who have nonetheless saved somebody's life. 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] libavdevice: Add KMS/DRM output device
On 20/01/2021 11:53, Nicolas George wrote: Mark Thompson (12021-01-19): Can you explain in more detail your use of libavdevice here? My general sense is that while they might sometimes be convenient to use if you are already working in a libav* context, they are so limited (by both the API and the implementation) that most users who want video output to a screen will turn more full-featured players to implement this. (To be clear here, I am talking specifically about outputs to a screen like fbdev/xv, not about output to non-screen-like devices such as v4l2 which certainly do have other use-cases.) For starter, since libavcodec and libavformat are supposed to be the preferred way of dealing with audio and video, we should assume that people who develop projects about it will likely have their data already in AVFrame and AVPacket format, so the fact that these devices work with the same kind of API is a huge plus. Second, even though they are limited, they do the work, and for a lot of projects that is plenty enough. Their existence in libavdevices avoids reinventing the wheel, and their common API makes it easy to switch, getting us portability for cheap. Also, I will turn the board on you: why do YOU object to these components? Because the libavformat API is not suitable for (especially) these use-cases, so including them in the library feels like a hack that happened to be convenient for some subset of people even though it doesn't really fit and wants something else. Those components do feel the worst to me, but this is really a general complaint about libavdevice as a whole. I would prefer that is either mostly moved into the ffmpeg utility (where it has clear use and could be better integrated), or updated to have a device-oriented API (if there are external users, hence the question). For an API, the things which immediately come to mind are: * Handle frames as well as packets. * Including hardware frames - DRM objects from KMS/V4L2, D3D surfaces from Windows desktop duplication (which doesn't currently exist but should). * Clear core option set - currently almost everything is set by inconsistent private options; things like pixel/sample format, frame/sample rate, geometry and hardware device should be common options to all. * Asynchronicity - a big annoyance in current recording scenarios with the ffmpeg utility is that both audio and video capture block, and do so on the same thread which results in skipped frames. * Capability probing - the existing method of options which log the capabilities are not very useful for API users. (Not meant to be an exhaustive list.) Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavdevice: Add KMS/DRM output device
Mark Thompson (12021-01-20): > Because the libavformat API is not suitable for (especially) these > use-cases, so including them in the library feels like a hack that > happened to be convenient for some subset of people even though it > doesn't really fit and wants something else. Again, I have used them in personal projects, and they do the work. The API can be enhanced, clearly, and you have some ideas that match mine about it. But before discussing this further with you, I would like you to acknowledge this: these devices are useful, removing or limiting them is the wrong way to go; the right way is enhancing them. 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 v4 3/3] avformat/mxfenc: prefer to use the configured metadta
ons 2021-01-20 klockan 00:27 +0100 skrev Marton Balint: > > On Tue, 19 Jan 2021, Tobias Rapp wrote: > > > On 18.01.2021 23:53, Tomas Härdin wrote: > > > lör 2021-01-16 klockan 08:43 +0800 skrev lance.lmw...@gmail.com: > > > > On Fri, Jan 15, 2021 at 09:43:58PM +0100, Marton Balint wrote: > > > > > On Fri, 15 Jan 2021, Tomas Härdin wrote: > > > > > > Again, why? If you have a company that maintains a fork of FFmpeg > > > > > > then > > > > > > compile that info in here instead. Compare with FFmbc which always > > > > > > puts > > > > > > "FFmbc" as CompanyName. > > > > > > > > > > And how can a product based on libavformat set the company name, > > > > > product > > > > > name and product version? It seems a valid use case for me that these > > > > > are > > > > > overridable. Also note that this product version is only the "user > > friendly" > > > > > version string, for the numeric version still LIBAVFORMAT_VERSION > > > > > values > > are > > > > > used. > > > > > > > > Yes, my use case is the product is using libavformat as library, so it's > > > > prefer to have way to override these information as requirements. > > > > > > What I'm worried about here is that we're going to get files which > > > claim to have been written by something other than libavformat. I've > > > had situations like this before, and it is a source of headache. For > > > example, if mxfenc writes some field incorrectly then this might cause > > > us to hack mxfdec to accept that field instead of fixing mxfenc. > > > > I agree that especially for the MXF format with its flexible structure > > it is more relevant to know the muxing library rather than the hosting > > application. Have seen MXF output files of other commercial products > > that also contain library identifiers like "libMXF" or "MXFtk" here. > > > > Other formats in FFmpeg use the "encoder" metadata key for embedding > > library information in the output file. A quick test with AVI output > > shows that this metadata is generated internally and cannot be > > overridden on the command-line. > > If your concern is being able to identify our mxf muxer, then why not use > the Platform metadata item for this? > > "Human readable name of the toolkit and operating system used. Best > practice is to use the form “SDK name (OS name)”" Where is this text from? Neither S377m-2004 nor RP210v10-2007 says this. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 6/7] avformat/lxfdec: Fix multiple integer overflows related to track_size
lör 2021-01-16 klockan 00:22 +0100 skrev Michael Niedermayer: > On Fri, Jan 15, 2021 at 09:48:38AM +0100, Tomas Härdin wrote: > > tor 2021-01-14 klockan 23:51 +0100 skrev Michael Niedermayer: > > > Fixes: signed integer overflow: 538976288 * 8 cannot be represented in > > > type 'int' > > > Fixes: > > > 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_LXF_fuzzer-6634030636335104 > > > > > > Found-by: continuous fuzzing process > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavformat/lxfdec.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/libavformat/lxfdec.c b/libavformat/lxfdec.c > > > index fa84ceea78..509d19fe7f 100644 > > > --- a/libavformat/lxfdec.c > > > +++ b/libavformat/lxfdec.c > > > @@ -195,7 +195,7 @@ static int get_packet_header(AVFormatContext *s) > > > return AVERROR_PATCHWELCOME; > > > } > > > > > > -samples = track_size * 8 / st->codecpar->bits_per_coded_sample; > > > +samples = track_size * 8LL / st->codecpar->bits_per_coded_sample; > > > > > > //use audio packet size to determine video standard > > > //for NTSC we have one 8008-sample audio frame per five video > > > frames > > > @@ -210,6 +210,8 @@ static int get_packet_header(AVFormatContext *s) > > > avpriv_set_pts_info(s->streams[0], 64, 1, 25); > > > } > > > > > > +if (av_popcount(channels) * (uint64_t)track_size > INT_MAX) > > > +return AVERROR_INVALIDDATA; > > > //TODO: warning if track mask != (1 << channels) - 1? > > > ret = av_popcount(channels) * track_size; > > > > What happens if channels == 0 ? Probably gets caught in > > av_new_packet(), just making sure > > Probably would produce a 0 sized packet. > That could be checked for too but seems unrelated to the integer overflow > are there any other constraints i should check for ? > The code suggests mask != (1 << channels) - 1 > what level of warning vs. error do you prefer for the different odd > possibilities? I haven't seen LXF files in quite a while, so I can't really say whether we should warn or not. Probably best not to increase nag in this case. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/paf: Do not zero allocated tables which are immedeately filled
could make use of av_malloc_array while there. On Wed, Jan 20, 2021 at 12:38 AM Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/paf.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavformat/paf.c b/libavformat/paf.c > index 9587111643..bcd6213a45 100644 > --- a/libavformat/paf.c > +++ b/libavformat/paf.c > @@ -149,11 +149,11 @@ static int read_header(AVFormatContext *s) > p->frame_blks > INT_MAX / sizeof(uint32_t)) > return AVERROR_INVALIDDATA; > > -p->blocks_count_table = av_mallocz(p->nb_frames * > +p->blocks_count_table = av_malloc(p->nb_frames * > sizeof(*p->blocks_count_table)); > -p->frames_offset_table = av_mallocz(p->nb_frames * > +p->frames_offset_table = av_malloc(p->nb_frames * > sizeof(*p->frames_offset_table)); > -p->blocks_offset_table = av_mallocz(p->frame_blks * > +p->blocks_offset_table = av_malloc(p->frame_blks * > sizeof(*p->blocks_offset_table)); > > p->video_size = p->max_video_blks * p->buffer_size; > -- > 2.17.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] allow x11grab to capture a window instead of the whole screen
From 0f1a1c46f05def54869ccb58e5d914fa8e0c5d13 Mon Sep 17 00:00:00 2001
From: sgerwk
Date: Wed, 20 Jan 2021 17:05:48 +0100
Subject: [PATCH] allow x11grab to capture a window instead of the whole screen
---
doc/indevs.texi | 3 +++
libavdevice/xcbgrab.c | 19 ---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 3924d03..0738919 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -1564,6 +1564,9 @@ With @var{follow_mouse}:
ffmpeg -f x11grab -follow_mouse centered -show_region 1 -framerate 25 -video_size cif -i :0.0 out.mpg
@end example
+@item window_id
+Grab this window, instead of the whole screen.
+
@item video_size
Set the video frame size. Default is the full desktop.
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index 95bdc8a..6e4ef5d 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -60,6 +60,7 @@ typedef struct XCBGrabContext {
AVRational time_base;
int64_t frame_duration;
+xcb_window_t window_id;
int x, y;
int width, height;
int frame_size;
@@ -82,6 +83,7 @@ typedef struct XCBGrabContext {
#define OFFSET(x) offsetof(XCBGrabContext, x)
#define D AV_OPT_FLAG_DECODING_PARAM
static const AVOption options[] = {
+{ "window_id", "Window to capture", OFFSET(window_id), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, D },
{ "x", "Initial x coordinate.", OFFSET(x), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, D },
{ "y", "Initial y coordinate.", OFFSET(y), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, D },
{ "grab_x", "Initial x coordinate.", OFFSET(x), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, D },
@@ -157,7 +159,7 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
XCBGrabContext *c = s->priv_data;
xcb_get_image_cookie_t iq;
xcb_get_image_reply_t *img;
-xcb_drawable_t drawable = c->screen->root;
+xcb_drawable_t drawable = c->window_id;
xcb_generic_error_t *e = NULL;
uint8_t *data;
int length;
@@ -267,7 +269,7 @@ static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
XCBGrabContext *c = s->priv_data;
xcb_shm_get_image_cookie_t iq;
xcb_shm_get_image_reply_t *img;
-xcb_drawable_t drawable = c->screen->root;
+xcb_drawable_t drawable = c->window_id;
xcb_generic_error_t *e = NULL;
AVBufferRef *buf;
xcb_shm_seg_t segment;
@@ -566,7 +568,7 @@ static int create_stream(AVFormatContext *s)
avpriv_set_pts_info(st, 64, 1, 100);
-gc = xcb_get_geometry(c->conn, c->screen->root);
+gc = xcb_get_geometry(c->conn, c->window_id);
geo = xcb_get_geometry_reply(c->conn, gc, NULL);
if (!geo)
return AVERROR_EXTERNAL;
@@ -745,7 +747,7 @@ static int select_region(AVFormatContext *s)
press_position = (xcb_point_t){ press->event_x, press->event_y };
rectangle.x = press_position.x;
rectangle.y = press_position.y;
-xcb_poly_rectangle(conn, root_window, gc, 1, &rectangle);
+xcb_poly_rectangle(conn, c->window_id, gc, 1, &rectangle);
was_pressed = 1;
break;
}
@@ -754,14 +756,14 @@ static int select_region(AVFormatContext *s)
xcb_motion_notify_event_t *motion =
(xcb_motion_notify_event_t *)event;
xcb_point_t cursor_position = { motion->event_x, motion->event_y };
-xcb_poly_rectangle(conn, root_window, gc, 1, &rectangle);
+xcb_poly_rectangle(conn, c->window_id, gc, 1, &rectangle);
rectangle = rectangle_from_corners(&press_position, &cursor_position);
-xcb_poly_rectangle(conn, root_window, gc, 1, &rectangle);
+xcb_poly_rectangle(conn, c->window_id, gc, 1, &rectangle);
}
break;
}
case XCB_BUTTON_RELEASE: {
-xcb_poly_rectangle(conn, root_window, gc, 1, &rectangle);
+xcb_poly_rectangle(conn, c->window_id, gc, 1, &rectangle);
done = 1;
break;
}
@@ -825,6 +827,9 @@ static av_cold int xcbgrab_read_header(AVFormatContext *s)
return AVERROR(EIO);
}
+if (c->window_id == 0)
+c->window_id = c->screen->root;
+
if (c->select_region) {
ret = select_region(s);
if (ret < 0) {
--
2.29.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".
[FFmpeg-devel] [PATCH] avutil/x86/float_dsp: add fma3 for scalarproduct
Signed-off-by: Paul B Mahol --- libavutil/x86/float_dsp.asm| 112 + libavutil/x86/float_dsp_init.c | 2 + 2 files changed, 114 insertions(+) diff --git a/libavutil/x86/float_dsp.asm b/libavutil/x86/float_dsp.asm index 517fd63638..f7497df34e 100644 --- a/libavutil/x86/float_dsp.asm +++ b/libavutil/x86/float_dsp.asm @@ -463,6 +463,118 @@ cglobal scalarproduct_float, 3,3,2, v1, v2, offset %endif RET +INIT_YMM fma3 +cglobal scalarproduct_float, 3,5,8, v1, v2, size, len, offset +xor offsetq, offsetq +xorps m0, m0 +shl sized, 2 +mov lenq, sizeq +cmp lenq, 32 +jl .l16 +cmp lenq, 64 +jl .l32 +cmp lenq, 128 +jl .l64 +andlenq, ~127 +xorpsm1, m1 +xorpsm2, m2 +xorpsm3, m3 +.loop128: +movups m4, [v1q+offsetq] +movups m5, [v1q+offsetq + 32] +movups m6, [v1q+offsetq + 64] +movups m7, [v1q+offsetq + 96] +fmaddps m0, m4, [v2q+offsetq ], m0 +fmaddps m1, m5, [v2q+offsetq + 32], m1 +fmaddps m2, m6, [v2q+offsetq + 64], m2 +fmaddps m3, m7, [v2q+offsetq + 96], m3 +add offsetq, 128 +cmp offsetq, lenq +jl .loop128 +addpsm0, m1 +addpsm2, m3 +addpsm0, m2 +mov lenq, sizeq +and lenq, 127 +cmp lenq, 64 +jge .l64 +cmp lenq, 32 +jge .l32 +cmp lenq, 16 +jge .l16 +vextractf128 xmm2, m0, 1 +addpsxmm0, xmm2 +movhlps xmm1, xmm0 +addpsxmm0, xmm1 +movssxmm1, xmm0 +shufps xmm0, xmm0, 1 +addssxmm0, xmm1 +RET +.l64: +andlenq, ~63 +addlenq, offsetq +xorpsm1, m1 +.loop64: +movups m4, [v1q+offsetq] +movups m5, [v1q+offsetq + 32] +fmaddps m0, m4, [v2q+offsetq], m0 +fmaddps m1, m5, [v2q+offsetq + 32], m1 +add offsetq, 64 +cmp offsetq, lenq +jl .loop64 +addpsm0, m1 +mov lenq, sizeq +and lenq, 63 +cmp lenq, 32 +jge .l32 +cmp lenq, 16 +jge .l16 +vextractf128 xmm2, m0, 1 +addpsxmm0, xmm2 +movhlps xmm1, xmm0 +addpsxmm0, xmm1 +movssxmm1, xmm0 +shufps xmm0, xmm0, 1 +addssxmm0, xmm1 +RET +.l32: +andlenq, ~31 +addlenq, offsetq +.loop32: +movups m4, [v1q+offsetq] +fmaddps m0, m4, [v2q+offsetq], m0 +add offsetq, 32 +cmp offsetq, lenq +jl .loop32 +vextractf128 xmm2, m0, 1 +addpsxmm0, xmm2 +mov lenq, sizeq +and lenq, 31 +cmp lenq, 16 +jge .l16 +movhlps xmm1, xmm0 +addpsxmm0, xmm1 +movssxmm1, xmm0 +shufps xmm0, xmm0, 1 +addssxmm0, xmm1 +RET +.l16: +andlenq, ~15 +addlenq, offsetq +.loop16: +movaps xmm1, [v1q+offsetq] +mulpsxmm1, [v2q+offsetq] +addpsxmm0, xmm1 +add offsetq, 16 +cmp offsetq, lenq +jl .loop16 +movhlps xmm1, xmm0 +addpsxmm0, xmm1 +movssxmm1, xmm0 +shufps xmm0, xmm0, 1 +addssxmm0, xmm1 +RET + ;- ; void ff_butterflies_float(float *src0, float *src1, int len); ;- diff --git a/libavutil/x86/float_dsp_init.c b/libavutil/x86/float_dsp_init.c index 8826e4e2c9..67bfbe18d0 100644 --- a/libavutil/x86/float_dsp_init.c +++ b/libavutil/x86/float_dsp_init.c @@ -76,6 +76,7 @@ void ff_vector_fmul_reverse_avx2(float *dst, const float *src0, const float *src1, int len); float ff_scalarproduct_float_sse(const float *v1, const float *v2, int order); +float ff_scalarproduct_float_fma3(const float *v1, const float *v2, int order); void ff_butterflies_float_sse(float *av_restrict src0, float *av_restrict src1, int len); @@ -117,5 +118,6 @@ av_cold void ff_float_dsp_init_x86(AVFloatDSPContext *fdsp) fdsp->vector_fmac_scalar = ff_vector_fmac_scalar_fma3; fdsp->vector_fmul_add= ff_vector_fmul_add_fma3; fdsp->vector_dmac_scalar = ff_vector_dmac_scalar_fma3; +fdsp->scalarproduct_float = ff_scalarproduct_float_fma3; } } -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] avcodec/apedec: Use FFNABS() in do_apply_filter()
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself Fixes: 29053/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-4814432697974784 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/apedec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c index 8fe7b5ee86..385e003c6a 100644 --- a/libavcodec/apedec.c +++ b/libavcodec/apedec.c @@ -1333,7 +1333,7 @@ static void do_apply_filter(APEContext *ctx, int version, APEFilter *f, /* Version 3.98 and later files */ /* Update the adaption coefficients */ -absres = FFABS(res); +absres = -(unsigned)FFNABS(res); if (absres) *f->adaptcoeffs = APESIGN(res) * (8 << ((absres > f->avg * 3) + (absres > f->avg * 4 / 3))); -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/5] avcodec/aacdec_template: Avoid undefined negation in imdct_and_windowing_eld()
Fixes: negation of -2147483648 cannot be represented in type 'INTFLOAT' (aka
'int'); cast to an unsigned type to negate this value to itself
Fixes:
29057/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5642758933053440
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/aacdec_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index fbe3074071..532fcff499 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2903,7 +2903,7 @@ static void imdct_and_windowing_ld(AACContext *ac,
SingleChannelElement *sce)
static void imdct_and_windowing_eld(AACContext *ac, SingleChannelElement *sce)
{
-INTFLOAT *in= sce->coeffs;
+UINTFLOAT *in = sce->coeffs;
INTFLOAT *out = sce->ret;
INTFLOAT *saved = sce->saved;
INTFLOAT *buf = ac->buf_mdct;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/5] tools/target_dec_fuzzer: Adjust threshold for wavpack
Fixes: Timeout (long -> 4sec)
Fixes:
29064/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5104450901508096
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index ea4b40..4658e19691 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -180,6 +180,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_TRUEMOTION2: maxpixels /= 1024; break;
case AV_CODEC_ID_VP7: maxpixels /= 256; break;
case AV_CODEC_ID_VP9: maxpixels /= 4096; break;
+case AV_CODEC_ID_WAVPACK: maxsamples /= 1024; break;
case AV_CODEC_ID_WMV3IMAGE: maxpixels /= 8192; break;
case AV_CODEC_ID_WS_VQA: maxpixels /= 16384; break;
case AV_CODEC_ID_WMALOSSLESS: maxsamples /= 1024; break;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/5] tools/target_dec_fuzzer: Adjust threshold for MSA1
Fixes: Timeout (too long to wait -> 1ms)
Fixes:
29048/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSA1_fuzzer-5733703473037312
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index e737d434f1..ea4b40 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -162,6 +162,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_LSCR:maxpixels /= 16;break;
case AV_CODEC_ID_MOTIONPIXELS:maxpixels /= 256; break;
case AV_CODEC_ID_MP4ALS: maxsamples /= 65536; break;
+case AV_CODEC_ID_MSA1:maxpixels /= 16384; break;
case AV_CODEC_ID_MSRLE: maxpixels /= 16;break;
case AV_CODEC_ID_MSS2:maxpixels /= 16384; break;
case AV_CODEC_ID_MSZH:maxpixels /= 128; break;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/5] tools/target_dec_fuzzer: Adjust flv1 threshold
Fixes: Timeout (long -> 95ms)
Fixes:
29068/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLV_fuzzer-6509662832820224
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 4658e19691..92b8b634d2 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -150,6 +150,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_DST: maxsamples /= 1<<20; break;
case AV_CODEC_ID_DXV: maxpixels /= 32;break;
case AV_CODEC_ID_FFWAVESYNTH: maxsamples /= 16384; break;
+case AV_CODEC_ID_FLV1:maxpixels /= 1024; break;
case AV_CODEC_ID_G2M: maxpixels /= 1024; break;
case AV_CODEC_ID_GDV: maxpixels /= 512; break;
case AV_CODEC_ID_GIF: maxpixels /= 16;break;
--
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] ffmpeg_opts: remove lowres check
On 1/9/2021 2:47 PM, James Almer wrote:
The st->codec values are updated based on the lowres factor by
avformat_find_stream_info() when it runs an instance of the decoder internally,
and the same thing happens in ffmpeg.c when we open ist->dec_ctx with
avcodec_open2(), so these assignments are redundant.
Signed-off-by: James Almer
---
This chunk here is not properly wrapped with the relevant pre-processor check
for AVStream->codec, and seeing it's ultimately redundant, i figured we might
as well delete it now.
For that matter, the deprecation of lowres in avcodec.h is in a very strange
state (the field is not removed, its offset is changed instead). Once the value
of FF_API_LOWRES is flipped, neither the field, the AVOption, or the usage
within decoders will be removed, but some code in libavformat/utils.c will be
disabled, and that may result in unexpected behavior.
fftools/ffmpeg_opt.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index c295514401..dec523d621 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -867,15 +867,6 @@ static void add_input_streams(OptionsContext *o,
AVFormatContext *ic)
case AVMEDIA_TYPE_VIDEO:
if(!ist->dec)
ist->dec = avcodec_find_decoder(par->codec_id);
-#if FF_API_LOWRES
-if (st->codec->lowres) {
-ist->dec_ctx->lowres = st->codec->lowres;
-ist->dec_ctx->width = st->codec->width;
-ist->dec_ctx->height = st->codec->height;
-ist->dec_ctx->coded_width = st->codec->coded_width;
-ist->dec_ctx->coded_height = st->codec->coded_height;
-}
-#endif
// avformat_find_stream_info() doesn't set this for us anymore.
ist->dec_ctx->framerate = st->avg_frame_rate;
Will apply soon.
___
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 03/13] cbs_h2645: Merge SEI message handling in common between codecs
On 1/18/2021 7:44 PM, Mark Thompson wrote:
diff --git a/libavcodec/cbs_sei.h b/libavcodec/cbs_sei.h
index 95beabf4d7..5ce4ad3ccd 100644
--- a/libavcodec/cbs_sei.h
+++ b/libavcodec/cbs_sei.h
@@ -21,8 +21,132 @@
#include
#include
+
#include "libavutil/buffer.h"
+#include "cbs.h"
+
+// SEI payload types form a common namespace between the H.264, H.265
+// and H.266 standards. A given payload type always has the same
+// meaning, but some names have different payload types in different
+// standards (e.g. scalable-nesting is 30 in H.264 but 133 in H.265).
+// The content of the payload data depends on the standard, though
+// many generic parts have the same interpretation everywhere (such as
+// mastering-display-colour-volume and user-data-unregistered).
+enum {
+SEI_TYPE_BUFFERING_PERIOD= 0,
+SEI_TYPE_PIC_TIMING = 1,
+SEI_TYPE_PAN_SCAN_RECT = 2,
+SEI_TYPE_FILLER_PAYLOAD = 3,
+SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35 = 4,
+SEI_TYPE_USER_DATA_UNREGISTERED = 5,
+SEI_TYPE_RECOVERY_POINT = 6,
+SEI_TYPE_DEC_REF_PIC_MARKING_REPETITION = 7,
+SEI_TYPE_SPARE_PIC = 8,
+SEI_TYPE_SCENE_INFO = 9,
+SEI_TYPE_SUB_SEQ_INFO= 10,
+SEI_TYPE_SUB_SEQ_LAYER_CHARACTERISTICS = 11,
+SEI_TYPE_SUB_SEQ_CHARACTERISTICS = 12,
+SEI_TYPE_FULL_FRAME_FREEZE = 13,
+SEI_TYPE_FULL_FRAME_FREEZE_RELEASE = 14,
+SEI_TYPE_FULL_FRAME_SNAPSHOT = 15,
+SEI_TYPE_PROGRESSIVE_REFINEMENT_SEGMENT_START= 16,
+SEI_TYPE_PROGRESSIVE_REFINEMENT_SEGMENT_END = 17,
+SEI_TYPE_MOTION_CONSTRAINED_SLICE_GROUP_SET = 18,
+SEI_TYPE_FILM_GRAIN_CHARACTERISTICS = 19,
+SEI_TYPE_DEBLOCKING_FILTER_DISPLAY_PREFERENCE= 20,
+SEI_TYPE_STEREO_VIDEO_INFO = 21,
+SEI_TYPE_POST_FILTER_HINT= 22,
+SEI_TYPE_TONE_MAPPING_INFO = 23,
+SEI_TYPE_SCALABILITY_INFO= 24,
+SEI_TYPE_SUB_PIC_SCALABLE_LAYER = 25,
+SEI_TYPE_NON_REQUIRED_LAYER_REP = 26,
+SEI_TYPE_PRIORITY_LAYER_INFO = 27,
+SEI_TYPE_LAYERS_NOT_PRESENT_4= 28,
+SEI_TYPE_LAYER_DEPENDENCY_CHANGE = 29,
+SEI_TYPE_SCALABLE_NESTING_4 = 30,
+SEI_TYPE_BASE_LAYER_TEMPORAL_HRD = 31,
+SEI_TYPE_QUALITY_LAYER_INTEGRITY_CHECK = 32,
+SEI_TYPE_REDUNDANT_PIC_PROPERTY = 33,
+SEI_TYPE_TL0_DEP_REP_INDEX = 34,
+SEI_TYPE_TL_SWITCHING_POINT = 35,
+SEI_TYPE_PARALLEL_DECODING_INFO = 36,
+SEI_TYPE_MVC_SCALABLE_NESTING= 37,
+SEI_TYPE_VIEW_SCALABILITY_INFO = 38,
+SEI_TYPE_MULTIVIEW_SCENE_INFO_4 = 39,
+SEI_TYPE_MULTIVIEW_ACQUISITION_INFO_4= 40,
+SEI_TYPE_NON_REQUIRED_VIEW_COMPONENT = 41,
+SEI_TYPE_VIEW_DEPENDENCY_CHANGE = 42,
+SEI_TYPE_OPERATION_POINTS_NOT_PRESENT= 43,
+SEI_TYPE_BASE_VIEW_TEMPORAL_HRD = 44,
+SEI_TYPE_FRAME_PACKING_ARRANGEMENT = 45,
+SEI_TYPE_MULTIVIEW_VIEW_POSITION_4 = 46,
+SEI_TYPE_DISPLAY_ORIENTATION = 47,
+SEI_TYPE_MVCD_SCALABLE_NESTING = 48,
+SEI_TYPE_MVCD_VIEW_SCALABILITY_INFO = 49,
+SEI_TYPE_DEPTH_REPRESENTATION_INFO_4 = 50,
+SEI_TYPE_THREE_DIMENSIONAL_REFERENCE_DISPLAYS_INFO_4 = 51,
+SEI_TYPE_DEPTH_TIMING= 52,
+SEI_TYPE_DEPTH_SAMPLING_INFO = 53,
+SEI_TYPE_CONSTRAINED_DEPTH_PARAMETER_SET_IDENTIFIER = 54,
+SEI_TYPE_GREEN_METADATA = 56,
+SEI_TYPE_STRUCTURE_OF_PICTURES_INFO = 128,
+SEI_TYPE_ACTIVE_PARAMETER_SETS = 129,
+SEI_TYPE_DECODING_UNIT_INFO = 130,
+SEI_TYPE_TEMPORAL_SUB_LAYER_ZERO_IDX = 131,
+SEI_TYPE_DECODED_PICTURE_HASH= 132,
+SEI_TYPE_SCALABLE_NESTING_5 = 133,
+SEI_TYPE_REGION_REFRESH_INFO = 134,
+SEI_TYPE_NO_DISPLAY = 135,
+SEI_TYPE_TIME_CODE = 136,
+SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME
Re: [FFmpeg-devel] [PATCH] avutil/x86/float_dsp: add fma3 for scalarproduct
On 1/20/2021 5:30 PM, Paul B Mahol wrote: Signed-off-by: Paul B Mahol --- libavutil/x86/float_dsp.asm| 112 + libavutil/x86/float_dsp_init.c | 2 + 2 files changed, 114 insertions(+) diff --git a/libavutil/x86/float_dsp.asm b/libavutil/x86/float_dsp.asm index 517fd63638..f7497df34e 100644 --- a/libavutil/x86/float_dsp.asm +++ b/libavutil/x86/float_dsp.asm @@ -463,6 +463,118 @@ cglobal scalarproduct_float, 3,3,2, v1, v2, offset %endif RET +INIT_YMM fma3 +cglobal scalarproduct_float, 3,5,8, v1, v2, size, len, offset +xor offsetq, offsetq +xorps m0, m0 +shl sized, 2 +mov lenq, sizeq +cmp lenq, 32 +jl .l16 +cmp lenq, 64 +jl .l32 +cmp lenq, 128 +jl .l64 +andlenq, ~127 +xorpsm1, m1 +xorpsm2, m2 +xorpsm3, m3 +.loop128: +movups m4, [v1q+offsetq] +movups m5, [v1q+offsetq + 32] +movups m6, [v1q+offsetq + 64] +movups m7, [v1q+offsetq + 96] +fmaddps m0, m4, [v2q+offsetq ], m0 +fmaddps m1, m5, [v2q+offsetq + 32], m1 +fmaddps m2, m6, [v2q+offsetq + 64], m2 +fmaddps m3, m7, [v2q+offsetq + 96], m3 Could use mmsize for the offsets. It will make it easier to adapt this function to eventually use avx512. +add offsetq, 128 +cmp offsetq, lenq +jl .loop128 +addpsm0, m1 +addpsm2, m3 +addpsm0, m2 Do only addpsm0, m2 addpsm1, m3 here. There's no need to combine all four regs into m0 if you end up jumping to l64, since m1 is still used there as an accumulator. +mov lenq, sizeq +and lenq, 127 +cmp lenq, 64 +jge .l64 Then add addpsm0, m1 After this line, since l32 and l16 use only m0. +cmp lenq, 32 +jge .l32 +cmp lenq, 16 +jge .l16 Move the next two instructions before this line. If you jump to l16 like this, vextractf128 will not be executed and you'll be missing the upper 128 bits of m0 in the final sum. +vextractf128 xmm2, m0, 1 +addpsxmm0, xmm2 +movhlps xmm1, xmm0 +addpsxmm0, xmm1 +movssxmm1, xmm0 +shufps xmm0, xmm0, 1 +addssxmm0, xmm1 +RET +.l64: +andlenq, ~63 +addlenq, offsetq +xorpsm1, m1 +.loop64: +movups m4, [v1q+offsetq] +movups m5, [v1q+offsetq + 32] +fmaddps m0, m4, [v2q+offsetq], m0 +fmaddps m1, m5, [v2q+offsetq + 32], m1 +add offsetq, 64 +cmp offsetq, lenq +jl .loop64 +addpsm0, m1 +mov lenq, sizeq +and lenq, 63 +cmp lenq, 32 +jge .l32 +cmp lenq, 16 +jge .l16 Ditto. +vextractf128 xmm2, m0, 1 +addpsxmm0, xmm2 +movhlps xmm1, xmm0 +addpsxmm0, xmm1 +movssxmm1, xmm0 +shufps xmm0, xmm0, 1 +addssxmm0, xmm1 +RET +.l32: +andlenq, ~31 +addlenq, offsetq +.loop32: +movups m4, [v1q+offsetq] +fmaddps m0, m4, [v2q+offsetq], m0 +add offsetq, 32 +cmp offsetq, lenq +jl .loop32 +vextractf128 xmm2, m0, 1 +addpsxmm0, xmm2 +mov lenq, sizeq +and lenq, 31 +cmp lenq, 16 +jge .l16 You got it right here. +movhlps xmm1, xmm0 +addpsxmm0, xmm1 +movssxmm1, xmm0 +shufps xmm0, xmm0, 1 +addssxmm0, xmm1 +RET +.l16: +andlenq, ~15 +addlenq, offsetq +.loop16: +movaps xmm1, [v1q+offsetq] +mulpsxmm1, [v2q+offsetq] +addpsxmm0, xmm1 +add offsetq, 16 +cmp offsetq, lenq +jl .loop16 +movhlps xmm1, xmm0 +addpsxmm0, xmm1 +movssxmm1, xmm0 +shufps xmm0, xmm0, 1 +addssxmm0, xmm1 +RET %if ARCH_X86_64 == 0 movss r0m, xm0 fld dword r0m %endif Above every RET in the function. + ;- ; void ff_butterflies_float(float *src0, float *src1, int len); ;- diff --git a/libavutil/x86/float_dsp_init.c b/libavutil/x86/float_dsp_init.c index 8826e4e2c9..67bfbe18d0 100644 --- a/libavutil/x86/float_dsp_init.c +++ b/libavutil/x86/float_dsp_init.c @@ -76,6 +76,7 @@ void ff_vector_fmul_reverse_avx2(float *dst, const float *src0, const float *src1, int len); float ff_scalarproduct_float_sse(const float *v1, const float *v2, int order); +float ff_scalarproduct_float_fma3(const float *v1, const float *v2, int order); void ff_butterflies_float_sse(float *av_restrict src0, float *av_restrict src1, int len); @@ -117,5 +118,6 @@ av_cold void ff_float_dsp_init_x86(AVFloatDSPContext *fdsp) fdsp->vector_fmac_scalar = ff_vector_fmac_scalar_fma3; fdsp->vector_fmul_add= ff_vector_fmul_add_fma3; fdsp->vector_dmac_scalar = ff_vector_dmac_scalar_fma3; +fd
[FFmpeg-devel] [PATCH] avutils/vulkan: hwmap, respect src frame resolution
fixes http://trac.ffmpeg.org/ticket/9055
The hw decoder may allocate a large frame from AVHWFramesContext, and adjust
width and height based on bitstream.
We need to use resolution from src frame instead of AVHWFramesContext.
test command:
ffmpeg -loglevel debug -hide_banner -hwaccel vaapi -init_hw_device
vaapi=va:/dev/dri/renderD128 -hwaccel_device va -hwaccel_output_format vaapi
-init_hw_device vulkan=vulk -filter_hw_device vulk -i 1920x1080.264 -c:v
libx264 -r:v 30 -profile:v high -preset veryfast -vf
"hwmap,chromaber_vulkan=0:0,hwdownload,format=nv12" -map 0 -y vaapiouts.mkv
expected:
No green bar at bottom.
---
libavutil/hwcontext_vulkan.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index d4ff4ae307..f6d0cae8ae 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -2009,7 +2009,7 @@ static inline VkFormat drm_to_vulkan_fmt(uint32_t
drm_fourcc)
}
static int vulkan_map_from_drm_frame_desc(AVHWFramesContext *hwfc, AVVkFrame
**frame,
- AVDRMFrameDescriptor *desc)
+ const AVFrame *src,
AVDRMFrameDescriptor *desc)
{
int err = 0;
VkResult ret;
@@ -2085,7 +2085,7 @@ static int
vulkan_map_from_drm_frame_desc(AVHWFramesContext *hwfc, AVVkFrame **f
};
get_plane_wh(&create_info.extent.width, &create_info.extent.height,
- hwfc->sw_format, hwfc->width, hwfc->height, i);
+ hwfc->sw_format, src->width, src->height, i);
for (int j = 0; j < planes; j++) {
plane_data[j].offset = desc->layers[i].planes[j].offset;
@@ -2246,7 +2246,7 @@ static int vulkan_map_from_drm(AVHWFramesContext *hwfc,
AVFrame *dst,
AVVkFrame *f;
VulkanMapping *map = NULL;
-err = vulkan_map_from_drm_frame_desc(hwfc, &f,
+err = vulkan_map_from_drm_frame_desc(hwfc, &f, src,
(AVDRMFrameDescriptor *)src->data[0]);
if (err)
return err;
--
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".
