Re: [FFmpeg-devel] lavu: add text encoding conversion API

2015-09-24 Thread Nicolas George 
Le duodi 2 vendémiaire, an CCXXIV, James Darnley a écrit :
> At first I was wondering how FFmpeg would have a non-optional part of
> the API if you depend on optional things such as iconv.  I was half
> prepared to rant about NIH and seriously wondering what was going to be
> proposed.
> 
> I think I see now that you are proposing a wrapper around other
> libraries.  Other than iconv I assume Windows has its own char encoding
> features which would likely be used here.

Well, I intend to have a built-in converter that handles UTF-8, ISO-8859-1,
UTF-16, UCS-2 and UCS-4, because that is very easy and quite convenient as a
fallback for systems lacking proper conversion libraries. But I definitely
do not intend to embed in lavu all the tables needed to convert from/to
legacy encodings.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] videotoolbox: allow to enable the async decoding.

2015-09-24 Thread Clément Bœsch 
On Sun, Aug 09, 2015 at 01:11:44PM +0200, Sebastien Zwickert wrote:
> This patch allows to use the Videotoolbox API in asynchonous mode.
> Note that when using async decoding the user is responsible for
> releasing the async frame.
> Moreover, an option called videotoolbox_async was added to enable
> async decoding with ffmpeg CLI.
> 
> ---
>  ffmpeg.h  |   1 +
>  ffmpeg_opt.c  |   1 +
>  ffmpeg_videotoolbox.c |  69 +
>  libavcodec/videotoolbox.c | 186 
> --
>  libavcodec/videotoolbox.h |  73 ++
>  5 files changed, 294 insertions(+), 36 deletions(-)
> 

Ping and more comments on this:

- is it meaningful to have a limit on the internal queue size (for memory
  load for instance), or it's not relevant in case of hw accel?

- isn't it missing a flush mechanism so seeking can be accurate?

[...]

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][PATCH] ffmpeg: add option to transform metadata using iconv

2015-09-24 Thread Nicolas George 
Le duodi 2 vendémiaire, an CCXXIV, James Darnley a écrit :
> It is not supposed to replace any invalid bytes with a "random"
> character. That sounds like it will only make the problem worse with
> that lossy removal of data. This is trying to fix incorrect
> interpretation of bytes.
> 
> This feature is to transform bytes into other bytes which when
> interpreted and displayed the correct text is appears on screen.
> 
> I will detail my exact use case at the bottom.

Indeed, but a feature like that must be designed with all reasonable use
cases in mind, and replacing isolated invalid octets values in input by a
fixed replacement character is a common practice, totally acceptable when
dealing with large amounts of data. I am not saying that it must be enabled
by default, but it needs to be an option.

> What do you mean? You need at least two encodings to be given to perform
> a conversion.  Two things become a list.

Yes, but the code to handle more than two is much more complicated than it
would have been with just two elements, i.e. only one conversion.

> It might not be very good but it is (void*) and NULL if you don't use
> the feature.

Yes, I understood that, but this is fragile code.

> It shouldn't.  This function receives buf2_len as equal to BUF_LEN - 1
> which means that iconv can only advance buf2 to buf2 + BUF_LEN - 1 which
> will let us write 0 into the last byte.

In that case, it should be written very explicitly in the function
documentation, otherwise someone may change the code and break the
assumption.

Also, I notice another flaw in that code: it uses '\0' as string terminator.
Text in non-ASCII encodings can contain '\0'. The end of the text must be
handled differently, with an explicit size argument or maybe a pointer to
the end.

> I won't send another patch for a little while.  I will see how your API
> proposal plays out.
> 
> And now for my tale.
> 
> I wanted ffmpeg to turn the string at [1] into the string at [3].  [1],
> with the exact hex bytes at [2], is artist tag out of a Flac file.  Flac
> files have Vorbis Comment metadata tags.  They are UTF-8 only.  If a
> program puts incorrect data in there how will any other program know how
> to display it?  What's worse is when the data gets converted twice.

Indeed. All modern formats should specify UTF-8 for all strings, there is
absolutely no valid reason to do otherwise nowadays.

> This specific case was to convert CP1252 to UTF-8 to GBK -- that is to
> interpret the input bytes as the CP1252 encoding and convert them to
> UTF-8, then take those bytes and convert them to GBK.  I added the code
> needed to take an argument in the form
> > "CP1252,UTF-8,GBK"
> parse it into separate encodings, open two iconv contexts, and finally
> perform the conversion.

I can not reproduce your conversion, but there is something that bugs me in
your reasoning.

With any sane iconv implementation, converting from A to B then from B to C
will either fail if B is too poor to code the input, or succeed and then
give the exact same result as converting directly from A to C.

As for chaining a conversion from A to B then from C to D with B != C, this
is braindead, and if FFmpeg were to support it at all, it should only be
with a very explicit request from the user to perform a dangerously lossy
conversion.

I do not understand what you were trying to achieve with your
"CP1252,UTF-8,GBK" conversion. First, why finish with GBK instead of sane
UTF-8? And second, if the output is really wanted in GBK, then what is the
purpose of the intermediate UTF-8 step?

IMHO, the only sane way of dealing with text is to handle everything in
UTF-8 internally: demuxers and anything that deals with input should convert
as soon as the encoding is known, muxers and anything that deals with output
should convert as late as possible.

(We do not do that for audio and video because conversions are expensive,
but text conversions are cheap and negligible compared to video and audio
processing.)

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Ching-Yi Chan 
Hi Hendrik,

I move the index data into AVStream, but seeking is slow. (it try to
download many data).
Is there something wrong ?

2015-09-24 16:09 GMT+08:00 Hendrik Leppkes :

> On Thu, Sep 24, 2015 at 9:08 AM, Ching-Yi Chan 
> wrote:
> > flacdec is not supported fast-seek yet.
> >
> > changes:
> >
> > 1. parse the seekpoint from metadata block
> > 2. add seek callback to look up seek position
> >
>
> You should store the index in the AVStream index_entries field, that
> way you don't need to duplicate the structure in the private flac
> context, and the generic seeking code can make use of them without you
> needing a specialized seekign function.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


0001-avformat-flacdec-support-fast-seek.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Hendrik Leppkes 
On Thu, Sep 24, 2015 at 9:08 AM, Ching-Yi Chan  wrote:
> flacdec is not supported fast-seek yet.
>
> changes:
>
> 1. parse the seekpoint from metadata block
> 2. add seek callback to look up seek position
>

You should store the index in the AVStream index_entries field, that
way you don't need to duplicate the structure in the private flac
context, and the generic seeking code can make use of them without you
needing a specialized seekign function.

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

[FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Ching-Yi Chan 
flacdec is not supported fast-seek yet.

changes:

1. parse the seekpoint from metadata block
2. add seek callback to look up seek position


0001-avformat-flacdec-support-fast-seek.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread wm4 
On Thu, 24 Sep 2015 15:08:06 +0800
Ching-Yi Chan  wrote:

> flacdec is not supported fast-seek yet.
> 
> changes:
> 
> 1. parse the seekpoint from metadata block
> 2. add seek callback to look up seek position

It would be great if we could run our new fate seek tests on this.
(Though I'm not sure where this test is.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Hendrik Leppkes 
On Thu, Sep 24, 2015 at 2:44 PM, Ching-Yi Chan  wrote:
> I found the generic seek will invoke the flac_read_timestamp function.
> It read exta packet will slow down the seek time
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/flacdec.c#L224
>
>

It does that to get to an accurate seek position. We do not have a way
to tell avformat to do a fast and inaccurate seek, and accuracy seems
more important to me, if the format allows for it.
Reading the index would however still allow this seek function to be
faster than it is now, since it knows the points in the index as
boundary points.

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

Re: [FFmpeg-devel] [RFC][PATCH] ffmpeg: add option to transform metadata using iconv

2015-09-24 Thread James Darnley 
On 2015-09-24 12:36, Nicolas George wrote:
> Le duodi 2 vendémiaire, an CCXXIV, James Darnley a écrit :
>> It is not supposed to replace any invalid bytes with a "random"
>> character. That sounds like it will only make the problem worse with
>> that lossy removal of data. This is trying to fix incorrect
>> interpretation of bytes.
>>
>> This feature is to transform bytes into other bytes which when
>> interpreted and displayed the correct text is appears on screen.
>>
>> I will detail my exact use case at the bottom.
> 
> Indeed, but a feature like that must be designed with all reasonable use
> cases in mind, and replacing isolated invalid octets values in input by a
> fixed replacement character is a common practice, totally acceptable when
> dealing with large amounts of data. I am not saying that it must be enabled
> by default, but it needs to be an option.

Noted.

As far as I understand the iconv API, it doesn't appear to do this for
you.  So adding this feature would require writing code to handle more
errors returned from the iconv() function.  That means a more
complicated argument handling structure is needed.

I don't mind trying to write this but it would be better to do it behind
the API you propose.  I will help you with it as best I can because I
seem to have involuntarily volunteered myself.

>> What do you mean? You need at least two encodings to be given to perform
>> a conversion.  Two things become a list.
> 
> Yes, but the code to handle more than two is much more complicated than it
> would have been with just two elements, i.e. only one conversion.
> 
>> It might not be very good but it is (void*) and NULL if you don't use
>> the feature.
> 
> Yes, I understood that, but this is fragile code.

Again, noted.  I can't see this being much less fragile though.  Having
thought again, I could reuse the av_dynarray that holds the char
encoding strings.

>> It shouldn't.  This function receives buf2_len as equal to BUF_LEN - 1
>> which means that iconv can only advance buf2 to buf2 + BUF_LEN - 1 which
>> will let us write 0 into the last byte.
> 
> In that case, it should be written very explicitly in the function
> documentation, otherwise someone may change the code and break the
> assumption.

Will add a comment to note this.

> Also, I notice another flaw in that code: it uses '\0' as string terminator.
> Text in non-ASCII encodings can contain '\0'. The end of the text must be
> handled differently, with an explicit size argument or maybe a pointer to
> the end.

Yes.  A user may request a conversion through UCS-2 which would break
because I call strlen() on the resulting string.  I need to return the
output length as it comes from iconv.

>> I won't send another patch for a little while.  I will see how your API
>> proposal plays out.
>>
>> And now for my tale.
>>
>> I wanted ffmpeg to turn the string at [1] into the string at [3].  [1],
>> with the exact hex bytes at [2], is artist tag out of a Flac file.  Flac
>> files have Vorbis Comment metadata tags.  They are UTF-8 only.  If a
>> program puts incorrect data in there how will any other program know how
>> to display it?  What's worse is when the data gets converted twice.
> 
> Indeed. All modern formats should specify UTF-8 for all strings, there is
> absolutely no valid reason to do otherwise nowadays.

Yes I agree.  I would suspect the problem comes from older software.

>> This specific case was to convert CP1252 to UTF-8 to GBK -- that is to
>> interpret the input bytes as the CP1252 encoding and convert them to
>> UTF-8, then take those bytes and convert them to GBK.  I added the code
>> needed to take an argument in the form
>>> "CP1252,UTF-8,GBK"
>> parse it into separate encodings, open two iconv contexts, and finally
>> perform the conversion.
> 
> I can not reproduce your conversion, but there is something that bugs me in
> your reasoning.
> 
> With any sane iconv implementation, converting from A to B then from B to C
> will either fail if B is too poor to code the input, or succeed and then
> give the exact same result as converting directly from A to C.
> 
> As for chaining a conversion from A to B then from C to D with B != C, this
> is braindead, and if FFmpeg were to support it at all, it should only be
> with a very explicit request from the user to perform a dangerously lossy
> conversion.
> 
> I do not understand what you were trying to achieve with your
> "CP1252,UTF-8,GBK" conversion. First, why finish with GBK instead of sane
> UTF-8? And second, if the output is really wanted in GBK, then what is the
> purpose of the intermediate UTF-8 step?
> 
> IMHO, the only sane way of dealing with text is to handle everything in
> UTF-8 internally: demuxers and anything that deals with input should convert
> as soon as the encoding is known, muxers and anything that deals with output
> should convert as late as possible.
> 
> (We do not do that for audio and video because conversions are expensive,
> but text

Re: [FFmpeg-devel] [DECISION] Server "move"

2015-09-24 Thread Michael Niedermayer 
On Tue, Sep 22, 2015 at 08:08:14PM +0200, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Sep 22, 2015 at 7:55 PM, compn  wrote:
> 
> > On Tue, 22 Sep 2015 14:21:22 +0200
> > Clément Bœsch  wrote:
> >
> > > On Mon, Sep 21, 2015 at 08:27:47PM +0100, Kieran Kunhya wrote:
> > > > > This "decision" thingy, is intended to confirm that
> > > > > * Stuff should be moved to the telepoint server, possibly
> > > > > duplicates should be left at/moved to the hetzner server for
> > > > > redundancy, if this is technically possible (maybe it should be
> > > > > called copy instead of move in that case)
> > > >
> > > > As discussed at VDD15 and posted to the admin IRC and emailed to the
> > > > root email address:
> > > > It was agreed by a large group of developers that this should be put
> > > > on hold and videolan remain a valid option.
> > > >
> > >
> > > Well, to be completely honest, it was Ronald & you mainly, the rest
> > > of the people in the room remained mostly silent, and it was about "a
> > > random server in Hungary [or sth like this] no ones know anything
> > > about".
> >
> > i agree with clement's assessment. i was the one who asked kieran to
> > include root@ffmpeg when asking about hosting. i'm not even sure what
> > their objections to bulgarian hosters were. aside from not knowing who
> > they were.
> >
> > i'm not here to make trouble, i'm not the one doing the work. i dont
> > care if we use videolan or bulgarian hoster.
> 
> 
> So I'm one of the concerned ones. I prefer caution simply because we do
> indeed not know them. Since other options exist (and are currently in use),
> I don't see the rush in moving away from our current "safe state".

I have suggested root to "copy" instead of "move" if that is
possible

If that is doable on the technical side then we would keep
the "safe state" and still have the new and more powerfull system.

about rushing, i dont want to rush, i want to avoid holding up
people who want to work on it. It likely will take a while
anyway before it is finished

Also if someone wants to help with the "copy" or with seperating
the services more for improved security and stuff
please contact root at ffmpeg.org

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Ching-Yi Chan 
I found the generic seek will invoke the flac_read_timestamp function.
It read exta packet will slow down the seek time
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/flacdec.c#L224



2015-09-24 17:27 GMT+08:00 Ching-Yi Chan :

> Hi Hendrik,
>
> I move the index data into AVStream, but seeking is slow. (it try to
> download many data).
> Is there something wrong ?
>
> 2015-09-24 16:09 GMT+08:00 Hendrik Leppkes :
>
>> On Thu, Sep 24, 2015 at 9:08 AM, Ching-Yi Chan 
>> wrote:
>> > flacdec is not supported fast-seek yet.
>> >
>> > changes:
>> >
>> > 1. parse the seekpoint from metadata block
>> > 2. add seek callback to look up seek position
>> >
>>
>> You should store the index in the AVStream index_entries field, that
>> way you don't need to duplicate the structure in the private flac
>> context, and the generic seeking code can make use of them without you
>> needing a specialized seekign function.
>>
>> - Hendrik
>> ___
>> 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_tremolo: make it bit-exact with sox effect of same name

2015-09-24 Thread Kyle Swanson 
>  s->table = av_malloc_array(inlink->sample_rate, sizeof(*s->table));


Just wondering. Is there a reason that the size of s->table is
(inlink->sample_rate)  and not (1.0 / inlink->sample_rate) ?

Thanks!
Kyle

On Wed, Sep 23, 2015 at 6:16 PM, Kyle Swanson  wrote:
> Looks good. Thanks for the clean-up.
>
> On Wed, Sep 23, 2015 at 4:22 PM, Paul B Mahol  wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavfilter/Makefile |  2 +-
>>  libavfilter/af_tremolo.c | 45 ++---
>>  2 files changed, 23 insertions(+), 24 deletions(-)
>>
>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>> index 7054275..c70887e 100644
>> --- a/libavfilter/Makefile
>> +++ b/libavfilter/Makefile
>> @@ -85,7 +85,7 @@ OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += 
>> af_silenceremove.o
>>  OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
>>  OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o
>>  OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
>> -OBJS-$(CONFIG_TREMOLO_FILTER)+= af_tremolo.o 
>> generate_wave_table.o
>> +OBJS-$(CONFIG_TREMOLO_FILTER)+= af_tremolo.o
>>  OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
>>  OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += af_volumedetect.o
>>
>> diff --git a/libavfilter/af_tremolo.c b/libavfilter/af_tremolo.c
>> index 6335401..0ae7a7c 100644
>> --- a/libavfilter/af_tremolo.c
>> +++ b/libavfilter/af_tremolo.c
>> @@ -22,15 +22,13 @@
>>  #include "avfilter.h"
>>  #include "internal.h"
>>  #include "audio.h"
>> -#include "generate_wave_table.h"
>>
>>  typedef struct TremoloContext {
>>  const AVClass *class;
>>  double freq;
>>  double depth;
>> -double *wave_table;
>> -int wave_table_index;
>> -int sample_rate;
>> +double *table;
>> +int index;
>>  } TremoloContext;
>>
>>  #define OFFSET(x) offsetof(TremoloContext, x)
>> @@ -44,20 +42,11 @@ static const AVOption tremolo_options[] = {
>>
>>  AVFILTER_DEFINE_CLASS(tremolo);
>>
>> -static double trem_env(AVFilterContext *ctx)
>> -{
>> -TremoloContext *s = ctx->priv;
>> -double env = s->wave_table[s->wave_table_index];
>> -s->wave_table_index++;
>> -if (s->wave_table_index >= s->sample_rate / s->freq)
>> -s->wave_table_index = 0;
>> -return 1.0 - (s->depth * env);
>> -}
>> -
>>  static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>>  {
>>  AVFilterContext *ctx = inlink->dst;
>>  AVFilterLink *outlink = ctx->outputs[0];
>> +TremoloContext *s = ctx->priv;
>>  const double *src = (const double *)in->data[0];
>>  const int channels = inlink->channels;
>>  const int nb_samples = in->nb_samples;
>> @@ -78,12 +67,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
>> *in)
>>  dst = (double *)out->data[0];
>>
>>  for (n = 0; n < nb_samples; n++) {
>> -const double env = trem_env(ctx);
>> -
>>  for (c = 0; c < channels; c++)
>> -dst[c] = src[c] * env;
>> +dst[c] = src[c] * s->table[s->index];
>>  dst += channels;
>>  src += channels;
>> +s->index++;
>> +if (s->index >= inlink->sample_rate)
>> +s->index = 0;
>>  }
>>
>>  if (in != out)
>> @@ -125,21 +115,30 @@ static int query_formats(AVFilterContext *ctx)
>>  static av_cold void uninit(AVFilterContext *ctx)
>>  {
>>  TremoloContext *s = ctx->priv;
>> -av_freep(>wave_table);
>> +av_freep(>table);
>>  }
>>
>>  static int config_input(AVFilterLink *inlink)
>>  {
>>  AVFilterContext *ctx = inlink->dst;
>>  TremoloContext *s = ctx->priv;
>> +const double offset = 1. - s->depth / 2.;
>> +int i;
>>
>> -s->sample_rate = inlink->sample_rate;
>> -s->wave_table = av_malloc_array(s->sample_rate / s->freq, 
>> sizeof(*s->wave_table));
>> -if (!s->wave_table)
>> +s->table = av_malloc_array(inlink->sample_rate, sizeof(*s->table));
>> +if (!s->table)
>>  return AVERROR(ENOMEM);
>>
>> -ff_generate_wave_table(WAVE_SIN, AV_SAMPLE_FMT_DBL, s->wave_table, 
>> s->sample_rate / s->freq, 0.0, 1.0, 0.0);
>> -s->wave_table_index = 0;
>> +for (i = 0; i < inlink->sample_rate; i++) {
>> +double env = s->freq * i / inlink->sample_rate;
>> +
>> +env = sin(2 * M_PI * fmod(env + 0.25, 1.0));
>> +
>> +s->table[i] = env * (1 - fabs(offset)) + offset;
>> +}
>> +
>> +s->index = 0;
>> +
>>  return 0;
>>  }
>>
>> --
>> 1.9.1
>>
>> ___
>> 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

[FFmpeg-devel] [PATCH] avfilter/generate_wave_table: clean up extra newlines

2015-09-24 Thread Kyle Swanson 
Signed-off-by: Kyle Swanson 
---
 libavfilter/generate_wave_table.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavfilter/generate_wave_table.c 
b/libavfilter/generate_wave_table.c
index bee9c00..6cd8022 100644
--- a/libavfilter/generate_wave_table.c
+++ b/libavfilter/generate_wave_table.c
@@ -80,5 +80,3 @@ void ff_generate_wave_table(enum WaveType wave_type,
 }
 }
 }
-
-
-- 
1.8.4

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

Re: [FFmpeg-devel] [PATCH] avfilter/af_tremolo: make it bit-exact with sox effect of same name

2015-09-24 Thread Kyle Swanson 
Sorry, I meant to type (1.0 / s->freq). This is one wavelength.

On Thu, Sep 24, 2015 at 9:29 AM, Kyle Swanson  wrote:
>>  s->table = av_malloc_array(inlink->sample_rate, sizeof(*s->table));
>
>
> Just wondering. Is there a reason that the size of s->table is
> (inlink->sample_rate)  and not (1.0 / inlink->sample_rate) ?
>
> Thanks!
> Kyle
>
> On Wed, Sep 23, 2015 at 6:16 PM, Kyle Swanson  wrote:
>> Looks good. Thanks for the clean-up.
>>
>> On Wed, Sep 23, 2015 at 4:22 PM, Paul B Mahol  wrote:
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavfilter/Makefile |  2 +-
>>>  libavfilter/af_tremolo.c | 45 ++---
>>>  2 files changed, 23 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>>> index 7054275..c70887e 100644
>>> --- a/libavfilter/Makefile
>>> +++ b/libavfilter/Makefile
>>> @@ -85,7 +85,7 @@ OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += 
>>> af_silenceremove.o
>>>  OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
>>>  OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o
>>>  OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
>>> -OBJS-$(CONFIG_TREMOLO_FILTER)+= af_tremolo.o 
>>> generate_wave_table.o
>>> +OBJS-$(CONFIG_TREMOLO_FILTER)+= af_tremolo.o
>>>  OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
>>>  OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += af_volumedetect.o
>>>
>>> diff --git a/libavfilter/af_tremolo.c b/libavfilter/af_tremolo.c
>>> index 6335401..0ae7a7c 100644
>>> --- a/libavfilter/af_tremolo.c
>>> +++ b/libavfilter/af_tremolo.c
>>> @@ -22,15 +22,13 @@
>>>  #include "avfilter.h"
>>>  #include "internal.h"
>>>  #include "audio.h"
>>> -#include "generate_wave_table.h"
>>>
>>>  typedef struct TremoloContext {
>>>  const AVClass *class;
>>>  double freq;
>>>  double depth;
>>> -double *wave_table;
>>> -int wave_table_index;
>>> -int sample_rate;
>>> +double *table;
>>> +int index;
>>>  } TremoloContext;
>>>
>>>  #define OFFSET(x) offsetof(TremoloContext, x)
>>> @@ -44,20 +42,11 @@ static const AVOption tremolo_options[] = {
>>>
>>>  AVFILTER_DEFINE_CLASS(tremolo);
>>>
>>> -static double trem_env(AVFilterContext *ctx)
>>> -{
>>> -TremoloContext *s = ctx->priv;
>>> -double env = s->wave_table[s->wave_table_index];
>>> -s->wave_table_index++;
>>> -if (s->wave_table_index >= s->sample_rate / s->freq)
>>> -s->wave_table_index = 0;
>>> -return 1.0 - (s->depth * env);
>>> -}
>>> -
>>>  static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>>>  {
>>>  AVFilterContext *ctx = inlink->dst;
>>>  AVFilterLink *outlink = ctx->outputs[0];
>>> +TremoloContext *s = ctx->priv;
>>>  const double *src = (const double *)in->data[0];
>>>  const int channels = inlink->channels;
>>>  const int nb_samples = in->nb_samples;
>>> @@ -78,12 +67,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
>>> *in)
>>>  dst = (double *)out->data[0];
>>>
>>>  for (n = 0; n < nb_samples; n++) {
>>> -const double env = trem_env(ctx);
>>> -
>>>  for (c = 0; c < channels; c++)
>>> -dst[c] = src[c] * env;
>>> +dst[c] = src[c] * s->table[s->index];
>>>  dst += channels;
>>>  src += channels;
>>> +s->index++;
>>> +if (s->index >= inlink->sample_rate)
>>> +s->index = 0;
>>>  }
>>>
>>>  if (in != out)
>>> @@ -125,21 +115,30 @@ static int query_formats(AVFilterContext *ctx)
>>>  static av_cold void uninit(AVFilterContext *ctx)
>>>  {
>>>  TremoloContext *s = ctx->priv;
>>> -av_freep(>wave_table);
>>> +av_freep(>table);
>>>  }
>>>
>>>  static int config_input(AVFilterLink *inlink)
>>>  {
>>>  AVFilterContext *ctx = inlink->dst;
>>>  TremoloContext *s = ctx->priv;
>>> +const double offset = 1. - s->depth / 2.;
>>> +int i;
>>>
>>> -s->sample_rate = inlink->sample_rate;
>>> -s->wave_table = av_malloc_array(s->sample_rate / s->freq, 
>>> sizeof(*s->wave_table));
>>> -if (!s->wave_table)
>>> +s->table = av_malloc_array(inlink->sample_rate, sizeof(*s->table));
>>> +if (!s->table)
>>>  return AVERROR(ENOMEM);
>>>
>>> -ff_generate_wave_table(WAVE_SIN, AV_SAMPLE_FMT_DBL, s->wave_table, 
>>> s->sample_rate / s->freq, 0.0, 1.0, 0.0);
>>> -s->wave_table_index = 0;
>>> +for (i = 0; i < inlink->sample_rate; i++) {
>>> +double env = s->freq * i / inlink->sample_rate;
>>> +
>>> +env = sin(2 * M_PI * fmod(env + 0.25, 1.0));
>>> +
>>> +s->table[i] = env * (1 - fabs(offset)) + offset;
>>> +}
>>> +
>>> +s->index = 0;
>>> +
>>>  return 0;
>>>  }
>>>
>>> --
>>> 1.9.1
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] avutil/opencl: Fix volatile pointer

2015-09-24 Thread Timo Rothenpieler 
---
 libavutil/opencl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index 1d78214..8686493 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -37,7 +37,7 @@
 #endif
 #include "atomic.h"
 
-static volatile pthread_mutex_t *atomic_opencl_lock = NULL;
+static pthread_mutex_t * volatile atomic_opencl_lock = NULL;
 #define LOCK_OPENCL pthread_mutex_lock(atomic_opencl_lock)
 #define UNLOCK_OPENCL pthread_mutex_unlock(atomic_opencl_lock)
 #else
@@ -363,7 +363,7 @@ static inline int init_opencl_mtx(void)
 av_free(tmp);
 return AVERROR(err);
 }
-if (avpriv_atomic_ptr_cas(_opencl_lock, NULL, tmp)) {
+if (avpriv_atomic_ptr_cas((void * volatile *)_opencl_lock, 
NULL, tmp)) {
 pthread_mutex_destroy(tmp);
 av_free(tmp);
 }
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH] avfilter/generate_wave_table: clean up extra newlines

2015-09-24 Thread Paul B Mahol 
On 9/24/15, Kyle Swanson  wrote:
> Signed-off-by: Kyle Swanson 
> ---
>  libavfilter/generate_wave_table.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/libavfilter/generate_wave_table.c
> b/libavfilter/generate_wave_table.c
> index bee9c00..6cd8022 100644
> --- a/libavfilter/generate_wave_table.c
> +++ b/libavfilter/generate_wave_table.c
> @@ -80,5 +80,3 @@ void ff_generate_wave_table(enum WaveType wave_type,
>  }
>  }
>  }
> -
> -
> --
> 1.8.4
>
> ___
> 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

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Ching-Yi Chan 
Is it acceptable to provide an option for different methods
between accuracy seek and fast but inaccurate.

For example, mp3dec having "usetoc" option to seek by toc.





2015-09-24 22:02 GMT+08:00 Hendrik Leppkes :

> On Thu, Sep 24, 2015 at 2:44 PM, Ching-Yi Chan 
> wrote:
> > I found the generic seek will invoke the flac_read_timestamp function.
> > It read exta packet will slow down the seek time
> > https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/flacdec.c#L224
> >
> >
>
> It does that to get to an accurate seek position. We do not have a way
> to tell avformat to do a fast and inaccurate seek, and accuracy seems
> more important to me, if the format allows for it.
> Reading the index would however still allow this seek function to be
> faster than it is now, since it knows the points in the index as
> boundary points.
>
> - Hendrik
> ___
> 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

[FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration

2015-09-24 Thread Timo Rothenpieler 
Signed-off-by: Timo Rothenpieler 
---
 doc/filters.texi  |   5 +
 libavfilter/chromakey_opencl_kernel.h |  98 +++
 libavfilter/opencl_allkernels.c   |   2 +
 libavfilter/vf_chromakey.c| 179 +-
 4 files changed, 283 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/chromakey_opencl_kernel.h

diff --git a/doc/filters.texi b/doc/filters.texi
index 044876c..4faf4b9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3734,6 +3734,11 @@ Signals that the color passed is already in YUV instead 
of RGB.
 
 Litteral colors like "green" or "red" don't make sense with this enabled 
anymore.
 This can be used to pass exact YUV values as hexadecimal numbers.
+
+@item opencl
+If set to 1, specify using OpenCL capabilities, only available if
+FFmpeg was configured with @code{--enable-opencl}. Default value is 0.
+
 @end table
 
 @subsection Examples
diff --git a/libavfilter/chromakey_opencl_kernel.h 
b/libavfilter/chromakey_opencl_kernel.h
new file mode 100644
index 000..56bbc79
--- /dev/null
+++ b/libavfilter/chromakey_opencl_kernel.h
@@ -0,0 +1,98 @@
+/*
+ * Copyright (c) 2015 Timo Rothenpieler 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFILTER_CHROMAKEY_OPENCL_KERNEL_H
+#define AVFILTER_CHROMAKEY_OPENCL_KERNEL_H
+
+#include "libavutil/opencl.h"
+
+const char *ff_kernel_chromakey_opencl = AV_OPENCL_KERNEL(
+
+inline unsigned char get_pixel(global unsigned char *src,
+   int x,
+   int y,
+   int w,
+   int h,
+   int linesize,
+   int hsub_log2,
+   int vsub_log2,
+   unsigned char def)
+{
+if (x < 0 || x >= w || y < 0 || x >= w)
+return def;
+
+x >>= hsub_log2;
+y >>= vsub_log2;
+
+return src[linesize * y + x];
+}
+
+kernel void chromakey(global unsigned char *src_u,
+  global unsigned char *src_v,
+  global unsigned char *dst,
+  int linesize_u,
+  int linesize_v,
+  int linesize_a,
+  int height,
+  int width,
+  int hsub_log2,
+  int vsub_log2,
+  unsigned char chromakey_u,
+  unsigned char chromakey_v,
+  float similarity,
+  float blend
+ )
+{
+int x = get_global_id(0);
+int y = get_global_id(1);
+unsigned char res;
+
+int xo, yo, du, dv;
+double diff = 0.0;
+
+if (x >= width || y >= height)
+return;
+
+for (yo = 0; yo < 3; yo++) {
+for (xo = 0; xo < 3; xo++) {
+du = get_pixel(src_u, x + xo - 1, y + yo - 1, width, height, 
linesize_u, hsub_log2, vsub_log2, chromakey_u);
+dv = get_pixel(src_v, x + xo - 1, y + yo - 1, width, height, 
linesize_v, hsub_log2, vsub_log2, chromakey_v);
+
+du -= chromakey_u;
+dv -= chromakey_v;
+
+diff += sqrt((du * du + dv * dv) / (double)(255.0 * 255.0));
+}
+}
+
+diff /= 9.0;
+
+if (blend > 0.0001) {
+res = clamp((diff - similarity) / blend, 0.0, 1.0) * 255.0;
+} else {
+res = (diff > similarity) ? 255 : 0;
+}
+
+dst[linesize_a * y + x] = res;
+}
+
+);
+
+#endif /* AVFILTER_CHROMAKEY_OPENCL_KERNEL_H */
diff --git a/libavfilter/opencl_allkernels.c b/libavfilter/opencl_allkernels.c
index 6d80fa8..fc05e66 100644
--- a/libavfilter/opencl_allkernels.c
+++ b/libavfilter/opencl_allkernels.c
@@ -23,6 +23,7 @@
 #include "libavutil/opencl.h"
 #include "deshake_opencl_kernel.h"
 #include "unsharp_opencl_kernel.h"
+#include "chromakey_opencl_kernel.h"
 #endif
 
 #define OPENCL_REGISTER_KERNEL_CODE(X, x)  
\
@@ -37,5 +38,6 @@ void ff_opencl_register_filter_kernel_code_all(void)
  #if CONFIG_OPENCL
OPENCL_REGISTER_KERNEL_CODE(DESHAKE, deshake);
OPENCL_REGISTER_KERNEL_CODE(UNSHARP, unsharp);

[FFmpeg-devel] [PATCH 2/3] avutil/opencl: Display build log on compile error

2015-09-24 Thread Timo Rothenpieler 
---
 libavutil/opencl.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index 8686493..2469ba4 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -452,8 +452,9 @@ cl_program av_opencl_compile(const char *program_name, 
const char *build_opts)
 cl_int status;
 int kernel_code_idx = 0;
 const char *kernel_source;
-size_t kernel_code_len;
+size_t kernel_code_len, build_log_len;
 char* ptr = NULL;
+char* build_log = NULL;
 cl_program program = NULL;
 
 LOCK_OPENCL;
@@ -485,6 +486,19 @@ cl_program av_opencl_compile(const char *program_name, 
const char *build_opts)
 if (status != CL_SUCCESS) {
 av_log(_ctx, AV_LOG_ERROR,
"Compilation failed with OpenCL program: %s\n", program_name);
+
+status = clGetProgramBuildInfo(program, opencl_ctx.device_id, 
CL_PROGRAM_BUILD_LOG, 0, NULL, _log_len);
+if (status != CL_SUCCESS)
+goto end;
+
+build_log = av_malloc(build_log_len);
+
+status = clGetProgramBuildInfo(program, opencl_ctx.device_id, 
CL_PROGRAM_BUILD_LOG, build_log_len, build_log, NULL);
+if (status != CL_SUCCESS)
+goto end;
+
+av_log(_ctx, AV_LOG_DEBUG, "OpenCL Build Log:\n%s\n", 
build_log);
+
 program = NULL;
 goto end;
 }
@@ -492,6 +506,7 @@ cl_program av_opencl_compile(const char *program_name, 
const char *build_opts)
 opencl_ctx.kernel_code[kernel_code_idx].is_compiled = 1;
 end:
 UNLOCK_OPENCL;
+av_free(build_log);
 return program;
 }
 
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread wm4 
On Thu, 24 Sep 2015 23:41:03 +0800
Ching-Yi Chan  wrote:

> Is it acceptable to provide an option for different methods
> between accuracy seek and fast but inaccurate.
> 
> For example, mp3dec having "usetoc" option to seek by toc.

You could use the AVFMT_FLAG_FAST_SEEK flag. (It's a flag set on the
format context.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_tremolo: make it bit-exact with sox effect of same name

2015-09-24 Thread Paul B Mahol 
On 9/24/15, Kyle Swanson  wrote:
> Sorry, I meant to type (1.0 / s->freq). This is one wavelength.


I inspected what filter produces with constant 0.5 mono input and
found it is repeating after each sample_rate number of samples.

Please do not top post.

>
> On Thu, Sep 24, 2015 at 9:29 AM, Kyle Swanson  wrote:
>>>  s->table = av_malloc_array(inlink->sample_rate, sizeof(*s->table));
>>
>>
>> Just wondering. Is there a reason that the size of s->table is
>> (inlink->sample_rate)  and not (1.0 / inlink->sample_rate) ?
>>
>> Thanks!
>> Kyle
>>
>> On Wed, Sep 23, 2015 at 6:16 PM, Kyle Swanson  wrote:
>>> Looks good. Thanks for the clean-up.
>>>
>>> On Wed, Sep 23, 2015 at 4:22 PM, Paul B Mahol  wrote:
 Signed-off-by: Paul B Mahol 
 ---
  libavfilter/Makefile |  2 +-
  libavfilter/af_tremolo.c | 45
 ++---
  2 files changed, 23 insertions(+), 24 deletions(-)

 diff --git a/libavfilter/Makefile b/libavfilter/Makefile
 index 7054275..c70887e 100644
 --- a/libavfilter/Makefile
 +++ b/libavfilter/Makefile
 @@ -85,7 +85,7 @@ OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  +=
 af_silenceremove.o
  OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
  OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o
  OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
 -OBJS-$(CONFIG_TREMOLO_FILTER)+= af_tremolo.o
 generate_wave_table.o
 +OBJS-$(CONFIG_TREMOLO_FILTER)+= af_tremolo.o
  OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
  OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += af_volumedetect.o

 diff --git a/libavfilter/af_tremolo.c b/libavfilter/af_tremolo.c
 index 6335401..0ae7a7c 100644
 --- a/libavfilter/af_tremolo.c
 +++ b/libavfilter/af_tremolo.c
 @@ -22,15 +22,13 @@
  #include "avfilter.h"
  #include "internal.h"
  #include "audio.h"
 -#include "generate_wave_table.h"

  typedef struct TremoloContext {
  const AVClass *class;
  double freq;
  double depth;
 -double *wave_table;
 -int wave_table_index;
 -int sample_rate;
 +double *table;
 +int index;
  } TremoloContext;

  #define OFFSET(x) offsetof(TremoloContext, x)
 @@ -44,20 +42,11 @@ static const AVOption tremolo_options[] = {

  AVFILTER_DEFINE_CLASS(tremolo);

 -static double trem_env(AVFilterContext *ctx)
 -{
 -TremoloContext *s = ctx->priv;
 -double env = s->wave_table[s->wave_table_index];
 -s->wave_table_index++;
 -if (s->wave_table_index >= s->sample_rate / s->freq)
 -s->wave_table_index = 0;
 -return 1.0 - (s->depth * env);
 -}
 -
  static int filter_frame(AVFilterLink *inlink, AVFrame *in)
  {
  AVFilterContext *ctx = inlink->dst;
  AVFilterLink *outlink = ctx->outputs[0];
 +TremoloContext *s = ctx->priv;
  const double *src = (const double *)in->data[0];
  const int channels = inlink->channels;
  const int nb_samples = in->nb_samples;
 @@ -78,12 +67,13 @@ static int filter_frame(AVFilterLink *inlink,
 AVFrame *in)
  dst = (double *)out->data[0];

  for (n = 0; n < nb_samples; n++) {
 -const double env = trem_env(ctx);
 -
  for (c = 0; c < channels; c++)
 -dst[c] = src[c] * env;
 +dst[c] = src[c] * s->table[s->index];
  dst += channels;
  src += channels;
 +s->index++;
 +if (s->index >= inlink->sample_rate)
 +s->index = 0;
  }

  if (in != out)
 @@ -125,21 +115,30 @@ static int query_formats(AVFilterContext *ctx)
  static av_cold void uninit(AVFilterContext *ctx)
  {
  TremoloContext *s = ctx->priv;
 -av_freep(>wave_table);
 +av_freep(>table);
  }

  static int config_input(AVFilterLink *inlink)
  {
  AVFilterContext *ctx = inlink->dst;
  TremoloContext *s = ctx->priv;
 +const double offset = 1. - s->depth / 2.;
 +int i;

 -s->sample_rate = inlink->sample_rate;
 -s->wave_table = av_malloc_array(s->sample_rate / s->freq,
 sizeof(*s->wave_table));
 -if (!s->wave_table)
 +s->table = av_malloc_array(inlink->sample_rate, sizeof(*s->table));
 +if (!s->table)
  return AVERROR(ENOMEM);

 -ff_generate_wave_table(WAVE_SIN, AV_SAMPLE_FMT_DBL, s->wave_table,
 s->sample_rate / s->freq, 0.0, 1.0, 0.0);
 -s->wave_table_index = 0;
 +for (i = 0; i < inlink->sample_rate; i++) {
 +double env = s->freq * i / inlink->sample_rate;
 +
 +env = sin(2 * M_PI * fmod(env + 0.25,

[FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix crash if number of slice counts change midstream

2015-09-24 Thread Paul B Mahol 
Everyting points this is currently unsupported.

Signed-off-by: Paul B Mahol 
---
 libavcodec/ffv1dec.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 557b1a0..886f172 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -776,18 +776,25 @@ static int read_header(FFV1Context *f)
 return AVERROR_INVALIDDATA;
 }
 } else if (f->version < 3) {
-f->slice_count = get_symbol(c, state, 0);
+if (get_symbol(c, state, 0) != f->slice_count) {
+ av_log(f->avctx, AV_LOG_ERROR, "midstream change of slice count 
is unsupported\n");
+ return AVERROR_INVALIDDATA;
+}
 } else {
 const uint8_t *p = c->bytestream_end;
-for (f->slice_count = 0;
- f->slice_count < MAX_SLICES && 3 < p - c->bytestream_start;
- f->slice_count++) {
+for (i = 0;
+ i < MAX_SLICES && 3 < p - c->bytestream_start;
+ i++) {
 int trailer = 3 + 5*!!f->ec;
 int size = AV_RB24(p-trailer);
 if (size + trailer > p - c->bytestream_start)
 break;
 p -= size + trailer;
 }
+if (i != f->slice_count) {
+av_log(f->avctx, AV_LOG_ERROR, "midstream change of slice count is 
unsupported\n");
+return AVERROR_INVALIDDATA;
+}
 }
 if (f->slice_count > (unsigned)MAX_SLICES || f->slice_count <= 0) {
 av_log(f->avctx, AV_LOG_ERROR, "slice count %d is invalid\n", 
f->slice_count);
-- 
1.9.1

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

[FFmpeg-devel] [PATCH] Return EOF for ICO when the end is reached

2015-09-24 Thread Michael Bradshaw 
Hello!

Attached patch makes the ICO demuxer return EOF instead of EIO when the end
of the file is reached. Currently, if you try to parse an ICO file, it will
always result in ffmpeg outputting an error because of this.

--Michael Bradshaw


0001-Return-EOF-for-ICO-when-the-end-is-reached.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] checkasm: add vp9dsp.itxfm_add tests.

2015-09-24 Thread Henrik Gramner 
On Tue, Sep 22, 2015 at 7:26 PM, Ronald S. Bultje  wrote:
> +for (k = 0; k < sz; k++) {
> +out[k] = 0.0;
> +for (n = 0; n < sz; n++)
> +out[k] += in[n] * cos(M_PI * (2 * n + 1) * k / (sz * 2.0));
> +if (k == 0)
> +out[k] *= M_SQRT1_2;
> +}

You could move the last row outside the for loop.

> +// see "Towards jointly optimal spatial prediction and adaptive transform in
> +// video/image coding", by J. Han, A. Saxena, and K. Rose
> +// IEEE Proc. ICASSP, pp. 726-729, Mar. 2010.
> +static void fadst4_1d(double *out, const double *in, int sz)
[...]
> +// see "A Butterfly Structured Design of The Hybrid Transform Coding Scheme",
> +// by Jingning Han, Yaowu Xu, and Debargha Mukherjee
> +// 
> http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41418.pdf

Thumbs up for giving sources.

+static void ftx(int16_t *out, const int16_t *in, enum TxfmMode tx,
+enum TxfmType txtp, int sz, int bit_depth)

This function is only ever called with in == out, so you could merge
those parameters.

+memcpy(subcoef0, coef, sz * sz * 2 * SIZEOF_PIXEL);
[...]
+memcpy(subcoef1, subcoef0, sz * sz * 2 * SIZEOF_PIXEL);

I'd define a SIZEOF_COEF or similar for this instead of using
SIZEOF_PIXEL on something that's aren't pixels.

I didn't feel like reading through two research papers so I won't
comment on your calculations for creating input coefficients, but the
testing code seems ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][PATCH] ffmpeg: add option to transform metadata using iconv

2015-09-24 Thread Nicolas George 
Le tridi 3 vendémiaire, an CCXXIV, James Darnley a écrit :
> As far as I understand the iconv API, it doesn't appear to do this for
> you.  So adding this feature would require writing code to handle more
> errors returned from the iconv() function.  That means a more
> complicated argument handling structure is needed.
> 
> I don't mind trying to write this but it would be better to do it behind
> the API you propose.

Of course. Actually, it is already there in the API, although I am not quite
satisfied because it can not be set as an option.

>   I will help you with it as best I can because I
> seem to have involuntarily volunteered myself.

I need some feedback to know if this kind of API is useful in FFmpeg (other
people are welcome to give advice too!), and to know if the actual API I
propose is suitable for various needs. But as for writing the code, I expect
it to be quite straightforward.

The question where I most need feedback is this: shall I make an API that
allows to convert from any encoding to any encoding, or an API that can
convert from any encoding to UTF-8 and from UTF-8 to any encoding?

There are pros and cons for each case. UTF-8 to/from anything is enough for
the needs of any sane program, and makes the handling of the replacement
character easier (because it can be specified in UTF-8 directly). OTOH,
any-to-any is more generic.

> I don't know what to say here.  I know the encodings needed for iconv
> because I arrived at them by brute force.  I wrote a short Lua script to
> iterate over a list of encodings supported by my iconv and arrived at
> this answer.  The command line tool called iconv is too clever for this
> because it returns an error when it can't convert.  As for ending in
> GBK, it is what the script told me.

Could you share the script and enough input to run it and reproduce the
results?

> This feature would not work if there was a misinterpretation in the
> middle.  As you say that would need A->B and C->D where B != C.  Perhaps
> this is why my solution isn't perfect, because there should be an
> assumption in the middle.
> 
> I could rework my code to allow for assumptions in the middle.  My case
> would then use "CP1252,UTF-8,UTF-8,GBK" as an argument.

I must say, I do not like your approach very much because it manipulates
text encoding in the middle of the program. All strings inside the program
should be in UTF-8.

I can propose this: add an option "metadata_text_encoding" to
AVFormatContext. If it is set on a demuxer, the demuxing framework uses it
to convert from it to UTF-8; and similarly, if it is set on a muxer, the
muxing framework uses it to convert from UTF-8 to it.

Then we can have a special syntax for it to specify bogus conversions.
Possibly: -metadata_text_encoding "[CP1252>UTF-8]GBK" to specify that the
text must first be converted from CP1252 to UTF-8 then considered to be GBK
(and converted to UTF-8). (Well, I consider the feature evil, so I will
probably not volunteer to implement it, but I will not oppose as long as it
can not be triggered too easily by an unsuspecting user.

What do you think of it?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix crash if number of slice counts change midstream

2015-09-24 Thread Paul B Mahol 
On 9/24/15, Michael Niedermayer  wrote:
> On Thu, Sep 24, 2015 at 09:45:35PM +0200, Paul B Mahol wrote:
>> Everyting points this is currently unsupported.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/ffv1dec.c | 15 +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> fixed differently (so slice_counts can change, not really tested
> though due to lack of encoder support)

That fix decodes nonsense for 2nd part when concatinating 2 nuts when
1st have 16
slices and 2nd have 4 slices.

Just create 2 nuts with different slice number and concat them with concat
demuxer and copy codec.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix crash if number of slice counts change midstream

2015-09-24 Thread Michael Niedermayer 
On Fri, Sep 25, 2015 at 12:29:04AM +0200, Paul B Mahol wrote:
> On 9/24/15, Michael Niedermayer  wrote:
> > On Thu, Sep 24, 2015 at 09:45:35PM +0200, Paul B Mahol wrote:
> >> Everyting points this is currently unsupported.
> >>
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavcodec/ffv1dec.c | 15 +++
> >>  1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > fixed differently (so slice_counts can change, not really tested
> > though due to lack of encoder support)
> 
> That fix decodes nonsense for 2nd part when concatinating 2 nuts when
> 1st have 16
> slices and 2nd have 4 slices.
> 
> Just create 2 nuts with different slice number and concat them with concat
> demuxer and copy codec.

why would this be a valid file ?

theres a global horizontal and vertical slice count and on this
raster slices can occupy some rectangular area, currently only 1x1
is supported. Theres no support to change the raster resolution
itself midstream. 

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Return EOF for ICO when the end is reached

2015-09-24 Thread Paul B Mahol 
On 9/24/15, Michael Bradshaw  wrote:
> Hello!
>
> Attached patch makes the ICO demuxer return EOF instead of EIO when the end
> of the file is reached. Currently, if you try to parse an ICO file, it will
> always result in ffmpeg outputting an error because of this.
>
> --Michael Bradshaw
>

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

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Michael Niedermayer 
On Fri, Sep 25, 2015 at 09:22:41AM +0800, Ching-Yi Chan wrote:
> I do it with AVFMT_FLAG_FAST_SEEK flag.
> 
> 
> 2015-09-24 23:47 GMT+08:00 wm4 :
> 
> > On Thu, 24 Sep 2015 23:41:03 +0800
> > Ching-Yi Chan  wrote:
> >
> > > Is it acceptable to provide an option for different methods
> > > between accuracy seek and fast but inaccurate.
> > >
> > > For example, mp3dec having "usetoc" option to seek by toc.
> >
> > You could use the AVFMT_FLAG_FAST_SEEK flag. (It's a flag set on the
> > format context.)
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  flacdec.c |   43 ++-
>  1 file changed, 42 insertions(+), 1 deletion(-)
> 980c23fbd623f488c24194ec92d75aebe5e183f8  
> 0001-avformat-flacdec-support-fast-seek.patch
> From 2e1d69e0a24455136d1a5dcc0898eac1bb2cb602 Mon Sep 17 00:00:00 2001
> From: "Ching Yi, Chan" 
> Date: Thu, 24 Sep 2015 13:04:40 +0800
> Subject: [PATCH] avformat/flacdec: support fast-seek
> 
> ---
>  libavformat/flacdec.c |   43 ++-
>  1 files changed, 42 insertions(+), 1 deletions(-)
> 
> diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
> index 4c1f943..3e4d867 100644
> --- a/libavformat/flacdec.c
> +++ b/libavformat/flacdec.c
> @@ -28,11 +28,14 @@
>  #include "vorbiscomment.h"
>  #include "replaygain.h"
>  
> +#define SEEKPOINT_SIZE 18
> +
>  static int flac_read_header(AVFormatContext *s)
>  {
>  int ret, metadata_last=0, metadata_type, metadata_size, 
> found_streaminfo=0;
>  uint8_t header[4];
>  uint8_t *buffer=NULL;
> +
>  AVStream *st = avformat_new_stream(s, NULL);
>  if (!st)
>  return AVERROR(ENOMEM);
> @@ -58,6 +61,7 @@ static int flac_read_header(AVFormatContext *s)
>  case FLAC_METADATA_TYPE_CUESHEET:
>  case FLAC_METADATA_TYPE_PICTURE:
>  case FLAC_METADATA_TYPE_VORBIS_COMMENT:
> +case FLAC_METADATA_TYPE_SEEKTABLE:
>  buffer = av_mallocz(metadata_size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
>  if (!buffer) {
>  return AVERROR(ENOMEM);
> @@ -132,7 +136,20 @@ static int flac_read_header(AVFormatContext *s)
>  av_log(s, AV_LOG_ERROR, "Error parsing attached picture.\n");
>  return ret;
>  }
> -} else {
> +} else if (metadata_type == FLAC_METADATA_TYPE_SEEKTABLE) {
> +const uint8_t *seekpoint = buffer;
> +int i, seek_point_count = metadata_size/SEEKPOINT_SIZE;
> +for(i=0; i +int64_t timestamp = bytestream_get_be64();
> +int64_t pos = bytestream_get_be64();
> +/* skip number of samples */
> +bytestream_get_be16();
> +av_add_index_entry(st, pos, timestamp, 0, 0, 
> AVINDEX_KEYFRAME);
> +}
> +av_freep();
> +}
> +else {
> +
>  /* STREAMINFO must be the first block */
>  if (!found_streaminfo) {
>  RETURN_ERROR(AVERROR_INVALIDDATA);

> @@ -169,6 +186,12 @@ static int flac_read_header(AVFormatContext *s)
>  if (ret < 0)
>  return ret;
>  
> +/* the real seek index offset should be the size of metadata blocks with 
> the offset in the frame blocks */
> +int metadata_head_size = avio_tell(s->pb);

this should be int64_t probably
also declarations and statments should not be mixed


> +int i;
> +for(i=0; inb_index_entries; i++) {
> +st->index_entries[i].pos += metadata_head_size;
> +}
>  return 0;
>  
>  fail:
> @@ -249,12 +272,30 @@ static av_unused int64_t 
> flac_read_timestamp(AVFormatContext *s, int stream_inde
>  return pts;
>  }
>  
> +static int flac_seek(AVFormatContext *s, int stream_index, int64_t 
> timestamp, int flags) {
> +if (!(s->flags_FLAG_FAST_SEEK)) {
> +return -1;
> +}
> +
> +int index = av_index_search_timestamp(s->streams[0], timestamp, flags);
> +if(index<0 || index >= s->streams[0]->nb_index_entries)
> +return -1;
> +
> +AVIndexEntry e = s->streams[0]->index_entries[index];

> +int ret = avio_seek(s->pb, e.pos, SEEK_SET);

int64_t

what level of accuracy is this code intended to have ?

seek-acodec-flac would differ by the amounts listed below if the code
would be enabled and not depend on AVFMT_FLAG_FAST_SEEK

--- ./tests/ref/seek/acodec-flac2015-09-25 03:40:06.793930465 +0200
+++ tests/data/fate/seek-acodec-flac2015-09-25 04:22:51.565984498 +0200
@@ -2,7 +2,7 @@
 ret: 0 st:-1 flags:0  ts:-1.00
 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:   8256 size:   
614
 ret: 0 st:-1 flags:1  ts: 1.894167
-ret: 0 st: 0 flags:1 dts: 1.880816 pts: 1.880816 pos:  86742 size:  
2191

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Ching-Yi Chan 
I do it with AVFMT_FLAG_FAST_SEEK flag.


2015-09-24 23:47 GMT+08:00 wm4 :

> On Thu, 24 Sep 2015 23:41:03 +0800
> Ching-Yi Chan  wrote:
>
> > Is it acceptable to provide an option for different methods
> > between accuracy seek and fast but inaccurate.
> >
> > For example, mp3dec having "usetoc" option to seek by toc.
>
> You could use the AVFMT_FLAG_FAST_SEEK flag. (It's a flag set on the
> format context.)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


0001-avformat-flacdec-support-fast-seek.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response

2015-09-24 Thread Lucas Andrade 
Here it goes.


Update Cookies on Setcookie response.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avutil/opencl: Fix volatile pointer

2015-09-24 Thread Michael Niedermayer 
On Thu, Sep 24, 2015 at 05:12:23PM +0200, Timo Rothenpieler wrote:
> ---
>  libavutil/opencl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

2015-09-24 Thread Ching-Yi Chan 
Thanks for checking.

I also check the AVFMT_FLAG_FAST_SEEK flag with parsing headers,
to fill the seektable into index entries only if AVFMT_FLAG_FAST_SEEK flag
is on.

If the AVFMT_FLAG_FAST_SEEK flag is not enabled, it will seek in original
way.

2015-09-25 10:37 GMT+08:00 Michael Niedermayer :

> On Fri, Sep 25, 2015 at 09:22:41AM +0800, Ching-Yi Chan wrote:
> > I do it with AVFMT_FLAG_FAST_SEEK flag.
> >
> >
> > 2015-09-24 23:47 GMT+08:00 wm4 :
> >
> > > On Thu, 24 Sep 2015 23:41:03 +0800
> > > Ching-Yi Chan  wrote:
> > >
> > > > Is it acceptable to provide an option for different methods
> > > > between accuracy seek and fast but inaccurate.
> > > >
> > > > For example, mp3dec having "usetoc" option to seek by toc.
> > >
> > > You could use the AVFMT_FLAG_FAST_SEEK flag. (It's a flag set on the
> > > format context.)
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
>
> >  flacdec.c |   43 ++-
> >  1 file changed, 42 insertions(+), 1 deletion(-)
> > 980c23fbd623f488c24194ec92d75aebe5e183f8
> 0001-avformat-flacdec-support-fast-seek.patch
> > From 2e1d69e0a24455136d1a5dcc0898eac1bb2cb602 Mon Sep 17 00:00:00 2001
> > From: "Ching Yi, Chan" 
> > Date: Thu, 24 Sep 2015 13:04:40 +0800
> > Subject: [PATCH] avformat/flacdec: support fast-seek
> >
> > ---
> >  libavformat/flacdec.c |   43 ++-
> >  1 files changed, 42 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
> > index 4c1f943..3e4d867 100644
> > --- a/libavformat/flacdec.c
> > +++ b/libavformat/flacdec.c
> > @@ -28,11 +28,14 @@
> >  #include "vorbiscomment.h"
> >  #include "replaygain.h"
> >
> > +#define SEEKPOINT_SIZE 18
> > +
> >  static int flac_read_header(AVFormatContext *s)
> >  {
> >  int ret, metadata_last=0, metadata_type, metadata_size,
> found_streaminfo=0;
> >  uint8_t header[4];
> >  uint8_t *buffer=NULL;
> > +
> >  AVStream *st = avformat_new_stream(s, NULL);
> >  if (!st)
> >  return AVERROR(ENOMEM);
> > @@ -58,6 +61,7 @@ static int flac_read_header(AVFormatContext *s)
> >  case FLAC_METADATA_TYPE_CUESHEET:
> >  case FLAC_METADATA_TYPE_PICTURE:
> >  case FLAC_METADATA_TYPE_VORBIS_COMMENT:
> > +case FLAC_METADATA_TYPE_SEEKTABLE:
> >  buffer = av_mallocz(metadata_size +
> AV_INPUT_BUFFER_PADDING_SIZE);
> >  if (!buffer) {
> >  return AVERROR(ENOMEM);
> > @@ -132,7 +136,20 @@ static int flac_read_header(AVFormatContext *s)
> >  av_log(s, AV_LOG_ERROR, "Error parsing attached
> picture.\n");
> >  return ret;
> >  }
> > -} else {
> > +} else if (metadata_type == FLAC_METADATA_TYPE_SEEKTABLE) {
> > +const uint8_t *seekpoint = buffer;
> > +int i, seek_point_count = metadata_size/SEEKPOINT_SIZE;
> > +for(i=0; i > +int64_t timestamp = bytestream_get_be64();
> > +int64_t pos = bytestream_get_be64();
> > +/* skip number of samples */
> > +bytestream_get_be16();
> > +av_add_index_entry(st, pos, timestamp, 0, 0,
> AVINDEX_KEYFRAME);
> > +}
> > +av_freep();
> > +}
> > +else {
> > +
> >  /* STREAMINFO must be the first block */
> >  if (!found_streaminfo) {
> >  RETURN_ERROR(AVERROR_INVALIDDATA);
>
> > @@ -169,6 +186,12 @@ static int flac_read_header(AVFormatContext *s)
> >  if (ret < 0)
> >  return ret;
> >
> > +/* the real seek index offset should be the size of metadata blocks
> with the offset in the frame blocks */
> > +int metadata_head_size = avio_tell(s->pb);
>
> this should be int64_t probably
> also declarations and statments should not be mixed
>
>
> > +int i;
> > +for(i=0; inb_index_entries; i++) {
> > +st->index_entries[i].pos += metadata_head_size;
> > +}
> >  return 0;
> >
> >  fail:
> > @@ -249,12 +272,30 @@ static av_unused int64_t
> flac_read_timestamp(AVFormatContext *s, int stream_inde
> >  return pts;
> >  }
> >
> > +static int flac_seek(AVFormatContext *s, int stream_index, int64_t
> timestamp, int flags) {
> > +if (!(s->flags_FLAG_FAST_SEEK)) {
> > +return -1;
> > +}
> > +
> > +int index = av_index_search_timestamp(s->streams[0], timestamp,
> flags);
> > +if(index<0 || index >= s->streams[0]->nb_index_entries)
> > +return -1;
> > +
> > +AVIndexEntry e = s->streams[0]->index_entries[index];
>
> > +int ret = avio_seek(s->pb, e.pos, SEEK_SET);
>
> int64_t
>
> what level of accuracy is this code intended to have ?
>
>