Re: [FFmpeg-devel] libavcodec: add timeshift bitstream filter [v3]
Hi Alexander, ‐‐‐ Original Message ‐‐‐ On Thursday, 8 de August de 2019 1:43, Alexander Strasser wrote: > On 2019-08-07 15:51 +, Andreas Håkon wrote: > > > Hi, > > This new version changes the name of the filter, and implements all > > suggestions. > > Thanks for renaming; "timeshift" sounds better to me, compared to > the previous "timer". > > Other suggestions which I came up with: > > - adjust_timestamps > - edit_timestamps > > Instead of the _timestamps suffix _ts or _ptsdts could be used. I like the name "edit_ts", it's short and clear. Opinions? > Maybe others have better suggestions. For me the current name > timeshift is acceptable. If you decide to rename it yet again, > I would recommend to not send new versions of the patch with > only name change for now. It's better to wait for potential > review comments. OK. > To make it clear I did only read your patch and didn't review > it at all. I wanted to comment on the name in time, because it's > always significantly more effort to deal with user visible naming > once the code is merged. I hope someone will review it soon. Regards. A.H. --- ___ 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 v4] avutil/mips: refine msa macros CLIP_*.
> 发件人: "Michael Niedermayer" > 发送时间: 2019-08-08 07:05:13 (星期四) > 收件人: "FFmpeg development discussions and patches" > 抄送: > 主题: Re: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*. > > On Wed, Aug 07, 2019 at 05:52:00PM +0800, gxw wrote: > > Changing details as following: > > 1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in > >source vector. > > 2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'. > >Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x). > >Performance of H264 decoding has speed up about 0.5%(from 4.35x to > > 4.37x). > >Performance of Theora decoding has speed up about 0.7%(from 5.79x to > > 5.83x). > > 3. Remove redundant macro 'CLIP_SH/Wn_0_255_MAX_SATU' and use > > 'CLIP_SH/Wn_0_255' > >instead, because there are no difference in the effect of this two > > macros. > > can these 3 things be split into 3 patches ? > It would be clearer if each change would be in its own patch > > thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Whats the most studid thing your enemy could do ? Blow himself up > Whats the most studid thing you could do ? Give up your rights and > freedom because your enemy blew himself up. It can be split into 3 patches. But there some benefits as 1 patch, these macros belong to the same class and are highly relevant. It is more intuitive to put them in a patch. thanks 北京市海淀区中关村环保科技示范园龙芯产业园2号楼 100095电话: +86 (10) 62546668传真: +86 (10) 62600826www.loongson.cn本邮件及其附件含有龙芯中科技术有限公司的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部 分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology Corporation Limited, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] hwcontext_d3d11va: support bgr0 pixel format
From: Thomas Volkert
---
libavutil/hwcontext_d3d11va.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 6670c47579..0204407330 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -82,11 +82,12 @@ static const struct {
DXGI_FORMAT d3d_format;
enum AVPixelFormat pix_fmt;
} supported_formats[] = {
-{ DXGI_FORMAT_NV12, AV_PIX_FMT_NV12 },
-{ DXGI_FORMAT_P010, AV_PIX_FMT_P010 },
+{ DXGI_FORMAT_NV12, AV_PIX_FMT_NV12 },
+{ DXGI_FORMAT_P010, AV_PIX_FMT_P010 },
+{ DXGI_FORMAT_B8G8R8A8_UNORM, AV_PIX_FMT_BGR0 },
// Special opaque formats. The pix_fmt is merely a place holder, as the
// opaque format cannot be accessed directly.
-{ DXGI_FORMAT_420_OPAQUE, AV_PIX_FMT_YUV420P },
+{ DXGI_FORMAT_420_OPAQUE, AV_PIX_FMT_YUV420P },
};
static void d3d11va_default_lock(void *ctx)
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1] lavf/hls: add http_seekable option for HTTP partial requests
> 在 2019年8月8日，上午12:32，Jun Zhao 写道：
>
> From: Jun Zhao
>
> Add http_seekable option for HTTP partial requests, when The
> EXT-X-BYTERANGE tag indicates that a Media Segment is a sub-range
> of the resource identified by its URI, we can use HTTP partial
> requests to get the Media Segment.
>
> Signed-off-by: Jun Zhao
> ---
> doc/demuxers.texi |4
> libavformat/hls.c |9 +++--
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 57d1532..fe766a5 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -338,6 +338,10 @@ Enabled by default.
> @item http_multiple
> Use multiple HTTP connections for downloading HTTP segments.
> Enabled by default for HTTP/1.1 servers.
> +
> +@item http_seekable
> +Use HTTP partial requests for downloading HTTP segments.
> +0 = disable, 1 = enable, -1 = auto, Default is auto.
> @end table
>
> @section image2
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 0522445..61b6759 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -207,6 +207,7 @@ typedef struct HLSContext {
> int max_reload;
> int http_persistent;
> int http_multiple;
> +int http_seekable;
> AVIOContext *playlist_pb;
> } HLSContext;
>
> @@ -1796,8 +1797,10 @@ static int hls_read_header(AVFormatContext *s)
> if ((ret = save_avio_options(s)) < 0)
> goto fail;
>
> -/* Some HLS servers don't like being sent the range header */
> -av_dict_set(>avio_opts, "seekable", "0", 0);
> +/* XXX: Some HLS servers don't like being sent the range header,
> + in this case, need to setting http_seekable = 0 to disable
> + the range header */
> +av_dict_set_int(>avio_opts, "seekable", c->http_seekable, 0);
>
> if ((ret = parse_playlist(c, s->url, NULL, s->pb)) < 0)
> goto fail;
> @@ -2311,6 +2314,8 @@ static const AVOption hls_options[] = {
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
> {"http_multiple", "Use multiple HTTP connections for fetching segments",
> OFFSET(http_multiple), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, FLAGS},
> +{"http_seekable", "Use HTTP partial requests, 0 = disable, 1 = enable,
> -1 = auto",
> +OFFSET(http_seekable), AV_OPT_TYPE_BOOL, { .i64 = -1}, -1, 1, FLAGS},
> {NULL}
> };
>
> --
> 1.7.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe”.
LGTM
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] libavcodec: add timeshift bitstream filter [v3]
On 2019-08-07 15:51 +, Andreas Håkon wrote: > Hi, > > This new version changes the name of the filter, and implements all > suggestions. Sorry, I couldn't reply earlier. Thanks for renaming; "timeshift" sounds better to me, compared to the previous "timer". Other suggestions which I came up with: * adjust_timestamps * edit_timestamps Instead of the _timestamps suffix _ts or _ptsdts could be used. Maybe others have better suggestions. For me the current name timeshift is acceptable. If you decide to rename it yet again, I would recommend to not send new versions of the patch with only name change for now. It's better to wait for potential review comments. To make it clear I did only read your patch and *didn't review* it at all. I wanted to comment on the name in time, because it's always significantly more effort to deal with user visible naming once the code is merged. Alexander > Supersedes: > https://patchwork.ffmpeg.org/patch/14195/ > https://patchwork.ffmpeg.org/patch/13743/ > https://patchwork.ffmpeg.org/patch/13699/ > > Regards. > A.H. > > --- > From 9e036e0a1dc20fd5c41686a48a5a0c2142f91de4 Mon Sep 17 00:00:00 2001 > From: Andreas Hakon > Date: Wed, 7 Aug 2019 17:45:25 +0200 > Subject: [PATCH] libavcodec: add timeshift bitstream filter [v3] > > This implements the new timeshift bitstream filter. > > Signed-off-by: Andreas Hakon > --- > doc/bitstream_filters.texi | 11 + > libavcodec/Makefile|1 + > libavcodec/bitstream_filters.c |1 + > libavcodec/timeshift_bsf.c | 87 > > 4 files changed, 100 insertions(+) > create mode 100644 libavcodec/timeshift_bsf.c > [...] ___ 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 4/5] avcodec/tiff: Detect infinite retry loop
On Tue, Aug 06, 2019 at 11:30:05PM +0200, Michael Niedermayer wrote: > Fixes: Timeout (Infinite->Finite) > Fixes: > 15706/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5114674904825856 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/tiff.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) This patch is likely buggy, ill write a better one Note, testcases which fail are welcome (i have none ATM) Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.
On Wed, Aug 07, 2019 at 05:52:00PM +0800, gxw wrote: > Changing details as following: > 1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in >source vector. > 2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'. >Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x). >Performance of H264 decoding has speed up about 0.5%(from 4.35x to 4.37x). >Performance of Theora decoding has speed up about 0.7%(from 5.79x to > 5.83x). > 3. Remove redundant macro 'CLIP_SH/Wn_0_255_MAX_SATU' and use > 'CLIP_SH/Wn_0_255' >instead, because there are no difference in the effect of this two macros. can these 3 things be split into 3 patches ? It would be clearer if each change would be in its own patch thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/avio: add avio_print_n_strings and avio_print
On 2019-08-07 21:28 +0200, Marton Balint wrote:
>
> On Wed, 7 Aug 2019, Alexander Strasser wrote:
>
> > Hi Marton!
> >
> > Not really sure if we need the API, but it definitely looks
> > handy. Just not sure how often it will used and really result
> > in clearer or shorter code.
>
> It has better performance than using av_printf because it does not need a
> temporary buffer.
True. I meant one could use avio_write like Paul demonstrated
or like Nicolas suggested introduce a simple wrapper function
avio_write_string .
But as I said right below, I'm not against this API.
> > Not opposed to it though; no strong opinion on this one.
> > Some comments follow inline. No in depth review, just what
> > came to my mind when reading your patch quickly.
> >
> >
> > On 2019-08-05 23:34 +0200, Marton Balint wrote:
> > > These functions can be used to print a variable number of strings
> > > consecutively
> > > to the IO context. Unlike av_bprintf, no temporery buffer is necessary.
> >
> > Small typo here: temporary
>
> Fixed locally.
>
> >
> > > Signed-off-by: Marton Balint
> > > ---
> > > doc/APIchanges| 3 +++
> > > libavformat/avio.h| 16
> > > libavformat/aviobuf.c | 17 +
> > > libavformat/version.h | 2 +-
> > > 4 files changed, 37 insertions(+), 1 deletion(-)
[...]
> > >
> > > +/**
> > > + * Write nb_strings number of strings (const char *) to the context.
> > > + * @return the total number of bytes written
> > > + */
> > > +int avio_print_n_strings(AVIOContext *s, int nb_strings, ...);
> > > +
> > > +/**
> > > + * Write strings (const char *) to the context.
> > > + * This is a macro around avio_print_n_strings but the number of strings
> > > to be
> > > + * written is determined automatically at compile time based on the
> > > number of
> > > + * parameters passed to this macro. For simple string concatenations this
> > > + * function is more performant than using avio_printf.
> > > + */
> > > +#define avio_print(s, ...) \
> > > +avio_print_n_strings(s, sizeof((const char*[]){__VA_ARGS__}) /
> > > sizeof(const char*), __VA_ARGS__)
> >
> > If we don't have this pattern in the code base already, it would
> > be better to compile and test on bunch of different compilers.
>
> I tested a few compilers (Clang, GCC, MSVC 2015) on https://godbolt.org/ and
> it seems to work.
Sounds good.
Another thing is, that the convenient macro will probably only be
usable in C client code. That's of course expected, and bindings
could provide similar implementations inspired by your design of
avio_print, which might be easier anyway in many cases. Just saying
because I think we should consider those things when designing and
extending FFmpeg's APIs.
[...]
> > >
> > > +int avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
> > > +{
> > > +va_list ap;
> > > +int ret = 0;
> > > +
> > > +va_start(ap, nb_strings);
> > > +for (int i = 0; i < nb_strings; i++) {
> > > +const char *str = va_arg(ap, const char *);
> > > +int len = strlen(str);
> > > +avio_write(s, (const unsigned char *)str, len);
> > > +ret += len;
> >
> > I first wanted to say you should compute with the count returned
> > by avio_write; then after diving into libavformat/avio_buf and
> > reading a cascade of void functions and seeing signalling via
> > field error in the context which also is sometimes (mis)used
> > to store a length(?), I withdraw that comment.
> >
> > Anyway you might consider using void for this function too,
> > otherwise I guess you should figure out how to do the error
> > checking inside of this function because if an error occurs
> > that call might have been partial and the following writes will
> > effectively not occur. So I'm feeling rather uncomfortable
> > with returning a count here. Maybe my stance is to narrow.
>
> It returns int because avio_printf also returns int, but since no error
> (other than IO error) can happen, maybe it is better to return void the same
> way as avio_write functions do. For IO errors the user should always check
> the IO context error flag, that is by design as far as I know.
>
> I'll change it to return void.
I have seen it in your patch version 2. Looks fine.
No more comments from me.
Thanks,
Alexander
___
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] Extract QP from h264 encoded videos
Aug 7, 2019, 11:46 PM by juandl-at-google@ffmpeg.org:
> On Tue, Aug 6, 2019 at 5:07 PM Mark Thompson wrote:
>
>> This should be in libavcodec, not libavutil - it relates directly to
>> codecs. (Indeed, you've ended up having to define a special non-libavcodec
>> enum of codecs below to make it work in libavutil at all.)
>>
> If this belongs in avcodec I can move it there, but I don't see a similar
> data structure in that library.
> I believe declaring different IDs for supported codecs here is a better
> approach.
>
>
>> > +enum AVQPArrIndexesH264 { // varaible names in spec document
>>
>> I don't think giving these enums a tag has any value?
>>
> They are not used in the code, but keeping them makes the purpose of each
> enum clearer.
>
>
>> > +AV_QP_ARR_SIZE_H264
>> > +};
>> > +
>> > +enum AVQPArrIndexesVP9 { // variable names in spec document
>> > +AV_QP_YAC_VP9 = 0, // get_dc_quant[][base_q_idx]
>>
>> This isn't right - get_dc_quant() is a function of one variable, not a
>> two-dimensional array (confused with dc_qlookup[][] somehow?).
>>
> Thank you, I think I meant: ac_q(get_qindex()).
>
> Why are you including higher-level frame values for VP9 and AV1, but not
>
>> including similar ones for H.264?
>>
> Again, I meant get_qindex(), it is supposed to represent the quant index
> for the specified segment, not frame quant index.
>
> What is the motivation for AV1 returning the exponential coefficient
>
>> scaling values (range 4..29247) rather than the linear parameter (range
>> 0..255) as you do for H.264?
>>
>
> Exposing both the values was a requirement by my team.
>
>> +#define AV_QP_ARR_MAX_SIZE AV_QP_ARR_SIZE_AV1
>>
>> Fixing this for all time for a particular codec which happens to need the
>> most space when it is defined doesn't seem like a good idea. E.g. you
>> can't support JPEG with only this number (it would need all entries in up
>> to four tables).
>>
>
> It might be better if the structure size wasn't fixed forever by the first
>
>> version of the API/ABI. Perhaps an approach something like that used for
>> AVRegionOfInterest would work?
>>
> Each instance of AVQuantizationParams has an array of qp values/indexes
> (qp_type[]) for which I need a constant to allocate memory.
> The approach AVRegionOfInterest uses does not solve that problem.
>
>> +/**
>> > + * x and y coordinates of the block in pixels
>> > + */
>> > +int x, y;
>>
>> Don't call these x/y coordinates because it not clear exactly what that
>> means (what is the scale, where is the origin, which direction is positive,
>> where in the block is being referred to, etc.).
>>
>
> Instead follow the same convention as other structures in FFmpeg and define
>
>> them as the distance in pixels from the left or the top edge of the picture
>> to the top-left corner of the block.
>>
> That's exactly their purpose, the distance in pixels from the top-left
> corner of the frame, to the top-left corner of the block. I will make the
> description clearer, thank you.
>
>
>> On 30/07/2019 03:19, Juan De León wrote:
>> > On Mon, Jul 29, 2019 at 12:48 PM Mark Thompson wrote:
>> >>
>> >> How do these values interact with cropping?
>> >
>> > I'm not sure I understand, could you elaborate?
>>
>> For codecs which include cropping such as H.26[45], the decoder may
>> directly apply cropping from the stream (controlled by
>> AVCodecContext.apply_cropping), possibly modified by alignment (with
>> AV_CODEC_FLAG_UNALIGNED), and then sets the AVFrame cropping fields to
>> reflect the remainder.
>>
>
> For example, in H.264 try setting the
>
>> frame_crop_left_offset/frame_crop_top_offset fields in a stream to large
>> values (h264_metadata can do this for an existing stream). What do your
>> x/y values then refer to in the result? They could be negative to indicate
>> macroblocks which are off the edges of the cropped picture, or they might
>> be relative to the uncropped picture in which case you would need
>> additional information to reconstruct which blocks they refer to in the
>> frame you actually have.
>>
> The coordinates of the blocks should correspond to the coded picture,
> quantization is still applied to cropped MBs outside of the frame so that
> should be considered for the logging and avg calculation, similar to an
> analyzer.
>
>
>> > +/**
>> > + * Stores an id corresponding to one of the supported codecs
>> > + */
>> > +enum AVExtractQPSupportedCodecs codec_id;
>>
>> enum AVCodecID, with this in libavcodec.
>>
> Like Michael said, this could cause conflict when extracting QP. It might
> be better to leave it as a separate ID.
>
No one will start writing an mpeg2 encoder now, so I disagree. A codec ID is
better.
>> +/**
>> > + * Get the string describing the qp type for the given codec
>> > + */
>> > +const char* av_get_qp_type_string(enum AVExtractQPSupportedCodecs
>> codec_id, int index);
>>
>> I'm not sure there is a good reason to embed this in the public API - what
Re: [FFmpeg-devel] [PATCH] Extract QP from h264 encoded videos
On Tue, Aug 6, 2019 at 5:07 PM Mark Thompson wrote:
> This should be in libavcodec, not libavutil - it relates directly to
> codecs. (Indeed, you've ended up having to define a special non-libavcodec
> enum of codecs below to make it work in libavutil at all.)
>
If this belongs in avcodec I can move it there, but I don't see a similar
data structure in that library.
I believe declaring different IDs for supported codecs here is a better
approach.
> > +enum AVQPArrIndexesH264 { // varaible names in spec document
>
> I don't think giving these enums a tag has any value?
>
They are not used in the code, but keeping them makes the purpose of each
enum clearer.
> > +AV_QP_ARR_SIZE_H264
> > +};
> > +
> > +enum AVQPArrIndexesVP9 { // variable names in spec document
> > +AV_QP_YAC_VP9 = 0, // get_dc_quant[][base_q_idx]
>
> This isn't right - get_dc_quant() is a function of one variable, not a
> two-dimensional array (confused with dc_qlookup[][] somehow?).
>
Thank you, I think I meant: ac_q(get_qindex()).
Why are you including higher-level frame values for VP9 and AV1, but not
> including similar ones for H.264?
>
Again, I meant get_qindex(), it is supposed to represent the quant index
for the specified segment, not frame quant index.
What is the motivation for AV1 returning the exponential coefficient
> scaling values (range 4..29247) rather than the linear parameter (range
> 0..255) as you do for H.264?
Exposing both the values was a requirement by my team.
> +#define AV_QP_ARR_MAX_SIZE AV_QP_ARR_SIZE_AV1
>
> Fixing this for all time for a particular codec which happens to need the
> most space when it is defined doesn't seem like a good idea. E.g. you
> can't support JPEG with only this number (it would need all entries in up
> to four tables).
It might be better if the structure size wasn't fixed forever by the first
> version of the API/ABI. Perhaps an approach something like that used for
> AVRegionOfInterest would work?
>
Each instance of AVQuantizationParams has an array of qp values/indexes
(qp_type[]) for which I need a constant to allocate memory.
The approach AVRegionOfInterest uses does not solve that problem.
> +/**
> > + * x and y coordinates of the block in pixels
> > + */
> > +int x, y;
>
> Don't call these x/y coordinates because it not clear exactly what that
> means (what is the scale, where is the origin, which direction is positive,
> where in the block is being referred to, etc.).
Instead follow the same convention as other structures in FFmpeg and define
> them as the distance in pixels from the left or the top edge of the picture
> to the top-left corner of the block.
>
That's exactly their purpose, the distance in pixels from the top-left
corner of the frame, to the top-left corner of the block. I will make the
description clearer, thank you.
> On 30/07/2019 03:19, Juan De León wrote:
> > On Mon, Jul 29, 2019 at 12:48 PM Mark Thompson wrote:
> >>
> >> How do these values interact with cropping?
> >
> > I'm not sure I understand, could you elaborate?
>
> For codecs which include cropping such as H.26[45], the decoder may
> directly apply cropping from the stream (controlled by
> AVCodecContext.apply_cropping), possibly modified by alignment (with
> AV_CODEC_FLAG_UNALIGNED), and then sets the AVFrame cropping fields to
> reflect the remainder.
For example, in H.264 try setting the
> frame_crop_left_offset/frame_crop_top_offset fields in a stream to large
> values (h264_metadata can do this for an existing stream). What do your
> x/y values then refer to in the result? They could be negative to indicate
> macroblocks which are off the edges of the cropped picture, or they might
> be relative to the uncropped picture in which case you would need
> additional information to reconstruct which blocks they refer to in the
> frame you actually have.
>
The coordinates of the blocks should correspond to the coded picture,
quantization is still applied to cropped MBs outside of the frame so that
should be considered for the logging and avg calculation, similar to an
analyzer.
> > +/**
> > + * Stores an id corresponding to one of the supported codecs
> > + */
> > +enum AVExtractQPSupportedCodecs codec_id;
>
> enum AVCodecID, with this in libavcodec.
>
Like Michael said, this could cause conflict when extracting QP. It might
be better to leave it as a separate ID.
> +/**
> > + * Get the string describing the qp type for the given codec
> > + */
> > +const char* av_get_qp_type_string(enum AVExtractQPSupportedCodecs
> codec_id, int index);
>
> I'm not sure there is a good reason to embed this in the public API - what
> user is ever going to call this function? Anyone using the enum values
> must already know exactly what each of them mean to do anything with them
> at all, so if they need string names they'll already have clearer ones than
> the cryptic short names you provide here.
I think it would probably be better to just
Re: [FFmpeg-devel] [PATCH v10 02/13] lavc/tiff: Decode embedded JPEGs in DNG images
On Wed, Aug 07, 2019 at 06:27:12PM +0300, velocit...@gmail.com wrote:
> From: Nick Renieris
>
> Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
>
> This commit adds support for:
> - DNG tiles
> - DNG tile huffman lossless JPEG decoding
> - DNG 8-bpp ("packed" as dcraw calls it) decoding
> - DNG color scaling [1]
> - LinearizationTable tag
> - BlackLevel tag
>
> [1]: As specified in the DNG Specification - Chapter 5
>
> Signed-off-by: Nick Renieris
> ---
> configure | 1 +
> libavcodec/Makefile | 2 +-
> libavcodec/tiff.c | 318 +++-
> libavcodec/tiff.h | 2 +
> 4 files changed, 315 insertions(+), 8 deletions(-)
breaks
TESTtiff-fax-g3s
--- ./tests/ref/fate/tiff-fax-g3s 2019-08-05 22:38:57.562197572 +0200
+++ tests/data/fate/tiff-fax-g3s2019-08-08 00:31:26.473428768 +0200
@@ -3,4 +3,4 @@
#codec_id 0: rawvideo
#dimensions 0: 2464x3248
#sar 0: 1/1
-0, 0, 0,1, 1000384, 0xb758eb8b
+0, 0, 0,1, 16006144, 0xef95913a
Test tiff-fax-g3s failed. Look at tests/data/fate/tiff-fax-g3s.err for details.
make: *** [fate-tiff-fax-g3s] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v10 04/13] lavc/tiff: Apply color scaling to uncompressed DNGs
On Wed, Aug 07, 2019 at 06:27:14PM +0300, velocit...@gmail.com wrote:
> From: Nick Renieris
>
> Signed-off-by: Nick Renieris
> ---
> libavcodec/tiff.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index c7e2adb3ae..b6f626daca 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -679,6 +679,25 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
> uint8_t *dst, int strid
> for (i = 0; i < width; i++)
> dst[i] = ff_reverse[src[i]];
> }
> +
> +/* Color processing for DNG images with uncompressed strips
> (non-tiled) */
> +if (is_dng) {
This variable is only added in a later patch
so this does not build
also some change in this patchset breaks:
./ffplay tickets/2826/pred6disc7.jpg
file should be here:
https://trac.ffmpeg.org/raw-attachment/ticket/2826/pred6disc7.jpg
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCHv2 1/3] avformat/avio: add avio_print_n_strings and avio_print
These functions can be used to print a variable number of strings consecutively
to the IO context. Unlike av_bprintf, no temporary buffer is necessary.
Signed-off-by: Marton Balint
---
doc/APIchanges| 3 +++
libavformat/avio.h| 17 +
libavformat/aviobuf.c | 12
libavformat/version.h | 2 +-
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6603a8229e..0b19fb067d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2019-08-xx - xx - lavf 58.31.100 - avio.h
+ Add avio_print_n_strings and avio_print.
+
2019-07-27 - xx - lavu 56.33.100 - tx.h
Add AV_TX_DOUBLE_FFT and AV_TX_DOUBLE_MDCT
diff --git a/libavformat/avio.h b/libavformat/avio.h
index dcb8dcdf93..0c622f44bd 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -574,6 +574,23 @@ int avio_feof(AVIOContext *s);
/** @warning Writes up to 4 KiB per call */
int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2, 3);
+/**
+ * Write nb_strings number of strings (const char *) to the context.
+ * This function is not to be used directly, use avio_print instead.
+ */
+void avio_print_n_strings(AVIOContext *s, int nb_strings, ...);
+
+/**
+ * Write strings (const char *) to the context.
+ * This is a macro around avio_print_n_strings but the number of strings to be
+ * written is determined automatically at compile time based on the number of
+ * parameters passed to this macro. For simple string concatenations this
+ * function is more performant than using avio_printf since it does not need a
+ * temporary buffer.
+ */
+#define avio_print(s, ...) \
+avio_print_n_strings(s, sizeof((const char*[]){__VA_ARGS__}) /
sizeof(const char*), __VA_ARGS__)
+
/**
* Force flushing of buffered data.
*
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 2d011027c9..4a37a13d7a 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1225,6 +1225,18 @@ int avio_printf(AVIOContext *s, const char *fmt, ...)
return ret;
}
+void avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
+{
+va_list ap;
+
+va_start(ap, nb_strings);
+for (int i = 0; i < nb_strings; i++) {
+const char *str = va_arg(ap, const char *);
+avio_write(s, (const unsigned char *)str, strlen(str));
+}
+va_end(ap);
+}
+
int avio_pause(AVIOContext *s, int pause)
{
if (!s->read_pause)
diff --git a/libavformat/version.h b/libavformat/version.h
index 45efaff9b9..feceaedc08 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 58
-#define LIBAVFORMAT_VERSION_MINOR 30
+#define LIBAVFORMAT_VERSION_MINOR 31
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/avio: add avio_print_n_strings and avio_print
On Wed, 7 Aug 2019, Alexander Strasser wrote:
Hi Marton!
Not really sure if we need the API, but it definitely looks
handy. Just not sure how often it will used and really result
in clearer or shorter code.
It has better performance than using av_printf because it does not need a
temporary buffer.
Not opposed to it though; no strong opinion on this one.
Some comments follow inline. No in depth review, just what
came to my mind when reading your patch quickly.
On 2019-08-05 23:34 +0200, Marton Balint wrote:
These functions can be used to print a variable number of strings consecutively
to the IO context. Unlike av_bprintf, no temporery buffer is necessary.
Small typo here: temporary
Fixed locally.
Signed-off-by: Marton Balint
---
doc/APIchanges| 3 +++
libavformat/avio.h| 16
libavformat/aviobuf.c | 17 +
libavformat/version.h | 2 +-
4 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6603a8229e..0b19fb067d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2019-08-xx - xx - lavf 58.31.100 - avio.h
+ Add avio_print_n_strings and avio_print.
+
2019-07-27 - xx - lavu 56.33.100 - tx.h
Add AV_TX_DOUBLE_FFT and AV_TX_DOUBLE_MDCT
diff --git a/libavformat/avio.h b/libavformat/avio.h
index dcb8dcdf93..ca08907917 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -574,6 +574,22 @@ int avio_feof(AVIOContext *s);
/** @warning Writes up to 4 KiB per call */
int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2, 3);
+/**
+ * Write nb_strings number of strings (const char *) to the context.
+ * @return the total number of bytes written
+ */
+int avio_print_n_strings(AVIOContext *s, int nb_strings, ...);
+
+/**
+ * Write strings (const char *) to the context.
+ * This is a macro around avio_print_n_strings but the number of strings to be
+ * written is determined automatically at compile time based on the number of
+ * parameters passed to this macro. For simple string concatenations this
+ * function is more performant than using avio_printf.
+ */
+#define avio_print(s, ...) \
+avio_print_n_strings(s, sizeof((const char*[]){__VA_ARGS__}) /
sizeof(const char*), __VA_ARGS__)
If we don't have this pattern in the code base already, it would
be better to compile and test on bunch of different compilers.
I tested a few compilers (Clang, GCC, MSVC 2015) on https://godbolt.org/
and it seems to work.
+
/**
* Force flushing of buffered data.
*
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 2d011027c9..c37b056b64 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1225,6 +1225,23 @@ int avio_printf(AVIOContext *s, const char *fmt, ...)
return ret;
}
+int avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
+{
+va_list ap;
+int ret = 0;
+
+va_start(ap, nb_strings);
+for (int i = 0; i < nb_strings; i++) {
+const char *str = va_arg(ap, const char *);
+int len = strlen(str);
+avio_write(s, (const unsigned char *)str, len);
+ret += len;
I first wanted to say you should compute with the count returned
by avio_write; then after diving into libavformat/avio_buf and
reading a cascade of void functions and seeing signalling via
field error in the context which also is sometimes (mis)used
to store a length(?), I withdraw that comment.
Anyway you might consider using void for this function too,
otherwise I guess you should figure out how to do the error
checking inside of this function because if an error occurs
that call might have been partial and the following writes will
effectively not occur. So I'm feeling rather uncomfortable
with returning a count here. Maybe my stance is to narrow.
It returns int because avio_printf also returns int, but since no error
(other than IO error) can happen, maybe it is better to return void the
same way as avio_write functions do. For IO errors the user should always
check the IO context error flag, that is by design as far as I know.
I'll change it to return void.
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/fate: Document how to request samples upload access
Am 07.08.19 um 21:18 schrieb Michael Niedermayer: > The awnser which most people will seek is put first > > Signed-off-by: Michael Niedermayer > --- > doc/fate.texi | 4 > 1 file changed, 4 insertions(+) > > diff --git a/doc/fate.texi b/doc/fate.texi > index 2be61d639c..c3550785a1 100644 > --- a/doc/fate.texi > +++ b/doc/fate.texi > @@ -149,6 +149,8 @@ the synchronisation of the samples directory. > > @chapter Uploading new samples to the fate suite > > +If you need a sample uploaded send a mail to samples-request. > + > This is for developers who have an account on the fate suite server. > If you upload new samples, please make sure they are as small as possible, > space on each client, network bandwidth and so on benefit from smaller test > cases. > @@ -157,6 +159,8 @@ practice generally do not replace, remove or overwrite > files as it likely would > break older checkouts or releases. > Also all needed samples for a commit should be uploaded, ideally 24 > hours, before the push. > +If you need an account for frequently uploading samples or you wish to help > +others by doing that send a mail to ffmpeg-devel. LGTM -Thilo ___ 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] doc/fate: Document how to request samples upload access
The awnser which most people will seek is put first Signed-off-by: Michael Niedermayer --- doc/fate.texi | 4 1 file changed, 4 insertions(+) diff --git a/doc/fate.texi b/doc/fate.texi index 2be61d639c..c3550785a1 100644 --- a/doc/fate.texi +++ b/doc/fate.texi @@ -149,6 +149,8 @@ the synchronisation of the samples directory. @chapter Uploading new samples to the fate suite +If you need a sample uploaded send a mail to samples-request. + This is for developers who have an account on the fate suite server. If you upload new samples, please make sure they are as small as possible, space on each client, network bandwidth and so on benefit from smaller test cases. @@ -157,6 +159,8 @@ practice generally do not replace, remove or overwrite files as it likely would break older checkouts or releases. Also all needed samples for a commit should be uploaded, ideally 24 hours, before the push. +If you need an account for frequently uploading samples or you wish to help +others by doing that send a mail to ffmpeg-devel. @example #First update your local samples copy: -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Extract QP from h264 encoded videos
On Wed, Aug 07, 2019 at 12:59:33AM +0100, Mark Thompson wrote: > On 05/08/2019 20:20, Juan De León wrote: [...] > > > +/** > > + * Stores an id corresponding to one of the supported codecs > > + */ > > +enum AVExtractQPSupportedCodecs codec_id; > > enum AVCodecID, with this in libavcodec. This may have interresting corner cases like mpeg4 which can use h263 style or mpeg2 style quantization depending on a flag so for these we may want the stored type to differ from the actual decoder codec_id and then the question of course arrises if a codec uses the same type of quantization as another, should it use the same id as that other or its own id. I think both have advantages and disadvantages Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/2] AltiVec/VSX fixes in swscale
On Wed, Aug 7, 2019, at 14:28, Moritz Barsnick wrote: > On Tue, Aug 06, 2019 at 17:55:35 +0200, Daniel Kolesa wrote: > > The first of these patches fixes the original report as described in > > https://trac.ffmpeg.org/ticket/7861. The second of the patches fixes > > the second report in the same ticket (by leigh123linux). > > If so, each of the commit messages should additionally say: > > "Fixes #7861" Alright, resent with updated commit messages. Daniel > > Moritz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/2] swscale: Replace illegal vector keyword usage in altivec code
While this technically compiles in current ffmpeg, this is only
because ffmpeg is compiled in strict ISO C mode, which disables
the builtin 'vector' keyword for AltiVec/VSX. Instead this gets
replaced with a macro inside altivec.h, which defines vector to
be actually __vector, which accepts random types.
Normally, the vector keyword should be used only with plain
scalar non-typedef types, such as unsigned int. But we have the
vec_(s|u)(8|16|32) macros, which can be used in a portable manner,
in util_altivec.h in libavutil.
This is also consistent with other AltiVec/VSX code elsewhere in
the tree.
Fixes #7861.
Signed-off-by: Daniel Kolesa
---
libswscale/ppc/swscale_altivec.c | 36 +-
libswscale/ppc/swscale_vsx.c | 882 +++
2 files changed, 459 insertions(+), 459 deletions(-)
diff --git a/libswscale/ppc/swscale_altivec.c b/libswscale/ppc/swscale_altivec.c
index 6b8cc2c194..1630355f51 100644
--- a/libswscale/ppc/swscale_altivec.c
+++ b/libswscale/ppc/swscale_altivec.c
@@ -153,13 +153,13 @@ static void yuv2plane1_float_altivec(const int32_t *src,
float *dest, int dstW)
const int add = (1 << (shift - 1));
const int clip = (1 << 16) - 1;
const float fmult = 1.0f / 65535.0f;
-const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
-const vector uint32_t vshift = (vector uint32_t) vec_splat_u32(shift);
-const vector uint32_t vlargest = (vector uint32_t) {clip, clip, clip,
clip};
-const vector float vmul = (vector float) {fmult, fmult, fmult, fmult};
-const vector float vzero = (vector float) {0, 0, 0, 0};
-vector uint32_t v;
-vector float vd;
+const vec_u32 vadd = (vec_u32) {add, add, add, add};
+const vec_u32 vshift = (vec_u32) vec_splat_u32(shift);
+const vec_u32 vlargest = (vec_u32) {clip, clip, clip, clip};
+const vec_f vmul = (vec_f) {fmult, fmult, fmult, fmult};
+const vec_f vzero = (vec_f) {0, 0, 0, 0};
+vec_u32 v;
+vec_f vd;
int i;
yuv2plane1_float_u(src, dest, dst_u, 0);
@@ -186,15 +186,15 @@ static void yuv2plane1_float_bswap_altivec(const int32_t
*src, uint32_t *dest, i
const int add = (1 << (shift - 1));
const int clip = (1 << 16) - 1;
const float fmult = 1.0f / 65535.0f;
-const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
-const vector uint32_t vshift = (vector uint32_t) vec_splat_u32(shift);
-const vector uint32_t vlargest = (vector uint32_t) {clip, clip, clip,
clip};
-const vector float vmul = (vector float) {fmult, fmult, fmult, fmult};
-const vector float vzero = (vector float) {0, 0, 0, 0};
-const vector uint32_t vswapbig = (vector uint32_t) {16, 16, 16, 16};
-const vector uint16_t vswapsmall = vec_splat_u16(8);
-vector uint32_t v;
-vector float vd;
+const vec_u32 vadd = (vec_u32) {add, add, add, add};
+const vec_u32 vshift = (vec_u32) vec_splat_u32(shift);
+const vec_u32 vlargest = (vec_u32) {clip, clip, clip, clip};
+const vec_f vmul = (vec_f) {fmult, fmult, fmult, fmult};
+const vec_f vzero = (vec_f) {0, 0, 0, 0};
+const vec_u32 vswapbig = (vec_u32) {16, 16, 16, 16};
+const vec_u16 vswapsmall = vec_splat_u16(8);
+vec_u32 v;
+vec_f vd;
int i;
yuv2plane1_float_bswap_u(src, dest, dst_u, 0);
@@ -208,8 +208,8 @@ static void yuv2plane1_float_bswap_altivec(const int32_t
*src, uint32_t *dest, i
vd = vec_ctf(v, 0);
vd = vec_madd(vd, vmul, vzero);
-vd = (vector float) vec_rl((vector uint32_t) vd, vswapbig);
-vd = (vector float) vec_rl((vector uint16_t) vd, vswapsmall);
+vd = (vec_f) vec_rl((vec_u32) vd, vswapbig);
+vd = (vec_f) vec_rl((vec_u16) vd, vswapsmall);
vec_st(vd, 0, (float *) [i]);
}
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 75dee5ea58..e6a35d3f78 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -103,9 +103,9 @@ static void yuv2plane1_8_vsx(const int16_t *src, uint8_t
*dest, int dstW,
const int dst_u = -(uintptr_t)dest & 15;
int i, j;
LOCAL_ALIGNED(16, int16_t, val, [16]);
-const vector uint16_t shifts = (vector uint16_t) {7, 7, 7, 7, 7, 7, 7, 7};
-vector int16_t vi, vileft, ditherleft, ditherright;
-vector uint8_t vd;
+const vec_u16 shifts = (vec_u16) {7, 7, 7, 7, 7, 7, 7, 7};
+vec_s16 vi, vileft, ditherleft, ditherright;
+vec_u8 vd;
for (j = 0; j < 16; j++) {
val[j] = dither[(dst_u + offset + j) & 7];
@@ -161,11 +161,11 @@ static void yuv2plane1_nbps_vsx(const int16_t *src,
uint16_t *dest, int dstW,
const int shift = 15 - output_bits;
const int add = (1 << (shift - 1));
const int clip = (1 << output_bits) - 1;
-const vector uint16_t vadd = (vector uint16_t) {add, add, add, add, add,
add, add, add};
-const vector uint16_t vswap = (vector uint16_t) vec_splat_u16(big_endian ?
8 : 0);
-const vector uint16_t vshift = (vector
[FFmpeg-devel] [PATCH v2 0/2] AltiVec/VSX fixes in swscale
Updated commit messages. Daniel Kolesa (2): swscale: Replace illegal vector keyword usage in altivec code swscale: Fix AltiVec/VSX build with recent GCC libswscale/ppc/swscale_altivec.c | 36 +- libswscale/ppc/swscale_vsx.c | 894 --- 2 files changed, 467 insertions(+), 463 deletions(-) -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] swscale: Fix AltiVec/VSX build with recent GCC
The argument to vec_splat_u16 must be a literal. By making the
function always inline and marking the arguments const, gcc can
turn those into literals, and avoid build errors like:
swscale_vsx.c:165:53: error: argument 1 must be a 5-bit signed literal
Fixes #7861.
Signed-off-by: Daniel Kolesa
---
libswscale/ppc/swscale_vsx.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index e6a35d3f78..af8b0e1fa3 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -154,8 +154,10 @@ static void yuv2plane1_nbps_u(const int16_t *src, uint16_t
*dest, int dstW,
}
}
-static void yuv2plane1_nbps_vsx(const int16_t *src, uint16_t *dest, int dstW,
- int big_endian, int output_bits)
+static av_always_inline void yuv2plane1_nbps_vsx(const int16_t *src,
+ uint16_t *dest, int dstW,
+ const int big_endian,
+ const int output_bits)
{
const int dst_u = -(uintptr_t)dest & 7;
const int shift = 15 - output_bits;
@@ -273,8 +275,10 @@ static void yuv2plane1_16_u(const int32_t *src, uint16_t
*dest, int dstW,
}
}
-static void yuv2plane1_16_vsx(const int32_t *src, uint16_t *dest, int dstW,
- int big_endian, int output_bits)
+static av_always_inline void yuv2plane1_16_vsx(const int32_t *src,
+ uint16_t *dest, int dstW,
+ const int big_endian,
+ int output_bits)
{
const int dst_u = -(uintptr_t)dest & 7;
const int shift = 3;
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/vaapi_encode: respect -force_key_frames setting
From: Aman Gupta Signed-off-by: Aman Gupta --- libavcodec/vaapi_encode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c index e69b59fa37..2fb43cf1a4 100644 --- a/libavcodec/vaapi_encode.c +++ b/libavcodec/vaapi_encode.c @@ -1057,7 +1057,7 @@ int ff_vaapi_encode_send_frame(AVCodecContext *avctx, const AVFrame *frame) if (err < 0) goto fail; -if (ctx->input_order == 0) +if (ctx->input_order == 0 || frame->pict_type == AV_PICTURE_TYPE_I) pic->force_idr = 1; pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3]; -- 2.20.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 02/14] vaapi_encode: Convert to send/receive API
On Thu, Dec 20, 2018 at 12:46 PM Mark Thompson wrote:
> This attaches the logic of picking the mode of for the next picture to
> the output, which simplifies some choices by removing the concept of
> the picture for which input is not yet available. At the same time,
> we allow more complex reference structures and track more reference
> metadata (particularly the contents of the DPB) for use in the
> codec-specific code.
>
> It also adds flags to explicitly track the available features of the
> different codecs. The new structure also allows open-GOP support, so
> that is now available for codecs which can do it.
> ---
> This change and related pieces (patches 1-6) have been hanging around for
> a while. If there are no comments I'll commit it probably early next year.
>
>
> libavcodec/vaapi_encode.c | 635 +---
> libavcodec/vaapi_encode.h | 74 +++-
> libavcodec/vaapi_encode_h264.c | 7 +-
> libavcodec/vaapi_encode_h265.c | 7 +-
> libavcodec/vaapi_encode_mjpeg.c | 9 +-
> libavcodec/vaapi_encode_mpeg2.c | 5 +-
> libavcodec/vaapi_encode_vp8.c | 3 +-
> libavcodec/vaapi_encode_vp9.c | 5 +-
> 8 files changed, 419 insertions(+), 326 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index d8bedbe162..eec083da4f 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -158,16 +158,10 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
> av_log(avctx, AV_LOG_DEBUG, ".\n");
> }
>
> -av_assert0(pic->input_available && !pic->encode_issued);
> +av_assert0(!pic->encode_issued);
> for (i = 0; i < pic->nb_refs; i++) {
> av_assert0(pic->refs[i]);
> -// If we are serialised then the references must have already
> -// completed. If not, they must have been issued but need not
> -// have completed yet.
> -if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING)
> -av_assert0(pic->refs[i]->encode_complete);
> -else
> -av_assert0(pic->refs[i]->encode_issued);
> +av_assert0(pic->refs[i]->encode_issued);
> }
>
> av_log(avctx, AV_LOG_DEBUG, "Input surface is %#x.\n",
> pic->input_surface);
> @@ -466,10 +460,7 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>
> pic->encode_issued = 1;
>
> -if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING)
> -return vaapi_encode_wait(avctx, pic);
> -else
> -return 0;
> +return 0;
>
> fail_with_picture:
> vaEndPicture(ctx->hwctx->display, ctx->va_context);
> @@ -626,315 +617,330 @@ static int vaapi_encode_free(AVCodecContext *avctx,
> return 0;
> }
>
> -static int vaapi_encode_step(AVCodecContext *avctx,
> - VAAPIEncodePicture *target)
> +static void vaapi_encode_add_ref(AVCodecContext *avctx,
> + VAAPIEncodePicture *pic,
> + VAAPIEncodePicture *target,
> + int is_ref, int in_dpb, int prev)
> {
> -VAAPIEncodeContext *ctx = avctx->priv_data;
> -VAAPIEncodePicture *pic;
> -int i, err;
> +int refs = 0;
>
> -if (ctx->issue_mode == ISSUE_MODE_SERIALISE_EVERYTHING ||
> -ctx->issue_mode == ISSUE_MODE_MINIMISE_LATENCY) {
> -// These two modes are equivalent, except that we wait for
> -// immediate completion on each operation if serialised.
> -
> -if (!target) {
> -// No target, nothing to do yet.
> -return 0;
> -}
> -
> -if (target->encode_complete) {
> -// Already done.
> -return 0;
> -}
> -
> -pic = target;
> -for (i = 0; i < pic->nb_refs; i++) {
> -if (!pic->refs[i]->encode_complete) {
> -err = vaapi_encode_step(avctx, pic->refs[i]);
> -if (err < 0)
> -return err;
> -}
> -}
> -
> -err = vaapi_encode_issue(avctx, pic);
> -if (err < 0)
> -return err;
> -
> -} else if (ctx->issue_mode == ISSUE_MODE_MAXIMISE_THROUGHPUT) {
> -int activity;
> -
> -// Run through the list of all available pictures repeatedly
> -// and issue the first one found which has all dependencies
> -// available (including previously-issued but not necessarily
> -// completed pictures).
> -do {
> -activity = 0;
> -for (pic = ctx->pic_start; pic; pic = pic->next) {
> -if (!pic->input_available || pic->encode_issued)
> -continue;
> -for (i = 0; i < pic->nb_refs; i++) {
> -if (!pic->refs[i]->encode_issued)
> -break;
> -}
> -if (i < pic->nb_refs)
> -continue;
> -err = vaapi_encode_issue(avctx, pic);
> -if (err <
[FFmpeg-devel] [PATCH] avcodec/h264_refs: do not use invalid mmco values in case of error
Hi, patch attached. 0001-avcodec-h264_refs-do-not-use-invalid-mmco-values-in-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V1] lavf/hls: add http_seekable option for HTTP partial requests
From: Jun Zhao
Add http_seekable option for HTTP partial requests, when The
EXT-X-BYTERANGE tag indicates that a Media Segment is a sub-range
of the resource identified by its URI, we can use HTTP partial
requests to get the Media Segment.
Signed-off-by: Jun Zhao
---
doc/demuxers.texi |4
libavformat/hls.c |9 +++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 57d1532..fe766a5 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -338,6 +338,10 @@ Enabled by default.
@item http_multiple
Use multiple HTTP connections for downloading HTTP segments.
Enabled by default for HTTP/1.1 servers.
+
+@item http_seekable
+Use HTTP partial requests for downloading HTTP segments.
+0 = disable, 1 = enable, -1 = auto, Default is auto.
@end table
@section image2
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 0522445..61b6759 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -207,6 +207,7 @@ typedef struct HLSContext {
int max_reload;
int http_persistent;
int http_multiple;
+int http_seekable;
AVIOContext *playlist_pb;
} HLSContext;
@@ -1796,8 +1797,10 @@ static int hls_read_header(AVFormatContext *s)
if ((ret = save_avio_options(s)) < 0)
goto fail;
-/* Some HLS servers don't like being sent the range header */
-av_dict_set(>avio_opts, "seekable", "0", 0);
+/* XXX: Some HLS servers don't like being sent the range header,
+ in this case, need to setting http_seekable = 0 to disable
+ the range header */
+av_dict_set_int(>avio_opts, "seekable", c->http_seekable, 0);
if ((ret = parse_playlist(c, s->url, NULL, s->pb)) < 0)
goto fail;
@@ -2311,6 +2314,8 @@ static const AVOption hls_options[] = {
OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
{"http_multiple", "Use multiple HTTP connections for fetching segments",
OFFSET(http_multiple), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, FLAGS},
+{"http_seekable", "Use HTTP partial requests, 0 = disable, 1 = enable, -1
= auto",
+OFFSET(http_seekable), AV_OPT_TYPE_BOOL, { .i64 = -1}, -1, 1, FLAGS},
{NULL}
};
--
1.7.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] doc/fate: Document how to request samples upload access
Am 07.08.19 um 16:57 schrieb Li, Zhong: >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Michael Niedermayer >> Sent: Tuesday, August 6, 2019 1:07 AM >> To: FFmpeg development discussions and patches >> >> Subject: [FFmpeg-devel] [PATCH] doc/fate: Document how to request >> samples upload access >> >> Signed-off-by: Michael Niedermayer >> --- >> doc/fate.texi | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/doc/fate.texi b/doc/fate.texi index 2be61d639c..e04fbfbe43 >> 100644 >> --- a/doc/fate.texi >> +++ b/doc/fate.texi >> @@ -157,6 +157,9 @@ practice generally do not replace, remove or >> overwrite files as it likely would break older checkouts or releases. >> Also all needed samples for a commit should be uploaded, ideally 24 >> hours, before the push. >> +If you need an account for frequently uploading samples or you wish to >> +help others do so send mail to ffmpeg-devel. Also please state if you >> +are available to help others upload samples if you request access. > > Probably I miss something. > > It is still not clear for someone need to help to upload a sample: who is the > contact person? > Should we update a new section with the name who can help others to upload, > or set-up/public a new mail list channel? The new samples-request@ mail alias should be mentioned somewhere, and maybe added to MAINTAINERS. Not sure if that is the right place to put it, though. -Thilo ___ 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] libavcodec: add timer bitstream filter [v2]
Hi Alexander, ‐‐‐ Original Message ‐‐‐ On Wednesday, 7 de August de 2019 10:01, Andreas Håkon wrote: > Hi Alexander, > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, 7 de August de 2019 0:24, Alexander Strasser eclip...@gmx.net > wrote: > > > Hi Andreas! > > On 2019-08-05 17:25 +, Andreas Håkon wrote: > > > > > On Monday, 5 de August de 2019 17:31, Moritz Barsnick barsn...@gmx.net > > > wrote: > > > > [...] > > > > Sorry for the noise. IIRC the naming was previously discussed. > > Can't remember the details right now. Unfortunately I don't have > > any good name suggestions too :( > > This is no objections, but at least to me the name timer sounds > > like some autonomous unit/process that can interrupt/call your > > process on defined/configured/subscribed intervals. Maybe it's > > just me... > > ...what do others think? > > It's nitial name was "retimer". After a suggestion I changed to "timer". > Other options can be "timestamp", "synchronizer", etc. > However, they're all a little vague. > > Therefore, I ask someone to present an appropriate name taking > into account the objective: shifting the PTS/DTS marks of a stream. > > You like "timeshift"? Check new version: https://patchwork.ffmpeg.org/patch/14302/ Regards. A.H. --- ___ 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] libavcodec: add timeshift bitstream filter [v3]
Hi,
This new version changes the name of the filter, and implements all suggestions.
Supersedes:
https://patchwork.ffmpeg.org/patch/14195/
https://patchwork.ffmpeg.org/patch/13743/
https://patchwork.ffmpeg.org/patch/13699/
Regards.
A.H.
---From 9e036e0a1dc20fd5c41686a48a5a0c2142f91de4 Mon Sep 17 00:00:00 2001
From: Andreas Hakon
Date: Wed, 7 Aug 2019 17:45:25 +0200
Subject: [PATCH] libavcodec: add timeshift bitstream filter [v3]
This implements the new timeshift bitstream filter.
Signed-off-by: Andreas Hakon
---
doc/bitstream_filters.texi | 11 +
libavcodec/Makefile|1 +
libavcodec/bitstream_filters.c |1 +
libavcodec/timeshift_bsf.c | 87
4 files changed, 100 insertions(+)
create mode 100644 libavcodec/timeshift_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 50a1679..f7fb0d4 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -644,6 +644,17 @@ codec) with metadata headers.
See also the @ref{mov2textsub} filter.
+@section timeshift
+
+Apply an offset to the PTS/DTS timestamps.
+
+@table @option
+@item offset
+The absolute offset value to apply to the PTS/DTS timestamps with a
+90kHz resolution.
+
+@end table
+
@section trace_headers
Log trace output containing all syntax elements in the coded stream
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fb..e929a99 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1096,6 +1096,7 @@ OBJS-$(CONFIG_NULL_BSF) += null_bsf.o
OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF) += remove_extradata_bsf.o
OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
+OBJS-$(CONFIG_TIMESHIFT_BSF) += timeshift_bsf.o
OBJS-$(CONFIG_TRACE_HEADERS_BSF) += trace_headers_bsf.o
OBJS-$(CONFIG_TRUEHD_CORE_BSF)+= truehd_core_bsf.o mlp_parse.o
mlp.o
OBJS-$(CONFIG_VP9_METADATA_BSF) += vp9_metadata_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 4630039..d728185 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -51,6 +51,7 @@ extern const AVBitStreamFilter ff_null_bsf;
extern const AVBitStreamFilter ff_prores_metadata_bsf;
extern const AVBitStreamFilter ff_remove_extradata_bsf;
extern const AVBitStreamFilter ff_text2movsub_bsf;
+extern const AVBitStreamFilter ff_timeshift_bsf;
extern const AVBitStreamFilter ff_trace_headers_bsf;
extern const AVBitStreamFilter ff_truehd_core_bsf;
extern const AVBitStreamFilter ff_vp9_metadata_bsf;
diff --git a/libavcodec/timeshift_bsf.c b/libavcodec/timeshift_bsf.c
new file mode 100644
index 000..1af9152
--- /dev/null
+++ b/libavcodec/timeshift_bsf.c
@@ -0,0 +1,87 @@
+/*
+ * 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
+ * This bitstream filter applies an offset to the PTS/DTS timestamps.
+ *
+ */
+
+#include "avcodec.h"
+#include "bsf.h"
+
+#include "libavutil/opt.h"
+
+#define FILTER_MAX_PTS 0x2 // (2^33)
+
+typedef struct TimeshiftContext {
+const AVClass *class;
+int offset;
+int first_debug_done;
+} TimeshiftContext;
+
+static int timeshift_filter(AVBSFContext *ctx, AVPacket *pkt)
+{
+int ret;
+TimeshiftContext *s = ctx->priv_data;
+int64_t opts,odts;
+
+ret = ff_bsf_get_packet_ref(ctx, pkt);
+if (ret < 0)
+return ret;
+
+opts = pkt->pts;
+if (pkt->pts != AV_NOPTS_VALUE) {
+pkt->pts += s->offset;
+pkt->pts &= FILTER_MAX_PTS;
+}
+odts = pkt->dts;
+if (pkt->dts != AV_NOPTS_VALUE) {
+pkt->dts += s->offset;
+pkt->pts &= FILTER_MAX_PTS;
+}
+
+if (!s->first_debug_done) {
+av_log(ctx, AV_LOG_DEBUG, "Updated PTS/DTS (%"PRId64"/%"PRId64" :
%"PRId64"/%"PRId64") with offset:%d\n",
+pkt->pts, pkt->dts, opts, odts, s->offset );
+s->first_debug_done = 1;
+}
+
+return 0;
+}
+
+#define OFFSET(x) offsetof(TimeshiftContext, x)
+#define FLAGS
(AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_SUBTITLE_PARAM|AV_OPT_FLAG_BSF_PARAM)
+static const AVOption options[] = {
+{ "offset", NULL,
[FFmpeg-devel] [PATCH v10 11/13] lavc/tiff: Decode 14-bit DNG images
From: Nick Renieris
Sample file:
https://drive.google.com/open?id=0B4JyRT3Lth5HVndyOTVOdWktM3J4TFEydTk1MnY3RWlpSzVB
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 8a671538aa..a40bcfb3d7 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -309,14 +309,18 @@ static void av_always_inline horizontal_fill(TiffContext
*s,
dst[(width+offset)*2+0] = (usePtr ? src[width] : c) >> 4;
}
break;
-case 12: {
- uint16_t *dst16 = (uint16_t *)dst;
- GetBitContext gb;
- init_get_bits8(, src, width);
- for (int i = 0; i < s->width; i++) {
- dst16[i] = get_bits(, 12) << 4;
- }
- }
+case 12:
+case 14: {
+uint16_t *dst16 = (uint16_t *)dst;
+int is_dng = (s->tiff_type == TIFF_TYPE_DNG || s->tiff_type ==
TIFF_TYPE_CINEMADNG);
+uint8_t shift = is_dng ? 0 : 16 - bpp;
+GetBitContext gb;
+
+init_get_bits8(, src, width);
+for (int i = 0; i < s->width; i++) {
+dst16[i] = get_bits(, bpp) << shift;
+}
+}
break;
default:
if (usePtr) {
@@ -1058,6 +1062,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
}
break;
case 10121:
+case 10141:
switch (AV_RL32(s->pattern)) {
case 0x02010100:
s->avctx->pix_fmt = s->le ? AV_PIX_FMT_BAYER_RGGB16LE :
AV_PIX_FMT_BAYER_RGGB16BE;
--
2.21.0.windows.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 v10 06/13] lavc/tiff: Fix edge case with full-length/width tiles
From: Nick Renieris In an image [1], the height was equal to the tile length (full-height tile) and after `height % tile_length` was applied to them with the current code, it resulted in the operating tile_length to be 0. This commit makes this leftover logic only applies if it's necessary. Signed-off-by: Nick Renieris --- libavcodec/tiff.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c index b6f626daca..f577639dfa 100644 --- a/libavcodec/tiff.c +++ b/libavcodec/tiff.c @@ -884,10 +884,14 @@ static int dng_decode_tiles(AVCodecContext *avctx, AVFrame *frame) int tile_byte_count_offset, tile_byte_count; int tile_count_x, tile_count_y; int tile_width, tile_length; +int has_width_leftover, has_height_leftover; int tile_x = 0, tile_y = 0; int pos_x = 0, pos_y = 0; int ret; +has_width_leftover = (s->width % s->tile_width != 0); +has_height_leftover = (s->height % s->tile_length != 0); + /* Calculate tile counts (round up) */ tile_count_x = (s->width + s->tile_width - 1) / s->tile_width; tile_count_y = (s->height + s->tile_length - 1) / s->tile_length; @@ -897,12 +901,12 @@ static int dng_decode_tiles(AVCodecContext *avctx, AVFrame *frame) tile_x = tile_idx % tile_count_x; tile_y = tile_idx / tile_count_x; -if (tile_x == tile_count_x - 1) // If on the right edge +if (has_width_leftover && tile_x == tile_count_x - 1) // If on the right-most tile tile_width = s->width % s->tile_width; else tile_width = s->tile_width; -if (tile_y == tile_count_y - 1) // If on the bottom edge +if (has_height_leftover && tile_y == tile_count_y - 1) // If on the bottom-most tile tile_length = s->height % s->tile_length; else tile_length = s->tile_length; -- 2.21.0.windows.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 v10 02/13] lavc/tiff: Decode embedded JPEGs in DNG images
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
[1]: As specified in the DNG Specification - Chapter 5
Signed-off-by: Nick Renieris
---
configure | 1 +
libavcodec/Makefile | 2 +-
libavcodec/tiff.c | 318 +++-
libavcodec/tiff.h | 2 +
4 files changed, 315 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 34c2adb4a4..112b84f0ba 100755
--- a/configure
+++ b/configure
@@ -2817,6 +2817,7 @@ tdsc_decoder_deps="zlib"
tdsc_decoder_select="mjpeg_decoder"
theora_decoder_select="vp3_decoder"
thp_decoder_select="mjpeg_decoder"
+tiff_decoder_select="mjpeg_decoder"
tiff_decoder_suggest="zlib lzma"
tiff_encoder_suggest="zlib"
truehd_decoder_select="mlp_parser"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fbcc6..f814c69996 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -616,7 +616,7 @@ OBJS-$(CONFIG_TARGA_ENCODER) += targaenc.o rle.o
OBJS-$(CONFIG_TARGA_Y216_DECODER) += targa_y216dec.o
OBJS-$(CONFIG_TDSC_DECODER)+= tdsc.o
OBJS-$(CONFIG_TIERTEXSEQVIDEO_DECODER) += tiertexseqv.o
-OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o faxcompr.o tiff_data.o
tiff_common.o
+OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o faxcompr.o tiff_data.o
tiff_common.o mjpegdec.o
OBJS-$(CONFIG_TIFF_ENCODER)+= tiffenc.o rle.o lzwenc.o tiff_data.o
OBJS-$(CONFIG_TMV_DECODER) += tmv.o cga_data.o
OBJS-$(CONFIG_TRUEHD_DECODER) += mlpdec.o mlpdsp.o
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c520d7df83..d1d2e15f45 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -35,6 +35,7 @@
#include "libavutil/attributes.h"
#include "libavutil/avstring.h"
+#include "libavutil/error.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/imgutils.h"
#include "libavutil/opt.h"
@@ -46,6 +47,7 @@
#include "mathops.h"
#include "tiff.h"
#include "tiff_data.h"
+#include "mjpegdec.h"
#include "thread.h"
#include "get_bits.h"
@@ -54,6 +56,10 @@ typedef struct TiffContext {
AVCodecContext *avctx;
GetByteContext gb;
+/* JPEG decoding for DNG */
+AVCodecContext *avctx_mjpeg; // wrapper context for MJPEG
+AVFrame *jpgframe; // decoded JPEG tile
+
int get_subimage;
uint16_t get_page;
int get_thumbnail;
@@ -76,7 +82,9 @@ typedef struct TiffContext {
int is_bayer;
uint8_t pattern[4];
+unsigned black_level;
unsigned white_level;
+const uint16_t *dng_lut; // Pointer to DNG linearization table
uint32_t sub_ifd;
uint16_t cur_page;
@@ -86,6 +94,14 @@ typedef struct TiffContext {
int stripsizesoff, stripsize, stripoff, strippos;
LZWState *lzw;
+/* Tile support */
+int is_tiled;
+int tile_byte_counts_offset, tile_offsets_offset;
+int tile_width, tile_length;
+int tile_count;
+
+int is_jpeg;
+
uint8_t *deinvert_buf;
int deinvert_buf_size;
uint8_t *yuv_line;
@@ -257,6 +273,9 @@ static int add_metadata(int count, int type,
};
}
+static void av_always_inline dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
+ const uint8_t *src, int src_stride, int
width, int height, int is_u16);
+
static void av_always_inline horizontal_fill(TiffContext *s,
unsigned int bpp, uint8_t* dst,
int usePtr, const uint8_t *src,
@@ -712,6 +731,204 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
return 0;
}
+/**
+ * Map stored raw sensor values into linear reference values.
+ * See: DNG Specification - Chapter 5
+ */
+static uint16_t av_always_inline dng_raw_to_linear16(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+// Lookup table lookup
+if (lut)
+value = lut[value];
+
+// Black level subtraction
+value = av_clip_uint16_c((unsigned)value - black_level);
+
+// Color scaling
+value = av_clip_uint16_c((unsigned)(((float)value * scale_factor) *
0x));
+
+return value;
+}
+
+static uint16_t av_always_inline dng_raw_to_linear8(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+return dng_raw_to_linear16(value, lut, black_level, scale_factor) >> 8;
+}
+
+static void dng_blit(TiffContext
[FFmpeg-devel] [PATCH v10 08/13] lavc/tiff: Force DNG pixel data endianness on an edge case
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 8db42d2bc5..7b9d7574c8 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1035,6 +1035,18 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
AV_RL32(s->pattern));
return AVERROR_PATCHWELCOME;
}
+/* Force endianness as mentioned in 'DNG Specification: Chapter 3:
BitsPerSample'
+NOTE: The spec actually specifies big-endian, not sure why we need
little-endian,
+ but such images don't work otherwise. */
+if ((s->tiff_type == TIFF_TYPE_DNG || s->tiff_type ==
TIFF_TYPE_CINEMADNG)
+&& (s->bpp != 8 && s->bpp != 16 && s->bpp != 32)) {
+switch (s->avctx->pix_fmt) {
+case AV_PIX_FMT_BAYER_RGGB16BE: s->avctx->pix_fmt =
AV_PIX_FMT_BAYER_RGGB16LE; break;
+case AV_PIX_FMT_BAYER_BGGR16BE: s->avctx->pix_fmt =
AV_PIX_FMT_BAYER_BGGR16LE; break;
+case AV_PIX_FMT_BAYER_GBRG16BE: s->avctx->pix_fmt =
AV_PIX_FMT_BAYER_GBRG16LE; break;
+case AV_PIX_FMT_BAYER_GRBG16BE: s->avctx->pix_fmt =
AV_PIX_FMT_BAYER_GRBG16LE; break;
+}
+}
break;
case 10161:
switch (AV_RL32(s->pattern)) {
--
2.21.0.windows.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 v10 12/13] lavc/mjpegdec: Skip useless APPx marker on bayer images
From: Nick Renieris
Samples:
- Embedded JPEG images in the DNG images here:
https://www.photographyblog.com/previews/pentax_k1_photos
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 94cf73549d..b3d6279853 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1810,8 +1810,15 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
int len, id, i;
len = get_bits(>gb, 16);
-if (len < 6)
-return AVERROR_INVALIDDATA;
+if (len < 6) {
+if (s->bayer) {
+// Pentax K-1 (digital camera) JPEG images embedded in DNG images
contain useless APP0 markers
+av_log(s->avctx, AV_LOG_WARNING, "skipping APPx (len=%"PRId32")
for bayer-encoded image\n", len);
+skip_bits(>gb, len);
+return 0;
+} else
+return AVERROR_INVALIDDATA;
+}
if (8 * len > get_bits_left(>gb))
return AVERROR_INVALIDDATA;
--
2.21.0.windows.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 v10 10/13] lavc/tiff: Support decoding of DNGs with single-component JPEGs
From: Nick Renieris
This enables decoding of DNG and CinemaDNG images generated by 'DJI Zenmuse X7'
Samples: https://www.dji.com/gr/zenmuse-x7/info#downloads
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 61 +++
1 file changed, 51 insertions(+), 10 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 7b9d7574c8..8a671538aa 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -274,7 +274,8 @@ static int add_metadata(int count, int type,
}
static void av_always_inline dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
- const uint8_t *src, int src_stride, int
width, int height, int is_u16);
+ const uint8_t *src, int src_stride, int
width, int height,
+ int is_single_comp, int is_u16);
static void av_always_inline horizontal_fill(TiffContext *s,
unsigned int bpp, uint8_t* dst,
@@ -695,6 +696,7 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
0, // no stride, only 1 line
width / pixel_size_bytes * pixel_size_bits / s->bpp,
// need to account for [1, 16] bpp
1,
+ 0, // single-component variation is only preset in
JPEG-encoded DNGs
is_u16);
}
@@ -792,18 +794,32 @@ static uint16_t av_always_inline
dng_process_color8(uint16_t value,
static void dng_blit(TiffContext *s, uint8_t *dst, int dst_stride,
const uint8_t *src, int src_stride,
- int width, int height, int is_u16)
+ int width, int height, int is_single_comp, int is_u16)
{
int line, col;
float scale_factor;
scale_factor = 1.0f / (s->white_level - s->black_level);
-if (is_u16) {
-for (line = 0; line < height; line++) {
+if (is_single_comp) {
+if (!is_u16)
+return; /* <= 8bpp unsupported */
+
+/* Image is double the width and half the height we need, each row
comprises 2 rows of the output
+ (split vertically in the middle). */
+for (line = 0; line < height / 2; line++) {
uint16_t *dst_u16 = (uint16_t *)dst;
uint16_t *src_u16 = (uint16_t *)src;
+/* Blit first half of input row row to initial row of output */
+for (col = 0; col < width; col++)
+*dst_u16++ = dng_process_color16(*src_u16++, s->dng_lut,
s->black_level, scale_factor);
+
+/* Advance the destination pointer by a row (source pointer
remains in the same place) */
+dst += dst_stride * sizeof(uint16_t);
+dst_u16 = (uint16_t *)dst;
+
+/* Blit second half of input row row to next row of output */
for (col = 0; col < width; col++)
*dst_u16++ = dng_process_color16(*src_u16++, s->dng_lut,
s->black_level, scale_factor);
@@ -811,12 +827,27 @@ static void dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
src += src_stride * sizeof(uint16_t);
}
} else {
-for (line = 0; line < height; line++) {
-for (col = 0; col < width; col++)
-*dst++ = dng_process_color8(*src++, s->dng_lut,
s->black_level, scale_factor);
+/* Input and output image are the same size and the MJpeg decoder has
done per-component
+ deinterleaving, so blitting here is straightforward. */
+if (is_u16) {
+for (line = 0; line < height; line++) {
+uint16_t *dst_u16 = (uint16_t *)dst;
+uint16_t *src_u16 = (uint16_t *)src;
+
+for (col = 0; col < width; col++)
+*dst_u16++ = dng_process_color16(*src_u16++, s->dng_lut,
s->black_level, scale_factor);
+
+dst += dst_stride * sizeof(uint16_t);
+src += src_stride * sizeof(uint16_t);
+}
+} else {
+for (line = 0; line < height; line++) {
+for (col = 0; col < width; col++)
+*dst++ = dng_process_color8(*src++, s->dng_lut,
s->black_level, scale_factor);
-dst += dst_stride;
-src += src_stride;
+dst += dst_stride;
+src += src_stride;
+}
}
}
}
@@ -828,7 +859,7 @@ static int dng_decode_jpeg_tile(AVCodecContext *avctx,
AVFrame *frame,
AVPacket jpkt;
uint8_t *dst_data, *src_data;
uint32_t dst_offset; /* offset from dst buffer in pixels */
-int is_u16, pixel_size;
+int is_single_comp, is_u16, pixel_size;
int ret;
/* Prepare a packet and send to the MJPEG decoder */
@@ -855,9 +886,18 @@ static int dng_decode_jpeg_tile(AVCodecContext *avctx,
AVFrame *frame,
/* Copy the outputted tile's pixels from 'jpgframe'
[FFmpeg-devel] [PATCH v10 09/13] lavc/mjpegdec: Enable decoding of single-component bayer images
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 6391107f78..94cf73549d 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -412,13 +412,21 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return AVERROR_PATCHWELCOME;
}
-/* Lossless JPEGs encoded in DNGs are commonly bayer-encoded. They contain
2
- interleaved components and the width stored in their SOF3 markers is the
- width of each one. We only output a single component, therefore we need
- to adjust the output image width. */
-if (s->lossless == 1 && nb_components == 2) {
-s->bayer = 1;
-width *= 2;
+/* Lossless JPEGs encoded in DNGs are commonly bayer-encoded. */
+if (s->lossless) {
+if (nb_components == 1) {
+/* They can contain 1 component, which is double the width and
half the height
+ of the final image (rows are interleaved). We don't handle the
decoding in
+ this file, but leave that to the DNG decoder. */
+s->bayer = 1;
+} else if (nb_components == 2) {
+/* Or they can contain 2 interleaved components and the width
stored in their
+ SOF3 markers is the width of each one. We only output a single
component,
+ therefore we need to adjust the output image width. We handle
the
+ deinterleaving (but not the debayering) in this file. */
+s->bayer = 1;
+width *= 2;
+}
}
/* if different size, realloc/alloc picture */
@@ -1184,10 +1192,15 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
ptr[3*mb_x + 0] = buffer[mb_x][1] + ptr[3*mb_x + 1];
ptr[3*mb_x + 2] = buffer[mb_x][2] + ptr[3*mb_x + 1];
}
-} else if (s->bayer && nb_components == 2) {
-for (mb_x = 0; mb_x < width; mb_x++) {
-((uint16_t*)ptr)[2*mb_x + 0] = buffer[mb_x][0];
-((uint16_t*)ptr)[2*mb_x + 1] = buffer[mb_x][1];
+} else if (s->bayer) {
+if (nb_components == 1) {
+for (mb_x = 0; mb_x < width; mb_x++)
+((uint16_t*)ptr)[mb_x] = buffer[mb_x][0];
+} else if (nb_components == 2) {
+for (mb_x = 0; mb_x < width; mb_x++) {
+((uint16_t*)ptr)[2*mb_x + 0] = buffer[mb_x][0];
+((uint16_t*)ptr)[2*mb_x + 1] = buffer[mb_x][1];
+}
}
} else {
for(i=0; ihttps://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v10 04/13] lavc/tiff: Apply color scaling to uncompressed DNGs
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c7e2adb3ae..b6f626daca 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -679,6 +679,25 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
for (i = 0; i < width; i++)
dst[i] = ff_reverse[src[i]];
}
+
+/* Color processing for DNG images with uncompressed strips
(non-tiled) */
+if (is_dng) {
+int is_u16, pixel_size_bytes, pixel_size_bits;
+
+is_u16 = (s->bpp > 8);
+pixel_size_bits = (is_u16 ? 16 : 8);
+pixel_size_bytes = (is_u16 ? sizeof(uint16_t) :
sizeof(uint8_t));
+
+dng_blit(s,
+ dst,
+ 0, // no stride, only 1 line
+ dst,
+ 0, // no stride, only 1 line
+ width / pixel_size_bytes * pixel_size_bits / s->bpp,
// need to account for [1, 16] bpp
+ 1,
+ is_u16);
+}
+
src += width;
break;
case TIFF_PACKBITS:
@@ -1950,7 +1969,8 @@ again:
FFSWAP(int, p->linesize[0], p->linesize[1]);
}
-if (s->is_bayer && s->white_level && s->bpp == 16) {
+if (s->is_bayer && s->white_level && s->bpp == 16 &&
+!(s->tiff_type == TIFF_TYPE_DNG || s->tiff_type ==
TIFF_TYPE_CINEMADNG)) {
uint16_t *dst = (uint16_t *)p->data[0];
for (i = 0; i < s->height; i++) {
for (j = 0; j < s->width; j++)
--
2.21.0.windows.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 v10 03/13] lavc/tiff: Convert DNGs to sRGB color space
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index d1d2e15f45..c7e2adb3ae 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -731,14 +731,23 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
return 0;
}
+static float av_always_inline linear_to_srgb(float value) {
+if (value <= 0.0031308)
+return value * 12.92;
+else
+return pow(value * 1.055, 1.0 / 2.4) - 0.055;
+}
+
/**
- * Map stored raw sensor values into linear reference values.
- * See: DNG Specification - Chapter 5
+ * Map stored raw sensor values into linear reference values (see: DNG
Specification - Chapter 5)
+ * Then convert to sRGB color space.
*/
-static uint16_t av_always_inline dng_raw_to_linear16(uint16_t value,
-const uint16_t *lut,
-uint16_t black_level,
-float scale_factor) {
+static uint16_t av_always_inline dng_process_color16(uint16_t value,
+ const uint16_t *lut,
+ uint16_t black_level,
+ float scale_factor) {
+float value_norm;
+
// Lookup table lookup
if (lut)
value = lut[value];
@@ -747,16 +756,19 @@ static uint16_t av_always_inline
dng_raw_to_linear16(uint16_t value,
value = av_clip_uint16_c((unsigned)value - black_level);
// Color scaling
-value = av_clip_uint16_c((unsigned)(((float)value * scale_factor) *
0x));
+value_norm = (float)value * scale_factor;
+
+// Color space conversion (sRGB)
+value = av_clip_uint16_c((uint16_t)(linear_to_srgb(value_norm) * 0x));
return value;
}
-static uint16_t av_always_inline dng_raw_to_linear8(uint16_t value,
+static uint16_t av_always_inline dng_process_color8(uint16_t value,
const uint16_t *lut,
uint16_t black_level,
float scale_factor) {
-return dng_raw_to_linear16(value, lut, black_level, scale_factor) >> 8;
+return dng_process_color16(value, lut, black_level, scale_factor) >> 8;
}
static void dng_blit(TiffContext *s, uint8_t *dst, int dst_stride,
@@ -774,7 +786,7 @@ static void dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
uint16_t *src_u16 = (uint16_t *)src;
for (col = 0; col < width; col++)
-*dst_u16++ = dng_raw_to_linear16(*src_u16++, s->dng_lut,
s->black_level, scale_factor);
+*dst_u16++ = dng_process_color16(*src_u16++, s->dng_lut,
s->black_level, scale_factor);
dst += dst_stride * sizeof(uint16_t);
src += src_stride * sizeof(uint16_t);
@@ -782,7 +794,7 @@ static void dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
} else {
for (line = 0; line < height; line++) {
for (col = 0; col < width; col++)
-*dst++ = dng_raw_to_linear8(*src++, s->dng_lut,
s->black_level, scale_factor);
+*dst++ = dng_process_color8(*src++, s->dng_lut,
s->black_level, scale_factor);
dst += dst_stride;
src += src_stride;
--
2.21.0.windows.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 v10 07/13] lavc/tiff: Don't apply strips-related logic to tiled images
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index f577639dfa..8db42d2bc5 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1780,7 +1780,7 @@ again:
}
}
-if (!s->strippos && !s->stripoff) {
+if (!s->is_tiled && !s->strippos && !s->stripoff) {
av_log(avctx, AV_LOG_ERROR, "Image data is missing\n");
return AVERROR_INVALIDDATA;
}
@@ -1788,27 +1788,29 @@ again:
if ((ret = init_image(s, )) < 0)
return ret;
-if (s->strips == 1 && !s->stripsize) {
-av_log(avctx, AV_LOG_WARNING, "Image data size missing\n");
-s->stripsize = avpkt->size - s->stripoff;
-}
+if (!s->is_tiled) {
+if (s->strips == 1 && !s->stripsize) {
+av_log(avctx, AV_LOG_WARNING, "Image data size missing\n");
+s->stripsize = avpkt->size - s->stripoff;
+}
-if (s->stripsizesoff) {
-if (s->stripsizesoff >= (unsigned)avpkt->size)
-return AVERROR_INVALIDDATA;
-bytestream2_init(, avpkt->data + s->stripsizesoff,
- avpkt->size - s->stripsizesoff);
-}
-if (s->strippos) {
-if (s->strippos >= (unsigned)avpkt->size)
-return AVERROR_INVALIDDATA;
-bytestream2_init(, avpkt->data + s->strippos,
- avpkt->size - s->strippos);
-}
+if (s->stripsizesoff) {
+if (s->stripsizesoff >= (unsigned)avpkt->size)
+return AVERROR_INVALIDDATA;
+bytestream2_init(, avpkt->data + s->stripsizesoff,
+avpkt->size - s->stripsizesoff);
+}
+if (s->strippos) {
+if (s->strippos >= (unsigned)avpkt->size)
+return AVERROR_INVALIDDATA;
+bytestream2_init(, avpkt->data + s->strippos,
+avpkt->size - s->strippos);
+}
-if (s->rps <= 0 || s->rps % s->subsampling[1]) {
-av_log(avctx, AV_LOG_ERROR, "rps %d invalid\n", s->rps);
-return AVERROR_INVALIDDATA;
+if (s->rps <= 0 || s->rps % s->subsampling[1]) {
+av_log(avctx, AV_LOG_ERROR, "rps %d invalid\n", s->rps);
+return AVERROR_INVALIDDATA;
+}
}
/* Handle DNG images with JPEG-compressed tiles */
--
2.21.0.windows.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 v10 05/13] lavc/jpegtables: Handle multiple mappings to the same value
From: Nick Renieris
Some JPEGs [1] have incorrect DHT entries that map 2 codes to
the same value.
The second (last) mapping does not ever actually appear in the
code stream, therefore ignoring any mappings after the first one
fixes this.
Without this, an "mjpeg_decode_dc: bad vlc: 0:0" error is thrown.
---
[1]: Embedded JPEGs in "X7 RAW" and "X7 CinemaDNG" samples here:
https://www.dji.com/gr/zenmuse-x7/info#downloads
Signed-off-by: Nick Renieris
---
libavcodec/jpegtables.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/libavcodec/jpegtables.c b/libavcodec/jpegtables.c
index cbe5523cb4..6f596cfc92 100644
--- a/libavcodec/jpegtables.c
+++ b/libavcodec/jpegtables.c
@@ -130,14 +130,27 @@ void ff_mjpeg_build_huffman_codes(uint8_t *huff_size,
uint16_t *huff_code,
{
int i, j, k,nb, code, sym;
-code = 0;
+/* Zero-initialize huff_size (needed for multiple mappings check below) */
+k = 0;
+for(i=1;i<=16;i++) {
+nb = bits_table[i];
+for(j=0;jhttps://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v10 01/13] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs without issues.
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 52 +--
libavcodec/mjpegdec.h | 1 +
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index a65bc8df15..6391107f78 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -412,6 +412,14 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return AVERROR_PATCHWELCOME;
}
+/* Lossless JPEGs encoded in DNGs are commonly bayer-encoded. They contain
2
+ interleaved components and the width stored in their SOF3 markers is the
+ width of each one. We only output a single component, therefore we need
+ to adjust the output image width. */
+if (s->lossless == 1 && nb_components == 2) {
+s->bayer = 1;
+width *= 2;
+}
/* if different size, realloc/alloc picture */
if (width != s->width || height != s->height || bits != s->bits ||
@@ -488,6 +496,9 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
switch (pix_fmt_id) {
+case 0x: /* for bayer-encoded huffman lossless JPEGs embedded
in DNGs */
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+break;
case 0x1100:
if (s->rgb)
s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
@@ -1041,17 +1052,20 @@ static int handle_rstn(MJpegDecodeContext *s, int
nb_components)
return reset;
}
+/* Handles 1 to 4 components */
static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s, int nb_components, int
predictor, int point_transform)
{
int i, mb_x, mb_y;
+unsigned width;
uint16_t (*buffer)[4];
int left[4], top[4], topleft[4];
const int linesize = s->linesize[0];
const int mask = ((1 << s->bits) - 1) << point_transform;
int resync_mb_y = 0;
int resync_mb_x = 0;
+int vpred[6];
-if (s->nb_components != 3 && s->nb_components != 4)
+if (s->nb_components <= 0 || s->nb_components > 4)
return AVERROR_INVALIDDATA;
if (s->v_max != 1 || s->h_max != 1 || !s->lossless)
return AVERROR_INVALIDDATA;
@@ -1059,8 +1073,15 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
s->restart_count = s->restart_interval;
-av_fast_malloc(>ljpeg_buffer, >ljpeg_buffer_size,
- (unsigned)s->mb_width * 4 * sizeof(s->ljpeg_buffer[0][0]));
+if (s->restart_interval == 0)
+s->restart_interval = INT_MAX;
+
+if (s->bayer)
+width = s->mb_width / nb_components; /* Interleaved, width stored is
the total so need to divide */
+else
+width = s->mb_width;
+
+av_fast_malloc(>ljpeg_buffer, >ljpeg_buffer_size, width * 4 *
sizeof(s->ljpeg_buffer[0][0]));
if (!s->ljpeg_buffer)
return AVERROR(ENOMEM);
@@ -1078,7 +1099,12 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
for (i = 0; i < 4; i++)
top[i] = left[i] = topleft[i] = buffer[0][i];
-for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
+if ((mb_y * s->width) % s->restart_interval == 0) {
+for (i = 0; i < 6; i++)
+vpred[i] = 1 << (s->bits-1);
+}
+
+for (mb_x = 0; mb_x < width; mb_x++) {
int modified_predictor = predictor;
if (get_bits_left(>gb) < 1) {
@@ -1102,12 +1128,19 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
topleft[i] = top[i];
top[i] = buffer[mb_x][i];
-PREDICT(pred, topleft[i], top[i], left[i], modified_predictor);
-
dc = mjpeg_decode_dc(s, s->dc_index[i]);
if(dc == 0xF)
return -1;
+if (!s->bayer || mb_x) {
+pred = left[i];
+} else { /* This path runs only for the first line in bayer
images */
+vpred[i] += dc;
+pred = vpred[i] - dc;
+}
+
+PREDICT(pred, topleft[i], top[i], pred, modified_predictor);
+
left[i] = buffer[mb_x][i] =
mask & (pred + (unsigned)(dc * (1 << point_transform)));
}
@@ -1151,6 +1184,11 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
ptr[3*mb_x + 0] = buffer[mb_x][1] + ptr[3*mb_x + 1];
ptr[3*mb_x + 2] = buffer[mb_x][2] + ptr[3*mb_x + 1];
}
+} else if (s->bayer && nb_components == 2) {
+for (mb_x = 0; mb_x < width;
[FFmpeg-devel] [PATCH v10 13/13] lavc/tiff: Support DNGs with striped (non-tiled) JPEGs images
From: Nick Renieris
DNG samples here can now be decoded:
- https://www.photographyblog.com/previews/pentax_k1_photos
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 79 +++
1 file changed, 45 insertions(+), 34 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index a40bcfb3d7..47140cddbc 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -550,6 +550,8 @@ static int tiff_unpack_fax(TiffContext *s, uint8_t *dst,
int stride,
return ret;
}
+static int dng_decode_strip(AVCodecContext *avctx, AVFrame *frame);
+
static int tiff_unpack_strip(TiffContext *s, AVFrame *p, uint8_t *dst, int
stride,
const uint8_t *src, int size, int strip_start,
int lines)
{
@@ -561,6 +563,7 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
int is_yuv = !(desc->flags & AV_PIX_FMT_FLAG_RGB) &&
(desc->flags & AV_PIX_FMT_FLAG_PLANAR) &&
desc->nb_components >= 3;
+int is_dng;
if (s->planar)
width /= s->bppcount;
@@ -662,6 +665,19 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
bytestream2_init(>gb, src, size);
bytestream2_init_writer(, dst, is_yuv ? s->yuv_line_size : (stride *
lines));
+is_dng = (s->tiff_type == TIFF_TYPE_DNG || s->tiff_type ==
TIFF_TYPE_CINEMADNG);
+
+/* Decode JPEG-encoded DNGs with strips */
+if (s->compr == TIFF_NEWJPEG && is_dng) {
+if (s->strips > 1) {
+av_log(s->avctx, AV_LOG_ERROR, "More than one DNG JPEG strips
unsupported\n");
+return AVERROR_PATCHWELCOME;
+}
+if ((ret = dng_decode_strip(s->avctx, p)) < 0)
+return ret;
+return 0;
+}
+
for (line = 0; line < lines; line++) {
if (src - ssrc > size) {
av_log(s->avctx, AV_LOG_ERROR, "Source data overread\n");
@@ -856,8 +872,8 @@ static void dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
}
}
-static int dng_decode_jpeg_tile(AVCodecContext *avctx, AVFrame *frame,
-int tile_byte_count, int x, int y, int w, int
h)
+static int dng_decode_jpeg(AVCodecContext *avctx, AVFrame *frame,
+ int tile_byte_count, int dst_x, int dst_y, int w,
int h)
{
TiffContext *s = avctx->priv_data;
AVPacket jpkt;
@@ -902,7 +918,7 @@ static int dng_decode_jpeg_tile(AVCodecContext *avctx,
AVFrame *frame,
return AVERROR_PATCHWELCOME;
}
-dst_offset = x + frame->linesize[0] * y / pixel_size;
+dst_offset = dst_x + frame->linesize[0] * dst_y / pixel_size;
dst_data = frame->data[0] + dst_offset * pixel_size;
src_data = s->jpgframe->data[0];
@@ -921,7 +937,7 @@ static int dng_decode_jpeg_tile(AVCodecContext *avctx,
AVFrame *frame,
return 0;
}
-static int dng_decode_tiles(AVCodecContext *avctx, AVFrame *frame)
+static int dng_decode_tiles(AVCodecContext *avctx, AVFrame *frame, AVPacket
*avpkt)
{
TiffContext *s = avctx->priv_data;
int tile_idx;
@@ -934,6 +950,12 @@ static int dng_decode_tiles(AVCodecContext *avctx, AVFrame
*frame)
int pos_x = 0, pos_y = 0;
int ret;
+s->jpgframe->width = s->tile_width;
+s->jpgframe->height = s->tile_length;
+
+s->avctx_mjpeg->width = s->tile_width;
+s->avctx_mjpeg->height = s->tile_length;
+
has_width_leftover = (s->width % s->tile_width != 0);
has_height_leftover = (s->height % s->tile_length != 0);
@@ -970,7 +992,7 @@ static int dng_decode_tiles(AVCodecContext *avctx, AVFrame
*frame)
bytestream2_seek(>gb, tile_offset, SEEK_SET);
/* Decode JPEG tile and copy it in the reference frame */
-ret = dng_decode_jpeg_tile(avctx, frame, tile_byte_count, pos_x,
pos_y, tile_width, tile_length);
+ret = dng_decode_jpeg(avctx, frame, tile_byte_count, pos_x, pos_y,
tile_width, tile_length);
if (ret < 0)
return ret;
@@ -983,30 +1005,24 @@ static int dng_decode_tiles(AVCodecContext *avctx,
AVFrame *frame)
}
}
-return 0;
-}
+/* Frame is ready to be output */
+frame->pict_type = AV_PICTURE_TYPE_I;
+frame->key_frame = 1;
-static int dng_decode(AVCodecContext *avctx, AVFrame *frame, AVPacket *avpkt) {
-int ret;
+return avpkt->size;
+}
+static int dng_decode_strip(AVCodecContext *avctx, AVFrame *frame)
+{
TiffContext *s = avctx->priv_data;
-s->jpgframe->width = s->tile_width;
-s->jpgframe->height = s->tile_length;
-
-s->avctx_mjpeg->width = s->tile_width;
-s->avctx_mjpeg->height = s->tile_length;
+s->jpgframe->width = s->width;
+s->jpgframe->height = s->height;
-/* Decode all tiles in a frame */
-ret = dng_decode_tiles(avctx, frame);
-if (ret < 0)
-return ret;
+s->avctx_mjpeg->width = s->width;
+s->avctx_mjpeg->height = s->height;
-/* Frame is ready to be output */
Re: [FFmpeg-devel] [PATCH v9 1/2] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
Going to post a new patchset with my latest work. It includes these 2 commits (one slightly modified) and 11 more. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Paul B Mahol > Sent: Wednesday, August 7, 2019 22:36 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add > support for QSV transpose filter" > > On Wed, Aug 7, 2019 at 4:34 PM Li, Zhong wrote: > > > > From: Nicolas George [mailto:geo...@nsup.org] > > > Sent: Wednesday, August 7, 2019 10:31 PM > > > To: FFmpeg development discussions and patches > > > > > > Cc: Li, Zhong > > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add > > > support for QSV transpose filter" > > > > > > Zhong Li (12019-08-07): > > > > This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e. > > > > > > > > Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi" > > > > > > The damage to the git log is done, this will just make it worse, IMHO. > > > > > > Regards, > > > > > > -- > > > Nicolas George > > > > So your suggestion should be: just keep it and do nothing now? > > > Please do nothing now, please do not forget it for next time, what is lavf > and what is lavfi. Thanks, will keep it in mind. ___ 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] doc/fate: Document how to request samples upload access
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Tuesday, August 6, 2019 1:07 AM > To: FFmpeg development discussions and patches > > Subject: [FFmpeg-devel] [PATCH] doc/fate: Document how to request > samples upload access > > Signed-off-by: Michael Niedermayer > --- > doc/fate.texi | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/fate.texi b/doc/fate.texi index 2be61d639c..e04fbfbe43 > 100644 > --- a/doc/fate.texi > +++ b/doc/fate.texi > @@ -157,6 +157,9 @@ practice generally do not replace, remove or > overwrite files as it likely would break older checkouts or releases. > Also all needed samples for a commit should be uploaded, ideally 24 > hours, before the push. > +If you need an account for frequently uploading samples or you wish to > +help others do so send mail to ffmpeg-devel. Also please state if you > +are available to help others upload samples if you request access. Probably I miss something. It is still not clear for someone need to help to upload a sample: who is the contact person? Should we update a new section with the name who can help others to upload, or set-up/public a new mail list channel? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Paul B Mahol > Sent: Wednesday, August 7, 2019 10:36 PM > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add > support for QSV transpose filter" > > On Wed, Aug 7, 2019 at 4:34 PM Li, Zhong wrote: > > > > From: Nicolas George [mailto:geo...@nsup.org] > > > Sent: Wednesday, August 7, 2019 10:31 PM > > > To: FFmpeg development discussions and patches > > > > > > Cc: Li, Zhong > > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add > > > support for QSV transpose filter" > > > > > > Zhong Li (12019-08-07): > > > > This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e. > > > > > > > > Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi" > > > > > > The damage to the git log is done, this will just make it worse, IMHO. > > > > > > Regards, > > > > > > -- > > > Nicolas George > > > > So your suggestion should be: just keep it and do nothing now? > > > Please do nothing now, please do not forget it for next time, what is lavf and > what is lavfi. Thanks for remind. Will take care of it next time. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"
On Wed, Aug 7, 2019 at 4:34 PM Li, Zhong wrote: > > From: Nicolas George [mailto:geo...@nsup.org] > > Sent: Wednesday, August 7, 2019 10:31 PM > > To: FFmpeg development discussions and patches > > > > Cc: Li, Zhong > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add > > support for QSV transpose filter" > > > > Zhong Li (12019-08-07): > > > This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e. > > > > > > Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi" > > > > The damage to the git log is done, this will just make it worse, IMHO. > > > > Regards, > > > > -- > > Nicolas George > > So your suggestion should be: just keep it and do nothing now? Please do nothing now, please do not forget it for next time, what is lavf and what is lavfi. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"
On Wed, Aug 7, 2019 at 4:31 PM Nicolas George wrote: > Zhong Li (12019-08-07): > > This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e. > > > > Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi" > > The damage to the git log is done, this will just make it worse, IMHO. > Yes, completely agree. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"
> From: Nicolas George [mailto:geo...@nsup.org] > Sent: Wednesday, August 7, 2019 10:31 PM > To: FFmpeg development discussions and patches > > Cc: Li, Zhong > Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add > support for QSV transpose filter" > > Zhong Li (12019-08-07): > > This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e. > > > > Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi" > > The damage to the git log is done, this will just make it worse, IMHO. > > Regards, > > -- > Nicolas George So your suggestion should be: just keep it and do nothing now? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for QSV transpose filter
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Paul B Mahol > Sent: Wednesday, August 7, 2019 10:08 PM > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for > QSV transpose filter > > Applied with updated commit message to remove the limitation > > description, since > > https://github.com/Intel-Media-SDK/MediaSDK/pull/1491 has been > merged. > > > Please revert, lavf stand for libavformat. > You need lavfi, as that stand for libavfilter. Sorry for the incaution. Revert patch has been sent and will merge soon. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"
Zhong Li (12019-08-07): > This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e. > > Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi" The damage to the git log is done, this will just make it worse, IMHO. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] lavfi/vf_vpp_qsv: add support for QSV transpose filter
From: Linjie Fu
Add transpose support for qsv_vpp with rotate and hflip:
- rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
- hflip: [0, 1] support horizontal flip;
Configure with:
{"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}
CMD:
ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
-vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv output.h264
ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv -i input.h264
-vf 'hwupload=extra_hw_frames=64,format=qsv,vpp_qsv=transpose=cclock_hflip'
-f rawvideo -pix_fmt nv12 ./transpose.yuv
Signed-off-by: Linjie Fu
Signed-off-by: Zhong Li
---
libavfilter/vf_vpp_qsv.c | 101 ++-
1 file changed, 99 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index 915cf74..f185133 100644
--- a/libavfilter/vf_vpp_qsv.c
+++ b/libavfilter/vf_vpp_qsv.c
@@ -36,12 +36,15 @@
#include "libavformat/avformat.h"
#include "qsvvpp.h"
+#include "transpose.h"
#define OFFSET(x) offsetof(VPPContext, x)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
/* number of video enhancement filters */
-#define ENH_FILTERS_COUNT (5)
+#define ENH_FILTERS_COUNT (7)
+#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
+#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
typedef struct VPPContext{
const AVClass *class;
@@ -54,6 +57,8 @@ typedef struct VPPContext{
mfxExtVPPDenoise denoise_conf;
mfxExtVPPDetail detail_conf;
mfxExtVPPProcAmp procamp_conf;
+mfxExtVPPRotation rotation_conf;
+mfxExtVPPMirroring mirroring_conf;
int out_width;
int out_height;
@@ -74,6 +79,10 @@ typedef struct VPPContext{
int crop_x;
int crop_y;
+int transpose;
+int rotate; /* rotate angle : [0, 90, 180, 270] */
+int hflip; /* flip mode : 0 = off, 1 = HORIZONTAL flip */
+
/* param for the procamp */
intprocamp;/* enable procamp */
float hue;
@@ -100,6 +109,15 @@ static const AVOption options[] = {
{ "contrast","ProcAmp contrast", OFFSET(contrast),
AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0, 10.0, .flags = FLAGS},
{ "brightness", "ProcAmp brightness", OFFSET(brightness),
AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0, 100.0, .flags = FLAGS},
+{ "transpose", "set transpose direction", OFFSET(transpose),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 6, FLAGS, "transpose"},
+{ "cclock_hflip", "rotate counter-clockwise with horizontal flip",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK_FLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "clock", "rotate clockwise",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK }, .flags=FLAGS, .unit =
"transpose" },
+{ "cclock","rotate counter-clockwise",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK }, .flags=FLAGS, .unit =
"transpose" },
+{ "clock_hflip", "rotate clockwise with horizontal flip",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK_FLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "reversal", "rotate by half-turn",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_REVERSAL}, .flags=FLAGS, .unit =
"transpose" },
+{ "hflip", "flip horizontally",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_HFLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "vflip", "flip vertically",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_VFLIP }, .flags=FLAGS, .unit =
"transpose" },
+
{ "cw", "set the width crop area expression", OFFSET(cw),
AV_OPT_TYPE_STRING, { .str = "iw" }, CHAR_MIN, CHAR_MAX, FLAGS },
{ "ch", "set the height crop area expression", OFFSET(ch),
AV_OPT_TYPE_STRING, { .str = "ih" }, CHAR_MIN, CHAR_MAX, FLAGS },
{ "cx", "set the x crop area expression", OFFSET(cx),
AV_OPT_TYPE_STRING, { .str = "(in_w-out_w)/2" }, CHAR_MIN, CHAR_MAX, FLAGS },
@@ -356,8 +374,87 @@ static int config_output(AVFilterLink *outlink)
param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)>procamp_conf;
}
+if (vpp->transpose >= 0) {
+#ifdef QSV_HAVE_ROTATION
+switch (vpp->transpose) {
+case TRANSPOSE_CCLOCK_FLIP:
+vpp->rotate = MFX_ANGLE_270;
+vpp->hflip = MFX_MIRRORING_HORIZONTAL;
+break;
+case TRANSPOSE_CLOCK:
+vpp->rotate = MFX_ANGLE_90;
+vpp->hflip = MFX_MIRRORING_DISABLED;
+break;
+case TRANSPOSE_CCLOCK:
+vpp->rotate = MFX_ANGLE_270;
+vpp->hflip = MFX_MIRRORING_DISABLED;
+break;
+case TRANSPOSE_CLOCK_FLIP:
+vpp->rotate = MFX_ANGLE_90;
+
[FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"
This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e.
Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi"
---
libavfilter/vf_vpp_qsv.c | 101 +--
1 file changed, 2 insertions(+), 99 deletions(-)
diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index f185133..915cf74 100644
--- a/libavfilter/vf_vpp_qsv.c
+++ b/libavfilter/vf_vpp_qsv.c
@@ -36,15 +36,12 @@
#include "libavformat/avformat.h"
#include "qsvvpp.h"
-#include "transpose.h"
#define OFFSET(x) offsetof(VPPContext, x)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
/* number of video enhancement filters */
-#define ENH_FILTERS_COUNT (7)
-#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
-#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
+#define ENH_FILTERS_COUNT (5)
typedef struct VPPContext{
const AVClass *class;
@@ -57,8 +54,6 @@ typedef struct VPPContext{
mfxExtVPPDenoise denoise_conf;
mfxExtVPPDetail detail_conf;
mfxExtVPPProcAmp procamp_conf;
-mfxExtVPPRotation rotation_conf;
-mfxExtVPPMirroring mirroring_conf;
int out_width;
int out_height;
@@ -79,10 +74,6 @@ typedef struct VPPContext{
int crop_x;
int crop_y;
-int transpose;
-int rotate; /* rotate angle : [0, 90, 180, 270] */
-int hflip; /* flip mode : 0 = off, 1 = HORIZONTAL flip */
-
/* param for the procamp */
intprocamp;/* enable procamp */
float hue;
@@ -109,15 +100,6 @@ static const AVOption options[] = {
{ "contrast","ProcAmp contrast", OFFSET(contrast),
AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0, 10.0, .flags = FLAGS},
{ "brightness", "ProcAmp brightness", OFFSET(brightness),
AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0, 100.0, .flags = FLAGS},
-{ "transpose", "set transpose direction", OFFSET(transpose),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 6, FLAGS, "transpose"},
-{ "cclock_hflip", "rotate counter-clockwise with horizontal flip",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK_FLIP }, .flags=FLAGS, .unit =
"transpose" },
-{ "clock", "rotate clockwise",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK }, .flags=FLAGS, .unit =
"transpose" },
-{ "cclock","rotate counter-clockwise",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK }, .flags=FLAGS, .unit =
"transpose" },
-{ "clock_hflip", "rotate clockwise with horizontal flip",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK_FLIP }, .flags=FLAGS, .unit =
"transpose" },
-{ "reversal", "rotate by half-turn",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_REVERSAL}, .flags=FLAGS, .unit =
"transpose" },
-{ "hflip", "flip horizontally",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_HFLIP }, .flags=FLAGS, .unit =
"transpose" },
-{ "vflip", "flip vertically",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_VFLIP }, .flags=FLAGS, .unit =
"transpose" },
-
{ "cw", "set the width crop area expression", OFFSET(cw),
AV_OPT_TYPE_STRING, { .str = "iw" }, CHAR_MIN, CHAR_MAX, FLAGS },
{ "ch", "set the height crop area expression", OFFSET(ch),
AV_OPT_TYPE_STRING, { .str = "ih" }, CHAR_MIN, CHAR_MAX, FLAGS },
{ "cx", "set the x crop area expression", OFFSET(cx),
AV_OPT_TYPE_STRING, { .str = "(in_w-out_w)/2" }, CHAR_MIN, CHAR_MAX, FLAGS },
@@ -374,87 +356,8 @@ static int config_output(AVFilterLink *outlink)
param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)>procamp_conf;
}
-if (vpp->transpose >= 0) {
-#ifdef QSV_HAVE_ROTATION
-switch (vpp->transpose) {
-case TRANSPOSE_CCLOCK_FLIP:
-vpp->rotate = MFX_ANGLE_270;
-vpp->hflip = MFX_MIRRORING_HORIZONTAL;
-break;
-case TRANSPOSE_CLOCK:
-vpp->rotate = MFX_ANGLE_90;
-vpp->hflip = MFX_MIRRORING_DISABLED;
-break;
-case TRANSPOSE_CCLOCK:
-vpp->rotate = MFX_ANGLE_270;
-vpp->hflip = MFX_MIRRORING_DISABLED;
-break;
-case TRANSPOSE_CLOCK_FLIP:
-vpp->rotate = MFX_ANGLE_90;
-vpp->hflip = MFX_MIRRORING_HORIZONTAL;
-break;
-case TRANSPOSE_REVERSAL:
-vpp->rotate = MFX_ANGLE_180;
-vpp->hflip = MFX_MIRRORING_DISABLED;
-break;
-case TRANSPOSE_HFLIP:
-vpp->rotate = MFX_ANGLE_0;
-vpp->hflip = MFX_MIRRORING_HORIZONTAL;
-break;
-case TRANSPOSE_VFLIP:
-vpp->rotate = MFX_ANGLE_180;
-vpp->hflip = MFX_MIRRORING_HORIZONTAL;
-break;
-default:
-av_log(ctx, AV_LOG_ERROR,
Re: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for QSV transpose filter
On Wed, Aug 7, 2019 at 4:04 PM Li, Zhong wrote:
> > From: Fu, Linjie
> > Sent: Monday, July 15, 2019 12:30 PM
> > To: Li, Zhong ; FFmpeg development discussions and
> > patches
> > Subject: RE: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> > QSV transpose filter
> >
> > > -Original Message-
> > > From: Li, Zhong
> > > Sent: Sunday, July 14, 2019 19:33
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Cc: Fu, Linjie
> > > Subject: RE: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support
> > > for QSV transpose filter
> > >
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf
> > > > Of Linjie Fu
> > > > Sent: Thursday, July 11, 2019 1:58 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Fu, Linjie
> > > > Subject: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> > > QSV
> > > > transpose filter
> > > >
> > > > Add transpose support for qsv_vpp with rotate and hflip:
> > > > - rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
> > > > - hflip: [0, 1] support horizontal flip;
> > > >
> > > > Configure with:
> > > > {"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","v
> > > > flip"}
> > > >
> > > > Limitation:
> > > > If pipeline contains resize, mirroring and other, VPP skips
> > > > other filters in MSDK when IOPattern equals d3d->d3d. So
> "cclock_hflip,
> > clock_hflip, vflip"
> > > > will not work in d3d->d3d condition.
> > > >
> > > > This pr is fixing this:
> > > > https://github.com/Intel-Media-SDK/MediaSDK/pull/1491
> > > >
> > > > CMD:
> > > > ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
> > > > -vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv
> > > > output.h264
> > >
> > > Tested:
> > > ffmpeg -hwaccel qsv -c:v h264_qsv -i
> > > ~/bbb_sunflower_1080p_30fps_normal.mp4 -vframes 100 -vf
> > > 'format=qsv,vpp_qsv=transpose=cclock_hflip' -c:v h264_qsv ch.mp4 Both
> > > Skylake and KBL failed:
> > >
> > > [Parsed_vpp_qsv_1 @ 0x5581aaf16080] Failed to create a qsvvpp, ret =
> > -15.
> > > [Parsed_vpp_qsv_1 @ 0x5581aaf16080] Failed to configure output pad on
> > > Parsed_vpp_qsv_1
> > > Error reinitializing filters!
> > > Failed to inject frame into filter network: Block device required
> > > Error while processing the decoded data for stream #0:0
> >
> > It is due to the limitation in MSDK mentioned in commit message:
> > If pipeline contains resize, mirroring and other, VPP skips other
> filters in
> > MSDK.
> >
> > And specially for resize (also width/height swap caused by rotate),
> > MFXVideoVPP_Init would fail directly, not simply skip the resize/rotate:
> > https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_li
> > b/vpp/src/mfx_vpp_hw.cpp#L5546
> >
> > This PR could handle this properly as suggested:
> > https://github.com/Intel-Media-SDK/MediaSDK/pull/1491
> >
> > - Linjie
>
> Applied with updated commit message to remove the limitation description,
> since https://github.com/Intel-Media-SDK/MediaSDK/pull/1491 has been
> merged.
Please revert, lavf stand for libavformat.
You need lavfi, as that stand for libavfilter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for QSV transpose filter
> From: Fu, Linjie
> Sent: Monday, July 15, 2019 12:30 PM
> To: Li, Zhong ; FFmpeg development discussions and
> patches
> Subject: RE: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> QSV transpose filter
>
> > -Original Message-
> > From: Li, Zhong
> > Sent: Sunday, July 14, 2019 19:33
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Cc: Fu, Linjie
> > Subject: RE: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support
> > for QSV transpose filter
> >
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of Linjie Fu
> > > Sent: Thursday, July 11, 2019 1:58 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie
> > > Subject: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> > QSV
> > > transpose filter
> > >
> > > Add transpose support for qsv_vpp with rotate and hflip:
> > > - rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
> > > - hflip: [0, 1] support horizontal flip;
> > >
> > > Configure with:
> > > {"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","v
> > > flip"}
> > >
> > > Limitation:
> > > If pipeline contains resize, mirroring and other, VPP skips
> > > other filters in MSDK when IOPattern equals d3d->d3d. So "cclock_hflip,
> clock_hflip, vflip"
> > > will not work in d3d->d3d condition.
> > >
> > > This pr is fixing this:
> > > https://github.com/Intel-Media-SDK/MediaSDK/pull/1491
> > >
> > > CMD:
> > > ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
> > > -vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv
> > > output.h264
> >
> > Tested:
> > ffmpeg -hwaccel qsv -c:v h264_qsv -i
> > ~/bbb_sunflower_1080p_30fps_normal.mp4 -vframes 100 -vf
> > 'format=qsv,vpp_qsv=transpose=cclock_hflip' -c:v h264_qsv ch.mp4 Both
> > Skylake and KBL failed:
> >
> > [Parsed_vpp_qsv_1 @ 0x5581aaf16080] Failed to create a qsvvpp, ret =
> -15.
> > [Parsed_vpp_qsv_1 @ 0x5581aaf16080] Failed to configure output pad on
> > Parsed_vpp_qsv_1
> > Error reinitializing filters!
> > Failed to inject frame into filter network: Block device required
> > Error while processing the decoded data for stream #0:0
>
> It is due to the limitation in MSDK mentioned in commit message:
> If pipeline contains resize, mirroring and other, VPP skips other filters in
> MSDK.
>
> And specially for resize (also width/height swap caused by rotate),
> MFXVideoVPP_Init would fail directly, not simply skip the resize/rotate:
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_li
> b/vpp/src/mfx_vpp_hw.cpp#L5546
>
> This PR could handle this properly as suggested:
> https://github.com/Intel-Media-SDK/MediaSDK/pull/1491
>
> - Linjie
Applied with updated commit message to remove the limitation description,
since https://github.com/Intel-Media-SDK/MediaSDK/pull/1491 has been merged.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/2] AltiVec/VSX fixes in swscale
On Tue, Aug 06, 2019 at 17:55:35 +0200, Daniel Kolesa wrote: > The first of these patches fixes the original report as described in > https://trac.ffmpeg.org/ticket/7861. The second of the patches fixes > the second report in the same ticket (by leigh123linux). If so, each of the commit messages should additionally say: "Fixes #7861" Moritz ___ 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] doc/developper: always use braces for statements
Moritz Barsnick (12019-08-07): > On Wed, Aug 07, 2019 at 00:14:06 +0200, Alexander Strasser wrote: > > Nicolas, changes to the coding style should be discussed and not > > be tunneled through documentation patches. Though I don't think > > the latter was the intention of the OP. > > It was probably caused by different reviews: > - "Please remove the brackets." > - "Please add brackets." > > I don't feel strongly about style rules being changed (though I do > prefer one of the two), but it should be consistent and documented. I think it is one of the cases that are best left to the discretion of whoever writes the code, or whoever maintains it if they have a strong opinion about it: there are more case-by-case factors than general arguments. And the communication about it was clumsy, but let us not dwell on it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]Support for Frame Doubling/ Tripling inFFMPEG's HEVC Decoder by parsing the picture_struct SEI value(Support forhttp://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245521.html
Hi Michael, The given patch is expected to break compliance because there is no support for frame-doubling (pic_struct=7) and frame-tripling (pic_struct=8) in the HM decoder. I have verified this on the HM Decoder v16.8 incl RExt. In HM's TDecTop::xActivateParameterSets(), only the pic_struct values 1,2,9,10,11 and 12 are dealt with (ref: Line#355&366 of TDecTop.cpp). There is no provision to deal with pic_struct values 7 and 8 which deal with Doubling and Tripling respectively. Hence HM is not able to handle frame doubling/ tripling. I verified it by decoding and counting yuv frames as well. Thanks & Regards, Praveen From: ffmpeg-devel on behalf of Michael Niedermayer Sent: Friday, August 2, 2019 2:40 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH]Support for Frame Doubling/ Tripling inFFMPEG's HEVC Decoder by parsing the picture_struct SEI value(Support forhttp://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245521.html) On Thu, Aug 01, 2019 at 12:46:21PM +, Praveen Kumar wrote: > Hi, > > This patch has the implementation for frame duplication (doubling/ tripling) > in FFmpeg's HEVC decoder based on the picture_structre SEI value (7 for > doubling and 8 for tripling) set while encoding. > This addresses the requirement mentioned in the thread > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245521.html > > Thanks & Regards, > Praveen > hevc_parser.c | 29 + > hevc_sei.c|6 ++ > hevc_sei.h| 15 +++ > hevcdec.c |8 > 4 files changed, 58 insertions(+) > 1acaad49a85cde86f32440d05b764ca2304887cd > Support-for-Frame-Doubling-Tripling-in-FFMPEG-HEVC-Decoder.patch > From 6b602399c68ce7062d8c2aefee9b3814be3f3b0e Mon Sep 17 00:00:00 2001 > From: Praveen Karadugattu > Date: Thu, 1 Aug 2019 17:47:36 +0530 > Subject: [PATCH] Support for Frame Doubling/ Tripling in FFMPEG's HEVC Decoder > by parsing the picture_struct SEI value (Support for > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245521.html) Breaks hevc fate tests TESThevc-conformance-WP_MAIN10_B_Toshiba_3 --- ./tests/ref/fate/hevc-conformance-WP_MAIN10_B_Toshiba_3 2019-07-31 21:32:01.464064534 +0200 +++ tests/data/fate/hevc-conformance-WP_MAIN10_B_Toshiba_3 2019-08-02 10:55:39.707488117 +0200 @@ -4,258 +4,131 @@ #dimensions 0: 416x240 #sar 0: 0/1 0, 0, 0,1, 299520, 0x6ecba46b -0, 1, 1,1, 299520, 0x54e6ef0a -0, 2, 2,1, 299520, 0x7a4d46c5 -0, 3, 3,1, 299520, 0xccd57f4e -0, 4, 4,1, 299520, 0xbe0cb48d -0, 5, 5,1, 299520, 0x10e7b49f -0, 6, 6,1, 299520, 0x81aa72e2 -0, 7, 7,1, 299520, 0x5bf7b51f -0, 8, 8,1, 299520, 0xfcedee4a -0, 9, 9,1, 299520, 0x586c99b6 -0, 10, 10,1, 299520, 0x414ca13c -0, 11, 11,1, 299520, 0x3f0162f2 -0, 12, 12,1, 299520, 0x4d450c05 -0, 13, 13,1, 299520, 0x0a58bd84 -0, 14, 14,1, 299520, 0x26e8394d -0, 15, 15,1, 299520, 0xfd78121b -0, 16, 16,1, 299520, 0x6afeaf44 -0, 17, 17,1, 299520, 0x3e9a9270 -0, 18, 18,1, 299520, 0x58b889ca -0, 19, 19,1, 299520, 0x0245ba62 -0, 20, 20,1, 299520, 0xddecc5ab -0, 21, 21,1, 299520, 0x32cf3cd9 -0, 22, 22,1, 299520, 0x5c0a0440 -0, 23, 23,1, 299520, 0x9d3e2fee -0, 24, 24,1, 299520, 0x2894c708 -0, 25, 25,1, 299520, 0x25be67d5 -0, 26, 26,1, 299520, 0xe3ece9d6 -0, 27, 27,1, 299520, 0xcc98e38b -0, 28, 28,1, 299520, 0xc448c794 -0, 29, 29,1, 299520, 0xb4f75575 -0, 30, 30,1, 299520, 0xac74a437 -0, 31, 31,1, 299520, 0x09c7f2e2 -0, 32, 32,1, 299520, 0xbfaed8ab -0, 33, 33,1, 299520, 0xb077d700 -0, 34, 34,1, 299520, 0x6efa0545 -0, 35, 35,1, 299520, 0xb8c1802d -0, 36, 36,1, 299520, 0x794774f8 -0, 37, 37,1, 299520, 0x1098f4ff -0, 38, 38,1, 299520, 0x80ab8bfc -0, 39, 39,1, 299520, 0xc324c3bc -0, 40, 40,1, 299520, 0x1eee77cd -0, 41, 41,1, 299520, 0x7147e72e -0, 42, 42,1, 299520, 0x1a34883c -0, 43,
Re: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.
LGTM. >-Original Message- >From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] >On Behalf Of gxw >Sent: Wednesday, August 7, 2019 5:52 PM >To: ffmpeg-devel@ffmpeg.org >Subject: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*. > >Changing details as following: >1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in > source vector. >2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'. > Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x). > Performance of H264 decoding has speed up about 0.5%(from 4.35x to 4.37x). > Performance of Theora decoding has speed up about 0.7%(from 5.79x to 5.83x). >3. Remove redundant macro 'CLIP_SH/Wn_0_255_MAX_SATU' and use >'CLIP_SH/Wn_0_255' > instead, because there are no difference in the effect of this two macros. >--- > libavcodec/mips/h264dsp_msa.c | 39 +-- > libavcodec/mips/h264idct_msa.c | 7 +- > libavcodec/mips/hevc_idct_msa.c | 21 +++--- > libavcodec/mips/hevc_lpf_sao_msa.c | 132 ++-- > libavcodec/mips/hevc_mc_bi_msa.c| 44 ++-- > libavcodec/mips/hevc_mc_biw_msa.c | 56 +++ > libavcodec/mips/hevc_mc_uniw_msa.c | 40 +-- > libavcodec/mips/hevcpred_msa.c | 8 +-- > libavcodec/mips/idctdsp_msa.c | 9 +-- > libavcodec/mips/qpeldsp_msa.c | 4 +- > libavcodec/mips/simple_idct_msa.c | 98 +++--- > libavcodec/mips/vp3dsp_idct_msa.c | 68 +++ > libavcodec/mips/vp8_idct_msa.c | 5 +- > libavcodec/mips/vp9_idct_msa.c | 10 ++- > libavutil/mips/generic_macros_msa.h | 119 +--- > 15 files changed, 280 insertions(+), 380 deletions(-) > >diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c >index c4ba8c4..dd05982 100644 >--- a/libavcodec/mips/h264dsp_msa.c >+++ b/libavcodec/mips/h264dsp_msa.c >@@ -413,8 +413,7 @@ static void avc_biwgt_8x8_msa(uint8_t *src, uint8_t *dst, >int32_t stride, > tmp7 = __msa_dpadd_s_h(offset, wgt, vec7); > SRA_4V(tmp0, tmp1, tmp2, tmp3, denom); > SRA_4V(tmp4, tmp5, tmp6, tmp7, denom); >-CLIP_SH4_0_255(tmp0, tmp1, tmp2, tmp3); >-CLIP_SH4_0_255(tmp4, tmp5, tmp6, tmp7); >+CLIP_SH8_0_255(tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7); > PCKEV_B2_UB(tmp1, tmp0, tmp3, tmp2, dst0, dst1); > PCKEV_B2_UB(tmp5, tmp4, tmp7, tmp6, dst2, dst3); > ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); >@@ -475,8 +474,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, >int32_t stride, > > SRA_4V(temp0, temp1, temp2, temp3, denom); > SRA_4V(temp4, temp5, temp6, temp7, denom); >-CLIP_SH4_0_255(temp0, temp1, temp2, temp3); >-CLIP_SH4_0_255(temp4, temp5, temp6, temp7); >+CLIP_SH8_0_255(temp0, temp1, temp2, temp3, temp4, temp5, temp6, >temp7); > PCKEV_B4_UB(temp1, temp0, temp3, temp2, temp5, temp4, temp7, temp6, > dst0, dst1, dst2, dst3); > ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); >@@ -531,7 +529,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, >int32_t stride, > temp = p1_or_q1_org_in << 1; \ > clip3 = clip3 - temp; \ > clip3 = __msa_ave_s_h(p2_or_q2_org_in, clip3);\ >-clip3 = CLIP_SH(clip3, negate_tc_in, tc_in); \ >+CLIP_SH(clip3, negate_tc_in, tc_in); \ > p1_or_q1_out = p1_or_q1_org_in + clip3; \ > } > >@@ -549,7 +547,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, >int32_t stride, > delta = q0_sub_p0 + p1_sub_q1; \ > delta >>= 3;\ > \ >-delta = CLIP_SH(delta, negate_threshold_in, threshold_in); \ >+CLIP_SH(delta, negate_threshold_in, threshold_in); \ > \ > p0_or_q0_out = p0_or_q0_org_in + delta; \ > q0_or_p0_out = q0_or_p0_org_in - delta; \ >@@ -598,7 +596,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, >int32_t stride, > delta = q0_sub_p0 + p1_sub_q1; \ > delta = __msa_srari_h(delta, 3); \ > \ >-delta = CLIP_SH(delta, -tc, tc); \ >+CLIP_SH(delta, -tc, tc); \ > \ > ILVR_B2_SH(zeros, src1, zeros, src2, res0_r, res1_r);\ >
[FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.
Changing details as following: 1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in source vector. 2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'. Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x). Performance of H264 decoding has speed up about 0.5%(from 4.35x to 4.37x). Performance of Theora decoding has speed up about 0.7%(from 5.79x to 5.83x). 3. Remove redundant macro 'CLIP_SH/Wn_0_255_MAX_SATU' and use 'CLIP_SH/Wn_0_255' instead, because there are no difference in the effect of this two macros. --- libavcodec/mips/h264dsp_msa.c | 39 +-- libavcodec/mips/h264idct_msa.c | 7 +- libavcodec/mips/hevc_idct_msa.c | 21 +++--- libavcodec/mips/hevc_lpf_sao_msa.c | 132 ++-- libavcodec/mips/hevc_mc_bi_msa.c| 44 ++-- libavcodec/mips/hevc_mc_biw_msa.c | 56 +++ libavcodec/mips/hevc_mc_uniw_msa.c | 40 +-- libavcodec/mips/hevcpred_msa.c | 8 +-- libavcodec/mips/idctdsp_msa.c | 9 +-- libavcodec/mips/qpeldsp_msa.c | 4 +- libavcodec/mips/simple_idct_msa.c | 98 +++--- libavcodec/mips/vp3dsp_idct_msa.c | 68 +++ libavcodec/mips/vp8_idct_msa.c | 5 +- libavcodec/mips/vp9_idct_msa.c | 10 ++- libavutil/mips/generic_macros_msa.h | 119 +--- 15 files changed, 280 insertions(+), 380 deletions(-) diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c index c4ba8c4..dd05982 100644 --- a/libavcodec/mips/h264dsp_msa.c +++ b/libavcodec/mips/h264dsp_msa.c @@ -413,8 +413,7 @@ static void avc_biwgt_8x8_msa(uint8_t *src, uint8_t *dst, int32_t stride, tmp7 = __msa_dpadd_s_h(offset, wgt, vec7); SRA_4V(tmp0, tmp1, tmp2, tmp3, denom); SRA_4V(tmp4, tmp5, tmp6, tmp7, denom); -CLIP_SH4_0_255(tmp0, tmp1, tmp2, tmp3); -CLIP_SH4_0_255(tmp4, tmp5, tmp6, tmp7); +CLIP_SH8_0_255(tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7); PCKEV_B2_UB(tmp1, tmp0, tmp3, tmp2, dst0, dst1); PCKEV_B2_UB(tmp5, tmp4, tmp7, tmp6, dst2, dst3); ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); @@ -475,8 +474,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, SRA_4V(temp0, temp1, temp2, temp3, denom); SRA_4V(temp4, temp5, temp6, temp7, denom); -CLIP_SH4_0_255(temp0, temp1, temp2, temp3); -CLIP_SH4_0_255(temp4, temp5, temp6, temp7); +CLIP_SH8_0_255(temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7); PCKEV_B4_UB(temp1, temp0, temp3, temp2, temp5, temp4, temp7, temp6, dst0, dst1, dst2, dst3); ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); @@ -531,7 +529,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, temp = p1_or_q1_org_in << 1; \ clip3 = clip3 - temp; \ clip3 = __msa_ave_s_h(p2_or_q2_org_in, clip3);\ -clip3 = CLIP_SH(clip3, negate_tc_in, tc_in); \ +CLIP_SH(clip3, negate_tc_in, tc_in); \ p1_or_q1_out = p1_or_q1_org_in + clip3; \ } @@ -549,7 +547,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, delta = q0_sub_p0 + p1_sub_q1; \ delta >>= 3;\ \ -delta = CLIP_SH(delta, negate_threshold_in, threshold_in); \ +CLIP_SH(delta, negate_threshold_in, threshold_in); \ \ p0_or_q0_out = p0_or_q0_org_in + delta; \ q0_or_p0_out = q0_or_p0_org_in - delta; \ @@ -598,7 +596,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, delta = q0_sub_p0 + p1_sub_q1; \ delta = __msa_srari_h(delta, 3); \ \ -delta = CLIP_SH(delta, -tc, tc); \ +CLIP_SH(delta, -tc, tc); \ \ ILVR_B2_SH(zeros, src1, zeros, src2, res0_r, res1_r);\ \ @@ -662,7 +660,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, q0_sub_p0 <<= 2; \ delta = q0_sub_p0 + p1_sub_q1; \ delta = __msa_srari_h(delta, 3); \ -
[FFmpeg-devel] [PATCH v3] avutil/mips: refine msa macros CLIP_*.
Changing details as following: 1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in source vector. 2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'. Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x). 3. Remove redundant macro 'CLIP_SH/Wn_0_255_MAX_SATU' and use 'CLIP_SH/Wn_0_255' instead, because there are no difference in the effect of this two macros. --- libavcodec/mips/h264dsp_msa.c | 39 +-- libavcodec/mips/h264idct_msa.c | 7 +- libavcodec/mips/hevc_idct_msa.c | 21 +++--- libavcodec/mips/hevc_lpf_sao_msa.c | 132 ++-- libavcodec/mips/hevc_mc_bi_msa.c| 44 ++-- libavcodec/mips/hevc_mc_biw_msa.c | 56 +++ libavcodec/mips/hevc_mc_uniw_msa.c | 40 +-- libavcodec/mips/hevcpred_msa.c | 8 +-- libavcodec/mips/idctdsp_msa.c | 9 +-- libavcodec/mips/qpeldsp_msa.c | 4 +- libavcodec/mips/simple_idct_msa.c | 98 +++--- libavcodec/mips/vp3dsp_idct_msa.c | 68 +++ libavcodec/mips/vp8_idct_msa.c | 5 +- libavcodec/mips/vp9_idct_msa.c | 10 ++- libavutil/mips/generic_macros_msa.h | 119 +--- 15 files changed, 280 insertions(+), 380 deletions(-) diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c index c4ba8c4..dd05982 100644 --- a/libavcodec/mips/h264dsp_msa.c +++ b/libavcodec/mips/h264dsp_msa.c @@ -413,8 +413,7 @@ static void avc_biwgt_8x8_msa(uint8_t *src, uint8_t *dst, int32_t stride, tmp7 = __msa_dpadd_s_h(offset, wgt, vec7); SRA_4V(tmp0, tmp1, tmp2, tmp3, denom); SRA_4V(tmp4, tmp5, tmp6, tmp7, denom); -CLIP_SH4_0_255(tmp0, tmp1, tmp2, tmp3); -CLIP_SH4_0_255(tmp4, tmp5, tmp6, tmp7); +CLIP_SH8_0_255(tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7); PCKEV_B2_UB(tmp1, tmp0, tmp3, tmp2, dst0, dst1); PCKEV_B2_UB(tmp5, tmp4, tmp7, tmp6, dst2, dst3); ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); @@ -475,8 +474,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, SRA_4V(temp0, temp1, temp2, temp3, denom); SRA_4V(temp4, temp5, temp6, temp7, denom); -CLIP_SH4_0_255(temp0, temp1, temp2, temp3); -CLIP_SH4_0_255(temp4, temp5, temp6, temp7); +CLIP_SH8_0_255(temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7); PCKEV_B4_UB(temp1, temp0, temp3, temp2, temp5, temp4, temp7, temp6, dst0, dst1, dst2, dst3); ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); @@ -531,7 +529,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, temp = p1_or_q1_org_in << 1; \ clip3 = clip3 - temp; \ clip3 = __msa_ave_s_h(p2_or_q2_org_in, clip3);\ -clip3 = CLIP_SH(clip3, negate_tc_in, tc_in); \ +CLIP_SH(clip3, negate_tc_in, tc_in); \ p1_or_q1_out = p1_or_q1_org_in + clip3; \ } @@ -549,7 +547,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, delta = q0_sub_p0 + p1_sub_q1; \ delta >>= 3;\ \ -delta = CLIP_SH(delta, negate_threshold_in, threshold_in); \ +CLIP_SH(delta, negate_threshold_in, threshold_in); \ \ p0_or_q0_out = p0_or_q0_org_in + delta; \ q0_or_p0_out = q0_or_p0_org_in - delta; \ @@ -598,7 +596,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, delta = q0_sub_p0 + p1_sub_q1; \ delta = __msa_srari_h(delta, 3); \ \ -delta = CLIP_SH(delta, -tc, tc); \ +CLIP_SH(delta, -tc, tc); \ \ ILVR_B2_SH(zeros, src1, zeros, src2, res0_r, res1_r);\ \ @@ -662,7 +660,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, q0_sub_p0 <<= 2; \ delta = q0_sub_p0 + p1_sub_q1; \ delta = __msa_srari_h(delta, 3); \ -delta = CLIP_SH(delta, -tc, tc); \ +CLIP_SH(delta, -tc, tc); \
Re: [FFmpeg-devel] [PATCH] Fixing HW accelerated decoders hanging or throwing error in h263dec
Hi Phil,
Unfortunately I cannot share the sample we use internally, but it should be
reproducible with any h.263/mpeg-4 encoded file & hw accelerated decoding.
Thanks
Stefan
-Original Message-
From: ffmpeg-devel On Behalf Of Philip
Langdale
Sent: Saturday, August 3, 2019 08:57
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] Fixing HW accelerated decoders hanging or
throwing error in h263dec
On 2019-08-03 00:09, Timo Rothenpieler wrote:
> On 02.08.2019 11:18, Stefan Schoenefeld wrote:
>> Hi all,
>>
>> Recently we encountered an issue when decoding a h.263 file:
>>
>> FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out
>> this is not directly related to NVDEC but is a problem that shows
>> with several other HW decoders like VDPAU, though the exact kind of
>> error is different (either error messages or freezing[1]). The root
>> cause is that ff_thread_finish_setup() is called twice per frame from
>> ff_h263_decode_frame(). This is not supported by
>> ff_thread_finish_setup() and specifically checked for and warned
>> against in the functions code. The issue is also specific to hw
>> accelerated decoding only as the second call to
>> ff_thread_finish_setup() is only issued when hw acceleration is on.
>> The fix is simple: add a check that the first call is only send when
>> hw acceleration is off, and the second call only when hw acceleration
>> is on (see attached patch). This works fine as far as I was able to
>> test with vdpau and nvdec/nvcuvid hw decoding. The patch also adds
>> NVDEC to the hw config list if available.
>>
>> I also noticed a secondary issue when browsing through the code which
>> is that, according to documentation, ff_thread_finish_setup() should
>> only be called if the codec implements update_thread_context(), which
>> h263dec does not. The patch does not address this and I'm not sure
>> any action needs to be taken here at all.
>>
>> Thanks,
>> Stefan
>>
>> [1] This is depending on whether or not the hw decoder sets the
>> HWACCEL_CAPS_ASYNC_SAFE flag
>>
>> From 0620ee777a8ba98145bb4781e30a77687c97dbf8 Mon Sep 17 00:00:00
>> 2001
>> From: Stefan Schoenefeld
>> Date: Fri, 2 Aug 2019 10:52:22 +0200
>> Subject: [PATCH] Fixing HW accelerated decoders hanging or throwing
>> error messages in h263dec
>>
>> ---
>> libavcodec/h263dec.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c index
>> 6f001f6..8ee844e 100644
>> --- a/libavcodec/h263dec.c
>> +++ b/libavcodec/h263dec.c
>> @@ -614,7 +614,7 @@ retry:
>> if ((ret = ff_mpv_frame_start(s, avctx)) < 0)
>> return ret;
>> -if (!s->divx_packed)
>> +if (!s->divx_packed && !avctx->hwaccel)
>> ff_thread_finish_setup(avctx);
>
> This seems correct to me, but I'd like another pair of eyes to look
> over it.
Seems fine to me as well.
>
>> if (avctx->hwaccel) {
>> @@ -747,6 +747,9 @@ const AVCodecHWConfigInternal
>> *ff_h263_hw_config_list[] = { #if CONFIG_H263_VAAPI_HWACCEL
>> HWACCEL_VAAPI(h263),
>> #endif
>> +#if CONFIG_MPEG4_NVDEC_HWACCEL
>> +HWACCEL_NVDEC(mpeg4),
>> +#endif
>
> Probably cleaner to split this into its own patch, but otherwise OK.
>
>> #if CONFIG_MPEG4_VDPAU_HWACCEL
>> HWACCEL_VDPAU(mpeg4),
>> #endif
Thanks for fixing this. I was always confused about whether h.263 was really
supported by the hardware or not. Can you provide a link to a reference sample
that fails without this change and succeeds with it?
--phil
___
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".
NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
Managing Director: Karen Theresa Burns
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avutil/mips: refine msa macros CLIP_*.
Changing details as following: 1. Remove the local variable out_m in CLIP_SH. Results are assigned to input vector, reduced the data replication. 2. Reimplement the macro CLIP_SH/Wn_0_255. The VP8 decoding performance has improved by 1.1%(7.03x to 7.11x, tested on loongson 3A4000). 3. Remove CLIP_SH/Wn_0_255_MAX_SATU. CLIP_SH/Wn_0_255_MAX_SATU and CLIP_SH/Wn_0_255 have the same function. It is not necessary to keep both, use CLIP_SH/Wn_0_255 instead. --- libavcodec/mips/h264dsp_msa.c | 39 +-- libavcodec/mips/h264idct_msa.c | 7 +- libavcodec/mips/hevc_idct_msa.c | 21 +++--- libavcodec/mips/hevc_lpf_sao_msa.c | 132 ++-- libavcodec/mips/hevc_mc_bi_msa.c| 44 ++-- libavcodec/mips/hevc_mc_biw_msa.c | 56 +++ libavcodec/mips/hevc_mc_uniw_msa.c | 40 +-- libavcodec/mips/hevcpred_msa.c | 8 +-- libavcodec/mips/idctdsp_msa.c | 9 +-- libavcodec/mips/qpeldsp_msa.c | 4 +- libavcodec/mips/simple_idct_msa.c | 98 +++--- libavcodec/mips/vp3dsp_idct_msa.c | 68 +++ libavcodec/mips/vp8_idct_msa.c | 5 +- libavcodec/mips/vp9_idct_msa.c | 10 ++- libavutil/mips/generic_macros_msa.h | 119 +--- 15 files changed, 280 insertions(+), 380 deletions(-) diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c index c4ba8c4..dd05982 100644 --- a/libavcodec/mips/h264dsp_msa.c +++ b/libavcodec/mips/h264dsp_msa.c @@ -413,8 +413,7 @@ static void avc_biwgt_8x8_msa(uint8_t *src, uint8_t *dst, int32_t stride, tmp7 = __msa_dpadd_s_h(offset, wgt, vec7); SRA_4V(tmp0, tmp1, tmp2, tmp3, denom); SRA_4V(tmp4, tmp5, tmp6, tmp7, denom); -CLIP_SH4_0_255(tmp0, tmp1, tmp2, tmp3); -CLIP_SH4_0_255(tmp4, tmp5, tmp6, tmp7); +CLIP_SH8_0_255(tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7); PCKEV_B2_UB(tmp1, tmp0, tmp3, tmp2, dst0, dst1); PCKEV_B2_UB(tmp5, tmp4, tmp7, tmp6, dst2, dst3); ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); @@ -475,8 +474,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, SRA_4V(temp0, temp1, temp2, temp3, denom); SRA_4V(temp4, temp5, temp6, temp7, denom); -CLIP_SH4_0_255(temp0, temp1, temp2, temp3); -CLIP_SH4_0_255(temp4, temp5, temp6, temp7); +CLIP_SH8_0_255(temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7); PCKEV_B4_UB(temp1, temp0, temp3, temp2, temp5, temp4, temp7, temp6, dst0, dst1, dst2, dst3); ST_D8(dst0, dst1, dst2, dst3, 0, 1, 0, 1, 0, 1, 0, 1, dst, stride); @@ -531,7 +529,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, temp = p1_or_q1_org_in << 1; \ clip3 = clip3 - temp; \ clip3 = __msa_ave_s_h(p2_or_q2_org_in, clip3);\ -clip3 = CLIP_SH(clip3, negate_tc_in, tc_in); \ +CLIP_SH(clip3, negate_tc_in, tc_in); \ p1_or_q1_out = p1_or_q1_org_in + clip3; \ } @@ -549,7 +547,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, delta = q0_sub_p0 + p1_sub_q1; \ delta >>= 3;\ \ -delta = CLIP_SH(delta, negate_threshold_in, threshold_in); \ +CLIP_SH(delta, negate_threshold_in, threshold_in); \ \ p0_or_q0_out = p0_or_q0_org_in + delta; \ q0_or_p0_out = q0_or_p0_org_in - delta; \ @@ -598,7 +596,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, delta = q0_sub_p0 + p1_sub_q1; \ delta = __msa_srari_h(delta, 3); \ \ -delta = CLIP_SH(delta, -tc, tc); \ +CLIP_SH(delta, -tc, tc); \ \ ILVR_B2_SH(zeros, src1, zeros, src2, res0_r, res1_r);\ \ @@ -662,7 +660,7 @@ static void avc_biwgt_8x16_msa(uint8_t *src, uint8_t *dst, int32_t stride, q0_sub_p0 <<= 2; \ delta = q0_sub_p0 + p1_sub_q1; \ delta = __msa_srari_h(delta, 3); \ -delta = CLIP_SH(delta, -tc, tc); \ +CLIP_SH(delta, -tc, tc);
Re: [FFmpeg-devel] [PATCH V2] avfilter/vf_convolution: add x86 SIMD for filter_3x3()
> -Original Message- > From: Song, Ruiling > Sent: Wednesday, July 31, 2019 3:54 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Song, Ruiling > Subject: [PATCH V2] avfilter/vf_convolution: add x86 SIMD for filter_3x3() > > Tested using a simple command (apply edge enhance): > ./ffmpeg_g -i ~/Downloads/bbb_sunflower_1080p_30fps_normal.mp4 \ > -vf convolution="0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 > 0 0 -1 1 0 0 > 0 0:5:1:1:1:0:128:128:128" \ > -an -vframes 1000 -f null /dev/null > > The fps increase from 151 to 270 on my local machine. > > Signed-off-by: Ruiling Song > --- > v2: > fix a bug in scalar code path. > Use macro PROCESS_V/S for the first tap to simplify code. Applied this version. > > libavfilter/convolution.h | 64 +++ > libavfilter/vf_convolution.c | 41 +-- > libavfilter/x86/Makefile | 2 + > libavfilter/x86/vf_convolution.asm| 156 ++ > libavfilter/x86/vf_convolution_init.c | 46 > 5 files changed, 271 insertions(+), 38 deletions(-) > create mode 100644 libavfilter/convolution.h > create mode 100644 libavfilter/x86/vf_convolution.asm > create mode 100644 libavfilter/x86/vf_convolution_init.c [...] ___ 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] libavcodec: add timer bitstream filter [v2]
Hi Alexander,
‐‐‐ Original Message ‐‐‐
On Wednesday, 7 de August de 2019 0:24, Alexander Strasser
wrote:
> Hi Andreas!
>
> On 2019-08-05 17:25 +, Andreas Håkon wrote:
>
> > On Monday, 5 de August de 2019 17:31, Moritz Barsnick barsn...@gmx.net
> > wrote:
>
> [...]
>
> > > > +static const AVClass timer_class = {
> > > >
> > > > - .class_name = "timer",
> > >
> > > In about half of the existing BSFs, this would be called "timer_bsf". I
> > > don't care, I just look at other existing code. ;-)
> >
> > Good point! Other bitstream filters have this. I'll update it.
> > Thank you!
>
> Sorry for the noise. IIRC the naming was previously discussed.
> Can't remember the details right now. Unfortunately I don't have
> any good name suggestions too :(
>
> This is no objections, but at least to me the name timer sounds
> like some autonomous unit/process that can interrupt/call your
> process on defined/configured/subscribed intervals. Maybe it's
> just me...
>
> ...what do others think?
It's nitial name was "retimer". After a suggestion I changed to "timer".
Other options can be "timestamp", "synchronizer", etc.
However, they're all a little vague.
Therefore, I ask someone to present an appropriate name taking
into account the objective: shifting the PTS/DTS marks of a stream.
You like "timeshift"?
Regards.
A.H.
---
___
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] doc/developper: always use braces for statements
On Wed, Aug 07, 2019 at 00:14:06 +0200, Alexander Strasser wrote: > Nicolas, changes to the coding style should be discussed and not > be tunneled through documentation patches. Though I don't think > the latter was the intention of the OP. It was probably caused by different reviews: - "Please remove the brackets." - "Please add brackets." I don't feel strongly about style rules being changed (though I do prefer one of the two), but it should be consistent and documented. (Same e.g. about the loop counter declaration within for(;;).) Cheers, Moritz ___ 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".
