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

[burek]

[00:11] <ubitux> it seems 24-bit flac encoding is using uninitialized values mmh..
[00:11] <ubitux> too bad libav doesn't have a full valgrind instance to spot it
[00:11] <durandal_1707> what? where?
[00:11] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20121106201806&slot=x86_64-archlinux-gcc-valgrindundef
[00:12] <durandal_1707> that each helgrind report takes 1 tb
[00:12] <ubitux> this is not helgrind
[00:13] <ubitux> if you are annoyed by the long helgrind & drd report, feel free to fix the races :)
[00:13] <durandal_1707> you evil
[00:13] <ubitux> ;)
[00:13] <ubitux> if you don't i'll add a hook to kill a kitten everytime cama2 vtc b fails
[00:14] <durandal_1707> what is that?
[00:14] <ubitux> you know the common h264 threading race
[00:14] <ubitux> that fails sometimes
[00:16] <Daemon404> even with teh fixes bbb and you did
[00:16] <Daemon404> ?
[00:17] <durandal_1707> see this table: http://download.das-werkstatt.com/pb/mthk/ffv1_stats/20121106/ffv1_stats.html - what all that numbers means....
[00:17] <ubitux> Daemon404: yes
[00:18] <ubitux> Daemon404: there are still many races actually.
[00:18] <ubitux> all over the threading thing
[00:18] <Daemon404> i know
[00:20] <ubitux> mr1_bt_a still fails too sometimes
[00:21] <durandal_1707> ubitux: could you add some subtitle encoding test so coverage is yellow/green for them?
[00:22] <ubitux> what encoder are you thinking about?
[00:22] <ubitux> ass encoding should be tested
[00:22] <ubitux> and srt encoding si kinda broken
[00:22] <ubitux> which i need to fix btw
[00:22] <ubitux> just messing with something else these days
[00:23] Action: ubitux still has no clue how to normalize properly rdft things
[00:23] <durandal_1707> wat  is SAP used for?
[01:52] <cone-11> ffmpeg.git 03Michael Niedermayer 07de0aa9e5a4e6: kgv1dec: fix end condition
[02:33] <cone-11> ffmpeg.git 03Paul B Mahol 077c2cfaac6a24: smjpegenc: use bits_per_coded_sample instead of calling function
[08:44] <cbsrobot> in 617d0d41a2 saste added an ifeq ($(CONFIG_AVCODEC),yes) &. to doc/Makefile and I am wondering
[08:45] <cbsrobot> as it is the only conditional based ifeq in all Makefile, is it advisable to do it this way ?
[08:46] <cbsrobot> I mean can I f.ex missuse the HAVE_LIST in configure to make coditional based switches in a Makefile ?
[08:49] <ubitux> cbsrobot: no idea but the rules in that files look a bit fragile
[08:49] <ubitux> like ifdef CONFIG_MANPAGES
[08:50] <cbsrobot> yeah this too
[08:50] <cbsrobot> ther is also ifdef SAMPLES in tests/Makefile
[08:50] <ubitux> mmh the ifdef should be ok actually
[08:51] <ubitux> since in config.mak you have either CONFIG_MANPAGE=yes or !CONFIG_MANPAGE=yes
[08:51] <ubitux> i think the ifeq needs to be change to a ifdef
[08:51] <ubitux> it's likely a confusion with config.h vs config.mak
[08:51] <cbsrobot> hmmm
[08:51] <cbsrobot> w
[08:52] <cbsrobot> well the ifdef SAMPLES in tests/Makefile checks for an evironnement variable
[08:52] <ubitux> that's fine as well
[08:52] <cbsrobot> but the ifdef CONFIG_MANPAGES checks for it in config.mak
[08:52] <ubitux> CONFIG_AVCODEC/yes in doc/Makefile should just be changed to a ifdef
[08:53] <ubitux> cbsrobot: SAMPLES is special
[08:53] <ubitux> you can make fate SAMPLES=...
[08:53] <cbsrobot> well that could lead to a lot of ifdeffery
[08:53] <cbsrobot> not sure this is the way to go &.
[08:53] <ubitux> ?
[08:54] <ubitux> i don't understand your problem
[08:54] <cbsrobot> it's not a problem
[08:54] <cbsrobot> I'm just wondering if it is ok to add ifdefs everywhere
[08:55] <cbsrobot> well it seems so
[08:55] <ubitux> you could try to do a DOCLIBS-$(CONFIG_AVCODEC) += libavcodec if you prefer
[08:55] <ubitux> and yes DOCLIBS-yes instead of DOCLIBS
[08:56] <ubitux> this doclibs thing is a bit weird though
[08:56] <cbsrobot> ok
[08:56] <cbsrobot> we
[08:57] <cbsrobot> well I'll send a patch for another issue and you can comment on that if you want
[08:57] <ubitux> (and /use/ DOCLIBS-yes..)
[09:00] <cbsrobot> hmm
[09:00] <cbsrobot> w
[09:00] <cbsrobot> whats the purpose of doclibs
[09:02] <cbsrobot> well I think I figured it out
[09:02] <cbsrobot> nm
[09:07] <ubitux> michaelni: just fyi, it seems i need to use 1./(1<<(N-1)) as rescale factor
[09:08] <ubitux> or 2/(1<<N)
[09:12] <ubitux> note this is to be applied on the complex numbers, note the magnitudes
[09:12] <ubitux> not* the magnitudes
[10:02] <ubitux> so this normalization: http://pastie.org/5339350
[10:02] <ubitux> seems to work: http://pastie.org/5339343
[10:06] <ohsix> do you know a lot about dsp?
[10:07] <ohsix> i've been looking for a treatise on why saturation is acceptable when you can probably also increase the word size
[10:08] <ubitux> no i really don't know much, and it even took me hours to realize how i was supposed to normalize properly
[10:08] <ubitux> and i found this by trial and error..
[10:09] <ohsix> hrm
[10:10] <ohsix> i've investigated it a bit, in audio and stuff i've seen math that pretty much makes the distinction useless; but the contexts it comes up in has it as a foregone conclusion and i'm just looking for background
[10:11] <ohsix> (and it's not always just to avoid wrapping as integers on the computermachines are want to do)
[10:50] <cone-765> ffmpeg.git 03Martin Storsjö 07ad961726dc0b: libopencore-amr: Check the return value of amr_decode_fix_avctx
[10:50] <cone-765> ffmpeg.git 03Michael Niedermayer 07cb395929e379: Merge remote-tracking branch 'qatar/master'
[11:14] <ubitux> michaelni: btw, why the "integer" define in swr instead of ptrdiff_t like it seems to be used in other places?
[11:51] <michaelni> the intent was to have a type for the native register size
[11:51] <michaelni> ptrdiff_t is VERY likely that but i think theres no gurantee
[11:51] <michaelni> and if not the asm code will actually fail
[11:52] <michaelni> and the C code might be slower
[11:55] <michaelni> also IIRC if we look at pre 32bit, there where cases where the max pointer differeence was larger than the native register size. I have no idea if this applied to any modern 32/64 bit system though
[11:56] <michaelni> applieS
[12:03] <ubitux> mmh, ok
[13:03] <ubitux> it seems i was able to do a naive fft 2d, yepee.
[13:04] <ubitux> saste: cbsrobot spotted a problem with what's on top of doc/Makefile
[13:05] <ubitux> or at least that's inconsistent
[13:06] <ubitux> i wonder if DOCLIBS-$(CONFIG_AVCODEC) += libavcodec and similar for the other libs wouldn't make more sense
[13:06] <ubitux> and btw in your doc filters your adding in under the wrong condition
[13:06] <ubitux> well, i'll send a mail.
[13:31] <cone-765> ffmpeg.git 03Michael Niedermayer 07dd11615bbca6: ffv1dec: more completely check slice count
[13:31] <cone-765> ffmpeg.git 03Michael Niedermayer 07fdfbb793c313: ffv1dec: propagate return code from ffv1_common_init()
[13:40] <durandal_1707> juanmabc: can adpcm amv support stereo?
[13:42] <juanmabc> s1mp3 players are good in audio, mp3 even, so players sure, format i don't know
[13:43] <juanmabc> ironically i would need a encoder to know
[13:44] <durandal_1707> encoder from avmtools supports mono only
[13:44] <nevcairiel> what does our decoder think?
[13:45] <durandal_1707> but my question is really, is there stereo adpcm amv samples?
[13:45] <cone-765> ffmpeg.git 03Peter Ross 07b50759cd6b48: wtvenc: do not emit stream2 and DSATTRIB_TRANSPORT_PROPERTY chunks; these are not required for playback
[13:48] <juanmabc> durandal_1707: let me check the companion windows amv encoder tool options, to reverse engineer that
[13:50] <juanmabc> for starters: this is "ffmpeg -i winencodedfile.amv": http://fpaste.org/OrjB/
[13:51] <cone-765> ffmpeg.git 03Peter Ross 070d9435048c12: wtvenc: indent fixup
[13:51] <cone-765> ffmpeg.git 03Peter Ross 073e65134326b8: wtvenc: output third video pts in timestamp chunk (this is what Microsoft Windows Media Center expects)
[13:56] <cone-765> ffmpeg.git 03Peter Ross 07b89cd2a0289f: wtvenc: simplify write_timestamp
[13:57] <juanmabc> durandal_1707: nope, the qualities are 3, low, normal, high, and the sizes are like 10, more than amv-codec-tools uses to manage
[13:59] <durandal_1707> size of what?
[13:59] <juanmabc> widthxheight: 128x128
[14:00] <juanmabc> since it's a player format, it has predefined sizes, i guess that does not matter for ffmpeg codecs
[14:00] <durandal_1707> looks no options for audio
[14:00] <durandal_1707> and what you use as source for audio?
[14:02] <cone-765> ffmpeg.git 03Peter Ross 07a373f352728c: wtvenc: produce seekable files
[14:04] <cone-765> ffmpeg.git 03Paul B Mahol 0708101e62cbde: adpcm: improve smjpeg decoding
[14:05] <juanmabc> durandal_1707: currently win version can use any direct show capable format to avi, amv-codec-tools seems to support a lot, though mp4 to amv works better
[14:06] <juanmabc> can you dcc receive files ? else i can upload the screenshot to an image pastebin
[14:06] <juanmabc> s/to avi/to amv/
[14:06] <durandal_1707> but does it produce stereo file from stere source
[14:07] <juanmabc> no
[14:07] <juanmabc> ffmpeg -i file original was stereo
[14:07] <juanmabc> settings have no mono/stereo setting
[14:10] <juanmabc> settings window: http://www.pasteall.org/pic/40095
[14:12] <juanmabc> it's a really limited format, but for the player, does the job nicely
[15:03] <durandal_1707> how to remove metadata?
[15:21] <vega13> hi
[15:21] <vega13> How can I feed my decoder SPS data for h264 decoding?
[15:21] <ubitux> durandal_1707: there are some tricks around -map_metadata for this
[15:25] <vega13> If I don't use an automatic avcodecctx I have to provide SPS data for the first packet so my decoder knows how to decode
[15:25] <durandal_1707> ubitux: i'm not aware of any
[15:25] <vega13> I know the sprop-parameter-sets of the h264 stream 
[15:26] <ubitux> durandal_1707: it's in the doc
[15:26] <vega13> do i need to insert this inside the data of the first avpacket ?
[15:26] <durandal_1707> ubitux: i read doc and couldn't find it
[15:27] <ubitux> A negative
[15:27] <ubitux> file index can be used to create a dummy mapping that just disables automatic copying.
[15:27] <ubitux> ?
[15:37] <vega13> Is it possible to decode a h264 stream with a custom avcodeccontext?
[16:33] <michaelni> vega13, SPS can be feeded into the decoder either in a packet of extradata
[16:34] <michaelni> oR
[17:15] <vega13> Thanks michaelni!
[18:08] <cone-765> ffmpeg.git 03Michael Niedermayer 074d2f83f8acb6: gsm_parser: fix infinite loop
[18:37] <cone-765> ffmpeg.git 03Michael Niedermayer 079dfe07a1fbcd: fate-rsync: replace -a by -rlt
[20:26] <ubitux> wtv is now leaking
[20:26] <ubitux> is peter on irc?
[20:27] <durandal_1707> ubitux: i doubt
[20:28] <ubitux> ok :(
[20:30] <durandal_1707> ubitux: thanks to your coverage logs it is easy to spot stupid/untested code
[20:31] <ubitux> your welcome :)
[22:33] <cone-187> ffmpeg.git 03Thierry Foucu 0798cbbabadb70: Fix the packet duration when flushing the encoder.
[22:48] <ubitux> michaelni: can you confirm the clipping to w-1 and h-1 in mplayer's geq is wrong?
[22:48] <ubitux>     xi=x= FFMIN(FFMAX(x, 0), (mpi->w >> (plane ? mpi->chroma_x_shift : 0))-1);
[22:48] <ubitux>     yi=y= FFMIN(FFMAX(y, 0), (mpi->h >> (plane ? mpi->chroma_y_shift : 0))-1);
[22:49] <ubitux> afaiu this is doing a av_clipf(x, 0, w - 1)
[22:49] <ubitux> and same of height
[22:49] <ubitux> but in the return you get:
[22:49] <ubitux>      (1-y)*((1-x)*src[xi +  yi    * stride] + x*src[xi + 1 +  yi    * stride])
[22:49] <ubitux>     +   y *((1-x)*src[xi + (yi+1) * stride] + x*src[xi + 1 + (yi+1) * stride]);
[22:49] <ubitux> so you're hitting at +1
[22:49] <ubitux> in the port i've changed it to w-2 and h-2
[22:49] <ubitux> so if you have a minute to comment on this&
[23:07] <michaelni> ubitux, you could try a last column/row that is white on aotherfwise black pic to see if its the correct fix
[23:22] <cone-187> ffmpeg.git 03Stefano Sabatini 07ef4dc3e55b67: lavu/opt: show valid range in case of out-of-range value
[23:22] <cone-187> ffmpeg.git 03Stefano Sabatini 071c6962dc20dc: lavu: remove disabled FF_API_OLD_EVAL_NAMES code
[23:22] <cone-187> ffmpeg.git 03Stefano Sabatini 0758d1d7024d6d: doc/Makefile: change DOCLIBS check
[23:23] <ubitux> michaelni: ok, will give it a try eventually; it's easy to reproduce the invalid read though
[23:24] <ubitux> i didn't try with mp=geq since it crashes all the time :p
[23:26] <durandal_1707> ubitux: not when i tested it
[23:26] <ubitux> durandal_1707?
[23:26] <ubitux> ./ffmpeg_g -f lavfi -i testsrc=d=1 -vf 'mp=geq=p(W-X\,Y)' -f null -
[23:26] <ubitux> this works for you?
[23:28] <durandal_1707> no, but in mplayer
[23:32] <ubitux> ok
[23:33] <durandal_1707> ubitux: can you do emboss with geq ?
[23:33] <ubitux> might be possible
[23:34] <ubitux> (p(x,y)+p(x-1,y-1))/2 or something?
[23:36] <cone-187> ffmpeg.git 03Alexander Strasser 074ccfcc8a0b16: doc/libavcodec: hint to where to find the Git history
[23:38] <ubitux> might be better adding -p(x+1,y+1) or stuff like that
[23:38] <ubitux> just find a common emboss convolution matrix
[23:39] <ubitux> i saw one recently, but don't have it in mind
[23:46] <cone-187> ffmpeg.git 03Nicolas George 07d55911adc8be: doc/faq: replace @file by @command for "ffmpeg".
[00:00] --- Thu Nov  8 2012