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

[burek]

[02:48] <cone-137> ffmpeg.git 03James Almer 07master:d59213b5d345: matroskaenc: Bump DocTypeVersion to 4
[03:46] <cone-137> ffmpeg.git 03Michael Niedermayer 07master:529540759f28: avcodec/simple_idct_template: adjust coeffs for 12bit idct
[11:48] <cone-727> ffmpeg.git 03Timothy Gu 07master:0e11790cf7ee: doc/encoders: add doc for AAC encoder
[11:48] <cone-727> ffmpeg.git 03Timothy Gu 07master:81bbe49a0e58: doc/encoders: improve libvo-aacenc doc
[12:08] <cone-727> ffmpeg.git 03Diego Biurrun 07master:9997a812e769: mem: Document the non-compatibility of av_realloc() and av_malloc()
[12:08] <cone-727> ffmpeg.git 03Michael Niedermayer 07master:61b3b5872019: Merge remote-tracking branch 'qatar/master'
[13:07] <cone-727> ffmpeg.git 03James Almer 07master:5ab7b3b9481e: matroskadec: Mute "Unknown entry" log messages for CueRelativePosition entries
[13:09] <cone-727> ffmpeg.git 03Paul B Mahol 07master:211a185cba78: avfilter/avfilter: check allocation failure in ff_insert_pad()
[13:16] <cone-727> ffmpeg.git 03Compn 07master:a06e20888dbc: changelog: add ffv1 yuva and dts streamid change
[13:20] <durandal_1707> Compn: don't kill newlines
[13:22] <Compn> ehe
[13:22] <Compn> merges are now forbidden, how do i flatten the git history ?
[13:22] <Compn> if someone commits between my git pull and my git push , my tree isnt 'fast forward' ...
[13:22] <ubitux> git pull --rebase
[13:23] <ubitux> or rebase manually properly
[13:23] <Compn> thx
[13:23] <Compn> mmmm
[13:23] <ubitux> aka keep your master clean
[13:23] <ubitux> and rebase your devel branch onto your master
[13:24] <Compn> just want to add a line to changelog, dont want to fuss :P
[13:24] <Compn> durandal_1707 : try to document changes in changelog :)
[13:24] <Compn> the ffv1 yuva was your commit
[13:28] <durandal_1707> Compn: if i document such changes Changelog would be 10mb in size
[13:29] <durandal_1707> see git log
[13:33] <durandal_1707> any more comments for adelay filter?
[13:33] <durandal_1707> if you did not notice yet, similar/but worse filter is in libaf of mplayers
[13:38] <Compn> i havent looked at it
[13:38] <durandal_1707> in mplayer?
[13:38] <Compn> its just for delaying audio a few seconds ?
[13:38] <Compn> -delay and -af delay 
[13:38] <Compn> i used it once or twice 
[13:39] <Compn> but i think the problem was fps detection, not actual audio offset :(
[13:40] <durandal_1707> you use it if your speakers are far a way from you and you want that sounds of all speakers come at same time to you
[13:40] <durandal_1707> that is what mplayer manual says
[13:55] <Compn> oh, kind of a doppler thing 
[13:55] <Compn> ?
[13:55] <Compn> or something
[13:56] <nevcairiel> its basically room correction, comensating for delay due to long speaker cables and distance to speakers, and stuff like that, although the real challenge is measuring the required differences
[13:57] <Compn> sounds difficult to measure and setup
[13:57] <nevcairiel> there is software to measure that with accurate micrphones
[13:57] <nevcairiel> +o
[13:58] <nevcairiel> but you'll most likely need such a mic
[14:00] <durandal_1707> isn't that for reverb?
[14:11] <cone-727> ffmpeg.git 03Paul B Mahol 07master:60abdb6c17ea: avfilter/af_aecho & af_compand: use extended_data
[14:30] Action: pippin believes in delay due to distance to speakers; not long audio cables though :d
[14:31] <pippin> (perceivable delay that is)
[14:43] <nevcairiel> very long cables? :d
[14:55] <j-b> Isn't it the time already to drop the qatar joke?
[15:00] <durandal_1707> you waited for michaelni to leave to ask question?
[15:08] <Daemon404> j-b, did you see what i pasted to you yesterday in the Other Channel?
[15:08] <Daemon404> about ibc/vlc
[15:10] <durandal_1707> do you mind to share it with us here?
[15:11] <Compn> j-b : it makes things easier to search for in git log
[15:11] <Compn> having a different name
[15:11] <Compn> try searching for 'libav' 
[15:11] <Daemon404> durandal_1707, 
[15:11] <Daemon404> [16:41] < jermy> There's a rather condescending poster from Cinegy here at IBC that says "If you're using VLC for your production workflow, then you're doing it wrong."
[15:11] <Compn> only about half of the results
[15:11] <Daemon404> [16:42] < jermy> If it works, and does the job cheaper than their software, the who cares. Grr
[15:11] <Daemon404> [20:10] < Daemon404> jermy, forarding to j-b
[15:11] <Daemon404> (sorry to hilight you so much btw)
[15:12] <Compn> j-b : suggestions welcome for new merge name
[15:13] <durandal_1707> that is nonsense
[15:13] <durandal_1707> use libav
[15:13] <Daemon404> yes
[15:13] <durandal_1707> is it hard to search for "libav/master"?
[15:13] <Daemon404> agree.
[15:14] <nevcairiel> this whole discussion is nonsense
[15:14] <nevcairiel> who cares how michael names his remotes
[15:14] <Daemon404> nevcairiel, of course it is
[15:15] <Daemon404> you can never have too many things to bikeshed
[15:15] <Daemon404> !
[15:15] <durandal_1707> it appears to hurt people feelings
[15:16] <Compn> everything hurts feelings now it seems
[15:16] <Compn> merging any commit without sending patches back 
[15:16] <Compn> michael still banned on libav lists
[15:16] <Daemon404> that was not to do with merging
[15:17] <Daemon404> anyway, ill just say my usual "you're all children" line and sip my coffee
[15:17] Action: Daemon404 vanishes into the bg
[15:17] Action: ubitux is more bugged about the opencl patch thing with the capitalization nonsense blocking a braindead patch since days
[15:17] <Compn> just commit it then
[15:17] Action: durandal_1707 hollow earth
[15:17] <Compn> stomp on the capitalization people
[15:17] <Compn> they can bikeshed after its in
[15:17] <ubitux> they won't
[15:17] <Compn> then theres no issue :)
[15:18] <ubitux> they will forget it a few minutes after
[15:19] <durandal_1707> libavfilter/vf_pullup.c  | 777 +++++++ -> will leave it to that line number
[15:20] <Daemon404> more to teh point
[15:20] <Daemon404> does opencl implement anythng /useful/ yet?
[15:20] <Compn> needed for dcp 4k support ?
[15:21] <Compn> 4k support in general...
[15:21] <Daemon404> eh?
[15:21] <Daemon404> afaik we only use opencl for some simple lavfi filters
[15:21] <Daemon404> like an unsharp mask
[15:22] <durandal_1707> i do not like how it is done in lavfi
[15:23] <Daemon404> of course
[15:23] <Daemon404> it is lavfi.
[15:23] Action: Daemon404 runs
[15:24] <Compn> Daemon404 : there are some chinese devels who want some opencl stuff
[15:24] <Compn> i mean are working on opencl stuff
[15:24] <Daemon404> i know
[15:24] <Daemon404> likely for marketting
[15:24] <Compn> i guess h265 also ?
[15:24] <Compn> lol
[15:24] <Daemon404> opencl is not used in any decoders
[15:24] <Daemon404> nor is it terribly useful
[15:24] <Daemon404> for such things
[15:24] <nevcairiel> all these gpu things are only good for processing, ie. tasks you can run massively in parallel
[15:25] <Daemon404> you could implement w3fdif in gpu probably
[15:25] <Daemon404> :P
[15:25] <Daemon404> since it's a convolution with no deps
[15:33] <michaelni> nevcairiel, do you still have objections to "[FFmpeg-devel] [PATCH] avfilter: avoid testing float == 0" ?
[15:36] <nevcairiel> no
[15:38] <michaelni> ok, thx
[15:44] <durandal_1707> so how long is timeout for maintainer review? 5 minutes?
[15:44] <durandal_1707> you could just ping it
[15:45] <durandal_1707> there is not thing that tracks sent patches
[15:47] <cone-727> ffmpeg.git 03Michael Niedermayer 07master:3dfc5f551f4c: avfilter: avoid testing float == 0
[15:47] <cone-727> ffmpeg.git 03Michael Niedermayer 07master:e428632c1a46: avcodec/jpeg2000dec: print invalid cdx/y values
[15:49] <Daemon404> durandal_1707, some projects say you should cc maintainers
[15:49] <Daemon404> so they dont miss the patch
[15:49] <Daemon404> but that would likely anger ours.
[15:54] <michaelni> durandal_1707, i did ping the patches, a little less than a month ago
[15:54] <michaelni> and later via IRC
[15:54] <michaelni> Daemon404, see our MAINTAINERs file, every maintainer can individually in it request to be CC-ed
[15:54] <durandal_1707> ok, it is trivial anyway ....
[15:55] <Daemon404> michaelni, oh
[15:55] <Daemon404> i should add that then
[15:55] <Daemon404> because i liked to be CC"d on my stuff
[15:55] <michaelni> of course theres a non 0 chance people forget setting CC ...
[15:56] <Daemon404> its close to 1.0 probability they forget
[16:09] <j-b> Daemon404: no, sorry, I did not.
[16:09] <j-b> Compn: just call is libav/master
[16:09] <j-b> nevcairiel: it appears in all commit logs, so yes, it mastters
[16:09] <j-b> -s
[16:10] <Daemon404> j-b, well did you see my repaste?
[16:10] <j-b> Daemon404: I? in the thalys... irc over ssh is slow...
[16:10] <j-b> Daemon404: yes, seen.
[16:10] <Daemon404> ok
[16:10] <Daemon404> i thought they were kinda being dicks about vlc there
[16:11] <j-b> Daemon404: I will take care of that right now, with my people on the place still
[16:11] <Daemon404> j-b, hit squad?
[16:11] <j-b> Daemon404: yes.
[16:11] <Daemon404> :D
[16:11] <j-b> Daemon404: I had a fight with 2 fraunhoffer guys, 2 x264 gpl violators and one ffmpeg violatro
[16:11] <Daemon404> ooohhh
[16:12] <Daemon404> next ibc you can star ta fight club
[16:12] <j-b> and I had a discussion with DTS :)
[16:12] <Daemon404> nobody has "discussions" with dts
[16:12] <j-b> and mentionned to ETSI and DVB that Dolby is not respecting their FRAND clauses
[16:12] <Daemon404> theyre never just "discussions"
[16:13] <j-b> and DVB did not like that at all
[16:13] <Daemon404> "j-b: IBC Trolling"
[16:16] <j-b> not really trolling.  OUr licenses must be respected.
[16:16] <Daemon404> fair enough.
[16:16] <Daemon404> you should tell corecodec that.
[16:16] <j-b> our licenses are our social contracts
[16:17] <j-b> so, if you don't respect our licenses, you don t respect our projects and persons
[16:17] <JEEB> :)
[16:17] <j-b> Daemon404: I will.
[16:17] <JEEB> and yes, DVB most probably is saner about people respecting their FRAND clauses
[16:17] <JEEB> let's hope it leads to something :)
[16:18] <j-b> Daemon404 people already consider me as an agrresive ass. So be it.
[16:18] <j-b> JEEB: I've asked the  lawyers that fought MS at the European court how we could attack Dolby
[16:19] <Daemon404> j-b, people consider me an agressive ass (i am)
[16:41] <j-b> 16:16 <@j-b> our licenses are our social contracts
[16:41] Last message repeated 1 time(s).
[16:41] <j-b> End of Lastlog
[16:42] Last message repeated 2 time(s).
[16:42] <Daemon404> what?
[16:42] <cone-727> ffmpeg.git 03Michael Niedermayer 07master:821a5938d100: avcodec/g2meet: Fix order of align and pixel size multiplication.
[16:42] <j-b> Daemon404: oops :)
[16:43] <j-b> Stupid internet connection
[17:46] <wm4> j-b: would it make sense to port vlc's .ts demuxer to libavformat?
[17:46] <Daemon404> isnt it gpl
[17:48] <wm4> who cares
[17:48] <nevcairiel> didnt vlc relicense most everything of their playback engine to lgpl
[17:48] <wm4> license header seems to say lgpl
[17:49] <wm4> libdvbpsi is lgpl as well
[17:49] <wm4> but who knows how many parts of vlc the demuxer (ts.c) pulls in
[17:51] <Daemon404> youre pretty much doomed to fail with .ts regardless of whose code you use
[17:51] <Daemon404> especially for seeking
[17:55] <nevcairiel> there is too many use-cases for TS for one "perfect" generic solution
[17:56] <wm4> yeah, but vlc still performs much better on average
[17:56] <nevcairiel> on average, i have no issues
[17:57] <nevcairiel> there is the occasional thing that doesn't work, but pretty rare, in my experience
[18:03] <wm4> looks like pretty much ignoring timestamps coming from the ts demuxer would improve things for me a lot
[18:03] <nevcairiel> never had any issues with those, also, they just come from the file :)
[18:45] <j-b> wm4: maybe
[18:45] <j-b> Daemon404: it is LGPL
[20:18] <kierank> Daemon404: ts seeking only works with an aux file
[20:20] <Daemon404> i assume that some sort of index
[20:21] <kierank> yes
[20:21] <Daemon404> thats true for many formats in lavf
[20:21] <Daemon404> hence ffms2 exists
[20:22] <wm4> for use with a video player, relative seeks would be good enough, which I believe could be handled even with a ts
[20:23] <Daemon404> (filesize / duration) * seekpoint duh
[20:32] <nevcairiel> using a binary search for the timestamp works OKish on local files
[20:32] <nevcairiel> assuming the file has timestamps, anyway
[20:33] <nevcairiel> but most actually do, even if some people claim that TS is not a format with timestamps :p
[20:37] <Daemon404> i thought 188byte ones do not
[20:37] <cone-727> ffmpeg.git 03Michael Niedermayer 07master:4f1a17b1a965: avcodec/c93: force dimensions to the correct value instead of depending on the demuxer to do so
[20:37] <iive> pcr are quite precise for timestamp. 
[20:37] <nevcairiel> there is PTS and DTS in TS, the 4 byte extra are something extra
[20:38] <nevcairiel> one of the few formats that can actually encode both PTS and DTS
[20:38] <Daemon404> mp4 does too
[20:39] <Daemon404> or maybe it was just dts, i cant remember
[20:39] <nevcairiel> mp4 cheats, it encodes dts and an offset to make it pts or something
[20:40] <Plorkyeran> when do you actually need dts?
[20:40] <Daemon404> right
[20:40] <nevcairiel> possibly the other way around
[20:40] <Daemon404> Plorkyeran, maybe stupid hardware things
[20:40] <Daemon404> i dunno
[20:42] <Plorkyeran> I guess you could use it to replace dropped packets before the decoder rather than after the decoder or something?
[20:42] <Plorkyeran> sending a stream in non-dts order would be weird
[21:08] <cone-727> ffmpeg.git 03Paul B Mahol 07master:693747c3d09f: avfilter/vsrc_life: use av_calloc()
[21:08] <cone-727> ffmpeg.git 03Paul B Mahol 07master:24678a61d9f1: avfilter/vf_gradfun: use av_calloc()
[21:36] <cone-727> ffmpeg.git 03Clément BSsch 07master:04427182bc01: avcodec: typo fix sepera* ’ separa*
[21:53] <durandal11707> hmm pullup filter does not need decimate filter, than what pts i set?
[22:20] <cone-727> ffmpeg.git 03Clément BSsch 07release/2.0:59147be24f4b: avformat/srtdec: skip initial random line breaks.
[22:20] <cone-727> ffmpeg.git 03Clément BSsch 07release/2.0:dc0403530e3e: avformat/subtitles: add a next line jumper and use it.
[22:20] <cone-727> ffmpeg.git 03Clément BSsch 07release/2.0:2dc6c5d46221: avcodec/srtdec: fix potential overread.
[22:20] <cone-727> ffmpeg.git 03Clément BSsch 07release/2.0:0f429392cf41: avcodec/assenc: fix potential overread.
[22:21] <wm4> ubitux: would it be possible to add utf-16 support to subs? that's the only thing missing
[22:21] <ubitux> dunno
[22:21] <ubitux> beastd: thx
[22:22] <ubitux> wm4: it will require some negociation with nicolas
[22:22] <ubitux> ;)
[22:22] <wm4> ........
[22:22] <beastd> he :)
[22:22] <ubitux> he started something, i'm still waiting...
[22:22] <wm4> what he's planning to do is just bad
[22:23] <wm4> it'll lead to an increase of mojibake, if anything
[22:23] <Daemon404> hes out of touch with reality
[22:23] <wm4> or hideous workarounds to get around of it
[22:23] <Daemon404> wm4, this is what happens when you live in a bubble
[22:24] <Daemon404> and willingly ignore real api users
[22:24] <wm4> or if you think ffmpeg.c is the only API user worth caring about
[22:24] <Daemon404> he's also an original mplayer dev
[22:24] <Daemon404> 'nuff said?
[22:25] <beastd> Daemon404: WTF!
[22:25] <durandal11707> defend!
[22:25] <wm4> lol
[22:25] <Daemon404> i didnt even say anything bad about it
[22:26] <Daemon404> if you drew any conclusions
[22:26] <Daemon404> they were your own.
[22:26] <Daemon404> :)
[22:26] <beastd> Daemon404: I did not even say anything bad. If you drew any conclusions...
[22:26] <Plorkyeran> just require that all files be utf-8
[22:27] <Plorkyeran> who cares about silly things like playing actual files
[22:27] <Plorkyeran> much better to be pure and clean
[22:27] <durandal11707> well why not write something, instead of waiting godot
[22:27] <ubitux> haters army is back tonight .o/
[22:27] Action: beastd wonders how Daemon404 defines original mplayer dev
[22:27] <Daemon404> inbred
[22:28] <Daemon404> cannbalizing ffmpeg with their abomination, etc
[22:28] <durandal11707> huh
[22:28] <Daemon404> grep ffmpeg's source for 'mplayer'
[22:29] <Daemon404> or git logs
[22:30] <beastd> Daemon404: I think you are way off here. And I do not know what Nicolas has to do with it.
[22:31] <Daemon404> the mplayer dev says im off. shock.
[22:31] <Daemon404> anyway, it was a side quip, unrelated to nicolas' idiocy
[22:31] <durandal11707> i think mplayer devs are posinous for ffmpeg project because they add hacks for mplayer into ffmpeg codebase
[22:32] <beastd> durandal11707: Not sure when I did that.
[22:32] <ubitux> durandal11707: i think this happened once
[22:32] <durandal11707> see line 1329 in libavcodec/utils.c
[22:33] <beastd> also many things got into ffmpeg because rxt ported them from mplayer
[22:33] <ubitux> that one exactly
[22:33] <durandal11707> i talking about hacks to make mplayer work in situation such and such
[22:33] <ubitux> well mplayer is an api user
[22:34] <wm4> a pretty bad one
[22:34] <wm4> due to code rot etc.
[22:34] <ubitux> a largely used one nevertheless
[22:34] <ubitux> widely*
[22:38] <durandal11707> same as mencoder
[22:38] <iive> yeh, ffmpeg shouldn't be used by any video players, it must stay pure. Burn all players!! You can send them to the gas chambers first. ~~
[22:39] <durandal11707> no, you missed point. mplayer uses ffmpeg internals
[22:39] <j-b> 22:34 <@ubitux> a largely used one nevertheless
[22:39] <beastd> durandal11707: mencoder is unmaintained.
[22:39] <j-b> that's beside the point
[22:39] <j-b> VLC is a widely used one, so we should get special hacks too?
[22:39] <beastd> durandal11707: it may break at any time and we actively tell people to use sth else e.g. ffmpeg
[22:40] <durandal11707> but stop using internal ffmpeg stuff
[22:40] <wm4> j-b: the recent vdpau hwaccel refactor ended up quite hacky, and was for VLC only
[22:40] <j-b> wm4: which one?
[22:40] <ubitux> j-b: you need to find vlc lovers in ffmpeg dev first ;)
[22:40] <beastd> j-b: IIRC you go ones from time to time
[22:40] <j-b> beastd: it should not be the case.
[22:40] <wm4> j-b: removing the vdpau "special" decoder and using the hwaccel API
[22:40] <j-b> wm4: that's the proper route, from what I understood.
[22:41] <j-b> and not a hack
[22:41] <j-b> complete hwaccell decoders are easy to manage from a player perspective
[22:41] <wm4> maybe, but considering the hwaccel architecture is not exactly great and there's the opinion that it "should be improved", it was more like a pointless refactoring after all
[22:41] <j-b> wm4: in 2015 ?
[22:41] <j-b> wm4: in 2018 ?
[22:41] <wm4> yes
[22:42] <beastd> j-b: but it wasn't quite ready AFAIK. so reimar quickly extended the new API in hurry.
[22:42] <j-b> well, my biased opinion is that hwaccell shouldn't be part of libavcodec
[22:42] <wm4> it sure doesn't fit in well
[22:42] <wm4> it's a hacky mess
[22:43] <ubitux> don't use it/fix it?
[22:43] <nevcairiel> eh, having it separate would be worse
[22:44] <iive> i don't think that moving it to a separate library would be welcomed.
[22:44] <nevcairiel> you need all the magic of parsing the sequence parameters, and the frame reodering, and whatnot
[22:44] <nevcairiel> thats all internals to the decoders
[22:44] <iive> isn't it more like parsers?
[22:45] <j-b> more and more hw decoding libraries are full-decoding
[22:45] <iive> but they are in avcodecs too
[22:45] <nevcairiel> i dont trust those
[22:45] <nevcairiel> intels is perpetually broken
[22:45] <nevcairiel> and you have no chance to fix it
[22:46] <nevcairiel> the hardware only does slice decoding, everything else is just software from the vendor
[22:46] <nevcairiel> i prefer controlling the software and make sure it works
[22:46] <cone-727> ffmpeg.git 03Alexander Strasser 07master:069010ffaec1: lavf/subtitles: Make comment less arrogant
[22:47] <ubitux> beastd: :(
[22:47] <beastd> ubitux: huh?
[22:47] <wm4> the problem is that this hwaccel API is really low level
[22:47] <Daemon404> "quickly extended the new API in hurry" -- libav*, the abridged history
[22:47] Action: Daemon404 runs
[22:47] <nevcairiel> but of course i come from windows, where there actually is an API that works OKish, and more importantly, works for all vendors
[22:47] <wm4> trying to support hwaccel on all platforms is a nightmare for someone who is writing something new
[22:48] <wm4> maybe that's the nature of things, but still
[22:48] <beastd> Daemon404: IIRC the incomplete stuff was pulled from Libav fork
[22:48] <ubitux> beastd: you remove my little happiness :(
[22:48] <j-b> wm4: so I don't see why removing the full decoder is a hack
[22:48] <wm4> nevcairiel: it's not much different on Linux (without Intel and plastic devices) or OSX
[22:49] <wm4> j-b: it replaces one hack with another
[22:49] <beastd> ubitux: if you need a comment in ffmpeg to feel like having a sane system, then that makes me sad :(
[22:49] <j-b> I don't see why the hwaccell one is a hack
[22:49] <wm4> IMHO it also disimproved at least one minor aspect of it, but maybe that's just me
[22:49] <ubitux> beastd: :D
[22:49] <nevcairiel> what api does one use on linux? vdpau these days since amd started supporting it? before that, i heard nvidia didnt really like vaapi, so there was no unified one
[22:49] <Daemon404> qsv duh
[22:49] <Daemon404> any time now im sure.
[22:50] <nevcairiel> qsv is flawed because intels bitstream parser keeps being buggy :p
[22:50] <j-b> yep
[22:53] <wm4> nevcairiel: it used to be vdpau (nvidia), vaapi (intel), and a third one by amd
[22:53] <iive> XvBA ?
[22:54] <wm4> nevcairiel: but now mesa implemented vdpau, so all open source drivers are going to use vdpau
[22:54] <wm4> yes xvba
[22:54] <wm4> I'm not sure what's the state of the amd closed source drivers
[22:54] <j-b> and now qsv
[22:54] <wm4> but the open source ones are starting to become usable
[22:54] <wm4> fuck Intel and their NIH
[22:55] <iive> there is wrapper from xvba to vaapi.
[22:55] <iive> not sure how many of the quirks are caused by the wrapper or by the xvba itself.
[22:55] <wm4> AFAIK it sucks, like all those wrappers
[22:56] <nevcairiel> at least on windows intel seems to be moving closer to the "standard" DXVA, and don't need many custom hacks anymore with newer drivers on at least SNB or higher hardware
[22:56] <nevcairiel> but of course they still have qsv in parallel as well
[23:03] <Compn> so wait
[23:03] <Compn> you guys are against porting mplayer libvo to ffplay? :P
[23:03] <Compn> should we port vlc video system instead ?
[23:03] <Compn> honest question, i dont care either way
[23:07] <wm4> lol porting libvo
[23:08] <durandal11707> no porting needed, but from scratch
[23:08] <durandal11707> but first you need to actually write proper libavdevice api
[23:09] <Compn> so bikeshed a while, got it.
[23:10] <durandal11707> why mplayer still does not work with lavfi?
[23:10] <durandal11707> why they are still keeping their unmaintained filters?
[23:11] <Compn> its just reimar and carl left mostly
[23:11] <Compn> iive still kicking too
[23:11] <Compn> does that old lavfi patch still work ?
[23:11] <wm4> mplayer has a vf_lavfi
[23:11] <wm4> not sure if it works, maybe not
[23:11] <Compn> its disabled by default i think
[23:11] <Compn> in configure
[23:12] <wm4> it uses libavfilter internals, but the way mplayer uses ffmpeg, that should not be the problem
[23:12] <Compn> ehe
[23:12] <Daemon404> wm4, ... is that new coddee?
[23:12] <Daemon404> code*
[23:12] <Compn> the problem was a lot of refactoring of api
[23:12] <wm4> mo, few years old
[23:12] <wm4> *no
[23:12] <iive> i'm mostly hanging around, no kicking.
[23:12] <durandal11707> lot?
[23:12] <Daemon404> ic
[23:13] <wm4> yeah, added 2 years ago
[23:13] <iive> well, there is sense in waiting for ffmpeg api to stabilize a little before starting to use complicated stuff
[23:13] <wm4> "    Some strange behaviours may appear due to the very different model of buffer allocation between mplayer and lavfi."
[23:14] <durandal11707> is mplayer using refcounting?
[23:14] <iive> it uses ref
[23:17] <wm4> mplayer has its own awkward form of refcounting, which is called direct rendering
[23:17] <iive> it allows filters to work in same buffer
[23:17] <wm4> this "numbered mpi" stuff is basically refcounting, and DR fulfills some of the same tasks as refcounting does
[23:18] <wm4> it's pretty confusing and not even reimar has gotten it right yet, apparently
[23:18] <iive> i used to know it well, but i've forgotten most of it.
[23:18] <durandal11707> ugh what a mplayermess i'm going to remove right now from lavfi
[23:20] <iive> ?
[23:21] <durandal11707> you gonna see it soon, oh how i enjoj executing rm
[23:21] <wm4> he means the libmpcodecs slave treadmill
[23:21] <iive> i'm afraid I won't.
[23:21] <ubitux> durandal11707: you rocks :)
[23:22] <iive> oh, you finally ported all the filters?
[23:22] <Compn> yes! rm mp_help-en.h! :)
[23:24] <wm4> oh nice, vf_pullup ported
[23:24] <wm4> I heard claims that it was some of the more useful filters
[23:25] <iive> yeh, dalias wrote it. too bad he never got to improve it. could have been even better.
[23:29] <durandal11707> 4 files changed, 2195 deletions(-)
[23:30] Action: wm4 still sees two eq filters
[23:31] <iive> two?
[23:31] <wm4> the remaining filters should all be trivial, except the *pp* ones
[23:31] <wm4> iive: vf_eq.c and vf_eq2.c
[23:32] <iive> afair eq2 could do everything eq does.
[23:32] <wm4> yeah
[23:32] <iive> somebody even wanted it removed from mplayer... just checked if it still exists.
[23:36] <iive> is there color correction filter in lavfi?
[23:36] <iive> i see colorbalance and colormatrix and they don't seem to have the same functionality.
[23:37] <durandal11707> what you mean by color correction?
[23:39] <iive> hue saturation, contrast, brightness
[23:40] <durandal11707> hue can do that, except contrast and gamma but that is trivial to add...
[23:40] <durandal11707> that is just lut
[23:41] Action: iive facepalms
[23:42] <cone-727> ffmpeg.git 03Michael Niedermayer 07master:b4a5fcb9988c: avcodec/mjpegdec: Fix rgb48 ljpeg
[23:43] <iive> oh, i forgot gamma.
[23:45] <durandal11707> removing mplayer help from lavfi........
[23:45] <cone-727> ffmpeg.git 03Paul B Mahol 07master:7ac6c6325e03: libavfilter/libmpcodecs: remove unused files
[23:47] <wm4> wow why was that file even there
[00:00] --- Mon Sep 16 2013