On Sun, Feb 19, 2017 at 2:00 AM, Marton Balint wrote:
> Reallocating a wrapped avframe invalidates internal pointers, such as extended
> data.
>
> FFmpeg has another way of passing AVFrames to muxers, but it seems the API
> (av_write_uncoded_frame) is not implemented in the ffmpeg CLI yet.
>
> Sig
2017-02-19 10:22 GMT+08:00 Pavel Koshevoy :
> On 02/18/2017 07:04 PM, Steven Liu wrote:
>
>>
>>
>> 2017-02-19 6:46 GMT+08:00 > pkoshe...@gmail.com>>:
>>
>> From: Pavel Koshevoy mailto:pkoshe...@gmail.com
>> >>
>>
>> ---
>> libavfilter/af_atempo.c | 6 +++---
>> 1 file changed, 3 i
On 02/18/2017 07:04 PM, Steven Liu wrote:
2017-02-19 6:46 GMT+08:00 mailto:pkoshe...@gmail.com>>:
From: Pavel Koshevoy mailto:pkoshe...@gmail.com>>
---
libavfilter/af_atempo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/af_atempo.
2017-02-19 6:46 GMT+08:00 :
> From: Pavel Koshevoy
>
> ---
> libavfilter/af_atempo.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> index a487882..eb62656 100644
> --- a/libavfilter/af_atempo.c
> +++ b/libavfilte
Reallocating a wrapped avframe invalidates internal pointers, such as extended
data.
FFmpeg has another way of passing AVFrames to muxers, but it seems the API
(av_write_uncoded_frame) is not implemented in the ffmpeg CLI yet.
Signed-off-by: Marton Balint
---
libavcodec/utils.c | 4 ++--
1 file
From: Pavel Koshevoy
---
libavfilter/af_atempo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index a487882..eb62656 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -697,11 +697,11 @@ static int
Hi,
> My name is George and I am a PhD student at Stanford. I am interested
> in the MPEG-4 ALS codec project for this year's GSoC program.
>
> Should I go straight into attempting to fix a bug of ALS on the
> tracker as a qualification task and if so do you have a specific one
> to recommend?
y
On 2/18/17, Steinar H. Gunderson wrote:
> The quantization table is stored in the natural order, but when we
> access it, we use an index that's in zigzag order, causing us to read
> the wrong value. This causes artifacts, especially in areas with
> horizontal or vertical edges. The artifacts look
The quantization table is stored in the natural order, but when we
access it, we use an index that's in zigzag order, causing us to read
the wrong value. This causes artifacts, especially in areas with
horizontal or vertical edges. The artifacts look a lot like the
DCT ringing artifacts you'd expec
On Sat, 18 Feb 2017, Josh de Kock wrote:
On 18/02/2017 00:51, Marton Balint wrote:
On Fri, 17 Feb 2017, Josh de Kock wrote:
Also add support for level 1.0 explicitly.
What is the use case for this? Reducing the number of colors?
Pretty much.
I don't think you can reduce the number o
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
12 matches
Mail list logo