Re: [FFmpeg-devel] [PATCH 04/11] libavformat/mxfdec.c: Try to increment current edit before rejecting a klv that spans onto next edit unit.

[Alexis Ballier]

On Wed, 21 Oct 2015 23:45:07 +0200
Tomas Härdin  wrote:

> On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> > Some files such as those from tickets #2817 & #2776 claim to have
> > constant edit unit size but, in fact, have some of them that are
> > smaller. This confuses the demuxer that tries to infer the current
> > edit unit from the position in the file. By trying to increment the
> > current edit unit before rejecting the packet for this reason, we
> > try to make it fit into its proper edit unit, which fixes demuxing
> > of those files while preserving the check for misprobed OpAtom
> > files. Seeking is not accurate but the files provide no way to
> > properly find the relevant edit unit.
> > 
> > Fixes tickets #2817 & #2776.
> > ---
> >  libavformat/mxfdec.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 593604e..526eca6 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -2956,6 +2956,18 @@ static int
> > mxf_read_packet_old(AVFormatContext *s, AVPacket *pkt) next_ofs =
> > mxf_set_current_edit_unit(mxf, klv.offset); 
> >  if (next_ofs >= 0 && next_klv > next_ofs) {
> > +/* Samples from tickets #2817 and #2776 claim to
> > have
> > + * constant edit unit size. However, some of them
> > are smaller.  
> 
> What does "them" refer to here? The edit units or the KLVs?
> 
> > + * Just after those smaller edit units,  
> 
> Right, the edit units. Maybe rework the grammar slightly.
> 
> > + * Just after those smaller edit units, klv.offset
> > is still in
> > + * the same edit unit according to the
> > computations from the
> > + * constant edit unit size. If the klv finishes
> > after, the next
> > + * check would truncate the packet and prevent
> > proper demuxing.
> > + * Try to increment the current edit unit before
> > doing that. */  
> 
> Let's see if I understand this correctly. For say EUBC = 10, there can
> still be KLVs that are some size larger than 10, but smaller than
> 2*EUBC = 20? So that the next edit unit would extend past the end of
> the KLV, and thus be bogus?
> 
>   KLV: |header|---|header|--|
> Edit unit:|0123456789|bogus<10|  |0123456789|bgs|
> 
> IIRC with MXF the bogus parts should still count as part of the
> essence stream. Maybe I'm missing something.

It's simpler than that, and if you don't understand then the comment
likely needs improving :) let's see:

H = header, V = video, A,B,C = audio tracks, F = fill item

mxf file defines a proper edit unit, with EUBC = 10 to be something
like:

1234567890
HVVVAFBFCF

now, in the samples, in some edit units, video is shorter; mxf spec
says it should be padded by fill items, but they're not and look like:

1234567890
HVAFBFCF

when continuing to read, we have:

12345678901234567890
HVAFBFCFHVVVAFBFCF
| eu 1   || eu 2   |

as you can see, 2nd video packet is still in the first edit unit
according to EUBC, and extends to next one.

that's what the patch is about: try to increment edit unit before
rejecting the packet.

in 'MXF_DVCAM_not_demuxable.mxf', those smaller video packets seem to
correspond to a black frame inserted between two scenes.

I've tried hard to get something better, but nothing seemed to work
properly; best other option I had was to increment edit unit when
seeing a system item, which worked but broke tests and in which I'm not
so confident it won't break with other broken files...

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

Re: [FFmpeg-devel] [PATCHv2] mmaldec: Add mpeg2 decoding support

[wm4]

On Wed, 21 Oct 2015 17:10:48 +0200
Julian Scheel  wrote:

> Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
> matter of setting the correct MMAL_ENCODING on the input port. To ease the
> addition of further supported mmal codecs a macro is introduced to generate
> the decoder and decoder class structs.
> 
> Signed-off-by: Julian Scheel 
> ---
> Changes in v2:
> - Replace error log message in init decoder with debug log message (thanks
>   Hendrik for spotting it)
> ---
>  configure  |  3 +++
>  libavcodec/Makefile|  1 +
>  libavcodec/allcodecs.c |  2 ++
>  libavcodec/mmaldec.c   | 71 
> +-
>  4 files changed, 53 insertions(+), 24 deletions(-)
> 
> diff --git a/configure b/configure
> index 1bbaf7f..a38b290 100755
> --- a/configure
> +++ b/configure
> @@ -2481,6 +2481,9 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
>  mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
>  mpeg2_dxva2_hwaccel_deps="dxva2"
>  mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
> +mpeg2_mmal_decoder_deps="mmal"
> +mpeg2_mmal_hwaccel_deps="mmal"
> +mpeg2_mmal_decoder_select="mpeg2video_decoder"
>  mpeg2_qsv_hwaccel_deps="libmfx"
>  mpeg2_qsv_hwaccel_select="qsvdec_mpeg2"
>  mpeg2_vaapi_hwaccel_deps="vaapi"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index af93f8a..f85fc18 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -370,6 +370,7 @@ OBJS-$(CONFIG_MPEG1VIDEO_DECODER)  += mpeg12dec.o 
> mpeg12.o mpeg12data.o
>  OBJS-$(CONFIG_MPEG1VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
>  OBJS-$(CONFIG_MPEG2VIDEO_DECODER)  += mpeg12dec.o mpeg12.o mpeg12data.o
>  OBJS-$(CONFIG_MPEG2VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
> +OBJS-$(CONFIG_MPEG2_MMAL_DECODER)  += mmaldec.o
>  OBJS-$(CONFIG_MPEG2_QSV_DECODER)   += qsvdec_mpeg2.o
>  OBJS-$(CONFIG_MPEG2_QSV_ENCODER)   += qsvenc_mpeg2.o
>  OBJS-$(CONFIG_MPEG4_DECODER)   += xvididct.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index d62bec7..7279620 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -97,6 +97,7 @@ void avcodec_register_all(void)
>  REGISTER_HWACCEL(MPEG2_XVMC,mpeg2_xvmc);
>  REGISTER_HWACCEL(MPEG2_D3D11VA, mpeg2_d3d11va);
>  REGISTER_HWACCEL(MPEG2_DXVA2,   mpeg2_dxva2);
> +REGISTER_HWACCEL(MPEG2_MMAL,mpeg2_mmal);
>  REGISTER_HWACCEL(MPEG2_QSV, mpeg2_qsv);
>  REGISTER_HWACCEL(MPEG2_VAAPI,   mpeg2_vaapi);
>  REGISTER_HWACCEL(MPEG2_VDPAU,   mpeg2_vdpau);
> @@ -238,6 +239,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(MPEG_VDPAU,mpeg_vdpau);
>  REGISTER_DECODER(MPEG1_VDPAU,   mpeg1_vdpau);
>  #endif
> +REGISTER_DECODER(MPEG2_MMAL,mpeg2_mmal);
>  REGISTER_DECODER(MPEG2_CRYSTALHD,   mpeg2_crystalhd);
>  REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
>  REGISTER_DECODER(MSA1,  msa1);
> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> index 13cc191..91fb084 100644
> --- a/libavcodec/mmaldec.c
> +++ b/libavcodec/mmaldec.c
> @@ -350,7 +350,17 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
> *avctx)
>  
>  format_in = decoder->input[0]->format;
>  format_in->type = MMAL_ES_TYPE_VIDEO;
> -format_in->encoding = MMAL_ENCODING_H264;
> +switch (avctx->codec_id) {
> +case AV_CODEC_ID_MPEG2VIDEO:
> +format_in->encoding = MMAL_ENCODING_MP2V;
> +av_log(avctx, AV_LOG_DEBUG, "Use MMAL MP2V encoding\n");
> +break;
> +case AV_CODEC_ID_H264:
> +default:
> +format_in->encoding = MMAL_ENCODING_H264;
> +av_log(avctx, AV_LOG_DEBUG, "Use MMAL H264 encoding\n");
> +break;
> +}
>  format_in->es->video.width = FFALIGN(avctx->width, 32);
>  format_in->es->video.height = FFALIGN(avctx->height, 16);
>  format_in->es->video.crop.width = avctx->width;
> @@ -766,31 +776,44 @@ AVHWAccel ff_h264_mmal_hwaccel = {
>  .pix_fmt= AV_PIX_FMT_MMAL,
>  };
>  
> +AVHWAccel ff_mpeg2_mmal_hwaccel = {
> +.name   = "mpeg2_mmal",
> +.type   = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_MPEG2VIDEO,
> +.pix_fmt= AV_PIX_FMT_MMAL,
> +};
> +
>  static const AVOption options[]={
>  {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, 
> extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
>  {NULL}
>  };
>  
> -static const AVClass ffmmaldec_class = {
> -.class_name = "mmaldec",
> -.option = options,
> -.version= LIBAVUTIL_VERSION_INT,
> -};
> -
> -AVCodec ff_h264_mmal_decoder = {
> -.name   = "h264_mmal",
> -.long_name  = NULL_IF_CONFIG_SMALL("h264 (mmal)"),
> -.type   = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_H264,
> -.priv_data_size = sizeof(MMALDecodeContext),
> -.init   = 

Re: [FFmpeg-devel] [PATCH] configure: add -Wstrict-prototypes when available

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 2:45 PM, Hendrik Leppkes  wrote:
> On Thu, Oct 22, 2015 at 8:40 PM, Ganesh Ajjanagadde
>  wrote:
>> GCC (and Clang) have this useful warning that is not enabled by -Wall or
>> -Wextra. This will ensure that issues like those fixed in
>> 4da52e3630343e8d3a79aef2cafcb6bf0b71e8da
>> will trigger warnings.
>>
>
> I did get this warning on GCC 5.2, which is how I found it in the
> first place. :)
> Seems to be enabled by default here at least.

Strange, I also run GCC 5.2 and it is not enabled by default, or even
with "-Wall -Wextra -pedantic".

>
> Otherwise probably OK if its not enabled on other compilers that
> understand such a flag.

Will wait to see if there are issues with some less-used compilers.

>
> - 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] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Thierry Foucu]

---
 libavformat/riff.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/riff.c b/libavformat/riff.c
index a9197e7..7de8936 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
 { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB, 0x71, 0x44, 
0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
 { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB, 0x42, 
0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
 { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF, 0x11, 
0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
+{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
 { AV_CODEC_ID_NONE }
 };
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [FFmpeg-devel] [PATCH 01/11] libavformat/mxfdec.c: klv_read_packet: Properly check klv_decode_ber_length return value.

[Alexis Ballier]

On Wed, 21 Oct 2015 23:31:29 +0200
Tomas Härdin  wrote:

> On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> > klv_decode_ber_length cannot return -1, but can return
> > AVERROR_INVALIDDATA. Store its return value in a signed integer
> > (instead of unsigned KLVPacket.length) and forward the error
> > appropriately. --- libavformat/mxfdec.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 00d420b..94a953b 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -366,13 +366,15 @@ static int mxf_read_sync(AVIOContext *pb,
> > const uint8_t *key, unsigned size) 
> >  static int klv_read_packet(KLVPacket *klv, AVIOContext *pb)
> >  {
> > +int64_t len;
> >  if (!mxf_read_sync(pb, mxf_klv_key, 4))
> >  return AVERROR_INVALIDDATA;
> >  klv->offset = avio_tell(pb) - 4;
> >  memcpy(klv->key, mxf_klv_key, 4);
> >  avio_read(pb, klv->key + 4, 12);
> > -klv->length = klv_decode_ber_length(pb);
> > -return klv->length == -1 ? -1 : 0;
> > +len = klv_decode_ber_length(pb);
> > +klv->length = FFMAX(len, 0);
> > +return FFMIN(len, 0);
> >  }  
> 
> Can't klv_read_packet() return int64_t instead?

you mean change the return type and return klv->length ?
that might work, but note that what I'm trying to fix is
klv_read_packet setting length to (unsigned)AVERROR_INVALIDDATA, i.e.,
something close to 2^64, and returning 0.
I don't see any problem by doing that, so it is as you prefer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add -Wstrict-prototypes when available

[Hendrik Leppkes]

On Thu, Oct 22, 2015 at 8:40 PM, Ganesh Ajjanagadde
 wrote:
> GCC (and Clang) have this useful warning that is not enabled by -Wall or
> -Wextra. This will ensure that issues like those fixed in
> 4da52e3630343e8d3a79aef2cafcb6bf0b71e8da
> will trigger warnings.
>

I did get this warning on GCC 5.2, which is how I found it in the
first place. :)
Seems to be enabled by default here at least.

Otherwise probably OK if its not enabled on other compilers that
understand such a flag.

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

[FFmpeg-devel] [PATCH] configure: add -Wstrict-prototypes when available

[Ganesh Ajjanagadde]

GCC (and Clang) have this useful warning that is not enabled by -Wall or
-Wextra. This will ensure that issues like those fixed in
4da52e3630343e8d3a79aef2cafcb6bf0b71e8da
will trigger warnings.

Signed-off-by: Ganesh Ajjanagadde 
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index a38b290..276ec30 100755
--- a/configure
+++ b/configure
@@ -5637,6 +5637,7 @@ disabled iconv || check_func_headers iconv.h iconv || 
check_lib2 iconv.h iconv -
 enabled debug && add_cflags -g"$debuglevel" && add_asflags -g"$debuglevel"
 
 # add some useful compiler flags if supported
+check_cflags -Wstrict-prototypes
 check_cflags -Wdeclaration-after-statement
 check_cflags -Wall
 check_cflags -Wdisabled-optimization
-- 
2.6.2

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

[FFmpeg-devel] Using ffmpeg library

[mohamed larbi gharib]

Hi,

Thank you for your help.

I would like to get information on what library shall I use for parsing
data from a transport stream file MPEG2/h264.

I would like to use ffprobe tools but as functions in my program (written
in C) returning a structure with stream index codec_name codec_tag and
codec_type and extra information.

example:

struct stream{
   int index;
   char* codec_name;
   char* codec_tag;
   char* codec_type;
   //
}

Actually I am using ffprobe in CLI outputting in JSON format and than I
parse the information using cJSON (https://github.com/kbranigan/cJSON) but
it is too slow.

Best regards,

-- 
Larbi Gharib
Diplômé en Génie Électrique à l'Université Laval

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

[FFmpeg-devel] [PATCH] vf_psnr: remove %0.2f format specifiers for stream summary line.

[Ronald S. Bultje]

This makes output equally precise as vf_ssim.
---
 libavfilter/vf_psnr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index a01b2c1..4f060c9 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -322,10 +322,10 @@ static av_cold void uninit(AVFilterContext *ctx)
 buf[0] = 0;
 for (j = 0; j < s->nb_components; j++) {
 int c = s->is_rgb ? s->rgba_map[j] : j;
-av_strlcatf(buf, sizeof(buf), " %c:%0.2f", s->comps[j],
+av_strlcatf(buf, sizeof(buf), " %c:%f", s->comps[j],
 get_psnr(s->mse_comp[c], s->nb_frames, s->max[c]));
 }
-av_log(ctx, AV_LOG_INFO, "PSNR%s average:%0.2f min:%0.2f max:%0.2f\n",
+av_log(ctx, AV_LOG_INFO, "PSNR%s average:%f min:%f max:%f\n",
buf,
get_psnr(s->mse, s->nb_frames, s->average_max),
get_psnr(s->max_mse, 1, s->average_max),
-- 
2.1.2

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

[FFmpeg-devel] [PATCH] vf_ssim: print per-channel dB values.

[Ronald S. Bultje]

---
 libavfilter/vf_ssim.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
index 5cd9361..e7a64f7 100644
--- a/libavfilter/vf_ssim.c
+++ b/libavfilter/vf_ssim.c
@@ -346,7 +346,8 @@ static av_cold void uninit(AVFilterContext *ctx)
 buf[0] = 0;
 for (i = 0; i < s->nb_components; i++) {
 int c = s->is_rgb ? s->rgba_map[i] : i;
-av_strlcatf(buf, sizeof(buf), " %c:%f", s->comps[i], s->ssim[c] / 
s->nb_frames);
+av_strlcatf(buf, sizeof(buf), " %c:%f (%f)", s->comps[i], 
s->ssim[c] / s->nb_frames,
+ssim_db(s->ssim[c], s->nb_frames));
 }
 av_log(ctx, AV_LOG_INFO, "SSIM%s All:%f (%f)\n", buf,
s->ssim_total / s->nb_frames, ssim_db(s->ssim_total, 
s->nb_frames));
-- 
2.1.2

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

Re: [FFmpeg-devel] [PATCH] avformat/electronicarts: support ADPCM PSX

[Paul B Mahol]

Dana 22. 10. 2015. 06:30 osoba "Peter Ross"  napisala je:
>
> On Wed, Oct 21, 2015 at 11:14:02PM +0200, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavformat/electronicarts.c | 19 +++
> >  1 file changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> > index c0b6d6e..12eec80 100644
> > --- a/libavformat/electronicarts.c
> > +++ b/libavformat/electronicarts.c
> > @@ -86,6 +86,8 @@ typedef struct EaDemuxContext {
> >  int sample_rate;
> >  int num_channels;
> >  int num_samples;
> > +
> > +int platform;
> >  } EaDemuxContext;
>
> all looks okay
> tested with psx samples
>
> > @@ -653,7 +664,7 @@ static int ea_read_packet(AVFormatContext *s,
AVPacket *pkt)
> >  case SEND_TAG:
> >  case SEEN_TAG:
> >  while (!avio_feof(pb)) {
> > -if (avio_rl32(pb)) {
> > +if (avio_rl32(pb) == SCHl_TAG) {
> >  avio_skip(pb, -4);
> >  break;
> >  }
>
> seems unrelated to demuxing files containing ADPCM PSX audio?

The adpcm psx one contain some junk bytes causing premature eof, so I wil
also check for other tags. Thanks.

>
> also note, this case block is triggered by several different versions of
elecontric arts files
> 'end audio stream tags' (SEAD, 1SNx, SCxLl). but when with this hunk
applied, the loop only ends early
> if 'SCHl_TAG' is reached.
>
> -- Peter
> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
>
> ___
> 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] Nvidia nevec presets

[Timo Rothenpieler]

Thanks for all , if you add "*Streaming*" *Presets* To Nvidia Nevec
  Presets , like this :

Automatic
Low Latency
Low Latency 2Pass
HQ Low Latency 2Pass
Lossless
HP lossless

Thanks



Not sure what you mean with this.
The ll/llhq/hp/... presets are all available. You can also enable 2pass 
mode for basically all of them. So I don't see anything missing here?




Timo





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

Re: [FFmpeg-devel] Encoding with QSV at an API level.

[Paul Knopf]

That was it! Thanks very much!

On Wed, Oct 21, 2015 at 4:38 PM, Hendrik Leppkes 
wrote:

> On Wed, Oct 21, 2015 at 9:42 PM, Paul Knopf 
> wrote:
> > I just realized that I was also getting an error on the stdout.
> >
> > [h264_qsv @ 00c7e6d8e680] Specified pixel format yuv420p is
> > invalid or not supported
> >
>
> Which probably means you also get an error return from one of the
> initialization functions which you didn't check.
> In any case, QSV encoding wants NV12 video, not YUV420P.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



-- 
Thanks!

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

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Hendrik Leppkes]

On Thu, Oct 22, 2015 at 1:29 PM, Sven Dueking  wrote:
>
>
>> -Ursprüngliche Nachricht-
>> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
>> von Carl Eugen Hoyos
>> Gesendet: Mittwoch, 14. Oktober 2015 12:43
>> An: FFmpeg development discussions and patches
>> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
>>
>> On Wednesday 14 October 2015 10:07:04 am Sven Dueking wrote:
>> > Hi all,
>> >
>> > The attached patches adds the VPP as filter module to FFMpeg.
>> > Looking forward to get feedback.
>>
>> Just a few comments, I expect you will get a comment explaining what
>> you can't do;-) (Sorry for the partly broken quotation.)
>>
>> In any case, please merge both patches, they are not independent.
>>
>> >
>> > Many thanks,
>> > Sven
>>
>> > From d09cff6d868bd2a0fd87e3906f8808638809494b Mon Sep 17 00:00:00
>> 2001
>> > From: Sven Dueking 
>> > Date: Wed, 14 Oct 2015 08:13:38 +0100
>> > Subject: [PATCH 1/2] added QSV based VPP filter
>> >
>> > ---
>> >  libavfilter/vf_qsv_vpp.c | 686
>> > +++ 1 file changed, 686
>> > insertions(+)
>> >  create mode 100644 libavfilter/vf_qsv_vpp.c
>> >
>> > diff --git a/libavfilter/vf_qsv_vpp.c b/libavfilter/vf_qsv_vpp.c new
>> > file mode 100644 index 000..629913e
>> > --- /dev/null
>> > +++ b/libavfilter/vf_qsv_vpp.c
>> > @@ -0,0 +1,686 @@
>> > +/*
>> > + * Intel MediaSDK Quick Sync Video VPP filter
>> > + *
>> > + * copyright (c) 2015 Sven Dueking
>> > + *
>> > + * This file is part of FFmpeg.
>> > + *
>> > + * Libav 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.
>> > + *
>> > + * Libav 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 Libav; if not, write to the Free Software
>> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> > 02110-1301 USA + */
>> > +
>> > +#include 
>> > +#include 
>> > +
>> > +#include "avfilter.h"
>> > +#include "internal.h"
>> > +#include "formats.h"
>> > +
>> > +#include "libavutil/avassert.h"
>> > +#include "libavutil/opt.h"
>> > +#include "libavutil/time.h"
>> > +#include "libavutil/avstring.h"
>> > +#include "libavutil/error.h"
>> > +#include "libavcodec/avcodec.h"
>> > +#include "libavcodec/qsv_internal.h"
>> > +
>> > +#include 
>> > +
>> > +#include "avfilter.h"
>> > +#include "formats.h"
>> > +#include "internal.h"
>> > +#include "video.h"
>> > +#include "libavutil/eval.h"
>> > +#include "libavutil/avstring.h"
>> > +#include "libavutil/internal.h"
>> > +#include "libavutil/libm.h"
>> > +#include "libavutil/imgutils.h"
>> > +#include "libavutil/mathematics.h"
>> > +#include "libavutil/opt.h"
>> > +#include "libavutil/pixfmt.h"
>>
>> Are they all necessary?
>>
>> > +
>> > +/**
>> > + * ToDo :
>> > + *
>> > + * - handle empty extbuffers
>> > + * - cropping
>> > + * - allocate number of surfaces depending modules and number of b
>> > +frames  */
>> > +
>> > +#define VPP_ZERO_MEMORY(VAR){ memset(, 0, sizeof(VAR));
>> }
>>
>> I don't think this is more readable, but that may only be me.
>>
>> > +#define VPP_ALIGN16(value)  (((value + 15) >> 4) << 4)
>> //
>> > round up to a multiple of 16 +#define VPP_ALIGN32(value)
>> (((value
>> > + 31) >> 5) << 5)  // round up to a multiple of 32 +#define
>>
>> Isn't this FFALIGN()?
>>
>> > VPP_CHECK_POINTER(P, ...)   {if (!(P)) {return __VA_ARGS__;}} +
>> > +// number of video enhancement filters (denoise, procamp, detail,
>> > video_analysis, image stab) +#define ENH_FILTERS_COUNT   5
>> > +
>> > +typedef struct {
>> > +const AVClass *class;
>> > +
>> > +AVFilterContext *ctx;
>> > +
>> > +mfxSession session;
>> > +QSVSession internal_qs;
>> > +
>> > +AVRational framerate;   // target
>> framerate
>> > +
>> > +mfxFrameSurface1 **in_surface;
>> > +mfxFrameSurface1 **out_surface;
>> > +
>> > +mfxFrameAllocRequest req[2];// [0] - in, [1]
>> - out
>> > +
>> > +int num_surfaces_in;// input
>> surfaces
>> > +int num_surfaces_out;   // output
>> surfaces
>> > +
>> > +unsigned char * surface_buffers_out;// output
>> surface
>> > buffer +
>> > +char *load_plugins;
>> > +
>> > +mfxVideoParam* pVppParam;
>> > +
>> > +int cur_out_idx;
>> > +
>> > +/* VPP extension */
>> > +mfxExtBuffer* pExtBuf[1+ENH_FILTERS_COUNT];
>> > +mfxExtVppAuxData 

Re: [FFmpeg-devel] [PATCH] libavformat/electronicarts: also demux mpeg audio layer 2

[Michael Niedermayer]

On Thu, Oct 22, 2015 at 05:47:33AM +0200, Paul B Mahol wrote:
> On 10/22/15, Peter Ross  wrote:
> > Signed-off-by: Peter Ross 
> >
> > http://wiki.multimedia.cx/index.php?title=Electronic_Arts_SCxl
> > ---
> >  libavformat/electronicarts.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> > index 5d21d49..335a635 100644
> > --- a/libavformat/electronicarts.c
> > +++ b/libavformat/electronicarts.c
> > @@ -237,6 +237,7 @@ static int process_audio_header_elements(AVFormatContext
> > *s)
> >  return 0;
> >  }
> >  break;
> > +case 15:
> >  case 16:
> >  ea->audio_codec = AV_CODEC_ID_MP3;
> >  break;
> > --
> > 2.1.4
> >
> > -- Peter
> > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
> >
> 
> ok

applied

thanks

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Carl Eugen Hoyos
> Gesendet: Mittwoch, 14. Oktober 2015 12:43
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> 
> On Wednesday 14 October 2015 10:07:04 am Sven Dueking wrote:
> > Hi all,
> >
> > The attached patches adds the VPP as filter module to FFMpeg.
> > Looking forward to get feedback.
> 
> Just a few comments, I expect you will get a comment explaining what
> you can't do;-) (Sorry for the partly broken quotation.)
> 
> In any case, please merge both patches, they are not independent.
> 
> >
> > Many thanks,
> > Sven
> 
> > From d09cff6d868bd2a0fd87e3906f8808638809494b Mon Sep 17 00:00:00
> 2001
> > From: Sven Dueking 
> > Date: Wed, 14 Oct 2015 08:13:38 +0100
> > Subject: [PATCH 1/2] added QSV based VPP filter
> >
> > ---
> >  libavfilter/vf_qsv_vpp.c | 686
> > +++ 1 file changed, 686
> > insertions(+)
> >  create mode 100644 libavfilter/vf_qsv_vpp.c
> >
> > diff --git a/libavfilter/vf_qsv_vpp.c b/libavfilter/vf_qsv_vpp.c new
> > file mode 100644 index 000..629913e
> > --- /dev/null
> > +++ b/libavfilter/vf_qsv_vpp.c
> > @@ -0,0 +1,686 @@
> > +/*
> > + * Intel MediaSDK Quick Sync Video VPP filter
> > + *
> > + * copyright (c) 2015 Sven Dueking
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * Libav 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.
> > + *
> > + * Libav 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 Libav; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include "avfilter.h"
> > +#include "internal.h"
> > +#include "formats.h"
> > +
> > +#include "libavutil/avassert.h"
> > +#include "libavutil/opt.h"
> > +#include "libavutil/time.h"
> > +#include "libavutil/avstring.h"
> > +#include "libavutil/error.h"
> > +#include "libavcodec/avcodec.h"
> > +#include "libavcodec/qsv_internal.h"
> > +
> > +#include 
> > +
> > +#include "avfilter.h"
> > +#include "formats.h"
> > +#include "internal.h"
> > +#include "video.h"
> > +#include "libavutil/eval.h"
> > +#include "libavutil/avstring.h"
> > +#include "libavutil/internal.h"
> > +#include "libavutil/libm.h"
> > +#include "libavutil/imgutils.h"
> > +#include "libavutil/mathematics.h"
> > +#include "libavutil/opt.h"
> > +#include "libavutil/pixfmt.h"
> 
> Are they all necessary?
> 
> > +
> > +/**
> > + * ToDo :
> > + *
> > + * - handle empty extbuffers
> > + * - cropping
> > + * - allocate number of surfaces depending modules and number of b
> > +frames  */
> > +
> > +#define VPP_ZERO_MEMORY(VAR){ memset(, 0, sizeof(VAR));
> }
> 
> I don't think this is more readable, but that may only be me.
> 
> > +#define VPP_ALIGN16(value)  (((value + 15) >> 4) << 4)
> //
> > round up to a multiple of 16 +#define VPP_ALIGN32(value)
> (((value
> > + 31) >> 5) << 5)  // round up to a multiple of 32 +#define
> 
> Isn't this FFALIGN()?
> 
> > VPP_CHECK_POINTER(P, ...)   {if (!(P)) {return __VA_ARGS__;}} +
> > +// number of video enhancement filters (denoise, procamp, detail,
> > video_analysis, image stab) +#define ENH_FILTERS_COUNT   5
> > +
> > +typedef struct {
> > +const AVClass *class;
> > +
> > +AVFilterContext *ctx;
> > +
> > +mfxSession session;
> > +QSVSession internal_qs;
> > +
> > +AVRational framerate;   // target
> framerate
> > +
> > +mfxFrameSurface1 **in_surface;
> > +mfxFrameSurface1 **out_surface;
> > +
> > +mfxFrameAllocRequest req[2];// [0] - in, [1]
> - out
> > +
> > +int num_surfaces_in;// input
> surfaces
> > +int num_surfaces_out;   // output
> surfaces
> > +
> > +unsigned char * surface_buffers_out;// output
> surface
> > buffer +
> > +char *load_plugins;
> > +
> > +mfxVideoParam* pVppParam;
> > +
> > +int cur_out_idx;
> > +
> > +/* VPP extension */
> > +mfxExtBuffer* pExtBuf[1+ENH_FILTERS_COUNT];
> > +mfxExtVppAuxData extVPPAuxData;
> > +
> > +/* Video Enhancement Algorithms */
> > +mfxExtVPPDeinterlacing deinterlace_conf;
> > +mfxExtVPPFrameRateConversion frc_conf;
> > +mfxExtVPPDenoise denoise_conf;
> > +

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Hendrik Leppkes
> Gesendet: Donnerstag, 22. Oktober 2015 14:00
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> 
> On Thu, Oct 22, 2015 at 1:29 PM, Sven Dueking  wrote:
> >
> >
> >> -Ursprüngliche Nachricht-
> >> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
> Auftrag
> >> von Carl Eugen Hoyos
> >> Gesendet: Mittwoch, 14. Oktober 2015 12:43
> >> An: FFmpeg development discussions and patches
> >> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> >>
> >> On Wednesday 14 October 2015 10:07:04 am Sven Dueking wrote:
> >> > Hi all,
> >> >
> >> > The attached patches adds the VPP as filter module to FFMpeg.
> >> > Looking forward to get feedback.
> >>
> >> Just a few comments, I expect you will get a comment explaining what
> >> you can't do;-) (Sorry for the partly broken quotation.)
> >>
> >> In any case, please merge both patches, they are not independent.
> >>
> >> >
> >> > Many thanks,
> >> > Sven
> >>
> >> > From d09cff6d868bd2a0fd87e3906f8808638809494b Mon Sep 17 00:00:00
> >> 2001
> >> > From: Sven Dueking 
> >> > Date: Wed, 14 Oct 2015 08:13:38 +0100
> >> > Subject: [PATCH 1/2] added QSV based VPP filter
> >> >
> >> > ---
> >> >  libavfilter/vf_qsv_vpp.c | 686
> >> > +++ 1 file changed,
> 686
> >> > insertions(+)
> >> >  create mode 100644 libavfilter/vf_qsv_vpp.c
> >> >
> >> > diff --git a/libavfilter/vf_qsv_vpp.c b/libavfilter/vf_qsv_vpp.c
> >> > new file mode 100644 index 000..629913e
> >> > --- /dev/null
> >> > +++ b/libavfilter/vf_qsv_vpp.c
> >> > @@ -0,0 +1,686 @@
> >> > +/*
> >> > + * Intel MediaSDK Quick Sync Video VPP filter
> >> > + *
> >> > + * copyright (c) 2015 Sven Dueking
> >> > + *
> >> > + * This file is part of FFmpeg.
> >> > + *
> >> > + * Libav 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.
> >> > + *
> >> > + * Libav 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 Libav; if not, write to the Free Software
> >> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> >> > 02110-1301 USA + */
> >> > +
> >> > +#include 
> >> > +#include 
> >> > +
> >> > +#include "avfilter.h"
> >> > +#include "internal.h"
> >> > +#include "formats.h"
> >> > +
> >> > +#include "libavutil/avassert.h"
> >> > +#include "libavutil/opt.h"
> >> > +#include "libavutil/time.h"
> >> > +#include "libavutil/avstring.h"
> >> > +#include "libavutil/error.h"
> >> > +#include "libavcodec/avcodec.h"
> >> > +#include "libavcodec/qsv_internal.h"
> >> > +
> >> > +#include 
> >> > +
> >> > +#include "avfilter.h"
> >> > +#include "formats.h"
> >> > +#include "internal.h"
> >> > +#include "video.h"
> >> > +#include "libavutil/eval.h"
> >> > +#include "libavutil/avstring.h"
> >> > +#include "libavutil/internal.h"
> >> > +#include "libavutil/libm.h"
> >> > +#include "libavutil/imgutils.h"
> >> > +#include "libavutil/mathematics.h"
> >> > +#include "libavutil/opt.h"
> >> > +#include "libavutil/pixfmt.h"
> >>
> >> Are they all necessary?
> >>
> >> > +
> >> > +/**
> >> > + * ToDo :
> >> > + *
> >> > + * - handle empty extbuffers
> >> > + * - cropping
> >> > + * - allocate number of surfaces depending modules and number of
> b
> >> > +frames  */
> >> > +
> >> > +#define VPP_ZERO_MEMORY(VAR){ memset(, 0,
> sizeof(VAR));
> >> }
> >>
> >> I don't think this is more readable, but that may only be me.
> >>
> >> > +#define VPP_ALIGN16(value)  (((value + 15) >> 4) << 4)
> >> //
> >> > round up to a multiple of 16 +#define VPP_ALIGN32(value)
> >> (((value
> >> > + 31) >> 5) << 5)  // round up to a multiple of 32
> +#define
> >>
> >> Isn't this FFALIGN()?
> >>
> >> > VPP_CHECK_POINTER(P, ...)   {if (!(P)) {return __VA_ARGS__;}} +
> >> > +// number of video enhancement filters (denoise, procamp, detail,
> >> > video_analysis, image stab) +#define ENH_FILTERS_COUNT   5
> >> > +
> >> > +typedef struct {
> >> > +const AVClass *class;
> >> > +
> >> > +AVFilterContext *ctx;
> >> > +
> >> > +mfxSession session;
> >> > +QSVSession internal_qs;
> >> > +
> >> > +AVRational framerate;   // target
> >> framerate
> >> > +
> >> > +mfxFrameSurface1 **in_surface;
> >> > +mfxFrameSurface1 

Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 5:49 AM, Carl Eugen Hoyos  wrote:
> Ganesh Ajjanagadde  gmail.com> writes:
>
>> > This broke fate with -ftrapv
>
>> > The problem seems to be in av_gcd() and not the De-Bruijn version of
>> > ff_ctzll since the gcc builtin is being used.
>>
>> Don't have the time to investigate right now - revert for now unless
>> someone can fix it quickly.
>
> Ping?
>
> Please revert if nobody can fix this.

"Fixing" this at the moment is highly dubious - read the thread. It
does not even occur in a reproducible way, does not trigger on ubsan,
I can't even see it on ftrapv. Show me why it is not a toolchain
issue.

>
> Carl Eugen
>
> ___
> 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 1/1] avcodec/png: read and write stereo3d frame side data information

[Gonzalo]

El 22/10/15 a las 17:50, Kirill Gavrilov escribió:

Use optional sTER chunk defining side-by-side stereo pair
within "Extensions to the PNG 1.2 Specification", version 1.3.0.

Specification:
http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

Note that patch does not add any image resolution checks defined by spec.

Regards,
Kirill

Do you have an example of writing a stereo image through the API?

--
Gonzalo Garramuño
ggarr...@gmail.com

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

Re: [FFmpeg-devel] [PATCH] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Hendrik Leppkes]

On Thu, Oct 22, 2015 at 11:48 PM, Thierry Foucu  wrote:
> On Thu, Oct 22, 2015 at 2:29 PM, Hendrik Leppkes 
> wrote:
>
>> On Thu, Oct 22, 2015 at 11:15 PM, Thierry Foucu  wrote:
>> > On Thu, Oct 22, 2015 at 2:08 PM, Hendrik Leppkes 
>> > wrote:
>> >
>> >> On Thu, Oct 22, 2015 at 9:19 PM, Thierry Foucu 
>> wrote:
>> >> > ---
>> >> >  libavformat/riff.c | 1 +
>> >> >  1 file changed, 1 insertion(+)
>> >> >
>> >> > diff --git a/libavformat/riff.c b/libavformat/riff.c
>> >> > index a9197e7..7de8936 100644
>> >> > --- a/libavformat/riff.c
>> >> > +++ b/libavformat/riff.c
>> >> > @@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
>> >> >  { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB,
>> 0x71,
>> >> 0x44, 0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
>> >> >  { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D,
>> 0xFB,
>> >> 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
>> >> >  { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB,
>> 0xCF,
>> >> 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
>> >> > +{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
>> 0x00,
>> >> 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
>> >> >  { AV_CODEC_ID_NONE }
>> >> >  };
>> >> > --
>> >>
>> >> This is the generic PCM GUID, isn't it? It could be any PCM bitdepth,
>> >> so the patch does not appear correct to me.
>> >>
>> >
>> > Should i then look for the generic PCM GUID (to decide this is a PCM
>> codec)
>> > and base on the bits_per_coded_sample, selects the PCM codec?
>> >
>> >
>>
>> From what I can tell such files should already be handled by the
>> generic WAVEFORMATEXTENSIBLE handler.
>> Can you share a file which doesn't work as expected?
>>
>>
> No pb. just uploaded to the ftp a file name
> raw_video_pcm_s24le.avi
>

That tool sure is writing weird broken files.
The usual base GUID is {--0010-8000-00AA00389B71}

This thing writes {----100080aa} and then has
8 bytes of extradata which contain the remainder of the GUID (and 4
zeros)
It  seems like they screwed something up and shifted the proper GUID
by 4 bytes after the expected field.

Does any software play this PCM track?

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

Re: [FFmpeg-devel] [PATCH] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Paul B Mahol]

On 10/22/15, Thierry Foucu  wrote:
> ---
>  libavformat/riff.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/riff.c b/libavformat/riff.c
> index a9197e7..7de8936 100644
> --- a/libavformat/riff.c
> +++ b/libavformat/riff.c
> @@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
>  { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB, 0x71,
> 0x44, 0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
>  { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB,
> 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
>  { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF,
> 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
> +{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
>  { AV_CODEC_ID_NONE }
>  };
> --
> 2.6.0.rc2.230.g3dd15c0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Sample? What creates such files?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 4:51 PM, Carl Eugen Hoyos  wrote:
> Ganesh Ajjanagadde  mit.edu> writes:
>
>> To put an end to a long and tortuous thread, and
>> due to the lack of relevant outstanding objections,
>> pushed.
>
> To sum it up:
> Several developers have explained to you that the
> numbers you posted show that FFmpeg is now either
> slower or equally fast, you have pushed with a
> commit message that claims that your patch makes
> FFmpeg faster.

I was far more nuanced because I know there are people like you who do
not understand such things. Seems like I failed at that anyway. I am
sorry, but I can only repeat the first two lines:
"It is well known that fabs and fabsf are at least as fast and sometimes
faster than the FFABS macro, at least on the gcc+glibc combination."

That statement is completely accurate. I did not claim "within
FFmpeg", since like I said usually there is no difference.

From where the "slower" comes from god knows.

> How do you call such a claim without any base?

Look at the asm, etc etc. Clement has already showed the difference.
"Without any base" is a completely incorrect and illogical statement.
Paul is clearly convinced enough to start using it in his own filters.

> Carl Eugen
>
> ___
> 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] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Thierry Foucu]

On Thu, Oct 22, 2015 at 1:45 PM, Paul B Mahol  wrote:

> On 10/22/15, Thierry Foucu  wrote:
> > ---
> >  libavformat/riff.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/riff.c b/libavformat/riff.c
> > index a9197e7..7de8936 100644
> > --- a/libavformat/riff.c
> > +++ b/libavformat/riff.c
> > @@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
> >  { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB, 0x71,
> > 0x44, 0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
> >  { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB,
> > 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
> >  { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF,
> > 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
> > +{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
> >  { AV_CODEC_ID_NONE }
> >  };
> > --
> > 2.6.0.rc2.230.g3dd15c0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> Sample? What creates such files?
>


File was generated by Media Express under Linux
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Thierry Foucu]

On Thu, Oct 22, 2015 at 2:08 PM, Hendrik Leppkes 
wrote:

> On Thu, Oct 22, 2015 at 9:19 PM, Thierry Foucu  wrote:
> > ---
> >  libavformat/riff.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/riff.c b/libavformat/riff.c
> > index a9197e7..7de8936 100644
> > --- a/libavformat/riff.c
> > +++ b/libavformat/riff.c
> > @@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
> >  { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB, 0x71,
> 0x44, 0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
> >  { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB,
> 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
> >  { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF,
> 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
> > +{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
> >  { AV_CODEC_ID_NONE }
> >  };
> > --
>
> This is the generic PCM GUID, isn't it? It could be any PCM bitdepth,
> so the patch does not appear correct to me.
>

Should i then look for the generic PCM GUID (to decide this is a PCM codec)
and base on the bits_per_coded_sample, selects the PCM codec?


>
> - 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] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Thierry Foucu]

On Thu, Oct 22, 2015 at 2:29 PM, Hendrik Leppkes 
wrote:

> On Thu, Oct 22, 2015 at 11:15 PM, Thierry Foucu  wrote:
> > On Thu, Oct 22, 2015 at 2:08 PM, Hendrik Leppkes 
> > wrote:
> >
> >> On Thu, Oct 22, 2015 at 9:19 PM, Thierry Foucu 
> wrote:
> >> > ---
> >> >  libavformat/riff.c | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/libavformat/riff.c b/libavformat/riff.c
> >> > index a9197e7..7de8936 100644
> >> > --- a/libavformat/riff.c
> >> > +++ b/libavformat/riff.c
> >> > @@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
> >> >  { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB,
> 0x71,
> >> 0x44, 0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
> >> >  { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D,
> 0xFB,
> >> 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
> >> >  { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB,
> 0xCF,
> >> 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
> >> > +{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00,
> >> 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
> >> >  { AV_CODEC_ID_NONE }
> >> >  };
> >> > --
> >>
> >> This is the generic PCM GUID, isn't it? It could be any PCM bitdepth,
> >> so the patch does not appear correct to me.
> >>
> >
> > Should i then look for the generic PCM GUID (to decide this is a PCM
> codec)
> > and base on the bits_per_coded_sample, selects the PCM codec?
> >
> >
>
> From what I can tell such files should already be handled by the
> generic WAVEFORMATEXTENSIBLE handler.
> Can you share a file which doesn't work as expected?
>
>
No pb. just uploaded to the ftp a file name
raw_video_pcm_s24le.avi




> - 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] Adds support parsing the QuickTime Metadata Keys.

[Tinglin Liu]

Thank you Derek for the reply.

Basically the metadata is stored in the structure like:

|--meta |hdlr |keys |ilst

1) Firstly, we check if the handler type in the metadata handler atom is
‘mdta’. If it is, we set found_hdlr_mdta in
​
MOVContext be 1.

2) The key and value are stored separately for each key-value pair. 'keys'
atom stores the key name table, while 'ilst' atom stores the values
corresponding to the indices in the key table. And since they are stored in
two different atoms, I have to store the name and count of the keys in the
MOVContext, and use them when parsing 'ilst'.

Cheers,
​Tinglin​


On Thu, Oct 22, 2015 at 11:43 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 10/20/2015 7:29 PM, Tinglin Liu wrote:
> > The Apple dev specification:
> >
> https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html
> > ---
> >  libavformat/isom.h |  3 +++
> >  libavformat/mov.c  | 77
> +-
> >  2 files changed, 74 insertions(+), 6 deletions(-)
>
> Is there a test file around we can add to FATE?
>
> > @@ -177,6 +177,9 @@ typedef struct MOVContext {
> >  int64_t duration; ///< duration of the longest track
> >  int found_moov;   ///< 'moov' atom has been found
> >  int found_mdat;   ///< 'mdat' atom has been found
> > +int found_hdlr_mdta;  ///< 'hdlr' atom with type 'mdta' has been
> found
> > +char **meta_keys;
> > +unsigned meta_keys_count;
>
> How exactly is it intended for these gets to be accessed?
> ​​
> MOVContext is an internal
> structure only. Perhaps this should be exported via side-data?

> @@ -368,6 +369,11 @@ retry:
> >  av_log(c->fc, AV_LOG_ERROR, "Error parsing cover
> art.\n");
> >  }
> >  return ret;
> > +} else if (!key &&
> ​​
> c->found_hdlr_mdta && c->meta_keys) {
>
> Is it ever possible for c->meta_keys to not be allocated here? (Patch
> doesn't
> provide me enough context liens to determine that.)
>

​
​
c->found_hdlr_mdta checks the handler type of 'hdlr' is good, but
c->meta_keys is read from 'keys'. I believe c->meta_keys is necessary in
case the 'keys' atom is missing.




>
> > +uint32_t index = AV_RB32();
> > +if (index < c->meta_keys_count && c->meta_keys[index]) {
>
> If we have already allocated c->meta_keys_count * sizeof(*c->meta_keys)
> entries,
> the latter check is redundant.
>
​
Updated in the patch, thanks.​


>
> > +key = c->meta_keys[index];
> > +}
>
> Perhaps some sort of warning if the index is out-of-range?
>

​Updated in the patch, thanks.
​


>
> > +// Allocates enough space if data_type is a float32 number,
> otherwise
> >  // worst-case requirement for output string in case of utf8 coded
> input
> > -str_size_alloc = (raw ? str_size : str_size * 2) + 1;
> > +num = (data_type == 23) ? 1 : 0;
>
> Redundant ternary operator.
>

​
​
​​
Updated in the patch, thanks.


> > +str_size_alloc = (num ? 512 : (raw ? str_size : str_size * 2)) + 1;
> >  str = av_mallocz(str_size_alloc);
> >  if (!str)
> >  return AVERROR(ENOMEM);
> > @@ -405,6 +413,10 @@ retry:
> >  else {
> >  if (!raw && (data_type == 3 || (data_type == 0 && (langcode <
> 0x400 || langcode == 0x7fff { // MAC Encoded
> >  mov_read_mac_string(c, pb, str_size, str, str_size_alloc);
> > +} else if (data_type == 23 && str_size >= 4) {  // BE float32
>
> Where does 4 come from?
>

​Because data_type 23 indicates it's a float32 data stored, so we need make
sure the size of data >= (32/8 = 4). ​



>
> > +union av_intfloat32 val;
> > +val.i = avio_rb32(pb);
>
> I'm not entirely sure of the portability of this code. Would this not fail
> on
> any system without IEEE floats?
>
> > +snprintf(str, str_size_alloc, "%f", val.f);
>
> Return value should be checked when using %f, in case of insane input.
>

​
​
Updated in the patch, thanks.
​


>
> > @@ -614,6 +621,15 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> >  av_log(c->fc, AV_LOG_TRACE, "ctype= %.4s (0x%08x)\n",
> (char*), ctype);
> >  av_log(c->fc, AV_LOG_TRACE, "stype= %.4s\n", (char*));
> >
> > +if (c->fc->nb_streams < 1) {  // meta before first trak
> > +if (type == MKTAG('m','d','t','a')) {
> > +c->found_hdlr_mdta = 1;
> > +}
> > +return 0;
> > +}
> > +
> > +st = c->fc->streams[c->fc->nb_streams-1];
>
> Any reason this was moved lower?
>

​Because we need check the type of the hdlr before first trak.​



>
> > +static int mov_read_keys(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> > +{
> > +uint32_t count;
> > +uint32_t i;
> > +
> > +if (atom.size < 8)
> > +return 0;
> > +
> > +avio_skip(pb, 4);
> > +count = avio_rb32(pb);
> > +if (count > UINT_MAX / 

Re: [FFmpeg-devel] [PATCH] vf_ssim: print per-channel dB values.

[Paul B Mahol]

On 10/22/15, Ronald S. Bultje  wrote:
> ---
>  libavfilter/vf_ssim.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
> index 5cd9361..e7a64f7 100644
> --- a/libavfilter/vf_ssim.c
> +++ b/libavfilter/vf_ssim.c
> @@ -346,7 +346,8 @@ static av_cold void uninit(AVFilterContext *ctx)
>  buf[0] = 0;
>  for (i = 0; i < s->nb_components; i++) {
>  int c = s->is_rgb ? s->rgba_map[i] : i;
> -av_strlcatf(buf, sizeof(buf), " %c:%f", s->comps[i], s->ssim[c]
> / s->nb_frames);
> +av_strlcatf(buf, sizeof(buf), " %c:%f (%f)", s->comps[i],
> s->ssim[c] / s->nb_frames,
> +ssim_db(s->ssim[c], s->nb_frames));
>  }
>  av_log(ctx, AV_LOG_INFO, "SSIM%s All:%f (%f)\n", buf,
> s->ssim_total / s->nb_frames, ssim_db(s->ssim_total,
> s->nb_frames));
> --
> 2.1.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Update docs, otherwise ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_psnr: remove %0.2f format specifiers for stream summary line.

[Paul B Mahol]

On 10/22/15, Ronald S. Bultje  wrote:
> This makes output equally precise as vf_ssim.
> ---
>  libavfilter/vf_psnr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
> index a01b2c1..4f060c9 100644
> --- a/libavfilter/vf_psnr.c
> +++ b/libavfilter/vf_psnr.c
> @@ -322,10 +322,10 @@ static av_cold void uninit(AVFilterContext *ctx)
>  buf[0] = 0;
>  for (j = 0; j < s->nb_components; j++) {
>  int c = s->is_rgb ? s->rgba_map[j] : j;
> -av_strlcatf(buf, sizeof(buf), " %c:%0.2f", s->comps[j],
> +av_strlcatf(buf, sizeof(buf), " %c:%f", s->comps[j],
>  get_psnr(s->mse_comp[c], s->nb_frames, s->max[c]));
>  }
> -av_log(ctx, AV_LOG_INFO, "PSNR%s average:%0.2f min:%0.2f
> max:%0.2f\n",
> +av_log(ctx, AV_LOG_INFO, "PSNR%s average:%f min:%f max:%f\n",
> buf,
> get_psnr(s->mse, s->nb_frames, s->average_max),
> get_psnr(s->max_mse, 1, s->average_max),
> --
> 2.1.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

[FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Tinglin Liu]

The Apple dev specification:
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html

Basically the structure is like:
|--meta
|hdlr
|keys
|ilst

1) The handler type in the metadata handler atom is ‘mdta’.
2) The key and value are stored separately for each key-value pair. 'keys' atom 
stores the key table, while 'ilst' atom stores the values corresponding to the 
indices in the key table.
---
 libavformat/isom.h |  3 ++
 libavformat/mov.c  | 93 ++
 2 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 6e921c0..dba30a2 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -177,6 +177,9 @@ typedef struct MOVContext {
 int64_t duration; ///< duration of the longest track
 int found_moov;   ///< 'moov' atom has been found
 int found_mdat;   ///< 'mdat' atom has been found
+int found_hdlr_mdta;  ///< 'hdlr' atom with type 'mdta' has been found
+char **meta_keys;
+unsigned meta_keys_count;
 DVDemuxContext *dv_demux;
 AVFormatContext *dv_fctx;
 int isom; ///< 1 if file is ISO Media (mp4/3gp)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7c90d40..c7905a1 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -265,6 +265,7 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 uint32_t data_type = 0, str_size, str_size_alloc;
 int (*parse)(MOVContext*, AVIOContext*, unsigned, const char*) = NULL;
 int raw = 0;
+int num = 0;
 
 switch (atom.type) {
 case MKTAG( '@','P','R','M'): key = "premiere_version"; raw = 1; break;
@@ -368,6 +369,15 @@ retry:
 av_log(c->fc, AV_LOG_ERROR, "Error parsing cover art.\n");
 }
 return ret;
+} else if (!key && c->found_hdlr_mdta && c->meta_keys) {
+uint32_t index = AV_RB32();
+if (index < c->meta_keys_count) {
+key = c->meta_keys[index];
+} else {
+av_log(c->fc, AV_LOG_WARNING,
+   "The index of 'data' is out of range: %d >= %d.\n",
+   index, c->meta_keys_count);
+}
 }
 } else return 0;
 } else if (atom.size > 4 && key && !c->itunes_metadata && !raw) {
@@ -394,8 +404,10 @@ retry:
 if (atom.size < 0 || str_size >= INT_MAX/2)
 return AVERROR_INVALIDDATA;
 
+// Allocates enough space if data_type is a float32 number, otherwise
 // worst-case requirement for output string in case of utf8 coded input
-str_size_alloc = (raw ? str_size : str_size * 2) + 1;
+num = (data_type == 23);
+str_size_alloc = (num ? 512 : (raw ? str_size : str_size * 2)) + 1;
 str = av_mallocz(str_size_alloc);
 if (!str)
 return AVERROR(ENOMEM);
@@ -405,6 +417,14 @@ retry:
 else {
 if (!raw && (data_type == 3 || (data_type == 0 && (langcode < 0x400 || 
langcode == 0x7fff { // MAC Encoded
 mov_read_mac_string(c, pb, str_size, str, str_size_alloc);
+} else if (data_type == 23 && str_size >= 4) {  // BE float32
+union av_intfloat32 val;
+val.i = avio_rb32(pb);
+if (snprintf(str, str_size_alloc, "%f", val.f) >= str_size_alloc) {
+av_log(c->fc, AV_LOG_ERROR,
+   "Failed to store the float32 number (0x%x) in 
string.\n", val.i);
+return AVERROR_INVALIDDATA;
+}
 } else {
 int ret = ffio_read_size(pb, str, str_size);
 if (ret < 0) {
@@ -599,11 +619,6 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 char *title_str;
 int ret;
 
-if (c->fc->nb_streams < 1) // meta before first trak
-return 0;
-
-st = c->fc->streams[c->fc->nb_streams-1];
-
 avio_r8(pb); /* version */
 avio_rb24(pb); /* flags */
 
@@ -614,6 +629,15 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 av_log(c->fc, AV_LOG_TRACE, "ctype= %.4s (0x%08x)\n", (char*), 
ctype);
 av_log(c->fc, AV_LOG_TRACE, "stype= %.4s\n", (char*));
 
+if (c->fc->nb_streams < 1) {  // meta before first trak
+if (type == MKTAG('m','d','t','a')) {
+c->found_hdlr_mdta = 1;
+}
+return 0;
+}
+
+st = c->fc->streams[c->fc->nb_streams-1];
+
 if (type == MKTAG('v','i','d','e'))
 st->codec->codec_type = AVMEDIA_TYPE_VIDEO;
 else if (type == MKTAG('s','o','u','n'))
@@ -3127,6 +3151,48 @@ static int mov_read_ilst(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return ret;
 }
 
+static int mov_read_keys(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+uint32_t count;
+uint32_t i;
+
+if (atom.size < 8)
+return 0;
+
+avio_skip(pb, 4);
+count = avio_rb32(pb);
+if (count > 

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Fri, Oct 16, 2015 at 7:53 AM, Ganesh Ajjanagadde  wrote:
> On Fri, Oct 16, 2015 at 7:30 AM, Michael Niedermayer
>  wrote:
>> On Thu, Oct 15, 2015 at 06:38:10AM -0400, Ganesh Ajjanagadde wrote:
>>> On Wed, Oct 14, 2015 at 6:53 AM, Hendrik Leppkes  
>>> wrote:
>>> > On Wed, Oct 14, 2015 at 12:49 PM, Carl Eugen Hoyos  
>>> > wrote:
>>> >> Ganesh Ajjanagadde  mit.edu> writes:
>>> >>
>>> >>> What? My numbers actually show that the new code may be faster -
>>> >>
>>> >> No, you are misunderstanding the numbers you posted.
>>> >> (Or I misunderstand them but nobody said so yet.)
>>> >>
>>> >> Highest runs are most relevant, skips have to be
>>> >> avoided (afaik).
>>> >>
>>> >> [...]
>>> >>
>>> >>> If you continue to post such stuff that has no basis, I might actually
>>> >>> get tempted into finding out for which floating point values the new
>>> >>> code is significantly faster, craft a relevant audio file, and post it
>>> >>> showing a huge performance difference - my random numbers benchmark
>>> >>> shows there must exist such values.
>>> >>
>>> >> Please do so!
>>> >>
>>> >>> > The more important question is if you can see the same
>>> >>> > changes in the disassembly of af_astats.o as what
>>> >>> > ubitux posted here for a short test function?
>>> >>>
>>> >>> I do. He uses clang/gcc, so do I.
>>> >>
>>> >> Sorry, my understanding fails here (I am not a native speaker):
>>> >> You did look at the disassembly of af_astats.o and there is
>>> >> inlined code instead of a function call?
>>> >>
>>> >>> The reason (irrelevant) is that both
>>> >>> of us run Arch.
>>> >>>
>>> >>> What is "more relevant" is if _you_ can see the changes
>>> >>> on some non Linux platform.
>>> >>
>>> >> If you could show that it is faster on any platform
>>> >> I would already be happy!
>>> >>
>>> >
>>> > A more important check would be that its not significantly slower on
>>> > any other platform. Just because one compiler/glibc combination
>>> > manages to produce an efficient inlined function doesn't necessarily
>>> > mean that some other compiler or libc couldn't produce a full function
>>> > call with all the overhead that comes with it, becoming significantly
>>> > slower.
>>>
>>> As I point out, all a libc implementer needs to do to be on par with
>>> the macro is to add the inline keyword. This was added in c99. If said
>>> libc does not, then it is fundamentally broken from a performance
>>> perspective. A beginning programmer can do that in a couple of
>>> minutes. Fix upstream and complain to them if it does not inline.
>>
>> I dont know how the latest compilers handle "inline" but a few years
>> ago gcc was rather dumb about inlining, and i think its not easy for
>> a compiler to be actually not "dumb"
>>
>> A compiler cannot inline everything that has the inline keyword,
>> it would lead (for some source code) to an explosion on size and
>> compile time.
>> and a good compiler will want to inline some functions even if they
>> do not have the inline keyword
>> Also its not easy to know for a compiler what to
>> inline and what not, there could be 10 functions a1(),a2(), a3(), ...
>> each calling the previous 10 times ...
>> the way gcc handled this (in the past and AFAIK at least) is to have
>> various complicated thresholds that limit the amount of inlining.
>> The big annoyance with this (years ago at least) was that if you
>> forced a function to be inlined by "force" gcc would then stop
>> inlining something else and you ended up either forcing every single
>> function you needed inlined or would have had to tune the thresholds
>>
>> it would be interresting to check if replacing FFABS by fabs causes
>> any big changes to inlining behavior (maybe that can be done by
>> comparing the list of symbols in the object files as fully inlined
>> functions s´wouldnt show up but maybe there are other ways)
>>
>> anyway iam not against using fabs() for float/double FFABS()
>> i just think some assumtations in this thread are possibly too
>> optimistic, but its quite possible these replacements are all fine
>> and the changes in inlining if any have no performance impact
>
> I myself am not "optimistic" in the sense that I think most of the
> time this will have zero change. All I am saying is that in cases
> where there is a difference, it will likely be in favor of fabs, etc
> and not the macro due to reasons I mentioned in the long commit
> message I posted.
>
>>
>> also if a *abs is implemented by using a branch (as in if its positive
>> jump over a negate instruction) then branch prediction can play a
>> sigificant role in performance, that is random values would be alot
>> slower than the same values ordered
>
> Maybe this is why I get such a large difference between fabs and FFABS
> in favor of fabs - I just keep random numbers with no ordering. If
> true, this is definitely in fabs's favor.
>
>> a good implementation should not use a 

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Carl Eugen Hoyos]

Ganesh Ajjanagadde  mit.edu> writes:

> To put an end to a long and tortuous thread, and 
> due to the lack of relevant outstanding objections, 
> pushed.

To sum it up:
Several developers have explained to you that the 
numbers you posted show that FFmpeg is now either 
slower or equally fast, you have pushed with a 
commit message that claims that your patch makes 
FFmpeg faster.
How do you call such a claim without any base?
Carl Eugen

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

[FFmpeg-devel] [PATCH 1/1] avcodec/png: read and write stereo3d frame side data information

[Kirill Gavrilov]

Use optional sTER chunk defining side-by-side stereo pair
within "Extensions to the PNG 1.2 Specification", version 1.3.0.

Specification:
http://www.libpng.org/pub/png/spec/register/pngext-1.4.0-pdg.html

Note that patch does not add any image resolution checks defined by spec.

Regards,
Kirill


0001-avcodec-png-read-and-write-stereo3d-frame-side-data-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vf_psnr/ssim: don't crash if stats_file is NULL.

[Ronald S. Bultje]

---
 libavfilter/vf_psnr.c | 24 +---
 libavfilter/vf_ssim.c | 24 +---
 2 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index ca41939..36bbab2 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -193,17 +193,19 @@ static av_cold int init(AVFilterContext *ctx)
 s->min_mse = +INFINITY;
 s->max_mse = -INFINITY;
 
-if (!strcmp(s->stats_file_str, "-")) {
-s->stats_file = stdout;
-} else if (s->stats_file_str) {
-s->stats_file = fopen(s->stats_file_str, "w");
-if (!s->stats_file) {
-int err = AVERROR(errno);
-char buf[128];
-av_strerror(err, buf, sizeof(buf));
-av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s: %s\n",
-   s->stats_file_str, buf);
-return err;
+if (s->stats_file_str) {
+if (!strcmp(s->stats_file_str, "-")) {
+s->stats_file = stdout;
+} else {
+s->stats_file = fopen(s->stats_file_str, "w");
+if (!s->stats_file) {
+int err = AVERROR(errno);
+char buf[128];
+av_strerror(err, buf, sizeof(buf));
+av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s: %s\n",
+   s->stats_file_str, buf);
+return err;
+}
 }
 }
 
diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
index 4dc96a7..ce1e3db 100644
--- a/libavfilter/vf_ssim.c
+++ b/libavfilter/vf_ssim.c
@@ -223,17 +223,19 @@ static av_cold int init(AVFilterContext *ctx)
 {
 SSIMContext *s = ctx->priv;
 
-if (!strcmp(s->stats_file_str, "-")) {
-s->stats_file = stdout;
-} else if (s->stats_file_str) {
-s->stats_file = fopen(s->stats_file_str, "w");
-if (!s->stats_file) {
-int err = AVERROR(errno);
-char buf[128];
-av_strerror(err, buf, sizeof(buf));
-av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s: %s\n",
-   s->stats_file_str, buf);
-return err;
+if (s->stats_file_str) {
+if (!strcmp(s->stats_file_str, "-")) {
+s->stats_file = stdout;
+} else {
+s->stats_file = fopen(s->stats_file_str, "w");
+if (!s->stats_file) {
+int err = AVERROR(errno);
+char buf[128];
+av_strerror(err, buf, sizeof(buf));
+av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s: %s\n",
+   s->stats_file_str, buf);
+return err;
+}
 }
 }
 
-- 
2.1.2

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

Re: [FFmpeg-devel] [PATCH] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Hendrik Leppkes]

On Thu, Oct 22, 2015 at 11:15 PM, Thierry Foucu  wrote:
> On Thu, Oct 22, 2015 at 2:08 PM, Hendrik Leppkes 
> wrote:
>
>> On Thu, Oct 22, 2015 at 9:19 PM, Thierry Foucu  wrote:
>> > ---
>> >  libavformat/riff.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/libavformat/riff.c b/libavformat/riff.c
>> > index a9197e7..7de8936 100644
>> > --- a/libavformat/riff.c
>> > +++ b/libavformat/riff.c
>> > @@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
>> >  { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB, 0x71,
>> 0x44, 0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
>> >  { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB,
>> 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
>> >  { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF,
>> 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
>> > +{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
>> >  { AV_CODEC_ID_NONE }
>> >  };
>> > --
>>
>> This is the generic PCM GUID, isn't it? It could be any PCM bitdepth,
>> so the patch does not appear correct to me.
>>
>
> Should i then look for the generic PCM GUID (to decide this is a PCM codec)
> and base on the bits_per_coded_sample, selects the PCM codec?
>
>

From what I can tell such files should already be handled by the
generic WAVEFORMATEXTENSIBLE handler.
Can you share a file which doesn't work as expected?

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

[FFmpeg-devel] [PATCH] vf_psnr: don't crash if stats_file is NULL.

[Ronald S. Bultje]

---
 libavfilter/vf_psnr.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index ca41939..36bbab2 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -193,17 +193,19 @@ static av_cold int init(AVFilterContext *ctx)
 s->min_mse = +INFINITY;
 s->max_mse = -INFINITY;
 
-if (!strcmp(s->stats_file_str, "-")) {
-s->stats_file = stdout;
-} else if (s->stats_file_str) {
-s->stats_file = fopen(s->stats_file_str, "w");
-if (!s->stats_file) {
-int err = AVERROR(errno);
-char buf[128];
-av_strerror(err, buf, sizeof(buf));
-av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s: %s\n",
-   s->stats_file_str, buf);
-return err;
+if (s->stats_file_str) {
+if (!strcmp(s->stats_file_str, "-")) {
+s->stats_file = stdout;
+} else {
+s->stats_file = fopen(s->stats_file_str, "w");
+if (!s->stats_file) {
+int err = AVERROR(errno);
+char buf[128];
+av_strerror(err, buf, sizeof(buf));
+av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s: %s\n",
+   s->stats_file_str, buf);
+return err;
+}
 }
 }
 
-- 
2.1.2

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

[FFmpeg-devel] [PATCH] avcodec/hap: set bits_per_coded_sample

[Tom Butterworth]

fixes issue where alpha is ignored in some players
---
 libavcodec/hapenc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/hapenc.c b/libavcodec/hapenc.c
index 7daadce..cb5dcfa 100644
--- a/libavcodec/hapenc.c
+++ b/libavcodec/hapenc.c
@@ -242,16 +242,19 @@ static av_cold int hap_init(AVCodecContext *avctx)
 case HAP_FMT_RGBDXT1:
 ratio = 8;
 avctx->codec_tag = MKTAG('H', 'a', 'p', '1');
+avctx->bits_per_coded_sample = 24;
 ctx->tex_fun = ctx->dxtc.dxt1_block;
 break;
 case HAP_FMT_RGBADXT5:
 ratio = 4;
 avctx->codec_tag = MKTAG('H', 'a', 'p', '5');
+avctx->bits_per_coded_sample = 32;
 ctx->tex_fun = ctx->dxtc.dxt5_block;
 break;
 case HAP_FMT_YCOCGDXT5:
 ratio = 4;
 avctx->codec_tag = MKTAG('H', 'a', 'p', 'Y');
+avctx->bits_per_coded_sample = 24;
 ctx->tex_fun = ctx->dxtc.dxt5ys_block;
 break;
 default:
-- 
2.4.9 (Apple Git-60)

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

Re: [FFmpeg-devel] [PATCH] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Hendrik Leppkes]

On Thu, Oct 22, 2015 at 9:19 PM, Thierry Foucu  wrote:
> ---
>  libavformat/riff.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/riff.c b/libavformat/riff.c
> index a9197e7..7de8936 100644
> --- a/libavformat/riff.c
> +++ b/libavformat/riff.c
> @@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
>  { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB, 0x71, 
> 0x44, 0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
>  { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB, 
> 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
>  { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF, 
> 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
> +{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
> 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
>  { AV_CODEC_ID_NONE }
>  };
> --

This is the generic PCM GUID, isn't it? It could be any PCM bitdepth,
so the patch does not appear correct to me.

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

Re: [FFmpeg-devel] [PATCH] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Thierry Foucu]

On Thu, Oct 22, 2015 at 2:29 PM, Hendrik Leppkes 
wrote:

> On Thu, Oct 22, 2015 at 11:15 PM, Thierry Foucu  wrote:
> > On Thu, Oct 22, 2015 at 2:08 PM, Hendrik Leppkes 
> > wrote:
> >
> >> On Thu, Oct 22, 2015 at 9:19 PM, Thierry Foucu 
> wrote:
> >> > ---
> >> >  libavformat/riff.c | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/libavformat/riff.c b/libavformat/riff.c
> >> > index a9197e7..7de8936 100644
> >> > --- a/libavformat/riff.c
> >> > +++ b/libavformat/riff.c
> >> > @@ -487,5 +487,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
> >> >  { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB,
> 0x71,
> >> 0x44, 0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
> >> >  { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D,
> 0xFB,
> >> 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
> >> >  { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB,
> 0xCF,
> >> 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
> >> > +{ AV_CODEC_ID_PCM_S24LE,{ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00,
> >> 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA } },
> >> >  { AV_CODEC_ID_NONE }
> >> >  };
> >> > --
> >>
> >> This is the generic PCM GUID, isn't it? It could be any PCM bitdepth,
> >> so the patch does not appear correct to me.
> >>
> >
> > Should i then look for the generic PCM GUID (to decide this is a PCM
> codec)
> > and base on the bits_per_coded_sample, selects the PCM codec?
> >
> >
>
> From what I can tell such files should already be handled by the
> generic WAVEFORMATEXTENSIBLE handler.
>

here is another version to fix the file.


diff --git a/libavformat/riff.h b/libavformat/riff.h
index 3b57bb45..cfc5ce8 100644
--- a/libavformat/riff.h
+++ b/libavformat/riff.h
@@ -109,6 +109,8 @@ extern const AVCodecGuid ff_codec_wav_guids[];
 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA, 0x00, 0x38, 0x9B, 0x71
 #define FF_AMBISONIC_BASE_GUID \
 0x21, 0x07, 0xD3, 0x11, 0x86, 0x44, 0xC8, 0xC1, 0xCA, 0x00, 0x00, 0x00
+#define PCM_BASE_GUID \
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xAA

 static av_always_inline int ff_guidcmp(const void *g1, const void *g2)
 {
diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 26779e1..ced19fb 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -71,7 +71,9 @@ static void parse_waveformatex(AVIOContext *pb,
AVCodecContext *c)
 if (!memcmp(subformat + 4,
 (const uint8_t[]){ FF_AMBISONIC_BASE_GUID }, 12) ||
 !memcmp(subformat + 4,
-(const uint8_t[]){ FF_MEDIASUBTYPE_BASE_GUID }, 12)) {
+(const uint8_t[]){ FF_MEDIASUBTYPE_BASE_GUID }, 12) ||
+!memcmp(subformat + 4,
+(const uint8_t[]){ PCM_BASE_GUID }, 12)) {
 c->codec_tag = AV_RL32(subformat);
 c->codec_id  = ff_wav_codec_get_id(c->codec_tag,
c->bits_per_coded_sample);




> Can you share a file which doesn't work as expected?
>
> - 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] web/src/legal: minor typo and grammer fixes

[Kieran Kunhya]

Yeah...sometimes it's best to just let the past lie there. I'd rather
see it gone completely to be honest .

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

Re: [FFmpeg-devel] [PATCH] web/src/legal: minor typo and grammer fixes

[Lou Logan]

On Thu, 22 Oct 2015 18:46:04 -0400, Ganesh Ajjanagadde wrote:

> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  src/legal | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/legal b/src/legal
> index c235d31..7be0291 100644
> --- a/src/legal
> +++ b/src/legal
> @@ -162,9 +162,9 @@ vigilant and diligent about collecting for MPEG-related 
> technologies.
>  
>  May 30, 2011
>  
> -Today FFmpeg has received the first legal threat 
> in its existence. Its
> +Today FFmpeg has received the first legal threat 
> in its existence. It's
>  from a previous root admin of FFmpeg, who now is root admin of the
>  Libav fork of FFmpeg. He claims copyright on the zigzag part of our
> -logo. It has to be noted that he said 4 years ago  href="http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
>  to whoever came up with the zigzag idea
> +logo. It has to be noted that he said 4 years ago  href="http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
>  to whoever came up with the zigzag idea.
>  Update May 31/June 1: we have replaced the logo with a better 
> looking one drawn by
>  Hervé Flores.

Fine of course, but honestly, who cares?

I'd prefer not to see such superfluous, minor patches increasing mailing
list and git log noise.

If you want to pursue these that is fine with me, but I don't think
anyone else should need to spend time reviewing and/or pushing them. In
other words, if you want to make such minor changes, please just do so
and push, but if you don't feel comfortable doing that then maybe make
a bigger patch consolidating a number of such changes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] legal: remove Legal Threats section

[wm4]

On Fri, 23 Oct 2015 00:22:45 +0100
Kieran Kunhya  wrote:

> On 23 October 2015 at 00:19, Lou Logan  wrote:
> > Signed-off-by: Lou Logan 
> > ---
> >
> > I'm tired of looking at it, being reminded of such things, and it has
> > served its purpose long ago.
> >
> > ---
> >  src/legal | 11 ---
> >  1 file changed, 11 deletions(-)
> >
> > diff --git a/src/legal b/src/legal
> > index c235d31..1037a69 100644
> > --- a/src/legal
> > +++ b/src/legal
> > @@ -157,14 +157,3 @@ you start trying to make money from patented 
> > technologies, the owners of
> >  the patents will come after their licensing fees. Notably, MPEG LA is
> >  vigilant and diligent about collecting for MPEG-related technologies.
> >  
> > -
> > -Legal threats
> > -
> > -May 30, 2011
> > -
> > -Today FFmpeg has received the first legal threat 
> > in its existence. Its
> > -from a previous root admin of FFmpeg, who now is root admin of the
> > -Libav fork of FFmpeg. He claims copyright on the zigzag part of our
> > -logo. It has to be noted that he said 4 years ago  > href="http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
> >  to whoever came up with the zigzag idea
> > -Update May 31/June 1: we have replaced the logo with a better 
> > looking one drawn by
> > -Hervé Flores.  
> 
> +1000

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

Re: [FFmpeg-devel] [PATCH] legal: remove Legal Threats section

[Ronald S. Bultje]

Hi,

On Thu, Oct 22, 2015 at 7:19 PM, Lou Logan  wrote:

> Signed-off-by: Lou Logan 
> ---
>
> I'm tired of looking at it, being reminded of such things, and it has
> served its purpose long ago.
>
> ---
>  src/legal | 11 ---
>  1 file changed, 11 deletions(-)
>
> diff --git a/src/legal b/src/legal
> index c235d31..1037a69 100644
> --- a/src/legal
> +++ b/src/legal
> @@ -157,14 +157,3 @@ you start trying to make money from patented
> technologies, the owners of
>  the patents will come after their licensing fees. Notably, MPEG LA is
>  vigilant and diligent about collecting for MPEG-related technologies.
>  
> -
> -Legal threats
> -
> -May 30, 2011
> -
> -Today FFmpeg has received the first legal
> threat in its existence. Its
> -from a previous root admin of FFmpeg, who now is root admin of the
> -Libav fork of FFmpeg. He claims copyright on the zigzag part of our
> -logo. It has to be noted that he said 4 years ago http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
> to whoever came up with the zigzag idea
> -Update May 31/June 1: we have replaced the logo with a better
> looking one drawn by
> -Hervé Flores.
> --
> 2.6.1


I agree, lgtm.

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

[FFmpeg-devel] [PATCH] web/src/legal: minor typo and grammer fixes

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 src/legal | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/legal b/src/legal
index c235d31..7be0291 100644
--- a/src/legal
+++ b/src/legal
@@ -162,9 +162,9 @@ vigilant and diligent about collecting for MPEG-related 
technologies.
 
 May 30, 2011
 
-Today FFmpeg has received the first legal threat in 
its existence. Its
+Today FFmpeg has received the first legal threat in 
its existence. It's
 from a previous root admin of FFmpeg, who now is root admin of the
 Libav fork of FFmpeg. He claims copyright on the zigzag part of our
-logo. It has to be noted that he said 4 years ago http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
 to whoever came up with the zigzag idea
+logo. It has to be noted that he said 4 years ago http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
 to whoever came up with the zigzag idea.
 Update May 31/June 1: we have replaced the logo with a better 
looking one drawn by
 Hervé Flores.
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] web/src/legal: minor typo and grammer fixes

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 7:11 PM, Lou Logan  wrote:
> On Thu, 22 Oct 2015 18:46:04 -0400, Ganesh Ajjanagadde wrote:
>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  src/legal | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/legal b/src/legal
>> index c235d31..7be0291 100644
>> --- a/src/legal
>> +++ b/src/legal
>> @@ -162,9 +162,9 @@ vigilant and diligent about collecting for MPEG-related 
>> technologies.
>>
>>  May 30, 2011
>>  
>> -Today FFmpeg has received the first legal threat 
>> in its existence. Its
>> +Today FFmpeg has received the first legal threat 
>> in its existence. It's
>>  from a previous root admin of FFmpeg, who now is root admin of the
>>  Libav fork of FFmpeg. He claims copyright on the zigzag part of our
>> -logo. It has to be noted that he said 4 years ago > href="http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
>>  to whoever came up with the zigzag idea
>> +logo. It has to be noted that he said 4 years ago > href="http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
>>  to whoever came up with the zigzag idea.
>>  Update May 31/June 1: we have replaced the logo with a better 
>> looking one drawn by
>>  Hervé Flores.
>
> Fine of course, but honestly, who cares?
>
> I'd prefer not to see such superfluous, minor patches increasing mailing
> list and git log noise.
>
> If you want to pursue these that is fine with me, but I don't think
> anyone else should need to spend time reviewing and/or pushing them. In
> other words, if you want to make such minor changes, please just do so
> and push, but if you don't feel comfortable doing that then maybe make
> a bigger patch consolidating a number of such changes.

Agreed, will send a bigger patch sometime - there are some others I caught.

> ___
> 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] web/src/legal: minor typo and grammer fixes

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 7:00 PM, Kieran Kunhya  wrote:
> Yeah...sometimes it's best to just let the past lie there. I'd rather
> see it gone completely to be honest .

I am in no position to judge this. Feel free to apply, remove the
thing, whatever - just wanted to point out the minor typos if someone
wants to fix them.

>
> Kieran
> ___
> 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] legal: remove Legal Threats section

[Lou Logan]

On Thu, 22 Oct 2015 15:19:02 -0800, Lou Logan wrote:

> Signed-off-by: Lou Logan 
> ---
>  src/legal | 11 ---
>  1 file changed, 11 deletions(-)

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

[FFmpeg-devel] [PATCH] avcodec/huffman: replace qsort with AV_QSORT

[Ganesh Ajjanagadde]

ff_huff_build_tree uses qsort underneath. AV_QSORT is substantially
faster due to the inlining of the comparison callback. Furthermore, this
code is reasonably performance critical, since in e.g the fraps codec,
ff_huff_build_tree is called on every frame. This routine is also called
in vp6 on every frame in some circumstances.

Sample benchmark (x86-64, Haswell, GNU/Linux), fraps-v2 from FATE:
new:
280110 decicycles in qsort,   1 runs,  0 skips
268260 decicycles in qsort,   2 runs,  0 skips

old:
1469910 decicycles in qsort,   1 runs,  0 skips
 952950 decicycles in qsort,   2 runs,  0 skips

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/huffman.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/huffman.c b/libavcodec/huffman.c
index c771bcf..d7403b8 100644
--- a/libavcodec/huffman.c
+++ b/libavcodec/huffman.c
@@ -26,6 +26,7 @@
 
 #include 
 
+#include "libavutil/qsort.h"
 #include "avcodec.h"
 #include "get_bits.h"
 #include "huffman.h"
@@ -170,7 +171,7 @@ int ff_huff_build_tree(AVCodecContext *avctx, VLC *vlc, int 
nb_codes, int nb_bit
"Tree construction is not possible\n");
 return -1;
 }
-qsort(nodes, nb_codes, sizeof(Node), cmp);
+AV_QSORT(nodes, nb_codes, Node, cmp);
 cur_node = nb_codes;
 nodes[nb_codes*2-1].count = 0;
 for (i = 0; i < nb_codes * 2 - 1; i += 2) {
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Derek Buitenhuis]

On 10/22/2015 11:04 PM, Tinglin Liu wrote:
> +} else if (data_type == 23 && str_size >= 4) {  // BE float32
> +union av_intfloat32 val;
> +val.i = avio_rb32(pb);

I found we have a function to to this: av_int2float().

> +if (snprintf(str, str_size_alloc, "%f", val.f) >= 
> str_size_alloc) {

snprintf can never return a value greater than the length passed to it, so just 
== is fine.

Although, thinking about it, I was incorrect in thinking it could overflow the 
512+1 length
buffer, since the largest float with precision of 6 (the default in C) + radix 
is smaller
than that by a lot. My bad.

Nothing here warrants resending, IMO, and I will amend and push tomorrow, to 
allow time
for others to review or comment in the meantime.

- Derek

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

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[wm4]

On Fri, 23 Oct 2015 00:10:20 +0100
Derek Buitenhuis  wrote:

> On 10/22/2015 11:04 PM, Tinglin Liu wrote:
> > +} else if (data_type == 23 && str_size >= 4) {  // BE float32
> > +union av_intfloat32 val;
> > +val.i = avio_rb32(pb);  
> 
> I found we have a function to to this: av_int2float().
> 
> > +if (snprintf(str, str_size_alloc, "%f", val.f) >= 
> > str_size_alloc) {  
> 
> snprintf can never return a value greater than the length passed to it, so 
> just == is fine.

Wrong, snprintf() always returns the number of characters the string
would have been, even if the buffer size is smaller.

Also, str_size_alloc is unsigned, so in theory this catches cases when
snprintf fails (negative return value) too. But probably doesn't matter
here.

Also, shouldn't this use some av_ wrapper? What about locale issues?
Some locales won't print a "." but a ",".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 02/11] avdevice/pulse_audio_common: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Sat, Oct 17, 2015 at 12:45 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Oct 17, 2015 at 12:36 PM, Michael Niedermayer
>  wrote:
>> On Thu, Oct 15, 2015 at 10:22:16PM -0400, Ganesh Ajjanagadde wrote:
>>> This does not trigger any warnings, but adds robustness.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavdevice/pulse_audio_common.h | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/libavdevice/pulse_audio_common.h 
>>> b/libavdevice/pulse_audio_common.h
>>> index 02534f7..902795e 100644
>>> --- a/libavdevice/pulse_audio_common.h
>>> +++ b/libavdevice/pulse_audio_common.h
>>> @@ -28,8 +28,10 @@
>>>
>>>  pa_sample_format_t ff_codec_id_to_pulse_format(enum AVCodecID codec_id);
>>>
>>> +av_warn_unused_result
>>>  int ff_pulse_audio_get_devices(AVDeviceInfoList *devices, const char 
>>> *server, int output);
>>>
>>> +av_warn_unused_result
>>>  int ff_pulse_audio_connect_context(pa_mainloop **pa_ml, pa_context 
>>> **pa_ctx,
>>> const char *server, const char 
>>> *description);
>>
>> iam not the maintainer of this but the changes look reasonable
>
> will wait for 48 hours, then push if no one responds.

pushed, thanks.

>
>>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Democracy is the form of government in which you can choose your dictator
>>
>> ___
>> 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] avcodec/huffman: replace qsort with AV_QSORT

[Timothy Gu]

On Thu, Oct 22, 2015 at 5:01 PM Ganesh Ajjanagadde 
wrote:

> Sample benchmark (x86-64, Haswell, GNU/Linux), fraps-v2 from FATE:
> new:
> 280110 decicycles in qsort,   1 runs,  0 skips
> 268260 decicycles in qsort,   2 runs,  0 skips
>
> old:
> 1469910 decicycles in qsort,   1 runs,  0 skips
>  952950 decicycles in qsort,   2 runs,  0 skips
>

Usually it takes more than 2 runs to make sure something is faster than the
other (try -stream_loop 1 on the input).

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

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Derek Buitenhuis]

On 10/22/2015 11:28 PM, Tinglin Liu wrote:
> 2) The key and value are stored separately for each key-value pair. 'keys'
> atom stores the key name table, while 'ilst' atom stores the values
> corresponding to the indices in the key table. And since they are stored in
> two different atoms, I have to store the name and count of the keys in the
> MOVContext, and use them when parsing 'ilst'.

Right. For some reason I thought it was begin exported. It's clear to me now.

>>> +union av_intfloat32 val;
>>> +val.i = avio_rb32(pb);
>>
>> I'm not entirely sure of the portability of this code. Would this not fail
>> on
>> any system without IEEE floats?

Still not sure about this, but I see such stuff used elsewhere in avformat,
via av_int2float, so I guess we probably don't care. Someone correct me if
I am mistaken.

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

[FFmpeg-devel] [PATCH] WIP: lavf/segment: provide a virtual AVIOContext representing all the segments

[Rodger Combs]

This allows the use of muxers like matroska, which attempt to seek even
when an AVIOContext doesn't set `seekable`, without concern for a rouge
seek leading the muxer to overwrite the wrong data in a later segment.
---
 doc/muxers.texi   |  17 
 libavformat/segment.c | 263 +-
 2 files changed, 215 insertions(+), 65 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 06483fa..f7b9ee3 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1145,6 +1145,23 @@ muxers/codecs. It is set to @code{0} by default.
 @item initial_offset @var{offset}
 Specify timestamp offset to apply to the output packet timestamps. The
 argument must be a time duration specification, and defaults to 0.
+
+@item individual_header_trailer @var{1|0}
+Write each segment as an individual distinct file in the underlying format.
+When this is set to @code{0}, the segments are treated as a single continuous
+stream. When set to @code{1} (the default), each individual segment receives
+a header and trailer, so they can be played independently.
+
+@item segment_header_filename @var{name}
+Write the global header to a separate file. Requires
+@var{individual_header_trailer} to be @code{0}. If not set, the global header
+will be written to the first file along with actual segment data.
+
+@item segment_seekback @var{1|0}
+Allow the muxer to seek back and overwrite data from previous segments. 
Requires
+@var{individual_header_trailer} to be @code{0}. If set to @code{0} (the 
default),
+the underlying muxer will be unable to seek back into previous segments, so 
they
+can be relied upon not to change once written.
 @end table
 
 @subsection Examples
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 36417f2..20fd8c9 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -49,8 +49,10 @@ typedef struct SegmentListEntry {
 int64_t start_pts;
 int64_t offset_pts;
 char *filename;
+char *full_filename;
 struct SegmentListEntry *next;
 int64_t last_duration;
+size_t start_offset;
 } SegmentListEntry;
 
 typedef enum {
@@ -119,7 +121,13 @@ typedef struct SegmentContext {
 
 SegmentListEntry cur_entry;
 SegmentListEntry *segment_list_entries;
+SegmentListEntry *segment_list_entries_all;
 SegmentListEntry *segment_list_entries_end;
+SegmentListEntry *segment_list_entry_writing;
+int seekback;  ///< allow seeking back to previous segments
+AVIOContext *cur_pb;   ///< current segment put-byte context
+size_t write_offset;
+size_t max_offset;
 } SegmentContext;
 
 static void print_csv_escaped_str(AVIOContext *ctx, const char *str)
@@ -138,6 +146,122 @@ static void print_csv_escaped_str(AVIOContext *ctx, const 
char *str)
 avio_w8(ctx, '"');
 }
 
+static int64_t virtual_seek(void *priv, int64_t target, int whence)
+{
+AVFormatContext *s = priv;
+SegmentContext *seg = s->priv_data;
+SegmentListEntry *it, *current = NULL;
+int64_t offset = target;
+int64_t ret;
+
+if (whence != SEEK_SET)
+return AVERROR(EINVAL);
+if (offset < 0)
+return AVERROR(EINVAL);
+
+if (offset >= seg->max_offset) {
+avio_closep(>cur_pb);
+seg->write_offset = offset;
+return offset;
+}
+
+if (seg->cur_entry.start_offset <= offset) {
+current = >cur_entry;
+} else {
+for (it = seg->segment_list_entries_all; it; it = it->next) {
+if (it->start_offset <= offset)
+current = it;
+else if (it->start_offset > offset)
+break;
+}
+}
+
+offset -= current->start_offset;
+
+if (current != seg->segment_list_entry_writing) {
+int is_seekback = (current != >cur_entry) && 
seg->segment_list_entries;
+char *new_filename;
+AVIOContext *new_ctx = NULL;
+AVDictionary *options = NULL;
+
+if (!seg->seekback && is_seekback)
+return AVERROR(EINVAL);
+
+new_filename = current->full_filename;
+
+if (new_filename) {
+if (is_seekback)
+av_dict_set_int(, "truncate", 0, 0);
+if ((ret = avio_open2(_ctx, new_filename, AVIO_FLAG_WRITE,
+  >interrupt_callback, )) < 0) {
+av_log(s, AV_LOG_ERROR, "Failed to seek into segment '%s'\n", 
new_filename);
+return ret;
+}
+}
+
+avio_close(seg->cur_pb);
+seg->cur_pb = new_ctx;
+seg->segment_list_entry_writing = current;
+}
+
+if (seg->cur_pb)
+if ((ret = avio_seek(seg->cur_pb, offset, SEEK_SET)) < 0)
+return ret;
+
+seg->write_offset = offset;
+
+return target;
+}
+
+static int virtual_write(void *priv, uint8_t *buf, int buf_size)
+{
+AVFormatContext *s = priv;
+SegmentContext *seg = s->priv_data;
+int ret = 0;
+int written = 0;
+
+while (written < buf_size) {
+   

Re: [FFmpeg-devel] [PATCH] legal: remove Legal Threats section

[Kieran Kunhya]

On 23 October 2015 at 00:19, Lou Logan  wrote:
> Signed-off-by: Lou Logan 
> ---
>
> I'm tired of looking at it, being reminded of such things, and it has
> served its purpose long ago.
>
> ---
>  src/legal | 11 ---
>  1 file changed, 11 deletions(-)
>
> diff --git a/src/legal b/src/legal
> index c235d31..1037a69 100644
> --- a/src/legal
> +++ b/src/legal
> @@ -157,14 +157,3 @@ you start trying to make money from patented 
> technologies, the owners of
>  the patents will come after their licensing fees. Notably, MPEG LA is
>  vigilant and diligent about collecting for MPEG-related technologies.
>  
> -
> -Legal threats
> -
> -May 30, 2011
> -
> -Today FFmpeg has received the first legal threat 
> in its existence. Its
> -from a previous root admin of FFmpeg, who now is root admin of the
> -Libav fork of FFmpeg. He claims copyright on the zigzag part of our
> -logo. It has to be noted that he said 4 years ago  href="http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
>  to whoever came up with the zigzag idea
> -Update May 31/June 1: we have replaced the logo with a better 
> looking one drawn by
> -Hervé Flores.

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

[FFmpeg-devel] [PATCH] legal: remove Legal Threats section

[Lou Logan]

Signed-off-by: Lou Logan 
---

I'm tired of looking at it, being reminded of such things, and it has
served its purpose long ago.

---
 src/legal | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/src/legal b/src/legal
index c235d31..1037a69 100644
--- a/src/legal
+++ b/src/legal
@@ -157,14 +157,3 @@ you start trying to make money from patented technologies, 
the owners of
 the patents will come after their licensing fees. Notably, MPEG LA is
 vigilant and diligent about collecting for MPEG-related technologies.
 
-
-Legal threats
-
-May 30, 2011
-
-Today FFmpeg has received the first legal threat in 
its existence. Its
-from a previous root admin of FFmpeg, who now is root admin of the
-Libav fork of FFmpeg. He claims copyright on the zigzag part of our
-logo. It has to be noted that he said 4 years ago http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44742;>Credit
 to whoever came up with the zigzag idea
-Update May 31/June 1: we have replaced the logo with a better 
looking one drawn by
-Hervé Flores.
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Derek Buitenhuis]

On 10/23/2015 12:19 AM, wm4 wrote:
> Wrong, snprintf() always returns the number of characters the string
> would have been, even if the buffer size is smaller.

That'll teach me to reply past midnight.

I am dumb at night.

> Also, shouldn't this use some av_ wrapper? What about locale issues?
> Some locales won't print a "." but a ",".

Oh right. C locales.

I don't know if we have a function for this specific problem or not,
but it would not surprise me if we do.

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Wang Bin]

VLC is using frame threading with hwaccel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] WIP: lavf/segment: provide a virtual AVIOContext representing all the segments

[Rodger Combs]

This allows the use of muxers like matroska, which attempt to seek even
when an AVIOContext doesn't set `seekable`, without concern for a rouge
seek leading the muxer to overwrite the wrong data in a later segment.
---
 doc/muxers.texi   |  17 
 libavformat/segment.c | 262 ++
 2 files changed, 215 insertions(+), 64 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 06483fa..f7b9ee3 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1145,6 +1145,23 @@ muxers/codecs. It is set to @code{0} by default.
 @item initial_offset @var{offset}
 Specify timestamp offset to apply to the output packet timestamps. The
 argument must be a time duration specification, and defaults to 0.
+
+@item individual_header_trailer @var{1|0}
+Write each segment as an individual distinct file in the underlying format.
+When this is set to @code{0}, the segments are treated as a single continuous
+stream. When set to @code{1} (the default), each individual segment receives
+a header and trailer, so they can be played independently.
+
+@item segment_header_filename @var{name}
+Write the global header to a separate file. Requires
+@var{individual_header_trailer} to be @code{0}. If not set, the global header
+will be written to the first file along with actual segment data.
+
+@item segment_seekback @var{1|0}
+Allow the muxer to seek back and overwrite data from previous segments. 
Requires
+@var{individual_header_trailer} to be @code{0}. If set to @code{0} (the 
default),
+the underlying muxer will be unable to seek back into previous segments, so 
they
+can be relied upon not to change once written.
 @end table
 
 @subsection Examples
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 36417f2..aeff0e6 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -49,8 +49,10 @@ typedef struct SegmentListEntry {
 int64_t start_pts;
 int64_t offset_pts;
 char *filename;
+char *full_filename;
 struct SegmentListEntry *next;
 int64_t last_duration;
+size_t start_offset;
 } SegmentListEntry;
 
 typedef enum {
@@ -119,7 +121,13 @@ typedef struct SegmentContext {
 
 SegmentListEntry cur_entry;
 SegmentListEntry *segment_list_entries;
+SegmentListEntry *segment_list_entries_all;
 SegmentListEntry *segment_list_entries_end;
+SegmentListEntry *segment_list_entry_writing;
+int seekback;  ///< allow seeking back to previous segments
+AVIOContext *cur_pb;   ///< current segment put-byte context
+size_t write_offset;
+size_t max_offset;
 } SegmentContext;
 
 static void print_csv_escaped_str(AVIOContext *ctx, const char *str)
@@ -138,6 +146,122 @@ static void print_csv_escaped_str(AVIOContext *ctx, const 
char *str)
 avio_w8(ctx, '"');
 }
 
+static int64_t virtual_seek(void *priv, int64_t target, int whence)
+{
+AVFormatContext *s = priv;
+SegmentContext *seg = s->priv_data;
+SegmentListEntry *it, *current = NULL;
+int64_t offset = target;
+int64_t ret;
+
+if (whence != SEEK_SET)
+return AVERROR(EINVAL);
+if (offset < 0)
+return AVERROR(EINVAL);
+
+if (offset >= seg->max_offset) {
+avio_closep(>cur_pb);
+seg->write_offset = offset;
+return offset;
+}
+
+if (seg->cur_entry.start_offset <= offset) {
+current = >cur_entry;
+} else {
+for (it = seg->segment_list_entries_all; it; it = it->next) {
+if (it->start_offset <= offset)
+current = it;
+else if (it->start_offset > offset)
+break;
+}
+}
+
+offset -= current->start_offset;
+
+if (current != seg->segment_list_entry_writing) {
+int is_seekback = (current != >cur_entry) && 
seg->segment_list_entries;
+char *new_filename;
+AVIOContext *new_ctx = NULL;
+AVDictionary *options = NULL;
+
+if (!seg->seekback && is_seekback)
+return AVERROR(EINVAL);
+
+new_filename = current->full_filename;
+
+if (new_filename) {
+if (is_seekback)
+av_dict_set_int(, "truncate", 0, 0);
+if ((ret = avio_open2(_ctx, new_filename, AVIO_FLAG_WRITE,
+  >interrupt_callback, )) < 0) {
+av_log(s, AV_LOG_ERROR, "Failed to seek into segment '%s'\n", 
new_filename);
+return ret;
+}
+}
+
+avio_close(seg->cur_pb);
+seg->cur_pb = new_ctx;
+seg->segment_list_entry_writing = current;
+}
+
+if (seg->cur_pb)
+if ((ret = avio_seek(seg->cur_pb, offset, SEEK_SET)) < 0)
+return ret;
+
+seg->write_offset = offset;
+
+return target;
+}
+
+static int virtual_write(void *priv, uint8_t *buf, int buf_size)
+{
+AVFormatContext *s = priv;
+SegmentContext *seg = s->priv_data;
+int ret = 0;
+int written = 0;
+
+while (written < buf_size) {
+   

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix ffmpeg.h trailing whitespace

[Carl Eugen Hoyos]

Marton Balint  passwd.hu> writes:

> How this passed through the commit hook?

I'd also like to know but please push.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Hendrik Leppkes]

On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin  wrote:
> VLC is using frame threading with hwaccel

Then they should fix their usage, its broken by design, as explained
in detail my post earlier in this thread.

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

Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[Carl Eugen Hoyos]

Ganesh Ajjanagadde  gmail.com> writes:

> > This broke fate with -ftrapv

> > The problem seems to be in av_gcd() and not the De-Bruijn version of
> > ff_ctzll since the gcc builtin is being used.
> 
> Don't have the time to investigate right now - revert for now unless
> someone can fix it quickly.

Ping?

Please revert if nobody can fix this.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix ffmpeg.h trailing whitespace

[Michael Niedermayer]

On Thu, Oct 22, 2015 at 05:30:27AM +0200, Marton Balint wrote:
> How this passed through the commit hook?
> 
> Signed-off-by: Marton Balint 
> ---
>  ffmpeg.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

ok

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH] vf_psnr/ssim: don't crash if stats_file is NULL.

[Paul B Mahol]

Dana 23. 10. 2015. 00:01 osoba "Ronald S. Bultje" 
napisala je:
>
> ---
>  libavfilter/vf_psnr.c | 24 +---
>  libavfilter/vf_ssim.c | 24 +---
>  2 files changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
> index ca41939..36bbab2 100644
> --- a/libavfilter/vf_psnr.c
> +++ b/libavfilter/vf_psnr.c
> @@ -193,17 +193,19 @@ static av_cold int init(AVFilterContext *ctx)
>  s->min_mse = +INFINITY;
>  s->max_mse = -INFINITY;
>
> -if (!strcmp(s->stats_file_str, "-")) {
> -s->stats_file = stdout;
> -} else if (s->stats_file_str) {
> -s->stats_file = fopen(s->stats_file_str, "w");
> -if (!s->stats_file) {
> -int err = AVERROR(errno);
> -char buf[128];
> -av_strerror(err, buf, sizeof(buf));
> -av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s:
%s\n",
> -   s->stats_file_str, buf);
> -return err;
> +if (s->stats_file_str) {
> +if (!strcmp(s->stats_file_str, "-")) {
> +s->stats_file = stdout;
> +} else {
> +s->stats_file = fopen(s->stats_file_str, "w");
> +if (!s->stats_file) {
> +int err = AVERROR(errno);
> +char buf[128];
> +av_strerror(err, buf, sizeof(buf));
> +av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s:
%s\n",
> +   s->stats_file_str, buf);
> +return err;
> +}
>  }
>  }
>
> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
> index 4dc96a7..ce1e3db 100644
> --- a/libavfilter/vf_ssim.c
> +++ b/libavfilter/vf_ssim.c
> @@ -223,17 +223,19 @@ static av_cold int init(AVFilterContext *ctx)
>  {
>  SSIMContext *s = ctx->priv;
>
> -if (!strcmp(s->stats_file_str, "-")) {
> -s->stats_file = stdout;
> -} else if (s->stats_file_str) {
> -s->stats_file = fopen(s->stats_file_str, "w");
> -if (!s->stats_file) {
> -int err = AVERROR(errno);
> -char buf[128];
> -av_strerror(err, buf, sizeof(buf));
> -av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s:
%s\n",
> -   s->stats_file_str, buf);
> -return err;
> +if (s->stats_file_str) {
> +if (!strcmp(s->stats_file_str, "-")) {
> +s->stats_file = stdout;
> +} else {
> +s->stats_file = fopen(s->stats_file_str, "w");
> +if (!s->stats_file) {
> +int err = AVERROR(errno);
> +char buf[128];
> +av_strerror(err, buf, sizeof(buf));
> +av_log(ctx, AV_LOG_ERROR, "Could not open stats file %s:
%s\n",
> +   s->stats_file_str, buf);
> +return err;
> +}
>  }
>  }
>

Ok

> --
> 2.1.2
>
> ___
> 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] avcodec/huffman: replace qsort with AV_QSORT

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 9:28 PM, Timothy Gu  wrote:
> On Thu, Oct 22, 2015 at 5:01 PM Ganesh Ajjanagadde 
> wrote:
>>
>> Sample benchmark (x86-64, Haswell, GNU/Linux), fraps-v2 from FATE:
>> new:
>> 280110 decicycles in qsort,   1 runs,  0 skips
>> 268260 decicycles in qsort,   2 runs,  0 skips
>>
>> old:
>> 1469910 decicycles in qsort,   1 runs,  0 skips
>>  952950 decicycles in qsort,   2 runs,  0 skips
>
>
> Usually it takes more than 2 runs to make sure something is faster than the
> other (try -stream_loop 1 on the input).

In this case the gain should be obvious due to inlining. Nevertheless,
here are new numbers. I chose vp6 for two reasons:
1. Above was for fraps-v2, giving vp6 for more "completeness".
2. stream_loop throws errors: Error while decoding stream #0:0:
Invalid data found when processing input for fraps-v2.

Here they are:
vp6 (old):
  78930 decicycles in qsort,   1 runs,  0 skips
  45330 decicycles in qsort,   2 runs,  0 skips
  27825 decicycles in qsort,   4 runs,  0 skips
  17471 decicycles in qsort,   8 runs,  0 skips
  12296 decicycles in qsort,  16 runs,  0 skips
   9554 decicycles in qsort,  32 runs,  0 skips
   8404 decicycles in qsort,  64 runs,  0 skips
   7405 decicycles in qsort, 128 runs,  0 skips
   6740 decicycles in qsort, 256 runs,  0 skips
   7540 decicycles in qsort, 512 runs,  0 skips
   9498 decicycles in qsort,1024 runs,  0 skips
   9938 decicycles in qsort,2048 runs,  0 skips
   8043 decicycles in qsort,4095 runs,  1 skips

vp6 (new):
  15880 decicycles in qsort,   1 runs,  0 skips
  10730 decicycles in qsort,   2 runs,  0 skips
  10155 decicycles in qsort,   4 runs,  0 skips
   7805 decicycles in qsort,   8 runs,  0 skips
   6883 decicycles in qsort,  16 runs,  0 skips
   6305 decicycles in qsort,  32 runs,  0 skips
   5854 decicycles in qsort,  64 runs,  0 skips
   5152 decicycles in qsort, 128 runs,  0 skips
   4452 decicycles in qsort, 256 runs,  0 skips
   4161 decicycles in qsort, 511 runs,  1 skips
   4081 decicycles in qsort,1023 runs,  1 skips
   4072 decicycles in qsort,2047 runs,  1 skips
   4004 decicycles in qsort,4095 runs,  1 skips

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

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Michael Niedermayer
> Gesendet: Donnerstag, 22. Oktober 2015 17:39
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> 
> On Wed, Oct 21, 2015 at 11:26:30AM +0200, Sven Dueking wrote:
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
> > > Auftrag von Moritz Barsnick
> > > Gesendet: Mittwoch, 14. Oktober 2015 11:23
> > > An: FFmpeg development discussions and patches
> > > Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> > >
> > > On Wed, Oct 14, 2015 at 10:07:04 +0200, Sven Dueking wrote:
> > > > The attached patches adds the VPP as filter module to FFMpeg.
> > > > Looking forward to get feedback.
> > >
> > > doc/filters.texi?
> > >
> > > (Sorry, those who know what vpp is might get along fine with this,
> > > but I couldn't even quicky find out...)
> >
> > Hi Moritz,
> >
> > Documentation attached. Is it ok to provide this as separate file ?
> 
> Please always provide "git am" compatible patches with commit message
> and author.
> Also Documentation should be added by the same patch that adds the code
> to be documented unless that was already commited (thats not critical
> but preferred)
> 
> Thanks
> 

OK, thanks.
> 
> >
> > Thanks for checking.
> >
> > Best,
> > Sven
> > >
> > > Moritz
> > > ___
> > > 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
> 
> 
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> When the tyrant has disposed of foreign enemies by conquest or treaty,
> and there is nothing more to fear from them, then he is always stirring
> up some war or other, in order that the people may require a leader. --
> Plato

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

[FFmpeg-devel] [PATCH] avutil/qsort: use do while form for AV_QSORT

[Ganesh Ajjanagadde]

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/qsort.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/qsort.h b/libavutil/qsort.h
index 30edcc8..f079661 100644
--- a/libavutil/qsort.h
+++ b/libavutil/qsort.h
@@ -27,7 +27,7 @@
  * to construct input that requires O(n^2) time but this is very unlikely to
  * happen with non constructed input.
  */
-#define AV_QSORT(p, num, type, cmp) {\
+#define AV_QSORT(p, num, type, cmp) do { \
 void *stack[64][2];\
 int sp= 1;\
 stack[0][0] = p;\
@@ -89,7 +89,7 @@
 }\
 }\
 }\
-}
+} while (0)
 
 /**
  * Merge sort, this sort requires a temporary buffer and is stable, its worst
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[Dale Curtis]

On Wed, Oct 21, 2015 at 6:52 PM, Dale Curtis 
wrote:

> On Tue, Oct 20, 2015 at 11:50 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>>
>> the last element to be written should be checked, so that if
>> initialization is done by 2 threads at the same time, neither can
>> return from this function without initialization having finished
>>
>> also the race detectors are broken if they complain about cases where
>> a variable that has value a is set to value a, that cannot be part of
>> a race, not even if a is written byte per byte instead of atomically
>> unless theres something iam missing
>> Is this something that can be fixed or disabled on the side of the
>> race detectors?
>> It might reduce false positives in FFmpeg and potentially other
>> tools.
>>
>
> We can suppress it, which I think is more reasonable then the overhead
> it'd take to make this "race" go away. I notice the sin tables are
> initialized within the fft context so there's no "race." Is there a reason
> the cosine tables aren't done this way?
>

Actually it looks like sin may suffer from the same issues -- it doesn't
make a copy like I was thinking it did. One of the TSAN folk detailed why
suppression isn't a good idea here
https://codereview.chromium.org/1412123007/#msg7 -- which roughly says we
can't rely on the compiler to do the right thing here.

What are your thoughts about using ff_thread_once() to build the full sin
and cos tables all at once?

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

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Hendrik Leppkes
> Gesendet: Donnerstag, 22. Oktober 2015 14:26
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> 
> On Thu, Oct 22, 2015 at 2:20 PM, Sven Dueking  wrote:
> >
> >
> >> -Ursprüngliche Nachricht-
> >> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
> Auftrag
> >> von Sven Dueking
> >> Gesendet: Donnerstag, 22. Oktober 2015 14:03
> >> An: 'FFmpeg development discussions and patches'
> >> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> >>
> >>
> >>
> >> > -Ursprüngliche Nachricht-
> >> > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
> >> > Auftrag von Hendrik Leppkes
> >> > Gesendet: Donnerstag, 22. Oktober 2015 14:00
> >> > An: FFmpeg development discussions and patches
> >> > Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> >> >
> >> > On Thu, Oct 22, 2015 at 1:29 PM, Sven Dueking 
> >> wrote:
> >> > >
> >> > >
> >> > >> -Ursprüngliche Nachricht-
> >> > >> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
> >> > Auftrag
> >> > >> von Carl Eugen Hoyos
> >> > >> Gesendet: Mittwoch, 14. Oktober 2015 12:43
> >> > >> An: FFmpeg development discussions and patches
> >> > >> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> >> > >>
> >> > >> On Wednesday 14 October 2015 10:07:04 am Sven Dueking wrote:
> >> > >> > Hi all,
> >> > >> >
> >> > >> > The attached patches adds the VPP as filter module to FFMpeg.
> >> > >> > Looking forward to get feedback.
> >> > >>
> >> > >> Just a few comments, I expect you will get a comment explaining
> >> > >> what you can't do;-) (Sorry for the partly broken quotation.)
> >> > >>
> >> > >> In any case, please merge both patches, they are not
> independent.
> >> > >>
> >> > >> >
> >> > >> > Many thanks,
> >> > >> > Sven
> >> > >>
> >> > >> > From d09cff6d868bd2a0fd87e3906f8808638809494b Mon Sep 17
> >> 00:00:00
> >> > >> 2001
> >> > >> > From: Sven Dueking 
> >> > >> > Date: Wed, 14 Oct 2015 08:13:38 +0100
> >> > >> > Subject: [PATCH 1/2] added QSV based VPP filter
> >> > >> >
> >> > >> > ---
> >> > >> >  libavfilter/vf_qsv_vpp.c | 686
> >> > >> > +++ 1 file
> >> > >> > +++ changed,
> >> > 686
> >> > >> > insertions(+)
> >> > >> >  create mode 100644 libavfilter/vf_qsv_vpp.c
> >> > >> >
> >> > >> > diff --git a/libavfilter/vf_qsv_vpp.c
> >> > >> > b/libavfilter/vf_qsv_vpp.c new file mode 100644 index
> >> > >> > 000..629913e
> >> > >> > --- /dev/null
> >> > >> > +++ b/libavfilter/vf_qsv_vpp.c
> >> > >> > @@ -0,0 +1,686 @@
> >> > >> > +/*
> >> > >> > + * Intel MediaSDK Quick Sync Video VPP filter
> >> > >> > + *
> >> > >> > + * copyright (c) 2015 Sven Dueking
> >> > >> > + *
> >> > >> > + * This file is part of FFmpeg.
> >> > >> > + *
> >> > >> > + * Libav 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.
> >> > >> > + *
> >> > >> > + * Libav 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 Libav; if not, write to the Free
> >> > >> > + Software
> >> > >> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor,
> Boston,
> >> MA
> >> > >> > 02110-1301 USA + */
> >> > >> > +
> >> > >> > +#include 
> >> > >> > +#include 
> >> > >> > +
> >> > >> > +#include "avfilter.h"
> >> > >> > +#include "internal.h"
> >> > >> > +#include "formats.h"
> >> > >> > +
> >> > >> > +#include "libavutil/avassert.h"
> >> > >> > +#include "libavutil/opt.h"
> >> > >> > +#include "libavutil/time.h"
> >> > >> > +#include "libavutil/avstring.h"
> >> > >> > +#include "libavutil/error.h"
> >> > >> > +#include "libavcodec/avcodec.h"
> >> > >> > +#include "libavcodec/qsv_internal.h"
> >> > >> > +
> >> > >> > +#include 
> >> > >> > +
> >> > >> > +#include "avfilter.h"
> >> > >> > +#include "formats.h"
> >> > >> > +#include "internal.h"
> >> > >> > +#include "video.h"
> >> > >> > +#include "libavutil/eval.h"
> >> > >> > +#include "libavutil/avstring.h"
> >> > >> > +#include "libavutil/internal.h"
> >> > >> > +#include "libavutil/libm.h"
> >> > >> > +#include "libavutil/imgutils.h"
> >> > >> > +#include 

Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[Michael Niedermayer]

On Thu, Oct 22, 2015 at 07:04:41AM -0400, Ganesh Ajjanagadde wrote:
> On Thu, Oct 22, 2015 at 5:49 AM, Carl Eugen Hoyos  wrote:
> > Ganesh Ajjanagadde  gmail.com> writes:
> >
> >> > This broke fate with -ftrapv
> >
> >> > The problem seems to be in av_gcd() and not the De-Bruijn version of
> >> > ff_ctzll since the gcc builtin is being used.
> >>
> >> Don't have the time to investigate right now - revert for now unless
> >> someone can fix it quickly.
> >
> > Ping?
> >
> > Please revert if nobody can fix this.
> 
> "Fixing" this at the moment is highly dubious - read the thread. It
> does not even occur in a reproducible way, does not trigger on ubsan,
> I can't even see it on ftrapv. Show me why it is not a toolchain
> issue.

IMO never just assume that a problem that appears after a change you do
is not caused by your code.
Because if you do and you are wrong the bug might never be fixed
while OTOH, if you assume its in your code you will sooner or later
by debuging find the bug or more details, and that may be a
code generation issue in the toolchain outside your code in case
you where wrong.
Its the safer default assumtation as the failure path if you are wrong
is less bad.

either way, bug fixed
the reason for non reproduceablility likely was that the x86 asm
overrode the C code in which the bug was


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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Sven Dueking
> Gesendet: Donnerstag, 22. Oktober 2015 14:03
> An: 'FFmpeg development discussions and patches'
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> 
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> > von Hendrik Leppkes
> > Gesendet: Donnerstag, 22. Oktober 2015 14:00
> > An: FFmpeg development discussions and patches
> > Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> >
> > On Thu, Oct 22, 2015 at 1:29 PM, Sven Dueking 
> wrote:
> > >
> > >
> > >> -Ursprüngliche Nachricht-
> > >> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
> > Auftrag
> > >> von Carl Eugen Hoyos
> > >> Gesendet: Mittwoch, 14. Oktober 2015 12:43
> > >> An: FFmpeg development discussions and patches
> > >> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> > >>
> > >> On Wednesday 14 October 2015 10:07:04 am Sven Dueking wrote:
> > >> > Hi all,
> > >> >
> > >> > The attached patches adds the VPP as filter module to FFMpeg.
> > >> > Looking forward to get feedback.
> > >>
> > >> Just a few comments, I expect you will get a comment explaining
> > >> what you can't do;-) (Sorry for the partly broken quotation.)
> > >>
> > >> In any case, please merge both patches, they are not independent.
> > >>
> > >> >
> > >> > Many thanks,
> > >> > Sven
> > >>
> > >> > From d09cff6d868bd2a0fd87e3906f8808638809494b Mon Sep 17
> 00:00:00
> > >> 2001
> > >> > From: Sven Dueking 
> > >> > Date: Wed, 14 Oct 2015 08:13:38 +0100
> > >> > Subject: [PATCH 1/2] added QSV based VPP filter
> > >> >
> > >> > ---
> > >> >  libavfilter/vf_qsv_vpp.c | 686
> > >> > +++ 1 file changed,
> > 686
> > >> > insertions(+)
> > >> >  create mode 100644 libavfilter/vf_qsv_vpp.c
> > >> >
> > >> > diff --git a/libavfilter/vf_qsv_vpp.c b/libavfilter/vf_qsv_vpp.c
> > >> > new file mode 100644 index 000..629913e
> > >> > --- /dev/null
> > >> > +++ b/libavfilter/vf_qsv_vpp.c
> > >> > @@ -0,0 +1,686 @@
> > >> > +/*
> > >> > + * Intel MediaSDK Quick Sync Video VPP filter
> > >> > + *
> > >> > + * copyright (c) 2015 Sven Dueking
> > >> > + *
> > >> > + * This file is part of FFmpeg.
> > >> > + *
> > >> > + * Libav 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.
> > >> > + *
> > >> > + * Libav 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 Libav; if not, write to the Free Software
> > >> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> MA
> > >> > 02110-1301 USA + */
> > >> > +
> > >> > +#include 
> > >> > +#include 
> > >> > +
> > >> > +#include "avfilter.h"
> > >> > +#include "internal.h"
> > >> > +#include "formats.h"
> > >> > +
> > >> > +#include "libavutil/avassert.h"
> > >> > +#include "libavutil/opt.h"
> > >> > +#include "libavutil/time.h"
> > >> > +#include "libavutil/avstring.h"
> > >> > +#include "libavutil/error.h"
> > >> > +#include "libavcodec/avcodec.h"
> > >> > +#include "libavcodec/qsv_internal.h"
> > >> > +
> > >> > +#include 
> > >> > +
> > >> > +#include "avfilter.h"
> > >> > +#include "formats.h"
> > >> > +#include "internal.h"
> > >> > +#include "video.h"
> > >> > +#include "libavutil/eval.h"
> > >> > +#include "libavutil/avstring.h"
> > >> > +#include "libavutil/internal.h"
> > >> > +#include "libavutil/libm.h"
> > >> > +#include "libavutil/imgutils.h"
> > >> > +#include "libavutil/mathematics.h"
> > >> > +#include "libavutil/opt.h"
> > >> > +#include "libavutil/pixfmt.h"
> > >>
> > >> Are they all necessary?
> > >>
> > >> > +
> > >> > +/**
> > >> > + * ToDo :
> > >> > + *
> > >> > + * - handle empty extbuffers
> > >> > + * - cropping
> > >> > + * - allocate number of surfaces depending modules and number
> of
> > b
> > >> > +frames  */
> > >> > +
> > >> > +#define VPP_ZERO_MEMORY(VAR){ memset(, 0,
> > sizeof(VAR));
> > >> }
> > >>
> > >> I don't think this is more readable, but that may only be me.
> > >>
> > >> > +#define VPP_ALIGN16(value)  (((value + 15) >> 4) << 4)
> > >> //
> > >> > round up to a multiple of 16 +#define VPP_ALIGN32(value)
> > >> (((value
> > >> > + 31) >> 5) << 5)  // round up to a multiple of 32
> > +#define
> > >>
> > >> Isn't this FFALIGN()?
> > >>
> > 

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter

[Hendrik Leppkes]

On Thu, Oct 22, 2015 at 2:20 PM, Sven Dueking  wrote:
>
>
>> -Ursprüngliche Nachricht-
>> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
>> von Sven Dueking
>> Gesendet: Donnerstag, 22. Oktober 2015 14:03
>> An: 'FFmpeg development discussions and patches'
>> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
>>
>>
>>
>> > -Ursprüngliche Nachricht-
>> > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
>> > von Hendrik Leppkes
>> > Gesendet: Donnerstag, 22. Oktober 2015 14:00
>> > An: FFmpeg development discussions and patches
>> > Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
>> >
>> > On Thu, Oct 22, 2015 at 1:29 PM, Sven Dueking 
>> wrote:
>> > >
>> > >
>> > >> -Ursprüngliche Nachricht-
>> > >> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
>> > Auftrag
>> > >> von Carl Eugen Hoyos
>> > >> Gesendet: Mittwoch, 14. Oktober 2015 12:43
>> > >> An: FFmpeg development discussions and patches
>> > >> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
>> > >>
>> > >> On Wednesday 14 October 2015 10:07:04 am Sven Dueking wrote:
>> > >> > Hi all,
>> > >> >
>> > >> > The attached patches adds the VPP as filter module to FFMpeg.
>> > >> > Looking forward to get feedback.
>> > >>
>> > >> Just a few comments, I expect you will get a comment explaining
>> > >> what you can't do;-) (Sorry for the partly broken quotation.)
>> > >>
>> > >> In any case, please merge both patches, they are not independent.
>> > >>
>> > >> >
>> > >> > Many thanks,
>> > >> > Sven
>> > >>
>> > >> > From d09cff6d868bd2a0fd87e3906f8808638809494b Mon Sep 17
>> 00:00:00
>> > >> 2001
>> > >> > From: Sven Dueking 
>> > >> > Date: Wed, 14 Oct 2015 08:13:38 +0100
>> > >> > Subject: [PATCH 1/2] added QSV based VPP filter
>> > >> >
>> > >> > ---
>> > >> >  libavfilter/vf_qsv_vpp.c | 686
>> > >> > +++ 1 file changed,
>> > 686
>> > >> > insertions(+)
>> > >> >  create mode 100644 libavfilter/vf_qsv_vpp.c
>> > >> >
>> > >> > diff --git a/libavfilter/vf_qsv_vpp.c b/libavfilter/vf_qsv_vpp.c
>> > >> > new file mode 100644 index 000..629913e
>> > >> > --- /dev/null
>> > >> > +++ b/libavfilter/vf_qsv_vpp.c
>> > >> > @@ -0,0 +1,686 @@
>> > >> > +/*
>> > >> > + * Intel MediaSDK Quick Sync Video VPP filter
>> > >> > + *
>> > >> > + * copyright (c) 2015 Sven Dueking
>> > >> > + *
>> > >> > + * This file is part of FFmpeg.
>> > >> > + *
>> > >> > + * Libav 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.
>> > >> > + *
>> > >> > + * Libav 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 Libav; if not, write to the Free Software
>> > >> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
>> MA
>> > >> > 02110-1301 USA + */
>> > >> > +
>> > >> > +#include 
>> > >> > +#include 
>> > >> > +
>> > >> > +#include "avfilter.h"
>> > >> > +#include "internal.h"
>> > >> > +#include "formats.h"
>> > >> > +
>> > >> > +#include "libavutil/avassert.h"
>> > >> > +#include "libavutil/opt.h"
>> > >> > +#include "libavutil/time.h"
>> > >> > +#include "libavutil/avstring.h"
>> > >> > +#include "libavutil/error.h"
>> > >> > +#include "libavcodec/avcodec.h"
>> > >> > +#include "libavcodec/qsv_internal.h"
>> > >> > +
>> > >> > +#include 
>> > >> > +
>> > >> > +#include "avfilter.h"
>> > >> > +#include "formats.h"
>> > >> > +#include "internal.h"
>> > >> > +#include "video.h"
>> > >> > +#include "libavutil/eval.h"
>> > >> > +#include "libavutil/avstring.h"
>> > >> > +#include "libavutil/internal.h"
>> > >> > +#include "libavutil/libm.h"
>> > >> > +#include "libavutil/imgutils.h"
>> > >> > +#include "libavutil/mathematics.h"
>> > >> > +#include "libavutil/opt.h"
>> > >> > +#include "libavutil/pixfmt.h"
>> > >>
>> > >> Are they all necessary?
>> > >>
>> > >> > +
>> > >> > +/**
>> > >> > + * ToDo :
>> > >> > + *
>> > >> > + * - handle empty extbuffers
>> > >> > + * - cropping
>> > >> > + * - allocate number of surfaces depending modules and number
>> of
>> > b
>> > >> > +frames  */
>> > >> > +
>> > >> > +#define VPP_ZERO_MEMORY(VAR){ memset(, 0,
>> > sizeof(VAR));
>> > >> }
>> > >>
>> > >> I don't think this is more readable, but that may only be me.
>> > >>
>> > >> > +#define VPP_ALIGN16(value)  (((value + 15) >> 4) << 4)
>> > >> //

Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 8:33 AM, Michael Niedermayer
 wrote:
> On Thu, Oct 22, 2015 at 07:04:41AM -0400, Ganesh Ajjanagadde wrote:
>> On Thu, Oct 22, 2015 at 5:49 AM, Carl Eugen Hoyos  wrote:
>> > Ganesh Ajjanagadde  gmail.com> writes:
>> >
>> >> > This broke fate with -ftrapv
>> >
>> >> > The problem seems to be in av_gcd() and not the De-Bruijn version of
>> >> > ff_ctzll since the gcc builtin is being used.
>> >>
>> >> Don't have the time to investigate right now - revert for now unless
>> >> someone can fix it quickly.
>> >
>> > Ping?
>> >
>> > Please revert if nobody can fix this.
>>
>> "Fixing" this at the moment is highly dubious - read the thread. It
>> does not even occur in a reproducible way, does not trigger on ubsan,
>> I can't even see it on ftrapv. Show me why it is not a toolchain
>> issue.
>
> IMO never just assume that a problem that appears after a change you do
> is not caused by your code.
> Because if you do and you are wrong the bug might never be fixed
> while OTOH, if you assume its in your code you will sooner or later
> by debuging find the bug or more details, and that may be a
> code generation issue in the toolchain outside your code in case
> you where wrong.
> Its the safer default assumtation as the failure path if you are wrong
> is less bad.
>
> either way, bug fixed
> the reason for non reproduceablility likely was that the x86 asm
> overrode the C code in which the bug was

Ok, go ahead and revert. I just did not see the hurry for reverting;
since it does not break normal builds.

>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
> ___
> 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] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 8:42 AM, Ganesh Ajjanagadde  wrote:
> On Thu, Oct 22, 2015 at 8:33 AM, Michael Niedermayer
>  wrote:
>> On Thu, Oct 22, 2015 at 07:04:41AM -0400, Ganesh Ajjanagadde wrote:
>>> On Thu, Oct 22, 2015 at 5:49 AM, Carl Eugen Hoyos  wrote:
>>> > Ganesh Ajjanagadde  gmail.com> writes:
>>> >
>>> >> > This broke fate with -ftrapv
>>> >
>>> >> > The problem seems to be in av_gcd() and not the De-Bruijn version of
>>> >> > ff_ctzll since the gcc builtin is being used.
>>> >>
>>> >> Don't have the time to investigate right now - revert for now unless
>>> >> someone can fix it quickly.
>>> >
>>> > Ping?
>>> >
>>> > Please revert if nobody can fix this.
>>>
>>> "Fixing" this at the moment is highly dubious - read the thread. It
>>> does not even occur in a reproducible way, does not trigger on ubsan,
>>> I can't even see it on ftrapv. Show me why it is not a toolchain
>>> issue.
>>
>> IMO never just assume that a problem that appears after a change you do
>> is not caused by your code.
>> Because if you do and you are wrong the bug might never be fixed
>> while OTOH, if you assume its in your code you will sooner or later
>> by debuging find the bug or more details, and that may be a
>> code generation issue in the toolchain outside your code in case
>> you where wrong.
>> Its the safer default assumtation as the failure path if you are wrong
>> is less bad.
>>
>> either way, bug fixed
>> the reason for non reproduceablility likely was that the x86 asm
>> overrode the C code in which the bug was
>
> Ok, go ahead and revert. I just did not see the hurry for reverting;
> since it does not break normal builds.

Just saw your commit. I guess a lot of the confusion stemmed from the
fact that James's report was slightly misleading - it seemed to target
av_gcd as opposed to the De-Bruijn implementation, where it seems the
bug really was.

>
>>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> I have often repented speaking, but never of holding my tongue.
>> -- Xenocrates
>>
>> ___
>> 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] avutil/qsort: use do while form for AV_QSORT

[Clément Bœsch]

On Thu, Oct 22, 2015 at 10:53:10PM -0400, Ganesh Ajjanagadde wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/qsort.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/qsort.h b/libavutil/qsort.h
> index 30edcc8..f079661 100644
> --- a/libavutil/qsort.h
> +++ b/libavutil/qsort.h
> @@ -27,7 +27,7 @@
>   * to construct input that requires O(n^2) time but this is very unlikely to
>   * happen with non constructed input.
>   */
> -#define AV_QSORT(p, num, type, cmp) {\
> +#define AV_QSORT(p, num, type, cmp) do { \
>  void *stack[64][2];\
>  int sp= 1;\
>  stack[0][0] = p;\
> @@ -89,7 +89,7 @@
>  }\
>  }\
>  }\
> -}
> +} while (0)
>  

Probably relevant for the AV_MSORT() below too

-- 
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] [PATCH] Added QSV based VPP filter

[Michael Niedermayer]

On Wed, Oct 21, 2015 at 11:26:30AM +0200, Sven Dueking wrote:
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> > von Moritz Barsnick
> > Gesendet: Mittwoch, 14. Oktober 2015 11:23
> > An: FFmpeg development discussions and patches
> > Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> > 
> > On Wed, Oct 14, 2015 at 10:07:04 +0200, Sven Dueking wrote:
> > > The attached patches adds the VPP as filter module to FFMpeg.
> > > Looking forward to get feedback.
> > 
> > doc/filters.texi?
> > 
> > (Sorry, those who know what vpp is might get along fine with this, but
> > I couldn't even quicky find out...)
> 
> Hi Moritz,
> 
> Documentation attached. Is it ok to provide this as separate file ? 

Please always provide "git am" compatible patches with commit message
and author.
Also Documentation should be added by the same patch that adds the
code to be documented unless that was already commited (thats not
critical but preferred)

Thanks


> 
> Thanks for checking.
> 
> Best,
> Sven
> > 
> > Moritz
> > ___
> > 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


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[Michael Niedermayer]

On Thu, Oct 22, 2015 at 08:53:07AM -0400, Ganesh Ajjanagadde wrote:
> On Thu, Oct 22, 2015 at 8:42 AM, Ganesh Ajjanagadde  wrote:
> > On Thu, Oct 22, 2015 at 8:33 AM, Michael Niedermayer
> >  wrote:
> >> On Thu, Oct 22, 2015 at 07:04:41AM -0400, Ganesh Ajjanagadde wrote:
> >>> On Thu, Oct 22, 2015 at 5:49 AM, Carl Eugen Hoyos  
> >>> wrote:
> >>> > Ganesh Ajjanagadde  gmail.com> writes:
> >>> >
> >>> >> > This broke fate with -ftrapv
> >>> >
> >>> >> > The problem seems to be in av_gcd() and not the De-Bruijn version of
> >>> >> > ff_ctzll since the gcc builtin is being used.
> >>> >>
> >>> >> Don't have the time to investigate right now - revert for now unless
> >>> >> someone can fix it quickly.
> >>> >
> >>> > Ping?
> >>> >
> >>> > Please revert if nobody can fix this.
> >>>
> >>> "Fixing" this at the moment is highly dubious - read the thread. It
> >>> does not even occur in a reproducible way, does not trigger on ubsan,
> >>> I can't even see it on ftrapv. Show me why it is not a toolchain
> >>> issue.
> >>
> >> IMO never just assume that a problem that appears after a change you do
> >> is not caused by your code.
> >> Because if you do and you are wrong the bug might never be fixed
> >> while OTOH, if you assume its in your code you will sooner or later
> >> by debuging find the bug or more details, and that may be a
> >> code generation issue in the toolchain outside your code in case
> >> you where wrong.
> >> Its the safer default assumtation as the failure path if you are wrong
> >> is less bad.
> >>
> >> either way, bug fixed
> >> the reason for non reproduceablility likely was that the x86 asm
> >> overrode the C code in which the bug was
> >
> > Ok, go ahead and revert. I just did not see the hurry for reverting;
> > since it does not break normal builds.
> 
> Just saw your commit. I guess a lot of the confusion stemmed from the
> fact that James's report was slightly misleading - it seemed to target
> av_gcd as opposed to the De-Bruijn implementation, where it seems the
> bug really was.

maybe ff_ctzll() was inlined in av_gcd and the compiler or debugger
then pointed to the wrong

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Hendrik Leppkes]

On Wed, Oct 14, 2015 at 11:47 AM, Hendrik Leppkes  wrote:
> On Wed, Oct 7, 2015 at 7:07 PM, Ivan Uskov  wrote:
>> Hello wm4,
>>
>> Wednesday, October 7, 2015, 7:40:45 PM, you wrote:
>>
>> w> There's no automagic way to get this done.
>>
>> w> Hardware accelerators like vaapi and vdpau need the same thing. These
>> w> have special APIs to set an API context on the decoder. Some APIs use
>> w> hwaccel_context, vdpau uses av_vdpau_bind_context().
>>
>> w> The hwaccel_context pointer is untyped (just a void*), and what it means
>> w> is implicit to the hwaccel or the decoder that is used. It could point
>> w> to some sort of qsv state, which will have to be explicitly allocated
>> w> and set by the API user (which might be ffmpeg.c).
>> So  if  I will implement something like ffmpeg_qsv.c (using ffmpeg_vdpau.c as
>> example)   and   extend  the  hwaccels[]  into  ffmpeg_opt.c  by corresponded
>> qsv entries it  would  be the acceptable solution, correct?
>>
>> w> For filters there is no such thing yet. New API would have to be
>> w> created. For filters in particular, we will have to make sure that the
>> w> API isn't overly qsv-specific, and that it is extendable to other APIs
>> w> (like for example vaapi or vdpau).
>> Ok,   if   VPP  could be the  issue  I  would  like  to  get  working  direct
>> link qsv_decoder-qsv_encoder first.
>>
>
> Libav has a patch that does exactly this, allow direct QSV->QSV
> transcoding with help of some utility code in ffmpeg.c/avconv.c
> You might want to look at that instead of re-inventing it. That'll
> help make everyones live easier, as I'll just merge it when the time
> comes, and the codebases don't diverge too drastically.
>

This functionality has been merged now. It works for some samples.
You can try to use it with a command line like this:

ffmpeg -hwaccel qsv -c:v h264_qsv -i h264.ts -c:v h264_qsv output.mkv

This will transcode using a QSV->QSV pipeline, no copying to system
memory, and about 2.5x faster on my IVB laptop.

However, its broken on a lot of more complex H264 files, you'll get
errors like get_buffer() failed - this is because our qsvdec behaves
rather strangely, and instead of buffering input data when needed, it
buffers output surfaces, which is not ideal, since it bloats up the
memory usage an the number of surfaces required explodes into
infinity.
I know how to fix it - just restore the decoder to the same buffering
model as it originally used, buffer input data instead of output
surfaces. Unless someone else wants to fix it, I'll simply do it in
the next week or so.

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

Re: [FFmpeg-devel] [PATCH] WIP: lavf/segment: provide a virtual AVIOContext representing all the segments

[Michael Niedermayer]

On Thu, Oct 22, 2015 at 04:50:00AM -0500, Rodger Combs wrote:
> This allows the use of muxers like matroska, which attempt to seek even
> when an AVIOContext doesn't set `seekable`, without concern for a rouge
> seek leading the muxer to overwrite the wrong data in a later segment.
> ---
>  doc/muxers.texi   |  17 
>  libavformat/segment.c | 262 
> ++
>  2 files changed, 215 insertions(+), 64 deletions(-)

ffmpeg -i matrixbench_mpeg2.mpg -vcodec mpeg2video -f segment  /tmp/out-%4d.mpg
results in (at the end)
*** glibc detected *** ffmpeg/ffmpeg: corrupted double-linked list: 
0x03b10ab0 ***

==29669== Invalid free() / delete / delete[] / realloc()rate=N/A
==29669==at 0x4C2B5D9: free (vg_replace_malloc.c:446)
==29669==by 0x691D68: seg_write_trailer (in ffmpeg/ffmpeg_g)
==29669==by 0x63E0A9: av_write_trailer (in ffmpeg/ffmpeg_g)
==29669==by 0x4B64CC: transcode (in ffmpeg/ffmpeg_g)
==29669==by 0x498A05: main (in ffmpeg/ffmpeg_g)
==29669==  Address 0x19b24280 is 0 bytes inside a block of size 13 free'd
==29669==at 0x4C2B5D9: free (vg_replace_malloc.c:446)
==29669==by 0x691D37: seg_write_trailer (in ffmpeg/ffmpeg_g)
==29669==by 0x63E0A9: av_write_trailer (in ffmpeg/ffmpeg_g)
==29669==by 0x4B64CC: transcode (in ffmpeg/ffmpeg_g)
==29669==by 0x498A05: main (in ffmpeg/ffmpeg_g)

[...]
-- 
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] ffmpeg: fix ffmpeg.h trailing whitespace

[Marton Balint]

On Thu, 22 Oct 2015, Carl Eugen Hoyos wrote:


Marton Balint  passwd.hu> writes:


How this passed through the commit hook?


I'd also like to know but please push.



Ok, pushed.

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

Re: [FFmpeg-devel] [PATCH 5/5] ffmpeg: add abort_on option to allow aborting on empty output

[Marton Balint]

On Mon, 19 Oct 2015, Marton Balint wrote:


On Mon, 19 Oct 2015, Michael Niedermayer wrote:


On Sun, Oct 18, 2015 at 12:24:07AM +0200, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 doc/ffmpeg.texi |  8 
 ffmpeg.c|  7 +++
 ffmpeg.h|  3 +++
 ffmpeg_opt.c| 21 +
 4 files changed, 39 insertions(+)


LGTM but maybe others have suggestions on the implementation or
user interface


Ok, I will apply in 48 hours if no further comments are received.



Pushed.

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