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

[burek]

[00:22] <llogan> michaelni: i'll do the OPW twitter today.
[00:23] <michaelni> thx
[00:42] <Timothy_Gu> michaelni: I agree with ubitux. However I'd like to highlight some key fixes in the release in Changelog maybe.
[00:43] <michaelni> Timothy_Gu, ok, can you post a patch ?
[00:44] <Timothy_Gu> maybe, I can't promise anything though. I'm moving this week to ~20 km away, so I'm pretty busy.
[00:44] <cone-729> ffmpeg.git 03Nicolas Martyanoff 07master:53f10e03687c: avformat/hlsenc: Add some comments to make the code easier to read
[00:44] <cone-729> ffmpeg.git 03Nicolas Martyanoff 07master:706fcffce138: avformat/hlsenc: rename some identifers to make the code easier to read
[00:44] <cone-729> ffmpeg.git 03Nicolas Martyanoff 07master:467e9d618685: avformat/hlsenc: add some empty lines to make the code easier to read
[00:47] <michaelni> Timothy_Gu, understood, but i need to know if i should wait with the release or not
[00:47] <michaelni> or maybe someone else volunteers to highlight these key fixes
[00:47] <michaelni> ?
[01:01] <jamrial> no reason to postpone a point release just to add a couple lines in changelog
[01:03] <jamrial> speaking of which, was 2.3 affected by the problem c0a586d9 fixed?
[01:07] <michaelni> avpriv_dsputil_init() is still in 2.3 but i definitly intend to backport ubituxs dsp-pixel-block-util-toolbox-thingy to it once its done
[01:13] <kierank> https://www.mir-swamp.org/#
[02:01] <Timothy_Gu> what is the difference between av_mallocz_array and av_calloc completely the same?
[02:02] <Timothy_Gu> *are they completely the same?
[02:02] <Timothy_Gu> from the code they are the same, besides the fact that av_calloc is not inlined
[02:02] <wm4> looks like it
[02:03] <wm4> mysterious
[02:03] <wm4> btw. av_mallocz_array looks dangerous, because it implies it's for arrays
[02:03] <wm4> and you often use realloc on arrays
[02:03] <wm4> but I think calling av_realloc on a av_malloc'ed ptr is not ok
[02:03] <wm4> for strange reasons
[02:04] <Timothy_Gu>  In this aspect av_mallocz(x) = av_calloc(1, x)
[02:04] <wm4> yeah, av_realloc doxygen says so
[02:04] <wm4> yes
[02:04] <wm4> also it's sad that these functions don't use calloc (which zeros automatically, and may do so much more efficiently than malloc+memset)
[02:05] <Timothy_Gu> michaelni?
[02:06] <wm4> maybe one was added by ffmpeg, and later libav added another one
[02:06] <michaelni> Timothy_Gu, yes?
[02:07] <Timothy_Gu> what do you think about all the av_calloc mess?
[02:08] <michaelni> mess ?
[02:08] <Timothy_Gu> see what I discussed with wm4
[02:09] <michaelni> the inline causes some object code expansion probably on calls
[02:10] <michaelni> calloc() use is tricky we need alignment
[02:10] <michaelni> and it would need extra code for the memalign hack case when thats enabled
[02:10] <Timothy_Gu> can't we just use av_malloc() code and then s/malloc/calloc/?
[02:11] <kierank> no
[02:11] <kierank> because calloc is not guarnateed aligned
[02:11] <michaelni> av_malloc uses memalign or _aligned_malloc() or posix_memalign or malloc + memalign hack
[02:12] <Timothy_Gu> and there's no _aligned_calloc?
[02:16] <wm4> one could just use calloc and align the result with the generic alignment hack
[02:17] <wm4> but maybe calloc wouldn't have much of an advantage anyway in this project
[02:17] <wm4> but Timothy_Gu has a valid point about all the redundant functions
[02:17] <michaelni> the alignment hack reduces what memory debuggers can detect so its better to avoid using it
[02:18] <wm4> I guess that's true
[02:27] <michaelni> is anyone going to highlight changelog entries for 2.3.1 ? or could give me a quick list of what i should do ?
[02:27] <michaelni> if not ill probably release in 1-2h without it
[02:27] <michaelni> or tomorrow if the time slips too much from other work
[02:28] <michaelni> Timothy_Gu, ?
[02:49] <michaelni> kierank, about mir-swamp.org, interresting, but its web interface is slow as hell, have u used it ? is it worth fighting through the web interface?
[02:52] <michaelni> also its web interface produces errors on every second page
[03:00] <Timothy_Gu> michaelni: * dv fallback * g2meet size change * AVDCT
[03:01] <michaelni> Timothy_Gu, will add them to the changelog, thanks
[03:02] <cone-729> ffmpeg.git 03Gerion Entrup 07master:dc315cdb4ecf: doc: add very basic libcdio documentation
[03:06] <Timothy_Gu_> michaelni: can you backport dc315cdb4ecf too?
[03:08] <michaelni> sure, locally done
[03:14] <j-b> libcdio?
[03:14] <j-b> but why?
[03:17] <wm4> so you can rip CDs with ffmpeg
[03:18] <wm4> and convert them to low bitrate mp3s
[03:18] <cone-729> ffmpeg.git 03Gerion Entrup 07release/2.3:1f58590e1e17: doc: add very basic libcdio documentation
[03:18] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:7c2d152f562a: Changelog: highlighting for 2.3.1
[03:21] <Timothy_Gu_> j-b: just so you know, libcdio has been in FFmpeg since 2011. We are just adding docs for it.
[03:34] <j-b> more shitty libraries!
[03:39] <cone-729> ffmpeg.git 03Gerion Entrup 07fatal: ambiguous argument 'refs/tags/n2.3.1': unknown revision or path not in the working tree.
[03:39] <cone-729> Use '--' to separate paths from revisions
[03:39] <cone-729> refs/tags/n2.3.1:HEAD: doc: add very basic libcdio documentation
[03:49] <Rin_Tohsaka> I'd just like to make a follow-up comment in response to something jamrial said almost a month ago
[03:50] <Rin_Tohsaka> the x64 and ssse3 optimizations in ffvp9 are flat-out necessary for 1280x720p 30fps decoding of VP9 video on a 1.6GHz AMD E-350 (bobcat core)
[03:51] <Rin_Tohsaka> MPC-HC 32bit sees 100% CPU utilization and has frame-drops while MPC-HC 64bit peaks out around 75% CPU utilization and plays back the video smoothly
[03:51] <jamrial> what was my comment again?
[03:52] <Rin_Tohsaka> http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2014-July/002201.html
[03:52] <Rin_Tohsaka> [00:08] <jamrial> but afaik it has 64bits execution units, which is awfully slow for sse
[03:52] <Rin_Tohsaka> which was in response to
[03:53] <wm4> so the problem is that vp9 has missing 32 bit asm opts or what?
[03:53] <jamrial> yes. that doesn't mean ssse3 optimizations are not going to be faster than c
[03:53] <Rin_Tohsaka> no problem wm4, just saying that the optimizations still help considerably
[03:55] <wm4> jamrial: hm still a somewhat interesting result isn't it
[03:55] <Rin_Tohsaka> consider that my SSSE3-less Brisbane was running the same ~75% CPU utilization but at 2.5GHz
[03:56] <Rin_Tohsaka> and in most other things I've found bobcat to be about 75% slower per clock than K8
[03:56] <Rin_Tohsaka> ....
[03:56] <Rin_Tohsaka> err, have 75% the performance per clock
[03:58] <Rin_Tohsaka> ok, that is all
[13:04] <cone-675> ffmpeg.git 03Michael Niedermayer 07master:37ec7d291eac: avcodec/mpeg4video_parser: Check for extradata parsing failure
[13:04] <cone-675> ffmpeg.git 03Michael Niedermayer 07master:72555f4a3827: avcodec/pthread_slice: Check for malloc failure
[14:18] <cone-675> ffmpeg.git 03Michael Niedermayer 07master:ceff29b9ad61: avcodec/resample: check for malloc failure
[14:18] <cone-675> ffmpeg.git 03Michael Niedermayer 07master:dd200c56c07b: avcodec/dvdsubdec: free subtitle rectangles if nothing is output
[14:22] <ubitux> michaelni: what's CSA?
[14:22] <ubitux> (who?)
[14:22] <michaelni> clang static analyzer
[14:22] <ubitux> ok
[14:32] <plepere> hi
[14:33] <plepere> quick question : using 3 operand psubw is OK in SSE ?
[14:35] <ubitux> if it's not ok x264 will translate to 2 op afaict
[14:35] <ubitux> s/ct/k/
[14:37] <plepere> ok
[14:38] <plepere> because I'm fixing my transform_add patch
[14:39] <plepere> thanks
[16:49] <cone-766> ffmpeg.git 03Benoit Fouet 07master:bf428bb3145c: h264_mp4toannexb_bsf: account for consecutive IDR pictures.
[16:49] <cone-766> ffmpeg.git 03Michael Niedermayer 07master:0782fb6bcb32: libavcodec/h264_parser: Increase parse_history, fix huge resolutions
[17:00] <kierank> Program received signal SIGSEGV, Segmentation fault.
[17:00] <kierank> [Switching to Thread 0x7fffa29c3700 (LWP 2061)]
[17:00] <kierank> 0x00007ffff6ac590a in avpriv_emms_yasm () from /usr/local/lib/libavutil.so.52
[17:00] <kierank> (gdb) bt
[17:00] <kierank> #0  0x00007ffff6ac590a in avpriv_emms_yasm ()
[17:00] <kierank>    from /usr/local/lib/libavutil.so.52
[17:00] <kierank> how can one crash in emms?
[17:02] <nevcairiel> no mmx support?
[17:02] <nevcairiel> :D
[17:03] <nevcairiel> although that would end up being sigill
[17:05] <ubitux> stack smashing exploding elsewhere?
[17:05] <kierank> it's in the opus decoder
[17:05] <ubitux> can we reproduce?
[17:07] <kierank> dunno
[17:27] <kierank> I can't get libavcodec.so to emit debug symbols
[17:34] <kierank> oh unless the stack is smashed
[17:36] <kierank> ==10940==
[17:36] <kierank> ==10940== Process terminating with default action of signal 11 (SIGSEGV)
[17:36] <kierank> ==10940==  General Protection Fault
[18:37] <Daemon404> kierank, this only happens with asm enabled?
[18:44] <kierank> dunno checking now
[18:45] Action: Daemon404 wonders if it oculd be swr
[18:47] <kierank> yep goes away without asm
[18:58] <kierank> oh well time to use opus with avresample
[19:05] <cone-766> ffmpeg.git 03Anshul Maheswhwari 07master:fcb11ec291e9: v4l2enc: adding AVClass
[19:15] <kierank> is there a HAVE_SWRESAMPLE #define ?
[19:16] <jamrial> CONFIG_SWRESAMPLE
[19:17] <nevcairiel> Does the decoder work with both now? I'm still using libopus because I use avresample
[19:17] <kierank> i keep getting crashes I suspect to be swresample so I'm going to move and see if they go away
[19:17] <kierank> though actually I was going to move anyway
[19:17] <jamrial> no, opus is hardcoded to work with swresample
[19:18] <jamrial> in libav it's hardcoded to avresample
[19:18] <nevcairiel> Wonder how hard it would be to make it work with both
[19:18] <jamrial> it's easy to make it use both, but it needs a maintainer to make sure it doesn't break
[19:19] <nevcairiel> Or my own fork just gets a patch to make it use only avresample at some point
[19:19] <jamrial> both as in one or the other, depending on config
[19:19] <Compn> >in b4 'lets just copy *resample into opus'
[19:19] <nevcairiel> For now libopus works
[19:20] <kierank> jamrial: I am going to try and do that now
[19:20] <jamrial> swr is better for opus than lavr. resampling is much faster in the former
[19:20] <nevcairiel> I would prefer it didn't rely on either tbh. I have another project that doesn't have either lib yet, and just adding it for opus seems overkill
[19:20] <kierank> jamrial: apart from the suspected crashes yes
[19:21] <jamrial> what was the crash?
[19:21] <jamrial> i wasn't here when you mentioned it
[19:21] <ubitux> kierank: did you play with the -cpuflags?
[19:21] <nevcairiel> Looked like smashed stack
[19:21] <kierank> ubitux: yes goes away with --disable-asm
[19:21] <kierank> I'm using the api
[19:21] <nevcairiel> All kinds of weird stuff
[19:21] <ubitux> you can force the cpu flags at runtime
[19:22] <ubitux> and set them to "none" or something more specific
[19:26] <ubitux> kierank: valgrind doesn't give more insight?
[19:26] <kierank> nope
[19:27] <kierank> also the opus in ts patch works in libav but not ffmpeg
[19:27] <kierank> so i can't be dealing with that crap
[19:27] <kierank> there is some magic guessing that picks mp3
[19:33] <michaelni> kierank, how can the issue be reproduced ?
[19:33] <kierank> don't know
[19:33] <kierank> that's the problem
[19:44] <michaelni> kierank, how can i reproduce the opus in ts issue then ?
[19:58] <Daemon404> [18:20] <@jamrial> swr is better for opus than lavr. resampling is much faster in the former <-- for all those people with avx who are bottlenecked on audio decoding
[19:58] <Daemon404> right?
[20:11] <cone-766> ffmpeg.git 03Reimar Döffinger 07master:f0de01856fde: dict.c: minor simplification.
[20:13] <kierank> seems to work with ffmpeg cli
[20:14] <kierank> so as an api issues it's almost impossible to reproduce
[20:15] <michaelni> kierank, can you share the sample & command line (even if you cant reproduce it, might be worth a try maybe it reproduces on my box)
[20:15] <kierank> can't share sample
[20:15] <kierank> will have to make one somehow
[20:15] <michaelni> :(
[20:16] <michaelni> The modern world of NDAs, how i hate it ...
[20:16] <Daemon404> an opus sample under nda?
[20:16] <Daemon404> thats a new one.
[20:17] <kierank> it's not an nda
[20:17] <kierank> it's a recording from a live channel
[20:17] <Daemon404> fair use.
[20:17] <kierank> i'm not concerned about copyright
[20:18] <Daemon404> then im not sure what
[20:18] <kierank> it's a feed for internal use only
[20:18] <Daemon404> certainly not a "recording from a live channel" then
[20:18] <kierank> it is the same feed as a live channel
[20:19] <kierank> literally a duplicated feed to that from the dth encoder
[20:19] <Daemon404> if the bits are the same then why differentiate
[20:42] <cone-766> ffmpeg.git 03Michael Niedermayer 07master:1af563b5dfea: avcodec/ratecontrol: remove unneeded statement
[20:42] <cone-766> ffmpeg.git 03Michael Niedermayer 07master:590c2996ee11: avcodec/flac_parser: remove duplicate assignent
[20:42] <cone-766> ffmpeg.git 03Michael Niedermayer 07master:5bedbc3da281: avcodec/diracdec: remove unneeded assignment
[21:19] <llogan> what's the significance of 2.3.1? it was released 15 days after 2.3. (I didn't follow or understand the AVDCT stuff)
[21:21] <cone-766> ffmpeg.git 03Michael Niedermayer 07master:a75a60f68610: avutil/pixdesc: remove unneeded assignment
[21:21] <cone-766> ffmpeg.git 03Michael Niedermayer 07master:fc19edd8f500: avfilter/trim: remove duplicate assignment
[21:21] <cone-766> ffmpeg.git 03Michael Niedermayer 07master:39133efc1b99: avdevice/oss_audio: Check SNDCTL_DSP_GETFMTS failure, print a warning but continue
[21:22] <michaelni> llogan, i generally try to make a point release 1-2 weeks after the first .0 release
[21:23] <llogan> oh, i should have realized that by now.
[21:23] <michaelni> i dont think 2.3.1 was truly significant 
[21:52] <ubitux> BBB: https://github.com/ubitux/FFmpeg/compare/avpixelutils here is a prototype
[21:52] <ubitux> so it exposes an api for pixel utils, which is enabled by default but can be disabled at configure
[21:53] <ubitux> (maybe that could be disabled and automatically be picked with some select/deps configure magic though, but we might want to expose that api anyway)
[21:53] <ubitux> i'll add diff_pixels and some x86 and will submit a proper patch, but anyway, it is disablable
[21:55] <ubitux> Timothy_Gu: ah! i told you your yellow was killing kittens, just use the orange...
[22:21] <Daemon404> wtf.... bintuils wont vompiler with gcc 4.9.1??
[22:21] <Daemon404> nevcairiel, did you hit this?
[22:21] <Daemon404> compile*
[22:24] <nevcairiel> Yes
[22:24] <JEEB> lolwut
[22:24] <nevcairiel> One new warning and they use error on warnings
[22:24] <JEEB> lol
[22:24] <Daemon404> fucking -Werror
[22:24] <Daemon404> die in a fire
[22:25] <Daemon404> i love how it also caused regressions in binutils tests
[22:25] <Daemon404> do the gnu toolchain people even talk to eachother
[22:26] <nevcairiel> I used a 4.8.3 cross compiler in the end to build the 4.9.1 target
[22:26] <Daemon404> im just backporting the fix from their git rep
[22:27] <nevcairiel> The issue is fixed since way earlier, they just don't release very often. :p
[22:27] <Daemon404> yes
[22:27] <Daemon404> i used to have to use binutils cvs for ages
[22:28] <nevcairiel> I would have to mangle my scripts to allow custom patches, but oh well. My way worked out in the end
[22:28] <nevcairiel> The version of the cross compiler used isn't all that important
[22:28] <Daemon404> its a pain in the butt though
[22:29] <Daemon404> also doing patch review on bugzilla is insane.
[22:29] <nevcairiel> bugzilla is insane
[22:32] <Compn> Daemon404 : can you imagine maintaining gcc ?
[22:33] <Compn> or any compiler
[22:33] <Daemon404> binutils is not a compiler
[22:33] <Compn> :P
[22:33] <Daemon404> but i would assume "make sure the compiler and build the linker and assembler" is kind of obvious
[22:33] <Daemon404> can*
[22:58] <jamrial> that's the kind of bug that should force them to get a point release out of the door asap
[22:58] <Daemon404> dude
[22:58] <Daemon404> gcc 4.9.x fuck up the linux kernel
[22:59] <Daemon404> and they still wont
[22:59] <Daemon404> because theyre ON A SCHEDULE
[22:59] <Daemon404> cant break the release schedule! ever!
[23:07] <jamrial> maybe they don't care because no distro is going to use gcc 4.9.x anyway until 4.10.x is out or something...
[23:08] <Daemon404> i dont know
[23:08] <Daemon404> it's also true gnu doesnt get any new blood at all, more or less
[23:08] <Daemon404> so theyll keep using methods and tech from 1995 forever
[23:08] <wm4> Daemon404: the author of musl now says that he thinks drepper actively sabotaged glibc for job security
[23:09] <wm4> <dalias> the more i watch the glibc folks clean up from the mess drepper left them...
[23:09] <ubitux> well drepper is working for goldman sachs
[23:09] <wm4>  <dalias> ...the more i'm convinced that he actively sabotaged glibc as job security
[23:10] <wm4> <dalias> there are things that make no sense at all, like per-arch asm for all of the pthread synchronization functions, which have no need for asm micro-optimization and have complex logic
[23:10] <wm4> ubitux: well, now
[23:10] <wm4> after he left gnu
[23:10] <wm4> anyway, so there are some surprising reasons why GNU software is shit
[23:10] <ubitux> well, it's probably the worst assholish company possible, so it reflects a bit the state of mind of the guy
[23:11] <ubitux> "company"
[23:11] <wm4> :)
[23:12] <Daemon404> wm4, well that is standard gnu code
[23:32] <cone-766> ffmpeg.git 03James Almer 07master:62baf5b8530d: x86/hevc_deblock: use existing x86util transpose macro in chroma_{10, 12}
[00:00] --- Fri Aug  1 2014