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

[burek]

[01:02:37 CEST] <cone-315> ffmpeg 03Michael Niedermayer 07master:3a6a8f6ee1cb: avcodec/ffv1enc: fix bps for >8bit yuv when not explicitly set
[02:51:44 CEST] <cone-315> ffmpeg 03Michael Niedermayer 07master:08326e73a234: avcodec/jpeg2000dec: Continue decoding reslevels even when empty ones are encountered
[04:54:50 CEST] <rcombs> anyone know if Paul B Mahol (onemda) is on Freenode?
[04:58:00 CEST] <jamrial> yes, he's durandal_1707
[04:59:25 CEST] <rcombs> ah
[04:59:26 CEST] <rcombs> durandal_1707: ping
[05:00:09 CEST] <durandal_1707> listening
[05:02:13 CEST] <rcombs> so, apparently the 'SEEK' chunk in BFSTM is the equivalent to the ADPC chunk in BRSTM
[05:02:58 CEST] <rcombs> so I've removed a bunch of the extradata and related code from my BFSTM demuxer in favor of using that, but apparently I'm doing something quite wrong here
[05:03:51 CEST] <rcombs> I was hearing some small popping sounds at what seem to be packet boundaries before that change; now they've just gotten worse instead of going away like I was hoping they would
[05:04:04 CEST] <rcombs> mind taking a look?
[05:05:25 CEST] <rcombs> https://gist.github.com/d7cacaccf741c8eebfeb <-- also I added little-endian support for BCSTM (the 3DS variant [the only difference is endianness and the magic string])
[05:07:08 CEST] <durandal_1707> there are brstm files with adpcm but without adpc chunk, they are currently unsupported. I think bit-exact seeking is not possible at all even with adpc chunk
[05:08:06 CEST] <rcombs> vgstream doesn't seem to use it at all
[05:09:04 CEST] <durandal_1707> you hearing clicks when seeking or always?
[05:09:10 CEST] <rcombs> always
[05:09:49 CEST] <rcombs> not present in BRSTMs; before I made the SEEK change I assumed it was just part of the track as they were pretty quiet
[05:10:04 CEST] <rcombs> but after the change I'm pretty sure it's an error on my part
[05:12:24 CEST] <rcombs> samples at http://109.163.233.168/Wii%20U/Splatoon.rar
[05:25:09 CEST] <durandal_1707> perhaps seek table is used only when seeking, but that doesn't explain quiter clicks
[05:25:48 CEST] <rcombs> yeah :/
[05:26:14 CEST] <durandal_1707> I would try listening vgmstream decode and compare
[05:29:03 CEST] <rcombs> good plan
[05:30:06 CEST] <durandal_1707> maybe there is bcstm muxer code somewhere on web
[05:30:49 CEST] <durandal_1707> I'm sure encountered brstm one
[05:34:11 CEST] <jamrial> if bcstm is only used on WiiU games then i doubt it. there's no homebrew/modding scene for that console yet afaik, unlike the Wii
[05:34:22 CEST] <jamrial> so a muxer is pointless for the time being
[05:35:55 CEST] <rcombs> jamrial: BCSTM is for 3DS
[05:36:00 CEST] <rcombs> which does have a modding community
[05:36:03 CEST] <jamrial> oh, i see
[05:36:32 CEST] <rcombs> and AFAICT the only difference between BCSTM (3DS) and BFSTM (WiiU) is endianness and the magic string
[05:37:12 CEST] <rcombs> might actually change it to only 1 demuxer for both of those
[05:38:13 CEST] <rcombs> durandal_1707: hmm, vgmstream's output (piped to ffplay) sounds fine
[05:40:04 CEST] <durandal_1707> maybe their decoder does something different
[05:40:40 CEST] <rcombs> only appreciable difference I've seen is a ` + 1024`
[05:43:31 CEST] <rcombs> or& wait
[05:43:35 CEST] <durandal_1707> I think it doesn't use table at all for decoding, maybe that code caused clicks
[05:43:37 CEST] Action: rcombs traces things
[05:44:24 CEST] <rcombs> they do use the table from the INFO header; just not the initialization values from ADPC/SEEK
[05:46:20 CEST] <rcombs> they have better support for sample counts not divisible by 14, which I'm planning on fixing once I'm done with this stuff
[05:46:55 CEST] <rcombs> (just consuming the extra data silenced an error but now that I look closer it does indeed leave a few samples undecoded)
[05:50:06 CEST] <rcombs> there _is_ some extra data at the end of each channel in the last block that should be ignored
[05:50:14 CEST] <cone-315> ffmpeg 03Michael Niedermayer 07master:d1050d995061: ffmpeg: Free last_frame instead of just unref
[05:50:20 CEST] <durandal_1707> I would compare adpc with seek of same music from brawlcustommusic as they allow downloading in brstm, bfstm and bcstm
[05:53:49 CEST] <rcombs> looks like they always write SEEK tables entirely composed of 0s
[05:55:13 CEST] <durandal_1707> hmm so vgmstream doesnt have quiter clicks?
[05:55:49 CEST] <rcombs> lemme see
[05:56:30 CEST] <rcombs> with ffmpeg on the brawlcustommusic track I hear quiet clicks in both BFSTM and BRSTM
[05:57:13 CEST] <rcombs> none with vgmstream
[05:59:32 CEST] <rcombs> lemme try commenting the initialization code
[06:02:54 CEST] <rcombs> :/ I think it's something other than the ADPCM initialization
[06:03:28 CEST] <rcombs> with the initial samples (from the seek table) ignored, I'm still hearing quiet clicks in brawlcustommusic's BFSTM, but not their BRSTM
[06:24:42 CEST] <philipl> ubitux: Can you review Niklesh's latest changes?
[06:25:14 CEST] <philipl> I've been going over them with him by email so I think they're decent at this point, but extra eyes would be a lot of help.
[06:27:13 CEST] <rcombs> oh, btw, I actually do have a 10-channel sample
[06:27:24 CEST] <rcombs> it's quite obnoxious to actually play
[06:27:49 CEST] <rcombs> have to manually specify a channel layout
[06:29:53 CEST] <rcombs> and I think it's actually 5 variations on a 2-channel track
[07:42:59 CEST] <rcombs> durandal_170: turns out I was missing an extra 24-byte offset to the data start position that BFSTM has with ADPCM_THP for some reason
[07:57:23 CEST] <jamrial> rcombs: coeff tables maybe?
[07:59:08 CEST] <jamrial> ast (another format that supports that adpcm codec) has 24bytes per packet/frame storing that
[08:20:59 CEST] <rcombs> jamrial: it's just once, not per-packet
[08:21:06 CEST] <rcombs> and the coefficient tables are elsewhere
[08:22:05 CEST] <rcombs> maybe it's meant to store initial state values, but I read those out of the SEEK chunk now, and they're always 0 for the first packet in the samples I have
[09:57:29 CEST] <rcombs> michaelni: could you add http://puu.sh/iti0d/bcf75b6960.bcstm at fate-suite/bfstm/loz-mm-mikau.bcstm
[10:08:43 CEST] <rcombs> http://puu.sh/itijr/a27e2aab46.png why yes, Adobe, that _is_ the full set of your products that I'd be interested in right now
[10:23:26 CEST] <nevcairiel> it knows you so well
[10:31:25 CEST] <ubitux> philipl: ok
[10:37:40 CEST] <wm4> " 
[10:37:40 CEST] <wm4>  Could you add multithreading to FLAC encoding? Maybe, openCL would be help common users too. flaCCL, FlaCuda? are multithreaded and have better compression than that one of ffmpeg. Could you include them into ffmpeg?"
[10:37:42 CEST] <wm4> pain and misery
[10:38:46 CEST] <nevcairiel> does flac use inter-compression, or is every audio frame independent?
[10:38:47 CEST] <BtbN> A CUDA based encoder provides better compression, wat?
[10:39:18 CEST] <nevcairiel> if its independent, frame based encoding is probably even possible without too much of a hassle
[10:39:27 CEST] <nevcairiel> frame based mt-encoding that is
[10:39:28 CEST] <thardin> what, they have one huge wav they need flac encoded or something?
[10:39:32 CEST] <wm4> I know we actually have multithreaded decoding
[10:39:36 CEST] <wm4> for a few lossless codecs
[10:39:38 CEST] <wm4> durandal_170: ping
[10:40:03 CEST] <nevcairiel> we also have the frame thread encoder, which only does intra-only image formats
[10:40:09 CEST] <nevcairiel> but no reason it couldnt possibly do audio as well
[10:40:17 CEST] <thardin> because otherwise someone needs to tell them about xargs -P
[10:40:37 CEST] <thardin> or parallell
[10:41:06 CEST] <BtbN> Is the flac algorithm even easily parallelizable?
[10:41:26 CEST] <nevcairiel> well these flac opencl and cuda encoders are an actual thing
[10:41:26 CEST] <durandal_170> wm4: pong
[10:41:29 CEST] <nevcairiel> so maybe?
[10:41:43 CEST] <BtbN> Only Cuda, can't find an OpenCL one
[10:42:06 CEST] <BtbN> Oh, FlaCuda uses OpenCL
[10:42:09 CEST] <nevcairiel> BtbN: http://www.cuetools.net/wiki/FLACCL
[10:42:12 CEST] <nevcairiel> they renamed it later
[10:44:16 CEST] <nevcairiel> not sure how accurate these speed graphs still are, flac got a bunch of SIMD since then
[10:44:24 CEST] <nevcairiel> reference flac that is
[11:00:52 CEST] <durandal_170> flac and wavpack frame mt is possible, but I haven't yet looked how easy it would be to do
[11:08:56 CEST] <durandal_170> rcombs: are you writing patches for bfstm?
[11:09:12 CEST] <rcombs> durandal_170: just sent a pile of them
[11:12:12 CEST] <rcombs> clicking is fixed, seeking works, loop points work, BCSTM decoding works
[11:31:56 CEST] <rcombs> durandal_170: http://puu.sh/itlH7/4c27fbd954.bfstm
[11:35:19 CEST] <rcombs> durandal_170: and there are indeed files which the block size change fixes
[11:35:25 CEST] <michaelni> rcombs, added bfstm/loz-mm-mikau.bcstm
[11:35:32 CEST] <rcombs> michaelni: thanks
[11:39:58 CEST] <durandal_170> rcombs: but overflow is possible so block size check need updating
[11:40:07 CEST] <rcombs> yup, tweaking now
[12:22:50 CEST] <nevcairiel> 1 hour flac has been encoding for days on him? what kind of crap system is that? =P
[12:24:03 CEST] <xtemp09> 12-core Intel Xeon cluster
[12:24:25 CEST] <nevcairiel> every core running at 1mhz?
[12:24:34 CEST] <nevcairiel> encoding an 1-hour flac takes minutes at best
[12:24:48 CEST] <xtemp09> ffmpeg -i source.wav -lpc_passes 6 -lpc_type 3 -compression_level 9 -exact_rice_parameters 1 -multi_dim_quant 1 output.flac
[12:24:53 CEST] <xtemp09> that was the command
[12:25:01 CEST] <xtemp09> source.wav ~1 Gb
[12:25:09 CEST] <xtemp09> ~60 minutes long
[12:26:01 CEST] <nevcairiel> channels? sample rate?
[12:26:05 CEST] <xtemp09> 2.8 GHz 
[12:26:07 CEST] <xtemp09> Xeon
[12:26:22 CEST] <xtemp09> I'm not sure
[12:26:34 CEST] <xtemp09> about the channels
[12:34:01 CEST] <xtemp09> and sampling rate.
[12:37:14 CEST] <wm4> "Trac thinks your submission might be Spam."
[12:38:11 CEST] <nevcairiel> did you try to troll again
[12:38:55 CEST] <wm4> successfully, fflogger is just slow
[12:49:21 CEST] <cone-489> ffmpeg 03Shivraj Patil 07master:98eb1ac90127: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for qpel functions
[14:19:13 CEST] <rcombs> nobody apply my patch series just yet, I've got a few more changes to make
[14:52:29 CEST] <cone-489> ffmpeg 03Michael Niedermayer 07master:7b1c03aa744f: avcodec/libx264: Avoid reconfig on equivalent aspect ratios
[14:59:58 CEST] <durandal_170>  rcombs: clicks with bfstm that was not previously present
[15:00:28 CEST] <rcombs> durandal_170: yeah, it's due to reading the seek table :/
[15:00:57 CEST] <rcombs> so now I'm trying to work what the difference between the seek table and reality is
[15:01:15 CEST] <rcombs> funny part is, the ones in my BCSTM samples work fine
[15:02:30 CEST] <rcombs> there are some differences between the calculated values and the ones in the seek table for those as well, but they're minor
[15:03:24 CEST] <rcombs> whereas with the BFSTM samples they seem to be completely out-of-sync
[15:05:09 CEST] <rcombs> durandal_170: I'm using this to examine the differences between the calculated values and the ones from the seek/adpc chunk: https://gist.github.com/8ca74ca061dc8196d0f8
[15:08:27 CEST] <ubitux> i still have weird shit while trying to use ff vda; probably on my side, but it seems to be decoding the same frames all over again randomly (i have about 5 differents data checksum, appearing randomly)
[15:08:37 CEST] <ubitux> i think i disabled the threading properly, but maybe not
[15:09:15 CEST] <ubitux> i guess this symptom doesn't say anything to anyone?
[15:15:21 CEST] <ubitux> the pixbuf addresses changes though
[15:34:53 CEST] <ubitux> ok that's because i requested rgb32
[15:35:01 CEST] <ubitux> somehow it works with yuv
[15:35:14 CEST] <ubitux> maybe something is broken in ff, i need to check
[15:42:06 CEST] <nevcairiel> ff itself only requests native preferred formats
[15:42:15 CEST] <nevcairiel> Might be rgb problem.
[15:49:28 CEST] <ubitux> yeah
[15:49:38 CEST] <ubitux> it probably doesn't handle properly the !planar ones
[15:49:44 CEST] <ubitux> i'll investigate
[15:50:01 CEST] <ubitux> anyway, got it working :p
[17:51:10 CEST] <wm4> michaelni: does this ring a bell? "mjpeg: unsupported coding type (ca)"
[17:51:14 CEST] <wm4> michaelni: do you want a sample?
[17:51:50 CEST] <wm4> michaelni: well, if you do, it's here https://www.dropbox.com/s/ho62m5py3kqk4km/01%20-%20Cider%20Time.mp3?dl=1
[17:51:56 CEST] <wm4> (yep, it's the cover art picture)
[17:52:14 CEST] Action: Daemon404 barfg
[17:57:50 CEST] <alexvf> hi
[17:58:55 CEST] <alexvf> is there a way of calculating the expected audio dts/pts that does not need sample_rate and frame_size?
[17:59:44 CEST] <alexvf> i have a ts lacking pts for some audio packets and i don't have sample_rate or frame_size (they are equal to 0)
[18:01:10 CEST] <nevcairiel> Audio is trivial, after decoding you will know the exact length of the frame anyway
[18:01:21 CEST] <nevcairiel> So just interpolate with that
[18:01:54 CEST] <alexvf> but how, if i don't have sample_rate?
[18:04:44 CEST] <wm4> do it after decoding
[18:05:14 CEST] <nevcairiel> If you don't have sample rate after decoding then your audio is not usable for anything
[18:05:42 CEST] <kierank> it's like a video without knowing the resolution
[18:08:00 CEST] <alexvf> mmm, i understand
[18:08:25 CEST] <alexvf> the problem is that i need to interpolate in the demux
[18:08:37 CEST] <alexvf> and i would only get that information in the dcoder
[18:09:06 CEST] <kierank> then buffer one frame
[18:09:09 CEST] <wm4> why do you need to?
[18:09:51 CEST] <alexvf> one frame is not enough, in the sample video i have the pattern is 1 audio packet with pts, 5 without pts
[18:10:10 CEST] <kierank> it's an mpeg-ts?
[18:10:17 CEST] <alexvf> yep
[18:10:29 CEST] <kierank> you need to use a parser for that
[18:10:43 CEST] <kierank> that's what ffmpeg does
[18:12:02 CEST] <alexvf> do you mean the ffmpeg program?
[18:12:20 CEST] <alexvf> because i'm already using libavformat and libavcodec
[18:12:44 CEST] <Daemon404> if you are decoding anyway, why do you need packet timestamps
[18:12:48 CEST] <Daemon404> get the frame timestamp
[18:15:29 CEST] <alexvf> Daemon404: i guess i could, and now i'm wondering why do i need it in the demux ...
[18:15:52 CEST] <cone-489> ffmpeg 03Michael Niedermayer 07master:57078e4d255a: avcodec/hevc_ps: Only discard overread VPS if a previous is available
[18:26:45 CEST] <wm4> is there an avio discard protocol?
[18:27:12 CEST] <wm4> similar to writing to /dev/null
[18:34:38 CEST] <alexvf> Daemon404: the frame pts has no value, is that possible?
[18:39:21 CEST] <kierank> then you have to wait for one with a valid pts
[18:40:06 CEST] <Daemon404> there is also av best effort timestamp
[18:40:07 CEST] <Daemon404> or w/e
[18:40:09 CEST] <Daemon404> this is what teh cli uses.
[18:41:29 CEST] Action: alexvf wonders how vlc plays this damn file ...
[18:41:44 CEST] <wm4> uh
[18:41:49 CEST] <wm4> missing audio timestamps are not hard
[18:42:01 CEST] <wm4> and in this case, you interpolate the missing PTS
[18:42:04 CEST] <wm4> after decoding
[18:42:15 CEST] <wm4> which is trivial, because you have the samplerate and sample count
[18:43:45 CEST] <alexvf> then, why libavcodec cannot do it? i'm getting no pts even after decoding and it supposedly has all that info
[18:45:29 CEST] <kierank> mpegts allows this
[18:46:24 CEST] <alexvf> i read somewhere that it allows intervals of 700ms could it be?
[18:46:28 CEST] <Daemon404> im thinking he wants to know why lavc doesnt interpolate for him.
[18:46:53 CEST] <alexvf> but i never found such a file
[18:48:21 CEST] <cone-489> ffmpeg 03Michael Niedermayer 07master:622f1468c92c: avformat/id3v2: detect PNG by header instead of mime
[18:48:49 CEST] <wm4> alexvf: libavcodec doesn't mess with timestamps, and shouldn'r
[18:48:53 CEST] <wm4> *shouldn't
[18:49:37 CEST] <alexvf> ok, it's fine but i'm definetely doing something wrong because even av_frame_get_best_effort_timestamp() return no pts
[18:49:45 CEST] <wm4> michaelni: can you apply this patch I wrote for stripping spaces from id3v2 cover art picture descriptions? a user keeps bothering me about it
[18:49:47 CEST] <Daemon404> wm4, yeah that's lavf's job
[18:49:48 CEST] Action: Daemon404 runs
[18:49:53 CEST] Action: wm4 stabs Daemon404 
[18:50:09 CEST] <wm4> alexvf: no, it's not wrong
[18:50:12 CEST] <wm4> alexvf: that's your job
[18:50:21 CEST] <wm4> it comes with libavcodec being a low level API and all
[18:51:16 CEST] <alexvf> wm4: yep, i meant i may be doing it wrong, because vlc can play this file and my program can't ;)
[18:52:04 CEST] <wm4> alexvf: well, just interpolate the timestamps and you should be fine
[18:52:36 CEST] <alexvf> time to dive into vlc code, thank you for the help guys
[18:55:28 CEST] <kierank> vlc has it's own demux
[18:55:33 CEST] <kierank> and parser/framer
[18:55:36 CEST] <kierank> that does all that
[18:55:38 CEST] <wm4> I'm not sure if the vlc code is the best to learn from, its lavc usage tends to be overcomplicated
[18:56:16 CEST] <wm4> looking at ffplay.c might be better, although ffplay.c is awful (all over the place)
[19:07:37 CEST] <lglinskih> kierank: I'm stuck on the stage of computing framecrc of a frame. Muxer framecrc works with a packet, I have a frame. Is it better to write my own function which works with frames?
[19:14:30 CEST] <michaelni> lglinskih, you dont need to implement something bitexactly identical to framecrc
[19:14:52 CEST] <michaelni> any reasonable checksum should be fine
[19:16:37 CEST] <cone-489> ffmpeg 03wm4 07master:d4007d176313: id3v2: strip trailing spaces from APIC tag
[19:18:05 CEST] <michaelni> lglinskih, you can use av_image_get_linesize() to find the number of "active" bytes in a line for an image
[19:23:21 CEST] <michaelni> lglinskih, it might be easier to use av_image_copy_to_buffer() then av_image_get_linesize()
[19:24:30 CEST] <michaelni> that should give you a byte array that you can then easily apply any checksum function  too
[19:24:33 CEST] <michaelni> to
[19:28:27 CEST] <lglinskih> michaelni: ok, thanks! and is it okay to use av_adler32_update for checksum?
[19:28:37 CEST] <michaelni> should be ok
[19:34:39 CEST] <wm4> michaelni: heh, thanks
[21:05:19 CEST] <wm4> michaelni: can you make a fast 2.7.1 release with my gnutls fix for disconnecting correctly included?
[21:05:43 CEST] <wm4> this breaks anything that wants to seek with https and if gnutls is used
[21:12:01 CEST] <michaelni> i need to do a 2.2 release,ill look at 2.7 after that
[21:13:42 CEST] <michaelni> wm4,  the commit to port is 2222f419da99ef85d49ab04e7e15b76612f4d054 ?
[21:14:26 CEST] <wm4> michaelni: correct
[21:17:08 CEST] <cone-489> ffmpeg 03wm4 07n2.2.16:HEAD: id3v2: strip trailing spaces from APIC tag
[21:27:16 CEST] <jamrial> michaelni: softfloat.h is not an installed header. is that intended?
[21:27:23 CEST] <jamrial> all its functions use the av_ prefix
[21:33:22 CEST] <michaelni> if people want to use it from outside or want it to be available to the outside then it can be made an installed header
[21:33:35 CEST] <michaelni> i think its not installed atm as nothing uses it
[21:40:16 CEST] <cone-489> ffmpeg 03James Almer 07release/2.7:3b6aeb148b1d: avformat/singlejpeg: fix standalone compilation
[22:18:20 CEST] <cone-489> ffmpeg 03Michael Niedermayer 07release/2.7:965f96c5ed44: ffmpeg_opt: Check for localtime() failure
[22:18:21 CEST] <cone-489> ffmpeg 03Andreas Cadhalpun 07release/2.7:ed5041143edb: configure: only disable VSX for !ppc64el
[22:18:22 CEST] <cone-489> ffmpeg 03Andreas Cadhalpun 07release/2.7:265db4154097: doc: fix spelling errors
[22:18:23 CEST] <cone-489> ffmpeg 03Andreas Cadhalpun 07release/2.7:3ba55ea4aec2: h264: er: Copy from the previous reference only if compatible
[22:18:24 CEST] <cone-489> ffmpeg 03Andreas Cadhalpun 07release/2.7:8a24ccfee384: examples/demuxing_decoding: use properties from frame instead of video_dec_ctx
[22:18:25 CEST] <cone-489> ffmpeg 03wm4 07release/2.7:9473e5a05d2c: avio: fix potential crashes when combining ffio_ensure_seekback + crc
[22:18:26 CEST] <cone-489> ffmpeg 03Michael Niedermayer 07release/2.7:08fadda68aeb: avcodec/ffv1enc: fix bps for >8bit yuv when not explicitly set
[22:18:27 CEST] <cone-489> ffmpeg 03Michael Niedermayer 07release/2.7:e04ae11fa06a: ffmpeg: Free last_frame instead of just unref
[22:18:28 CEST] <cone-489> ffmpeg 03Michael Niedermayer 07release/2.7:6432f8826dd1: avcodec/hevc_ps: Only discard overread VPS if a previous is available
[22:18:29 CEST] <cone-489> ffmpeg 03wm4 07release/2.7:c3c8365dbd3b: tls_gnutls: fix hang on disconnection
[22:34:54 CEST] <kierank> lglinskih: sorry was on a train
[22:34:58 CEST] <kierank> but i think michaelni helped you
[22:38:23 CEST] <BBB> is anyone interested in a patch that changes tiny_ssim to become lavf based?
[22:38:38 CEST] <BBB> its a bit hacky so its not exactly ready, but maybe others want to finish it up
[22:38:55 CEST] <BBB> (i was getting fed up with having to use pipes every time I want to compare two files that are not raw yuv)
[22:39:36 CEST] <durandal_1707> You mean lavfi based?
[22:39:41 CEST] <BBB> no, lavf
[22:39:57 CEST] <BBB> it doesnt fopen() two yuv inputs
[22:40:06 CEST] <BBB> it avformat_open_input()s two inputs
[22:40:15 CEST] <BBB> is basically what the patch does
[22:40:16 CEST] <durandal_1707> hack hack hack
[22:40:20 CEST] <BBB> why?
[22:40:28 CEST] <BBB> open two files, read/decode frames, ssim them
[22:40:31 CEST] <BBB> hows that hack?
[22:41:06 CEST] <durandal_1707> it should be in lavfi.
[22:41:13 CEST] <BBB> what part?
[22:41:15 CEST] <BBB> and why?
[22:41:58 CEST] <durandal_1707> it duplicates read/decode code
[22:42:26 CEST] <BBB> it uses public api
[22:42:29 CEST] <BBB> thats a hack nowaday?
[22:42:44 CEST] <nevcairiel> Don't listen to him
[22:43:23 CEST] <nevcairiel> Can you make it stay compatible with old calling syntax?
[22:45:10 CEST] <BBB> it used to be tiny_ssim a.yuv b.yuv widthxheight
[22:45:17 CEST] <BBB> now its tiny_ssim a.y4m b.mkv
[22:45:27 CEST] <BBB> (an widthxheight is implied by the inputs)
[22:45:37 CEST] <BBB> so the syntax is a little different
[22:45:48 CEST] <BBB> I didnt add support for specifying raw yuv parameters yet, probably should
[22:46:01 CEST] <BBB> (like tiny_ssim -size withxheight a.yuv b.mkv)
[22:46:45 CEST] <nevcairiel> Just trying to preserve syntax for peoples scripts might be useful
[22:46:47 CEST] <nevcairiel> So that previous commands for yuv files still wofk
[22:46:54 CEST] <BBB> I might just make it a new utility then
[22:46:56 CEST] <BBB> like tiny_ssim_2
[22:47:07 CEST] <durandal_1707> You will need to maintain it whenever API changes
[22:47:31 CEST] <nevcairiel> It's a good check for not breaking public api too often :P
[22:47:38 CEST] <durandal_1707> With lavfi you leave it to others 
[22:47:48 CEST] <nevcairiel> It doesn't belong in lavfi
[22:48:08 CEST] <durandal_1707> It does.
[22:48:44 CEST] <BBB> I dont even know what you guys are talking about
[22:48:47 CEST] <BBB> what belongs in lavfi?
[22:48:53 CEST] <BBB> calculating the ssim between two inputs?
[22:48:56 CEST] <durandal_1707> But I will not object lavf one
[22:49:29 CEST] <nevcairiel> Putting it there would be the hack, instead of creating a couple lines of standalone tool for testing purposes
[22:50:19 CEST] <durandal_1707> use ffmpeg for everything
[22:50:52 CEST] <jamrial> changing tiny_ssim to support opening formats that are not raw yuv is certainly lavf territory, not lavfi
[22:52:58 CEST] <durandal_1707> qt-fastdstart is slower than ffmpeg
[22:55:36 CEST] <durandal_1707> do tell^
[22:55:55 CEST] <wm4> lol ffmpeg devs afraid of using their own API, because the API could change
[22:56:17 CEST] <durandal_1707> huh
[22:57:15 CEST] <gchristensen> Hi there, it is possible I could donate infrastructure to ffmpeg, including build infrastructure farms, or websites, etc. I'm pretty flexible. it would be on behalf of the company I work for. Who should I talk to, what would be most beneficial, etc ..?
[22:57:27 CEST] <gchristensen> website hosting*
[22:57:54 CEST] <nevcairiel> Like I said, don't listen to that guy, "use ffmpeg for everything" is what's wrong woth any devs attitude :p
[22:58:13 CEST] <nevcairiel> with many*
[22:58:36 CEST] <durandal_1707> you are nightmare
[22:58:45 CEST] <gchristensen> my co has a fairly advanced and capable build farm infrastructure which might be particularly interesting, but again  -- just looking to contribute.
[22:59:20 CEST] <durandal_1707> michaelni ^
[23:00:48 CEST] <ubitux> gchristensen: first easy thing would be to provide fate instances (see http://fate.ffmpeg.org/ and https://ffmpeg.org/fate.html) with various exotic configuration/hw/toolchain/...
[23:01:34 CEST] <ubitux> gchristensen: then i think we looked at moving to a new server a while back; even though it seems mostly sysadmin blocked, michaelni can probably tell you more about this
[23:01:44 CEST] <ubitux> or beastd, but he isn't connected right now
[23:01:51 CEST] <ubitux> and thanks a lot for the proposition
[23:02:05 CEST] <michaelni> most stuff is already moved to the new server
[23:03:04 CEST] <michaelni> faster/more powerfull  computers for developers who want/need more powerfull hw might be useful
[23:03:27 CEST] <michaelni> also we need a slave name server that isnt in .hu
[23:03:31 CEST] <ubitux> BBB: i agree with durandal_1707 that you should probably just abstract all the formats & codecs layers by just adding a filter; i think there is even a vf_psnr already
[23:04:26 CEST] <BBB> Im still not sure I understand how I would use it
[23:04:34 CEST] <ubitux> just like vf_psnr?
[23:04:39 CEST] <BBB> like, right now, I have this tool thats a few lines of change and I call it as tiny_ssim a.y4m b.mkv
[23:04:42 CEST] <BBB> how would vf_ssim work?
[23:04:45 CEST] <BBB> I really have no idea
[23:04:53 CEST] <nevcairiel> lavfi sucks for such stuff
[23:04:57 CEST] <ubitux> https://ffmpeg.org/ffmpeg-filters.html#psnr
[23:05:27 CEST] <nevcairiel> The syntax to use it would be a 100x more complicated than tiny_ssim now
[23:05:51 CEST] <ubitux> yes maybe the interface is not great
[23:05:53 CEST] <wm4> heh
[23:06:24 CEST] <durandal_1707> pick whatever you prefer I plan to add vf_swim anyway, haters gona hate
[23:06:31 CEST] <nevcairiel> Learn from linux and produce small usable tools
[23:06:41 CEST] <ubitux> like systemd?
[23:06:59 CEST] Action: JEEBsv quickly hides the go-systemd tab from his browser
[23:07:07 CEST] <durandal_1707> :)
[23:08:09 CEST] <durandal_1707> Stupid android spellchecker,can it be disabled?
[23:10:44 CEST] <cone-489> ffmpeg 03wm4 07master:f6c3f1ed6048: avformat: clarify what package needs to be compiled with SSL support
[23:11:00 CEST] <gchristensen> sorry for being AFK for a minute there. so 1. I can provide fate instances. how do those get triggered, or would it be on a cron, or would it be on commit? what config /hw / toolchain would be considered exotic? this would be very easy for me to set up.I may be able to provide access to an AWS account with a limited budget that ffmpeg could do anything they wanted (budget-limited) which could include
[23:11:02 CEST] <gchristensen> dev machines or slave DNS
[23:11:06 CEST] <gchristensen> ubitux / michaelni ^
[23:11:38 CEST] <jamrial> durandal_1707: in "language and input" or such, i guess
[23:12:01 CEST] <ubitux> gchristensen: the trigger is generally up to the user (see the 2nd link for how to setup)
[23:12:12 CEST] <ubitux> gchristensen: exotic is something you can't find on the first link
[23:12:45 CEST] <ubitux> so, weird compiler, weird arch, weird OS, ...
[23:13:11 CEST] <ubitux> or just weird ffmpeg configuration, new crazy static analyzer, efficient thread analysis tool, ...
[23:13:13 CEST] <ubitux> that kind of stuff
[23:13:18 CEST] <jamrial> or not necessarely weird but not currently covered
[23:13:53 CEST] <jamrial> like for example, old compiler versions tend to be dropped pretty fast. there are almost no gcc 4.9 clients ever since you moved to gcc 5 :p
[23:14:24 CEST] <ubitux> :)
[23:14:35 CEST] <ubitux> bleeding edge ftw
[23:14:36 CEST] <gchristensen> so this all seems fine, I can run it across a variety of configurations. is there any obvious, pressing configuration that would be a great first start?
[23:15:57 CEST] <ubitux> i can't think of any right now... maybe we can ask cehoyos, he generally suggests some build configuration
[23:16:07 CEST] <jamrial> hi kurosu
[23:16:32 CEST] <ubitux> gchristensen: you might want to send a mail to ffmpeg-devel to reach more people
[23:17:43 CEST] <kurosu> Hi James & all
[23:17:47 CEST] <gchristensen> can-do
[23:21:00 CEST] <michaelni> tickets related to fate: (that is also some missing fate clients), also feel free to add more tickets if you know of other missing cases https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~fate&col=id&col=summary&col=status&col=type&col=component&col=version&col=time&col=changetime&report=1&order=priority
[23:23:48 CEST] <jamrial> i'm personally running a gcc trunk client to catch compiler bugs early and avoid another fiasco like gcc 4.9.0
[23:26:01 CEST] <nevcairiel> f'ing SDL, why does it force building in GUI mode just by linking in its libraries
[23:26:46 CEST] <wm4> just don't link sdl
[23:27:01 CEST] <nevcairiel> thats the easy way out =p
[23:27:10 CEST] <nevcairiel> but its annoying if you want ffplay to test things
[23:27:22 CEST] <jamrial> it's the "-Dmain=SDL_main" addition to CFLAGS what breaks things
[23:29:21 CEST] <jamrial> doesn't seem to break ffmpeg or ffprobe, but it does break the stuff inside the tools/ folder and the "-test" executables from lavc/lavu
[00:00:00 CEST] --- Fri Jun 19 2015