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

[burek]

[00:04] <beastd> saste: yes. i guess most people try to achieve things as fast as possible without having to dive in deep.
[00:07] <cone-390> ffmpeg.git 03Michael Niedermayer 071f1960519a17: lxfdec: fix "no audio stream" check. avoid null ptrs deref
[00:07] <cone-390> ffmpeg.git 03Michael Niedermayer 072f74f8d7dce2: imc: sanity check scalefactors.
[00:07] <beastd> saste: i just saw you posted swscale doc patch. will try to read it tomorrow.
[00:07] <saste> beastd, thanks
[00:07] Action: beastd is going to bed now
[00:07] <beastd> bye...
[00:43] <ubitux> seems Ronald is fed up with Diego pushing the cabac test drop haha
[00:44] <ubitux> "i give up"
[00:45] <ubitux> saste: anything else you need me to review while i'm at it?
[00:45] <saste> ubitux, no, i'm being lazy
[00:45] <ubitux> lazy to ask me to review?
[00:45] <ubitux> @_@
[00:45] <saste> no lazy to post patches
[00:46] <saste> nice work with geq
[00:46] <saste> now I'm waiting for geqrgb
[00:49] <ubitux> i'm not working on it :)
[00:49] <ubitux> i'm trying to write a brand new awesome filter these days
[00:49] <ubitux> and i'm wondering about porting some other mp filters
[00:50] <ubitux> &and my subtitles todo entry are swearing at me
[00:50] <ubitux> entries*
[00:50] <ubitux> but since no one is reviewing my subtitles patches i have an excuse :-°
[00:51] <saste> i could review them but i'm a n00b when it comes to subtitles
[00:51] <saste> (random excuse #123)
[00:51] <ubitux> :D
[00:53] <burek> guys, are you interested that we buy ffmp.eg domain
[00:53] <ubitux> saste: so what's the next awesomeness you're going to submit?
[00:53] <burek> to setup our own pastebin and url shortener
[00:53] <ubitux> ok with me if you don't ask me to pay anything
[00:53] <ubitux> ;)
[00:54] <Compn> what country is it ?
[00:54] <Compn> i dont support facist regimes 
[00:54] <burek> it's 20$ annualy :) i think we can afford that :)
[00:54] <burek> egypt
[00:54] <Compn> ...
[00:55] <burek> you should the best about fascist regimes :) you live in usa :)
[00:55] <burek> should know*
[00:55] <ubitux> :D
[00:57] <burek> you eat gmo food, have the obesity as a normal condition, fluoride in your water (for whiter teeth, right? just like jews in nazzi camps had, I wonder if there's any connection between those two) :) and of course, you don't even have your own state controled currency :) the private bank is printing it for you, to which you pay interest :)
[00:57] <burek> so much about that :)
[00:58] <gnafu> Hehe, fluoridation in the water, and ice cream...  /Children's/ ice cream.
[00:58] <gnafu> I will not let them sap and impurify my precious bodily fluids!
[00:58] <saste> US politics is a mess, but where is so much better?
[00:59] <saste> northern europe may be an option, but the weather sucks there
[00:59] <ubitux> i heard they have some nice weather in usa lately too
[01:00] <burek> :D
[01:01] <saste> ubitux, i'll try to review nicolas patches tomorrow, bye for now
[01:01] <ubitux> dja na~
[02:06] <cone-390> ffmpeg.git 03Michael Niedermayer 079406d6be55db: ffmpeg: fix audio timestamps on stream copy with -ss
[02:22] <wm4> why doesn't ffmpeg set preprocessor macros for newly added features, instead of forcing application developers to do version checks?
[02:30] <iive> like?
[02:33] <cone-390> ffmpeg.git 03Georg Lippitsch 0715b02ddee033: Update iec61883 to handle multiple devices, and allow selection of DV device by its GUID
[02:33] <cone-390> ffmpeg.git 03Michael Niedermayer 079f088712d454: ffmpeg: fix double ;;
[02:33] <cone-390> ffmpeg.git 03Michael Niedermayer 07b61658829b2f: Merge remote-tracking branch 'lippit/master'
[02:36] <wm4> iive: e.g. the planar audio change could have added a symbol that indicates the requirement to support these, as well as the presence of API functions specific to planar audio
[02:55] <iive> wm4: aha, something like the CONFIG_SOMETHING. It is actually nice idea.
[03:43] <cone-390> ffmpeg.git 03Michael Niedermayer 0739c5cd601ef0: vmnc: check input size before reading chunk header, fix overread
[03:43] <cone-390> ffmpeg.git 03Michael Niedermayer 07e1631f8ebe9a: aasc: check before reading the first 4 byte, fix overread
[03:43] <cone-390> ffmpeg.git 03Michael Niedermayer 077acee6654ccd: mpeg12data: increase size of ff_mpeg1_default_intra_matrix to prevent harmless overreads from crashing
[03:43] <cone-390> ffmpeg.git 03Michael Niedermayer 0766ff90f4a3d8: 8bps: check index against buffer size before reading line length pointer.
[07:37] <ubitux> michaelni: thank you sooo much for 9406d6be5 :)
[09:25] <ubitux> oh that's awesome we can starts ffmpeg automatically in ffserver with the configuration
[09:25] <ubitux> start*
[10:10] <ubitux> commit bot is down again :(
[10:11] <cone-677> ffmpeg.git 03Clément BSsch 07a9ba9268d7f7: ffserver: prefer av_asprintf over malloc+snprintf for Launch setting.
[10:11] <cone-677> ffmpeg.git 03Clément BSsch 0726afdbcfc0ec: ffserver: fix NULL dereference with quoted Stream name.
[10:11] <ubitux> \o/
[10:11] <ubitux> anyone to have a look to the two ffserver patches?
[12:11] <cone-677> ffmpeg.git 03Luca Barbato 0722a0827dff29: hlsenc: stand alone hls segmenter
[12:11] <cone-677> ffmpeg.git 03Luca Barbato 07c1a02e884ac7: pixdesc: add av_pix_fmt_get_chroma_sub_sample
[12:11] <cone-677> ffmpeg.git 03Luca Barbato 07cc085993f42c: avcodec: remove ff_is_hwaccel_pix_fmt
[12:11] <cone-677> ffmpeg.git 03Luca Barbato 0783f9ed42ec69: libtheoraenc: add missing pixdesc.h header
[12:11] <cone-677> ffmpeg.git 03Diego Biurrun 075e9c6ef8f3be: x86: h264_weight_10bit: port to cpuflags
[12:11] <cone-677> ffmpeg.git 03Michael Niedermayer 07e13d5e9a4b5b: Merge commit '5e9c6ef8f3beb9ed7b271654a82349ac90fe43f2'
[12:11] <cone-677> ffmpeg.git 03Michael Niedermayer 07d4e74d5d6d67: Remove deprecation of avcodec_get_chroma_sub_sample.
[12:31] <cone-677> ffmpeg.git 03Diego Biurrun 07da39cac8def7: Drop broken and unused CABAC test program.
[12:31] <cone-677> ffmpeg.git 03Michael Niedermayer 07b0c543b1deba: Merge commit 'da39cac8def7ea73cad2fa2b611209663c7abe2c'
[12:49] <cone-677> ffmpeg.git 03Diego Biurrun 0726301caaa1ae: x86: mmx2 ---> mmxext in asm constructs
[12:49] <cone-677> ffmpeg.git 03Michael Niedermayer 07a1b5c9634e87: Merge remote-tracking branch 'qatar/master'
[16:46] <burek> can someone resolve this mistery please: http://ffmpeg.gusari.org/viewtopic.php?p=1183
[16:46] <burek> im not that good with huffyuv
[16:51] <michaelni> burek, can you explain the "mistery" ?
[16:58] <iive> burek: the bpp in avi files is completely arbitrary.
[16:59] <iive> for example yuv420/yv12 is actually 12bit 
[17:00] <iive> and this is the internal format for all broadcast video. it have 8 bits for luma channel and 2 channels at quarter resolution, so 8+8/4+8/4.
[17:01] <iive> you are using huff YUV, so this kind of implies that you are not using rgb.
[17:02] <iive> ... 2 chroma channels at quarter resolution...
[17:13] <iive> usually the avi bmp header is filled with the corresponding value for getting the same quality in rgb. this explains the different bpp readings.
[17:14] <iive> I think the mystery is why converting 422 huffyuv to 422 huffyuv becomes 1.5 times bigger.
[17:18] <JEEB> prediction mode?
[17:20] <ubitux> http://msdn.microsoft.com/en-us/library/1b3fsfxw%28v=vs.80%29.aspx i need this in gcc o_o
[17:22] <ubitux> http://en.chys.info/2010/07/counterpart-of-assume-in-gcc/ mmh...
[17:25] Action: ubitux wants to add av_assume()
[17:33] <nevcairiel> i thought gcc had something similar
[17:40] <cone-677> ffmpeg.git 03Michael Niedermayer 0787d073eaccc0: mov: Dont try to calculate with unknown durations, fix division by 0
[17:40] <cone-677> ffmpeg.git 03Michael Niedermayer 07ccce723c6d0e: vc1dec: check first field slices, fix out of array read.
[17:40] <Daemon404> regardless
[17:40] <Daemon404> it's horrible and ugly
[17:40] <Daemon404> and pseudo-micro-optimization :>
[17:42] <Compn> pointless micro optimization?!
[17:42] <Compn> sounds like something we need !
[17:43] <nevcairiel> i dunno, i like the concept of flagging branches as impossible to happen. Especially wrapping it into asserts. If you asserted something, you can assume it is that way afterwards. In a release build, the assert goes away, but the assumption can stay
[17:43] <Daemon404> asserts != assume
[17:44] <Daemon404> btw nevcairiel my custom get buffer failed miserably :D
[17:44] <michaelni> nevcairiel, sounds interresting
[17:44] <Daemon404> i think its due to the hacky was mpeg*c store MV info in teh spaces between frames in alloced buffers...
[17:45] <nevcairiel> seriously?
[17:45] <Daemon404> thats the explanation i got the teh existence of frame->base[i]
[17:46] <ubitux> the assume thing is pretty nice to give some kind of hint to the compiler like f(int x) { assume(x > 0 && x < 10); ... }  yepee compiler might do a lot of things
[17:46] <nevcairiel> well, i only know that my implementation randomly crashed on multi-threaded decoding, and at the time i didnt have msvc builds yet to figure it out
[17:46] <Daemon404> i see
[17:46] <Daemon404> im using 1 trhead (Default)
[17:46] <Daemon404> it crashing inside the mpeg2video decoder
[17:46] <Daemon404> in MV stuff
[17:47] <nevcairiel> but then i didnt use a custom implementation, i just wanted to control the life-time of the buffer because i was trying to avoid memcpys with yadif on another thread and the likes
[17:47] <Daemon404> yeah im trying to use it to direct render into vapoursynth's buffers
[17:47] <Daemon404> theyre guaranteed to be 32-aligned
[17:47] <Daemon404> so i thought id be ok
[17:49] <ubitux> nevcairiel, Daemon404: is there a hope for you guys to add at some point a shared msvc box?
[17:49] <michaelni> "Daemon404> i think its due to the hacky was mpeg*c store MV info in teh spaces between frames in alloced buffers..." <---- sounds creepy, and sounds like you know really well how the code works
[17:49] <michaelni> ;)
[17:49] <ubitux> nevcairiel, Daemon404: btw, any 64-bit?
[17:50] <Daemon404> ubitux, i HAVE a shared msvc box
[17:50] <Daemon404> but its still out due to hurricane sandy
[17:50] <Daemon404> :>
[17:50] <nevcairiel> not in ffmpeg, it was broken until a few days ago, didnt even compile
[17:50] <Daemon404> michaelni, nah... i asked others
[17:51] <ubitux> nevcairiel: yes but it should be fixed now, that's why i'm asking
[17:51] <nevcairiel> also, http://fate.ffmpeg.org/history.cgi?slot=x86_64-msvc10-windows-native
[17:51] <nevcairiel> 64 bit ^
[17:51] <Daemon404> kshishkov explained something abotu edges/mvs etc
[17:51] <nevcairiel> i can enable a shared build, lets see
[17:51] <michaelni> Daemon404, you probably need to setr CODEC_FLAG_EMU_EDGE
[17:52] <michaelni> and forget about MV info between mysterious spaces in paralell dimensions :)
[17:52] <Daemon404> michaelni, that doesnt seem liek something i set inside get_buffer
[17:52] <Daemon404> i tried reading avcodec_default_get_buffer's video counterpart but it's full of arcane magic
[17:52] <ubitux> nevcairiel: oh the os column was marked as win32, my bad
[17:52] <Daemon404> and internal-only things
[17:53] <nevcairiel> ubitux: thats the auto-detected value, i could add --target-os=win64, but really, same difference
[17:53] <michaelni> CODEC_FLAG_EMU_EDGE could be set when you set the get_buffer callback
[17:53] <ubitux> nevcairiel: no worry, it's not important
[17:53] <nevcairiel> doesnt matter for the builds, its just visual
[17:53] <Daemon404> ill dig out my get_buffer impl later tonight and pastebin it
[17:53] <Daemon404> i dont have it with me at work
[18:04] <nevcairiel> ubitux: http://fate.ffmpeg.org/report.cgi?time=20121114170229&slot=x86_32-msvc10-dll-windows-native
[18:05] <Daemon404> %3a
[18:05] <Daemon404> very classy
[18:05] <nevcairiel> its just a display problem on the fate website
[18:05] <nevcairiel> luckily :p
[18:05] <Daemon404> olol
[18:15] <nevcairiel> the : has already caused too many problems
[18:30] <ubitux> nevcairiel: thx! :)
[18:56] <ubitux> "// minor note: the HAVE_xyz is messed up after that line so do not use it."  but they are used several times in the next lines :(
[19:04] <cone-677> ffmpeg.git 03Paul B Mahol 07dbc44667ce3d: Add missing dependency for avr demuxer
[19:20] <Daemon404> ubitux, dont worry, it's only a minor note.
[19:20] <Daemon404> not a major one.
[19:21] <ubitux> :)
[19:28] <cone-677> ffmpeg.git 03Michael Niedermayer 07ab8517b89196: vc1dec: require a minimum of 2x2 for the edge pos. Avoid assertion failure
[19:28] <cone-677> ffmpeg.git 03Michael Niedermayer 0730bce34b6719: vpriv_adx_decode_header: avoid underreading the array.
[19:37] <michaelni> it should work as its outside CONFIG_RUNTIME_CPUDETECT but they can probably be replace by COMPILE_*
[19:42] <ubitux> i'm trying to rework this
[19:43] <ubitux> any idea how i should different compilation then?
[19:43] <ubitux> at least, do we have an altivec fate instance?
[19:43] <ubitux> and/or a 3dnow?
[19:44] <ubitux> well the 3dnow the build can be tested easily with the runtime cpudetect thing
[19:47] <michaelni> theres a 3dnow box
[19:48] <michaelni> using COMPILE should work as its outside RUNTIME_CPUDETECT (there will be just 1 of the compiles enabled)
[19:48] <michaelni> but one could also leave it as is and just improve the comment
[19:49] <michaelni> note, i do not know how much of the pp code the 3dnow box tests as some of this is not bitexact
[19:50] <michaelni> this of course could be improved and fuzzy testing be added
[19:50] <ubitux> i'm changing this stuff, hopefully in the right direction
[19:51] <ubitux> i've an idea to make this stuff more obvious, i'll see if it works soon
[20:28] <dbro> Hey all! I'm porting the muxing example to Android for live A/V encoding. My AVPackets have identical pts, dts, duration as the original example, but the audio timing in the output file is all wrong. Thanks in advance for helping a FOSS brother out
[20:28] <dbro> my output: http://dbro.pro/public/ffmpeg/ffmpeg_error_example.mp4 
[20:29] <dbro> apologies for the off-topic. Just figure knowledgeable ones are here
[21:33] <burek> iive, thanks for the explanation :)
[21:34] <burek> i'll copy your explanation verbatim on the forum
[21:34] <burek> because i dont understand 2 words of what you said :)
[21:40] <Compn> dbro : stick around and ask again later, its just not busy time on irc at the moment :)
[21:45] <michaelni> dbro, if the same code works "differently" on android, add printfs/av_logs and diff the output you get relative to a x86 
[21:46] <michaelni> dbro, OTOH if the code is not the same, what is different ?
[21:47] <dbro> Compn: aye, will do
[21:48] <dbro> michaelni: Instead of filling the AVFrame with dummy A/V, I'm using the device camera / mic data
[21:50] <dbro> other than that I've just segmented the muxinc example's main() function into 3 functions: initialize, encodeFrame, and finalize
[21:54] <dbro> with each encodeFrame call I shuttle in one frame of video and audio. Yet the output isn't in sync even if I ensure AVPackets have identical pts, dts, and duration.
[21:57] <michaelni> dbro, your output file contains 3 times more video than audio
[21:59] <michaelni> dbro, is teh mic recording at 44.1khz ?
[21:59] <dbro> michaelni: Yeah, and I get the audio frame size from the AVStream->AVCodecContext->frame size
[22:01] <dbro> maybe my assumption of one frame of video corresponding to one frame of audio is the problem
[22:05] <michaelni> dbro, there is no such correspondece at 15fps, 44.1khz and 1024  sample audio frames
[22:08] <ubitux> meh the mmx version is faster than the sse :(
[22:09] <Skyler_> on which CPU, for which function?
[22:09] <dbro> michaelni: right, thanks! I'll try to instead asynchronously send audio and video frames and hope it works out 
[22:10] <ubitux> Skyler_: an i7 first gen, and you're not gonna like the code: http://pastie.org/5379110
[22:11] <ubitux> COMPILE_SSE2 block is slower
[22:11] <dbro> michaelni: how did you determine the video/audio content ratio.
[22:15] <Skyler_> Okay, I'd start by suggesting you use movq, move to 4 separate registers, and punpcklbw them
[22:15] <Skyler_> Oh, I see, you need to do the pavgb...
[22:15] <Skyler_> Hmm
[22:15] <Skyler_> 4x movq, 2x pavgb, 2x punpck, might work bett rthan what you're currently oding.
[22:16] <Skyler_> you should probably use pxor instead of xorps, since mixing float and int instructions can be bad
[22:16] <Skyler_> same with movq vs movlps
[22:16] <Skyler_> movlps doesn't overwrite the top half of the register, so it creates a false dependency.
[22:16] <Skyler_> If you really need to do movlps + movhps, do movq + movhps instead.
[22:17] <Skyler_> if it's possible you miht do better by unrolling it a bit more too?
[22:17] <Skyler_> *might
[22:18] <ubitux> ok so one thing at a time: why should i prefer the movq/pavgb instead of the mov[lh]ps and stuff?
[22:19] <ubitux> oh didn't read you entirely, sorry
[22:20] <ubitux> what is this dependency thing? does it add some kind of "read-only" constraint in the top half?
[22:20] <ubitux> (sorry if this is obvious, it's the first time i'm writing such asm :p)
[22:24] <Skyler_> okay, let's start one at a time then
[22:24] <Skyler_> movlps modifies the low half, but keeps the top half the same.
[22:24] <Skyler_> This means that it cannot be executed until the top half of the register is known.
[22:24] <Skyler_> This is a false dependency, because in reality, you're going to throw away the top with movhps in the next instruction.
[22:24] <Skyler_> So the CPU will stall until that top half is known from the previous iteration, even though it doesn't need to.
[22:24] <Skyler_> movq *doesn't* keep the top half, so there's no such dependency.
[22:25] <ubitux> oh, ok fun
[22:26] <Skyler_> The next part is, you might be better off doing 4 loads to separate registers, 2 pavgb, and then 2 punpcklbw, instead of 4 loads to 2 registers, 1 pavgb, and the movdqa+punpck+punpck.  I don't know, you'll have to bench it.
[22:26] <Skyler_> It might be better dependency-wise.
[22:28] <ubitux> ok, thanks, i'll try this
[22:28] <ubitux> but first i really need to change something in pp to ease the tests
[22:28] <ubitux> michaelni: do you mind if i use av_get_cpu_flags() instead of the cpuCaps?
[22:33] <ubitux> (in pp)
[22:49] <michaelni> ubitux, sure use  av_get_cpu_flags() or replace cpuCaps by it
[22:51] <ubitux> great, thanks
[22:52] <ubitux> do we need to keep compat with the old cpu flag forcing or we can just drop it completely?
[22:52] <ubitux> (and rely on the flag force api)
[22:52] <ubitux> old cpy flag forcing ’ pp cpu flags
[23:01] <michaelni> ubitux, dunno
[23:04] <ubitux> erm it seems abused for pixel format&
[23:06] <michaelni> its used as general purpose flags
[23:16] <ubitux> erh i guess i'll have to port vf pp&
[23:54] <cone-417> ffmpeg.git 03Michael Niedermayer 0750f0a6b4e64b: wmaprodec: check num_sfb for validity. Fix out of array accesses
[23:54] <cone-417> ffmpeg.git 03Michael Niedermayer 07612ecfbbbb3f: gifdec: check ff_lzw_decode_init() return value, fix out of array reads
[23:54] <cone-417> ffmpeg.git 03Michael Niedermayer 07e70144cba13d: bink: check quant_index, fix out of array read
[23:58] <ubitux> michaelni: how much j00ru left? :)
[23:58] <ubitux> do you get more of them regularly?
[23:59] <ubitux> - git log --grep j00ru --pretty=oneline| wc -l
[23:59] <ubitux> 483
[23:59] <ubitux> fear.
[00:00] --- Thu Nov 15 2012