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

[burek]

[00:02] <BBB> Daemon404: I'm not complaining, just saying technically it looks like it does something that makes sense :) I don't use ffprobe myself except for scripting purposes
[00:07] <BBB> michaelni: well the reason I want to split it is that I don't think the implementation in h264 is correct
[00:07] <BBB> michaelni: and that's largely because it is shared and we're trying to fit h264 in mpeg, which doesn't make much sense
[00:08] <BBB> michaelni: e.g. look at the frame selection: if I'm a b frame or low delay or output in coded order, output cur (that's fine), else, output the first reference (are you sure that's correct?)
[00:09] <BBB> whereas for mpeg, that makes perfect sense
[00:10] <BBB> so they _should_ be different if you ask me (trying to fit them together just makes it needlessly complex or introduces bugs)
[00:10] <BBB> then again I don't care much, chrome doesn't actually use draw_horiz_band so perhaps I should make that configurable ?
[00:10] <BBB> (ie. in h264 without draw_horiz_band, the function doesn't do anything)
[00:22] <iive> BBB: I think the question here is the opposite. If you have a correct decode output for h264, would it be able to handle older codecs?
[00:31] <BBB> unlikely :) because the other codecs would need weird stuff like edge extension
[00:47] <iive> not long ago h264 also had edge extension... If I remember correctly you were the one to enable it as speed optimization, now I guess you removed it as speed optimization :)
[00:50] <michaelni> BBB, ok, had forgotten the issues with h264+horiz band implementation
[00:52] <cone-215> ffmpeg.git 03Ronald S. Bultje 07master:454c5d10b293: h264: add a copy of draw_horiz_band.
[00:52] <BBB> iive: no that wasn't me :)
[00:52] <BBB> iive: I did remove it yes, and that was indeed a speed optimization
[00:52] <BBB> I wrote a patch for vp8 to enable it as a speed optimization
[00:52] <BBB> which is when I figured out it was in fact slower
[00:52] <BBB> so instead, I removed it from h264
[00:52] <BBB> now they're both faster
[00:53] <BBB> michaelni: yt; trying to fix up that error resilience dependency removal patch now; any ideas on how to expose that the dependency of h264 on er is optional?
[00:53] <BBB> michaelni: e.g. should I make er a commandline option so I can do --disable-everything --enable-decoder=h264 --{disable,enable}-error-resilience?
[00:54] <iive> hum... i'll have to check my logs. But I remember arguing with somebody about the edge, his explanation was that because of high number of 4x4 partitions and calling emu_edge for each of them, it is faster to have it as buffer wide.
[00:54] <BBB> iive: the data speaks otherwise
[00:55] <iive> maybe different test sample.
[00:55] <BBB> no, I tested a lot of samples
[00:55] <BBB> here's one thing: motion is generally only in one direction
[00:55] <BBB> so either you use small edges on both sides (no motion), or bigger edges on one side
[00:56] <BBB> having to draw 16 pixel edges on both sides, if only 1/4 of that on either side, or the full part on 1 side, is used, means you're wasting a lot of cycles
[00:56] <BBB> a fast emu_edge implementation isn't really difficult, and will not have this mandatory overhead
[00:56] <BBB> i.e. it only draws what's needed
[00:57] <michaelni> a --disable-error-... sounds like a good idea yes, btw iam not sure it should be called resilience and not concealment but i am happy with either name
[00:58] <BBB> we can argue over the name while I try to implement it
[00:58] <BBB> it's easy to change
[00:58] <BBB> it should probably be called concealment yes
[00:58] <BBB> the config option is called resilience though
[00:58] <BBB> not sure why
[00:59] <michaelni> probably because the filename has resilience in it which probably was my mistake from long ago
[01:00] <BBB> hm... let's fix that
[01:01] <BBB> why does --disable-everything --enable-decoder=h264 compile in things like frame_thread_encoder, fft, rdft, rawdec, audioconvert, fmtconvert, jrevdct, resample and resample2?
[01:01] <BBB> I guess I still have some work ahead of me
[01:02] <BBB> (I have a local patch to rip out dsputil)
[01:03] <iive> why do you want to rip it? using h264 only for hwaccel?
[01:03] <BBB> h264 does not use dsputil
[01:04] <BBB> also:
[01:04] <BBB>   "_iconv_open", referenced from:
[01:04] <BBB>       _avcodec_decode_subtitle2 in libavcodec.a(utils.o)
[01:04] <BBB> ?
[01:04] <BBB> ubitux: your patch?
[01:04] <BBB> ubitux: I remember someone saying you were looking for a mac person to fix that? I'm here, what do I test
[01:06] <ubitux> oh perfect
[01:06] <ubitux> yeah well, the question is
[01:06] <ubitux> why the configure check passes
[01:06] <ubitux> but not the final link op
[01:07] <ubitux> one user already did that, but can you paste the iconv-related info from config.log and the full ld line with make ffmpeg V=1?
[01:07] <ubitux> the configure check with -liconv should have worked
[01:08] <ubitux> but the ffmpeg link step which seems to include -liconv as well at the end doesn't
[01:08] <ubitux> BBB ^
[01:21] <BBB> yeah, one sec
[01:22] <ubitux> (btw, one workaround is obviously to --disable-iconv if you need a working build fast)
[01:34] <BBB> I know that
[01:35] <BBB> but that's not useful for automated purposes
[01:35] <ubitux> i'm willing to fix it asap :p
[01:35] <BBB> http://pastebin.com/xc3qWbVc
[01:35] <ubitux> ok so the -liconv configure check actually worked
[01:35] <ubitux> as expected..
[01:35] <BBB> http://pastebin.com/2siaQWbw
[01:36] <ubitux> ok
[01:36] <ubitux> can you move the -liconv before the -L/opt/.. ?
[01:38] <BBB> same output
[01:38] <BBB> (-lSDLmain -lSDL -lm -liconv -lbz2 -lz -L/opt/local/lib)
[01:39] <ubitux> ok so my second and only guess would be that it's because of an optim in the configure check 
[01:39] <BBB> if I remove -L/opt/local/lib and all sdl related things, it passes  abit more
[01:40] <ubitux> oO
[01:40] <Daemon404> ldd iconv.dylib
[01:40] <Daemon404> or whatever ldd is on mac
[01:41] <Daemon404> er well if its dynamic it wouldnt matter i guess
[01:41] Action: Daemon404 dumb
[01:41] <BBB> ff_print_debug_info2 is in mpegvideo, so h264 still fails to compile for me
[01:41] <BBB> maybe move that to utils.c?
[01:41] <BBB> michaelni: ?
[01:42] <Daemon404> huh.. i wonder
[01:42] <Daemon404> google shows a lot of sdl related to iconv failures on mac
[01:42] <ubitux> &
[01:42] Action: Daemon404 wonders if disablign sdl fixes
[01:42] <BBB> nope
[01:42] <BBB> reintroducing -L/opt/local/lib makes it fail
[01:42] <BBB> without any sdl
[01:43] <iive> BBB: i remember somebody moving a debug function to the only file it is used. can you check its history? 
[01:43] <ubitux> is there some conflicting iconv symbols between what's in /opt/local/lib and what's <elsewhere>?
[01:44] <BBB> iive: this one is used in mpeg and in h264
[01:44] <BBB> ubitux: I have one libiconv in each location, yes
[01:44] <cbsrobot_> isn't /opt/local/lib used by macports ?
[01:44] <Compn> [15:31] <peper03> wm4: I wouldn't say there's no hope, just that I think it's a substantial undertaking, particularly to abstract DVDs to the level where MythTV, VLC, XBMC et al could just link in a library, point it at a DVD and get it to play.
[01:44] <Compn> ^^ i dont think this could ever happen :(
[01:45] <Compn> unless some big company paid for the whole thing
[01:45] <ubitux> i wonder why it prefers libiconv from /opt/local/lib even if it's placed before the -L
[01:46] <ubitux> (at least it seems)
[01:46] <ubitux> maybe it's a more recent version?
[01:46] <ubitux> (which is broken somehow?)
[01:47] <BBB> cbsrobot_: yes
[01:48] <Compn> ubitux : i remember some people went insane when working with iconv ... so dont sweat it too hard ;)
[01:50] <Daemon404> Compn, probably the gettext/iconv circular dependency from hell
[01:51] <iive> ubitux: are -L supposed to be searched in the order specified?
[01:51] <ubitux> i don't know
[01:51] <Compn> i'd like to know if commercial dvd software has the same problems with dvds that opensource software has
[01:51] <Compn> that would make me feel better.
[01:51] <Compn> or "dvds" i should call them. since they've perverted the phillips dvd spec so badly , they arent allowed to use the dvd logo
[01:52] <ubitux> BBB: just curious, what pkg-config --libs libiconv gives you?
[01:52] <Compn> ubitux : should ask fate owners to report that too
[01:53] <michaelni> BBB if you want you could also put the call to print_debug_info2() under if(CONFIG_MPEGVIDEO), i dunno what is best
[01:53] <ubitux> Compn: i already sent a mail to him, still no news
[01:55] <Compn> michaelni : btw is there any copyright on the draw_horiz_band ? if so the copyright should be copied to h264 too ... :)
[01:55] <cbsrobot_> when I try to install libiconv with homebrw I get:
[01:55] <cbsrobot_> Apple distributes libiconv with OS X, you can find it in /usr/lib.
[01:55] <cbsrobot_> Some build scripts fail to detect it correctly, please check existing
[01:55] <Compn> duplicate code > duplicate copyrights
[01:56] <ubitux> well, anyway, if it's present it /opt/local/lib as well, it should work too
[01:57] <ubitux> maybe the version present in /opt/local/lib is for 32-bit only or something like this?
[01:57] <ubitux> (and the linker doesn't try to fallback on the system one)
[01:58] <BBB> michaelni: hm... I split it out for now... but yes, ideally it's one of those things we can compile without, we'd really like to be able to get a minimal config (we won't be using that code anyway, and it looks like it's quite a lot)
[01:58] <BBB> if CONFIG_MPEGVIDEO is ok I'll do that instead
[01:59] <iive> BBB: utils.c in libavcodec seems like a good solution.
[02:00] <michaelni>  CONFIG_MPEGVIDEO is ok IMHO
[02:03] <BBB> ok sent a new patch
[02:06] <iive> imho, not a good idea your debug output to depend on random other options. but whatever works for you.
[02:08] <BBB> iive: well it's a commandline option anyway
[02:09] <michaelni> iive, putting it in utils.c doesnt feel completely right, iam not sure why
[02:09] <BBB> it's not generic
[02:10] <BBB> all these flags are mpegvideo-specific
[02:10] <michaelni> yes
[02:10] <iive> do we have file dedicated to debug output?
[02:10] <BBB> also, http://pastebin.com/y5UBSNZk is a list of what's left to split before --disable-everything --enable-decoder=h264 without dsputil works
[02:10] <BBB> iive: that was my first patch, but that does make my binaries quite a bit bigger, so ideally it'd be configurable in itself alslo
[02:11] <Daemon404> the splititng up has made a huge diff btw
[02:11] <Daemon404> my minimal builds for mpeg2 have gone from 2.7 to 2.9 mb
[02:11] <Daemon404> er, 2.7 to 1.9
[02:11] <Daemon404> thats a nontrivial amount
[02:11] <BBB> lol
[02:11] <BBB> I was like, 2.9 mb, that wasn't quite the intention
[02:11] <BBB> but yes, splitting helps a lot
[02:12] <Daemon404> 1.9 is still huge for mpeg2
[02:12] <Daemon404> also because tehres som fuck up deps
[02:12] <BBB> you're including all mpeg encoding dsp functions
[02:12] <BBB> also mpeg2 includes mpeg4
[02:12] <Daemon404> dsputil has a hard dep on h264qpel asm
[02:12] <BBB> really, you need to split out the mpeg2 decoding asm into its own submodules
[02:12] <BBB> dsputil is ... broken
[02:12] <BBB> the only fix is to not use it
[02:13] <Daemon404> oh and that 1.9 mb turns into 500 kb with msvc
[02:13] <Daemon404> too bad its so much slower for mpeg2
[02:13] <BBB> because msvc has no inline asm :)
[02:13] <BBB> that's like cheating
[02:13] <BBB> we saw the same thing for chrome btw
[02:13] <Daemon404> i doubt there's 1.4 mb of asm
[02:13] <BBB> msvc is 1MB smaller than gcc
[02:14] <BBB> you'd be surprised
[02:14] <BBB> and chrome was equal speed, because all h264 asm except cabac is yasm
[02:14] <BBB> same for vp8
[02:14] <BBB> and vp3 has no inline asm at all anymore
[02:14] <BBB> (maybe these crazy hpel functions, not sure)
[02:14] <Daemon404> doesnt chrome ship vp6 too
[02:14] <Daemon404> for like, old youtube vids
[02:15] <Daemon404> and such
[02:15] <BBB> no
[02:15] <BBB> that's flash
[02:15] <Daemon404> orite
[02:15] <Daemon404> i like to forget ti exists
[02:15] <Daemon404> it*
[02:15] <BBB> heh :)
[02:15] <Daemon404> i wish chrome was less buggy tho
[02:15] <BBB> file bugs
[02:15] <BBB> also, latest chrome has vp9 support
[02:15] <Daemon404> there are longstanding bugs
[02:15] <Daemon404> for my issue
[02:15] <Daemon404> no fixe
[02:15] <BBB> what's the issue?
[02:15] <Daemon404> only attempted fixes
[02:16] <Daemon404> contents of a tab will be entirely black
[02:16] <Daemon404> disablign all hw accel fixes it
[02:16] <BBB> I've heard of that one
[02:16] <Daemon404> happens randomly
[02:16] <BBB> isn't that a driver bug?
[02:16] <Daemon404> latest nvidia drivers
[02:16] <Daemon404> and it happens on my laptop too, which is amd
[02:16] <Daemon404> so its no isolated
[02:16] <Daemon404> not*
[02:17] <Daemon404> also, on some setups, the html5 video playback plays 2 seconds and crashes/stops/errors
[02:17] <Daemon404> very reproducible on our site.. i do need to file a bg about that
[02:17] <Daemon404> but i keep forgetting
[02:19] <Daemon404> lastly (and this has a bug files)
[02:19] <Daemon404> is that chrome has a hardcoded 1mb probe size
[02:19] <Daemon404> for using metadata apis
[02:19] <Daemon404> otehr browsers use a few kb of our bw, chrome uses 1mb every time, which cosumes a nontrivial amount of bw
[02:20] <Daemon404> considering chroems large userbase
[02:20] <Daemon404> /rant
[02:20] <BBB> file ugbugs
[02:20] <Daemon404> :)
[02:20] <Daemon404> that one has a bug report
[02:20] <Daemon404> largely ignores.
[02:20] <Daemon404> d
[02:20] <BBB> assign it to dalecurtis
[02:20] <Daemon404> random users can assign things?
[02:21] <ubitux> "dalecurtis, i choose you!"
[02:21] <BBB> what is imgconvert?
[02:23] Action: Daemon404 goes back to poking NSS's horrible API
[02:27] <BBB> ah... shrink is one of those mpegvideoenc things
[02:27] <BBB> why is it in imgconvert.c?
[02:27] <BBB> and can avpicture_deinterlace die now that we have yadif?
[02:28] <Daemon404> welcome to 2003?
[02:28] <iive> probably for historical reasons,
[02:29] <BBB> I'll just make imgconvert depend on config_dsputil or so
[02:29] <Daemon404> iive, that doesnt seem like a legitimate reason for something so silly
[02:30] <Daemon404> say that enough and you get mplayer
[02:32] <BBB>   "_avcodec_find_best_pix_fmt_of_2", referenced from:
[02:32] <BBB>       _pick_format in libavfilter.a(avfiltergraph.o)
[02:32] <BBB> that seems broken?
[02:32] <BBB> why would avfilter depend on avcodec?
[02:32] <BBB> Daemon404: well, given that a mpeg2 decoder used to be 2.7MB, I'd say we're not too far off mplayer
[02:33] <Daemon404> :V
[02:33] <iive> h264 depends on *_get_chroma_sub_sample...
[02:35] <Compn> BBB : is avpicture_deinterlace faster than yadif ?
[02:35] <Compn> :P
[02:35] <BBB> iive: right, I'd expect it to; I'd also expect such a function to live in lavu, not in imgconvert.c
[02:36] <BBB> Compn: avpicture_deinterlace looks like it is a smoothing filter or something along those lines
[02:36] <Compn> theres lots of old code to do deint and pp in ffmpeg methinks
[02:37] <Compn> unfortunately, html5 h264 lags in opera on my setup where h264 in flash does not. i think its due to how its buffered :\
[02:37] <BBB> it's a 5tap -1,4,2,4,-1 filter
[02:38] <BBB> I don't see how such a filter does anything related to deinterlacing
[02:38] <Compn> both use crazy amounts of cpu vs just playing with mplayer...
[02:38] <BBB> it does no mc between fields
[02:39] <Skyler_> BBB: you need to interpolate the missing field
[02:39] <Skyler_> -1,4,2,4,-1 is weird though
[02:39] <Compn> ehe
[02:39] <Compn> http://web.archiveorange.com/archive/v/yR2T401Db3lAyJD3781C
[02:40] <Compn> michaelni called that code crap in 2009 :)
[02:40] <Compn> BBB : remove it while no one is looking! :D
[02:43] <BBB> Skyler_: that's what it does :)
[02:44] <BBB> michaelni: can we kill avpicture_deinterlace?
[02:44] <BBB> Compn: yeah the filter is indeed crap, I have no opinion on the code quality
[02:50] <michaelni> we can mark it as deprecated with a pointer to better filter(s) and then remove it once it was deprecated for long enough
[02:59] <iive> have fun.
[03:04] <BBB> I can make it configurable and deprecated
[03:05] <BBB> that works for me
[03:21] <BBB> michaelni: it's been marked deprecated for a few years already in ffmpeg_opt.c
[03:21] <BBB> michaelni: is that enough? or you want an additional while attribute_deprecated in avcodec.h?
[03:25] <michaelni> i think it is or was used by other applications sadly too
[03:26] <Compn> mplayer has some lavc deints, but i dont know if they are the same
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:4f873341b4d5: sanm: add forgotten check for decoded_size in old_codec37()
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:f62537d9f1b4: sanm: Use the correct height variable in the decoded_size checks
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:534c0df6e0ed: pngdec/filter: dont access out of array elements at the end
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:d17b9469c940: tiff: Check buffer allocation and pointer increment more carefully in shorts2str() and double2str()
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:82213d67bad8: shorten: dont leave invalid channel counts in the context.
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:e35da91b52cc: swr: check channel layouts before using them.
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:1ddb0b6fa0bd: avcodec_decode_audio4: check got_frame_ptr before handling initial skip
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:676df8c4c70c: h264: check that luma and chroma depth match
[03:36] <cone-215> ffmpeg.git 03Michael Niedermayer 07release/1.0:d034ddcd1f6c: rtmpproto: Check APP_MAX_LENGTH
[11:51] <cone-686> ffmpeg.git 03Martin Storsjö 07master:8fbab7a6c84f: rtpdec: Initialize some variables to silence compiler warnings
[11:51] <cone-686> ffmpeg.git 03Michael Niedermayer 07master:fd464d4d01b3: Merge remote-tracking branch 'qatar/master'
[11:58] <durandal_1707> michaelni: so you never noticed that stereo3d filter in lavfi is broken?
[12:11] <cone-686> ffmpeg.git 03Justin Ruggles 07release/1.1:73d6f4651e64: ac3dec: validate channel output mode against channel count
[12:11] <cone-686> ffmpeg.git 03Luca Barbato 07release/1.1:37e99e384e37: vorbisdec: Add missing checks
[12:11] <cone-686> ffmpeg.git 03Michael Niedermayer 07release/1.1:494ddd377ada: vorbisdec: Error on bark_map_size equal to 0.
[12:11] <cone-686> ffmpeg.git 03Luca Barbato 07release/1.1:c6c4dc69354f: vorbisdec: Accept 0 amplitude_bits
[12:11] <cone-686> ffmpeg.git 03Martin Storsjö 07release/1.1:1b0082eabcc9: flvdec: Don't read the VP6 header byte when setting codec type based on metadata
[12:11] <cone-686> ffmpeg.git 03Michael Niedermayer 07release/1.1:7327505883b1: rtmpproto: Check APP_MAX_LENGTH
[12:11] <cone-686> ffmpeg.git 03Michael Niedermayer 07release/1.1:b3c8fd1f0e48: Merge commit '1b0082eabcc98e079d33c61da4d30ded89de68a9' into release/1.1
[12:18] <michaelni> durandal_1707, last i tested it worked (i did not test it with 3d glasses so i cant say if its output made sense)
[12:19] <cone-686> ffmpeg.git 03Martin Storsjö 07release/1.1:efa860351825: flvdec: Check the return value of a malloc
[12:19] <cone-686> ffmpeg.git 03Anton Khirnov 07release/1.1:b6f5a1ca588c: h264: on reference overflow, reset the reference count to 0, not 1.
[12:19] <cone-686> ffmpeg.git 03Anton Khirnov 07release/1.1:704952fee52f: h264: set ref_count to 0 for intra slices.
[12:19] <cone-686> ffmpeg.git 03Reinhard Tartler 07release/1.1:a3b3096772c6: update Changelog
[12:19] <cone-686> ffmpeg.git 03Michael Niedermayer 07release/1.1:992957ac3050: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[12:24] <durandal_1707> michaelni: how giving hardocode numbers as arguments is user friendly/useful
[12:26] <wm4> but it's the mplayer way!
[12:27] <wm4> wait, not even mplayer does
[12:27] <durandal_1707> mplayer accepts strings
[12:27] <durandal_1707> mpv accepts for sure
[12:28] <michaelni> hardcoded numbers as args is not user friendly no
[12:30] <wm4> durandal_1707: usually, mplayer takes numbers as arguments, but in this case, even mplayer accepts strings
[12:32] <cone-686> ffmpeg.git 03Ronald S. Bultje 07master:d4e649cca6de: h264: make it possible to compile without error_resilience.
[12:32] <cone-686> ffmpeg.git 03Ronald S. Bultje 07master:d98aa7cdc19b: h264: put call to ff_print_debug_info2 under CONFIG_MPEGVIDEO.
[12:46] <durandal_1707> huh, why ffplay ignores sample aspect ratio?
[13:35] <ubitux> durandal_1707: ffplay tests/lena.pnm -vf split,blend doesn't work :(
[13:43] <durandal_1707> ubitux: i told you already that single images do not work because lavfi API for that is missing and i did not want to copy paste overlay code
[13:44] <durandal_1707> actually for any stream(s) filter will stop on encounering first EOF
[13:44] <durandal_1707> so for same number X of frames, X > 1 you will get X-1 filtered frames .....
[14:28] <cone-686> ffmpeg.git 03Michael Niedermayer 07master:981cf0c30003: movenc: Do not flag secondary audio and subtitle tracks as enabled.
[14:28] <cone-686> ffmpeg.git 03Michael Niedermayer 07master:3fac99cd9d00: Merge remote-tracking branch 'cehoyos/master'
[16:05] <durandal_1707> the stereo3d filter is just bino rip off?
[16:33] <durandal_1707> ubitux: what you wanted to do with blend filter?
[16:40] <ubitux> just wanted to see the effect of additionning the image with itself
[16:50] <durandal_1707> did you see it?
[16:53] <ubitux> with a video yeah
[16:56] <durandal_1707> ubitux: try difference/and/xor/or
[17:00] <ubitux> "split[a][b]; [a]pad=iw*2[p]; [b]split[x][y]; [x]select='gt(n,0)'[z]; [y][z]blend=all_mode=difference[f]; [p][f]overlay=w" hehe
[17:00] <cone-334> ffmpeg.git 03Michael Niedermayer 07master:6c6dc8ccea56: wmadec: check nb_frames
[17:03] <durandal_1707> ubitux: i mean when comparing encoding quality
[17:03] <durandal_1707> average is also good
[17:04] <ubitux> ah, didn't compare that, just wanted to play with the effects
[17:04] <durandal_1707> can i get review for stereo3d? I want to add more features to it.
[17:42] <wm4> does libavcodec support mp3PRO?
[17:42] <nevcairiel> dont think so
[17:44] <JEEB> pretty much nothing does afaik
[18:55] <cone-334> ffmpeg.git 03Michael Niedermayer 07master:d210e9741e7c: rv34: fix aspect ratio
[18:55] <cone-334> ffmpeg.git 03Michael Niedermayer 07master:f2cb99313941: avformat: gather aspect ratio from rv30/40 in find_stream_info
[19:39] <cone-334> ffmpeg.git 03Michael Niedermayer 07master:9af8179cdb5e: ffmpeg: fix -stats -v 0
[21:26] <cone-334> ffmpeg.git 03Ronald S. Bultje 07master:2cffe38df3df: Deprecate deinterlaced in libavcodec.
[21:46] <cone-334> ffmpeg.git 03Reimar Döffinger 07master:88d55b827d5e: Remove incorrect use of ctype.h functions.
[22:04] <BBB> so now what's left is a whole bunch of fullpel c mc functions, ff_cropTbl, zigzag_direct, and some mmxext/sse2 optimizations shared between hpel and qpel; so... shall I just make a new file that contains the fullpel mc c functions so it can be shared between hpel and qpel?
[22:08] <cone-334> ffmpeg.git 03Clément BSsch 07master:14e240cb4aaa: lavfi/opencv: isgraph -> av_isgraph.
[22:10] Action: ubitux wonders if 5cd597f isn't responsible for http://fate.ffmpeg.org/report.cgi?time=20130303144843&slot=x86_64-archlinux-gcc-valgrind
[22:11] <ubitux> BBB: any hint for the iconv ld failure? :(
[22:18] <BBB> ubitux: not really... it seems it finds two versions of libiconv and I'm not sure but it's not working
[22:19] <ubitux> could you try gcc -Wl,-v?
[22:19] <ubitux> so we can get a clue about what's going on
[22:19] <ubitux> also a magic-linker-dump-info-tool on both libiconv might help
[22:19] <ubitux> i wonder if one isn't 32-bit only or something nasty like this
[22:20] <BBB> no, it warns on the terminal if that happens
[22:21] <michaelni> ubitux, maybe you should disable iconv until this is resolved
[22:21] <ubitux> michaelni: yeah i guess that's what i'm going to do...
[22:24] <BBB> http://pastebin.com/n1TH76E2
[22:24] <BBB> nothing too useful there I'm afraid
[22:25] <ubitux> yeah :(
[22:25] <ubitux> can you list the available symbols in the different iconv libs?
[22:27] <BBB> http://pastebin.com/8QjaQ8Lj
[22:28] <ubitux> 0000000000019060 T _libiconv_open
[22:28] <ubitux> aargh.
[22:28] <ubitux> no shit niggah
[22:28] <ubitux> T_T
[22:29] <ubitux> ok let's #define iconv_open on libiconv_open etc
[22:29] <cone-334> ffmpeg.git 03Michael Niedermayer 07master:e2427f04b7bc: ffmpeg_opt: Ask for overwrite in single image2 files too
[22:30] <BBB> don't forget that it tests against /usr/lib
[22:30] <BBB> and then it uses the one in /opt/local/lib because of the -L flag
[22:30] <BBB> so make sure you do something that works in that case, or hardcode the location of the library in some way
[22:31] <ubitux> i'm not sure there is any sane way to deal with this in the configure..
[22:39] <ubitux> fuck that shit seriously..
[22:41] <ubitux> BBB: anyway, thx for the testing
[22:42] <BBB> lol
[22:42] <BBB> no wonder people hate libiconv
[22:43] <BBB> so people ok with me adding a fpeldsp and fpeldsp_template to deal with fullpel mc functions shared between qpel and hpel?
[22:43] <BBB> or maybe I'll just move it to qpel, not sure
[22:52] <Compn> ubitux : check how vlc does it :D
[22:53] <Compn> or mplayer. .....
[22:53] <ubitux> i don't care
[22:53] <ubitux> i'll just --enable-iconv for myself and in my fate instances and that will do
[22:54] <ubitux> if mac os users can't convert subtitles with charset, they can fix it themselves
[22:54] <ubitux> for example by fixing this libiconv insanity :
[22:54] <ubitux> :p
[22:57] <ubitux> Compn: and i can't just "look how it's done"
[22:58] <ubitux> blind guess is frustrating, and i don't want to annoy BBB during one month trying all kind of shitty debug in mplayer/vlc/ffmpeg
[23:06] Action: Compn wonders why people work on open source, but then never copy code from other projects who have had this fixed for years already
[23:07] <ubitux> vlc is using autotools ’ i can't import anything
[23:07] <ubitux> mplayer uses a close but different system, where i'm not sure it even supports libiconv
[23:08] <ubitux> Compn: now, you can also try to write something and realize by yourself the problems :)
[23:17] <wm4> mplayer is usually not the place to get clean code
[23:19] <Compn> freakin autotools :D
[23:19] <wm4> ubitux: musl (a complete libc) has a really small iconv implementation, though it still requires some large tables: http://git.musl-libc.org/cgit/musl/tree/src/locale/iconv.c
[23:19] <wm4> that would be a good place to steal from
[23:20] <Compn> is that dalias's project ?
[23:20] <Compn> cant remember how many libc reimplementations there are now
[23:21] <wm4> yes that's dalias's
[23:23] <ubitux> yes, i considered having a fficonv... but huge tables..
[23:24] <ubitux> every time i look at musl i want to try it :p
[23:24] <ubitux> i wonder if i should try to add a fate instance with it
[23:50] <cone-334> ffmpeg.git 03Clément BSsch 07master:16ed6a6bf7a7: doc/filters: fix degrees/radians copy/paste fail.
[23:51] <cone-334> ffmpeg.git 03Clément BSsch 07master:9ad3cd5b5f84: build: disable iconv by default.
[23:53] <ubitux> saste \o/
[23:54] <ubitux> saste: i need you to get done with the volume eval
[23:54] <ubitux> btw, i was considerating adding a eval_expr_is_const() or similar, to enable/disable the optimized path in volume (and elsewhere)
[00:00] --- Mon Mar  4 2013