On 1/6/19 4:43 AM, Carl Eugen Hoyos wrote:
> 2019-01-03 6:19 GMT+01:00, David Bryant :
>> On 12/28/18 3:56 AM, Paul B Mahol wrote:
>>> On 12/24/18, Derek Buitenhuis wrote:
On 24/12/2018 17:47, David Bryant wrote:
> I want to do that, but am swamped at work right now, so it will probably
The encoders such as libx264 support different QPs offset for different MBs,
it makes possible for ROI-based encoding. It makes sense to add support
within ffmpeg to generate/accept ROI infos and pass into encoders.
Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
generates
Signed-off-by: Guo, Yejun
---
doc/APIchanges | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 5889fb2..a39a3ff 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2019-01-08
This patch just enables the path from ffmpeg to libx264,
the more encoders can be added later.
Signed-off-by: Guo, Yejun
---
libavcodec/libx264.c | 62
1 file changed, 62 insertions(+)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
On Tue, 8 Jan 2019 at 00:26, Mohammad Izadi wrote:
> ---
> libavcodec/hevc_sei.c | 236 --
> libavcodec/hevc_sei.h | 6 ++
> libavcodec/hevcdec.c | 19
> 3 files changed, 255 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_sei.c
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Tuesday, January 08, 2019 3:20 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V6 2/2]
On 1/7/2019 8:55 PM, Mohammad Izadi wrote:
> ---
> libavcodec/hevc_sei.c | 236 --
> libavcodec/hevc_sei.h | 6 ++
> libavcodec/hevcdec.c | 19
> 3 files changed, 255 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_sei.c
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Tuesday, January 08, 2019 3:21 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V6 1/2] avutil: add ROI
---
libavcodec/hevc_sei.c | 236 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 19
3 files changed, 255 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..7e59bf0813 100644
---
On 1/7/19, Michael Niedermayer wrote:
> On Mon, Jan 07, 2019 at 08:51:33PM +0100, Paul B Mahol wrote:
>> On 1/7/19, https://ieeexplore.ieee.org/document/7291728Michael
>> Niedermayer wrote:
>> > On Mon, Jan 07, 2019 at 07:41:04PM +0100, Paul B Mahol wrote:
>> >> On 1/7/19, Michael Niedermayer
On Mon, Jan 07, 2019 at 08:51:33PM +0100, Paul B Mahol wrote:
> On 1/7/19, https://ieeexplore.ieee.org/document/7291728Michael
> Niedermayer wrote:
> > On Mon, Jan 07, 2019 at 07:41:04PM +0100, Paul B Mahol wrote:
> >> On 1/7/19, Michael Niedermayer wrote:
> >> > Fixes: Timeout
> >> > Fixes:
>
On 1/7/19, https://ieeexplore.ieee.org/document/7291728Michael
Niedermayer wrote:
> On Mon, Jan 07, 2019 at 07:41:04PM +0100, Paul B Mahol wrote:
>> On 1/7/19, Michael Niedermayer wrote:
>> > Fixes: Timeout
>> > Fixes:
>> >
On Mon, Jan 07, 2019 at 07:41:04PM +0100, Paul B Mahol wrote:
> On 1/7/19, Michael Niedermayer wrote:
> > Fixes: Timeout
> > Fixes:
> > 11354/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> >
> > Before: Executed
> >
On Mon, Jan 07, 2019 at 10:45:02PM +1100, Peter Ross wrote:
> ---
> this table is used at vp3_decode_init time, and is needlessly uint32_t.
> will push in a day or so.
>
> libavcodec/vp3data.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp3data.h
On Tue, Jan 08, 2019 at 03:54:14AM +0800, Guo, Yejun wrote:
> The encoders such as libx264 support different QPs offset for different MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
>
> Typical
On Tue, Jan 08, 2019 at 03:54:38AM +0800, Guo, Yejun wrote:
> This patch just enables the path from ffmpeg to libx264,
> the more encoders can be added later.
>
> Signed-off-by: Guo, Yejun
> ---
> libavcodec/libx264.c | 67
>
> 1 file
On Mon, Jan 07, 2019 at 10:01:22AM +0200, Lauri Kasanen wrote:
> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> yuv420p16be \
> -s 1920x1728 -f null -vframes 100 -v error -nostats -
>
> 9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
> Fate passes, each
On 1/7/19, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 11354/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
>
> Before: Executed
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> in 9470 ms
> After : Executed
>
On Mon, Jan 07, 2019 at 07:24:53PM +0200, Lauri Kasanen wrote:
> On Mon, 7 Jan 2019 17:42:58 +0100
> Michael Niedermayer wrote:
>
> > > According to a 2010 comparison
> > > https://keyj.emphy.de/video-encoder-comparison/
> > > x264 constrained baseline (everything off) takes something like 30%
>
Hi,
On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote:
> On Mon, 7 Jan 2019 12:02:58 -0500
> "Ronald S. Bultje" wrote:
>
> > Have you considered vp8? It may sound weird but this is basically what
> vp8
> > was great at: being really simple to decode.
>
> VP8 has a reputation of being slow,
On Mon, 7 Jan 2019 17:42:58 +0100
Michael Niedermayer wrote:
> > According to a 2010 comparison
> > https://keyj.emphy.de/video-encoder-comparison/
> > x264 constrained baseline (everything off) takes something like 30%
> > longer to decode vs xvid at the same rate. Probably more because that
>
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 27
libavfilter/Makefile | 1 +
libavfilter/af_anlmdn.c | 257 +++
libavfilter/allfilters.c | 1 +
4 files changed, 286 insertions(+)
create mode 100644 libavfilter/af_anlmdn.c
diff
Hi Lauri,
On Mon, Jan 7, 2019 at 3:15 AM Lauri Kasanen wrote:
> If you were to design a video codec for a very low-end decoder, what
> would it look like?
>
Have you considered vp8? It may sound weird but this is basically what vp8
was great at: being really simple to decode.
Ronald
On Mon, Jan 07, 2019 at 03:38:35PM +0200, Lauri Kasanen wrote:
> On Mon, 7 Jan 2019 13:44:56 +0100
> Michael Niedermayer wrote:
>
> > > The modern approaches, DCT, FFT, wavelets and such transforms, are all
> > > likely too slow to decode.
> >
> > you said it can do mpeg1 and xvid, these are
Signed-off-by: Dmitry Humeniuk
---
Changelog|1 +
doc/filters.texi | 23 +
libavfilter/Makefile |1 +
libavfilter/af_dumpwave.c| 234
libavfilter/allfilters.c |1 +
libavfilter/version.h
On Mon, 7 Jan 2019 13:44:56 +0100
Michael Niedermayer wrote:
> > The modern approaches, DCT, FFT, wavelets and such transforms, are all
> > likely too slow to decode.
>
> you said it can do mpeg1 and xvid, these are DCT based
> have you tried H.264 ? (i imagine that might with asm optimizations
On Mon, Jan 07, 2019 at 01:44:56PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 07, 2019 at 10:17:48AM +0200, Lauri Kasanen wrote:
> > Hi,
> >
> > If you were to design a video codec for a very low-end decoder, what
> > would it look like?
> >
> > My target is MIPS 100MHz, and it should
On Mon, Jan 07, 2019 at 10:17:48AM +0200, Lauri Kasanen wrote:
> Hi,
>
> If you were to design a video codec for a very low-end decoder, what
> would it look like?
>
> My target is MIPS 100MHz, and it should decode 320x240x30 in full speed
> in software, with headroom for audio too. Seems all
Vittorio Giovara (12019-01-07):
> size_t represents a length
> so using it for video dimensions makes perfect sense.
size_t represents a system-dependent size of object in memory, not any
"length". There is no reason to have different resolution
On Sat, Jan 5, 2019 at 2:15 AM James Almer wrote:
> On 1/4/2019 10:08 AM, Vittorio Giovara wrote:
> > On Fri, Jan 4, 2019 at 12:22 PM Nicolas George wrote:
> >
> >> Rostislav Pehlivanov (12019-01-04):
> +typedef struct AVRegionOfInterest {
> +size_t self_size;
> +size_t
This patch just enables the path from ffmpeg to libx264,
the more encoders can be added later.
Signed-off-by: Guo, Yejun
---
libavcodec/libx264.c | 67
1 file changed, 67 insertions(+)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
The encoders such as libx264 support different QPs offset for different MBs,
it makes possible for ROI-based encoding. It makes sense to add support
within ffmpeg to generate/accept ROI infos and pass into encoders.
Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
generates
On Mon, Jan 07, 2019 at 12:42:24PM +0100, Carl Eugen Hoyos wrote:
> 2019-01-07 12:40 GMT+01:00, Peter Ross :
> > macros for reading and writing 64-bit aligned little-endian values.
> >
> > these macros are used by the DST decoder and give a performance boost
> > on big-endian platforms that where
---
this table is used at vp3_decode_init time, and is needlessly uint32_t.
will push in a day or so.
libavcodec/vp3data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vp3data.h b/libavcodec/vp3data.h
index 3884bca878..c82b1b3a86 100644
---
---
updated accordingly...
libavcodec/dstdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dstdec.c b/libavcodec/dstdec.c
index 511861f4d2..0614c99c4b 100644
--- a/libavcodec/dstdec.c
+++ b/libavcodec/dstdec.c
@@ -343,8 +343,8 @@ static int
2019-01-07 12:40 GMT+01:00, Peter Ross :
> macros for reading and writing 64-bit aligned little-endian values.
>
> these macros are used by the DST decoder and give a performance boost
> on big-endian platforms that where the compiler must normally guard
> against unaligned memory access.
I
macros for reading and writing 64-bit aligned little-endian values.
these macros are used by the DST decoder and give a performance boost
on big-endian platforms that where the compiler must normally guard
against unaligned memory access.
---
libavutil/intreadwrite.h | 15 +++
1 file
Hi,
If you were to design a video codec for a very low-end decoder, what
would it look like?
My target is MIPS 100MHz, and it should decode 320x240x30 in full speed
in software, with headroom for audio too. Seems all the codec research
in last 20 years has been more quality with more overhead,
38 matches
Mail list logo
