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

[burek]

[00:00] <Zeranoe> smarter: Do you know if the vp8 encoder needs to be disabled when compile vpx so FFmpeg uses vp9?
[00:13] <Zeranoe> Does ffurl_register_protocol depend on anything? Or is there any reason it wouldn't be compiled into an LGPL build?
[00:28] <smarter> Zeranoe: no need to
[01:14] <Zeranoe> is ffurl_register_protocol dependent on Linux? I'm not seeing it anywhere in the Windows builds.
[01:22] <bri> Zeranoe: iirc, that was 'hidden'
[01:26] <Zeranoe> Does this have anything to do with it: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=8e76a19b63a3fa322a64a7d27bd6e642c7fe7f85;hp=80c6e238b0f42a0b07fbc195564a50032b3608ba Looks like that commit made it internal
[01:27] <wm4> are you dealing with software that tries to call this function?
[01:28] <bri> i think so. i asked how to use my own protocols a while back. the idea is that you can pass in a custom protocol now on the open functions
[01:28] <Zeranoe> wm4: Probably, someone just reported to me that they couldn't use that function
[01:28] <wm4> yeah, you can't define user-defined protocols anymore
[01:28] <wm4> you can still do user-defined IO though
[01:29] <Zeranoe> wm4: So what would an alternative be for them?
[01:30] <wm4> they can create a stream with user callbacks with avio_alloc_context()
[01:32] <bri> Zeranoe: there's a huge comment about it at the top of avformat.h
[01:35] <Zeranoe> bri: I guess they didn't read that
[01:35] <bri> we did some custom protocols way back then and was hit by that change too :P
[01:51] <cone-351> ffmpeg.git 03Michael Niedermayer 07master:0538b29ae800: avcodec/cabac: force get_cabac to be not inlined
[02:31] <cone-351> ffmpeg.git 03Michael Niedermayer 07master:63f74cedc9c7: avcodec/cavsdec: reset stc
[02:31] <cone-351> ffmpeg.git 03Michael Niedermayer 07master:9ca32b2060ec: avcodec/cavsdec: print warning if no frame has been decoded
[03:16] <llogan> what does the noise bsf do? i do not understand the contents of libavcodec/noise_bsf.c and using it just seems to screw up the video
[03:17] <llogan> kind of fun though
[04:14] <cone-351> ffmpeg.git 03Michael Niedermayer 07master:bc1b828536cd: avcodec/cavsdec: use more specific error codes
[04:14] <cone-351> ffmpeg.git 03Michael Niedermayer 07master:be99054e77f1: avcodec/cavsdec: print error messages in case of errors
[07:32] <ubitux> BBB: frame parallel=1 sample uploaded in http://lucy.pkh.me/samples/vp9/etv5k/ - artefacts reproducible
[07:33] <ubitux> (around 7 sec at least)
[09:06] <trunk> hi,all. does ffmpeg support "ftypmp42"?
[09:07] <trunk> i only find in source "ffio_wfourcc(pb, "mp41");",not have ffio_wfourcc(pb, "mp42");
[10:27] <j-b> 'morning
[10:40] <ubitux> philipl is not here anymore?
[10:41] <ubitux> ah, seems in holidays
[12:16] <cone-611> ffmpeg.git 03Diego Biurrun 07master:3d7c84747d4b: x86: Initialize mmxext after amd3dnow optimizations
[12:16] <cone-611> ffmpeg.git 03Michael Niedermayer 07master:5b4d57455d5b: Merge remote-tracking branch 'qatar/master'
[12:48] <BBB> ubitux: wanna debug/fix? :)
[12:52] <ubitux> BBB: not really :)
[12:52] <ubitux> the last encode will be available tomorrow
[12:54] <ubitux> libvpx still needs ~30 hours to encode 3.5 minutes on an i7 2600 @_@
[13:00] <BBB> ok
[13:00] <BBB> well I guess I'll have to look at it then, that kinda sucks but what can I do
[13:03] <ubitux> BBB: i think the crash i reported is more important though :p
[13:04] <saste> how can i do an out-of-tree build?
[13:04] <ubitux> saste: git clean your source directory, go into another, and run the configure from here
[13:05] <saste> ubitux, thx, will try
[13:23] <michaelni> rm config.h/mak should be enough, no git clean needed
[13:38] <BBB> ubitux: no, basic functionality and tests therefore is most important
[13:38] <BBB> ubitux: crashes come second; a product is only somewhat useful if it crashes, but is completely useless if it can't decode correct content
[13:39] <ubitux> yeah but crashes are security relevant :p
[13:39] <BBB> otherwise it'd be totally ok to break non-broken file playback to fix crashers, which makes no sense
[13:40] <ubitux> btw, there is no unsigned pcmp*b?
[13:41] <ubitux> mmh i guess it doesn't actually matter&
[13:41] <nevcairiel> it just compares bits more or less
[13:49] <BBB> well it matters for pcmpgtw
[13:49] <BBB> ubitux: if you need unsigned, just pxor 0x80
[13:50] <BBB> ubitux: that makes it signed (it's basically the same as -128) and then you can use pcmpgtw
[13:50] <ubitux> yeah ok
[13:50] <ubitux> i use it only with the b compare anyway
[13:50] <ubitux> still dunno how to exploit the result though
[13:50] <BBB> masking
[13:51] <BBB> if (a) { res = b(); } else { res = c(); }
[13:52] <BBB> mask = a; res_a = b(); res_b = c(); res = (res_a & a) | (res_b & ~a);
[13:52] <BBB> ~a is the same as pxor(a, 0xffffffffffffffff)
[13:52] <BBB> but there's also pnand for this purpose
[13:53] <BBB> er, pandn
[13:53] <ubitux> i mean i don't know how to check the result of that pcmp..b thing to branch
[13:53] <BBB> you don't branch
[13:53] <BBB> simd is branchless
[13:53] <BBB> you do both codepaths and and/or the results
[13:53] <BBB> check my line again
[13:54] <BBB> mask = a; res_a = one_code_path(); res_b = else_code_path(); res = pand(res_a, a) | pandn(res_b, a)
[13:54] <ubitux> oh
[13:54] <BBB> note how there's no branch
[13:54] <BBB> makes sense now? :)
[13:54] <ubitux> yeah but it sounds inefficient 
[13:55] <ubitux> oO
[13:55] <BBB> right, it does, but it's not
[13:55] <BBB> because you do 2 codepaths for 16 pixels at a time
[13:55] <BBB> so it's still 8 pixels per codepath on average
[13:55] <ubitux> i wrote the 16 and 8 paths
[13:55] <BBB> for the branchy part - and 16 for the unbranchy part
[13:55] <BBB> cool
[13:55] <ubitux> i was wondering about the 4/2 at the end
[13:56] <BBB> right, so it's like this
[13:56] <ubitux> so i'll compute all these paths all the time? oO
[13:56] <BBB> for 16wd, yes
[13:56] <BBB> for 8wd, only 3
[13:56] <BBB> for 4wd, only 2
[13:56] <ubitux> fear.
[13:56] <BBB> :)
[13:56] <BBB> it's worth it, really
[13:56] <BBB> this is one of the criticisms of the vp8 loopfilter btw
[13:56] <ubitux> i wonder how it could be more efficient than branching
[13:56] <BBB> that it had two completely unrelated filtering elements that had to both be run in simd
[13:57] <BBB> like I said, you do 16 per simd iteration
[14:02] <ubitux> sure but if i have to compute the 4 paths all the time...
[14:07] <ubitux> it's too bad the 4/2 paths can't be computed using the 8/16 formula with dummy values
[14:07] <BBB> you can share some code between the 4/2 paths iirc
[14:08] <BBB> they are similar to the vp8 loopfilter
[14:08] <ubitux> yes probably
[14:08] <ubitux> it's still mostly a byte-per-byte case
[14:08] <BBB> but yes you're right and this is likely going to be a criticism on the codec if we get around to writing a blog post about the decoder
[15:40] <zidanne> Why would ic->duration become wrong? This is my log line: seekTo called for 900 secs. (ic->duration: 11676735, xduration: 11.000000) xduration is ic->duration divided by 1000000
[16:00] <cone-611> ffmpeg.git 03Michael Niedermayer 07master:6005ab3e0ed6: avcodec/mjpegenc: use av_log2_16bit() in encode_block()
[16:24] <ubitux> BBB: so even in the cas ewhere there is no postprocessing to do (fm=0), we're going to compute the whole 4 paths and rewrite dst?
[18:04] <cone-611> ffmpeg.git 03Michael Niedermayer 07master:dc1b0a54f9fe: avformat/utils: provide more IO statistics in debug output at start and end of av_find_streaminfo()
[18:04] <cone-611> ffmpeg.git 03Michael Niedermayer 07master:1565a9a9e90c: avformat/utils: factor rfps calculation out
[18:04] <cone-611> ffmpeg.git 03Michael Niedermayer 07master:e2bf00ce4643: avformat/mov: calculate rfps from the first 100 frames of the index
[18:26] <Compn> http://torrentfreak.com/court-open-source-project-liable-for-3rd-party-drm-busting-coding-131205/
[18:26] <Compn> Rathann : ^^
[18:26] <Rathann> hi
[18:27] <Rathann> WTF
[18:27] <Rathann> madness...
[18:28] <Daemon404> damn... i was about to link the obligatory america, fuck yeah video
[18:28] <Daemon404> but germany.
[18:28] <Compn> rtmpe is in ffmpeg you know...
[18:30] <av500> ...This means that if any company or individual wants to use an open (or closed) source binary (commercial or not), they are liable for it if it contains any illegal functions...
[18:30] <av500> well duh, yes of course
[18:30] <av500> live by the binary, die by the binary
[18:31] <Compn> is distributing an 'illegal function' illegal ?
[18:31] <av500> distributing DRM circumvetion might be
[18:31] <bri> isn't that like a gun company being responsible for murders?
[18:31] <av500> no
[18:31] <Compn> only if the gun can decrypt something :D
[18:31] <av500> exactly
[18:31] <bri> eheh
[18:31] <Compn> lol
[18:31] <av500> kill somebody, fine
[18:31] <av500> copy a movie, big problem
[18:32] <Daemon404> guns *can* decrypt things
[18:32] <Daemon404> but i prefer a $5 wrench.
[18:32] <av500> one can always make new people, but that movie ticket is lost forever
[18:41] <Compn> so ffmpeg "banned in germany" news post ? :)
[18:43] <nevcairiel> how does rtmpe defeat a DRM? dont you need a valid encryption key or something?
[18:44] <Compn> theres a key
[18:44] <Compn> 'adobe flash player 0001'  or something
[18:44] <wm4> just because it's DRM it hasn't to be effective
[18:44] <Compn> 'right
[18:44] <wm4> you could even just have a single "copyrighted" bit
[18:44] <wm4> remember, lawyers are not intelligent beings
[18:45] <Compn> copyright, trademark and encryption , all in one
[18:45] <nevcairiel> there is actually precedence that a protection needs to be somewhat effective for it to count in germany
[18:45] <Compn> without the key, you cant decrypt
[18:45] <Compn> so thats effective, no ?
[18:45] <Compn> also theres rtmpe10 too
[18:46] <Compn> which is heavily encrypted
[18:46] <nevcairiel> a WEP encrypted wifi is now considered like running a completely free wifi in the eyes of the law, for example :p
[18:46] <nevcairiel> and i believe backup of DVD is no longe illegal because the CSS protection has been deemed stupid
[18:46] <Compn> beastd : whats wrong with germany? http://torrentfreak.com/court-open-source-project-liable-for-3rd-party-drm-busting-coding-131205/
[18:46] <beastd> hi
[18:48] <beastd> oh dear. i know nothing about the details. seems seriously ill though---
[18:49] <Compn> is there any news in the german open source .... community ?
[18:52] <{V}> how is it news that they're responsible for what they distribute? especially binaries?
[18:54] <Compn> {V} : the ruling means ffmpeg is illegal in germany
[18:54] <Compn> with a 250,000 euro fine for “production, distribution and possession” of an ‘illegal’ piece of software.
[18:54] <Compn> even posession of the software is illegal
[18:54] <Compn> you guys are doing a binary vs source issue, this is much deeper than that
[18:55] <Compn> (btw all distros in germany shipping ffmpeg would also be illegal...)
[18:56] <beastd> i think it is not decided yet
[19:02] <Compn> beastd : wheres the german court website ?
[19:04] <Compn> i guess theres a few different courts of course
[19:04] <Compn> so we need to find out what court this was in
[19:04] <Compn> to see if we can read opinion / ruling / judgement
[19:04] <nevcairiel> i'll wait for a more credible page to post this anyway, you know, with actual information on the source and such
[19:05] <Compn> like heise ?
[19:05] <Compn> or slashdot linking back to torrentfreak ? :P
[19:06] <{V}> http://raschlegal.de/uploads/media/LG_HH__B.v._25.04.13__Az._310_O_144-13.pdf
[19:06] <nevcairiel> heise would be ok, they usually research stuff to find the real source :p
[19:06] <Compn> oo
[19:07] <Compn> i see RTMPE and $250,000
[19:07] <wm4> this is ridiculous
[19:08] <wm4> software can download video from some streaming site -> illegal, pay 250.000
[19:08] <nevcairiel> thats also 8 month old
[19:08] <wm4> true
[19:08] <j-b> lol
[19:08] <j-b> VLC is infriging
[19:08] <nevcairiel> its just the injunction to block spreading of the software
[19:08] <j-b> RTMPE
[19:08] <j-b> Oh My God, I'm going to get suuuuued
[19:09] <bencoh> :]
[19:10] <{V}> here's the december one: http://raschlegal.de/uploads/media/LG_Hamburg_Urt__v__29_11_2013__AZ__310_O_144-13.pdf
[19:10] <Compn> {V} : so is the torrent freak article correct ?
[19:10] <nevcairiel> the article on torrentfreak is really terrible, it doesnt really distinguish anything between the injunction or any following legal proceedings
[19:11] <Compn> true
[19:11] <Compn> http://www.golem.de/news/streaming-video-gericht-macht-geschaeftsfuehrer-fuer-jdownloader2-haftbar-1312-103129.html
[19:12] <Compn> searching german news , past week, for 'jdownloader2' 
[19:12] <{V}> Compn, I haven't decyphered the german yet.
[19:12] <Compn> something something software patents
[19:13] <Compn> i guess this is more encryption law
[19:14] <{V}> the article that linked to that last pdf was http://raschlegal.de/news/jdownloader2-lg-hamburg-bestaetigt-haftung-des-geschaeftsfuehrers/
[19:15] <Compn> so the hamburg regional court
[19:15] <nevcairiel> well the judgement does mention one specific clause in the law that is limited to applications that have the primary goal to circumvent (or at least make it easier to) protections, which one could argue an app like jdownloader is
[19:15] <nevcairiel> but a video player wouldnt have this primary purpose
[19:16] <Compn> by that logic , you could just put a video player in jdownloader to get around that
[19:16] <Compn> jmediaplayer
[19:16] <nevcairiel> wouldnt really change the primary function of jdownloader
[19:16] <nevcairiel> which is to make it easier to steal stuff from the web
[19:17] Action: Compn steals all of nevcairiel's digital bits
[19:17] <nevcairiel> of course if you get a smart judge and good lawyers, it should be easy to demonstrate that RTMPE is not safe
[19:17] <nevcairiel> or secure
[19:18] <nevcairiel> anyhow the main point is not about RTMPE
[19:18] <nevcairiel> because their real gripe was that it had a specific download plujgin for their myvideo.de domain
[19:18] <nevcairiel> not a generic RTMPE downloader
[19:18] <beastd> i would have expected to find sth here:  http://justiz.hamburg.de/urteilsdatenbank/
[19:19] <beastd> but couldn't find it
[19:20] <Compn> nevcairiel : that part about posessing encryption decrypting software ?
[19:20] <Compn> i guess i'd have to read the german law
[19:20] <nevcairiel> i suppose the lesson is that a company needs to be careful what they ship
[19:20] <Compn> (translated to english)
[19:20] <Compn> posessing man
[19:21] <Compn> ignore shipping
[19:21] <Compn> merely posessing
[19:21] <nevcairiel> the law doesnt make rtmpe alone illegal, the judgement is pretty specifically tailored to jdownloader and its special myvideo plugin, that did more then that
[19:22] <Compn> its about the encryption in rtmpe
[19:22] <Compn> afaict
[19:22] <Compn> maybe i am wrong
[19:22] <nevcairiel> I just read the judgement
[19:22] <nevcairiel> since you know, i am german :P
[19:22] <Compn> i dont know whos german around here
[19:22] <beastd> the thing is with thing being copy protected or not AFACIT
[19:22] <Compn> can you link us to the law ?
[19:23] <Compn> not the judgement, but the actual part in the law
[19:23] <ubitux> any trick to fill a xmm reg with 1's?
[19:23] <beastd> in germany you supposedly not allowed to circumvent copy protectsion
[19:23] <nevcairiel> rtmpe is not a copy protection though
[19:23] <nevcairiel> its a transport encryption
[19:23] <nevcairiel> like ssl
[19:23] <Compn> nevcairiel : you are german, but are you a lawyer? :P
[19:24] <nevcairiel> everyone is a lawyer on the interwebs
[19:24] <Compn> ianal
[19:24] <Compn> :)
[19:24] <beastd> nevcairiel: IANAL but the haburg court obviously rated rtmpe as copy protected.
[19:25] <nevcairiel> not alone
[19:25] <nevcairiel> everywhere RTMPE is mentioned, they also mention some kind of security token
[19:25] <michaelni> ubitux, some compare equal instruction of the register with itself
[19:25] <Compn> almost every rtmpe stream has a security token
[19:25] <Compn> and ffmpeg has support to enter security tokens
[19:25] <Compn> i think.
[19:25] <Compn> rtmpdump does anyhow
[19:25] <ubitux> michaelni: pcmpeqb mx, mx?
[19:26] <michaelni> ubitux, yes
[19:26] <ubitux> ok, good enough, thx
[19:27] <nevcairiel> Compn: the primary law being used here is http://www.gesetze-im-internet.de/urhg/__95a.html
[19:27] <nevcairiel> specifically 3) 3.
[19:28] <Compn> thank you
[19:28] <Compn> although probably cant trust google translator
[19:28] <Compn> :)
[19:28] <nevcairiel> which basically says that software with the primary goal to break protection is forbidden
[19:29] <wm4> so yeah, change jdownload into a video player
[19:29] <wm4> with additional save function
[19:30] <nevcairiel> just use a video player which already has this functionality? :p
[19:30] <nevcairiel> it also says that sofware which would be useless once this function is taken out, also qualifies for these rules
[19:30] <Compn> jdownloader isnt useless without that plugin
[19:31] <Compn> actually a very useful tool when dealing with file locker sites
[19:31] <nevcairiel> but a special rtmpe video player might be :p
[19:32] <Compn> dont sections 1 and 2 on that page also apply ?
[19:32] <nevcairiel> the third is what was specificlaly named in the judgement, but sure
[19:32] <Compn> Technical measures are effective, to the extent they use a protected work or other protected under this Act subject matter protected by the right holder through an access control, a protection mechanism, such as encryption, scrambling or other transformation or a mechanism to control the duplication, which achieves the protection objective ensure, is kept under control.
[19:33] <Compn> encryption, right there 
[19:33] <Compn> to control duplication, e.g. if you dump network packets, you cant decode it unless you decrypt it
[19:34] <nevcairiel> it also says access control or protection, which is arguable if thats something rtmpe as a transport encryption is good for
[19:34] <Compn> if you dont have the key, you cant access it :P
[19:35] <Compn> or security token
[19:35] <nevcairiel> i thought its just a key-exchange algorithm using DH
[19:35] <nevcairiel> like ssl
[19:36] <Compn> theres a couple different keys
[19:36] <Compn> first is the adobe flash player 0001 which is in all rtmpe i think
[19:36] <Compn> then theres security tokens, which are in ... 30-50% of streams
[19:37] <Compn> sometimes those are hardcoded in .swf players
[19:37] <nevcairiel> the implementation in ffmpeg looks like a normal DH key exchange
[19:37] <nevcairiel> so just transport protection
[19:37] <Compn> ffmpeg does not have any list of security tokens ,anyways
[19:38] <Compn> so its primary function isnt to ripoff your protected stream
[19:38] <Compn> although it can be used to do so
[19:38] <nevcairiel> all i can read makes rtmpe sound like a light-weight version of rtmps (which just uses ssl/tls)
[19:38] <Compn> sorry, i'm mixing up usa laws of copy protection tools . so its all confusing to me.
[19:41] <Compn> well i dont know all rtmpe stuff. theres rtmpe10 handshake and securetoken http://www.wowza.com/forums/content.php?450-How-to-protect-RTMP-streaming-using-SecureToken-(ModuleSecureToken)
[19:42] <nevcairiel> sounds like its an addon to rtmpe, not part of rtmpe itself
[19:59] <zidanne> which third party libraries do we have support for mp3 decoding?
[19:59] <nevcairiel> there is a native mp3 decoder
[20:45] <Compn> zidanne : i dont think ffmpeg has mpg123 wrapper anymore
[20:56] <wm4> nevcairiel: what are you doing about mpeg4 + GMC? it seems many hw decoders don't support it (fully), yet advertise mpeg4 support
[20:57] <nevcairiel> i dont think i have ever seen a GMC sample
[20:58] <nevcairiel> plus my mpeg4 hw support is pretty limited, and i dont plan to extend it, more likely remove
[20:58] <wm4> I had 3 users who hit this problem now
[20:58] <wm4> and it's not like I have many users
[20:58] <nevcairiel> do you have a sample at hand?
[20:59] <nevcairiel> i only support mpeg4 through nvidias cuvid interface, maybe its api is smart enough to refuse and trigger a fallback to software
[20:59] <Compn> wm4 : you sound like every single hw mpeg4 player ever
[20:59] <Compn> theres mpeg4 files that wont play on hw, get over it ;)
[20:59] <wm4> apparently this is affected https://trac.ffmpeg.org/ticket/3138 https://dl.dropboxusercontent.com/u/3219541/harlock-ep20.mkv
[21:00] <nevcairiel> Compn: the problem in a software player is that you want to fallback to software decoding, preferably seamless
[21:00] <wm4> but I didn't exactly check this myself
[21:00] <Compn> ah ;p
[21:00] <Compn> mpeg4 in mkv ? 
[21:00] <wm4> hw decoders will just eat whatever they get, and decode abstract art if unsupported features are used
[21:00] <Compn> i guess that was before the great h264...
[21:01] <JEEB> in between ogm and H.264 in matroska
[21:11] <nevcairiel> wm4: i do indeed see quite a lot of corruption in that sample with hw decode
[21:11] <wm4> nevcairiel: I guess it's time to disable mpeg4 by default then, heh
[21:11] <nevcairiel> but mpeg4 hwaccel is explicitly disabled by default, and if someone turns it on ... i'll just tell em not to
[21:11] <wm4> yeah
[21:12] <nevcairiel> i should turn mpeg4-mt back on though
[21:12] <Daemon404> why give users buttons that break things
[21:12] <nevcairiel> because they bitch and whine otherwise
[21:12] <Daemon404> so? a kid can bitch and whine cause he wants to play with fireworks
[21:12] <Daemon404> im still not gonna let a small child play with fireworks.
[21:13] <nevcairiel> its not like its a common type of video
[21:13] <wm4> nevcairiel: you disable ffmpeg mt decoding for some codecs?
[21:13] <nevcairiel> i actually explicitly enable it on those where i want it
[21:13] <llogan> Daemon404: i would. i don't like kids.
[21:13] <nevcairiel> .. which is kinda all that support it, except mpeg4
[21:13] <nevcairiel> i should dig up that sample that broke with mt
[21:13] <nevcairiel> probably a seeking thing
[22:07] <cone-799> ffmpeg.git 03Carl Eugen Hoyos 07master:af7562a03556: Ignore es_map_length when parsing mpeg program stream map.
[22:09] <relaxed> ubitux michaelni, Hi. This change to freetype2 in debian unstable causes configure to fail with git when trying to enable it.  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731015
[22:14] <michaelni> relaxed, is there a tested patch that fixes it ? (i dont want to randomly change includes hoping it fixes something)
[22:14] <relaxed> http://pastie.org/pastes/8531653/text
[22:14] <relaxed> config.log ^^
[22:15] <relaxed> One on the libav devs said, "elenril : seems we're using the api wrong"
[22:15] <relaxed> I have no patch for it.
[22:16] <relaxed> I assume libav will patch it soon. I just wanted to bring it to your attention.
[22:19] <nevcairiel> michaelni: i have a h264 interlaced clip that multi-threads extremely poorly, and because its 4:2:2 10-bit, it barely reaches realtime speed. do you know if the mt capability of such interlaced clips can be improved?
[22:19] <nevcairiel> I can provide the sample once its finished uploading
[22:22] <beastd> relaxed: does it compile if loosen the configure check
[22:23] <relaxed> It expects /usr/include/freetype2/freetype/freetype.h which is now located at /usr/include/freetype2/freetype.h
[22:24] <relaxed> I'm confused by you're use of "loosen"
[22:24] <beastd> relaxed: I mean just change the code in configure to not test for freetype but assume it is there
[22:25] <beastd> it seems to me the issue is only in configure and not in the actual code using freetype
[22:29] <michaelni> nevcairiel, without seeing the clip, yes PAFF MT can be improved
[22:30] <nevcairiel> michaelni:  clip is here http://files.1f0.de/samples/h264-422-10bit-interlaced-slow-decode.mkv .. i can also open a ticket if you prefer
[22:30] <relaxed> beastd: I'm sure I could hack it to build for me but that's not important. This was just a heads up.
[22:30] <michaelni> nevcairiel, yes please open a ticket
[22:30] <nevcairiel> ok
[22:32] <beastd> relaxed: Sorry, just trying to offload a bit of work on you. Does configure succeed if you just drop the line that starts with  "enabled libfreetype"  ?
[22:34] <beastd> relaxed: if configure succeeds, it would be nice if you could try to build ffmpeg. i will look at how to fix configure in the meantime. just trying to make sure the drawtext filter does not have any problem but configure is the only culprit.
[22:37] <Zeranoe> Has there been recent development on how bitrate settings are applied? Before I didn't have th ability to control the bitrate of a encoder, now I do. 
[22:39] <Zeranoe> No wait, nevermind
[22:43] <relaxed> Did you read this? http://www.freetype.org/freetype2/docs/tutorial/step1.html
[22:50] <beastd> relaxed: I understood we should use the marco instead of the header name
[22:52] <beastd> and to my findings so far the drawtext filter is doing fine. i currently do not yet see a good way to bolt it on the configure check which is directly using the header name
[23:41] <beastd> That would be the ugly way to fix the freetype detection in configure:  http://pastebin.com/t5P8ZrjT
[23:42] <beastd> Beware untested. I have another idea to approach it.
[23:49] <Daemon404> why on earth does freetype do that
[23:50] <Daemon404> that is so incredibly braindead...
[00:00] --- Fri Dec  6 2013