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

[irc at mansr.com]

[00:03:12] <CIA-92> ffmpeg: stefano * r24727 /trunk/libavfilter/defaults.c:
[00:03:13] <CIA-92> ffmpeg: Fix the size of the data to be copied from an AVFilterBuffer to an
[00:03:13] <CIA-92> ffmpeg: AVFilterBuffereRef in avfilter_default_get_video_buffer().
[00:03:13] <CIA-92> ffmpeg: The error was being caused by the previous patch which resized
[00:03:13] <CIA-92> ffmpeg: AVFilterBuffer's data and linesize arrays to 8.
[00:03:13] <CIA-92> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram" &smeenaks&ucsd&edu&.
[00:03:14] <CIA-92> ffmpeg: stefano * r24728 /trunk/ (4 files in 2 dirs):
[00:03:14] <CIA-92> ffmpeg: Move format from AVFilterBuffer to AVFilterPicRef.
[00:03:15] <CIA-92> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram |smeenaks|ucsd|edu|.
[00:20:50] <CIA-92> ffmpeg: stefano * r24729 /trunk/doc/APIchanges: Add APIchanges entry after r24728.
[00:22:10] <j0sh> lu_zero: any idea why rtsp doesn't receive RTCP packets other than 200s?
[01:16:17] <CIA-92> ffmpeg: stefano * r24730 /trunk/ (16 files in 2 dirs):
[01:16:17] <CIA-92> ffmpeg: Rename AVFilterPicRef to AVFilterBufferRef.
[01:16:17] <CIA-92> ffmpeg: The struct is going to be used for storing audio buffer references as
[01:16:17] <CIA-92> ffmpeg: well, and the new name is more generic.
[01:16:17] <CIA-92> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram @smeenaks at ucsd@edu at .
[01:16:18] <CIA-92> ffmpeg: stefano * r24731 /trunk/ (11 files in 2 dirs):
[01:16:19] <CIA-92> ffmpeg: Rename functions and fields:
[01:16:19] <CIA-92> ffmpeg: avfilter_(un)ref_pic -> avfilter_(un)ref_buffer
[01:16:20] <CIA-92> ffmpeg: avfilter_copy_picref_props -> avfilter_copy_buffer_ref_props
[01:16:20] <CIA-92> ffmpeg: AVFilterBufferRef.pic -> AVFilterBufferRef.buffer
[01:16:21] <CIA-92> ffmpeg: They have been renamed to allow sharing with audio.
[01:16:21] <CIA-92> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram $smeenaks$ucsd$edu$.
[01:16:22] <CIA-92> ffmpeg: stefano * r24732 /trunk/ (9 files in 2 dirs): (log message trimmed)
[01:16:23] <CIA-92> ffmpeg: Rename fields:
[01:16:23] <CIA-92> ffmpeg: AVFilterLink.srcpic -> AVFilterLink.src_buf
[01:16:24] <CIA-92> ffmpeg: AVFilterLink.cur_pic -> AVFilterLink.cur_buf
[01:25:32] <CIA-92> ffmpeg: stefano * r24733 /trunk/doc/APIchanges: Add APIchanges entries after the last recent libavfilter renames.
[01:37:24] <CIA-92> ffmpeg: stefano * r24734 /trunk/libavcodec/ (libdiracdec.c libopenjpeg.c libschroedingerdec.c):
[01:37:24] <CIA-92> ffmpeg: Fix the compilation of some libavcodec/lib* files which were not
[01:37:24] <CIA-92> ffmpeg: including libavcore/imgutils.h, which was required since the recent
[01:37:24] <CIA-92> ffmpeg: avcodec_check_dimensions() -> av_check_image_size() transition.
[01:38:36] <j0sh> lu_zero: wbs: hmm, looks like we don't actively try and get rtcp over udp
[01:47:04] <saintdev> peloverde: i love it already :)
[02:36:23] <saintdev> peloverde: the windows on screenshot in your blog, is that the sine window, or the kb window?
[08:08:44] <lu_zero> good morning
[08:12:05] <wbs> j0sh: hmm, yes, that seems to be the case...
[08:12:53] <wbs> j0sh: you can get to the rtcp file handle via rtp_get_file_handles, but that's scheduled for removal at the next major bump. I don't see any other way to get the rtcp file handle
[08:13:22] <wbs> j0sh: but once you have that, it shouldn't be too much work to listen for the rtcp file handle too in the same loop as listening for packets on the other udp sockets
[08:13:51] <wbs> j0sh: don't know what blocking requirements the comment in rtsp.c refers to, feels outdated imo
[08:13:55] <lu_zero> j0sh: what are you trying to do?
[08:14:41] <wbs> rtcp bye support, afaik
[08:16:19] <lu_zero> uhm
[08:21:04] <lu_zero>     if (buf[1] >= 200 && buf[1] <= 204) {
[08:21:04] <lu_zero>         rtcp_parse_packet(s, buf, len);
[08:21:04] <lu_zero>         return -1;
[08:21:04] <lu_zero>     }
[08:27:21] <wbs> yes, but in udp_read_packet, we only get the rtp udp socket's file handle and select for packets on that one, not the rtcp one
[08:27:29] <j0sh> yo
[08:28:28] <j0sh> in rtpproto.c, we supposedly check the rtcp fd when reading
[08:28:38] <wbs> yeah
[08:29:07] <wbs> but we wont read from it unless the select in udp_read_packet indicated a packet on the rtp port
[08:29:21] <wbs> so the rtcp bye packets will probably be missed
[08:29:43] <wbs> since we arent getting any more rtp data at that point
[08:30:46] <j0sh> hmmmm
[08:31:22] <j0sh> why is the rtp_get_file_handles function being removed anyway?
[08:31:34] <lu_zero> my idea of using a proper filler+queue is getting more and more stance
[08:32:03] <wbs> j0sh: BBB introduced a more generic function for getting a file handle
[08:32:08] <j0sh> http://archives.free.net.ph/message/20100301.202700.05295b2e.ca.html
[08:32:18] <wbs> too bad you can only get one handle using that one
[08:32:21] <j0sh> yeah
[08:33:05] <lu_zero> we can reinstate the old one if needed
[08:33:13] <wbs> true
[08:33:25] <lu_zero> or really implement the network thread =P
[08:34:10] <lu_zero> or make the rtpproto return on rtcp as well
[08:34:33] <wbs> rtpproto itself does return packets from rtcp
[08:34:56] <wbs> but since the reads are blocking, we read from them only once we know they've got something to return
[08:35:15] <wbs> and we only check the rtp port for that
[08:35:42] <lu_zero> ^^
[08:35:48] <j0sh> can we select() to see if they're ready?
[08:35:56] <j0sh> (or whatever the function is)
[08:36:20] <j0sh> im guessing portability is a concern here
[08:37:02] <j0sh> select() is apparently posix, but windows isn't
[08:37:08] <lu_zero> check the rtp proto
[08:37:25] <lu_zero> it correctly checks for rtcp and rtp
[08:40:16] <cartman> j0sh: instead of select you use WaitForSingleObject, WaitForMultibleObjects on windows
[08:41:00] <wbs> j0sh: we already do a select there
[08:41:07] <j0sh> aye, i noticed
[08:41:10] <wbs> we just don't include the rtcp sockets
[08:41:49] <wbs> so 1) reinstate the rtp_ function scheduled for removal, 2) use that instead of the generic url_get_file_handle, 3) add the rtcp sockets to the list of sockets select waits for
[08:42:45] <wbs> 4) use the rtp-specific get_file_handle when checking for which socket that triggered select, too
[08:42:48] <wbs> 5) profit
[08:42:58] <j0sh> excellent
[08:44:39] <lu_zero>         FD_SET(s->rtcp_fd, &rfds);
[08:44:47] <lu_zero> I'm missing something?
[08:44:56] <wbs> yes, read udp_read_packet in rtsp.c
[08:45:13] <wbs> since we have many rtp URLContexts, we first want to know which one to read
[08:45:17] <wbs> since reads on them are blocking
[08:46:35] <lu_zero> ahhh
[08:46:37] <lu_zero> right
[08:48:34] <lu_zero> right
[08:54:46] * lu_zero doesn't like what he sees
[09:01:29] <j0sh> no?
[09:28:49] <lu_zero> j0sh: we call a select and then another batch of select
[09:36:24] <KotH> moin
[09:37:23] <lu_zero> hi KotH
[09:41:10] <cartman> morning
[09:41:31] <j0sh> yeah, from rtcp and then again in rtpproto
[09:43:46] <j0sh> *rubs eyes* all my rtcp data is coming in as RTCP SR even though wireshark says otherwise
[09:43:59] <j0sh> i'm gonna get some sleep, will figure it out in the morning
[09:46:04] <j0sh> that also leads me to believe i was actually getting rtcp packets all along
[09:46:59] <wbs> yes, you may have got them, but you can't reliably get them
[09:47:36] <wbs> since if the rtp socket had a packet, rtpproto checked both rtcp and rtp, and returned the one from rtcp first
[09:47:54] <j0sh> right
[10:24:08] <mru> greetings from ARN
[10:27:51] <cartman> ARN?
[10:33:57] <mru> arlanda airport
[10:34:13] * mru found some free wifi
[10:34:23] <wbs> oh, they have such there now?
[10:34:49] <mru> mcdonalds does
[10:34:53] <wbs> ah, of course. :-)
[10:35:31] <spaam> mru: going home to your mother?:D
[10:36:13] <mru> I'm going to my mom's, wouldn't call it home
[10:45:32] <cartman> mom is good
[10:45:34] <cartman> home is better
[10:58:06] <kshishkov> cartman: I'd say it's definitely more drastic for me - I consider Sweden to be my homeland despite having no relatives or real estate there
[10:58:30] <cartman> kshishkov: anywhere but $HOME baby
[10:59:19] * kshishkov points out that his initials can be written as "kssh", and he set $HOME=Sweden there
[11:00:44] <cartman> lol
[11:17:04] <CIA-92> ffmpeg: mstorsjo * r24735 /trunk/ (8 files in 2 dirs):
[11:17:04] <CIA-92> ffmpeg: Add RTP packetization of Theora and Vorbis
[11:17:04] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[12:31:35] <CIA-92> ffmpeg: darkshikari * r24736 /trunk/libavcodec/h264_cavlc.c: H.264: 8% faster CAVLC zero-run decoding
[12:58:57] * Compn asks a dumb question
[12:59:04] <spaam> ok
[12:59:12] <Compn> did Dark_Shikari measure any actual speed up or just fewer cycles ?
[12:59:39] <Compn> because then it should say 8% fewer cycles ?
[13:03:41] <J_Darnley> Here comes another stupid question
[13:04:07] <J_Darnley> Aren't cycles time?
[13:22:31] <Compn> yes but there is a difference between time and cycles
[13:22:46] <Compn> you can shave off 10,000 cycles and it only amounts to 1 ms
[13:23:02] <Compn> so no, they arent the same
[13:23:41] <Compn> usually when a patch comes in thats xx% faster, its acommpanied by benchmarks
[13:23:45] <KotH> you can save off 10'000 cycles and your code could become 1ms slower
[13:23:55] <Compn> when its just cycles faster the author mentions passing reg tests
[13:24:06] <Compn> and this mail mentioned neither so i'm asking
[13:25:01] <Compn> yeah, thats why we try to have multiple tests , to make sure nothing breaks or slows down :)
[13:25:55] <Compn> J_Darnley : howd it go with the vuze guys? i didnt read all of it
[13:26:15] <J_Darnley> Over IRC I got a patch that I already had
[13:26:28] <J_Darnley> No repsonse but the auto-reply to my email
[13:26:45] <Compn> if you havent already, you could add that to the ffmpeg tracker , someone may find it useful
[13:26:50] <J_Darnley> I did
[13:26:53] <Compn> oh good
[13:26:58] <J_Darnley> wait
[13:27:03] <J_Darnley> what bit did you mean?
[13:27:10] <Compn> the downmixer patch ?
[13:27:36] <J_Darnley> That's probably already there somewhere
[13:27:43] <Compn> http://muzso.hu/dfiles/public/6to2channel-resample.patch
[13:29:12] <J_Darnley> I could attach my IRC log to the issue if people would find it useful
[13:30:25] <Compn> i dont think other issues have emails posted, maybe its too much info
[13:30:38] <Compn> and not an official stance, those guys werent the package maintainers anyways
[13:31:03] <Compn> anyways thanks for doing the extra work J_Darnley
[13:32:03] <J_Darnley> I know, that's why I've also sent en email through the vuze.com/corp website
[13:32:39] <Compn> you can see how much trouble it is to get answers from people distributing ffmpeg. multiply that by the 200-300 lgpl violations and you can see how many hours this takes.
[13:35:39] <J_Darnley> I wish they had been using a newer revision
[13:35:54] <J_Darnley> 12 commits later and they would have distibuting some of my code
[13:36:02] <wbs> :-)
[13:44:42] <kierank> they're using your code in x264, no?
[13:52:12] <J_Darnley> I'm not sure, I'll have to lookup what version they're using
[13:54:14] <J_Darnley> core 88
[13:55:56] <kierank> quite old then
[13:57:21] <J_Darnley> There was one commit to my name at that time but I only moved jason's code down a few lines
[14:12:32] <CIA-92> ffmpeg: siretart * r24737 /trunk/ (libavformat/rtsp.c libavcodec/alsdec.c): Fix spelling in comment(s)
[17:27:31] <xxthink> who has the dvd spec?
[17:27:33] <xxthink> or The Unofficial DVD Specifications Guide
[17:27:47] <kshishkov> DVD Consortium of something similar
[17:28:02] <peloverde> DVD Forum
[17:28:16] <kshishkov> DVD Gang
[17:29:24] <kierank> http://www.youtube.com/watch?v=EjH9cEoEup8
[17:30:04] <kshishkov> but I'm not sure if any of people I know has ever seen real DVD spec
[17:30:29] <xxthink> ok
[17:30:44] <xxthink> it is too difficult to find a copy of it freely
[17:31:00] <xxthink> I googled many days without result
[17:38:47] <kierank> if there's anything specific you want to know ask on doom9
[17:41:01] <peloverde> http://en.wikipedia.org/wiki/DVD_Forum
[17:48:54] <xxthink> ok
[17:48:58] <xxthink> I'll go to sleep
[17:49:05] <xxthink> it's 02:00 now
[17:49:23] <peloverde> it's 13:49 here
[17:49:34] <xxthink> :)
[17:49:35] <xxthink> bye
[17:50:44] <merbanan> strange with a 12 minute time zone
[17:53:55] <kshishkov> Venezuela has 30-minute offset though
[17:54:17] <kshishkov> and Russia has special 1-hour offset
[17:54:34] <kshishkov> must be something wrong with those Socialist/Communist countries
[17:58:00] <iive> i remember ugo chaves changing the timezone offset it a way to be most painful for usa. i would assume it include 15 minute offset.
[17:58:48] <janneg> india has 30min offsets too
[17:59:31] <kshishkov> hmm, indeed
[17:59:54] <elenril> what's the point? ForTheLulz?
[18:00:49] <iive> elenril: trade
[18:00:50] <kshishkov> Canada does that too
[18:01:05] <kshishkov> and Iran
[18:01:17] <iive> yes, the axes of evil.
[18:01:20] <kshishkov> Nepal uses UTC+5:45
[18:01:42] <kshishkov> and Aussies use +8:45
[18:01:58] <kshishkov> Kiwis +12:45
[18:02:28] <kshishkov> most reasonable guess is that they just adjust timezone to better correspond to their real location
[18:02:53] <kshishkov> or just to mess with foreighners' clocks
[18:08:02] <iive> most probably the second.
[18:08:52] <kshishkov> or like the case with Ukraine - "free and independent even from common sense"
[18:09:26] <elenril> at least it has a normal tz
[18:10:05] <kshishkov> unlike its northeast neighbour
[18:42:10] <kierank> http://andyjko.com/2010/07/13/mozilla-summit-2010-and-dev-culture/
[18:59:26] <DonDiego> salve
[18:59:41] <DonDiego> mru: i would like to make a feature request for fate:
[18:59:51] <DonDiego> it should run 'make checkheaders'
[19:00:01] <DonDiego> i asked mike to do that years ago, but ...
[19:05:55] <kshishkov> you can just create such test by yourself
[19:08:31] <spaam> but do you really need that everyone runs it ?
[19:24:46] <DonDiego> yes!
[19:24:50] <DonDiego> absolutely
[19:25:27] <DonDiego> kshishkov: probably, but i haven't looked into fate yet and i'm on vacation :)
[19:25:30] <kshishkov> make your own Fate with blackjack and hookers^W^W^W checkheaders and MPlayer
[19:25:42] <kshishkov> DonDiego: so is mru
[19:25:53] <DonDiego> also, if it's a oneliner, it's easier to just request it from the maintainer
[19:26:14] <DonDiego> kshishkov: isn't mru around karlsruhe right now?
[19:26:30] <kshishkov> he sent his greetings from Sweden today
[19:26:36] <kshishkov> he's on vacation
[19:29:38] <DonDiego> k
[19:30:16] * kshishkov would suspect that some of Diegos should be outside Italy too
[19:30:44] * DonDiego sends kshishkov a pizza from italy
[19:31:14] * kshishkov reminds DonDiego that his pizza eating habits haven't changed yet
[19:31:36] * DonDiego reminds kshishkov that this is completely irrational
[19:32:04] * kshishkov reminds DonDiego that this is totally in nature of men
[19:32:28] * DonDiego responds that the nature of hackers is not the nature of men
[19:33:32] * kshishkov checks his nature - is not nocturnal, does not drink coffee, does not eat pizza
[19:33:37] <kshishkov> yup, perfect hacker
[19:35:10] <peloverde> fixup_vorbis_headers() seems to depend on 3 packets being allocated... how does it attempt to know that that is the case?
[19:36:03] <kshishkov> probably it's obvious from specs
[19:36:16] <kshishkov> like there are two packets for theora headers
[19:37:32] <peloverde> ummm no... You can only depend on that being the case when dealing with wellformed streams
[19:41:07] <peloverde> If pkt_type equals 5 on the first call to vorbis_header() the whole thing seems to explode
[19:42:01] * kshishkov would like to say a pun on rotten ogg
[19:44:25] <peloverde> And why the hell can't vorbis use one singular header packet like any reasonable format?
[19:44:50] <kshishkov> because it was designed by Xiph^TM for Ogg^TM
[19:45:59] <kshishkov> think about it more like of LATM AAC in some container
[19:51:04] * cartman hands kshishkov  a â„¢
[19:51:57] * kshishkov is too lazy to paste most of the nonlatin characters
[19:52:08] * cartman pets his mac keyboard :P
[19:52:09] <cartman> handy
[19:52:28] * kshishkov has Mac keyboard next to him
[19:52:39] <cartman> ALT-2 produces TM sign here
[19:52:53] * kshishkov is on Linux now
[20:18:04] <bcoudurier> hi guys
[20:27:51] <Dark_Shikari> Compn: on my test clip I was testing on, zero run decoding was "only" about 1/4 to 1/3 of decoding time
[20:32:39] <kierank> bcoudurier: do you know a simple way to demux 302m audio?
[20:33:33] <bcoudurier> from TS ?
[20:34:04] <kierank> yes
[20:34:28] <bcoudurier> yes, just add 'bssd' to the registration desc array in mpegts.c
[20:35:20] <kierank> but what about the 302m syntax elements?
[20:36:15] <bcoudurier> ah, well I don't know any simple way :/
[20:37:55] <bcoudurier> the 16 and 24 cases are painful
[20:38:45] <kierank> there's a 20-bit case iirc as well
[20:40:15] <bcoudurier> the 20 bit case is easier IIRC
[20:40:18] <bcoudurier> because 20+4
[20:41:38] <bcoudurier> maybe get_bits is easier, but I used byte reading and shuffling last time
[20:41:55] <saintd3v> peloverde: the screenshot for aacx on your blog are those sine windows?
[20:42:27] <bcoudurier> they go in pairs, so there are 3 case, 5,6,7 bytes
[20:42:40] <peloverde> The file was created by ffmpeg so ti was whatever we use by default
[20:42:59] <peloverde> but i really should stick it in the status bar or somewhere else visible
[20:43:05] <kierank> " but I used byte reading and shuffling last time" --> yes that is what vlc does.
[20:43:12] <kierank> except their demux doesn't seem to work
[20:43:20] <kierank> playback works I think
[20:45:05] <bcoudurier> lpcm playback works yes
[20:45:17] <saintd3v> peloverde: yeah, you can tell easily the different shapes, but i don't know which shape is which
[20:45:31] <DonDiego> bcoudurier: bonjour :)
[20:45:41] <saintd3v> interestingly, itunes solely uses the opposite window type that we do
[20:45:55] <saintd3v> and nero uses the same as us for long blocks, but the other type for short blocks
[20:45:59] <bcoudurier> hey DonDiego, how are you ?
[20:46:47] <peloverde> saintd3v: that is a kbd window
[20:47:09] <saintd3v> on your blog?
[20:47:19] <peloverde> yes
[20:48:29] <bcoudurier> kierank, maybe there is a "reverse" situation that is different in your situation
[20:49:02] <saintd3v> i wonder if there is some benefit to using sine windows for short blocks?
[20:49:31] <saintd3v> guess i'll have to try that
[20:50:52] <saintd3v> peloverde: i checked with aacx, and with lame attack detection on castanets we get attacks right down to the sub-block (1/3 of a short block)
[20:51:49] <peloverde> The latest update shows window grouping with color
[20:52:20] <saintd3v> but there are a few cases where there are 2 attacks in a frame, and we miss the second one because of grouping
[20:52:52] <saintd3v> attack detection still sees it. the groupings just need adjusted.
[20:52:57] <peloverde> Assuming the two attacks are comparable the second one shouldn't matter
[20:53:24] <saintd3v> like 2 castanet hits one at the start of the frame, and one near the end?
[20:53:58] <saintd3v> the first is grouped by itself, the second is grouped with the two blocks preceding it.
[20:54:04] <peloverde> yeah, can you hear a noticeable preecho on the second one, it should be mostly masked by the first
[20:55:06] <saintd3v> i can _see_ the pre-echo, does that count?
[20:55:10] <peloverde> no
[20:55:28] <saintd3v> haven't done too much listening tests, other than to make sure it's not totally screwed up
[20:55:38] <saintd3v> also itunes grouping detection is _stellar_
[20:56:10] <saintd3v> afaikt they do grouping decision along with their analysis
[20:56:58] <Dark_Shikari> Q: why is this hard?  i.e. what's hard about doing grouping analysis
[20:57:06] <peloverde> forward temporal masking is much stronger than backwards temporal masking
[20:57:14] <Dark_Shikari> for that matter, what is "grouping"?
[20:57:15] <saintd3v> Dark_Shikari: didn't say it was
[20:57:27] <Dark_Shikari> (specifically)
[20:58:04] <saintd3v> short sequences (8 short blocks) can be grouped into a number of groups
[20:58:11] <saintd3v> each group has the same scalefactor
[20:58:13] <Dark_Shikari> how so
[20:58:20] <Dark_Shikari> like, in what ways can they be grouped
[20:58:23] <Dark_Shikari> and what benefits does it get?
[20:58:31] <Dark_Shikari> just saving bits on one scalefactor?
[20:58:55] <peloverde> saves bits on scale factors and on sectioning
[20:59:19] <Dark_Shikari> what are the possible groupings?
[20:59:41] <peloverde> whatever you want
[20:59:43] <saintd3v> 1 block per group to 8 blocks per group
[20:59:58] <peloverde> 2^7
[20:59:59] <saintd3v> they have to be sequential, afaik
[21:00:03] <peloverde> yes
[21:00:43] <saintd3v> Dark_Shikari: we can do it with our current attack detection, but itunes just keeps amazing me with how much they put into it
[21:00:49] <Dark_Shikari> OK, you want viterbi for this
[21:00:54] <Dark_Shikari> viterbi can get this optimally, pretty fast
[21:01:26] <peloverde> what would you make the cost function?
[21:01:34] <Dark_Shikari> ok, here's how I'd do it (let me think for a moment)
[21:01:45] <Dark_Shikari> wait, cost function?  you don't have one?
[21:01:52] <Dark_Shikari> ...
[21:01:53] <peloverde> note that testing any particular grouping is very expensive
[21:01:58] <Dark_Shikari> how can you have an encoder without a cost function?
[21:02:08] <Dark_Shikari> an encoder for anything?
[21:02:38] <Dark_Shikari> anyways, here's how I'd do it... I *think* this is optimal
[21:02:49] <Dark_Shikari> 1) calculate the cost of the first of the 8
[21:03:07] <Dark_Shikari> 2) calculate two possibilities: first and second grouped, first and second ungrouped
[21:03:15] <Dark_Shikari> at each step, we will keep track of two states
[21:03:24] <Dark_Shikari> A) the best state where CURRENT is grouped with PREVIOUS
[21:03:31] <Dark_Shikari> B) the best state where CURRENT is not grouped with PREVIOUS
[21:03:43] <peloverde> That would make the encode 8x slower
[21:03:48] <Dark_Shikari> so we have two states now, [1][2] and [12]
[21:03:51] <Dark_Shikari> now, we try 3
[21:04:11] <peloverde> I see what you are saying, that's very slow
[21:04:12] <Dark_Shikari> thus we test [1][2][3] and [123] and [12][3]
[21:04:16] <Dark_Shikari> we can eliminate one of those
[21:04:21] <saintd3v> peloverde: i think it's a good idea, maybe for later, though
[21:04:27] <Dark_Shikari> peloverde: why does it make things 8 times slower?
[21:04:35] <Dark_Shikari> You don't have to do full analysis for every single one
[21:04:47] <Dark_Shikari> you just have to do enough analysis to get a vague idea of what is better
[21:04:52] <Dark_Shikari> x264 does this type of thing for bframe decision
[21:05:01] <Dark_Shikari> it's not horribly slow, because it does about 50x less work than a normal encode on each comparison
[21:05:22] <saintd3v> but x264 also has fast bframe decision ;)
[21:05:31] <Dark_Shikari> Thus -- the output of each step of the process is two possible states
[21:05:42] <Dark_Shikari> and at each step, you analyze up to three possibilities, and throw out one of them.
[21:05:48] <Dark_Shikari> the three possibilities are:
[21:05:53] <Dark_Shikari> 1) End the grouping, single-group the next one.
[21:06:05] <Dark_Shikari> 2) Continue the grouping
[21:06:15] <Dark_Shikari> oh wait, I guess that should be 4 not 3
[21:06:19] <peloverde> and where do we get the "vague idea of what is better"?
[21:06:24] <Dark_Shikari> you need to do the same two options to continue the second state, too
[21:06:36] <saintd3v> maybe viterbi is how itunes does it
[21:06:52] <Dark_Shikari> peloverde: are groupings per-band?
[21:06:56] <peloverde> no
[21:07:17] <saintd3v> because _any_ block that has mostly different dct coefficients starts a new group
[21:07:25] <Compn> Dark_Shikari : i dont know what zero run means but ok :P
[21:07:33] <saintd3v> even if it's a non-attack short sequence o.O
[21:07:34] <CIA-92> ffmpeg: stefano * r24738 /trunk/doc/indevs.texi: Fix VfW spelling.
[21:07:34] <CIA-92> ffmpeg: stefano * r24739 /trunk/doc/protocols.texi: Apply misc docs fixes spotted by Diego.
[21:07:44] <Dark_Shikari> peloverde: ok, so the purpose of groupings is to limit bits spent on scalefactors
[21:07:48] <Dark_Shikari> by sharing scalefactors between similar bands?
[21:07:50] <Dark_Shikari> er,
[21:07:55] <peloverde> and codebooks
[21:08:00] <Dark_Shikari> between similar transforms
[21:08:03] <Dark_Shikari> in the 8 short
[21:08:18] <Dark_Shikari> ok, so here's one example
[21:08:26] <Dark_Shikari> How fast can you find scalefactors for a band?
[21:08:27] <peloverde> All scalefactors and HCBs are identical in windows of the same grouping
[21:08:29] <Dark_Shikari> Like, how shittily and awfully
[21:08:40] <Dark_Shikari> What's the fastest algorithm you can come up with besides just not trying at all
[21:08:43] <Dark_Shikari> and how does it compare to the current?
[21:09:05] <Dark_Shikari> same with codebooks
[21:09:28] <Dark_Shikari> part of encoding is coming up with fast approximations for the purpose of mode decision, and then using a better algorithm later.
[21:09:52] <saintd3v> Dark_Shikari: how about we do this later once i understand more of the layout of the enocder :P
[21:10:23] <saintd3v> unless you want to write it. i know about ||<--this much
[21:10:28] <peloverde> A fast approximation for scalefactors is setting everything to use HCB1 and calculating appropriate scalefactors for that
[21:10:56] <peloverde> But I still don't see why I'm wasting time discussing eliminating an artifact that hasn't even been demonstrated to be audible
[21:11:12] <peloverde> especially when we still have so many clearly audible artifacts
[21:11:20] <saintd3v> peloverde: agreed
[21:11:45] <peloverde> ...except shitty grouping does fuck up the TLS
[21:11:56] <Dark_Shikari> peloverde: "eliminating an artifact"?
[21:12:06] <Dark_Shikari> perhaps we care about compression here too?
[21:12:41] <saintd3v> we can add this later, i think it's a great idea, but let's focus on getting rid of the crappy 3gpp windowing for now
[21:13:31] <saintd3v> and by crappy i mean; fails more often than it is correct.
[21:14:02] <Dark_Shikari> heh.
[21:14:32] <peloverde> The problem isn't 3GPP
[21:14:41] <peloverde> or most of it isn't
[21:14:47] <saintd3v> well, it's probably the implementation
[21:14:51] <peloverde> yes
[21:14:53] <saintd3v> either way, it's broken
[21:14:56] <peloverde> true
[21:15:22] <peloverde> lame attack decision is actually very close to 3GPP
[21:16:03] <saintd3v> well i got to get back to work
[21:17:10] <peloverde> "An attack is detected if one of these subblock energies exceeds a *sliding average* of the previous energies by a constant factor attackRatio and is greater than a constant energy level minAttackNrg = 1e-3."
[21:17:46] <peloverde> The "sliding average" is underspecified in 3GPP and what we use is completely inappropriate
[21:31:45] <CIA-92> ffmpeg: alexc * r24740 /trunk/libavformat/oggparsevorbis.c: oggparsevorbis: Add some sanity checks to header packet ordering/presence.
[22:16:12] <spaam> nice with base64 encoded patch
[22:16:40] <Dark_Shikari> lol
[22:17:40] <J_Darnley> He is right about the rules
[22:45:36] <peloverde> perhaps it is time to update the rules?
[23:11:20] <CIA-92> ffmpeg: darkshikari * r24741 /trunk/ (5 files in 4 dirs):
[23:11:20] <CIA-92> ffmpeg: Split h264dsp and h264pred in configure.
[23:11:20] <CIA-92> ffmpeg: Many H.264 derivatives, like RV40 and VP8, use the H.264 prediction functions
[23:11:20] <CIA-92> ffmpeg: but not the weight/loopfilter functions.
[23:11:20] <CIA-92> ffmpeg: This should reduce the size of builds with one of these derivatives but without
[23:11:21] <CIA-92> ffmpeg: H.264 decoding itself.