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

[irc at mansr.com]

[00:03:25] <ramiro> thanks
[00:52:44] <ramiro> did google just add an annoying and ugly left sidebar?
[00:53:12] <kierank> they are probably a/b testing it
[00:54:03] <ramiro> i had seen it in google.com.br, which I usually avoid, but not in normal google.com
[00:54:18] <astrange> i think it was already present but optional, and now they're testing making it default
[00:55:20] <ramiro> is it removable?
[00:55:34] <ramiro> I'm still not happy about the bigger search box
[03:26:13] <Kovensky> ramiro: google.com insists on redirecting to .com.br for me, and also insists on enabling hl=pt-BR unless I set the hl=en-US cookie
[03:26:41] <Kovensky> <@astrange> i think it was already present but optional <-- Labs feature?
[03:32:27] <saintdev> Kovensky: you can set your language settings in the preferences
[03:32:44] <Kovensky> that's what I meant by setting the cookie
[03:33:36] <saintdev> well it sounded like you were setting the cookie manually :p
[03:33:50] <Kovensky> :p
[04:31:42] <Dark_Shikari> hmm, we need to add intra refresh and crf max to ffmpeg
[04:52:21] <Dark_Shikari> http://pastebin.org/204244
[04:52:27] <Dark_Shikari> quick patch review, anyone feel free to complain
[04:52:38] <Dark_Shikari> oh, I need to bump minor version number right?
[04:57:39] <Dark_Shikari> anyone?
[04:58:50] <astrange> PIR can't be a flags2?
[04:58:56] <Dark_Shikari> oh, good point
[05:02:32] <Dark_Shikari> astrange: http://pastebin.org/204254
[05:04:46] <astrange> it doesn't matter that it's not !!(avctx->flags2 & CODEC_FLAG_PASS1) ?
[05:04:52] <astrange> i don't see anything else
[05:04:56] <Dark_Shikari> x264 boolifies itself.
[05:05:33] <Dark_Shikari> oops, need to update the help text
[05:11:43] <Dark_Shikari> lol, pass1
[05:11:45] <Dark_Shikari> oops
[05:26:18] <KotH> god morgon
[06:02:15] <elenril> o_0 chromium? in debian main?
[06:03:50] <saintdev> must be v1.0*
[06:03:52] <saintdev> :P
[06:04:08] <saintdev> because it's *moar stable*
[06:04:39] * elenril wonders why doesn't it depend on ffmpeg
[06:05:25] <saintdev> because it uses an internal library.
[06:15:36] <benoit-> moin
[06:30:42] <scaphilo> how does this work: Lets say you have a interleased mpeg2 intra field picture (top field) and a following p field picture (bottom field). the p field picture refers a past past bottom field . Is this a reconstructed  value then?
[06:31:12] <Dark_Shikari> the p field picture references the top field
[06:31:13] <scaphilo> or does it refer the top field of the past intra?
[06:31:17] <Dark_Shikari> yes, bottom field can reference top field
[06:31:25] <Dark_Shikari> this is only allowed in field coding (not mbaff obviously)
[06:31:29] <astrange> you found an mpeg2 with field pictures?
[06:31:42] <astrange> i never did remember where i got one
[06:32:28] <scaphilo> am yes i think unforunatly my testvideos have some of them
[06:32:34] <Dark_Shikari> for some reason it's not used very often
[06:32:37] <Dark_Shikari> I'm not quite sure why
[06:32:40] <Dark_Shikari> paff is rather popular in h264
[06:32:52] <Dark_Shikari> Maybe it's because mbaff is really fucking difficult to implement in h264, while it's trivial in mpeg-2 by comparison
[06:33:01] <scaphilo> :-)
[06:33:59] <scaphilo> thx for help
[07:54:35] <elenril> lol at chromium proxy settings redirecting me at http://code.google.com/p/chromium/wiki/LinuxProxyConfig
[10:09:06] <j-b> 'morning
[10:11:07] <av500> gm
[10:12:41] <av500> j-b: beer was even paid for my microsoft :)
[10:12:49] <av500> err, by microsoft
[12:01:58] <lu_zero> beer?
[12:01:59] <lu_zero> where?
[12:02:06] <lu_zero> (good $morning)
[12:02:18] <mru> no beer here... :-(
[12:02:20] <kshishkov> in Redmond, Massachusets :)
[12:02:45] <lu_zero> mru: here just tonic water =)
[12:03:01] <mru> without gin?
[12:03:09] <lu_zero> just tonic water
[12:03:22] * mru likes it better with gin and lemon
[12:03:24] <kshishkov> mru: they really have to be careful when driving FIATs
[12:04:08] <lu_zero> kshishkov: they who?
[12:04:27] <kshishkov> lu_zero: Italians, especially near Torino
[12:04:38] <lu_zero> kshishkov: here we know better =P
[12:05:08] * lu_zero doesn't use fiat
[12:05:22] <kshishkov> good for you
[12:05:26] <lu_zero> AND after they messed up putting wince on their new models I think I won't.
[12:05:30] <lu_zero> ever
[12:06:01] <av500> lu_zero: beer in paris last night
[12:06:07] <lu_zero> oh
[12:06:13] <lu_zero> too far from me =P
[12:06:19] * kshishkov hates iat for licensed Fiat 124 clones
[12:06:19] <av500> j-b missed getting free beer paid by M$
[12:06:32] <mru> why where they handing out beer?
[12:06:38] <thresh> doesnt that make you some kind of a renegade?
[12:06:50] <av500> mru: ex-coworker is M$ now
[12:07:03] * lu_zero wants to organize something here sooner or later
[12:07:12] <av500> so we talked shop for 5min and it was a business meeting :)
[12:07:39] <av500> he could have told j-b about how to add PlayReady to vlc :)
[12:07:52] <lu_zero> PlayReady?
[12:07:58] <av500> M$ drm
[12:08:17] <j-b> av500: shit...
[12:08:28] <j-b> av500: does anyone still care about PlayReady ?
[12:08:30] <lu_zero> PlayNever, PayAlready?
[12:08:45] <av500> j-b: it seems to be pickung up
[12:11:00] <j-b> av500: again? fuck.
[12:11:05] <j-b> av500: for videos?
[12:11:06] <lu_zero> I wonder why
[12:11:08] <lu_zero> it's pointless
[12:11:22] <av500> j-b: yes
[12:12:26] <j-b> av500: so like FairPlay, its usage is picking up
[12:13:23] <av500> is it?
[12:13:43] <av500> i thought all appl video stuff was drmed from the start, no?
[12:14:03] <kshishkov> only on iPods
[12:15:01] <j-b> av500: all iTunes things are DRM'd now
[12:15:09] <j-b> it wasn't always the case
[12:17:02] <spaam> j-b: not all things are DRM'd . didnt they remove it from the music ?
[12:17:23] <av500> j-b: ok
[12:17:51] <av500> m$ guy said its also due to larger resolutions now
[12:18:37] <kshishkov> i.e. they finally got stuff with quality worth protecting
[12:20:40] <j-b> spaam: integrally yes.
[12:23:46] <Kovensky> mru: lol @ that __STDC_CONSTANT_MACROS patch
[12:24:27] <spaam> time to change ffmpeg to c++ ?;P
[12:24:38] <mru> no, time to change c++ to ffmpeg
[12:26:52] <Kovensky> nah, TRWTF is that he undeffes _STDINT_H so he can include stdint again
[12:26:52] <Kovensky> lol
[12:27:23] <mru> yeah
[12:27:42] <mru> which is in itself multiple WTFs
[12:32:07] <spaam> Tjoppen: got a new name? ;)
[12:34:20] <Kovensky> lol, on arch-general ML:
[12:34:24] <Kovensky> "I was reading the "about" page (http://www.archlinux.org/about/) in the archlinux website and I noticed that this line is a little outdated: "Arch also offers an [unsupported] section in the Arch Linux User Repository (AUR), which contains over 9,000 build scripts" It should say "over 21.000 build scripts"."
[12:35:02] <kshishkov> it's still true, 21000 > 9000
[12:35:55] <Kovensky> missing the point :(
[12:36:27] <spaam> :)
[12:36:29] <kshishkov> deliberately
[12:41:54] <j-b> av500: does an open-source lib break those DRM ?
[12:42:10] <Tjoppen> spaam: ?
[12:42:49] <spaam> Tjoppen: look what declan harrison  called you.. tom..  i though your name was Tomas.. ;D
[12:43:22] <Tjoppen> oh. hah :)
[12:44:26] <av500> j-b: an open src lib by itself does not break anything
[12:44:47] <av500> but I doubt playready spec is open to open src imlementation
[12:44:53] <Tjoppen> he brings up a good point though; I should put that patch up on the list for people to look at
[12:45:37] <Tjoppen> but at the moment I have more pressing matters: fika
[12:48:40] <spaam> Tjoppen: fika <3
[13:00:07] <ramiro> we should change libavfilter/parseutils.c:color_table to follow http://xkcd.com/color/rgb.txt
[13:00:32] <ramiro> (based on http://blog.xkcd.com/2010/05/03/color-survey-results/ )
[13:01:14] <av500> ramiro: it misses one color: "bikeshed"
[13:02:16] <ramiro> av500: we already have that one, its rand().
[13:02:36] <ramiro> (we actually do somewhere in libavfilter, I'm not kidding =)
[13:05:17] <janneg> indeed if (!strcasecmp(color_string, "random") || !strcasecmp(color_string, "bikeshed")) {
[13:37:27] <Kovensky> "A couple dozen people embedded SQL ‘drop table’ statements in the color names. Nice try, kids." <-- blame yourself
[13:37:30] <Kovensky> lol
[13:37:51] <mru> bobby tables...
[13:37:58] <kshishkov> yes
[13:38:03] <thresh> :-)
[13:40:44] <thresh> nice trolling, http://www.youtube.com/watch?v=B4n7wo8rvTM
[13:41:39] <kshishkov> nice timing on reporting it too, BBB has just joined
[13:41:48] <BBB> hi
[13:41:56] <thresh> kshishkov: well, mru is always around here also ;-)
[13:43:11] <thresh> [root at ntpd /]# mkdir
[13:43:11] <thresh> Segmentation fault
[13:44:00] <spaam> eh?
[13:44:04] <kshishkov> try "ls /lib"
[13:44:24] <thresh> nah, this is VPS after some FS corruption on a host node
[13:55:09] <BBB> kshishkov: what was I needed for?
[13:55:37] <kshishkov> for watching http://www.youtube.com/watch?v=B4n7wo8rvTM
[13:57:05] <BBB> oh
[13:57:17] <BBB> the guy screaming was a lunatic homeless person apparently
[14:41:55] <BBB> is it just me or is this avctx extradata "thing" heavily overengineered?
[14:42:09] <av500> its a char buffer
[14:42:36] <mru> it's as simple as it can possibly be
[14:43:03] <BBB> that's fine
[14:43:14] <BBB> but his patch has 100 lines of code in iff.h to "get" these chars
[14:43:20] <BBB> I meant that part
[14:43:33] <av500> that is codec dependent
[14:43:48] <av500> no?
[14:43:59] <BBB> the GET_EXCTX_INT8/16/32/64, PUT_EXCTX_INT*, EXTRA_CONTEXT_*, etc.
[14:44:07] <av500> for lavf xtradata is an opaque char array
[14:44:36] <mru> wtf, that looks wrong
[14:44:38] <BBB> it'd be much less code to just write a 10-line doxy in iff.h documenting this
[14:44:43] <mru> he should be using the bytestream.h stuff
[14:44:59] <BBB> and then implement it without this bloatware plainly using bytestream api
[14:46:24] <peloverde> also WTF is the deal with those NULL checks?
[14:47:55] <BBB> I'll review it later today
[14:48:09] <BBB> wanted to make sure it wasn't something people told him to do for some maybe-good reason
[14:48:41] <av500> ppl told him to store his stuff portably
[14:48:54] <av500> as in dont memcpy a struct to xtradata
[14:49:12] <BBB> right, I remember that
[14:49:15] <BBB> which is good
[14:49:21] <BBB> and then mru told him to use bytestrea.h right?
[14:49:24] <BBB> so what happened
[14:49:27] <BBB> where did it go wrong? :)
[14:49:51] <av500> bytestrea.h not found :)
[14:49:55] <wbs> he wrote more than 5 lines of own code without consulting anybody? ;P
[14:50:00] <mru> he strikes me as a bit oldschool/amiga
[14:50:07] <mru> we have to get him out of that mindset
[14:50:07] <wbs> mru: oh, really? ;P
[14:50:45] <av500> he lacks the 5y lurk and learn bit
[14:51:03] * av500 is in year 2...
[14:51:09] <merbzt> mru: you truely are the master of sarcasm
[14:51:22] * BBB agrees with mru
[14:51:23] <BBB> he will learn
[14:51:34] <BBB> I think he has great potential
[14:51:52] <av500> at least he can keep the amiga port alive
[14:52:09] <BBB> av500: where's your next ptch? :)
[14:52:13] <kshishkov> BBB: don't say that until he delivers something really impressive, preferably REd
[14:52:21] <av500> BBB: hmm, another one?
[14:52:41] <BBB> lol :)
[14:53:53] * av500 svn ups
[14:54:10] <lu_zero> yawn
[14:57:58] <kshishkov> each time you svn up, lu_zero yawns
[14:59:25] <lu_zero> kshishkov: not that often
[14:59:41] * lu_zero is bored
[15:00:19] * av500 svn ups
[15:00:48] <mru> lu_zero: try flaming the c++ fool
[15:01:58] <peloverde> I don't see why he considers "#define __STDC_CONSTANT_MACROS" / "-D__STDC_CONSTANT_MACROS" so burdensome
[15:02:18] <mru> seems pretty light compared to coding in c++ in the first place
[15:02:59] <Tjoppen> incidentally, I also noticed that C++ issue but instead of nagging the list I simply added -D__STDC_CONSTANT_MACROS. that enabled me to remove a bunch of such #defines from my code, since other libs also require it
[15:05:46] * lu_zero did that in flux
[15:06:28] <lu_zero> mru: seems others are doing as well
[15:06:38] <lu_zero> and overall it's a pointless exercise
[15:06:51] <mru> oh, come on
[15:06:59] <mru> it's not every day you get a FRENCH C++ troll
[15:07:24] <janneg> if I weren't working on a ffmpeg using C++ application I would vote to rename a few variables class and new in avcodec.h
[15:07:42] <lu_zero> janneg: that's evil
[15:07:48] <mru> I'd approve it
[15:08:01] <lu_zero> eh...
[15:08:04] <mru> next time I write a library I'm going to do that
[15:09:25] <lu_zero> in order to actively deprecate C++ we'd need something that works good for that task
[15:09:53] <lu_zero> the problem is that we cannot see any use for C++ beside causing headache
[15:14:50] <kshishkov> mru: but it looked to me that we got more treaullaux that trolls
[15:15:19] <mru> kshishkov: eau only works in the last syllable
[15:15:29] <mru> at least that's my heuristic
[15:15:36] <j-b> Lol, it is Eric Valette...
[15:15:41] <mru> actual french-speakers can correct me
[15:15:47] <kshishkov> j-b ?
[15:15:49] <mru> j-b: you know that troll?
[15:15:55] <j-b> s/troll/moron
[15:16:51] <kshishkov> mru: I remember several French lasting trolls, both independent and from Divx and Google
[15:17:17] <mru> you mean robux4?
[15:17:23] <mru> he's alright
[15:17:29] <mru> he came to his senses
[15:17:37] <kshishkov> what about Frank?
[15:17:59] <mru> does he wear a rabbit suit?
[15:18:19] <j-b> well, robux4 is nice, but the bloat MKV can be is a bit his fault
[15:18:31] <mru> it is his fault
[15:18:41] <j-b> like, DVD menus inside MKV
[15:19:04] <mru> but he's listening to my advice on an update to the format
[15:19:11] <kshishkov> well, he could end with ISO image inside MKV
[15:19:42] <lu_zero> sounds interesting
[15:19:47] <lu_zero> pointless but interesting
[15:19:48] <av500> when can I have that feature
[15:20:22] <lu_zero> citing libc as an example of "good behaviour for C++" is quite strange
[15:20:39] * kshishkov checks pig airports
[15:20:46] <kshishkov> av500: not today, I fear
[15:20:54] <peloverde> use of libc headers from C++ is deprecated
[15:21:11] <mru> talk about reinventing the wheel
[15:21:49] <peloverde> Basically they have wrappers now that are preferred
[15:22:04] <lu_zero> mostly because they hide the define stuff
[15:22:19] <mru> they could do that without changing the names
[15:22:54] <peloverde> but they threw the C compatibility angle out ages ago when they broke "char *foo = malloc(16);"
[15:23:04] <mru> by using a different header search path and compiler extensions like include_next
[15:23:17] <lu_zero> #include <cfoo> instead #define __I_M_A_FOOL #include <foo.h>
[15:23:32] <kshishkov> mru: please add "
[15:23:41] <kshishkov> int new" somewhere into FFmpeg headers
[15:23:55] <mru> it's tempting
[15:24:22] <mru> we could screw with people using gnu99 mode too by calling something asm
[15:24:24] <kshishkov> or "int class", it can be fitted in many places
[15:25:12] <lu_zero> bettalso *_cast
[15:26:19] <j-b> You C++ haters! You French haters! You FT haters! Bad people, bad!
[15:26:26] <lu_zero> FT?
[15:26:30] <j-b> France Telecom
[15:26:42] <lu_zero> I don't care much
[15:26:46] <j-b> orange-ftgroup.com
[15:26:54] <j-b> Eric est toujours aussi con :)
[15:27:07] <peloverde> I recall them being responsible for one of the more obnoxious parts of 14496-3
[15:27:15] <peloverde> so yes I do hate them
[15:27:18] <peloverde> them and NTT
[15:27:42] <peloverde> NTT who decided a twinVQ variant belonged in 14496-3
[15:27:59] <kshishkov> well, VQF was purely their creation
[15:28:36] <peloverde> yes but do we need a non VQF twinvq format in 14496-3 sp 04?
[15:29:09] <kshishkov> because MPEG-4 Audio is versatile
[15:29:12] <peloverde> they are just shoehorning shit in there to try to get patent royalties
[15:30:33] <av500> they have little kids to feed
[15:30:37] <av500> think about the children
[15:30:45] <wbs> gah, even after being hinted that one shouldn't use structs for writing extradata, he _still_ uses that
[15:30:57] <wbs> regarding the iff/amiga stuff...
[15:31:07] <peloverde> I hope their children are forced to implement all of -3, especially the underspecified parts
[15:32:35] <lu_zero> wbs: where?
[15:32:51] <wbs> lu_zero: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088036.html
[15:32:51] <kshishkov> peloverde: children labour is prohibited in many countries
[15:33:08] <wbs> lu_zero: the one BBB mentioned a while ago
[15:33:31] <lu_zero> ah
[15:34:09] <mru> kshishkov: great, then we can have them arrested
[15:35:05] <lu_zero> mru: the children or the vqf shoehorners?
[15:42:27] <mru> if we're lucky, both
[15:45:44] <av500> BBB: there: http://ffmpeg.pastebin.com/YBxmYhc4
[15:46:12] <mru> isn't there generic code for that?
[15:46:51] <av500> pcm_Read_seek() with blockalign=1 maybe
[15:48:27] <av500> thats what I used and simplified
[15:52:47] <mru> I thought there was some shared code for such things
[15:54:04] <av500> looking for it
[15:55:33] <jai> av500: isnt there a seektable ?
[15:56:47] <av500> seems not
[15:57:13] <jai> av500: http://flac.sourceforge.net/format.html#seekpoint
[15:57:15] <mru> flac has an optional index
[15:57:41] <jai> yes, and we should use that if present
[15:57:55] <av500> never saw one
[15:59:29] <av500> hmm, why does av_index_search_timestamp() works for .mp3?
[15:59:35] <av500> and not for flac
[17:11:55] <peloverde> I can't believe I wasted the whole morning trolling on the ML
[17:12:12] <Dark_Shikari> what's wrong with trolling
[17:13:40] <pJok> trolling is never waste
[17:13:45] <pJok> if applied correctly that is
[17:19:56] <Kovensky> peloverde: "So you are asking our project to behave more like glibc? Be careful"
[17:20:00] <Kovensky> what you wish for...
[17:20:02] <Kovensky> lol
[17:20:04] <Kovensky> durf @ irssi breaking the quote
[17:21:23] <BBB> peloverde: well done though \o/
[17:21:34] <BBB> some memorable quotes
[17:24:57] <Kovensky> "You're dangerously close to invoking Godwin's law there." <-- lol mru
[17:25:43] * elenril thinks hitler would have used c++
[17:25:56] <Kovensky> durf, why are so many messages that appear, then get broken in the middle by o9k mail headers, then get included all over again but correctly
[17:26:02] * Kovensky blames thunderbird
[17:26:16] * jai rues the fact that libmatroska is written in c++
[17:26:28] <elenril> who uses libmatroska
[17:26:40] <jai> vlc native demuxer
[17:26:53] <elenril> why not use lav....nvm
[17:27:07] <elenril> why not use mplayer ;)
[17:27:09] <jai> lavf can be sued as well
[17:27:11] <jai> err
[17:27:12] <jai> *used
[17:27:19] <Kovensky> please dont sue us
[17:27:37] <jai> maybe it could even be bump up to default
[17:27:42] <jai> *bumped
[17:27:50] * Kovensky still considers lavf completely unusable for matroska until aurel fixes ASS demuxing
[17:27:56] <elenril> ^this
[17:28:09] * Kovensky also still considers it completely unusable while aurel and michael block ordered chapters
[17:28:09] <jai> wasn't that fixed?
[17:28:24] <elenril> nobody is blocking ordered chapters
[17:28:24] <Dark_Shikari> and that whole thing about ffmpeg going into an infinite loop when decoding dirac from matroska
[17:28:32] <Dark_Shikari> and other similar bugs
[17:28:36] * Compn considers embedded subtitles blah anyways, external ass !!
[17:28:46] <Dark_Shikari> oh, and the fact that muxing raw h264 -> mkv is broken
[17:28:53] <elenril> broken? how?
[17:28:55] <jai> maybe i'm completely missing the bugreports. anyone have a roundup link?
[17:28:59] <Kovensky> Compn: can't embed fonts if you use external ass
[17:29:01] <Dark_Shikari> elenril: it doesn't _work_
[17:29:11] <Dark_Shikari> it just stops with a timestamp error
[17:29:19] <Kovensky> jai: aurel marked it as NOTABUG
[17:29:28] <jai> Kovensky: huh
[17:29:32] <Kovensky> jai: however, his demuxer is the *only* matroska demuxer that corrupts the ASS packets
[17:29:37] <jai> Kovensky: do you have a link btw?
[17:29:46] <Compn> Kovensky : why not? also i dont think ffmpeg supports muxing fonts either
[17:29:48] <Kovensky> hmm, no; it's what I remember from the fflames
[17:30:08] <Dark_Shikari> Compn: can't mux h264, can't mux fonts, bugged with ASS.... aka impossible to use =p
[17:30:14] <Kovensky> Compn: nobody uses libavformat for muxing
[17:30:19] <Kovensky> not matroska
[17:30:23] * elenril does
[17:30:30] <Kovensky> elenril is a nut
[17:30:35] <Compn> who has raw h264 anyhow ?
[17:30:40] <elenril> right, i forgot
[17:30:40] * Compn curious
[17:30:52] <Kovensky> Compn: x264 input -o output.264
[17:31:00] <Compn> and if you say mencoder -ovc x264 -of rawvideo ...
[17:31:38] <Kovensky> there's also a plan to move x264's mp4 muxer to libavformat but it doesn't support certain atoms
[17:31:42] <Kovensky> according to VFR Maniac
[17:31:43] <Dark_Shikari> Yeah, that too
[17:31:54] <Dark_Shikari> that is a good candidate for troll-driven development imo
[17:31:59] <Compn> heh
[17:32:00] <Dark_Shikari> bcoudurier LOVES being told his mp4 muxer sucks
[17:32:18] <Compn> isnt atom support fairly easy to add ?
[17:32:20] <Kovensky> lol
[17:32:23] <Compn> why mp4 has a million atoms anyways
[17:32:27] <Dark_Shikari> Compn: requires API support too
[17:32:27] <Compn> ugh
[17:32:29] <Kovensky> Compn: blame apple
[17:32:44] <jai> Kovensky: https://roundup.ffmpeg.org/issue588 ?
[17:34:07] <BBB> he still kept the GET_* macros
[17:34:11] * BBB bangs head against wall
[17:53:15] <peloverde> GET_* is gone now :)
[17:55:53] * _av500_ hums "you can't always GET_* what you want..."
[19:20:42] <BastyCDGS> hi
[19:20:46] <mru> lo
[19:20:51] <BastyCDGS> 32 or 64? :D
[19:20:59] <mru> 8
[19:22:11] <BastyCDGS> have you read my post almost 10 mins ago?
[19:22:17] <BastyCDGS> maybe this changes things a little bit...
[19:22:20] <peloverde> talk about spectral holes: http://i.imgur.com/Y2N1T.png :(
[19:24:11] <BastyCDGS> to review the problem, if codec_id == CODEC_ID_RAWVIDEO and read_packet has been called, when decode_init is called then?
[19:27:34] <BastyCDGS> or is never called and that's the reason why it calls read_palette of decoder by itself in the demuxer?
[19:28:42] <jai> Connecting to samples.mplayerhq.hu|213.144.138.186|:80... connected.
[19:28:43] <jai> HTTP request sent, awaiting response... 403 Forbidden
[19:28:47] <jai> ^^ :(
[19:29:06] <_av500_> u are not allowed :)
[19:29:16] <_av500_> you have too many samples already
[19:29:24] <BastyCDGS> hey jai, maybe you can help with the CODEC_ID_RAWVIDEO issue?
[19:29:25] <jai> need moar samples
[19:29:59] <jai> BastyCDGS: i can? :)
[19:30:08] <BastyCDGS> is it even correct to add the palette data to a RAWVIDEO codec id?
[19:30:10] <jai> what's the issue?
[19:31:00] <BastyCDGS> issue is that the decoder's read color palette is called within read_packet in demuxer only if it's CODEC_ID_RAWVIDEO
[19:33:25] <jai> and why is that a problem?
[19:33:32] <jai> also, which code is this?
[19:33:49] <BastyCDGS> see my latest post in ml I pasted it there
[19:34:07] <BastyCDGS> what RAWVIDEO means exactly? that the raw input data is just copied over?
[19:34:21] <BastyCDGS> plus extradata?
[19:36:25] <jai> the rawvideo codec id hooks up to raw pixel data
[19:36:49] <BastyCDGS> only the pixel data without colormap?
[19:37:06] <jai> yes
[19:37:14] <BastyCDGS> then the code is wrong anyway ;)
[19:37:33] <BastyCDGS> and I can remove the call in the demuxer to the colormap
[19:39:42] <BastyCDGS> the current decoder does the following when it's RAWVIDEO codec it, it either copies the plane data bit by bit or if byterun1 just decompresses and then copies plane data bit by bit
[19:39:57] <BastyCDGS> the demuxer appends the palette data to it
[19:40:07] <BastyCDGS> is that correct and intended behaviour?
[19:43:42] <BastyCDGS> BBB, good you're here
[19:43:44] <BBB> BastyCDGS: to get back to the discussion before I unplugged my cable to help someone else: don't rely on order of calling, it's bad habit :)
[19:44:38] <BastyCDGS> jai just said that adding the palette data for CODEC_ID_RAWVIDEO is not expected
[19:45:07] <BastyCDGS> that would mean I can complete remove the call to avcodec read_cmap_palette in demuxer ;)
[19:45:23] <BastyCDGS> jai said it should just be the raw pixel data
[19:45:37] <BBB> data[1] should be the palette IIRC
[19:46:17] <jai> yeah, data[1] should be the colormap if pixfmt == pal8
[19:46:21] <BastyCDGS> but looking at the current decoder implementation shows me that it just copies plane data or if byterun1 it just decompresses and copies that 1:1
[19:46:44] <jai> BastyCDGS: data[0] should be raw pixel data
[19:47:15] <BastyCDGS> after if'ing if it's RAWVIDEO, the current demuxer does:
[19:47:17] <BastyCDGS> if(av_new_packet(pkt, iff->body_size + AVPALETTE_SIZE) < 0) {
[19:47:17] <BastyCDGS>             return AVERROR(ENOMEM);
[19:47:17] <BastyCDGS>         }
[19:47:17] <BastyCDGS>  
[19:47:17] <BastyCDGS>         ret = ff_cmap_read_palette(st->codec, (uint32_t*)(pkt->data + iff->body_size));
[19:47:23] <BastyCDGS> that's wrong then, right?
[19:47:30] <BBB> looks weird
[19:47:32] <BBB> let me relook
[19:47:37] <BastyCDGS> ff_cmap_read_palette is in decoder
[19:48:37] <BastyCDGS> do I have to handle cmap for RAWVIDEO in demuxer at all?
[19:48:55] <BastyCDGS> i.e. is decode_init from decoder called somewhere when it's RAWVIDEO?
[19:49:17] <BastyCDGS> because if it's I just can remove demuxer cmap handling stuff and it's all fine ;)
[19:49:29] <BBB> that code looks weird
[19:49:33] <BBB> try to remove it and see what happens
[19:49:45] <BBB> although I have to admit I'm confused because it never sets the palette data anywhere else
[19:49:54] <BastyCDGS> I have to use ffmpeg -i infile.iff -f rawvideo to test, right?
[19:49:59] <BBB> no
[19:50:12] <BastyCDGS> how then?
[19:50:14] <BBB> you have to find an iff file that has the rawvideo codec instead of ilbm
[19:50:17] <BBB> iblm
[19:50:29] <BBB> it's like a divx avi versus a mjpeg avi
[19:50:37] <BBB> you can't play the mjpeg avi with -f divx
[19:50:43] <BBB> you have to find an actual divx avi
[19:51:31] <BastyCDGS> seems to be set if it's not ILBM but PBM file
[19:51:44] <BBB> yes
[19:51:50] <BastyCDGS> oh and I see, only if no compression is used
[19:51:50] <BBB> so find a pbm file
[19:52:19] <jai> KotH: does samples.mphq block certain ip ranges?
[19:52:27] <kierank> it does iirc
[19:52:55] <BastyCDGS> then try tor ;)
[19:52:57] <jai> meh :/
[19:53:06] * peloverde looks at at faac and lavc (faac inspired quantizer search) side by side and can't figure out what inspired this super buggy termination condition
[19:53:47] <jai> i'll try with a different ip
[19:55:15] <jai> no luck :(
[19:55:29] <peloverde> also whoever taught menno his tab/space style deserves a beating
[19:55:56] <mru> he has a defined style?
[19:56:08] <Kovensky> lol
[19:56:18] * Kovensky just uses whatever emacs gives him ._.
[19:56:25] <Kovensky> though I tweaked settings a lot
[19:56:30] <Kovensky> what settings do you use btw mru
[19:56:42] <mru> depends on what I'm working on
[19:56:59] <Kovensky> what's your init.el
[19:57:06] <BastyCDGS> don't find any IFF-PBMs :(
[19:57:34] <peloverde> his style appears to be tabs = 8 spaces, on alternating indentation levels use tabs for the bulk and spaces for change, and each indentation level is 1d6 spaces
[19:57:54] <Kovensky> 1d6? lol
[19:58:18] * Kovensky never played traditional rpgs :(
[19:58:39] <Kovensky> actually, I have played pen-and-paper ones, but never one of the traditional ones
[19:58:59] <Kovensky> they were made up on the spot by whoever was the game master lol
[19:59:38] <BastyCDGS> got one!
[20:02:31] <mru> Kovensky: http://pastie.org/949043
[20:02:40] <BastyCDGS> damn, this is a byterun1 PBM
[20:02:47] <BastyCDGS> so rawvideo stuff isn't called
[20:02:59] <BastyCDGS> it just uses RAWVIDEO for raw PBM
[20:05:13] <BastyCDGS> but doing a:
[20:05:13] <BastyCDGS> ./ffmpeg -i ../patches/ASH.LBM -f rawvideo /tmp/test.raw
[20:05:16] <BastyCDGS> does the trick
[20:05:45] <BastyCDGS> oh no just for output not for input :(
[20:06:17] <BastyCDGS> do you think it's safe to just remove that part and let handle raw IFF-PBM files like it would handle raw IFF-ILBM files?
[20:06:42] <BastyCDGS> in the demuxer
[20:06:55] <BastyCDGS> because for byterun1 IFF-PBM it doesn't do that ugly stuff too
[20:07:57] <BastyCDGS> well wait what file handles CODEC_ID_RAWVIDEO?
[20:08:14] <BastyCDGS> it's not handled by the IFF decoder at all I just see because the codec id isn't listened here
[20:09:20] <Kovensky> mru: short ._.
[20:09:37] * Kovensky has a lot of file-lock and cperl-mode specific configs
[20:09:51] <mru> Kovensky: that's just the C-related part
[20:10:01] <mru> the whole thing is 320 lines
[20:10:09] <mru> not including other .el files it pulls in
[20:10:14] <BBB> BastyCDGS: try it, and just see if output is the same
[20:10:16] <Kovensky> heh
[20:10:23] <Kovensky> I *think* I put my .emacs.d on github
[20:10:44] <BastyCDGS> I haven't a file with IFF-PBM raw data
[20:10:49] <Kovensky> hmm no, just the cperl-mode mods I did
[20:11:06] <BastyCDGS> I don't even find any usable information about IFF-PBM raw...but IFF-PBM byterun1 just works fine
[20:11:11] <BastyCDGS> and is handled by the IFF decoder
[20:11:30] <BastyCDGS> like IFF ILBM
[20:11:48] <BastyCDGS> so from pure logic it should the same for IFF PBM raw (handled like IFF ILBM raw)
[20:17:04] <BBB> well look, if we support it, there must be some file that uses it
[20:18:27] <BastyCDGS> well I just dropped that else if stuff
[20:18:33] <BastyCDGS> testing with all files seems to be ok
[20:19:29] <BastyCDGS> is it safe to remove avformat/iff.h
[20:19:29] <BastyCDGS> int ff_cmap_read_palette(AVCodecContext *avctx, uint32_t *pal);
[20:19:39] <CIA-7> ffmpeg: alexc * r23035 /trunk/libavcodec/aaccoder.c: Make the faac inspired quantizer search make sense for a slightly narrower definition of "make sense."
[20:19:39] <BastyCDGS> and make the only remaining ff_cmap_read_palette static?
[20:20:00] <BastyCDGS> or might ff_cmap_read_palette be called from outside?
[20:20:20] <BastyCDGS> i.e. an external application (thus part of public API)
[20:20:23] <BastyCDGS> in ffmpeg
[20:21:56] <BBB> no
[20:22:00] <BBB> it's ff_*()
[20:22:04] <BBB> public api is avi_*()
[20:22:06] <BBB> er...
[20:22:08] <BBB> av_*()
[20:22:20] <BBB> but ehm, make sure that the files you're testing with actually use this codepath
[20:22:23] <BBB> otherwise it's useless
[20:22:53] <BastyCDGS> well looking at IFF PBM byterun1 file I have (the only one) shows me it's the same as ILBM
[20:23:06] <BastyCDGS> there's a new chunk in it though, TINY (guess it's thumbnail)
[20:23:12] <BastyCDGS> otherwise it's exactly the same
[20:23:13] <mru> put in a deliberate error and make sure the output changes
[20:23:56] <BastyCDGS> you mean instead of setting codec id to RAWVIDEO dump a format not supported error?
[20:26:56] <BastyCDGS> mru
[20:26:59] <BastyCDGS> I got the difference!
[20:27:04] <BastyCDGS> between PBM and ILBM
[20:27:23] <BastyCDGS> it only differs that you don't do decodeplane in PBM
[20:27:35] <BastyCDGS> at least the IFF-PBM byterun1 decoder shows that
[20:28:02] <BastyCDGS> it does the same as the bpp <= 8 stuff from ILBM except a missing call to decodeplane8
[20:28:15] <BastyCDGS> so these two format probably just differ in chunky/planar bitmap data
[20:28:30] <BastyCDGS> very probably ;)
[20:36:36] <CIA-7> ffmpeg: alexc * r23036 /trunk/libavcodec/aacenc.c: Error out when too many bits per frame are requested.
[20:39:30] <BastyCDGS> If someone can confirm that COCEC_ID_RAWVIDEO is for chunky data the issue is solved ;)
[20:39:35] <CIA-7> ffmpeg: alexc * r23037 /trunk/libavcodec/aaccoder.c: 10l: store the result of clipping added in r23035
[20:40:21] <BastyCDGS> example for chunky data: 3a 3b 3f 37 1f 3c
[20:40:21] <BastyCDGS> would mean pixel 0 = color index 3a, pixel 1 = color index 3b etc.
[20:40:42] <BastyCDGS> if that's what CODEC_ID_RAWVIDEO decodes for PIX_FMT_PAL8 then I have solved the issue
[20:52:18] <BastyCDGS> patch submitted to ml
[20:52:27] <BastyCDGS> please review carefully
[21:03:35] <peloverde> Now this is what I call a spectral hole! http://i.imgur.com/WUlG5.png
[21:05:13] <mru> watch your step, you could trip over that
[21:05:37] * Dark_Shikari sees the troll
[21:05:43] <Dark_Shikari> in before a comment on how ffaac sucks
[21:08:03] <peloverde> and it only took 8.5 minutes to dig that hole
[21:10:03] <pJok> [insert comment here about fixing ffaacenc]
[21:10:05] <mru> peloverde: look what you let out
[21:10:20] * BastyCDGS added HAM6/8 support now to PBM files also
[21:10:28] <BastyCDGS> unfortunately no files to test with
[21:10:28] <Dark_Shikari> btw guys, I need a quick ABX from you all
[21:10:41] <mru> Dark_Shikari: sure, #2 looks best
[21:10:55] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/a.png
[21:10:57] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/b.png
[21:10:58] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/x.png
[21:11:00] <Dark_Shikari> x is source
[21:11:04] <mru> don't tell us that
[21:11:06] <Dark_Shikari> Which is better, A or B?
[21:11:10] <Dark_Shikari> mru: it's blindingly obvious
[21:12:07] <peloverde> A
[21:12:18] <mru> A
[21:12:24] <mru> no question there
[21:12:29] <mru> but both are pretty poor
[21:12:40] <Dark_Shikari> B seems to do better on the bottom
[21:12:46] <Dark_Shikari> it's less willing to destroy detail completely
[21:12:53] <Dark_Shikari> but A seems overall better
[21:12:56] <BastyCDGS> GREAT! IFF-ILBM/PBM now decodes _all_ files correctly I have (and that's quite a lot)
[21:13:05] <mru> A is blurrier
[21:13:07] <BastyCDGS> except those with masking (not supported yet)
[21:13:18] <Dark_Shikari> mru: now, guess which codecs the two are.
[21:13:30] <mru> B has lots of nasty edge artefacts
[21:13:36] <peloverde> The reflection on the bottom of the red thing is terrible in B
[21:14:03] <pJok> A looks  less blocky
[21:14:42] <Dark_Shikari> so yeah, now let's play the Guess The Codec game
[21:14:52] <ramiro> vorbis?
[21:14:53] <peloverde> x264 and dirac?
[21:15:01] * Kovensky didn't look at the pics but shoots xvid and theora
[21:15:08] <Kovensky> dirac wouldn't have blocks
[21:15:08] <Dark_Shikari> peloverde: vp7 and dirac
[21:15:15] <Kovensky> it does? lol
[21:15:22] * Kovensky didn't expect blocks on wavelets
[21:15:27] <Dark_Shikari> they're not quite blocks
[21:15:33] <peloverde> who cares about vp7?
[21:15:33] <pJok> ITS VP8!!!!1111111one
[21:15:36] <pJok> [/troll]
[21:15:41] <Kovensky> I just saw "blurry" and "blocky"
[21:15:48] <Dark_Shikari> peloverde: well then the conclusion is:
[21:15:53] <mru> A doesn't have much blocks
[21:15:54] <Dark_Shikari> x264 >>>>>>>>>>>>>>>>>>> vp7 >>> dirac >>>> theora
[21:16:05] <Dark_Shikari> x264: http://mirror05.x264.nl/Dark/x264_parkjoy.png
[21:16:06] <ramiro> isn't the codec name h.264?
[21:16:14] <Dark_Shikari> ramiro: we're testing encoders
[21:16:17] <Kovensky> ramiro: we're talking about the encoders
[21:16:35] <ramiro> I thought the names would then be diracenc or somesuch
[21:16:36] <Kovensky> since vp7, dirac and theora only have one implementation each, there's not much poin--
[21:16:40] <Dark_Shikari> ramiro: schro
[21:16:41] <Kovensky> which dirac implementation did you use Dark_Shikari
[21:16:43] <Dark_Shikari> dirac has two
[21:16:52] <Dark_Shikari> 1.0.9 schro with recommended settings by ds
[21:16:57] <Dark_Shikari> after fixing ffmpeg's wrapper to not be shit
[21:17:08] <ramiro> can't you use schro directly?
[21:17:33] <Dark_Shikari> there's no schrocli
[21:17:45] <ramiro> oh, I wasn't aware of that
[21:18:31] <ramiro> ot: is there anywhere we can get the list of gsoc'ers for each project? the official list only has the student/mentor names
[21:19:23] <Dark_Shikari> hmm, I need more codecs for this test
[21:19:27] <Dark_Shikari> hmm, let's try ffmpeg mpeg4!
[21:19:30] <Dark_Shikari> or xvid
[21:20:07] <mru> mpeg2
[21:20:10] <ramiro> make it 1d and pass it through vorbis!
[21:20:46] <Dark_Shikari> mru: unfortunately HCenc, the best mpeg-2 encoder I know of, won't take gop sizes over 18
[21:20:49] <Dark_Shikari> which is a bit unfair
[21:21:05] <Dark_Shikari> ok, the best one which I could get my hands on easily =p
[21:21:08] <Dark_Shikari> legally, at least
[21:21:15] <Dark_Shikari> I think the latest cce or whatever is pretty good too
[21:24:59] * BastyCDGS added another patch for PBM HAM decoding (forget it with my last one sorry folks)
[21:29:21] <Dark_Shikari> oh wow.  xvid is going to look hilarious
[21:31:29] <BastyCDGS> if someone wants to assist me in testing new PBM stuff...
[21:31:52] <BastyCDGS> write a ILBM to PBM converter
[21:32:02] <BBB> send an email to peter ross (he wrote that codec originally, no?)
[21:32:06] <BBB> ask him for the source file
[21:32:21] <BastyCDGS> I doubt he has an HAM PBM source file ;)
[21:32:56] <BastyCDGS> ILBM => PBM converter, just copy every chunk in file except BODY
[21:33:20] <BastyCDGS> for BODY: decodeplane8 it and write result instead of planar stuff (one byte, no word-padding per line)
[21:34:52] <BastyCDGS> maybe somebody already has a nice tool which can convert IFF ILBM to IFF PBM ;)
[21:35:03] <BastyCDGS> but do not mix IFF PBM with plain PBM ascii files
[21:35:07] <BastyCDGS> they're totally different
[21:38:15] <Dark_Shikari> mru / peloverde http://mirror05.x264.nl/Dark/compare/xvid.png
[21:39:04] <BBB> BastyCDGS: no, but I mean  for rawvideo
[21:39:11] <BBB> BastyCDGS: there must be some case where tawvideo is used
[21:39:21] <BBB> so iff.c in avformat is used, but not iff.c in avcodec
[21:39:27] <BBB> I want to see that file work
[21:39:39] <BastyCDGS> regarding this I just sent the mail ;)
[21:40:02] <BBB> ok
[21:40:25] <BastyCDGS> I'll do a grep maybe I find the decoder
[21:41:51] <BBB> rawdec.c
[21:41:56] <BBB> it means "no codec"
[21:42:13] <BBB> e.g. the data is literally paletted video
[21:42:16] <BBB> or RGB24
[21:42:18] <BBB> or so
[21:43:03] <BastyCDGS> i.e. chunky 8-bit data with PAL8?
[21:44:51] <Dark_Shikari> I need a comedy option for this codec comparison
[21:44:54] <Dark_Shikari> svq1?
[21:45:30] <BastyCDGS> sebastian vater quirk1? :D
[21:46:18] <BBB> Dark_Shikari: snow1!1112
[21:46:22] <Dark_Shikari> that isn't comedy though
[21:46:25] <Dark_Shikari> "comedy" must be much worse than theora
[21:46:32] <elenril> bink?
[21:46:32] <BBB> snow!!112
[21:46:34] <Dark_Shikari> in before "theora is the joke"
[21:46:52] <BBB> you're telling me snow is better than theora?
[21:46:57] <Dark_Shikari> elenril: that would work
[21:46:59] <Dark_Shikari> lemme try bink
[21:47:05] <BBB> otherwise
[21:47:06] <BBB> wmv1
[21:47:10] <BBB> that sucks quite a lot
[21:47:18] <Dark_Shikari> better than mpeg4 isn't it?
[21:47:28] <BBB> you're confused with wmv3
[21:47:48] <Dark_Shikari> msmpeg4 was based on mpeg4
[21:47:55] <Dark_Shikari> and that went through like 3 iterations of new features
[21:47:56] <Dark_Shikari> then wmv1
[21:47:57] <Dark_Shikari> then wmv2
[21:48:00] <Dark_Shikari> then finally wmv3 was a rewrite
[21:48:08] <janneg> rv10
[21:48:16] <Dark_Shikari> those are all mpeg4-generation
[21:48:21] <BastyCDGS> wmv1 + rot13?
[21:48:24] <Dark_Shikari> none will be significantly different from mpeg4
[21:49:11] <BBB> hm....
[21:49:22] <BBB> how about... h261?
[21:49:26] <BBB> do we have a h261enc?
[21:49:46] <Dark_Shikari> h261 is resolution-restricted iirc
[21:50:05] <BBB> it sucks ass
[21:50:13] <BBB> I thought that was the predecessor of all mpeg codecs
[21:50:35] <Dark_Shikari> yes
[21:50:39] <Dark_Shikari> but it's still transform-based
[21:50:44] <Dark_Shikari> imo the comedy option should be not primarily transform-based
[21:50:53] <mru> svq1 then
[21:50:59] <Dark_Shikari> Yeah, svq1 is encoding now
[21:51:01] <Dark_Shikari> it's hysterically slow
[21:51:06] <Dark_Shikari> yay for vector quant
[21:51:12] <Dark_Shikari> oh, yeah, and bink too
[21:51:25] <Dark_Shikari> svq1 is going to be fun, I'll need newton's method to get the right bitrate
[21:51:42] <mru> some indeo version
[21:51:46] <BBB> mjpeg
[21:51:49] <Dark_Shikari> I don't think that will even hit the target bitrate
[21:51:50] <Dark_Shikari> For either of those
[21:51:57] <Dark_Shikari> 14mbps at 1080p50
[21:52:10] <BBB> mjpeg should give pretty crappy results
[21:52:13] <BBB> it's I-frame only
[21:52:15] <Dark_Shikari> I know
[21:52:19] <Dark_Shikari> that's beyond comedy and just stupid =p
[21:52:25] <mru> that's not enough for mpeg2 either
[21:52:27] <BBB> you asked for it
[21:52:30] <Dark_Shikari> mru: mpeg2 will work
[21:52:30] <BBB> apng? :-p
[21:52:44] <Dark_Shikari> BBB: no ability to adjust bitrate
[21:52:45] <mru> mpeg2 would need about twice as many bits to look good
[21:52:49] <Dark_Shikari> mru: more
[21:52:51] <Dark_Shikari> source is hard
[21:52:58] <Dark_Shikari> 4 times, minimum
[21:53:06] <mru> yeah probably, for that source
[21:53:21] <Dark_Shikari> I was shocked how good x264 came out
[21:54:00] <BBB> you can stop pampering yourself now :-p
[21:54:06] <Dark_Shikari> lol
[21:54:09] <BBB> is it lgpl yet and integrated in the ffmpeg trunk?
[21:54:12] * BBB runs
[21:54:20] <Dark_Shikari> is it proprietary yet and being sold to microsoft?
[21:54:21] * Dark_Shikari runs
[21:54:47] <Dark_Shikari> also, apparently I made bink go nuts by feeding it an avisynth source file
[21:54:52] <Dark_Shikari> file size: Projecting: 17,534,507 bytes (0.0 to 1)
[21:54:57] <Dark_Shikari> 0.0 to 1 compression, hell yes
[22:02:25] <BastyCDGS> well I know a compression method which compresses infinity non-repeatable bytes to just one
[22:02:36] <BastyCDGS> "compression method"
[22:03:10] <BastyCDGS> unpack(PI) => 3.14159265...
[22:03:19] <BastyCDGS> one symbol (1 byte) unpacks to infinity unique bytes :D
[22:03:46] <BastyCDGS> unpack(e) => 2.7182818...
[22:03:48] <BastyCDGS> works too ;)
[22:03:51] <BastyCDGS> so it's flexible ;)
[22:04:22] <BastyCDGS> the other way is compressing infinite unique bytes to just one (huffman's dream)
[22:24:54] <Tjoppen> speaking of comedy options and such, maybe I should get around to implementing a cinepak encoder? I have one sketched down on paper
[22:25:07] <Dark_Shikari> lol
[22:25:59] <Tjoppen> I even though about using SSIM for it - even the VQ step. that'd be interesting
[22:27:30] <Tjoppen> but then again.. that's almost being serious :o
[22:27:43] <Dark_Shikari> comedy option is almost done
[22:27:45] <Dark_Shikari> you will lol
[22:27:53] * Dark_Shikari waits for pngout to do its magic
[22:30:46] * BastyCDGS 's bed is waiting for me going to sleep
[22:30:53] <BastyCDGS> so I will you all a good night and nice dreams
[22:31:22] <Dark_Shikari> hey, bink makes like a 3x smaller png
[22:31:56] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/bink.png
[22:32:09] <Dark_Shikari> Now that's fucking funny
[22:32:34] <mru> that's comedy
[22:32:56] <Tjoppen> hah. nasty :)
[22:32:56] <BastyCDGS> yes never seen such a sharp image ;)
[22:33:40] <elenril> lol
[22:33:46] <Tjoppen> bedtime here as well
[22:35:16] <BBB> uh
[22:35:17] <BBB> wtf
[22:35:21] <BBB> :)
[22:35:28] <BBB> I suppose you're telling us the encoder is broken? :)
[22:36:27] <Dark_Shikari> no, the encoder works quite fine
[22:39:16] <CIA-7> ffmpeg: darkshikari * r23038 /trunk/ (4 files in 2 dirs):
[22:39:16] <CIA-7> ffmpeg: Add intra refresh and crf-max support to the libavcodec libx264 wrapper.
[22:39:16] <CIA-7> ffmpeg: Minor version bump.
[22:42:36] <BBB> Dark_Shikari: it looks like shit
[22:42:38] <BBB> all blocks are even
[22:42:45] <BBB> with a few exceptions
[22:42:54] <Dark_Shikari> the way it compresses the trees is rather interesting
[22:43:04] <BBB> shitty
[22:44:59] <astrange> 13:28 <@Dark_Shikari> oh, and the fact that muxing raw h264 -> mkv is broken <- it doesn't work for mp4 either, it just doesn't error (silently generating an invalid file is actually worse)
[22:45:14] <Dark_Shikari> oh dear :/
[22:45:16] <Dark_Shikari> when was this broken?
[22:45:31] <astrange> it never worked, the h264 parser doesn't set dts
[22:45:38] <astrange> on at least some kinds of files
[22:46:09] <kierank> it's been broken for ages
[22:46:27] <astrange> i also want the mpeg4 parser to turn divxvid into real mpeg4
[22:46:41] <Dark_Shikari> why don't we have some intermediate filter that adds dts ?
[22:46:46] <mru> astrange: difference?
[22:46:49] <Dark_Shikari> so we don't have to write dts-generation code to every single parser?
[22:46:59] <Dark_Shikari> mru: elimination of packed b-frames
[22:47:00] <astrange> xvid has no global header, no dts, packed b-frames
[22:47:22] <mru> "xvid has no dts" makes no sense
[22:48:01] <astrange> the encoder doesn't emit dts, it just assumes a 1 frame delay and reordering in the decoder
[22:48:06] <mru> and mpeg4 can store the vol header either out of band or repeated in-band (with I-frames)
[22:48:24] <astrange> so it doesn't support mp4 without a parser
[22:48:49] <astrange> now that i think about it, i haven't tried libx264 -> .mp4, but i'm pretty sure it doesn't work
[22:50:00] <peloverde> WHAT! "Canonical has tried to clarify how — if not why — it has licensed a *closed-source* and patented codec for video on PCs running its Linux."
[22:50:05] <mru> lately _everything_ I've tried has resulted in that dreaded non-monotone timestamp error or duplicated frames
[22:50:18] <mru> peloverde: reading the register?
[22:50:32] <peloverde> slashdot
[22:50:46] <mru> I read that exact sentence in the register
[22:51:06] <mru> and they've been smoking some serious crack lately
[22:52:08] <astrange> i know ("know") a slashdot editor, nobody in the register though
[22:52:16] <Dark_Shikari> wow, I guessed the qscale almost exactly on my svq1 encode
[22:52:28] <peloverde> Being the original asker I feel a bit like this: http://www.smbc-comics.com/index.php?db=comics&id=1851#comic
[22:52:41] <mru> peloverde: ah, /. is quoting the register
[22:53:03] <Dark_Shikari> oh god svq1 is hilarious
[22:57:06] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/svq1.png
[22:57:16] <Dark_Shikari> bink actually beats it
[22:57:37] <BBB> the trees look better though
[22:57:47] <Dark_Shikari> eh, I prefer the bink trees
[23:00:54] <Dark_Shikari> so, what else should I test
[23:01:49] <BBB> snow :)
[23:02:35] <Dark_Shikari> going ffmpeg mpeg-2 now
[23:03:56] <janneg> s/mpeg-2 /s/
[23:07:06] <drv> the bink trees look like bizarro-world color by numbe
[23:07:06] <drv> r
[23:09:08] <Dark_Shikari> bink does at least seem very good at getting edges right
[23:21:02] <kierank> test quicktime's svq
[23:22:00] <Dark_Shikari> last I heard it was a disaster
[23:22:04] <Dark_Shikari> at low bitrates, that is
[23:22:06] <Dark_Shikari> the ratecontrol completely breaks