Re: [FFmpeg-devel] [PATCH v3] avformat/dashdec: fix memleak for commit commit e134c203

[Steven Liu]

> 2020年3月26日 下午11:46，Nicolas George  写道：
> 
> Steven Liu (12020-03-24):
>> These member will be used for get more correct information of the MPD
>> 
>> Suggested-by: Andreas Rheinhardt 
>> Suggested-by: Nicolas George 
>> Signed-off-by: Steven Liu 
>> ---
>> libavformat/dashdec.c | 244 --
>> 1 file changed, 214 insertions(+), 30 deletions(-)
>> 
>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>> index 5bbe5d3985..b5bb8e674c 100644
>> --- a/libavformat/dashdec.c
>> +++ b/libavformat/dashdec.c
>> @@ -108,6 +108,7 @@ struct representation {
>> int64_t cur_seg_offset;
>> int64_t cur_seg_size;
>> struct fragment *cur_seg;
>> +char *lang;
>> 
>> /* Currently active Media Initialization Section */
>> struct fragment *init_section;
>> @@ -122,19 +123,15 @@ struct representation {
>> typedef struct DASHContext {
>> const AVClass *class;
>> char *base_url;
>> -char *adaptionset_contenttype_val;
>> -char *adaptionset_par_val;
>> -char *adaptionset_lang_val;
>> -char *adaptionset_minbw_val;
>> -char *adaptionset_maxbw_val;
>> -char *adaptionset_minwidth_val;
>> -char *adaptionset_maxwidth_val;
>> -char *adaptionset_minheight_val;
>> -char *adaptionset_maxheight_val;
>> -char *adaptionset_minframerate_val;
>> -char *adaptionset_maxframerate_val;
>> -char *adaptionset_segmentalignment_val;
>> -char *adaptionset_bitstreamswitching_val;
>> +char *adaptionset_lang;
>> +uint64_t adaptionset_minbw;
>> +uint64_t adaptionset_maxbw;
>> +uint64_t adaptionset_minwidth;
>> +uint64_t adaptionset_maxwidth;
>> +uint64_t adaptionset_minheight;
>> +uint64_t adaptionset_maxheight;
>> +AVRational adaptionset_minframerate;
>> +AVRational adaptionset_maxframerate;
>> 
>> int n_videos;
>> struct representation **videos;
>> @@ -169,6 +166,79 @@ typedef struct DASHContext {
>> 
>> } DASHContext;
>> 
> 
>> +static int get_ratio_from_string(AVRational *dst, char *src)
> 
> const char *
Ok, will modify it.
> 
>> +{
> 
>> +char *p = src;
> 
> Not useful.
> 
>> +char *end = NULL;
>> +char *end_ptr = NULL;
>> +int num, den;
>> +
> 
>> +num = (int)strtol(p, &end_ptr, 10);
> 
> Possible integer overflow.
Ok, will modify it . I should add range of the value check. 
> 
>> +if (errno == ERANGE || end_ptr == src) {
>> +return AVERROR_INVALIDDATA;
>> +}
> 
> Unnecessary braces.
Ok, will modify it.
> 
>> +
>> +if (end_ptr[0] == '\0') {
>> +dst->den = 1;
>> +dst->num = num;
>> +return 0;
>> +}
>> +
>> +if (end_ptr[0] != '/')
>> +return AVERROR_INVALIDDATA;
> 
>> +p = end_ptr + 1;
> 
> Not useful.
Do you mean I should use end_ptr++ ?
> 
>> +den = (int)strtol(p, &end, 10);
> 
> Possible integer overflow.
Ok, will modify it . I should add range of the value check. 

> 
>> +if (errno == ERANGE || end == src) {
> 
>> +dst->den = 1;
> 
> Why?
For example:
32000/goodmorning
This is wrong framerate, and the Denominator is init to 0, so set it 1 here, 
because n/0 is incorrect.
> 
>> +return AVERROR_INVALIDDATA;
>> +}
>> +dst->den = den;
>> +
>> +return 0;
>> +}
>> +
> 
>> +static uint64_t dash_prop_get_int64(AVFormatContext *s, xmlNodePtr node, 
>> uint64_t *dst, const char *key)
> 
> The return type does not work.
Ok, will modify it.
> 
>> +{
>> +char *end_ptr = NULL;
>> +char *val = xmlGetProp(node, key);
>> +int ret = 0;
>> +
>> +if (val) {
> 
>> +ret = strtoull(val, &end_ptr, 10);
> 
> Can't store unsigned long long into int.
Ok, will modify it.
> 
>> +if (errno == ERANGE) {
>> +av_log(s, AV_LOG_WARNING, "overflow/underflow when get value of 
>> %s\n", key);
>> +xmlFree(val);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +if (end_ptr == val || end_ptr[0] != '\0') {
>> +av_log(s, AV_LOG_ERROR, "The %s field value is "
>> +"not a valid number: %s\n", key, val);
>> +xmlFree(val);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +*dst = ret;
>> +xmlFree(val);
>> +}
>> +return ret;
>> +}
>> +
>> +static int dash_get_prop_ratio(AVFormatContext *s, xmlNodePtr node, 
>> AVRational *member, const char *key)
>> +{
>> +char *val = xmlGetProp(node, key);
>> +int ret = 0;
>> +AVRational rate;
>> +
>> +if (val) {
>> +ret = get_ratio_from_string(&rate, val);
>> +if (ret < 0)
>> +av_log(s, AV_LOG_WARNING, "Ignoring invalid %s frame rate 
>> '%s'\n", key, val);
>> +xmlFree(val);
>> +}
>> +member->num = rate.num;
>> +member->den = rate.den;
>> +return ret;
>> +}
>> +
>> static int ishttp(char *url)
>> {
>> const char *proto_name = avio_find_protocol_name(url);
>> @@ -885,6 +955,15 @@ static int 
>> parse_manifest_representation(AVFormatContext *s, const char *ur

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/avpacket: Always treat dst in av_packet_ref as uninitialized

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-02-12 16:02:21)
>> av_packet_ref() mostly treated the destination packet dst as uninitialized,
>> i.e. the destination fields were simply overwritten. But if the source
>> packet was not reference-counted, dst->buf was treated as if it pointed
>> to an already allocated buffer (if != NULL) to be reallocated to the
>> desired size.
>>
>> The documentation did not explicitly state whether the dst will be treated
>> as uninitialized, but it stated that if the source packet is not refcounted,
>> a new buffer in dst will be allocated. This and the fact that the side-data
>> as well as the codepath taken in case src is refcounted always treated the
>> packet as uninitialized means that dst should always be treated as
>> uninitialized for the sake of consistency. And this behaviour has been
>> explicitly documented.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/avcodec.h  | 2 +-
>>  libavcodec/avpacket.c | 1 +
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index dc5807324f..982a545dc6 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -4600,7 +4600,7 @@ void av_packet_free_side_data(AVPacket *pkt);
>>   *
>>   * @see av_packet_unref
>>   *
>> - * @param dst Destination packet
>> + * @param dst Destination packet. Will be treated as initially 
>> uninitialized.
> 
> The 'initially' sounds weird to me. How about "Will be completely
> overwritten"?
> 
Changed.

>>   * @param src Source packet
>>   *
>>   * @return 0 on success, a negative AVERROR on error.
>> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
>> index 74845efcd2..0d9ddeee07 100644
>> --- a/libavcodec/avpacket.c
>> +++ b/libavcodec/avpacket.c
>> @@ -614,6 +614,7 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src)
>>  return ret;
>>  
>>  if (!src->buf) {
>> +dst->buf = NULL;
>>  ret = packet_alloc(&dst->buf, src->size);
>>  if (ret < 0)
>>  goto fail;
>> -- 
>> 2.20.1
> 
> weak sugestion - perhaps it'd be clearer to just add a call to
> av_init_packet() to the beginning of that function

It's unnecessary on success, but I have added it on failure in [1].
> 
> Also, we might want to finally forbid non-refcounted packets completely.
> 
Then you might want to take a look at [2].

- Andreas

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259083.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/253662.html

___
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] avcodec/avcodec, avpacket: Return blank packet on av_packet_ref() failure

[Andreas Rheinhardt]

Up until now, it was completely unspecified what the content of the
destination packet dst was on error. Depending upon where the error
happened calling av_packet_unref() on dst might be dangerous.

This commit changes this by making sure that dst is blank on error, so
unreferencing it again is safe (and still pointless). This behaviour is
documented.

Signed-off-by: Andreas Rheinhardt 
---
 doc/APIchanges| 4 
 libavcodec/avcodec.h  | 3 ++-
 libavcodec/avpacket.c | 7 ---
 libavcodec/version.h  | 2 +-
 4 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 8eeaec2028..f2bb2d242b 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2020-03-27 - xx - lavc 58.77.100 - avcodec.h
+  av_packet_ref() now guarantees to return the destination packet
+  in a blank state on error.
+
 2020-03-10 - xx - lavc 58.75.100 - avcodec.h
   Add AV_PKT_DATA_ICC_PROFILE.
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index f918d20a61..8fc0ad92c9 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4651,7 +4651,8 @@ void av_packet_free_side_data(AVPacket *pkt);
  * @param dst Destination packet. Will be completely overwritten.
  * @param src Source packet
  *
- * @return 0 on success, a negative AVERROR on error.
+ * @return 0 on success, a negative AVERROR on error. On error, dst
+ * will be blank (as if returned by av_packet_alloc()).
  */
 int av_packet_ref(AVPacket *dst, const AVPacket *src);
 
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 132567bc2d..c622718a45 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -610,12 +610,13 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src)
 {
 int ret;
 
+dst->buf = NULL;
+
 ret = av_packet_copy_props(dst, src);
 if (ret < 0)
-return ret;
+goto fail;
 
 if (!src->buf) {
-dst->buf = NULL;
 ret = packet_alloc(&dst->buf, src->size);
 if (ret < 0)
 goto fail;
@@ -637,7 +638,7 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src)
 
 return 0;
 fail:
-av_packet_free_side_data(dst);
+av_packet_unref(dst);
 return ret;
 }
 
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 1f19b67adc..7e01d9526f 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  58
-#define LIBAVCODEC_VERSION_MINOR  76
+#define LIBAVCODEC_VERSION_MINOR  77
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
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 v2 1/2] avcodec/avpacket: Always treat dst in av_packet_ref as uninitialized

[Andreas Rheinhardt]

av_packet_ref() mostly treated the destination packet dst as uninitialized,
i.e. the destination fields were simply overwritten. But if the source
packet was not reference-counted, dst->buf was treated as if it pointed
to an already allocated buffer (if != NULL) to be reallocated to the
desired size.

The documentation did not explicitly state whether the dst will be treated
as uninitialized, but it stated that if the source packet is not refcounted,
a new buffer in dst will be allocated. This and the fact that the side-data
as well as the codepath taken in case src is refcounted always treated the
packet as uninitialized means that dst should always be treated as
uninitialized for the sake of consistency. And this behaviour has been
explicitly documented.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/avcodec.h  | 2 +-
 libavcodec/avpacket.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 78c483c25c..f918d20a61 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4648,7 +4648,7 @@ void av_packet_free_side_data(AVPacket *pkt);
  *
  * @see av_packet_unref
  *
- * @param dst Destination packet
+ * @param dst Destination packet. Will be completely overwritten.
  * @param src Source packet
  *
  * @return 0 on success, a negative AVERROR on error.
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index b5667659fd..132567bc2d 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -615,6 +615,7 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src)
 return ret;
 
 if (!src->buf) {
+dst->buf = NULL;
 ret = packet_alloc(&dst->buf, src->size);
 if (ret < 0)
 goto fail;
-- 
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] lavc/v4l2_m2m_dec: Init reserved bytes to zero before ioctl call

[Andriy Gelman]

On Thu, 12. Mar 22:40, Andriy Gelman wrote:
> On Sun, 08. Mar 11:49, Andriy Gelman wrote:
> > From: Andriy Gelman 
> > 
> > struct v4l2_selection contains reserved bytes which should be set to
> > zero before the ioctl call.
> > 
> > Fixes valgrind error:
> > Syscall param ioctl(VKI_V4L2_S_SELECTION) points to uninitialised byte(s)
> > 
> > Signed-off-by: Andriy Gelman 
> > ---
> >  libavcodec/v4l2_m2m_dec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> > index d666edffe46..c5ee86b9935 100644
> > --- a/libavcodec/v4l2_m2m_dec.c
> > +++ b/libavcodec/v4l2_m2m_dec.c
> > @@ -39,7 +39,7 @@ static int v4l2_try_start(AVCodecContext *avctx)
> >  V4L2m2mContext *s = ((V4L2m2mPriv*)avctx->priv_data)->context;
> >  V4L2Context *const capture = &s->capture;
> >  V4L2Context *const output = &s->output;
> > -struct v4l2_selection selection;
> > +struct v4l2_selection selection = { 0 };
> >  int ret;
> >  
> >  /* 1. start the output process */
> > -- 
> > 2.25.0
> > 
> 
> ping
> 

ping

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

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

Re: [FFmpeg-devel] [PATCH v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet

[Michael Niedermayer]

On Thu, Mar 26, 2020 at 10:47:37AM +0100, Anton Khirnov wrote:
> Quoting Andreas Rheinhardt (2020-03-20 17:51:41)
> > Jan Ekström:
> > > On Fri, Mar 20, 2020 at 5:45 PM  wrote:
> > >>
> > >> From: Limin Wang 
> > >>
> > >> This fixes webvtt segment output.
> > >>
> > >> Please testing with the following command and check the output:
> > >> ./ffmpeg -i ../fate-suite/sub/MicroDVD_capability_tester.srt -f segment 
> > >> -segment_time 10 \
> > >> -segment_list_size 0  -segment_list sub.m3u8 -segment_format webvtt 
> > >> -scodec webvtt sub-%d.vtt
> > >>
> > >>
> > >> Signed-off-by: Limin Wang 
> > >> ---
> > >>  fftools/ffmpeg.c |  1 +
> > >>  tests/ref/fate/binsub-movtextenc |  2 +-
> > >>  tests/ref/fate/sub2video | 86 
> > >>  3 files changed, 45 insertions(+), 44 deletions(-)
> > >>
> > >> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > >> index aaaf241314..c5a2d0731d 100644
> > >> --- a/fftools/ffmpeg.c
> > >> +++ b/fftools/ffmpeg.c
> > >> @@ -1054,6 +1054,7 @@ static void do_subtitle_out(OutputFile *of,
> > >>  else
> > >>  pkt.pts += av_rescale_q(sub->end_display_time, 
> > >> (AVRational){ 1, 1000 }, ost->mux_timebase);
> > >>  }
> > >> +pkt.flags |= AV_PKT_FLAG_KEY;
> > >>  pkt.dts = pkt.pts;
> > >>  output_packet(of, &pkt, ost, 0);
> > >>  }
> > > 
> > > I do wonder if this is just a case of people forgetting to set the
> > > flag for the relevant packets in the relevant modules?
> > > 
> > > I'm not sure if all API users should be forced to handle this
> > > separately. If the packets are decode'able by themselves, they should
> > > be marked as such.
> > > 
> > > (Unfortunately, this probably means that all subtitle encoders and
> > > text-based subtitle format demuxers would have to be updated where
> > > this flag is not set)
> > > 
> > av_read_frame() already sets the AV_PKT_FLAG_KEY-flag for all subtitle
> > packets (see is_intra_only() in libavformat/utils.c; the subtitle
> > demuxer based around FFDemuxSubtitlesQueues actually have the flag set
> > even before it reaches is_intra_only()). One could do something similar
> > in libavformat/mux.c.
> > But are we actually sure that all subtitle packets are decodable by
> > themselves? IIRC this is not true for all PGS subtitles.
> > 
> > - Andreas
> > 
> > PS: The semantics of the AV_CODEC_PROP_INTRA_ONLY-flag seem to be based
> > around the assumption that subtitle packets are always intra-only: It is
> > only for video and audio-codecs only.
> 
> I would interpret it as simply not being defined for subtitles, rather
> than saying they are all always intra only. So we can always add new
> semantics for subtitles to it.

+1

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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 v1 1/2] avfilter/vf_showinfo: check if the s12m data size is valid

[Michael Niedermayer]

On Wed, Mar 25, 2020 at 06:45:47PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  libavfilter/vf_showinfo.c | 4 
>  1 file changed, 4 insertions(+)

will apply

thx

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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] libavcodec/jpeg2000.h: fix comments for JPEG2000 markers

[Michael Niedermayer]

On Wed, Mar 25, 2020 at 06:48:44PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan 
> 
> The comments for some of the markers were incorrect.
> This patch fixes the comments associated with the markers.
> ---
>  libavcodec/jpeg2000.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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]configure: Get the correct ident for clang-cl.exe

[Carl Eugen Hoyos]

Am Do., 26. März 2020 um 11:30 Uhr schrieb Martin Storsjö :
>
> On Thu, 26 Mar 2020, Carl Eugen Hoyos wrote:
>
> > Hi!
> >
> > Attached patch avoids that ffmpeg claims its compiler was "No input
> > file" when using clang-cl.
> >
> > Please comment, Carl Eugen
>
> > @@ -4663,7 +4663,11 @@ probe_cc(){
> >  _ld_path='-libpath:'
> >  elif $_cc -nologo- 2>&1 | grep -q Microsoft || { $_cc -v 2>&1 |
> grep -q clang && $_cc -? > /dev/null 2>&1; }; then
> >  _type=msvc
> > -_ident=$($_cc 2>&1 | head -n1 | tr -d '\r')
> > +if $_cc -nologo- 2>&1 | grep -q Microsoft; then
> > +_ident=$($_cc 2>&1 | head -n1 | tr -d '\r')
> > +else
> > +_ident=$($_cc --version 2>/dev/null | head -n1)
>
> The change looks good to me, but isn't "tr -d '\r'" (potentially) needed
> here as well?

Applied with that change.

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]configure: Remove all C standard versions from the MSVC command line

[Carl Eugen Hoyos]

Am Do., 26. März 2020 um 11:29 Uhr schrieb Martin Storsjö :
>
> On Thu, 26 Mar 2020, Carl Eugen Hoyos wrote:
>
> > Hi!
> >
> > Attached patch removes an ugly warning shown for every file when using
> > clang-cl.exe.
> >
> > Please comment, Carl Eugen
>
> LGTM

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] [PATCH 2/3 v2] avcodec/encode: restructure the old encode API

[James Almer]

On 3/26/2020 4:42 PM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-26 20:28:12)
>> On 3/26/2020 5:57 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2020-03-16 22:30:01)
 Following the same logic as 061a0c14bb, this commit turns the old encode 
 API
 into a wrapper for the new one.

 Signed-off-by: James Almer 
 ---
 This could be squashed with the previous commit, like it was done in 
 061a0c14bb,
 but i figured it would be easier to review this way.

  libavcodec/encode.c   | 364 +-
  libavcodec/internal.h |   1 +
  libavcodec/utils.c|   8 +
  3 files changed, 116 insertions(+), 257 deletions(-)

 diff --git a/libavcodec/encode.c b/libavcodec/encode.c
 index cdea1c6c1e..0fdb9e2df2 100644
 --- a/libavcodec/encode.c
 +++ b/libavcodec/encode.c
 @@ -610,3 +361,102 @@ int attribute_align_arg 
 avcodec_receive_packet(AVCodecContext *avctx, AVPacket *
  
  return 0;
  }
 +
 +static int compat_encode(AVCodecContext *avctx, AVPacket *avpkt,
 + int *got_packet, const AVFrame *frame)
 +{
 +AVCodecInternal *avci = avctx->internal;
 +AVPacket user_pkt;
 +int ret;
 +
 +*got_packet = 0;
 +
 +if (frame && avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
 +if (frame->format == AV_PIX_FMT_NONE)
 +av_log(avctx, AV_LOG_WARNING, "AVFrame.format is not set\n");
 +if (frame->width == 0 || frame->height == 0)
 +av_log(avctx, AV_LOG_WARNING, "AVFrame.width or height is not 
 set\n");
 +}
 +
 +ret = avcodec_send_frame(avctx, frame);
 +if (ret == AVERROR_EOF)
 +ret = 0;
 +else if (ret == AVERROR(EAGAIN)) {
 +/* we fully drain all the output in each encode call, so this 
 should not
 + * ever happen */
 +return AVERROR_BUG;
 +} else if (ret < 0)
 +return ret;
 +
 +av_packet_move_ref(&user_pkt, avpkt);
 +while (ret >= 0) {
 +ret = avcodec_receive_packet(avctx, avpkt);
 +if (ret < 0) {
 +if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
 +ret = 0;
 +goto finish;
 +}
 +
 +if (avpkt != avci->compat_encode_packet) {
 +if (avpkt->data && user_pkt.data) {
 +if (user_pkt.size >= avpkt->size) {
 +memcpy(user_pkt.data, avpkt->data, avpkt->size);
 +av_buffer_unref(&avpkt->buf);
 +avpkt->buf  = user_pkt.buf;
 +avpkt->data = user_pkt.data;
 +av_init_packet(&user_pkt);
 +} else {
 +av_log(avctx, AV_LOG_ERROR, "Provided packet is too 
 small, needs to be %d\n", avpkt->size);
 +ret = AVERROR(EINVAL);
 +goto finish;
>>>
>>> Shouldn't the packet be unreffed somewhere in this block?
>>
>> Yeah. Fixed locally.
>>
>>>
 +}
 +}
 +
 +*got_packet = 1;
 +avpkt = avci->compat_encode_packet;
 +} else {
 +if (!avci->compat_decode_warned) {
 +av_log(avctx, AV_LOG_WARNING, "The deprecated 
 avcodec_encode_* "
 +   "API cannot return all the packets for this 
 encoder. "
 +   "Some packets will be dropped. Update your code to 
 the "
 +   "new encoding API to fix this.\n");
 +avci->compat_decode_warned = 1;
 +}
>>>
>>> Same.
>>
>> avpkt is avci->compat_encode_packet in this block. It will either be
>> unreffed next time avcodec_receive_packet() is called with it, or by
>> avcodec_close(). No need to unref it here explicitly, but i can do it if
>> you prefer that.
> 
> I think it's better not to leave data we're not going to use just lying
> around for no reason. So yeah, I'd prefer it to be unreffed here.

Ok, added and the updated set sent.
___
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 03/21] avformat/mpeg: Remove unnecessary av_packet_unref()

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-22 04:47:38)
>> Forgotten in 6a67d518.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavformat/mpeg.c | 8 ++--
>>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> Looks ok
> 
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 02/21] avformat/yop: Use av_packet_move_ref() for packet ownership transfer

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-22 04:47:37)
>> Also return 0 after successfully reading a packet.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavformat/yop.c | 9 +++--
>>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> ok
> 
Thanks, applied.

- 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 01/21] avformat/nsvdec: Use av_packet_move_ref() for packet ownership transfer

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-22 04:47:36)
>> Also simply return 0 in case a packet has been successfully read.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavformat/nsvdec.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> Looks ok.
> 
Thanks, applied.

- 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 1/2 v3] avcodec/encode: restructure the core encoding code

[James Almer]

This commit follows the same logic as 061a0c14bb, but for the encode API: The
new public encoding API will no longer be a wrapper around the old deprecated
one, and the internal API used by the encoders now consists of a single
receive_packet() callback that pulls frames as required.

Signed-off-by: James Almer 
---
 libavcodec/avcodec.h  |  12 +-
 libavcodec/decode.c   |   1 -
 libavcodec/encode.c   | 282 --
 libavcodec/encode.h   |  39 ++
 libavcodec/internal.h |   7 +-
 libavcodec/utils.c|  10 +-
 6 files changed, 272 insertions(+), 79 deletions(-)
 create mode 100644 libavcodec/encode.h

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 78c483c25c..9e41321772 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3653,14 +3653,10 @@ typedef struct AVCodec {
 int (*decode)(AVCodecContext *, void *outdata, int *outdata_size, AVPacket 
*avpkt);
 int (*close)(AVCodecContext *);
 /**
- * Encode API with decoupled packet/frame dataflow. The API is the
- * same as the avcodec_ prefixed APIs (avcodec_send_frame() etc.), except
- * that:
- * - never called if the codec is closed or the wrong type,
- * - if AV_CODEC_CAP_DELAY is not set, drain frames are never sent,
- * - only one drain frame is ever passed down,
- */
-int (*send_frame)(AVCodecContext *avctx, const AVFrame *frame);
+ * Encode API with decoupled frame/packet dataflow. This function is called
+ * to get one output packet. It should call ff_encode_get_frame() to obtain
+ * input data.
+ */
 int (*receive_packet)(AVCodecContext *avctx, AVPacket *avpkt);
 
 /**
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index af6bb3f952..22f0f8acb0 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -2039,7 +2039,6 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
 av_frame_unref(avci->buffer_frame);
 av_frame_unref(avci->compat_decode_frame);
 av_packet_unref(avci->buffer_pkt);
-avci->buffer_pkt_valid = 0;
 
 av_packet_unref(avci->ds.in_pkt);
 
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 9ed2cf0f59..4856f41635 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -26,6 +26,7 @@
 #include "libavutil/samplefmt.h"
 
 #include "avcodec.h"
+#include "encode.h"
 #include "frame_thread_encoder.h"
 #include "internal.h"
 
@@ -78,14 +79,10 @@ int ff_alloc_packet(AVPacket *avpkt, int size)
 /**
  * Pad last frame with silence.
  */
-static int pad_last_frame(AVCodecContext *s, AVFrame **dst, const AVFrame *src)
+static int pad_last_frame(AVCodecContext *s, AVFrame *frame, const AVFrame 
*src)
 {
-AVFrame *frame = NULL;
 int ret;
 
-if (!(frame = av_frame_alloc()))
-return AVERROR(ENOMEM);
-
 frame->format = src->format;
 frame->channel_layout = src->channel_layout;
 frame->channels   = src->channels;
@@ -106,12 +103,10 @@ static int pad_last_frame(AVCodecContext *s, AVFrame 
**dst, const AVFrame *src)
   s->channels, s->sample_fmt)) < 0)
 goto fail;
 
-*dst = frame;
-
 return 0;
 
 fail:
-av_frame_free(&frame);
+av_frame_unref(frame);
 return ret;
 }
 
@@ -182,7 +177,11 @@ int attribute_align_arg 
avcodec_encode_audio2(AVCodecContext *avctx,
 }
 
 if (frame->nb_samples < avctx->frame_size) {
-ret = pad_last_frame(avctx, &padded_frame, frame);
+if (!(padded_frame = av_frame_alloc())) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
+ret = pad_last_frame(avctx, padded_frame, frame);
 if (ret < 0)
 goto end;
 
@@ -359,101 +358,248 @@ int avcodec_encode_subtitle(AVCodecContext *avctx, 
uint8_t *buf, int buf_size,
 return ret;
 }
 
-static int do_encode(AVCodecContext *avctx, const AVFrame *frame, int 
*got_packet)
+int ff_encode_get_frame(AVCodecContext *avctx, AVFrame *frame)
 {
+AVCodecInternal *avci = avctx->internal;
+
+if (avci->draining)
+return AVERROR_EOF;
+
+if (!avci->buffer_frame->buf[0])
+return AVERROR(EAGAIN);
+
+av_frame_move_ref(frame, avci->buffer_frame);
+
+return 0;
+}
+
+static int encode_simple_internal(AVCodecContext *avctx, AVPacket *avpkt)
+{
+AVCodecInternal   *avci = avctx->internal;
+EncodeSimpleContext *es = &avci->es;
+AVFrame  *frame = es->in_frame;
+int got_packet;
 int ret;
-*got_packet = 0;
 
-av_packet_unref(avctx->internal->buffer_pkt);
-avctx->internal->buffer_pkt_valid = 0;
+if (avci->draining_done)
+return AVERROR_EOF;
 
-if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
-ret = avcodec_encode_video2(avctx, avctx->internal->buffer_pkt,
-frame, got_packet);
-} else if (avctx->codec_type == AVMEDIA_TYPE_AUDIO) {
-ret = avcodec_encode_au

[FFmpeg-devel] [PATCH 2/2 v3] avcodec/encode: restructure the old encode API

[James Almer]

Following the same logic as 061a0c14bb, this commit turns the old encode API
into a wrapper for the new one.

Signed-off-by: James Almer 
---
 libavcodec/encode.c   | 366 +-
 libavcodec/internal.h |   1 +
 libavcodec/utils.c|   8 +
 3 files changed, 118 insertions(+), 257 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 4856f41635..c52496d862 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -32,43 +32,28 @@
 
 int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, int64_t size, 
int64_t min_size)
 {
-if (avpkt->size < 0) {
-av_log(avctx, AV_LOG_ERROR, "Invalid negative user packet size %d\n", 
avpkt->size);
-return AVERROR(EINVAL);
-}
 if (size < 0 || size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
 av_log(avctx, AV_LOG_ERROR, "Invalid minimum required packet size 
%"PRId64" (max allowed is %d)\n",
size, INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE);
 return AVERROR(EINVAL);
 }
 
+av_assert0(!avpkt->data);
+
 if (avctx && 2*min_size < size) { // FIXME The factor needs to be finetuned
-av_assert0(!avpkt->data || avpkt->data != 
avctx->internal->byte_buffer);
-if (!avpkt->data || avpkt->size < size) {
-av_fast_padded_malloc(&avctx->internal->byte_buffer, 
&avctx->internal->byte_buffer_size, size);
-avpkt->data = avctx->internal->byte_buffer;
-avpkt->size = avctx->internal->byte_buffer_size;
-}
+av_fast_padded_malloc(&avctx->internal->byte_buffer, 
&avctx->internal->byte_buffer_size, size);
+avpkt->data = avctx->internal->byte_buffer;
+avpkt->size = size;
 }
 
-if (avpkt->data) {
-AVBufferRef *buf = avpkt->buf;
-
-if (avpkt->size < size) {
-av_log(avctx, AV_LOG_ERROR, "User packet is too small (%d < 
%"PRId64")\n", avpkt->size, size);
-return AVERROR(EINVAL);
-}
-
-av_init_packet(avpkt);
-avpkt->buf  = buf;
-avpkt->size = size;
-return 0;
-} else {
+if (!avpkt->data) {
 int ret = av_new_packet(avpkt, size);
 if (ret < 0)
 av_log(avctx, AV_LOG_ERROR, "Failed to allocate packet of size 
%"PRId64"\n", size);
 return ret;
 }
+
+return 0;
 }
 
 int ff_alloc_packet(AVPacket *avpkt, int size)
@@ -110,240 +95,6 @@ fail:
 return ret;
 }
 
-int attribute_align_arg avcodec_encode_audio2(AVCodecContext *avctx,
-  AVPacket *avpkt,
-  const AVFrame *frame,
-  int *got_packet_ptr)
-{
-AVFrame *extended_frame = NULL;
-AVFrame *padded_frame = NULL;
-int ret;
-AVPacket user_pkt = *avpkt;
-int needs_realloc = !user_pkt.data;
-
-*got_packet_ptr = 0;
-
-if (!avctx->codec->encode2) {
-av_log(avctx, AV_LOG_ERROR, "This encoder requires using the 
avcodec_send_frame() API.\n");
-return AVERROR(ENOSYS);
-}
-
-if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY) && !frame) {
-av_packet_unref(avpkt);
-return 0;
-}
-
-/* ensure that extended_data is properly set */
-if (frame && !frame->extended_data) {
-if (av_sample_fmt_is_planar(avctx->sample_fmt) &&
-avctx->channels > AV_NUM_DATA_POINTERS) {
-av_log(avctx, AV_LOG_ERROR, "Encoding to a planar sample format, "
-"with more than %d channels, but 
extended_data is not set.\n",
-   AV_NUM_DATA_POINTERS);
-return AVERROR(EINVAL);
-}
-av_log(avctx, AV_LOG_WARNING, "extended_data is not set.\n");
-
-extended_frame = av_frame_alloc();
-if (!extended_frame)
-return AVERROR(ENOMEM);
-
-memcpy(extended_frame, frame, sizeof(AVFrame));
-extended_frame->extended_data = extended_frame->data;
-frame = extended_frame;
-}
-
-/* extract audio service type metadata */
-if (frame) {
-AVFrameSideData *sd = av_frame_get_side_data(frame, 
AV_FRAME_DATA_AUDIO_SERVICE_TYPE);
-if (sd && sd->size >= sizeof(enum AVAudioServiceType))
-avctx->audio_service_type = *(enum AVAudioServiceType*)sd->data;
-}
-
-/* check for valid frame size */
-if (frame) {
-if (avctx->codec->capabilities & AV_CODEC_CAP_SMALL_LAST_FRAME) {
-if (frame->nb_samples > avctx->frame_size) {
-av_log(avctx, AV_LOG_ERROR, "more samples than frame size 
(avcodec_encode_audio2)\n");
-ret = AVERROR(EINVAL);
-goto end;
-}
-} else if (!(avctx->codec->capabilities & 
AV_CODEC_CAP_VARIABLE_FRAME_SIZE)) {
-/* if we already got an undersized frame, that must have been the 
last */
-if (avctx->internal->last_audio_frame) {
-

[FFmpeg-devel] [PATCH 0/2 v3] Restructuring the encode API

[James Almer]

This set follows the same logic as 061a0c14bb, but for the encode API: The
new public API will no longer be a wrapper around the old deprecated one, and
the internal API used by the encoders now consists of a single receive_packet()
callback that pulls frames as required.

Because of the above, PATCH 1/2 can't be applied until all the relevant encoders
have been adapted, and said changes squashed into it. This means librav1e, 
nvenc,
amfenc, v4l2_m2m, and vaapi_enc. I have ported librav1e in
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-March/258567.html both to
test this set and for it to work as an example for the maintainers of the other
three encoders in order to get an idea of what they should do. Similarly, Andriy
Gelman ported v4l2_m2m_enc in
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-March/258192.html

James Almer (2):
  avcodec/encode: restructure the core encoding code
  avcodec/encode: restructure the old encode API

 libavcodec/avcodec.h  |  12 +-
 libavcodec/decode.c   |   1 -
 libavcodec/encode.c   | 560 +-
 libavcodec/encode.h   |  39 +++
 libavcodec/internal.h |   8 +-
 libavcodec/utils.c|  18 +-
 6 files changed, 346 insertions(+), 292 deletions(-)
 create mode 100644 libavcodec/encode.h

-- 
2.25.2

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

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

Re: [FFmpeg-devel] [PATCH 2/3 v2] avcodec/encode: restructure the old encode API

[Anton Khirnov]

Quoting James Almer (2020-03-26 20:28:12)
> On 3/26/2020 5:57 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-03-16 22:30:01)
> >> Following the same logic as 061a0c14bb, this commit turns the old encode 
> >> API
> >> into a wrapper for the new one.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> This could be squashed with the previous commit, like it was done in 
> >> 061a0c14bb,
> >> but i figured it would be easier to review this way.
> >>
> >>  libavcodec/encode.c   | 364 +-
> >>  libavcodec/internal.h |   1 +
> >>  libavcodec/utils.c|   8 +
> >>  3 files changed, 116 insertions(+), 257 deletions(-)
> >>
> >> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> >> index cdea1c6c1e..0fdb9e2df2 100644
> >> --- a/libavcodec/encode.c
> >> +++ b/libavcodec/encode.c
> >> @@ -610,3 +361,102 @@ int attribute_align_arg 
> >> avcodec_receive_packet(AVCodecContext *avctx, AVPacket *
> >>  
> >>  return 0;
> >>  }
> >> +
> >> +static int compat_encode(AVCodecContext *avctx, AVPacket *avpkt,
> >> + int *got_packet, const AVFrame *frame)
> >> +{
> >> +AVCodecInternal *avci = avctx->internal;
> >> +AVPacket user_pkt;
> >> +int ret;
> >> +
> >> +*got_packet = 0;
> >> +
> >> +if (frame && avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> >> +if (frame->format == AV_PIX_FMT_NONE)
> >> +av_log(avctx, AV_LOG_WARNING, "AVFrame.format is not set\n");
> >> +if (frame->width == 0 || frame->height == 0)
> >> +av_log(avctx, AV_LOG_WARNING, "AVFrame.width or height is not 
> >> set\n");
> >> +}
> >> +
> >> +ret = avcodec_send_frame(avctx, frame);
> >> +if (ret == AVERROR_EOF)
> >> +ret = 0;
> >> +else if (ret == AVERROR(EAGAIN)) {
> >> +/* we fully drain all the output in each encode call, so this 
> >> should not
> >> + * ever happen */
> >> +return AVERROR_BUG;
> >> +} else if (ret < 0)
> >> +return ret;
> >> +
> >> +av_packet_move_ref(&user_pkt, avpkt);
> >> +while (ret >= 0) {
> >> +ret = avcodec_receive_packet(avctx, avpkt);
> >> +if (ret < 0) {
> >> +if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
> >> +ret = 0;
> >> +goto finish;
> >> +}
> >> +
> >> +if (avpkt != avci->compat_encode_packet) {
> >> +if (avpkt->data && user_pkt.data) {
> >> +if (user_pkt.size >= avpkt->size) {
> >> +memcpy(user_pkt.data, avpkt->data, avpkt->size);
> >> +av_buffer_unref(&avpkt->buf);
> >> +avpkt->buf  = user_pkt.buf;
> >> +avpkt->data = user_pkt.data;
> >> +av_init_packet(&user_pkt);
> >> +} else {
> >> +av_log(avctx, AV_LOG_ERROR, "Provided packet is too 
> >> small, needs to be %d\n", avpkt->size);
> >> +ret = AVERROR(EINVAL);
> >> +goto finish;
> > 
> > Shouldn't the packet be unreffed somewhere in this block?
> 
> Yeah. Fixed locally.
> 
> > 
> >> +}
> >> +}
> >> +
> >> +*got_packet = 1;
> >> +avpkt = avci->compat_encode_packet;
> >> +} else {
> >> +if (!avci->compat_decode_warned) {
> >> +av_log(avctx, AV_LOG_WARNING, "The deprecated 
> >> avcodec_encode_* "
> >> +   "API cannot return all the packets for this 
> >> encoder. "
> >> +   "Some packets will be dropped. Update your code to 
> >> the "
> >> +   "new encoding API to fix this.\n");
> >> +avci->compat_decode_warned = 1;
> >> +}
> > 
> > Same.
> 
> avpkt is avci->compat_encode_packet in this block. It will either be
> unreffed next time avcodec_receive_packet() is called with it, or by
> avcodec_close(). No need to unref it here explicitly, but i can do it if
> you prefer that.

I think it's better not to leave data we're not going to use just lying
around for no reason. So yeah, I'd prefer it to be unreffed here.

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

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

Re: [FFmpeg-devel] [PATCH 1/3 v2] avcodec/encode: restructure the core encoding code

[James Almer]

On 3/26/2020 5:43 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-16 22:30:00)
>> This commit follows the same logic as 061a0c14bb, but for the encode API: The
>> new public encoding API will no longer be a wrapper around the old deprecated
>> one, and the internal API used by the encoders now consists of a single
>> receive_packet() callback that pulls frames as required.
>>
>> Signed-off-by: James Almer 
>> ---
> 
> Generally looks ok, only some minor comments below.
> 
>>  libavcodec/avcodec.h  |  12 +-
>>  libavcodec/decode.c   |   1 -
>>  libavcodec/encode.c   | 285 --
>>  libavcodec/encode.h   |  39 ++
>>  libavcodec/internal.h |   7 +-
>>  libavcodec/utils.c|  10 +-
>>  6 files changed, 277 insertions(+), 77 deletions(-)
>>  create mode 100644 libavcodec/encode.h
>> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
>> index 9ed2cf0f59..cdea1c6c1e 100644
>> --- a/libavcodec/encode.c
>> +++ b/libavcodec/encode.c
>> @@ -26,6 +26,7 @@
>>  #include "libavutil/samplefmt.h"
>>  
>>  #include "avcodec.h"
>> +#include "encode.h"
>>  #include "frame_thread_encoder.h"
>>  #include "internal.h"
>>  
>> @@ -80,12 +81,9 @@ int ff_alloc_packet(AVPacket *avpkt, int size)
>>   */
>>  static int pad_last_frame(AVCodecContext *s, AVFrame **dst, const AVFrame 
>> *src)
>>  {
>> -AVFrame *frame = NULL;
>> +AVFrame *frame = *dst;
>>  int ret;
>>  
>> -if (!(frame = av_frame_alloc()))
>> -return AVERROR(ENOMEM);
>> -
>>  frame->format = src->format;
>>  frame->channel_layout = src->channel_layout;
>>  frame->channels   = src->channels;
>> @@ -106,12 +104,10 @@ static int pad_last_frame(AVCodecContext *s, AVFrame 
>> **dst, const AVFrame *src)
> 
> Doesn't need to be a double pointer anymore.

I know, but i left it as is to keep the changes to
avcodec_encode_audio2() to a minimum.

Although admittedly, since avcodec_encode_audio2() is being completely
rewritten in the following patch, it hardly matters. So changed locally.

> 
>> +static int encode_send_packet_internal(AVCodecContext *avctx, const AVFrame 
>> *src)
> 
> Should this be named send_frame?

Yes, changed locally.

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 2/3 v2] avcodec/encode: restructure the old encode API

[James Almer]

On 3/26/2020 5:57 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-16 22:30:01)
>> Following the same logic as 061a0c14bb, this commit turns the old encode API
>> into a wrapper for the new one.
>>
>> Signed-off-by: James Almer 
>> ---
>> This could be squashed with the previous commit, like it was done in 
>> 061a0c14bb,
>> but i figured it would be easier to review this way.
>>
>>  libavcodec/encode.c   | 364 +-
>>  libavcodec/internal.h |   1 +
>>  libavcodec/utils.c|   8 +
>>  3 files changed, 116 insertions(+), 257 deletions(-)
>>
>> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
>> index cdea1c6c1e..0fdb9e2df2 100644
>> --- a/libavcodec/encode.c
>> +++ b/libavcodec/encode.c
>> @@ -610,3 +361,102 @@ int attribute_align_arg 
>> avcodec_receive_packet(AVCodecContext *avctx, AVPacket *
>>  
>>  return 0;
>>  }
>> +
>> +static int compat_encode(AVCodecContext *avctx, AVPacket *avpkt,
>> + int *got_packet, const AVFrame *frame)
>> +{
>> +AVCodecInternal *avci = avctx->internal;
>> +AVPacket user_pkt;
>> +int ret;
>> +
>> +*got_packet = 0;
>> +
>> +if (frame && avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
>> +if (frame->format == AV_PIX_FMT_NONE)
>> +av_log(avctx, AV_LOG_WARNING, "AVFrame.format is not set\n");
>> +if (frame->width == 0 || frame->height == 0)
>> +av_log(avctx, AV_LOG_WARNING, "AVFrame.width or height is not 
>> set\n");
>> +}
>> +
>> +ret = avcodec_send_frame(avctx, frame);
>> +if (ret == AVERROR_EOF)
>> +ret = 0;
>> +else if (ret == AVERROR(EAGAIN)) {
>> +/* we fully drain all the output in each encode call, so this 
>> should not
>> + * ever happen */
>> +return AVERROR_BUG;
>> +} else if (ret < 0)
>> +return ret;
>> +
>> +av_packet_move_ref(&user_pkt, avpkt);
>> +while (ret >= 0) {
>> +ret = avcodec_receive_packet(avctx, avpkt);
>> +if (ret < 0) {
>> +if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
>> +ret = 0;
>> +goto finish;
>> +}
>> +
>> +if (avpkt != avci->compat_encode_packet) {
>> +if (avpkt->data && user_pkt.data) {
>> +if (user_pkt.size >= avpkt->size) {
>> +memcpy(user_pkt.data, avpkt->data, avpkt->size);
>> +av_buffer_unref(&avpkt->buf);
>> +avpkt->buf  = user_pkt.buf;
>> +avpkt->data = user_pkt.data;
>> +av_init_packet(&user_pkt);
>> +} else {
>> +av_log(avctx, AV_LOG_ERROR, "Provided packet is too 
>> small, needs to be %d\n", avpkt->size);
>> +ret = AVERROR(EINVAL);
>> +goto finish;
> 
> Shouldn't the packet be unreffed somewhere in this block?

Yeah. Fixed locally.

> 
>> +}
>> +}
>> +
>> +*got_packet = 1;
>> +avpkt = avci->compat_encode_packet;
>> +} else {
>> +if (!avci->compat_decode_warned) {
>> +av_log(avctx, AV_LOG_WARNING, "The deprecated 
>> avcodec_encode_* "
>> +   "API cannot return all the packets for this encoder. 
>> "
>> +   "Some packets will be dropped. Update your code to 
>> the "
>> +   "new encoding API to fix this.\n");
>> +avci->compat_decode_warned = 1;
>> +}
> 
> Same.

avpkt is avci->compat_encode_packet in this block. It will either be
unreffed next time avcodec_receive_packet() is called with it, or by
avcodec_close(). No need to unref it here explicitly, but i can do it if
you prefer that.

> 
> Beyond those two apparent leaks, looks good.

I'll send an updated set with the first two patches only. Now we just
need nvenc, amfenc and vaapi_enc ported, and then we can apply everything.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/matroskadec: Don't discard the upper 32bits of TrackNumber

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-26 01:41:42)
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> This has already been sent in [1]; I'm resending it because it fits
>> here.
>>
>> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254841.html
>>
>>  libavformat/matroskadec.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
> 
> Looks good
> 
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] doc/developer.texi: Add variadic macros to allowed C language features

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-23 03:38:38)
>> They are used in several places like CBS.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  doc/developer.texi | 3 +++
>>  1 file changed, 3 insertions(+)
> 
> Looks ok
> 
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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Thilo Borgmann]

Am 26.03.20 um 12:18 schrieb Nicolas George:
> Thilo Borgmann (12020-03-26):
>> Ok. So if I understand all of this correctly, the overall goal of the
>> tones project is already redundant to your old proposal (or at least
>> partially, Paul?).
> 
> I do not know what the overall goal of the tones project is: I have not
> seen it discussed on the list.

I strongly agree we should more thoroughly review future project proposals. The 
questions about validity/usefullness raised here should have been settled 
before it goes online for students to select.


>> Has there been any reason why it never made it into git HEAD?
> 
> It was just a vague proposal, not actual code.
> 
>> So for this patch as-is, AFAICT Paul wanted the external lib as
>> qualification task only and finally get things natively implemented
>> during GSoC?
> 
> I don't know what Paul wanted, I have not seen it discussed on the list.
> 
>> And then, it would of course only make sense to do this project based
>> on what Nicolas old proposal was. Assuming it served the same goal.

That was basically my misunderstanding of the topic. Paul wants a tone/music 
generator utilizing fluidsynth, not just as part of qualification as I 
understood it. And after talking to Nicolas, he is fine continuing that GSoC 
project as intended.

@Ashutosh: So please continue working on your project/application with Paul as 
planned. 

Time to give some actual feedback on the code / review, please.

Thanks,
Thilo
___
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/dashdec: fix memleak for commit commit e134c203

[Nicolas George]

Steven Liu (12020-03-24):
> These member will be used for get more correct information of the MPD
> 
> Suggested-by: Andreas Rheinhardt 
> Suggested-by: Nicolas George 
> Signed-off-by: Steven Liu 
> ---
>  libavformat/dashdec.c | 244 --
>  1 file changed, 214 insertions(+), 30 deletions(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 5bbe5d3985..b5bb8e674c 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -108,6 +108,7 @@ struct representation {
>  int64_t cur_seg_offset;
>  int64_t cur_seg_size;
>  struct fragment *cur_seg;
> +char *lang;
>  
>  /* Currently active Media Initialization Section */
>  struct fragment *init_section;
> @@ -122,19 +123,15 @@ struct representation {
>  typedef struct DASHContext {
>  const AVClass *class;
>  char *base_url;
> -char *adaptionset_contenttype_val;
> -char *adaptionset_par_val;
> -char *adaptionset_lang_val;
> -char *adaptionset_minbw_val;
> -char *adaptionset_maxbw_val;
> -char *adaptionset_minwidth_val;
> -char *adaptionset_maxwidth_val;
> -char *adaptionset_minheight_val;
> -char *adaptionset_maxheight_val;
> -char *adaptionset_minframerate_val;
> -char *adaptionset_maxframerate_val;
> -char *adaptionset_segmentalignment_val;
> -char *adaptionset_bitstreamswitching_val;
> +char *adaptionset_lang;
> +uint64_t adaptionset_minbw;
> +uint64_t adaptionset_maxbw;
> +uint64_t adaptionset_minwidth;
> +uint64_t adaptionset_maxwidth;
> +uint64_t adaptionset_minheight;
> +uint64_t adaptionset_maxheight;
> +AVRational adaptionset_minframerate;
> +AVRational adaptionset_maxframerate;
>  
>  int n_videos;
>  struct representation **videos;
> @@ -169,6 +166,79 @@ typedef struct DASHContext {
>  
>  } DASHContext;
>  

> +static int get_ratio_from_string(AVRational *dst, char *src)

const char *

> +{

> +char *p = src;

Not useful.

> +char *end = NULL;
> +char *end_ptr = NULL;
> +int num, den;
> +

> +num = (int)strtol(p, &end_ptr, 10);

Possible integer overflow.

> +if (errno == ERANGE || end_ptr == src) {
> +return AVERROR_INVALIDDATA;
> +}

Unnecessary braces.

> +
> +if (end_ptr[0] == '\0') {
> +dst->den = 1;
> +dst->num = num;
> +return 0;
> +}
> +
> +if (end_ptr[0] != '/')
> +return AVERROR_INVALIDDATA;

> +p = end_ptr + 1;

Not useful.

> +den = (int)strtol(p, &end, 10);

Possible integer overflow.

> +if (errno == ERANGE || end == src) {

> +dst->den = 1;

Why?

> +return AVERROR_INVALIDDATA;
> +}
> +dst->den = den;
> +
> +return 0;
> +}
> +

> +static uint64_t dash_prop_get_int64(AVFormatContext *s, xmlNodePtr node, 
> uint64_t *dst, const char *key)

The return type does not work.

> +{
> +char *end_ptr = NULL;
> +char *val = xmlGetProp(node, key);
> +int ret = 0;
> +
> +if (val) {

> +ret = strtoull(val, &end_ptr, 10);

Can't store unsigned long long into int.

> +if (errno == ERANGE) {
> +av_log(s, AV_LOG_WARNING, "overflow/underflow when get value of 
> %s\n", key);
> +xmlFree(val);
> +return AVERROR_INVALIDDATA;
> +}
> +if (end_ptr == val || end_ptr[0] != '\0') {
> +av_log(s, AV_LOG_ERROR, "The %s field value is "
> +"not a valid number: %s\n", key, val);
> +xmlFree(val);
> +return AVERROR_INVALIDDATA;
> +}
> +*dst = ret;
> +xmlFree(val);
> +}
> +return ret;
> +}
> +
> +static int dash_get_prop_ratio(AVFormatContext *s, xmlNodePtr node, 
> AVRational *member, const char *key)
> +{
> +char *val = xmlGetProp(node, key);
> +int ret = 0;
> +AVRational rate;
> +
> +if (val) {
> +ret = get_ratio_from_string(&rate, val);
> +if (ret < 0)
> +av_log(s, AV_LOG_WARNING, "Ignoring invalid %s frame rate 
> '%s'\n", key, val);
> +xmlFree(val);
> +}
> +member->num = rate.num;
> +member->den = rate.den;
> +return ret;
> +}
> +
>  static int ishttp(char *url)
>  {
>  const char *proto_name = avio_find_protocol_name(url);
> @@ -885,6 +955,15 @@ static int parse_manifest_representation(AVFormatContext 
> *s, const char *url,
>  ret = AVERROR(ENOMEM);
>  goto end;
>  }
> +if (c->adaptionset_lang) {
> +rep->lang = av_strdup(c->adaptionset_lang);
> +if (!rep->lang) {
> +av_log(s, AV_LOG_ERROR, "alloc language memory failure\n");
> +av_freep(&rep);
> +ret = AVERROR(ENOMEM);
> +goto end;
> +}
> +}
>  rep->parent = s;
>  representation_segmenttemplate_node = 
> find_child_node_by_name(representation_node, "SegmentTemplate");
>  representation_baseurl_node

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Robert Krüger]

Hi Baptiste,

On Tue, May 14, 2019 at 10:38 AM Thomas Mundt  wrote:

> Hi Baptiste,
>
> Am Di., 14. Mai 2019 um 00:33 Uhr schrieb Baptiste Coudurier <
> baptiste.coudur...@gmail.com>:
>
> > ---
> >  libavformat/Makefile |   2 +-
> >  libavformat/avc.c| 186 +
> >  libavformat/avc.h|  15 +++
> >  libavformat/hevc.c   |  36 +---
> >  libavformat/mxf.h|   1 +
> >  libavformat/mxfenc.c | 213 ++-
> >  6 files changed, 372 insertions(+), 81 deletions(-)
> >
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index 99be60d184..df87c54a58 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
> >  OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
> >  OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
> >  OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
> > -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> > audiointerleave.o
> > +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> > audiointerleave.o avc.o
> >  OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
> >  OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
> >  OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
> > diff --git a/libavformat/avc.c b/libavformat/avc.c
> > index ec50033a04..a041e84357 100644
> > --- a/libavformat/avc.c
> > +++ b/libavformat/avc.c
> > @@ -21,6 +21,7 @@
> >
> >  #include "libavutil/intreadwrite.h"
> >  #include "libavcodec/h264.h"
> > +#include "libavcodec/get_bits.h"
> >  #include "avformat.h"
> >  #include "avio.h"
> >  #include "avc.h"
> > @@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const
> > uint8_t *start,
> >
> >  return start + res;
> >  }
> > +
> > +uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
> > +  uint32_t *dst_len, int header_len)
> > +{
> > +uint8_t *dst;
> > +uint32_t i, len;
> > +
> > +dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
> > +if (!dst)
> > +return NULL;
> > +
> > +/* NAL unit header */
> > +i = len = 0;
> > +while (i < header_len && i < src_len)
> > +dst[len++] = src[i++];
> > +
> > +while (i + 2 < src_len)
> > +if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
> > +dst[len++] = src[i++];
> > +dst[len++] = src[i++];
> > +i++; // remove emulation_prevention_three_byte
> > +} else
> > +dst[len++] = src[i++];
> > +
> > +while (i < src_len)
> > +dst[len++] = src[i++];
> > +
> > +memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> > +
> > +*dst_len = len;
> > +return dst;
> > +}
> > +
> > +static const AVRational avc_sample_aspect_ratio[17] = {
> > +{   0,  1 },
> > +{   1,  1 },
> > +{  12, 11 },
> > +{  10, 11 },
> > +{  16, 11 },
> > +{  40, 33 },
> > +{  24, 11 },
> > +{  20, 11 },
> > +{  32, 11 },
> > +{  80, 33 },
> > +{  18, 11 },
> > +{  15, 11 },
> > +{  64, 33 },
> > +{ 160, 99 },
> > +{   4,  3 },
> > +{   3,  2 },
> > +{   2,  1 },
> > +};
> > +
> > +static inline int get_ue_golomb(GetBitContext *gb) {
> > +int i;
> > +for (i = 0; i < 32 && !get_bits1(gb); i++)
> > +;
> > +return get_bitsz(gb, i) + (1 << i) - 1;
> > +}
> > +
> > +static inline int get_se_golomb(GetBitContext *gb) {
> > +int v = get_ue_golomb(gb) + 1;
> > +int sign = -(v & 1);
> > +return ((v >> 1) ^ sign) - sign;
> > +}
> > +
> > +H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int
> > buf_size)
> > +{
> > +int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
> > +int num_ref_frames_in_pic_order_cnt_cycle;
> > +int delta_scale, lastScale = 8, nextScale = 8;
> > +int sizeOfScalingList;
> > +H264SequenceParameterSet *sps = NULL;
> > +GetBitContext gb;
> > +uint8_t *rbsp_buf;
> > +
> > +rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, &rbsp_size, 0);
> > +if (!rbsp_buf)
> > +return NULL;
> > +
> > +ret = init_get_bits8(&gb, rbsp_buf, rbsp_size);
> > +if (ret < 0)
> > +goto end;
> > +
> > +sps = av_mallocz(sizeof(*sps));
> > +if (!sps)
> > +goto end;
> > +
> > +sps->profile_idc = get_bits(&gb, 8);
> > +sps->constraint_set_flags |= get_bits1(&gb) << 0; //
> > constraint_set0_flag
> > +sps->constraint_set_flags |= get_bits1(&gb) << 1; //
> > constraint_set1_flag
> > +sps->constraint_set_flags |= get_bits1(&gb) << 2; //
> > constraint_set2_flag
> > +sps->constraint_set_flags |= get_bits1(&gb) << 3; //
> > constraint_set3_flag
> > +sps->constraint_set_flags |= get_bits1(&gb) << 4; //
> > constraint_set4_flag
> > +sps->constraint_set_flags |= get_bits1(&gb) << 5; //
> > constraint_set5_flag
> > +skip_bits(&gb, 2); // reserved_zero_2bits
> > 

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Reduce size of the allocated MOVIentry array

[James Almer]

On 3/26/2020 11:22 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-26 15:18:53)
>> On 3/26/2020 11:06 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2020-03-25 18:56:44)
 Increase it in a linear way instead.
 Helps reduce memory usage, especially on long, non fragmented output.

 Signed-off-by: James Almer 
 ---
 An alternative is using av_fast_realloc(), in a similar fashion as
 ff_add_index_entry(), which will keep the memory usage more closely tied 
 to the
 amount of entries needed, but the amount of reallocations will be much 
 higher,
 so i don't know if the tradeof is beneficial.
>>>
>>> Wait, wouldn't fast_realloc() do pretty much the same as your patch? Why
>>> should the number of reallocations be higher?
>>
>> I meant mimicking the behavior of ff_add_index_entry(), doing something like
>>
>> cluster = av_fast_realloc(trk->cluster,
>>   &trk->cluster_capacity,
>>   (trk->entry + 1) * sizeof(*trk->cluster));
>> trk->cluster = cluster;
>>
>> Which will get rid of the fixed MOV_INDEX_CLUSTER_SIZE increase per
>> realloc, and resulting in more, smaller size increment reallocs (but of
>> course not after every single new entry, which is the entire point of
>> av_fast_realloc()).
> 
> Ah, got it.
> 
> I'd say your patch is better, but it probably doesn't matter much.

Applied then, 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 2/4] lavc/x86/hevc_add_res: Fix overflow in ADD_RES_SSE_8_8

[Anton Khirnov]

Quoting Linjie Fu (2020-03-05 08:47:54)
> Fix overflow for coeff -32768 in function ADD_RES_SSE_8_8 with
> no performance drop.
> 
> ./checkasm --test=hevc_add_res --bench
> 
> Mainline:
>   - hevc_add_res.add_residual [OK]
> hevc_add_res_8x8_8_sse2: 15.5
> 
> Add overflow test case:
>   - hevc_add_res.add_residual [FAILED]
> 
> After:
>   - hevc_add_res.add_residual [OK]
> hevc_add_res_8x8_8_sse2: 15.5
> 
> Signed-off-by: Xu Guangxin 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/x86/hevc_add_res.asm | 45 
> -
>  1 file changed, 22 insertions(+), 23 deletions(-)

This and 3/4 acked by Lynne on IRC, so will push later if nobody
objects.

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

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

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add variadic macros to allowed C language features

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-23 03:38:38)
> They are used in several places like CBS.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  doc/developer.texi | 3 +++
>  1 file changed, 3 insertions(+)

Looks ok

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: use a buffer pool to allocate VP9Frame extradata

[James Almer]

On 3/26/2020 11:30 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-06 01:09:39)
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/vp9.c| 13 -
>>  libavcodec/vp9dec.h |  4 
>>  2 files changed, 16 insertions(+), 1 deletion(-)
>>
> 
> Looks reasonable. Any measurable performance difference?

Very noticeable when i use the START_TIMER/STOP_TIMER macros within the
function, of course, but despite only allocating about three buffers for
the entire decoding process instead of one per frame, i didn't notice
any reduction in overall decoding time.
Someone better at benchmarking may want to give it a try, though.

Will apply, 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] avcodec/vp9: use a buffer pool to allocate VP9Frame extradata

[Anton Khirnov]

Quoting James Almer (2020-03-06 01:09:39)
> Signed-off-by: James Almer 
> ---
>  libavcodec/vp9.c| 13 -
>  libavcodec/vp9dec.h |  4 
>  2 files changed, 16 insertions(+), 1 deletion(-)
> 

Looks reasonable. Any measurable performance difference?

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

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/matroskadec: Improve forward compability

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-26 01:41:44)
> Matroska is built around the principle that a reader does not need to
> understand everything in a file in order to be able to make use of it;
> it just needs to ignore the data it doesn't know about.
> 
> Our demuxer typically follows this principle, but there is one important
> instance where it does not: A Block belonging to a TrackEntry with no
> associated stream is treated as invalid data (i.e. the demuxer will try
> to resync to the next level 1 element because it takes this as a sign
> that it has lost sync). Given that we do not create streams if we don't
> know or don't support the type of the TrackEntry, this impairs this
> demuxer's forward compability.
> 
> Furthermore, ignoring Blocks belonging to a TrackEntry without
> corresponding stream can (in future commits) also be used to ignore
> TrackEntries with obviously bogus entries without affecting the other
> TrackEntries (by not creating a stream for said TrackEntry).
> 
> Finally, given that matroska_find_track_by_num() already emits its own
> error message in case there is no TrackEntry with a given TrackNumber,
> the error message (with level AV_LOG_INFO) for this can be removed.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---

Looks reasonable

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

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Reduce size of the allocated MOVIentry array

[Anton Khirnov]

Quoting James Almer (2020-03-26 15:18:53)
> On 3/26/2020 11:06 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-03-25 18:56:44)
> >> Increase it in a linear way instead.
> >> Helps reduce memory usage, especially on long, non fragmented output.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> An alternative is using av_fast_realloc(), in a similar fashion as
> >> ff_add_index_entry(), which will keep the memory usage more closely tied 
> >> to the
> >> amount of entries needed, but the amount of reallocations will be much 
> >> higher,
> >> so i don't know if the tradeof is beneficial.
> > 
> > Wait, wouldn't fast_realloc() do pretty much the same as your patch? Why
> > should the number of reallocations be higher?
> 
> I meant mimicking the behavior of ff_add_index_entry(), doing something like
> 
> cluster = av_fast_realloc(trk->cluster,
>   &trk->cluster_capacity,
>   (trk->entry + 1) * sizeof(*trk->cluster));
> trk->cluster = cluster;
> 
> Which will get rid of the fixed MOV_INDEX_CLUSTER_SIZE increase per
> realloc, and resulting in more, smaller size increment reallocs (but of
> course not after every single new entry, which is the entire point of
> av_fast_realloc()).

Ah, got it.

I'd say your patch is better, but it probably doesn't matter much.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Reduce size of the allocated MOVIentry array

[James Almer]

On 3/26/2020 11:06 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-25 18:56:44)
>> Increase it in a linear way instead.
>> Helps reduce memory usage, especially on long, non fragmented output.
>>
>> Signed-off-by: James Almer 
>> ---
>> An alternative is using av_fast_realloc(), in a similar fashion as
>> ff_add_index_entry(), which will keep the memory usage more closely tied to 
>> the
>> amount of entries needed, but the amount of reallocations will be much 
>> higher,
>> so i don't know if the tradeof is beneficial.
> 
> Wait, wouldn't fast_realloc() do pretty much the same as your patch? Why
> should the number of reallocations be higher?

I meant mimicking the behavior of ff_add_index_entry(), doing something like

cluster = av_fast_realloc(trk->cluster,
  &trk->cluster_capacity,
  (trk->entry + 1) * sizeof(*trk->cluster));
trk->cluster = cluster;

Which will get rid of the fixed MOV_INDEX_CLUSTER_SIZE increase per
realloc, and resulting in more, smaller size increment reallocs (but of
course not after every single new entry, which is the entire point of
av_fast_realloc()).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/matroskadec: Don't discard valid packets

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-26 01:41:43)
> A Block (meaning both a Block in a BlockGroup as well as a SimpleBlock)
> must have at least three bytes after the field containing the encoded
> TrackNumber. So a if there are <= 3 bytes, the Matroska demuxer would
> skip this block, believing it to be an empty, but valid Block.
> 
> This might discard valid Blocks, even nonempty ones (namely if the track
> uses header stripping). And certain definitely spec-incompliant Blocks
> don't raise errors: Those with two or less bytes left after the encoded
> TrackNumber and those with three bytes left, but with flags indicating
> that the Block uses lacing (in which case there has to be further data
> describing the lacing).
> 
> Furthermore, zero-sized packets were still possible because only the
> size of the last entry of a lace was checked.
> 
> This commit fixes this. All spec-compliant Blocks are now returned to
> the caller, even those with a size of zero. This is in accordance with the
> documentation of av_read_frame(): "This function returns what is stored
> in the file, and does not validate that what is there are valid frames
> for the decoder".
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> mkclean can produce blocks where the payload has a size of zero before
> readding the removed header. E.g. it does this if a stream only has one
> frame in total (although in such a case the overhead of header removal
> compression is greater than the number of bytes saved in the Blocks);
> this can in particular happen with forced subtitle tracks with only one
> frame (which is how I noticed this).
> 
> I am unsure what to do with size-zero packets; I don't know any
> Matroska Codec Mapping where this would be allowed. But there is nothing
> explicitly stating that they are generally illegal, so this commit
> returns them. The only thing I am certain is that stripping these
> packets away needs to happen after the content compressions have been
> reversed.

Maybe they are not illegal in matroska, but I have strong doubts that
they would be illegal to export from a demuxer. We do have packets with
no actual data (only side data), but those still contain _something_.
I suspect many users wouldn't handle outright empty packets well.

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/matroskadec: Don't discard the upper 32bits of TrackNumber

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-26 01:41:42)
> Signed-off-by: Andreas Rheinhardt 
> ---
> This has already been sent in [1]; I'm resending it because it fits
> here.
> 
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254841.html
> 
>  libavformat/matroskadec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Looks good

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

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Reduce size of the allocated MOVIentry array

[Anton Khirnov]

Quoting James Almer (2020-03-25 18:56:44)
> Increase it in a linear way instead.
> Helps reduce memory usage, especially on long, non fragmented output.
> 
> Signed-off-by: James Almer 
> ---
> An alternative is using av_fast_realloc(), in a similar fashion as
> ff_add_index_entry(), which will keep the memory usage more closely tied to 
> the
> amount of entries needed, but the amount of reallocations will be much higher,
> so i don't know if the tradeof is beneficial.

Wait, wouldn't fast_realloc() do pretty much the same as your patch? Why
should the number of reallocations be higher?

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

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

[FFmpeg-devel] [PATCH v1 2/4] avformat/hlsplaylist: simplify code for checking whether the string is empty

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/hlsplaylist.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/hlsplaylist.c b/libavformat/hlsplaylist.c
index 9cbd02353f..56244496c0 100644
--- a/libavformat/hlsplaylist.c
+++ b/libavformat/hlsplaylist.c
@@ -65,11 +65,11 @@ void ff_hls_write_stream_info(AVStream *st, AVIOContext 
*out,
 if (st && st->codecpar->width > 0 && st->codecpar->height > 0)
 avio_printf(out, ",RESOLUTION=%dx%d", st->codecpar->width,
 st->codecpar->height);
-if (codecs && strlen(codecs) > 0)
+if (codecs && codecs[0])
 avio_printf(out, ",CODECS=\"%s\"", codecs);
-if (agroup && strlen(agroup) > 0)
+if (agroup && agroup[0])
 avio_printf(out, ",AUDIO=\"group_%s\"", agroup);
-if (ccgroup && strlen(ccgroup) > 0)
+if (ccgroup && ccgroup[0])
 avio_printf(out, ",CLOSED-CAPTIONS=\"%s\"", ccgroup);
 avio_printf(out, "\n%s\n\n", filename);
 }
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH v1 1/4] avformat/hlsenc: remove the first slash of the relative path line in the master m3u8 file

[lance . lmwang]

From: Limin Wang 

Please testing with the following command:
./ffmpeg -y -i input.mkv \
 -b:v:0 5250k -c:v h264 -pix_fmt yuv420p -profile:v main -level 4.1 \
 -b:a:0 256k \
 -c:a mp2 -ar 48000 -ac 2 -map 0:v -map 0:a:0\
 -f hls -var_stream_map "v:0,a:0" \
 -master_pl_name master.m3u8 -t 300 -hls_time 10 -hls_init_time 4 
-hls_list_size \
 10 -master_pl_publish_rate 10  -hls_flags \
 delete_segments+discont_start+split_by_time ./tmp/video.m3u8

then cat ./tmp/master.m3u8
before:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=6056600,RESOLUTION=1280x720,CODECS="avc1.4d4829,mp4a.40.33"
/video.m3u8

$ ./ffmpeg -i  ./tmp/master.m3u8 -c:v copy -c:a mp2 ./test.mkv
[hls @ 0x7f82f900] Skip ('#EXT-X-VERSION:3')
[hls @ 0x7f82f900] Opening '/video.m3u8' for reading
[hls @ 0x7f82f900] parse_playlist error No such file or directory 
[/video.m3u8]
./tmp/master.m3u8: No such file or directory

after:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=6056600,RESOLUTION=1280x720,CODECS="avc1.4d4829,mp4a.40.33"
video.m3u8

Signed-off-by: Limin Wang 
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index b4c72b6e54..a0a3a4647b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1260,7 +1260,7 @@ static const char* get_relative_url(const char 
*master_url, const char *media_ur
 }
 }
 
-return media_url + base_len;
+return media_url + base_len + 1;
 }
 
 static int64_t get_stream_bit_rate(AVStream *stream)
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH v1 3/4] avformat: add subtitle support in master playlist m3u8

[lance . lmwang]

From: Limin Wang 

Test with the following command for the webvtt subtitle:
$ ./ffmpeg -y -i input_with_subtitle.mkv \
 -b:v:0 5250k -c:v h264 -pix_fmt yuv420p -profile:v main -level 4.1 \
 -b:a:0 256k \
 -c:s webvtt -c:a mp2 -ar 48000 -ac 2 -map 0:v -map 0:a:0 -map 0:s:0 \
 -f hls -var_stream_map "v:0,a:0,s:0,sgroup:subtitle" \
 -master_pl_name master.m3u8 -t 300 -hls_time 10 -hls_init_time 4 
-hls_list_size \
 10 -master_pl_publish_rate 10  -hls_flags \
 delete_segments+discont_start+split_by_time ./tmp/video.m3u8

Check the master m3u8:
$ cat tmp/master.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subtitle",NAME="subtitle_0",DEFAULT=YES,URI="video_vtt.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=6056600,RESOLUTION=1280x720,CODECS="avc1.4d4829,mp4a.40.33",SUBTITLES="subtitle"
video.m3u8

Check the result by convert to mkv:
$ ./ffmpeg -strict experimental -i ./tmp/master.m3u8 -c:v copy -c:a mp2 -c:s 
srt ./test.mkv

Signed-off-by: Limin Wang 
---
 libavformat/dashenc.c |  2 +-
 libavformat/hlsenc.c  | 26 --
 libavformat/hlsplaylist.c | 17 -
 libavformat/hlsplaylist.h |  4 +++-
 4 files changed, 44 insertions(+), 5 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94d463972a..d1fe90b00c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1311,7 +1311,7 @@ static int write_manifest(AVFormatContext *s, int final)
 get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL, 
i);
 ff_hls_write_stream_info(st, c->m3u8_out, stream_bitrate,
  playlist_file, agroup,
- codec_str_ptr, NULL);
+ codec_str_ptr, NULL, NULL);
 }
 dashenc_io_close(s, &c->m3u8_out, temp_filename);
 if (use_rename)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a0a3a4647b..d7b9c0e20a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -164,6 +164,7 @@ typedef struct VariantStream {
 int is_default; /* default status of audio group */
 char *language; /* audio lauguage name */
 char *agroup; /* audio group name */
+char *sgroup; /* subtitle group name */
 char *ccgroup; /* closed caption group name */
 char *baseurl;
 char *varname; // variant name
@@ -1289,7 +1290,9 @@ static int create_master_playlist(AVFormatContext *s,
 unsigned int i, j;
 int ret, bandwidth;
 const char *m3u8_rel_name = NULL;
+const char *vtt_m3u8_rel_name = NULL;
 char *ccgroup;
+char *sgroup = NULL;
 ClosedCaptionsStream *ccs;
 const char *proto = avio_find_protocol_name(hls->master_m3u8_url);
 int is_file_proto = proto && !strcmp(proto, "file");
@@ -1412,13 +1415,24 @@ static int create_master_playlist(AVFormatContext *s,
 vs->ccgroup);
 }
 
+if (vid_st && vs->sgroup) {
+sgroup = vs->sgroup;
+vtt_m3u8_rel_name = get_relative_url(hls->master_m3u8_url, 
vs->vtt_m3u8_name);
+if (!vtt_m3u8_rel_name) {
+av_log(s, AV_LOG_WARNING, "Unable to find relative subtitle 
URL\n");
+break;
+}
+
+ff_hls_write_subtitle_rendition(hls->m3u8_out, sgroup, 
vtt_m3u8_rel_name, vs->language, i, hls->has_default_key ? vs->is_default : 1);
+}
+
 if (!hls->has_default_key || !hls->has_video_m3u8) {
 ff_hls_write_stream_info(vid_st, hls->m3u8_out, bandwidth, 
m3u8_rel_name,
-aud_st ? vs->agroup : NULL, vs->codec_attr, ccgroup);
+aud_st ? vs->agroup : NULL, vs->codec_attr, ccgroup, 
sgroup);
 } else {
 if (vid_st) {
 ff_hls_write_stream_info(vid_st, hls->m3u8_out, bandwidth, 
m3u8_rel_name,
- aud_st ? vs->agroup : NULL, 
vs->codec_attr, ccgroup);
+ aud_st ? vs->agroup : NULL, 
vs->codec_attr, ccgroup, sgroup);
 }
 }
 }
@@ -1893,6 +1907,7 @@ static int parse_variant_stream_mapstring(AVFormatContext 
*s)
  * practical usage)
  *
  * agroup: is key to specify audio group. A string can be given as value.
+ * sgroup: is key to specify subtitle group. A string can be given as 
value.
  */
 p = av_strdup(hls->var_stream_map);
 if (!p)
@@ -1960,6 +1975,12 @@ static int 
parse_variant_stream_mapstring(AVFormatContext *s)
 if (!vs->agroup)
 return AVERROR(ENOMEM);
 continue;
+} else if (av_strstart(keyval, "sgroup:", &val)) {
+av_free(vs->sgroup);
+vs->sgroup = av_strdup(val);
+if (!vs->sgroup)
+return AVERROR(ENOMEM);
+continue;
 } else if (av_strstart(keyval, "ccgroup:", &val)) {
 av_free(vs->ccgroup);

[FFmpeg-devel] [PATCH v1 4/4] avformat/hlsenc: use av_asprintf()

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/hlsenc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index d7b9c0e20a..694dab42dd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2950,13 +2950,11 @@ static int hls_init(AVFormatContext *s)
 if (ret < 0)
 goto fail;
 } else {
-vs->vtt_m3u8_name = av_malloc(vtt_basename_size);
+vs->vtt_m3u8_name = av_asprintf("%s_vtt.m3u8", 
vs->vtt_basename);
 if (!vs->vtt_m3u8_name) {
 ret = AVERROR(ENOMEM);
 goto fail;
 }
-strcpy(vs->vtt_m3u8_name, vs->vtt_basename);
-av_strlcat(vs->vtt_m3u8_name, "_vtt.m3u8", vtt_basename_size);
 }
 av_strlcat(vs->vtt_basename, vtt_pattern, vtt_basename_size);
 }
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH 1/4] lavc/x86/hevc_add_res: Fix overflow in ADD_RES_MMX_4_8

[Anton Khirnov]

Quoting Linjie Fu (2020-03-05 08:47:37)
> Fix overflow for coeff -32768 in function ADD_RES_MMX_4_8 with no
> performance drop.
> 
> ./checkasm --test=hevc_add_res --bench
> 
> Mainline:
>   - hevc_add_res.add_residual [OK]
> hevc_add_res_4x4_8_mmxext: 15.5
> 
> Add overflow test case:
>   - hevc_add_res.add_residual [FAILED]
> 
> After:
>   - hevc_add_res.add_residual [OK]
> hevc_add_res_4x4_8_mmxext: 15.0
> 
> Signed-off-by: Xu Guangxin 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/x86/hevc_add_res.asm | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)

Looks ok and even more readable.
Thank you, queueing.

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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Thilo Borgmann (12020-03-26):
> Ok. So if I understand all of this correctly, the overall goal of the
> tones project is already redundant to your old proposal (or at least
> partially, Paul?).

I do not know what the overall goal of the tones project is: I have not
seen it discussed on the list.

> Has there been any reason why it never made it into git HEAD?

It was just a vague proposal, not actual code.

> So for this patch as-is, AFAICT Paul wanted the external lib as
> qualification task only and finally get things natively implemented
> during GSoC?

I don't know what Paul wanted, I have not seen it discussed on the list.

> And then, it would of course only make sense to do this project based
> on what Nicolas old proposal was. Assuming it served the same goal.
> 
> Nicolas, can you please give a link here to your proposal for Ashutosh
> to find it easily?

https://ffmpeg.org/pipermail/ffmpeg-devel/2018-September/234714.html

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Thilo Borgmann]

Am 26.03.20 um 11:58 schrieb Nicolas George:
> Thilo Borgmann (12020-03-26):
>> Let's look at this. There are two things here:
>>
>> a) Is it a good enough solution of the qualfification task Paul has
>> given to Ashutosh?
>>
>> b) Is it unsuitable to apply? Well that might be but we need to get
>> clear about a) for the sake of GSoC.
>>
>> Also, a) & b) might be a reoccuring problem this year, as IIRC Jai
>> also gave a qualification tasks that might be on its own useless to
>> apply to git HEAD. But AFAIKT this is not on devel by now. So please
>> let's concentrate on these two questions. Any thoughts appreciated.
> 
> The original proposal for a tone audio source was from me, more than a
> year ago. It was for testing purposes: to be able to feed filters and
> codecs realistic input without relying on external files. For that, it
> would have been completely internal and bit-exact.
> 
> Now, there is a new proposal. Without looking into it closer, I supposed
> it was based on the same goal: testing. Apparently not. But I have not
> seen that discussed on the list.
> 
> I have no objection to the task if it serves a purpose. But it has
> nothing to do with my original proposal and this version, using an
> external library, would be worthless for testing.

Ok. So if I understand all of this correctly, the overall goal of the tones 
project is already redundant to your old proposal (or at least partially, 
Paul?).

Has there been any reason why it never made it into git HEAD?

So for this patch as-is, AFAICT Paul wanted the external lib as qualification 
task only and finally get things natively implemented during GSoC?

If so, we can first review this patch as RFC to give Ashutosh feedback to his 
coding & things. And wether or not he'll pass qualification, gets selected for 
a probably available slot etc, reads as if he's doing the GSoC project finally, 
we can have Ashutosh work on an implementation of the audio tones project. 
Assuming there haven't been any fundamental objections to Nicolas old proposal 
about such a thing already.

And then, it would of course only make sense to do this project based on what 
Nicolas old proposal was. Assuming it served the same goal.

Nicolas, can you please give a link here to your proposal for Ashutosh to find 
it easily?

-Thilo



___
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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Thilo Borgmann (12020-03-26):
> Let's look at this. There are two things here:
> 
> a) Is it a good enough solution of the qualfification task Paul has
> given to Ashutosh?
> 
> b) Is it unsuitable to apply? Well that might be but we need to get
> clear about a) for the sake of GSoC.
> 
> Also, a) & b) might be a reoccuring problem this year, as IIRC Jai
> also gave a qualification tasks that might be on its own useless to
> apply to git HEAD. But AFAIKT this is not on devel by now. So please
> let's concentrate on these two questions. Any thoughts appreciated.

The original proposal for a tone audio source was from me, more than a
year ago. It was for testing purposes: to be able to feed filters and
codecs realistic input without relying on external files. For that, it
would have been completely internal and bit-exact.

Now, there is a new proposal. Without looking into it closer, I supposed
it was based on the same goal: testing. Apparently not. But I have not
seen that discussed on the list.

I have no objection to the task if it serves a purpose. But it has
nothing to do with my original proposal and this version, using an
external library, would be worthless for testing.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH] lavc/pthread_frame: Update user context in ff_frame_thread_free

[Anton Khirnov]

Quoting Linjie Fu (2019-12-27 09:47:35)
> Resolution/format changes lead to re-initialization of hardware
> accelerations(vaapi/dxva2/..) with new hwaccel_priv_data in
> the worker-thread. But hwaccel_priv_data in user context won't
> be updated until the resolution changing frame is output.
> 
> A termination with "-vframes" just after the reinit will lead to:
> 1. memory leak in worker-thread.
> 2. double free in user-thread.
> 
> Update user context in ff_frame_thread_free with the last thread
> submit_packet() was called on.
> 
> To reproduce:
> ffmpeg -hwaccel vaapi(dxva2) -v verbose -i
> fate-suite/h264/reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12
> -f rawvideo -vsync passthrough -vframes 47 -y out.yuv
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/pthread_frame.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 36ac0ac..8bdd735 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -657,6 +657,13 @@ void ff_frame_thread_free(AVCodecContext *avctx, int 
> thread_count)
>  
>  park_frame_worker_threads(fctx, thread_count);
>  
> +if (fctx->prev_thread && avctx->internal->hwaccel_priv_data !=
> + 
> fctx->prev_thread->avctx->internal->hwaccel_priv_data) {
> +if (update_context_from_thread(avctx, fctx->prev_thread->avctx, 1) < 
> 0) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to update user thread.\n");
> +}
> +}
> +
>  if (fctx->prev_thread && fctx->prev_thread != fctx->threads)
>  if (update_context_from_thread(fctx->threads->avctx, 
> fctx->prev_thread->avctx, 0) < 0) {
>  av_log(avctx, AV_LOG_ERROR, "Final thread update failed\n");
> -- 
> 2.7.4

Not an ideal solution - we shouldn't be leaving stale pointers around in
the first place - but I suppose it's good enough for now.

Will push unless someone objects.

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

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

Re: [FFmpeg-devel] [PATCH]configure: Get the correct ident for clang-cl.exe

[Martin Storsjö]

On Thu, 26 Mar 2020, Carl Eugen Hoyos wrote:


Hi!

Attached patch avoids that ffmpeg claims its compiler was "No input
file" when using clang-cl.

Please comment, Carl Eugen



@@ -4663,7 +4663,11 @@ probe_cc(){
 _ld_path='-libpath:'
 elif $_cc -nologo- 2>&1 | grep -q Microsoft || { $_cc -v 2>&1 | 

grep -q clang && $_cc -? > /dev/null 2>&1; }; then

 _type=msvc
-_ident=$($_cc 2>&1 | head -n1 | tr -d '\r')
+if $_cc -nologo- 2>&1 | grep -q Microsoft; then
+_ident=$($_cc 2>&1 | head -n1 | tr -d '\r')
+else
+_ident=$($_cc --version 2>/dev/null | head -n1)


The change looks good to me, but isn't "tr -d '\r'" (potentially) needed 
here as well?


// Martin

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

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

Re: [FFmpeg-devel] [PATCH]configure: Remove all C standard versions from the MSVC command line

[Martin Storsjö]

On Thu, 26 Mar 2020, Carl Eugen Hoyos wrote:


Hi!

Attached patch removes an ugly warning shown for every file when using
clang-cl.exe.

Please comment, Carl Eugen


LGTM

// Martin

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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Thilo Borgmann]

Am 26.03.20 um 10:48 schrieb Paul B Mahol:
> On 3/26/20, Nicolas George  wrote:
>> Ashutosh Pradhan (12020-03-26):
>>> I was trying to random tones using cellular automata (it won't sound good
>>> if the tones are too random so I used a scale) for the GSoC audio tones
>>> filter project.
>>
>> Yes, that's already in the doc. What I ask is what good you expect from
>> it.
> 
> What kind of insinuation is this?
> This is qualification task for GSoC project, if you have something against it,
> ask me directly instead.

Let's look at this. There are two things here:

a) Is it a good enough solution of the qualfification task Paul has given to 
Ashutosh?

b) Is it unsuitable to apply? Well that might be but we need to get clear about 
a) for the sake of GSoC.

Also, a) & b) might be a reoccuring problem this year, as IIRC Jai also gave a 
qualification tasks that might be on its own useless to apply to git HEAD. But 
AFAIKT this is not on devel by now. So please let's concentrate on these two 
questions. Any thoughts appreciated.

Thanks,
Thilo
___
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] avformat: Add Dynacolor MVC Demuxer

[Tom Needham]

Thanks for your feedback. Please see the attached patch with all the style
changes addressed which also applies properly.


0001-avformat-Add-Dynacolor-MVC-Demuxer.patch
Description: Binary 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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Thilo Borgmann]

Am 26.03.20 um 11:24 schrieb Nicolas George:
> Paul B Mahol (12020-03-26):
>> Apparently you are talking about completely different and irrelevant stuff
>> for this task.
> 
> Apparently, you did not read my previous mails very carefully, because I
> already explained.

Please let's stop here, we're loosing the connection to the subject.

-Thilo

___
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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Paul B Mahol (12020-03-26):
> Apparently you are talking about completely different and irrelevant stuff
> for this task.

Apparently, you did not read my previous mails very carefully, because I
already explained.

-- 
  Nicolas George
___
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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Paul B Mahol]

On 3/26/20, Nicolas George  wrote:
> Paul B Mahol (12020-03-26):
>> That is just your biased opinion.
>
> No, that is not my opinion, that is the position of the project for
> years: we don't control external libraries, their output can change from
> one version to the next or with forks and patched versions. Only
> internal implementation is suited for testing, preferably bit-exact.
>

Apparently you are talking about completely different and irrelevant stuff
for this task.
___
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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Paul B Mahol (12020-03-26):
> That is just your biased opinion.

No, that is not my opinion, that is the position of the project for
years: we don't control external libraries, their output can change from
one version to the next or with forks and patched versions. Only
internal implementation is suited for testing, preferably bit-exact.

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Paul B Mahol]

On 3/26/20, Nicolas George  wrote:
> Paul B Mahol (12020-03-26):
>> > No insinuation at all, just an honest question.
>> We will see...
>
> This... is an insinuation.
>
>> Use case is to generate nice listenable music that is computer generated.
>> This filter as is just prototype and is not meant to be applied in
>> current version but only when final version is done with all needed
>> features is implemented.
>
> Ok. I doubt it will achieve anything without incorporating the rules of
> harmony discovered during the renaissance, but as long as the goal is
> properly defined I have no objection.
>
> I had doubts that it was meant for testing, because it is similar to an
> old proposal of mine which was exactly meant for testing. This
> implementation is 100% unsuited for testing since it uses an external
> library.

That is just your biased opinion.
___
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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Paul B Mahol (12020-03-26):
> > No insinuation at all, just an honest question.
> We will see...

This... is an insinuation.

> Use case is to generate nice listenable music that is computer generated.
> This filter as is just prototype and is not meant to be applied in
> current version but only when final version is done with all needed
> features is implemented.

Ok. I doubt it will achieve anything without incorporating the rules of
harmony discovered during the renaissance, but as long as the goal is
properly defined I have no objection.

I had doubts that it was meant for testing, because it is similar to an
old proposal of mine which was exactly meant for testing. This
implementation is 100% unsuited for testing since it uses an external
library.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Paul B Mahol]

On 3/26/20, Nicolas George  wrote:
> Paul B Mahol (12020-03-26):
>> What kind of insinuation is this?
>
> No insinuation at all, just an honest question.

We will see...

>
>> This is qualification task for GSoC project, if you have something against
>> it,
>> ask me directly instead.
>
> Of course, feel free to answer the question. What is the use case for
> this filter?

Use case is to generate nice listenable music that is computer generated.
This filter as is just prototype and is not meant to be applied in
current version
but only when final version is done with all needed features is implemented.
___
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] ffplay, avcodec, avformat: Don't initialize before av_packet_ref()

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-13 14:28:33)
> It already initializes the packet.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Resending because of 3117f47f19d051d47ba29c9b78c2ca525f0fdb45.
> 
>  fftools/ffplay.c  | 2 +-
>  libavcodec/qsvdec_h2645.c | 2 +-
>  libavcodec/qsvdec_other.c | 2 +-
>  libavformat/fifo.c| 1 -
>  libavformat/img2enc.c | 8 
>  libavformat/tee.c | 1 -
>  6 files changed, 7 insertions(+), 9 deletions(-)

Generally looks good, but it occurred to me that the semantics of what
happens on failure in av_packet_ref() is unspecified, which might lead
to those uninitialized packets now being full of random data, which
might be dangerous.

So we might want to specify that on failure dst is reset to a clean
state and replace the call to av_packet_free_side_data() with
av_packet_unref().

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/avpacket: Always treat dst in av_packet_ref as uninitialized

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-02-12 16:02:21)
> av_packet_ref() mostly treated the destination packet dst as uninitialized,
> i.e. the destination fields were simply overwritten. But if the source
> packet was not reference-counted, dst->buf was treated as if it pointed
> to an already allocated buffer (if != NULL) to be reallocated to the
> desired size.
> 
> The documentation did not explicitly state whether the dst will be treated
> as uninitialized, but it stated that if the source packet is not refcounted,
> a new buffer in dst will be allocated. This and the fact that the side-data
> as well as the codepath taken in case src is refcounted always treated the
> packet as uninitialized means that dst should always be treated as
> uninitialized for the sake of consistency. And this behaviour has been
> explicitly documented.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/avcodec.h  | 2 +-
>  libavcodec/avpacket.c | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index dc5807324f..982a545dc6 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -4600,7 +4600,7 @@ void av_packet_free_side_data(AVPacket *pkt);
>   *
>   * @see av_packet_unref
>   *
> - * @param dst Destination packet
> + * @param dst Destination packet. Will be treated as initially uninitialized.

The 'initially' sounds weird to me. How about "Will be completely
overwritten"?

>   * @param src Source packet
>   *
>   * @return 0 on success, a negative AVERROR on error.
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 74845efcd2..0d9ddeee07 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -614,6 +614,7 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src)
>  return ret;
>  
>  if (!src->buf) {
> +dst->buf = NULL;
>  ret = packet_alloc(&dst->buf, src->size);
>  if (ret < 0)
>  goto fail;
> -- 
> 2.20.1

weak sugestion - perhaps it'd be clearer to just add a call to
av_init_packet() to the beginning of that function

Also, we might want to finally forbid non-refcounted packets completely.

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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Ashutosh Pradhan (12020-03-26):
> Since random tones generated using seed( ) was already sent on the mailing
> list, Paul had suggested me to control the duration between tones and to
> generate tones using cellular automata.

I am not asking what YOU are doing, I am asking what benefits our users
would get from this filter. In what case a user would want to use this
filter.

If you cannot answer this question, then there is no reason to adopt it.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Paul B Mahol (12020-03-26):
> What kind of insinuation is this?

No insinuation at all, just an honest question.

> This is qualification task for GSoC project, if you have something against it,
> ask me directly instead.

Of course, feel free to answer the question. What is the use case for
this filter?

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Ashutosh Pradhan]

On Thu, Mar 26, 2020 at 2:53 PM Nicolas George  wrote:

> Ashutosh Pradhan (12020-03-26):
> > I was trying to random tones using cellular automata (it won't sound good
> > if the tones are too random so I used a scale) for the GSoC audio tones
> > filter project.
>
> Yes, that's already in the doc. What I ask is what good you expect from
> it.
> Since random tones generated using seed( ) was already sent on the mailing
> list, Paul had suggested me to control the duration between tones and to
> generate tones using cellular automata.
> > On Thu, Mar 26, 2020 at 2:41 PM Nicolas George  wrote:
>
> Please remember not to top post on this mailing-list.
>
> Regards,
>
> --
>   Nicolas George
> ___
> 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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Paul B Mahol]

On 3/26/20, Nicolas George  wrote:
> Ashutosh Pradhan (12020-03-26):
>> I was trying to random tones using cellular automata (it won't sound good
>> if the tones are too random so I used a scale) for the GSoC audio tones
>> filter project.
>
> Yes, that's already in the doc. What I ask is what good you expect from
> it.

What kind of insinuation is this?
This is qualification task for GSoC project, if you have something against it,
ask me directly instead.

>
>> On Thu, Mar 26, 2020 at 2:41 PM Nicolas George  wrote:
>
> Please remember not to top post on this mailing-list.
>
> Regards,
>
> --
>   Nicolas George
>
___
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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-20 17:51:41)
> Jan Ekström:
> > On Fri, Mar 20, 2020 at 5:45 PM  wrote:
> >>
> >> From: Limin Wang 
> >>
> >> This fixes webvtt segment output.
> >>
> >> Please testing with the following command and check the output:
> >> ./ffmpeg -i ../fate-suite/sub/MicroDVD_capability_tester.srt -f segment 
> >> -segment_time 10 \
> >> -segment_list_size 0  -segment_list sub.m3u8 -segment_format webvtt 
> >> -scodec webvtt sub-%d.vtt
> >>
> >>
> >> Signed-off-by: Limin Wang 
> >> ---
> >>  fftools/ffmpeg.c |  1 +
> >>  tests/ref/fate/binsub-movtextenc |  2 +-
> >>  tests/ref/fate/sub2video | 86 
> >>  3 files changed, 45 insertions(+), 44 deletions(-)
> >>
> >> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >> index aaaf241314..c5a2d0731d 100644
> >> --- a/fftools/ffmpeg.c
> >> +++ b/fftools/ffmpeg.c
> >> @@ -1054,6 +1054,7 @@ static void do_subtitle_out(OutputFile *of,
> >>  else
> >>  pkt.pts += av_rescale_q(sub->end_display_time, 
> >> (AVRational){ 1, 1000 }, ost->mux_timebase);
> >>  }
> >> +pkt.flags |= AV_PKT_FLAG_KEY;
> >>  pkt.dts = pkt.pts;
> >>  output_packet(of, &pkt, ost, 0);
> >>  }
> > 
> > I do wonder if this is just a case of people forgetting to set the
> > flag for the relevant packets in the relevant modules?
> > 
> > I'm not sure if all API users should be forced to handle this
> > separately. If the packets are decode'able by themselves, they should
> > be marked as such.
> > 
> > (Unfortunately, this probably means that all subtitle encoders and
> > text-based subtitle format demuxers would have to be updated where
> > this flag is not set)
> > 
> av_read_frame() already sets the AV_PKT_FLAG_KEY-flag for all subtitle
> packets (see is_intra_only() in libavformat/utils.c; the subtitle
> demuxer based around FFDemuxSubtitlesQueues actually have the flag set
> even before it reaches is_intra_only()). One could do something similar
> in libavformat/mux.c.
> But are we actually sure that all subtitle packets are decodable by
> themselves? IIRC this is not true for all PGS subtitles.
> 
> - Andreas
> 
> PS: The semantics of the AV_CODEC_PROP_INTRA_ONLY-flag seem to be based
> around the assumption that subtitle packets are always intra-only: It is
> only for video and audio-codecs only.

I would interpret it as simply not being defined for subtitles, rather
than saying they are all always intra only. So we can always add new
semantics for subtitles to it.

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

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

Re: [FFmpeg-devel] [PATCH 03/21] avformat/mpeg: Remove unnecessary av_packet_unref()

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-22 04:47:38)
> Forgotten in 6a67d518.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/mpeg.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)

Looks ok

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

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

Re: [FFmpeg-devel] [PATCH 02/21] avformat/yop: Use av_packet_move_ref() for packet ownership transfer

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-22 04:47:37)
> Also return 0 after successfully reading a packet.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/yop.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)

ok

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

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

Re: [FFmpeg-devel] [PATCH 01/21] avformat/nsvdec: Use av_packet_move_ref() for packet ownership transfer

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-03-22 04:47:36)
> Also simply return 0 in case a packet has been successfully read.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/nsvdec.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Looks ok.

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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Ashutosh Pradhan (12020-03-26):
> I was trying to random tones using cellular automata (it won't sound good
> if the tones are too random so I used a scale) for the GSoC audio tones
> filter project.

Yes, that's already in the doc. What I ask is what good you expect from
it.

> On Thu, Mar 26, 2020 at 2:41 PM Nicolas George  wrote:

Please remember not to top post on this mailing-list.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Ashutosh Pradhan]

I was trying to random tones using cellular automata (it won't sound good
if the tones are too random so I used a scale) for the GSoC audio tones
filter project.

On Thu, Mar 26, 2020 at 2:41 PM Nicolas George  wrote:

> Ashutosh Pradhan (12020-03-26):
> > Use cellular automata and fluidsynth sequencer to generate tones in
> major pentatonic scale
>
> Can you explain the use cases for this filter?
>
> Regards,
>
> --
>   Nicolas George
>
___
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] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Nicolas George]

Ashutosh Pradhan (12020-03-26):
> Use cellular automata and fluidsynth sequencer to generate tones in major 
> pentatonic scale

Can you explain the use cases for this filter?

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH 2/3 v2] avcodec/encode: restructure the old encode API

[Anton Khirnov]

Quoting James Almer (2020-03-16 22:30:01)
> Following the same logic as 061a0c14bb, this commit turns the old encode API
> into a wrapper for the new one.
> 
> Signed-off-by: James Almer 
> ---
> This could be squashed with the previous commit, like it was done in 
> 061a0c14bb,
> but i figured it would be easier to review this way.
> 
>  libavcodec/encode.c   | 364 +-
>  libavcodec/internal.h |   1 +
>  libavcodec/utils.c|   8 +
>  3 files changed, 116 insertions(+), 257 deletions(-)
> 
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index cdea1c6c1e..0fdb9e2df2 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -610,3 +361,102 @@ int attribute_align_arg 
> avcodec_receive_packet(AVCodecContext *avctx, AVPacket *
>  
>  return 0;
>  }
> +
> +static int compat_encode(AVCodecContext *avctx, AVPacket *avpkt,
> + int *got_packet, const AVFrame *frame)
> +{
> +AVCodecInternal *avci = avctx->internal;
> +AVPacket user_pkt;
> +int ret;
> +
> +*got_packet = 0;
> +
> +if (frame && avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> +if (frame->format == AV_PIX_FMT_NONE)
> +av_log(avctx, AV_LOG_WARNING, "AVFrame.format is not set\n");
> +if (frame->width == 0 || frame->height == 0)
> +av_log(avctx, AV_LOG_WARNING, "AVFrame.width or height is not 
> set\n");
> +}
> +
> +ret = avcodec_send_frame(avctx, frame);
> +if (ret == AVERROR_EOF)
> +ret = 0;
> +else if (ret == AVERROR(EAGAIN)) {
> +/* we fully drain all the output in each encode call, so this should 
> not
> + * ever happen */
> +return AVERROR_BUG;
> +} else if (ret < 0)
> +return ret;
> +
> +av_packet_move_ref(&user_pkt, avpkt);
> +while (ret >= 0) {
> +ret = avcodec_receive_packet(avctx, avpkt);
> +if (ret < 0) {
> +if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
> +ret = 0;
> +goto finish;
> +}
> +
> +if (avpkt != avci->compat_encode_packet) {
> +if (avpkt->data && user_pkt.data) {
> +if (user_pkt.size >= avpkt->size) {
> +memcpy(user_pkt.data, avpkt->data, avpkt->size);
> +av_buffer_unref(&avpkt->buf);
> +avpkt->buf  = user_pkt.buf;
> +avpkt->data = user_pkt.data;
> +av_init_packet(&user_pkt);
> +} else {
> +av_log(avctx, AV_LOG_ERROR, "Provided packet is too 
> small, needs to be %d\n", avpkt->size);
> +ret = AVERROR(EINVAL);
> +goto finish;

Shouldn't the packet be unreffed somewhere in this block?

> +}
> +}
> +
> +*got_packet = 1;
> +avpkt = avci->compat_encode_packet;
> +} else {
> +if (!avci->compat_decode_warned) {
> +av_log(avctx, AV_LOG_WARNING, "The deprecated 
> avcodec_encode_* "
> +   "API cannot return all the packets for this encoder. "
> +   "Some packets will be dropped. Update your code to 
> the "
> +   "new encoding API to fix this.\n");
> +avci->compat_decode_warned = 1;
> +}

Same.

Beyond those two apparent leaks, looks good.

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

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

Re: [FFmpeg-devel] [PATCH 1/3 v2] avcodec/encode: restructure the core encoding code

[Anton Khirnov]

Quoting James Almer (2020-03-16 22:30:00)
> This commit follows the same logic as 061a0c14bb, but for the encode API: The
> new public encoding API will no longer be a wrapper around the old deprecated
> one, and the internal API used by the encoders now consists of a single
> receive_packet() callback that pulls frames as required.
> 
> Signed-off-by: James Almer 
> ---

Generally looks ok, only some minor comments below.

>  libavcodec/avcodec.h  |  12 +-
>  libavcodec/decode.c   |   1 -
>  libavcodec/encode.c   | 285 --
>  libavcodec/encode.h   |  39 ++
>  libavcodec/internal.h |   7 +-
>  libavcodec/utils.c|  10 +-
>  6 files changed, 277 insertions(+), 77 deletions(-)
>  create mode 100644 libavcodec/encode.h
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index 9ed2cf0f59..cdea1c6c1e 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -26,6 +26,7 @@
>  #include "libavutil/samplefmt.h"
>  
>  #include "avcodec.h"
> +#include "encode.h"
>  #include "frame_thread_encoder.h"
>  #include "internal.h"
>  
> @@ -80,12 +81,9 @@ int ff_alloc_packet(AVPacket *avpkt, int size)
>   */
>  static int pad_last_frame(AVCodecContext *s, AVFrame **dst, const AVFrame 
> *src)
>  {
> -AVFrame *frame = NULL;
> +AVFrame *frame = *dst;
>  int ret;
>  
> -if (!(frame = av_frame_alloc()))
> -return AVERROR(ENOMEM);
> -
>  frame->format = src->format;
>  frame->channel_layout = src->channel_layout;
>  frame->channels   = src->channels;
> @@ -106,12 +104,10 @@ static int pad_last_frame(AVCodecContext *s, AVFrame 
> **dst, const AVFrame *src)

Doesn't need to be a double pointer anymore.

> +static int encode_send_packet_internal(AVCodecContext *avctx, const AVFrame 
> *src)

Should this be named send_frame?

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

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

[FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Ashutosh Pradhan]

Use cellular automata and fluidsynth sequencer to generate tones in major 
pentatonic scale

diff --git a/Changelog b/Changelog
index d1572553a5..5ddd2484b0 100644
--- a/Changelog
+++ b/Changelog
@@ -48,6 +48,7 @@ version :
 - AMQP 0-9-1 protocol (RabbitMQ)
 - Vulkan support
 - avgblur_vulkan, overlay_vulkan, scale_vulkan and chromaber_vulkan filters
+- atone filter
 
 
 version 4.2:
diff --git a/configure b/configure
index 6ceb0c7af4..2ec7e377f3 100755
--- a/configure
+++ b/configure
@@ -233,6 +233,7 @@ External library support:
and libraw1394 [no]
   --enable-libfdk-aac  enable AAC de/encoding via libfdk-aac [no]
   --enable-libfliteenable flite (voice synthesis) support via libflite 
[no]
+  --enable-libfluidsynth   enable libfluidsynth support for fluidsynth [no]
   --enable-libfontconfig   enable libfontconfig, useful for drawtext filter 
[no]
   --enable-libfreetype enable libfreetype, needed for drawtext filter [no]
   --enable-libfribidi  enable libfribidi, improves drawtext filter [no]
@@ -1770,6 +1771,7 @@ EXTERNAL_LIBRARY_LIST="
 libdc1394
 libdrm
 libflite
+libfluidsynth
 libfontconfig
 libfreetype
 libfribidi
@@ -3465,6 +3467,7 @@ asr_filter_deps="pocketsphinx"
 ass_filter_deps="libass"
 atempo_filter_deps="avcodec"
 atempo_filter_select="rdft"
+atone_filter_deps="libfluidsynth"
 avgblur_opencl_filter_deps="opencl"
 avgblur_vulkan_filter_deps="vulkan libglslang"
 azmq_filter_deps="libzmq"
@@ -6270,6 +6273,7 @@ enabled libfdk_aac&& { check_pkg_config 
libfdk_aac fdk-aac "fdk-aac/aace
  warn "using libfdk without pkg-config"; } }
 flite_extralibs="-lflite_cmu_time_awb -lflite_cmu_us_awb -lflite_cmu_us_kal 
-lflite_cmu_us_kal16 -lflite_cmu_us_rms -lflite_cmu_us_slt -lflite_usenglish 
-lflite_cmulex -lflite"
 enabled libflite  && require libflite "flite/flite.h" flite_init 
$flite_extralibs
+enabled libfluidsynth && require_pkg_config libfluidsynth fluidsynth 
"fluidsynth.h" fluid_log
 enabled fontconfig&& enable libfontconfig
 enabled libfontconfig && require_pkg_config libfontconfig fontconfig 
"fontconfig/fontconfig.h" FcInit
 enabled libfreetype   && require_pkg_config libfreetype freetype2 
"ft2build.h FT_FREETYPE_H" FT_Init_FreeType
diff --git a/doc/filters.texi b/doc/filters.texi
index 328e984e92..193dcaf8e9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6050,6 +6050,60 @@ anoisesrc=d=60:c=pink:r=44100:a=0.5
 @end example
 @end itemize
 
+@section atone
+
+Generate legato tones using cellular automata.
+To compile filter configure ffmpeg with @code{--enable-libfluidsynth} 
+
+The filter accepts the following options:
+
+@table @option
+@item sample_rate, r
+Specify the sample rate. Default value is 44100 Hz.
+
+@item sfont
+Specify the location of soundfont file. Default value is 
+"/usr/share/sounds/sf2/FluidR3_GM.sf2"(for linux).
+
+@item duration, d
+Specify the duration of the generated audio stream. Not specifying this option
+results in playing tones for infinite length.
+
+@item velocity, v
+Specify the velocity of key press. Default value is 80.
+
+@item MIDI_channel
+Specify the MIDI channel number between(0 to 16) to play tones. Default is 0.
+
+@item tone_change_interval, t
+Specify the time interval between successive tones in seconds. Default is 0.2s.
+
+@item rule
+Specify the rule between 0 to 255 to get the rule set. Default is 30.
+
+@item width
+Specify the width of the cells array. Default is 64.
+
+@item tempo
+Specify the beats per minute. Default is 120.
+
+@item samples_per_frame
+Set the number of samples per each output frame. Default is 1024.
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+Generate 10 seconds of random tones, with a key velocity of 100, midi channel 1
+and an tone change interval of 0.1s:
+@example
+atone=d=10:MIDI_channel=1:v=100:t=0.1:sfont="example.sf2":rule=193
+atone=duration=10:MIDI_channel=1:velocity=100:tone_change_interval=0.1:sfont="example.sf2":rule=193
+@end example
+@end itemize
+
 @section hilbert
 
 Generate odd-tap Hilbert transform FIR coefficients.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 750412da6b..b1f0c4be35 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -151,6 +151,7 @@ OBJS-$(CONFIG_FLITE_FILTER)  += asrc_flite.o
 OBJS-$(CONFIG_HILBERT_FILTER)+= asrc_hilbert.o
 OBJS-$(CONFIG_SINC_FILTER)   += asrc_sinc.o
 OBJS-$(CONFIG_SINE_FILTER)   += asrc_sine.o
+OBJS-$(CONFIG_ATONE_FILTER)  += asrc_atone.o
 
 OBJS-$(CONFIG_ANULLSINK_FILTER)  += asink_anullsink.o
 
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 501e5d041b..4d3efc7e15 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -145,6 +145,7 @@ extern AVFilter ff_asrc_flite;
 extern AVFilter ff_asrc_hilbert;
 extern AVFilter ff_asrc_sinc;
 extern AVF