[FFmpeg-devel-irc] IRC log for 2010-07-18

[irc at mansr.com]

[00:50:42] <saintdev> peloverde: ping
[05:53:40] <_av500_> http://www.dspdimension.com/admin/dft-a-pied/
[07:43:12] <CIA-99> ffmpeg: pross * r24295 /trunk/libavcodec/ (cga_data.c cga_data.h): Add ff_vga16_font
[07:45:29] <CIA-99> ffmpeg: pross * r24296 /trunk/libavcodec/ (cga_data.c cga_data.h): Add ff_draw_pc_font()
[07:47:18] <CIA-99> ffmpeg: pross * r24297 /trunk/libavcodec/tmv.c: 8088flex TMV video decoder now uses ff_draw_pc_font()
[07:53:35] <CIA-99> ffmpeg: pross * r24298 /trunk/libavcodec/ (cga_data.c cga_data.h): Add @file documentation tag
[07:56:21] <mru> morning
[07:56:35] <av500> morning
[07:58:09] * elenril wonders why did xelatex decide to go batshit insane overnight
[07:58:59] <pross-au> morning (okay)
[08:04:25] <CIA-99> ffmpeg: pross * r24299 /trunk/libavcodec/ (allcodecs.c avcodec.h ansi.c Makefile): ASCII/ANSI art decoder
[08:05:53] <CIA-99> ffmpeg: pross * r24300 /trunk/libavformat/ (sauce.c sauce.h): Add ff_sauce_read()
[08:06:12] <mru> wtf is sauce?
[08:06:16] <mru> is it secret?
[08:06:57] <pross-au> Indeed
[08:07:08] <pross-au> It was the precursor to ID3
[08:07:21] <pross-au> Goes with the ansi patch
[08:07:45] <CIA-99> ffmpeg: pross * r24301 /trunk/ (6 files in 3 dirs): Tele-typewriter demuxer
[08:11:13] <pross-au> Hmm, perhaps i better check that doxygen syntax...
[08:14:01] <CIA-99> ffmpeg: pross * r24302 /trunk/libavformat/sauce.h: Use correct doxygen syntax
[08:16:33] <CIA-99> ffmpeg: pross * r24303 /trunk/libavformat/sauce.h: Remove trailing linefeed
[08:18:16] <mru> pross-au: where/when was this lot reviewed?
[08:23:12] <pross-au> ml
[08:23:17] <mru> when?
[08:23:20] <mru> I see no review
[08:23:21] <pross-au> March ~ June
[08:23:24] <mru> oh
[08:24:45] <pross-au> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/090886.html
[08:29:32] <av500> pross-au: read between the lines, you are supposed to also write the "ass&utf8 subtitle renderer" :)
[08:31:20] <pross-au> There's something fundamentally wrong about ASS...
[08:31:42] <av500> :)
[08:31:54] <av500> it's advanced SSA, so why not ASSA?
[08:32:14] <pross-au> TLAs
[08:32:16] <mru> primitive minds can only hold 3 letters at a time
[08:32:32] <av500> wha?
[08:32:50] * elenril points at mru's nick
[08:32:53] <mru> hmm, they can handle 3 letters and 1 punctuation it seems
[08:33:06] <av500> hello tro
[08:33:18] <thresh> _tro, you meant
[08:33:27] <pross-au> goes back to using git and svn
[08:33:31] <av500> I'm primitive in my own way
[08:38:36] <av500> mru: bored?
[08:38:53] <mru> I've been looking for that text
[08:39:15] <mru> but it seems like someone went through great pains to excise it from the internets
[08:39:24] <av500> http://lists.xiph.org/pipermail/vorbis/2000-June/012621.html
[08:39:32] <av500> he has lost it...
[08:39:58] <mru> wow, so he's argumenting by appeal to a text _that nobody can read_?!!!
[08:41:06] <av500> well, its a well used pratice these days, ask the TSA on what legal basis they operate the no-fly list :)
[08:41:22] <mru> classified
[08:42:16] <pross-au> how did we get from ASS to OGG to TSA
[08:42:25] <pross-au> The link is tenuous at best
[08:44:47] <mru> pross-au: you're not on #vp8 I take it
[08:45:04] <pross-au> Nah, i'm good thanks
[08:45:31] <av500> pross-au: it's TLA day
[08:46:31] <av500> mru: can you please try to have a boring codec discussion, I'm trying to work over here :)
[08:52:59] <pross-au> mru: why not use sth like  hash://<filename>?algorithm={md5,sha1,etc.}
[08:53:15] <mru> pross-au: too fucking complicated
[08:53:39] <pross-au> well the algo can default to md5
[08:53:44] <pross-au> so it becomes hash://filename
[11:36:25] <mchinen> I keep getting crc = 0 after running av_crc on buffers that shouldn't pass the check.
[11:36:35] <mchinen> crc = av_crc(av_crc_get_table(AV_CRC_16_ANSI), 0, buf, buf_len_including_crc_at_end);
[11:38:05] <mchinen> is there something strange about this? (typo - I expect crc != 0 but get crc ==0)
[12:08:26] <astrange> http://pastebin.com/GqVBm8re what are you supposed to be sorting cachegrind by?
[12:08:35] <astrange> (giving up and using a sampling profiler is an ok answer)
[12:27:26] <av500> lu_zero: dont feed him
[12:33:56] <lu_zero> av500: but I have plenty of troll food!
[12:34:05] <lu_zero> btw
[12:34:23] <av500> he is not a troll, he is just plain annoying
[12:35:16] <lu_zero> astrange: you might be happier using a visualizator
[12:36:30] <ohsix> something going on on the ml again?
[12:36:56] <av500> no
[12:45:35] <mru> cruncher?
[12:45:41] <av500> yeah
[12:45:54] <mru> he's a bit annoying
[12:46:10] <av500> yes
[12:46:13] <mru> not much of a troll though
[12:46:20] <av500> [14:34] <av500> he is not a troll, he is just plain annoying
[12:46:35] <mru> that's why I guessed
[12:47:46] <av500> he has almost 3k posts at doom9....
[12:47:59] <mru> now count mine
[12:50:24] <av500> 10 billion
[12:50:50] <mru> I don't remember ever posting there
[12:50:55] <av500> :)
[12:51:07] <av500> I did not count his 3k *for* hime
[12:51:10] <av500> -e
[12:51:23] <av500> ppl that post to forums have too much free time
[12:51:52] <mru> I can't stand those forums
[12:52:08] <mru> especially not the posters with 3-page animated signatures
[12:52:24] <av500> on the archos uses ML, every 6 month one of them made a forum, most of them never to be heard of again
[12:52:27] <av500> users
[12:52:45] <av500> every time I asked the guys to make the forum email-capable
[12:52:45] * pJok points at mru for the art of trolling
[12:53:04] <av500> which seems to be physically impossible
[12:53:36] <mru> for those who run them, yes
[12:53:46] <av500> the most you get from all these phpBB clowns is an email notificiation
[12:54:12] <av500> why is it  hard to email the text of the post and accept and email reply to the same topic?
[12:54:32] <mru> then it would just be a mailing list
[12:54:40] <av500> :)
[12:54:43] <av500> it would be both
[12:55:07] <ohsix> forsooth; thats like putting content in an rss feed!
[12:55:25] <av500> -EIWANTITINMYMAILER
[12:55:39] <mru> rss is nothing but a poor reinvention of nntp
[12:56:25] <mru> with bigger ego
[12:56:46] <av500> rss sucks unless you have one centralized place that keeps your feeds
[12:56:55] <mru> exactly
[12:56:57] <av500> like an imap server for email
[12:57:00] <mru> at which point it becomes nntp
[12:57:32] <av500> mru: I mean, when I read one entry from SW-A I dont want it flagged as new in SW-B
[12:57:41] <pJok> av500, google reader
[12:57:46] <mru> google reader is nice
[12:57:49] <av500> pJok: and guess what I use
[12:57:59] <av500> and on the phone, I have the rss reader sync to gr
[12:58:02] <pJok> its the best invention since sliced bread
[12:58:12] <mru> google reader works fine on the phone too
[12:58:18] <pJok> i would be scared to sync up my phone with gr
[12:58:19] <av500> at which point it stops to be an rss client and is just a gr interface...
[12:58:31] <pJok> i use the google mobile reader site
[12:58:33] <pJok> works a treat
[12:58:43] <av500> iKnow
[12:58:44] <mru> pJok: I wish more countries than sweden had discovered sliced _cheese_
[12:58:55] <av500> mru: popular here too
[12:59:00] <mru> do they have cheese slicers in denmark?
[12:59:02] <lu_zero> mru: what's the discovery?
[12:59:05] <pJok> mru, it was norway who made the cheese slicer... but its a scandinavian thing
[12:59:17] <av500> mru: home sliced?
[12:59:27] * pJok had two instances of the cheese slicer
[12:59:35] <mru> http://upload.wikimedia.org/wikipedia/commons/6/6d/Osthyvel_20050723_001.jpg
[12:59:42] <av500> pJok: you freed one and the other segfaulted?
[12:59:43] <pJok> the norwegian one and the one with a pianowire
[12:59:51] <pJok> av500, something like that
[12:59:59] * pJok doesn't actually buy cheese that often anymore
[13:00:06] <av500> mru: kitchen stores have that, make great wedding gifts...
[13:00:16] <av500> "it's a uh oh cheese thingy, well thanks...."
[13:00:18] <pJok> i dont eat much at home so what ever stuff i keep in the fridge ends up getting too
[13:00:21] <pJok> old
[13:00:28] <lu_zero> mru: I have something similar as well
[13:00:33] <lu_zero> not just for cheese
[13:00:58] <mru> they can be found outside of scandinavia, but you have to look hard
[13:01:02] <mru> and most people don't have one
[13:01:20] <lu_zero> and I have also a tool specific for a certain type of cheese
[13:01:29] <lu_zero> that's more a sharder
[13:01:38] <mru> for parmesan?
[13:01:42] <lu_zero> yup
[13:01:43] <av500> chese fragmenter
[13:01:49] <mru> grater
[13:01:52] <lu_zero> no
[13:02:11] <mru> oh, to make little flakes?
[13:02:24] <av500> http://www.shop-016.de/shop_cfg/KingFood/14906.jpg
[13:03:42] <pJok> http://en.wikipedia.org/wiki/Cheese_slicer
[13:03:45] <lu_zero> http://i70.twenga.com/casa/coltello-da-parmigiano/coltello-per-formaggio-grana-tp_235849049034898396.png
[13:04:14] <lu_zero> av500: your image search skill is better than mine
[13:04:18] <av500> :)
[13:04:24] <lu_zero> anyway that is
[13:04:49] <av500> is it popular in italian crime shows?
[13:05:07] <pJok> mru, http://www.midtjyskudlejning.dk/billeder/s-ostehoevl.jpg my prefered one
[13:05:08] <lu_zero> how so
[13:05:15] <av500> "...he died from the parmesan knife in the forehead..."
[13:05:26] <lu_zero> nah
[13:05:43] <av500> "..so it was the drowning in concrete then..."
[13:06:03] <lu_zero> the crime object of the summer is the crowbar
[13:06:12] <lu_zero> and you are mixing stuff up
[13:06:20] <lu_zero> parmesan -> north
[13:06:31] <av500> yes, I mix concrete before I use it...
[13:06:37] <mru> with cheese?
[13:06:40] <lu_zero> people part of buildings and streets -> south
[13:07:00] <lu_zero> people using knives to sort out issues -> center
[13:07:11] <av500> they dont meet ever?
[13:07:12] <mru> I was always told to avoid getting any organic matter in the concrete mix
[13:07:36] <mru> av500: yes, in the middle, where they kill people by drowning them in cheese
[13:08:05] <av500> wasnt that in .CH?
[13:08:10] <lu_zero> av500: apparently the method do not mix even if they do business with
[13:08:15] <lu_zero> av500: in .ch is chocolate!
[13:08:28] <lu_zero> or they forget you in a safe
[13:08:40] <av500> they keep you safe...
[13:08:57] <lu_zero> or just use military grade weapons
[13:09:07] <pJok> military grade chocolate?
[13:09:07] <lu_zero> (with or w/out bullets)
[13:09:22] <lu_zero> pJok: interesting question
[13:09:33] <lu_zero> I had stories about military grade fondue
[13:09:47] <pJok> that required military grade cheese and chocolate?
[13:09:52] <pJok> sounds military delicious
[13:10:13] <lu_zero> fondue -> cheese and milk or cheese and wine (white)
[13:10:42] <lu_zero> I'm not so far from the border so it's a local recipe as well
[14:02:27] <CIA-99> ffmpeg: diego * r24304 /trunk/doc/faq.texi: Fix URL for ffv1, msmpeg4, asv1, 4xm docs.
[16:04:26] <kierank> hehe found another schrodingbug
[16:05:33] <av500> so its gone
[16:06:19] <kierank> my code should have crashed badly
[16:06:26] <kierank> by some miracle was working
[16:09:14] <mru> quick, call the vatican
[16:16:18] * BBB lacks context
[16:16:34] * av500 gives BBB 0x345DEF67
[16:16:46] <av500> careful, its a void*
[16:16:58] <BBB> is it stack of malloced?
[16:17:23] <av500> my stack here
[16:17:24] <mru> it's unaligned
[16:17:37] <BBB> it is
[16:17:44] <BBB> DEF70 would be aligned though
[16:17:51] <BBB> but might be out of range already if it's on the stack
[16:19:59] <jai> lol
[16:20:47] <jai> av500: maybe you caught him in a bad mood
[16:20:58] <av500> the stack?
[16:21:10] <BBB> Dark_Shikari: can you review my chroma inner loopfilter patch?
[16:21:17] <jai> michael that is
[16:21:18] <BBB> Dark_Shikari: I'm halfway the mbedge one already and don't want to hold this up too long
[16:21:28] <BBB> oh, regarding michael
[16:21:35] <BBB> that link that benjamin sent
[16:21:38] <BBB> suggests that he's on irc
[16:21:44] <BBB> I thought he wasn't?
[16:21:56] <mru> michael sometimes reads the logs
[16:22:20] * av500 waves to michael
[16:22:52] <BBB> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/17029/match=wolfgang+hesseler
[16:23:04] <BBB> ohwell
[16:23:09] <av500> ...that FFmpeg-based DOS multimedia viewer...
[16:24:12] <mru> hmm, reverse deja vu
[16:24:23] <jai> what do they use for video output?
[16:24:36] <mru> vga framebuffer I guess
[16:24:40] <mru> it's dos..
[16:25:03] <BBB> that's a pretty bad license violation
[16:25:12] <BBB> it mixes closed-source code with gpl code
[16:25:18] <av500> its a DOS attack, no?
[16:25:25] <BBB> return of the DOS
[16:25:38] <av500> denial of saticfaction
[16:27:19] <av500> he ask for money for that thing?
[16:27:24] <av500> asks
[16:29:21] <BBB> it's shareware
[16:29:22] <BBB> yeah
[17:08:08] <twnqx> else if ((size == 64) && (value & 0xFE) && !(value & 0x01)) /* 11111110 */ <-- sometimes i wonder
[17:10:46] <av500> 6
[17:12:17] <kierank> BBB: ok to PM?
[17:14:40] <BBB> yes
[18:21:32] <CIA-99> ffmpeg: jai_menon * r24305 /trunk/ffmpeg.c:
[18:21:32] <CIA-99> ffmpeg: FFmpeg : Replace some av_exit calls in av_transcode with branches to the
[18:21:32] <CIA-99> ffmpeg: cleanup code.
[18:21:32] <CIA-99> ffmpeg: This plugs a bunch of memleaks.
[18:33:49] <funman> kshishkov: do you want a .rso sample?
[18:34:23] <kshishkov> why not?
[18:36:44] <kierank> funman: is your .rso format the same as the wii's .rso format?
[18:36:56] <funman> kierank: no idea
[18:37:02] <kshishkov> maybe not
[18:37:18] * kshishkov remembers Intel IVF vs On2 IVF
[18:37:40] <funman> kierank: you have a sample / info on these files?
[18:38:05] <funman> kshishkov: http://pastie.org/1049533
[18:38:45] <kierank> funman: the wii rso is their equivalent of .so files
[18:38:56] <kierank> so no the same one then
[18:39:09] <kierank> not*
[18:39:15] <CIA-99> ffmpeg: mru * r24306 /trunk/libavformat/avio.c:
[18:39:15] <CIA-99> ffmpeg: Allow all valid (and only valid) characters in URL scheme for url_open()
[18:39:15] <CIA-99> ffmpeg: The URL specification allows letters, numbers, plus, hyphen, and period
[18:39:15] <CIA-99> ffmpeg: in the scheme part. The isalpha() test would allow additional characters
[18:39:15] <CIA-99> ffmpeg: depending on locale settings while rejecting numbers and punctuation.
[18:39:30] <_av500_> we still need the .elf demuxer
[18:39:46] <kshishkov> _av500_: send a patch
[18:40:06] <funman> _av500_: but first the x86 decoder?
[18:40:14] <mru> it would be apt for a troll to submit the elf demuxer...
[18:40:38] <_av500_> what is stopping said troll?
[18:41:05] <kshishkov> mru: trolling output for FFmpeg is good too
[18:44:13] <twnqx> _av500_: render it as a matrix screensaver?
[18:50:42] <_av500_> i think the apropriate x86 decoder in lavc would be qemu
[18:52:47] <funman> what would it decode to?
[18:54:20] <_av500_> printf
[18:54:34] <mru> _av500_: that's with the ascii-art backend
[18:54:38] <mru> it has sdl output too
[18:54:42] <mru> with full graphics
[18:54:50] <_av500_> yes
[18:55:01] <_av500_> and seek would be cool, like reverse debugging
[18:55:21] <kshishkov> funman: it decodes fine but looks like output is not full 16-bit audio but rather 8-bit
[18:55:21] <mru> forward seek?
[18:55:32] <mru> can you seek past the place where it crashes?
[18:55:41] <_av500_> hmm
[18:56:00] <funman> kshishkov: the converter i use might downsample it before encoding (especially since the other codec in rso is pcm u8
[18:56:31] <kshishkov> funman: this hack will convert rso from stdin to raw s16le at stdout - http://pastie.org/1049550
[18:56:50] <kshishkov> function for nibble decompressing is borrowed from FFmpeg
[18:56:58] <kshishkov> tables as well
[18:57:32] <funman> thx
[18:58:12] <funman> i'll look at it when the rso patch is deemed acceptable (one thing at a time)
[18:58:37] <mru> acceptable isn't good enough, it must be perfect
[18:58:42] <mru> lego is important stuff
[18:59:04] <funman> well i disagree
[18:59:11] <kshishkov> mru: danish blocks are important?
[18:59:21] <funman> what's nice with lego is build, break, repeat
[18:59:29] <funman> if it's perfect it'll just sit there and you won't have fun
[19:00:06] * mru preferred meccano though
[19:00:09] <mru> much sturdier
[19:00:32] <funman> did it have motors and such?
[19:00:52] <mru> we never had the official ones
[19:01:04] <mru> but we added some DC motors we obtained from somewhere
[19:04:20] <BBB> is there a mmx instr to expand a register of signed bytes to words?
[19:04:42] <Dark_Shikari> BBB: gj
[19:04:44] <Dark_Shikari> let me check it out
[19:05:01] <BBB> oh there he is :-p
[19:05:02] <BBB> hello
[19:05:10] <BBB> do you have a highlight on the word mmx or so? ;)
[19:06:42] <BBB> I guess pxor res, res; pcmpeqb res, x; and then SBUTTERFLY x, res, tmp?
[19:07:04] <BBB> or rather pcmpgtb, I guess
[19:07:05] <Dark_Shikari> BBB: movpx seems like a stupid acronym
[19:07:50] <BBB> movfullrow?
[19:07:58] <BBB> movrow maybe
[19:07:59] <Dark_Shikari> It looks pretty straightforward to me otherwise
[19:08:01] <Dark_Shikari> movrow, ok
[19:08:04] <Dark_Shikari> everything else ok
[19:08:33] <BBB> mbedge filter is mostly in-place already, will try to have it finished in 1-2 days
[19:08:36] <mru> what, no signed unpack?
[19:08:50] <BBB> I don't think mmx has signed byte->word
[19:09:41] <Dark_Shikari> Why do you need a sign-extending unpack?
[19:10:08] <mru> there are times when it's useful
[19:10:18] <Dark_Shikari> Yeah, but I imagine most cases it's avoidable
[19:14:41] <mru> why would you want to avoid it?
[19:14:53] <mru> if you have the instruction, surely using it is better
[19:16:29] <Dark_Shikari> mru: well duh
[19:16:34] <Dark_Shikari> I mean in most cases, lack of it on x86 isn't killer
[19:16:43] <Dark_Shikari> (unlike some other missing instructions, like vtrn)
[19:16:55] <mru> vtrn is fantastic
[19:17:03] <mru> and vzip/vuzp too
[19:17:27] <Dark_Shikari> so after this, 4 more functions
[19:17:34] <Dark_Shikari> mbedge V, mbedge H, mbedge chroma V, mbedge chroma H
[19:17:45] <Dark_Shikari> then we finish the edge emulation stuff yuvi started, unless he already committed
[19:17:53] <Dark_Shikari> then we merge my like-x264-deblocking patch
[19:18:05] <Dark_Shikari> then we turn deblock strength calculation into a LUT
[19:18:12] <Dark_Shikari> then we optimize the bloody cabac
[19:18:57] <Honoome> mru: no jokes about valgrind warnings and debian patches?
[19:19:16] <mru> heh
[19:19:34] <funman> mru: http://pastie.org/1049575 < is that worth doing it?
[19:19:54] <mru> no, __builtin_clz() already does the right thing
[19:20:22] <mru> I would've done something like that long ago if it didn't
[19:21:00] <funman> ah i hadn't spotted the definition in intmath.h
[19:26:02] <BBB> Dark_Shikari: mbedge_filter for vp8 is signed, and requires a mul*27/18/9 >> 7
[19:26:12] <BBB> with a +63 for rounding in there somewhere
[19:26:25] <Dark_Shikari> let me check that.
[19:26:26] <mru> no rounding shift?
[19:26:39] <BBB> ((w*27)+63)>>7
[19:26:52] <mru> is there no rounding shift instruction?
[19:26:57] <BBB> not that I know
[19:27:00] <Dark_Shikari> not on x86
[19:27:01] <BBB> but I don't know very much
[19:27:03] <mru> primitive
[19:27:03] <Dark_Shikari> It would be nice to have.
[19:27:10] <mru> neon has both kinds
[19:27:11] <Dark_Shikari> There are a few instructions that do have rounding
[19:27:20] <BBB> not to mention that vp8 is round-screwed
[19:27:21] <Dark_Shikari> pmulhrsw is actually potentially interesting here
[19:27:27] <BBB> it does +4>>3 in one case and +3>>3 in another
[19:27:29] <Dark_Shikari> pmulhrsw does the following
[19:27:34] <mru> vqrshrun is one of the best neon instructions
[19:27:37] <Dark_Shikari> each input value is treated as a signed 16-bit instruction
[19:27:44] <Dark_Shikari> er, signed 16-bit number
[19:27:54] <Dark_Shikari> er, bah, let me restate that
[19:28:00] <Dark_Shikari> the input values are 16-bit sigend FIX8
[19:28:03] <Dark_Shikari> *signed
[19:28:03] <BBB> I have the book here, I can look it up ;)
[19:28:07] <mru> shift signed value right with rounding and saturate unsigned to half width
[19:28:08] <Dark_Shikari> and the output is 16-bit signed FIX8
[19:28:17] <Dark_Shikari> and it does a multiplication with correct rounding
[19:28:32] <Dark_Shikari> wikipedia is better, probably loren wrote it:
[19:28:34] <Dark_Shikari> treat the sixteen-bit words in registers A and B as signed 15-bit fixed-point numbers between -1 and 1 (eg 0x4000 is treated as 0.5 and 0xa000 as -0.75), and multiply them together with correct rounding.
[19:28:57] <Dark_Shikari> Might be slightly wrong rounding for this case because of the bloody +63
[19:29:50] <Dark_Shikari> btw, you're planning to do the unpack-to-word after w = clip_int8(w + 3*(q0-p0)); right, BBB?
[19:29:58] <BBB> Dark_Shikari: right
[19:30:02] <BBB> that's what I need it for
[19:30:04] <Dark_Shikari> ok, in SSSE3, you can do this:
[19:30:07] <Dark_Shikari> fyi
[19:30:11] * BBB looks
[19:30:16] <Dark_Shikari> let xmm0 = w
[19:30:17] * BBB wants a ssse3 cpu :-p
[19:30:24] <Dark_Shikari> punpcklbw xmm0, [pb_1]
[19:30:32] <Dark_Shikari> pmaddubsw xmm0, {27, 63}
[19:30:43] <Dark_Shikari> psraw xmm0, 7
[19:30:52] <Dark_Shikari> this is one less op than the pmullw method.
[19:31:15] <Dark_Shikari> For the signed saturation, it might be faster to unpack the pixels, add to them, and repack.
[19:32:34] <BBB> ok, I'll check it out... let me first get a basic mmx one rolling ;)
[19:32:58] <Dark_Shikari> for mmx, I would do
[19:33:03] <Dark_Shikari> punpcklbw mm0, 0
[19:33:07] <Dark_Shikari> pmullw mm0, 27
[19:33:13] <Dark_Shikari> paddw mm0, 63
[19:33:16] <Dark_Shikari> psraw mm0, 7
[19:33:38] <BBB> well, it's signed, so it's a little more complicated
[19:33:45] <Dark_Shikari> pmullw isn't signed?
[19:33:53] <BBB> punpcklbw isn't signed
[19:33:54] <Dark_Shikari> Oh, you need to fix the punpcklbw
[19:33:58] <Dark_Shikari> ahhhhhhhhh I see your problem
[19:34:05] <Dark_Shikari> ok, in that case the ssse3 one is not one instruction better
[19:34:06] <BBB> probably mova mm1, mm0; pcmpgtb mm1, 0
[19:34:08] <Dark_Shikari> it's WAY better.
[19:34:13] <BBB> punpcklbw mm0, mm1
[19:34:35] <Dark_Shikari> nevermind, was confused for a second
[19:34:40] <BBB> or something like that
[19:34:46] <BBB> I'm probably mixing up somewhere ;)
[19:34:53] <Dark_Shikari> no, you're right
[19:35:21] <BBB> and then all the stuff you just said
[19:35:38] <Dark_Shikari> do everything as normal for mmx, except use that trick for the unpack
[19:35:42] <Dark_Shikari> is probably the best way.
[19:35:52] <Dark_Shikari> ssse3 is where it gets really interesting because of the addition of byte multiplies.
[19:36:24] <BBB> ok, will have it done in a few days
[19:36:28] <BBB> now gotta go to a party ;)
[19:54:23] <CIA-99> ffmpeg: cehoyos * r24307 /trunk/libavcodec/mpegaudiodec_float.c:
[19:54:24] <CIA-99> ffmpeg: Fix memleak when using mp*float decoder.
[19:54:24] <CIA-99> ffmpeg: Patch by flybird2k at gmail
[20:07:39] <CIA-99> ffmpeg: lorenm * r24308 /trunk/libavcodec/ (x86/fft_mmx.asm ppc/fft_altivec_s.S arm/fft_neon.S): more credits to D. J. Bernstein for fft
[20:18:43] <mchinen> ffplay stops calling av_read_frame as soon as url_feof(pb) returns true.  Is this incorrect?
[20:19:20] <mchinen> i have a flac parser that has a queue of frames that requires the user to keep calling read_frame after reaching the end of the file to get them
[20:19:34] <mru> it seems a bit wrong to me
[20:20:06] <CIA-99> ffmpeg: mru * r24309 /trunk/libavformat/ (md5proto.c Makefile allformats.c):
[20:20:07] <CIA-99> ffmpeg: Add MD5 protocol
[20:20:07] <CIA-99> ffmpeg: This is a write-only protocol which computes the md5sum of data written,
[20:20:07] <CIA-99> ffmpeg: and on close writes this to the designated output or stdout if none
[20:20:07] <CIA-99> ffmpeg: is specified. It can be used to test muxers without writing an actual
[20:20:07] <CIA-99> ffmpeg: file.
[20:20:08] <CIA-99> ffmpeg: mru * r24310 /trunk/tests/fate-update.sh: fate: do not delete ref files when updating tests from db
[20:20:11] <CIA-99> ffmpeg: mru * r24311 /trunk/tests/fate-run.sh: fate-run: rename some variables consistently with other files
[20:20:11] <CIA-99> ffmpeg: mru * r24312 /trunk/tests/ (fate.mak fate-update.sh fate-run.sh): fate: use our variable names in test rules imported from Mike's db
[20:20:11] <CIA-99> ffmpeg: mru * r24313 /trunk/tests/fate-run.sh: fate: apply TARGET_EXEC only to commands starting with absolute path
[20:20:11] <CIA-99> ffmpeg: mru * r24314 /trunk/tests/fate-run.sh: fate: add some helper functions to simplify test rules
[20:20:30] <mchinen> ok i'll submit that as a seperate patch
[20:20:53] <elenril> so...is a tar muxer next?
[20:22:32] <Dark_Shikari> RFC: libavcodec has no per-sequence TFF option
[20:22:34] <Dark_Shikari> only a per-frame TFF option
[20:22:41] <Dark_Shikari> x264 needs to know TFF at the start of encoding, before the first frame.
[20:30:56] <mru> Dark_Shikari: tff is a per-frame attribute
[20:30:59] <mru> it varies
[20:31:04] <mru> telecine
[20:31:11] <Dark_Shikari> No, that's not how telecine works
[20:31:16] <Dark_Shikari> for telecine, you have a per-frame pulldown flag
[20:31:23] <CIA-99> ffmpeg: mstorsjo * r24315 /trunk/libavformat/rtspenc.c: Include lavu headers using quotes instead of angle brackets
[20:31:23] <Dark_Shikari> i.e. an RFF flag
[20:31:26] <mru> hard telecine
[20:31:39] <mru> some idiots do that
[20:31:45] <Dark_Shikari> why would hard telecine have varying field order?
[20:32:03] <mru> err, I'm stupid, it's soft that varies
[20:32:11] <Dark_Shikari> soft is the one where it's resolved via RFFs though
[20:32:11] <mru> after you've repeated a field, the field order changes
[20:32:16] <Dark_Shikari> no it doesn't
[20:32:23] <Dark_Shikari> an RFF flag simply says "repeat this field on playback"
[20:32:28] <Dark_Shikari> it doesn't affect the bitstream
[20:32:38] <Dark_Shikari> in h264, the top vs bottom field is used in compression
[20:32:45] <Dark_Shikari> to determine how to scale motion vectors and such
[20:32:51] <_av500_> Dark_Shikari: congrat, you made c't magazine here in .de
[20:32:51] <Dark_Shikari> for weighted bipred, etc
[20:32:54] <_av500_> +s
[20:33:11] <kierank> what's c't magazine?
[20:33:12] <Dark_Shikari> so it is inherently wrong to use the wrong *FF flag
[20:33:14] <_av500_> vp8 article mentions your analys
[20:33:32] <_av500_> kierank: the only german computer magazine
[20:33:46] <Dark_Shikari> >vp8 article
[20:33:48] <Dark_Shikari> they're late.
[20:33:50] <Dark_Shikari> oh, they're a magazine.
[20:33:55] <Dark_Shikari> the Old Media
[20:34:01] <Dark_Shikari> mru: so what's the proper solution?
[20:34:03] <Dark_Shikari> do we modify the x264 API?
[20:34:20] <Dark_Shikari> x264 currently has two flags you can set:
[20:34:28] <Dark_Shikari> 1) pic struct flags (per frame, the h264 analog of RFF flags)
[20:34:34] <Dark_Shikari> 2) TFF/BFF (sequence-wide flag)
[20:35:26] <_av500_> kierank: h-online is also from them: http://www.h-online.com/open/news/item/FFmpeg-0-6-adds-WebM-VP8-support-1023584.html
[20:36:22] <mru> Dark_Shikari: suppose frame 1 has tff and rff
[20:36:35] <mru> then the second top field to be displayed is still from frame 1
[20:36:42] <Dark_Shikari> x264 doesn't care about what is displayed.
[20:36:47] <mru> the field after that, a bottom field, will be from frame 2
[20:36:50] <mru> hence frame 2 has bff
[20:36:51] <Dark_Shikari> er... no.
[20:36:53] <Dark_Shikari> wrong.
[20:37:08] <Dark_Shikari> "frame 1" is the first coded field, and the second coded field.
[20:37:11] <Dark_Shikari> x264 doesn't care what you display.
[20:37:14] <Dark_Shikari> it cares what you code.
[20:37:27] <Dark_Shikari> for example, frame 1 may have a TBT pic struct flag
[20:37:39] <Dark_Shikari> er, actually let me check the flag names
[20:37:57] <Dark_Shikari> ah ok, so a simple example
[20:38:01] <Dark_Shikari> PIC_STRUCT_TOP_BOTTOM_TOP
[20:38:05] <Dark_Shikari> display top, display bottom, display top
[20:38:13] <Dark_Shikari> that means you have 2 coded fields, 3 display fields.
[20:38:32] <Dark_Shikari> so frame 1 contains coded fields A and B
[20:38:32] <mru> yes
[20:38:36] <Dark_Shikari> which map to display fields A,B,C
[20:38:42] <Dark_Shikari> frame 2 contains coded fields C and D
[20:38:48] <Dark_Shikari> which map to display fields E and F (for example)
[20:38:56] <Honoome> why did I accept to work on rails, why?
[20:39:04] <mru> Honoome: warned you...
[20:40:53] <mru> for actually interlaced content, the field order is of course constant
[20:40:58] <Honoome> mru: I'm so close to just declaring myself bankrupt and go sell crap at mediamarkt =_=
[20:41:25] <mru> if you're coding progressive frames with pulldown flags, the field order is an invention for display purposes only
[20:41:38] <Dark_Shikari> mru: oh, I see where I went wrong
[20:41:40] <mru> Honoome: is it that bad?
[20:41:43] <Dark_Shikari> if you have pic struct, and you're using it for pulldown
[20:41:46] <Dark_Shikari> your content is PROGRESSIVE
[20:41:50] <Dark_Shikari> and there is no field order in the stream
[20:41:53] <Dark_Shikari> thus tff/bff don't even apply
[20:42:17] <mru> to the codec, no
[20:42:31] <Dark_Shikari> So the point is, you don't need tff/bff set per frame.
[20:42:36] <Honoome> mru: middleware over rails.. the doc is outdated, it no longer supports one of the two formats... yet they kept around the monkeypatching of the 3rd party library that did the processing
[20:42:47] <mru> Dark_Shikari: mpeg2 signals it per frame for display purposes
[20:43:12] <mru> I still don't see where the problem is
[20:43:44] <mru> why do you need to know the field order earlier than together with the first frame?
[20:44:23] <Dark_Shikari> Because the codec is initted before the first frame.
[20:44:34] <Dark_Shikari> Want to restructure ffmpeg to not require the header before the first frame?
[20:44:38] <mru> can't you defer that?
[20:44:57] <Dark_Shikari> for global header formats, it requests the header before the first frame, afaik
[20:45:07] <Dark_Shikari> Yup
[20:45:08] <Dark_Shikari> It does.
[20:47:38] <CIA-99> ffmpeg: mru * r24316 /trunk/tests/ (fate.mak fate-update.sh fate2.mak): fate: use helper functions in test rules
[20:47:39] <CIA-99> ffmpeg: mru * r24317 /trunk/tests/fate-run.sh:
[20:47:39] <CIA-99> ffmpeg: fate: simplify test runner slightly
[20:47:39] <CIA-99> ffmpeg: All tests use the provided helper functions so prepending $target_exec
[20:47:39] <CIA-99> ffmpeg: and using eval is no longer required.
[20:50:54] <CIA-99> ffmpeg: mru * r24318 /trunk/tests/fate-update.sh: fate: ensure all imported rules are handled by helpers
[21:14:45] <Dark_Shikari> patch review please
[21:14:47] <Dark_Shikari> http://pastebin.org/403140
[21:14:52] <Dark_Shikari> this is bugmaster's patch to make swscale not-broke on win64
[21:15:54] <mru> I predict michael will demand benchmarks with all compilers on all cpus
[21:16:01] <mru> and then reject it anyway
[21:16:19] <Dark_Shikari> how about I just commit it?
[21:16:22] <Dark_Shikari> and hope nobody notices
[21:16:36] <Dark_Shikari> It doesn't affect asm output on any arch that isn't broken
[21:16:41] <Dark_Shikari> and it fixes it on those where it is
[21:16:42] <mru> I think it should all be rewritten in yasm
[21:16:47] <Dark_Shikari> oh I agree
[21:18:06] <Dark_Shikari> ok, I'm going to give people a while to complain in irc before I commit.
[21:19:07] <mru> we also need to fix those damned xmm clobbers
[21:19:13] <Dark_Shikari> yes, but that doesn't affect swscale
[21:19:17] <Dark_Shikari> it doesn't use sse
[21:19:27] <mru> ought it not?
[21:19:32] <Dark_Shikari> it should yes
[21:19:37] <Dark_Shikari> but michael hasn't worke don it in years
[21:19:53] <mru> the code is so horrible to look at it makes my eyes bleed
[21:33:34] <Dark_Shikari> mru: fuck.  I can't commit it because I don't have mplayer repo commit access.
[21:34:01] <Dark_Shikari> mru: can you commit it with this commit message? http://pastebin.org/403233
[21:34:10] <mru> I can give you access
[21:34:18] <mru> I think that's fair
[21:34:34] <Dark_Shikari> ok
[21:34:35] <mru> michael was cross because mplayer devs didn't have automatic rights to ffmpeg
[21:34:41] <mru> and libsws is ffmpeg anyway
[21:34:49] <Dark_Shikari> ok
[21:35:25] <Honoome> mru: any comment about the dprintf vs posix thing? :P
[21:36:25] <mru> ff_dprintf
[21:37:58] <Dark_Shikari> mru: ping me when I have access
[21:38:20] <mru> hmm, you should have access already
[21:38:28] <Dark_Shikari> it's asking me for my password
[21:38:35] <Dark_Shikari> which I don't even remember because they insisted on making it like 25 characters
[21:38:44] <Dark_Shikari> making it less secure
[21:38:50] <mru> it's the same as ffmpeg
[21:38:54] <Dark_Shikari> I know.
[21:38:56] <mru> copy the svn credentials file
[21:39:07] <Dark_Shikari> where's that?
[21:39:17] <mru> ~/.subversion
[21:39:27] <Dark_Shikari> ah there it is
[21:39:36] <Dark_Shikari> lol, 22-character alphanumericsymbolic
[21:40:10] <Dark_Shikari> does it go to ffmpeg-cvslog?
[21:40:14] <mru> yes
[21:40:14] <Dark_Shikari> or will they bikeshed me on a different location
[21:40:15] <Dark_Shikari> ok
[21:43:07] <Dark_Shikari> well, it's in.
[21:44:50] <Dark_Shikari> now let's see if fate dies.
[21:44:57] <Dark_Shikari> does fate auto update for new swscale revs?
[21:44:59] <Dark_Shikari> or only ffmpeg revs?
[21:45:52] <mru> only ffmpeg I think
[21:46:00] <mru> commit something to trigger it
[21:46:00] <Dark_Shikari> so we need one more commit ;)
[21:46:03] <Dark_Shikari> lol
[21:46:07] * Kovensky sees nothing from CIA anywhere
[21:46:27] <Dark_Shikari> cia only tracks ffmpeg, not swscale
[21:46:47] <Kovensky> not in #mplayerdev either
[21:47:44] <mru> Dark_Shikari: cia tracks both
[21:47:49] <mru> but swscale is often delayed a lot
[21:47:54] <mru> no idea why
[22:01:42] <CIA-99> libswscale: darkshikari * r31751 /trunk/libswscale/swscale_template.c: (log message trimmed)
[22:01:42] <CIA-99> libswscale: Another try at fixing swscale on win64, as per r31153.
[22:01:42] <CIA-99> libswscale: Don't change paramater passing, but instead use casts.
[22:01:42] <CIA-99> libswscale: Shouldn't affect asm output on anything other than win64.
[22:01:42] <CIA-99> libswscale: libswscale should work on win64 now.
[22:01:43] <CIA-99> libswscale: The rest of ffmpeg still isn't win64 compatible due to the issue of xmm
[22:01:44] <CIA-99> libswscale: clobbers, but swscale doesn't use any SSE.
[22:21:04] <Tjoppen> finally back in umeå again. have to poke at that pix_fmt_descriptor export stuff tomorrow
[22:38:42] <CIA-99> ffmpeg: stefano * r24319 /trunk/libavfilter/ (avfilter.c avfilter.h internal.h):
[22:38:42] <CIA-99> ffmpeg: Make avfilter.c dprintf* functions internal and declare them in an
[22:38:42] <CIA-99> ffmpeg: internal.h header, so they can be easily used from other files.
[22:39:27] <mru> saste: ping
[22:40:41] <saste> mru: pong
[22:40:58] <mru> I'm looking at lavfi-regression.sh and I'm a bit confused
[22:41:15] <mru> the lavfi_pixdesc section
[22:41:22] <mru> ref_file=tests/ref/lavfi/lavfi_pixdesc
[22:41:28] <mru> rm -f $ref_file
[22:41:31] <mru> what's that all about?
[22:41:46] <saste> that's a clever trick ;-)
[22:41:52] <mru> no it's not
[22:41:59] <mru> you must never, ever write in the ref dir
[22:42:30] <saste> the idea is to create the reference using the reference of the unfiltered stuff
[22:42:47] <mru> the ref dir is for static reference files
[22:42:54] <mru> _never_ write to it
[22:42:56] <saste> which needs to be the same as the output issued by the files filtered with pixdesctest
[22:43:09] <saste> I considered the issue...
[22:43:15] <mru> not enough
[22:43:25] <mru> it's also failing to run at all
[22:43:26] <saste> the alternative I suppose is to provide the reference
[22:43:33] <saste> ??
[22:43:46] <mru> tests/ref/lavfi/lavfi_pixdesc: No such file or directory
[22:44:45] <saste> I suppose that will happen if you don't have permission to write there...
[22:46:01] <mru> but you're not allowed to write there
[22:46:03] <mru> I told you that
[22:46:08] <saste> anyway fate never complained about that, and the pixdesc test is enabled since the first commit of pixdesctest
[22:46:18] <mru> those tests aren't run by fate
[22:46:24] <mru> because they don't work
[22:46:29] <mru> I'm trying to fix that
[22:46:55] <saste> can you confirm that's a permission problem?
[22:47:04] <mru> it's a directory not existing problem
[22:47:13] <mru> try building outside the source dir
[22:47:30] <mru> but that's beside the point
[22:47:36] <mru> DO NOT WRITE TO THE REF IR
[22:47:38] <mru> DIR
[22:48:04] <saste> yes... I already get that... just trying to understand what's failing
[22:48:20] <mru> tests/ref doesn't exist in the build dir
[22:49:23] <saste> let me think about that... I'll try to come with a solution tomorrow
[22:49:56] <mru> just check in the ref file
[22:50:29] <saste> the reason for which I started to write in the ref dir is that I needed to write a reference *depending on the supported pixel formats*
[22:50:40] <saste> which depend on the machine endiannes
[22:50:50] <mru> hmm
[22:50:55] <saste> that's why I couldn't have a static reference file
[22:51:11] <mru> you're still not allowed to write to the ref dir
[22:51:41] <saste> ok but in that case I need to find an alternative solution
[22:52:07] <saste> the brute force solution would be to implement support for all pixfmt in both LE/BE
[22:52:52] <mru> or choose the ref depending on endianness
[22:53:14] <mru> make two tests
[22:53:18] <saste> seems feasible
[22:53:21] <mru> lavfi_pixdesc_le and _be
[22:53:36] <mru> make one depend on bigendian and the other on !bigendian
[22:54:28] <mru> also, why is that test prefixed lavfi_ ?
[22:54:33] <mru> none of the others are
[22:54:43] <saste> BTW the reason for which I didn't committed the other 1-1 lavfi test is that it is failing on LE (i.e. your PPC machine)
[22:55:16] <saste> well that was a namespace problem...
[22:55:39] <mru> I don't see anything else called pixdesc
[22:56:03] <saste> let me recall... I was addressing a specific problem... that or I tried to be future-proof
[22:58:26] <saste> there is a test pixfmt in the lavf tests
[22:58:55] <saste> then I added the pix_fmts test... since I wanted to avoid potential confusion I decided to add the prefix lavfi
[22:59:18] <saste> that was to distinguish regtest-pixfmt from regtest-lavfi_pix_fmts
[22:59:19] <mru> I see
[23:02:44] <saste> anyway... leave me some days to fix the pixdesctest test issue... then feel free to blame me on ML or ping me here
[23:30:30] * Kovensky wonders what would be a good read on DSP (mainly audio stuff for gsoc)