[00:31:45] <Dark_Shikari> peloverde: ping [02:40:40] <Compn> oooh [02:40:41] <Compn> idea time [02:41:06] <Compn> mru : what about a cron job that sends a mail to ffmpeg-issues with a filename of every new file uploaded to incoming ? [02:41:16] <Compn> KotH [02:41:48] <Compn> this will finally solve a ton of incoming problems, having an automated bug creation [02:43:18] * Compn sleeps before any more good ideas leak out of his brain [02:45:18] <beandog> dont you want them to leak out? [02:45:32] <beandog> aren't there ftpds with fam? [02:46:09] <Compn> fam ? [02:46:19] <beandog> file alteration monitor [02:47:06] <beandog> anyway [02:47:13] <beandog> im sure theres an ftpd that supports hooks [02:47:40] <beandog> alright, Im gonna go bump stuff now. [02:47:49] <beandog> packages, that is. [02:55:24] <Compn> the order in which to report bugs would change, first > upload file, second > reply to roundup issue. a more advanced script could even move such files into issueXXXX dirs automatically. [05:08:58] <CIA-99> ffmpeg: jai_menon * r24279 /trunk/libavformat/avidec.c: avidec : Free codec context before initializing the chained DV demuxer. [05:27:20] <CIA-99> ffmpeg: mstorsjo * r24280 /trunk/libavformat/aviobuf.c: [05:27:20] <CIA-99> ffmpeg: aviobuf: Do short seeks forward by reading and skipping data instead of a proper seek [05:27:20] <CIA-99> ffmpeg: This improves performance on e.g. seekable http. [05:41:07] <CIA-99> ffmpeg: jai_menon * r24281 /trunk/libavformat/avidec.c: avidec : Free packet if dv_produce_packet fails. [08:01:51] <mru> morning [08:03:18] <mru> thinking about how to build a new fate [08:03:57] <_av500_> KotH: http://www.flickr.com/photos/av500/4801350504/ [08:04:19] <mru> :-) [08:04:58] <thresh> good morning [08:05:29] <mru> it would obviously be nice to keep all the client-side scripts in the ffmpeg repo [08:05:50] <mru> and drive it all from make [08:06:09] <mru> but if the makefiles broke, it wouldn't be able to report that... [08:09:17] <mru> so I guess a separate script is required [08:09:30] <mru> or at least a fully standalone script [08:46:54] <kurosu> Yuvi: (regarding a discussion here some 27H ago) GL_UNPACK_ROW_LENGTH isn't available with OpenGL ES (you have to do the copy line by line yourself), which is what most smartphones and tablets get [08:47:54] <mru> things with GL ES have shared memory anyway [08:49:40] <kurosu> I don't get the point, but whatever, this is the obvious reason for the stride concern Jason reported earlier [09:11:01] <DonDiego> Yuvi: vp8.c:892: warning: suggest explicit braces to avoid ambiguous 'else' [09:20:29] <CIA-99> libswscale: mstorsjo * r31746 /trunk/libswscale/swscale.c: [09:20:29] <CIA-99> libswscale: In planarCopyWrapper, Only copy length, not stride of the last line in the plane [09:20:29] <CIA-99> libswscale: If the destination planes are offset within the destination buffer, [09:20:29] <CIA-99> libswscale: writing the extra bytes at the end may write outside of the destination [09:20:29] <CIA-99> libswscale: buffer. [09:20:52] <ohsix> thats one semicolon away from disaster [09:23:40] <mru> DonDiego: while I agree with the sentiment, that warning is badly phrased [09:23:57] <mru> there is nothing ambiguous about it [09:24:03] <mru> confusing perhaps [09:29:11] <DonDiego> and btw, weren't we going to do away with the parentheses warning? [09:30:14] <mru> is this a different warning? [09:30:28] <DonDiego> yes [10:15:43] <CIA-99> ffmpeg: stefano * r24282 /trunk/ (5 files in 2 dirs): Add color source. [10:44:33] <CIA-99> ffmpeg: diego * r24283 /trunk/libavcodec/ (8 files): [10:44:33] <CIA-99> ffmpeg: Fix Doxygen @param command attribute syntax. [10:44:33] <CIA-99> ffmpeg: The [in] and [out] attributes have to be appended to the @param command. [10:45:08] <CIA-99> ffmpeg: stefano * r24284 /trunk/libavfilter/ (avfilter.h defaults.c): [10:45:08] <CIA-99> ffmpeg: Rename AVFilterPic to AVFilterBuffer. [10:45:08] <CIA-99> ffmpeg: The struct is going to be used for audio data as well, so the new name [10:45:08] <CIA-99> ffmpeg: is less misleading. [10:45:08] <CIA-99> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram smeenaks AT ucsd DOT edu. [10:48:15] <CIA-99> ffmpeg: stefano * r24285 /trunk/doc/APIchanges: Add APIchanges entry for AVFilterPic -> AVFilterBuffer rename. [10:51:15] <CIA-99> ffmpeg: vitor * r24286 /trunk/tests/ (ref/fate/msmpeg4v1 fate2.mak): [10:51:16] <CIA-99> ffmpeg: Undo my revert at r24260. [10:51:16] <CIA-99> ffmpeg: This is the only way by now to test this codec. [10:51:47] <elenril> saste: +@var{color}:@var{frame_size}:@var{frame_width} << shouldn't the second one be frame_rate? [10:52:22] <saste> yes indeed I missed that... [10:52:36] <saste> going to fix it in few minutes [10:57:54] <CIA-99> ffmpeg: stefano * r24287 /trunk/doc/filters.texi: [10:57:54] <CIA-99> ffmpeg: Fix documentation syntax for the color source, the third parameter is [10:57:54] <CIA-99> ffmpeg: frame_rate, not frame_width. Thanks elenril for spotting it. [11:02:42] <DonDiego> janneg: any progress with latm? :) [11:12:33] <pjay_> hi ! anyone familiar with mmst.c ? i have problems with it and i'm trying to debug it. [12:10:05] <lu_zero> good morning [12:10:14] <mru> morning [12:17:38] <mru> http://www.bbc.co.uk/news/world-europe-10660867 [14:13:58] <markuman> !randnick [15:03:31] <CIA-99> ffmpeg: mru * r24288 /trunk/tests/fate-run.sh: fate: whitespace cosmetics [15:03:31] <CIA-99> ffmpeg: mru * r24289 /trunk/tests/fate-run.sh: [15:03:31] <CIA-99> ffmpeg: fate: add stddev comparator [15:03:31] <CIA-99> ffmpeg: This allows CMP=stddev in test rules. The test passes if the reported [15:03:31] <CIA-99> ffmpeg: stddev is <= the FUZZ value (default 1). [16:35:52] <CIA-99> ffmpeg: cehoyos * r24290 /trunk/libavutil/internal.h: Use attribute force_align_arg_pointer only on x86_32. [17:15:14] <mru> lol basty thinks someone will write a new tracker... [17:16:55] <kierank> what's a tracker? [17:17:17] <kshishkov> module music player [17:17:50] * kierank reads the wikipedia article [17:17:52] <kshishkov> you know, in pattern/note format [17:19:05] <kierank> the only thing i know relating to that is midi [17:19:44] <Dark_Shikari> MIDI is one tracker format [17:19:46] <kshishkov> well, in zeroth approximation it's the same thing [17:20:14] <mru> Dark_Shikari: no, tracker data can be represented as midi [17:20:22] <mru> midi is also a hell of a lot more [17:20:32] <kshishkov> now just imagine MIDI with notes grouped with defined note group order and instruments [17:20:49] <kshishkov> yes, MIDI is also a joystick port :) [17:20:51] <mru> we had a fun flame war about that some time ago [17:21:21] <mru> eventually it emerged that basty had never heard of a moog synth [17:21:30] <Dark_Shikari> LOL [17:21:34] <Dark_Shikari> _what_ [17:21:43] <jai> synths ftw [17:21:43] <Dark_Shikari> I wasn't even alive when those are around and I've heard of them [17:21:49] <mru> which is rather embarrassing for someone allegedly dabbling in electronic music [17:22:00] <mru> they're legendary [17:22:01] * kshishkov still thinks the best synth is called church organ [17:22:22] * mru thought that was maxim [17:23:09] <kshishkov> at least another GSoCer has heard of Therminvox [17:23:30] <spaam> :) [17:23:41] <Dark_Shikari> mru: MIDI is a tracker format in the same way that .doc is a styled text format [17:23:45] <Dark_Shikari> sure, .doc can have images too [17:23:50] <Dark_Shikari> but that doesn't make it less of a text format. [17:24:11] <Dark_Shikari> (images, and macros, and viruses) [17:24:32] <mru> no, it goes much further [17:24:41] <mru> file formats are only a tiny part of midi [17:24:47] <Dark_Shikari> ok, true [17:24:55] <mru> it contains electrical specs for connecting stuff [17:25:03] <mru> and wire protocols [17:25:09] <mru> sync mechanisms [17:25:11] <mru> etc etc [17:25:25] <mru> it's mainly about _playing music_ [17:25:48] <kshishkov> on instruments with digital interfaces [17:25:52] <Dark_Shikari> mru: well it's like MPEG-4 [17:25:56] <Dark_Shikari> there's MPEG-4 part 2 and 10 (video) [17:25:59] <Dark_Shikari> then there's audio [17:26:00] <Dark_Shikari> then there's a container [17:26:01] <Dark_Shikari> etc etc [17:26:05] <Dark_Shikari> all kinds of shit in one spec [17:26:05] <mru> and bifs [17:26:22] <kshishkov> and structured whatever [17:26:27] <mru> seriously though, ask an actual musician about midi [17:26:34] <mru> I bet file formats is not the first thing he'll mention [17:27:06] <kshishkov> mru: don't people remember that sound cards had MIDI ports, for instance? [17:27:21] <mru> evidently not [17:28:11] <kshishkov> well, I cannot say that I was introduced to computers early but even I know that stuff [17:30:35] * kshishkov reflects on it and feels extremely old [17:31:05] * mru reflects in the mirror... nah, still not very old [17:32:11] * kshishkov is not eligible for ungdom biljett anymore - should be very old indeed [17:32:30] <mru> no, that means you're not a kid anymore [17:32:50] <spaam> :) [17:33:01] <spaam> and it will be more expensive.. [17:33:15] <kshishkov> javisst [17:33:21] <Dark_Shikari> I remember midi ports. I used one with a keyboard I had [17:33:42] <Dark_Shikari> fuck, I remember when I could actually play piano. [17:33:54] <mru> spaam: relatively, it's much cheaper for those of us with decent jobs [17:34:03] <mru> spaam: but I guess you wouldn't know much about that [17:34:12] <spaam> mru: not yet.. [17:34:28] <mru> I never played the piano, only with it [17:35:58] <kshishkov> spaam: move to Ukraine, railroad tickets are much cheaper there (service quality is proportional too) [17:37:16] <spaam> kshishkov: no thanks :) next time im going to move will be malmö or someplace near :) [17:37:18] <kierank> railrunner is best ticket ever on dutch trains [17:37:48] <kshishkov> spaam: I'd like to move to the north of Gotaland [17:38:06] <spaam> kshishkov: why there? :) [17:38:22] <kshishkov> spaam: too warm for me elsewhere [17:38:25] <mru> stockholm is the only place in sweden worth living [17:38:37] <mru> kshishkov: if you want cold, go to kiruna or something [17:38:47] <spaam> mru: nothing wrong with norrland :) [17:39:04] <mru> spaam: only that it's too cold, too dark, and too far away [17:39:05] <kshishkov> mru: I dreamed of doing that [17:39:08] <mru> and too boring [17:39:32] <kshishkov> mru: if it has Internet access it's not that boring [17:39:36] <spaam> mru: boing ? haha only if you make it [17:39:46] <spaam> boring [17:40:08] <mru> so what would you do? go for a ride on the snowmobile? [17:40:19] <mru> not my idea of fun [17:40:24] <mru> not in the long term at least [17:40:38] <kshishkov> vodka works in long term for Russians [17:40:53] <mru> vodka only masks the boredom [17:41:00] <mru> drunkenness can mask almost anything [17:41:02] <spaam> hembrÀnt ;D [17:41:34] <spaam> moonshine in english ;D [17:45:17] <kshishkov> well, Sundsvall seems to be a nice place too [17:45:43] <spaam> umeÃ¥ is much better :) [17:45:55] <spaam> i like that city more :) [17:46:09] * kshishkov tries to guess where spaam was born [17:46:49] <spaam> in a city between umeÃ¥ and sundsvall :) [17:47:20] <kshishkov> I'd rather choose LuleÃ¥ then [17:47:36] <mru> luleÃ¥ at least has a respectable university [17:48:04] * kshishkov knows a guy with email address there [17:48:22] <merbanan> spaam: övik ? [17:48:25] <spaam> merbanan: yes [17:48:34] <spaam> kshishkov: benjamin? ;D [17:48:45] <spaam> i think he has a email from ltu.se. [17:48:58] <merbanan> yeah I think I have that [17:49:07] <spaam> ah its you :) [17:49:15] <merbanan> yes I'm me [17:49:52] <mru> merbanan: if you were not, then who would you be? [17:50:29] <merbanan> someone else of course [17:50:44] <mru> but then who'd he be? [17:50:46] <merbanan> a pure logic deduction [17:51:19] <merbanan> he would be someone else also [17:51:45] <mru> but eventually it would have to come back to someone else being you [17:51:51] <mru> to maintain equilibrium [17:52:13] <kshishkov> mru: and I'm crazy guy [17:52:21] <kshishkov> graduated from KTH [17:52:54] <kshishkov> (with totally different 'K' than in your KTH of course) [18:14:07] <CIA-99> ffmpeg: stefano * r24291 /trunk/libavfilter/ (avfilter.h defaults.c): [18:14:07] <CIA-99> ffmpeg: Remove AVFilterBuffer w and h fields. [18:14:07] <CIA-99> ffmpeg: These fields are never used, and they do not seem to belong to [18:14:07] <CIA-99> ffmpeg: AVFilterBuffer anymore, now that it is now a media-independent [18:14:07] <CIA-99> ffmpeg: structure and these fields are video-related. [18:14:08] <CIA-99> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram smeenaks ! ucsd ! edu. [18:17:50] <CIA-99> ffmpeg: stefano * r24292 /trunk/doc/APIchanges: Add APIchanges entry after AVFilterBuffer w and h fields removal. [18:28:02] <CIA-99> ffmpeg: stefano * r24293 /trunk/libavfilter/avfilter.h: [18:28:03] <CIA-99> ffmpeg: Clarify AVFilterBuffer documentation, make it clear that it is not [18:28:03] <CIA-99> ffmpeg: necessarily video-related. [18:56:48] <CIA-99> ffmpeg: stefano * r24294 /trunk/libavfilter/avfilter.h: [18:56:48] <CIA-99> ffmpeg: Move the AV_PERM_* flags definition outside the AVFilterPicRef [18:56:48] <CIA-99> ffmpeg: definition. [18:56:48] <CIA-99> ffmpeg: This way it is easier to reference them in other structures, for [18:56:48] <CIA-99> ffmpeg: example in the pending AVFilterSamplesRef struct. [18:56:49] <CIA-99> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram smeenaks AT ucsd DOT edu. [19:07:02] <mchinen> for parsers is it better to assume the frame length is at it says in the header, or is it better to look over all frame data for a new header? [19:07:38] <mru> go with the header value first [19:07:51] <mru> if you don't find the next frame where it should be, start searching [19:07:54] <mchinen> i would think the first is better, but I see some code that does the second, i guess, to look for interrupted frames. But this is subject to getting unluck [19:08:05] <mchinen> ok [19:08:14] <mru> the mpegvideo parsers must scan the entire frame [19:08:15] <mchinen> thats what i'd prefer too [19:08:18] <mru> there is no size field [19:08:30] <mchinen> i'm rebuilding a flac parser that jason ruggles submitted [19:08:41] <mru> flac parsing is nasty [19:08:50] <mru> there is no size header [19:09:04] <mchinen> hm [19:10:29] <mru> there's only a 16-bit sync word [19:10:42] <mru> which frequently occurs in the payload too [19:11:23] <mru> you have to do something like scan for the syncword, then parse and validate the header following it [19:11:40] <mru> if the header seems weird, keep searching [19:11:55] <mru> there's an 8-bit crc covering the header [19:12:10] <mru> of course there's a 1 in 256 chance it will match randomly [19:12:20] <mchinen> haha [19:12:37] <mru> so when you find a sane header with correct crc, you scan for the next sync word [19:12:49] <mru> at the end of each frame is a 16-bit crc for that frame [19:12:53] <mru> so check that [19:13:01] <jai> is this for seeking in flac? [19:13:09] <mru> jai: yes [19:13:14] <jai> k [19:13:21] <mchinen> yes [19:13:35] <mru> if the header checks out and the frame crc matches, there is still a 1 in 16 million chance it's fake [19:13:38] <mchinen> okay that's pretty much what's in there already [19:14:19] <mru> if the following frame also validates, you're probably good [19:15:11] <mru> if you think 1 in 16M sounds low, consider I have ~130GB of flac files, and my collection is small [19:15:49] <mru> and because it's compressed data, any bit string is as likely as any other [19:15:53] <mru> well, in theory [19:16:22] <mchinen> yeah, the bitrate is much higher so it's more likely. People on the list didn't like the idea of just validating two frames for this reason [19:16:31] <mchinen> (from a thread in mar 09) [19:16:46] <mru> yes, even two frames might not be enough at all times [19:17:15] <mru> if only they'd put some sync emulation prevention in there... [19:17:35] <mru> this is what happens when amateurs design file formats [19:17:38] <mru> or codecs [19:17:43] <mchinen> yeah really. [19:17:46] <mru> compresses well but is a bitch to use [19:19:41] <mchinen> maybe i'll just make the number of subsequent validated frames arbitrary and this will be enough [19:31:24] <spaam> mru: so you can make a better format? ; [19:32:07] <mru> spaam: there are some mistakes I wouldn't make [19:32:17] <jai> better framing maybe [19:32:31] <mru> that would be one thing [19:32:50] <mru> or require external framing [19:32:58] <mru> but that's annoying too
participants (1)
-
irc@mansr.com