Re: [FFmpeg-devel] [PATCH] avcodec/utils: do not reallocate packet buffer for AV_CODEC_ID_WRAPPED_AVFRAME

[Hendrik Leppkes]

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.
>
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/utils.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index f4085bf..d09384a 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1926,7 +1926,7 @@ int attribute_align_arg 
> avcodec_encode_audio2(AVCodecContext *avctx,
>  }
>
>  if (!ret) {
> -if (needs_realloc && avpkt->data) {
> +if (needs_realloc && avpkt->data && avctx->codec_id != 
> AV_CODEC_ID_WRAPPED_AVFRAME) {
>  ret = av_buffer_realloc(>buf, avpkt->size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
>  if (ret >= 0)
>  avpkt->data = avpkt->buf->data;
> @@ -2027,7 +2027,7 @@ int attribute_align_arg 
> avcodec_encode_video2(AVCodecContext *avctx,
>  else if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
>  avpkt->pts = avpkt->dts = frame->pts;
>
> -if (needs_realloc && avpkt->data) {
> +if (needs_realloc && avpkt->data && avctx->codec_id != 
> AV_CODEC_ID_WRAPPED_AVFRAME) {
>  ret = av_buffer_realloc(>buf, avpkt->size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
>  if (ret >= 0)
>  avpkt->data = avpkt->buf->data;
> --
> 2.10.2

Maybe this condition should be placed on the top where needs_realloc
is defined, so its never 1 in the first place?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: fix drift calculation, ticket #6157

[Steven Liu]

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 > >>
>>
>> ---
>>  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 yae_adjust_position(ATempoContext
>> *atempo)
>>  AudioFragment   *frag = yae_curr_frag(atempo);
>>
>>  const double prev_output_position =
>> -(double)(prev->position[1] - atempo->origin[1] +
>> atempo->window / 2);
>> +(double)(prev->position[1] - atempo->origin[1] +
>> atempo->window /
>> 2) *
>> +atempo->tempo;
>>
>>  const double ideal_output_position =
>> -(double)(prev->position[0] - atempo->origin[0] +
>> atempo->window /
>> 2) /
>> -atempo->tempo;
>> +(double)(prev->position[0] - atempo->origin[0] +
>> atempo->window / 2);
>>
>>  const int drift = (int)(prev_output_position -
>> ideal_output_position);
>>
>> --
>> 2.6.6
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org 
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>>
>>
>>
>> LGTM
>>
>>
>> Thanks
>>
>
>
> Then would someone apply this, please?
>

Will apply after 24 hours!

>
>
> Thank you,
>
> Pavel
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: fix drift calculation, ticket #6157

[Pavel Koshevoy]

On 02/18/2017 07:04 PM, Steven Liu wrote:



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/libavfilter/af_atempo.c
@@ -697,11 +697,11 @@ static int yae_adjust_position(ATempoContext *atempo)
 AudioFragment   *frag = yae_curr_frag(atempo);

 const double prev_output_position =
-(double)(prev->position[1] - atempo->origin[1] + atempo->window / 
2);
+(double)(prev->position[1] - atempo->origin[1] + atempo->window /
2) *
+atempo->tempo;

 const double ideal_output_position =
-(double)(prev->position[0] - atempo->origin[0] + atempo->window /
2) /
-atempo->tempo;
+(double)(prev->position[0] - atempo->origin[0] + atempo->window / 
2);

 const int drift = (int)(prev_output_position - ideal_output_position);

--
2.6.6

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org 
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel




LGTM


Thanks



Then would someone apply this, please?


Thank you,

Pavel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: fix drift calculation, ticket #6157

[Steven Liu]

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/libavfilter/af_atempo.c
> @@ -697,11 +697,11 @@ static int yae_adjust_position(ATempoContext
> *atempo)
>  AudioFragment   *frag = yae_curr_frag(atempo);
>
>  const double prev_output_position =
> -(double)(prev->position[1] - atempo->origin[1] + atempo->window /
> 2);
> +(double)(prev->position[1] - atempo->origin[1] + atempo->window /
> 2) *
> +atempo->tempo;
>
>  const double ideal_output_position =
> -(double)(prev->position[0] - atempo->origin[0] + atempo->window /
> 2) /
> -atempo->tempo;
> +(double)(prev->position[0] - atempo->origin[0] + atempo->window /
> 2);
>
>  const int drift = (int)(prev_output_position - ideal_output_position);
>
> --
> 2.6.6
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


LGTM


Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/utils: do not reallocate packet buffer for AV_CODEC_ID_WRAPPED_AVFRAME

[Marton Balint]

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 changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index f4085bf..d09384a 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1926,7 +1926,7 @@ int attribute_align_arg 
avcodec_encode_audio2(AVCodecContext *avctx,
 }
 
 if (!ret) {
-if (needs_realloc && avpkt->data) {
+if (needs_realloc && avpkt->data && avctx->codec_id != 
AV_CODEC_ID_WRAPPED_AVFRAME) {
 ret = av_buffer_realloc(>buf, avpkt->size + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (ret >= 0)
 avpkt->data = avpkt->buf->data;
@@ -2027,7 +2027,7 @@ int attribute_align_arg 
avcodec_encode_video2(AVCodecContext *avctx,
 else if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
 avpkt->pts = avpkt->dts = frame->pts;
 
-if (needs_realloc && avpkt->data) {
+if (needs_realloc && avpkt->data && avctx->codec_id != 
AV_CODEC_ID_WRAPPED_AVFRAME) {
 ret = av_buffer_realloc(>buf, avpkt->size + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (ret >= 0)
 avpkt->data = avpkt->buf->data;
-- 
2.10.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/af_atempo: fix drift calculation, ticket #6157

[pkoshevoy]

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 yae_adjust_position(ATempoContext *atempo)
 AudioFragment   *frag = yae_curr_frag(atempo);
 
 const double prev_output_position =
-(double)(prev->position[1] - atempo->origin[1] + atempo->window / 2);
+(double)(prev->position[1] - atempo->origin[1] + atempo->window / 2) *
+atempo->tempo;
 
 const double ideal_output_position =
-(double)(prev->position[0] - atempo->origin[0] + atempo->window / 2) /
-atempo->tempo;
+(double)(prev->position[0] - atempo->origin[0] + atempo->window / 2);
 
 const int drift = (int)(prev_output_position - ideal_output_position);
 
-- 
2.6.6

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC 2017 MPEG-4 ALS codec project

[Thilo Borgmann]

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?

yes you might do your qualification task right away. 

Hmm... you might try to fix #5297. If you encounter the use of get_unary() have 
a close look at this. IIRC it has to handle the termination bit differently 
than default to fix this issue. (I might misremember, though).

We should continue this thread off-list and mail directly for discussion.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] speedhq: fix decoding artifacts

[Paul B Mahol]

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 a lot like the
> DCT ringing artifacts you'd expect to see from a low-bitrate file,
> but when comparing to NewTek's own decoder, it's obvious they're not
> supposed to be there.
>
> Fix by simply storing the scaled quantization table in zigzag order.
> Performance is unchanged.
> ---
>  libavcodec/speedhq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
> index 45ee37a4e6..60efb0222b 100644
> --- a/libavcodec/speedhq.c
> +++ b/libavcodec/speedhq.c
> @@ -409,7 +409,7 @@ static int decode_speedhq_field(const SHQContext *s,
> const uint8_t *buf, int buf
>  static void compute_quant_matrix(int *output, int qscale)
>  {
>  int i;
> -for (i = 0; i < 64; i++) output[i] = unscaled_quant_matrix[i] * qscale;
> +for (i = 0; i < 64; i++) output[i] =
> unscaled_quant_matrix[ff_zigzag_direct[i]] * qscale;
>  }
>
>  static int speedhq_decode_frame(AVCodecContext *avctx,
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libzvbi: base support for multiple levels

[Marton Balint]

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 of colors based on teletext
level, because libzvbi uses high (>32) colors for navigation, which is
also part of level 1.0.

Also, I don't think you can skip fix_transparency.



Does level 1.0 support transparency?


Not as a color, but as a feature. See Start Box/End Box. Typical for 
subtitles.





And by reducing to level 1.0, you are excluding a lot of users, many
countries use the extra international characters level 1.5 provides.



1.5 could be done instead.


If you only want to reduce the number of colors, then I prefer an option
which makes the code go through every pixel, find the minimum color
value, and sets nb_colors to that.  Still a hack, but IMHO small enough
to be acceptable, until subtitle filters are implemented, and you can do
this with a filter.



Not entirely sure what you mean by this, shouldn't the nb_colors be set
based on the CLUT?


As long as according to zvbi docs it has internal colors from index 32 to 
39 for navigation, it does not matter how many CLUT the page uses.


What I am saying is that it's simpler to add a txt_reduce_colors 
option, and if that is set, find the maximum used color index, and set 
nb_colors to that + 1.


I think the original teletext patch had such a feature, but I removed it, 
hoping that it can be achieved with a subtitle filter later in the 
future...


Or if you are specifically aiming for 16 colors, then the 
txt_reduce_colors option can do a modulo 16 for each color index instead 
of finding the maximum index, which may vary between different pages, and 
I don't know how the dvb subtitle encoder would behave in that case.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option v2

[Timo Rothenpieler]

applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cuvid: don't overwrite deinterlace at progressive input

[Timo Rothenpieler]

applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel