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

[burek]

[00:00:19 CEST] <TMM> hi all!
[00:00:29 CEST] <BBB> hey
[00:00:31 CEST] <TMM> I've gotten somewhere with my implementation of those interplay codecs
[00:01:07 CEST] <TMM> I need to be able to copy an 8x8 block of pixels from the previous frame to the current frame with an offset that I have in bytes only. The helper functions I've found so far don't seem particularly helpful
[00:01:27 CEST] <TMM> the code in question in my naive player does this : pixeldata = video_buffer_prev + (out - video_buffer_cur) + (unsigned short)op - 0xC000;
[00:02:03 CEST] <TMM> so, the current offset in the current frame, on the previous frame, minus an offset (in pixels)
[00:02:22 CEST] <TMM> am I allowed to just memcpy from s->last_frame?
[00:03:38 CEST] <kierank> there are motion compensation (mc) functions to do this but to get the codec to work you should just memcpy for now
[00:03:41 CEST] <kierank> and then fix later imo
[00:04:49 CEST] <BBB> use the emulated edge mc functions instead of memcpy
[00:04:55 CEST] <BBB> else youll get issues if mv points out of frame
[00:04:57 CEST] <TMM> Is there documentation on those?
[00:05:21 CEST] <BBB> https://www.ffmpeg.org/doxygen/2.0/structVideoDSPContext.html#aa0c5b1dc31b9661800d1b4b2b744aef9
[00:06:16 CEST] <TMM> ok, so I have to convert this offset to an x,y position?
[00:06:43 CEST] <BBB> yes
[00:06:58 CEST] <BBB> block_w/h is 8 for you
[00:07:29 CEST] <TMM> are there helpers for that too? or just divide by linewidth and take the remaineder for x?
[00:07:29 CEST] <BBB> src_x/y is the current block offset x/y minus motion vector
[00:07:36 CEST] <BBB> or plus motion vector
[00:07:39 CEST] <BBB> yeah that works
[00:07:54 CEST] <BBB> and w/h is the size of the reference frame (typically also size of this frame)
[00:09:00 CEST] <TMM> do I need to create one of those VideoDSPContexts?
[00:09:47 CEST] <durandal_1707> i believe interplay doesnt use those
[00:12:49 CEST] <TMM> it seems to have a copy_from() function, I'm seeing it it'll work for this
[00:17:06 CEST] <TMM> I thought that did something else :)
[00:17:29 CEST] <TMM> it talkes about motion compensation too, I figured it was something else
[00:19:21 CEST] <BBB> J_Darnley: Ill re-look at wmv1 later, Im tired :(
[00:19:52 CEST] <J_Darnley> that's fine
[00:20:03 CEST] <BBB> J_Darnley: I suspect something with table permutation again, but I dont have the energy to look anymore
[00:20:10 CEST] <BBB> this is the last one, right?
[00:20:50 CEST] <J_Darnley> there was fate-mdec-v3 bt that's probably just a subset
[00:21:02 CEST] <TMM> it seems that this copy_from function takes an x,y as well, but it is based on an offset off of the current position
[00:21:05 CEST] <J_Darnley> let me check that with your patch
[00:21:26 CEST] <TMM> my math seems to be failing me as how to go from a byte offset to an x,y offset, I guess just the same?
[00:24:56 CEST] <BBB> yes
[00:25:06 CEST] <BBB> again, divided by linesize
[00:33:16 CEST] <J_Darnley> BBB: yes that looks like mdec and mdec-v3 taken care of
[00:33:22 CEST] <BBB> woohoo
[00:33:28 CEST] <BBB> oh wait I was gonna rest
[00:33:49 CEST] <J_Darnley> Yes you were, please do
[00:35:59 CEST] <philipl> jkqxz: https://wiki.ubuntu.com/IntelQuickSyncVideo This seems inaccurate, and is, i think, an active document for them.
[00:36:15 CEST] <philipl> jkqxz: Seems worth correcting, in some way.
[00:37:16 CEST] <TMM> I got it mostly working! :D
[00:37:29 CEST] <TMM> I get some artifacts now I don't get with my own implementation
[00:37:40 CEST] <TMM> but it's pretty close, so small fixes I hope...
[00:44:10 CEST] <TMM> Also ffplay isn't exiting on my codec :)
[00:59:55 CEST] <TMM> well, this can now mostly play interplay 0x06 videos: https://github.com/hpvb/FFmpeg/tree/interplay-mve
[01:00:31 CEST] <TMM> There are more artifacts than in my player, it seems that frame flipping works a little different in ffmpeg than just the straight 'stupid' flipping I did on my own player
[01:03:04 CEST] <TMM> some blocks stay black in some frames, that shouldn't be possible
[01:04:14 CEST] <jkqxz> philipl:  Why am I reading this?  Sounds like it's written by some random individual bitter about their own incompetence.
[01:05:52 CEST] <philipl> jkqxz: https://insights.ubuntu.com/2017/06/16/ubuntu-desktop-weekly-update-june-16-2017/
[01:06:12 CEST] <philipl> That's an official ubuntu progress update calling that page an official description of where they think they are.
[01:06:17 CEST] <philipl> I was terrified when I read it.
[01:07:19 CEST] <jkqxz> Are they actually trying to troll Intel?
[01:07:45 CEST] <philipl> troll by way of incompetence?
[01:07:53 CEST] <philipl> "We trained him wrong, as a joke"
[01:09:53 CEST] <jkqxz> No, I mean "we don't want to bother doing anything ourselves, please make everything work perfectly for us or we will keep saying how terrible intel is and how nothing works at all".
[01:10:35 CEST] <TMM> oh, ffplay doesn't stop on any mve movie it seems, looks like there's another bug to fix there, wasn't my hacking :)
[01:11:36 CEST] <philipl> jkqxz: That is true. But they're also saying negative things about where ffmpeg is in all this. I suppose it's not surprising.
[01:15:53 CEST] <llogan> that wiki article was writting by a single user
[01:16:11 CEST] <jkqxz> Tbh I'm not very interested in trying to correct that sort of thing.  Idiots say stupid things about free software all the time, and trying to correct them will drag you into trying to fix everything they've broken while they abuse you.
[01:16:40 CEST] <philipl> llogan: a single user who works at Canonical.
[01:16:59 CEST] <philipl> so it describes what they are doing (or not doing) and how they think things work.
[01:17:02 CEST] <philipl> sad panda.
[01:18:46 CEST] <philipl> jkqxz: I don't blame you, but wanted to point it out.
[01:18:46 CEST] <jkqxz> I know it all works, as do a load of ffmpeg and mpv users.
[01:20:12 CEST] <philipl> As do I. I'm one of those happy users.
[01:34:45 CEST] <wm4> lol at that ubuntu stuff
[01:35:17 CEST] <wm4> if I understand this right, they're basically complaining that ffmpeg+vaapi needs too much custom glue? of course that's solved with the newer hwaccel support
[01:35:33 CEST] <wm4> but still, gstreamer implemented similar things for ages???
[01:35:48 CEST] <wm4> and this is somehow about totem, which uses gstreamer
[01:35:51 CEST] <wm4> so, whatever
[01:39:18 CEST] <philipl> wm4: It's a disaster. The only thing Totem has ever done for me is crash.
[01:41:43 CEST] <BBB> what ubuntu thing?
[01:41:46 CEST] <BBB> I wanna read!
[01:46:00 CEST] <philipl> scroll up.
[01:46:08 CEST] <philipl> Your brain will hurt.
[01:47:14 CEST] <BBB> I saw https://insights.ubuntu.com/2017/06/16/ubuntu-desktop-weekly-update-june-16-2017/
[01:47:16 CEST] <BBB> that one?
[01:47:29 CEST] <philipl> https://wiki.ubuntu.com/IntelQuickSyncVideo specifically
[01:47:45 CEST] <BBB> ooo that one
[01:47:49 CEST] <BBB> this will be fun
[01:48:07 CEST] <wm4> hm maybe this could be explained by Intel somehow trying to get Ubuntu to license their SDK?
[01:48:17 CEST] <wm4> (don't know if there's such a thing)
[01:49:46 CEST] <philipl> wm4: I'd almost consider that preferable. It reads like terrible terrible cluelessness to me.
[02:10:50 CEST] <BBB> so heres one thing to keep in mind
[02:11:15 CEST] <BBB> Im mostly concerned about the reputation damage they could do to ffmpeg, I dont care so much about hwaccel or intel :-p
[02:11:39 CEST] <BBB> most people in the graphical opensource community consider ffmpeg a piece of crap
[02:11:49 CEST] <BBB> and theyll do anything in their limited understanding to just make it fit that image
[02:15:00 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07master:9b65dbf7349a: avcodec/gdv: Fix undefined shift
[02:15:00 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07master:1edbf5e20c75: avcodec/hevcdec: Fix signed integer overflow in decode_lt_rps()
[02:23:48 CEST] <wm4> they might be right, but it's still going to be less crap than most opensource GUI stuff (and now I made everyone my enemy trollol)
[03:51:10 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a9bb748cee2b: avcodec/hq_hqa: Fix: runtime error: signed integer overflow: -255 * 10180917 cannot be represented in type 'int'
[03:51:11 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b4bb262b485f: avcodec/takdec: Fix  runtime error: left shift of negative value -42
[03:51:12 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e74ec432932a: avcodec/mlpdec: Fix runtime error: left shift of negative value -1
[03:51:13 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:3814f965aa07: avcodec/flicvideo: Check frame_size before decrementing
[03:51:14 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f66f1c523258: avcodec/aacdec_template: Fix fixed point scale in decode_cce()
[03:51:15 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:dd01941b9a74: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int'
[03:51:16 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:70247373a1c7: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int'
[03:51:17 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6ee9d6e32fe4: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[03:51:18 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:4f40dac0afa7: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int'
[03:51:19 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:bc133fe409fe: avcodec/mimic: Use ff_set_dimensions() to set the dimensions
[03:51:20 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:0ff8f9b8e000: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int'
[03:51:21 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1d52ed4da8b5: avcodec/mlpdec: Do not leave a invalid num_primitive_matrices in the context
[03:51:22 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f5212833b2e2: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 170 is too large for 32-bit type 'int'
[03:51:23 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:90ff230fd18e: avcodec/sbrdsp_fixed: fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[03:51:24 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e1e7b75cbf8b: avcodec/mlpdsp: Fix runtime error: signed integer overflow: -24419392 * 128 cannot be represented in type 'int'
[03:51:25 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:20363bef602d: avcodec/takdec: Fix runtime error: left shift of negative value -63
[03:51:26 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:bc95cd148017: avcodec/aac_defines: Fix: runtime error: left shift of negative value -2
[03:51:27 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:228b1e3f40a3: avcodec/takdec: Fix runtime error: signed integer overflow: 8192 * 524308 cannot be represented in type 'int'
[03:51:28 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:eed9fc2f61a3: avcodec/vmnc: Check location before use
[03:51:29 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:510f968849c4: avcodec/mpeg4videodec: Check for multiple VOL headers
[03:51:30 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:43db1288dd9a: avcodec/aacdec_fixed: Fix runtime error: shift exponent 34 is too large for 32-bit type 'int'
[03:51:31 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a7f35b7f358b: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -32767 * 130560 cannot be represented in type 'int'
[03:51:32 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:3b0f0dab4aed: avcodec/ivi_dsp: Fix multiple runtime error: left shift of negative value -71
[03:51:33 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:8d7ccdf873ad: avcodec/jpeglsdec: Check get_bits_left() before decoding a picture
[03:51:34 CEST] <cone-785> ffmpeg 03Max Justicz 07release/3.2:66aa3c61fe89: avcodec/sanm: Fix uninitialized reference frames
[03:51:35 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6b1a01f3ec84: avcodec/jpeg2000dec: Check tile offsets
[03:51:36 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:fdba18c0683b: avcodec/jpeg2000dec: Fix copy and paste error
[03:51:37 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:8cbe7461b364: avcodec/diracdec: Fix off by 1 error in quant check
[03:51:38 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:c41902278903: avcodec/smc: Check remaining input
[03:51:39 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:7072201271d3: avcodec/aacdec_fixed: Fix runtime error: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int'
[03:51:40 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:af71771a6ce3: avutil/internal: Do not enable CHECKED with DEBUG
[03:51:41 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:9b27474cdfd8: avformat/mux: Fix copy an paste typo
[03:51:42 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:288eb8b17ef5: avcodec/ra144dec: Fix runtime error: left shift of negative value -17
[03:51:43 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1e74ee34f978: avcodec/mlpdec: Do not leave invalid values in matrix_out_ch[] on error
[03:51:44 CEST] <cone-785> ffmpeg 03Kevin Mark 07release/3.2:706bbb22b1b3: doc/filters: Clarify scale2ref example
[03:51:45 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6eb1a6f48b17: avcodec/ivi_dsp: Fix runtime error: left shift of negative value -2
[03:51:46 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e7776cedf586: avcodec/sbrdsp_template: Fix: runtime error: signed integer overflow: 849815297 + 1315389781 cannot be represented in type 'int'
[03:51:47 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e18bd51596b7: avcodec/libfdk-aacdec: Correct buffer_size parameter
[03:51:48 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:7108189a54f3: avcodec/wnv1: More strict buffer size check
[03:51:49 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b1da01c05169: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int'
[03:51:50 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f5839a782669: avcodec/sheervideo: Check input buffer size before allocating and decoding
[03:51:51 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f720b436152a: avcodec/jpeg2000dec: Check tile offsets more completely
[03:51:52 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:ee202d98ce18: avcodec/jpeg2000: Fix runtime error: signed integer overflow: 4185 + 2147483394 cannot be represented in type 'int'
[03:51:53 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:2b220944e98a: avcodec/snow: Fix runtime error: signed integer overflow: 1086573993 + 1086573994 cannot be represented in type 'int'
[03:51:54 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b08f7e592f89: avcodec/ylc: Check count in build_vlc()
[03:51:55 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a871e42e30c3: avcodec/aacdec_fixed: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[03:51:56 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:66c9e5e3eb43: avcodec/webp: Fixes null pointer dereference
[03:51:57 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1b048028a71d: avcodec/aac_defines: Add missing () to AAC_HALF_SUM() macro
[03:51:58 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:efe4dbb6e650: avcodec/ra144: Fix runtime error: signed integer overflow: 11184810 * 404 cannot be represented in type 'int'
[03:51:59 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:5b6d056da8a1: avcodec/ra144: Fix runtime error: signed integer overflow: -2449 * 1398101 cannot be represented in type 'int'
[03:52:00 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:362a98eea9b8: avcodec/truemotion2: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[03:52:01 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:ba925988efe7: avcodec/truemotion2: Fix passing null pointer to memset()
[03:52:02 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1d4199e02311: avcodec/jpeg2000dec: Use ff_set_dimensions()
[03:52:03 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:9f8da7e2aa62: avcodec/dds: Fix runtime error: left shift of 145 by 24 places cannot be represented in type 'int'
[03:52:04 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:df7f051f4dbf: avcodec/ansi: Fix frame memleak
[03:52:05 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b424fde5decd: avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int'
[03:52:06 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:d5f5d2132277: avcodec/wavpack: Check float_shift
[03:52:07 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:625fb0895980: avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float'
[03:52:08 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:5415c88e3706: avformat/avidec: Limit formats in gab2 to srt and ass/ssa
[03:52:09 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:79a5cac07754: avcodec/cavsdec: Fix runtime error: signed integer overflow: 59 + 2147483600 cannot be represented in type 'int'
[03:52:10 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:ccc598dbcb79: avcodec/pnm: Use ff_set_dimensions()
[03:52:11 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:cb14b289bc99: avcodec/ra144: Fixes runtime error: signed integer overflow: 7160 * 327138 cannot be represented in type 'int'
[03:52:12 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:64ecc9eda976: avcodec/hevc_ps: Fix runtime error: signed integer overflow: 2147483628 + 256 cannot be represented in type 'int'
[03:52:13 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1d6983c89907: avcodec/cinepak: Check input packet size before frame reallocation
[03:52:14 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:fe2a92cfd43d: avcodec/wavpack: Fix runtime error: signed integer overflow: 2013265955 - -134217694 cannot be represented in type 'int'
[03:52:15 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a8643da03a98: avcodec/cfhd: Fix runtime error: signed integer overflow: 65280 * 65288 cannot be represented in type 'int'
[03:52:16 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b7afa9f8aad0: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[03:52:17 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6a44539bc800: avcodec/aacps: Fix runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'INTFLOAT' (aka 'int')
[03:52:18 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:858adb27a0c9: avformat/options: log filename on open
[03:52:19 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:7edf95874053: avcodec/ac3dec_fixed: Fix runtime error: left shift of 419 by 23 places cannot be represented in type 'int'
[03:52:20 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:90c38d6ab8df: avcodec/pafvideo: Check packet size and frame code before ff_reget_buffer()
[03:52:21 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:439757d38a6a: avcodec/dxv: Check remaining bytes in dxv_decompress_raw()
[03:52:22 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:5c2c0979e243: avcodec/hevc_ps: Fix runtime error: index 32 out of bounds for type 'uint8_t [32]'
[03:52:23 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:25b7dc959a08: avutil/softfloat: Fix sign error in and improve documentation of av_int2sf()
[03:52:24 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:5c82f67012c3: avcodec/qdrw: Fix null pointer dereference
[03:52:25 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:25dac3128b60: avformat/hls: Check local file extensions
[03:52:26 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:fb0d1cafab1d: avcodec/cavs: Fix runtime error: signed integer overflow: -12648062 * 256 cannot be represented in type 'int'
[03:52:27 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:260a286e5308: avcodec/tiff: Avoid loosing allocated geotag values
[03:52:28 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:873397e27e97: avcodec/mjpegdec: Check that reference frame matches the current frame
[03:52:29 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f865aa6beeb4: avcodec/takdec: Fix multiple runtime error: signed integer overflow: 637072 * 4096 cannot be represented in type 'int'
[03:52:30 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:fe5b764e6aa9: avcodec/pafvideo: Fix assertion failure
[03:52:31 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:d5284145680f: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 53098 * 40448 cannot be represented in type 'int'
[03:52:32 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f7ea74422f25: avcodec/ac3dec_fixed: Fix multiple runtime error: signed integer overflow: -39271008 * 59 cannot be represented in type 'int'
[03:52:33 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e93ffb488844: avcodec/indeo4: Check remaining data in Pic hdr extension parsing code
[03:52:34 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e5714e4ccbc9: avcodec/h264_parse: Check picture structure when initializig weight table
[03:52:35 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1f1b73cb1666: avcodec/cfhd: Check band parameters before storing them
[03:52:36 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:ef157cec8130: avcodec/flicvideo: Fix runtime error: signed integer overflow: 4864 * 459296 cannot be represented in type 'int'
[03:52:37 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:9a8419541f2b: avcodec/ra144: Fix runtime error: signed integer overflow: -2200 * 1033073 cannot be represented in type 'int'
[03:52:38 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:722cbfc5e163: avcodec/tiff: Fix leak of geotags[].val
[03:52:39 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1df854736646: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1297616
[03:52:40 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:753d04b618e7: avcodec/snowdec: Fix runtime error: left shift of negative value -1
[03:52:41 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:266ecedc75f2: avcodec/wavpack: Fix runtime error: signed integer overflow: 1886191616 + 277872640 cannot be represented in type 'int'
[03:52:42 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:61bf10368c2b: avcodec/jpeg2000dwt: Fix runtime error: left shift of negative value -123
[03:52:43 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:22a6713ce9e1: avcodec/libvpxdec: Check that display dimensions fit in the storage dimensions
[03:52:44 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:15a408f1822f: avcodec/sbrdsp_fixed: Return an error from sbr_hf_apply_noise() if operations are impossible
[03:52:45 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:c1e2c1e84e3a: avcodec/aacsbr_fixed: Check shift in sbr_hf_assemble()
[03:52:46 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:46acaabd2a13: avcodec/mpeg4videodec: Fix integer overflow in num_sprite_warping_points=2 case
[03:52:47 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:3c6aa2e0d12f: avcodec/mpeg4videodec: Check sprite delta upshift against overflowing.
[03:52:48 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:81527019b1d1: avcodec/hevc_refs: Check nb_refs in add_candidate_ref()
[03:52:49 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6d77a3ff3cd8: avcodec/hevcdec: Check nb_sps
[03:52:50 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:31c1c0b46a70: avcodec/dnxhd_parser: Do not return invalid value from dnxhd_find_frame_end() on error
[03:52:51 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:d09ec6c27f85: avcodec/jpeg2000: Fixes integer overflow in ff_jpeg2000_ceildivpow2()
[03:52:52 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:39d9308b992a: avcodec/truemotion2: Move skip computation after checks
[03:52:53 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:12cf6ace44f6: avcodec/shorten: Sanity check maxnlpc
[03:52:54 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:c00ef60abda2: avcodec/jpeg2000dec: Check nonzerobits more completely
[03:52:55 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a2055f8e3f14: avcodec/hevcdec: Fix signed integer overflow in decode_lt_rps()
[03:52:56 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1a54f239ad00: Update for 3.2.6
[04:13:01 CEST] <atomnuker> 999 decicycles in fft5_c, 4193700 runs,    604 skips  vs   838 decicycles in fft5_avx, 4193746 runs,    558 skips
[04:13:20 CEST] <atomnuker> just being faster than C is an accomplishment
[04:14:10 CEST] <atomnuker> moreover I use 5 shufps one or two of which are redundant
[04:15:19 CEST] <atomnuker> (also its really meant to be a macro which gets put inside the 15-point fft rather than a function)
[04:37:10 CEST] <atomnuker> here's the code if someone wants to see it: https://pars.ee/temp/mdct15_v1.txt
[04:40:23 CEST] <jamrial> atomnuker: use xorps with constants using INT32_MIN instead of -1.0
[04:42:53 CEST] <jamrial> and instead of pand/por (which btw are integer instructions, not float) with those masks, just use shufps
[04:45:49 CEST] <jamrial> vfmsubadd123ps is fma3, not avx. also use "fmsubadd dst, src1, src2, src3" instead
[04:58:11 CEST] <atomnuker> what difference does it make when using integer instructions on floats?
[05:01:48 CEST] <rcombs> using integer instructions and then using float instructions involves some sort of internal context switch
[05:02:05 CEST] <rcombs> I dunno exactly how it works but it's slow
[05:02:32 CEST] <rcombs> something something pipeline something
[05:03:25 CEST] <rcombs> it's why there are floating-point and integer versions of what look like they should be type-agnostic instructions, like xorps, movaps, etc
[05:04:40 CEST] <atomnuker> I should probably be using the float unpack too
[05:05:48 CEST] <rcombs> the floating-point instructions have the disadvantage of running on fewer ports than the integer ones, though
[05:06:17 CEST] <rcombs> and the bypass-delay penalty is generally pretty small
[05:07:01 CEST] <rcombs> so if you've got a bunch of operations to do that have both float and integer variants, and they could be parallelized, you probably want the int versions
[05:07:26 CEST] <rcombs> but otherwise, try to stick to the same type for everything
[05:07:38 CEST] <rcombs> jamrial almost certainly can explain this better than I can
[05:22:09 CEST] <atomnuker> its certainly a bit faster though (a few tens of decicycles)
[05:23:32 CEST] <atomnuker> crap its 4:23 and its already practically day outside
[05:24:07 CEST] <atomnuker> (its still light enough to read a book outside at 3:45 what's the point of going to sleep anyway?)
[09:39:24 CEST] <LongChair> jkqxz: you around  ? :)
[11:29:53 CEST] <TMM> does ffplay have a feature to start off paused on the first frame?
[11:30:03 CEST] <TMM> I need to do some debugging and that'd be really helpful
[11:33:01 CEST] <ubitux> try to is->paused = 1 before the call to event_loop()? 
[11:36:57 CEST] <TMM> ok! I thought perhaps ffplay had a feature for it
[11:37:29 CEST] <ubitux> can't see any afaict
[11:37:41 CEST] <ubitux> if the hack work you may want to submit a patch
[11:37:45 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vHhUV
[11:37:45 CEST] <KGB> 13FFV1/06master 14330ccde 15Dave Rice: extend intro and add summary of version history...
[11:37:45 CEST] <TMM> you tried with CAPT.MVE?
[11:38:08 CEST] <ubitux> i don't know what CAPT.MVE is
[11:38:23 CEST] <TMM> oh, sorry, the artifacts I see are only on the new codec I'm implementing
[11:38:27 CEST] <TMM> I thought perhaps you tried my code
[11:38:35 CEST] <ubitux> sorry, no :)
[11:43:09 CEST] <TMM> I still have one frame that's broken, it's weird
[11:43:17 CEST] <TMM> in my own player that frame doesn't appear at all
[11:43:40 CEST] <TMM> I don't suppose ffplay will ever show a frame that was 'half done' or something, if my codec didn't do something wrong?
[11:45:56 CEST] <TMM> (my own player uses no ffmpeg code, and does super 'dumb' frame flipping, just 2 buffers that get flipped, drawing of the next frame continues on the data already there from the second last frame)
[11:54:23 CEST] <jkqxz> LongChair:  Yes.  (Generally it's easier to just assume I'll always see things eventually if you write here.)
[12:06:42 CEST] <LongChair> ok cool :)
[12:07:01 CEST] <LongChair> jkqxz: not sure if you saw the links i posted in PM
[12:07:16 CEST] <LongChair> i have tried to adjust my MPP stuff to your sample 
[12:07:24 CEST] <LongChair> but i have a few more questions
[12:07:46 CEST] <LongChair> i'm not sure where AVDRMDeviceContext and AVDRMFramesContext should be created
[12:11:18 CEST] <jkqxz> Did you have any thoughts on the question above about associating DRM formats with planes?
[12:12:32 CEST] <jkqxz> After some thought I think it goes with each plane, rather than global (v1) or per-object (v2).  That is in order to fit with the EGL import use.
[12:13:06 CEST] <LongChair> hmmm
[12:13:28 CEST] <jkqxz> So, DRM_FORMAT_NV12 wouldn't be used at all in the desktop cases - it would be an R8 plane and an RG88 plane, in one object or two.
[12:13:50 CEST] <LongChair> So we'd need to have an array for formats i guess
[12:13:53 CEST] <jkqxz> It would only be used if the platform actually has magic multiple-plane things which are supported in single calls (as Rockchip appears to).
[12:14:02 CEST] <jkqxz> It would go in the planes object.
[12:14:10 CEST] <LongChair> well rockchip mainly uses NV12
[12:14:16 CEST] <jkqxz> (I haven't updated anything after the second version yet.)
[12:14:55 CEST] <LongChair> i have pushed some of you code (aside the vaapi specifics) and update my code to use that 
[12:15:27 CEST] <LongChair> see the last commits here : https://github.com/LongChair/FFmpeg/commits/rockchip
[12:15:37 CEST] <jkqxz> Yeah, ignore the VAAPI stuff in your code, that's just testing what is wanted elsewhere.
[12:16:03 CEST] <jkqxz> You didn't see the second version above?
[12:16:18 CEST] <LongChair> i don't think so 
[12:16:31 CEST] <LongChair> maybe i was psoted before i connected from home 
[12:16:38 CEST] <LongChair> can you share the link again N 
[12:16:38 CEST] <jkqxz> <http://sprunge.us/fVaM>
[12:17:18 CEST] <jkqxz> I think the DRM format bit needs to move from objects to planes.
[12:18:23 CEST] <LongChair> hmmm
[12:18:43 CEST] <LongChair> possibly 
[12:19:07 CEST] <LongChair> and the format-Modifier ? 
[12:19:42 CEST] <LongChair> i need to get a quick lunch bb in 30 mins or so :) i'd like to move one this conversation :)
[12:19:51 CEST] <jkqxz> Probably the same?  Though objects are likely tiled completely, so don't know.
[12:21:26 CEST] <jkqxz> I don't know what other format modifiers there might be - only ones doing tiling things currently exist (<https://cgit.freedesktop.org/mesa/drm/tree/include/drm/drm_fourcc.h#n165>).
[12:26:30 CEST] <jkqxz> Does the EGL import for Rockchip actually require the second plane of the NV12 image?  I wonder whether it's just ignored - that would match the normal EGL use in mpv.
[12:27:05 CEST] <jkqxz> (That is, you give it one "plane" which is DRM_FORMAT_NV12, and that becomes the object.)
[12:42:31 CEST] <TMM> it appears that this codec keeps three buffers, one of the buffers being the current display buffer, it only seems to copy blocks changed from the previous buffers over, which it has to keep it appears
[12:42:37 CEST] <TMM> I'm so confused as to how to do this properly
[12:43:18 CEST] <TMM> it copies the changed blocks over, but it still expects to have access to the previous data on that frame that *doesn't* contain these changed blocks 2 frames later
[12:43:41 CEST] <TMM> I feel I'm missing something really fundamental here, but I just don't understand what
[12:45:19 CEST] <TMM> what I mean is that it appears to want to copy blocks from the second last frame, but that is not the frame actually displayed but the frame decoded to
[12:46:32 CEST] <TMM> in my own player I solved this by having the two buffers to decode to, and then for the display buffer I'd only copy changed blocks
[12:46:50 CEST] <TMM> but I'm not sure how to do this in ffmpeg, or if this is even really what I should be doing
[12:47:02 CEST] <LongChair> jkqxz: back
[12:48:06 CEST] <TMM> I think it expects to be able to copy a block from before the last time it was changed, not from the previous frame(s)
[12:48:29 CEST] <LongChair> jkqxz: well for EGL and NV12, the dmabuf import will use like 2 planes
[12:48:55 CEST] <LongChair> they have same fd but different offset / pitches
[12:49:07 CEST] <LongChair> https://github.com/LongChair/mpv/blob/rockchip/video/out/opengl/hwdec_drmprime_egl.c#L162-L215
[12:50:37 CEST] <LongChair> you have a set of fds / offsets / pitches to set ... those are interpreted by the gpu driver depending on the DRM FORMAT 
[12:50:45 CEST] <jkqxz> Yes, I mean: in that code, does it still work if you don't bother to supply the second plane?
[12:50:59 CEST] <TMM> I guess I'll just have to allocate two more frames and just keep rotating them like in my original player?
[12:51:26 CEST] <TMM> and do the final copy to the display frame separately
[12:51:35 CEST] <LongChair> jkqxz: for EGL and dmabuf import there is no way to provide several formats 
[12:51:53 CEST] <LongChair> there is only one EGL_LINUX_DRM_FOURCC_EXT 
[12:52:26 CEST] <jkqxz> That's why I'm asking the question.
[12:52:31 CEST] <LongChair> and several EGL_DMA_BUF_PLANE<X>_FD_EXT ... 
[12:52:44 CEST] <TMM> does any of that make sense at all? :)
[12:53:12 CEST] <jkqxz> NV12 import on the desktop platforms doesn't have the NV12 format, so you make two separate images which are R8 and RG88.
[12:54:12 CEST] <jkqxz> Hmm.  <https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt> does say you need both planes.
[12:54:33 CEST] <jkqxz> So maybe rather than talking about planes in the frame descriptor, we should instead be talking about images which contain planes.
[12:55:54 CEST] <jkqxz> That is, { int nb_images; struct { uint32_t drm_format; ... modifiers? ...; int nb_planes; struct { int index; ptrdiff_t offset; ptrdiff_t pitch; } planes[N]; } }
[12:56:20 CEST] <LongChair> so NV12 would be one image with 2 planes ? and for desktop two images with one plane eash ? 
[12:56:24 CEST] <LongChair> each*
[12:56:29 CEST] <jkqxz> Yes.
[12:56:55 CEST] <LongChair> i suppose this makes sense :)
[12:57:21 CEST] <jkqxz> wm4:  ^ ?
[12:57:50 CEST] <LongChair> for the modifiers part i have no idea what a modifier is ... never used any .. but i suppose they should be at the same place than formats 
[13:00:42 CEST] <jkqxz> Aha!  They are per-plane: <https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt>.
[13:00:51 CEST] <jkqxz> At least that's clear.
[13:01:37 CEST] <LongChair> jkqxz: yeah seems right :)
[13:02:59 CEST] <LongChair> jkqxz: i'll try to make the opengl-interop in mpv do it right when we have settled with something. If you still play with vaapi then you could probably have it render the frames with drm overlay 
[13:03:31 CEST] <LongChair> i don't want that interop to be rockchip specific
[13:03:49 CEST] <LongChair> just a way to render the AV-PIX-FMT_DRM frames that is as generic as can be
[13:06:29 CEST] <LongChair> jkqxz: let's see what wm4 thinks about that :) then we can make a sample v3 :p
[13:08:50 CEST] <TMM> If I want to create an AVFrame* do I have to set its size somehow? I have done an av_frame_alloc() on my two scratch buffers, but it seems to not be enough. Makes sense I suppose.
[13:09:09 CEST] <TMM> Should I maybe be using just char* buffers for this internally to my codec instead of AVFrames?
[13:12:33 CEST] <nevcairiel> you need to create an avframe, fill its size and type, and then fall ff_get_buffer
[13:16:05 CEST] <TMM> nevcairiel, is that this av_frame_set_qp_data()?
[13:16:14 CEST] <TMM> table*
[13:23:26 CEST] <TMM> oh, I see, does ff_get_buffer() actually create a buffer?
[13:27:12 CEST] <wm4> jkqxz, LongChair: right, for vaapi you import one image per plane
[13:27:23 CEST] <wm4> and each image is mapped as texture
[13:27:47 CEST] <wm4> thus you an sample from luma and chroma planes as separate textures
[13:37:58 CEST] <TMM> OK: So what I appear to have to do is decode my frames to separate buffers, then only copy blocks that have changed in that buffer to the actually display frames. Filling the entire display frame with what was there previously for blocks that weren't changed. I think I need to have two buffers to do this decoding on, at least that's how I did it in the past. So I was thinking of creating two AVFrame's for this decoding and then swapping th
[13:37:58 CEST] <TMM> em, in the final step of frame decoding copying the actual changed blocks.
[13:38:03 CEST] <TMM> Does this sound reasonable?
[13:38:42 CEST] <wm4> it's an obscure game format, so whatever works
[13:39:21 CEST] <TMM> well, I'd like to see this merged eventually :)
[13:42:51 CEST] <TMM> I'm also not entirely sure where I should be allocating the buffers for my 'scratch' AVFrames, ipvideo_decode_init probably, but I don't know if I have the information there yet required to do so
[13:44:24 CEST] <atomnuker> wait until you get a packet and then allocate it (or reallocate it if the format changes)
[13:44:46 CEST] <atomnuker> all decoders should be able to deal with changing pixel formats, widths, everything
[13:45:22 CEST] <atomnuker> though you could probably rely that those old game formats won't change anything during runtime
[13:46:31 CEST] <TMM> they can actually change resolution
[13:46:44 CEST] <TMM> but ffmpeg currently doesn't support that for MVE
[13:47:38 CEST] <BBB> wm4: I dont disagree that most of that stuff is marketing bs, but my point was that theres a lot of people that willingly believe it because they dont know any better (see that ubuntu post)
[13:47:40 CEST] <TMM> maybe I'll just implement it without supporting these changes now, then made a separate patch to support that feature for all formats
[13:47:47 CEST] <BBB> wm4: I used to be in that group also, mind you
[13:48:15 CEST] <BBB> wm4: there was a whole group of us that *was* interested in codecs and we had come up with ideas to implement popular codecs outside of ffmpeg so that we wouldnt rely on crap software (no really!)
[13:48:24 CEST] <BBB> of course that never worked out (pheew)
[13:48:56 CEST] <wm4> BBB: well if all you want is a light third party dependency, then ffmpeg is the worst you could get
[13:49:12 CEST] <wm4> because ffmpeg is monolithic, big, and with a cazy and fast changing API
[13:49:18 CEST] <BBB> I think we need some positive PR work on our end to make their view of us more favourable, or at least make them willing to investigate before they assume blatantly false allegations as facts
[13:49:30 CEST] <BBB> right, and gstreamers api never changes
[13:49:31 CEST] <wm4> (the latter part is probably getting better)
[13:49:44 CEST] <wm4> BBB: is that irony or not?
[13:52:25 CEST] <wm4> I mean I heard gst's API was very stable
[13:52:34 CEST] <wm4> having not changed ABI for a decade etc.
[13:52:56 CEST] <TMM> atomnuker, can you tell me what api I should use to create that buffer? I found some references to av_picture_fill and  avpicture_get_size() but the doxygen suggests I should be using an AVBuffer api?
[13:55:44 CEST] <atomnuker> TMM: ff_get_buffer
[13:56:15 CEST] <TMM> oh, so that does create the buffer? I was confused
[13:56:30 CEST] <TMM> will that also fill in things like the linesize etc?
[13:57:06 CEST] <atomnuker> yes
[13:57:56 CEST] <TMM> ok, thanks, sorry for misunderstanding you nevcairiel
[14:15:32 CEST] <TMM> atomnuker, do I need to separate free that buffer or will av_frame_free() take care of that?
[14:16:16 CEST] <atomnuker> I don't think you understand how decode_frame works
[14:16:30 CEST] <atomnuker> you get an empty unallocated frame in the void pointer
[14:16:49 CEST] <atomnuker> you cast the pointer to an avframe
[14:17:04 CEST] <atomnuker> it points to some outside frame but is empty
[14:17:15 CEST] <atomnuker> ff_get_buffer fills it and allocates the buffers
[14:17:23 CEST] <atomnuker> and then you draw to it
[14:17:55 CEST] <atomnuker> you don't free it before you return, something else frees it, the decoder only allocates and draws to it
[14:18:25 CEST] <atomnuker> now, if you want to allocate another frame, you can do that again using the ff_get_buffer function
[14:18:47 CEST] <atomnuker> though you'll own it so you'll need to free it (during deinit since you'll need it)
[14:19:03 CEST] <TMM> I need to keep two frames for internal decoding purposes that never get freed until after the entire movie is done
[14:19:30 CEST] <atomnuker> yep, go ahead and do that on the first frame and call av_frame_free during deinit
[14:20:16 CEST] <atomnuker> put error checking to make sure the allocated width and height still match the width and height on each frame
[14:20:27 CEST] <nevcairiel> didnt you say you just need the last frame, why is it two now
[14:21:02 CEST] <nevcairiel> we have plenty simple codecs that reference the last frame in the decoder, you could look at one of those
[14:21:17 CEST] <atomnuker> (keep in mind you can technically avoid allocation of extra frames if you can reuse the first frames by reffing the frames you are given)
[14:21:41 CEST] <TMM> nevcairiel, this codec doesn't do that, it needs to refer to an 8x8 pixel block since before the last time it was changed, an arbitrary amount of time in the past
[14:21:59 CEST] <nevcairiel> well thats still one frame
[14:23:20 CEST] <TMM> This is the function I currently have that does the right thing now: https://github.com/hpvb/FFmpeg/commit/21aa37ae8326a09a72e44ab9352f60e4439f01d9#diff-ce350f92bdf8894a883f5ba0197ee800R987
[14:24:01 CEST] <TMM> the relevant bits for what I now do with those two extra frames is here : https://github.com/hpvb/FFmpeg/commit/21aa37ae8326a09a72e44ab9352f60e4439f01d9#diff-ce350f92bdf8894a883f5ba0197ee800R1065
[14:25:13 CEST] <TMM> And this is where I need to get data from prior to the last time a particular block was changed: https://github.com/hpvb/FFmpeg/commit/21aa37ae8326a09a72e44ab9352f60e4439f01d9#diff-ce350f92bdf8894a883f5ba0197ee800R1048
[14:35:30 CEST] <BBB> wm4: it was irony, because when they add hw support, they also need api additions
[14:35:43 CEST] <BBB> wm4: its not that the gstreamer stamp suddenly makes everything magical
[14:35:54 CEST] <BBB> youre still subject to reality and so on
[14:36:41 CEST] <nevcairiel> but it so does!
[14:37:31 CEST] <nevcairiel> for reasons the foss people really like gstreamer, even though its just an ugly wrapper around all the things they dont like =p
[14:38:03 CEST] <BBB> I think we should stop them disliking us
[14:38:12 CEST] <BBB> they dislike us for reasons that have little to do with technology
[14:38:15 CEST] <BBB> these are all just side-effects
[14:38:25 CEST] <BBB> they dislike our api because they dislike us, its like partisan politics
[14:38:36 CEST] <wm4> BBB: I don't know the gst API, the only time I tried it it fucked with my head and I didn't get it
[14:38:38 CEST] <BBB> they also dislike our implementations and our hardware support because they dislike us
[14:38:43 CEST] <BBB> the fundamental issue is that they dislike us
[14:38:48 CEST] <BBB> we can fix the disliking us
[14:38:54 CEST] <BBB> then they will like our api better also
[14:38:56 CEST] <BBB> and our hw
[14:38:58 CEST] <BBB> and everything else
[14:38:58 CEST] <nevcairiel> maybe they should just stop being petty
[14:39:03 CEST] <BBB> ...
[14:39:08 CEST] <wm4> on the other hand I think the ffmpeg API is quite simple now (although obscure things still might steal attention and energy from new users, so that should be fixed)
[14:39:10 CEST] <BBB> yes and libav/ffmpeg is all libavs fault
[14:39:19 CEST] <BBB> that will surely fix everything
[14:39:36 CEST] <BBB> wm4: if you know gst, gst api is quite simple
[14:39:36 CEST] <wm4> who mentioned libav
[14:39:41 CEST] <BBB> wm4: if you know ffmpeg, ff api is quite simple
[14:39:44 CEST] <BBB> but theyre different
[14:39:45 CEST] <wm4> <nevcairiel> for reasons the foss people really like gstreamer, even though its just an ugly wrapper around all the things they dont like =p <- like dshow on windows? trollol
[14:39:51 CEST] <BBB> so if you know and expect ffmpeg, gst api is crazy
[14:39:56 CEST] <BBB> and if you know and expect gst, ff api is crazy
[14:40:05 CEST] <wm4> that was at a time when I didn't know ffmpeg well
[14:40:15 CEST] <BBB> my point is we should stop hating them and should try to get them to stop hating us
[14:40:21 CEST] <BBB> for example by being nice
[14:40:33 CEST] <wm4> (and I was quite afraid of ffmpeg first, I didn't know if I could keep up with my mplayer2 fork)
[14:40:35 CEST] <nevcairiel> when i first got into ffmpeg, i  didnt find the api very hard, and that was in a time when it was still much worse then it is today
[14:40:57 CEST] <wm4> maybe it's because dshow is so much more crazy
[14:40:59 CEST] <BBB> nevcairiel: did you start before it worked on msvc?
[14:41:03 CEST] <nevcairiel> yes
[14:41:05 CEST] <nevcairiel> much before that
[14:41:07 CEST] <BBB> omg poor you
[14:41:18 CEST] <BBB> pre-fork?
[14:41:22 CEST] <nevcairiel> yea
[14:41:28 CEST] <nevcairiel> i started in like 2010
[14:41:33 CEST] <BBB> yeah youve seen everything then
[14:41:56 CEST] <wm4> also our API example are all shitty and confusing
[14:42:07 CEST] <BBB> they are indeed
[14:42:52 CEST] <nevcairiel> well the problem with examples is that all the things are rather inter-twined, to demonstrate decoding you also need to involve avformat, because you want something that actually works
[14:43:20 CEST] <nevcairiel> so small self-contained examples is hard
[14:51:32 CEST] <BBB> J_Darnley: Im looking at wmv1 now, a quick test suggests that its related to inter block coding?
[14:51:40 CEST] <BBB> Im not 100% sure how yet
[14:51:48 CEST] <BBB> but they keyframe is identical
[14:54:43 CEST] <iive> I've always thought that others dislike using ffmpeg api, because it breaks/changes so much
[14:55:22 CEST] <iive> and that was even pre-fork. e.g. ffms
[14:55:57 CEST] <nevcairiel> well its not like we change it for fun, but because the design was limiting serious improvements
[14:56:49 CEST] <iive> well, renaming labels, variables, moving stuff around...
[14:57:45 CEST] <iive> or e.g. removing a single fixed quant variable and replacing it with additional array that contains the quant for a given range.... yeh, that's much simpler
[15:02:00 CEST] <jkqxz> LongChair: wm4:  <http://sprunge.us/CRhE>
[15:02:45 CEST] <jkqxz> Mainly the header changed: more comments on everything.
[15:04:04 CEST] <jkqxz> How big should the arrays be?  The EGL extension limits you to four planes per image, and you can't really have more images or object than real planes.
[15:06:02 CEST] <jkqxz> I think it's unnecessary to actually do the allocation setup at this point - if there is a non-testing use-case for it then it can be added later without an ABI change, because AVHWFramesContext.hwctx is expandable.
[15:10:22 CEST] <wm4> ugh nested static arrays
[15:10:46 CEST] <jkqxz> Would you prefer them to be named structures?  I wondered about that, but they don't have any external use at all.
[15:10:48 CEST] <wm4> next iteration you should also get rid of the nested anonymous struct definitions, and define them separately
[15:11:31 CEST] <kierank> BBB/J_Darnley: did you end up resolving the issues
[15:11:36 CEST] <wm4> do we expect that there are cases where you have multiple images, and each image can have more than 1 plane?
[15:11:45 CEST] <BBB> kierank: mdec is fixed, Im looking at wmv1 now
[15:11:57 CEST] <kierank> ok
[15:11:59 CEST] <wm4> as opposed to 1 "merged" image for all planes vs. 1 image per plane
[15:12:07 CEST] <kierank> amazing what a leviathan this idct is
[15:12:40 CEST] <jkqxz> NV12A in NV12-is-one-image-land?
[15:12:50 CEST] <BBB> kierank: :-p
[15:12:58 CEST] <wm4> jkqxz: never heard of this NV12A?
[15:13:19 CEST] <nevcairiel> it seems fascinating that the idct which should be a rather generic component can apparently cause single issues in odd codecs
[15:13:31 CEST] <jkqxz> I mean, NV12 + A.
[15:13:40 CEST] <jkqxz> Is that a thing?
[15:13:40 CEST] <wm4> jkqxz: does anything use it?
[15:13:43 CEST] <BBB> michaelni: how is the permutation for the fdct set? what I mean is, how do we ensure that the permutation of the fdct output and idct input is identical?
[15:13:51 CEST] <BBB> michaelni: or where does the conversion between them take place?
[15:14:03 CEST] <jkqxz> No idea, I'm just trying to think of ways that people writing drivers could screw over anything but the most general representation :P
[15:15:33 CEST] <wm4> jkqxz: I'm fine with assuming this won't happen for now
[15:15:51 CEST] <wm4> I'm thinking that this would make it slightly easier, but maybe I'm wrong
[15:18:02 CEST] <jkqxz> A top level flag for "planes are all in one image"?  (If set, use the format on the first one and combine all of the planes.)
[15:19:45 CEST] <wm4> or maybe an array of 4 planes, and each plane has a flag whether it starts a new image?
[15:19:58 CEST] <jkqxz> I guess you don't need that if you know separately how many planes are in each format (e.g. NV12 -> 2).
[15:19:59 CEST] <wm4> ok maybe that's all worse than having a 4x4 nested array
[15:20:10 CEST] <wm4> hm not sure
[15:20:29 CEST] <wm4> don't you still need to tell EGL/DRM the offset and stride of each plane?
[15:21:30 CEST] <jkqxz> Yes.  You'd see a DRM_FORMAT_NV12 plane and know that you have to combine it into one image with the next one.
[15:32:46 CEST] <TMM> Is there a frame number somewhere? I have to skip a particular operation only on the very first frame
[15:33:34 CEST] <BBB> kierank: making slow progress, the block that starts the mismatch is at mb_x=13, mb_y=0, frame=1, block=3
[15:33:54 CEST] <BBB> kierank: it appears that the noise shaping did something different
[15:34:18 CEST] <BBB> Im suspecting that it may not be aware of wmv1 scantable specifics (theyre different from mpeg1/msmpeg4v12)
[15:34:23 CEST] <BBB> or something like that
[15:35:03 CEST] <kierank> cool, thanks for spending time on this
[15:37:20 CEST] <BBB> kierank: and the diff comes from round
[15:37:23 CEST] <BBB> err
[15:37:23 CEST] <BBB> quant
[15:38:46 CEST] <BBB> what the hell, input to quant is also different
[15:38:56 CEST] <BBB> hm..
[15:41:19 CEST] <TMM> I just posted my patch to ffmpeg-devel, I hope I didn't mess it up too badly :)
[15:54:15 CEST] <atomnuker> TMM: avctx->frame_number
[16:05:39 CEST] <BBB> michaelni: at this point I probably need help; I have identical commandlines with -idct simple or without (to force the C idct or the SSE2 one we wrote); otherwise no cpuflags and all bitexact flags are set
[16:06:17 CEST] <BBB> michaelni: at frame: 1, mb_x: 4, mb_y: 0, b: 0, intra: 0, mv_dir: 1, mv: 0, -4 (with or without -idct simple)
[16:06:34 CEST] <BBB> michaelni: the residual (from diff_pixels()) is different
[16:06:35 CEST] <BBB> michaelni: why?
[16:06:58 CEST] <BBB> michaelni: until then, everything is the same, and assuming that the reference is the keyframe, the encoding of the keyframe itself is identical
[16:07:17 CEST] <BBB> michaelni: so & why is the predictor different? is stuff there dependent on idct variables?
[16:13:41 CEST] <TMM> atomnuker, that did it, thank you!
[16:14:17 CEST] <iive> BBB: j-frames (intra x8) are not involved in these tests, are there?
[16:14:43 CEST] <atomnuker> J_Darnley: in hindsight, I'm not sure that strip -x patch was a good idea
[16:15:24 CEST] <atomnuker> the text and comments are also stripped so you're left with just instructions
[16:15:47 CEST] <atomnuker> it looks tidier but it takes a bit longer to look up which instruction goes where if you have many similar
[16:31:38 CEST] <LongChair> jkqxz, wm4: ok saw the last version, are we happy with that one ? 
[16:32:56 CEST] <wm4> not sure
[16:33:11 CEST] <wm4> I'm slightly unhappy with the nested array, that makes for 256 inner entries
[16:36:22 CEST] <michaelni> BBB for your first question, i think we permute to the idct order in dct quantize
[16:38:47 CEST] <michaelni> for the 2nd question i dont know, the idct can used in the decission which mb coding mode to use and such though when thats enabled
[16:41:30 CEST] <jkqxz> AV_NUM_DATA_POINTERS is 8.
[16:41:47 CEST] <jkqxz> I think 4 would probably be ok there.
[16:46:46 CEST] <LongChair> i think wm4 means he would like something like AVDRMFrameDescriptorObject, AVDRMFrameDescriptorImage and AVDRMFrameDescriptorPlane separately :)
[16:50:12 CEST] <wm4> that too
[16:50:23 CEST] <wm4> jkqxz: oh, well, still makes 64
[17:02:46 CEST] <J_Darnley> atomnuker: that's a shame
[17:03:40 CEST] <J_Darnley> What takes more time?  Did you mean human work or some program?
[17:04:36 CEST] Action: J_Darnley wonders where he left mp3gain
[17:06:29 CEST] <atomnuker> more human work to figure out, yet not because the printout looks more tidy rather than <comment>\n<instruction>\n<comment> etc.
[17:08:03 CEST] <J_Darnley> I don't think I've ever seen that.  Perhaps gdb and objdump are too dumb for that
[17:08:45 CEST] <J_Darnley> if you want to revert I won't object
[17:10:54 CEST] <atomnuker> this happens in perf
[17:11:08 CEST] <atomnuker> nah, its fine, I don't mind it
[17:24:10 CEST] <atomnuker> J_Darnley: can you test that -X does what you preferred?
[17:24:42 CEST] <atomnuker> it leaves comments and globals but apparently removes compiler generated symbols (like loops)
[17:25:15 CEST] <atomnuker> just replace check_stripflags -x with check_stripflags -X in configure
[17:29:05 CEST] <Gramner> -X doesn't strip things like function_name.loop
[17:29:16 CEST] <Gramner> which -x does
[17:53:00 CEST] <BBB> I think which flag you want depends on what your goal is
[17:53:04 CEST] <BBB> -X is better for perf output
[17:53:11 CEST] <BBB> -x
[17:53:13 CEST] <BBB> I mean
[17:53:20 CEST] <BBB> -X is better for debugging, where you want to know loop markers
[18:21:02 CEST] <LongChair> jkqxz: any other proposal ? :)
[18:38:32 CEST] <philipl> BtbN jkqxz wm4: https://github.com/philipl/FFmpeg/commit/472d5a58d3676b2c906c10bab04484a511d4eaf2
[18:38:52 CEST] <philipl> Trying to introduce a new ffmpeg hwaccel type so we can deprecate cuvid properly, but it's not working.
[18:56:43 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=6170bd453cb8ec4217ca83d9d3dc42cdb2e466b5;hb=HEAD#l2793>
[18:56:59 CEST] <jkqxz> Two hwaccels with the same pixfmt does not work so well.
[19:06:02 CEST] <wm4> right, you somehow need to block get_format
[19:18:25 CEST] <philipl> sad panda.
[19:18:46 CEST] <philipl> So, can we look at a strategy to specify the default output format for the hwaccel?
[19:20:45 CEST] <wm4> you mean cuda specifically defaulting to a different output format?
[19:20:53 CEST] <philipl> Yeah
[19:21:44 CEST] <philipl> make the default format part of the hwaccel definition in ffmpeg_opt.c
[19:26:10 CEST] <wm4> that would lead to a messy difference between cuda and everything else that we'd never get rid of
[19:26:17 CEST] <wm4> (wait, why is cuda different in the first place?)
[19:26:43 CEST] <wm4> maybe we could just deprecate _not_ using hwaccel_output_format?
[19:26:51 CEST] <philipl> We could.
[19:27:02 CEST] <philipl> Or why not treat the hwaccel's pix_fmt as the default to begin with?
[19:27:13 CEST] <philipl> Isn't that actually what most people want?
[19:27:28 CEST] <philipl> If they're using 'ffmpeg' and hwaccel, they are probably trying to do a full hardware transcode
[19:31:42 CEST] <wm4> philipl: I don't know, isn't the argument compatibility? so changing everything to either behavior is a breakage
[19:32:23 CEST] <philipl> Isn't hwaccel_output_format new in the set of changes that jkqxz pushed? We haven't released anything with it yet.
[19:33:23 CEST] <wm4> ah
[19:33:35 CEST] <wm4> so for e.g. vaapi, did the default change?
[19:34:07 CEST] <philipl> Yeah. I don't know. Presumably, ffmpeg didn't even work with vaapi before, so maybe that's a bad example.
[19:34:09 CEST] <philipl> What about vdpau?
[19:36:05 CEST] <jkqxz> The -hwaccel_output_format option has been there for VAAPI since it was first added last year.  Before the recent change, VDPAU and DXVA2 would always download and there was no way to tell it not to.
[19:36:12 CEST] <jkqxz> No defaults have changed.
[19:37:09 CEST] <nevcairiel> (also no reason not to, since nothing could really do anything with dxva2 frames)
[19:37:09 CEST] <jkqxz> Well, DXVA2 will once that gets merged here.
[19:37:24 CEST] <jkqxz> Yeah, but we want to change that!
[19:37:54 CEST] <philipl> https://github.com/philipl/FFmpeg/commit/453c4d8dd9cb0e9ed2ac594d05420a34f46116c6
[19:37:57 CEST] <philipl> That's my idea.
[19:38:07 CEST] <philipl> just make the default be the native hwaccel format
[19:38:40 CEST] <nevcairiel> the question is if that automatically works with any sort of software processing transparently
[19:39:01 CEST] <jkqxz> No, you will need hwdownload if you have that.
[19:39:07 CEST] <atomnuker> jamrial: I'm getting illegal hardware instruction on fmaddps, and I'm running on a skylake
[19:39:10 CEST] <philipl> yeah. it won't magically work.
[19:39:13 CEST] <nevcairiel> because previously you could just set -hwaccel dxva2 and it would just work
[19:39:15 CEST] <atomnuker> is there something special I need to do to use fma?
[19:39:27 CEST] <nevcairiel> hardware decoder, no further limitations
[19:39:40 CEST] <wm4> so cuda was always the different one
[19:39:44 CEST] <jkqxz> Yeah, I'm dubious about the compatibility change.
[19:39:57 CEST] <philipl> wm4: So, then we add a flag to the hwaccel entry saying whether the native format is default or not.
[19:40:19 CEST] <nevcairiel> personally i think it would probably be best if they all behave the same
[19:40:22 CEST] <jkqxz> Not really, it's different because it's not a real hwaccel at all.  QSV similarly - you would get hardware surface output if you set hwaccel and not if not.
[19:41:07 CEST] <LongChair> jkqxz, wm4: so do we settle on something for that hwcontext_drm ? is all we need to split the AVDRMFrameDescriptor sub structs in other individual structs or do we need more changes ? 
[19:41:59 CEST] <wm4> I'm still not convinced we need to support the case of multiple planes per image + multiple images
[19:42:17 CEST] <wm4> just leads to complexity with generic code trying to handle that
[19:43:14 CEST] <LongChair> ok, jkqxz: thoughts ? 
[19:43:15 CEST] <jkqxz> philipl:  I think that change would be ok.  The default_pix_fmt for everything except cuvid would presumably be NONE?
[19:43:36 CEST] <wm4> philipl: so did "ffmpeg -hwaccel cuvid -i file.mkv ..." actually work and use the cuda format?
[19:43:42 CEST] <jkqxz> wm4:  Would you prefer a one-dimensional array with markers saying where the image boundaries are, then?
[19:43:51 CEST] <wm4> jkqxz: hm, maybe
[19:44:00 CEST] <philipl> wm4: with my default change, it worked.
[19:44:15 CEST] <wm4> jkqxz: but that would be semantically the same, and a nested array might be better
[19:44:38 CEST] <wm4> jkqxz: (probably still could #define AV_DRM_PLANES 4, instead of using AV_NUM_DATA_POINTERS)
[19:45:02 CEST] <wm4> philipl: does that mean -hwaccel magically forces the correct codec?
[19:45:03 CEST] <jkqxz> Yeah, I'm pretty sure 4 is good.
[19:45:28 CEST] <philipl> jkqxz: https://github.com/philipl/FFmpeg/commit/e4772ef21eb148f54076e5ff9b9be0f5b249a5d5
[19:45:30 CEST] <jamrial> atomnuker: make sure you're using fmaddps (a macro), not vfmaddps (a fma4 instruction)
[19:45:40 CEST] <philipl> wm4: If we tell it to force it, then it does.
[19:45:57 CEST] <wm4> philipl: not following here
[19:46:11 CEST] <philipl> wm4: Ok, maybe I misunderstood your question.
[19:46:26 CEST] <philipl> Today, '-hwaccel cuvid' forces the native cuda format.
[19:46:37 CEST] <philipl> When people don't want that they don't specify the hwaccel.
[19:47:04 CEST] <philipl> To achieve the same behaviour with generic hwaccel, I need to override the output format automatically.
[19:47:16 CEST] <philipl> My latest suggestion is a per-hwaccel flag that says whether to override to the native format or not.
[19:47:21 CEST] <jkqxz> philipl:  That change mixes the two?  (Also please don't shout your booleans.)
[19:47:26 CEST] <philipl> and we set it to true for cuda, and maybe for qsv but not for anything else.
[19:47:38 CEST] <wm4> philipl: I'm talking about the codec
[19:48:04 CEST] <wm4> since the default codec will be "h264" which doesn't support cuda, you need "h264_cuvid"
[19:48:08 CEST] <philipl> jkqxz: don't shout booleans? We use uppercase normally, I thought.
[19:48:36 CEST] <philipl> wm4: if you specify the codec without the hwaccel, you get a software format
[19:49:08 CEST] <wm4> and if you specify the hwaccel without codec? (that has been my question for the last 5 minutes)
[19:49:21 CEST] <philipl> I think it blows up. hang on.
[19:50:34 CEST] <philipl> wm4: it just ignores it, because it's not a real hwaccel.
[19:50:43 CEST] <philipl> the default software decoder and encoder get used.
[19:51:12 CEST] <wm4> ok
[19:51:50 CEST] <wm4> that must be quite confusing for users
[19:52:05 CEST] <philipl> I'm not sure what they experience, honestly :-)
[19:52:10 CEST] <philipl> So what happens today:
[19:52:20 CEST] <wm4> so I'd say this is all lost, and we should at least make them all behave the same
[19:52:35 CEST] <wm4> that means, requiring -hwaccel_output_format for cuda
[19:52:44 CEST] <philipl> 1) If you don't specify '-hwaccel cuvid' and try to use cuvid/nvenc, they will use the hardware with download/upload in between.
[19:53:01 CEST] <philipl> 2) if you do specify '-hwaccel cuvid' and use cuvid without nvenc, it blows up with format mismatch
[19:53:21 CEST] <wm4> wut
[19:53:22 CEST] <philipl> 3) If you specify -hwaccel cuvid without cuvid/nvenc, it's just ignored.
[19:53:47 CEST] <philipl> 2a) If you use hw_download, it works too
[19:54:11 CEST] <nevcairiel> the cuvid and qsv cases have been all sorts of fucked up
[19:54:43 CEST] <wm4> but 2) shouldn't happen with the new behavior
[19:54:44 CEST] <atomnuker> jamrial: yep, using the macro (can you configure the macro like the instruction e.g. 123 or 321?)
[19:54:46 CEST] <nevcairiel> imho -hwaccel cuvid should do a simple thing: make ffmpeg.c somehow pick the cuvid decoders over the other decoders, if available, and nothign else
[19:55:03 CEST] <wm4> nevcairiel: that would be a higher level thing
[19:55:05 CEST] <nevcairiel> that would make  it behave just like -hwaccel dxva2 or such
[19:55:17 CEST] <wm4> (but agreed)
[19:55:35 CEST] <wm4> that would require an API extension as far as I'm aware
[19:55:44 CEST] <nevcairiel> name matching, yo
[19:55:48 CEST] <wm4> (there's nothing that tells it which decoder is a cuvid h264 decoder etc.)
[19:55:59 CEST] <wm4> name matching is what I do in mpv, and it makes me cry
[19:56:29 CEST] <philipl> wm4: 2) doesn't happen with new generic hwaccel, but the primary case (use hwaccel, specify cuvid and nvenc) stops using full hardware transcoding.
[19:56:47 CEST] <wm4> philipl: so the user needs to add that flag
[19:56:50 CEST] <wm4> where's the problem
[19:57:27 CEST] <wm4> ffmpeg.c hwaccel is rather low level, so it reflects to how it's used
[19:57:55 CEST] <wm4> you need to decide and choose your filters whether to handle hwaccel or sw formats etc.
[19:57:56 CEST] <jamrial> atomnuker: the macro chooses the correct fma3 instruction for you
[19:59:18 CEST] <philipl> Today, 'hwaccel cuvid' is the way you ask for full transcoding. That's the issue.
[19:59:18 CEST] <philipl> If we switch to generic hwaccel, it stops working
[19:59:18 CEST] <philipl> command line comaptibility breaks
[19:59:18 CEST] <philipl> old command line stops doing what it used to do
[19:59:19 CEST] <philipl> BtbN: said he thought that was a problem in the email thread
[19:59:19 CEST] <atomnuker> how does it know which numbers I want to add and multiply?
[20:00:07 CEST] <philipl> I have to run. Maybe BtbN will chime in at some point. I'll try and catch up later.
[20:04:22 CEST] <nevcairiel> atomnuker: you specify it in fma4 syntax and it figures it out
[20:04:54 CEST] <nevcairiel> it choses the appropriate instruction based on which parameters are memory arguments, if any
[20:08:01 CEST] <atomnuker> wtf, it was crashing because I used INIT_XMM fma4
[20:08:21 CEST] <atomnuker> I thought fma4 was a superset of fma3 as well
[20:08:36 CEST] <nevcairiel> no, they are competing techs, fma3 is intel, fma4 is amd
[20:09:16 CEST] <atomnuker> ...
[20:09:25 CEST] <nevcairiel> although amd started supporting fma3 as well now
[20:09:58 CEST] <nevcairiel> amd ryzen actually dropped fma4, afaik
[20:10:17 CEST] <nevcairiel> or it was just broken adn therefor disabled
[20:10:18 CEST] <nevcairiel> one of those
[20:10:24 CEST] <jamrial> it wasn't broken
[20:10:46 CEST] <jamrial> they officially dropped it for ryzen, yes, but it apparently still work :p
[20:10:56 CEST] <jamrial> at least according to agner's pdf
[20:11:32 CEST] <jamrial> the history of fma3/4 is fun. good example of lack of communication i guess
[20:13:24 CEST] <jamrial> xop seems to be gone for good in ryzen
[20:13:42 CEST] <nevcairiel> no point in keeping those, with intels dominance noone optimizes for those
[20:16:27 CEST] <atomnuker> fmaddps fails if the first register is less than m5
[20:16:40 CEST] <atomnuker> this is some messed up macro
[20:17:00 CEST] <atomnuker> (e.g. fma3 emulation of ``fmaddps xmm4, xmm3, xmm2, xmm5'' is not supported)
[20:17:20 CEST] <nevcairiel> fma3 only supports 3 registers, so your dst needs to be identical to one of your sources
[20:18:01 CEST] <atomnuker> oh, so that's why fma4 compiled correctly
[20:19:32 CEST] <jamrial> if you use four different regs in a function targetting fma3, it should warn you
[20:19:46 CEST] <nevcairiel> well, it'll error on you
[20:19:49 CEST] <nevcairiel> ie. an advanced warning
[20:19:49 CEST] <nevcairiel> :D
[20:21:07 CEST] <TMM> "While the FMA4 instructions seem to work according to some tests, they can also give wrong results.[16]"
[20:21:09 CEST] <TMM> fun
[20:23:51 CEST] <jamrial> is that on ryzen?
[20:24:59 CEST] <TMM> yeah
[20:25:25 CEST] <TMM> apparently they dropped support for it late in the release process and they didn't want to patch the instruction decoder
[20:25:38 CEST] <TMM> so ryzen doesn't signal FMA4 in CPUID, but it doesn't trap
[20:25:47 CEST] <TMM> it just returns garbage, on some insns
[20:25:50 CEST] <TMM> that's real fun
[20:26:07 CEST] <nevcairiel> well not really
[20:26:11 CEST] <nevcairiel> if you use it without cpuid
[20:26:13 CEST] <nevcairiel> its your own fault
[20:26:19 CEST] <atomnuker> well, fma does increase inaccuracies slightly
[20:26:40 CEST] <TMM> well, sure, you're not supposed to use features not in cpuid, but don't processors normally trap?
[20:27:13 CEST] <TMM> I don't know if people use the trapping behavior for feature detection instead of cpuid maybe
[20:30:06 CEST] <nevcairiel> i suppose, but it would seem stupid to do that if there is a feature reporting mechanism
[21:07:04 CEST] <TMM> I'm looking at why MVE movie playback doesn't exit, the AVInputFormat .read_packet returns AVERROR(EIO), this is apparently not enough to end the decoding. Does the codec have to do something too?
[21:28:39 CEST] <TMM> oh, ffplay also doesn't end on avis it seems
[21:30:28 CEST] <TMM> There actually was a bug with that :) It always returned 'invalid data' at the end of an MVE, I fixed htat at least
[21:30:39 CEST] <TMM> but is ffplay supposed to exit at the end of a file?
[21:31:01 CEST] <TMM> ffplay from fedora packages also doesn't seem to exit, weird
[21:37:23 CEST] <nevcairiel> ffplay doesnt exist on its own unless you specify -autoexit i think
[21:46:10 CEST] <TMM> ah
[21:48:03 CEST] <TMM> nevcairiel, that did it :) also now I can verify that my codec is actually not so broken
[22:17:21 CEST] <cone-823> ffmpeg 03James Almer 07master:8ddb6820bd52: avformat/libssh: check the user provided a password before trying to use it
[22:24:52 CEST] <atomnuker> jamrial / nevcairiel: how do I replace vfmaddsub123ps m3, m2, m1 with fmaddsubps?
[22:25:19 CEST] <atomnuker> all permutations of the 4 registers yield completely wrong results to what I need
[22:25:57 CEST] <jamrial> atomnuker: fma* dst, src1, src2, src3 ---> dst = src1 * src2 + src3
[22:26:38 CEST] <TMM> Hmm, there's one more feature missing in ffmpeg for MVE support it seems. MVE has this notion of a 'display op' which is what will make the current front buffer actually render to screen. Currently ffmpeg renders each display frame to the output
[22:26:43 CEST] <jamrial> dst needs to be the same as one of the three src regs for it to work with fma3
[22:27:21 CEST] <TMM> does ffmpeg natively have a feature for this? Or do I have to implement 'offscreen' rending the the codec and pass whether or not whatever is currently on the front buffer be actually displayed or not?
[22:27:30 CEST] <nevcairiel> 123 isnt even a valid suffix, is it
[22:29:12 CEST] <atomnuker> it compiles and runs fine
[22:31:38 CEST] <nevcairiel> all the intel docs i see only reference 132, 213 or 231
[22:32:05 CEST] <TMM> I think I basically need to be calling my codec repeatedly without necessarily creating an actual frame
[22:32:59 CEST] <atomnuker> how come it runs then?
[22:33:42 CEST] <jamrial> "error: undefined symbol `vfmaddps123.loop'"
[22:33:48 CEST] <jamrial> 123 doesn't even assemble for me
[22:34:27 CEST] <jamrial> atomnuker: in any case, it's not hard. just use fm{add,sub,etc} dst, src1, src2, src3 and forget about all the crazy numbers and crap from fma3
[22:34:39 CEST] <jamrial> the macros will figure that out for you
[22:35:23 CEST] <nevcairiel> vfmaddsub132ps m3, m2, m1 would become  fmaddsubps m3, m3, m1, m2 anyway
[22:35:43 CEST] <atomnuker> oh crap, I thought my dst was m1
[22:36:05 CEST] <atomnuker> (because I wanted to use it in another part of the code but there the dst was m1)
[22:36:46 CEST] <atomnuker> yep, everything is fine now
[22:36:59 CEST] <nevcairiel> if you need to translate existing fma3 code to fma4/x86inc, you can a ctually use the numbers to permute the arguments
[22:37:18 CEST] <nevcairiel> 132 -> swap second and third argument
[22:38:34 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07master:c94326c1fc2f: avcodec/hevcpred_template: Fix left shift of negative value
[22:38:35 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07master:c746f92a8e03: avcodec/jpeg2000dsp: Reorder operations in ict_int() to avoid 2 integer overflows
[22:38:36 CEST] <cone-823> ffmpeg 03Daniel Kucera 07master:d4a900fad8b1: libavformat/subfile: return AVERROR_EOF on EOF
[22:38:37 CEST] <cone-823> ffmpeg 03Daniel Kucera 07master:c557718bea35: libavformat/file: return AVERROR_EOF on EOF
[22:38:50 CEST] <nevcairiel> and because the order of multiplications makes no difference, not even all combinations have to exist for fma3
[22:38:54 CEST] <nevcairiel> hence 123 is not a thing
[22:39:39 CEST] <jamrial> sucks that fma3 ended up winning in the end
[22:39:46 CEST] <jamrial> intel goes and introduces avx with the big change of adding non-destructive versions of existing instructions, then goes and adopts fma3
[22:40:38 CEST] <nevcairiel> i guess they didnt make non-destructive avx versions of fma3 in the process? :p
[22:40:44 CEST] <nevcairiel> well that would've kinda been fma4 just weirder
[22:41:21 CEST] <nevcairiel> fma4 is also more flexible with using memory inputs, it can actually take two, not just one
[22:41:32 CEST] <jamrial> it can?
[22:42:40 CEST] <jamrial> yasm doesn't seem to like it
[22:43:13 CEST] <nevcairiel> maybe it can just take the memory input in two different locations instead of just the last one like fma3, and the docs werent very explicit
[22:43:33 CEST] <jamrial> yes, that it can
[22:43:36 CEST] <nevcairiel> (thats really the reason why fma3 has the different permuations anyway, so different arguments can be memory)
[22:43:40 CEST] <jamrial> either in the third or four operand
[22:45:40 CEST] <TMM> Is it actually ok to not emit a new frame when decode() is called?
[22:47:10 CEST] <TMM> I guess I'll have to queue op video data until I see a decode op actually, and just run it in the codec, judging by the apis
[22:47:37 CEST] <atomnuker> TMM: yep, just set *got_frame to 0 and return a 0
[22:48:14 CEST] <TMM> oh, that's not as painful as I'd feared then
[22:49:20 CEST] <Gramner> you cannot really encode multiple memory operands in x86 anyway, not without inventing a new instruction encoding that isn't even similar to the existing ModR/M stuff which would add a ton of decoder complexity
[22:52:16 CEST] <Gramner> also fma4 is essentially two separate instructions since either the multiplier or the addend can be memory
[22:52:35 CEST] <Gramner> they just happen to have the same instruction name
[22:57:39 CEST] <Gramner> intel's implementation of vex couldn't really handle more than 3 registers in a sensible way, see vpblendvb for a fun example of hackery required to accomplish 4-arg (it encodes one register number as an imm8 and is slower than the non-vex pblendvb on some cpus)
[23:01:00 CEST] <Gramner> intel and amd wouild both be better off if they would actually talk to each other about how to handle ISA extensions, but good luck with that
[23:11:42 CEST] <TMM> atomnuker, ah, this worked great
[23:14:19 CEST] <TMM> maybe I should chop up this patch series and actually try to submit it
[23:14:34 CEST] <TMM> I think my request for comment patch may be a little large for anyone to seriously look at
[23:25:54 CEST] <nevcairiel> Gramner: well at this point it doesnt seem all that likely that AMD would be inventing many extensions, but who knows
[23:26:23 CEST] <Gramner> they're better off not doing that, yeah
[23:26:44 CEST] <Gramner> they have a very limited R&D budget, better spend it somewhere more useful
[23:30:29 CEST] <Gramner> I wonder what will happen ~2019 when amd's x86-64 patents expire while intel still holds patents for all the new instruction sets
[23:30:33 CEST] <nevcairiel> meanwhile, intel and its partners seem to have some pre-launch trouble with Skylake-X, reviewers are a bit annoyed that the BIOSes are a bit unfinished and performance drastically improved just in the last 48 hours, with reviews scheduled to be released on monday... busy weekend
[23:31:57 CEST] <jamrial> Gramner: what could happen then?
[23:32:11 CEST] <Gramner> who knows?
[23:34:20 CEST] <Gramner> I guess anyone should be able to make x86-64 chips by then, albeit without AVX and new stuff like that. dunno if anyone's up for it
[23:35:18 CEST] <nevcairiel> its not like any of the non-AMD/Intel chips ever were any good
[00:00:00 CEST] --- Sun Jun 18 2017