[FFmpeg-devel] [PATCH v2] doc/filters: add the sr filter model generation scripts new repository link

2019-05-15 Thread Steven Liu
Hold on the old repository link and mention new repository link  development 
continues

Signed-off-by: Steven Liu 
---
 doc/filters.texi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 38c70bf674..2e9db150f2 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16538,7 +16538,8 @@ See @url{https://arxiv.org/abs/1609.05158}.
 @end itemize
 
 Training scripts as well as scripts for model generation are provided in
-the repository at @url{https://github.com/HighVoltageRocknRoll/sr.git}.
+the repository at @url{https://github.com/HighVoltageRocknRoll/sr.git}(have 
stop maintaince)
+or @url{https://github.com/XueweiMeng/sr/tree/sr_dnn_native}(development 
continues).
 
 The filter accepts the following options:
 
-- 
2.17.2 (Apple Git-113)



___
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/filters: update the sr filter model generation scripts repository link

2019-05-15 Thread Liu Steven


> 在 2019年5月16日,下午1:15,Gyan  写道:
> 
> 
> 
> On 16-05-2019 10:39 AM, Liu Steven wrote:
>> 
>>> 在 2019年5月16日,下午12:40,Gyan  写道:
>>> 
>>> 
>>> 
>>> On 16-05-2019 08:20 AM, Steven Liu wrote:
 The https://github.com/HighVoltageRocknRoll/sr.git looks have stop
 maintaince, so link it to new repository
 
 Signed-off-by: Steven Liu 
 ---
  doc/filters.texi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/doc/filters.texi b/doc/filters.texi
 index 38c70bf674..317c256079 100644
 --- a/doc/filters.texi
 +++ b/doc/filters.texi
 @@ -16538,7 +16538,7 @@ See @url{https://arxiv.org/abs/1609.05158}.
  @end itemize
Training scripts as well as scripts for model generation are provided in
 -the repository at @url{https://github.com/HighVoltageRocknRoll/sr.git}.
 +the repository at 
 @url{https://github.com/XueweiMeng/sr/tree/sr_dnn_native}.
The filter accepts the following options:
  
>>> I see that the new url points to a fork, but is the sr filter author the 
>>> maintainer or collaborator?
>> That is not the main problem if the old repository have no people 
>> maintaining it, because the dnn_native need update, but the old repository
>> author has  loss of communication, we send email to he, no response, pr have 
>> no people review and merge, that will block the dnn_native of ffmpeg,
>> if the dnn_native is blocked, the GSoC of derain will stop.
>> 
>> Or duplicate dnn_native code? reference to: 
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244075.html
>> Or other suggestions welcome. :D
>> 
> Keep old URL. Add new URL and mention it is a fork where development 
> continues.
Okay,

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



___
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/filters: update the sr filter model generation scripts repository link

2019-05-15 Thread Gyan



On 16-05-2019 10:39 AM, Liu Steven wrote:



在 2019年5月16日,下午12:40,Gyan  写道:



On 16-05-2019 08:20 AM, Steven Liu wrote:

The https://github.com/HighVoltageRocknRoll/sr.git looks have stop
maintaince, so link it to new repository

Signed-off-by: Steven Liu 
---
  doc/filters.texi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 38c70bf674..317c256079 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16538,7 +16538,7 @@ See @url{https://arxiv.org/abs/1609.05158}.
  @end itemize
Training scripts as well as scripts for model generation are provided in
-the repository at @url{https://github.com/HighVoltageRocknRoll/sr.git}.
+the repository at @url{https://github.com/XueweiMeng/sr/tree/sr_dnn_native}.
The filter accepts the following options:
  

I see that the new url points to a fork, but is the sr filter author the 
maintainer or collaborator?

That is not the main problem if the old repository have no people maintaining 
it, because the dnn_native need update, but the old repository
author has  loss of communication, we send email to he, no response, pr have no 
people review and merge, that will block the dnn_native of ffmpeg,
if the dnn_native is blocked, the GSoC of derain will stop.

Or duplicate dnn_native code? reference to: 
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244075.html
Or other suggestions welcome. :D

Keep old URL. Add new URL and mention it is a fork where development 
continues.


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

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

Re: [FFmpeg-devel] [PATCH] avfilter/drawtext: stop resource leak

2019-05-15 Thread Gyan



On 15-05-2019 05:13 PM, Paul B Mahol wrote:

On 5/15/19, Gyan  wrote:

See http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244029.html

Gyan


probably ok

Pushed as 8cf947ca4c603f14cdb016eff0c341cb37ec09cc

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

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

Re: [FFmpeg-devel] [PATCH] doc/filters: update the sr filter model generation scripts repository link

2019-05-15 Thread Liu Steven


> 在 2019年5月16日,下午12:40,Gyan  写道:
> 
> 
> 
> On 16-05-2019 08:20 AM, Steven Liu wrote:
>> The https://github.com/HighVoltageRocknRoll/sr.git looks have stop
>> maintaince, so link it to new repository
>> 
>> Signed-off-by: Steven Liu 
>> ---
>>  doc/filters.texi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 38c70bf674..317c256079 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -16538,7 +16538,7 @@ See @url{https://arxiv.org/abs/1609.05158}.
>>  @end itemize
>>Training scripts as well as scripts for model generation are provided in
>> -the repository at @url{https://github.com/HighVoltageRocknRoll/sr.git}.
>> +the repository at @url{https://github.com/XueweiMeng/sr/tree/sr_dnn_native}.
>>The filter accepts the following options:
>>  
> I see that the new url points to a fork, but is the sr filter author the 
> maintainer or collaborator?
That is not the main problem if the old repository have no people maintaining 
it, because the dnn_native need update, but the old repository
author has  loss of communication, we send email to he, no response, pr have no 
people review and merge, that will block the dnn_native of ffmpeg,
if the dnn_native is blocked, the GSoC of derain will stop.

Or duplicate dnn_native code? reference to: 
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244075.html
Or other suggestions welcome. :D


Thanks

Steven

___
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/filters: update the sr filter model generation scripts repository link

2019-05-15 Thread Gyan



On 16-05-2019 08:20 AM, Steven Liu wrote:

The https://github.com/HighVoltageRocknRoll/sr.git looks have stop
maintaince, so link it to new repository

Signed-off-by: Steven Liu 
---
  doc/filters.texi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 38c70bf674..317c256079 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16538,7 +16538,7 @@ See @url{https://arxiv.org/abs/1609.05158}.
  @end itemize
  
  Training scripts as well as scripts for model generation are provided in

-the repository at @url{https://github.com/HighVoltageRocknRoll/sr.git}.
+the repository at @url{https://github.com/XueweiMeng/sr/tree/sr_dnn_native}.
  
  The filter accepts the following options:
  
I see that the new url points to a fork, but is the sr filter author the 
maintainer or collaborator?


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

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

[FFmpeg-devel] [PATCH V2] avutil/tx: add check against (*ctx)

2019-05-15 Thread Ruiling Song
ctx is a pointer to pointer here.

Signed-off-by: Ruiling Song 
---
 libavutil/tx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/tx.c b/libavutil/tx.c
index 934ef27c81..1690604040 100644
--- a/libavutil/tx.c
+++ b/libavutil/tx.c
@@ -697,7 +697,7 @@ static int gen_mdct_exptab(AVTXContext *s, int len4, double 
scale)
 
 av_cold void av_tx_uninit(AVTXContext **ctx)
 {
-if (!ctx)
+if (!ctx || !(*ctx))
 return;
 
 av_free((*ctx)->pfatab);
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH] avutil/tx: should check against (*ctx)

2019-05-15 Thread James Almer
On 5/16/2019 1:47 AM, Ruiling Song wrote:
> ctx is a pointer to pointer here.
> 
> Signed-off-by: Ruiling Song 
> ---
>  libavutil/tx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavutil/tx.c b/libavutil/tx.c
> index 934ef27c81..2bf4aa1c28 100644
> --- a/libavutil/tx.c
> +++ b/libavutil/tx.c
> @@ -697,7 +697,7 @@ static int gen_mdct_exptab(AVTXContext *s, int len4, 
> double scale)
>  
>  av_cold void av_tx_uninit(AVTXContext **ctx)
>  {
> -if (!ctx)
> +if (!(*ctx))

It should actually check for both, ctx and *ctx.

>  return;
>  
>  av_free((*ctx)->pfatab);
> 

___
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] avutil/tx: should check against (*ctx)

2019-05-15 Thread Ruiling Song
ctx is a pointer to pointer here.

Signed-off-by: Ruiling Song 
---
 libavutil/tx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/tx.c b/libavutil/tx.c
index 934ef27c81..2bf4aa1c28 100644
--- a/libavutil/tx.c
+++ b/libavutil/tx.c
@@ -697,7 +697,7 @@ static int gen_mdct_exptab(AVTXContext *s, int len4, double 
scale)
 
 av_cold void av_tx_uninit(AVTXContext **ctx)
 {
-if (!ctx)
+if (!(*ctx))
 return;
 
 av_free((*ctx)->pfatab);
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH] lavc/vp9_superframe_bsf: avoid error messages in one line

2019-05-15 Thread Fu Linjie
Add "\n" to avoid continuous error messages in one line.

Signed-off-by: Fu Linjie 
---
 libavcodec/vp9_superframe_bsf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
index ea67507..23933d4 100644
--- a/libavcodec/vp9_superframe_bsf.c
+++ b/libavcodec/vp9_superframe_bsf.c
@@ -133,7 +133,7 @@ static int vp9_superframe_filter(AVBSFContext *ctx, 
AVPacket *out)
 
 if (uses_superframe_syntax && s->n_cache > 0) {
 av_log(ctx, AV_LOG_ERROR,
-   "Mixing of superframe syntax and naked VP9 frames not 
supported");
+   "Mixing of superframe syntax and naked VP9 frames not 
supported\n");
 res = AVERROR(ENOSYS);
 goto done;
 } else if ((!invisible || uses_superframe_syntax) && !s->n_cache) {
@@ -142,7 +142,7 @@ static int vp9_superframe_filter(AVBSFContext *ctx, 
AVPacket *out)
 goto done;
 } else if (s->n_cache + 1 >= MAX_CACHE) {
 av_log(ctx, AV_LOG_ERROR,
-   "Too many invisible frames");
+   "Too many invisible frames\n");
 res = AVERROR_INVALIDDATA;
 goto done;
 }
-- 
2.7.4

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

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

[FFmpeg-devel] [PATCH] doc/filters: update the sr filter model generation scripts repository link

2019-05-15 Thread Steven Liu
The https://github.com/HighVoltageRocknRoll/sr.git looks have stop
maintaince, so link it to new repository

Signed-off-by: Steven Liu 
---
 doc/filters.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 38c70bf674..317c256079 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16538,7 +16538,7 @@ See @url{https://arxiv.org/abs/1609.05158}.
 @end itemize
 
 Training scripts as well as scripts for model generation are provided in
-the repository at @url{https://github.com/HighVoltageRocknRoll/sr.git}.
+the repository at @url{https://github.com/XueweiMeng/sr/tree/sr_dnn_native}.
 
 The filter accepts the following options:
 
-- 
2.17.2 (Apple Git-113)




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

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

Re: [FFmpeg-devel] [PATCH v2 1/2] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed

2019-05-15 Thread Andriy Gelman
On Thu, 16. May 00:43, Michael Niedermayer wrote:
> On Tue, May 14, 2019 at 05:54:21PM -0400, Andriy Gelman wrote:
> > From: Andriy Gelman 
> > 
> > Fixes Ticket #7895.
> > 
> > Currently, timestamp interpolation is disabled by default in H264 and
> > HEVC.  This creates playback issues when the demuxer does not output a
> > valid timestamp. This patch allows interpolation when no b-frames have
> > been observed during decoding, which fixes playback issues for some
> > missing timestamp cases.
> > ---
> >  libavformat/utils.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index a63d71b0f4..3dd0bf0d66 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -1233,7 +1233,9 @@ static void compute_pkt_fields(AVFormatContext *s, 
> > AVStream *st,
> >  int64_t offset;
> >  AVRational duration;
> >  int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
> > -   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
> > +   st->codecpar->codec_id != AV_CODEC_ID_HEVC ||
> > +   (!st->internal->avctx->max_b_frames &&
> > +st->cur_dts != RELATIVE_TS_BASE); /*skip when no 
> > timing info from demuxer */
> >  
> >  if (s->flags & AVFMT_FLAG_NOFILLIN)
> >  return;
> > @@ -1272,6 +1274,10 @@ static void compute_pkt_fields(AVFormatContext *s, 
> > AVStream *st,
> >  delay = st->internal->avctx->has_b_frames;
> >  presentation_delayed = 0;
> >  
> > +/*update max_b_frames if delay is larger */
> > +if (delay > st->internal->avctx->max_b_frames)
> > +  st->internal->avctx->max_b_frames = delay;
> > +
> >  /* XXX: need has_b_frame, but cannot get it if the codec is
> >   *  not initialized */
> >  if (delay &&
> > @@ -1337,7 +1343,8 @@ static void compute_pkt_fields(AVFormatContext *s, 
> > AVStream *st,
> >  presentation_delayed, av_ts2str(pkt->pts), 
> > av_ts2str(pkt->dts), av_ts2str(st->cur_dts),
> >  pkt->stream_index, pc, pkt->duration, delay, onein_oneout);
> >  
> > -/* Interpolate PTS and DTS if they are not present. We skip H264
> > +/* Interpolate PTS and DTS if they are not present. H264/HEVC 
> > timestamps are
> > + * interpolated only if no b-frames have been observed. Otherwise, we 
> > skip H264/HEVC
> >   * currently because delay and has_b_frames are not reliably set. */
> >  if ((delay == 0 || (delay == 1 && pc)) &&
> >  onein_oneout) {
> 
> This may produce some approximate values that are sometimes wrong.
> 
> If you want to compute exact timestamps, see "Conditional coding of 
> timestamps"
> in H.222. I only have a older draft here so mine only covers mpeg & h264 but 
> maybe the next covers hevc too.

ok, thanks. I'll look over this.
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 v2 1/2] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed

2019-05-15 Thread Michael Niedermayer
On Tue, May 14, 2019 at 05:54:21PM -0400, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> Fixes Ticket #7895.
> 
> Currently, timestamp interpolation is disabled by default in H264 and
> HEVC.  This creates playback issues when the demuxer does not output a
> valid timestamp. This patch allows interpolation when no b-frames have
> been observed during decoding, which fixes playback issues for some
> missing timestamp cases.
> ---
>  libavformat/utils.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index a63d71b0f4..3dd0bf0d66 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1233,7 +1233,9 @@ static void compute_pkt_fields(AVFormatContext *s, 
> AVStream *st,
>  int64_t offset;
>  AVRational duration;
>  int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
> -   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
> +   st->codecpar->codec_id != AV_CODEC_ID_HEVC ||
> +   (!st->internal->avctx->max_b_frames &&
> +st->cur_dts != RELATIVE_TS_BASE); /*skip when no 
> timing info from demuxer */
>  
>  if (s->flags & AVFMT_FLAG_NOFILLIN)
>  return;
> @@ -1272,6 +1274,10 @@ static void compute_pkt_fields(AVFormatContext *s, 
> AVStream *st,
>  delay = st->internal->avctx->has_b_frames;
>  presentation_delayed = 0;
>  
> +/*update max_b_frames if delay is larger */
> +if (delay > st->internal->avctx->max_b_frames)
> +  st->internal->avctx->max_b_frames = delay;
> +
>  /* XXX: need has_b_frame, but cannot get it if the codec is
>   *  not initialized */
>  if (delay &&
> @@ -1337,7 +1343,8 @@ static void compute_pkt_fields(AVFormatContext *s, 
> AVStream *st,
>  presentation_delayed, av_ts2str(pkt->pts), av_ts2str(pkt->dts), 
> av_ts2str(st->cur_dts),
>  pkt->stream_index, pc, pkt->duration, delay, onein_oneout);
>  
> -/* Interpolate PTS and DTS if they are not present. We skip H264
> +/* Interpolate PTS and DTS if they are not present. H264/HEVC timestamps 
> are
> + * interpolated only if no b-frames have been observed. Otherwise, we 
> skip H264/HEVC
>   * currently because delay and has_b_frames are not reliably set. */
>  if ((delay == 0 || (delay == 1 && pc)) &&
>  onein_oneout) {

This may produce some approximate values that are sometimes wrong.

If you want to compute exact timestamps, see "Conditional coding of timestamps"
in H.222. I only have a older draft here so mine only covers mpeg & h264 but 
maybe the next covers hevc too.

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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 v2 1/2] lavu/display: add av_display_rotation_hflip_get and bump version

2019-05-15 Thread Michael Niedermayer
On Tue, May 14, 2019 at 10:36:44PM -0700, Jun Li wrote:
> Add av_display_rotation_hflip_get to get information whether the
> matrix indicates horizontal flip.
> ---
>  doc/APIchanges|  3 +++
>  libavutil/display.c   | 14 ++
>  libavutil/display.h   | 14 ++
>  libavutil/tests/display.c |  8 
>  libavutil/version.h   |  2 +-
>  tests/ref/fate/display|  4 
>  6 files changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index e75c4044ce..73c6809563 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>  
>  API changes, most recent first:
>  
> +2019-05-13 - XX - lavu 56.28.100 - display.h
> +  Add av_display_rotation_hflip_get
> +
>  2019-04-20 - 3153a6502a - lavc 58.52.100 - avcodec.h
>Add AV_CODEC_FLAG_DROPCHANGED to allow avcodec_receive_frame to drop
>frames whose parameters differ from first decoded frame in stream.
> diff --git a/libavutil/display.c b/libavutil/display.c
> index a0076e067b..f5a6a4a08d 100644
> --- a/libavutil/display.c
> +++ b/libavutil/display.c
> @@ -71,3 +71,17 @@ void av_display_matrix_flip(int32_t matrix[9], int hflip, 
> int vflip)
>  for (i = 0; i < 9; i++)
>  matrix[i] *= flip[i % 3];
>  }
> +
> +double av_display_rotation_hflip_get(const int32_t matrix[9], int *hflip)
> +{
> +int32_t m[9];
> +*hflip = 0;
> +memcpy(m, matrix, sizeof(m));
> +

> +if (m[0] > 0 && m[4] < 0 || m[0] < 0 && m[4] > 0 ||
> +m[1] > 0 && m[3] > 0 || m[1] < 0 && m[3] < 0) {
> +*hflip = 1;
> +av_display_matrix_flip(m, 1, 0);
> +}

This is not correct
consider the identity transform matrix
1   0
0   1

now if the 0 elements are only so slightly off 0 this could set hflip, this
does not make the matrix flip anything, its still basically a identity matrix.

What you want to detect here, i _think_, is the direction in which the matrix
rotates the vector. Not sure what the technical term is but the "z" sign of
the cross product of the 2 basis vectors should be that if iam not mistaken.

I think that results in something like m[0]*m[4] < m[1]*m[3] but ive not
checked this so please check before using it 

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

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

Re: [FFmpeg-devel] [PATCH] avcodec/qtrle: return last frame even if unchanged

2019-05-15 Thread Michael Niedermayer
On Wed, May 15, 2019 at 10:53:25PM +0200, Hendrik Leppkes wrote:
> On Wed, May 15, 2019 at 8:41 PM Michael Niedermayer
>  wrote:
> >
> > Fixes: Ticket7880
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/qtrle.c| 27 +--
> >  tests/ref/fate/qtrle-8bit |  1 +
> >  2 files changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
> > index 2c29547e5a..11226cb842 100644
> > --- a/libavcodec/qtrle.c
> > +++ b/libavcodec/qtrle.c
> > @@ -45,6 +45,7 @@ typedef struct QtrleContext {
> >
> >  GetByteContext g;
> >  uint32_t pal[256];
> > +int need_flush;
> >  } QtrleContext;
> >
> >  #define CHECK_PIXEL_PTR(n) 
> >\
> > @@ -444,6 +445,12 @@ static av_cold int qtrle_decode_init(AVCodecContext 
> > *avctx)
> >  return 0;
> >  }
> >
> > +static void qtrle_flush(AVCodecContext *avctx){
> > +QtrleContext *s = avctx->priv_data;
> > +
> > +s->need_flush = 0;
> > +}
> > +
> >  static int qtrle_decode_frame(AVCodecContext *avctx,
> >void *data, int *got_frame,
> >AVPacket *avpkt)
> > @@ -454,11 +461,26 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
> >  int has_palette = 0;
> >  int ret, size;
> >
> > +if (!avpkt->data) {
> > +if (s->need_flush) {
> > +s->need_flush = 0;
> > +if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
> > +return ret;
> > +if ((ret = av_frame_ref(data, s->frame)) < 0)
> > +return ret;
> > +*got_frame = 1;
> > +}
> > +return 0;
> > +}
> > +
> >  bytestream2_init(>g, avpkt->data, avpkt->size);
> >
> >  /* check if this frame is even supposed to change */
> > -if (avpkt->size < 8)
> > +if (avpkt->size < 8) {
> > +s->need_flush = 1;
> >  return avpkt->size;
> > +}
> > +s->need_flush = 0;
> >
> >  /* start after the chunk size */
> >  size = bytestream2_get_be32(>g) & 0x3FFF;
> > @@ -572,5 +594,6 @@ AVCodec ff_qtrle_decoder = {
> >  .init   = qtrle_decode_init,
> >  .close  = qtrle_decode_end,
> >  .decode = qtrle_decode_frame,
> > -.capabilities   = AV_CODEC_CAP_DR1,
> > +.flush  = qtrle_flush,
> > +.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
> >  };
> > diff --git a/tests/ref/fate/qtrle-8bit b/tests/ref/fate/qtrle-8bit
> > index 27bb8aad71..39a03b7b6c 100644
> > --- a/tests/ref/fate/qtrle-8bit
> > +++ b/tests/ref/fate/qtrle-8bit
> > @@ -61,3 +61,4 @@
> >  0,160,160,1,   921600, 0xcfd6ad2b
> >  0,163,163,1,   921600, 0x3b372379
> >  0,165,165,1,   921600, 0x36f245f5
> > +0,166,166,1,   921600, 0x36f245f5
> 
> Does this actually work if there is a gap between the last frame and
> the previously changed frame?
> I'm not sure where it would save the proper timestamp.

i had tested it with this:
make -j12 && ./ffmpeg -i test.mov test%d.jpg

and it turned a case with a single frame and 10 skiped ones into 11 frames
so i assume it works. Do you have a case where it does not work ?

thx

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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]

2019-05-15 Thread Michael Niedermayer
On Wed, May 15, 2019 at 11:13:57PM +0200, Werner Robitza wrote:
> On Wed, May 15, 2019 at 4:55 PM Gyan  wrote:
> > On 15-05-2019 05:06 PM, Werner Robitza wrote:
> > > On Wed, May 15, 2019 at 11:36 AM Gyan  wrote:
> > >> Which lines in the CLI help?
> > > SWScaler AVOptions:
> > >-sws_flags   E..V. scaler flags (default 
> > > bicubic)
> > > ...
> > >-src_formatE..V. source format (default 
> > > yuv420p)
> > >-dst_formatE..V. destination format (default 
> > > yuv420p)
> > >-src_range E..V. source is full range 
> > > (default false)
> > >-dst_range E..V. destination is full range
> > > (default false)
> > >
> > >> I don't see any constants set in the AVOptions struct. Can you share a 
> > >> command line where you could set this option using a string?
> > > I was just going by the help printed above, including the default. If
> > > a string is not valid, which values are?
> > The help function fetches the string name for the default value but the
> > user has to input an integer.
> >
> > The pixel formats are declared in an enum in libavutil/pixfmt.h. The
> > integers correspond to their index in that list.
> 
> That seems very bad in terms of usability. Is there a particular
> reason why the "-pix_fmt" option can parse these values, but swscaler
> not? In fact, most (if not all) other options that accept a finite set
> of arguments don't use numbers in that way, but strings.
> I can add the integers to the documentation as a lookup table, but it
> feels weird doing so.

where exactly is a end user facing interface using integers for pix_fmt
in place of named identifers, can you show an example command line ?

Maybe there is some misunderstranding between end user facing interface
in API for lib users, interfacing with components through the C API would
use pixel format values which fundamentally are integers throughout the
various libs. But end user facing interface like what is accessed from
the command line should use human compatible string values

thx


> 
> > >>> +If set to 1, source range will be full range.
> > >> Mention the range of values possible and their meaning.
> > > I don't understand, as no other values are possible. Well, 0 is
> > > possible but meaningless since it's default; 1 indicates "true".
> > Sure, if the option name was is_src_range_full. But src_range allows you
> > to specify a range. So, even though there are only two, better to
> > mention the allowed values and their meaning.
> 
> Ok. Will send an update.
> ___
> 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".

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

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

Re: [FFmpeg-devel] [PATCH 2/2] configure: log_file: Replace pr with awk invocation

2019-05-15 Thread Alexander Strasser
Dropped.

Pushed Yejun's version instead:

[PATCH V5 2/2] configure: replace 'pr' with printf  since busybox does not 
support pr



On 2019-05-01 18:08 +0200, Alexander Strasser wrote:
> Fixes remaining part of ticket #5680
>
> Signed-off-by: Alexander Strasser 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 81e3776060..96ada8f636 100755
> --- a/configure
> +++ b/configure
> @@ -503,7 +503,7 @@ log(){
>
>  log_file(){
>  log BEGIN $1
> -pr -n -t $1 >> $logfile
> +awk '{ printf("%5d\t%s\n", NR, $0) }' $1 >> $logfile
>  log END $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]

2019-05-15 Thread Werner Robitza
On Wed, May 15, 2019 at 4:55 PM Gyan  wrote:
> On 15-05-2019 05:06 PM, Werner Robitza wrote:
> > On Wed, May 15, 2019 at 11:36 AM Gyan  wrote:
> >> Which lines in the CLI help?
> > SWScaler AVOptions:
> >-sws_flags   E..V. scaler flags (default bicubic)
> > ...
> >-src_formatE..V. source format (default yuv420p)
> >-dst_formatE..V. destination format (default 
> > yuv420p)
> >-src_range E..V. source is full range (default 
> > false)
> >-dst_range E..V. destination is full range
> > (default false)
> >
> >> I don't see any constants set in the AVOptions struct. Can you share a 
> >> command line where you could set this option using a string?
> > I was just going by the help printed above, including the default. If
> > a string is not valid, which values are?
> The help function fetches the string name for the default value but the
> user has to input an integer.
>
> The pixel formats are declared in an enum in libavutil/pixfmt.h. The
> integers correspond to their index in that list.

That seems very bad in terms of usability. Is there a particular
reason why the "-pix_fmt" option can parse these values, but swscaler
not? In fact, most (if not all) other options that accept a finite set
of arguments don't use numbers in that way, but strings.
I can add the integers to the documentation as a lookup table, but it
feels weird doing so.

> >>> +If set to 1, source range will be full range.
> >> Mention the range of values possible and their meaning.
> > I don't understand, as no other values are possible. Well, 0 is
> > possible but meaningless since it's default; 1 indicates "true".
> Sure, if the option name was is_src_range_full. But src_range allows you
> to specify a range. So, even though there are only two, better to
> mention the allowed values and their meaning.

Ok. Will send an update.
___
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 V5 2/2] configure: replace 'pr' with printf since busybox does not support pr

2019-05-15 Thread Alexander Strasser
On 2019-05-05 01:38 +, Guo, Yejun wrote:
>
> > -Original Message-
> > Alexander Strasser
> > Sent: Sunday, May 05, 2019 3:42 AM
> >
> > On 2019-04-28 00:38 +, Guo, Yejun wrote:
> > > > From: avih [mailto:avih...@yahoo.com]
> > > > Sent: Wednesday, April 24, 2019 9:23 PM
> > > > To: FFmpeg development discussions and patches
> > 
> > > > Cc: Guo, Yejun 
> > > > Subject: Re: [FFmpeg-devel] [PATCH V5 2/2] configure: replace 'pr' with
> > printf
> > > > since busybox does not support pr
> > > >
> > > > >  log_file(){
> > > > > -    log BEGIN $1
> > > > > -    pr -n -t $1 >> $logfile
> > > > > -    log END $1
> > > > > +    log BEGIN "$1"
> > > > > +    log_file_i=1
> > > > > +    while IFS= read -r log_file_line;do
> >
> >
> > > > > +    printf '%5s  %s\n' "${log_file_i}" "${log_file_line}"
> >
> > I would like to do minimal adjustment to the line quoted above:
> >
> >    printf '%5d\t%s\n' "$log_file_i" "$log_file_line"
>
> It's good.
>
> >
> > The \t makes the output equal to the current output. I would
> > prefer the %d because it makes the format a bit easier to grasp.
> >
> > The removed {} pairs around log_file_i and log_file_line, aren't
> > needed and without them the style should be more consistent.
> >
> >
> > > > > +    log_file_i=$(($log_file_i+1))
> > > > > +    done < "$1" >> "$logfile"
> > > > > +    log END "$1"
> > > > > }
> > > >
> > > > Looks good to me, no further comments (but I don't push).
> > >
> > > this patch set asks for push, or more comments, thanks.
> >
> > It's faster than the current pr implementation.
> >
> > If there are no objections to this patch in general and
> > to my suggested modifications in particular, I intent
> > to push it next week on friday.

Pushed.

Thanks to Yejun and Avi.


  Alexander
___
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] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

2019-05-15 Thread Hendrik Leppkes
On Wed, May 15, 2019 at 9:21 PM Adam Richter  wrote:
>
> On Tue, May 14, 2019 at 6:48 PM myp...@gmail.com  wrote:
> >
> > On Wed, May 15, 2019 at 7:01 AM Hendrik Leppkes  wrote:
> > >
> > > On Tue, May 14, 2019 at 11:25 PM Adam Richter  
> > > wrote:
> > > >
> > > > Consider, for example, if you agree that columnization makes this range 
> > > > check
> > > > more recognizable in a glance and makes it easier to spot what the 
> > > > bounds are
> > > > (the sixteen space indentation is taken from the code in which it 
> > > > appeared):
> > > >
> > > > av_assert0(par->bits_per_coded_sample >= 0 &&
> > > > par->bits_per_coded_sample <= 8);
> > > >
> > > > ...vs...
> > > >
> > > > av_assert0(par->bits_per_coded_sample >= 0);
> > > > av_assert0(par->bits_per_coded_sample <= 8);
> > > >
> > > > A possible counter-argument to this might be that, in a long sequence
> > > > of assertions, can be informative to group related assertions
> > > > together, which I think is true, but it is possible to get this other
> > > > means, such as by using blank lines to separate express such grouping.
> > > >
> > > > So, Mark, if you decide you are OK with my complete patches, I encourage
> > > > you to let me know.  Otherwise, if there are any of those changes which 
> > > > you
> > > > are OK with, I would like to just to to get those merged.  Finally, if 
> > > > you would
> > > > rather see none of those changes merged (one one to split the 
> > > > assertions in
> > > > libavformat and one was for everywhere else in ffmpeg), please let me 
> > > > know
> > > > about that too, in which case, if no one advocates for their
> > > > inclusion, I'll drop
> > > > my proposal to merge these changes.
> > > >
> > >
> > > Unfortunately I have to agree with Mark. asserst that check the same
> > > value or extremely closely related values should stay combined.
> > >
> > I agree this part
>
> I am trying to understand what problem you see with this.
>
> It occurs to me that you might be concerned about generating less
> efficient code for the common assert success case, in particular,
> in the example I showed for readability, potentially dereferencing
> "par" twice, but I made a test program (attached) and determined
> from reading the generated assembly that at least for gcc with
> optimization -O2 on x86_64, x86_32, aarch64 and arm32, as
> long as the abort function has "__attribute__ ((noreturn))", the
> compiler seems to be able to avoid repeating the memory fetch
> for the second assertion.  I also check this for clang -O2 on
> on x86_64.
>
> Of course, without the noreturn attribute on the abort function,
> the compiler realizes that the abort function could have written
> to memory, so it refetches the value in the split assertion case,
> which I think might have been your concern, but as long as
> the abort function is declared with an attribute noreturn, we
> should be OK for gcc.
>
> On the other hand, I'm not sure what compilers people use
> for other platforms such as Microsoft Windows and if you tell
> me that it is a known problem on a specific platform that is
> potentially relevant to ffmpeg, that would probably change my
> mind.
>
> Of course, it's not necessary for you change my mind or for
> you to invest further time in this discussion, as I imagine you
> and other participants have other things to do.  So, if I don't
> get a further explanation, I may still believe that you're wrong,
> but I'll respect your need to prioritize tasks other than continuing
> this discussion, and will not expect to see my proposed change
> merged unless the predominant opinion of others in this discussion
> changes to being in favor it, which, so far, I acknowledge, it is not.

You seem to be totally overthinking this. I'm not concerned about code
generation or anything like that, just the simple fact that I believe
that the checks are more logical and actually easier to understand if
they are logically grouped and combined. And I really don't see the
advantage in any of these changes, personally.

>
> > > >
> > > > Also after this, I may take a look at adding a branch hint to the 
> > > > av_assertN
> > > > macros if nobody objects.
> > > >
> > >
> > > Please don't, we don't do branch hints anywhere, and this is a bad
> > > place to start.
> > > If an assert is truely performance sensitive (as in, it makes a
> > > measurable difference), it should probably be moved from assert0 to
> > > assert1, and as such is only enabled in testing builds.
> > >
> > If assert0 or assert1 lead to performance drop, we need some profiling
> > data, then try to fix it.
>
> The above comments by Hendrick and you does not identify a cost to
> adding a branch hint to assert.  There would be a downside in the form of
> a few lines of code complexity in libavutil/avassert.h.  If that is
> your concern,
> I guess our disagreement is that I see reducing the cost of assert so that
> 

[FFmpeg-devel] [PATCH v3] avformat/ifv: added support for ifv cctv files

2019-05-15 Thread Swaraj Hota
Fixes ticket #2956.

Signed-off-by: Swaraj Hota 
---
Revised patch based on previous discussions.
Some of the changes are:
- using AVIndexEntry now
- demuxer is totally index based (removed linear search)
- added seeking functionality with timestamps 

There are some timing issues though, due to which seeking does not
work in the files with audio (works fine for files without audio).
I tried a lot but couldn't figure it out, maybe I don't understand
timing stuff clearly. Any suggestions regarding this will be really
helpful. Thanks in advance!

---
 Changelog|   1 +
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/ifv.c| 316 +++
 libavformat/version.h|   4 +-
 5 files changed, 321 insertions(+), 2 deletions(-)
 create mode 100644 libavformat/ifv.c

diff --git a/Changelog b/Changelog
index e6b209ae0a..e0b27657d7 100644
--- a/Changelog
+++ b/Changelog
@@ -30,6 +30,7 @@ version :
 - colorhold filter
 - xmedian filter
 - asr filter
+- IFV demuxer
 
 
 version 4.1:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..f68d41e4a5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -231,6 +231,7 @@ OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
 OBJS-$(CONFIG_IDCIN_DEMUXER) += idcin.o
 OBJS-$(CONFIG_IDF_DEMUXER)   += bintext.o sauce.o
 OBJS-$(CONFIG_IFF_DEMUXER)   += iff.o
+OBJS-$(CONFIG_IFV_DEMUXER)   += ifv.o
 OBJS-$(CONFIG_ILBC_DEMUXER)  += ilbc.o
 OBJS-$(CONFIG_ILBC_MUXER)+= ilbc.o
 OBJS-$(CONFIG_IMAGE2_DEMUXER)+= img2dec.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d316a0529a..cd00834807 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -188,6 +188,7 @@ extern AVOutputFormat ff_ico_muxer;
 extern AVInputFormat  ff_idcin_demuxer;
 extern AVInputFormat  ff_idf_demuxer;
 extern AVInputFormat  ff_iff_demuxer;
+extern AVInputFormat  ff_ifv_demuxer;
 extern AVInputFormat  ff_ilbc_demuxer;
 extern AVOutputFormat ff_ilbc_muxer;
 extern AVInputFormat  ff_image2_demuxer;
diff --git a/libavformat/ifv.c b/libavformat/ifv.c
new file mode 100644
index 00..c834b3b63c
--- /dev/null
+++ b/libavformat/ifv.c
@@ -0,0 +1,316 @@
+/*
+ * IFV demuxer
+ *
+ * Copyright (c) 2019 Swaraj Hota
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "internal.h"
+#include "avio_internal.h"
+
+
+typedef struct IFVContext {
+uint32_t next_video_index;
+uint32_t next_audio_index;
+uint32_t total_vframes;
+uint32_t total_aframes;
+
+int width, height;
+int is_audio_present;
+int sample_rate;
+
+int video_stream_index;
+int audio_stream_index;
+} IFVContext;
+
+static int ifv_probe(const AVProbeData *p)
+{
+static const uint8_t ifv_magic[] = {0x11, 0xd2, 0xd3, 0xab, 0xba, 0xa9,
+0xcf, 0x11, 0x8e, 0xe6, 0x00, 0xc0, 0x0c, 0x20, 0x53, 0x65, 0x44};
+
+if (!memcmp(p->buf, ifv_magic, sizeof(ifv_magic)))
+return AVPROBE_SCORE_MAX;
+
+return 0;
+}
+
+static int read_index(AVFormatContext *s,
+  enum AVMediaType frame_type,
+  uint32_t start_index)
+{
+IFVContext *ifv = s->priv_data;
+AVStream *st;
+int64_t pos, size, timestamp;
+uint32_t end_index, i;
+int ret;
+
+if (frame_type == AVMEDIA_TYPE_VIDEO) {
+end_index = ifv->total_vframes;
+st = s->streams[ifv->video_stream_index];
+} else {
+end_index = ifv->total_aframes;
+st = s->streams[ifv->audio_stream_index];
+}
+
+for (i = start_index; i < end_index; i++) {
+pos = avio_rl32(s->pb);
+size = avio_rl32(s->pb);
+
+avio_skip(s->pb, 8);
+timestamp = avio_rl32(s->pb);
+
+ret = av_add_index_entry(st, pos, timestamp, size, 0, 0);
+if (ret < 0)
+return ret;
+
+avio_skip(s->pb, frame_type == AVMEDIA_TYPE_VIDEO? 8: 4);
+}
+
+return 0;
+}
+
+static int parse_header(AVFormatContext *s)
+{
+IFVContext *ifv = s->priv_data;
+uint32_t aud_magic;
+uint32_t vid_magic;
+
+avio_skip(s->pb, 0x5c);
+ifv->width = avio_rl16(s->pb);

Re: [FFmpeg-devel] [PATCH] avcodec/qtrle: return last frame even if unchanged

2019-05-15 Thread Hendrik Leppkes
On Wed, May 15, 2019 at 8:41 PM Michael Niedermayer
 wrote:
>
> Fixes: Ticket7880
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/qtrle.c| 27 +--
>  tests/ref/fate/qtrle-8bit |  1 +
>  2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
> index 2c29547e5a..11226cb842 100644
> --- a/libavcodec/qtrle.c
> +++ b/libavcodec/qtrle.c
> @@ -45,6 +45,7 @@ typedef struct QtrleContext {
>
>  GetByteContext g;
>  uint32_t pal[256];
> +int need_flush;
>  } QtrleContext;
>
>  #define CHECK_PIXEL_PTR(n)   
>  \
> @@ -444,6 +445,12 @@ static av_cold int qtrle_decode_init(AVCodecContext 
> *avctx)
>  return 0;
>  }
>
> +static void qtrle_flush(AVCodecContext *avctx){
> +QtrleContext *s = avctx->priv_data;
> +
> +s->need_flush = 0;
> +}
> +
>  static int qtrle_decode_frame(AVCodecContext *avctx,
>void *data, int *got_frame,
>AVPacket *avpkt)
> @@ -454,11 +461,26 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
>  int has_palette = 0;
>  int ret, size;
>
> +if (!avpkt->data) {
> +if (s->need_flush) {
> +s->need_flush = 0;
> +if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
> +return ret;
> +if ((ret = av_frame_ref(data, s->frame)) < 0)
> +return ret;
> +*got_frame = 1;
> +}
> +return 0;
> +}
> +
>  bytestream2_init(>g, avpkt->data, avpkt->size);
>
>  /* check if this frame is even supposed to change */
> -if (avpkt->size < 8)
> +if (avpkt->size < 8) {
> +s->need_flush = 1;
>  return avpkt->size;
> +}
> +s->need_flush = 0;
>
>  /* start after the chunk size */
>  size = bytestream2_get_be32(>g) & 0x3FFF;
> @@ -572,5 +594,6 @@ AVCodec ff_qtrle_decoder = {
>  .init   = qtrle_decode_init,
>  .close  = qtrle_decode_end,
>  .decode = qtrle_decode_frame,
> -.capabilities   = AV_CODEC_CAP_DR1,
> +.flush  = qtrle_flush,
> +.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
>  };
> diff --git a/tests/ref/fate/qtrle-8bit b/tests/ref/fate/qtrle-8bit
> index 27bb8aad71..39a03b7b6c 100644
> --- a/tests/ref/fate/qtrle-8bit
> +++ b/tests/ref/fate/qtrle-8bit
> @@ -61,3 +61,4 @@
>  0,160,160,1,   921600, 0xcfd6ad2b
>  0,163,163,1,   921600, 0x3b372379
>  0,165,165,1,   921600, 0x36f245f5
> +0,166,166,1,   921600, 0x36f245f5

Does this actually work if there is a gap between the last frame and
the previously changed frame?
I'm not sure where it would save the proper timestamp.

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

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

Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: add support for per frame rotation and flip

2019-05-15 Thread Andriy Gelman
On Wed, 15. May 11:57, Jun Li wrote:
> On Wed, May 15, 2019 at 11:45 AM Andriy Gelman 
> wrote:
> 
> > On Tue, 14. May 22:36, Jun Li wrote:
> > > Fix #6945
> > > Current implementaion for autorotate works fine for stream
> > > level rotataion but no support for frame level operation
> > > and frame flip. This patch is for adding flip support and
> > > per frame operations.
> > > ---
> > >  fftools/cmdutils.c  |  9 ++---
> > >  fftools/cmdutils.h  |  2 +-
> > >  fftools/ffmpeg.c| 21 ++-
> > >  fftools/ffmpeg.h|  2 +
> > >  fftools/ffmpeg_filter.c | 81 ++---
> > >  fftools/ffplay.c| 28 +++---
> > >  6 files changed, 126 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> > > index 9cfbc45c2b..b8bb904419 100644
> > > --- a/fftools/cmdutils.c
> > > +++ b/fftools/cmdutils.c
> > > @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int
> > *size, int new_size)
> > >  return array;
> > >  }
> > >
> > > -double get_rotation(AVStream *st)
> > > +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
> > >  {
> > > -uint8_t* displaymatrix = av_stream_get_side_data(st,
> > > -
> >  AV_PKT_DATA_DISPLAYMATRIX, NULL);
> > >  double theta = 0;
> > > -if (displaymatrix)
> > > -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> > > +
> > > +if (display_matrix)
> > > +theta = -av_display_rotation_hflip_get(display_matrix, hflip);
> > >
> > >  theta -= 360*floor(theta/360 + 0.9/360);
> > >
> > > diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> > > index 6e2e0a2acb..dce44ed6e1 100644
> > > --- a/fftools/cmdutils.h
> > > +++ b/fftools/cmdutils.h
> > > @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int
> > *size, int new_size);
> > >  char name[128];\
> > >  av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
> > >
> > > -double get_rotation(AVStream *st);
> > > +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
> > >
> > >  #endif /* FFTOOLS_CMDUTILS_H */
> > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > > index 01f04103cf..9ea1aaa930 100644
> > > --- a/fftools/ffmpeg.c
> > > +++ b/fftools/ffmpeg.c
> > > @@ -2126,6 +2126,24 @@ static int
> > ifilter_has_all_input_formats(FilterGraph *fg)
> > >  return 1;
> > >  }
> > >
> > > +static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter,
> > AVFrame* frame)
> > > +{
> > > +int32_t* stream_matrix =
> > (int32_t*)av_stream_get_side_data(ifilter->ist->st,
> > > +
> > AV_PKT_DATA_DISPLAYMATRIX, NULL);
> > > +// if we already have display matrix from stream, use it instead of
> > extracting
> > > +// from frame.
> > > +if (stream_matrix) {
> > > +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
> > > +return 0;
> > > +}
> > > +
> > > +// cleanup the display matrix, may be from last frame
> > > +memset(ifilter->display_matrix, 0, 4 * 9);
> > > +av_display_rotation_set(ifilter->display_matrix, 0);
> > > +
> > > +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> > > +}
> > > +
> > >  static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
> > >  {
> > >  FilterGraph *fg = ifilter->graph;
> > > @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter
> > *ifilter, AVFrame *frame)
> > > ifilter->channel_layout != frame->channel_layout;
> > >  break;
> > >  case AVMEDIA_TYPE_VIDEO:
> > > -need_reinit |= ifilter->width  != frame->width ||
> > > +need_reinit |= ifilter_display_matrix_need_from_frame(ifilter,
> > frame) ||
> > > +   ifilter->width  != frame->width ||
> > > ifilter->height != frame->height;
> > >  break;
> > >  }
> > > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > > index eb1eaf6363..8331720663 100644
> > > --- a/fftools/ffmpeg.h
> > > +++ b/fftools/ffmpeg.h
> > > @@ -251,6 +251,8 @@ typedef struct InputFilter {
> > >  int channels;
> > >  uint64_t channel_layout;
> > >
> > > +int32_t display_matrix[9];
> > > +
> > >  AVBufferRef *hw_frames_ctx;
> > >
> > >  int eof;
> > > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > > index 72838de1e2..1894f30561 100644
> > > --- a/fftools/ffmpeg_filter.c
> > > +++ b/fftools/ffmpeg_filter.c
> > > @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg,
> > AVFilterInOut *in)
> > >  fg->inputs[fg->nb_inputs - 1]->format = -1;
> > >  fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
> > >  fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in,
> > 1);
> > > +av_display_rotation_set(fg->inputs[fg->nb_inputs -
> > 1]->display_matrix, 0);
> > >
> > >  fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 *
> > sizeof(AVFrame*));
> > >  if 

Re: [FFmpeg-devel] [PATCH] libavformat/qsvenc: fix mpeg2 missing headers

2019-05-15 Thread Andreas Rheinhardt
Reimar Döffinger:
> On Wed, May 15, 2019 at 09:39:00AM +, Andreas Rheinhardt wrote:
>>> This problem really needs to be solved. The bitstream generated breaks the 
>>> standard!
>>>
>> If I am not mistaken, then the bitstream generated doesn't break the
>> standard; it is just inconvenient for streaming purposes.
> 
> (sorry if it's nonsense, I did not investigate in detail)
> If the problem to solve is to ensure headers are regularly
> repeated, that does not sound like a QSV-specific problem
> and more a job for a bitstream filter.
> There might even be code like that already for the
> case when we convert from formats with global headers
> to formats like MPEG-TS that want them repeated.
There's actually a dump_extra bitstream filter.

- 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] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

2019-05-15 Thread Adam Richter
On Tue, May 14, 2019 at 6:48 PM myp...@gmail.com  wrote:
>
> On Wed, May 15, 2019 at 7:01 AM Hendrik Leppkes  wrote:
> >
> > On Tue, May 14, 2019 at 11:25 PM Adam Richter  
> > wrote:
> > >
> > > Consider, for example, if you agree that columnization makes this range 
> > > check
> > > more recognizable in a glance and makes it easier to spot what the bounds 
> > > are
> > > (the sixteen space indentation is taken from the code in which it 
> > > appeared):
> > >
> > > av_assert0(par->bits_per_coded_sample >= 0 &&
> > > par->bits_per_coded_sample <= 8);
> > >
> > > ...vs...
> > >
> > > av_assert0(par->bits_per_coded_sample >= 0);
> > > av_assert0(par->bits_per_coded_sample <= 8);
> > >
> > > A possible counter-argument to this might be that, in a long sequence
> > > of assertions, can be informative to group related assertions
> > > together, which I think is true, but it is possible to get this other
> > > means, such as by using blank lines to separate express such grouping.
> > >
> > > So, Mark, if you decide you are OK with my complete patches, I encourage
> > > you to let me know.  Otherwise, if there are any of those changes which 
> > > you
> > > are OK with, I would like to just to to get those merged.  Finally, if 
> > > you would
> > > rather see none of those changes merged (one one to split the assertions 
> > > in
> > > libavformat and one was for everywhere else in ffmpeg), please let me know
> > > about that too, in which case, if no one advocates for their
> > > inclusion, I'll drop
> > > my proposal to merge these changes.
> > >
> >
> > Unfortunately I have to agree with Mark. asserst that check the same
> > value or extremely closely related values should stay combined.
> >
> I agree this part

I am trying to understand what problem you see with this.

It occurs to me that you might be concerned about generating less
efficient code for the common assert success case, in particular,
in the example I showed for readability, potentially dereferencing
"par" twice, but I made a test program (attached) and determined
from reading the generated assembly that at least for gcc with
optimization -O2 on x86_64, x86_32, aarch64 and arm32, as
long as the abort function has "__attribute__ ((noreturn))", the
compiler seems to be able to avoid repeating the memory fetch
for the second assertion.  I also check this for clang -O2 on
on x86_64.

Of course, without the noreturn attribute on the abort function,
the compiler realizes that the abort function could have written
to memory, so it refetches the value in the split assertion case,
which I think might have been your concern, but as long as
the abort function is declared with an attribute noreturn, we
should be OK for gcc.

On the other hand, I'm not sure what compilers people use
for other platforms such as Microsoft Windows and if you tell
me that it is a known problem on a specific platform that is
potentially relevant to ffmpeg, that would probably change my
mind.

Of course, it's not necessary for you change my mind or for
you to invest further time in this discussion, as I imagine you
and other participants have other things to do.  So, if I don't
get a further explanation, I may still believe that you're wrong,
but I'll respect your need to prioritize tasks other than continuing
this discussion, and will not expect to see my proposed change
merged unless the predominant opinion of others in this discussion
changes to being in favor it, which, so far, I acknowledge, it is not.

> > >
> > > Also after this, I may take a look at adding a branch hint to the 
> > > av_assertN
> > > macros if nobody objects.
> > >
> >
> > Please don't, we don't do branch hints anywhere, and this is a bad
> > place to start.
> > If an assert is truely performance sensitive (as in, it makes a
> > measurable difference), it should probably be moved from assert0 to
> > assert1, and as such is only enabled in testing builds.
> >
> If assert0 or assert1 lead to performance drop, we need some profiling
> data, then try to fix it.

The above comments by Hendrick and you does not identify a cost to
adding a branch hint to assert.  There would be a downside in the form of
a few lines of code complexity in libavutil/avassert.h.  If that is
your concern,
I guess our disagreement is that I see reducing the cost of assert so that
perhaps CPU usage with and without would be a tiny bit more similar for
reproducing problems and maybe (I'm not saying it's likely) it might tip a
trade-off in favor of keeping an assert enabled in some borderline
circumstance.  I'd take that trade (add the branch prediction).

If you want to educate me on some other reason why I may be wrong,
about adding the branch prediction for assertion checks, I'd been keen
to know, but I realize everyone's time is limited, and if I haven't
convinced you and also created consensus in favor of adding the
branch prediction to assertion 

Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: add support for per frame rotation and flip

2019-05-15 Thread Jun Li
On Wed, May 15, 2019 at 11:45 AM Andriy Gelman 
wrote:

> On Tue, 14. May 22:36, Jun Li wrote:
> > Fix #6945
> > Current implementaion for autorotate works fine for stream
> > level rotataion but no support for frame level operation
> > and frame flip. This patch is for adding flip support and
> > per frame operations.
> > ---
> >  fftools/cmdutils.c  |  9 ++---
> >  fftools/cmdutils.h  |  2 +-
> >  fftools/ffmpeg.c| 21 ++-
> >  fftools/ffmpeg.h|  2 +
> >  fftools/ffmpeg_filter.c | 81 ++---
> >  fftools/ffplay.c| 28 +++---
> >  6 files changed, 126 insertions(+), 17 deletions(-)
> >
> > diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> > index 9cfbc45c2b..b8bb904419 100644
> > --- a/fftools/cmdutils.c
> > +++ b/fftools/cmdutils.c
> > @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size)
> >  return array;
> >  }
> >
> > -double get_rotation(AVStream *st)
> > +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
> >  {
> > -uint8_t* displaymatrix = av_stream_get_side_data(st,
> > -
>  AV_PKT_DATA_DISPLAYMATRIX, NULL);
> >  double theta = 0;
> > -if (displaymatrix)
> > -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> > +
> > +if (display_matrix)
> > +theta = -av_display_rotation_hflip_get(display_matrix, hflip);
> >
> >  theta -= 360*floor(theta/360 + 0.9/360);
> >
> > diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> > index 6e2e0a2acb..dce44ed6e1 100644
> > --- a/fftools/cmdutils.h
> > +++ b/fftools/cmdutils.h
> > @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size);
> >  char name[128];\
> >  av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
> >
> > -double get_rotation(AVStream *st);
> > +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
> >
> >  #endif /* FFTOOLS_CMDUTILS_H */
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 01f04103cf..9ea1aaa930 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -2126,6 +2126,24 @@ static int
> ifilter_has_all_input_formats(FilterGraph *fg)
> >  return 1;
> >  }
> >
> > +static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter,
> AVFrame* frame)
> > +{
> > +int32_t* stream_matrix =
> (int32_t*)av_stream_get_side_data(ifilter->ist->st,
> > +
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
> > +// if we already have display matrix from stream, use it instead of
> extracting
> > +// from frame.
> > +if (stream_matrix) {
> > +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
> > +return 0;
> > +}
> > +
> > +// cleanup the display matrix, may be from last frame
> > +memset(ifilter->display_matrix, 0, 4 * 9);
> > +av_display_rotation_set(ifilter->display_matrix, 0);
> > +
> > +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> > +}
> > +
> >  static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
> >  {
> >  FilterGraph *fg = ifilter->graph;
> > @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter
> *ifilter, AVFrame *frame)
> > ifilter->channel_layout != frame->channel_layout;
> >  break;
> >  case AVMEDIA_TYPE_VIDEO:
> > -need_reinit |= ifilter->width  != frame->width ||
> > +need_reinit |= ifilter_display_matrix_need_from_frame(ifilter,
> frame) ||
> > +   ifilter->width  != frame->width ||
> > ifilter->height != frame->height;
> >  break;
> >  }
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index eb1eaf6363..8331720663 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -251,6 +251,8 @@ typedef struct InputFilter {
> >  int channels;
> >  uint64_t channel_layout;
> >
> > +int32_t display_matrix[9];
> > +
> >  AVBufferRef *hw_frames_ctx;
> >
> >  int eof;
> > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > index 72838de1e2..1894f30561 100644
> > --- a/fftools/ffmpeg_filter.c
> > +++ b/fftools/ffmpeg_filter.c
> > @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg,
> AVFilterInOut *in)
> >  fg->inputs[fg->nb_inputs - 1]->format = -1;
> >  fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
> >  fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in,
> 1);
> > +av_display_rotation_set(fg->inputs[fg->nb_inputs -
> 1]->display_matrix, 0);
> >
> >  fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 *
> sizeof(AVFrame*));
> >  if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
> > @@ -807,22 +808,43 @@ static int
> configure_input_video_filter(FilterGraph *fg, InputFilter *ifilter,
> >  last_filter = ifilter->filter;
> >
> >  if (ist->autorotate) {
> > -double theta = get_rotation(ist->st);
> > +int 

Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: add support for per frame rotation and flip

2019-05-15 Thread Jun Li
On Wed, May 15, 2019 at 5:18 AM Andriy Gelman 
wrote:

> On Tue, 14. May 22:36, Jun Li wrote:
> > Fix #6945
> > Current implementaion for autorotate works fine for stream
> > level rotataion but no support for frame level operation
> > and frame flip. This patch is for adding flip support and
> > per frame operations.
> > ---
> >  fftools/cmdutils.c  |  9 ++---
> >  fftools/cmdutils.h  |  2 +-
> >  fftools/ffmpeg.c| 21 ++-
> >  fftools/ffmpeg.h|  2 +
> >  fftools/ffmpeg_filter.c | 81 ++---
> >  fftools/ffplay.c| 28 +++---
> >  6 files changed, 126 insertions(+), 17 deletions(-)
> >
> > diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> > index 9cfbc45c2b..b8bb904419 100644
> > --- a/fftools/cmdutils.c
> > +++ b/fftools/cmdutils.c
> > @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size)
> >  return array;
> >  }
> >
> > -double get_rotation(AVStream *st)
> > +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
> >  {
> > -uint8_t* displaymatrix = av_stream_get_side_data(st,
> > -
>  AV_PKT_DATA_DISPLAYMATRIX, NULL);
> >  double theta = 0;
> > -if (displaymatrix)
> > -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> > +
> > +if (display_matrix)
> > +theta = -av_display_rotation_hflip_get(display_matrix, hflip);
> >
> >  theta -= 360*floor(theta/360 + 0.9/360);
> >
> > diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> > index 6e2e0a2acb..dce44ed6e1 100644
> > --- a/fftools/cmdutils.h
> > +++ b/fftools/cmdutils.h
> > @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size);
> >  char name[128];\
> >  av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
> >
> > -double get_rotation(AVStream *st);
> > +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
> >
> >  #endif /* FFTOOLS_CMDUTILS_H */
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 01f04103cf..9ea1aaa930 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -2126,6 +2126,24 @@ static int
> ifilter_has_all_input_formats(FilterGraph *fg)
> >  return 1;
> >  }
> >
> > +static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter,
> AVFrame* frame)
> > +{
> > +int32_t* stream_matrix =
> (int32_t*)av_stream_get_side_data(ifilter->ist->st,
> > +
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
> > +// if we already have display matrix from stream, use it instead of
> extracting
> > +// from frame.
> > +if (stream_matrix) {
> > +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
>
> would it be better to use sizeof?
> memcpy(ifilter->display_matrix, stream_matrix, sizeof(int32_t) * 9);
>

Hi Andriy,
Thanks for the review. I was suggested to use constant instead of
sizeof(type) in previous patch:
https://patchwork.ffmpeg.org/patch/13000/
I cannot think of any case that sizeof(int32_t) is not '4', so they mean
the same for me from code correctness perspective.
Of course from coding habit or design perspective, there might have some
different opinions and discussion.
So I am going to keep the constant '4' here unless it is not a correct
value in any case.

Thanks,
-Jun


> > +return 0;
> > +}
> > +
> > +// cleanup the display matrix, may be from last frame
> > +memset(ifilter->display_matrix, 0, 4 * 9);
>
> memset(ifilter->display_matrix, 0, sizeof(int32_t) * 9);
>
> > +av_display_rotation_set(ifilter->display_matrix, 0);
> > +
> > +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> > +}
> > +
> >  static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
> >  {
> >  FilterGraph *fg = ifilter->graph;
> > @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter
> *ifilter, AVFrame *frame)
> > ifilter->channel_layout != frame->channel_layout;
> >  break;
> >  case AVMEDIA_TYPE_VIDEO:
> > -need_reinit |= ifilter->width  != frame->width ||
> > +need_reinit |= ifilter_display_matrix_need_from_frame(ifilter,
> frame) ||
> > +   ifilter->width  != frame->width ||
> > ifilter->height != frame->height;
> >  break;
> >  }
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index eb1eaf6363..8331720663 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -251,6 +251,8 @@ typedef struct InputFilter {
> >  int channels;
> >  uint64_t channel_layout;
> >
> > +int32_t display_matrix[9];
> > +
> >  AVBufferRef *hw_frames_ctx;
> >
> >  int eof;
> > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > index 72838de1e2..1894f30561 100644
> > --- a/fftools/ffmpeg_filter.c
> > +++ b/fftools/ffmpeg_filter.c
> > @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg,
> AVFilterInOut *in)
> >  fg->inputs[fg->nb_inputs - 

Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: add support for per frame rotation and flip

2019-05-15 Thread Andriy Gelman
On Tue, 14. May 22:36, Jun Li wrote:
> Fix #6945
> Current implementaion for autorotate works fine for stream
> level rotataion but no support for frame level operation
> and frame flip. This patch is for adding flip support and
> per frame operations.
> ---
>  fftools/cmdutils.c  |  9 ++---
>  fftools/cmdutils.h  |  2 +-
>  fftools/ffmpeg.c| 21 ++-
>  fftools/ffmpeg.h|  2 +
>  fftools/ffmpeg_filter.c | 81 ++---
>  fftools/ffplay.c| 28 +++---
>  6 files changed, 126 insertions(+), 17 deletions(-)
> 
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 9cfbc45c2b..b8bb904419 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int 
> *size, int new_size)
>  return array;
>  }
>  
> -double get_rotation(AVStream *st)
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
>  {
> -uint8_t* displaymatrix = av_stream_get_side_data(st,
> - 
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
>  double theta = 0;
> -if (displaymatrix)
> -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> +
> +if (display_matrix)
> +theta = -av_display_rotation_hflip_get(display_matrix, hflip);
>  
>  theta -= 360*floor(theta/360 + 0.9/360);
>  
> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> index 6e2e0a2acb..dce44ed6e1 100644
> --- a/fftools/cmdutils.h
> +++ b/fftools/cmdutils.h
> @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int *size, 
> int new_size);
>  char name[128];\
>  av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
>  
> -double get_rotation(AVStream *st);
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
>  
>  #endif /* FFTOOLS_CMDUTILS_H */
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 01f04103cf..9ea1aaa930 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2126,6 +2126,24 @@ static int ifilter_has_all_input_formats(FilterGraph 
> *fg)
>  return 1;
>  }
>  
> +static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter, 
> AVFrame* frame)
> +{
> +int32_t* stream_matrix = 
> (int32_t*)av_stream_get_side_data(ifilter->ist->st, 
> +AV_PKT_DATA_DISPLAYMATRIX, 
> NULL);
> +// if we already have display matrix from stream, use it instead of 
> extracting
> +// from frame.
> +if (stream_matrix) {
> +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
> +return 0;
> +}
> +
> +// cleanup the display matrix, may be from last frame
> +memset(ifilter->display_matrix, 0, 4 * 9);
> +av_display_rotation_set(ifilter->display_matrix, 0);
> +
> +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> +}
> +
>  static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
>  {
>  FilterGraph *fg = ifilter->graph;
> @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter *ifilter, 
> AVFrame *frame)
> ifilter->channel_layout != frame->channel_layout;
>  break;
>  case AVMEDIA_TYPE_VIDEO:
> -need_reinit |= ifilter->width  != frame->width ||
> +need_reinit |= ifilter_display_matrix_need_from_frame(ifilter, 
> frame) ||
> +   ifilter->width  != frame->width ||
> ifilter->height != frame->height;
>  break;
>  }
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index eb1eaf6363..8331720663 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -251,6 +251,8 @@ typedef struct InputFilter {
>  int channels;
>  uint64_t channel_layout;
>  
> +int32_t display_matrix[9];
> +
>  AVBufferRef *hw_frames_ctx;
>  
>  int eof;
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 72838de1e2..1894f30561 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg, 
> AVFilterInOut *in)
>  fg->inputs[fg->nb_inputs - 1]->format = -1;
>  fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
>  fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in, 1);
> +av_display_rotation_set(fg->inputs[fg->nb_inputs - 1]->display_matrix, 
> 0);
>  
>  fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 * 
> sizeof(AVFrame*));
>  if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
> @@ -807,22 +808,43 @@ static int configure_input_video_filter(FilterGraph 
> *fg, InputFilter *ifilter,
>  last_filter = ifilter->filter;
>  
>  if (ist->autorotate) {
> -double theta = get_rotation(ist->st);
> +int hflip = 0;
> +double theta = get_rotation_hflip(ifilter->display_matrix, );
>  
> -if (fabs(theta - 90) < 1.0) {
> +if (fabs(theta) < 

[FFmpeg-devel] [PATCH] avcodec/qtrle: return last frame even if unchanged

2019-05-15 Thread Michael Niedermayer
Fixes: Ticket7880

Signed-off-by: Michael Niedermayer 
---
 libavcodec/qtrle.c| 27 +--
 tests/ref/fate/qtrle-8bit |  1 +
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index 2c29547e5a..11226cb842 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -45,6 +45,7 @@ typedef struct QtrleContext {
 
 GetByteContext g;
 uint32_t pal[256];
+int need_flush;
 } QtrleContext;
 
 #define CHECK_PIXEL_PTR(n) 
   \
@@ -444,6 +445,12 @@ static av_cold int qtrle_decode_init(AVCodecContext *avctx)
 return 0;
 }
 
+static void qtrle_flush(AVCodecContext *avctx){
+QtrleContext *s = avctx->priv_data;
+
+s->need_flush = 0;
+}
+
 static int qtrle_decode_frame(AVCodecContext *avctx,
   void *data, int *got_frame,
   AVPacket *avpkt)
@@ -454,11 +461,26 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
 int has_palette = 0;
 int ret, size;
 
+if (!avpkt->data) {
+if (s->need_flush) {
+s->need_flush = 0;
+if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+return ret;
+if ((ret = av_frame_ref(data, s->frame)) < 0)
+return ret;
+*got_frame = 1;
+}
+return 0;
+}
+
 bytestream2_init(>g, avpkt->data, avpkt->size);
 
 /* check if this frame is even supposed to change */
-if (avpkt->size < 8)
+if (avpkt->size < 8) {
+s->need_flush = 1;
 return avpkt->size;
+}
+s->need_flush = 0;
 
 /* start after the chunk size */
 size = bytestream2_get_be32(>g) & 0x3FFF;
@@ -572,5 +594,6 @@ AVCodec ff_qtrle_decoder = {
 .init   = qtrle_decode_init,
 .close  = qtrle_decode_end,
 .decode = qtrle_decode_frame,
-.capabilities   = AV_CODEC_CAP_DR1,
+.flush  = qtrle_flush,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
 };
diff --git a/tests/ref/fate/qtrle-8bit b/tests/ref/fate/qtrle-8bit
index 27bb8aad71..39a03b7b6c 100644
--- a/tests/ref/fate/qtrle-8bit
+++ b/tests/ref/fate/qtrle-8bit
@@ -61,3 +61,4 @@
 0,160,160,1,   921600, 0xcfd6ad2b
 0,163,163,1,   921600, 0x3b372379
 0,165,165,1,   921600, 0x36f245f5
+0,166,166,1,   921600, 0x36f245f5
-- 
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 v2] libavutil: add an FFT & MDCT implementation

2019-05-15 Thread Reimar Döffinger
On Tue, May 14, 2019 at 08:41:02PM +0200, Lynne wrote:
> May 14, 2019, 7:12 PM by one...@gmail.com:
> > On 5/14/19, Carl Eugen Hoyos <> ceffm...@gmail.com 
> > > > wrote:
> >>> Am 14.05.2019 um 19:17 schrieb Lynne <>>> d...@lynne.ee 
> >>> :
> >>>
> >>> I've attached the latest version.
> >>>
> >>
> >> This patch is still not ok, please do not commit.
> >>
> >
> > I will and you can not stop me.
> >
>
> Attached a version with fft-template.c's copyright and mine like James 
> suggested
> so the fighting can at least somewhat stop and I can write some SIMD.

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] libavformat/qsvenc: fix mpeg2 missing headers

2019-05-15 Thread Reimar Döffinger
On Wed, May 15, 2019 at 09:39:00AM +, Andreas Rheinhardt wrote:
> > This problem really needs to be solved. The bitstream generated breaks the 
> > standard!
> >
> If I am not mistaken, then the bitstream generated doesn't break the
> standard; it is just inconvenient for streaming purposes.

(sorry if it's nonsense, I did not investigate in detail)
If the problem to solve is to ensure headers are regularly
repeated, that does not sound like a QSV-specific problem
and more a job for a bitstream filter.
There might even be code like that already for the
case when we convert from formats with global headers
to formats like MPEG-TS that want them repeated.
___
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] Populate MPEG2TS codec_tag using ff_codec_movvideo_tags/ff_codec_movaudio_tags (av4cc) rather than the PES stream_type. For MPEG2TS files containing h264, ffprobe currently

2019-05-15 Thread Hendrik Leppkes
On Wed, May 15, 2019 at 6:15 PM Damien Levin
 wrote:
>
> ---
>  libavformat/mpegts.c  | 9 +++--
>  tests/ref/fate/concat-demuxer-simple2-lavf-ts | 4 ++--
>  2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 8a84e5cc19..79c0b78b1f 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -877,6 +877,13 @@ static void mpegts_find_stream_type(AVStream *st,
>  st->codecpar->codec_id   != types->codec_id) {
>  st->codecpar->codec_type = types->codec_type;
>  st->codecpar->codec_id   = types->codec_id;
> +if (types->codec_type == AVMEDIA_TYPE_VIDEO) {
> +st->codecpar->codec_tag =
> +ff_codec_get_tag(ff_codec_movvideo_tags, 
> types->codec_id);
> +} else if (types->codec_type == AVMEDIA_TYPE_AUDIO) {
> +st->codecpar->codec_tag =
> +ff_codec_get_tag(ff_codec_movaudio_tags, 
> types->codec_id);
> +}
>  st->internal->need_context_update = 1;
>  }
>  st->request_probe= 0;
> @@ -908,8 +915,6 @@ static int mpegts_set_stream_info(AVStream *st, 
> PESContext *pes,
> "stream=%d stream_type=%x pid=%x prog_reg_desc=%.4s\n",
> st->index, pes->stream_type, pes->pid, (char *)_reg_desc);
>
> -st->codecpar->codec_tag = pes->stream_type;
> -

The current behavior is correct, per the documentation of the field:
" A demuxer should set this to what is stored in the field used to
identify the codec."

Arbitrarily setting the field from a table without any relation to the
container is definitely not correct. If a user wants to know the tag
to be used in mov/mp4, they can determine that independently, but not
from the mpegts demuxer. This field is container-specific, and as such
exporting the pes stream type is actually the correct thing to do.

On a personal note, I actually use that value to detect certain
streams from Blu-rays and their secondary meaning, since every pes
stream type is clearly defined, the value can be used to eg. identify
if an audio stream is primary or secondary audio.

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

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

Re: [FFmpeg-devel] [PATCH 1/2] Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input"

2019-05-15 Thread Michael Niedermayer
On Tue, May 14, 2019 at 10:31:00PM +0200, Marton Balint wrote:
> 
> 
> On Wed, 8 May 2019, Michael Niedermayer wrote:
> 
> >On Tue, May 07, 2019 at 02:03:22AM +0200, Marton Balint wrote:
> >>
> >>
> >>On Tue, 7 May 2019, Michael Niedermayer wrote:
> >>
> >>>On Sun, May 05, 2019 at 08:51:08PM +0200, Marton Balint wrote:
> This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.
> 
> I don't think it is a good idea to drop frames from CFR input just 
> because they
> are duplicated, that can cause issues for API users expecting CFR input. 
> Also
> it can cause issues at the end of file, if the last frame is a duplicated
> frame.
> 
> Fixes ticket #7880.
> 
> Signed-off-by: Marton Balint 
> ---
> libavcodec/qtrle.c|  12 ++---
> tests/ref/fate/qtrle-8bit | 109 
> ++
> 2 files changed, 115 insertions(+), 6 deletions(-)
> >>>
> >>>This change would make the decoder quite a bit slower.
> >>
> >>I guess that can be easily fixed by only copying the buffer if it really is
> >>a different frame.
> >>
> >>>It also would make encoding the output harder.
> >>>For example motion estimation would be run over unchanged frames even when
> >>>no cfr is wanted.
> >>
> >>The performance penalty is much more acceptable to me than the issue
> >>described in the ticket. Do you see a straightforward way to fix it other
> >>than reverting?
> >
> >decoders can in general have frames at the end which need to be flushed
> >out. For example IPB mpeg1/2/4/...
> >In the same way the decoder could output a last frame representing the end
> >exactly
> 
> Yeah, that probably would fix the ticket. However I am still worried that it
> is just a matter of time before somebody reports something else that is
> broken because of VFR and unknown frame duration.
> 

> Do you plan on working on fixing the ticket? It is a regression, so
> prefeably it should either be fixed in a reasonable time frame or if nobody
> is willing to do it then we should revert.

ill post a patch that implements the last frame flush idea. 

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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 v2] libavutil: add an FFT & MDCT implementation

2019-05-15 Thread James Almer
On 5/15/2019 2:57 PM, Lynne wrote:
> May 14, 2019, 7:41 PM by d...@lynne.ee:
> 
>> May 14, 2019, 7:12 PM by > one...@gmail.com > :
>>
>>> On 5/14/19, Carl Eugen Hoyos <> >> ceffm...@gmail.com 
>>> >>  > ceffm...@gmail.com 
>>> >> >> > wrote:
>>>



> Am 14.05.2019 um 19:17 schrieb Lynne <>>>  d...@lynne.ee 
>   >>> d...@lynne.ee 
>   >:
>
> I've attached the latest version.
>

 This patch is still not ok, please do not commit.

>>>
>>> I will and you can not stop me.
>>>
>>
>> Attached a version with fft-template.c's copyright and mine like James 
>> suggested
>> so the fighting can at least somewhat stop and I can write some SIMD.
>>
>>> +/*
>>> + * Copyright (c) 2019 Lynne <>> d...@lynne.ee >>  
>>> > d...@lynne.ee >> >>
>>> + * Power of two FFT:
>>> + * Copyright (c) 2008 Loren Merritt
>>> + * Copyright (c) 2002 Fabrice Bellard
>>> + * Partly based on libdjbfft by D. J. Bernstein
>>> + *
>>> + * This file is part of FFmpeg.
>>>
> 
> Pushed.

You also need to bump libavutil minor version, and add an entry to
doc/APIChanges listing the new symbols.
___
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] libavutil: add an FFT & MDCT implementation

2019-05-15 Thread Lynne
May 14, 2019, 7:41 PM by d...@lynne.ee:

> May 14, 2019, 7:12 PM by > one...@gmail.com > :
>
>> On 5/14/19, Carl Eugen Hoyos <> >> ceffm...@gmail.com 
>> >>  > ceffm...@gmail.com 
>> >> >> > wrote:
>>
>>>
>>>
>>>
 Am 14.05.2019 um 19:17 schrieb Lynne <>>>  d...@lynne.ee 
   >>> d...@lynne.ee 
   >:

 I've attached the latest version.

>>>
>>> This patch is still not ok, please do not commit.
>>>
>>
>> I will and you can not stop me.
>>
>
> Attached a version with fft-template.c's copyright and mine like James 
> suggested
> so the fighting can at least somewhat stop and I can write some SIMD.
>
>> +/*
>> + * Copyright (c) 2019 Lynne <>> d...@lynne.ee >>  
>> > d...@lynne.ee >> >>
>> + * Power of two FFT:
>> + * Copyright (c) 2008 Loren Merritt
>> + * Copyright (c) 2002 Fabrice Bellard
>> + * Partly based on libdjbfft by D. J. Bernstein
>> + *
>> + * This file is part of FFmpeg.
>>

Pushed.
___
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] [CLOSED] movie Filter reload Option

2019-05-15 Thread TalkVideo
This is marked tested now, per below.


On Wed, May 15, 2019 at 01:35:24PM -0400, talkvi...@talkvideo.net wrote:
> The ultimate goal that was the source of the question for this email thread 
> was to enable spontaneous, and random injection of media into an existing RTMP
> stream. It has been accomplished. It is generally referred to as "Media Play"
> on YouTube, and other sites, and it allows the Audience to interact in 
> Real-Time
> with the stream, and modify its Content.
> 
> It is being tested Live while posting this message, here:
> 
> https://www.youtube.com/watch?v=xJgyle00A8k
> 
> A previous Live Stream demonstrating this is here:
> 
> https://www.youtube.com/watch?v=wOULTQ5dzls 
> 
> YouTube may have fixed audio sync issues after ingestion.
> 
> 
> It has been tested as follows:
> 
> 
> 1) Script 1 -- Updates files used by the "drawtext" And PNG "overlay" filters:
> 
> while :; do date +%s.%N > live.tmp; mv live.tmp live.txt; cp 1px-Alpha.png 
> overlay.tmp ; mv overlay.tmp overlay.png; sleep 1; cp 
> large-red-circle-emoji.png overlay.tmp ; mv overlay.tmp overlay.png; date 
> +%s.%N > live.tmp; mv live.tmp live.txt; free; sleep 1; done
> 
> 
> 2) Script 2 --  On a looping basis, stream video from whatever source into 
> the main FFMPEG process 
> as $INPUT_2. This stream for the "overlay" filter is generated from PNG, FLV, 
> or possibly RTMP Inputs. 
>  
> while :; do
> vid=`find ./videos -maxdepth 1 -type f -size +100M -print0 | xargs -0 ls | 
> sort -R | tail -n1 `;  echo $vid;  
> # Get a random video from a directory, and print its name.
> 
> /usr/local/bin/ffmpeg -re -y  -i $vid -r 30 -c:v libx264 -x264-params 
> "nal-hrd=cbr" -qmin 1 -qmax 15 -b:v 8M -maxrate 40M -bufsize 20M -g 15  
> -preset ultrafast -s 640x360 -t 10 -f flv -an -r 30   
> "rtmp://localhost:1935/video_overlay/key"; usleep 3;
> # Stream that video into INPUT_2 of the main FFMPEG process.
> 
> ffmpeg -y -re  -f image2 -loop 1 -r 30 -i 640x360-Alpha.png  -c:v libx264 
> -x264-params "nal-hrd=cbr" -qmin 1 -qmax 15 -b:v 8M -maxrate 40M -bufsize 20M 
> -g 15  -preset ultrafast  -s 64x36 -f flv -t 3 
> "rtmp://localhost:1935/video_overlay/key"; usleep 3; 
> # Generate a stream from a PNG Image into the main stream. FLV Does not 
> support Alpha.
> # The Image will appear as a black area. The image appears in upper right 
> corner
> # as a 64x36 area. It possibly can be reduced to a single pixel, to make it 
> "disappear".
> 
> ffmpeg -y -re  -f image2 -loop 1 -r 30 -i 640x360-Alpha.png  -c:v libx264 
> -x264-params "nal-hrd=cbr" -qmin 1 -qmax 15 -b:v 8M -maxrate 40M -bufsize 20M 
> -g 15  -preset ultrafast  -s 640x360 -f flv -t 3 
> "rtmp://localhost:1935/video_overlay/key"; usleep 3; 
> # Same as the line above, but now the area is 640x360. This creates the 
> effect of
> # a window appearing in upper right corner, from the smaller black area 
> created by the line above.
> 
> ffmpeg -y -re -f flv  -r 30 -i 
> "rtmp://localhost:1935/inbound_rtmp/key?listen_timeout=15000"  -s 
> 640x360 -r 30  -c:v libx264 -x264-params "nal-hrd=cbr" -qmin 1 -qmax 15 -b:v 
> 8M -maxrate 40M -bufsize 20M -g 15  -preset ultrafast  -f flv  
> -filter_complex "crop=640:360:in_w-out_w:in_h-in_h" -t 7   
> "rtmp://localhost:1935/video_overlay/key" ;  usleep 3;
> # Crops an area of the stream that is INPUT_1 to the main FFMPEG process, and 
> sends it
> # back into that process as an overlay. Can be used when no other overlay is 
> desired,
> # but must maintain Frame Sync with main process.
> 
> 3) Script 3 -- The main FFMPEG process. This is the command that would be 
> called by an
> "exec_push" directive to the nginx_rtmp module. It can be run directly at the 
> command line,
> or by some kind of calling script, and will receive input via RTMP, and 
> output it to YouTube,
> or some other endpoint.
> 
> /usr/local/bin/ffmpeg -y -re -r 30  $INPUT_1 -re -r 30 -an $INPUT_2 -f image2 
> -loop 1 -r 30 -i /home/nginx/overlay.png  -c:v libx264 -x264-params 
> "nal-hrd=cbr" -filter_complex 
> 'overlay=main_w-overlay_w:main_h-main_h:repeatlast=0:eof_action=pass, 
> overlay=100:main_h-overlay_h-600, 
> drawtext=fontfile=/home/nginx/fonts/Live.ttf:textfile=/home/nginx/live.txt:reload=1:x=main_w/33:y=main_h/24:fontsize=h/20:fontcolor=white:borderw=3'
>  -qmin 1 -qmax 15  -c:a aac -b:a 128k -b:v 8M -maxrate 40M -bufsize 20M -g 15 
>  -preset ultrafast -s 1920x1080  -r 30 $OUTPUT
> 
> The Inputs and Outputs of this process can be switched as follows, for 
> testing, etc.
> 
> export INPUT_1='-i Input.flv' # Testing Main Stream From Stored File
> export INPUT_1='-i 
> rtmp://localhost:1935/inbound_rtmp/key?listen_timeout=15000' # Live 
> Source
> 
> export INPUT_2='-f image2 -loop 1 -i 640x360-Alpha.png' # Image Overlay From 
> File 
> export INPUT_2='-i  
> rtmp://localhost:1935/video_overlay/key?listen_timeout=15000' # Live 
> or other Video overlay
> 
> export OUTPUT="-f flv /dev/null" # Output for testing / debugging.
> export OUTPUT="-f 

Re: [FFmpeg-devel] [SOLVED] movie Filter reload Option

2019-05-15 Thread TalkVideo
The ultimate goal that was the source of the question for this email thread 
was to enable spontaneous, and random injection of media into an existing RTMP
stream. It has been accomplished. It is generally referred to as "Media Play"
on YouTube, and other sites, and it allows the Audience to interact in Real-Time
with the stream, and modify its Content.

It is being tested Live while posting this message, here:

https://www.youtube.com/watch?v=xJgyle00A8k

A previous Live Stream demonstrating this is here:

https://www.youtube.com/watch?v=wOULTQ5dzls 

YouTube may have fixed audio sync issues after ingestion.


It has been tested as follows:


1) Script 1 -- Updates files used by the "drawtext" And PNG "overlay" filters:

while :; do date +%s.%N > live.tmp; mv live.tmp live.txt; cp 1px-Alpha.png 
overlay.tmp ; mv overlay.tmp overlay.png; sleep 1; cp 
large-red-circle-emoji.png overlay.tmp ; mv overlay.tmp overlay.png; date 
+%s.%N > live.tmp; mv live.tmp live.txt; free; sleep 1; done


2) Script 2 --  On a looping basis, stream video from whatever source into the 
main FFMPEG process 
as $INPUT_2. This stream for the "overlay" filter is generated from PNG, FLV, 
or possibly RTMP Inputs. 
 
while :; do
vid=`find ./videos -maxdepth 1 -type f -size +100M -print0 | xargs -0 ls | sort 
-R | tail -n1 `;  echo $vid;  
# Get a random video from a directory, and print its name.

/usr/local/bin/ffmpeg -re -y  -i $vid -r 30 -c:v libx264 -x264-params 
"nal-hrd=cbr" -qmin 1 -qmax 15 -b:v 8M -maxrate 40M -bufsize 20M -g 15  -preset 
ultrafast -s 640x360 -t 10 -f flv -an -r 30   
"rtmp://localhost:1935/video_overlay/key"; usleep 3;
# Stream that video into INPUT_2 of the main FFMPEG process.

ffmpeg -y -re  -f image2 -loop 1 -r 30 -i 640x360-Alpha.png  -c:v libx264 
-x264-params "nal-hrd=cbr" -qmin 1 -qmax 15 -b:v 8M -maxrate 40M -bufsize 20M 
-g 15  -preset ultrafast  -s 64x36 -f flv -t 3 
"rtmp://localhost:1935/video_overlay/key"; usleep 3; 
# Generate a stream from a PNG Image into the main stream. FLV Does not support 
Alpha.
# The Image will appear as a black area. The image appears in upper right corner
# as a 64x36 area. It possibly can be reduced to a single pixel, to make it 
"disappear".

ffmpeg -y -re  -f image2 -loop 1 -r 30 -i 640x360-Alpha.png  -c:v libx264 
-x264-params "nal-hrd=cbr" -qmin 1 -qmax 15 -b:v 8M -maxrate 40M -bufsize 20M 
-g 15  -preset ultrafast  -s 640x360 -f flv -t 3 
"rtmp://localhost:1935/video_overlay/key"; usleep 3; 
# Same as the line above, but now the area is 640x360. This creates the effect 
of
# a window appearing in upper right corner, from the smaller black area created 
by the line above.

ffmpeg -y -re -f flv  -r 30 -i 
"rtmp://localhost:1935/inbound_rtmp/key?listen_timeout=15000"  -s 
640x360 -r 30  -c:v libx264 -x264-params "nal-hrd=cbr" -qmin 1 -qmax 15 -b:v 8M 
-maxrate 40M -bufsize 20M -g 15  -preset ultrafast  -f flv  -filter_complex 
"crop=640:360:in_w-out_w:in_h-in_h" -t 7   
"rtmp://localhost:1935/video_overlay/key" ;  usleep 3;
# Crops an area of the stream that is INPUT_1 to the main FFMPEG process, and 
sends it
# back into that process as an overlay. Can be used when no other overlay is 
desired,
# but must maintain Frame Sync with main process.

3) Script 3 -- The main FFMPEG process. This is the command that would be 
called by an
"exec_push" directive to the nginx_rtmp module. It can be run directly at the 
command line,
or by some kind of calling script, and will receive input via RTMP, and output 
it to YouTube,
or some other endpoint.

/usr/local/bin/ffmpeg -y -re -r 30  $INPUT_1 -re -r 30 -an $INPUT_2 -f image2 
-loop 1 -r 30 -i /home/nginx/overlay.png  -c:v libx264 -x264-params 
"nal-hrd=cbr" -filter_complex 
'overlay=main_w-overlay_w:main_h-main_h:repeatlast=0:eof_action=pass, 
overlay=100:main_h-overlay_h-600, 
drawtext=fontfile=/home/nginx/fonts/Live.ttf:textfile=/home/nginx/live.txt:reload=1:x=main_w/33:y=main_h/24:fontsize=h/20:fontcolor=white:borderw=3'
 -qmin 1 -qmax 15  -c:a aac -b:a 128k -b:v 8M -maxrate 40M -bufsize 20M -g 15  
-preset ultrafast -s 1920x1080  -r 30 $OUTPUT

The Inputs and Outputs of this process can be switched as follows, for testing, 
etc.

export INPUT_1='-i Input.flv' # Testing Main Stream From Stored File
export INPUT_1='-i 
rtmp://localhost:1935/inbound_rtmp/key?listen_timeout=15000' # Live 
Source

export INPUT_2='-f image2 -loop 1 -i 640x360-Alpha.png' # Image Overlay From 
File 
export INPUT_2='-i  
rtmp://localhost:1935/video_overlay/key?listen_timeout=15000' # Live or 
other Video overlay

export OUTPUT="-f flv /dev/null" # Output for testing / debugging.
export OUTPUT="-f mp4 out.mp4" # Save as file Check For Output quality, sync, 
etc.
export OUTPUT="-f flv rtmp://a.rtmp.youtube.com/live2/" # 
Live!



Tweakable Paramaters:
-s 640x360 # Image Size. Adjust "-b:v", "-maxrate" and 
"-bufsize" with this.
-r 30  # Frame Rate. Probably best to match source 

Re: [FFmpeg-devel] [PATCH] avfilter: add apitch filter

2019-05-15 Thread Paul B Mahol
On 5/12/19, Paul B Mahol  wrote:
> On 5/12/19, Michael Niedermayer  wrote:
>> On Sun, May 12, 2019 at 11:00:51PM +0200, Nicolas George wrote:
>>> Marton Balint (12019-05-12):
>>> > Yeah, you are right, what I had in mind was this:
>>> >
>>> > apitch  ===  asetrate,aresample,atempo
>>>
>>> Exactly. And reciprocally, atempo = apitch+asetrate+aresample.
>>>
>>> Furthermore, since it works with the spectrum, the filter that does the
>>> hard work can probably easily output at any sample rate, at a cost much
>>> lower than resampling afterwards. Therefore, it makes most sense to have
>>> a single filter with all three parameters (sample rate, speed adjustment
>>> and pitch adjustment).
>>
>> and if thats done in our resampler than that can also be combined with
>> changing the channel order, layout, sample type and so on.
>> Iam not sure its a good idea but purely technically it should be more
>> efficient to do it all together.
>> Also swresample already supports an external FFT resampler so it might
>> actually fit in there nicely and it might even allow us to remove an
>> external
>> dependancy without loosing a feature. (assuming the new FFT resampler
>> would be equally good)
>>
>>
>
> To make it work dynamically, filter must resample audio internally.
>

Can I get testers?
___
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 0/3] avfilter/vf_scale_cuda: Various improvements

2019-05-15 Thread Timo Rothenpieler

On 14.05.2019 05:12, Philip Langdale wrote:

After Sergey's bug report, I went and fixed a couple of other things
I noticed while I was looking at the filter.

Philip Langdale (3):
   avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content
   avfilter/vf_scale_cuda: Add support for YUV444P16
   avfilter/vf_scale_cuda: Simplify output plane addressing

  libavfilter/vf_scale_cuda.c | 41 +
  1 file changed, 28 insertions(+), 13 deletions(-)



Series LGTM



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] Populate MPEG2TS codec_tag using ff_codec_movvideo_tags/ff_codec_movaudio_tags (av4cc) rather than the PES stream_type. For MPEG2TS files containing h264, ffprobe currently retu

2019-05-15 Thread Damien Levin
---
 libavformat/mpegts.c  | 9 +++--
 tests/ref/fate/concat-demuxer-simple2-lavf-ts | 4 ++--
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 8a84e5cc19..79c0b78b1f 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -877,6 +877,13 @@ static void mpegts_find_stream_type(AVStream *st,
 st->codecpar->codec_id   != types->codec_id) {
 st->codecpar->codec_type = types->codec_type;
 st->codecpar->codec_id   = types->codec_id;
+if (types->codec_type == AVMEDIA_TYPE_VIDEO) {
+st->codecpar->codec_tag =
+ff_codec_get_tag(ff_codec_movvideo_tags, 
types->codec_id);
+} else if (types->codec_type == AVMEDIA_TYPE_AUDIO) {
+st->codecpar->codec_tag =
+ff_codec_get_tag(ff_codec_movaudio_tags, 
types->codec_id);
+}
 st->internal->need_context_update = 1;
 }
 st->request_probe= 0;
@@ -908,8 +915,6 @@ static int mpegts_set_stream_info(AVStream *st, PESContext 
*pes,
"stream=%d stream_type=%x pid=%x prog_reg_desc=%.4s\n",
st->index, pes->stream_type, pes->pid, (char *)_reg_desc);
 
-st->codecpar->codec_tag = pes->stream_type;
-
 mpegts_find_stream_type(st, pes->stream_type, ISO_types);
 if (pes->stream_type == 4 || pes->stream_type == 0x0f)
 st->request_probe = 50;
diff --git a/tests/ref/fate/concat-demuxer-simple2-lavf-ts 
b/tests/ref/fate/concat-demuxer-simple2-lavf-ts
index e5cf18bbce..95f9859205 100644
--- a/tests/ref/fate/concat-demuxer-simple2-lavf-ts
+++ b/tests/ref/fate/concat-demuxer-simple2-lavf-ts
@@ -211,5 +211,5 @@ 
video|1|171982|1.910911|168382|1.870911|3600|0.04|N/A|N/A|17440|216388|__MPE
 
 
video|1|175582|1.950911|171982|1.910911|3600|0.04|N/A|N/A|15019|235000|__MPEGTS
 Stream ID
 
-0|mp2|unknown|audio|1/44100|[3][0][0][0]|0x0003|s16p|44100|1|mono|0|N/A|0/0|0/0|1/9|0|0.00|N/A|N/A|64000|N/A|N/A|N/A|N/A|89|0|0|0|0|0|0|0|0|0|0|0|0
-1|mpeg2video|4|video|1/25|[2][0][0][0]|0x0002|352|288|0|0|1|1:1|11:9|yuv420p|8|tv|unknown|unknown|unknown|left|progressive|N/A|1|N/A|25/1|25/1|1/9|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|60|0|0|0|0|0|0|0|0|0|0|0|0
+0|mp2|unknown|audio|1/44100|.mp3|0x33706d2e|s16p|44100|1|mono|0|N/A|0/0|0/0|1/9|0|0.00|N/A|N/A|64000|N/A|N/A|N/A|N/A|89|0|0|0|0|0|0|0|0|0|0|0|0
+1|mpeg2video|4|video|1/25|m2v1|0x3176326d|352|288|0|0|1|1:1|11:9|yuv420p|8|tv|unknown|unknown|unknown|left|progressive|N/A|1|N/A|25/1|25/1|1/9|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|60|0|0|0|0|0|0|0|0|0|0|0|0
-- 
2.21.0.1020.gf2820cf01a-goog

___
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/pngdec: Check input space

2019-05-15 Thread Michael Niedermayer
On Tue, May 14, 2019 at 08:52:27PM +0100, Kieran Kunhya wrote:
> On Tue, 14 May 2019 at 20:42, Michael Niedermayer 
> wrote:
> 
> > Fixes: Timeout (33sec -> 78ms)
> > Fixes:
> > 14668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5767073352908800
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by
> > :
> > Michael Niedermayer 
> > ---
> >  libavcodec/pngdec.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> > index 6a681be29d..78988d9e75 100644
> > --- a/libavcodec/pngdec.c
> > +++ b/libavcodec/pngdec.c
> > @@ -1535,6 +1535,9 @@ static int decode_frame_lscr(AVCodecContext *avctx,
> >  AVFrame *frame = data;
> >  int ret, nb_blocks, offset = 0;
> >
> > +if (avpkt->size < 2)
> > +return AVERROR_INVALIDDATA;
> > +
> >
> 
> Why not 1?

because the code reads 2 bytes next:

nb_blocks = bytestream2_get_le16(gb);


> Or maybe 3?
> Or maybe 42?

Its not checking for 3 or 42 or another number because the smallest
valid frame that our decoder accepts is 2 bytes.
In case you have a specification for LSCR, that would be interresting
to read to see if it contains more constraints which would lead to a
larger minimum size

Thanks


> 
> Random numbers to fix random samples are just absurd.
> 
> Kieran
> ___
> 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".

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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/qsvenc: fix mpeg2 encoding

2019-05-15 Thread Andreas Håkon
> > >
> > > It is closer to be merged, but need to confirm which exact line of code
> > > make difference.
> > > (Your verification on Windows was appreciated.)
> >
> > As I pointed, the QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) check fails
> > in Windows.
> > This version runs without problems and resolves the bug (in Windows).
>
> Well, let me to explain with more detail:
>
> V1:
> if (avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO &&
>
> > QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11))
>
> For mpeg2 case, it is always equal to "if (0)" , right?
>
> V2:
> if (avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO)
>
> For mpeg2 case, it is equal to "if (0)" too, right?
>
> Thus why I asked what the difference between V1 and V2 was.


I'm sorry! Now I understand what you're saying. It's my fault.
Well then... I feel like you're right.

However, I can only comment that the first time I compiled your patch
it doesn't work. And for this reason I created this one.
And now I can confirm that it resolves the problem.

Please feel free to approve whatever you think is best. But something has
to be done, because the MPEG-2 QSV encoder in Windows is broken.

Regards.
A.H.

---

___
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/qsvenc: fix mpeg2 encoding

2019-05-15 Thread Li, Zhong
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Andreas Håkon
> Sent: Wednesday, May 15, 2019 8:55 PM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: fix mpeg2 encoding
> 
> Hi,
> 
> 
> > > The difference?
> > > In addition to a few extra little checks, It seems that the
> > > QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) check fails every time in
> > > Windows (almost in my environment).
> >
> > If QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) always equal to zero,
> > then co3 won't be set, If codec is MPEG2, co3 won't be set too.
> > I can't see any difference for MPEG2 case.
> 
> Your assumption about QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) is
> not real.
> This depends on the run-time driver used.
> 
> 
> > > Futhermore, it has more sense to apply the check inside the
> > > conditional preprocessing of #if QSV_HAVE_CO3 and not outside.
> >
> > Make sense, but no difference for run-time result?
> 
> I prefer to make the code as more legible as possible.
> That's the reason for the other additions of #if QSV_HAVE_CO3.
> 
> 
> > > As a summary: I confirm that my patch works. And it's based on your
> > > proposal. So please comment positively to merge it.
> >
> > It is closer to be merged, but need to confirm which exact line of code
> make difference.
> > (Your verification on Windows was appreciated.)
> 
> As I pointed, the QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) check fails
> in Windows.
> This version runs without problems and resolves the bug (in Windows).

Well, let me to explain with more detail:

V1: 
if (avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO &&
> QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11)) 

For mpeg2 case, it is always equal to "if (0)" , right? 

V2:
if (avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO)

For mpeg2 case, it is equal to "if (0)" too, right?

Thus why I asked what the difference between V1 and V2 was. 
___
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]

2019-05-15 Thread Gyan



On 15-05-2019 05:06 PM, Werner Robitza wrote:

On Wed, May 15, 2019 at 11:36 AM Gyan  wrote:

Which lines in the CLI help?

SWScaler AVOptions:
   -sws_flags   E..V. scaler flags (default bicubic)
...
   -src_formatE..V. source format (default yuv420p)
   -dst_formatE..V. destination format (default 
yuv420p)
   -src_range E..V. source is full range (default 
false)
   -dst_range E..V. destination is full range
(default false)


I don't see any constants set in the AVOptions struct. Can you share a command 
line where you could set this option using a string?

I was just going by the help printed above, including the default. If
a string is not valid, which values are?
The help function fetches the string name for the default value but the 
user has to input an integer.


The pixel formats are declared in an enum in libavutil/pixfmt.h. The 
integers correspond to their index in that list.

+If set to 1, source range will be full range.

Mention the range of values possible and their meaning.

I don't understand, as no other values are possible. Well, 0 is
possible but meaningless since it's default; 1 indicates "true".
Sure, if the option name was is_src_range_full. But src_range allows you 
to specify a range. So, even though there are only two, better to 
mention the allowed values and their meaning.


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

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

Re: [FFmpeg-devel] [PATCH v2] Add multiple padding method in dnn native

2019-05-15 Thread Pedro Arthur
Em qua, 15 de mai de 2019 às 04:44, Steven Liu
 escreveu:
>
> Xuewei Meng  于2019年5月11日周六 上午11:11写道:
> >
> > ---
> >  libavfilter/dnn_backend_native.c | 52 
> >  libavfilter/dnn_backend_native.h |  3 ++
> >  2 files changed, 43 insertions(+), 12 deletions(-)
> >
> > diff --git a/libavfilter/dnn_backend_native.c 
> > b/libavfilter/dnn_backend_native.c
> > index 06fbdf368b..171a756385 100644
> > --- a/libavfilter/dnn_backend_native.c
> > +++ b/libavfilter/dnn_backend_native.c
> > @@ -61,6 +61,12 @@ static DNNReturnType set_input_output_native(void 
> > *model, DNNInputData *input, c
> >  return DNN_ERROR;
> >  }
> >  cur_channels = conv_params->output_num;
> > +
> > +if(conv_params->padding_method == VALID){
> > +int pad_size = conv_params->kernel_size - 1;
> > +cur_height -= pad_size;
> > +cur_width -= pad_size;
> > +}
> >  break;
> >  case DEPTH_TO_SPACE:
> >  depth_to_space_params = (DepthToSpaceParams 
> > *)network->layers[layer].params;
> > @@ -77,6 +83,10 @@ static DNNReturnType set_input_output_native(void 
> > *model, DNNInputData *input, c
> >  if (network->layers[layer].output){
> >  av_freep(>layers[layer].output);
> >  }
> > +
> > +if(cur_height <= 0 || cur_width <= 0)
> > +return DNN_ERROR;
> > +
> >  network->layers[layer].output = av_malloc(cur_height * cur_width * 
> > cur_channels * sizeof(float));
> >  if (!network->layers[layer].output){
> >  return DNN_ERROR;
> > @@ -154,13 +164,14 @@ DNNModel *ff_dnn_load_model_native(const char 
> > *model_filename)
> >  ff_dnn_free_model_native();
> >  return NULL;
> >  }
> > +conv_params->padding_method = 
> > (int32_t)avio_rl32(model_file_context);
> >  conv_params->activation = 
> > (int32_t)avio_rl32(model_file_context);
> >  conv_params->input_num = 
> > (int32_t)avio_rl32(model_file_context);
> >  conv_params->output_num = 
> > (int32_t)avio_rl32(model_file_context);
> >  conv_params->kernel_size = 
> > (int32_t)avio_rl32(model_file_context);
> >  kernel_size = conv_params->input_num * conv_params->output_num 
> > *
> >conv_params->kernel_size * 
> > conv_params->kernel_size;
> > -dnn_size += 16 + (kernel_size + conv_params->output_num << 2);
> > +dnn_size += 20 + (kernel_size + conv_params->output_num << 2);
> >  if (dnn_size > file_size || conv_params->input_num <= 0 ||
> >  conv_params->output_num <= 0 || conv_params->kernel_size 
> > <= 0){
> >  avio_closep(_file_context);
> > @@ -218,23 +229,35 @@ DNNModel *ff_dnn_load_model_native(const char 
> > *model_filename)
> >
> >  static void convolve(const float *input, float *output, const 
> > ConvolutionalParams *conv_params, int width, int height)
> >  {
> > -int y, x, n_filter, ch, kernel_y, kernel_x;
> >  int radius = conv_params->kernel_size >> 1;
> >  int src_linesize = width * conv_params->input_num;
> >  int filter_linesize = conv_params->kernel_size * 
> > conv_params->input_num;
> >  int filter_size = conv_params->kernel_size * filter_linesize;
> > +int pad_size = (conv_params->padding_method == VALID) ? 
> > (conv_params->kernel_size - 1) / 2 : 0;
> >
> > -for (y = 0; y < height; ++y){
> > -for (x = 0; x < width; ++x){
> > -for (n_filter = 0; n_filter < conv_params->output_num; 
> > ++n_filter){
> > +for (int y = pad_size; y < height - pad_size; ++y){
> > +for (int x = pad_size; x < width - pad_size; ++x){
> > +for (int n_filter = 0; n_filter < conv_params->output_num; 
> > ++n_filter){
> >  output[n_filter] = conv_params->biases[n_filter];
> > -for (ch = 0; ch < conv_params->input_num; ++ch){
> > -for (kernel_y = 0; kernel_y < 
> > conv_params->kernel_size; ++kernel_y){
> > -for (kernel_x = 0; kernel_x < 
> > conv_params->kernel_size; ++kernel_x){
> > -output[n_filter] += input[CLAMP_TO_EDGE(y + 
> > kernel_y - radius, height) * src_linesize +
> > -  CLAMP_TO_EDGE(x + 
> > kernel_x - radius, width) * conv_params->input_num + ch] *
> > -
> > conv_params->kernel[n_filter * filter_size + kernel_y * filter_linesize +
> > -
> > kernel_x * conv_params->input_num + ch];
> > +
> > +for (int ch = 0; ch < conv_params->input_num; ++ch){
> > +for (int kernel_y = 0; kernel_y < 
> > conv_params->kernel_size; ++kernel_y){
> > +for (int kernel_x = 

[FFmpeg-devel] [PATCH] libavformat/mpegtsenc: Add minimal support for ATSC PSIP tables

2019-05-15 Thread Phillip Burr
Minimal support for ATSC PSIP tables.  Does not support STT or
EIT tables and so is not compliant with terrestrial ATSC.
ATSC tables are not created by default, and will only be transmitted
if either "atsc_name" or "atsc_channel" metadata is supplied.

Signed-off-by: Phillip Burr 
---
 libavformat/mpegts.h|   8 +
 libavformat/mpegtsenc.c | 412 
 2 files changed, 343 insertions(+), 77 deletions(-)

diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index 272e2be4f7..ca6943b1ba 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -35,12 +35,20 @@
 /* pids */
 #define PAT_PID 0x
 #define SDT_PID 0x0011
+#define ATSC_PID0x1ffb
 
 /* table ids */
 #define PAT_TID   0x00
 #define PMT_TID   0x02
 #define M4OD_TID  0x05
 #define SDT_TID   0x42
+#define MGT_TID   0xc7
+#define TVCT_TID  0xc8
+#define CVCT_TID  0xc9
+#define RRT_TID   0xca
+#define EIT_TID   0xcb
+#define ETT_TID   0xcc
+#define STT_TID   0xcd
 
 #define STREAM_TYPE_VIDEO_MPEG1 0x01
 #define STREAM_TYPE_VIDEO_MPEG2 0x02
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fc0ea225c6..9846b50367 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -56,6 +56,11 @@ typedef struct MpegTSService {
 int sid;   /* service ID */
 uint8_t name[256];
 uint8_t provider_name[256];
+
+uint16_t atsc_name[7]; /* ATSC VCT fields */
+int atsc_mj_channel;
+int atsc_mn_channel;
+
 int pcr_pid;
 int pcr_packet_count;
 int pcr_packet_period;
@@ -77,11 +82,16 @@ typedef struct MpegTSWrite {
 const AVClass *av_class;
 MpegTSSection pat; /* MPEG-2 PAT table */
 MpegTSSection sdt; /* MPEG-2 SDT table context */
+MpegTSSection atsc; /* ATSC tables */
 MpegTSService **services;
 int sdt_packet_count;
 int sdt_packet_period;
 int pat_packet_count;
 int pat_packet_period;
+int mgt_packet_count;
+int mgt_packet_period;
+int tvct_packet_count;
+int tvct_packet_period;
 int nb_services;
 int onid;
 int tsid;
@@ -113,6 +123,9 @@ typedef struct MpegTSWrite {
 double sdt_period;
 int64_t last_pat_ts;
 int64_t last_sdt_ts;
+int64_t last_mgt_ts;
+int64_t last_tvct_ts;
+int xmit_atsc;
 
 int omit_video_pes_length;
 } MpegTSWrite;
@@ -189,14 +202,24 @@ static inline void put16(uint8_t **q_ptr, int val)
 *q_ptr = q;
 }
 
+static inline void put32(uint8_t **q_ptr, int val)
+{
+uint8_t *q;
+q  = *q_ptr;
+*q++   = val >> 24;
+*q++   = val >> 16;
+*q++   = val >> 8;
+*q++   = val;
+*q_ptr = q;
+}
+
 static int mpegts_write_section1(MpegTSSection *s, int tid, int id,
  int version, int sec_num, int last_sec_num,
- uint8_t *buf, int len)
+ int private, uint8_t *buf, int len)
 {
 uint8_t section[1024], *q;
 unsigned int tot_len;
-/* reserved_future_use field must be set to 1 for SDT */
-unsigned int flags = tid == SDT_TID ? 0xf000 : 0xb000;
+unsigned int flags = private ? 0xf000 : 0xb000;
 
 tot_len = 3 + 5 + len + 4;
 /* check if not too big */
@@ -226,6 +249,12 @@ static int mpegts_write_section1(MpegTSSection *s, int 
tid, int id,
 #define SDT_RETRANS_TIME 500
 #define PAT_RETRANS_TIME 100
 #define PCR_RETRANS_TIME 20
+#define MGT_RETRANS_TIME 150
+#define TVCT_RETRANS_TIME 400
+#define EIT0_RETRANS_TIME 500
+#define EIT1_RETRANS_TIME 3000
+#define EIT23_RETRANS_TIME 6
+#define STT_RETRANS_TIME 1000
 
 typedef struct MpegTSWriteStream {
 struct MpegTSService *service;
@@ -260,7 +289,7 @@ static void mpegts_write_pat(AVFormatContext *s)
 put16(, service->sid);
 put16(, 0xe000 | service->pmt.pid);
 }
-mpegts_write_section1(>pat, PAT_TID, ts->tsid, ts->tables_version, 0, 
0,
+mpegts_write_section1(>pat, PAT_TID, ts->tsid, ts->tables_version, 0, 
0, 0,
   data, q - data);
 }
 
@@ -282,6 +311,79 @@ static void put_registration_descriptor(uint8_t **q_ptr, 
uint32_t tag)
 *q_ptr = q;
 }
 
+static int extract_stream_type(AVStream *st, MpegTSWrite *ts)
+{
+int stream_type;
+
+switch (st->codecpar->codec_id) {
+case AV_CODEC_ID_MPEG1VIDEO:
+case AV_CODEC_ID_MPEG2VIDEO:
+stream_type = STREAM_TYPE_VIDEO_MPEG2;
+break;
+case AV_CODEC_ID_MPEG4:
+stream_type = STREAM_TYPE_VIDEO_MPEG4;
+break;
+case AV_CODEC_ID_H264:
+stream_type = STREAM_TYPE_VIDEO_H264;
+break;
+case AV_CODEC_ID_HEVC:
+stream_type = STREAM_TYPE_VIDEO_HEVC;
+break;
+case AV_CODEC_ID_CAVS:
+stream_type = STREAM_TYPE_VIDEO_CAVS;
+break;
+case AV_CODEC_ID_DIRAC:
+stream_type = STREAM_TYPE_VIDEO_DIRAC;
+break;
+case AV_CODEC_ID_VC1:
+stream_type = STREAM_TYPE_VIDEO_VC1;
+break;
+case 

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: fix mpeg2 encoding

2019-05-15 Thread Andreas Håkon
Hi,


> > The difference?
> > In addition to a few extra little checks, It seems that the
> > QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) check fails every time in
> > Windows (almost in my environment).
>
> If QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) always equal to zero, then co3 
> won't be set,
> If codec is MPEG2, co3 won't be set too.
> I can't see any difference for MPEG2 case.

Your assumption about QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) is not real.
This depends on the run-time driver used.


> > Futhermore, it has more sense to apply the check inside the conditional
> > preprocessing of #if QSV_HAVE_CO3 and not outside.
>
> Make sense, but no difference for run-time result?

I prefer to make the code as more legible as possible.
That's the reason for the other additions of #if QSV_HAVE_CO3.


> > As a summary: I confirm that my patch works. And it's based on your
> > proposal. So please comment positively to merge it.
>
> It is closer to be merged, but need to confirm which exact line of code make 
> difference.
> (Your verification on Windows was appreciated.)

As I pointed, the QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) check fails in 
Windows.
This version runs without problems and resolves the bug (in Windows).

So, I suggest to accept this patch.

Regards.
A.H.

---

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

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

Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: add support for per frame rotation and flip

2019-05-15 Thread Andriy Gelman
On Tue, 14. May 22:36, Jun Li wrote:
> Fix #6945
> Current implementaion for autorotate works fine for stream
> level rotataion but no support for frame level operation
> and frame flip. This patch is for adding flip support and
> per frame operations.
> ---
>  fftools/cmdutils.c  |  9 ++---
>  fftools/cmdutils.h  |  2 +-
>  fftools/ffmpeg.c| 21 ++-
>  fftools/ffmpeg.h|  2 +
>  fftools/ffmpeg_filter.c | 81 ++---
>  fftools/ffplay.c| 28 +++---
>  6 files changed, 126 insertions(+), 17 deletions(-)
> 
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 9cfbc45c2b..b8bb904419 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int 
> *size, int new_size)
>  return array;
>  }
>  
> -double get_rotation(AVStream *st)
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
>  {
> -uint8_t* displaymatrix = av_stream_get_side_data(st,
> - 
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
>  double theta = 0;
> -if (displaymatrix)
> -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> +
> +if (display_matrix)
> +theta = -av_display_rotation_hflip_get(display_matrix, hflip);
>  
>  theta -= 360*floor(theta/360 + 0.9/360);
>  
> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> index 6e2e0a2acb..dce44ed6e1 100644
> --- a/fftools/cmdutils.h
> +++ b/fftools/cmdutils.h
> @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int *size, 
> int new_size);
>  char name[128];\
>  av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
>  
> -double get_rotation(AVStream *st);
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
>  
>  #endif /* FFTOOLS_CMDUTILS_H */
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 01f04103cf..9ea1aaa930 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2126,6 +2126,24 @@ static int ifilter_has_all_input_formats(FilterGraph 
> *fg)
>  return 1;
>  }
>  
> +static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter, 
> AVFrame* frame)
> +{
> +int32_t* stream_matrix = 
> (int32_t*)av_stream_get_side_data(ifilter->ist->st, 
> +AV_PKT_DATA_DISPLAYMATRIX, 
> NULL);
> +// if we already have display matrix from stream, use it instead of 
> extracting
> +// from frame.
> +if (stream_matrix) {
> +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);

would it be better to use sizeof? 
memcpy(ifilter->display_matrix, stream_matrix, sizeof(int32_t) * 9); 

> +return 0;
> +}
> +
> +// cleanup the display matrix, may be from last frame
> +memset(ifilter->display_matrix, 0, 4 * 9);

memset(ifilter->display_matrix, 0, sizeof(int32_t) * 9);

> +av_display_rotation_set(ifilter->display_matrix, 0);
> +
> +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> +}
> +
>  static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
>  {
>  FilterGraph *fg = ifilter->graph;
> @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter *ifilter, 
> AVFrame *frame)
> ifilter->channel_layout != frame->channel_layout;
>  break;
>  case AVMEDIA_TYPE_VIDEO:
> -need_reinit |= ifilter->width  != frame->width ||
> +need_reinit |= ifilter_display_matrix_need_from_frame(ifilter, 
> frame) ||
> +   ifilter->width  != frame->width ||
> ifilter->height != frame->height;
>  break;
>  }
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index eb1eaf6363..8331720663 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -251,6 +251,8 @@ typedef struct InputFilter {
>  int channels;
>  uint64_t channel_layout;
>  
> +int32_t display_matrix[9];
> +
>  AVBufferRef *hw_frames_ctx;
>  
>  int eof;
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 72838de1e2..1894f30561 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg, 
> AVFilterInOut *in)
>  fg->inputs[fg->nb_inputs - 1]->format = -1;
>  fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
>  fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in, 1);
> +av_display_rotation_set(fg->inputs[fg->nb_inputs - 1]->display_matrix, 
> 0);
>  
>  fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 * 
> sizeof(AVFrame*));
>  if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
> @@ -807,22 +808,43 @@ static int configure_input_video_filter(FilterGraph 
> *fg, InputFilter *ifilter,
>  last_filter = ifilter->filter;
>  
>  if (ist->autorotate) {
> -double theta = get_rotation(ist->st);
> +   

Re: [FFmpeg-devel] [PATCH] avfilter/drawtext: stop resource leak

2019-05-15 Thread Paul B Mahol
On 5/15/19, Gyan  wrote:
>
> See http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244029.html
>
> Gyan
>

probably ok
___
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]

2019-05-15 Thread Werner Robitza
On Wed, May 15, 2019 at 11:36 AM Gyan  wrote:
> Which lines in the CLI help?

SWScaler AVOptions:
  -sws_flags   E..V. scaler flags (default bicubic)
   ...
  -src_formatE..V. source format (default yuv420p)
  -dst_formatE..V. destination format (default yuv420p)
  -src_range E..V. source is full range (default false)
  -dst_range E..V. destination is full range
(default false)

> I don't see any constants set in the AVOptions struct. Can you share a 
> command line where you could set this option using a string?

I was just going by the help printed above, including the default. If
a string is not valid, which values are?
Or am I looking in the wrong place?

> > +If set to 1, source range will be full range.
>
> Mention the range of values possible and their meaning.

I don't understand, as no other values are possible. Well, 0 is
possible but meaningless since it's default; 1 indicates "true".

Werner

PS: Sorry for missing the subject line in this email.
___
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/qsvenc: fix mpeg2 encoding

2019-05-15 Thread Li, Zhong
> > > Subject: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: fix mpeg2
> > > encoding Fixes bug #7839
> > > https://trac.ffmpeg.org/ticket/7839
> > > Supersedes:
> > > #12935 - https://patchwork.ffmpeg.org/patch/12935/
> > > #12872 - https://patchwork.ffmpeg.org/patch/12872/
> > > Regards.
> > > A.H.
> >
> > It was saidhttps://patchwork.ffmpeg.org/patch/12935/ could not fix
> #7839, how this one can work?
> 
> 
> I compiled your patch and doesn't work.
> My path works.

Glad to know it.

> The difference?
> In addition to a few extra little checks, It seems that the
> QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) check fails every time in
> Windows (almost in my environment).

If QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) always equal to zero, then co3 
won't be set, 
If codec is MPEG2, co3 won't be set too.
I can't see any difference for MPEG2 case.

> Futhermore, it has more sense to apply the check inside the conditional
> preprocessing of #if QSV_HAVE_CO3 and not outside.

Make sense, but no difference for run-time result? 

> As a summary: I confirm that my patch works. And it's based on your
> proposal. So please comment positively to merge it.

It is closer to be merged, but need to confirm which exact line of code make 
difference.
(Your verification on Windows was appreciated.)

> Thank you!
> A.H.
___
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] Add multiple padding method in dnn native

2019-05-15 Thread Guo, Yejun

> 
> 
> From: Xuewei Meng [mailto:xwmen...@gmail.com]
> Sent: Wednesday, May 15, 2019 4:41 PM
> To: Guo, Yejun 
> Cc: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v2] Add multiple padding method in dnn
> native
> 
> 
> 
> Guo, Yejun  于2019年5月15日周三 下午2:21写道:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Steven Liu
> > Sent: Wednesday, May 15, 2019 10:38 AM
> > To: FFmpeg development discussions and patches
> 
> > Cc: Xuewei Meng 
> > Subject: Re: [FFmpeg-devel] [PATCH v2] Add multiple padding method in dnn
> > native
> >
> > Xuewei Meng  于2019年5月11日周六 上午
> 11:11
> > 写道:
> > >
> > > ---
> > >  libavfilter/dnn_backend_native.c | 52 
> > >  libavfilter/dnn_backend_native.h |  3 ++
> > >  2 files changed, 43 insertions(+), 12 deletions(-)
> 
> @xuewei, we still need to mention the impact of sr filter, and explain why
> same_clamp_to_edge is needed.
> There are three padding methods in this patch, VALID, SAME and
> SAME_CLAMP_TO_EDGE. The 'VALID' and 'SAME' options are tensorflow
> supported padding methods. And the third one, 'SAME_CLAMP_TO_EDGE', is
> suggested by sr filter. As this method can keep the output with the same size
> as original input, and gives a slight better result as mentioned by Pedro 
> Arthur.
> So we keep this option in dnn native mode.

nice, please add them into commit log. And also the impact to sr filter.

> 
> > >
> > > diff --git a/libavfilter/dnn_backend_native.c
> > b/libavfilter/dnn_backend_native.c
> > > index 06fbdf368b..171a756385 100644
> > > --- a/libavfilter/dnn_backend_native.c
> > > +++ b/libavfilter/dnn_backend_native.c
> > > @@ -61,6 +61,12 @@ static DNNReturnType
> set_input_output_native(void
> > *model, DNNInputData *input, c
> > >                  return DNN_ERROR;
> > >              }
> > >              cur_channels = conv_params->output_num;
> > > +
> > > +            if(conv_params->padding_method == VALID){
> > > +                int pad_size = conv_params->kernel_size - 1;
> > > +                cur_height -= pad_size;
> > > +                cur_width -= pad_size;
> > > +            }
> > >              break;
> > >          case DEPTH_TO_SPACE:
> > >              depth_to_space_params = (DepthToSpaceParams
> > *)network->layers[layer].params;
> > > @@ -77,6 +83,10 @@ static DNNReturnType
> set_input_output_native(void
> > *model, DNNInputData *input, c
> > >          if (network->layers[layer].output){
> > >              av_freep(>layers[layer].output);
> > >          }
> > > +
> > > +        if(cur_height <= 0 || cur_width <= 0)
> > > +            return DNN_ERROR;
> > > +
> > >          network->layers[layer].output = av_malloc(cur_height *
> > cur_width * cur_channels * sizeof(float));
> > >          if (!network->layers[layer].output){
> > >              return DNN_ERROR;
> > > @@ -154,13 +164,14 @@ DNNModel *ff_dnn_load_model_native(const
> > char *model_filename)
> > >                  ff_dnn_free_model_native();
> > >                  return NULL;
> > >              }
> > > +            conv_params->padding_method =
> > (int32_t)avio_rl32(model_file_context);
> > >              conv_params->activation =
> > (int32_t)avio_rl32(model_file_context);
> > >              conv_params->input_num =
> > (int32_t)avio_rl32(model_file_context);
> > >              conv_params->output_num =
> > (int32_t)avio_rl32(model_file_context);
> > >              conv_params->kernel_size =
> > (int32_t)avio_rl32(model_file_context);
> > >              kernel_size = conv_params->input_num *
> > conv_params->output_num *
> > >                            conv_params->kernel_size *
> > conv_params->kernel_size;
> > > -            dnn_size += 16 + (kernel_size + conv_params->output_num
> > << 2);
> > > +            dnn_size += 20 + (kernel_size +
> conv_params->output_num
> > << 2);
> > >              if (dnn_size > file_size || conv_params->input_num <= 0
> ||
> > >                  conv_params->output_num <= 0 ||
> > conv_params->kernel_size <= 0){
> > >                  avio_closep(_file_context);
> > > @@ -218,23 +229,35 @@ DNNModel *ff_dnn_load_model_native(const
> > char *model_filename)
> > >
> > >  static void convolve(const float *input, float *output, const
> > ConvolutionalParams *conv_params, int width, int height)
> > >  {
> > > -    int y, x, n_filter, ch, kernel_y, kernel_x;
> > >      int radius = conv_params->kernel_size >> 1;
> > >      int src_linesize = width * conv_params->input_num;
> > >      int filter_linesize = conv_params->kernel_size *
> > conv_params->input_num;
> > >      int filter_size = conv_params->kernel_size * filter_linesize;
> > > +    int pad_size = (conv_params->padding_method == VALID) ?
> > (conv_params->kernel_size - 1) / 2 : 0;
> > >
> > > -    for (y = 0; y < height; ++y){
> > > -        for (x = 0; x < width; ++x){
> > > -            for (n_filter = 0; n_filter < conv_params->output_num;
> > 

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: fix mpeg2 encoding

2019-05-15 Thread Andreas Håkon
Hi,

> > Subject: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: fix mpeg2 encoding
> > Fixes bug #7839
> > https://trac.ffmpeg.org/ticket/7839
> > Supersedes:
> > #12935 - https://patchwork.ffmpeg.org/patch/12935/
> > #12872 - https://patchwork.ffmpeg.org/patch/12872/
> > Regards.
> > A.H.
>
> It was saidhttps://patchwork.ffmpeg.org/patch/12935/ could not fix #7839, how 
> this one can work?


I compiled your patch and doesn't work.
My path works.

The difference?
In addition to a few extra little checks, It seems that the
QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11) check fails every time in
Windows (almost in my environment).

Futhermore, it has more sense to apply the check inside the
conditional preprocessing of #if QSV_HAVE_CO3 and not outside.

As a summary: I confirm that my patch works. And it's based on your
proposal. So please comment positively to merge it.

Thank you!
A.H.

___
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/qsvenc: fix mpeg2 encoding

2019-05-15 Thread Li, Zhong
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Andreas Håkon
> Sent: Wednesday, May 15, 2019 12:00 AM
> To: FFmpeg development discussions and patches
> 
> Subject: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: fix mpeg2 encoding
> 
> Fixes bug #7839
> https://trac.ffmpeg.org/ticket/7839
> 
> Supersedes:
> #12935 - https://patchwork.ffmpeg.org/patch/12935/
> #12872 - https://patchwork.ffmpeg.org/patch/12872/
> 
> Regards.
> A.H.

It was said https://patchwork.ffmpeg.org/patch/12935/ could not fix #7839, how 
this one can work?
___
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] libavformat/qsvenc: fix mpeg2 missing headers

2019-05-15 Thread Andreas Rheinhardt
Hello,

Andreas Håkon:
> 
> Hi Andreas,
> 
> 
>> I know nothing about QSV, but I know a bit about MPEG-2 and have
>> therefore taken a quick look at this:
> 
> I'm running a lot of tests with QSV. So I know a little bit about that.
> 
> 
>> 1.
>>
>>> +  if ((p_buf[7] & 0x1) == 1) {
>>> +  memcpy(q->matrix, p_buf + 8, 64);
>>> +  p_sec += 4;
>>> +  av_log(avctx, AV_LOG_VERBOSE, "Found
>>
>> You are checking the wrong bit here (it should be the 0x2 bit) and you
>> are copying the wrong bits. That's because the intra_quantiser_matrix
>> matrix (if it is explicitly coded) doesn't start at a byte-aligned
>> position. Maybe you should not split the sequence header into two
>> buffers, but simply use one big buffer (and record the size of the
>> actual data in the buffer (which of course depends on the whether the
>> matrices are explicitly coded or not) somewhere)?
>> (If it is so that MPEG-2-QSV only ever uses the
>> non_intra_quantiser_matrix, then your approach might make sense.)
> 
> I'll revise it.
> 
> However, please note that in our tests the QSV MPEG-2 encoder has never
> written an intra_quantiser_matrix. The code is here to complete it.
> 
> 
>> 2. You are implicitly assuming that only one of the matrices exists,
>> but there can be two in the sequence header. Or is it documented
>> somewhere that MPEG-2-QSV can only use one matrix?
> 
> As I say, the current driver never writes an intra_quantiser_matrix.
> 
> 
>> 3. You are also implicitly assuming that there is no
>> quant_matrix_extension (which can have up to four matrices in it, but
>> only up to two for 4:2:0 video). Is it documented somewhere that this
>> is so?
> 
> As far as I know, the QSV documentation does not describe anything about it.
> Perhaps the best solution is to completely forget the intra_quantiser_matrix.
> What do you think?
>
Even if you only want to support the case you observed, it would IMO
simplify the code to use one big buffer for the sequence header (and
record the actual size of the sequence header) than use two small
buffers. That way you would not need to distinguish between the cases
1 and 2 when inserting. And if you use only one big buffer, it is easy
to support both matrices that may occur in a sequence header.

>> 5. You seem to use p_sec as a bitfield; so it would seem appropriate
>> to use |= to set the bits and not addition.
> 
> Well, the current implementation is pretty simple to understand.
> I see no reason to change it, as it is an internal loop indicator.
> 
It would not complicate anything to use |=.
> 
>> 7.
>>
>>> +  case 1:
>>> +  memmove(bs->Data + 23, bs->Data, bs->DataLength - 23);
>>> +  bs->DataLength  += 23;
>>> +  memcpy( bs->Data + 0 , q->seq_header, 13);
>>> +  memcpy( bs->Data + 13, q->seq_ext,10);
>>> +  break;
>>> +  case 2:
>>> +  memmove(bs->Data + 87, bs->Data, bs->DataLength - 87);
>>> +  bs->DataLength  += 87;
>>> +  memcpy( bs->Data + 0 , q->seq_header, 13);
>>> +  memcpy( bs->Data + 13, q->matrix, 64);
>>> +  memcpy( bs->Data + 77, q->seq_ext,10);
>>> +  break;
>>
>> This looks extremely fishy: You essentially throw the last 23/87 bytes
>> of the bs.Data buffer away and nevertheless you increase the length of
>> the data by 23/87 bytes.
> 
> Please, note that bs->Data is an already allocated buffer. The allocated
> space is q->packet_size that correspond to:
> 
> - QSVEncContext *q;
> - q->packet_size = q->param.mfx.BufferSizeInKB * 1000;
> 
> So the buffer is initialized to a large value inside the function
> qsv_retrieve_enc_params() at the initilitation of the hw encoder.
> 
> Check it at:
> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc.c#L860
> 
> So, then it's not a fault to throw the last bytes of the buffer, as the
> Length is much small that the Size of the buffer.
> 
> Futhermore, the Length is the size of the data allocated inside the
> buffer and not the size of the buffer. So, when you reinsert the missing
> tables in the header you need to update the value of the Length.
> 
> That said, the code is correct.
> 
No. If the situation is as you describe and only the first
bs->DataLength bytes of the buffer are valid, then you nevertheless
need to copy (memmove) all of the valid bytes, not only the first
bs->DataLength - 23/87.
The way your code above is written implies that bs->DataLength doesn't
need to be updated (as you throw away the last 23/87 valid bytes and
put 23/87 (valid) bytes at the front).

> More comments?

Yes. Why did you put all the new variables that you introduced into
such a large scope?
And there is the flag AV_CODEC_FLAG_GLOBAL_HEADER which if set means
that one should only put the headers into the extradata and not in

Re: [FFmpeg-devel] [PATCH]

2019-05-15 Thread Gyan



On 15-05-2019 02:28 PM, Werner Robitza wrote:

This fixes documentation for swscaler which is not reflecting what is
shown when running ffmpeg -h full.

Best regards,
Werner



From a460bae885499cb7782c096336cb351dfe6652ad Mon Sep 17 00:00:00 2001
From: Werner Robitza 
Date: Wed, 15 May 2019 10:52:00 +0200
Subject: [PATCH] doc/swscaler: fix documentation of pixel format and range

The possible values for source and destination pixel format, as well as the
correct values for source and destination range are printed when running
ffmpeg -h full, but are incorrect in the documentation. This patch fixes
the documentation accordingly.


Which lines in the CLI help?


Signed-off-by: Werner Robitza 
---
 doc/scaler.texi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/scaler.texi b/doc/scaler.texi
index f73804adfe..c873d6b2a7 100644
--- a/doc/scaler.texi
+++ b/doc/scaler.texi
@@ -81,16 +81,16 @@ Set destination width.
 Set destination height.
 
 @item src_format

-Set source pixel format (must be expressed as an integer).
+Set source pixel format.


I don't see any constants set in the AVOptions struct. Can you share a command 
line where you could set this option using a string?


 @item dst_format
-Set destination pixel format (must be expressed as an integer).
+Set destination pixel format.


^ same as above.


 @item src_range
-Select source range.
+If set to 1, source range will be full range.


Mention the range of values possible and their meaning.
 

 @item dst_range
-Select destination range.
+If set to 1, destination range will be full range.


^ same as above.


 @anchor{sws_params}
 @item param0, param1
--
2.21.0



Gyan

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

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

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

2019-05-15 Thread Daniel Kučera
>
> Ping.
>
> --
>
> S pozdravom / Best regards
> Daniel Kucera.

Ping.

-- 

S pozdravom / Best regards
Daniel Kucera.
___
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]

2019-05-15 Thread Werner Robitza
This fixes documentation for swscaler which is not reflecting what is
shown when running ffmpeg -h full.

Best regards,
Werner


0001-doc-swscaler-fix-documentation-of-pixel-format-and-r.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] [PATCH v2] Add multiple padding method in dnn native

2019-05-15 Thread Xuewei Meng
Guo, Yejun  于2019年5月15日周三 下午2:21写道:

>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Steven Liu
> > Sent: Wednesday, May 15, 2019 10:38 AM
> > To: FFmpeg development discussions and patches 
> > Cc: Xuewei Meng 
> > Subject: Re: [FFmpeg-devel] [PATCH v2] Add multiple padding method in dnn
> > native
> >
> > Xuewei Meng  于2019年5月11日周六 上午11:11
> > 写道:
> > >
> > > ---
> > >  libavfilter/dnn_backend_native.c | 52 
> > >  libavfilter/dnn_backend_native.h |  3 ++
> > >  2 files changed, 43 insertions(+), 12 deletions(-)
>
> @xuewei, we still need to mention the impact of sr filter, and explain why
> same_clamp_to_edge is needed.
>
> There are three padding methods in this patch, VALID, SAME and
SAME_CLAMP_TO_EDGE. The 'VALID' and 'SAME' options are tensorflow supported
padding methods. And the third one, 'SAME_CLAMP_TO_EDGE', is suggested by
sr filter. As this method can keep the output with the same size as
original input, and gives a slight better result as mentioned by Pedro
Arthur. So we keep this option in dnn native mode.


> > >
> > > diff --git a/libavfilter/dnn_backend_native.c
> > b/libavfilter/dnn_backend_native.c
> > > index 06fbdf368b..171a756385 100644
> > > --- a/libavfilter/dnn_backend_native.c
> > > +++ b/libavfilter/dnn_backend_native.c
> > > @@ -61,6 +61,12 @@ static DNNReturnType set_input_output_native(void
> > *model, DNNInputData *input, c
> > >  return DNN_ERROR;
> > >  }
> > >  cur_channels = conv_params->output_num;
> > > +
> > > +if(conv_params->padding_method == VALID){
> > > +int pad_size = conv_params->kernel_size - 1;
> > > +cur_height -= pad_size;
> > > +cur_width -= pad_size;
> > > +}
> > >  break;
> > >  case DEPTH_TO_SPACE:
> > >  depth_to_space_params = (DepthToSpaceParams
> > *)network->layers[layer].params;
> > > @@ -77,6 +83,10 @@ static DNNReturnType set_input_output_native(void
> > *model, DNNInputData *input, c
> > >  if (network->layers[layer].output){
> > >  av_freep(>layers[layer].output);
> > >  }
> > > +
> > > +if(cur_height <= 0 || cur_width <= 0)
> > > +return DNN_ERROR;
> > > +
> > >  network->layers[layer].output = av_malloc(cur_height *
> > cur_width * cur_channels * sizeof(float));
> > >  if (!network->layers[layer].output){
> > >  return DNN_ERROR;
> > > @@ -154,13 +164,14 @@ DNNModel *ff_dnn_load_model_native(const
> > char *model_filename)
> > >  ff_dnn_free_model_native();
> > >  return NULL;
> > >  }
> > > +conv_params->padding_method =
> > (int32_t)avio_rl32(model_file_context);
> > >  conv_params->activation =
> > (int32_t)avio_rl32(model_file_context);
> > >  conv_params->input_num =
> > (int32_t)avio_rl32(model_file_context);
> > >  conv_params->output_num =
> > (int32_t)avio_rl32(model_file_context);
> > >  conv_params->kernel_size =
> > (int32_t)avio_rl32(model_file_context);
> > >  kernel_size = conv_params->input_num *
> > conv_params->output_num *
> > >conv_params->kernel_size *
> > conv_params->kernel_size;
> > > -dnn_size += 16 + (kernel_size + conv_params->output_num
> > << 2);
> > > +dnn_size += 20 + (kernel_size + conv_params->output_num
> > << 2);
> > >  if (dnn_size > file_size || conv_params->input_num <= 0 ||
> > >  conv_params->output_num <= 0 ||
> > conv_params->kernel_size <= 0){
> > >  avio_closep(_file_context);
> > > @@ -218,23 +229,35 @@ DNNModel *ff_dnn_load_model_native(const
> > char *model_filename)
> > >
> > >  static void convolve(const float *input, float *output, const
> > ConvolutionalParams *conv_params, int width, int height)
> > >  {
> > > -int y, x, n_filter, ch, kernel_y, kernel_x;
> > >  int radius = conv_params->kernel_size >> 1;
> > >  int src_linesize = width * conv_params->input_num;
> > >  int filter_linesize = conv_params->kernel_size *
> > conv_params->input_num;
> > >  int filter_size = conv_params->kernel_size * filter_linesize;
> > > +int pad_size = (conv_params->padding_method == VALID) ?
> > (conv_params->kernel_size - 1) / 2 : 0;
> > >
> > > -for (y = 0; y < height; ++y){
> > > -for (x = 0; x < width; ++x){
> > > -for (n_filter = 0; n_filter < conv_params->output_num;
> > ++n_filter){
> > > +for (int y = pad_size; y < height - pad_size; ++y){
> > > +for (int x = pad_size; x < width - pad_size; ++x){
> > > +for (int n_filter = 0; n_filter < conv_params->output_num;
> > ++n_filter){
> > >  output[n_filter] = conv_params->biases[n_filter];
> > > -for (ch = 0; ch < 

Re: [FFmpeg-devel] [PATCH] libavformat/qsvenc: fix mpeg2 missing headers

2019-05-15 Thread Andreas Håkon

Hi Andreas,


> I know nothing about QSV, but I know a bit about MPEG-2 and have
> therefore taken a quick look at this:

I'm running a lot of tests with QSV. So I know a little bit about that.


> 1.
>
> > +  if ((p_buf[7] & 0x1) == 1) {
> > +  memcpy(q->matrix, p_buf + 8, 64);
> > +  p_sec += 4;
> > +  av_log(avctx, AV_LOG_VERBOSE, "Found
>
> You are checking the wrong bit here (it should be the 0x2 bit) and you
> are copying the wrong bits. That's because the intra_quantiser_matrix
> matrix (if it is explicitly coded) doesn't start at a byte-aligned
> position. Maybe you should not split the sequence header into two
> buffers, but simply use one big buffer (and record the size of the
> actual data in the buffer (which of course depends on the whether the
> matrices are explicitly coded or not) somewhere)?
> (If it is so that MPEG-2-QSV only ever uses the
> non_intra_quantiser_matrix, then your approach might make sense.)

I'll revise it.

However, please note that in our tests the QSV MPEG-2 encoder has never
written an intra_quantiser_matrix. The code is here to complete it.


> 2. You are implicitly assuming that only one of the matrices exists,
> but there can be two in the sequence header. Or is it documented
> somewhere that MPEG-2-QSV can only use one matrix?

As I say, the current driver never writes an intra_quantiser_matrix.


> 3. You are also implicitly assuming that there is no
> quant_matrix_extension (which can have up to four matrices in it, but
> only up to two for 4:2:0 video). Is it documented somewhere that this
> is so?

As far as I know, the QSV documentation does not describe anything about it.
Perhaps the best solution is to completely forget the intra_quantiser_matrix.
What do you think?


> 4. According to the standard (section 6.1.1.6), if a sequence header
> access unit contains a sequence_scalable_extension or
> sequence_display_extension, then these need to be repeated in every
> access unit with a repeat sequence header. So if MPEG-2-QSV might emit
> them at the beginning, you need to record them and reinsert them along
> with the rest every time you insert sequence headers.

Sure! But the bitstream from the QSV MPEG-2 encoder never generates
a sequence_scalable_extension nor a sequence_display_extension.
For this reason this patch only reinserts the SEQ_START_CODE and
EXT_START_CODE.


> 5. You seem to use p_sec as a bitfield; so it would seem appropriate
> to use |= to set the bits and not addition.

Well, the current implementation is pretty simple to understand.
I see no reason to change it, as it is an internal loop indicator.


> 6. Is it really certain (and not only observed behaviour) that the QSV
> encoder does not repeat sequence header in-band? (It is against the
> specs to have two sequence headers in an access unit.)

Absolutly! It repeats only Group Of Pictures (01B8), Picture header (0100)
and Picture_Coding_Extension; and forgets the rest.
You can run more tests if you want. But the QSV MPEG-2 encoder has not been
updated for years on Intel drivers.


> 7.
>
> > +  case 1:
> > +  memmove(bs->Data + 23, bs->Data, bs->DataLength - 23);
> > +  bs->DataLength  += 23;
> > +  memcpy( bs->Data + 0 , q->seq_header, 13);
> > +  memcpy( bs->Data + 13, q->seq_ext,10);
> > +  break;
> > +  case 2:
> > +  memmove(bs->Data + 87, bs->Data, bs->DataLength - 87);
> > +  bs->DataLength  += 87;
> > +  memcpy( bs->Data + 0 , q->seq_header, 13);
> > +  memcpy( bs->Data + 13, q->matrix, 64);
> > +  memcpy( bs->Data + 77, q->seq_ext,10);
> > +  break;
>
> This looks extremely fishy: You essentially throw the last 23/87 bytes
> of the bs.Data buffer away and nevertheless you increase the length of
> the data by 23/87 bytes.

Please, note that bs->Data is an already allocated buffer. The allocated
space is q->packet_size that correspond to:

- QSVEncContext *q;
- q->packet_size = q->param.mfx.BufferSizeInKB * 1000;

So the buffer is initialized to a large value inside the function
qsv_retrieve_enc_params() at the initilitation of the hw encoder.

Check it at:
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc.c#L860

So, then it's not a fault to throw the last bytes of the buffer, as the
Length is much small that the Size of the buffer.

Futhermore, the Length is the size of the data allocated inside the
buffer and not the size of the buffer. So, when you reinsert the missing
tables in the header you need to update the value of the Length.

That said, the code is correct.


> 8.
>
> > +   if (avctx->codec_id == AV_CODEC_ID_MPEG2VIDEO) {
> > +  q->section_state = 0;
> > +   }
> > +   else {
> > +  q->section_state = -1;
> > +   }
>
> The 

[FFmpeg-devel] [PATCH] avfilter/drawtext: stop resource leak

2019-05-15 Thread Gyan


See http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244029.html

Gyan
From 22f3b816e8da13877872a2e6ac408fc32de7d561 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Wed, 15 May 2019 12:36:05 +0530
Subject: [PATCH] avfilter/drawtext: stop resource leak

Fixes Coverity CID 1445099
---
 libavfilter/vf_drawtext.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index b166574d71..01cd7fa122 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -894,7 +894,7 @@ static int command(AVFilterContext *ctx, const char *cmd, 
const char *arg, char
 
 ctx->priv = old;
 uninit(ctx);
-av_freep(old);
+av_freep();
 
 ctx->priv = new;
 return config_input(ctx->inputs[0]);
@@ -903,7 +903,7 @@ static int command(AVFilterContext *ctx, const char *cmd, 
const char *arg, char
 
 fail:
 av_log(ctx, AV_LOG_ERROR, "Failed to process command. Continuing with 
existing parameters.\n");
-av_freep(new);
+av_freep();
 return ret;
 }
 
-- 
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 v2] Add multiple padding method in dnn native

2019-05-15 Thread Guo, Yejun


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Steven Liu
> Sent: Wednesday, May 15, 2019 10:38 AM
> To: FFmpeg development discussions and patches 
> Cc: Xuewei Meng 
> Subject: Re: [FFmpeg-devel] [PATCH v2] Add multiple padding method in dnn
> native
> 
> Xuewei Meng  于2019年5月11日周六 上午11:11
> 写道:
> >
> > ---
> >  libavfilter/dnn_backend_native.c | 52 
> >  libavfilter/dnn_backend_native.h |  3 ++
> >  2 files changed, 43 insertions(+), 12 deletions(-)

@xuewei, we still need to mention the impact of sr filter, and explain why 
same_clamp_to_edge is needed.

> >
> > diff --git a/libavfilter/dnn_backend_native.c
> b/libavfilter/dnn_backend_native.c
> > index 06fbdf368b..171a756385 100644
> > --- a/libavfilter/dnn_backend_native.c
> > +++ b/libavfilter/dnn_backend_native.c
> > @@ -61,6 +61,12 @@ static DNNReturnType set_input_output_native(void
> *model, DNNInputData *input, c
> >  return DNN_ERROR;
> >  }
> >  cur_channels = conv_params->output_num;
> > +
> > +if(conv_params->padding_method == VALID){
> > +int pad_size = conv_params->kernel_size - 1;
> > +cur_height -= pad_size;
> > +cur_width -= pad_size;
> > +}
> >  break;
> >  case DEPTH_TO_SPACE:
> >  depth_to_space_params = (DepthToSpaceParams
> *)network->layers[layer].params;
> > @@ -77,6 +83,10 @@ static DNNReturnType set_input_output_native(void
> *model, DNNInputData *input, c
> >  if (network->layers[layer].output){
> >  av_freep(>layers[layer].output);
> >  }
> > +
> > +if(cur_height <= 0 || cur_width <= 0)
> > +return DNN_ERROR;
> > +
> >  network->layers[layer].output = av_malloc(cur_height *
> cur_width * cur_channels * sizeof(float));
> >  if (!network->layers[layer].output){
> >  return DNN_ERROR;
> > @@ -154,13 +164,14 @@ DNNModel *ff_dnn_load_model_native(const
> char *model_filename)
> >  ff_dnn_free_model_native();
> >  return NULL;
> >  }
> > +conv_params->padding_method =
> (int32_t)avio_rl32(model_file_context);
> >  conv_params->activation =
> (int32_t)avio_rl32(model_file_context);
> >  conv_params->input_num =
> (int32_t)avio_rl32(model_file_context);
> >  conv_params->output_num =
> (int32_t)avio_rl32(model_file_context);
> >  conv_params->kernel_size =
> (int32_t)avio_rl32(model_file_context);
> >  kernel_size = conv_params->input_num *
> conv_params->output_num *
> >conv_params->kernel_size *
> conv_params->kernel_size;
> > -dnn_size += 16 + (kernel_size + conv_params->output_num
> << 2);
> > +dnn_size += 20 + (kernel_size + conv_params->output_num
> << 2);
> >  if (dnn_size > file_size || conv_params->input_num <= 0 ||
> >  conv_params->output_num <= 0 ||
> conv_params->kernel_size <= 0){
> >  avio_closep(_file_context);
> > @@ -218,23 +229,35 @@ DNNModel *ff_dnn_load_model_native(const
> char *model_filename)
> >
> >  static void convolve(const float *input, float *output, const
> ConvolutionalParams *conv_params, int width, int height)
> >  {
> > -int y, x, n_filter, ch, kernel_y, kernel_x;
> >  int radius = conv_params->kernel_size >> 1;
> >  int src_linesize = width * conv_params->input_num;
> >  int filter_linesize = conv_params->kernel_size *
> conv_params->input_num;
> >  int filter_size = conv_params->kernel_size * filter_linesize;
> > +int pad_size = (conv_params->padding_method == VALID) ?
> (conv_params->kernel_size - 1) / 2 : 0;
> >
> > -for (y = 0; y < height; ++y){
> > -for (x = 0; x < width; ++x){
> > -for (n_filter = 0; n_filter < conv_params->output_num;
> ++n_filter){
> > +for (int y = pad_size; y < height - pad_size; ++y){
> > +for (int x = pad_size; x < width - pad_size; ++x){
> > +for (int n_filter = 0; n_filter < conv_params->output_num;
> ++n_filter){
> >  output[n_filter] = conv_params->biases[n_filter];
> > -for (ch = 0; ch < conv_params->input_num; ++ch){
> > -for (kernel_y = 0; kernel_y <
> conv_params->kernel_size; ++kernel_y){
> > -for (kernel_x = 0; kernel_x <
> conv_params->kernel_size; ++kernel_x){
> > -output[n_filter] +=
> input[CLAMP_TO_EDGE(y + kernel_y - radius, height) * src_linesize +
> > -
> CLAMP_TO_EDGE(x + kernel_x - radius, width) * conv_params->input_num + ch]
> *
> > -
> conv_params->kernel[n_filter * filter_size + kernel_y * filter_linesize +
> > -
> kernel_x * conv_params->input_num + ch];
> > +
> > +for (int ch = 0; ch < conv_params->input_num; ++ch){
> > +