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

[burek]

[00:07:28 CEST] <iive> how could performance inprove drastically in the last 48 hours??
[00:07:45 CEST] <nevcairiel> new BIOSes
[00:08:41 CEST] <iive> new microcode?
[00:09:06 CEST] <nevcairiel> who knows what parts exactly influence it so much
[00:10:34 CEST] <iive> that's my point
[00:13:56 CEST] <nevcairiel> I asked some of them if they can elaborate what exactly influences it so much, but i dont know if they know :)
[00:41:24 CEST] <DHE> ryzen?
[00:44:42 CEST] <iive> :)
[00:48:41 CEST] <DHE> I have one of those. can confirm BIOS updates are a must...
[00:48:59 CEST] <DHE> would not be surprised for a big performance boost from a bios update, probably related to RAM
[01:12:33 CEST] <TMM> atomnuker, when creating a patch series for review, is it OK if some patches depend on previous patches?
[01:14:18 CEST] <jamrial> TMM: yes
[01:20:53 CEST] <TMM> jamrial, thanks
[01:36:45 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07release/3.2:b7362f3c6bc2: avcodec/hevcpred_template: Fix left shift of negative value
[01:36:46 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07release/3.2:74cf081ef09f: avcodec/jpeg2000dsp: Reorder operations in ict_int() to avoid 2 integer overflows
[01:36:47 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07release/3.2:431ccd3f55ea: Changelog: update
[02:28:21 CEST] <cone-823> ffmpeg 03Daniel Kucera 07n3.2.6:HEAD: libavformat/file: return AVERROR_EOF on EOF
[12:49:54 CEST] <atomnuker> is there some way to allocate around 30 floats on stack from asm?
[12:52:40 CEST] <atomnuker> meh, I'll use 9 regs and live with 7 which is plenty
[12:54:07 CEST] <iive> atomnuker: you can put 4'th number in cgloval, and the entry code would allocate that many bytes in the stack
[12:54:37 CEST] <iive> aka, 4, 6, 6, 30*4, 
[12:55:18 CEST] <atomnuker> that's neat
[12:56:22 CEST] <iive> rsp then points to the start of the buffer, it is also mmsize aligned.
[12:58:33 CEST] <Gramner> the stack is realigned before allocating space, so if you need a certain alignment you must request a multiple of that alignment
[12:59:17 CEST] <Gramner> this is useful because sometimes you intentionally want misalignment, e.g. because you want to later push some args to the stack before calling another function
[13:01:15 CEST] <iive> Gramner: btw, if you don't give any number, or you put zero in there, the stack won't be touched
[13:02:01 CEST] <Gramner> well yes, we don't want to execute instructions to align stuff if we don't need to
[13:02:06 CEST] <iive> this means, that if i want to dynamically allocate stack space, i'd have to align myself.
[13:02:34 CEST] <iive> or allocate fixed mmsize first
[13:03:59 CEST] <Gramner> dynamic stack alignment is kind of evil though
[13:04:13 CEST] <Gramner> just unconditionally use the maximum size instead
[13:04:30 CEST] <Gramner> synamic stack allocation*
[13:05:53 CEST] <Gramner> I don't think we want to use alloca() in C code either?
[13:07:42 CEST] <atomnuker> we don't, libopus does and its horrible
[13:10:25 CEST] <wm4> weren't you pro-VLAs a while ago
[13:13:29 CEST] <atomnuker> I hadn't seen libopus
[13:33:24 CEST] <BBB> J_Darnley: Ive made very slow progress, but I think Im on to something, Ive found one encoded block that indeed does not use the permutation
[13:33:43 CEST] <BBB> J_Darnley: Im still tracking down where the block coding mode for that block comes from
[13:35:13 CEST] <J_Darnley> Thank you
[13:49:07 CEST] <BBB> michaelni: Im in mpv_decode_mb_internal, whats the easiest way to figure out what encode decision lead to a particular block choice? is there a helper macro to debug that?
[13:49:24 CEST] <BBB> or which variables should I log?
[13:49:38 CEST] <BBB> (I guess s->mb_intra, s->mv_dir, s->mv, etc.?)
[13:51:27 CEST] <BBB> first change in decode_internal: DCT coeffs of MB at 0x0, block=2, intra=0:
[13:51:40 CEST] <BBB> I think this is the second frame (its a 2-frame encode)
[13:53:57 CEST] <michaelni> s->mb_intra, s->mv_dir, s->mv ,s->mv_type is an option
[13:55:50 CEST] <michaelni> and ac_pred maybe
[14:13:06 CEST] <BBB> DCT coeffs of MB at 0x0, block=2, intra=0, mv_dir: 1, mv_type: 0, mv: -1,-4, ac_pred: 0
[14:13:10 CEST] <BBB> thats not particularly interesting
[14:14:06 CEST] <BBB> mv_type = 0 means 16x16, right?
[14:14:12 CEST] <BBB> mv_dir = 1 means mv_forward
[14:14:43 CEST] <BBB> maybe related to edge_mc being invoked?
[14:15:48 CEST] <BBB> I think its something else though, the coefficients are much, much larger than for the other blocks around it
[14:15:59 CEST] <BBB> is there a skip?
[14:20:04 CEST] <BBB> yes, the residual is missing in the encode_mb step
[14:20:24 CEST] <BBB> or, skip_dct[2] = 1
[14:20:54 CEST] <BBB> so I assume s->block_last_index[i] = -1; is a special thing that the encode_mb loop has to deal with?
[14:21:03 CEST] <BBB> and msmpeg4enc.c doesn't?
[14:21:12 CEST] <BBB> oh but this explains something else also
[14:21:26 CEST] <BBB> why did it - specifically for wmv1 - have a special step to re-find the eob?
[14:21:29 CEST] <BBB> now I get it
[14:21:38 CEST] <BBB> because it doesnt support block_last_index = -1
[14:21:47 CEST] <BBB> so& how do you encode skip in wmv1?
[14:22:20 CEST] <BBB> (msmpeg4enc.c:619)
[14:22:26 CEST] <BBB> I wonder if I can just delete that code
[14:23:14 CEST] <BBB> thats actually a pretty big bug and may actually have positive effects on wmv1 encoding performance
[14:23:20 CEST] <BBB> insofar that we care about that
[14:34:19 CEST] <BBB> or maybe I just didnt check block_last_index correctly
[14:39:09 CEST] <BBB> hm ok so ignore all of that
[14:39:18 CEST] <BBB> I still have a prediction error that I just cannot figure out :(
[14:41:23 CEST] <BBB>  pred - x: 4, y: 0, intra: 0, mvdir: 1 mv: 0/-4, mvtype: 0, mcsel: 0, qs: 0, flags: 0x800002 <- the predictor changes for the topleft 8x10 pixels in this block
[14:41:31 CEST] <BBB> its not off by much, but its off
[14:41:41 CEST] <BBB> the only diff is -idct simple being present or not
[14:42:21 CEST] <BBB> and as far as I can see, the reference frame is identical between the two
[14:42:23 CEST] <BBB> :(
[14:42:52 CEST] <BBB> J_Darnley: can we just force wmv1 to continue using C? I really dont think I want to spend much more time on this
[14:43:02 CEST] <BBB> J_Darnley: really, nobody in the world cares about wmv1 encoding. nobody does
[14:43:08 CEST] <BBB> this isnt worth spending time at
[14:43:28 CEST] <JEEB> not even wmv3/vc1 but wmv1
[14:43:30 CEST] <JEEB> yea, makes sense
[14:46:27 CEST] <wm4> I'd rather ask why the fuck we have wmv encoding at all
[14:46:42 CEST] <JEEB> because someone implemented it
[14:47:07 CEST] <JEEB> and well, at some point it had use cases I guess
[15:09:15 CEST] <BBB> is it true we dont have any msmpeg4v3 tests?
[15:09:21 CEST] <BBB> not encoding and not decoding?
[15:17:08 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07master:9a6503f496ae: avcodec/iff: Cleanup on init failure
[15:17:09 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07master:27c20068054d: avcodec/takdec: Fixes: integer overflow in AV_SAMPLE_FMT_U8P output
[15:17:10 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07master:4132218b87cd: avcodec/htmlsubtitles: Replace very slow redundant sscanf() calls by cleaner and faster code
[15:17:11 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07master:14b834c45a00: avcodec/htmlsubtitles: Factor open brace handling into its own function
[16:03:40 CEST] <cone-289> ffmpeg 03Hein-Pieter van Braam 07master:099d35401c1a: Cleanly exit at the end of an Interplay MVE
[16:17:47 CEST] <cone-289> ffmpeg 03Marton Balint 07master:8a0932531157: avformat/rmenc: do not access AVIO write buffer directly
[16:29:10 CEST] <jkqxz> wm4:  Happy with <http://sprunge.us/LUUd>?  I've gone back to a single array.  Also the subobjects now have separate definitions.
[16:33:00 CEST] <wm4> jkqxz: still worried about the consumer side of this, I guess I'll let LongChair decide (since he implemented this)
[16:33:13 CEST] <wm4> on the other hand, his code and the vaapi one are separate
[16:33:35 CEST] <wm4> jkqxz: why does the drm object descriptor need a size field?
[16:37:38 CEST] <jkqxz> While EGL doesn't want it for import, other things do (<https://github.com/01org/libva/blob/master/va/va.h#L927>, <https://cgit.freedesktop.org/beignet/tree/include/CL/cl_intel.h#n143>).
[16:37:42 CEST] <jkqxz> Also, it makes mmap() possible without huge amounts of code trying to work out what regions to map.
[16:37:52 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:d2f43c48f9cd: avcodec/aacdec_template: Fix fixed point scale in decode_cce()
[16:37:53 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f0a24f2f77d1: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int'
[16:37:54 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:2e7cf081a061: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int'
[16:37:55 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:fceacfc1320f: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[16:37:56 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3a69d5d3f01d: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int'
[16:37:57 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:08375d37be07: avcodec/mimic: Use ff_set_dimensions() to set the dimensions
[16:37:58 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:51a80d0f7165: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int'
[16:37:59 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b526aed4d580: avcodec/mlpdec: Do not leave a invalid num_primitive_matrices in the context
[16:38:00 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:1476c1b2c751: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 170 is too large for 32-bit type 'int'
[16:38:01 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4b5920e49302: avcodec/sbrdsp_fixed: fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[16:38:02 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:eee339866667: avcodec/mlpdsp: Fix runtime error: signed integer overflow: -24419392 * 128 cannot be represented in type 'int'
[16:38:03 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:56ce2cae385e: avcodec/takdec: Fix runtime error: left shift of negative value -63
[16:38:04 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:87de89ac7856: avcodec/aac_defines: Fix: runtime error: left shift of negative value -2
[16:38:05 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e6d6363eb30d: avcodec/takdec: Fix runtime error: signed integer overflow: 8192 * 524308 cannot be represented in type 'int'
[16:38:06 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:859188863b9d: avcodec/vmnc: Check location before use
[16:38:07 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9ac7c504eaa4: avcodec/mpeg4videodec: Check for multiple VOL headers
[16:38:08 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9a680966d1be: avcodec/aacdec_fixed: Fix runtime error: shift exponent 34 is too large for 32-bit type 'int'
[16:38:09 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:a8fb8cd716df: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -32767 * 130560 cannot be represented in type 'int'
[16:38:10 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:7b074e728d24: avcodec/ivi_dsp: Fix multiple runtime error: left shift of negative value -71
[16:38:11 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3b67878ab4f6: avcodec/jpeglsdec: Check get_bits_left() before decoding a picture
[16:38:12 CEST] <cone-289> ffmpeg 03Max Justicz 07release/3.1:1d35eda0b2c5: avcodec/sanm: Fix uninitialized reference frames
[16:38:13 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b3f8d3880002: avcodec/jpeg2000dec: Check tile offsets
[16:38:14 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:5202bef67aad: avcodec/jpeg2000dec: Fix copy and paste error
[16:38:15 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e383baee9c66: avcodec/smc: Check remaining input
[16:38:16 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b77ce15e4722: avcodec/aacdec_fixed: Fix runtime error: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int'
[16:38:16 CEST] <jkqxz> What are you feeling is problematic on the consumer side?
[16:38:17 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9aaadb1ee3eb: avutil/internal: Do not enable CHECKED with DEBUG
[16:38:18 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:162ad001b834: avformat/mux: Fix copy an paste typo
[16:38:19 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4354def5efb7: avcodec/ra144dec: Fix runtime error: left shift of negative value -17
[16:38:20 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f71d15f04fef: avcodec/mlpdec: Do not leave invalid values in matrix_out_ch[] on error
[16:38:21 CEST] <cone-289> ffmpeg 03Kevin Mark 07release/3.1:5aaec845738b: doc/filters: Clarify scale2ref example
[16:38:22 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:8da4f91fca83: avcodec/ivi_dsp: Fix runtime error: left shift of negative value -2
[16:38:23 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9ff9355b8497: avcodec/sbrdsp_template: Fix: runtime error: signed integer overflow: 849815297 + 1315389781 cannot be represented in type 'int'
[16:38:24 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:1c0524da00f0: avcodec/libfdk-aacdec: Correct buffer_size parameter
[16:38:25 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f4ff72cde6fc: avcodec/wnv1: More strict buffer size check
[16:38:26 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:cadb2d590dc9: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int'
[16:38:27 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:efa7ce36e372: avcodec/sheervideo: Check input buffer size before allocating and decoding
[16:38:28 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:c04d2b2f9ded: avcodec/jpeg2000dec: Check tile offsets more completely
[16:38:29 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:ed1a66821382: avcodec/jpeg2000: Fix runtime error: signed integer overflow: 4185 + 2147483394 cannot be represented in type 'int'
[16:38:30 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b778eb8d64c2: avcodec/snow: Fix runtime error: signed integer overflow: 1086573993 + 1086573994 cannot be represented in type 'int'
[16:38:31 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:41c6624c885c: avcodec/ylc: Check count in build_vlc()
[16:38:32 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:228093ec9368: avcodec/aacdec_fixed: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[16:38:33 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f88fd9027c49: avcodec/webp: Fixes null pointer dereference
[16:38:34 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:78603ff0f9e0: avcodec/aac_defines: Add missing () to AAC_HALF_SUM() macro
[16:38:35 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:37709a5f8205: avcodec/ra144: Fix runtime error: signed integer overflow: 11184810 * 404 cannot be represented in type 'int'
[16:38:36 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b31bb8a6142c: avcodec/ra144: Fix runtime error: signed integer overflow: -2449 * 1398101 cannot be represented in type 'int'
[16:38:37 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e561676c55aa: avcodec/truemotion2: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[16:38:38 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:79f75b123b34: avcodec/truemotion2: Fix passing null pointer to memset()
[16:38:39 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4ba6f68b27c2: avcodec/jpeg2000dec: Use ff_set_dimensions()
[16:38:40 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f11bc174292f: avcodec/ansi: Fix frame memleak
[16:38:41 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:64168825dec0: avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int'
[16:38:42 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:ea70971cbe9f: avcodec/wavpack: Check float_shift
[16:38:43 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:276eae8adc95: avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float'
[16:38:44 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:39c729c375a6: avformat/avidec: Limit formats in gab2 to srt and ass/ssa
[16:38:45 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:2a55e8bda943: avcodec/cavsdec: Fix runtime error: signed integer overflow: 59 + 2147483600 cannot be represented in type 'int'
[16:38:46 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4911902c6f31: avcodec/pnm: Use ff_set_dimensions()
[16:38:47 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:6ad05cbad1de: avcodec/ra144: Fixes runtime error: signed integer overflow: 7160 * 327138 cannot be represented in type 'int'
[16:38:48 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:317690375e78: avcodec/hevc_ps: Fix runtime error: signed integer overflow: 2147483628 + 256 cannot be represented in type 'int'
[16:38:49 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:89b2e25e138d: avcodec/cinepak: Check input packet size before frame reallocation
[16:38:50 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4007ba9833cb: avcodec/wavpack: Fix runtime error: signed integer overflow: 2013265955 - -134217694 cannot be represented in type 'int'
[16:38:51 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3ecefcabe076: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[16:38:52 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:cc6eec316e2a: avcodec/aacps: Fix runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'INTFLOAT' (aka 'int')
[16:38:53 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:6af15d2d896d: avformat/options: log filename on open
[16:38:54 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:80d39a5bb34d: avcodec/ac3dec_fixed: Fix runtime error: left shift of 419 by 23 places cannot be represented in type 'int'
[16:38:55 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e04d3aadc01f: avcodec/pafvideo: Check packet size and frame code before ff_reget_buffer()
[16:38:56 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:0ad5a36b8b7a: avcodec/dxv: Check remaining bytes in dxv_decompress_raw()
[16:38:57 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:278b8d18ad29: avcodec/hevc_ps: Fix runtime error: index 32 out of bounds for type 'uint8_t [32]'
[16:38:58 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:1f4da7c38460: avutil/softfloat: Fix sign error in and improve documentation of av_int2sf()
[16:38:59 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:6f49b9a68813: avcodec/qdrw: Fix null pointer dereference
[16:39:00 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e0a3b8670d27: avformat/hls: Check local file extensions
[16:39:01 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:bcf63142d159: avcodec/cavs: Fix runtime error: signed integer overflow: -12648062 * 256 cannot be represented in type 'int'
[16:39:02 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:42b26b41a4e6: avcodec/tiff: Avoid loosing allocated geotag values
[16:39:03 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:79f0677332c3: avcodec/mjpegdec: Check that reference frame matches the current frame
[16:39:04 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e8aa646e4a23: avcodec/takdec: Fix multiple runtime error: signed integer overflow: 637072 * 4096 cannot be represented in type 'int'
[16:39:05 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:fb1d3fb1e5af: avcodec/pafvideo: Fix assertion failure
[16:39:06 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:faa104541d36: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 53098 * 40448 cannot be represented in type 'int'
[16:39:07 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:cd16f4cf4b08: avcodec/ac3dec_fixed: Fix multiple runtime error: signed integer overflow: -39271008 * 59 cannot be represented in type 'int'
[16:39:08 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:26afadbd2935: avcodec/indeo4: Check remaining data in Pic hdr extension parsing code
[16:39:09 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f263c4687f60: avcodec/cfhd: Check band parameters before storing them
[16:39:10 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4f2aaccff0ec: avcodec/flicvideo: Fix runtime error: signed integer overflow: 4864 * 459296 cannot be represented in type 'int'
[16:39:11 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9f5ada688051: avcodec/ra144: Fix runtime error: signed integer overflow: -2200 * 1033073 cannot be represented in type 'int'
[16:39:12 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:427ee58d613a: avcodec/tiff: Fix leak of geotags[].val
[16:39:13 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:7927112377b5: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1297616
[16:39:14 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:afc6d2242cbc: avcodec/snowdec: Fix runtime error: left shift of negative value -1
[16:39:15 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:562690a7f73e: avcodec/wavpack: Fix runtime error: signed integer overflow: 1886191616 + 277872640 cannot be represented in type 'int'
[16:39:16 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3a3c32ea1f81: avcodec/jpeg2000dwt: Fix runtime error: left shift of negative value -123
[16:39:17 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:fc5bbdf2c5ab: avcodec/sbrdsp_fixed: Return an error from sbr_hf_apply_noise() if operations are impossible
[16:39:18 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:fe3fcc551d71: avcodec/aacsbr_fixed: Check shift in sbr_hf_assemble()
[16:39:19 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:c19fd272482e: avcodec/mpeg4videodec: Fix integer overflow in num_sprite_warping_points=2 case
[16:39:20 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:5d609474f3b5: avcodec/mpeg4videodec: Check sprite delta upshift against overflowing.
[16:39:21 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:8d0c353b733b: avcodec/hevc_refs: Check nb_refs in add_candidate_ref()
[16:39:22 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:2d7e26277a7b: avcodec/hevcdec: Check nb_sps
[16:39:23 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3e6b7d5802f1: avcodec/jpeg2000: Fixes integer overflow in ff_jpeg2000_ceildivpow2()
[16:39:24 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:cfaa5affadd5: avcodec/truemotion2: Move skip computation after checks
[16:39:25 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:37c77f74c277: avcodec/shorten: Sanity check maxnlpc
[16:39:26 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:d51d7b097144: avcodec/jpeg2000dec: Check nonzerobits more completely
[16:39:27 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:10dc2c48ed04: avcodec/hevcdec: Fix signed integer overflow in decode_lt_rps()
[16:39:28 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:2d0fd04f1619: avcodec/hevcpred_template: Fix left shift of negative value
[16:39:29 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:575ba2100787: avcodec/jpeg2000dsp: Reorder operations in ict_int() to avoid 2 integer overflows
[16:39:30 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:8a38efad428f: avcodec/takdec: Fixes: integer overflow in AV_SAMPLE_FMT_U8P output
[16:39:31 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:dcace98d085b: Update for 3.1.9
[16:41:18 CEST] <jkqxz> wm4:  [Post git spam]  What are you feeling is problematic on the consumer side?
[16:41:54 CEST] <atomnuker> jamrial / nevcairiel: do you know why doing a movu from [%1q + 1*mmsize + 8 + %2] inside a macro doesn't work?
[16:42:44 CEST] <atomnuker> its like the %2 index gets ignored and I load incorrect things
[16:43:02 CEST] <atomnuker> incrementing %1 outside the macro works though
[16:43:44 CEST] <wm4> jkqxz: determining how the planes or images are assembled
[16:44:11 CEST] <wm4> basically translating it to calls that create EGL images or map DRM FBs
[16:45:02 CEST] <jkqxz> I added the plane_index field to help in this one now that it isn't implicit in the structure of the nested array.
[16:45:08 CEST] <wm4> I keep thinking that just a flag that tells you whether it's a format that implicitly merges both planes, or that exports separate buffers, would be the best
[16:45:27 CEST] <wm4> is it possible to map a vaapi NV12 image as DRM FB?
[16:45:42 CEST] <wm4> or does it have to go through VPP RGB conversion
[16:46:16 CEST] <jkqxz> I think the FB on Intel has to be RGB.
[16:47:31 CEST] <jkqxz> (You make the FB separately, map that to a VAAPI object, and VPP into it.)
[16:48:11 CEST] <jkqxz> Or at least, I assume you do for pure DRM FBs.  I've only ever done it with ones coming from DRI.
[16:53:50 CEST] <wm4> jkqxz: also not sure if I get format/format_modifier
[16:54:04 CEST] <wm4> shouldn't at least one of them be per object?
[16:57:13 CEST] <jkqxz> Maybe modifier could be per-object, but I'm not sure whether that is a real constraint.  (format definitely isn't.)
[16:57:50 CEST] <wm4> huh
[17:09:23 CEST] <jkqxz> Modifiers are per-object <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bae781b259269590109e8a4a8227331362b88212>.
[17:16:54 CEST] <jkqxz> wm4:  New version with the modifier on the object rather than the plane <http://sprunge.us/dhXH>.
[17:25:52 CEST] <wm4> seen
[17:33:05 CEST] <cone-289> ffmpeg 03Paul B Mahol 07master:a23a56e77c0c: libavfilter/af_biquads: add shorter option for width_type
[17:51:44 CEST] <atomnuker> durandal_1707: sorry, I couldn't finish af_noisereduct today, will have to do it during the week
[17:52:32 CEST] <atomnuker> (got distracted by simd)
[18:14:30 CEST] <cone-289> ffmpeg 03Mark Thompson 07master:d984b29b21f6: vf_hwmap: Add missing error code
[18:14:31 CEST] <cone-289> ffmpeg 03Mark Thompson 07master:70808859ddf4: vf_hwmap: Properly free a locally derived device
[18:14:32 CEST] <cone-289> ffmpeg 03Mark Thompson 07master:f434ddf48e08: avconv_hw: Free device on initialisation failure
[18:35:19 CEST] <bofh_> atomnuker: got a copy of the SIMD (AVX?) fft5 that managed to be slower than the C?
[18:35:27 CEST] <bofh_> I am very curious, because what.
[18:35:58 CEST] <bofh_> (also, af_noisered? Ephraim-Malah noise suppression filter like the one in libspeexdsp?)
[18:41:41 CEST] <atomnuker> no, FFT based
[18:42:42 CEST] <atomnuker> also like I said its not slower itself, the asm code is almost 2x faster than C
[18:43:14 CEST] <atomnuker> but the non-simd code I haven't done fully yet is more than 2x slower than the non-simd code with the original C stuff
[18:43:55 CEST] <atomnuker> which slows the entire function down to 3/2 the speed of the C function
[18:44:38 CEST] <atomnuker> happens with both clang and gcc so have no idea what's going on
[19:32:02 CEST] <durandal_1707> atomnuker: how much lines have you wrote?
[20:03:39 CEST] <BBB> michaelni: about mpegvideo encoding, how does reconstruction work? I still dont get that. it seems to me that encode_mb is where block choices are made, and that actually calls decode_mb, but it also seems that decode_mb parses the bitstream which seems unnecessary, so how does this work?
[20:07:15 CEST] <michaelni> theres no bitstream parsing happening in the encoder
[20:09:56 CEST] <michaelni> the encoder only runs the commo parts that both encoder and decoder need
[20:10:23 CEST] <michaelni> these should be in ff_mpv_decode_mb() i think (the function was renamed in cleanup at some point)
[20:16:20 CEST] <BBB> aha
[20:16:22 CEST] <BBB> ok, that name is confusing
[20:16:24 CEST] <BBB> tnx
[20:16:25 CEST] <BBB> so...
[20:16:51 CEST] <BBB> I see this (between -idct simple and whatever the default is) is put_dct() for the keyframe:
[20:16:54 CEST] <BBB>  dequant
[20:16:55 CEST] <BBB> - 1342   0   0 -49   0  29   0   0
[20:16:56 CEST] <BBB> + 1342   0   0 -49   0   1   0   0
[20:17:04 CEST] <BBB> this is a de-permutated first line of s->block
[20:17:24 CEST] <BBB> so & does dct_unquantize_intra depend on idct_permutation in some undocumented way?
[20:17:36 CEST] <BBB> and could that screw with formats that have private scantables like wmv1?
[20:17:49 CEST] <BBB> (and that dont update quantization tables with the permutation table)
[20:18:02 CEST] <BBB> I believe this is the origin of the bug
[20:18:10 CEST] <BBB> (dont ask me why Im still looking at this, I dont know...)
[20:21:25 CEST] <BBB> ahaaaaaaaaaa
[20:21:27 CEST] <BBB> yes indeed
[20:21:31 CEST] <BBB> how utterly incredibly evil :D
[20:21:51 CEST] <BBB> and after that the bug goes away
[20:21:54 CEST] <BBB> hurray!
[20:23:02 CEST] <rkern> Did the host key for source.ffmpeg.org change?
[20:24:43 CEST] <BBB> rkern: about 3 months ago, yes
[20:25:48 CEST] <BBB> sorry, I cant find the email right now, but it was announced I believe
[20:27:19 CEST] <BBB> J_Darnley: kierank: https://pastebin.com/raarpqWR
[20:27:25 CEST] <BBB> J_Darnley: and thats the last Im doing on this ;)
[20:27:53 CEST] <BBB> its a little hacky but I really dont think we should care about crap like this
[20:28:02 CEST] <BBB> feel free to optimize in whatever way is appropriate
[20:28:30 CEST] <BBB> (the problem is that raster_end - to my knowledge - is not adjusted to the wmv1-specific scantables)
[20:28:40 CEST] <BBB> but Im not 100% sure
[20:33:38 CEST] <jamrial> rkern: https://mailman.videolan.org/pipermail/vlc-devel/2017-April/112787.html
[21:07:30 CEST] <cone-289> ffmpeg 03Paul B Mahol 07master:478a1949d920: avfilter/af_amix: fix possible hang
[21:14:06 CEST] <BBB> its also interesting how mpeg1/2 intra and inter unquantize use intra_scantable, and h263 intra/inter unquantize use inter_scantable
[21:14:15 CEST] <BBB> this is not obvious and I have no friggin clue what it means
[21:26:34 CEST] <atomnuker> durandal_1707: 360 lines, started from af_adelay
[21:27:17 CEST] <wm4> BBB: basically mpegvideo is still a nightmare
[21:27:19 CEST] <atomnuker> in hindsight, I should restart again from af_afftfilt
[21:31:21 CEST] <atomnuker> durandal_1707: af_afftfilt looks wrong
[21:31:54 CEST] <atomnuker> in the case that overlap is enabled
[21:32:06 CEST] <atomnuker> (e.g. the window function does overlap)
[21:33:33 CEST] <durandal_1707> huh?
[21:36:04 CEST] <atomnuker> nevermind, I thought the overlap was incorrectly calculated
[21:37:09 CEST] <atomnuker> also what's up with the avfft.c wrapper around fft.h?
[21:46:00 CEST] <atomnuker> huh, didn't know we exposed an FFT/MDCT through the public api, cool
[21:48:29 CEST] <atomnuker> yet stuff in libavcodec still uses the ff_mdct/fft functions, this needs cleanup, but got a million things to do first
[21:51:06 CEST] <kierank> BBB: <3
[21:51:24 CEST] <BBB> you owe me beer :-p
[21:52:02 CEST] <kierank> :)
[22:02:35 CEST] <wbs> does anybody have logs from thursday/friday they can share? I've been mentioned but my scrollback doesn't go far enough back
[22:05:28 CEST] <jamrial> wbs: https://ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-June/
[22:05:44 CEST] <wbs> jamrial: thanks
[22:05:58 CEST] <jamrial> and http://ffmpeg.gusari.org/irclogs/ for real time logs for the current day
[22:07:04 CEST] <jamrial> ah, also full archive, now that i look closely
[22:10:38 CEST] <BBB> wbs: it was probably me
[22:10:57 CEST] <BBB> someone claimed that loopfilter was not aarch64 optimized for vp9 and I thought ti was, so I pinged you to confirm :-p
[22:11:18 CEST] <BBB> but then it turned out to be a misunderstanding or so
[22:11:24 CEST] <BBB> sorry about that
[22:12:12 CEST] <atomnuker> I did test it on a raspberry pi 3, got 8 fps for 4 threads
[22:12:34 CEST] <BBB> is a raspberry pi any good?
[22:12:42 CEST] <BBB> (sounds like it isn't)
[22:12:44 CEST] <JEEB> just popular
[22:12:56 CEST] <atomnuker> its the worst money can buy, I hate it, its the most unreliable board I've ever used
[22:12:58 CEST] <JEEB> also I should really install something aarch64 onto my rpi3
[22:13:09 CEST] <atomnuker> JEEB: good. luck.
[22:13:12 CEST] <JEEB> :D
[22:13:15 CEST] <JEEB> inorite
[22:13:18 CEST] <atomnuker> archlinux has an aarch64 beta
[22:13:21 CEST] <atomnuker> did it run? yes
[22:13:31 CEST] <atomnuker> the one time I did manage to get it to run
[22:13:34 CEST] <JEEB> fedora supposed to do it but they don't seem to have published any images
[22:13:57 CEST] <atomnuker> they break the aarch64 image on a daily basis it seems so you really need to hit the date
[22:14:45 CEST] <atomnuker> also there's little functionality if you go with aarch64
[22:15:03 CEST] <atomnuker> since it only supports the unmodified kernel without any blobs
[22:15:23 CEST] <atomnuker> no wifi, bluetooth, audio, temperature sensor, current clockspeed
[22:15:53 CEST] <JEEB> yea
[22:16:13 CEST] <atomnuker> though because its archlinux rather than the most horrible outdated debian ever it'll run faster
[22:16:52 CEST] <JEEB> anyways, according to some people aarch64 was "work complete" in March https://github.com/raspberrypi/linux/issues/1915
[22:58:18 CEST] <wm4> atomnuker: you mean raspbian?
[22:59:44 CEST] <atomnuker> yep, the complete opposite of stable debian in every way
[23:00:00 CEST] <atomnuker> stable -> nope
[23:00:06 CEST] <atomnuker> outdated -> very outdated
[23:09:16 CEST] <TMM> I thought arch was pretty bleeding edge
[23:10:43 CEST] <nevcairiel> raspbian jessie seems to be generally OK for me, but i didnt really pay that much attention of how current it is, i only wanted a very basic system to run
[23:10:44 CEST] <atomnuker> well, not archlinux arm
[23:12:38 CEST] <atomnuker> the issue I think is there's no single way to boot multiple variants of boards, so distributions can't really make images to run on all these boards
[23:13:17 CEST] <atomnuker> even though uboot is present on all boards each needs specific boot instructions, e.g. offset to load the kernel at
[23:13:27 CEST] <JEEB> yup
[23:13:46 CEST] <JEEB> although in theory EFI ARM boards would make that simpler. those just happen to be enterprise only
[23:14:56 CEST] <BtbN> I'm fighting with UEFI PXE boot right now... not fun
[23:15:01 CEST] <atomnuker> yep, arm servers are definitely taking over the market steadily
[23:15:07 CEST] <atomnuker> ...not
[23:15:12 CEST] <wm4> too bad the world is too bad of a place as that they could just agree on some simple boot standard
[23:15:39 CEST] <BtbN> well, there is arm-efi and aarch64-efi
[23:15:46 CEST] <iive> atomnuker: if your rpi3 is defective, you should return it.
[23:15:48 CEST] <BtbN> They just decide not to use it
[23:15:56 CEST] <JEEB> yup
[23:16:08 CEST] <wm4> maybe it's too complex and fuckup and probably comes with license fees
[23:16:15 CEST] <wm4> *fucked up
[23:16:38 CEST] <JEEB> the APIs are windows-style which can e thought of as fucked up
[23:16:40 CEST] <iive> i remember linus complaining about EFI complexity....
[23:16:46 CEST] <atomnuker> iive: I have 2, one which I bought not a month ago, and I can't say I trust either
[23:16:47 CEST] <JEEB> but at least there's a reference implementation
[23:17:04 CEST] <JEEB> (which some makers just utilize it)
[23:17:53 CEST] <iive> atomnuker: what's the problem? hangs, reboots?
[23:19:36 CEST] <atomnuker> kernel panics when compiling anything heavy, downloading heavily and general packaging incompetence leading to non-bootable boards on upgrades
[23:20:19 CEST] <atomnuker> (did I mention the regular debian packaging team also maintains their own armhf and aarch64 package repos?)
[23:20:41 CEST] <nevcairiel> i havent had any such issues in multi-hour compile jobs, but admitedly i did put heatsinks on it
[23:20:58 CEST] <TMM> atomnuker, sorry, one more question :) I think I followed all of the patch submission guidelines for my last patch series but it appears nobody is replying to them. Do you think I did something wrong or am I just being impatient? I don't mind waiting but if it's being ignored because I'm an idiot I'd like to fix it :)
[23:21:36 CEST] <atomnuker> nevcairiel: oh and that too, the board is the least thermoconductive variant of fiberglass and makes each chip a hotspot
[23:22:13 CEST] <atomnuker> TMM: its the weekend, for some reason people here are less active during the weekend
[23:22:14 CEST] <nevcairiel> its a bit silly they dont just ship it with a tiny sink, this piece is tiny and totally solves such problems
[23:22:44 CEST] <iive> atomnuker: packaging is software problem. kernel panics.... might be hardware one
[23:22:58 CEST] <TMM> atomnuker, you'd think people have more time on their hands :) I'll just wait then. Thanks!
[23:23:00 CEST] <iive> atomnuker: do you have same problem with both boards?
[23:23:11 CEST] <atomnuker> who knows, that one is 2500km away and uplugged
[23:23:33 CEST] <atomnuker> haven't tried compiling ffmpeg on the new one, but it hasn't done that
[23:23:50 CEST] <atomnuker> I'm 99.9% sure it was packaging incompetence and an upgrade left the other one bricked
[23:24:23 CEST] <atomnuker> stupid fragile barely booting boards, this would never happen on an x86 machine
[23:24:51 CEST] <nevcairiel> how do you brick something where everything stateful is on the memory card you can just re-flash
[23:25:18 CEST] <atomnuker> well, its bricked until I can get to it, its 2500km away
[23:37:32 CEST] <TMM> atomnuker, that sucks. We ship some payment systems based off of rpis. They do die a lot all by themselves :-/ We got the most ridiculously expensive sd cards for them now and that helps a little, but they do die rather often.
[23:37:56 CEST] <JEEB> yea, they just got popular
[23:38:04 CEST] <TMM> atomnuker, even the PIs themselves just crap out.RPI1 seems the most stable, but we can't source them anymore :-/
[23:38:24 CEST] <nevcairiel> pi1 is so ridicoulously slow tho
[23:38:28 CEST] <JEEB> some goodwill and looking good to the public goes a long way
[23:38:32 CEST] <BtbN> I configured all my "productive" RPis to reboot every night
[23:38:41 CEST] <BtbN> from my experience they get unstable the longer the uptime
[23:39:09 CEST] <TMM> nevcairiel, the payment system was originally built for the rpi1, we have a super stripped down openwrt based os for it and the system itself is written entirely in C. It runs fine on an underclocked rpi1 even :)
[23:39:35 CEST] <TMM> underclocking the rpi2 helps a little, but now we can't get those either... 
[23:39:53 CEST] <TMM> so now I'm porting to rpi3, I'm anticipating even more shit
[23:41:07 CEST] <BtbN> The moment I put my current SD card into the Pi3, my PC couldn't read it anymore
[23:41:10 CEST] <BtbN> returns weird MMC errors
[23:41:11 CEST] <atomnuker> rfkill and unload all unnecessary modules you don't need
[23:41:20 CEST] <BtbN> but works perfectly fine in the Pi itself, and in an external USB reader
[23:42:09 CEST] <nevcairiel> i've had weird sd card problems as well, only worked properly if i used the tiny netinstall noobs image and properly re-formatted the SD from within the rpi
[23:42:45 CEST] <BtbN> The card works fine for me
[23:42:47 CEST] <TMM> yeah, rpis and SD cards are really weird
[23:42:56 CEST] <BtbN> just not in the internal SD card reader on my laptop
[23:43:23 CEST] <TMM> I have a whole box of sd cards that will either no longer read anywhere, not read in a pi but will read in a pc, or won't read in a pc but will read in a pi
[23:44:01 CEST] <nevcairiel> i have my main data on a usb drive connected to the pi, but booting from usb is still very wonky
[23:44:08 CEST] <TMM> I wonder if the problem is the pi or just that sd cards ain general are crap
[23:44:42 CEST] <TMM> the really expensive ones we use now at least when they die they won't read anywhere anymore :P
[23:44:49 CEST] <TMM> and it takes longer for that to happen
[23:45:55 CEST] <atomnuker> they sell atom-based rpi-sized x86 machines now
[23:46:17 CEST] <atomnuker> unfortunately even though they come from china they're extremely expensive for what they are
[23:46:23 CEST] <TMM> atomnuker, do they have the same gpio? We have custom hardware that plugs into it
[23:46:32 CEST] <atomnuker> yep, they do
[23:46:40 CEST] <nevcairiel> intel has a credit-card sized x86 systems
[23:46:47 CEST] <atomnuker> but they're 10x the price and don't come with ram, you have to buy your own
[23:46:48 CEST] <JEEB> atomnuker: also the intel edison has 100KiB+ kernel patches
[23:47:31 CEST] <atomnuker> JEEB: that's like a million lines, have they been merged/looking to be merged?
[23:47:55 CEST] <JEEB> some stuff have been half-merged but mostly it means that a lot of edisons are still running 3.10 or so
[23:48:03 CEST] <TMM> that's pretty crap then
[23:48:11 CEST] <JEEB> IIRC intel started looking into improving that but I never looked into it again
[23:48:12 CEST] <TMM> I was thinking of trying the banana pis
[23:48:56 CEST] <JEEB> atomnuker: I think the best part of the edison patch was that it was jenkins-squashed
[23:48:59 CEST] <JEEB> so you had no idea what changes went in together
[23:50:10 CEST] <JEEB> 01org/edison-linux goes up to 3.19
[23:50:21 CEST] <atomnuker> oh wow, even worse than the odroid c2s
[23:50:29 CEST] <JEEB> then it seems like some andy-shev is doing something with newer kernels
[23:50:34 CEST] <JEEB> https://github.com/andy-shev/linux/tree/eds
[23:50:55 CEST] <atomnuker> also maybe I'm being paranoid but the thing on the picture looks very much like it doesn't have a bios
[23:51:06 CEST] <atomnuker> so you can't plug a usb flash and install debian
[23:51:25 CEST] <JEEB> edison? you can flash the reference UEFI implementation on it
[23:51:31 CEST] <atomnuker> ...
[23:51:38 CEST] <JEEB> and it will actually work
[23:51:45 CEST] <JEEB> I think that's what it comes with out of the box
[23:51:50 CEST] <cone-289> ffmpeg 03Marton Balint 07master:7ed6f9168b7f: fate: use do_md5sum instead of the md5 protocol for most md5 fate tests
[23:52:09 CEST] <JEEB> so yea, in that sense I've only booted it with UEFI
[23:52:17 CEST] <JEEB> and that should work with 32bit debian as well I guess
[23:52:25 CEST] <JEEB> I think it might support 64bit as well but I never tested
[23:53:35 CEST] <JEEB> but yea, just because of the long long kernel patch set I just kind of meh'd at the edison
[23:53:43 CEST] <JEEB> even if by its size and being x86 it looks promising
[23:53:58 CEST] <JEEB> it is fucking expensive also compared to the ARM stuff
[23:54:17 CEST] <BtbN> The edison was discontinued anyway, or was it the only survivor?
[23:54:33 CEST] <JEEB> no idea, I bought one in early 2015 because I happened to be working with them
[23:54:40 CEST] <JEEB> and never touched it after having some random code run on its GPIO
[23:55:02 CEST] Action: JEEB even has a whole "IoT set" for it with sensors etc
[00:00:00 CEST] --- Mon Jun 19 2017