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

[burek]

[00:00:18 CEST] <wm4> how does git LFS work? (yeah I'm totally too lazy to look it up)
[00:00:40 CEST] <Daemon404> its github's thing
[00:00:43 CEST] <Daemon404> google it
[00:01:12 CEST] <llogan> he can't. too lazy.
[00:02:02 CEST] <Daemon404> it works by running some code and doing some operations
[00:02:04 CEST] <Daemon404> presumably on file.s
[00:05:12 CEST] <wm4> so it basically works around git's database for file contents
[00:05:30 CEST] <wm4> and stores the actual contents separately
[00:05:47 CEST] <wm4> reminds me of git submodules, I hope its not as bad
[00:14:33 CEST] <jamrial> a sample collection per release branch is surely a good idea. files currently can be added but not removed because old versions will still need them to run fate
[01:30:00 CEST] <cone-166> ffmpeg 03Timothy Gu 07master:5faca08cafc1: texi2pod: Handle @verbatim
[01:30:01 CEST] <cone-166> ffmpeg 03Timothy Gu 07master:3d6069d01c8b: Use @verbatim instead of @example for ASCII arts
[02:02:43 CEST] <cone-166> ffmpeg 03James Almer 07master:410c93cfd5ab: doc: add missing x86 cpuflags to fftools documentation
[02:02:44 CEST] <cone-166> ffmpeg 03James Almer 07master:666ec9bd0972: doc: add missing arm cpuflags to fftools documentation
[02:02:45 CEST] <cone-166> ffmpeg 03James Almer 07master:9fc45681e0c4: doc: add aarch64 cpuflags to fftools documentation
[02:27:02 CEST] <cone-166> ffmpeg 03Martin Storsjö 07master:4f373a5111f9: vfwcap: Unbreak building after c201069fa
[02:27:03 CEST] <cone-166> ffmpeg 03Michael Niedermayer 07master:d4a6c9404601: Merge commit '4f373a5111f900af54301907132942f95276285c'
[02:44:28 CEST] <cone-166> ffmpeg 03Andrey Utkin 07master:7f64a7503b19: rtpenc_jpeg: handle case of picture dimensions not dividing by 8
[03:01:22 CEST] <Timothy_Gu> ls
[03:01:26 CEST] <Timothy_Gu> oops
[04:13:26 CEST] <Timothy_Gu> OK I think i set up a haiku vm correctly. let's see how it rols.
[05:41:09 CEST] <jamrial> Timothy_Gu: that's a weird error your latest edit generated in the wiki
[06:15:14 CEST] <Timothy_Gu> jamrial: I was trying to use syntax highlighting provided by trac&
[06:15:30 CEST] <Timothy_Gu> jamrial: it works for some languages like C but not shell
[06:15:38 CEST] <jamrial> just pointed it out in case you missed it
[06:16:55 CEST] <Timothy_Gu> also for some reason I need to explicitly define HAVE_6REGS to 0 on Haiku&
[06:18:06 CEST] <jamrial> do both ebx_available and ebp_available configure checks succeed?
[06:18:23 CEST] <Timothy_Gu> jamrial: no, ebx didn't but ebp did
[06:18:35 CEST] <Timothy_Gu> and gcc is complaining about impossible constraints
[06:19:51 CEST] <jamrial> as long as one of those succeeds HAVE_6REGS is set to true
[06:20:17 CEST] <Timothy_Gu> jamrial: yes but compilation fails even though ebp is clearly available
[06:20:23 CEST] <jamrial> are you using the same compiler as michaelni?
[06:20:42 CEST] <jamrial> could be a gcc bug
[06:21:08 CEST] <Timothy_Gu> michaelni's haiku box died a long time ago
[06:21:19 CEST] <Timothy_Gu> and no i don't think so
[06:21:35 CEST] <Timothy_Gu> (i thin his was using 4.4 or something while im using 4.8)
[06:21:51 CEST] <Timothy_Gu> i'll check
[06:21:54 CEST] <jamrial> ah, then you can open a ticket in gcc's bugzilla
[06:22:08 CEST] <jamrial> you may be lucky and it will get fixed before they close the 4.8 branch :p
[06:22:39 CEST] <jamrial> which they will do after 4.8.5 is released, i guess
[06:22:41 CEST] <Timothy_Gu> jamrial: they are unlikely to fix anything related to haiku :d
[06:23:13 CEST] <jamrial> well, assuming there is a haiku maintainer, he's unlikely to have many bug reports to deal with :p
[06:24:01 CEST] <Timothy_Gu> actually quite the opposite :p
[06:24:23 CEST] <Timothy_Gu> anyway, micahel's box was using 4.3.3, and it's on x86-64
[06:24:30 CEST] <Timothy_Gu> while mine is 4.8.* on x86
[06:25:22 CEST] <Timothy_Gu> 4.8.4 (2014_12_21)
[06:33:10 CEST] <Timothy_Gu> "PIC register clobbered by '%ebx'"
[06:38:27 CEST] <Timothy_Gu> jamrial: seems like Haiku builds EVERYTHING with -fPIC, which gives FFmpeg a performance hit so big they had to explicitly disable it in their build: https://github.com/mirror/haikuports/blob/master/media-video/ffmpeg/ffmpeg-2.3.recipe#L137
[06:39:04 CEST] <Timothy_Gu> or rather they don't build with -fPIC but rather hardcode it in their GCC build&
[06:57:02 CEST] <Timothy_Gu> jamrial: seems to be this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602 it was filed 4 years ago and was fixed about 6 months ago
[06:58:32 CEST] <jamrial> doesn't look like it was backported
[06:59:31 CEST] <Timothy_Gu> no it wasn't
[07:00:53 CEST] <Timothy_Gu> even on my ubuntu machine it's broken
[07:01:09 CEST] <Timothy_Gu> now the question is why configure didn't catch that
[07:06:15 CEST] <Timothy_Gu> wait, the issue is about ebx
[07:06:24 CEST] <Timothy_Gu> ugh time to get some sleep
[13:59:30 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07master:e0d8ff5ef105: avformat/nsvdec: Use av_malloc_array()
[13:59:30 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07master:e33355213daf: avformat/wtvenc: Use av_realloc_array()
[13:59:30 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07master:d6bcdf0dcdd7: avformat/xwma: Use av_malloc_array()
[14:52:27 CEST] <BBB> so, theres this interesting discussion in libav-devel where they want to change some unsigned int to uint32_t
[14:52:33 CEST] <BBB> can we please not ever merge that sort of stuff?
[14:53:13 CEST] <kierank> why do they want to do that
[14:53:28 CEST] <BBB> I cant possibly imagine any situation where its warranted
[14:53:36 CEST] <BBB> but its diego and a new contributor
[14:53:37 CEST] <BBB> so...
[14:54:26 CEST] <kierank> ah
[14:55:15 CEST] <j-b> Unfortunately, sometimes this makes sense
[14:56:44 CEST] <Compn> BBB : bring it up on ffmpeg-devel
[14:56:50 CEST] <Compn> otherwise will be forgotten on irc
[14:57:06 CEST] <Compn> quote or reply from libav-devel thread too for maximum effect
[14:57:23 CEST] <Compn> or at least ping michaelni so he sees this request here :P
[14:58:30 CEST] <j-b> technically, unsigned int could be only 0-65535 range
[14:58:46 CEST] <j-b> while uint32_t is guaranteed to be at least 32bits
[14:59:10 CEST] <michaelni> posix gurantees (unsigned) int to be 32bit at least
[14:59:15 CEST] <BBB> posix means 32bit
[14:59:17 CEST] <BBB> right
[14:59:23 CEST] <BBB> so, no, unsigned int is >= 32 bit
[14:59:37 CEST] <kierank> http://comments.gmane.org/gmane.comp.gdb.patches/106689
[14:59:40 CEST] <BBB> but adjusts to nativity of the system running on, i.e. its not guaranteed to be 32bit on systems where 64bits ay be more performant
[14:59:40 CEST] <kierank> can we do this please too
[14:59:57 CEST] <BBB> so unsigned int for non-array types where the specific scope/size makes no difference, is better
[15:06:49 CEST] <Compn> kierank : apply the patch to gdb or introduce av_16bit_something ? 
[15:12:42 CEST] <wm4> kierank: also, POSIX requires chars to be 8 bits
[15:15:15 CEST] <kierank> "This explains how unsigned arithmetic wraparound works, not what happens
[15:15:16 CEST] <kierank> when you assign negative values to unsigned variables."
[15:15:16 CEST] <kierank> lol'd
[15:15:39 CEST] <kierank> oh well bbq time
[15:20:51 CEST] <wm4> haha nicolas gets repeatedly accused of trolling
[15:20:56 CEST] Action: wm4 gets popcorn
[16:21:33 CEST] <lglinskih> hi! what does the `align` parameter of av_frame_get_buffer do?
[16:22:34 CEST] <lglinskih> the doc says "buffer size alignment". What is the alignment of a size?
[16:25:47 CEST] <wm4> lglinskih: it's the byte alignment of the data
[16:26:19 CEST] <wm4> lglinskih: so for video, it means the pointers to each 1st pixel of a line is aligned to this value
[16:26:29 CEST] <wm4> if you don't know what it means, just set it to 32
[16:31:01 CEST] <lglinskih> wm4: that's what I did=)
[17:59:50 CEST] <cone-750> ffmpeg 03Michael Kostylev 07master:7a9b764c0737: libdc1394: Unbreak build after c201069fa
[17:59:51 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07master:6530e2ff0cd0: Merge commit '7a9b764c0737f42cf2458c3c5378b0df216e14a2'
[18:12:43 CEST] <cone-750> ffmpeg 03James Almer 07master:bbdb50d7a8a9: libx265: print supported presets and tunes on error
[18:12:44 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07master:816bbc1cf532: Merge commit 'bbdb50d7a8a91f38188fd15080d7f45f1540b3ac'
[19:22:37 CEST] <kierank> OK now Nicholas wants an http server
[19:26:28 CEST] <Daemon404> kierank, it as his gsoc ide.a
[19:26:32 CEST] <Daemon404> was*
[19:30:24 CEST] <wm4> what's the http server for?
[19:31:14 CEST] <j-b> ponr
[19:35:40 CEST] <Compn> mongoose project is a simple http server that offers whatevers in the active dir , http://code.google.com/p/mongoose/
[19:35:44 CEST] <Compn> got a libmongoose too :P
[19:37:19 CEST] <wm4> there are probably hundreds of http servers
[19:47:47 CEST] <kierank> wm4:  nih
[20:08:28 CEST] <rcombs> this whole Perseus thing would be very interesting if there was any evidence it actually exists
[20:13:09 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07master:f944aeb07aff: avformat/rtpproto: Move dscp into context & AVOptions
[22:12:31 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:f597b9f04e69: avutil/pca: Check for av_malloc* failures
[22:12:32 CEST] <cone-750> ffmpeg 03Rainer Hochecker 07release/2.6:7689fe5cfd28: h264: avoid unnecessary calls to get_format
[22:12:33 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:fa538f1a8c33: Revert "avcodec/exr: fix memset first arg in reverse_lut()"
[22:12:34 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:f1b4a71ddfcd: avcodec/h264: Fail for invalid mixed IDR / non IDR frames in slice threading mode
[22:12:35 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:9ee7fcdcd087: avcodec/h264_refs: Do not set reference to things which dont exist
[22:12:36 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:9bff35abde67: ffmpeg: Fix extradata allocation
[22:12:37 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:ac07ab7db78d: avformat/utils: avoid discarded streams in av_find_default_stream_index()
[22:12:38 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:d3f96c1e3cc2: avcodec/h264: Fix race between slices where one overwrites data from the next
[22:12:39 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:3550d239a6cb: avcodec/h264: finish previous slices before switching to single thread mode
[22:12:40 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:7d5908d5c834: avcodec/h264_slice: Dont reset mb_aff_frame per slice
[22:12:41 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:8be177e048ce: avcodec/h264: reset the counts in the correct context
[22:12:42 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:bcc4c360aadf: avcodec/aacdec: Fix storing state before PCE decode
[22:12:43 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:e6d9094fd3c6: avcodec/h264: Be more tolerant to changing pps id between slices
[22:12:44 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:b4bfbbfb95ac: avcodec/h264_ps: Move truncation check from VUI to SPS
[22:12:45 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:05b448082ae0: avcodec/h264: Do not fail with randomly truncated VUIs
[22:37:09 CEST] <cone-750> ffmpeg 03Michael Niedermayer 07release/2.6:369f46aae3f2: Update for 2.6.2
[23:12:40 CEST] <cone-750> ffmpeg 03Stephan Holljes 07master:b51027fd18f6: libavformat/http.c: Make http-listen work as an input stream.
[23:56:35 CEST] <jamrial> michaelni: are documentation commits ok to backport?
[23:56:44 CEST] <michaelni> sure
[00:00:00 CEST] --- Sun Apr 12 2015