[FFmpeg-devel] [PATCH v2] avformat/dhav: also support ZLAV packets

2020-11-08 Thread Michael Keeley 
Some DVRs (e.g. D7008FH made by iSmart Cities (Zhuhai) Limited) output the same 
format .dav file,
but use ZLAV/zlav tags to delimit the packets instead of DHAV/dhav.

Signed-off-by: Michael Keeley 
---
 Changelog |  1 +
 libavformat/dhav.c| 31 ++-
 libavformat/version.h |  2 +-
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/Changelog b/Changelog
index 0ea1901bbe..a56216543d 100644
--- a/Changelog
+++ b/Changelog
@@ -41,6 +41,7 @@ version :
 - LEGO Racers ALP (.tun & .pcm) muxer
 - AV1 VAAPI decoder
 - adenorm filter
+- Add ZLAV format to DHAV demuxer
 
 
 version 4.3:
diff --git a/libavformat/dhav.c b/libavformat/dhav.c
index 53deaff77e..40c2cc78b0 100644
--- a/libavformat/dhav.c
+++ b/libavformat/dhav.c
@@ -1,5 +1,5 @@
 /*
- * DHAV demuxer
+ * DHAV/ZLAV demuxer
  *
  * Copyright (c) 2018 Paul B Mahol
  *
@@ -57,7 +57,7 @@ static int dhav_probe(const AVProbeData *p)
 if (!memcmp(p->buf, "DAHUA", 5))
 return AVPROBE_SCORE_MAX;
 
-if (memcmp(p->buf, "DHAV", 4))
+if (memcmp(p->buf, "DHAV", 4) && memcmp(p->buf, "ZLAV", 4))
 return 0;
 
 if (p->buf[4] == 0xf0 ||
@@ -163,6 +163,19 @@ static int parse_ext(AVFormatContext *s, int length)
 return 0;
 }
 
+static int read_start_tag(AVIOContext *pb)
+{
+unsigned int start_tag = avio_rl32(pb);
+return start_tag == MKTAG('D','H','A','V') || start_tag == 
MKTAG('Z','L','A','V');
+}
+
+static int read_end_tag(AVIOContext *pb)
+{
+unsigned int end_tag = avio_rl32(pb);
+return end_tag == MKTAG('d','h','a','v') || end_tag == 
MKTAG('z','l','a','v');
+}
+
+
 static int read_chunk(AVFormatContext *s)
 {
 DHAVContext *dhav = s->priv_data;
@@ -173,11 +186,11 @@ static int read_chunk(AVFormatContext *s)
 if (avio_feof(s->pb))
 return AVERROR_EOF;
 
-if (avio_rl32(s->pb) != MKTAG('D','H','A','V')) {
+if (!read_start_tag(s->pb)) {
 dhav->last_good_pos += 0x8000;
 avio_seek(s->pb, dhav->last_good_pos, SEEK_SET);
 
-while (avio_rl32(s->pb) != MKTAG('D','H','A','V')) {
+while (!read_start_tag(s->pb)) {
 if (avio_feof(s->pb))
 return AVERROR_EOF;
 dhav->last_good_pos += 0x8000;
@@ -247,7 +260,7 @@ static int64_t get_duration(AVFormatContext *s)
 return 0;
 
 avio_seek(s->pb, avio_size(s->pb) - 8, SEEK_SET);
-if (avio_rl32(s->pb) == MKTAG('d','h','a','v')) {
+if (read_end_tag(s->pb)) {
 int seek_back = avio_rl32(s->pb);
 
 avio_seek(s->pb, -seek_back, SEEK_CUR);
@@ -281,12 +294,12 @@ static int dhav_read_header(AVFormatContext *s)
 avio_skip(s->pb, 0x400 - 5);
 dhav->last_good_pos = avio_tell(s->pb);
 } else {
-if (!memcmp(signature, "DHAV", 4)) {
+if (!memcmp(signature, "DHAV", 4) || !memcmp(signature, "ZLAV", 4)) {
 avio_seek(s->pb, -5, SEEK_CUR);
 dhav->last_good_pos = avio_tell(s->pb);
 } else if (s->pb->seekable) {
 avio_seek(s->pb, avio_size(s->pb) - 8, SEEK_SET);
-while (avio_rl32(s->pb) == MKTAG('d','h','a','v')) {
+while (read_end_tag(s->pb)) {
 int seek_back;
 
 seek_back = avio_rl32(s->pb) + 8;
@@ -409,7 +422,7 @@ retry:
 stream_index = dhav->type == 0xf0 ? dhav->audio_stream_index : 
dhav->video_stream_index;
 if (stream_index < 0) {
 avio_skip(s->pb, ret);
-if (avio_rl32(s->pb) == MKTAG('d','h','a','v'))
+if (read_end_tag(s->pb))
 avio_skip(s->pb, 4);
 goto retry;
 }
@@ -425,7 +438,7 @@ retry:
 if (pkt->stream_index >= 0)
 pkt->pts = get_pts(s, pkt->stream_index);
 pkt->pos = dhav->last_good_pos;
-if (avio_rl32(s->pb) == MKTAG('d','h','a','v'))
+if (read_end_tag(s->pb))
 avio_skip(s->pb, 4);
 
 return ret;
diff --git a/libavformat/version.h b/libavformat/version.h
index ddcca9ae50..b43193bcb1 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR  64
+#define LIBAVFORMAT_VERSION_MINOR  65
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
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

2020-11-08 Thread Michael Niedermayer 
On Fri, Oct 16, 2020 at 10:57:22AM +0200, Joakim Tjernlund wrote:
> From https://bugs.chromium.org/p/chromium/issues/detail?id=1095962
> 
> This seems to be caused by the custom handling of "av_max_alloc(0)" in
> Chromium's ffmpeg fork to mean unlimited (added in [1]).
> 
> Upstream ffmpeg doesn't treat 0 as a special value; versions before 4.3 
> seemingly worked
> because 32 was subtracted from max_alloc_size (set to 0 by Chromium) 
> resulting in an
> integer underflow, making the effective limit be SIZE_MAX - 31.
> 
> Now that the above underflow doesn't happen, the tab just crashes. The 
> upstream change
> for no longer subtracting 32 from max_alloc_size was included in ffmpeg 4.3. 
> [2]
> 
> [1] 
> https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/73563
> [2] https://github.com/FFmpeg/FFmpeg/commit/731c77589841
> ---
> 
> Restore av_malloc_max(0) to MAX_INT fixing MS Teams, Discord older chromium 
> etc.
> 
> Signed-off-by: Joakim Tjernlund 
> ---
> 
>  v2: Cover the full API range 0-31
> 
>  v3: Closer compat with < 4.3 ffmpeg
> 
>  v4: Adjust size accoriding to Andreas Rheinhardt comments
> 
>  libavutil/mem.c | 2 ++
>  1 file changed, 2 insertions(+)

"Unbreak av_malloc_max(0) API/ABI"
The commit message of this is incorrect

The API before and after this documented the current git master behavior
more correct would be
"Break API of av_malloc_max() for 0-31, to restore ABI behavior so applications 
using this do not need to be changed"

Also id like to raise awareness that this function had a big warning:
*
* @warning Exercise extreme caution when using this function. Don't touch
*  this if you do not understand the full consequence of doing so.
*/
void av_max_alloc(size_t max);

And also id like to raise awareness that the default limit is INT_MAX
while with 0 as argument it becomes SIZE_MAX. I would expect that is
not safe everywhere and could open security issues.
If anything 0 should be interpreted as the default INT_MAX
If its not obvious where SIZE_MAX can be an issue, consider what we
use to index arrays, int, and that doesnt go to SIZE_MAX but instead
hits undefined behavior maybe becomes negative and accesses out of array

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

2020-11-08 Thread Andreas Rheinhardt 
Michael Niedermayer:
> On Fri, Oct 16, 2020 at 10:57:22AM +0200, Joakim Tjernlund wrote:
>> From https://bugs.chromium.org/p/chromium/issues/detail?id=1095962
>> 
>> This seems to be caused by the custom handling of "av_max_alloc(0)" in
>> Chromium's ffmpeg fork to mean unlimited (added in [1]).
>>
>> Upstream ffmpeg doesn't treat 0 as a special value; versions before 4.3 
>> seemingly worked
>> because 32 was subtracted from max_alloc_size (set to 0 by Chromium) 
>> resulting in an
>> integer underflow, making the effective limit be SIZE_MAX - 31.
>>
>> Now that the above underflow doesn't happen, the tab just crashes. The 
>> upstream change
>> for no longer subtracting 32 from max_alloc_size was included in ffmpeg 4.3. 
>> [2]
>>
>> [1] 
>> https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/73563
>> [2] https://github.com/FFmpeg/FFmpeg/commit/731c77589841
>> ---
>>
>> Restore av_malloc_max(0) to MAX_INT fixing MS Teams, Discord older chromium 
>> etc.
>>
>> Signed-off-by: Joakim Tjernlund 
>> ---
>>
>>  v2: Cover the full API range 0-31
>>
>>  v3: Closer compat with < 4.3 ffmpeg
>>
>>  v4: Adjust size accoriding to Andreas Rheinhardt comments
>>
>>  libavutil/mem.c | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> "Unbreak av_malloc_max(0) API/ABI"
> The commit message of this is incorrect
> 
> The API before and after this documented the current git master behavior
> more correct would be
> "Break API of av_malloc_max() for 0-31, to restore ABI behavior so 
> applications using this do not need to be changed"
> 

I agree.

> Also id like to raise awareness that this function had a big warning:
> *
> * @warning Exercise extreme caution when using this function. Don't touch
> *  this if you do not understand the full consequence of doing so.
> */
> void av_max_alloc(size_t max);
> 
> And also id like to raise awareness that the default limit is INT_MAX
> while with 0 as argument it becomes SIZE_MAX. 

No: With the old version 0 was effectively SIZE_MAX - 31, with current
git head 0 means that all allocations of > 0 fail (yet requests of size
0 still result in an allocation of size 1); with the proposed version
av_max_alloc(0) would set the limit to SIZE_MAX - 32. This off-by-one is
surely unintentional.

I would expect that is
> not safe everywhere and could open security issues.
> If anything 0 should be interpreted as the default INT_MAX

That would be an API break.

> If its not obvious where SIZE_MAX can be an issue, consider what we
> use to index arrays, int, and that doesnt go to SIZE_MAX but instead
> hits undefined behavior maybe becomes negative and accesses out of array

Any code that relies on allocations > INT_MAX to fail is buggy and must
be fixed; and so is any code that uses an index parameter of type int
and uses a comparison with a value of type size_t as its loop condition.

- Andreas

*: Btw: AVFormatContext.nb_streams is unsigned, yet it is common to use
an int to loop over the streams. This is not dangerous now, as the
max_streams option is limited to INT_MAX. But we should probably change
this habit.
___
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

2020-11-08 Thread Michael Niedermayer 
On Sun, Nov 08, 2020 at 11:35:43AM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Fri, Oct 16, 2020 at 10:57:22AM +0200, Joakim Tjernlund wrote:
> >> From https://bugs.chromium.org/p/chromium/issues/detail?id=1095962
> >> 
> >> This seems to be caused by the custom handling of "av_max_alloc(0)" in
> >> Chromium's ffmpeg fork to mean unlimited (added in [1]).
> >>
> >> Upstream ffmpeg doesn't treat 0 as a special value; versions before 4.3 
> >> seemingly worked
> >> because 32 was subtracted from max_alloc_size (set to 0 by Chromium) 
> >> resulting in an
> >> integer underflow, making the effective limit be SIZE_MAX - 31.
> >>
> >> Now that the above underflow doesn't happen, the tab just crashes. The 
> >> upstream change
> >> for no longer subtracting 32 from max_alloc_size was included in ffmpeg 
> >> 4.3. [2]
> >>
> >> [1] 
> >> https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/73563
> >> [2] https://github.com/FFmpeg/FFmpeg/commit/731c77589841
> >> ---
> >>
> >> Restore av_malloc_max(0) to MAX_INT fixing MS Teams, Discord older 
> >> chromium etc.
> >>
> >> Signed-off-by: Joakim Tjernlund 
> >> ---
> >>
> >>  v2: Cover the full API range 0-31
> >>
> >>  v3: Closer compat with < 4.3 ffmpeg
> >>
> >>  v4: Adjust size accoriding to Andreas Rheinhardt comments
> >>
> >>  libavutil/mem.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> > 
> > "Unbreak av_malloc_max(0) API/ABI"
> > The commit message of this is incorrect
> > 
> > The API before and after this documented the current git master behavior
> > more correct would be
> > "Break API of av_malloc_max() for 0-31, to restore ABI behavior so 
> > applications using this do not need to be changed"
> > 
> 
> I agree.
> 
> > Also id like to raise awareness that this function had a big warning:
> > *
> > * @warning Exercise extreme caution when using this function. Don't 
> > touch
> > *  this if you do not understand the full consequence of doing 
> > so.
> > */
> > void av_max_alloc(size_t max);
> > 
> > And also id like to raise awareness that the default limit is INT_MAX
> > while with 0 as argument it becomes SIZE_MAX. 
> 
> No: With the old version 0 was effectively SIZE_MAX - 31, with current
> git head 0 means that all allocations of > 0 fail (yet requests of size
> 0 still result in an allocation of size 1); with the proposed version
> av_max_alloc(0) would set the limit to SIZE_MAX - 32. This off-by-one is
> surely unintentional.
> 

> I would expect that is
> > not safe everywhere and could open security issues.
> > If anything 0 should be interpreted as the default INT_MAX
> 
> That would be an API break.

yes, that was meant as a "less bad" alternative to SIZE_MAX - 31


> 
> > If its not obvious where SIZE_MAX can be an issue, consider what we
> > use to index arrays, int, and that doesnt go to SIZE_MAX but instead
> > hits undefined behavior maybe becomes negative and accesses out of array
> 
> Any code that relies on allocations > INT_MAX to fail is buggy and must
> be fixed;

YES


> and so is any code that uses an index parameter of type int
> and uses a comparison with a value of type size_t as its loop condition.

YES
though there are more complex failure cases
for example a
array[i + j*C]
here the 2 loops for i and j can have int limits and int indexes and still
if the array is not limited to INT_MAX this could go bad


> 
> - Andreas
> 
> *: Btw: AVFormatContext.nb_streams is unsigned, yet it is common to use
> an int to loop over the streams. This is not dangerous now, as the
> max_streams option is limited to INT_MAX. But we should probably change
> this habit.

yes

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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] libavformat/movenc.c: Fix avg_frame_rate inversion on timecode track writing

2020-11-08 Thread Ivan Baykalov 
When mov_create_timecode_track function is executed,
track->st->avg_frame_rate becomes inverted due to
track->st->avg_frame_rate = av_inv_q(rate);

, where "rate" is frame per second here.

I didn't find any obvious negative effect of this operation, but this may
lead to some misunderstanding. In particular, it's hard to say why number
of frames per second could be calculated as

nb_frames  = ROUNDED_DIV(track->st->avg_frame_rate.den,
track->st->avg_frame_rate.num);

---

 libavformat/movenc.c | 6 +++---

 1 file changed, 3 insertions(+), 3 deletions(-)



diff --git a/libavformat/movenc.c b/libavformat/movenc.c index
fea8a86192..e06c902c84 100644

--- a/libavformat/movenc.c

+++ b/libavformat/movenc.c

@@ -2352,8 +2352,8 @@ static int mov_write_tmcd_tag(AVIOContext *pb,
MOVTrack *track)

 return AVERROR(EINVAL);

 #endif

 } else {

-frame_duration = av_rescale(track->timescale,
track->st->avg_frame_rate.num, track->st->avg_frame_rate.den);

-nb_frames  = ROUNDED_DIV(track->st->avg_frame_rate.den,
track->st->avg_frame_rate.num);

+frame_duration = av_rescale(track->timescale,
track->st->avg_frame_rate.den, track->st->avg_frame_rate.num);

+nb_frames  = ROUNDED_DIV(track->st->avg_frame_rate.num,
track->st->avg_frame_rate.den);

 }



 if (nb_frames > 255) {

@@ -6190,7 +6190,7 @@ static int mov_create_timecode_track(AVFormatContext
*s, int index, int src_inde

 return AVERROR(ENOMEM);

 track->par->codec_type = AVMEDIA_TYPE_DATA;

 track->par->codec_tag  = track->tag;

-track->st->avg_frame_rate = av_inv_q(rate);

+track->st->avg_frame_rate = rate;



 /* the tmcd track just contains one packet with the frame number */

 AV_WB32(pkt.data, tc.start);

--

2.28.0.windows.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/nutenc: cosmetics

2020-11-08 Thread Andriy Gelman 
From: Andriy Gelman 

Realign from previous commit and fix typo in comment.
---
 libavformat/nutenc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index 5a775a92fe..0323984556 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -506,7 +506,7 @@ static int write_globalinfo(NUTContext *nut, AVIOContext 
*bc)
 while ((t = av_dict_get(s->metadata, "", t, AV_DICT_IGNORE_SUFFIX)))
 count += add_info(dyn_bc, t->key, t->value);
 
-put_v(bc, 0); //stream_if_plus1
+put_v(bc, 0); //stream_id_plus1
 put_v(bc, 0); //chapter_id
 put_v(bc, 0); //timestamp_start
 put_v(bc, 0); //length
@@ -996,11 +996,11 @@ static int nut_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 goto fail;
 }
 } else {
-if (1LL << (20 + 3 * nut->header_rep_count) <= avio_tell(bc)) {
-ret = write_headers(s, bc);
-if (ret < 0)
-goto fail;
-}
+if (1LL << (20 + 3 * nut->header_rep_count) <= avio_tell(bc)) {
+ret = write_headers(s, bc);
+if (ret < 0)
+goto fail;
+}
 }
 
 if (key_frame && !(nus->last_flags & FLAG_KEY))
-- 
2.28.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/4] avformat/nutenc: don't use header_count to store different variables

2020-11-08 Thread Andriy Gelman 
From: Andriy Gelman 

Currently, header_count is used to store both the elision header count
and the header repetition count (number of times headers have been written
to output). Fix this by using a separate variable to store repetition
count.

Signed-off-by: Andriy Gelman 
---
 libavformat/nut.h| 3 ++-
 libavformat/nutenc.c | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/nut.h b/libavformat/nut.h
index a4409ee23d..a990d3832e 100644
--- a/libavformat/nut.h
+++ b/libavformat/nut.h
@@ -103,7 +103,8 @@ typedef struct NUTContext {
 unsigned int time_base_count;
 int64_t last_syncpoint_pos;
 int64_t last_resync_pos;
-int header_count;
+int header_count;   // elision header count
+int header_rep_count;   // number of times headers written
 AVRational *time_base;
 struct AVTreeNode *syncpoints;
 int sp_count;
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index 1dcb2be1b1..87adef6f7e 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -684,7 +684,7 @@ static int write_headers(AVFormatContext *avctx, 
AVIOContext *bc)
 }
 
 nut->last_syncpoint_pos = INT_MIN;
-nut->header_count++;
+nut->header_rep_count++;
 
 ret = 0;
 fail:
@@ -988,7 +988,7 @@ static int nut_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 data_size += sm_size;
 }
 
-if (1LL << (20 + 3 * nut->header_count) <= avio_tell(bc))
+if (1LL << (20 + 3 * nut->header_rep_count) <= avio_tell(bc))
 write_headers(s, bc);
 
 if (key_frame && !(nus->last_flags & FLAG_KEY))
-- 
2.28.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/4] avformat/nutenc: add option to periodically insert global headers

2020-11-08 Thread Andriy Gelman 
From: Andriy Gelman 

Signed-off-by: Andriy Gelman 
---
 doc/muxers.texi  |  6 ++
 libavformat/nut.h|  3 ++-
 libavformat/nutenc.c | 10 ++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 813b4678f4..ace236fca6 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1822,6 +1822,12 @@ Change the syncpoint usage in nut:
 The @var{none} and @var{timestamped} flags are experimental.
 @item -write_index @var{bool}
 Write index at the end, the default is to write an index.
+@item -header_period @var{value}
+Sets how often global headers are re-inserted into the bytestream.
+Default value is -1. This inserts headers at exponentially increasing locations
+@math{2^23, 2^26, 2^29,...} etc.
+Setting parameter in the range @math{[0,62]}, will insert headers periodically
+after each @math{2^header_period} bytes at the next possible location.
 @end table
 
 @example
diff --git a/libavformat/nut.h b/libavformat/nut.h
index a990d3832e..c0928306c1 100644
--- a/libavformat/nut.h
+++ b/libavformat/nut.h
@@ -104,7 +104,8 @@ typedef struct NUTContext {
 int64_t last_syncpoint_pos;
 int64_t last_resync_pos;
 int header_count;   // elision header count
-int header_rep_count;   // number of times headers written
+int64_t header_rep_count;   // number of times headers written
+int header_period;  // header insertion option
 AVRational *time_base;
 struct AVTreeNode *syncpoints;
 int sp_count;
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index 0646f72af2..5a775a92fe 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -988,11 +988,20 @@ static int nut_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 data_size += sm_size;
 }
 
+if (nut->header_period >= 0) {
+if (avio_tell(bc) >> nut->header_period > nut->header_rep_count) {
+ret = write_headers(s, bc);
+nut->header_rep_count = avio_tell(bc) >> nut->header_period;
+if (ret < 0)
+goto fail;
+}
+} else {
 if (1LL << (20 + 3 * nut->header_rep_count) <= avio_tell(bc)) {
 ret = write_headers(s, bc);
 if (ret < 0)
 goto fail;
 }
+}
 
 if (key_frame && !(nus->last_flags & FLAG_KEY))
 store_sp = 1;
@@ -1221,6 +1230,7 @@ static const AVOption options[] = {
 { "none","Disable syncpoints, low overhead and unseekable", 0, 
AV_OPT_TYPE_CONST, {.i64 = NUT_PIPE},  INT_MIN, INT_MAX, E, 
"syncpoints" },
 { "timestamped", "Extend syncpoints with a wallclock timestamp",0, 
AV_OPT_TYPE_CONST, {.i64 = NUT_BROADCAST}, INT_MIN, INT_MAX, E, 
"syncpoints" },
 { "write_index", "Write index",   
OFFSET(write_index), AV_OPT_TYPE_BOOL,  {.i64 = 1},   0,   
1, E, },
+{ "header_period", "Header insertion parameter",  
OFFSET(header_period), AV_OPT_TYPE_INT, {.i64 =-1},  -1,  
62, E, },
 { NULL },
 };
 
-- 
2.28.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/4] avformat/nutenc: check return of write_headers()

2020-11-08 Thread Andriy Gelman 
From: Andriy Gelman 

Signed-off-by: Andriy Gelman 
---
 libavformat/nutenc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index 87adef6f7e..0646f72af2 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -988,8 +988,11 @@ static int nut_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 data_size += sm_size;
 }
 
-if (1LL << (20 + 3 * nut->header_rep_count) <= avio_tell(bc))
-write_headers(s, bc);
+if (1LL << (20 + 3 * nut->header_rep_count) <= avio_tell(bc)) {
+ret = write_headers(s, bc);
+if (ret < 0)
+goto fail;
+}
 
 if (key_frame && !(nus->last_flags & FLAG_KEY))
 store_sp = 1;
-- 
2.28.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] lavc/amfenc: HWConfig for amf encoder.

2020-11-08 Thread Mark Thompson 

On 28/10/2020 23:28, Dmitrii Ovchinnikov wrote:



This looks right, but can you clarify the intent behind the hw config
cases?  (Do you have an ffmpeg command line or other example which is
improved by them?)

Hi! This ticket describes the problem.

https://trac.ffmpeg.org/ticket/8953#ticket

I added a proper explanation to the commit message and applied with that.

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 4/5] avformat/lvfdec: Check stream_index before use

2020-11-08 Thread Paul B Mahol 
LGTM

On Sun, Nov 8, 2020 at 12:18 AM Michael Niedermayer 
wrote:

> Fixes: assertion failure
> Fixes:
> 26905/clusterfuzz-testcase-minimized-ffmpeg_dem_LVF_fuzzer-5724267599364096.fuzz
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavformat/lvfdec.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/lvfdec.c b/libavformat/lvfdec.c
> index 8b8d6f01b9..4c87728def 100644
> --- a/libavformat/lvfdec.c
> +++ b/libavformat/lvfdec.c
> @@ -106,6 +106,7 @@ static int lvf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
>  unsigned size, flags, timestamp, id;
>  int64_t pos;
>  int ret, is_video = 0;
> +int stream_index;
>
>  pos = avio_tell(s->pb);
>  while (!avio_feof(s->pb)) {
> @@ -121,12 +122,15 @@ static int lvf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
>  case MKTAG('0', '1', 'w', 'b'):
>  if (size < 8)
>  return AVERROR_INVALIDDATA;
> +stream_index = is_video ? 0 : 1;
> +if (stream_index >= s->nb_streams)
> +return AVERROR_INVALIDDATA;
>  timestamp = avio_rl32(s->pb);
>  flags = avio_rl32(s->pb);
>  ret = av_get_packet(s->pb, pkt, size - 8);
>  if (flags & (1 << 12))
>  pkt->flags |= AV_PKT_FLAG_KEY;
> -pkt->stream_index = is_video ? 0 : 1;
> +pkt->stream_index = stream_index;
>  pkt->pts  = timestamp;
>  pkt->pos  = pos;
>  return ret;
> --
> 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".

Re: [FFmpeg-devel] [PATCH 1/4] avformat/nutenc: don't use header_count to store different variables

2020-11-08 Thread Andreas Rheinhardt 
Andriy Gelman:
> From: Andriy Gelman 
> 
> Currently, header_count is used to store both the elision header count
> and the header repetition count (number of times headers have been written
> to output). Fix this by using a separate variable to store repetition
> count.
> 
> Signed-off-by: Andriy Gelman 
> ---
>  libavformat/nut.h| 3 ++-
>  libavformat/nutenc.c | 4 ++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/nut.h b/libavformat/nut.h
> index a4409ee23d..a990d3832e 100644
> --- a/libavformat/nut.h
> +++ b/libavformat/nut.h
> @@ -103,7 +103,8 @@ typedef struct NUTContext {
>  unsigned int time_base_count;
>  int64_t last_syncpoint_pos;
>  int64_t last_resync_pos;
> -int header_count;
> +int header_count;   // elision header count
> +int header_rep_count;   // number of times headers written
>  AVRational *time_base;
>  struct AVTreeNode *syncpoints;
>  int sp_count;
> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> index 1dcb2be1b1..87adef6f7e 100644
> --- a/libavformat/nutenc.c
> +++ b/libavformat/nutenc.c
> @@ -684,7 +684,7 @@ static int write_headers(AVFormatContext *avctx, 
> AVIOContext *bc)
>  }
>  
>  nut->last_syncpoint_pos = INT_MIN;
> -nut->header_count++;
> +nut->header_rep_count++;
>  
>  ret = 0;
>  fail:
> @@ -988,7 +988,7 @@ static int nut_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  data_size += sm_size;
>  }
>  
> -if (1LL << (20 + 3 * nut->header_count) <= avio_tell(bc))
> +if (1LL << (20 + 3 * nut->header_rep_count) <= avio_tell(bc))
>  write_headers(s, bc);
>  
>  if (key_frame && !(nus->last_flags & FLAG_KEY))
> 
1. You are not the first to notice this:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200505141657.10787-2-andreas.rheinha...@gmail.com/
2. Your patch is incomplete: header_count is also used in write_trailer.
If you use the correct value there, you will have to update lots of
fate-tests (see the above commit). (The fate updates of that old patch
need to be updated (and were incomplete anyway because I did not ran
tests for gpl-components*).
3. The reason the above patch (or rather patchset) has not been applied
is that there is actually a subtle bug with chapters: Users are allowed
to add new chapters after writing the header (some muxer then write the
chapters when writing the trailer). Yet this doesn't work with nut right
now: See the commit message of the preceding patch
(https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200505141657.10787-1-andreas.rheinha...@gmail.com/)
for details.

- Andreas

*: I only noticed this through patchwork, so thank you again for this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avfilter: add speechnorm filter

2020-11-08 Thread Paul B Mahol 
Signed-off-by: Paul B Mahol 
---
 doc/filters.texi|  57 +
 libavfilter/Makefile|   1 +
 libavfilter/af_speechnorm.c | 441 
 libavfilter/allfilters.c|   1 +
 4 files changed, 500 insertions(+)
 create mode 100644 libavfilter/af_speechnorm.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 8380f6cac2..7343632f42 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5276,6 +5276,63 @@ and also with custom gain:
 @end example
 @end itemize
 
+@section speechnorm
+Speech Normalizer.
+
+This filter expands or compress each half-cycle of audio samples
+(local set of samples all above or all bellow zero) depending on threshold 
value,
+so audio reaches target peak value under conditions controlled by bellow 
options.
+
+The filter accepts the following options:
+
+@table @option
+@item peak, p
+Set the expansion target peak value. This specifies the highest allowed 
absolute amplitude
+level for the normalized audio input. Default value is 0.95. Allowed range is 
from 0.0 to 1.0.
+
+@item expansion, e
+Set the maximum expansion factor. Allowed range is from 1.0 to 50.0. Default 
value is 2.0.
+This option controls maximum local half-cycle of samples expansion. The 
maximum expansion
+would be such that local peak value reach target peak value but never to 
surpass it and that
+ratio between new and previous peak value does not surpass this option value.
+
+@item compression, c
+Set the maximum compression factor. Allowed range is from 1.0 to 50.0. Default 
value is 2.0.
+This option controls maximum local half-cycle of samples compression. This 
option is used
+only if @option{threshold} option is set to value greater than 0.0, than in 
such cases
+when local peak is lower or same as value set by @option{threshold} all 
samples belonging to
+that peak's half-cycle would be compressed by current compression factor.
+
+@item threshold, t
+Set the threshold value. Default value is 0.0. Allowed range is from 0.0 to 
1.0.
+This option specify which half-cycles of samples will be compressed and which 
will be expanded.
+Any half-cycle samples with their local peak value bellow or same as this 
option value will be
+compressed by current compression factor, otherwise, if greater than threshold 
value it will be
+expanded with expansion factor so that it could reach peak target value but 
never surpass it.
+
+@item raise, r
+Set the expansion raising amount per each half-cycle of samples. Default value 
is 0.001.
+Allowed range is from 0.0 to 1.0. This controls how fast expansion factor is 
raised per
+each new half-cycle until it reaches @option{expansion} value.
+
+@item fall, f
+Set the compression raising amount per each half-cycle of samples. Default 
value is 0.001.
+Allowed range is from 0.0 to 1.0. This controls how fast compression factor is 
raised per
+each new half-cycle until it reaches @option{compression} value.
+
+@item channels, h
+Specify which channels to filter, by default all available channels are 
filtered.
+
+@item invert, i
+Enable inverted filtering, by default is disabled. This inverts interpretation 
of @option{threshold}
+option. When enabled any half-cycle of samples with their local peak value 
bellow or same as
+@option{threshold} option will be expanded otherwise it will be compressed.
+@end table
+
+@subsection Commands
+
+This filter supports the all above options as @ref{commands}.
+
 @section stereotools
 
 This filter has some handy utilities to manage stereo signals, for converting
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 0c2a5d1cf4..36f3d2d0e4 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -138,6 +138,7 @@ OBJS-$(CONFIG_SIDECHAINGATE_FILTER)  += af_agate.o
 OBJS-$(CONFIG_SILENCEDETECT_FILTER)  += af_silencedetect.o
 OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += af_silenceremove.o
 OBJS-$(CONFIG_SOFALIZER_FILTER)  += af_sofalizer.o
+OBJS-$(CONFIG_SPEECHNORM_FILTER) += af_speechnorm.o
 OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
 OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o
 OBJS-$(CONFIG_SUPEREQUALIZER_FILTER) += af_superequalizer.o
diff --git a/libavfilter/af_speechnorm.c b/libavfilter/af_speechnorm.c
new file mode 100644
index 00..75ed60be7b
--- /dev/null
+++ b/libavfilter/af_speechnorm.c
@@ -0,0 +1,441 @@
+/*
+ * Speech Normalizer
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * 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 Ge

Re: [FFmpeg-devel] [PATCH 08/10] avformat/nutenc: Cosmetics

2020-11-08 Thread Michael Niedermayer 
On Mon, May 04, 2020 at 08:22:48PM +0200, Andreas Rheinhardt wrote:
> Mainly reindentation.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/nutenc.c | 42 ++
>  1 file changed, 22 insertions(+), 20 deletions(-)

probably ok

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- 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".

Re: [FFmpeg-devel] [PATCH 11/12] avformat/nutenc: Don't segfault when chapters are added during muxing

2020-11-08 Thread Michael Niedermayer 
On Thu, May 07, 2020 at 05:49:06PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Tue, May 05, 2020 at 04:16:56PM +0200, Andreas Rheinhardt wrote:
> >> When writing the header, the NUT muxer allocates an array with as many
> >> entries as there are chapters containing information about the used
> >> timebase. This information is used when writing the headers and also
> >> when resending the headers (as the NUT muxer does from time to time).
> >>
> >> When the NUT muxer writes or resends the headers, it simply presumes
> >> that there are enough entries in its array for each chapter in the
> >> AVFormatContext. Yet users are allowed to add chapters during the muxing
> >> process, so this presumption is wrong and may lead to segfaults.
> >>
> >> So explicitly store the number of entries of the chapter array and refer
> >> to this number whenever headers are written.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >> This patch presumes that the user may not change or remove the chapters
> >> available during writing the header (if there were chapters available
> >> when writing the header at all). I hope this is ok.
> >>
> >>  libavformat/nut.h| 1 +
> >>  libavformat/nutenc.c | 3 ++-
> >>  2 files changed, 3 insertions(+), 1 deletion(-)
> > 
> > how do i apply this (for testing) ?
> 
> When you test this, you should be aware that the first time the header
> is repeated is after 16 TiB of output (see patch #12 for the reason), so
> you should better change the following line in nut_write_packet() to
> reduce said interval:
> if (1LL << (20 + 3 * nut->header_count) <= avio_tell(bc))
> 
> > on its own it fails and it seems the previous patchset doesnt like applying
> > anymore either 
> > 
> I have already applied patches 1-4 + 9 (that you said were ok) from this
> patchset. Patches 5-8 and 10-11 apply cleanly on top of master. Did you
> try to also apply the patches that have already been merged?
> 
> (Patch #12 does not apply cleanly any more, because of the changes to
> the ref files in b4967fc71c63eae8cd96f9c46cd3e1fbd705bbf9. Furthermore
> my patch as sent only updated a subset of fate-tests, because my build
> was not configured with enable-gpl. I already fixed this. Normally I'd
> resend the mail, but given its huge size I'd like to avoid that this
> time. Should I send it?)
> 
> > 
> >>
> >> diff --git a/libavformat/nut.h b/libavformat/nut.h
> >> index a4409ee23d..52225fed93 100644
> >> --- a/libavformat/nut.h
> >> +++ b/libavformat/nut.h
> >> @@ -115,6 +115,7 @@ typedef struct NUTContext {
> >>  int flags;
> >>  int version; // version currently in use
> >>  int minor_version;
> >> +unsigned nb_chapters;
> >>  } NUTContext;
> >>  
> >>  extern const AVCodecTag ff_nut_subtitle_tags[];
> >> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> >> index 5071278835..2d35c44b79 100644
> >> --- a/libavformat/nutenc.c
> >> +++ b/libavformat/nutenc.c
> >> @@ -675,7 +675,7 @@ static int write_headers(AVFormatContext *avctx, 
> >> AVIOContext *bc)
> >>  goto fail;
> >>  }
> >>  
> >> -for (i = 0; i < nut->avf->nb_chapters; i++) {
> >> +for (i = 0; i < nut->nb_chapters; i++) {
> >>  write_chapter(nut, dyn_bc, i, prelude, &prelude_size);
> > 
> > also if i read this correctly, this would not write all chapters.
> > That seems not ideal
> 
> It's indeed not ideal; it is designed to fix a potential segfault, not
> to add functionality. (Without this patch patch #12 would run into this
> bug more often.)

how hard is it to fix this correctly ?
if its really alot of code sure its ok to do a simple fix for something
like backporting ...


> 
> I don't know NUT very well, but I see two ways how this could be
> implemented:

> 1. One adds the timebases of these chapters to the arrays of timebases
> that already exist and writes the chapters with their timebases. This
> would involve moving code from nut_write_header() to write_headers(). I
> don't know whether adding a new timebase mid-stream is even allowed by
> the spec.

no i dont think you can add timebases mid stream currently.Iam not even sure how
much sense that makes when you cannot add streams mid stream


> 2. One writes the chapters with the best timebase available for them,
> even when it is not an exact match.

i would be interrested in cases where an exact match is not available
that said i dont care much about what happens when the user provided
chapters are not representable in the format. Error out, drop, approximate.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


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 12/12] avformat/nutenc: Fix repeating headers

2020-11-08 Thread Michael Niedermayer 
On Thu, May 07, 2020 at 06:05:01PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Tue, May 05, 2020 at 04:16:57PM +0200, Andreas Rheinhardt wrote:
[...]
> > 
> >> I am also unsure why the size difference between successive headers
> >> grows exponentially.
> > 
> > I think i dont understand what you say here.
> > The size of each header should not grow exponentially relativly to the
> > previous
> > 
> I did not mean the size of the header, but the position/offsets of the
> headers. I specifically meant this line:
> if (1LL << (20 + 3 * nut->header_count) <= avio_tell(bc))
> which in its current form that the first repeated header will be written
> after 16 TiB, then another one after 128 TiB (i.e. after further 112
> TiB) and so on.

The intend here was to write the redundant set of headers after maybe a mb

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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/nutenc: don't use header_count to store different variables

2020-11-08 Thread Andriy Gelman 
On Mon, 09. Nov 00:04, Andreas Rheinhardt wrote:
> Andriy Gelman:
> > From: Andriy Gelman 
> > 
> > Currently, header_count is used to store both the elision header count
> > and the header repetition count (number of times headers have been written
> > to output). Fix this by using a separate variable to store repetition
> > count.
> > 
> > Signed-off-by: Andriy Gelman 
> > ---
> >  libavformat/nut.h| 3 ++-
> >  libavformat/nutenc.c | 4 ++--
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavformat/nut.h b/libavformat/nut.h
> > index a4409ee23d..a990d3832e 100644
> > --- a/libavformat/nut.h
> > +++ b/libavformat/nut.h
> > @@ -103,7 +103,8 @@ typedef struct NUTContext {
> >  unsigned int time_base_count;
> >  int64_t last_syncpoint_pos;
> >  int64_t last_resync_pos;
> > -int header_count;
> > +int header_count;   // elision header count
> > +int header_rep_count;   // number of times headers written
> >  AVRational *time_base;
> >  struct AVTreeNode *syncpoints;
> >  int sp_count;
> > diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> > index 1dcb2be1b1..87adef6f7e 100644
> > --- a/libavformat/nutenc.c
> > +++ b/libavformat/nutenc.c
> > @@ -684,7 +684,7 @@ static int write_headers(AVFormatContext *avctx, 
> > AVIOContext *bc)
> >  }
> >  
> >  nut->last_syncpoint_pos = INT_MIN;
> > -nut->header_count++;
> > +nut->header_rep_count++;
> >  
> >  ret = 0;
> >  fail:
> > @@ -988,7 +988,7 @@ static int nut_write_packet(AVFormatContext *s, 
> > AVPacket *pkt)
> >  data_size += sm_size;
> >  }
> >  
> > -if (1LL << (20 + 3 * nut->header_count) <= avio_tell(bc))
> > +if (1LL << (20 + 3 * nut->header_rep_count) <= avio_tell(bc))
> >  write_headers(s, bc);
> >  
> >  if (key_frame && !(nus->last_flags & FLAG_KEY))
> > 
> 1. You are not the first to notice this:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200505141657.10787-2-andreas.rheinha...@gmail.com/

The goal of my set was to help user in [1] by adding option to insert periodic
headers (see patch 3).
http://ffmpeg.org/pipermail/ffmpeg-user/2020-November/050690.html

> 2. Your patch is incomplete: header_count is also used in write_trailer.
> If you use the correct value there, you will have to update lots of
> fate-tests (see the above commit). (The fate updates of that old patch
> need to be updated (and were incomplete anyway because I did not ran
> tests for gpl-components*).

It has been dead code since the header elision support was added.
Would it make sense to remove that code in write_trailer()? This would simplify
your patch.

> 3. The reason the above patch (or rather patchset) has not been applied
> is that there is actually a subtle bug with chapters: Users are allowed
> to add new chapters after writing the header (some muxer then write the
> chapters when writing the trailer). Yet this doesn't work with nut right
> now: See the commit message of the preceding patch
> (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200505141657.10787-1-andreas.rheinha...@gmail.com/)
> for details.

I'd have to look at your set in more detail, but I thought repeated headers had
to be the same as original ones. From the spec:

"Headers may be repeated, but if they are, then all mandatory headers MUST be
repeated and repeated headers MUST be identical."

-- 
Andriy
___
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/1] avfilter/vf_lut3d: fix sanitizef INF handling

2020-11-08 Thread mindmark 
From: Mark Reid 

---
 libavfilter/vf_lut3d.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 988f6c8b55..172d6df0c8 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -107,7 +107,7 @@ typedef struct ThreadData {
 
 #define EXPONENT_MASK 0x7F80
 #define MANTISSA_MASK 0x007F
-#define SIGN_MASK 0x7FFF
+#define SIGN_MASK 0x8000
 
 static inline float sanitizef(float f)
 {
@@ -120,7 +120,7 @@ static inline float sanitizef(float f)
 return 0.0f;
 } else if (t.i & SIGN_MASK) {
 // -INF
-return FLT_MIN;
+return -FLT_MAX;
 } else {
 // +INF
 return FLT_MAX;
-- 
2.27.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add support for Screen Content Coding (SCC) extension

2020-11-08 Thread Xiang, Haihao 

@Zhong, @Mark

Could you take a look at this patch when you get a chance?

Thanks
Haihao

> 
> > This patch adds support for SCC encoding on ICL+ platform
> 
> Sample pipeline:
> ffmpeg -init_hw_device qsv=qsv:hw -f lavfi -i testsrc -vf \
> "format=nv12,hwupload=extra_hw_frames=64,format=qsv" -c:v hevc_qsv \
> -profile:v scc -low_power 1 out.h265
> ---
>  libavcodec/qsvenc.c  | 3 +++
>  libavcodec/qsvenc_hevc.c | 3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 1ed8f5d973..29750735e0 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -69,6 +69,9 @@ static const struct {
>  { MFX_PROFILE_HEVC_MAINSP,  "mainsp"},
>  { MFX_PROFILE_HEVC_REXT,"rext"  },
>  #endif
> +#if QSV_VERSION_ATLEAST(1, 32)
> +{ MFX_PROFILE_HEVC_SCC, "scc"   },
> +#endif
>  };
>  
>  static const char *print_profile(mfxU16 profile)
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> index 347f30655e..663f21439f 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -241,6 +241,9 @@ static const AVOption options[] = {
>  { "main10",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_HEVC_MAIN10  }, INT_MIN, INT_MAX, VE, "profile" },
>  { "mainsp",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_HEVC_MAINSP  }, INT_MIN, INT_MAX, VE, "profile" },
>  { "rext",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_HEVC_REXT}, INT_MIN, INT_MAX, VE, "profile" },
> +#if QSV_VERSION_ATLEAST(1, 32)
> +{ "scc", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_HEVC_SCC }, INT_MIN, INT_MAX, VE, "profile" },
> +#endif
>  
>  { "gpb", "1: GPB (generalized P/B frame); 0: regular P frame",
> OFFSET(qsv.gpb), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE},
>  
___
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] lavc/qsvenc: allows the SDK runtime to choose LowPower/non-LowPower modes

2020-11-08 Thread Xiang, Haihao 

@Zhong, @Mark

Could you take a look at this patch when you get a chance?

Thanks
Haihao


> The SDK supports LowPower and non-LowPower modes, but some features are
> available only under one of the two modes. Currently non-LowPower mode
> is always chosen in FFmpeg if the mode is not set explicitly, which will
> result in some SDK errors if a feature is unavailable under non-LowPower
> mode. With this patch, the mode is unknown in FFmpeg if the mode is not
> set explicitly, the SDK is responsible for mode selection
> ---
> This is the new version for "lavc/qsvenc: let the SDK to choose the
> encoding mode by default" and the git commit log is updated only
> 
>  libavcodec/qsvenc.c | 6 --
>  libavcodec/qsvenc.h | 2 +-
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 1ed8f5d973..cff96e59c9 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -510,7 +510,7 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  }
>  }
>  
> -if (q->low_power) {
> +if (q->low_power == 1) {
>  #if QSV_HAVE_VDENC
>  q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
>  #else
> @@ -519,7 +519,9 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  q->low_power = 0;
>  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>  #endif
> -} else
> +} else if (q->low_power == -1)
> +q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
> +else
>  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>  
>  q->param.mfx.CodecProfile   = q->profile;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index 4f579d1db1..55cc1a 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -96,7 +96,7 @@
>  { "adaptive_b", "Adaptive B-frame
> placement", OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1,  1, VE }, \
>  { "b_strategy", "Strategy to choose between I/P/B-frames",
> OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE
> }, \
>  { "forced_idr", "Forcing I frames as IDR
> frames", OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 =
> 0  },  0,  1, VE }, \
> -{ "low_power", "enable low power mode(experimental: many limitations by mfx
> version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
> 0}, 0, 1, VE},\
> +{ "low_power", "enable low power mode(experimental: many limitations by mfx
> version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
> -1}, -1, 1, VE},\
>  
>  extern const AVCodecHWConfigInternal *ff_qsv_enc_hw_configs[];
>  
___
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/1] avcodec/exr: use lookuptable for alpha if there is no trc_func

2020-11-08 Thread mindmark 
From: Mark Reid 

---
 libavcodec/exr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index cf7824402a..e907c5c464 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1203,7 +1203,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 }
 } else if (s->pixel_type == EXR_HALF) {
 // 16-bit
-if (c < 3) {
+if (c < 3 || !trc_func) {
 for (x = 0; x < xsize; x++) {
 *ptr_x++ = 
s->gamma_table[bytestream_get_le16(&src)];
 }
-- 
2.27.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".