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"}
Limitation:
If pipeline
Yes, obviously this is not complete. As was said, the DNG spec is huge
and I did bring up this concern in a personal email to Paul a few days
ago.
I was told that:
> 3 months should be enough to finish most of specification, note you work on
> real world DNG files, so if some feature from spec is
---
libavcodec/cbs_vp9.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index 237416a06f..cd046afa46 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -416,6 +416,9 @@ static int cbs_vp9_split_fragment(CodedBitstreamContext
From: Zhong Li
VP9 decoder is supported on Intel kabyLake+ platforms with MSDK Version 1.19+
Signed-off-by: Zhong Li
---
Tested on Coffee Lake.
Changelog | 1 +
configure | 6 ++
libavcodec/allcodecs.c| 1 +
libavcodec/qsv.c | 5 +
Rewrites the parser entirely, using CBS for header parsing. A new
entrypoint to the CBS code is added to avoid any copy overhead.
---
On 18/03/2019 03:22, Li, Zhong wrote:
> If you think that case can be resolved for VP9 parser, could you please
> provide more details?
Since all the
On 2/25/2019 7:50 AM, Paweł Wegner wrote:
> This fixes avformat_query_codec incorrectly returning 0 for
> mov container and mov_text subtitles.
>
> Signed-off-by: Paweł Wegner
> ---
> libavformat/movenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Fri, Mar 08, 2019 at 03:15:40PM +0100, Lynne wrote:
> 7 Mar 2019, 21:22 by mich...@niedermayer.cc:
>
> > On Thu, Mar 07, 2019 at 07:26:32PM +0100, Lynne wrote:
> >
> >> By default now, if AV_EF_CRCCHECK or AV_EF_IGNORE_ERR are enabled the
> >> decoder
> >> will skip the chunk and carry on
On 18/03/2019 20:44, Michael Niedermayer wrote:
> do you have a sample for h264 ? (or only teh one for hevc) ?
On hand, just HEVC.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi Nicolas!
On 2019-03-18 00:24 +0100, Nicolas George wrote:
> Alexander Strasser (12019-03-18):
> > I tested the EAGAIN version and it worked. I also tested returning a
>
> ffmpeg.c uses the non-blocking mode.
That would explain it. I now tested, the FFERROR_REDO approach,
and I think it works
On Wed, Mar 13, 2019 at 12:08 PM Paweł Wegner
wrote:
> On Mon, Mar 4, 2019 at 10:52 AM Paweł Wegner
> wrote:
>
>> On Mon, Mar 4, 2019 at 10:50 AM Paweł Wegner
>> wrote:
>>
>>> ping
>>>
>>> On Mon, Feb 25, 2019 at 11:50 AM Paweł Wegner
>>> wrote:
>>>
This fixes avformat_query_codec
2019-03-18 16:08 GMT+01:00, Olivier Maignial :
> +char * end_ptr = NULL;
Assuming you have to send a new patch anyway,
please make this "char *end_ptr"...
> +long int val = strtol(value, _ptr, 10);
> +if (value[0] == '\n' ||
On Mon, Mar 18, 2019 at 07:19:06PM +, Derek Buitenhuis wrote:
> We don't treat this as an error.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/h2645_parse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
On Mon, Mar 18, 2019 at 04:08:40PM +0100, Olivier Maignial wrote:
> RFC-4566 do not give any limit of size on interger parameters given in fmtp
> line.
> By reading some more RFCs it is possible to find examples where some integers
> parameters are greater than 32 (see RFC-6416, 7.4)
> ---
>
On Mon, Mar 18, 2019 at 03:46:09PM +, Derek Buitenhuis wrote:
> If we don't propagate these errors, h264dec and hevcdec can get up to all
> sorts of
> weirdness, especially threaded, while trying to continue on with things they
> shouldn't.
> Can cause stuff like:
do you have a sample for
On 3/18/2019 4:19 PM, Derek Buitenhuis wrote:
> We don't treat this as an error.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/h2645_parse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index
Fixes deadlocks when decoding packets containing more than one of the
aforementioned
slices when using frame threads.
Signed-off-by: James Almer
---
See the discussion in the
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241192.html
thread.
Alternative fixes that don't discard the
On 18/03/2019 18:38, James Almer wrote:
> So, what i'm seeing here is two slice NALs in the same packet (which
> means processed in the same decode_nal_units() loop in hevcdec.c)
> reporting being the "first slice segment in the pic". And that's
> seemingly making the threading logic shit itself.
We don't treat this as an error.
Signed-off-by: Derek Buitenhuis
---
libavcodec/h2645_parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 942f2c5d71..24658b3dfa 100644
--- a/libavcodec/h2645_parse.c
+++
RFC-4566 do not give any limit of size on interger parameters given in fmtp
line.
By reading some more RFCs it is possible to find examples where some integers
parameters are greater than 32 (see RFC-6416, 7.4)
---
libavformat/rtpdec_mpeg4.c | 17 +
1 file changed, 13
> -Original Message-
> From: Rogozhkin, Dmitry V
> Sent: Saturday, March 16, 2019 4:18 AM
> To: Li, Zhong ; ffmpeg-devel@ffmpeg.org; Gurulev, Dmitry
>
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser
> with MFXVideoDECODE_DecodeHeader()
>
> On Mon,
> -Original Message-
> From: Rogozhkin, Dmitry V
> Sent: Saturday, March 16, 2019 4:17 AM
> To: Li, Zhong ; ffmpeg-devel@ffmpeg.org; Gurulev, Dmitry
>
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser
> with MFXVideoDECODE_DecodeHeader()
>
> On Thu,
On 3/18/2019 12:52 PM, Derek Buitenhuis wrote:
> On 18/03/2019 15:50, James Almer wrote:
>> This will abort the splitting process when it's meant to only discard
>> the faulty NAL. Even the log message stats it's skipping it.
>
> The log message also claims to be AV_LOG_ERROR.
>
> Also there are
Hi Ronald,
actually the problem was occurring transcoding quicktime files with ProRes
settings and not with h264.
Changing the number of threads would not solve the problem.
I noticed that memory usage would keep growing as long i reached a certain
point at which i would get a message like
On 18/03/2019 15:55, Carl Eugen Hoyos wrote:
> The first 500k of this file allow to reproduce the issue,
> so I believe the sample is too big.
Sure, I can trim it. I'll resend the test + file once a solution
is agreed upon.
- Derek
___
ffmpeg-devel
2019-03-18 16:46 GMT+01:00, Derek Buitenhuis :
> FATE sample is located here:
> http://chromashift.org/nal_header_deadlock.mp4
The first 500k of this file allow to reproduce the issue,
so I believe the sample is too big.
Carl Eugen
___
ffmpeg-devel
On 18/03/2019 15:50, James Almer wrote:
> This will abort the splitting process when it's meant to only discard
> the faulty NAL. Even the log message stats it's skipping it.
The log message also claims to be AV_LOG_ERROR.
Also there are no comments indicating why this is right, or any commit I
On 3/18/2019 12:46 PM, Derek Buitenhuis wrote:
> If we don't propagate these errors, h264dec and hevcdec can get up to all
> sorts of
> weirdness, especially threaded, while trying to continue on with things they
> shouldn't.
> Can cause stuff like:
>
> [hevc @ 0x577107c0] get_buffer()
Signed-off-by: Derek Buitenhuis
---
tests/fate/hevc.mak | 3 +++
tests/ref/fate/hevc-nal-header-deadlock | 12
2 files changed, 15 insertions(+)
create mode 100644 tests/ref/fate/hevc-nal-header-deadlock
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
FATE sample is located here:
http://chromashift.org/nal_header_deadlock.mp4
md5sum is: 166f5959a67fccf3017eaeb010a64fcf
Since it causes a deadlock in FFmpeg, please be careful if opening in
e.g. a browser.
Derek Buitenhuis (2):
h2645_parse: Propagate NAL header parsing errors
FATE:
If we don't propagate these errors, h264dec and hevcdec can get up to all sorts
of
weirdness, especially threaded, while trying to continue on with things they
shouldn't.
Can cause stuff like:
[hevc @ 0x577107c0] get_buffer() cannot be called after
ff_thread_finish_setup()
[hevc @
2019-03-18 12:56 GMT+01:00, Lauri Kasanen :
> Signed-off-by: Lauri Kasanen
> ---
> libswscale/ppc/swscale_ppc_template.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/libswscale/ppc/swscale_ppc_template.c
>
Removes an av_malloc() per frame.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index d9079cbbef..30c6eccfef 100644
--- a/libavcodec/libdav1d.c
+++
On Mon, 18 Mar 2019 14:06:15 +0100
Carl Eugen Hoyos wrote:
>
> This looks good to me if you tested it and it reduces the number of warnings.
Tested on power8. With these two patches, swscale/ppc has no warnings.
- Lauri
___
ffmpeg-devel mailing list
2019-03-18 12:56 GMT+01:00, Lauri Kasanen :
> Signed-off-by: Lauri Kasanen
> ---
> libswscale/ppc/swscale_altivec.c | 6 +++---
> libswscale/ppc/swscale_ppc_template.c | 9 +
> libswscale/ppc/swscale_vsx.c | 6 +++---
> 3 files changed, 11 insertions(+), 10 deletions(-)
>
>
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_ppc_template.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/libswscale/ppc/swscale_ppc_template.c
b/libswscale/ppc/swscale_ppc_template.c
index 3964a7a..aff2dd7 100644
---
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_altivec.c | 6 +++---
libswscale/ppc/swscale_ppc_template.c | 9 +
libswscale/ppc/swscale_vsx.c | 6 +++---
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/libswscale/ppc/swscale_altivec.c
Yay, thanks!
On 3/16/19 12:04 AM, Michael Niedermayer wrote:
> no
> will apply
>
> thx
>
> [...]
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 3/18/19, Moritz Barsnick wrote:
> On Wed, Mar 13, 2019 at 10:17:40 +0100, Moritz Barsnick wrote:
>> Signed-off-by: Moritz Barsnick
>> ---
>> Tested against sample provided here:
>> https://ffmpeg.org/pipermail/ffmpeg-user/2019-March/043717.html
>>
>> libavformat/aiffdec.c | 5 +
>> 1
On Mon, Mar 18, 2019 at 7:29 AM Zhong Li wrote:
>
> WinBRCMaxAvgKbps is to specify maximum average bitrate over a
> sliding window with size of WinBRCSize
>
> WinBRCMaxAvgKbps will be ignored in CBR mode and equal to TargetKbps.
>
How are these modes different to ffmpeg rc_max_rate in
On Mon, Mar 18, 2019 at 09:13:01AM +0100, Moritz Barsnick wrote:
> On Sun, Mar 17, 2019 at 23:05:01 +0100, Paul B Mahol wrote:
> > Still wrong, You can decode images you linked just fine (albeit with
> > incorrect colors) with command:
> >
> > ffmpeg -subimage 1 -i IMAGE.dng rest of command.
> 在 2019年3月18日，上午8:52，Jun Li 写道：
>
> On Fri, Mar 15, 2019 at 6:04 PM Jun Li wrote:
>
>> Calculate bitrate based on fragment size, only applied when
>> bitrate is not set, for example rtsp source.
>>
>> Signed-off-by: Jun Li
>> ---
>> libavformat/smoothstreamingenc.c | 32
On Mon, 18 Mar 2019 09:13:01 +0100
Moritz Barsnick wrote:
> On Sun, Mar 17, 2019 at 23:05:01 +0100, Paul B Mahol wrote:
> > Still wrong, You can decode images you linked just fine (albeit with
> > incorrect colors) with command:
> >
> > ffmpeg -subimage 1 -i IMAGE.dng rest of command.
>
>
On 3/18/19, velocit...@gmail.com wrote:
> From: Nick Renieris
>
> Prints "DNG images are not supported" if it finds a TIFF image with
> the 'DNGVersion' tag. In DNG images with the .tiff extension, it
> solves the issue where the TIFF thumbnail in IFD 0 was incorrectly
> parsed (related
On Wed, Mar 13, 2019 at 10:17:40 +0100, Moritz Barsnick wrote:
> Signed-off-by: Moritz Barsnick
> ---
> Tested against sample provided here:
> https://ffmpeg.org/pipermail/ffmpeg-user/2019-March/043717.html
>
> libavformat/aiffdec.c | 5 +
> 1 file changed, 5 insertions(+)
Friendly ping.
On Sun, Mar 17, 2019 at 23:05:01 +0100, Paul B Mahol wrote:
> Still wrong, You can decode images you linked just fine (albeit with
> incorrect colors) with command:
>
> ffmpeg -subimage 1 -i IMAGE.dng rest of command.
Shouldn't, ideally, these image files be demuxed as two image streams?
WinBRCMaxAvgKbps is to specify maximum average bitrate over a
sliding window with size of WinBRCSize
WinBRCMaxAvgKbps will be ignored in CBR mode and equal to TargetKbps.
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 12
libavcodec/qsvenc.h | 5 +
2 files changed, 17
46 matches
Mail list logo
