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

[burek]

[00:11] <Compn> Pinhole : just for playing ?
[00:12] <Compn> a multi-core box or even video card that has hw accel mpeg2 would be better ...
[00:12] <Compn> unless you want multiple 1080 streams on one puter or something silly
[00:12] <Compn> even then, unloading decoding wouldnt help afaik
[00:16] <Pinhole> sh4 processor with an embedded co-processor.
[00:17] <Compn> sh4 , isnt that like dreamcast ?
[00:31] <cone-448> ffmpeg.git 03Alexis Ballier 071475815a1a06: Apply again [916352f282855e3e4e86a39df9452fead2aa0771] that got lost in the merges.
[01:42] <Pinhole> Compn, it's an older settop box.  I'm trying to replace a binary blob with something open and more current.
[02:10] <Compn> Pinhole : ah, sounds very complicated
[02:11] <Pinhole> Shouldn't be too bad.  I should be able to feed a buffer in shared memory, use avcodec to decode it directly into the framebuffer.
[03:56] <cone-153> ffmpeg.git 03Michael Niedermayer 07ebfc212b02bf: dv1394: fix order of AVOption fields
[05:11] <cone-153> ffmpeg.git 03Jason 07a5f6720f13c7: Add QT CC track mux support
[08:09] <ohsix> that's one interesting bug
[08:10] <ubitux> wtf
[08:10] <ubitux> ah haha he kept "Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker."
[08:10] <ubitux> Priority: critical
[08:10] <ubitux> nice
[08:10] <ohsix> i'm wondering if he has some weird build or if he messed it up himself
[08:11] <ohsix> orrrr if he literally doesn't know how to do anything but vcodec msmpeg4v2
[08:11] <ohsix> developer reproduced: yes, too
[08:20] <ohsix> oh boy
[08:21] <ohsix> i see a fe wmore of these in the immediate future
[08:21] <ohsix> i can't help but think that dude gets to spend other peoples money to not read the documentation
[12:45] <divVerent> Mista_D: as for this ticket, I am not sure, but could this usage require specifying a bitstream filter manually?
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07bb6941af2afd: lavc: move SANE_NB_CHANNELS to internal.h and use it in the PCM decoders
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 070366664ef9af: lavc: check channel count after decoder init
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07a4202003b21e: dca_parser: allow the parser to change the sample rate
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07b24a4449a5ae: amrnbdec: set channels, channel_layout, and sample_rate
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07ee0e9678e761: amrwbdec: set channels, channel_layout, and sample_rate
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07ec2694d25905: g722dec: set channel layout at initialization instead of validating it
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 074f56f9c48f40: dsicinaudio: set channels and channel layout
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07a38eadf7ed08: atrac1: do not keep a copy of channel count in the private context
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07a3145d0335b0: bmvaudio: set channel layout at init() rather than validating it
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 073509eee19c03: cook: use AVCodecContext.channels instead of keeping a private copy
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 078aa5b8c5c825: cook: remove unneeded COOKContext variable, bit_rate
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07926e9d28f1a8: cook: remove unneeded COOKContext variable, sample_rate
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 07d21b2e472682: cook: reverse a condition so that the code makes more sense
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 077efbba2e3665: cook: use av_get_channel_layout_nb_channels() instead of cook_count_channels()
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 078f173ef019d7: cook: move samples_per_frame from COOKSubpacket to where it is used
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 0793e27f86f161: cook: use av_dlog() for debug logging instead of av_log() with AV_LOG_ERROR
[13:49] <cone-559> ffmpeg.git 03Justin Ruggles 078ac0f6767bf6: dcadec: allow the decoder to change the channel layout mid-stream
[13:49] <cone-559> ffmpeg.git 03Michael Niedermayer 07db9f426caba5: Merge commit '8ac0f6767bf63d3e6b308ee6648ff02598b81e03'
[14:05] <cone-559> ffmpeg.git 03Michael Niedermayer 0700aa7fa786e4: pcm: fix handling of more than 8 channels for planar
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 07268f8ba11257: flacdec: use av_samples_* functions for sample buffer allocation
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 0790fcac0e95b7: flacdec: allow mid-stream channel layout change
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 0799d868635725: flacdec: do not warn on sample rate change
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 07e00eb03cd8bf: g726dec: set channel layout at initialization instead of validating it
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 07a346aaf148dc: g726dec: do not validate sample rate
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 07c5b8acad731c: libgsmdec: always set channel layout and sample rate at initialization
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 0732c7769e5c85: gsmdec: always set channel layout and sample rate at initialization
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 071c7a0161538a: imc: set channels to 1 instead of validating it
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 070fd1ddf15545: dpcm: use AVCodecContext.channels instead of keeping a private copy
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 0730f8da29bf60: libilbc: set channel layout
[14:32] <cone-559> ffmpeg.git 03Justin Ruggles 07d40dab907aad: libopencore-amr: set channel layout for amr-nb or if not set by the user
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 07d26701ce2f35: nellymoserdec: set channels to 1
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 07e3d6ab57042e: qcelpdec: set channel layout
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 07be2ab8b75a63: qdm2: make sure channels is not <= 0 and set channel layout
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 07eb38d8fe926b: qdm2: remove unneeded checks for channel count
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 076159f6436495: ra144dec: set channel layout
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 074e13e50432bd: ra288dec: set channel layout
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 074c53f4aed3ed: shorten: validate that the channel count in the header is not <= 0
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 07523734eb6a90: sipr: set channel layout
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 07cebea00c8aba: truespeech: set channel layout
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 078cc72ce5a0d8: twinvq: validate that channels is not <= 0
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 07335826cf5f71: twinvq: set channel layout
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 07b5f628e22774: twinvq: validate sample rate code
[14:33] <cone-559> ffmpeg.git 03Justin Ruggles 0750a65e7a540c: vmdaudio: set channel layout
[14:33] <cone-559> ffmpeg.git 03Michael Niedermayer 076788350281c4: Merge commit '50a65e7a540ce6747f81d6dbf6a602ad35be77ff'
[14:49] <durandal_1707> is there nice way to read float from string in portable way?
[14:54] <saste> durandal_1707, I suppose sscanf is not good enough
[14:54] <ubitux> av_strtod?
[14:55] <ubitux> i think nicolas worked on a native implementation
[14:55] <durandal_1707> saste: and how would you convert that rational?
[14:56] <saste> durandal_1707, where's the trap?
[14:57] <durandal_1707> i need to convert 15.00 to rational
[14:58] <saste> different platforms may have a different representations of the same value, but i suppose you know that
[14:58] <saste> 15.00 is a string?
[14:58] <saste> usually we do: "15.00" => av_strtod() => av_d2q()
[14:58] <durandal_1707> yes
[14:59] <saste> i don't know if there is a more direct way
[15:00] <saste> durandal_1707, av_parse_ratio() also may do
[15:04] <ubitux> saste: shoudln't we accept only hexa input for numerical value of the sample fmt ?
[15:05] <ubitux> iirc for pan for instance, there is a tricky thing like chlayout:..., where chlayout can be a string, or a 0x value, but also an int for the number of channels
[15:06] <ubitux> though, for sample format it might not make sense
[15:06] <ubitux> but what if the numerical value was the defaut sample format for a given number of bytes, and the hex value the sample fmt id ?
[15:09] <saste> ubitux, I copypasted the OPT_PIX_FMT code
[15:10] <saste> also how the trick applies to the sample formats?
[15:11] <saste> and you want to do: printf("sample_fmt:%d", sample_fmt) rather than %0xd
[15:11] <ubitux> it was a comparison with sample format because the value can represent the sample format or the number of channel from which a default channel layout is choosen
[15:11] <ubitux> and i was thinking of something similar with the number of bytes for a given sample format
[15:11] <ubitux> (sample *layout* in the first sentence sorry)
[15:12] <cone-559> ffmpeg.git 03Justin Ruggles 072ed40608e949: wma: do not keep private copies of some AVCodecContext fields
[15:12] <cone-559> ffmpeg.git 03Justin Ruggles 07002097a00bb9: wmapro: use AVCodecContext.channels instead of keeping a private copy
[15:12] <cone-559> ffmpeg.git 03Justin Ruggles 07f7b8506573f2: wmavoice: set channel layout
[15:12] <cone-559> ffmpeg.git 03Justin Ruggles 075459848b146f: ws-snd1: set channel layout
[15:12] <cone-559> ffmpeg.git 03Ilkka Ollakka 076d1270a0f9ed: decode_audio3: initialize AVFrame
[15:12] <cone-559> ffmpeg.git 03Martin Storsjö 07c19e9d00a706: doc: Point to the new location of the c99-to-c89 tool
[15:12] <cone-559> ffmpeg.git 03Anton Khirnov 07f70381ab9d53: a64: remove interleaved mode.
[15:12] <cone-559> ffmpeg.git 03Anton Khirnov 07179a5c37e070: rtpdec: factorize identical code used in several handlers
[15:12] <cone-559> ffmpeg.git 03Anton Khirnov 07fdc867288697: audiointerleave: deobfuscate a function call.
[15:12] <cone-559> ffmpeg.git 03Anton Khirnov 070876c2808075: lavc: add some AVPacket doxy.
[15:12] <cone-559> ffmpeg.git 03Martin Storsjö 072b831a59d9ea: rtpdec_vp8: Don't parse fields that aren't used
[15:12] <ubitux> but really just an idea
[15:12] <cone-559> ffmpeg.git 03Michael Niedermayer 07e1c804d883f3: dv1394: Swap the min and max values of the 'standard' option
[15:12] <cone-559> ffmpeg.git 03Michael Niedermayer 078551c6bec0fd: Merge remote-tracking branch 'qatar/master'
[15:12] <ubitux> <@saste> and you want to do: printf("sample_fmt:%d", sample_fmt) rather than %0xd // why?
[15:12] <saste> ubitux, feel free to reply on list, but les's try not to overdesign things
[15:13] <ubitux> 0x%x looks appropriate but well :)
[15:13] <ubitux> just to be clear: i'm fine with the patch as is
[15:13] <ubitux> this idea just crossed my mind p
[15:13] <ubitux> :p
[15:13] <saste> i'm running away, cyl
[15:13] <ubitux> cya :)
[15:22] <burek> hm
[15:23] <burek> does ffplay has any frame size limitations for playing videos?
[15:23] <burek> http://ffmpeg.gusari.org/viewtopic.php?f=26&t=719
[15:24] <durandal_1707> yes
[15:24] <durandal_1707> it use sdl
[15:24] <michaelni> burek, you might try to force SDL software rendering, this should circumvent hw limits
[15:25] <michaelni> theres a environment variable you can set for that, cant remember its name ATM though
[15:25] <burek> oh ok
[15:26] <burek> anyway, I just saw the guy is asking about mjpeg decoder specifically
[15:26] <burek> so, I stated the question incorrectly
[15:27] <burek> "I wish to use ffmpeg to play MJPEG stream on a video viewer. Wanted to know if there is any limit on resolution supported ? Is there any MAX Width and MAX Height ?"
[15:27] <burek> I guess he is asking about if mjpeg supports some maxw/maxh resolutions or there is no limit
[15:27] <burek> mjpeg decoder*
[15:30] <cone-559> ffmpeg.git 03Nicolas George 07483c1aa5f114: lavu/bprint: add av_bprint_get_buffer().
[15:30] <cone-559> ffmpeg.git 03Nicolas George 07805b57001f80: lavc/pngdec: decode textual data (tEXt and zTXt).
[15:33] <michaelni> there are 2 limits, one is due to 16bit width and height fields in JPEG and one due to indexing of samples with int
[15:33] <michaelni> you are unlikely to hit either limit in practice
[15:36] <burek> ok, thanks :)
[15:44] <nevcairiel> durandal_1707: you wrote the tak decoder, right? I have a file which says "unsupported codec: 0", any interest in fixing/implementing this? :)
[15:49] <durandal_1707> nevcairiel: not for free
[15:49] <Compn> lol
[15:50] <Compn> upload sample + make report, maybe someone will get to it
[15:50] <nevcairiel> i dont personally care, i just saw that it didnt work. Some developers take pride in their work and try to make it as good as possible, but shrug =p
[15:50] <nevcairiel> i got the report from one of my users, i'll direct him to trac instead then
[15:51] <Compn> lav filters eh ?
[15:51] <Compn> at least its name isnt exactly the same :P
[15:52] <nevcairiel> i had the name before the great fork, it has nothing to do with the other project =P
[15:52] <durandal_1707> codec 0 is soo old that i did not even bother to look how much work is to support it (it is like supporting older wavpacks,apes,musepacks and similar shit)
[15:52] <Compn> nevcairiel : i meant its not the same name as libavfilter  , i wasnt talking about the fork
[15:53] <Compn> kostya didnt seem interested in TAK either
[15:53] <Compn> tired of lossless audio codecs maybe?
[15:53] <nevcairiel> these days it sounds easier to just implement a new lossless decoder then bothering to implement an old one 0P
[15:55] <durandal_1707> nevcairiel: you have users?
[15:55] <nevcairiel> quite a lot of them these days
[15:56] <Compn> before microsoft gets rid of directshow ....
[15:56] <durandal_1707> nevcairiel: you are doing what?
[15:57] <nevcairiel> they already limited directshow a bit in windows 8, if you are writing a Metro application you cannot use it
[15:57] <nevcairiel> have to use their replacement, Media Foundation
[15:57] <nevcairiel> (which no-one supports)
[15:57] <Compn> are you going to support it? lol
[15:58] <ubitux> major_brand     : JUNK
[15:58] <JEEB> the Ut Video developer wrote a MF dec/enc filter the other day, released it with ver12
[15:58] <nevcairiel> durandal_1707: a directshow demuxer and audio/video decoders based on lavf/lavc
[15:58] <nevcairiel> Compn: if i ever get bored
[15:58] <ubitux> "JUNK" is an alias for "QT", right?
[15:58] <nevcairiel> MF is superior from its technological aspects
[15:58] <nevcairiel> its just .. no player uses it
[15:58] <nevcairiel> so why write stuff for it
[15:58] <nevcairiel> chicken/egg problem =p
[15:59] <durandal_1707> nevcairiel: there is directshow plugin for tak that supports codec 0
[15:59] <nevcairiel> i know, but people prefer to use one decoder to play everything, and not go install 100 different things
[16:01] <Compn> plus those bastards started offering codec pack full of malware in them
[16:01] <Compn> so idiot users cant just install them willy nilly anymore
[16:15] <burek> that's good
[16:15] <burek> it will lower the number of idiot users and raise their intelligence :)
[16:19] <gnafu> Survival of the fittest!
[16:24] <ubitux> don't forget idiocracy :p
[16:59] <Garf> commit 915a2a0a656518ab50fe28754f9016772c835c8c
[16:59] <Garf> Author: Diego Biurrun <diego at biurrun.de>
[16:59] <Garf> this broke mingw64 crosscompiling
[16:59] <Garf> libavcodec/x86/dsputil_mmx.o:dsputil_mmx.c:(.text+0x3c52): undefined reference to `_ff_avg_h264_qpel8_mc33_10_mmxext'
[17:01] <Garf> well, crosscompiling with --disable-everything
[17:09] <Daemon404> Garf, that sounds like it might be broken while compiling normally too
[17:09] <Garf> Daemon404: I thought so, but no.
[17:10] <Garf> I don't see anything mingw specific in the patch.
[17:10] <Garf> So I'm a bit puzzled
[17:10] <Daemon404> wait what
[17:10] <Daemon404> that was pushed in march
[17:10] <nevcairiel> fate didnt complain
[17:10] <Daemon404> and i sure have been cross compiling fine
[17:10] <Garf> a native mingw compile (not crosscompile) fails here; +YASM-OBJS-$(CONFIG_H264QPEL)           += x86/h264_qpel_10bit.o
[17:10] <Daemon404> for months and months
[17:11] <Daemon404> native has worked for months and months too
[17:11] <Garf> yes, but you probably have H264 enabled
[17:11] <Daemon404> since it was pushed all back in march
[17:11] <Daemon404> i have one build with only mpeg12
[17:12] <Daemon404> i want to test, but all my mingw boxes went down in the hurricane...
[17:12] <Daemon404> boo-urns
[17:12] <Garf> ./configure --cross-prefix=i686-w64-mingw32- --disable-everything --enable-decoder=aac --enable-shared --disable-swscale --disable-network --disable-avdevice --disable-swscale --disable-avprobe  --disable-avfilter --target-os=mingw32 --arch=x86 --disable-debug --enable-runtime-cpudetect
[17:12] <Garf> this works if I back out that patch
[17:12] <Daemon404> you dont need all those extra disables btw
[17:12] <Daemon404> disable everything does what it says
[17:13] <Daemon404> unless im mistaken...
[17:13] <Daemon404> (it might just disable all features)
[17:14] <Garf> it disables the features, those extra disables are needed to not get those libs
[17:19] <nevcairiel> works just fine for me on git master
[17:20] <nevcairiel> are you sure you're on the right project? disable-avprobe isnt even an option =p
[17:20] <Garf> well I'm on libav itself
[17:20] <Garf> ffmpeg has similar problems
[17:20] <nevcairiel> then you shouldnt ask here :p
[17:20] <nevcairiel> i just build git master with your command line, after removing --disable-avprobe
[17:20] <nevcairiel> works fine
[17:21] <Garf> libav doesn't have a seperate channel (at least not according to the docs)
[17:21] <Daemon404> yes it does
[17:22] <Garf> http://pastebin.com/3rudsPeX  <- that fixes it, but doesn't make much sense to me
[17:22] <Compn> Garf : its #libav 
[17:22] <iive> Garf: what (similar) problems does ffmpeg have?
[17:22] <Compn> or #libav-devel if you have a patch or other devel question
[17:22] <Garf> it fails in the same manner, iirc
[17:22] <Garf> anyway, I'll ask there if anyone has a clue what's up
[17:23] <Garf> nevcairiel: on mingw?
[17:23] <nevcairiel> yes
[17:23] <iive> but nevcairiel just said it doesn't . So likely the problem is fixed in ffmpeg repository.
[17:23] <Compn> Garf : do you have mingw-w64 installed or just regular mingw ?
[17:23] <iive> what version of ffmpeg have you tried?
[17:24] <Garf> Compn: mingw-w64
[17:24] <Garf> iive: git 
[17:24] <Daemon404> sec i just installed mingw-w64
[17:25] <Daemon404> reproduced
[17:25] <nevcairiel> so why does mine build just fine then? =P
[17:26] <Daemon404> i repro'd it on libav
[17:26] <Daemon404> trying ffmpeg now
[17:26] <Daemon404> inb4 hidden change in merge commit
[17:27] <Daemon404> yes ffmpeg is fine
[17:27] <Garf> hmm, let me check that again
[17:27] <Garf> maybe it reveals what's up with libav
[17:29] <Garf> the relevant makefile is identical
[17:29] <nevcairiel> the function is probably just not referenced in cases when its not built
[17:30] <Compn> is libav's mingw fate say its not working ?
[17:30] <Daemon404> you know what time it is?
[17:30] <Daemon404> git bisect time
[17:30] <nevcairiel> Compn: no fate box with h264 disabled
[17:30] <nevcairiel> because, who does that =p
[17:30] <Daemon404> to find where it got fixed
[17:30] <Daemon404> bahaa
[17:30] <Daemon404> (ill do it)
[17:31] <Compn> lol
[17:31] <Compn> who knows
[17:31] <Compn> Garf : why are you compiling this atrocity ?
[17:31] <nevcairiel> obviously, he only wants an aac decoder
[17:31] <Compn> doesnt --disable-everything also --disable-swscale ?
[17:33] <Daemon404> Compn, please read first
[17:33] <Daemon404> before saying things we'eve already discussed
[17:33] <Daemon404> <_<
[17:34] <Compn> derp derp derp
[17:34] <Garf> Hmm, I thought ffmpeg just used libavcodec, but a collegue just informed me that's almost a holy war subject
[17:34] <Garf> So I'm definitely complaining in the wrong channel :P
[17:35] <Compn> holy war :D
[17:35] <Compn> libav is a fork
[17:35] <Compn> so both projects work on it ...
[17:36] <Garf> ha, I think I found something
[17:37] <Garf> `_ff_put_h264_qpel8_mc00_10_mmxext'
[17:37] <Garf> is missing
[17:37] <Compn> the holy grail?
[17:37] <Garf>         } else if (bit_depth == 10) {
[17:37] <Garf> #if HAVE_YASM
[17:37] <Garf> #if !ARCH_X86_64
[17:37] <Garf>             SET_QPEL_FUNCS(avg_h264_qpel, 0, 16, 10_mmxext, ff_);
[17:38] <Garf> this explains why my local compile works -> that's 64-bit
[17:38] <durandal_1707> why i get no video packets when using -c copy?
[17:38] <Compn> is that one of those mmxext diego renamed ?
[17:38] <Daemon404> thats not relevant, Compn 
[17:38] <Compn> bah
[17:39] <Daemon404> 64-bit always has mmxext/mmx2, and i guess it forgot to check for it actually being enabled
[17:39] Action: Compn keeps guessing until Daemon404 gives up
[17:40] <Daemon404> ffmpeg is the same though.
[17:40] <nevcairiel> there is a big if(CONFIG_H264QPEL) above that, though
[17:40] <Daemon404> yes
[17:40] <Daemon404> thats why im confused
[17:41] <nevcairiel> libav might be setting it accidentally?
[17:42] <Daemon404> maybe
[17:42] <Daemon404> config.h:#define CONFIG_H264QPEL 0
[17:43] <Garf> #if CONFIG_H264QPEL && ARCH_X86_32 && HAVE_YASM // ARCH_X86_64 implies sse2+
[17:43] <Garf> QPEL16(mmxext)
[17:43] <Garf> #endif
[17:43] <Garf> so
[17:43] <Garf> libavcodec doesn't have that line
[17:43] <Garf> libav
[17:44] <Garf> but it does define CONFIG_H264QPEL off
[17:44] <Compn> haha, someone confused the names. i knew it would happen :)
[17:44] <Daemon404> daemon404 at bbvm:~/dev/l/libav$ diff -ur libavcodec/x86/dsputil_mmx.c ../../f/ffmpeg/libavcodec/x86/dsputil_mmx.c | diffstat
[17:44] <Daemon404>  dsputil_mmx.c |  286 ++++++++++++++++++++++++++++++++++++++++++++++++----------
[17:44] <Daemon404>  1 file changed, 241 insertions(+), 45 deletions(-)
[17:44] <Daemon404> so messy
[17:44] <nevcairiel> a lot of that is probably the dirac dsp things?
[17:45] <Daemon404> some is random inline asm
[17:45] <Garf> got it
[17:45] <Garf> the above is ffmpeg
[17:45] <Garf> this is libav:
[17:45] <Garf> #if ARCH_X86_32 && HAVE_YASM // ARCH_X86_64 implies sse2+
[17:45] <Garf> QPEL16(mmxext)
[17:45] <Garf> #endif
[17:45] <Garf> sounds like I can make a trivial patch
[17:45] <Daemon404> git blame
[17:45] <Daemon404> git format-patch
[17:45] <Daemon404> git send-email
[17:46] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commit;f=libavcodec/x86/h264_qpel.c;h=001d9d5e9320d95e967c8bebea6cc88acf7f6526
[17:46] <nevcairiel> wasnt fixed in a merge commit
[17:46] <nevcairiel> =P
[17:47] <Compn> good ole carl :)
[17:47] <Daemon404> a very useless commit message though
[17:47] <Daemon404> "fix bug
[17:47] <Compn> what
[17:47] <Compn> maybe
[17:47] <Daemon404> it completely lacks any description og whats beign fixed
[17:47] <Compn> standard ffmpeg commit message tho
[17:47] <Daemon404> yes
[17:47] <nevcairiel> why is that file compiled at all without qpel, i wonder
[17:47] <Daemon404> aka shit
[17:47] <Compn> 'fix --xxxyyy'
[17:48] <Daemon404> nevcairiel, i find it best not to ask that
[17:48] <Daemon404> because it's always a horrible reason
[17:48] <Daemon404> that makes me cry
[17:48] <Compn> we have a fatebox on --disable--everything dont we ?
[17:49] <nevcairiel> if we do, it doesnt mention that in its comment
[17:49] <cone-559> ffmpeg.git 03Paul B Mahol 07c39fb3081620: smjpegdec: set nb_frames for video stream
[17:49] <Compn> maybe i'm thinking --disable-optimizations ?
[17:49] <nevcairiel> that we have
[17:50] <Compn> wonder how fast compilation is with --disable-everything
[17:50] <Compn> ehe
[17:50] <Daemon404> configure takes longer than compilation for me with any config
[17:50] <nevcairiel> still builds the essentials, so fast, but not instant
[17:50] <Compn> Daemon404 : are you going to multi-thread it ?
[17:50] <Compn> or is it already? hmm
[17:50] <nevcairiel> mingw configure seems faster then the actual build
[17:51] <Daemon404> multithreaded configure is a needless layer of complexity for no gain
[17:51] <Daemon404> and a stupid idea
[17:51] <Compn> mingw configure is terrible due to sh or whatnot
[17:51] Action: Compn takes his stupid ideas and goes home then
[17:52] <durandal_1707> configure is terrible idea use make directly
[17:52] <Compn> one big bat file of make
[17:53] <Garf> nevcairiel: thx. just pasted that on libav-devel, I hope they can take it :)
[17:53] <Compn> a patch from carl on libav ? hmm
[17:53] <iive> Garf: as long as you don't mention where does the fix comes from :P
[17:53] Action: Compn can hear the holy war now
[17:53] Action: Compn beats the drums
[17:55] <durandal_1707> decode in AVCodec should be documented
[18:12] <kierank> durandal_1707: do you not understand how to make measurements with repeat readings?
[18:13] <durandal_1707> kierank: what are you talking about?
[18:14] <kierank> "Why you need to rereun all the time? "
[18:14] <durandal_1707> so?
[18:15] <kierank> i don't understand this comment you make
[18:35] <ubitux> haha diego just stole the patch
[18:43] <durandal_1707> NIH syndrom
[18:54] <Daemon404> durandal_1707, http://forum.doom9.org/showpost.php?p=1598804&postcount=12773
[18:55] <nevcairiel> i already tried that, he didn't care
[18:55] <Daemon404> very classy
[18:55] <nevcairiel> apparently, that particular encoding mode in that file is very old
[18:55] <durandal_1707> i care
[18:57] <nevcairiel> "not for free" is not a very caring comment, imho =p
[18:57] <durandal_1707> i don't care that you care what i care or not care
[18:57] <Compn> Daemon404 : so you like diegos commit message on that patch (carls patch to fix --disable-everything) ?
[18:57] <Compn> Daemon404 : http://lists.libav.org/pipermail/libav-devel/2012-November/038804.html
[18:58] <Daemon404> no
[18:58] <Compn> i guess i mean the subject , not the commit message
[18:58] <Compn> "x86: h264qpel: Only define mmxext QPEL functions if H264QPEL is enabled"
[19:00] <Compn> i ask because i dont know what you are looking for in a commit message
[19:00] <Compn> i'm trying to get a better idea of what a good message looks like...
[19:00] <Compn> i'm not just trolling all of the time :P
[19:03] <Daemon404> he didnt mention that it was 32-bit specific
[19:12] <ubitux> <@durandal_1707> NIH syndrom // well, in that particular case, it's a bit rude
[19:13] <ubitux> he got the link to the patch, did the same and just put the condition in a different order for the sake of changing it :p
[19:13] <ubitux> (and get full authorship)
[19:17] <durandal_1707> it is NIH syndrom. it can't be cured
[19:18] <Compn> ubitux : how else are you supposed to be top comitter if you dont rearrange to get full authorship of it ? :P
[19:19] <durandal_1707> what will happen if i start doing same thing, takeing patches from libav and taking full authorship? would libav just ignore that?
[19:20] <durandal_1707> because there are some patches rotting and not committed
[19:20] <iive> durandal_1707: only one way to find out :)
[19:20] <Compn> libav has been doing it for a while. few cherry picks here and there
[19:46] <ubitux> Compn: it's fine to take authorship on the commit when the code "changes", but in that case, the bug was found and fixed by the original author, so at least some small recognition (signed of/based on work by/whatever) wouldn't hurt
[19:47] <ubitux> the fun part is that the person stealing credits is the author of the regression, and strangely forget to mention it in the commit :)
[19:47] <ubitux> but well, whatever, i'm nitpicking for something that doesn't concern me directly
[20:37] <ubitux> oups sorry michaelni (and carl who is likely reading irc logs), i completely misreplied in the qt-junk-patch-thing
[20:41] <michaelni> i realized :)
[20:41] <michaelni> i was thinking that maybe we should have a qt and a isom flag and seperate set them
[20:42] <michaelni> that is qt=1 when its in the list and isom when its in the list
[20:53] <cone-698> ffmpeg.git 03Paul B Mahol 0777d89a5b1601: apedec: consume packet after it has been fully decoded
[22:54] <cone-698> ffmpeg.git 03Heesuk Jung 0725b7aa980bb8: Fix bit_rate in MPEG1/2 Video
[23:16] <cone-698> ffmpeg.git 03Paul B Mahol 07f58f600c6899: lclenc: make compression level user selectable
[23:49] <michaelni> hi saste
[23:49] <michaelni> did you had time to look at the coverity issues in xfacenc and ffprobe ?
[23:50] <michaelni> iive, btw do you want to help with fixing coverity issues ? :)
[23:50] <saste> not yet
[23:50] <iive> michaelni: no
[23:51] <michaelni> iive, thats a harsh and unfriendly awnser
[23:51] <iive> i try to stay away from .gov domains.
[23:52] <michaelni> its .com
[23:52] <iive> hum... wasn't it under dhs or something?
[23:55] <michaelni> iive i dont know these politics
[23:56] <iive> well, security is not my thing.
[23:58] <iive> I would never close a issue as "false positive" in fear I may be missing something.
[23:58] <ohsix> if you've written code it sort of is :p
[23:59] <michaelni> few of the issues found are security relevant its mostly normal bugs and false positives
[00:00] --- Sat Nov  3 2012