[FFmpeg-devel-irc] IRC log for 2010-02-05

[irc at mansr.com]

[00:13:38] <DonDiego> Yuvi: say, where was your theora speedup tree?
[00:14:43] <Yuvi> DonDiego: http://github.com/yuvi/ffmpeg/tree/vp3-rewrite
[00:15:01] <DonDiego> how much faster is that thing?
[00:15:10] <Yuvi> just finished fixing the final bugs, but it's slower than it should be because I assumed theora was too much like sane codecs
[00:15:12] <DonDiego> compared to trunk and libtheora 1.1?
[00:15:21] <Yuvi> currently 15% for cases that matter, probably about the same speed as 1.1
[00:15:39] <DonDiego> so you're going to get it merged soon?
[00:15:57] <Yuvi> yeah, I mainly need to not do MC twice for uncoded blocks
[00:17:20] <DonDiego> do you know if it will be faster than 1.1 in the end?
[00:17:31] <DonDiego> we should have much more (x86) asm..
[00:20:03] <Yuvi> almost certainly; that doesn't (yet) include DC-only IDCT (or near DC-only), asm for the x,y MC, or the faster DC prediction that 1.1 has
[00:20:33] <DonDiego> can we steal some asm from them?
[00:21:06] <Yuvi> yeah, but the only thing that would be useful is 10-element mmx IDCT which I'd probably end up rewriting for sse anyway
[00:21:14] <DonDiego> k
[00:38:30] <CIA-17> ffmpeg: michael * r21638 /trunk/ffplay.c:
[00:38:30] <CIA-17> ffmpeg: Fast seeking.
[00:38:30] <CIA-17> ffmpeg: Try clicking with the mouse in the window, hold the button and drag.
[01:57:56] <Compn> Try clicking with the mouse in the window, hold the button and drag.
[01:57:59] <Compn> madness!
[02:07:28] <CIA-17> ffmpeg: michael * r21639 /trunk/ffplay.c: Pretty RDFT audio visulaization.
[02:20:12] <Vitor1001> Is it just for me that "ffplay -h" segfaults?
[02:21:45] <drv> crashes here too
[02:22:06] <Vitor1001> :p
[02:24:25] <drv> but hey, what developer ever reads the help? ;)
[02:25:55] <Kovensky> now, michael, go worry about actually useful things, like making h264 faster :P
[02:26:15] <drv> pretty visualizations are good too
[02:33:22] * Compn waits for the day that someone replies via email to the -devel-logs list
[02:33:33] <Compn> irc>email interface
[02:34:18] <Kovensky> that list was actually made?
[03:04:41] <Compn> yes
[04:08:41] <justlooking> @''#
[04:43:12] <CIA-17> ffmpeg: vitor * r21640 /trunk/ffplay.c: Do not segfault when doing "ffplay -h"
[06:40:32] <pJok> mornings
[06:40:44] <kshishkov> goda morgnar
[06:41:53] * pJok mails kshishkov some swedish snow
[06:42:06] <av500> ikea catalogue?
[06:42:28] <pJok> those are like the bible, you can find them anywhere in the world
[06:42:54] <pJok> sweden looks like a winter wonderland
[06:44:50] <kshishkov> av500: would you believe we don't have those either?
[06:46:36] <av500> yes
[06:47:35] <kshishkov> BTW, I've been near the biggest Ikea store in the world but have't visited any of them so far
[06:48:59] <pJok> neat
[06:49:16] <pJok> the biggest ikea in sweden is afair the one they are rebuilding at Väla here in skåne
[06:50:11] <kshishkov> nej, det ligger i Skärholmen, Stockholms lan
[06:50:27] <pJok> at the moment, yes :P
[06:50:57] <pJok> oh its also the worldds biggest
[06:50:58] <pJok> neat
[06:51:11] <pJok> i did not know that
[06:52:38] <kshishkov> also visit Skärholmen at night to experience Russian life
[06:53:42] <pJok> i have no idea when i'll get to stockholm again
[06:53:55] <pJok> last time i was just there for a transit to gran canaria
[06:54:01] <pJok> and that was nearly a year ago
[06:55:16] <kshishkov> and I've been for a transit in Malmö once
[06:57:41] <pJok> im mostly in malmö for transit
[06:57:58] <pJok> since its just a lump of city in the middle of a perfectly good motorway
[06:58:20] <pJok> it means that you have to drive nearly three times the distance just to get around it instead of driving through or under
[06:58:50] * kshishkov does not drive
[07:00:22] <pJok> i do when i need to, usually i just take the train, but its the same story with that
[07:00:36] <pJok> at least the citytunnel is ready in 10 months time
[07:00:46] <kshishkov> indeed
[07:01:13] * kshishkov hates local railroads
[07:01:15] <pJok> not that its doing much to my trip to work other than cut 7 minutes off my train time
[07:02:22] <kshishkov> http://fc03.deviantart.net/fs32/i/2008/224/4/7/Marxsoft_Windows__Iron_Curtain_by_The_Camo.png
[07:03:59] <pJok> mmmmh, iron curtain
[07:32:43] <Yuvi> is svq1 tested on fate?
[07:33:30] <astrange> one file http://fate.multimedia.cx/index.php?test_spec=142
[07:34:19] <astrange> http://fate.multimedia.cx/index.php?test_result=42337938 last frame is being dropped?
[07:38:12] <kshishkov> seems so
[08:35:47] <DonDiego> What's this fftrollbot thingie?
[08:35:59] <kshishkov> IRC logger
[08:36:09] <DonDiego> logging to where?
[08:36:17] <kshishkov> ffmpeg-devel-irc ML
[08:36:34] <av500> so nm can read when he gets flamed
[08:36:50] <DonDiego> this was announced where?
[08:37:05] <kshishkov> here on IRC, I guess
[08:37:05] <Dark_Shikari> the ML and on IRC a few dozen times
[08:37:14] <DonDiego> not to me..
[08:37:32] <av500> $topic
[08:37:37] <Dark_Shikari> that too.
[08:42:58] <DonDiego> ugh, the log is not even in utf-8 ..
[08:44:36] <Dark_Shikari> fail
[08:45:01] <Dark_Shikari> let's screw with it then.  everyone post in katakana!
[08:45:11] <kshishkov> ok, you have a chance to see bot developer in person and tell him to fix
[08:45:25] <elenril> or we can write like this
[08:45:59] <kshishkov> Dark_Shikari: nah, use cyrillic
[08:46:37] <Dark_Shikari> いふゆあるりぢぬぐじすりつのうゆあるのつゆしぬぐぜぼつ
[08:47:14] <Dark_Shikari> yes, we should all chat using transliterated kana
[08:47:57] <superdump> that only works if people can understand it / translate it back to a-z or so
[08:48:33] <Dark_Shikari> a-z?   >implying that japanese can even represent all the english letters losslessly
[08:49:07] <kshishkov> of coulse
[08:49:52] <kshishkov> 日本語使う飯ういいだね
[08:50:27] * kshishkov notes that Japanese input in terminal does not work so good
[08:50:39] <Dark_Shikari> what's wrong with it?
[08:50:46] <Dark_Shikari> it's no different than outside a terminal
[08:50:52] <elenril> your terminal fails?
[08:51:08] <Dark_Shikari> but if you mean that japanese input fails i ngeneral, you are correct
[08:51:08] <kshishkov> yep, different character width screws displaying here
[08:51:14] <kshishkov> of course not
[08:51:26] <Dark_Shikari> works fine here in putty
[08:51:52] <saintdev> Ｄａｒｋ＿Ｓｈｉｋａｒｉ：　ｗｈａｔ　ａｂｏｕｔ　ｆｕｌｌ－ｗｉｄｔｈ　ｃｈａｒａｃｔｅｒｓ？
[08:51:55] <kshishkov> but we could use Vietnamese instead
[08:52:22] <kshishkov> the same Latin letters with useless marks
[08:52:28] <Dark_Shikari> ｓａｉｎｔｄｅｖ：　ｉ　ａｇｒｅｅ　ｃｏｍｐｌｅｔｅｌｙ．
[08:56:18] <saintdev> ｎｏ ｔｒａｎｓｌｉｔｅｒａｔｉｏｎ ｎｅｃｅｓｓａｒｙ， ｊｕｓｔ ｕｔｆ－８ ｓｕｐｐｏｒｔ！
[08:57:45] <DonDiego> umlauts: äöü ÄÖÜ
[08:57:58] <kshishkov> Vietnamese
[08:57:59] <DonDiego> more stuff: ß ñ
[08:58:11] <twnqx> now ß is a normal character.
[08:58:13] <superdump> æ
[08:58:20] <DonDiego> €
[08:58:25] <twnqx> …
[08:58:32] <Dark_Shikari> DonDiego: nicht veilleicht mit die Schreibreforme
[08:58:48] <twnqx> doch, immer noch, nur seltener.
[08:58:51] <kshishkov> ờ
[08:58:57] <Dark_Shikari> ja ja
[08:59:00] <kshishkov> Ä‘
[08:59:23] * superdump needs to map swedish letters to useful keys
[08:59:28] <kshishkov> IPA would be even funnier
[09:00:21] <kshishkov> superdump: and what's the problem? I can type both Swedish and Russian on my Apple US keyboard
[09:00:22] <thresh> indian pale ale?
[09:00:40] <saintdev> Ｗｈａｔ ｗｅ ｒｅａｌｌｙ ｎｅｅｄ ｔｏ ｄｏ ｉｓ ｊｕｓｔ ｐｕｔ ＂michael＂ ｉｎ ｐｌａｉｎ ｔｅｘｔ ｉｎ ｔｈｅ ｍｉｄｄｌｅ ｏｆ ｓｏｍｅ ｕｔｆ－８
[09:01:04] <kshishkov> saintdev: throw H.264 somewhere too
[09:02:19] <saintdev> Ｏｈ ｙｅａｈ ｆｏｒｇｏｔ ａｂｏｕｔ ｔｈｅ H.264
[09:02:42] <saintdev> Ｒｅｐｅａｔ ａｔ ｒａｎｄｏｍ ｉｎｔｅｒｖａｌｓ．．．
[09:03:03] <kshishkov> it should be a task for fftrollbot itself
[09:05:58] <DonDiego> Dark_Shikari: btw, those patent links you gave me are somewhat too new..
[09:06:15] <saintdev> Ｏｎ ａ ｓｉｄｅ ｎｏｔｅ， ｆｕｌｌｗｉｄｔｈ ｃｈａｒａｃｔｅｒｓ ｌｏｏｋ ｈｏｒｒｉｂｌｅ ｉｎ Ｄｅｊａ Ｖｕ Ｓａｎｓ Ｍｏｎｏ
[09:07:06] <kshishkov> saintdev: it's mostly the fact kerning is awful and characters are probably bitmap
[09:08:30] <av500> you have to try harder, so far my irrsi session shows all chars ok
[09:08:55] <saintdev> ｋｓｈｉｓｈｋｏｖ： ｉｔ ｓｅｅｍｓ ｔｏ ｂｅ ａ ｗｈｏｌｅ ｄｉｆｆｅｒｅｎｔ ｆｏｎｔ． Ｔｈｅｙ ｌｏｏｋ ｏｋ ｉｎ Ｄｅｊａ Ｖｕ Ｓａｎｓ （ｎｏｎ－ｍｏｎｏ）
[09:08:59] <kshishkov> av500: probably not in log
[09:09:33] <saintdev> Ｔｈｅｙ ｌｏｏｋ ｌｉｋｅ ａ ｃｈｉｌｄ＇ｓ ｈａｎｄｗｒｉｔｉｎｇ
[09:12:13] <superdump> they look fine in my logs
[09:12:30] <kshishkov> superdump: look at yesterday log on ML
[09:13:49] <saintdev> ｓｕｐｅｒｄｕｍｐ： ｗｅ＇ｒｅ ｍｅｓｓｉｎｇ ｗｉｔｈ ｆｆｔｒｏｌｌｂｏｔ （ｆｆｍｐｅｇ－ｄｅｖｅｌ－ｉｒｃ ＭＬ）， ａｎｄ ｉｎ ｔｕｒｎ michael
[09:14:12] <superdump> mostly fine, some garbled crap
[09:15:06] <saintdev> ｔｈａｔ ｇａｒｂｌｅｄ ｃｒａｐ ｊｕｓｔ ｈａｐｐｅｎｓ ｔｏ ｂｅ ｕｔｆ－８．．．
[09:15:20] <superdump> kshishkov: i guess i want something like alt gr + a is a with a circle on top, alt gr + e is a with diaresis and alt gr + o is o with diaresis
[09:16:01] <saintdev> ｗｈｉｃｈ ｉｓ ｒｅｑｕｉｒｅｄ ｆｏｒ ｆｕｌｌｗｉｄｔｈ ｃｈａｒａｃｔｅｒｓ ：ｐ
[09:16:04] <superdump> i'll xmodmap it
[09:16:40] <superdump> currently i get æeø
[09:16:45] <superdump> respectively
[09:17:06] <kshishkov> seems Danish
[09:17:28] <superdump> mmm
[09:17:46] <superdump> is there any better way to switch the level 3 chars about than manually doing it with xmodmap?
[09:18:03] <superdump> i guess i could hack an xkb layout or something
[09:18:09] <saintdev> superdump: yes, forget what's called, though
[09:20:08] <saintdev> it's the one where you can press the key, then the keys that it looks like
[09:20:52] <saintdev> æ = <whateveritscalled>, a, e
[09:21:34] <saintdev> compose key!
[09:22:07] <superdump> compose key?
[09:22:16] <superdump> which key is that?
[09:22:18] <saintdev> https://help.ubuntu.com/community/ComposeKey
[09:22:30] <saintdev> meh, that's not the good article
[09:22:52] <saintdev> erm wait, yeah it is, just have to skip to #5
[09:23:44] <saintdev> Shift+AltGr, <key1>, <key2>
[09:25:50] <superdump> doesn't work too reliably
[09:26:14] <saintdev> for me it did, but I had to set it to something non-default
[09:26:29] <saintdev> and i don't use gnome/ubuntu
[09:28:08] <saintdev> anyway, off to bed.
[09:41:34] <elenril> anyone knows where i can find specs for avi metadata?
[09:43:30] <mru> what metadata?
[09:43:36] <mru> the I* tags?
[09:43:54] <elenril> yes
[09:43:55] <superdump> åÅäÄöÖ
[09:43:58] <superdump> winner
[09:44:05] <superdump> MÃ¥ns
[09:44:12] <superdump> </tribute>
[09:44:25] <mru> ;-)
[09:44:29] <kshishkov> elenril: wiki.multimedia.cx has links to AVI specs
[09:50:13] * elenril kicks m$crosoft
[09:50:26] <elenril> found a huge list of tags on some random page, but nothing official
[09:51:27] <mru> there is nothing official
[09:51:34] <kshishkov> it's "extensible" - you can have a cartload of tags invented purely by yourself
[09:51:50] <elenril> pure w00tness
[09:53:02] <elenril> well microsoft docs mention a few of them, so i'd expect a list somewhere
[09:54:19] <av500> mru: eta tomorrow morning
[09:54:55] <av500> mru: somehow 3 of the 6 do not like 1280x1024 (from an A5) dunno if it is better from BB, so be prepared to run 1024x768
[09:55:04] <mru> ok
[09:55:36] <av500> less stress on the sdram anyway :)
[09:55:42] <av500> mru: u have content?
[09:55:45] <mru> yes
[09:55:50] <mru> got 2 more beagles?
[09:55:53] <av500> yes
[09:55:59] <mru> all good then
[09:56:04] <mru> I'll pick up some sd cards today
[09:56:18] <av500> I have one 6x extension cord, so I need 1 free plug for my part
[09:56:57] <av500> try to secure something sturdy to place this on, this beast is heavy (60pounds)
[10:04:08] <kshishkov> av500: there's always floor
[10:04:27] <av500> yes
[10:04:36] <av500> floor is plan B
[10:04:52] <av500> destroy fosdem wall with power drill was plan A
[10:14:36] <elenril> but everything starting with I should be an info tag, right?
[10:14:53] <kshishkov> not necessarily
[10:15:59] <elenril> counterexamples?
[10:16:10] <av500> ipad
[10:16:49] * elenril shoots av500 
[10:16:58] <elenril> besides that's 'i', not 'I' =p
[10:19:59] * DonDiego packs for FOSDEM
[10:20:02] * elenril looks at mplayer's demuxer
[10:20:20] <mru> ipad is obviously for padding
[10:20:24] <mru> padding metadata, that is
[10:20:42] * elenril head explodes
[10:20:55] <mru> idx1 als isn't an info tag
[10:20:58] <mru> *also
[10:21:14] <av500> mru: it informs you of where nice video frames are
[10:21:48] <mru> elenril: why don't you come to fosdem?
[10:21:56] <elenril> exams?
[10:22:04] <elenril> no money?
[10:22:14] <av500> fix a bug, get money
[10:22:23] <elenril> that's still all 'i', not 'I'
[10:25:14] <elenril> o_0 read_avi_header() 673 lines
[10:30:35] <mru> elenril: what about ıpad?
[10:31:30] <elenril> ?
[10:32:35] <mru> or Ä°
[10:33:16] <av500> ÏŠpad
[10:34:20] <av500> ипад
[10:34:43] <thresh> unag, you say?
[10:35:09] <elenril> http://www.alliednetservices.com/clipart/ipad.jpg ?
[10:35:24] <mru> http://www.youtube.com/watch?v=8eF0y0IfpPU
[10:36:14] <av500> thresh: do I?
[10:39:25] <thresh> at least the letters look similar using terminus
[11:25:12] * elenril loves it when sdl crashes x
[11:26:07] <kshishkov> think about WIndows then
[11:26:09] <elenril> does AV_WB32 do what i think it does?
[11:26:28] <kshishkov> depends on your thoughts
[11:26:42] <kshishkov> if you think it writes 32 bit-endian integer then yes
[11:26:50] <CIA-17> ffmpeg: michael * r21641 /trunk/ffplay.c:
[11:26:50] <CIA-17> ffmpeg: Scale rdft vissualization up by 2 so theres no unused space on the top
[11:26:50] <CIA-17> ffmpeg: but rather the unimportant high frequencies are cut off if the window is
[11:26:50] <CIA-17> ffmpeg: not a multiple of 2 high.
[11:27:32] <kshishkov> EComprehensionError
[11:30:51] * elenril sighs
[11:30:54] <elenril> this avi stuff is amess
[11:31:05] <kshishkov> yes
[11:31:42] <elenril> hmm, apparrently avidec can't read metadata written by avienc
[11:31:56] <kshishkov> why should it?
[11:32:26] <av500> what is the longest chain of mux demux with different format that lavf can handle :)
[11:32:29] <elenril> why not
[11:34:12] <av500> mru: ping
[11:34:34] <kshishkov> elenril: you've looked at this? http://abcavi.kibi.ru/infotags.htm
[11:34:52] <elenril> yes, found it an hour ago
[11:36:21] <elenril> i think i'll just try to read everything that starts with 'I' as an info tag
[11:39:41] <kshishkov> heh, no luck
[11:39:45] <kshishkov> read ODML specs
[11:39:58] <kshishkov> http://www.the-labs.com/Video/odmlff2-avidef.pdf
[11:40:18] <kshishkov> section "Microsoft-Defined Tombstone Data"
[11:43:14] <elenril> we don't read/use this ISMP thing anyway
[11:43:26] <kshishkov> nor metadata :P
[11:43:49] <elenril> so it won't break anything
[11:51:34] <CIA-17> ffmpeg: michael * r21642 /trunk/libavformat/avidec.c: Correcting wrong looking stream_id validity check in avidec.
[11:51:48] <elenril> o_0
[11:55:31] <superdump> :)
[12:17:52] <CIA-17> ffmpeg: michael * r21643 /trunk/libavformat/avidec.c: Support strn tag in avidec.
[12:19:34] <elenril> srsly wtf
[12:20:10] <kshishkov> what, you don't like the fact someone is working at improving AVI demuxer?
[12:21:50] <elenril> no, he just picked a weird time for that
[12:22:25] <elenril> now i'll get ten million conflicts
[12:23:15] <kshishkov> so, some of you should have done his work earlier
[12:23:42] <superdump> elenril: maybe send him an e-mail and ask him what he's working on and talk about what you're working on
[12:23:54] <superdump> maybe he can give you some pointers and let you do the work rather than doing it himself
[12:24:00] <superdump> and then he can look at something else
[12:24:36] <kshishkov> yeah, like Н.264
[12:26:29] <elenril> yeah or i can ask him to admit he's hiding here :)
[12:27:05] <kshishkov> he's hiding at former capital of your country
[12:28:04] <elenril> my country: destination not found
[12:29:06] <kshishkov> .cz
[12:30:04] <elenril> not really my country -- my papers stilll say i'm ukrainian :(
[12:30:34] <kshishkov> do you feel that Ukraine is your country?
[12:30:37] <thresh> now now want to change your nationality mister?
[12:30:58] <elenril> ofc not
[12:31:00] <kshishkov> citizenship at least
[12:31:27] <elenril> thresh: you don't?
[12:31:48] <kshishkov> at least I don't feel that Ukraine is my country and I'm really Ukrainian
[12:31:53] <thresh> i don't really know
[12:31:59] <thresh> probably the same as kshishkov
[12:32:04] <thresh> although i miss Russia when i'm away
[12:32:48] <kshishkov> I miss Sweden
[12:33:10] <thresh> i didnt really like any of places i've been too
[12:33:13] <thresh> -o
[12:33:38] <elenril> chocolateland is nice
[12:33:46] <thresh> well except for mountains and i couldnt live there because there are no large cities in there
[12:34:02] <elenril> large cities ftl
[12:34:16] <kshishkov> thresh: you live in a small town
[12:34:21] <thresh> yeah, called Moscow
[12:34:40] <kshishkov> really? I was thinking it's outside Moscow border
[12:35:06] <thresh> yeah, 5 km away from mkad
[12:35:20] <av500> walking distance
[12:35:43] <kshishkov> thresh: and it's not Zelenograd either :P
[12:36:20] <kshishkov> av500: true, you can only _walk_ there
[12:36:29] <thresh> exactly
[12:36:58] <thresh> trains are overcrowded, the only road has huge traffic jams
[12:37:37] <Compn> its not that big cities themselves are the good part, but they attract the international foods/shops which are better than small town shops ? ehe
[12:37:55] <Compn> of course, big cities have more entertainment ...
[12:38:00] * elenril thinks those are overrated
[12:38:09] <thresh> yes, i only care about entertainment in Moscow
[12:56:09] <DonDiego> does chromium support h264?
[12:56:15] <DonDiego> or just google chrome?
[12:56:30] <DonDiego> both use ffmpeg iirc, but i forget how they built it..
[12:56:41] <DonDiego> does anybody remember the links to the repo?
[12:59:16] <jez9999> anyone know where BBB is?
[12:59:25] <jez9999> he been online recently?
[13:01:26] <janneg> http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob;f=third_party/ffmpeg/README.chromium;h=1aedd7865f1766b9229ad84237738401db6ad7c7;hb=HEAD
[13:01:31] <janneg> DonDiego: ^^^
[13:02:04] <janneg> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/
[13:03:23] <janneg> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium?view=markup
[13:03:54] <janneg> for chromium all except --enable-decoder=theora --enable-decoder=vorbis --enable-demuxer=ogg is disabled
[13:04:26] * elenril just realized he's been muxing flac to avi for about half an hour
[13:04:32] <elenril> and it works o_0
[13:28:20] <superdump> Dark_Shikari: http://gunshotfx.com/libavcodec/
[14:06:43] * superdump wonders why we hadn't added a link to fate from ffmpeg.org yet...
[14:07:29] <kshishkov> devs know, nobody else cares
[14:15:36] <Compn> superdump : you can commit to ffmpeg.org repo at any time :P
[14:15:48] <superdump> indeed i shall
[15:16:01] <CIA-17> ffmpeg: michael * r21644 /trunk/libavformat/avienc.c:
[15:16:01] <CIA-17> ffmpeg: strn muxing in avi support.
[15:16:01] <CIA-17> ffmpeg: untested as ffmpeg.c has no means to set AVStream metadata (patchwelcome)
[15:17:30] <CIA-17> ffmpeg: michael * r21645 /trunk/ffplay.c:
[15:17:30] <CIA-17> ffmpeg: Make sure the rdft has enough audio available.
[15:17:30] <CIA-17> ffmpeg: 10l (looks cleaner now)
[15:19:39] <merbzt> elenril: suck t
[15:19:42] <merbzt> o bye you :)
[15:19:48] <merbzt> be you
[15:20:03] <merbzt> now the avi muxer supports the I meta data flags
[15:20:33] <kierank> next thing we know he'll just RE that neyrink software and write the decoder and also an encoder
[15:20:44] <superdump> neyrink?
[15:21:12] <kierank> company that makes the dolby encoders
[15:21:17] <kierank> whole suite of them iirc
[15:21:23] <elenril> srsly this is getting annoying
[15:21:26] * elenril kicks sdl
[15:22:11] <elenril> merbzt: lol
[15:23:02] <kshishkov> kierank: why they are called "dolby" then?
[15:23:09] * elenril wonders how is he supposed to store utf-8 in avi
[15:23:22] <kshishkov> you are not supposed to do that
[15:23:55] <kshishkov> it's Windows way - either UCS16 or local codepage
[15:24:05] <kshishkov> I'd bet on the second
[15:24:12] <av500> kshishkov: avi supports UCS16?
[15:24:31] <merbzt> elenril: does your metadata work enable the tags to follow the file as you transcode files to other containers ?
[15:24:43] <kierank> [15:23] <@kshishkov> kierank: why they are called "dolby" then? --> because dolby only do hardware
[15:24:45] <kshishkov> av500: I doubt it, but it's more likely than utf-8
[15:24:54] <kierank> also they should be known as trollby
[15:25:07] <av500> kshishkov: for sure, but i guess when they made it up they had ascii in mind
[15:25:08] <elenril> kshishkov: :effort: to implement in ffmpeg
[15:25:09] <kierank> for keeping shit like ac-3 in the market
[15:25:13] <kshishkov> who wrote that ATSC A/52 codec then?
[15:25:43] <kierank> I mean hardware as in hardware encoders
[15:25:50] <elenril> merbzt: that should work even now
[15:26:13] <kierank> hmm apparently dolby do software
[15:26:19] <kshishkov> elenril: to cheer you up a bit - it sucks even more to be _me_
[15:26:35] <elenril> heh
[15:27:15] <elenril> i still find it weird that codec companies aren't fighting over you with your experience
[15:27:31] <CIA-17> ffmpeg: michael * r21646 /trunk/ffplay.c:
[15:27:31] <CIA-17> ffmpeg: make the RDFT vissualizatiom default, the scopes are ugly and eat CPU like
[15:27:31] <CIA-17> ffmpeg: piranhas.
[15:27:44] * kshishkov is not sure how to treat possible invitation from Buffering Inc. though
[15:28:07] <kierank> LOL
[15:28:43] <kierank> reply every minute with Buffering....5%, etc
[15:28:51] <Dark_Shikari> piranhas
[15:28:51] <Dark_Shikari> lol
[15:29:15] <Dark_Shikari> elenril: they don't seem to be interested in people with actual skills
[15:29:18] <elenril> rdft?
[15:29:34] <Dark_Shikari> I haven't received one invitation from a codec company
[15:29:37] <Dark_Shikari> well, encoder, at least
[15:29:38] <kshishkov> real-part discrete Fourier
[15:29:42] <elenril> o_0
[15:30:03] <elenril> you worked for corecodec, right?
[15:30:05] <kshishkov> Dark_Shikari: you seem to have some ties to DivX and CoreCodec though
[15:30:19] <Dark_Shikari> divx?  lol
[15:30:27] <Dark_Shikari> unless by ties you mean "we crashed their halloween party and routinely make fun of them"
[15:30:31] <Dark_Shikari> corecodec doesn't do encoders
[15:30:41] <kshishkov> yes
[15:30:56] <kierank> they said they were going to make an h.264 encoder at one point
[15:31:02] <Dark_Shikari> kierank: if they release one, it will be x264
[15:31:05] <elenril> kshishkov: real-part?
[15:31:16] * elenril should read about discrete ft sometime
[15:31:22] <kshishkov> elenril: yes, no imaginary part of complex numbers
[15:31:54] <kshishkov> elenril: all Fourier transforms around here are discrete - no analogue transforms in digital world
[15:31:57] <elenril> we defined ft only from R->R
[15:31:58] <av500> kshishkov: so they only way to lure you out of .ua is an encoder job?
[15:32:14] <kshishkov> av500: no, almost any job really
[15:33:01] * elenril had integral transformations this semester
[15:33:20] <kshishkov> av500: and it's not "lure", it's mostly "give a possibility to escape from .ua"
[15:33:23] <superdump> Dark_Shikari: did you see the continuation of that h.264 decoding thread on -user?
[15:33:31] <superdump> the guy posted a sample on the page now
[15:33:31] <av500> kshishkov: I know :)
[15:33:36] <Dark_Shikari> idiots being idiots?
[15:33:43] <superdump> so maybe we can check it and tell him what he's doing wrong
[15:34:00] <elenril> what thread?
[15:34:03] <kshishkov> elenril: and I had nothing regarding transforms
[15:34:33] <kshishkov> elenril: not thread, webpage telling lavc H.264 decoder sucks in colours
[15:34:40] <superdump> elenril: one about h.264 decoding being inferior in libavcodec compared to quicktime, final cut, adobe after effects and so on
[15:34:56] <elenril> obvious troll is obvious
[15:35:43] <av500> superdump: also inferior to th***? :)
[15:35:43] <kshishkov> superdump: would be funnier if it turned out to be inferior to Perian, FFdshow and VLC
[15:36:04] <superdump> it would be funnier, yes
[15:36:12] <superdump> i don't think it's trolling
[15:36:23] <superdump> i think it's rather something to do with the way they're handling the decoder output
[15:36:30] <superdump> that differs from what is going on with quicktime
[15:36:45] <superdump> from the screenshots it almost looks like quicktime is adding noise
[15:37:18] <kierank> microsoft does that with mpeg-4 asp iirc
[15:37:30] <kierank> postprocessing you can't turn off
[15:37:51] <kshishkov> "film corn"?
[15:38:06] <superdump> kierank: they do it with wmv
[15:38:18] <superdump> i think you can turn it off with some registry settings
[15:38:33] <superdump> i don't think i've looked at that in about 8 years
[15:38:36] <superdump> lol
[15:38:36] <kshishkov> superdump: Th***a does that too
[15:38:52] <superdump> theora's deblocking is in-loop, no?
[15:39:32] <kshishkov> no, it also employs postprocessing
[15:39:50] <kshishkov> deringing, another deblocking, something else
[15:40:09] <Yuvi> superdump: yes, similar loop filter to h.263's
[15:40:44] <Dark_Shikari> any chance we can ban those trolls from the ML?
[15:41:30] <superdump> Dark_Shikari: which trolls?
[15:41:36] <Dark_Shikari> the ffmpeg-user ones
[15:41:41] <superdump> i would rather figure out what the problem is and conclude the issue
[15:41:50] <superdump> so that if it happens again we can point people to it
[15:42:05] <Dark_Shikari> they won't
[15:42:06] <kshishkov> Dark_Shikari: so you _read_ that list?
[15:42:09] <Dark_Shikari> they refuse to listen to any answers
[15:42:10] <ohsix> Dark_Shikari: http://rationalwiki.com/wiki/Special_pleading
[15:42:11] <Dark_Shikari> therefore, they are trolls
[15:42:14] <Dark_Shikari> therefore, they should be banned
[15:42:19] <superdump> refuse to listen to any answers?
[15:42:22] <superdump> bullshit
[15:42:29] <Dark_Shikari> superdump: read the thread
[15:42:32] <superdump> i did
[15:42:35] <superdump> i've been following it
[15:42:40] <Dark_Shikari> they still do not understand what H.264 is
[15:42:48] <Dark_Shikari> despite having been told by multiple professionals
[15:42:55] <ohsix> you dont listen all that much either Dark_Shikari, i'd just duck out if i were you
[15:42:58] <Dark_Shikari> they follow the "I'm right, everyone else is wrong" methodology
[15:43:30] <superdump> you're not listening to what they're saying - we know the decoder output is identical
[15:43:31] <kierank> lol at that guy who says you can choose to deblock
[15:43:35] <superdump> or it should be
[15:43:39] <Dark_Shikari> superdump: but that isn't what the guys I responded to are saying
[15:43:41] <Dark_Shikari> read again!
[15:43:47] <Dark_Shikari> they insist the deblocker is not only optional
[15:43:52] <Dark_Shikari> but can be performed validly in whatever way the decoder wants
[15:44:02] <Dark_Shikari> and the reason lavc is worse is because "it's deblocking too strong"
[15:44:34] <kshishkov> give them autoinserted pp filter!
[15:44:50] <kshishkov> s/pp/shapness+gauss noise/
[15:45:09] <superdump> he's confused and you're not willing to listen and try to figure out what's wrong
[15:45:21] <Dark_Shikari> I already know what's probably wrong
[15:45:25] <Dark_Shikari> 99% chance, it's a colorspace conversion issue
[15:45:31] <Dark_Shikari> however, he won't listen to me when I told him that
[15:45:45] <elenril> crap, i just did git commit --amend instead of git rebase --continue
[15:45:47] <Dark_Shikari> he is absolutely, utterly convinced that libavcodec must be wrong
[15:45:47] <superdump> he did listen and he's been trying to figure that out code-wise
[15:45:52] <elenril> any way to undo it?
[15:45:54] <Dark_Shikari> Then why is he still claiming the deblocker is wrong?
[15:46:12] <Dark_Shikari> You may be talking about a different "he"
[15:46:19] <superdump> because he doesn't understand
[15:46:28] <Dark_Shikari> um, but you said he did listen
[15:46:35] <Dark_Shikari> and he's "trying to figure out" the colorspace conversion
[15:46:49] <Dark_Shikari> how can he have "listened" and be "trying to figure out" the colorspace conversion _while_ believing that the deblocker is wrong?
[15:46:49] <superdump> he listened, but that doesn't mean he suddenly understands how to fix the problem
[15:46:55] <Dark_Shikari> I didn't say that.
[15:47:01] <Dark_Shikari> If he listened, he should know what _isn't_ the problem
[15:47:13] <Dark_Shikari> considering part of what he should have listened to included an explanation of why that isn't the problem
[15:47:17] <Yuvi> elenril: git reflog, find the unammended commit, do a diff to the current head
[15:48:03] <superdump> in his last e-mail with the updated test after i'd told him about the swscale stuff and you'd told him about the bit exactness of decoding, thomas didn't say anything about deblocking being the issue
[15:48:26] <superdump> he pointed to some flags in swscale that seemed relevant that he's been playing with
[15:48:33] <superdump> but he still has some issue with that
[15:48:44] <Yuvi> not entirely sure how that'll interact with the rebase though
[15:48:44] <Dark_Shikari> um, did you read what I quoted in my emails?!
[15:48:51] <Dark_Shikari> I quoted him saying exactly what you said he didn't say
[15:48:54] <superdump> i haven't read your last e-mail yet
[15:49:48] <superdump> i was referring to his last e-mail, not that one you responded to
[15:51:28] <elenril> hmm, maybe i'll just do a soft reset+add+rebase --continue
[15:54:15] <superdump> Dark_Shikari: i was hoping that you'd have some humility and focus on what the problem might be rather than jumping all over their ignorance of how h.264 works
[15:54:43] <Dark_Shikari> superdump: ignorance is fine
[15:54:45] <Dark_Shikari> I have no problem with ignorance
[15:54:46] <superdump> rather than expending effort being destructive, why not be constructive
[15:54:46] <Dark_Shikari> I never have
[15:54:52] <Dark_Shikari> I have a problem with arrogance
[15:54:57] <Dark_Shikari> with people who insist that they are right, despite being ignorant
[15:54:57] <superdump> clearly
[15:55:11] <Dark_Shikari> ignorance is fine as long as you realize you are ignorant and are willing to learn
[15:55:25] <Dark_Shikari> but the instant you start insisting that your ignorant opinion is right and every professional in the world is wrong
[15:55:33] <Dark_Shikari> I instantly lose every last bit of caring for your position.
[15:56:28] <superdump> aren't you interested in having some provable way to use ffmpeg to provide output that is identical to quicktime/final cut pro/adobe after effects/whatever other widely used tool one might stumble across?
[15:56:31] <Dark_Shikari> Yes
[15:56:33] <Dark_Shikari> of course I am
[15:56:40] <Dark_Shikari> that's why I went out of my way to explain how ffmpeg worked
[15:56:44] <Dark_Shikari> and the difference between libavcodec and swscale
[15:56:48] <Dark_Shikari> and the difference betwee yuv and rgb
[15:56:58] <Dark_Shikari> and at what stage the difference occurs
[15:57:02] <Dark_Shikari> and why it owuld occur
[15:57:04] <Dark_Shikari> and what the proble might be
[15:57:06] <Dark_Shikari> *problem
[15:57:13] <Dark_Shikari> is this still not enough?
[15:57:54] <superdump> feel free to discontinue your involvement in the thread if you're not interested in figuring out how to manage the correct configuration of swscale
[15:58:10] <Dark_Shikari> and people wonder why nobody wants to help on ffmpeg-user
[15:58:16] <Dark_Shikari> support people are treated like utter shit
[15:58:43] <Dark_Shikari> if anyone so much as gets together and helps someone, they get flamed
[15:58:57] <Dark_Shikari> the more useful information they post, the more they get flamed
[15:59:03] <Dark_Shikari> in the end, you end up with an ML full of unanswered questions
[15:59:08] <Dark_Shikari> because nobody wants to help.
[15:59:18] <superdump> maybe the people requesting support would be receptive to correction and information about why they're wrong if they're provided with a solution for their problem first
[15:59:34] <Dark_Shikari> I already told them the problem: it's a BT.709 vs BT.601 issue
[15:59:38] <Dark_Shikari> this is a long-standing problem with swscale
[15:59:48] <superdump> one that i think can be worked around
[15:59:57] <Dark_Shikari> it doesn't pass BT.601/BT.709 flags correctly from libavcodec
[16:00:24] <superdump> http://git.ffmpeg.org/?p=libswscale;a=blob;f=utils.c;h=928a5fd85e5480dbbb005604eb3fa7d2b0143080;hb=HEAD#l910
[16:00:27] <superdump> no
[16:00:30] <superdump> but maybe one can code something to do it
[16:01:01] <Yuvi> hm, did I not apply my patch series
[16:01:06] <Yuvi> not that it'd probably help in this case
[16:01:09] <superdump> and
[16:01:11] <superdump> http://git.ffmpeg.org/?p=libswscale;a=blob;f=swscale.h;h=9e14262d30f4311ef7fbc419cf1515a57b292d0b;hb=HEAD#l198
[16:01:35] <Dark_Shikari> btw, 601 is used for SD and 709 for HD, right?
[16:01:49] <kierank> yes
[16:01:55] <superdump> i think if one called getContext first and then called that function afterwards with the correct parameters, it would work correctly
[16:02:05] <superdump> according to wikipedia at least, yes
[16:02:25] <superdump> i was thinking maybe we could autodetect within get context and set the right option rather than just using default
[16:02:29] <Yuvi> whoops, michael approved them (for this) but I never pushed
[16:02:40] <superdump> or maybe expose the available options in sws
[16:02:56] <superdump> Yuvi: you have options for controlling whether BT.601/709 are being used?
[16:03:22] <elenril> hmm, this new visualisation is nice
[16:04:34] <Yuvi> superdump: yeah, not too user friendly though since it needs -colorspace 4 or something like that to manually change it
[16:04:45] <Yuvi> let me find them and push
[16:04:55] <superdump> well, we can fix that up pretty easily i guess
[16:04:59] <superdump> add an option somewhere
[16:05:34] <superdump> Yuvi: but, if it's at all doable, that's great
[16:07:47] <Dark_Shikari> superdump: there, that better?
[16:09:49] <superdump> yes
[16:09:53] <superdump> thank you very much :)
[16:10:05] <superdump> that's precisely the kind of answer i was looking for
[16:13:24] <superdump> Yuvi: are you having any luck finding them?
[16:14:14] <Yuvi> http://pastebin.com/m6f194a37 just need to double check a concantenated fullrange -> mpeg range and back conversion
[16:14:42] <superdump> cool
[16:15:23] <superdump> in this case i think BT.709 is 16..235
[16:15:33] <Dark_Shikari> fullrange and 709/601 are independent iirc
[16:15:42] <Dark_Shikari> you can have any of the 4 possible combinations
[16:16:05] * elenril wonders why doesn't ffplay exit at EOF
[16:16:13] <elenril> is this a bug or a feature
[16:16:17] <kshishkov> feature
[16:16:27] <kshishkov> useful for image viewing
[16:16:32] <elenril> oh
[16:16:35] <kshishkov> and seeking back
[16:18:16] <superdump> Dark_Shikari: in terms of coefficients and full-/mpeg-range being orthogonal, definitely
[16:18:47] <Vitor1001> anyone thinks that quicktime is doing some pos-processing behind users back?
[16:18:49] <superdump> but in terms of the specs, i think BT.601 and BT.709 also define the range as 16..235 as well
[16:18:53] <superdump> but maybe i'm wrong
[16:18:58] <superdump> Vitor1001: possibly, yes
[16:19:01] <Vitor1001> it looks like at least they are adding noise
[16:19:04] <superdump> the quicktime images look noisier
[16:19:08] <superdump> yup
[16:19:14] <Vitor1001> looks like a valid lavfi feature request
[16:19:17] <superdump> honestly, it does look better
[16:19:33] <Vitor1001> "-vfilters happy_machead"
[16:19:34] <superdump> to my eyes
[16:19:37] <superdump> lol
[16:20:21] <Dark_Shikari> superdump: that's not exactly news, vorbis has been doing it for years ;)
[16:20:26] <jai> lol
[16:20:45] <superdump> dithering?
[16:21:34] <Dark_Shikari> no
[16:21:36] <Dark_Shikari> noise
[16:21:45] <Dark_Shikari> not merely diterhing helps perceptual quality
[16:21:46] <Dark_Shikari> noise does too
[16:21:53] <Dark_Shikari> because of the energy preservation idea
[16:22:01] <kshishkov> noise, dithering, what's the difference?
[16:22:11] <Dark_Shikari> dithering covers up lack of bit depth
[16:22:14] <Dark_Shikari> it is extremely limited
[16:22:16] <Dark_Shikari> and +/-1 only
[16:22:21] <Dark_Shikari> noise is much stronger
[16:28:19] <superdump> ah, i see
[16:28:23] <superdump> that's interesting
[16:28:28] <superdump> Dark_Shikari: added decoder-side?
[16:29:41] <Dark_Shikari> superdump: no, probably after the decoder
[16:29:50] <Dark_Shikari> or are you talking about vorbis?
[16:32:30] <superdump> vorbis
[16:33:13] <Dark_Shikari> vorbis adds it on encoder-side
[16:33:19] <Dark_Shikari> CELT adds it decoder-side as part of dequantization
[16:33:50] <superdump> interesting indeed
[16:33:59] <superdump> well, whatever aids lossy compression :)
[16:34:07] <Dark_Shikari> the reason vorbis doesn't do decoder-side is that they didn't realize it until after bitstream being frozen
[16:34:20] <superdump> they didn't realise what?
[16:34:27] <superdump> they were adding noise?
[16:35:52] <Dark_Shikari> that conserving energy was the single most important psy optimization
[16:39:08] <superdump> :)
[16:39:21] <superdump> ain't physics great?
[16:39:41] <kshishkov> looking at people in general - it ain't
[16:40:23] <superdump> Yuvi: looking at that patch you pasted, that'll work if the decoder can set the correct colour space/standard/whatever you want to call it
[16:40:55] <superdump> so then we need to make sure it's right and/or accessible in ffmpeg
[16:41:02] <superdump> you said there's a -colorspace option?
[16:41:07] * superdump looks at the help output
[16:41:25] <superdump> yup
[16:41:28] <superdump> right
[16:43:04] <CIA-17> libswscale: conrad * r30513 /trunk/libswscale/ (swscale.h yuv2rgb.c): Add function to translate SWS_CS_* to coefficient array
[16:52:46] <Yuvi> superdump: yep, only mpeg2, h.264, and theora export that atm, dunno how many more codecs could set it
[16:53:35] <Yuvi> and it looks like swscale doesn't support this for yuv -> yuv or rgb -> yuv, only yuv -> rgb
[16:59:29] <superdump> ok
[16:59:48] <superdump> so for RGB input we can't choose BT.709?
[17:00:00] <superdump> does it just assume BT.601?
[17:00:27] <Yuvi> I think so
[17:11:49] <elenril> anyone knows if nut tags are case sensitive?
[17:15:52] <kshishkov> nut spec should know
[17:16:58] <elenril> it doesn't
[17:17:23] <elenril> ie it doesn't say anything => they're case sensitive
[17:17:28] <elenril> but that's braindead
[17:17:50] <elenril> so i'd rather assume someone just forgot to write it
[17:51:24] <Compn> intel guy didnt give me a list of supported boards either
[17:51:38] <Compn> Yes, this GPU is only on Atom boards but not all Atom boards have this. By lspci you can find out how the video is enabled. If the VGA compatible controller shows SCH Poulsbo then you know it uses SGX core.
[17:53:58] <elenril> ah, that evil proprietary crap :)
[17:54:32] <elenril> iirc gma x4500 have vaapi support too
[17:57:19] <Compn> arent they all proprietary?
[17:57:24] <Compn> nvidia, ati and intel ?
[17:59:15] <elenril> intel is free
[17:59:26] <elenril> except for this gma 500, but it's not really intel
[18:08:42] <iive> well, most users with video driver problems have intel, yesterday somebody had problem with intel audio card... i've personally reported bugs for intel lan cards, and i'm not sure if the fix/workaround hit mainstream...
[18:09:20] <kshishkov> +1 for realtek?
[18:09:27] <elenril> intel doesn't make audio cards afaik
[18:09:40] <iive> no, they embed everything
[18:09:48] <kshishkov> Centrino FTW
[18:09:55] * superdump has an intel gma h4500mhd
[18:10:02] <superdump> erm
[18:10:06] <elenril> these "intel" cards have realtek chips
[18:10:10] <elenril> or something like that
[18:10:13] <superdump> i swear i typed x4500mhd
[18:10:16] <superdump> in my head
[18:10:19] <superdump> :)
[18:16:37] <elenril> did location of preset change recently?
[18:18:08] <Kovensky> <+elenril> intel doesn't make audio cards afaik <-- the hdaudio spec is from them IIRC
[18:18:16] <elenril> i know
[18:18:30] <Kovensky> < iive> well, most users with video driver problems have intel <-- and sis, and via...
[18:18:32] <elenril> but afaik they don't actually make any cards
[18:19:04] <iive> Kovensky: sis anv via... i can't remember last time somebody got that...
[18:19:35] <Kovensky> well, sis users can't have sis video driver problems, there ISN'T a video driver
[18:19:52] <elenril> my sister has a via card
[18:20:31] <elenril> official drivers are pretty much nonexistent, openchrome is very slow, doesn't support 3d, etc
[18:20:52] <kshishkov> wanna Trident video with 512kB RAM?
[18:21:09] <elenril> intel drivers have some problems, but they're _much_ better than via
[18:21:20] <iive> elenril: intel doesn't make any standalone video cards, yet they own more than half of the market.
[18:21:36] * Kovensky would be glad to have an intel igp
[18:21:46] <elenril> iive: i was talking about audio cards
[18:21:55] <iive> ever heard of ac97?
[18:22:11] <elenril> afaik they do manufacture gma
[18:22:19] <elenril> sure, so?
[18:22:45] <kshishkov> elenril: developing, producing and labeling are 3 separate stages
[18:22:51] <iive> it's intel invention. i'm not sure what hda is, but every kernel patch have a lot of changes in it. it's intel too.
[18:23:12] <Kovensky> aren't the gma by imagine systems?
[18:23:30] <elenril> kshishkov: i know that =p
[18:23:59] * elenril kicks ffmpeg for 'av_interleaved_write_frame(): Error while opening file'
[18:24:43] <elenril> Despite similarities, Intel's main series of GMA IGPs is not based on the PowerVR technology Intel licensed from Imagination Technologies
[18:24:48] <elenril> ^wikipedia
[18:25:09] <kshishkov> and I thought PoverVR is for embedded devices
[18:26:32] <iive> it is bad idea to accept everything wikipedia says as undoubtful truth
[18:26:58] <kshishkov> yes, look what they wrote about Bink
[18:27:14] <kshishkov> has someone seen wavelets in it?
[18:27:24] * iive points at kshishkov 
[18:27:44] <elenril> kshishkov: add them ;)
[18:28:01] <elenril> btw when are you finally going to commit bink decoder? :)
[18:28:12] <kshishkov> when it's reviewed :P
[18:29:08] * kshishkov thinks whom to kick for final Indeo 5 decoder review
[18:33:13] <elenril> indeo? who uses that?
[18:33:26] <iive> there are a lot of legacy videos with it.
[18:33:32] <iive> some of them from games.
[18:34:01] <kshishkov> not so popular as Indeo 4 for some reason though...
[18:34:14] <elenril> everybody switched to bink ;)
[18:36:47] <kshishkov> we don't have decoder for it either :P
[18:43:04] * elenril wonders if it'll be possible to steal matroska index writing code for nut
[18:43:39] <kshishkov> why?
[18:43:53] <elenril> because i'm too lame to write it from scratch
[18:44:19] <Yuvi> the nut muxer doesn't write an index?
[18:44:30] <kshishkov> it does not
[18:44:30] <elenril> afaik no
[18:44:34] <kshishkov> not lavf one
[18:44:41] * kshishkov recodes into nut now
[18:44:51] <elenril> (but now it writes all metadata :) )
[18:45:03] <Yuvi> huh, I thought the spec pretty much required one for files not intended to be streamed live
[18:45:26] <kshishkov> still, lavf does not create index for them
[18:46:03] <elenril> An index packet to facilitate O(1) seek-to-time operations may follow
[18:46:10] <elenril> not required
[18:47:37] <kshishkov> I'd like it to store real duration time instead
[18:48:04] <elenril> i think it's stored in index
[18:48:13] <kshishkov> lol
[18:48:17] <elenril> at least if i understood the specs
[18:59:35] <elenril> wtf does dereferencing type-punned pointer will break strict-aliasing rules mean?
[19:00:30] <kshishkov> a warning on place where compiler may botch your code
[19:01:27] <elenril> lol
[19:01:32] * elenril should learn c sometime
[19:01:41] <kshishkov> really
[19:04:39] <elenril> maybe i shouldn't have used mru's evil black magic
[19:32:28] <Yuvi> huh, I did not know that there was legal precedent for H.264 being safe from submarine patents
[19:32:39] <superdump> oh?
[19:32:46] <Yuvi> http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Patent_licensing
[19:33:15] <Yuvi> qualcomm lost its case for applying its patents to h.264 since they didn't disclose them to JVT by 2003
[19:34:08] <Yuvi> ofc, one of them (http://www.freepatentsonline.com/5576767.pdf) seems like it applies to just about any video codec
[19:36:44] <superdump> then only the question of whether there are patents not licensed by the mpeg-la
[19:36:46] <superdump> oops
[19:37:18] <superdump> i want to ask the question of whether there are patents not licensed by the mpeg-la that were disclosed to jvt before h.264's release
[19:39:57] <elenril> no such patents exist
[19:59:24] <janneg> Yuvi: but only since qualcomm was participating in JVT.
[20:00:39] <janneg> ther could be still h264 submarine patents from everyone not involved in JVT. it's unlikely
[20:11:42] <superdump> Dark_Shikari: i have unbanned ohsix. i suggest you both resolve your differences or refrain from devolving into petty arguments or maybe even refrain from talking to each other at all if you so choose
[20:11:47] <superdump> there's always /ignore
[20:30:25] <m4k3r> hi. I think there are some missing spaces on libavutil/mem.c . The patch is here: ffmpeg.pastebim.com/d23774b55 . If someone could apply without sending to the ml - it's really stupid - ..
[20:33:25] <janneg> http://ffmpeg.pastebin.com/d23774b55
[20:33:46] <m4k3r> uh, sorry.
[20:33:55] <janneg> assuming the typo wasn't intended to spam
[20:35:49] <janneg> m4k3r: I doubt anyone will apply that patch, are those the only 4 occurances of no space before '='?
[20:36:18] <m4k3r> yep. That's fot that
[20:36:48] <m4k3r> *for that that I haven't send it to the ml.
[20:45:11] * elenril wonders if nut spec is obfuscated on purpose
[20:51:01] <Yuvi> elenril: that's how micheal actually thinks ;)
[20:52:15] <elenril> heh
[23:04:20] <CIA-17> ffmpeg: stefano * r21647 /trunk/libavformat/avio.h: Doxument url_fdopen().
[23:25:01] <CIA-17> ffmpeg: stefano * r21648 /trunk/libavdevice/avdevice.h: Satisfy style nits.