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

[burek]

[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 at ffmpeg.org".
[14:50] <Compn> only result for ffmpeg-legal at 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