[FFmpeg-devel] [PATCH v2 1/4] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet

2020-04-20 Thread lance . lmwang
From: Limin Wang 

For better code review, the patch is helping to update the fate tests result
so the change of ffmpeg.c willbe deleted in the last patch.

Signed-off-by: Limin Wang 
---
 fftools/ffmpeg.c |  1 +
 tests/ref/fate/binsub-movtextenc |  2 +-
 tests/ref/fate/sub2video | 86 
 3 files changed, 45 insertions(+), 44 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index d896b14a14..293561a8b1 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1056,6 +1056,7 @@ static void do_subtitle_out(OutputFile *of,
 else
 pkt.pts += av_rescale_q(sub->end_display_time, (AVRational){ 
1, 1000 }, ost->mux_timebase);
 }
+pkt.flags |= AV_PKT_FLAG_KEY;
 pkt.dts = pkt.pts;
 output_packet(of, , ost, 0);
 }
diff --git a/tests/ref/fate/binsub-movtextenc b/tests/ref/fate/binsub-movtextenc
index 78c05f4376..a8f94b7227 100644
--- a/tests/ref/fate/binsub-movtextenc
+++ b/tests/ref/fate/binsub-movtextenc
@@ -1 +1 @@
-35adf776cd73e808186ae7124445f4b8
+fc6d07679ac1f718aa50de687924cd97
diff --git a/tests/ref/fate/sub2video b/tests/ref/fate/sub2video
index 4e034a5e91..80abe9c905 100644
--- a/tests/ref/fate/sub2video
+++ b/tests/ref/fate/sub2video
@@ -10,7 +10,7 @@
 0,  0,  0,1,   518400, 0x83c27b82
 0,  1,  1,1,   518400, 0x4051c7f9
 0,  2,  2,1,   518400, 0xfb00e17e
-1, 499000, 499000,  496, 1015, 0x19e092d2, F=0x0
+1, 499000, 499000,  496, 1015, 0x19e092d2
 0,  3,  3,1,   518400, 0x192abb74
 0,  4,  4,1,   518400, 0x4669a88b
 0,  5,  5,1,   518400, 0xaababe00
@@ -58,129 +58,129 @@
 0, 47, 47,1,   518400, 0xde69683f
 0, 48, 48,1,   518400, 0x7df08fba
 0, 49, 49,1,   518400, 0xbab197ea
-1,   15355000,   15355000,  4733000, 2094, 0x3c171425, F=0x0
+1,   15355000,   15355000,  4733000, 2094, 0x3c171425
 0, 77, 77,1,   518400, 0x902285d9
 0,100,100,1,   518400, 0xbab197ea
-1,   48797000,   48797000,  256, 2480, 0x7c0edf21, F=0x0
+1,   48797000,   48797000,  256, 2480, 0x7c0edf21
 0,244,244,1,   518400, 0x7a11c812
 0,257,257,1,   518400, 0xbab197ea
-1,   51433000,   51433000,  2366000, 3059, 0xc95b8a05, F=0x0
+1,   51433000,   51433000,  2366000, 3059, 0xc95b8a05
 0,258,258,1,   518400, 0x34cdddee
 0,269,269,1,   518400, 0xbab197ea
-1,   5391,   5391,  2696000, 2095, 0x61bb15ed, F=0x0
+1,   5391,   5391,  2696000, 2095, 0x61bb15ed
 0,270,270,1,   518400, 0x4db4ce51
 0,283,283,1,   518400, 0xbab197ea
-1,   56663000,   56663000,  1262000, 1013, 0xc9ae89b7, F=0x0
+1,   56663000,   56663000,  1262000, 1013, 0xc9ae89b7
 0,284,284,1,   518400, 0xe6bc0ea9
 0,290,290,1,   518400, 0xbab197ea
-1,   58014000,   58014000,  1661000,  969, 0xe01878f0, F=0x0
+1,   58014000,   58014000,  1661000,  969, 0xe01878f0
 0,291,291,1,   518400, 0xa8643af7
 0,298,298,1,   518400, 0xbab197ea
-1,   67724000,   67724000,  1365000,  844, 0xe7db4fc1, F=0x0
+1,   67724000,   67724000,  1365000,  844, 0xe7db4fc1
 0,339,339,1,   518400, 0xb1885c67
 0,345,345,1,   518400, 0xbab197ea
-1,   69175000,   69175000,  1558000,  802, 0xf48531ba, F=0x0
+1,   69175000,   69175000,  1558000,  802, 0xf48531ba
 0,346,346,1,   518400, 0x378e3fd0
 0,354,354,1,   518400, 0xbab197ea
-1,   70819000,   70819000,  1865000, 1709, 0xb4d5a1bd, F=0x0
+1,   70819000,   70819000,  1865000, 1709, 0xb4d5a1bd
 0,355,355,1,   518400, 0xa3782469
 0,363,363,1,   518400, 0xbab197ea
-1,   72762000,   72762000,  1968000, 2438, 0x99d7bc82, F=0x0
+1,   72762000,   72762000,  1968000, 2438, 0x99d7bc82
 0,364,364,1,   518400, 0xba23a0d5
 0,374,374,1,   518400, 0xbab197ea
-1,   74806000,   74806000,  1831000, 2116, 0x96514097, F=0x0
+1,   74806000,   74806000,  1831000, 2116, 0x96514097
 0,375,375,1,   518400, 0x129de2f8
 0,383,383,1,   518400, 0xbab197ea
-1,   76716000,   76716000,  1262000, 1822, 0xefccc72e, F=0x0
+1,   76716000,   76716000,  1262000, 1822, 0xefccc72e
 0,384,384,1,   518400, 0x19772f0f
 0,390,390,1,   518400, 0xbab197ea
-1,   78051000,   78051000,  1524000,  987, 0x7b927a27, F=0x0
+1,   78051000,   78051000,  1524000,  

[FFmpeg-devel] [PATCH v2 1/4] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet

2020-04-20 Thread lance . lmwang
From: Limin Wang 

For better code review, the patch is helping to update the fate tests result
so the change of ffmpeg.c will be deleted in the last patch.

Signed-off-by: Limin Wang 
---
 fftools/ffmpeg.c |  1 +
 tests/ref/fate/binsub-movtextenc |  2 +-
 tests/ref/fate/sub2video | 86 
 3 files changed, 45 insertions(+), 44 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index d896b14a14..293561a8b1 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1056,6 +1056,7 @@ static void do_subtitle_out(OutputFile *of,
 else
 pkt.pts += av_rescale_q(sub->end_display_time, (AVRational){ 
1, 1000 }, ost->mux_timebase);
 }
+pkt.flags |= AV_PKT_FLAG_KEY;
 pkt.dts = pkt.pts;
 output_packet(of, , ost, 0);
 }
diff --git a/tests/ref/fate/binsub-movtextenc b/tests/ref/fate/binsub-movtextenc
index 78c05f4376..a8f94b7227 100644
--- a/tests/ref/fate/binsub-movtextenc
+++ b/tests/ref/fate/binsub-movtextenc
@@ -1 +1 @@
-35adf776cd73e808186ae7124445f4b8
+fc6d07679ac1f718aa50de687924cd97
diff --git a/tests/ref/fate/sub2video b/tests/ref/fate/sub2video
index 4e034a5e91..80abe9c905 100644
--- a/tests/ref/fate/sub2video
+++ b/tests/ref/fate/sub2video
@@ -10,7 +10,7 @@
 0,  0,  0,1,   518400, 0x83c27b82
 0,  1,  1,1,   518400, 0x4051c7f9
 0,  2,  2,1,   518400, 0xfb00e17e
-1, 499000, 499000,  496, 1015, 0x19e092d2, F=0x0
+1, 499000, 499000,  496, 1015, 0x19e092d2
 0,  3,  3,1,   518400, 0x192abb74
 0,  4,  4,1,   518400, 0x4669a88b
 0,  5,  5,1,   518400, 0xaababe00
@@ -58,129 +58,129 @@
 0, 47, 47,1,   518400, 0xde69683f
 0, 48, 48,1,   518400, 0x7df08fba
 0, 49, 49,1,   518400, 0xbab197ea
-1,   15355000,   15355000,  4733000, 2094, 0x3c171425, F=0x0
+1,   15355000,   15355000,  4733000, 2094, 0x3c171425
 0, 77, 77,1,   518400, 0x902285d9
 0,100,100,1,   518400, 0xbab197ea
-1,   48797000,   48797000,  256, 2480, 0x7c0edf21, F=0x0
+1,   48797000,   48797000,  256, 2480, 0x7c0edf21
 0,244,244,1,   518400, 0x7a11c812
 0,257,257,1,   518400, 0xbab197ea
-1,   51433000,   51433000,  2366000, 3059, 0xc95b8a05, F=0x0
+1,   51433000,   51433000,  2366000, 3059, 0xc95b8a05
 0,258,258,1,   518400, 0x34cdddee
 0,269,269,1,   518400, 0xbab197ea
-1,   5391,   5391,  2696000, 2095, 0x61bb15ed, F=0x0
+1,   5391,   5391,  2696000, 2095, 0x61bb15ed
 0,270,270,1,   518400, 0x4db4ce51
 0,283,283,1,   518400, 0xbab197ea
-1,   56663000,   56663000,  1262000, 1013, 0xc9ae89b7, F=0x0
+1,   56663000,   56663000,  1262000, 1013, 0xc9ae89b7
 0,284,284,1,   518400, 0xe6bc0ea9
 0,290,290,1,   518400, 0xbab197ea
-1,   58014000,   58014000,  1661000,  969, 0xe01878f0, F=0x0
+1,   58014000,   58014000,  1661000,  969, 0xe01878f0
 0,291,291,1,   518400, 0xa8643af7
 0,298,298,1,   518400, 0xbab197ea
-1,   67724000,   67724000,  1365000,  844, 0xe7db4fc1, F=0x0
+1,   67724000,   67724000,  1365000,  844, 0xe7db4fc1
 0,339,339,1,   518400, 0xb1885c67
 0,345,345,1,   518400, 0xbab197ea
-1,   69175000,   69175000,  1558000,  802, 0xf48531ba, F=0x0
+1,   69175000,   69175000,  1558000,  802, 0xf48531ba
 0,346,346,1,   518400, 0x378e3fd0
 0,354,354,1,   518400, 0xbab197ea
-1,   70819000,   70819000,  1865000, 1709, 0xb4d5a1bd, F=0x0
+1,   70819000,   70819000,  1865000, 1709, 0xb4d5a1bd
 0,355,355,1,   518400, 0xa3782469
 0,363,363,1,   518400, 0xbab197ea
-1,   72762000,   72762000,  1968000, 2438, 0x99d7bc82, F=0x0
+1,   72762000,   72762000,  1968000, 2438, 0x99d7bc82
 0,364,364,1,   518400, 0xba23a0d5
 0,374,374,1,   518400, 0xbab197ea
-1,   74806000,   74806000,  1831000, 2116, 0x96514097, F=0x0
+1,   74806000,   74806000,  1831000, 2116, 0x96514097
 0,375,375,1,   518400, 0x129de2f8
 0,383,383,1,   518400, 0xbab197ea
-1,   76716000,   76716000,  1262000, 1822, 0xefccc72e, F=0x0
+1,   76716000,   76716000,  1262000, 1822, 0xefccc72e
 0,384,384,1,   518400, 0x19772f0f
 0,390,390,1,   518400, 0xbab197ea
-1,   78051000,   78051000,  1524000,  987, 0x7b927a27, F=0x0
+1,   78051000,   78051000,  1524000, 

Re: [FFmpeg-devel] [PATCH] lavfi/vf_vpp_qsv: fix the infinite loop while framerate lower than input

2020-04-20 Thread Fu, Linjie
> From: Zhong Li 
> Sent: Sunday, April 19, 2020 23:00
> To: Fu, Linjie 
> Cc: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavfi/vf_vpp_qsv: fix the infinite loop
> while framerate lower than input
> 
> Fu, Linjie  于2020年2月29日周六 下午5:35写道:
> >
> > > -Original Message-
> > > From: Zhong Li 
> > > Sent: Saturday, February 29, 2020 13:14
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Cc: Fu, Linjie 
> > > Subject: Re: [FFmpeg-devel] [PATCH] lavfi/vf_vpp_qsv: fix the infinite
> loop
> > > while framerate lower than input
> > >
> > > Linjie Fu  于2020年2月28日周五 下午11:34写
> 道:
> > > >
> > > > There are frame droppings in frc while converting into a lower
> framerate,
> > > > and MSDK returns ERROR_MORE_DATA which should be ignored.
> > >
> > > Should be fixed in MSDK instead of working around in FFmpeg?
> >
> > MSDK made decision regarding frame rate conversion. If it's the framerate
> down case,
> > FRC would skip frame without producing an output [1], and request a new
> input frame.
> 
> I can't see the benefit to use MSDK framerate conversion function. Is
> it a good idea to drop it and use ffmpeg native fps filter instead?

The implementation of FRC inside MSDK is quite straight-forward or simple
currently since it just drops or repeats frames, hence I think using native fps
filter is a good idea for decoding + FRC or FRC + encoding.

However, for a pure hardware transcoding pipeline, there may be some
performance issues if inserting a software filter, extra memory copy would
be introduced in hwdownload/hwupload between system memory and video
memory, which would impact a lot for large resolutions.

Took a simple tests for 4K 10bit HEVC transcoding:

# inserting a fps filter in the transcoding: 20 fps
$ ffmpeg -hwaccel qsv -c:v hevc_qsv -i ../Exodus_UHD_HDR_Exodus_draft.mp4 -vf 
"hwdownload,format=p010le,fps=fps=60,hwupload=extra_hw_frames=40" -c:v hevc_qsv 
out.mp4

# using msdk framerate conversion: 33 fps
$ ffmpeg -hwaccel qsv -c:v hevc_qsv -i ../Exodus_UHD_HDR_Exodus_draft.mp4 -vf 
"vpp_qsv=framerate=60" -c:v hevc_qsv out.mp4

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

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

[FFmpeg-devel] [PATCH v2 3/4] avformat/utils: move is_intra_only() to header and rename to ff_is_intra_only()

2020-04-20 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/internal.h | 2 ++
 libavformat/utils.c| 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index 329b2e972d..716e42cc3e 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -521,6 +521,8 @@ unsigned int ff_codec_get_tag(const AVCodecTag *tags, enum 
AVCodecID id);
 
 enum AVCodecID ff_codec_get_id(const AVCodecTag *tags, unsigned int tag);
 
+int ff_is_intra_only(enum AVCodecID id);
+
 /**
  * Select a PCM codec based on the given parameters.
  *
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 2fb2309f68..259b2f0aba 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1016,7 +1016,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
-static int is_intra_only(enum AVCodecID id)
+int ff_is_intra_only(enum AVCodecID id)
 {
 const AVCodecDescriptor *d = avcodec_descriptor_get(id);
 if (!d)
@@ -1415,7 +1415,7 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 presentation_delayed, delay, av_ts2str(pkt->pts), 
av_ts2str(pkt->dts), av_ts2str(st->cur_dts), st->index, st->id);
 
 /* update flags */
-if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA || 
is_intra_only(st->codecpar->codec_id))
+if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA || 
ff_is_intra_only(st->codecpar->codec_id))
 pkt->flags |= AV_PKT_FLAG_KEY;
 #if FF_API_CONVERGENCE_DURATION
 FF_DISABLE_DEPRECATION_WARNINGS
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH v2 4/4] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet

2020-04-20 Thread lance . lmwang
From: Limin Wang 

delete the previous change of ffmpeg.c and movenc.c as mux.c will be
in charge of setting AV_PKT_FLAG_KEY.

Signed-off-by: Limin Wang 
---
 fftools/ffmpeg.c   | 1 -
 libavformat/internal.h | 2 ++
 libavformat/mux.c  | 7 ++-
 libavformat/tests/movenc.c | 1 -
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 293561a8b1..d896b14a14 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1056,7 +1056,6 @@ static void do_subtitle_out(OutputFile *of,
 else
 pkt.pts += av_rescale_q(sub->end_display_time, (AVRational){ 
1, 1000 }, ost->mux_timebase);
 }
-pkt.flags |= AV_PKT_FLAG_KEY;
 pkt.dts = pkt.pts;
 output_packet(of, , ost, 0);
 }
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 716e42cc3e..c4fac5cc76 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -189,6 +189,8 @@ struct AVStreamInternal {
  */
 int need_context_update;
 
+int is_intra_only;
+
 FFFrac *priv_pts;
 };
 
diff --git a/libavformat/mux.c b/libavformat/mux.c
index a6253f5430..ea6524f579 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -357,6 +357,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (desc && desc->props & AV_CODEC_PROP_REORDER)
 st->internal->reorder = 1;
 
+st->internal->is_intra_only = ff_is_intra_only(par->codec_id);
+
 if (of->codec_tag) {
 if (   par->codec_tag
 && par->codec_id == AV_CODEC_ID_RAWVIDEO
@@ -773,6 +775,7 @@ static int check_packet(AVFormatContext *s, AVPacket *pkt)
 static int prepare_input_packet(AVFormatContext *s, AVPacket *pkt)
 {
 int ret;
+AVStream *st = s->streams[pkt->stream_index];
 
 ret = check_packet(s, pkt);
 if (ret < 0)
@@ -781,7 +784,6 @@ static int prepare_input_packet(AVFormatContext *s, 
AVPacket *pkt)
 #if !FF_API_COMPUTE_PKT_FIELDS2 || !FF_API_LAVF_AVCTX
 /* sanitize the timestamps */
 if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS)) {
-AVStream *st = s->streams[pkt->stream_index];
 
 /* when there is no reordering (so dts is equal to pts), but
  * only one of them is set, set the other as well */
@@ -818,6 +820,9 @@ static int prepare_input_packet(AVFormatContext *s, 
AVPacket *pkt)
 }
 }
 #endif
+/* update flags */
+if (st->internal->is_intra_only)
+pkt->flags |= AV_PKT_FLAG_KEY;
 
 return 0;
 }
diff --git a/libavformat/tests/movenc.c b/libavformat/tests/movenc.c
index 0ff87da7d6..1d15d97ad9 100644
--- a/libavformat/tests/movenc.c
+++ b/libavformat/tests/movenc.c
@@ -256,7 +256,6 @@ static void mux_frames(int n, int c)
 pkt.dts = pkt.pts = audio_dts;
 pkt.stream_index = 1;
 pkt.duration = audio_duration;
-pkt.flags |= AV_PKT_FLAG_KEY;
 audio_dts += audio_duration;
 } else {
 if (frames == end_frames)
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH v2 2/4] avformat/tests/movenc: set AV_PKT_FLAG_KEY for audio packet

2020-04-20 Thread lance . lmwang
From: Limin Wang 

For better code review, the patch is helping to update the fate tests result
so the change of movenc.c will be deleted in the last patch.

Signed-off-by: Limin Wang 
---
 libavformat/tests/movenc.c |  1 +
 tests/ref/fate/movenc  | 50 +++---
 2 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/libavformat/tests/movenc.c b/libavformat/tests/movenc.c
index 1d15d97ad9..0ff87da7d6 100644
--- a/libavformat/tests/movenc.c
+++ b/libavformat/tests/movenc.c
@@ -256,6 +256,7 @@ static void mux_frames(int n, int c)
 pkt.dts = pkt.pts = audio_dts;
 pkt.stream_index = 1;
 pkt.duration = audio_duration;
+pkt.flags |= AV_PKT_FLAG_KEY;
 audio_dts += audio_duration;
 } else {
 if (frames == end_frames)
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 637a347e05..fb39b98165 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -2,17 +2,17 @@ write_data len 36, time nopts, type header atom ftyp
 write_data len 2389, time nopts, type header atom -
 write_data len 788, time 100, type sync atom moof
 write_data len 110, time nopts, type trailer atom -
-66cf48604f039aa9a51711786f5c8778 3323 non-empty-moov
+5f401347fc3c771b819e2449d69d4861 3323 non-empty-moov
 write_data len 36, time nopts, type header atom ftyp
 write_data len 2721, time nopts, type header atom -
 write_data len 908, time 97, type sync atom moof
 write_data len 110, time nopts, type trailer atom -
-04b2e86f455af94f9258b8d66dbf71f5 3775 non-empty-moov-elst
+4267feee527adf8cd4f7b36ac0fc0872 3775 non-empty-moov-elst
 write_data len 36, time nopts, type header atom ftyp
 write_data len 2629, time nopts, type header atom -
 write_data len 908, time 100, type sync atom moof
 write_data len 110, time nopts, type trailer atom -
-e9f6fa032d6d8265d67aef5de81a48bf 3683 non-empty-moov-no-elst
+44077b9ad45f3e16fafe4e5ada54e9b0 3683 non-empty-moov-no-elst
 write_data len 24, time nopts, type header atom ftyp
 write_data len 1171, time nopts, type header atom -
 write_data len 728, time 0, type sync atom moof
@@ -20,35 +20,35 @@ write_data len 828, time nopts, type unknown atom -
 write_data len 728, time 99, type sync atom moof
 write_data len 812, time nopts, type unknown atom -
 write_data len 148, time nopts, type trailer atom -
-da105e0b2c19079519c6eed7d5a1151c 4439 ismv
+92ce825ff40505ec8676191705adb7e7 4439 ismv
 write_data len 36, time nopts, type header atom ftyp
 write_data len 1123, time nopts, type header atom -
 write_data len 796, time 0, type sync atom moof
 write_data len 788, time 100, type sync atom moof
 write_data len 148, time nopts, type trailer atom -
-e6a4b15443d006efd727a80f6624b7db 2891 empty-moov
+08f4b3ad3a3ea224b2ee731476b9056b 2891 empty-moov
 write_data len 36, time nopts, type header atom ftyp
 write_data len 1123, time nopts, type header atom -
 write_data len 1068, time 0, type sync atom moof
 write_data len 908, time 100, type sync atom moof
 write_data len 148, time nopts, type trailer atom -
-800f854aff2ac76dfaddebd0562c75b9 3283 empty-moov-no-elst
+d7a2dcb43eb0f95f92669f55fc7adeba 3283 empty-moov-no-elst
 write_data len 36, time nopts, type header atom ftyp
 write_data len 1123, time nopts, type header atom -
 write_data len 900, time -3, type sync atom moof
 write_data len 908, time 97, type sync atom moof
 write_data len 148, time nopts, type trailer atom -
-eca1a945c9063dab0858af6b85925533 3115 empty-moov-no-elst-no-adjust
+ea70ca697306976879be408431c27aee 3115 empty-moov-no-elst-no-adjust
 write_data len 1159, time nopts, type header atom ftyp
 write_data len 796, time 0, type sync atom moof
 write_data len 788, time 100, type sync atom moof
 write_data len 148, time nopts, type trailer atom -
-e6a4b15443d006efd727a80f6624b7db 2891 delay-moov
+08f4b3ad3a3ea224b2ee731476b9056b 2891 delay-moov
 write_data len 1231, time nopts, type header atom ftyp
 write_data len 916, time -3, type sync atom moof
 write_data len 908, time 97, type sync atom moof
 write_data len 148, time nopts, type trailer atom -
-c2ecdbc80668fcee73f5a039e2dba579 3203 delay-moov-elst
+314cc3b6296f4ee583b328a34be50b2f 3203 delay-moov-elst
 write_data len 1195, time nopts, type header atom ftyp
 write_data len 836, time 0, type sync atom moof
 write_data len 67, time nopts, type trailer atom -
@@ -63,66 +63,66 @@ write_data len 1123, time nopts, type header atom -
 351ae2c8b6d35d98b4848c309cce6704 1159 empty-moov-header
 write_data len 796, time 0, type sync atom moof
 write_data len 788, time 100, type sync atom moof
-a0165f4a26a409212b0946e981bdefb9 1584 empty-moov-content
+289ee982188d66988a374a462b0b5376 1584 empty-moov-content
 write_data len 148, time nopts, type trailer atom -
 write_data len 1159, time nopts, type header atom ftyp
 351ae2c8b6d35d98b4848c309cce6704 1159 delay-moov-header
 write_data len 796, time 0, type sync atom moof
 

Re: [FFmpeg-devel] [PATCH v4 2/7] lavutil: add DOVI related header

2020-04-20 Thread myp...@gmail.com
On Mon, Apr 20, 2020 at 9:08 PM Anton Khirnov  wrote:
>
> Quoting Jean-Baptiste Kempf (2020-04-19 10:25:07)
> > I'd like to ask opinions whether a installed header for just one structure 
> > is a good idea.
>
> I see no problem with it. More smaller headers is better that a few big
> headers.
>
> Another issue is that this struct has no constructor and thus cannot be
> extended without breaking ABI.
>
This structure is part of API, so I can't find a simple way to extend
without break the ABI, I believe  there are similar problems for
AVSphericalMapping
___
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 8/8] avcodec/mjpeg2jpeg_bsf: Remove unnecessary header

2020-04-20 Thread Andreas Rheinhardt
libavutil/mem.h is unneeded since 33d18982fa03feb061c8f744a4f0a9175c1f63ab,
the commit that introduced the new packet-based bsf API, because with
this switch the allocations were no longer performed directly, but by
av_new_packet().

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mjpeg2jpeg_bsf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/mjpeg2jpeg_bsf.c b/libavcodec/mjpeg2jpeg_bsf.c
index 6f02bc033c..76605b2805 100644
--- a/libavcodec/mjpeg2jpeg_bsf.c
+++ b/libavcodec/mjpeg2jpeg_bsf.c
@@ -27,7 +27,6 @@
 #include 
 
 #include "libavutil/error.h"
-#include "libavutil/mem.h"
 #include "libavutil/intreadwrite.h"
 
 #include "avcodec.h"
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 5/8] avcodec/dca_core_bsf: Remove unnecessary header

2020-04-20 Thread Andreas Rheinhardt
This bsf never needed libavutil/mem.h.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dca_core_bsf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/dca_core_bsf.c b/libavcodec/dca_core_bsf.c
index 8565796951..f0c5039e30 100644
--- a/libavcodec/dca_core_bsf.c
+++ b/libavcodec/dca_core_bsf.c
@@ -22,7 +22,6 @@
 #include "bsf.h"
 #include "bytestream.h"
 #include "dca_syncwords.h"
-#include "libavutil/mem.h"
 
 static int dca_core_filter(AVBSFContext *ctx, AVPacket *pkt)
 {
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 4/8] avcodec/chomp_bsf: Remove unnecessary header

2020-04-20 Thread Andreas Rheinhardt
This bsf never needed internal.h.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/chomp_bsf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/chomp_bsf.c b/libavcodec/chomp_bsf.c
index 3ba45f3e06..9b06ace0a4 100644
--- a/libavcodec/chomp_bsf.c
+++ b/libavcodec/chomp_bsf.c
@@ -21,7 +21,6 @@
 
 #include "avcodec.h"
 #include "bsf.h"
-#include "internal.h"
 
 static int chomp_filter(AVBSFContext *ctx, AVPacket *pkt)
 {
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 3/8] avcodec/vp9_raw_reorder_bsf: Remove unnecessary header

2020-04-20 Thread Andreas Rheinhardt
This bsf doesn't have any options, so including libavutil/opt.h is
unnecessary.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/vp9_raw_reorder_bsf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/vp9_raw_reorder_bsf.c b/libavcodec/vp9_raw_reorder_bsf.c
index e55a358457..2a1bdb9ba7 100644
--- a/libavcodec/vp9_raw_reorder_bsf.c
+++ b/libavcodec/vp9_raw_reorder_bsf.c
@@ -20,7 +20,6 @@
 #include "libavutil/intmath.h"
 #include "libavutil/log.h"
 #include "libavutil/mem.h"
-#include "libavutil/opt.h"
 
 #include "bsf.h"
 #include "get_bits.h"
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 7/8] avcodec/noise_bsf: Remove unnecessary headers

2020-04-20 Thread Andreas Rheinhardt
With 33d18982fa03feb061c8f744a4f0a9175c1f63ab, the commit introducing
the new packet-based bsf API, a new buffer was no longer allocated
directly, but via av_new_packet(), so that libavutil/mem.h was no longer
needed.

Moreover since commit dc99ee6b08e54de13b4c82ff265609b6ab83e3d8
av_packet_make_writable() is employed which copies the data in case it
is unavoidable so that string.h is no longer used (it was used for
memcpy()).

Finally, this bsf has options and therefore uses an AVClass, yet it
doesn't do logging. So remove libavutil/log.h.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/noise_bsf.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
index 721fd217ec..3e85c2c698 100644
--- a/libavcodec/noise_bsf.c
+++ b/libavcodec/noise_bsf.c
@@ -19,13 +19,10 @@
  */
 
 #include 
-#include 
 
 #include "avcodec.h"
 #include "bsf.h"
 
-#include "libavutil/log.h"
-#include "libavutil/mem.h"
 #include "libavutil/opt.h"
 
 typedef struct NoiseContext {
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 6/8] avcodec/dump_extradata_bsf: Remove unnecessary header

2020-04-20 Thread Andreas Rheinhardt
Since 33d18982fa03feb061c8f744a4f0a9175c1f63ab (the commit that
introduced the new bsf API) allocating an enlarged buffer in case
extradata needs to be added to a packet is done via av_new_packet(),
so that libavutil/mem.h is no longer needed.

Furthermore, remove libavutil/log.h. This function uses something
provided by it (an AVClass), yet it does so only for AVOptions, not
for logging purposes (there is no av_log() here), so only including
libavutil/opt.h seems appropriate.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dump_extradata_bsf.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/dump_extradata_bsf.c b/libavcodec/dump_extradata_bsf.c
index 0b6d404792..fbff795380 100644
--- a/libavcodec/dump_extradata_bsf.c
+++ b/libavcodec/dump_extradata_bsf.c
@@ -23,8 +23,6 @@
 #include "avcodec.h"
 #include "bsf.h"
 
-#include "libavutil/log.h"
-#include "libavutil/mem.h"
 #include "libavutil/opt.h"
 
 enum DumpFreq {
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 2/8] avformat/mux: Remove unnecessary headers

2020-04-20 Thread Andreas Rheinhardt
mux.c was split from utils.c in 55f9037f38bc3beacb2f5a17408c1d24c077d7fd
and during this split all headers were simply copied without checking if
they were only needed in the part that stayed in utils.c (or whether
these haeders were needed at all). As a result quite a lot of headers
in mux.c are unnecessary. This commit removes them.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index a6253f5430..c348b8fdc8 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -20,29 +20,16 @@
  */
 
 #include "avformat.h"
-#include "avio_internal.h"
 #include "internal.h"
 #include "libavcodec/internal.h"
-#include "libavcodec/bytestream.h"
 #include "libavutil/opt.h"
 #include "libavutil/dict.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/timestamp.h"
-#include "metadata.h"
-#include "id3v2.h"
 #include "libavutil/avassert.h"
 #include "libavutil/avstring.h"
 #include "libavutil/internal.h"
 #include "libavutil/mathematics.h"
-#include "libavutil/parseutils.h"
-#include "libavutil/time.h"
-#include "riff.h"
-#include "audiointerleave.h"
-#include "url.h"
-#include 
-#if CONFIG_NETWORK
-#include "network.h"
-#endif
 
 /**
  * @file
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 1/8] avformat/utils: Remove superfluous headers

2020-04-20 Thread Andreas Rheinhardt
stdarg.h has been included in 780d7897a9c9295b43f1f0e9b49a11f99cd402c3
for ff_url_join(). This header became unnecessary when this function was
moved into a separate file in df9f22d42b0905385629a9d368bb5a1eef2b45ef.

libavutil/pixdesc.h has been included for av_get_pix_fmt_name() in
603b8bc2a109978c8499b06d2556f1433306eca7 and is unused since commit
2fb7501938b7103624c9bef740ca498258cacdab that removed the stuff belonging
to FF_API_FORMAT_PARAMETERS. Notice that this file still uses
AV_PIX_FMT_NONE and that therefore the header libavutil/pixfmt.h has
been included (this header is included in pixdesc.h as well as also in
libavutil/internal.h which is also included).

libavutil/time_internal.h has been included for gmtime_r() in commit
e7dd97b5d8cd6ea150446591f37a5946e8ab7cfb; it is unused since commit
b72a7b96f84e5f16dd93b60668aecfda99442c71 which basically moved the code
making use of gmtime_r() to libavutil/dict.c to use in
avpriv_dict_set_timestamp().

audiointerleave.h has been added in c26e58e32cf430f060209e0d6088181f4426b3ce
because of ff_interleave_compare_dts() (at that time the muxing code
was not split from utils.c yet); said function became static in commit
101e1f6ff90c3365bfde05469ae26d2ee7f71f3e, making this header redundant.

metadata.h has been mostly included for what now resides in
libavutil/dict.h. The stuff that now resides in metadata.h has only been
used briefly: From commits ed7694d8cf4633da444237f4df7efc48936419d2 to
d60a9f52eb42dc76dea9996c8ba3567ae98a9a04.

riff.h has been added in 45da8124a09d0ac5f9d8174884584c5f80309d0c
because riff.h once contained declarations for (ff_)codec_get_tag().
This was changed in bfe5454cd238b16e7977085f880205229103eccb.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/utils.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 2fb2309f68..a36d6738cd 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -19,7 +19,6 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include 
 #include 
 
 #include "config.h"
@@ -31,26 +30,22 @@
 #include "libavutil/mathematics.h"
 #include "libavutil/opt.h"
 #include "libavutil/parseutils.h"
-#include "libavutil/pixdesc.h"
+#include "libavutil/pixfmt.h"
 #include "libavutil/thread.h"
 #include "libavutil/time.h"
-#include "libavutil/time_internal.h"
 #include "libavutil/timestamp.h"
 
 #include "libavcodec/bytestream.h"
 #include "libavcodec/internal.h"
 #include "libavcodec/raw.h"
 
-#include "audiointerleave.h"
 #include "avformat.h"
 #include "avio_internal.h"
 #include "id3v2.h"
 #include "internal.h"
-#include "metadata.h"
 #if CONFIG_NETWORK
 #include "network.h"
 #endif
-#include "riff.h"
 #include "url.h"
 
 #include "libavutil/ffversion.h"
-- 
2.20.1

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec/avpacket: Don't simply forward return value of av_dict_set()

2020-04-20 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> The documentation of av_dict_set() states that values >= 0 indicate
> success, whereas av_packet_unpack_dictionary() implies that return
> values > 0 are impossible. So only forward the return value of
> av_dict_set() in av_packet_unpack_dictionary() on error.
> 
> (Btw: av_dict_set() does currently not return values > 0.)
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/avpacket.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index ad020eef13..360722c365 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -525,10 +525,10 @@ fail:
>  int av_packet_unpack_dictionary(const uint8_t *data, int size, AVDictionary 
> **dict)
>  {
>  const uint8_t *end;
> -int ret = 0;
> +int ret;
>  
>  if (!dict || !data || !size)
> -return ret;
> +return 0;
>  end = data + size;
>  if (size && end[-1])
>  return AVERROR_INVALIDDATA;
> @@ -541,11 +541,11 @@ int av_packet_unpack_dictionary(const uint8_t *data, 
> int size, AVDictionary **di
>  
>  ret = av_dict_set(dict, key, val, 0);
>  if (ret < 0)
> -break;
> +return ret;
>  data = val + strlen(val) + 1;
>  }
>  
> -return ret;
> +return 0;
>  }
>  
>  int av_packet_shrink_side_data(AVPacket *pkt, enum AVPacketSideDataType type,
> 
Will apply tomorrow if there are no objections.

- 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] avformat/r3d: Remove write-only array

2020-04-20 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/r3d.c | 20 +++-
>  1 file changed, 3 insertions(+), 17 deletions(-)
> 
> diff --git a/libavformat/r3d.c b/libavformat/r3d.c
> index 224bcf780d..7aa0c5a2c3 100644
> --- a/libavformat/r3d.c
> +++ b/libavformat/r3d.c
> @@ -27,7 +27,6 @@
>  
>  typedef struct R3DContext {
>  unsigned video_offsets_count;
> -unsigned *video_offsets;
>  unsigned rdvo_offset;
>  
>  int audio_channels;
> @@ -118,17 +117,14 @@ static int r3d_read_rdvo(AVFormatContext *s, Atom *atom)
>  int i;
>  
>  r3d->video_offsets_count = (atom->size - 8) / 4;
> -r3d->video_offsets = av_malloc(atom->size);
> -if (!r3d->video_offsets)
> -return AVERROR(ENOMEM);
>  
>  for (i = 0; i < r3d->video_offsets_count; i++) {
> -r3d->video_offsets[i] = avio_rb32(s->pb);
> -if (!r3d->video_offsets[i]) {
> +unsigned video_offset = avio_rb32(s->pb);
> +if (!video_offset) {
>  r3d->video_offsets_count = i;
>  break;
>  }
> -av_log(s, AV_LOG_TRACE, "video offset %d: %#x\n", i, 
> r3d->video_offsets[i]);
> +av_log(s, AV_LOG_TRACE, "video offset %d: %#x\n", i, video_offset);
>  }
>  
>  if (st->avg_frame_rate.num)
> @@ -400,15 +396,6 @@ static int r3d_seek(AVFormatContext *s, int 
> stream_index, int64_t sample_time, i
>  return 0;
>  }
>  
> -static int r3d_close(AVFormatContext *s)
> -{
> -R3DContext *r3d = s->priv_data;
> -
> -av_freep(>video_offsets);
> -
> -return 0;
> -}
> -
>  AVInputFormat ff_r3d_demuxer = {
>  .name   = "r3d",
>  .long_name  = NULL_IF_CONFIG_SMALL("REDCODE R3D"),
> @@ -416,6 +403,5 @@ AVInputFormat ff_r3d_demuxer = {
>  .read_probe = r3d_probe,
>  .read_header= r3d_read_header,
>  .read_packet= r3d_read_packet,
> -.read_close = r3d_close,
>  .read_seek  = r3d_seek,
>  };
> 
Will apply tomorrow if there are no objections.

- 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] avformat/webvttdec: Remove write-only variable

2020-04-20 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/webvttdec.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/libavformat/webvttdec.c b/libavformat/webvttdec.c
> index 52579c5ed2..6c4d5f6736 100644
> --- a/libavformat/webvttdec.c
> +++ b/libavformat/webvttdec.c
> @@ -60,7 +60,7 @@ static int64_t read_ts(const char *s)
>  static int webvtt_read_header(AVFormatContext *s)
>  {
>  WebVTTContext *webvtt = s->priv_data;
> -AVBPrint header, cue;
> +AVBPrint cue;
>  int res = 0;
>  AVStream *st = avformat_new_stream(s, NULL);
>  
> @@ -71,7 +71,6 @@ static int webvtt_read_header(AVFormatContext *s)
>  st->codecpar->codec_id   = AV_CODEC_ID_WEBVTT;
>  st->disposition |= webvtt->kind;
>  
> -av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
>  av_bprint_init(,0, AV_BPRINT_SIZE_UNLIMITED);
>  
>  for (;;) {
> @@ -166,7 +165,6 @@ static int webvtt_read_header(AVFormatContext *s)
>  
>  end:
>  av_bprint_finalize(,NULL);
> -av_bprint_finalize(, NULL);
>  return res;
>  }
>  
> 
Will apply tomorrow unless there are objections.

- 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 6/6] dnn-layer-mathbinary-test: add unit test for divide

2020-04-20 Thread Guo, Yejun


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Guo, Yejun
> Sent: Thursday, April 16, 2020 8:53 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 6/6] dnn-layer-mathbinary-test: add unit
> test for divide
> 
> 
> 
> > -Original Message-
> > From: Guo, Yejun
> > Sent: Saturday, April 11, 2020 4:40 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Guo, Yejun 
> > Subject: [PATCH 6/6] dnn-layer-mathbinary-test: add unit test for divide
> >
> > Signed-off-by: Guo, Yejun 
> 
> this patch set ask for review, thanks.

will push tomorrow if no other comments, 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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cbs_h265_syntax_template: Limit num_long_term_pics more strictly

2020-04-20 Thread James Almer
On 4/20/2020 7:03 PM, Michael Niedermayer wrote:
> The limit is based on hevcdec.c
> Fixes: 
> 20854/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5160442882424832
> Fixes: out of array access
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/cbs_h265_syntax_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/cbs_h265_syntax_template.c 
> b/libavcodec/cbs_h265_syntax_template.c
> index 180a045c34..b74b9648c3 100644
> --- a/libavcodec/cbs_h265_syntax_template.c
> +++ b/libavcodec/cbs_h265_syntax_template.c
> @@ -1367,7 +1367,7 @@ static int 
> FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
>  infer(num_long_term_sps, 0);
>  idx_size = 0;
>  }
> -ue(num_long_term_pics, 0, HEVC_MAX_LONG_TERM_REF_PICS);
> +ue(num_long_term_pics, 0, FFMIN(HEVC_MAX_LONG_TERM_REF_PICS, 
> FF_ARRAY_ELEMS(current->poc_lsb_lt) - current->num_long_term_sps));

Maybe poc_lsb_lt should also have HEVC_MAX_LONG_TERM_REF_PICS elems
instead of HEVC_MAX_REFS, same as in the hevc decoder.

Also the spec defines some specific limit to this field:

"When nuh_layer_id is equal to 0, the value of num_long_term_pics shall
be less than or equal to sps_max_dec_pic_buffering_minus1[TemporalId] −
NumNegativePics[CurrRpsIdx] − NumPositivePics[CurrRpsIdx] −
num_long_term_sps − TwoVersionsOfCurrDecPicFlag"

With CurrRpsIdx derived as:
– If short_term_ref_pic_set_sps_flag is equal to 1, CurrRpsIdx is set
equal to short_term_ref_pic_set_idx.
– Otherwise, CurrRpsIdx is set equal to num_short_term_ref_pic_sets.

And TwoVersionsOfCurrDecPicFlag as:
"TwoVersionsOfCurrDecPicFlag = pps_curr_pic_ref_enabled_flag &&
(sample_adaptive_offset_enabled_flag ||
!pps_deblocking_filter_disabled_flag ||
deblocking_filter_override_enabled_flag)
When sps_max_dec_pic_buffering_minus1[ TemporalId ] is equal to 0, the
value of TwoVersionsOfCurrDecPicFlag shall be equal to 0."

But i don't know if it's worth adding that many checks.
___
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] [RFC PATCH v2] libavcodec/jpeg2000_parser: Add jpeg2000 parser

2020-04-20 Thread Michael Niedermayer
On Mon, Apr 20, 2020 at 04:13:44PM +0530, Gautam Ramakrishnan wrote:
> On Mon, Apr 20, 2020 at 3:38 PM Michael Niedermayer
>  wrote:
> >
> > On Mon, Apr 20, 2020 at 01:36:47AM +0530, gautamr...@gmail.com wrote:
> > > From: Gautam Ramakrishnan 
> > >
> > > I have attempted to write a JPEG2000 Parser. Need
> > > help on testing the code and some tips on how to
> >
> > to test the code i would sugest to generate a file
> > or files with many jpeg2000 images and then try to
> > decode it to -f framecrc
> This helps me check whether the image is correct by comparing the CRC value?
> > if that work repeat while varying the packet size
> > input to the parser, a parser must work with anything
> > from 1 byte per input to sizes being larger than a
> > single frame.
> >
> So a packet to a parser is basically a smaller unit to which the parser is fed
> data to? When I tried printing buffer size during parse, it shows 4096.

> Does that mean the packet size was 4096?

yes, that likely comes from 
libavformat/img2dec.c:size[0] = 4096;

random pieces of bytes -> parser -> sequence of packets representing frames

thanks

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

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

[FFmpeg-devel] [PATCH 3/3] avcodec/cbs_h265_syntax_template: Limit num_long_term_pics more strictly

2020-04-20 Thread Michael Niedermayer
The limit is based on hevcdec.c
Fixes: 
20854/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5160442882424832
Fixes: out of array access

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

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 180a045c34..b74b9648c3 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1367,7 +1367,7 @@ static int 
FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
 infer(num_long_term_sps, 0);
 idx_size = 0;
 }
-ue(num_long_term_pics, 0, HEVC_MAX_LONG_TERM_REF_PICS);
+ue(num_long_term_pics, 0, FFMIN(HEVC_MAX_LONG_TERM_REF_PICS, 
FF_ARRAY_ELEMS(current->poc_lsb_lt) - current->num_long_term_sps));
 
 for (i = 0; i < current->num_long_term_sps +
 current->num_long_term_pics; i++) {
-- 
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 2/3] avcodec/iff: Check length before memcpy() in decode_deep_rle32()

2020-04-20 Thread Michael Niedermayer
Fixes: out of array read
Fixes: 
20796/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5111364702175232.fuzz

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

diff --git a/libavcodec/iff.c b/libavcodec/iff.c
index 2e65e266d0..23d19d8a25 100644
--- a/libavcodec/iff.c
+++ b/libavcodec/iff.c
@@ -722,6 +722,8 @@ static void decode_deep_rle32(uint8_t *dst, const uint8_t 
*src, int src_size, in
 int size = opcode + 1;
 for (i = 0; i < size; i++) {
 int length = FFMIN(size - i, width);
+if (src_end - src < length)
+return;
 memcpy(dst + y*linesize + x * 4, src, length * 4);
 src += length * 4;
 x += length;
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 1/3] avcodec/iff: Fix invalid pointer intermediates in decode_deep_rle32()

2020-04-20 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavcodec/iff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/iff.c b/libavcodec/iff.c
index acd6519b06..2e65e266d0 100644
--- a/libavcodec/iff.c
+++ b/libavcodec/iff.c
@@ -715,7 +715,7 @@ static void decode_deep_rle32(uint8_t *dst, const uint8_t 
*src, int src_size, in
 {
 const uint8_t *src_end = src + src_size;
 int x = 0, y = 0, i;
-while (src + 5 <= src_end) {
+while (src_end - src >= 5) {
 int opcode;
 opcode = *(int8_t *)src++;
 if (opcode >= 0) {
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 4/4] avcodec/cbs_h265: add missing support for reserved_payload_extension_data SEI bits

2020-04-20 Thread James Almer
Fixes ticket #8622

Signed-off-by: James Almer 
---
It fixes it assuming the Picture Timing in that sample is not being misparsed
by cbs_h265.
We're compliant with the latest revision of the spec, so any
reserved_payload_extension_data found in a sample created today is almost
guaranteed to be bogus. But the spec states that they should be skipped if
found, for forward compatibility reasons.
Would be worth checking if the nvenc encoder is at fault, writing faulty SEI
messages.

This patch could for that matter make many potential cases of undiscovered
cbs_h265 SEI misparsing be handled as if the remaining bits were these reserved
bits.

 libavcodec/cbs_h265.h |  1 +
 libavcodec/cbs_h265_syntax_template.c | 44 +--
 2 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index 2c1e153ad9..73897f77a4 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -715,6 +715,7 @@ typedef struct H265RawSEIPayload {
 AVBufferRef *data_ref;
 } other;
 } payload;
+H265RawExtensionData extension_data;
 } H265RawSEIPayload;
 
 typedef struct H265RawSEI {
diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index f978e16549..ef3254d27f 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -2054,11 +2054,43 @@ static int 
FUNC(sei_alpha_channel_info)(CodedBitstreamContext *ctx,
 return 0;
 }
 
+static int FUNC(payload_extension)(CodedBitstreamContext *ctx, RWContext *rw,
+   H265RawExtensionData *current, uint32_t 
payload_size,
+   int cur_pos)
+{
+int err, i;
+
+#ifdef READ
+if (cbs_h265_payload_extension_present(rw, payload_size, cur_pos)) {
+GetBitContext tmp = *rw;
+int payload_zero_bits, bits_left = 8 * payload_size - cur_pos;
+if (bits_left > 8)
+skip_bits_long(, bits_left - 8);
+payload_zero_bits = ff_ctz(get_bits(, FFMIN(bits_left, 8)));
+if (payload_zero_bits >= bits_left - 1)
+return AVERROR_INVALIDDATA;
+current->bit_length = bits_left - payload_zero_bits - 1;
+allocate(current->data, (current->bit_length + 7) / 8);
+for (i = 0; i < current->bit_length; i++) {
+uint8_t bit;
+xu(1, reserved_payload_extension_data, bit, 0, 1, 0);
+current->data[i / 8] |= bit << (7 - i % 8);
+}
+}
+#else
+for (i = 0; i < current->bit_length; i++)
+xu(1, reserved_payload_extension_data,
+   current->data[i / 8] >> (7 - i % 8) & 1, 0, 1, 0);
+#endif
+
+return 0;
+}
+
 static int FUNC(sei_payload)(CodedBitstreamContext *ctx, RWContext *rw,
  H265RawSEIPayload *current, int prefix)
 {
 int err, i;
-int start_position, end_position;
+int start_position, current_position, end_position;
 
 #ifdef READ
 start_position = get_bits_count(rw);
@@ -2122,7 +2154,15 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
RWContext *rw,
 }
 }
 
-if (byte_alignment(rw)) {
+#ifdef READ
+current_position = get_bits_count(rw) - start_position;
+if (current_position != 8 * current->payload_size) {
+#else
+current_position = put_bits_count(rw) - start_position;
+if (byte_alignment(rw) || current->extension_data.bit_length) {
+#endif
+CHECK(FUNC(payload_extension)(ctx, rw, >extension_data,
+  current->payload_size, 
current_position));
 fixed(1, bit_equal_to_one, 1);
 while (byte_alignment(rw))
 fixed(1, bit_equal_to_zero, 0);
-- 
2.26.0

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

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

[FFmpeg-devel] [PATCH 1/4] avcodec/cbs_h265: fix writing extension_data bits

2020-04-20 Thread James Almer
We only care about the right most bit.

Signed-off-by: James Almer 
---
Fixes handling files like
https://trac.ffmpeg.org/attachment/ticket/7965/puppets_with_alpha_hevc.mov
Without this patch, parsing works but passing the VPS through hevc_metadata_bsf
when writing fails.

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

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 180a045c34..85b952e64c 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -80,7 +80,7 @@ static int FUNC(extension_data)(CodedBitstreamContext *ctx, 
RWContext *rw,
 }
 #else
 for (k = 0; k < current->bit_length; k++)
-xu(1, extension_data, current->data[k / 8] >> (7 - k % 8), 0, 1, 0);
+xu(1, extension_data, current->data[k / 8] >> (7 - k % 8) & 1, 0, 1, 
0);
 #endif
 return 0;
 }
-- 
2.26.0

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

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

[FFmpeg-devel] [PATCH 3/4] avcodec/cbs_h265: move the payload_extension_present check into its own function

2020-04-20 Thread James Almer
Will be reused in the following patch.

Signed-off-by: James Almer 
---
 libavcodec/cbs_h2645.c| 9 +
 libavcodec/cbs_h265_syntax_template.c | 8 +++-
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index d42073cc5a..d862e2 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -233,6 +233,15 @@ static int cbs_write_se_golomb(CodedBitstreamContext *ctx, 
PutBitContext *pbc,
 return 0;
 }
 
+static int cbs_h265_payload_extension_present(GetBitContext *gbc, uint32_t 
payload_size,
+  int cur_pos)
+{
+int bits_left;
+bits_left = payload_size * 8 - cur_pos;
+return (bits_left > 0 &&
+(bits_left > 7 || ff_ctz(show_bits(gbc, bits_left)) < bits_left - 
1));
+}
+
 #define HEADER(name) do { \
 ff_cbs_trace_header(ctx, name); \
 } while (0)
diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index fe5ffac80f..f978e16549 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1568,7 +1568,7 @@ static int 
FUNC(sei_buffering_period)(CodedBitstreamContext *ctx, RWContext *rw,
 int err, i, length;
 
 #ifdef READ
-int start_pos, end_pos, bits_left;
+int start_pos;
 start_pos = get_bits_count(rw);
 #endif
 
@@ -1649,10 +1649,8 @@ static int 
FUNC(sei_buffering_period)(CodedBitstreamContext *ctx, RWContext *rw,
 #ifdef READ
 // payload_extension_present() - true if we are before the last 1-bit
 // in the payload structure, which must be in the last byte.
-end_pos = get_bits_count(rw);
-bits_left = *payload_size * 8 - (end_pos - start_pos);
-if (bits_left > 0 &&
-(bits_left > 7 || ff_ctz(show_bits(rw, bits_left)) < bits_left - 1))
+if (cbs_h265_payload_extension_present(rw, *payload_size,
+   get_bits_count(rw) - start_pos))
 flag(use_alt_cpb_params_flag);
 else
 infer(use_alt_cpb_params_flag, 0);
-- 
2.26.0

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

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

[FFmpeg-devel] [PATCH 2/4] avcodec/cbs_h265: rename H265RawPSExtensionData to H265RawExtensionData

2020-04-20 Thread James Almer
So that NAL types other than Parameter Set ones may use it.

Signed-off-by: James Almer 
---
 libavcodec/cbs_h265.h | 10 +-
 libavcodec/cbs_h265_syntax_template.c |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index ad746bf35f..2c1e153ad9 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -182,11 +182,11 @@ typedef struct H265RawVUI {
 uint8_t log2_max_mv_length_vertical;
 } H265RawVUI;
 
-typedef struct H265RawPSExtensionData {
+typedef struct H265RawExtensionData {
 uint8_t *data;
 size_t bit_length;
 AVBufferRef *data_ref;
-} H265RawPSExtensionData;
+} H265RawExtensionData;
 
 typedef struct H265RawVPS {
 H265RawNALUnitHeader nal_unit_header;
@@ -221,7 +221,7 @@ typedef struct H265RawVPS {
 H265RawHRDParameters hrd_parameters[HEVC_MAX_LAYER_SETS];
 
 uint8_t vps_extension_flag;
-H265RawPSExtensionData extension_data;
+H265RawExtensionData extension_data;
 } H265RawVPS;
 
 typedef struct H265RawSTRefPicSet {
@@ -325,7 +325,7 @@ typedef struct H265RawSPS {
 uint8_t sps_scc_extension_flag;
 uint8_t sps_extension_4bits;
 
-H265RawPSExtensionData extension_data;
+H265RawExtensionData extension_data;
 
 // Range extension.
 uint8_t transform_skip_rotation_enabled_flag;
@@ -413,7 +413,7 @@ typedef struct H265RawPPS {
 uint8_t pps_scc_extension_flag;
 uint8_t pps_extension_4bits;
 
-H265RawPSExtensionData extension_data;
+H265RawExtensionData extension_data;
 
 // Range extension.
 uint8_t log2_max_transform_skip_block_size_minus2;
diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 85b952e64c..fe5ffac80f 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -59,7 +59,7 @@ static int FUNC(byte_alignment)(CodedBitstreamContext *ctx, 
RWContext *rw)
 }
 
 static int FUNC(extension_data)(CodedBitstreamContext *ctx, RWContext *rw,
-H265RawPSExtensionData *current)
+H265RawExtensionData *current)
 {
 int err;
 size_t k;
-- 
2.26.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 2/2] libavcodec/jpeg2000dec.c: ROI marker support

2020-04-20 Thread Carl Eugen Hoyos
Am Mo., 20. Apr. 2020 um 21:38 Uhr schrieb :
>
> From: Gautam Ramakrishnan 
>
> This patch adds support for decoding images
> with a Region of Interest. Allows decoding
> samples such as p0_03.j2k. This patch should
> fix ticket #4681.

The following inlined poc makes FFmpeg's output for this
sample bit-exact with kdu_render and opj_decompress.

jasper's output file looks ugly.

Carl Eugen

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index af6dcee228..5380596c04 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1921,7 +1921,9 @@ static inline void tile_codeblocks
 int val = lrintf(*datap) + (1 << (cbps - 1));
\
 /* DC level shift and clip see ISO
15444-1:2002 G.1.2 */  \
 val  = av_clip(val, 0, (1 << cbps) - 1);
\
-*dst = val << (precision - cbps);
\
+*dst = val << ((precision < 8 ? 8 :
precision) - cbps);   \
+if (precision < 8) \
+*dst |= *dst >> (8 - precision); \
 datap++;
\
 dst += pixelsize;
\
 }
\
@@ -1930,7 +1932,9 @@ static inline void tile_codeblocks
 int val = *i_datap + (1 << (cbps - 1));
\
 /* DC level shift and clip see ISO
15444-1:2002 G.1.2 */  \
 val  = av_clip(val, 0, (1 << cbps) - 1);
\
-*dst = val << (precision - cbps);
\
+*dst = val << ((precision < 8 ? 8 :
precision) - cbps);   \
+if (precision < 8) \
+*dst |= *dst >> (8 - precision); \
 i_datap++;
\
 dst += pixelsize;
\
 }
\
@@ -1972,7 +1976,7 @@ static int jpeg2000_decode_tile
 }

 if (s->precision <= 8) {
-write_frame_8(s, tile, picture, 8);
+write_frame_8(s, tile, picture, s->precision);
 } else {
 int precision = picture->format == AV_PIX_FMT_XYZ12 ||
 picture->format == AV_PIX_FMT_RGB48 ||
___
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] libavcodec/jpeg2000dec.c: Support for CRG marker

2020-04-20 Thread Gautam Ramakrishnan
On Tue, Apr 21, 2020 at 1:12 AM Carl Eugen Hoyos  wrote:
>
> Am Mo., 20. Apr. 2020 um 21:38 Uhr schrieb :
> >
> > From: Gautam Ramakrishnan 
> >
> > This patch adds support for CRG marker. Allows
> > samples such as p0_03.j2k to be decoded.
>
> The patch indicates to me that it adds support for
> skipping the CRG marker: Am I wrong?
>
Yep, that's correct. I guess I just used a standard phrase
to word the patch message. The CRG marker does nothing.
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



-- 
-
Gautam |
___
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] libavcodec/jpeg2000dec.c: Support for CRG marker

2020-04-20 Thread Carl Eugen Hoyos
Am Mo., 20. Apr. 2020 um 21:38 Uhr schrieb :
>
> From: Gautam Ramakrishnan 
>
> This patch adds support for CRG marker. Allows
> samples such as p0_03.j2k to be decoded.

The patch indicates to me that it adds support for
skipping the CRG marker: Am I wrong?

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

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

[FFmpeg-devel] [PATCH 1/2] libavcodec/jpeg2000dec.c: Support for CRG marker

2020-04-20 Thread gautamramk
From: Gautam Ramakrishnan 

This patch adds support for CRG marker. Allows
samples such as p0_03.j2k to be decoded.
---
 libavcodec/jpeg2000dec.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index af6dcee228..5a7d9e7882 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -798,6 +798,15 @@ static int get_sot(Jpeg2000DecoderContext *s, int n)
 return 0;
 }
 
+static int read_crg(Jpeg2000DecoderContext *s, int n)
+{
+if (s->ncomponents*4 != n - 2) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid CRG marker.\n");
+return AVERROR_INVALIDDATA;
+}
+bytestream2_skip(>g, n - 2);
+return 0;
+}
 /* Tile-part lengths: see ISO 15444-1:2002, section A.7.1
  * Used to know the number of tile parts and lengths.
  * There may be multiple TLMs in the header.
@@ -2061,6 +2070,9 @@ static int 
jpeg2000_read_main_headers(Jpeg2000DecoderContext *s)
 // the comment is ignored
 bytestream2_skip(>g, len - 2);
 break;
+case JPEG2000_CRG:
+ret = read_crg(s, len);
+break;
 case JPEG2000_TLM:
 // Tile-part lengths
 ret = get_tlm(s, len);
-- 
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 2/2] libavcodec/jpeg2000dec.c: ROI marker support

2020-04-20 Thread gautamramk
From: Gautam Ramakrishnan 

This patch adds support for decoding images
with a Region of Interest. Allows decoding
samples such as p0_03.j2k. This patch should
fix ticket #4681.
---
 libavcodec/jpeg2000.h|  1 +
 libavcodec/jpeg2000dec.c | 57 +++-
 2 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index 7b78c0193e..0f82716981 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -210,6 +210,7 @@ typedef struct Jpeg2000Component {
 int *i_data;
 int coord[2][2];   // border coordinates {{x0, x1}, {y0, y1}} -- can be 
reduced with lowres option
 int coord_o[2][2]; // border coordinates {{x0, x1}, {y0, y1}} -- original 
values from jpeg2000 headers
+uint8_t roi_shift; // ROI scaling value for the component
 } Jpeg2000Component;
 
 /* misc tools */
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5a7d9e7882..da19345ee7 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -117,6 +117,7 @@ typedef struct Jpeg2000DecoderContext {
 Jpeg2000CodingStyle codsty[4];
 Jpeg2000QuantStyle  qntsty[4];
 Jpeg2000POC poc;
+uint8_t roi_shift[4];
 
 int bit_index;
 
@@ -598,6 +599,29 @@ static int get_coc(Jpeg2000DecoderContext *s, 
Jpeg2000CodingStyle *c,
 return 0;
 }
 
+static int get_rgn(Jpeg2000DecoderContext *s, int n)
+{
+uint16_t compno;
+compno = (s->ncomponents < 257)? bytestream2_get_byte(>g):
+ bytestream2_get_be16u(>g);
+if (bytestream2_get_byte(>g)) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid RGN header.\n");
+return AVERROR_INVALIDDATA; // SRgn field value is 0
+}
+// SPrgn field
+if (compno < s->ncomponents) {
+if (s->curtileno == -1)
+s->roi_shift[compno] = bytestream2_get_byte(>g);
+else {
+if (s->tile[s->curtileno].tp_idx != 0)
+return AVERROR_INVALIDDATA; // marker occurs only in first 
tile part of tile
+s->tile[s->curtileno].comp[compno].roi_shift = 
bytestream2_get_byte(>g);
+}
+return 0;
+}
+return AVERROR_INVALIDDATA;
+}
+
 /* Get common part for QCD and QCC segments. */
 static int get_qcx(Jpeg2000DecoderContext *s, int n, Jpeg2000QuantStyle *q)
 {
@@ -947,6 +971,9 @@ static int init_tile(Jpeg2000DecoderContext *s, int tileno)
 comp->coord[1][0] = ff_jpeg2000_ceildivpow2(comp->coord_o[1][0], 
s->reduction_factor);
 comp->coord[1][1] = ff_jpeg2000_ceildivpow2(comp->coord_o[1][1], 
s->reduction_factor);
 
+if (!comp->roi_shift)
+comp->roi_shift = s->roi_shift[compno];
+
 if (ret = ff_jpeg2000_init_component(comp, codsty, qntsty,
  s->cbps[compno], s->cdx[compno],
  s->cdy[compno], s->avctx))
@@ -1615,9 +1642,9 @@ static void decode_clnpass(Jpeg2000DecoderContext *s, 
Jpeg2000T1Context *t1,
 
 static int decode_cblk(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *codsty,
Jpeg2000T1Context *t1, Jpeg2000Cblk *cblk,
-   int width, int height, int bandpos)
+   int width, int height, int bandpos, uint8_t roi_shift)
 {
-int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits - 1;
+int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits - 1 + 
roi_shift;
 int pass_cnt = 0;
 int vert_causal_ctx_csty_symbol = codsty->cblk_style & JPEG2000_CBLK_VSC;
 int term_cnt = 0;
@@ -1691,6 +1718,19 @@ static int decode_cblk(Jpeg2000DecoderContext *s, 
Jpeg2000CodingStyle *codsty,
 return 1;
 }
 
+static inline int roi_shift_param(Jpeg2000Component *comp,
+   int quan_parameter)
+{
+uint8_t roi_shift;
+int val;
+roi_shift = comp->roi_shift;
+val = (quan_parameter < 0)?-quan_parameter:quan_parameter;
+
+if (val > (1 << roi_shift))
+return (quan_parameter < 0)?-(val >> roi_shift):(val >> roi_shift);
+return quan_parameter;
+}
+
 /* TODO: Verify dequantization for lossless case
  * comp->data can be float or int
  * band->stepsize can be float or int
@@ -1708,7 +1748,7 @@ static void dequantization_float(int x, int y, 
Jpeg2000Cblk *cblk,
 float *datap = >f_data[(comp->coord[0][1] - comp->coord[0][0]) * 
(y + j) + x];
 int *src = t1->data + j*t1->stride;
 for (i = 0; i < w; ++i)
-datap[i] = src[i] * band->f_stepsize;
+datap[i] = roi_shift_param(comp, src[i]) * band->f_stepsize;
 }
 }
 
@@ -1724,11 +1764,11 @@ static void dequantization_int(int x, int y, 
Jpeg2000Cblk *cblk,
 int *src = t1->data + j*t1->stride;
 if (band->i_stepsize == 32768) {
 for (i = 0; i < w; ++i)
-datap[i] = src[i] / 2;
+datap[i] = roi_shift_param(comp, src[i]) / 2;
 

Re: [FFmpeg-devel] [PATCH] gas-preprocessor: Fix use of Visual Studio compiler values -w... or -FS

2020-04-20 Thread Martin Storsjö

On Mon, 20 Apr 2020, Martin Storsjö wrote:


On Mon, 20 Apr 2020, phunkyfish wrote:


From: Alwin Esch 

---
gas-preprocessor.pl | 4 
1 file changed, 4 insertions(+)

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 860b97c..126ee50 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -164,6 +164,8 @@ if ($as_type ne "armasm") {
@preprocess_c_cmd = grep ! /^-EHsc$/, @preprocess_c_cmd;
@preprocess_c_cmd = grep ! /^-O/, @preprocess_c_cmd;
@preprocess_c_cmd = grep ! /^-oldit/, @preprocess_c_cmd;
+@preprocess_c_cmd = grep ! /^-FS/, @preprocess_c_cmd;
+@preprocess_c_cmd = grep ! /^-w/, @preprocess_c_cmd;

@gcc_cmd = grep ! /^-G/, @gcc_cmd;
@gcc_cmd = grep ! /^-W/, @gcc_cmd;
@@ -171,6 +173,8 @@ if ($as_type ne "armasm") {
@gcc_cmd = grep ! /^-fp/, @gcc_cmd;
@gcc_cmd = grep ! /^-EHsc$/, @gcc_cmd;
@gcc_cmd = grep ! /^-O/, @gcc_cmd;
+@gcc_cmd = grep ! /^-FS/, @gcc_cmd;
+@gcc_cmd = grep ! /^-w/, @gcc_cmd;

my @outfiles = grep /\.(o|obj)$/, @gcc_cmd;
$tempfile = $outfiles[0].".asm";
--
2.24.2 (Apple Git-127)


Ok with me - will push a bit later.


Pushed.

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: Pass ret from decode_iccp_chunk()

2020-04-20 Thread Michael Niedermayer
On Mon, Apr 20, 2020 at 03:04:35PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-04-18 01:48:47)
> > Found while reviewing a patch fixing a similar issue
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> 
> Looks ok

will apply

thx

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/adpcm_ima_{apc, ssi, oki}: replace while() with for()

2020-04-20 Thread Michael Niedermayer
On Sat, Apr 18, 2020 at 12:59:25AM +, Zane van Iperen wrote:
> Per discussion at 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260854.html
> 
> Signed-off-by: Zane van Iperen 
> ---
>  libavcodec/adpcm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

will apply

thx

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

You can kill me, but you cannot change the truth.


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

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

[FFmpeg-devel] [PATCH 2/3] avformat/movenc: Use base container timescale, instead of hard coded default

2020-04-20 Thread Kevin Wheatley
Signed-off-by: Kevin Wheatley 
---
 libavformat/movenc.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7d79eca..508fa73 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2879,7 +2879,7 @@ static int mov_write_tkhd_tag(AVIOContext *pb, 
MOVMuxContext *mov,
   MOVTrack *track, AVStream *st)
 {
 int64_t duration = av_rescale_rnd(calc_pts_duration(mov, track),
-  MOV_TIMESCALE, track->timescale,
+  mov->mov_timescale, track->timescale,
   AV_ROUND_UP);
 int version = duration < INT32_MAX ? 0 : 1;
 int flags   = MOV_TKHD_FLAG_IN_MOVIE;
@@ -3027,7 +3027,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
MOVMuxContext *mov,
   MOVTrack *track)
 {
 int64_t duration = av_rescale_rnd(calc_pts_duration(mov, track),
-  MOV_TIMESCALE, track->timescale,
+  mov->mov_timescale, track->timescale,
   AV_ROUND_UP);
 int version = duration < INT32_MAX ? 0 : 1;
 int entry_size, entry_count, size;
@@ -3046,7 +3046,7 @@ static int mov_write_edts_tag(AVIOContext *pb, 
MOVMuxContext *mov,
 }
 }
 
-delay = av_rescale_rnd(start_dts + start_ct, MOV_TIMESCALE,
+delay = av_rescale_rnd(start_dts + start_ct, mov->mov_timescale,
track->timescale, AV_ROUND_DOWN);
 version |= delay < INT32_MAX ? 0 : 1;
 
@@ -3081,8 +3081,8 @@ static int mov_write_edts_tag(AVIOContext *pb, 
MOVMuxContext *mov,
 /* Avoid accidentally ending up with start_ct = -1 which has got a
  * special meaning. Normally start_ct should end up positive or zero
  * here, but use FFMIN in case dts is a small positive integer
- * rounded to 0 when represented in MOV_TIMESCALE units. */
-av_assert0(av_rescale_rnd(start_dts, MOV_TIMESCALE, track->timescale, 
AV_ROUND_DOWN) <= 0);
+ * rounded to 0 when represented in mov->mov_timescale units. */
+av_assert0(av_rescale_rnd(start_dts, mov->mov_timescale, 
track->timescale, AV_ROUND_DOWN) <= 0);
 start_ct  = -FFMIN(start_dts, 0);
 /* Note, this delay is calculated from the pts of the first sample,
  * ensuring that we don't reduce the duration for cases with
@@ -3316,7 +3316,7 @@ static int mov_write_mvhd_tag(AVIOContext *pb, 
MOVMuxContext *mov)
 if (mov->tracks[i].entry > 0 && mov->tracks[i].timescale) {
 int64_t max_track_len_temp = av_rescale_rnd(
 calc_pts_duration(mov, 
>tracks[i]),
-MOV_TIMESCALE,
+mov->mov_timescale,
 mov->tracks[i].timescale,
 AV_ROUND_UP);
 if (max_track_len < max_track_len_temp)
@@ -3345,7 +3345,7 @@ static int mov_write_mvhd_tag(AVIOContext *pb, 
MOVMuxContext *mov)
 avio_wb32(pb, mov->time); /* creation time */
 avio_wb32(pb, mov->time); /* modification time */
 }
-avio_wb32(pb, MOV_TIMESCALE);
+avio_wb32(pb, mov->mov_timescale);
 (version == 1) ? avio_wb64(pb, max_track_len) : avio_wb32(pb, 
max_track_len); /* duration of longest track */
 
 avio_wb32(pb, 0x0001); /* reserved (preferred rate) 1.0 = normal */
@@ -5921,7 +5921,7 @@ static int mov_create_chapter_track(AVFormatContext *s, 
int tracknum)
 
 track->mode = mov->mode;
 track->tag = MKTAG('t','e','x','t');
-track->timescale = MOV_TIMESCALE;
+track->timescale = mov->mov_timescale;
 track->par = avcodec_parameters_alloc();
 if (!track->par)
 return AVERROR(ENOMEM);
@@ -5982,8 +5982,8 @@ static int mov_create_chapter_track(AVFormatContext *s, 
int tracknum)
 AVChapter *c = s->chapters[i];
 AVDictionaryEntry *t;
 
-int64_t end = av_rescale_q(c->end, c->time_base, 
(AVRational){1,MOV_TIMESCALE});
-pkt.pts = pkt.dts = av_rescale_q(c->start, c->time_base, 
(AVRational){1,MOV_TIMESCALE});
+int64_t end = av_rescale_q(c->end, c->time_base, 
(AVRational){1,mov->mov_timescale});
+pkt.pts = pkt.dts = av_rescale_q(c->start, c->time_base, 
(AVRational){1,mov->mov_timescale});
 pkt.duration = end - pkt.dts;
 
 if ((t = av_dict_get(c->metadata, "title", NULL, 0))) {
@@ -6518,7 +6518,7 @@ static int mov_init(AVFormatContext *s)
 } else if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA) {
 track->timescale = st->time_base.den;
 } else {
-track->timescale = MOV_TIMESCALE;
+track->timescale = mov->mov_timescale;
 }
 if (!track->height)
 track->height = 

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/adpcm: update get_nb_samples() doc

2020-04-20 Thread Michael Niedermayer
On Sat, Apr 18, 2020 at 12:59:33AM +, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen 
> ---
>  libavcodec/adpcm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

thx

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

You can kill me, but you cannot change the truth.


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

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

[FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add an automatic timescale computation

2020-04-20 Thread Kevin Wheatley
Activated when the -mov_timescale command line/MOVMuxContext
parameter is set to 0 or less. If the user passes any value
greater than 0, then it will be used as-is. The default
value is kept unchanged at 1000.

When active, it uses the base assumption from the QuickTime
specification of 600 and combines the video stream time
bases to compute an accurate answer if possible.

In cases when the first stream result falls outside
MOV_MAX_AUTO_TIMESCALE or if a non-integer video stream is
encounted, then the first stream's time_base will be used as the
base.

Signed-off-by: Kevin Wheatley 
---
 libavformat/movenc.c | 71 
 libavformat/movenc.h |  1 +
 2 files changed, 72 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 508fa73..8edb848 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6208,6 +6208,70 @@ static int 
mov_create_dvd_sub_decoder_specific_info(MOVTrack *track,
 return 0;
 }
 
+static int mov_determine_movie_timescale(AVFormatContext *s, MOVMuxContext 
*mov)
+{
+// Assume typical integer frame rates:
+// 600 is a common multiple of 24, 25, 30, 50, 60, etc.
+// see p221, https://developer.apple.com/standards/qtff-2001.pdf
+int timescale = 600;
+AVRational temp;
+int exact;
+int first_video_track = 1;
+
+// If the user specified a timescale, just use it as-is
+if (mov->mov_timescale > 0) {
+return mov->mov_timescale;
+}
+
+// Determine the timescale, based on the video stream time_base values
+for (int i = 0; i < s->nb_streams; i++) {
+AVStream *st = s->streams[i];
+if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
+
+// If the first video track is not an integer, use its denominator
+// as the basis of the remaining calculations
+if (first_video_track && st->time_base.num != 1) {
+timescale = st->time_base.den;
+av_log(s, AV_LOG_VERBOSE, "Using first video stream 
non-integer time_base: %d/%d\n",
+   st->time_base.den, st->time_base.num);
+}
+
+// determine if we can make an even multiple of the current 
timescale and the video track
+av_log(s, AV_LOG_VERBOSE, "Current estimated timescale: %d\n", 
timescale);
+av_log(s, AV_LOG_TRACE, "Stream #%d time_base: %d/%d\n", i,
+   st->time_base.num, st->time_base.den);
+
+// Try keep the time_scale within a sensible bound
+exact = av_reduce(, ,
+  (int64_t)timescale * st->time_base.num,
+  st->time_base.den,
+  MOV_MAX_AUTO_TIMESCALE);
+
+// Use a scaled version of the timescale
+if (exact) {
+timescale *= temp.den;
+av_log(s, AV_LOG_TRACE, "Adjusted timescale: %d/%d %d\n",
+   temp.den, temp.num, timescale);
+} else {
+// We overflowed try the denominator as is
+timescale = temp.den;
+av_log(s, AV_LOG_WARNING, "Timescale calculation out of bounds 
approximating %d/%d %d\n",
+   temp.den, temp.num, timescale);
+}
+
+if (first_video_track && ((timescale > MOV_MAX_AUTO_TIMESCALE) || 
!exact)) {
+timescale = st->time_base.den;
+av_log(s, AV_LOG_WARNING, "Potentially large timescale, "
+  "using first video stream time_base: 
%d/%d\n",
+   st->time_base.den, st->time_base.num);
+}
+first_video_track = 0;
+}
+}
+av_log(s, AV_LOG_VERBOSE, "Final timescale: %d\n", timescale);
+return timescale;
+}
+
 static int mov_init(AVFormatContext *s)
 {
 MOVMuxContext *mov = s->priv_data;
@@ -6266,6 +6330,13 @@ static int mov_init(AVFormatContext *s)
 mov->reserved_moov_size = -1;
 }
 
+mov->mov_timescale = mov_determine_movie_timescale(s, mov);
+if (mov->mov_timescale > MOV_MAX_AUTO_TIMESCALE) {
+av_log(s, AV_LOG_WARNING, "Potentially large timescale %d, use "
+  "-mov_timescale if you have issues\n",
+  mov->mov_timescale);
+}
+
 if (mov->use_editlist < 0) {
 mov->use_editlist = 1;
 if (mov->flags & FF_MOV_FLAG_FRAGMENT &&
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 322968c..4d6b7b7 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -30,6 +30,7 @@
 #define MOV_FRAG_INFO_ALLOC_INCREMENT 64
 #define MOV_INDEX_CLUSTER_SIZE 1024
 #define MOV_TIMESCALE 1000
+#define MOV_MAX_AUTO_TIMESCALE 1
 
 #define RTP_MAX_PACKET_SIZE 1450
 
-- 
1.8.5.6

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

To 

[FFmpeg-devel] [PATCH v3 0/3] avformat/movenc: Support for variable timescale in mov containers

2020-04-20 Thread Kevin Wheatley
v3 - rebased to current master

This set of patches work together to facilitate user specified timescales for
the Movie Header Atom 'mvhd', which allows constant sample table durations for
all frame rates.

Currently there is a fixed timescale of 1000, which is not an even multiple of
all the typical video frame/field rates. This means when performing certain
duration based operations it is possible to be inaccurate.

The default behaviour is left at the current default defined by MOV_TIMESCALE,
but can be over ridden by using the -mov_timescale  option.

Typical values of 600 would work for 24, 25 and 30 FPS, for 23.976 and other
fractional rates could use 2997 same as Avid (or 24000 though caution
should be used when encoding long durations).

An automatic mode has been added if a negative value is passed to the option.
This will compute an appropriate time scale starting from the lowest numbered
video stream's time scale.


Example usage that has better behaviour than the current:

# Encode 50 frames at 24FPS and concatenate 5 copies
ffmpeg -f lavfi -i smptebars=duration=2.08:size=1920x1080:rate=24 \
-codec dnxhd -pix_fmt yuv422p -b:v 115M smptebars_dnx_1000.mov
cat < concat_1000.txt
file smptebars_dnx_1000.mov
file smptebars_dnx_1000.mov
file smptebars_dnx_1000.mov
file smptebars_dnx_1000.mov
file smptebars_dnx_1000.mov
EOF
ffmpeg -f concat -i concat_1000.txt -c copy smpte_concat_1000.mov
ffprobe smpte_concat_1000.mov

The output of ffprobe will show a frame rate of 23.99 due to the effect of ther
sample durations in the stts entries.

With the new option of -mov_timescale set to 600:

ffmpeg -f lavfi -i smptebars=duration=2.08:size=1920x1080:rate=24 \
-codec dnxhd -pix_fmt yuv422p -b:v 115M -mov_timescale 600 smptebars_dnx_600.mov
cat < concat_600.txt
file smptebars_dnx_600.mov
file smptebars_dnx_600.mov
file smptebars_dnx_600.mov
file smptebars_dnx_600.mov
file smptebars_dnx_600.mov
EOF
ffmpeg -f concat -i concat_600.txt -c copy -mov_timescale 600 
smpte_concat_600.mov
ffprobe smpte_concat_600.mov

The durations all line up, the stts table is smaller and no rounding issues 
occur.

Kevin

Kevin Wheatley (3):
  avformat/movenc: Add command line option to set base mov file
timescale
  avformat/movenc: Use base container timescale, instead of hard coded
default
  avformat/movenc: Add an automatic timescale computation

 libavformat/movenc.c | 94 ++--
 libavformat/movenc.h |  2 ++
 2 files changed, 85 insertions(+), 11 deletions(-)

-- 
1.8.5.6

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

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

[FFmpeg-devel] [PATCH 1/3] avformat/movenc: Add command line option to set base mov file timescale

2020-04-20 Thread Kevin Wheatley
Signed-off-by: Kevin Wheatley 
---
 libavformat/movenc.c | 1 +
 libavformat/movenc.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 253cff8..7d79eca 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -91,6 +91,7 @@ static const AVOption options[] = {
 { "min_frag_duration", "Minimum fragment duration", 
offsetof(MOVMuxContext, min_fragment_duration), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
 { "frag_size", "Maximum fragment size", offsetof(MOVMuxContext, 
max_fragment_size), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM},
 { "ism_lookahead", "Number of lookahead entries for ISM files", 
offsetof(MOVMuxContext, ism_lookahead), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
+{ "mov_timescale", "set timescale of mov container", 
offsetof(MOVMuxContext, mov_timescale), AV_OPT_TYPE_INT, {.i64 = 
MOV_TIMESCALE}, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
 { "video_track_timescale", "set timescale of all video tracks", 
offsetof(MOVMuxContext, video_track_timescale), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
 { "brand","Override major brand", offsetof(MOVMuxContext, 
major_brand),   AV_OPT_TYPE_STRING, {.str = NULL}, .flags = 
AV_OPT_FLAG_ENCODING_PARAM },
 { "use_editlist", "use edit list", offsetof(MOVMuxContext, use_editlist), 
AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, AV_OPT_FLAG_ENCODING_PARAM},
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 997b2d6..322968c 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -205,6 +205,7 @@ typedef struct MOVMuxContext {
 AVIOContext *mdat_buf;
 int first_trun;
 
+int mov_timescale;
 int video_track_timescale;
 
 int reserved_moov_size; ///< 0 for disabled, -1 for automatic, size 
otherwise
-- 
1.8.5.6

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

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

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

2020-04-20 Thread Marton Balint



On Thu, 16 Apr 2020, Carl Eugen Hoyos wrote:


Am Mo., 13. Apr. 2020 um 02:17 Uhr schrieb Marton Balint :




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

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

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


I think there is enough room for "Support for muxing pcm and pgs in m2ts"


Ok, will apply soon the series with that line in the changelog.

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

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

[FFmpeg-devel] [PATCH] avformat/mpegtsenc: don't print warning for DVB text streams

2020-04-20 Thread Gyan Doshi
They can be demuxed by ffmpeg.
---
 libavformat/mpegtsenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index ccb631d746..3818001976 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -381,6 +381,10 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 case AV_CODEC_ID_TIMED_ID3:
 stream_type = STREAM_TYPE_METADATA;
 break;
+case AV_CODEC_ID_DVB_SUBTITLE:
+case AV_CODEC_ID_DVB_TELETEXT:
+stream_type = STREAM_TYPE_PRIVATE_DATA;
+break;
 default:
 av_log(s, AV_LOG_WARNING, "Stream %d, codec %s, is muxed as a 
private data stream "
"and may not be recognized upon reading.\n", i, 
avcodec_get_name(st->codecpar->codec_id));
-- 
2.26.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] lavf/tls_gnutls: check for interrupt inside handshake loop

2020-04-20 Thread Jan Ekström
On Thu, Sep 5, 2019 at 6:13 PM Michael Niedermayer
 wrote:
>
> On Fri, Aug 16, 2019 at 10:38:46AM +0200, Błażej Szczygieł wrote:
> > fixes #8080
> >
> > Signed-off-by: Błażej Szczygieł 
> > ---
> >  libavformat/tls_gnutls.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
> > index f32bc2821b..f507b7d044 100644
> > --- a/libavformat/tls_gnutls.c
> > +++ b/libavformat/tls_gnutls.c
> > @@ -184,6 +184,10 @@ static int tls_open(URLContext *h, const char *uri, 
> > int flags, AVDictionary **op
> >  gnutls_priority_set_direct(p->session, "NORMAL", NULL);
> >  do {
> >  ret = gnutls_handshake(p->session);
> > +if (ff_check_interrupt(>interrupt_callback)) {
> > +ret = AVERROR_EXIT;
> > +goto fail;
> > +}
> >  if (gnutls_error_is_fatal(ret)) {
> >  ret = print_tls_error(h, ret);
> >  goto fail;
>
> probably ok
>
> Thanks
>

I've been meaning to look at this (and apply if it looks good), and
while the other TLS wrappers don't seem to have this (I guess their
handshake doesn't base on a loop?), it seems to almost match examples
found in f.ex. libavformat/network.c, libavformat/libzmq.c or
libavformat/libsrt.c.

The only point I notice is that usually the interrupt check is the
first thing done a loop, and unless people see any issues with it, I
will apply this patch with that change during today or so?

Best regards,
Jan
___
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] libavcodec/dnxhddata.c: Fix quantization weights for id 1271

2020-04-20 Thread Neil Birkbeck
From the ST 2019-1:2016 standard,
https://ieeexplore.ieee.org/abstract/document/7513364
in Table D.1, compression ID 1235, 1271 use the same weights.

This fixes what looks like a slight sharpening when decoding
samples encoded as DNxHR HQX 10- or 12-bit from other encoders
(e.g., like from DaVinci Resolve).

Signed-off-by: Neil Birkbeck 
---
 libavcodec/dnxhddata.c | 10 +-
 tests/ref/fate/dnxhr-12bit |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 154be89860..73260eadba 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -25,7 +25,7 @@
 
 /* The quantization tables below are in zigzag order! */
 
-/* Used in CID 1235, 1256, 1270 */
+/* Used in CID 1235, 1256, 1270, 1271 */
 static const uint8_t dnxhd_1235_luma_weight[] = {
  0, 32, 32, 32, 33, 32, 32, 32,
 32, 31, 32, 33, 33, 33, 33, 35,
@@ -37,7 +37,7 @@ static const uint8_t dnxhd_1235_luma_weight[] = {
 50, 50, 53, 55, 55, 56, 60, 60,
 };
 
-/* Used in CID 1235, 1256 */
+/* Used in CID 1235, 1256, 1271 */
 static const uint8_t dnxhd_1235_chroma_weight[] = {
  0, 32, 33, 34, 34, 33, 34, 35,
 37, 40, 43, 42, 39, 38, 39, 41,
@@ -97,7 +97,7 @@ static const uint8_t dnxhd_1238_chroma_weight[] = {
 82, 77, 80, 86, 84, 82, 82, 82,
 };
 
-/* Used in CID 1241, 1271 */
+/* Used in CID 1241 */
 static const uint8_t dnxhd_1241_luma_weight[] = {
  0, 32, 33, 34, 34, 35, 36, 37,
 36, 37, 38, 38, 38, 39, 39, 40,
@@ -109,7 +109,7 @@ static const uint8_t dnxhd_1241_luma_weight[] = {
 48, 46, 47, 48, 48, 49, 49, 49,
 };
 
-/* Used in CID 1241, 1271 */
+/* Used in CID 1241 */
 static const uint8_t dnxhd_1241_chroma_weight[] = {
  0, 32, 36, 38, 37, 37, 40, 41,
 40, 40, 42, 42, 41, 41, 41, 41,
@@ -1047,7 +1047,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 0 }, { 57344, 255} },
 { 1271, DNXHD_VARIABLE, DNXHD_VARIABLE, DNXHD_VARIABLE, DNXHD_VARIABLE,
   0, 6, DNXHD_VARIABLE, 4,
-  dnxhd_1241_luma_weight, dnxhd_1241_chroma_weight,
+  dnxhd_1235_luma_weight, dnxhd_1235_chroma_weight,
   dnxhd_1235_dc_codes, dnxhd_1235_dc_bits,
   dnxhd_1235_ac_codes, dnxhd_1235_ac_bits, dnxhd_1235_ac_info,
   dnxhd_1235_run_codes, dnxhd_1235_run_bits, dnxhd_1235_run,
diff --git a/tests/ref/fate/dnxhr-12bit b/tests/ref/fate/dnxhr-12bit
index eb5716780c..c6e8fd99ae 100644
--- a/tests/ref/fate/dnxhr-12bit
+++ b/tests/ref/fate/dnxhr-12bit
@@ -3,4 +3,4 @@
 #codec_id 0: rawvideo
 #dimensions 0: 1920x1080
 #sar 0: 1/1
-0,  0,  0,1,  8294400, 0x31bfa8f1
+0,  0,  0,1,  8294400, 0xbe1dc546
-- 
2.26.1.301.g55bc3eb7cb9-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 2/2] fate/truehd: add a test for the truehd_core bitstream filter

2020-04-20 Thread James Almer
On 4/19/2020 4:01 PM, James Almer wrote:
> On 4/19/2020 2:57 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 4/19/2020 2:45 PM, Andreas Rheinhardt wrote:
 James Almer:
> Signed-off-by: James Almer 
> ---
>  tests/fate/truehd.mak | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/tests/fate/truehd.mak b/tests/fate/truehd.mak
> index 6c8b1220f1..e672716527 100644
> --- a/tests/fate/truehd.mak
> +++ b/tests/fate/truehd.mak
> @@ -8,5 +8,10 @@ fate-truehd-5.1-downmix-2.0: CMD = md5pipe -f truehd 
> -request_channel_layout 2 -
>  fate-truehd-5.1-downmix-2.0: CMP = oneline
>  fate-truehd-5.1-downmix-2.0: REF = a269aee0051d4400c9117136f08c9767
>  
> +FATE_TRUEHD-$(call ALLYES, TRUEHD_DEMUXER TRUEHD_MUXER TRUEHD_CORE_BSF) 
> += fate-truehd-core-bsf
> +fate-truehd-core-bsf: CMD = md5pipe -i 
> $(TARGET_SAMPLES)/truehd/atmos.thd -c:a copy -bsf:a truehd_core -fflags 
> +bitexact -f truehd
> +fate-truehd-core-bsf: CMP = oneline
> +fate-truehd-core-bsf: REF = 3aa5d0c7825051f3657b71fd6135183b
> +
>  FATE_SAMPLES_AUDIO += $(FATE_TRUEHD-yes)
>  fate-truehd: $(FATE_TRUEHD-yes)
>
 Sure about the requirements? The truehd demuxer uses
 ff_raw_read_packet_partial() to read packets, so I expected to see the
 parser among the requirements.
>>>
>>> Sure, i can add it. But it may be more correct to add the parser
>>> dependency to the demuxer in configure instead, like the DTS ones do.
>>
>> Yeah, that makes sense.
> 
> Done. Will push this test later if there are no objections.

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] [PATCH] avformat/oggenc: Don't free AVStream's priv_data, fix memleak

2020-04-20 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> For FLAC, Speed, Opus and VP8 the Ogg muxer allocates two buffers
>> for building the headers: The first for extradata in an Ogg-specific
>> format and the second contains a Vorbiscomment. These buffers are
>> reachable via pointers in the corresponding AVStream's priv_data.
>>
>> If an error happens during building the headers, the AVStream's
>> priv_data would be freed. This is pointless in general as it would be
>> freed generically anyway, but here it is actively harmful: If the second
>> of the aforementioned allocations fails, the first buffer would leak
>> upon freeing priv_data.
>>
>> This commit stops freeing priv_data manually, which allows the muxer to
>> properly clean up in the deinit function.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavformat/oggenc.c | 7 +--
>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
>> index fe89f23e36..fbd14fedf9 100644
>> --- a/libavformat/oggenc.c
>> +++ b/libavformat/oggenc.c
>> @@ -546,7 +546,6 @@ static int ogg_init(AVFormatContext *s)
>>   >metadata);
>>  if (err) {
>>  av_log(s, AV_LOG_ERROR, "Error writing FLAC headers\n");
>> -av_freep(>priv_data);
>>  return err;
>>  }
>>  } else if (st->codecpar->codec_id == AV_CODEC_ID_SPEEX) {
>> @@ -555,7 +554,6 @@ static int ogg_init(AVFormatContext *s)
>>>metadata);
>>  if (err) {
>>  av_log(s, AV_LOG_ERROR, "Error writing Speex headers\n");
>> -av_freep(>priv_data);
>>  return err;
>>  }
>>  } else if (st->codecpar->codec_id == AV_CODEC_ID_OPUS) {
>> @@ -564,7 +562,6 @@ static int ogg_init(AVFormatContext *s)
>>   >metadata, s->chapters, 
>> s->nb_chapters);
>>  if (err) {
>>  av_log(s, AV_LOG_ERROR, "Error writing Opus headers\n");
>> -av_freep(>priv_data);
>>  return err;
>>  }
>>  } else if (st->codecpar->codec_id == AV_CODEC_ID_VP8) {
>> @@ -572,7 +569,6 @@ static int ogg_init(AVFormatContext *s)
>>  s->flags & AVFMT_FLAG_BITEXACT);
>>  if (err) {
>>  av_log(s, AV_LOG_ERROR, "Error writing VP8 headers\n");
>> -av_freep(>priv_data);
>>  return err;
>>  }
>>  } else {
>> @@ -585,7 +581,7 @@ static int ogg_init(AVFormatContext *s)
>>st->codecpar->codec_id == 
>> AV_CODEC_ID_VORBIS ? 30 : 42,
>>(const uint8_t**)oggstream->header, 
>> oggstream->header_len) < 0) {
>>  av_log(s, AV_LOG_ERROR, "Extradata corrupted\n");
>> -av_freep(>priv_data);
>> +oggstream->header[1] = NULL;
>>  return AVERROR_INVALIDDATA;
>>  }
>>  
>> @@ -755,7 +751,6 @@ static void ogg_free(AVFormatContext *s)
>>  av_freep(>header[0]);
>>  }
>>  av_freep(>header[1]);
>> -av_freep(>priv_data);
>>  }
>>  
>>  while (p) {
>>
> Will apply this tomorrow if there are no objections.
> 
> - Andreas
> 
Applied.

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

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/qpeg: mark the init function as thread-safe

2020-04-20 Thread James Almer
On 4/20/2020 1:28 PM, Anton Khirnov wrote:
> Quoting James Almer (2020-04-20 15:39:19)
>> On 4/20/2020 10:30 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2020-04-17 05:10:08)
 Signed-off-by: James Almer 
 ---
  libavcodec/qpeg.c | 1 +
  1 file changed, 1 insertion(+)
>>>
>>> Looks good.
>>> Could have INIT_CLEANUP too, it seems.
>>
>> No, since the only way for init() to fail now is if allocating a->ref
>> fails, and if that happens then there's nothing to free.
> 
> Which means it's trivially INIT_CLEANUP.
> I believe the intent was to gradually mark all the codecs as
> INIT_CLEANUP and then drop the flag so they all behave the same.

Never interpreted it that way myself, since in decoders where it's not
needed it results in a call to close() for no gain, but ok, added and
pushed.

Thanks.

> 
> Anyway, that's just a nit, feel free to ignore.
> 

___
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/bsf: Use macro for "packet is empty"

2020-04-20 Thread Andreas Rheinhardt
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-04-19 21:22:52)
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/bsf.c | 13 ++---
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
> 
> Good idea
> 
Applied, thanks.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/utils: Fix memleak when decoding subtitle in find_stream_info

2020-04-20 Thread Andreas Rheinhardt
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-04-18 21:54:26)
>> avformat_find_stream_info() may decode some frames to get stream
>> information. And when it does this for subtitles, the decoded subtitles
>> leak.
>>
>> (Decoding subtitles was added in b1511e00f6fefde6cb31b2e17f7812cfac1c8bd6
>> for PGS subtitles. When PGS subtitles originate from a container that
>> exports every segment as a packet of its own, no output will be
>> generated when decoding a packet, because not enough input is available.
>> Yet when used with PGS subtitles in the Matroska form a single packet
>> contains enough data to generate output. Yet said output is not freed,
>> hence this leak.)
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
> 
> Looks good.
> 
Applied, thanks.

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

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/qpeg: mark the init function as thread-safe

2020-04-20 Thread Anton Khirnov
Quoting James Almer (2020-04-20 15:39:19)
> On 4/20/2020 10:30 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-04-17 05:10:08)
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavcodec/qpeg.c | 1 +
> >>  1 file changed, 1 insertion(+)
> > 
> > Looks good.
> > Could have INIT_CLEANUP too, it seems.
> 
> No, since the only way for init() to fail now is if allocating a->ref
> fails, and if that happens then there's nothing to free.

Which means it's trivially INIT_CLEANUP.
I believe the intent was to gradually mark all the codecs as
INIT_CLEANUP and then drop the flag so they all behave the same.

Anyway, that's just a nit, feel free to ignore.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Don't free uninitialized AVBPrint

2020-04-20 Thread Andreas Rheinhardt
Marton Balint:
> 
> 
> On Mon, 20 Apr 2020, Andreas Rheinhardt wrote:
> 
>> Fixes Coverity ID 1462307.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> I intend to apply this soon if there are no objections.
>>
>> libavformat/rtsp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> index 49f7644fab..0a6462000d 100644
>> --- a/libavformat/rtsp.c
>> +++ b/libavformat/rtsp.c
>> @@ -2567,8 +2567,8 @@ static int rtp_read_header(AVFormatContext *s)
>> fail_nobuf:
>>     ret = AVERROR(ENOMEM);
>>     av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer
>> space for sdp-headers\n");
>> -fail:
>>     av_bprint_finalize(, NULL);
>> +fail:
>>     avcodec_parameters_free();
>>     if (in)
>>     ffurl_close(in);
> 
> LGTM thanks. I guess this rtsp fix has a series of bad luck :)
> 
> Regards,
> Marton

Applied, thanks.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Put strings instead of pointers to strings into array

2020-04-20 Thread Andreas Rheinhardt
Marton Balint:
> 
> 
> On Mon, 20 Apr 2020, Andreas Rheinhardt wrote:
> 
>> In this example, the difference in length between the shortest and
>> longest string is three, so that not using pointers to strings saves
>> space even on 32bit systems.
>>
>> Moreover, there is no need to use a sentinel here; it can be replaced
>> with FF_ARRAY_ELEMS.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> I have to admit that this is untested.
>>
>> libavformat/rtsp.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> index 0a6462000d..b2b3f32011 100644
>> --- a/libavformat/rtsp.c
>> +++ b/libavformat/rtsp.c
>> @@ -2526,10 +2526,11 @@ static int rtp_read_header(AVFormatContext *s)
>>
>>     p = strchr(s->url, '?');
>>     if (p) {
>> -    static const char *filters[][2] = {{"sources", "incl"},
>> {"block", "excl"}, {NULL, NULL}};
>> +    static const char filters[][2][8] = { { "sources", "incl" },
>> +  { "block",   "excl" } };
>>     int i;
>>     char *q;
>> -    for (i = 0; filters[i][0]; i++) {
>> +    for (i = 0; i < FF_ARRAY_ELEMS(filters); i++) {
>>     if (av_find_info_tag(filters_buf, sizeof(filters_buf),
>> filters[i][0], p)) {
>>     q = filters_buf;
>>     while ((q = strchr(q, ',')) != NULL)
> 
> LGTM, thanks.
> 
> Marton

Applied, thanks.

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

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

Re: [FFmpeg-devel] [PATCH] cmdutils: stop using deprecated av_codec_next()

2020-04-20 Thread Josh de Kock

On 14/04/2020 13:37, Josh de Kock wrote:

On Tue, Apr 14, 2020, at 9:09 AM, Anton Khirnov wrote:

---
  fftools/cmdutils.c | 33 +++--
  1 file changed, 19 insertions(+), 14 deletions(-)

[...]


LGTM, thanks. I will apply this a bit later after my set (or you can if you 
want it sooner).


Applied.

--
Josh

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

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

Re: [FFmpeg-devel] [PATCH 3/3] tools: stop using deprecated av_codec_next()

2020-04-20 Thread Josh de Kock

On 14/04/2020 13:38, Josh de Kock wrote:

Signed-off-by: Josh de Kock 
---
  tools/enum_options.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/enum_options.c b/tools/enum_options.c
index 28631d1a6b..548e427b7a 100644
--- a/tools/enum_options.c
+++ b/tools/enum_options.c
@@ -113,13 +113,14 @@ static void show_format_opts(void)
  
  static void show_codec_opts(void)

  {
+void *iter = NULL;
  AVCodec *c = NULL;
  
  printf("@section Generic codec AVOptions\n");

  show_opts(avcodec_get_class());
  
  printf("@section Codec-specific AVOptions\n");

-while ((c = av_codec_next(c))) {
+while ((c = av_codec_iterate())) {
  if (!c->priv_class)
  continue;
  printf("@subsection %s AVOptions\n", c->priv_class->class_name);



Set applied.

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

2020-04-20 Thread Vittorio Giovara
On Mon, Apr 20, 2020 at 10:09 AM Paul B Mahol  wrote:

> On 4/20/20, Rashil Gandhi  wrote:
> > Hi,
> >
> > I figured reading my proposal was too much work so I have a one-line
> > question here that I'd like to know the answer to.
> >
> > Can an FFmpeg video filter access unclamped 32-bit float values from
> > an OpenEXR input file?
> >
>
> Nope, because decoder outputs currently non-floats pixel formats only.
> This can easily be changed, but then swscale need to be updated.
>

In theory one could use zscale (zimg) which already support float input.
However the decoder does need to be updated to output that particular
format.
See what it does in the vf_tonemap.c filter.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] OpenColorIO - Google Summer of Code

2020-04-20 Thread Paul B Mahol
On 4/20/20, Rashil Gandhi  wrote:
> Hi,
>
> I figured reading my proposal was too much work so I have a one-line
> question here that I'd like to know the answer to.
>
> Can an FFmpeg video filter access unclamped 32-bit float values from
> an OpenEXR input file?
>

Nope, because decoder outputs currently non-floats pixel formats only.
This can easily be changed, but then swscale need to be updated.

> I'd like to request again, if this is not the correct place to
> approach the developers, please tell me how I can reach out to them.
>
> Regards,
> Rashil
>
>
> On Sun, 12 Apr 2020 at 15:25, Rashil Gandhi  wrote:
>
>> Hi,
>>
>> I'm a student applying for Google Summer of Code this year in the
>> organization Academy Software Foundation. One of the projects that
>> come under them is OpenColorIO, a color management framework for
>> visual effects and animation. The project idea that I'd like to work
>> on is 'Adding OpenColorIO support to FFmpeg', which extends or
>> modifies FFmpeg so that OpenColorIO could be employed for color
>> conversion in FFmpeg. More details of which can be found on
>>
>> https://github.com/AcademySoftwareFoundation/tac/tree/master/gsoc#opencolorio.
>>
>>
>> Through the medium of this mailing list I'd like to ask the
>> developers of FFmpeg for their guidance on how such an idea should
>> be proceeded with. Kindly go through the Project Overview and
>> Timeline sections of my GSoC proposal here
>>
>> https://docs.google.com/document/d/17ZxMjNR7cRMtwyxbcb0VzfeEvNizKWbmpFa67zuR4r4/edit?usp=sharing.
>>
>> It consists of some basic preliminary analysis of how the idea would
>> be implemented. The support of FFmpeg developers throughout is
>> fundamental for the project idea.
>>
>> If this is not the correct place to approach the developers, please
>> tell me how I can reach out to them.
>>
>> Regards,
>> Rashil Gandhi
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/qpeg: remove an unnecessary intermediary AVFrame

2020-04-20 Thread James Almer
On 4/20/2020 10:28 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-04-17 05:10:06)
>> Decoding can be handled directly in the output frame.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/qpeg.c | 22 +-
>>  1 file changed, 9 insertions(+), 13 deletions(-)
>>
> 
> Seems you're also fixing flush, so maybe mention that in the commit
> message.
> 
> Otherwise looks ok

Will mention that and apply. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/qpeg: mark the init function as thread-safe

2020-04-20 Thread James Almer
On 4/20/2020 10:30 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-04-17 05:10:08)
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/qpeg.c | 1 +
>>  1 file changed, 1 insertion(+)
> 
> Looks good.
> Could have INIT_CLEANUP too, it seems.

No, since the only way for init() to fail now is if allocating a->ref
fails, and if that happens then there's nothing to free.

Will apply, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/qpeg: mark the init function as thread-safe

2020-04-20 Thread Anton Khirnov
Quoting James Almer (2020-04-17 05:10:08)
> Signed-off-by: James Almer 
> ---
>  libavcodec/qpeg.c | 1 +
>  1 file changed, 1 insertion(+)

Looks good.
Could have INIT_CLEANUP too, it seems.

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

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

Re: [FFmpeg-devel] OpenColorIO - Google Summer of Code

2020-04-20 Thread Rashil Gandhi
Hi,

I figured reading my proposal was too much work so I have a one-line
question here that I'd like to know the answer to.

Can an FFmpeg video filter access unclamped 32-bit float values from
an OpenEXR input file?

I'd like to request again, if this is not the correct place to
approach the developers, please tell me how I can reach out to them.

Regards,
Rashil


On Sun, 12 Apr 2020 at 15:25, Rashil Gandhi  wrote:

> Hi,
>
> I'm a student applying for Google Summer of Code this year in the
> organization Academy Software Foundation. One of the projects that
> come under them is OpenColorIO, a color management framework for
> visual effects and animation. The project idea that I'd like to work
> on is 'Adding OpenColorIO support to FFmpeg', which extends or
> modifies FFmpeg so that OpenColorIO could be employed for color
> conversion in FFmpeg. More details of which can be found on
>
> https://github.com/AcademySoftwareFoundation/tac/tree/master/gsoc#opencolorio.
>
>
> Through the medium of this mailing list I'd like to ask the
> developers of FFmpeg for their guidance on how such an idea should
> be proceeded with. Kindly go through the Project Overview and
> Timeline sections of my GSoC proposal here
>
> https://docs.google.com/document/d/17ZxMjNR7cRMtwyxbcb0VzfeEvNizKWbmpFa67zuR4r4/edit?usp=sharing.
>
> It consists of some basic preliminary analysis of how the idea would
> be implemented. The support of FFmpeg developers throughout is
> fundamental for the project idea.
>
> If this is not the correct place to approach the developers, please
> tell me how I can reach out to them.
>
> Regards,
> Rashil Gandhi
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/qpeg: export missing frame properties

2020-04-20 Thread Anton Khirnov
Quoting James Almer (2020-04-17 05:10:07)
> Signed-off-by: James Almer 
> ---

Looks ok

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/qpeg: remove an unnecessary intermediary AVFrame

2020-04-20 Thread Anton Khirnov
Quoting James Almer (2020-04-17 05:10:06)
> Decoding can be handled directly in the output frame.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/qpeg.c | 22 +-
>  1 file changed, 9 insertions(+), 13 deletions(-)
> 

Seems you're also fixing flush, so maybe mention that in the commit
message.

Otherwise looks ok

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/bsf: Use macro for "packet is empty"

2020-04-20 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2020-04-19 21:22:52)
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/bsf.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 

Good idea

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

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

Re: [FFmpeg-devel] [PATCH v4 2/7] lavutil: add DOVI related header

2020-04-20 Thread Anton Khirnov
Quoting Jean-Baptiste Kempf (2020-04-19 10:25:07)
> I'd like to ask opinions whether a installed header for just one structure is 
> a good idea.

I see no problem with it. More smaller headers is better that a few big
headers.

Another issue is that this struct has no constructor and thus cannot be
extended without breaking ABI.

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: Pass ret from decode_iccp_chunk()

2020-04-20 Thread Anton Khirnov
Quoting Michael Niedermayer (2020-04-18 01:48:47)
> Found while reviewing a patch fixing a similar issue
> 
> Signed-off-by: Michael Niedermayer 
> ---

Looks ok

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

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

Re: [FFmpeg-devel] [PATCH] gas-preprocessor: Fix use of Visual Studio compiler values -w... or -FS

2020-04-20 Thread Martin Storsjö

On Mon, 20 Apr 2020, phunkyfish wrote:


From: Alwin Esch 

---
gas-preprocessor.pl | 4 
1 file changed, 4 insertions(+)

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 860b97c..126ee50 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -164,6 +164,8 @@ if ($as_type ne "armasm") {
@preprocess_c_cmd = grep ! /^-EHsc$/, @preprocess_c_cmd;
@preprocess_c_cmd = grep ! /^-O/, @preprocess_c_cmd;
@preprocess_c_cmd = grep ! /^-oldit/, @preprocess_c_cmd;
+@preprocess_c_cmd = grep ! /^-FS/, @preprocess_c_cmd;
+@preprocess_c_cmd = grep ! /^-w/, @preprocess_c_cmd;

@gcc_cmd = grep ! /^-G/, @gcc_cmd;
@gcc_cmd = grep ! /^-W/, @gcc_cmd;
@@ -171,6 +173,8 @@ if ($as_type ne "armasm") {
@gcc_cmd = grep ! /^-fp/, @gcc_cmd;
@gcc_cmd = grep ! /^-EHsc$/, @gcc_cmd;
@gcc_cmd = grep ! /^-O/, @gcc_cmd;
+@gcc_cmd = grep ! /^-FS/, @gcc_cmd;
+@gcc_cmd = grep ! /^-w/, @gcc_cmd;

my @outfiles = grep /\.(o|obj)$/, @gcc_cmd;
$tempfile = $outfiles[0].".asm";
--
2.24.2 (Apple Git-127)


Ok with me - will push a bit later.

// Martin

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

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

Re: [FFmpeg-devel] [PATCH] avformat/utils: Fix memleak when decoding subtitle in find_stream_info

2020-04-20 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2020-04-18 21:54:26)
> avformat_find_stream_info() may decode some frames to get stream
> information. And when it does this for subtitles, the decoded subtitles
> leak.
> 
> (Decoding subtitles was added in b1511e00f6fefde6cb31b2e17f7812cfac1c8bd6
> for PGS subtitles. When PGS subtitles originate from a container that
> exports every segment as a packet of its own, no output will be
> generated when decoding a packet, because not enough input is available.
> Yet when used with PGS subtitles in the Matroska form a single packet
> contains enough data to generate output. Yet said output is not freed,
> hence this leak.)
> 
> Signed-off-by: Andreas Rheinhardt 
> ---

Looks good.

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

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

[FFmpeg-devel] [PATCH] gas-preprocessor: Fix use of Visual Studio compiler values -w... or -FS

2020-04-20 Thread phunkyfish
From: Alwin Esch 

---
 gas-preprocessor.pl | 4 
 1 file changed, 4 insertions(+)

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 860b97c..126ee50 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -164,6 +164,8 @@ if ($as_type ne "armasm") {
 @preprocess_c_cmd = grep ! /^-EHsc$/, @preprocess_c_cmd;
 @preprocess_c_cmd = grep ! /^-O/, @preprocess_c_cmd;
 @preprocess_c_cmd = grep ! /^-oldit/, @preprocess_c_cmd;
+@preprocess_c_cmd = grep ! /^-FS/, @preprocess_c_cmd;
+@preprocess_c_cmd = grep ! /^-w/, @preprocess_c_cmd;
 
 @gcc_cmd = grep ! /^-G/, @gcc_cmd;
 @gcc_cmd = grep ! /^-W/, @gcc_cmd;
@@ -171,6 +173,8 @@ if ($as_type ne "armasm") {
 @gcc_cmd = grep ! /^-fp/, @gcc_cmd;
 @gcc_cmd = grep ! /^-EHsc$/, @gcc_cmd;
 @gcc_cmd = grep ! /^-O/, @gcc_cmd;
+@gcc_cmd = grep ! /^-FS/, @gcc_cmd;
+@gcc_cmd = grep ! /^-w/, @gcc_cmd;
 
 my @outfiles = grep /\.(o|obj)$/, @gcc_cmd;
 $tempfile = $outfiles[0].".asm";
-- 
2.24.2 (Apple Git-127)

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

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

Re: [FFmpeg-devel] [PATCH v1] lavf/mp3enc: fix ID3v1 year metadata setting issue

2020-04-20 Thread Anton Khirnov
Quoting myp...@gmail.com (2020-04-20 14:05:50)
> On Mon, Apr 20, 2020 at 8:00 PM Anton Khirnov  wrote:
> >
> > Quoting Jun Zhao (2020-04-20 10:17:06)
> > > From: Jun Zhao 
> > >
> > > Follow the http://id3.org/ID3v1, setting the year metadata
> > > for ID3v1.
> > >
> > > fix #8623
> > >
> > > Signed-off-by: Jun Zhao 
> > > ---
> > >  libavformat/mp3enc.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
> > > index 34b753f..157174f 100644
> > > --- a/libavformat/mp3enc.c
> > > +++ b/libavformat/mp3enc.c
> > > @@ -45,6 +45,7 @@ static int id3v1_set_string(AVFormatContext *s, const 
> > > char *key,
> > >  return !!tag;
> > >  }
> > >
> > > +// refer to: http://id3.org/ID3v1
> > >  static int id3v1_create_tag(AVFormatContext *s, uint8_t *buf)
> > >  {
> > >  AVDictionaryEntry *tag;
> > > @@ -58,7 +59,7 @@ static int id3v1_create_tag(AVFormatContext *s, uint8_t 
> > > *buf)
> > >  count += id3v1_set_string(s, "TIT2",buf +  3, 30 + 1);   
> > > //title
> > >  count += id3v1_set_string(s, "TPE1",buf + 33, 30 + 1);   
> > > //author|artist
> > >  count += id3v1_set_string(s, "TALB",buf + 63, 30 + 1);   
> > > //album
> > > -count += id3v1_set_string(s, "TDRC",buf + 93,  4 + 1);   
> > > //date
> > > +count += id3v1_set_string(s, "TYER",buf + 93,  4 + 1);   
> > > //year
> >
> > This will break for ID3v2.4, no?
> >
> Why? This change is just changing the ID3v1

The "date" tag is converted to "TDRC" for v2.4 and "TYER"/"TDAT" for
v2.3.

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

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

Re: [FFmpeg-devel] [PATCH v1] lavf/mp3enc: fix ID3v1 year metadata setting issue

2020-04-20 Thread myp...@gmail.com
On Mon, Apr 20, 2020 at 8:00 PM Anton Khirnov  wrote:
>
> Quoting Jun Zhao (2020-04-20 10:17:06)
> > From: Jun Zhao 
> >
> > Follow the http://id3.org/ID3v1, setting the year metadata
> > for ID3v1.
> >
> > fix #8623
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavformat/mp3enc.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
> > index 34b753f..157174f 100644
> > --- a/libavformat/mp3enc.c
> > +++ b/libavformat/mp3enc.c
> > @@ -45,6 +45,7 @@ static int id3v1_set_string(AVFormatContext *s, const 
> > char *key,
> >  return !!tag;
> >  }
> >
> > +// refer to: http://id3.org/ID3v1
> >  static int id3v1_create_tag(AVFormatContext *s, uint8_t *buf)
> >  {
> >  AVDictionaryEntry *tag;
> > @@ -58,7 +59,7 @@ static int id3v1_create_tag(AVFormatContext *s, uint8_t 
> > *buf)
> >  count += id3v1_set_string(s, "TIT2",buf +  3, 30 + 1);   
> > //title
> >  count += id3v1_set_string(s, "TPE1",buf + 33, 30 + 1);   
> > //author|artist
> >  count += id3v1_set_string(s, "TALB",buf + 63, 30 + 1);   
> > //album
> > -count += id3v1_set_string(s, "TDRC",buf + 93,  4 + 1);   //date
> > +count += id3v1_set_string(s, "TYER",buf + 93,  4 + 1);   //year
>
> This will break for ID3v2.4, no?
>
Why? This change is just changing the ID3v1
> --
> Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v1] lavf/mp3enc: fix ID3v1 year metadata setting issue

2020-04-20 Thread Anton Khirnov
Quoting Jun Zhao (2020-04-20 10:17:06)
> From: Jun Zhao 
> 
> Follow the http://id3.org/ID3v1, setting the year metadata
> for ID3v1.
> 
> fix #8623
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/mp3enc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
> index 34b753f..157174f 100644
> --- a/libavformat/mp3enc.c
> +++ b/libavformat/mp3enc.c
> @@ -45,6 +45,7 @@ static int id3v1_set_string(AVFormatContext *s, const char 
> *key,
>  return !!tag;
>  }
>  
> +// refer to: http://id3.org/ID3v1
>  static int id3v1_create_tag(AVFormatContext *s, uint8_t *buf)
>  {
>  AVDictionaryEntry *tag;
> @@ -58,7 +59,7 @@ static int id3v1_create_tag(AVFormatContext *s, uint8_t 
> *buf)
>  count += id3v1_set_string(s, "TIT2",buf +  3, 30 + 1);   //title
>  count += id3v1_set_string(s, "TPE1",buf + 33, 30 + 1);   
> //author|artist
>  count += id3v1_set_string(s, "TALB",buf + 63, 30 + 1);   //album
> -count += id3v1_set_string(s, "TDRC",buf + 93,  4 + 1);   //date
> +count += id3v1_set_string(s, "TYER",buf + 93,  4 + 1);   //year

This will break for ID3v2.4, no?

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/rtsp: fix rtsp multicasts

2020-04-20 Thread Wolfgang Haupt

On 20.04.20 10:52, Wolfgang Haupt wrote:

On 20.04.20 10:08, Marton Balint wrote:



On Mon, 20 Apr 2020, Wolfgang Haupt wrote:


On 19.04.20 23:43, Marton Balint wrote:



On Sun, 19 Apr 2020, Wolfgang Haupt wrote:


On 19.04.20 14:53, Marton Balint wrote:



On Sun, 19 Apr 2020, Wolfgang Haupt wrote:


ping

On 03.04.20 08:42, Wolfgang Haupt wrote:

Hey,

is someone up to review this patch?

It's an attempt to fix rtsp streams that use udp multicasts as 
the underlying

transmission protocol.
The idea was taken from live555 as the said stream worked in VLC.

It still applies cleanly on current master.


Best Regards,
Wolfgang

On 18.10.19 18:59, Wolfgang Haupt wrote:

If an rtsp server offers a udp multicast
address as response of a DESCRIBE command
the rtsp client is expected to issue
SETUP with "Transport: RTP/AVP/UDP;multicast".
Some rtsp servers bail out otherwise.
---
  libavformat/rtsp.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 859defa592..3f0cbfc98b 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1913,6 +1913,9 @@ redirect:
  && (rt->rtsp_flags & RTSP_FLAG_PREFER_TCP))
  lower_transport = RTSP_LOWER_TRANSPORT_TCP;
  +    if (ff_is_multicast_address((struct 
sockaddr*)>rtsp_streams[rt->nb_rtsp_streams-1]->sdp_ip))
+    lower_transport = 
RTSP_LOWER_TRANSPORT_UDP_MULTICAST;

+


Shouldn't this take into account lower_transport_mask? E.g. it 
should only prefer multicast if it is allowed in the mask?


Can you explain what the lower_transport_mask is about?
I cannot think of any case where you wouldn't want use udp 
multicast when the rtsp server gives you a mutlicast-ip

in response to a DESCRIBE request.


I am not familiar with the code, but it looks like it is used to 
control the allowed (tried) transport methods. The rtsp protocol 
has an rtsp_transport option, that is the source of the mask:

https://www.ffmpeg.org/ffmpeg-all.html#rtsp
If UDP multicast transport is disallowed because it is not in the 
mask then you should not set it as far as I see.


Mhm, yeah that's actually the problem I tried to fix.
Reading the docs again, I'm not sure if I missed it before, but the 
docs are stating:
Multiple lower transport protocols may be specified, in that case 
they are tried one at a time (if the setup of one fails, the next 
one is tried). For the muxer, only the ‘tcp’ and ‘udp’ options are 
supported.


Are you fixing the muxer or the demuxer? So are you reading via 
multicast or generating multicast?
I'm trying to fix the demuxer, so I'm reading a multicast udp stream 
from an IP camera.


However I still cannot manage to get udp + udp_multicast into the 
lower_transport_mask on the commandline, so I'm still not sure 
how/if it's possible to really set multiple protocols.


Why not? Isn't it just specifying -rtsp_transport +udp+udp_multicast ?
I tried various separators like blank, comma, colon - now I gave your 
version a try, but it still fails.


./ffprobe -rtsp_transport +udp+udp_multicast -i 
rtsp://172.17.1.131/stream1m


[rtsp @ 0x55be51d7c600] Nonmatching transport in server reply
rtsp://172.17.1.131/stream1m: Invalid data found when processing input

While writing this reply, I did some more debugging:
Your version of the commandline successfully changes the value of the 
lower_transport_mask but it still just fails to probe - I'll dig into 
why it's not working as expected and come back with

my conclusions.

Alright, thanks to your comments I think I now fully understand the code.
All of your remarks are right, I printed the value of 
lower_transport_mask and see that it's 7 by default and 5 for 
udp+udp_multicast, etc.


The RTSP-Server of that camera, does never return "status_code == 461", 
instead it just answers with
"[rtsp @ 0x55971cf77e80] line='Transport: 
RTP/AVP;multicast;source=172.17.1.131;destination=239.17.1.131;port=6780-6781;ttl=10;'"

no matter what protocol I request.

This results in ff_rtsp_make_setup_request returning AVERROR_INVALIDDATA 
instead of 1 and the mechanism to retry the next protocol doesn't get 
fired, instead ffmpeg bails out immediately.
Probably the camera is violating the RFC (honestly I don't know the RFC 
good enough) and I cannot upstream this patch :(

Big thanks for the review, though.





Therefore my patch always adds "udp_multicast" as lower_transport no 
matter what the lower_transport_mask is as soon as the DESCRIBE 
response returns a multicast IP, because
clients don't know when to set udp vs. udp_multicast as you can't 
know which stream you get.


That is why lower_transport is a mask, a combination of the possible 
values. And it looks like by default everything _is_ allowed.
My stream always fails until I specify exactly: ./ffprobe 
-rtsp_transport udp_multicast -i rtsp://172.17.1.131/stream1m


Regards,
Marton





Regards,
Marton





Thanks,
Marton

  err = ff_rtsp_make_setup_request(s, host, port, 

Re: [FFmpeg-devel] [RFC PATCH v2] libavcodec/jpeg2000_parser: Add jpeg2000 parser

2020-04-20 Thread Gautam Ramakrishnan
On Mon, Apr 20, 2020 at 4:18 PM Kieran O Leary  wrote:
>
> Hi,
>
> Forgive my ignorance ,but what is the difference between a parser and a
> decoder in this context? What does this parser add that wasn't covered in
> the decoder?
>
Quoting Carl from a previous thread:
Try the following:
$ cat 1.jpg 2.jpg | ffmpeg -i -f null -
(Is expected to decode two frames as can be seen in the console output,
also works for example with png)

$ cat 1.j2k 2.j2k | ffmpeg -i - -f null -
Will only decode one frame because there is no parser to split the
input.
> Best,
>
> Kieran O'Leary
> Irish Film Institute
> ___
> 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".



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

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

[FFmpeg-devel] [PATCH v1] avcodec/utils: use av_rescale()

2020-04-20 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/utils.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 26c038dfd9..005d596dfd 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2229,8 +2229,8 @@ int64_t ff_guess_coded_bitrate(AVCodecContext *avctx)
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
 bits_per_coded_sample = av_get_bits_per_pixel(desc);
 }
-bitrate = (int64_t)bits_per_coded_sample * avctx->width * avctx->height *
-  framerate.num / framerate.den;
+bitrate = av_rescale(avctx->width * avctx->height,
+bits_per_coded_sample * framerate.num, framerate.den);
 
 return bitrate;
 }
-- 
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] [RFC PATCH v2] libavcodec/jpeg2000_parser: Add jpeg2000 parser

2020-04-20 Thread Paul B Mahol
On 4/20/20, Kieran O Leary  wrote:
> Hi,
>
> Forgive my ignorance ,but what is the difference between a parser and a
> decoder in this context? What does this parser add that wasn't covered in
> the decoder?

Bunch of stuff, like splitting packets.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v1] avcodec/h264_metadata_bsf: add option to delete SEI user data

2020-04-20 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 doc/bitstream_filters.texi |  3 +++
 libavcodec/h264_metadata_bsf.c | 19 +++
 2 files changed, 22 insertions(+)

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 8fe5b3ad75..652eb4620f 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -273,6 +273,9 @@ possibly separated by hyphens, and the string can be 
anything.
 For example, @samp{086f3693-b7b3-4f2c-9653-21492feee5b8+hello} will
 insert the string ``hello'' associated with the given UUID.
 
+@item delete_user_data
+Deletes all SEI user data messages.
+
 @item delete_filler
 Deletes both filler NAL units and filler SEI messages.
 
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index d96a50dbf7..8b42faff1b 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -76,6 +76,7 @@ typedef struct H264MetadataContext {
 int crop_bottom;
 
 const char *sei_user_data;
+int delete_user_data;
 
 int delete_filler;
 
@@ -361,6 +362,21 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
AVPacket *pkt)
 }
 }
 
+if (ctx->delete_user_data) {
+for (i = au->nb_units - 1; i >= 0; i--) {
+if (au->units[i].type == H264_NAL_SEI) {
+H264RawSEI *sei = au->units[i].content;
+
+for (j = sei->payload_count - 1; j >= 0; j--) {
+if (sei->payload[j].payload_type ==
+H264_SEI_TYPE_USER_DATA_UNREGISTERED)
+ff_cbs_h264_delete_sei_message(ctx->cbc, au,
+   >units[i], j);
+}
+}
+}
+}
+
 // Only insert the SEI in access units containing SPSs, and also
 // unconditionally in the first access unit we ever see.
 if (ctx->sei_user_data && (has_sps || !ctx->done_first_au)) {
@@ -684,6 +700,9 @@ static const AVOption h264_metadata_options[] = {
 { "sei_user_data", "Insert SEI user data (UUID+string)",
 OFFSET(sei_user_data), AV_OPT_TYPE_STRING, { .str = NULL }, .flags = 
FLAGS },
 
+{ "delete_user_data", "Delete all SEI user data",
+OFFSET(delete_user_data), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS},
+
 { "delete_filler", "Delete all filler (both NAL and SEI)",
 OFFSET(delete_filler), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS},
 
-- 
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] [RFC PATCH v2] libavcodec/jpeg2000_parser: Add jpeg2000 parser

2020-04-20 Thread Kieran O Leary
Hi,

Forgive my ignorance ,but what is the difference between a parser and a
decoder in this context? What does this parser add that wasn't covered in
the decoder?

Best,

Kieran O'Leary
Irish Film Institute
___
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] [RFC PATCH v2] libavcodec/jpeg2000_parser: Add jpeg2000 parser

2020-04-20 Thread Gautam Ramakrishnan
On Mon, Apr 20, 2020 at 3:38 PM Michael Niedermayer
 wrote:
>
> On Mon, Apr 20, 2020 at 01:36:47AM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan 
> >
> > I have attempted to write a JPEG2000 Parser. Need
> > help on testing the code and some tips on how to
>
> to test the code i would sugest to generate a file
> or files with many jpeg2000 images and then try to
> decode it to -f framecrc
This helps me check whether the image is correct by comparing the CRC value?
> if that work repeat while varying the packet size
> input to the parser, a parser must work with anything
> from 1 byte per input to sizes being larger than a
> single frame.
>
So a packet to a parser is basically a smaller unit to which the parser is fed
data to? When I tried printing buffer size during parse, it shows 4096.
Does that mean the packet size was 4096?
> there can to be corner cases in parsers when input
> split the wrong header value
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Whats the most studid thing your enemy could do ? Blow himself up
> Whats the most studid thing you could do ? Give up your rights and
> freedom because your enemy blew himself up.
>
> ___
> 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".



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

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

Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Put strings instead of pointers to strings into array

2020-04-20 Thread Ross Nicholson


> On 20 Apr 2020, at 02:42, Andreas Rheinhardt  
> wrote:
> 
> In this example, the difference in length between the shortest and
> longest string is three, so that not using pointers to strings saves
> space even on 32bit systems.
> 
> Moreover, there is no need to use a sentinel here; it can be replaced
> with FF_ARRAY_ELEMS.

Thanks, again.

> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> I have to admit that this is untested.
> 
> libavformat/rtsp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 0a6462000d..b2b3f32011 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -2526,10 +2526,11 @@ static int rtp_read_header(AVFormatContext *s)
> 
> p = strchr(s->url, '?');
> if (p) {
> -static const char *filters[][2] = {{"sources", "incl"}, {"block", 
> "excl"}, {NULL, NULL}};
> +static const char filters[][2][8] = { { "sources", "incl" },
> +  { "block",   "excl" } };
> int i;
> char *q;
> -for (i = 0; filters[i][0]; i++) {
> +for (i = 0; i < FF_ARRAY_ELEMS(filters); i++) {
> if (av_find_info_tag(filters_buf, sizeof(filters_buf), 
> filters[i][0], p)) {
> q = filters_buf;
> while ((q = strchr(q, ',')) != NULL)
> -- 
> 2.20.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Don't free uninitialized AVBPrint

2020-04-20 Thread Ross Nicholson


> On 20 Apr 2020, at 08:53, Marton Balint  wrote:
> 
> 
> 
>> On Mon, 20 Apr 2020, Andreas Rheinhardt wrote:
>> 
>> Fixes Coverity ID 1462307.
>> 
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> I intend to apply this soon if there are no objections.
>> 
>> libavformat/rtsp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> index 49f7644fab..0a6462000d 100644
>> --- a/libavformat/rtsp.c
>> +++ b/libavformat/rtsp.c
>> @@ -2567,8 +2567,8 @@ static int rtp_read_header(AVFormatContext *s)
>> fail_nobuf:
>>ret = AVERROR(ENOMEM);
>>av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space for 
>> sdp-headers\n");
>> -fail:
>>av_bprint_finalize(, NULL);
>> +fail:
>>avcodec_parameters_free();
>>if (in)
>>ffurl_close(in);
> 
> LGTM thanks. I guess this rtsp fix has a series of bad luck :)

Man, and I was sure the last version was good. Thanks Andreas for fixing up.

> 
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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] [RFC PATCH v2] libavcodec/jpeg2000_parser: Add jpeg2000 parser

2020-04-20 Thread Michael Niedermayer
On Mon, Apr 20, 2020 at 01:36:47AM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan 
> 
> I have attempted to write a JPEG2000 Parser. Need
> help on testing the code and some tips on how to

to test the code i would sugest to generate a file
or files with many jpeg2000 images and then try to
decode it to -f framecrc
if that work repeat while varying the packet size
input to the parser, a parser must work with anything
from 1 byte per input to sizes being larger than a
single frame.

there can to be corner cases in parsers when input
split the wrong header value

thx

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

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.



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

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add ff_inlink_peek_samples and ff_inlink_skip samples

2020-04-20 Thread Nicolas George
Paul B Mahol (12020-04-18):
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/avfilter.c | 96 ++
>  libavfilter/filters.h  | 17 
>  2 files changed, 113 insertions(+)
> 
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 394811916d..90c73fb64b 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -1190,6 +1190,61 @@ static int take_samples(AVFilterLink *link, unsigned 
> min, unsigned max,
>  return 0;
>  }
>  
> +static int peek_samples(AVFilterLink *link, unsigned peek_samples,
> +AVFrame **rframe)
> +{
> +AVFrame *frame0, *frame, *buf;
> +unsigned nb_samples, nb_frames, i, p;
> +int ret;
> +
> +/* Note: this function relies on no format changes and must only be
> +   called with enough samples. */
> +av_assert1(samples_ready(link, link->min_samples));
> +frame0 = frame = ff_framequeue_peek(>fifo, 0);
> +if (!link->fifo.samples_skipped && frame->nb_samples == peek_samples) {
> +*rframe = av_frame_clone(frame);
> +return 0;
> +}
> +nb_frames = 0;
> +nb_samples = 0;
> +while (1) {
> +if (nb_samples + frame->nb_samples >= peek_samples)
> +break;
> +nb_samples += frame->nb_samples;
> +nb_frames++;
> +if (nb_frames == ff_framequeue_queued_frames(>fifo))
> +break;
> +frame = ff_framequeue_peek(>fifo, nb_frames);
> +}
> +
> +buf = ff_get_audio_buffer(link, peek_samples);
> +if (!buf)
> +return AVERROR(ENOMEM);
> +ret = av_frame_copy_props(buf, frame0);
> +if (ret < 0) {
> +av_frame_free();
> +return ret;
> +}
> +buf->pts = frame0->pts;
> +
> +p = 0;
> +for (i = 0; i < nb_frames; i++) {
> +frame = ff_framequeue_peek(>fifo, i);
> +av_samples_copy(buf->extended_data, frame->extended_data, p, 0,
> +frame->nb_samples, link->channels, link->format);
> +p += frame->nb_samples;
> +}
> +if (p < peek_samples) {
> +unsigned n = peek_samples - p;
> +frame = ff_framequeue_peek(>fifo, i);
> +av_samples_copy(buf->extended_data, frame->extended_data, p, 0, n,
> +link->channels, link->format);
> +}
> +
> +*rframe = buf;
> +return 0;
> +}

This is a copy-paste of take_samples() with only minimal changes. Please
make more effort to share the code.

> +
>  static int ff_filter_frame_to_filter(AVFilterLink *link)
>  {
>  AVFrame *frame = NULL;
> @@ -1512,6 +1567,47 @@ int ff_inlink_consume_samples(AVFilterLink *link, 
> unsigned min, unsigned max,
>  return 1;
>  }
>  
> +int ff_inlink_peek_samples(AVFilterLink *link, unsigned nb_samples,
> +   AVFrame **rframe)
> +{
> +AVFrame *frame;
> +int ret;
> +
> +av_assert1(nb_samples);
> +*rframe = NULL;
> +if (!ff_inlink_check_available_samples(link, nb_samples))
> +return 0;
> +if (link->status_in)
> +nb_samples = FFMIN(nb_samples, 
> ff_framequeue_queued_samples(>fifo));
> +ret = peek_samples(link, nb_samples, );
> +if (ret < 0)
> +return ret;
> +*rframe = frame;
> +return !!frame;
> +}
> +
> +void ff_inlink_skip_samples(AVFilterLink *link, unsigned skip_samples)
> +{
> +while (skip_samples > 0) {
> +AVFrame *frame = ff_inlink_peek_frame(link, 0);
> +if (skip_samples >= frame->nb_samples) {
> +frame = ff_framequeue_take(>fifo);
> +skip_samples -= frame->nb_samples;
> +av_frame_free();
> +} else {
> +break;
> +}
> +}
> +
> +if (skip_samples)
> +ff_framequeue_skip_samples(>fifo, skip_samples, 
> link->time_base);
> +
> +if (ff_inlink_queued_frames(link)) {
> +AVFrame *frame = ff_inlink_peek_frame(link, 0);
> +consume_update(link, frame);
> +}
> +}
> +
>  AVFrame *ff_inlink_peek_frame(AVFilterLink *link, size_t idx)
>  {
>  return ff_framequeue_peek(>fifo, idx);
> diff --git a/libavfilter/filters.h b/libavfilter/filters.h
> index 1157755403..7dc0b35981 100644
> --- a/libavfilter/filters.h
> +++ b/libavfilter/filters.h
> @@ -115,6 +115,23 @@ int ff_inlink_consume_frame(AVFilterLink *link, AVFrame 
> **rframe);
>  int ff_inlink_consume_samples(AVFilterLink *link, unsigned min, unsigned max,
>  AVFrame **rframe);
>  
> +/**
> + * Peek samples from the link's FIFO.
> + *
> + * @return  >0 if a samples are available,
> + *  0 and set rframe to NULL if no samples are available,
> + *  or AVERROR code
> + */
> +int ff_inlink_peek_samples(AVFilterLink *link, unsigned nb_samples,
> +   AVFrame **rframe);
> +
> +/**
> + * Skip samples from the link's FIFO.
> + *
> + * @note  May trigger process_command() and/or update is_disabled.
> + */
> +void ff_inlink_skip_samples(AVFilterLink *link, unsigned 

Re: [FFmpeg-devel] [PATCH] libavformat/rtsp: fix rtsp multicasts

2020-04-20 Thread Wolfgang Haupt

On 20.04.20 10:08, Marton Balint wrote:



On Mon, 20 Apr 2020, Wolfgang Haupt wrote:


On 19.04.20 23:43, Marton Balint wrote:



On Sun, 19 Apr 2020, Wolfgang Haupt wrote:


On 19.04.20 14:53, Marton Balint wrote:



On Sun, 19 Apr 2020, Wolfgang Haupt wrote:


ping

On 03.04.20 08:42, Wolfgang Haupt wrote:

Hey,

is someone up to review this patch?

It's an attempt to fix rtsp streams that use udp multicasts as 
the underlying

transmission protocol.
The idea was taken from live555 as the said stream worked in VLC.

It still applies cleanly on current master.


Best Regards,
Wolfgang

On 18.10.19 18:59, Wolfgang Haupt wrote:

If an rtsp server offers a udp multicast
address as response of a DESCRIBE command
the rtsp client is expected to issue
SETUP with "Transport: RTP/AVP/UDP;multicast".
Some rtsp servers bail out otherwise.
---
  libavformat/rtsp.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 859defa592..3f0cbfc98b 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1913,6 +1913,9 @@ redirect:
  && (rt->rtsp_flags & RTSP_FLAG_PREFER_TCP))
  lower_transport = RTSP_LOWER_TRANSPORT_TCP;
  +    if (ff_is_multicast_address((struct 
sockaddr*)>rtsp_streams[rt->nb_rtsp_streams-1]->sdp_ip))

+    lower_transport = RTSP_LOWER_TRANSPORT_UDP_MULTICAST;
+


Shouldn't this take into account lower_transport_mask? E.g. it 
should only prefer multicast if it is allowed in the mask?


Can you explain what the lower_transport_mask is about?
I cannot think of any case where you wouldn't want use udp 
multicast when the rtsp server gives you a mutlicast-ip

in response to a DESCRIBE request.


I am not familiar with the code, but it looks like it is used to 
control the allowed (tried) transport methods. The rtsp protocol has 
an rtsp_transport option, that is the source of the mask:

https://www.ffmpeg.org/ffmpeg-all.html#rtsp
If UDP multicast transport is disallowed because it is not in the 
mask then you should not set it as far as I see.


Mhm, yeah that's actually the problem I tried to fix.
Reading the docs again, I'm not sure if I missed it before, but the 
docs are stating:
Multiple lower transport protocols may be specified, in that case 
they are tried one at a time (if the setup of one fails, the next one 
is tried). For the muxer, only the ‘tcp’ and ‘udp’ options are 
supported.


Are you fixing the muxer or the demuxer? So are you reading via 
multicast or generating multicast?
I'm trying to fix the demuxer, so I'm reading a multicast udp stream 
from an IP camera.


However I still cannot manage to get udp + udp_multicast into the 
lower_transport_mask on the commandline, so I'm still not sure how/if 
it's possible to really set multiple protocols.


Why not? Isn't it just specifying -rtsp_transport +udp+udp_multicast ?
I tried various separators like blank, comma, colon - now I gave your 
version a try, but it still fails.


./ffprobe -rtsp_transport +udp+udp_multicast -i rtsp://172.17.1.131/stream1m

[rtsp @ 0x55be51d7c600] Nonmatching transport in server reply
rtsp://172.17.1.131/stream1m: Invalid data found when processing input

While writing this reply, I did some more debugging:
Your version of the commandline successfully changes the value of the 
lower_transport_mask but it still just fails to probe - I'll dig into 
why it's not working as expected and come back with

my conclusions.



Therefore my patch always adds "udp_multicast" as lower_transport no 
matter what the lower_transport_mask is as soon as the DESCRIBE 
response returns a multicast IP, because
clients don't know when to set udp vs. udp_multicast as you can't 
know which stream you get.


That is why lower_transport is a mask, a combination of the possible 
values. And it looks like by default everything _is_ allowed.
My stream always fails until I specify exactly: ./ffprobe 
-rtsp_transport udp_multicast -i rtsp://172.17.1.131/stream1m


Regards,
Marton





Regards,
Marton





Thanks,
Marton

  err = ff_rtsp_make_setup_request(s, host, port, 
lower_transport,

rt->server_type == RTSP_SERVER_REAL ?
real_challenge : NULL);





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

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

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

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



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

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

___

Re: [FFmpeg-devel] [PATCH] tests/fate/hlsenc: rename fate macro define from FATE_AFILTER to FATE_HLSENC

2020-04-20 Thread Steven Liu


> 2020年4月15日 下午2:58,Steven Liu  写道:
> 
> and add fate-hlsenc for test all of the testcase
> Signed-off-by: Steven Liu 
> ---
> tests/fate/hlsenc.mak | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak
> index ff58094252..43f93c8c5b 100644
> --- a/tests/fate/hlsenc.mak
> +++ b/tests/fate/hlsenc.mak
> @@ -5,7 +5,7 @@ tests/data/live_no_endlist.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | 
> tests/data
> -hls_flags omit_endlist -codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/live_no_endlist_%03d.ts \
> $(TARGET_PATH)/tests/data/live_no_endlist.m3u8 2>/dev/null
> 
> -FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-no-endlist
> +FATE_HLSENC-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-no-endlist
> fate-hls-live-no-endlist: tests/data/live_no_endlist.m3u8
> fate-hls-live-no-endlist: SRC = $(TARGET_PATH)/tests/data/live_no_endlist.m3u8
> fate-hls-live-no-endlist: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false 
> -t 6 -f s24le
> @@ -19,7 +19,7 @@ tests/data/live_last_endlist.m3u8: 
> ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
> -codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/live_last_endlist_%03d.ts \
> $(TARGET_PATH)/tests/data/live_last_endlist.m3u8 2>/dev/null
> 
> -FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-last-endlist
> +FATE_HLSENC-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-last-endlist
> fate-hls-live-last-endlist: tests/data/live_last_endlist.m3u8
> fate-hls-live-last-endlist: SRC = 
> $(TARGET_PATH)/tests/data/live_last_endlist.m3u8
> fate-hls-live-last-endlist: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false 
> -t 6 -f s24le
> @@ -34,7 +34,7 @@ tests/data/live_endlist.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | 
> tests/data
> -hls_list_size 0 -codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/live_endlist_%d.ts \
> $(TARGET_PATH)/tests/data/live_endlist.m3u8 2>/dev/null
> 
> -FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-endlist
> +FATE_HLSENC-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-endlist
> fate-hls-live-endlist: tests/data/live_endlist.m3u8
> fate-hls-live-endlist: SRC = $(TARGET_PATH)/tests/data/live_endlist.m3u8
> fate-hls-live-endlist: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false -t 
> 20 -f s24le
> @@ -48,7 +48,7 @@ tests/data/hls_segment_size.m3u8: 
> ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
>   -hls_list_size 0 -codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/hls_segment_size_%d.ts \
>   $(TARGET_PATH)/tests/data/hls_segment_size.m3u8 2>/dev/null
> 
> -FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-segment-size
> +FATE_HLSENC-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-segment-size
> fate-hls-segment-size: tests/data/hls_segment_size.m3u8
> fate-hls-segment-size: CMD = framecrc -flags +bitexact -i 
> $(TARGET_PATH)/tests/data/hls_segment_size.m3u8 -vf setpts=N*23
> 
> @@ -59,7 +59,7 @@ tests/data/hls_segment_single.m3u8: 
> ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
>   -hls_list_size 0 -codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/hls_segment_single.ts \
>   $(TARGET_PATH)/tests/data/hls_segment_single.m3u8 2>/dev/null
> 
> -FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-segment-single
> +FATE_HLSENC-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-segment-single
> fate-hls-segment-single: tests/data/hls_segment_single.m3u8
> fate-hls-segment-single: CMD = framecrc -flags +bitexact -i 
> $(TARGET_PATH)/tests/data/hls_segment_single.m3u8 -vf setpts=N*23
> 
> @@ -70,7 +70,7 @@ tests/data/hls_init_time.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | 
> tests/data
>   -hls_list_size 5 -codec:a mp2fixed -hls_segment_filename 
> $(TARGET_PATH)/tests/data/hls_init_time_%d.ts \
>   $(TARGET_PATH)/tests/data/hls_init_time.m3u8 2>/dev/null
> 
> -FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-init-time
> +FATE_HLSENC-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-init-time
> fate-hls-init-time: tests/data/hls_init_time.m3u8
> 

[FFmpeg-devel] [PATCH v2] lavf/tls_mbedtls: fix resource leak

2020-04-20 Thread Jun Zhao
From: Jun Zhao 

fix resource leak in mbedtls part.

fix #8614

Signed-off-by: Jun Zhao 
---
 libavformat/tls_mbedtls.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index 9b80a1e..965adf1 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -62,6 +62,7 @@ static int tls_close(URLContext *h)
 mbedtls_ctr_drbg_free(_ctx->ctr_drbg_context);
 mbedtls_entropy_free(_ctx->entropy_context);
 
+ffurl_closep(_ctx->tls_shared.tcp);
 return 0;
 }
 
-- 
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 v1] lavf/mp3enc: fix ID3v1 year metadata setting issue

2020-04-20 Thread Jun Zhao
From: Jun Zhao 

Follow the http://id3.org/ID3v1, setting the year metadata
for ID3v1.

fix #8623

Signed-off-by: Jun Zhao 
---
 libavformat/mp3enc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index 34b753f..157174f 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -45,6 +45,7 @@ static int id3v1_set_string(AVFormatContext *s, const char 
*key,
 return !!tag;
 }
 
+// refer to: http://id3.org/ID3v1
 static int id3v1_create_tag(AVFormatContext *s, uint8_t *buf)
 {
 AVDictionaryEntry *tag;
@@ -58,7 +59,7 @@ static int id3v1_create_tag(AVFormatContext *s, uint8_t *buf)
 count += id3v1_set_string(s, "TIT2",buf +  3, 30 + 1);   //title
 count += id3v1_set_string(s, "TPE1",buf + 33, 30 + 1);   
//author|artist
 count += id3v1_set_string(s, "TALB",buf + 63, 30 + 1);   //album
-count += id3v1_set_string(s, "TDRC",buf + 93,  4 + 1);   //date
+count += id3v1_set_string(s, "TYER",buf + 93,  4 + 1);   //year
 count += id3v1_set_string(s, "comment", buf + 97, 30 + 1);
 if ((tag = av_dict_get(s->metadata, "TRCK", NULL, 0))) { //track
 buf[125] = 0;
-- 
2.7.4

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/rtsp: fix rtsp multicasts

2020-04-20 Thread Marton Balint



On Mon, 20 Apr 2020, Wolfgang Haupt wrote:


On 19.04.20 23:43, Marton Balint wrote:



On Sun, 19 Apr 2020, Wolfgang Haupt wrote:


On 19.04.20 14:53, Marton Balint wrote:



On Sun, 19 Apr 2020, Wolfgang Haupt wrote:


ping

On 03.04.20 08:42, Wolfgang Haupt wrote:

Hey,

is someone up to review this patch?

It's an attempt to fix rtsp streams that use udp multicasts as the 
underlying

transmission protocol.
The idea was taken from live555 as the said stream worked in VLC.

It still applies cleanly on current master.


Best Regards,
Wolfgang

On 18.10.19 18:59, Wolfgang Haupt wrote:

If an rtsp server offers a udp multicast
address as response of a DESCRIBE command
the rtsp client is expected to issue
SETUP with "Transport: RTP/AVP/UDP;multicast".
Some rtsp servers bail out otherwise.
---
  libavformat/rtsp.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 859defa592..3f0cbfc98b 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1913,6 +1913,9 @@ redirect:
  && (rt->rtsp_flags & RTSP_FLAG_PREFER_TCP))
  lower_transport = RTSP_LOWER_TRANSPORT_TCP;
  +    if (ff_is_multicast_address((struct 
sockaddr*)>rtsp_streams[rt->nb_rtsp_streams-1]->sdp_ip))

+    lower_transport = RTSP_LOWER_TRANSPORT_UDP_MULTICAST;
+


Shouldn't this take into account lower_transport_mask? E.g. it 
should only prefer multicast if it is allowed in the mask?


Can you explain what the lower_transport_mask is about?
I cannot think of any case where you wouldn't want use udp multicast 
when the rtsp server gives you a mutlicast-ip

in response to a DESCRIBE request.


I am not familiar with the code, but it looks like it is used to 
control the allowed (tried) transport methods. The rtsp protocol has 
an rtsp_transport option, that is the source of the mask:

https://www.ffmpeg.org/ffmpeg-all.html#rtsp
If UDP multicast transport is disallowed because it is not in the mask 
then you should not set it as far as I see.


Mhm, yeah that's actually the problem I tried to fix.
Reading the docs again, I'm not sure if I missed it before, but the docs 
are stating:
Multiple lower transport protocols may be specified, in that case they 
are tried one at a time (if the setup of one fails, the next one is 
tried). For the muxer, only the ‘tcp’ and ‘udp’ options are supported.


Are you fixing the muxer or the demuxer? So are you reading via multicast 
or generating multicast?


However I still cannot manage to get udp + udp_multicast into the 
lower_transport_mask on the commandline, so I'm still not sure how/if 
it's possible to really set multiple protocols.


Why not? Isn't it just specifying -rtsp_transport +udp+udp_multicast ?

Therefore my patch always adds "udp_multicast" as lower_transport no 
matter what the lower_transport_mask is as soon as the DESCRIBE response 
returns a multicast IP, because
clients don't know when to set udp vs. udp_multicast as you can't know 
which stream you get.


That is why lower_transport is a mask, a combination of the possible 
values. And it looks like by default everything _is_ allowed.


Regards,
Marton





Regards,
Marton





Thanks,
Marton

  err = ff_rtsp_make_setup_request(s, host, port, 
lower_transport,
   rt->server_type == 
RTSP_SERVER_REAL ?

   real_challenge : NULL);





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

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

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

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



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

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

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

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



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

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

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

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

Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Don't free uninitialized AVBPrint

2020-04-20 Thread Marton Balint



On Mon, 20 Apr 2020, Andreas Rheinhardt wrote:


Fixes Coverity ID 1462307.

Signed-off-by: Andreas Rheinhardt 
---
I intend to apply this soon if there are no objections.

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

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 49f7644fab..0a6462000d 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2567,8 +2567,8 @@ static int rtp_read_header(AVFormatContext *s)
fail_nobuf:
ret = AVERROR(ENOMEM);
av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space for 
sdp-headers\n");
-fail:
av_bprint_finalize(, NULL);
+fail:
avcodec_parameters_free();
if (in)
ffurl_close(in);


LGTM thanks. I guess this rtsp fix has a series of bad luck :)

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

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

Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Put strings instead of pointers to strings into array

2020-04-20 Thread Marton Balint



On Mon, 20 Apr 2020, Andreas Rheinhardt wrote:


In this example, the difference in length between the shortest and
longest string is three, so that not using pointers to strings saves
space even on 32bit systems.

Moreover, there is no need to use a sentinel here; it can be replaced
with FF_ARRAY_ELEMS.

Signed-off-by: Andreas Rheinhardt 
---
I have to admit that this is untested.

libavformat/rtsp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 0a6462000d..b2b3f32011 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2526,10 +2526,11 @@ static int rtp_read_header(AVFormatContext *s)

p = strchr(s->url, '?');
if (p) {
-static const char *filters[][2] = {{"sources", "incl"}, {"block", 
"excl"}, {NULL, NULL}};
+static const char filters[][2][8] = { { "sources", "incl" },
+  { "block",   "excl" } };
int i;
char *q;
-for (i = 0; filters[i][0]; i++) {
+for (i = 0; i < FF_ARRAY_ELEMS(filters); i++) {
if (av_find_info_tag(filters_buf, sizeof(filters_buf), 
filters[i][0], p)) {
q = filters_buf;
while ((q = strchr(q, ',')) != NULL)


LGTM, thanks.

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

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

Re: [FFmpeg-devel] [PATCH v1] lavf/tls_mbedtls: fix resource leak

2020-04-20 Thread myp...@gmail.com
On Mon, Apr 20, 2020 at 3:05 PM Andreas Rheinhardt
 wrote:
>
> Jun Zhao:
> > From: Jun Zhao 
> >
> > fix resource leak in mbedtls part.
> >
> > fix #8614
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavformat/tls_mbedtls.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
> > index 9b80a1e..eb4b2a0 100644
> > --- a/libavformat/tls_mbedtls.c
> > +++ b/libavformat/tls_mbedtls.c
> > @@ -62,6 +62,8 @@ static int tls_close(URLContext *h)
> >  mbedtls_ctr_drbg_free(_ctx->ctr_drbg_context);
> >  mbedtls_entropy_free(_ctx->entropy_context);
> >
> > +if (tls_ctx->tls_shared.tcp)
> > +ffurl_close(tls_ctx->tls_shared.tcp);
> >  return 0;
> >  }
> >
> > You can simply use ffurl_closep() instead of these two lines.
>
Yes, will update the code,tks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 12/20] avformat/matroskaenc: Improve Cues in case of no video

2020-04-20 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> The Matroska muxer currently only adds CuePoints in three cases:
> a) For video keyframes. b) For the first audio frame in a new Cluster if
> in DASH-mode. c) For subtitles. This means that ordinary Matroska audio
> files won't have any Cues which impedes seeking.
> 
> This commit changes this. For every track in a file without video track
> it is checked and tracked whether a Cue entry has already been added
> for said track for the current Cluster. This is used to add a Cue entry
> for each first packet of each track in each Cluster.
> 
> Implements #3149.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/matroskaenc.c | 21 +++
>  tests/ref/fate/aac-autobsf-adtstoasc  |  4 ++--
>  tests/ref/fate/matroska-flac-extradata-update |  4 ++--
>  tests/ref/lavf/mka|  4 ++--
>  4 files changed, 18 insertions(+), 15 deletions(-)
> 
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index b9bfd34756..a469d48cc0 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2120,6 +2120,10 @@ static void mkv_end_cluster(AVFormatContext *s)
>  MatroskaMuxContext *mkv = s->priv_data;
>  
>  end_ebml_master_crc32(s->pb, >cluster_bc, mkv, MATROSKA_ID_CLUSTER, 
> 0, 1);
> +if (!mkv->have_video) {
> +for (unsigned i = 0; i < s->nb_streams; i++)
> +mkv->tracks[i].has_cue = 0;
> +}
>  mkv->cluster_pos = -1;
>  avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_FLUSH_POINT);
>  }
> @@ -,7 +2226,7 @@ static int mkv_check_new_extra_data(AVFormatContext *s, 
> AVPacket *pkt)
>  return 0;
>  }
>  
> -static int mkv_write_packet_internal(AVFormatContext *s, AVPacket *pkt, int 
> add_cue)
> +static int mkv_write_packet_internal(AVFormatContext *s, AVPacket *pkt)
>  {
>  MatroskaMuxContext *mkv = s->priv_data;
>  AVIOContext *pb;
> @@ -2268,10 +2272,12 @@ static int mkv_write_packet_internal(AVFormatContext 
> *s, AVPacket *pkt, int add_
>  ret = mkv_write_block(s, pb, MATROSKA_ID_SIMPLEBLOCK, pkt, keyframe);
>  if (ret < 0)
>  return ret;
> -if ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) && (par->codec_type == 
> AVMEDIA_TYPE_VIDEO && keyframe || add_cue)) {
> +if ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) && keyframe &&
> +(par->codec_type == AVMEDIA_TYPE_VIDEO || !mkv->have_video && 
> !track->has_cue)) {
>  ret = mkv_add_cuepoint(mkv, pkt->stream_index, ts,
> mkv->cluster_pos, relative_packet_pos, 
> -1);
>  if (ret < 0) return ret;
> +track->has_cue = 1;
>  }
>  } else {
>  if (par->codec_id == AV_CODEC_ID_WEBVTT) {
> @@ -2336,8 +2342,7 @@ static int mkv_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  // on seeing key frames.
>  start_new_cluster = keyframe;
>  } else if (mkv->is_dash && codec_type == AVMEDIA_TYPE_AUDIO &&
> -   (mkv->cluster_pos == -1 ||
> -cluster_time > mkv->cluster_time_limit)) {
> +   cluster_time > mkv->cluster_time_limit) {
>  // For DASH audio, we create a Cluster based on cluster_time_limit
>  start_new_cluster = 1;
>  } else if (!mkv->is_dash &&
> @@ -2361,9 +2366,7 @@ static int mkv_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  
>  // check if we have an audio packet cached
>  if (mkv->cur_audio_pkt.size > 0) {
> -// for DASH audio, a CuePoint has to be added when there is a new 
> cluster.
> -ret = mkv_write_packet_internal(s, >cur_audio_pkt,
> -mkv->is_dash ? start_new_cluster : 
> 0);
> +ret = mkv_write_packet_internal(s, >cur_audio_pkt);
>  av_packet_unref(>cur_audio_pkt);
>  if (ret < 0) {
>  av_log(s, AV_LOG_ERROR,
> @@ -2378,7 +2381,7 @@ static int mkv_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  if (pkt->size > 0)
>  ret = av_packet_ref(>cur_audio_pkt, pkt);
>  } else
> -ret = mkv_write_packet_internal(s, pkt, 0);
> +ret = mkv_write_packet_internal(s, pkt);
>  return ret;
>  }
>  
> @@ -2406,7 +2409,7 @@ static int mkv_write_trailer(AVFormatContext *s)
>  
>  // check if we have an audio packet cached
>  if (mkv->cur_audio_pkt.size > 0) {
> -ret = mkv_write_packet_internal(s, >cur_audio_pkt, 0);
> +ret = mkv_write_packet_internal(s, >cur_audio_pkt);
>  if (ret < 0) {
>  av_log(s, AV_LOG_ERROR,
> "Could not write cached audio packet ret:%d\n", ret);
> diff --git a/tests/ref/fate/aac-autobsf-adtstoasc 
> b/tests/ref/fate/aac-autobsf-adtstoasc
> index f1c6f889d4..d9191fb37f 100644
> --- a/tests/ref/fate/aac-autobsf-adtstoasc
> +++ b/tests/ref/fate/aac-autobsf-adtstoasc
> @@ -1,5 +1,5 @@
> -9d0c81ce285a84c0137316004d091d95 
> 

Re: [FFmpeg-devel] [PATCH v1] lavf/tls_mbedtls: fix resource leak

2020-04-20 Thread Andreas Rheinhardt
Jun Zhao:
> From: Jun Zhao 
> 
> fix resource leak in mbedtls part.
> 
> fix #8614
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/tls_mbedtls.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
> index 9b80a1e..eb4b2a0 100644
> --- a/libavformat/tls_mbedtls.c
> +++ b/libavformat/tls_mbedtls.c
> @@ -62,6 +62,8 @@ static int tls_close(URLContext *h)
>  mbedtls_ctr_drbg_free(_ctx->ctr_drbg_context);
>  mbedtls_entropy_free(_ctx->entropy_context);
>  
> +if (tls_ctx->tls_shared.tcp)
> +ffurl_close(tls_ctx->tls_shared.tcp);
>  return 0;
>  }
>  
> You can simply use ffurl_closep() instead of these two lines.

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

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

[FFmpeg-devel] [PATCH v1] lavf/tls_mbedtls: fix resource leak

2020-04-20 Thread Jun Zhao
From: Jun Zhao 

fix resource leak in mbedtls part.

fix #8614

Signed-off-by: Jun Zhao 
---
 libavformat/tls_mbedtls.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index 9b80a1e..eb4b2a0 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -62,6 +62,8 @@ static int tls_close(URLContext *h)
 mbedtls_ctr_drbg_free(_ctx->ctr_drbg_context);
 mbedtls_entropy_free(_ctx->entropy_context);
 
+if (tls_ctx->tls_shared.tcp)
+ffurl_close(tls_ctx->tls_shared.tcp);
 return 0;
 }
 
-- 
2.7.4

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/rtsp: fix rtsp multicasts

2020-04-20 Thread Wolfgang Haupt

On 19.04.20 23:43, Marton Balint wrote:



On Sun, 19 Apr 2020, Wolfgang Haupt wrote:


On 19.04.20 14:53, Marton Balint wrote:



On Sun, 19 Apr 2020, Wolfgang Haupt wrote:


ping

On 03.04.20 08:42, Wolfgang Haupt wrote:

Hey,

is someone up to review this patch?

It's an attempt to fix rtsp streams that use udp multicasts as the 
underlying

transmission protocol.
The idea was taken from live555 as the said stream worked in VLC.

It still applies cleanly on current master.


Best Regards,
Wolfgang

On 18.10.19 18:59, Wolfgang Haupt wrote:

If an rtsp server offers a udp multicast
address as response of a DESCRIBE command
the rtsp client is expected to issue
SETUP with "Transport: RTP/AVP/UDP;multicast".
Some rtsp servers bail out otherwise.
---
  libavformat/rtsp.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 859defa592..3f0cbfc98b 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1913,6 +1913,9 @@ redirect:
  && (rt->rtsp_flags & RTSP_FLAG_PREFER_TCP))
  lower_transport = RTSP_LOWER_TRANSPORT_TCP;
  +    if (ff_is_multicast_address((struct 
sockaddr*)>rtsp_streams[rt->nb_rtsp_streams-1]->sdp_ip))

+    lower_transport = RTSP_LOWER_TRANSPORT_UDP_MULTICAST;
+


Shouldn't this take into account lower_transport_mask? E.g. it 
should only prefer multicast if it is allowed in the mask?


Can you explain what the lower_transport_mask is about?
I cannot think of any case where you wouldn't want use udp multicast 
when the rtsp server gives you a mutlicast-ip

in response to a DESCRIBE request.


I am not familiar with the code, but it looks like it is used to 
control the allowed (tried) transport methods. The rtsp protocol has 
an rtsp_transport option, that is the source of the mask:

https://www.ffmpeg.org/ffmpeg-all.html#rtsp
If UDP multicast transport is disallowed because it is not in the mask 
then you should not set it as far as I see.


Mhm, yeah that's actually the problem I tried to fix.
Reading the docs again, I'm not sure if I missed it before, but the docs 
are stating:
Multiple lower transport protocols may be specified, in that case they 
are tried one at a time (if the setup of one fails, the next one is 
tried). For the muxer, only the ‘tcp’ and ‘udp’ options are supported.


However I still cannot manage to get udp + udp_multicast into the 
lower_transport_mask on the commandline, so I'm still not sure how/if 
it's possible to really set multiple protocols.
Therefore my patch always adds "udp_multicast" as lower_transport no 
matter what the lower_transport_mask is as soon as the DESCRIBE response 
returns a multicast IP, because
clients don't know when to set udp vs. udp_multicast as you can't know 
which stream you get.




Regards,
Marton





Thanks,
Marton

  err = ff_rtsp_make_setup_request(s, host, port, 
lower_transport,
   rt->server_type == 
RTSP_SERVER_REAL ?

   real_challenge : NULL);





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

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

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

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



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

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

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