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

[irc at mansr.com]

[00:43:18] <CIA-92> ffmpeg: michael * r22517 /trunk/libavcodec/error_resilience.c: Ensure that the deblock filter accesses the correct MVs for h264.
[01:33:32] <CIA-92> ffmpeg: stefano * r22518 /trunk/libavutil/error.h: Lexically sort the error code definitions.
[01:33:33] <CIA-92> ffmpeg: stefano * r22519 /trunk/libavutil/error.h:
[01:33:34] <CIA-92> ffmpeg: Mark AVERROR_ENOENT for deletion at the next libavutil major bump.
[01:33:34] <CIA-92> ffmpeg: The symbol is currently unused, AVERROR(ENOENT) must be used instead.
[01:53:19] <CIA-92> ffmpeg: michael * r22520 /trunk/ (3 files in 3 dirs): Make sure all mvs of a mb are set in the error concealment code.
[04:06:31] <Dark_Shikari> static (*func)( int16_t *, uint32_t ) x264_cache_mv_func_table[12]
[04:06:33] <Dark_Shikari> why doesn't this work?
[04:06:36] <Dark_Shikari> (an array of function pointers)
[04:18:01] <mru> static void (*func[12])(int, ...);
[04:19:37] <Dark_Shikari> windows file locking is blegh
[04:19:46] <Dark_Shikari> lol, accidentally hit "up" in the wrong window
[04:19:47] <Dark_Shikari> I hate that
[04:20:05] <Dark_Shikari> mru: works great.  thanks
[10:35:17] <astrange> can i get git svn dcommit to work from a git.ffmpeg.org clone?
[10:35:38] <kshishkov> try it
[10:35:42] <KotH> hmm.. i think so
[10:35:49] <KotH> at least mru uses git to commit to svn
[10:35:53] <KotH> dunno how though
[10:36:26] * kshishkov prefers direct approach with minimum intermediate abstraction levels
[10:37:20] <astrange> copying and applying multiple patches seems more error prone than one dcommit
[10:38:06] * KotH preferes not to commit anything
[10:38:11] <KotH> less mistakes this way ;)
[10:38:47] <kshishkov> yes, Russian proverb is "one who does not do anything does not do mistakes either"
[10:41:49] * KotH notes that he could be a good russian, if he'd drink vodka 
[10:45:11] <kshishkov> indeed, not that it's something to be proud about though IMO
[10:46:18] <Yuvi> pretty sure it's impossible to set up git-svn with git.ffmpeg.org's repo
[10:47:07] <Yuvi> mru uses a different repo that has the right urls in commit messages, I forget how I set it up to get dcommit to work from that
[13:39:02] <CIA-92> ffmpeg: reimar * r22521 /trunk/libavformat/avidec.c:
[13:39:02] <CIA-92> ffmpeg: Avoid creating tiny (possibly only 64 bytes large) audio packets resulting in
[13:39:02] <CIA-92> ffmpeg: huge processing and memory usage overhead for avi files with raw PCM audio.
[17:46:31] <ramiro> any tips I should follow when REing a DLL written in c++? like in how do I reconstruct a proper class?
[17:47:46] <mru> it's usually pretty obvious
[17:47:52] <mru> which compiler?
[17:48:01] <ramiro> msvc++
[17:48:08] <ramiro> or so that's what IDA says
[17:48:26] <mru> ecx contains the this pointer
[17:48:42] <mru> first field it points to is the vtable for the class
[17:48:56] <mru> data fields follow
[17:49:41] <mru> if you find a constructor you can usualy figure out at least an outline of the class
[17:51:58] <kshishkov> and demangling names also gives a lot of useful information
[17:52:40] <ramiro> the dll has very few symbols
[17:52:54] <kshishkov> what's its name?
[17:55:23] <kshishkov> in most cases I don't even bother about class structure
[17:56:48] <kshishkov> RV for example had nothing very useful in constructors
[17:58:24] <kshishkov> mru: found an example of very good thinking - my netbook had Ethernet NIC MAC printed on sticker. The catch is that sticker is placed on HDD connector so I found it only after full disassembly
[17:58:55] <mru> nice
[17:59:18] <kshishkov> and there was one case where I'd like to know it without powering that netbook
[18:00:20] <ramiro> does it void warranty as well?
[18:00:28] <kshishkov> screw warranty
[18:00:36] <ramiro> kind of like dogbert's help desk... the serial number is conveniently placed inside the unit.
[18:01:05] <kshishkov> I had to took it to warranty repair because of HDD read failure - they did nothing except disconnecting touchpad
[18:01:33] <kshishkov> and now it just does not take DC input
[18:41:52] <mfg> Is there something wrong with my resubmission of the probe loop patch?  Last time it was checked it shortly after the review.
[18:42:17] <kshishkov> better ping
[18:42:31] <mfg> ?
[18:42:59] <kshishkov> if there was no reaction on it for a week you just send reminder
[18:43:09] <mfg> i did.  there was no response to that either.
[18:44:17] <kshishkov> try again then, there should be some response after second or third ping for sure
[18:44:46] <mfg> ok
[18:49:46] <saste> mfg: I'll reapply it again later
[18:50:01] <saste> then we'll see if it will break fate again ;-)
[18:50:08] <mfg> lol
[18:50:19] <mfg> I wish I could run the full regression at home
[18:50:33] <mfg> at least on my native arch
[18:50:46] <kshishkov> mfg: yes, complaining on IRC also helps sometimes
[18:51:12] <mfg> hey! I wasn't complaining ;)  I was "reminding"
[18:51:21] <mfg> :)
[18:51:33] <saste> I thought about the same... maybe the fate guys can say if that's possible
[18:51:41] <saste> I didn't played much with fate yet...
[18:54:08] <twnqx> 2-3 days
[18:54:40] <elenril> about complaining on irc, somebody can apply a patch for me? ;)
[18:55:04] <kshishkov> it's not December yet ;)
[18:55:08] <mfg> lol
[18:56:27] <elenril> that's it, no delicious cake for kshishkov
[18:56:44] <kshishkov> it''s alie anyway
[18:57:11] <elenril> 'cake is a lie' is a lie
[18:57:42] <kshishkov> I'm glad
[18:58:02] <kshishkov> and I can manage without cake anyway
[18:58:43] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/SourGrapesTropes
[19:19:39] <mru> BBB: about those plots you were doing
[19:19:48] <BBB> hi, sorry I left
[19:19:54] <mru> I was asking you to do a single plot of in/out
[19:20:06] <BBB> in the same graph?
[19:20:06] <mru> err, out/in
[19:20:13] <BBB> or out divided-by in
[19:20:15] <mru> yes
[19:20:17] <mru> divide
[19:20:24] <mru> and log(out/in) too
[19:20:25] <BBB> frequencies
[19:20:32] <BBB> right?
[19:20:35] <mru> frequency on horizontal axis, yes
[19:20:50] <mru> that's how a frequency response graph is usually done
[19:21:26] * BBB goes check how to do that
[19:26:07] <BBB> working on it
[19:26:11] <CIA-92> ffmpeg: mru * r22522 /trunk/ (12 files in 3 dirs):
[19:26:11] <CIA-92> ffmpeg: Separate DWT from snow and dsputil
[19:26:11] <CIA-92> ffmpeg: This moves the DWT functions from snow.c and dsputil.c to a file of
[19:26:11] <CIA-92> ffmpeg: their own. A new struct, DWTContext, holds the function pointers
[19:26:11] <CIA-92> ffmpeg: previously part of DSPContext.
[19:26:12] <CIA-92> ffmpeg: mru * r22523 /trunk/libavcodec/ (dwt.h snow.c dwt.c): Add ff_ prefix to dwt functions
[19:28:48] <CIA-92> ffmpeg: reimar * r22524 /trunk/libavcodec/ (tableprint.c tableprint.h): Add some more table-printing functions needed for future patches.
[19:29:57] <BBB> you want after/before, not after-before?
[19:30:06] <mru> yes
[19:30:08] <BBB> 25/15 and -25/-15 will both give the same number
[19:30:09] <BBB> not very informative
[19:30:24] <mru> that's exactly what you want
[19:30:42] <mru> it's a scaling
[19:31:17] <CIA-92> ffmpeg: reimar * r22525 /trunk/libavcodec/ (qdm2.c qdm2_tablegen.c qdm2_tablegen.h Makefile): Allow hard-coding several QDM2 tables (about 32 kB size).
[19:31:34] <BBB> http://people.gnome.org/~rbultje/beforeafter.png
[19:31:46] <BBB> you shouldn't need a log(), but let me know if you want it anyway
[19:32:12] <BBB> unless you meant log(x-axis)
[19:33:54] <BBB> my impression is that much more than a bandpassfilter, it's simply a filter that strengthens the high-amplitude?dB output and weakens the low-dB-output
[19:34:09] <BBB> we already concluded it wasn't a simple bandpassfilter, I think
[19:35:22] <mru> uh, what's that a plot of?
[19:37:29] <BBB>  output frequencies / input frequencies
[19:37:33] <BBB> X-axis is frequencies
[19:37:38] <BBB> output is dBout/dBin
[19:37:40] <BBB> Y-axis
[19:38:30] <BBB> I forgot to label the X-axis I guess
[19:42:02] <mru> that's not what I said
[19:42:11] <mru> you plotted log(out)/log(in)
[19:42:24] <mru> I want out/in and log(out/in)
[19:42:36] <mru> the latter is of course log(out)-log(in)
[19:43:30] <mru> http://en.wikipedia.org/wiki/Bode_plot
[19:43:46] <BBB> oh
[19:43:50] <BBB> oops
[19:43:51] <BBB> let me try again
[19:43:57] <BBB> I didn't know input was log() already
[19:44:18] <mru> dB means 10*log10(x)
[19:45:05] <peloverde> or 20*log10 dependi g on conext
[19:45:11] * mru thinks BBB needs to study some signals and systems
[19:45:19] <mru> peloverde: yes, power vs energy
[19:48:02] <BBB> sorry :(
[19:48:22] <BBB> 1.93654E-26	4.54841E-20	4.25762E-07	-6.370833
[19:48:24] <BBB> oops
[19:48:29] <BBB> http://people.gnome.org/~rbultje/logbeforeafter.png
[19:48:31] <BBB> wrong copypaste
[19:49:10] <CIA-92> ffmpeg: mru * r22526 /trunk/ (Makefile common.mak): Fix brief make output for generated tables
[19:49:17] <mru> now you can clearly see some lowpass characteristics
[19:49:21] <mru> but it's quite erratic
[19:50:13] <BBB> if you look here: http://people.gnome.org/~rbultje/lowpassfilter.png
[19:50:43] <BBB> you see that the filter ("removing") strength correlates with dBs
[19:51:05] <BBB> so the filter simply weakens weak frequencies
[19:51:58] <mru> why can't you get that resolution in the other plot?
[19:52:08] <mru> it had only a couple dozen data points
[19:52:54] <BBB> uh, audacity pretties up the graph, that's all
[19:53:08] <BBB> the excel graph is with the data given to me by audacity
[19:53:40] <mru> audacity is crap
[19:54:02] <mru> are you saying it invents hundreds of data points?
[19:54:16] <BBB> ?
[19:54:25] <BBB> which one has more data points according to you?
[19:54:35] <mru> the double-screenshot one
[19:54:46] <BBB> it's the same data, interpolated using a hanning window
[19:54:52] <BBB> see the button on the bototm left
[19:55:00] <BBB> if you change it, the shape of the data points changes
[19:55:05] <BBB> I can make it rectangular
[19:55:10] <BBB> then it looks equally crappy
[19:55:48] <BBB> or maybe it actually does a wider bit radix, and the 512 setting only applies to the exported data
[19:56:13] <BBB> no, 512 is the input
[19:57:35] <mru> you can't have 7kHz components in 512 samples
[19:57:42] <mru> err
[19:57:55] <BBB> 1<<bit_radix=512
[19:57:59] <mru> what exactly is the x axis there anyway?
[19:58:11] <mru> is that taking sampling rate into accout?
[19:58:14] <mru> +n
[19:59:06] <ramiro> what the hell is a _purecall?
[19:59:18] <BBB> sorry, new one with actual frequencies, I again didn't label the X-axis
[19:59:25] <mru> ramiro: one the many calling conventions on mswindows
[20:00:43] <CIA-92> ffmpeg: reimar * r22527 /trunk/libavcodec/ (aac.c cbrt_tablegen.c Makefile cbrt_tablegen.h): Allow hard-coding of the 32kB cubic-root table for AAC.
[20:00:48] <Dark_Shikari> purecall? wtf is that
[20:01:08] <mru> probably something C++ related
[20:01:29] <ramiro> I get: .rdata:10108970 off_10108970    dd offset _purecall
[20:01:47] <ramiro> on that offset there is: .text:100E8D7C                 jmp     ds:__imp__purecall
[20:02:10] <ramiro> which is an extrn
[20:02:15] <mru> ah, that's what traps calls to virtual functions with no implementation
[20:02:27] <mru> and throws a nasty exception and dies
[20:03:35] <ramiro> ah, I remember seeing something like that back when I used some c++...
[20:05:28] <mru> you learn a lot through RE work
[20:11:10] <ramiro> __userpurge?
[20:12:41] * BBB has to leave again
[20:13:04] <BBB> thanks for the help so far :) sorry I'm a little absent today/yesterday
[21:17:19] <CIA-92> ffmpeg: stefano * r22528 /trunk/libavutil/error.h:
[21:17:19] <CIA-92> ffmpeg: Change the definition of AVERROR_NUMEXPECTED at the next libavutil
[21:17:19] <CIA-92> ffmpeg: major bump, using an FFmpeg specific error code rather than EDOM,
[21:17:19] <CIA-92> ffmpeg: which has a quite different semantics.
[22:26:23] <CIA-92> ffmpeg: mru * r22529 /trunk/libavutil/error.h: Add missing includes to libavutil/error.h
[22:26:23] <CIA-92> ffmpeg: mru * r22530 /trunk/libavutil/error.h:
[22:26:23] <CIA-92> ffmpeg: error.h: test EDOM instead of EINVAL
[22:26:23] <CIA-92> ffmpeg: C99 doesn't require EINVAL, only EDOM, EILSEQ, and ERANGE.
[22:30:03] <CIA-92> ffmpeg: mru * r22531 /trunk/libavcodec/dwt.c:
[22:30:03] <CIA-92> ffmpeg: DWT: x86 init should depend on HAVE_MMX
[22:30:03] <CIA-92> ffmpeg: The init function is only compiled if MMX is enabled, the call
[22:30:03] <CIA-92> ffmpeg: must use the same condition.
[22:41:17] <CIA-92> ffmpeg: stefano * r22532 /trunk/libavformat/ (utils.c internal.h): (log message trimmed)
[22:41:17] <CIA-92> ffmpeg: Move the probe loop from av_open_input_file() into its own method
[22:41:17] <CIA-92> ffmpeg: av_probe_input_buffer() so that it can be reused. Here are a few
[22:41:17] <CIA-92> ffmpeg: differences to the original way things were probed:
[22:41:17] <CIA-92> ffmpeg: - maximum probe buffer size can be specified as a parameter.
[22:41:18] <CIA-92> ffmpeg: - offset within the stream to probe from can be specified as a parameter.
[22:41:19] <CIA-92> ffmpeg: - instead of seeking back to the start each time a probe fails, stream
[23:53:38] <CIA-92> ffmpeg: cehoyos * r22533 /trunk/libavcodec/vdpau.c: Cosmetics: Fix a comment.