[00:37] <ubitux> BBB: what about the 64x64 blocks in vp9? [00:37] <ubitux> BBB: do transforms for those blocks really exist? or they're only "segmentable" in 32x32 and smaller? [00:38] <libfud> hey all, I don't know how important to you this is, but I'll say it anyway. Statically building ffmpeg against musl instead of glibc fails unless you patch libavutil/error.c to include string.h and use -D_BSD_SOURCE as a CFLAG [00:38] <libfud> sorry if this isn't the right place to say it [00:40] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:8349be852be7: avformat/lxfdec: use a parser to parse video frame headers [00:49] <michaelni_> libfud, can you submit a clean patch that fixes this ? [00:50] <libfud> michaelni_: sure thing [00:51] <libfud> I have the patch uploaded already to https://github.com/libfud/sabotage/blob/newpkgs/KEEP/ffmpeg-avutil.patch [00:51] <libfud> where do I submit it to? [00:51] <ubitux> libfud: system header on top [00:51] <libfud> oh [00:52] <ubitux> also, a patch needs to be against git/HEAD [00:52] <libfud> ok, I'll write it against that [00:52] <ubitux> thx [00:52] <libfud> no problem [00:52] <libfud> I'm pretty new to this kind of stuff [00:53] <libfud> so I appreciate being told when I'm doing something fucked up [00:53] <michaelni_> about submit to: ffmpeg-devel mailing list (https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/) [00:54] <durandal_1707> libfud: musl? [00:54] <libfud> so, above #undef _GNU_SOURCE or below that [00:55] <libfud> durandal_1707: http://www.musl-libc.org/intro.html [00:56] <durandal_1707> well if you want it get fixed you either: report bug or sent patch or find someone who will do it for you [01:07] <libfud> I sent an email to the mailing list [01:20] <iive> libfud: nice to see musl getting more popular [01:21] Action: pippin also enjoys musl ;) [01:22] <iive> :O [01:23] <libfud> yeah [01:23] <iive> on what platform are you using it? [01:23] <libfud> I've fallen in love with it, everything builds a hell of a lot faster [01:24] <libfud> well, I started testing it out on fedora x86, but I'm currently chrooted into sabotage [01:24] <libfud> which I can boot from but I can't figure out how to get X running properly yet [01:24] <pippin> iive: I use it on arm [01:25] <pippin> (kobo ereaders actually) [01:25] <libfud> heh [01:26] Action: pippin should probably give hacking up ffplay for the kobo a go; it will probably work at ~10fps but have no sound :p [01:27] <iive> too bad I have to leave. [01:28] <iive> libfud: do you mean that musl compiles faster or that gcc compiles everything faster under musl? [01:29] <libfud> gcc compiles faster when linking against musl than glibc [01:29] <iive> hehe, sounds grate. [01:29] <libfud> or so it seems to me, I remember how long building certain packages took with gentoo [01:29] <libfud> which def. used glibc and not musl [01:30] <iive> I know the author spent quite some time polishing memory allocations and thread creation. [01:30] <iive> well, have fun. gtg [01:30] <libfud> see you later [01:30] <iive> n8 ppl. [01:35] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:03882030982c: avformat/utils: fix duration_fields calculation when need_parsing=0 [04:27] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:990bbc15b8e7: avcodec/error_resilience: change out commented printf() to av_log() [04:27] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:93cf7b01950b: avcodec/h264: set er.ref_count earlier [10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/1.1:e27fab0e6ee0: avformat/lxfdec: use a parser to parse video frame headers [10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/1.2:95d0baa95217: avcodec/h264: set er.ref_count earlier [10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/1.2:458933fdb8d5: avformat/lxfdec: use a parser to parse video frame headers [10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/2.0:be47e931343e: avcodec/h264: set er.ref_count earlier [10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/2.0:237ef710a177: avformat/lxfdec: use a parser to parse video frame headers [10:52] <ubitux> fun, ted hardcode subtitles now for various formats & languages [10:53] <ubitux> i wonder why they just didn't mux them [11:40] <cone-108> ffmpeg.git 03Stefano Sabatini 07master:51b01573e536: ffprobe: fix format section XML validation [11:40] <cone-108> ffmpeg.git 03Stefano Sabatini 07master:291ad12ea2d1: ffprobe: show probe_score in the format section [12:58] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:d7f917c37af2: fate: update fate tests after master:291ad12ea2d1: ffprobe: show probe_score in the format section [13:06] <cone-108> ffmpeg.git 03Christian Schmidt 07master:a42e3a670054: pcm_dvd: consolidate pieces from pcm.c and mpeg.c [13:06] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:cb4d05e7f256: Merge commit 'a42e3a6700547e4e49445bda81d3a89ec3e081a9' [13:07] <cone-108> ffmpeg.git 03Martin Storsjö 07master:789cd1de99cd: pcm-dvd: Fix build on big endian [13:07] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:7c1805869d6f: avcodec/pcm-dvd: discard buffer if block size changed [13:36] <cone-108> ffmpeg.git 03Diego Elio Pettenò 07master:faa8245bd45c: vf_lut: Constantize [13:36] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:67d7ea9825f6: Merge commit 'faa8245bd45c1a6dd220ba9407ea1c82132aa1ce' [14:00] <cone-108> ffmpeg.git 03Vittorio Giovara 07master:f4ca970dba13: configure: Add docdir configuration option [14:00] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:d8809b357c5e: Merge commit 'f4ca970dba13a60a1334cce1b574036e6f624b9c' [14:14] <cone-108> ffmpeg.git 03Martin Storsjö 07master:21ffd4101167: pcm-dvd: Fix build on big endian [14:14] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:8901f48e636b: Merge remote-tracking branch 'qatar/master' [14:54] <compn> what is the status of redcode support?. [14:54] <compn> and bayer rgb [14:54] <compn> colorspace [15:34] <michaelni__> compn, i wanted to work on bayer rgb in ffv1 and maybe sws if noone else does it (peter had worked on that a bit) [15:34] <compn> yeah, i see peters patch from 2012 [15:36] <compn> maybe ping him? [15:37] <michaelni> compn, dont hesitate to ... and feel free to cc me [15:37] <wm4> so, I have a .ts sample that works fine with the vlc and mkvmerge demuxer, but not libavformat or mplayer [15:38] <wm4> how do I make someone care [15:38] <compn> upload it [15:38] <michaelni> compn, i mean if you ping privately, if its on ffmpeg-dev no need to cc :) [15:39] <wm4> compn: one example (a user uploaded it, sorry for the hoster he picked): https://mega.co.nz/#!zR0wWK4L!B-RGF3sreOsUMyBshBQc8x74iRhtNi7tFt3Wcu74vUE [15:39] <compn> ok michael, just im on a tablet, in france, so even writing emails is not easy ehe [15:39] <wm4> works perfectly in vlc [15:40] <wm4> ffplay craps itself (so does anything mplayer with -demuxer lavf) [15:40] <wm4> mplayer's -demuxer mpegts appears to work fine, but actually video timestamps are jumping around [15:41] <wm4> (it basically works only because mplayer is in a mode that ignores video timestamps for most of playback, hurr) [15:48] <michaelni> compn, no hurry it can wait until you have a real keyboard to type [15:58] <compn> argh mega's js is so bloated [16:07] <wm4> compn: it's bloated on purpose [16:17] <iive> compn: you are in france. congratulation (y) [17:48] <cone-108> ffmpeg.git 03Peter Ross 07master:9116995efb9c: libavutil: add AV_PIX_FMT_BAYER pixel formats [17:48] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:4aeb996f71bd: pixfmt: add native bayer 16bit formats [18:05] <wm4> what are these bayer things? [18:05] <Daemon404> colorspaces [18:05] <Daemon404> many cameras use them [18:05] <wm4> shouldn't this be a raw codec instead of it's so irregular [18:09] <wm4> "The pixel format descriptors are set to more or less arbitrary values as bayer formats do not fit in the descriptors structure." [18:09] <wm4> oh the fun [18:10] <michaelni> the problem with a raw codecs for it is that there are codecs that store bayer and id like to add support to ffv1 for it too [18:10] <michaelni> s/a// [18:11] <wm4> if the pixdescs make no sense, maybe they simply shouldn't be set (like with hwaccel formats) [18:11] <michaelni> yes, they are pretty much set only minimally to get the average bits per pixel correct [19:06] <nevcairiel> builds fail completely now if texi2html is not present? whats this madness? [19:07] <wm4> yeah, I've noticed someone else had the same problem, I think [19:09] <nevcairiel> half of fate is red because of that [19:09] <wm4> heh [19:10] <wm4> so it seems the mpc8.c decoder can return 0, which means it wants to packet to be repeated [19:11] <wm4> a bit odd... is it guaranteed it can't cause the caller to enter and endless decoding loop? [19:11] <wm4> s/and/an/ [19:13] <nevcairiel> some codecs work like that, they decode subframes separately to lower latency for example, and needs to be called a few times with the same packet [19:13] <nevcairiel> if thats something mpc8 does, or if its just bugged, i couldnt tell [19:14] <wm4> normally you'd expect them to return the number of bytes consumed (as it is documented) - but I suppose some codecs need the full packet or so to decode more sub frames or so [19:16] <nevcairiel> it could also be that it consumes the packet the first call, and then refuses to consume nothing of the next packet until it decoded the first one completely [20:04] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:91acb23a2880: doc: fix insane hard texi2html dependancy [21:23] <cone-108> ffmpeg.git 03Paul B Mahol 07master:fc435d977a53: pcm-dvd: remove redundant log message [21:23] <cone-108> ffmpeg.git 03Paul B Mahol 07master:5be7aecc80b5: pcm-dvd: use av_freep() [22:08] <durandal_1707> something is making red fate [22:14] <Daemon404> /bin/sh: texi2html: not found [22:14] <Daemon404> make: *** [doc/ffmpeg.html] Error 127 [22:14] <Daemon404> someone mae texi2html non-optional [22:14] <Daemon404> made* [22:17] <nevcairiel> that should already be fixed again [22:17] <nevcairiel> my fate boxes passed again [22:17] <Daemon404> nevcairiel, its a shame you could come to VDD [22:17] <Daemon404> lots of fun, lots of trolling [22:18] <Daemon404> couldnt8 [22:18] <Daemon404> * [22:19] Action: ubitux finds those social events kind of extremely boring at some point though [22:19] <Daemon404> you werent in many of the interesting rooms [22:19] <Daemon404> or at least i didnt see you in them [22:20] <ubitux> the only interesting one was ffmpeg ;) [22:20] <Daemon404> daala was quite interesting [22:20] <Daemon404> tim is awesome [22:20] <ubitux> i was there [22:20] <Daemon404> i also herped and derped in the x265 room [22:20] <Daemon404> and spent a bunch of time talking to that youtube guy [22:20] <ubitux> i was afraid of a huge amount of trolling in x265 so i didn't go there [22:21] <Daemon404> i took the piss out of the [22:21] <Daemon404> m [22:21] <Daemon404> <_< [22:21] <ubitux> yeah the youtube discussion in ffmpeg room was cool [22:21] <ubitux> which means 2 hours were enough instead of the week end, at least for me [22:21] <durandal_1707> how many were in that room? [22:21] <ubitux> i felt like wasting my time a bit, but that was expected [22:22] <ubitux> durandal_1707: around 12 iirc [22:22] <Daemon404> well, i didnt get bored anyway [22:22] <Daemon404> lots of people to talk to [22:23] <Daemon404> also i didnt see you at parc asterix [22:23] <durandal_1707> ubitux: so what it was all about? [22:23] <durandal_1707> you never saw me [22:23] <Daemon404> i was talking about ubitux [22:24] <Daemon404> actually the only one i saw ther was compn, i think [22:24] <ubitux> durandal_1707: the youtube guy expressed his will to help and raised the main issue they have with ffmpeg [22:24] <Daemon404> ubitux, he also told me hes sending an edit list patch soon (tm) [22:24] <durandal_1707> yes... (i'm all ears) [22:25] <wm4> edit lists? [22:25] <Daemon404> mp4 edit lists [22:25] <wm4> ew [22:25] <ubitux> durandal_1707: which is basically mov/mp4 edit list, captionning, and some colorspaces issues [22:25] <ubitux> also mpegts bad support forcing them to hf with mencoder [22:25] <ubitux> and he was asking what youtube could do to help [22:25] <wm4> haha [22:26] <wm4> port vlc's ts demuxer? [22:26] <Daemon404> ubitux, he also wanted to do something with vimeo, like a big regression suite/test using our samples [22:26] <wm4> and kill the old code with fucking fire [22:26] <Daemon404> i think kind of like coverity, giving the devs access [22:26] <Daemon404> or something like that, perhaps separate [22:27] <ubitux> ah btw, kierank [22:27] <ubitux> how is the gpu draft? :) [22:29] <ubitux> <@Daemon404> also i didnt see you at parc asterix // i don't find much things fun tbh, and especially not that kind of activities [22:29] <Daemon404> heh [22:30] <kierank> ubitux: opus in TS draft first [22:30] <ubitux> :( [22:31] <durandal_1707> gpu draft? [22:31] <kierank> ubitux: opus in TS is more interesting than GPUs, no? [22:31] <kierank> durandal_1707: explain to people why GPU encoding is a scam [22:32] <kierank> And doesn't work [22:32] <ubitux> kierank: not for me [22:32] <Daemon404> i can perhaps start a rough point form list [22:32] <Daemon404> i get enogh BS email about GPUs [22:32] <Daemon404> but not tonight [22:32] <wm4> I thought hardware based encoding is normal for consumer cameras and TV stations and such? [22:34] <ubitux> ow and i almost forgot to watch the eotena ep this w-e with all those adventures! [22:59] <kierank> wm4: hardware encoding is not the same as gpu [23:31] <funman> 22:26 <+wm4> port vlc's ts demuxer? [23:33] <funman> ubitux: do you remember what problem he (Thierry) had with ts ? [23:33] <ubitux> nope [23:36] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:c72cca5a44d8: avcodec/ffv1dec: move initial_states init to init_thread_copy() [23:36] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:21dc3a3cc23c: avcodec/ffv1dec: reorganize thread init/update [23:37] <wm4> funman: well, there are some samples around [23:37] <durandal_1707> there are reported bugs [23:40] <funman> wm4: if you have a link i can test them with vlc, i have a few samples that are not working as well [23:40] <wm4> funman: a user linked me this today, I think it plays fine in vlc https://mega.co.nz/#!zR0wWK4L!B-RGF3sreOsUMyBshBQc8x74iRhtNi7tFt3Wcu74vUE [23:41] <wm4> it appears you got completely broken timestamps with libavformat, or something similarly weird [23:49] <funman> yup, mplayer plays it as well btw [23:57] <wm4> funman: mplayer doesn't handle it really well, for one, mplayer mostly ignores video timestamps in this case, and you can see the playback time "fluctuating" [00:00] --- Mon Sep 2 2013