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

[burek]

[00:36:14 CEST] <philipl> For everyone's general amusement: I managed to carefully double the height of various vdpau elements (video surface, decoder, mixer) while keeping the output size unchanged. Then if I render only the 'top field' of the hevc frame, it provides the decoded frame correctly. If course, this prevents 4k video from being decoded as the maximum decoder height is capped.
[03:20:02 CEST] <Compn> wm4 : is asf-new the default asf demuxer in mpv now ?
[03:20:31 CEST] <Compn> i forgot what the testing protocol was when mplayer was testing new lavf features. 3 months? 6 months?
[03:20:47 CEST] <cone-242> ffmpeg 03George Boyle 07master:02bd4d93c9df: fate/api-tests: Added dependency on $(FF_DEP_LIBS)
[03:20:47 CEST] <cone-242> ffmpeg 03Ludmila Glinskih 07master:ca3b27455234: api-h264-test: build with another api test
[03:21:21 CEST] <Compn> mplayer users found lots of bugs in previous lavf codecs and demuxers. when those were made default in mplayer for testing, since ffmpeg is more stable and mplayer is more experimental
[03:22:22 CEST] <Compn> i dont really care which is default, but this is a format with at least 15 years of testing. it would be like rewriting the avi demuxer and making the new one default without testing millions of files.
[03:22:42 CEST] <Compn> oh well no one cares about compn
[03:25:47 CEST] <Compn> "lavf codecs" derp
[03:26:06 CEST] <jamrial> well, difference is that (afaik) unlike asf, people went and hacked every single kind of audio and video codec known to man into avi :p
[03:26:35 CEST] <jamrial> so rewriting avidec is a monumental task if you plan to also support crap like that
[03:27:08 CEST] <Compn> asf has a few codecs , not as many as avi of course
[03:27:36 CEST] <Compn> how do i test the new asf demux ?
[03:27:48 CEST] <Compn> -f asf-o ?
[03:34:13 CEST] <jamrial> asf_o i think
[05:17:15 CEST] <cone-242> ffmpeg 03Michael Niedermayer 07master:be4e1f28fd65: avformat/asfdec: Print packet_obj_size in case it is invalid
[05:17:16 CEST] <cone-242> ffmpeg 03Michael Niedermayer 07master:4ccd2b31f0e9: avformat/asfdec: Allow packet_obj_size == 0
[05:49:50 CEST] <jamrial> i find the act of fixing the old demuxer to "favor" the argument about it being better than the new somewhat misguided
[06:45:32 CEST] <Compn> none of that matters
[06:45:43 CEST] <Compn> only matters to test both demuxers against millions of samples
[06:45:51 CEST] <Compn> i have the lists still
[06:46:05 CEST] <Compn> videos_wmvp.txt videos_wvp2.txt
[06:46:10 CEST] <Compn> from picsearch
[06:46:21 CEST] <Compn> there were some more too.
[06:47:31 CEST] <Compn> the weird thing is that libav complains ffmpeg adds any feature without testing, now libav wants to add a feature quickly and ffmpeg wants to test, now we are the bad guys wanting more testing? weird situation :P
[08:13:55 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:21cede9e970a: doc/filters: fix documentation bug in ssim filter
[10:18:48 CEST] <cbsrobot_> j-b: is this your new VLC ad in japan ? https://www.youtube.com/watch?v=MxC_Rl5INpY&feature=youtu.be&t=7
[10:20:39 CEST] <j-b> cbsrobot_: W-T-F
[10:35:46 CEST] <JEEBsv> Compn: it's not as if the demuxer was not tested at all, but I do see the point. was the actual list of working/non-working samples and the test results published?
[11:45:55 CEST] <ubitux> michaelni: i didn't understnad your answer @ http://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174337.html
[11:46:02 CEST] <ubitux> my point was about the 2 branches having the same code
[11:46:24 CEST] <ubitux> so that was on purpose (!yuv444 needs to be changed later or something?)
[11:48:35 CEST] <michaelni> YUV should not use a transform (it doesnt), RGB should use the ICT for lossy and RCT for lossless, this should be easy to implement, 
[11:50:38 CEST] <michaelni> see G.2 and G.3 in the j2k spec, its quite simple to implement
[11:51:02 CEST] <ubitux> ok
[11:52:43 CEST] <michaelni> ICT & RCT are basically RGB->YUV type transforms one losslessly reversible
[12:24:43 CEST] <cone-006> ffmpeg 03Shivraj Patil 07master:d9deae04a78b: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for pixblock functions
[13:02:22 CEST] <BBB> maybe we should do a vote on asfdemux
[13:02:31 CEST] <BBB> I mean, &
[13:07:00 CEST] <wm4> sounds like an interesting idea
[13:07:25 CEST] <wm4> but isn't only cehoyos against? and mini pretends to be impartial as usual
[13:23:37 CEST] <kierank> lol
[13:57:28 CEST] <ubitux> did anyone share samples that were supported by one but not another?
[14:08:29 CEST] <durandal_1707> c-e found sample that didn't worked with old demuxer
[15:20:48 CEST] <Compn> new feature vs replacement feature
[15:21:09 CEST] <Compn> i mean, you understand how many millions of files the old demuxer has been tested on
[15:21:27 CEST] <Compn> possibly billions. so many spanking videos for j-b
[15:21:44 CEST] <Daemon404> iirc vlc doesnt even use out wmv demux
[15:21:48 CEST] <Daemon404> neither does mplayer or mpv.
[15:21:52 CEST] <Daemon404> because its so broken.
[15:21:55 CEST] <Daemon404> they all use their own.
[15:22:10 CEST] <wm4> mpv dropped the mplayer one and suffered the consequences
[15:22:19 CEST] <Daemon404> constant bug reports?
[15:22:20 CEST] <kurosu> Has any of them be fuzzed? That would matter to some (not all) users. But then, such scrutiny isn't applied to most pieces of code
[15:22:34 CEST] <Daemon404> old one has of course been
[15:22:39 CEST] <Daemon404> during the j00ru phase.
[15:22:59 CEST] <Compn> wtf @ that youtube clip. cbsrobot_
[15:23:08 CEST] <wm4> Daemon404: complaints about seeking being borked are common, but mostly they are against stuff like .ts or DVD (as expected)
[15:23:25 CEST] <Daemon404> wm4, i think top complains for ffms2 are: .ts seeking is broken, wmv seeking is broken
[15:23:31 CEST] <Daemon404> by several orders of magnitude
[15:23:47 CEST] <Daemon404> and this is even with an index.
[15:24:15 CEST] <Daemon404> some people on doom9 and github had taken to patching ffmpeg with the new asf demuxer (before it was in)
[15:24:20 CEST] <Daemon404> and distributing ffms2 builds with it
[15:24:22 CEST] <Daemon404> to work around it
[15:25:21 CEST] <Daemon404> i wonder how well this new demuxer works on problematic long-gop wmv files
[15:25:27 CEST] <Daemon404> this was one of the reasons vlc hated it iirc
[15:25:30 CEST] <Daemon404> (dont quote me)
[15:25:33 CEST] <kurosu> too bad nobody has time or expertise to fix these broken demuxers (iirc kierank complained ts couldn't fit the ffmpeg model anyway)
[15:25:42 CEST] <Daemon404> it doesnt
[15:25:59 CEST] <Daemon404> it is a consequence of having a 'generic' demux lib.
[15:28:36 CEST] <Compn> has anyone tried to add a wrapper for another ts demuxer , or everyone just uses their ts demuxer and lavc and dont care about lavf anyway
[15:36:13 CEST] <BBB> kierank: btw, regarding the api thing we talked about yesterday
[15:36:31 CEST] <BBB> kierank: Id be really delighted if (over time, very long term) this could lead to better documentation of how seeking works
[15:36:59 CEST] <BBB> kierank: not api-wise, but implementation wise, like in if you use demuxer XYZ, seeking works like this XYZ and has these limitations XYZ
[15:37:33 CEST] <Daemon404> BBB, gl;hf
[15:37:35 CEST] <BBB> (most people dont care about any of this, but try to do frame-accurate seeking and share single code between ivf and annexb/hevc, and youre basically in hell)
[15:37:39 CEST] <Daemon404> it would would need to be demxuer specific
[15:37:44 CEST] <Daemon404> e.g. some seek based on pts, some based on dts
[15:37:46 CEST] <BBB> absolutely
[15:37:48 CEST] <Daemon404> and based on *neither*
[15:37:52 CEST] <Daemon404> some*
[15:37:56 CEST] <BBB> but Id like to know how it works so that I can write things ffmpeg.c doesnt do
[15:38:02 CEST] <BBB> right now thats not possible
[15:38:09 CEST] <BBB> and I bet half of our demuxer authors dont know either
[15:38:11 CEST] <BBB> which is really bad
[15:38:14 CEST] <Daemon404> its possible if you know the internals
[15:38:15 CEST] <BBB> because it likely means its undefined
[15:38:18 CEST] <Daemon404> ive hit that wall a few times.
[15:38:21 CEST] <BBB> I know the internals
[15:38:24 CEST] <BBB> thats what makes it so bad
[15:38:33 CEST] <BBB> imagine someone trying to do what Im trying to do, but not knowing the internals
[15:39:11 CEST] <Daemon404> BBB, relevant from me: https://twitter.com/daemon404/status/612288114195865601
[15:39:18 CEST] <Daemon404> i say this as a long time API user, of couse.
[15:39:41 CEST] <Daemon404> though that was about ubitux 
[15:39:42 CEST] Action: Daemon404 runs
[15:40:25 CEST] <BBB> :D
[15:40:33 CEST] <BBB> I appreciate the cynisism
[15:40:38 CEST] <BBB> its appropriate
[15:41:05 CEST] <Daemon404> btw i count mplayer as internal
[15:47:47 CEST] <ubitux> :(
[15:48:11 CEST] <Daemon404> ubitux, long time api users have no remorese
[15:48:15 CEST] <Daemon404> remorse*
[15:48:16 CEST] <Daemon404> ;)
[15:56:41 CEST] <wm4> mplayer doesn't really use the API correctly
[15:56:58 CEST] <Daemon404> did it stop cannibalizing finally?
[15:57:02 CEST] <wm4> no
[15:57:22 CEST] <Daemon404> didnt think so
[15:57:29 CEST] <wm4> you'd think with development slowing down they'd make changes to make maintenance easier
[15:57:52 CEST] <BBB> I think they just stop touching code
[15:57:56 CEST] <BBB> it works now"
[15:58:00 CEST] <BBB> and then they expect api stability
[15:58:08 CEST] <wm4> mplayer? kind of
[15:58:20 CEST] <wm4> I suspect mplayer is much of the reason some old APIs don't get removed
[15:59:06 CEST] <Daemon404> did we nuke lavc's deint yet
[15:59:17 CEST] <wm4> it's easy to say that users should update their API usage, but if you have to fix MPlayer code yourself... then it's not easy
[15:59:33 CEST] <Daemon404> it only took you 3 years
[15:59:38 CEST] <wm4> lol
[16:00:01 CEST] <BBB> no lavc deint is still under a macro enabled by default
[16:00:02 CEST] <BBB> sadly
[16:00:12 CEST] <Daemon404> :(
[16:00:16 CEST] <Daemon404> what even uses it?
[16:00:18 CEST] <Daemon404> and why?
[16:00:20 CEST] <wm4> we also have 3 vdpau APIs
[16:00:23 CEST] <BBB> mplayer from 7 years ago
[16:00:29 CEST] <Daemon404> o.
[16:00:40 CEST] <wm4> (granted, the 3rd is very similar/builds on the 2nd, and is rather recent)
[16:01:22 CEST] <wm4> Daemon404: also there's this guy on the ML who is a fan of the old deint API
[16:02:08 CEST] Action: Daemon404 ponders sending a rm patch
[16:02:17 CEST] <wm4> automatic flamewar
[16:02:29 CEST] <Daemon404> ... has that ever stopped me?
[16:02:43 CEST] <wm4> if you do I'll reply with +1
[16:02:47 CEST] <BBB> I think it needs a lavc version bump
[16:02:58 CEST] <BBB> so youd need to do that (Im fine with it)
[16:03:04 CEST] <Daemon404> BBB, it was deprecated several verison bumps ago
[16:03:05 CEST] <Daemon404> wasnt it
[16:03:33 CEST] <wm4> right, you probably need stupid "remove on next bump" ifdeffery
[16:03:48 CEST] <Daemon404> i never understoof the point of that
[16:03:48 CEST] <wm4> if it isn't already
[16:03:49 CEST] <BBB> ../libavcodec/version.h:#define LIBAVCODEC_VERSION_MAJOR 56
[16:03:54 CEST] <Daemon404> if the version is already bumped
[16:03:55 CEST] <BBB> ../libavcodec/version.h:#define FF_API_DEINTERLACE       (LIBAVCODEC_VERSION_MAJOR < 57)
[16:04:09 CEST] <Daemon404> hmm ok
[16:04:29 CEST] <wm4> we all know the FF_API_DEINTERLACE def will be updated on the next actual bump
[16:04:39 CEST] <BBB> also see f4c444e17d137c786f0ed2da0e5943df505d5f9e
[16:04:48 CEST] <BBB> -#define FF_API_DEINTERLACE       (LIBAVCODEC_VERSION_MAJOR < 56)
[16:04:49 CEST] <BBB> +#define FF_API_DEINTERLACE       (LIBAVCODEC_VERSION_MAJOR < 57)
[16:04:55 CEST] <Daemon404> what the shit?
[16:04:56 CEST] <BBB> I havent backtracked further than that
[16:05:08 CEST] <wm4> that was silly... it was a major bump except they didn't want a real major bump
[16:06:00 CEST] <durandal_1707> audioconvert
[16:06:39 CEST] <Daemon404> durandal_1707, ... is that not dead yet?
[16:06:47 CEST] <Daemon404> (if it's what i think it is
[16:06:49 CEST] <wm4> ffzombie
[16:07:10 CEST] <BBB> the version before that is my original patch which put it under the version conditional
[16:07:15 CEST] <BBB> so I guess major was never bumped since then
[16:07:27 CEST] <BBB> 54b298fe5650c124c29a8283cfd05024ac409d3a
[16:07:42 CEST] <wm4> over 2 years ago
[16:07:45 CEST] <durandal_1707> michaelni: old deprecated stuff need to go
[16:08:10 CEST] <BBB> Date:   Sun Mar 3 08:23:08 2013 -080
[16:08:11 CEST] <BBB> indeed
[16:08:58 CEST] <Daemon404> at least carl wont object to API removal
[16:09:02 CEST] <Daemon404> since he can only comprehend the CLI.
[16:09:14 CEST] <wm4> heh
[16:09:21 CEST] <nevcairiel> he did object the old vdpau shit removal, since his beloved mplayer uses that
[16:09:41 CEST] <wm4> mplayer supports both now
[16:09:56 CEST] <wm4> because apparently there were some regressions
[16:10:28 CEST] <wm4> do we keep a list of "stupid things that should be fixed on the next major bump"? I recall av_init_packet having stupid semantics
[16:10:40 CEST] <wm4> or does everything need to be ifdefferied?
[16:10:59 CEST] <nevcairiel> ideally you want a replacement in early so people that follow master can update
[16:11:20 CEST] <Daemon404> wm4, well my issue with the packet stuff is
[16:11:24 CEST] <nevcairiel> and changing semantic of an existing function is always difficult since it can be hard to notice such changes
[16:11:26 CEST] <Daemon404> some is av_packet_thing
[16:11:30 CEST] <Daemon404> some is av_thing_packet
[16:11:36 CEST] <Daemon404> i constantly fuck it up
[16:15:00 CEST] <wm4> av_dup_packet is also a thing that must die
[16:17:06 CEST] <wm4> Daemon404: how much would you hate me if I added av_packet_init()
[16:17:16 CEST] <wm4> which, unlike av_init_packet, would actually init _all_ fields
[16:20:39 CEST] <BBB> yeah can we kill av_dup_packet?
[16:20:43 CEST] <BBB> the doxy says it all
[16:21:07 CEST] <BBB> Warning
[16:21:09 CEST] <BBB> This is a hack - the packet memory allocation stuff is broken. The packet is allocated if it was not really allocated.
[16:21:42 CEST] <BBB> wm4: please dont add function duplicates, just fix av_init_packet?
[16:21:44 CEST] <BBB> or is that silly?
[16:21:55 CEST] <wm4> BBB: complaints about subtly different semantics
[16:22:12 CEST] <BBB> right but now every time I typo the function name, it works but behaves differently
[16:22:13 CEST] <wm4> av_init_packet doesn't set the size/data fields, and some code might rely on this
[16:22:17 CEST] <BBB> instead of giving me a compile error
[16:32:49 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:da8b22897740: avformat/avio: Move avio_delete() avio_move() to avpriv_ namespace
[16:58:31 CEST] <cone-006> ffmpeg 03Rostislav Pehlivanov 07master:7c10b87b5744: aacenc: add support for coding of intensity stereo scalefactor indices
[17:34:58 CEST] <nevcairiel> wm4: you mean some code sets the fields before calling av_init_packet? that would seem like a rather terrible control flow
[17:36:51 CEST] <wm4> yes, but this is how this function was "designed"
[17:37:22 CEST] <nevcairiel> unfortunately changing this is a bit iffy, since it would be a silent failure
[17:37:31 CEST] <nevcairiel> such things are annoying
[17:37:36 CEST] <wm4> yep
[17:38:42 CEST] <wm4> it was done this way by Fabrice Bellard in 2003
[17:40:55 CEST] <wm4> and for no apparent reason
[17:41:02 CEST] <cone-006> ffmpeg 03Carl Eugen Hoyos 07master:a876a4da4a92: lavf/img2dec: Autodetect dds frames.
[17:41:03 CEST] <cone-006> ffmpeg 03Carl Eugen Hoyos 07master:45441eb0f643: Changelog: Add jpeg 2000 improvements before they get forgotten.
[17:41:04 CEST] <cone-006> ffmpeg 03Carl Eugen Hoyos 07master:5a458420e2fb: lavf/asfdec: Reduce minimum header size.
[17:41:05 CEST] <cone-006> ffmpeg 03Carl Eugen Hoyos 07master:dee794381904: lavf/img2dec: Improve detection of valid Quickdraw images.
[17:41:06 CEST] <cone-006> ffmpeg 03Carl Eugen Hoyos 07master:77c0b149be12: lavf/mpegts: Return 0 if the probe function does not detect mpegts.
[17:41:07 CEST] <cone-006> ffmpeg 03Carl Eugen Hoyos 07master:4b920d7b4a58: lavf/msnwc: Return 0 if the probe function does not detect msnwc-tcp.
[17:41:08 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:e55e5be982a6: Merge remote-tracking branch 'cehoyos/master'
[17:48:05 CEST] <Daemon404> i wonder why the MIPS guys are sending so much stuff to every media project
[17:48:16 CEST] <Daemon404> last ditch attempt to not die?
[17:48:44 CEST] <BtbN> isn't the chinese CPU a MIPS one, and they are the ones sending all the patches?
[17:48:53 CEST] <Daemon404> longsoon? lol
[17:49:51 CEST] <BtbN> Yep, seems to be MIPS.
[17:50:28 CEST] <Daemon404> yes it is
[18:06:47 CEST] <markos_> hi all, speaking of dying arches, I've done a bunch of altivec patches that give a 2-7% on x264 decoding, I have them on a forked github tree, what's the usual procedure, should I send them one by one or combine them? they pass the regression tests and most of the videos I've tested, but this is a first time, so I might be missing sth
[18:07:07 CEST] <markos_> (they are against current master btw)
[18:08:27 CEST] <BtbN> you should propably ask on the x264 ml. Or are they against ffmpeg?
[18:08:39 CEST] <markos_> https://github.com/markos/FFmpeg/commits/master
[18:08:42 CEST] <markos_> against ffmpeg
[18:09:11 CEST] <BtbN> Hm? What do they do then? x264 is primarily an external library
[18:09:36 CEST] <J_Darnley> I think you mean H.264 decoding
[18:09:45 CEST] <BtbN> oh, _de_coding
[18:09:56 CEST] <markos_> sorry, yes, bad choice of words :)
[18:10:59 CEST] <J_Darnley> it happens especially when one software dominates a particular area
[18:12:14 CEST] <BtbN> I'd guess it happens because certain content providers put x264 in their filenames.
[18:12:58 CEST] <Daemon404> J_Darnley, its worse when the scene picks it up and uses it incorrectly
[18:13:02 CEST] <Daemon404> as they wont to d
[18:13:02 CEST] <Daemon404> o
[18:32:43 CEST] <cone-006> ffmpeg 03Paul B Mahol 07master:9842d6707fd6: avfilter/avf_showvolume: optionally display channel names
[19:13:34 CEST] <Compn> markos_ : send a pull request
[19:13:42 CEST] <Compn> i guess
[19:13:46 CEST] <Compn> or push request
[19:13:49 CEST] <Compn> whatever its called
[19:14:38 CEST] <Daemon404> a patch to the ml
[19:18:22 CEST] <Compn> that too
[19:18:50 CEST] <markos_> the one generated by git format-patch like mentioned in the howto, I guess?
[19:21:32 CEST] <jamrial> yes
[19:22:03 CEST] <jamrial> if you can't get git send-email to work, just attach the file created by format-patch into an email
[19:24:06 CEST] <markos_> yeah, that's my worry atm, I wouldn't want to fill the list with test mails just to make sure it works :)
[19:47:45 CEST] <tizbac> hello, i'm trying to implement frame interpolation on libavfilter to allow converting videos from 24/30 fps to 60 fps, https://github.com/tizbac/FFmpeg/commit/ac73e47cf3b5b3b3a066425fc13db238d1be2803 , problem is i can't get a reliable motion estimation and as a consequence, the result is full of misplaced squares
[19:48:28 CEST] <tizbac> does anyone have suggestions on how to do it correctly?
[19:49:07 CEST] <nevcairiel> how do you expect to get motion information?
[19:49:24 CEST] <tizbac> i've done it using diamond search
[19:49:38 CEST] <tizbac> to get the motion vectors between 2 frames for each block
[19:50:10 CEST] <nevcairiel> well motion detection is one of the larger problems for every video codec, you can try to benefit from their research, but its probably never going to be perfect
[19:50:27 CEST] <tizbac> i know, but svp project has it working
[19:50:32 CEST] <kierank> svp project?
[19:50:36 CEST] <tizbac> so somehow it's possible to get a decent result
[19:50:41 CEST] <nevcairiel> their quality is terrible, imho
[19:51:39 CEST] <tizbac> it's still better than 24 fps
[19:51:39 CEST] <nevcairiel> kierank: its a fancy installer and config GUI for various avisynth motion interpolation plugins
[19:51:45 CEST] <kierank> ah
[19:51:48 CEST] <kierank> mvtools is good
[19:51:55 CEST] <Daemon404> http://i4.minus.com/ibjPtPu1AKZLlh.jpg
[19:51:58 CEST] <Daemon404> yeah svp is great...
[19:51:59 CEST] Action: Daemon404 runs
[19:51:59 CEST] <kierank> I really dont understand people who do frame interpolation
[19:52:10 CEST] <tizbac> kierank, yeah , problem with mvtools is that source code is no more readable than assembler
[19:52:11 CEST] <kierank> I accept high frame rate
[19:52:19 CEST] <wm4> mvtools got ported to vapoursynth
[19:52:24 CEST] <kierank> but I don't accept creating frames out of nowhere
[19:52:27 CEST] <nevcairiel> tizbac: well its avisynth, thats expected
[19:52:40 CEST] <Daemon404> wm4, rewritten*
[19:52:55 CEST] <wm4> right, not like that shit could actually be ported
[19:53:08 CEST] <tizbac> wm4, is there any source code of the rewritten version?
[19:53:17 CEST] <wm4> yes
[19:53:39 CEST] <wm4> this one I think? https://github.com/dubhater/vapoursynth-mvtools
[19:54:40 CEST] <Daemon404> you know mvtools just uses x264's code in some bits right?
[19:54:47 CEST] <Daemon404> for ME
[19:55:27 CEST] <tizbac> Daemon404, yeah i've seen that
[19:57:31 CEST] <tizbac> kierank, compared to real 60 fps it sucks, but compared to 24 fps it's much better
[19:57:45 CEST] <tizbac> especially on big screens
[19:57:57 CEST] <Daemon404> i can only disagree
[19:58:01 CEST] <nevcairiel> I wouldnt agree, personally
[19:58:05 CEST] <nevcairiel> but everyone their own
[19:58:06 CEST] <Daemon404> interpolated 24->60 looks awful to my eyes
[19:58:13 CEST] <kierank> yes it looks too artificial
[19:58:39 CEST] <nevcairiel> I used to enjoy the processing my TV offered for a bit, until I saw terrible artifacts in a couple scenes, and i turned it off :d
[19:59:12 CEST] <tizbac> yeah there are artifacts on scenes like when james is on top of the speeding train in "Skyfall" movie
[19:59:40 CEST] <nevcairiel> any high motion scenes or scenes with motion in several directions is going to give you issues
[20:00:25 CEST] <rcombs> Daemon404: svp BURNING LOVEs you
[20:00:44 CEST] <Daemon404> im afraid any anime references go over my head nowadays
[20:01:04 CEST] <rcombs> wrong bote anyway
[20:35:56 CEST] <llogan> https://wiki.debian.org/Debate/libav-provider/ffmpeg
[20:39:22 CEST] <philipl> wow. That's quite a turnaround by some Debian folks.
[20:40:30 CEST] <wm4> "Libav even dropped support for version 0.8, which is used in Debian Wheezy, already:"
[20:40:36 CEST] <wm4> these arguments are harmful for the ffmpeg project
[20:40:39 CEST] <wm4> but whatever
[20:49:13 CEST] <durandal_1707> why?
[20:49:37 CEST] <wm4> because it implies that maintaining crap forever is a thing worth doing
[20:49:47 CEST] <wm4> which diverts important resources and effort
[20:50:21 CEST] <wm4> if debian wants to keep really ancient stuff, why don't they maintain it? it's their self-declared job after all
[20:50:45 CEST] <J_Darnley> They'll do another openssh if they do that.
[20:57:54 CEST] <Daemon404> it wouldnt be that bad if ffmpeg was sane
[20:58:01 CEST] <Daemon404> and had 1 or 2 point releases, maintained
[20:58:02 CEST] <Daemon404> bot 40
[20:58:05 CEST] <Daemon404> not*
[21:15:23 CEST] <Zeranoe> If I was to manually remove all source files that are GPL only and I compile without --enable-gpl, will the build compile and work?
[21:17:48 CEST] <Daemon404> wat
[21:19:29 CEST] <Zeranoe> Daemon404: Can a build be compiled that's LGPL only from source that contains only LGPL components
[21:24:12 CEST] <JEEBsv> as long as you don't break the build system around it, yes
[21:25:25 CEST] <JEEBsv> the build system should set which files are compiled
[21:25:48 CEST] <JEEBsv> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/Makefile
[21:26:00 CEST] <JEEBsv> like the stuff here
[21:26:04 CEST] <J_Darnley> I would guess that somebody might be interested in (and fix) any errors you encounter.
[21:26:07 CEST] <Daemon404> whats the goal here though
[21:26:12 CEST] <Daemon404> i dont get it
[21:26:23 CEST] <J_Darnley> Paranoia?
[21:26:27 CEST] <JEEBsv> if a feature is not selected, that .o file is not generated from the same named .c file
[21:26:41 CEST] <JEEBsv> aka that file is not compiled
[21:32:33 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:47f4e2d8960c: avcodec/pngdec: Only allow one IHDR chunk
[21:40:22 CEST] <durandal_1707> nevcairiel: you already use new add demuxer?
[22:17:43 CEST] <nevcairiel> JEEBsv: there are one or two things that are GPL only in the middle of other files
[22:17:50 CEST] <nevcairiel> iirc something in h264
[22:20:29 CEST] <JEEBsv> nevcairiel: yes, but those are generally within ifdefs, no?
[22:20:55 CEST] <nevcairiel> sure, but finding and removing them might end up slightly more annoying than just excluding lavfi filters which are GPL, for instance.
[22:21:06 CEST] <JEEBsv> sure
[22:21:26 CEST] <JEEBsv> which is why generally you just trust that the system was more or less sane'ish
[22:21:31 CEST] <nevcairiel> not that I get the point of even wanting to do that, but shrug
[22:21:33 CEST] <JEEBsv> and if you configure it as LGPL you get LGPL shit
[22:26:06 CEST] <Compn> seriously, asf_o demuxer ?
[22:26:17 CEST] <Compn> seriously? people defending this?
[22:27:58 CEST] <Compn> ffmpeg -f asf_o -i http://samples.ffmpeg.org/A-codecs/WMSP/wma9audio-notworkmplayer.wma out.wav
[22:28:00 CEST] <Compn> huhuhu
[22:29:41 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:a1736926e9ae: avcodec/pngdec: Require a IHDR chunk before fctl
[22:29:42 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:f1ffa01dd3da: avcodec/pngdec: Copy IHDR & plte state from last thread
[22:31:08 CEST] <JEEBsv> Compn: thank you for actually linking a sample instead of lolrhetoric
[22:31:45 CEST] <Zeranoe> Looks like these are all the source files that contain GPL components http://paste.debian.net/plain/266857
[22:31:59 CEST] <Compn> JEEBsv : i'm sad no one else linked a sample :(
[22:32:15 CEST] <Daemon404> of course not
[22:32:20 CEST] <Daemon404> carl admitted he didnt even test it
[22:33:32 CEST] <Compn> guys give it a rest will you? :P
[22:33:39 CEST] <Compn> actually, dont care
[22:33:44 CEST] <Compn> nevermind
[22:34:32 CEST] <Compn> also sorry for late testing delay, i had to wait for nightly build :P
[22:34:37 CEST] Action: Compn too lazy to compile
[22:34:47 CEST] <durandal_1707> cropdetect is gpl?
[22:35:09 CEST] <JEEBsv> I almost wanted to joke if some nightly builds actually worked for you
[22:36:00 CEST] <durandal_1707> they dont?
[22:37:16 CEST] <Compn> Zeranoe's builds work fine for me 
[22:37:20 CEST] <Compn> (i'm on windows atm)
[22:39:16 CEST] <JEEBsv> durandal_1707: IIRC Compn was on ye olde NT5 for a very long time
[22:39:19 CEST] <JEEBsv> and I don't mean 5.1
[22:39:23 CEST] <Compn> win2k 
[22:40:48 CEST] <Compn> [asf_o @ 031c0140] Could not find codec parameters for stream 0 (Video: mpeg4 (MP4S / 0x5334504D), n
[22:40:48 CEST] <Compn> one, 640x480): unspecified pixel format
[22:40:48 CEST] <Compn> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[22:40:48 CEST] <Compn> bug821-2.asf: could not find codec parameters
[22:40:51 CEST] <Compn> argh bad paste
[22:41:03 CEST] <Compn> -f asf_o http://samples.ffmpeg.org/mplayer-bugs/bug821/bug821-2.asf
[22:41:05 CEST] <Compn> ehe
[22:41:10 CEST] <Compn> er dont do the http
[22:41:12 CEST] <Compn> download it first
[22:41:19 CEST] <Compn> -f asf_o bug821-2.asf
[22:49:23 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:b54ac8403bfe: avcodec/pngdec: Check values before updating context in decode_fctl_chunk()
[22:51:15 CEST] <Compn> -i...... argh i'm losing it today
[22:52:39 CEST] Action: JEEBsv hands Compn a lollipop
[23:02:46 CEST] <Daemon404> a a wild thierry appears
[00:00:00 CEST] --- Tue Jun 30 2015