[FFmpeg-devel-irc] IRC log for 2010-08-17

[irc at mansr.com]

[05:25:09] <thresh> moroning
[07:18:13] <KotH> salut
[07:18:39] <elenril> воистину салют
[07:23:45] <kshishkov> таки да
[07:38:15] <siretart> morning
[07:38:23] <kshishkov> god morgon
[07:47:00] <CIA-93> ffmpeg: cehoyos * r24800 /trunk/ffplay.c:
[07:47:01] <CIA-93> ffmpeg: Move do_exit() up for upcoming patch.
[07:47:01] <CIA-93> ffmpeg: Patch by Mike Scheutzow, mjs973 optonline net
[07:47:42] <merbzt> is it possible to create a big sliced based h264 stream from multiple small h264 streams ?
[07:48:00] <merbzt> ie without a full decode/recode step ?
[07:48:26] <kshishkov> probably yes
[07:48:34] <CIA-93> ffmpeg: cehoyos * r24801 /trunk/ffplay.c:
[07:48:35] <CIA-93> ffmpeg: Fix SDL crash on specific hardware.
[07:48:35] <CIA-93> ffmpeg: Patch by Mike Scheutzow, mjs973 optonline net
[08:07:20] <xxthink> does someone debug libmpeg2?
[08:08:01] <KotH> the answer to that question is most probably yes
[08:08:20] <xxthink> KotH: I can't find the debug options
[08:08:23] <saintdev> let's see if we can go a whole day answering every question "probably yes"
[08:08:38] <xxthink> ./configure --enable-debug?
[08:08:43] <xxthink> only this options?
[08:09:47] <xxthink> ./configure --enable-debug, then make and gdb mpeg2dec?
[08:09:53] <xxthink> is this right? Ko
[08:10:09] <spaam> try and find out
[08:10:16] <KotH> xxthink: probably yes
[08:10:21] <KotH> saintdev: probably yes :)
[08:11:10] <saintdev> lol
[08:13:08] <xxthink> KotH: I can't step into the libmpeg2 lib is following the commands which I just print
[08:14:06] <CIA-93> ffmpeg: cehoyos * r24802 /trunk/ffplay.c: Mention lowres if SDL can't provide the needed resolution.
[09:51:32] <Tjoppen> ffplay should support -programid methinks
[09:52:03] <Tjoppen> lunch.
[09:55:03] <spaam> Tjoppen: bring some food to me also )
[09:55:21] * kshishkov won't say no to Swedish food as well
[10:39:02] <merbzt> kshishkov: forgot to say but your package is in the mail
[10:39:11] <merbzt> sent it last saturday
[10:40:24] <kshishkov> yay!
[10:40:45] <kshishkov> tack så mycket
[10:56:02] <merbzt> should be there in 1-3 days
[10:56:13] <merbzt> hopefully the cheese is still ok
[11:00:37] <kshishkov> well, it's not that warm here
[11:01:22] <kshishkov> (and it still sounds better than 10-days delivery to certain third-world country)
[11:07:50] <KotH> .o0(#ffmpeg-devel, where people deal with chocolate and cheese)
[11:08:16] <merbzt> and trocadero
[11:08:24] <mru> the important things in life
[11:09:09] <merbzt> kshishkov: http://op.se/ettan/extralasning/lordag/1.2061030--det-finns-de-som-kallar-sig-for-trocaholister-
[11:10:23] <Tjoppen> :)
[11:13:55] <mru> hey look, os/2 on fate
[11:14:01] <Dark_Shikari> LOL
[11:14:12] <mru> and it passes all the tests
[11:14:31] <Dark_Shikari> guess that makes it better than BSD
[11:14:40] <mru> bsd passes now
[11:17:56] <kshishkov> merbzt: guess why I want to visit Sundsvall?
[11:18:21] <merbzt> visit Vasa bryggerier :)
[11:18:36] <kshishkov> at least sample its production :)
[11:19:05] <kshishkov> I'm pretty sure even you won't refuse few bottles of Trocadero from there
[11:20:09] <merbzt> Dark_Shikari: do you know if it is possible to take several small h264 streams and merge them to a slicebased stream without doing a full decode/encode cycle ?
[11:23:44] <kshishkov> I suspect there may be a problem with out of bounds MVs but the rest may work fine
[11:25:34] <mru> hmm, MVs around the edges would be a problem
[11:25:56] <mru> crossing a slice edge is not the same as going off the picture
[11:26:46] <merbzt> lets say we can control the encoded stream
[11:27:06] <merbzt> would it be possible to never generate those kind of motion vectors
[11:27:11] <mru> if you can restrict the MVs to be entirely within the frame, you should be good
[11:27:12] <kshishkov> of course
[11:27:52] <kshishkov> mru: left/right out-of-bounds MV should not matter in this case
[11:27:59] <mru> of course
[11:28:08] <mru> only edges that become internal after merging
[11:29:59] <kshishkov> mru: why do I think of your videowall ideas after reading all this?
[11:30:35] <mru> that would need fmo as well
[11:31:32] <kshishkov> well, inversed - H.264 stream with fully independent picture slices
[12:29:33] <KotH> who of our italian friends is responsible for  ammin4-195.ltt.it [195.120.125.26] ?
[13:08:17] <lu_zero> not me I think
[13:40:11] <Honoome> KotH: somebody around Parma... aka not me
[13:43:43] <KotH> hmm..
[13:43:54] <KotH> it's someone who runs a fate node
[13:43:57] <kshishkov> could be some other Diego if he changed ISP
[13:44:58] <KotH> it doesnt have to be a diego
[13:44:59] <mru> none of the fate machines are there afaik
[13:45:05] <KotH> hmm..
[13:45:40] <mru> they're run by me, michael kostylev, mike, ramiro, jeff downs, and dave yeo
[13:48:03] <mru> and none of them uses that IP
[13:48:13] <mru> or anything near it
[13:49:52] <KotH> hmm^2..
[13:50:38] <mru> nobody in italy even
[13:54:06] <KotH> hmm^3..
[13:55:38] <lu_zero> ^^;
[13:59:10] <Vitor1001> mru: who is the owner of the slot x86_32-macosx-gcc-4.0.1?
[13:59:17] <Vitor1001> mru: He needs to rsync
[13:59:19] <mru> mike
[13:59:54] <Vitor1001> ok, will write him.
[14:00:22] <BBB> how do I use fate? make fate doesn't appear to test very much
[14:00:39] <mru> BBB: you probably don't have the samples then
[14:00:46] <BBB> I configured with --samples=
[14:01:11] <mru> blank?
[14:01:11] <BBB> ah I indeed don't have all samples
[14:01:16] <BBB> no, with a dir
[14:01:21] <BBB> how did rsync work again?
[14:01:43] <Vitor1001>   rsync -aL rsync://rsync.mplayerhq.hu:/samples/fate-suite/ fate/fate-suite
[14:01:49] <Vitor1001> BBB: BTW, how is xp8 going?
[14:02:43] <BBB> little slow, I'm trying to figure out a license violation for now, and spent a little time on h264 zero-mv optimizations yesterday also
[14:02:46] <BBB> but it's ongoing
[14:03:14] <Vitor1001> :)
[14:03:44] <BBB> this isn't working
[14:03:49] <BBB> rsync says I have all files up to date
[14:03:56] <BBB> yet the first test (4xm) fails
[14:04:39] <Vitor1001> BBB: try "make fate SAMPLES=/home/you/path/to/your/samples"
[14:04:50] <Vitor1001> BBB: Be careful not to use "~" in the path
[14:05:07] <KotH> Vitor1001: please add -W too
[14:05:10] <BBB> ahhhhhh
[14:05:13] <BBB> yes I use ~
[14:05:14] <BBB> why can't I?
[14:05:21] <Vitor1001> KotH: What is -W supposed to do?
[14:05:26] <Vitor1001> BBB: no idea, ask mru.
[14:05:27] <BBB> shouldn't the shell expand it?
[14:05:34] <KotH> Vitor1001: whole file transfere -> do not checksum the file
[14:05:51] <KotH> Vitor1001: has the advantage that it uses less cpu on the server :)
[14:06:23] <CIA-93> ffmpeg: aurel * r24803 /trunk/libavformat/matroskadec.c:
[14:06:23] <CIA-93> ffmpeg: matroskadec: fix integer overflow
[14:06:23] <CIA-93> ffmpeg: patch from reimar
[14:06:24] <Vitor1001> KotH: Ok, I see. Indeed, our files are not big enough for this to be worth it.
[14:06:49] <KotH> even if they are, bw is cheaper than cpu
[14:07:02] <KotH> and if the developers use a bit of bw, i dont care at all
[14:07:33] <KotH> cpu is more limited resource and if we run out of it, it can have strange and nasty sideeffects
[14:07:38] <Vitor1001> KotH: ok. Maybe it would be worth to write a note the fate mailing list asking for people to use -W?
[14:07:45] <KotH> mru: ?
[14:08:15] <mru> feel free
[14:08:18] <mru> the list is open
[14:08:40] * KotH doesnt want to subscribe to yet another video coding mailinglist he doesnt read
[14:08:49] <mru> it's low volume
[14:08:53] <KotH> i'm already on a dozen or two
[14:09:05] <KotH> they are all low volume
[14:09:56] <BBB> "/Users/ronaldbultje/Projects/ffmpeg-svn"/tests/fate-run.sh fate-4xm "/Users/ronaldbultje/Movies/fate-suite" "" "/Users/ronaldbultje/Projects/ffmpeg-svn" 'md5  -i /Users/ronaldbultje/Movies/fate-suite/4xm/TimeGatep01s01n01a02_2.4xm -f s16le' '' '' ''
[14:09:59] <BBB> wht doesn't that work?
[14:10:05] <BBB> I guess it's because the movie isn't there
[14:10:12] <BBB> how do I convince rsync to put it there?
[14:10:55] <BBB> rsync -Pvrt samples.mplayerhq.hu::samples/fate-suite . isn't right?
[14:13:22] <Vitor1001> BBB: rsync gives no error?
[14:13:31] <BBB> it tells me it succeeded
[14:13:43] <Vitor1001> BBB: I use "rsync -aLW rsync://rsync.mplayerhq.hu:/samples/fate-suite/ fate/fate-suite"
[14:17:36] <BBB> ah now it's downloading
[14:17:42] * BBB kicks rsync
[14:26:08] <CIA-93> ffmpeg: aurel * r24804 /trunk/libavformat/matroskadec.c:
[14:26:08] <CIA-93> ffmpeg: matroskadec: minor simplification
[14:26:08] <CIA-93> ffmpeg: patch from reimar
[14:52:40] <DonDiego> moin
[14:52:45] <DonDiego> mru: http://pastebin.com/V3wuDg4M
[14:54:48] <mru> why?
[14:55:11] <DonDiego> because we no longer have rules for .d files..
[14:56:01] <mru> ok
[14:59:38] <CIA-93> ffmpeg: diego * r24805 /trunk/Makefile:
[14:59:38] <CIA-93> ffmpeg: Skip adding SDL_CFLAGS to CFLAGS for the ffplay.d target.
[14:59:38] <CIA-93> ffmpeg: We no longer create .d files directly, so the rule is pointless.
[14:59:38] <CIA-93> ffmpeg: stefano * r24806 /trunk/ (9 files in 5 dirs): Add hflip filter.
[15:00:04] <DonDiego> and that was another leftover..
[15:00:28] <mru> thanks
[15:03:33] <CIA-93> ffmpeg: diego * r24807 /trunk/common.mak:
[15:03:34] <CIA-93> ffmpeg: Remove dep/depend targets and related variables.
[15:03:34] <CIA-93> ffmpeg: We no longer create dependency files directly, so the rules are now pointless.
[15:04:43] <Vitor1001> saste: One less to go :D
[15:09:09] <BBB> yay, fate works for me now
[15:09:50] <BBB> saste: nice work on avfilter! :)
[15:10:30] <saste> ehehe and is just the beginning!!
[15:10:58] <saste> now i'm working an audio integration... soon i'll commit the patch
[15:11:10] <BBB> I really like it, it's got a very pretty design, basically a gstreamer-esq idea of plugging stuff together, but then without all the shit
[15:13:08] <DonDiego> btw
[15:13:13] <CIA-93> ffmpeg: stefano * r24808 /trunk/libavfilter/avfilter.c: Add missing NULL checks in avfilter_ref_buffer().
[15:13:13] <CIA-93> ffmpeg: stefano * r24809 /trunk/libavfilter/defaults.c: Add missing checks in avfilter_default_get_video_buffer().
[15:13:17] <DonDiego> i think all of you should register on ohloh.net
[15:13:29] <DonDiego> http://www.ohloh.net/p/ffmpeg/contributors
[15:14:01] <DonDiego> but afaict most of you haven't yet..
[15:19:12] <DonDiego> saste: go ahead and click the 'i am this person' button...
[15:19:23] <DonDiego> saste: won't take you more than five minutes :)
[15:21:35] <KotH> great... race condition in usb code caused by running of a virus scanner...
[15:21:41] * KotH blames spaam 
[15:22:00] <spaam> what did i do this time?
[15:23:51] <lu_zero> virus scanner?
[15:23:58] <lu_zero> j0sh: poing
[15:26:56] <KotH> spaam: enough to deserve the blame
[15:27:49] <KotH> lu_zero: the usb bug i'm hunting, this morning i figured out (quite by accident) that it is a race condition. a few minutes ago, the virus scanner informed me that its background task finished... now i cannot trigger the race condition anymore
[15:28:49] <kshishkov> run it again then :)
[15:31:14] <BBB> DonDiego: I'm on there
[15:33:19] <KotH> kshishkov: as i said, i cannot trigger it anymore
[15:33:30] * KotH curses, then blames spaam again
[15:34:45] <spaam> fail KotH
[15:43:35] <saste> DonDiego: account created
[15:43:39] <DonDiego> :)
[15:45:37] <lu_zero> KotH: windows and development do not mix well
[15:45:54] <lu_zero> the problem is that the bug exists AND
[15:46:14] <lu_zero> you need to probably load the bus to reproduce =P
[15:49:02] <DonDiego> kshishkov: no interest in joining?
[15:49:09] <DonDiego> saste: why not use your real name?
[15:50:49] <saste> DonDiego: done
[15:53:34] <xxthink> does a PES packet must start with the start code?
[15:53:50] <xxthink> the start code is 0x000001
[15:53:51] <mru> what a silly question
[15:54:35] <xxthink> mru: I find some pes packet doesn't contain the start code
[15:54:52] <xxthink> but just as the iso13813-1 says
[15:55:01] <xxthink> the pes code start with a start code
[15:55:20] <mru> if it doesn't start with a start code, it's not a pes packet
[15:55:23] <mru> simple as that
[15:56:54] <xxthink> http://pastebin.org/568406
[15:57:02] <xxthink> this is the output of my ts stream.
[15:57:11] <xxthink> perhaps the first packet is an error packet
[15:58:16] <mru> more likely a PSI packet
[16:00:31] <KotH> lu_zero: windows doesnt mix well with anything
[16:01:06] <KotH> lu_zero: the prob is, there is no complete test enviroment for usb...neither on windows nor on linux... actually there are less tools to test usb on linux than on windows
[16:01:33] <lu_zero> libusb doesn't provide anything useful?
[16:05:16] <DonDiego> btw, is anybody going to froscon?
[16:06:23] * mru isn't
[16:07:20] * lu_zero cannot =|
[16:07:48] * KotH not
[16:07:54] <KotH> no time no money
[16:08:33] * mru converted his time to money
[16:09:54] <funman> time is money, s is $
[16:10:21] <mru> of course, that's how I was able to convert it
[16:10:42] * KotH would not accept any $ as payment
[16:11:09] <spaam> KotH: you can get SEK ;)
[16:11:13] * funman looks for the 'narco dollar' unicode character
[16:11:36] <funman> i'll just go with âš—$
[16:11:51] <lu_zero> uhm?
[16:11:57] <lu_zero> it doesn't parse here
[16:13:10] <KotH> spaam: quite worthless as well.. at least in .ch
[16:14:01] <funman> lu_zero: âš— ?
[16:14:05] <spaam> KotH: but you can buy trocadero for it in .se  then kshishkov will be jealous ;)
[16:14:25] <funman> U+2697 ALEMBIC = chemical term, chemistry
[16:14:26] <KotH> i eat only good food
[16:15:33] <lu_zero> KotH: when you'll pass by torino?
[16:15:50] <lu_zero> we have plenty of slow-food place you might like
[16:17:26] <KotH> :-)
[16:17:51] <KotH> i doubt i'll travel much in the next months/years
[16:18:07] <KotH> though, torino shouldnt be too expensive to reach
[16:25:16] <lu_zero> ^^
[16:41:13] <lu_zero> BBB: there is something I'm not getting
[16:41:29] <lu_zero> you changed function_tab[x]=function_x
[16:42:11] <lu_zero> to function_tab[x][{0,1,2,3}]=function_x
[16:46:06] <DonDiego> bye
[17:08:49] <xxthink> Questions on the sycronization of a TS stream.
[17:09:26] <xxthink> when trascoding a ts stream, first I look for the PCR flag in the TS stream and find it . the PCRID is the video stream in the TS
[17:09:48] <xxthink> then I can know the PTS of the video frame
[17:10:00] <mru> no
[17:10:02] <xxthink> But how to calculate the time of the audio stream?
[17:10:08] <xxthink> why?
[17:10:14] <mru> that's not how it works
[17:10:40] <xxthink> pls more detail, mru.
[17:10:46] <mru> read the spec
[17:11:24] <xxthink> I am reading the spec now and don't know whether I understand it correctly
[17:11:46] <mru> then keep reading
[17:11:52] <xxthink> :)
[17:19:00] <lu_zero>    mpegts is that complex?
[17:19:17] <mru> no
[17:28:18] <BBB> lu_zero: yes
[17:28:30] <BBB> lu_zero: that allows me to write differently optimized versions depending on the arguments
[17:28:37] <BBB> lu_zero: by default I can set them all to the slow version
[17:28:49] <BBB> lu_zero: but I cna make some faster than others because they have different constraints
[17:28:59] <BBB> vp8 uses it also, speedup is very significant
[17:33:08] <lu_zero> I missed the place where you set it
[17:34:33] <lu_zero> put_rv40_chroma_pixels_tab gets something different
[17:35:26] <BBB> what do you mean?
[17:35:40] <BBB> the one where I set [0][0]?
[17:35:49] <BBB> that's the same as the qpel ones above
[17:36:04] <BBB> the idea is to not have to implement the pixel_copy function for each subversion of h264
[17:36:08] <BBB> because it's identical
[17:36:50] <lu_zero> BBB: I was expecting to have the h264 function table containing variations ^^
[17:37:00] <BBB> it will
[17:37:04] <BBB> but that takes time to write
[17:37:06] <BBB> this is just setup
[17:37:10] <BBB> after this we can speed it up
[17:37:14] <BBB> unless you want a 200k patch
[17:37:19] <lu_zero> that's what fooled me =)
[17:37:23] <BBB> heh :)
[17:37:31] <lu_zero> since for rv40 you got changes
[17:37:36] <BBB> yes
[17:37:42] <BBB> they have no noticeable effect
[17:38:40] <kshishkov> who mentioned the deepest shit?
[17:39:24] <kshishkov> you should know that motion compensation in RV40 is a bit "strange"
[17:39:38] <lu_zero> as in painful?
[17:39:50] <kshishkov> as in idiotic
[17:39:56] <BBB> kshishkov: not the fullpel one
[17:40:11] <BBB> the fullpel would be identical to h264 and any other codec
[17:40:28] <kshishkov> yes, for *any* codec in existence :)
[17:41:23] * kshishkov should finally implement weighted MC for RV40 B-frames
[17:55:43] <j0sh> lu_zero: ping
[17:57:17] <lu_zero> j0sh: pong
[17:57:31] <j0sh> sup
[17:57:46] <j0sh> you poinged earlier?
[18:00:13] <lu_zero> I did, but apparently I forgot what to ask you
[18:00:40] * lu_zero is staring at mesa crashing, expedite crashing and other random stuff at the same time
[18:02:09] <j0sh> mesa?
[18:03:21] <lu_zero> yup
[18:03:43] <lu_zero> gallium seems to have some problems with its loader
[18:08:29] <j0sh> oh, 3d stuff
[18:08:57] <lu_zero> yup
[18:08:59] <lu_zero> sort of
[18:09:14] <CIA-93> ffmpeg: stefano * r24810 /trunk/tools/lavfi-showfiltfmts.c: Set the correct type for the output links.
[18:09:14] <CIA-93> ffmpeg: stefano * r24811 /trunk/libavfilter/ (formats.c avfilter.c avfilter.h defaults.c):
[18:09:14] <CIA-93> ffmpeg: Implement libavfilter audio framework.
[18:09:14] <CIA-93> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram * smeenaks * ucsd * edu *.
[18:09:15] <CIA-93> ffmpeg: stefano * r24812 /trunk/libavfilter/defaults.c: Cosmetics: apply misc style fixes.
[18:14:03] <CIA-93> ffmpeg: stefano * r24813 /trunk/doc/APIchanges:
[18:14:04] <CIA-93> ffmpeg: Add APIchanges entry after libavfilter audio framework addition of
[18:14:04] <CIA-93> ffmpeg: r24811.
[18:26:24] <CIA-93> ffmpeg: stefano * r24814 /trunk/ (4 files in 2 dirs):
[18:26:24] <CIA-93> ffmpeg: Define macro AV_NE() and use it in libavdevice.
[18:26:24] <CIA-93> ffmpeg: Help further refactoring.
[18:28:43] <CIA-93> ffmpeg: stefano * r24815 /trunk/doc/APIchanges: Add APIchanges entry after the addition of AV_NE in r28814.
[18:43:22] <Vitor1001> saste: FATE didn't like your patch :(
[18:43:39] <saste> I know i'm looking at it :-(
[18:46:14] <mru> perhaps testing would have been a good idea
[18:46:33] <peloverde> saintdev: AACX has been updated
[18:46:43] <saintdev> peloverde: cool
[18:48:53] <saste> mru: what the hell is working here...
[18:49:07] <saste> maybe the missing "libavutil/" ?
[18:49:37] <peloverde> Scalefactor display should be working now for short windows
[18:49:45] <CIA-93> ffmpeg: mru * r24816 /trunk/libavutil/common.h: Fix out-of-tree build
[18:57:43] <saintdev> peloverde: seems to be \o/
[18:58:49] <saste> mru: thanks
[19:16:40] <kshishkov> peloverde: http://codecs.multimedia.cx/?p=297 fourth abstract :)
[19:17:37] <peloverde> lol
[19:19:55] <Vitor1001> kshishkov: If you ever visit paris, write me an email so I can pay you a beer
[19:20:16] <kshishkov> Vitor1001: no use, I don't drink beer
[19:21:00] <Vitor1001> kshishkov: or some stinking cheese ;)
[19:22:29] <kshishkov> I'm pretty sure French have some romantic name for it
[19:24:10] <kierank> fromage?
[19:24:39] <kshishkov> could be, I'm not very romantic
[19:24:44] <Vitor1001> kshishkov: depends on the cheese. The names vary wildly (some not so romantic, actually)
[19:25:08] <kshishkov> Vitor1001: I know, named mostly after places
[19:25:09] <Vitor1001> "crottin de chèvre" commes to mind (goat dung)
[19:25:29] <Vitor1001> http://languagelog.ldc.upenn.edu/nll/?p=2320
[19:26:12] <Vitor1001> I
[19:26:47] <Vitor1001> I'm sure it is not a coincidence this name it only used for very small, solid cheese.
[19:27:00] <kshishkov> there's German-invented alcoholic beverage with French name that was widely popular in USSR
[19:27:29] <Vitor1001> lol
[19:27:33] <kshishkov> I'm pretty sure you've heard about it - Eau de Cologne
[19:27:43] <Vitor1001> yes
[19:28:32] <kshishkov> I heard that some crazy guys used it as a parfume instead of drinking it
[19:28:34] <Vitor1001> things named in languages foreign to the inventors have typically more fishy names
[19:31:10] <CIA-93> ffmpeg: aurel * r24817 /trunk/libavformat/ (mpegts.c nutdec.c avformat.h): add LAVF_API_MAX_STREAMS define to disable the deprecated MAX_STREAMS API
[19:40:24] <peloverde> Is there any good yasm samplecode that deals with struct offsets?
[19:40:57] <mru> peloverde: I don't think there's anything to help you
[19:41:24] <peloverde> http://www.tortall.net/projects/yasm/manual/html/nasm-stdmac.html Section 4.8.4 seems useful
[19:42:00] <mru> there's no guarantee you'll match the C compiler's idea of a struct
[19:43:35] <peloverde> Struct rules have to be part of the ABI, no? Scructs often live in installed headers
[19:43:48] <mru> the C ABI, yes
[19:43:53] <mru> yasm isn't C
[19:44:14] <peloverde> calling conventions are part of the C ABI and yasm has to deal with those
[19:44:31] <mru> but this struct is not passed as a parameter
[19:44:36] <mru> only a pointer to it is passed
[19:45:06] <peloverde> yes, but if yasm's C ABI support can include calling conventions, I don't see why it can't include structs
[19:45:37] <mru> I didn't know yasm had any C-specific support whatsoever
[19:46:04] <mru> and those names you pointed at don't match C types either
[19:48:48] <peloverde> It seems like at worst I could macro it with manual padding
[19:48:58] <mru> beware of pointers
[19:50:38] <spaam> scary things
[19:52:38] <Dark_Shikari> see common/x86/cabac-a.asm for an example of dealing with pointers in yasm
[19:52:40] <Dark_Shikari> in x264
[19:52:43] <Dark_Shikari> for a simple struct.
[19:52:43] <peloverde> thanks
[19:52:51] <Dark_Shikari> Oh, and it also deals with DECLARE_ALIGNED.
[20:24:08] <CIA-93> ffmpeg: aurel * r24818 /trunk/libavformat/ (6 files): add LAVF_API_OLD_METADATA define to disable the deprecated metadata API
[20:37:12] <CIA-93> ffmpeg: mru * r24819 /trunk/tests/fate.sh:
[20:37:12] <CIA-93> ffmpeg: fate: store last version in per-slot file
[20:37:12] <CIA-93> ffmpeg: This allows the same workdir to be used by multiple slots.
[20:46:43] <BBB> h264dsp_mmx.c is a little messy (?)
[20:48:30] <Dark_Shikari> "little"
[20:48:50] <BBB> hehe I knew he'd reply ;)
[20:49:14] <BBB> maybe we should rewrite it in yasm like we did for vp8dsp
[20:57:05] <mru> that would be awesome
[20:57:42] <peloverde> ok, how do I call one cglobal from inside another?
[20:57:51] <mru> call foo?
[20:58:13] <peloverde> Where do I put arguments? registers? the stack?
[20:58:23] <mru> wherever abi says
[20:58:30] <mru> maybe there's a macro for it
[20:58:45] <mru> 32-bit uses stack, 64-bit uses regs for first 4? args
[20:59:07] <peloverde> yes, I was hoping Dark_Shikari or BBB might know a macro for it
[20:59:11] <mru> are you fixing the fft?
[20:59:15] <peloverde> yes
[20:59:17] <peloverde> well imdct
[20:59:20] <peloverde> but same idea
[20:59:20] <mru> yeah
[20:59:22] <mru> great
[20:59:59] <mru> kshishkov: btw, photos from .se on my blog
[21:00:04] <mru> one has a train
[21:00:25] <peloverde> I could just try inlining it seeing as fft_dispatch is just a tiny wrapper to switch to the FFT's internal calling convention
[21:04:56] <BBB> peloverde: call, and use either stack or push/pop for arguments
[21:05:04] <BBB> I dont' think there's a macro for it
[21:05:18] <mru> push/pop is stack...
[21:05:38] <BBB> I know that, but some people reserve space for calling new functions on the stack, others use push/pop
[21:06:05] <mru> you mean some use sub esp, mov foo, [esp]
[21:06:11] <mru> which is the same thing in the end
[21:06:15] <mru> and wrong for 64-bit
[21:06:23] <mru> if you stick to abi
[21:06:31] <peloverde> Since ff_fft_dispatch is just a wrapper I think it makes more sense inline it, I'm just trying to figure out "dispatch_tab"
[21:06:42] <mru> yeah, makes sense
[21:08:02] <BBB> wtf
[21:08:21] <BBB> I'm trying to "figure out" a zip password of an encrypted zip containing (suspected) LGPL software
[21:08:27] <BBB> I'm using fcrackzip
[21:08:32] <BBB> guess what I see in stdout:
[21:08:35] <BBB> sh: COPYING.GPLv2: command not found
[21:08:51] <BBB> (among thousands of other errors, still trying to figure out the zip pass)
[21:08:59] <BBB> I wonder what the hell fcrackzip is doing
[21:09:10] <dylanza> hi all - I'm busy writing a jpeg2000 decoder (more to learn, but if I finish it I'll try get it into the codebase) - but I cant find the spec anywhere online (except for ITU which makes you pay) - which spec did the summer of code guy use?
[21:09:18] <peloverde> What is "[$$]"?
[21:09:47] <BBB> [$$] was something related to pic
[21:09:52] <BBB> I can't remember exactly what it was
[21:10:23] <BBB> dylanza: hey there... ask on ml, so the people who wrote that code can respond
[21:11:36] <kierank> dylanza: I might be able to find you a spec
[21:17:30] <dylanza> kierank: great let me know
[21:19:07] <[1]kierank> dylanza: what's the name or code of the spec you're looking for?
[21:19:58] <dylanza> kierank: ITU T.800 or ISO/IEC 15444-1
[21:22:43] <kierank> hmm i only get amedments to 15444-1
[21:22:46] <kierank> amendments*
[21:24:07] <kierank> I have -2, -6 and -12 if that's of any use?
[21:24:58] <dylanza> sure - maybe it will have the stuff I need (for now)
[21:27:19] <peloverde> -14 is identical to 14496-12
[21:27:22] <peloverde> *-12
[21:52:49] <peloverde> What's the mapping of register numbers to register names? (More particularity which register is C)
[23:26:40] <kierank> phew....finally found that bug in lowcomp that was breaking everything
[23:48:29] <peloverde> What's wrong with "mulps xmm0, xmm5"?
[23:48:43] <Dark_Shikari> you tell me
[23:49:59] <peloverde> I'm getting "error: invalid combination of opcode and operands"
[23:50:16] <Dark_Shikari> in yasm?
[23:50:25] <peloverde> yeah
[23:51:06] <Dark_Shikari> o.0
[23:51:11] <Dark_Shikari> try looking at the preprocessed source
[23:51:19] <Dark_Shikari> and seeing what is acutally going on
[23:53:26] <spaam> kierank: good boy
[23:56:23] <peloverde> The mulps is getting turned into a pfmul
[23:56:42] <Dark_Shikari> Look at some %defines.
[23:56:50] <Dark_Shikari> Most likely, someone is %defining around to turn sse code into 3dnow.
[23:57:00] <Dark_Shikari> templating
[23:58:22] <peloverde> yes I see "%define mulps pfmul"