Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Remove messing with jpeg context

[Paul B Mahol]

Please confirm you are not breaking tile files in any way.

On Sat, Dec 25, 2021 at 11:43 PM Michael Niedermayer 
wrote:

> The whole concept is just not correct, also as it seems not to be needed
> at all, all dng files i have decode without this.
>
> Fixes: various crashes
> Fixes:
> 42937/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-4625073334517760
> Fixes:
> 42938/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-4643368217477120
> Fixes:
> 42939/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-4925325908246528
> Fixes:
> 42940/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-4925378806808576
> Fixes:
> 42941/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6202009265504256
> Fixes:
> 42944/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6076860998483968
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/tiff.c | 24 ++--
>  1 file changed, 2 insertions(+), 22 deletions(-)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index 60773d59ed0..fd85d104dc4 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -721,20 +721,6 @@ static int dng_decode_jpeg(AVCodecContext *avctx,
> AVFrame *frame,
>  return 0;
>  }
>
> -static int dng_decode_strip(AVCodecContext *avctx, AVFrame *frame)
> -{
> -TiffContext *s = avctx->priv_data;
> -int ret = ff_set_dimensions(s->avctx_mjpeg, s->width, s->height);
> -
> -if (ret < 0)
> -return ret;
> -
> -s->jpgframe->width  = s->width;
> -s->jpgframe->height = s->height;
> -
> -return dng_decode_jpeg(avctx, frame, s->stripsize, 0, 0, s->width,
> s->height);
> -}
> -
>  static int tiff_unpack_strip(TiffContext *s, AVFrame *p, uint8_t *dst,
> int stride,
>   const uint8_t *src, int size, int
> strip_start, int lines)
>  {
> @@ -856,7 +842,7 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame
> *p, uint8_t *dst, int strid
>  av_log(s->avctx, AV_LOG_ERROR, "More than one DNG JPEG strips
> unsupported\n");
>  return AVERROR_PATCHWELCOME;
>  }
> -if ((ret = dng_decode_strip(s->avctx, p)) < 0)
> +if ((ret = dng_decode_jpeg(s->avctx, p, s->stripsize, 0, 0,
> s->width, s->height)) < 0)
>  return ret;
>  return 0;
>  }
> @@ -972,13 +958,7 @@ static int dng_decode_tiles(AVCodecContext *avctx,
> AVFrame *frame,
>  int has_width_leftover, has_height_leftover;
>  int tile_x = 0, tile_y = 0;
>  int pos_x = 0, pos_y = 0;
> -int ret = ff_set_dimensions(s->avctx_mjpeg, s->tile_width,
> s->tile_length);
> -
> -if (ret < 0)
> -return ret;
> -
> -s->jpgframe->width  = s->tile_width;
> -s->jpgframe->height = s->tile_length;
> +int ret;
>
>  has_width_leftover = (s->width % s->tile_width != 0);
>  has_height_leftover = (s->height % s->tile_length != 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Remove messing with jpeg context

[Michael Niedermayer]

On Sun, Dec 26, 2021 at 09:50:28AM +0100, Paul B Mahol wrote:
> Please confirm you are not breaking tile files in any way.

Ive tested both strip and tile dng/tiff files

Thats what i tested with:

1_1.1.1.dpx 
1_1.2.1.dpx 
1_1.3.1.dpx 
A001_C022_20171009_R00100.dng 
Footage_01/A003_C001_20170717_R00446.dng
RAW_ONEPLUS_ONE-A0001.DNG 
SCANNER_NIKON_LS5000.DNG
pentax_k1_69.dng
z8pf.dng
00119443.DNG
IMG_3459.dng

if you have files which cover other configurations, iam happy to test them too

thx

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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/speexdec: Consider mode in frame size check

[Michael Niedermayer]

No speex samples with non default frame sizes are known (to me)
the official speexenc seems to only generate the 3 default ones.
Thus it may be that the fuzzer samples where the first non default
values encountered by the decoder.
Possibly the "<" should be "!="

If someone has a valid speex file with non default frame sizes that
would be interesting!

Fixes: out of array access
Fixes: 
42821/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-5640695772217344

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/speexdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/speexdec.c b/libavcodec/speexdec.c
index 1c33607db27..dcbdf5e010a 100644
--- a/libavcodec/speexdec.c
+++ b/libavcodec/speexdec.c
@@ -1419,7 +1419,7 @@ static int parse_speex_extradata(AVCodecContext *avctx,
 return AVERROR_INVALIDDATA;
 s->bitrate = bytestream_get_le32(&buf);
 s->frame_size = bytestream_get_le32(&buf);
-if (s->frame_size < NB_FRAME_SIZE)
+if (s->frame_size < NB_FRAME_SIZE << s->mode)
 return AVERROR_INVALIDDATA;
 s->vbr = bytestream_get_le32(&buf);
 s->frames_per_packet = bytestream_get_le32(&buf);
-- 
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] http: make caching of redirect url optional

[Ronald S. Bultje]

Hi,

(I was asked to respond since I'm listed as HTTP maintainer, not sure I
should be since I'm mostly working on video codecs nowadays.)

On Tue, Nov 2, 2021 at 9:00 AM Eran Kornblau 
wrote:

> The motivation for this feature is S3 signatures – currently we have a
> problem where S3 signatures cannot be created
> with an expiration of more than 12H. In some cases, a transcoding task may
> execute for more than that.
> If we use a pre-signed S3 URL, and ffmpeg disconnects/seeks after the
> expiration of the URL, it will fail.
>
> The solution we are planning is to have some local server on the machine
> running ffmpeg that will generate an S3-signature,
> and redirect to the full pre-signed URL. For this to work, I need to
> disable the caching of redirects, and have ffmpeg always
> start from the initial URL.
> The nice thing about this solution is that the video data is pulled
> directly from S3 – in other words, the local server doesn’t
> hold any real load, it just builds the signature and returns a redirect.
>

Uhm... This is a really weird solution, but it does look right.

Generally speaking, we're typically concerned about the default being the
right behaviour. I would say that (maybe after some time, at the next ABI
break or so), 0 should be the default, not 1. This is the same as what
Marton/Hendrik said also, I think, so consider this consensus. I would just
do that with the appropriate ABI macros so the default behaviour changes at
the next bump.

Patch itself is fine, it has some whitespace change at line 430 and 621
that is not really necessary, but otherwise no objections from me.

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

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

[FFmpeg-devel] [PATCH v3] avformat/mov: add option max_stts_delta

[Gyan Doshi]

Very high stts sample deltas may occasionally be intended but usually
they are written in error or used to store a negative value for dts correction
when treated as signed 32-bit integers.

This option lets the user set an upper limit, beyond which the delta is clamped 
to 1.
Values greater than the limit if negative when cast to int32 are used to adjust 
onward dts.

Unit is the track time scale. Default is UINT_MAX - 48000*10 which
allows upto a 10 second dts correction for 48 kHz audio streams while
accommodating 99.9% of uint32 range.
---
v3 changes:

factored out loop
simplified correction logic
added doc

 doc/demuxers.texi  |  9 
 libavformat/isom.h |  1 +
 libavformat/mov.c  | 55 +-
 3 files changed, 40 insertions(+), 25 deletions(-)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index cab8a7072c..99d4ab7bc5 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -713,6 +713,15 @@ specify.
 
 @item decryption_key
 16-byte key, in hex, to decrypt files encrypted using ISO Common Encryption 
(CENC/AES-128 CTR; ISO/IEC 23001-7).
+
+@item max_stts_delta
+Very high sample deltas written in a trak's stts box may occasionally be 
intended but usually they are written in
+error or used to store a negative value for dts correction when treated as 
signed 32-bit integers. This option lets
+the user set an upper limit, beyond which the delta is clamped to 1. Values 
greater than the limit if negative when
+cast to int32 are used to adjust onward dts.
+
+Unit is the track time scale. Range is 0 to UINT_MAX. Default is 
@code{UINT_MAX - 48000*10} which allows upto
+a 10 second dts correction for 48 kHz audio streams while accommodating 99.9% 
of @code{uint32} range.
 @end table
 
 @subsection Audible AAX
diff --git a/libavformat/isom.h b/libavformat/isom.h
index ef8f19b18c..625dea8421 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -305,6 +305,7 @@ typedef struct MOVContext {
 int32_t movie_display_matrix[3][3]; ///< display matrix from mvhd
 int have_read_mfra_size;
 uint32_t mfra_size;
+uint32_t max_stts_delta;
 } MOVContext;
 
 int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..f93c8bef31 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2925,6 +2925,8 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 unsigned int i, entries, alloc_size = 0;
 int64_t duration = 0;
 int64_t total_sample_count = 0;
+int64_t current_dts = 0;
+int64_t corrected_dts = 0;
 
 if (c->fc->nb_streams < 1)
 return 0;
@@ -2965,11 +2967,34 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 sc->stts_data[i].count= sample_count;
 sc->stts_data[i].duration= sample_duration;
 
-av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n",
+av_log(c->fc, AV_LOG_TRACE, "sample_count=%u, sample_duration=%u\n",
 sample_count, sample_duration);
 
-duration+=(int64_t)sample_duration*(uint64_t)sample_count;
-total_sample_count+=sample_count;
+/* STTS sample offsets are uint32 but some files store it as int32
+ * with negative values used to correct DTS delays.
+   There may be abnormally large values as well. */
+if (sample_duration > c->max_stts_delta) {
+// assume high delta is a correction if negative when cast as int32
+int32_t delta_magnitude = (int32_t)sample_duration;
+av_log(c->fc, AV_LOG_WARNING, "Too large sample offset %u in stts 
entry %u with count %u in st:%d. Clipping to 1.\n",
+   sample_duration, i, sample_count, st->index);
+sc->stts_data[i].duration = 1;
+corrected_dts += (delta_magnitude < 0 ? (int64_t)delta_magnitude : 
1) * sample_count;
+} else {
+corrected_dts += sample_duration * sample_count;
+}
+
+current_dts += sc->stts_data[i].duration * sample_count;
+
+if (current_dts > corrected_dts) {
+int64_t drift = (current_dts - corrected_dts)/sample_count;
+uint32_t correction = (sc->stts_data[i].duration > drift) ? drift 
: sc->stts_data[i].duration - 1;
+current_dts -= correction * sample_count;
+sc->stts_data[i].duration -= correction;
+}
+
+
duration+=(int64_t)sc->stts_data[i].duration*(uint64_t)sc->stts_data[i].count;
+total_sample_count+=sc->stts_data[i].count;
 }
 
 sc->stts_count = i;
@@ -3856,13 +3881,10 @@ static void mov_build_index(MOVContext *mov, AVStream 
*st)
 unsigned int distance = 0;
 unsigned int rap_group_index = 0;
 unsigned int rap_group_sample = 0;
-int64_t last_dts = 0;
-int64_t dts_correction = 0;
 int rap_group_present = sc->rap_group_count && sc->rap_group;
 int key_off = (sc->keyframe_count && sc->keyframes[0] 

Re: [FFmpeg-devel] GitHub Integration

[Lynne]

26 Dec 2021, 02:03 by l...@chinaffmpeg.org:

>
>
>> 在 2021年12月26日，上午8:55，lance.lmw...@gmail.com 写道：
>>
>> On Sat, Dec 25, 2021 at 05:15:19PM +, Soft Works wrote:
>>
>>>
>>>
 -Original Message-
 From: ffmpeg-devel  On Behalf Of Lynne
 Sent: Saturday, December 25, 2021 5:50 PM
 To: FFmpeg development discussions and patches 
 Subject: Re: [FFmpeg-devel] GitHub Integration

 23 Dec 2021, 00:24 by softwo...@hotmail.com:

> Hi,
>
> holidays are approaching and I got a little present for all of you
> even though it won’t be something for everybody.
>
> A while ago I had committed to prepare a test setup for integrating
> GitHub in a similar way as the Git developers are doing.
>
> For those who missed it or don’t remember the outcome:
> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html
> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html
>
> Before someone’s temperature might start rising, I want to repeat
> some important corner points:
>
> - it's not a migration nor the start of a migration
> - nothing changes, it doesn't affect anybody's way of working
> it doesn't replace anything
> - it's an add-on that one could use or not
>
> Basic functionality is that it allows to submit patches to the ML
> through GitHub pull requests.
>
> Right now must features are working, but e-mails are not sent to
> the ML yet, just to one's own e-mail address.
>
>
> I don't want to post the repository location publicly at this time,
> but for anybody who would be interested in taking a look at this,
> please send me an e-mail or PM me on IRC.
>

 I'd rather we move away from ML development altogether.
 There's general consensus already, and of course one or
 two who'd rather not.

>>>
>>> I'd prefer that as well, but in back in summer there were quite a number
>>> of developers (> 2) indicating that they are fine with the 
>>> ML approach, so I'm not really sure about whether and when this 
>>> will happen eventually.
>>>
>>> This GitHub-PR-Bridge is not meant to be an alternative or replacement
>>> for an eventual full migration to another platform.
>>>
>>> It's just an interim solution until a migration will eventually happen
>>> (probably like in the 2030ies.. ;-)
>>>
>>
>> My point:
>> 1, In China network environment, when accessing Github, the network will be
>> blocked or very slow.
>> 2, For gmail is blocked, so I prefer to use cli, remote ssh to a cloud host,
>> use mutt/vim for ML email, and scp, and git cli tools are professional to do
>> everything for the patchset send, push etc. Yes, I can use socket5 to 
>> forward,
>> but I like cli instead of web for I prefer to use keyboard instead of mouse.
>>
>
> +1
>

We'd never move to Github, that much's for sure. Videolan already
hosts a Gitlab instance, and I doubt the great firewall would have an
issue with that.
___
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] [RFC] avdevice: lock to minor version of avformat

[Diederick Niehorster]

As per discussion on the list (
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see
especially https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281586.html),
to resolve the the unholy ABI-relationship between libavdevice and
libavformat and allow easier working on the part of the avdevice API
that lives in avformat, lock avdevice to a specific major and minor
version of avformat.

Signed-off-by: Diederick Niehorster 
---
 libavdevice/avdevice.c | 10 ++
 libavdevice/version.h  | 10 ++
 libavformat/utils.c|  5 +
 libavformat/version.h  | 11 +++
 libavutil/macros.h |  2 ++
 5 files changed, 38 insertions(+)

diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
index 8f460c7564..b608ec532f 100644
--- a/libavdevice/avdevice.c
+++ b/libavdevice/avdevice.c
@@ -38,6 +38,16 @@ unsigned avdevice_version(void)
 return LIBAVDEVICE_VERSION_INT;
 }
 
+unsigned avdevice_version_same_minor()
+{
+// check version of loaded lavf has same major and minor version as
+// this library was compiled against
+if ((avformat_version_same_minor()) & ~0xFF != (LIBAVFORMAT_VERSION_INT & 
~0xFF))
+abort();
+
+return avformat_version();
+}
+
 const char * avdevice_configuration(void)
 {
 return FFMPEG_CONFIGURATION;
diff --git a/libavdevice/version.h b/libavdevice/version.h
index 41f568d6b0..4c511a7f53 100644
--- a/libavdevice/version.h
+++ b/libavdevice/version.h
@@ -26,6 +26,7 @@
  */
 
 #include "libavutil/version.h"
+#include "libavutil/macros.h"
 
 #define LIBAVDEVICE_VERSION_MAJOR  59
 #define LIBAVDEVICE_VERSION_MINOR   1
@@ -48,4 +49,13 @@
  */
 #define FF_API_DEVICE_CAPABILITIES (LIBAVDEVICE_VERSION_MAJOR < 60)
 
+/**
+ * avdevice_version_same_minor() expands to a function with
+ * the same minor and major version it was compiled against
+ * encoded in it. Enables linking locking to the minor version
+ * of other libraries they were compiled against.
+ */
+#define avdevice_version_same_minor 
AV_MAKE_MAJOR_MINOR_FUNC_NAME(device,LIBAVFORMAT_VERSION_MAJOR,LIBAVFORMAT_VERSION_MINOR)
+unsigned avdevice_version_same_minor();
+
 #endif /* AVDEVICE_VERSION_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 332ba534d2..607a777c3f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -63,6 +63,11 @@ unsigned avformat_version(void)
 return LIBAVFORMAT_VERSION_INT;
 }
 
+unsigned avformat_version_same_minor()
+{
+return avformat_version();
+}
+
 const char *avformat_configuration(void)
 {
 return FFMPEG_CONFIGURATION;
diff --git a/libavformat/version.h b/libavformat/version.h
index 379a68cc7c..2423800687 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -28,6 +28,7 @@
  */
 
 #include "libavutil/version.h"
+#include "libavutil/macros.h"
 
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
@@ -63,4 +64,14 @@
 
 
 #define FF_API_R_FRAME_RATE1
+
+/**
+ * avformat_version_same_minor() expands to a function with
+ * the same minor and major version it was compiled against
+ * encoded in it. Enables linking locking to the minor version
+ * of other libraries they were compiled against. 
+ */
+#define avformat_version_same_minor 
AV_MAKE_MAJOR_MINOR_FUNC_NAME(format,LIBAVFORMAT_VERSION_MAJOR,LIBAVFORMAT_VERSION_MINOR)
+unsigned avformat_version_same_minor();
+
 #endif /* AVFORMAT_VERSION_H */
diff --git a/libavutil/macros.h b/libavutil/macros.h
index 2a7567c3ea..dda1bf6452 100644
--- a/libavutil/macros.h
+++ b/libavutil/macros.h
@@ -73,6 +73,8 @@
  * @}
  */
 
+#define AV_MAKE_MAJOR_MINOR_FUNC_NAME(name,major,minor) 
AV_GLUE(av,name)AV_GLUE(_version_,major)AV_GLUE(_,minor)
+
 #define AV_PRAGMA(s) _Pragma(#s)
 
 #define FFALIGN(x, a) (((x)+(a)-1)&~((a)-1))
-- 
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".

Re: [FFmpeg-devel] [PATCH v3] avformat/mov: add option max_stts_delta

[zhilizhao(赵志立)]

> On Dec 27, 2021, at 12:00 AM, Gyan Doshi  wrote:
> 
> Very high stts sample deltas may occasionally be intended but usually
> they are written in error or used to store a negative value for dts correction
> when treated as signed 32-bit integers.
> 
> This option lets the user set an upper limit, beyond which the delta is 
> clamped to 1.
> Values greater than the limit if negative when cast to int32 are used to 
> adjust onward dts.
> 
> Unit is the track time scale. Default is UINT_MAX - 48000*10 which
> allows upto a 10 second dts correction for 48 kHz audio streams while
> accommodating 99.9% of uint32 range.
> ---
> v3 changes:
> 
> factored out loop
> simplified correction logic
> added doc
> 
> doc/demuxers.texi  |  9 
> libavformat/isom.h |  1 +
> libavformat/mov.c  | 55 +-
> 3 files changed, 40 insertions(+), 25 deletions(-)
> 
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index cab8a7072c..99d4ab7bc5 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -713,6 +713,15 @@ specify.
> 
> @item decryption_key
> 16-byte key, in hex, to decrypt files encrypted using ISO Common Encryption 
> (CENC/AES-128 CTR; ISO/IEC 23001-7).
> +
> +@item max_stts_delta
> +Very high sample deltas written in a trak's stts box may occasionally be 
> intended but usually they are written in
> +error or used to store a negative value for dts correction when treated as 
> signed 32-bit integers. This option lets
> +the user set an upper limit, beyond which the delta is clamped to 1. Values 
> greater than the limit if negative when
> +cast to int32 are used to adjust onward dts.
> +
> +Unit is the track time scale. Range is 0 to UINT_MAX. Default is 
> @code{UINT_MAX - 48000*10} which allows upto
> +a 10 second dts correction for 48 kHz audio streams while accommodating 
> 99.9% of @code{uint32} range.
> @end table
> 
> @subsection Audible AAX
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index ef8f19b18c..625dea8421 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -305,6 +305,7 @@ typedef struct MOVContext {
> int32_t movie_display_matrix[3][3]; ///< display matrix from mvhd
> int have_read_mfra_size;
> uint32_t mfra_size;
> +uint32_t max_stts_delta;
> } MOVContext;
> 
> int ff_mp4_read_descr_len(AVIOContext *pb);
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2aed6e80ef..f93c8bef31 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2925,6 +2925,8 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
> unsigned int i, entries, alloc_size = 0;
> int64_t duration = 0;
> int64_t total_sample_count = 0;
> +int64_t current_dts = 0;
> +int64_t corrected_dts = 0;
> 
> if (c->fc->nb_streams < 1)
> return 0;
> @@ -2965,11 +2967,34 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
> sc->stts_data[i].count= sample_count;
> sc->stts_data[i].duration= sample_duration;
> 
> -av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n",
> +av_log(c->fc, AV_LOG_TRACE, "sample_count=%u, sample_duration=%u\n",
> sample_count, sample_duration);
> 
> -duration+=(int64_t)sample_duration*(uint64_t)sample_count;
> -total_sample_count+=sample_count;
> +/* STTS sample offsets are uint32 but some files store it as int32
> + * with negative values used to correct DTS delays.
> +   There may be abnormally large values as well. */
> +if (sample_duration > c->max_stts_delta) {
> +// assume high delta is a correction if negative when cast as 
> int32
> +int32_t delta_magnitude = (int32_t)sample_duration;
> +av_log(c->fc, AV_LOG_WARNING, "Too large sample offset %u in 
> stts entry %u with count %u in st:%d. Clipping to 1.\n",
> +   sample_duration, i, sample_count, st->index);
> +sc->stts_data[i].duration = 1;
> +corrected_dts += (delta_magnitude < 0 ? (int64_t)delta_magnitude 
> : 1) * sample_count;
> +} else {
> +corrected_dts += sample_duration * sample_count;
> +}
> +
> +current_dts += sc->stts_data[i].duration * sample_count;
> +
> +if (current_dts > corrected_dts) {
> +int64_t drift = (current_dts - corrected_dts)/sample_count;
> +uint32_t correction = (sc->stts_data[i].duration > drift) ? 
> drift : sc->stts_data[i].duration - 1;
> +current_dts -= correction * sample_count;
> +sc->stts_data[i].duration -= correction;
> +}
> +
> +
> duration+=(int64_t)sc->stts_data[i].duration*(uint64_t)sc->stts_data[i].count;

The second cast doesn’t help much.

> +total_sample_count+=sc->stts_data[i].count;
> }
> 
> sc->stts_count = i;
> @@ -3856,13 +3881,10 @@ static void mov_build_index(MOVContext *mov, AVStream 
> *st)
> unsigne

Re: [FFmpeg-devel] GitHub Integration

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Lynne
> Sent: Sunday, December 26, 2021 5:49 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] GitHub Integration
> 
> 26 Dec 2021, 02:03 by l...@chinaffmpeg.org:
> 
> >
> >
> >> 在 2021年12月26日，上午8:55，lance.lmw...@gmail.com 写道：
> >>
> >> On Sat, Dec 25, 2021 at 05:15:19PM +, Soft Works wrote:
> >>
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On Behalf Of Lynne
>  Sent: Saturday, December 25, 2021 5:50 PM
>  To: FFmpeg development discussions and patches 
>  Subject: Re: [FFmpeg-devel] GitHub Integration
> 
>  23 Dec 2021, 00:24 by softwo...@hotmail.com:
> 
> > Hi,
> >
> > holidays are approaching and I got a little present for all of you
> > even though it won’t be something for everybody.
> >
> > A while ago I had committed to prepare a test setup for integrating
> > GitHub in a similar way as the Git developers are doing.
> >
> > For those who missed it or don’t remember the outcome:
> > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html
> > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html
> >
> > Before someone’s temperature might start rising, I want to repeat
> > some important corner points:
> >
> > - it's not a migration nor the start of a migration
> > - nothing changes, it doesn't affect anybody's way of working
> > it doesn't replace anything
> > - it's an add-on that one could use or not
> >
> > Basic functionality is that it allows to submit patches to the ML
> > through GitHub pull requests.
> >
> > Right now must features are working, but e-mails are not sent to
> > the ML yet, just to one's own e-mail address.
> >
> >
> > I don't want to post the repository location publicly at this time,
> > but for anybody who would be interested in taking a look at this,
> > please send me an e-mail or PM me on IRC.
> >
> 
>  I'd rather we move away from ML development altogether.
>  There's general consensus already, and of course one or
>  two who'd rather not.
> 
> >>>
> >>> I'd prefer that as well, but in back in summer there were quite a number
> >>> of developers (> 2) indicating that they are fine with the
> >>> ML approach, so I'm not really sure about whether and when this
> >>> will happen eventually.
> >>>
> >>> This GitHub-PR-Bridge is not meant to be an alternative or replacement
> >>> for an eventual full migration to another platform.
> >>>
> >>> It's just an interim solution until a migration will eventually happen
> >>> (probably like in the 2030ies.. ;-)
> >>>
> >>
> >> My point:
> >> 1, In China network environment, when accessing Github, the network will
> be
> >> blocked or very slow.
> >> 2, For gmail is blocked, so I prefer to use cli, remote ssh to a cloud
> host,
> >> use mutt/vim for ML email, and scp, and git cli tools are professional to
> do
> >> everything for the patchset send, push etc. Yes, I can use socket5 to
> forward,
> >> but I like cli instead of web for I prefer to use keyboard instead of
> mouse.
> >>
> >
> > +1
> >
> 
> We'd never move to Github, that much's for sure. Videolan already
> hosts a Gitlab instance, and I doubt the great firewall would have an
> issue with that.

I'm not sure. My interpretation of Lance' and Steven's comments would
be that they'd prefer to stick to the ML.

sw
___
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] GitHub Integration

[Ronald S. Bultje]

Hi,

On Sun, Dec 26, 2021 at 3:21 PM Soft Works  wrote:

> I'm not sure. My interpretation of Lance' and Steven's comments would
> be that they'd prefer to stick to the ML.
>

No, it's not strictly related to that - they want something that is CLI
accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/
and github has this here: https://github.com/cli/cli - the next question is
whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or
whether the instances are self-hosted (github: no, gitlab-videolan: yes).

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

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

Re: [FFmpeg-devel] GitHub Integration

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Ronald S.
> Bultje
> Sent: Sunday, December 26, 2021 10:38 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] GitHub Integration
> 
> Hi,
> 
> On Sun, Dec 26, 2021 at 3:21 PM Soft Works  wrote:
> 
> > I'm not sure. My interpretation of Lance' and Steven's comments would
> > be that they'd prefer to stick to the ML.
> >
> 
> No, it's not strictly related to that - they want something that is CLI
> accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/
> and github has this here: https://github.com/cli/cli - the next question is
> whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or
> whether the instances are self-hosted (github: no, gitlab-videolan: yes).

Agreed. For the submission part, there are CLI options in both cases.
Also true for both cases: the discussion part would change to WWW.

But I'm probably the very last one here to advocate staying with the ML.
Even though I'd prefer GitHub, I would welcome a move to GitLab as well,
and when something like GitGitGadget would have existed for GitLab instead
of GitHub, then I would have adopted that instead.

Looking back at the discussion in August, where I made these suggestions,
a lot of developers had responded, indicating their satisfaction with the
ML approach (some even defending it strongly). Just very few indicated
support for a move to either GitHub or GitLab.

Off-list, I've seen some who were claiming that a majority would exist,
favoring a move to GitLab. That would be great, but I'm not seeing it.
Where is that majority and why do so few of them speak up, then?

After reading the ML for several years, and from what I've learned about
the group interaction dynamics, my assessment is, that a migration
away from the ML is unlikely to happen in a short-term future.
Those who don't want to move are just on standby, waiting for the next
attempt to be made in order to turn it down once again, and those who
would like to move, are sufficiently satisfied by the thought
alone that a move to GitLab would happen "soon". 
Most likely, by the end of 2022, the situation will just be the same.

On the other side, the "GitHub Gateway/Integration" with the 
ffmpeg-codebot is available right now and able to bridge
the gap between ML and more modern and integrated development workflows.
It's not meant to replace, avoid or compete with an actual migration,
and when a migration would happen e.g. to GitLab, it will be still useful
to have a bot on GitHub that either mirrors PRs from GitHub or just 
auto-closes them with an appropriate message.

Somebody said on IRC that the GH integration might only delay a real 
migration away from the ML.
But I'm seeing it somewhat differently: this might rather serve as an 
indication for which approach will be preferred by the majority, maybe
even accelerating a final migration.

Kind regards,
softworkz








___
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 v3] avformat/mov: add option max_stts_delta

[Michael Niedermayer]

On Sun, Dec 26, 2021 at 09:30:44PM +0530, Gyan Doshi wrote:
> Very high stts sample deltas may occasionally be intended but usually
> they are written in error or used to store a negative value for dts correction
> when treated as signed 32-bit integers.
> 
> This option lets the user set an upper limit, beyond which the delta is 
> clamped to 1.
> Values greater than the limit if negative when cast to int32 are used to 
> adjust onward dts.
> 
> Unit is the track time scale. Default is UINT_MAX - 48000*10 which
> allows upto a 10 second dts correction for 48 kHz audio streams while
> accommodating 99.9% of uint32 range.
> ---
> v3 changes:
> 
> factored out loop

> simplified correction logic

this looks more sane now
i guess this cannot be easily split into a seperate patch ?


[...]
> @@ -2965,11 +2967,34 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  sc->stts_data[i].count= sample_count;
>  sc->stts_data[i].duration= sample_duration;
>  
> -av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n",
> +av_log(c->fc, AV_LOG_TRACE, "sample_count=%u, sample_duration=%u\n",
>  sample_count, sample_duration);
>  
> -duration+=(int64_t)sample_duration*(uint64_t)sample_count;
> -total_sample_count+=sample_count;
> +/* STTS sample offsets are uint32 but some files store it as int32
> + * with negative values used to correct DTS delays.
> +   There may be abnormally large values as well. */
> +if (sample_duration > c->max_stts_delta) {
> +// assume high delta is a correction if negative when cast as 
> int32
> +int32_t delta_magnitude = (int32_t)sample_duration;
> +av_log(c->fc, AV_LOG_WARNING, "Too large sample offset %u in 
> stts entry %u with count %u in st:%d. Clipping to 1.\n",
> +   sample_duration, i, sample_count, st->index);
> +sc->stts_data[i].duration = 1;
> +corrected_dts += (delta_magnitude < 0 ? (int64_t)delta_magnitude 
> : 1) * sample_count;
> +} else {
> +corrected_dts += sample_duration * sample_count;
> +}
> +
> +current_dts += sc->stts_data[i].duration * sample_count;
> +
> +if (current_dts > corrected_dts) {
> +int64_t drift = (current_dts - corrected_dts)/sample_count;

division by 0


thx

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

It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: fix DNxHD GC container_ul

[Marton Balint]

On Thu, 16 Dec 2021, Tomas Härdin wrote:


tis 2021-12-14 klockan 16:27 +0100 skrev Nicolas Gaullier:

Signed-off-by: Nicolas Gaullier 
---
 libavformat/mxfenc.c  | 2 +-
 tests/ref/lavf/mxf_opatom | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index fcd9afda2a..512baa45d3 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -181,7 +181,7 @@ static const MXFContainerEssenceEntry
mxf_essence_container_uls[] = {
   {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x00
,0x00,0x00 },
   mxf_write_cdci_desc },
 // DNxHD
-    { {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11
,0x01,0x00 },
+    { {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x0D,0x01,0x03,0x01,0x02,0x11
,0x01,0x00 },
   {
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01
,0x05,0x00 },
   {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x01
,0x00,0x00 },
   mxf_write_cdci_desc },
diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
index 61e70b..b818f26c36 100644
--- a/tests/ref/lavf/mxf_opatom
+++ b/tests/ref/lavf/mxf_opatom
@@ -1,3 +1,3 @@
-5d235c127ace64b1f4fe6c79a7ca8be6 *tests/data/lavf/lavf.mxf_opatom
+e558e50a94d88762e07ab8149aced7b9 *tests/data/lavf/lavf.mxf_opatom
 4717625 tests/data/lavf/lavf.mxf_opatom
 tests/data/lavf/lavf.mxf_opatom CRC=0xf55aa22a


Should be fine based on previous discussion


Applied the series.

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

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

[FFmpeg-devel] [PATCH 1/5] avformat/aviobuf: set AVIOContext->error on bprint buffer ENOMEM

[Marton Balint]

This makes sure the error condition is kept in AVIOContext even if the user
does not check the return value of avio_read_to_bprint or
ff_read_line_to_bprint.

Signed-off-by: Marton Balint 
---
 libavformat/aviobuf.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 29d4bd7510..6f8a822ee3 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -875,8 +875,10 @@ static int64_t read_string_to_bprint_overwrite(AVIOContext 
*s, AVBPrint *bp,
 if (ret < 0)
 return ret;
 
-if (!av_bprint_is_complete(bp))
+if (!av_bprint_is_complete(bp)) {
+s->error = AVERROR(ENOMEM);
 return AVERROR(ENOMEM);
+}
 
 return bp->len;
 }
@@ -1351,8 +1353,10 @@ int avio_read_to_bprint(AVIOContext *h, AVBPrint *pb, 
size_t max_size)
 if (ret <= 0)
 return ret;
 av_bprint_append_data(pb, buf, ret);
-if (!av_bprint_is_complete(pb))
+if (!av_bprint_is_complete(pb)) {
+h->error = AVERROR(ENOMEM);
 return AVERROR(ENOMEM);
+}
 max_size -= ret;
 }
 return 0;
-- 
2.31.1

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

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

[FFmpeg-devel] [PATCH 2/5] avformat/movenc: factorize data shifting

[Marton Balint]

And move data shift function from movenc to utils.

Signed-off-by: Marton Balint 
---
 libavformat/internal.h |  7 ++
 libavformat/movenc.c   | 55 ++---
 libavformat/utils.c| 56 ++
 3 files changed, 65 insertions(+), 53 deletions(-)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index 2ba795d669..63235ce5cf 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -1019,4 +1019,11 @@ void ff_format_set_url(AVFormatContext *s, char *url);
 
 void avpriv_register_devices(const AVOutputFormat * const o[], const 
AVInputFormat * const i[]);
 
+/**
+ * Make shift_size amount of space at read_start by shifting data in the output
+ * at read_start until the current IO position. The underlying IO context must
+ * be seekable.
+ */
+int ff_format_shift_data(AVFormatContext *s, int64_t read_start, int 
shift_size);
+
 #endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 0f912dd012..40ad4f8642 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7150,13 +7150,8 @@ static int compute_sidx_size(AVFormatContext *s)
 
 static int shift_data(AVFormatContext *s)
 {
-int ret = 0, moov_size;
+int moov_size;
 MOVMuxContext *mov = s->priv_data;
-int64_t pos, pos_end;
-uint8_t *buf, *read_buf[2];
-int read_buf_id = 0;
-int read_size[2];
-AVIOContext *read_pb;
 
 if (mov->flags & FF_MOV_FLAG_FRAGMENT)
 moov_size = compute_sidx_size(s);
@@ -7165,53 +7160,7 @@ static int shift_data(AVFormatContext *s)
 if (moov_size < 0)
 return moov_size;
 
-buf = av_malloc(moov_size * 2);
-if (!buf)
-return AVERROR(ENOMEM);
-read_buf[0] = buf;
-read_buf[1] = buf + moov_size;
-
-/* Shift the data: the AVIO context of the output can only be used for
- * writing, so we re-open the same output, but for reading. It also avoids
- * a read/seek/write/seek back and forth. */
-avio_flush(s->pb);
-ret = s->io_open(s, &read_pb, s->url, AVIO_FLAG_READ, NULL);
-if (ret < 0) {
-av_log(s, AV_LOG_ERROR, "Unable to re-open %s output file for "
-   "the second pass (faststart)\n", s->url);
-goto end;
-}
-
-/* mark the end of the shift to up to the last data we wrote, and get ready
- * for writing */
-pos_end = avio_tell(s->pb);
-avio_seek(s->pb, mov->reserved_header_pos + moov_size, SEEK_SET);
-
-/* start reading at where the new moov will be placed */
-avio_seek(read_pb, mov->reserved_header_pos, SEEK_SET);
-pos = avio_tell(read_pb);
-
-#define READ_BLOCK do {
 \
-read_size[read_buf_id] = avio_read(read_pb, read_buf[read_buf_id], 
moov_size);  \
-read_buf_id ^= 1;  
 \
-} while (0)
-
-/* shift data by chunk of at most moov_size */
-READ_BLOCK;
-do {
-int n;
-READ_BLOCK;
-n = read_size[read_buf_id];
-if (n <= 0)
-break;
-avio_write(s->pb, read_buf[read_buf_id], n);
-pos += n;
-} while (pos < pos_end);
-ff_format_io_close(s, &read_pb);
-
-end:
-av_free(buf);
-return ret;
+return ff_format_shift_data(s, mov->reserved_header_pos, moov_size);
 }
 
 static int mov_write_trailer(AVFormatContext *s)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 332ba534d2..a78797ef57 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2035,3 +2035,59 @@ const char *av_disposition_to_string(int disposition)
 
 return NULL;
 }
+
+int ff_format_shift_data(AVFormatContext *s, int64_t read_start, int 
shift_size)
+{
+int ret;
+int64_t pos, pos_end;
+uint8_t *buf, *read_buf[2];
+int read_buf_id = 0;
+int read_size[2];
+AVIOContext *read_pb;
+
+buf = av_malloc_array(shift_size, 2);
+if (!buf)
+return AVERROR(ENOMEM);
+read_buf[0] = buf;
+read_buf[1] = buf + shift_size;
+
+/* Shift the data: the AVIO context of the output can only be used for
+ * writing, so we re-open the same output, but for reading. It also avoids
+ * a read/seek/write/seek back and forth. */
+avio_flush(s->pb);
+ret = s->io_open(s, &read_pb, s->url, AVIO_FLAG_READ, NULL);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Unable to re-open %s output file for shifting 
data\n", s->url);
+goto end;
+}
+
+/* mark the end of the shift to up to the last data we wrote, and get ready
+ * for writing */
+pos_end = avio_tell(s->pb);
+avio_seek(s->pb, read_start + shift_size, SEEK_SET);
+
+avio_seek(read_pb, read_start, SEEK_SET);
+pos = avio_tell(read_pb);
+
+#define READ_BLOCK do {
 \
+read_size[read_buf_id] = avio_read(read_pb, read_buf[read_buf_id], 
shift_size);  \
+read_buf_id ^= 1;   

[FFmpeg-devel] [PATCH 3/5] avformat/flvenc: use ff_format_shift_data for data shifting

[Marton Balint]

add_keyframe_index seems to generate a corrupted index even before this change.

Signed-off-by: Marton Balint 
---
 libavformat/flvenc.c | 59 +---
 1 file changed, 6 insertions(+), 53 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 5130d429ad..31d1d93c23 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -576,15 +576,9 @@ static int flv_append_keyframe_info(AVFormatContext *s, 
FLVContext *flv, double
 
 static int shift_data(AVFormatContext *s)
 {
-int ret = 0;
-int n = 0;
+int ret;
 int64_t metadata_size = 0;
 FLVContext *flv = s->priv_data;
-int64_t pos, pos_end = avio_tell(s->pb); /* Save the pre-shift size. */
-uint8_t *buf, *read_buf[2];
-int read_buf_id = 0;
-int read_size[2];
-AVIOContext *read_pb;
 
 metadata_size = flv->filepositions_count * 9 * 2 + 10; /* filepositions 
and times value */
 metadata_size += 2 + 13; /* filepositions String */
@@ -596,58 +590,17 @@ static int shift_data(AVFormatContext *s)
 if (metadata_size < 0)
 return metadata_size;
 
-buf = av_malloc_array(metadata_size, 2);
-if (!buf) {
-return AVERROR(ENOMEM);
-}
-read_buf[0] = buf;
-read_buf[1] = buf + metadata_size;
+ret = ff_format_shift_data(s, flv->keyframes_info_offset, metadata_size);
+if (ret < 0)
+return ret;
 
 avio_seek(s->pb, flv->metadata_size_pos, SEEK_SET);
 avio_wb24(s->pb, flv->metadata_totalsize + metadata_size);
 
-avio_seek(s->pb, flv->metadata_totalsize_pos, SEEK_SET);
+avio_seek(s->pb, flv->metadata_totalsize_pos + metadata_size, SEEK_SET);
 avio_wb32(s->pb, flv->metadata_totalsize + 11 + metadata_size);
 
-/* Shift the data: the AVIO context of the output can only be used for
- * writing, so we re-open the same output, but for reading. It also avoids
- * a read/seek/write/seek back and forth. */
-avio_flush(s->pb);
-ret = s->io_open(s, &read_pb, s->url, AVIO_FLAG_READ, NULL);
-if (ret < 0) {
-av_log(s, AV_LOG_ERROR, "Unable to re-open %s output file for "
-   "the second pass (add_keyframe_index)\n", s->url);
-goto end;
-}
-
-/* Get ready for writing. */
-avio_seek(s->pb, flv->keyframes_info_offset + metadata_size, SEEK_SET);
-
-/* start reading at where the keyframe index information will be placed */
-avio_seek(read_pb, flv->keyframes_info_offset, SEEK_SET);
-pos = avio_tell(read_pb);
-
-#define READ_BLOCK do {
 \
-read_size[read_buf_id] = avio_read(read_pb, read_buf[read_buf_id], 
metadata_size);  \
-read_buf_id ^= 1;  
 \
-} while (0)
-
-/* shift data by chunk of at most keyframe *filepositions* and *times* 
size */
-READ_BLOCK;
-do {
-READ_BLOCK;
-n = read_size[read_buf_id];
-if (n < 0)
-break;
-avio_write(s->pb, read_buf[read_buf_id], n);
-pos += n;
-} while (pos <= pos_end);
-
-ff_format_io_close(s, &read_pb);
-
-end:
-av_free(buf);
-return ret;
+return 0;
 }
 
 static int flv_init(struct AVFormatContext *s)
-- 
2.31.1

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

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

[FFmpeg-devel] [PATCH 4/5] avformat/segafilmenc: use ff_format_shift_data for shifting

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/segafilmenc.c | 51 ---
 1 file changed, 5 insertions(+), 46 deletions(-)

diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index ff8cb66aca..737805faa6 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -170,54 +170,13 @@ static int film_init(AVFormatContext *format_context)
 static int write_header(AVFormatContext *format_context, uint8_t *header,
 unsigned header_size)
 {
-int ret = 0;
-int64_t pos, pos_end;
-uint8_t *buf, *read_buf[2];
-int read_buf_id = 0;
-int read_size[2];
-AVIOContext *read_pb;
-
-buf = av_malloc(header_size);
-if (!buf)
-return AVERROR(ENOMEM);
-read_buf[0] = buf;
-read_buf[1]  = header;
-read_size[1] = header_size;
-
-/* Write the header at the beginning of the file, shifting all content as 
necessary;
- * based on the approach used by MOV faststart. */
-avio_flush(format_context->pb);
-ret = format_context->io_open(format_context, &read_pb, 
format_context->url, AVIO_FLAG_READ, NULL);
-if (ret < 0) {
-av_log(format_context, AV_LOG_ERROR, "Unable to re-open %s output file 
to "
-   "write the header\n", format_context->url);
-av_free(buf);
+int ret = ff_format_shift_data(format_context, 0, header_size);
+if (ret < 0)
 return ret;
-}
 
-/* Mark the end of the shift to up to the last data we are going to write,
- * and get ready for writing */
-pos_end = avio_tell(format_context->pb) + header_size;
-pos = avio_seek(format_context->pb, 0, SEEK_SET);
-
-/* start reading at where the new header will be placed */
-avio_seek(read_pb, 0, SEEK_SET);
-
-/* shift data by chunk of at most header_size */
-do {
-int n;
-read_size[read_buf_id] = avio_read(read_pb, read_buf[read_buf_id],
-   header_size);
-read_buf_id ^= 1;
-n = read_size[read_buf_id];
-if (n <= 0)
-break;
-avio_write(format_context->pb, read_buf[read_buf_id], n);
-pos += n;
-} while (pos < pos_end);
-ff_format_io_close(format_context, &read_pb);
-
-av_free(buf);
+avio_seek(format_context->pb, 0, SEEK_SET);
+avio_write(format_context->pb, header, header_size);
+
 return 0;
 }
 
-- 
2.31.1

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

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

[FFmpeg-devel] [PATCH 5/5] avformat/utils: propagate return value of ff_format_io_close in ff_format_shift_data

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index a78797ef57..23e81bda9d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2085,7 +2085,7 @@ int ff_format_shift_data(AVFormatContext *s, int64_t 
read_start, int shift_size)
 avio_write(s->pb, read_buf[read_buf_id], n);
 pos += n;
 } while (pos < pos_end);
-ff_format_io_close(s, &read_pb);
+ret = ff_format_io_close(s, &read_pb);
 
 end:
 av_free(buf);
-- 
2.31.1

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

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

[FFmpeg-devel] [PATCH v15 1/2] avformat/imf: Demuxer

[pal]

From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
The IMF demuxer accepts as input an IMF CPL. The assets referenced by the 
CPL can be
contained in multiple deliveries, each defined by an ASSETMAP file:

ffmpeg -assetmaps ,,... -i 

If -assetmaps is not specified, FFMPEG looks for a file called ASSETMAP.xml 
in the same directory as the CPL.

EXAMPLE:
ffmpeg -i 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
 out.mp4

The Interoperable Master Format (IMF) is a file-based media format for the
delivery and storage of professional audio-visual masters.
An IMF Composition consists of an XML playlist (the Composition Playlist)
and a collection of MXF files (the Track Files). The Composition Playlist 
(CPL)
assembles the Track Files onto a timeline, which consists of multiple 
tracks.
The location of the Track Files referenced by the Composition Playlist is 
stored
in one or more XML documents called Asset Maps. More details at 
https://www.imfug.com/explainer.
The IMF standard was first introduced in 2013 and is managed by the SMPTE.

CHANGE NOTES:

- improve code style

 MAINTAINERS  |   1 +
 configure|   3 +-
 doc/demuxers.texi|   6 +
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/imf.h| 207 +
 libavformat/imf_cpl.c| 841 
 libavformat/imfdec.c | 899 +++
 8 files changed, 1958 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/imf.h
 create mode 100644 libavformat/imf_cpl.c
 create mode 100644 libavformat/imfdec.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c065e94498..6312a1d12e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -433,6 +433,7 @@ Muxers/Demuxers:
   idroqdec.cMike Melanson
   iff.c Jaikrishnan Menon
   img2*.c   Michael Niedermayer
+  imf*.cMarc-Antoine Arnaud, Pierre-Anthony 
Lemieux, Valentin Noël
   ipmovie.c Mike Melanson
   ircam*Paul B Mahol
   iss.c Stefan Gehrer
diff --git a/configure b/configure
index 23ef2abc9b..07fb7925d8 100755
--- a/configure
+++ b/configure
@@ -298,7 +298,7 @@ External library support:
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
   --enable-libxml2 enable XML parsing using the C library libxml2, 
needed
-   for dash demuxing support [no]
+   for dash and imf demuxing support [no]
   --enable-libzimg enable z.lib, needed for zscale filter [no]
   --enable-libzmq  enable message passing via libzmq [no]
   --enable-libzvbi enable teletext support via libzvbi [no]
@@ -3415,6 +3415,7 @@ hls_muxer_select="mpegts_muxer"
 hls_muxer_suggest="gcrypt openssl"
 image2_alias_pix_demuxer_select="image2_demuxer"
 image2_brender_pix_demuxer_select="image2_demuxer"
+imf_demuxer_deps="libxml2"
 ipod_muxer_select="mov_muxer"
 ismv_muxer_select="mov_muxer"
 ivf_muxer_select="av1_metadata_bsf vp9_superframe_bsf"
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index cab8a7072c..655704d2c4 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -267,6 +267,12 @@ which streams to actually receive.
 Each stream mirrors the @code{id} and @code{bandwidth} properties from the
 @code{} as metadata keys named "id" and "variant_bitrate" 
respectively.
 
+@section imf
+
+Interoperable Master Format demuxer.
+
+This demuxer presents audio and video streams found in an IMF Composition.
+
 @section flv, live_flv, kux
 
 Adobe Flash Video Format demuxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2b5caf9d33..7f058f3ea0 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -285,6 +285,7 @@ OBJS-$(CONFIG_IMAGE_WEBP_PIPE_DEMUXER)+= img2dec.o 
img2.o
 OBJS-$(CONFIG_IMAGE_XBM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_XPM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_XWD_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMF_DEMUXER)   += imfdec.o imf_cpl.o
 OBJS-$(CONFIG_INGENIENT_DEMUXER) += ingenientdec.o rawdec.o
 OBJS-$(CONFIG_IPMOVIE_DEMUXER)   += ipmovie.o
 OBJS-$(CONFIG_IPU_DEMUXER)   += ipudec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 1054ac9667..f680616cdd 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -212,6 +212,7 @@ extern const AVInputFormat  ff_image2pipe_demuxer;
 extern const AVOutputFormat ff_image2pipe_muxer;
 extern const AVInputFormat  ff_image2_alias_pix_demuxer;
 extern c

[FFmpeg-devel] [PATCH v15 2/2] avformat/imf: Tests

[pal]

From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
Tests for the IMF demuxer.

 libavformat/Makefile   |   1 +
 libavformat/tests/imf.c| 526 +
 tests/fate/libavformat.mak |   4 +
 tests/ref/fate/imf |  54 
 4 files changed, 585 insertions(+)
 create mode 100644 libavformat/tests/imf.c
 create mode 100644 tests/ref/fate/imf

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 7f058f3ea0..533bb67f31 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -697,6 +697,7 @@ TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
 TESTPROGS-$(CONFIG_MOV_MUXER)+= movenc
 TESTPROGS-$(CONFIG_NETWORK)  += noproxy
 TESTPROGS-$(CONFIG_SRTP) += srtp
+TESTPROGS-$(CONFIG_IMF_DEMUXER)  += imf
 
 TOOLS = aviocat \
 ismindex\
diff --git a/libavformat/tests/imf.c b/libavformat/tests/imf.c
new file mode 100644
index 00..68e4c8b6af
--- /dev/null
+++ b/libavformat/tests/imf.c
@@ -0,0 +1,526 @@
+/*
+ * 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
+ */
+
+/*
+ *
+ * Copyright (c) Sandflow Consulting LLC
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * * Redistributions of source code must retain the above copyright notice, 
this
+ *   list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright notice,
+ *   this list of conditions and the following disclaimer in the documentation
+ *   and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/**
+ * Tests for IMF CPL and ASSETMAP processing
+ *
+ * @author Valentin Noel
+ * @author Pierre-Anthony Lemieux
+ * @file
+ * @ingroup lavu_imf
+ */
+
+#include "libavformat/imf_cpl.c"
+#include "libavformat/imfdec.c"
+#include "libavformat/mxf.h"
+
+#include 
+
+const char *cpl_doc =
+"http://www.smpte-ra.org/schemas/2067-3/2016\"";
+" xmlns:cc=\"http://www.smpte-ra.org/schemas/2067-2/2016\"";
+" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\";>"
+"urn:uuid:8713c020-2489-45f5-a9f7-87be539e20b5"
+"2021-07-13T17:06:22Z"
+"FFMPEG"
+"FFMPEG sample content"
+""
+"  "
+"urn:uuid:8e097bb0-cff7-4969-a692-bad47bfb528f"
+"  "
+""
+"24000 1001"
+""
+""
+"urn:uuid:81fed4e5-9722-400a-b9d1-7f2bd21df4b6"
+""
+""
+"urn:uuid:16327185-9205-47ef-a17b-ee28df251db7"
+"urn:uuid:461f5424-8f6e-48a9-a385-5eda46fda381"
+""
+""
+"urn:uuid:ea3d0f23-55d6-4e03-86ec-cfe0666f0e6a"
+"24"
+""
+"LFOA"
+"5"
+""
+""
+""
+""
+""
+"urn:uuid:6ae100b0-92d1-41be-9321-85e0933dfc42"
+"urn:uuid:e8ef9653-565c-479c-8039-82d4547973c5"
+""
+""
+"urn:uuid:7d418acb-07a3-4e57-984c-b8ea2f7de4ec"
+"24"
+
"urn:uuid:f00e49a8-0dec-4e6c-95e7-078df988b751"
+"urn:uuid:6f768ca4-c89e-4dac-9056-a29425d40ba1"
+""
+""
+""
+""
+"urn:uuid:754dae53-c25f-4f3c-97e4-2bfe5463f83b"
+"urn:uuid:68e3fae5-d94b-44d2-92a6-b94877fbcdb5"
+""
+""
+"urn:uuid:61ce2a70-10a2-4521-850b-4218755ff3c9"
+"24"
+
"urn:uuid:f00e49a8-0dec-4e6c-95e7-078df988b751"
+"urn:uuid:381dadd2-061e-46cc-a63a-e3d58ce7f488"
+"

Re: [FFmpeg-devel] [PATCH v14 1/2] avformat/imf: Demuxer

[Pierre-Anthony Lemieux]

On Fri, Dec 24, 2021 at 4:08 PM Zane van Iperen  wrote:
>
> Looks mostly alright, just some style nits. Once they're fixed, lgtm.
>
> On Wednesday, 22 December 2021 4:42:08 AM AEST p...@sandflow.com wrote:
>
> > +
> > +int ff_imf_xml_read_uuid(xmlNodePtr element, uint8_t uuid[16])
> > +{
> > +xmlChar *element_text = NULL;
> > +int scanf_ret;
> > +int ret = 0;
> > +
> > +element_text = xmlNodeListGetString(element->doc, 
> > element->xmlChildrenNode, 1);
> > +scanf_ret = sscanf(element_text,
> > +   FF_IMF_UUID_FORMAT,
> > +   &uuid[0],
> > +   &uuid[1],
> > +   &uuid[2],
> > +   &uuid[3],
> > +   &uuid[4],
> > +   &uuid[5],
> > +   &uuid[6],
> > +   &uuid[7],
> > +   &uuid[8],
> > +   &uuid[9],
> > +   &uuid[10],
> > +   &uuid[11],
> > +   &uuid[12],
> > +   &uuid[13],
> > +   &uuid[14],
> > +   &uuid[15]);
>
> I'm not the biggest fan of this, but if you're doing the libuuid refactoring 
> afterwards, then I'm inclined
> to let it be.

Yes, I plan to tackle the libuuid refactoring afterwards.

>
> > +static int fill_base_resource(xmlNodePtr resource_elem, FFIMFBaseResource 
> > *resource, FFIMFCPL *cpl)
> > +{
> > +xmlNodePtr element = NULL;
> > +int ret = 0;
> > +
> > +/* read EditRate */
> > +if (!(element = ff_imf_xml_get_child_element_by_name(resource_elem, 
> > "EditRate"))) {
> > +resource->edit_rate = cpl->edit_rate;
> > +} else if (ret = ff_imf_xml_read_rational(element, 
> > &resource->edit_rate)) {
>
> When doing inline assignments, use an extra (), e.g.
> if ((ret = ff_imf_xml_read_rational(element, &resource->edit_rate)))

Addressed by v15.


>
> > +av_log(NULL, AV_LOG_ERROR, "Invalid EditRate element found in a 
> > Resource\n");
> > +return ret;
> > +}
> > +
> > +/* read EntryPoint */
> > +if (element = ff_imf_xml_get_child_element_by_name(resource_elem, 
> > "EntryPoint")) {
> > +if (ret = ff_imf_xml_read_uint32(element, &resource->entry_point)) 
> > {
>
> ()
>
> > +av_log(NULL, AV_LOG_ERROR, "Invalid EntryPoint element found 
> > in a Resource\n");
> > +return ret;
> > +}
> > +} else {
> > +resource->entry_point = 0;
> > +}
> > +
> > +/* read IntrinsicDuration */
> > +if (!(element = ff_imf_xml_get_child_element_by_name(resource_elem, 
> > "IntrinsicDuration"))) {
> > +av_log(NULL, AV_LOG_ERROR, "IntrinsicDuration element missing from 
> > Resource\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +if (ret = ff_imf_xml_read_uint32(element, &resource->duration)) {
>
> ()
>
> > +av_log(NULL, AV_LOG_ERROR, "Invalid IntrinsicDuration element 
> > found in a Resource\n");
> > +return ret;
> > +}
> > +resource->duration -= resource->entry_point;
> > +
> > +/* read SourceDuration */
> > +if (element = ff_imf_xml_get_child_element_by_name(resource_elem, 
> > "SourceDuration")) {
>
> ()
>
> > +if (ret = ff_imf_xml_read_uint32(element, &resource->duration)) {
>
> ()
>
> > +av_log(NULL, AV_LOG_ERROR, "SourceDuration element missing 
> > from Resource\n");
> > +return ret;
> > +}
> > +}
> > +
> > +/* read RepeatCount */
> > +if (element = ff_imf_xml_get_child_element_by_name(resource_elem, 
> > "RepeatCount"))
>
> ()
>
> > +ret = ff_imf_xml_read_uint32(element, &resource->repeat_count);
> > +
> > +return ret;
> > +}
> > +
> > +static int fill_trackfile_resource(xmlNodePtr tf_resource_elem,
> > +   FFIMFTrackFileResource *tf_resource,
> > +   FFIMFCPL *cpl)
> > +{
> > +xmlNodePtr element = NULL;
> > +int ret = 0;
> > +
> > +if (ret = fill_base_resource(tf_resource_elem, (FFIMFBaseResource 
> > *)tf_resource, cpl))
>
> ()
>
> > +return ret;
> > +
> > +/* read TrackFileId */
> > +if (element = ff_imf_xml_get_child_element_by_name(tf_resource_elem, 
> > "TrackFileId")) {
> > +if (ret = ff_imf_xml_read_uuid(element, 
> > tf_resource->track_file_uuid)) {
>
> ()
>
> > +av_log(NULL, AV_LOG_ERROR, "Invalid TrackFileId element found 
> > in Resource\n");
> > +return ret;
> > +}
> > +} else {
> > +av_log(NULL, AV_LOG_ERROR, "TrackFileId element missing from 
> > Resource\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +return ret;
> > +}
> > +
> > +static int fill_marker_resource(xmlNodePtr marker_resource_elem,
> > +FFIMFMarkerResource *marker_resource,
> > +FFIMFCPL *cpl)
> > +{
> > +xmlNodePt

Re: [FFmpeg-devel] GitHub Integration

[lance . lmwang]

On Sun, Dec 26, 2021 at 04:37:54PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Dec 26, 2021 at 3:21 PM Soft Works  wrote:
> 
> > I'm not sure. My interpretation of Lance' and Steven's comments would
> > be that they'd prefer to stick to the ML.
> >
> 
> No, it's not strictly related to that - they want something that is CLI
> accessible. Gitlab has this here: https://glab.readthedocs.io/en/latest/
> and github has this here: https://github.com/cli/cli - the next question is
> whether the gitlab/hub hosts are blocked by a firewall (no idea) and/or
> whether the instances are self-hosted (github: no, gitlab-videolan: yes).

Yes, self-hosted is more preferable, I recall github has blocked devleopers
in some country by US trade controls. Who knows what's the rules will be
changed someday as it's controlled by company.

> 
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions

[Xiang, Haihao]

On Thu, 2021-12-23 at 14:01 +, Xiang, Haihao wrote:
> On Fri, 2021-11-26 at 19:29 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of Anton
> > > Khirnov
> > > Sent: Friday, November 26, 2021 8:12 PM
> > > To: FFmpeg development discussions and patches 
> > > Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When
> > > deriving
> > > a
> > > hwdevice, search for existing device in both directions
> > > 
> > > Quoting Soft Works (2021-11-26 19:43:58)
> > > > Maybe I'm missing something, but hw device contexts are refcounted.
> > > > What happens in hwdevice_ctx_free() is this:
> > > > 
> > > > av_buffer_unref(&ctx->internal->source_device);
> > > 
> > > IIUC this only happens after the parent device is freed. My concern is
> > > the following situation:
> > > - the caller creates a parent hwdevice
> > > - the caller derives a child from it, which may acquire some additional
> > >   resources beyond what the parent holds
> > > - the caller unrefs all his references to the child, but the child does
> > >   not get freed because the parent still holds a reference to it
> > > 
> > > Since av_hwdevice_ctx_create_derived() has a flags parameter, we might
> > > want to introduce a flag to control this behavior.
> > 
> > I understand what you mean. I'm just not sure whether a practical case
> > with such a requirement exists. Should that turn out to be required,
> > such flag can be added at any time, IMO.
> 
> 
> I agree we may add such flag later if required. May we merge this patch to fix
> the annoying derivation limitation if no other concern ? 

Any other comment for this patch version? I'll add the note pointed out by Lynne
and push this patch if no objection. 

Thanks
Haihao

___
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 V3 2/2] libavutil/hwcontext_opencl: fix a bug for mapping qsv frame to opencl

[Chen, Wenbin]

> On Fri, 2021-12-10 at 13:38 +0800, Wenbin Chen wrote:
> > From: nyanmisaka 
> >
> > mfxHDLPair was added to qsv, so modify qsv->opencl map function as well.
> > Now the following commandline works:
> >
> > ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 \
> > -init_hw_device qsv=qs@va -init_hw_device opencl=ocl@va -
> filter_hw_device ocl
> > \
> > -hwaccel qsv -hwaccel_output_format qsv -hwaccel_device qs -c:v
> h264_qsv \
> > -i input.264 -vf
> "hwmap=derive_device=opencl,format=opencl,avgblur_opencl, \
> > hwmap=derive_device=qsv:reverse=1:extra_hw_frames=32,format=qsv" \
> > -c:v h264_qsv output.264
> >
> > Signed-off-by: nyanmisaka 
> > Signed-off-by: Wenbin Chen 
> > ---
> >  libavutil/hwcontext_opencl.c | 3 ++-
> >  libavutil/hwcontext_qsv.h| 5 +
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> > index 26a3a24593..ab812999cd 100644
> > --- a/libavutil/hwcontext_opencl.c
> > +++ b/libavutil/hwcontext_opencl.c
> > @@ -48,6 +48,7 @@
> >  #if HAVE_OPENCL_VAAPI_INTEL_MEDIA
> >  #if CONFIG_LIBMFX
> >  #include 
> > +#include "hwcontext_qsv.h"
> >  #endif
> >  #include 
> >  #include 
> > @@ -2249,7 +2250,7 @@ static int
> opencl_map_from_qsv(AVHWFramesContext
> > *dst_fc, AVFrame *dst,
> >  #if CONFIG_LIBMFX
> >  if (src->format == AV_PIX_FMT_QSV) {
> >  mfxFrameSurface1 *mfx_surface = (mfxFrameSurface1*)src->data[3];
> > -va_surface = *(VASurfaceID*)mfx_surface->Data.MemId;
> > +va_surface = *MFXSURFACEP_TO_VASURFACEP(mfx_surface);
> >  } else
> >  #endif
> >  if (src->format == AV_PIX_FMT_VAAPI) {
> > diff --git a/libavutil/hwcontext_qsv.h b/libavutil/hwcontext_qsv.h
> > index b98d611cfc..957df01ef1 100644
> > --- a/libavutil/hwcontext_qsv.h
> > +++ b/libavutil/hwcontext_qsv.h
> > @@ -29,6 +29,11 @@
> >   * contain AVBufferRefs whose data pointer points to an
> mfxFrameSurface1
> > struct.
> >   */
> >
> > +#if CONFIG_VAAPI
> > +#define MFXSURFACEP_TO_VASURFACEP(surf) \
> > +(VASurfaceID*)(((mfxHDLPair*)surf->Data.MemId)->first)
> > +#endif
> > +
> 
> Is it possible to remove the dependency on VAAPI in a public qsv header file ?
> 
> Thanks
> Haihao

How about moving this to qsv_internal.h?

> 
> >  /**
> >   * This struct is allocated as AVHWDeviceContext.hwctx
> >   */
> ___
> 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/2] avcodec/qsvenc_hevc: use AV_OPT_TYPE_BOOL for aud option

[Xiang, Haihao]

On Sat, 2021-12-25 at 11:48 +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
> I haven't tested it for no build environment for qsv.
> 
>  libavcodec/qsvenc_hevc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> index 5847ea2..08aba30 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -250,7 +250,7 @@ static const AVOption options[] = {
>  { "tile_cols",  "Number of columns for tiled
> encoding",   OFFSET(qsv.tile_cols),AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
> UINT16_MAX, VE },
>  { "tile_rows",  "Number of rows for tiled
> encoding",  OFFSET(qsv.tile_rows),AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
> UINT16_MAX, VE },
>  { "recovery_point_sei", "Insert recovery point SEI
> messages",   OFFSET(qsv.recovery_point_sei),  AV_OPT_TYPE_INT, { .i64
> = -1 },   -1,  1, VE },
> -{ "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
> +{ "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE},
>  
>  { NULL },
>  };

Tested and applied, thx

-Haihao

___
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 V3 2/2] libavutil/hwcontext_opencl: fix a bug for mapping qsv frame to opencl

[Xiang, Haihao]

On Mon, 2021-12-27 at 03:13 +, Chen, Wenbin wrote:
> > On Fri, 2021-12-10 at 13:38 +0800, Wenbin Chen wrote:
> > > From: nyanmisaka 
> > > 
> > > mfxHDLPair was added to qsv, so modify qsv->opencl map function as well.
> > > Now the following commandline works:
> > > 
> > > ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 \
> > > -init_hw_device qsv=qs@va -init_hw_device opencl=ocl@va -
> > 
> > filter_hw_device ocl
> > > \
> > > -hwaccel qsv -hwaccel_output_format qsv -hwaccel_device qs -c:v
> > 
> > h264_qsv \
> > > -i input.264 -vf
> > 
> > "hwmap=derive_device=opencl,format=opencl,avgblur_opencl, \
> > > hwmap=derive_device=qsv:reverse=1:extra_hw_frames=32,format=qsv" \
> > > -c:v h264_qsv output.264
> > > 
> > > Signed-off-by: nyanmisaka 
> > > Signed-off-by: Wenbin Chen 
> > > ---
> > >  libavutil/hwcontext_opencl.c | 3 ++-
> > >  libavutil/hwcontext_qsv.h| 5 +
> > >  2 files changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> > > index 26a3a24593..ab812999cd 100644
> > > --- a/libavutil/hwcontext_opencl.c
> > > +++ b/libavutil/hwcontext_opencl.c
> > > @@ -48,6 +48,7 @@
> > >  #if HAVE_OPENCL_VAAPI_INTEL_MEDIA
> > >  #if CONFIG_LIBMFX
> > >  #include 
> > > +#include "hwcontext_qsv.h"
> > >  #endif
> > >  #include 
> > >  #include 
> > > @@ -2249,7 +2250,7 @@ static int
> > 
> > opencl_map_from_qsv(AVHWFramesContext
> > > *dst_fc, AVFrame *dst,
> > >  #if CONFIG_LIBMFX
> > >  if (src->format == AV_PIX_FMT_QSV) {
> > >  mfxFrameSurface1 *mfx_surface = (mfxFrameSurface1*)src->data[3];
> > > -va_surface = *(VASurfaceID*)mfx_surface->Data.MemId;
> > > +va_surface = *MFXSURFACEP_TO_VASURFACEP(mfx_surface);
> > >  } else
> > >  #endif
> > >  if (src->format == AV_PIX_FMT_VAAPI) {
> > > diff --git a/libavutil/hwcontext_qsv.h b/libavutil/hwcontext_qsv.h
> > > index b98d611cfc..957df01ef1 100644
> > > --- a/libavutil/hwcontext_qsv.h
> > > +++ b/libavutil/hwcontext_qsv.h
> > > @@ -29,6 +29,11 @@
> > >   * contain AVBufferRefs whose data pointer points to an
> > 
> > mfxFrameSurface1
> > > struct.
> > >   */
> > > 
> > > +#if CONFIG_VAAPI
> > > +#define MFXSURFACEP_TO_VASURFACEP(surf) \
> > > +(VASurfaceID*)(((mfxHDLPair*)surf->Data.MemId)->first)
> > > +#endif
> > > +
> > 
> > Is it possible to remove the dependency on VAAPI in a public qsv header file
> > ?
> > 
> > Thanks
> > Haihao
> 
> How about moving this to qsv_internal.h?
> 

There is no qsv_internal.h in libavutils. I think we may provide a function
using ff_ as prefix to get the internal vaapi/dxva2/d3d11va handle, user may
call this function and cast the returned handle to the right type in other
hwcontext. If so, we needn't add the dependency on VAAPI in this public header
file. 

Thanks
Haihao

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

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

[FFmpeg-devel] [PATCH] avformat/mov: correct 0 valued entries in stts

[Gyan Doshi]

As per ISO 14496-12, sample duration of 0 is invalid except for
the last entry.

In addition, also catch 0 value for sample count.
---
 libavformat/mov.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..fb7406cdd6 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2968,6 +2968,18 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n",
 sample_count, sample_duration);
 
+if (!sample_count) {
+av_log(c->fc, AV_LOG_WARNING, "invalid sample count of 0 in stts for 
st %d at entry %u; changing to 1.\n",
+   c->fc->nb_streams-1, i);
+sc->stts_data[i].count = sample_count = 1;
+}
+
+if (!sample_duration && i != entries-1) {
+av_log(c->fc, AV_LOG_WARNING, "invalid sample delta of 0 in stts for 
st %d at entry %u; changing to 1.\n",
+   c->fc->nb_streams-1, i);
+sc->stts_data[i].duration = sample_duration = 1;
+}
+
 duration+=(int64_t)sample_duration*(uint64_t)sample_count;
 total_sample_count+=sample_count;
 }
-- 
2.33.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 v3] avformat/mov: add option max_stts_delta

[Gyan Doshi]

On 2021-12-27 05:21 am, Michael Niedermayer wrote:

On Sun, Dec 26, 2021 at 09:30:44PM +0530, Gyan Doshi wrote:

Very high stts sample deltas may occasionally be intended but usually
they are written in error or used to store a negative value for dts correction
when treated as signed 32-bit integers.

This option lets the user set an upper limit, beyond which the delta is clamped 
to 1.
Values greater than the limit if negative when cast to int32 are used to adjust 
onward dts.

Unit is the track time scale. Default is UINT_MAX - 48000*10 which
allows upto a 10 second dts correction for 48 kHz audio streams while
accommodating 99.9% of uint32 range.
---
v3 changes:

factored out loop
simplified correction logic

this looks more sane now
i guess this cannot be easily split into a seperate patch ?


No, all stts corrections depend on context of earlier corrections.



[...]

@@ -2965,11 +2967,34 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
  sc->stts_data[i].count= sample_count;
  sc->stts_data[i].duration= sample_duration;
  
-av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n",

+av_log(c->fc, AV_LOG_TRACE, "sample_count=%u, sample_duration=%u\n",
  sample_count, sample_duration);
  
-duration+=(int64_t)sample_duration*(uint64_t)sample_count;

-total_sample_count+=sample_count;
+/* STTS sample offsets are uint32 but some files store it as int32
+ * with negative values used to correct DTS delays.
+   There may be abnormally large values as well. */
+if (sample_duration > c->max_stts_delta) {
+// assume high delta is a correction if negative when cast as int32
+int32_t delta_magnitude = (int32_t)sample_duration;
+av_log(c->fc, AV_LOG_WARNING, "Too large sample offset %u in stts entry 
%u with count %u in st:%d. Clipping to 1.\n",
+   sample_duration, i, sample_count, st->index);
+sc->stts_data[i].duration = 1;
+corrected_dts += (delta_magnitude < 0 ? (int64_t)delta_magnitude : 
1) * sample_count;
+} else {
+corrected_dts += sample_duration * sample_count;
+}
+
+current_dts += sc->stts_data[i].duration * sample_count;
+
+if (current_dts > corrected_dts) {
+int64_t drift = (current_dts - corrected_dts)/sample_count;

division by 0


A sample count of 0 is nonsensical. Sent a separate patch for 0 values 
in stts. Will rebase this one on top.


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

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m_dec: dequeue frame if input isn't ready

[Andriy Gelman]

On Tue, 14. Dec 02:12, Cameron Gutman wrote:
> The V4L2M2M API operates asynchronously, so multiple packets can
> be enqueued before getting a batch of frames back. Since it was
> only possible to receive a frame by submitting another packet,
> there wasn't a way to drain those excess output frames from when
> avcodec_receive_frame() returned AVERROR(EAGAIN).
> 

> In my testing, this change reduced decode latency of a real-time
> 60 FPS H.264 stream by approximately 10x (200ms -> 20ms) on a
> Raspberry Pi 4.

I was doing some more tests today, but didn't have any luck dequeuing a frame
if ff_decode_get_packet() returned EAGAIN.
Could you share the dataset?

Thanks,
-- 
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".

Re: [FFmpeg-devel] [PATCH] avformat/mov: correct 0 valued entries in stts

[zhilizhao(赵志立)]

> On Dec 27, 2021, at 1:57 PM, Gyan Doshi  wrote:
> 
> As per ISO 14496-12, sample duration of 0 is invalid except for
> the last entry.
> 
> In addition, also catch 0 value for sample count.
> ---
> libavformat/mov.c | 12 
> 1 file changed, 12 insertions(+)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2aed6e80ef..fb7406cdd6 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2968,6 +2968,18 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
> av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n",
> sample_count, sample_duration);
> 
> +if (!sample_count) {
> +av_log(c->fc, AV_LOG_WARNING, "invalid sample count of 0 in stts for 
> st %d at entry %u; changing to 1.\n",
> +   c->fc->nb_streams-1, i);

No, zero is a valid value, for example, fragmented mp4.

> +sc->stts_data[i].count = sample_count = 1;
> +}
> +
> +if (!sample_duration && i != entries-1) {
> +av_log(c->fc, AV_LOG_WARNING, "invalid sample delta of 0 in stts for 
> st %d at entry %u; changing to 1.\n",
> +   c->fc->nb_streams-1, i);
> +sc->stts_data[i].duration = sample_duration = 1;
> +}
> +
> duration+=(int64_t)sample_duration*(uint64_t)sample_count;
> total_sample_count+=sample_count;
> }
> -- 
> 2.33.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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: correct 0 valued entries in stts

[zhilizhao(赵志立)]

> On Dec 27, 2021, at 2:38 PM, zhilizhao(赵志立)  wrote:
> 
>> On Dec 27, 2021, at 1:57 PM, Gyan Doshi  wrote:
>> 
>> As per ISO 14496-12, sample duration of 0 is invalid except for
>> the last entry.
>> 
>> In addition, also catch 0 value for sample count.
>> ---
>> libavformat/mov.c | 12 
>> 1 file changed, 12 insertions(+)
>> 
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 2aed6e80ef..fb7406cdd6 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -2968,6 +2968,18 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
>> *pb, MOVAtom atom)
>>av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n",
>>sample_count, sample_duration);
>> 
>> +if (!sample_count) {
>> +av_log(c->fc, AV_LOG_WARNING, "invalid sample count of 0 in stts 
>> for st %d at entry %u; changing to 1.\n",
>> +   c->fc->nb_streams-1, i);
> 
> No, zero is a valid value, for example, fragmented mp4.

Ok, it’s sample_count, not entry_count.

> 
>> +sc->stts_data[i].count = sample_count = 1;
>> +}
>> +
>> +if (!sample_duration && i != entries-1) {
>> +av_log(c->fc, AV_LOG_WARNING, "invalid sample delta of 0 in stts 
>> for st %d at entry %u; changing to 1.\n",
>> +   c->fc->nb_streams-1, i);
>> +sc->stts_data[i].duration = sample_duration = 1;
>> +}
>> +
>>duration+=(int64_t)sample_duration*(uint64_t)sample_count;
>>total_sample_count+=sample_count;
>>}
>> -- 
>> 2.33.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 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/3] libavcodec/vaapi_encode: Change the way to call async to increase performance

[Xiang, Haihao]

On Wed, 2021-10-27 at 16:57 +0800, Wenbin Chen wrote:
> Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
> decrease. The reason is that vaRenderPicture() and vaSyncSurface() are
> called at the same time (vaRenderPicture() always followed by a
> vaSyncSurface()). When we encode stream with B frames, we need buffer to
> reorder frames, so we can send serveral frames to HW at once to increase
> performance. Now I changed them to be called in a
> asynchronous way, which will make better use of hardware.
> 1080p transcoding increases about 17% fps on my environment.

Could you provide your command ? I'd like to have a try. 

Thanks
Haihao

> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavcodec/vaapi_encode.c | 41 ---
>  libavcodec/vaapi_encode.h |  3 +++
>  2 files changed, 33 insertions(+), 11 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index ec054ae701..5927849233 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -951,8 +951,10 @@ static int vaapi_encode_pick_next(AVCodecContext *avctx,
>  if (!pic && ctx->end_of_stream) {
>  --b_counter;
>  pic = ctx->pic_end;
> -if (pic->encode_issued)
> +if (pic->encode_complete)
>  return AVERROR_EOF;
> +else if (pic->encode_issued)
> +return AVERROR(EAGAIN);
>  }
>  
>  if (!pic) {
> @@ -1177,20 +1179,31 @@ int ff_vaapi_encode_receive_packet(AVCodecContext
> *avctx, AVPacket *pkt)
>  return AVERROR(EAGAIN);
>  }
>  
> -pic = NULL;
> -err = vaapi_encode_pick_next(avctx, &pic);
> -if (err < 0)
> -return err;
> -av_assert0(pic);
> +while (av_fifo_size(ctx->encode_fifo) <= MAX_PICTURE_REFERENCES *
> sizeof(VAAPIEncodePicture *)) {
> +pic = NULL;
> +err = vaapi_encode_pick_next(avctx, &pic);
> +if (err < 0)
> +break;
> +av_assert0(pic);
>  
> -pic->encode_order = ctx->encode_order++;
> +pic->encode_order = ctx->encode_order +
> +(av_fifo_size(ctx->encode_fifo) /
> sizeof(VAAPIEncodePicture *));
>  
> -err = vaapi_encode_issue(avctx, pic);
> -if (err < 0) {
> -av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> -return err;
> +err = vaapi_encode_issue(avctx, pic);
> +if (err < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> +return err;
> +}
> +
> +av_fifo_generic_write(ctx->encode_fifo, &pic, sizeof(pic), NULL);
>  }
>  
> +if (!av_fifo_size(ctx->encode_fifo))
> +return err;
> +
> +av_fifo_generic_read(ctx->encode_fifo, &pic, sizeof(pic), NULL);
> +ctx->encode_order = pic->encode_order + 1;
> +
>  err = vaapi_encode_output(avctx, pic, pkt);
>  if (err < 0) {
>  av_log(avctx, AV_LOG_ERROR, "Output failed: %d.\n", err);
> @@ -2520,6 +2533,11 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
>  }
>  }
>  
> +ctx->encode_fifo = av_fifo_alloc((MAX_PICTURE_REFERENCES + 1) *
> +  sizeof(VAAPIEncodePicture *));
> +if (!ctx->encode_fifo)
> +return AVERROR(ENOMEM);
> +
>  return 0;
>  
>  fail:
> @@ -2552,6 +2570,7 @@ av_cold int ff_vaapi_encode_close(AVCodecContext *avctx)
>  
>  av_freep(&ctx->codec_sequence_params);
>  av_freep(&ctx->codec_picture_params);
> +av_fifo_freep(&ctx->encode_fifo);
>  
>  av_buffer_unref(&ctx->recon_frames_ref);
>  av_buffer_unref(&ctx->input_frames_ref);
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index b41604a883..89fe8de466 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -29,6 +29,7 @@
>  
>  #include "libavutil/hwcontext.h"
>  #include "libavutil/hwcontext_vaapi.h"
> +#include "libavutil/fifo.h"
>  
>  #include "avcodec.h"
>  #include "hwconfig.h"
> @@ -345,6 +346,8 @@ typedef struct VAAPIEncodeContext {
>  int roi_warned;
>  
>  AVFrame *frame;
> +
> +AVFifoBuffer *encode_fifo;
>  } VAAPIEncodeContext;
>  
>  enum {
___
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/3] libavcodec/vaapi_encode: Change the way to call async to increase performance

[Chen, Wenbin]

> On Wed, 2021-10-27 at 16:57 +0800, Wenbin Chen wrote:
> > Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
> > decrease. The reason is that vaRenderPicture() and vaSyncSurface() are
> > called at the same time (vaRenderPicture() always followed by a
> > vaSyncSurface()). When we encode stream with B frames, we need buffer
> to
> > reorder frames, so we can send serveral frames to HW at once to increase
> > performance. Now I changed them to be called in a
> > asynchronous way, which will make better use of hardware.
> > 1080p transcoding increases about 17% fps on my environment.
> 
> Could you provide your command ? I'd like to have a try.
> 
> Thanks
> Haihao

Here is my command:
ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.264 -c:v h264_vaapi 
output.264

Thanks
Wenbin

> 
> >
> > Signed-off-by: Wenbin Chen 
> > ---
> >  libavcodec/vaapi_encode.c | 41 ---
> >  libavcodec/vaapi_encode.h |  3 +++
> >  2 files changed, 33 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index ec054ae701..5927849233 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -951,8 +951,10 @@ static int
> vaapi_encode_pick_next(AVCodecContext *avctx,
> >  if (!pic && ctx->end_of_stream) {
> >  --b_counter;
> >  pic = ctx->pic_end;
> > -if (pic->encode_issued)
> > +if (pic->encode_complete)
> >  return AVERROR_EOF;
> > +else if (pic->encode_issued)
> > +return AVERROR(EAGAIN);
> >  }
> >
> >  if (!pic) {
> > @@ -1177,20 +1179,31 @@ int
> ff_vaapi_encode_receive_packet(AVCodecContext
> > *avctx, AVPacket *pkt)
> >  return AVERROR(EAGAIN);
> >  }
> >
> > -pic = NULL;
> > -err = vaapi_encode_pick_next(avctx, &pic);
> > -if (err < 0)
> > -return err;
> > -av_assert0(pic);
> > +while (av_fifo_size(ctx->encode_fifo) <= MAX_PICTURE_REFERENCES *
> > sizeof(VAAPIEncodePicture *)) {
> > +pic = NULL;
> > +err = vaapi_encode_pick_next(avctx, &pic);
> > +if (err < 0)
> > +break;
> > +av_assert0(pic);
> >
> > -pic->encode_order = ctx->encode_order++;
> > +pic->encode_order = ctx->encode_order +
> > +(av_fifo_size(ctx->encode_fifo) /
> > sizeof(VAAPIEncodePicture *));
> >
> > -err = vaapi_encode_issue(avctx, pic);
> > -if (err < 0) {
> > -av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> > -return err;
> > +err = vaapi_encode_issue(avctx, pic);
> > +if (err < 0) {
> > +av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> > +return err;
> > +}
> > +
> > +av_fifo_generic_write(ctx->encode_fifo, &pic, sizeof(pic), NULL);
> >  }
> >
> > +if (!av_fifo_size(ctx->encode_fifo))
> > +return err;
> > +
> > +av_fifo_generic_read(ctx->encode_fifo, &pic, sizeof(pic), NULL);
> > +ctx->encode_order = pic->encode_order + 1;
> > +
> >  err = vaapi_encode_output(avctx, pic, pkt);
> >  if (err < 0) {
> >  av_log(avctx, AV_LOG_ERROR, "Output failed: %d.\n", err);
> > @@ -2520,6 +2533,11 @@ av_cold int
> ff_vaapi_encode_init(AVCodecContext *avctx)
> >  }
> >  }
> >
> > +ctx->encode_fifo = av_fifo_alloc((MAX_PICTURE_REFERENCES + 1) *
> > +  sizeof(VAAPIEncodePicture *));
> > +if (!ctx->encode_fifo)
> > +return AVERROR(ENOMEM);
> > +
> >  return 0;
> >
> >  fail:
> > @@ -2552,6 +2570,7 @@ av_cold int
> ff_vaapi_encode_close(AVCodecContext *avctx)
> >
> >  av_freep(&ctx->codec_sequence_params);
> >  av_freep(&ctx->codec_picture_params);
> > +av_fifo_freep(&ctx->encode_fifo);
> >
> >  av_buffer_unref(&ctx->recon_frames_ref);
> >  av_buffer_unref(&ctx->input_frames_ref);
> > diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> > index b41604a883..89fe8de466 100644
> > --- a/libavcodec/vaapi_encode.h
> > +++ b/libavcodec/vaapi_encode.h
> > @@ -29,6 +29,7 @@
> >
> >  #include "libavutil/hwcontext.h"
> >  #include "libavutil/hwcontext_vaapi.h"
> > +#include "libavutil/fifo.h"
> >
> >  #include "avcodec.h"
> >  #include "hwconfig.h"
> > @@ -345,6 +346,8 @@ typedef struct VAAPIEncodeContext {
> >  int roi_warned;
> >
> >  AVFrame *frame;
> > +
> > +AVFifoBuffer *encode_fifo;
> >  } VAAPIEncodeContext;
> >
> >  enum {
___
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".