>tor 2018-12-20 klockan 10:53 +0800 skrev gxw:
>> The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is
>> still 32
>> in function ff_hevc_sao_edge_filter_8_msa. So, use
>> AV_INPUT_BUFFER_PADDING_SIZE directly.
>> Fate tests passed.
>> ---
>>
this was a typo in my original patch. there is no requirement for 64-byte
alignment here, and it does not affect decoder performance.
---
libavcodec/dstdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dstdec.c b/libavcodec/dstdec.c
index 368cb64931..511861f4d2
---
the dst sample file is 40 kilobytes.
i don't have write access to fate-suite to upload it.
tests/fate/audio.mak | 3 +++
tests/ref/fate/dsf-dst | 16
2 files changed, 19 insertions(+)
create mode 100644 tests/ref/fate/dsf-dst
diff --git a/tests/fate/audio.mak
> 在 2018年12月20日，上午12:19，Aleksey Skripka 写道：
>
> All my tests ok.
> Thank you, Adrian.
>
>> On 19 Dec 2018, at 12:41, Adrian wrote:
>>
>> Okay, so given you two have some valid points, I've combined both and ended
>> up with final version of the patch:
>> - it uses temp file for playlist
On 12/20/2018 8:56 PM, Michael Niedermayer wrote:
> On Thu, Dec 20, 2018 at 06:54:12PM -0300, James Almer wrote:
>> On 12/20/2018 6:40 PM, Michael Niedermayer wrote:
>>> Future gcc may no longer support this
>>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>>
This commit adds configuration options to libvpxenc.c that can be used to
tune the sharpness parameter for VP8 and VP9.
Signed-off-by: Rene Claus
---
doc/encoders.texi | 4
libavcodec/libvpxenc.c | 6 ++
2 files changed, 10 insertions(+)
diff --git a/doc/encoders.texi
On Thu, Dec 20, 2018 at 06:54:12PM -0300, James Almer wrote:
> On 12/20/2018 6:40 PM, Michael Niedermayer wrote:
> > Future gcc may no longer support this
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libpostproc/postprocess_template.c | 2 +-
> > 1 file changed, 1 insertion(+), 1
On Thu, Dec 20, 2018 at 11:00:32AM +0100, Nicolas George wrote:
> Andrey Semashev (2018-12-10):
> > This commit adds a new set of functions to avio and url subsystems, which
> > allow users to invoke IO buffer synchronization with the underlying media.
> > The most obvious target for this
On 18/12/2018 01:28, Song, Ruiling wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Tuesday, December 18, 2018 6:33 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavfi/vf_hwmap:
On Thu, Dec 20, 2018 at 18:24:07 +0100, Roland Singer wrote:
> hope somebody can help solving a segmentation fault caused by using the
> h264_v4l2m2m encoder on an Samsung Exynos5422.
[...]
> > # ./encode_video out h264_v4l2m2m
Run:
$ gdb -ex r --args ./encode_video out h264_v4l2m2m
At the core
On Wed, Dec 19, 2018 at 04:00:22PM -0800, Jacob Trimble wrote:
> When reading frames, we need to use the fragment for the correct
> stream. Sometimes the "current" fragment is not the same as the one
> the frame is for.
>
> Found by Chromium's ClusterFuzz:
> https://crbug.com/906392 and
On 12/20/2018 6:40 PM, Michael Niedermayer wrote:
> Future gcc may no longer support this
>
> Signed-off-by: Michael Niedermayer
> ---
> libpostproc/postprocess_template.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libpostproc/postprocess_template.c
>
On 18/12/2018 09:54, Zachary Zhou wrote:
> Swap width and height when do clock/cclock rotation
> Add reveral/reveral_flip options
>
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> -hwaccel_output_format vaapi -i input.264 -vf "transpose_vaapi=clock_flip"
> -c:v h264_vaapi output.h264
This avoids problems if %4 is the stack pointer
the constraints do not allow %4 to be the stack pointer but gcc 9 may
no longer support specifying such constraints
Signed-off-by: Michael Niedermayer
---
libpostproc/postprocess_template.c | 8
1 file changed, 4 insertions(+), 4
Future gcc may no longer support this
Signed-off-by: Michael Niedermayer
---
libpostproc/postprocess_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libpostproc/postprocess_template.c
b/libpostproc/postprocess_template.c
index 485eb5cfc0..b0adfd168c 100644
---
On 12/12/2018 16:26, Guo, Yejun wrote:
> This patchset contains two patches.
> - the first patch (this patch) finished the code and ask for upstream.
> - the second patch is just a quick example on how to generate ROI info.
>
> The encoders such as libx264 support different QPs offset for
On 12/20/2018 5:45 PM, Mark Thompson wrote:
> On 20/12/2018 15:39, James Almer wrote:
>> delta_frame_id_minus1 is not a single value in the bitstream, and can
>> store values up to 17 bits wide.
>>
>> Fixes parsing files with frame ids.
>>
>> Signed-off-by: James Almer
>> ---
>> See
>>
Use the frame-skip feature to maintain a specified framerate from the
point of view of the driver.
---
Not finished - mostly a POC for using timestamps rather than the suggestion of
adding a new side-data type to trigger the VFR frame-skip feature. Kindof
works, with the iHD driver only -
Allow setting the mode explicitly, and try to make a sensible choice
given the available parameters if not.
---
From patch:
// * If the user has set a mode explicitly with the rc_mode option,
// use it and fail if it is not available.
// * If an explicit QP option has been set, use
---
libavcodec/vaapi_encode_vp9.c | 104 +-
1 file changed, 51 insertions(+), 53 deletions(-)
diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
index 94f29c0483..97142dcc49 100644
--- a/libavcodec/vaapi_encode_vp9.c
+++
---
libavcodec/vaapi_encode_vp9.c | 41 +--
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
index 97142dcc49..f89fd0d07a 100644
--- a/libavcodec/vaapi_encode_vp9.c
+++
Doesn't change anything, but makes the behaviour better match that of the
other codecs (the CONSTANT_QUALITY_ONLY flag already ensures that CQP is
the only RC mode selectable for MJPEG).
---
libavcodec/vaapi_encode_mjpeg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
No supported encode driver requires the pool to be fixed-size, so just
remove this constraint.
---
libavcodec/vaapi_encode.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index eec083da4f..b4e9fadaee 100644
---
---
libavcodec/vaapi_encode_vp8.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
index 166636cd84..ddbe4c9075 100644
--- a/libavcodec/vaapi_encode_vp8.c
+++ b/libavcodec/vaapi_encode_vp8.c
@@
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
On 20/12/2018 15:39, James Almer wrote:
> delta_frame_id_minus1 is not a single value in the bitstream, and can
> store values up to 17 bits wide.
>
> Fixes parsing files with frame ids.
>
> Signed-off-by: James Almer
> ---
> See
>
---
One minor fix here since last time (dpb_delay was broken with B-depth > 1).
libavcodec/vaapi_encode_h264.c | 375 +++--
1 file changed, 309 insertions(+), 66 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index
---
libavcodec/vaapi_encode_mpeg2.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c
index 9d42c3e644..174611ff24 100644
--- a/libavcodec/vaapi_encode_mpeg2.c
+++
---
libavcodec/vaapi_encode.c | 15 ---
libavcodec/vaapi_encode.h | 4
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index eda8a36299..d8bedbe162 100644
--- a/libavcodec/vaapi_encode.c
+++
Also fixes QP going out of range when modified by the quant factor/offset
values, and clarifies the QP behaviour for >8-bit modes.
---
libavcodec/vaapi_encode_h265.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git
Also fixes QP going out of range when modified by the quant factor/offset
values.
---
libavcodec/vaapi_encode_h264.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index
The reference picture sets are now constructed directly from the DPB
information.
---
libavcodec/vaapi_encode_h265.c | 191 +++--
1 file changed, 111 insertions(+), 80 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index
From: Mohammad Izadi
The dynamic metadata contains data for color volume transform - application 4
of SMPTE 2094-40:2016 standard. The data comes from HEVC in the
SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35.
I'll add support to HEVC in a follow-up.
---
libavutil/Makefile | 2 +
Thank you! Please go ahead and push the patch.
--
Best,
Mohammad
On Thu, Dec 20, 2018 at 11:07 AM Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:
> On Thu, Dec 20, 2018 at 7:18 PM Mohammad Izadi
> wrote:
>
> > Hi Vittorio,
> >
> > Thank you for your feedback ! Here is my answers to your
On Thu, Dec 20, 2018 at 7:18 PM Mohammad Izadi wrote:
> Hi Vittorio,
>
> Thank you for your feedback ! Here is my answers to your questions:
>
> I thought we were going to rename the header as dynamic_hdr.h since it may
> contain multiple variants of metadata.
> Also I believe "metadata" in the
I noticed that a patch was submitted to the developers list in April 2018 that
adds OpenCL scale filter support to ffmpeg. It doesn't appear to have been
added to the master development branch. What's the status? Also, are there
plans to add a yadif or similar OpenCL filter?
Best regards,
Hi Vittorio,
Thank you for your feedback ! Here is my answers to your questions:
I thought we were going to rename the header as dynamic_hdr.h since it may
contain multiple variants of metadata.
Also I believe "metadata" in the name is redundant, but won't insist too
much if you have strong
On Thu, 20 Dec 2018 at 16:30, Tomas Härdin wrote:
> Trivial enough. You could probably roll many or even all of these
> patches together
>
Thanks for your feedback. I was reluctant to submit so many patches, but I
worried at the time that combining them would require an overly long commit
On Thu, 20 Dec 2018 at 16:30, Tomas Härdin wrote:
> I have a feeling this could be sped up further by just doing *xored =
> histogram[0] == ZMBV_BLOCK*ZMBV_BLOCK after the loops, if [PATCH 3/4]
> is applied before this. Computing both histogram and xored in the loop
> seems pointless.
>
You're
Hi,
hope somebody can help solving a segmentation fault caused by using the
h264_v4l2m2m encoder on an Samsung Exynos5422.
I tested the encoder using the unmodified examples (git master):
- encode_video.c
- transcoding.c
> # ./encode_video out h264_v4l2m2m
> [h264_v4l2m2m @ 0x49e150] driver
ons 2018-12-19 klockan 22:00 + skrev matthew.w.fearn...@gmail.com:
> > From: Matthew Fearnley
>
> score_tab[] was only declared/initialised for elements 0..255, but with
> block sizes set to 16*16, it was possible to reach 256.
>
> This limit could also be overflowed in the histogram,
ons 2018-12-19 klockan 22:00 + skrev matthew.w.fearn...@gmail.com:
> > From: Matthew Fearnley
>
> All the values in score_tab are positive or 0, and so should be the sum
> returned by block_cmp().
>
> The logic in zmbv_me() assumes that all 'bv' values will be non-negative,
> in order to
ons 2018-12-19 klockan 22:00 + skrev matthew.w.fearn...@gmail.com:
> > From: Matthew Fearnley
>
> Store the value of *xored computed within block_cmp() in a local variable,
> and only update the *xored parameter at the same time as *mx,*my are set.
> This ensures that the value of *xored is
ons 2018-12-19 klockan 22:00 + skrev matthew.w.fearn...@gmail.com:
> > From: Matthew Fearnley
>
> If *xored is 0, then histogram[0]==bw*bh and histogram[1..255]==0.
>
> Because histogram[0] is skipped over for the entropy calculation, the
> return value is always 0 when *xored==0, so we
delta_frame_id_minus1 is not a single value in the bitstream, and can
store values up to 17 bits wide.
Fixes parsing files with frame ids.
Signed-off-by: James Almer
---
See
https://code.videolan.org/videolan/dav1d/uploads/a23d47dda3011a8e39ab1ac7c508b220/input.ivf
libavcodec/cbs_av1.h
tor 2018-12-20 klockan 10:53 +0800 skrev gxw:
> The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is
> still 32
> in function ff_hevc_sao_edge_filter_8_msa. So, use
> AV_INPUT_BUFFER_PADDING_SIZE directly.
> Fate tests passed.
> ---
> libavcodec/mips/hevc_lpf_sao_msa.c |
Andrey Semashev (2018-12-10):
> This commit adds a new set of functions to avio and url subsystems, which
> allow users to invoke IO buffer synchronization with the underlying media.
> The most obvious target for this extension if the filesystem streams. Invoking
> IO synchronization allows user
On 12/19/18 4:33 PM, Carl Eugen Hoyos wrote:
How can we reproduce the assertion failure?
I do not have a scenario for ffmpeg command line utility, I have it in a
proprietary project based on libav*, here I have custom I/O attached to
AVFormatContext, initial buffer was 64K, input is MPEGTS
Paul B Mahol (2018-12-20):
> It is an obvious attack.
It was a technical comment wrapped in very polite and welcoming
language. Maybe it was an obvious mistake (but if it is obvious, I
cannot see it), but it certainly was not an attack.
Regards,
--
Nicolas George
signature.asc
Description:
On 12/20/18, Nicolas George wrote:
> Paul B Mahol (2018-12-20):
>> Please refrain from telling me such obvious untrue things.
>
> How can it be obvious if it is untrue?
>
> Rather than taking it as an attack, I think a better approach would be
> to assume the comment was given in good faith and
Paul B Mahol (2018-12-20):
> Please refrain from telling me such obvious untrue things.
How can it be obvious if it is untrue?
Rather than taking it as an attack, I think a better approach would be
to assume the comment was given in good faith and use the single line
you answer to give an useful
On 12/19/18 8:49 PM, Michael Niedermayer wrote:
On Wed, Dec 19, 2018 at 02:33:49PM +0200, Artyom Lebedev wrote:
It was reallocated even if the exisiting buffer is larger than needed one,
thus unnecessary shrinking it.
aviobuf.c |3 +++
1 file changed, 3 insertions(+)
On 12/20/18, Carl Eugen Hoyos wrote:
> 2018-12-19 21:32 GMT+01:00, Paul B Mahol :
>
>> +static av_cold int photocd_decode_init(AVCodecContext *avctx)
>> +{
>> +avctx->pix_fmt= AV_PIX_FMT_YUV420P;
>
> I very much welcome this patch but it appears that the colourspace
> conversion is
53 matches
Mail list logo
