[Ffmpeg-devel-irc] ffmpeg-devel.log.20120826

[burek]

[02:00] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r0c3a3b75d7 10ffmpeg/libavformat/ac3dec.c: 
[02:00] <CIA-56> ffmpeg: ac3_probe: fix probing of non standard AC3
[02:00] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:42] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * raa7a565101 10ffmpeg/libavcodec/cllc.c: 
[02:42] <CIA-56> ffmpeg: cllc: Pad swapped buffer
[02:42] <CIA-56> ffmpeg: The bitstream buffer must be padded, or the bitstream reader might
[02:42] <CIA-56> ffmpeg: read over the end.
[02:42] <CIA-56> ffmpeg: Fixes the following valgrind warning:
[02:42] <CIA-56> ffmpeg:  Use of uninitialised value of size 8 at 0x591BAE: cllc_decode_frame (cllc.c:166)
[02:42] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[02:42] <CIA-56> ffmpeg: 03Mans Rullgard 07master * rdb70730291 10ffmpeg/libavcodec/x86/fft_mmx.asm: 
[02:42] <CIA-56> ffmpeg: x86: fft: remove unused fft_dispatch* functions
[02:42] <CIA-56> ffmpeg: These functions are not used since the yasm conversion.
[02:42] <CIA-56> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:42] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * refab2e004a 10ffmpeg/tests/ (fate/lossless-video.mak ref/fate/cllc-argb ref/fate/cllc-rgb): 
[02:42] <CIA-56> ffmpeg: FATE: Add Canopus Lossless tests
[02:42] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[02:42] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rc684cb29bc 10ffmpeg/: (log message trimmed)
[02:42] <CIA-56> ffmpeg: Merge remote-tracking branch 'qatar/master'
[05:00] <Daemon404> michaelni, http://pastebin.com/raw.php?i=9tNgW27U <-- is this at all useful to you? (collect over cama2_vtc_b.avc)
[05:02] Action: Daemon404 is going to rerun on ffmpeg
[05:11] <michaelni> Daemon404, thx, surely could be usefull
[05:11] <Daemon404> randomly decided to grab a trial of intels inspector thingy
[05:21] <Daemon404> michaelni, http://pastebin.com/raw.php?i=CigX6T9X ffmpeg run
[05:22] <Daemon404> ive kept the data dirs around to probe more if need be
[05:25] <michaelni> Daemon404, thx
[05:27] <Compn> data race eh
[05:30] <michaelni> there sure are data races in there, i expect many of the found things to be false positives though
[05:30] <michaelni> P3 for example looks like a false positive
[05:31] <Daemon404> well it's an automated tool
[05:31] <Daemon404> i expect for some falses
[05:32] <Daemon404> i should do an entire fate run and shove it somewhere, maybe.
[05:35] <michaelni> you should setup a fate client running it daily :)
[05:35] <Daemon404> well its a 30 day trial, and it costs like $900 USD
[05:35] <Daemon404> if only i still was interning at intel... ;)
[05:36] <michaelni> how does it know its 30 days are over ?
[05:36] <Compnn> i'm sure if someone emails the last @intel.com we'll get some free server time
[05:36] <Daemon404> michaelni, probably a call home
[05:36] <Daemon404> + eval license
[05:36] <Compnn> companies love ffmpeg :)
[05:36] <Daemon404> also before anyone says
[05:36] <Daemon404> i checked
[05:36] <Daemon404> no crack, so no ARRR MATEY
[05:37] <Compnn> why not just email intel ?
[05:37] <michaelni> Compnn, is right its probably relatively easy to get a free license
[05:37] <Compnn> i bet j-b knows some intel people
[05:38] <michaelni> but its no fun
[05:38] <Compnn> :P
[05:38] <michaelni> bypassing the 30day limit is cooler
[05:38] <michaelni> does it work when it cant call home ?
[05:38] <Compnn> that was the thing to do , back then, crack your own trialware
[05:39] <Daemon404> yes...
[05:39] <Daemon404> i mostly just changed a jmp to skip nag screens
[05:39] <Daemon404> in ollydbg
[05:39] <Daemon404> michaelni, dunno... i can kill networking in the vm of course
[05:39] <Daemon404> <_<
[05:40] <Daemon404> i do know i had to disable selinux during install
[05:41] <michaelni> selinux incomp could be unrelated to trial stuff but just for some of its actual featrues to work
[05:41] <Daemon404> i generally disable it anyway
[05:41] <Daemon404> it just gets in the way for me
[05:42] <michaelni> anyway isnt really important, i think i know someone @intel and could try asking for a free license if you want
[05:42] <Daemon404> depends if its actually useful :
[05:42] <Daemon404> :P
[05:42] <Compnn> static code analysers are always useful
[05:42] <Compnn> we can find out which company wastes time on it ! :P
[05:42] <Compnn> ehe
[05:43] <Compnn> hows coverity going michaelni ?
[05:43] <Daemon404> speaking of which
[05:43] <Daemon404> does ffmpeg have an asan box?
[05:43] <michaelni> Compnn, dunno
[05:43] <michaelni> Daemon404, yes
[05:43] <Daemon404> ah.
[05:52] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rbfb39023b0 10ffmpeg/libavcodec/ (cabac.c cabac.h h264.c): 
[05:52] <CIA-56> ffmpeg: h264: ff_init_cabac_states doesnt use its argument thus remove it
[05:52] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[09:09] <xxthink> hello, why the latest ffmpeg doesn't support libfaad decoding?
[09:13] <xxthink> I want to use ffmpeg to decode an aac stream
[09:13] <xxthink> it always says:  SSR not implemented.
[09:14] <xxthink> are there some patchs to decode this kind of aac stream?
[12:45] <Compnn> 2010-06-20	Måns Rullgård	Remove libfaad wrapper
[12:45] <Compnn> Remove libfaad wrapper
[12:46] <Compnn> been a while since it was removed
[12:46] <durandal_1707> oh, so you want that reverted?
[12:53] <CIA-56> ffmpeg: 03Paul B Mahol 07master * r8f9941b160 10ffmpeg/libavcodec/avrndec.c: 
[12:53] <CIA-56> ffmpeg: avrndec: silence warning about incompatible pointer types
[12:53] <CIA-56> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[12:53] <Compnn> durandal_1707 : imo ffmpeg should provide api to all of these libs
[12:53] <Compnn> makes it easier for other projects to use , if all of the libs have the same interface
[12:54] <durandal_1707> isn't libfaad replaced by libfaad2?
[12:54] <Compnn> hmmm?
[12:55] <ohsix> it will always be a poor match if you actually need something that makes that particular library novel or interesting
[13:02] <Compnn> what will be a poor match ?
[13:03] <durandal_1707> does faad2 provide anything that native decoder does not have?
[13:06] <JEEB> it is mostly worse off feature-wise, but there are a few rare cases IIRC where it might support something that ffaac doesn't, but I'm not sure about that. Also faad is known to just ignore most erroneous states and to try to go forward instead of stopping.
[13:06] <JEEB> personally I'd rather see ffaac developed further than faad getting used again
[13:16] <maister> anyone here knows their way around swscale? trying to understand initFilter() in libswscale/utils.c
[13:17] <ubitux> Daemon404: did you try to diff the inspxe-cl output between the cama2_vtc_b and a working similar (with no race detected) h264 test?
[13:18] <ubitux> maister: did you see doc/swscale.txt?
[13:18] <JEEB> (expect a response in 3-4 hours as I guess he's asleep until then)
[13:18] <maister> ubitux, not yet, will have a look.
[13:18] <maister> "The official guide to swscale for confused developers." <-- hah, great :d
[13:23] <maister> hm, wait, so scaling RGB24 -> RGB24 would go through YUV first?
[13:32] <Compn> JEEB : its not a replacement, its a failback when ffaac is missing a feature
[13:32] <Compn> and those small-subsets of AAC have been on wishlist of ffaac for years
[13:32] <Compn> because they are ... very small subsets of aac samples
[13:33] <Compn> a faad wrapper takes ... an hour? of work to re-commit the thing
[13:33] <Compn> sbr aac feature takes a while to code up i think
[13:34] <nevcairiel> ffaac should support sbr just fine
[13:34] <Compn> durandal_1707 : yes, check the supported aac list inside aacdec.c , it has some things missing :)
[13:35] <Compn> yes, maybe that user had old version...
[13:35] <Compn> or runs into different sbr problenm
[13:36] <Compn> [03:14] <xxthink> I want to use ffmpeg to decode an aac stream
[13:36] <Compn> [03:14] <xxthink> it always says:  SSR not implemented.
[13:36] <Compn> [03:16] <xxthink> are there some patchs to decode this kind of aac stream?
[13:36] <Compn> he wanted SSR
[13:36] <Compn> my bad for saying SBR ...
[13:36] <Compn> nevcairiel ^&
[13:37] <nevcairiel> i see, now thats something different
[14:05] <standesbeamter> michaelni, are you around?
[14:06] <standesbeamter> i still don't understand your comment to my dpx patch ...
[15:12] <kierank> Compn / michaelni: depending on how easy it is to stop you could probably run that tool on obe2
[17:08] <cbsrobot> are all 29.97 fps files automatically "drop frame" or not ?
[17:30] <cypher497> cbsrobot: 29.97 is the fps, timecode can be drop or non-drop
[18:07] <nyuhu> does anyone know how I can easily/quickly test the process_command callback in a lavfi filter ?
[18:10] <ubitux> iirc you can do it while ffmpeg is encoding, pressing 'c'
[18:11] <nyuhu> :o
[18:11] <nyuhu> thx for the tip
[18:12] <ubitux> i think saste wrote a filter to write a timeline of commands or something
[18:13] <nyuhu> yep, but it didnt get pushed yet
[18:14] <ubitux> yup :(
[18:14] <ubitux> nyuhu: what's your next filter btw? :)
[18:15] <nyuhu> an histogram equalizer
[18:16] <ubitux> cool, ok :)
[20:01] <maister> hm, is this really intended? When I rescale RGB to RGB, it first goes through YUV and back RGB. It also chroma subsamples at a resolution far lower than the original image. E.g. for 512x224 -> 256x224 point scale, it will only sample with 128px horizontally, causing some really nasty artifacts when it goes back to 256px.
[20:02] <maister> swscale.txt says it should indeed go to yuv 8-bit first before horizontal scale, but I fail to see why it has to do that.
[20:02] <Daemon404> swscale has a direct rgb->rgb patch nowadays
[20:02] <JEEB> it shouldn't, at least the scaling video filter doesn't do that AFAIK
[20:02] <Daemon404> swscale.txt is old...
[20:02] <Daemon404> how old is your ffmpeg?
[20:02] <maister> latest git
[20:02] <Daemon404> wait, didnt YOU write that path?
[20:02] <Daemon404> if youre teh arch linux guy
[20:03] <maister> No, that was gbr24 -> rgb unscaled
[20:03] <Daemon404> ah, right.
[20:03] <maister> this is scaled :p
[20:03] <maister> Can I provide a test case so you can see what I mean?
[20:03] <Daemon404> certainly cant hurt
[20:03] <maister> ok, 2 sec
[20:05] <maister> http://i.imgur.com/6lLmV.png <-- test image. It's 512x224. As you may see it's really just a point sampled stretch from 256x224. I expect to get back the original if I do this:
[20:05] <maister> ffmpeg -i test_image.png -sws_flags neighbor -vf scale=256:224 test_output.png
[20:06] <maister> the result however, introduces tons of weird errors
[20:06] <Daemon404> i think swscale only has resizing functions for yuv
[20:07] <Daemon404> neighbor resize in rgb should be trivial to add, but it opens a big bucket of worms
[20:07] <maister> http://i.imgur.com/Xw1iw.png <-- output
[20:07] <maister> especially noticable around the sprite in the middle
[20:08] <maister> the thing that worries me the most however
[20:08] <maister> is that at some point
[20:08] <maister> it's working with a width of 128px
[20:08] <maister> and not 256px
[20:09] <Daemon404> ill look into adding some rgb scaling stuff today maybe
[20:09] <Daemon404> i dont think many people do it
[20:09] <maister> Daemon404, apparently not H.264/RGB either :(
[20:09] <Daemon404> there arent a ton of usecases :P
[20:09] <Daemon404> game capture happens to be one
[20:09] <maister> true, but I'm very interested in that case ;)
[20:10] <Daemon404> no to mention most game capture tends to be windows-based
[20:10] <Daemon404> and people end up usign avisynth's rg bresizing
[20:10] <Daemon404> s/rg b/rgb /
[20:12] <maister> So far, only mplayer (1) seems to play H.264/RGB ootb, I should lobby around some more.
[20:13] <Daemon404> if vlc doesnt
[20:13] <Daemon404> i can add it
[20:13] <Daemon404> (vlc git + ffmpeg i mean)
[20:13] <Daemon404> it should.
[20:14] <maister> I can have a look
[20:14] <Daemon404> lav filters should as well
[20:14] <Daemon404> otherwise stab nevcairiel 
[20:14] <JEEB> works
[20:14] <maister> really? that's great
[20:14] <maister> :D
[20:15] <Daemon404> ffms2 supports it now too
[20:15] <Daemon404> so you can get it into avisynth
[20:15] <maister> That leaves mplayer2.
[20:15] <JEEB> it should work with mplayer2 too o_O
[20:15] <maister> doesn't here
[20:15] <maister> It says GBR pixel format is not recognized
[20:15] <maister> and refuses to play
[20:15] <JEEB> how old is that build?
[20:16] <maister> from git as well
[20:16] <JEEB> I remember there being herp and derp about that a long time ago
[20:16] <JEEB> but it should've already been fixed ages ago
[20:16] <maister> grepping through source doesn't give anything for "GBR"
[20:16] <maister> at least
[20:17] <JEEB> well it IIRC should've been just handled as RGB on the player's side, and swscale would be the one handling the GBR->RGB conversion
[20:17] <maister> mplayer2 put it off for a while because libav didn't have GBR until 6 months after ffmpeg did.
[20:17] <maister> or so
[20:18] <Daemon404> only because i ported it.
[20:18] <maister> right, you contacted me about it
[20:18] <maister> ?
[20:18] <Daemon404> aye
[20:18] <maister> right
[20:21] <maister> hm, which vlc version was supposed to work with h264/rgb?
[20:22] <Daemon404> try vlc git master + ffmpeg git master?
[20:22] <maister> will do
[20:23] <maister> 2.0.3 didn't work at least.
[20:23] <j-b> yeah
[20:23] <j-b> it worked at one point, then never again
[20:23] <maister> lol
[20:24] <Daemon404> lawl
[20:24] <j-b> and for some reason, noone cared
[20:25] <maister> Daemon404, you know the reason why libav and ffmpeg call GBR by different names?
[20:25] <maister> In ffmpeg it's GBR24P and libav it's just GBRP iirc
[20:25] <Daemon404> no i dont.
[20:27] <maister> wish by downlink was faster, checking out mplayer2 and vlc from git takes ages :v
[20:27] <maister> my*
[20:28] <maister> ok
[20:29] <maister> latest mplayer2 from git: http://pastebin.com/W7yANQWL
[20:39] <maister> hm, is there a solid way to differentiate between ffmpeg and libav at compile time?
[20:39] <Daemon404> nowadays, you can check the minor verison of any lib
[20:39] <Daemon404> if its >=100 its ffmpeg
[20:40] <maister> ok
[20:41] <Daemon404> or was it micro
[20:41] <Daemon404> i cant remember.
[21:01] <maister> ok, seems mplayer2 does have h264/rgb in some private branches, but not in master yet.
[21:02] <maister> still broken in vlc git btw :\
[21:08] <j-b> maister: green screen?
[21:08] <maister> yup :(
[21:09] <maister> [0x7fe918c02578] avcodec decoder error: don't know how to convert chroma 82
[21:09] <j-b> which one is 82...
[21:09] <maister> hurr durr
[21:09] <maister> :p
[21:09] <Daemon404> j-b, good thing those enums are labelled.. ohwait
[21:09] <j-b> :)
[21:12] <j-b> I hate overly long enums where there is no way to find the missing values
[21:12] <Daemon404> yup.
[21:12] <j-b> and with #ifdefs in the middle to be sure you cannot count :)
[21:13] <maister> = 1, = 2, = 3, = 4
[21:13] <maister> ;)
[21:15] <j-b> one every 20 is usually nice
[21:17] <Compn> anybody have a working m3u8 sample ?
[21:17] <Compn> like for testing...
[21:17] <Compn> public stream
[21:19] <j-b> maister: 10bits?
[21:19] <maister> the sample?
[21:19] <maister> it's 8-bit
[21:19] <j-b> yessir
[21:19] <maister> pix_fmt_gbrp
[21:21] <maister> it fails in TestFfmpegChroma(), because there's no GBRP found in that big list
[21:21] <maister> :p
[21:22] <maister> I'll see what some random hacking does :v
[21:29] <maister> just adding the format like the others triggers a segfault. :\
[21:31] <j-b> indeed
[21:32] <j-b> probably not the right memory size
[21:37] <j-b> oh, that is because GBRP is planar
[21:38] <j-b> reminds me of the mess Daemon404 had to fight (and failed)
[21:38] <maister> what mess?
[21:39] <maister> what mplayer does at least is to set up a preferred conversion to some RGB/BGR variant.
[21:39] <maister> and it just works :p
[21:45] <maister> I see why it's segfaulting
[21:45] <maister> no error checking on if the picture queue is initialized correctly
[22:09] <Daemon404> [15:38] <@j-b> reminds me of the mess Daemon404 had to fight (and failed) <-- i didnt fail, i just stop caring
[22:18] <maister> wait, what
[22:18] <maister> vlc detects h264/rgb as yuy2?
[22:18] <maister> o__O
[22:19] <Daemon404> vlc's colorspace stuff scares me. i faied recently at adding ARGB support
[22:19] <Daemon404> failed*
[22:21] <j-b> because libavutil colorspace does not scare you?
[22:22] <Daemon404> j-b, because i am familiar with the horrors of libav*
[22:22] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rd1ee2cf74a 10ffmpeg/libavformat/ (nut.c nut.h): 
[22:22] <CIA-56> ffmpeg: nutenc: keep track of the written syncpoint count
[22:22] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:22] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rcebbaf578d 10ffmpeg/libavformat/nutdec.c: 
[22:22] <CIA-56> ffmpeg: nutdec: improve information in error message
[22:22] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:22] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rc2a134c66c 10ffmpeg/libavformat/ (nut.h nutenc.c): 
[22:22] <CIA-56> ffmpeg: nutenc: keep track if keyframe PTS
[22:22] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:23] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r3a621c9d99 10ffmpeg/ (48 files in 4 dirs): 
[22:23] <CIA-56> ffmpeg: nutenc: Support writing an index
[22:23] <CIA-56> ffmpeg: The seek test improves in accuracy
[22:23] <CIA-56> ffmpeg: Fixes Ticket877
[22:23] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:23] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * re6a045ba56 10ffmpeg/libavformat/nutdec.c: 
[22:23] <CIA-56> ffmpeg: nutdec: Flip the direction for seeking with an index in the failure case.
[22:23] <CIA-56> ffmpeg: This is closer to how seeking works without an index
[22:23] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:23] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rb2a8ce4e67 10ffmpeg/libavformat/ (nut.h nutenc.c): 
[22:23] <CIA-56> ffmpeg: nutenc: keep track of max_pts
[22:23] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:26] <nevcairiel> colorspace stuff in libav* might not be ideal, but i didnt find dealing with it all that bad. I just shove all formats i dont support natively though swscale and be done with it
[22:31] <j-b> Daemon404: you should have received a mail about HOTEL
[22:32] <Daemon404> i just read it
[22:32] <j-b> cool.
[22:32] <Daemon404> our roomies are a surprise?
[22:34] <j-b> Daemon404: who do you want to be with.
[22:34] <j-b> I'll hand the list 2morrow
[22:34] <Daemon404> i dont really mind
[22:34] <Daemon404> just curious.
[22:34] <j-b> then random()
[22:35] <Daemon404> indeed
[22:52] <CIA-56> ffmpeg: 03Loren Merritt 07master * r566858a770 10ffmpeg/libavfilter/vf_hqdn3d.c: vf_hqdn3d: support 16bit colordepth
[22:52] <CIA-56> ffmpeg: 03Anton Khirnov 07master * r44b0b85fe9 10ffmpeg/avconv.c: avconv: prefer user-forced input framerate when choosing output framerate
[22:52] <CIA-56> ffmpeg: 03Loren Merritt 07master * r7a1944b907 10ffmpeg/ (4 files in 3 dirs): 
[22:52] <CIA-56> ffmpeg: vf_hqdn3d: x86 asm
[22:52] <CIA-56> ffmpeg: 13% faster on penryn, 16% on sandybridge, 15% on bulldozer
[22:52] <CIA-56> ffmpeg: Not simd; a compiler should have generated this, but gcc didn't.
[22:52] <CIA-56> ffmpeg: 03Diego Biurrun 07master * ref07ac1e12 10ffmpeg/libavcodec/ (cavs.c cavs.h cavsdata.h cavsdec.c): cavs: Move data tables used in only one place to that file
[22:53] <CIA-56> ffmpeg: 03Jan Ekström 07master * r09bd0ea94e 10ffmpeg/tests/ (fate/utvideo.mak ref/fate/utvideo_rgba_single_symbol): 
[22:53] <CIA-56> ffmpeg: fate: Add a single symbol Ut Video decoder test
[22:53] <CIA-56> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[22:53] <CIA-56> ffmpeg: 03Mans Rullgard 07master * r88386feefd 10ffmpeg/libavcodec/ (Makefile cavs.c cavsdata.c): 
[22:53] <CIA-56> ffmpeg: cavs: convert cavsdata.h to a .c file
[22:53] <CIA-56> ffmpeg: Defining tables in header files is ugly and prone to duplication.
[22:53] <CIA-56> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[22:53] <CIA-56> ffmpeg: 03Diego Biurrun 07master * r1ce5dce454 10ffmpeg/libavcodec/ (dwt.c dwt.h): dwt: Remove unused code.
[22:53] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r17106a7c90 10ffmpeg/: (log message trimmed)
[22:53] <CIA-56> ffmpeg: Merge remote-tracking branch 'qatar/master'
[22:53] <CIA-56> ffmpeg: * qatar/master:
[22:53] <CIA-56> ffmpeg:  audio_frame_queue: Clean up ff_af_queue_log_state debug function
[22:53] <CIA-56> ffmpeg:  dwt: Remove unused code.
[22:53] <CIA-56> ffmpeg:  cavs: convert cavsdata.h to a .c file
[22:53] <CIA-56> ffmpeg:  cavs: Move inline functions only used in one file out of the header
[22:53] <CIA-56> ffmpeg: 03Diego Biurrun 07master * rd7f9786cbc 10ffmpeg/libavcodec/ (audio_frame_queue.c audio_frame_queue.h): 
[22:53] <CIA-56> ffmpeg: audio_frame_queue: Clean up ff_af_queue_log_state debug function
[22:53] <CIA-56> ffmpeg: The function is debug-only, so only compile it in debug mode.
[22:53] <CIA-56> ffmpeg: Make it static as it has no uses outside of the file.
[22:53] <CIA-56> ffmpeg: Change av_log() to av_dlog().
[22:54] <CIA-56> ffmpeg: 03Diego Biurrun 07master * ra6d9f9e60e 10ffmpeg/libavcodec/ (cavs.c cavs.h cavsdec.c): cavs: Move inline functions only used in one file out of the header
[23:38] Action: bgmarete is away: I'm busy
[23:39] Last message repeated 1 time(s).
[23:39] Action: bgmarete is back (gone 00:00:08)
[23:49] <Daemon404> meh
[23:50] <Daemon404> i cant even find the resizing code in swscale
[23:50] <maister> what part?
[23:50] <maister> libswscale/utils.c has the context creation iirc.
[23:51] <Daemon404> nothing is clear
[23:51] <Daemon404> from a look
[23:51] <Daemon404> all very convoluted
[23:51] <maister> Daemon404, I spent 4-5 hours today trying to figure out what was going on.
[23:51] <maister> :p
[23:51] <Daemon404> i havent located the alctual scaling yet
[23:52] <Daemon404> actual*
[23:52] <maister> As I understand it, sws_init_context sets up the filter values, then you have the "magic" swScale function or something that apparently does it all. 
[23:53] <Daemon404> i think youre right
[23:53] <Daemon404> but hell if i know how to work it / add anything
[23:53] <maister> :(
[23:54] <Daemon404> no comments, no documentation, very unclear code
[23:54] <Daemon404> fucks given -> 0
[23:55] <maister> Daemon404, apparently, there's self-modifying MMX asm in there as well D:
[23:55] <Daemon404> there is
[23:55] <Daemon404> swscale is similar to ravenholm
[00:00] --- Mon Aug 27 2012