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

[irc at mansr.com]

[00:44:14] <peloverde> What advantage does libxine have over directly using FFmpeg?
[00:46:51] <peloverde> I ask because of the KDE phonon libxien back end and stuff like this http://people.gnome.org/~michael/blog/2010-07-06-ooo-gstreamer.html
[01:31:01] <Honoome> peloverde: libxine has a few more layers
[01:31:14] <peloverde> wrappers all the way down?
[01:31:17] <Honoome> peloverde: but seriously I'd count it dead (and I say that as one of the developers)
[01:31:29] <Honoome> it doesn't use libavformat
[01:31:50] <Honoome> it has its own demuxers and input protocols, including smb and a gvfs one (and the phonon system has its own kio plugin)
[01:32:10] <Honoome> it can use other libraries beside libavcodec (like faad, mad, ...)
[01:32:17] <peloverde> I never really understood why kde and/or kubuntu chose it as the default phonon backend
[01:32:34] <Honoome> *shrug* I'm not sure why they did so... I guess at the time gstreamer didn't look so clean
[01:32:44] <Honoome> and they wanted something abstract enough...
[01:33:24] <Honoome> I did suggest a couple of times they should have been looking at vlc
[01:33:41] <Honoome> up to two years ago there were two active xine devs, me and _ds_...
[01:33:57] <Honoome> and I was of the idea that most of xine had to be rewritten from scratch anyway, maybe using glib rather than trying to reinvent the wheel
[01:34:35] <Honoome> I started a 1.2 branch that had a bunch of fixes, and used libavutil rather than inventing new things for it, but then I had personal trouble and other priorities stepped up
[01:35:13] <Honoome> now I look back, I maintain it was a very good learning experience, but I think it's not worth trying to keep it alive
[01:35:45] <peloverde> I'm happy that these days most players aren't implementing their own codecs anymore
[01:36:03] <Honoome> even the plugins system is totally fucked up, it can easily use up over 1MB of memory per-instance, simply because of the way the plugins are loadedd
[01:37:31] <Honoome> well, I think most of the game formats' demuxers that Mike added are originally coming from xine :)
[01:38:02] <peloverde> A bunch of code started as Mike's in xine, was ported to mplayer then ported to ffmpeg
[01:38:50] <Honoome> while a bunch of code developed by I-don't-want-to-ask-who as RTSP demuxer in xine was ported to vlc and mplayer and caused a string of security vulnerabilities
[01:38:51] <Honoome> hrm
[01:39:14] <Honoome> [half of which I fixed months before reports, but I never noticed they were security vulnerabilities in the first place]
[01:40:26] <peloverde> There are still so many potential buffer disasters it is kind of funny
[01:40:39] <peloverde> indeo3 frightens me
[01:40:44] <Honoome> in the rtsp code from xine or in ffmpeg in general? :P
[01:40:50] <peloverde> ffmpeg in general
[01:41:18] <Honoome> heh I wonder why Google didn't unleash their security team over the FFmpeg codebase since they are using it
[01:41:26] <Honoome> probably they focused on h264 and webm
[01:41:31] <peloverde> They did over the parts they use
[01:41:43] <peloverde> aac, vorbis, h.264, mov, ogg, and theora
[01:41:50] <peloverde> (plus any sucked in common code)
[01:42:02] <peloverde> forgot mp3
[01:42:17] <peloverde> but they also have some ugly patches like a checked git_bits()
[01:42:46] <peloverde> My guess is youtube just runs in a sandbox
[01:42:47] <Honoome> they are a bunch of ugly patchers in general, worse I ever only seen in FreeBSD
[01:44:51] <peloverde> In general certain features are very hard to fuzz because they require intracte structure to even be activated
[01:45:13] <peloverde> To fuzz SBR I had to start after the first SBR I-frame
[01:45:52] <peloverde> PS is even messier, to fuzz it you need to choose very narrow ranges to get good coverage
[01:46:37] <Honoome> I'm afraid I'm not experienced enough in fuzzying, I'm more for static analysis even though I know its limits
[01:47:44] <Honoome> I could be reading the Fuzzying book rather than the diabetes one before sleeping but I'm not sure if that's going to be an improvement
[01:49:32] <Honoome> one will scare the heck out of me, the other will keep me reasoning on how to make good use of it on my projects... nah, not goodnight books for sure
[03:07:13] <peloverde> Does binutils include a c++ nameunmangler?
[03:19:05] <hyc> yes
[03:19:07] <hyc> :P
[03:19:33] <hyc> someone else can answer again when he comes back...
[04:21:05] <_av500_> 42
[05:03:20] <hyc> hmmm. reading the opencore source code, they do support RTP/TCP
[05:03:28] <hyc> I just haven't found out how they specify to use it
[05:54:13] <hyc> bahh. //For transport options, we only let server choose between "RTP/AVP/UDP" or "x-pn-tng/tcp"
[06:16:34] <Tjoppen> morrn
[06:19:59] <av500> gm
[06:21:00] <Tjoppen> ooh, srt parser/muxer/demuxer on ml
[06:22:55] <Tjoppen> shouldn't the demuxer end the packets just before the next "foo --> bar" line?
[06:31:46] <Tjoppen> ah, it sets itself to AVSTREAM_PARSE_FULL. maybe I should look into exactly how parsing works
[06:37:26] <wbs> hyc: actually, when looking at the latest opencore code, it does seem to support rtsp/tcp, using rtspt:// urls... but I'm not sure how to launch such an url, at least in the browser, it just doesn't recognize the url scheme
[06:37:37] <wbs> hyc: (I'm testing on android 2.2)
[06:39:18] <av500> wbs: write a small test app that opens this url in a VideoView or so...
[06:39:56] <wbs> yeah, I guess that's an option
[06:43:05] <wbs> agh, nah, I don't think there's any point in that yet at least - the rtspt url handling in opencore doesn't seem to exist in the version tagged for 2.2
[06:45:10] <av500> wbs: you know, android is open source, you could send them a patch :)
[06:46:03] <wbs> yes, but how do you send a patch that says "please use the latest master branch of this project for the next release, instead of just using a year old branch"?
[06:46:15] <wbs> it seems that the code for this was added in august last year or so
[06:46:28] <wbs> but even the 2.2 release that came out just recently still doesn't include it
[06:46:56] <wbs> av500: and I've already got a handful of patches merged in android
[06:47:11] * av500 bows to wbs
[06:47:46] <wbs> the gerrit code review system is quite neat in one way, for those projects that actually use it properly
[06:48:31] <wbs> opencore is nasty though... you send in a patch, they approve it, but don't merge the actual git commit that you sent in, instead they do a similar (but not necessarily identical) change in their own code tree, that gets propagated out in the next code dump, and then tell you to close your patch ticket
[06:48:42] <wbs> so there's hardly any traceback to the original author of the fix
[06:57:54] <wbs> it's a bit disgruntling when patch handling, such as this one, https://review.source.android.com/10904 or https://review.source.android.com/10906 end up like this: https://android.git.kernel.org/?p=platform%2Fexternal%2Fopencore.git;a=commit;h=f532d145194e474cb30d8644b8eee83873ad24cc
[06:58:12] <wbs> "This patch should now be present in the head of the master master branch. Please confirm and then abandon this change. Thank you for the contribution."
[07:02:39] <av500> wbs: ic
[07:03:56] <wbs> with other android repos, that uses the code review system properly though, the contributions end up as proper git commits merged into the history, with all the original author info preserved properly, such as https://android.git.kernel.org/?p=platform%2Fbionic.git;a=commit;h=c88110e284d6fcb5922c72f524dc3b4f24139580
[07:05:19] <av500> I guess the opencore stuff gets fwd'ed to oc themselves...
[07:05:39] <wbs> yeah, and maintained in their own repo, and then just exports commits from there out into the public git
[07:05:53] <av500> yeah
[07:06:08] <wbs> earlier, they actually did merges of public contributions in the public git tree, which then partially were overwritten by accident by the next code drop
[07:06:16] <av500> :)
[07:06:16] <wbs> so in that sense, this approach at least is less error prone
[07:31:38] <hyc> wbs: I only have 2.1 on my G1
[07:32:12] <wbs> hyc: ok.. well, they still seem to have too old opencore version in 2.2, too
[07:32:23] <wbs> they're still using an opencore based on something from march 2009
[07:32:55] <hyc> oh well
[07:32:55] <wbs> with lots of new fancy features in the master branch, seemingly just gathering dust since the official releases don't use it
[07:33:10] <hyc> I found the rtspt stuff in this tree too, but right, the browser doesn't pass it thru
[07:34:09] <hyc> and even if it did, I'm not sure that tunneled RTSP is what we want...
[07:35:33] <lu_zero> hi
[07:36:01] <hyc> rtspt -> PVMF_MIME_DATA_SOURCE_RTSP_TUNNELLING
[07:36:15] <lu_zero> rtspt ?
[07:36:37] <wbs> lu_zero: in the opencore media framework, they use rtspt:// urls to indicate that they want tcp interleaving
[07:36:48] <hyc> lu_zero: I was looking for a way to use RTP/TCP in opencore on android
[07:36:50] <lu_zero> -_-
[07:36:59] <hyc> I am not convinced rtspt is actually RTP/TCP tho
[07:37:05] <wbs> umm, yes it is
[07:37:45] <hyc> maybe things look different in your tree, perhaps I should update
[07:38:53] <wbs> rtspt:// seems to be handled by opencore/nodes/streaming/streamingmanager/plugins/rtsptunicast..., and this sets rtspExtIntf->SetStreamingType(PVRTSP_3GPP_TCP);
[07:38:55] <lu_zero> hyc: if you happen to get an application for android please tell me if opencore is interoperable with feng
[07:39:24] <hyc> I can probably tell you that right now, if you have a feng server handy
[07:39:25] <lu_zero> Honoome: you tried something on it as well
[07:39:40] <hyc> I have the code here but I never installed/configured it
[07:39:55] <hyc> wbs: ok that makes more sense
[07:40:24] <wbs> the terminology tunneling vs interleaving for rtsp/tcp is mostly just what you prefer to call it
[07:40:26] <hyc> I saw the code in pvmf_streaming_manager_node.cpp that says "check if tunelling plugin is to be instantiated"
[07:40:32] <lu_zero> rtsp://backstage2.esof2010.org/live/live_12.sd
[07:40:35] <hyc> but I hadn't found the plugin itself
[07:40:43] <lu_zero> live with mpeg2 stuff inside
[07:40:56] <hyc> mpeg2 probably won't work
[07:41:03] <hyc> mpeg4, h.263, h.264bp
[07:41:37] <lu_zero> rtsp://media.lscube.org/tests/tc.mov
[07:42:23] <lu_zero> h264+mp3 might work?
[07:42:27] <hyc> could not be played
[07:42:32] <hyc> (tc.mov)
[07:42:33] <wbs> don't think mp3 is supported there
[07:42:37] <lu_zero> -_-
[07:42:40] <lu_zero> sigh
[07:42:42] <lu_zero> just amr?
[07:42:46] <hyc> aac
[07:42:55] <lu_zero> let me find a file like that
[07:44:20] <av500> amr or aac
[07:44:48] <hyc> wbs: ah, my plugins directory only has rtspunicast, no rtspstunicast
[07:45:02] <hyc> rtspt ...
[07:45:08] <lu_zero> rtsp://backstage6.esof2010.org/esof_greetings.mov
[07:45:37] <lu_zero> that might work
[07:45:43] <lu_zero> h264+aac
[07:46:02] <hyc> failed
[07:46:12] <lu_zero> how?
[07:46:12] <hyc> it has to be h.264BP
[07:46:21] <lu_zero> sigh -_-
[07:46:21] <hyc> lemme see what ffprobe / ffplay tells me
[07:46:26] <lu_zero> that picky?
[07:46:42] <wbs> lu_zero: very few phones support h264 main profile
[07:46:49] <hyc> yep, very picky
[07:46:54] <av500> base profile
[07:47:13] <lu_zero> sigh
[07:47:31] <hyc> ffprobe has some error messages on that stream too
[07:47:35] <av500> lu_zero: it plays in my own media player stack! :)
[07:47:48] <av500> but spits out a lot of h264 errors from lavc..
[07:47:51] <wbs> lu_zero: I'm testing against sample_100kbit.mp4 from DSS, with feng... it stays at "Loading video" for forever, and then stops with "cannot be played" after >30 sec
[07:48:04] <hyc> by the way, it seems like something broke re h264 between r239xx and r24034
[07:48:43] <hyc> I can no longer play H.264 flv streams from ffserver
[07:48:56] <hyc> and it was working at r239xx
[07:49:13] <wbs> lu_zero: that particular file works just fine when served by DSS
[07:49:22] <lu_zero> auhmm
[07:49:31] <lu_zero> add another bug about compatibility ^^
[07:49:48] <lu_zero> hyc: can you bisect it?
[07:49:51] <hyc> wbs: probably the hint tracks
[07:50:02] <wbs> hyc: umm, no
[07:50:11] <hyc> ffserver barfed on them, anyway
[07:50:22] <hyc> lu_zero: I'll try to narrow it down later
[07:50:44] <wbs> hint tracks are necessary for DSS to serve it, but feng has its own packetizers and doesn't use the hint track, but they don't matter if they're present
[07:51:02] <hyc> ok
[07:51:03] <wbs> the same file works fine when served by feng, when watching using ffplay
[07:52:02] <hyc> lu_zero: oh, I just noticed, your esof_greetings.mov is 480x368, my G1 can only play up to 480x320
[07:52:35] <hyc> so that may also be the reason it refused to play...
[07:54:31] <hyc> cool, SRT parser. muxer/demuxer? shouldn't it just be a track in some other muxed file?
[07:57:46] <hyc> anyone have any suggestions on https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/091570.html ?
[07:58:31] <hyc> Luca's patch worked, but he's still fretting over code duplication
[07:59:15] <hyc> and we're only talking about 1-2 lines of code here. refactoring h264.c seems to be more effort than it's worth.
[08:00:25] <Tjoppen> if you can demux SRT in .avi it makes sense to be able to demux regular .srt files
[08:01:05] <hyc> Tjoppen: ok, was just curious
[08:01:29] <wbs> lu_zero: actually, it seems to work with the android player, but it seems like you've broken http://bugs.lscube.org/show_bug.cgi?id=3 again
[08:01:51] <hyc> without Luca's patch ffserver is totally broken for flv h.264. (but with his patch it's still broken right now, I need to figure out why.)
[08:02:18] <Tjoppen> I was actually thinking a bit about this earlier.. noone really protested to my idea of having subtitle demuxers. good to see someone finally getting around to it
[08:02:44] <lu_zero> no
[08:02:49] <lu_zero> =E
[08:02:51] <hyc> I was thinking of adding subtitle mux/demux for FLV
[08:03:05] <hyc> but at the moment it seems like a lot of hassle and probably few players support it
[08:03:07] <lu_zero> how so?
[08:03:23] <Tjoppen> I'm going to add an EBU/STL demuxer later
[08:03:30] <av500> hyc: there are flvs with subs inside?
[08:03:44] <hyc> av500: there can be, but there's no single standard for them
[08:03:53] <av500> any in the wild at all?
[08:03:55] <hyc> FLVs can contain an event list in the metadata
[08:04:05] <hyc> and one of the event types is text
[08:04:05] <av500> yes, I remember now, we talked about it
[08:04:08] <hyc> yep
[08:04:17] <hyc> I had actually dug up some samples
[08:04:21] <hyc> don't remember where I left them
[08:04:48] <KotH> hyc: i hope you left them on mphq ;)
[08:05:05] <hyc> mmmmmm.... oops
[08:06:03] <KotH> hmm^2
[08:06:11] <KotH> why are there only 3g free space left in incomming?
[08:06:14] <hyc> sigh. don't remember at the moment. and I would hate to accidentally upload a porn clip instead...
[08:06:33] <KotH> we dont mind porn clips as long as it's not gay porn ;)
[08:06:41] <hyc> lol
[08:07:18] <hyc> av500: I think I got derailed by the whole "closed captions are not the same as subtitles" thing
[08:07:50] <av500> KotH: maybe you should state porn preference in sample upload rules....
[08:08:08] <hyc> support for both is so obscure in FLV, it all seemed too fractured
[08:08:09] <av500> so ppl know
[08:08:14] <KotH> av500: i dont have a porn preference, it's just that i dont mind it :)
[08:08:30] <av500> no, which kind is ok to upload...
[08:19:29] <lu_zero> av500: that's remind me the 1s april idea of committing a porn-optimized codec
[08:21:39] <kshishkov> whom shall we ask for test data to tune it?
[08:24:15] <lu_zero> pff
[08:26:04] <twice11> I heard rumors of sites where you can download many .flv samples.
[08:26:16] <kshishkov> youtube?
[08:26:24] <twice11> For porn samples, I mean. Without need of special firefox extensions.
[08:26:40] <kshishkov> I don't care anyway
[08:30:42] <lu_zero> wbs: how to test the regression?
[08:32:29] <wbs> lu_zero: you print source=... in the Transport header in SETUP replies
[08:32:55] <wbs> lu_zero: if you print source=0.0.0.0, you probably used the same ip for binding the local udp socket, too
[08:41:37] <ohsix> peloverde: c++-filt?
[08:50:47] <hyc> nm will already demangle for you
[08:51:15] <Tjoppen> the vc1 decoder seems to be very flaky. I've managed to crash it several times today
[08:51:42] <kshishkov> huh?
[08:53:19] <Tjoppen> I'm hacking with mainconcept, and about half of its output crashes the decoder
[08:55:46] <Tjoppen> the short story is it crashes in the call to MPV_common_end() in vc1_decode_end()
[08:56:40] <kshishkov> any details
[08:56:56] <kshishkov> while I'm mere maintainer of VC-1 decoder, I may be interested in that
[08:57:17] <Tjoppen> yes, I suspected that. I'll post an issue
[08:59:25] <Tjoppen> another interesting thing is that it thinks the file is 720x576 when it's 1440x576
[08:59:41] <Tjoppen> but that might be mainconcept screwing up
[09:04:20] <hyc> how ironic. watching my G1 phone on my G1 phone freezes up. http://m.youtube.com/watch?gl=US&client=mv-google&xl_blz_off=xl_blz_off&hl=en&v=F7lWLjtrbR0
[09:21:45] <Tjoppen> kshishkov: https://roundup.ffmpeg.org/issue2076  /MPlayer/incoming/vc1-double-free
[09:24:03] <kshishkov> thanks
[09:29:07] <kshishkov> hmm, looks like it tries writing past the picture
[09:30:03] <av500> onto the wooden table?
[09:34:29] <lu_zero> av500: onto the wall
[09:34:32] <lu_zero> in the other room
[09:34:47] <av500> so you get room access violation?
[09:36:39] <lu_zero> and the guard complains
[09:38:05] <elenril> lu_zero: why are we still using svn ;)
[09:44:13] <lu_zero> mru: you got time next week?
[09:44:21] <lu_zero> elenril: complain in ml
[09:44:44] <lu_zero> hi DonDiego
[09:44:49] <mru> time for what?
[09:46:01] <lu_zero> migrate to git once the elenril email lands
[09:47:09] <elenril> meh, complaining here is easier ;)
[09:49:42] <lu_zero> elenril: do that or no git till the next meeting =P
[09:50:49] <KotH> elenril is complaining?
[10:01:52] <lu_zero> KotH: we should pick a day to move roundup tell me when you are free
[10:02:03] <KotH> lol
[10:02:06] * KotH is never free
[10:02:15] <KotH> ok, maybe in december or so
[10:02:40] <KotH> tell me when you want to do it and i try to make it free
[10:05:57] <lu_zero> 5 months and the server will be dismissed ^^
[10:08:04] <lu_zero> otherwise give me an account on the place or I'll give you the accounts on the server/other server
[10:08:13] <superdump> lu_zero, mru : did you figure out how you wanted to manage accounts?
[10:08:21] <superdump> iirc mru didn't want to give people shell accounts
[10:10:01] <KotH> we dont give out shell accounts unless there is a need for it
[10:10:13] <iive> superdump: KotH is the "owner" of the server.
[10:10:27] <KotH> and only to those people we trust enough that they can keep their ssh key and their own machine secure enough
[10:10:41] <kshishkov> i.e. nobody
[10:10:46] <KotH> iive: owner is the wrong word. i'm only the legal representative
[10:11:08] <lu_zero> KotH: gitolite or gitosis
[10:11:36] <iive> KotH: that's why I used ""
[10:11:48] <superdump> gitolite? not heard of that one
[10:11:54] <superdump> is the project actively maintained?
[10:11:55] <lu_zero> gitosis in perl
[10:12:13] <kshishkov> lu_zero: why both sound like a disease names?
[10:12:20] * KotH trusts perl coders more than python coders
[10:12:26] <lu_zero> gitosis is in python and is more or less maintained by gentoo
[10:12:35] <lu_zero> KotH: install gitolite then =)
[10:12:53] <lu_zero> http://github.com/sitaramc/gitolite
[10:12:54] <KotH> lu_zero: open a bug on bugzilla using the mphq cateogry :)
[10:13:01] <lu_zero> KotH: ok
[10:13:39] * KotH has first to see who can produce this damn PCB within 3 weeks
[10:13:48] <mru> it doesn't take more than 5 lines of shell script to set up a shared account
[10:14:31] <lu_zero> KotH: which bugzilla btw? I cannot see the mphq category
[10:15:06] <lu_zero> mru: a bit more if you want to expand the concept
[10:15:35] <KotH> lu_zero: bugzilla.mphq
[10:15:47] <mru> my main concern is with accounting, how to know which real person did what
[10:16:30] <KotH> .o0(japanese invasion)
[10:17:08] <lu_zero> hi henry_
[10:21:13] <CIA-99> ffmpeg: cehoyos * r24079 /trunk/libavformat/img2.c: Associate .tga with format image2.
[10:22:50] <lu_zero> mru: you'd like to use gpg signed commits?
[10:23:31] <mru> no, that solves a different problem
[10:24:18] <mru> I want every access to the 'git' account logged in a way I can trace back to a real person
[10:24:28] <thresh> uhm, ssh logins?
[10:24:39] <mru> I do not want to hand out ssh logins to everybody
[10:24:54] <thresh> how would you enable someone to commit without it?
[10:25:03] <mru> shared account and ssh keys
[10:25:12] <mru> read the backlog dammit
[10:25:17] <thresh> doesnt git push involve ssh login?
[10:25:21] <thresh> not involve i mean
[10:25:25] <CIA-99> ffmpeg: cehoyos * r24080 /trunk/libavcodec/wmadec.c:
[10:25:25] <CIA-99> ffmpeg: Silence warning "new qualifiers in middle of multi-level
[10:25:25] <CIA-99> ffmpeg: non-const cast are unsafe".
[10:25:25] <CIA-99> ffmpeg: Patch by Eli Friedman, eli d friedman a gmail
[10:26:12] <mru> anyway, ssh has means of identifying the key used for login
[10:26:17] <mru> that's good enough for me
[10:27:00] <lu_zero> thresh: you can have a single ssh account restricted for the gitosis/gitolite/whatever daemon
[10:37:19] <CIA-99> ffmpeg: michael * r24081 /trunk/libavcodec/mpegaudiodec.c:
[10:37:19] <CIA-99> ffmpeg: Move ff_dct_init(context) out of if(one time init)
[10:37:19] <CIA-99> ffmpeg: fixes calling a null pointer in issue658
[10:39:57] <CIA-99> ffmpeg: michael * r24082 /trunk/libavformat/asfdec.c:
[10:39:57] <CIA-99> ffmpeg: Ignore extradata & w/h in asf/dvr.
[10:39:57] <CIA-99> ffmpeg: The w/h values are wrong and extradata contains a fake seq header that causes
[10:39:57] <CIA-99> ffmpeg: decoding to fail later, a valid seq header is in the stream itself.
[10:39:57] <CIA-99> ffmpeg: Fixes issue658
[10:58:06] * mru lols at the clueless idiots on doom9
[10:58:18] <mru> "AFAIK, floating point decoding is most useful when you're doing transcoding. I don't think it's THAT important for playback"
[10:59:17] * elenril thinks the dshow guy responses were more lulzy
[10:59:32] <mru> "I know float is slower, but most people care more about quality.
[10:59:37] <iive> you should probably thank tomshardware benchmarks on flaskmpeg mpeg2->4 tanscoding tool for that.
[11:01:21] <lu_zero> ??
[11:02:05] <elenril> lu_zero: http://forum.doom9.org/showthread.php?t=155516
[12:28:42] <CIA-99> ffmpeg: mru * r24083 /trunk/libavcodec/motion_est.c:
[12:28:42] <CIA-99> ffmpeg: motion_est: fix implicit truncation warnings
[12:28:42] <CIA-99> ffmpeg: Patch by Reimar D?ffinger and Eli Friedman (independently).
[13:11:53] <CIA-99> ffmpeg: aurel * r24084 /trunk/libavformat/ (assenc.c assdec.c): imporve long_name for ass (de)muxer
[14:34:02] <Tjoppen> heh, michael worrying about libavutil containing multimedia stuff. look at the name of the library :)
[14:34:48] <mru> it was created by splitting some parts off lavc
[14:35:19] <kshishkov> does that mean lavc contains multimedia stuff too?
[14:35:25] <Tjoppen> gasp!
[14:36:34] <av500> Tjoppen: here "av"  = absolutely versatile
[14:36:52] <mru> ambiguously vague
[14:37:01] <av500> +1
[14:37:17] <av500> btw, wtf is that lowres?
[14:37:31] <mru> downscaling a la IJG
[14:37:39] <mru> partial idct
[14:37:39] <av500> and that is needed where?
[14:37:43] <mru> nowhere
[14:37:47] <av500> ah like IJG
[14:37:53] <mru> it's obviously a tad faster
[14:38:03] <av500> the 80s are over, no?
[14:38:28] <mru> judging by prevailing hairstyles, yes
[14:39:29] <av500> http://www.flickr.com/photos/av500/4767108775/in/set-72157624309805057/
[14:40:01] <Tjoppen> :)
[17:28:32] <CIA-99> ffmpeg: mru * r24085 /trunk/libavutil/intmath.h: intmath: whitespace cosmetics
[17:28:32] <CIA-99> ffmpeg: mru * r24086 /trunk/libavutil/ (intmath.h common.h): Remove macro duplication between common.h and intmath.h
[17:28:33] <CIA-99> ffmpeg: mru * r24087 /trunk/libavutil/common.h: Allow arch-overrides for all common.h clip and log2 functions
[17:28:34] <CIA-99> ffmpeg: mru * r24088 /trunk/libavutil/arm/intmath.h: ARM: intmath.h cosmetics
[17:28:34] <CIA-99> ffmpeg: mru * r24089 /trunk/libavutil/arm/intmath.h: ARM: optimised integer clip functions
[17:48:07] <peloverde> I don't think anyone is ever going to use libavutil without at at least one other FFmpeg library
[17:48:18] <mru> of course not
[17:48:21] <Honoome> I wonder what would happen if xorg and the various desktop environments started using libavutil to provide common optimised routines
[17:48:31] <skal_zZzZzz_> av500: nice pic :)
[17:48:41] <Honoome> peloverde: gha I was thinking the opposite at this point :P
[17:48:49] * _skal_ back on earth
[17:49:30] * Honoome wonders about an API/ABI-compatible libpng using libavutil... :P
[17:49:57] <Honoome> if lu_zero dares me to I might even take a stab at that ;)
[17:50:54] <_av500_> Honoome: libavoil?
[17:51:11] <Honoome> _av500_: hope not
[17:51:24] <Honoome> libavtomic wouldn't be bad though
[17:51:35] <Honoome> to repalce that crud that goes under the name libatomic_ops
[17:58:33] <_av500_> libikeshed
[18:00:54] <Honoome> _av500_: sole maintainer michaelni?
[18:04:32] <_av500_> we should vote
[18:04:55] <kierank> vote to have a vote too
[18:06:06] <_av500_> ffmpeg 0.7 "code, don't vote"
[18:07:16] <mru> isn't 0.7 "troll driven development"?
[18:07:25] <Honoome> rotfl
[18:08:15] <_av500_> mru: we never voted on that, did we?
[18:08:21] <mru> trolls don't vote
[18:08:39] <kierank> I think _av500_ is becoming a bigger troll than mru
[18:10:10] <mru> we should set up another trolling session some weekend while I'm in .de
[18:12:10] <_av500_> +1
[18:13:59] <kierank> I want to do that thing KotH suggested a while ago
[18:14:05] <kierank> massive meetup of all free multimedia people
[18:14:12] <kshishkov> kierank: av500 is the biggest troll indeed
[18:14:24] <kierank> except I would expect streetfights to occur
[18:15:10] <kierank> like mru vs monty
[18:15:20] <Honoome> kierank: like half of us poking sharp sticks at the xiph guys
[18:15:48] <kierank> it would end up just turning into various factions
[18:15:51] <CIA-99> ffmpeg: jai_menon * r24090 /trunk/ffplay.c: FFplay : Fix segfault when playing monoaural streams.
[18:15:52] <kierank> gstreamer, xiph etc
[18:17:48] <kshishkov> somebody should invite people from companies like Real or Adobe too (not Mike though)
[18:18:25] <mru> inviting Real would be a good troll
[18:20:08] <peloverde> Why not Mike?
[18:20:22] <mru> not only mike
[18:20:28] <jai> asking them for sponsorship might be a nicer troll
[18:20:33] <mru> lol
[18:21:01] <Honoome> why? Real's still alive?
[18:21:18] <iive> is there something left for RE from Real?
[18:21:24] <jai> ralf
[18:21:52] <iive> ? what is that?
[18:21:55] <j0sh> iive: the port-knocking sequence in real's rtsp-http variant
[18:21:58] <kierank> some troll codec
[18:22:04] <jai> their homegrown lossless codec
[18:22:05] <Honoome> j0sh: they use port-knocking?!
[18:22:13] <kshishkov> lossless codec named after Ralf Wiggum (from Simpsons)
[18:22:28] <j0sh> Honoome: yup, i discovered it in the wild a few weeks ago when working on ffmpeg rtsp-http
[18:22:51] * Honoome wonders if feng should be compatible on the server side
[18:23:06] <j0sh> i haven't made much of an effort to document it yet
[18:23:18] <mru> client-side compat is easy
[18:23:26] <mru> just display "buffering..."
[18:24:43] <CIA-99> ffmpeg: stefano * r24091 /trunk/libavfilter/avfilter.h: Implement avfilter_copy_picref_props().
[18:24:50] <iive> j0sh: are you sure it doesn't try to use the older protocols first?
[18:25:46] <j0sh> iive: it might, from my brief testing it worked OK without the port-knocking urls
[18:25:52] <CIA-99> ffmpeg: stefano * r24092 /trunk/ (7 files in 4 dirs): Add pixdesctest filter and corresponding test.
[18:26:05] <Honoome> wbs: are you sure the local socket is left with 0.0.0.0? I thought it would have been bound to the correct addres... well, at least I guess I can check it out now on the APUE
[18:26:41] <Honoome> saste: uhm since you're around :P -- did we lose the ability to rotate a video or am I blind?
[18:27:08] <saste> did we ever had that feature?
[18:27:13] <dgt84> Can anybody help me to use eval.h and declare function pointers?
[18:27:18] <saste> i mean without libavfilter?
[18:27:19] <mru> I don't think we ever did
[18:27:44] <mru> dgt84: what kind of function pointers?
[18:27:44] <saste> did you tried with rotate in libavfilter-soc? the last time i tried it was working...
[18:27:47] <Honoome> saste: good question, I _thought_ we had and lu_zero suggested we had as well, but I wouldn't be ready to bet on that
[18:28:04] <Honoome> saste: ah that might be the trick...
[18:28:07] <mru> dgt84: will these do?  int (*(*(*(*foo)[4])(int (*)(int *)))[2])(int);
[18:28:35] <wbs> Honoome: yes, I'm quite sure
[18:28:37] <Honoome> mru: ... please tell me you have those on a post-it and you just copy paste them and not re-create them on the fly
[18:28:49] <dgt84> mru, whatever crazy structure I need to make to pass to eval.h's av_parse_expr() for funcs2. I'm able to do the const stuff but am not that strong with C for the functions.
[18:28:51] <mru> Honoome: yes, I had this one saved
[18:29:04] <wbs> Honoome: as a response to setup, it replies "Transport: RTP/AVP;unicast;source=0.0.0.0;client_port=5000-5001;..."
[18:29:20] <wbs> Honoome: where the source= address is the same as it used to bind the udp socket a few lines earlier in the same file
[18:29:24] <mru> dgt84: just take a suitable function prototype and change funcname to (*funcname)
[18:29:38] <Honoome> saste: erm... happen to have the link at hand for the repo? ^^;;
[18:29:47] <dgt84> mru, it says it wants "double (* const *funcs2)(void *, double, double)". How would I declare a function for that and how would I make a list of them that complies with the FFmpeg style guidelines?
[18:29:48] <Honoome> wbs: okay will check it out...
[18:29:57] <saste> ffmpeg.org/libavfilter.html ;-)
[18:30:19] <saste> near the top of the file there is the checkout command
[18:30:29] <mru> oh, that's a pointer to pointer to function
[18:30:43] <dgt84> <head explodes>
[18:30:57] <mru> an array of function pointers is probably what you want
[18:31:19] <mru> each function should be "double func(void *, double, double)"
[18:31:29] <saste> exactly
[18:31:47] <saste> dgt84: did you already grepped the libavcodec code for examples?
[18:31:57] <mru> then you make an array like so: double (funcs[])(void *, double, double) = { func1, func2, ... }
[18:32:12] <Honoome> saste: thanks :) I owe you a coffee or something if one day we get an italian devs meetup (*prod* lu_zero *prod*)
[18:32:12] <dgt84> saste, I did not, figured people here knew and could provide a quick answer so I don't get stuck on something stupid ;-)
[18:32:28] <mru> sorry, that was wrong
[18:32:33] <mru> that was an array of functions
[18:32:37] <mru> and that doesn't exist
[18:33:05] <mru> should be double (const *funcs[])(void *, double, double) = { ... }
[18:33:46] <mru> then you can simply pass "funcs" to the eval.h function
[18:34:24] <dgt84> mru, hmmm, this seems to give me "expected identifier or ‘(’ before ‘const’"
[18:34:38] <dgt84> using the latest line you pasted
[18:34:44] <mru> it was untested
[18:35:06] <saste> dgt84: libavcodec/ratecontrol.c
[18:35:13] <mru> without the const?
[18:35:18] <saste> dgt84: look the definition of func1
[18:36:24] <dgt84> saste, mru, thanks will check out that example and try to get it working
[18:36:50] <mru> here's an example straight from the C spec: void (*signal(int sig, void (*func)(int)))(int);
[18:37:21] <saste> dgt84: ok, waiting for reviewing your scale patch
[18:58:22] <dgt84> saste, argh... what do you recommend for string splitting on ":" in C? strtok seems to stop processing when it reaches the ',' in e.g. "round(H, 16)"
[19:04:52] <mru> strtok() isn't threadsafe
[19:04:56] <mru> use strtok_r
[19:10:47] <blight_> hi is svn broken?
[19:11:30] <dgt84> mru, how do you initialize the third parameter (char **save_ptr)? I set it to NULL and get a segfault :-/
[19:12:28] <mru> char *foo; ...; strtok_r(s, sep, &foo);
[19:12:37] <mru> oh, and foo=NULL before
[19:13:07] <mru> scratch that
[19:13:12] <mru> doesn't need init
[19:13:19] <mru> but only pass on first call
[19:13:30] <dgt84> mru, cool that does work. Still seems to want to stop processing on reaching a comma though... wtf
[19:13:52] <mru> damn, I'm confused
[19:13:55] <mru> that's strsep
[19:14:01] <dgt84> mru, const char *delim = ":";
[19:14:09] <dgt84> you would think that would mean only delimit on ":" right?
[19:14:13] <mru> yes
[19:14:28] <mru> you can pass a literal ":" to the strtok call if you want
[19:14:45] * Honoome would use static const char delim[] = ":"; if you really want to declare it as named var
[19:15:13] <mru> Honoome: doing that makes sure you get a private copy of it
[19:15:27] <Honoome> mru: note my "if you really want"
[19:15:49] <mru> using a pointer you may use a shared string literal
[19:16:03] <mru> and the compiler will hopefully not allocate any actual space for the pointer
[19:16:17] <Honoome> you'd then need a const char *const delim then
[19:16:51] <mru> string constants are not writable by default
[19:16:56] <mru> sharing them is perfectly safe
[19:17:37] <Honoome> mru: it really makes a difference between const char *const and const char * last I checked with GCC
[19:17:43] <dgt84> even passing as a literal it seems to crap out on commas
[19:17:49] <mru> Honoome: then gcc is being stupid
[19:17:52] <mru> which is hardly news
[19:17:54] <Honoome> even within a function context
[19:17:59] <Honoome> [it is expected on unit-context]
[19:18:29] <Honoome> anyway I'd say the literal is the right choice for strtok_r most of the times ;P
[19:18:33] <dgt84> input = "round(W, 2)", calling strtok_r("round(W, 2)", ":", save_ptr) => "round(W"
[19:18:57] <mru> dgt84: &save_ptr
[19:19:15] <Honoome> char *save_ptr = NULL; and then call it as &save_ptr
[19:19:15] <blight_> libavfilter/libavfilter.so: undefined reference to `read_line' <-- i think SVN is broken
[19:19:28] <dgt84> mru, yeah I am doing that, sorry. It works between calls, it's just not liking commas for some reason I'm not getting
[19:19:29] <mru> blight_: I think not
[19:19:52] <mru> dgt84: your font renders : as ,?
[19:20:17] <dgt84> I highly doubt that lol
[19:20:37] <mru> blight_: sorry, you're right, some idiot (stefano) broke it
[19:20:40] <mru> thanks
[19:20:46] <blight_> it's broken on windows too i believe
[19:21:01] <blight_> libavformat/img2.c: In function 'av_str2id':
[19:21:03] <blight_> libavformat/img2.c:112: error: implicit declaration of function 'strcasecmp'
[19:21:19] <blight_> the function is called stricmp on windows iirc
[19:21:46] <mru> nonstandard
[19:21:52] <mru> strcasecmp is standard
[19:22:05] <Dark_Shikari> our configure adapts itself for many nonstandard systems
[19:22:08] <Dark_Shikari> why is windows different?
[19:22:20] <Dark_Shikari> log2 is standard, but BSD doesn't have it.
[19:22:23] <Dark_Shikari> So we configure check for it.
[19:22:29] <Dark_Shikari> Even though it's required by the C spec.
[19:22:47] <mru> nobody ever complained about strcasecmp before
[19:22:50] <blight_> mru: i know but it should still compile on windows shouldn it?
[19:22:53] <mru> we've been using it for years
[19:23:07] <mru> I don't care if it fails on windows
[19:23:10] <blight_> ok
[19:23:27] <Dark_Shikari> mru: well, then lets roll back the bsd compatibility code, ok?
[19:23:32] <Dark_Shikari> we've been using log2 for yeras
[19:23:35] <Dark_Shikari> I don't care if it fails on bsd.
[19:23:40] <Dark_Shikari> it's a waste of code.
[19:24:17] <mru> look ffmpeg works on windows _NOW_
[19:24:23] <mru> it uses strcasecmp _NOW_
[19:24:25] <Dark_Shikari> no it doesn't
[19:24:29] <mru> ergo, there is no problem with strcasecmp
[19:24:32] <Dark_Shikari> it only works because the people doing windows builds hacked it to work
[19:24:34] <Dark_Shikari> to avoid exactly that problem
[19:24:39] <mru> hmm
[19:24:40] <Dark_Shikari> It's one of the patches that they include
[19:24:42] <mru> I didn't know that
[19:24:58] <Dark_Shikari> it's a problem related to a define
[19:25:07] <Dark_Shikari> the strcasecmp defines are wrapped in ifndef D_STRICT_ANSI
[19:25:08] <Dark_Shikari> or something
[19:25:11] <Dark_Shikari> (in system headers)
[19:25:22] <mru> lol
[19:25:34] <mru> it's in iso c99
[19:25:47] <Dark_Shikari> It could be that their implementation isn't strict-ansi compliant or something
[19:25:58] <peloverde> I thought *BSD was finally catching up with c99
[19:25:59] <Dark_Shikari> Either way I don't like it when peopel downstream have to apply patches.
[19:26:06] <Dark_Shikari> peloverde: yes, in 2018
[19:26:11] <Dark_Shikari> afk, going to work
[19:26:45] <peloverde> http://www.freebsd.org/projects/c99/index.html
[19:28:39] <dgt84> mru, actually I don't think this is an issue with how I'm calling strtok, but an issue in libavfilter maybe? "error initializing filter 'scale' with args 'round(W:flags=0xA0000004'"
[19:29:25] <dgt84> It is chopping my stuff off after the comma because libavfilter uses a comma to delimit filters... so how can one even use eval on filter arguments if you want multiple args?
[19:30:04] <dgt84> saste, any ideas ^
[19:30:52] <mru> oh my god
[19:30:56] <mru> I can't believe this
[19:37:02] <blight_> latest revision committed by mru works on linux
[19:37:55] <mru> no
[19:38:03] <mru> shared libs are broken at the moment
[19:39:00] <iive> you know, richard have made alternative simple libc, we could solve all problems by using it...
[19:39:26] <_av500_> fflibc
[19:39:39] <mru> libavc
[19:39:50] <_av500_> yup
[19:40:55] <iive> it is in the mphq svn repository. imho it lacks some of the mind breaking forking and threading gimmics...
[19:41:17] <_av500_> autoforking?
[19:42:11] <Honoome> hmmm
[19:42:52] <j0sh> wbs: how do you track the leaks in ffmpeg's "T.676" functions that valgrind sometimes gives?
[19:43:06] <mru> doesn't it give a line number?
[19:43:07] <j0sh> actually, where do these even come from?
[19:43:13] <j0sh> mru: yeah, it does
[19:43:14] <mru> those are generated by the compiler
[19:43:33] <mru> it sometimes breaks parts of a function out into a separate function
[19:43:35] <j0sh> but everything afterwards is kind of messed up, like it says av_mallocz is in mem.c
[19:43:41] <mru> it is
[19:44:04] <j0sh> oh, there *is* a mem.c. my bad
[19:44:14] <astrange> functions shouldn't be named T.676, iirc newer gcc gives better function names in the interprocedural optimizations
[19:44:42] <j0sh> time to update gcc then?
[19:44:44] <astrange> but it still has problems like emitting warnings for "get_bits.clone.0" instead of "get_bits"
[19:44:58] <j0sh> im using 4.4.3
[19:45:05] <astrange> try 4.5.whatever then
[19:45:08] <j0sh> ok
[19:46:14] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r24078/ if someone wants to go through the noise
[19:47:25] <j0sh> astrange: that's a really cool tool. does it come with clang?
[19:47:51] <peloverde> kind of
[19:47:59] <Honoome> hm that's a nice one indeed
[19:48:02] <astrange> http://clang-analyzer.llvm.org/
[19:48:15] <Honoome> lu_zero: if it's not in portage I want it now! :P
[19:48:36] <astrange> clang --analyze works but emits something annoying instead of that html page, if you aren't on os x
[19:48:53] <astrange> you might be able to get it to print analyzer stuff like regular warnings
[19:53:46] <mru> ah, _now_ I understand why they're called static analysers
[19:54:10] <mru> the output resembles static (line noise)
[19:54:28] <Dark_Shikari> clang actually is pretty accurate IMO
[19:54:35] <Dark_Shikari> if you ignore the dead stores, it's only about 90% noise
[19:54:38] <mru> only 97% noise eh?
[19:54:41] <Dark_Shikari> which is actually enough to work through
[19:54:44] <Dark_Shikari> unlike, say, lint.
[19:54:51] <mru> lint is totally rubbish
[19:54:55] <Dark_Shikari> Exactly
[19:54:55] <mru> it does one statement at a time
[19:55:07] <Dark_Shikari> lint has both problems
[19:55:08] <mru> there's now way that can be accurate _or_ useful
[19:55:10] <Dark_Shikari> it doesn't give useful results
[19:55:16] <mru> s/now/no/
[19:55:17] <Dark_Shikari> and the useless non-results are mixed in with thousands of junk reuslts
[19:55:28] <Dark_Shikari> YOU FORGOT FIVE EXTRA PARENS HERE.
[19:55:48] <mru> my favourite is when it whinges about a+b+c
[19:55:52] <Dark_Shikari> speaking of which, I think we should keep the gcc extra paren warnings
[19:55:53] <mru> it wants (a+b)+c
[19:55:56] <Dark_Shikari> re that mailing list thread
[19:56:03] <Honoome> Dark_Shikari: hm is it intended that the presets for ipod640 and ipod320 are tfu? :P
[19:56:25] <mru> yeah, as long as gcc doesn't go too over the top with them
[19:56:31] <mru> it's got worse over the years
[20:00:01] <j0sh> http://www.tbray.org/ongoing/When/201x/2010/06/29/No-Defaults
[20:00:40] <j0sh> i agree with him
[20:00:51] <j0sh> eg, keeping sorta-extraneous things like parens to make the code readable
[20:01:14] <mru> but only when it makes it more readable, not less
[20:01:41] <mru> you can often achieve a natural grouping with whitespace instead
[20:02:11] <mru> write not (a << 24) | (b << 16) | (c << 8) | d
[20:02:19] <mru> but a<<24 | b<<16 | c<<8 | d
[20:02:23] <j0sh> sometimes if the operator precedence rules aren't completely clear, parens are the safer way
[20:02:46] <Dark_Shikari> as long as our code doesn't look like theora's
[20:02:50] <Dark_Shikari> aka "no spaces, no parens"
[20:03:18] <mru> j0sh: only when you can't remember the rules, or the precedence differs radically from what formatting makes it look like
[20:03:22] <Honoome> Dark_Shikari: no sense!
[20:04:04] <CIA-99> ffmpeg: alexc * r24093 /trunk/libavformat/adtsenc.c: Cosmetics: whitespace
[20:04:11] <j0sh> from the article: "I’ve learned a lot of programming languages over the years, and I’ve taken care never to learn the operator precedence rules in any of them."
[20:04:29] <mru> idiot and proud of it
[20:04:33] <j0sh> whether that's smart or not is up for debate, heh
[20:04:50] * Honoome cries because of x264 presets!
[20:04:59] <mru> placebo ftw
[20:05:03] <_av500_> when i started i sprinkled parens all over the code
[20:05:21] <_av500_> nowi try to use the precendce rulez
[20:05:21] <peloverde> I wonder if he does that for all his "+"s and "*"s too
[20:06:16] <mru> C is not Lisp dammit
[20:06:22] <mru> if you want parens, code in lisp
[20:06:43] <peloverde> Also anyone who has studied boolean algebra knows the order of operations for logical operators
[20:06:52] <mru> the irony is that those who complain the most about precedence rules have the hardest time using postfix or prefix notation
[20:07:08] <mru> peloverde: and anyone who hasn't has no business near a computer
[20:07:13] <peloverde> indeed
[20:08:57] <mru> the C operator precedence is quite sane too
[20:09:06] <mru> it minimises the amount of parens in common situations
[20:10:27] <CIA-99> ffmpeg: mru * r24094 /trunk/libavcodec/arm/fft_neon.S: ARM: hide a .size directive on non-ELF targets
[20:10:28] <CIA-99> ffmpeg: mru * r24095 /trunk/libavcodec/arm/asm.S:
[20:10:29] <CIA-99> ffmpeg: ARM: set section to .text in 'function' macro
[20:10:29] <CIA-99> ffmpeg: This ensures code always goes into the .text section and avoids the
[20:10:29] <CIA-99> ffmpeg: need to specify it explicitly after changing sections.
[20:10:29] <CIA-99> ffmpeg: mru * r24096 /trunk/libavcodec/arm/simple_idct_neon.S: ARM: remove unnecessary .previous directive
[20:10:40] <peloverde> WTF! Why did CT decide to make the first signaling test file have a slightly different payload than the others?
[20:24:48] <CIA-99> ffmpeg: mru * r24097 /trunk/libavcodec/aacdec.c: aacdec: remove checks for impossible error conditions
[21:10:14] <saste> someone has an idea about what's going on with read_line / write_line?
[21:10:25] <saste> that's killing half fate builds...
[21:14:02] <mru> it's not exported from the shared lib
[21:14:05] <mru> missing av_ prefix
[21:18:32] <saste> weird don't we have lots of non av_ prefixed functions?
[21:18:59] <saste> but maybe they are the only one in lavu...
[21:22:57] <BBB> omg @ several 100 kb of headers on ffmpeg-soc
[21:24:33] <CIA-99> ffmpeg: cehoyos * r24098 /trunk/libavcodec/ (20 files): Add new decoder property max_lowres and do not init decoder if requested value is higher.
[21:29:06] <j0sh> BBB: at least they are very well commented :)
[21:29:19] <BBB> no, they have a lot of comments
[21:29:25] <BBB> that doesn't mean they are well commented
[21:29:30] <j0sh> heh
[21:31:38] <j0sh> BBB: what's the different between sebastian and hemanth's projects?
[21:31:56] <BBB> hemanth does avfilter for audio
[21:32:02] <BBB> sebastian does mod file support
[21:35:17] <j0sh> a mod file?
[21:35:30] <kierank> some random amiga thing
[21:35:48] <kierank> that sebastian takes very seriously
[21:36:01] <BBB> google for (lib)modplug or (lib)mikmod
[21:36:03] <_av500_> ;)
[21:39:13] <mru> saste: it would be nice if you prefixed you're patch mail subjects with just [PATCH]
[21:39:21] <mru> not [random-junk PATCH]
[21:46:05] <mchinen> anyone want to help me commit my patch from a few days ago?
[21:46:18] <mchinen> move put_v
[21:49:47] <CIA-99> ffmpeg: alexc * r24099 /trunk/libavcodec/aacenc.c: aacenc: Enforce LFE bitstream restrictions.
[21:50:27] <BBB> mchinen: ping it once... if nobody's done it toorrow, I'll do it
[21:50:33] <BBB> mchinen: usually carl eugen or someone will commit
[21:51:41] <CIA-99> ffmpeg: alexc * r24100 /trunk/libavcodec/aacenc.c: Cosmetics: whitespace
[21:51:59] <mchinen> thanks
[22:09:34] <BBB> j0sh: nice patch!
[22:09:42] <BBB> I basically have no comments ;)
[22:09:45] <Dark_Shikari> BBB: status on loopfilter btw? =p
[22:10:01] <BBB> Dark_Shikari: was reviewing stuff yesterday/daybefore, I restarted work today
[22:10:17] <Dark_Shikari> k
[22:10:19] <BBB> for V-inner, I have most checks complete, I have about 10-20 instructions for filter_common to write
[22:10:22] <BBB> it's pretty much done
[22:10:34] <BBB> I already added the transpose steps for H, so H should be easy
[22:10:44] <BBB> after that I'll do mbedge
[22:10:55] <BBB> or the U/V combined one
[22:11:09] <BBB> I'm now looking at sebastian's code for modfile support
[22:11:12] <BBB> ...
[22:34:09] <merbanan> BBB: omg, qdm2 rtp packetization
[22:34:17] <merbanan> why in the world
[22:34:19] <BBB> I wrote that a long time ago
[22:34:23] <merbanan> is it used by someone ?
[22:34:25] <BBB> yes
[22:34:31] <BBB> also, quicktime/apple supports it
[22:34:48] <merbanan> mein godt
[22:34:50] <BBB> it was my first succesful RE project :-p
[22:34:56] <merbanan> he ;)
[22:35:04] <BBB> "how to do something productive in IDA"
[22:35:08] <BBB> just before wmavoice
[22:43:36] <j0sh> BBB: sweet
[23:42:30] <CIA-99> ffmpeg: mru * r24101 /trunk/ (3 files in 2 dirs):
[23:42:31] <CIA-99> ffmpeg: Rename read/write_line() to av_read/write_image_line().
[23:42:31] <CIA-99> ffmpeg: The old names were not av_ prefixed, and they were causing linking
[23:42:31] <CIA-99> ffmpeg: failure on many platforms. The new names are also more descriptive.
[23:42:31] <CIA-99> ffmpeg: Patch by Stefano Sabatini.
[23:48:39] <CIA-99> ffmpeg: michael * r24102 /trunk/libavutil/random_seed.c: get_generic_seed() for the cases without /dev/random and AV_READ_TIME
[23:50:06] <mru> auughh, I hate michael's "var= value" style
[23:50:33] <kierank> i also hate that
[23:50:42] <kierank> especially where it's mixed
[23:51:28] <Dark_Shikari> +1
[23:53:13] <CIA-99> ffmpeg: jbr * r24103 /trunk/libavcodec/ac3_parser.c:
[23:53:13] <CIA-99> ffmpeg: ac3: make the value of codec_id during (E-)AC-3 parsing stay CODEC_ID_EAC3
[23:53:13] <CIA-99> ffmpeg: if any E-AC-3 frames have been detected instead of switching back and forth for
[23:53:13] <CIA-99> ffmpeg: AC-3 core + dependent E-AC-3 substream(s).
[23:53:13] <CIA-99> ffmpeg: Fixes Issue 2022.
[23:57:50] <saste> mru: thanks, I'll commit reindent and APIchanges tomorrow, i badly need to sleep now
[23:58:01] <saste> goodnight
[23:58:03] <mru> I didn't know you were still awake
[23:58:13] <mru> so I committed it
[23:58:19] <saste> good thanks