Re: [FFmpeg-devel] [PATCH] avfilter: Added siti filter
Am 09.03.22 um 18:31 schrieb Paul B Mahol:
On 3/8/22, Thilo Borgmann wrote:
Am 07.03.22 um 20:06 schrieb Paul B Mahol:
On 3/7/22, Thilo Borgmann wrote:
Am 06.03.22 um 22:25 schrieb Paul B Mahol:
On 3/6/22, Thilo Borgmann wrote:
Am 22.02.22 um 12:30 schrieb Thilo Borgmann:
Am 18.02.22 um 17:08 schrieb Paul B Mahol:
On Sat, Feb 12, 2022 at 11:55 AM Thilo Borgmann
wrote:
Am 31.01.22 um 12:55 schrieb James Almer:
On 1/31/2022 8:53 AM, Anton Khirnov wrote:
Quoting Thilo Borgmann (2022-01-18 14:58:07)
Violations of code style.
Enhanced.
Not enough. There are still many remaining, e.g.
* opening brace of a function definition should be on its own
line
* the context should generally be the first argument
* unsigned char* should be uint8_t*
* mixed declarations and code (the compiler should warn about
that)
I think someone said that clang (or some versions) is apparently
not
warning about this, hence why so many of these end up being missed
in
reviews or even by the patch author.
This and all of Anton's comments in v3. Also removed some more
obviously
useless doubles.
Why it uses doubles in so many places?
Is there any real benefit in that, except extra slowdown?
I guess because it's originating in some c&p Matlab code.
I did %s#double#float#g for v4, loosing some precision we can ignore
IMHO.
v3:
Total frames: 2
Spatial Information:
Average: 165.451985
Max: 165.817542
Min: 165.086427
Temporal Information:
Average: 1.007263
Max: 2.014525
Min: 0.00
v4:
Total frames: 2
Spatial Information:
Average: 164.385895
Max: 164.742325
Min: 164.029480
Temporal Information:
Average: 1.007241
Max: 2.014483
Min: 0.00
Ping.
Into wrong section of changelog added entry.
Useless cast of allocation results.
Does filter changes pixels? If not, add metadata flag to appropriate
place.
All addressed in v5, thx!
Changelog entry is still in wrong, 5.0, section.
Fixed in v6.
Also added a FATE test for it.
Could use fminf/ float functions instead of double variants.
v7.
-Thilo
From 01c3d6dd73ad4c34c44c9cbc8171e330e766144f Mon Sep 17 00:00:00 2001
From: Boris Baracaldo
Date: Sat, 12 Mar 2022 10:04:44 +0100
Subject: [PATCH v7] lavfilter: Add SITI filter
Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as
defined
in ITU-T P.910: Subjective video quality assessment methods for multimedia
applications.
---
Changelog | 1 +
doc/filters.texi | 23 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_siti.c | 349 ++
tests/fate-run.sh | 9 +
tests/fate/filter-video.mak | 3 +
tests/ref/fate/filter-refcmp-siti-yuv | 15 ++
9 files changed, 403 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_siti.c
create mode 100644 tests/ref/fate/filter-refcmp-siti-yuv
diff --git a/Changelog b/Changelog
index 3af8aa032b..200bd82680 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version 5.1:
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
- pcm-bluray encoder
+- SITI filter
version 5.0:
diff --git a/doc/filters.texi b/doc/filters.texi
index 26c5b4db48..9f50fd899f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19944,6 +19944,29 @@ ffmpeg -i input1.mkv -i input2.mkv -filter_complex
"[0:v][1:v] signature=nb_inpu
@end itemize
+@anchor{siti}
+@section siti
+
+Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as
defined
+in ITU-T P.910: Subjective video quality assessment methods for multimedia
+applications. Available PDF at
@url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
+
+It accepts the following option:
+
+@table @option
+@item print_summary
+If set to 1, Summary statistics will be printed to the console. Default 0.
+@end table
+
+@subsection Examples
+@itemize
+@item
+To calculate SI/TI metrics and print summary:
+@example
+ffmpeg -i input.mp4 -vf siti=print_summary=1 -f null -
+@end example
+@end itemize
+
@anchor{smartblur}
@section smartblur
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 56d33e6480..43653597d8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -456,6 +456,7 @@ OBJS-$(CONFIG_SMARTBLUR_FILTER) +=
vf_smartblur.o
OBJS-$(CONFIG_SOBEL_FILTER) += vf_convolution.o
OBJS-$(CONFIG_SOBEL_OPENCL_FILTER) += vf_convolution_opencl.o
opencl.o \
opencl/convolution.o
+OBJS-$(CONFIG_SITI_FILTER) += vf_siti.o
OBJS-$(CONFIG_SPLIT_FILTER) += split.o
OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o qp_table.o
OBJS-$(CONFIG_SR_FILTER) += vf_sr.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f5caee3a62..9fbaaacf47 100644
--- a/libavfilt
Re: [FFmpeg-devel] [PATCH v2] avcodec/pngenc: support writing iCCP chunks
On Fri, 11 Mar 2022 12:18:13 +0100 Andreas Rheinhardt wrote: > 2. Using an AVBPrint with its dynamic reallocations is probably not good > here at all: It is easy to get a good upper bound via deflateBound() > which allows to omit the reallocations/the loop. (I should probably have > applied So, I rewrote the code to only use a single av_bprint_get_buffer() call, rather than looping through it. This is semantically identical to doing an extra malloc(), but also allows the 1K buffer on the stack. I did a survey of all (compressed) iCCP chunks found in PNG files in my "collection" (home folder..), and this is what I found: Min. 1st Qu. MedianMean 3rd Qu.Max. 2752619263930002639 14813 Only roughly 11.57% of files are below the "1K" cutoff threshold for using the small buffer optimization. In light of this, I don't think the 1K optimization is hugely important. But, using the AVBPrint does make the code slightly easier to work with in my eyes. The cleanest alternative, I think, would be to store the deflateBound on the ICC profile somewhere in the PNGEncContext, and then use av_malloc to get a temporary buffer inside `png_get_iccp`. It's of course possible to somehow write directly to the output packet buffer, but I don't think avoiding a ~4K malloc/memcpy is worth the hassle and bug risk of sidestepping png_write_chunk in favor of some custom chunk writing code. Thoughts? ___ 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 v3] avcodec/pngenc: support writing iCCP chunks
From: Niklas Haas
encode_zbuf is mostly a mirror image of decode_zbuf. Other than that,
the code is pretty straightforward. Special care needs to be taken to
avoid writing more than 79 characters of the profile description (the
maximum supported).
To write the (dynamically sized) deflate-encoded data, we allocate extra
space in the packet and use that directly as a scratch buffer. Modify
png_write_chunk slightly to allow pre-writing the chunk contents like
this. This implementation does unfortunately require initializing the
deflate instance twice, but deflateBound() is not redundant with
deflate() so we're not throwing away any significant work.
Also add a FATE transcode test to ensure that the ICC profile gets
encoded correctly.
---
Changes in v3:
- rewrite to write the chunk in-place (inside the packet buffer)
Actually, I implemented an AVBPrint-less version that I think I'm
happier with overall. The extent of the "crimes" needed to support
writing chunks in-place was a single `if` in png_write_chunk and
hard-coding an 8 byte start offset.
I like this the most, since it doesn't require dynamic allocation _at
all_. It also ends up producing a 1 byte smaller test file for some
reason (not as a result of any obvious bug, but simply because zlib
compresses the last few bytes of the stream in a slightly different way,
probably as a result of some internal heuristics related to the buffer
size - the decoded ICC profile checksum is the same).
---
libavcodec/pngenc.c| 93 +-
tests/fate/image.mak | 3 ++
tests/ref/fate/png-icc | 8
3 files changed, 102 insertions(+), 2 deletions(-)
create mode 100644 tests/ref/fate/png-icc
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 3ebcc1e571..e9bbe33adf 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -235,7 +235,8 @@ static void png_write_chunk(uint8_t **f, uint32_t tag,
bytestream_put_be32(f, av_bswap32(tag));
if (length > 0) {
crc = av_crc(crc_table, crc, buf, length);
-memcpy(*f, buf, length);
+if (*f != buf)
+memcpy(*f, buf, length);
*f += length;
}
bytestream_put_be32(f, ~crc);
@@ -343,10 +344,88 @@ static int png_get_gama(enum
AVColorTransferCharacteristic trc, uint8_t *buf)
return 1;
}
+static size_t zbuf_bound(const uint8_t *data, size_t size)
+{
+z_stream zstream;
+size_t bound;
+
+zstream.zalloc = ff_png_zalloc,
+zstream.zfree = ff_png_zfree,
+zstream.opaque = NULL;
+if (deflateInit(&zstream, Z_DEFAULT_COMPRESSION) != Z_OK)
+return 0;
+
+zstream.next_in = data;
+zstream.avail_in = size;
+bound = deflateBound(&zstream, size);
+deflateEnd(&zstream);
+return bound;
+}
+
+static int encode_zbuf(uint8_t **buf, const uint8_t *buf_end,
+ const uint8_t *data, size_t size)
+{
+z_stream zstream;
+int ret;
+
+zstream.zalloc = ff_png_zalloc,
+zstream.zfree = ff_png_zfree,
+zstream.opaque = NULL;
+if (deflateInit(&zstream, Z_DEFAULT_COMPRESSION) != Z_OK)
+return AVERROR_EXTERNAL;
+zstream.next_in = data;
+zstream.avail_in = size;
+zstream.next_out = *buf;
+zstream.avail_out = buf_end - *buf;
+ret = deflate(&zstream, Z_FINISH);
+deflateEnd(&zstream);
+if (ret != Z_STREAM_END)
+return AVERROR_EXTERNAL;
+
+*buf = zstream.next_out;
+return 0;
+}
+
+static int png_write_iccp(uint8_t **bytestream, const uint8_t *end,
+ const AVFrameSideData *side_data)
+{
+const AVDictionaryEntry *entry;
+const char *name;
+uint8_t *start, *buf;
+int ret;
+
+if (!side_data || !side_data->size)
+return 0;
+
+/* write the chunk contents first */
+start = *bytestream + 8; /* make room for iCCP tag + length */
+buf = start;
+
+/* profile description */
+entry = av_dict_get(side_data->metadata, "name", NULL, 0);
+name = (entry && entry->value[0]) ? entry->value : "icc";
+for (int i = 0;; i++) {
+char c = (i == 79) ? 0 : name[i];
+bytestream_put_byte(&buf, c);
+if (!c)
+break;
+}
+
+/* compression method and profile data */
+bytestream_put_byte(&buf, 0);
+if ((ret = encode_zbuf(&buf, end, side_data->data, side_data->size)))
+return ret;
+
+/* rewind to the start and write the chunk header/crc */
+png_write_chunk(bytestream, MKTAG('i', 'C', 'C', 'P'), start, buf - start);
+return 0;
+}
+
static int encode_headers(AVCodecContext *avctx, const AVFrame *pict)
{
AVFrameSideData *side_data;
PNGEncContext *s = avctx->priv_data;
+int ret;
/* write png header */
AV_WB32(s->buf, avctx->width);
@@ -399,7 +478,14 @@ static int encode_headers(AVCodecContext *avctx, const
AVFrame *pict)
if (png_get_gama(pict->color_trc, s->buf))
png_write_chunk(&s->bytestream, MKTAG('g', 'A', 'M', 'A'), s->buf, 4);
-/* put
Re: [FFmpeg-devel] [PATCH v2] avcodec: Add dv marker bsf
> On Mar 10, 2022, at 4:41 AM, Tobias Rapp wrote:
>
> On 09/03/2022 19:18, Michael Niedermayer wrote:
>> Signed-off-by: Michael Niedermayer
>> ---
>> doc/bitstream_filters.texi | 30
>> libavcodec/Makefile | 1 +
>> libavcodec/bitstream_filters.c | 1 +
>> libavcodec/dv_error_marker_bsf.c | 127 +++
>> 4 files changed, 159 insertions(+)
>> create mode 100644 libavcodec/dv_error_marker_bsf.c
>> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
>> index a0092878c8..8c5d84dceb 100644
>> --- a/doc/bitstream_filters.texi
>> +++ b/doc/bitstream_filters.texi
>> @@ -132,6 +132,36 @@ the header stored in extradata to the key packets:
>> ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v
>> dump_extra out.ts
>> @end example
>> +@section dv_error_marker
>> +
>> +Blocks in DV which are marked as damaged are replaced by blocks of the
>> specified color.
>> +
>> +@table @option
>> +@item color
>> +The color to replace damaged blocks by
>> +@item sta
>> +A 16 bit mask which specifies which of the 16 possible error status values
>> are
>> +to be replaced by colored blocks. 0xFFFE is the default which replaces all
>> non 0
>> +error status values.
>> +@table @samp
>> +@item ok
>> +No error, no concealment
>> +@item err
>> +Error, No concealment
>> +@item res
>> +Reserved
>> +@item notok
>> +Error or concealment
>> +@item notres
>> +Not reserved
>> +@item Aa, Ba, Ca, Ab, Bb, Cb, A, B, C, a, b, erri, erru
>> +The specific error status code
>> +@end table
>> +see page 44-46 or section 5.5 of
>> +@url{http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf}
>> +
>> +@end table
>> +
>> @section eac3_core
>> [...]
> The filter options look nice to me now. Have not actually tested the
> bitstream filter on DV files, though.
I tested this and this works well for me. Here's a few samples that demonstrate
the filter:
./ffmpeg -i
https://samples.ffmpeg.org/archive/audio/pcm_s16le/dv+dvvideo+pcm_s16le++dropout.dv
-bsf dv_error_marker=sta=b -f rawvideo -c:v copy - | ffplay -
./ffmpeg -i
https://archive.org/download/DvAnalyzerSampleDvVideoErrorConcealment/DV_Analyzer_Sample_Video_Error_Concealment_original.dv
-bsf dv_error_marker=sta=b -f rawvideo -c:v copy - | ffplay -
Dave Rice
___
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 v8 1/1] avformat: Add IPFS protocol support.
On Fri, Mar 11, 2022 at 02:45:17PM +0100, Mark Gaiser wrote: > On Wed, Mar 9, 2022 at 10:36 AM Michael Niedermayer > wrote: > > > On Wed, Mar 09, 2022 at 01:30:30AM +0100, Mark Gaiser wrote: > > > On Wed, Mar 9, 2022 at 12:45 AM Michael Niedermayer < > > mich...@niedermayer.cc> > > > wrote: > > > > > > > On Tue, Mar 08, 2022 at 01:49:22PM +0100, Mark Gaiser wrote: > > > > > On Fri, Mar 4, 2022 at 7:09 PM Michael Niedermayer < > > > > mich...@niedermayer.cc> > > > > > wrote: > > > > > > > > > > > On Thu, Mar 03, 2022 at 03:58:53PM +0100, Mark Gaiser wrote: > > > > > > > On Tue, Mar 1, 2022 at 11:01 PM Michael Niedermayer < > > > > > > mich...@niedermayer.cc> > > > > > > > wrote: > > > > > > > > > > > > > > > On Mon, Feb 28, 2022 at 02:09:15PM +0100, Tomas Härdin wrote: > > > > > > > > > sön 2022-02-27 klockan 15:29 +0100 skrev Mark Gaiser: > > > > > > > > > > Ping 2 > > > > > > > > > > > > > > > > > > > > I'd really like to get this merged! > > > > > > > > > > This kinda blocks me right now from proceeding with IPFS > > > > > > integration > > > > > > > > > > in > > > > > > > > > > Kodi, MPV and VLC. Implementations in those (who rely on > > > > ffmpeg) > > > > > > are > > > > > > > > > > significantly easier once this patch is finally landed in > > > > ffmpeg. > > > > > > > > > > > > > > > > > > I'd like to hear at least one other dev chime in on this one > > > > > > > > > > > > > > > > what exactly are you not sure about ? > > > > > > > > what exactly needs a 2nd look ? > > > > > > > > > > > > > > > > > > > > > > My assumption. > > > > > > > In general just a second look by someone other than Tomas. > > > > > > > And, as he was skeptical about this patch at first, likely > > another > > > > > > opinion > > > > > > > if this makes sense to add in ffmpeg. > > > > > > > To me it does very much but i'm biased :) > > > > > > > > > > > > ipfs support makes sense to be added to ffmpeg. ive seen ipfs urls > > and > > > > ive > > > > > > already been annoyed that some tools dont "just" work with them. > > > > > > While if i compare this to many other formats which i have never > > seen > > > > > > outside the context of FFmpeg. So from this biased single sample > > that i > > > > > > am, ipfs seems more widespread and thats why iam in favor of its > > > > support > > > > > > > > > > > > thx > > > > > > > > > > > > Great to have your support :) > > > > > Reading that is quite motivating to work on it, no joke! > > > > > > > > > > Just to be clear here. Having this in ffmpeg won't make it "just > > work" > > > > yet. > > > > > For a minimal feeling of "hey, it works out of the box" you'd need: > > > > > - The next or version after the next IPFS. > > > > > - MPV support which relies on this patch to even be supported in mpv > > > > > - Have a node running locally > > > > > > > > if theres no local node it should fallback to a public node > > > > ATM > > > > IPFS_GATEWAY=https://dweb.link ./ffplay ipfs://... > > > > works > > > > so such a fallback is all thats needed for it to just work > > > > > > > > > > Yes, the beauty of gateways. > > > > > > Are you suggesting that I update the patch to add this default? > > > > Iam not sure > > > > > > > I would prefer not to add that even though it would give a feeling of > > "just > > > works". > > > > > I'm mostly concerned about the bandwidth usage it could cause on that > > site. > > > > you could add more than one > > you could point people to https://ipfs.io/ipns/ipnso.com/ to let them > > select > > their own or maybe theres a better way > > > > > > > But also about potential hacks. If this is a default and well used then > > it > > > becomes quite appealing for hackers to take control of dweb.link and send > > > back data that wasn't requested. > > > > Thats a valid concern but not adding a default is not really solving this > > Because what do most people do then ? > > They google for a gateway and pick the first that works. > > Thats plausibly not going to give them the fastest nor the most secure nor > > even not the same as the last million people searching. > > > > To setup a ipfs node on ones own machiene, first it would be needed that > > this > > is VERY simple and clean > > if i run "apt search ipfs", theres none, so that already fails here > > but for the fun, i tried to search for ipfs node on the app store on my > > iphone > > no, also nothing. > > > > so i dont think "install an ipfs node" is really a viable solution for the > > average joe. > > > > we have a wide range of platforms, linux, windows, android, ios just to > > name > > the major ones. This protocol should work on all of them. > > I think a default gateway is the easy way to make that happen, asking the > > user to set a gateway will already leave android and iphone users probably > > wondering how to do that. Is there a way ? > > > > So really iam not saying "add a default", iam really saying "make it work > > for everyone", its ok if the user has to choose one or set some default but >
Re: [FFmpeg-devel] [PATCH v2] avcodec: Add dv marker bsf
On Sat, Mar 12, 2022 at 10:11:52AM -0500, Dave Rice wrote:
>
>
> > On Mar 10, 2022, at 4:41 AM, Tobias Rapp wrote:
> >
> > On 09/03/2022 19:18, Michael Niedermayer wrote:
> >> Signed-off-by: Michael Niedermayer
> >> ---
> >> doc/bitstream_filters.texi | 30
> >> libavcodec/Makefile | 1 +
> >> libavcodec/bitstream_filters.c | 1 +
> >> libavcodec/dv_error_marker_bsf.c | 127 +++
> >> 4 files changed, 159 insertions(+)
> >> create mode 100644 libavcodec/dv_error_marker_bsf.c
> >> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> >> index a0092878c8..8c5d84dceb 100644
> >> --- a/doc/bitstream_filters.texi
> >> +++ b/doc/bitstream_filters.texi
> >> @@ -132,6 +132,36 @@ the header stored in extradata to the key packets:
> >> ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v
> >> dump_extra out.ts
> >> @end example
> >> +@section dv_error_marker
> >> +
> >> +Blocks in DV which are marked as damaged are replaced by blocks of the
> >> specified color.
> >> +
> >> +@table @option
> >> +@item color
> >> +The color to replace damaged blocks by
> >> +@item sta
> >> +A 16 bit mask which specifies which of the 16 possible error status
> >> values are
> >> +to be replaced by colored blocks. 0xFFFE is the default which replaces
> >> all non 0
> >> +error status values.
> >> +@table @samp
> >> +@item ok
> >> +No error, no concealment
> >> +@item err
> >> +Error, No concealment
> >> +@item res
> >> +Reserved
> >> +@item notok
> >> +Error or concealment
> >> +@item notres
> >> +Not reserved
> >> +@item Aa, Ba, Ca, Ab, Bb, Cb, A, B, C, a, b, erri, erru
> >> +The specific error status code
> >> +@end table
> >> +see page 44-46 or section 5.5 of
> >> +@url{http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf}
> >> +
> >> +@end table
> >> +
> >> @section eac3_core
> >> [...]
> > The filter options look nice to me now. Have not actually tested the
> > bitstream filter on DV files, though.
>
> I tested this and this works well for me. Here's a few samples that
> demonstrate the filter:
>
> ./ffmpeg -i
> https://samples.ffmpeg.org/archive/audio/pcm_s16le/dv+dvvideo+pcm_s16le++dropout.dv
> -bsf dv_error_marker=sta=b -f rawvideo -c:v copy - | ffplay -
> ./ffmpeg -i
> https://archive.org/download/DvAnalyzerSampleDvVideoErrorConcealment/DV_Analyzer_Sample_Video_Error_Concealment_original.dv
> -bsf dv_error_marker=sta=b -f rawvideo -c:v copy - | ffplay -
I tested a bit more and it failed with dvcprohd, i have fixed it and will in a
moment post a version that seems to work with both
please retest
PS: i used some artificially damaged files from fate/dv/
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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".
[FFmpeg-devel] [PATCH] avcodec: Add dv marker bsf
Signed-off-by: Michael Niedermayer
---
doc/bitstream_filters.texi | 30 +++
libavcodec/Makefile | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/dv_error_marker_bsf.c | 139 +++
4 files changed, 171 insertions(+)
create mode 100644 libavcodec/dv_error_marker_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index a0092878c8..8c5d84dceb 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -132,6 +132,36 @@ the header stored in extradata to the key packets:
ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v dump_extra
out.ts
@end example
+@section dv_error_marker
+
+Blocks in DV which are marked as damaged are replaced by blocks of the
specified color.
+
+@table @option
+@item color
+The color to replace damaged blocks by
+@item sta
+A 16 bit mask which specifies which of the 16 possible error status values are
+to be replaced by colored blocks. 0xFFFE is the default which replaces all non 0
+error status values.
+@table @samp
+@item ok
+No error, no concealment
+@item err
+Error, No concealment
+@item res
+Reserved
+@item notok
+Error or concealment
+@item notres
+Not reserved
+@item Aa, Ba, Ca, Ab, Bb, Cb, A, B, C, a, b, erri, erru
+The specific error status code
+@end table
+see page 44-46 or section 5.5 of
+@url{http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf}
+
+@end table
+
@section eac3_core
Extract the core from a E-AC-3 stream, dropping extra channels.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cd929da8e6..f36b2e992d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1163,6 +1163,7 @@ OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+=
av1_frame_split_bsf.o
OBJS-$(CONFIG_CHOMP_BSF) += chomp_bsf.o
OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += dump_extradata_bsf.o
OBJS-$(CONFIG_DCA_CORE_BSF) += dca_core_bsf.o
+OBJS-$(CONFIG_DV_ERROR_MARKER_BSF)+= dv_error_marker_bsf.o
OBJS-$(CONFIG_EAC3_CORE_BSF) += eac3_core_bsf.o
OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF) += extract_extradata_bsf.o\
av1_parse.o h2645_parse.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index d565286397..ab27972a88 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -31,6 +31,7 @@ extern const AVBitStreamFilter ff_av1_metadata_bsf;
extern const AVBitStreamFilter ff_chomp_bsf;
extern const AVBitStreamFilter ff_dump_extradata_bsf;
extern const AVBitStreamFilter ff_dca_core_bsf;
+extern const AVBitStreamFilter ff_dv_error_marker_bsf;
extern const AVBitStreamFilter ff_eac3_core_bsf;
extern const AVBitStreamFilter ff_extract_extradata_bsf;
extern const AVBitStreamFilter ff_filter_units_bsf;
diff --git a/libavcodec/dv_error_marker_bsf.c b/libavcodec/dv_error_marker_bsf.c
new file mode 100644
index 00..ef83e914da
--- /dev/null
+++ b/libavcodec/dv_error_marker_bsf.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (c) 2022 Michael Niedermayer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "libavutil/colorspace.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+
+typedef struct DVErrorMarkerContext {
+const AVClass *class;
+uint8_t color_rgba[4];
+int sta;
+uint8_t marked_block[76];
+} DVErrorMarkerContext;
+
+static void setdc(uint8_t *b, const uint8_t color_rgba[4], int cblocks, int
y_step, int v_step, int u_step) {
+for (int i=0; i<4; i++) {
+b[0] = RGB_TO_Y_JPEG(color_rgba[0], color_rgba[1],color_rgba[2]) + 128;
+b[1] = 0x06;
+b += y_step;
+}
+for (int i=0; ipriv_data;
+int i;
+
+memset(s->marked_block, -1, 76);
+setdc(s->marked_block, s->color_rgba, 1, 14, 10, 10);
+setdc(s->marked_block, s->color_rgba, 2, 10, 10, 8);
+
+return 0;
+}
+
+static int dv_error_marker_filter(AVBSFContext *ctx, AVPacket *pkt)
+{
+DVErrorMarkerContext *s = ctx->priv_data;
+int ret = ff_bsf_get_packet_ref(ctx, pkt);
+uint8_t *p;
+int writable = 0;
+int stamask = s->sta;
+int match_count = 0;
+
Re: [FFmpeg-devel] [PATCH] movenc: Use LIBAVFORMAT_IDENT instead of LIBAVCODEC_IDENT
On 3/11/2022 11:23 AM, Martin Storsjö wrote: The muxer seems to have had one seemingly accidental use of LIBAVCODEC_IDENT, while LIBAVFORMAT_IDENT probably is the relevant one (which is used multiple times in the same file). Signed-off-by: Martin Storsjö --- libavformat/movenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 4c868919ae..a2c2145354 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -4108,7 +4108,7 @@ static int mov_write_uuidusmt_tag(AVIOContext *pb, AVFormatContext *s) avio_wb16(pb, 0x021C); /* data */ if (!(s->flags & AVFMT_FLAG_BITEXACT)) -mov_write_psp_udta_tag(pb, LIBAVCODEC_IDENT, "eng", 0x04); +mov_write_psp_udta_tag(pb, LIBAVFORMAT_IDENT, "eng", 0x04); mov_write_psp_udta_tag(pb, title->value, "eng", 0x01); mov_write_psp_udta_tag(pb, "2006/04/01 11:11:11", "und", 0x03); LGTM ___ 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] movenc: Use LIBAVFORMAT_IDENT instead of LIBAVCODEC_IDENT
On Sat, 12 Mar 2022, James Almer wrote: On 3/11/2022 11:23 AM, Martin Storsjö wrote: The muxer seems to have had one seemingly accidental use of LIBAVCODEC_IDENT, while LIBAVFORMAT_IDENT probably is the relevant one (which is used multiple times in the same file). Signed-off-by: Martin Storsjö --- libavformat/movenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 4c868919ae..a2c2145354 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -4108,7 +4108,7 @@ static int mov_write_uuidusmt_tag(AVIOContext *pb, AVFormatContext *s) avio_wb16(pb, 0x021C); /* data */ if (!(s->flags & AVFMT_FLAG_BITEXACT)) -mov_write_psp_udta_tag(pb, LIBAVCODEC_IDENT, "eng", 0x04); +mov_write_psp_udta_tag(pb, LIBAVFORMAT_IDENT, "eng", 0x04); mov_write_psp_udta_tag(pb, title->value, "eng", 0x01); mov_write_psp_udta_tag(pb, "2006/04/01 11:11:11", "und", 0x03); LGTM Thanks, pushed. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/9] libavcodec: Split version.h
On Fri, 11 Mar 2022, Martin Storsjö wrote: This avoids including version.h in all source files, avoiding unnecessary rebuilds when the version number is bumped. Only version_major.h is included by the main header, which defines availability of e.g. FF_API_* macros, and which is bumped much less often. --- fftools/cmdutils.c | 1 + fftools/ffmpeg.c | 1 + fftools/ffprobe.c | 1 + libavcodec/Makefile| 1 + libavcodec/aacenc.c| 1 + libavcodec/avcodec.c | 1 + libavcodec/avcodec.h | 2 +- libavcodec/codec.h | 2 +- libavcodec/dpxenc.c| 1 + libavcodec/j2kenc.c| 1 + libavcodec/libvorbisenc.c | 1 + libavcodec/mjpegenc_common.c | 1 + libavcodec/mpeg4videoenc.c | 1 + libavcodec/options_table.h | 2 +- libavcodec/packet.h| 2 +- libavcodec/pthread_frame.c | 2 +- libavcodec/tiffenc.c | 1 + libavcodec/vaapi_encode_h264.c | 1 + libavcodec/vc2enc.c| 1 + libavcodec/version.h | 28 ++--- libavcodec/version_major.h | 55 ++ libavformat/movenc.c | 1 + 22 files changed, 77 insertions(+), 31 deletions(-) create mode 100644 libavcodec/version_major.h After pushing "movenc: Use LIBAVFORMAT_IDENT instead of LIBAVCODEC_IDENT", I amended this patch locally to remove the change to libavformat/movenc.c. // 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".
[FFmpeg-devel] [PATCH 3/4] avformat/mxfdec: Check for avio_read() failure in mxf_read_strong_ref_array()
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index d7cdd22c8a..828fc0f9f1 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -932,6 +932,7 @@ static int mxf_read_cryptographic_context(void *arg,
AVIOContext *pb, int tag, i
static int mxf_read_strong_ref_array(AVIOContext *pb, UID **refs, int *count)
{
+int64_t ret;
unsigned c = avio_rb32(pb);
//avio_read() used int
@@ -946,7 +947,12 @@ static int mxf_read_strong_ref_array(AVIOContext *pb, UID
**refs, int *count)
return AVERROR(ENOMEM);
}
avio_skip(pb, 4); /* useless size of objects, always 16 according to specs
*/
-avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
+ret = avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
+if (ret != *count * sizeof(UID)) {
+*count = ret < 0 ? 0 : ret / sizeof(UID);
+return ret < 0 ? ret : AVERROR_INVALIDDATA;
+}
+
return 0;
}
--
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/4] avformat/mxfdec: Do not clear array in mxf_read_strong_ref_array() before writing
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 828fc0f9f1..f088712494 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -941,7 +941,7 @@ static int mxf_read_strong_ref_array(AVIOContext *pb, UID
**refs, int *count)
*count = c;
av_free(*refs);
-*refs = av_calloc(*count, sizeof(UID));
+*refs = av_malloc(*count * sizeof(UID));
if (!*refs) {
*count = 0;
return AVERROR(ENOMEM);
--
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/4] avformat/mxfdec: Check count in mxf_read_strong_ref_array()
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index b85c10bf19..d7cdd22c8a 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -932,7 +932,13 @@ static int mxf_read_cryptographic_context(void *arg,
AVIOContext *pb, int tag, i
static int mxf_read_strong_ref_array(AVIOContext *pb, UID **refs, int *count)
{
-*count = avio_rb32(pb);
+unsigned c = avio_rb32(pb);
+
+//avio_read() used int
+if (c > INT_MAX / sizeof(UID))
+return AVERROR_PATCHWELCOME;
+*count = c;
+
av_free(*refs);
*refs = av_calloc(*count, sizeof(UID));
if (!*refs) {
--
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/4] avcodec/vp9_superframe_split_bsf: Check in size
Fixes: Out of array read
Fixes:
45137/clusterfuzz-testcase-minimized-ffmpeg_BSF_VP9_SUPERFRAME_SPLIT_fuzzer-4984270639202304
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp9_superframe_split_bsf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vp9_superframe_split_bsf.c
b/libavcodec/vp9_superframe_split_bsf.c
index ed0444561a..6af555c078 100644
--- a/libavcodec/vp9_superframe_split_bsf.c
+++ b/libavcodec/vp9_superframe_split_bsf.c
@@ -51,6 +51,11 @@ static int vp9_superframe_split_filter(AVBSFContext *ctx,
AVPacket *out)
return ret;
in = s->buffer_pkt;
+if (in->size == 0) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
marker = in->data[in->size - 1];
if ((marker & 0xe0) == 0xc0) {
int length_size = 1 + ((marker >> 3) & 0x3);
--
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".
