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

[burek]

[00:51:22 CEST] <jamrial> there, some merges for nasm love on the ml
[00:58:33 CEST] <J_Darnley> Ha.  I was half working on similar too
[01:01:25 CEST] <atomnuker> jamrial: been waiting for those, they all LGTM
[01:02:24 CEST] <atomnuker> "generating dependency information as a sideeffect of assembling, thus cutting build times in half"
[01:02:28 CEST] <atomnuker> seriously?
[01:03:04 CEST] <JEEB> :D
[01:03:26 CEST] <atomnuker> (is that compared to nasm without the second patch or to current yasm?)
[01:10:34 CEST] <iive> atomnuker: assembly compilation is not something that takes much time...
[01:10:46 CEST] <JEEB> tell that to some of the stuff in x265
[01:10:58 CEST] <iive> it's C++
[01:11:02 CEST] <JEEB> there's asm
[01:11:08 CEST] <iive> intrinsics?
[01:11:08 CEST] <JEEB> I meant the actual yasm execution
[01:11:26 CEST] <JEEB> x265 actually used asm so that yasm needed its hash table largened
[01:11:57 CEST] <JEEB> https://github.com/yasm/yasm/commit/e32ff2c2abc22532a58c9b687d922500d23fd709
[01:11:58 CEST] <iive> ok, at least one thing they've done right
[01:30:45 CEST] <Gramner> oh yeah, that commit. I got tired of yasm being slow as hell so I went and made it 20x faster
[01:41:47 CEST] <iive> what is that hash used for?
[01:42:09 CEST] <iive> branchs ?
[01:46:51 CEST] <Gramner> macros invocation and stuff like that. and since almost all sse instructions are overloaded as macros in x86inc that ends up being a lot
[01:47:26 CEST] <iive> i see.
[01:54:42 CEST] <cone-135> ffmpeg 03Luca Barbato 07master:19bf50406ebf: configure: Move up the avbuild directory creation
[02:21:58 CEST] <BBB> JEEB: have you never built ffmpeg?
[02:22:14 CEST] <BBB> JEEB: without that patch, building the vp9 inverse transform also takes several minutes
[02:22:19 CEST] <BBB> its not just x265 ;)
[02:25:41 CEST] <iive> well, who needs more than 31 macros?
[02:26:50 CEST] <atomnuker> I'll tell you who
[02:26:56 CEST] <atomnuker> people who use avx2, that's who
[02:27:07 CEST] <atomnuker> 8 floats... my head hurts
[02:27:08 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:e95fcfe8fb28: avcodec/lpc: signed integer overflow in compute_lpc_coefs() (aacdec_fixed)
[02:27:09 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:5443c4bdf482: avcodec/mpeg4videodec: Fix overflow in virtual_ref computation
[02:27:10 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:fdfbcbdd1487: avcodec/hevcdec: Check beta and tc offset in hls_slice_header()
[02:27:11 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:d7b3d5c3f2e2: avcodec/hevc_filter: Fix invalid shift
[02:27:12 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:70a7df049c41: avcodec/mpegvideo: Use intra_scantable in dct_unquantize_h263_intra_c()
[02:38:06 CEST] <iive> atomnuker: that was kind of rethorical question, like who needs more than 640KB of ram...
[02:38:57 CEST] <atomnuker> I'll tell you who
[02:39:06 CEST] <atomnuker> people who use avx2, that's who
[02:39:41 CEST] <iive> :D
[04:19:33 CEST] <thebombzen> it appears that some sort of fuzzing is going on
[04:19:37 CEST] <thebombzen> that's a lot of bug fixes
[04:28:20 CEST] <rcombs> 0.o iOS 11 supports Opus
[04:28:23 CEST] <rcombs> (in CAF)
[04:28:38 CEST] <rcombs> (in Podcasts.app)
[04:45:42 CEST] <jamrial> rcombs: got a sample? would be nice to support i guess
[04:45:58 CEST] <rcombs> https://hetzel.net/2017-06-12/ios-11-opus-support-in-podcast-feeds/
[08:09:04 CEST] <cone-583> ffmpeg 03Memphiz 07master:998609ddb888: aarch64: vp9: Fix assembling with Xcode 6.2 and older
[08:09:04 CEST] <cone-583> ffmpeg 03Memphiz 07master:9e85c5d6a7e6: aarch64: vp9 16bpp: Fix assembling with Xcode 6.2 and older
[13:41:27 CEST] <durandal_1707> i will work on atrac9 only if somebody pays me
[14:07:33 CEST] <RiCON> rcombs: "Podcasts.app supports Opus playback, if you claim the file is AAC, although its CAF containing Opus." lol
[14:09:56 CEST] <ritsuka> iOS 11 added opus and flac at the system level, so every app can decode it if you avoid the existing file type checks
[14:11:04 CEST] <durandal_1707> it have strange extradata
[14:11:37 CEST] <ritsuka> I have not found any documentation for the extradata
[14:12:32 CEST] <thebombzen> ios 11 finally added flac and opus support? well finally
[14:12:59 CEST] <ritsuka> opus probably for webrtc
[14:14:04 CEST] <atomnuker> did they write their own decoder or did they use libflac/opus?
[14:18:03 CEST] <thebombzen> probably their own. NIE
[14:18:08 CEST] <thebombzen> err NIH
[14:20:54 CEST] <atomnuker> until I see proof I shall still consider ffopusenc to be the first and only non-libopus based thing out there
[14:23:29 CEST] <ritsuka> symbols names look likes standard libflac/libopus
[14:25:43 CEST] <durandal_1707> ritsuka: you have binary of ios decoder?
[14:26:11 CEST] <ritsuka> I checked the macOS one
[15:00:17 CEST] <cone-485> ffmpeg 03Ronald S. Bultje 07master:42dd1434bf6a: mdec: use correctly permutated quant matrix for dequantization.
[15:01:58 CEST] <cone-485> ffmpeg 03Ronald S. Bultje 07master:e639d09199dd: mdec: stop preferring the simple IDCT.
[15:04:42 CEST] <BBB> J_Darnley: do you have a tree or patches for the outstanding ones so I can address michaelnis issues/comments/review?
[15:04:49 CEST] <BBB> J_Darnley: I dont remember which ones are outstanding
[15:31:36 CEST] <J_Darnley> BBB: I'll rebase and push
[15:31:43 CEST] <BBB> push?
[15:31:47 CEST] <BBB> oh to gitlab
[15:31:49 CEST] <BBB> :)
[15:31:54 CEST] <J_Darnley> yes
[15:32:02 CEST] <BBB> ty!
[15:33:40 CEST] <BBB> michaelni: any idea where to look for that rgb bug?
[15:33:58 CEST] <J_Darnley> BBB: mpeg2_asm8
[15:34:40 CEST] <BBB> ah cool, so 3 patches remaining
[15:34:44 CEST] <J_Darnley> yes
[15:40:12 CEST] <jamrial> ritsuka: you have the High Sierra beta? think you can create a couple varied opus-in-caf files? mainly channels other than mono
[15:41:05 CEST] <jamrial> might help identifying what the contents of the extradata are. the only obvious one is samplerate
[15:41:40 CEST] <jamrial> for some reason they didn't just dump the usual Ogg OpusHead like matroska and mp4 do
[15:42:48 CEST] <atomnuker> jamrial: if you're familiar with ogg could you take a look why https://jmvalin.ca/misc_stuff/chain_works.opus fails to decode correctly?
[15:43:12 CEST] <atomnuker> its a chained opus file, used by online radios
[15:43:35 CEST] <atomnuker> (we support chained vorbis, I tried to look at why we do so I could replicate it but couldn't)
[15:47:06 CEST] <BBB> ah fixed, easy
[16:11:37 CEST] <BBB> atomnuker: chained opus, nooooooooooooooo
[16:22:02 CEST] <atomnuker> then there's also the fact that our opus muxer doesn't code pre-skip properly
[16:22:41 CEST] <atomnuker> *post-skip, not pre-skip, I think at least pre-skip is coded correctly
[16:25:43 CEST] <durandal_170> ritsuka: can you create stereo file?
[16:29:37 CEST] <ritsuka> yes
[16:55:16 CEST] <durandal_170> atomnuker: how is noiseredux going?
[16:57:22 CEST] <ritsuka> durandal_170 jamrial : https://www.dropbox.com/s/si70wf7cpxcqnni/opus-caf.zip?dl=0 mono and stereo, I couldn't create any other channel layout with afconvert
[16:59:49 CEST] <durandal_170> lol, than just ignore extradata and it should work
[17:16:03 CEST] <jamrial> durandal_170: yeah, but i guess one of those values is pre-skip, so while working skipping extradata is not "ideal"
[18:17:36 CEST] <atomnuker> durandal_170: I'll work on it tonight after I finish fft15 asm
[18:17:40 CEST] <atomnuker> so close now
[18:17:52 CEST] <atomnuker> what's the best way of doing strided writes?
[18:18:39 CEST] <atomnuker> e.g. first 8 bytes go to stride*(2), next ones to to stride*(2), etc.
[18:19:13 CEST] <atomnuker> I think I remembered seeing an instruction which handled that but I could be mistaken
[18:20:24 CEST] <nevcairiel> i always thought there is only load instructions for that pattern
[18:21:15 CEST] <iive> atomnuker: hum?
[18:21:35 CEST] <iive> 8 bytes are 2 floats?
[18:22:11 CEST] <jamrial> sounds like scatter, but that's avx512
[18:22:17 CEST] <nevcairiel> fft always operates in two float elements, real and imaginary
[18:22:35 CEST] <atomnuker> yep, 2 floats
[18:22:50 CEST] <iive> ssse3 had something similar
[18:23:13 CEST] <atomnuker> I guess I'll have to extract and do 4 movs
[18:23:37 CEST] <jamrial> oh, you can use extractps then, sse4
[18:24:06 CEST] <atomnuker> that extracts 1 float value, I need 2
[18:24:26 CEST] <atomnuker> extractpd?
[18:24:38 CEST] <jamrial> for two there's mov[lh]ps, but that only works on xmm regs afaik
[18:24:39 CEST] <atomnuker> huh, there isn't an extractpd
[18:25:18 CEST] <iive> movhps movlps
[18:25:48 CEST] <jamrial> for ymm i don't think you can extract 8 bytes from an arbitrary position of the reg. Gramner complained about the lack of such functinality once
[18:26:38 CEST] <iive> yeh, and it's sse1
[18:26:47 CEST] <Gramner> correct, you can't
[18:26:49 CEST] <jamrial> same with extracps now that i check. only xmm
[18:27:00 CEST] <Gramner> need to first vextractf128
[18:27:40 CEST] <gh0st__> That's unfortunate
[18:29:18 CEST] <gh0st__> I was looking such thing all over avx2 spec, but didn't find anything.
[18:36:38 CEST] <dcherednik> Hi. Can someone read fft function in libavcodec/dcaenc.c? Is it correct implementation?
[18:38:17 CEST] <atomnuker> dcherednik: that's actually a duplicated function
[18:38:23 CEST] <atomnuker> dcaenc uses an integer mdct
[18:38:31 CEST] <atomnuker> *fft
[18:38:54 CEST] <atomnuker> we already have an integer fft if you switch a define before including libavcodec/fft.h
[18:39:06 CEST] <dcherednik> Yes, and i want to replace it with common function
[18:39:17 CEST] <atomnuker> ah, cool, I was also wanting to do that
[18:39:24 CEST] <dcherednik> but got a bit different result
[18:39:25 CEST] <atomnuker> it used the fft for analysis only, right?
[18:39:32 CEST] <dcherednik> right
[18:40:31 CEST] <atomnuker> I'd suggest logging the coefficients you get from one function vs the other and plotting them against each other
[18:40:39 CEST] <atomnuker> if they look similar they'll be right
[18:41:03 CEST] <atomnuker> I guess the fft inside dcaenc used a different approximation
[18:41:24 CEST] <atomnuker> jamrial: I'm quite annoyed by the fact I can't do [outq + strideq*(1 + %8)]
[18:42:48 CEST] <atomnuker> why is nasm telling me I have an invalid effective address, it should know better to resolve the argument of the macro
[18:49:06 CEST] <Gramner> that should work?
[18:49:24 CEST] <Gramner> assuming the resulting multiplier is 1,2,4 or 8
[18:49:30 CEST] <iive> atomnuker: I think there are just *1 *2 *4 
[18:49:49 CEST] <iive> *8 too?
[18:50:12 CEST] <Gramner> yes
[18:50:15 CEST] <iive> definitely not mmsize
[18:50:46 CEST] <atomnuker> oh, I didn't know you could only multiply by a power of two
[18:51:00 CEST] <atomnuker> I need to multiply by 3 so that's out the window then
[18:51:08 CEST] <iive> it's hidden shift
[18:52:16 CEST] <nevcairiel> you can cheat by using an extra addition, but you already have one in there, so thats out too
[18:52:32 CEST] <iive> is stride a constant?
[18:52:56 CEST] <iive> i guess not, if you keep it in register
[19:02:15 CEST] <jamrial> atomnuker: if you need to do stride * 3, you need to store that value in a separate register using for example "lea stride3q, [strideq+strideq*2]"
[19:02:47 CEST] <iive> or increment outq
[19:03:11 CEST] <jamrial> "lea stride3q, [strideq*3]" also works, as nasm/yasm will convert it into the above before assembly
[19:11:57 CEST] <atomnuker> have to use 4 LEAs, no choice
[19:15:49 CEST] <atomnuker> oh come on
[19:17:05 CEST] <atomnuker> shit, I need to also multiply the stride and keep it in a separate register
[19:22:00 CEST] <cone-485> ffmpeg 03Paul B Mahol 07master:664ac7c5e2e9: avfilter/af_stereotools: add forgotten break
[20:01:53 CEST] <atomnuker> 20% increase in opus decoding performance
[20:02:05 CEST] <atomnuker> I still need to clean it up though
[20:04:55 CEST] <iive> total?!
[20:05:12 CEST] <iive> that's massive!
[20:05:12 CEST] <atomnuker> yep
[20:19:40 CEST] <durandal_170> ritsuka: i cant fetch it
[20:22:24 CEST] <jamrial> durandal_170: https://0x0.st/lkh.caf that's the stereo one
[20:22:52 CEST] <jamrial> durandal_170: https://0x0.st/ldr.caf and the mono
[20:23:46 CEST] <jamrial> durandal_170: there are apparently five values in the extradata for these opus-in-caf files. first one seems to always be 2048, second is sample rate (fixed to 48000 and not original sample rate as in OpusHead it seems), third is the same as frames_per_packet from the desc chunk, fourth seems to always be -1000, and fifth is channel count
[20:24:10 CEST] <jamrial> no idea what 2048 and -1000 are, but most likely not pre-skip
[20:24:51 CEST] <jamrial> so unless you find something i didn't notice, i guess skipping extradata is the way to go
[20:49:12 CEST] <dcherednik> atomnuker: It looks like fft inside dcaenc works wrong with DC. Plots looks similar, but shifted for one line. If disable windowing, put DC - I get correct result in case of common ffmpeg implementation, and something strange with long tail in case of dca fft.
[20:50:19 CEST] <atomnuker> put dc? from where?
[20:50:48 CEST] <atomnuker> (also could you just change the implementation to use float FFTs? it'll make working with it far easier)
[20:52:00 CEST] <dcherednik> I have already implemented fixed and fixed_32 rdft, tests passes.
[20:52:01 CEST] <durandal_170> why?
[20:54:38 CEST] <dcherednik> Just emulate dc input for fft, I expect to get x*N in first real output.
[20:58:13 CEST] <atomnuker> durandal_170: because you don't have to do weird scaling everywhere
[21:06:22 CEST] <tdjones> atomnuker: Have you been able to make any more progess on the opus psy transient detection?
[21:09:35 CEST] <atomnuker> no, had other things to do
[21:31:49 CEST] <ubitux> jamrial: about the aacpsdsp fate tests; do you want me to apply with your patches separated or you prefer to squash them in my original commit with signed-off + desc of the changes
[21:32:06 CEST] <jamrial> squash them, yeah
[21:32:10 CEST] <ubitux> ok
[21:32:16 CEST] <ubitux> i won't integrate your latest test though
[21:32:22 CEST] <ubitux> you can still add it on top
[21:32:25 CEST] <ubitux> i'll just pick your fixes
[21:32:30 CEST] <jamrial> alright
[21:32:47 CEST] <ubitux> sorry for the delay btw, i'm still fighting with these boards and their shitty kernel support
[21:33:24 CEST] <ubitux> i'll send the final patchset tmr and probably apply in the week-end or next week
[21:33:43 CEST] <jamrial> ubitux: btw, i'm about to push the build system libav cherry picks i sent to the ml. that includes making nasm the default, so you might want to change your nasm fate client to instead force yasm after that :p
[21:34:06 CEST] <ubitux> sure
[21:34:25 CEST] <ubitux> i need to catchup with the ml 
[21:39:12 CEST] <jamrial> ubitux: i'd like to get back to merges as well, whenever you have time. it would be ideal to get to the major bump before ~4 months since the last release have passed
[21:39:21 CEST] <jamrial> we're relatively close and there are a lot of noops ahead (bitstream reader commits, or cherry picked stuff)
[21:40:16 CEST] <ubitux> well the question is what to do with dash
[21:40:27 CEST] <ubitux> the guy finally answered me to say he'll have a look when he has time
[21:40:36 CEST] <ubitux> but it's been days/weeks now
[21:40:38 CEST] <ubitux> so..
[21:40:44 CEST] <jamrial> for things that we have already implemented in a different way and the person that wrote them can't be reached, lets just favor the merged version and not waste time with it
[21:40:59 CEST] <jamrial> and yeah, if they take a lot of time then IMO lets do the same
[21:41:35 CEST] <ubitux> i agree, but i'd like to test anyway, and testing dash ’ lazyness++
[21:42:51 CEST] <ubitux> i'm ok spending days doing mostly monkey merging and noops
[21:43:03 CEST] <ubitux> but spending days trying to figure out how to test the code is really annoying
[21:43:34 CEST] <ubitux> unless we're almost 1 on 1 with libav
[21:44:42 CEST] <jamrial> let dashenc users test it by rushing to trac to report regressions :p
[22:01:33 CEST] <wm4> just skip the dash stuff?
[22:02:15 CEST] <Compn> yeah dont mess up dash :P
[22:02:17 CEST] Action: Compn runs
[22:03:39 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:fd502f4f5fe8: build: Generalize yasm/nasm-related variable names
[22:03:40 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:0cc0c5b6dbf1: build: Allow generating dependencies as a side-effect of assembling
[22:03:41 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:d44935cbf4e4: build: Explicitly set 32-bit/64-bit object formats for nasm/yasm
[22:03:42 CEST] <cone-485> ffmpeg 03James Almer 07master:3cc73d3d6d2a: build: fix commandline selection of nasm
[22:03:43 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:4f9297ac3b39: build: Prefer NASM assembler over YASM
[22:03:44 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:5cae5a1defa3: configure: Move x86 assembler sanity check into assembler probe function
[22:03:48 CEST] <jamrial> so long, yasm, and thanks for resurrecting nasm
[22:24:57 CEST] <mateo`> maybe i should turn one of my aarch64 board into a fate instance
[22:43:30 CEST] <leif> Hello, I have found several typos in the doxygen documentation. I'd be happy to submit a patch/PR/etc to fix these typos. It looks like the only way to submit the fix for the docs is to subscribe to ffmpeg-devel, is this correct?
[22:44:08 CEST] <J_Darnley> It is easier to email the list of you subscribe, otherwise you wait in the mod queue.
[22:44:22 CEST] <J_Darnley> However you can turn off email delivery.
[22:44:34 CEST] <durandal_170> leif: yes, which typos?
[22:49:23 CEST] <leif> J_Darnley: okay thanks.
[22:49:33 CEST] <leif> durandal_170: Sure, one moment:
[22:50:11 CEST] <leif> For starters:
[22:50:16 CEST] <leif> next input/input in the list, NULL if this is the last
[22:50:21 CEST] <leif> I suspect you meant input/output there
[22:50:29 CEST] <leif> (In the docs for AVFilterInOut)
[22:51:38 CEST] <durandal_170> ah i thought about documentation, just send patch
[22:52:11 CEST] <leif> OH, okay
[22:52:15 CEST] <leif> Will do, thanks.
[22:52:30 CEST] <leif> But ya, just some small things here and there.
[22:52:36 CEST] <leif> Thanks. :)
[22:57:00 CEST] <jamrial> nevcairiel: msvc does not like nasm "LINK : fatal error LNK1000: unknown error at 00007FF6E623F74C; consult documentation for technical support options"
[22:57:52 CEST] <nevcairiel> jamrial: seems to work for libav
[22:58:29 CEST] <nevcairiel> .. unless configure figures that out and switches to yasm
[22:58:37 CEST] <jamrial> it's libavcodec only
[22:58:42 CEST] <jamrial> other libraries don't throw that error
[22:58:46 CEST] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20170621204044&log=compile&slot=x86_32-msvc14-dll-windows-native
[22:59:40 CEST] <nevcairiel> so likely some specific code somewhere
[22:59:45 CEST] <nevcairiel> something libav doesnt have
[23:00:50 CEST] <nevcairiel> interestingly only --enabled-shared as well
[23:00:54 CEST] <nevcairiel> maybe nasm needs a flag?
[23:02:12 CEST] <jamrial> nevcairiel: the static client hasn't yet run with the nasm commits
[23:02:24 CEST] <jamrial> unless you mean you tried just now yourself
[23:02:30 CEST] <nevcairiel> oh right i only looked at the time, not the rev
[23:02:57 CEST] <jamrial> i'm also wonder wtf is going on with netbsd: http://fate.ffmpeg.org/log.cgi?time=20170621101529&log=compile&slot=x86_64-netbsd-gcc46
[23:03:05 CEST] <jamrial> "yasm: warning: can open only one input file, only the last file will be processed"
[23:03:35 CEST] <jamrial> yasm, not nasm, so i guess the command line is faulty
[23:04:01 CEST] <jamrial> can't reproduce on mingw or archlinux x86_64
[23:47:51 CEST] <atomnuker> (-166.398041 -0.023095) vs (-166.398041 -0.023098)
[23:48:06 CEST] <atomnuker> does these differences look like they're because of fma?
[23:48:39 CEST] <durandal_170> whats that?
[23:48:53 CEST] <atomnuker> coefficients
[23:49:30 CEST] <atomnuker> they're so very slightly different but they break the fft
[23:49:47 CEST] <durandal_170> bug somewhere?
[23:50:34 CEST] <jamrial> nevcairiel: yeah, shared only it seems
[00:00:00 CEST] --- Thu Jun 22 2017