[FFmpeg-devel] [PATCH]lavf/http: Add httpproxy to the default protocol whitelist

[Carl Eugen Hoyos]

Hi!

Attached patch may fix an issue reported on the user mailing list.

Please review, Carl Eugen
diff --git a/libavformat/http.c b/libavformat/http.c
index f18d9e2..4f9d730 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1541,7 +1541,7 @@ const URLProtocol ff_https_protocol = {
 .priv_data_size  = sizeof(HTTPContext),
 .priv_data_class = _context_class,
 .flags   = URL_PROTOCOL_FLAG_NETWORK,
-.default_whitelist   = "http,https,tls,rtp,tcp,udp,crypto"
+.default_whitelist   = "http,https,tls,rtp,tcp,udp,crypto,httpproxy"
 };
 #endif /* CONFIG_HTTPS_PROTOCOL */
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks

[Mats Peterson]

On 03/13/2016 06:15 AM, Mats Peterson wrote:

On 03/12/2016 07:12 AM, Mats Peterson wrote:

New patch set. Forget the old one.

 From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:



"biSize: Specifies the number of bytes required by the structure. This
value does not include the size of the color table or the size of the
color masks, if they are appended to the end of structure."

So, biSize is 40 for palettized video as well. And Windows Media Player
won't display any video when using Microsoft Video 1 in 8 bpp mode or
RLE4/RLE8 if this value is set to anything else than 40.

For non-palette extra data in huffyuv, ffvhuff, asv1 and asv2, the extra
data will be included in biSize. There are possibly more codecs with
special global headers, but we can fix that as they are discovered.
Currently these are the only ones I know of.



As an alternative to using a list, and as a compromise from my side, is
the snippet below good enough?

avio_wl32(pb, 40 + (ignore_extradata || pix_fmt == AV_PIX_FMT_PAL8 ?
   0 : extradata_size));




This one is better:

avio_wl32(pb, 40 + (ignore_extradata || pal_avi ? 0 : extradata_size);


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks

[Mats Peterson]

On 03/12/2016 07:12 AM, Mats Peterson wrote:

New patch set. Forget the old one.

 From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:


"biSize: Specifies the number of bytes required by the structure. This
value does not include the size of the color table or the size of the
color masks, if they are appended to the end of structure."

So, biSize is 40 for palettized video as well. And Windows Media Player
won't display any video when using Microsoft Video 1 in 8 bpp mode or
RLE4/RLE8 if this value is set to anything else than 40.

For non-palette extra data in huffyuv, ffvhuff, asv1 and asv2, the extra
data will be included in biSize. There are possibly more codecs with
special global headers, but we can fix that as they are discovered.
Currently these are the only ones I know of.



As an alternative to using a list, and as a compromise from my side, is 
the snippet below good enough?


avio_wl32(pb, 40 + (ignore_extradata || pix_fmt == AV_PIX_FMT_PAL8 ?
  0 : extradata_size));

Mats

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

Re: [FFmpeg-devel] [PATCHv5 1/3] tests/gapless: add gapless aac tests

[Michael Niedermayer]

On Sun, Mar 13, 2016 at 01:12:25AM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  tests/fate-run.sh| 28 ++
>  tests/fate/gapless.mak   | 28 +-
>  tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 43 
> 
>  tests/ref/fate/gaplessenc-pcm-to-mov-aac | 43 
> 
>  tests/ref/fate/gaplessinfo-itunes1   | 43 
> 
>  tests/ref/fate/gaplessinfo-itunes2   | 43 
> 
>  6 files changed, 227 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/gaplessenc-itunes-to-ipod-aac
>  create mode 100644 tests/ref/fate/gaplessenc-pcm-to-mov-aac
>  create mode 100644 tests/ref/fate/gaplessinfo-itunes1
>  create mode 100644 tests/ref/fate/gaplessinfo-itunes2

tested on mips and arm qemu and x86 mingw

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 10:28 PM, Mats Peterson wrote:

On 03/12/2016 10:25 PM, Mats Peterson wrote:

On 03/12/2016 10:16 PM, Mats Peterson wrote:

On 03/12/2016 06:39 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 04:37:39PM +0100, Mats Peterson wrote:

On 03/12/2016 04:33 PM, Mats Peterson wrote:

On 03/12/2016 04:29 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in
the
demuxer  is a future task. Now the muxing of video with xxpc
chunks
works properly at least.

Try playing the resulting test.avi file from the command line
below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17
00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a
zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int
avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised
value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by
anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at
least?


patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.


40 is exactly what it should be, in *all* cases, regardless of what
follows the BITMAPINFOHEADER. Read below.



The spec says:
"A stream format chunk ('strf') must follow the stream header chunk.
The stream format chunk describes the format of the data in the
stream. The data contained in this chunk depends on the stream type.
For video streams, the information is a BITMAPINFO structure,
including palette information if appropriate. For audio streams, the
information is a WAVEFORMATEX structure."

If that chunk is a BITMAPINFO structure + a palette then formats
without a palette would likely have biSize similar to the chunk
size ...

its quite possible iam missing some details of course ...



You're missing the specification of the BITMAPINFOHEADER. It states
that
biSize is the 

Re: [FFmpeg-devel] [PATCH]lavc/hevc: Support GBR encoding and decoding

[Hendrik Leppkes]

On Sun, Mar 13, 2016 at 3:14 AM, Hendrik Leppkes  wrote:
> On Sat, Mar 12, 2016 at 1:44 PM, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch allows GBR encoding and decoding for hevc.
>>
>
> Encoder and decoder patches should be separated, they are quite
> distinct code other then being related by codec, otherwise its
> probably fine.
>

Actually some further comments:

> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index bcb63a3..7237ee6 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -561,6 +561,17 @@ static void decode_vui(GetBitContext *gb, AVCodecContext 
> *avctx,
> vui->transfer_characteristic = AVCOL_TRC_UNSPECIFIED;
> if (vui->matrix_coeffs >= AVCOL_SPC_NB)
> vui->matrix_coeffs = AVCOL_SPC_UNSPECIFIED;
> +if (vui->matrix_coeffs == AVCOL_SPC_RGB)
> +switch (sps->pix_fmt) {
> +case AV_PIX_FMT_YUV444P:
> +sps->pix_fmt = AV_PIX_FMT_GBRP;
> +break;
> +case AV_PIX_FMT_YUV444P10:
> +sps->pix_fmt = AV_PIX_FMT_GBRP10;
> +break;
> +case AV_PIX_FMT_YUV444P12:
> +sps->pix_fmt = AV_PIX_FMT_GBRP12;
> +}

Please add a break here for consistency, avoiding issues early, etc. :)

> }
> }
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index 68c7fba..072bace 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -257,6 +263,7 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
> AVPacket *pkt,
>
> x265pic.pts  = pic->pts;
> x265pic.bitDepth = av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth;
> +printf("x265pic.bitDepth: %d \n", x265pic.bitDepth);
>
> x265pic.sliceType = pic->pict_type == AV_PICTURE_TYPE_I ? X265_TYPE_I 
> :
> pic->pict_type == AV_PICTURE_TYPE_P ? X265_TYPE_P 
> :

The printf is hopefully a debugging artifact? :)


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

Re: [FFmpeg-devel] [PATCH]lavc/hevc: Support GBR encoding and decoding

[Hendrik Leppkes]

On Sat, Mar 12, 2016 at 1:44 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch allows GBR encoding and decoding for hevc.
>

Encoder and decoder patches should be separated, they are quite
distinct code other then being related by codec, otherwise its
probably fine.

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

[FFmpeg-devel] [PATCH 2/2] avutil/dict: add warning to docs about invalidating existing entries when adding a new entry

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavutil/dict.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavutil/dict.h b/libavutil/dict.h
index b0aa784..542d540 100644
--- a/libavutil/dict.h
+++ b/libavutil/dict.h
@@ -116,6 +116,9 @@ int av_dict_count(const AVDictionary *m);
  * Note: If AV_DICT_DONT_STRDUP_KEY or AV_DICT_DONT_STRDUP_VAL is set,
  * these arguments will be freed on error.
  *
+ * Warning: Adding a new entry to a dictionary invalidates all existing entries
+ * previously returned with av_dict_get.
+ *
  * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
  * a dictionary struct is allocated and put in *pm.
  * @param key entry key to add to *pm (will be av_strduped depending on flags)
-- 
2.6.2

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

[FFmpeg-devel] Fwd: Need help in fixing in FFmpegWrapper: av_interleaved_write_frame video issue.

[krish]

Hello,
I am new to this forum and have zero knowledge on ffmpeg.  I have forwarded
this to users group a 10 hours ago but haven't any reply. Not sure if I can
post in dev forum. Sincere apologies if this mail doesn't fit dev forum's
criteria.

I am using KickFlip's sdk for live straming from an android device.

Everything works fine until  35 Mins  of live streaming, but starts failing
after 35 Mins , the errors comes from FFmpegWrapper.so library.

*Error: FFmpegWrapper﹕ av_interleaved_write_frame video: 0 pkt: 64440 size:
565 error: Invalid argument*

On searching for solutions , I came across this solution ,(
https://github.com/Kickflip/kickflip-android-sdk/issues/35#issuecomment-149854977
)

In File FFmpegWrapper.C  , change int type cast to int64.

packet->pts = (int) jPts;

to:

packet->pts = (int64_) jPts;

Is this the correct solution ? If yes then how can I build the required
libraries ? I really appreciate your help in fixing the above issue. (
NOTE: Tried contacting kickflip but haven't got any response from them )

Thanks in advance.

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

[FFmpeg-devel] [PATCHv5 2/3] avformat/utils: increase detected start_time with skip_samples

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/utils.c  | 10 +++-
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 68 ++--
 tests/ref/fate/gaplessinfo-itunes1   |  4 +-
 tests/ref/fate/gaplessinfo-itunes2   |  4 +-
 4 files changed, 46 insertions(+), 40 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index e0aea87..ccb76d2 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -971,8 +971,11 @@ static void update_initial_timestamps(AVFormatContext *s, 
int stream_index,
 if (is_relative(pktl->pkt.dts))
 pktl->pkt.dts += shift;
 
-if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts != 
AV_NOPTS_VALUE)
+if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts != 
AV_NOPTS_VALUE) {
 st->start_time = pktl->pkt.pts;
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO && 
st->codec->sample_rate)
+st->start_time += av_rescale_q(st->skip_samples, 
(AVRational){1, st->codec->sample_rate}, st->time_base);
+}
 
 if (pktl->pkt.pts != AV_NOPTS_VALUE && delay <= MAX_REORDER_DELAY && 
has_decode_delay_been_guessed(st)) {
 pts_buffer[0] = pktl->pkt.pts;
@@ -983,8 +986,11 @@ static void update_initial_timestamps(AVFormatContext *s, 
int stream_index,
 }
 }
 
-if (st->start_time == AV_NOPTS_VALUE)
+if (st->start_time == AV_NOPTS_VALUE) {
 st->start_time = pts;
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO && 
st->codec->sample_rate)
+st->start_time += av_rescale_q(st->skip_samples, (AVRational){1, 
st->codec->sample_rate}, st->time_base);
+}
 }
 
 static void update_initial_durations(AVFormatContext *s, AVStream *st,
diff --git a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac 
b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
index 1d4262f..564c212 100644
--- a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
+++ b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
@@ -1,43 +1,43 @@
 [STREAM]
 index=0
-start_pts=1058
+start_pts=-1024
 duration_ts=104384
 [/STREAM]
 [FORMAT]
-start_time=0.023991
+start_time=-0.023220
 duration=2.367000
 [/FORMAT]
-packet|pts=1058|dts=1058|duration=1024
-packet|pts=2082|dts=2082|duration=1024
-packet|pts=3106|dts=3106|duration=1024
-packet|pts=4130|dts=4130|duration=1024
-packet|pts=5154|dts=5154|duration=1024
-packet|pts=6178|dts=6178|duration=1024
-packet|pts=7202|dts=7202|duration=1024
-packet|pts=8226|dts=8226|duration=1024
-packet|pts=97314|dts=97314|duration=1024
-packet|pts=98338|dts=98338|duration=1024
-packet|pts=99362|dts=99362|duration=1024
-packet|pts=100386|dts=100386|duration=1024
-packet|pts=101410|dts=101410|duration=1024
-packet|pts=102434|dts=102434|duration=1024
-packet|pts=103458|dts=103458|duration=1024
-packet|pts=104482|dts=104482|duration=-98
+packet|pts=-1024|dts=-1024|duration=1024
+packet|pts=0|dts=0|duration=1024
+packet|pts=1024|dts=1024|duration=1024
+packet|pts=2048|dts=2048|duration=1024
+packet|pts=3072|dts=3072|duration=1024
+packet|pts=4096|dts=4096|duration=1024
+packet|pts=5120|dts=5120|duration=1024
+packet|pts=6144|dts=6144|duration=1024
+packet|pts=95232|dts=95232|duration=1024
+packet|pts=96256|dts=96256|duration=1024
+packet|pts=97280|dts=97280|duration=1024
+packet|pts=98304|dts=98304|duration=1024
+packet|pts=99328|dts=99328|duration=1024
+packet|pts=100352|dts=100352|duration=1024
+packet|pts=101376|dts=101376|duration=1024
+packet|pts=102400|dts=102400|duration=1984
 stream|nb_read_packets=102
-frame|pkt_pts=1058|pkt_dts=1058|best_effort_timestamp=1058|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=2082|pkt_dts=2082|best_effort_timestamp=2082|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=3106|pkt_dts=3106|best_effort_timestamp=3106|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=4130|pkt_dts=4130|best_effort_timestamp=4130|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=5154|pkt_dts=5154|best_effort_timestamp=5154|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=6178|pkt_dts=6178|best_effort_timestamp=6178|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=7202|pkt_dts=7202|best_effort_timestamp=7202|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=8226|pkt_dts=8226|best_effort_timestamp=8226|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=97314|pkt_dts=97314|best_effort_timestamp=97314|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=98338|pkt_dts=98338|best_effort_timestamp=98338|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=99362|pkt_dts=99362|best_effort_timestamp=99362|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=100386|pkt_dts=100386|best_effort_timestamp=100386|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=101410|pkt_dts=101410|best_effort_timestamp=101410|pkt_duration=1024|nb_samples=1024
-frame|pkt_pts=102434|pkt_dts=102434|best_effort_timestamp=102434|pkt_duration=1024|nb_samples=1024

[FFmpeg-devel] [PATCHv5 3/3] avformat/mov: read start_pad from edit list start time if codec is aac

[Marton Balint]

Related to ticket #2324, #2325.

Stream duration still need to be fixed...

Signed-off-by: Marton Balint 
---
 libavformat/mov.c| 3 +++
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 8 
 tests/ref/fate/gaplessenc-pcm-to-mov-aac | 8 
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4f446ba..3fa8fcc 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2688,6 +2688,9 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 st->codec->has_b_frames = 1;
 }
 }
+
+if (!unsupported && st->codec->codec_id == AV_CODEC_ID_AAC && 
start_time > 0)
+sc->start_pad = start_time;
 }
 
 /* only use old uncompressed audio chunk demuxing when stts specifies it */
diff --git a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac 
b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
index 564c212..aacb058 100644
--- a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
+++ b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
@@ -1,10 +1,10 @@
 [STREAM]
 index=0
-start_pts=-1024
+start_pts=0
 duration_ts=104384
 [/STREAM]
 [FORMAT]
-start_time=-0.023220
+start_time=0.00
 duration=2.367000
 [/FORMAT]
 packet|pts=-1024|dts=-1024|duration=1024
@@ -24,7 +24,6 @@ packet|pts=100352|dts=100352|duration=1024
 packet|pts=101376|dts=101376|duration=1024
 packet|pts=102400|dts=102400|duration=1984
 stream|nb_read_packets=102
-frame|pkt_pts=-1024|pkt_dts=-1024|best_effort_timestamp=-1024|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=1024
@@ -32,6 +31,7 @@ 
frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_
 
frame|pkt_pts=4096|pkt_dts=4096|best_effort_timestamp=4096|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=5120|pkt_dts=5120|best_effort_timestamp=5120|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=6144|pkt_dts=6144|best_effort_timestamp=6144|pkt_duration=1024|nb_samples=1024
+frame|pkt_pts=7168|pkt_dts=7168|best_effort_timestamp=7168|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=95232|pkt_dts=95232|best_effort_timestamp=95232|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=96256|pkt_dts=96256|best_effort_timestamp=96256|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=97280|pkt_dts=97280|best_effort_timestamp=97280|pkt_duration=1024|nb_samples=1024
@@ -40,4 +40,4 @@ 
frame|pkt_pts=99328|pkt_dts=99328|best_effort_timestamp=99328|pkt_duration=1024|
 
frame|pkt_pts=100352|pkt_dts=100352|best_effort_timestamp=100352|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=101376|pkt_dts=101376|best_effort_timestamp=101376|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=102400|pkt_dts=102400|best_effort_timestamp=102400|pkt_duration=1984|nb_samples=1024
-stream|nb_read_frames=102
+stream|nb_read_frames=101
diff --git a/tests/ref/fate/gaplessenc-pcm-to-mov-aac 
b/tests/ref/fate/gaplessenc-pcm-to-mov-aac
index b71d094..05dff6e 100644
--- a/tests/ref/fate/gaplessenc-pcm-to-mov-aac
+++ b/tests/ref/fate/gaplessenc-pcm-to-mov-aac
@@ -1,10 +1,10 @@
 [STREAM]
 index=0
-start_pts=-1024
+start_pts=0
 duration_ts=530224
 [/STREAM]
 [FORMAT]
-start_time=-0.023220
+start_time=0.00
 duration=12.024000
 [/FORMAT]
 packet|pts=-1024|dts=-1024|duration=1024
@@ -24,7 +24,6 @@ packet|pts=526336|dts=526336|duration=1024
 packet|pts=527360|dts=527360|duration=1024
 packet|pts=528384|dts=528384|duration=1840
 stream|nb_read_packets=518
-frame|pkt_pts=-1024|pkt_dts=-1024|best_effort_timestamp=-1024|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=1024
@@ -32,6 +31,7 @@ 
frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_
 
frame|pkt_pts=4096|pkt_dts=4096|best_effort_timestamp=4096|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=5120|pkt_dts=5120|best_effort_timestamp=5120|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=6144|pkt_dts=6144|best_effort_timestamp=6144|pkt_duration=1024|nb_samples=1024
+frame|pkt_pts=7168|pkt_dts=7168|best_effort_timestamp=7168|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=521216|pkt_dts=521216|best_effort_timestamp=521216|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=522240|pkt_dts=522240|best_effort_timestamp=522240|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=523264|pkt_dts=523264|best_effort_timestamp=523264|pkt_duration=1024|nb_samples=1024
@@ -40,4 +40,4 @@ 
frame|pkt_pts=525312|pkt_dts=525312|best_effort_timestamp=525312|pkt_duration=10
 

[FFmpeg-devel] [PATCHv5 1/3] tests/gapless: add gapless aac tests

[Marton Balint]

Signed-off-by: Marton Balint 
---
 tests/fate-run.sh| 28 ++
 tests/fate/gapless.mak   | 28 +-
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 43 
 tests/ref/fate/gaplessenc-pcm-to-mov-aac | 43 
 tests/ref/fate/gaplessinfo-itunes1   | 43 
 tests/ref/fate/gaplessinfo-itunes2   | 43 
 6 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/gaplessenc-itunes-to-ipod-aac
 create mode 100644 tests/ref/fate/gaplessenc-pcm-to-mov-aac
 create mode 100644 tests/ref/fate/gaplessinfo-itunes1
 create mode 100644 tests/ref/fate/gaplessinfo-itunes2

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 16087cb..5631267 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -96,6 +96,21 @@ probeframes(){
 run ffprobe${PROGSUF} -show_frames -v 0 "$@"
 }
 
+probegaplessinfo(){
+filename="$1"
+shift
+run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries 
format=start_time,duration:stream=index,start_pts,duration_ts -v 0 "$filename" 
"$@"
+pktfile1="${outdir}/${test}.pkts"
+framefile1="${outdir}/${test}.frames"
+cleanfiles="$cleanfiles $pktfile1 $framefile1"
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
-count_packets -show_entries packet=pts,dts,duration:stream=nb_read_packets -v 
0 "$filename" "$@" > "$pktfile1"
+head -n 8 "$pktfile1"
+tail -n 9 "$pktfile1"
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
-count_frames -show_entries 
frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames
 -v 0 "$filename" "$@" > "$framefile1"
+head -n 8 "$framefile1"
+tail -n 9 "$framefile1"
+}
+
 ffmpeg(){
 dec_opts="-hwaccel $hwaccel -threads $threads -thread_type $thread_type"
 ffmpeg_args="-nostdin -nostats -cpuflags $cpuflags"
@@ -249,6 +264,19 @@ gapless(){
 do_md5sum $decfile3
 }
 
+gaplessenc(){
+sample=$(target_path $1)
+format=$2
+codec=$3
+
+file1="${outdir}/${test}.out-1"
+cleanfiles="$cleanfiles $file1"
+
+# test data after reencoding
+ffmpeg -i "$sample" -flags +bitexact -fflags +bitexact -map 0:a -c:a 
$codec -f $format -y "$file1"
+probegaplessinfo "$file1"
+}
+
 concat(){
 template=$1
 sample=$2
diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
index 2fb005f..8cae3ac 100644
--- a/tests/fate/gapless.mak
+++ b/tests/fate/gapless.mak
@@ -3,5 +3,31 @@ fate-gapless-mp3: CMD = gapless 
$(TARGET_SAMPLES)/gapless/gapless.mp3
 
 FATE_GAPLESS = $(FATE_GAPLESS-yes)
 
+FATE_GAPLESSINFO_PROBE-$(call DEMDEC, MOV, AAC) += fate-gaplessinfo-itunes1
+fate-gaplessinfo-itunes1: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gaplessinfo-itunes1: CMD = probegaplessinfo 
$(TARGET_SAMPLES)/cover_art/Owner-iTunes_9.0.3.15.m4a
+
+FATE_GAPLESSINFO_PROBE-$(call DEMDEC, MOV, AAC) += fate-gaplessinfo-itunes2
+fate-gaplessinfo-itunes2: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gaplessinfo-itunes2: CMD = probegaplessinfo 
$(TARGET_SAMPLES)/gapless/102400samples_qt-lc-aac.m4a
+
+FATE_GAPLESSENC_PROBE-$(call ENCDEC, AAC, MOV) += 
fate-gaplessenc-itunes-to-ipod-aac
+fate-gaplessenc-itunes-to-ipod-aac: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gaplessenc-itunes-to-ipod-aac: CMD = gaplessenc 
$(TARGET_SAMPLES)/gapless/102400samples_qt-lc-aac.m4a ipod aac
+
+FATE_GAPLESSENC_PROBE-$(call ENCDEC, AAC, MOV) += 
fate-gaplessenc-pcm-to-mov-aac
+fate-gaplessenc-pcm-to-mov-aac: $(AREF)
+fate-gaplessenc-pcm-to-mov-aac: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gaplessenc-pcm-to-mov-aac: CMD = gaplessenc $(AREF) mov aac
+
+FATE_GAPLESSINFO-$(CONFIG_FFPROBE) = $(FATE_GAPLESSINFO_PROBE-yes)
+FATE_GAPLESSINFO = $(FATE_GAPLESSINFO-yes)
+
+FATE_GAPLESSENC-$(CONFIG_FFPROBE) = $(FATE_GAPLESSENC_PROBE-yes)
+FATE_GAPLESSENC = $(FATE_GAPLESSENC-yes)
+
 FATE_SAMPLES_AVCONV += $(FATE_GAPLESS)
-fate-gapless: $(FATE_GAPLESS)
+FATE_SAMPLES_AVCONV += $(FATE_GAPLESSINFO)
+FATE_SAMPLES_AVCONV += $(FATE_GAPLESSENC)
+
+fate-gapless: $(FATE_GAPLESS) $(FATE_GAPLESSINFO) $(FATE_GAPLESSENC)
diff --git a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac 
b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
new file mode 100644
index 000..1d4262f
--- /dev/null
+++ b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
@@ -0,0 +1,43 @@
+[STREAM]
+index=0
+start_pts=1058
+duration_ts=104384
+[/STREAM]
+[FORMAT]
+start_time=0.023991
+duration=2.367000
+[/FORMAT]
+packet|pts=1058|dts=1058|duration=1024
+packet|pts=2082|dts=2082|duration=1024
+packet|pts=3106|dts=3106|duration=1024
+packet|pts=4130|dts=4130|duration=1024
+packet|pts=5154|dts=5154|duration=1024
+packet|pts=6178|dts=6178|duration=1024
+packet|pts=7202|dts=7202|duration=1024
+packet|pts=8226|dts=8226|duration=1024
+packet|pts=97314|dts=97314|duration=1024
+packet|pts=98338|dts=98338|duration=1024
+packet|pts=99362|dts=99362|duration=1024

[FFmpeg-devel] [PATCHv4 2/3] avformat/utils: increase detected start_time with skip_samples

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/utils.c| 10 --
 tests/ref/fate/gaplessinfo-itunes1 |  4 ++--
 tests/ref/fate/gaplessinfo-itunes2 |  4 ++--
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index e0aea87..ccb76d2 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -971,8 +971,11 @@ static void update_initial_timestamps(AVFormatContext *s, 
int stream_index,
 if (is_relative(pktl->pkt.dts))
 pktl->pkt.dts += shift;
 
-if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts != 
AV_NOPTS_VALUE)
+if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts != 
AV_NOPTS_VALUE) {
 st->start_time = pktl->pkt.pts;
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO && 
st->codec->sample_rate)
+st->start_time += av_rescale_q(st->skip_samples, 
(AVRational){1, st->codec->sample_rate}, st->time_base);
+}
 
 if (pktl->pkt.pts != AV_NOPTS_VALUE && delay <= MAX_REORDER_DELAY && 
has_decode_delay_been_guessed(st)) {
 pts_buffer[0] = pktl->pkt.pts;
@@ -983,8 +986,11 @@ static void update_initial_timestamps(AVFormatContext *s, 
int stream_index,
 }
 }
 
-if (st->start_time == AV_NOPTS_VALUE)
+if (st->start_time == AV_NOPTS_VALUE) {
 st->start_time = pts;
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO && 
st->codec->sample_rate)
+st->start_time += av_rescale_q(st->skip_samples, (AVRational){1, 
st->codec->sample_rate}, st->time_base);
+}
 }
 
 static void update_initial_durations(AVFormatContext *s, AVStream *st,
diff --git a/tests/ref/fate/gaplessinfo-itunes1 
b/tests/ref/fate/gaplessinfo-itunes1
index a18879b..717a2a8 100644
--- a/tests/ref/fate/gaplessinfo-itunes1
+++ b/tests/ref/fate/gaplessinfo-itunes1
@@ -1,10 +1,10 @@
 [STREAM]
 index=0
-start_pts=0
+start_pts=2112
 duration_ts=1294336
 [/STREAM]
 [FORMAT]
-start_time=0.00
+start_time=0.047889
 duration=29.350023
 [/FORMAT]
 packet|pts=0|dts=0|duration=1024
diff --git a/tests/ref/fate/gaplessinfo-itunes2 
b/tests/ref/fate/gaplessinfo-itunes2
index c81dddf..be15113 100644
--- a/tests/ref/fate/gaplessinfo-itunes2
+++ b/tests/ref/fate/gaplessinfo-itunes2
@@ -1,10 +1,10 @@
 [STREAM]
 index=0
-start_pts=0
+start_pts=2112
 duration_ts=105472
 [/STREAM]
 [FORMAT]
-start_time=0.00
+start_time=0.047891
 duration=2.391655
 [/FORMAT]
 packet|pts=0|dts=0|duration=1024
-- 
2.6.2

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

[FFmpeg-devel] [PATCHv4 3/3] avformat/mov: read start_pad from edit list start time if codec is aac

[Marton Balint]

Related to ticket #2324, #2325.

Stream duration still need to be fixed...

Signed-off-by: Marton Balint 
---
 libavformat/mov.c| 3 +++
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 8 
 tests/ref/fate/gaplessenc-pcm-to-mov-aac | 8 
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4f446ba..3fa8fcc 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2688,6 +2688,9 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 st->codec->has_b_frames = 1;
 }
 }
+
+if (!unsupported && st->codec->codec_id == AV_CODEC_ID_AAC && 
start_time > 0)
+sc->start_pad = start_time;
 }
 
 /* only use old uncompressed audio chunk demuxing when stts specifies it */
diff --git a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac 
b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
index b71d094..05dff6e 100644
--- a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
+++ b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
@@ -1,10 +1,10 @@
 [STREAM]
 index=0
-start_pts=-1024
+start_pts=0
 duration_ts=530224
 [/STREAM]
 [FORMAT]
-start_time=-0.023220
+start_time=0.00
 duration=12.024000
 [/FORMAT]
 packet|pts=-1024|dts=-1024|duration=1024
@@ -24,7 +24,6 @@ packet|pts=526336|dts=526336|duration=1024
 packet|pts=527360|dts=527360|duration=1024
 packet|pts=528384|dts=528384|duration=1840
 stream|nb_read_packets=518
-frame|pkt_pts=-1024|pkt_dts=-1024|best_effort_timestamp=-1024|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=1024
@@ -32,6 +31,7 @@ 
frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_
 
frame|pkt_pts=4096|pkt_dts=4096|best_effort_timestamp=4096|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=5120|pkt_dts=5120|best_effort_timestamp=5120|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=6144|pkt_dts=6144|best_effort_timestamp=6144|pkt_duration=1024|nb_samples=1024
+frame|pkt_pts=7168|pkt_dts=7168|best_effort_timestamp=7168|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=521216|pkt_dts=521216|best_effort_timestamp=521216|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=522240|pkt_dts=522240|best_effort_timestamp=522240|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=523264|pkt_dts=523264|best_effort_timestamp=523264|pkt_duration=1024|nb_samples=1024
@@ -40,4 +40,4 @@ 
frame|pkt_pts=525312|pkt_dts=525312|best_effort_timestamp=525312|pkt_duration=10
 
frame|pkt_pts=526336|pkt_dts=526336|best_effort_timestamp=526336|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=527360|pkt_dts=527360|best_effort_timestamp=527360|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=528384|pkt_dts=528384|best_effort_timestamp=528384|pkt_duration=1840|nb_samples=1024
-stream|nb_read_frames=518
+stream|nb_read_frames=517
diff --git a/tests/ref/fate/gaplessenc-pcm-to-mov-aac 
b/tests/ref/fate/gaplessenc-pcm-to-mov-aac
index b71d094..05dff6e 100644
--- a/tests/ref/fate/gaplessenc-pcm-to-mov-aac
+++ b/tests/ref/fate/gaplessenc-pcm-to-mov-aac
@@ -1,10 +1,10 @@
 [STREAM]
 index=0
-start_pts=-1024
+start_pts=0
 duration_ts=530224
 [/STREAM]
 [FORMAT]
-start_time=-0.023220
+start_time=0.00
 duration=12.024000
 [/FORMAT]
 packet|pts=-1024|dts=-1024|duration=1024
@@ -24,7 +24,6 @@ packet|pts=526336|dts=526336|duration=1024
 packet|pts=527360|dts=527360|duration=1024
 packet|pts=528384|dts=528384|duration=1840
 stream|nb_read_packets=518
-frame|pkt_pts=-1024|pkt_dts=-1024|best_effort_timestamp=-1024|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=1024
@@ -32,6 +31,7 @@ 
frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_
 
frame|pkt_pts=4096|pkt_dts=4096|best_effort_timestamp=4096|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=5120|pkt_dts=5120|best_effort_timestamp=5120|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=6144|pkt_dts=6144|best_effort_timestamp=6144|pkt_duration=1024|nb_samples=1024
+frame|pkt_pts=7168|pkt_dts=7168|best_effort_timestamp=7168|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=521216|pkt_dts=521216|best_effort_timestamp=521216|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=522240|pkt_dts=522240|best_effort_timestamp=522240|pkt_duration=1024|nb_samples=1024
 
frame|pkt_pts=523264|pkt_dts=523264|best_effort_timestamp=523264|pkt_duration=1024|nb_samples=1024
@@ -40,4 +40,4 @@ 
frame|pkt_pts=525312|pkt_dts=525312|best_effort_timestamp=525312|pkt_duration=10
 

[FFmpeg-devel] [PATCHv4 1/3] tests/gapless: add gapless aac tests

[Marton Balint]

Signed-off-by: Marton Balint 
---
 tests/fate-run.sh| 28 ++
 tests/fate/gapless.mak   | 29 ++-
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 43 
 tests/ref/fate/gaplessenc-pcm-to-mov-aac | 43 
 tests/ref/fate/gaplessinfo-itunes1   | 43 
 tests/ref/fate/gaplessinfo-itunes2   | 43 
 6 files changed, 228 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/gaplessenc-itunes-to-ipod-aac
 create mode 100644 tests/ref/fate/gaplessenc-pcm-to-mov-aac
 create mode 100644 tests/ref/fate/gaplessinfo-itunes1
 create mode 100644 tests/ref/fate/gaplessinfo-itunes2

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 16087cb..5631267 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -96,6 +96,21 @@ probeframes(){
 run ffprobe${PROGSUF} -show_frames -v 0 "$@"
 }
 
+probegaplessinfo(){
+filename="$1"
+shift
+run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries 
format=start_time,duration:stream=index,start_pts,duration_ts -v 0 "$filename" 
"$@"
+pktfile1="${outdir}/${test}.pkts"
+framefile1="${outdir}/${test}.frames"
+cleanfiles="$cleanfiles $pktfile1 $framefile1"
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
-count_packets -show_entries packet=pts,dts,duration:stream=nb_read_packets -v 
0 "$filename" "$@" > "$pktfile1"
+head -n 8 "$pktfile1"
+tail -n 9 "$pktfile1"
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
-count_frames -show_entries 
frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames
 -v 0 "$filename" "$@" > "$framefile1"
+head -n 8 "$framefile1"
+tail -n 9 "$framefile1"
+}
+
 ffmpeg(){
 dec_opts="-hwaccel $hwaccel -threads $threads -thread_type $thread_type"
 ffmpeg_args="-nostdin -nostats -cpuflags $cpuflags"
@@ -249,6 +264,19 @@ gapless(){
 do_md5sum $decfile3
 }
 
+gaplessenc(){
+sample=$(target_path $1)
+format=$2
+codec=$3
+
+file1="${outdir}/${test}.out-1"
+cleanfiles="$cleanfiles $file1"
+
+# test data after reencoding
+ffmpeg -i "$sample" -flags +bitexact -fflags +bitexact -map 0:a -c:a 
$codec -f $format -y "$file1"
+probegaplessinfo "$file1"
+}
+
 concat(){
 template=$1
 sample=$2
diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
index 2fb005f..42941b1 100644
--- a/tests/fate/gapless.mak
+++ b/tests/fate/gapless.mak
@@ -3,5 +3,32 @@ fate-gapless-mp3: CMD = gapless 
$(TARGET_SAMPLES)/gapless/gapless.mp3
 
 FATE_GAPLESS = $(FATE_GAPLESS-yes)
 
+FATE_GAPLESSINFO_PROBE-$(call DEMDEC, MOV, AAC) += fate-gaplessinfo-itunes1
+fate-gaplessinfo-itunes1: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gaplessinfo-itunes1: CMD = probegaplessinfo 
$(TARGET_SAMPLES)/cover_art/Owner-iTunes_9.0.3.15.m4a
+
+FATE_GAPLESSINFO_PROBE-$(call DEMDEC, MOV, AAC) += fate-gaplessinfo-itunes2
+fate-gaplessinfo-itunes2: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gaplessinfo-itunes2: CMD = probegaplessinfo 
$(TARGET_SAMPLES)/gapless/102400samples_qt-lc-aac.m4a
+
+FATE_GAPLESSENC_PROBE-$(call ENCDEC, AAC, MOV) += 
fate-gaplessenc-itunes-to-ipod-aac
+fate-gaplessenc-itunes-to-ipod-aac: $(AREF)
+fate-gaplessenc-itunes-to-ipod-aac: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gaplessenc-itunes-to-ipod-aac: CMD = gaplessenc $(AREF) ipod aac
+
+FATE_GAPLESSENC_PROBE-$(call ENCDEC, AAC, MOV) += 
fate-gaplessenc-pcm-to-mov-aac
+fate-gaplessenc-pcm-to-mov-aac: $(AREF)
+fate-gaplessenc-pcm-to-mov-aac: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gaplessenc-pcm-to-mov-aac: CMD = gaplessenc $(AREF) mov aac
+
+FATE_GAPLESSINFO-$(CONFIG_FFPROBE) = $(FATE_GAPLESSINFO_PROBE-yes)
+FATE_GAPLESSINFO = $(FATE_GAPLESSINFO-yes)
+
+FATE_GAPLESSENC-$(CONFIG_FFPROBE) = $(FATE_GAPLESSENC_PROBE-yes)
+FATE_GAPLESSENC = $(FATE_GAPLESSENC-yes)
+
 FATE_SAMPLES_AVCONV += $(FATE_GAPLESS)
-fate-gapless: $(FATE_GAPLESS)
+FATE_SAMPLES_AVCONV += $(FATE_GAPLESSINFO)
+FATE_SAMPLES_AVCONV += $(FATE_GAPLESSENC)
+
+fate-gapless: $(FATE_GAPLESS) $(FATE_GAPLESSINFO) $(FATE_GAPLESSENC)
diff --git a/tests/ref/fate/gaplessenc-itunes-to-ipod-aac 
b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
new file mode 100644
index 000..b71d094
--- /dev/null
+++ b/tests/ref/fate/gaplessenc-itunes-to-ipod-aac
@@ -0,0 +1,43 @@
+[STREAM]
+index=0
+start_pts=-1024
+duration_ts=530224
+[/STREAM]
+[FORMAT]
+start_time=-0.023220
+duration=12.024000
+[/FORMAT]
+packet|pts=-1024|dts=-1024|duration=1024
+packet|pts=0|dts=0|duration=1024
+packet|pts=1024|dts=1024|duration=1024
+packet|pts=2048|dts=2048|duration=1024
+packet|pts=3072|dts=3072|duration=1024
+packet|pts=4096|dts=4096|duration=1024
+packet|pts=5120|dts=5120|duration=1024
+packet|pts=6144|dts=6144|duration=1024
+packet|pts=521216|dts=521216|duration=1024
+packet|pts=522240|dts=522240|duration=1024

Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[Thilo Borgmann]

Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
> Add coreimage filter for OSX.

Should now also work with Linux based configure.

-Thilo
From af0bbaebb1a04be203338fa7bf199c26a7dfa3df Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sun, 13 Mar 2016 00:35:25 +0100
Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
 on OSX.

---
 Changelog  |   1 +
 MAINTAINERS|   1 +
 configure  |   2 +
 doc/filters.texi   |  67 ++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_coreimage.m | 553 +
 7 files changed, 626 insertions(+)
 create mode 100644 libavfilter/vf_coreimage.m

diff --git a/Changelog b/Changelog
index 1f57f5e..5053a86 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
 - ciescope filter
 - protocol blacklisting API
 - MediaCodec H264 decoding
+- coreimage filter (GPU based image filtering on OSX)
 
 
 version 3.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 531c21d..a993a67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -370,6 +370,7 @@ Filters:
   vf_colorbalance.c Paul B Mahol
   vf_colorkey.c Timo Rothenpieler
   vf_colorlevels.c  Paul B Mahol
+  vf_coreimage.mThilo Borgmann
   vf_deband.c   Paul B Mahol
   vf_dejudder.c Nicholas Robbins
   vf_delogo.c   Jean Delvare (CC )
diff --git a/configure b/configure
index 1b189328..da51e06 100755
--- a/configure
+++ b/configure
@@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
 frei0r_src_filter_extralibs='$ldl'
 ladspa_filter_extralibs='$ldl'
 nvenc_encoder_extralibs='$ldl'
+coreimage_filter_extralibs="-framework QuartzCore -framework AppKit -framework 
OpenGL"
 
 if ! disabled network; then
 check_func getaddrinfo $network_extralibs
@@ -5483,6 +5484,7 @@ enabled avisynth  && { { check_lib2 "windows.h" 
LoadLibrary; } ||
die "ERROR: LoadLibrary/dlopen not found for 
avisynth"; }
 enabled cuda  && check_lib cuda.h cuInit -lcuda
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
+enabled coreimage_filter  && { check_header_objcc QuartzCore/CoreImage.h || 
disable coreimage_filter; }
 enabled decklink  && { check_header DeckLinkAPI.h || die "ERROR: 
DeckLinkAPI.h header not found"; }
 enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h 
header not found"; }
 enabled gmp   && require2 gmp gmp.h mpz_export -lgmp
diff --git a/doc/filters.texi b/doc/filters.texi
index d5d619e..7fdbe61 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4955,6 +4955,73 @@ convolution="-2 -1 0 -1 1 1 0 1 2:-2 -1 0 -1 1 1 0 1 
2:-2 -1 0 -1 1 1 0 1 2:-2 -
 Copy the input source unchanged to the output. This is mainly useful for
 testing purposes.
 
+@anchor{coreimage}
+@section coreimage
+
+Video filtering on GPU using Apple's CoreImage API on OSX.
+
+Hardware acceleration is based on an OpenGL context. Usually, this means it is 
processed by video hardware. However, software-based OpenGL implementations 
exist which means there is no guarantee for hardware processing. It depends on 
the respective OSX.
+
+There are many filters and image generators provided by Apple that come with a 
large variety of options. The filter has to be referenced by its name along 
with its options.
+
+The coreimage filter accepts the following options:
+@table @option
+@item list_filters
+List all available filters along with all their respective options as well as 
possible minimum and maximum values along with the default values.
+@example
+coreimage=list_filters=true
+@end example
+
+@item filter
+Specifiy all filters by their respective name and options.
+Use @option{list_filters} to determine all valid filter names and options.
+Numerical options are specified by a float value and are automatically clamped 
to their respective value range.
+Vector and color options have to be specified by a list of space separated 
float values. Character escaping has to be done.
+A special option name @code{default} is available to use default options for a 
filter.
+It is required to specify either @code{default} or at least one of the filter 
options.
+All omitted options are used with their default values.
+The syntax of the filter string is as follows:
+@example
+filter=@=[@=][@...][#@=[@=][@...]]
+@end example
+@end table
+
+Several filters can be chained for successive processing without GPU-HOST 
transfers allowing for fast processing of complex filter chains.
+Currently, only filters with zero (generators) or exactly one (filters) input 
image and one output image are supported.
+Also, transition filters are not yet usable as intended.
+
+Some filters generate 

Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[Thilo Borgmann]

Am 13.03.16 um 00:29 schrieb James Almer:
> On 3/12/2016 7:59 PM, Thilo Borgmann wrote:
>> Am 12.03.16 um 23:45 schrieb James Almer:
 On 3/12/2016 7:09 PM, Thilo Borgmann wrote:
>> Am 12.03.16 um 21:45 schrieb Michael Niedermayer:
>> On Sat, Mar 12, 2016 at 03:19:11PM +0100, Thilo Borgmann wrote:
>> Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
>> [...]
>> also breaks build on linux
>> ./configure && make -j12
>> ...
>> libavfilter/vaf_spectrumsynth.c:434:9: warning: ‘ret’ may be used 
>> uninitialized in this function [-Wuninitialized]
>> CC  libavfilter/vf_copy.o
>> OBJCC   libavfilter/vf_coreimage.o
>> gcc: error trying to exec 'cc1obj': execvp: No such file or directory
>> make: *** [libavfilter/vf_coreimage.o] Error 1
>> make: *** Waiting for unfinished jobs
>> Should be fixed in attached patch.

 No, it isn't. vf_coreimage must depend on coreimage, otherwise it will be 
 enabled for
 every platform.
 Also, coreimage is not a component listed in any list, so it's always 
 disabled. Look
 for example at chromaprint to get an idea of what's missing.
>> I'm sorry, I've no linux right now to test it on...
>> coreimage is no external lib, I don't think chromaprint analogies would fit.
>> It is more like avfoundation. However, I think I made one more mistake
>> that has been changed.
>>
>> Please test again the attached patch.
>>
>> Thanks!
>>
>> -Thilo
>>
>>
>> 0002-lavf-Add-coreimage-filter-for-GPU-based-image-filter.patch
>>
>>
>> From 76d67f19f1f537ca20ee86047d318558fe3a36cd Mon Sep 17 00:00:00 2001
>> From: Thilo Borgmann 
>> Date: Sat, 12 Mar 2016 23:55:50 +0100
>> Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
>>  on OSX.
>>
>> ---
>>  Changelog  |   1 +
>>  MAINTAINERS|   1 +
>>  configure  |   2 +
>>  doc/filters.texi   |  67 ++
>>  libavfilter/Makefile   |   1 +
>>  libavfilter/allfilters.c   |   1 +
>>  libavfilter/vf_coreimage.m | 553 
>> +
>>  7 files changed, 626 insertions(+)
>>  create mode 100644 libavfilter/vf_coreimage.m
>>
>> diff --git a/Changelog b/Changelog
>> index 1f57f5e..5053a86 100644
>> --- a/Changelog
>> +++ b/Changelog
>> @@ -12,6 +12,7 @@ version :
>>  - ciescope filter
>>  - protocol blacklisting API
>>  - MediaCodec H264 decoding
>> +- coreimage filter (GPU based image filtering on OSX)
>>  
>>  
>>  version 3.0:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 531c21d..a993a67 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -370,6 +370,7 @@ Filters:
>>vf_colorbalance.c Paul B Mahol
>>vf_colorkey.c Timo Rothenpieler
>>vf_colorlevels.c  Paul B Mahol
>> +  vf_coreimage.mThilo Borgmann
>>vf_deband.c   Paul B Mahol
>>vf_dejudder.c Nicholas Robbins
>>vf_delogo.c   Jean Delvare (CC 
>> )
>> diff --git a/configure b/configure
>> index 1b189328..d21d22d 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
>>  frei0r_src_filter_extralibs='$ldl'
>>  ladspa_filter_extralibs='$ldl'
>>  nvenc_encoder_extralibs='$ldl'
>> +coreimage_filter_extralibs="-framework QuartzCore -framework AppKit 
>> -framework OpenGL"
>>  
>>  if ! disabled network; then
>>  check_func getaddrinfo $network_extralibs
>> @@ -5483,6 +5484,7 @@ enabled avisynth  && { { check_lib2 
>> "windows.h" LoadLibrary; } ||
>> die "ERROR: LoadLibrary/dlopen not found for 
>> avisynth"; }
>>  enabled cuda  && check_lib cuda.h cuInit -lcuda
>>  enabled chromaprint   && require chromaprint chromaprint.h 
>> chromaprint_get_version -lchromaprint
>> +enabled coreimage_filter  && { check_header_objcc CoreImage/CoreImage.h || 
>> disable avfoundation_indev; }
> 
> I assume avfoundation_indev here is a copy-paste mistake? But yes, it
> should be ok after changing that into coreimage_filter.

Indeed and found another bug. It never really checked on OSX.

In the mean time I could test Linux & OSX, now it seems to work.
Will attach the works-for-me patch in a seperate mail.

Thanks!

-Thilo

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

Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_decimate: Use the correct frame in difference calculation

[Michael Niedermayer]

On Wed, Dec 16, 2015 at 06:54:55PM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> Fixes Ticket4964
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/vf_decimate.c |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

patchset applied

[...]
-- 
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 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[James Almer]

On 3/12/2016 7:59 PM, Thilo Borgmann wrote:
> Am 12.03.16 um 23:45 schrieb James Almer:
>> > On 3/12/2016 7:09 PM, Thilo Borgmann wrote:
>>> >> Am 12.03.16 um 21:45 schrieb Michael Niedermayer:
>  On Sat, Mar 12, 2016 at 03:19:11PM +0100, Thilo Borgmann wrote:
>>> >> Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
>  [...]
>  also breaks build on linux
>  ./configure && make -j12
>  ...
>  libavfilter/vaf_spectrumsynth.c:434:9: warning: ‘ret’ may be used 
>  uninitialized in this function [-Wuninitialized]
>  CC  libavfilter/vf_copy.o
>  OBJCC   libavfilter/vf_coreimage.o
>  gcc: error trying to exec 'cc1obj': execvp: No such file or directory
>  make: *** [libavfilter/vf_coreimage.o] Error 1
>  make: *** Waiting for unfinished jobs
>>> >> Should be fixed in attached patch.
>> > 
>> > No, it isn't. vf_coreimage must depend on coreimage, otherwise it will be 
>> > enabled for
>> > every platform.
>> > Also, coreimage is not a component listed in any list, so it's always 
>> > disabled. Look
>> > for example at chromaprint to get an idea of what's missing.
> I'm sorry, I've no linux right now to test it on...
> coreimage is no external lib, I don't think chromaprint analogies would fit.
> It is more like avfoundation. However, I think I made one more mistake
> that has been changed.
> 
> Please test again the attached patch.
> 
> Thanks!
> 
> -Thilo
> 
> 
> 0002-lavf-Add-coreimage-filter-for-GPU-based-image-filter.patch
> 
> 
> From 76d67f19f1f537ca20ee86047d318558fe3a36cd Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann 
> Date: Sat, 12 Mar 2016 23:55:50 +0100
> Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
>  on OSX.
> 
> ---
>  Changelog  |   1 +
>  MAINTAINERS|   1 +
>  configure  |   2 +
>  doc/filters.texi   |  67 ++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vf_coreimage.m | 553 
> +
>  7 files changed, 626 insertions(+)
>  create mode 100644 libavfilter/vf_coreimage.m
> 
> diff --git a/Changelog b/Changelog
> index 1f57f5e..5053a86 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -12,6 +12,7 @@ version :
>  - ciescope filter
>  - protocol blacklisting API
>  - MediaCodec H264 decoding
> +- coreimage filter (GPU based image filtering on OSX)
>  
>  
>  version 3.0:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 531c21d..a993a67 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -370,6 +370,7 @@ Filters:
>vf_colorbalance.c Paul B Mahol
>vf_colorkey.c Timo Rothenpieler
>vf_colorlevels.c  Paul B Mahol
> +  vf_coreimage.mThilo Borgmann
>vf_deband.c   Paul B Mahol
>vf_dejudder.c Nicholas Robbins
>vf_delogo.c   Jean Delvare (CC )
> diff --git a/configure b/configure
> index 1b189328..d21d22d 100755
> --- a/configure
> +++ b/configure
> @@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
>  frei0r_src_filter_extralibs='$ldl'
>  ladspa_filter_extralibs='$ldl'
>  nvenc_encoder_extralibs='$ldl'
> +coreimage_filter_extralibs="-framework QuartzCore -framework AppKit 
> -framework OpenGL"
>  
>  if ! disabled network; then
>  check_func getaddrinfo $network_extralibs
> @@ -5483,6 +5484,7 @@ enabled avisynth  && { { check_lib2 "windows.h" 
> LoadLibrary; } ||
> die "ERROR: LoadLibrary/dlopen not found for 
> avisynth"; }
>  enabled cuda  && check_lib cuda.h cuInit -lcuda
>  enabled chromaprint   && require chromaprint chromaprint.h 
> chromaprint_get_version -lchromaprint
> +enabled coreimage_filter  && { check_header_objcc CoreImage/CoreImage.h || 
> disable avfoundation_indev; }

I assume avfoundation_indev here is a copy-paste mistake? But yes, it
should be ok after changing that into coreimage_filter.

>  enabled decklink  && { check_header DeckLinkAPI.h || die "ERROR: 
> DeckLinkAPI.h header not found"; }
>  enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h 
> header not found"; }
>  enabled gmp   && require2 gmp gmp.h mpz_export -lgmp

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

Re: [FFmpeg-devel] [PATCHv3 1/3] tests/gapless: add gapless aac tests

[Marton Balint]

On Sat, 12 Mar 2016, Michael Niedermayer wrote:


On Sat, Mar 12, 2016 at 02:49:10AM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 tests/fate-run.sh | 30 ++
 tests/fate/gapless.mak| 20 +-
 tests/ref/fate/gapless2-ipod-aac1 | 82 +++
 tests/ref/fate/gapless2-ipod-aac2 | 82 +++
 tests/ref/fate/gapless2-mov-aac   | 82 +++



i missed that but
is this writing into the fate samples directory ?
thats not good if it does, the directory may be read only and would
not get cleaned


You're right. I'll just rework the series once more, and will also 
separate the decode and the encode part of the tests, for better

readability.

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[Thilo Borgmann]

Am 12.03.16 um 23:45 schrieb James Almer:
> On 3/12/2016 7:09 PM, Thilo Borgmann wrote:
>> Am 12.03.16 um 21:45 schrieb Michael Niedermayer:
 On Sat, Mar 12, 2016 at 03:19:11PM +0100, Thilo Borgmann wrote:
>> Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
 [...]
 also breaks build on linux
 ./configure && make -j12
 ...
 libavfilter/vaf_spectrumsynth.c:434:9: warning: ‘ret’ may be used 
 uninitialized in this function [-Wuninitialized]
 CC  libavfilter/vf_copy.o
 OBJCC   libavfilter/vf_coreimage.o
 gcc: error trying to exec 'cc1obj': execvp: No such file or directory
 make: *** [libavfilter/vf_coreimage.o] Error 1
 make: *** Waiting for unfinished jobs
>> Should be fixed in attached patch.
> 
> No, it isn't. vf_coreimage must depend on coreimage, otherwise it will be 
> enabled for
> every platform.
> Also, coreimage is not a component listed in any list, so it's always 
> disabled. Look
> for example at chromaprint to get an idea of what's missing.

I'm sorry, I've no linux right now to test it on...
coreimage is no external lib, I don't think chromaprint analogies would fit.
It is more like avfoundation. However, I think I made one more mistake
that has been changed.

Please test again the attached patch.

Thanks!

-Thilo
From 76d67f19f1f537ca20ee86047d318558fe3a36cd Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 12 Mar 2016 23:55:50 +0100
Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
 on OSX.

---
 Changelog  |   1 +
 MAINTAINERS|   1 +
 configure  |   2 +
 doc/filters.texi   |  67 ++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_coreimage.m | 553 +
 7 files changed, 626 insertions(+)
 create mode 100644 libavfilter/vf_coreimage.m

diff --git a/Changelog b/Changelog
index 1f57f5e..5053a86 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
 - ciescope filter
 - protocol blacklisting API
 - MediaCodec H264 decoding
+- coreimage filter (GPU based image filtering on OSX)
 
 
 version 3.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 531c21d..a993a67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -370,6 +370,7 @@ Filters:
   vf_colorbalance.c Paul B Mahol
   vf_colorkey.c Timo Rothenpieler
   vf_colorlevels.c  Paul B Mahol
+  vf_coreimage.mThilo Borgmann
   vf_deband.c   Paul B Mahol
   vf_dejudder.c Nicholas Robbins
   vf_delogo.c   Jean Delvare (CC )
diff --git a/configure b/configure
index 1b189328..d21d22d 100755
--- a/configure
+++ b/configure
@@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
 frei0r_src_filter_extralibs='$ldl'
 ladspa_filter_extralibs='$ldl'
 nvenc_encoder_extralibs='$ldl'
+coreimage_filter_extralibs="-framework QuartzCore -framework AppKit -framework 
OpenGL"
 
 if ! disabled network; then
 check_func getaddrinfo $network_extralibs
@@ -5483,6 +5484,7 @@ enabled avisynth  && { { check_lib2 "windows.h" 
LoadLibrary; } ||
die "ERROR: LoadLibrary/dlopen not found for 
avisynth"; }
 enabled cuda  && check_lib cuda.h cuInit -lcuda
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
+enabled coreimage_filter  && { check_header_objcc CoreImage/CoreImage.h || 
disable avfoundation_indev; }
 enabled decklink  && { check_header DeckLinkAPI.h || die "ERROR: 
DeckLinkAPI.h header not found"; }
 enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h 
header not found"; }
 enabled gmp   && require2 gmp gmp.h mpz_export -lgmp
diff --git a/doc/filters.texi b/doc/filters.texi
index d5d619e..7fdbe61 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4955,6 +4955,73 @@ convolution="-2 -1 0 -1 1 1 0 1 2:-2 -1 0 -1 1 1 0 1 
2:-2 -1 0 -1 1 1 0 1 2:-2 -
 Copy the input source unchanged to the output. This is mainly useful for
 testing purposes.
 
+@anchor{coreimage}
+@section coreimage
+
+Video filtering on GPU using Apple's CoreImage API on OSX.
+
+Hardware acceleration is based on an OpenGL context. Usually, this means it is 
processed by video hardware. However, software-based OpenGL implementations 
exist which means there is no guarantee for hardware processing. It depends on 
the respective OSX.
+
+There are many filters and image generators provided by Apple that come with a 
large variety of options. The filter has to be referenced by its name along 
with its options.
+
+The coreimage filter accepts the following options:
+@table @option
+@item list_filters
+List all available filters along with all their respective options as well as 
possible minimum and maximum values along with 

Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[James Almer]

On 3/12/2016 7:09 PM, Thilo Borgmann wrote:
> Am 12.03.16 um 21:45 schrieb Michael Niedermayer:
>> > On Sat, Mar 12, 2016 at 03:19:11PM +0100, Thilo Borgmann wrote:
>>> >> Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
 >>> Add coreimage filter for OSX.
>>> >>
>>> >> Corrected patch attached.
>>> >>
>>> >> -Thilo
>>> >>
>> > 
>>> >>  Changelog  |1 
>>> >>  MAINTAINERS|1 
>>> >>  configure  |3 
>>> >>  doc/filters.texi   |   67 +
>>> >>  libavfilter/Makefile   |1 
>>> >>  libavfilter/allfilters.c   |1 
>>> >>  libavfilter/vf_coreimage.m |  553 
>>> >> +
>>> >>  7 files changed, 627 insertions(+)
>>> >> 2bc3194273f31211d7ee3effc2af6c6d1b393db2  
>>> >> 0002-lavf-Add-coreimage-filter-for-GPU-based-image-filter.patch
>>> >> From 124fb0ce2a30c965ec28c8fbff1c04a872f33bc6 Mon Sep 17 00:00:00 2001
>>> >> From: Thilo Borgmann 
>>> >> Date: Sat, 12 Mar 2016 15:18:04 +0100
>>> >> Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image 
>>> >> filtering
>>> >>  on OSX.
>>> >>
>>> >> ---
>>> >>  Changelog  |   1 +
>>> >>  MAINTAINERS|   1 +
>>> >>  configure  |   3 +
>>> >>  doc/filters.texi   |  67 ++
>>> >>  libavfilter/Makefile   |   1 +
>>> >>  libavfilter/allfilters.c   |   1 +
>>> >>  libavfilter/vf_coreimage.m | 553 
>>> >> +
>>> >>  7 files changed, 627 insertions(+)
>>> >>  create mode 100644 libavfilter/vf_coreimage.m
>>> >>
>>> >> diff --git a/Changelog b/Changelog
>>> >> index 1f57f5e..5053a86 100644
>>> >> --- a/Changelog
>>> >> +++ b/Changelog
>>> >> @@ -12,6 +12,7 @@ version :
>>> >>  - ciescope filter
>>> >>  - protocol blacklisting API
>>> >>  - MediaCodec H264 decoding
>>> >> +- coreimage filter (GPU based image filtering on OSX)
>>> >>  
>>> >>  
>>> >>  version 3.0:
>>> >> diff --git a/MAINTAINERS b/MAINTAINERS
>>> >> index 531c21d..a993a67 100644
>>> >> --- a/MAINTAINERS
>>> >> +++ b/MAINTAINERS
>>> >> @@ -370,6 +370,7 @@ Filters:
>>> >>vf_colorbalance.c Paul B Mahol
>>> >>vf_colorkey.c Timo Rothenpieler
>>> >>vf_colorlevels.c  Paul B Mahol
>>> >> +  vf_coreimage.mThilo Borgmann
>>> >>vf_deband.c   Paul B Mahol
>>> >>vf_dejudder.c Nicholas Robbins
>>> >>vf_delogo.c   Jean Delvare (CC 
>>> >> )
>>> >> diff --git a/configure b/configure
>>> >> index 1b189328..fe96215 100755
>>> >> --- a/configure
>>> >> +++ b/configure
>>> >> @@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
>>> >>  frei0r_src_filter_extralibs='$ldl'
>>> >>  ladspa_filter_extralibs='$ldl'
>>> >>  nvenc_encoder_extralibs='$ldl'
>>> >> +coreimage_filter_extralibs="-framework QuartzCore -framework AppKit 
>>> >> -framework OpenGL"
>>> >>  
>>> >>  if ! disabled network; then
>>> >>  check_func getaddrinfo $network_extralibs
>> > 
>>> >> @@ -5483,6 +5484,8 @@ enabled avisynth  && { { check_lib2 
>>> >> "windows.h" LoadLibrary; } ||
>>> >> die "ERROR: LoadLibrary/dlopen not found 
>>> >> for avisynth"; }
>>> >>  enabled cuda  && check_lib cuda.h cuInit -lcuda
>>> >>  enabled chromaprint   && require chromaprint chromaprint.h 
>>> >> chromaprint_get_version -lchromaprint
>>> >> +enabled coreimage && { check_header_oc CoreImage/CoreImage.h || 
>>> >> die "ERROR: CoreImage.h header not found"; }
>>> >> +#enabled coreimage && { check_lib2 CoreImage/CoreImage.h 
>>> >> CGGetActiveDisplayList -framework CoreImage; }
>> > 
>> > this looks suspect
> Removed.
> 
>> > also breaks build on linux
>> > ./configure && make -j12
>> > ...
>> > libavfilter/vaf_spectrumsynth.c:434:9: warning: ‘ret’ may be used 
>> > uninitialized in this function [-Wuninitialized]
>> > CC  libavfilter/vf_copy.o
>> > OBJCC   libavfilter/vf_coreimage.o
>> > gcc: error trying to exec 'cc1obj': execvp: No such file or directory
>> > make: *** [libavfilter/vf_coreimage.o] Error 1
>> > make: *** Waiting for unfinished jobs
> Should be fixed in attached patch.

No, it isn't. vf_coreimage must depend on coreimage, otherwise it will be 
enabled for
every platform.
Also, coreimage is not a component listed in any list, so it's always disabled. 
Look
for example at chromaprint to get an idea of what's missing.

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[Thilo Borgmann]

Am 12.03.16 um 21:45 schrieb Michael Niedermayer:
> On Sat, Mar 12, 2016 at 03:19:11PM +0100, Thilo Borgmann wrote:
>> Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
>>> Add coreimage filter for OSX.
>>
>> Corrected patch attached.
>>
>> -Thilo
>>
> 
>>  Changelog  |1 
>>  MAINTAINERS|1 
>>  configure  |3 
>>  doc/filters.texi   |   67 +
>>  libavfilter/Makefile   |1 
>>  libavfilter/allfilters.c   |1 
>>  libavfilter/vf_coreimage.m |  553 
>> +
>>  7 files changed, 627 insertions(+)
>> 2bc3194273f31211d7ee3effc2af6c6d1b393db2  
>> 0002-lavf-Add-coreimage-filter-for-GPU-based-image-filter.patch
>> From 124fb0ce2a30c965ec28c8fbff1c04a872f33bc6 Mon Sep 17 00:00:00 2001
>> From: Thilo Borgmann 
>> Date: Sat, 12 Mar 2016 15:18:04 +0100
>> Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
>>  on OSX.
>>
>> ---
>>  Changelog  |   1 +
>>  MAINTAINERS|   1 +
>>  configure  |   3 +
>>  doc/filters.texi   |  67 ++
>>  libavfilter/Makefile   |   1 +
>>  libavfilter/allfilters.c   |   1 +
>>  libavfilter/vf_coreimage.m | 553 
>> +
>>  7 files changed, 627 insertions(+)
>>  create mode 100644 libavfilter/vf_coreimage.m
>>
>> diff --git a/Changelog b/Changelog
>> index 1f57f5e..5053a86 100644
>> --- a/Changelog
>> +++ b/Changelog
>> @@ -12,6 +12,7 @@ version :
>>  - ciescope filter
>>  - protocol blacklisting API
>>  - MediaCodec H264 decoding
>> +- coreimage filter (GPU based image filtering on OSX)
>>  
>>  
>>  version 3.0:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 531c21d..a993a67 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -370,6 +370,7 @@ Filters:
>>vf_colorbalance.c Paul B Mahol
>>vf_colorkey.c Timo Rothenpieler
>>vf_colorlevels.c  Paul B Mahol
>> +  vf_coreimage.mThilo Borgmann
>>vf_deband.c   Paul B Mahol
>>vf_dejudder.c Nicholas Robbins
>>vf_delogo.c   Jean Delvare (CC 
>> )
>> diff --git a/configure b/configure
>> index 1b189328..fe96215 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
>>  frei0r_src_filter_extralibs='$ldl'
>>  ladspa_filter_extralibs='$ldl'
>>  nvenc_encoder_extralibs='$ldl'
>> +coreimage_filter_extralibs="-framework QuartzCore -framework AppKit 
>> -framework OpenGL"
>>  
>>  if ! disabled network; then
>>  check_func getaddrinfo $network_extralibs
> 
>> @@ -5483,6 +5484,8 @@ enabled avisynth  && { { check_lib2 
>> "windows.h" LoadLibrary; } ||
>> die "ERROR: LoadLibrary/dlopen not found for 
>> avisynth"; }
>>  enabled cuda  && check_lib cuda.h cuInit -lcuda
>>  enabled chromaprint   && require chromaprint chromaprint.h 
>> chromaprint_get_version -lchromaprint
>> +enabled coreimage && { check_header_oc CoreImage/CoreImage.h || die 
>> "ERROR: CoreImage.h header not found"; }
>> +#enabled coreimage && { check_lib2 CoreImage/CoreImage.h 
>> CGGetActiveDisplayList -framework CoreImage; }
> 
> this looks suspect

Removed.

> also breaks build on linux
> ./configure && make -j12
> ...
> libavfilter/vaf_spectrumsynth.c:434:9: warning: ‘ret’ may be used 
> uninitialized in this function [-Wuninitialized]
> CC  libavfilter/vf_copy.o
> OBJCC   libavfilter/vf_coreimage.o
> gcc: error trying to exec 'cc1obj': execvp: No such file or directory
> make: *** [libavfilter/vf_coreimage.o] Error 1
> make: *** Waiting for unfinished jobs

Should be fixed in attached patch.

-Thilo

From 3238a251ddd10dce64ed27abf30cf5d4b78f1b87 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 12 Mar 2016 22:53:33 +0100
Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
 on OSX.

---
 Changelog  |   1 +
 MAINTAINERS|   1 +
 configure  |   2 +
 doc/filters.texi   |  67 ++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_coreimage.m | 553 +
 7 files changed, 626 insertions(+)
 create mode 100644 libavfilter/vf_coreimage.m

diff --git a/Changelog b/Changelog
index 1f57f5e..5053a86 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
 - ciescope filter
 - protocol blacklisting API
 - MediaCodec H264 decoding
+- coreimage filter (GPU based image filtering on OSX)
 
 
 version 3.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 531c21d..a993a67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -370,6 +370,7 @@ Filters:
   vf_colorbalance.c Paul B Mahol
   vf_colorkey.c

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 10:25 PM, Mats Peterson wrote:

On 03/12/2016 10:16 PM, Mats Peterson wrote:

On 03/12/2016 06:39 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 04:37:39PM +0100, Mats Peterson wrote:

On 03/12/2016 04:33 PM, Mats Peterson wrote:

On 03/12/2016 04:29 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in
the
demuxer  is a future task. Now the muxing of video with xxpc
chunks
works properly at least.

Try playing the resulting test.avi file from the command line
below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17
00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a
zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int
avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised
value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by
anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at least?


patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.


40 is exactly what it should be, in *all* cases, regardless of what
follows the BITMAPINFOHEADER. Read below.



The spec says:
"A stream format chunk ('strf') must follow the stream header chunk.
The stream format chunk describes the format of the data in the
stream. The data contained in this chunk depends on the stream type.
For video streams, the information is a BITMAPINFO structure,
including palette information if appropriate. For audio streams, the
information is a WAVEFORMATEX structure."

If that chunk is a BITMAPINFO structure + a palette then formats
without a palette would likely have biSize similar to the chunk
size ...

its quite possible iam missing some details of course ...



You're missing the specification of the BITMAPINFOHEADER. It states
that
biSize is the size of the structure, i.e. the BITMAPINFOHEADER 

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 10:16 PM, Mats Peterson wrote:

On 03/12/2016 06:39 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 04:37:39PM +0100, Mats Peterson wrote:

On 03/12/2016 04:33 PM, Mats Peterson wrote:

On 03/12/2016 04:29 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc
chunks
works properly at least.

Try playing the resulting test.avi file from the command line
below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17
00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a
zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int
avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised
value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by
anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at least?


patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.


40 is exactly what it should be, in *all* cases, regardless of what
follows the BITMAPINFOHEADER. Read below.



The spec says:
"A stream format chunk ('strf') must follow the stream header chunk.
The stream format chunk describes the format of the data in the
stream. The data contained in this chunk depends on the stream type.
For video streams, the information is a BITMAPINFO structure,
including palette information if appropriate. For audio streams, the
information is a WAVEFORMATEX structure."

If that chunk is a BITMAPINFO structure + a palette then formats
without a palette would likely have biSize similar to the chunk
size ...

its quite possible iam missing some details of course ...



You're missing the specification of the BITMAPINFOHEADER. It states
that
biSize is the size of the structure, i.e. the BITMAPINFOHEADER itself.
No less, no more.

Re: [FFmpeg-devel] [PATCH] Add support for HLS PLAYLIST types EVENT and VOD

[Michael Niedermayer]

On Thu, Dec 17, 2015 at 03:16:45AM +, Adam Kent wrote:
> Thanks Carl, good point, hope this is better.
> 
> ---
>  doc/muxers.texi  |  8 
>  libavformat/hlsenc.c | 20 
>  2 files changed, 28 insertions(+)

applied

thanks

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 06:39 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 04:37:39PM +0100, Mats Peterson wrote:

On 03/12/2016 04:33 PM, Mats Peterson wrote:

On 03/12/2016 04:29 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc chunks
works properly at least.

Try playing the resulting test.avi file from the command line below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17
00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at least?


patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.


40 is exactly what it should be, in *all* cases, regardless of what
follows the BITMAPINFOHEADER. Read below.



The spec says:
"A stream format chunk ('strf') must follow the stream header chunk.
The stream format chunk describes the format of the data in the
stream. The data contained in this chunk depends on the stream type.
For video streams, the information is a BITMAPINFO structure,
including palette information if appropriate. For audio streams, the
information is a WAVEFORMATEX structure."

If that chunk is a BITMAPINFO structure + a palette then formats
without a palette would likely have biSize similar to the chunk
size ...

its quite possible iam missing some details of course ...



You're missing the specification of the BITMAPINFOHEADER. It states that
biSize is the size of the structure, i.e. the BITMAPINFOHEADER itself.
No less, no more.

Re: [FFmpeg-devel] [PATCH] fix http chunk encoding parsing

[Michael Niedermayer]

On Tue, Dec 15, 2015 at 12:31:18PM +0300, Eugene Kosov wrote:
> ---
>  ffserver.c | 77 
> --
>  1 file changed, 50 insertions(+), 27 deletions(-)

sorry for the late reply

please explain what exactly this patch fixes and how to reproduce it

thx

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- 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 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 03:19:11PM +0100, Thilo Borgmann wrote:
> Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
> > Add coreimage filter for OSX.
> 
> Corrected patch attached.
> 
> -Thilo
> 

>  Changelog  |1 
>  MAINTAINERS|1 
>  configure  |3 
>  doc/filters.texi   |   67 +
>  libavfilter/Makefile   |1 
>  libavfilter/allfilters.c   |1 
>  libavfilter/vf_coreimage.m |  553 
> +
>  7 files changed, 627 insertions(+)
> 2bc3194273f31211d7ee3effc2af6c6d1b393db2  
> 0002-lavf-Add-coreimage-filter-for-GPU-based-image-filter.patch
> From 124fb0ce2a30c965ec28c8fbff1c04a872f33bc6 Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann 
> Date: Sat, 12 Mar 2016 15:18:04 +0100
> Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
>  on OSX.
> 
> ---
>  Changelog  |   1 +
>  MAINTAINERS|   1 +
>  configure  |   3 +
>  doc/filters.texi   |  67 ++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vf_coreimage.m | 553 
> +
>  7 files changed, 627 insertions(+)
>  create mode 100644 libavfilter/vf_coreimage.m
> 
> diff --git a/Changelog b/Changelog
> index 1f57f5e..5053a86 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -12,6 +12,7 @@ version :
>  - ciescope filter
>  - protocol blacklisting API
>  - MediaCodec H264 decoding
> +- coreimage filter (GPU based image filtering on OSX)
>  
>  
>  version 3.0:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 531c21d..a993a67 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -370,6 +370,7 @@ Filters:
>vf_colorbalance.c Paul B Mahol
>vf_colorkey.c Timo Rothenpieler
>vf_colorlevels.c  Paul B Mahol
> +  vf_coreimage.mThilo Borgmann
>vf_deband.c   Paul B Mahol
>vf_dejudder.c Nicholas Robbins
>vf_delogo.c   Jean Delvare (CC )
> diff --git a/configure b/configure
> index 1b189328..fe96215 100755
> --- a/configure
> +++ b/configure
> @@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
>  frei0r_src_filter_extralibs='$ldl'
>  ladspa_filter_extralibs='$ldl'
>  nvenc_encoder_extralibs='$ldl'
> +coreimage_filter_extralibs="-framework QuartzCore -framework AppKit 
> -framework OpenGL"
>  
>  if ! disabled network; then
>  check_func getaddrinfo $network_extralibs

> @@ -5483,6 +5484,8 @@ enabled avisynth  && { { check_lib2 "windows.h" 
> LoadLibrary; } ||
> die "ERROR: LoadLibrary/dlopen not found for 
> avisynth"; }
>  enabled cuda  && check_lib cuda.h cuInit -lcuda
>  enabled chromaprint   && require chromaprint chromaprint.h 
> chromaprint_get_version -lchromaprint
> +enabled coreimage && { check_header_oc CoreImage/CoreImage.h || die 
> "ERROR: CoreImage.h header not found"; }
> +#enabled coreimage && { check_lib2 CoreImage/CoreImage.h 
> CGGetActiveDisplayList -framework CoreImage; }

this looks suspect

also breaks build on linux
./configure && make -j12
...
libavfilter/vaf_spectrumsynth.c:434:9: warning: ‘ret’ may be used uninitialized 
in this function [-Wuninitialized]
CC  libavfilter/vf_copy.o
OBJCC   libavfilter/vf_coreimage.o
gcc: error trying to exec 'cc1obj': execvp: No such file or directory
make: *** [libavfilter/vf_coreimage.o] Error 1
make: *** Waiting for unfinished jobs

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_quantization: use cbrt table

[Reimar Döffinger]

On Sat, Mar 12, 2016 at 12:09:13PM -0500, Ganesh Ajjanagadde wrote:
> And yes, for me the proof of the pudding is in the eating. In other
> words, if you or someone else sends a small, simple patch achieving
> the above one-line change, I will be very happy and will learn
> something.

I don't think that one line change is the problem.
The problem is moving the tables into a .c file.
And the biggest issue there is actually the fixed/non-fixed split.
Which you kind of avoided by always including both tables, even
if e.g. the fixed point would never be used.
That part was most painful for me :)
And I am still unclear where I should use AAC_RENAME and where
(especially for the headers) I can just assume one or the other.
I'll send a patch that does the data sharing, leaving the
one-liner to you :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.

[Reimar Döffinger]

Allows sharing and reusing the data between different files.

Signed-off-by: Reimar Döffinger 
---
 libavcodec/Makefile | 10 +-
 libavcodec/aacdec.c |  2 +-
 libavcodec/aacdec_fixed.c   |  6 +++---
 libavcodec/aacdec_template.c|  4 ++--
 libavcodec/cbrt_data.c  | 28 +++
 libavcodec/cbrt_data.h  | 38 +
 libavcodec/cbrt_data_fixed.c| 29 
 libavcodec/cbrt_tablegen.h  | 18 --
 libavcodec/cbrt_tablegen_template.c |  8 ++--
 9 files changed, 116 insertions(+), 27 deletions(-)
 create mode 100644 libavcodec/cbrt_data.c
 create mode 100644 libavcodec/cbrt_data.h
 create mode 100644 libavcodec/cbrt_data_fixed.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1cd9572..6bb1af1 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -137,17 +137,17 @@ OBJS-$(CONFIG_A64MULTI_ENCODER)+= a64multienc.o 
elbg.o
 OBJS-$(CONFIG_A64MULTI5_ENCODER)   += a64multienc.o elbg.o
 OBJS-$(CONFIG_AAC_DECODER) += aacdec.o aactab.o aacsbr.o 
aacps_float.o \
   aacadtsdec.o mpeg4audio.o kbdwin.o \
-  sbrdsp.o aacpsdsp_float.o
+  sbrdsp.o aacpsdsp_float.o cbrt_data.o
 OBJS-$(CONFIG_AAC_FIXED_DECODER)   += aacdec_fixed.o aactab.o 
aacsbr_fixed.o aacps_fixed.o \
   aacadtsdec.o mpeg4audio.o kbdwin.o \
-  sbrdsp_fixed.o aacpsdsp_fixed.o
+  sbrdsp_fixed.o aacpsdsp_fixed.o 
cbrt_data_fixed.o
 OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o aaccoder.o aacenctab.o\
   aacpsy.o aactab.o  \
   aacenc_is.o \
   aacenc_tns.o \
   aacenc_ltp.o \
   aacenc_pred.o \
-  psymodel.o mpeg4audio.o kbdwin.o
+  psymodel.o mpeg4audio.o kbdwin.o 
cbrt_data.o
 OBJS-$(CONFIG_AASC_DECODER)+= aasc.o msrledec.o
 OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o ac3.o 
kbdwin.o
 OBJS-$(CONFIG_AC3_FIXED_DECODER)   += ac3dec_fixed.o ac3dec_data.o ac3.o 
kbdwin.o
@@ -1017,8 +1017,8 @@ $(GEN_HEADERS): $(SUBDIR)%_tables.h: 
$(SUBDIR)%_tablegen$(HOSTEXESUF)
$(M)./$< > $@
 
 ifdef CONFIG_HARDCODED_TABLES
-$(SUBDIR)aacdec.o: $(SUBDIR)cbrt_tables.h
-$(SUBDIR)aacdec_fixed.o: $(SUBDIR)cbrt_fixed_tables.h
+$(SUBDIR)cbrt_data.o: $(SUBDIR)cbrt_tables.h
+$(SUBDIR)cbrt_data_fixed.o: $(SUBDIR)cbrt_fixed_tables.h
 $(SUBDIR)aacps_float.o: $(SUBDIR)aacps_tables.h
 $(SUBDIR)aacps_fixed.o: $(SUBDIR)aacps_fixed_tables.h
 $(SUBDIR)aactab_fixed.o: $(SUBDIR)aac_fixed_tables.h
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 26bdea1..ee9b4eb 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -50,7 +50,7 @@
 #include "aac.h"
 #include "aactab.h"
 #include "aacdectab.h"
-#include "cbrt_tablegen.h"
+#include "cbrt_data.h"
 #include "sbr.h"
 #include "aacsbr.h"
 #include "mpeg4audio.h"
diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
index 396a874..acb8178 100644
--- a/libavcodec/aacdec_fixed.c
+++ b/libavcodec/aacdec_fixed.c
@@ -75,7 +75,7 @@
 #include "aac.h"
 #include "aactab.h"
 #include "aacdectab.h"
-#include "cbrt_tablegen.h"
+#include "cbrt_data.h"
 #include "sbr.h"
 #include "aacsbr.h"
 #include "mpeg4audio.h"
@@ -155,9 +155,9 @@ static void vector_pow43(int *coefs, int len)
 for (i=0; i

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 04:37:39PM +0100, Mats Peterson wrote:
> On 03/12/2016 04:33 PM, Mats Peterson wrote:
> >On 03/12/2016 04:29 PM, Michael Niedermayer wrote:
> >>On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:
> >>>On 03/12/2016 02:52 PM, Michael Niedermayer wrote:
> On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:
> >On 03/12/2016 02:26 PM, Mats Peterson wrote:
> >>On 03/12/2016 12:53 PM, Michael Niedermayer wrote:
> >>>On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:
> Here's an interesting one. Windows Media Player won't make any
> palette
> changes without the xxpc chunks beeing indexed.
> 
> Fixing the logic for reading and seeking with xxpc chunks in the
> demuxer  is a future task. Now the muxing of video with xxpc chunks
> works properly at least.
> 
> Try playing the resulting test.avi file from the command line below
> with Windows Media Player, with and without this patch.
> 
> ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi
> 
> Mats
> 
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> >>>
>   libavformat/avi.h|6 +++-
>   libavformat/avienc.c |   56
> +--
>   tests/ref/lavf-fate/avi_cram |4 +--
>   3 files changed, 51 insertions(+), 15 deletions(-)
> 2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
> 0002-Add-xxpc-entries-to-index.patch
>  From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17
> 00:00:00 2001
> From: Mats Peterson 
> Date: Sat, 12 Mar 2016 07:00:33 +0100
> Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index
> 
> ---
>   libavformat/avi.h|6 -
>   libavformat/avienc.c |   56
> +-
>   tests/ref/lavf-fate/avi_cram |4 +--
>   3 files changed, 51 insertions(+), 15 deletions(-)
> 
> diff --git a/libavformat/avi.h b/libavformat/avi.h
> index 34da76f..af21f2c 100644
> --- a/libavformat/avi.h
> +++ b/libavformat/avi.h
> @@ -32,7 +32,11 @@
>   #define AVI_MASTER_INDEX_SIZE   256
>   #define AVI_MAX_STREAM_COUNT100
> 
> +/* stream header flags */
> +#define AVISF_VIDEO_PALCHANGES  0x0001
> +
>   /* index flags */
> -#define AVIIF_INDEX 0x10
> +#define AVIIF_INDEX 0x0010
> +#define AVIIF_NO_TIME   0x0100
> 
>   #endif /* AVFORMAT_AVI_H */
> diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> index ad50379..b731bc2 100644
> --- a/libavformat/avienc.c
> +++ b/libavformat/avienc.c
> @@ -44,13 +44,14 @@
>    */
> 
>   typedef struct AVIIentry {
> -unsigned int flags, pos, len;
> +char tag[5];
> >>>
> >>>the tag should be 4 bytes
> >>>5 is ugly, it requires padding and bloats the structure with a zero
> >>>byte
> >>>
> >>
> >>OK.
> >>
> >>>
> +unsigned int flags;
> +unsigned int pos;
> +unsigned int len;
>   } AVIIentry;
> 
>   #define AVI_INDEX_CLUSTER_SIZE 16384
> 
> -#define AVISF_VIDEO_PALCHANGES 0x0001
> -
>   typedef struct AVIIndex {
>   int64_t indx_start;
>   int64_t audio_strm_offset;
> >>>
> @@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
>   }
>   if (!empty) {
>   avist = s->streams[stream_id]->priv_data;
> -avi_stream2fourcc(tag, stream_id,
> +if (*ie->tag)
> >>>
> >>>==18406== Conditional jump or move depends on uninitialised value(s,
> >>>==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
> >>>==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
> >>>==18406==by 0x64A234: av_write_trailer (mux.c:1124)
> >>>==18406==by 0x43A729: transcode (ffmpeg.c:4173)
> >>>==18406==by 0x43ACE3: main (ffmpeg.c:4334)
> >>>
> >>
> >>OK.
> >
> >
> >It's not really uninitalised, is it? Since it isn't used by anything
> >but my own code, it's all zero bytes, right?
> 
> after this patch snow encoding failed, i run valgrind and saw this
> so there was something wrong, i dont know for sure if it was this
> 
> 
> >>>
> >>>OK. By the way, are you in the process of applying patch 1 at least?
> >>
> >>patch one has a list of exceptions, this list contains every single
> >>case for which evidence has 

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_quantization: use cbrt table

[Reimar Döffinger]

On Sat, Mar 12, 2016 at 12:09:13PM -0500, Ganesh Ajjanagadde wrote:
> And yes, for me the proof of the pudding is in the eating. In other
> words, if you or someone else sends a small, simple patch achieving
> the above one-line change, I will be very happy and will learn
> something.

Does that mean you did not see my patch, you did not consider
it because it was not quite finished, or because it was still
too complicated?

> 3. Why do we even need all this hardcoded table chicanery? No one has
> presented a use case where they make a serious difference, with
> benches to support when I called for it wrt cbrt_tab and aac. Of
> course it will be faster in many cases (e.g mpegaudio_tablegen still
> takes 1M cycles down from 10M before), but by how much is really the
> question. Ronald gave one related to numerous small files, but even
> that was a stretch as one can batch process them together.

The point is to avoid each table using up memory if you run hundreds
of instances, reduce the attack surface for security issues by having
more data in .rodata, and for platforms supporting it allow the
tables to be stored and used directly from ROM, and even on normal
platforms all them being swapped out to the binary instead of a swap
file.
That should mostly be useful for special platforms.
But for some codecs the biggest: It makes things actually properly
thread-safe instead of the hacks and luck we in some cases rely on
to make initializing those table thread-safe/reliable.
It is part of a plan B in case we ever need truly, 100% reliable
thread safety without placing a significant number of functions under
locks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2 2/2] lavu/lfg: switch to Ziggurat algorithm for normal random number generation (WIP)

[Ganesh Ajjanagadde]

On Sat, Mar 12, 2016 at 11:42 AM, Reimar Döffinger
 wrote:
> On Sat, Mar 12, 2016 at 11:11:32AM -0500, Ganesh Ajjanagadde wrote:
>> On Sat, Mar 12, 2016 at 11:02 AM, Michael Niedermayer
>>  wrote:
>> >> +static inline double ziggurat(AVLFG *lfg)
>> >> +{
>> >> +while (1) {
>> >
>> >> +uint64_t r = (((uint64_t)av_lfg_get(lfg) << 32) + 
>> >> av_lfg_get(lfg)) & 0x000f;
>> >
>> > the order of Function evaluations is undefined here i think
>>
>> And why would that matter? Aren't these just approximations to truly
>> uniform 32 bits? rand()<<32 + rand() is common:
>
> Because you generally don't want the randomness to include the
> compiler/compiler options used.
> You can end up with a case where a bug only happens when you get
> a specific value.
> To debug you compile with -O1. Now the compiler changes the order
> here and suddenly the bug is gone!
> So I think the more appropriate question would be: why is having
> them in a single line so important that you would risk doing
> this to yourself or a fellow developer?
> Personally I am fan of splitting things into lines anyway when
> the cost is minimal, like
> uint64_t r = (uint64_t)av_lfg_get(lfg) << 32;
> r += av_lfg_get(lfg);
> r &= 0x000f;

No problem, I don't mind at all and actually like multiple lines
myself. Changed and posted v3. Thanks.

> ___
> 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] lavc/aacenc_quantization: use cbrt table

[Ganesh Ajjanagadde]

On Sat, Mar 12, 2016 at 11:35 AM, Reimar Döffinger
 wrote:
> On Sat, Mar 12, 2016 at 10:21:10AM -0500, Ganesh Ajjanagadde wrote:
>> Ok. Let me put it this way: I have a super simple patch that simply
>> moves stuff to cbrt_data.c and works perfectly well under default
>> configure, with no changes to the Makefile apart from adding
>> cbrt_data.o to the list of objects for AAC.
>>
>> As soon as I test under --enable-hardcoded-tables, I get linker errors
>> during the host table generation phase due to undefined ff_cbrt_tab,
>> etc. I also know why they occur: I declare ff_cbrt_tab as extern in
>> cbrt_tablegen.h, so basically during host generation phase cbrt_data.c
>> needs to also get compiled in, where the implementation is done. But
>> the host gen simply #includes cbrt_tablegen.h, sees the extern
>> declaration (since during host gen it #defs hardcoded to 0, that is
>> how it gets the "magic" done), does not find the implementation, and
>> naturally complains.
>>
>> So one could of course duplicate the code in tablegen_template etc and
>> not #include cbrt_tablegen, it can actually be very short since we
>> don't care about efficiency there and the fancy current algorithm does
>> not need to be used.
>>
>> But whatever it is, be it Makefile chicanery or some ad-hoc methods
>> like above, something needs to be done; there is no "natural"
>> solution.
>>
>> TL;DR: I am not going to waste time on this. Anyone wants to do it, it
>> is conceptually trivial.
>
> I really don't see what the problem is??
> Attached is a (approx.) 4 line change that avoids the Makefile
> mess and does not duplicate code.
> It needs one hack due to config.h usage in cbrt_data.c.
> It and the ugly cbrt_data.c include in the table generator
> could be avoided by simply leaving ff_cbrt_tab and the table
> generation code in cbrt_tablegen.h and using a cbrt_data.h
> in aacenc.c etc. which is more logical anyway than having
> a cbrt_tablegen.h header that contains declarations for
> stuff that is actually in cbrt_data.c.
> It seems to me the only problem here was caused by
> trying to physically move stuff into cbrt_data.c instead
> of just including whatever needs to be exported for
> use by the other files, and in addition (mis?) using
> the cbrt_tablegen.h header for the stuff in cbrt_data.c.
> I can of course try to clean up these last things,
> but I'm not really familiar with the code and
> some of the changes seem not completely trivial
> (e.g. the aacenc_quantization.h one)

There is nothing going on there, all I am trying trying to achieve is:
libavcodec/aacenc_quantization.h:108:quantized
= c*cbrtf(c)*IQ;
by quantized = cbrt_tab[c]*IQ.

There is just the details of:
1. Making sure cbrt_tableinit is called before this.
2. Making it build and run correctly.

> so I'd rather not.
> (I admit that there must be something about that
> tablegen code that is genuinely aligned with my
> thinking but not most else's, because to me it
> looks clean and obvious while a lot of people think
> it is a confusing horror... I have been unable to
> figure out a way to fix this)

Maybe it is because you were the one who wrote most of this stuff originally.
BTW, here is an example of why I consider it a horror: look at lines
62, 63, 998-1002 of libavcodec/Makefile. These are all things that are
not at all needed if we did not have this stuff.

And yes, for me the proof of the pudding is in the eating. In other
words, if you or someone else sends a small, simple patch achieving
the above one-line change, I will be very happy and will learn
something.

But until then, I can't really do much; it is just from my perspective useless:
1. Gains are anyway small.
2. Essentially it is a one line change as noted above, why do I need
to spend so much time trying to get it to work?
3. Why do we even need all this hardcoded table chicanery? No one has
presented a use case where they make a serious difference, with
benches to support when I called for it wrt cbrt_tab and aac. Of
course it will be faster in many cases (e.g mpegaudio_tablegen still
takes 1M cycles down from 10M before), but by how much is really the
question. Ronald gave one related to numerous small files, but even
that was a stretch as one can batch process them together. In fact,
taking some inspiration from a remark by wm4, I put in some effort for
making dynamic init faster, in one or two cases we got rid of this
chicanery altogether.
Most clients anyway do not --enable-hardcoded-tables as it is not the
default, and (rightfully so) is placed under the "expert options".

Simply put, why do I need to waste my time on a feature that:
a) essentially no client cares about
b) that is clearly not localized/contained properly and complicates
the build system.
c) adds complexity to the codebase that only a few people truly
understand so that
d) it becomes non-trivial in order to do a trivial change that has
arguably more impact than the net 

Re: [FFmpeg-devel] [PATCHv2 2/2] lavu/lfg: switch to Ziggurat algorithm for normal random number generation (WIP)

[Reimar Döffinger]

On Sat, Mar 12, 2016 at 11:11:32AM -0500, Ganesh Ajjanagadde wrote:
> On Sat, Mar 12, 2016 at 11:02 AM, Michael Niedermayer
>  wrote:
> >> +static inline double ziggurat(AVLFG *lfg)
> >> +{
> >> +while (1) {
> >
> >> +uint64_t r = (((uint64_t)av_lfg_get(lfg) << 32) + 
> >> av_lfg_get(lfg)) & 0x000f;
> >
> > the order of Function evaluations is undefined here i think
> 
> And why would that matter? Aren't these just approximations to truly
> uniform 32 bits? rand()<<32 + rand() is common:

Because you generally don't want the randomness to include the
compiler/compiler options used.
You can end up with a case where a bug only happens when you get
a specific value.
To debug you compile with -O1. Now the compiler changes the order
here and suddenly the bug is gone!
So I think the more appropriate question would be: why is having
them in a single line so important that you would risk doing
this to yourself or a fellow developer?
Personally I am fan of splitting things into lines anyway when
the cost is minimal, like
uint64_t r = (uint64_t)av_lfg_get(lfg) << 32;
r += av_lfg_get(lfg);
r &= 0x000f;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2 2/2] lavu/lfg: switch to Ziggurat algorithm for normal random number generation (WIP)

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 11:11:32AM -0500, Ganesh Ajjanagadde wrote:
> On Sat, Mar 12, 2016 at 11:02 AM, Michael Niedermayer
>  wrote:
> > On Sat, Mar 12, 2016 at 08:58:41AM -0500, Ganesh Ajjanagadde wrote:
> >> Code taken from the Julia project, licensed under MIT:
> >> https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn
> >> derived from: "The Ziggurat Method for generating random variables" - 
> >> Marsaglia and Tsang.
> >>
> >> Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is
> >> well known to be the fastest method empirically for generating normal 
> >> random
> >> variables for a fixed PRNG source.
> >>
> >> Note that there are a large number of implementations with
> >> various tunings, this was one of the simpler ones and also has a friendly
> >> license.
> >>
> >> This results in ~ 3x speedup of random number generation:
> >> old:
> >>   15090 decicycles in av_bmg_get,   1 runs,  0 skips
> >>   13140 decicycles in av_bmg_get,   2 runs,  0 skips
> >>   10117 decicycles in av_bmg_get,   4 runs,  0 skips
> >>   [...]
> >>2133 decicycles in av_bmg_get,  524268 runs, 20 skips=60.4x
> >>2134 decicycles in av_bmg_get, 1048531 runs, 45 skips=61.3x
> >>2135 decicycles in av_bmg_get, 2097061 runs, 91 skips=61.9x
> >>
> >> new:
> >>7650 decicycles in av_gaussian_get,   1 runs,  0 skips
> >>5490 decicycles in av_gaussian_get,   2 runs,  0 skips
> >>3982 decicycles in av_gaussian_get,   4 runs,  0 skips
> >>[...]
> >> 812 decicycles in av_gaussian_get,  524281 runs,  7 skips
> >> 813 decicycles in av_gaussian_get, 1048563 runs, 13 skips
> >> 813 decicycles in av_gaussian_get, 2097131 runs, 21 skips
> >>
> >> and accordingly a ~2% speedup in aac encoding (-march=native, Haswell, 
> >> clang):
> >>
> >> old:
> >> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac  5.30s user 0.02s 
> >> system 99% cpu 5.322 total
> >> new:
> >> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac  5.16s user 0.03s 
> >> system 99% cpu 5.198 total
> >>
> >> Function added as av_gaussian_get with documentation, minor bumped.
> >>
> > [...]
> >
> >> +static inline double ziggurat(AVLFG *lfg)
> >> +{
> >> +while (1) {
> >
> >> +uint64_t r = (((uint64_t)av_lfg_get(lfg) << 32) + 
> >> av_lfg_get(lfg)) & 0x000f;
> >
> > the order of Function evaluations is undefined here i think
> 
> And why would that matter? Aren't these just approximations to truly

reproduceability
a user has case where something fails the developer cannot reproduce
as his compiler evaluates them in a different order

also for regression tests it would be better if the values roughly are
the same between platforms

[...]
-- 
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

[FFmpeg-devel] [PATCHv2] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)

[Ganesh Ajjanagadde]

This is ~2x faster for y not an integer on Haswell+GCC, and should
generally be faster due to the fact that anyway powf essentially does
this under the hood. Made an inline function in lavu/internal.h for this
purpose.

Note that there are some accuracy differences, that should generally be
negligible. In particular, FATE still passes on this platform.

Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC.
before:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac  6.05s user 0.06s system 104% cpu 
5.821 total

after:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.67s user 0.03s system 105% cpu 
5.416 total

This is also faster than an alternative approach that pulls in powf, gets rid of
the crufty NaN checks and other special cases, exploits knowledge about the 
intervals, etc.
This of course does not exclude smarter approaches; just suggests that
there would need to be significant work on this front of lower utility than
searches for hotspots elsewhere.

Reviewed-by: Reimar Döffinger 
Reviewed-by: Ronald S. Bultje 
Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/aacenc_utils.h |  6 +-
 libavutil/internal.h  | 16 
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
index 41a6296..28ea5cd 100644
--- a/libavcodec/aacenc_utils.h
+++ b/libavcodec/aacenc_utils.h
@@ -28,6 +28,7 @@
 #ifndef AVCODEC_AACENC_UTILS_H
 #define AVCODEC_AACENC_UTILS_H
 
+#include "libavutil/internal.h"
 #include "aac.h"
 #include "aacenctab.h"
 #include "aactab.h"
@@ -122,7 +123,10 @@ static inline float find_form_factor(int group_len, int 
swb_size, float thresh,
 if (s >= ethresh) {
 nzl += 1.0f;
 } else {
-nzl += powf(s / ethresh, nzslope);
+if (nzslope == 2.f)
+nzl += (s / ethresh) * (s / ethresh);
+else
+nzl += ff_fast_pow(s / ethresh, nzslope);
 }
 }
 if (e2 > thresh) {
diff --git a/libavutil/internal.h b/libavutil/internal.h
index da76ca2..aa43754 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -315,6 +315,22 @@ static av_always_inline float ff_exp10f(float x)
 }
 
 /**
+ * Compute x^y for floating point x, y. Note: this function is faster than the
+ * libm variant due to mainly 2 reasons:
+ * 1. It does not handle any edge cases. In particular, this is only guaranteed
+ * to work correctly for x > 0.
+ * 2. It is not as accurate as a standard nearly "correctly rounded" libm 
variant.
+ * @param x base
+ * @param y exponent
+ * @return x^y
+ */
+static av_always_inline float ff_fast_pow(float x, float y)
+{
+return expf(logf(x) * y);
+}
+
+
+/**
  * A wrapper for open() setting O_CLOEXEC.
  */
 av_warn_unused_result
-- 
2.7.2

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

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_quantization: use cbrt table

[Reimar Döffinger]

On Sat, Mar 12, 2016 at 10:21:10AM -0500, Ganesh Ajjanagadde wrote:
> Ok. Let me put it this way: I have a super simple patch that simply
> moves stuff to cbrt_data.c and works perfectly well under default
> configure, with no changes to the Makefile apart from adding
> cbrt_data.o to the list of objects for AAC.
> 
> As soon as I test under --enable-hardcoded-tables, I get linker errors
> during the host table generation phase due to undefined ff_cbrt_tab,
> etc. I also know why they occur: I declare ff_cbrt_tab as extern in
> cbrt_tablegen.h, so basically during host generation phase cbrt_data.c
> needs to also get compiled in, where the implementation is done. But
> the host gen simply #includes cbrt_tablegen.h, sees the extern
> declaration (since during host gen it #defs hardcoded to 0, that is
> how it gets the "magic" done), does not find the implementation, and
> naturally complains.
> 
> So one could of course duplicate the code in tablegen_template etc and
> not #include cbrt_tablegen, it can actually be very short since we
> don't care about efficiency there and the fancy current algorithm does
> not need to be used.
> 
> But whatever it is, be it Makefile chicanery or some ad-hoc methods
> like above, something needs to be done; there is no "natural"
> solution.
> 
> TL;DR: I am not going to waste time on this. Anyone wants to do it, it
> is conceptually trivial.

I really don't see what the problem is??
Attached is a (approx.) 4 line change that avoids the Makefile
mess and does not duplicate code.
It needs one hack due to config.h usage in cbrt_data.c.
It and the ugly cbrt_data.c include in the table generator
could be avoided by simply leaving ff_cbrt_tab and the table
generation code in cbrt_tablegen.h and using a cbrt_data.h
in aacenc.c etc. which is more logical anyway than having
a cbrt_tablegen.h header that contains declarations for
stuff that is actually in cbrt_data.c.
It seems to me the only problem here was caused by
trying to physically move stuff into cbrt_data.c instead
of just including whatever needs to be exported for
use by the other files, and in addition (mis?) using
the cbrt_tablegen.h header for the stuff in cbrt_data.c.
I can of course try to clean up these last things,
but I'm not really familiar with the code and
some of the changes seem not completely trivial
(e.g. the aacenc_quantization.h one) so I'd rather not.
(I admit that there must be something about that
tablegen code that is genuinely aligned with my
thinking but not most else's, because to me it
looks clean and obvious while a lot of people think
it is a confusing horror... I have been unable to
figure out a way to fix this)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1cd9572..fca1da0 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -137,17 +137,17 @@ OBJS-$(CONFIG_A64MULTI_ENCODER)+= a64multienc.o elbg.o
 OBJS-$(CONFIG_A64MULTI5_ENCODER)   += a64multienc.o elbg.o
 OBJS-$(CONFIG_AAC_DECODER) += aacdec.o aactab.o aacsbr.o aacps_float.o \
   aacadtsdec.o mpeg4audio.o kbdwin.o \
-  sbrdsp.o aacpsdsp_float.o
+  sbrdsp.o aacpsdsp_float.o cbrt_data.o
 OBJS-$(CONFIG_AAC_FIXED_DECODER)   += aacdec_fixed.o aactab.o aacsbr_fixed.o aacps_fixed.o \
   aacadtsdec.o mpeg4audio.o kbdwin.o \
-  sbrdsp_fixed.o aacpsdsp_fixed.o
+  sbrdsp_fixed.o aacpsdsp_fixed.o cbrt_data.o
 OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o aaccoder.o aacenctab.o\
   aacpsy.o aactab.o  \
   aacenc_is.o \
   aacenc_tns.o \
   aacenc_ltp.o \
   aacenc_pred.o \
-  psymodel.o mpeg4audio.o kbdwin.o
+  psymodel.o mpeg4audio.o kbdwin.o cbrt_data.o
 OBJS-$(CONFIG_AASC_DECODER)+= aasc.o msrledec.o
 OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o ac3.o kbdwin.o
 OBJS-$(CONFIG_AC3_FIXED_DECODER)   += ac3dec_fixed.o ac3dec_data.o ac3.o kbdwin.o
@@ -1017,8 +1017,7 @@ $(GEN_HEADERS): $(SUBDIR)%_tables.h: $(SUBDIR)%_tablegen$(HOSTEXESUF)
 	$(M)./$< > $@
 
 ifdef CONFIG_HARDCODED_TABLES
-$(SUBDIR)aacdec.o: $(SUBDIR)cbrt_tables.h
-$(SUBDIR)aacdec_fixed.o: $(SUBDIR)cbrt_fixed_tables.h
+$(SUBDIR)cbrt_data.o: $(SUBDIR)cbrt_tables.h
 $(SUBDIR)aacps_float.o: $(SUBDIR)aacps_tables.h
 $(SUBDIR)aacps_fixed.o: $(SUBDIR)aacps_fixed_tables.h
 $(SUBDIR)aactab_fixed.o: $(SUBDIR)aac_fixed_tables.h
diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
index 396a874..04ebe99 100644
--- a/libavcodec/aacdec_fixed.c
+++ b/libavcodec/aacdec_fixed.c

Re: [FFmpeg-devel] Subtitles for GSoC

[Ganesh Ajjanagadde]

On Wed, Mar 9, 2016 at 6:33 AM, Nicolas George  wrote:
> Le nonidi 19 ventôse, an CCXXIV, Clement Boesch a écrit :
[...]
>
>> - they are defined in libavcodec, and we do not want libavfilter to
>>   depend on libavcodec for a core feature (we have a few filters
>>   depending on it, but that's optional). As such, libavutil is a much
>>   better place for this, which already contains the AVFrame.
>
> Personally, I have no problem about lavfi depending on lavc; I want to merge
> all libraries anyway.

I also like the idea of merging the libs. Could you please point me to
some thread with your thoughts on it, or alternatively create a new
thread for this if you think it could be useful for the project?

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

Re: [FFmpeg-devel] [PATCH]lavf/mkvenc: Set bit_depth for lossless audio codecs

[Carl Eugen Hoyos]

wm4  googlemail.com> writes:

> On Sat, 12 Mar 2016 16:51:18 +0100
> Carl Eugen Hoyos  ag.or.at> wrote:
> 
> > Attached patch makes the output of the mkv muxer more 
> > similar to what mkvmerge does.
> > May fix ticket #5332.
> > 
> > Please comment, Carl Eugen
> 
> Are you sure this is correct,

No.

> and _why_?

I am not sure I understand:
I don't know if it's correct but that is what mkvmerge 
does and imo, it makes much more sense to write an 
actually useful value instead of 32 for all (or some) 
lossless audio codecs.

Don't you agree?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavf/mkvenc: Set bit_depth for lossless audio codecs

[wm4]

On Sat, 12 Mar 2016 16:51:18 +0100
Carl Eugen Hoyos  wrote:

> Hi!
> 
> Attached patch makes the output of the mkv muxer more similar to what 
> mkvmerge does.
> May fix ticket #5332.
> 
> Please comment, Carl Eugen

Are you sure this is correct, and _why_?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2 2/2] lavu/lfg: switch to Ziggurat algorithm for normal random number generation (WIP)

[Ganesh Ajjanagadde]

On Sat, Mar 12, 2016 at 11:02 AM, Michael Niedermayer
 wrote:
> On Sat, Mar 12, 2016 at 08:58:41AM -0500, Ganesh Ajjanagadde wrote:
>> Code taken from the Julia project, licensed under MIT:
>> https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn
>> derived from: "The Ziggurat Method for generating random variables" - 
>> Marsaglia and Tsang.
>>
>> Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is
>> well known to be the fastest method empirically for generating normal random
>> variables for a fixed PRNG source.
>>
>> Note that there are a large number of implementations with
>> various tunings, this was one of the simpler ones and also has a friendly
>> license.
>>
>> This results in ~ 3x speedup of random number generation:
>> old:
>>   15090 decicycles in av_bmg_get,   1 runs,  0 skips
>>   13140 decicycles in av_bmg_get,   2 runs,  0 skips
>>   10117 decicycles in av_bmg_get,   4 runs,  0 skips
>>   [...]
>>2133 decicycles in av_bmg_get,  524268 runs, 20 skips=60.4x
>>2134 decicycles in av_bmg_get, 1048531 runs, 45 skips=61.3x
>>2135 decicycles in av_bmg_get, 2097061 runs, 91 skips=61.9x
>>
>> new:
>>7650 decicycles in av_gaussian_get,   1 runs,  0 skips
>>5490 decicycles in av_gaussian_get,   2 runs,  0 skips
>>3982 decicycles in av_gaussian_get,   4 runs,  0 skips
>>[...]
>> 812 decicycles in av_gaussian_get,  524281 runs,  7 skips
>> 813 decicycles in av_gaussian_get, 1048563 runs, 13 skips
>> 813 decicycles in av_gaussian_get, 2097131 runs, 21 skips
>>
>> and accordingly a ~2% speedup in aac encoding (-march=native, Haswell, 
>> clang):
>>
>> old:
>> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac  5.30s user 0.02s system 
>> 99% cpu 5.322 total
>> new:
>> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac  5.16s user 0.03s system 
>> 99% cpu 5.198 total
>>
>> Function added as av_gaussian_get with documentation, minor bumped.
>>
> [...]
>
>> +static inline double ziggurat(AVLFG *lfg)
>> +{
>> +while (1) {
>
>> +uint64_t r = (((uint64_t)av_lfg_get(lfg) << 32) + av_lfg_get(lfg)) 
>> & 0x000f;
>
> the order of Function evaluations is undefined here i think

And why would that matter? Aren't these just approximations to truly
uniform 32 bits? rand()<<32 + rand() is common:
https://stackoverflow.com/questions/8120062/generate-random-64-bit-integer,
and it is not undefined AFAIK, merely unspecified:
https://stackoverflow.com/questions/24348383/order-of-execution-of-function-calls-within-a-line-undefined.

>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I know you won't believe me, but the highest form of Human Excellence is
> to question oneself and others. -- Socrates
>
> ___
> 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 2/2] lavu/lfg: switch to Ziggurat algorithm for normal random number generation (WIP)

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 08:58:41AM -0500, Ganesh Ajjanagadde wrote:
> Code taken from the Julia project, licensed under MIT:
> https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn
> derived from: "The Ziggurat Method for generating random variables" - 
> Marsaglia and Tsang.
> 
> Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is
> well known to be the fastest method empirically for generating normal random
> variables for a fixed PRNG source.
> 
> Note that there are a large number of implementations with
> various tunings, this was one of the simpler ones and also has a friendly
> license.
> 
> This results in ~ 3x speedup of random number generation:
> old:
>   15090 decicycles in av_bmg_get,   1 runs,  0 skips
>   13140 decicycles in av_bmg_get,   2 runs,  0 skips
>   10117 decicycles in av_bmg_get,   4 runs,  0 skips
>   [...]
>2133 decicycles in av_bmg_get,  524268 runs, 20 skips=60.4x
>2134 decicycles in av_bmg_get, 1048531 runs, 45 skips=61.3x
>2135 decicycles in av_bmg_get, 2097061 runs, 91 skips=61.9x
> 
> new:
>7650 decicycles in av_gaussian_get,   1 runs,  0 skips
>5490 decicycles in av_gaussian_get,   2 runs,  0 skips
>3982 decicycles in av_gaussian_get,   4 runs,  0 skips
>[...]
> 812 decicycles in av_gaussian_get,  524281 runs,  7 skips
> 813 decicycles in av_gaussian_get, 1048563 runs, 13 skips
> 813 decicycles in av_gaussian_get, 2097131 runs, 21 skips
> 
> and accordingly a ~2% speedup in aac encoding (-march=native, Haswell, clang):
> 
> old:
> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac  5.30s user 0.02s system 
> 99% cpu 5.322 total
> new:
> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac  5.16s user 0.03s system 
> 99% cpu 5.198 total
> 
> Function added as av_gaussian_get with documentation, minor bumped.
> 
[...]

> +static inline double ziggurat(AVLFG *lfg)
> +{
> +while (1) {

> +uint64_t r = (((uint64_t)av_lfg_get(lfg) << 32) + av_lfg_get(lfg)) & 
> 0x000f;

the order of Function evaluations is undefined here i think


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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [PATCHv2 1/2] lavu/lfg-test: add simple sample mean, stddev checks

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 08:58:40AM -0500, Ganesh Ajjanagadde wrote:
> Also added a TODO to change to a proper normality test in the future.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/lfg.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)

LGTM

thx

[...]
-- 
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

[FFmpeg-devel] [PATCH]lavf/mkvenc: Set bit_depth for lossless audio codecs

[Carl Eugen Hoyos]

Hi!

Attached patch makes the output of the mkv muxer more similar to what 
mkvmerge does.
May fix ticket #5332.

Please comment, Carl Eugen
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 05b1b94..b721dc3 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -854,6 +854,9 @@ static int mkv_write_track(AVFormatContext *s, 
MatroskaMuxContext *mkv,
 bit_depth = av_get_bytes_per_sample(codec->sample_fmt) << 3;
 if (!bit_depth)
 bit_depth = codec->bits_per_coded_sample;
+if (   codec->codec_id == AV_CODEC_ID_FLAC
+|| codec->codec_id == AV_CODEC_ID_TTA)
+bit_depth = codec->bits_per_raw_sample;
 
 if (codec->codec_id == AV_CODEC_ID_AAC) {
 ret = get_aac_sample_rates(s, codec, _rate, 
_sample_rate);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 04:42 PM, Mats Peterson wrote:

On 03/12/2016 04:37 PM, Mats Peterson wrote:

On 03/12/2016 04:33 PM, Mats Peterson wrote:

On 03/12/2016 04:29 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc
chunks
works properly at least.

Try playing the resulting test.avi file from the command line
below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17
00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a
zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext
*s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised
value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at least?


patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.


40 is exactly what it should be, in *all* cases, regardless of what
follows the BITMAPINFOHEADER. Read below.



The spec says:
"A stream format chunk ('strf') must follow the stream header chunk.
The stream format chunk describes the format of the data in the
stream. The data contained in this chunk depends on the stream type.
For video streams, the information is a BITMAPINFO structure,
including palette information if appropriate. For audio streams, the
information is a WAVEFORMATEX structure."

If that chunk is a BITMAPINFO structure + a palette then formats
without a palette would likely have biSize similar to the chunk
size ...

its quite possible iam missing some details of course ...



You're missing the specification of the BITMAPINFOHEADER. It states that
biSize is the size of the structure, i.e. the BITMAPINFOHEADER itself.
No less, no more.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd183376%28v=vs.85%29.aspx

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 04:37 PM, Mats Peterson wrote:

On 03/12/2016 04:33 PM, Mats Peterson wrote:

On 03/12/2016 04:29 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc
chunks
works properly at least.

Try playing the resulting test.avi file from the command line
below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17
00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised
value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at least?


patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.


40 is exactly what it should be, in *all* cases, regardless of what
follows the BITMAPINFOHEADER. Read below.



The spec says:
"A stream format chunk ('strf') must follow the stream header chunk.
The stream format chunk describes the format of the data in the
stream. The data contained in this chunk depends on the stream type.
For video streams, the information is a BITMAPINFO structure,
including palette information if appropriate. For audio streams, the
information is a WAVEFORMATEX structure."

If that chunk is a BITMAPINFO structure + a palette then formats
without a palette would likely have biSize similar to the chunk
size ...

its quite possible iam missing some details of course ...



You're missing the specification of the BITMAPINFOHEADER. It states that
biSize is the size of the structure, i.e. the BITMAPINFOHEADER itself.
No less, no more.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd183376%28v=vs.85%29.aspx





Now, the HuffYUV author has invented his own 

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 04:33 PM, Mats Peterson wrote:

On 03/12/2016 04:29 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc chunks
works properly at least.

Try playing the resulting test.avi file from the command line below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17
00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at least?


patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.


40 is exactly what it should be, in *all* cases, regardless of what
follows the BITMAPINFOHEADER. Read below.



The spec says:
"A stream format chunk ('strf') must follow the stream header chunk.
The stream format chunk describes the format of the data in the
stream. The data contained in this chunk depends on the stream type.
For video streams, the information is a BITMAPINFO structure,
including palette information if appropriate. For audio streams, the
information is a WAVEFORMATEX structure."

If that chunk is a BITMAPINFO structure + a palette then formats
without a palette would likely have biSize similar to the chunk
size ...

its quite possible iam missing some details of course ...



You're missing the specification of the BITMAPINFOHEADER. It states that
biSize is the size of the structure, i.e. the BITMAPINFOHEADER itself.
No less, no more.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd183376%28v=vs.85%29.aspx




Now, the HuffYUV author has invented his own spec-breaking 
BITMAPINFOHEADER, and for 

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 04:29 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc chunks
works properly at least.

Try playing the resulting test.avi file from the command line below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at least?


patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.


40 is exactly what it should be, in *all* cases, regardless of what 
follows the BITMAPINFOHEADER. Read below.




The spec says:
"A stream format chunk ('strf') must follow the stream header chunk. The stream 
format chunk describes the format of the data in the stream. The data contained in this 
chunk depends on the stream type. For video streams, the information is a BITMAPINFO 
structure, including palette information if appropriate. For audio streams, the 
information is a WAVEFORMATEX structure."

If that chunk is a BITMAPINFO structure + a palette then formats
without a palette would likely have biSize similar to the chunk
size ...

its quite possible iam missing some details of course ...



You're missing the specification of the BITMAPINFOHEADER. It states that 
biSize is the size of the structure, i.e. the BITMAPINFOHEADER itself. 
No less, no more.


https://msdn.microsoft.com/en-us/library/windows/desktop/dd183376%28v=vs.85%29.aspx

Mats

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 02:54:45PM +0100, Mats Peterson wrote:
> On 03/12/2016 02:52 PM, Michael Niedermayer wrote:
> >On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:
> >>On 03/12/2016 02:26 PM, Mats Peterson wrote:
> >>>On 03/12/2016 12:53 PM, Michael Niedermayer wrote:
> On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:
> >Here's an interesting one. Windows Media Player won't make any palette
> >changes without the xxpc chunks beeing indexed.
> >
> >Fixing the logic for reading and seeking with xxpc chunks in the
> >demuxer  is a future task. Now the muxing of video with xxpc chunks
> >works properly at least.
> >
> >Try playing the resulting test.avi file from the command line below
> >with Windows Media Player, with and without this patch.
> >
> >ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi
> >
> >Mats
> >
> >--
> >Mats Peterson
> >http://matsp888.no-ip.org/~mats/
> 
> >  libavformat/avi.h|6 +++-
> >  libavformat/avienc.c |   56
> >+--
> >  tests/ref/lavf-fate/avi_cram |4 +--
> >  3 files changed, 51 insertions(+), 15 deletions(-)
> >2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
> >0002-Add-xxpc-entries-to-index.patch
> > From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00 2001
> >From: Mats Peterson 
> >Date: Sat, 12 Mar 2016 07:00:33 +0100
> >Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index
> >
> >---
> >  libavformat/avi.h|6 -
> >  libavformat/avienc.c |   56
> >+-
> >  tests/ref/lavf-fate/avi_cram |4 +--
> >  3 files changed, 51 insertions(+), 15 deletions(-)
> >
> >diff --git a/libavformat/avi.h b/libavformat/avi.h
> >index 34da76f..af21f2c 100644
> >--- a/libavformat/avi.h
> >+++ b/libavformat/avi.h
> >@@ -32,7 +32,11 @@
> >  #define AVI_MASTER_INDEX_SIZE   256
> >  #define AVI_MAX_STREAM_COUNT100
> >
> >+/* stream header flags */
> >+#define AVISF_VIDEO_PALCHANGES  0x0001
> >+
> >  /* index flags */
> >-#define AVIIF_INDEX 0x10
> >+#define AVIIF_INDEX 0x0010
> >+#define AVIIF_NO_TIME   0x0100
> >
> >  #endif /* AVFORMAT_AVI_H */
> >diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> >index ad50379..b731bc2 100644
> >--- a/libavformat/avienc.c
> >+++ b/libavformat/avienc.c
> >@@ -44,13 +44,14 @@
> >   */
> >
> >  typedef struct AVIIentry {
> >-unsigned int flags, pos, len;
> >+char tag[5];
> 
> the tag should be 4 bytes
> 5 is ugly, it requires padding and bloats the structure with a zero
> byte
> 
> >>>
> >>>OK.
> >>>
> 
> >+unsigned int flags;
> >+unsigned int pos;
> >+unsigned int len;
> >  } AVIIentry;
> >
> >  #define AVI_INDEX_CLUSTER_SIZE 16384
> >
> >-#define AVISF_VIDEO_PALCHANGES 0x0001
> >-
> >  typedef struct AVIIndex {
> >  int64_t indx_start;
> >  int64_t audio_strm_offset;
> 
> >@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
> >  }
> >  if (!empty) {
> >  avist = s->streams[stream_id]->priv_data;
> >-avi_stream2fourcc(tag, stream_id,
> >+if (*ie->tag)
> 
> ==18406== Conditional jump or move depends on uninitialised value(s,
> ==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
> ==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
> ==18406==by 0x64A234: av_write_trailer (mux.c:1124)
> ==18406==by 0x43A729: transcode (ffmpeg.c:4173)
> ==18406==by 0x43ACE3: main (ffmpeg.c:4334)
> 
> >>>
> >>>OK.
> >>
> >>
> >>It's not really uninitalised, is it? Since it isn't used by anything
> >>but my own code, it's all zero bytes, right?
> >
> >after this patch snow encoding failed, i run valgrind and saw this
> >so there was something wrong, i dont know for sure if it was this
> >
> >
> 
> OK. By the way, are you in the process of applying patch 1 at least?

patch one has a list of exceptions, this list contains every single
case for which evidence has been provided
that is all evidence provided so far is consistent in that a biSize
of 40 is wrong for non palette global headers.
It sure might be that the evidence is biased by bad luck as its only
few codecs we looked at in detail but still

also to justify this a bit more through the spec

The spec says:
"A stream format chunk ('strf') must follow the stream header chunk. The stream 
format chunk describes the format of the data in the stream. The data contained 
in this chunk depends on the stream type. For video streams, the information is 
a 

[FFmpeg-devel] [PATCH 2/2 v3] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

Forgot to check return values from avi_add_ientry(). Original 
description follows:


Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks being indexed.

Fixing the logic for reading and seeking with xxpc chunks in the demuxer 
 is a future task. Now the muxing of video with xxpc chunks works 
properly at least.


Try playing the resulting test.avi file from the command line below with 
Windows Media Player, with and without this patch.


ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From dde62d49f69c0685eb3fe704ec58d45017be64a2 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 16:18:36 +0100
Subject: [PATCH 2/2 v3] lavf/avienc: Add xxpc entries to index

---
 libavformat/avi.h|6 ++-
 libavformat/avienc.c |  100 --
 tests/ref/lavf-fate/avi_cram |4 +-
 3 files changed, 73 insertions(+), 37 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
 #define AVI_MASTER_INDEX_SIZE   256
 #define AVI_MAX_STREAM_COUNT100
 
+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
 /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100
 
 #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b48fa9c 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
  */
 
 typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[4];
+unsigned int flags;
+unsigned int pos;
+unsigned int len;
 } AVIIentry;
 
 #define AVI_INDEX_CLUSTER_SIZE 16384
 
-#define AVISF_VIDEO_PALCHANGES 0x0001
-
 typedef struct AVIIndex {
 int64_t indx_start;
 int64_t audio_strm_offset;
@@ -96,6 +97,43 @@ static inline AVIIentry *avi_get_ientry(const AVIIndex *idx, int ent_id)
 return >cluster[cl][id];
 }
 
+static int avi_add_ientry(AVFormatContext *s, int stream_index, char *tag,
+  unsigned int flags, unsigned int size)
+{
+AVIContext *avi  = s->priv_data;
+AVIOContext *pb  = s->pb;
+AVIStream *avist = s->streams[stream_index]->priv_data;
+AVIIndex *idx= >indexes;
+int cl   = idx->entry / AVI_INDEX_CLUSTER_SIZE;
+int id   = idx->entry % AVI_INDEX_CLUSTER_SIZE;
+
+if (idx->ents_allocated <= idx->entry) {
+idx->cluster = av_realloc_f(idx->cluster, sizeof(void*), cl+1);
+if (!idx->cluster) {
+idx->ents_allocated = 0;
+idx->entry  = 0;
+return AVERROR(ENOMEM);
+}
+idx->cluster[cl] =
+av_malloc(AVI_INDEX_CLUSTER_SIZE * sizeof(AVIIentry));
+if (!idx->cluster[cl])
+return AVERROR(ENOMEM);
+idx->ents_allocated += AVI_INDEX_CLUSTER_SIZE;
+}
+
+if (tag)
+memcpy(idx->cluster[cl][id].tag, tag, 4);
+else
+*(idx->cluster[cl][id].tag) = '\0';
+idx->cluster[cl][id].flags = flags;
+idx->cluster[cl][id].pos   = avio_tell(pb) - avi->movi_list;
+idx->cluster[cl][id].len   = size;
+avist->max_size = FFMAX(avist->max_size, size);
+idx->entry++;
+
+return 0;
+}
+
 static int64_t avi_start_new_riff(AVFormatContext *s, AVIOContext *pb,
   const char *riff_tag, const char *list_tag)
 {
@@ -612,9 +650,13 @@ static int avi_write_idx1(AVFormatContext *s)
 }
 if (!empty) {
 avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)
+ffio_wfourcc(pb, ie->tag);
+else {
+avi_stream2fourcc(tag, stream_id,
   s->streams[stream_id]->codec->codec_type);
-ffio_wfourcc(pb, tag);
+ffio_wfourcc(pb, tag);
+}
 avio_wl32(pb, ie->flags);
 avio_wl32(pb, ie->pos);
 avio_wl32(pb, ie->len);
@@ -654,6 +696,7 @@ static int write_skip_frames(AVFormatContext *s, int stream_index, int64_t dts)
 return 0;
 }
 
+
 static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 const int stream_index = pkt->stream_index;
@@ -709,6 +752,20 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 unsigned char tag[5];
 avi_stream2fourcc(tag, stream_index, enc->codec_type);
 tag[2] = 'p'; tag[3] = 'c';
+if (s->pb->seekable) {
+int ret;
+if (avist->strh_flags_offset) {
+int64_t cur_offset = avio_tell(pb);
+

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_quantization: use cbrt table

[Ganesh Ajjanagadde]

On Fri, Mar 11, 2016 at 3:05 AM, Reimar Döffinger
 wrote:
> On 11.03.2016, at 03:48, Ganesh Ajjanagadde  wrote:
>
>> On Thu, Mar 10, 2016 at 3:12 AM, Reimar Döffinger
>>  wrote:
>>> On 10.03.2016, at 00:49, Ganesh Ajjanagadde  wrote:
>>>
 There is no reason for computing cbrtf at runtime; we have a table for
 this.

 Cruft needed due to the build system, the people who still like using
 hardcoded tables and need for single cbrt_tab across the code.
>>>
>>> Could you please explain what exactly the problem is?
>>> Why would you need cbrt_table.c for example? You can just conditionally 
>>> include it from cbrt_data.c for example.
>>> Hardcoded tables are meant to only change when the initialization code is 
>>> run, not where the resulting data is located, i.e. it should only ever 
>>> replace a
>>> int table[size];
>>> by
>>> const int table[size] = { data };
>>> (though with the indirection of placing the second one in a header)
>>
>> The data can't go into a header; else one gets multiple copies, see
>> above. Please not that I may still be missing something; this
>> hardcoded ifdefry and build system is something I am not that familiar
>> with.
>
> You just include the header in the C file (and only that one) where you want 
> the data to be.
> Obviously if you do not want multiple copies that will be some shared C file, 
> not the encoder or decoder code directly.
> But the same applies to the non-hardcoded tables, they also need a shared 
> file or else you get two copies in the bss section.
> I really don't see why the issue you describe should need anything other than 
> replacing a
> int ff_something[size];
> by
> #if hardcodec
> #include "something_table.h"
> #else
> ff_something[size];
> #endif
>
> hardcoding should _never_ ever require changing the code structure or the .c 
> files compiled in.
> It should only consist of
> 1) generating a table header (can get a bit tricky admittedly, this should be 
> the most difficult step)
> 2) including that header instead of the code otherwise creating the 
> uninitialised table in .bss
> 3) disabling the code that initializes the table
>
> Nothing magic beyond that.

Ok. Let me put it this way: I have a super simple patch that simply
moves stuff to cbrt_data.c and works perfectly well under default
configure, with no changes to the Makefile apart from adding
cbrt_data.o to the list of objects for AAC.

As soon as I test under --enable-hardcoded-tables, I get linker errors
during the host table generation phase due to undefined ff_cbrt_tab,
etc. I also know why they occur: I declare ff_cbrt_tab as extern in
cbrt_tablegen.h, so basically during host generation phase cbrt_data.c
needs to also get compiled in, where the implementation is done. But
the host gen simply #includes cbrt_tablegen.h, sees the extern
declaration (since during host gen it #defs hardcoded to 0, that is
how it gets the "magic" done), does not find the implementation, and
naturally complains.

So one could of course duplicate the code in tablegen_template etc and
not #include cbrt_tablegen, it can actually be very short since we
don't care about efficiency there and the fancy current algorithm does
not need to be used.

But whatever it is, be it Makefile chicanery or some ad-hoc methods
like above, something needs to be done; there is no "natural"
solution.

TL;DR: I am not going to waste time on this. Anyone wants to do it, it
is conceptually trivial.

> ___
> 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 2/2 v2] lavf/avienc: Add 'xxpc' entries to index

[Mats Peterson]

Made some changes based on your comments, Michael.

Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks being indexed.

Fixing the logic for reading and seeking with xxpc chunks in the demuxer 
 is a future task. Now the muxing of video with xxpc chunks works 
properly at least.


Try playing the resulting test.avi file from the command line below with 
Windows Media Player, with and without this patch.


ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats
>From 44c4c77d7bfbab1ff014192a4812ccbe80c0ca02 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 16:00:17 +0100
Subject: [PATCH 2/2 v2] lavf/avienc: Add 'xxpc' entries to index

---
 libavformat/avi.h|6 ++-
 libavformat/avienc.c |   97 ++
 tests/ref/lavf-fate/avi_cram |4 +-
 3 files changed, 68 insertions(+), 39 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
 #define AVI_MASTER_INDEX_SIZE   256
 #define AVI_MAX_STREAM_COUNT100
 
+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
 /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100
 
 #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..7ee35ce 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
  */
 
 typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[4];
+unsigned int flags;
+unsigned int pos;
+unsigned int len;
 } AVIIentry;
 
 #define AVI_INDEX_CLUSTER_SIZE 16384
 
-#define AVISF_VIDEO_PALCHANGES 0x0001
-
 typedef struct AVIIndex {
 int64_t indx_start;
 int64_t audio_strm_offset;
@@ -96,6 +97,43 @@ static inline AVIIentry *avi_get_ientry(const AVIIndex *idx, int ent_id)
 return >cluster[cl][id];
 }
 
+static int avi_add_ientry(AVFormatContext *s, int stream_index, char *tag,
+  unsigned int flags, unsigned int size)
+{
+AVIContext *avi  = s->priv_data;
+AVIOContext *pb  = s->pb;
+AVIStream *avist = s->streams[stream_index]->priv_data;
+AVIIndex *idx= >indexes;
+int cl   = idx->entry / AVI_INDEX_CLUSTER_SIZE;
+int id   = idx->entry % AVI_INDEX_CLUSTER_SIZE;
+
+if (idx->ents_allocated <= idx->entry) {
+idx->cluster = av_realloc_f(idx->cluster, sizeof(void*), cl+1);
+if (!idx->cluster) {
+idx->ents_allocated = 0;
+idx->entry  = 0;
+return AVERROR(ENOMEM);
+}
+idx->cluster[cl] =
+av_malloc(AVI_INDEX_CLUSTER_SIZE * sizeof(AVIIentry));
+if (!idx->cluster[cl])
+return AVERROR(ENOMEM);
+idx->ents_allocated += AVI_INDEX_CLUSTER_SIZE;
+}
+
+if (tag)
+memcpy(idx->cluster[cl][id].tag, tag, 4);
+else
+*(idx->cluster[cl][id].tag) = '\0';
+idx->cluster[cl][id].flags = flags;
+idx->cluster[cl][id].pos   = avio_tell(pb) - avi->movi_list;
+idx->cluster[cl][id].len   = size;
+avist->max_size = FFMAX(avist->max_size, size);
+idx->entry++;
+
+return 0;
+}
+
 static int64_t avi_start_new_riff(AVFormatContext *s, AVIOContext *pb,
   const char *riff_tag, const char *list_tag)
 {
@@ -612,9 +650,13 @@ static int avi_write_idx1(AVFormatContext *s)
 }
 if (!empty) {
 avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)
+ffio_wfourcc(pb, ie->tag);
+else {
+avi_stream2fourcc(tag, stream_id,
   s->streams[stream_id]->codec->codec_type);
-ffio_wfourcc(pb, tag);
+ffio_wfourcc(pb, tag);
+}
 avio_wl32(pb, ie->flags);
 avio_wl32(pb, ie->pos);
 avio_wl32(pb, ie->len);
@@ -654,6 +696,7 @@ static int write_skip_frames(AVFormatContext *s, int stream_index, int64_t dts)
 return 0;
 }
 
+
 static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 const int stream_index = pkt->stream_index;
@@ -709,6 +752,17 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 unsigned char tag[5];
 avi_stream2fourcc(tag, stream_index, enc->codec_type);
 tag[2] = 'p'; tag[3] = 'c';
+if (s->pb->seekable) {
+if (avist->strh_flags_offset) {
+int64_t cur_offset = avio_tell(pb);
+avio_seek(pb, avist->strh_flags_offset, SEEK_SET);
+avio_wl32(pb, 

Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 02:40:25AM -0800, Sasi Inguva wrote:
> Fill DTS if all packets have been read in avformat_find_stream_info, and still
> has_decode_delay_been_guessed returns false.
> 
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/utils.c |  77 ++---
>  tests/fate/h264.mak |   3 +
>  tests/ref/fate/h264-dts_5frames | 125 
> 
>  3 files changed, 184 insertions(+), 21 deletions(-)
>  create mode 100644 tests/ref/fate/h264-dts_5frames

applied

thanks

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

For every action, there is an equal and opposite reaction. -- Newton
For every man jailed for a minor crime, theres one person more that
will hate the government, some of them will become terrorists.


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

Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[Thilo Borgmann]

Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
> Add coreimage filter for OSX.

Corrected patch attached.

-Thilo

From 124fb0ce2a30c965ec28c8fbff1c04a872f33bc6 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 12 Mar 2016 15:18:04 +0100
Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
 on OSX.

---
 Changelog  |   1 +
 MAINTAINERS|   1 +
 configure  |   3 +
 doc/filters.texi   |  67 ++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_coreimage.m | 553 +
 7 files changed, 627 insertions(+)
 create mode 100644 libavfilter/vf_coreimage.m

diff --git a/Changelog b/Changelog
index 1f57f5e..5053a86 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
 - ciescope filter
 - protocol blacklisting API
 - MediaCodec H264 decoding
+- coreimage filter (GPU based image filtering on OSX)
 
 
 version 3.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 531c21d..a993a67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -370,6 +370,7 @@ Filters:
   vf_colorbalance.c Paul B Mahol
   vf_colorkey.c Timo Rothenpieler
   vf_colorlevels.c  Paul B Mahol
+  vf_coreimage.mThilo Borgmann
   vf_deband.c   Paul B Mahol
   vf_dejudder.c Nicholas Robbins
   vf_delogo.c   Jean Delvare (CC )
diff --git a/configure b/configure
index 1b189328..fe96215 100755
--- a/configure
+++ b/configure
@@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
 frei0r_src_filter_extralibs='$ldl'
 ladspa_filter_extralibs='$ldl'
 nvenc_encoder_extralibs='$ldl'
+coreimage_filter_extralibs="-framework QuartzCore -framework AppKit -framework 
OpenGL"
 
 if ! disabled network; then
 check_func getaddrinfo $network_extralibs
@@ -5483,6 +5484,8 @@ enabled avisynth  && { { check_lib2 "windows.h" 
LoadLibrary; } ||
die "ERROR: LoadLibrary/dlopen not found for 
avisynth"; }
 enabled cuda  && check_lib cuda.h cuInit -lcuda
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
+enabled coreimage && { check_header_oc CoreImage/CoreImage.h || die 
"ERROR: CoreImage.h header not found"; }
+#enabled coreimage && { check_lib2 CoreImage/CoreImage.h 
CGGetActiveDisplayList -framework CoreImage; }
 enabled decklink  && { check_header DeckLinkAPI.h || die "ERROR: 
DeckLinkAPI.h header not found"; }
 enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h 
header not found"; }
 enabled gmp   && require2 gmp gmp.h mpz_export -lgmp
diff --git a/doc/filters.texi b/doc/filters.texi
index d5d619e..7fdbe61 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4955,6 +4955,73 @@ convolution="-2 -1 0 -1 1 1 0 1 2:-2 -1 0 -1 1 1 0 1 
2:-2 -1 0 -1 1 1 0 1 2:-2 -
 Copy the input source unchanged to the output. This is mainly useful for
 testing purposes.
 
+@anchor{coreimage}
+@section coreimage
+
+Video filtering on GPU using Apple's CoreImage API on OSX.
+
+Hardware acceleration is based on an OpenGL context. Usually, this means it is 
processed by video hardware. However, software-based OpenGL implementations 
exist which means there is no guarantee for hardware processing. It depends on 
the respective OSX.
+
+There are many filters and image generators provided by Apple that come with a 
large variety of options. The filter has to be referenced by its name along 
with its options.
+
+The coreimage filter accepts the following options:
+@table @option
+@item list_filters
+List all available filters along with all their respective options as well as 
possible minimum and maximum values along with the default values.
+@example
+coreimage=list_filters=true
+@end example
+
+@item filter
+Specifiy all filters by their respective name and options.
+Use @option{list_filters} to determine all valid filter names and options.
+Numerical options are specified by a float value and are automatically clamped 
to their respective value range.
+Vector and color options have to be specified by a list of space separated 
float values. Character escaping has to be done.
+A special option name @code{default} is available to use default options for a 
filter.
+It is required to specify either @code{default} or at least one of the filter 
options.
+All omitted options are used with their default values.
+The syntax of the filter string is as follows:
+@example
+filter=@=[@=][@...][#@=[@=][@...]]
+@end example
+@end table
+
+Several filters can be chained for successive processing without GPU-HOST 
transfers allowing for fast processing of complex filter chains.
+Currently, only filters with zero (generators) or exactly one (filters) input 
image and one output 

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 03:00 PM, Mats Peterson wrote:

On 03/12/2016 02:54 PM, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc chunks
works properly at least.

Try playing the resulting test.avi file from the command line below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00
2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this



In what way did snow encoding fail? It works just fine here, Michael.

Mats

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

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)

[Ganesh Ajjanagadde]

On Sat, Mar 12, 2016 at 9:15 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Sat, Mar 12, 2016 at 9:03 AM, Ganesh Ajjanagadde 
> wrote:
>
>> On Fri, Mar 11, 2016 at 9:30 AM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Thu, Mar 10, 2016 at 9:23 PM, Ganesh Ajjanagadde 
>> > wrote:
>> >
>> >> On Thu, Mar 10, 2016 at 8:56 AM, Ronald S. Bultje 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Thu, Mar 10, 2016 at 2:37 AM, Reimar Döffinger <
>> >> reimar.doeffin...@gmx.de>
>> >> > wrote:
>> >> >
>> >> >> On 10.03.2016, at 03:06, Ganesh Ajjanagadde 
>> wrote:
>> >> >>
>> >> >> > On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
>> >> >> >  wrote:
>> >> >> >> On 08.03.2016, at 04:48, Ganesh Ajjanagadde 
>> >> wrote:
>> >> >> >>
>> >> >> >>> +nzl += expf(logf(s / ethresh) * nzslope);
>> >> >> >>
>> >> >> >> Shouldn't log2f/exp2f be faster?
>> >> >> >> log2f at least has CPU support on x86 AFAICT.
>> >> >> >
>> >> >> > I had tested this, and no, though it is still faster than powf.
>> >> >> >
>> >> >> > It still seems to rely on libm, note that we don't use -ffast-math
>> and
>> >> >> > a look at
>> >> >> https://github.com/lattera/glibc/tree/master/sysdeps/x86_64/fpu
>> >> >> > as well seems to say no. Problem is, GNU people like to prioritize
>> >> >> > "correctly rounded" behavior over fast, reasonably accurate code,
>> >> >> > sometimes to ludicruous degrees.
>> >> >> >
>> >> >> > Personally, I don't know why we don't use -ffast-math, not many
>> seem
>> >> >> > to care that heavily on strict IEEE semantics. Maybe it leads to
>> too
>> >> >> > much variation across platforms?
>> >> >>
>> >> >> You lose some guarantees. In particular, the compiler will assume
>> NaNs
>> >> do
>> >> >> not happen and you cannot predict which code path (after a comparison
>> >> for
>> >> >> example) they take.
>> >> >> But some code for either security or correctness reasons needs them
>> to
>> >> be
>> >> >> handled a certain way.
>> >> >> I guess in theory you could try to make sure fisnan is used in all
>> those
>> >> >> cases, but then you need to find them, and I think if you take
>> >> -ffast-math
>> >> >> description literally there is no guarantee that even fisnan
>> continues
>> >> to
>> >> >> work... I am also not sure none of the code relies on order of
>> >> operations
>> >> >> to get the precision it needs.
>> >> >> So it is simply too dangerous.
>> >> >> Some more specific options might be possible to use though (but I
>> think
>> >> >> even full -ffast-math gains you almost nothing? Does it even help
>> >> here?).
>> >>
>> >> Yes, sorry, I meant some specific things from -ffast-math. I checked
>> >> configure, most of the unambiguously clear ones are already being
>> >> turned on. As such, it seems ok.
>> >>
>> >> >
>> >> >
>> >> > One could also consider writing some customized assembly (calling the
>> >> > relevant instructions instead of C wrappers) in cases where it is
>> >> > speed-sensitive. It's sort of the inverse of what Ganesh is
>> suggesting, I
>> >> > guess, maybe some more effort involved but it can't be that much. You
>> >> could
>> >> > even use av_always_inline functions and inline assembly to call the
>> >> > relevant instruction and otherwise keep things in C. That's identical
>> to
>> >> > what -ffast-math does but turns on only when specifically calling the
>> new
>> >> > API function name...
>> >>
>> >> So seems like everything wrt this patch is fine, right?
>> >
>> >
>> > Not really. Your patch still does two things, and I don't like the
>> explicit
>> > exp(log(a)*b).
>>
>> Well, both are needed for the speedup. Without the 2.0 check, there is
>> a speed regression. I don't understand why it is "two things" in that
>> case.
>>
>> > What I'm thinking is that you should have a static inline
>> > function, let's call it fast_pow(a, b), which can internally (in the C
>> > version) be implemented as exp+log. Just as you found for pow, we might
>> > find that for exp/log, the system lib is not very optimized and we can do
>> > it faster ourselves by doing whatever -ffast-math is doing for these
>> > functions. Those would be more specifically optimized and that would be
>> > part of the fast_pow implementation. This way, the code in aacenc remains
>> > easy to follow and the optimization is accessible for other parts of
>> ffmpeg
>> > also.
>>
>> Ok, changed locally.
>
>
> Please submit a new patch, this is not a minor cosmetic change.

I definitely will, just was addressing your first point and making it
clear why I did it that way, so that I don't waste effort.

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

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)

[Ronald S. Bultje]

Hi,

On Sat, Mar 12, 2016 at 9:03 AM, Ganesh Ajjanagadde 
wrote:

> On Fri, Mar 11, 2016 at 9:30 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Thu, Mar 10, 2016 at 9:23 PM, Ganesh Ajjanagadde 
> > wrote:
> >
> >> On Thu, Mar 10, 2016 at 8:56 AM, Ronald S. Bultje 
> >> wrote:
> >> > Hi,
> >> >
> >> > On Thu, Mar 10, 2016 at 2:37 AM, Reimar Döffinger <
> >> reimar.doeffin...@gmx.de>
> >> > wrote:
> >> >
> >> >> On 10.03.2016, at 03:06, Ganesh Ajjanagadde 
> wrote:
> >> >>
> >> >> > On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
> >> >> >  wrote:
> >> >> >> On 08.03.2016, at 04:48, Ganesh Ajjanagadde 
> >> wrote:
> >> >> >>
> >> >> >>> +nzl += expf(logf(s / ethresh) * nzslope);
> >> >> >>
> >> >> >> Shouldn't log2f/exp2f be faster?
> >> >> >> log2f at least has CPU support on x86 AFAICT.
> >> >> >
> >> >> > I had tested this, and no, though it is still faster than powf.
> >> >> >
> >> >> > It still seems to rely on libm, note that we don't use -ffast-math
> and
> >> >> > a look at
> >> >> https://github.com/lattera/glibc/tree/master/sysdeps/x86_64/fpu
> >> >> > as well seems to say no. Problem is, GNU people like to prioritize
> >> >> > "correctly rounded" behavior over fast, reasonably accurate code,
> >> >> > sometimes to ludicruous degrees.
> >> >> >
> >> >> > Personally, I don't know why we don't use -ffast-math, not many
> seem
> >> >> > to care that heavily on strict IEEE semantics. Maybe it leads to
> too
> >> >> > much variation across platforms?
> >> >>
> >> >> You lose some guarantees. In particular, the compiler will assume
> NaNs
> >> do
> >> >> not happen and you cannot predict which code path (after a comparison
> >> for
> >> >> example) they take.
> >> >> But some code for either security or correctness reasons needs them
> to
> >> be
> >> >> handled a certain way.
> >> >> I guess in theory you could try to make sure fisnan is used in all
> those
> >> >> cases, but then you need to find them, and I think if you take
> >> -ffast-math
> >> >> description literally there is no guarantee that even fisnan
> continues
> >> to
> >> >> work... I am also not sure none of the code relies on order of
> >> operations
> >> >> to get the precision it needs.
> >> >> So it is simply too dangerous.
> >> >> Some more specific options might be possible to use though (but I
> think
> >> >> even full -ffast-math gains you almost nothing? Does it even help
> >> here?).
> >>
> >> Yes, sorry, I meant some specific things from -ffast-math. I checked
> >> configure, most of the unambiguously clear ones are already being
> >> turned on. As such, it seems ok.
> >>
> >> >
> >> >
> >> > One could also consider writing some customized assembly (calling the
> >> > relevant instructions instead of C wrappers) in cases where it is
> >> > speed-sensitive. It's sort of the inverse of what Ganesh is
> suggesting, I
> >> > guess, maybe some more effort involved but it can't be that much. You
> >> could
> >> > even use av_always_inline functions and inline assembly to call the
> >> > relevant instruction and otherwise keep things in C. That's identical
> to
> >> > what -ffast-math does but turns on only when specifically calling the
> new
> >> > API function name...
> >>
> >> So seems like everything wrt this patch is fine, right?
> >
> >
> > Not really. Your patch still does two things, and I don't like the
> explicit
> > exp(log(a)*b).
>
> Well, both are needed for the speedup. Without the 2.0 check, there is
> a speed regression. I don't understand why it is "two things" in that
> case.
>
> > What I'm thinking is that you should have a static inline
> > function, let's call it fast_pow(a, b), which can internally (in the C
> > version) be implemented as exp+log. Just as you found for pow, we might
> > find that for exp/log, the system lib is not very optimized and we can do
> > it faster ourselves by doing whatever -ffast-math is doing for these
> > functions. Those would be more specifically optimized and that would be
> > part of the fast_pow implementation. This way, the code in aacenc remains
> > easy to follow and the optimization is accessible for other parts of
> ffmpeg
> > also.
>
> Ok, changed locally.


Please submit a new patch, this is not a minor cosmetic change.

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

[FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.

[Thilo Borgmann]

Add coreimage filter for OSX.

-Thilo
From 82c98fc9e27655e3e9b32adbf4122f94649359c5 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 12 Mar 2016 14:54:49 +0100
Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
 on OSX.

---
 Changelog|  1 +
 MAINTAINERS  |  1 +
 configure|  3 +++
 doc/filters.texi | 67 
 libavfilter/Makefile |  1 +
 libavfilter/allfilters.c |  1 +
 6 files changed, 74 insertions(+)

diff --git a/Changelog b/Changelog
index 1f57f5e..5053a86 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
 - ciescope filter
 - protocol blacklisting API
 - MediaCodec H264 decoding
+- coreimage filter (GPU based image filtering on OSX)
 
 
 version 3.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 531c21d..a993a67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -370,6 +370,7 @@ Filters:
   vf_colorbalance.c Paul B Mahol
   vf_colorkey.c Timo Rothenpieler
   vf_colorlevels.c  Paul B Mahol
+  vf_coreimage.mThilo Borgmann
   vf_deband.c   Paul B Mahol
   vf_dejudder.c Nicholas Robbins
   vf_delogo.c   Jean Delvare (CC )
diff --git a/configure b/configure
index 1b189328..fe96215 100755
--- a/configure
+++ b/configure
@@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
 frei0r_src_filter_extralibs='$ldl'
 ladspa_filter_extralibs='$ldl'
 nvenc_encoder_extralibs='$ldl'
+coreimage_filter_extralibs="-framework QuartzCore -framework AppKit -framework 
OpenGL"
 
 if ! disabled network; then
 check_func getaddrinfo $network_extralibs
@@ -5483,6 +5484,8 @@ enabled avisynth  && { { check_lib2 "windows.h" 
LoadLibrary; } ||
die "ERROR: LoadLibrary/dlopen not found for 
avisynth"; }
 enabled cuda  && check_lib cuda.h cuInit -lcuda
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
+enabled coreimage && { check_header_oc CoreImage/CoreImage.h || die 
"ERROR: CoreImage.h header not found"; }
+#enabled coreimage && { check_lib2 CoreImage/CoreImage.h 
CGGetActiveDisplayList -framework CoreImage; }
 enabled decklink  && { check_header DeckLinkAPI.h || die "ERROR: 
DeckLinkAPI.h header not found"; }
 enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h 
header not found"; }
 enabled gmp   && require2 gmp gmp.h mpz_export -lgmp
diff --git a/doc/filters.texi b/doc/filters.texi
index d5d619e..7fdbe61 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4955,6 +4955,73 @@ convolution="-2 -1 0 -1 1 1 0 1 2:-2 -1 0 -1 1 1 0 1 
2:-2 -1 0 -1 1 1 0 1 2:-2 -
 Copy the input source unchanged to the output. This is mainly useful for
 testing purposes.
 
+@anchor{coreimage}
+@section coreimage
+
+Video filtering on GPU using Apple's CoreImage API on OSX.
+
+Hardware acceleration is based on an OpenGL context. Usually, this means it is 
processed by video hardware. However, software-based OpenGL implementations 
exist which means there is no guarantee for hardware processing. It depends on 
the respective OSX.
+
+There are many filters and image generators provided by Apple that come with a 
large variety of options. The filter has to be referenced by its name along 
with its options.
+
+The coreimage filter accepts the following options:
+@table @option
+@item list_filters
+List all available filters along with all their respective options as well as 
possible minimum and maximum values along with the default values.
+@example
+coreimage=list_filters=true
+@end example
+
+@item filter
+Specifiy all filters by their respective name and options.
+Use @option{list_filters} to determine all valid filter names and options.
+Numerical options are specified by a float value and are automatically clamped 
to their respective value range.
+Vector and color options have to be specified by a list of space separated 
float values. Character escaping has to be done.
+A special option name @code{default} is available to use default options for a 
filter.
+It is required to specify either @code{default} or at least one of the filter 
options.
+All omitted options are used with their default values.
+The syntax of the filter string is as follows:
+@example
+filter=@=[@=][@...][#@=[@=][@...]]
+@end example
+@end table
+
+Several filters can be chained for successive processing without GPU-HOST 
transfers allowing for fast processing of complex filter chains.
+Currently, only filters with zero (generators) or exactly one (filters) input 
image and one output image are supported.
+Also, transition filters are not yet usable as intended.
+
+Some filters generate output images with additional padding depending on the 
respective filter 

[FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Multikey for AVDictionary.

-Thilo
From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 12 Mar 2016 14:52:17 +0100
Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

---
 libavutil/dict.c | 5 -
 libavutil/dict.h | 5 +++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavutil/dict.c b/libavutil/dict.c
index 8bb65a1..70c0184 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, const 
char *value,
 int flags)
 {
 AVDictionary *m = *pm;
-AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
+AVDictionaryEntry *tag = NULL;
 char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
 
+if (!(flags & AV_DICT_MULTIKEY)) {
+tag = av_dict_get(m, key, NULL, flags);
+}
 if (flags & AV_DICT_DONT_STRDUP_KEY)
 copy_key = (void *)key;
 else
diff --git a/libavutil/dict.h b/libavutil/dict.h
index b0aa784..c589bcd 100644
--- a/libavutil/dict.h
+++ b/libavutil/dict.h
@@ -76,6 +76,7 @@
 #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing entries.
 #define AV_DICT_APPEND 32   /**< If the entry already exists, append 
to it.  Note that no
   delimiter is added, the strings are 
simply concatenated. */
+#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal keys in 
the dictionary */
 
 typedef struct AVDictionaryEntry {
 char *key;
@@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
  *
  * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
  * a dictionary struct is allocated and put in *pm.
- * @param key entry key to add to *pm (will be av_strduped depending on flags)
- * @param value entry value to add to *pm (will be av_strduped depending on 
flags).
+ * @param key entry key to add to *pm (will either be av_strduped or added as 
a new key depending on flags)
+ * @param value entry value to add to *pm (will be av_strduped or added as a 
new key depending on flags).
  *Passing a NULL value will cause an existing entry to be deleted.
  * @return >= 0 on success otherwise an error code <0
  */
-- 
2.4.9 (Apple Git-60)

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

[FFmpeg-devel] [PATCH] Add coreimage filter for GPU based image filtering on OSX

[Thilo Borgmann]

Hi,

addressing ticket #4143.

This adds a basic filter for GPU filtering using Apple's Core Image API.
Current restrictions are that only 1-to-1 filters and 0-to-1 generators
are supported. N-to-N filters and transition filters are further work.

Also all processing is currently done for ARGB only. Other formats are
also further work.

Parsing the filter string is done by AVDictionary, unfortunately. I
could not find an easy way to convert it to a AVTree. At least for the
small amount of key-value pairs the speed penalty is negligible.

AVDictionary has been extended to allow multiple equal keys to be able
to chain several instances of the same filter(name) in a single call of
coreimage without GPU-CPU transfer.

More testing on some more MACs would also be appreciated.

Patch 1/2: AVDitionary changes
Patch 2/2: coreimage filter


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

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)

[Ganesh Ajjanagadde]

On Fri, Mar 11, 2016 at 9:30 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Thu, Mar 10, 2016 at 9:23 PM, Ganesh Ajjanagadde 
> wrote:
>
>> On Thu, Mar 10, 2016 at 8:56 AM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Thu, Mar 10, 2016 at 2:37 AM, Reimar Döffinger <
>> reimar.doeffin...@gmx.de>
>> > wrote:
>> >
>> >> On 10.03.2016, at 03:06, Ganesh Ajjanagadde  wrote:
>> >>
>> >> > On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
>> >> >  wrote:
>> >> >> On 08.03.2016, at 04:48, Ganesh Ajjanagadde 
>> wrote:
>> >> >>
>> >> >>> +nzl += expf(logf(s / ethresh) * nzslope);
>> >> >>
>> >> >> Shouldn't log2f/exp2f be faster?
>> >> >> log2f at least has CPU support on x86 AFAICT.
>> >> >
>> >> > I had tested this, and no, though it is still faster than powf.
>> >> >
>> >> > It still seems to rely on libm, note that we don't use -ffast-math and
>> >> > a look at
>> >> https://github.com/lattera/glibc/tree/master/sysdeps/x86_64/fpu
>> >> > as well seems to say no. Problem is, GNU people like to prioritize
>> >> > "correctly rounded" behavior over fast, reasonably accurate code,
>> >> > sometimes to ludicruous degrees.
>> >> >
>> >> > Personally, I don't know why we don't use -ffast-math, not many seem
>> >> > to care that heavily on strict IEEE semantics. Maybe it leads to too
>> >> > much variation across platforms?
>> >>
>> >> You lose some guarantees. In particular, the compiler will assume NaNs
>> do
>> >> not happen and you cannot predict which code path (after a comparison
>> for
>> >> example) they take.
>> >> But some code for either security or correctness reasons needs them to
>> be
>> >> handled a certain way.
>> >> I guess in theory you could try to make sure fisnan is used in all those
>> >> cases, but then you need to find them, and I think if you take
>> -ffast-math
>> >> description literally there is no guarantee that even fisnan continues
>> to
>> >> work... I am also not sure none of the code relies on order of
>> operations
>> >> to get the precision it needs.
>> >> So it is simply too dangerous.
>> >> Some more specific options might be possible to use though (but I think
>> >> even full -ffast-math gains you almost nothing? Does it even help
>> here?).
>>
>> Yes, sorry, I meant some specific things from -ffast-math. I checked
>> configure, most of the unambiguously clear ones are already being
>> turned on. As such, it seems ok.
>>
>> >
>> >
>> > One could also consider writing some customized assembly (calling the
>> > relevant instructions instead of C wrappers) in cases where it is
>> > speed-sensitive. It's sort of the inverse of what Ganesh is suggesting, I
>> > guess, maybe some more effort involved but it can't be that much. You
>> could
>> > even use av_always_inline functions and inline assembly to call the
>> > relevant instruction and otherwise keep things in C. That's identical to
>> > what -ffast-math does but turns on only when specifically calling the new
>> > API function name...
>>
>> So seems like everything wrt this patch is fine, right?
>
>
> Not really. Your patch still does two things, and I don't like the explicit
> exp(log(a)*b).

Well, both are needed for the speedup. Without the 2.0 check, there is
a speed regression. I don't understand why it is "two things" in that
case.

> What I'm thinking is that you should have a static inline
> function, let's call it fast_pow(a, b), which can internally (in the C
> version) be implemented as exp+log. Just as you found for pow, we might
> find that for exp/log, the system lib is not very optimized and we can do
> it faster ourselves by doing whatever -ffast-math is doing for these
> functions. Those would be more specifically optimized and that would be
> part of the fast_pow implementation. This way, the code in aacenc remains
> easy to follow and the optimization is accessible for other parts of ffmpeg
> also.

Ok, changed locally.

>
> Ronald
> ___
> 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]lavc/hevc: Support GBR encoding and decoding

[Carl Eugen Hoyos]

Moritz Barsnick  gmx.net> writes:

> > +case AV_PIX_FMT_GBRP:
> > +case AV_PIX_FMT_GBRP10:
> > +case AV_PIX_FMT_GBRP12:
> > +ctx->params->vui.matrixCoeffs = AVCOL_SPC_RGB;
> > +ctx->params->vui.bEnableVideoSignalTypePresentFlag  = 1;
> > +ctx->params->vui.bEnableColorDescriptionPresentFlag = 1;
> >  case AV_PIX_FMT_YUV444P:
> >  case AV_PIX_FMT_YUV444P10:
> >  case AV_PIX_FMT_YUV444P12:
> 
> Fallthrough intended?

Definitely.

> Might be worth documenting then, because reading
> such switch/cases can become confusing.

I believe we don't usually add a comment here, 
several files distinguish in a similar way between 
gbrp and yuv444p.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 02:54 PM, Mats Peterson wrote:

On 03/12/2016 02:52 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any
palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc chunks
works properly at least.

Try playing the resulting test.avi file from the command line below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00
2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised value(s,
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by anything
but my own code, it's all zero bytes, right?


after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this




OK. By the way, are you in the process of applying patch 1 at least?

Mats



I really don't like people who don't follow the AVI specs, using a 
biSize other than 40. But we could make an exception for HuffYUV, 
ffvhuff, asv1 and asv2.


Mats

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

Re: [FFmpeg-devel] [PATCH] lavu/lfg: switch to Ziggurat algorithm for normal random number generation

[Ganesh Ajjanagadde]

On Fri, Mar 11, 2016 at 8:56 AM, Michael Niedermayer
 wrote:
> On Thu, Mar 10, 2016 at 11:16:08PM -0500, Ganesh Ajjanagadde wrote:
[...]
>> +static inline double ziggurat(AVLFG *lfg)
>> +{
>> +while (1) {
>
>> +uint64_t r = (av_lfg_get(lfg) << 31) + av_lfg_get(lfg);
>
> this looks like undefined behavior


>
> also the numbers that come out of this look different

Sorry about this; the julia code had a 64 bit random number generator
that I emulated incorrectly. I also forgot that they use 1 based
indexing in one spot. Fixed and posted v2, this in fact fixes the
other issue as well.

Benches are updated, there is a slight variation.

Wrote a sample mean and stddev computation as a sanity check for the
future; I will add a proper normality test some time.

[...]
>
>
> --
> 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

[FFmpeg-devel] [PATCHv2 2/2] lavu/lfg: switch to Ziggurat algorithm for normal random number generation (WIP)

[Ganesh Ajjanagadde]

Code taken from the Julia project, licensed under MIT:
https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn
derived from: "The Ziggurat Method for generating random variables" - Marsaglia 
and Tsang.

Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is
well known to be the fastest method empirically for generating normal random
variables for a fixed PRNG source.

Note that there are a large number of implementations with
various tunings, this was one of the simpler ones and also has a friendly
license.

This results in ~ 3x speedup of random number generation:
old:
  15090 decicycles in av_bmg_get,   1 runs,  0 skips
  13140 decicycles in av_bmg_get,   2 runs,  0 skips
  10117 decicycles in av_bmg_get,   4 runs,  0 skips
  [...]
   2133 decicycles in av_bmg_get,  524268 runs, 20 skips=60.4x
   2134 decicycles in av_bmg_get, 1048531 runs, 45 skips=61.3x
   2135 decicycles in av_bmg_get, 2097061 runs, 91 skips=61.9x

new:
   7650 decicycles in av_gaussian_get,   1 runs,  0 skips
   5490 decicycles in av_gaussian_get,   2 runs,  0 skips
   3982 decicycles in av_gaussian_get,   4 runs,  0 skips
   [...]
812 decicycles in av_gaussian_get,  524281 runs,  7 skips
813 decicycles in av_gaussian_get, 1048563 runs, 13 skips
813 decicycles in av_gaussian_get, 2097131 runs, 21 skips

and accordingly a ~2% speedup in aac encoding (-march=native, Haswell, clang):

old:
ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac  5.30s user 0.02s system 99% 
cpu 5.322 total
new:
ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac  5.16s user 0.03s system 99% 
cpu 5.198 total

Function added as av_gaussian_get with documentation, minor bumped.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/aaccoder.c |   2 +-
 libavutil/lfg.c   | 304 +-
 libavutil/lfg.h   |   9 ++
 libavutil/version.h   |   2 +-
 4 files changed, 314 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
index bca1f59..d44bb50 100644
--- a/libavcodec/aaccoder.c
+++ b/libavcodec/aaccoder.c
@@ -531,7 +531,7 @@ static void search_for_pns(AACEncContext *s, AVCodecContext 
*avctx, SingleChanne
 band = >psy.ch[s->cur_channel].psy_bands[(w+w2)*16+g];
 for (i = 0; i < sce->ics.swb_sizes[g]; i+=2) {
 double rnd[2];
-av_bmg_get(>lfg, rnd);
+av_gaussian_get(>lfg, rnd, 2);
 PNS[i+0] = (float)rnd[0];
 PNS[i+1] = (float)rnd[1];
 }
diff --git a/libavutil/lfg.c b/libavutil/lfg.c
index 5ffd76f..7163c6b 100644
--- a/libavutil/lfg.c
+++ b/libavutil/lfg.c
@@ -44,6 +44,302 @@ av_cold void av_lfg_init(AVLFG *c, unsigned int seed)
 c->index = 0;
 }
 
+/*  Code adapted from the Julia project:
+https://github.com/JuliaLang/julia/blob/master/base/random.jl.
+This is licensed under MIT 
(https://github.com/JuliaLang/julia/blob/master/LICENSE.md)
+Copyright (c) 2009-2016: Jeff Bezanson, Stefan Karpinski, Viral B. Shah, 
and other contributors:
+
+https://github.com/JuliaLang/julia/contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a 
copy of this software and associated documentation files (the "Software"), to 
deal in the Software without restriction, including without limitation the 
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or 
sell copies of the Software, and to permit persons to whom the Software is 
furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in 
all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
+*/
+
+/* The Ziggurat Method for generating random variables - Marsaglia and 
Tsang
+Paper and reference code: http://www.jstatsoft.org/v05/i08/. */
+/* Tables for normal distribution */
+static const uint64_t ki[] = {
+
UINT64_C(0x0007799ec012f7b2),UINT64_C(0x),UINT64_C(0x0006045f4c7de363),UINT64_C(0x0006d1aa7d5ec0a5),
+
UINT64_C(0x000728fb3f60f777),UINT64_C(0x0007592af4e9fbc0),UINT64_C(0x000777a5c0bf655d),UINT64_C(0x00078ca3857d2256),
+
UINT64_C(0x00079bf6b0ffe58b),UINT64_C(0x0007a7a34ab092ad),UINT64_C(0x0007b0d2f20dd1cb),UINT64_C(0x0007b83d3aa9cb52),
+

[FFmpeg-devel] [PATCHv2 1/2] lavu/lfg-test: add simple sample mean, stddev checks

[Ganesh Ajjanagadde]

Also added a TODO to change to a proper normality test in the future.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/lfg.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/libavutil/lfg.c b/libavutil/lfg.c
index ffa2f1f..5ffd76f 100644
--- a/libavutil/lfg.c
+++ b/libavutil/lfg.c
@@ -84,17 +84,33 @@ int main(void)
 {
 double mean   = 1000;
 double stddev = 53;
+double samp_mean = 0.0, samp_stddev = 0.0;
+double samp0, samp1;
 
 av_lfg_init(, 42);
 
 for (i = 0; i < 1000; i += 2) {
 double bmg_out[2];
 av_bmg_get(, bmg_out);
+samp0 = bmg_out[0] * stddev + mean;
+samp1 = bmg_out[1] * stddev + mean;
+samp_mean += samp0 + samp1;
+samp_stddev += samp0 * samp0 + samp1 * samp1;
 av_log(NULL, AV_LOG_INFO,
"%f\n%f\n",
-   bmg_out[0] * stddev + mean,
-   bmg_out[1] * stddev + mean);
+   samp0,
+   samp1);
 }
+/* TODO: add proper normality test */
+samp_mean /= 1000;
+samp_stddev /= 999;
+samp_stddev -= (1000.0/999.0)*samp_mean*samp_mean;
+samp_stddev = sqrt(samp_stddev);
+av_log(NULL, AV_LOG_INFO, "sample mean  : %f\n"
+  "true mean: %f\n"
+  "sample stddev: %f\n"
+  "true stddev  : %f\n",
+   samp_mean, mean, samp_stddev, stddev);
 }
 
 return 0;
-- 
2.7.2

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 02:36:59PM +0100, Mats Peterson wrote:
> On 03/12/2016 02:26 PM, Mats Peterson wrote:
> >On 03/12/2016 12:53 PM, Michael Niedermayer wrote:
> >>On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:
> >>>Here's an interesting one. Windows Media Player won't make any palette
> >>>changes without the xxpc chunks beeing indexed.
> >>>
> >>>Fixing the logic for reading and seeking with xxpc chunks in the
> >>>demuxer  is a future task. Now the muxing of video with xxpc chunks
> >>>works properly at least.
> >>>
> >>>Try playing the resulting test.avi file from the command line below
> >>>with Windows Media Player, with and without this patch.
> >>>
> >>>ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi
> >>>
> >>>Mats
> >>>
> >>>--
> >>>Mats Peterson
> >>>http://matsp888.no-ip.org/~mats/
> >>
> >>>  libavformat/avi.h|6 +++-
> >>>  libavformat/avienc.c |   56
> >>>+--
> >>>  tests/ref/lavf-fate/avi_cram |4 +--
> >>>  3 files changed, 51 insertions(+), 15 deletions(-)
> >>>2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
> >>>0002-Add-xxpc-entries-to-index.patch
> >>> From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00 2001
> >>>From: Mats Peterson 
> >>>Date: Sat, 12 Mar 2016 07:00:33 +0100
> >>>Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index
> >>>
> >>>---
> >>>  libavformat/avi.h|6 -
> >>>  libavformat/avienc.c |   56
> >>>+-
> >>>  tests/ref/lavf-fate/avi_cram |4 +--
> >>>  3 files changed, 51 insertions(+), 15 deletions(-)
> >>>
> >>>diff --git a/libavformat/avi.h b/libavformat/avi.h
> >>>index 34da76f..af21f2c 100644
> >>>--- a/libavformat/avi.h
> >>>+++ b/libavformat/avi.h
> >>>@@ -32,7 +32,11 @@
> >>>  #define AVI_MASTER_INDEX_SIZE   256
> >>>  #define AVI_MAX_STREAM_COUNT100
> >>>
> >>>+/* stream header flags */
> >>>+#define AVISF_VIDEO_PALCHANGES  0x0001
> >>>+
> >>>  /* index flags */
> >>>-#define AVIIF_INDEX 0x10
> >>>+#define AVIIF_INDEX 0x0010
> >>>+#define AVIIF_NO_TIME   0x0100
> >>>
> >>>  #endif /* AVFORMAT_AVI_H */
> >>>diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> >>>index ad50379..b731bc2 100644
> >>>--- a/libavformat/avienc.c
> >>>+++ b/libavformat/avienc.c
> >>>@@ -44,13 +44,14 @@
> >>>   */
> >>>
> >>>  typedef struct AVIIentry {
> >>>-unsigned int flags, pos, len;
> >>>+char tag[5];
> >>
> >>the tag should be 4 bytes
> >>5 is ugly, it requires padding and bloats the structure with a zero
> >>byte
> >>
> >
> >OK.
> >
> >>
> >>>+unsigned int flags;
> >>>+unsigned int pos;
> >>>+unsigned int len;
> >>>  } AVIIentry;
> >>>
> >>>  #define AVI_INDEX_CLUSTER_SIZE 16384
> >>>
> >>>-#define AVISF_VIDEO_PALCHANGES 0x0001
> >>>-
> >>>  typedef struct AVIIndex {
> >>>  int64_t indx_start;
> >>>  int64_t audio_strm_offset;
> >>
> >>>@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
> >>>  }
> >>>  if (!empty) {
> >>>  avist = s->streams[stream_id]->priv_data;
> >>>-avi_stream2fourcc(tag, stream_id,
> >>>+if (*ie->tag)
> >>
> >>==18406== Conditional jump or move depends on uninitialised value(s)
> >>==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
> >>==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
> >>==18406==by 0x64A234: av_write_trailer (mux.c:1124)
> >>==18406==by 0x43A729: transcode (ffmpeg.c:4173)
> >>==18406==by 0x43ACE3: main (ffmpeg.c:4334)
> >>
> >
> >OK.
> 
> 
> It's not really uninitalised, is it? Since it isn't used by anything
> but my own code, it's all zero bytes, right?

after this patch snow encoding failed, i run valgrind and saw this
so there was something wrong, i dont know for sure if it was this


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

For every action, there is an equal and opposite reaction. -- Newton
For every man jailed for a minor crime, theres one person more that
will hate the government, some of them will become terrorists.


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

Re: [FFmpeg-devel] [PATCH]lavc/hevc: Support GBR encoding and decoding

[Moritz Barsnick]

On Sat, Mar 12, 2016 at 13:44:13 +0100, Carl Eugen Hoyos wrote:
>  break;
> +case AV_PIX_FMT_GBRP:
> +case AV_PIX_FMT_GBRP10:
> +case AV_PIX_FMT_GBRP12:
> +ctx->params->vui.matrixCoeffs = AVCOL_SPC_RGB;
> +ctx->params->vui.bEnableVideoSignalTypePresentFlag  = 1;
> +ctx->params->vui.bEnableColorDescriptionPresentFlag = 1;
>  case AV_PIX_FMT_YUV444P:
>  case AV_PIX_FMT_YUV444P10:
>  case AV_PIX_FMT_YUV444P12:

Fallthrough intended? Might be worth documenting then, because reading
such switch/cases can become confusing.

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

Re: [FFmpeg-devel] [PATCHv3 1/3] tests/gapless: add gapless aac tests

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 02:49:10AM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  tests/fate-run.sh | 30 ++
>  tests/fate/gapless.mak| 20 +-
>  tests/ref/fate/gapless2-ipod-aac1 | 82 
> +++
>  tests/ref/fate/gapless2-ipod-aac2 | 82 
> +++
>  tests/ref/fate/gapless2-mov-aac   | 82 
> +++
>  5 files changed, 295 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/gapless2-ipod-aac1
>  create mode 100644 tests/ref/fate/gapless2-ipod-aac2
>  create mode 100644 tests/ref/fate/gapless2-mov-aac
> 
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 16087cb..1063c0c 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -96,6 +96,21 @@ probeframes(){
>  run ffprobe${PROGSUF} -show_frames -v 0 "$@"
>  }
>  
> +probegaplessinfo(){
> +filename=$1
> +shift
> +run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries 
> format=start_time,duration:stream=index,start_pts,duration_ts -v 0 
> "$filename" "$@"
> +pktfile1="${filename}.pkts"
> +framefile1="${filename}.frames"
> +cleanfiles="$cleanfiles $pktfile1 $framefile1"
> +run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
> -show_entries packet=pts,dts,duration -v 0 "$filename" "$@" | nl -w 1 -s '|' 
> > $pktfile1
> +head -n 8 $pktfile1
> +tail -n 8 $pktfile1
> +run ffprobe${PROGSUF} -bitexact -select_streams a -of compact 
> -show_entries 
> frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples -v 0 
> "$filename" "$@" | nl -w 1 -s '|' > $framefile1
> +head -n 8 $framefile1
> +tail -n 8 $framefile1
> +}
> +
>  ffmpeg(){
>  dec_opts="-hwaccel $hwaccel -threads $threads -thread_type $thread_type"
>  ffmpeg_args="-nostdin -nostats -cpuflags $cpuflags"
> @@ -249,6 +264,21 @@ gapless(){
>  do_md5sum $decfile3
>  }
>  
> +gapless2(){
> +sample=$(target_path $1)
> +format=$2
> +codec=$3
> +
> +file1="${outdir}/${test}.out-1"
> +cleanfiles="$cleanfiles $file1"
> +
> +# test source data
> +probegaplessinfo "$sample" | sed 's/^/source|/'
> +# test data after reencoding
> +ffmpeg -i "$sample" -flags +bitexact -fflags +bitexact -map 0:a -c:a 
> $codec -f $format -y $file1
> +probegaplessinfo "$file1" | sed 's/^/target|/'
> +}
> +
>  concat(){
>  template=$1
>  sample=$2
> diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
> index 2fb005f..8d819bd 100644
> --- a/tests/fate/gapless.mak
> +++ b/tests/fate/gapless.mak
> @@ -3,5 +3,23 @@ fate-gapless-mp3: CMD = gapless 
> $(TARGET_SAMPLES)/gapless/gapless.mp3
>  
>  FATE_GAPLESS = $(FATE_GAPLESS-yes)
>  
> +FATE_GAPLESS2_PROBE-$(call ENCDEC, AAC, MOV) += fate-gapless2-ipod-aac1
> +fate-gapless2-ipod-aac1: ffprobe$(PROGSSUF)$(EXESUF)
> +fate-gapless2-ipod-aac1: CMD = gapless2 
> $(TARGET_SAMPLES)/cover_art/Owner-iTunes_9.0.3.15.m4a ipod aac

i missed that but
is this writing into the fate samples directory ?
thats not good if it does, the directory may be read only and would
not get cleaned

[...]
-- 
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 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 02:26 PM, Mats Peterson wrote:

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc chunks
works properly at least.

Try playing the resulting test.avi file from the command line below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d
0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56
+-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised value(s)
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.



It's not really uninitalised, is it? Since it isn't used by anything but 
my own code, it's all zero bytes, right?


Mats

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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

On 03/12/2016 02:20 PM, Mats Peterson wrote:

On 03/12/2016 01:14 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 11:43:32AM +0100, Mats Peterson wrote:

why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video
Capture Driver, Version:  3.8.2.2"

in asv2_320x240_3.avi




Regarding asv1/asv2, they do use 48 in biSize, but since there is no
official documentation for these codecs that explicitly mentions
that biSize should be 48 (which breaks the specs), it's plain wrong
to use anything else than 40.


just because the creator of a format chooses to keep the specs
secret doesnt mean you can freely choose the formats of headers.

What is correct for it is what the official software stores and it
stores 48 not 40, also 48 is the value i would have expected that they
would use.




Well, then they're breaking the specs, just like HuffYUV.



They're breaking the AVI specs, that is.

Mats

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index

[Mats Peterson]

On 03/12/2016 12:53 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:

Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks beeing indexed.

Fixing the logic for reading and seeking with xxpc chunks in the
demuxer  is a future task. Now the muxing of video with xxpc chunks
works properly at least.

Try playing the resulting test.avi file from the command line below
with Windows Media Player, with and without this patch.

ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  libavformat/avi.h|6 +++-
  libavformat/avienc.c |   56 
+--
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)
2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d  0002-Add-xxpc-entries-to-index.patch
 From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index

---
  libavformat/avi.h|6 -
  libavformat/avienc.c |   56 +-
  tests/ref/lavf-fate/avi_cram |4 +--
  3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
  #define AVI_MASTER_INDEX_SIZE   256
  #define AVI_MAX_STREAM_COUNT100

+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES  0x0001
+
  /* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME   0x0100

  #endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
   */

  typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];


the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte



OK.




+unsigned int flags;
+unsigned int pos;
+unsigned int len;
  } AVIIentry;

  #define AVI_INDEX_CLUSTER_SIZE 16384

-#define AVISF_VIDEO_PALCHANGES 0x0001
-
  typedef struct AVIIndex {
  int64_t indx_start;
  int64_t audio_strm_offset;



@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
  }
  if (!empty) {
  avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)


==18406== Conditional jump or move depends on uninitialised value(s)
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



OK.





+ffio_wfourcc(pb, ie->tag);
+else {
+avi_stream2fourcc(tag, stream_id,
s->streams[stream_id]->codec->codec_type);
-ffio_wfourcc(pb, tag);
+ffio_wfourcc(pb, tag);
+}
  avio_wl32(pb, ie->flags);
  avio_wl32(pb, ie->pos);
  avio_wl32(pb, ie->len);
@@ -673,6 +678,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  return avi_write_packet_internal(s, pkt); /* Passthrough */

  if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+AVIContext *avi  = s->priv_data;
  AVIStream *avist = s->streams[stream_index]->priv_data;
  AVIOContext *pb  = s->pb;
  AVPacket *opkt   = pkt;
@@ -709,6 +715,39 @@ static int avi_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  unsigned char tag[5];
  avi_stream2fourcc(tag, stream_index, enc->codec_type);
  tag[2] = 'p'; tag[3] = 'c';
+if (s->pb->seekable) {
+AVIIndex *idx;
+int cl, id;
+if (avist->strh_flags_offset) {
+int64_t cur_offset = avio_tell(pb);
+avio_seek(pb, avist->strh_flags_offset, SEEK_SET);
+avio_wl32(pb, AVISF_VIDEO_PALCHANGES);
+avio_seek(pb, cur_offset, SEEK_SET);
+avist->strh_flags_offset = 0;
+}
+idx = >indexes;
+cl = idx->entry / AVI_INDEX_CLUSTER_SIZE;
+id = idx->entry % AVI_INDEX_CLUSTER_SIZE;
+if (idx->ents_allocated <= idx->entry) {
+idx->cluster = 

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

On 03/12/2016 01:36 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 12:34:00PM +0100, Mats Peterson wrote:

Mats Peterson  skrev: (12 mars 2016 12:30:28 
CET)

Mats Peterson  skrev: (12 mars 2016
12:25:30 CET)

Mats Peterson  skrev: (12 mars 2016
12:14:03 CET)

On 03/12/2016 12:08 PM, Mats Peterson wrote:

On 03/12/2016 11:53 AM, Mats Peterson wrote:

On 03/12/2016 11:48 AM, Mats Peterson wrote:

On 03/12/2016 11:43 AM, Mats Peterson wrote:

why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32-

ASUS

Video

Capture Driver, Version:  3.8.2.2"

in asv2_320x240_3.avi




Regarding asv1/asv2, they do use 48 in biSize, but since there

is

no

official documentation for these codecs that explicitly mentions

that

biSize should be 48 (which breaks the specs), it's plain wrong

to

use

anything else than 40.



Furthermore, any "global headers" in *any* codec have nothing to

do

with

the BITMAPINFOHEADER. They aren't connected in any way. The size

of

the

BITMAPINFOHEADER is 40, so biSize should always be 40, since it

defines

the size of the BITMAPINFOHEADER, not the size of the

BITMAPINFOHEADER +

extra data.

Mats



If it wasn't for the braindead specification of HuffYUV with its

own

BITMAPINFOHEADER variant, this would be a piece of cake. Always

use

40

in biSize.

Mats

___


I vote for using huffyuv and ffvhuff (since it's a variant of

huffyuv)

as the only exceptions to using 40 bytes in biSize, regardless of

any

non-conformant existing or future stuff.



If the authors of future specs should happen to think that biSize
should
be anything else than 40, we'd better tell them the facts.

Mats

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


Perhaps you can use my latest 2-part patch set that includes asv1 and
asv2 in the "exception list", but thaf's it. No more entries should
ever need to be added to this list.

Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


In fact, it's wrong to include asv1 and asv2, since there are no specs
available. You decide. I'll stop now.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Well, the only specs I can find are the ones written by you, and they mention 
the global header, but no custom BITMAPINFOHEADER. Hence, biSize should be 40.


updated my "specs" but these are just based on observation/reverse
engeneering so not really true specs



Yes, I know.

Mats

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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

On 03/12/2016 01:14 PM, Michael Niedermayer wrote:

On Sat, Mar 12, 2016 at 11:43:32AM +0100, Mats Peterson wrote:

why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video
Capture Driver, Version:  3.8.2.2"

in asv2_320x240_3.avi




Regarding asv1/asv2, they do use 48 in biSize, but since there is no
official documentation for these codecs that explicitly mentions
that biSize should be 48 (which breaks the specs), it's plain wrong
to use anything else than 40.


just because the creator of a format chooses to keep the specs
secret doesnt mean you can freely choose the formats of headers.

What is correct for it is what the official software stores and it
stores 48 not 40, also 48 is the value i would have expected that they
would use.




Well, then they're breaking the specs, just like HuffYUV.

Mats

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

Re: [FFmpeg-devel] [PATCH]lavc/hevc: Support GBR encoding and decoding

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

>  AV_PIX_FMT_YUV420P,
>  AV_PIX_FMT_YUV422P,
>  AV_PIX_FMT_YUV444P,
> +AV_PIX_FMT_GBRP10,

Fixed locally to AV_PIX_FMT_GBRP;

Carl Eugen

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

[FFmpeg-devel] [PATCH]lavc/hevc: Support GBR encoding and decoding

[Carl Eugen Hoyos]

Hi!

Attached patch allows GBR encoding and decoding for hevc.

Please comment, Carl Eugen
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index bcb63a3..7237ee6 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -561,6 +561,17 @@ static void decode_vui(GetBitContext *gb, AVCodecContext 
*avctx,
 vui->transfer_characteristic = AVCOL_TRC_UNSPECIFIED;
 if (vui->matrix_coeffs >= AVCOL_SPC_NB)
 vui->matrix_coeffs = AVCOL_SPC_UNSPECIFIED;
+if (vui->matrix_coeffs == AVCOL_SPC_RGB)
+switch (sps->pix_fmt) {
+case AV_PIX_FMT_YUV444P:
+sps->pix_fmt = AV_PIX_FMT_GBRP;
+break;
+case AV_PIX_FMT_YUV444P10:
+sps->pix_fmt = AV_PIX_FMT_GBRP10;
+break;
+case AV_PIX_FMT_YUV444P12:
+sps->pix_fmt = AV_PIX_FMT_GBRP12;
+}
 }
 }
 
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 68c7fba..072bace 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -154,6 +154,12 @@ static av_cold int libx265_encode_init(AVCodecContext 
*avctx)
 case AV_PIX_FMT_YUV422P12:
 ctx->params->internalCsp = X265_CSP_I422;
 break;
+case AV_PIX_FMT_GBRP:
+case AV_PIX_FMT_GBRP10:
+case AV_PIX_FMT_GBRP12:
+ctx->params->vui.matrixCoeffs = AVCOL_SPC_RGB;
+ctx->params->vui.bEnableVideoSignalTypePresentFlag  = 1;
+ctx->params->vui.bEnableColorDescriptionPresentFlag = 1;
 case AV_PIX_FMT_YUV444P:
 case AV_PIX_FMT_YUV444P10:
 case AV_PIX_FMT_YUV444P12:
@@ -257,6 +263,7 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 
 x265pic.pts  = pic->pts;
 x265pic.bitDepth = av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth;
+printf("x265pic.bitDepth: %d \n", x265pic.bitDepth);
 
 x265pic.sliceType = pic->pict_type == AV_PICTURE_TYPE_I ? X265_TYPE_I :
 pic->pict_type == AV_PICTURE_TYPE_P ? X265_TYPE_P :
@@ -318,6 +325,7 @@ static const enum AVPixelFormat x265_csp_eight[] = {
 AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_GBRP,
 AV_PIX_FMT_NONE
 };
 
@@ -325,9 +333,11 @@ static const enum AVPixelFormat x265_csp_ten[] = {
 AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_GBRP10,
 AV_PIX_FMT_YUV420P10,
 AV_PIX_FMT_YUV422P10,
 AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_GBRP10,
 AV_PIX_FMT_NONE
 };
 
@@ -335,12 +345,15 @@ static const enum AVPixelFormat x265_csp_twelve[] = {
 AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_GBRP,
 AV_PIX_FMT_YUV420P10,
 AV_PIX_FMT_YUV422P10,
 AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_GBRP10,
 AV_PIX_FMT_YUV420P12,
 AV_PIX_FMT_YUV422P12,
 AV_PIX_FMT_YUV444P12,
+AV_PIX_FMT_GBRP12,
 AV_PIX_FMT_NONE
 };
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 12:34:00PM +0100, Mats Peterson wrote:
> Mats Peterson  skrev: (12 mars 2016 
> 12:30:28 CET)
> >Mats Peterson  skrev: (12 mars 2016
> >12:25:30 CET)
> >>Mats Peterson  skrev: (12 mars 2016
> >>12:14:03 CET)
> >>>On 03/12/2016 12:08 PM, Mats Peterson wrote:
>  On 03/12/2016 11:53 AM, Mats Peterson wrote:
> > On 03/12/2016 11:48 AM, Mats Peterson wrote:
> >> On 03/12/2016 11:43 AM, Mats Peterson wrote:
> >>> why do you think they are written by libavformat ?
> >>>
> >>> i see:
> >>> "C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32-
> >ASUS
> >>>Video
> >>> Capture Driver, Version:  3.8.2.2"
> >>>
> >>> in asv2_320x240_3.avi
> >>>
> >>>
> >>>
> >>> Regarding asv1/asv2, they do use 48 in biSize, but since there
> >is
> >>>no
> >>> official documentation for these codecs that explicitly mentions
> >>>that
> >>> biSize should be 48 (which breaks the specs), it's plain wrong
> >to
> >>>use
> >>> anything else than 40.
> >>>
> >>
> >> Furthermore, any "global headers" in *any* codec have nothing to
> >>do
> >>>with
> >> the BITMAPINFOHEADER. They aren't connected in any way. The size
> >>of
> >>>the
> >> BITMAPINFOHEADER is 40, so biSize should always be 40, since it
> >>>defines
> >> the size of the BITMAPINFOHEADER, not the size of the
> >>>BITMAPINFOHEADER +
> >> extra data.
> >>
> >> Mats
> >>
> >
> > If it wasn't for the braindead specification of HuffYUV with its
> >>own
> > BITMAPINFOHEADER variant, this would be a piece of cake. Always
> >use
> >>>40
> > in biSize.
> >
> > Mats
> >
> > ___
> 
>  I vote for using huffyuv and ffvhuff (since it's a variant of
> >>>huffyuv)
>  as the only exceptions to using 40 bytes in biSize, regardless of
> >>any
>  non-conformant existing or future stuff.
> 
> >>>
> >>>If the authors of future specs should happen to think that biSize
> >>>should 
> >>>be anything else than 40, we'd better tell them the facts.
> >>>
> >>>Mats
> >>>
> >>>___
> >>>ffmpeg-devel mailing list
> >>>ffmpeg-devel@ffmpeg.org
> >>>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >>Perhaps you can use my latest 2-part patch set that includes asv1 and
> >>asv2 in the "exception list", but thaf's it. No more entries should
> >>ever need to be added to this list.
> >>
> >>Mats
> >>-- 
> >>Mats Peterson
> >>http://matsp888.no-ip.org/~mats/
> >>___
> >>ffmpeg-devel mailing list
> >>ffmpeg-devel@ffmpeg.org
> >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >In fact, it's wrong to include asv1 and asv2, since there are no specs
> >available. You decide. I'll stop now.
> >-- 
> >Mats Peterson
> >http://matsp888.no-ip.org/~mats/
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Well, the only specs I can find are the ones written by you, and they mention 
> the global header, but no custom BITMAPINFOHEADER. Hence, biSize should be 40.

updated my "specs" but these are just based on observation/reverse
engeneering so not really true specs

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

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 11:43:32AM +0100, Mats Peterson wrote:
> why do you think they are written by libavformat ?
> 
> i see:
> "C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video
> Capture Driver, Version:  3.8.2.2"
> 
> in asv2_320x240_3.avi
> 
> 
> 
> Regarding asv1/asv2, they do use 48 in biSize, but since there is no
> official documentation for these codecs that explicitly mentions
> that biSize should be 48 (which breaks the specs), it's plain wrong
> to use anything else than 40.

just because the creator of a format chooses to keep the specs
secret doesnt mean you can freely choose the formats of headers.

What is correct for it is what the official software stores and it
stores 48 not 40, also 48 is the value i would have expected that they
would use.


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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH] lavu/lfg: switch to Ziggurat algorithm for normal random number generation

[Ganesh Ajjanagadde]

On Fri, Mar 11, 2016 at 3:10 AM, Reimar Döffinger
 wrote:
> On 11.03.2016, at 05:16, Ganesh Ajjanagadde  wrote:
>> Code taken from the Julia project, licensed under MIT:
>> https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn
>> derived from: "The Ziggurat Method for generating random variables" - 
>> Marsaglia and Tsang.
>>
>> Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is
>> well known to be the fastest method empirically for generating normal random
>> variables. Note that there are a large number of implementations with
>> various tunings, this was one of the simpler ones and also has a friendly
>> license.
>
> I absolutely can't see how this could be the fastest considering it uses the 
> rather slow av_lfg_get twice, unless you only mean the part of getting floats 
> in a certain distribution and not the actual randomness.

That is what I meant, all random generators use a uniform bitstream at
their core regardless and then transform it somehow. For example, the
linked arxiv paper (fastest I could fine) uses a SIMD optimized
Mersenne twister variant.

> I asked a long time ago for the decoder, but never got an answer why we use 
> lfg and not a much faster lcg.

I guess there is no inherent reason.
I recall Michael's general analysis:
http://guru.multimedia.cx/category/pseudo-random-number-generators/.

> ___
> 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 2/2] lavf/avienc: Add xxpc entries to index

[Michael Niedermayer]

On Sat, Mar 12, 2016 at 07:14:16AM +0100, Mats Peterson wrote:
> Here's an interesting one. Windows Media Player won't make any palette
> changes without the xxpc chunks beeing indexed.
> 
> Fixing the logic for reading and seeking with xxpc chunks in the
> demuxer  is a future task. Now the muxing of video with xxpc chunks
> works properly at least.
> 
> Try playing the resulting test.avi file from the command line below
> with Windows Media Player, with and without this patch.
> 
> ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi
> 
> Mats
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  libavformat/avi.h|6 +++-
>  libavformat/avienc.c |   56 
> +--
>  tests/ref/lavf-fate/avi_cram |4 +--
>  3 files changed, 51 insertions(+), 15 deletions(-)
> 2cf2565f9e258ee1a2bfcb83e4f30ecb1c13296d  0002-Add-xxpc-entries-to-index.patch
> From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Sat, 12 Mar 2016 07:00:33 +0100
> Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index
> 
> ---
>  libavformat/avi.h|6 -
>  libavformat/avienc.c |   56 
> +-
>  tests/ref/lavf-fate/avi_cram |4 +--
>  3 files changed, 51 insertions(+), 15 deletions(-)
> 
> diff --git a/libavformat/avi.h b/libavformat/avi.h
> index 34da76f..af21f2c 100644
> --- a/libavformat/avi.h
> +++ b/libavformat/avi.h
> @@ -32,7 +32,11 @@
>  #define AVI_MASTER_INDEX_SIZE   256
>  #define AVI_MAX_STREAM_COUNT100
>  
> +/* stream header flags */
> +#define AVISF_VIDEO_PALCHANGES  0x0001
> +
>  /* index flags */
> -#define AVIIF_INDEX 0x10
> +#define AVIIF_INDEX 0x0010
> +#define AVIIF_NO_TIME   0x0100
>  
>  #endif /* AVFORMAT_AVI_H */
> diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> index ad50379..b731bc2 100644
> --- a/libavformat/avienc.c
> +++ b/libavformat/avienc.c
> @@ -44,13 +44,14 @@
>   */
>  
>  typedef struct AVIIentry {
> -unsigned int flags, pos, len;
> +char tag[5];

the tag should be 4 bytes
5 is ugly, it requires padding and bloats the structure with a zero
byte


> +unsigned int flags;
> +unsigned int pos;
> +unsigned int len;
>  } AVIIentry;
>  
>  #define AVI_INDEX_CLUSTER_SIZE 16384
>  
> -#define AVISF_VIDEO_PALCHANGES 0x0001
> -
>  typedef struct AVIIndex {
>  int64_t indx_start;
>  int64_t audio_strm_offset;

> @@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
>  }
>  if (!empty) {
>  avist = s->streams[stream_id]->priv_data;
> -avi_stream2fourcc(tag, stream_id,
> +if (*ie->tag)

==18406== Conditional jump or move depends on uninitialised value(s)
==18406==at 0x598D80: avi_write_idx1 (avienc.c:616)
==18406==by 0x599D6D: avi_write_trailer (avienc.c:859)
==18406==by 0x64A234: av_write_trailer (mux.c:1124)
==18406==by 0x43A729: transcode (ffmpeg.c:4173)
==18406==by 0x43ACE3: main (ffmpeg.c:4334)



> +ffio_wfourcc(pb, ie->tag);
> +else {
> +avi_stream2fourcc(tag, stream_id,
>s->streams[stream_id]->codec->codec_type);
> -ffio_wfourcc(pb, tag);
> +ffio_wfourcc(pb, tag);
> +}
>  avio_wl32(pb, ie->flags);
>  avio_wl32(pb, ie->pos);
>  avio_wl32(pb, ie->len);
> @@ -673,6 +678,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  return avi_write_packet_internal(s, pkt); /* Passthrough */
>  
>  if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
> +AVIContext *avi  = s->priv_data;
>  AVIStream *avist = s->streams[stream_index]->priv_data;
>  AVIOContext *pb  = s->pb;
>  AVPacket *opkt   = pkt;
> @@ -709,6 +715,39 @@ static int avi_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  unsigned char tag[5];
>  avi_stream2fourcc(tag, stream_index, enc->codec_type);
>  tag[2] = 'p'; tag[3] = 'c';
> +if (s->pb->seekable) {
> +AVIIndex *idx;
> +int cl, id;
> +if (avist->strh_flags_offset) {
> +int64_t cur_offset = avio_tell(pb);
> +avio_seek(pb, avist->strh_flags_offset, 
> SEEK_SET);
> +avio_wl32(pb, AVISF_VIDEO_PALCHANGES);
> +avio_seek(pb, cur_offset, SEEK_SET);
> +avist->strh_flags_offset = 0;
> +}
> +idx = >indexes;
> +cl = idx->entry / AVI_INDEX_CLUSTER_SIZE;
> +id = idx->entry % 

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

Mats Peterson  skrev: (12 mars 2016 12:30:28 
CET)
>Mats Peterson  skrev: (12 mars 2016
>12:25:30 CET)
>>Mats Peterson  skrev: (12 mars 2016
>>12:14:03 CET)
>>>On 03/12/2016 12:08 PM, Mats Peterson wrote:
 On 03/12/2016 11:53 AM, Mats Peterson wrote:
> On 03/12/2016 11:48 AM, Mats Peterson wrote:
>> On 03/12/2016 11:43 AM, Mats Peterson wrote:
>>> why do you think they are written by libavformat ?
>>>
>>> i see:
>>> "C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32-
>ASUS
>>>Video
>>> Capture Driver, Version:  3.8.2.2"
>>>
>>> in asv2_320x240_3.avi
>>>
>>>
>>>
>>> Regarding asv1/asv2, they do use 48 in biSize, but since there
>is
>>>no
>>> official documentation for these codecs that explicitly mentions
>>>that
>>> biSize should be 48 (which breaks the specs), it's plain wrong
>to
>>>use
>>> anything else than 40.
>>>
>>
>> Furthermore, any "global headers" in *any* codec have nothing to
>>do
>>>with
>> the BITMAPINFOHEADER. They aren't connected in any way. The size
>>of
>>>the
>> BITMAPINFOHEADER is 40, so biSize should always be 40, since it
>>>defines
>> the size of the BITMAPINFOHEADER, not the size of the
>>>BITMAPINFOHEADER +
>> extra data.
>>
>> Mats
>>
>
> If it wasn't for the braindead specification of HuffYUV with its
>>own
> BITMAPINFOHEADER variant, this would be a piece of cake. Always
>use
>>>40
> in biSize.
>
> Mats
>
> ___

 I vote for using huffyuv and ffvhuff (since it's a variant of
>>>huffyuv)
 as the only exceptions to using 40 bytes in biSize, regardless of
>>any
 non-conformant existing or future stuff.

>>>
>>>If the authors of future specs should happen to think that biSize
>>>should 
>>>be anything else than 40, we'd better tell them the facts.
>>>
>>>Mats
>>>
>>>___
>>>ffmpeg-devel mailing list
>>>ffmpeg-devel@ffmpeg.org
>>>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>Perhaps you can use my latest 2-part patch set that includes asv1 and
>>asv2 in the "exception list", but thaf's it. No more entries should
>>ever need to be added to this list.
>>
>>Mats
>>-- 
>>Mats Peterson
>>http://matsp888.no-ip.org/~mats/
>>___
>>ffmpeg-devel mailing list
>>ffmpeg-devel@ffmpeg.org
>>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>In fact, it's wrong to include asv1 and asv2, since there are no specs
>available. You decide. I'll stop now.
>-- 
>Mats Peterson
>http://matsp888.no-ip.org/~mats/
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Well, the only specs I can find are the ones written by you, and they mention 
the global header, but no custom BITMAPINFOHEADER. Hence, biSize should be 40.

Mats
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

Mats Peterson  skrev: (12 mars 2016 12:25:30 
CET)
>Mats Peterson  skrev: (12 mars 2016
>12:14:03 CET)
>>On 03/12/2016 12:08 PM, Mats Peterson wrote:
>>> On 03/12/2016 11:53 AM, Mats Peterson wrote:
 On 03/12/2016 11:48 AM, Mats Peterson wrote:
> On 03/12/2016 11:43 AM, Mats Peterson wrote:
>> why do you think they are written by libavformat ?
>>
>> i see:
>> "C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS
>>Video
>> Capture Driver, Version:  3.8.2.2"
>>
>> in asv2_320x240_3.avi
>>
>>
>>
>> Regarding asv1/asv2, they do use 48 in biSize, but since there is
>>no
>> official documentation for these codecs that explicitly mentions
>>that
>> biSize should be 48 (which breaks the specs), it's plain wrong to
>>use
>> anything else than 40.
>>
>
> Furthermore, any "global headers" in *any* codec have nothing to
>do
>>with
> the BITMAPINFOHEADER. They aren't connected in any way. The size
>of
>>the
> BITMAPINFOHEADER is 40, so biSize should always be 40, since it
>>defines
> the size of the BITMAPINFOHEADER, not the size of the
>>BITMAPINFOHEADER +
> extra data.
>
> Mats
>

 If it wasn't for the braindead specification of HuffYUV with its
>own
 BITMAPINFOHEADER variant, this would be a piece of cake. Always use
>>40
 in biSize.

 Mats

 ___
>>>
>>> I vote for using huffyuv and ffvhuff (since it's a variant of
>>huffyuv)
>>> as the only exceptions to using 40 bytes in biSize, regardless of
>any
>>> non-conformant existing or future stuff.
>>>
>>
>>If the authors of future specs should happen to think that biSize
>>should 
>>be anything else than 40, we'd better tell them the facts.
>>
>>Mats
>>
>>___
>>ffmpeg-devel mailing list
>>ffmpeg-devel@ffmpeg.org
>>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>Perhaps you can use my latest 2-part patch set that includes asv1 and
>asv2 in the "exception list", but thaf's it. No more entries should
>ever need to be added to this list.
>
>Mats
>-- 
>Mats Peterson
>http://matsp888.no-ip.org/~mats/
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

In fact, it's wrong to include asv1 and asv2, since there are no specs 
available. You decide. I'll stop now.
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

Mats Peterson  skrev: (12 mars 2016 12:14:03 
CET)
>On 03/12/2016 12:08 PM, Mats Peterson wrote:
>> On 03/12/2016 11:53 AM, Mats Peterson wrote:
>>> On 03/12/2016 11:48 AM, Mats Peterson wrote:
 On 03/12/2016 11:43 AM, Mats Peterson wrote:
> why do you think they are written by libavformat ?
>
> i see:
> "C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS
>Video
> Capture Driver, Version:  3.8.2.2"
>
> in asv2_320x240_3.avi
>
>
>
> Regarding asv1/asv2, they do use 48 in biSize, but since there is
>no
> official documentation for these codecs that explicitly mentions
>that
> biSize should be 48 (which breaks the specs), it's plain wrong to
>use
> anything else than 40.
>

 Furthermore, any "global headers" in *any* codec have nothing to do
>with
 the BITMAPINFOHEADER. They aren't connected in any way. The size of
>the
 BITMAPINFOHEADER is 40, so biSize should always be 40, since it
>defines
 the size of the BITMAPINFOHEADER, not the size of the
>BITMAPINFOHEADER +
 extra data.

 Mats

>>>
>>> If it wasn't for the braindead specification of HuffYUV with its own
>>> BITMAPINFOHEADER variant, this would be a piece of cake. Always use
>40
>>> in biSize.
>>>
>>> Mats
>>>
>>> ___
>>
>> I vote for using huffyuv and ffvhuff (since it's a variant of
>huffyuv)
>> as the only exceptions to using 40 bytes in biSize, regardless of any
>> non-conformant existing or future stuff.
>>
>
>If the authors of future specs should happen to think that biSize
>should 
>be anything else than 40, we'd better tell them the facts.
>
>Mats
>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Perhaps you can use my latest 2-part patch set that includes asv1 and asv2 in 
the "exception list", but thaf's it. No more entries should ever need to be 
added to this list.

Mats
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

On 03/12/2016 12:08 PM, Mats Peterson wrote:

On 03/12/2016 11:53 AM, Mats Peterson wrote:

On 03/12/2016 11:48 AM, Mats Peterson wrote:

On 03/12/2016 11:43 AM, Mats Peterson wrote:

why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video
Capture Driver, Version:  3.8.2.2"

in asv2_320x240_3.avi




Regarding asv1/asv2, they do use 48 in biSize, but since there is no
official documentation for these codecs that explicitly mentions that
biSize should be 48 (which breaks the specs), it's plain wrong to use
anything else than 40.



Furthermore, any "global headers" in *any* codec have nothing to do with
the BITMAPINFOHEADER. They aren't connected in any way. The size of the
BITMAPINFOHEADER is 40, so biSize should always be 40, since it defines
the size of the BITMAPINFOHEADER, not the size of the BITMAPINFOHEADER +
extra data.

Mats



If it wasn't for the braindead specification of HuffYUV with its own
BITMAPINFOHEADER variant, this would be a piece of cake. Always use 40
in biSize.

Mats

___


I vote for using huffyuv and ffvhuff (since it's a variant of huffyuv)
as the only exceptions to using 40 bytes in biSize, regardless of any
non-conformant existing or future stuff.



If the authors of future specs should happen to think that biSize should 
be anything else than 40, we'd better tell them the facts.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

On 03/12/2016 11:53 AM, Mats Peterson wrote:

On 03/12/2016 11:48 AM, Mats Peterson wrote:

On 03/12/2016 11:43 AM, Mats Peterson wrote:

why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video
Capture Driver, Version:  3.8.2.2"

in asv2_320x240_3.avi




Regarding asv1/asv2, they do use 48 in biSize, but since there is no
official documentation for these codecs that explicitly mentions that
biSize should be 48 (which breaks the specs), it's plain wrong to use
anything else than 40.



Furthermore, any "global headers" in *any* codec have nothing to do with
the BITMAPINFOHEADER. They aren't connected in any way. The size of the
BITMAPINFOHEADER is 40, so biSize should always be 40, since it defines
the size of the BITMAPINFOHEADER, not the size of the BITMAPINFOHEADER +
extra data.

Mats



If it wasn't for the braindead specification of HuffYUV with its own
BITMAPINFOHEADER variant, this would be a piece of cake. Always use 40
in biSize.

Mats

___


I vote for using huffyuv and ffvhuff (since it's a variant of huffyuv) 
as the only exceptions to using 40 bytes in biSize, regardless of any 
non-conformant existing or future stuff.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

On 03/12/2016 11:48 AM, Mats Peterson wrote:

On 03/12/2016 11:43 AM, Mats Peterson wrote:

why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video
Capture Driver, Version:  3.8.2.2"

in asv2_320x240_3.avi




Regarding asv1/asv2, they do use 48 in biSize, but since there is no
official documentation for these codecs that explicitly mentions that
biSize should be 48 (which breaks the specs), it's plain wrong to use
anything else than 40.



Furthermore, any "global headers" in *any* codec have nothing to do with
the BITMAPINFOHEADER. They aren't connected in any way. The size of the
BITMAPINFOHEADER is 40, so biSize should always be 40, since it defines
the size of the BITMAPINFOHEADER, not the size of the BITMAPINFOHEADER +
extra data.

Mats



If it wasn't for the braindead specification of HuffYUV with its own 
BITMAPINFOHEADER variant, this would be a piece of cake. Always use 40 
in biSize.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

On 03/12/2016 11:43 AM, Mats Peterson wrote:

why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video
Capture Driver, Version:  3.8.2.2"

in asv2_320x240_3.avi




Regarding asv1/asv2, they do use 48 in biSize, but since there is no
official documentation for these codecs that explicitly mentions that
biSize should be 48 (which breaks the specs), it's plain wrong to use
anything else than 40.



Furthermore, any "global headers" in *any* codec have nothing to do with 
the BITMAPINFOHEADER. They aren't connected in any way. The size of the 
BITMAPINFOHEADER is 40, so biSize should always be 40, since it defines 
the size of the BITMAPINFOHEADER, not the size of the BITMAPINFOHEADER + 
extra data.


Mats

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

Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.

[Sasi Inguva]

Sent the patch with modifications, and also added a fate test. Please use
this  file
https://drive.google.com/file/d/0Bz6XfEJZ-9N3cy1nYnRweHRFRjQ/view?usp=sharing
for the fate test . framecrc muxer is giving valid DTS with/without this
patch so I used probeframes for the test.

On Fri, Mar 11, 2016 at 4:31 PM, Michael Niedermayer  wrote:

> On Fri, Mar 11, 2016 at 01:54:07PM -0800, Sasi Inguva wrote:
> > For testing , a link to one such failing video
> >
> https://drive.google.com/file/d/0Bz6XfEJZ-9N3X0FSMWR6T3B3U28/view?usp=sharing
> >  . Without this patch,
>
> can we include this video in the fate samples for adding a fate test?
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
> ___
> 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/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video
Capture Driver, Version:  3.8.2.2"

in asv2_320x240_3.avi




Regarding asv1/asv2, they do use 48 in biSize, but since there is no 
official documentation for these codecs that explicitly mentions that 
biSize should be 48 (which breaks the specs), it's plain wrong to use 
anything else than 40.


Mats

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

[FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.

[Sasi Inguva]

Fill DTS if all packets have been read in avformat_find_stream_info, and still
has_decode_delay_been_guessed returns false.

Signed-off-by: Sasi Inguva 
---
 libavformat/utils.c |  77 ++---
 tests/fate/h264.mak |   3 +
 tests/ref/fate/h264-dts_5frames | 125 
 3 files changed, 184 insertions(+), 21 deletions(-)
 create mode 100644 tests/ref/fate/h264-dts_5frames

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 5f48de1..e027302 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -936,14 +936,44 @@ static int64_t select_from_pts_buffer(AVStream *st, 
int64_t *pts_buffer, int64_t
 return dts;
 }
 
+/**
+ * Updates the dts of packets of a stream in pkt_buffer, by re-ordering the pts
+ * of the packets in a window.
+ */
+static void update_dts_from_pts(AVFormatContext *s, int stream_index,
+AVPacketList *pkt_buffer)
+{
+AVStream *st   = s->streams[stream_index];
+int delay  = st->codec->has_b_frames;
+int i;
+
+int64_t pts_buffer[MAX_REORDER_DELAY+1];
+
+for (i = 0; ipkt.stream_index != stream_index)
+continue;
+
+if (pkt_buffer->pkt.pts != AV_NOPTS_VALUE && delay <= 
MAX_REORDER_DELAY) {
+pts_buffer[0] = pkt_buffer->pkt.pts;
+for (i = 0; i pts_buffer[i + 1]; i++)
+FFSWAP(int64_t, pts_buffer[i], pts_buffer[i + 1]);
+
+pkt_buffer->pkt.dts = select_from_pts_buffer(st, pts_buffer, 
pkt_buffer->pkt.dts);
+}
+}
+}
+
 static void update_initial_timestamps(AVFormatContext *s, int stream_index,
   int64_t dts, int64_t pts, AVPacket *pkt)
 {
 AVStream *st   = s->streams[stream_index];
 AVPacketList *pktl = s->internal->packet_buffer ? 
s->internal->packet_buffer : s->internal->parse_queue;
-int64_t pts_buffer[MAX_REORDER_DELAY+1];
+AVPacketList *pktl_it;
+
 uint64_t shift;
-int i, delay;
 
 if (st->first_dts != AV_NOPTS_VALUE ||
 dts   == AV_NOPTS_VALUE ||
@@ -951,36 +981,28 @@ static void update_initial_timestamps(AVFormatContext *s, 
int stream_index,
 is_relative(dts))
 return;
 
-delay = st->codec->has_b_frames;
 st->first_dts = dts - (st->cur_dts - RELATIVE_TS_BASE);
 st->cur_dts   = dts;
 shift = (uint64_t)st->first_dts - RELATIVE_TS_BASE;
 
-for (i = 0; ipkt.stream_index != stream_index)
+for (pktl_it = pktl; pktl_it; pktl_it = get_next_pkt(s, st, pktl_it)) {
+if (pktl_it->pkt.stream_index != stream_index)
 continue;
-if (is_relative(pktl->pkt.pts))
-pktl->pkt.pts += shift;
+if (is_relative(pktl_it->pkt.pts))
+pktl_it->pkt.pts += shift;
 
-if (is_relative(pktl->pkt.dts))
-pktl->pkt.dts += shift;
+if (is_relative(pktl_it->pkt.dts))
+pktl_it->pkt.dts += shift;
 
-if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts != 
AV_NOPTS_VALUE)
-st->start_time = pktl->pkt.pts;
-
-if (pktl->pkt.pts != AV_NOPTS_VALUE && delay <= MAX_REORDER_DELAY && 
has_decode_delay_been_guessed(st)) {
-pts_buffer[0] = pktl->pkt.pts;
-for (i = 0; i pts_buffer[i + 1]; i++)
-FFSWAP(int64_t, pts_buffer[i], pts_buffer[i + 1]);
+if (st->start_time == AV_NOPTS_VALUE && pktl_it->pkt.pts != 
AV_NOPTS_VALUE)
+st->start_time = pktl_it->pkt.pts;
+}
 
-pktl->pkt.dts = select_from_pts_buffer(st, pts_buffer, 
pktl->pkt.dts);
-}
+if (has_decode_delay_been_guessed(st)) {
+update_dts_from_pts(s, stream_index, pktl);
 }
 
 if (st->start_time == AV_NOPTS_VALUE)
@@ -3165,6 +3187,7 @@ int avformat_find_stream_info(AVFormatContext *ic, 
AVDictionary **options)
 int64_t max_stream_analyze_duration;
 int64_t max_subtitle_analyze_duration;
 int64_t probesize = ic->probesize;
+int eof_reached = 0;
 
 flush_codecs = probesize > 0;
 
@@ -3331,6 +3354,7 @@ int avformat_find_stream_info(AVFormatContext *ic, 
AVDictionary **options)
 
 if (ret < 0) {
 /* EOF or error*/
+eof_reached = 1;
 break;
 }
 
@@ -3454,6 +3478,17 @@ int avformat_find_stream_info(AVFormatContext *ic, 
AVDictionary **options)
 count++;
 }
 
+if (eof_reached && ic->internal->packet_buffer) {
+int stream_index;
+for (stream_index = 0; stream_index < ic->nb_streams; stream_index++) {
+// EOF already 

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Mats Peterson]

On 03/12/2016 10:58 AM, Michael Niedermayer wrote:

On Fri, Mar 11, 2016 at 10:26:43PM +0100, Mats Peterson wrote:

On 03/11/2016 06:45 PM, Michael Niedermayer wrote:

On Fri, Mar 11, 2016 at 03:31:55PM +0100, Mats Peterson wrote:

On 03/11/2016 03:27 PM, Mats Peterson wrote:

On 03/11/2016 03:21 PM, Mats Peterson wrote:

On 03/11/2016 03:13 PM, Mats Peterson wrote:

Michael Niedermayer  skrev: (11 mars 2016
15:05:49 CET)

On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote:

Mats Peterson  skrev: (11 mars 2016

14:06:19 CET)

Mats Peterson  skrev: (11 mars

2016

13:55:20 CET)

Michael Niedermayer  skrev: (11 mars 2016
13:49:32 CET)

On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote:

On 03/11/2016 01:25 PM, Mats Peterson wrote:

On 03/11/2016 01:14 PM, Michael Niedermayer wrote:

On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote:

On 03/11/2016 05:10 AM, Mats Peterson wrote:

Forget patch 2/3 and 3/3 from the old patch set.

 From the Microsoft documentation for BITMAPINFOHEADER at





https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:






"biSize: Specifies the number of bytes required by the

structure.

This

value does not include the size of the color table or the

size

of

the

color masks, if they are appended to the end of structure."

So, biSize is always 40. Also, Windows Media Player won't

detect

video

encoded with Microsoft Video 1 in 8 bpp mode if this value

is

anything

else than 40. I don't know about other codecs, they probably

work.

Anyway, we should stick with the specs, and not include the

palette

size
in that field.

Regarding the biClrUsed field, I'm setting it to 1 <<
bits_per_coded_sample if palettized video, since setting it

to

0

is

another case where it won't work with Windows Media Player

and

Microsoft
Video 1 in 8 bpp mode.

Mats





Once, again, HuffYUV has its own variant of BITMAPINFOHEADER

that

*does* include the size of the Huffman tables in biSize.

That's

the

only exception as far as I know.


is huffyuv really the exception ? and not raw rgb or palettes

?


asv1 and asv2 do not have 40 there



which codec with a non-palette global header puts 40 there ?


[...]


As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8
won't even display in Windows Media Player if this value is

anything

else than 40.


msv1 / RLE4/8 doesnt have a "Non palette global header"


[...]


That's correct. Sorry. Anyway, the only case I know of is HuffYUV

with

its special variant of BITMAPINFOHEADER that includes the Huffman
tables. Is there stated anywhere in the ASUS specs that the size of

the

extra data following the BITMAPINFOHEADER should be included in

biSize?

If not, it should be 40.

Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Those asv1/asv2 files play just fine with a biSize of 40, at that.

Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Should we perhaps "tighten" the "specs" (I saw that you have written

some documentation on asv1/asv2 in FFmpeg), and include those extra
bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg
invention.

we didnt invent ASUS video 1 and 2 nor huffyuv

which codec with a non-palette global header puts 40 there ?

the ms specs just says the color table & mask isnt part of biSize
it doesnt say the global header isnt, or iam looking at the wrong text
or location in the text/spec

[...]


Again, only one I know of is HuffYUV, and the specs define a custom
BITMAPINFOHEADER that includes the Huffman tables. The "global data"
in ASUS is only 8 bytes. Do they regard the BITMAPINFOHEADER as being
part of this global data as well? And should we? A BITMAPINFOHEADER is
a BITMAPINFOHEADER is a BITMAPINFOHEADER...

Mats



Do you have a sample file with asv1/asv2 *created by ASUS* where biSize
isn't 40?

Mts



I got the asv1/asv2 samples from the MPlayer sample directory. Are they

>from ASUS? They all use a biSize of 48.


Mats



Nope. Written with libavformat.


why do you think they are written by libavformat ?

i see:
"C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video Capture Driver, 
Version:  3.8.2.2"

in asv2_320x240_3.avi




Yes, you are right. I was looking at some other files. Sorry. So how
do we proceed from here? Should we make an exception to the "40-byte
rule" for HuffYUV, ffvhuff, asv1 and asv2 in the meantime?


before writing a system based on a list of exceptions, please awnser
the question

which codec with a non-palette global header puts 40 there


In my latest 2-part patch set 

Re: [FFmpeg-devel] libavutil/aes_ctr.c

[Michael Niedermayer]

On Fri, Mar 11, 2016 at 09:16:15AM -0800, NagaChaitanya Vellanki wrote:
> Need guidance on getting started to write tests for libavutil/aes_ctr.c.

please see how the code is used in libavformat/movenccenc.c and
libavformat/mov.c


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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Michael Niedermayer]

On Fri, Mar 11, 2016 at 10:26:43PM +0100, Mats Peterson wrote:
> On 03/11/2016 06:45 PM, Michael Niedermayer wrote:
> >On Fri, Mar 11, 2016 at 03:31:55PM +0100, Mats Peterson wrote:
> >>On 03/11/2016 03:27 PM, Mats Peterson wrote:
> >>>On 03/11/2016 03:21 PM, Mats Peterson wrote:
> On 03/11/2016 03:13 PM, Mats Peterson wrote:
> >Michael Niedermayer  skrev: (11 mars 2016
> >15:05:49 CET)
> >>On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote:
> >>>Mats Peterson  skrev: (11 mars 2016
> >>14:06:19 CET)
> Mats Peterson  skrev: (11 mars
> >>2016
> 13:55:20 CET)
> >Michael Niedermayer  skrev: (11 mars 2016
> >13:49:32 CET)
> >>On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote:
> >>>On 03/11/2016 01:25 PM, Mats Peterson wrote:
> On 03/11/2016 01:14 PM, Michael Niedermayer wrote:
> >On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote:
> >>On 03/11/2016 05:10 AM, Mats Peterson wrote:
> >>>Forget patch 2/3 and 3/3 from the old patch set.
> >>>
> >>> From the Microsoft documentation for BITMAPINFOHEADER at
> >>>
> >>>
> >https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
> >
> >
> >>>
> >>>
> >>>
> >>>"biSize: Specifies the number of bytes required by the
> >structure.
> >>This
> >>>value does not include the size of the color table or the
> >>size
> >of
> >>the
> >>>color masks, if they are appended to the end of structure."
> >>>
> >>>So, biSize is always 40. Also, Windows Media Player won't
> detect
> >>video
> >>>encoded with Microsoft Video 1 in 8 bpp mode if this value
> >>is
> >>anything
> >>>else than 40. I don't know about other codecs, they probably
> >>work.
> >>>Anyway, we should stick with the specs, and not include the
> >>palette
> >>>size
> >>>in that field.
> >>>
> >>>Regarding the biClrUsed field, I'm setting it to 1 <<
> >>>bits_per_coded_sample if palettized video, since setting it
> >>to
> 0
> >>is
> >>>another case where it won't work with Windows Media Player
> >>and
> >>>Microsoft
> >>>Video 1 in 8 bpp mode.
> >>>
> >>>Mats
> >>>
> >>>
> >>>
> >>
> >>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER
> that
> >>*does* include the size of the Huffman tables in biSize.
> >>That's
> >>the
> >>only exception as far as I know.
> >
> >is huffyuv really the exception ? and not raw rgb or palettes
> >>?
> >
> >asv1 and asv2 do not have 40 there
> >>
> >which codec with a non-palette global header puts 40 there ?
> >>
> >>[...]
> >>
> >>>As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8
> >>>won't even display in Windows Media Player if this value is
> anything
> >>>else than 40.
> >>
> >>msv1 / RLE4/8 doesnt have a "Non palette global header"
> >>
> >>
> >>[...]
> >
> >That's correct. Sorry. Anyway, the only case I know of is HuffYUV
> >>with
> >its special variant of BITMAPINFOHEADER that includes the Huffman
> >tables. Is there stated anywhere in the ASUS specs that the size of
> the
> >extra data following the BITMAPINFOHEADER should be included in
> biSize?
> >If not, it should be 40.
> >
> >Mats
> >--
> >Mats Peterson
> >http://matsp888.no-ip.org/~mats/
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Those asv1/asv2 files play just fine with a biSize of 40, at that.
> 
> Mats
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>>
> >>>Should we perhaps "tighten" the "specs" (I saw that you have written
> >>some documentation on asv1/asv2 in FFmpeg), and include those extra
> >>bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg
> >>invention.
> >>
>