Re: [FFmpeg-devel] [PATCH v1 1/3] libavformat/rtsp.h : Add member ignore_rtcp to RTSPState

[Minlei Sun]

Thanks, Moritz.

I will submit a new patch in order to update doc/protocols.texi, this is my 
oversight.

Regarding "ignore_rtcp" flag, it is turned off by default. When some devices 
(such as hikvision iSecure Center Platform v1.3.xxx) rtsp stream contains rtcp 
data packets (may be non-standard), there will be a freeze when the output is 
rtmp stream.
So when "igore_rtcp" is enabled, this situation can be solved.


___
ffmpeg-devel mailing list
ffmpeg-devel@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] doc/protocols.texi : Add ignore_rtcp option in rtsp section

[sunml]

From: Minlei Sun 

Signed-off-by: Minlei Sun 
---
 doc/protocols.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a6e46b99ad..604d42b693 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1188,6 +1188,9 @@ libavformat identifier string.
 @item user_agent
 Override User-Agent header. If not specified, it defaults to the
 libavformat identifier string.
+
+@item ignore_rtcp
+Ignore rtcp packets in rtsp stream to avoid transcoding stuck. Default valule 
is 0.
 @end table
 
 When receiving data over UDP, the demuxer tries to reorder received packets
-- 
2.24.3 (Apple Git-128)

___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavutil: additional side_data accessor

[Brad Hards]

The existing function allows access the first instance of a given
type. Mostly that is OK, but some types can occur multiple times
(e.g. libx264 can write version info, VANC and UMID related data as
user data unregistered SEI.

This adds API to access additional instances of a given SEI type.
---
 libavutil/frame.c | 19 +++
 libavutil/frame.h | 20 
 2 files changed, 39 insertions(+)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 31a2117b82..662fcfd452 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -748,6 +748,25 @@ AVFrameSideData *av_frame_get_side_data(const AVFrame 
*frame,
 return NULL;
 }
 
+AVFrameSideData *av_frame_get_side_data_n(const AVFrame *frame,
+  enum AVFrameSideDataType type,
+  const int side_data_instance)
+{
+int i;
+int n = 0;
+
+for (i = 0; i < frame->nb_side_data; i++) {
+if (frame->side_data[i]->type == type) {
+if (n == side_data_instance) {
+return frame->side_data[i];
+} else {
+n++;
+}
+}
+}
+return NULL;
+}
+
 static int frame_copy_video(AVFrame *dst, const AVFrame *src)
 {
 const uint8_t *src_data[4];
diff --git a/libavutil/frame.h b/libavutil/frame.h
index a5ed91b20a..76dd14cbd5 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -943,12 +943,32 @@ AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame 
*frame,
  AVBufferRef *buf);
 
 /**
+ * Find the first instance of side data of a given type.
+ *
+ * @param frame a frame to find the side data in
+ * @param type type of the side data to find
+ *
  * @return a pointer to the side data of a given type on success, NULL if there
  * is no side data with such type in this frame.
  */
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
 enum AVFrameSideDataType type);
 
+/**
+ * Find a specified instance of side data of a given type.
+ *
+ * @param frame a frame to find the side data in
+ * @param type type of the side data to find
+ * @param side_data_instance instance of the side data to return (0 base).
+ *
+ * @return a pointer to the n'th instance of side data of a given type on
+ * success, NULL if there are less than side_data_instance instances of the
+ * given type.
+ */
+AVFrameSideData *av_frame_get_side_data_n(const AVFrame *frame,
+  enum AVFrameSideDataType type,
+  const int side_data_instance);
+
 /**
  * Remove and free all side data instances of the given type.
  */
-- 
2.27.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] libavutil: additional side_data accessor

[Nicolas George]

Brad Hards (12021-04-20):
> The existing function allows access the first instance of a given
> type. Mostly that is OK, but some types can occur multiple times
> (e.g. libx264 can write version info, VANC and UMID related data as
> user data unregistered SEI.
> 
> This adds API to access additional instances of a given SEI type.
> ---
>  libavutil/frame.c | 19 +++
>  libavutil/frame.h | 20 
>  2 files changed, 39 insertions(+)

IIRC, there was a discussion a long time ago that concluded that
multiple instances of the same side data should not happen.

Somebody remembers it?

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH] Gsoc: add the two fuzzy targets

[Michael Niedermayer]

On Tue, Apr 20, 2021 at 12:34:13PM +0800, Heng Zhang wrote:
> 
> 
> > 在 2021年4月19日，下午5:47，Michael Niedermayer  写道：
> > 
> > On Mon, Apr 19, 2021 at 05:06:10PM +0800, a397341...@163.com 
> >  wrote:
> >> From: toseven 
[...]
> >> +if (ret < 0)
> >> +{
> >> +fprintf(stderr, "Error occurred in av_packet_add_side_data: %s\n",
> >> +av_err2str(ret));
> >> +}
> >> +return ret;
> > 
> > the { } placing style mismatches whats used in FFmpeg (i dont mind but some 
> > people do mind)
> > 
> > more general, how much code coverage is gained with these 2 fuzzers 
> > compared to what already exists ?
> > 
> > thanks
> 
> Okay, I will modify my style to adopt for FFmpeg. What is more, I didn’t 
> compare the code coverage between them. Do I have to do this?  I mainly refer 
> to the fate test from libavcodec/tests/avpacket.c and 
> libavfilter/tests/formats.c.

If code coverage does not improve, what would be the reason for FFmpeg to
include the code ?

Thanks

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

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

Re: [FFmpeg-devel] [PATCH v3 1/1] avformat/mpegtsenc: Write necessary descriptors into PMT for arib_caption muxing

[zheng qian]

On Tue, Apr 20, 2021 at 6:46 AM Jan Ekström  wrote:
>
> On Tue, Apr 20, 2021 at 12:11 AM Marton Balint  wrote:
> >
> >
> >
> > On Mon, 19 Apr 2021, zheng qian wrote:
> >
> > > Is there anyone who could review this patch?
> >
> > Jan was interested in this, so preferably he should also comment, but it
> > looks fine to me.
> >
>
> OK, this explains why I didn't see my response on patchwork.
> Apparently he had CC'd me and thus the "reply" button in gmail sent an
> e-mail directly to him and I was hurrying due to being on a lunch
> break -_- (and thus didn't notice).
>
> In any case, I did some comments and am now waiting for a second
> opinion regarding the usage of stream_identifiers in the ARIB context.
> After all, the specifications do let one utilize 0x30-0x37 for profile
> A/full-seg ARIB captions, so there must be a reason for them to not be
> as limited as profile C/1seg to a single identifier :)
>

I've found related definitions in ARIB TR-B14, Fascicle 1, 4.2.8.1
and you can find it in
http://web.archive.org/web/20160319090430/http://arib.or.jp/english/html/overview/doc/8-TR-B14v2_8-1p3-2-E2.pdf

4.2.8.1 section says:
"However, for component tag values of default ES of caption,
set 0x30 or 0x87, for component tag value of default ES of
superimpose, set 0x38 or 0x88."

That means 0x30 is considered as the default value for
Profile A caption ES. The section didn't describe how to
utilize other values rather than 0x30 in the 0x30~0x37 range,
and due to the second language caption is designed to be
multiplexed in the same ES, seems that it's assumed that
there will be usually only one ARIB caption within a program.

Anyway, I have never seen a TS program that carries 2 or more
arib_caption streams among Japanese TV channels.
Even if we manually try to remux 2 or more arib_caption streams
into a TS program and both use the component tag of 0x30,
it shouldn't cause any playback problems.

Best regards,
zheng qian

> 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 mailing list
ffmpeg-devel@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] libavutil: additional side_data accessor

[James Almer]

On 4/20/2021 7:10 AM, Nicolas George wrote:

Brad Hards (12021-04-20):

The existing function allows access the first instance of a given
type. Mostly that is OK, but some types can occur multiple times
(e.g. libx264 can write version info, VANC and UMID related data as
user data unregistered SEI.

This adds API to access additional instances of a given SEI type.
---
  libavutil/frame.c | 19 +++
  libavutil/frame.h | 20 
  2 files changed, 39 insertions(+)


IIRC, there was a discussion a long time ago that concluded that
multiple instances of the same side data should not happen.

Somebody remembers it?


I recall long ago i tried to make av_frame_new_side_data() replace the 
existing element if it found one, effectively limiting side data to one 
per type and copying the behavior of packet side data, but it was 
rejected as it was argued more than one per type had some use. And 
seeing that now decoders like h264 may attach more than one element of 
AV_FRAME_DATA_SEI_UNREGISTERED type as contained inside the bitstream 
AUs, it may be a good idea for it to be supported officially with our 
accessors (Right now you need to manually traverse the side data array 
to find all instances of a given type).




Regards,


___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavutil: additional side_data accessor

[Nicolas George]

James Almer (12021-04-20):
> I recall long ago i tried to make av_frame_new_side_data() replace the
> existing element if it found one, effectively limiting side data to one per
> type and copying the behavior of packet side data, but it was rejected as it
> was argued more than one per type had some use. And seeing that now decoders
> like h264 may attach more than one element of AV_FRAME_DATA_SEI_UNREGISTERED
> type as contained inside the bitstream AUs, it may be a good idea for it to
> be supported officially with our accessors (Right now you need to manually
> traverse the side data array to find all instances of a given type).

Thanks for the clarification, I remembered it backwards.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH 69/87] avutil/pixdesc: Remove deprecated AV_PIX_FMT_FLAG_PSEUDOPAL

[Michael Niedermayer]

On Mon, Apr 19, 2021 at 11:10:06AM -0300, James Almer wrote:
> From: Andreas Rheinhardt 
> 
> Deprecated in d6fc031caf64eed921bbdef86d79d56bfc2633b0.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/decode.c  |  5 +
>  libavcodec/ffv1dec.c |  3 +--
>  libavcodec/rawdec.c  | 17 +
>  libavfilter/drawutils.c  |  2 +-
>  libavfilter/framepool.c  |  6 ++
>  libavfilter/vf_crop.c|  2 +-
>  libavfilter/vf_pixdesctest.c |  3 +--
>  libavfilter/vf_scale.c   |  3 +--
>  libavfilter/vf_untile.c  |  2 +-
>  libavutil/frame.c|  2 +-
>  libavutil/imgutils.c | 15 ---
>  libavutil/internal.h |  9 -
>  libavutil/pixdesc.c  |  9 -
>  libavutil/pixdesc.h  | 20 
>  libavutil/version.h  |  3 ---
>  tests/ref/fate/imgutils  | 10 +-
>  16 files changed, 28 insertions(+), 83 deletions(-)

breaks:
./ffmpeg -i ticket/3933/128.jls

  libswscale  5. 10.100 /  5. 10.100
  libswresample   3. 10.100 /  3. 10.100
  libpostproc55. 10.100 / 55. 10.100
==30215== Invalid write of size 4
==30215==at 0x9D4457: ff_jpegls_decode_lse (jpeglsdec.c:130)
==30215==by 0xA26145: ff_mjpeg_receive_frame (mjpegdec.c:2542)
==30215==by 0x85A2B9: decode_receive_frame_internal (decode.c:527)
==30215==by 0x85A565: avcodec_send_packet (decode.c:593)
==30215==by 0x70F684: try_decode_frame (utils.c:3072)
==30215==by 0x712CF4: avformat_find_stream_info (utils.c:3923)
==30215==by 0x22D58A: open_input_file (ffmpeg_opt.c:1198)
==30215==by 0x23C0C0: open_files (ffmpeg_opt.c:3340)
==30215==by 0x23C274: ffmpeg_parse_options (ffmpeg_opt.c:3380)
==30215==by 0x25BA4E: main (ffmpeg.c:4991)
==30215==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==30215== 
==30215== 
==30215== Process terminating with default action of signal 11 (SIGSEGV)
==30215==  Access not within mapped region at address 0x0
==30215==at 0x9D4457: ff_jpegls_decode_lse (jpeglsdec.c:130)
==30215==by 0xA26145: ff_mjpeg_receive_frame (mjpegdec.c:2542)
==30215==by 0x85A2B9: decode_receive_frame_internal (decode.c:527)
==30215==by 0x85A565: avcodec_send_packet (decode.c:593)
==30215==by 0x70F684: try_decode_frame (utils.c:3072)
==30215==by 0x712CF4: avformat_find_stream_info (utils.c:3923)
==30215==by 0x22D58A: open_input_file (ffmpeg_opt.c:1198)
==30215==by 0x23C0C0: open_files (ffmpeg_opt.c:3340)
==30215==by 0x23C274: ffmpeg_parse_options (ffmpeg_opt.c:3380)
==30215==by 0x25BA4E: main (ffmpeg.c:4991)
==30215==  If you believe this happened as a result of a stack
==30215==  overflow in your program's main thread (unlikely but
==30215==  possible), you can try to increase the size of the
==30215==  main thread stack using the --main-stacksize= flag.
==30215==  The main thread stack size used in this run was 8388608.
==30215== 

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

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


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

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

Re: [FFmpeg-devel] [PATCH v1] doc/protocols.texi : Add ignore_rtcp option in rtsp section

[Gyan Doshi]

On 2021-04-20 13:35, su...@epoint.com.cn wrote:

From: Minlei Sun 

Signed-off-by: Minlei Sun 
---
  doc/protocols.texi | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a6e46b99ad..604d42b693 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1188,6 +1188,9 @@ libavformat identifier string.
  @item user_agent
  Override User-Agent header. If not specified, it defaults to the
  libavformat identifier string.
+
+@item ignore_rtcp
+Ignore rtcp packets in rtsp stream to avoid transcoding stuck. Default valule 
is 0.
  @end table


Where do you see this option?

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

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

[FFmpeg-devel] [PATCH v2 28/90] avcodec: Remove deprecated old aliases for NVENC encoders

[Andreas Rheinhardt]

Deprecated in 888a5c794778a2f2aad22e9b4a3952dff92b11fa.

Signed-off-by: Andreas Rheinhardt 
---
Now also removing the configure and Makefile entries for the removed
encoders.

 configure   |  3 --
 libavcodec/Makefile |  3 --
 libavcodec/allcodecs.c  |  6 
 libavcodec/nvenc_h264.c | 69 -
 libavcodec/nvenc_hevc.c | 37 --
 libavcodec/version.h|  3 --
 6 files changed, 121 deletions(-)

diff --git a/configure b/configure
index cc1013fb1d..9cc9fa7816 100755
--- a/configure
+++ b/configure
@@ -3064,7 +3064,6 @@ overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 amf_deps_any="libdl LoadLibrary"
 nvenc_deps="ffnvcodec"
 nvenc_deps_any="libdl LoadLibrary"
-nvenc_encoder_deps="nvenc"
 
 aac_mf_encoder_deps="mediafoundation"
 ac3_mf_encoder_deps="mediafoundation"
@@ -3132,8 +3131,6 @@ mpeg4_omx_encoder_deps="omx"
 mpeg4_v4l2m2m_decoder_deps="v4l2_m2m mpeg4_v4l2_m2m"
 mpeg4_v4l2m2m_encoder_deps="v4l2_m2m mpeg4_v4l2_m2m"
 msmpeg4_crystalhd_decoder_select="crystalhd"
-nvenc_h264_encoder_select="h264_nvenc_encoder"
-nvenc_hevc_encoder_select="hevc_nvenc_encoder"
 vc1_crystalhd_decoder_select="crystalhd"
 vc1_cuvid_decoder_deps="cuvid"
 vc1_mmal_decoder_deps="mmal"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 31b220025b..2539839528 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -373,8 +373,6 @@ OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_H264_MF_ENCODER) += mfenc.o mf_utils.o
 OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
 OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
-OBJS-$(CONFIG_NVENC_ENCODER)   += nvenc_h264.o
-OBJS-$(CONFIG_NVENC_H264_ENCODER)  += nvenc_h264.o
 OBJS-$(CONFIG_H264_OMX_ENCODER)+= omx.o
 OBJS-$(CONFIG_H264_QSV_DECODER)+= qsvdec.o
 OBJS-$(CONFIG_H264_QSV_ENCODER)+= qsvenc_h264.o
@@ -395,7 +393,6 @@ OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuviddec.o
 OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_HEVC_MF_ENCODER) += mfenc.o mf_utils.o
 OBJS-$(CONFIG_HEVC_NVENC_ENCODER)  += nvenc_hevc.o
-OBJS-$(CONFIG_NVENC_HEVC_ENCODER)  += nvenc_hevc.o
 OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec.o
 OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o hevc_ps_enc.o   \
   hevc_data.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 3194232500..cf6fe2055b 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -27,7 +27,6 @@
 #include "config.h"
 #include "libavutil/thread.h"
 #include "avcodec.h"
-#include "version.h"
 
 extern AVCodec ff_a64multi_encoder;
 extern AVCodec ff_a64multi5_encoder;
@@ -796,11 +795,6 @@ extern AVCodec ff_h264_qsv_encoder;
 extern AVCodec ff_h264_v4l2m2m_encoder;
 extern AVCodec ff_h264_vaapi_encoder;
 extern AVCodec ff_h264_videotoolbox_encoder;
-#if FF_API_NVENC_OLD_NAME
-extern AVCodec ff_nvenc_encoder;
-extern AVCodec ff_nvenc_h264_encoder;
-extern AVCodec ff_nvenc_hevc_encoder;
-#endif
 extern AVCodec ff_hevc_amf_encoder;
 extern AVCodec ff_hevc_cuvid_decoder;
 extern AVCodec ff_hevc_mediacodec_decoder;
diff --git a/libavcodec/nvenc_h264.c b/libavcodec/nvenc_h264.c
index 4c2585876e..ea7390cbf1 100644
--- a/libavcodec/nvenc_h264.c
+++ b/libavcodec/nvenc_h264.c
@@ -198,75 +198,6 @@ static const AVCodecDefault defaults[] = {
 { NULL },
 };
 
-#if FF_API_NVENC_OLD_NAME
-
-static av_cold int nvenc_old_init(AVCodecContext *avctx)
-{
-av_log(avctx, AV_LOG_WARNING, "This encoder is deprecated, use 
'h264_nvenc' instead\n");
-return ff_nvenc_encode_init(avctx);
-}
-
-#if CONFIG_NVENC_ENCODER
-static const AVClass nvenc_class = {
-.class_name = "nvenc",
-.item_name = av_default_item_name,
-.option = options,
-.version = LIBAVUTIL_VERSION_INT,
-};
-
-AVCodec ff_nvenc_encoder = {
-.name   = "nvenc",
-.long_name  = NULL_IF_CONFIG_SMALL("NVIDIA NVENC H.264 encoder"),
-.type   = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_H264,
-.init   = nvenc_old_init,
-.receive_packet = ff_nvenc_receive_packet,
-.close  = ff_nvenc_encode_close,
-.flush  = ff_nvenc_encode_flush,
-.priv_data_size = sizeof(NvencContext),
-.priv_class = &nvenc_class,
-.defaults   = defaults,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_HARDWARE |
-  AV_CODEC_CAP_ENCODER_FLUSH,
-.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
-.pix_fmts   = ff_nvenc_pix_fmts,
-.wrapper_name   = "nvenc",
-.hw_configs = ff_nvenc_hw_configs,
-};
-#endif
-
-/* Add an alias for nvenc_h264 */
-#if CONFIG_NVENC_H264_ENCODER
-static const AVClass nvenc_h264_class = {
-.class_name = "nvenc_h264",
-.item_name = av_default_item_name,
-.option = options,
-.version = LIBAVUTIL_VERSION_INT,
-};
-
-AVCodec ff_nvenc_h264_encoder = {
-.name   

Re: [FFmpeg-devel] [PATCH 1/6] avformat/cafdec: Check channels

[Michael Niedermayer]

On Sun, Apr 11, 2021 at 12:24:41AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -1184429040541376544 * 32 cannot be 
> represented in type 'long'
> Fixes: 
> 31788/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-6236746338664448
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/cafdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply patchset

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

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

Re: [FFmpeg-devel] [PATCH 2/6] Execure whole size check earlier for rv20

[Andreas Rheinhardt]

Michael Niedermayer:
> Fixes: Timeout
> Fixes: 
> 31380/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV20_fuzzer-5230899257016320
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/rv10.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
> index bd70689cab..9c3a48c251 100644
> --- a/libavcodec/rv10.c
> +++ b/libavcodec/rv10.c
> @@ -154,7 +154,7 @@ static int rv10_decode_picture_header(MpegEncContext *s)
>  return mb_count;
>  }
>  
> -static int rv20_decode_picture_header(RVDecContext *rv)
> +static int rv20_decode_picture_header(RVDecContext *rv, int whole_size)
>  {
>  MpegEncContext *s = &rv->m;
>  int seq, mb_pos, i, ret;
> @@ -232,6 +232,10 @@ static int rv20_decode_picture_header(RVDecContext *rv)
> "attempting to change resolution to %dx%d\n", new_w, 
> new_h);
>  if (av_image_check_size(new_w, new_h, 0, s->avctx) < 0)
>  return AVERROR_INVALIDDATA;
> +
> +if (whole_size < (new_w + 15)/16 * ((new_h + 15)/16) / 8)
> +return AVERROR_INVALIDDATA;
> +
>  ff_mpv_common_end(s);
>  
>  // attempt to keep aspect during typical resolution switches
> @@ -447,7 +451,7 @@ static int rv10_decode_packet(AVCodecContext *avctx, 
> const uint8_t *buf,
>  if (s->codec_id == AV_CODEC_ID_RV10)
>  mb_count = rv10_decode_picture_header(s);
>  else
> -mb_count = rv20_decode_picture_header(rv);
> +mb_count = rv20_decode_picture_header(rv, whole_size);
>  if (mb_count < 0) {
>  if (mb_count != ERROR_SKIP_FRAME)
>  av_log(s->avctx, AV_LOG_ERROR, "HEADER ERROR\n");
> 
Typo: Execute.

- 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 v2 33/90] avformat: Constify the API wrt AV(In|Out)putFormat

[Andreas Rheinhardt]

Also constify AVProbeData.

Signed-off-by: Andreas Rheinhardt 
---
v1 forgot to update doc/examples.

 doc/APIchanges   | 10 
 doc/examples/muxing.c|  2 +-
 doc/examples/remuxing.c  |  2 +-
 fftools/ffmpeg_opt.c | 12 +
 fftools/ffplay.c |  7 ++---
 fftools/ffprobe.c|  2 +-
 libavdevice/internal.h   |  2 +-
 libavdevice/utils.c  |  2 +-
 libavfilter/lavfutils.c  |  2 +-
 libavfilter/src_movie.c  |  2 +-
 libavformat/avformat.h   | 44 ++--
 libavformat/avidec.c |  2 +-
 libavformat/dashdec.c|  2 +-
 libavformat/fifo.c   |  4 +--
 libavformat/format.c | 33 
 libavformat/hdsenc.c |  2 +-
 libavformat/hls.c|  2 +-
 libavformat/hlsenc.c |  4 +--
 libavformat/mpeg.c   |  2 +-
 libavformat/mux.c|  2 +-
 libavformat/rtpdec_asf.c |  2 +-
 libavformat/rtpenc_chain.c   |  2 +-
 libavformat/rtpenc_mpegts.c  |  4 +--
 libavformat/sapdec.c |  2 +-
 libavformat/segment.c|  2 +-
 libavformat/smoothstreamingenc.c |  2 +-
 libavformat/utils.c  |  2 +-
 libavformat/version.h|  3 ---
 libavformat/webm_chunk.c |  2 +-
 29 files changed, 83 insertions(+), 78 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index cd3ea3c865..e9fa7ddf64 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -17,6 +17,16 @@ API changes, most recent first:
 2021-04-17 - xx - lavu 56.73.100 - frame.h detection_bbox.h
   Add AV_FRAME_DATA_DETECTION_BBOXES
 
+2021-04-14 - xx - lavf y - avformat.h
+  Constified the pointers to AVInputFormats and AVOutputFormats
+  in AVFormatContext, avformat_alloc_output_context2(),
+  av_find_input_format(), av_probe_input_format(),
+  av_probe_input_format2(), av_probe_input_format3(),
+  av_probe_input_buffer2(), av_probe_input_buffer(),
+  avformat_open_input(), av_guess_format() and av_guess_codec().
+  Furthermore, constified the AVProbeData in av_probe_input_format(),
+  av_probe_input_format2() and av_probe_input_format3().
+
 2021-04-06 - xx - lavf 58.78.100 - avformat.h
   Add avformat_index_get_entries_count(), avformat_index_get_entry(),
   and avformat_index_get_entry_from_timestamp().
diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 42f704c258..014359e2ca 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -536,8 +536,8 @@ static void close_stream(AVFormatContext *oc, OutputStream 
*ost)
 int main(int argc, char **argv)
 {
 OutputStream video_st = { 0 }, audio_st = { 0 };
+const AVOutputFormat *fmt;
 const char *filename;
-AVOutputFormat *fmt;
 AVFormatContext *oc;
 AVCodec *audio_codec, *video_codec;
 int ret;
diff --git a/doc/examples/remuxing.c b/doc/examples/remuxing.c
index 9e4d1031b4..13313a1748 100644
--- a/doc/examples/remuxing.c
+++ b/doc/examples/remuxing.c
@@ -45,7 +45,7 @@ static void log_packet(const AVFormatContext *fmt_ctx, const 
AVPacket *pkt, cons
 
 int main(int argc, char **argv)
 {
-AVOutputFormat *ofmt = NULL;
+const AVOutputFormat *ofmt = NULL;
 AVFormatContext *ifmt_ctx = NULL, *ofmt_ctx = NULL;
 AVPacket pkt;
 const char *in_filename, *out_filename;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 807e783422..9e26de5a94 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1068,7 +1068,7 @@ static int open_input_file(OptionsContext *o, const char 
*filename)
 {
 InputFile *f;
 AVFormatContext *ic;
-AVInputFormat *file_iformat = NULL;
+const AVInputFormat *file_iformat = NULL;
 int err, i, ret;
 int64_t timestamp;
 AVDictionary *unused_opts = NULL;
@@ -1117,20 +1117,22 @@ static int open_input_file(OptionsContext *o, const 
char *filename)
 av_dict_set_int(&o->g->format_opts, "sample_rate", 
o->audio_sample_rate[o->nb_audio_sample_rate - 1].u.i, 0);
 }
 if (o->nb_audio_channels) {
+const AVClass *priv_class;
 /* because we set audio_channels based on both the "ac" and
  * "channel_layout" options, we need to check that the specified
  * demuxer actually has the "channels" option before setting it */
-if (file_iformat && file_iformat->priv_class &&
-av_opt_find(&file_iformat->priv_class, "channels", NULL, 0,
+if (file_iformat && (priv_class = file_iformat->priv_class) &&
+av_opt_find(&priv_class, "channels", NULL, 0,
 AV_OPT_SEARCH_FAKE_OBJ)) {
 av_dict_set_int(&o->g->format_opts, "channels", 
o->audio_channels[o->nb_audio_channels - 1].u.i, 0);
 }
 }
 if (o->nb_frame_rates) {
+const AVClass *priv_class;
 /* set the format-level framerate option;
  * this is important for video grab

Re: [FFmpeg-devel] [PATCH] avcodec/jpeglsdec: Don't allocate+free JPEGLSState for every frame

[Michael Niedermayer]

On Wed, Apr 14, 2021 at 11:21:40PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/jpeglsdec.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
[...]
> @@ -548,7 +548,7 @@ AVCodec ff_jpegls_decoder = {
>  .long_name  = NULL_IF_CONFIG_SMALL("JPEG-LS"),
>  .type   = AVMEDIA_TYPE_VIDEO,
>  .id = AV_CODEC_ID_JPEGLS,
> -.priv_data_size = sizeof(MJpegDecodeContext),
> +.priv_data_size = sizeof(JpegLSDecodeContext),
>  .init   = ff_mjpeg_decode_init,
>  .close  = ff_mjpeg_decode_end,

Sorry for not spotting this before it was applied but this feels problematic
a mjpeg could contain jpeg-ls
in fact iam pretty sure you can mix lossless and lossy coding in a single jpeg
image. Not sure if there is something in jpeg-ls that would prevent it from
being part of the mix.
I think its easier/more robust if the same context type would be used

Thanks

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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 v2 74/90] avcodec/codec, allcodecs: Constify the AVCodec API

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
Now also updating doc/examples and tests/api as well as
libavdevice/dshow.c.

 doc/APIchanges   |  5 +
 doc/examples/demuxing_decoding.c |  2 +-
 doc/examples/muxing.c| 10 ++
 doc/examples/transcode_aac.c |  4 ++--
 doc/examples/transcoding.c   |  4 ++--
 doc/examples/vaapi_encode.c  |  2 +-
 doc/examples/vaapi_transcode.c   |  4 ++--
 libavcodec/allcodecs.c   | 18 +-
 libavcodec/codec.h   |  8 
 libavdevice/dshow.c  |  2 +-
 tests/api/api-band-test.c|  2 +-
 tests/api/api-flac-test.c| 10 +-
 tests/api/api-h264-test.c|  2 +-
 tests/api/api-seek-test.c|  2 +-
 tools/target_dec_fuzzer.c|  8 
 15 files changed, 45 insertions(+), 38 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 2522978952..a823a4419c 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -17,6 +17,11 @@ API changes, most recent first:
 2021-04-17 - xx - lavu 56.73.100 - frame.h detection_bbox.h
   Add AV_FRAME_DATA_DETECTION_BBOXES
 
+2021-04-14 - xx - lavc y - codec.h
+  avcodec_find_encoder_by_name(), avcodec_find_encoder(),
+  avcodec_find_decoder_by_name() and avcodec_find_decoder()
+  now return a pointer to const AVCodec.
+
 2021-04-14 - xx - lavf y - avformat.h
   Constified AVFormatContext.*_codec.
 
diff --git a/doc/examples/demuxing_decoding.c b/doc/examples/demuxing_decoding.c
index db5e0cb951..55fdb2555c 100644
--- a/doc/examples/demuxing_decoding.c
+++ b/doc/examples/demuxing_decoding.c
@@ -149,7 +149,7 @@ static int open_codec_context(int *stream_idx,
 {
 int ret, stream_index;
 AVStream *st;
-AVCodec *dec = NULL;
+const AVCodec *dec = NULL;
 AVDictionary *opts = NULL;
 
 ret = av_find_best_stream(fmt_ctx, type, -1, -1, NULL, 0);
diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 014359e2ca..fe1b9ded21 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -121,7 +121,7 @@ static int write_frame(AVFormatContext *fmt_ctx, 
AVCodecContext *c,
 
 /* Add an output stream. */
 static void add_stream(OutputStream *ost, AVFormatContext *oc,
-   AVCodec **codec,
+   const AVCodec **codec,
enum AVCodecID codec_id)
 {
 AVCodecContext *c;
@@ -242,7 +242,8 @@ static AVFrame *alloc_audio_frame(enum AVSampleFormat 
sample_fmt,
 return frame;
 }
 
-static void open_audio(AVFormatContext *oc, AVCodec *codec, OutputStream *ost, 
AVDictionary *opt_arg)
+static void open_audio(AVFormatContext *oc, const AVCodec *codec,
+   OutputStream *ost, AVDictionary *opt_arg)
 {
 AVCodecContext *c;
 int nb_samples;
@@ -405,7 +406,8 @@ static AVFrame *alloc_picture(enum AVPixelFormat pix_fmt, 
int width, int height)
 return picture;
 }
 
-static void open_video(AVFormatContext *oc, AVCodec *codec, OutputStream *ost, 
AVDictionary *opt_arg)
+static void open_video(AVFormatContext *oc, const AVCodec *codec,
+   OutputStream *ost, AVDictionary *opt_arg)
 {
 int ret;
 AVCodecContext *c = ost->enc;
@@ -539,7 +541,7 @@ int main(int argc, char **argv)
 const AVOutputFormat *fmt;
 const char *filename;
 AVFormatContext *oc;
-AVCodec *audio_codec, *video_codec;
+const AVCodec *audio_codec, *video_codec;
 int ret;
 int have_video = 0, have_audio = 0;
 int encode_video = 0, encode_audio = 0;
diff --git a/doc/examples/transcode_aac.c b/doc/examples/transcode_aac.c
index 73786ab59b..711076b5a5 100644
--- a/doc/examples/transcode_aac.c
+++ b/doc/examples/transcode_aac.c
@@ -60,7 +60,7 @@ static int open_input_file(const char *filename,
AVCodecContext **input_codec_context)
 {
 AVCodecContext *avctx;
-AVCodec *input_codec;
+const AVCodec *input_codec;
 int error;
 
 /* Open the input file to read from it. */
@@ -144,7 +144,7 @@ static int open_output_file(const char *filename,
 AVCodecContext *avctx  = NULL;
 AVIOContext *output_io_context = NULL;
 AVStream *stream   = NULL;
-AVCodec *output_codec  = NULL;
+const AVCodec *output_codec= NULL;
 int error;
 
 /* Open the output file to write to it. */
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 6ca3089330..3a97426e2c 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -77,7 +77,7 @@ static int open_input_file(const char *filename)
 
 for (i = 0; i < ifmt_ctx->nb_streams; i++) {
 AVStream *stream = ifmt_ctx->streams[i];
-AVCodec *dec = avcodec_find_decoder(stream->codecpar->codec_id);
+const AVCodec *dec = avcodec_find_decoder(stream->codecpar->codec_id);
 AVCodecContext *codec_ctx;
 if (!dec) {
 av_log(NULL, AV_LOG_ERROR, "Failed to find decoder for s

Re: [FFmpeg-devel] [PATCH] avcodec/jpeglsdec: Don't allocate+free JPEGLSState for every frame

[Andreas Rheinhardt]

Michael Niedermayer:
> On Wed, Apr 14, 2021 at 11:21:40PM +0200, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/jpeglsdec.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
> [...]
>> @@ -548,7 +548,7 @@ AVCodec ff_jpegls_decoder = {
>>  .long_name  = NULL_IF_CONFIG_SMALL("JPEG-LS"),
>>  .type   = AVMEDIA_TYPE_VIDEO,
>>  .id = AV_CODEC_ID_JPEGLS,
>> -.priv_data_size = sizeof(MJpegDecodeContext),
>> +.priv_data_size = sizeof(JpegLSDecodeContext),
>>  .init   = ff_mjpeg_decode_init,
>>  .close  = ff_mjpeg_decode_end,
> 
> Sorry for not spotting this before it was applied but this feels problematic
> a mjpeg could contain jpeg-ls
> in fact iam pretty sure you can mix lossless and lossy coding in a single jpeg
> image. Not sure if there is something in jpeg-ls that would prevent it from
> being part of the mix.
> I think its easier/more robust if the same context type would be used
> 
I am now looking at this again and there is indeed nothing that prevents
other codecs using ff_mjpeg_decode_init() from calling
ff_jpegls_decode_picture(). I don't know why I didn't check this
earlier, sorry for that. And thanks. Will fix it.

- 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 v2 75/90] avformat/avformat, utils: Make av_find_best_stream const-correct

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
Now also updating doc/examples.

 doc/APIchanges | 4 
 doc/examples/extract_mvs.c | 2 +-
 doc/examples/filtering_audio.c | 2 +-
 doc/examples/filtering_video.c | 2 +-
 doc/examples/hw_decode.c   | 2 +-
 doc/examples/vaapi_transcode.c | 2 +-
 libavformat/avformat.h | 2 +-
 libavformat/utils.c| 4 ++--
 8 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index a823a4419c..d19b817660 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -17,6 +17,10 @@ API changes, most recent first:
 2021-04-17 - xx - lavu 56.73.100 - frame.h detection_bbox.h
   Add AV_FRAME_DATA_DETECTION_BBOXES
 
+2021-04-14 - xx - lavf y - avformat.h
+  av_find_best_stream now uses a const AVCodec ** parameter
+  for the returned decoder.
+
 2021-04-14 - xx - lavc y - codec.h
   avcodec_find_encoder_by_name(), avcodec_find_encoder(),
   avcodec_find_decoder_by_name() and avcodec_find_decoder()
diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
index de31ccd2b9..42e1844150 100644
--- a/doc/examples/extract_mvs.c
+++ b/doc/examples/extract_mvs.c
@@ -78,7 +78,7 @@ static int open_codec_context(AVFormatContext *fmt_ctx, enum 
AVMediaType type)
 int ret;
 AVStream *st;
 AVCodecContext *dec_ctx = NULL;
-AVCodec *dec = NULL;
+const AVCodec *dec = NULL;
 AVDictionary *opts = NULL;
 
 ret = av_find_best_stream(fmt_ctx, type, -1, -1, &dec, 0);
diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
index 834b137cd9..508c19c60b 100644
--- a/doc/examples/filtering_audio.c
+++ b/doc/examples/filtering_audio.c
@@ -48,8 +48,8 @@ static int audio_stream_index = -1;
 
 static int open_input_file(const char *filename)
 {
+const AVCodec *dec;
 int ret;
-AVCodec *dec;
 
 if ((ret = avformat_open_input(&fmt_ctx, filename, NULL, NULL)) < 0) {
 av_log(NULL, AV_LOG_ERROR, "Cannot open input file\n");
diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 105a200d93..88394530ab 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -53,8 +53,8 @@ static int64_t last_pts = AV_NOPTS_VALUE;
 
 static int open_input_file(const char *filename)
 {
+const AVCodec *dec;
 int ret;
-AVCodec *dec;
 
 if ((ret = avformat_open_input(&fmt_ctx, filename, NULL, NULL)) < 0) {
 av_log(NULL, AV_LOG_ERROR, "Cannot open input file\n");
diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
index 71be6e6709..096a229c0d 100644
--- a/doc/examples/hw_decode.c
+++ b/doc/examples/hw_decode.c
@@ -152,7 +152,7 @@ int main(int argc, char *argv[])
 int video_stream, ret;
 AVStream *video = NULL;
 AVCodecContext *decoder_ctx = NULL;
-AVCodec *decoder = NULL;
+const AVCodec *decoder = NULL;
 AVPacket packet;
 enum AVHWDeviceType type;
 int i;
diff --git a/doc/examples/vaapi_transcode.c b/doc/examples/vaapi_transcode.c
index e9b33eede0..a174bb643a 100644
--- a/doc/examples/vaapi_transcode.c
+++ b/doc/examples/vaapi_transcode.c
@@ -62,7 +62,7 @@ static enum AVPixelFormat get_vaapi_format(AVCodecContext 
*ctx,
 static int open_input_file(const char *filename)
 {
 int ret;
-AVCodec *decoder = NULL;
+const AVCodec *decoder = NULL;
 AVStream *video = NULL;
 
 if ((ret = avformat_open_input(&ifmt_ctx, filename, NULL, NULL)) < 0) {
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 23bdaa207b..28069d45dc 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2070,7 +2070,7 @@ int av_find_best_stream(AVFormatContext *ic,
 enum AVMediaType type,
 int wanted_stream_nb,
 int related_stream,
-AVCodec **decoder_ret,
+const AVCodec **decoder_ret,
 int flags);
 
 /**
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7078891dc0..2f66f539a6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4200,7 +4200,7 @@ AVProgram *av_find_program_from_stream(AVFormatContext 
*ic, AVProgram *last, int
 
 int av_find_best_stream(AVFormatContext *ic, enum AVMediaType type,
 int wanted_stream_nb, int related_stream,
-AVCodec **decoder_ret, int flags)
+const AVCodec **decoder_ret, int flags)
 {
 int i, nb_streams = ic->nb_streams;
 int ret = AVERROR_STREAM_NOT_FOUND;
@@ -4260,7 +4260,7 @@ int av_find_best_stream(AVFormatContext *ic, enum 
AVMediaType type,
 }
 }
 if (decoder_ret)
-*decoder_ret = (AVCodec*)best_decoder;
+*decoder_ret = best_decoder;
 return ret;
 }
 
-- 
2.27.0

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

To un

[FFmpeg-devel] [PATCH] avcodec/jpeglsdec: Don't presume the context to contain and JLSState

[Andreas Rheinhardt]

Before 9b3c46a081a9f01559082bf7a154fc6be1e06c18 every call to
ff_jpegls_decode_picture() allocated and freed a JLSState. This commit
instead put said structure into the context of the JPEG-LS decoder to
avoid said allocation. But said function can also be called from other
MJPEG-based decoders and their contexts doesn't contain said structure,
leading to segfaults. This commit fixes this: The JLSState is now
allocated on the first call to ff_jpegls_decode_picture() and stored in
the context.

Found-by: Michael Niedermayer 
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/jpeglsdec.c | 15 ---
 libavcodec/mjpegdec.c  |  1 +
 libavcodec/mjpegdec.h  |  3 +++
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index 92df81600b..e17de09e9f 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -45,11 +45,6 @@
  */
 //#define JLS_BROKEN
 
-typedef struct JpegLSDecodeContext {
-MJpegDecodeContext mjpeg;
-JLSState state;
-} JpegLSDecodeContext;
-
 /**
  * Decode LSE block with initialization parameters
  */
@@ -355,10 +350,16 @@ int ff_jpegls_decode_picture(MJpegDecodeContext *s, int 
near,
 {
 int i, t = 0;
 uint8_t *zero, *last, *cur;
-JLSState *const state = &((JpegLSDecodeContext*)s)->state;
+JLSState *state = s->jls_state;
 int off = 0, stride = 1, width, shift, ret = 0;
 int decoded_height = 0;
 
+if (!state) {
+state = av_malloc(sizeof(*state));
+if (!state)
+return AVERROR(ENOMEM);
+s->jls_state = state;
+}
 zero = av_mallocz(s->picture_ptr->linesize[0]);
 if (!zero)
 return AVERROR(ENOMEM);
@@ -548,7 +549,7 @@ AVCodec ff_jpegls_decoder = {
 .long_name  = NULL_IF_CONFIG_SMALL("JPEG-LS"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_JPEGLS,
-.priv_data_size = sizeof(JpegLSDecodeContext),
+.priv_data_size = sizeof(MJpegDecodeContext),
 .init   = ff_mjpeg_decode_init,
 .close  = ff_mjpeg_decode_end,
 .receive_frame  = ff_mjpeg_receive_frame,
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index f3d9e99aab..7c7cc20af8 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2916,6 +2916,7 @@ av_cold int ff_mjpeg_decode_end(AVCodecContext *avctx)
 reset_icc_profile(s);
 
 av_freep(&s->hwaccel_picture_private);
+av_freep(&s->jls_state);
 
 return 0;
 }
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index 0d69d9101b..2400a179f1 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -49,6 +49,8 @@ typedef struct ICCEntry {
 intlength;
 } ICCEntry;
 
+struct JLSState;
+
 typedef struct MJpegDecodeContext {
 AVClass *class;
 AVCodecContext *avctx;
@@ -163,6 +165,7 @@ typedef struct MJpegDecodeContext {
 enum AVPixelFormat hwaccel_sw_pix_fmt;
 enum AVPixelFormat hwaccel_pix_fmt;
 void *hwaccel_picture_private;
+struct JLSState *jls_state;
 } MJpegDecodeContext;
 
 int ff_mjpeg_build_vlc(VLC *vlc, const uint8_t *bits_table,
-- 
2.27.0

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

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

[FFmpeg-devel] [PATCH v1] doc/protocols.texi : Add ignore_rtcp option in rtsp section

[sunml]

From: Minlei Sun 

Signed-off-by: Minlei Sun 
---
 doc/protocols.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a6e46b99ad..604d42b693 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1188,6 +1188,9 @@ libavformat identifier string.
 @item user_agent
 Override User-Agent header. If not specified, it defaults to the
 libavformat identifier string.
+
+@item ignore_rtcp
+Ignore rtcp packets in rtsp stream to avoid transcoding stuck. Default valule 
is 0.
 @end table
 
 When receiving data over UDP, the demuxer tries to reorder received packets
-- 
2.24.3 (Apple Git-128)

___
ffmpeg-devel mailing list
ffmpeg-devel@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] doc/protocols.texi : Add ignore_rtcp option in rtsp section

[sunml]

From: Minlei Sun 

Regarding ignore_rtcp flag, it is turned off by default. When some devices 
(such as hikvision iSecure Center Platform v1.3.xxx) rtsp stream contains rtcp 
data packets (may be non-standard), there will be a freeze when the output is 
rtmp stream.
So when igore_rtcp is enabled, this situation can be solved.

Signed-off-by: Minlei Sun 
---
 doc/protocols.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a6e46b99ad..604d42b693 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1188,6 +1188,9 @@ libavformat identifier string.
 @item user_agent
 Override User-Agent header. If not specified, it defaults to the
 libavformat identifier string.
+
+@item ignore_rtcp
+Ignore rtcp packets in rtsp stream to avoid transcoding stuck. Default valule 
is 0.
 @end table
 
 When receiving data over UDP, the demuxer tries to reorder received packets
-- 
2.24.3 (Apple Git-128)

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

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

Re: [FFmpeg-devel] [PATCH v3 1/1] avformat/mpegtsenc: Write necessary descriptors into PMT for arib_caption muxing

[Jan Ekström]

On Tue, Apr 20, 2021 at 3:03 PM zheng qian  wrote:
>
> On Tue, Apr 20, 2021 at 6:46 AM Jan Ekström  wrote:
> >
> > On Tue, Apr 20, 2021 at 12:11 AM Marton Balint  wrote:
> > >
> > >
> > >
> > > On Mon, 19 Apr 2021, zheng qian wrote:
> > >
> > > > Is there anyone who could review this patch?
> > >
> > > Jan was interested in this, so preferably he should also comment, but it
> > > looks fine to me.
> > >
> >
> > OK, this explains why I didn't see my response on patchwork.
> > Apparently he had CC'd me and thus the "reply" button in gmail sent an
> > e-mail directly to him and I was hurrying due to being on a lunch
> > break -_- (and thus didn't notice).
> >
> > In any case, I did some comments and am now waiting for a second
> > opinion regarding the usage of stream_identifiers in the ARIB context.
> > After all, the specifications do let one utilize 0x30-0x37 for profile
> > A/full-seg ARIB captions, so there must be a reason for them to not be
> > as limited as profile C/1seg to a single identifier :)
> >
>
> I've found related definitions in ARIB TR-B14, Fascicle 1, 4.2.8.1
> and you can find it in
> http://web.archive.org/web/20160319090430/http://arib.or.jp/english/html/overview/doc/8-TR-B14v2_8-1p3-2-E2.pdf
>
> 4.2.8.1 section says:
> "However, for component tag values of default ES of caption,
> set 0x30 or 0x87, for component tag value of default ES of
> superimpose, set 0x38 or 0x88."
>
> That means 0x30 is considered as the default value for
> Profile A caption ES. The section didn't describe how to
> utilize other values rather than 0x30 in the 0x30~0x37 range,
> and due to the second language caption is designed to be
> multiplexed in the same ES, seems that it's assumed that
> there will be usually only one ARIB caption within a program.
>

Alright, so I took another look as well throughout these Technical
Recommendations:

TR B14 fascicle 4
- http://www.arib.or.jp/english/html/overview/doc/8-TR-B14v6_5-4p5-E1.pdf

See:
14  Use of “component_tag”

> Table 14-1   Assignment of “component_tag” Values
> Others
> 0x30 to 0x7F
> Please note that 0x40 is assigned to the default ES for data
> broadcasting. 0x30, 0x31 to 0x37, 0x38 and 0x39 to 0x3F are assigned to 
> subtitle
> main, subtitle sub, teletext main and teletext sub respectively.

Then in TR B14 fascicle 2:
- http://www.arib.or.jp/english/html/overview/doc/8-TR-B14v6_5-2p5-E1.pdf

> 4.2.1  Specification for composition and transmission
> (3) Number of ES
> The maximum number of ESs that can be transmitted simultaneously for the same 
> service is
> 1  for  captions  and  1  for  superimpositions  when  the  component  group  
> descriptor  is  not
> transmitted. When the component group descriptor is transmitted, the maximum 
> number of ESs
> for captions is 1 and the maximum number of ESs for superimpositions is 1 for 
> each component
> group.

So to recap my understanding:
1. STD side (specs): It seems like these values have to be unique at
least at the level of a PMT (thus, per-program) - discussed this with
a person working on ARIB area of operations :) .
2. STD side: We can indeed have multiple caption/subtitle ES in a
single program (PMT) for Profile A. Profile C is always limited to one
ES per program since only one content_tag is possible.
3. TR side (tech. rec.): 0x30/0x87 should be the default for Profile A/C
4. TR side: If we do not code Component Group Descriptor (0xD9 in the
EIT), we should stick to a single ES (the default one) on both Profile
A and C.
5. TR side: If we code a Component Group Descriptor in the EIT, we can
have one ES for each composition group.

So basically:
1. STD side lets us go for it
2. TR side says "nope, you stick to one - unless you're defining
composition groups". Which is why you do not see multi-subtitle
streams in the wild, since almost nobody utilizes Content Group
Descriptors.

We don't and not sure if we will ever support component groups, so the
alternatives are:
1. Follow TR side, and be more strict than the specification. Limit in
`mpegts_init` each program to a single ARIB caption stream (be it
Profile A or Profile C). Set component_tag in descriptor to the
default one (0x30 or 0x87 respectively).
2. Follow STD side, and utilize what the specification enables. Limit
in `mpegts_init` each program to either 8 Profile A ARIB caption
streams, or 1 Profile C ARIB caption stream. Set component_tag
iteratively in order.

In both cases during counting the profile should be checked, since we
require the profile info to be there for writing of the descriptor.

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

Re: [FFmpeg-devel] [PATCH v2] doc/protocols.texi : Add ignore_rtcp option in rtsp section

[Gyan Doshi]

On 2021-04-20 22:50, su...@epoint.com.cn wrote:

From: Minlei Sun 

Regarding ignore_rtcp flag, it is turned off by default. When some devices 
(such as hikvision iSecure Center Platform v1.3.xxx) rtsp stream contains rtcp 
data packets (may be non-standard), there will be a freeze when the output is 
rtmp stream.
So when igore_rtcp is enabled, this situation can be solved.

Signed-off-by: Minlei Sun 
---
  doc/protocols.texi | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a6e46b99ad..604d42b693 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1188,6 +1188,9 @@ libavformat identifier string.
  @item user_agent
  Override User-Agent header. If not specified, it defaults to the
  libavformat identifier string.
+
+@item ignore_rtcp
+Ignore rtcp packets in rtsp stream to avoid transcoding stuck. Default valule 
is 0.
  @end table


Can you identify which source code unit implements this option?

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/libopusenc: reload packet loss at encode

[Lynne]

Mar 3, 2021, 16:50 by philip-dylan.gleo...@savoirfairelinux.com:

> Le 16/02/2021 à 15:04, Philip-Dylan Gleonec a écrit :
>
>> An estimation of packet loss is required by libopus to compute its FEC
>> data. Currently, this estimation is constant, and can not be changed
>> after configuration. This means an application using libopus through
>> ffmpeg can not adapt the packet loss estimation when the network
>> quality degrades.
>>
>> This patch makes the encoder reload the packet_loss AVOption before
>> encoding samples, if fec is enabled. This way an application can modify
>> the packet loss estimation by changing the AVOption. Typical use-case
>> is a RTP stream, where packet loss can be estimated from RTCP packets.
>>
>> Signed-off-by: Philip-Dylan Gleonec 
>> 
>> ---
>>  libavcodec/libopusenc.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
>> index 70d17f802b..c18e8ae7fa 100644
>> --- a/libavcodec/libopusenc.c
>> +++ b/libavcodec/libopusenc.c
>> @@ -460,6 +460,15 @@ static int libopus_encode(AVCodecContext *avctx, 
>> AVPacket *avpkt,
>>  int ret;
>>  int discard_padding;
>>  +if (opus->opts.fec) {
>> +ret = opus_multistream_encoder_ctl(opus->enc,
>> +   
>> OPUS_SET_PACKET_LOSS_PERC(opus->opts.packet_loss));
>> +if (ret != OPUS_OK)
>> +av_log(avctx, AV_LOG_WARNING,
>> +   "Unable to set expected packet loss percentage: %s\n",
>> +   opus_strerror(ret));
>> +}
>> +
>>  if (frame) {
>>  ret = ff_af_queue_add(&opus->afq, frame);
>>  if (ret < 0)
>>
>
> Hello,
>
> Is someone interested in picking this up, or is there some correction I 
> should make to this patch ?
>

Could you check if the option value has changed in between calls
to encode and only reset the packet loss value if it has?
With that change, patch looks good.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/1] avcodec/libopusdec: Enable FEC/PLC

[Lynne]

Mar 3, 2021, 16:51 by philip-dylan.gleo...@savoirfairelinux.com:

> Le 18/02/2021 à 17:38, Philip-Dylan Gleonec a écrit :
>
>> Here is the reworked patch properly attached.
>> Sorry about the duplicate mail, I just noticed I had a mishap with my
>> mail client and the previous patch was scrubbed.
>>
>
>
> Hello,
>
> Is someone interested in picking this up, or is there some further 
> corrections/improvements I should make to this patch ?
>

Patch looks good.
I'll push it alongside the libopusdec patch once you've resent it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/jpeglsdec: Don't presume the context to contain and JLSState

[Michael Niedermayer]

On Tue, Apr 20, 2021 at 06:26:49PM +0200, Andreas Rheinhardt wrote:
> Before 9b3c46a081a9f01559082bf7a154fc6be1e06c18 every call to
> ff_jpegls_decode_picture() allocated and freed a JLSState. This commit
> instead put said structure into the context of the JPEG-LS decoder to
> avoid said allocation. But said function can also be called from other
> MJPEG-based decoders and their contexts doesn't contain said structure,
> leading to segfaults. This commit fixes this: The JLSState is now
> allocated on the first call to ff_jpegls_decode_picture() and stored in
> the context.
> 
> Found-by: Michael Niedermayer 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/jpeglsdec.c | 15 ---
>  libavcodec/mjpegdec.c  |  1 +
>  libavcodec/mjpegdec.h  |  3 +++
>  3 files changed, 12 insertions(+), 7 deletions(-)

LGTM

thx

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

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

Re: [FFmpeg-devel] [PATCH v3 1/1] avformat/mpegtsenc: Write necessary descriptors into PMT for arib_caption muxing

[Jan Ekström]

On Tue, Apr 20, 2021 at 8:16 PM Jan Ekström  wrote:
>
> On Tue, Apr 20, 2021 at 3:03 PM zheng qian  wrote:
> >
> > On Tue, Apr 20, 2021 at 6:46 AM Jan Ekström  wrote:
> > >
> > > On Tue, Apr 20, 2021 at 12:11 AM Marton Balint  wrote:
> > > >
> > > >
> > > >
> > > > On Mon, 19 Apr 2021, zheng qian wrote:
> > > >
> > > > > Is there anyone who could review this patch?
> > > >
> > > > Jan was interested in this, so preferably he should also comment, but it
> > > > looks fine to me.
> > > >
> > >
> > > OK, this explains why I didn't see my response on patchwork.
> > > Apparently he had CC'd me and thus the "reply" button in gmail sent an
> > > e-mail directly to him and I was hurrying due to being on a lunch
> > > break -_- (and thus didn't notice).
> > >
> > > In any case, I did some comments and am now waiting for a second
> > > opinion regarding the usage of stream_identifiers in the ARIB context.
> > > After all, the specifications do let one utilize 0x30-0x37 for profile
> > > A/full-seg ARIB captions, so there must be a reason for them to not be
> > > as limited as profile C/1seg to a single identifier :)
> > >
> >
> > I've found related definitions in ARIB TR-B14, Fascicle 1, 4.2.8.1
> > and you can find it in
> > http://web.archive.org/web/20160319090430/http://arib.or.jp/english/html/overview/doc/8-TR-B14v2_8-1p3-2-E2.pdf
> >
> > 4.2.8.1 section says:
> > "However, for component tag values of default ES of caption,
> > set 0x30 or 0x87, for component tag value of default ES of
> > superimpose, set 0x38 or 0x88."
> >
> > That means 0x30 is considered as the default value for
> > Profile A caption ES. The section didn't describe how to
> > utilize other values rather than 0x30 in the 0x30~0x37 range,
> > and due to the second language caption is designed to be
> > multiplexed in the same ES, seems that it's assumed that
> > there will be usually only one ARIB caption within a program.
> >
>
> Alright, so I took another look as well throughout these Technical
> Recommendations:
>
> TR B14 fascicle 4
> - http://www.arib.or.jp/english/html/overview/doc/8-TR-B14v6_5-4p5-E1.pdf
>
> See:
> 14  Use of “component_tag”
>
> > Table 14-1   Assignment of “component_tag” Values
> > Others
> > 0x30 to 0x7F
> > Please note that 0x40 is assigned to the default ES for data
> > broadcasting. 0x30, 0x31 to 0x37, 0x38 and 0x39 to 0x3F are assigned to 
> > subtitle
> > main, subtitle sub, teletext main and teletext sub respectively.
>
> Then in TR B14 fascicle 2:
> - http://www.arib.or.jp/english/html/overview/doc/8-TR-B14v6_5-2p5-E1.pdf
>
> > 4.2.1  Specification for composition and transmission
> > (3) Number of ES
> > The maximum number of ESs that can be transmitted simultaneously for the 
> > same service is
> > 1  for  captions  and  1  for  superimpositions  when  the  component  
> > group  descriptor  is  not
> > transmitted. When the component group descriptor is transmitted, the 
> > maximum number of ESs
> > for captions is 1 and the maximum number of ESs for superimpositions is 1 
> > for each component
> > group.
>
> So to recap my understanding:
> 1. STD side (specs): It seems like these values have to be unique at
> least at the level of a PMT (thus, per-program) - discussed this with
> a person working on ARIB area of operations :) .
> 2. STD side: We can indeed have multiple caption/subtitle ES in a
> single program (PMT) for Profile A. Profile C is always limited to one
> ES per program since only one content_tag is possible.
> 3. TR side (tech. rec.): 0x30/0x87 should be the default for Profile A/C
> 4. TR side: If we do not code Component Group Descriptor (0xD9 in the
> EIT), we should stick to a single ES (the default one) on both Profile
> A and C.
> 5. TR side: If we code a Component Group Descriptor in the EIT, we can
> have one ES for each composition group.
>
> So basically:
> 1. STD side lets us go for it
> 2. TR side says "nope, you stick to one - unless you're defining
> composition groups". Which is why you do not see multi-subtitle
> streams in the wild, since almost nobody utilizes Content Group
> Descriptors.
>
> We don't and not sure if we will ever support component groups, so the
> alternatives are:
> 1. Follow TR side, and be more strict than the specification. Limit in
> `mpegts_init` each program to a single ARIB caption stream (be it
> Profile A or Profile C). Set component_tag in descriptor to the
> default one (0x30 or 0x87 respectively).
> 2. Follow STD side, and utilize what the specification enables. Limit
> in `mpegts_init` each program to either 8 Profile A ARIB caption
> streams, or 1 Profile C ARIB caption stream. Set component_tag
> iteratively in order.
>

I think in general I am preferring the "follow the TR" way since I
just heard another implementer generally speaking also ignores
everything else than 0x30/0x87.

Did not yet add the per-program limitation but poked a bit at it with
https://github.com/jeeb/ffmpeg/commits/mpegts_arib_caption_muxing .

1. Split the writing 

Re: [FFmpeg-devel] [PATCH v3 1/1] avformat/mpegtsenc: Write necessary descriptors into PMT for arib_caption muxing

[zheng qian]

On Wed, Apr 21, 2021 at 7:04 AM Jan Ekström  wrote:
>
> I think in general I am preferring the "follow the TR" way since I
> just heard another implementer generally speaking also ignores
> everything else than 0x30/0x87.
>
> Did not yet add the per-program limitation but poked a bit at it with
> https://github.com/jeeb/ffmpeg/commits/mpegts_arib_caption_muxing .
>
> 1. Split the writing of the ARIB caption descriptor as the PMT writing
> function is already way too long. Was not sure if exit or plain break
> would be sufficient, but nothing else around in that function seems to
> return with an error... so break it is.
> 2. Added logging in case an unset/unknown profile was utilized.
> 3. Re-added extraction of additional_arib_caption_info into extradata,
> and writing it out in the muxer if available.
>

I doubt whether it's necessary to extract addtitional_arib_caption_info.
According to ARIB TR-B24, Fascicle 1, 4.2.8.4 - 4.2.8.5:

> Data Encoding Method Descriptor required in PMT:
> DMF is always '0011', aka 0x3
> Timing is always '01' for caption, aka 0x1

Reversed is filled as '11'  aka 0x3 as you know, so for arib_caption,
addtitional_arib_caption_info could be determined as 0x3d.

ARIB superimpose should utilize Timing(00) since superimpose
uses Asynchronous_PES, but it belongs to another topic.

In other words, addtitional_arib_caption_info can be generated by
profile information safely and is not necessary to copy by extradata.

Regards,
zheng

> Feel free to note how you like these changes :)
>
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 00/11] lavu/tx: FFT improvements, additions and assembly

[Lynne]

Apr 19, 2021, 22:19 by d...@lynne.ee:

> This patchset cleans up and improves the power-of-two C code, 
> adds a 7-point and a 9-point FFT, and adds a power-of-two length
> floating-point assembly.
>

Ping. There's no one signed up to review the assembly yet, but apart from me,
there's unfortunately pretty much no one else who does float SIMD these days.
Thought I did spend long enough on every part to make sure it's as close
to perfect as I could make it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Major bump

[Steven Liu]

> 2021年4月5日 下午7:09，Anton Khirnov  写道：
> 
> Hi,
> this patchset bumps major version of all the libraries and removes many
> deprecated APIs, as discussed at length during past months. Patches
> 11-16 will be squashed together on push, but are sent separately for
> ease of review. FATE passes (here at least).
> 
> As agreed during the last developer call, I am disabling the
> uspp/mcdeint filters that depend on removed libavcodec APIs. They should
> be easy to re-enable if anyone finds the motivation to update them.
> 
> I am postponing the removal of compute_muxer_pkt_fields() in lavf, along
> with usage of AVCodecContext.time_base for decoding, since removing them
> without breakage requires a fair bit of additional infrastructure that
> is not yet there. I have plans for all these and hopefully I'll get to
> it before the next bump.
> 
> Carl asked during the last meeting for some reasoning for the bump. The
> general reasons are that
> - old APIs are unable to provide all the features of the new ones
>  (that's usually why new APIs are added)
> - old APIs tend to be harder to use correctly, they often have obscure
>  quirks or corner cases
> - maintaining compatibility wrappers for them is a major obstacle to
>  further development
> I'm appending some notes for the specific changes further down, they
> could be added to the wiki or the website news entry.
> 
> Please comment,
> -- 
> Anton Khirnov
> 
> Major bump notes
> 
> libavcodec
> --
> * old audio/video decoding APIs avcodec_decode_video2 and
>  avcodec_decode_audio4 were removed;
>  they are replaced by avcodec_send_packet/avcodec_receive_frame, which
>  decouple input and output and can return any number of output frames
>  for a single input packet
> * old audio/video encoding APIs avcodec_encode_video2 and
>  avcodec_encode_audio2 were removed;
>  they are replaced by avcodec_send_frame/avcodec_receive_packet, which
>  decouple input and output and can return any number of output packets
>  for a single input frame
> * AVCodecContext.coded_frame removed without replacement
> * AVCodecContext.side_data_only_packets removed, codecs (currently only 
> flacenc)
>  now always behave as if this field was set to 1
> * AVCodecContext.vbv_delay removed, replaced by AV_PKT_DATA_CPB_PROPERTIES 
> side data
> * AVCodecContext.rtp_callback removed without replacement
> * AVCodecContext.*_bits removed without replacement
> * following AVCodecContext fields  removed, replaced by encoder-private 
> options
>- coder_type and FF_CODER_TYPE*
>- b_frame_strategy
>- mpeg_quant
>- prediction_method and FF_PRED_*
>- pre_me
>- scenechange_threshold
>- noise_reduction
>- me_penalty_compensation
>- brd_scale
>- chromaoffset
>- b_sensitivity
>- context_model
>- frame_skip_*
>- min/max_prediction_order
>- timecode_frame_start
>- rtp_payload_size
> * AVPacket.convergence_duration removed, use AVPacket.duration instead
> * AVPacket API for pre-refcounted memory management were removed
>- av_dup_packet
>- av_copy_packet
>- av_copy_packet_side_data
>- av_free_packet
>  users should use refcounted packet API instead
> * av_packet_merge_side_data and av_packet_split_side_data removed without 
> replacement,
>  packets with merged side data are no longer supported
> * AVPicture and its related APIs removed; it is replaced either by AVFrame API
>  or imgutils in libavutil
> * old bistream filtering API (using AVBitStreamFilterContext) removed, 
> replaced by the API
>  in libavcodec/bsf.h
> * avcodec_copy_context removed, it never makes sense for users to call this 
> function
> * avcodec_get_context_defaults3 removed, users should allocate a new codec 
> context
>  instead of resettting an old one
> * av_get_codec_tag_string replaced by av_fourcc_make_string/av_fourcc2str
> * avcodec_get_chroma_sub_sample replaced by av_pix_fmt_get_chroma_sub_sample
> * AVCodecContext accessors removed, AVCodecContext fields should be accessed 
> directly
> * AVHWAccel and its related functions removed from public API, as there was 
> no reason
>  for them to be user-visible
> * AV_CODEC_CAP_INTRA_ONLY and AV_CODEC_CAP_INTRA_ONLY removed, use 
> corresponding
>  AVCodecDescriptor.props values instead
> * av_lockmgr_register and AVLockOp removed, libavcodec handles locking 
> internally
> * codec registration APIs removed, all codecs are always registered
>- avcodec_register
>- avcodec_register_all
> * av_codec_next replaced by av_codec_iterate
> * AVCPBProperties.max/min/avg_bitrate types changed from int to int64_t
> * avcodec_get_pix_fmt_loss replaced by av_get_pix_fmt_loss
> * avcodec_find_best_pix_fmt_of_2 replaced by avcodec_find_best_pix_fmt_of_2
> * avcodec_find_best_pix_fmt2 removed
> * av_parser_change removed; dump_extradata, remove_extra or extract_extradata
>  should be used instead
> * FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS removed, ASS subtitles are always decoded 
> without

Re: [FFmpeg-devel] Major bump

[Andreas Rheinhardt]

Steven Liu:
> 
> 
>> 2021年4月5日 下午7:09，Anton Khirnov  写道：
>>
>> Hi,
>> this patchset bumps major version of all the libraries and removes many
>> deprecated APIs, as discussed at length during past months. Patches
>> 11-16 will be squashed together on push, but are sent separately for
>> ease of review. FATE passes (here at least).
>>
>> As agreed during the last developer call, I am disabling the
>> uspp/mcdeint filters that depend on removed libavcodec APIs. They should
>> be easy to re-enable if anyone finds the motivation to update them.
>>
>> I am postponing the removal of compute_muxer_pkt_fields() in lavf, along
>> with usage of AVCodecContext.time_base for decoding, since removing them
>> without breakage requires a fair bit of additional infrastructure that
>> is not yet there. I have plans for all these and hopefully I'll get to
>> it before the next bump.
>>
>> Carl asked during the last meeting for some reasoning for the bump. The
>> general reasons are that
>> - old APIs are unable to provide all the features of the new ones
>>  (that's usually why new APIs are added)
>> - old APIs tend to be harder to use correctly, they often have obscure
>>  quirks or corner cases
>> - maintaining compatibility wrappers for them is a major obstacle to
>>  further development
>> I'm appending some notes for the specific changes further down, they
>> could be added to the wiki or the website news entry.
>>
>> Please comment,
>> -- 
>> Anton Khirnov
>>
>> Major bump notes
>> 
>> libavcodec
>> --
>> * old audio/video decoding APIs avcodec_decode_video2 and
>>  avcodec_decode_audio4 were removed;
>>  they are replaced by avcodec_send_packet/avcodec_receive_frame, which
>>  decouple input and output and can return any number of output frames
>>  for a single input packet
>> * old audio/video encoding APIs avcodec_encode_video2 and
>>  avcodec_encode_audio2 were removed;
>>  they are replaced by avcodec_send_frame/avcodec_receive_packet, which
>>  decouple input and output and can return any number of output packets
>>  for a single input frame
>> * AVCodecContext.coded_frame removed without replacement
>> * AVCodecContext.side_data_only_packets removed, codecs (currently only 
>> flacenc)
>>  now always behave as if this field was set to 1
>> * AVCodecContext.vbv_delay removed, replaced by AV_PKT_DATA_CPB_PROPERTIES 
>> side data
>> * AVCodecContext.rtp_callback removed without replacement
>> * AVCodecContext.*_bits removed without replacement
>> * following AVCodecContext fields  removed, replaced by encoder-private 
>> options
>>- coder_type and FF_CODER_TYPE*
>>- b_frame_strategy
>>- mpeg_quant
>>- prediction_method and FF_PRED_*
>>- pre_me
>>- scenechange_threshold
>>- noise_reduction
>>- me_penalty_compensation
>>- brd_scale
>>- chromaoffset
>>- b_sensitivity
>>- context_model
>>- frame_skip_*
>>- min/max_prediction_order
>>- timecode_frame_start
>>- rtp_payload_size
>> * AVPacket.convergence_duration removed, use AVPacket.duration instead
>> * AVPacket API for pre-refcounted memory management were removed
>>- av_dup_packet
>>- av_copy_packet
>>- av_copy_packet_side_data
>>- av_free_packet
>>  users should use refcounted packet API instead
>> * av_packet_merge_side_data and av_packet_split_side_data removed without 
>> replacement,
>>  packets with merged side data are no longer supported
>> * AVPicture and its related APIs removed; it is replaced either by AVFrame 
>> API
>>  or imgutils in libavutil
>> * old bistream filtering API (using AVBitStreamFilterContext) removed, 
>> replaced by the API
>>  in libavcodec/bsf.h
>> * avcodec_copy_context removed, it never makes sense for users to call this 
>> function
>> * avcodec_get_context_defaults3 removed, users should allocate a new codec 
>> context
>>  instead of resettting an old one
>> * av_get_codec_tag_string replaced by av_fourcc_make_string/av_fourcc2str
>> * avcodec_get_chroma_sub_sample replaced by av_pix_fmt_get_chroma_sub_sample
>> * AVCodecContext accessors removed, AVCodecContext fields should be accessed 
>> directly
>> * AVHWAccel and its related functions removed from public API, as there was 
>> no reason
>>  for them to be user-visible
>> * AV_CODEC_CAP_INTRA_ONLY and AV_CODEC_CAP_INTRA_ONLY removed, use 
>> corresponding
>>  AVCodecDescriptor.props values instead
>> * av_lockmgr_register and AVLockOp removed, libavcodec handles locking 
>> internally
>> * codec registration APIs removed, all codecs are always registered
>>- avcodec_register
>>- avcodec_register_all
>> * av_codec_next replaced by av_codec_iterate
>> * AVCPBProperties.max/min/avg_bitrate types changed from int to int64_t
>> * avcodec_get_pix_fmt_loss replaced by av_get_pix_fmt_loss
>> * avcodec_find_best_pix_fmt_of_2 replaced by avcodec_find_best_pix_fmt_of_2
>> * avcodec_find_best_pix_fmt2 removed
>> * av_parser_change removed; dump_extradata, remove_extra or extra

Re: [FFmpeg-devel] [PATCH v2] doc/protocols.texi : Add ignore_rtcp option in rtsp section

[Minlei Sun]

>On 2021-04-20 22:50, su...@epoint.com.cn wrote:
>> From: Minlei Sun 
>>
>> Regarding ignore_rtcp flag, it is turned off by default. When some devices 
>> (such as hikvision iSecure Center Platform v1.3.xxx) rtsp stream contains 
>> rtcp data packets (may be non-standard), there will be a freeze when the 
>> output is rtmp stream.
>> So when igore_rtcp is enabled, this situation can be solved.
>>
>> Signed-off-by: Minlei Sun 
>> ---
>>   doc/protocols.texi | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/doc/protocols.texi b/doc/protocols.texi
>> index a6e46b99ad..604d42b693 100644
>> --- a/doc/protocols.texi
>> +++ b/doc/protocols.texi
>> @@ -1188,6 +1188,9 @@ libavformat identifier string.
>>   @item user_agent
>>   Override User-Agent header. If not specified, it defaults to the
>>   libavformat identifier string.
>> +
>> +@item ignore_rtcp
>> +Ignore rtcp packets in rtsp stream to avoid transcoding stuck. Default 
>> valule is 0.
>>   @end table
>
>Can you identify which source code unit implements this option?
>
>Gyan

Thanks.
I submitted a patch before, the name of the patch is [FFmpeg-devel,v1,1/3] 
libavformat/rtsp.h: Add member ignore_rtcp to RTSPState
___
ffmpeg-devel mailing list
ffmpeg-devel@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] doc/protocols.texi : Add ignore_rtcp option in rtsp section

[Gyan Doshi]

On 2021-04-21 08:44, Minlei Sun wrote:

On 2021-04-20 22:50, su...@epoint.com.cn wrote:

From: Minlei Sun 

Regarding ignore_rtcp flag, it is turned off by default. When some devices 
(such as hikvision iSecure Center Platform v1.3.xxx) rtsp stream contains rtcp 
data packets (may be non-standard), there will be a freeze when the output is 
rtmp stream.
So when igore_rtcp is enabled, this situation can be solved.

Signed-off-by: Minlei Sun 
---
   doc/protocols.texi | 3 +++
   1 file changed, 3 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a6e46b99ad..604d42b693 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1188,6 +1188,9 @@ libavformat identifier string.
   @item user_agent
   Override User-Agent header. If not specified, it defaults to the
   libavformat identifier string.
+
+@item ignore_rtcp
+Ignore rtcp packets in rtsp stream to avoid transcoding stuck. Default valule 
is 0.
   @end table

Can you identify which source code unit implements this option?

Gyan

Thanks.
I submitted a patch before, the name of the patch is [FFmpeg-devel,v1,1/3] 
libavformat/rtsp.h: Add member ignore_rtcp to RTSPState


Found it. Please squash all patches together, as suggested earlier.

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

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

Re: [FFmpeg-devel] [ffmpeg-web][PATCH] Drop my entry from the consulting list

[Gyan Doshi]

On 2021-04-19 02:08, Stefano Sabatini wrote:

Hi,

I've not been really active in the last period and this patch
clarifies this condition.


Will apply.

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

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

Re: [FFmpeg-devel] [PATCH v3 1/1] avformat/mpegtsenc: Write necessary descriptors into PMT for arib_caption muxing

[zheng qian]

On Wed, Apr 21, 2021 at 10:00 AM zheng qian  wrote:
>
> ARIB superimpose should utilize Timing(00) since superimpose
> uses Asynchronous_PES, but it belongs to another topic.
>
> In other words, addtitional_arib_caption_info can be generated by
> profile information safely and is not necessary to copy by extradata.
>

P.S.: AFAIK the DMF and Timing field actually do not affect ARIB B24
subtitle decoder/renderers' behavior since they always follow the
TMD and DMF field in caption_management_data(), which is
periodically transmitted in arib_caption ES.

In TR-B24, the Timing field for Superimpose could be
'00'(Non-synchronization) or '01'(Time synchronization),
and AFAIK Superimpose used in Japan DTV has never utilized
Timing field rather than '00', since Superimpose is designed to
be displayed immediately once received and usually used for
providing urgent disaster alerts and newsletters (like NHK速報).

Later I'd like to introduce arib_superimpose codec for superimpose
recognition and remuxing, and I believe that for arib_superimpose,
using fixed value 00 for Timing doesn't cause problems in practice.

thus, I'm waiting for your opinion.

Regards,
zheng qian

> Regards,
> zheng
>
> > Feel free to note how you like these changes :)
> >
> > 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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