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

[burek]

[00:50] <ubitux> BBB: what does "fm" stands for?
[00:50] <ubitux> same question for the E, I and H threshold
[00:54] <ubitux> btw, should i add threading to the coverage fate instance?
[21:20] <durandal_1707> michaelni: what's about those mans commits reverts from yadif?
[21:21] <durandal_1707> exp. "lavfi: convert input/ouput list compound literals to named objects" is pathetic
[21:21] <durandal_1707> how such changes could be considered to have copyright
[21:22] <durandal_1707> does it means I can not change it back?
[21:23] <nevcairiel> you can change it back, you just cant copy the commit
[21:23] <wm4> what if the new change is almost literally the same as the old change? because it's trivial and there's no other way to do it?
[21:23] Action: durandal_1707 was there any group lobotomy recently?
[21:24] <nevcairiel> if you want to do it right, then dont look at the commit, just take the code and make it look good again. if you come to the same exact result in the end, there is no copyright violated
[21:25] <nevcairiel> oif course someone could still claim that
[21:25] <nevcairiel> but good luck in a court
[21:25] <wm4> copyright sure is a strange thing
[21:25] Action: durandal_1707 takes gun
[21:33] <durandal_1707> K&R is copyrighted too?
[21:34] <nevcairiel> i doubt its possible to win a copyright fight on whitespace changes
[21:34] <nevcairiel> but if in doubt, easier to revert one commit and re-format the code later
[21:49] <cone-359> ffmpeg.git 03Diego Biurrun 07master:3cd612d44789: gitignore: Ignore multilibrary example programs
[21:49] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:d4268634155d: Merge commit '3cd612d44789948f72b52944474e0870c5c60964'
[21:56] <cone-359> ffmpeg.git 03Diego Biurrun 07master:7b05845b1523: doc: Try to find nonstandard Perl path from the environment
[21:56] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:003f405caf9f: Merge remote-tracking branch 'qatar/master'
[22:11] <ubitux> BBB: the most annoying part is the !flat 1/2B case at the end :p
[22:16] <nevcairiel> this donmoir person sure has some deranged views on things
[22:17] <ubitux> why is he talking about avresample now?
[22:17] <ubitux> oO
[22:17] <ubitux> wth is going on in this thread
[22:19] <ubitux> > the interface avpicture_delinterlace is elegantly simple
[22:19] <ubitux> what am i reading
[22:19] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:b2c89453dcc1: avformat/avisynth: remove duplicate av_new_packet() call
[22:20] <nevcairiel> apparently API simlicity and resource usage are more important to him then actual deinterlacing quality
[22:23] <nevcairiel> because the avpicture_deinterlace is really quite terrible
[22:23] <nevcairiel> its a simple field blend, iirc
[22:25] <wm4> he also complains about how yadif is "twice as slow"
[22:27] <Compn> saste : bcourdurier is busy with ffmbc :)
[22:28] <BBB> maybe I'll split vp8dsp.asm also
[22:28] <nevcairiel> creating a filtergraph may need more boilerplate then necessary, but the actual filtering of the frames is not that bad (once you figured out how to interact with the buffer source/sink), not sure what goes on in his head :)
[22:28] <ubitux> BBB: isn't it already split?
[22:28] <nevcairiel> i thought diego split the loopfilter out or something
[22:28] <ubitux> i thought diego did the split
[22:28] <ubitux> ah, only lpf
[22:29] <nevcairiel> admittedly the loopfilter is more asm then all that remains
[22:29] <j-b> ah, nice, finally the reverts
[22:30] <Compn> what flame level are we at now ?
[22:30] Action: Compn goes to read mailing list
[22:30] <nevcairiel> amazingly, the whole thread seems to stay quite clam @ deint discussion on the list
[22:30] <nevcairiel> calm*
[22:35] <wm4> to be fair, as much as the deint function sucks, there's no reason to actually remove it
[22:35] <wm4> it could be dumped into libpostproc or something instead
[22:35] <Compn> you mean the original deint stuff ?
[22:35] <Compn> for people who dont want to use lavfi ? 
[22:35] <Compn> sure 
[22:35] <wm4> the lavc one
[22:35] <nevcairiel> it should be removed from avcodec, if you want to preserve it in a code grave like postproc .. go ahead
[22:36] <ubitux> Compn: no, just for don moir
[22:36] <Compn> lol
[22:36] <wm4> actually I think libpostproc has some deinterlacers too...
[22:36] <ubitux> it has indeed
[22:37] <nevcairiel> ever since yadif got slice threading, I havent had any speed complaints anymore
[22:37] Action: Compn wonders if software will be advertising the fact that it has the amazing 'yadif deinterlacer' in the future
[22:37] <Compn> heh
[22:37] <Compn> has anyone ever done double blind deint comparasion ?
[22:38] <Daemon404> yadif isnt amazing
[22:38] <Daemon404> people use it because its realtime
[22:38] <nevcairiel> yeah, anything really better is just extremely slow
[22:39] <Compn> i'd agree with you except its the only deint i've seen anyone talk about in the past 5+ years
[22:39] <Daemon404> you mstnt go on doom9 much
[22:39] <Daemon404> QTGMC has been king for ages
[22:39] <Compn> not with the security in their forums :P
[22:39] <Daemon404> lol
[22:39] <Daemon404> theyre on vb from like 2006
[22:39] <Daemon404> its awesome
[22:39] <nevcairiel> QTGMC is pretty good, but also pretty slow
[22:39] <Daemon404> 0 fucks given
[22:40] <Compn> not that i use real passwords anywhere anyway
[22:40] <Compn> nor real emails, real names, real info of any kind
[22:52] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-lpf#diff-f5653acbc04f21d22eaa6bfd4954e66eR107
[22:52] <ubitux> i wonder if i'm doing this right&
[23:30] <ubitux> BBB: we can't mux vp9 ivf with ffmpeg?
[23:48] <BBB> ubitux: I've never tried
[23:51] <ubitux> ok
[23:51] <ubitux> BBB: not sure if it's broken on purpose but libvpx/vp90-2-07-frame_parallel.webm has artifacts at the end
[23:52] <BBB> ?
[23:52] <BBB> not sure
[23:52] <ubitux> (same for libvpx/vp90-2-05-resize.ivf btw)
[23:53] <BBB> resize is not supported
[23:53] <ubitux> ok
[23:54] <ubitux> anyway, lpf in progress, i'll probably be done at the end of the month
[23:54] <ubitux> gtg, 'night
[23:54] <BBB> g'nite
[00:00] --- Mon Dec  2 2013