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

[burek]

[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