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

[burek]

[00:26] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:f4aa8085f23c: Avoid a null pointer dereference on oom in the aac encoder.
[00:26] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:712ef25116b4: Avoid a null pointer dereference after oom on frame size change in mpegvideo.c.
[01:02] <wm4> wow kfreebsd
[01:14] <durandal11707> wm4: there is fear that multithread audio decoding will eat betteries life
[01:15] <durandal11707> and its really not that important, as audio codecs are usually sane enough to be decoded in real time
[01:17] <durandal11707> exluding extreme cases like als
[01:20] <pengvado> Daemon404: fixed
[01:20] <Daemon404> i saw
[01:30] <durandal11707> wm4: also there are some small issues with it (same with video) that i'm not really motiviated to fix right now
[01:30] <wm4> what issues
[01:31] <durandal11707> if error happens when decoding some frame it may not be reported at all
[01:31] <durandal11707> also pts/dts may be wrong for broken files
[01:32] <durandal11707> same issues are present for video decoding too
[01:32] <wm4> that kind of sucks
[02:23] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:ae038c091446: vorbisdec: propagate errors from setup_classifs()
[02:23] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:709cae2bcbc0: vorbisdec: Check VLC tables during use instead of setup
[02:34] <cone-914> ffmpeg.git 03Loren Merritt 07master:1221bb623978: x86: lpc: fix a segfault in av_evaluate_lls_sse2()
[02:34] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:4e488ac5f5c0: Merge remote-tracking branch 'qatar/master'
[02:34] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:a6e46ed51ab9: Revert "avutil/x86: disable ff_evaluate_lls_sse2() for 32bit"
[02:47] <cone-914> ffmpeg.git 03Marton Balint 07master:447d2e31d167: ffplay: use frame->pkt_pts instead of pkt->pts in audio pts calculation
[02:48] <cone-914> ffmpeg.git 03Marton Balint 07master:02fc61a5a683: ffplay: always send zero packets to flush audio decoders
[02:48] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:ec837a08993d: Merge remote-tracking branch 'cus/stable'
[03:31] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:b42bcaef29e6: Avoid a null pointer dereference in avcodec_decode_audio4().
[04:09] <ubitux> http://lucy.pkh.me/test.swf  generated with ffmpeg \o/
[04:17] <Daemon404> interesting choice of video
[04:18] <ubitux> :)
[04:18] <Daemon404> somewhat mesmerizing
[04:18] <ubitux> i'm actually porting my "html loops" into swf
[04:19] <Daemon404> to be less portable?
[04:19] <ubitux> well my html loops were/are buggy with firefox
[04:19] <ubitux> anyway, i wasn't able to find decent tools to generate swf, so i had to patch ffmpeg :P
[04:19] <Daemon404> o
[04:20] <ubitux> portability is overrated anyway
[04:20] <ubitux> people stupid enough to want to watch braindead loops will make the effort to install a flash plugin :)
[04:21] <ubitux> Daemon404: you recognize the source of the video?
[04:21] <Daemon404> no
[04:28] <ubitux> you disappoint me
[09:37] <cone-792> ffmpeg.git 03Jean Delvare 07master:16fd75ceec1d: lavfi/delogo: use weighted interpolation
[10:42] <JEEB> michaelni, thanks for fixing 2720 :)
[10:46] <wm4> meanwhile we're discussing about removing mplayer's demux_ts from mpv, but we can't because it's better than ffmpeg's
[10:53] <JEEB> switch to VLC's instead nîn
[11:23] <nevcairiel> wm4: define "better"? I've had no real issues with the ffmpeg ts demuxer
[11:26] <wm4> nevcairiel: timestamp problems with tv caps
[11:26] <wm4> no proper playback is possible
[11:27] <nevcairiel> curious that i haven't heard anything, you wouldn't happen to have a file handy would you?
[11:37] <cone-792> ffmpeg.git 03Luca Barbato 07master:7388c0c58601: indeo: Properly forward the error codes
[11:37] <cone-792> ffmpeg.git 03Michael Niedermayer 07master:43229d609a17: Merge commit '7388c0c58601477db076e2e74e8b11f8a644384a'
[11:38] <wm4> nevcairiel: he says later
[11:45] <cone-792> ffmpeg.git 03Luca Barbato 07master:dd3754a48854: indeo: use proper error code
[11:45] <cone-792> ffmpeg.git 03Michael Niedermayer 07master:280afa40bcf5: Merge commit 'dd3754a48854cd570d38db72394491aab0f36570'
[12:03] <cone-792> ffmpeg.git 03Luca Barbato 07master:1194a410807b: indeo5: reject negative motion vectors
[12:03] <cone-792> ffmpeg.git 03Michael Niedermayer 07master:cc53c28fdc2b: Merge commit '1194a410807bac3eafbeb632578b937656d273e7'
[12:12] <cone-792> ffmpeg.git 03Luca Barbato 07master:b36e1893ef34: indeo: check for reference when inheriting mvs
[12:12] <cone-792> ffmpeg.git 03Michael Niedermayer 07master:38f1d5676918: Merge remote-tracking branch 'qatar/master'
[16:01] <cone-608> ffmpeg.git 03Stefano Sabatini 07master:7ebab4159a69: doc/encoders: apply various fixes to libmp3lame documentation
[16:42] <saste> wm4: libgme => fuc***ng awesome
[18:05] <saste> ubitux: ping
[18:07] <saste> uh? and now why avfiltergraph.h was merged into avfilter.h?
[18:07] <saste> i wish people would be doing real work rather than shuffling things around
[18:08] <ubitux> saste: pong
[18:08] <saste> ubitux: about the avfiltergraph_ thing
[18:10] <saste> so i propose this: is avfilter_graph_parse() deprecated in l.?
[18:10] <saste> discard the first part above
[18:11] <saste> we can restore lavfi compatibility, but at the next bump
[18:12] <ubitux> wasn't avfilter_graph_parse() version supposed to be useful in some circumstances?
[18:12] <ubitux> but well yeah i guess that's ok
[18:12] <saste> ubitux, no
[18:12] <saste> the new function (avfilter_graph_parse2()) is more versatile
[18:13] <ubitux> i dont think the fork deprecated the v1
[18:13] <saste> indeed it superceded avfilter_graph_parse(), then l. reimplemented it, but without a wheel (no way to set log_ctx)
[18:15] <saste> do you see better solutions?
[18:15] <saste> do you propose to bump libavfilter just after release?
[18:16] <ubitux> carl was proposing to use the api incompatible fork macro
[18:16] <ubitux> abi*
[18:16] <saste> ETOOBORINGWORK
[18:17] <ubitux> well, using that macro make the code immediately compatible
[18:17] <ubitux> and then we can consider a slow api break for the function
[18:17] <ubitux> slow and proper*
[18:17] <saste> note that i personally don't care about fork compatibility, so i'm going to do my proposal and just let people who want it fixed to improve it
[18:17] <ubitux> don't ask me then ;)
[18:19] <saste> ubitux, how can an API break be "slow"??
[18:21] <ubitux> long deprecated phase
[18:21] <nevcairiel> deprecate now, delete in 10 years
[18:23] <saste> socis folks still didn't publish accepted organizations
[18:25] <saste> does someone know if nicolas bertrand is available on irc?
[18:27] <ubitux> BuxiNess?
[18:27] <Compn> saste : shuffling things around is real work. how else are you going to increase commit numbers? :P
[18:28] <saste> Compn, why? can't you just reindent stuff here and there?
[18:30] <Compn> cosmetics dont count!
[18:30] <BuxiNess> ubitux, yes and hello
[18:31] <ubitux> hello, it seems saste want you
[18:31] <BuxiNess> yes
[18:33] <BuxiNess> And btw , made ffmpeg comparsion of native decoder and libopenjpeg
[18:34] <BuxiNess> libopenjpeg is faster, with threading enabled. I have much more context switch in native decoder than libopenjpeg. This it can be realted?
[18:35] <BuxiNess> realted/related
[19:21] <saste> wow avfilter_parse_graph2() docs is *confusing*
[19:25] <Compn> BuxiNess : how much faster ?
[19:27] <durandal_1707> +1
[19:31] <saste> ubitux, and it turns out that avfilter_parse_graph2() adopts a different logic with respects to our avfilter_parse_graph()
[19:34] <saste> ubitux, help me to find an alternative name for our modified avfilter_graph_parse()
[19:35] <ubitux> avfilter_graph_parsep
[19:35] <saste> avfilter_graph_parse_ptr()?
[19:35] <ubitux> whatever yeah
[19:35] <ubitux> i think it was suggested to simplify that whole interface anyway
[19:35] <ubitux> at least wm4 was looking forward this
[19:36] <saste> one problem at a time
[19:36] <saste> let's first restore binary compatibility
[19:36] <saste> after that we'll have three functions, of which we really need just one
[19:37] <saste> the other ones being libav-compatibility cruft
[20:19] <Daemon404> hey nevcairiel 
[20:20] <Daemon404> why do you label dirac as VC-2 in lav?
[20:20] <Daemon404> vc-2 is just intra only dirac...
[20:20] <nevcairiel> thats the name field of the AVCodec
[20:20] <Daemon404> O.o
[20:20] <Daemon404> weird.
[20:21] <nevcairiel> .long_name      = NULL_IF_CONFIG_SMALL("BBC Dirac VC-2"),
[20:21] <JEEBsv> yup
[20:46] Action: Daemon404 wonders why AV_QSORT exists
[20:57] <cone-965> ffmpeg.git 03Michael Niedermayer 07master:b791a0831b0a: avcodec/x86/dsputil_init: only use xvid idct for lowres=0
[21:00] <Daemon404> .....
[21:00] <Daemon404> b791a0831b0a027e7ba4eb6961cc0180472ac603 is fuckign bullshit
[21:00] <Daemon404> and is api breakage
[21:00] <Daemon404> youre changing behavior of a public api
[21:01] <Daemon404> and thats not fix, thats a shitty hack
[21:01] <michaelni> Daemon404, ?
[21:01] <Daemon404> people who set idct algo ti xvid's will not get the same behavior as before
[21:01] <Daemon404> it i settable via api
[21:02] <michaelni> behavior before was to crash
[21:02] <michaelni> xvid idct is 8x8
[21:02] <michaelni> for lowres > 0 you need 4x4 or smaller
[21:02] <Daemon404> er... fuuuuuuuuck
[21:02] <Daemon404> is misread that as lowres!=0
[21:02] <Daemon404> carry on
[21:02] <Daemon404> im retarded
[21:02] <Daemon404> sorry
[21:03] <Daemon404> (although i dont know of anyone actually using lowres)
[21:13] <superware> hi michaelni
[21:13] <michaelni> hi superware 
[21:19] <superware> michaelni: I was wondering whether you'll like to test my challenging mpegts stream :) to verify there aren't any further issues.
[21:38] <michaelni> superware, you can apply the patchset, compile and test it yourself if you want or wait until it is reviewed & applies
[21:38] <michaelni> applieD
[21:53] <superware> michaelni: but I saw the patch was applied, wasn't it?
[21:54] <durandal_1707> wan't it on mailig list?
[21:54] <superware> it was
[21:55] <durandal_1707> than its easy to check if its applied
[21:56] <Daemon404> https://github.com/openembedded/oe-core/blob/master/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/lower-rank.diff
[21:56] <Daemon404> does this seem useful to us?
[21:57] <Daemon404> wait im dumb
[21:57] <Daemon404> thats for gstreamer
[21:57] <Daemon404> derp
[21:57] <superware> durandal_1707: ok, I see mpegts.c was applied, but aviobuf.c and avio_internal.h not
[21:58] <superware> durandal_1707: hmmm maybe none was applied
[21:59] <superware> durandal_1707: can you help me test it?
[21:59] <superware> (the stream)
[21:59] <durandal_1707> i have paypal
[22:00] <superware> heh, with enough credit, I hope
[22:02] <superware> durandal_1707: what's the avg review & apply time from patchset?
[22:03] <Daemon404> pretty quick
[22:03] <Daemon404> assuming responses
[22:04] <superware> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-June/145286.html and the two following had no responses, right?
[22:16] <superware> thanks, bye
[23:25] <Rathann> hm apparently nobody tested --enable-libcdio with libcdio not installed
[23:26] <Rathann> the check doesn't bail out of configure if it fails
[23:26] <durandal_1707> EPATCHWELCOME
[23:27] <Rathann> sure
[23:27] <Rathann> :)
[23:32] <Rathann> correction, it's fixed in master already
[23:36] <Compn> ah yes, the uav bugreport i trolled
[00:00] --- Tue Jul  2 2013