[00:05] <ubitux> < michaelni> ubitux, add 128 to each byte, do a shift, mask and subtract 16 from each byte [00:05] <ubitux> i still don't get the trick [00:05] <ubitux> what are you masking? [00:06] <michaelni> that stuff that a 8bit shift would have removed [00:06] <michaelni> shift + mask == 8bit unsiged shift [00:06] <ubitux> i think i understand the unsigned shift one; you just mask out the 3 bits before doing a whole shift so they don't reach the next byte [00:07] <ubitux> mmh.. [00:08] <ubitux> but you do that after the shift? [00:08] <ubitux> meh, i'm confused [00:16] <ubitux> michaelni: http://pastie.org/pastes/8581295/text [00:16] <ubitux> so what now? [00:16] <ubitux> (top down exec, top is the input, left is the action [00:16] <ubitux> ) [01:17] <michaelni> ubitux, was afk, but in>>3 == ((in+128)>>3)-16 [01:19] <michaelni> ubitux, in that pastie it looks like your right shift does 11101010 -> 01111101, that doesnzt look like a right shift of 3 [01:22] <michaelni> or if that was supposed to be just the 64bit shift result, you need a pand after that to clear off the bits that a 8bit shift would have removed [02:57] <kgp705> hi:) [03:08] <PwrSurge> ubitux: got it working by recompiling with --disable-mipsfpu, --disable-mipsdspr1 and --disable-mipsdspr2 [03:09] <PwrSurge> word of advice, CPU optimizations should be "opt-in" and NOT "opt-out" [03:10] <kgp705> somebody can help me? why ffmpeg always stop stream at stream start after 4hours? [03:10] <kgp705> RTMPSockBuf_Fill, recv returned -1. GetSockError(): 10060 (Unknown error) [03:10] <kgp705> RTMP_ReadPacket, failed to read RTMP packet header [03:10] <kgp705> No more output streams to write to, finishing. [04:04] <cone-330> ffmpeg.git 03Michael Niedermayer 07master:8efde6d80c94: avformat/mov: clear padding area in mov_read_extradata() [04:07] <michaelni> PwrSurge, talk with Nedeljko Babic, there are no mips experts here, so writing here about mips will likely not have much effect [04:08] <michaelni> s/there are no mips experts here/there are no mips experts here I THINK/ [04:09] <michaelni> PwrSurge, also Nedeljko is the maintainer of the mips code, so he is the person to speak with if theres a issue in the code [04:11] <PwrSurge> i'm ok now [04:11] <PwrSurge> is he on IRC? [04:13] <michaelni> AFAIK, no [04:13] <michaelni> but i might be wrong of course [04:14] <michaelni> you can find his email address in the source code ... [10:45] <ubitux> michaelni: ok i finally get it, thanks a lot! [10:48] <ubitux> http://pastie.org/pastes/8582132/text makes more sense now :) [10:49] <ubitux> ofc, with the >>3 or >>4 done unsigned on the whole 64b word [11:01] <ubitux> which makes me realize we can actually do that with a single data [11:02] <ubitux> like doing the shift first, then (x^16)-16 [11:16] <ubitux> http://pastie.org/pastes/8582156/text [11:16] <ubitux> seems to work :) [11:17] <ubitux> and that's better because i only need one reg of data [11:17] <ubitux> oups, not 0x10 in the next one [11:18] <ubitux> http://pastie.org/pastes/8582158/text [11:18] <ubitux> here it is [12:53] <ubitux> http://pastie.org/pastes/8582285/text more complete example [12:54] <ubitux> now i'm wondering about a shortcut for the >>1 case [13:12] <funman> so who's coming to fosdem? [13:12] Action: funman is [13:16] <ubitux> if we have a ffmpeg stand i might consider it [13:16] <ubitux> i don't think it's the case though [13:58] <BBB> michaelni: I'm listed as moderator for 2 MLs on mplayerhq.hu (ffmpeg-soc-mentor and ffmpeg-legal), can I be removed? I'm really not tending to the MLs anymore and to my knowledge they're not in use anyway (I think they should be archived and/or deleted) [13:58] <BBB> but I keep getting daily emails about pending admin requests that I don't want to handle [14:09] <ubitux> ok, filter4() and filter2() done (but probably broken) [14:09] <ubitux> i'm gonna have a good time debugging all of this [14:24] <BBB> good joy :) [14:30] <Compn> BBB : you should be able to moderate yourself off of the list [14:31] <Compn> if you still have the password [14:31] <Compn> (i dont have access to those lists) [14:44] <michaelni> BBB, done [14:45] <michaelni> does anyone want to take over ML admin/mod of the 2 lists ? [14:45] <michaelni> -legal has noone now [14:47] <michaelni> or should they be deleted ? [14:48] <Compn> is -legal even written anywhere ? [14:48] <Compn> i mean, how would a person know to contact it ? [14:48] <michaelni> no idea [14:48] <Compn> if not in docs/wiki/code just delete it [14:50] <Compn> No results found for "ffmpeg-legal@ffmpeg.org". [14:50] <Compn> only result for ffmpeg-legal@mplayerhq.hu is lists.mplayerhq.hu/mailman/listinfo/ffmpeg-legal [14:50] <Compn> in the googles [14:50] <Compn> i didnt check code/docs [14:51] <Compn> i think it was made so the team could discuss legal issues ? [14:52] <Compn> just another worthless private ml ? [14:54] <michaelni> last mail i seem to have locally from it is from Mon, 23 May 2011 [15:10] <BBB> the list is unused [15:10] <michaelni> Compn, posted the suggestion to delete it to the ML [15:10] <BBB> it was for foundation setup and for some legal settlements with license violators that I pursued 4-5 years ago or so [15:10] <BBB> I stopped doing that 3 year ago when I started working for goog [15:11] <BBB> and foundation-wise ffmpeg uses something else now [15:11] <BBB> so no need to use the list anymore [15:11] <BBB> open lists are better anyway [15:11] Action: michaelni agrees [15:25] <BBB> I find changing assembly for icl kinda odd, basically agree with reimar, let's fix MANGLE [15:30] <saste> michaelni, ffmpeg-soc-mentor also should be deleted as well [15:30] <saste> we're not using since two years, and we should use the regular -devel mailing lists for such projects [15:30] <saste> the idea is to "integrate" students in the natural development environment [15:31] <saste> ^^ ignore this one, -mentor was about mentors [15:34] <BBB> well I still agree [15:34] <BBB> we can restart the list when soc comes in again [17:43] <j-b> ubitux: do you know where vismv is implemented in ffplay.c? [17:44] <ubitux> it's in the mpeg decoder [17:46] <j-b> I understood that, but is it just setting p_context->debug_mv to 1 or something more than that? [17:46] <ubitux> i think that's all [17:47] <j-b> It fails in VLC, no idea why [17:48] <cone-703> ffmpeg.git 03Yu Xiaolei 07master:af228a9f9f00: swscale/arm: fix build error with --enable-shared [17:48] <ubitux> it fails how? [17:48] <ubitux> no effect? [17:50] <j-b> yep [17:51] <wm4> who uses vismv and why? [17:52] <michaelni> i used it occasionally to see the motion vectors [17:53] <nevcairiel> its more of a debug/dev tool then something that users should ever see [17:56] <j-b> wm4: me, when teaching [18:12] <iive> i think libav removed it. probably got merged. [18:12] <michaelni> iive, vismv is supported in ffmpeg [18:13] <j-b> no, it definitively works with my ffplay [18:14] <ubitux> j-b: look at setting p_context->debug as well maybe [18:14] <michaelni> also works in ffmpeg and valgrind shows nothing odd with either ffplay or ffmpeg and -vismv [18:14] <iive> well, you know I do not like the deletionism. [18:15] <ubitux> though, debug_mv should be enough [18:16] <ubitux> j-b: oh, make sure you're not using hwaccel [18:16] <clever> is there a command line flag to force hwaccel off? [18:17] <j-b> ubitux: I am not [18:17] <j-b> ubitux: and I force no EMU_EDGE [18:18] <ubitux> no idea then :p [18:27] <michaelni> j-b, "cvlc --avcodec-vismv 7 matrixbench_mpeg2.mpg" works here but --ffmpeg-vismv doesnt [18:30] <j-b> 7 ? [18:31] <michaelni> 1+2+4 [18:32] <michaelni> but 1 should behave the same id guess [18:32] <michaelni> dunno what the difference is between the avcodec and ffmpeg options [18:34] <j-b> ffmpeg should be deprecated name of the same option, since it is a libavcodec option [18:56] <j-b> ubitux: as you seemed to care: https://wiki.videolan.org/Libavcodec_regressions/ [18:57] <ubitux> cool [18:58] <j-b> ubitux: and sorry, but WTH do you need that many RGB pixfmt? [18:58] <ubitux> do I? [18:58] <j-b> you do :) [18:58] <ubitux> dunno [18:59] <ubitux> is it problematic ? [18:59] <wm4> I'm wondering what the heck is up with these bayer formats [19:00] <j-b> ubitux: tbh, it's not problematic, but for libavutil users, it means more work [19:00] <wm4> they're not used anywhere, and they look like they'd break everything [19:00] <wm4> j-b: IMO most pixel formats come from endian and bit width variants [19:01] <wm4> j-b: endian swapping could be done in the raw video decoders/encoders instead (who needs odd-endian natively?) [19:01] <wm4> j-b: the bit width variants could be reduced by padding them with LSB zeros instead of MSB zeros, but AFAIK would require more work in the decoders [19:01] <j-b> wm4: well, I do not see the need for RGB0 [19:01] <wm4> IMO RGB0 is useful to indicate the lack of alpha [19:02] <wm4> how else would you know [19:02] <j-b> RGB24 [19:02] <wm4> that's 3 bytes per pixel [19:03] <wm4> there are also some odd formats, like AV_PIX_FMT_MONOBLACK [19:03] <wm4> which seems to be redundant with AV_PIX_FMT_MONOWHITE, except it's inverse [19:04] <wm4> anyway, just removing the endian variants would literally half the number of pixfmts [19:04] <j-b> still, sorry, they are wayy too many [19:05] <wm4> and most of them are used only by raw decoders... [19:07] <wm4> IMO they aren't really a problem though... what's worse is that a decoder can output any format it likes [19:07] <wm4> instead of a user requested one (so a user has to be able to deal with any format) [19:07] <wm4> but that's because libavcodec is so low level [19:07] <wm4> and you have to swscale the output yourself [19:08] <kierank> wbs: what's wrong with bayer? [19:08] <kierank> wm4: [19:08] <kierank> sorry [19:09] <wm4> I don't know thus format, but it uses some extremely weird form of RGB subsampling [19:09] <kierank> it's what comes from the camera sensor [19:09] <wm4> which breaks everything that expects that RGB is sane [19:09] <kierank> almost everything that you ever watch has come from a bayer sensor [19:09] <wm4> e.g. a user might use pixdesc to access individual components, and this code would break with BAYER (there are actually some filters in lavfi that do this) [19:10] <wm4> what a sick world [19:10] <kierank> a user might try to use pixdesc [19:10] <j-b> planar RGB was alos breaking the "sane part" [19:10] <kierank> and then fail [19:10] <wm4> j-b: planar RGB is rather easy to handle and to detect, though [19:10] <j-b> yes [19:11] <wm4> kierank: I suspect it's more on the fail side usually... [19:11] <nevcairiel> its not ffmpegs fault some codecs encode their stuff like that :d [19:12] <kierank> I gave up trying to use pixdesc [19:12] <wm4> on the other hand, ffmpeg has only a small number of audio formats [19:12] <kierank> can't remember exactly why but it was a complete pita [19:12] <wm4> even 24 bit audio, which is rather widely used everywhere, is not supported [19:12] <nevcairiel> but its also really the only one missing [19:12] <j-b> ah, that! [19:12] <j-b> No way to show the user that it was 24bit audio in the UI [19:12] <wm4> heh [19:12] <nevcairiel> sure is [19:12] <j-b> sooo many user complaints [19:12] <nevcairiel> read raw_bits_per_sample [19:13] <kierank> i thought ffmpeg has 24-bit audio? [19:13] <wm4> j-b: always show 24 instead of 32, nobody will notice [19:13] <j-b> wm4: that's cheating [19:13] <wm4> kierank: it's converted to 32 bit [19:13] <nevcairiel> there is a variable for that in avcodeccontext, why not use it o.o [19:13] <nevcairiel> i send patches for various codecs to actually set it properly [19:13] <wm4> nevcairiel: there are many variables there [19:13] <wm4> the question is whether it's reliable (maybe it isn't...) [19:13] <wm4> hm I guess I could use it [19:14] <nevcairiel> not sure how many codecs really use S32 [19:14] <nevcairiel> could check how many of those set it [19:14] <kierank> anything packed uncompressed [19:14] <wm4> and then introduce a AF_FORMAT_S32_BUT_REALLY_24 in my code [19:14] <nevcairiel> i just lug around the bits per sample [19:14] <nevcairiel> since i also want to show 20, if appropriate [19:16] <wm4> nevcairiel: what's the correct spelling of that variable? [19:16] <kierank> wm4: i can understand why it's done that way though [19:16] <wm4> I only see av_get_exact_bits_per_sample [19:16] <kierank> because if you want to convert it you have to change to 32-bit each time [19:16] <nevcairiel> AVCodecContext bits_per_raw_sample [19:16] <wm4> nevcairiel: thanks [19:16] <kierank> wm4: would your S24 be three bytes, or 24-bits in 32-bits unshifted? [19:16] <wm4> kierank: 3 bytes [19:17] <nevcairiel> which is probably why its not done [19:17] <kierank> then it would be a pita to convert [19:17] <nevcairiel> SIMDing 24-bit audio is painful [19:17] <wm4> it's what the audio APIs expect [19:17] <nevcairiel> i tried once [19:17] <j-b> nevcairiel: this field is just an "information" field? [19:18] <wm4> nevcairiel: libavresample (which is the only thing which will have to deal with it) could perhaps convert it on the fly? [19:18] <nevcairiel> aren't all fields some kind of information? [19:18] <kierank> wm4: then it's pointless [19:18] <nevcairiel> but sure, its not mandatory, you can play it as S32 just fine since its shifted to MSBs [19:18] <kierank> wm4: it's the same as the people who wanted 10-bit video to be shifted into a uint16_t [19:18] <nevcairiel> it just informs you that 8 bits are zeros, for example [19:18] <kierank> to process it you'd have to shift it pointlessly [19:19] <wm4> well duh, all decoders shift around data [19:19] <wm4> but the purpose of doing that is to turn it into easy to handle information [19:19] <kierank> ????? [19:19] <kierank> wtf [19:19] <wm4> so there's a tradeoff [19:19] <nevcairiel> i always get that mixed up, ffmpeg doesnt shift video, right? [19:19] <kierank> some decoders do because they haven't been updated iirc [19:19] <kierank> wm4: it's bad because you need 32-bit intermediates [19:19] <nevcairiel> the stupid thing is, all the microsoft types for >8-bit video expect shifted [19:19] <nevcairiel> so i have to do it anyway :D [19:20] <kierank> whereas you can do simple processing on 10-bit [19:20] <wm4> kierank: yeah, and according to michaelni it'd be slightly less efficient [19:20] <wm4> but think of the display side... what takes 10 bit natively? [19:20] Action: kierank has a lot of equipment which does [19:20] <wm4> even 10 but yuv? [19:20] <wm4> *bit [19:20] <kierank> all the video processing I do is 10-bit 4:2:2 [19:20] <nevcairiel> remember his broadcast background, they do much more 10-bit then the average persons [19:20] <kierank> hundreds of channels doing that [19:20] <wm4> I guess that's "pro" stuff then [19:21] <kierank> for example to do an interlaced 422 -> 420 conversion I do a weighted average of the chroma fields [19:21] <kierank> if it was 16-bit I would have to use 32-bit intermediates [19:23] <nevcairiel> reminds me of my rgb converter, it starts to lose precision once input goes above 14 bits, since i didnt use 32-bit intermediates [19:24] <nevcairiel> luckily, thats rather are, and with a 8-bit rgb end result, you wouldnt notice anyway =P [19:30] <wm4> anyway, still could kill off 50% of the formats by removing the endian variants [19:31] <wm4> or is there a valid use case for these too? other than FATE possibly becoming a little bit slower [19:31] <nevcairiel> raw formats i suppose [19:32] <nevcairiel> dont want to byteswap them just because we lack a non-native endian format [19:32] <nevcairiel> on the other hand, audio does that too [19:32] <nevcairiel> (but then audio is usually not a cpu hog) [19:40] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:6ea05ef278b2: avcodec/h264: remove unused variable [19:40] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:833501657bed: avutil/frame: increase padding for frames [20:21] <ubitux> (probably broken) filter6() done [20:21] <ubitux> filter14 remaining, here we go. [20:22] <nevcairiel> so you write all of them first and fix them later? :D [20:23] <ubitux> yes [20:23] <ubitux> i know that's not really a good idea but well. [20:23] <ubitux> i've thought a lot on each of them so it should be fine ;) [20:24] <ubitux> at least it builds! [20:34] <ubitux> i love when the number of registers matches exactly the number i need [20:34] <ubitux> unfortunately it doesn't happen often :p [21:00] <rcombs> kierank: ProRes is 12-bit iirc [21:10] <kierank> rcombs: ? [21:10] <rcombs> a lot of TV stuff is 12bit, not even 10bit [21:12] <kierank> SDI is 10-bit [21:43] <BBB> ubitux: I do it that way too, I find it ok [22:10] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:55fa898969d1: avcodec/jpeg2000dec: zero Jpeg2000QuantStyle structure before use in get_qcd() [00:00] --- Sun Dec 29 2013