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

irc at mansr.com irc at mansr.com
Sun Jul 18 02:00:04 CEST 2010


[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: + at 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


More information about the FFmpeg-devel-irc mailing list