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

[burek]

[00:01:11 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:2752410c4788: avcodec/golomb: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[00:01:12 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:d05bdba2428d: avcodec/mss3: Fix runtime error: signed integer overflow: -2146318336 - 2139696256 cannot be represented in type 'int'
[00:01:13 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:6899e6e56065: avcodec/diracdec: Fix Assertion frame->buf[0] failed at libavcodec/decode.c:610
[05:59:01 CEST] <cone-423> ffmpeg 03James Almer 07release/3.2:49279d4cc2c7: avformat/concatdec: fix the h264 annexb extradata check
[05:59:01 CEST] <cone-423> ffmpeg 03James Almer 07release/3.2:8d9f9270780d: avcodec/options: factorize avcodec_copy_context() cleanup code
[05:59:01 CEST] <cone-423> ffmpeg 03James Almer 07release/3.2:65add3a8184d: avcodec/options: do a more thorough clean up in avcodec_copy_context()
[05:59:01 CEST] <cone-423> ffmpeg 03Aaron Levinson 07release/3.2:9cf601f87da8: avformat/utils: free AVStream.codec properly in free_stream()
[08:28:50 CEST] <atomnuker> cmp r4d, 4;  cmovl r4, r5  error: label or instruction expected at start of line
[08:28:54 CEST] <atomnuker> HOW IS THIS AN ERROR
[08:29:09 CEST] <atomnuker> I really hate old x86 junk and wish all flags would burn
[08:29:57 CEST] <Threads> sounds like we got some communism going on here
[08:30:21 CEST] <atomnuker> no, discrimination
[08:30:33 CEST] <atomnuker> this exact string is used many many time throughout the code
[08:31:26 CEST] <atomnuker> yet in this exact file cmp doesn't mean cmp, it means some evil word which nasm interprets as me demanding it gives me all its moneyt
[09:22:24 CEST] <sinanksu> IMPORTANT : SwfSize parameter available in ffmpeg?
[09:22:45 CEST] <atomnuker> what the fuck, it turns out it was because I had 2 arguments named "c" and "s"
[09:23:20 CEST] <atomnuker> holy crap did nasm mistake the c in cmp for the argument
[09:24:11 CEST] <ubitux> the last funny thing i got wrt asm was with the ';' not being a start of comment in gas
[09:24:23 CEST] <ubitux> even though my editor was coloring the line as comment
[09:24:32 CEST] <ubitux> the asm was still assembled, and so running
[09:24:48 CEST] <ubitux> so i was "commenting" half of the asm, and it was still working
[09:29:24 CEST] <atomnuker> what is nasm doing interpreting an instruction and thinking you want a register, it wouldn't be valid
[09:32:33 CEST] <sinanksu> My code : ffmpeg -i "rtmpe : / / xxxxxx/xlive app=xlive swfUrl=http : / / xxxxxxx/VideoPlayer.swf  swfAge=5aaaa32059cba732636c28519b2ce34a3568f1058a8bd02d6a932643554ccbb4 swfVfy=1 swfSize=546447 pageUrl=http : / /xxxxxxx conn=S:client conn=S:3.1.0.10 conn=S:en live=1 playpath=raw:599773" -c copy "2017blablabla.flv"
[09:32:53 CEST] <sinanksu> Error Output : Unknown option swfSize
[09:32:53 CEST] <sinanksu> Valid RTMP options are:
[09:32:55 CEST] <rcombs> what prompted the switch off of yasm, anyway?
[09:33:33 CEST] <atomnuker> nasm is maintained
[09:39:49 CEST] <sinanksu> ?
[09:44:41 CEST] <rcombs> ah
[09:47:37 CEST] <atomnuker> sinanksu: no idea, this channel isn't for support, #ffmpeg is
[10:51:10 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:eaf644e120b3: avfilter: add acopy filter
[10:52:48 CEST] <kierank> 8:22 am <" atomnuker> what the fuck, it turns out it was because I had 2 arguments named "c" and "s"
[10:53:12 CEST] <kierank> You kinda deserve it then :)
[10:53:47 CEST] <atomnuker> I guess so
[10:54:03 CEST] <atomnuker> (since both were floats I just removed them from the namespace)
[11:12:13 CEST] <durandal_1707> what audio filters are we missing?
[11:22:28 CEST] <atomnuker> noise reduction
[11:22:58 CEST] <atomnuker> crackle suppresion
[11:44:19 CEST] <J_Darnley> Does ffmpeg's mailing lists have a way to ask it to send me a specific email?
[11:45:17 CEST] <durandal_1707> atomnuker: when you gonna write some audio filter?
[11:45:37 CEST] <BtbN> J_Darnley, I don't think so
[11:45:52 CEST] <BtbN> but it has an archive if you are looking for a specific thing
[11:47:35 CEST] <atomnuker> J_Darnley: send a patch to change -wN to -x and I'll LGTM it
[11:48:01 CEST] <atomnuker> (it annoyed me as well because I'm more interested in overall function performance rather than separate stages
[11:48:03 CEST] <J_Darnley> BtbN: That might have to do
[11:48:15 CEST] <atomnuker> durandal_1707: dunno, monday maybe
[11:48:22 CEST] <BtbN> pretty sure the archives have a link that you can click to reply to a mail
[11:48:53 CEST] <BtbN> yeah, they do, at the very top
[11:56:32 CEST] <Gramner> atomnuker: yeah, the error message from yasm/nasm aren't generally very helpful. it would be quite useful if it would just print the full preprocessed line that causes a problem
[11:59:47 CEST] <Gramner> at least you got an error message. I recently spent like 2 hours trying to debug why the hell a piece of code wasn't working only to realize that a data variable and a cpuflag- suffixed function had the same name , and the latter silently shadowed the former due to preproccesing definition trickery so I was using a random piece of code as a shuffle mask.
[12:00:59 CEST] <Gramner> I should do that intentionally somewhere just to screw with people and call it a size optimization
[12:26:28 CEST] <nevcairiel> if you can find a function that has the correct data pattern and still does something useful, that would be quite magical :D
[13:04:43 CEST] <durandal_1707> atomnuker: are you serious?
[13:06:36 CEST] <atomnuker> yeah, why not, I'll write the noise reduction one
[13:28:05 CEST] <durandal_1707> atomnuker: with wavelets?
[13:29:08 CEST] <atomnuker> no, I plan to go the FFT route
[13:29:37 CEST] <atomnuker> I'll wait until there are no huge changes in coefficients in between frames and use that as noise signature
[13:30:16 CEST] <atomnuker> then I'll just subtrack those coefficients off of any future frame
[13:30:58 CEST] <atomnuker> how would the wavelets method work with audio?
[13:41:57 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:df640dbbc949: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -17047030 cannot be represented in type 'int'
[13:41:58 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:c4c0245686bc: avcodec/g723_1dec: Fix runtime error: left shift of negative value -1
[13:41:59 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:f225003d1736: avcodec/texturedsp: Fix runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[13:44:45 CEST] <durandal_1707> atomnuker: soft and hard thresholding, i forgot almost everything about it
[14:48:52 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:d5711cb89121: avcodec/avcodec: Limit the number of side data elements per packet
[14:48:53 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:ccce2248bf56: avcodec/vp8dsp: vp7_luma_dc_wht_c: Fix multiple runtime error: signed integer overflow: -1366381240 + -1262413604 cannot be represented in type 'int'
[16:40:54 CEST] <kierank> J_Darnley: i would say submit an mmx yasm conversion
[16:40:57 CEST] <kierank> then do sse
[16:41:12 CEST] <kierank> and also ignore neckbeards who say it is 1% slower or whatever
[16:41:59 CEST] <J_Darnley> That's basically what I have done.
[16:42:20 CEST] <J_Darnley> The two sse2 functions at the bottom are from the original.
[16:42:29 CEST] <kierank> ah
[16:42:33 CEST] <kierank> what parts are WIP?
[16:43:04 CEST] <J_Darnley> Strictly, none of it.  It works just fine.
[16:44:24 CEST] <J_Darnley> I just don't expect to push the patch as submitted
[16:44:32 CEST] <J_Darnley> I'm working to see if there are speedups from using xmm instead of mmx
[16:45:21 CEST] <kierank> ok
[16:45:41 CEST] <kierank> talk to Gramner and BBB i guess
[16:46:13 CEST] <BBB> is this the simple_idct?
[16:46:18 CEST] <J_Darnley> yes
[16:46:19 CEST] <kierank> yup
[16:46:22 CEST] <BBB> right...
[16:46:27 CEST] <BBB> so that code is & crazy
[16:46:33 CEST] <BBB> like, I have no other words for it
[16:46:35 CEST] <BBB> its fast, sure
[16:46:37 CEST] <BBB> but its crazy
[16:46:56 CEST] <BBB> now, strictly speaking, it does a 2x2 4x4 subidct loop, right?
[16:47:00 CEST] <BBB> so you should be able to speed it up
[16:47:16 CEST] <BBB> just by ignoring the mmx code and writing a loopless full 8x8 idct
[16:47:19 CEST] <J_Darnley> I don't know what it does.  I haven't looked at the C version yet
[16:47:21 CEST] <BBB> maybe with a idct-only case
[16:47:23 CEST] <BBB> haha
[16:47:24 CEST] <BBB> :)
[16:47:26 CEST] <BBB> ok
[16:47:27 CEST] <BBB> so
[16:47:47 CEST] <BBB> want me to give a quick top-level hunnch?
[16:48:10 CEST] <J_Darnley> Yes if you're not busy
[16:48:14 CEST] <BBB> which may be totally wrong but nobody can confirm ot deny it since michaelni didnt remember and nobody else understands that code
[16:48:16 CEST] <BBB> so
[16:48:23 CEST] <BBB> the idct is in words
[16:48:27 CEST] <BBB> mmx registers are 8 byte
[16:48:32 CEST] <BBB> so hold 4 elements
[16:48:52 CEST] <BBB> the idct is 8x8
[16:49:05 CEST] <BBB> so that means you can only do half the 1d idct per register
[16:49:09 CEST] <BBB> right?
[16:49:26 CEST] <BBB> in addition, you have (since it was written for 32bit/mmx) only 8 registers
[16:49:40 CEST] <BBB> how do you speed it up? simple: sub-idcts
[16:49:43 CEST] <J_Darnley> Yeah, it moves in and out of memory a lot
[16:49:44 CEST] <BBB> vp9 does that also
[16:49:57 CEST] <BBB> so if only the top-4x4 coefs are non-zero
[16:50:06 CEST] <BBB> you can ignore the second half of the first 1d idct
[16:50:12 CEST] <BBB> and you can ignore half the multiplies etc. also
[16:50:19 CEST] <BBB> so thats why its fast
[16:50:31 CEST] <BBB> vp9 does that too, its crazy and nobody will understand 5 years from now
[16:50:36 CEST] <BBB> and then they will curse me
[16:50:37 CEST] <BBB> I apologize
[16:50:42 CEST] <BBB> but I wont remember
[16:50:45 CEST] <BBB> ;)
[16:50:46 CEST] <BBB> anyway
[16:50:54 CEST] <BBB> you can literally translate the asm in mmx/32bit as-is
[16:50:55 CEST] <BBB> thats fine
[16:51:04 CEST] <BBB> for 64bit/xmm, I would just rewrite it and ignore what exists
[16:51:18 CEST] <BBB> just rewrite the C as-is, 16 byte=8 elements per registers, assume you have 16 registers
[16:51:19 CEST] <BBB> its all fine
[16:51:24 CEST] <BBB> on 32bit, you can use the mmx one
[16:51:30 CEST] <BBB> no loop, etc.
[16:51:41 CEST] <BBB> the loop and 2 1ds are all unrolled in the mmx/32bit version youre seeing
[16:51:44 CEST] <BBB> thats why its so long
[16:51:58 CEST] <BBB> but it does amke it faster
[16:52:44 CEST] <BBB> also, thanks! so happy to see someone working on this
[16:53:42 CEST] <BBB> your indenting is off in some parts ;) </diego>
[16:54:20 CEST] <J_Darnley> Yeah, I plan a big whitespace fix too.
[16:54:42 CEST] Action: J_Darnley is afk
[16:54:47 CEST] <BBB> do you think we need a checkasm test for this?
[16:54:55 CEST] <BBB> would probably be somewhat useful for some tests
[17:39:12 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:9cd62b2ca49b: avfilter/vf_pad: revert part of 57c3670896c69714ca
[17:43:49 CEST] <cbsrobot> lol at the first few lines of http://ffmpeg.gusari.org/irclogs/2017/05/11/ffmpeg.log.20170511
[17:51:47 CEST] <wm4> sigh
[18:12:09 CEST] <BBB> cbsrobot: thats kinda brilliant :D
[18:15:34 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:e312ed0504c1: avfilter/af_astats: add RMS difference too
[18:31:57 CEST] <tdjones> I can't seem to find this in the docs, but what is the easiest way to execute a single set of FATE tests (a single makefile) rather than rerunning the entire suite?
[18:33:39 CEST] <J_Darnley> make fate-test-name for just 1
[18:33:59 CEST] <J_Darnley> I don't know about everything in a specific file
[18:34:26 CEST] <tdjones> That works, didn't know if by test name or file would be easier. Thanks!
[18:37:05 CEST] <J_Darnley> make fate-list will list all available tests
[18:37:38 CEST] <J_Darnley> Useful to grep for a specific term
[18:38:17 CEST] <J_Darnley> If I'm working on h264: make fate-list | egrep 'h264|avc' > fate-list-h264
[18:38:34 CEST] <J_Darnley> then make $(cat fate-list-h264)
[18:39:34 CEST] <tdjones> That's perfect, thank you.
[18:42:14 CEST] <RiCON> durandal_1707: doesn't that revert break the centering with aspect_ratio?
[18:42:50 CEST] <RiCON> ah, no, probably not
[19:09:36 CEST] <atomnuker> rcombs: lgtm'd flac picture writing patch, the bug was in my code
[19:26:26 CEST] <BtbN> Is there a better way to count CPU cycles a function uses than rdtsc? It seems to be independend of actual CPU cycles on modern CPUs.
[19:27:43 CEST] <nevcairiel> not really, no. it just gets rather noisy the bigger your functions are, so best is to measure small inner loops or s omething, where you know the cost is inside that function
[19:33:07 CEST] <tmm1> is anyone working on mediacodec encoders?
[19:36:39 CEST] <tmm1> mateo`: do you know?
[19:41:34 CEST] <atomnuker> BtbN: if you're trying to compare performance just use START/STOP_TIMER from libavutil/timer.h
[19:42:19 CEST] <BtbN> nah, roommate has a university task to win some competition to optimize a function with regard to CPU cycles.
[19:42:29 CEST] <BtbN> And some people are getting crazy low results that seem impossible.
[19:42:50 CEST] <BtbN> So we suspect that it's not truly measuring CPU cycles, which seems accurate.
[19:43:02 CEST] <alevinsn> it depends if the CPU has invariant TSC or not
[19:43:16 CEST] <alevinsn> modern Intel processors have invariant TSC
[19:43:22 CEST] <BtbN> Everyone runs the evaluation script on their own machine
[19:43:25 CEST] <alevinsn> but, there are also high performance timers
[19:43:28 CEST] <BtbN> and the results of that are then compared
[19:43:32 CEST] <BtbN> so the whole competition is flawed
[19:44:15 CEST] <BtbN> It also measures the "cycles" of like a million benchmark-runs
[19:48:23 CEST] <nevcairiel> we typically also measure as many runs as we can, on modern CPUs it can always decide to do something else =p
[19:48:49 CEST] <nevcairiel> anyhow such a "competition" should ultimately be measured on the same system
[19:50:05 CEST] <nevcairiel> a different cpu can already produce different cycle counts
[19:51:37 CEST] <BtbN> something weird we observed here on our machines: On his Haswell CPU, the average cycle count for his implementation is 35k, best case is 25k. On my Ryzen, the average is at 30k, but the best case is also 30k.
[19:55:28 CEST] <BtbN> In the competition some people have submited numbers below 10k "cycles" for the same computational task.
[20:15:24 CEST] <BtbN> can someone who is familiar with the configure/Makefile stuff review that nvcc patch? No idea who qualified there, hopefully someone.
[20:18:28 CEST] <J_Darnley> Oh no.  You people aren't adding cover writing to the flac muxer are you?
[20:20:40 CEST] <nevcairiel> sure are. why?
[20:21:15 CEST] <J_Darnley> I hate them and I hate how ffmpeg treats them as a video stream.
[20:29:04 CEST] <alevinsn> BtbN:  I glanced at the nvcc patch ("[PATCH 2/3] build: add support for building .cu files via nvcc")
[20:29:21 CEST] <alevinsn> BtbN:  I haven't tested anything, but it seems like it will be fine
[20:29:32 CEST] <alevinsn> nevcairiel is more of an expert on this though
[20:55:01 CEST] <durandal_1707> it should be attachement
[20:58:06 CEST] <jamrial> ideally, audio format muxers shouldn't try to mux any video stream they get as cover art, they all should look at the stream's disposition and discard stuff accordingly
[20:59:00 CEST] <jamrial> durandal_1707: no way to get stream info that way, which some formats like flac need for cover art
[21:27:40 CEST] <durandal_1707> amerge is flawed, i cant pick 7.1 channel layout from 8 channels somehow
[21:44:30 CEST] <durandal_1707> im thinking about removing all hw stuff in ffmpeg
[21:46:18 CEST] <durandal_1707> and forking
[21:49:25 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:c02921417b24: avfilter/aeval: free input frame on error
[21:49:26 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:3d55e4883c2a: avfilter/aeval: remove comment that was left from some other file
[23:31:07 CEST] <cone-423> ffmpeg 03James Almer 07master:28f60eeabbdc: avcodec/avpacket: allow only one element per type in packet side data
[23:41:20 CEST] <cone-423> ffmpeg 03Martin Vignali 07master:73ae60d7df04: libavcodec/exr : cosmetics variable name
[23:41:21 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:cb243972b121: avcodec/xpmdec: Fix multiple pointer/memory issues
[00:00:00 CEST] --- Sat May 13 2017