Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Anton Khirnov (12022-11-08): > Sure, and that's about it. And as I said before - there is no way to > tell when a device will be ready, so this is of very limited usefulness. This is not true for many devices. Sorry to contradict you once again, but you would know it if you had any experience working with devices. > That is not a meaningful difference. A meaningful difference would be > one that has actionable consequences. Well, it has actionable consequences: if you treat EAGAIN like REDO you introduce a busy wait, and if you treat REDO like EAGAIN you introduce a significant slowness. Now that you make me mention it, I remember it was precisely the reason I introduced REDO: to fix a slowness in resyncs. -- 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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
On 11/9/22, Nicolas George wrote: > Anton Khirnov (12022-11-08): >> Sure, and that's about it. And as I said before - there is no way to >> tell when a device will be ready, so this is of very limited usefulness. > > This is not true for many devices. Sorry to contradict you once again, > but you would know it if you had any experience working with devices. > >> That is not a meaningful difference. A meaningful difference would be >> one that has actionable consequences. > > Well, it has actionable consequences: if you treat EAGAIN like REDO you > introduce a busy wait, and if you treat REDO like EAGAIN you introduce a > significant slowness. Now that you make me mention it, I remember it was > precisely the reason I introduced REDO: to fix a slowness in resyncs. > I'm not interested in REDO / EAGAIN differences. Can this bug be fixed at all? > -- > 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". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Paul B Mahol (12022-11-09): > I'm not interested in REDO / EAGAIN differences. They delete this thread. > Can this bug be fixed at all? This bug has been fixed for seven years. I would rather we do not unfix it. -- 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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
On 11/9/22, Nicolas George wrote: > Paul B Mahol (12022-11-09): >> I'm not interested in REDO / EAGAIN differences. > > They delete this thread. > >> Can this bug be fixed at all? > > This bug has been fixed for seven years. I would rather we do not unfix > it. The bug is found by Jan IIRC, and fixed by not using EAGAIN return values in demuxer IIRC. It would be better that bug is explained in commit log too. > > -- > 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". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Paul B Mahol (12022-11-09): > The bug is found by Jan IIRC, and fixed by not using EAGAIN return > values in demuxer IIRC. Then I do not know what bug you are referring to. Maybe try honing your communication skills. -- 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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Quoting Nicolas George (2022-11-09 09:21:34) > Anton Khirnov (12022-11-08): > > Sure, and that's about it. And as I said before - there is no way to > > tell when a device will be ready, so this is of very limited usefulness. > > This is not true for many devices. Sorry to contradict you once again, > but you would know it if you had any experience working with devices. We could really do with fewer of these personal attacks. > > That is not a meaningful difference. A meaningful difference would be > > one that has actionable consequences. > > Well, it has actionable consequences: if you treat EAGAIN like REDO you > introduce a busy wait, In most devices it's a sleep rather than a busy wait. And in those where it isn't, it should be. Furthermore, since the caller has no way of knowing how long to wait, there is little they can do other than sleeping for a random period and hoping for the best. > and if you treat REDO like EAGAIN you introduce a > significant slowness. Now that you make me mention it, I remember it was > precisely the reason I introduced REDO: to fix a slowness in resyncs. I highly doubt that returning control back to the caller will cause any slowdown in and of itself, it's more about what the caller will do in response. If they choose to sleep for a random amount of time, then maybe they should stop doing that (which is exactly what this patchset does). -- 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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Anton Khirnov (12022-11-09): > > Well, it has actionable consequences: if you treat EAGAIN like REDO you > > introduce a busy wait, > In most devices it's a sleep rather than a busy wait. And in those where > it isn't, it should be. I do not know how your sentence connects to mine. > Furthermore, since the caller has no way of knowing how long to wait, > there is little they can do other than sleeping for a random period and > hoping for the best. This is why I have wanted to fix the design of demuxers and demuxer-like components for years, but it is a tremendous work. In the meantime, we just do with "av_usleep(1000)" and it is terrible. > I highly doubt that returning control back to the caller will cause any > slowdown in and of itself, it's more about what the caller will do in > response. If they choose to sleep for a random amount of time, then > maybe they should stop doing that (which is exactly what this patchset > does). Sleeping is the only correct reaction to EAGAIN. -- 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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Quoting Nicolas George (2022-11-09 10:38:06) > Anton Khirnov (12022-11-09): > > > Well, it has actionable consequences: if you treat EAGAIN like REDO you > > > introduce a busy wait, > > In most devices it's a sleep rather than a busy wait. And in those where > > it isn't, it should be. > > I do not know how your sentence connects to mine. If your concern with busy-waiting is pointless energy consumption, then the correct thing to do is change all busy-waiting devices to sleep internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked, and almost all of them actually do exactly this, the only exception is avfoundation. > > > Furthermore, since the caller has no way of knowing how long to wait, > > there is little they can do other than sleeping for a random period and > > hoping for the best. > > This is why I have wanted to fix the design of demuxers and demuxer-like > components for years, but it is a tremendous work. In the meantime, we > just do with "av_usleep(1000)" and it is terrible. > > > I highly doubt that returning control back to the caller will cause any > > slowdown in and of itself, it's more about what the caller will do in > > response. If they choose to sleep for a random amount of time, then > > maybe they should stop doing that (which is exactly what this patchset > > does). > > Sleeping is the only correct reaction to EAGAIN. First, this would be an incredibly strong claim - given how many possible usage patterns there are - even if we did have support for user-side polling. But since we do not, then it's even more dubious, because the user does not know how long to sleep for. The only truly correct way to work with arbitrary demuxers currently is run it in blocking mode in a separate thread (which is exactly what ffmpeg.c does now). Furthermore this claim is not supported by development history. mpegts will currently return EAGAIN on failed resyncs, specifically to give the caller the opportunity to decide what to do next. RTSP does something similar. This has nothing to do with waiting for the network, because neither of these two demuxers know about the state of the network. And there is no essential difference between what mpegts does with EAGAIN and e.g. flvdec with REDO. The point of this set is giving control to the caller. If the caller wants blocking operations, they unset AVFMT_FLAG_NONBLOCK and don't have to deal with EAGAINs. If they want the limited support for context switching that lavf can provide, they set AVFMT_FLAG_NONBLOCK and decide what to do. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat: fix use of undeclared identifier error when compiling Chromium
I have reported the errors I encountered during the compilation process in the Chromium-Dev Group before, and I uploaded the detailed error information in this post. https://groups.google.com/a/chromium.org/g/chromium-dev/c/mB7yoDsYtbs The following is the address where I submitted CL to Chromium before. The patch submitted in it is the same as the patch I submit to ffmpeg now. I tested it with the patch I submitted myself and found that the defs.h and codec_id.h files were introduced. After that, the compilation can proceed normally. https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/4014019 "zhilizhao(赵志立)" 於 2022年11月9日週三 上午10:58寫道： > > > > On Nov 9, 2022, at 10:41, 揚帆起航 wrote: > > > > I encountered an error in the files included in this patch when compiling > > Chromium. When I followed this patch to modify the ffmpeg file in the > > Chromium source code, the compilation no longer reported errors. > > > > Chromium regularly merges the latest revisions of ffmpeg through > > Cherry-Pick. I also submitted this patch to Chromium before submitting it > > to ffmpeg, but Chromium asked me to submit it to ffmpeg first > > We can’t reproduce the issue, so more details of each ‘undeclared > identifier error’ should be given. For example, why > > >>> +#include "libavcodec/defs.h” > > is needed in flac_picture.c since it’s already included by avformat.h? > > > > > "zhilizhao(赵志立)" 於 2022年11月9日 週三 10:23 寫道： > > > >> > >> > >>> On Nov 9, 2022, at 03:48, uiopt...@gmail.com wrote: > >>> > >>> From: gz83 > >>> > >>> Cross-compiling Chromium on Ubuntu 22.04 will encounter errors related > >>> to avformat, because Chromium regularly synchronizes upstream changes, > >>> so now submit code directly to upstream > >>> --- > >>> libavformat/flac_picture.c | 3 ++- > >>> libavformat/matroskadec.c | 10 +- > >>> libavformat/mov.c | 11 ++- > >>> libavformat/oggdec.c | 1 + > >>> libavformat/riff.c | 1 + > >>> 5 files changed, 15 insertions(+), 11 deletions(-) > >>> > >>> diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c > >>> index b33fee75b4..36d190fdc7 100644 > >>> --- a/libavformat/flac_picture.c > >>> +++ b/libavformat/flac_picture.c > >>> @@ -19,9 +19,10 @@ > >>> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > >> 02110-1301 USA > >>> */ > >>> > >>> -#include "libavutil/intreadwrite.h" > >>> #include "libavcodec/bytestream.h" > >>> +#include "libavcodec/defs.h" > >>> #include "libavcodec/png.h" > >>> +#include "libavutil/intreadwrite.h" > >>> #include "avformat.h" > >>> #include "demux.h" > >>> #include "flac_picture.h" > >>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > >>> index d582f566a2..f7bb962941 100644 > >>> --- a/libavformat/matroskadec.c > >>> +++ b/libavformat/matroskadec.c > >>> @@ -34,6 +34,11 @@ > >>> #include > >>> #include > >>> > >>> +#include "libavcodec/bytestream.h" > >>> +#include "libavcodec/defs.h" > >>> +#include "libavcodec/flac.h" > >>> +#include "libavcodec/mpeg4audio.h" > >>> +#include "libavcodec/packet_internal.h" > >>> #include "libavutil/avstring.h" > >>> #include "libavutil/base64.h" > >>> #include "libavutil/bprint.h" > >>> @@ -50,11 +55,6 @@ > >>> #include "libavutil/time_internal.h" > >>> #include "libavutil/spherical.h" > >>> > >>> -#include "libavcodec/bytestream.h" > >>> -#include "libavcodec/flac.h" > >>> -#include "libavcodec/mpeg4audio.h" > >>> -#include "libavcodec/packet_internal.h" > >>> - > >>> #include "avformat.h" > >>> #include "avio_internal.h" > >>> #include "demux.h" > >>> diff --git a/libavformat/mov.c b/libavformat/mov.c > >>> index 1f436e21d6..39d2c71edb 100644 > >>> --- a/libavformat/mov.c > >>> +++ b/libavformat/mov.c > >>> @@ -29,6 +29,12 @@ > >>> #include > >>> #include > >>> > >>> +#include "libavcodec/ac3tab.h" > >>> +#include "libavcodec/defs.h" > >>> +#include "libavcodec/flac.h" > >>> +#include "libavcodec/hevc.h" > >>> +#include "libavcodec/mpegaudiodecheader.h" > >>> +#include "libavcodec/mlp_parse.h" > >>> #include "libavutil/attributes.h" > >>> #include "libavutil/bprint.h" > >>> #include "libavutil/channel_layout.h" > >>> @@ -49,11 +55,6 @@ > >>> #include "libavutil/stereo3d.h" > >>> #include "libavutil/timecode.h" > >>> #include "libavutil/uuid.h" > >>> -#include "libavcodec/ac3tab.h" > >>> -#include "libavcodec/flac.h" > >>> -#include "libavcodec/hevc.h" > >>> -#include "libavcodec/mpegaudiodecheader.h" > >>> -#include "libavcodec/mlp_parse.h" > >>> #include "avformat.h" > >>> #include "internal.h" > >>> #include "avio_internal.h" > >>> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c > >>> index 3b19e0bd89..c4321a9436 100644 > >>> --- a/libavformat/oggdec.c > >>> +++ b/libavformat/oggdec.c > >>> @@ -29,6 +29,7 @@ > >>> */ > >>> > >>> #include > >>> +#include "libavcodec/defs.h" > >>> #include "libavutil/avassert.h" > >>> #include "libavutil/intreadwrite.h" > >>> #include "avio_internal.h" > >>> diff --git a/libavf
Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Anton Khirnov (12022-11-09): > If your concern with busy-waiting is pointless energy consumption, then > the correct thing to do is change all busy-waiting devices to sleep > internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked, and > almost all of them actually do exactly this, the only exception is > avfoundation. Yes, devices currently do the right thing as much as our framework permits. Breaking that is one of the two ways merging EAGAIN and REDO can break our code. > First, this would be an incredibly strong claim - given how many > possible usage patterns there are Mostly true nonetheless. > The only truly > correct way to work with arbitrary demuxers currently is run it in > blocking mode in a separate thread (which is exactly what ffmpeg.c does > now). It is not a correct way, only slightly less broken. > Furthermore this claim is not supported by development history. mpegts > will currently return EAGAIN on failed resyncs, specifically to give the > caller the opportunity to decide what to do next. IIRC, this is precisely what REDO was introduced to fix. If the bug was introduced again or incompletely fixed, this it is an issue. Indeed, the two uses of EAGAIN in libavformat/mpegts.c seems highly dubious. But as I explained, REDO and EAGAIN have a very different semantic with regard to when the caller needs to retry and cannot be merged. Now, if you want me to take from my time to explain it again with more details and more clarity for your benefit… I suggest you tone done the condescension towards me. -- 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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Quoting Nicolas George (2022-11-09 11:41:32) > Anton Khirnov (12022-11-09): > > If your concern with busy-waiting is pointless energy consumption, then > > the correct thing to do is change all busy-waiting devices to sleep > > internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked, and > > almost all of them actually do exactly this, the only exception is > > avfoundation. > > Yes, devices currently do the right thing as much as our framework > permits. > > Breaking that is one of the two ways merging EAGAIN and REDO can break > our code. I have no idea what you mean by this. What is being broken and how? > > Furthermore this claim is not supported by development history. mpegts > > will currently return EAGAIN on failed resyncs, specifically to give the > > caller the opportunity to decide what to do next. > > IIRC, this is precisely what REDO was introduced to fix. If the bug was > introduced again or incompletely fixed, this it is an issue. Indeed, the > two uses of EAGAIN in libavformat/mpegts.c seems highly dubious. > > But as I explained, REDO and EAGAIN have a very different semantic with > regard to when the caller needs to retry and cannot be merged. Maybe more context will clarify the motivation here. What became this patchset started as an attempt to make all uses of EAGAIN/REDO in lavf/lavd consistent. While doing that I gradually came to the conclusion that the distinction is arbitrary - e.g. multiple demuxers deliberately return EAGAIN as context switch method. Now we could declare this practice invalid, but as this has been done in multiple demuxers independently, and has been in the tree for over 10 years, so this should not be done lightly. The question then is - what should be the effective rule for deciding whether a demuxer returns EAGAIN or REDO in any given case? Opinions on this are very much welcome. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavfi/vf_decimate: add mixed option to process input only partially to be decimated
Enabling the option will only decimate frames below dupthresh and output at
variable frame rate.
Signed-off-by: lovesyk
---
libavfilter/vf_decimate.c | 42 +--
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/libavfilter/vf_decimate.c b/libavfilter/vf_decimate.c
index f61e501c96..dbeca427f1 100644
--- a/libavfilter/vf_decimate.c
+++ b/libavfilter/vf_decimate.c
@@ -44,6 +44,7 @@ typedef struct DecimateContext {
AVFrame **clean_src;///< frame queue for the clean source
int got_frame[2]; ///< frame request flag for each input stream
int64_t last_pts; ///< last output timestamp
+int64_t last_duration; ///< last output duration
int64_t start_pts; ///< base for output timestamps
uint32_t eof; ///< bitmask for end of stream
int hsub, vsub; ///< chroma subsampling values
@@ -51,6 +52,9 @@ typedef struct DecimateContext {
int nxblocks, nyblocks;
int bdiffsize;
int64_t *bdiffs;
+AVRational in_tb; // input time-base
+AVRational nondec_tb; // non-decimated time-base
+AVRational dec_tb; // decimated time-base
/* options */
int cycle;
@@ -61,6 +65,7 @@ typedef struct DecimateContext {
int blockx, blocky;
int ppsrc;
int chroma;
+int mixed;
} DecimateContext;
#define OFFSET(x) offsetof(DecimateContext, x)
@@ -74,6 +79,7 @@ static const AVOption decimate_options[] = {
{ "blocky","set the size of the y-axis blocks used during metric
calculations", OFFSET(blocky), AV_OPT_TYPE_INT, {.i64 = 32}, 4, 1<<9, FLAGS
},
{ "ppsrc", "mark main input as a pre-processed input and activate
clean source input stream", OFFSET(ppsrc), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
FLAGS },
{ "chroma","set whether or not chroma is considered in the metric
calculations", OFFSET(chroma), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
+{ "mixed", "set whether or not the input only partially contains
content to be decimated", OFFSET(mixed), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
FLAGS },
{ NULL }
};
@@ -193,7 +199,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*in)
}
if (dm->queue[lowest].maxbdiff < dm->dupthresh)
duppos = lowest;
-drop = scpos >= 0 && duppos < 0 ? scpos : lowest;
+
+if (dm->mixed && duppos < 0) {
+drop = -1; // no drop if mixed content + no frame in cycle
below threshold
+} else {
+drop = scpos >= 0 && duppos < 0 ? scpos : lowest;
+}
}
/* metrics debug */
@@ -212,7 +223,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*in)
/* push all frames except the drop */
ret = 0;
for (i = 0; i < dm->cycle && dm->queue[i].frame; i++) {
-AVRational in_tb = ctx->inputs[INPUT_MAIN]->time_base;
if (i == drop) {
if (dm->ppsrc)
av_frame_free(&dm->clean_src[i]);
@@ -221,7 +231,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*in)
AVFrame *frame = dm->queue[i].frame;
dm->queue[i].frame = NULL;
if (frame->pts != AV_NOPTS_VALUE && dm->start_pts ==
AV_NOPTS_VALUE)
-dm->start_pts = av_rescale_q(frame->pts, in_tb,
outlink->time_base);
+dm->start_pts = av_rescale_q(frame->pts, dm->in_tb,
outlink->time_base);
if (dm->ppsrc) {
av_frame_free(&frame);
@@ -230,9 +240,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*in)
continue;
dm->clean_src[i] = NULL;
}
-frame->pts = outlink->frame_count_in +
+
+frame->pts = dm->last_duration ? dm->last_pts +
dm->last_duration :
(dm->start_pts == AV_NOPTS_VALUE ? 0 :
dm->start_pts);
-frame->duration = 1;
+frame->duration = dm->mixed ? av_div_q(drop < 0 ? dm->nondec_tb
: dm->dec_tb, outlink->time_base).num : 1;
+dm->last_duration = frame->duration;
dm->last_pts = frame->pts;
ret = ff_filter_frame(outlink, frame);
if (ret < 0)
@@ -329,6 +341,7 @@ static av_cold int decimate_init(AVFilterContext *ctx)
}
dm->start_pts = AV_NOPTS_VALUE;
+dm->last_duration = 0;
return 0;
}
@@ -388,6 +401,9 @@ static int config_output(AVFilterLink *outlink)
dm->bdiffsize = dm->nxblocks * dm->nyblocks;
dm->bdiffs= av_malloc_array(dm->bdiffsize, sizeof(*dm->bdiffs));
dm->queue = av_calloc(dm->cycle, sizeof(*dm->queue));
+dm->in_tb = inlink->time_base;
+dm->nondec_tb = av_inv_q(fps);
+dm->dec_tb= av_mul_q(dm->nondec_tb, (AVRational){dm->cycle,
dm->cycle - 1});
if (!dm->bdiffs || !dm->queue)
return AVERROR(ENOMEM);
@@ -403,11 +419,17 @@ static int config_output(AVFilterLink *outlink)
"current rate of %d/%d is invalid\n", fps.num, fps.den);
return AVE
Re: [FFmpeg-devel] [PATCH] lavfi/vf_decimate: add mixed option to process input only partially to be decimated
The purpose of this new option is to enable processing of mixed content such as TV recordings or even movies which have some cuts in telecined 24fps and others in 30p. Enabling it (mixed=1) will calculate a common timebase between decimated and non-decimated content and set frame duration according to whether the current cycle contains a frame deemed to be a duplicate or not. The default is disabled (mixed=0) and keeping it disabled will keep the PTS as before (verified using ffprobe). Regarding setting frame->pts, I had to adjust this part a bit as it is no longer possible to assume all frames counted by frame_count_in have the same duration. As for outlink->frame_rate, I have removed the assignment in the case of mixed content as the output will be of variable frame rate. Please tell me in case this is not sufficient to signalize VFR content. An example for verifying the result is http://samples.ffmpeg.org/HDTV/Hellboy.ts ffmpeg -i Hellboy.ts -map 0:v -c:v libx264 -vf fps=fps=3/1001,fieldmatch,decimate=mixed=1,fps=fps=12/1001 -preset veryfast -crf 10 Hellboy.mp4 The source has a frame rate of 3/1001 -> timebase 1001/3 which with a decimation cycle of 5 results in a decimated timebase of 24000/1001 and a common timebase of 1001/12. The source contains 24fps interlaced content which will result in a duration of 5 frames at the output frame rate of 12/1001. The source also contains 30p content which in the output will have a duration of 4 frames. This particular source requires the frame rate to be set to constant 3/1001. I haven't looked into why but I have verified this to also be required if not applying this patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Anton Khirnov (12022-11-09): > I have no idea what you mean by this. What is being broken and how? EAGAIN and REDO are different. If you make them the same, you break one of them. Or possibly both if you are being really stupid, but at least one. > Maybe more context will clarify the motivation here. What became this > patchset started as an attempt to make all uses of EAGAIN/REDO in > lavf/lavd consistent. And as I explained, it is not possible. > While doing that I gradually came to the > conclusion that the distinction is arbitrary - e.g. multiple demuxers > deliberately return EAGAIN as context switch method. Now we could > declare this practice invalid, but as this has been done in multiple > demuxers independently, and has been in the tree for over 10 years, so > this should not be done lightly. I introduced REDO precisely to fix demuxers who abused EAGAIN like that. > The question then is - what should be the effective rule for deciding > whether a demuxer returns EAGAIN or REDO in any given case? > Opinions on this are very much welcome. I do not have an opinion, I have knowledge. The semantic of EAGAIN has always been, since it stabilized, that the operation cannot be completed immediately, it requires an external event, like a network packet or an IRQ on a device. Therefore, the only correct reaction to EAGAIN is to delay retrying. Ideally delay until an event is received; if that cannot be achieved a small arbitrary delay is still infinitely better than busy wait. This is standard Unix system and network programming, knowing this in and out is IMO an absolute prerequisite for tinkering with FFmpeg's network code. The semantic of AVERROR(EAGAIN) is ours to decide, but it would be really really stupid from us to decide for something that is not aligned with the wider semantic of EAGAIN. And aligning with EAGAIN is what we did, with the caveat that most of it only works with devices and elementary protocols. Except for the bugs at hand. Now, as you observed, some demuxers have abused AVERROR(EAGAIN) to let the framework re-call them and continue their work, for example looking for a resync marker. This is an abuse, this is invalid. If AVERROR(EAGAIN) is handled correctly, using it to look for a resync marker causes a delay to be inserted. The delay is very small, negligible in most cases, but it should not be there. And if the resync marker is hard to find, the delay will add up. If I remember correctly, this is precisely the issue AVERROR_REDO fixes: a damaged sample that would be very slow to demux without consuming CPU because of the delays introduced by the correct handling of AVERROR(EAGAIN). There was another way to fix the issue: have the demuxers loop themselves looking for a resync. But it would have required more reworking of the code. Last detail: we do not have the API to return to the user in the middle of the search for a resync marker. If this is something you want for some reason, you will need to introduce something new. But if so, please first explain your use case. -- 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 v2 1/2] avformat/file: Add a specialized url_check callback for pipe protocol
Bump.
Is anyone interested in looking at these two patches? I’m trying to get
into ffmpeg development and it would be nice to get some experience of
the full process of getting a patch landed. I don’t have commit rights.
Thanks in advance for any feedback.
Regards,
– Neil
Neil Roberts writes:
> Using file_check for the pipe protocol doesn't make sense. For example,
> for a URL like “pipe:0” it would end up checking whether the “pipe:0”
> file exists. This patch instead makes it check the access modes on the
> corresponding file descriptor using fcntl on *nix and DuplicateHandle on
> Windows.
>
> v2: Use DuplicateHandle on Windows to check whether the duplicated
> handle can have the corresponding access flags.
>
> Signed-off-by: Neil Roberts
> ---
> libavformat/file.c | 74 --
> 1 file changed, 71 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 98c9e81bcb..b3f7bc9282 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -375,9 +375,8 @@ const URLProtocol ff_file_protocol = {
>
> #if CONFIG_PIPE_PROTOCOL
>
> -static int pipe_open(URLContext *h, const char *filename, int flags)
> +static int pipe_get_fd(const char *filename, int flags)
> {
> -FileContext *c = h->priv_data;
> int fd;
> char *final;
> av_strstart(filename, "pipe:", &filename);
> @@ -390,6 +389,14 @@ static int pipe_open(URLContext *h, const char
> *filename, int flags)
> fd = 0;
> }
> }
> +
> +return fd;
> +}
> +
> +static int pipe_open(URLContext *h, const char *filename, int flags)
> +{
> +FileContext *c = h->priv_data;
> +int fd = pipe_get_fd(filename, flags);
> #if HAVE_SETMODE
> setmode(fd, O_BINARY);
> #endif
> @@ -398,13 +405,74 @@ static int pipe_open(URLContext *h, const char
> *filename, int flags)
> return 0;
> }
>
> +static int pipe_check(URLContext *h, int mask)
> +{
> +int fd = pipe_get_fd(h->filename, mask);
> +int access = 0;
> +
> +#ifdef _WIN32
> +
> +HANDLE pipe_handle = (HANDLE) _get_osfhandle(fd);
> +HANDLE tmp_handle;
> +
> +if (pipe_handle == INVALID_HANDLE_VALUE)
> +return AVERROR(errno);
> +
> +if (mask & AVIO_FLAG_READ &&
> +DuplicateHandle(GetCurrentProcess(), /* hSourceProcessHandle */
> +pipe_handle,
> +GetCurrentProcess(), /* hTargetProcessHandle */
> +&tmp_handle,
> +FILE_READ_DATA,
> +FALSE, /* bInheritHandle */
> +0 /* options */)) {
> +access |= AVIO_FLAG_READ;
> +CloseHandle(tmp_handle);
> +}
> +
> +if (mask & AVIO_FLAG_WRITE &&
> +DuplicateHandle(GetCurrentProcess(), /* hSourceProcessHandle */
> +pipe_handle,
> +GetCurrentProcess(), /* hTargetProcessHandle */
> +&tmp_handle,
> +FILE_WRITE_DATA,
> +FALSE, /* bInheritHandle */
> +0 /* options */)) {
> +access |= AVIO_FLAG_WRITE;
> +CloseHandle(tmp_handle);
> +}
> +
> +#else /* _WIN32 */
> +
> +int status_flags = fcntl(fd, F_GETFL);
> +
> +if (status_flags == -1)
> +return AVERROR(errno);
> +
> +switch (status_flags & O_ACCMODE) {
> +case O_RDONLY:
> +access = AVIO_FLAG_READ;
> +break;
> +case O_WRONLY:
> +access = AVIO_FLAG_WRITE;
> +break;
> +case O_RDWR:
> +access = AVIO_FLAG_READ | AVIO_FLAG_WRITE;
> +break;
> +}
> +
> +#endif /* _WIN32 */
> +
> +return access & mask;
> +}
> +
> const URLProtocol ff_pipe_protocol = {
> .name= "pipe",
> .url_open= pipe_open,
> .url_read= file_read,
> .url_write = file_write,
> .url_get_file_handle = file_get_handle,
> -.url_check = file_check,
> +.url_check = pipe_check,
> .priv_data_size = sizeof(FileContext),
> .priv_data_class = &pipe_class,
> .default_whitelist = "crypto,data"
> --
> 2.37.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 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/5] avcodec/clearvideo: Remove unnecessary level parameter
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/clearvideo.c | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/clearvideo.c b/libavcodec/clearvideo.c
> index 4d6549560b..82311bc645 100644
> --- a/libavcodec/clearvideo.c
> +++ b/libavcodec/clearvideo.c
> @@ -362,19 +362,18 @@ static void mvi_update_row(MVInfo *mvi)
> }
> }
>
> -static TileInfo *decode_tile_info(GetBitContext *gb, const LevelCodes *lc,
> int level)
> +static TileInfo *decode_tile_info(GetBitContext *gb, const LevelCodes *lc)
> {
> TileInfo *ti;
> int i, flags = 0;
> int16_t bias = 0;
> MV mv = { 0 };
>
> -if (lc[level].flags_cb.table) {
> -flags = get_vlc2(gb, lc[level].flags_cb.table, CLV_VLC_BITS, 2);
> -}
> +if (lc->flags_cb.table)
> +flags = get_vlc2(gb, lc->flags_cb.table, CLV_VLC_BITS, 2);
>
> -if (lc[level].mv_cb.table) {
> -uint16_t mv_code = get_vlc2(gb, lc[level].mv_cb.table, CLV_VLC_BITS,
> 2);
> +if (lc->mv_cb.table) {
> +uint16_t mv_code = get_vlc2(gb, lc->mv_cb.table, CLV_VLC_BITS, 2);
>
> if (mv_code != MV_ESC) {
> mv.x = (int8_t)(mv_code & 0xff);
> @@ -385,8 +384,8 @@ static TileInfo *decode_tile_info(GetBitContext *gb,
> const LevelCodes *lc, int l
> }
> }
>
> -if (lc[level].bias_cb.table) {
> -uint16_t bias_val = get_vlc2(gb, lc[level].bias_cb.table,
> CLV_VLC_BITS, 2);
> +if (lc->bias_cb.table) {
> +uint16_t bias_val = get_vlc2(gb, lc->bias_cb.table, CLV_VLC_BITS, 2);
>
> if (bias_val != BIAS_ESC) {
> bias = (int16_t)(bias_val);
> @@ -406,7 +405,7 @@ static TileInfo *decode_tile_info(GetBitContext *gb,
> const LevelCodes *lc, int l
> if (ti->flags) {
> for (i = 0; i < 4; i++) {
> if (ti->flags & (1 << i)) {
> -TileInfo *subti = decode_tile_info(gb, lc, level + 1);
> +TileInfo *subti = decode_tile_info(gb, lc + 1);
> ti->child[i] = subti;
> }
> }
> @@ -599,7 +598,7 @@ static int clv_decode_frame(AVCodecContext *avctx,
> AVFrame *rframe,
> TileInfo *tile;
> MV mv, cmv;
>
> -tile = decode_tile_info(&c->gb, &lev[0], 0); // Y
> +tile = decode_tile_info(&c->gb, &lev[0]); // Y
> if (!tile)
> return AVERROR(ENOMEM);
> mv = mvi_predict(&c->mvi, i, j, tile->mv);
> @@ -614,14 +613,14 @@ static int clv_decode_frame(AVCodecContext *avctx,
> AVFrame *rframe,
> cmv.x /= 2;
> cmv.y /= 2;
> av_freep(&tile);
> -tile = decode_tile_info(&c->gb, &lev[4], 0); // U
> +tile = decode_tile_info(&c->gb, &lev[4]); // U
> if (!tile)
> return AVERROR(ENOMEM);
> ret = restore_tree(avctx, c->pic, c->prev, 1, x, y,
> size, tile, cmv);
> if (ret < 0)
> mb_ret = ret;
> av_freep(&tile);
> -tile = decode_tile_info(&c->gb, &lev[7], 0); // V
> +tile = decode_tile_info(&c->gb, &lev[7]); // V
> if (!tile)
> return AVERROR(ENOMEM);
> ret = restore_tree(avctx, c->pic, c->prev, 2, x, y,
> size, tile, cmv);
Will apply this patchset tomorrow unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avfilter/af_surround: Check return value of av_tx_init()
Should fix Coverity issue #1516766.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/af_surround.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/libavfilter/af_surround.c b/libavfilter/af_surround.c
index 858fed609a..969325cf6b 100644
--- a/libavfilter/af_surround.c
+++ b/libavfilter/af_surround.c
@@ -194,7 +194,7 @@ static int config_input(AVFilterLink *inlink)
{
AVFilterContext *ctx = inlink->dst;
AudioSurroundContext *s = ctx->priv;
-int ch;
+int ch, err;
s->rdft = av_calloc(inlink->ch_layout.nb_channels, sizeof(*s->rdft));
if (!s->rdft)
@@ -204,9 +204,10 @@ static int config_input(AVFilterLink *inlink)
for (ch = 0; ch < inlink->ch_layout.nb_channels; ch++) {
float scale = 1.f;
-av_tx_init(&s->rdft[ch], &s->tx_fn, AV_TX_FLOAT_RDFT, 0, s->buf_size,
&scale, 0);
-if (!s->rdft[ch])
-return AVERROR(ENOMEM);
+err = av_tx_init(&s->rdft[ch], &s->tx_fn, AV_TX_FLOAT_RDFT,
+ 0, s->buf_size, &scale, 0);
+if (err < 0)
+return err;
}
s->input_levels = av_malloc_array(s->nb_in_channels,
sizeof(*s->input_levels));
if (!s->input_levels)
@@ -263,7 +264,7 @@ static int config_output(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
AudioSurroundContext *s = ctx->priv;
-int ch;
+int ch, err;
s->irdft = av_calloc(outlink->ch_layout.nb_channels, sizeof(*s->irdft));
if (!s->irdft)
@@ -273,9 +274,10 @@ static int config_output(AVFilterLink *outlink)
for (ch = 0; ch < outlink->ch_layout.nb_channels; ch++) {
float iscale = 1.f;
-av_tx_init(&s->irdft[ch], &s->itx_fn, AV_TX_FLOAT_RDFT, 1,
s->buf_size, &iscale, 0);
-if (!s->irdft[ch])
-return AVERROR(ENOMEM);
+err = av_tx_init(&s->irdft[ch], &s->itx_fn, AV_TX_FLOAT_RDFT,
+ 1, s->buf_size, &iscale, 0);
+if (err < 0)
+return err;
}
s->output_levels = av_malloc_array(s->nb_out_channels,
sizeof(*s->output_levels));
if (!s->output_levels)
--
2.34.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/4] avfilter/vf_fftfilt: Check return value of av_tx_init()
Should fix Coverity issue #1516765.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_fftfilt.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/libavfilter/vf_fftfilt.c b/libavfilter/vf_fftfilt.c
index 067ce7eb30..231e74fd72 100644
--- a/libavfilter/vf_fftfilt.c
+++ b/libavfilter/vf_fftfilt.c
@@ -306,7 +306,7 @@ static int config_props(AVFilterLink *inlink)
{
FFTFILTContext *s = inlink->dst->priv;
const AVPixFmtDescriptor *desc;
-int i, plane;
+int err, i, plane;
desc = av_pix_fmt_desc_get(inlink->format);
s->depth = desc->comp[0].depth;
@@ -335,12 +335,14 @@ static int config_props(AVFilterLink *inlink)
for (int j = 0; j < s->nb_threads; j++) {
float scale = 1.f, iscale = 1.f;
-av_tx_init(&s->hrdft[j][i], &s->htx_fn, AV_TX_FLOAT_RDFT, 0, 1 <<
s->rdft_hbits[i], &scale, 0);
-if (!s->hrdft[j][i])
-return AVERROR(ENOMEM);
-av_tx_init(&s->ihrdft[j][i], &s->ihtx_fn, AV_TX_FLOAT_RDFT, 1, 1
<< s->rdft_hbits[i], &iscale, 0);
-if (!s->ihrdft[j][i])
-return AVERROR(ENOMEM);
+err = av_tx_init(&s->hrdft[j][i], &s->htx_fn, AV_TX_FLOAT_RDFT,
+ 0, 1 << s->rdft_hbits[i], &scale, 0);
+if (err < 0)
+return err;
+err = av_tx_init(&s->ihrdft[j][i], &s->ihtx_fn, AV_TX_FLOAT_RDFT,
+ 1, 1 << s->rdft_hbits[i], &iscale, 0);
+if (err < 0)
+return err;
}
/* RDFT - Array initialization for Vertical pass*/
@@ -356,12 +358,14 @@ static int config_props(AVFilterLink *inlink)
for (int j = 0; j < s->nb_threads; j++) {
float scale = 1.f, iscale = 1.f;
-av_tx_init(&s->vrdft[j][i], &s->vtx_fn, AV_TX_FLOAT_RDFT, 0, 1 <<
s->rdft_vbits[i], &scale, 0);
-if (!s->vrdft[j][i])
-return AVERROR(ENOMEM);
-av_tx_init(&s->ivrdft[j][i], &s->ivtx_fn, AV_TX_FLOAT_RDFT, 1, 1
<< s->rdft_vbits[i], &iscale, 0);
-if (!s->ivrdft[j][i])
-return AVERROR(ENOMEM);
+err = av_tx_init(&s->vrdft[j][i], &s->vtx_fn, AV_TX_FLOAT_RDFT,
+ 0, 1 << s->rdft_vbits[i], &scale, 0);
+if (err < 0)
+return err;
+err = av_tx_init(&s->ivrdft[j][i], &s->ivtx_fn, AV_TX_FLOAT_RDFT,
+ 1, 1 << s->rdft_vbits[i], &iscale, 0);
+if (err < 0)
+return err;
}
}
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avfilter/af_afir: Check return value of av_tx_init()
Should fix Coverity issue #1516762.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/af_afir.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
index e1fe7d6a64..910999cce7 100644
--- a/libavfilter/af_afir.c
+++ b/libavfilter/af_afir.c
@@ -158,6 +158,7 @@ static int init_segment(AVFilterContext *ctx,
AudioFIRSegment *seg,
int offset, int nb_partitions, int part_size)
{
AudioFIRContext *s = ctx->priv;
+int err;
seg->tx = av_calloc(ctx->inputs[0]->ch_layout.nb_channels,
sizeof(*seg->tx));
seg->itx = av_calloc(ctx->inputs[0]->ch_layout.nb_channels,
sizeof(*seg->itx));
@@ -178,22 +179,29 @@ static int init_segment(AVFilterContext *ctx,
AudioFIRSegment *seg,
return AVERROR(ENOMEM);
for (int ch = 0; ch < ctx->inputs[0]->ch_layout.nb_channels && part_size
>= 8; ch++) {
-double dscale = 1.0, idscale = 1.0 / part_size;
-float fscale = 1.f, ifscale = 1.f / part_size;
+union { double d; float f; } scale, iscale;
+enum AVTXType tx_type;
switch (s->format) {
case AV_SAMPLE_FMT_FLTP:
-av_tx_init(&seg->tx[ch], &seg->tx_fn, AV_TX_FLOAT_RDFT, 0, 2 *
part_size, &fscale, 0);
-av_tx_init(&seg->itx[ch], &seg->itx_fn, AV_TX_FLOAT_RDFT, 1, 2 *
part_size, &ifscale, 0);
+scale.f = 1.f;
+iscale.f = 1.f / part_size;
+tx_type = AV_TX_FLOAT_RDFT;
break;
case AV_SAMPLE_FMT_DBLP:
-av_tx_init(&seg->tx[ch], &seg->tx_fn, AV_TX_DOUBLE_RDFT, 0, 2 *
part_size, &dscale, 0);
-av_tx_init(&seg->itx[ch], &seg->itx_fn, AV_TX_DOUBLE_RDFT, 1, 2 *
part_size, &idscale, 0);
+scale.d = 1.0;
+iscale.d = 1.0 / part_size;
+tx_type = AV_TX_DOUBLE_RDFT;
break;
}
-
-if (!seg->tx[ch] || !seg->itx[ch])
-return AVERROR(ENOMEM);
+err = av_tx_init(&seg->tx[ch], &seg->tx_fn, tx_type,
+ 0, 2 * part_size, &scale, 0);
+if (err < 0)
+return err;
+err = av_tx_init(&seg->itx[ch], &seg->itx_fn, tx_type,
+ 1, 2 * part_size, &iscale, 0);
+if (err < 0)
+return err;
}
seg->sumin = ff_get_audio_buffer(ctx->inputs[0], seg->fft_length);
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] avfilter/vf_fftdnoiz: Check return value of av_tx_init()
Should fix Coverity issue #1500329.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_fftdnoiz.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_fftdnoiz.c b/libavfilter/vf_fftdnoiz.c
index e74f40b4cb..f7200699c6 100644
--- a/libavfilter/vf_fftdnoiz.c
+++ b/libavfilter/vf_fftdnoiz.c
@@ -208,13 +208,17 @@ static int config_input(AVFilterLink *inlink)
for (int i = 0; i < s->nb_threads; i++) {
float scale = 1.f, iscale = 1.f;
-
-av_tx_init(&s->fft[i], &s->tx_fn, AV_TX_FLOAT_FFT, 0, s->block_size,
&scale, 0);
-av_tx_init(&s->ifft[i], &s->itx_fn, AV_TX_FLOAT_FFT, 1, s->block_size,
&iscale, 0);
-av_tx_init(&s->fft_r[i], &s->tx_r_fn, AV_TX_FLOAT_FFT, 0, 1 +
s->nb_prev + s->nb_next, &scale, 0);
-av_tx_init(&s->ifft_r[i], &s->itx_r_fn, AV_TX_FLOAT_FFT, 1, 1 +
s->nb_prev + s->nb_next, &iscale, 0);
-if (!s->fft[i] || !s->ifft[i] || !s->fft_r[i] || !s->ifft_r[i])
-return AVERROR(ENOMEM);
+int err;
+
+if ((err = av_tx_init(&s->fft[i],&s->tx_fn,AV_TX_FLOAT_FFT,
+ 0, s->block_size, &scale, 0)) < 0
||
+(err = av_tx_init(&s->ifft[i], &s->itx_fn, AV_TX_FLOAT_FFT,
+ 1, s->block_size, &iscale, 0)) < 0
||
+(err = av_tx_init(&s->fft_r[i], &s->tx_r_fn, AV_TX_FLOAT_FFT,
+ 0, 1 + s->nb_prev + s->nb_next, &scale, 0)) < 0
||
+(err = av_tx_init(&s->ifft_r[i], &s->itx_r_fn, AV_TX_FLOAT_FFT,
+ 1, 1 + s->nb_prev + s->nb_next, &iscale, 0)) < 0)
+return err;
}
for (i = 0; i < s->nb_planes; i++) {
--
2.34.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/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa)
Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 : Support for mlpa muxing was added back in 2019: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no support from other applications. In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 For VLC: videolan/vlc@9c49f40 Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 And mpv does support this as well. If there was ever a good reason to make this feature experimental, I don't think these applications change the situation. The reason to make this experimental was, because there was no implementation from others at this time. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html Now, there is implementation from others. How many implementation from others will be needed to change the situation? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] [RFC PATCH] lavd/v4l2: cover all bufer if bytesperline is set by driver
Some drivers may set bytesperline if hardware use padding bytes for
alignment. In this case lavd/v4l2 will expect W*H bytes per frame, but
driver will provide Pitch*H bytes which makes v4l2 unhappy.
This change adjusts frame width to cover entire data buffer aligning
lavd/v4l2 expectations with data provided by the driver. As a result
user will be able to get image stream from device, albeit having
garbage in padding bytes.
Signed-off-by: Dima Buzdyk
---
libavdevice/v4l2.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 5e85d1a2b3..b1e837f740 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -83,7 +83,7 @@ struct video_data {
AVClass *class;
int fd;
int pixelformat; /* V4L2_PIX_FMT_* */
-int width, height;
+int width, height, pitch;
int frame_size;
int interlaced;
int top_field_first;
@@ -202,7 +202,7 @@ fail:
}
static int device_init(AVFormatContext *ctx, int *width, int *height,
- uint32_t pixelformat)
+ int *pitch, uint32_t pixelformat)
{
struct video_data *s = ctx->priv_data;
struct v4l2_format fmt = { .type = V4L2_BUF_TYPE_VIDEO_CAPTURE };
@@ -224,6 +224,7 @@ static int device_init(AVFormatContext *ctx, int *width,
int *height,
*width, *height, fmt.fmt.pix.width, fmt.fmt.pix.height);
*width = fmt.fmt.pix.width;
*height = fmt.fmt.pix.height;
+*pitch = fmt.fmt.pix.bytesperline;
}
if (pixelformat != fmt.fmt.pix.pixelformat) {
@@ -779,6 +780,7 @@ static int device_try_init(AVFormatContext *ctx,
enum AVPixelFormat pix_fmt,
int *width,
int *height,
+ int *pitch,
uint32_t *desired_format,
enum AVCodecID *codec_id)
{
@@ -787,7 +789,7 @@ static int device_try_init(AVFormatContext *ctx,
*desired_format = ff_fmt_ff2v4l(pix_fmt, ctx->video_codec_id);
if (*desired_format) {
-ret = device_init(ctx, width, height, *desired_format);
+ret = device_init(ctx, width, height, pitch, *desired_format);
if (ret < 0) {
*desired_format = 0;
if (ret != AVERROR(EINVAL))
@@ -804,7 +806,7 @@ static int device_try_init(AVFormatContext *ctx,
(char
*)av_x_if_null(av_get_pix_fmt_name(ff_fmt_conversion_table[i].ff_fmt), "none"));
*desired_format = ff_fmt_conversion_table[i].v4l2_fmt;
-ret = device_init(ctx, width, height, *desired_format);
+ret = device_init(ctx, width, height, pitch, *desired_format);
if (ret >= 0)
break;
else if (ret != AVERROR(EINVAL))
@@ -933,11 +935,13 @@ static int v4l2_read_header(AVFormatContext *ctx)
s->width = fmt.fmt.pix.width;
s->height = fmt.fmt.pix.height;
+s->pitch = fmt.fmt.pix.bytesperline;
av_log(ctx, AV_LOG_VERBOSE,
"Setting frame size to %dx%d\n", s->width, s->height);
}
-res = device_try_init(ctx, pix_fmt, &s->width, &s->height,
&desired_format, &codec_id);
+res = device_try_init(ctx, pix_fmt, &s->width, &s->height, &s->pitch,
+ &desired_format, &codec_id);
if (res < 0)
goto fail;
@@ -948,6 +952,24 @@ static int v4l2_read_header(AVFormatContext *ctx)
if (codec_id != AV_CODEC_ID_NONE && ctx->video_codec_id ==
AV_CODEC_ID_NONE)
ctx->video_codec_id = codec_id;
+/* If bytesperpixel is set by driver then set width co cover full
+ * buffer area even if there are garbage data to be displayed.
+ * It is better to display padding bytes and give application ability
+ * to crop image later than fail to display image stream completely */
+if (s->pitch) {
+int linesize;
+
+pix_fmt = ff_fmt_v4l2ff(desired_format, codec_id);
+linesize = av_image_get_linesize(pix_fmt, s->width, 0);
+if (linesize > 0) {
+s->width = s->pitch * s->width / linesize;
+
+av_log(ctx, AV_LOG_INFO,
+ "Expand frame width to %dx%d to cover full buffer\n",
+ s->width, s->height);
+}
+}
+
if ((res = av_image_check_size(s->width, s->height, 0, ctx)) < 0)
goto fail;
--
2.37.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] lavd/v4l2: add HEVC streams support
Signed-off-by: Dima Buzdyk
---
libavcodec/hevc_parser.c | 4
libavdevice/v4l2-common.c | 3 +++
libavdevice/v4l2.c| 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 59f9a0ff3e..8f99a277a1 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -330,6 +330,10 @@ static int hevc_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
if (!is_dummy_buf)
parse_nal_units(s, buf, buf_size, avctx);
+if (s->flags & PARSER_FLAG_ONCE) {
+s->flags &= PARSER_FLAG_COMPLETE_FRAMES;
+}
+
*poutbuf = buf;
*poutbuf_size = buf_size;
return next;
diff --git a/libavdevice/v4l2-common.c b/libavdevice/v4l2-common.c
index b5b4448a31..353e83efdd 100644
--- a/libavdevice/v4l2-common.c
+++ b/libavdevice/v4l2-common.c
@@ -55,6 +55,9 @@ const struct fmt_map ff_fmt_conversion_table[] = {
#ifdef V4L2_PIX_FMT_H264
{ AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264},
#endif
+#ifdef V4L2_PIX_FMT_HEVC
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_HEVC, V4L2_PIX_FMT_HEVC},
+#endif
#ifdef V4L2_PIX_FMT_MPEG4
{ AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG4,V4L2_PIX_FMT_MPEG4 },
#endif
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 5e85d1a2b3..5558435827 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -972,7 +972,7 @@ static int v4l2_read_header(AVFormatContext *ctx)
if (codec_id == AV_CODEC_ID_RAWVIDEO)
st->codecpar->codec_tag =
avcodec_pix_fmt_to_codec_tag(st->codecpar->format);
-else if (codec_id == AV_CODEC_ID_H264) {
+else if (codec_id == AV_CODEC_ID_H264 || codec_id == AV_CODEC_ID_HEVC) {
avpriv_stream_set_need_parsing(st, AVSTREAM_PARSE_FULL_ONCE);
}
if (desired_format == V4L2_PIX_FMT_YVU420)
--
2.37.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] motion_est: fixed signed_integer_overflow when computing score
--- libavcodec/motion_est.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c index d17ffe42b4..95978d95dd 100644 --- a/libavcodec/motion_est.c +++ b/libavcodec/motion_est.c @@ -1571,7 +1571,7 @@ void ff_estimate_b_frame_motion(MpegEncContext * s, type= CANDIDATE_MB_TYPE_BACKWARD_I; } -score= ((unsigned)(score*score + 128*256))>>16; +score= ((uint64_t)(score)*(uint64_t)(score) + 128*256)>>16; c->mc_mb_var_sum_temp += score; s->mc_mb_var[mb_y*s->mb_stride + mb_x] = score; //FIXME use SSE } -- 2.38.1.493.g58b659f92b-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
