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

[burek]

[00:01] <Daemon404> Skyler_, http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=23a8c63452009df21b3f184936b343593d4ccb04
[00:02] <cone-12> ffmpeg.git 03mrlika 07master:e2707a7cf741: avformat/mpegts: DVB subtitles multiple languages support
[00:44] <cone-12> ffmpeg.git 03Lukasz Marek 07master:db403023c016: lavd/opengl_enc: add gray8/16 formats
[00:44] <cone-12> ffmpeg.git 03Lukasz Marek 07master:db4a704482b0: lavd/opengl_enc: implement uncoded frame callback
[00:44] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:70acb1515912: Merge remote-tracking branch 'lukaszmluki/master'
[01:20] <JEEB> welp, sent that e-mail before running make fate-utvideoenc on this side. Aand this thing decided to rebuild everything in lavf it seems :| Oh well, at least lavc isn't completely rebuilt
[01:20] <JEEB> not that I expect the tests to fail
[01:23] <JEEB> yup
[01:23] <JEEB> utvideoenc tests pass
[01:23] <JEEB> all's fine
[01:23] <JEEB> should add some multi-slice tests later
[01:40] <cone-12> ffmpeg.git 03Janne Grunau 07master:f795a8a8bf5e: h264: make context_count unsigned
[01:40] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:84873794ad92: Merge commit 'f795a8a8bf5e312dad2c2829c543b9d309376ca1'
[02:05] <cone-12> ffmpeg.git 03Janne Grunau 07master:8a2250344b19: jv: detect partial packets in the demuxer
[02:06] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:abb6821e43e7: Merge commit '8a2250344b19a343d830a902dbcf4c0b929ea49b'
[02:33] <cone-12> ffmpeg.git 03Janne Grunau 07master:60e6cecf9bc7: configure: avserver does not need $ldl
[02:33] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:fd982f2b40b8: Merge commit '60e6cecf9bc7d6a238e6b316da52edcc6d1ef7f8'
[04:02] <cone-12> ffmpeg.git 03Janne Grunau 07master:d261719319a5: configure: do not link libraries against program-specific dependencies
[04:02] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:8dc5a46466de: Merge commit 'd261719319a505e1716e8b52fc955bef0503ff96'
[04:57] <cone-12> ffmpeg.git 03Janne Grunau 07master:73eca738acd0: mpeg12dec: do not add stereo3D side data to a non-existing frame
[04:57] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:abe3f79d62f4: Merge remote-tracking branch 'qatar/master'
[05:22] <cone-12> ffmpeg.git 03Lukasz Marek 07master:1e5cb426c687: lavd/avdevice: add param to create window buffer message
[09:00] <t355u5> Is it on purpose that ffmpeg -version in git gives this output 'ffmpeg version 2.1.git' instead of the usual 'ffmpeg version N-60836-g8bfa5a5'? This really makes it hard to differentiate the binaries. Can this be changed back?
[11:26] <ubitux> Daemon404: so you didn't change the AVERROR into EXTERNAL?
[12:39] <pross-au> BBB: if you are about, what VP8 streams are you using for benchmark & profiling
[13:23] <michaelni> t355u5, ffmpeg -version should print N-60597-g1e5cb42, try a fresh checkout in a seperate directory
[13:25] <t355u5> michaelni: will try that, thx
[13:32] <cone-526> ffmpeg.git 03Luca Barbato 07master:f8c507f44b4c: h264: Refactor ff_h264_decode_ref_pic_list_reordering
[13:32] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:5cbd7ce016ad: Merge commit 'f8c507f44b4c994895fc7ad954f009f61de69b1c'
[13:36] <JEEB> which does FFmpeg prefer when talking about v2 patches? in-reply-to or a new thread?
[13:39] <BBB> pross-au: parkjoy is ok, I don't really have a fixed one for vp8
[13:40] <BBB> pross-au: there's also sintel (we used that and parkjoy for the initial ffvp8 announcement post on jason's blog)
[13:40] <BBB> JEEB: I think whichever you prefer, most of us parse our mail inbox manually so we will read it regardless
[13:42] <JEEB> I don't really have a preference, and I'm already in-reply-to'ing @ Libav, so I guess I'll do that?
[13:45] <BBB> sure
[13:45] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:73e8fab31dc1: h264: print values in case of error
[13:45] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:60b46a00c62d: Merge commit '73e8fab31dc19c4371499e612856accbc00b2820'
[13:45] <pross-au> thanks. i have been using those, but they seem rather short given the huge performance gains since the initial ff VP8 work. i will look for something longer.
[13:50] <ubitux> hi durandal_1707 
[13:50] <ubitux> did you see the ticket for you?
[13:50] <ubitux> :)
[13:50] <BBB> pross-au: I thought sintel was long?
[13:52] <BBB> it's 1253 frames, is that enough?
[13:52] <BBB> else get etv5k from ubitux and encode it yourself, that works
[13:52] <ubitux> 'want a vp8 encode?
[13:53] <pross-au> even on my old core2, sintel decoders in 3.something seconds (mt), or 13s (single thread)
[13:54] <BBB> 13s is fine
[13:55] <BBB> anyway most vp7 patches look good, I'd like the actual vp8.c touching code to be made such that the condition is inlined though, so vp8 doesn't get slower
[13:57] <pross-au> over several runs, the user time variance here on a 13s decode is ~0.5%
[13:57] <BBB> that seems ok
[13:58] <BBB> (you know it took me 5 tries before I realize your patch [5/6] vp7 decoder is buried under [0/6])
[13:58] <BBB> so I just saw it for the first time
[13:59] <BBB> pross-au: what is copy_frame()?
[13:59] <pross-au> no worries. so you suggest moving the shared functions to vp78_template.h/c and inlining them
[13:59] <BBB> that seems really ugly, can't you use av_frame_ref()?
[14:00] <BBB> I guess you could template them, that's one way, yes
[14:00] <pross-au> copy_frame copies the AVFframe. there is probably an avutil equiv
[14:00] <BBB> why copy and not ref?
[14:00] <pross-au> #defines will be too messy!
[14:00] <BBB> it's ok, life is messy
[14:00] <pross-au> the copy is needed because the fade operation is destructive.
[14:01] <pross-au> vp8 is relatively mess-free
[14:01] <pross-au> s/is/was/
[14:02] <Skyler_> fade operation?
[14:02] <BBB> what is vp7_calculate_mb_offset?
[14:02] <BBB> vp7 has a fade?
[14:02] <BBB> so wait, you write a copy of the frame and then re-write all pixels post-fade?
[14:02] <pross-au> Skyler_: the vp7 codec has a 'fade' operation that adjust the lum of the previous frame
[14:03] <BBB> that seems odd, why not just do the fade without the double store?
[14:03] <pross-au> BBB: that would make sense.
[14:03] <BBB> how are vp7_decode_mvs and vp8_decode_mvs different?
[14:03] <pross-au> vp7_calculate_mb_offset. ugh, there are bugs in VP7 that we must emulate
[14:03] <Skyler_> does fade replace the original frame in the reference buffer?
[14:04] <Skyler_> or does fade only affect it for the current frame, and not again?
[14:04] <BBB> do segmentation features in vp7 require an error and return instead of a warning and continue?
[14:04] <BBB>  if (s->vp7) { //FIXME: clueless as to why VP8 does not require this
[14:05] <BBB> we memset in the idct
[14:05] <BBB> so all data post-idct and on init is always zero
[14:05] <BBB> you probably want to do that in vp7 also - it's faster
[14:05] <Skyler_> http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154447.html   ugh, it's missing the patch, I wanted to look at it
[14:05] <BBB> Skyler_: it's there, but gmail orders it in the same thread as [0/6]
[14:06] <Skyler_> I was looking at the archives
[14:06] <BBB> pross-au: it might be that the memset is required when you predict but the block is skip so you don't use the coefficients; so skip the dc predict if skip=true, so you don't need to zero
[14:06] <BBB> pross-au: that's about all the comments I have so far
[14:06] <pross-au> BBB: VP7 mv prediction can go far back as (-2,-2) relative to the current macroblock. the decoder doesn't guard this properly. e.g. when mb_x=0, an xoffset -1 is denied, but xoffset -2 is permitted.
[14:07] <pross-au> idct: great that solves that riddle
[14:07] <BBB> Skyler_: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154452.html
[14:07] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:3a0576702825: h264: store current_sps_id inside the current sps
[14:07] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:99b12357f47e: Merge commit '3a0576702825423abecb32627c530dbc4c0f73bc'
[14:07] <Skyler_> ohhhh there it is, thanks
[14:08] <BBB> Skyler_ will likely have more comments, but as I said, the inlining of if (vp7) is the most important, that'll remove most of the speed impact on vp8
[14:08] <BBB> it will make the binary slightly bigger but I don't think anyone cares about that
[14:08] <BBB> chrome is like 100s of MBs so a few extra kb for ffmpeg.exe is irrelevant
[14:08] <BBB> brb
[14:08] <pross-au> Skyler_:  the fade (if enabled in the header) is applied to the previous frame. 
[14:09] <Skyler_> I guess doing the weighting in the MC would be less efficient than copying the whole frame...
[14:10] <BBB> looks like fade doesn't replace the reference
[14:10] <BBB> if I can see
[14:10] <BBB> anyway, brb
[14:10] <pross-au> well i have ONE sample with fade.
[14:11] <j-b> do you have enough VP7 samples?
[14:11] <pross-au> hardly worth optimising that case
[14:11] <j-b> I thought it was very rare
[14:11] <pross-au> yeah i found a huge archive on the web. non-english :)
[14:11] <kierank> lol
[14:12] <j-b> crazy :)
[14:12] <JEEB> I remember around 2007 a Japanese IRC friend of mine had put some encodes for this new VP7 format up for me
[14:12] <JEEB> I had downloaded them, too
[14:12] <pross-au> conspiracy, 911, cia, allah stuff
[14:12] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:15210354cf27: h264: drop outdated comments
[14:12] <JEEB> then didn't take long for it to get bulldozed over by x264
[14:12] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:a7eb93b3671f: Merge commit '15210354cf27cf4e24d91f84d66cf471511ce718'
[14:13] <JEEB> too bad the guy didn't have the samples any more :<
[14:13] <Skyler_> there's still a public free vp7 encoder isn't there, right?
[14:13] <pross-au> yes
[14:13] <JEEB> the vfw one most probably, yes
[14:13] <pross-au> archive.org
[14:13] <JEEB> :)
[14:14] <pross-au> the old on2 site with all the downloads is no more. but archive.org has captured many of the exe
[14:14] <durandal_1707> ubitux: what happens if you at line 518 change < to <= ?
[14:15] <ubitux> what file?
[14:15] <Skyler_> someone probably already said this but read_mv_component should be templated into vp8/vp7 versions
[14:16] <Skyler_> rather than being passed s->vp7
[14:16] <durandal_1707> ubitux: libavfilter/af_compand.c
[14:16] <Skyler_> er, decode_splitmvs should I guess
[14:16] <merbanan> JEEB: do you have any UMD movies ?
[14:16] <JEEB> yeah
[14:16] <pross-au> Skyler_: okay
[14:16] <JEEB> merbanan, do you need a full dir structure or you're OK with just the MPEG-PS?
[14:16] <ubitux> durandal_1707: line 518 is EOF
[14:16] <ubitux> durandal_1707: or i'm missing sth?
[14:16] <merbanan> JEEB: the mpeg-ps
[14:16] <JEEB> k
[14:17] <merbanan> JEEB: or does it already work playing those files ?
[14:17] <JEEB> merbanan, http://fushizen.eu/u/jeeb/derp/00002.MPS
[14:17] <Skyler_> +    } else \n if (s->segmentation.update_map) {
[14:17] <JEEB> the audio doesn't get found
[14:17] <JEEB> the video works JustFine
[14:17] <Skyler_> nitpick but I think we usually drop the \n there?
[14:17] <ubitux> (yes)
[14:17] <merbanan> JEEB: MUST BE FIXED
[14:17] <JEEB> http://up-cat.net/p/dcaccb79
[14:18] <merbanan> the world has been waiting for so long ....
[14:18] <JEEB> which stream it is gets pretty obvious as looking at the output of that bbdmux thing :)
[14:18] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:304e916a92bc: h264_sei: name buffering period type consistently
[14:18] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:1d91af5abae8: Merge commit '304e916a92bc17385a485bec2f957e192257ddb6'
[14:18] <durandal_1707> ubitux: 158 :)
[14:18] <JEEB> also I tried to parse the packet it begins with, but that seems to be malformed or something?
[14:18] <JEEB> (in a hex editor)
[14:18] <JEEB> or I'm just failing at parsing MPEG-PS by hand, har har har
[14:19] <JEEB> also it seems like UMD videos were encoded with the same early'ish H.264 encoders that brought us the blu-rays with the full range flag on :)
[14:19] <ubitux> durandal_1707: testing equality on fp?
[14:19] <ubitux> durandal_1707: still failing btw
[14:19] <durandal_1707> hmm, you have sox installed?
[14:21] <JEEB> merbanan, I hope you will have more luck with lavf/mpeg.c than I had :)
[14:21] <merbanan> JEEB: we'll see what we can extract, getting lavf to demux the stream shouldn't be that big a problem
[14:21] <merbanan> the smaller stream should be the subtitles
[14:22] <JEEB> I should probably dump my spiderman UMD, too
[14:22] <cone-526> ffmpeg.git 03Vittorio Giovara 07master:066ad249843b: h264_sei: reorder headers
[14:22] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:a062bee1c127: Merge commit '066ad249843bde656265b59110c2521e2b1ce131'
[14:23] <Skyler_> wow.  I'm surprised by how... undifferent vp7 is from vp8
[14:25] <ubitux> durandal_1707: no but i can install it
[14:25] <ubitux> durandal_1707: ok now it's installed
[14:25] <pross-au> the on2 engineers have pioneered the tick tock approach to codec manufacturing. 3->4, 5->6, 7->8, 9->...
[14:26] <nevcairiel> what was it you said, its vp8 with less features and more bugs?
[14:26] <durandal_1707> ubitux: now try to see if with same arguments and sample you get overread..
[14:27] <pross-au> yep
[14:27] <BBB> Skyler_: pross-au: I think the whole sequence of calls all the way down from vp8_decode_frame should be templated
[14:28] <BBB> (since there's just so many if (vp7)s in there that are per-mb)
[14:28] <Skyler_> I wonder if it'd be easier to make a template file and include it in two separate c files or something.  that much templating feels ugly either way, I guess
[14:29] <pross-au> should there be only vp8.c, or move common stuff to vp78_template spilt in two
[14:30] <ubitux> durandal_1707: i have no idea how sox works :)
[14:30] <BBB> Skyler_: that would work yes
[14:30] <ubitux> durandal_1707: can you provide something i can copy paste?
[14:30] <BBB> but I don't mind how it's templated, as long as vp8 doesn't get significantly slower :-p
[14:30] <BBB> bbl work
[14:32] <pross-au> the upside, this approach will also speed up vp7, for all 3 of its users
[14:40] <durandal_1707> ubitux: perhaps you could try random thing from sox manual
[14:42] <ubitux> durandal_1707: i think i'll work on sth else instead
[14:51] <durandal_1707> what you said? :) carry on!
[14:54] <ubitux> durandal_1707: i prefer if you fix your own bug ;)
[14:54] <ubitux> i don't mind testing for you ofc
[14:55] <durandal_1707> np
[14:57] <pross-au> hmmm, there are more vp7 torrents, than there are vp8 and vp9 combined.
[14:58] <nevcairiel> who puts stuff in  vp7
[14:59] <cone-526> ffmpeg.git 03Diego Biurrun 07master:f1f42cfc6680: build: Do not pass HTML snippets and stylesheet as input to Doxygen
[14:59] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:2fd0b5bd60b3: Merge commit 'f1f42cfc66804907d1df9231469e4296472bb0f5'
[15:01] <pross-au> on2
[15:01] <nevcairiel> then the other questions, who torrents that
[15:03] <durandal_1707> i hope it is something useful
[15:05] <JEEB> vp7 used to have some use for a while, but it surely didn't take long for everyone and their dog to notice that using x264 was a much better alternative
[15:05] <JEEB> on the other hand, with vp8/9 it's mostly troll torrents
[15:08] <ubitux> JEEB: why? isn't vp9 decoder good enough now?
[15:08] <ubitux> :)
[15:08] <JEEB> oh the decoder is :)
[15:08] <ubitux> libvpx, even though it's slow, should provide better results that x264, isn't it?
[15:09] <JEEB> I haven't tested it lately, but that's possible since the format seems better than AVC
[15:09] <durandal_1707> is James Darnley here?
[15:09] <JEEB> it's J_Darnley 
[15:10] <durandal_1707> J_Darnley: why gpl for flac asm?
[15:14] <kierank> ubitux: that's quite a contentious issue
[15:14] <kierank> but on paper yes
[15:16] <pross-au> 'tuning'
[15:23] <cone-526> ffmpeg.git 03Diego Biurrun 07master:19d3127867f0: doxygen: Set EXAMPLE_PATH from within doxy-wrapper.sh
[15:23] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:cbf09bb63f31: Merge commit '19d3127867f001d007f98bc8c5a85c5409abf788'
[15:27] <J_Darnley> durandal_1707: I greatly prefer the GPL
[15:28] <J_Darnley> And on an optional bit of code like this, it doesn't make much difference
[15:28] <J_Darnley> To the user of library that is
[15:29] <cone-526> ffmpeg.git 03Diego Biurrun 07master:3a26ccbf0d9f: build: doxy: Include code examples in Doxygen documentation
[15:30] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:71052d85c16b: Merge commit '3a26ccbf0d9f806d067e76a3f484170abecb36b3'
[15:30] <kurosu_> actually, I was thinking naming a file flac_dsp_gpl was bothersome and %if CONFIG_GPL could have achieved the same
[15:31] <kurosu_> but then there is the license in the file header
[15:31] <kurosu_> so people wishing to write further lgpl flac dsp will probably need another file with a different header
[15:31] <kurosu_> that and it's pesky and bothersome for people that should use their time for better things
[15:32] <J_Darnley> There is the other James' flac dsp contributions in a non-gpl file
[15:34] <J_Darnley> In my opinion you should be very clear about the license of a file in a mixed project like this
[15:37] <cone-526> ffmpeg.git 03Diego Biurrun 07master:0b9716c45568: doc/examples: misc Doxygen markup improvements
[15:37] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:fba1592f3550: Merge remote-tracking branch 'qatar/master'
[15:37] <durandal_1707> J_Darnley: there is code that does same thing but in another license?
[15:38] <J_Darnley> No
[15:38] <J_Darnley> His is for the decoder
[15:38] <J_Darnley> Mine is for the encoder
[15:38] <Daemon404> ew, we're adding gpl-only asm?
[15:38] <Daemon404> how lovely
[15:39] <Compn> you can still sell it , just have to provide source bro
[15:39] <kurosu_> why not? I have myself been a pain some years ago and requested a (3-clauses, iirc) BSD license
[15:39] <durandal_1707> like it matters.....
[15:39] <Compn> china doesnt care for licenses
[15:40] <Daemon404> 3-clause bsd doesnt cause any issues
[15:40] <kurosu_> yea, actually less, because no configure worries and so on
[15:41] <kurosu_> to me, it just means anyone is free to use that code however he likes
[15:41] <Daemon404> i, myself, dont subscribe to the rms-style of freedom
[15:41] <durandal_1707> we should really switch to AGPL and make big monez
[15:41] <kierank> that's what gpac wanted
[15:41] <Compn> oh no not another license bikeshed :P
[15:41] <kierank> iirc use of AGPL means I would have to stick a notice on all my tv channels
[15:41] <J_Darnley> I don't go quite that far either.  I'm using Windows after all.
[15:41] <Daemon404> gpac can do what they want
[15:42] <Daemon404> i dont use their broken software
[15:42] <kierank> Daemon404: gpac want a cloud gpl
[15:42] <kierank> Daemon404: so people who use it in the cloud need to release source
[15:42] <Daemon404> maybe it would teach them to use better software
[16:05] <JEEB> talking of GPAC, I just sent this PR to l-smash :) https://github.com/l-smash/l-smash/pull/14
[16:15] <cone-526> ffmpeg.git 03Werner Robitza 07master:1ffac25d31eb: doc/filters/histogram: copyedit for grammar
[16:23] <wm4> hilarious when I have to add workarounds for broken files, and then find out that these files were generated by ffmpeg
[16:23] <JEEB> :D
[16:23] <JEEB> that happens at times
[16:23] <j-b> wm4: this never happens
[16:23] <j-b> JEEB: at times?
[16:24] <wm4> apparently this file was created by transcoding DVB to vobsub
[16:24] <j-b> A lot of MKV produces by ffmpeg were not conform (maybe it is fixed). Ogg and ASF were not better
[16:24] <JEEB> exactly what I mean :)
[16:24] <j-b> TS is broken, but that's normal, it's TS
[16:25] <JEEB> yeah, only kierank has given enough love to it
[16:25] <nevcairiel> its pretty usual for muxed files to fail, especially MKVs, because it just tries to mux anything, but hardly knows about all the special ways to mux things
[16:26] <JEEB> yeah, it has the generic route
[16:26] <nevcairiel> I use ffmpeg TS muxer for HLS, seems to work pretty nice on a wide variety of devices so far, so i can't complain :d
[16:26] <JEEB> yeah, nothing seems to be strict in that area
[16:26] <JEEB> so you're more or less OK :)
[16:26] <wm4> I have to say that I'm impressed that transcoding dvb sub to vobsub works at all
[16:26] <wm4> but ffmpeg forgot to set the resolution
[16:26] <wm4> and also wrote random crap into the idx file (???)
[16:26] <wm4> idx file aka matroska vobsub codec data
[16:31] <kurosu_> wm4: some people call this "securing opportunities for work in the future" (old joke about paid jobs, may not apply here perfectly)
[16:32] <wm4> maybe that applies to stuff like apple's highly expensive applications writing mov files that violate apple's own spec
[16:33] <kurosu_> is there a way to do s/Libav/ffmpeg during a cherry-pick ?
[16:33] Action: ubitux always chills when hearing about vobsub in ffmpeg
[16:34] <JEEB> wm4, quicktime violates its own file format's spec all the time :P
[16:34] <ubitux> wm4: that resolution is probably not exported from the dvb sub
[16:37] <j-b> btw, what does AppleRottenFruit use for subtitles now?
[16:39] <wm4> ubitux: I think dvb and pgs set the resolution on the first subtitle packet or somewhere later
[16:39] <JEEB> I don't think they ever moved away from their timed text?
[16:40] <Daemon404> hey! safari can use webvtt!
[16:40] <JEEB> Ù‰cWƒDc

[16:41] <JEEB> (that said, webvtt in its simplest is just srt, so I guess it's not The Satan yet)
[16:41] <Daemon404> srt is actually very very annoying and error prone to parse
[16:41] <Daemon404> despite looking simple
[16:41] <Daemon404> :V
[16:42] <JEEB> to quote a certain famous singer, "You're the Devil in Disguise"
[16:55] <durandal_1707> the srt?
[16:56] <Compn> j-b : it looks like you need a plugin to deal with subtitles for final cut pro, so it converts an srt to timed text
[16:57] <Compn> http://documentation.apple.com/en/finalcutstudio/workflows/index.html#chapter=6%26section=4%26tasks=true
[16:59] <Compn> j-b : also , heres how much apple cares about documentation , http://www.apple.com/quicktime/tutorials/texttracks.html has been 404 for years.
[17:00] <Compn> hey look, google and apple opensourced it
[17:00] <Compn> http://www.opensource.apple.com/source/WebCore/WebCore-7536.30.2/html/track/TextTrack.cpp
[17:00] <Compn> whatever the heck that is
[17:02] <Compn> ffmpeg site:opensource.apple.com
[17:02] <Compn> neat 
[17:03] <Compn> webkit stuff
[17:04] <Daemon404> hey kierank 
[17:04] <Daemon404> http://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper_December_2013.pdf
[17:04] <Daemon404> did oyu know ffmpeg made it into their latest whitepaper
[17:05] <Compn> ehe i saw that a while back
[17:05] <Compn> they should have just said 'ffmpeg sucks'
[17:05] <Daemon404> some of their authorized products use ffmpeg for prores
[17:06] <ubitux> :D
[17:06] <Compn> the authorized software 3rd parties or apple stuff itself ?
[17:06] <ubitux> haha
[17:06] <Daemon404> former
[17:06] <Daemon404> duh
[17:07] <Compn> is our decoder/encoder faster than apples ?
[17:07] <Compn> i forgot benchmarks
[17:08] <kierank> Daemon404: not true
[17:08] <kierank> what authorised stuff uses ffmpeg
[17:09] <Daemon404> hmm maybe i was mistaken
[17:09] <Daemon404> i thought i spotted a few that did
[18:01] <Daemon404> i see there's an influx of really dum libx265 questions on the user ML...
[18:01] Action: Daemon404 is luckily not subscribed
[18:10] <J_Darnley> Daemon404: whuch user list?  x265's?
[18:11] <Daemon404> ffmpeg's
[18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:5df2a502f214: ffserver: avoid useless substitution
[18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:ba6186d6eb31: ffserver: factor out connection closing from handler
[18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:35e525b73263: ffserver: fix some comments
[18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:720530e52aec: ffserver: cosmetics
[18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:87079bd055e3: ffserver: merge RTSP's teardown & pause routines
[18:37] <cone-526> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:9ed876ac92b9: MAINTAINERS: add myself as ffserver maintainer
[20:52] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:68a959cb2717: avcodec/utils: improve guess_correct_pts() by considerng mixed dts/pts use caused by NOPTSs
[20:52] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:480af3a35ce3: avformat/utils: skip the MPEG-2 style dts/pts code for HEVC
[20:59] <J_Darnley> fg
[21:06] <durandal_1707> is there way to transfer year-month-day time to pts?
[21:21] <Compn> LOL
[21:22] <Compn> i picked random sample in sample repo and its porn :\
[21:22] <reynaldo> Compn: \o/
[21:22] Action: Compn picks other sample
[21:22] <durandal_1707> Compn: you already watched it....
[21:22] <reynaldo> out of pure scientific interest, what sample was that?
[21:22] <Compn> durandal_1707 : yes but should i post it to the list asking people to test it ?
[21:22] <durandal_1707> scientific?
[21:23] <Compn> reynaldo : http://samples.ffmpeg.org/MPEG1/mpeg_demuxer_crash.mpg
[21:23] <Compn> innocent looking name.... :P
[21:23] <reynaldo> durandal_1707: sure, I was to make sure it playbacks ok
[21:23] <reynaldo> was/want
[21:25] Action: Compn picks zelda commercial instead
[21:30] <Compn> libavformat version 55.30.100 (internal)
[21:30] <Compn> https protocol not found, recompile with openssl or gnutls enabled.
[21:30] <Compn> urgh
[21:36] <Compn> no native https ? :P
[21:36] <cone-526> ffmpeg.git 03Derek Buitenhuis 07master:41836c4e306e: libx265: Fix use of uninitialized input picture
[21:36] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:374576d6ee68: Merge commit '41836c4e306e572ecf80d5a714aaec532c7ece60'
[21:37] <cone-526> ffmpeg.git 03Derek Buitenhuis 07master:4127e6aeb6e9: libx265: Remove redundant default param call
[21:37] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:92225877cee1: Merge commit '4127e6aeb6e9ef53f5acf06e99c06f4b2c0cce34'
[21:40] <durandal_1707> are you out of your mind?
[21:43] <Compn> it was in jest :)
[21:57] <cone-526> ffmpeg.git 03Jan Ekström 07master:3fbad0071469: utvideoenc: Enable support for multiple slices and use them
[21:57] <cone-526> ffmpeg.git 03Jan Ekström 07master:efec857c9f70: utvideoenc: Enable support for multiple slices and use them
[21:57] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:e136579ca358: Merge commit '3fbad00714698f59c6326edfcc63db87f525e7c0'
[22:07] <cone-526> ffmpeg.git 03Janne Grunau 07master:98fdfa99704f: ppc: reduce overreads when loading 8 pixels in altivec dsp functions
[22:07] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:f11905763cda: Merge remote-tracking branch 'qatar/master'
[23:28] <cone-526> ffmpeg.git 03Peter Ross 07master:c55143179234: avcodec/h264pred: deconflict DC_128_PRED and HOR_VP8_PRED
[00:00] --- Sat Feb 15 2014