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

[burek]

[00:15] <jamrial> speaking of http://coverage.ffmpeg.org/, wouldn't it be better if it's run with cpuflags=0? it doesn't cover .asm files and we've gotten rid of most inline asm by now
[00:16] <jamrial> a lot of *dsp.c files outside the x86 folders are pretty red because the asm functions are used instead
[00:21] <Compn> jamrial : --disable-optimizations ?
[00:22] <Compn> probably just need more builds to be run, like fate i guess
[00:30] <ubitux> jamrial: so you suggest makesopts="CPUFLAGS=none"?
[00:30] <ubitux> i guess i can do that
[00:30] <ubitux> i have --disable-optimizations in the extra_conf already
[00:31] <ubitux> jamrial: added CPUFLAGS=none, you'll see the results at next run
[00:31] <jamrial> ubitux: cool, thanks
[00:36] <michaelni> maybe the code could be run twice for one coverage output, once with cpuflags=none and once normal
[00:37] <ubitux> yeah, i thought about running it with threads as well
[01:27] <michaelni> mraulet, d249e6828e8a84758010ec020a84dfcd156b585e breaks fate-hevc-conformance-INITQP_B_Sony_1 on alpha
[01:28] <michaelni> http://fate.ffmpeg.org/report.cgi?time=20140719192958&slot=alpha-debian-qemu-gcc-4.7
[01:33] <mraulet> all 10bits
[01:38] <mraulet> I think I have th bug
[01:52] <cone-472> ffmpeg.git 03db0 07master:9ce64ba11122: doc: update the documentation generator to match the new website
[01:52] <mraulet> I see this as a potential fix https://github.com/OpenHEVC/FFmpeg/commit/0a8ce1cbdaff7cd026bcf95ee3787bc7b4c063ee
[02:02] <cone-472> ffmpeg.git 03Clément BSsch 07master:28f31e78eb9c: doc: restore default.css
[02:26] <BBB>     sps->vps_id = get_bits(gb, 4);
[02:26] <BBB>     if (sps->vps_id >= MAX_VPS_COUNT) {
[02:26] <BBB> libavcodec/hevc.h:#define MAX_VPS_COUNT 16
[02:26] <BBB> what does that do?
[02:27] <mraulet> BBB nothing
[02:30] <michaelni> mraulet, that patch breaks alignment i think  but seems to fix alpha
[02:31] <mraulet> I can put 16 for edges
[02:31] <mraulet> instead of one
[02:41] <michaelni> mraulet, i have a crash with s->sps being null in get_buffer_sao() with that patch
[02:42] <michaelni> about alignment, dunno, i thought first it crashed because of aligment but it seems it doesnt, dunno if any simd functions access it and would benefit from align 
[02:43] <mraulet> at the moment none access to this buffer 
[02:43] <michaelni> then i guess + 1 is ok, but the correct sps need to be passed to this
[02:45] <michaelni> can fix that myself i guess if you are tired/busy
[02:47] <mraulet> ok it is almost 3am here :-)
[02:56] <michaelni> done
[02:56] <cone-472> ffmpeg.git 03Mickaël Raulet 07master:950a4f832661: hevc: fix offset for sao temporary frame
[05:47] <Timothy_Gu> ubitux: huh?
[05:47] <Timothy_Gu> I can probably fix the fate part
[05:47] <cone-472> ffmpeg.git 03Mickaël Raulet 07master:729479a199a9: fate/hevc: update fate rext tests
[05:49] <Timothy_Gu> michaelni, ubitux: Can you merge these two pull requests https://github.com/db0company/web/pulls?state=closed ?
[05:50] <Timothy_Gu> and take a look at the makeinfo patches on ML and https://github.com/db0company/web/pulls
[05:51] <Timothy_Gu> ubitux: for coverage you can take a look at it.
[05:54] <michaelni> Timothy_Gu, ill leave it to ubitux, iam too tired atm, dont want to mess up and cherry pick of 940b76dc85547d3e97bd0c08dedba330397a7030 produces conflicts
[05:55] <michaelni> ubitux, likely wil be awake tomorrow before me
[09:59] <rcombs> wow, new website is super-sexy
[10:00] <rcombs> though "Converting videos and audios has never been so easy." <-- feels like this would be better as "video and audio"
[10:01] <kurosu> "The FFmpeg project is proud a brand new version" <- of ?
[10:02] <rcombs> I see "The FFmpeg project is proud a brand new version of the website made by db0."
[10:02] <kurosu> was made then ?
[10:02] <kurosu> still confusing
[10:02] <rcombs> which seems to be missing a "to launch" or "to announce" or something
[10:03] <kurosu> yeah
[10:04] <kurosu> I don't think it's very important but the top part before news doesn't fit in my screen height
[10:06] <ubitux> oups, seems i was really tired yesterday
[10:08] <ubitux> fixed
[10:09] <rcombs> fixed which?
[10:10] <ubitux> > to announce
[10:11] <rcombs> huzzah
[10:12] <rcombs> thoughts on "videos and audios"? "videos" seems natural, but I've never heard "audios" anywhere else
[10:13] <kurosu> sounds?
[10:14] <kurosu> your multimedia files?
[10:14] <kurosu> or drop audios altogether
[10:14] <rcombs> or just "video and audio"
[10:17] <ubitux> i'll make the change as soon as you agree together :p
[10:18] <rcombs> those in favor of "video and audio"?
[10:18] Action: rcombs \o
[10:18] <rcombs> those opposed?
[10:19] <rcombs> motion passes; one for, none against, 115 abstain
[10:19] <rcombs> (this is how democracy works, right?)
[10:20] <ubitux> :)
[10:20] <ubitux> ofc
[10:21] <rcombs> (and #ffmpeg-devel is run via direct democracy, right?)
[10:21] <rcombs> (yeah, let's go with that)
[10:22] <kurosu> actually, you just displayed an oligarchy of 1 person :D
[10:23] <rcombs> that'd be a dictatorship
[10:23] <rcombs> which I may or may not be OK with
[10:24] <rcombs> kurosu: would you like to cast an absentee ballot?
[10:25] <kurosu> if it means I get a poney, why not
[10:25] <kurosu> or bread and some games
[10:25] <rcombs> you can have circuses, but no bread
[10:26] <ubitux> i suggest a monarchy with king the queen, so please rcombs & kurosu, choose a change, the people of the ffmpeg are begging for you decision
[10:26] <ubitux> s/the/and/
[10:26] <ubitux> your* decision
[10:26] <rcombs> hear that, kurosu? This is a super-important bit of website copy
[10:27] <rcombs> so important that it's the very first issue being brought before the newly-established monarchy
[10:27] <rcombs> I'm sticking with my previous suggestion; what do you think, kurosu?
[10:28] <ubitux> (dropping the 's'?)
[10:28] <rcombs> (yeah)
[10:28] <rcombs> (on both words)
[10:28] <ubitux> the ss then
[10:29] <rcombs> no, `-ss` has to stay or else we can't seek without filters
[10:29] <ubitux> ah ok
[10:29] <rcombs> :P
[10:29] <ubitux> ffmpeg is really complex, i'm getting lost
[10:32] <rcombs> (that was a joke)
[10:34] <fionag> who's the king and queen?
[10:34] <fionag> and if there's kings and queens we need princes and princesses.
[10:34] <fionag> and knights, to fight the libav menace 
[10:45] <ubitux> fionag: yes we'll go at war after when we decided if we need to kill the 's' first
[10:47] <rcombs> it seems we're just waiting on someone to second the motion
[10:56] <fionag> 's' ?
[10:58] <ubitux> fionag: yes the original discussion is how to reword the sentence on our new frontpage
[10:59] <ubitux> like should we write "videos and audios", "video and audio", "videos", something else..
[12:27] <J_Darnley> Fucking designers!  Apparently they no longer know the meaning of "required".
[12:28] <J_Darnley> When I askes what javascript is required for on the download page, the answer should have been "to unhide the windows and mac links".
[12:35] <Mavrik> o, new page <3
[12:53] <JEEB> J_Darnley, lol
[12:54] <JEEB> yeah, for them "required" means "is it required for all the bells and whistles so that the site looks exactly like they designed"
[12:54] <J_Darnley> Yeah... patch on its way.
[13:20] <Mavrik> so basically, instead of using JS to hide icons, they used it to show them? :)
[13:23] <J_Darnley> Something like that
[14:09] <cone-390> ffmpeg.git 03Jan Gerber 07master:73b7a360d8a3: matroskaenc: Don't set language to empty string, use "und"
[15:48] <michaelni> ubitux, db0 , on download.html theres a button with "git Git Snapshot", i guess the double git is a typo
[15:49] <ubitux> one is an icon
[15:49] <ubitux> but yeah i guess we could drop it
[15:49] <michaelni> icon + alt="git" ?
[15:52] <db0> ok
[17:03] <Timothy_Gu> michaelni: yep. http://fortawesome.github.io/Font-Awesome/examples/
[17:09] <cone-390> ffmpeg.git 03db0company 07master:e2842cfe76c9: MAINTAINERS: Add db0 for the website
[17:18] <Timothy_Gu> ubitux: any comments on my patches?
[18:38] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/0.5:04fb6bb9155a: avcodec/parser: reset indexes on realloc failure
[18:38] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/0.5:02ac859dfe1f: avcodec/jpeglsdec: check err value for ls_get_code_runterm()
[18:38] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/0.5:43aae0045572: avcodec/vmnc: Check  that rectangles are within the picture
[18:38] <cone-390> ffmpeg.git 03Dale Curtis 07release/0.5:90c8fa52216b: matroska: Fix use after free
[18:38] <cone-390> ffmpeg.git 03Xi Wang 07release/0.5:974c2ad87c34: lzo: fix overflow checking in copy_backptr()
[18:38] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/0.5:24a0273cb86e: avutil/lzo: Fix integer overflow
[18:39] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/0.5:a81f72e48231: Update for 0.5.14
[18:54] <cone-390> ffmpeg.git 03db0company 07fatal: ambiguous argument 'refs/tags/n0.5.14': unknown revision or path not in the working tree.
[18:54] <cone-390> Use '--' to separate paths from revisions
[18:54] <cone-390> refs/tags/n0.5.14:HEAD: MAINTAINERS: Add db0 for the website
[19:00] <michaelni> Btw, about http://trac.ffmpeg.org/wiki/Downstreams, IMHO it should be sorted by ffmpeg release not by distro/app name
[19:01] <michaelni> would be more usefull to see for us who still uses a given branch
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:0916d0f9d1b9: vorbisdec: Check bark_map_size.
[19:17] <cone-390> ffmpeg.git 03Dale Curtis 07release/1.0:85b1ce977bd5: matroska: Fix use after free
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:588ae964f4bb: swscale/x86/swscale: fix missing xmm clobbers in yuv2yuvX_sse3()
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:1ec03662c0f2: avcodec/h263dec: Fix use of uninitialized memory from the bitstream buffer
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:5f7e6b9c37a4: avcodec/x86/mpegvideoenc_template: fix integer overflow
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:551f36955c6b: avcodec/h264_mp4toannexb_bsf: prepend global headers before any in stream parameter sets
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:12eb9d911121: avcodec/wma: use av_freep(), do not leave stale pointers in memory
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:81e5ce4c280e: swresample/resample: Limit filter length
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:b1ac8b1d3842: swresample/dither: use av_malloc_array()
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:d7573f88a9b9: swresample/resample: use av_malloc_array() where appropriate
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:f80af81e6e12: swscale/x86/swscale_template: loose hardcoded dstw_offset
[19:17] <cone-390> ffmpeg.git 03Anthoine Bourgeois 07release/1.0:b5ec163e5a47: avcodec/dirac_arith: Fix build with PIC and stack-check options
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:0443fe264068: avcodec/x86/idct_sse2_xvid: fix non C99 inline function
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:f3230ba067af: avformat/mpegts: Remove redundant check
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:00476d924902: avcodec/diracdec: fix undefined behavior with shifts
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:43d24fc34cb8: avcodec/g723_1: add assert to help static code analyzers
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:8ef02e4e89a2: avfilter/vf_deshake: fix loss of precission with odd resolutions
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:ee0db8a51f8c: avfilter/filtfmts: Support dynamically allocated in/outputs
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:acba4d1e55e0: avformat/h263dec: Fix h263 probe
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:6b0c1ed11608: swresample: fix AV_CH_LAYOUT_STEREO_DOWNMIX input
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:2277706b3581: avcodec/mjpegdec: Fix undefined shift
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:033b0a4e7fc8: avfilter/graphdump: Fix pointer to local outside scope
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:1930efe23650: avutil/cpu: force mmx on selection of higher x86 SIMD features
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:a116f16e5dc7: avcodec/libvorbisenc: dont add the duration to AV_NOPTS_VALUE
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:8935e2390074: avformat/flvenc: Do not allow creating h263/mpeg4 in flv without unofficial format extensions being enabled.
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:f48d7abf40f3: avcodec/alsdec: Clear MPEG4AudioConfig so that no use of uninitialized memory is possible
[19:17] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:8f443e4f32c9: avformat/mpc: attempt to allocate a packet that is not smaller than the data inside it
[19:18] <cone-390> ffmpeg.git 03Xi Wang 07release/1.0:ff712a262d31: lzo: fix overflow checking in copy_backptr()
[19:18] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:7b5c706494a7: avutil/lzo: Fix integer overflow
[19:18] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:3a2c4453f04e: avformat/utils: do not wait for packets from discarded streams for genpts
[19:19] <ubitux> Timothy_Gu_: which one?
[19:19] <ubitux> (sorry)
[19:20] <Timothy_Gu_> all of them ([PATCH 1/3] Use makeinfo to generate html doc for the new website et al.)
[19:21] <michaelni> mraulet, smarter, is "Christophe Gisq (3.2K) [FFmpeg-devel] [PATCH] hevc: wait proper position for tmvp" and "Christophe Gisq (5.2K) [FFmpeg-devel] [PATCH 2] hevc: use different thread wait/report for tmvp" ok to be applied ?
[19:21] <mraulet> I look into it
[19:24] <cone-390> ffmpeg.git 03Michael Niedermayer 07release/1.0:f2a8c429dc60: update for 1.0.10
[19:48] <ubitux> Timothy_Gu_: this will require a different setup on the server
[19:49] <cone-390> ffmpeg.git 03db0company 07fatal: ambiguous argument 'refs/tags/n1.0.10': unknown revision or path not in the working tree.
[19:49] <cone-390> Use '--' to separate paths from revisions
[19:49] <cone-390> refs/tags/n1.0.10:HEAD: MAINTAINERS: Add db0 for the website
[19:52] <ubitux> Timothy_Gu_: doc/style.min.css is already in
[19:52] <ubitux> for make info i dunno
[19:53] <ubitux> (i don't know perl)
[19:54] <ubitux> ah i was looking at the wrong patchset
[19:55] <ubitux> Timothy_Gu_: no way for patch 3/3
[19:55] <ubitux> keeping in sync that way sucks
[20:00] <kurosu> mraulet, michaelni I think it needs more careful analysis
[20:00] <kurosu> I don't know if it breaks smething when wpp is used on a frame and not on another
[20:01] <kurosu> and 1% is good but depends a lot on how the system behaves
[20:01] <kurosu> I mean, the "use different thread" etc
[20:02] <kurosu> mraulet, if you have a system with more than 2 cores and could test in either openhevc or ffmpeg...
[20:08] <kurosu> BBB / michaelni, also thinking of a new threading api based on reporting x/y
[20:09] <kurosu> as vp9/hevc can use structures that are up to 64 pixels wide and up, this might help
[20:09] <kurosu> so far, I failed to make it work on hevc
[20:10] <kurosu> https://github.com/kurosu/ffmpeg/commit/577561fcf48965dfdf74fc2c12b7675f37d463b1
[20:10] <kurosu> not intended for real review, but just something that may get you interested more than just talk
[20:35] <Timothy_Gu> ubitux: I know, and I tried to avoid it. But makeinfo sucks, it automatica
[20:35] <Timothy_Gu> automatically inserts markup.
[20:36] <Timothy_Gu> There's no way to work around it without doing this ugly hack.
[20:36] <ubitux> open a ticket to them and tell them we can't migrate to makeinfo because of this
[20:37] <ubitux> this is a maintainance regression, there is no way we're going to maintain 2 version with different split granularity
[20:51] <cone-390> ffmpeg.git 03Nidhi Makhijani 07master:9f99a5f1d078: mpegencconetxt: Move rv10-specific orig_width/orig_height where they belong
[20:51] <cone-390> ffmpeg.git 03Michael Niedermayer 07master:02e3e3ea51ff: Merge commit '9f99a5f1d078721a30a76aec27c58805b7b87e58'
[21:01] <BBB> kurosu: vp9 is lazy as hell, it just does y only
[21:01] <BBB> kurosu: I believe h264 does that also?
[21:01] <kurosu> BBB: does the api allow that at all ?
[21:02] <kurosu> it didn't seem to me
[21:02] <BBB> sure
[21:02] <BBB> ff_thread_report_progress(frame, y);
[21:02] <BBB> and await_progress then adjusts y based on loopfilter and mc filter size
[21:03] <BBB> its super-easy
[21:03] <kurosu> errr, I mean waiting on x too, or am I missing something ?
[21:04] <Timothy_Gu_> ubitux: I found a way to fix it!
[21:04] <ubitux> good :)
[21:08] <BBB> kurosu: sure, ff_thread_await_progress(frame, y * n_columns + x);
[21:08] <BBB> kurosu: e.g. vp8 does that
[21:10] <kurosu> weird, I thought about doing this and at some point "not gonna work"
[21:10] <kurosu> I'll think about it then
[21:11] <BBB> it depends on both halfs of how its used
[21:11] <BBB> if you do loopfilter per-row: not gonna work
[21:11] <kurosu> it's done per super structure so should work
[21:11] <BBB> if your frame handling is strictly per-block: may work
[21:11] <BBB> right
[21:12] <BBB> vp9 does loopfilter per-row so wont work as-is
[21:12] <BBB> I had a proof-of-concept patch to change it, but it wasnt faster
[21:12] <mraulet> kurosu it will be complex to manage for tiles
[21:12] <kurosu> yeah, it might but the more frequent checks/updates have a cost too
[21:12] <BBB> nah tiles is easy, vp9 has that issue too
[21:14] <kurosu> mraulet, wpp/slices/tiles may all report different levels of completion at for different y - does it actually work currently unless you force strict raster scan processing ?
[21:15] <mraulet> but using y and x to report progress might become complex with tiles
[21:15] <kurosu> does it work now ?
[21:16] <mraulet> now? means?
[21:16] <mraulet> with the current head
[21:16] <kurosu> does frame-mt work with threaded decoding of tiles
[21:16] <mraulet> yes
[21:16] <kurosu> there was support for wpp, but it didn't seem obviously the case for tiles, from the code
[21:16] <mraulet> we are reporting at the end of a row
[21:17] <mraulet> ah you mean having for in parallel
[21:17] <kurosu> yeah
[21:17] <mraulet> you cannot have both slice and frame with ffmpeg upstream
[21:18] <mraulet> but it is available in openhevc
[21:18] <kurosu> ok
[21:18] <kurosu> you told me you had wpp+frame-mt too
[21:19] <mraulet> the counterparts it is hard to know the number of threads to give for wpp or frame
[21:19] <BBB> wpp cant change frame-to-frame can it?
[21:19] <kurosu> what's the level of signalling of wpp already? sps ?
[21:19] <mraulet> sps
[21:19] <kurosu> because you could report x,y report only if wpp is deactivated at the sps level
[21:20] <kurosu> but same for slices and tiles, though
[21:20] <kurosu> anyway, these are all rethorical if x/y report actually doesn't bring benefit
[21:20] <mraulet> x265 has wpp activated inside :-)
[21:21] <kurosu> both wpp and frame-mt ?
[21:21] <mraulet> if I am not wrong
[21:21] <kurosu> well wpp is the most obvious option for many implementations
[21:21] <mraulet> we also have tiles and frame-mt but it does not give benefit
[21:22] <mraulet> because of loop_filter across_tiles
[21:22] <kurosu> that exists also for slices
[21:23] <mraulet> slice level parallelism is not active
[21:23] <mraulet> we use slice level for tiles and wpp
[21:24] <mraulet> but not for slice itself
[21:24] <mraulet> right now at least
[21:24] <mraulet> michaelni: what is the issue with the arm platform?
[21:26] <michaelni> issue ? arm ?
[21:27] <iive> bytestream aligned access?
[21:27] <mraulet> http://fate.ffmpeg.org/?query=cc:gcc%204.4.3%20%28Ubuntu%204.4.3-4ubuntu5.1%29%2F%2F
[21:27] <cone-390> ffmpeg.git 03Michael Niedermayer 07master:9a8a18a2e9c3: doc/issue_tracker: Correct sub-domain for mailing list
[21:28] <kurosu> potentially the intreadwrite patch as it relates to mv pred
[21:29] <mraulet> yeah but there is a new option in the command line of the configure that seems to fix hevc fate
[21:29] <mraulet> disable-asm
[21:31] <Timothy_Gu_> ubitux: https://gist.github.com/TimothyGu/d9df4cecf8297fb75168
[21:31] <Timothy_Gu_> is it ok?
[21:31] <iive> could "libavcodec/arm/mlpdsp_armv5te.S:626: Warning: conditional outside an IT block for Thumb." be releated?
[21:32] <iive> all i see are warnings.
[21:32] <kurosu> iive: no the crashes are in hevc code
[21:32] <mraulet> but fixed with disabled-asm
[21:32] <mraulet> the only assembly code for now in hevc is the cabac
[21:32] <kurosu> might be a pointer alignment issue
[21:33] <kurosu> mraulet, no other dsp used like block copy or the like ?
[21:34] <mraulet> no
[21:34] <kurosu> anyway, having a backtrace should clear things up
[21:34] <mraulet> emu_edge may be
[21:34] <iive> is there way to automate backtrace ?
[21:35] <kurosu> mraulet, was your patch around sao that used a one-pixel border applied ?
[21:35] <kurosu> if yes, that might be it
[21:35] <ubitux> Timothy_Gu_: ok, cool :)
[21:35] <mraulet> now it is back to green
[21:35] <mraulet> http://fate.ffmpeg.org/?query=cc:gcc%204.4.3%20%28Ubuntu%204.4.3-4ubuntu5.1%29%2F%2F
[21:36] <mraulet> without any disable-asm option
[21:36] <mraulet> I am lost
[21:36] <mraulet> :-)
[21:37] <iive> well, it might use ununitilized data, thus giving random errors. or overheating or faulty hardware. (or emulation).
[21:37] <michaelni> well ive no clue either, ill try to build it with similar options and see if i can get it to crash under gdb
[21:38] <michaelni> would be nice though if we could extend fate so it always provides back traces
[21:41] <iive> maybe `gdb -x runbacktrace.cmd --args "$*" `
[21:43] <iive> runbacktrace.cmd contains "run" and "bt" on separate lines.
[21:47] <iive> add "quit" as third line too.
[21:48] <michaelni> ideal would be some kind of --enable-gdb that does all 
[21:48] <michaelni> the needed stuff
[21:48] <michaelni> for fate clients
[21:49] <iive> i've seen some project link to gdb in order to provide backtrace at segfalut. not sure how it is done.
[21:53] <iive> ok, instead of quit -batch option does the trick.
[21:53] <iive> michaelni: you can execute tests with added `gdb -batch -x runbt.cmd --args "$*" `  where $* is the current command
[22:00] <michaelni> iive doesnt work
[22:00] <michaelni> --target_exec='gdb -batch -x runbt.cmd --args' leads to fate failures due to gdb output being interpreted as app output
[22:01] <michaelni> like "+[Thread debugging using libthread_db enabled]"
[22:03] <iive> oh..
[22:03] <iive> -batch-silent might help
[22:03] <iive> i just hope it won't suppress the backtrace
[22:03] <iive>  it does...
[22:04] <iive> and it doesn't seem to suppress everything.
[22:07] <kurosu> BBB: neither h264 nor vp8 seems to wait based on the x position
[22:07] <BBB> h264 doesn't
[22:07] <BBB> I believe vp8 does?
[22:07] <BBB> maybe I misremember
[22:07] <kurosu> example: ff_thread_await_progress(ref, (3 + y_off + block_h + subpel_idx[2][my])
[22:08] <kurosu> so no
[22:08] <BBB> oh it doesn't
[22:08] <BBB> how interesting
[22:08] <kurosu> if you think about it, you can just do x*row+x
[22:08] <BBB> ohwell, sorry
[22:08] <kurosu> err y*row+x
[22:08] <iive> michaelni: -batch -q seems to suppress most output while showing the backtrace.
[22:08] <BBB> y*n_cols+x
[22:09] <kurosu> you need to do something like (y&(block_size-1))*row + x*block_size
[22:09] <kurosu> *can't just do
[22:09] <BBB> right, y/x is clearly in unit block size
[22:09] <BBB> which for h264/vp8 would be 16x16, and for vp9/hevc is 64x64
[22:09] <BBB> although I guess it can be less for hevc with variable max_ctb_size
[22:10] <BBB> gotta go
[22:10] <kurosu> bye
[22:10] <kurosu> for now can't make that to work with hevc
[22:10] <michaelni> iive, still fails with diffs like "+[Inferior 1 (process 26165) exited normally]"
[22:10] <kurosu> as soon as I add progress on an incomplete row, it fails
[22:11] <iive> guh,, ERROR "OK"
[22:11] <iive> is every text output treated as error?
[22:16] <iive> maybe when normal run exits, it can't execute 'bt' thus returning error.
[22:25] <iive> michaelni: does -return-child-result help?
[22:31] <michaelni> iive why dont you try it? would be faster sure than if i do and post the result and yu interpret, and no that also fails the same way, fate uses the output of some tests and any change causes failure
[22:32] <michaelni> stdout output must not chnage
[22:32] <iive> i don't have fate here... and that's a problem.
[22:32] <iive> i mean, it would take a bit to set it up.
[22:33] <michaelni> you dont need to setup a real fate client
[22:33] <michaelni> make fate fails too
[22:34] <michaelni> you just need  --samples=<some dir here> and make fate-rsync to get the samples
[22:34] <michaelni> thats unless you already have them somewhere then you cna use that
[22:41] <iive> so far I can't find a way to suppress gdb stderr output...
[22:41] <iive> so I'm out of ideas.
[22:44] <Timothy_Gu> how about *san toolchains or libsegfault?
[22:55] <michaelni> none of that is available on that arm box
[22:56] <michaelni> also at least valgrind does not work on it
[22:56] <michaelni> before someone suggests it
[23:00] <iive> that's to be expected, valgrind implements a whole virtual machine/cpu
[23:01] <iive> so it is not trivial to port it to other arch
[23:04] <michaelni> valgrind supposedly supports arm
[23:08] <michaelni> also if someone has a arm box with working valgrind, please setup a fate client, independant of these issues now it would be very usefull
[23:24] <Timothy_Gu_> db0, ubitux: updated patch posted. BTW this also fixes the double title as seen here: http://ffmpeg.org/ffmpeg.html
[00:00] --- Mon Jul 21 2014