[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add low_delay_b option for HEVC

[Linjie Fu]

Low delay B-frame is supported on ICL+ platform.

For low power encoding, low_delay_b should be enabled by default.

Low delay B:


There is an on-going work in libva and media-driver to add querys
support for low delay b, would add it once it's ready:
https://github.com/intel/libva/pull/220
https://github.com/intel/libva/pull/364
https://github.com/intel/media-driver/issues/721

Signed-off-by: Linjie Fu 
---
 doc/encoders.texi  |  8 
 libavcodec/vaapi_encode_h265.c | 19 +--
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index e23b6b3..b0812be 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3089,6 +3089,14 @@ Some combination of the following values:
 Include HDR metadata if the input frames have it
 (@emph{mastering_display_colour_volume} and @emph{content_light_level}
 messages).
+
+@item low_delay_b
+Use low delay B-frames instead of P frames. Reordering of pictures is
+not allowed. The first picture is encoded as an I picture and subsequent
+pictures are encoded as B pictures. Moreover, since past B pictures are
+used for prediction, a low coding delay but with higher coding efficiency
+(because of bi-prediction) is achieved.
+
 @end table
 
 @end table
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 97dc5a7..cd48545 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -62,6 +62,7 @@ typedef struct VAAPIEncodeH265Context {
 int tier;
 int level;
 int sei;
+int low_delay_b;
 
 // Derived settings.
 int fixed_qp_idr;
@@ -894,6 +895,9 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 
 sh->slice_type = hpic->slice_type;
 
+if (sh->slice_type == HEVC_SLICE_P && priv->low_delay_b)
+sh->slice_type = HEVC_SLICE_B;
+
 sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
 (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1;
 
@@ -1054,9 +1058,13 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 vslice->ref_pic_list0[0] = vpic->reference_frames[0];
 }
 if (pic->nb_refs >= 2) {
-// Forward reference for B-frame.
 av_assert0(pic->type == PICTURE_TYPE_B);
-vslice->ref_pic_list1[0] = vpic->reference_frames[1];
+if (priv->low_delay_b)
+// Reference for low delay B-frame
+vslice->ref_pic_list1[0] = vpic->reference_frames[0];
+else
+// Forward reference for B-frame.
+vslice->ref_pic_list1[0] = vpic->reference_frames[1];
 }
 
 return 0;
@@ -1181,6 +1189,11 @@ static av_cold int vaapi_encode_h265_init(AVCodecContext 
*avctx)
 if (priv->qp > 0)
 ctx->explicit_qp = priv->qp;
 
+/* low_delay_b is required for low power encoding */
+priv->low_delay_b = ctx->low_power ? 1 : priv->low_delay_b;
+if (priv->low_delay_b)
+av_log(avctx, AV_LOG_VERBOSE, "Low delay B-frame enabled.\n");
+
 return ff_vaapi_encode_init(avctx);
 }
 
@@ -1256,6 +1269,8 @@ static const AVOption vaapi_encode_h265_options[] = {
   0, AV_OPT_TYPE_CONST,
   { .i64 = SEI_MASTERING_DISPLAY | SEI_CONTENT_LIGHT_LEVEL },
   INT_MIN, INT_MAX, FLAGS, "sei" },
+{ "low_delay_b", "Use low delay B frames instead of P frames",
+  OFFSET(low_delay_b), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
 
 { NULL },
 };
-- 
2.7.4

___
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] lavc/vaapi_encode_h265: fix max_transform_hierarchy_depth_inter/intra

[Linjie Fu]

Set the max_transform_hierarchy_depth_inter/intra to 2 by default
based on the Programmer's Reference Manuals (PRM) in [1].

Intel Encoder only supports 2 levels of quad-tree. That is:
- max_transform_hierarchy_depth_inter/intra <= 2.

[1] 


Signed-off-by: Linjie Fu 
---
Fixed value for intel platform, makes more sense on TGL+ platform.
(If conflict with other driver capability, we may add query support
 later)
 libavcodec/vaapi_encode_h265.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index cd48545..d6cb82a 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -445,8 +445,9 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 sps->log2_min_luma_transform_block_size_minus2   = 0;
 sps->log2_diff_max_min_luma_transform_block_size = 3;
 // Full transform hierarchy allowed (2-5).
-sps->max_transform_hierarchy_depth_inter = 3;
-sps->max_transform_hierarchy_depth_intra = 3;
+// Default to 2 based on Programmer's Reference Manuals of Intel graphics
+sps->max_transform_hierarchy_depth_inter = 2;
+sps->max_transform_hierarchy_depth_intra = 2;
 // AMP works.
 sps->amp_enabled_flag = 1;
 // SAO and temporal MVP do not work.
-- 
2.7.4

___
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 00/20] Matroska muxer patches

[Andreas Rheinhardt]

Andreas Rheinhardt:
> This patchset is sort-of a revival of the part of a patchset I sent
> earlier [1], but which couldn't be applied fully because the way the
> webm_chunk muxer bypassed the API [2]. Now that this has been fixed [3],
> I have taken the opportunity to resend this patchset in an updated form.
> 
> It does not yet completely eliminate the limit on the number of tracks
> as requested in [4], but no longer counting attachments among the number
> of tracks is beneficial even if said limit will be removed.
> 
> - Andreas
> 
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/252578.html
> [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254783.html
> [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/257850.html
> [4]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259734.html
> 
> Andreas Rheinhardt (20):
>   avformat/matroskaenc: Ensure that ChapterUID are != 0
>   avformat/matroskaenc: Don't waste bytes writing durations
>   avformat/matroskaenc: Use random TrackUID
>   avformat/matroskaenc: Reuse random seed
>   avformat/matroskaenc: Remove allocations for Attachments
>   avformat/matroskaenc: Make output more deterministic
>   avformat/matroskaenc: Ignore AttachedFiles for track limit
>   avformat/matroskaenc: Automatically use right TrackNumber in Cues
>   avformat/matroskaenc: Increase max supported tracks
>   avformat/matroskaenc: Change signature of mkv_write_track()
>   avformat/matroskaenc: Add check for using explicit TrackNumber
>   avformat/matroskaenc: Improve Cues in case of no video
>   avformat/matroskaenc: Don't use size of inexistent Cluster
>   avformat/matroskaenc: Warn that WebM doesn't support Attachments
>   avformat/matroskaenc: Only write Tracks if there is a track
>   avformat/matroskaenc: Don't waste bytes on length fields
>   avformat/matroskaenc: Add const where appropriate
>   avformat/matroskaenc: Don't needlessly copy AVCodecParameters
>   avformat/matroskaenc: Redo handling of FlagDefault
>   avformat/matroskaenc: Cosmetics
> 
>  doc/muxers.texi   |  19 +
>  libavformat/matroskaenc.c | 595 ++
>  tests/fate/matroska.mak   |   2 +-
>  tests/fate/wavpack.mak|   4 +-
>  tests/ref/fate/aac-autobsf-adtstoasc  |   4 +-
>  tests/ref/fate/binsub-mksenc  |   2 +-
>  tests/ref/fate/matroska-flac-extradata-update |   4 +-
>  tests/ref/fate/rgb24-mkv  |   4 +-
>  tests/ref/lavf-fate/av1.mkv   |   2 +-
>  tests/ref/lavf/mka|   4 +-
>  tests/ref/lavf/mkv|   4 +-
>  tests/ref/lavf/mkv_attachment |   4 +-
>  tests/ref/seek/lavf-mkv   |  44 +-
>  13 files changed, 384 insertions(+), 308 deletions(-)
> 
Will apply the initial half of the patchset (i.e. 1-10 with the
exception of 9).

- Andreas
___
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] FFMPEG On YouTube

[ffmpeg-devel]

On this YouTube Channel I cover different Tech Topics:

https://www.youtube.com/channel/UCyoHzQ_ePBPct3qbB-J7dMQ

As part of the Content I create, I will follow this and the
ffmpeg-user list and answer questions, follow threads,
etc.

I have been participating in these mailing lists off and on
for more than 10 years. It will make for some good tech content.

I will be doing it live, and pre-recorded. It makes for some
very easy ad-hoc live content that I hope helps.

Thanks.

___
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 1/2] avcodec: add adpcm_ima_ssi encoder

[Zane van Iperen]

On Sun, 12 Apr 2020 16:38:06 +0200
"Paul B Mahol"  wrote:

> On 4/12/20, Zane van Iperen  wrote:
> > On Sun, 12 Apr 2020 15:01:39 +0200
> > "Paul B Mahol"  wrote:
> >  
> >> >
> >> > I probably should have mentioned that yes, I had already added
> >> > the appropriate SSI code to adpcm_compress_trellis().  
> >>
> >> The one that updates node predictor?  
> >> >
> >> >  
> > Yep, wherever there was a check for QT, I added a check for SSI so
> > that they both take the same code paths.
> >
> > They're the same format, so that shouldn't cause any problems.
> >  
> 
> Please point to latest such patch that contain that change.

Here:
https://github.com/vs49688/FFmpeg ssienc-v4-pre

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

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

Re: [FFmpeg-devel] [PATCH v2] avutil/log: update text requesting samples

[Carl Eugen Hoyos]

Am Mo., 13. Apr. 2020 um 02:19 Uhr schrieb Marton Balint :
>
>
>
> On Mon, 13 Apr 2020, Carl Eugen Hoyos wrote:
>
> > Am Mo., 13. Apr. 2020 um 00:45 Uhr schrieb Marton Balint :
> >>
> >> Signed-off-by: Marton Balint 
> >> ---
> >>  libavutil/log.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavutil/log.c b/libavutil/log.c
> >> index 8d4945249e..965dbca5e1 100644
> >> --- a/libavutil/log.c
> >> +++ b/libavutil/log.c
> >> @@ -466,9 +466,9 @@ static void missing_feature_sample(int sample, void 
> >> *avc, const char *msg,
> >> "occurs, it means that your file has a feature which has not "
> >> "been implemented.\n");
> >>  if (sample)
> >> -av_log(avc, AV_LOG_WARNING, "If you want to help, upload a sample 
> >> "
> >> -   "of this file to ftp://upload.ffmpeg.org/incoming/ "
> >> -   "and contact the ffmpeg-devel mailing list. 
> >> (ffmpeg-devel@ffmpeg.org)\n");
> >> +av_log(avc, AV_LOG_WARNING, "If you want to help, contact "
> >> +   "ffmpeg-devel@ffmpeg.org and if requested upload a sample "
> >> +   "of this file to https://streams.videolan.org/upload/\n";);
> >
> > Uploading a sample is of course much more important than sending an email,
> > so this makes the patch significantly worse imo.
>
> You wrote that we typically ask for samples we already have. So why
> aks for uploading them first?

Even if we already have 99% of such samples (we certainly don't), I
would consider getting the remaining 1% of highest importance.

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

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

Re: [FFmpeg-devel] [PATCH v2] avutil/log: update text requesting samples

[Marton Balint]

On Mon, 13 Apr 2020, Carl Eugen Hoyos wrote:


Am Mo., 13. Apr. 2020 um 00:45 Uhr schrieb Marton Balint :


Signed-off-by: Marton Balint 
---
 libavutil/log.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/log.c b/libavutil/log.c
index 8d4945249e..965dbca5e1 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -466,9 +466,9 @@ static void missing_feature_sample(int sample, void *avc, 
const char *msg,
"occurs, it means that your file has a feature which has not "
"been implemented.\n");
 if (sample)
-av_log(avc, AV_LOG_WARNING, "If you want to help, upload a sample "
-   "of this file to ftp://upload.ffmpeg.org/incoming/ "
-   "and contact the ffmpeg-devel mailing list. 
(ffmpeg-devel@ffmpeg.org)\n");
+av_log(avc, AV_LOG_WARNING, "If you want to help, contact "
+   "ffmpeg-devel@ffmpeg.org and if requested upload a sample "
+   "of this file to https://streams.videolan.org/upload/\n";);


Uploading a sample is of course much more important than sending an email,
so this makes the patch significantly worse imo.


You wrote that we typically ask for samples we already have. So why 
aks for uploading them first?


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

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

Re: [FFmpeg-devel] [PATCH v2 4/4] avformat/mpegtsenc: use the correct stream_types and write HDMV descriptors for m2ts

[Marton Balint]

On Mon, 13 Apr 2020, Carl Eugen Hoyos wrote:


Am Mo., 13. Apr. 2020 um 00:38 Uhr schrieb Marton Balint :


Fixes ticket #2622.

Signed-off-by: Marton Balint 
---
 Changelog   |  1 +
 libavformat/mpegtsenc.c | 58 -
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 6dfe750d81..4ba44e5e2d 100644
--- a/Changelog
+++ b/Changelog
@@ -58,6 +58,7 @@ version :
 - switch from AvxSynth to AviSynth+ on Linux
 - mv30 decoder
 - Expanded styling support for 3GPP Timed Text Subtitles (movtext)
+- use the correct stream types for m2ts output


Don't you agree that "Support pcm audio when muxing m2ts"
or "Support BluRay muxing" is a stronger wording?


That is not true, m2ts mode is nowhere near Blu-ray compatible yet, so it 
would be misleading to say that. Also it is not just about PCM audio, the 
ticket was opened for PGS subtitles as far as I remember.


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

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

Re: [FFmpeg-devel] [PATCH v2 4/4] avformat/mpegtsenc: use the correct stream_types and write HDMV descriptors for m2ts

[Carl Eugen Hoyos]

Am Mo., 13. Apr. 2020 um 00:38 Uhr schrieb Marton Balint :
>
> Fixes ticket #2622.
>
> Signed-off-by: Marton Balint 
> ---
>  Changelog   |  1 +
>  libavformat/mpegtsenc.c | 58 
> -
>  2 files changed, 58 insertions(+), 1 deletion(-)
>
> diff --git a/Changelog b/Changelog
> index 6dfe750d81..4ba44e5e2d 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -58,6 +58,7 @@ version :
>  - switch from AvxSynth to AviSynth+ on Linux
>  - mv30 decoder
>  - Expanded styling support for 3GPP Timed Text Subtitles (movtext)
> +- use the correct stream types for m2ts output

Don't you agree that "Support pcm audio when muxing m2ts"
or "Support BluRay muxing" is a stronger wording?

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

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

Re: [FFmpeg-devel] [PATCH v2] avutil/log: update text requesting samples

[Carl Eugen Hoyos]

Am Mo., 13. Apr. 2020 um 00:45 Uhr schrieb Marton Balint :
>
> Signed-off-by: Marton Balint 
> ---
>  libavutil/log.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/log.c b/libavutil/log.c
> index 8d4945249e..965dbca5e1 100644
> --- a/libavutil/log.c
> +++ b/libavutil/log.c
> @@ -466,9 +466,9 @@ static void missing_feature_sample(int sample, void *avc, 
> const char *msg,
> "occurs, it means that your file has a feature which has not "
> "been implemented.\n");
>  if (sample)
> -av_log(avc, AV_LOG_WARNING, "If you want to help, upload a sample "
> -   "of this file to ftp://upload.ffmpeg.org/incoming/ "
> -   "and contact the ffmpeg-devel mailing list. 
> (ffmpeg-devel@ffmpeg.org)\n");
> +av_log(avc, AV_LOG_WARNING, "If you want to help, contact "
> +   "ffmpeg-devel@ffmpeg.org and if requested upload a sample "
> +   "of this file to https://streams.videolan.org/upload/\n";);

Uploading a sample is of course much more important than sending an email,
so this makes the patch significantly worse imo.

Carl Eugen
___
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]lavu/mem: Make alloc array functions more similar to av_malloc

[Andreas Rheinhardt]

Carl Eugen Hoyos:
> Am Mo., 13. Apr. 2020 um 00:20 Uhr schrieb James Almer :
>>
>> On 4/12/2020 7:07 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 23:58 Uhr schrieb James Almer :

 On 4/12/2020 6:53 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer 
> :
>>
>> On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer 
>>> :

 On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> :
>>
>> Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
>> :
>>>
>>> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
 Hi!

 Attached patch makes the alloc array functions more similar to
 av_malloc, depending on max_alloc_size instead of INT_MAX.

 Allows a work-around for ticket #7140

 Please comment, Carl Eugen
>>>
  mem.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 507531ed6f0932834d005bc1dd7d18e762f158b2  
 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
 From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 
 2001
 From: Carl Eugen Hoyos 
 Date: Sat, 4 Apr 2020 00:37:03 +0200
 Subject: [PATCH] lavu/mem: Make alloc array functions more similar 
 to
  av_malloc().

 Do not limit the array allocation functions to allocations of 
 INT_MAX,
 instead depend on max_alloc_size like av_malloc().

 Allows a workaround for ticket #7140.
 ---
  libavutil/mem.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> av_size_mult() may be faster
>>
>> New patch attached.
>
> And an actually working variant.
>
> Please comment, Carl Eugen

> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 12 Apr 2020 00:36:30 +0200
> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> av_malloc().
>
> Do not limit the array allocation functions and av_calloc() to 
> allocations
> of INT_MAX, instead depend on max_alloc_size like av_malloc().
>
> Allows a workaround for ticket #7140.
> ---
>  libavutil/mem.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 88fe09b179..e044374c62 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
>
>  void *av_malloc_array(size_t nmemb, size_t size)
>  {
> -if (!size || nmemb >= INT_MAX / size)
> +size_t result;
> +if (av_size_mult(nmemb, size, &result) < 0)
>  return NULL;
> -return av_malloc(nmemb * size);
> +return av_malloc(result);

 If I'm reading this right, when size is 0, instead of NULL this will 
 now
 return av_malloc(0), which looks like it may end up being a pointer to 
 a
 1 byte big buffer. Is that intended?

 The previous version you sent apparently considered that scenario.
>>>
>>> But it did not pass fate because the behaviour before the patch
>>> was not to return NULL for alloc(0).
>>
>> Before this patch it would return NULL when size was 0 and alloc(0) when
>> nmemb was 0. Now it will return alloc(0) when either of the two
>> arguments is 0.
>>
>> The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
>> similar instead, if we want to keep the original behavior.
>
> How did the original behaviour make any sense?

 Not saying it made sense, i'm saying we changed that behavior when the
 patch, at least based on the description, only tried to replace the
 INT_MAX limit with max_alloc_size.

 If making size 0 return malloc(0) was intended, or ultimately preferred,
 then I'll not oppose to it.
>>>
>>> To me, the old behaviour (returning NULL for some argument being 0
>>> but not the other) made less sense than the new behaviour (not
>>> special-casing 0 for any argument).
>>> The fact that returning NULL broke fate surprised me but I failed
>>> to find the reason.
>>
>> I'm fairly sure your first patch failed because it made one of these
>> functions return NULL for an nmemb == 0 case in some test, when it was
>>

[FFmpeg-devel] [PATCH v2] avutil/log: update text requesting samples

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavutil/log.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/log.c b/libavutil/log.c
index 8d4945249e..965dbca5e1 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -466,9 +466,9 @@ static void missing_feature_sample(int sample, void *avc, 
const char *msg,
"occurs, it means that your file has a feature which has not "
"been implemented.\n");
 if (sample)
-av_log(avc, AV_LOG_WARNING, "If you want to help, upload a sample "
-   "of this file to ftp://upload.ffmpeg.org/incoming/ "
-   "and contact the ffmpeg-devel mailing list. 
(ffmpeg-devel@ffmpeg.org)\n");
+av_log(avc, AV_LOG_WARNING, "If you want to help, contact "
+   "ffmpeg-devel@ffmpeg.org and if requested upload a sample "
+   "of this file to https://streams.videolan.org/upload/\n";);
 }
 
 void avpriv_request_sample(void *avc, const char *msg, ...)
-- 
2.16.4

___
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 v2 4/4] avformat/mpegtsenc: use the correct stream_types and write HDMV descriptors for m2ts

[Marton Balint]

Fixes ticket #2622.

Signed-off-by: Marton Balint 
---
 Changelog   |  1 +
 libavformat/mpegtsenc.c | 58 -
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 6dfe750d81..4ba44e5e2d 100644
--- a/Changelog
+++ b/Changelog
@@ -58,6 +58,7 @@ version :
 - switch from AvxSynth to AviSynth+ on Linux
 - mv30 decoder
 - Expanded styling support for 3GPP Timed Text Subtitles (movtext)
+- use the correct stream types for m2ts output
 
 
 version 4.2:
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index add35aca89..b154675d60 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -359,6 +359,54 @@ static int get_dvb_stream_type(AVFormatContext *s, 
AVStream *st)
 return stream_type;
 }
 
+static int get_m2ts_stream_type(AVFormatContext *s, AVStream *st)
+{
+int stream_type;
+
+switch (st->codecpar->codec_id) {
+case AV_CODEC_ID_MPEG2VIDEO:
+stream_type = STREAM_TYPE_VIDEO_MPEG2;
+break;
+case AV_CODEC_ID_H264:
+stream_type = STREAM_TYPE_VIDEO_H264;
+break;
+case AV_CODEC_ID_VC1:
+stream_type = STREAM_TYPE_VIDEO_VC1;
+break;
+case AV_CODEC_ID_HEVC:
+stream_type = STREAM_TYPE_VIDEO_HEVC;
+break;
+case AV_CODEC_ID_PCM_BLURAY:
+stream_type = 0x80;
+break;
+case AV_CODEC_ID_AC3:
+stream_type = 0x81;
+break;
+case AV_CODEC_ID_DTS:
+stream_type = (st->codecpar->channels > 6) ? 0x85 : 0x82;
+break;
+case AV_CODEC_ID_TRUEHD:
+stream_type = 0x83;
+break;
+case AV_CODEC_ID_EAC3:
+stream_type = 0x84;
+break;
+case AV_CODEC_ID_HDMV_PGS_SUBTITLE:
+stream_type = 0x90;
+break;
+case AV_CODEC_ID_HDMV_TEXT_SUBTITLE:
+stream_type = 0x92;
+break;
+default:
+av_log(s, AV_LOG_WARNING, "Stream %d, codec %s, is muxed as a private 
data stream "
+   "and may not be recognized upon reading.\n", st->index, 
avcodec_get_name(st->codecpar->codec_id));
+stream_type = STREAM_TYPE_PRIVATE_DATA;
+break;
+}
+
+return stream_type;
+}
+
 static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service)
 {
 MpegTSWrite *ts = s->priv_data;
@@ -372,6 +420,14 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 q += 2; /* patched after */
 
 /* put program info here */
+if (ts->m2ts_mode) {
+put_registration_descriptor(&q, MKTAG('H', 'D', 'M', 'V'));
+*q++ = 0x88;// descriptor_tag - hdmv_copy_control_descriptor
+*q++ = 0x04;// descriptor_length
+put16(&q, 0x0fff);  // CA_System_ID
+*q++ = 0xfc;// private_data_byte
+*q++ = 0xfc;// private_data_byte
+}
 
 val = 0xf000 | (q - program_info_length_ptr - 2);
 program_info_length_ptr[0] = val >> 8;
@@ -401,7 +457,7 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 break;
 }
 
-stream_type = get_dvb_stream_type(s, st);
+stream_type = ts->m2ts_mode ? get_m2ts_stream_type(s, st) : 
get_dvb_stream_type(s, st);
 
 *q++ = stream_type;
 put16(&q, 0xe000 | ts_st->pid);
-- 
2.16.4

___
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/8] fftools/ffmpeg: also flush encoders which have a variable frame size

[Marton Balint]

On Wed, 8 Apr 2020, Marton Balint wrote:




On Sat, 28 Mar 2020, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
fftools/ffmpeg.c | 3 ---
1 file changed, 3 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index aaaf241314..6cc3c5a14d 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1913,9 +1913,6 @@ static void flush_encoders(void)
}
}

-if (enc->codec_type == AVMEDIA_TYPE_AUDIO && enc->frame_size <= 1)
-continue;
-
if (enc->codec_type != AVMEDIA_TYPE_VIDEO && enc->codec_type != 

AVMEDIA_TYPE_AUDIO)

continue;


Ping for this, will apply soon.


Applied.

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

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

Re: [FFmpeg-devel] [PATCH]lavu/mem: Make alloc array functions more similar to av_malloc

[James Almer]

On 4/12/2020 7:26 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Apr. 2020 um 00:20 Uhr schrieb James Almer :
>>
>> On 4/12/2020 7:07 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 23:58 Uhr schrieb James Almer :

 On 4/12/2020 6:53 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer 
> :
>>
>> On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer 
>>> :

 On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> :
>>
>> Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
>> :
>>>
>>> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
 Hi!

 Attached patch makes the alloc array functions more similar to
 av_malloc, depending on max_alloc_size instead of INT_MAX.

 Allows a work-around for ticket #7140

 Please comment, Carl Eugen
>>>
  mem.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 507531ed6f0932834d005bc1dd7d18e762f158b2  
 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
 From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 
 2001
 From: Carl Eugen Hoyos 
 Date: Sat, 4 Apr 2020 00:37:03 +0200
 Subject: [PATCH] lavu/mem: Make alloc array functions more similar 
 to
  av_malloc().

 Do not limit the array allocation functions to allocations of 
 INT_MAX,
 instead depend on max_alloc_size like av_malloc().

 Allows a workaround for ticket #7140.
 ---
  libavutil/mem.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> av_size_mult() may be faster
>>
>> New patch attached.
>
> And an actually working variant.
>
> Please comment, Carl Eugen

> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 12 Apr 2020 00:36:30 +0200
> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> av_malloc().
>
> Do not limit the array allocation functions and av_calloc() to 
> allocations
> of INT_MAX, instead depend on max_alloc_size like av_malloc().
>
> Allows a workaround for ticket #7140.
> ---
>  libavutil/mem.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 88fe09b179..e044374c62 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
>
>  void *av_malloc_array(size_t nmemb, size_t size)
>  {
> -if (!size || nmemb >= INT_MAX / size)
> +size_t result;
> +if (av_size_mult(nmemb, size, &result) < 0)
>  return NULL;
> -return av_malloc(nmemb * size);
> +return av_malloc(result);

 If I'm reading this right, when size is 0, instead of NULL this will 
 now
 return av_malloc(0), which looks like it may end up being a pointer to 
 a
 1 byte big buffer. Is that intended?

 The previous version you sent apparently considered that scenario.
>>>
>>> But it did not pass fate because the behaviour before the patch
>>> was not to return NULL for alloc(0).
>>
>> Before this patch it would return NULL when size was 0 and alloc(0) when
>> nmemb was 0. Now it will return alloc(0) when either of the two
>> arguments is 0.
>>
>> The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
>> similar instead, if we want to keep the original behavior.
>
> How did the original behaviour make any sense?

 Not saying it made sense, i'm saying we changed that behavior when the
 patch, at least based on the description, only tried to replace the
 INT_MAX limit with max_alloc_size.

 If making size 0 return malloc(0) was intended, or ultimately preferred,
 then I'll not oppose to it.
>>>
>>> To me, the old behaviour (returning NULL for some argument being 0
>>> but not the other) made less sense than the new behaviour (not
>>> special-casing 0 for any argument).
>>> The fact that returning NULL broke fate surprised me but I failed
>>> to find the reason.
>>
>> I'm fairly sure your first patch failed because it made one of these
>> functions return NULL for an nmemb == 0 case 

Re: [FFmpeg-devel] [PATCH]lavu/mem: Make alloc array functions more similar to av_malloc

[Carl Eugen Hoyos]

Am Mo., 13. Apr. 2020 um 00:20 Uhr schrieb James Almer :
>
> On 4/12/2020 7:07 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 23:58 Uhr schrieb James Almer :
> >>
> >> On 4/12/2020 6:53 PM, Carl Eugen Hoyos wrote:
> >>> Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer 
> >>> :
> 
>  On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer 
> > :
> >>
> >> On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> >>> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> >>> :
> 
>  Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
>  :
> >
> > On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch makes the alloc array functions more similar to
> >> av_malloc, depending on max_alloc_size instead of INT_MAX.
> >>
> >> Allows a work-around for ticket #7140
> >>
> >> Please comment, Carl Eugen
> >
> >>  mem.c |8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >> 507531ed6f0932834d005bc1dd7d18e762f158b2  
> >> 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
> >> From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 
> >> 2001
> >> From: Carl Eugen Hoyos 
> >> Date: Sat, 4 Apr 2020 00:37:03 +0200
> >> Subject: [PATCH] lavu/mem: Make alloc array functions more similar 
> >> to
> >>  av_malloc().
> >>
> >> Do not limit the array allocation functions to allocations of 
> >> INT_MAX,
> >> instead depend on max_alloc_size like av_malloc().
> >>
> >> Allows a workaround for ticket #7140.
> >> ---
> >>  libavutil/mem.c | 8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > av_size_mult() may be faster
> 
>  New patch attached.
> >>>
> >>> And an actually working variant.
> >>>
> >>> Please comment, Carl Eugen
> >>
> >>> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> >>> From: Carl Eugen Hoyos 
> >>> Date: Sun, 12 Apr 2020 00:36:30 +0200
> >>> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> >>> av_malloc().
> >>>
> >>> Do not limit the array allocation functions and av_calloc() to 
> >>> allocations
> >>> of INT_MAX, instead depend on max_alloc_size like av_malloc().
> >>>
> >>> Allows a workaround for ticket #7140.
> >>> ---
> >>>  libavutil/mem.c | 20 
> >>>  1 file changed, 12 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/libavutil/mem.c b/libavutil/mem.c
> >>> index 88fe09b179..e044374c62 100644
> >>> --- a/libavutil/mem.c
> >>> +++ b/libavutil/mem.c
> >>> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
> >>>
> >>>  void *av_malloc_array(size_t nmemb, size_t size)
> >>>  {
> >>> -if (!size || nmemb >= INT_MAX / size)
> >>> +size_t result;
> >>> +if (av_size_mult(nmemb, size, &result) < 0)
> >>>  return NULL;
> >>> -return av_malloc(nmemb * size);
> >>> +return av_malloc(result);
> >>
> >> If I'm reading this right, when size is 0, instead of NULL this will 
> >> now
> >> return av_malloc(0), which looks like it may end up being a pointer to 
> >> a
> >> 1 byte big buffer. Is that intended?
> >>
> >> The previous version you sent apparently considered that scenario.
> >
> > But it did not pass fate because the behaviour before the patch
> > was not to return NULL for alloc(0).
> 
>  Before this patch it would return NULL when size was 0 and alloc(0) when
>  nmemb was 0. Now it will return alloc(0) when either of the two
>  arguments is 0.
> 
>  The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
>  similar instead, if we want to keep the original behavior.
> >>>
> >>> How did the original behaviour make any sense?
> >>
> >> Not saying it made sense, i'm saying we changed that behavior when the
> >> patch, at least based on the description, only tried to replace the
> >> INT_MAX limit with max_alloc_size.
> >>
> >> If making size 0 return malloc(0) was intended, or ultimately preferred,
> >> then I'll not oppose to it.
> >
> > To me, the old behaviour (returning NULL for some argument being 0
> > but not the other) made less sense than the new behaviour (not
> > special-casing 0 for any argument).
> > The fact that returning NULL broke fate surprised me but I failed
> > to find the reason.
>
> I'm fairly sure your first patch failed because it made one of these
> functions return NULL for an nmemb == 0 case in some test, when it was
> not expected to.

Of cour

[FFmpeg-devel] [PATCH 2/2] avcodec/cbs_jpeg_syntax_template: Check array index in huffman_table()

[Michael Niedermayer]

Fixes: index 224 out of bounds for type 'uint8_t [224]'
Fixes: 
21534/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-6291612167831552

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

diff --git a/libavcodec/cbs_jpeg_syntax_template.c 
b/libavcodec/cbs_jpeg_syntax_template.c
index 1ffb77d231..6eda56d623 100644
--- a/libavcodec/cbs_jpeg_syntax_template.c
+++ b/libavcodec/cbs_jpeg_syntax_template.c
@@ -89,6 +89,8 @@ static int FUNC(huffman_table)(CodedBitstreamContext *ctx, 
RWContext *rw,
 ij = 0;
 for (i = 0; i < 16; i++) {
 for (j = 0; j < current->L[i]; j++) {
+if (ij >= 224)
+return AVERROR_INVALIDDATA;
 us(8, V[ij], ij, 0, 255);
 ++ij;
 }
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 1/2] avcodec/cbs_jpeg_syntax_template: Check table index before use in dht()

[Michael Niedermayer]

Fixes: out of array access
Fixes: 
21515/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5766121576988672

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

diff --git a/libavcodec/cbs_jpeg_syntax_template.c 
b/libavcodec/cbs_jpeg_syntax_template.c
index d3cd9ff62e..1ffb77d231 100644
--- a/libavcodec/cbs_jpeg_syntax_template.c
+++ b/libavcodec/cbs_jpeg_syntax_template.c
@@ -108,6 +108,9 @@ static int FUNC(dht)(CodedBitstreamContext *ctx, RWContext 
*rw,
 
 n = 2;
 for (i = 0; n < current->Lh; i++) {
+if (i >= 8)
+return AVERROR_INVALIDDATA;
+
 CHECK(FUNC(huffman_table)(ctx, rw, ¤t->table[i]));
 
 ++n;
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH]lavu/mem: Make alloc array functions more similar to av_malloc

[James Almer]

On 4/12/2020 7:07 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 23:58 Uhr schrieb James Almer :
>>
>> On 4/12/2020 6:53 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer :

 On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer 
> :
>>
>> On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>>> :

 Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
 :
>
> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch makes the alloc array functions more similar to
>> av_malloc, depending on max_alloc_size instead of INT_MAX.
>>
>> Allows a work-around for ticket #7140
>>
>> Please comment, Carl Eugen
>
>>  mem.c |8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 507531ed6f0932834d005bc1dd7d18e762f158b2  
>> 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
>> From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 
>> 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 4 Apr 2020 00:37:03 +0200
>> Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
>>  av_malloc().
>>
>> Do not limit the array allocation functions to allocations of 
>> INT_MAX,
>> instead depend on max_alloc_size like av_malloc().
>>
>> Allows a workaround for ticket #7140.
>> ---
>>  libavutil/mem.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> av_size_mult() may be faster

 New patch attached.
>>>
>>> And an actually working variant.
>>>
>>> Please comment, Carl Eugen
>>
>>> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos 
>>> Date: Sun, 12 Apr 2020 00:36:30 +0200
>>> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
>>> av_malloc().
>>>
>>> Do not limit the array allocation functions and av_calloc() to 
>>> allocations
>>> of INT_MAX, instead depend on max_alloc_size like av_malloc().
>>>
>>> Allows a workaround for ticket #7140.
>>> ---
>>>  libavutil/mem.c | 20 
>>>  1 file changed, 12 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/libavutil/mem.c b/libavutil/mem.c
>>> index 88fe09b179..e044374c62 100644
>>> --- a/libavutil/mem.c
>>> +++ b/libavutil/mem.c
>>> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
>>>
>>>  void *av_malloc_array(size_t nmemb, size_t size)
>>>  {
>>> -if (!size || nmemb >= INT_MAX / size)
>>> +size_t result;
>>> +if (av_size_mult(nmemb, size, &result) < 0)
>>>  return NULL;
>>> -return av_malloc(nmemb * size);
>>> +return av_malloc(result);
>>
>> If I'm reading this right, when size is 0, instead of NULL this will now
>> return av_malloc(0), which looks like it may end up being a pointer to a
>> 1 byte big buffer. Is that intended?
>>
>> The previous version you sent apparently considered that scenario.
>
> But it did not pass fate because the behaviour before the patch
> was not to return NULL for alloc(0).

 Before this patch it would return NULL when size was 0 and alloc(0) when
 nmemb was 0. Now it will return alloc(0) when either of the two
 arguments is 0.

 The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
 similar instead, if we want to keep the original behavior.
>>>
>>> How did the original behaviour make any sense?
>>
>> Not saying it made sense, i'm saying we changed that behavior when the
>> patch, at least based on the description, only tried to replace the
>> INT_MAX limit with max_alloc_size.
>>
>> If making size 0 return malloc(0) was intended, or ultimately preferred,
>> then I'll not oppose to it.
> 
> To me, the old behaviour (returning NULL for some argument being 0
> but not the other) made less sense than the new behaviour (not
> special-casing 0 for any argument).
> The fact that returning NULL broke fate surprised me but I failed
> to find the reason.

I'm fairly sure your first patch failed because it made one of these
functions return NULL for an nmemb == 0 case in some test, when it was
not expected to.

Also, if you look at the doxy for these functions, they mention how they
should behave depending on if size or nmemb are 0. Most of these don't
seem to be honoring their documentation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubsc

Re: [FFmpeg-devel] [PATCH]lavu/mem: Make alloc array functions more similar to av_malloc

[Carl Eugen Hoyos]

Am Mo., 13. Apr. 2020 um 00:17 Uhr schrieb Andreas Rheinhardt
:
>
> Carl Eugen Hoyos:
> > Am So., 12. Apr. 2020 um 23:58 Uhr schrieb James Almer :
> >>
> >> On 4/12/2020 6:53 PM, Carl Eugen Hoyos wrote:
> >>> Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer 
> >>> :
> 
>  On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer 
> > :
> >>
> >> On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> >>> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> >>> :
> 
>  Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
>  :
> >
> > On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch makes the alloc array functions more similar to
> >> av_malloc, depending on max_alloc_size instead of INT_MAX.
> >>
> >> Allows a work-around for ticket #7140
> >>
> >> Please comment, Carl Eugen
> >
> >>  mem.c |8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >> 507531ed6f0932834d005bc1dd7d18e762f158b2  
> >> 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
> >> From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 
> >> 2001
> >> From: Carl Eugen Hoyos 
> >> Date: Sat, 4 Apr 2020 00:37:03 +0200
> >> Subject: [PATCH] lavu/mem: Make alloc array functions more similar 
> >> to
> >>  av_malloc().
> >>
> >> Do not limit the array allocation functions to allocations of 
> >> INT_MAX,
> >> instead depend on max_alloc_size like av_malloc().
> >>
> >> Allows a workaround for ticket #7140.
> >> ---
> >>  libavutil/mem.c | 8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > av_size_mult() may be faster
> 
>  New patch attached.
> >>>
> >>> And an actually working variant.
> >>>
> >>> Please comment, Carl Eugen
> >>
> >>> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> >>> From: Carl Eugen Hoyos 
> >>> Date: Sun, 12 Apr 2020 00:36:30 +0200
> >>> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> >>> av_malloc().
> >>>
> >>> Do not limit the array allocation functions and av_calloc() to 
> >>> allocations
> >>> of INT_MAX, instead depend on max_alloc_size like av_malloc().
> >>>
> >>> Allows a workaround for ticket #7140.
> >>> ---
> >>>  libavutil/mem.c | 20 
> >>>  1 file changed, 12 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/libavutil/mem.c b/libavutil/mem.c
> >>> index 88fe09b179..e044374c62 100644
> >>> --- a/libavutil/mem.c
> >>> +++ b/libavutil/mem.c
> >>> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
> >>>
> >>>  void *av_malloc_array(size_t nmemb, size_t size)
> >>>  {
> >>> -if (!size || nmemb >= INT_MAX / size)
> >>> +size_t result;
> >>> +if (av_size_mult(nmemb, size, &result) < 0)
> >>>  return NULL;
> >>> -return av_malloc(nmemb * size);
> >>> +return av_malloc(result);
> >>
> >> If I'm reading this right, when size is 0, instead of NULL this will 
> >> now
> >> return av_malloc(0), which looks like it may end up being a pointer to 
> >> a
> >> 1 byte big buffer. Is that intended?
> >>
> >> The previous version you sent apparently considered that scenario.
> >
> > But it did not pass fate because the behaviour before the patch
> > was not to return NULL for alloc(0).
> 
>  Before this patch it would return NULL when size was 0 and alloc(0) when
>  nmemb was 0. Now it will return alloc(0) when either of the two
>  arguments is 0.
> 
>  The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
>  similar instead, if we want to keep the original behavior.
> >>>
> >>> How did the original behaviour make any sense?
> >>
> >> Not saying it made sense, i'm saying we changed that behavior when the
> >> patch, at least based on the description, only tried to replace the
> >> INT_MAX limit with max_alloc_size.
> >>
> >> If making size 0 return malloc(0) was intended, or ultimately preferred,
> >> then I'll not oppose to it.
> >
> > To me, the old behaviour (returning NULL for some argument being 0
> > but not the other) made less sense than the new behaviour (not
> > special-casing 0 for any argument).
> > The fact that returning NULL broke fate surprised me but I failed
> > to find the reason.
> >
> Which tests failed?

Many (I am not saying that it isn't a single point of failure, but I
didn't find it).

Carl Eugen
___
ffmpeg-devel mailing 

Re: [FFmpeg-devel] [PATCH]lavu/mem: Make alloc array functions more similar to av_malloc

[Andreas Rheinhardt]

Carl Eugen Hoyos:
> Am So., 12. Apr. 2020 um 23:58 Uhr schrieb James Almer :
>>
>> On 4/12/2020 6:53 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer :

 On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer 
> :
>>
>> On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>>> :

 Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
 :
>
> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch makes the alloc array functions more similar to
>> av_malloc, depending on max_alloc_size instead of INT_MAX.
>>
>> Allows a work-around for ticket #7140
>>
>> Please comment, Carl Eugen
>
>>  mem.c |8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 507531ed6f0932834d005bc1dd7d18e762f158b2  
>> 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
>> From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 
>> 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 4 Apr 2020 00:37:03 +0200
>> Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
>>  av_malloc().
>>
>> Do not limit the array allocation functions to allocations of 
>> INT_MAX,
>> instead depend on max_alloc_size like av_malloc().
>>
>> Allows a workaround for ticket #7140.
>> ---
>>  libavutil/mem.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> av_size_mult() may be faster

 New patch attached.
>>>
>>> And an actually working variant.
>>>
>>> Please comment, Carl Eugen
>>
>>> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos 
>>> Date: Sun, 12 Apr 2020 00:36:30 +0200
>>> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
>>> av_malloc().
>>>
>>> Do not limit the array allocation functions and av_calloc() to 
>>> allocations
>>> of INT_MAX, instead depend on max_alloc_size like av_malloc().
>>>
>>> Allows a workaround for ticket #7140.
>>> ---
>>>  libavutil/mem.c | 20 
>>>  1 file changed, 12 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/libavutil/mem.c b/libavutil/mem.c
>>> index 88fe09b179..e044374c62 100644
>>> --- a/libavutil/mem.c
>>> +++ b/libavutil/mem.c
>>> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
>>>
>>>  void *av_malloc_array(size_t nmemb, size_t size)
>>>  {
>>> -if (!size || nmemb >= INT_MAX / size)
>>> +size_t result;
>>> +if (av_size_mult(nmemb, size, &result) < 0)
>>>  return NULL;
>>> -return av_malloc(nmemb * size);
>>> +return av_malloc(result);
>>
>> If I'm reading this right, when size is 0, instead of NULL this will now
>> return av_malloc(0), which looks like it may end up being a pointer to a
>> 1 byte big buffer. Is that intended?
>>
>> The previous version you sent apparently considered that scenario.
>
> But it did not pass fate because the behaviour before the patch
> was not to return NULL for alloc(0).

 Before this patch it would return NULL when size was 0 and alloc(0) when
 nmemb was 0. Now it will return alloc(0) when either of the two
 arguments is 0.

 The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
 similar instead, if we want to keep the original behavior.
>>>
>>> How did the original behaviour make any sense?
>>
>> Not saying it made sense, i'm saying we changed that behavior when the
>> patch, at least based on the description, only tried to replace the
>> INT_MAX limit with max_alloc_size.
>>
>> If making size 0 return malloc(0) was intended, or ultimately preferred,
>> then I'll not oppose to it.
> 
> To me, the old behaviour (returning NULL for some argument being 0
> but not the other) made less sense than the new behaviour (not
> special-casing 0 for any argument).
> The fact that returning NULL broke fate surprised me but I failed
> to find the reason.
> 
Which tests failed?

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

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

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mpegtsenc: use the correct stream_types and write HDMV descriptors for m2ts

[Carl Eugen Hoyos]

Am Fr., 10. Apr. 2020 um 21:45 Uhr schrieb Marton Balint :
>
> Fixes ticket #2622.
>
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mpegtsenc.c | 58 
> -
>  1 file changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index add35aca89..b154675d60 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -359,6 +359,54 @@ static int get_dvb_stream_type(AVFormatContext *s, 
> AVStream *st)
>  return stream_type;
>  }
>
> +static int get_m2ts_stream_type(AVFormatContext *s, AVStream *st)
> +{
> +int stream_type;
> +
> +switch (st->codecpar->codec_id) {
> +case AV_CODEC_ID_MPEG2VIDEO:
> +stream_type = STREAM_TYPE_VIDEO_MPEG2;
> +break;
> +case AV_CODEC_ID_H264:
> +stream_type = STREAM_TYPE_VIDEO_H264;
> +break;
> +case AV_CODEC_ID_VC1:
> +stream_type = STREAM_TYPE_VIDEO_VC1;
> +break;
> +case AV_CODEC_ID_HEVC:
> +stream_type = STREAM_TYPE_VIDEO_HEVC;
> +break;
> +case AV_CODEC_ID_PCM_BLURAY:
> +stream_type = 0x80;
> +break;
> +case AV_CODEC_ID_AC3:
> +stream_type = 0x81;
> +break;
> +case AV_CODEC_ID_DTS:
> +stream_type = (st->codecpar->channels > 6) ? 0x85 : 0x82;
> +break;
> +case AV_CODEC_ID_TRUEHD:
> +stream_type = 0x83;
> +break;
> +case AV_CODEC_ID_EAC3:
> +stream_type = 0x84;
> +break;
> +case AV_CODEC_ID_HDMV_PGS_SUBTITLE:
> +stream_type = 0x90;
> +break;
> +case AV_CODEC_ID_HDMV_TEXT_SUBTITLE:
> +stream_type = 0x92;
> +break;

I believe this is worth a line in the Changelog.

Carl Eugen
___
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/mips: fix compilation with MIPS16

[Rosen Penev]

On Sun, Apr 12, 2020 at 7:40 AM Michael Niedermayer
 wrote:
>
> On Sat, Apr 11, 2020 at 06:54:32PM -0700, Rosen Penev wrote:
> > get_cabac_inline for mips uses inline asm that relies on mips32
> > instructions.
> >
> > Signed-off-by: Rosen Penev 
> > ---
> >  libavcodec/mips/cabac.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/mips/cabac.h b/libavcodec/mips/cabac.h
> > index 2a05e5ab3c..cc40dbba15 100644
> > --- a/libavcodec/mips/cabac.h
> > +++ b/libavcodec/mips/cabac.h
> > @@ -28,6 +28,7 @@
> >  #include "libavutil/mips/mmiutils.h"
> >  #include "config.h"
> >
>
> > +#ifndef __mips16
>
> this should probably be something set by configure
> something like HAVE_MIPS* i suspect
config.h does not have a HAVE_MIPS16 macro defined anywhere.
>
> 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
>
> ___
> 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]lavu/mem: Make alloc array functions more similar to av_malloc

[Carl Eugen Hoyos]

Am So., 12. Apr. 2020 um 23:58 Uhr schrieb James Almer :
>
> On 4/12/2020 6:53 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer :
> >>
> >> On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
> >>> Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer 
> >>> :
> 
>  On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> > :
> >>
> >> Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
> >> :
> >>>
> >>> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
>  Hi!
> 
>  Attached patch makes the alloc array functions more similar to
>  av_malloc, depending on max_alloc_size instead of INT_MAX.
> 
>  Allows a work-around for ticket #7140
> 
>  Please comment, Carl Eugen
> >>>
>   mem.c |8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
>  507531ed6f0932834d005bc1dd7d18e762f158b2  
>  0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
>  From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 
>  2001
>  From: Carl Eugen Hoyos 
>  Date: Sat, 4 Apr 2020 00:37:03 +0200
>  Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
>   av_malloc().
> 
>  Do not limit the array allocation functions to allocations of 
>  INT_MAX,
>  instead depend on max_alloc_size like av_malloc().
> 
>  Allows a workaround for ticket #7140.
>  ---
>   libavutil/mem.c | 8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> av_size_mult() may be faster
> >>
> >> New patch attached.
> >
> > And an actually working variant.
> >
> > Please comment, Carl Eugen
> 
> > From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos 
> > Date: Sun, 12 Apr 2020 00:36:30 +0200
> > Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> > av_malloc().
> >
> > Do not limit the array allocation functions and av_calloc() to 
> > allocations
> > of INT_MAX, instead depend on max_alloc_size like av_malloc().
> >
> > Allows a workaround for ticket #7140.
> > ---
> >  libavutil/mem.c | 20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavutil/mem.c b/libavutil/mem.c
> > index 88fe09b179..e044374c62 100644
> > --- a/libavutil/mem.c
> > +++ b/libavutil/mem.c
> > @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
> >
> >  void *av_malloc_array(size_t nmemb, size_t size)
> >  {
> > -if (!size || nmemb >= INT_MAX / size)
> > +size_t result;
> > +if (av_size_mult(nmemb, size, &result) < 0)
> >  return NULL;
> > -return av_malloc(nmemb * size);
> > +return av_malloc(result);
> 
>  If I'm reading this right, when size is 0, instead of NULL this will now
>  return av_malloc(0), which looks like it may end up being a pointer to a
>  1 byte big buffer. Is that intended?
> 
>  The previous version you sent apparently considered that scenario.
> >>>
> >>> But it did not pass fate because the behaviour before the patch
> >>> was not to return NULL for alloc(0).
> >>
> >> Before this patch it would return NULL when size was 0 and alloc(0) when
> >> nmemb was 0. Now it will return alloc(0) when either of the two
> >> arguments is 0.
> >>
> >> The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
> >> similar instead, if we want to keep the original behavior.
> >
> > How did the original behaviour make any sense?
>
> Not saying it made sense, i'm saying we changed that behavior when the
> patch, at least based on the description, only tried to replace the
> INT_MAX limit with max_alloc_size.
>
> If making size 0 return malloc(0) was intended, or ultimately preferred,
> then I'll not oppose to it.

To me, the old behaviour (returning NULL for some argument being 0
but not the other) made less sense than the new behaviour (not
special-casing 0 for any argument).
The fact that returning NULL broke fate surprised me but I failed
to find the reason.

Carl Eugen
___
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]lavu/mem: Make alloc array functions more similar to av_malloc

[James Almer]

On 4/12/2020 6:53 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer :
>>
>> On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer :

 On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> :
>>
>> Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
>> :
>>>
>>> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
 Hi!

 Attached patch makes the alloc array functions more similar to
 av_malloc, depending on max_alloc_size instead of INT_MAX.

 Allows a work-around for ticket #7140

 Please comment, Carl Eugen
>>>
  mem.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 507531ed6f0932834d005bc1dd7d18e762f158b2  
 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
 From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 2001
 From: Carl Eugen Hoyos 
 Date: Sat, 4 Apr 2020 00:37:03 +0200
 Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
  av_malloc().

 Do not limit the array allocation functions to allocations of INT_MAX,
 instead depend on max_alloc_size like av_malloc().

 Allows a workaround for ticket #7140.
 ---
  libavutil/mem.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> av_size_mult() may be faster
>>
>> New patch attached.
>
> And an actually working variant.
>
> Please comment, Carl Eugen

> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 12 Apr 2020 00:36:30 +0200
> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> av_malloc().
>
> Do not limit the array allocation functions and av_calloc() to allocations
> of INT_MAX, instead depend on max_alloc_size like av_malloc().
>
> Allows a workaround for ticket #7140.
> ---
>  libavutil/mem.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 88fe09b179..e044374c62 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
>
>  void *av_malloc_array(size_t nmemb, size_t size)
>  {
> -if (!size || nmemb >= INT_MAX / size)
> +size_t result;
> +if (av_size_mult(nmemb, size, &result) < 0)
>  return NULL;
> -return av_malloc(nmemb * size);
> +return av_malloc(result);

 If I'm reading this right, when size is 0, instead of NULL this will now
 return av_malloc(0), which looks like it may end up being a pointer to a
 1 byte big buffer. Is that intended?

 The previous version you sent apparently considered that scenario.
>>>
>>> But it did not pass fate because the behaviour before the patch
>>> was not to return NULL for alloc(0).
>>
>> Before this patch it would return NULL when size was 0 and alloc(0) when
>> nmemb was 0. Now it will return alloc(0) when either of the two
>> arguments is 0.
>>
>> The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
>> similar instead, if we want to keep the original behavior.
> 
> How did the original behaviour make any sense?

Not saying it made sense, i'm saying we changed that behavior when the
patch, at least based on the description, only tried to replace the
INT_MAX limit with max_alloc_size.

If making size 0 return malloc(0) was intended, or ultimately preferred,
then I'll not oppose to it.
___
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]lavu/mem: Make alloc array functions more similar to av_malloc

[Carl Eugen Hoyos]

Am So., 12. Apr. 2020 um 23:52 Uhr schrieb James Almer :
>
> On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer :
> >>
> >> On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> >>> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> >>> :
> 
>  Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
>  :
> >
> > On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch makes the alloc array functions more similar to
> >> av_malloc, depending on max_alloc_size instead of INT_MAX.
> >>
> >> Allows a work-around for ticket #7140
> >>
> >> Please comment, Carl Eugen
> >
> >>  mem.c |8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >> 507531ed6f0932834d005bc1dd7d18e762f158b2  
> >> 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
> >> From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos 
> >> Date: Sat, 4 Apr 2020 00:37:03 +0200
> >> Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
> >>  av_malloc().
> >>
> >> Do not limit the array allocation functions to allocations of INT_MAX,
> >> instead depend on max_alloc_size like av_malloc().
> >>
> >> Allows a workaround for ticket #7140.
> >> ---
> >>  libavutil/mem.c | 8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > av_size_mult() may be faster
> 
>  New patch attached.
> >>>
> >>> And an actually working variant.
> >>>
> >>> Please comment, Carl Eugen
> >>
> >>> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> >>> From: Carl Eugen Hoyos 
> >>> Date: Sun, 12 Apr 2020 00:36:30 +0200
> >>> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> >>> av_malloc().
> >>>
> >>> Do not limit the array allocation functions and av_calloc() to allocations
> >>> of INT_MAX, instead depend on max_alloc_size like av_malloc().
> >>>
> >>> Allows a workaround for ticket #7140.
> >>> ---
> >>>  libavutil/mem.c | 20 
> >>>  1 file changed, 12 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/libavutil/mem.c b/libavutil/mem.c
> >>> index 88fe09b179..e044374c62 100644
> >>> --- a/libavutil/mem.c
> >>> +++ b/libavutil/mem.c
> >>> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
> >>>
> >>>  void *av_malloc_array(size_t nmemb, size_t size)
> >>>  {
> >>> -if (!size || nmemb >= INT_MAX / size)
> >>> +size_t result;
> >>> +if (av_size_mult(nmemb, size, &result) < 0)
> >>>  return NULL;
> >>> -return av_malloc(nmemb * size);
> >>> +return av_malloc(result);
> >>
> >> If I'm reading this right, when size is 0, instead of NULL this will now
> >> return av_malloc(0), which looks like it may end up being a pointer to a
> >> 1 byte big buffer. Is that intended?
> >>
> >> The previous version you sent apparently considered that scenario.
> >
> > But it did not pass fate because the behaviour before the patch
> > was not to return NULL for alloc(0).
>
> Before this patch it would return NULL when size was 0 and alloc(0) when
> nmemb was 0. Now it will return alloc(0) when either of the two
> arguments is 0.
>
> The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
> similar instead, if we want to keep the original behavior.

How did the original behaviour make any sense?

Carl Eugen
___
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]lavu/mem: Make alloc array functions more similar to av_malloc

[James Almer]

On 4/12/2020 5:55 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer :
>>
>> On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
>>> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>>> :

 Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
 :
>
> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch makes the alloc array functions more similar to
>> av_malloc, depending on max_alloc_size instead of INT_MAX.
>>
>> Allows a work-around for ticket #7140
>>
>> Please comment, Carl Eugen
>
>>  mem.c |8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 507531ed6f0932834d005bc1dd7d18e762f158b2  
>> 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
>> From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 4 Apr 2020 00:37:03 +0200
>> Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
>>  av_malloc().
>>
>> Do not limit the array allocation functions to allocations of INT_MAX,
>> instead depend on max_alloc_size like av_malloc().
>>
>> Allows a workaround for ticket #7140.
>> ---
>>  libavutil/mem.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> av_size_mult() may be faster

 New patch attached.
>>>
>>> And an actually working variant.
>>>
>>> Please comment, Carl Eugen
>>
>>> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos 
>>> Date: Sun, 12 Apr 2020 00:36:30 +0200
>>> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
>>> av_malloc().
>>>
>>> Do not limit the array allocation functions and av_calloc() to allocations
>>> of INT_MAX, instead depend on max_alloc_size like av_malloc().
>>>
>>> Allows a workaround for ticket #7140.
>>> ---
>>>  libavutil/mem.c | 20 
>>>  1 file changed, 12 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/libavutil/mem.c b/libavutil/mem.c
>>> index 88fe09b179..e044374c62 100644
>>> --- a/libavutil/mem.c
>>> +++ b/libavutil/mem.c
>>> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
>>>
>>>  void *av_malloc_array(size_t nmemb, size_t size)
>>>  {
>>> -if (!size || nmemb >= INT_MAX / size)
>>> +size_t result;
>>> +if (av_size_mult(nmemb, size, &result) < 0)
>>>  return NULL;
>>> -return av_malloc(nmemb * size);
>>> +return av_malloc(result);
>>
>> If I'm reading this right, when size is 0, instead of NULL this will now
>> return av_malloc(0), which looks like it may end up being a pointer to a
>> 1 byte big buffer. Is that intended?
>>
>> The previous version you sent apparently considered that scenario.
> 
> But it did not pass fate because the behaviour before the patch
> was not to return NULL for alloc(0).

Before this patch it would return NULL when size was 0 and alloc(0) when
nmemb was 0. Now it will return alloc(0) when either of the two
arguments is 0.

The check should be (!size || av_size_mult(nmemb, size, &result) < 0) or
similar instead, if we want to keep the original behavior.
___
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/cbs: Avoid leaving the ... out in calls to variadic macros

[Andreas Rheinhardt]

Mark Thompson:
> On 23/03/2020 00:52, Andreas Rheinhardt wrote:
>> According to C99, there has to be at least one argument for every ...
>> in a variadic function-like macro. In practice most (all?) compilers also
>> allow to leave it completely out, but it is nevertheless required: In a
>> variadic macro "there shall be more arguments in the invocation than there
>> are parameters in the macro definition (excluding the ...)." (C99,
>> 6.10.3.4).
>>
>> CBS (not the framework itself, but the macros used in the
>> cbs_*_syntax_template.c files) relies on the compiler allowing to leave
>> a variadic macro argument out. This leads to warnings when compiling in
>> -pedantic mode, e.g. "warning: must specify at least one argument for
>> '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]"
>> from Clang.
>>
>> Most of these warnings can be easily avoided: The syntax_templates
>> mostly contain helper macros that expand to more complex variadic macros
>> and these helper macros often omit an argument for the  Modifying
>> them to always expand to complex macros with an empty argument for the
>> ... at the end fixes most of these warnings: The number of warnings went
>> down from 400 to 0 for cbs_av1, from 1114 to 32 for cbs_h2645, from 38 to
>> 0 for cbs_jpeg, from 166 to 0 for cbs_mpeg2 and from 110 to 8 for cbs_vp9.
>>
>> These eight remaining warnings for cbs_vp9 have been fixed by switching
>> to another macro in cbs_vp9_syntax_template: The fixed values for the
>> sync bytes as well as the trailing bits for byte-alignment are now read
>> via the fixed() macro (this also adds a check to ensure that trailing
>> bits are indeed zero as they have to be).
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> There are two ways to fix the remaining 32 warnings from cbs_h2645:
>>
>> Simply add ", " to all macro calls that make use of the complex macros;
>> this has the drawback of adding uglyness to cbs_h26x_syntax_template.c.
>>
>> Or add new macros for these macro calls: The places that produce
>> warnings use the complex macros directly, because they use names
>> different from the default names that the helper macros use, but they do
>> not use subscripts and therefore leave the variadic argument (designed
>> for subscripts) out. I would have implemented the second solution if it
>> were not for the problem of the naming of the new macros.
>>
>> (There is of course also the possibility not to care about the remaining
>> ones.)
>>
>>  libavcodec/cbs_av1.c | 16 
>>  libavcodec/cbs_h2645.c   | 14 +++---
>>  libavcodec/cbs_jpeg.c|  2 +-
>>  libavcodec/cbs_mpeg2.c   |  6 +++---
>>  libavcodec/cbs_vp9.c | 13 ++---
>>  libavcodec/cbs_vp9_syntax_template.c | 21 -
>>  6 files changed, 29 insertions(+), 43 deletions(-)
> 
> Looks fine to me, keeping the ugliness in the macros rather than the 
> templates is good.
> 
> Is there any compiler which actually fails here, or is the only case which 
> finds it the warning in clang pedantic mode?
> 
> Thanks,
> 
> - Mark

Applied, thanks.

- Andreas
___
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]lavfi/telecine: Mark telecined frames as interlaced

[Kieran Kunhya]

On Sun, 12 Apr 2020 at 14:41, Carl Eugen Hoyos  wrote:

> Am So., 12. Apr. 2020 um 15:16 Uhr schrieb Paul B Mahol  >:
> >
> > On 4/12/20, Carl Eugen Hoyos  wrote:
> > > Am So., 12. Apr. 2020 um 15:00 Uhr schrieb Paul B Mahol <
> one...@gmail.com>:
> > >>
> > >> On 4/12/20, Carl Eugen Hoyos  wrote:
> > >> > Am So., 12. Apr. 2020 um 11:35 Uhr schrieb Paul B Mahol
> > >> > :
> > >> >>
> > >> >> On 4/12/20, Carl Eugen Hoyos  wrote:
> > >> >> > Am So., 12. Apr. 2020 um 10:38 Uhr schrieb Paul B Mahol
> > >> >> > :
> > >> >> >>
> > >> >> >> On 4/11/20, Paul B Mahol  wrote:
> > >> >> >> > On 4/11/20, Carl Eugen Hoyos  wrote:
> > >> >> >> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
> > >> >> >> >> :
> > >> >> >> >>>
> > >> >> >> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
> > >> >> >> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
> > >> >> >> >>> > :
> > >> >> >> >>> >>
> > >> >> >> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen
> Hoyos
> > >> >> >> >>> >> :
> > >> >> >> >>> >> >
> > >> >> >> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen
> Hoyos
> > >> >> >> >>> >> > :
> > >> >> >> >>> >> > >
> > >> >> >> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
> > >> >> >> >>> >> > > :
> > >> >> >> >>> >> > > >
> > >> >> >> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> > >> >> >> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl
> Eugen
> > >> >> >> >>> >> > > > > Hoyos
> > >> >> >> >>> >> > > > > :
> > >> >> >> >>> >> > > > >
> > >> >> >> >>> >> > > > >> Attached patch marks actually telecined frames
> as
> > >> >> >> >>> >> > > > >> interlaced,
> > >> >> >> >>> >> > > > >> other frames as progressive.
> > >> >> >> >>> >> > > > >
> > >> >> >> >>> >> > > > > New patch with changes to fate attached.
> > >> >> >> >>> >> > > > >
> > >> >> >> >>> >> > > > > Please comment, Carl Eugen
> > >> >> >> >>> >> > > >
> > >> >> >> >>> >> > > > Those yadif tests look wrong. The patch shouldn't
> > >> >> >> >>> >> > > > affect
> > >> >> >> >>> >> > > > them.
> > >> >> >> >>> >> > >
> > >> >> >> >>> >> > > Clearly, thank you!
> > >> >> >> >>> >> > >
> > >> >> >> >>> >> > > New patch attached, it should now only change the
> > >> >> >> >>> >> > > telecined
> > >> >> >> >>> >> > > frames and leave the other frames as they are, the
> > >> >> >> >>> >> > > setfield
> > >> >> >> >>> >> > > filter can be used to force a progressive setting for
> > >> >> >> >>> >> > > them.
> > >> >> >> >>> >> >
> > >> >> >> >>> >> > New patch attached that also sets top_field_first
> > >> >> >> >>> >>
> > >> >> >> >>> >> Which had the effect that fate is correct again, new
> patch
> > >> >> >> >>> >> attached.
> > >> >> >> >>> >
> > >> >> >> >>> > Patch applied.
> > >> >> >> >>> >
> > >> >> >> >>>
> > >> >> >> >>> This was never approved by me.
> > >> >> >> >>
> > >> >> >> >> You reviewed it on irc and correctly pointed out the missing
> > >> >> >> >> bits.
> > >> >> >> >
> > >> >> >> > Lies, I was against that idea from start.
> > >> >> >> >
> > >> >> >> >>
> > >> >> >> >>> So revert it ASAP!
> > >> >> >> >>
> > >> >> >> >> What should be changed about it?
> > >> >> >> >
> > >> >> >> > Return of code as it was before this pointless change.
> > >> >> >> > I see no good out of it.
> > >> >> >>
> > >> >> >> I gonna revert this ASAP!
> > >> >> >
> > >> >> > Could you explain why it is wrong to mark interlaced frames
> > >> >> > as interlaced?
> > >> >>
> > >> >> The frames are not interlaced.
> > >> >
> > >> > Using the usual 3:2 telecine, the filter outputs two progressive
> > >> > frames, followed by three interlaced frames, the patch should
> > >> > mark the interlaced frames as interlaced and I believe it does.
> > >>
> > >> You are very ignorant or very stupid or both.
> > >
> > > Apparently yes because ...
> > >
> > >> Interlaced frames are frames produced by interlacing.
> > >> Telecine is not interlacing.
> > >
> > > ... to the best of my knowledge, the telecine process outputs
> > > interlaced (and non-interlaced) frames, so I do not understand
> > > your argumentation, please elaborate.
> >
> > Interlacing usually destroys half of data, telecine never does that.
>
> There are cameras that output interlaced content, they do not
> destroy any data (the "missing" data never existed).
>
> I don't think your definition is ideal, a more useful definition is that
> the fields of one frame originate from different points in time.
>
> > Claiming frames are interlaced will just confuse confused users more.
>
> I was more thinking of encoders, they will be less confused with the
> patch.
>
> > >> >> I thought you knew that interlacing destroys half of data.
> > >> >> Telecine does not destroys data.
> > >> >
> > >> > Telecine duplicates some data, leading to interlaced frames.
> > >> > A (perfect) detecine process can remove the duplicated data
> > >> > (and the interlaced frames).
>

You both seem to misunderstand, confusing the structure of the frame with
the tr

Re: [FFmpeg-devel] [PATCH]lavu/mem: Make alloc array functions more similar to av_malloc

[Carl Eugen Hoyos]

Am So., 12. Apr. 2020 um 22:48 Uhr schrieb James Almer :
>
> On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> > :
> >>
> >> Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
> >> :
> >>>
> >>> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
>  Hi!
> 
>  Attached patch makes the alloc array functions more similar to
>  av_malloc, depending on max_alloc_size instead of INT_MAX.
> 
>  Allows a work-around for ticket #7140
> 
>  Please comment, Carl Eugen
> >>>
>   mem.c |8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
>  507531ed6f0932834d005bc1dd7d18e762f158b2  
>  0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
>  From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 2001
>  From: Carl Eugen Hoyos 
>  Date: Sat, 4 Apr 2020 00:37:03 +0200
>  Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
>   av_malloc().
> 
>  Do not limit the array allocation functions to allocations of INT_MAX,
>  instead depend on max_alloc_size like av_malloc().
> 
>  Allows a workaround for ticket #7140.
>  ---
>   libavutil/mem.c | 8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> av_size_mult() may be faster
> >>
> >> New patch attached.
> >
> > And an actually working variant.
> >
> > Please comment, Carl Eugen
>
> > From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos 
> > Date: Sun, 12 Apr 2020 00:36:30 +0200
> > Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> > av_malloc().
> >
> > Do not limit the array allocation functions and av_calloc() to allocations
> > of INT_MAX, instead depend on max_alloc_size like av_malloc().
> >
> > Allows a workaround for ticket #7140.
> > ---
> >  libavutil/mem.c | 20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavutil/mem.c b/libavutil/mem.c
> > index 88fe09b179..e044374c62 100644
> > --- a/libavutil/mem.c
> > +++ b/libavutil/mem.c
> > @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
> >
> >  void *av_malloc_array(size_t nmemb, size_t size)
> >  {
> > -if (!size || nmemb >= INT_MAX / size)
> > +size_t result;
> > +if (av_size_mult(nmemb, size, &result) < 0)
> >  return NULL;
> > -return av_malloc(nmemb * size);
> > +return av_malloc(result);
>
> If I'm reading this right, when size is 0, instead of NULL this will now
> return av_malloc(0), which looks like it may end up being a pointer to a
> 1 byte big buffer. Is that intended?
>
> The previous version you sent apparently considered that scenario.

But it did not pass fate because the behaviour before the patch
was not to return NULL for alloc(0).

Carl Eugen
___
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] Stereo 3D frame packing or HDMI checkerboard input (capture from screen)

[fireYtail3DYTnow livestreamer]

I want to live stream from my computer which has those two 3D formats, to
SBS format. The stereo3d filter only allows frame packing and checkerboard
as output, not input, and not sure if there is any way to capture frame
packing video in the first place. Nvidia 3D vision shuts down if it detects
screen capture and goes back to 2D mode, and if it doesn't detect it
capture hasn't worked for me so far (black screen or 2D video depending on
method used)

On Sunday, 12 April 2020, Vittorio Giovara 
wrote:

> On Sun, Apr 12, 2020 at 8:35 AM fireYtail3DYTnow livestreamer <
> permanentswi...@gmail.com> wrote:
>
> > Hello, good morning. I'm a Nvidia 3D vision user and due to having to use
> > outdated drivers and software after the discontinuation of the feature a
> > year ago I request that the feature to use Stereo 3D frame packing (from
> > screen) preferably, or alternatively HDMI checkerboard input for live
> > streaming via FFMPEG, with SBS as the output sorting. When will this
> > possibility be added, approximately? Right now it's only possible to do
> it
> > in reverse (take a SBS input from screen and convert it to either option)
> > I've spent many hours trying to find a way to do this but requesting this
> > is my last hope.
> >
>
> Hi,
> not sure I follow your request, are you asking how to display two frames in
> a single SBS one or to convert a frame packed video to SBS?
> For the first one there is the framepack filter, for the second there is
> the stereo3d filter. I don't think either support checkerboard however.
> Also this is the developer mailing list, you might have better luck on the
> user mailing list.
> --
> Vittorio
> ___
> 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]lavu/mem: Make alloc array functions more similar to av_malloc

[James Almer]

On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> :
>>
>> Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
>> :
>>>
>>> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
 Hi!

 Attached patch makes the alloc array functions more similar to
 av_malloc, depending on max_alloc_size instead of INT_MAX.

 Allows a work-around for ticket #7140

 Please comment, Carl Eugen
>>>
  mem.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 507531ed6f0932834d005bc1dd7d18e762f158b2  
 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
 From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 2001
 From: Carl Eugen Hoyos 
 Date: Sat, 4 Apr 2020 00:37:03 +0200
 Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
  av_malloc().

 Do not limit the array allocation functions to allocations of INT_MAX,
 instead depend on max_alloc_size like av_malloc().

 Allows a workaround for ticket #7140.
 ---
  libavutil/mem.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> av_size_mult() may be faster
>>
>> New patch attached.
> 
> And an actually working variant.
> 
> Please comment, Carl Eugen

> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 12 Apr 2020 00:36:30 +0200
> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> av_malloc().
> 
> Do not limit the array allocation functions and av_calloc() to allocations
> of INT_MAX, instead depend on max_alloc_size like av_malloc().
> 
> Allows a workaround for ticket #7140.
> ---
>  libavutil/mem.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 88fe09b179..e044374c62 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
>  
>  void *av_malloc_array(size_t nmemb, size_t size)
>  {
> -if (!size || nmemb >= INT_MAX / size)
> +size_t result;
> +if (av_size_mult(nmemb, size, &result) < 0)
>  return NULL;
> -return av_malloc(nmemb * size);
> +return av_malloc(result);

If I'm reading this right, when size is 0, instead of NULL this will now
return av_malloc(0), which looks like it may end up being a pointer to a
1 byte big buffer. Is that intended?

The previous version you sent apparently considered that scenario.

>  }
>  
>  void *av_mallocz_array(size_t nmemb, size_t size)
>  {
> -if (!size || nmemb >= INT_MAX / size)
> +size_t result;
> +if (av_size_mult(nmemb, size, &result) < 0)
>  return NULL;
> -return av_mallocz(nmemb * size);
> +return av_mallocz(result);
>  }
>  
>  void *av_realloc_array(void *ptr, size_t nmemb, size_t size)
>  {
> -if (!size || nmemb >= INT_MAX / size)
> +size_t result;
> +if (av_size_mult(nmemb, size, &result) < 0)
>  return NULL;
> -return av_realloc(ptr, nmemb * size);
> +return av_realloc(ptr, result);
>  }
>  
>  int av_reallocp_array(void *ptr, size_t nmemb, size_t size)
> @@ -243,9 +246,10 @@ void *av_mallocz(size_t size)
>  
>  void *av_calloc(size_t nmemb, size_t size)
>  {
> -if (size <= 0 || nmemb >= INT_MAX / size)
> +size_t result;
> +if (av_size_mult(nmemb, size, &result) < 0)
>  return NULL;
> -return av_mallocz(nmemb * size);
> +return av_mallocz(result);
>  }
>  
>  char *av_strdup(const char *s)
> -- 
> 2.24.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]lavf/gdv: Improve palette saturation

[Carl Eugen Hoyos]

Am Do., 7. Sept. 2017 um 15:40 Uhr schrieb Ronald S. Bultje
:
>
> Hi Carl,
>
> On Mon, Aug 28, 2017 at 10:49 AM, Carl Eugen Hoyos 
> wrote:
>
> > 2017-08-27 9:03 GMT+02:00 Paul B Mahol :
> > > On 8/26/17, Carl Eugen Hoyos  wrote:
> >
> > >> Attached patch slightly improves the saturation of the
> > >> gdv palette.
> > >>
> > >> Please comment, Carl Eugen
> > >
> > > Does this match how it is displayed by original game?
> >
> > The original game was written for a graphic adapter that
> > supports 6bit palette. FFmpeg only supports 8bit palette,
> >
>
> OK, so that matches the current code:
>
>  unsigned r = bytestream2_get_byte(gb);
>  unsigned g = bytestream2_get_byte(gb);
>  unsigned b = bytestream2_get_byte(gb);
>  gdv->pal[i] = 0xFFU << 24 | r << 18 | g << 10 | b << 2;
>
> This indeed suggests the byte only contains 6 lower bits, the upper 2 being
> 0. It also indeed suggests that "white" (11) would be converted to (in
> bits) 1100, not , which is indeed unsaturated.
>
>
> > the patch makes the colour white (and all saturated colours)
> > as similar to the intended output as possible and does not
> > change black (and other colours with little intensity).
>
>
> So let's say you have (in bits) 11 or 00 (white and black).
>
>  unsigned r = bytestream2_get_byte(gb);
>  unsigned g = bytestream2_get_byte(gb);
>  unsigned b = bytestream2_get_byte(gb);
> +r |= r >> 4;
> +g |= g >> 4;
> +b |= b >> 4;
>
> This converts that to 11 and 00.
>
>  gdv->pal[i] = 0xFFU << 24 | r << 18 | g << 10 | b << 2;
>
> And it seems to me that the color is then _still_ 1100, which is
> unsaturated. Don't you want to do something like:
>
> #define convert6to8(x) ((x << 2) | ((x + 8) >> 4))
>
>  unsigned r = bytestream2_get_byte(gb);
>  unsigned g = bytestream2_get_byte(gb);
>  unsigned b = bytestream2_get_byte(gb);
> +r = convert6to8(r);
> +g = convert6to8(g);
> +b = convert6to8(b);
>  gdv->pal[i] = (0xFFU << 24) | (r << 16) | (g << 8) | b;
>
> Or am I misunderstanding?

No, thank you for your review!

New patch attached.

Please comment, Carl Eugen
From 3e456735e8dd268947a92574296a80a8a1e40750 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 12 Apr 2020 22:46:08 +0200
Subject: [PATCH] lavf/gdv: Improve saturation of gdv palette.

---
 libavformat/gdv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/gdv.c b/libavformat/gdv.c
index 2ecbb535e7..2d50530b83 100644
--- a/libavformat/gdv.c
+++ b/libavformat/gdv.c
@@ -143,7 +143,7 @@ static int gdv_read_header(AVFormatContext *ctx)
 unsigned r = avio_r8(pb);
 unsigned g = avio_r8(pb);
 unsigned b = avio_r8(pb);
-gdv->pal[i] = 0xFFU << 24 | r << 18 | g << 10 | b << 2;
+gdv->pal[i] = 0xFFU << 24 | r << 18 | r >> 4 << 16 | g << 10 | g >> 4 << 8 | b << 2 | b >> 4;
 }
 }
 
-- 
2.24.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]lavu/mem: Make alloc array functions more similar to av_malloc

[Carl Eugen Hoyos]

Am So., 12. Apr. 2020 um 16:32 Uhr schrieb Michael Niedermayer
:
>
> On Sun, Apr 12, 2020 at 01:53:51AM +0200, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> > :
> > >
> > > Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
> > > :
> > > >
> > > > On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
> > > > > Hi!
> > > > >
> > > > > Attached patch makes the alloc array functions more similar to
> > > > > av_malloc, depending on max_alloc_size instead of INT_MAX.
> > > > >
> > > > > Allows a work-around for ticket #7140
> > > > >
> > > > > Please comment, Carl Eugen
> > > >
> > > > >  mem.c |8 
> > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > 507531ed6f0932834d005bc1dd7d18e762f158b2  
> > > > > 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
> > > > > From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 2001
> > > > > From: Carl Eugen Hoyos 
> > > > > Date: Sat, 4 Apr 2020 00:37:03 +0200
> > > > > Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
> > > > >  av_malloc().
> > > > >
> > > > > Do not limit the array allocation functions to allocations of INT_MAX,
> > > > > instead depend on max_alloc_size like av_malloc().
> > > > >
> > > > > Allows a workaround for ticket #7140.
> > > > > ---
> > > > >  libavutil/mem.c | 8 
> > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > >
> > > > av_size_mult() may be faster
> > >
> > > New patch attached.
> >
> > And an actually working variant.
> >
> > Please comment, Carl Eugen
>
> >  mem.c |   20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
> > 9be759276a25d6fa787286c3bce849486573266a  
> > 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
> > From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos 
> > Date: Sun, 12 Apr 2020 00:36:30 +0200
> > Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> > av_malloc().
> >
> > Do not limit the array allocation functions and av_calloc() to allocations
> > of INT_MAX, instead depend on max_alloc_size like av_malloc().
> >
> > Allows a workaround for ticket #7140.
> > ---
> >  libavutil/mem.c | 20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
>
> should be ok

Patch applied.

Thank you, Carl Eugen
___
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] Stereo 3D frame packing or HDMI checkerboard input (capture from screen)

[Vittorio Giovara]

On Sun, Apr 12, 2020 at 8:35 AM fireYtail3DYTnow livestreamer <
permanentswi...@gmail.com> wrote:

> Hello, good morning. I'm a Nvidia 3D vision user and due to having to use
> outdated drivers and software after the discontinuation of the feature a
> year ago I request that the feature to use Stereo 3D frame packing (from
> screen) preferably, or alternatively HDMI checkerboard input for live
> streaming via FFMPEG, with SBS as the output sorting. When will this
> possibility be added, approximately? Right now it's only possible to do it
> in reverse (take a SBS input from screen and convert it to either option)
> I've spent many hours trying to find a way to do this but requesting this
> is my last hope.
>

Hi,
not sure I follow your request, are you asking how to display two frames in
a single SBS one or to convert a frame packed video to SBS?
For the first one there is the framepack filter, for the second there is
the stereo3d filter. I don't think either support checkerboard however.
Also this is the developer mailing list, you might have better luck on the
user mailing list.
-- 
Vittorio
___
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/spdifenc: handle long TrueHD input_timing gaps

[Anssi Hannula]

Some TrueHD streams contain frames that have very long gaps in
input_timing fields, while output_timing remains constant-rate. These
are likely due to encoding discontinuities of some sort as the TrueHD
substream terminator marker is observed before the gap.

Such frames trigger a sanity check in the current code - however, such
gaps are valid.

The gaps require us to insert many IEC 61937 bursts worth of MAT padding
into the output. To facilitate that, add a mechanism in
spdif_write_packet() to allow writing out multiple bursts per AVPacket,
and use that in spdif_header_truehd() to write out any full bursts that
do not yet contain any actual audio data from the current AVPacket.

Modify the sanity check to allow up to 50 MAT frames full of padding.

Fixes: incredibles2-truehd-bitstreaming.thd
---

I'll apply this soon unless there are comments.


 libavformat/spdifenc.c | 48 --
 1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c
index 0288872fd3..7041ecf2c8 100644
--- a/libavformat/spdifenc.c
+++ b/libavformat/spdifenc.c
@@ -68,6 +68,7 @@ typedef struct IEC61937Context {
 
 int use_preamble;   ///< preamble enabled (disabled for 
exactly pre-padded DTS)
 int extra_bswap;///< extra bswap for payload (for LE DTS 
=> standard BE DTS)
+int more_bursts_needed; ///< more bursts needed for the same 
AVPacket
 
 uint8_t *hd_buf[2]; ///< allocated buffers to concatenate hd 
audio frames
 int hd_buf_size;///< size of the hd audio buffer (eac3, 
dts4)
@@ -80,6 +81,7 @@ typedef struct IEC61937Context {
 uint16_t truehd_prev_time;  ///< input_timing from the last frame
 int truehd_prev_size;   ///< previous frame size in bytes, 
including any MAT codes
 int truehd_samples_per_frame;   ///< samples per frame for padding 
calculation
+int truehd_padding_remaining;   ///< amount of padding still needed before 
data
 
 /* AVOptions: */
 int dtshd_rate;
@@ -450,7 +452,12 @@ static int spdif_header_truehd(AVFormatContext *s, 
AVPacket *pkt)
 return AVERROR_INVALIDDATA;
 
 input_timing = AV_RB16(pkt->data + 2);
-if (ctx->truehd_prev_size) {
+
+if (ctx->truehd_padding_remaining) {
+/* padding was calculated on previous call and some still remains */
+padding_remaining = ctx->truehd_padding_remaining;
+
+} else if (ctx->truehd_prev_size) {
 uint16_t delta_samples = input_timing - ctx->truehd_prev_time;
 /*
  * One multiple-of-48kHz frame is 1/1200 sec and the IEC 61937 rate
@@ -470,8 +477,8 @@ static int spdif_header_truehd(AVFormatContext *s, AVPacket 
*pkt)
delta_samples, delta_bytes);
 
 /* sanity check */
-if (padding_remaining < 0 || padding_remaining >= MAT_FRAME_SIZE / 2) {
-avpriv_request_sample(s, "Unusual frame timing: %"PRIu16" => 
%"PRIu16", %d samples/frame",
+if (padding_remaining < 0 || padding_remaining >= MAT_PKT_OFFSET * 50) 
{
+avpriv_request_sample(s, "Unusual frame timing (%"PRIu16" => 
%"PRIu16", %d samples/frame)",
   ctx->truehd_prev_time, input_timing, 
ctx->truehd_samples_per_frame);
 padding_remaining = 0;
 }
@@ -520,6 +527,15 @@ static int spdif_header_truehd(AVFormatContext *s, 
AVPacket *pkt)
 /* count the remainder of the code as part of frame size */
 if (code_len_remaining)
 total_frame_size += code_len_remaining;
+
+if (have_pkt && padding_remaining) {
+/*
+ * We already have a full burst but padding still remains,
+ * write out the current burst and ask us to be called again
+ * via ctx->more_bursts_needed to avoid filling our buffers.
+ */
+break;
+}
 }
 
 if (padding_remaining) {
@@ -547,9 +563,14 @@ static int spdif_header_truehd(AVFormatContext *s, 
AVPacket *pkt)
 
 ctx->truehd_prev_size = total_frame_size;
 ctx->truehd_prev_time = input_timing;
+ctx->truehd_padding_remaining = padding_remaining;
 
-av_log(s, AV_LOG_TRACE, "TrueHD frame inserted, total size %d, buffer 
position %d\n",
-   total_frame_size, ctx->hd_buf_filled);
+if (padding_remaining)
+av_log(s, AV_LOG_TRACE, "TrueHD frame not yet inserted, %d bytes more 
padding needed\n",
+   padding_remaining);
+else
+av_log(s, AV_LOG_TRACE, "TrueHD frame inserted, total size %d, buffer 
position %d\n",
+   total_frame_size, ctx->hd_buf_filled);
 
 if (!have_pkt) {
 ctx->pkt_offset = 0;
@@ -560,6 +581,8 @@ static int spdif_header_truehd(AVFormatContext *s, AVPacket 
*pkt)
 ctx->pkt_offset  = MAT_PKT_OFFSET;
 ctx->out_bytes   = MAT_FRAME_SIZE;
 ctx->length_code = MAT_FRAME_SIZE

Re: [FFmpeg-devel] [PATCH] vaapi_decode: Improve logging around codec/profile selection

[Fu, Linjie]

> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: Sunday, April 12, 2020 21:00
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] vaapi_decode: Improve logging around
> codec/profile selection
> 
> ---
> On 12/04/2020 13:14, Mark Thompson wrote:
> > ...  This does rather suggest that the error messages in that file should be
> clearer, though - it would be nice if it could distinguish between "this codec
> isn't supported by libavcodec at all", "this codec might work but hasn't built
> into this libavcodec" and "this codec is supported by libavcodec but not by
> your hardware".
> 
> Something like this?
> 
> 
>  libavcodec/vaapi_decode.c | 39 +++
> 
>  1 file changed, 31 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 54a0ecb47a..a191850e36 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -429,6 +429,7 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
>  const AVCodecDescriptor *codec_desc;
>  VAProfile *profile_list = NULL, matched_va_profile, va_profile;
>  int profile_count, exact_match, matched_ff_profile, codec_profile;
> +int found_codec, found_profile;
> 
>  AVHWDeviceContext*device = (AVHWDeviceContext*)device_ref-
> >data;
>  AVVAAPIDeviceContext *hwctx = device->hwctx;
> @@ -457,15 +458,19 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
>  }
> 
>  matched_va_profile = VAProfileNone;
> +found_codec = found_profile = 0;
>  exact_match = 0;
> 
>  for (i = 0; i < FF_ARRAY_ELEMS(vaapi_profile_map); i++) {
>  int profile_match = 0;
>  if (avctx->codec_id != vaapi_profile_map[i].codec_id)
>  continue;
> +found_codec = 1;
>  if (avctx->profile == vaapi_profile_map[i].codec_profile ||
> -vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
> +vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN) {
>  profile_match = 1;
> +found_profile = 1;
> +}
> 
>  va_profile = vaapi_profile_map[i].profile_parser ?
>   vaapi_profile_map[i].profile_parser(avctx) :
> @@ -487,24 +492,42 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
>  }
>  av_freep(&profile_list);
> 
> -if (matched_va_profile == VAProfileNone) {
> -av_log(avctx, AV_LOG_ERROR, "No support for codec %s "
> -   "profile %d.\n", codec_desc->name, avctx->profile);
> +if (!found_codec) {
> +av_log(avctx, AV_LOG_ERROR, "This libavcodec build does not "
> +   "support VAAPI decoding of codec %s.\n",
> +   codec_desc->name);
> +err = AVERROR(ENOSYS);
> +goto fail;
> +}
> +if (!found_profile && !(avctx->hwaccel_flags &
> +AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH)) {
> +// We allow this case with profile-mismatch enabled to support
> +// things like trying to decode H.264 extended profile.
> +av_log(avctx, AV_LOG_ERROR, "This libavcodec build does not "
> +   "support VAAPI decoding of codec %s profile %d.\n",
> +   codec_desc->name, avctx->profile);
>  err = AVERROR(ENOSYS);
>  goto fail;
>  }
> +if (matched_va_profile == VAProfileNone) {
> +av_log(avctx, AV_LOG_ERROR, "This VAAPI driver does not "
> +   "support decoding of codec %s.\n",
> +   codec_desc->name);
> +err = AVERROR(EINVAL);
> +goto fail;
> +}
>  if (!exact_match) {
>  if (avctx->hwaccel_flags &
>  AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH) {
> -av_log(avctx, AV_LOG_VERBOSE, "Codec %s profile %d not "
> -   "supported for hardware decode.\n",
> +av_log(avctx, AV_LOG_WARNING, "This VAAPI driver does not "
> +   "support decoding of codec %s profile %d.\n",
> codec_desc->name, avctx->profile);
>  av_log(avctx, AV_LOG_WARNING, "Using possibly-"
> "incompatible profile %d instead.\n",
> matched_ff_profile);
>  } else {
> -av_log(avctx, AV_LOG_VERBOSE, "Codec %s profile %d not "
> -   "supported for hardware decode.\n",
> +av_log(avctx, AV_LOG_ERROR, "This VAAPI driver does not "
> +   "support decoding of codec %s profile %d.\n",
> codec_desc->name, avctx->profile);
>  err = AVERROR(EINVAL);
>  goto fail;
> --
Generally makes sense, however there is one concern if I got it correctly:

If a codec is not supported by VAAPI in current libavcodec build, 
ff_get_format()
would not select VAAPI as the HW acceleration. 
Instead, it would fallback to the native software decoding path, and won't 
trigger
the (!found_codec) logic.

./configure --ena

Re: [FFmpeg-devel] [PATCH] avformat/Makefile: Add missing rawenc dependency for iLBC muxer

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Forgotten in ab502fab.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> Sorry for this mistake in ab502fab.
>>
>> 054ce5f786f0bff2491bda5497850d2390621176 is not a real fix, because
>> --disable-everything --enable-muxer=ilbc would still fail.
>>
>>  libavformat/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 8fd0d43721..9d4c230bcf 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -239,7 +239,7 @@ OBJS-$(CONFIG_IDF_DEMUXER)   += bintext.o 
>> sauce.o
>>  OBJS-$(CONFIG_IFF_DEMUXER)   += iff.o
>>  OBJS-$(CONFIG_IFV_DEMUXER)   += ifv.o
>>  OBJS-$(CONFIG_ILBC_DEMUXER)  += ilbc.o
>> -OBJS-$(CONFIG_ILBC_MUXER)+= ilbc.o
>> +OBJS-$(CONFIG_ILBC_MUXER)+= ilbc.o rawenc.o
>>  OBJS-$(CONFIG_IMAGE2_DEMUXER)+= img2dec.o img2.o
>>  OBJS-$(CONFIG_IMAGE2_MUXER)  += img2enc.o img2.o
>>  OBJS-$(CONFIG_IMAGE2PIPE_DEMUXER)+= img2dec.o img2.o
>>
> Ping. (Given that I created this mess, I am of course eager to fix it.)
> 
> - Andreas
> 
Will apply.

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

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

[FFmpeg-devel] [PATCH 2/2] avformat/flacenc: Don't allocate updated streaminfo separately

[Andreas Rheinhardt]

It is a small buffer of a known, fixed size and so it should simply be
put into the muxer's context.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/flacenc.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index 42c1efec54..a043274df6 100644
--- a/libavformat/flacenc.c
+++ b/libavformat/flacenc.c
@@ -42,7 +42,8 @@ typedef struct FlacMuxerContext {
 AVPacketList *queue, *queue_end;
 
 /* updated streaminfo sent by the encoder at the end */
-uint8_t *streaminfo;
+uint8_t streaminfo[FLAC_STREAMINFO_SIZE];
+int updated_streaminfo;
 
 unsigned attached_types;
 } FlacMuxerContext;
@@ -294,12 +295,8 @@ static int flac_write_audio_packet(struct AVFormatContext 
*s, AVPacket *pkt)
 streaminfo = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
  &streaminfo_size);
 if (streaminfo && streaminfo_size == FLAC_STREAMINFO_SIZE) {
-av_freep(&c->streaminfo);
-
-c->streaminfo = av_malloc(FLAC_STREAMINFO_SIZE);
-if (!c->streaminfo)
-return AVERROR(ENOMEM);
 memcpy(c->streaminfo, streaminfo, FLAC_STREAMINFO_SIZE);
+c->updated_streaminfo = 1;
 }
 
 if (pkt->size)
@@ -338,7 +335,7 @@ static int flac_write_trailer(struct AVFormatContext *s)
 flac_queue_flush(s);
 }
 
-if (!c->write_header || !c->streaminfo)
+if (!c->write_header || !c->updated_streaminfo)
 return 0;
 
 if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
@@ -359,7 +356,6 @@ static void flac_deinit(struct AVFormatContext *s)
 FlacMuxerContext *c = s->priv_data;
 
 ff_packet_list_free(&c->queue, &c->queue_end);
-av_freep(&c->streaminfo);
 }
 
 static int flac_write_packet(struct AVFormatContext *s, AVPacket *pkt)
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 1/2] avformat/flacenc: Only update streaminfo if it has changed

[Andreas Rheinhardt]

An AVStream's codecpar is supposed to be filled by the caller before
avformat_write_header(); if the CodecParameters change, the caller
should signal this via packet side data, but not touch the AVStream's
codecpar.

The FLAC muxer checks for packet side data containing updated extradata,
yet if nothing has arrived by the time the trailer is written, the
already written extradata is overwritten by the very same extradata
again, unless the output is unseekable, in which case a warning that the
FLAC header can't be rewritten is emitted.

This commit changes this by only trying to rewrite the extradata if a
new streaminfo arrived via packet side data. Only then is a warning
emitted in case the output is unseekable.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/flacenc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index 1aae0c97e0..42c1efec54 100644
--- a/libavformat/flacenc.c
+++ b/libavformat/flacenc.c
@@ -331,8 +331,6 @@ static int flac_write_trailer(struct AVFormatContext *s)
 AVIOContext *pb = s->pb;
 int64_t file_size;
 FlacMuxerContext *c = s->priv_data;
-uint8_t *streaminfo = c->streaminfo ? c->streaminfo :
-  
s->streams[c->audio_stream_idx]->codecpar->extradata;
 
 if (c->waiting_pics) {
 av_log(s, AV_LOG_WARNING, "No packets were sent for some of the "
@@ -340,14 +338,14 @@ static int flac_write_trailer(struct AVFormatContext *s)
 flac_queue_flush(s);
 }
 
-if (!c->write_header || !streaminfo)
+if (!c->write_header || !c->streaminfo)
 return 0;
 
 if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
 /* rewrite the STREAMINFO header block data */
 file_size = avio_tell(pb);
 avio_seek(pb, 8, SEEK_SET);
-avio_write(pb, streaminfo, FLAC_STREAMINFO_SIZE);
+avio_write(pb, c->streaminfo, FLAC_STREAMINFO_SIZE);
 avio_seek(pb, file_size, SEEK_SET);
 } else {
 av_log(s, AV_LOG_WARNING, "unable to rewrite FLAC header.\n");
-- 
2.20.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] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp

[Ross Nicholson]

User testing has been completed successfully so this is ready to be applied.

Thanks 

> On 7 Apr 2020, at 23:50, Ross Nicholson  wrote:
> 
> 
> Thank you for the explanation Marton. It's make perfect sense to me know. So 
> UNLIMITED would be the right choice here.
> 
> All of your other comments are addressed in the latest version. Thanks again 
> for reviewing.
> 
>> On Tue, 7 Apr 2020 at 22:03, Marton Balint  wrote:
>> 
>> 
>> On Tue, 7 Apr 2020, Ross Nicholson wrote:
>> 
>> > Great, thanks again. 
>> >
>> > A question about AV_BPRINT_SIZE_AUTOMATIC. Is there a heuristic for when 
>> > to use this versus unlimited?
>> >
>> > Or is it that generally if you would have used a buffer of 1000 or less 
>> > automatic is the right choice?
>> 
>> It depends on what you want. With AUTOMATIC you limit length to 1000 chars 
>> but you don't have to free the buffer. Otherwise you are not limiting the 
>> buffer size, but you have to free it. So if it is impossible to hit the 
>> limit, you should always use AUTOMATIC.
>> 
>> In this case you have to decide for yourself which to use, because I don't 
>> know if 1000 char buffer is big enough for the possible use cases. I 
>> only suggested to consider it, because you are using limited buffers for 
>> other strings, so it may not even be possible to outgrow 1000 chars. It is 
>> up to you decide depending on what you want to support.
>> 
>> Regards,
>> Marton
>> 
>> >
>> >> On 7 Apr 2020, at 20:50, Marton Balint  wrote:
>> >> 
>> >> 
>> >> 
>> >>> On Tue, 7 Apr 2020, phunkyfish wrote:
>> >>> 
>> >>> ---
>> >>> libavformat/rtsp.c | 48 +-
>> >>> 1 file changed, 39 insertions(+), 9 deletions(-)
>> >>> 
>> >>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> >>> index cd6fc32a29..dad3f7915e 100644
>> >>> --- a/libavformat/rtsp.c
>> >>> +++ b/libavformat/rtsp.c
>> >>> @@ -21,6 +21,7 @@
>> >>> #include "libavutil/avassert.h"
>> >>> #include "libavutil/base64.h"
>> >>> +#include "libavutil/bprint.h"
>> >>> #include "libavutil/avstring.h"
>> >>> #include "libavutil/intreadwrite.h"
>> >>> #include "libavutil/mathematics.h"
>> >>> @@ -2447,7 +2448,7 @@ static int rtp_probe(const AVProbeData *p)
>> >>> static int rtp_read_header(AVFormatContext *s)
>> >>> {
>> >>>uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
>> >>> -char host[500], sdp[500];
>> >>> +char host[500], filters_buf[1000];
>> >>>int ret, port;
>> >>>URLContext* in = NULL;
>> >>>int payload_type;
>> >>> @@ -2456,6 +2457,8 @@ static int rtp_read_header(AVFormatContext *s)
>> >>>AVIOContext pb;
>> >>>socklen_t addrlen = sizeof(addr);
>> >>>RTSPState *rt = s->priv_data;
>> >>> +const char *p;
>> >>> +AVBPrint sdp;
>> >>>
>> >>>if (!ff_network_init())
>> >>>return AVERROR(EIO);
>> >>> @@ -2513,16 +2516,38 @@ static int rtp_read_header(AVFormatContext *s)
>> >>>av_url_split(NULL, 0, NULL, 0, host, sizeof(host), &port,
>> >>> NULL, 0, s->url);
>> >>> -snprintf(sdp, sizeof(sdp),
>> >>> - "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
>> >>> - addr.ss_family == AF_INET ? 4 : 6, host,
>> >>> - par->codec_type == AVMEDIA_TYPE_DATA  ? "application" :
>> >>> - par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
>> >>> - port, payload_type);
>> >>> -av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
>> >>> +av_bprint_init(&sdp, 0, AV_BPRINT_SIZE_UNLIMITED);
>> >> 
>> >> You may also use AV_BPRINT_SIZE_AUTOMATIC in which case you will get a 
>> >> static buffer which will be limited (roughly 1000 chars) but you don't 
>> >> have to free it with av_bprint_finalize().
>> >> 
>> >>> +av_bprintf(&sdp, "v=0\r\nc=IN IP%d %s\r\n",
>> >>> +   addr.ss_family == AF_INET ? 4 : 6, host);
>> >>> +
>> >>> +p = strchr(s->url, '?');
>> >>> +if (p) {
>> >>> +static const char *filters[][2] = {{"sources", "incl"}, 
>> >>> {"block", "excl"}, {NULL, NULL}};
>> >>> +int i;
>> >>> +char *q;
>> >>> +for (i = 0; filters[i][0]; i++) {
>> >>> +if (av_find_info_tag(filters_buf, sizeof(filters_buf), 
>> >>> filters[i][0], p)) {
>> >>> +q = filters_buf;
>> >>> +while ((q = strchr(q, ',')) != NULL)
>> >>> +*q = ' ';
>> >>> +av_bprintf(&sdp, "a=source-filter:%s IN IP%d %s %s\r\n",
>> >>> +   filters[i][1],
>> >>> +   addr.ss_family == AF_INET ? 4 : 6, host,
>> >>> +   filters_buf);
>> >>> +}
>> >>> +}
>> >>> +}
>> >>> +
>> >>> +av_bprintf(&sdp, "m=%s %d RTP/AVP %d\r\n",
>> >>> +   par->codec_type == AVMEDIA_TYPE_DATA  ? "application" :
>> >>> +   par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : 
>> >>> "audio",
>> >>> +   port, payload_type);
>> >>> +av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp.

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: fix the build failure when hevc_vaapi is disabled

[Fu, Linjie]

> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: Sunday, April 12, 2020 20:14
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: fix the build failure
> when hevc_vaapi is disabled
> 
> On 12/04/2020 12:55, Andreas Rheinhardt wrote:
> > Linjie Fu:
> >> Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
> >>
> >> Failure reported in:
> >> http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-
> archlinux-gcc-random
> >>
> >> Signed-off-by: Linjie Fu 
> >> ---
> >>  libavcodec/vaapi_decode.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> >> index 54a0ecb..06916cc 100644
> >> --- a/libavcodec/vaapi_decode.c
> >> +++ b/libavcodec/vaapi_decode.c
> >> @@ -383,6 +383,7 @@ static const struct {
> >> H264ConstrainedBaseline),
> >>  MAP(H264,H264_MAIN,   H264Main),
> >>  MAP(H264,H264_HIGH,   H264High),
> >> +#if CONFIG_HEVC_VAAPI_HWACCEL
> >>  #if VA_CHECK_VERSION(0, 37, 0)
> >>  MAP(HEVC,HEVC_MAIN,   HEVCMain),
> >>  MAP(HEVC,HEVC_MAIN_10,HEVCMain10  ),
> >> @@ -393,6 +394,7 @@ static const struct {
> >>  MAP(HEVC,HEVC_REXT,   None,
> >>   ff_vaapi_parse_hevc_rext_profile ),
> >>  #endif
> >> +#endif
> >>  MAP(MJPEG,   MJPEG_HUFFMAN_BASELINE_DCT,
> >>JPEGBaseline),
> >>  MAP(WMV3,VC1_SIMPLE,  VC1Simple   ),
> >>
> > Any more comments? If not, I'll apply this soon (i.e. in a few hours).
> 
> I'd put it around the RExt part only, to be more consistent with other codecs.
Ok, and  also combined with VA_CHECK_VERSION as Carl has suggested, thx.

- Linjie


___
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 v2] lavc/vaapi_decode: fix the build failure when hevc_vaapi is disabled

[Linjie Fu]

Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi

Failure reported in:
http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-random

Signed-off-by: Linjie Fu 
---
 libavcodec/vaapi_decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 54a0ecb..5e4f62b 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -389,7 +389,7 @@ static const struct {
 MAP(HEVC,HEVC_MAIN_STILL_PICTURE,
   HEVCMain),
 #endif
-#if VA_CHECK_VERSION(1, 2, 0)
+#if VA_CHECK_VERSION(1, 2, 0) && CONFIG_HEVC_VAAPI_HWACCEL
 MAP(HEVC,HEVC_REXT,   None,
  ff_vaapi_parse_hevc_rext_profile ),
 #endif
-- 
2.7.4

___
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] kmsgrab: Drop DRM master if running as root

[Mark Thompson]

If we have both root and DRM master then drop the latter because we
don't need both and holding onto it can interfere with running other
programs.

From a discussion with deltasquared on IRC.
---
It would be marginally better to check whether we have CAP_SYS_ADMIN rather 
than just whether we are effectively root, but the capabilities interface is a 
lot more complex to query and this is already sufficient to cover the reported 
case.

 libavdevice/kmsgrab.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
index d0de774871..53280da0f5 100644
--- a/libavdevice/kmsgrab.c
+++ b/libavdevice/kmsgrab.c
@@ -263,6 +263,13 @@ static av_cold int kmsgrab_read_header(AVFormatContext 
*avctx)
 ctx->device = (AVHWDeviceContext*) ctx->device_ref->data;
 ctx->hwctx  = (AVDRMDeviceContext*)ctx->device->hwctx;
 
+if (geteuid() == 0 && drmIsMaster(ctx->hwctx->fd)) {
+// If we have both root and DRM master then drop the latter
+// because we don't need both and holding onto it can interfere
+// with running other programs.
+drmDropMaster(ctx->hwctx->fd);
+}
+
 err = drmSetClientCap(ctx->hwctx->fd,
   DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
 if (err < 0) {
-- 
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 1/2] swscale/yuv2rgb: Fix vertical dither offset with slices

[Michael Niedermayer]

On Thu, Apr 02, 2020 at 10:56:32PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libswscale/yuv2rgb.c | 43 ++-
>  1 file changed, 22 insertions(+), 21 deletions(-)

will apply

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mips: fix get_cabac_inline_mips function name

[Michael Niedermayer]

On Sat, Apr 11, 2020 at 06:54:33PM -0700, Rosen Penev wrote:
> On other platforms, the functions are named get_cabac_inline_xxx but not
> this one. There's also a define.
> 
> Signed-off-by: Rosen Penev 
> ---
>  libavcodec/mips/cabac.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

thx

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

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

Re: [FFmpeg-devel] [PATCH] avformat/oggdec: Check for EOF after page header

[Michael Niedermayer]

On Wed, Apr 01, 2020 at 09:29:14PM +0200, Michael Niedermayer wrote:
> Fixes: Infinite loop
> Fixes: Ticket8594
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/oggdec.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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] avcodec/mips: fix compilation with MIPS16

[Michael Niedermayer]

On Sat, Apr 11, 2020 at 06:54:32PM -0700, Rosen Penev wrote:
> get_cabac_inline for mips uses inline asm that relies on mips32
> instructions.
> 
> Signed-off-by: Rosen Penev 
> ---
>  libavcodec/mips/cabac.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/mips/cabac.h b/libavcodec/mips/cabac.h
> index 2a05e5ab3c..cc40dbba15 100644
> --- a/libavcodec/mips/cabac.h
> +++ b/libavcodec/mips/cabac.h
> @@ -28,6 +28,7 @@
>  #include "libavutil/mips/mmiutils.h"
>  #include "config.h"
>  

> +#ifndef __mips16

this should probably be something set by configure
something like HAVE_MIPS* i suspect

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 1/2] tools/target_dec_fuzzer: Adjust threshold for zerocodec

[Michael Niedermayer]

On Sun, Feb 23, 2020 at 06:27:25PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (147sec -> 1sec)
> Fixes: 
> 20764/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ZEROCODEC_fuzzer-5068274603917312
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  tools/target_dec_fuzzer.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

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

Democracy is the form of government in which you can choose your dictator


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 v3 1/2] avcodec: add adpcm_ima_ssi encoder

[Paul B Mahol]

On 4/12/20, Zane van Iperen  wrote:
> On Sun, 12 Apr 2020 15:01:39 +0200
> "Paul B Mahol"  wrote:
>
>> >
>> > I probably should have mentioned that yes, I had already added the
>> > appropriate SSI code to adpcm_compress_trellis().
>>
>> The one that updates node predictor?
>> >
>> >
> Yep, wherever there was a check for QT, I added a check for SSI so that
> they both take the same code paths.
>
> They're the same format, so that shouldn't cause any problems.
>

Please point to latest such patch that contain that change.

> ___
> 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 2/2] avcodec/mv30: use aandcttables for quantizer scaling

[Michael Niedermayer]

On Sun, Apr 12, 2020 at 12:33:50PM +1000, Peter Ross wrote:
> ---
>  configure |  2 +-
>  libavcodec/mv30.c | 22 ++
>  2 files changed, 3 insertions(+), 21 deletions(-)

assuming these are the same, the patch should be ok
and assuming noone objects of course

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


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]lavu/mem: Make alloc array functions more similar to av_malloc

[Michael Niedermayer]

On Sun, Apr 12, 2020 at 01:53:51AM +0200, Carl Eugen Hoyos wrote:
> Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> :
> >
> > Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
> > :
> > >
> > > On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
> > > > Hi!
> > > >
> > > > Attached patch makes the alloc array functions more similar to
> > > > av_malloc, depending on max_alloc_size instead of INT_MAX.
> > > >
> > > > Allows a work-around for ticket #7140
> > > >
> > > > Please comment, Carl Eugen
> > >
> > > >  mem.c |8 
> > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > 507531ed6f0932834d005bc1dd7d18e762f158b2  
> > > > 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
> > > > From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 2001
> > > > From: Carl Eugen Hoyos 
> > > > Date: Sat, 4 Apr 2020 00:37:03 +0200
> > > > Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
> > > >  av_malloc().
> > > >
> > > > Do not limit the array allocation functions to allocations of INT_MAX,
> > > > instead depend on max_alloc_size like av_malloc().
> > > >
> > > > Allows a workaround for ticket #7140.
> > > > ---
> > > >  libavutil/mem.c | 8 
> > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > av_size_mult() may be faster
> >
> > New patch attached.
> 
> And an actually working variant.
> 
> Please comment, Carl Eugen

>  mem.c |   20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 9be759276a25d6fa787286c3bce849486573266a  
> 0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
> From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 12 Apr 2020 00:36:30 +0200
> Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> av_malloc().
> 
> Do not limit the array allocation functions and av_calloc() to allocations
> of INT_MAX, instead depend on max_alloc_size like av_malloc().
> 
> Allows a workaround for ticket #7140.
> ---
>  libavutil/mem.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)

should be ok

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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] avcodec/cbs: Avoid leaving the ... out in calls to variadic macros

[Andreas Rheinhardt]

Mark Thompson:
> On 23/03/2020 00:52, Andreas Rheinhardt wrote:
>> According to C99, there has to be at least one argument for every ...
>> in a variadic function-like macro. In practice most (all?) compilers also
>> allow to leave it completely out, but it is nevertheless required: In a
>> variadic macro "there shall be more arguments in the invocation than there
>> are parameters in the macro definition (excluding the ...)." (C99,
>> 6.10.3.4).
>>
>> CBS (not the framework itself, but the macros used in the
>> cbs_*_syntax_template.c files) relies on the compiler allowing to leave
>> a variadic macro argument out. This leads to warnings when compiling in
>> -pedantic mode, e.g. "warning: must specify at least one argument for
>> '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]"
>> from Clang.
>>
>> Most of these warnings can be easily avoided: The syntax_templates
>> mostly contain helper macros that expand to more complex variadic macros
>> and these helper macros often omit an argument for the  Modifying
>> them to always expand to complex macros with an empty argument for the
>> ... at the end fixes most of these warnings: The number of warnings went
>> down from 400 to 0 for cbs_av1, from 1114 to 32 for cbs_h2645, from 38 to
>> 0 for cbs_jpeg, from 166 to 0 for cbs_mpeg2 and from 110 to 8 for cbs_vp9.
>>
>> These eight remaining warnings for cbs_vp9 have been fixed by switching
>> to another macro in cbs_vp9_syntax_template: The fixed values for the
>> sync bytes as well as the trailing bits for byte-alignment are now read
>> via the fixed() macro (this also adds a check to ensure that trailing
>> bits are indeed zero as they have to be).
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> There are two ways to fix the remaining 32 warnings from cbs_h2645:
>>
>> Simply add ", " to all macro calls that make use of the complex macros;
>> this has the drawback of adding uglyness to cbs_h26x_syntax_template.c.
>>
>> Or add new macros for these macro calls: The places that produce
>> warnings use the complex macros directly, because they use names
>> different from the default names that the helper macros use, but they do
>> not use subscripts and therefore leave the variadic argument (designed
>> for subscripts) out. I would have implemented the second solution if it
>> were not for the problem of the naming of the new macros.
>>
>> (There is of course also the possibility not to care about the remaining
>> ones.)
>>
>>  libavcodec/cbs_av1.c | 16 
>>  libavcodec/cbs_h2645.c   | 14 +++---
>>  libavcodec/cbs_jpeg.c|  2 +-
>>  libavcodec/cbs_mpeg2.c   |  6 +++---
>>  libavcodec/cbs_vp9.c | 13 ++---
>>  libavcodec/cbs_vp9_syntax_template.c | 21 -
>>  6 files changed, 29 insertions(+), 43 deletions(-)
> 
> Looks fine to me, keeping the ugliness in the macros rather than the 
> templates is good.
> 
> Is there any compiler which actually fails here, or is the only case which 
> finds it the warning in clang pedantic mode?
> 
Both Clang as well as GCC warn in pedantic mode for this (although GCC's
warning is not called "gnu-zero-variadic-macro-arguments"; it simply
says "warning: ISO C99 requires at least one argument for the "..." in a
variadic macro").

Any suggestions for macro names for the remaining stuff (stuff that uses
an unusual name, but no subscripts (like last_payload_type_byte and
last_payload_size_byte))? If not, I'll apply.

I know of no compiler that refuses to compile because of this.

- Andreas
___
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]lavfi/telecine: Mark telecined frames as interlaced

[Carl Eugen Hoyos]

Am So., 12. Apr. 2020 um 15:16 Uhr schrieb Paul B Mahol :
>
> On 4/12/20, Carl Eugen Hoyos  wrote:
> > Am So., 12. Apr. 2020 um 15:00 Uhr schrieb Paul B Mahol :
> >>
> >> On 4/12/20, Carl Eugen Hoyos  wrote:
> >> > Am So., 12. Apr. 2020 um 11:35 Uhr schrieb Paul B Mahol
> >> > :
> >> >>
> >> >> On 4/12/20, Carl Eugen Hoyos  wrote:
> >> >> > Am So., 12. Apr. 2020 um 10:38 Uhr schrieb Paul B Mahol
> >> >> > :
> >> >> >>
> >> >> >> On 4/11/20, Paul B Mahol  wrote:
> >> >> >> > On 4/11/20, Carl Eugen Hoyos  wrote:
> >> >> >> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
> >> >> >> >> :
> >> >> >> >>>
> >> >> >> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
> >> >> >> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
> >> >> >> >>> > :
> >> >> >> >>> >>
> >> >> >> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> >> >> >> >>> >> :
> >> >> >> >>> >> >
> >> >> >> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> >> >> >> >>> >> > :
> >> >> >> >>> >> > >
> >> >> >> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
> >> >> >> >>> >> > > :
> >> >> >> >>> >> > > >
> >> >> >> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> >> >> >> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen
> >> >> >> >>> >> > > > > Hoyos
> >> >> >> >>> >> > > > > :
> >> >> >> >>> >> > > > >
> >> >> >> >>> >> > > > >> Attached patch marks actually telecined frames as
> >> >> >> >>> >> > > > >> interlaced,
> >> >> >> >>> >> > > > >> other frames as progressive.
> >> >> >> >>> >> > > > >
> >> >> >> >>> >> > > > > New patch with changes to fate attached.
> >> >> >> >>> >> > > > >
> >> >> >> >>> >> > > > > Please comment, Carl Eugen
> >> >> >> >>> >> > > >
> >> >> >> >>> >> > > > Those yadif tests look wrong. The patch shouldn't
> >> >> >> >>> >> > > > affect
> >> >> >> >>> >> > > > them.
> >> >> >> >>> >> > >
> >> >> >> >>> >> > > Clearly, thank you!
> >> >> >> >>> >> > >
> >> >> >> >>> >> > > New patch attached, it should now only change the
> >> >> >> >>> >> > > telecined
> >> >> >> >>> >> > > frames and leave the other frames as they are, the
> >> >> >> >>> >> > > setfield
> >> >> >> >>> >> > > filter can be used to force a progressive setting for
> >> >> >> >>> >> > > them.
> >> >> >> >>> >> >
> >> >> >> >>> >> > New patch attached that also sets top_field_first
> >> >> >> >>> >>
> >> >> >> >>> >> Which had the effect that fate is correct again, new patch
> >> >> >> >>> >> attached.
> >> >> >> >>> >
> >> >> >> >>> > Patch applied.
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>> This was never approved by me.
> >> >> >> >>
> >> >> >> >> You reviewed it on irc and correctly pointed out the missing
> >> >> >> >> bits.
> >> >> >> >
> >> >> >> > Lies, I was against that idea from start.
> >> >> >> >
> >> >> >> >>
> >> >> >> >>> So revert it ASAP!
> >> >> >> >>
> >> >> >> >> What should be changed about it?
> >> >> >> >
> >> >> >> > Return of code as it was before this pointless change.
> >> >> >> > I see no good out of it.
> >> >> >>
> >> >> >> I gonna revert this ASAP!
> >> >> >
> >> >> > Could you explain why it is wrong to mark interlaced frames
> >> >> > as interlaced?
> >> >>
> >> >> The frames are not interlaced.
> >> >
> >> > Using the usual 3:2 telecine, the filter outputs two progressive
> >> > frames, followed by three interlaced frames, the patch should
> >> > mark the interlaced frames as interlaced and I believe it does.
> >>
> >> You are very ignorant or very stupid or both.
> >
> > Apparently yes because ...
> >
> >> Interlaced frames are frames produced by interlacing.
> >> Telecine is not interlacing.
> >
> > ... to the best of my knowledge, the telecine process outputs
> > interlaced (and non-interlaced) frames, so I do not understand
> > your argumentation, please elaborate.
>
> Interlacing usually destroys half of data, telecine never does that.

There are cameras that output interlaced content, they do not
destroy any data (the "missing" data never existed).

I don't think your definition is ideal, a more useful definition is that
the fields of one frame originate from different points in time.

> Claiming frames are interlaced will just confuse confused users more.

I was more thinking of encoders, they will be less confused with the
patch.

> >> >> I thought you knew that interlacing destroys half of data.
> >> >> Telecine does not destroys data.
> >> >
> >> > Telecine duplicates some data, leading to interlaced frames.
> >> > A (perfect) detecine process can remove the duplicated data
> >> > (and the interlaced frames).

Carl Eugen
___
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/cbs: Avoid leaving the ... out in calls to variadic macros

[Mark Thompson]

On 23/03/2020 00:52, Andreas Rheinhardt wrote:
> According to C99, there has to be at least one argument for every ...
> in a variadic function-like macro. In practice most (all?) compilers also
> allow to leave it completely out, but it is nevertheless required: In a
> variadic macro "there shall be more arguments in the invocation than there
> are parameters in the macro definition (excluding the ...)." (C99,
> 6.10.3.4).
> 
> CBS (not the framework itself, but the macros used in the
> cbs_*_syntax_template.c files) relies on the compiler allowing to leave
> a variadic macro argument out. This leads to warnings when compiling in
> -pedantic mode, e.g. "warning: must specify at least one argument for
> '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]"
> from Clang.
> 
> Most of these warnings can be easily avoided: The syntax_templates
> mostly contain helper macros that expand to more complex variadic macros
> and these helper macros often omit an argument for the  Modifying
> them to always expand to complex macros with an empty argument for the
> ... at the end fixes most of these warnings: The number of warnings went
> down from 400 to 0 for cbs_av1, from 1114 to 32 for cbs_h2645, from 38 to
> 0 for cbs_jpeg, from 166 to 0 for cbs_mpeg2 and from 110 to 8 for cbs_vp9.
> 
> These eight remaining warnings for cbs_vp9 have been fixed by switching
> to another macro in cbs_vp9_syntax_template: The fixed values for the
> sync bytes as well as the trailing bits for byte-alignment are now read
> via the fixed() macro (this also adds a check to ensure that trailing
> bits are indeed zero as they have to be).
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> There are two ways to fix the remaining 32 warnings from cbs_h2645:
> 
> Simply add ", " to all macro calls that make use of the complex macros;
> this has the drawback of adding uglyness to cbs_h26x_syntax_template.c.
> 
> Or add new macros for these macro calls: The places that produce
> warnings use the complex macros directly, because they use names
> different from the default names that the helper macros use, but they do
> not use subscripts and therefore leave the variadic argument (designed
> for subscripts) out. I would have implemented the second solution if it
> were not for the problem of the naming of the new macros.
> 
> (There is of course also the possibility not to care about the remaining
> ones.)
> 
>  libavcodec/cbs_av1.c | 16 
>  libavcodec/cbs_h2645.c   | 14 +++---
>  libavcodec/cbs_jpeg.c|  2 +-
>  libavcodec/cbs_mpeg2.c   |  6 +++---
>  libavcodec/cbs_vp9.c | 13 ++---
>  libavcodec/cbs_vp9_syntax_template.c | 21 -
>  6 files changed, 29 insertions(+), 43 deletions(-)

Looks fine to me, keeping the ugliness in the macros rather than the templates 
is good.

Is there any compiler which actually fails here, or is the only case which 
finds it the warning in clang pedantic mode?

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 v3] avformat/hlsenc: add hls_fmp4_init_resend option

[Steven Liu]

> 2020年4月7日 下午5:31，Steven Liu  写道：
> 
> add option for resend init file after m3u8 refresh everytime.
> 
> Signed-off-by: Steven Liu 
> ---
> doc/muxers.texi  |  3 +++
> libavformat/hlsenc.c | 41 -
> 2 files changed, 39 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index d304181671..4ae9d2cda9 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -836,6 +836,9 @@ fmp4 files may be used in HLS version 7 and above.
> @item hls_fmp4_init_filename @var{filename}
> Set filename to the fragment files header file, default filename is 
> @file{init.mp4}.
> 
> +@item hls_fmp4_init_resend @var{filename}
> +Resend init file after m3u8 file refresh every time, default is @var{0}.
> +
> When @code{var_stream_map} is set with two or more variant streams, the
> @var{filename} pattern must contain the string "%v", this string specifies
> the position of variant stream index in the generated init file names.
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index b4c72b6e54..668439440c 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -119,6 +119,7 @@ typedef struct VariantStream {
> int packets_written;
> int init_range_length;
> uint8_t *temp_buffer;
> +uint8_t *init_buffer;
> 
> AVFormatContext *avf;
> AVFormatContext *vtt_avf;
> @@ -192,6 +193,7 @@ typedef struct HLSContext {
> char *segment_filename;
> char *fmp4_init_filename;
> int segment_type;
> +int resend_init_file;  ///< resend init file into disk after refresh m3u8
> 
> int use_localtime;  ///< flag to expand filename with localtime
> int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
> @@ -2234,6 +2236,23 @@ static int hls_write_header(AVFormatContext *s)
> return ret;
> }
> 
> +static int hls_init_file_resend(AVFormatContext *s, VariantStream *vs)
> +{
> +HLSContext *hls = s->priv_data;
> +AVDictionary *options = NULL;
> +int ret = 0;
> +
> +set_http_options(s, &options, hls);
> +ret = hlsenc_io_open(s, &vs->out, hls->fmp4_init_filename, &options);
> +av_dict_free(&options);
> +if (ret < 0)
> +return ret;
> +avio_write(vs->out, vs->init_buffer, vs->init_range_length);
> +hlsenc_io_close(s, &vs->out, hls->fmp4_init_filename);
> +
> +return ret;
> +}
> +
> static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
> {
> HLSContext *hls = s->priv_data;
> @@ -2246,7 +2265,6 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> int range_length = 0;
> const char *proto = NULL;
> int use_temp_file = 0;
> -uint8_t *buffer = NULL;
> VariantStream *vs = NULL;
> char *old_filename = NULL;
> 
> @@ -2332,9 +2350,12 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> avio_flush(oc->pb);
> if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> if (!vs->init_range_length) {
> -range_length = avio_close_dyn_buf(oc->pb, &buffer);
> -avio_write(vs->out, buffer, range_length);
> -av_freep(&buffer);
> +range_length = avio_close_dyn_buf(oc->pb, &vs->init_buffer);
> +if (range_length <= 0)
> +return AVERROR(EINVAL);
> +avio_write(vs->out, vs->init_buffer, range_length);
> +if (!hls->resend_init_file)
> +av_freep(&vs->init_buffer);
> vs->init_range_length = range_length;
> avio_open_dyn_buf(&oc->pb);
> vs->packets_written = 0;
> @@ -2446,6 +2467,14 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> }
> }
> 
> +if (hls->resend_init_file && hls->segment_type == SEGMENT_TYPE_FMP4) 
> {
> +ret = hls_init_file_resend(s, vs);
> +if (ret < 0) {
> +av_freep(&old_filename);
> +return ret;
> +}
> +}
> +
> if (hls->flags & HLS_SINGLE_FILE) {
> vs->number++;
> vs->start_pos += vs->size;
> @@ -2510,7 +2539,8 @@ static void hls_free_variant_streams(struct HLSContext 
> *hls)
> }
> 
> avformat_free_context(vs->avf);
> -
> +if (hls->resend_init_file)
> +av_freep(&vs->init_buffer);
> hls_free_segments(vs->segments);
> hls_free_segments(vs->old_segments);
> av_freep(&vs->m3u8_name);
> @@ -3010,6 +3040,7 @@ static const AVOption options[] = {
> {"mpegts",   "make segment file to mpegts files in m3u8", 0, 
> AV_OPT_TYPE_CONST, {.i64 = SEGMENT_TYPE_MPEGTS }, 0, UINT_MAX,   E, 
> "segment_type"},
> {"fmp4",   "make segment file to fragment mp4 files in m3u8", 0, 
> AV_OPT_TYPE_CONST, {.i64 = SEGMENT_TYPE_FMP4 }, 0, UINT_MAX,   E, 
> "segment_type"},
> {"hls_fmp4_init_filename", "set fragment mp4 file init filename", 
> OFFSET(fmp4_init_filename),   AV_O

Re: [FFmpeg-devel] [PATCH v3 1/2] avcodec: add adpcm_ima_ssi encoder

[Zane van Iperen]

On Sun, 12 Apr 2020 15:01:39 +0200
"Paul B Mahol"  wrote:

> >
> > I probably should have mentioned that yes, I had already added the
> > appropriate SSI code to adpcm_compress_trellis().  
> 
> The one that updates node predictor?
> >
> >
Yep, wherever there was a check for QT, I added a check for SSI so that
they both take the same code paths.

They're the same format, so that shouldn't cause any problems.

___
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]lavfi/telecine: Mark telecined frames as interlaced

[Paul B Mahol]

On 4/12/20, Carl Eugen Hoyos  wrote:
> Am So., 12. Apr. 2020 um 15:00 Uhr schrieb Paul B Mahol :
>>
>> On 4/12/20, Carl Eugen Hoyos  wrote:
>> > Am So., 12. Apr. 2020 um 11:35 Uhr schrieb Paul B Mahol
>> > :
>> >>
>> >> On 4/12/20, Carl Eugen Hoyos  wrote:
>> >> > Am So., 12. Apr. 2020 um 10:38 Uhr schrieb Paul B Mahol
>> >> > :
>> >> >>
>> >> >> On 4/11/20, Paul B Mahol  wrote:
>> >> >> > On 4/11/20, Carl Eugen Hoyos  wrote:
>> >> >> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
>> >> >> >> :
>> >> >> >>>
>> >> >> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
>> >> >> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
>> >> >> >>> > :
>> >> >> >>> >>
>> >> >> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
>> >> >> >>> >> :
>> >> >> >>> >> >
>> >> >> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>> >> >> >>> >> > :
>> >> >> >>> >> > >
>> >> >> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
>> >> >> >>> >> > > :
>> >> >> >>> >> > > >
>> >> >> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
>> >> >> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen
>> >> >> >>> >> > > > > Hoyos
>> >> >> >>> >> > > > > :
>> >> >> >>> >> > > > >
>> >> >> >>> >> > > > >> Attached patch marks actually telecined frames as
>> >> >> >>> >> > > > >> interlaced,
>> >> >> >>> >> > > > >> other frames as progressive.
>> >> >> >>> >> > > > >
>> >> >> >>> >> > > > > New patch with changes to fate attached.
>> >> >> >>> >> > > > >
>> >> >> >>> >> > > > > Please comment, Carl Eugen
>> >> >> >>> >> > > >
>> >> >> >>> >> > > > Those yadif tests look wrong. The patch shouldn't
>> >> >> >>> >> > > > affect
>> >> >> >>> >> > > > them.
>> >> >> >>> >> > >
>> >> >> >>> >> > > Clearly, thank you!
>> >> >> >>> >> > >
>> >> >> >>> >> > > New patch attached, it should now only change the
>> >> >> >>> >> > > telecined
>> >> >> >>> >> > > frames and leave the other frames as they are, the
>> >> >> >>> >> > > setfield
>> >> >> >>> >> > > filter can be used to force a progressive setting for
>> >> >> >>> >> > > them.
>> >> >> >>> >> >
>> >> >> >>> >> > New patch attached that also sets top_field_first
>> >> >> >>> >>
>> >> >> >>> >> Which had the effect that fate is correct again, new patch
>> >> >> >>> >> attached.
>> >> >> >>> >
>> >> >> >>> > Patch applied.
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>> This was never approved by me.
>> >> >> >>
>> >> >> >> You reviewed it on irc and correctly pointed out the missing
>> >> >> >> bits.
>> >> >> >
>> >> >> > Lies, I was against that idea from start.
>> >> >> >
>> >> >> >>
>> >> >> >>> So revert it ASAP!
>> >> >> >>
>> >> >> >> What should be changed about it?
>> >> >> >
>> >> >> > Return of code as it was before this pointless change.
>> >> >> > I see no good out of it.
>> >> >>
>> >> >> I gonna revert this ASAP!
>> >> >
>> >> > Could you explain why it is wrong to mark interlaced frames
>> >> > as interlaced?
>> >>
>> >> The frames are not interlaced.
>> >
>> > Using the usual 3:2 telecine, the filter outputs two progressive
>> > frames, followed by three interlaced frames, the patch should
>> > mark the interlaced frames as interlaced and I believe it does.
>> >
>>
>> You are very ignorant or very stupid or both.
>
> Apparently yes because ...
>
>> Interlaced frames are frames produced by interlacing.
>> Telecine is not interlacing.
>
> ... to the best of my knowledge, the telecine process outputs
> interlaced (and non-interlaced) frames, so I do not understand
> your argumentation, please elaborate.
>

Interlacing usually destroys half of data, telecine never does that.

Claiming frames are interlaced will just confuse confused users more.

>> >> I thought you knew that interlacing destroys half of data.
>> >> Telecine does not destroys data.
>> >
>> > Telecine duplicates some data, leading to interlaced frames.
>> > A (perfect) detecine process can remove the duplicated data
>> > (and the interlaced frames).
>
> Happy Easter, Carl Eugen
> ___
> 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 v2 2/7] lavutil: add dolby vision related header

[myp...@gmail.com]

On Sun, Apr 12, 2020 at 9:06 PM Jean-Baptiste Kempf  wrote:
>
>
>
> On Sun, Apr 12, 2020, at 03:22, myp...@gmail.com wrote:
> > On Sat, Apr 11, 2020 at 10:18 PM Jean-Baptiste Kempf  
> > wrote:
> > >
> > > I really do not think it is a good idea to have a header with the name 
> > > dolby in it.
> > >
> > Can you give some details, I don't why is a bad idea.
>
> Dolby is a trademark.
I see, will rename the file, tks the comments
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH]lavfi/telecine: Mark telecined frames as interlaced

[Carl Eugen Hoyos]

Am So., 12. Apr. 2020 um 15:00 Uhr schrieb Paul B Mahol :
>
> On 4/12/20, Carl Eugen Hoyos  wrote:
> > Am So., 12. Apr. 2020 um 11:35 Uhr schrieb Paul B Mahol :
> >>
> >> On 4/12/20, Carl Eugen Hoyos  wrote:
> >> > Am So., 12. Apr. 2020 um 10:38 Uhr schrieb Paul B Mahol
> >> > :
> >> >>
> >> >> On 4/11/20, Paul B Mahol  wrote:
> >> >> > On 4/11/20, Carl Eugen Hoyos  wrote:
> >> >> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
> >> >> >> :
> >> >> >>>
> >> >> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
> >> >> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
> >> >> >>> > :
> >> >> >>> >>
> >> >> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> >> >> >>> >> :
> >> >> >>> >> >
> >> >> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> >> >> >>> >> > :
> >> >> >>> >> > >
> >> >> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
> >> >> >>> >> > > :
> >> >> >>> >> > > >
> >> >> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> >> >> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen
> >> >> >>> >> > > > > Hoyos
> >> >> >>> >> > > > > :
> >> >> >>> >> > > > >
> >> >> >>> >> > > > >> Attached patch marks actually telecined frames as
> >> >> >>> >> > > > >> interlaced,
> >> >> >>> >> > > > >> other frames as progressive.
> >> >> >>> >> > > > >
> >> >> >>> >> > > > > New patch with changes to fate attached.
> >> >> >>> >> > > > >
> >> >> >>> >> > > > > Please comment, Carl Eugen
> >> >> >>> >> > > >
> >> >> >>> >> > > > Those yadif tests look wrong. The patch shouldn't affect
> >> >> >>> >> > > > them.
> >> >> >>> >> > >
> >> >> >>> >> > > Clearly, thank you!
> >> >> >>> >> > >
> >> >> >>> >> > > New patch attached, it should now only change the telecined
> >> >> >>> >> > > frames and leave the other frames as they are, the setfield
> >> >> >>> >> > > filter can be used to force a progressive setting for them.
> >> >> >>> >> >
> >> >> >>> >> > New patch attached that also sets top_field_first
> >> >> >>> >>
> >> >> >>> >> Which had the effect that fate is correct again, new patch
> >> >> >>> >> attached.
> >> >> >>> >
> >> >> >>> > Patch applied.
> >> >> >>> >
> >> >> >>>
> >> >> >>> This was never approved by me.
> >> >> >>
> >> >> >> You reviewed it on irc and correctly pointed out the missing bits.
> >> >> >
> >> >> > Lies, I was against that idea from start.
> >> >> >
> >> >> >>
> >> >> >>> So revert it ASAP!
> >> >> >>
> >> >> >> What should be changed about it?
> >> >> >
> >> >> > Return of code as it was before this pointless change.
> >> >> > I see no good out of it.
> >> >>
> >> >> I gonna revert this ASAP!
> >> >
> >> > Could you explain why it is wrong to mark interlaced frames
> >> > as interlaced?
> >>
> >> The frames are not interlaced.
> >
> > Using the usual 3:2 telecine, the filter outputs two progressive
> > frames, followed by three interlaced frames, the patch should
> > mark the interlaced frames as interlaced and I believe it does.
> >
>
> You are very ignorant or very stupid or both.

Apparently yes because ...

> Interlaced frames are frames produced by interlacing.
> Telecine is not interlacing.

... to the best of my knowledge, the telecine process outputs
interlaced (and non-interlaced) frames, so I do not understand
your argumentation, please elaborate.

> >> I thought you knew that interlacing destroys half of data.
> >> Telecine does not destroys data.
> >
> > Telecine duplicates some data, leading to interlaced frames.
> > A (perfect) detecine process can remove the duplicated data
> > (and the interlaced frames).

Happy Easter, Carl Eugen
___
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]lavfi/telecine: Mark telecined frames as interlaced

[Jean-Baptiste Kempf]

On Sun, Apr 12, 2020, at 15:00, Paul B Mahol wrote:
> You are very ignorant or very stupid or both.

Whatever the technical merit, please do not insult people.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2 2/7] lavutil: add dolby vision related header

[Jean-Baptiste Kempf]

On Sun, Apr 12, 2020, at 03:22, myp...@gmail.com wrote:
> On Sat, Apr 11, 2020 at 10:18 PM Jean-Baptiste Kempf  
> wrote:
> >
> > I really do not think it is a good idea to have a header with the name 
> > dolby in it.
> >
> Can you give some details, I don't why is a bad idea.

Dolby is a trademark.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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 1/2] avcodec: add adpcm_ima_ssi encoder

[Paul B Mahol]

On 4/12/20, Zane van Iperen  wrote:
> On Sun, 12 Apr 2020 11:41:40 +0200
> "Paul B Mahol"  wrote:
>
>> On 4/12/20, Zane van Iperen  wrote:
>> > On Sat, 11 Apr 2020 22:02:26 +0200
>> > "Paul B Mahol"  wrote:
>> >
>> >> >
>> >> > Ping.
>> >> >
>> >> > Also, could someone please clarify something for me?
>> >> >
>> >> > When encoding, there's no inherit differences between trellis and
>> >> > non-trellis other then a potentially more-accurate set of
>> >> > nibbles?
>> >> >
>> >> > And the decoder is none the wiser and chews on them both the same
>> >> > way?
>> >> >
>> >> > If I'm right, then this looks to be a decoder issue...
>> >> >
>> >>
>> >> You are wrong, just follow qt adpcm encoder code.
>> >>
>> >
>> > I did.
>> >
>> >
>> > Is it possible, and I don't suggest this lightly, that the trellis
>> > code is bugged, and errors accumulate over time?
>> >
>> > I ask this because all of the encoders (except adpcm_yamaha, which
>> > is different anyway) have either the full sample and/or the step
>> > index periodically written to the bitstream, which is then used to
>> > reset the state machine, thus errors don't accumulate.
>> >
>> > adpcm_ima_ssi doesn't have that, so it relies on the state being
>> > accurate through the entire stream. This would certainly explain the
>> > behaviour I'm seeing in certain cases (see below).
>> >
>> > In both images, the top stream is encoded with '-trellis 0', and the
>> > bottom with '-trellis 1':
>> > - https://0x0.st/iSdS.png
>> >   This one's obvious where the problem is.
>> > - https://0x0.st/iSdQ.png
>> >   This is more subtle, but the entire stream is offset slightly.
>> > It's more noticeable at the start and end.
>> >
>> >
>> > For reference, here's the code I'm using. You'll see it's basically
>> > the same as the adpcm_ima_qt code:
>> >
>> > if (avctx->trellis > 0) {
>> > FF_ALLOC_OR_GOTO(avctx, buf, n * avctx->channels, error);
>> >
>> > for (ch = 0; ch < avctx->channels; ch++) {
>> > adpcm_compress_trellis(avctx, samples + ch, buf + n * ch,
>> >c->status + ch, n, avctx->channels);
>> > c->status[ch].prev_sample = c->status[ch].predictor;
>> > }
>> >
>> > for (i = 0; i < n; i++) {
>> > for (ch = 0; ch < avctx->channels; ch++) {
>> > put_bits(&pb, 4, buf[n * ch + i]);
>> > }
>> > }
>> > av_free(buf);
>> > }
>> >
>> >
>> > Or maybe I just don't fully understand how trellis works.
>>
>> Yes. that is 100% correct.
>>
>> Also you ignored fact that you do not update nodes for SSI variant in
>> compress trellis.
>
> I probably should have mentioned that yes, I had already added the
> appropriate SSI code to adpcm_compress_trellis().

The one that updates node predictor?
>
>
>
>
> ___
> 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]lavfi/telecine: Mark telecined frames as interlaced

[Paul B Mahol]

On 4/12/20, Carl Eugen Hoyos  wrote:
> Am So., 12. Apr. 2020 um 11:35 Uhr schrieb Paul B Mahol :
>>
>> On 4/12/20, Carl Eugen Hoyos  wrote:
>> > Am So., 12. Apr. 2020 um 10:38 Uhr schrieb Paul B Mahol
>> > :
>> >>
>> >> On 4/11/20, Paul B Mahol  wrote:
>> >> > On 4/11/20, Carl Eugen Hoyos  wrote:
>> >> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
>> >> >> :
>> >> >>>
>> >> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
>> >> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
>> >> >>> > :
>> >> >>> >>
>> >> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
>> >> >>> >> :
>> >> >>> >> >
>> >> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>> >> >>> >> > :
>> >> >>> >> > >
>> >> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
>> >> >>> >> > > :
>> >> >>> >> > > >
>> >> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
>> >> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen
>> >> >>> >> > > > > Hoyos
>> >> >>> >> > > > > :
>> >> >>> >> > > > >
>> >> >>> >> > > > >> Attached patch marks actually telecined frames as
>> >> >>> >> > > > >> interlaced,
>> >> >>> >> > > > >> other frames as progressive.
>> >> >>> >> > > > >
>> >> >>> >> > > > > New patch with changes to fate attached.
>> >> >>> >> > > > >
>> >> >>> >> > > > > Please comment, Carl Eugen
>> >> >>> >> > > >
>> >> >>> >> > > > Those yadif tests look wrong. The patch shouldn't affect
>> >> >>> >> > > > them.
>> >> >>> >> > >
>> >> >>> >> > > Clearly, thank you!
>> >> >>> >> > >
>> >> >>> >> > > New patch attached, it should now only change the telecined
>> >> >>> >> > > frames and leave the other frames as they are, the setfield
>> >> >>> >> > > filter can be used to force a progressive setting for them.
>> >> >>> >> >
>> >> >>> >> > New patch attached that also sets top_field_first
>> >> >>> >>
>> >> >>> >> Which had the effect that fate is correct again, new patch
>> >> >>> >> attached.
>> >> >>> >
>> >> >>> > Patch applied.
>> >> >>> >
>> >> >>>
>> >> >>> This was never approved by me.
>> >> >>
>> >> >> You reviewed it on irc and correctly pointed out the missing bits.
>> >> >
>> >> > Lies, I was against that idea from start.
>> >> >
>> >> >>
>> >> >>> So revert it ASAP!
>> >> >>
>> >> >> What should be changed about it?
>> >> >
>> >> > Return of code as it was before this pointless change.
>> >> > I see no good out of it.
>> >>
>> >> I gonna revert this ASAP!
>> >
>> > Could you explain why it is wrong to mark interlaced frames
>> > as interlaced?
>>
>> The frames are not interlaced.
>
> Using the usual 3:2 telecine, the filter outputs two progressive
> frames, followed by three interlaced frames, the patch should
> mark the interlaced frames as interlaced and I believe it does.
>

You are very ignorant or very stupid or both.
Interlaced frames are frames produced by interlacing.
Telecine is not interlacing.

>> I thought you knew that interlacing destroys half of data.
>> Telecine does not destroys data.
>
> Telecine duplicates some data, leading to interlaced frames.
> A (perfect) detecine process can remove the duplicated data
> (and the interlaced frames).
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] vaapi_decode: Improve logging around codec/profile selection

[Mark Thompson]

---
On 12/04/2020 13:14, Mark Thompson wrote:
> ...  This does rather suggest that the error messages in that file should be 
> clearer, though - it would be nice if it could distinguish between "this 
> codec isn't supported by libavcodec at all", "this codec might work but 
> hasn't built into this libavcodec" and "this codec is supported by libavcodec 
> but not by your hardware".

Something like this?


 libavcodec/vaapi_decode.c | 39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 54a0ecb47a..a191850e36 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -429,6 +429,7 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
 const AVCodecDescriptor *codec_desc;
 VAProfile *profile_list = NULL, matched_va_profile, va_profile;
 int profile_count, exact_match, matched_ff_profile, codec_profile;
+int found_codec, found_profile;
 
 AVHWDeviceContext*device = (AVHWDeviceContext*)device_ref->data;
 AVVAAPIDeviceContext *hwctx = device->hwctx;
@@ -457,15 +458,19 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
 }
 
 matched_va_profile = VAProfileNone;
+found_codec = found_profile = 0;
 exact_match = 0;
 
 for (i = 0; i < FF_ARRAY_ELEMS(vaapi_profile_map); i++) {
 int profile_match = 0;
 if (avctx->codec_id != vaapi_profile_map[i].codec_id)
 continue;
+found_codec = 1;
 if (avctx->profile == vaapi_profile_map[i].codec_profile ||
-vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
+vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN) {
 profile_match = 1;
+found_profile = 1;
+}
 
 va_profile = vaapi_profile_map[i].profile_parser ?
  vaapi_profile_map[i].profile_parser(avctx) :
@@ -487,24 +492,42 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
 }
 av_freep(&profile_list);
 
-if (matched_va_profile == VAProfileNone) {
-av_log(avctx, AV_LOG_ERROR, "No support for codec %s "
-   "profile %d.\n", codec_desc->name, avctx->profile);
+if (!found_codec) {
+av_log(avctx, AV_LOG_ERROR, "This libavcodec build does not "
+   "support VAAPI decoding of codec %s.\n",
+   codec_desc->name);
+err = AVERROR(ENOSYS);
+goto fail;
+}
+if (!found_profile && !(avctx->hwaccel_flags &
+AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH)) {
+// We allow this case with profile-mismatch enabled to support
+// things like trying to decode H.264 extended profile.
+av_log(avctx, AV_LOG_ERROR, "This libavcodec build does not "
+   "support VAAPI decoding of codec %s profile %d.\n",
+   codec_desc->name, avctx->profile);
 err = AVERROR(ENOSYS);
 goto fail;
 }
+if (matched_va_profile == VAProfileNone) {
+av_log(avctx, AV_LOG_ERROR, "This VAAPI driver does not "
+   "support decoding of codec %s.\n",
+   codec_desc->name);
+err = AVERROR(EINVAL);
+goto fail;
+}
 if (!exact_match) {
 if (avctx->hwaccel_flags &
 AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH) {
-av_log(avctx, AV_LOG_VERBOSE, "Codec %s profile %d not "
-   "supported for hardware decode.\n",
+av_log(avctx, AV_LOG_WARNING, "This VAAPI driver does not "
+   "support decoding of codec %s profile %d.\n",
codec_desc->name, avctx->profile);
 av_log(avctx, AV_LOG_WARNING, "Using possibly-"
"incompatible profile %d instead.\n",
matched_ff_profile);
 } else {
-av_log(avctx, AV_LOG_VERBOSE, "Codec %s profile %d not "
-   "supported for hardware decode.\n",
+av_log(avctx, AV_LOG_ERROR, "This VAAPI driver does not "
+   "support decoding of codec %s profile %d.\n",
codec_desc->name, avctx->profile);
 err = AVERROR(EINVAL);
 goto fail;
-- 
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] avcodec/cbs: Avoid leaving the ... out in calls to variadic macros

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Andreas Rheinhardt:
>>> According to C99, there has to be at least one argument for every ...
>>> in a variadic function-like macro. In practice most (all?) compilers also
>>> allow to leave it completely out, but it is nevertheless required: In a
>>> variadic macro "there shall be more arguments in the invocation than there
>>> are parameters in the macro definition (excluding the ...)." (C99,
>>> 6.10.3.4).
>>>
>>> CBS (not the framework itself, but the macros used in the
>>> cbs_*_syntax_template.c files) relies on the compiler allowing to leave
>>> a variadic macro argument out. This leads to warnings when compiling in
>>> -pedantic mode, e.g. "warning: must specify at least one argument for
>>> '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]"
>>> from Clang.
>>>
>>> Most of these warnings can be easily avoided: The syntax_templates
>>> mostly contain helper macros that expand to more complex variadic macros
>>> and these helper macros often omit an argument for the  Modifying
>>> them to always expand to complex macros with an empty argument for the
>>> ... at the end fixes most of these warnings: The number of warnings went
>>> down from 400 to 0 for cbs_av1, from 1114 to 32 for cbs_h2645, from 38 to
>>> 0 for cbs_jpeg, from 166 to 0 for cbs_mpeg2 and from 110 to 8 for cbs_vp9.
>>>
>>> These eight remaining warnings for cbs_vp9 have been fixed by switching
>>> to another macro in cbs_vp9_syntax_template: The fixed values for the
>>> sync bytes as well as the trailing bits for byte-alignment are now read
>>> via the fixed() macro (this also adds a check to ensure that trailing
>>> bits are indeed zero as they have to be).
>>>
>>> Signed-off-by: Andreas Rheinhardt 
>>> ---
>>> There are two ways to fix the remaining 32 warnings from cbs_h2645:
>>>
>>> Simply add ", " to all macro calls that make use of the complex macros;
>>> this has the drawback of adding uglyness to cbs_h26x_syntax_template.c.
>>>
>>> Or add new macros for these macro calls: The places that produce
>>> warnings use the complex macros directly, because they use names
>>> different from the default names that the helper macros use, but they do
>>> not use subscripts and therefore leave the variadic argument (designed
>>> for subscripts) out. I would have implemented the second solution if it
>>> were not for the problem of the naming of the new macros.
>>>
>>> (There is of course also the possibility not to care about the remaining
>>> ones.)
>>>
>>>  libavcodec/cbs_av1.c | 16 
>>>  libavcodec/cbs_h2645.c   | 14 +++---
>>>  libavcodec/cbs_jpeg.c|  2 +-
>>>  libavcodec/cbs_mpeg2.c   |  6 +++---
>>>  libavcodec/cbs_vp9.c | 13 ++---
>>>  libavcodec/cbs_vp9_syntax_template.c | 21 -
>>>  6 files changed, 29 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
>>> index 16eb7143b6..fc228086c2 100644
>>> --- a/libavcodec/cbs_av1.c
>>> +++ b/libavcodec/cbs_av1.c
>>> @@ -550,12 +550,12 @@ static size_t 
>>> cbs_av1_get_payload_bytes_left(GetBitContext *gbc)
>>>  #define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs, 
>>> __VA_ARGS__ }) : NULL)
>>>  
>>>  #define fb(width, name) \
>>> -xf(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
>>> +xf(width, name, current->name, 0, MAX_UINT_BITS(width), 0, )
>>>  #define fc(width, name, range_min, range_max) \
>>> -xf(width, name, current->name, range_min, range_max, 0)
>>> +xf(width, name, current->name, range_min, range_max, 0, )
>>>  #define flag(name) fb(1, name)
>>>  #define su(width, name) \
>>> -xsu(width, name, current->name, 0)
>>> +xsu(width, name, current->name, 0, )
>>>  
>>>  #define fbs(width, name, subs, ...) \
>>>  xf(width, name, current->name, 0, MAX_UINT_BITS(width), subs, 
>>> __VA_ARGS__)
>>> @@ -568,7 +568,7 @@ static size_t 
>>> cbs_av1_get_payload_bytes_left(GetBitContext *gbc)
>>>  
>>>  #define fixed(width, name, value) do { \
>>>  av_unused uint32_t fixed_value = value; \
>>> -xf(width, name, fixed_value, value, value, 0); \
>>> +xf(width, name, fixed_value, value, value, 0, ); \
>>>  } while (0)
>>>  
>>>  
>>> @@ -623,9 +623,9 @@ static size_t 
>>> cbs_av1_get_payload_bytes_left(GetBitContext *gbc)
>>>  #define delta_q(name) do { \
>>>  uint8_t delta_coded; \
>>>  int8_t delta_q; \
>>> -xf(1, name.delta_coded, delta_coded, 0, 1, 0); \
>>> +xf(1, name.delta_coded, delta_coded, 0, 1, 0, ); \
>>>  if (delta_coded) \
>>> -xsu(1 + 6, name.delta_q, delta_q, 0); \
>>> +xsu(1 + 6, name.delta_q, delta_q, 0, ); \
>>>  else \
>>>  delta_q = 0; \
>>>  current->name = delta_q; \
>>> @@ -700,9 +700,9 @@ static size_t 
>>> cbs_av1_get_payload_bytes_left(GetBitCo

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: fix the build failure when hevc_vaapi is disabled

[Mark Thompson]

On 12/04/2020 12:55, Andreas Rheinhardt wrote:
> Linjie Fu:
>> Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
>>
>> Failure reported in:
>> http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-random
>>
>> Signed-off-by: Linjie Fu 
>> ---
>>  libavcodec/vaapi_decode.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
>> index 54a0ecb..06916cc 100644
>> --- a/libavcodec/vaapi_decode.c
>> +++ b/libavcodec/vaapi_decode.c
>> @@ -383,6 +383,7 @@ static const struct {
>> H264ConstrainedBaseline),
>>  MAP(H264,H264_MAIN,   H264Main),
>>  MAP(H264,H264_HIGH,   H264High),
>> +#if CONFIG_HEVC_VAAPI_HWACCEL
>>  #if VA_CHECK_VERSION(0, 37, 0)
>>  MAP(HEVC,HEVC_MAIN,   HEVCMain),
>>  MAP(HEVC,HEVC_MAIN_10,HEVCMain10  ),
>> @@ -393,6 +394,7 @@ static const struct {
>>  MAP(HEVC,HEVC_REXT,   None,
>>   ff_vaapi_parse_hevc_rext_profile ),
>>  #endif
>> +#endif
>>  MAP(MJPEG,   MJPEG_HUFFMAN_BASELINE_DCT,
>>JPEGBaseline),
>>  MAP(WMV3,VC1_SIMPLE,  VC1Simple   ),
>>
> Any more comments? If not, I'll apply this soon (i.e. in a few hours).

I'd put it around the RExt part only, to be more consistent with other codecs.  
This does rather suggest that the error messages in that file should be 
clearer, though - it would be nice if it could distinguish between "this codec 
isn't supported by libavcodec at all", "this codec might work but hasn't built 
into this libavcodec" and "this codec is supported by libavcodec but not by 
your hardware".

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

[FFmpeg-devel] Stereo 3D frame packing or HDMI checkerboard input (capture from screen)

[fireYtail3DYTnow livestreamer]

Hello, good morning. I'm a Nvidia 3D vision user and due to having to use
outdated drivers and software after the discontinuation of the feature a
year ago I request that the feature to use Stereo 3D frame packing (from
screen) preferably, or alternatively HDMI checkerboard input for live
streaming via FFMPEG, with SBS as the output sorting. When will this
possibility be added, approximately? Right now it's only possible to do it
in reverse (take a SBS input from screen and convert it to either option)
I've spent many hours trying to find a way to do this but requesting this
is my last hope.
___
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/mux: Make uncoded frames av_packet_unref() compatible

[Andreas Rheinhardt]

Currently uncoded frames (i.e. packets whose data actually points to an
AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
on them will not free them, but may simply make sure that they leak by
losing the pointer to the frame.

This commit changes this by actually making uncoded frames refcounted.
In order not to rely on sizeof(AVFrame) (which is not part of the public
API and so must not be used here in libavformat) the packet's data is
changed to a (padded) buffer containing just a pointer to an AVFrame.
Said buffer is owned by an AVBuffer with a custom free function that
frees the frame as well as the buffer. Thereby the pointer/the AVBuffer
owns the AVFrame.

Said ownership can actually be transferred by copying and resetting
the pointer, as might happen when actually writing the uncoded frames
in AVOutputFormat.write_uncoded_frame() (although currently no muxer
makes use of this possibility).

This makes packets containing uncoded frames compatible with
av_packet_unref(). This already has three advantages in interleaved mode:
1. If an error happens at the preparatory steps (before the packet is
put into the interleavement queue), the frame is properly freed.
2. If the trailer is never written, the frames still in the
interleavement queue will now be properly freed by
ff_packet_list_free().
3. The custom code for moving the packet to the packet list in
ff_interleave_add_packet() can be removed.

It will also simplify fixing further memleaks in future commits.

Suggested-by: Marton Balint 
Signed-off-by: Andreas Rheinhardt 
---
How embarrassing! The earlier version forgot to check the allocation.

 libavformat/mux.c | 56 ---
 1 file changed, 34 insertions(+), 22 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index cc2d1e275a..bb54fd5528 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -550,12 +550,6 @@ fail:
 
 #define AV_PKT_FLAG_UNCODED_FRAME 0x2000
 
-/* Note: using sizeof(AVFrame) from outside lavu is unsafe in general, but
-   it is only being used internally to this file as a consistency check.
-   The value is chosen to be very unlikely to appear on its own and to cause
-   immediate failure if used anywhere as a real size. */
-#define UNCODED_FRAME_PACKET_SIZE (INT_MIN / 3 * 2 + (int)sizeof(AVFrame))
-
 
 #if FF_API_COMPUTE_PKT_FIELDS2 && FF_API_LAVF_AVCTX
 FF_DISABLE_DEPRECATION_WARNINGS
@@ -650,7 +644,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 switch (st->codecpar->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
 frame_size = (pkt->flags & AV_PKT_FLAG_UNCODED_FRAME) ?
- ((AVFrame *)pkt->data)->nb_samples :
+ (*(AVFrame **)pkt->data)->nb_samples :
  av_get_audio_frame_duration(st->codec, pkt->size);
 
 /* HACK/FIXME, we skip the initial 0 size packets as they are most
@@ -746,10 +740,10 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 
 if ((pkt->flags & AV_PKT_FLAG_UNCODED_FRAME)) {
-AVFrame *frame = (AVFrame *)pkt->data;
-av_assert0(pkt->size == UNCODED_FRAME_PACKET_SIZE);
-ret = s->oformat->write_uncoded_frame(s, pkt->stream_index, &frame, 0);
-av_frame_free(&frame);
+AVFrame **frame = (AVFrame **)pkt->data;
+av_assert0(pkt->size == sizeof(*frame));
+ret = s->oformat->write_uncoded_frame(s, pkt->stream_index, frame, 0);
+av_packet_unref(pkt);
 } else {
 ret = s->oformat->write_packet(s, pkt);
 }
@@ -926,14 +920,9 @@ int ff_interleave_add_packet(AVFormatContext *s, AVPacket 
*pkt,
 this_pktl= av_malloc(sizeof(AVPacketList));
 if (!this_pktl)
 return AVERROR(ENOMEM);
-if (pkt->flags & AV_PKT_FLAG_UNCODED_FRAME) {
-av_assert0(pkt->size == UNCODED_FRAME_PACKET_SIZE);
-av_assert0(((AVFrame *)pkt->data)->buf);
-} else {
-if ((ret = av_packet_make_refcounted(pkt)) < 0) {
-av_free(this_pktl);
-return ret;
-}
+if ((ret = av_packet_make_refcounted(pkt)) < 0) {
+av_free(this_pktl);
+return ret;
 }
 
 av_packet_move_ref(&this_pktl->pkt, pkt);
@@ -1319,22 +1308,45 @@ int ff_write_chained(AVFormatContext *dst, int 
dst_stream, AVPacket *pkt,
 return ret;
 }
 
+static void uncoded_frame_free(void *unused, uint8_t *data)
+{
+av_frame_free((AVFrame **)data);
+av_free(data);
+}
+
 static int write_uncoded_frame_internal(AVFormatContext *s, int stream_index,
 AVFrame *frame, int interleaved)
 {
 AVPacket pkt, *pktp;
 
 av_assert0(s->oformat);
-if (!s->oformat->write_uncoded_frame)
+if (!s->oformat->write_uncoded_frame) {
+av_frame_free(&frame);
 return AVERROR(ENOSYS);
+}
 
 if (!frame) {
 pktp = NULL;
 } else {
+size_t   bufsize = sizeof(frame) + AV_INPUT_BUFFER_PADDING_SIZE;

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: fix the build failure when hevc_vaapi is disabled

[Andreas Rheinhardt]

Linjie Fu:
> Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
> 
> Failure reported in:
> http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-random
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/vaapi_decode.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 54a0ecb..06916cc 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -383,6 +383,7 @@ static const struct {
> H264ConstrainedBaseline),
>  MAP(H264,H264_MAIN,   H264Main),
>  MAP(H264,H264_HIGH,   H264High),
> +#if CONFIG_HEVC_VAAPI_HWACCEL
>  #if VA_CHECK_VERSION(0, 37, 0)
>  MAP(HEVC,HEVC_MAIN,   HEVCMain),
>  MAP(HEVC,HEVC_MAIN_10,HEVCMain10  ),
> @@ -393,6 +394,7 @@ static const struct {
>  MAP(HEVC,HEVC_REXT,   None,
>   ff_vaapi_parse_hevc_rext_profile ),
>  #endif
> +#endif
>  MAP(MJPEG,   MJPEG_HUFFMAN_BASELINE_DCT,
>JPEGBaseline),
>  MAP(WMV3,VC1_SIMPLE,  VC1Simple   ),
> 
Any more comments? If not, I'll apply this soon (i.e. in a few hours).

- Andreas
___
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 PATCH] RFC -> JPEG-XL: Image format header reader

[Varun Gupta]

Hi everyone,

I made some improvements to the header reader for JPEG-XL, the patch for
which I had submitted earlier.
The improvements include writing separate functions for all the
datatypes to minimize code redundancy.
All this information regarding headers will have to be read in the
parser itself because I won't be able to find the frame end without it.
There is a particular thing that is bothering me and I would like to get
some suggestion from the community regarding that.
How should i handle the case of the reader reading bits beyond the
boundary ?
I have returned an error code for that in the reader implementation but
should I check it everytime I read some bits ?
This would make the code really messy. Please suggest something
regarding this and I'll be happy to include it in my patch.
Thanks
Varun

---
 libavcodec/jpegxl.h | 391 
 libavcodec/jpegxl_parser.h  |  47 
 libavcodec/jpegxl_read_header.c | 340 +++
 3 files changed, 778 insertions(+)
 create mode 100644 libavcodec/jpegxl.h
 create mode 100644 libavcodec/jpegxl_parser.h
 create mode 100644 libavcodec/jpegxl_read_header.c

diff --git a/libavcodec/jpegxl.h b/libavcodec/jpegxl.h
new file mode 100644
index 00..154aab8f61
--- /dev/null
+++ b/libavcodec/jpegxl.h
@@ -0,0 +1,391 @@
+/*
+ * JPEG-XL format definitions
+ * Copyright (c) 2020 Varun Gupta
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * JPEG-XL format definitions.
+ */
+
+#ifndef AVCODEC_JPEGXL_H
+#define AVCODEC_JPEGXL_H
+
+#include "get_bits.h"
+#include 
+
+#define JPEG_XL_SIG_FF0xff
+#define JPEG_XL_SIG_TYPE  0x0a
+
+typedef enum ColourSpace {
+kRGB = 0,
+kGrey,
+kXYB,
+kUnknown,
+kXYZ
+} ColourSpace;
+
+typedef enum Primaries {
+kSRGB = 1,
+kCustomPrimary = 2,
+k2100 = 9,
+kP3 = 11
+} Primaries;
+
+typedef enum RenderingIntent {
+kPerceptual = 0,
+kRelative,
+kSaturation,
+kAbsolute
+} RenderingIntent;
+
+typedef enum WhitePoint {
+kD65 = 1,
+kCustom = 2,
+kE = 10,
+kDCI = 11
+} WhitePoint;
+
+typedef enum TransferFunction {
+k709 = 1,
+kUnknownTransferFunction = 2,
+kLinear = 8,
+kSRGBTransferFunction = 13,
+kPQ = 16,
+kDCITransferFunction = 17,
+kHLG = 18
+} TransferFunction;
+
+typedef struct Customxy {
+int x;
+int y;
+} Customxy;
+
+typedef struct ExtraChannelInfo {
+unsigned int meaning;
+float red;
+float green;
+float blue;
+float solidity;
+} ExtraChannelInfo;
+
+typedef enum JPEGXLHeaderStates {
+JPEGXL_UNDEFINED = 0,
+JPEGXL_SIG,
+JPEGXL_SIZE_HEADER,
+JPEGXL_IMAGE_METADATA,
+JPEGXL_PREVIEW_HEADER,
+JPEGXL_ANIMATION_HEADER,
+JPEGXL_ICC_CODEC,
+JPEGXL_PREVIEW_FRAME,
+JPEGXL_FRAMES
+} jpegxl_header_states;
+
+typedef struct ColourEncoding {
+unsigned int all_default;
+unsigned int received_icc;
+unsigned int opaque_icc;
+ColourSpace colour_space;
+WhitePoint white_point;
+Customxy white;
+Primaries primaries;
+Customxy red;
+Customxy green;
+Customxy blue;
+unsigned int have_gamma;
+unsigned int gamma;
+TransferFunction transfer_function;
+RenderingIntent rendering_intent;
+} ColourEncoding;
+
+typedef struct Extensions {
+unsigned long long extensions;
+unsigned long long extension_bits;
+} Extensions;
+
+typedef struct ImageMetadata2 {
+unsigned int all_default;
+unsigned int have_preview;
+unsigned int have_animation;
+unsigned int orientation_minus_1;
+unsigned int depth_bits;
+unsigned int depth_shift;
+unsigned int num_extra_channels;
+unsigned int extra_channel_bits;
+ExtraChannelInfo* extra_channel_info;
+Extensions extension;
+} ImageMetadata2;
+
+typedef struct SizeHeader {
+unsigned int ysize_div8_minus_1;
+unsigned int ysize_minus_1;
+unsigned int xsize_div8_minus_1;
+unsigned int xsize_minus_1;
+unsigned int xsize;
+unsigned int ysize;
+} SizeHeader;
+
+typedef struct PreviewHeader {
+unsigned int ysize_div8_minus_1;
+unsigned int ysize_minus_1;
+unsigned int xsize_div8_minus_1;
+unsigned int xsize_minus_1;
+unsigned int xsize;
+u

Re: [FFmpeg-devel] [PATCH v3 1/2] avcodec: add adpcm_ima_ssi encoder

[Zane van Iperen]

On Sun, 12 Apr 2020 11:41:40 +0200
"Paul B Mahol"  wrote:

> On 4/12/20, Zane van Iperen  wrote:
> > On Sat, 11 Apr 2020 22:02:26 +0200
> > "Paul B Mahol"  wrote:
> >  
> >> >
> >> > Ping.
> >> >
> >> > Also, could someone please clarify something for me?
> >> >
> >> > When encoding, there's no inherit differences between trellis and
> >> > non-trellis other then a potentially more-accurate set of
> >> > nibbles?
> >> >
> >> > And the decoder is none the wiser and chews on them both the same
> >> > way?
> >> >
> >> > If I'm right, then this looks to be a decoder issue...
> >> >  
> >>
> >> You are wrong, just follow qt adpcm encoder code.
> >>  
> >
> > I did.
> >
> >
> > Is it possible, and I don't suggest this lightly, that the trellis
> > code is bugged, and errors accumulate over time?
> >
> > I ask this because all of the encoders (except adpcm_yamaha, which
> > is different anyway) have either the full sample and/or the step
> > index periodically written to the bitstream, which is then used to
> > reset the state machine, thus errors don't accumulate.
> >
> > adpcm_ima_ssi doesn't have that, so it relies on the state being
> > accurate through the entire stream. This would certainly explain the
> > behaviour I'm seeing in certain cases (see below).
> >
> > In both images, the top stream is encoded with '-trellis 0', and the
> > bottom with '-trellis 1':
> > - https://0x0.st/iSdS.png
> >   This one's obvious where the problem is.
> > - https://0x0.st/iSdQ.png
> >   This is more subtle, but the entire stream is offset slightly.
> > It's more noticeable at the start and end.
> >
> >
> > For reference, here's the code I'm using. You'll see it's basically
> > the same as the adpcm_ima_qt code:
> >
> > if (avctx->trellis > 0) {
> > FF_ALLOC_OR_GOTO(avctx, buf, n * avctx->channels, error);
> >
> > for (ch = 0; ch < avctx->channels; ch++) {
> > adpcm_compress_trellis(avctx, samples + ch, buf + n * ch,
> >c->status + ch, n, avctx->channels);
> > c->status[ch].prev_sample = c->status[ch].predictor;
> > }
> >
> > for (i = 0; i < n; i++) {
> > for (ch = 0; ch < avctx->channels; ch++) {
> > put_bits(&pb, 4, buf[n * ch + i]);
> > }
> > }
> > av_free(buf);
> > }
> >
> >
> > Or maybe I just don't fully understand how trellis works.  
> 
> Yes. that is 100% correct.
> 
> Also you ignored fact that you do not update nodes for SSI variant in
> compress trellis.

I probably should have mentioned that yes, I had already added the
appropriate SSI code to adpcm_compress_trellis().




___
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]lavfi/telecine: Mark telecined frames as interlaced

[Carl Eugen Hoyos]

Am So., 12. Apr. 2020 um 11:35 Uhr schrieb Paul B Mahol :
>
> On 4/12/20, Carl Eugen Hoyos  wrote:
> > Am So., 12. Apr. 2020 um 10:38 Uhr schrieb Paul B Mahol :
> >>
> >> On 4/11/20, Paul B Mahol  wrote:
> >> > On 4/11/20, Carl Eugen Hoyos  wrote:
> >> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
> >> >> :
> >> >>>
> >> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
> >> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
> >> >>> > :
> >> >>> >>
> >> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> >> >>> >> :
> >> >>> >> >
> >> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> >> >>> >> > :
> >> >>> >> > >
> >> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
> >> >>> >> > > :
> >> >>> >> > > >
> >> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> >> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos
> >> >>> >> > > > > :
> >> >>> >> > > > >
> >> >>> >> > > > >> Attached patch marks actually telecined frames as
> >> >>> >> > > > >> interlaced,
> >> >>> >> > > > >> other frames as progressive.
> >> >>> >> > > > >
> >> >>> >> > > > > New patch with changes to fate attached.
> >> >>> >> > > > >
> >> >>> >> > > > > Please comment, Carl Eugen
> >> >>> >> > > >
> >> >>> >> > > > Those yadif tests look wrong. The patch shouldn't affect
> >> >>> >> > > > them.
> >> >>> >> > >
> >> >>> >> > > Clearly, thank you!
> >> >>> >> > >
> >> >>> >> > > New patch attached, it should now only change the telecined
> >> >>> >> > > frames and leave the other frames as they are, the setfield
> >> >>> >> > > filter can be used to force a progressive setting for them.
> >> >>> >> >
> >> >>> >> > New patch attached that also sets top_field_first
> >> >>> >>
> >> >>> >> Which had the effect that fate is correct again, new patch
> >> >>> >> attached.
> >> >>> >
> >> >>> > Patch applied.
> >> >>> >
> >> >>>
> >> >>> This was never approved by me.
> >> >>
> >> >> You reviewed it on irc and correctly pointed out the missing bits.
> >> >
> >> > Lies, I was against that idea from start.
> >> >
> >> >>
> >> >>> So revert it ASAP!
> >> >>
> >> >> What should be changed about it?
> >> >
> >> > Return of code as it was before this pointless change.
> >> > I see no good out of it.
> >>
> >> I gonna revert this ASAP!
> >
> > Could you explain why it is wrong to mark interlaced frames
> > as interlaced?
>
> The frames are not interlaced.

Using the usual 3:2 telecine, the filter outputs two progressive
frames, followed by three interlaced frames, the patch should
mark the interlaced frames as interlaced and I believe it does.

> I thought you knew that interlacing destroys half of data.
> Telecine does not destroys data.

Telecine duplicates some data, leading to interlaced frames.
A (perfect) detecine process can remove the duplicated data
(and the interlaced frames).

Carl Eugen
___
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] OpenColorIO - Google Summer of Code

[Rashil Gandhi]

Hi,

I'm a student applying for Google Summer of Code this year in the
organization Academy Software Foundation. One of the projects that
come under them is OpenColorIO, a color management framework for
visual effects and animation. The project idea that I'd like to work
on is 'Adding OpenColorIO support to FFmpeg', which extends or
modifies FFmpeg so that OpenColorIO could be employed for color
conversion in FFmpeg. More details of which can be found on
https://github.com/AcademySoftwareFoundation/tac/tree/master/gsoc#opencolorio.


Through the medium of this mailing list I'd like to ask the
developers of FFmpeg for their guidance on how such an idea should
be proceeded with. Kindly go through the Project Overview and
Timeline sections of my GSoC proposal here
https://docs.google.com/document/d/17ZxMjNR7cRMtwyxbcb0VzfeEvNizKWbmpFa67zuR4r4/edit?usp=sharing.

It consists of some basic preliminary analysis of how the idea would
be implemented. The support of FFmpeg developers throughout is
fundamental for the project idea.

If this is not the correct place to approach the developers, please
tell me how I can reach out to them.

Regards,
Rashil Gandhi
___
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 1/2] avcodec: add adpcm_ima_ssi encoder

[Paul B Mahol]

On 4/12/20, Zane van Iperen  wrote:
> On Sat, 11 Apr 2020 22:02:26 +0200
> "Paul B Mahol"  wrote:
>
>> >
>> > Ping.
>> >
>> > Also, could someone please clarify something for me?
>> >
>> > When encoding, there's no inherit differences between trellis and
>> > non-trellis other then a potentially more-accurate set of nibbles?
>> >
>> > And the decoder is none the wiser and chews on them both the same
>> > way?
>> >
>> > If I'm right, then this looks to be a decoder issue...
>> >
>>
>> You are wrong, just follow qt adpcm encoder code.
>>
>
> I did.
>
>
> Is it possible, and I don't suggest this lightly, that the trellis code
> is bugged, and errors accumulate over time?
>
> I ask this because all of the encoders (except adpcm_yamaha, which is
> different anyway) have either the full sample and/or the step index
> periodically written to the bitstream, which is then used to reset the
> state machine, thus errors don't accumulate.
>
> adpcm_ima_ssi doesn't have that, so it relies on the state being
> accurate through the entire stream. This would certainly explain the
> behaviour I'm seeing in certain cases (see below).
>
> In both images, the top stream is encoded with '-trellis 0', and the
> bottom with '-trellis 1':
> - https://0x0.st/iSdS.png
>   This one's obvious where the problem is.
> - https://0x0.st/iSdQ.png
>   This is more subtle, but the entire stream is offset slightly. It's
>   more noticeable at the start and end.
>
>
> For reference, here's the code I'm using. You'll see it's basically
> the same as the adpcm_ima_qt code:
>
> if (avctx->trellis > 0) {
> FF_ALLOC_OR_GOTO(avctx, buf, n * avctx->channels, error);
>
> for (ch = 0; ch < avctx->channels; ch++) {
> adpcm_compress_trellis(avctx, samples + ch, buf + n * ch,
>c->status + ch, n, avctx->channels);
> c->status[ch].prev_sample = c->status[ch].predictor;
> }
>
> for (i = 0; i < n; i++) {
> for (ch = 0; ch < avctx->channels; ch++) {
> put_bits(&pb, 4, buf[n * ch + i]);
> }
> }
> av_free(buf);
> }
>
>
> Or maybe I just don't fully understand how trellis works.

Yes. that is 100% correct.

Also you ignored fact that you do not update nodes for SSI variant in
compress trellis.
___
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]lavfi/telecine: Mark telecined frames as interlaced

[Paul B Mahol]

On 4/12/20, Hendrik Leppkes  wrote:
> On Sun, Apr 12, 2020 at 10:38 AM Paul B Mahol  wrote:
>>
>> On 4/11/20, Paul B Mahol  wrote:
>> > On 4/11/20, Carl Eugen Hoyos  wrote:
>> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
>> >> :
>> >>>
>> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
>> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
>> >>> > :
>> >>> >>
>> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
>> >>> >> :
>> >>> >> >
>> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>> >>> >> > :
>> >>> >> > >
>> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
>> >>> >> > > :
>> >>> >> > > >
>> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
>> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos
>> >>> >> > > > > :
>> >>> >> > > > >
>> >>> >> > > > >> Attached patch marks actually telecined frames as
>> >>> >> > > > >> interlaced,
>> >>> >> > > > >> other frames as progressive.
>> >>> >> > > > >
>> >>> >> > > > > New patch with changes to fate attached.
>> >>> >> > > > >
>> >>> >> > > > > Please comment, Carl Eugen
>> >>> >> > > >
>> >>> >> > > > Those yadif tests look wrong. The patch shouldn't affect
>> >>> >> > > > them.
>> >>> >> > >
>> >>> >> > > Clearly, thank you!
>> >>> >> > >
>> >>> >> > > New patch attached, it should now only change the telecined
>> >>> >> > > frames and leave the other frames as they are, the setfield
>> >>> >> > > filter can be used to force a progressive setting for them.
>> >>> >> >
>> >>> >> > New patch attached that also sets top_field_first
>> >>> >>
>> >>> >> Which had the effect that fate is correct again, new patch
>> >>> >> attached.
>> >>> >
>> >>> > Patch applied.
>> >>> >
>> >>>
>> >>> This was never approved by me.
>> >>
>> >> You reviewed it on irc and correctly pointed out the missing bits.
>> >
>> > Lies, I was against that idea from start.
>> >
>> >>
>> >>> So revert it ASAP!
>> >>
>> >> What should be changed about it?
>> >
>> > Return of code as it was before this pointless change.
>> > I see no good out of it.
>>
>> I gonna revert this ASAP!
>
> If you feel the patch is wrong, then you should present technical
> arguments to that purpose. Otherwise, there was plenty time on the ML
> to review it, and you only commented after it was on the ML for over a
> week and commited, despite clearly knowing that it existed.
>

I do not feel. I know that patch is incorrect. And already objected on IRC.
___
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]lavfi/telecine: Mark telecined frames as interlaced

[Paul B Mahol]

On 4/12/20, Carl Eugen Hoyos  wrote:
> Am So., 12. Apr. 2020 um 10:38 Uhr schrieb Paul B Mahol :
>>
>> On 4/11/20, Paul B Mahol  wrote:
>> > On 4/11/20, Carl Eugen Hoyos  wrote:
>> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
>> >> :
>> >>>
>> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
>> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
>> >>> > :
>> >>> >>
>> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
>> >>> >> :
>> >>> >> >
>> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>> >>> >> > :
>> >>> >> > >
>> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
>> >>> >> > > :
>> >>> >> > > >
>> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
>> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos
>> >>> >> > > > > :
>> >>> >> > > > >
>> >>> >> > > > >> Attached patch marks actually telecined frames as
>> >>> >> > > > >> interlaced,
>> >>> >> > > > >> other frames as progressive.
>> >>> >> > > > >
>> >>> >> > > > > New patch with changes to fate attached.
>> >>> >> > > > >
>> >>> >> > > > > Please comment, Carl Eugen
>> >>> >> > > >
>> >>> >> > > > Those yadif tests look wrong. The patch shouldn't affect
>> >>> >> > > > them.
>> >>> >> > >
>> >>> >> > > Clearly, thank you!
>> >>> >> > >
>> >>> >> > > New patch attached, it should now only change the telecined
>> >>> >> > > frames and leave the other frames as they are, the setfield
>> >>> >> > > filter can be used to force a progressive setting for them.
>> >>> >> >
>> >>> >> > New patch attached that also sets top_field_first
>> >>> >>
>> >>> >> Which had the effect that fate is correct again, new patch
>> >>> >> attached.
>> >>> >
>> >>> > Patch applied.
>> >>> >
>> >>>
>> >>> This was never approved by me.
>> >>
>> >> You reviewed it on irc and correctly pointed out the missing bits.
>> >
>> > Lies, I was against that idea from start.
>> >
>> >>
>> >>> So revert it ASAP!
>> >>
>> >> What should be changed about it?
>> >
>> > Return of code as it was before this pointless change.
>> > I see no good out of it.
>>
>> I gonna revert this ASAP!
>
> Could you explain why it is wrong to mark interlaced frames
> as interlaced?

The frames are not interlaced.

I thought you knew that interlacing destroys half of data.
Telecine does not destroys data.
___
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]lavfi/telecine: Mark telecined frames as interlaced

[Hendrik Leppkes]

On Sun, Apr 12, 2020 at 10:38 AM Paul B Mahol  wrote:
>
> On 4/11/20, Paul B Mahol  wrote:
> > On 4/11/20, Carl Eugen Hoyos  wrote:
> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
> >> :
> >>>
> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
> >>> > :
> >>> >>
> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> >>> >> :
> >>> >> >
> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> >>> >> > :
> >>> >> > >
> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
> >>> >> > > :
> >>> >> > > >
> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos
> >>> >> > > > > :
> >>> >> > > > >
> >>> >> > > > >> Attached patch marks actually telecined frames as
> >>> >> > > > >> interlaced,
> >>> >> > > > >> other frames as progressive.
> >>> >> > > > >
> >>> >> > > > > New patch with changes to fate attached.
> >>> >> > > > >
> >>> >> > > > > Please comment, Carl Eugen
> >>> >> > > >
> >>> >> > > > Those yadif tests look wrong. The patch shouldn't affect them.
> >>> >> > >
> >>> >> > > Clearly, thank you!
> >>> >> > >
> >>> >> > > New patch attached, it should now only change the telecined
> >>> >> > > frames and leave the other frames as they are, the setfield
> >>> >> > > filter can be used to force a progressive setting for them.
> >>> >> >
> >>> >> > New patch attached that also sets top_field_first
> >>> >>
> >>> >> Which had the effect that fate is correct again, new patch attached.
> >>> >
> >>> > Patch applied.
> >>> >
> >>>
> >>> This was never approved by me.
> >>
> >> You reviewed it on irc and correctly pointed out the missing bits.
> >
> > Lies, I was against that idea from start.
> >
> >>
> >>> So revert it ASAP!
> >>
> >> What should be changed about it?
> >
> > Return of code as it was before this pointless change.
> > I see no good out of it.
>
> I gonna revert this ASAP!

If you feel the patch is wrong, then you should present technical
arguments to that purpose. Otherwise, there was plenty time on the ML
to review it, and you only commented after it was on the ML for over a
week and commited, despite clearly knowing that it existed.

- Hendrik
___
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]lavfi/telecine: Mark telecined frames as interlaced

[Carl Eugen Hoyos]

Am So., 12. Apr. 2020 um 10:38 Uhr schrieb Paul B Mahol :
>
> On 4/11/20, Paul B Mahol  wrote:
> > On 4/11/20, Carl Eugen Hoyos  wrote:
> >> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
> >> :
> >>>
> >>> On 4/11/20, Carl Eugen Hoyos  wrote:
> >>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
> >>> > :
> >>> >>
> >>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> >>> >> :
> >>> >> >
> >>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> >>> >> > :
> >>> >> > >
> >>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
> >>> >> > > :
> >>> >> > > >
> >>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> >>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos
> >>> >> > > > > :
> >>> >> > > > >
> >>> >> > > > >> Attached patch marks actually telecined frames as
> >>> >> > > > >> interlaced,
> >>> >> > > > >> other frames as progressive.
> >>> >> > > > >
> >>> >> > > > > New patch with changes to fate attached.
> >>> >> > > > >
> >>> >> > > > > Please comment, Carl Eugen
> >>> >> > > >
> >>> >> > > > Those yadif tests look wrong. The patch shouldn't affect them.
> >>> >> > >
> >>> >> > > Clearly, thank you!
> >>> >> > >
> >>> >> > > New patch attached, it should now only change the telecined
> >>> >> > > frames and leave the other frames as they are, the setfield
> >>> >> > > filter can be used to force a progressive setting for them.
> >>> >> >
> >>> >> > New patch attached that also sets top_field_first
> >>> >>
> >>> >> Which had the effect that fate is correct again, new patch attached.
> >>> >
> >>> > Patch applied.
> >>> >
> >>>
> >>> This was never approved by me.
> >>
> >> You reviewed it on irc and correctly pointed out the missing bits.
> >
> > Lies, I was against that idea from start.
> >
> >>
> >>> So revert it ASAP!
> >>
> >> What should be changed about it?
> >
> > Return of code as it was before this pointless change.
> > I see no good out of it.
>
> I gonna revert this ASAP!

Could you explain why it is wrong to mark interlaced frames
as interlaced?
Or do you believe that progressive frames are marked interlaced?
Or should other frames be marked as progressive?

Carl Eugen
___
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 1/2] avcodec: add adpcm_ima_ssi encoder

[Zane van Iperen]

On Sat, 11 Apr 2020 22:02:26 +0200
"Paul B Mahol"  wrote:

> >
> > Ping.
> >
> > Also, could someone please clarify something for me?
> >
> > When encoding, there's no inherit differences between trellis and
> > non-trellis other then a potentially more-accurate set of nibbles?
> >
> > And the decoder is none the wiser and chews on them both the same
> > way?
> >
> > If I'm right, then this looks to be a decoder issue...
> >  
> 
> You are wrong, just follow qt adpcm encoder code.
> 

I did.


Is it possible, and I don't suggest this lightly, that the trellis code
is bugged, and errors accumulate over time?

I ask this because all of the encoders (except adpcm_yamaha, which is
different anyway) have either the full sample and/or the step index
periodically written to the bitstream, which is then used to reset the
state machine, thus errors don't accumulate.

adpcm_ima_ssi doesn't have that, so it relies on the state being
accurate through the entire stream. This would certainly explain the
behaviour I'm seeing in certain cases (see below).

In both images, the top stream is encoded with '-trellis 0', and the
bottom with '-trellis 1':
- https://0x0.st/iSdS.png
  This one's obvious where the problem is.
- https://0x0.st/iSdQ.png
  This is more subtle, but the entire stream is offset slightly. It's
  more noticeable at the start and end.


For reference, here's the code I'm using. You'll see it's basically
the same as the adpcm_ima_qt code:

if (avctx->trellis > 0) {
FF_ALLOC_OR_GOTO(avctx, buf, n * avctx->channels, error);

for (ch = 0; ch < avctx->channels; ch++) {
adpcm_compress_trellis(avctx, samples + ch, buf + n * ch,
   c->status + ch, n, avctx->channels);
c->status[ch].prev_sample = c->status[ch].predictor;
}

for (i = 0; i < n; i++) {
for (ch = 0; ch < avctx->channels; ch++) {
put_bits(&pb, 4, buf[n * ch + i]);
}
}
av_free(buf);
}


Or maybe I just don't fully understand how trellis works.

Zane



___
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]lavfi/telecine: Mark telecined frames as interlaced

[Paul B Mahol]

On 4/11/20, Paul B Mahol  wrote:
> On 4/11/20, Carl Eugen Hoyos  wrote:
>> Am Sa., 11. Apr. 2020 um 15:10 Uhr schrieb Paul B Mahol
>> :
>>>
>>> On 4/11/20, Carl Eugen Hoyos  wrote:
>>> > Am So., 5. Apr. 2020 um 02:05 Uhr schrieb Carl Eugen Hoyos
>>> > :
>>> >>
>>> >> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
>>> >> :
>>> >> >
>>> >> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
>>> >> > :
>>> >> > >
>>> >> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer
>>> >> > > :
>>> >> > > >
>>> >> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
>>> >> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos
>>> >> > > > > :
>>> >> > > > >
>>> >> > > > >> Attached patch marks actually telecined frames as
>>> >> > > > >> interlaced,
>>> >> > > > >> other frames as progressive.
>>> >> > > > >
>>> >> > > > > New patch with changes to fate attached.
>>> >> > > > >
>>> >> > > > > Please comment, Carl Eugen
>>> >> > > >
>>> >> > > > Those yadif tests look wrong. The patch shouldn't affect them.
>>> >> > >
>>> >> > > Clearly, thank you!
>>> >> > >
>>> >> > > New patch attached, it should now only change the telecined
>>> >> > > frames and leave the other frames as they are, the setfield
>>> >> > > filter can be used to force a progressive setting for them.
>>> >> >
>>> >> > New patch attached that also sets top_field_first
>>> >>
>>> >> Which had the effect that fate is correct again, new patch attached.
>>> >
>>> > Patch applied.
>>> >
>>>
>>> This was never approved by me.
>>
>> You reviewed it on irc and correctly pointed out the missing bits.
>
> Lies, I was against that idea from start.
>
>>
>>> So revert it ASAP!
>>
>> What should be changed about it?
>
> Return of code as it was before this pointless change.
> I see no good out of it.

I gonna revert this ASAP!
___
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".