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

[burek]

[00:03] <cone-472> ffmpeg 03James Almer 07master:5c8f74708504: x86/hevc_sao: use unaligned movs for sao_{band,filter} with width 8
[01:15] <cone-472> ffmpeg 03Michael Niedermayer 07master:85108195c561: avutil/common: minor simplification in av_clip_intp2_c()
[02:12] <rcombs> and it keeps going!
[03:34] <cone-472> ffmpeg 03Michael Niedermayer 07master:047fd986bf36: avfilter/vf_drawbox: Fix handling of max values
[04:27] <jamrial> why do we have a different value for AV_CPU_FLAG_CMOV compared to libav? isn't this breaking things?
[04:28] <jamrial> there's even commented out deprecation code for our current value, that was supposed to be replaced with the one from libav
[04:29] <cone-472> ffmpeg 03Michael Niedermayer 07master:fd8c3277c494: ffprobe: Change string_validation to int, its accessed via AVOption as int
[04:29] <cone-472> ffmpeg 03Michael Niedermayer 07master:cf729b248973: avcodec/libfdk-aacdec: Change conceal_method to int, its accessed via AVOption as int
[04:29] <cone-472> ffmpeg 03Michael Niedermayer 07master:7ff296be9f41: avfilter/avf_showspectrum: Change enums to int, which are accessed via AVOption as int
[04:29] <cone-472> ffmpeg 03Michael Niedermayer 07master:27a5d09c6adc: avfilter/avf_avectorscope: Change enums to int, which are accessed via AVOption as int
[04:29] <cone-472> ffmpeg 03Michael Niedermayer 07master:d545668e256e: avfilter/af_volume: Change enums to int, which are accessed via AVOption as int
[04:29] <cone-472> ffmpeg 03Michael Niedermayer 07master:e8c1eb09c7fc: avfilter/af_biquads: Change width_type to int as its accessed as int via AVOptions
[04:29] <cone-472> ffmpeg 03Michael Niedermayer 07master:34b13dbadff9: avfilter/af_aphaser: Change type to int as its accessed as int via AVOptions
[09:55] <fffan> does avformat_open_input thread-safe for rtmp url?
[09:56] <fffan> cause when I open two rtmp url simultaneous in two thread, the heap is broken.
[10:24] <fffan> @j-b
[10:28] <rmklp> is there any place where I can find docs on how to update fate hashes/crcs after a code change? Theres nothing at https://ffmpeg.org/fate.html or https://ffmpeg.org/developer.html
[10:28] <nevcairiel> ffmpegs native rtmp support should hopefully be thread-safe ... for librtmp, all bets are off
[11:57] <cone-561> ffmpeg 03Michael Niedermayer 07master:f27d5bd3d2c6: tests/fate: Add S302M test
[12:09] <cone-561> ffmpeg 03Gilles Chanteperdrix 07master:ebf1f512e991: avformat/rtpdec_mpa_robust: fix commit 96084251e57d1738fde02a2b0d37ca609d9efd71
[12:09] <cone-561> ffmpeg 03Gilles Chanteperdrix 07master:bfdd15c4e8b2: MAINTAINERS: add myself as rtpdec_mpa_robust maintainer
[13:29] <Daemon404> i spot ubitux on the front page of /r/prpgramming
[13:29] <Daemon404> programming even
[13:34] <thardin> which post?
[13:38] <kurosu_> those "erosion, dilation, median, deflate & inflate" filters remind me of avisynth's masktools, which use more templated code, as well as useful options (to work on specific planes, sometimes start/end positions etc)
[13:43] <Daemon404> thardin, hqx one
[13:49] <thardin> ah
[13:49] <thardin> taking a look, I'm going to guess a LUT was used tho
[13:54] <thardin> clever deduplication even. neat
[13:54] <cone-561> ffmpeg 03Claudio Freire 07master:84f4be424d52: avcodec/aacpsy: Fix AAC Psy PE reduction calculation when multiple iterations are required
[13:55] <thardin> "I had a short stab at implementing HQX in GLSL some while ago, but swiftly dropped the idea like a rod of enriched uranium upon seeing the reference."  :D
[14:04] <compn> interesting another static code analyizer
[14:04] <compn> http://www.viva64.com/en/examples/V557/
[14:04] <compn> you guys saw this yet? they tested ffmpeg too ;)
[14:04] <compn> http://www.viva64.com/en/examples/
[14:05] <nevcairiel> static analyzers aren't that super useful imho
[14:05] <compn> coverity has found a few bugs 
[14:06] <compn> so they arent worthless either
[14:08] <compn> and a lot of false positives 
[14:12] <compn> We have deliberately refused to implement an option to view all the bugs found in a particular project: this might lead to an incorrect impression regarding the number of errors in the project and the analyzer's capabilities. 
[14:12] <compn> derp
[14:19] <ubitux> Daemon404: yeah, that's because i was about 18 hours on the front page of HN for the templating article
[14:19] <ubitux> and someone crawled my blog and reposted the hqx one on reddit
[14:20] <compn> i like your blog ubitux , nice pictures and explanations. 
[14:20] <compn> even though i am not a programmer.
[14:20] <ubitux> next one will be more interesting
[14:20] <ubitux> i'll try to make it for the end of the week
[14:22] <Daemon404> ubitux, o
[14:56] <cone-561> ffmpeg 03Clément BSsch 07master:9b1755bce7fd: configure/help: consistently use "autodetect"
[14:57] <ubitux> can i disable libxcb?
[14:57] <ubitux> (autodetect)
[16:28] <j-b> Anyone knows why do we require mips32r2 ?
[16:37] <cone-561> ffmpeg 03Michael Niedermayer 07master:7c9e7bd4257a: avcodec/pngenc: replace round by lrint()
[17:00] <cone-561> ffmpeg 03Andreas Cadhalpun 07master:08728f400b83: avformat/rm: limit packet size
[17:10] <ubitux> apparently 6ecc3fd61225c79116de64167e3bf47736f0e779 is causing a regression
[17:12] <ubitux> which sounds weird since apparently it's affecting arm
[17:12] <ubitux> well, someone will probably come.
[17:17] <Atrus_> hi all; 
[17:18] <Atrus_> I was testing hevc decoding on arm-v7a 
[17:18] <Atrus_> it is segfaulting in copy_CTB in hevc_filter.c
[17:19] <Atrus_> if I revert hevc/sao: use aligned copies 6a6aeb538b4bb it works back
[17:19] <ubitux> kurosu_: ^
[18:19] <kurosu_> Atrus_, try http://pastebin.com/kjmAfbL8 ?
[18:20] <kurosu_> knowing where it crashes more precisely (like a line) might be useful too
[18:20] <Atrus_> kurosu_: looking at my log and pastebining it
[18:21] <nevcairiel> evil arm with its evil alignment problems =p
[18:21] <kurosu_> it's a shot in the dark, the address should be at least always be 8-byte-aligned
[18:21] <Atrus_> ok I was wondering if it was supposed to be always aligend
[18:22] <kurosu_> actually no, you're right
[18:22] <kurosu_> copy_CTB(dst - (left_pixels << sh)
[18:22] <kurosu_> so the address may not be aligned at all
[18:23] <kurosu_> that's also the case where an odd number of pixels may be copied
[18:23] <kurosu_> might also fix icc crashes
[18:24] <kurosu_> (though I thought it overoptimized movqs into movdqa)
[18:24] <nevcairiel> i still think its odd that icc uses a 128 bit load for a 64 bit copy
[18:24] <nevcairiel> but i dont know if its save to assume that a 64-bit vlaue is usually 16-byte aligned
[18:25] <nevcairiel> or it figured out what the loop is doing and thought "I'll unroll this a bit and use 128-bit copies"
[18:25] <kurosu_> yes, but if the address isn't aligned... :(
[18:25] <kurosu_> I think jamrial said it optimized the C code actually, iirc
[18:26] <nevcairiel> thats where I don't know which alignment the ABI usually guarantees for 64-bit values
[18:26] <nevcairiel> since thats what the C macro does, cast it to a 64-bit type and use assignment
[18:26] <kurosu_> well movq applies to any alignment, but it seems the arm equivalent doesn't
[18:26] <kurosu_> oh, ok
[18:28] <nevcairiel> thats also where ARM falls over, a 64-bit assignment requires 64-bit alignment
[18:28] <nevcairiel> while the *U macros just copy individual bytes
[18:29] <nevcairiel> its all a lot of black magic if you ask me
[18:29] <nevcairiel> but i guess you need this to make fast decoders
[18:30] <nevcairiel> we had a similar case at $work recently when porting to arm, some over-engineered generic data storage code crashed on arm when casting an arbitrary pointer to double
[18:31] <nevcairiel> i miss good old forgiving x86
[18:31] <nevcairiel> :)
[18:31] <Atrus_> kurosu_: I am reproducing to get a log, then I will test with last change
[18:32] <Atrus_> kurosu_: I am building with android gcc btw & it might behave differently
[18:35] <kurosu_> nevcairiel, people call that ricing, but that's in the end 0.1% sprinkled over the code that add up to 5%
[18:36] <kurosu_> but my fault here, I knew AV_COPY64 add an unaligned version already but neglected that case
[18:36] <kurosu_> *had an unaligned
[18:39] <kurosu_> iirc, x264 started that trend, but at a point where there probably wasn't much anything left to optimize
[18:44] <kurosu_> Atrus_, thanks
[18:45] <Atrus_> kurosu_: I check that everything is ok on my side and I report; thanks to you
[18:45] <kurosu_> please mention in the channel whether it worked: I'll be away in a few minutes and may not be available for further debugging
[18:45] <Atrus_> oki
[18:46] <ubitux> why wasn't this spotted by fate btw?
[18:47] <ubitux> we have many arm instances; is this code covered?
[18:48] <ubitux> it seems covered according to coverage.ffmpeg.org
[18:50] <jamrial> all the arm-v7a slots using android ndk are build only, so maybe that's why
[18:57] <Atrus_> kurosu_: works \o/
[19:02] <compn> j-b : require mips32r2 where? do you mean why 32r2 or is something broken somewhere  in configure ?
[19:03] <compn> michaelni : do you already know about the static code analysis http://www.viva64.com/en/examples/ , or should i post it to -devel or ?
[19:03] <compn> the page says they are in contact with projects... maybe i just havent seen said contact.
[19:11] <compn> oh yes
[19:11] <compn> a year ago hahah
[19:11] <compn> https://trac.ffmpeg.org/ticket/3466
[19:11] <compn> there it is
[19:17] <compn> now searching for other code analysis of ffmpeg...
[19:17] <compn> found this https://continuousassurance.org/about-us/
[19:18] <compn> has anyone used it on ffmpeg ^ ?
[19:18] <nevcairiel> there is dozens of static code analyzers out there, the problem is that most of them spit out so many false positivies that its way too tedious to care
[19:19] <compn> j-b : do you use static code analyzers ? 
[19:19] <compn> nevcairiel : no one said you had to review the false positives :P
[19:19] <compn> some developers like doing these weird useless tasks...
[19:20] <nevcairiel> compn: you only know if its a false positive after reviewing it, duh
[19:20] <nevcairiel> if the tool knew that, it wouldnt tell you :P
[19:20] <compn> i mean
[19:20] <j-b> compn: yes
[19:20] <compn> you dont have to review the output from the code analyzers
[19:20] <compn> j-b : did you ever use that site continuousassurance.org ?
[19:21] <kurosu_> Atrus_, I don't see how it would fail now, but you know where to report now :)
[19:21] <kurosu_> I'll send the corresponding patch to the ml meanwhile
[19:21] <kurosu_> it's strange that it didn't get caught by fate instances on arm
[19:32] <kurosu_> michaelni, fix for crash on ARM and HEVC on ml, in case 2.6 can still get it
[19:38] <cone-561> ffmpeg 03Christophe Gisquet 07master:efd3f407e50e: hevc/sao: use unaligned copy
[19:57] <saste> wtf ffmpeg was accepted into GSOC
[19:57] <saste> that's unexpected
[19:58] <wm4> wat
[19:58] <Daemon404> time to eat my hat...
[19:59] <wm4> yay for more libpostproc improvements
[20:01] <jamrial> whoa
[20:07] <himangi> saste: something I had been waiting for.. :)
[20:08] <kierank> saste: i'm still laughing
[20:09] <kierank> congratulations though
[20:10] <llogan> i'll be damned
[20:11] <cone-561> ffmpeg 03Luca Barbato 07master:dbc1163b203b: prores: Extend the padding check to 16bit
[20:11] <cone-561> ffmpeg 03Michael Niedermayer 07master:ada512f91df6: Merge commit 'dbc1163b203b175d246b7454c32ac176f84006d1'
[20:11] <llogan> saste: if you give me words, i can tweet something
[20:12] <saste> llogan, fine with me, but I'm not that important (indeed I did almost nothing for this gsoc application)
[20:13] <llogan> i did even less
[20:13] <llogan> maybe we were the problem
[20:13] <saste> llogan, yep that's likely :-)
[20:13] <jamrial> someone should poke the guy doing the work in the epic aac trac ticket to apply
[20:13] <saste> now I have to go, bye
[20:13] <llogan> see you saste
[20:14] <michaelni> llogan, feel free to pick the tweet wording as you see fit
[20:15] <llogan> "WTF LOOOOOOOOOOOOL FFMPEG N GSOC!!!~!1`~!"
[20:15] <kierank> saste: is it public?
[20:15] <llogan> xiph is in too
[20:15] <llogan> https://www.google-melange.com/gsoc/org/list/public/google/gsoc2015
[20:16] <kierank> ah
[20:16] <jamrial> what are xiph's proposed projects? daala?
[20:16] <llogan> https://wiki.xiph.org/Summer_of_Code_2015
[20:17] <jamrial> thanks
[20:17] <llogan> looks like mostly icecat stuff
[20:17] <ubitux> do we really have interesting gsoc topic?
[20:17] <llogan> *icecast
[20:18] <ubitux> that's a good news though
[20:19] <Daemon404> ubitux, well im still thinking gsoc will go about as well as previous years
[20:19] <ubitux> it's been a few years we aren't on gosc so..
[20:19] <Daemon404> every year*
[20:21] <llogan> did we pay the OPWers yet?
[20:24] <cone-561> ffmpeg 03Luca Barbato 07master:619d5e7db889: v4l2: Use the codec descriptor facility
[20:24] <cone-561> ffmpeg 03Michael Niedermayer 07master:cde6e328de21: Merge commit '619d5e7db88941cadb8136f805564e885c6c6434'
[20:26] <michaelni> llogan, thats a question for saste, he seems to have just left
[20:27] <llogan> i don't know the timeline or anything. just curious
[20:29] <rcombs> oh hey gsoc \o/
[20:35] <pross> gwoc \o/
[20:37] <llogan> jamrial: i poked klaussfreire
[20:40] <cone-561> ffmpeg 03Luca Barbato 07master:9a26ba971387: v4l2: Add support for h264
[20:40] <cone-561> ffmpeg 03Michael Niedermayer 07master:f2e01b693fe4: Merge commit '9a26ba971387a348e14f363ddcdcb5bba0b413d1'
[20:47] <compn> Daemon404 and his double secret probation
[20:47] <compn> :D
[20:51] <ubitux> can anyone tell me what's the point of *avctx->coded_frame           = *pic; in proresenc_kostya.c?
[20:55] <REASY> Hello all
[20:55] <compn> hello
[20:55] <REASY> I think I found bug in mpegts_free
[20:56] <REASY> How can I help with this bug?
[20:56] <llogan> how can the issue be duplicated? also, we are often a forgetful lot. making a bug report is probably the best thing to do.
[20:56] <llogan> or submit a patch
[20:57] <REASY> I'm not sure that it's really  bug
[20:57] <REASY> But I have memory leaks
[20:58] <REASY> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mpegts.c
[20:58] <REASY> in method static void mpegts_free(MpegTSContext *ts)
[20:59] <REASY> At first clear_programs(ts);
[21:00] <REASY> But after clear we can't free earier allocated memory 
[21:00] <REASY> in static MpegTSFilter *mpegts_open_section_filter()
[21:03] <cone-561> ffmpeg 03Martin Storsjö 07master:91eee2af8727: Revert "mov: Change DTS-based seek into CTS-based seek."
[21:03] <cone-561> ffmpeg 03Michael Niedermayer 07master:82fe4072ea42: Revert "avformat/mov: Bypass av_add_index_entry()"
[21:03] <cone-561> ffmpeg 03Michael Niedermayer 07master:cb39fe933653: Merge commit '91eee2af87278b3c2008f7a86d2cdfe6934e9f42'
[21:04] <REASY> Can one approve my bug?
[21:10] <ubitux> i'm pretty puzzled at this coded_frame thing
[21:11] <ubitux> encoder allocates and free it
[21:11] <ubitux> but never use it
[21:11] Action: ubitux confused
[21:13] <nevcairiel> yeah its not used by the libs itself
[21:13] <nevcairiel> the encoders set some fields, and api users could read those fields
[21:13] <nevcairiel> but its really kinda pointless
[21:13] <ubitux> what
[21:13] <jamrial> REASY: create a ticket in https://trac.ffmpeg.org if you can
[21:14] <jamrial> it will make it easier for us to keep track of it
[21:14] <REASY> Ok, thanks, I undestand
[21:14] <REASY> But I debugging WinRT build of last ffmpeg
[21:15] <REASY> And maybe I do something wrong
[21:15] <REASY> I will retest 
[21:15] <wm4> <nevcairiel> but its really kinda pointless <- why am I not surprised
[21:16] <ubitux> nevcairiel: but ok, that clears things up
[21:16] <ubitux> i can fix the encoder then
[21:27] <cone-561> ffmpeg 03Clément BSsch 07master:546d69eb43e8: avcodec: use av_frame_free() for coded_frame
[21:27] <cone-561> ffmpeg 03Clément BSsch 07master:17cb05fe0634: avfilter/lavfutils: use av_frame_free for freeing an AVFrame
[21:27] <cone-561> ffmpeg 03Clément BSsch 07master:f5cbb2c55e19: avfilter/vf_tblend: use av_frame_free for freeing an AVFrame
[21:37] <ubitux> michaelni: didn't you send a patch to alloc the coded frame only in one place?
[21:37] <ubitux> i vaguely remember such patch but can't find it
[21:42] <michaelni> ubitux, you know i cant spell, search for "codec_frame" but i think the patch had some issues which i fixed locally
[21:43] <ubitux> haha, ok thamks
[21:43] <ubitux> the cool thing with such typo is that the only occurence is the one i'm looking for
[21:43] <ubitux> (please don't take this as an encouragement to make more of them)
[21:50] <ubitux> michaelni: don't you need to add a avctx->coded_frame->key_frame = 1 ?
[21:50] <cone-561> ffmpeg 03Timo Rothenpieler 07master:b86af8da3100: avformat/dashenc: Use local variable instead of duplicated dereferences
[21:50] <cone-561> ffmpeg 03Timo Rothenpieler 07master:6cfd53667509: avformat/dashenc: Update codec_str on extradata_size change
[21:50] <ubitux> btw, isn't this information in the avpacket anyway?
[21:50] <ubitux> why do we need to use coded_frame for that?
[21:51] <nevcairiel> the key frame info is indeed pointless
[21:51] <nevcairiel> some other info like frame type, or some other statistic values are more useful
[21:51] <ubitux> ah, the error thing
[21:52] <ubitux> i see
[22:13] <cone-561> ffmpeg 03Martin Storsjö 07master:33d412eb4a2a: dashenc: Simplify code by using a local variable
[22:13] <cone-561> ffmpeg 03Michael Niedermayer 07master:bf691e1d3956: Merge commit '33d412eb4a2a083c1514ddbe69295b37e1918a8c'
[22:56] <cone-561> ffmpeg 03Clément BSsch 07master:da2a49ac9ab5: avcodec/proresenc_kostya: fix coded_frame handling
[00:00] --- Tue Mar  3 2015