[FFmpeg-devel-irc] IRC log for 2010-09-14

[irc at mansr.com]

[00:10:35] <bcoudurier> does anybody have the latest SMPTE specs ?
[00:18:49] <CIA-63> ffmpeg: michael * r25117 /trunk/libavutil/log.c:
[00:18:49] <CIA-63> ffmpeg: Limit av_log repeat detection to terminals so as to avoid filling files with
[00:18:49] <CIA-63> ffmpeg: lots of mess.
[01:12:37] <Compn> bcoudurier : maybe the ffmpeg foundation could get in some better contacts with smpte ? :P
[05:25:24] <Tjoppen> god morgon
[05:25:45] <_av500_> gm
[05:28:34] <kshishkov> god morgon
[05:29:37] <kshishkov> (men en svenska morgon är bättre)
[05:47:02] <pJok> god morgon kshishkov
[05:48:23] <kshishkov> god morgon
[05:48:35] <Tjoppen> autumn weather
[06:40:05] <Tjoppen> hrm.. still rather mixed support for growing files in lavf
[06:40:29] <astrange> yes that doesn't get tested well
[06:40:40] <Tjoppen> I managed to make the avi demuxer quite confused yesterday
[06:41:25] <Tjoppen> my code crashed, but I managed to fix it. however a lot of demuxers assume !is_streamed() means they can seek wherever
[06:41:36] <Tjoppen> especially SEEK_END
[06:43:01] <Tjoppen> it's sort of like how on a pipe you can still seek back a little bit (since lavf buffers a few k), but in this case you can always seek back to any point before where you are. and url_fsize() is unreliable
[06:43:40] <Tjoppen> too bad only BSD handles growing files correctly (IMO) :\
[06:49:47] <astrange> darwin seems to work for me. it might be a BSD though
[06:49:56] <astrange> what does linux do if it doesn't count as correct?
[06:50:51] * funman happily watches growing .avi on linux with mplayer and vlc
[06:51:25] <funman> i'm not sure if mplayer use lavf though
[06:51:37] <mru> morning
[06:51:57] <astrange> mplayer uses native for avi
[06:52:02] <mru> I'd also like to know what Tjoppen considers correct
[06:52:07] <mru> and how linux differs from that
[06:53:26] <Tjoppen> well, posix has reading files that are written as undefined behaviour
[06:54:02] <mru> surele it's more specific than that
[06:54:22] <Tjoppen> linux gives you eof at where the file ended when it was open, while bsd blocks until the file is closed on more data is written to it
[06:54:29] <Tjoppen> *opened
[06:54:43] <mru> I don't believe that
[06:55:17] <mru> I've played films as they download many times
[06:55:58] <Tjoppen> then the players are probably being smart
[06:56:20] <mru> I wrote the code
[06:56:23] <Tjoppen> try curl http://foo > bar & ffplay - < bar
[06:56:30] <mru> maybe ffplay is stupid
[06:56:43] <astrange> i think ffplay is too simple to be stupid, not sure though
[06:56:46] <Tjoppen> ah, right. but cat bar > asdf
[06:57:04] <Tjoppen> ffplay will play from stdin just fine (depending on container of course)
[06:57:12] <mru> cat will sto when it catches up with the writer
[06:57:18] <mru> stop
[06:57:36] <mru> blocking is imo weird
[06:57:57] <mru> the file ends there, and there is no reason to believe it will ever grow
[06:58:29] <Tjoppen> but it's opened for writing by another process. if it were closed, sure
[06:58:50] <mru> open for writing doesn't mean it will grow
[06:58:58] <mru> the other process might be rewriting parts of it
[06:59:01] <Tjoppen> it means it can. if it won't, you should close it
[06:59:03] <mru> or just sitting there
[06:59:28] <funman> or truncate?
[06:59:29] <mru> treating the current end as the end is the only sane thing to do
[06:59:33] <mru> funman: or that
[07:00:17] <astrange> perian caches the eof position and rechecks it when there's a request to read past it
[07:02:07] <mru> having different behaviour depending on some other process merely having the file open is totally bizarre
[07:02:25] <mru> and I somehow doubt even bsd is that sick
[07:03:03] <Tjoppen> IIRC you can append a file to itself, causing it to grow infinately
[07:03:18] <mru> huh?
[07:03:24] <mru> cat foo >>foo ?
[07:03:28] <Tjoppen> yes
[07:03:34] <funman> cat: a: input file is output file
[07:03:40] <mru> that would work in linux
[07:03:47] <mru> unless cat itself objects
[07:03:57] <Tjoppen> you could probably fool it with a fifo
[07:04:14] <funman> >> a < a works
[07:05:09] <Tjoppen> anyway, reading open files is fairly odd as is. as long as there were some way to specify which behaviour you want I'd be happy
[07:05:38] <mru> why should it be any different?
[07:06:45] <Tjoppen> hm
[07:07:37] <mru> does that mean that on bsd one can wreak havoc by opening a few files and sitting on the file descriptors?
[07:07:52] <mru> thus blocking every process that tries to read to the end?
[07:08:14] <mru> sure, you need write permission but still
[07:08:54] <Tjoppen> presumably. but maybe you need to ioctl() a bit
[07:09:04] <mru> to do what?
[07:09:23] <funman> you don't mean fcntl()?
[07:09:40] <Tjoppen> right
[07:10:41] <Tjoppen> what could work good enough is mkfifo and tee
[07:11:47] <Tjoppen> say you want to download something and transcode it at the same time. mkfifo tempfifo && curl url | tee filename > tempfifo & ffmpeg -i tempfifo etc.
[07:13:40] <Tjoppen> or even without the fifo, just | ffmpeg -i -
[07:13:48] <mru> yes, there are cases where you might want the blocking behaviour
[07:13:52] <mru> but those are special
[07:14:00] <mru> and should be requested by the _reader_
[07:15:39] <superdump> http://felipec.wordpress.com/2010/09/14/gst-av-0-3-better-performance-for-vorbis-and-mp3/
[07:15:48] <superdump> it seems flac needs some more optimisation for arm
[07:15:58] <superdump> (i'm guessing these battery life tests were done on an n900
[07:16:00] <superdump> )
[07:16:10] <superdump> not that people like felipec
[07:16:25] <mru> gst isn't design to be power-efficient
[07:16:26] <funman> superdump: rockbox has some arm7 asm for flac
[07:16:27] <superdump> and not that that matters
[07:16:38] <funman> it's slower than C on arm9 though
[07:16:40] <mru> flac decoding is so fast it doesn't need optimisations
[07:16:55] <superdump> mru: at least look at the article
[07:16:59] <mru> I'm looking
[07:17:03] <mru> but it's felipec...
[07:17:20] <superdump> don't we want to be better than everything? :)
[07:17:31] <kshishkov> mru: you're wrong. Flac would benefit from reading optimisations but those are not decoder thing
[07:17:36] <funman> doesn't gst-ffmpeg already exist ? oO
[07:17:53] <superdump> funman: keep reading
[07:17:53] <mru> funman: NIF: not invented by felipe
[07:18:22] <mru> flac is fast enough to be easily decoded realtime at the lowest cpu speed
[07:18:30] <funman> superdump: ah, small screen here ;)
[07:18:50] <superdump> mru: well, still, battery life on mobile devices is interesting
[07:19:08] <mru> yes, but there's nothing for us to do
[07:19:18] <kshishkov> funman: don't use your MP3 player for Internet browsing then
[07:19:23] <mru> going from 10% at lowest speed to 9% isn't going to make a big difference
[07:19:41] <mru> gst is doing something else that eats power
[07:20:03] <funman> kshishkov: only for gaming: http://www.youtube.com/watch?v=1rVV_0xKmhw
[07:20:36] <superdump> mru: the graph is ffmpeg versus libflac
[07:20:39] <astrange> does gst-ffmpeg work with aac yet, or are they still intentionally ignoring their bitstream destruction to claim ffmpeg doesn't work?
[07:20:46] <superdump> both through gst
[07:20:46] <kshishkov> funman: yes, Tetris and Doom are classic
[07:20:49] <mru> superdump: so it's doing something stupid in the ffmpeg wrapper
[07:21:27] <mru> but I'll see if there's by chance anything I can do to speed it up
[07:21:30] <kshishkov> "gstreamer", "doing something stupid in the wrapper" - tautology
[07:22:05] <mru> I could probably speed up vorbis by 30% or so too
[07:22:07] <mru> on the A8
[07:22:18] <mru> like I did with aac
[07:23:00] <kshishkov> one guy said that Vorbis wasn't designed with portable players in mind
[07:23:38] <av500> lol
[07:24:08] <mru> that is true
[07:24:36] <mru> they wouldn't have allowed unbounded table sizes if it were
[07:24:59] <av500> mru: tell me about it
[07:25:11] <av500> we hada student that wanted to put vorbis on a c54x
[07:25:27] <funman> there's a tremor branch without malloc iirc
[07:25:34] <av500> in the end he did 70% on the arm and only the transform on the dsp
[07:25:43] <av500> funman: does not help
[07:25:45] <mru> funman: how does that manage to work? refuse to play certain files?
[07:25:59] <av500> funman: you can end up wtih 1MB of tables
[07:26:26] <funman> mru: no idea i never looked at it
[07:26:53] <av500> funman: as said, we tried
[07:27:08] <av500> but the poor c54x dsp with 64k ram cried a lot
[07:27:20] <av500> then rolled over and died
[07:28:05] <av500> kshishkov: of course vorbis was not desinged for portable, it was meant for streaming and at that time mp3 players had no wifi...
[07:28:29] <kshishkov> av500: at least it used existing container
[07:29:17] <av500> yes, a shiny one: http://www.feuerverzinken.com/uploads/pics/2.6-3.jpg
[07:29:22] <funman> http://ompldr.org/vNWpjMg/beat.flac < how could i find the frequency of the beat ? i don't see a pattern in audacity
[07:31:17] <kshishkov> funman: use logarithmic spectrum
[07:32:46] <mru> fft of the envelope
[07:33:26] <funman> it's between 5 & 10Hz, too small for seeing it on the spectrum?
[07:36:39] <Tjoppen> iirc autocorrelation is the standard solution
[07:40:17] <mru> funman: use a longer fft
[07:40:45] <mru> Tjoppen: how does autocorrelation tell you the beat frequency?
[07:41:11] <mru> hmm, I guess you'd get secondary peaks at the beat frequency
[07:41:20] <kshishkov> simple correlation with sine wave can do that though
[07:41:48] <kshishkov> but if you perform it for all discrete frequencies you get FFT
[07:42:04] <Tjoppen> mru: yes
[07:42:31] <funman> http://i.imgur.com/GoqnI.png
[07:43:04] <Tjoppen> you might want to perform DFT with non-integer frequencies as well
[07:43:15] <Tjoppen> if you go that route
[07:43:29] <andoma> Tjoppen: what other routes are there?
[07:43:44] <kshishkov> andoma: torturing file creator
[07:43:50] <Tjoppen> :)
[07:44:04] <kshishkov> until he says what was beat frequency
[07:44:20] <funman> i'm the creator :/
[07:44:29] * mru tortures funman
[07:45:19] <funman> it's a recording of a mp3 'playing back' something with headphones muted
[07:46:10] <mru> brad0: you're on bsd right?
[07:46:26] <brad0> yes.
[07:46:51] <mru> we were discussing what happens if a process reads to the (current) end of a file being written by another process
[07:47:17] <mru> someone said bsd was different from linux
[07:54:28] <funman> seems to be quite close to 4Hz
[07:54:56] <av500> infrasound
[07:55:11] <funman> 4 beats per second
[07:55:20] * mru needs a bigger sub for that
[07:55:50] <mru> and the downstairs neighbour doesn't like my current one...
[07:56:14] <mru> Tjoppen: I can't find anything in posix or bsd docs to support your claim
[07:56:16] * kshishkov tries to remember number of xkcd with elliptical dish
[07:56:26] <mru> 54
[07:58:13] <Tjoppen> hm. maybe so. it was a friend of mine why uses bsd that showed me a while back
[07:58:18] <Tjoppen> *who
[08:01:17] <kshishkov> mru: I meant 316
[08:01:46] <cartman> av500: German Consulate in Istanbul is a joy to work with, not
[08:02:09] <cartman> they want shitloads of paperwork and it should be in _order_ they tell you
[08:02:11] <cartman> wow
[08:02:13] <kshishkov> cartman: Ukrainian Embassy in Kiev is wonderful too
[08:02:35] <cartman> next time I am only attending conferences in USA
[08:02:43] <cartman> it was easier to get 10 year visa from USA
[08:02:47] <kshishkov> try UK for a change ;)
[08:02:53] <cartman> yeah more paperwork :P
[08:03:07] <kshishkov> in .ua they also require fingerprints
[08:03:18] <cartman> for US, yes
[08:03:45] <cartman> at least they don't need my urine sample
[08:03:46] <funman> cut hands, enjoy less paperworks
[08:03:53] <cartman> Germans might want that
[08:04:00] <funman> cut ... no i'm fine with urine sample
[08:04:08] <cartman> lol
[08:04:11] <cartman> see ;)
[08:05:15] <kshishkov> cartman: from my experience they required you to glue your photo to visa application in .de embassy while in .se embassy they did almost everything themselves, without much security hassle too
[08:05:30] <cartman> kshishkov: really .nl was easier :-/
[08:05:45] <av500> cartman: i know, german consulates are bad
[08:05:58] <av500> but, why dont you hire a stand-in to go for you? :)
[08:05:59] <cartman> av500: the bad thing is I coming .de to spend money!
[08:06:16] <kshishkov> av500: from my statistics - .se 100% success, .de 50% success
[08:06:21] <cartman> my wife will buy half of nici.de :P
[08:06:24] <av500> cartman: well, i guess their filter for that is not good enough
[08:06:49] <cartman> av500: really too many Turks around there?
[08:06:52] <pJok> kshishkov, swedes are a bit more pragmatic
[08:06:54] <kshishkov> av500: thet should count for re-exporting German own money ;)
[08:07:13] <kshishkov> pJok: yes, I noticed that.
[08:07:19] <av500> cartman: ask me about getting my family members from belgrade to visit here, same thing
[08:07:35] <kshishkov> av500: at least now it should be easier
[08:07:35] <cartman> av500: so its not about Turks ok cool :P
[08:07:49] <av500> cartman: :)
[08:08:01] <kshishkov> cartman: and yes, there are too many Turks around here
[08:08:09] <cartman> kshishkov: in .se or .de?
[08:08:12] <pJok> kshishkov, i like that about sweden... more pragmatic and less hassle wiht most things... and they are sensible too
[08:08:18] <av500> cartman: you might be luckier if you just checked [ ] Berlin, turkish sector.....
[08:08:22] <kshishkov> cartman: in .de for now
[08:08:30] <cartman> kshishkov: uneducated crowd?
[08:08:39] <kshishkov> cartman: and in my native city there were too many Vietnamese
[08:09:13] <kshishkov> av500: I smell tautology there as well
[08:09:26] <av500> I smell kebab
[08:09:29] <cartman> hopefully Munich is better
[08:09:35] <funman> av500: time to shower?
[08:09:39] <kshishkov> cartman: quite likely. I seem to live in Turkish part of town as well now
[08:09:41] <cartman> I need somewhere I can buy nici.de stuff
[08:09:58] <cartman> kshishkov: try to keep away from Turkish girls, and it'll be all ok :P
[08:10:11] <kshishkov> cartman: and yes, Muenchen is definitely better. Almost everything is better than Berlin though
[08:10:43] <kshishkov> cartman: why?
[08:10:49] <cartman> kshishkov: uhm
[08:10:53] <cartman> hard to tell in English :P
[08:11:06] <funman> because Turkish brothers are strong and protective?
[08:11:14] <cartman> over-protective freaks maybe
[08:11:39] <cartman> lets say like this; this happened a few days ago; happens all the time in east-Turkey:
[08:11:42] <kshishkov> well, I understand that
[08:11:45] <cartman> someone rapes a teenage girl
[08:11:52] <cartman> the family kills the girl
[08:11:58] <cartman> because she is unclean now etc.
[08:12:00] <cartman> you get the idea
[08:12:25] <cartman> and most of the Turkish people in Europe comes from these rural areas
[08:12:43] <kshishkov> yuck!
[08:12:49] <cartman> sad but true
[08:13:17] <kshishkov> well, "Jewish" Russian emigrants are not much better though
[08:13:54] <cartman> they kill their small kids too?
[08:15:39] <cartman> this is part of the reason when you say Turk, av500 will say kebab
[08:15:41] <cartman> ;)
[08:16:30] * cartman points av500 too http://döner.de
[08:17:25] <kshishkov> cartman: well, it's mostly shawarma in .ua and it's believed to be mostly from dogs or cats meat with occasional health safety inspector
[08:17:37] <cartman> lol
[08:19:16] <kshishkov> you can also ask thresh
[08:57:26] <mru> http://pastebin.com/kqD56TmU
[08:57:34] <mru> ^^ allegedly hdcp master key
[09:00:20] <twnqx> av500: http://pastebin.com/kqD56TmU
[09:00:22] <twnqx> oh lol
[09:00:27] <twnqx> i should have read that first :P
[09:00:38] <KotH> news travels fast in ffmpeg-land ;)
[09:00:56] <cartman> does I tattoo it or what?
[09:01:33] <twnqx> well, all that needs to be said about it is on wikipedia :P
[09:01:35] <twnqx> To break the Blom's scheme of HDCP, one needs a minimum of 39 device keys in order to reconstruct the secret symmetrical master matrix that has been used to compute all device keys.
[09:01:44] <cartman> KotH: Åžeriat is coming along fine
[09:06:18] <KotH> cartman: yeah.. i heard about it
[09:06:40] <KotH> cartman: when the fuck will you get up over there, and kick those assholes out?
[09:06:49] <KotH> cartman: or do i have to come over and lead you?
[09:06:56] <cartman> KotH: like never you mean?
[09:06:58] <cartman> :D
[09:07:35] <cartman> Everybody lives in what they deserve, people have spoken now they'll live what they deserve
[09:07:59] <cartman> mv #ffmpeg-devel #middleeast-devel
[09:08:00] <cartman> ;)
[09:08:22] <thresh> this is also true for .ru and .ua at least, you know
[09:08:39] <cartman> yup
[09:08:47] <cartman> there is a big picture
[09:09:53] <cartman> KotH: you'll appreciate http://goo.gl/yRBL
[09:11:43] <KotH> cartman: ^^'
[09:19:12] <thresh> hmm, I wonder why current ffmpeg trunk thinks i'm on x86, while i'm definitely on x86_64
[09:23:18] <thresh> hmm, that's not the error as subarch is defined to X86_64
[09:23:50] <KotH> siretart: is it possible to tell the guy who administrates wiki.debian.org that his system is down?
[09:26:41] <av500> twnqx: ok, and?
[09:31:35] <cartman> http://www.securityfocus.com/news/236 this is from 2001
[09:31:36] <cartman> whoa
[09:39:01] <thresh> wonder if noone got bored enough to crack those?
[09:40:34] <av500> well it seems someone did
[09:44:44] <kshishkov> av500: security theatre
[09:56:32] <twnqx> av500: didn't we have a discussion on that subject liek a month ago? :)
[09:57:10] <siretart> KotH: AFAIUI wiki.debian.org is maintained by DSA, who is surely notified by their nagios monitoring software
[09:57:10] <av500> ah yes
[09:57:28] <av500> twnqx: so, you are going to make a de-dhcp box now?
[09:57:48] <twnqx> boring and too easy, no? :P
[09:58:04] <cartman> de-dhcp new internet protocol
[09:58:45] <twnqx> on the other hand i could test it.. if my BD player outputs to my old non-dhcp enabled displays...
[09:58:55] <av500> hdcp
[09:59:00] <cartman> :D
[09:59:02] <twnqx> :D hdcp :P
[10:00:31] <KotH> siretart: oh..ok
[10:00:40] <KotH> siretart: so it's just a mater of time until the right person wakes up :)
[10:01:36] <kshishkov> av500: yes, displays should have static IPs assigned
[10:08:31] <KotH> kshishkov: say again?
[10:10:47] <cartman> kshishkov: lol
[10:11:57] <kshishkov> KotH: "if my BD player outputs to my old non-dhcp enabled displays..." - static IP displays should not have problems with DHCP
[10:12:33] <mru> I want to kill michael
[10:13:02] <KotH> kshishkov: sauce?
[10:13:36] <KotH> mru: did he rape your teenage daughter nobody knows about?
[10:14:12] <kshishkov> KotH: IRC line with HDCP typo from 15 minutes ago misinterpreted by me
[10:14:28] <kshishkov> KotH: so that's how you call FFmpeg these days?
[10:14:53] <mru> KotH: he's being unreasonable
[10:15:04] <Compn> wasnt there already hardware to strip out the hdcp encryption? no, i guess i'm imagining again...
[10:15:09] <mru> last message repated 1 times
[10:15:11] <mru> last message repated 2 times
[10:15:13] <mru> last message repated 3 times
[10:15:15] <mru> last message repated 4 times
[10:15:36] <mru> that's not my idea of repeat suppression
[10:15:40] <funman> he's being unreasonable 5 times?
[10:15:48] <av500> Compn: if it was, it was not legal
[10:15:59] <mru> av500: nothing illegal about it
[10:16:10] <mru> possibly in breach of some hdcp licence agreement
[10:16:18] <Compn> av500 : just depends what country you are in of course
[10:16:26] <mru> between the manufacturer and the hdcp consortium
[10:16:32] <av500> mru: yes
[10:16:39] <av500> and dcma in selected places
[10:16:41] <mru> a user of such a device would not be violating any laws
[10:16:53] <mru> not automatically
[10:16:58] <mru> if used to pirate films, then yes
[10:17:03] <Compn> unless a country had an anti-circumventing law ...
[10:17:13] <funman> ah damn, 'not automatically'
[10:17:14] <Compn> and no fair use
[10:17:27] <funman> else i would acquire such a device and break into banks / kill random people
[10:27:25] <Compn> i see a few 'hdcp stripper' boxes around
[10:29:03] <vipw> then you must go to pretty kinky nightclubs
[10:29:20] <thresh> lol @ http://www.adobe.com/support/security/advisories/apsa10-03.html
[10:29:26] <KotH> funman: depends on your anti-circumventing law
[10:30:21] <KotH> funman: in .ch you are not allowed to break any copy protection systems. but the definition of copyprotection systems is so narrow, that any DRM style system (and that includes AACS and CSS) do not fall into that category
[10:30:23] <funman> thresh: 'you're gonna get pwned for 2 weeks' ?
[10:30:43] <cartman> seems so
[11:03:26] <pJok> i have an idea for a very effective copy protection scheme... don't make it if you dont want it to be copied...
[11:03:48] <Dark_Shikari> but then they can infiltrate your dreams and copy it out of your brain
[11:04:05] <av500> then somebody else makes it and you can claim they infringed your idea....
[11:04:17] <av500> us courts would agree
[11:04:25] <av500> brillant!
[11:06:49] <pJok> its super effective!
[11:07:09] <pJok> mru, did it choke on ffmpeg source yet?
[11:07:10] <av500> yes
[11:07:22] <av500> i gues it is still building
[11:08:21] <pJok> just interesting to see what it makes of the source
[11:12:06] <Compn> thresh : damn adobe sucks at security
[11:16:44] <pJok> Compn, nothing new there
[11:20:51] <pJok> Compn, every other week there's a new problem with acrobat reader... so i stopped caring
[11:21:23] <Compn> reader scares me
[11:22:21] <Compn> that java one that sends spam thru your open webmail account is fun tho
[11:22:55] <Compn> guess its back to disabling all plugins like back in the day
[11:47:32] <mru> pJok: it chokes on int64_t
[12:01:00] <pJok> mru, funny... so its quite unusable then?
[12:01:30] <mru> yes, totally
[12:01:58] <mru> we rely on 64-bit arithmetic working
[12:02:02] <cartman> PING kh-notblockedbyturkey.l.google.com (74.125.77.190): 56 data bytes
[12:02:04] <cartman> for real :D
[12:05:45] <kshishkov> cartman: makes you wonder how much Tukey bans then
[12:05:54] <cartman> too much :D
[12:07:10] <kshishkov> cartman: and what happens if you say to policeman "Hello, I'm of Armenian-Kurd origin, Ataturk killed my ancestors, your country sucks"?
[12:07:30] <mru> they put you in jail
[12:07:35] <cartman> the last sucky part gets you in jail
[12:07:45] <cartman> first two just gets flames
[12:08:07] <kshishkov> so saying things about Armenian genocide is okay now?
[12:08:23] <cartman> yes
[12:08:36] <cartman> see the recent ruling about now deceased Hrant Dink
[12:08:46] <cartman> Turkey will pay 100.000 Euros
[12:09:02] <kshishkov> not 100k Turkih Liras?
[12:09:07] <cartman> nah
[12:09:13] <mru> turkis euros
[12:09:19] <mru> +h
[12:09:27] <av500> are they like italian euros?
[12:09:30] <av500> or greek ones?
[12:09:37] <cartman> german euros :P
[12:10:46] <cartman> http://www.hurriyetdailynews.com/n.php?n=european-court-found-turkey-guilty-on-dink-case-2010-09-14
[12:11:19] <kshishkov> av500: Polish Euros should be fine too
[12:11:48] <av500> polished? sure
[12:11:56] * av500 likes 'em shiny
[12:12:09] <cartman> one Apple-W too much :P
[12:12:26] <av500> wapple?
[12:12:34] <cartman> mapple!
[12:12:39] <cartman> steve mobs :P
[12:12:41] * Compn waits for steve jobs to rename to isteve jobs
[12:12:51] <av500> it will be iSteve
[12:13:00] <kshishkov> av500: BTW, I saw guy using Archos book reader
[12:13:10] <av500> and he will introduce iJobs once president
[12:13:16] <av500> kshishkov: err, which one?
[12:14:11] <kshishkov> av500: dunno, black case, maybe 7" display
[12:14:19] <kshishkov> "Archos" label
[12:14:32] <av500> ah ok, the archos 7 home tablet
[12:14:32] <kshishkov> and it was used for reading some text
[12:16:40] <kshishkov> still, that may be the first time I've seen Archos product used in the wild
[12:19:03] <KotH> you mean, you've never seen any of the products in the wild, you produce?
[12:19:29] <av500> i have
[12:20:07] <KotH> your own do not count ;)
[12:20:48] <Compn> typically they produce hardware in 3rd world countries and sell in first world countries, with first world prices, thus guarenteeing that the person who makes said product would never spend a few months wages on it
[12:21:27] <av500> Compn: dont forget they also jump from factory roof
[12:22:47] <kshishkov> Compn: Apple-brand fairy dust is very expensive
[12:22:54] <mru> pJok: it also doesn't support compound initialisers
[12:23:28] <mru> nor designated initialisers
[12:23:58] <mru> and not variadic functions
[12:24:21] <kshishkov> funny, the first C compiler used special library functions for 32-bit multiplications that were missing on PDP and newer one can't support 64-bit
[12:24:30] <kshishkov> variadic?
[12:24:35] <kshishkov> like printf?
[12:24:37] <mru> yes
[12:24:52] <mru> it allows calling them, but not implementing
[12:25:09] <mru> chokes on va_list stuff
[12:25:32] <KotH> mru: what compiler? mrucc?
[12:25:40] <kshishkov> KotH: tcc
[12:25:44] <mru> no, not tcc
[12:25:53] <mru> that silly "formally verified" one
[12:26:07] <kshishkov> hosted at inria?
[12:26:10] <mru> that one
[12:26:22] <kshishkov> have you tried pcc?
[12:26:30] <cartman> possible c compiler?
[12:26:32] <kshishkov> it should also fail nice
[12:26:33] <mru> what would be the point?
[12:26:37] <KotH> formally verified compiler?
[12:26:41] <KotH> what the heck does that mean?
[12:26:53] <kshishkov> KotH: "yup, it's compiler"
[12:26:55] <mru> exercise in academic futility
[12:27:01] <cartman> KotH: it can be used for mission critical stuff
[12:27:08] <KotH> cartman: yeah. right
[12:27:11] <mru> http://compcert.inria.fr/
[12:27:31] <mru> so far I've only got it to compile hello world
[12:27:43] <KotH> cartman: it is ceritified that it cannot fail under no circumstances in the enviroment it was designed in. unfortunately, it will be never used in this enviroment
[12:27:50] <cartman> they have nice diagrams, they must ve right
[12:28:36] <kshishkov> yeah, first diagram - "CIL, C#Minor", include me out
[12:29:14] <av500> last step: powerPC assembly
[12:29:22] <cartman> yeah thats a wtf moment
[12:29:26] <av500> ah right, mac only
[12:29:39] <mru> it runs on linux too
[12:30:12] <kshishkov> av500: probably register allocation goes all GCC on machine with less available registers
[12:30:13] <av500> MAC/Linux?
[12:30:25] <av500> GNU/MAC/Linux?
[12:32:34] <KotH> MAC/Linux+GNU
[12:32:42] <KotH> you have to follow the new nomencalture
[12:33:10] * kshishkov kills KotH by dropping Stallman on him
[12:33:40] * KotH rattles with his chains
[12:33:50] * KotH haunts kshishkov for all eternity
[12:34:20] * kshishkov uses Ghost of Communism on KotH
[12:34:31] * jannau recently listened to a radio interview with a FSFE supported struggling with GNU/ when speaking about android
[12:34:49] <jannau> s/supported/supporter/
[12:34:56] <KotH> GNU/android?
[12:35:15] <KotH> .o0(an android gnu)
[12:36:16] <jannau> he said android uses GNU/linux
[12:36:22] <av500> jannau: so was it gnu/android to him?
[12:36:25] <av500> ah
[12:36:25] <KotH> o_0
[12:36:48] <KotH> i'm not sure, but i dont think there is any gnu software running on android
[12:37:03] <av500> that was the whole idea :)
[12:37:13] <av500> except gcc
[12:37:23] <mru> that's not running _on_ android
[12:37:28] <av500> jaja
[12:37:37] <cartman> j0j0 RMS ownz you via gcc
[12:37:53] <cartman> it inserts .rms sections to your code
[12:37:59] <kshishkov> yes, sometimes I feel owned after using GCC
[12:38:16] <av500> cartman: not mine, I removed the GPL notive from every source code file :)
[12:38:20] <av500> notice
[12:38:33] * cartman sends RMS after av500 
[12:38:49] <cartman> he can kill you with his bare beard
[12:38:54] <av500> bare feet
[12:39:02] <cartman> nah he is heavy
[12:39:06] <cartman> feet will of course work
[12:39:22] <kshishkov> av500: it's fun to see you two wrestle
[12:39:23] <mru> his beard will probably disgust you to death
[12:39:32] <mru> death by disgustion
[12:39:36] <av500> mru: it feeds a family of 4 for a week....
[12:39:39] <cartman> yeah
[12:40:03] * mru wouldn't be surpised if a family of 4 rats lived in it
[12:41:32] <kshishkov> named "gcc", "gas", "gld" and "gnu"
[12:43:10] <av500> btw, if i take gcc, mod it a lot and compile sw with it, am i allowed to distribute said sw?
[12:43:22] <mru> can't see why not
[12:43:36] * pJok rerolls GCCs random code generator
[12:44:16] <cartman> av500: thats what Apple does
[12:44:25] <cartman> send a huge diff too
[12:44:44] <av500> diff?
[12:44:51] <cartman> patch
[12:44:54] <mru> no need
[12:45:01] <cartman> its fun
[12:45:04] <mru> you're not including the compiler binary with the distribution
[12:45:17] <kshishkov> they do
[12:45:46] <mru> apple yes
[12:45:54] <av500> but not evil me
[12:46:06] <cartman> not sending patch is not evil
[12:46:15] <cartman> Apple has patches but those are GPLv2 only
[12:46:22] <cartman> hence GCC can't merge them
[12:46:26] <cartman> treats them nicely
[12:46:29] <kshishkov> av500: see the latest XKCD
[12:47:59] <cartman> kshishkov: fun
[12:48:27] <kshishkov> cartman: fun was when av500 was told those strips also have alt text
[12:48:40] <Tjoppen> derp. avidec.c sets AVStream::start_time to zero
[12:48:43] <cartman> ah , rookie
[12:48:43] <cartman> :D
[12:49:14] <cartman> I met a guy from Google who doesn't know what Dilbert is
[12:49:17] <cartman> its a weird world
[12:50:05] <Tjoppen> I'm copying packets in the range [10,60) seconds from one file to the other (not touching timestamps) and the demuxer gets A/V 10 sec out of sync
[12:50:27] <av500> 10 .. 10 I see a pattern
[12:50:46] <Tjoppen> yes. probably that start_time line
[12:51:20] <Tjoppen> "Only set this if you are absolutely 100% sure that the value you set it to really is the pts of the first frame."  so the demuxer doesn't follow the API. should be easy peasy to patch it then
[12:51:46] <kshishkov> what's output file format?
[12:52:11] <Tjoppen> avi -> avi
[12:52:22] <Tjoppen> and just filtering out packets outside that range
[12:52:42] <kshishkov> still, timestamps may be preserved and they're present only for video
[12:52:54] <Tjoppen> well, it doesn't seem to preserve them for the audio
[12:53:10] <Tjoppen> it sort of magically comes up with the audio timestamps, while video has them correct
[12:53:12] <kshishkov> because they're not stored for audio, I think
[12:53:15] <Tjoppen> audio starts at 0, video at 10
[12:53:47] <av500> kshishkov: avi stored neither timestamps
[12:53:51] <av500> stores
[12:54:11] <kshishkov> yes, I strongly suspected that
[12:54:14] <Tjoppen> indeed. it just stores byte offsets and such in its index
[12:54:34] <kshishkov> so you should look at avienc.c
[13:01:09] <Tjoppen> maybe so. I'll poke a bit at it
[13:09:35] <Tjoppen> ah, right.. it uses empty packets to handle VFR and such. so it treats the first incoming video packet with dts=383 as expected. but this doesn't reaaly seem possible to apply to audio
[13:10:47] <Tjoppen> this will become very interesting if I feed it timestamps from say MXF. it is quite common that its timestamps start at 1:00:00 or 10:00:00
[13:16:36] <Tjoppen> it seems my demuxing code already subtracts start_time. might as well do something similar when demuxing then :o
[13:16:48] <Tjoppen> err.. *muxing
[13:22:12] <CIA-63> ffmpeg: stefano * r25118 /trunk/ (7 files in 3 dirs): Implement libopencv smooth filter.
[13:22:13] <CIA-63> libswscale: ramiro * r32241 /trunk/libswscale/ (rgb2rgb.c rgb2rgb_template.c):
[13:22:13] <CIA-63> libswscale: rgb2rgb: don't misuse HAVE_* defines
[13:22:13] <CIA-63> libswscale: Introduce and use COMPILE_TEMPLATE_* instead.
[13:37:26] <CIA-63> ffmpeg: rbultje * r25119 /trunk/libavcodec/ (5 files in 2 dirs): (log message trimmed)
[13:37:26] <CIA-63> ffmpeg: Rename h264_idct_sse2.asm to h264_idct.asm; move inline IDCT asm from
[13:37:26] <CIA-63> ffmpeg: h264dsp_mmx.c to h264_idct.asm (as yasm code). Because the loops are now
[13:37:26] <CIA-63> ffmpeg: coded in asm instead of C, this is (depending on the function) up to 50%
[13:37:26] <CIA-63> ffmpeg: faster for cases where gcc didn't do a great job at looping.
[13:37:27] <CIA-63> ffmpeg: Since h264_idct_add8() is now faster than the manual loop setup in h264.c,
[13:37:28] <CIA-63> ffmpeg: in-asm idct calling can now be enabled for chroma as well (see r16207). For
[14:23:55] <Tjoppen> ah, michael ok'd av_popcount(). time to commit I guess
[14:24:43] <BBB___> what is that?
[14:24:48] <mru> which one did he approve?
[14:26:06] <Tjoppen> popcount3.patch. the bit hack one
[14:27:14] <Tjoppen> occupies less space if nothing else. also, good enough for now
[14:27:53] <mru> bit hack and 4-bit table are more or less equivalent speedwise it seems
[14:33:08] <kshishkov> someone should hardwire it to inline asm though
[14:35:04] <mru> gcc seems to do a good enough job unless the machine has a popcount instruction
[14:37:49] * av500 wants a popcorn instruction
[14:37:59] <av500> ah, HCF
[14:38:01] <kshishkov> i.e. not on x86, ARM or PPC?
[14:38:29] <KotH> av500: HCF?
[14:38:30] <kshishkov> av500: popcorn was an arcanoid clone with catchy tune
[14:38:35] <mru> KotH: halt and catch fire
[14:38:57] <av500> aka toggle all io lines as fast a possible
[14:39:23] <kshishkov> those are implementation details
[14:39:36] <kshishkov> could be just a bit of termite embedded
[14:39:41] * mru is reminded of bit-banged dram interface
[14:39:55] <av500> mru: it did not catch fire
[14:40:49] <kshishkov> there are wonderful inventions but few live so long as x86
[14:42:05] <KotH> and it will live a lot longer than anyone would intend it to live
[14:42:22] <KotH> hence, we'll have soon programmer archeoligists
[14:42:52] * av500 reminds people of how dead e.g. COBOL is
[14:42:57] <av500> ppl learn it today...
[14:43:38] <kshishkov> yes, legacy is a curse
[14:44:11] <kshishkov> av500: would you call fresh CS graduate to patch your old FORTRAN code?
[14:44:49] * av500 would post job offer in retirement homes
[14:44:52] * mru read that as french
[14:45:16] <av500> the french only know Fourtrain
[14:45:29] <kshishkov> Fourtraint
[14:45:44] <av500> Le Fourtraint
[14:46:08] <kshishkov> av500: where's your HQ again?
[14:46:38] <CIA-63> ffmpeg: thardin * r25120 /trunk/libavutil/ (avutil.h common.h): Add av_popcount() to libavutil/common.h and bump minor version
[14:47:30] <Tjoppen> there. now I can get on with my patch
[14:56:14] <merbzt> I know a girl who is studying to be a cobol programmer
[14:56:29] <lu_zero> merbzt: how so?
[14:56:30] <KotH> must be a very geek girl '^^
[14:56:37] <lu_zero> or into SM
[14:56:45] <KotH> or after the big money
[14:56:52] <lu_zero> there is?
[14:56:58] <av500> merbzt: does she have grandchildren?
[14:57:11] <KotH> at least here in .ch you get quite some bucks if you know cobol or pl/1
[14:57:15] <merbzt> not that I know of
[14:57:15] <cartman> Processor	: ARMv6-compatible processor rev 6 (v6l)
[14:57:15] <cartman> BogoMIPS	: 499.71
[14:57:19] <cartman> hail my new Android tablet!
[14:57:25] <merbzt> her employer pays her education
[14:57:35] * KotH hails the great king of chocolate
[14:57:43] <cartman> thats me :P
[14:57:47] <av500> merbt: the only cobol coder "girl" I know is my mom, and she has :)
[14:57:53] <av500> +z
[14:58:00] <KotH> cartman: turkish chocolate is not any better than japanese chocolate
[14:58:05] <merbzt> av500: lol :)
[14:58:07] <merbzt> awesome
[14:58:08] <KotH> cartman: though the bonibon have style :)
[14:58:22] <KotH> av500: lol
[14:59:33] <KotH> av500: how come your mom ended up as cobol programmer?
[14:59:43] <av500> it was all the rage in '65
[15:00:26] <av500> she did that for a few years, then ended up more in DB2 admin
[15:01:10] <KotH> hmm...
[15:01:44] <kshishkov> luckily for us all, IBM is slowly dying
[15:01:45] <KotH> i think in 65 my mother was either cutting up dead bodies, or helping to make babies cry
[15:02:13] <KotH> kshishkov: i wouldnt be surprised if ibm survives m$
[15:02:22] <av500> KotH: as long as not cutting up crying babies...
[15:02:31] <kshishkov> KotH: of course it will
[15:02:47] <KotH> av500: i dont think she did that.. though she cut up a few living people too
[15:03:11] <kshishkov> KotH: how did you get mother from China?
[15:03:15] <KotH> av500: and sticking needles into her classmates
[15:03:30] <kshishkov> ... or from Haiti
[15:03:31] <KotH> kshishkov: huh?
[15:04:22] <kshishkov> KotH: http://en.wikipedia.org/wiki/Cultural_revolution seems appropriate enough
[15:04:36] <lu_zero> Haiti....
[15:04:57] <kshishkov> lu_zero: Voodoo is the main religion there
[15:06:11] <KotH> kshishkov: eh.. she was a midwife and surgery nurse by profession :)
[15:07:52] <kshishkov> KotH: ah. I always thought that slapping newborn on his/her ass is a good welcome to this world
[15:08:10] <BBB> kshishkov: when will you commit your wvp decoder? :-p
[15:08:14] <av500> kshishkov: yes, but you need a certified slapper
[15:08:46] <kshishkov> BBB: when I finish it, of course. Not that I've started yet.
[15:09:11] <KotH> kshishkov: better than shooting them :)
[15:09:19] <kshishkov> av500: nope, for instance, you'd do fine without certificate
[15:09:43] <kshishkov> KotH: that's arguable
[15:14:33] <KotH> kshishkov: you mean you should have been shot instead of slapped?
[15:15:08] <av500> slapshot?
[15:17:26] <kshishkov> KotH: dunno, could be better life
[15:17:54] <kshishkov> av500: possible with glove launcher
[16:45:20] <Compn> i dont understand the whole slapping baby thing. howd it go 1000 years ago before we got this slapping idea?
[16:45:52] <av500> slapped by mammut
[16:46:06] <av500> sorry, that was 10k ys ago
[16:46:20] <av500> 1k ys ago, slapping might have been known
[16:49:18] <KotH> Compn: the slapping is only a help to get the baby breathing
[16:49:36] <av500> its not like you need to slap life into it
[16:49:42] <KotH> Compn: most start breathing w/o it, but some need a good slap before they can enjoy living
[16:50:06] <av500> KotH: my kids both was not slapped :)
[16:50:34] <mru> they saved the slapping later?
[16:50:49] <KotH> av500: yeah, and see what became of them!
[16:51:45] * mru has met the little trolls
[16:53:50] <KotH> did they throw stones at you?
[16:54:01] * elenril is now officially a bc
[16:54:03] <elenril> \o/
[16:54:35] <cartman> binary compatible?
[16:55:15] <KotH> bc is an calculator
[16:55:18] <av500> mru: yes, save the slapping for a time when they can remember it :)
[16:55:19] <KotH> s/an/a/
[16:55:36] <elenril> what KotH said
[16:56:05] * KotH ponders whether he should call for a video coder developer meeting in the first week of june 2011
[16:56:16] <av500> sure
[16:56:22] <av500> ffcon?
[16:56:25] <av500> where?
[16:56:33] <av500> i suggest beermany
[16:56:35] <KotH> @lug-camp :)
[16:56:43] <av500> a chocountry
[16:56:53] <cartman> come to Turkey once in a while damn it
[16:57:03] <KotH> yes, chococountr.pampa
[16:57:16] <av500> KotH: in a tent? moi? come on
[16:57:28] <KotH> cartman: sure, organize room enough and we'll come :)
[16:57:39] <KotH> av500: we've bunkers to sleep in too :)
[16:58:16] <av500> you'll have to move some saddam gold to make room for me....
[16:58:21] * KotH wouldnt recomend to sleep in a tent at the location we currently plan, unless you are from lapland
[16:58:39] <KotH> av500: nah.. not necessary
[16:58:44] * av500 survived iceland in a tent
[16:58:57] <KotH> av500: we've standardized, one-size-fits-all beds in our bunkers ;)
[16:58:59] <mru> but iceland did not survive
[16:59:16] <cartman> KotH: prove me you are serious and it can be done
[16:59:25] * KotH is always serious
[16:59:32] <KotH> unless i'm not serious
[16:59:41] <KotH> when*
[16:59:46] <cartman> s/you/all the multimedia guys
[17:00:02] <KotH> cartman: btw: you owe me a meeting anyways
[17:00:14] <cartman> KotH: true
[17:00:34] <cartman> I think TUBITAK might be interested in sponsoring a multimedia event
[17:00:36] <cartman> possibly
[17:00:44] <cartman> and I could troll easily :P
[17:01:20] <KotH> cartman: tubitak sponsored meeting? that'd be cool!
[17:01:32] <cartman> KotH: Pardus -> Tubitak
[17:01:46] <KotH> cartman: so ka
[17:01:50] <KotH> cartman: omoshiroii
[17:01:50] <av500> tubiwhat?
[17:02:03] <av500> ah tubitak
[17:02:03] <cartman> av500: like inria
[17:02:08] <cartman> just Turkish
[17:02:09] <av500> tübitak
[17:02:38] <cartman> (Rarely) Research & (Barely) Development
[17:02:48] <cartman> they got money though :P
[17:04:19] <Compn> KotH : yes i know that, i was just curious what they did before they learned this bit of information? just a lot of dead babies ?
[17:04:41] <KotH> Compn: i dont think anyone remeberes when that custom first appeared ^^'
[17:04:48] <KotH> Compn: it's old, very old knowledge
[17:05:00] <av500> and it could have traces of cargo
[17:05:36] <KotH> Compn: and yes, it probably has been learned the way how 99.9999% of all medical knowledge came to be: by pure accident that some thing freaky worked
[17:12:48] <CIA-63> ffmpeg: mru * r25121 /trunk/libavcodec/arm/h264idct_neon.S: ARM: fix NEON h264_idct_add8
[18:19:43] <BBB> peloverde: ping
[18:31:37] <peloverde> pong
[18:45:16] <lu_zero> @root ping
[18:45:37] <lu_zero> KotH, mru, anybody else =P
[18:46:41] <mru> pong
[18:48:58] <lu_zero> roundup migration plan
[18:50:18] <j0sh> http://pastebin.com/kqD56TmU
[18:50:28] <j0sh> hdcp key
[18:50:38] <mmu_man> yep
[18:50:41] <spaam> yeah
[18:50:44] <mmu_man> mirror it everywhere
[18:51:06] <lu_zero> time to have a different t-shirt design?
[18:51:57] <mmu_man> need to get a new wardrobe and get rid of those DECSS ones ?
[18:56:18] <CIA-63> ffmpeg: mru * r25122 /trunk/configure: Update pathscale compiler detection
[20:26:31] <j0sh> intel's new core arch (sandy bridge) has hardware decoders and encoders
[20:26:45] <j0sh> http://www.anandtech.com/show/3922/intels-sandy-bridge-architecture-exposed/6
[20:27:17] <j0sh> Dark_Shikari: what do you think?
[20:37:00] * mru think Dark_Shikari will start ranting about asics
[21:08:18] <Dark_Shikari> j0sh: It's 5x slower than x264
[21:08:22] <Dark_Shikari> therefore, embarassing
[21:08:42] <Dark_Shikari> it's probably worse too
[21:08:57] <thresh> what about decoding?
[21:09:09] <Dark_Shikari> Probably similar to the GPU stuff we already have
[21:11:11] <Dark_Shikari> every time I see a test in which they downscale 1080p to ipod resolution for benchmarking encoding, it's basically a guarantee they're trying to cheat
[21:11:46] <thresh> but that's like 99% of transcodes nowadays on cpu's like that
[21:12:14] <mru> what kind of cpu core is this?
[21:12:33] <Dark_Shikari> mru: it's just an asic stuck onto the cpu
[21:12:37] <Dark_Shikari> much like the asic decoder on a gpu
[21:12:41] <_av500_> lol
[21:12:42] <Dark_Shikari> thresh: not really
[21:12:49] <Dark_Shikari> who the hell encodes from a blu-ray to an ipod?
[21:13:04] <mru> yes, but what cpu is it bolted to?
[21:13:06] <mru> atom?
[21:13:08] <mru> something real?
[21:13:08] <Dark_Shikari> mru: sandy bridge
[21:13:12] <Dark_Shikari> i.e. something real
[21:13:19] <mru> I'd have to look up what that means
[21:13:20] <Dark_Shikari> the successor to nehalem
[21:13:38] <mru> is that i7?
[21:13:47] <Dark_Shikari> same product line, yes
[21:14:58] <mru> so what's the point of the video thing?
[21:15:06] <mru> the main cpu should be plenty fast enough
[21:15:53] <Dark_Shikari> buzzword compliance, getting people to use their shit
[21:17:01] * mru wonders how much money is wasted on buzzword crap
[21:20:54] <kierank> [22:12] <@Dark_Shikari> who the hell encodes from a blu-ray to an ipod? --> virtually all the non-x264 benchmarks I've seen end up doing that an calling it "1080p encoding"
[21:21:01] <kierank> and*
[21:21:37] <mru> lol
[21:43:19] <Compn> Dark_Shikari : so you want to see bluray to deinterlaced bluray comparasions? :P
[21:43:26] <Compn> er deinterlaced 1080 that is
[21:43:31] <Compn> 1080/720
[21:44:45] <Compn> youd think they would have found out how to keep non-interlaced and interlaced losslessly on the same stream, much like how the 3d stuff is stored or something
[21:44:49] <Compn> frames, fields
[21:44:54] * Compn has no clue what hes talking about
[21:48:17] <j0sh> i would think at least things like hardware dct/idct or cavlc could be helpful
[21:48:32] <Dark_Shikari> Compn: blurays aren't interlaced
[21:48:48] <Dark_Shikari> j0sh: dct/idct is so fast that 'accelerating' it would be meaningless
[21:49:06] * j0sh has no idea how the dct is implemented
[21:49:19] <Dark_Shikari> it takes less than 2% of total time
[21:49:31] <merbanan> cabac takes more
[21:59:57] <kierank> some blu-rays are interlaced
[22:00:03] <kierank> sports
[22:00:11] <Dark_Shikari> yes, few.
[22:02:52] <bcoudurier> fyi espn shoots and broadcast in 720p
[22:03:11] <kierank> yes because they are not stupid
[22:03:18] <kierank> though espn europe is 1080i...
[22:03:51] <Dark_Shikari> I thought they shoot in 1080p60
[22:03:55] <Dark_Shikari> and then downconvert for cable
[22:04:00] <Dark_Shikari> (to whichever broadcasters prefer)
[22:04:20] <kierank> iirc some parts of their chain are 1080p60 but not all
[22:10:06] <bcoudurier> shoot in 1080p60 ?
[22:10:37] <bcoudurier> that would be awesome but that's not certain they bought so many cameras that can, or is it cheaper now ?
[22:10:46] <kierank> no i don't think they shoot in 1080p60 yet
[22:13:17] <Compn> oh
[22:13:23] <Compn> then what about interlaced dvds? :P
[22:14:02] <Dark_Shikari> that's basically just concerts
[22:14:41] <bcoudurier> espn europe is 1080i ? stupid ..
[22:15:12] <_av500_> its best of both, 1080 and 60fps :)
[22:15:14] <bcoudurier> is it dumbass EBU that required that ?
[22:16:40] <kierank> no it is the british that promote 1080i...
[22:16:49] <kierank> the ebu promote 720p50
[22:17:02] <_av500_> german tv backed of 720 recently
[22:17:23] <_av500_> now they retarget for 1080
[22:17:36] <_av500_> german public tv that is
[22:17:38] <kierank> because people complained?
[22:17:46] <_av500_> because they were alone
[22:17:53] <jannau> _av500_: not exactly. It sounded more that they are speculating for 1080p50
[22:18:03] <kierank> _av500_: there are quite a few 720p50 channels in europe
[22:18:08] <_av500_> k
[22:18:20] <kierank> svt, hd suisse, orf (on some platforms)
[22:18:24] <kierank> estonian one
[22:18:33] <_av500_> .ch and .orf tend to follow .de :)
[22:18:52] <kierank> encoders suck anyway so it all looks like crap
[22:18:58] <_av500_> course
[22:19:19] <kierank> or when decent encoder is used bitrate is too low
[22:19:36] <_av500_> but "its hd"
[22:19:49] <_av500_> ppl can buy larger tv sets
[22:20:25] <_av500_> i met a guy who was happy to watch analog crap cable on a 100"
[22:21:43] <CIA-63> ffmpeg: michael * r25123 /trunk/libavformat/avformat.h: Clarify what av_read_frame() returns.
[22:22:20] <jannau> _av500_: still batter that crap private DVB-T on a 100"
[22:24:14] <_av500_> lol micheal, so i am free to chop up a file as i see fit and return the pieces in av_read_frame()?
[22:25:31] <_av500_> sorry, lol michael
[23:45:03] <jannau> argh, declaring libpostproc|swscale history as mess is an understatement. I can understand why mru doesn't want to fix it more than once
[23:45:12] <jannau> +a