[Ffmpeg-devel-irc] ffmpeg-devel.log.20140810

[burek]

[00:10] <kierank> ah finally
[00:10] <kierank> http://pastebin.com/LV7G554T
[00:16] <kierank> no change with assert level 2
[00:20] <kierank> how do you use asan with ffmpeg
[00:21] <j-b> ubitux: sorry, ridiculous
[00:22] <j-b> nevcairiel: ok
[00:24] <michaelni> kierank, iam sure theres a easier way but: --extra-cflags='-faddress-sanitizer -O1 -fno-omit-frame-pointer' --extra-ldflags=-faddress-sanitizer
[00:25] <J_Darnley> Wasn't a --toolchain=gcc-asan option added?
[00:25] <michaelni> also output would need to be send through asan_symbolize.py 
[00:25] <michaelni> J_Darnley, probably
[00:26] <michaelni> i just copy and pasted what i had in a stored configure line for asas testing
[00:26] <michaelni> that predates --toochain=...
[00:27] <J_Darnley> Yes, pardon the 4-line paste:
[00:27] <J_Darnley>     gcc-asan)
[00:27] <J_Darnley>         cc_default="gcc"
[00:27] <J_Darnley>         add_cflags  -fsanitize=address
[00:27] <J_Darnley>         add_ldflags -fsanitize=address
[00:29] <kierank> what is the minimum gcc
[00:29] <kierank> oh 4.8
[00:29] <kierank> i'm on 4.6
[00:29] <J_Darnley> Not sure
[00:30] <J_Darnley> ... oh
[00:39] <kierank> do I still have to do this asan_smybolize thing?
[00:41] <viperfx_> Does anyone know how to disable indexing for mov demuxer
[00:44] <smarter> kierank: only if you don't have llvm-symbolizer in your PATH
[00:46] <viperfx_> Is there any way to improve the speed of the avformat_open_input() call for mp4a DASH file through http? Does FFmpeg need to read all of it before it can proceed?
[00:47] <J_Darnley> I don't know what dash is but is the moov atom at the front?
[00:48] <kierank> symbol lookup error: /usr/lib/libswresample.so.0: undefined symbol: __asan_init_v1
[00:49] <cone-860> ffmpeg.git 03Anton Khirnov 07master:1985c2e75c60: Bump major versions of all libraries.
[00:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:889cb3ae2375: avcodec: remove deprecated use of FF_IDCT_XVIDMMX
[00:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:c89afc9acfc7: delay removial of FF_API_CODEC_ID, FF_API_OLD_AVOPTIONS and FF_API_OLD_ENCODE_VIDEO
[00:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:5e1832c29c2d: avutil: delay removial of FF_API_GET_CHANNEL_LAYOUT_COMPAT
[00:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:70b8668fb532: drop LLS1, rename LLS2 to LLS
[00:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:6fac4826249d: avcodec/flacdec: fix handling of av_samples_fill_arrays() return value
[00:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:80c1cb522c97: avcodec/version: leave old audio API
[00:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:a57ece0cb48b: Merge commit '1985c2e75c607ac51bfd8dc87d2957a5edf2b6f8'
[00:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:65cb02e87a8f: avcodec/version: delay removial of FF_API_AUDIO_CONVERT/FF_API_AVCODEC_RESAMPLE
[00:50] <michaelni> kierank, asan symbolize is for clang asan i dont know about gcc asan
[00:54] <kierank> michaelni: anything else apart from asan that's useful
[00:54] <kierank> it doesn't work at all
[00:56] <mark4o> kierank: valgrind?
[00:56] <kierank> not on a realtime stream
[00:56] <kierank> i'll have to figure out how to disable video
[00:57] <michaelni> cant you dont the stream to a file for easier debuging ?
[00:57] <michaelni> duMP
[00:57] <kierank> not easily
[00:57] <mark4o> did you add -fsanitize=address to your link flags?
[00:57] <kierank> yes
[00:57] <kierank> but it broke everything
[01:01] <viperfx_> J_Darnley: is that the header info? How do I detect that?
[01:02] <kierank> great and now moving to 4.8 broke the entire build
[01:03] <J_Darnley> Yeah.  A demuxer has to read that to read everything else.  Usually it would just seek.
[01:05] <viperfx_>  It seems to take 4-6s to complete that call. That time suggests that it is reading the whole file.
[01:07] <kierank> put the moov atom at the front
[01:08] <kierank> probably it's seeking to the end
[01:12] <Paranoialmaniac> dash always starts moov atom immediately if the file is the first segment
[01:13] <Paranoialmaniac> and moov atom shall have no sample table for fast start
[01:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:d9e7dc3e1664: ffmpeg: do not use SWR_CH_MAX
[01:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:ced765ceb323: avfilter/af_pan: check if the number of channels where sucessfully set
[01:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:ce1bb4b75d52: avfilter/af_pan: Do not use SWR_CH_MAX
[01:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:36bce999f5e7: libavfilter/af_amerge: Do not depend on SWR_CH_MAX
[01:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:74be0f82a775: swresample-test: make it independant of the internal SWR_CH_MAX
[01:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:97f8c7a03edd: bump libpostproc and libswresample
[01:25] <viperfx_> The file is on a server I have no control over
[01:28] <kierank> oh bugger it's because of this abi break
[01:29] <Paranoialmaniac> viperfx_: you have no control and the file has no moov atom before any mdat and moof atom, then you cannot do anything
[01:31] <viperfx_> Hmm isn't DASH meant to be for adapting streaming? How do browsers play the audio without downloading it all first
[01:31] <Paranoialmaniac> if the moov atom is not preceeded by any moof and mdat atom, the file is not a segment file for dash
[01:32] <Paranoialmaniac> * does not preceed
[01:32] <Paranoialmaniac> sorry
[01:32] <viperfx_> I don't quite understand the terms you are using. Should I use http://atomicparsley.sourceforge.net/ to check the file
[01:33] <Paranoialmaniac> yes. something like this
[01:34] <cone-860> ffmpeg.git 03Anton Khirnov 07master:472f9ed312ec: Remove obsolete FF_API_AVFRAME_COLORSPACE cruft.
[01:34] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:287602f9d80f: Merge commit '472f9ed312ec784f7c72876b77163f4741880d05'
[01:34] <viperfx_> Ah damn, it says :AtomicParsley error: unsupported MPEG-4 file brand found 'dash'
[01:35] <Paranoialmaniac> viperfx_: use boxdumper https://onedrive.live.com/?cid=6bdd4375ac8933c6&id=6BDD4375AC8933C6!404
[01:36] <viperfx_> I am afraid I am on OSX
[01:36] <jamrial> michaelni: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: libavcodec/libavcodec.so.56: version node not found for symbol av_fast_malloc at LIBAVCODEC_55
[01:36] <jamrial> ~/ffmpeg $ grep -r 'LIBAVCODEC_55' *
[01:36] <viperfx_> I can send you the URL if you like?
[01:36] <jamrial> libavcodec/utils.c:#    define LIBNAME "LIBAVCODEC_55"
[01:37] <Paranoialmaniac> viperfx_: you can easily build l-smash i think
[01:37] <mark4o> viperfx_: brew install l-smash (if you have homebrew installed)
[01:38] <Paranoialmaniac> the latest l-smash in homebrew is somewhat broken though
[01:38] <Paranoialmaniac> enough to dump the structure
[01:40] <viperfx_> Yep got it. Should I show you a pastebin?
[01:40] <Paranoialmaniac> show me please
[01:41] <viperfx_> It is quite large. Is the --box cmd enough?
[01:42] <cone-860> ffmpeg.git 03Nicolas George 07master:f87db4468539: lavf/avio: do not include bprint.h.
[01:42] <cone-860> ffmpeg.git 03Anton Khirnov 07master:24e87f7f425a: Remove obsolete FF_API_PROBE_MIME cruft.
[01:42] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:0f7ca2d77893: Merge remote-tracking branch 'cigaes/master'
[01:42] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:c218d8218d95: Merge commit '24e87f7f425a52b1e69661dcb2fbe0555a76f30b'
[01:42] <Paranoialmaniac> viperfx_: yes. enough
[01:43] <viperfx_> Great. http://tny.cz/571eb4af 
[01:44] <kierank> doesn't seem to crash in valgrind
[01:44] <kierank> but v quickly in gdb
[01:44] <Paranoialmaniac> this structure is youtube's one
[01:44] <viperfx_> Yep
[01:45] <viperfx_> Its youtube's m4a dash audio file
[01:46] <Paranoialmaniac> at least moov atom is placed much earlier. dunno why so take much time to start
[01:47] <viperfx_> Could this be a bug in the demuxer?
[01:48] <Paranoialmaniac> dunno. ask the author of the demuxer
[01:48] <viperfx_> the moov atom is the one placed just after ftyp?
[01:48] <Paranoialmaniac> yes
[01:48] <viperfx_> Urm could I be using the wrong demuxer?
[01:48] <Paranoialmaniac> moov atom contains initialization info for codecs
[01:49] <viperfx_> Is there a particular one that works well with this?
[01:53] <Paranoialmaniac> dunno
[01:53] <Paranoialmaniac> though i want to add the feature into l-smash
[01:54] <Paranoialmaniac> btw i'm an author of l-smash
[01:55] <michaelni> viperfx_, how can the issue be reproduced =
[01:55] <michaelni> ?
[01:56] <viperfx_> michaelni: Well first you would have to obtain the stream link through youtube-dl
[01:56] <viperfx_> youtube-dl -f 140 -g YOUTUBE_URL
[01:57] <viperfx_> Then you should be able to see the effect on any ffmpeg programs such as ffplay
[01:58] <viperfx_> Or even ffmpeg -i URL
[01:58] <viperfx_> michaelni: youtube-dl can be obtained from here : https://github.com/rg3/youtube-dl
[01:59] <michaelni> and what is YOUTUBE_URL  ?
[01:59] <viperfx_> The url of any music video on youtube you like :)
[02:01] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:a973e01501bc: avcodec: disable FF_API_FAST_MALLOC
[02:07] <cone-860> ffmpeg.git 03Anton Khirnov 07master:24c788f48787: Remove obsolete FF_API_REFERENCE_DTS cruft.
[02:07] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:329832d779e2: Merge commit '24c788f4878729a42150581d7ed7e9a11daf874d'
[02:14] <cone-860> ffmpeg.git 03Anton Khirnov 07master:9325d88eba80: lavc: remove obsolete and disabled avpriv functions
[02:14] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:a71fcfad892c: Merge commit '9325d88eba8038b3e2a4485e473a018410379e2d'
[02:15] <llogan> i'll be back in a week. going on a fishing/shrimping/drinking trip.
[02:17] <viperfx_> michaelni: have you noticed the delay?
[02:18] <michaelni> viperfx_, didnt yet had time to look but i made a note
[02:18] <viperfx_> ok cheers
[02:25] <kierank> possibly these crashes were a gdb bug
[02:25] <kierank> stops crashing with gdb 7.8
[02:25] <kierank> oh wait
[02:25] <kierank> crashed
[02:26] <kierank> doesn't appear to crash in valgrind
[02:39] <cone-860> ffmpeg.git 03Luca Barbato 07master:8c6f43029137: mpeg: Suppress a compiler warning on callback type
[02:40] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:e18d9d90f1d3: Merge commit '8c6f430291374cf6d2cfb85cdbb809803b5a7d83'
[02:45] <kierank> crash is ff_vector_fmac_scalar_avx
[02:45] <kierank> as far as I can tell
[02:53] <michaelni> viperfx_, -f 130 results in "ERROR: requested format not available"
[02:53] <michaelni> without f 130 i dont see a long delay
[02:53] <viperfx_> michaelni: its -f 140
[03:06] <jamrial> kierank: is the data 32-byte aligned?
[03:06] <kierank> don't know exactly where the crash is
[03:06] <kierank> it's stopped crashing now so i guess it's in a particular opus function
[03:06] <kierank> depending on the content
[03:13] <michaelni> kierank, also is the len parameter to ff_vector_fmac_scalar_avx a multiple of 16, >= 16 and not too large ?
[03:13] <kierank> len parameter is 960
[03:13] <michaelni> always ?
[03:13] <michaelni> or thats the last before the crash ?
[03:13] <kierank> last before crash
[03:13] <michaelni> ok
[03:14] <kierank> but my stream is only 20ms frames
[03:15] <kierank> crash is here
[03:15] <kierank> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/opusdec.c;h=b28edfbcd962bce33bc0983d1e09948072acd5c4;hb=HEAD#l319
[03:28] <kierank> e405f130 e4004180 are the two addresses
[03:29] <kierank> jamrial: ^
[03:36] <kierank> sigh ffmpeg decides opus audio is mp3
[03:38] <kierank> good to see it ignores the pmt
[03:45] <jamrial> e405f130 doesn't seem 32-byte aligned
[03:47] <kierank> the input is very rarely 32 byte aligned
[03:47] <kierank> out_tmp[i]
[03:47] <kierank> sorry the output
[03:48] <jamrial> both need to be 32-byte aligned. it's a constrain mentioned in float_dsp.h
[03:49] <kierank> is fast_malloc guaranteed to be 32-byte aligned
[03:55] <kierank> both the buffers are totally fucked
[03:56] <kierank> michaelni: anyway it's reproducable now
[03:57] <kierank> as long as I get rid of the aac probe code 
[03:57] <kierank> because ffmpeg likes to think opus in ts is aac
[03:58] <Compn> you added opus in ts demux without adding an encoder, and then expect us to test it using ... magic ?
[03:59] <kierank> no but i expect a demux not to override what i tell it to
[03:59] <Compn> change the opus probe score ?
[03:59] <kierank> the spec definitively says it's opus but ffmpeg decides to change it somewhere
[03:59] <kierank> why probe?
[03:59] <kierank> the mapping definitively says it is opus in ts
[03:59] <Compn> you say aac probe is winning
[03:59] <kierank> it has a string Opus
[03:59] <kierank> yes but why is aac probe even being called
[03:59] <kierank> that's the ridiculous part
[03:59] <Compn> ok, i see the problem
[04:00] <kierank> it would have been merged from libav with bugs
[04:00] <kierank> which would have been fun
[04:00] <Compn> missed a codec mapping then?
[04:00] <Compn> its in mpegts.c ... wheres the other one
[04:01] <Compn> theres riff and isom but , probably the bug is in mpegts code
[04:01] <kierank> it's mapped correctly
[04:01] <Compn> are you sure you built against local ffmpeg and are running local ffmpeg not a system lavf... ?
[04:01] <kierank> local ffmpeg yes
[04:01] <kierank> because as soon as I remove the aac probe code it works
[04:01] <Compn> paste full ffmpeg output to pastebin
[04:02] <Compn> with the aac code taking over
[04:02] <kierank> that's not the bug
[04:02] <michaelni> if its mapped correctly why does it not work ? also how can i reproduce that probe issue =?
[04:02] <kierank> the bug is opus crashes
[04:02] <kierank> michaelni: because there is some magic that decides it's aac
[04:02] <kierank> possibly in ffmpeg.c
[04:02] <kierank> who knows
[04:02] <kierank> michaelni: the bigger issue is the crash
[04:02] <Compn> how can opus crash if its aac decoder ?
[04:02] <Compn> heh
[04:02] <kierank> any why none of  the addreses in opusdec.c are 32-bit aligned
[04:02] <kierank> Compn: because i use my own demux
[04:02] <Compn> ah
[04:03] <Compn> the truth!
[04:03] <kierank> specifically because of silly hacks like that
[04:03] <kierank> but that is orthogonal to the crash
[04:03] <jamrial> kierank: av_fast_malloc should be in most cases aligned to 32 bytes as long as you compile ffmpeg with avx support. it nonetheless depends on system and build-time config
[04:03] <Compn> problem is your buggy demuxer then :P
[04:03] <kierank> Compn: seriously?
[04:03] <Compn> its just a guess...
[04:03] <kierank> no
[04:04] <kierank> the addresses are still broken in opusdec with ffmpeg
[04:04] <kierank> the demux works fine
[04:04] <Compn> is it the autodetect of LATM that causes aac probe ?
[04:04] <Compn>      * so auto-detect LOAS/LATM instead of hardcoding it. */
[04:06] <michaelni> kierank, please dont forget to provide some usefull info about the opus misdetection once you are done with the more imporatnt things
[04:07] <michaelni> i do want to fix it
[04:07] <kierank> michaelni: well in principle if I say something is opus in mpegts nothing should change it
[04:08] <michaelni> yes, but you want that 
[04:08] <michaelni> you only have to tell me how to reproduce it 
[04:08] <michaelni> and ill fix it
[04:09] <michaelni> or rather ill try
[04:09] <kierank> i'm not concerned about this specific issue
[04:09] <kierank> it's more why ffmpeg decides to override the demux
[04:10] <Compn> kierank : you didnt specify opus in mpegts.c
[04:10] <kierank> the whole point of going through this process and getting mozilla to pay $2500 registration is so that we could uniqely identify it
[04:10] <michaelni> kierank, i really dont know what or why should override the demuxer
[04:10] <Compn> i mean, doesnt it have to have a ISO type in this table in mpegts.c ? static const StreamType ISO_types[] = {
[04:10] <kierank> yes and there is a patch on the ML that does that
[04:10] <Compn> your patch doesnt specify it.
[04:10] <kierank> it's not an iso type
[04:10] <kierank> it's a registered type
[04:11] <kierank> static const StreamType REGD_types[] = {
[04:11] <Compn> i guess it doesnt have to be both...
[04:11] <kierank> can't be both
[04:11] <kierank> by definition
[04:12] <kierank> either you register it with the registration authority or it's an ISO type
[04:12] <Compn> ah
[04:12] <Compn> are you going to ifdef all the opus stuff in mpegts ? 
[04:13] <Compn> depending if opus decoder is enabled or not...
[04:13] <Compn> strange though, i wonder where the aac probe is jumping in on
[04:14] <Compn> kierank : in ffmpeg debug log does it say 'probing ' ?
[04:14] <Compn>                         if (pes->st->codec->codec_id == AV_CODEC_ID_NONE && !pes->st->request_probe) {
[04:15] <Compn> is it a pes header in your mpegts ?
[04:15] <kierank> yes
[04:15] <michaelni> kierank, make sure you set st->request_probe = 0
[04:15] <michaelni> and not 1
[04:16] <kierank> i don't do any probing
[04:16] <kierank> what i think happens is ffmpeg ignores pmt
[04:16] <kierank> and probes first
[04:16] <Compn> ok then its activating the pes header detection stuff which detects it as CODEC_ID_NONE, then the aac probe code jumps in
[04:16] <Compn> maybe
[04:18] <michaelni> kierank, if nothing enables probing then streams shouldnt be probed
[04:18] <Compn> around line 990 mpegts.c
[04:18] <kierank> michaelni: yes but what probably happens is a pes arrives first
[04:18] <kierank> and the demux uses that instead of following the spec and using pmt
[04:19] <Compn> so we should change the demuxer to check for pmt before using pes header code ?
[04:19] <kierank> yes
[04:19] <kierank> i'm sure it did at some point
[04:19] <Compn> i remember someone complaining about pes headers in mpegts before... few months ago
[04:19] <kierank> but there was some file that required breaking the spec
[04:20] <Compn> theres always a file :)
[04:20] <kierank> ok so opusdec
[04:20] <kierank> libav is also bugged
[04:21] <kierank> but they don't seem to have unrolled 
[04:21] <kierank> so possibly the bug is less likely to occur
[04:21] <kierank> less likely to segfault
[04:22] <Compn> if you can share sample michael would like to fix it kierank
[04:22] <kierank> give me a minute
[04:22] <kierank> https://dl.dropboxusercontent.com/u/2701213/alignment.opus
[04:23] <kierank> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/opusdec.c;h=b28edfbcd962bce33bc0983d1e09948072acd5c4;hb=HEAD#l319
[04:23] <kierank> if you printf the addresses here they are not 32-byte aligned
[04:23] <Compn> what compiler to reproduce ?
[04:25] <kierank> 4.8.1 x86-64
[04:28] <michaelni> kierank, they are 32byte aligned here
[04:28] <michaelni> av_log(0,0, "XXX %d %d\n", ((int)out_tmp[i]) & 31, ((int)s->celt_output[i]) & 31);
[04:31] <michaelni> anyway i need t o go to bed soon, ill look at the log tomorrow
[04:44] <kierank> michaelni: [av] XXX 16 0
[04:45] <michaelni> its always 0 0 here
[04:45] <kierank> not on the same file
[04:45] <kierank> seems that file is ok
[04:45] <kierank> but on the live stream it crashes but i'll have to try and catch a bit
[04:45] <kierank> that causes the crash
[04:46] <kierank> might depend on API vs ffmpeg
[04:48] <michaelni> are you getting misaligned pointers from a *malloc function or they get offseted to that later ?
[04:49] <kierank> could be the calling application as well
[04:49] <kierank> i think
[04:52] <kierank> I think the API has to say the output data from get_buffer MUST be 32 byte aligned
[05:02] <cone-860> ffmpeg.git 03James Almer 07master:ddce2b265444: tools/fourcc2pixfmt: use avpriv_get_raw_pix_fmt_tags()
[05:02] <cone-860> ffmpeg.git 03James Almer 07master:6985ef781397: lavfi: stop exporting internal functions
[05:21] <mark4o> kierank: your alignment.opus file is invalid; the reference decoder doesnt accept it at all
[05:21] <mark4o> it is because you have a channel mapping for mapping family 0, which is not valid
[05:30] <kierank> it was the output when remuxing without any checks for validity
[05:31] <kierank> but the crash is unrelated
[05:36] <mark4o> remuxing from what source?
[05:44] <kierank> from ts
[05:44] <kierank> without checking the ts extradata is suitable for going into ogg
[05:45] <kierank> (because in the past the only extradata type was ogg)
[05:51] <Compn> mark4o : we still dont want decoder to crash, even if invalid file (especially if invalid file)
[05:52] <mark4o> kierank: ah ok, so it is the extradata that you are generating in mpegts.c; I think it is correct except for the length, which you are always setting to sizeof(opus_default_extradata)
[05:52] <mark4o> ffmpeg ignores extra junk at the end but the reference decoder doesnt
[05:53] <mark4o> Compn: yes, just another issue not related to crash
[05:53] <kierank> I have sent a patch for the crash
[05:54] <mark4o> kierank: the patch that only changes a comment?
[05:54] <kierank> yes
[05:55] <kierank> if you make your buffers 32-byte aligned you don't have a crash
[05:55] <mark4o> ok
[11:38] <ubitux> kierank: is it me or there is a weird sound jump around 64 seconds?
[11:38] <ubitux> (ffplay -ss 64 alignment.opus)
[11:43] <ubitux> mmh yeah it seems there is a large ts jump
[11:43] <ubitux> [Parsed_ashowinfo_0 @ 0x7fccd0004f40] n:149 pts:3086400 pts_time:64.3 pos:236672 fmt:fltp channels:2 chlayout:stereo rate:48000 nb_samples:960 checksum:11086BF6 plane_checksums: [ 5F43425D 04692999 ]
[11:43] <ubitux> [Parsed_ashowinfo_0 @ 0x7fccd0004f40] n:150 pts:3121920 pts_time:65.04 pos:236672 fmt:fltp channels:2 chlayout:stereo rate:48000 nb_samples:960 checksum:D7F9FF6C plane_checksums: [ 761B7391 7D448BDB ]
[12:00] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20140810044909&slot=x86_64-archlinux-gcc-valgrindundef
[12:06] <viperfx_> michaelni: Should I submit a bug report regarding the youtube mp4a dash format issue?
[12:15] <michaelni> viperfx_, yes
[12:15] <viperfx_> Did you get a chance to confirm the issue? michaelni 
[12:15] <viperfx_> it would be good to know its not just me :)
[12:16] <michaelni> viperfx_, i saw a ~4sec delay on startup
[12:17] <michaelni> would be ideal if we could avoid that
[12:17] <viperfx_> Yep okay, and that is abnormal for a file with the moov atom at the start
[12:17] <viperfx_> Is there any other details I should include? That could be helpful to the devs
[12:19] <viperfx_> michaelni: is this something fairly trivial to fix ?
[12:20] <viperfx_> Is there a chance that a newcomer could tackle this?
[12:37] <cone-672> ffmpeg.git 03Christophe Gisquet 07master:7117547298b1: hevc: fix incorrect sao buffer size
[12:48] <viperfx_> michaelni: Done! https://trac.ffmpeg.org/ticket/3842
[12:54] <wm4> viperfx_: have you found the option that makes it work?
[12:54] <viperfx_> wm4: What do you mean?
[12:54] <wm4> disabling indexing or so
[12:55] <wm4> should make it load instantly
[12:55] <wm4> you should also write that it downloads the whole file
[12:56] <wm4> ah, found it: fflags=+ignidx
[12:57] <wm4> that actually disables loading the index, rather than disabling indexing
[12:59] <viperfx_> wm4: on the ticket?
[12:59] <viperfx_> If I was using ffmpeg using the iibav libraries 
[12:59] <wm4> yes
[12:59] <viperfx_> where do I set this flag
[13:00] <wm4> av_set_opt
[13:00] <wm4> err
[13:00] <wm4> av_opt_set
[13:00] <wm4> use "fflags" and "+ignidx" as params
[13:03] <viperfx_> wm4: That func does not seem available to me
[13:04] <wm4> pretty sure it's available...
[13:04] <viperfx_> Is it global or part of a class
[13:05] <viperfx_> AVOptions?
[13:05] <wm4> uh, ffmpeg is fully in C
[13:05] <wm4> did you include libavutil/opt.h?
[13:05] <viperfx_> No, I did not :/
[13:05] <wm4> pass the lavf context as first argument
[13:06] <viperfx_> AVFormatContext ?
[13:07] <wm4> yes
[13:09] <viperfx_> wm4:  What do i set as the search flag?
[13:10] <wm4> 0 should work in this case
[13:13] <viperfx_> wm4: Yep your right, its much faster. However, it does not detect the duration.
[13:13] <viperfx_> But its a great improvement!
[13:14] <viperfx_> I suppose that is kinda what disabling indexing does? :)
[13:14] <wm4> depends entirely on the file format
[13:15] <wm4> and in this case depends on details how mov works
[13:16] <viperfx_> Ah okay, well it seems to detect the duration of 10s. But then carries on playing til the end :)
[13:18] <Paranoialmaniac> you cannot know whole duration unless there is mehd atom or edts atom basically
[13:18] <Paranoialmaniac> at startup
[13:19] <Paranoialmaniac> youtube sets whole duration of a track to tkhd duration but this is out-of-spec
[13:20] <wm4> what makes libavformat read the whole file?
[13:25] <Paranoialmaniac> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;h=b2ef482ce2de4890bdf30a1375e28113e6070f43;hb=HEAD#l3244
[13:29] <Paranoialmaniac> hmm? the demuxer doesn't start immediately the first mdat atom is so large?
[13:30] <wm4> that's a large condition
[13:30] <wm4> so I guess it's searching for the mdat atom?
[13:31] <Paranoialmaniac> even if fragmented, the demuxer can't skip the first mdat when minimal indexing
[13:31] <ubitux> wm4: note that we can't really modify libavr much or we would have to change its name
[13:31] <Paranoialmaniac> this behavior is weird and prevent fast-start
[13:32] <wm4> ubitux: how so? you're doing that with the other libs too
[13:32] <ubitux> yes but we didn't fork them from libav
[13:33] <ubitux> typically if we happened to modify avr, we should either do it in libav, or change its name
[13:33] <wm4> you could just enable it by default
[13:33] <wm4> but then you'd be afraid that swr falls into disuse
[13:33] <Compn> to enable avr by default means we would have to test it
[13:33] <ubitux> ^
[13:33] <Compn> do you have a simple way to test it wm4 ?
[13:33] <ubitux> and we don't test it
[13:34] <wm4> libav has tests
[13:34] <ubitux> yes, but for libav
[13:34] <Compn> wouldnt we have to modify ffmpeg to make switching of resample possible ?
[13:34] <Compn> patch welcome
[13:34] <ubitux> it is maintained on libav side, but we don't support a proper integration in ffmpeg
[13:34] <ubitux> Compn: i don't think such patch would be welcome actually
[13:34] <Compn> its a lib, that we dont have support for in our program, i guess
[13:34] <wm4> Compn: no, lavfi has 2 reampler filters
[13:35] <wm4> one for swr and one for lavr
[13:35] <Compn> ubitux : lol, well 'patch welcome' is usually a troll because no one ever sends patch
[13:35] <viperfx_> Guys could someone confirm the issue is reproducable with the current FFmpeg git head?
[13:35] <ubitux> but it's dishonest to say it here
[13:35] <wm4> but seriously, what the heck are you doing, why are you making people write code for 2 APIs?
[13:35] <wm4> viperfx_: just say yes
[13:35] <michaelni> wm4, ubitux i cannot maintain avr in ffmpeg, if you guys want that swr fork instead of swr i wont stop you but you must maintain it long term
[13:35] <viperfx_> urm alright
[13:35] <michaelni> incuding security support
[13:36] <wm4> viperfx_: I'm pretty sure nothing about it changed recently
[13:36] <Compn> wm4 : write a wrapper lib for either one so they can use the same api ?
[13:36] <ubitux> i just think that modifying avr to a certain extent means that we should rename it, and it defeats the purpose wm4 is looking for
[13:36] <wm4> well, debian is enabling it by default, so maybe I can drop my swr code
[13:36] <ubitux> we can't rely on libav to maintain issue we would have on our side
[13:36] <Compn> wm4 : or would that be ok with you ?
[13:36] <wm4> (problem solved)
[13:37] <ubitux> wm4: following that reasoning, debian might include ffmpeg, so maybe you can drop your libav code
[13:37] <wm4> true
[13:37] <Compn> somehow i doubt debian will reverse and put mplayer back in :P
[13:37] <wm4> that's a much larger step, though, and there are still libav distros
[13:38] <ubitux> such as?
[13:38] <viperfx_> So in its current state. I can disable indexing and wont be able to seek or get the correct duration.
[13:38] <viperfx_> and not get the current duration*
[13:38] <wm4> viperfx_: seeking should still work, I think
[13:39] <michaelni> ubitux, wm4, also theres another aspect i truely dont get, what is the whole avr/swr fuzz about ? why dont we work together to improve swr and use it
[13:40] <ubitux> because it's not available in debian
[13:40] <ubitux> that's the only reason
[13:40] <wm4> wrong
[13:40] <michaelni> ubitux, thats fixable
[13:40] <michaelni> ubitux, any reasons against ffmpeg dont apply to swr
[13:41] <ubitux> wm4: so what else?
[13:41] <Compn> michaelni : can you make the api with avr the same ? i think thats what wm4 is complaining about
[13:41] <Compn> so people dont have to write two api...
[13:41] <ubitux> Compn: no
[13:41] <Compn> or a wrapper api
[13:41] <Paranoialmaniac> viperfx_: you can't fast-seek a position until you read that position once since you don't know the position you want to seek at the first time
[13:41] <ubitux> Compn: the api is almost the same, but some stuff are simpler in swr
[13:42] <wm4> ubitux: I want my project to work both ffmpeg and libav (and other projects also want that), and the swr/avr makes this harder
[13:42] <viperfx_> wm4: I cannot seek because I do not have the full duration 
[13:42] <wm4> viperfx_: you can just seek to a timestamp
[13:42] <ubitux> wm4: and you want it to work with both ffmpeg and libav because ffmpeg is not available everywhere, that is, not in ffmpeg
[13:42] <ubitux> not in debian*
[13:43] <viperfx_> wm4: visually speaking on a UI, how would you limit the range without knowing the full duration?
[13:43] <Compn> ubitux : well, because some users choose libav or ffmpeg and they want to support both
[13:43] <wm4> viperfx_: well, I guess that's a UI problem
[13:43] <Compn> and by choose , i mean debian chose for them :p
[13:43] <ubitux> Compn: they don't, distro choose for them
[13:44] <ubitux> so anyway, that's always the same issue
[13:44] <wm4> viperfx_: but AFAIK dash has metadata to piece mp4 fragments together?
[13:44] <ubitux> avr is prefered over swr only because of its distribution, and not its technical merits
[13:44] <ubitux> that's not really a logic we should encourage
[13:44] <Compn> ubitux : we can either work with downstream or we can ignore them 
[13:44] <viperfx_> Right, but FFmpeg does not do that yet?
[13:44] <Compn> downstream being mpv
[13:44] <wm4> viperfx_: no dash streaming support, no
[13:44] <Compn> and some other projects that chose to support both
[13:45] <ubitux> Compn: let's cut the discussion, there is a technical one currently we are interrupting
[13:45] Action: ubitux &
[13:45] <wm4> ubitux: I remember when I actually dropped support for an older version of ffmpeg, because swr was crashy, while avr wasn't
[13:45] <wm4> but of course that's unfair because that's just a now-fixed bug
[13:45] <Paranoialmaniac> wm4: viperfx_'s samle has no metadata to seek random access points
[13:45] <ubitux> "one day there was an issue with swr, avr is better!"
[13:46] <wm4> Paranoialmaniac: libavformat's generic seeking code will probably take care of it by skipping until the target PTS
[13:46] <viperfx_> Paranoialmaniac: Does that void the suggest about seeking with timestamps then?
[13:46] <wm4> ubitux: let's just say that my overall experience with swr was more negative
[13:47] <Paranoialmaniac> wm4: yes. i know. but you can't fast seek at the first time without manifest file in this case
[13:50] <Paranoialmaniac> viperfx_: sure
[13:50] <wm4> so I wonder how youtube handles this...
[13:50] <BBB> I dont see how changing avr/swr merging helps anyone; lavcodec is shared, and its still a nightmare to work with for downstreams
[13:52] <wm4> the swr/avr mess is probably unfixable, so let's just be sad
[13:54] <Paranoialmaniac> wm4: sidx atom? the libavformat mov demuxer has no support of sidx box. sorry i forgot the presence of sidx atom :P
[13:54] <Compn> wm4 : i think i suggested to j-b once that he should fork ffmpeg/libav and pick features from both projects to make the 'one true ffmpeg' but i dont think he wanted to do that...
[13:56] <wm4> Paranoialmaniac: aha, so if that were implemented, it would fix all issues? what exactly does the atom contain?
[13:56] <wm4> Compn: that would in fact be the best and only way to solve the fork issue
[13:57] <wm4> there'd be some significant danger of it just ending up as 3rd fork, of course
[13:57] <Compn> its a possiblity
[13:57] <wm4> but if it works, devs would slowly migrate to this project
[13:57] <Compn> also maintainer questions would arise 
[13:57] <wm4> and the original projects would fade into obscurity
[13:58] <Paranoialmaniac> wm4: sidx atom has collection of durations, size and random access type of subsegments in a segment file
[13:59] <Paranoialmaniac> here. subsegment == moof + mdat
[14:46] <BBB> has anyone actually compared avr vs. swr performance?
[14:46] <BBB> the code I touched (I compared the avr version) was probably 1.5x as fast in swr
[14:47] <BBB> and thats in the main resampling codepath, mind you
[14:47] <BBB> not some obscure external outer loop nobody cares about
[14:56] <BBB> kierank: Im highly doubtful avr vs swr trollwars in the context of debian are going to be beneficial for anyone, that should really be done outside the debian mailinglist...
[14:56] <kierank> probably true
[14:56] <kierank> but they are enabling avr
[14:57] <BBB> that trollwar will get lost in the other debian trollwars, and that means I wont read half of it, why dont you do that in a new thread so theres a small chance that I actually care and read it
[15:00] <kierank> I just continued the thread
[16:09] <Daemon404> BBB, when in the history of time have any debian trollwars been beneficial to anyone? :)
[16:12] <Daemon404> oh! i guess i can push that mplayer hack reversal
[16:12] <Daemon404> i totally forgot
[16:15] <wm4> I still don't understand how swr and avr came to be
[16:15] <wm4> especially in such high similarity
[16:15] <Daemon404> ffmetch fundign + youtueb funding + forkwars
[16:15] <Daemon404> and lulz
[16:15] <Daemon404> honestly, i really give 0 fucks abotu swr vs avr
[16:16] <Daemon404> note how i have purposelt been uninvolved
[16:16] <Daemon404> :D
[16:16] <kierank> wm4: see ml
[16:16] <kierank> wm4: swr came out of nowhere
[16:17] <kierank> wm4: avr was because of libav/ffmtech drama
[16:17] <Daemon404> kierank, translations: internet is srs bsns
[16:46] <kurosu> ff_(vc1|wmv3)_decoder have ".flush          = ff_mpeg_flush"
[16:46] <kurosu> ff_mpeg_flush does "MpegEncContext *s = avctx->priv_data"
[16:47] <kurosu> yet, avctx->priv_data should be afaik a VC1Context*
[16:47] <kurosu> I don't get how that works, and I suppose I'm missing something
[16:48] <kurosu> does that make more sense to someone else ?
[16:50] <kierank> probably the beginning of a vc1context is an mpegenccontext
[16:50] <kurosu> yes just confirmed that
[16:51] <kurosu> vc1.h:198
[16:51] <wm4> D:
[16:51] <kierank> that's pretty normal
[16:51] <kierank> the kernel does things like that sometimes
[16:51] <kierank> and also lets you go up with CONTAINER_OF
[16:51] <kierank> afaik libavcodec only ever goes down
[16:52] <ubitux> a lot of projects do that
[16:54] <kurosu> yeah, it's just that I had taken MpegEncContext being there as a random event and not something intended
[16:54] <kurosu> or even required, actually
[16:55] <wm4> <ubitux> a lot of projects do that <- and they're all morally wrong
[16:57] <ubitux> we might be wrong in the case of MpegEncContext, but in itself that's not wrong
[16:59] <cone-492> ffmpeg.git 03Derek Buitenhuis 07master:43654a22c037: Revert "lavc/utils: Do not require dimensions for PNG."
[17:00] <Daemon404> wm4, ^
[17:06] <wm4> sure took a while to undo this
[17:30] <cone-492> ffmpeg.git 03Christophe Gisquet 07master:84bc45880ae1: hevc_mvs: set candidate availabilities
[18:18] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:07262c719945: avcodec/options_table: leave xvidmmx AVOption in place
[18:18] <cone-492> ffmpeg.git 03Christophe Gisquet 07master:0d0d24af0159: hevc_ps: verify P/T/L information
[18:21] <BBB> Daemon404: so happy to be using mac; no need for all this distro trollcrap
[18:21] <BBB> just some bofh that decides what my computer runs and it works
[18:23] <wm4> yeah, and there are only 3 or so projects that try to play linux distro on the mac (like homebrew)
[18:38] <cone-492> ffmpeg.git 03Luca Barbato 07master:fb1ddcdc8f51: avresample: Introduce AVFrame-based API
[18:38] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:78eaaa857e95: Merge commit 'fb1ddcdc8f51b9d261ae8e9c26b91e81f7b6bf45'
[18:47] <cone-492> ffmpeg.git 03Diego Elio Pettenò 07master:2597a842a0a2: tiff: Improve grayscale support
[18:48] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:61b9ce00a30c: Merge commit '2597a842a0a2c7e8aa76f32733d27bf64817ae86'
[18:54] <cone-492> ffmpeg.git 03Carl Eugen Hoyos 07master:273fc0139e0a: lavf/img2dec: Initialize a stack variable.
[18:54] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:d6efed84b1da: Merge remote-tracking branch 'cehoyos/master'
[18:55] <BBB> kurosu: and yes youre right end-of-buffer validation is a good idea regardless for sps/vps/pps
[18:56] <kierank> the encoders i've seen have totally buggered vps
[18:57] <nevcairiel> Luckily the decoder doesn't read vps then
[18:58] <mraulet> it does but not too mcuh
[18:58] <nevcairiel> (Or well use anything from it)
[18:59] <mraulet> vps is mostly needed for hevc extensions
[18:59] <kierank> it did try and validate it
[18:59] <cone-492> ffmpeg.git 03Martin Storsjö 07master:f4312352fc52: configure: Add probe identification of MS armasm
[19:00] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:f51c3e3a84e6: Merge commit 'f4312352fc52cc47c1ba398a33f629d32a737e91'
[19:53] <cone-492> ffmpeg.git 03Diego Biurrun 07master:9f8cf50e3be0: configure: Enable gas-preprocessor on all OSes but only if available
[19:53] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:7e4e45d227e1: Merge commit '9f8cf50e3be04b8e178086edaa4598826143303d'
[20:31] <cone-492> ffmpeg.git 03Martin Storsjö 07master:ab0742d2f34d: configure: Suggest upgrading gas-preprocessor instead of just installing
[20:31] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:3787495e1f2c: Merge commit 'ab0742d2f34d70415620441b7ed7da2f03a0c14f'
[20:50] <cone-492> ffmpeg.git 03Reinhard Tartler 07master:59cc0812207e: Prepare for 11_alpha2 Release
[20:50] <cone-492> ffmpeg.git 03Nidhi Makhijani 07master:8dca0877e3e1: mpegts: Return proper error code on invalid input data
[20:50] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:c24be3c4a2e1: Merge commit '59cc0812207e3c2e2f2e559d60d0a8f9296a8847'
[20:50] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:d123d9abef52: Merge commit '8dca0877e3e1457e9ec79ffa1ead1135aabb791c'
[20:59] <cone-492> ffmpeg.git 03Anton Khirnov 07master:d63443b9684f: lavc: drop the av_fast_{re,m}alloc compatibility wrappers
[20:59] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:bd879652476b: Merge commit 'd63443b9684fa7b3e086634f7b44b203b6d9221e'
[21:08] <wm4> is trac down?
[21:09] <kierank> it's up but slow
[21:10] <wm4> hm yeah, now it seems to be loading... extremely slowly
[21:23] <kurosu> same here
[21:28] <viperfx_> Hi guys, I have come across another bug. Regarding openssl though this time. I can reproduce it in cmd line on desktop and on ios
[21:28] <viperfx_> Wanted to run it by you guys before submitting a ticket
[21:29] <viperfx_> First you will need to generate a URL with youtube-dl. $ youtube-dl -f 171 -g YOUTUBE_URL
[21:29] <viperfx_> That should give a stream url for WebM format
[21:30] <viperfx_> If you test that url with ffplay "stream_url"
[21:30] <viperfx_> You will notice at the end of the audio. There is this error: [tls @ 0x7fb64af13f20] error:00000000:lib(0):func(0):reason(0)0/0
[21:35] <wm4> ah, lovely incomprehensible openssl errors (or is it gnutls)
[21:35] <wm4> ah, openssl
[21:36] <wm4> in general this code seems to work (there are people using it)
[21:37] <cone-492> ffmpeg.git 03Mark Reid 07master:cab39afb1a9c: avformat/movenc: check that reel_name length doesn't exceed UINT16_MAX
[21:43] <viperfx_> Yea, its strange. I did not have this issue til recently.
[21:44] <viperfx_> It is not an issue really, but iOS panic's out
[21:44] <viperfx_> and I dont know how to avoid it
[21:52] <BBB> kurosu: I like that patch :)
[21:52] <BBB> (the vps/sps/pps/slicehdr size validation)
[21:54] <BBB> kierank: I dont see your new thread?
[21:54] <kierank> BBB: i'm not going to start a new thread after all the angry pms and emails I got
[21:54] <BBB> just the existing one, which is way too long and mythtv-central so Im not going to make that worse
[21:54] <BBB> I wsnt angry
[21:54] <kierank> not from you
[21:54] <kierank> but from others
[21:54] <BBB> oh ok
[21:54] <BBB> fine then
[21:54] <kierank> In fact I regret posting in that thread
[21:55] <BBB> soryr to hear, anyway, I agree with the general comment that the api couldve benefited from a quick review
[21:55] <BBB> I do fairly feel that swr is a lot faster than avr but some people dont seem to care about that
[21:57] <kierank> BBB: are you going to vdd?
[21:58] <BBB> no, my sisters wedding is around the same time
[21:58] <BBB> maybe next year, although I have to admit flying hasnt gotten cheaper lately
[21:58] <BBB> Im trying to buy a house so money is getitng more tight again
[22:03] <kurosu> BBB: Michael already had fortified the decoder though but it was time to reduce the attack window
[22:03] <kurosu> BBB: and the bigger city you live in, the more expensive they get
[22:04] <BBB> yeah Ive noticed that, prices are like way out there
[22:04] <kurosu> I kind of remember an image series showing NY flats and european mansions of equivalent prices
[22:04] <BBB> its the problem if everyone has money; you only get stuff if you have MOAR MOAR MOAR
[22:04] <kurosu> I don't know how disconnected are rates nowadays
[22:05] <kurosu> Many French people have to take a mortgage for 20+ years
[22:05] <kurosu> put another way, prices per square meters have doubled with inflation compensated
[22:05] <kurosu> in 10 years
[22:09] <kierank> many english people will just permanently rent
[22:09] <kierank> generation of renters
[22:12] <BBB> in manhattan, financial district is considered relatively cheap, and youll get a 2-bedroom appat (1000-1400sqft) for 1.2-1.4 million in a basic setting; the problem is that with all these rich people, theyre putting down double-price luxury appartments with things like gym, lounge, like a hotel more than a house, and that gets into 2-3million for the same appartment, and I just dont have that money but supply keeps going down in nor
[22:12] <BBB> appts
[22:12] <BBB> brooklyn is nice also& but Id like to buy in manhattan if I can
[22:15] <ubitux> ffs i spent my w-e on something i hate with passion: threading
[22:15] <ubitux> at least it seems to work now
[22:16] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:9bcdb98839f3: avcodec/iff: Factorize av_pix_fmt_desc_get() out
[22:16] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:3539d6c63a16: avcodec/iff: check pixfmt for rgb8 / rgbn
[22:20] <BBB> threading is cool
[22:23] <ubitux> no >:(
[22:24] <ubitux> it's a pain, and it's cheating!
[22:37] <ubitux> we lack a "developers" page on our web site
[22:37] <ubitux> developers/contribute
[22:37] <ubitux> something like, what's the main method to submit patches etc
[22:37] <Compn> you mean donate or welcome to the porject ?
[22:37] <Compn> ah
[22:37] <ubitux> it's kind of mentioned in the mailing-list page but...
[22:38] <ubitux> people often tend to look at github typically
[22:38] <Compn> you mean like this page
[22:38] <Compn> http://www.videolan.org/contribute.html
[22:38] <Compn> kinda
[22:38] <ubitux> yes
[22:38] <ubitux> and merge the "MPlayer patch guidelines" into that page
[22:43] <BBB> omg bitcoin
[22:43] <Compnn> what i miss
[22:43] <BBB> anyway hows that ffmpeg foundation thing going?
[22:43] <BBB> like, can I request new hardware like a nice macbook pro laptop? my current one doesnt have avx2
[22:44] <Compn> yes, thats absolutely what donations are for
[22:44] <Compn> so devels can work on specific hardwares
[22:44] <Compn> assuming you are going to work on avx2 and not just .... get a new macbook :P
[22:44] <Compn> not that i run the program or anything, just my opinion
[22:46] <ubitux> BBB: https://ffmpeg.org/pipermail/ffmpeg-devel/2014-July/159929.html
[22:47] <ubitux> we currently have about 3.5k it seems
[22:48] <BBB> 3.5k doesnt get you a macbook, ok, Ill just buy my own then
[22:48] <BBB> its funny, when I started ffmtech, it had 20-30k or so? where did all that money go
[22:48] <ubitux> ah, ffmtech might have way more money
[22:48] <BBB> I guess I had different methods of getting donations back then
[22:48] <ubitux> http://ffmtech.org/projects.html
[22:49] <BBB> omg diego inline asm conversion
[22:49] <BBB> all whitespacers please alert
[22:50] <BBB> ok anyway
[22:50] <ubitux> it's funded it seems
[22:50] <ubitux> ;)
[22:50] <kierank> afaik it's not fonded
[22:50] <ubitux> i'm just refering to the progress bar on the right
[22:50] <kierank> oh yeah
[22:50] <kierank> lol
[22:51] Action: BBB gonna take kids out
[22:51] <BBB> later
[22:51] <ubitux> "hf"
[23:32] Action: ubitux wonders why the diff planes of mpdecimate has increment of 4... and starts at x=8
[23:33] <cone-492> ffmpeg.git 03Chris \"Koying\" Browet 07release/2.3:6d2219e9f950: avcodec/h264_mp4toannexb_bsf: fix issue when sps/pps are already in the bistream (cherry picked from commit ad91bf854b559f1afc42fc06f8a7dfbb75def5c8)
[23:33] <cone-492> ffmpeg.git 03Benoit Fouet 07release/2.3:7a1262fca37d: h264_mp4toannexb_bsf: account for consecutive IDR pictures.
[23:33] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:594b1fa9615f: libavcodec/h264_parser: Increase parse_history, fix huge resolutions
[23:33] <cone-492> ffmpeg.git 03Anshul Maheswhwari 07release/2.3:3ed27832e7b0: v4l2enc: adding AVClass
[23:33] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:d6173ae341fa: avcodec/mpeg12dec: fix support for interlaced mpeg2 with missing last slice
[23:33] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:aa0a8ef50e88: avcodec/dvdsub_parser: never return 0 when the input isnt 0
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:76d59f1b34bb: avcodec/dvdsub_parser: Check buf_size before reading 32bit packet size
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:638c3aca645a: avcodec/dvdsub_parser: print message if packet is smaller than the packet size field
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:2eb72d5bdcd5: ffmpeg_opt: Use av_guess_codec() instead of AVOutputFormat->*codec
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:b63ec0cb0fb5: avformat/tee: flip assigment direction
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:fdfe94f4b16f: avcodec/wavpackenc: Fix log2sample() result value
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:7a6b5d7a867e: ffserver: initialize pbuffer in prepare_sdp_description()
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:901e275697de: avutil/cpu: add aarch64 entries to 2nd table
[23:34] <cone-492> ffmpeg.git 03Anton Khirnov 07release/2.3:a72b7286e6db: cdgraphics: do not return 0 from the decode function
[23:34] <cone-492> ffmpeg.git 03Felix Abecassis 07release/2.3:69281934935e: h264: fix interpretation of interleved stereo modes
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:ed15be7519af: avformat/matroskaenc: fix MAX_CUEPOINT_SIZE calculation
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:83956309cc16: avcodec/iff: check pixfmt for rgb8 / rgbn
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:fc57959fd57d: avcodec/iff: Factorize av_pix_fmt_desc_get() out
[23:34] <cone-492> ffmpeg.git 03Michael Niedermayer 07release/2.3:c5129da726bb: update for FFmpeg 2.3.2
[23:41] <cone-492> ffmpeg.git 03Carl Eugen Hoyos 07master:788cf6f0c607: Remove panscan information in av_frame_copy_props() if resolution changes.
[23:47] <cone-492> ffmpeg.git 03Diego Biurrun 07master:cc1d8c54c19d: avcodec: Postpone FF_IDCT_XVIDMMX removal until the next version bump
[23:47] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:d177f275170c: Merge commit 'cc1d8c54c19dd14fb851e3e7a7793d6b3bd75e94'
[23:51] <jamrial> michaelni: might be a good idea to undo commit 07262c71 to reinstate the FF_API_IDCT_XVIDMMX guards
[23:53] <cone-492> ffmpeg.git 03Martin Storsjö 07master:08b94f160a2c: configure: Don't pass MSVC compiler options -M[TD] to armasm
[23:53] <cone-492> ffmpeg.git 03Michael Niedermayer 07master:77273456137f: Merge commit '08b94f160a2c966bb83e32bde0e52246fafa2155'
[23:55] <michaelni> jamrial, hmm, possible but imho we should keep the command line support longer than the next bump, its just one line 
[23:57] <jamrial> fine by me
[00:00] --- Mon Aug 11 2014