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

[burek]

[00:17] <ioni> i'm here j-b 
[00:17] <j-b> pasteeater: see ioni 
[00:22] <Compn> spaam : i'm good in that i run the rtmpsuck program and hope nothing goes wrong
[00:22] <Compn> otherwise i have no idea :P
[00:26] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r4717e29796 10ffmpeg/libavformat/flvdec.c: 
[00:26] <CIA-18> ffmpeg: flvdec: skip duplicate indexes
[00:26] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:30] <pasteeater> ioni: "j-b: (H.264 decoding) regression reported by the ArchLinux packager against VLC. maybe an issue on our side"
[00:30] <pasteeater> how can we duplicate the issue?
[00:31] <ioni> pasteeater, vlc 1.1.2, ffmpeg head, any mkv with h264
[00:31] <j-b> but 0.8.5 works, right?
[00:31] <ioni> yes
[00:32] <ioni> 0.8.6 
[00:32] <ioni> tried 0.8 branch head
[00:33] <iive> ioni: tried to play it with ffplay?
[00:34] <ioni> yes
[00:34] <ioni> works fine
[00:34] <ioni> https://trac.videolan.org/vlc/ticket/5518
[00:35] <iive> tried to bisect?
[00:36] <pasteeater> todo to myself: make a bisect howto on trac.
[00:38] <iive> i'm quite sure a new more practical guide of using git would be quite welcome.
[00:45] <ioni> iive, i didn't because nobody confirmed it
[00:46] <ioni> i should try vlc head to see if is working
[00:53] <Daemon404> [18:47] < Daemon404> does libavcodec have any functions to do a forward little-endian bitscan?
[00:53] <Daemon404> [18:49] < Daemon404> or a little-endian get_bits?
[00:53] <Daemon404> ^
[00:59] <michaelni> Daemon404, #define ALT_BITSTREAM_READER_LE somewhere at the top does not do what you want ?
[00:59] <Daemon404> let me check
[01:04] <iive> ioni: if same ffplay plays the file normally, then it is vlc related problem, but it would still be useful to find the commit that caused it.
[01:04] <iive> it may be e.g. api change.
[01:04] <Daemon404> michaelni, thanks that indeed works
[01:06] <Daemon404> now.. does it have a bitscan function?
[01:06] <michaelni> for one direction theres av_log2()
[01:06] <Daemon404> wait, how would log2 work for bitscanning?
[01:07] <michaelni> integer log2 is the index of the first set bit when you search from most significsnt to least
[01:09] <Daemon404> michaelni, i want the opposite direction though
[01:12] <michaelni> Daemon404, something like __builtin_ctz() ?
[01:12] <michaelni> i dont  think we have that yet
[01:12] <Daemon404> ok
[01:13] <michaelni> Daemon404, you can implement it like av_log2()
[01:14] <michaelni> if speed matters
[01:23] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r5955c63c36 10ffmpeg/libavdevice/v4l2.c: 
[01:23] <CIA-18> ffmpeg: v4l2: fix uninitialized variable
[01:23] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:27] <Daemon404> michaelni, i think ive got what i need, but
[01:27] <Daemon404> mmm n/m got it.
[02:22] <CIA-18> ffmpeg: 03Justin Ruggles 07master * rb8f02f5b4e 10ffmpeg/libavcodec/x86/ (dsputil_mmx.c dsputil_yasm.asm): dsputil: use cpuflags in x86 versions of vector_clip_int32()
[02:22] <CIA-18> ffmpeg: 03Martin Storsjö 07master * r4b3dc857e4 10ffmpeg/libavformat/rtsp.c: 
[02:22] <CIA-18> ffmpeg: rtsp: Discard the dynamic handler, if it has an alloc function which failed
[02:22] <CIA-18> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[02:22] <CIA-18> ffmpeg: 03Martin Storsjö 07master * red307e2659 10ffmpeg/libavformat/rdt.c: 
[02:22] <CIA-18> ffmpeg: rdt: Check the return value of avformat_open
[02:22] <CIA-18> ffmpeg: If it failed, return NULL. This avoids trying to use an
[02:22] <CIA-18> ffmpeg: half-initialized RDTDemuxContext.
[02:22] <CIA-18> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[02:22] <CIA-18> ffmpeg: 03Martin Storsjö 07master * r0882689116 10ffmpeg/libavformat/rmdec.c: (log message trimmed)
[02:22] <CIA-18> ffmpeg: rdt: Set AVFMT_NOFILE on ff_rdt_demuxer
[02:22] <CIA-18> ffmpeg: This makes rdt work again, which has been broken since
[02:22] <CIA-18> ffmpeg: 603b8bc2a109978c8499b06d2556f1433306eca7. This commit made
[02:22] <CIA-18> ffmpeg: opening a demuxer without a file (or in this case, with a filename
[02:22] <CIA-18> ffmpeg: which can't be opened) fail, unless the demuxer actually declared
[02:22] <CIA-18> ffmpeg: AVFMT_NOFILE.
[02:22] <CIA-18> ffmpeg: 03Martin Storsjö 07master * r87892ef8a6 10ffmpeg/libavformat/avformat.h: 
[02:22] <CIA-18> ffmpeg: avformat: Revise wording
[02:22] <CIA-18> ffmpeg: It might make sense not to make the function completely mandatory
[02:22] <CIA-18> ffmpeg: immediately at the next bump, which might be quite soon after
[02:22] <CIA-18> ffmpeg: the function was introduced.
[02:22] <CIA-18> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[02:22] <CIA-18> ffmpeg: 03Alex Converse 07master * ra1684cf82d 10ffmpeg/libavcodec/msmpeg4.c: 
[02:22] <CIA-18> ffmpeg: msmpeg4: Don't set up run-level info for level 0.
[02:22] <CIA-18> ffmpeg: run: The number of zero coefficients preceding a non-zero coefficient,
[02:22] <CIA-18> ffmpeg: in the scan order. The absolute value of the non-zero coefficient is
[03:39] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * rac3c895d93 10ffmpeg/libavcodec/utils.c: 
[03:39] <CIA-18> ffmpeg: Revert "Warn the user if lowres > max_lowres, set lowres to max_lowres and continue"
[03:39] <CIA-18> ffmpeg: Changing the lowres value is risky because the user application may have a
[03:39] <CIA-18> ffmpeg: local copy and not read back into it, or not undo some lowres dependant things.
[03:39] <CIA-18> ffmpeg: A patch implementing this in ffplay is already on ffmpeg-dev, so this feature
[03:39] <CIA-18> ffmpeg: should be back soon.
[03:39] <CIA-18> ffmpeg: This reverts commit 125ea3ee06c4d71082bee3fc03c65d7c8c10d68c.
[10:30] <ubitux> i'm trying to allocated a RGBA pic buffer with av_image_alloc(), but it raises an invalid argument
[10:31] <ubitux> size sounds valid to me (1280x1080)
[10:33] <ubitux> any idea what i'm doing wrong?
[10:34] <ubitux> it looks like av_image_alloc(pointers, linesize, PIX_FMT_RGBA, 1280, 1080, 1);
[10:35] <ubitux> a small size, another pixfmt, another alignment, always the same, invalid argument
[10:36] <ubitux> pointers and linesize are simply uint8_t *pointers[4], int linesize[4] buffers
[10:41] <CIA-18> ffmpeg: 03Carl Eugen Hoyos 07master * r6aaf6db253 10ffmpeg/libavformat/mpegts.c: 
[10:41] <CIA-18> ffmpeg: Support decoding transport streams from Sony NXCAM.
[10:41] <CIA-18> ffmpeg: Fixes ticket #617.
[10:41] <CIA-18> ffmpeg: 03Carl Eugen Hoyos 07master * r8a3f976498 10ffmpeg/libavformat/ (isom.c mov.c): 
[10:41] <CIA-18> ffmpeg: Support decoding "m1v " mpeg1video in mov.
[10:41] <CIA-18> ffmpeg: Fixes ticket #579 at least for ffplay.
[10:41] <CIA-18> ffmpeg: 03Carl Eugen Hoyos 07master * r4d7c71c364 10ffmpeg/libavformat/ (audiointerleave.c internal.h utils.c): 
[10:41] <CIA-18> ffmpeg: Check for OOM after av_mallocz() in ff_interleave_add_packet().
[10:41] <CIA-18> ffmpeg: Fixes a crash with the sample from Ubuntu bug #869125.
[10:57] <ubitux> arh i'm so stupid.
[12:18] <ioni> pasteeater, ping
[14:34] <ubitux> i need to do a pixfmt convert, what should i use for this?
[14:34] <ubitux> i though it was part of swscale but seems not
[14:34] <ubitux> the av_image_ func doesn't seem to have such thing too
[14:43] <michaelni> ubitux, sws_getContext + sws_scale
[14:44] <ubitux> mmh ok thank you
[15:09] <ioni> hey michaelni 
[15:10] <ioni> pasteeater, i finished bisecting that vlc issue
[15:10] <ioni> no idea if is a ffmpeg issue or vlc
[15:10] <ioni> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=475fb67d0b391ad1e8e3e8e3d65d7e6892e17e7a
[15:10] <ioni> reverting this fixes vlc
[15:30] <michaelni> ioni, ill revert this one, it was just to simplify avidemux
[15:30] <ioni> michaelni, i'm talking about  http://trac.videolan.org/vlc/ticket/5518
[15:30] <ioni> maybe is vlc related
[15:32] <michaelni> of course it is but default AVFrame.opaque changing is not something we should do when it breaks some app
[15:33] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r33feba3abf 10ffmpeg/libavcodec/utils.c: 
[15:33] <CIA-18> ffmpeg: Revert "lavc: Init AVFrame->opaque to AVCodecContext.opaque in avcodec_default_get_buffer()"
[15:33] <CIA-18> ffmpeg: This commit causes problems for vlc, see https://trac.videolan.org/vlc/ticket/5518
[15:33] <CIA-18> ffmpeg: This reverts commit 475fb67d0b391ad1e8e3e8e3d65d7e6892e17e7a.
[15:37] <ioni> michaelni, now that ffmpeg has a lot of releases, you encourage distributions to use released tarballs vs snapshot from master?
[15:37] <ioni> we used to do snapshots because releases weren't that often
[15:39] <maister> michaelni, I looked more into rgb15to24 converting in libswscale. I can't see any way to make it convert to the full scale. And looking at the comments it doesn't seem like a good idea to just change it.
[15:39] <michaelni> i would use git master if i was a distribution but iam not :)
[15:40] <ioni> k
[15:40] <j-b> ioni: nice job of bisecting...
[15:40] <ioni> thanks
[15:40] <ioni> i realized that i need a better computer
[15:40] <j-b> Now, why the hell VLC does not like this commit is beyond me ?
[15:40] <ioni> compiling ffmpeg on my lappy is so damn slow
[15:41] <j-b> Now, why the hell VLC does not like this commit, is beyond me ?
[15:42] <michaelni> maister, please elaborate what you think it should do and what it does and why its bad
[15:42] <maister> michaelni, the comment says this: http://pastebin.com/P0Z4dEnb
[15:43] <maister> michaelni, the "better method" is needed for games, since it's very easy to spot a darker tone in i.e. game footage.
[15:44] <maister> however, the comments to give a good reason for the current method, so ... :s
[15:44] <maister> do*
[15:44] <maister> the comment is in rgb2rgb_template.c:231
[15:44] <maister> same comment for the MMX version
[15:45] <michaelni> the comment is from 2002 :)
[15:45] <michaelni> id say png is broken if this affects compression
[15:45] <maister> ok, so you think we can use the "proper" method?
[15:45] <michaelni> yes
[15:45] <maister> ok, I can try to make a patch
[15:46] <michaelni> :)
[15:46] <maister> then I don't have to reinvent parts of swscale in my app, lol
[15:46] <michaelni> also adding SSE/AVX versions to the MMX should increase speed alot
[15:46] <michaelni> on modern cpu that is
[15:46] <maister> ye
[15:47] <maister> I was thinking about SSE for the gbr24p stuff
[15:47] <maister> as well
[15:48] <maister> there's altivec code too?
[15:49] <michaelni> for rgb2rgb i think not
[15:50] <maister> ok
[15:50] <maister> I might have to ask a bit about the MMX code ... :)
[15:51] <maister> looks scary
[15:54] <ubitux> is there some specific sws flag i should use for the lossy-less or lossless pixfmt convert (from anything to rgb24?)
[16:02] <michaelni> ubitux, if theres support for doing something lossless it should be done by default
[16:02] <ubitux> ok
[16:02] <michaelni> there are flags to avoid chroma subsample and accurate rounding though
[16:02] <michaelni> which may help in some cases
[16:03] <ubitux> i'm comparing the results of some histogram rgb analysis between python imaging library and ffmpeg, and i don't have the same results while reading a jpeg
[16:03] <ubitux> i guess the imaging library is doing a crappy pixfmt convert
[16:04] <ubitux> or i'm misusing the swscale :p
[16:05] <maister> you're doing rgb15/16 to rgb24 by any chance? :P
[16:06] <ubitux> yuvj420p -> rgb24
[16:29] <maister> michaelni, in mmx there are 8 registers, right?
[16:36] <michaelni> maister, yes
[16:36] <michaelni> they use the x87 float stack
[16:37] <michaelni> so dont mix mmx with float :)
[16:50] <maister> michaelni, hrr, k. :P I've updated the C versions at least.
[16:51] <maister> Now trying to make sense of this inline asm
[16:51] <maister> btw
[16:51] <maister> inline asm using the "m"(*s)
[16:52] <maister> where s is an uint16_t
[16:52] <maister> *
[16:52] <maister> what does that mean exactly?
[16:53] <maister> nvm
[17:46] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r4b7ef5a1e6 10ffmpeg/libavformat/flvdec.c: 
[17:46] <CIA-18> ffmpeg: flv: Skip invalid index
[17:46] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:51] <Kov|meiya> flv has an index?
[17:51] <av500> it can have
[17:52] <Kov|meiya> ic
[17:52] <Kov|meiya> I probably ignored that part of the spec
[18:22] <ubitux> i just finished a video filter which select 1/N frame, based on the stats of the N last frames; but since i don't want to keep in memory N frames, is it still possible to raise an abritrary frame?
[18:28] <j-b> michaelni: Compn: creation of directories inside the incoming should be OK now.
[18:32] <maister> michaelni, updated the MMX conversion code as well. now going to test ... :D
[18:37] <michaelni> maister, great
[18:37] <michaelni> j-b, thx
[18:38] <michaelni> ubitux, if you implement some way for a filter to request seeking or pass the compressed frame to the filter or do 2passes
[18:39] <maister> michaelni, I saw there was a colorspace-test.c in swscale
[18:39] <maister> from 2002 :D
[18:39] <michaelni> :)
[18:39] <maister> is it still viable as a way of testing these functions?
[18:41] <michaelni> it should still work, yes
[18:43] <maister> any way to build it with the build system?
[18:43] <maister> it's defined in TESTPROGS
[18:43] <maister> at least in the makefile
[19:05] <CIA-18> ffmpeg: 03Reimar Döffinger 07oldabi * r661e081176 10ffmpeg/libavformat/flvdec.c: 
[19:05] <CIA-18> ffmpeg: Do not call parse_keyframes_index with NULL stream.
[19:05] <CIA-18> ffmpeg: Seems to fix trac issue #569.
[19:05] <CIA-18> ffmpeg: Sample is unfortunately not available, but it might be caused by
[19:05] <CIA-18> ffmpeg: an index existing for non-existing audio stream (?).
[19:05] <CIA-18> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[19:05] <CIA-18> ffmpeg: (cherry picked from commit 6ea6ff053af2aff8a9a898292f9640efa9290c9f)
[19:05] <CIA-18> ffmpeg: 03Reimar Döffinger 07release/0.7 * rd484a07f1c 10ffmpeg/libavformat/flvdec.c: 
[19:05] <CIA-18> ffmpeg: Do not call parse_keyframes_index with NULL stream.
[19:05] <CIA-18> ffmpeg: Seems to fix trac issue #569.
[19:05] <CIA-18> ffmpeg: Sample is unfortunately not available, but it might be caused by
[19:05] <CIA-18> ffmpeg: an index existing for non-existing audio stream (?).
[19:05] <CIA-18> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[19:05] <CIA-18> ffmpeg: (cherry picked from commit 6ea6ff053af2aff8a9a898292f9640efa9290c9f)
[19:05] <CIA-18> ffmpeg: 03Reimar Döffinger 07release/0.8 * r54e4bf3296 10ffmpeg/libavformat/flvdec.c: 
[19:05] <CIA-18> ffmpeg: Do not call parse_keyframes_index with NULL stream.
[19:06] <CIA-18> ffmpeg: libavformat: add support for G726 audio decoder in RTP and RTSP streams
[19:06] <CIA-18> ffmpeg: Fixes Ticket611
[19:06] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:06] <CIA-18> ffmpeg: (cherry picked from commit df9c1cfb48c2d8ddb3c11b4d1e8c4c33c6b0d8a2)
[19:07] <michaelni> maister, make libswscale/colorspace-test
[19:08] <ubitux> michaelni: about the filter, is there anything similar ATM?
[19:08] <michaelni> let me think
[19:08] <maister> michaelni, getting undefined references to the various functions.
[19:09] <ubitux> i see the select filter has some frame queue
[19:09] <michaelni> maister, its working here 
[19:09] <maister> michaelni, hm.
[19:10] <maister> tested 15->24 mmx at least.
[19:10] <maister> worked
[19:11] <michaelni> ubitux, libmpcodecs/vf_framestep.c
[19:11] <michaelni> mayve
[19:11] <michaelni> maybe
[19:12] <ubitux> yes, the limited and non-native version of select filter :)
[19:13] <michaelni> if you want something with delay vf_yadif adds a very short delay
[19:13] <ubitux> mmh ok
[19:13] <ubitux> thank you :)
[19:13] <michaelni> np
[19:14] <ubitux> btw, it's for a thumbnail filter
[19:14] <ubitux> so it picks an "interesting" frame
[19:15] <ubitux> (avoid blackframe with absolute seek and similar)
[19:15] <ubitux> i think it could be useful
[20:38] <CIA-18> ffmpeg: 03Reimar Döffinger 07release/0.7 * r80a173a33b 10ffmpeg/libavutil/lzo.c: 
[20:38] <CIA-18> ffmpeg: av_lzo1x_decode: properly handle negative buffer length.
[20:38] <CIA-18> ffmpeg: Treating them like 0 is safest, current code would invoke
[20:38] <CIA-18> ffmpeg: undefined pointer arithmetic behaviour in this case.
[20:38] <CIA-18> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[20:38] <CIA-18> ffmpeg: (cherry picked from commit b9242fd12f4be4a79e31fd0aa125ab8a48226896)
[20:39] <CIA-18> ffmpeg: (cherry picked from commit 0411b1928965050a940155984a16ad82fe462fc1)
[20:39] <CIA-18> ffmpeg: 03Reimar Döffinger 07release/0.8 * r0411b19289 10ffmpeg/libavutil/lzo.c: 
[20:39] <CIA-18> ffmpeg: av_lzo1x_decode: properly handle negative buffer length.
[20:39] <CIA-18> ffmpeg: Treating them like 0 is safest, current code would invoke
[20:39] <CIA-18> ffmpeg: undefined pointer arithmetic behaviour in this case.
[20:39] <CIA-18> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[20:39] <CIA-18> ffmpeg: (cherry picked from commit b9242fd12f4be4a79e31fd0aa125ab8a48226896)
[20:39] <CIA-18> ffmpeg: 03Reimar Döffinger 07release/0.7 * r3970d4e728 10ffmpeg/libavcodec/nuv.c: 
[20:39] <CIA-18> ffmpeg: nuv: Fix combination of size changes and LZO compression.
[20:39] <CIA-18> ffmpeg: There were multiple issues, for example might we have to re-run
[20:39] <CIA-18> ffmpeg: the decompression when the size of the buffer increased,
[20:39] <CIA-18> ffmpeg: we should always use a decompression buffer large enough for
[20:39] <CIA-18> ffmpeg: the header (so we do not get stuck when the size is too small).
[20:39] <CIA-18> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[20:39] <CIA-18> ffmpeg: 03Reimar Döffinger 07release/0.8 * rd58c5586ec 10ffmpeg/libavcodec/nuv.c: 
[20:39] <CIA-18> ffmpeg: nuv: Fix combination of size changes and LZO compression.
[20:39] <CIA-18> ffmpeg: There were multiple issues, for example might we have to re-run
[20:39] <CIA-18> ffmpeg: the decompression when the size of the buffer increased,
[20:39] <CIA-18> ffmpeg: we should always use a decompression buffer large enough for
[20:39] <CIA-18> ffmpeg: the header (so we do not get stuck when the size is too small).
[20:39] <CIA-18> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[20:43] <maister> michaelni, I haven't tested this fully yet, but this is what I've got so far:
[20:43] <maister> http://pastebin.com/3CLDsM3n
[20:44] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r0643ff1712 10ffmpeg/libavformat/mpegvideodec.c: 
[20:44] <CIA-18> ffmpeg: mpegvideo_probe: dont be too picky on spec compliance and the lack of system startcodes.
[20:44] <CIA-18> ffmpeg: Fixes Ticket620
[20:44] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:44] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r26d7eb40fd 10ffmpeg/libavformat/mpegvideodec.c: 
[20:44] <CIA-18> ffmpeg: mpegvideo probe: fix slice counting
[20:44] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:44] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * rb52f2d88fe 10ffmpeg/libavformat/mpegvideodec.c: 
[20:44] <CIA-18> ffmpeg: mpegvideo_probe: count video and audio pes seperately
[20:44] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:50] <michaelni> maister, did you consider pmullw ?
[20:51] <michaelni> i think it could be used instead of split shit merge
[20:51] <michaelni> shift :)
[20:51] <kierank> lol
[20:51] <maister> lol
[20:52] <maister> michaelni, no, haven't. It has to be scaled by 0xff/0xf8 at least.
[20:54] <michaelni> a + (a<<5) is the same as a*0x21
[20:55] <michaelni> so you could mask the bits you need then pmullw and then shift it into place
[20:56] <michaelni> pmulh(u)w might also help for some
[20:56] <maister> michaelni, hm. yes.
[20:57] <michaelni> but note pmulhuw is mmx2 not mmx if iam not mistaken
[20:57] Action: michaelni is sure its not mmx actually
[21:01] <maister> hm, a + (a << 5) is not equivalent to (a << 3) + (a >> 2) though.
[21:01] <michaelni> ( a + (a << 5))>>2
[21:01] <maister> oh right
[21:04] <ubitux> michaelni: the range case doesn't look standard
[21:04] <ubitux> are you sure it won't cause any compilation issue?
[21:06] <maister> michaelni, but the shift/or stuff is fine for C, or?
[21:10] <ubitux> it looks like a gnu extension
[21:10] <ubitux> (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Case-Ranges.html)
[21:10] <ubitux> unfortunately :)
[21:11] <michaelni> ubitux, yes :(
[21:11] <michaelni> ill fix it
[21:11] <michaelni> we had this in rv10.c too
[21:11] <michaelni> but that was removed long ago
[21:11] <ubitux> i didn't find any other match in the project
[21:12] <michaelni> maister, c is ok, there are some simplifications possible but  thats unrelated to the paztch
[21:12] <michaelni> ubitux, c21f308e77ee1ab9dd280f40f2008122d1fc53d7 removed them
[21:13] <ubitux> i see, ok
[21:19] <maister> michaelni, isn't an uint64_t approach practically the same as mmx? ;)
[21:20] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r4e38d4ef0e 10ffmpeg/libavformat/mpegvideodec.c: 
[21:20] <CIA-18> ffmpeg: mpegvideo_probe: Getting rid of the use of GCC language extensions
[21:20] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:26] <michaelni> maister, there are some instructions missing for unit64
[21:26] <michaelni> like punpck*
[21:26] <maister> michaelni, ye, ofc. :p I'll try to use pmullw. was hard enough getting the shift version to work, lol :D
[22:16] <CIA-18> ffmpeg: 03Reimar Döffinger 07master * rfd791675d4 10ffmpeg/libavcodec/eacmv.c: 
[22:16] <CIA-18> ffmpeg: Fix nonsense buffer hints.
[22:16] <CIA-18> ffmpeg: The codec uses all previous frames as reference frames, so they
[22:16] <CIA-18> ffmpeg: certainly must be preserved and readable.
[22:16] <CIA-18> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[22:42] <maister> michaelni, think I managed a pmullw approach
[22:42] <maister> adds 4 ops for 15 bit and 5 for 16 bit.
[22:44] <michaelni> maister, is it faster than the last ?
[22:44] <michaelni> see START/STOP_TIMER
[22:53] <maister> michaelni, at which granularity? per call to the function, or swscale itself?
[22:54] <michaelni> per call is probably better
[22:54] <maister> it uses rdtsc I guess?
[23:02] <michaelni> yes
[23:03] <maister> 7105903 dezicycles in rgb15tobgr24, 2048 runs, 0 skips
[23:03] <maister> 7015641 dezicycles in rgb15tobgr24, 4096 runs, 0 skips
[23:03] <maister> that's for pmullw at least
[23:04] <maister> btw, what's a dezicycle? :s
[23:06] <maister> 7758353 dezicycles in rgb15tobgr24, 2048 runs, 0 skips
[23:06] <maister> 7683802 dezicycles in rgb15tobgr24, 4096 runs, 0 skips
[23:06] <maister> for shift/or version
[23:11] <maister> 6739170 dezicycles in rgb15tobgr24, 2048 runs, 0 skips
[23:11] <maister> 7043551 dezicycles in rgb15tobgr24, 4096 runs, 0 skips
[23:11] <maister> tried pmullw again
[23:20] <maister> michaelni, here's the patch so far at least: http://pastebin.com/W6EHKh80
[23:20] <michaelni> maister, http://en.wikipedia.org/wiki/Deci-
[23:25] <maister> was confused about dezi-
[23:25] <maister> but I guess
[23:27] <michaelni> you can get rid of some shifts by using pmulhw
[23:28] <michaelni> pmulhw is mmx *huw mmx2
[23:30] <maister> michaelni, ok, guess I'll have to look at that tomorrow. Getting late here :P
[23:31] <kierank> i would suggest writing the asm in yasm
[23:32] <Daemon404> what's libav*'s 2^x function?
[23:32] <kierank> 1 << x ?
[23:33] <michaelni> instead of (x*0x21)>>7 you can do (x*0x4200)>>16
[23:33] <Daemon404> derp, braindead.
[23:33] <michaelni> the * >>16 is pmulhw
[23:33] <michaelni> just be carefull as it is signed
[23:34] <maister> michaelni, :)
[23:40] <michaelni> kierank, converting to yasm is work and risks introducing bugs, also theres C code to handle the %8 remainder 
[23:40] <michaelni> that C code would need to be changed to asm or you would have to somehow integrate it with C
[23:42] <Daemon404> anyway, c99 VBLE decoder will be incoming soon :)
[23:42] <Daemon404> (it had no source code previously at all, only a binary)
[23:42] <Compn> vble ?
[23:42] <Compn> cant remember what that is
[23:42] <Daemon404> Yet Another Lossless Codec
[23:42] <michaelni> thus in summary converting to yasm seems more work then gain but i wont stop anyone from doing it
[23:42] <Daemon404> by MarcFD
[23:42] <Daemon404> it was popular back in teh day on doom9
[23:43] <Compn> ah
[23:43] <Compn> theres quite a few lossless video codecs now :)
[23:43] <Daemon404> youd be amazed how many are still in frequent use
[23:43] <Daemon404> <_<
[23:43] <iive> is it video ?
[23:43] <Daemon404> yes
[23:44] <maister> michaelni, so regarding the right, that means the R component in rgb16 has to be shifted first?
[23:44] <maister> s/right/sign/
[23:46] <michaelni> yes (that is unless its mmx2 or later but i think its better to consider this only after everything is in git and if tehres still interrest)
[23:48] <maister> if I understand it correctly, the 4 shifts in 15-bit can be removed
[23:48] <maister> and 4/5 shifts in 16bit?
[23:51] <michaelni> the low case of the 3 needs a shift
[00:00] --- Wed Nov  9 2011