Re: [FFmpeg-devel] [PATCH] avformat/rtpdec: attach producer reference time if available
Hi James,
This patch had a bug in the calculation of prft time. I did not account for
the timebase differences between media timestamp and wall clock. I have
sent a new patch for review.
-Alok
On Tue, Mar 23, 2021 at 3:04 PM James Almer wrote:
> On 3/23/2021 6:29 PM, Alok Priyadarshi wrote:
> > This produces true wallclock time at rtp source instead of the
> > local wallclock time at rtp client.
> > ---
> > libavformat/internal.h | 8
> > libavformat/rtpdec.c | 20
> > libavformat/utils.c| 9 +
> > 3 files changed, 37 insertions(+)
> >
> > diff --git a/libavformat/internal.h b/libavformat/internal.h
> > index 17a6ab07d3..1e10cde00e 100644
> > --- a/libavformat/internal.h
> > +++ b/libavformat/internal.h
> > @@ -254,6 +254,14 @@ uint64_t ff_ntp_time(void);
> >*/
> > uint64_t ff_get_formatted_ntp_time(uint64_t ntp_time_us);
> >
> > +/**
> > + * Parse the NTP time in micro seconds (since NTP epoch).
> > + *
> > + * @param ntp_ts NTP time stamp formatted as per the RFC-5905.
> > + * @return the time in micro seconds (since NTP epoch)
> > + */
> > +uint64_t ff_parse_ntp_time(uint64_t ntp_ts);
> > +
> > /**
> >* Append the media-specific SDP fragment for the media stream c
> >* to the buffer buff.
> > diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> > index 3d5b200099..b935dba1b8 100644
> > --- a/libavformat/rtpdec.c
> > +++ b/libavformat/rtpdec.c
> > @@ -30,6 +30,7 @@
> > #include "url.h"
> > #include "rtpdec.h"
> > #include "rtpdec_formats.h"
> > +#include "internal.h"
> >
> > #define MIN_FEEDBACK_INTERVAL 20 /* 200 ms in us */
> >
> > @@ -583,6 +584,19 @@ void ff_rtp_parse_set_crypto(RTPDemuxContext *s,
> const char *suite,
> > s->srtp_enabled = 1;
> > }
> >
> > +static int rtp_set_prft(RTPDemuxContext *s, AVPacket *pkt, uint32_t
> timestamp) {
> > +AVProducerReferenceTime *prft =
> > +(AVProducerReferenceTime *) av_packet_new_side_data(
> > +pkt, AV_PKT_DATA_PRFT, sizeof(AVProducerReferenceTime));
> > +if (!prft)
> > +return AVERROR(ENOMEM);
> > +
> > +prft->wallclock = ff_parse_ntp_time(s->last_rtcp_ntp_time) -
> NTP_OFFSET_US +
> > + timestamp - s->last_rtcp_timestamp;
> > +prft->flags = 24;
> > +return 0;
> > +}
> > +
> > /**
> >* This was the second switch in rtp_parse packet.
> >* Normalizes time, if required, sets stream_index, etc.
> > @@ -594,6 +608,12 @@ static void finalize_packet(RTPDemuxContext *s,
> AVPacket *pkt, uint32_t timestam
> > if (timestamp == RTP_NOTS_VALUE)
> > return;
> >
> > +if (s->last_rtcp_ntp_time != AV_NOPTS_VALUE) {
> > +if (rtp_set_prft(s, pkt, timestamp) < 0) {
> > +av_log(s->ic, AV_LOG_WARNING, "rtpdec: failed to set prft");
> > +}
> > +}
> > +
> > if (s->last_rtcp_ntp_time != AV_NOPTS_VALUE && s->ic->nb_streams >
> 1) {
> > int64_t addend;
> > int delta_timestamp;
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 7e5767ec60..569922beaf 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4734,6 +4734,15 @@ uint64_t ff_get_formatted_ntp_time(uint64_t
> ntp_time_us)
> > return ntp_ts;
> > }
> >
> > +uint64_t ff_parse_ntp_time(uint64_t ntp_ts)
> > +{
> > +uint64_t sec = ntp_ts >> 32;
> > +uint64_t frac_part = ntp_ts & 0xULL;
> > +uint64_t usec = (frac_part * 100) / 0xULL;
> > +
> > +return (sec * 100) + usec;
> > +}
> > +
> > int av_get_frame_filename2(char *buf, int buf_size, const char *path,
> int number, int flags)
> > {
> > const char *p;
>
> Applied, thanks.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/rtpdec: Fix prft wallclock time.
Timestamp difference is available in media timebase (1/90K) where as
rtcp time is in the default microseconds timebase. This patch fixes
the calculated prft wallclock time by rescaling the timestamp delta
to the microseconds timebase.
---
libavformat/rtpdec.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index b935dba1b8..21c1d01785 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -585,14 +585,19 @@ void ff_rtp_parse_set_crypto(RTPDemuxContext *s, const
char *suite,
}
static int rtp_set_prft(RTPDemuxContext *s, AVPacket *pkt, uint32_t timestamp)
{
+int64_t rtcp_time, delta_timestamp, delta_time;
+
AVProducerReferenceTime *prft =
(AVProducerReferenceTime *) av_packet_new_side_data(
pkt, AV_PKT_DATA_PRFT, sizeof(AVProducerReferenceTime));
if (!prft)
return AVERROR(ENOMEM);
-prft->wallclock = ff_parse_ntp_time(s->last_rtcp_ntp_time) - NTP_OFFSET_US
+
- timestamp - s->last_rtcp_timestamp;
+rtcp_time = ff_parse_ntp_time(s->last_rtcp_ntp_time) - NTP_OFFSET_US;
+delta_timestamp = (int64_t)timestamp - (int64_t)s->last_rtcp_timestamp;
+delta_time = av_rescale_q(delta_timestamp, s->st->time_base,
AV_TIME_BASE_Q);
+
+prft->wallclock = rtcp_time + delta_time;
prft->flags = 24;
return 0;
}
--
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] avfilter/overlay_cuda: fix framesync with embedded PGS subtitle
applied smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/hwupload_cuda: add YUVA420P format support
applied smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/pthread_frame: Factor initializing single thread out
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/pthread_frame.c | 127 -
> 1 file changed, 68 insertions(+), 59 deletions(-)
>
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 7bcb9a7bcc..311d6ed771 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -763,52 +763,12 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
> thread_count)
> avctx->codec = NULL;
> }
>
> -int ff_frame_thread_init(AVCodecContext *avctx)
> +static av_cold int init_thread(PerThreadContext *p,
> + FrameThreadContext *fctx, AVCodecContext
> *avctx,
> + AVCodecContext *src, const AVCodec *codec,
> int first)
> {
> -int thread_count = avctx->thread_count;
> -const AVCodec *codec = avctx->codec;
> -AVCodecContext *src = avctx;
> -FrameThreadContext *fctx;
> -int i, err = 0;
> -
> -if (!thread_count) {
> -int nb_cpus = av_cpu_count();
> -// use number of cores + 1 as thread count if there is more than one
> -if (nb_cpus > 1)
> -thread_count = avctx->thread_count = FFMIN(nb_cpus + 1,
> MAX_AUTO_THREADS);
> -else
> -thread_count = avctx->thread_count = 1;
> -}
> -
> -if (thread_count <= 1) {
> -avctx->active_thread_type = 0;
> -return 0;
> -}
> -
> -avctx->internal->thread_ctx = fctx =
> av_mallocz(sizeof(FrameThreadContext));
> -if (!fctx)
> -return AVERROR(ENOMEM);
> -
> -fctx->threads = av_mallocz_array(thread_count, sizeof(PerThreadContext));
> -if (!fctx->threads) {
> -av_freep(>internal->thread_ctx);
> -return AVERROR(ENOMEM);
> -}
> -
> -pthread_mutex_init(>buffer_mutex, NULL);
> -pthread_mutex_init(>hwaccel_mutex, NULL);
> -pthread_mutex_init(>async_mutex, NULL);
> -pthread_cond_init(>async_cond, NULL);
> -
> -fctx->async_lock = 1;
> -fctx->delaying = 1;
> -
> -if (codec->type == AVMEDIA_TYPE_VIDEO)
> -avctx->delay = src->thread_count - 1;
> -
> -for (i = 0; i < thread_count; i++) {
> AVCodecContext *copy = av_malloc(sizeof(AVCodecContext));
> -PerThreadContext *p = >threads[i];
> +int err;
>
> pthread_mutex_init(>mutex, NULL);
> pthread_mutex_init(>progress_mutex, NULL);
> @@ -819,22 +779,19 @@ int ff_frame_thread_init(AVCodecContext *avctx)
> p->frame = av_frame_alloc();
> if (!p->frame) {
> av_freep();
> -err = AVERROR(ENOMEM);
> -goto error;
> +return AVERROR(ENOMEM);
> }
> p->avpkt = av_packet_alloc();
> if (!p->avpkt) {
> av_freep();
> -err = AVERROR(ENOMEM);
> -goto error;
> +return AVERROR(ENOMEM);
> }
>
> p->parent = fctx;
> p->avctx = copy;
>
> if (!copy) {
> -err = AVERROR(ENOMEM);
> -goto error;
> +return AVERROR(ENOMEM);
> }
>
> *copy = *src;
> @@ -842,8 +799,7 @@ int ff_frame_thread_init(AVCodecContext *avctx)
> copy->internal = av_malloc(sizeof(AVCodecInternal));
> if (!copy->internal) {
> copy->priv_data = NULL;
> -err = AVERROR(ENOMEM);
> -goto error;
> +return AVERROR(ENOMEM);
> }
> *copy->internal = *src->internal;
> copy->internal->thread_ctx = p;
> @@ -854,27 +810,27 @@ int ff_frame_thread_init(AVCodecContext *avctx)
> if (codec->priv_data_size) {
> copy->priv_data = av_mallocz(codec->priv_data_size);
> if (!copy->priv_data) {
> -err = AVERROR(ENOMEM);
> -goto error;
> +return AVERROR(ENOMEM);
> }
>
> if (codec->priv_class) {
> *(const AVClass **)copy->priv_data = codec->priv_class;
> err = av_opt_copy(copy->priv_data, src->priv_data);
> if (err < 0)
> -goto error;
> +return err;
> }
> }
>
> -if (i)
> +if (!first)
> copy->internal->is_copy = 1;
>
> if (codec->init)
> err = codec->init(copy);
> +if (err < 0) {
> +return err;
> +}
>
> -if (err) goto error;
> -
> -if (!i)
> +if (first)
> update_context_from_thread(avctx, copy, 1);
>
> atomic_init(>debug_threads, (copy->debug & FF_DEBUG_THREADS) !=
> 0);
> @@ -882,6 +838,59 @@ int ff_frame_thread_init(AVCodecContext *avctx)
> err = AVERROR(pthread_create(>thread, NULL, frame_worker_thread,
> p));
> p->thread_init= !err;
> if(!p->thread_init)
> +return err;
> +return 0;
> +}
> +
> +int ff_frame_thread_init(AVCodecContext
Re: [FFmpeg-devel] [PATCH 1/6] avformat/jacosubdec: Fix leak on error
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/jacosubdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/jacosubdec.c b/libavformat/jacosubdec.c
> index b44e3b7783..828c33057f 100644
> --- a/libavformat/jacosubdec.c
> +++ b/libavformat/jacosubdec.c
> @@ -199,6 +199,7 @@ static int jacosub_read_header(AVFormatContext *s)
>
> sub = ff_subtitles_queue_insert(>q, line, len,
> merge_line);
> if (!sub) {
> +av_bprint_finalize(, NULL);
> ret = AVERROR(ENOMEM);
> goto fail;
> }
>
Will apply this patchset later tonight unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils: add helper functions to retrieve index entries from an AVStream
On 3/24/2021 4:48 PM, Nicolas George wrote: James Almer (12021-03-24): Because it's not even a pointer that's guaranteed to be valid or point to valid data until the next call to one specific function or set of functions (Your example is basically av_dict_get(), where only calls to av_dict_set*() on a AVDictionary you own will make previously returned AVDictionaryEntry invalid), and instead it's a pointer that may or may not be valid after the next call to potentially *any* lavf function, because it could be modified by reading the header, reading a packet, and maybe more cases, all depending on demuxer, and after which it could still be pointing to the desired entry, or to some other entry, or to freed memory. What you say is true, but it is absolutely not a problem if the user access the pointer immediately, before calling any other function, just like it is supposed to do when derefencing ctx->streams. In any case, would a int av_get_index_entry(AVStream *st, int idx, int64_t *pos, int64_t *timestamp, int *size, int *distance, int *flags); implementation, which is basically the inverse of av_add_index_entry(), be ok instead? No AVIndexEntry usage, only the fields the caller cares about can be returned, and no "This pointer will autodestruct in five seconds" situation. I will not block it as I would block the version with dynamic allocation, but you will need a little more work to convince me that this is better than just returning the pointer. You make more work for yourself and more work for the user, you have to have a good reason for it. I think it's clear by now that nothing i could say will convince you it's better to not return a pointer to an internal array when there are safer alternatives, and i already gave my reasons why, none of which satisfied you, so i don't see the point in keeping this discussion going. If some other developer wants to chime in and comment which approach they prefer, then that would be ideal. I have no hurry to push this, and I'd rather know which direction to go before i write a v3, so it can wait. 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] avformat/utils: add helper functions to retrieve index entries from an AVStream
James Almer (12021-03-24): > Because it's not even a pointer that's guaranteed to be valid or point to > valid data until the next call to one specific function or set of functions > (Your example is basically av_dict_get(), where only calls to av_dict_set*() > on a AVDictionary you own will make previously returned AVDictionaryEntry > invalid), and instead it's a pointer that may or may not be valid after the > next call to potentially *any* lavf function, because it could be modified > by reading the header, reading a packet, and maybe more cases, all depending > on demuxer, and after which it could still be pointing to the desired entry, > or to some other entry, or to freed memory. What you say is true, but it is absolutely not a problem if the user access the pointer immediately, before calling any other function, just like it is supposed to do when derefencing ctx->streams. > In any case, would a > > int av_get_index_entry(AVStream *st, int idx, int64_t *pos, >int64_t *timestamp, int *size, >int *distance, int *flags); > > implementation, which is basically the inverse of av_add_index_entry(), be > ok instead? No AVIndexEntry usage, only the fields the caller cares about > can be returned, and no "This pointer will autodestruct in five seconds" > situation. I will not block it as I would block the version with dynamic allocation, but you will need a little more work to convince me that this is better than just returning the pointer. You make more work for yourself and more work for the user, you have to have a good reason for 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] avfilter/vf_nlmeans_opencl: making filter independent of bit depth
Hello. Is there something I should be doing in order to get this patch reviewed for inclusion in master? I couldn't find the proper maintainer for this filter in the MAINTAINERS file. -- Lucas Clemente Vella lve...@gmail.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] avformat/utils: add helper functions to retrieve index entries from an AVStream
On 3/24/2021 12:15 PM, Nicolas George wrote: James Almer (12021-03-23): If your creative API invention is better, then i have no problem with it even if it goes against existing conventions. Which for that matter reminds me that i changed my mind regarding your refcounted proposal, since the alternative of adding an AVRefCount struct other structs can then use has proven to be kinda ugly/unwieldy, at least in the example implementation i saw. So there you have it. Thank you very much for letting me know. I appreciate a lot. I hope I will manage to convince you that we need a convenient and efficient string API too, even if that means quite a bit of code to implement it. I have no opinion on a strings API. Why did you choose an example that can crash? To show why the warning in the documentation would be needed? Because i'm not against documenting details about this approach whenever used. My point is that we accepts in our API constructs that are somewhat tricky to use, with constraints that are not checked by the compiler and that the user is responsible for meeting, and that can cause crashes, for the sake of efficiency and simplicity. It is a good thing, I would not have it any other way. I am using ctx->streams directly. More accurately, we should always use ctx->streams *immediately*. ^ You did not use it directly since you accessed the copy pointer you made two lines above instead, and you did not use that copy immediately since you ^^^ first called av_read_frame(), which may have invalidated it. As I said, the important word is "immediately", not "directly". But no matter. By returning a pointer the user has to free, they will get leaks if they don't read the doc. Sorry, I had not understood that you were really considering returning a dynamically allocated structure, I thought you mentioned the solution as a bad idea. I don't recall saying that, or at least not in this thread. It's definitely not my preferred solution for the reasons you state below, which is why i didn't do it at first. But in my first reply i suggested it as an alternative to ensure sizeof(AVIndexEntry) would not be effectively tied to the ABI, and then sent a v2 of this patch implementing it. Remember, we should always have this guiding principle in mind: Do not use dynamic allocations if we can make it work without. And in this case, this is not theoretical. A file with frequent keyframes can have thousands of entries, and some applications will want to walk the entire array, which is currently very fast. Adding a function call in the middle will cause some overhead, but not that much. Adding a dynamic allocation, on the other hand, would make it sluggishly slow. So I'm not making this function lazy-user proof, I'm trying to not give them a pointer to an offset within a volatile internal array they have no business accessing. But WHY? What is so bad with this: while ((entry = av_index_get_entry(st, idx++))) do_some_math(entry->timestamp, entry->pos); do_some_more_math(); ? No dynamic allocation, no sizeof(AVIndexEntry) creeping into the ABI, almost as fast as direct access, almost as simple. This is by far the simplest and most efficient solution for both you and our users. So why reject it? Because it's not even a pointer that's guaranteed to be valid or point to valid data until the next call to one specific function or set of functions (Your example is basically av_dict_get(), where only calls to av_dict_set*() on a AVDictionary you own will make previously returned AVDictionaryEntry invalid), and instead it's a pointer that may or may not be valid after the next call to potentially *any* lavf function, because it could be modified by reading the header, reading a packet, and maybe more cases, all depending on demuxer, and after which it could still be pointing to the desired entry, or to some other entry, or to freed memory. In any case, would a int av_get_index_entry(AVStream *st, int idx, int64_t *pos, int64_t *timestamp, int *size, int *distance, int *flags); implementation, which is basically the inverse of av_add_index_entry(), be ok instead? No AVIndexEntry usage, only the fields the caller cares about can be returned, and no "This pointer will autodestruct in five seconds" situation. Following your example above, it would look like while (!av_get_index_entry(st, idx++, , , NULL, NULL, NULL)) do_some_math(timestamp, pos); do_some_more_math(); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mov: Ignore multiple STSC / STCO
Fixes: STSC / STCO inconsistency and assertion failure
Fixes: crbug1184666.mp4
Found-by: Chromium ASAN fuzzer
Reviewed-by: Matt Wolenetz
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5f8bcfbf22..69d44a64b5 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2037,8 +2037,10 @@ static int mov_read_stco(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
if (!entries)
return 0;
-if (sc->chunk_offsets)
-av_log(c->fc, AV_LOG_WARNING, "Duplicated STCO atom\n");
+if (sc->chunk_offsets) {
+av_log(c->fc, AV_LOG_WARNING, "Ignoring duplicated STCO atom\n");
+return 0;
+}
av_free(sc->chunk_offsets);
sc->chunk_count = 0;
sc->chunk_offsets = av_malloc_array(entries, sizeof(*sc->chunk_offsets));
@@ -2671,8 +2673,10 @@ static int mov_read_stsc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
if (!entries)
return 0;
-if (sc->stsc_data)
-av_log(c->fc, AV_LOG_WARNING, "Duplicated STSC atom\n");
+if (sc->stsc_data) {
+av_log(c->fc, AV_LOG_WARNING, "Ignoring duplicated STSC atom\n");
+return 0;
+}
av_free(sc->stsc_data);
sc->stsc_count = 0;
sc->stsc_data = av_malloc_array(entries, sizeof(*sc->stsc_data));
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils: add helper functions to retrieve index entries from an AVStream
James Almer (12021-03-23): > If your creative API invention is better, then i have no problem with it > even if it goes against existing conventions. > > Which for that matter reminds me that i changed my mind regarding your > refcounted proposal, since the alternative of adding an AVRefCount struct > other structs can then use has proven to be kinda ugly/unwieldy, at least in > the example implementation i saw. So there you have it. Thank you very much for letting me know. I appreciate a lot. I hope I will manage to convince you that we need a convenient and efficient string API too, even if that means quite a bit of code to implement it. > Why did you choose an example that can crash? To show why the warning in the > documentation would be needed? Because i'm not against documenting details > about this approach whenever used. My point is that we accepts in our API constructs that are somewhat tricky to use, with constraints that are not checked by the compiler and that the user is responsible for meeting, and that can cause crashes, for the sake of efficiency and simplicity. It is a good thing, I would not have it any other way. > > I am using ctx->streams directly. More accurately, we should always use > > ctx->streams *immediately*. ^ > > You did not use it directly since you accessed the copy pointer you made two > lines above instead, and you did not use that copy immediately since you ^^^ > first called av_read_frame(), which may have invalidated it. As I said, the important word is "immediately", not "directly". But no matter. > By returning a pointer the user has to free, they will get leaks if they > don't read the doc. Sorry, I had not understood that you were really considering returning a dynamically allocated structure, I thought you mentioned the solution as a bad idea. Remember, we should always have this guiding principle in mind: Do not use dynamic allocations if we can make it work without. And in this case, this is not theoretical. A file with frequent keyframes can have thousands of entries, and some applications will want to walk the entire array, which is currently very fast. Adding a function call in the middle will cause some overhead, but not that much. Adding a dynamic allocation, on the other hand, would make it sluggishly slow. > So I'm not making this function lazy-user proof, I'm > trying to not give them a pointer to an offset within a volatile internal > array they have no business accessing. But WHY? What is so bad with this: while ((entry = av_index_get_entry(st, idx++))) do_some_math(entry->timestamp, entry->pos); do_some_more_math(); ? No dynamic allocation, no sizeof(AVIndexEntry) creeping into the ABI, almost as fast as direct access, almost as simple. This is by far the simplest and most efficient solution for both you and our users. So why reject 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 2/3] avcodec/kmvc: Move commonly used variables to the front of the context
ons 2021-03-24 klockan 15:26 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > ons 2021-03-24 klockan 14:49 +0100 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
> > > > > Reduces codesize because the offset in pointer+offset addressing
> > > > > requires less bytes to encode. Reduces the size of .text from 8871B
> > > > > to 8146B (GCC 10, -O3, x64).
> > > > >
> > > > > Signed-off-by: Andreas Rheinhardt
> > > > > ---
> > > > > libavcodec/kmvc.c | 4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
> > > > > index 8d9f0a9693..dd1ae05f2d 100644
> > > > > --- a/libavcodec/kmvc.c
> > > > > +++ b/libavcodec/kmvc.c
> > > > > @@ -44,12 +44,12 @@
> > > > > typedef struct KmvcContext {
> > > > > AVCodecContext *avctx;
> > > >
> > > > Couldn't this be removed too? Doesn't have to hold up this patch of
> > > > course
> > > >
> > > It is currently used for log messages; such usage is fairly common, but
> > > it can of course be changed. Don't know if it is beneficial though.
> >
> > Maybe moving it further down the struct saves some .text?
> >
> Moving the GetBitContext to the top spot is beneficial (saves 77B);
> removing avctx from the context is even more so: 77B+4B in decode_init.
> I can do so if desired.
Eh, whatever. The patchset works and looks decent enough.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/kmvc: Move commonly used variables to the front of the context
Tomas Härdin:
> ons 2021-03-24 klockan 14:49 +0100 skrev Andreas Rheinhardt:
>> Tomas Härdin:
>>> mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
Reduces codesize because the offset in pointer+offset addressing
requires less bytes to encode. Reduces the size of .text from 8871B
to 8146B (GCC 10, -O3, x64).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/kmvc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
index 8d9f0a9693..dd1ae05f2d 100644
--- a/libavcodec/kmvc.c
+++ b/libavcodec/kmvc.c
@@ -44,12 +44,12 @@
typedef struct KmvcContext {
AVCodecContext *avctx;
>>>
>>> Couldn't this be removed too? Doesn't have to hold up this patch of
>>> course
>>>
>> It is currently used for log messages; such usage is fairly common, but
>> it can of course be changed. Don't know if it is beneficial though.
>
> Maybe moving it further down the struct saves some .text?
>
Moving the GetBitContext to the top spot is beneficial (saves 77B);
removing avctx from the context is even more so: 77B+4B in decode_init.
I can do so if desired.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/kmvc: Move commonly used variables to the front of the context
ons 2021-03-24 klockan 14:49 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
> > > Reduces codesize because the offset in pointer+offset addressing
> > > requires less bytes to encode. Reduces the size of .text from 8871B
> > > to 8146B (GCC 10, -O3, x64).
> > >
> > > Signed-off-by: Andreas Rheinhardt
> > > ---
> > > libavcodec/kmvc.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
> > > index 8d9f0a9693..dd1ae05f2d 100644
> > > --- a/libavcodec/kmvc.c
> > > +++ b/libavcodec/kmvc.c
> > > @@ -44,12 +44,12 @@
> > > typedef struct KmvcContext {
> > > AVCodecContext *avctx;
> >
> > Couldn't this be removed too? Doesn't have to hold up this patch of
> > course
> >
> It is currently used for log messages; such usage is fairly common, but
> it can of course be changed. Don't know if it is beneficial though.
Maybe moving it further down the struct saves some .text?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Increase MOV_TIMESCALE for higher precision
Gyan, thanks for clarification! It is all exactly as you described. I thought to set MOV_TIMESCALE to either 60kHz or 90kHz as both are divisible by most common fps values. And x10 increase is for further precision in conversion to seconds. Say it's needed to write segmentDuration=289.4892 sec in elst to start presentation time from. Using timescale of 1000 we lose 0,0002 sec which turns into pts drift by 6 points for video track timescale of 30kHz. IMHO there is no need to pull MOV_TIMESCALE up to cli arg because there is no need to control it. The only requirement is best precision. What do you think? On Wed, Mar 24, 2021 at 2:42 PM Gyan Doshi wrote: > > > On 2021-03-24 15:45, Jan Ekström wrote: > > On Wed, Mar 24, 2021 at 7:30 AM Gyan Doshi wrote: > >> > >> > >> On 2021-03-24 03:38, Andrey Rikunov wrote: > >>> --- > >>>libavformat/movenc.h | 2 +- > >>>1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/libavformat/movenc.h b/libavformat/movenc.h > >>> index cdbc407..8a152c0 100644 > >>> --- a/libavformat/movenc.h > >>> +++ b/libavformat/movenc.h > >>> @@ -29,7 +29,7 @@ > >>> > >>>#define MOV_FRAG_INFO_ALLOC_INCREMENT 64 > >>>#define MOV_INDEX_CLUSTER_SIZE 1024 > >>> -#define MOV_TIMESCALE 1000 > >>> +#define MOV_TIMESCALE 6 > >> Instead of hardcoding it, add an option to allow the user to set it. > > if MOV still needs its timescale override of 1:1000 for some > > To be clear, the MOV_TIMESCALE refers to the timescale written in the > mvhd atom in all products of movenc.c. It is distinct from the > stream/track timescales. The mvhd value is the basis for the duration > field in edit list entries but not media time which is denominated in > terms of track timescale ( what video_track_timescale targets but only > for video streams). Users in the past have asked for a change (usually > to 600) because some Apple products (FCP ?) only work well with 600 for > mvhd timescale. There is no strict inter-relation or constraint across > mvhd and the trak timescales, so auto_adjust_timescale shouldn't force > it in any hardcoded manner. > > 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 mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/kmvc: Move commonly used variables to the front of the context
Tomas Härdin:
> mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
>> Reduces codesize because the offset in pointer+offset addressing
>> requires less bytes to encode. Reduces the size of .text from 8871B
>> to 8146B (GCC 10, -O3, x64).
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/kmvc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
>> index 8d9f0a9693..dd1ae05f2d 100644
>> --- a/libavcodec/kmvc.c
>> +++ b/libavcodec/kmvc.c
>> @@ -44,12 +44,12 @@
>> typedef struct KmvcContext {
>> AVCodecContext *avctx;
>
> Couldn't this be removed too? Doesn't have to hold up this patch of
> course
>
It is currently used for log messages; such usage is fairly common, but
it can of course be changed. Don't know if it is beneficial though.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/kmvc: Move commonly used variables to the front of the context
mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
> Reduces codesize because the offset in pointer+offset addressing
> requires less bytes to encode. Reduces the size of .text from 8871B
> to 8146B (GCC 10, -O3, x64).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/kmvc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
> index 8d9f0a9693..dd1ae05f2d 100644
> --- a/libavcodec/kmvc.c
> +++ b/libavcodec/kmvc.c
> @@ -44,12 +44,12 @@
> typedef struct KmvcContext {
> AVCodecContext *avctx;
Couldn't this be removed too? Doesn't have to hold up this patch of
course
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/11] avcodec/adpcm: add comment to has_status field
On 24/3/21 12:12 am, Zane van Iperen wrote: Signed-off-by: Zane van Iperen --- libavcodec/adpcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) As these are trivial patches, I will apply them tomorrow and backport to 4.4. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] 回复: 回复: Possibility to add tonemap filter to ffmpeg 3.2.7
I didn't mean to offend neither expect free work. I only expect to get some quick hit from here. I am new to the old project and it have lot of history debt. The changes are made by previous colleagues through years and it's mainly about custom live infra. I am making search about make the modification to work with current FFmpeg or make these requested feature work in old version. I have to admit patch new feature to old version is not a good idea from your advice. Thanks. 发件人: ffmpeg-devel 代表 Nicolas George 发送时间: 2021年3月24日 19:02 收件人: FFmpeg development discussions and patches 主题: Re: [FFmpeg-devel] 回复: Possibility to add tonemap filter to ffmpeg 3.2.7 Li Jinyao (12021-03-24): > Can you give me some advice? The only advice we can give you is that you post here the changes you have made to the old FFmpeg and start working on making work with current FFmpeg and getting integrated into the official version. I hope you do not expect people here will help you gratis to take our public free code so that you can use with your private proprietary code. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Increase MOV_TIMESCALE for higher precision
On 2021-03-24 15:45, Jan Ekström wrote: On Wed, Mar 24, 2021 at 7:30 AM Gyan Doshi wrote: On 2021-03-24 03:38, Andrey Rikunov wrote: --- libavformat/movenc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/movenc.h b/libavformat/movenc.h index cdbc407..8a152c0 100644 --- a/libavformat/movenc.h +++ b/libavformat/movenc.h @@ -29,7 +29,7 @@ #define MOV_FRAG_INFO_ALLOC_INCREMENT 64 #define MOV_INDEX_CLUSTER_SIZE 1024 -#define MOV_TIMESCALE 1000 +#define MOV_TIMESCALE 6 Instead of hardcoding it, add an option to allow the user to set it. if MOV still needs its timescale override of 1:1000 for some To be clear, the MOV_TIMESCALE refers to the timescale written in the mvhd atom in all products of movenc.c. It is distinct from the stream/track timescales. The mvhd value is the basis for the duration field in edit list entries but not media time which is denominated in terms of track timescale ( what video_track_timescale targets but only for video streams). Users in the past have asked for a change (usually to 600) because some Apple products (FCP ?) only work well with 600 for mvhd timescale. There is no strict inter-relation or constraint across mvhd and the trak timescales, so auto_adjust_timescale shouldn't force it in any hardcoded manner. 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 2/7] avcodec/vc1dec: Postpone allocating sprite frame to avoid segfault
Andreas Rheinhardt:
> Up until now, the VC-1 decoders allocated an AVFrame for usage with
> sprites during vc1_decode_init(); yet said AVFrame can be freed if
> (re)initializing the context (which happens ordinarily during decoding)
> fails. The AVFrame does not get allocated again lateron in this case,
> leading to segfaults.
>
> Fix this by moving the allocation of said frame immediately before it is
> used (this also means that said frame won't be allocated at all any more
> in case of a regular (i.e. non-image) stream).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/vc1dec.c | 20 +++-
> 1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
> index 7809234ff7..5cdf197da7 100644
> --- a/libavcodec/vc1dec.c
> +++ b/libavcodec/vc1dec.c
> @@ -539,12 +539,6 @@ static av_cold int vc1_decode_init(AVCodecContext *avctx)
> ff_h264chroma_init(>h264chroma, 8);
> ff_qpeldsp_init(>qdsp);
>
> -// Must happen after calling ff_vc1_decode_end
> -// to avoid de-allocating the sprite_output_frame
> -v->sprite_output_frame = av_frame_alloc();
> -if (!v->sprite_output_frame)
> -return AVERROR(ENOMEM);
> -
> avctx->has_b_frames = !!avctx->max_b_frames;
>
> if (v->color_prim == 1 || v->color_prim == 5 || v->color_prim == 6)
> @@ -577,20 +571,15 @@ static av_cold int vc1_decode_init(AVCodecContext
> *avctx)
> v->sprite_height > 1 << 14 ||
> v->output_width > 1 << 14 ||
> v->output_height > 1 << 14) {
> -ret = AVERROR_INVALIDDATA;
> -goto error;
> +return AVERROR_INVALIDDATA;
> }
>
> if ((v->sprite_width&1) || (v->sprite_height&1)) {
> avpriv_request_sample(avctx, "odd sprites support");
> -ret = AVERROR_PATCHWELCOME;
> -goto error;
> +return AVERROR_PATCHWELCOME;
> }
> }
> return 0;
> -error:
> -av_frame_free(>sprite_output_frame);
> -return ret;
> }
>
> /** Close a VC1/WMV3 decoder
> @@ -1147,6 +1136,11 @@ image:
> avctx->height = avctx->coded_height = v->output_height;
> if (avctx->skip_frame >= AVDISCARD_NONREF)
> goto end;
> +if (!v->sprite_output_frame &&
> +!(v->sprite_output_frame = av_frame_alloc())) {
> +ret = AVERROR(ENOMEM);
> +goto err;
> +}
> #if CONFIG_WMV3IMAGE_DECODER || CONFIG_VC1IMAGE_DECODER
> if ((ret = vc1_decode_sprites(v, >gb)) < 0)
> goto err;
>
Will apply tonight unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] 回复: Possibility to add tonemap filter to ffmpeg 3.2.7
Li Jinyao (12021-03-24): > Can you give me some advice? The only advice we can give you is that you post here the changes you have made to the old FFmpeg and start working on making work with current FFmpeg and getting integrated into the official version. I hope you do not expect people here will help you gratis to take our public free code so that you can use with your private proprietary code. 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] 回复: Possibility to add tonemap filter to ffmpeg 3.2.7
Thanks, I am trying pick tonemap changes back, and I found tonemap relay on single precision planar RGB pixel formats like AV_PIX_FMT_GBRPF32, which means I need to pick these code, too. I am working on it now, but I am not sure if there are a lot work to do to make 3.2.4 support these pixel formats and what else work may I need to do to make it work. Can you give me some advice? 李金尧 > 在 2021年3月24日，下午1:27，Gyan Doshi 写道： > > > >> On 2021-03-24 08:17, Li Jinyao wrote: >> The patches for the custom feature are in a private cvs, it's about 400+ >> commits. I tried to link against 4.3.1, found about 10 functions are missing. >> If it hard to add tone map back, maybe patch these feature to a newer ffmpeg >> version is more feasible? > > tonemap was added in v3.4. So try to cherry-pick that initial commit, and > then try to achieve close to equivalency of the current state by inlining > missing functions. > > 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 mailing list ffmpeg-devel@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] Increase MOV_TIMESCALE for higher precision
On Wed, Mar 24, 2021 at 7:30 AM Gyan Doshi wrote: > > > > On 2021-03-24 03:38, Andrey Rikunov wrote: > > --- > > libavformat/movenc.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/movenc.h b/libavformat/movenc.h > > index cdbc407..8a152c0 100644 > > --- a/libavformat/movenc.h > > +++ b/libavformat/movenc.h > > @@ -29,7 +29,7 @@ > > > > #define MOV_FRAG_INFO_ALLOC_INCREMENT 64 > > #define MOV_INDEX_CLUSTER_SIZE 1024 > > -#define MOV_TIMESCALE 1000 > > +#define MOV_TIMESCALE 6 > > Instead of hardcoding it, add an option to allow the user to set it. I think if the "Mov requires timescale 1000" assumption is no longer correct, it should be removed and the generic time base based timescale generation utilized instead, which is utilized for MP4-likes. That way by setting time base one can affect it with the standard option. For the general logic (for MP4- likes), I am planning on getting rid of the video time scale option in the following steps: 1. Figure out what the historical reasons for having a video time scale of over 10k are (I think it was mostly to adjust A/V sync with more granularity than frame rate - but we have edit lists for that now?). 2. If those still hold, make a "auto_adjust_timescale" boolean, which would first be on by default. 3. Make video_timescale disable the auto-adjustment of video timescale, and set the time base earlier in the muxer logic (since muxers are allowed to override the AVStreams' time base). 4. Deprecate video_timescale and point people towards -auto_adjust_timescale false/0 -time_base:v "1:NUMBER" I have seen people add various timescale related options to movenc in their trees for audio/subtitles just because it's not clear that we already have time_base :s . Thus this just needs to be cleaned up. And if MOV still needs its timescale override of 1:1000 for some compatibility reasons (?) then "auto_adjust_timescale" can also poke at that. 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] avcodec/h264_metadata: add change pic_order_cnt_type option
To Andreas Rheinhardt, > It is unsafe in the sense that it can lead to invalid and broken files. > But it is way safer than actually modifying the slice headers, because > the latter is absolutely irreversible, whereas one just needs to set big > enough values to fix files broken by setting too low values for > reorder_frames and max_dec_frame_buffering. For this a warning in the > documentation that wrong values might break files should suffice. Got it. > Just for confirmation: Setting num_reorder_frames to zero is not enough? On my tested devices setting num_reorder_frames to zero is enough. But I can't ensure it will be effective on every decoder. > This is wrong: pic_order_cnt_lsb is typically incremented by two per > frame (but it can be different), whereas frame_num is only incremented > after a reference picture and only by 1. Furthermore, both these values > are only coded modulo a certain power of two and these powers can be > different. I have found that only on macOS 11 pic_order_cnt_lsb is incremented by two while on iOS 14 or other Android devices I have tested pic_order_cnt_lsb is incremented by one. You could try to generate a bytestream on iOS to verify it. sharpbai ___ ffmpeg-devel mailing list ffmpeg-devel@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] avcodec/h264_metadata: add change pic_order_cnt_type option
sharp...@gmail.com: > To Andreas Rheinhardt, > >> Why is this not possible? I just told you how you could set >> max_dec_frame_buffering to a lower value. It seems you haven't tried it. > > Ahh...I thought what you care about is the unsafety of directly modifing > num_reorder_frames and num_reorder_frames to a lower value. > It is unsafe in the sense that it can lead to invalid and broken files. But it is way safer than actually modifying the slice headers, because the latter is absolutely irreversible, whereas one just needs to set big enough values to fix files broken by setting too low values for reorder_frames and max_dec_frame_buffering. For this a warning in the documentation that wrong values might break files should suffice. > We have tested set max_dec_frame_buffering to 0 and num_reorder_frames to 0. > The result is the same as set pic_order_cnt_type to 2. > Just for confirmation: Setting num_reorder_frames to zero is not enough? > Setting max_dec_frame_buffering requires to modify sps only while setting > pic_order_cnt_type requires to modify every slice. I think your method > is better. > > Btw, for safety you could compare pic_order_cnt_lsb and frame_num in every > slice header. The difference should not be larger than (num_reorder_frames * > 2). > Or an error should be generated. > This is wrong: pic_order_cnt_lsb is typically incremented by two per frame (but it can be different), whereas frame_num is only incremented after a reference picture and only by 1. Furthermore, both these values are only coded modulo a certain power of two and these powers can be different. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavfi/qsvvpp: support async depth
On Sun, 2021-03-21 at 18:10 +0800, Linjie Fu wrote:
> Hi Fei,
>
> On Mon, Mar 15, 2021 at 1:13 PM Fei Wang
> wrote:
> >
> > Async depth will allow qsv filter cache few frames, and avoid force
> > switch and end filter task frame by frame. This change will improve
> > performance for some multi-task case, for example 1:N transcode(
> > decode + vpp + encode) with all QSV plugins.
>
> Async depth support for qsv vpp is valuable for the performance of
> whole qsv pipeline, since both decoding/encoding have already
> supported the async_depth.
>
> Hence, would you please help to elaborate more about the details
> about
> the performance improvement for the whole pipeline?
> (For examples, before/after this patch, cmdline, platform and the
> fps ...)
Will add some data in my next version.
>
> > Signed-off-by: Fei Wang
> > ---
> > Change: combine used and queued into queued in QSVFrame.
> >
> > libavfilter/qsvvpp.c | 153 ++-
> >
> > libavfilter/qsvvpp.h | 41 -
> > libavfilter/vf_deinterlace_qsv.c | 14 +--
> > libavfilter/vf_vpp_qsv.c | 75 ---
> > 4 files changed, 193 insertions(+), 90 deletions(-)
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> > index f216b3f248..e7c7a12cfa 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -27,6 +27,7 @@
> > #include "libavutil/hwcontext_qsv.h"
> > #include "libavutil/time.h"
> > #include "libavutil/pixdesc.h"
> > +#include "libavutil/fifo.h"
>
> This seems to be redundant, since you're adding fifo.h in qsvvpp.h as
> well.
Thanks, will remove this line.
>
> > #include "internal.h"
> > #include "qsvvpp.h"
> > @@ -37,37 +38,6 @@
> > #define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
> > #define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
> >
> > -typedef struct QSVFrame {
> > -AVFrame *frame;
> > -mfxFrameSurface1 *surface;
> > -mfxFrameSurface1 surface_internal; /* for system memory */
> > -struct QSVFrame *next;
> > -} QSVFrame;
> > -
> > -/* abstract struct for all QSV filters */
> > -struct QSVVPPContext {
> > -mfxSession session;
> > -int (*filter_frame) (AVFilterLink *outlink, AVFrame *frame);/*
> > callback */
> > -enum AVPixelFormat out_sw_format; /* Real output format */
> > -mfxVideoParam vpp_param;
> > -mfxFrameInfo *frame_infos; /* frame info for each
> > input */
> > -
> > -/* members related to the input/output surface */
> > -int in_mem_mode;
> > -int out_mem_mode;
> > -QSVFrame *in_frame_list;
> > -QSVFrame *out_frame_list;
> > -int nb_surface_ptrs_in;
> > -int nb_surface_ptrs_out;
> > -mfxFrameSurface1 **surface_ptrs_in;
> > -mfxFrameSurface1 **surface_ptrs_out;
> > -
> > -/* MFXVPP extern parameters */
> > -mfxExtOpaqueSurfaceAlloc opaque_alloc;
> > -mfxExtBuffer **ext_buffers;
> > -int nb_ext_buffers;
> > -};
> > -
> > static const mfxHandleType handle_types[] = {
> > MFX_HANDLE_VA_DISPLAY,
> > MFX_HANDLE_D3D9_DEVICE_MANAGER,
> > @@ -336,9 +306,11 @@ static int fill_frameinfo_by_link(mfxFrameInfo
> > *frameinfo, AVFilterLink *link)
> > static void clear_unused_frames(QSVFrame *list)
> > {
> > while (list) {
> > -if (list->surface && !list->surface->Data.Locked) {
> > -list->surface = NULL;
> > +/* list->queued==1 means the frame is not cached in VPP
> > + * process any more, it can be released to pool. */
> > +if ((list->queued == 1) && !list->surface.Data.Locked) {
> > av_frame_free(>frame);
> > +list->queued = 0;
> > }
> > list = list->next;
> > }
> > @@ -361,8 +333,10 @@ static QSVFrame *get_free_frame(QSVFrame
> > **list)
> > QSVFrame *out = *list;
> >
> > for (; out; out = out->next) {
> > -if (!out->surface)
> > +if (!out->queued) {
> > +out->queued = 1;
> > break;
> > +}
> > }
> >
> > if (!out) {
> > @@ -371,8 +345,9 @@ static QSVFrame *get_free_frame(QSVFrame
> > **list)
> > av_log(NULL, AV_LOG_ERROR, "Can't alloc new output
> > frame.\n");
> > return NULL;
> > }
> > -out->next = *list;
> > -*list = out;
> > +out->queued = 1;
> > +out->next = *list;
> > +*list = out;
> > }
> >
> > return out;
> > @@ -402,7 +377,7 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> > AVFilterLink *inlink, AVFrame *p
> > return NULL;
> > }
> > qsv_frame->frame = av_frame_clone(picref);
> > -qsv_frame->surface = (mfxFrameSurface1 *)qsv_frame->frame-
> > >data[3];
> > +qsv_frame->surface = *(mfxFrameSurface1 *)qsv_frame-
> >
[FFmpeg-devel] [PATCH 3/3] lavfi/dnn_backend_tensorflow.c: fix mem leak in execute_model_tf
Signed-off-by: Ting Fu
---
libavfilter/dnn/dnn_backend_tf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index c18cb4063f..c0aa510630 100644
--- a/libavfilter/dnn/dnn_backend_tf.c
+++ b/libavfilter/dnn/dnn_backend_tf.c
@@ -766,18 +766,21 @@ static DNNReturnType execute_model_tf(const DNNModel
*model, const char *input_n
if (nb_output != 1) {
// currently, the filter does not need multiple outputs,
// so we just pending the support until we really need it.
+TF_DeleteTensor(input_tensor);
avpriv_report_missing_feature(ctx, "multiple outputs");
return DNN_ERROR;
}
tf_outputs = av_malloc_array(nb_output, sizeof(*tf_outputs));
if (tf_outputs == NULL) {
+TF_DeleteTensor(input_tensor);
av_log(ctx, AV_LOG_ERROR, "Failed to allocate memory for
*tf_outputs\n"); \
return DNN_ERROR;
}
output_tensors = av_mallocz_array(nb_output, sizeof(*output_tensors));
if (!output_tensors) {
+TF_DeleteTensor(input_tensor);
av_freep(_outputs);
av_log(ctx, AV_LOG_ERROR, "Failed to allocate memory for output
tensor\n"); \
return DNN_ERROR;
@@ -786,6 +789,7 @@ static DNNReturnType execute_model_tf(const DNNModel
*model, const char *input_n
for (int i = 0; i < nb_output; ++i) {
tf_outputs[i].oper = TF_GraphOperationByName(tf_model->graph,
output_names[i]);
if (!tf_outputs[i].oper) {
+TF_DeleteTensor(input_tensor);
av_freep(_outputs);
av_freep(_tensors);
av_log(ctx, AV_LOG_ERROR, "Could not find output \"%s\" in
model\n", output_names[i]); \
@@ -799,6 +803,7 @@ static DNNReturnType execute_model_tf(const DNNModel
*model, const char *input_n
tf_outputs, output_tensors, nb_output,
NULL, 0, NULL, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK) {
+TF_DeleteTensor(input_tensor);
av_freep(_outputs);
av_freep(_tensors);
av_log(ctx, AV_LOG_ERROR, "Failed to run session when executing
model\n");
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] lavfi/dnn_backend_tensorflow.c: fix mem leak in load_native_model
Signed-off-by: Ting Fu
---
libavfilter/dnn/dnn_backend_tf.c | 55 ++--
1 file changed, 31 insertions(+), 24 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index e016571304..c18cb4063f 100644
--- a/libavfilter/dnn/dnn_backend_tf.c
+++ b/libavfilter/dnn/dnn_backend_tf.c
@@ -330,7 +330,7 @@ static DNNReturnType add_conv_layer(TFModel *tf_model,
TF_Operation *transpose_o
TF_OperationDescription *op_desc;
TF_Output input;
int64_t strides[] = {1, 1, 1, 1};
-TF_Tensor *tensor;
+TF_Tensor *kernel_tensor = NULL, *biases_tensor = NULL;
int64_t dims[4];
int dims_len;
char name_buffer[NAME_BUFFER_SIZE];
@@ -347,17 +347,15 @@ static DNNReturnType add_conv_layer(TFModel *tf_model,
TF_Operation *transpose_o
dims[2] = params->kernel_size;
dims[3] = params->input_num;
dims_len = 4;
-tensor = TF_AllocateTensor(TF_FLOAT, dims, dims_len, size * sizeof(float));
-memcpy(TF_TensorData(tensor), params->kernel, size * sizeof(float));
-TF_SetAttrTensor(op_desc, "value", tensor, tf_model->status);
+kernel_tensor = TF_AllocateTensor(TF_FLOAT, dims, dims_len, size *
sizeof(float));
+memcpy(TF_TensorData(kernel_tensor), params->kernel, size * sizeof(float));
+TF_SetAttrTensor(op_desc, "value", kernel_tensor, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK){
-av_log(ctx, AV_LOG_ERROR, "Failed to set value for kernel of conv
layer %d\n", layer);
-return DNN_ERROR;
+goto err;
}
op = TF_FinishOperation(op_desc, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK){
-av_log(ctx, AV_LOG_ERROR, "Failed to add kernel to conv layer %d\n",
layer);
-return DNN_ERROR;
+goto err;
}
snprintf(name_buffer, NAME_BUFFER_SIZE, "transpose%d", layer);
@@ -370,8 +368,7 @@ static DNNReturnType add_conv_layer(TFModel *tf_model,
TF_Operation *transpose_o
TF_SetAttrType(op_desc, "Tperm", TF_INT32);
op = TF_FinishOperation(op_desc, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK){
-av_log(ctx, AV_LOG_ERROR, "Failed to add transpose to conv layer
%d\n", layer);
-return DNN_ERROR;
+goto err;
}
snprintf(name_buffer, NAME_BUFFER_SIZE, "conv2d%d", layer);
@@ -385,8 +382,7 @@ static DNNReturnType add_conv_layer(TFModel *tf_model,
TF_Operation *transpose_o
TF_SetAttrString(op_desc, "padding", "VALID", 5);
*cur_op = TF_FinishOperation(op_desc, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK){
-av_log(ctx, AV_LOG_ERROR, "Failed to add conv2d to conv layer %d\n",
layer);
-return DNN_ERROR;
+goto err;
}
snprintf(name_buffer, NAME_BUFFER_SIZE, "conv_biases%d", layer);
@@ -394,17 +390,15 @@ static DNNReturnType add_conv_layer(TFModel *tf_model,
TF_Operation *transpose_o
TF_SetAttrType(op_desc, "dtype", TF_FLOAT);
dims[0] = params->output_num;
dims_len = 1;
-tensor = TF_AllocateTensor(TF_FLOAT, dims, dims_len, params->output_num *
sizeof(float));
-memcpy(TF_TensorData(tensor), params->biases, params->output_num *
sizeof(float));
-TF_SetAttrTensor(op_desc, "value", tensor, tf_model->status);
+biases_tensor = TF_AllocateTensor(TF_FLOAT, dims, dims_len,
params->output_num * sizeof(float));
+memcpy(TF_TensorData(biases_tensor), params->biases, params->output_num *
sizeof(float));
+TF_SetAttrTensor(op_desc, "value", biases_tensor, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK){
-av_log(ctx, AV_LOG_ERROR, "Failed to set value for conv_biases of conv
layer %d\n", layer);
-return DNN_ERROR;
+goto err;
}
op = TF_FinishOperation(op_desc, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK){
-av_log(ctx, AV_LOG_ERROR, "Failed to add conv_biases to conv layer
%d\n", layer);
-return DNN_ERROR;
+goto err;
}
snprintf(name_buffer, NAME_BUFFER_SIZE, "bias_add%d", layer);
@@ -416,8 +410,7 @@ static DNNReturnType add_conv_layer(TFModel *tf_model,
TF_Operation *transpose_o
TF_SetAttrType(op_desc, "T", TF_FLOAT);
*cur_op = TF_FinishOperation(op_desc, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK){
-av_log(ctx, AV_LOG_ERROR, "Failed to add bias_add to conv layer %d\n",
layer);
-return DNN_ERROR;
+goto err;
}
snprintf(name_buffer, NAME_BUFFER_SIZE, "activation%d", layer);
@@ -440,11 +433,15 @@ static DNNReturnType add_conv_layer(TFModel *tf_model,
TF_Operation *transpose_o
TF_SetAttrType(op_desc, "T", TF_FLOAT);
*cur_op = TF_FinishOperation(op_desc, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK){
-av_log(ctx, AV_LOG_ERROR, "Failed to add activation function to conv
layer %d\n", layer);
-return DNN_ERROR;
+goto err;
}
return
[FFmpeg-devel] [PATCH 1/3] lavfi/dnn_backend_tensorflow.c: fix mem leak in load_tf_model
Signed-off-by: Ting Fu
---
libavfilter/dnn/dnn_backend_tf.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index 750a476726..e016571304 100644
--- a/libavfilter/dnn/dnn_backend_tf.c
+++ b/libavfilter/dnn/dnn_backend_tf.c
@@ -282,6 +282,9 @@ static DNNReturnType load_tf_model(TFModel *tf_model, const
char *model_filename
TF_SetConfig(sess_opts, sess_config,
sess_config_length,tf_model->status);
av_freep(_config);
if (TF_GetCode(tf_model->status) != TF_OK) {
+TF_DeleteGraph(tf_model->graph);
+TF_DeleteStatus(tf_model->status);
+TF_DeleteSessionOptions(sess_opts);
av_log(ctx, AV_LOG_ERROR, "Failed to set config for sess options
with %s\n",
tf_model->ctx.options.sess_config);
return DNN_ERROR;
@@ -292,6 +295,8 @@ static DNNReturnType load_tf_model(TFModel *tf_model, const
char *model_filename
TF_DeleteSessionOptions(sess_opts);
if (TF_GetCode(tf_model->status) != TF_OK)
{
+TF_DeleteGraph(tf_model->graph);
+TF_DeleteStatus(tf_model->status);
av_log(ctx, AV_LOG_ERROR, "Failed to create new session with model
graph\n");
return DNN_ERROR;
}
@@ -304,6 +309,9 @@ static DNNReturnType load_tf_model(TFModel *tf_model, const
char *model_filename
_op, 1, NULL, tf_model->status);
if (TF_GetCode(tf_model->status) != TF_OK)
{
+TF_DeleteSession(tf_model->session, tf_model->status);
+TF_DeleteGraph(tf_model->graph);
+TF_DeleteStatus(tf_model->status);
av_log(ctx, AV_LOG_ERROR, "Failed to run session when
initializing\n");
return DNN_ERROR;
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h264_metadata: add change pic_order_cnt_type option
To Andreas Rheinhardt, > Why is this not possible? I just told you how you could set > max_dec_frame_buffering to a lower value. It seems you haven't tried it. Ahh...I thought what you care about is the unsafety of directly modifing num_reorder_frames and num_reorder_frames to a lower value. We have tested set max_dec_frame_buffering to 0 and num_reorder_frames to 0. The result is the same as set pic_order_cnt_type to 2. Setting max_dec_frame_buffering requires to modify sps only while setting pic_order_cnt_type requires to modify every slice. I think your method is better. Btw, for safety you could compare pic_order_cnt_lsb and frame_num in every slice header. The difference should not be larger than (num_reorder_frames * 2). Or an error should be generated. ___ ffmpeg-devel mailing list ffmpeg-devel@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 v1] avfilter/vf_vpp_qsv: add scale mode option
On Mon, 2021-03-22 at 20:12 +0800, Linjie Fu wrote:
> On Wed, Feb 24, 2021 at 9:44 AM Fei Wang
> wrote:
> >
> > The option allow user to set diffenent scaling mode from
> > auto/low-power/high-quality.
> >
> > More details:
> >
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxExtVPPScaling
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavfilter/vf_vpp_qsv.c | 25 +++--
> > 1 file changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> > index 5d57707455..effc459d3b 100644
> > --- a/libavfilter/vf_vpp_qsv.c
> > +++ b/libavfilter/vf_vpp_qsv.c
> > @@ -43,8 +43,9 @@
> >
> > /* number of video enhancement filters */
> > #define ENH_FILTERS_COUNT (7)
> > -#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
> > -#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> > +#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
> > +#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> > +#define QSV_HAVE_SCALING_CONFIG QSV_VERSION_ATLEAST(1, 19)
> >
> > typedef struct VPPContext{
> > const AVClass *class;
> > @@ -59,6 +60,9 @@ typedef struct VPPContext{
> > mfxExtVPPProcAmp procamp_conf;
> > mfxExtVPPRotation rotation_conf;
> > mfxExtVPPMirroring mirroring_conf;
> > +#ifdef QSV_HAVE_SCALING_CONFIG
> > +mfxExtVPPScaling scale_conf;
> > +#endif
> >
> > int out_width;
> > int out_height;
> > @@ -83,6 +87,8 @@ typedef struct VPPContext{
> > int rotate; /* rotate angle : [0, 90, 180,
> > 270] */
> > int hflip; /* flip mode : 0 = off, 1 =
> > HORIZONTAL flip */
> >
> > +int scale_mode; /* scale mode : 0 = auto, 1 = low
> > power, 2 = high quality */
> > +
> > /* param for the procamp */
> > intprocamp;/* enable procamp */
> > float hue;
> > @@ -128,6 +134,7 @@ static const AVOption options[] = {
> > { "h", "Output video height", OFFSET(oh),
> > AV_OPT_TYPE_STRING, { .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> > { "height", "Output video height", OFFSET(oh),
> > AV_OPT_TYPE_STRING, { .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> > { "format", "Output pixel format", OFFSET(output_format_str),
> > AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
> > +{ "scale_mode", "scale mode: 0=auto, 1=low power, 2=high
> > quality", OFFSET(scale_mode), AV_OPT_TYPE_INT, { .i64 =
> > MFX_SCALING_MODE_DEFAULT }, MFX_SCALING_MODE_DEFAULT,
> > MFX_SCALING_MODE_QUALITY, .flags = FLAGS, "scale mode" },
> >
> > { NULL }
> > };
> > @@ -454,6 +461,20 @@ static int config_output(AVFilterLink
> > *outlink)
> > #endif
> > }
> >
> > +if (inlink->w != outlink->w || inlink->h != outlink->h) {
> > +#ifdef QSV_HAVE_SCALING_CONFIG
> > +memset(>scale_conf, 0, sizeof(mfxExtVPPScaling));
> > +vpp->scale_conf.Header.BufferId=
> > MFX_EXTBUFF_VPP_SCALING;
> > +vpp->scale_conf.Header.BufferSz=
> > sizeof(mfxExtVPPScaling);
> > +vpp->scale_conf.ScalingMode= vpp->scale_mode;
> > +
> > +param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)
> > >scale_conf;
> > +#else
> > +av_log(ctx, AV_LOG_WARNING, "The QSV VPP Scale option is "
> > +"not supported with this MSDK version.\n");
> > +#endif
> > +}
> > +
> > if (vpp->use_frc || vpp->use_crop || vpp->deinterlace || vpp-
> > >denoise ||
> > vpp->detail || vpp->procamp || vpp->rotate || vpp->hflip
> > ||
> > inlink->w != outlink->w || inlink->h != outlink->h ||
> > in_format != vpp->out_format)
> > --
> > 2.17.1
> >
>
> Looks reasonable, and it seems the default behaviour is QUALITY mode
> on all platforms except for APL:
That's right. If scale_mode is set to auto, MSDK will choose different
mode(high-quality/low-power) on different platform.
>
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/shared/src/mfx_vpp_vaapi.cpp#L1258
>
> - linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
