> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Wednesday, December 26, 2018 09:15
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope
On Wed, Dec 26, 2018 at 12:42 AM Michael Niedermayer
wrote:
>
> On Mon, Dec 10, 2018 at 06:23:54PM +0800, Linjie Fu wrote:
> > Given that leading_zero_8bits can be included many times at the beginning
> > of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
> > in last frame and
On 12/25/2018 7:15 PM, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 11502/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
> Before: Executed
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
> in 11294 ms
> After : Executed
On Tue, 25 Dec 2018 at 22:17 Michael Niedermayer
wrote:
> Fixes: Timeout
> Fixes:
> 11502/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
> Before: Executed
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
> in 11294 ms
> After :
On Mon, Dec 10, 2018 at 06:23:54PM +0800, Linjie Fu wrote:
> Given that leading_zero_8bits can be included many times at the beginning
> of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
> in last frame and may lead to some warnings in parse_nal_units when s->flags
> is set to
Fixes: Timeout
Fixes:
11502/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
Before: Executed
clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
in 11294 ms
After : Executed
Otherwise it is left to the value from the previous iteration
Signed-off-by: Michael Niedermayer
---
libavcodec/exr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 13755e1e6e..0f8b0fda9f 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@
Fixes: Out of memory
Fixes:
11582/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5730204559867904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/exr.c | 5 +
1 file
Frame properties were not copied, so e.g. PTS was not set for the last frame.
Regression since ef3babb2c70f564dc1634b3f29c6e35a2b2dc239.
Signed-off-by: Marton Balint
---
libavfilter/af_asetnsamples.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/af_asetnsamples.c
Signed-off-by: Moritz Barsnick
---
doc/bitstream_filters.texi | 4
libavcodec/realtime_bsf.c | 7 +--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 8c71100460..860c555c3f 100644
---
Works for video and audio streams.
Similar to the -re option in ffmpeg that only works for input files,
and is only implemented for the command line tool, not available in
the libraries.
Implementation mostly taken from libavfilter/f_realtime.c.
Signed-off-by: Moritz Barsnick
---
The realtime bitstream filter is modeled exactly along the
realtime/arealtime filters, but works on bitstream level, allowing to use
them with the copy codec.
It can be considered a proof of concept, as ffmpeg offers the "-re" option
to achieve this, but:
- the "-re" option is not available in
Signed-off-by: Moritz Barsnick
---
This adds two double precision divisions per frame, which seems acceptable.
I'm not sure scaling the limit by the factor is the correct idea. It feels
right regarding the discontinuities, but not according to the limit option's
description.
doc/filters.texi
On Tue, 25 Dec 2018, Tomas Härdin wrote:
sön 2018-12-23 klockan 01:12 +0100 skrev Marton Balint:
> Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index
On Sun, 23 Dec 2018, Paul B Mahol wrote:
On 12/23/18, Marton Balint wrote:
We no longer use strftime directly but use av_timegm to get an int64_t
timestamp.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
LGTM
Thanks,
On Tue, Dec 25, 2018 at 02:11:45PM +0100, Paul B Mahol wrote:
> On 12/25/18, Michael Niedermayer wrote:
> > On Mon, Dec 24, 2018 at 06:34:30PM +0100, Paul B Mahol wrote:
> > [...]
> >> -static const char *get_channel_name(int channel_id)
> >> +const char *av_channel_name(enum AVChannel
On 12/25/18, Paul B Mahol wrote:
> On 12/25/18, Michael Niedermayer wrote:
>> On Mon, Dec 24, 2018 at 11:54:31PM +, Kieran Kunhya wrote:
>>> >
>>> > commit 0ca7a8deeffd33e05ae15a447259b32b6678c727 (HEAD -> master)
>>> > Author: Michael Niedermayer
>>> > Date: Mon Dec 24 01:14:50 2018
On 12/25/18, Michael Niedermayer wrote:
> On Mon, Dec 24, 2018 at 11:54:31PM +, Kieran Kunhya wrote:
>> >
>> > commit 0ca7a8deeffd33e05ae15a447259b32b6678c727 (HEAD -> master)
>> > Author: Michael Niedermayer
>> > Date: Mon Dec 24 01:14:50 2018 +0100
>> >
>> > avcodec/lagarith:
On 12/25/18, Michael Niedermayer wrote:
> On Mon, Dec 24, 2018 at 06:34:30PM +0100, Paul B Mahol wrote:
> [...]
>> -static const char *get_channel_name(int channel_id)
>> +const char *av_channel_name(enum AVChannel channel_id)
>> {
>
>> if (channel_id < 0 || channel_id >=
This patchset contains two patches.
- the first patch finished the code and ask for upstreaming.
- the second patch (this patch) is just a quick example and
not ask for upstreaming.
to verify it, the command line looks like:
./ffmpeg -i .../path_to_1920x1080_video_file -vf scale=1920:1080 -c:v
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 different MBs,
it makes possible for ROI-based encoding.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Friday, December 21, 2018 7:39 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavfi/vf_hwmap: make hwunmap from
> software frame work.
>
>
On Mon, Dec 24, 2018 at 11:54:31PM +, Kieran Kunhya wrote:
> >
> > commit 0ca7a8deeffd33e05ae15a447259b32b6678c727 (HEAD -> master)
> > Author: Michael Niedermayer
> > Date: Mon Dec 24 01:14:50 2018 +0100
> >
> > avcodec/lagarith: Optimize case with singleton probability distribution
>
On Tue, Dec 25, 2018 at 15:16:17 +0800, Zachary Zhou wrote:
> It supports ICL platform.
> H2H (HDR to HDR): P010 -> RGB10
> H2S (HDR to SDR): P010 -> RGB8
>
> libva commit for HDR10
> https://github.com/intel/libva/commit/cf11abe5e1b9c93ee75cf974076957162c1605b9
BTW, there's a typo in your libva
On 12/25/18, Liu Steven wrote:
>
>
>> 在 2018年12月25日，上午1:28，Paul B Mahol 写道：
>>
>> On 12/24/18, Michael Niedermayer wrote:
>>> On Fri, Dec 21, 2018 at 06:09:50PM +0800, Steven Liu wrote:
Before patch:
init nbits = 17, get 1 samples, average cost: 16105 us
After patch:
lör 2018-12-22 klockan 15:54 + skrev Matthew Fearnley:
> > On 22 Dec 2018, at 12:15, Tomas Härdin wrote:
> >
> > tor 2018-12-20 klockan 17:48 + skrev Matthew Fearnley:
> > > > > > On Thu, 20 Dec 2018 at 16:30, Tomas Härdin > > > > > .se> wrote:
> > > >
> > > > Trivial enough. You could
lör 2018-12-22 klockan 15:32 + skrev Matthew Fearnley:
> > > >
> > > Note that bw,bh aren't guaranteed to equal ZMBV_BLOCK, so `histogram[0] ==
> > > bw*bh` would have to be used to guard against those (literal) edge cases.
> >
> > Right, yes. But if we have block sizes other than
sön 2018-12-23 klockan 01:12 +0100 skrev Marton Balint:
> > Signed-off-by: Marton Balint
> ---
> libavformat/mxfdec.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index d78f8ad2e4..0553adcb06 100644
> ---
sön 2018-12-23 klockan 01:12 +0100 skrev Marton Balint:
> > Signed-off-by: Marton Balint
> ---
> libavformat/mxfenc.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 5e7bd212dc..032ee3bf3d 100644
> ---
29 matches
Mail list logo
