[FFmpeg-devel-irc] IRC log for 2010-03-03

[irc at mansr.com]

[00:10:48] <CIA-92> ffmpeg: cehoyos * r22160 /trunk/libavcodec/vdpau.c:
[00:10:48] <CIA-92> ffmpeg: Support B-frames when decoding MPEG-4 with VDPAU hardware acceleration.
[00:10:49] <CIA-92> ffmpeg: Based on a patch by NVIDIA.
[01:39:21] <CIA-92> ffmpeg: michael * r22161 /trunk/libavcodec/h264.h:
[01:39:21] <CIA-92> ffmpeg: Load the whole left side of mv&ref only when needed.
[01:39:21] <CIA-92> ffmpeg: 30 cpu cycles faster
[01:39:52] <Dark_Shikari> woot more h264 stuff
[01:40:32] <mru> those cycle counts are a bit meaningless without more context
[01:40:42] <mru> is that per frame, per-mb, per-mv or what?
[01:40:46] <Dark_Shikari> per mb
[01:41:38] <astrange> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/mpeg12.c;h=09bac2d8603b1c168b5ed7bc8510a84a48754084;hb=HEAD#l857 hmm can't qscale*quant_matrix[j] be done when the quant matrixes are loaded?
[01:41:53] <Dark_Shikari> sounds very bad for cache if qscale varies often
[01:42:26] <Dark_Shikari> then again, I think h264 does that.  x264 definitely does
[01:43:02] <astrange> well it doesn't vary more than once per mb
[01:43:07] <Dark_Shikari> true
[01:43:19] <Dark_Shikari> you could precalculate for all possible qscales
[02:21:42] <CIA-92> ffmpeg: michael * r22162 /trunk/libavcodec/h264.h: Another 3 useless zeroing instructions.
[02:36:19] <mru> lol at winmo-using idiot
[03:09:19] <Compn> hah ohloh fixed it
[03:09:20] <Compn> http://www.ohloh.net/p/ffmpeg/analyses/latest
[03:09:35] <mru> about time
[03:09:52] <mru> still haven't fixed autoconf claims
[03:11:03] <Compn> haha
[03:11:14] <Compn> should call it something different than configure
[03:11:19] <Compn> call it ffconfigure :D
[03:11:34] <mru> but it's easy to spot genuine autoconf
[03:11:48] <mru> if "configure" is larger than C files combined, it's autoconf
[03:12:10] <mru> and by larger I mean orders of magnitude larger
[03:20:43] <peloverde> they still haven't fixed the c++ claims either
[03:20:52] <mru> there is one c++ file
[03:20:54] <mru> something beos
[03:23:45] <peloverde> really? I can't seem to find it
[03:24:06] <mru> libavdevice/beosaudio.cpp
[03:25:12] <peloverde> ahh, there it is
[03:25:26] <peloverde> for a while ohloh was counting all .h files as c++
[05:48:51] <elenril> Honoome: ping
[08:12:17] <superdump> hmm
[08:12:21] <superdump> hey DonDiego
[08:12:32] <superdump> some bugs in the ffmpeg 0.5.1 release announcement
[08:12:37] <superdump> i was just about to fix them :)
[08:12:56] <superdump> they point to the 0.5.1 release notes and changelog
[08:13:05] <superdump> and the name on the downloads page wasn't edited
[08:13:43] <DonDiego> hmmm?
[08:15:51] <superdump> DonDiego: i'm fixing it
[08:15:53] <superdump> don't worry
[08:16:37] <superdump> the version wasn't changed at the top of the release notes
[08:16:53] <DonDiego> beat you to it
[08:16:54] <superdump> and now i'm not really sure what the version name is supposed to be
[08:16:56] <superdump> ok
[08:17:27] <superdump> nor the date in the release notes
[08:18:31] <DonDiego> imagine that the version name refers to the branch :)
[08:20:31] <superdump> hehe
[08:21:50] <superdump> oops
[08:21:55] <DonDiego> ah, good catch :)
[08:22:05] <superdump> better
[08:22:12] <superdump> i thought my client needed quotes
[08:22:13] <superdump> it seems not
[08:23:27] <Dark_Shikari> superdump: so can I harass you to write an x264enc2 gstreamer module? ;)
[08:23:37] <Dark_Shikari> I discussed with ds some various API ideas
[08:23:45] <Dark_Shikari> to fix the disaster of the current one
[08:23:50] <superdump> sure
[08:24:11] <superdump> maybe in #gstreamer or a query though
[08:24:19] <superdump> here doesn't seem an appropriate place :)
[08:24:45] <Dark_Shikari> then let's bounce over there
[08:26:00] <CIA-92> ffmpeg: diego * r22163 /branches/0.5/RELEASE: Add point release date.
[08:28:13] <DonDiego> WVP2
[08:28:30] <DonDiego> does not have a mentor listed, but it's a first tier project - what gives?
[08:28:50] <DonDiego> same for wma lossless and ralf
[08:29:59] <Dark_Shikari> WVP2 is the single most important codec imo
[08:30:26] <Dark_Shikari> maybe kostya could mentor it?
[08:39:17] <DonDiego> why so important?
[08:39:54] <Dark_Shikari> according to facebook statistics, it is the most popular missing codec
[08:39:59] <Dark_Shikari> by a large margin
[08:40:11] <Dark_Shikari> WMA Speech, WMA Pro, and Indeo 5 removed all the ones that were anywhere close
[08:40:21] <Dark_Shikari> leaving WVP2 as the sore thumb sticking out, the last one we don't have.
[08:40:44] <DonDiego> where is it used?
[08:40:54] <Dark_Shikari> it's used by Windows Movie Maker I would guess.
[08:41:11] <Dark_Shikari> iirc like 1-2% of all facebook video uploads were wvp2
[08:41:24] <kierank> wow
[08:41:31] <superdump> what's the largest? h.264? :)
[08:41:37] <Dark_Shikari> superdump: probably mjpeg
[08:41:42] <superdump> mmm
[08:41:47] <Dark_Shikari> cameras, cell phone cameras
[08:41:48] <twnqx> not xvid?
[08:41:55] <kierank> why xvid?
[08:42:14] <kierank> mjpeg is understandable because of all the crappy cameras
[08:51:58] <jai> no ralf eh :)
[08:52:41] <astrange> does ralf have any marketshare?
[08:52:45] <jai> nope
[08:53:01] <astrange> tak has non-zero marketshare, which is bad for a closed source lossless codec
[08:53:20] <jai> tak has a huge fanboi base over at HA
[08:53:35] <kierank> we should RE those Red codecs
[08:53:37] <KotH> HA?
[08:53:42] <kierank> that would shut all the RED fanboys up
[08:53:42] <astrange> hydrogenaudio
[08:53:56] <jai> kierank: we should first fix our demuxer :|
[09:05:48] <DonDiego> hey, what happened with justin's spectral extension patch for ac-3?
[09:08:23] <superdump> hmm, if it didn't get merged, it probably got overreviewed and left
[09:13:39] <jai> stuck in the review queue
[09:13:53] <jai> justin didnt get around to posting a new patch
[09:14:36] <jai> but i like how superdump phrased it :)
[09:17:36] <CIA-92> ffmpeg: diego * r22164 /trunk/libavdevice/bktr.c:
[09:17:36] <CIA-92> ffmpeg: Add _NETBSD_SOURCE definition to fix compilation on NetBSD.
[09:17:36] <CIA-92> ffmpeg: NetBSD is unlikely to fix their headers and the FATE box passes it
[09:17:36] <CIA-92> ffmpeg: as -D_NETBSD_SOURCE on the command line anyway. In this case, it's
[09:17:36] <CIA-92> ffmpeg: better to keep the hack well-contained within this file.
[09:17:37] <CIA-92> ffmpeg: Closes issue 886.
[09:17:38] <CIA-92> ffmpeg: patch by Jorge Acereda, jacereda brainstorm es
[09:23:24] <DonDiego> somebody prod justin to pick it up again..
[09:24:05] <superdump> maybe he doesn't have time
[09:29:13] <DonDiego> maybe he just needs to get asked :)
[09:39:02] <CIA-92> ffmpeg: pross * r22165 /trunk/libavcodec/iff.c: use intended const syntax
[09:45:24] <CIA-92> ffmpeg: pross * r22166 /trunk/libavformat/bink.c: Support demuxing of streamed Bink files
[09:47:48] <superdump> siretart: do you know who does the packaging for gst-ffmpeg?
[09:48:12] <bilboed-pi> superdump, you might wanna specify the distro :)
[09:48:32] <superdump> well, siretart does ffmpeg packages for ubuntu/debian
[09:48:39] <superdump> and i'd like to know for both :)
[09:49:27] <peloverde> packages.{debian.org,ubuntu.com}?
[09:50:26] <peloverde> http://packages.debian.org/sid/gstreamer0.10-ffmpeg
[09:51:23] <peloverde> Looks like Sebastian Dröge for both
[09:51:36] <superdump> mmm
[09:51:38] <superdump> slomo
[09:51:40] <superdump> :)
[09:51:43] <superdump> and sjoerd
[09:52:46] <CIA-92> ffmpeg: pross * r22167 /trunk/libavcodec/binkaudio.c: Perform coefficient transformations in Bink Audio DCT decoder (issue1770)
[09:53:10] <Dark_Shikari> pross-au: does that fix the audio artifacts?
[09:53:48] <pross-au> Dark_Shikari: yep!
[09:53:53] <Dark_Shikari> wooohoo
[09:54:03] <Dark_Shikari> now we just need kostya to fix the speed bug in bink files
[09:54:20] <pross-au> Is that all?
[09:54:26] <pross-au> :D
[09:54:32] <Dark_Shikari> and the seek issue
[09:54:43] <andoma> it would be awesome to get AAC-HE in the 0.6 release
[09:54:47] <pross-au> seeking is not practical
[09:55:23] <Dark_Shikari> pross-au: I mean that if I click on the video, it crashes mplayer
[09:55:29] <pross-au> oh what?
[09:55:31] <Dark_Shikari> and of course it's practical
[09:55:47] <Dark_Shikari> do it the same way you seek in anything else without an index
[09:55:49] <pross-au> there is only one keyframe
[09:55:49] <Dark_Shikari> Just Keep Decoding
[09:55:51] <Dark_Shikari> And?
[09:55:56] <Dark_Shikari> bink decodes quickly
[09:56:06] <Dark_Shikari> if I hit forward, I expect it to decode faster than realtime until I get there.
[09:56:09] <peloverde> andoma: HE-AAC would be awesome, but I feel like we've had this discussion every day this week. I'm still stalled on the same two vague review points
[09:56:37] <pross-au> havent tried bink with mplayer
[09:56:52] <andoma> peloverde: right :/
[09:57:06] <pross-au> but if bink seek is crashing, i will have a look at it
[09:57:23] <peloverde> The sample rate issue is actually important the otherone is just kind of wishlisty as far as I'm concerned
[09:57:45] <astrange> i think you could ignore the filterbank one, it's ok for now in my profiling
[09:57:50] <astrange> (not much)
[09:58:50] <peloverde> astrange: I agree, but the sample rate thing absolutely needs to play nice with the rest of ffmpeg
[09:59:42] <astrange> but i do think you can factor sbr->k[4]][i + ENVELOPE_ADJUSTMENT_OFFSET][0] and phi[0/1][indexsine] out of the loop at the end of sbr_hf_assemble
[10:10:04] <peloverde> I'll fix that right now
[10:27:27] <pross-au> Dark_Shikari: mplayer does not crash here when i click in the window..
[10:58:29] <CIA-92> ffmpeg: michael * r22168 /trunk/libavcodec/h264.c: Simplify implicit_weight table init.
[10:59:07] <elenril> is seeking in bink supposed to work?
[11:21:21] <pross-au> elenril: seeking takes you back to frame '0'
[11:31:42] <peloverde> astrange: I just overhauled sbr_hf_assemble()
[11:55:25] * DonDiego cheers on peloverde
[11:55:37] <DonDiego> "works with HTML 5" needs you :9
[11:55:38] <DonDiego> :)
[12:07:01] <peloverde> How do we feel about memory vs speed tradeoffs
[12:07:50] <peloverde> I can get 11% improvement from HE-AAC but it will cost doubling the synthesis buffers
[12:10:13] <superdump> peloverde: well, doubling might be ok if the amount being doubled is not too large
[12:11:07] <peloverde> It's a 4K increase per channel
[12:13:00] <andoma> 4 Kelvin?
[12:13:01] <iive> peloverde: how much memory does that mean in typical use?
[12:13:34] <iive> aka 8192 for stereo?
[12:13:49] <merbzt> http://i.imgur.com/yMgFT.jpg
[12:13:53] <peloverde> 8192 kbytes for stereo
[12:14:08] <peloverde> it's per channel actually used, not per max channels
[12:14:24] <iive> 8MB...
[12:15:05] <peloverde> err 8192 bytes per stereo
[12:15:22] <peloverde> didn't mean to double count the 1024
[12:15:37] <peloverde> 8MB for 2048 channels ;)
[12:15:55] <iive> that's nothing. not all devices have 8mb free memory, but i bet they could sqeeze 8k from somewhere.
[12:16:32] * KotH would struggle to find 8kb of free memory on his devices
[12:16:58] <iive> your devices don't have enough memory for the whole aac code, let alone data :P
[12:17:14] <peloverde> I wound up replacing a per channel per frame memmove with an occasional memcpy
[12:17:24] <peloverde> AAC can be done with much less memory than we do
[12:17:45] <peloverde> (see my old aac-lowmem patch)
[12:18:02] <merbzt> peloverde: did you look at the opencore aac decoder ?
[12:18:07] <KotH> peloverde: can that part be easily isolated?
[12:18:13] <merbzt> have they done any neat tricks ?
[12:18:22] <KotH> peloverde: ie, would it be feasible to have a compile time switch to choose memory vs cpu?
[12:19:01] <peloverde> merbzt: opencore IIRC is just the 3GPP refsoft from coding technologies (now dolby.de) under a different license
[12:19:29] <merbzt> ok
[12:19:57] <peloverde> KotH: It would be possible but it would add some complications to the code
[12:20:04] <merbzt> peloverde: how much faster is the he code compared to faad ?
[12:20:10] <KotH> peloverde: ok, then it's not feasible
[12:20:13] <peloverde> also most people who care about lowmem also want fixed pont which we don't do... yet
[12:20:41] <KotH> is there a use of he-aac for non-vidoe files?
[12:20:41] <peloverde> merbzt: we are about 25% faster before this improvement
[12:20:58] <peloverde> he-aac is used heavily by streaming music
[12:21:15] <peloverde> http://www.shoutcast.com/
[12:21:17] <KotH> offline?
[12:21:20] <iive> i thought the he is low quality?!
[12:21:32] <KotH> if you have streaming, you've tcp, if you've tcp, you've enough memory for sure
[12:21:43] <andoma> lot of tv broadcasting is starting to use aac-he now as well
[12:21:56] <peloverde> there are portable players that support HE-AAC
[12:22:06] <KotH> the only use case that cares about memory in that range would be portable mp3-players
[12:22:08] <wbs> those shoutcast-aac-streams, they're progressive http downloads, right?
[12:22:31] <peloverde> the 3GPP refsoft is a good starting point for most users
[12:22:56] <merbzt> KotH: ie the rockbox guys
[12:23:02] <peloverde> It's really high quality for refsoft, probably because coding was hoping to make up for it in licensing
[12:23:04] <KotH> merbzt: exactly
[12:23:29] <peloverde> 3GPP refsoft also supports floating point
[12:25:29] <peloverde> however this particular speedup/memory tradeoff would be a very simple ifdef
[12:27:18] <KotH> hmm... looks like most cpu's used for mp3 players have something in the range of 64k internal ram + some external attached... (but extermal mem might need to be mapped or copied first to be used)
[12:29:43] <peloverde> I wish I had 64K when I was doing that stuff
[12:30:40] * iive looking for his ancient apple ][e clone
[12:30:52] <KotH> peloverde: that stuff?
[12:31:57] <peloverde> Vivace Semiconductor VSP-100 and other Improv Systems Crescendo based platforms
[12:32:52] <peloverde> the company is defunct now
[12:36:53] <peloverde> http://web.archive.org/web/20080513081706/www.vivacesemi.com/technology/technology.html
[12:37:40] <merbzt> Real Media
[12:37:44] <merbzt> cool :)
[12:54:26] <thresh> haha, russian "linux-related" websites wrote about ffmpeg 0.5.1
[12:54:39] <thresh> mentioning changes from trunk as changes in 0.5.1
[12:54:43] <thresh> idiots
[12:57:05] <merbzt> I think we need a pre written text that "news" sites can take
[12:57:16] <merbzt> instead of writing crap
[12:59:09] <thresh> yes, this would be awesome indeed
[12:59:22] <thresh> however this is already written on a website, lol
[13:00:01] <merbzt> I mean for 0.6
[13:00:11] <merbzt> 5.1 is already out
[13:00:35] <merbzt> maybe even translate it
[13:03:34] <jai> "FFmpeg Press Kit"? ;)
[13:03:54] <kierank> lol
[13:39:35] <superdump> mru: ping?
[13:40:22] <mru> pong
[13:43:05] <merbzt> anyone know what baptiste is up to ?
[13:49:42] <superdump> mru: i was just wondering if there were any special kernel options needed for oprofile with an armv5l
[13:50:05] <superdump> other than profiling, oprofile, have_oprofile and tracepoints
[13:50:06] <mru> you need an armv5 with perf counters to begin with
[13:50:11] <mru> I don't think there are many
[13:50:16] <superdump> oh
[13:50:25] <superdump> how can i tell? is it in cpuinfo?
[13:50:28] <mru> you can use oprofile in timer mode
[13:50:41] <superdump> yes, i have /dev/oprofile/cpu_type timer
[13:50:44] <mru> less accurate but works everywhere
[13:50:48] <superdump> ok
[13:51:11] <superdump> then i guess that may have to do
[13:51:46] <mru> you could also do profiling on an armv7 with caches, dual-issue, and branch pred turned off :-)
[13:52:08] <mru> L2 caches
[13:53:18] <superdump> :)
[14:13:55] <jez9999> Anyone know why, in rtpproto.c, ffmpeg calls select(), but passes NULL for its timeout value, so it ends up blocking indefinitely?
[14:16:50] <wbs> jez9999: no reason that I can see, I guess it should wait in shorter periods and at least check url_interrupt_cb(), like other uses of select
[14:16:55] <wbs> patch welcome, I guess :-)
[14:17:34] <mru> guys, please read http://hardwarebug.org/2010/03/03/ogg-objections/
[14:18:59] <bilboed-pi> comparing ogg (a streaming format by design) and iso (not a streaming format) is a bit of a fallacy
[14:19:03] <bilboed-pi> (in the overhead section)
[14:19:47] <kierank> add that the name "granule" sound stupid
[14:19:48] <mru> ogg claims to be a general-purpose format
[14:19:59] <bilboed-pi> lol
[14:20:31] <bilboed-pi> indexes have been added to ogg a month back
[14:20:36] <bilboed-pi> (yes, about friggin time)
[14:21:38] <mru> what?
[14:21:41] <mru> where is this?
[14:21:45] <mru> I read the spec last night
[14:22:25] <jez9999> BBB____: hey, i've noticed that rtpproto.c's rtp_read() function calls select(), but passes NULL for the timeout.
[14:22:32] <jez9999> this means that it blocks indefinitely
[14:22:36] <jez9999> presumably this is wrong
[14:22:41] <bilboed-pi> mru, let me check
[14:22:55] <BBB> jez9999: that's probably wrong, yes
[14:23:08] <BBB> it should select() like the udp/tcp functions
[14:23:26] <merbzt> http://www.inmethod.com/air-video/licenses.html
[14:24:15] <jez9999> BBB: any reason the time value is set using microsecs and not millisecs?: tv.tv_usec = 100 * 1000;
[14:24:28] <jez9999> could be tv.tv_sec = 100
[14:24:36] <mru> merbzt: are they doing anything wrong?
[14:24:40] <wbs> jez9999: that's seconds, not milliseconds
[14:24:46] <jez9999> ah
[14:24:46] <jez9999> ok
[14:25:08] <BBB> microseconds
[14:25:09] <jez9999> well isn't a 10th of a second too short?
[14:25:10] <BBB> so 0.1 sec
[14:25:11] <bilboed-pi> mru, my bad, still a draft : http://wiki.xiph.org/Ogg_Index
[14:25:16] <BBB> jez9999: no, because it loops
[14:25:17] <jez9999> it's going to return quite often with no new data
[14:25:22] <jez9999> oh i see
[14:25:40] <BBB> jez9999: the timeout is so we cancel out of the loop through url_interrupt_cb
[14:25:43] <mru> ewww, what an ugly wiki
[14:25:46] <jez9999> i wonder whether xuggler has any way to access url_interrupt_cb.
[14:25:46] <BBB> otherwise it loops
[14:25:59] <bilboed-pi> mru, and this blog has a bit more details : http://pearce.org.nz/blog/
[14:26:04] <bilboed-pi> anyway, going home
[14:26:25] * bilboed-pi is gonna have to add support for avcodec_align_dimensions2 in gst-ffmpeg :(
[14:27:25] <merbzt> mru: they have some patches in there
[14:27:32] <kierank> lol at the 32-bit frame counter
[14:28:08] <merbzt> mru: might be worth to check for
[14:29:11] <wbs> BBB: btw, had time to check this one? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083999.html
[14:29:15] <wbs> it should be quite straight forward
[14:29:29] <BBB> I missed that one
[14:29:33] <BBB> I wonder why I did
[14:29:33] <BBB> anyway
[14:29:41] <BBB> have to go to a meeting
[14:29:45] <BBB> will be back and will check
[14:29:49] <BBB> +/- 2 hrs
[14:29:54] <wbs> ok, no hurry :-)
[14:34:37] <iive> mru: in the first section, mapping thing sounds too complicated, add general example like "you cannot do stream copy of video from ogg to mkv, without knowing and supporting the exact codec and its mapping, even if you don't change even 1 bit of the data itself"
[14:35:01] <mru> mapping _is_ too complicated
[14:38:44] <mru> iive: also, I don't think stream copy is _that_ important
[14:39:13] <iive> it is just example that is easy to understand.
[14:39:29] <mru> I don't want to use contrived examples
[14:41:04] <iive> well, it's your blog. but people would have hard time to understand why different mappings are such a problem.
[14:42:33] <CIA-92> ffmpeg: michael * r22169 /trunk/libavcodec/ (h264_refs.c h264.c h264.h): Merge weight & offset tables, 15 cpu cycles faster.
[14:42:42] <mru> would they understand why stream copy is important?
[14:42:45] <mru> I don't...
[14:43:07] <mru> people just want to play their films
[14:46:44] <iive> well, after reading how horrible is ogg, they would like to convert their movies into something playbale...
[14:46:58] <mru> I doubt they actually have any ogg files
[14:47:07] <mru> when was the last time you saw one in the wild?
[14:47:19] <kierank> on wikipedia :/
[14:51:39] <iive> mru: there was a time when a lot of anime groups supported the "new kid" ogg, at least for the ability to embed subtitles in it. So yeh... Fortunately they've long moved to mkv and/or mp4
[14:52:24] <iive> anyway, the copy is just simplified example of the common input processing system of every media player.
[14:52:37] <iive> btw, does ogg have a way to signal keyframes?
[14:52:46] <mru> no
[14:52:53] <mru> codec mappings can define one
[14:53:46] <iive> well, your explanation of seeking is missing this point completely.
[14:54:12] <iive> it means that you must use codec parser to be able to seek...
[14:57:32] <mru> ogg seeking sucks even _without_ that point
[14:58:52] <DonDiego> nonetheless a point worth making..
[14:59:09] <DonDiego> something i never understood:
[14:59:19] <DonDiego> vp3 worked fine in various containers
[14:59:33] <DonDiego> there was no need to create a new container to begin with
[14:59:39] <mru> ogg is much older
[14:59:54] <mru> it was created for vorbis and vorbis only
[15:00:03] <mru> which is indeed a bitch to store in other containers
[15:00:11] <DonDiego> still theora could be designed to work in generic containers
[15:00:12] <mru> because they botched the design
[15:00:18] <mru> as could vorbis
[15:00:32] <mru> but there's a lot of NIH over at xiph
[15:04:01] <KotH> there is lots of NIH all over OSS ;)
[15:04:41] <iive> by botched you mean, they intentionally made it dependent on ogg.
[15:05:06] <mru> yes
[15:08:31] <iive> the whole point here is that each aspect of ogg sucking multiplies the other aspects, making ogg suck exponentially.
[15:09:05] <mru> I want to focus on the points monty hasn't dismissed already
[15:09:14] <mru> but I'm adding a note to the seeking section
[15:11:08] <jez9999> BBB: see issue 1790 - i'm writing a patch now
[15:11:29] <DonDiego> mru: this should not be just for monty
[15:11:45] <DonDiego> monty can answer the points if he wants to
[15:11:56] <DonDiego> but they should be raised for the general public nonetheless
[15:13:08] * KotH prints mru's blog and distributes it on the street
[15:13:33] <mru> KotH: hold your horses, it's still in beta
[15:17:33] * KotH holds his ponnies
[15:24:11] <CIA-92> ffmpeg: gb * r22170 /trunk/libavcodec/vaapi_h264.c:
[15:24:11] <CIA-92> ffmpeg: Cope with rev 22169 change:
[15:24:11] <CIA-92> ffmpeg: Merge weight & offset tables.
[16:14:14] <DonDiego> "In a large file with variable bitrate, 50 seeks might be required to find the correct position."
[16:14:27] <DonDiego> add some numbers to this
[16:14:38] <DonDiego> "large" and "variable" are quite vague
[16:15:21] <DonDiego> "one should bear in mind that the Ogg format designed at a time"
[16:15:23] <DonDiego> -->
[16:15:29] <DonDiego> "one should bear in mind that the Ogg format WAS designed at a time"
[16:16:00] * mru makes note not to write stuff after 5am in future
[16:48:33] <CIA-92> ffmpeg: michael * r22171 /trunk/libavcodec/h264.h: move svq3 specific fields to the end of the context
[16:50:34] <Anarhist> what's the credit policy of FFMpeg, if i submit the patch which i believe to be non-trivial (ie it took me a better part of the day to debug and get it to the point where it's something i'm proud of) can i add myself to the CREDITS within that same patch. also what are the chances of somebody saying "i could have done that in 5 minutes, so you are lame"
[16:57:39] <BBB> Anarhist: CREDIT requires a non-trivial feature addition, I think
[16:58:24] <BBB> Anarhist: but you could always try...
[16:58:29] <Anarhist> ok, i probably won't give anything to myself probably, looking at the credits file, it seems that it's pretty small
[16:59:03] <Anarhist> or maybe try, and if i get flamed, it's only internet
[16:59:47] <mru> a day's work is not usually enough for a mention in CREDITS
[17:00:34] <Anarhist> fair enough, it differs from project to project, so that's why i've asked
[17:04:06] <mru> if you send a patch your name will be mentioned in the commit message
[17:06:44] <DonDiego> "There is, however, a significant different there"
[17:06:46] <DonDiego> --->
[17:06:51] <DonDiego> "There is, however, a significant differenCE there"
[17:08:18] <Anarhist> well, that's cool i'm not really out for fame, i just wanted to know how it's done here
[17:08:52] <BBB> most people in the CREDITS file have SVN access
[17:09:04] <Anarhist> lol, i'm sorry that is funny
[17:09:12] <BBB> you get SVN access after being involved and supplying multiple patches for a longer period of time
[17:09:22] <BBB> it's vague :)
[17:12:19] <mru> DonDiego: reload
[17:15:47] <mru> there's some discussion at http://news.ycombinator.com/item?id=1164161
[17:16:42] <DonDiego> already?
[17:16:52] * kierank posted it
[17:16:59] <DonDiego> please mention what the standard terms they changed are
[17:17:05] <DonDiego> maybe in a quick table
[17:25:23] <CIA-92> ffmpeg: vitor * r22172 /trunk/libavcodec/ (vp6.c vp56.c): Plug some memory leaks in the VP6 decoder
[17:26:51] <CIA-92> ffmpeg: vitor * r22173 /trunk/libavformat/nsvdec.c:
[17:26:52] <CIA-92> ffmpeg: Plug memory leak in NSV demuxer.
[17:26:52] <CIA-92> ffmpeg: Patch by Jai Menon.
[17:27:09] <DonDiego> all in all the tone of the post could be a tad more neutral
[17:27:49] <mru> it's hard...
[17:29:59] <DonDiego> i know
[17:30:14] <DonDiego> your timestamp article is much more neutral though
[17:32:18] <CIA-92> ffmpeg: vitor * r22174 /trunk/ (8 files in 3 dirs): Plug memory leak in NUT muxer and demuxer
[17:33:19] <iive> mru: actually i think you should add another chapter for the symbiotic link between ogg, vorbis and theora. A lot of people confuse ogg and vorbis.
[17:36:45] <DonDiego> mru: i think the message of your post would benefit from being toned down a bit
[17:37:02] <DonDiego> you can see the reaction on ycombinator.org already..
[17:37:16] <mru> any part in particular?
[17:37:22] <DonDiego> let me see..
[17:37:49] <DonDiego> oh, and yes, a few quick introductory words about ogg vs. vorbis vs. theora vs. whatever might help
[17:37:53] <mru> I guess I could drop the bit about the romans...
[17:38:10] <DonDiego> same as you did in the timestamp article
[17:39:23] <DonDiego> "True generality is evidently not a quality favoured by Xiph."
[17:39:27] <DonDiego> could be misread..
[17:39:45] <mru> I could drop that
[17:40:17] <DonDiego> the roman numeral comparison is actually good, it helps explain
[17:40:31] <DonDiego> but the snide remark after that does not..
[17:41:03] <mru> I enjoyed writing that part...
[17:41:12] <iive> btw, this thing about the romans, it's used by mkv to store the pack the 3 hears into extradata, and i think that it comes from some rfc, not sure if it was tcp or something.
[17:41:46] <mru> I've never seen it attributed to anything but xiph
[17:41:47] <DonDiego> i believe you, it is funny :)
[17:41:50] <DonDiego> "True generality is evidently not a quality favoured by Xiph."
[17:41:56] <DonDiego> say something about ogg there
[17:42:08] <DonDiego> don't put words into the xiph people's mouths
[17:42:18] <mru> xiph designed ogg
[17:42:36] <DonDiego> "The Ogg format is clearly not a good choice for a low-latency application."
[17:42:46] <DonDiego> same statement now directed at ogg instead of xiph
[17:42:51] <DonDiego> s/same/comparable/
[17:44:20] <mru> so I'll remove the last 2 sentences in the roman paragraph?
[17:45:20] <DonDiego> for example, yes
[17:45:42] <DonDiego> it's nice that you gave a number for the amount of seeks now
[17:46:00] <DonDiego> maybe you can add a second one for a file below a gig
[17:46:18] <DonDiego> 10GB is a large file and not necessarily common depending on application
[17:46:26] <janneg> mru: at least the SEI in h264 uses the same format: size=0;
[17:46:34] <janneg> do{
[17:46:49] <janneg> size+= show_bits(&s->gb, 8); }while(get_bits(&s->gb, 8) == 255);
[17:47:29] <mru> presumably that field is unlikely to ever need more than 2 bytes
[17:47:59] <DonDiego> the last paragraph is somewhat flamish as well
[17:47:59] <mru> in ogg a 20-byte field is _normal_
[17:48:00] <janneg> I would think so
[17:48:34] <mru> DonDiego: which last paragraph?
[17:48:46] <DonDiego> final words
[17:48:47] <janneg> just to point out that the encoding is used elsewhere
[17:48:51] <mru> about patents?
[17:48:54] <mru> flamish?
[17:49:03] <mru> you've become sensitive...
[17:49:56] <janneg> it makes sense if the length is usually below 255 but could be longer in rare cases
[17:50:14] <mru> yes
[17:50:29] <mru> you have to look at the statistical distribution to choose a good encoding
[17:50:53] <mru> if 5-10k is a normal value this is not a good encoding
[17:59:51] <janneg> not to speak about raw yuv data, 16k just to encode the the length of a single 1080p frame
[18:00:59] <mru> let's not go there
[18:04:34] <iive> argh, can't find the rfc thing
[18:04:38] <DonDiego> mru: no, not necessarily the patents, more like "certain organizations", "ferocity", "campaigners", etc..
[18:04:53] <mru> campaigner is bad now?
[18:07:27] <DonDiego> not in itself
[18:07:42] <DonDiego> but you're loading all the terms up with a lot of adjectives
[18:07:43] <mru> how would you describe them?
[18:08:17] <DonDiego> pick out some of what monty said
[18:08:23] <DonDiego> and present it more neutrally
[18:08:38] <DonDiego> then pick it apart based on technical merit
[18:09:19] <DonDiego> but i guess it's not that important
[18:09:20] <Compn> what url are you guys talking about? the hacker news entry ?
[18:09:31] <DonDiego> i'm off home now
[18:09:44] <DonDiego> i fixed the autobuilder at work enough for today :)
[18:10:04] <mru> DonDiego: I thought a picking-apart was exactly what this was
[18:10:37] <mru> Compn: he probably meant http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/
[18:10:42] <mru> look for comments from monty
[18:12:51] <DonDiego> it is a picking apart
[18:13:06] <DonDiego> but at the end you only quickly touch on common replies
[18:13:16] <DonDiego> in much less detail than the rest of the post
[18:13:28] <DonDiego> it might be worth answering some of monty's points in more detail
[18:13:40] <DonDiego> Compn: http://hardwarebug.org/2010/03/03/ogg-objections/
[18:14:28] <mru> DonDiego: I was trying to keep the amount of debating low
[18:14:32] <Compn> ah i was going to check mru's blog, but i got distracted. trying to do 400 things at once is one or two too many
[18:14:36] <DonDiego> ok, going home now, cu tommorrow
[18:23:00] <Dark_Shikari> mru: why the hell didn't you mention matroska?
[18:23:01] <Dark_Shikari> seriously
[18:23:15] <Dark_Shikari> it is what we _NEED_ to do
[18:23:17] <Dark_Shikari> read http://news.ycombinator.com/item?id=1164694 , no
[18:23:18] <Dark_Shikari> *now
[18:23:20] <Dark_Shikari> and go mention matroska
[18:24:32] <elmojo> janneg: let me know if you want more help with BBB rendering - I got a C2Q with 4GB (8GB in a few days hopefully)
[18:25:25] <ohsix> heh, doesn't that allege conspiracy when there is a valid reason for it existing (the ecosystem angle)
[18:26:13] <Dark_Shikari> What conspiracy?
[18:26:16] <Dark_Shikari> that isn't a conspiracy
[18:26:31] <ohsix> whereas their realm of purview and interest is their own ecosystem, they aren't interested in things outside of it for their intent and purpose
[18:26:39] <Dark_Shikari> the GPL existing is not a conspiracy
[18:26:52] <Dark_Shikari> no seriously, I argued with an ogg advocate yesterday
[18:26:56] <Dark_Shikari> he made EXACTLY THIS ARGUMENT
[18:27:01] <Dark_Shikari> that Ogg is better because it doesn't let you use non-free formats
[18:27:06] <Dark_Shikari> and that's why Ogg is more free
[18:27:12] <ohsix> whom? is it public?
[18:27:50] <ohsix> i'd have to take it under consideration to not make most of whats under the bullet points out to conspiracy
[18:27:54] <Dark_Shikari> it was a debate in #ffmpeg
[18:27:57] <Dark_Shikari> it's not a conspiracy!
[18:28:02] <Dark_Shikari> it's quite open and obvious
[18:28:12] <ohsix> heh
[18:28:12] <Dark_Shikari> xiph obviously does not allow h264 in ogg because they don't want people putting h264 in ogg
[18:28:15] <Dark_Shikari> what's conspiratorial about that?
[18:28:34] <ohsix> is #ffmpeg also posted to michaels irc log list?
[18:29:12] <Dark_Shikari> don't know
[18:29:14] <Dark_Shikari> probably not
[18:29:41] <ohsix> k
[18:30:48] <ohsix> its just my opinion having not witnessed this conversation that it being omitted and being used as a pseudo proof is nonconvincing, i cant falsify your theory considering the entire statement as made
[18:31:19] <Dark_Shikari> wait
[18:31:25] <Dark_Shikari> so you are claiming there is not one person in the world who believes what I stated?
[18:31:54] <ohsix> i'm not talking about beliefs
[18:32:49] <mru> Dark_Shikari: do you have a log of that conversation?
[18:32:52] <ohsix> i'm talking about the statement and why it looks conspiratorial to me, if i ever read the conversation you essentially make reference to, i may have a different opinion; as might any reader of the statement
[18:34:54] <twnqx> i do have.
[18:34:58] <twnqx> the log, that is
[18:35:05] <Dark_Shikari> mru: can you just stuff matroska in that damn post? =p
[18:35:26] <mru> Dark_Shikari: why? this is about ogg
[18:35:38] <mru> and matroska overhead at least isn't all that stellar
[18:36:03] <Dark_Shikari> But you should give an alternative
[18:36:10] <Dark_Shikari> people will ignore your whining unless you say "Thus you should use...X"
[18:36:18] <mru> I HATE PEOPLE
[18:36:24] <Dark_Shikari> Like in my post you are one of the people ignoring the fact that Matroska exists
[18:36:27] <Dark_Shikari> and just debating about Ogg
[18:36:33] <Dark_Shikari> If you want to smack the Ogg people down, give them another option
[18:36:37] <mru> why am I not allowed to recognise that something stinks without offering a ready solution?
[18:36:47] <Dark_Shikari> You are, but you need to think practically here.
[18:36:56] <Dark_Shikari> people will disregard your post by saying "ogg is the best we have"
[18:36:59] <Dark_Shikari> when that is OBVIOUSLY A LIE.
[18:37:04] <Dark_Shikari> (referring to patent-free formats)
[18:37:17] <Dark_Shikari> in order to deal with that, you have to give an alternative.
[18:37:45] <mru> ok, I'll add a section on alternatives
[18:37:56] <mru> I'll think about it while I cook dinner
[18:38:40] <twnqx> uh... pastebin only outputted /
[18:38:42] <twnqx> :(
[18:40:55] <twnqx> ohsix / mru: http://pastebin.org/100661 if you're really THAT bored
[18:41:07] <mru> Dark_Shikari: the matroska spec is a bit messy... calculating the overhead will take some time
[18:41:28] <ohsix> i dont think an alternative needs mentioning for objective statements, you muddle & bring in possible attacks from detractors for what you advocate; muddling your original objective, maybe have a follow up post on why matroska sucks too, then ref the earlier discussion; people can make their own judgement
[18:41:54] <twnqx> overhead + gain through h.264 vs. less overhead + loss through theora.. hmmm
[18:42:01] <ohsix> twnqx: thanks
[18:42:19] <mru> h264 in ogg is trivial if you bother
[18:42:49] <twnqx> well, i don't really care, i'm converting ogg on sight
[18:42:50] <CIA-92> ffmpeg: rbultje * r22175 /trunk/ffserver.c:
[18:42:50] <CIA-92> ffmpeg: Update to work with chunked encoding HTTP streams (as served by FFmpeg since
[18:42:50] <CIA-92> ffmpeg: a few months now). Fixes issue 1738.
[18:42:58] <ohsix> at the very least if you say why everything sucks, someone can pick something that sucks the least and be quite confident thats the best they can currently manage :P
[18:43:19] <twnqx> mru: with seek index? :P
[18:43:45] <BBB> I hate ffserver
[18:44:23] <twnqx> my main reason to dislike ogg is mplayer's fail at playing it, e.g. automatically selecting the right audio stream by language
[18:44:29] <BBB> anyway, another issue fixed...
[18:44:38] <twnqx> oh, and failing to automatically enable subtitles etc
[18:44:47] <ohsix> fwiw, right off in that #ffmpeg discussion, when i was using ffmpeg to do mkv stuff, it wouldn't seek either; i resorted to elementary streams and using mkvmerge
[18:45:03] <twnqx> just mkvmerge the .mkv
[18:45:04] <ohsix> i was no doubt doing something wrong
[18:45:07] <twnqx> easier.
[18:45:09] <twnqx> no
[18:45:44] <mru> twnqx: well, blame ogg for not having a standard language tag
[18:45:53] * twnqx blames ogg 
[18:45:58] <janneg> elmojo: sure, read http://www.jannau.net/bbb_videowall/ and ask if you have questions
[18:46:12] <janneg> mru: which job did you choose?
[18:46:25] <elmojo> janneg: trying to download the production files but no one is seeding it right now
[18:47:26] <janneg> elmojo: I'm seeding, the piratebay tracker is obviously down, so you need to have dht enabled
[18:48:28] <elmojo> dht enabled here... let me try another client
[18:48:39] <Dark_Shikari> mru: I don't mean a comparison
[18:48:43] <Dark_Shikari> I just mean a note about it as an alternative
[18:50:27] <ohsix> fwiw, i asked the fellow to refine what he meant about ogg/mkv & gpl/bsd, first thing he said 10:48 <Anarhist> well, i'm reconsidering my ogg position at the moment
[18:53:36] <Dark_Shikari> he did
[18:53:38] <Dark_Shikari> I convinced him of mkv ;)
[18:54:09] <Dark_Shikari> all I said was that such a thing was the argument he made at one point
[18:54:18] <Dark_Shikari> which means there is at least one person who believes or believed such a thing.
[18:54:26] <Dark_Shikari> meaning it's not a strawman.
[18:54:45] <astrange> mkv mappings aren't so generic either
[18:55:05] <Dark_Shikari> It's still more flexible though
[18:55:10] <astrange> they hadn't heard of "generic" when they started it, so the codecs they had heard of all get weird special ones
[18:55:11] <Dark_Shikari> not generic, sure, but at least they exist.
[18:55:21] <Dark_Shikari> Would be better if they were _actually_ generic.
[18:55:35] <astrange> (there's an old slashdot comment by christoph whoever it was saying that mov "doesn't support MPEG-2")
[18:55:47] <ohsix> heh dont make assumptions, i dont think that conversation convinced anyone of anything; he went on to mention that you cant use it as a general container was something to look further into
[18:56:04] <Dark_Shikari> obviously, I convinced him to look further into it ;)
[18:56:46] <ohsix> its something his cursory understanding just missed; it wasn't exactly well argued huhuhu
[19:05:15] <ohsix> i think its important that the guy was willing to defend his opinion even if it was poorly stated as "fact", but he is rationally assessing the fact that you cant use it as a general container now
[19:24:20] <ohsix> heres the conversation i had with the guy if anyone is further interested http://pastebin.org/100673
[19:25:15] <Dark_Shikari> http://www.lyris-lite.net/2010/girl_hornet.png blu-ray quality folks
[19:31:09] <andoma> ??
[19:31:55] <Dark_Shikari> just a screenshot from a blu-ray disk.
[19:32:02] <Dark_Shikari> courtesy of "bad encoder land"
[19:32:37] <CIA-92> ffmpeg: fenrir * r22176 /trunk/libavcodec/tta.c: Fixed overreads in TTA decoder with corrupted bistreams.
[19:32:37] <CIA-92> ffmpeg: michael * r22177 /trunk/libavcodec/h264.h: Note about luma/chroma_weight tables and their datatype.
[19:33:14] <CIA-92> ffmpeg: michael * r22178 /trunk/libavcodec/h264.c: cosmetic addition of {}
[19:45:15] <CIA-92> ffmpeg: michael * r22179 /trunk/libavcodec/h264.h: remove unused left_border field from context.
[19:48:46] <Yuvi> mru: could you elaborate on the advantages of splitting packets in mpeg-ts? (and whether they also apply to ps?)
[19:51:11] <Yuvi> btw, #theora was funny, before your post was posted they were telling someone to use chained ogg instead of actually adding chapters to ogg
[19:51:40] <mru> rotfl
[19:52:02] <mru> chained ogg streams have no inter-relation whatsoever
[19:53:40] <Yuvi> apparently giving each chained segment a different title will make it look like it has chapters in firefox
[19:54:46] <elenril> chained ogg is something like segment linking in matroska?
[19:55:03] <CIA-92> ffmpeg: fenrir * r22180 /trunk/libavcodec/dxva2_h264.c: Fixed DXVA2 H264 hwaccel compilation.
[19:55:07] <Yuvi> except worse, since you don't know about it until you hit it in the middle of the file
[19:55:15] <elenril> o_0
[19:55:33] <Dark_Shikari> add that to the post then.
[19:55:56] <elenril> does ffmpeg support that?
[19:56:40] <Yuvi> no, but in theory an application using lavf could if it watched for new streams and assumed chained ogg semantics for what to do with them
[19:57:46] <elenril> btw did anyone except baptiste and michael see the playlist patch from gsoc?
[19:58:44] <Yuvi> Dark_Shikari: 3rd bullet point in complexity
[19:59:25] <Dark_Shikari> ah k.
[19:59:37] <Yuvi> also, correct seeking is a lot more annoying than mru made it out to be
[20:03:33] <Yuvi> and the broken continuations appears to be a bug in libogg that *still* has not been fixed, for at least 3 years
[20:03:54] <mru> that's in *libogg*?
[20:04:03] <ohsix> is there a bug # for that somewhere?
[20:04:44] <mru> ouch, I've been slashdotted
[20:05:13] <mru> webserver temporarily blocked until I get a ratelimit in place
[20:05:45] <Dark_Shikari> er, you don't have a cache?
[20:05:52] <Dark_Shikari> mru: start adding more points, quickly ;)
[20:06:01] <mru> Dark_Shikari: adsl isn't coping
[20:06:15] <Dark_Shikari> mru: you host it on an ADSL?!>!!?
[20:06:17] <ohsix> 302 it to the .nyud.net url
[20:06:17] <mru> do you have a caching proxy I could borrow?
[20:06:35] <Dark_Shikari> I have a dreamhost account
[20:06:44] <Dark_Shikari> if you want I can host a snapshot mirror or something
[20:08:17] <mru> I usually get no more than 200 hits per day
[20:08:24] <Dark_Shikari> as I said
[20:08:28] <Dark_Shikari> give me a snapshot, and I will mirror it
[20:08:30] <Dark_Shikari> and you can post a redirect
[20:08:46] <Dark_Shikari> give me a tar or something
[20:08:49] <Dark_Shikari> I can give you doom10.org/hardwarebug
[20:09:18] <Dark_Shikari> hell if you want, give me the whole site, it really doesn't matter
[20:09:25] <ohsix> http://www.coralcdn.org/
[20:09:34] <Dark_Shikari> coral is really slow
[20:10:01] <Dark_Shikari> so mru, add the comment about matroska and then give me a snapshot
[20:10:03] <Dark_Shikari> and I'll post it
[20:10:38] <ohsix> its slow if it cant reach the origin; which is why you need to do it ASAP :< or manually prime it at the source
[20:12:41] <ohsix> but he's going to have a hard time doing anything if his dsl is being overwhelmed
[20:12:55] <Dark_Shikari> just give me a tarball, as I said.
[20:13:44] <mru> as from wget -r ?
[20:15:46] <ohsix> once its "dead" the article will probably be amended with the nyud bits anyways
[20:16:21] <Dark_Shikari> mru: whatever you want
[20:16:29] <Dark_Shikari> stuff it on mediafire, I'll mirror it, you set up a redirect
[20:16:31] <Dark_Shikari> I don't care how you do it
[20:16:40] <Dark_Shikari> just do it fast.
[20:16:50] <mru> what's the rush?
[20:17:43] <Dark_Shikari> you're on slashdot
[20:17:50] <Dark_Shikari> it's better to get mirorred before you fall off the first page
[20:18:01] <ohsix> (firehose, not /. proper)
[20:18:12] <astrange> it's on my front page
[20:18:20] <mru> http://news.slashdot.org/story/10/03/03/1913246/Technical-Objections-To-the-Ogg-Container-Format
[20:18:29] <ohsix> fancy
[20:18:52] <Dark_Shikari> Ah ok
[20:22:06] <Vitor1001> mru is slashdotted...
[20:23:11] <ohsix> Yuvi: is there a bug # for the continuation thing?
[20:23:23] <Yuvi> ohsix: I don't think so
[20:23:45] <ohsix> hm, how come it wasn't looked into 3 years ago
[20:23:47] <andoma> Connecting to hardwarebug.org...
[20:24:01] <andoma> wellwell
[20:24:33] <mru> I had to block it while I get a mirror up
[20:24:38] <mru> sorry
[20:24:49] <Yuvi> it's admittedly hard to isolate (I haven't created such a file), since you need a packet whose size is modulo 255 and in the stream happens to end on a page
[20:25:09] <andoma> mru: :)
[20:25:33] <ohsix> if they knew they'd probably have fixed it :P or at least told whoever reported it to piss off
[20:25:40] <Vitor1001> BTW, congrats mru for getting our point across...
[20:27:23] <Yuvi> I think we told them when it was first reported and were told it was fixed (since it was produced with old software), then j managed to create another such file with fully updated libs
[20:28:30] <ohsix> is that file available?
[20:32:08] <iive> mru: found out why streamcopy is so important, it's actually from Dark_Shikari's blog. streamers and muxers actually do stream copy.
[20:33:11] <Yuvi> ohsix: http://v2v.cc/~j/samples/breaking_ffmpeg.ogv is the newer one
[20:35:37] <ohsix> heh those are some alien looking artifacts
[20:35:54] <ohsix> could this be used to raise a bug with? i'm not familiar with what teh actual problem is
[20:37:50] <CIA-92> ffmpeg: michael * r22181 /trunk/libavcodec/h264.h:
[20:37:50] <CIA-92> ffmpeg: Move all context fields that are not used in the mb and block layers
[20:37:50] <CIA-92> ffmpeg: to the end of the structure.
[20:37:50] <CIA-92> ffmpeg: 4 cpu cycles faster in 3k cpu cycles
[20:38:23] <Yuvi> the problem is that libogg sometimes will not set the continuation flag if a all of a packet's data is completed on the prior page, but it decided to put the terminal 0 segment on the next page
[20:38:33] <twnqx> wow, michael really reads the details in the chat
[20:38:48] <elmojo> janneg: should have the production files late tonight - you can send me the job you'd like for me to start first or I'll pick one
[20:38:59] <Yuvi> so having such a file doesn't help for debugging except proving it still happens
[20:39:10] <ohsix> hm
[20:40:13] <ohsix> so it generates broken bitstreams?
[20:40:34] <Yuvi> yes, which it happens to also accept without complaint
[20:41:31] <Yuvi> it's also really easy to generate invalid bitstreams with libogg if you don't explicitly flush after the first header packet and also before any data packets
[20:41:37] <Yuvi> which happens a lot
[20:42:34] <Yuvi> and you won't know they're invalid because libogg doesn't complain in playing them
[20:42:40] <ohsix> what are the practical implications if libogg also accepts these broken files? is what its doing out of spec or something? seems that if you could produce a bitstream thats repeatable from libogg then it could be looked at
[20:43:30] <Yuvi> means that other ogg demuxers also have to handle these files, but don't know it because it's not in the spec
[20:43:51] <Yuvi> sorta like how wine has to emulate windows bugs
[20:44:16] <ohsix> hmm, so a fix could be just turning unmentioned behaviour into something documented, and leaving this 3 year thing where it is
[20:44:29] <Yuvi> no
[20:44:58] <Yuvi> well maybe, if you say "ignore the continued flag, it contains nothing useful"
[20:45:25] <Yuvi> which would mean that in seeking, you can't emit the first packet you complete
[20:45:32] <Yuvi> because you don't know if it's continued from former pages
[20:46:16] <ohsix> oggz validate throws an error up for the file, dunno if its related, sec
[20:46:45] <ohsix> http://pastebin.org/100712
[20:47:16] <ohsix> "terminal header page" sounds interesting though
[20:47:27] <Yuvi> the second is the broken continuations, the first is the header stuff I was talking about I think
[20:47:56] <Yuvi> thought ffmpeg2theora fixed that a while ago though
[20:48:34] <ohsix> so the file exists thats broken when it was encoded, i'm wondering how to get libogg to produce the broken stream as is, now; so it can be fixed
[20:49:38] <ohsix> or wait, oggz can chop/edit this file, if its broken after it copies it to another stream it could still be in there? (assuming it makes a full slog through the framing)
[20:49:58] <Yuvi> oggz doesn't use libogg iirc
[20:50:22] <ohsix> ahh
[20:51:17] <ohsix> maybe they could promote the part of oggz that checks for that error to libogg for a while and see if reports come in of it happening, they could put a big fat THIS IS WRONG, POST BUG PLZ type message in there
[20:52:47] <ohsix> ogginfo says its broken too, but in a different way, gap in sequence numbers "got x when expecting y" where ix is 343 and 34, and y is 2 in both cases
[20:53:31] <ohsix> at the very least they can lint any file and fix anything thats evident as it happens in the future, if its reported
[20:54:46] <ohsix> theres something about oggz being better or something than libogg in "oggz" the commands documentation
[20:55:27] <ohsix> apparently it takes off most of the "shoot yourself in the foot" sharp corners that were in libogg
[21:01:46] <CIA-92> ffmpeg: mstorsjo * r22182 /trunk/libavformat/rtpdec_h264.c:
[21:01:46] <CIA-92> ffmpeg: Properly pad H.264 extradata when taken from fmtp SDP attributes
[21:01:46] <CIA-92> ffmpeg: This fixes some valgrind warnings.
[21:03:25] <mru> blog back up of sorts
[21:03:58] <mru> I put a static mirror on ffmpeg.org and ratelimit connections locally
[21:04:06] <mru> seems to stay afloat like that
[21:11:04] <CIA-92> ffmpeg: michael * r22183 /trunk/libavcodec/ (h264_refs.c h264.c h264.h):
[21:11:04] <CIA-92> ffmpeg: Reorder indexes in weight tables.
[21:11:04] <CIA-92> ffmpeg: 5 cpu cycles faster.
[21:15:39] * Vitor1001 can not understand why his patch (http://ffmpeg.pastebin.ca/1821836) does not fix (wrongly) issue 956 :(
[21:28:46] <BBB> Vitor1001: can you make wma1/2dec output float?
[21:29:04] <BBB> there's a issue tracker entry for that
[21:29:11] <BBB> internals are float anyway
[21:47:33] <CIA-92> ffmpeg: aurel * r22184 /trunk/libavformat/matroskadec.c:
[21:47:33] <CIA-92> ffmpeg: matroskadec: timestamps are dts and not pts in ms vfw compatibility mode
[21:47:33] <CIA-92> ffmpeg: original patch by elupus _at_ ecce _dot_ se
[21:50:19] <CIA-92> ffmpeg: aurel * r22185 /trunk/libavformat/matroskadec.c: matroskadec: cosmetic indentation
[21:52:33] <Vitor1001> BBB: I don't know if michael will be ok with making it slower...
[21:52:49] <Vitor1001> Also I'm a little out of time :p
[21:52:53] <BBB> oh ok
[22:04:10] <BBB> Vitor1001: you're a math genius right?
[22:04:27] <janneg> elmojo: pick any
[22:04:30] <BBB> Vitor1001: in the first table on this page: http://projects.scipy.org/scipy/ticket/738, what is the number 0.38461538?
[22:13:41] <drv> lol, googling for that number brings up http://blog.xkcd.com/2009/09/02/urinal-protocol-vulnerability/
[22:16:39] <drv> it's just 5/13
[22:18:14] <thresh> nicely done, xkcd
[22:19:45] <mru> so guys, how can we take advantage of the slashdotting?
[22:20:29] <Dark_Shikari> promote matroska
[22:20:32] <superdump> donations?
[22:20:34] <Dark_Shikari> remind people on slashdot that it's free
[22:21:29] * mru should have stuck google ads on the blog :-)
[22:21:42] <Dark_Shikari> doesn't make anything with /.
[22:22:00] <Yuvi> I really don't get how xiph people think that codec-dependant timestamps aren't retarded
[22:22:35] <Dark_Shikari> it allows them to control what formats people put in ogg
[22:22:38] <Dark_Shikari> for them, it's awesome
[22:23:24] <iive> Yuvi: it is not politically correct to call them retarded, you must call them "different"
[22:23:28] <Dark_Shikari> no no
[22:23:31] <Dark_Shikari> the correct term is palin-american
[22:23:45] <Yuvi> heh
[22:24:03] <Yuvi> I need to draw a diagram of what's frustrating me with seeking
[22:25:09] <Yuvi> since *no other container* has this problem, since no other container defines timestamps in a completely codec-independant way, and allows packets to be split across pages, and allows multiple packets to be packed in one page
[22:26:14] <Yuvi> and the timestamps could be the beginning or end of the assiociated packet
[22:27:33] <j-b> Vitor1001: many thanks
[22:28:57] <iive> Dark_Shikari: i'm quite sure all retarded people feel very offended by that term.
[22:29:29] <BBB> drv: wooh, thanks
[22:29:45] <BBB> drv: what about 0.34013605?
[22:29:56] <CIA-92> ffmpeg: aurel * r22186 /trunk/libavcodec/ (vp6.c vp56.c): move vp6 huffman table freeing code, out of common vp56 code
[22:30:01] * BBB has no idea why there's a number 5/13 in his code
[22:37:54] <drv> BBB: maybe 50/147?
[22:38:28] <BBB> 50/130 and 50/147...
[22:38:31] <BBB> hmm, interesting
[22:40:46] <drv> BBB: http://www.mindspring.com/~alanh/fracs.html looks handy, just found it now
[22:41:36] <BBB> that's pretty cool
[22:42:25] <drv> looks like it does it in a pretty terrible way, but useful nonetheless :)
[22:42:31] <BBB> that's ok
[22:42:33] <BBB> good enough for me
[22:42:39] <BBB> unfortunately it doesn't handle e/pi/etc.
[22:42:41] <BBB> but that's ok
[22:43:16] <drv> yeah, i was considering writing something that knew about common stuff like pi, sqrt(2), etc.
[22:43:25] <drv> but i'm lazy ;)
[23:14:56] <mru> Dark_Shikari: what container/transport do your low-latency friends use?
[23:18:08] <BBB> the ones I talk to use old-fashioned mpeg, or flv
[23:19:42] <j-b> ts ?
[23:21:05] <BBB> no, actual mpeg1 system
[23:21:10] <BBB> you wouldn't believe it
[23:21:55] <mru> mpeg1 system and mpeg2 ps are more or less equivalent
[23:22:21] <mru> ps adds a few optional things that are sometimes nice
[23:22:28] <mru> and the format is a bit cleaner
[23:22:41] <mru> but there's nothing wrong with mpeg1 system as such
[23:23:23] <BBB> well, it means they roughly limit themselves to mpeg1video, so they don't use h264/mpeg4
[23:23:29] <BBB> which is a little silly nowadays, if you as me
[23:23:38] <BBB> but hey, they run a business, not me
[23:24:01] <mru> if you control both ends, shoving anything inside mpeg1-system is trivial
[23:24:47] <Dark_Shikari> mru: UDP
[23:24:54] <BBB> mru: well, they only control the sending part
[23:25:01] <mru> Dark_Shikari: and on top of that?
[23:25:34] <BBB> I think they chose mpeg1sys/mpeg1vid b/c it works nicely within browsers
[23:25:49] <BBB> IE, Firefox on Mac and Windows all support it
[23:26:49] <Dark_Shikari> I don't know
[23:26:53] <Dark_Shikari> probably something custom
[23:26:56] <Dark_Shikari> or maybe something like FLV
[23:26:59] <Dark_Shikari> i.e. trivially simple
[23:27:03] <Dark_Shikari> I think it's a very very simple custom layer
[23:27:06] <Dark_Shikari> For flash they use RTMP obviously
[23:27:18] <Dark_Shikari> which is over TCP and thus crappier
[23:28:29] <CIA-92> ffmpeg: conrad * r22187 /trunk/libavformat/matroskaenc.c:
[23:28:29] <CIA-92> ffmpeg: matroskaenc: use "title" tag instead of "description" in track title.
[23:28:29] <CIA-92> ffmpeg: Patch by Anton Khirnov < whyskas at gmail >
[23:28:29] <CIA-92> ffmpeg: conrad * r22188 /trunk/libavcodec/vp3.c: Explictly separate decoding whether fragments are coded by plane
[23:28:31] <CIA-92> ffmpeg: conrad * r22189 /trunk/libavcodec/vp3.c:
[23:28:31] <CIA-92> ffmpeg: Do MC and IDCT in coding (hilbert) order
[23:28:31] <CIA-92> ffmpeg: This increases the slice size to 64 pixels, due to having to decode an
[23:28:31] <CIA-92> ffmpeg: entire chroma superblock row per slice.
[23:28:32] <CIA-92> ffmpeg: This can be up to 6% slower depending on clip and CPU, but is necessary
[23:28:32] <CIA-92> ffmpeg: for future optimizations that gain significantly more than was lost.
[23:28:33] <CIA-92> ffmpeg: conrad * r22190 /trunk/libavcodec/vp3.c:
[23:28:33] <CIA-92> ffmpeg: Delay translating DCT tokens into coefficients until immediately before IDCT
[23:28:34] <CIA-92> ffmpeg: This is generally around 12% faster than the prior method of creating a
[23:28:34] <CIA-92> ffmpeg: linked list for each block as tokens are read, but can be anywhere from
[23:28:35] <CIA-92> ffmpeg: 8% to 28% faster depending on file and CPU.
[23:29:15] <Dark_Shikari> Yuvi: anything else missing?
[23:29:29] <Dark_Shikari> to be merged
[23:29:37] <mru> lol, some idiot just posted a comment: "I did not finish your article ..."
[23:30:02] <Dark_Shikari> btw, x264 is probably going to get slashdotted in the next couple weeks
[23:30:08] <Dark_Shikari> we are about to announce the first open source blu-ray support
[23:30:15] <mru> :-)))
[23:30:24] <Yuvi> a few things, the only major one in terms of restructuring is MV handling
[23:30:43] <Dark_Shikari> our plan is to make a free blu-ray and give it out with the announcement for download
[23:30:49] <BBB> Dark_Shikari: decrypt support?
[23:30:53] <Dark_Shikari> BBB: encode
[23:30:56] <BBB> oh...
[23:30:59] <Dark_Shikari> Make your own Blu-rays.
[23:31:06] <BBB> who's working on decode/decrypt?
[23:31:08] <Dark_Shikari> No more paying $100,000 for Blu-code.
[23:31:11] <BBB> j-b?
[23:31:21] <Dark_Shikari> and no more http://www.lyris-lite.net/2010/girl_hornet.png
[23:31:22] <astrange> how do you create the system structure?
[23:31:24] <j-b> BBB: ?
[23:31:28] <Dark_Shikari> astrange: Well, that's an unsolved problem ;)
[23:31:32] <astrange> i think i figured out how to make a dvd with mencoder once
[23:31:34] <Dark_Shikari> But hopefully when encode is done for audio and video
[23:31:38] <Dark_Shikari> someone will make authoring tools
[23:31:45] <Dark_Shikari> since that will be the only thing left
[23:31:46] <BBB> j-b: is anyone working on BR decrypt?
[23:31:52] <mru> Dark_Shikari: wtf happened in that picture?
[23:31:54] <Yuvi> did that ever happen for DVDs?
[23:31:56] <Dark_Shikari> mru: awful encoder
[23:32:04] <j-b> BBB: you mean, like http://bd.videolan.org .?
[23:32:12] <thresh> 1080p, gif-style
[23:32:17] <mru> Dark_Shikari: I can tell, but what did it fuck up?
[23:32:26] <Dark_Shikari> I have no idea.
[23:32:27] <mru> qp varying like mad?
[23:32:33] <BBB> aha
[23:32:35] <BBB> j-b: thnks
[23:33:47] <j-b> BBB: wrappers for mplayer are there too
[23:34:03] <BBB> can we merge that and libdvdnav/css into ffmpeg?
[23:34:19] <j-b> no idea :D
[23:34:21] <j-b> you tell me
[23:34:27] <BBB> I say yes
[23:34:33] <BBB> too bad it's all GPL
[23:34:40] <BBB> well you can't have it all I guess
[23:34:48] <j-b> GPL is cool :D
[23:34:58] <astrange> find a good semantic mapping to avformatcontext and sure
[23:35:02] <j-b> BBB: libdvdnav should be fixed.
[23:35:10] <BBB> ?
[23:35:20] <j-b> BBB: and libbluray is quite early stage still
[23:35:27] <BBB> that much is clear
[23:35:29] <BBB> but it's cool :)
[23:36:06] <j-b> BBB: libbdnav should work
[23:36:21] <j-b> but libaacs is still, complex, and lacking keys
[23:36:24] <BBB> what do you mean dvdnav is broken byut bdnav should work?
[23:36:29] <BBB> and how similar are they?
[23:37:08] <j-b> different
[23:37:25] <j-b> I mean dvdnav is broken, because it doesn't handle correctly new DVDs
[23:37:40] <j-b> and bdnav should work in comparison to libaacs :)
[23:37:49] <j-b> not in comparison to libdvdnav
[23:39:11] <BBB> you should fix dvdnav then :)
[23:39:21] <BBB> anyway, interesting stuff you guys have
[23:39:23] <BBB> very interesting
[23:39:49] <j-b> we didn't do anything
[23:40:18] <j-b> last time I suggested patches for libdvdnav, I was more or less told to fuck off
[23:40:22] <j-b> which I did
[23:40:34] <BBB> see
[23:40:38] <BBB> that's why it should go into ffmpeg
[23:40:46] <BBB> at least we maintain stuff 10 years after
[23:51:28] <richardus> thank you mr. hardwarebug.org for your post, it was very good.
[23:51:55] <mru> my pleasure
[23:54:35] <Yuvi> is there a way to get make test print all the diffs in one run?
[23:54:50] <mru> make -k test
[23:55:07] <Yuvi> thanks