Re: [FFmpeg-devel] [PATCH V6 3/3] lavfi/dnn: Remove DNN native backend

2023-04-26 Thread Guo, Yejun



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Ting Fu
> Sent: Monday, March 6, 2023 9:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V6 3/3] lavfi/dnn: Remove DNN native
> backend

This commit LGTM, 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 V6 2/3] lavfi/dnn: Modified DNN native backend related tools and docs.

2023-04-26 Thread Guo, Yejun



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Ting Fu
> Sent: Monday, March 6, 2023 9:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V6 2/3] lavfi/dnn: Modified DNN native
> backend related tools and docs.
> 
> Deleted the native backend related files in 'tools' dir. Modify its'
> docs and codes mentioned in such docs.

We'll remove native backend, so change the default backend in filters, 
and also remove the python scripts which generate native model file.

___
ffmpeg-devel mailing list
ffmpeg-devel@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 V6 1/3] lavfi/dnn: Mark native backend as unsupported

2023-04-26 Thread Guo, Yejun



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Ting Fu
> Sent: Monday, March 6, 2023 9:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V6 1/3] lavfi/dnn: Mark native backend as
> unsupported
> 
> Native is deprecated value for backed_type option. Modify related error

Native backend will be removed, and so change the interface first.

> message.
> 
> Signed-off-by: Ting Fu 
> ---
>  libavfilter/dnn/dnn_interface.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/libavfilter/dnn/dnn_interface.c b/libavfilter/dnn/dnn_interface.c
> index 554a36b0dc..5b1695a1dd 100644
> --- a/libavfilter/dnn/dnn_interface.c
> +++ b/libavfilter/dnn/dnn_interface.c
> @@ -24,7 +24,6 @@
>   */
> 
>  #include "../dnn_interface.h"
> -#include "dnn_backend_native.h"
>  #include "dnn_backend_tf.h"
>  #include "dnn_backend_openvino.h"
>  #include "libavutil/mem.h"
> @@ -39,13 +38,6 @@ DNNModule *ff_get_dnn_module(DNNBackendType
> backend_type)
>  }
> 
>  switch(backend_type){
> -case DNN_NATIVE:
> -dnn_module->load_model = _dnn_load_model_native;
> -dnn_module->execute_model = _dnn_execute_model_native;
> -dnn_module->get_result = _dnn_get_result_native;
> -dnn_module->flush = _dnn_flush_native;
> -dnn_module->free_model = _dnn_free_model_native;
> -break;
>  case DNN_TF:
>  #if (CONFIG_LIBTENSORFLOW == 1)
>  dnn_module->load_model = _dnn_load_model_tf; @@ -71,7 +63,7
> @@ DNNModule *ff_get_dnn_module(DNNBackendType backend_type)
>  #endif
>  break;
>  default:
> -av_log(NULL, AV_LOG_ERROR, "Module backend_type is not native or
> tensorflow\n");
> +av_log(NULL, AV_LOG_ERROR, "Module backend_type is not
> + supported or enabled.\n");
>  av_freep(_module);
>  return NULL;
>  }
> --
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH 2/2] avformat/tests/imf: add invalid resource test

2023-04-26 Thread pal
From: Pierre-Anthony Lemieux 

---
 libavformat/tests/imf.c | 65 +
 tests/ref/fate/imf  |  2 ++
 2 files changed, 67 insertions(+)

diff --git a/libavformat/tests/imf.c b/libavformat/tests/imf.c
index 2cacb43f47..cfd84fb8c8 100644
--- a/libavformat/tests/imf.c
+++ b/libavformat/tests/imf.c
@@ -218,6 +218,45 @@ const char *cpl_doc =
 ""
 "";
 
+const char *cpl_bad_resource_doc =
+"http://www.smpte-ra.org/schemas/2067-3/2016\";
+" xmlns:cc=\"http://www.smpte-ra.org/schemas/2067-2/2016\";
+" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\;>"
+"urn:uuid:8713c020-2489-45f5-a9f7-87be539e20b5"
+"2021-07-13T17:06:22Z"
+"FFMPEG"
+"FFMPEG sample content"
+""
+"  "
+"urn:uuid:8e097bb0-cff7-4969-a692-bad47bfb528f"
+"  "
+""
+""
+"false"
+"24"
+"02:10:01.23"
+""
+"24000 1001"
+""
+""
+"urn:uuid:81fed4e5-9722-400a-b9d1-7f2bd21df4b6"
+""
+""
+"urn:uuid:6ae100b0-92d1-41be-9321-85e0933dfc42"
+"urn:uuid:e8ef9653-565c-479c-8039-82d4547973c5"
+""
+""
+"urn:uuid:7d418acb-07a3-4e57-984c-b8ea2f7de4ec"
+"24"
+
"urn:uuid:f00e49a8-0dec-4e6c-95e7-078df988b751"
+""
+""
+""
+""
+""
+""
+"";
+
 const char *cpl_bad_doc = "";
 
 const char *asset_map_doc =
@@ -366,6 +405,27 @@ static int test_bad_cpl_parsing(FFIMFCPL **cpl)
 return 0;
 }
 
+static int test_bad_resource_cpl_parsing(FFIMFCPL **cpl)
+{
+xmlDocPtr doc;
+int ret;
+
+doc = xmlReadMemory(cpl_bad_resource_doc, strlen(cpl_bad_resource_doc), 
NULL, NULL, 0);
+if (doc == NULL) {
+printf("XML parsing failed.\n");
+return 1;
+}
+
+ret = ff_imf_parse_cpl_from_xml_dom(doc, cpl);
+xmlFreeDoc(doc);
+if (ret) {
+printf("CPL parsing failed.\n");
+return ret;
+}
+
+return 0;
+}
+
 static int check_asset_locator_attributes(IMFAssetLocator *asset, 
IMFAssetLocator *expected_asset)
 {
 
@@ -533,5 +593,10 @@ int main(int argc, char *argv[])
 }
 printf(" End failing test \n");
 
+printf(" The following should emit errors \n");
+if (test_bad_resource_cpl_parsing() != 0)
+ret = 1;
+printf(" End emission of errors \n");
+
 return ret;
 }
diff --git a/tests/ref/fate/imf b/tests/ref/fate/imf
index 5093167bc7..fdfed8ac17 100644
--- a/tests/ref/fate/imf
+++ b/tests/ref/fate/imf
@@ -53,3 +53,5 @@ For asset: 4:
  The following should fail 
 CPL parsing failed.
  End failing test 
+ The following should emit errors 
+ End emission of errors 
-- 
2.25.1

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

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


[FFmpeg-devel] [PATCH 1/2] avformat/imf: fix invalid resource handling

2023-04-26 Thread pal
From: Pierre-Anthony Lemieux 

---
 libavformat/imf_cpl.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
index ad84a68b13..a7cf5fa360 100644
--- a/libavformat/imf_cpl.c
+++ b/libavformat/imf_cpl.c
@@ -608,11 +608,10 @@ static int push_main_audio_sequence(xmlNodePtr 
audio_sequence_elem, FFIMFCPL *cp
 ret = fill_trackfile_resource(resource_elem,
   >resources[vt->resource_count],
   cpl);
-vt->resource_count++;
-if (ret) {
+if (ret)
 av_log(NULL, AV_LOG_ERROR, "Invalid Resource\n");
-continue;
-}
+else
+vt->resource_count++;
 
 resource_elem = xmlNextElementSibling(resource_elem);
 }
@@ -691,11 +690,10 @@ static int push_main_image_2d_sequence(xmlNodePtr 
image_sequence_elem, FFIMFCPL
 ret = fill_trackfile_resource(resource_elem,
   
>main_image_2d_track->resources[cpl->main_image_2d_track->resource_count],
   cpl);
-cpl->main_image_2d_track->resource_count++;
-if (ret) {
+if (ret)
 av_log(NULL, AV_LOG_ERROR, "Invalid Resource\n");
-continue;
-}
+else
+cpl->main_image_2d_track->resource_count++;
 
 resource_elem = xmlNextElementSibling(resource_elem);
 }
-- 
2.25.1

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

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


Re: [FFmpeg-devel] [PATCH 0/2] Implement SMPTE 2038 output support over Decklink SDI

2023-04-26 Thread Devin Heitmueller
Hi Marton,

Sorry, I'm now recognizing I should have answered this email prior to
the later one.  Comments inline:

On Tue, Apr 25, 2023 at 5:59 PM Marton Balint  wrote:
> > Regarding the use of avpriv_packet_list() as opposed to
> > avpacket_queue_*, I used the avpacket_queue functions for consistency
> > with the decklink capture module where it is used today.  Also,
> > avpacket_queue is threadsafe while avpriv_packet_list.*() is not.
> > While the threadsafeness is not critical for the VANC case, I have
> > subsequent patches for audio where it is important, and I figured it
> > would more consistent to use the same queue mechanism within decklink
> > for all three (capture, audio output, and vanc output).
>
> Can you explain how thread safety will be relevant for audio? The
> muxer should get packets in a thread safe way, so I don't quite see how
> suddenly it will be needed.

I have a subsequent patch which supports multiple audio output streams
(which may be a mix of PCM and compressed audio).  Those streams need
to be interleaved together before submitting them to the hardware.  I
made a fundamental change to the design such that I employ an
intermediate FIFO which contains the interleaved audio, and the
submission to the hardware is done in the audio callback as we get
close to the scheduling deadline (which runs on a separate thread and
thus the queue needs to be thread-safe).

I am quite confident that considerable discussion will be needed to
explain why I arrived at this design decision, as even I will
acknowledge that it seems ugly at first inspection.  The design has
actually evolved three or four times over the last five years as I had
to address a variety of edge cases found in real-world usage and
working in low-latency environments.

> > That said, I wouldn't specifically object to converting to the
> > avpriv_packet_list functions since thread-safeness isn't really a
> > requirement for this particular case.  It's probably worth noting
> > though that I extended the avpacket_queue method to allow me to peek
> > at the first packet in the queue (which avpriv_packet_list doesn't
> > support today).  Hence converting to avpriv_packet_list would require
> > an equivalent addition to be accepted upstream.
>
> You can access the internals of the PacketList struct, so you can just add
> needed function to your own code, you don't necessarily have to make it
> public. On the other hand, the avpriv_packet_list does not have the
> concept of queue size or queue count, so it is not only thread safety
> that will be missing.

Ok.

> Two things bother me with the decklink queue:
>
> 1) It duplicates the functionality of avpriv_packet_list_put and
> avpriv_packet_list_get, but it seems to me it should not be difficult
> to actually use these get/put functions in the decklink queue as well,
> because it is already using the same packet list struct internally.
> Maybe can you give it a try?

Sure, I can take a look.  I am definitely in favor of using common
functions, and it wasn't until I looked more closely at the code did I
recognize why the author wrote yet another FIFO implementation rather
than using one of the standard public ones.

If we can end up with the decklink queue being a simple wrapper around
avpriv_packet_list() but with an added mutex, then I think that would
be ideal.

> 2) Namespacing of the struct / functions are wrong. Struct is called
> AVPacketQueue, it should be something like DecklinkPacketQueue in order
> to make it clear that it is not a public struct. The function names are
> prefixed with avpacket, which is also wrong. It should be simply
> packet_queue_xxx, av* would imply a public function. And if you
> factorize it to a non-static function, then it should be
> ff_decklink_packet_queue_xxx.

I never really liked the naming either, and agree that it implies the
functionality is public rather than private to decklink.  I can submit
a patch renaming the functions.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 0/2] Implement SMPTE 2038 output support over Decklink SDI

2023-04-26 Thread Devin Heitmueller
Hello Marton,

On Wed, Apr 26, 2023 at 3:36 AM Marton Balint  wrote:
> Okay, I realized there is one thing here I don't understand. What if we
> interleave data packets the same way as others, but we don't wait for them
> in order to start flushing packet queues?
>
> So I wonder, if you removed the AV_CODEC_ID_SMPTE_2038 exception
> from init_muxer when calculating si->nb_interleaved_streams but keep the
> exception in ff_interleave_packet_per_dts, and set
> max_interleave_delta to 1, would that work?

I was actually wondering the same thing after our email exchange
yesterday.  I haven't tried it yet, but I suspect it might very well
result in the 2038 packets not being very far ahead of the video.  We
still need an intermediate data structure to hold onto the 2038
packets (and there could be multiple) before the corresponding video
frame arrives, and a queue is still a reasonable data structure to
store those packets within the decklink module.

Your suggestion might be a good one, and it might change the behavior
such that the packets in general would be more often held in the mux
queue rather than the decklink queue.  But I don't think it changes
anything about the fundamental design, and it doesn't eliminate the
need for stashing the data packets until the corresponding video is to
be sent out.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@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/5] ccfifo: Properly handle CEA-708 captions through framerate conversion

2023-04-26 Thread Devin Heitmueller
Hi Lance,

Thank you for your review.  Comments inline.

On Tue, Apr 25, 2023 at 10:28 AM Lance Wang  wrote:
> > +/* Based on the target FPS, figure out the expected cc_count and
> > number of
> > +   608 tuples per packet.  See ANSI/CTA-708-E Sec 4.3.6.1. */
> > +for (i = 0; i < (sizeof(cc_lookup_vals) / sizeof(struct cc_lookup));
> > i++) {
> >
>
> I prefer to use FF_ARRAY_ELEMS here.

Ok.

> > +if (framerate->num == cc_lookup_vals[i].num &&
> > +framerate->den == cc_lookup_vals[i].den) {
> > +ccf->expected_cc_count = cc_lookup_vals[i].cc_count;
> > +ccf->expected_608 = cc_lookup_vals[i].num_608;
> > +break;
> > +}
> > +}
> > +
> > +if (ccf->expected_608 == 0) {
> > +av_log(ccf->log_ctx, AV_LOG_WARNING, "cc_fifo cannot transcode
> > captions fps=%d/%d\n",
> > +   framerate->num, framerate->den);
> > +return NULL;
> >
>
> why not use goto error?  I feel ccf should be freed.

Good point.  I'll fix that.

>
>
> > +}
> > +
> > +return ccf;
> > +
> > +error:
> > +ff_ccfifo_freep();
> > +return NULL;
> > +}
> > +
> > +int ff_ccfifo_inject(AVCCFifo *ccf, AVFrame *frame)
> > +{
> > +AVFrameSideData *sd;
> > +int cc_filled = 0;
> > +int i;
> > +
> > +if (!ccf)
> > +return 0;
> >
>
> + * @returnZero on success, or negative AVERROR
> + *code on failure.
>
>  why not return error code?  the same to other failure condition.

Ok, so there are legal cases where ccf is NULL and it isn't an error
condition.  If the creation of the FIFO fails due to an unsupported
output framerate, the expectation is that you can continue to call the
inject/extract functions and they will simply do nothing (i.e. it will
work in passthrough mode).  There are two alternatives to this
approach:

1.  Continue to have the FIFO creation fail (returning a NULL
pointer), and then have to make sure every caller of extract/inject
checks for the NULL pointer prior to calling the function.

2.  Have the FIFO creation report the warning but "succeed" and create
the FIFO, and then have the inject/extract functions check some flag
within the ccf structure and do nothing if the flag is set.

I'm open to ideas on the best approach here.

> +
> > +if (ccf->cc_detected == 0 || ccf->expected_cc_count == 0)
> > +return 0;
> > +
> > +sd = av_frame_new_side_data(frame, AV_FRAME_DATA_A53_CC,
> > +ccf->expected_cc_count *
> > CC_BYTES_PER_ENTRY);
> > +if (!sd)
> > +return 0;
> >
>
> same.

Ok.

> > +int ff_ccfifo_extract(AVCCFifo *ccf, AVFrame *frame)
> > +{
> > +int i;
> > +
> > +if (!ccf)
> > +return 0;
> >
>
> + * @returnZero on success, or negative AVERROR
> + *code on failure.
> same question.

Same explanation as for ff_ccfifo_inject() above,

> > +#ifndef AVUTIL_CCFIFO_H
> > +#define AVUTIL_CCFIFO_H
> >
>
> AVUTIL is wrong here

Ok.

>
> > +
> > +#include "libavutil/avutil.h"
> > +#include "libavutil/frame.h"
> > +#include "libavutil/fifo.h"
> > +
> > +typedef struct AVCCFifo AVCCFifo;
> > +
> > +/**
> > + * Allocate an AVCCFifo.
> > + *
> > + * @param sample_fmt  sample format
> > + * @param channelsnumber of channels
> > + * @param nb_samples  initial allocation size, in samples
> >
>
> This is mismatch comments

Ok.

> > + * @returnnewly allocated AVCCFifo, or NULL on error
> > + */
> > +AVCCFifo *ff_ccfifo_alloc(AVRational *framerate, void *log_ctx);
> > +
> > +/**
> > + * Free an AVCCFifo
> > + *
> > + * @param ccf Pointer to the pointer to the AVCCFifo which should be freed
> > + * @note `*ptr = NULL` is safe and leads to no action.
> > + */
> > +void ff_ccfifo_freep(AVCCFifo **ccf);
> > +
> > +
> > +/**
> > + * Read a frame into a CC Fifo
> >
>
> It's not clear I think.

I don't love the "inject/extract" naming, but I couldn't think of a
better name (I've actually renamed those functions a couple of times
over the years I had this code in a non-upstream tree).  In particular
because the extract function both extracts/removes the bytes from the
frame and inserts them into the queue, the naming can be a bit
confusing (and vice versa for the inject function).

I welcome suggestions on a better name that more clearly describes
what the two functions do.

Again, thanks for your comments.  The majority of the issues you
raised are simple enough to fix, and I welcome suggestions on the
others.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/mediacodec: Add AV1 encoder

2023-04-26 Thread Samuel Raposo Vieira Mira
Connected FFmpeg to Mediacodec AV1 encoder
---
configure   |   1 +
libavcodec/Makefile |   1 +
libavcodec/allcodecs.c  |   1 +
libavcodec/mediacodec_wrapper.c |  12 
libavcodec/mediacodecenc.c  | 115 
5 files changed, 118 insertions(+), 12 deletions(-)

diff --git a/configure b/configure
index bb7be67676..0a60deac65 100755
--- a/configure
+++ b/configure
@@ -3162,6 +3162,7 @@ aac_mf_encoder_deps="mediafoundation"
ac3_mf_encoder_deps="mediafoundation"
av1_cuvid_decoder_deps="cuvid CUVIDAV1PICPARAMS"
av1_mediacodec_decoder_deps="mediacodec"
+av1_mediacodec_encoder_deps="mediacodec"
av1_nvenc_encoder_deps="nvenc NV_ENC_PIC_PARAMS_AV1"
av1_nvenc_encoder_select="atsc_a53"
h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b0971ce833..166f77f12a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -253,6 +253,7 @@ OBJS-$(CONFIG_AURA2_DECODER)   += aura.o
OBJS-$(CONFIG_AV1_DECODER) += av1dec.o
OBJS-$(CONFIG_AV1_CUVID_DECODER)   += cuviddec.o
OBJS-$(CONFIG_AV1_MEDIACODEC_DECODER)  += mediacodecdec.o
+OBJS-$(CONFIG_AV1_MEDIACODEC_ENCODER)  += mediacodecenc.o
OBJS-$(CONFIG_AV1_NVENC_ENCODER)   += nvenc_av1.o nvenc.o
OBJS-$(CONFIG_AV1_QSV_ENCODER) += qsvenc_av1.o
OBJS-$(CONFIG_AVRN_DECODER)+= avrndec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 8eeed34e57..f583aad860 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -836,6 +836,7 @@ extern const FFCodec ff_libaom_av1_decoder;
extern const FFCodec ff_av1_decoder;
extern const FFCodec ff_av1_cuvid_decoder;
extern const FFCodec ff_av1_mediacodec_decoder;
+extern const FFCodec ff_av1_mediacodec_encoder;
extern const FFCodec ff_av1_nvenc_encoder;
extern const FFCodec ff_av1_qsv_decoder;
extern const FFCodec ff_av1_qsv_encoder;
diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 1c29bb7406..015f275a0f 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -35,6 +35,8 @@
#include "ffjni.h"
#include "mediacodec_wrapper.h"
+#include "libavutil/pixdesc.h"
+
struct JNIAMediaCodecListFields {
 jclass mediacodec_list_class;
@@ -345,6 +347,11 @@ int 
ff_AMediaCodecProfile_getProfileFromAVCodecContext(AVCodecContext *avctx)
 static const int MPEG4ProfileAdvancedScalable = 0x4000;
 static const int MPEG4ProfileAdvancedSimple   = 0x8000;
+static const int AV1ProfileMain8  = 0x1;
+static const int AV1ProfileMain10 = 0x2;
+static const int AV1ProfileMain10HDR10 = 0x1000;
+static const int AV1ProfileMain10HDR10Plus = 0x2000;
+
 // Unused yet.
 (void)AVCProfileConstrainedHigh;
 (void)HEVCProfileMain10HDR10;
@@ -353,6 +360,8 @@ int 
ff_AMediaCodecProfile_getProfileFromAVCodecContext(AVCodecContext *avctx)
 (void)VP9Profile3HDR;
 (void)VP9Profile2HDR10Plus;
 (void)VP9Profile3HDR10Plus;
+(void)AV1ProfileMain10HDR10;
+(void)AV1ProfileMain10HDR10Plus;
 if (avctx->codec_id == AV_CODEC_ID_H264) {
 switch(avctx->profile) {
@@ -436,6 +445,9 @@ int 
ff_AMediaCodecProfile_getProfileFromAVCodecContext(AVCodecContext *avctx)
 default:
 break;
 }
+} else if(avctx->codec_id == AV_CODEC_ID_AV1) {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
+return desc != NULL && desc->comp[0].depth == 8? AV1ProfileMain8 : 
AV1ProfileMain10;
 }
 return -1;
diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
index e4b583a542..10da43c3e7 100644
--- a/libavcodec/mediacodecenc.c
+++ b/libavcodec/mediacodecenc.c
@@ -170,6 +170,9 @@ static av_cold int mediacodec_init(AVCodecContext *avctx)
 case AV_CODEC_ID_MPEG4:
 codec_mime = "video/mp4v-es";
 break;
+case AV_CODEC_ID_AV1:
+codec_mime = "video/av01";
+break;
 default:
 av_assert0(0);
 }
@@ -779,16 +782,16 @@ DECLARE_MEDIACODEC_ENCODER(hevc, "H.265", 
AV_CODEC_ID_HEVC)
 enum MediaCodecVP9Level {
 VP9Level1  = 0x1,
-VP9Level11  = 0x2,
+VP9Level11 = 0x2,
 VP9Level2  = 0x4,
-VP9Level21  = 0x8,
-VP9Level3 = 0x10,
+VP9Level21 = 0x8,
+VP9Level3  = 0x10,
 VP9Level31 = 0x20,
 VP9Level4  = 0x40,
-VP9Level41  = 0x80,
-VP9Level5 = 0x100,
+VP9Level41 = 0x80,
+VP9Level5  = 0x100,
 VP9Level51 = 0x200,
-VP9Level52  = 0x400,
+VP9Level52 = 0x400,
 VP9Level6  = 0x800,
 VP9Level61 = 0x1000,
 VP9Level62 = 0x2000,
@@ -837,15 +840,15 @@ DECLARE_MEDIACODEC_ENCODER(vp9, "VP9", AV_CODEC_ID_VP9)
 enum MediaCodecMpeg4Level {
 MPEG4Level0  = 0x01,
-MPEG4Level0b  = 0x02,
-MPEG4Level1 = 0x04,
+MPEG4Level0b = 0x02,
+MPEG4Level1  = 0x04,
 MPEG4Level2  = 0x08,
-MPEG4Level3 = 0x10,
+MPEG4Level3  = 0x10,
 MPEG4Level3b = 0x18,
-MPEG4Level4 = 0x20,
-MPEG4Level4a  

[FFmpeg-devel] [PATCH] avcodec/mediacodec: Add VP8 encoder

2023-04-26 Thread Samuel Raposo Vieira Mira
Connected FFmpeg to Mediacodec VP8 encoder
---
configure   |  1 +
libavcodec/Makefile |  1 +
libavcodec/allcodecs.c  |  1 +
libavcodec/mediacodec_wrapper.c |  4 
libavcodec/mediacodecenc.c  | 29 +
5 files changed, 36 insertions(+)

diff --git a/configure b/configure
index 0a60deac65..a54398c57f 100755
--- a/configure
+++ b/configure
@@ -3240,6 +3240,7 @@ vc1_qsv_decoder_select="qsvdec"
vc1_v4l2m2m_decoder_deps="v4l2_m2m vc1_v4l2_m2m"
vp8_cuvid_decoder_deps="cuvid"
vp8_mediacodec_decoder_deps="mediacodec"
+vp8_mediacodec_encoder_deps="mediacodec"
vp8_qsv_decoder_select="qsvdec"
vp8_rkmpp_decoder_deps="rkmpp"
vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 166f77f12a..aacea4f4b6 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -767,6 +767,7 @@ OBJS-$(CONFIG_VP7_DECODER) += vp8.o vpx_rac.o
OBJS-$(CONFIG_VP8_DECODER) += vp8.o vpx_rac.o
OBJS-$(CONFIG_VP8_CUVID_DECODER)   += cuviddec.o
OBJS-$(CONFIG_VP8_MEDIACODEC_DECODER)  += mediacodecdec.o
+OBJS-$(CONFIG_VP8_MEDIACODEC_ENCODER)  += mediacodecenc.o
OBJS-$(CONFIG_VP8_QSV_DECODER) += qsvdec.o
OBJS-$(CONFIG_VP8_RKMPP_DECODER)   += rkmppdec.o
OBJS-$(CONFIG_VP8_VAAPI_ENCODER)   += vaapi_encode_vp8.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f583aad860..184bb8521f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -881,6 +881,7 @@ extern const FFCodec ff_prores_videotoolbox_encoder;
extern const FFCodec ff_vc1_cuvid_decoder;
extern const FFCodec ff_vp8_cuvid_decoder;
extern const FFCodec ff_vp8_mediacodec_decoder;
+extern const FFCodec ff_vp8_mediacodec_encoder;
extern const FFCodec ff_vp8_qsv_decoder;
extern const FFCodec ff_vp8_v4l2m2m_encoder;
extern const FFCodec ff_vp8_vaapi_encoder;
diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 015f275a0f..b088cd2945 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -321,6 +321,8 @@ int 
ff_AMediaCodecProfile_getProfileFromAVCodecContext(AVCodecContext *avctx)
 static const int HEVCProfileMain10HDR10 = 0x1000;
 static const int HEVCProfileMain10HDR10Plus = 0x2000;
+static const int VP8ProfileMain = 0x01;
+
 static const int VP9Profile0 = 0x01;
 static const int VP9Profile1 = 0x02;
 static const int VP9Profile2 = 0x04;
@@ -396,6 +398,8 @@ int 
ff_AMediaCodecProfile_getProfileFromAVCodecContext(AVCodecContext *avctx)
 case FF_PROFILE_HEVC_MAIN_10:
 return HEVCProfileMain10;
 }
+} else if (avctx->codec_id == AV_CODEC_ID_VP8) {
+return VP8ProfileMain;
 } else if (avctx->codec_id == AV_CODEC_ID_VP9) {
 switch (avctx->profile) {
 case FF_PROFILE_VP9_0:
diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
index 10da43c3e7..ff28d5f14a 100644
--- a/libavcodec/mediacodecenc.c
+++ b/libavcodec/mediacodecenc.c
@@ -164,6 +164,9 @@ static av_cold int mediacodec_init(AVCodecContext *avctx)
 case AV_CODEC_ID_HEVC:
 codec_mime = "video/hevc";
 break;
+case AV_CODEC_ID_VP8:
+codec_mime = "video/x-vnd.on2.vp8";
+break;
 case AV_CODEC_ID_VP9:
 codec_mime = "video/x-vnd.on2.vp9";
 break;
@@ -778,6 +781,32 @@ DECLARE_MEDIACODEC_ENCODER(hevc, "H.265", AV_CODEC_ID_HEVC)
 #endif  // CONFIG_HEVC_MEDIACODEC_ENCODER
+#if CONFIG_VP8_MEDIACODEC_ENCODER
+
+enum MediaCodecVP8Level {
+VP8Level_Version0 = 0x01,
+VP8Level_Version1 = 0x02,
+VP8Level_Version2 = 0x04,
+VP8Level_Version3 = 0x08,
+};
+
+static const AVOption vp8_options[] = {
+COMMON_OPTION
+{ "level", "Specify tier and level",
+OFFSET(level), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE, 
"level" },
+{ "V0","Level Version 0",
+0, AV_OPT_TYPE_CONST, { .i64 = VP8Level_Version0 },  0, 0, VE, 
 "level" },
+{ "V1","Level Version 1",
+0, AV_OPT_TYPE_CONST, { .i64 = VP8Level_Version1 },  0, 0, VE, 
 "level" },
+{ "V2","Level Version 2",
+0, AV_OPT_TYPE_CONST, { .i64 = VP8Level_Version2 },  0, 0, VE, 
 "level" },
+{ "V3","Level Version 3",
+0, AV_OPT_TYPE_CONST, { .i64 = VP8Level_Version3 },  0, 0, VE, 
 "level" },
+{ NULL, }
+};
+
+#endif  // CONFIG_VP8_MEDIACODEC_ENCODER
+
#if CONFIG_VP9_MEDIACODEC_ENCODER
 enum MediaCodecVP9Level {
--




avcodec-mediacodec-add-vp8.patch.b64
Description: avcodec-mediacodec-add-vp8.patch.b64
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavu/avassert: include config.h

2023-04-26 Thread Nicolas George
Hendrik Leppkes (12023-04-26):
> This is an installed header, it cannot depend on config.h

Thanks for spotting it, that was counter-intuitive since config.h is
almost indispensable to its workings.

Updated version attached, similar to what exists in common.h.

Regards,

-- 
  Nicolas George
From e1a5ac8ba11d9321e3d0f8bebded805c779a17c1 Mon Sep 17 00:00:00 2001
From: Nicolas George 
Date: Wed, 26 Apr 2023 14:29:29 +0200
Subject: [PATCH] lavu/avassert: include config.h

Fix setting the assert level.

Signed-off-by: Nicolas George 
---
 libavutil/avassert.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavutil/avassert.h b/libavutil/avassert.h
index 51e462bbae..1895fb7551 100644
--- a/libavutil/avassert.h
+++ b/libavutil/avassert.h
@@ -28,6 +28,9 @@
 #define AVUTIL_AVASSERT_H
 
 #include 
+#ifdef HAVE_AV_CONFIG_H
+#   include "config.h"
+#endif
 #include "log.h"
 #include "macros.h"
 
-- 
2.39.2



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

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


Re: [FFmpeg-devel] [PATCH 2/2] lavu/avassert: include config.h

2023-04-26 Thread Hendrik Leppkes
On Wed, Apr 26, 2023 at 2:32 PM Nicolas George  wrote:
>
> Fix setting the assert level.
>
> Signed-off-by: Nicolas George 
> ---
>  libavutil/avassert.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/avassert.h b/libavutil/avassert.h
> index 51e462bbae..8f3f72c80c 100644
> --- a/libavutil/avassert.h
> +++ b/libavutil/avassert.h
> @@ -28,6 +28,7 @@
>  #define AVUTIL_AVASSERT_H
>
>  #include 
> +#include "config.h"
>  #include "log.h"
>  #include "macros.h"
>

This is an installed header, it cannot depend on config.h

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

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/avcodec: fix UB NULL+0

2023-04-26 Thread zhilizhao(赵志立)



> On Apr 12, 2023, at 01:49, Zhao Zhili  wrote:
> 
> From: Zhao Zhili 
> 
> ---
> libavcodec/avcodec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index fb1362290f..5a96899d50 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -44,10 +44,11 @@
> 
> int avcodec_default_execute(AVCodecContext *c, int (*func)(AVCodecContext 
> *c2, void *arg2), void *arg, int *ret, int count, int size)
> {
> -int i;
> +size_t i;
> 
> for (i = 0; i < count; i++) {
> -int r = func(c, (char *)arg + i * size);
> +size_t offset = i * size;
> +int r = func(c, FF_PTR_ADD((char *)arg, offset));
> if (ret)
> ret[i] = r;
> }
> -- 
> 2.25.1
> 

Will apply soon unless there is objection.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavu/avassert: include config.h

2023-04-26 Thread Nicolas George
Fix setting the assert level.

Signed-off-by: Nicolas George 
---
 libavutil/avassert.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/avassert.h b/libavutil/avassert.h
index 51e462bbae..8f3f72c80c 100644
--- a/libavutil/avassert.h
+++ b/libavutil/avassert.h
@@ -28,6 +28,7 @@
 #define AVUTIL_AVASSERT_H
 
 #include 
+#include "config.h"
 #include "log.h"
 #include "macros.h"
 
-- 
2.39.2

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

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


[FFmpeg-devel] [PATCH 1/2] lavc/intrax8: fix an assert

2023-04-26 Thread Nicolas George
Signed-off-by: Nicolas George 
---
 libavcodec/intrax8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/intrax8.c b/libavcodec/intrax8.c
index e4c8b96c9c..c5c6727282 100644
--- a/libavcodec/intrax8.c
+++ b/libavcodec/intrax8.c
@@ -109,7 +109,7 @@ static inline void x8_select_ac_table(IntraX8Context *const 
w, int mode)
 table_index   = get_bits(w->gb, 3);
 // 2 modes use same tables
 w->j_ac_vlc_table[mode] = j_ac_vlc[w->quant < 13][mode >> 
1][table_index].table;
-av_assert2(w->j_ac_vlc[mode]);
+av_assert2(j_ac_vlc[mode]);
 }
 
 static inline int x8_get_orient_vlc(IntraX8Context *w)
-- 
2.39.2

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

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


Re: [FFmpeg-devel] [PATCH 1/3] lavf/dv: do not set video timebase more than once

2023-04-26 Thread Michael Niedermayer
On Mon, Apr 24, 2023 at 05:55:51PM +0200, Anton Khirnov wrote:
> Current code will call avpriv_set_pts_info() for each video frame,
> possibly setting a different timebase if the stream framerate changes.
> This violates API conventions, as the timebase is supposed to stay
> constant after stream creation.
> 
> Change the demuxer to set a single timebase that is fine enough to
> handle all supported DV framerates.
> 
> The seek tests change slightly because the new timebase is more
> granular.
> ---
>  libavcodec/dv.h   |  3 +++
>  libavformat/dv.c  | 25 -
>  tests/ref/seek/lavf-dv| 16 
>  tests/ref/seek/vsynth_lena-dv | 24 
>  tests/ref/seek/vsynth_lena-dv-411 | 24 
>  tests/ref/seek/vsynth_lena-dv-50  | 24 
>  6 files changed, 67 insertions(+), 49 deletions(-)

This breaks:

./ffmpeg -ss 4:56 -i ~/tickets/4086/Oca-Agu\ 1995.avi -codec copy -t 1 
-bitexact 4086-30frames.dv
(the file is empty after the patch)

The file seems no longer available on the original link and a little big
ill put it in your home directory on the server probably in 30+min or so.
once you are done with it please delete it off the server so it doesnt eat
diskspace

thx


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

What does censorship reveal? It reveals fear. -- Julian Assange


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] lavf/mp3enc: write attached pictures in the stream order

2023-04-26 Thread Anton Khirnov
Not in the order in which the packets were passed to the muxer, which
may be arbitrary. This guarantees stable and predictable output.

Changes the result of fate-cover-art-mp3-id3v2-remux, where the pictures
are now ordered correctly in the file.
---
 libavformat/mp3enc.c | 64 ++--
 tests/ref/fate/cover-art-mp3-id3v2-remux | 22 
 2 files changed, 60 insertions(+), 26 deletions(-)

diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index 5e81f72a59a..da33272e4e9 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -96,6 +96,10 @@ static int id3v1_create_tag(AVFormatContext *s, uint8_t *buf)
 // size of the XING/LAME data, starting from the Xing tag
 #define XING_SIZE 156
 
+typedef struct MP3StreamData {
+AVPacket *apic;
+} MP3StreamData;
+
 typedef struct MP3Context {
 const AVClass *class;
 ID3v2EncContext id3;
@@ -129,8 +133,8 @@ typedef struct MP3Context {
 
 /* index of the audio stream */
 int audio_stream_idx;
-/* number of attached pictures we still need to write */
-int pics_to_write;
+/* number of attached pictures for which we did not yet get a packet */
+int pics_to_buffer;
 
 /* audio packets are queued here until we get all the attached pictures */
 PacketList queue;
@@ -385,6 +389,20 @@ static int mp3_queue_flush(AVFormatContext *s)
 AVPacket *const pkt = ffformatcontext(s)->pkt;
 int ret = 0, write = 1;
 
+// write all buffered attached pictures
+for (int i = 0; i < s->nb_streams; i++) {
+MP3StreamData *stp = s->streams[i]->priv_data;
+
+if (!stp || !stp->apic)
+continue;
+
+ret = ff_id3v2_write_apic(s, >id3, stp->apic);
+if (ret < 0)
+return ret;
+
+av_packet_free(>apic);
+}
+
 ff_id3v2_finish(>id3, s->pb, s->metadata_header_padding);
 mp3_write_xing(s);
 
@@ -473,7 +491,7 @@ static int mp3_write_trailer(struct AVFormatContext *s)
 uint8_t buf[ID3v1_TAG_SIZE];
 MP3Context *mp3 = s->priv_data;
 
-if (mp3->pics_to_write) {
+if (mp3->pics_to_buffer) {
 av_log(s, AV_LOG_WARNING, "No packets were sent for some of the "
"attached pictures.\n");
 mp3_queue_flush(s);
@@ -523,35 +541,40 @@ static int mp3_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 MP3Context *mp3 = s->priv_data;
 
 if (pkt->stream_index == mp3->audio_stream_idx) {
-if (mp3->pics_to_write) {
+if (mp3->pics_to_buffer) {
 /* buffer audio packets until we get all the pictures */
 int ret = avpriv_packet_list_put(>queue, pkt, NULL, 0);
 
 if (ret < 0) {
 av_log(s, AV_LOG_WARNING, "Not enough memory to buffer audio. 
Skipping picture streams\n");
-mp3->pics_to_write = 0;
+mp3->pics_to_buffer = 0;
 mp3_queue_flush(s);
 return mp3_write_audio_packet(s, pkt);
 }
 } else
 return mp3_write_audio_packet(s, pkt);
 } else {
+AVStream   *st = s->streams[pkt->stream_index];
+MP3StreamData *stp = st->priv_data;
 int ret;
 
 /* warn only once for each stream */
-if (s->streams[pkt->stream_index]->nb_frames == 1) {
+if (st->nb_frames == 1) {
 av_log(s, AV_LOG_WARNING, "Got more than one picture in stream %d,"
" ignoring.\n", pkt->stream_index);
 }
-if (!mp3->pics_to_write || s->streams[pkt->stream_index]->nb_frames >= 
1)
+if (!mp3->pics_to_buffer || st->nb_frames >= 1)
 return 0;
 
-if ((ret = ff_id3v2_write_apic(s, >id3, pkt)) < 0)
-return ret;
-mp3->pics_to_write--;
+av_assert0(!stp->apic);
+stp->apic = av_packet_clone(pkt);
+if (!stp->apic)
+return AVERROR(ENOMEM);
+
+mp3->pics_to_buffer--;
 
 /* flush the buffered audio packets */
-if (!mp3->pics_to_write &&
+if (!mp3->pics_to_buffer &&
 (ret = mp3_queue_flush(s)) < 0)
 return ret;
 }
@@ -588,7 +611,11 @@ static int mp3_init(struct AVFormatContext *s)
 return AVERROR(EINVAL);
 }
 mp3->audio_stream_idx = i;
-} else if (st->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
+} else if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
+st->priv_data = av_mallocz(sizeof(MP3StreamData));
+if (!st->priv_data)
+return AVERROR(ENOMEM);
+} else {
 av_log(s, AV_LOG_ERROR, "Only audio streams and pictures are 
allowed in MP3.\n");
 return AVERROR(EINVAL);
 }
@@ -597,9 +624,9 @@ static int mp3_init(struct AVFormatContext *s)
 av_log(s, AV_LOG_ERROR, "No audio stream present.\n");
 return AVERROR(EINVAL);
 }
-mp3->pics_to_write = s->nb_streams - 1;
+mp3->pics_to_buffer = s->nb_streams - 

Re: [FFmpeg-devel] [PATCH] lavu: header and documentation for AVWriter

2023-04-26 Thread Anton Khirnov
Quoting Nicolas George (2023-04-25 19:11:44)
> Hi.
> 
> I finally have some tome to go at this again.
> 
> Totalizing this thread, the previous discussions and the few private
> mails I received, I conclude there is significant more support than
> opposition to AVWriter, so I am moving forward with polishing and
> pushing the implementation.

This project is developed in the open, private emails, rumors, and
hearsay do not count as arguments.

This code is unnecessary bloat that adds nothing of value to the
project.

-- 
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/options_table: reorder nokey after nointra

2023-04-26 Thread Steven Liu
Zhao Zhili  于2023年4月26日周三 10:49写道:
>
> From: Zhao Zhili 
>
> So the values are in ascending order.
>
> Signed-off-by: Zhao Zhili 
> ---
>  libavcodec/options_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index f331ce2861..4f5918c7f6 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -259,8 +259,8 @@ static const AVOption avcodec_options[] = {
>  {"default" , "discard useless frames",  0, 
> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_DEFAULT }, INT_MIN, INT_MAX, V|D, 
> "avdiscard"},
>  {"noref"   , "discard all non-reference frames",0, 
> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONREF  }, INT_MIN, INT_MAX, V|D, 
> "avdiscard"},
>  {"bidir"   , "discard all bidirectional frames",0, 
> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_BIDIR   }, INT_MIN, INT_MAX, V|D, 
> "avdiscard"},
> -{"nokey"   , "discard all frames except keyframes", 0, 
> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONKEY  }, INT_MIN, INT_MAX, V|D, 
> "avdiscard"},
>  {"nointra" , "discard all frames except I frames",  0, 
> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONINTRA}, INT_MIN, INT_MAX, V|D, 
> "avdiscard"},
> +{"nokey"   , "discard all frames except keyframes", 0, 
> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONKEY  }, INT_MIN, INT_MAX, V|D, 
> "avdiscard"},
>  {"all" , "discard all frames",  0, 
> AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_ALL }, INT_MIN, INT_MAX, V|D, 
> "avdiscard"},
>  {"bidir_refine", "refine the two motion vectors used in bidirectional 
> macroblocks", OFFSET(bidir_refine), AV_OPT_TYPE_INT, {.i64 = 1 }, 0, 4, V|E},
>  {"keyint_min", "minimum interval between IDR-frames", OFFSET(keyint_min), 
> AV_OPT_TYPE_INT, {.i64 = 25 }, INT_MIN, INT_MAX, V|E},
> --
> 2.25.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


LGTM


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

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


Re: [FFmpeg-devel] [PATCH 0/2] Implement SMPTE 2038 output support over Decklink SDI

2023-04-26 Thread Marton Balint



On Mon, 24 Apr 2023, Devin Heitmueller wrote:


Hello Marton,

Thanks for reviewing.  Comments inline:

On Sun, Apr 23, 2023 at 2:43 PM Marton Balint  wrote:

In general, queueing packets in specific components should be avoided if
possible. Muxed packets are normally ordered by DTS and stream id, generic
code ensures that. If you want something other than that, then I think
the perferred way of doing it is by providing a custom interleave
function. (e.g. to ensure you get data packets before video even if data
stream has a higher stream ID.)


To be clear, using a queue was not first choice.  It's the result of
trying different approaches, and I'm open to constructive suggestions
on alternatives.

While what you're are saying is correct "in general", there are some
really important reasons why it doesn't work in this case.  Permit me
to explain...

By default, the behavior of the mux interleaver is to wait until there
is at least one packet available for each stream before writing to the
output module (in this case decklink).  However data formats such as
SMPTE ST2038 are considered to be "sparse" as there isn't necessarily
a continuous stream of packets like with video and audio (there may be
many seconds between packets, or no packets at all).  As a result you
can't wait for a packet to be available on all streams since on some
streams it will simply wait continuously until hitting the
max_interleave_delta, at which point it will burst out everything in
the queue.  This would cause stalls and/or stuttering playback on the
decklink output.

To accommodate these sparse streams we added code to mux.c to not wait
for 2038 packets.  A side-effect of that though is that packets will
be sent through as soon as they hit the mux, which in most cases will
be significantly ahead of the video (potentially hundreds of
milliseconds).  This can easily be seen experimentally by adding an
av_log() line to ff_decklink_write_packet(), which will show in many
cases the PTS values of the data frames being sent 20+ frames before
the corresponding video.


Okay, I realized there is one thing here I don't understand. What if we 
interleave data packets the same way as others, but we don't wait for them 
in order to start flushing packet queues?


So I wonder, if you removed the AV_CODEC_ID_SMPTE_2038 exception
from init_muxer when calculating si->nb_interleaved_streams but keep the 
exception in ff_interleave_packet_per_dts, and set 
max_interleave_delta to 1, would that work?


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