Re: [FFmpeg-devel] [PATCH] avfilter: add amplify filter
On 4/28/18, Carl Eugen Hoyos wrote:
> 2018-04-28 0:56 GMT+02:00, Paul B Mahol :
>
>> +static int query_formats(AVFilterContext *ctx)
>> +{
>> +static const enum AVPixelFormat pixel_fmts[] = {
>> +AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9,
>> +AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12,
>> +AV_PIX_FMT_GRAY16,
>> +AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
>> +AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
>> +AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV444P,
>> +AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P,
>> +AV_PIX_FMT_YUVJ440P, AV_PIX_FMT_YUVJ444P,
>> +AV_PIX_FMT_YUVJ411P,
>> +AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
>> +AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
>> +AV_PIX_FMT_YUV440P10,
>> +AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
>> +AV_PIX_FMT_YUV440P12,
>> +AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14,
>> +AV_PIX_FMT_YUV420P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV444P16,
>> +AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10,
>> +AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,
>
> Just curious:
> Why is this necessary / why did the original code not work?
Added planes parameter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cbs_h2645: create a reference to the existing buffer when decomposing slice units
On Fri, 2018-04-27 at 20:50 -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/cbs_h2645.c | 18 -- > 1 file changed, 4 insertions(+), 14 deletions(-) > > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c > index 5585831cf6..5e5598f377 100644 > --- a/libavcodec/cbs_h2645.c > +++ b/libavcodec/cbs_h2645.c > @@ -776,15 +776,10 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext > *ctx, > } > > slice->data_size = len - pos / 8; > -slice->data_ref = av_buffer_alloc(slice->data_size + > - AV_INPUT_BUFFER_PADDING_SIZE); > +slice->data_ref = av_buffer_ref(unit->data_ref); According the comment for CodedBitstreamUnit::data_ref, unit->data_ref might be NULL, how about adding 'av_assert0(unit->data_ref)' before the above line? > if (!slice->data_ref) > return AVERROR(ENOMEM); > -slice->data = slice->data_ref->data; > -memcpy(slice->data, > - unit->data + pos / 8, slice->data_size); > -memset(slice->data + slice->data_size, 0, > - AV_INPUT_BUFFER_PADDING_SIZE); > +slice->data = unit->data + pos / 8; > slice->data_bit_start = pos % 8; > } > break; > @@ -946,15 +941,10 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext > *ctx, > } > > slice->data_size = len - pos / 8; > -slice->data_ref = av_buffer_alloc(slice->data_size + > - AV_INPUT_BUFFER_PADDING_SIZE); > +slice->data_ref = av_buffer_ref(unit->data_ref); Same comment as above. > if (!slice->data_ref) > return AVERROR(ENOMEM); > -slice->data = slice->data_ref->data; > -memcpy(slice->data, > - unit->data + pos / 8, slice->data_size); > -memset(slice->data + slice->data_size, 0, > - AV_INPUT_BUFFER_PADDING_SIZE); > +slice->data = unit->data + pos / 8; > slice->data_bit_start = pos % 8; > } > break; ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_mpeg2: create a reference to the existing buffer when decomposing slice units
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_mpeg2.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
> index 989daf0a4d..8ca47061fe 100644
> --- a/libavcodec/cbs_mpeg2.c
> +++ b/libavcodec/cbs_mpeg2.c
> @@ -191,16 +191,11 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext
> *ctx,
> len = unit->data_size;
>
> slice->data_size = len - pos / 8;
> -slice->data_ref = av_buffer_alloc(slice->data_size +
> - AV_INPUT_BUFFER_PADDING_SIZE);
> +slice->data_ref = av_buffer_ref(unit->data_ref);
How about adding an assertion to check unit->data_ref against NULL?
> if (!slice->data_ref)
> return AVERROR(ENOMEM);
> -slice->data = slice->data_ref->data;
> +slice->data = unit->data + pos / 8;
>
> -memcpy(slice->data,
> - unit->data + pos / 8, slice->data_size);
> -memset(slice->data + slice->data_size, 0,
> - AV_INPUT_BUFFER_PADDING_SIZE);
> slice->data_bit_start = pos % 8;
>
> } else {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation
> This patch is not correct. > > this code is not used if AV_CODEC_FLAG_BITEXACT is set, because it is > not bit exact ... > > Also the case where the off by 1 error occurs is a rare corner case, > Compared to the errors introduced by the IDCT this is not significant > > If you want to optimize the bit exact version, feel free to do so. > It may be faster to use xor -1 before and after avg for this though Thank you for the review. VC-1 spec is defined bit exact, including the inverse transform. This code is used by the VC-1 decoder and as I was under the impression that the VC-1 decoder ought to be bit exact without any additional command line options, I tried to resolve the issue. As this code is guarded by AV_CODEC_FLAG_BITEXACT, i agree that the proposed solution is not appropriate. The underlying question remains though. Should the VC-1 decoder fully conform to spec or do we allow small deviations? In addition, the VC-1 fate tests put the -bitexact option after the input file (-i). I could only get the bitexeact working if it was put before the input file. Thus, I think the current vc-1 fate-tests do not use the bit exact version. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation
On Sat, Apr 28, 2018 at 10:44:54AM +0200, Jerome Borsboom wrote: > > This patch is not correct. > > > > this code is not used if AV_CODEC_FLAG_BITEXACT is set, because it is > > not bit exact ... > > > > Also the case where the off by 1 error occurs is a rare corner case, > > Compared to the errors introduced by the IDCT this is not significant > > > > If you want to optimize the bit exact version, feel free to do so. > > It may be faster to use xor -1 before and after avg for this though > > Thank you for the review. VC-1 spec is defined bit exact, including the > inverse transform. This code is used by the VC-1 decoder and as I was under > the impression that the VC-1 decoder ought to be bit exact without any > additional > command line options, I tried to resolve the issue. yes, thats a bug, this should not be used if the whole decoder is bitexactly defined > > As this code is guarded by AV_CODEC_FLAG_BITEXACT, i agree that the > proposed solution is not appropriate. The underlying question remains though. > Should > the VC-1 decoder fully conform to spec or do we allow small deviations? i think it should fully conform, this needs to be fixed can you fix it so the decoder uses only bitexact functions ? (i guess this should be easy by passing the appropriate flag to the init code, but didnt look if the API passes it as seperate argument of passes a context, with a context it may be cleanest to change the internal API ...) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation
On Sat, Apr 28, 2018 at 10:44 AM, Jerome Borsboom wrote: >> This patch is not correct. >> >> this code is not used if AV_CODEC_FLAG_BITEXACT is set, because it is >> not bit exact ... >> >> Also the case where the off by 1 error occurs is a rare corner case, >> Compared to the errors introduced by the IDCT this is not significant >> >> If you want to optimize the bit exact version, feel free to do so. >> It may be faster to use xor -1 before and after avg for this though > > Thank you for the review. VC-1 spec is defined bit exact, including the > inverse transform. This code is used by the VC-1 decoder and as I was under > the impression that the VC-1 decoder ought to be bit exact without any > additional > command line options, I tried to resolve the issue. > > As this code is guarded by AV_CODEC_FLAG_BITEXACT, i agree that the > proposed solution is not appropriate. The underlying question remains though. > Should > the VC-1 decoder fully conform to spec or do we allow small deviations? If the spec is bitexact, then our decoder should be by default as well. Perhaps such things should be flipped around and use bitexact by default unless the "fast" flag is specified. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_overlay: add slice threading
Signed-off-by: Paul B Mahol
---
libavfilter/vf_overlay.c | 281 ---
1 file changed, 190 insertions(+), 91 deletions(-)
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index c6a6ac82f3..cb304e9522 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -40,6 +40,10 @@
#include "framesync.h"
#include "video.h"
+typedef struct ThreadData {
+AVFrame *dst, *src;
+} ThreadData;
+
static const char *const var_names[] = {
"main_w","W", ///< width of the mainvideo
"main_h","H", ///< height of the mainvideo
@@ -124,7 +128,7 @@ typedef struct OverlayContext {
AVExpr *x_pexpr, *y_pexpr;
-void (*blend_image)(AVFilterContext *ctx, AVFrame *dst, const AVFrame
*src, int x, int y);
+int (*blend_slice)(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs);
} OverlayContext;
static av_cold void uninit(AVFilterContext *ctx)
@@ -403,10 +407,10 @@ static int config_output(AVFilterLink *outlink)
* Blend image in src to destination buffer dst at position (x, y).
*/
-static av_always_inline void blend_image_packed_rgb(AVFilterContext *ctx,
+static av_always_inline void blend_slice_packed_rgb(AVFilterContext *ctx,
AVFrame *dst, const AVFrame *src,
int main_has_alpha, int x, int y,
- int is_straight)
+ int is_straight, int jobnr, int nb_jobs)
{
OverlayContext *s = ctx->priv;
int i, imax, j, jmax;
@@ -425,13 +429,19 @@ static av_always_inline void
blend_image_packed_rgb(AVFilterContext *ctx,
const int sb = s->overlay_rgba_map[B];
const int sa = s->overlay_rgba_map[A];
const int sstep = s->overlay_pix_step[0];
+int slice_start, slice_end;
uint8_t *S, *sp, *d, *dp;
i = FFMAX(-y, 0);
-sp = src->data[0] + i * src->linesize[0];
-dp = dst->data[0] + (y+i) * dst->linesize[0];
+imax = FFMIN(-y + dst_h, src_h);
+
+slice_start = (imax * jobnr) / nb_jobs;
+slice_end = (imax * (jobnr+1)) / nb_jobs;
+
+sp = src->data[0] + (i + slice_start) * src->linesize[0];
+dp = dst->data[0] + (y + i + slice_start) * dst->linesize[0];
-for (imax = FFMIN(-y + dst_h, src_h); i < imax; i++) {
+for (i = i + slice_start; i < slice_end; i++) {
j = FFMAX(-x, 0);
S = sp + j * sstep;
d = dp + (x+j) * dstep;
@@ -495,7 +505,9 @@ static av_always_inline void blend_plane(AVFilterContext
*ctx,
int dst_offset,
int dst_step,
int straight,
- int yuv)
+ int yuv,
+ int jobnr,
+ int nb_jobs)
{
int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
@@ -505,16 +517,22 @@ static av_always_inline void blend_plane(AVFilterContext
*ctx,
int xp = x>>hsub;
uint8_t *s, *sp, *d, *dp, *dap, *a, *da, *ap;
int jmax, j, k, kmax;
+int slice_start, slice_end;
j = FFMAX(-yp, 0);
-sp = src->data[i] + j * src->linesize[i];
+jmax = FFMIN(-yp + dst_hp, src_hp);
+
+slice_start = (jmax * jobnr) / nb_jobs;
+slice_end = ((jmax * (jobnr+1)) / nb_jobs);
+
+sp = src->data[i] + slice_start * src->linesize[i];
dp = dst->data[dst_plane]
- + (yp+j)* dst->linesize[dst_plane]
+ + (yp + slice_start) * dst->linesize[dst_plane]
+ dst_offset;
-ap = src->data[3] + (jdata[3] + ((yp+j) << vsub) * dst->linesize[3];
+ap = src->data[3] + (slice_start << vsub) * src->linesize[3];
+dap = dst->data[3] + ((yp + slice_start) << vsub) * dst->linesize[3];
-for (jmax = FFMIN(-yp + dst_hp, src_hp); j < jmax; j++) {
+for (j = j + slice_start; j < slice_end; j++) {
k = FFMAX(-xp, 0);
d = dp + (xp+k) * dst_step;
s = sp + k;
@@ -577,17 +595,23 @@ static av_always_inline void blend_plane(AVFilterContext
*ctx,
static inline void alpha_composite(const AVFrame *src, const AVFrame *dst,
int src_w, int src_h,
int dst_w, int dst_h,
- int x, int y)
+ int x, int y,
+ int jobnr, int nb_jobs)
{
uint8_t alpha; ///< the amount of overlay to blend on to main
uint8_t *s, *sa, *d, *da;
int i, imax, j, jmax;
+int slice_start, slice_end;
+
+imax = FFMIN(-y + dst_h, src_h);
+slice_start = (imax * jobnr) / nb_jobs;
+slice_end = ((imax * (jobnr+1)) / nb_jobs);
i = FFMAX(-y, 0);
-sa = src->data[3] + i * s
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation
On 28 April 2018 at 10:42, Hendrik Leppkes wrote: > On Sat, Apr 28, 2018 at 10:44 AM, Jerome Borsboom > wrote: > >> This patch is not correct. > >> > >> this code is not used if AV_CODEC_FLAG_BITEXACT is set, because it is > >> not bit exact ... > >> > >> Also the case where the off by 1 error occurs is a rare corner case, > >> Compared to the errors introduced by the IDCT this is not significant > >> > >> If you want to optimize the bit exact version, feel free to do so. > >> It may be faster to use xor -1 before and after avg for this though > > > > Thank you for the review. VC-1 spec is defined bit exact, including the > > inverse transform. This code is used by the VC-1 decoder and as I was > under > > the impression that the VC-1 decoder ought to be bit exact without any > additional > > command line options, I tried to resolve the issue. > > > > As this code is guarded by AV_CODEC_FLAG_BITEXACT, i agree that the > > proposed solution is not appropriate. The underlying question remains > though. Should > > the VC-1 decoder fully conform to spec or do we allow small deviations? > > If the spec is bitexact, then our decoder should be by default as > well. Perhaps such things should be flipped around and use bitexact by > default unless the "fast" flag is specified. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > I'd say just remove it, it'll bitrot otherwise since no one will use it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation
2018-04-28 13:11 GMT+02:00, Rostislav Pehlivanov : > I'd say just remove it, it'll bitrot otherwise since no one will use it. Not all mpeg decoders are bit-exact and the date of the functions indicate they are used for such decoders. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation
On 28 April 2018 at 12:34, Carl Eugen Hoyos wrote: > 2018-04-28 13:11 GMT+02:00, Rostislav Pehlivanov : > > > I'd say just remove it, it'll bitrot otherwise since no one will use it. > > Not all mpeg decoders are bit-exact and the date of the functions > indicate they are used for such decoders. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Not all mpeg codecs are specified as being bitexact, so they'd be okay. This isn't. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper
On Sat, 28 Apr 2018 11:08:01 +0800 Steven Liu wrote: > > On 28 Apr 2018, at 03:37, wm4 wrote: > > > > + > > +if (strncmp(pd->name, "xyz", 3) == 0) > > +continue; > > liuqideMacBook-Pro:xxx liuqi$ ../tools/patcheck > ~/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch > patCHeck 1e10.0 > This tool is intended to help a human check/review patches. It is very far > from > being free of false positives and negatives, and its output are just hints of > what > may or may not be bad. When you use it and it misses something or detects > something wrong, fix it and send a patch to the ffmpeg-devel mailing list. > License: GPL, Author: Michael Niedermayer > egrep: empty (sub)expression > > These functions may need av_cold, please review the whole patch for similar > functions needing av_cold > /Users/liuqi/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch:147:+static > int is_native_endian(enum AVPixelFormat pixfmt) av_cold seems dumb but I guess I can cargo-cult that. > x==0 / x!=0 can be simplified to !x / x > /Users/liuqi/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch:193:+ > if (strncmp(pd->name, "xyz", 3) == 0) > /Users/liuqi/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch:204:+ > c->offset != 0 || c->shift != 0 || I prefer to keep those explicit, especially the strncmp one. But I don't have that strong feelings about it, so if someone minds I can still change it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper
On Fri, 27 Apr 2018 22:27:47 -0300 James Almer wrote: > On 4/27/2018 4:37 PM, wm4 wrote: > > From: wm4 > > > > require_pkg_config libvapoursynth "vapoursynth-script >= 42" VSScript.h > > vsscript_init || die "ERROR: vapoursynth or vsscript not found"; > > die() is needed only with test_pkg_config and check_pkg_config, not > require_pkg_config. OK, will remove. > And seeing that vapoursynth-script.pc depends on vapoursynth.pc, you can > simplify all this by only checking for vapoursynth-script. I'm not sure if I should rely on this. But considering VSScript.h includes VapourSynth.h anyway, and we don't use any VapourSynth functions directly, the risk is low, so I'll remove it. > > +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO; > > +st->codecpar->codec_id = AV_CODEC_ID_WRAPPED_AVFRAME; > > What exactly is the use case for this? You mean using wrapped avframe? It means you don't have to mess with raw encoding/decoding. Unless we have some fancy way to make rawdec.c accept frames packed by av_image_copy_to_buffer() without having to map pixfmts to raw codecs? (rawdec.c is a lot of code, I might have missed a simple way to make it accept that.) > > +pkt->buf = av_buffer_create((uint8_t*)frame, sizeof(*frame), > > So, the whole wrapped avframe is pretty much fucked up since conception. > Did nobody notice that lavc/wrapped_avframe.c is using sizeof(AVFrame)? > > Much like in here, it's wrong and Bad Things(tm) will happen as soon as > we add a new field. Ah, that is true. In theory it's in conflict with out policy that libavutil can append fields to AVFrame, without rebuilding libavcodec. I've copied this AVFrame packing code from kmsgrab.c though (which is also new code, and which I've noticed leaks memory when handling malloc failure). I think it'd be best if we had updated "non-dumb" side data which can manage AVFrames in a correct way. But it'll be a long way until this happens, apparently. If you really want to solve this, we could introduce an av_frame_get_struct_size() call, which would be dumb, but correct. (Or maybe make it avpriv_?) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cbs_h2645: create a reference to the existing buffer when decomposing slice units
On 4/28/2018 5:02 AM, Xiang, Haihao wrote: > On Fri, 2018-04-27 at 20:50 -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavcodec/cbs_h2645.c | 18 -- >> 1 file changed, 4 insertions(+), 14 deletions(-) >> >> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c >> index 5585831cf6..5e5598f377 100644 >> --- a/libavcodec/cbs_h2645.c >> +++ b/libavcodec/cbs_h2645.c >> @@ -776,15 +776,10 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext >> *ctx, >> } >> >> slice->data_size = len - pos / 8; >> -slice->data_ref = av_buffer_alloc(slice->data_size + >> - >> AV_INPUT_BUFFER_PADDING_SIZE); >> +slice->data_ref = av_buffer_ref(unit->data_ref); > > According the comment for CodedBitstreamUnit::data_ref, unit->data_ref might > be > NULL, how about adding 'av_assert0(unit->data_ref)' before the above line? Judging by Mark's cbs_jpeg patch, which i notice now is doing the same thing (so my patches here were probably in his local queue in some for anyway), i guess it's safe to assume unit->data_ref will never be null. All the functions allocating a unit so far (ff_cbs_insert_unit_data, ff_cbs_alloc_unit_data) seem to make sure it's reference counted. I'll wait for Mark to comment in any case. > > >> if (!slice->data_ref) >> return AVERROR(ENOMEM); >> -slice->data = slice->data_ref->data; >> -memcpy(slice->data, >> - unit->data + pos / 8, slice->data_size); >> -memset(slice->data + slice->data_size, 0, >> - AV_INPUT_BUFFER_PADDING_SIZE); >> +slice->data = unit->data + pos / 8; >> slice->data_bit_start = pos % 8; >> } >> break; >> @@ -946,15 +941,10 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext >> *ctx, >> } >> >> slice->data_size = len - pos / 8; >> -slice->data_ref = av_buffer_alloc(slice->data_size + >> - >> AV_INPUT_BUFFER_PADDING_SIZE); >> +slice->data_ref = av_buffer_ref(unit->data_ref); > > Same comment as above. > >> if (!slice->data_ref) >> return AVERROR(ENOMEM); >> -slice->data = slice->data_ref->data; >> -memcpy(slice->data, >> - unit->data + pos / 8, slice->data_size); >> -memset(slice->data + slice->data_size, 0, >> - AV_INPUT_BUFFER_PADDING_SIZE); >> +slice->data = unit->data + pos / 8; >> slice->data_bit_start = pos % 8; >> } >> break; > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper
On 4/28/2018 8:51 AM, wm4 wrote: > On Sat, 28 Apr 2018 11:08:01 +0800 > Steven Liu wrote: > >>> On 28 Apr 2018, at 03:37, wm4 wrote: >>> > >>> + >>> +if (strncmp(pd->name, "xyz", 3) == 0) >>> +continue; >> >> liuqideMacBook-Pro:xxx liuqi$ ../tools/patcheck >> ~/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch >> patCHeck 1e10.0 >> This tool is intended to help a human check/review patches. It is very far >> from >> being free of false positives and negatives, and its output are just hints >> of what >> may or may not be bad. When you use it and it misses something or detects >> something wrong, fix it and send a patch to the ffmpeg-devel mailing list. >> License: GPL, Author: Michael Niedermayer >> egrep: empty (sub)expression >> >> These functions may need av_cold, please review the whole patch for similar >> functions needing av_cold >> /Users/liuqi/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch:147:+static >> int is_native_endian(enum AVPixelFormat pixfmt) > > av_cold seems dumb but I guess I can cargo-cult that. Unless av_cold is needed/expected for AVInputFormat->read_header like it's done for AVCodec->init, none of these functions need it at all. Especially since they will be inlined by the compiler anyway. At most, make the small ones like is_native_endian explicitly inline. > >> x==0 / x!=0 can be simplified to !x / x >> /Users/liuqi/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch:193:+ >> if (strncmp(pd->name, "xyz", 3) == 0) >> /Users/liuqi/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch:204:+ >> c->offset != 0 || c->shift != 0 || > > I prefer to keep those explicit, especially the strncmp one. But I > don't have that strong feelings about it, so if someone minds I can > still change it. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] add CUgraphicsRegisterFlags enum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 26 Apr 2018 17:09:14 +0200
Daniel Oberhoff wrote:
> > On 26. Apr 2018, at 16:20, Daniel Oberhoff
> > wrote:
> >
> > ---
> > include/ffnvcodec/dynlink_cuda.h | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/ffnvcodec/dynlink_cuda.h
> > b/include/ffnvcodec/dynlink_cuda.h index 2cc50bb..df1d316 100644
> > --- a/include/ffnvcodec/dynlink_cuda.h
> > +++ b/include/ffnvcodec/dynlink_cuda.h
> > @@ -68,6 +68,14 @@ typedef enum CUlimit_enum {
> > CU_LIMIT_DEV_RUNTIME_PENDING_LAUNCH_COUNT = 4
> > } CUlimit;
> >
> > +typedef enum CUgraphicsRegisterFlags_enum {
> > +CU_GRAPHICS_REGISTER_FLAGS_NONE = 0x00,
> > +CU_GRAPHICS_REGISTER_FLAGS_READ_ONLY = 0x01,
> > +CU_GRAPHICS_REGISTER_FLAGS_WRITE_DISCARD = 0x02,
> > +CU_GRAPHICS_REGISTER_FLAGS_SURFACE_LDST = 0x04,
> > +CU_GRAPHICS_REGISTER_FLAGS_TEXTURE_GATHER = 0x08
> > +} CUgraphicsRegisterFlags;
> > +
> > typedef struct CUDA_MEMCPY2D_st {
> > size_t srcXInBytes;
> > size_t srcY;
> > --
> > 2.14.3 (Apple Git-98)
> >
>
>
> also need this
>
> ---
> include/ffnvcodec/dynlink_cuda.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/ffnvcodec/dynlink_cuda.h
> b/include/ffnvcodec/dynlink_cuda.h index df1d316..24c37a7 100644
> --- a/include/ffnvcodec/dynlink_cuda.h
> +++ b/include/ffnvcodec/dynlink_cuda.h
> @@ -107,8 +107,6 @@ typedef enum CUGLDeviceList_enum {
> CU_GL_DEVICE_LIST_NEXT_FRAME = 3,
> } CUGLDeviceList;
>
> -#define CU_GRAPHICS_REGISTER_FLAGS_WRITE_DISCARD 2
> -
> typedef CUresult CUDAAPI tcuInit(unsigned int Flags);
> typedef CUresult CUDAAPI tcuDeviceGetCount(int *count);
> typedef CUresult CUDAAPI tcuDeviceGet(CUdevice *device, int ordinal);
> --
> 2.14.3 (Apple Git-98)
>
Looks fine.
- --phil
- --phil
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAlrkjSkACgkQ+NaxlGp1aC5WtACZAQE/z07C8zfwWK7o/MFkeWKi
FDsAoI9eMc8zTEicsdszh6zqraJh59Yx
=dBxi
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper
On Sat, 28 Apr 2018 11:58:27 -0300 James Almer wrote: > On 4/28/2018 8:51 AM, wm4 wrote: > > On Sat, 28 Apr 2018 11:08:01 +0800 > > Steven Liu wrote: > > > >>> On 28 Apr 2018, at 03:37, wm4 wrote: > >>> > > > >>> + > >>> +if (strncmp(pd->name, "xyz", 3) == 0) > >>> +continue; > >> > >> liuqideMacBook-Pro:xxx liuqi$ ../tools/patcheck > >> ~/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch > >> patCHeck 1e10.0 > >> This tool is intended to help a human check/review patches. It is very far > >> from > >> being free of false positives and negatives, and its output are just hints > >> of what > >> may or may not be bad. When you use it and it misses something or detects > >> something wrong, fix it and send a patch to the ffmpeg-devel mailing list. > >> License: GPL, Author: Michael Niedermayer > >> egrep: empty (sub)expression > >> > >> These functions may need av_cold, please review the whole patch for > >> similar functions needing av_cold > >> /Users/liuqi/Downloads/FFmpeg-devel-avformat-add-vapoursynth-wrapper.patch:147:+static > >> int is_native_endian(enum AVPixelFormat pixfmt) > > > > av_cold seems dumb but I guess I can cargo-cult that. > > Unless av_cold is needed/expected for AVInputFormat->read_header like > it's done for AVCodec->init, none of these functions need it at all. > Especially since they will be inlined by the compiler anyway. Only a small number of functions/formats in libavformat use av_cold. But it doesn't harm either. > At most, make the small ones like is_native_endian explicitly inline. Doesn't seem needed either. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/vc1: fix mquant calculation
In vc1_decode_i_blocks_adv mquant needs to be reset to its default value for
each macroblock, instead of once at the beginning of the slice.
DQPROFILE specifies which macroblocks can have an alternative quantizer step
size. When DQPROFILE specifies edges, the selection is applicable to the edges
of the picture. Slice edges are not selected by DQPROFILE.
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1_block.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index 0caa5ebb85..f59c440943 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -177,7 +177,7 @@ static void vc1_put_signed_blocks_clamped(VC1Context *v)
edges = 15;\
if ((edges&1) && !s->mb_x) \
mquant = -v->altpq;\
-if ((edges&2) && s->first_slice_line) \
+if ((edges&2) && !s->mb_y) \
mquant = -v->altpq;\
if ((edges&4) && s->mb_x == (s->mb_width - 1)) \
mquant = -v->altpq;\
@@ -2626,7 +2626,7 @@ static void vc1_decode_i_blocks_adv(VC1Context *v)
int cbp, val;
uint8_t *coded_val;
int mb_pos;
-int mquant = v->pq;
+int mquant;
int mqdiff;
GetBitContext *gb = &s->gb;
@@ -2671,6 +2671,7 @@ static void vc1_decode_i_blocks_adv(VC1Context *v)
init_block_index(v);
for (;s->mb_x < s->mb_width; s->mb_x++) {
int16_t (*block)[64] = v->block[v->cur_blk_idx];
+mquant = v->pq;
ff_update_block_index(s);
s->bdsp.clear_blocks(block[0]);
mb_pos = s->mb_x + s->mb_y * s->mb_stride;
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: change fps progress log message to show two decimal digits
On Fri, Apr 27, 2018 at 08:00:33PM -0300, André Camargo wrote: > Useful when transcoding videos at 29.97 fps because delivers a more accurate > result for monitoring. > --- > fftools/ffmpeg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: Add system time and real time to benchmarking.
On Fri, Apr 27, 2018 at 01:31:59PM -0400, Mark Wachsler wrote: > The -benchmark and -benchmark_all options now show user, system, and real > time, > instead of just user time. > --- > fftools/ffmpeg.c | 49 +++- > 1 file changed, 36 insertions(+), 13 deletions(-) ok, will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/arm: avoid conditional branch to PLT in THUMB-2.
On Fri, Apr 27, 2018 at 02:06:04PM -0700, Rahul Chaudhry wrote: > It was reported on github that this patch causes build errors with xcode: > > https://github.com/FFmpeg/FFmpeg/commit/b22db4f465c9adb2cf1489e04f7b65ef6bb55b8b#commitcomment-28725295 > > The attached patch fixes the build errors by renaming the labels. This time > I've tested it with clang from xcode on a MacBook to verify that the build > works. > > Thanks, > Rahul > > > On Thu, Apr 19, 2018 at 11:06 AM, Michael Niedermayer > wrote: > > On Wed, Apr 18, 2018 at 04:40:28PM -0700, Rahul Chaudhry wrote: > >> On Wed, Apr 18, 2018 at 3:46 PM, Michael Niedermayer > >> wrote: > >> > please make sure this works on apple based arm (unless you know it works) > >> > (ive tested qemu linux based) > >> > > >> > Also please add a commit message > >> > >> If by 'apple based arm' you mean llvm/clang assembler, then yes, I've > >> verified > >> that the assembly works with armv7a-cros-linux-gnueabi-clang (version > >> 7.0.0). > >> > >> Updated patch with new commit message is attached. > >> > >> Thanks, > >> Rahul > > > >> From 2e3318acf266b519e98b680102a07196d6ddbf93 Mon Sep 17 00:00:00 2001 > >> From: Rahul Chaudhry > >> Date: Wed, 18 Apr 2018 16:29:39 -0700 > >> Subject: [PATCH] swresample/arm: remove unintentional relocation. > > > > ok, will apply > > > > thx > From a58b726947cc22081d899894036fa01933dfac0a Mon Sep 17 00:00:00 2001 > From: Rahul Chaudhry > Date: Fri, 27 Apr 2018 13:49:52 -0700 > Subject: [PATCH] swresample/arm: rename labels to fix xcode build error will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper
This can "demux" .vpy files.
Some minor code copied from other LGPL parts of FFmpeg.
I did not found a good way to test a few of the more obscure features,
like VFR nodes, compat pixel formats, or nodes with dynamic size/format
changes. These can be easily implemented on demand.
---
configure | 5 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/vapoursynth.c | 421 ++
4 files changed, 428 insertions(+)
create mode 100644 libavformat/vapoursynth.c
diff --git a/configure b/configure
index 9fa1665496..fcc93ecc30 100755
--- a/configure
+++ b/configure
@@ -303,6 +303,7 @@ External library support:
--disable-sdl2 disable sdl2 [autodetect]
--disable-securetransport disable Secure Transport, needed for TLS support
on OSX if openssl and gnutls are not used
[autodetect]
+ --enable-vapoursynth enable VapourSynth demuxer [no]
--disable-xlib disable xlib [autodetect]
--disable-zlib disable zlib [autodetect]
@@ -1724,6 +1725,7 @@ EXTERNAL_LIBRARY_LIST="
mediacodec
openal
opengl
+vapoursynth
"
HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3088,6 +3090,7 @@ libx265_encoder_deps="libx265"
libxavs_encoder_deps="libxavs"
libxvid_encoder_deps="libxvid"
libzvbi_teletext_decoder_deps="libzvbi"
+vapoursynth_demuxer_deps="vapoursynth"
videotoolbox_suggest="coreservices"
videotoolbox_deps="corefoundation coremedia corevideo"
videotoolbox_encoder_deps="videotoolbox
VTCompressionSessionPrepareToEncodeFrames"
@@ -6130,6 +6133,8 @@ enabled rkmpp && { require_pkg_config rkmpp
rockchip_mpp rockchip/r
{ enabled libdrm ||
die "ERROR: rkmpp requires --enable-libdrm"; }
}
+enabled vapoursynth && require_pkg_config vapoursynth
"vapoursynth-script >= 42" VSScript.h vsscript_init
+
if enabled gcrypt; then
GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3eeca5091d..e1e74a8f43 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -570,6 +570,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o
OBJS-$(CONFIG_LIBSRT_PROTOCOL) += libsrt.o
OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o
OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
+OBJS-$(CONFIG_VAPOURSYNTH_DEMUXER) += vapoursynth.o
# protocols I/O
OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d582778b3b..a94364f41d 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -482,6 +482,7 @@ extern AVOutputFormat ff_chromaprint_muxer;
extern AVInputFormat ff_libgme_demuxer;
extern AVInputFormat ff_libmodplug_demuxer;
extern AVInputFormat ff_libopenmpt_demuxer;
+extern AVInputFormat ff_vapoursynth_demuxer;
#include "libavformat/muxer_list.c"
#include "libavformat/demuxer_list.c"
diff --git a/libavformat/vapoursynth.c b/libavformat/vapoursynth.c
new file mode 100644
index 00..6758a7bf31
--- /dev/null
+++ b/libavformat/vapoursynth.c
@@ -0,0 +1,421 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+* @file
+* VapourSynth demuxer
+*
+* Synthesizes vapour (?)
+*/
+
+#include
+
+#include
+#include
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct VSContext {
+const AVClass *class;
+
+const VSAPI *vsapi;
+VSCore *vscore;
+VSScript *vss;
+int did_init;
+
+VSNodeRef *outnode;
+int is_cfr;
+int current_frame;
+
+int c_order[4];
+
+/* options */
+int64_t max_size;
+} VSContext;
+
+#define OFFSET(x) offsetof(VSContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM
+#define D AV_OPT_FLAG_DECODING_PARAM
+static const AVOption options[] = {
+{"max_size","set max file size supported (in bytes)",
OFFSET(max_size),AV_OPT_TYPE_INT64, {.i64 = 1 * 1024 * 1024}, 0,
SIZE_MAX - 1, A|D},
+{NULL
[FFmpeg-devel] [PATCH] avformat/matroskaenc: do not write timebase as framerate
If the API user doesn't set avg_frame_rate, matroskaenc will write the current timebase as "default duration" for the video track. This makes no sense, because the "default duration" implies the framerate of the video. Since the timebase is forced to 1/1000, this will make the resulting file claim 1000fps. Drop it and don't write the element. It's optional, so it's better not to write it if the framerate is unknown. Strangely does not require FATE changes. --- libavformat/matroskaenc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 5950b4de44..b7ff1950d3 100644 --- a/libavformat/matroskaenc.c +++ b/libavformat/matroskaenc.c @@ -1304,8 +1304,6 @@ static int mkv_write_track(AVFormatContext *s, MatroskaMuxContext *mkv, if( st->avg_frame_rate.num > 0 && st->avg_frame_rate.den > 0 && av_cmp_q(av_inv_q(st->avg_frame_rate), st->time_base) > 0) put_ebml_uint(pb, MATROSKA_ID_TRACKDEFAULTDURATION, 10LL * st->avg_frame_rate.den / st->avg_frame_rate.num); -else -put_ebml_uint(pb, MATROSKA_ID_TRACKDEFAULTDURATION, 10LL * st->time_base.num / st->time_base.den); if (!native_id && ff_codec_get_tag(ff_codec_movvideo_tags, par->codec_id) && -- 2.16.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: do not write timebase as framerate
2018-04-28 19:24 GMT+02:00, wm4 : > If the API user doesn't set avg_frame_rate, matroskaenc will write the > current timebase as "default duration" for the video track. This makes > no sense, because the "default duration" implies the framerate of the > video. Since the timebase is forced to 1/1000, this will make the > resulting file claim 1000fps. > > Drop it and don't write the element. It's optional, so it's better not > to write it if the framerate is unknown. (Isn't it default frame duration?) Please mention ticket #6386 if you commit. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: do not write timebase as framerate
On Sat, 28 Apr 2018 19:52:38 +0200 Carl Eugen Hoyos wrote: > 2018-04-28 19:24 GMT+02:00, wm4 : > > If the API user doesn't set avg_frame_rate, matroskaenc will write the > > current timebase as "default duration" for the video track. This makes > > no sense, because the "default duration" implies the framerate of the > > video. Since the timebase is forced to 1/1000, this will make the > > resulting file claim 1000fps. > > > > Drop it and don't write the element. It's optional, so it's better not > > to write it if the framerate is unknown. > > (Isn't it default frame duration?) The Matroska "spec" calls it DefaultDuration. > Please mention ticket #6386 if you commit. So if this was known to you, and you even made a patch, why did you never send the patch to the list? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper
On 4/28/2018 2:05 PM, wm4 wrote:
> This can "demux" .vpy files.
>
> Some minor code copied from other LGPL parts of FFmpeg.
>
> I did not found a good way to test a few of the more obscure features,
> like VFR nodes, compat pixel formats, or nodes with dynamic size/format
> changes. These can be easily implemented on demand.
> ---
> configure | 5 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/vapoursynth.c | 421
> ++
> 4 files changed, 428 insertions(+)
> create mode 100644 libavformat/vapoursynth.c
[...]
> +static int read_packet_vs(AVFormatContext *s, AVPacket *pkt)
> +{
> +VSContext *vs = s->priv_data;
> +AVStream *st = s->streams[0];
> +AVFrame *frame = NULL;
> +char vserr[80];
> +const VSFrameRef *vsframe = NULL;
> +const VSVideoInfo *info = vs->vsapi->getVideoInfo(vs->outnode);
> +int err = 0;
> +const uint8_t *src_data[4];
> +int src_linesizes[4];
> +const VSMap *props;
> +int i;
> +
> +if (vs->current_frame >= info->numFrames)
> +return AVERROR_EOF;
> +
> +vsframe = vs->vsapi->getFrame(vs->current_frame, vs->outnode, vserr,
> sizeof(vserr));
> +if (!vsframe) {
> +av_log(s, AV_LOG_ERROR, "Error getting frame: %s\n", vserr);
> +err = AVERROR_EXTERNAL;
> +goto end;
> +}
> +
> +props = vs->vsapi->getFramePropsRO(vsframe);
> +
> +frame = av_frame_alloc();
> +if (!frame) {
> +err = AVERROR(ENOMEM);
> +goto end;
> +}
> +
> +frame->format = st->codecpar->format;
> +frame->width= st->codecpar->width;
> +frame->height = st->codecpar->height;
> +frame->colorspace = st->codecpar->color_space;
> +
> +// Values according to ISO/IEC 14496-10.
> +frame->colorspace = get_vs_prop_int(s, props, "_Matrix",
> frame->colorspace);
> +frame->color_primaries = get_vs_prop_int(s, props, "_Primaries",
> frame->color_primaries);
> +frame->color_trc= get_vs_prop_int(s, props, "_Transfer",
> frame->color_trc);
> +
> +if (get_vs_prop_int(s, props, "_ColorRange", 1) == 0)
> +frame->color_range = AVCOL_RANGE_JPEG;
> +
> +frame->sample_aspect_ratio.num = get_vs_prop_int(s, props, "_SARNum", 0);
> +frame->sample_aspect_ratio.den = get_vs_prop_int(s, props, "_SARDen", 1);
> +
> +av_assert0(vs->vsapi->getFrameWidth(vsframe, 0) == frame->width);
> +av_assert0(vs->vsapi->getFrameHeight(vsframe, 0) == frame->height);
> +
> +err = av_frame_get_buffer(frame, 0);
> +if (err < 0)
> +goto end;
> +
> +for (i = 0; i < info->format->numPlanes; i++) {
> +int p = vs->c_order[i];
> +src_data[i] = vs->vsapi->getReadPtr(vsframe, p);
> +src_linesizes[i] = vs->vsapi->getStride(vsframe, p);
> +}
> +
> +av_image_copy(frame->data, frame->linesize, src_data, src_linesizes,
> + frame->format, frame->width, frame->height);
> +
> +pkt->buf = av_buffer_create((uint8_t*)frame, sizeof(*frame),
> +free_frame, NULL, 0);
> +if (!pkt->buf) {
> +err = AVERROR(ENOMEM);
> +goto end;
> +}
> +
> +frame = NULL; // pkt owns it now
> +
> +pkt->data = pkt->buf->data;
> +pkt->size = pkt->buf->size;
> +pkt->flags |= AV_PKT_FLAG_TRUSTED;
> +
> +if (vs->is_cfr)
> +pkt->pts = vs->current_frame;
> +
> +vs->current_frame++;
> +
> +end:
> +if (err < 0)
> +av_packet_unref(pkt);
Unneeded. Nothing after pkt->buf is initialized can fail right now. And
if av_buffer_create() fails, pkt will be untouched.
> +av_frame_free(&frame);
> +vs->vsapi->freeFrame(vsframe);
> +return err;
Shouldn't you set err to pkt->size right above the end label?
> +}
> +
> +static int read_seek_vs(AVFormatContext *s, int stream_idx, int64_t ts, int
> flags)
> +{
> +VSContext *vs = s->priv_data;
> +
> +if (!vs->is_cfr)
> +return AVERROR(ENOSYS);
> +
> +vs->current_frame = FFMIN(FFMAX(0, ts), s->streams[0]->duration);
> +return 0;
> +}
> +
> +static av_cold int probe_vs(AVProbeData *p)
> +{
> +// Explicitly do not support this. VS scripts are written in Python, and
> +// can run arbitrary code on the user's system.
> +return 0;
> +}
> +
> +static const AVClass class_vs = {
> +.class_name = "VapourSynth demuxer",
> +.item_name = av_default_item_name,
> +.option = options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +AVInputFormat ff_vapoursynth_demuxer = {
> +.name = "vapoursynth",
> +.long_name = NULL_IF_CONFIG_SMALL("VapourSynth demuxer"),
> +.priv_data_size = sizeof(VSContext),
> +.read_probe = probe_vs,
> +.read_header= read_header_vs,
> +.read_packet= read_packet_vs,
> +.read_close = read_close_vs,
> +.read_seek = read_seek_vs,
> +.priv_class
[FFmpeg-devel] [PATCH] avformat/hls: don't propagate deprecated "user-agent" AVOption
This code will print a warning if any user agent is set - even if the
API user used the proper non-deprecated "user_agent" option.
This change should not even break anything, because even if the user
sets the deprecated "user-agent" option, http.c copies it to the
"user_agent" option anyway.
---
libavformat/hls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index ffec124818..4ee4be769d 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1593,7 +1593,7 @@ static int save_avio_options(AVFormatContext *s)
{
HLSContext *c = s->priv_data;
static const char * const opts[] = {
-"headers", "http_proxy", "user_agent", "user-agent", "cookies",
"referer", "rw_timeout", NULL };
+"headers", "http_proxy", "user_agent", "cookies", "referer",
"rw_timeout", NULL };
const char * const * opt = opts;
uint8_t *buf;
int ret = 0;
--
2.16.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper
On Sat, 28 Apr 2018 15:28:13 -0300 James Almer wrote: > On 4/28/2018 2:05 PM, wm4 wrote: > > This can "demux" .vpy files. > > > > +pkt->data = pkt->buf->data; > > +pkt->size = pkt->buf->size; > > +pkt->flags |= AV_PKT_FLAG_TRUSTED; > > + > > +if (vs->is_cfr) > > +pkt->pts = vs->current_frame; > > + > > +vs->current_frame++; > > + > > +end: > > +if (err < 0) > > +av_packet_unref(pkt); > > Unneeded. Nothing after pkt->buf is initialized can fail right now. And > if av_buffer_create() fails, pkt will be untouched. Could be good for robustness reasons, but OK, removed. > > +av_frame_free(&frame); > > +vs->vsapi->freeFrame(vsframe); > > +return err; > > Shouldn't you set err to pkt->size right above the end label? I'm not sure what you mean. err is initialized to 0, and only becomes non-0 on errors, so it doesn't need to be set here. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper
On 4/28/2018 3:38 PM, wm4 wrote: > On Sat, 28 Apr 2018 15:28:13 -0300 > James Almer wrote: > >> On 4/28/2018 2:05 PM, wm4 wrote: >>> This can "demux" .vpy files. >>> > > >>> +pkt->data = pkt->buf->data; >>> +pkt->size = pkt->buf->size; >>> +pkt->flags |= AV_PKT_FLAG_TRUSTED; >>> + >>> +if (vs->is_cfr) >>> +pkt->pts = vs->current_frame; >>> + >>> +vs->current_frame++; >>> + >>> +end: >>> +if (err < 0) >>> +av_packet_unref(pkt); >> >> Unneeded. Nothing after pkt->buf is initialized can fail right now. And >> if av_buffer_create() fails, pkt will be untouched. > > Could be good for robustness reasons, but OK, removed. > >>> +av_frame_free(&frame); >>> +vs->vsapi->freeFrame(vsframe); >>> +return err; >> >> Shouldn't you set err to pkt->size right above the end label? > > I'm not sure what you mean. err is initialized to 0, and only becomes > non-0 on errors, so it doesn't need to be set here. I was under the impression that read_packet() functions were supposed to return the size of the packet read on success, but it seems it's not consistent (some demuxers do, others don't). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: do not write timebase as framerate
2018-04-28 20:05 GMT+02:00, wm4 : > On Sat, 28 Apr 2018 19:52:38 +0200 > Carl Eugen Hoyos wrote: > >> 2018-04-28 19:24 GMT+02:00, wm4 : >> > If the API user doesn't set avg_frame_rate, matroskaenc will write the >> > current timebase as "default duration" for the video track. This makes >> > no sense, because the "default duration" implies the framerate of the >> > video. Since the timebase is forced to 1/1000, this will make the >> > resulting file claim 1000fps. >> > >> > Drop it and don't write the element. It's optional, so it's better not >> > to write it if the framerate is unknown. >> >> (Isn't it default frame duration?) > > The Matroska "spec" calls it DefaultDuration. Which sounds more similar to "default frame duration" than "framerate"... >> Please mention ticket #6386 if you commit. > > So if this was known to you, and you even made a patch, why > did you never send the patch to the list? I am not convinced the patch is correct and the OP claimed that it did not fix the reported issue completely. (And this was of course not known "to me" but to everybody.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: do not write timebase as framerate
On Sat, 28 Apr 2018 21:18:47 +0200 Carl Eugen Hoyos wrote: > 2018-04-28 20:05 GMT+02:00, wm4 : > > On Sat, 28 Apr 2018 19:52:38 +0200 > > Carl Eugen Hoyos wrote: > > > >> 2018-04-28 19:24 GMT+02:00, wm4 : > >> > If the API user doesn't set avg_frame_rate, matroskaenc will write the > >> > current timebase as "default duration" for the video track. This makes > >> > no sense, because the "default duration" implies the framerate of the > >> > video. Since the timebase is forced to 1/1000, this will make the > >> > resulting file claim 1000fps. > >> > > >> > Drop it and don't write the element. It's optional, so it's better not > >> > to write it if the framerate is unknown. > >> > >> (Isn't it default frame duration?) > > > > The Matroska "spec" calls it DefaultDuration. > > Which sounds more similar to "default frame duration" than > "framerate"... It's the same thing, really. Technically the framerate is the inverse of it. > >> Please mention ticket #6386 if you commit. > > > > So if this was known to you, and you even made a patch, why > > did you never send the patch to the list? > > I am not convinced the patch is correct and the OP claimed > that it did not fix the reported issue completely. > > (And this was of course not known "to me" but to everybody.) It definitely does fix the issue that ffmpeg writes files that mkv demuxers, including ffmpeg's, detect as having video framerate of 1000hz. I don't know what that issue is about and I don't care, it's just that you posted a patch there that does exactly the same thing as mine. I'll gladly leave that to you. Will push tomorrow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_fieldmatch: add support for >8 bit depth in ppsrc
Also fix leaks while here.
Signed-off-by: Paul B Mahol
---
libavfilter/vf_fieldmatch.c | 48 +
1 file changed, 44 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_fieldmatch.c b/libavfilter/vf_fieldmatch.c
index 4f10ed7ccd..68335ba678 100644
--- a/libavfilter/vf_fieldmatch.c
+++ b/libavfilter/vf_fieldmatch.c
@@ -79,6 +79,7 @@ typedef struct FieldMatchContext {
AVFrame *prv2, *src2, *nxt2;///< sliding window of the optional second
stream
int got_frame[2]; ///< frame request flag for each input
stream
int hsub, vsub; ///< chroma subsampling values
+int bpc;///< bytes per component
uint32_t eof; ///< bitmask for end of stream
int64_t lastscdiff;
int64_t lastn;
@@ -613,7 +614,7 @@ static void copy_fields(const FieldMatchContext *fm,
AVFrame *dst,
const int nb_copy_fields = (plane_h >> 1) + (field ? 0 : (plane_h &
1));
av_image_copy_plane(dst->data[plane] + field*dst->linesize[plane],
dst->linesize[plane] << 1,
src->data[plane] + field*src->linesize[plane],
src->linesize[plane] << 1,
-get_width(fm, src, plane), nb_copy_fields);
+get_width(fm, src, plane) * fm->bpc,
nb_copy_fields);
}
}
@@ -852,16 +853,48 @@ static int request_frame(AVFilterLink *outlink)
static int query_formats(AVFilterContext *ctx)
{
-// TODO: second input source can support >8bit depth
+FieldMatchContext *fm = ctx->priv;
+
static const enum AVPixelFormat pix_fmts[] = {
AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
AV_PIX_FMT_NONE
};
+static const enum AVPixelFormat unproc_pix_fmts[] = {
+AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P,
+AV_PIX_FMT_YUVJ440P, AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_YUVJ411P,
+AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
+AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV440P10,
+AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
+AV_PIX_FMT_YUV440P12,
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14,
+AV_PIX_FMT_YUV420P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_NONE
+};
+int ret;
+
AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
if (!fmts_list)
return AVERROR(ENOMEM);
-return ff_set_common_formats(ctx, fmts_list);
+if (!fm->ppsrc) {
+return ff_set_common_formats(ctx, fmts_list);
+}
+
+if ((ret = ff_formats_ref(fmts_list,
&ctx->inputs[INPUT_MAIN]->out_formats)) < 0)
+return ret;
+fmts_list = ff_make_format_list(unproc_pix_fmts);
+if (!fmts_list)
+return AVERROR(ENOMEM);
+if ((ret = ff_formats_ref(fmts_list, &ctx->outputs[0]->in_formats)) < 0)
+return ret;
+if ((ret = ff_formats_ref(fmts_list,
&ctx->inputs[INPUT_CLEANSRC]->out_formats)) < 0)
+return ret;
+return 0;
}
static int config_input(AVFilterLink *inlink)
@@ -947,7 +980,12 @@ static av_cold void fieldmatch_uninit(AVFilterContext *ctx)
av_frame_free(&fm->prv);
if (fm->nxt != fm->src)
av_frame_free(&fm->nxt);
+if (fm->prv2 != fm->src2)
+av_frame_free(&fm->prv2);
+if (fm->nxt2 != fm->src2)
+av_frame_free(&fm->nxt2);
av_frame_free(&fm->src);
+av_frame_free(&fm->src2);
av_freep(&fm->map_data[0]);
av_freep(&fm->cmask_data[0]);
av_freep(&fm->tbuffer);
@@ -959,10 +997,12 @@ static av_cold void fieldmatch_uninit(AVFilterContext
*ctx)
static int config_output(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
-const FieldMatchContext *fm = ctx->priv;
+FieldMatchContext *fm = ctx->priv;
const AVFilterLink *inlink =
ctx->inputs[fm->ppsrc ? INPUT_CLEANSRC : INPUT_MAIN];
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+fm->bpc = (desc->comp[0].depth + 7) / 8;
outlink->time_base = inlink->time_base;
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
outlink->frame_rate = inlink->frame_rate;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: add slice threading
On Sat, Apr 28, 2018 at 12:00:46PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_overlay.c | 281
> ---
> 1 file changed, 190 insertions(+), 91 deletions(-)
>
> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> index c6a6ac82f3..cb304e9522 100644
> --- a/libavfilter/vf_overlay.c
> +++ b/libavfilter/vf_overlay.c
> @@ -40,6 +40,10 @@
> #include "framesync.h"
> #include "video.h"
>
> +typedef struct ThreadData {
> +AVFrame *dst, *src;
> +} ThreadData;
> +
> static const char *const var_names[] = {
> "main_w","W", ///< width of the mainvideo
> "main_h","H", ///< height of the mainvideo
> @@ -124,7 +128,7 @@ typedef struct OverlayContext {
>
> AVExpr *x_pexpr, *y_pexpr;
>
> -void (*blend_image)(AVFilterContext *ctx, AVFrame *dst, const AVFrame
> *src, int x, int y);
> +int (*blend_slice)(AVFilterContext *ctx, void *arg, int jobnr, int
> nb_jobs);
> } OverlayContext;
>
> static av_cold void uninit(AVFilterContext *ctx)
> @@ -403,10 +407,10 @@ static int config_output(AVFilterLink *outlink)
> * Blend image in src to destination buffer dst at position (x, y).
> */
>
> -static av_always_inline void blend_image_packed_rgb(AVFilterContext *ctx,
> +static av_always_inline void blend_slice_packed_rgb(AVFilterContext *ctx,
> AVFrame *dst, const AVFrame *src,
> int main_has_alpha, int x, int y,
> - int is_straight)
> + int is_straight, int jobnr, int nb_jobs)
> {
> OverlayContext *s = ctx->priv;
> int i, imax, j, jmax;
> @@ -425,13 +429,19 @@ static av_always_inline void
> blend_image_packed_rgb(AVFilterContext *ctx,
> const int sb = s->overlay_rgba_map[B];
> const int sa = s->overlay_rgba_map[A];
> const int sstep = s->overlay_pix_step[0];
> +int slice_start, slice_end;
> uint8_t *S, *sp, *d, *dp;
>
> i = FFMAX(-y, 0);
> -sp = src->data[0] + i * src->linesize[0];
> -dp = dst->data[0] + (y+i) * dst->linesize[0];
> +imax = FFMIN(-y + dst_h, src_h);
> +
> +slice_start = (imax * jobnr) / nb_jobs;
> +slice_end = (imax * (jobnr+1)) / nb_jobs;
> +
> +sp = src->data[0] + (i + slice_start) * src->linesize[0];
> +dp = dst->data[0] + (y + i + slice_start) * dst->linesize[0];
>
> -for (imax = FFMIN(-y + dst_h, src_h); i < imax; i++) {
> +for (i = i + slice_start; i < slice_end; i++) {
> j = FFMAX(-x, 0);
> S = sp + j * sstep;
> d = dp + (x+j) * dstep;
> @@ -495,7 +505,9 @@ static av_always_inline void blend_plane(AVFilterContext
> *ctx,
> int dst_offset,
> int dst_step,
> int straight,
> - int yuv)
> + int yuv,
> + int jobnr,
> + int nb_jobs)
> {
> int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
> int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
> @@ -505,16 +517,22 @@ static av_always_inline void
> blend_plane(AVFilterContext *ctx,
> int xp = x>>hsub;
> uint8_t *s, *sp, *d, *dp, *dap, *a, *da, *ap;
> int jmax, j, k, kmax;
> +int slice_start, slice_end;
>
> j = FFMAX(-yp, 0);
> -sp = src->data[i] + j * src->linesize[i];
> +jmax = FFMIN(-yp + dst_hp, src_hp);
> +
> +slice_start = (jmax * jobnr) / nb_jobs;
> +slice_end = ((jmax * (jobnr+1)) / nb_jobs);
> +
> +sp = src->data[i] + slice_start * src->linesize[i];
> dp = dst->data[dst_plane]
> - + (yp+j)* dst->linesize[dst_plane]
> + + (yp + slice_start) * dst->linesize[dst_plane]
>+ dst_offset;
> -ap = src->data[3] + (j -dap = dst->data[3] + ((yp+j) << vsub) * dst->linesize[3];
> +ap = src->data[3] + (slice_start << vsub) * src->linesize[3];
> +dap = dst->data[3] + ((yp + slice_start) << vsub) * dst->linesize[3];
>
> -for (jmax = FFMIN(-yp + dst_hp, src_hp); j < jmax; j++) {
> +for (j = j + slice_start; j < slice_end; j++) {
> k = FFMAX(-xp, 0);
> d = dp + (xp+k) * dst_step;
> s = sp + k;
> @@ -577,17 +595,23 @@ static av_always_inline void
> blend_plane(AVFilterContext *ctx,
> static inline void alpha_composite(const AVFrame *src, const AVFrame *dst,
> int src_w, int src_h,
> int dst_w, int dst_h,
> - int x, int y)
> + int x, int y,
> + int jobnr, int nb_jobs)
> {
> uint8_t alpha; ///< the amount of overlay t
Re: [FFmpeg-devel] [PATCH] avcodec/vc1: fix mquant calculation
On Sat, Apr 28, 2018 at 05:15:32PM +0200, Jerome Borsboom wrote: > In vc1_decode_i_blocks_adv mquant needs to be reset to its default value for > each macroblock, instead of once at the beginning of the slice. > > DQPROFILE specifies which macroblocks can have an alternative quantizer step > size. When DQPROFILE specifies edges, the selection is applicable to the edges > of the picture. Slice edges are not selected by DQPROFILE. > > Signed-off-by: Jerome Borsboom > --- > libavcodec/vc1_block.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) will apply btw, maybe you want to add yourself to the MAINTAINERs file for vc1.c, you worked more on it than anyone else recently so you are de facto already maintaining it more than anyone else thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fftools/ffmpeg: fix mixed code and declarations
Signed-off-by: James Almer
---
fftools/ffmpeg.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index d3054092ba..9b3e9d121e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4727,8 +4727,7 @@ static int transcode(void)
static BenchmarkTimeStamps get_benchmark_time_stamps(void)
{
-BenchmarkTimeStamps time_stamps;
-time_stamps.real_usec = av_gettime_relative();
+BenchmarkTimeStamps time_stamps = { .real_usec = av_gettime_relative() };
#if HAVE_GETRUSAGE
struct rusage rusage;
@@ -4833,10 +4832,11 @@ int main(int argc, char **argv)
if (transcode() < 0)
exit_program(1);
if (do_benchmark) {
+int64_t utime, stime, rtime;
current_time = get_benchmark_time_stamps();
-int64_t utime = current_time.user_usec - ti.user_usec;
-int64_t stime = current_time.sys_usec - ti.sys_usec;
-int64_t rtime = current_time.real_usec - ti.real_usec;
+utime = current_time.user_usec - ti.user_usec;
+stime = current_time.sys_usec - ti.sys_usec;
+rtime = current_time.real_usec - ti.real_usec;
av_log(NULL, AV_LOG_INFO,
"bench: utime=%0.3fs stime=%0.3fs rtime=%0.3fs\n",
utime / 100.0, stime / 100.0, rtime / 100.0);
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
