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

[burek]

[00:05:21 CEST] <ubitux> durandal_1707: yeah? can you share?
[00:07:41 CEST] <durandal_1707> ubitux: fast separable non-local means
[00:08:16 CEST] <ubitux> https://arxiv.org/pdf/1407.2343.pdf ok
[00:19:02 CEST] <jamrial> ubitux: you updated your fate clients and now valgrind complains about two tests that seemingly make no sense :p
[00:19:22 CEST] <jamrial> wonder if it's gcc 8.1.0 at fault, or something else like libc
[03:22:45 CEST] <cone-081> ffmpeg 03Jerome Borsboom 07master:fac584991597: avcodec/vc1: FIELDTX is only present in interlaced frame I/BI pictures
[03:22:45 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:56e76bd0579c: avformat/mov: Break out early if chunk_count is 0 in mov_build_index()
[03:22:45 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:2c2d689c5664: avformat/mov: Only fail for STCO/STSC contradictions if both exist
[12:46:18 CEST] <kierank> gagandeep: data is little endian I think
[12:46:24 CEST] <kierank> You are using big endian functions
[12:50:39 CEST] <gagandeep> kierank: fixed the table issue, they were implecitely converting uint8_t * buffer to int16_t * buffer and then adding offset to 16 bit buffer
[12:51:04 CEST] <kierank> Yes
[12:51:10 CEST] <gagandeep> just finallizing some stuff, i think i should be able to fix that last sample by today
[12:59:10 CEST] <kierank> gagandeep: cool
[12:59:13 CEST] <kierank> what else is left?
[12:59:33 CEST] <kierank> I also saw in the code that we do decompand sometimes on some codebooks where it's not necessary
[12:59:40 CEST] <kierank> there's a flag saying not to decompand
[13:15:31 CEST] <gagandeep> well, currently i am not decompanding when codebook 2 is used (same table but having different name and flag with decompanding not needed), that is taken care of
[13:16:03 CEST] <gagandeep> in lowpass decoding, an offset is added, i will confirm from where to get that and update that as well
[13:17:09 CEST] <gagandeep> kierank: i have directly access the bitstream buffer from getbytecontext, will that be alright?
[13:17:30 CEST] <kierank> yes
[13:17:35 CEST] <kierank> see how it's done for lowpass coeffs
[13:18:17 CEST] <gagandeep> in lowpass, i think you used function bytestream2_get_be but i am directly referencing the pointer to buffer for table
[13:18:35 CEST] <gagandeep> peak.base = gb.buffer
[13:18:59 CEST] <gagandeep> because they are not giving size of the peak table so i don't have other options
[13:19:52 CEST] <kierank> hmmm ok, a bit strange
[13:20:38 CEST] <gagandeep> yeah, i mean they have size in their struct in codec state but they dont have a tag value pair for that
[13:23:45 CEST] <kierank> I think they are using a trick that if the fsm decoder produces two coefficients then the second one MUST be small
[13:29:34 CEST] <gagandeep> yeah, well my peak_table values are matching now, just need to properly integrate it with the decoding of highpass bands
[13:29:39 CEST] <durandal_1707> atomnuker: i have anlmeans almost working, but can not understand why i get heavily distorted audio
[14:57:30 CEST] <durandal_1707> atomnuker: fine to apply mbedTLS ?
[15:01:24 CEST] <BBB> atomnuker: I have some basics in place now
[15:02:50 CEST] <durandal_1707> BBB: what basics?
[15:04:42 CEST] <gagandeep> kierank: what are chunks
[15:04:42 CEST] <durandal_1707> ugh, filter removes background noises just fine but does some strange distortion to voices
[15:05:26 CEST] <kierank> gagandeep: in what context
[15:06:42 CEST] <gagandeep> i think i will need to skip peak table when bitstream gets to it
[15:06:45 CEST] <gagandeep> don't you thin
[15:06:48 CEST] <gagandeep> *think
[15:07:15 CEST] <gagandeep> either the bitstream is at tag value pair or it is at subband data
[15:07:35 CEST] <gagandeep> but if it is at peak table, i think this is the last thing causing me trouble
[15:08:38 CEST] <gagandeep> there is a tag called chunk header for peak table, do you understand anything by this
[15:10:02 CEST] <gagandeep> also i am unable to catch this chunk tag = 0x4001 in cfhd
[15:11:19 CEST] <gagandeep> kierank: any thoughts
[15:14:01 CEST] <durandal_1707> gagandeep: searching for 0x4001 doesnt show anything? perhaps search for 0x0140 ?
[15:16:06 CEST] <gagandeep> could this tag 0x4001 be affected by the endian system?
[15:16:32 CEST] <nevcairiel> any value over 8-bit would
[15:18:49 CEST] <gagandeep> 0x0140 doesn't work, but let me see
[15:19:11 CEST] <gagandeep> but what are chunks, they are the data?
[15:54:32 CEST] <gagandeep> chunk data was already handled by kierank so need for me to fuss over that
[16:10:47 CEST] <gagandeep> kierank: finally last sample for interlacing fixed (i think)
[16:10:49 CEST] <gagandeep> https://imgur.com/a/KQ0a57H
[16:10:52 CEST] <gagandeep> ffmpeg output
[16:11:02 CEST] <gagandeep> will be sending patch later
[16:11:21 CEST] <kierank> Doesn't load on my phone (am roaming) but congtatulations
[16:11:28 CEST] <kierank> Does it match cineform bitstream
[16:12:54 CEST] <gagandeep> i'll check that, though, it wouldn't be strange for there to be some other offset at this point 
[16:14:00 CEST] <gagandeep> afk, going to eat now
[17:59:05 CEST] <atomnuker> durandal_1707: heavily distorted?
[17:59:30 CEST] <durandal_1707> atomnuker: i dunno what kind of convolution i need to do
[17:59:31 CEST] <atomnuker> BBB: neat, put it up on github if you're comfortable its good enough so we can get other interested people
[17:59:53 CEST] <BBB> j-b: ^^ :-p
[18:00:05 CEST] <atomnuker> durandal_1707: where does the distortion appear? in the high frequencies?
[18:00:26 CEST] <durandal_1707> should use FFT, but its not really useful because lavc FFT only knows about power of 2
[18:00:54 CEST] <durandal_1707> atomnuker: yes, big spikes in spetrogram
[18:03:36 CEST] <atomnuker> does it change/move with respect to the input?
[18:04:51 CEST] <durandal_1707> atomnuker: if voice appears it appears too, for only noise it is silent
[18:06:44 CEST] <atomnuker> what about for sine waves with different frequencies?
[18:15:32 CEST] <durandal_1707> havent tried, but this thing is slow
[18:24:11 CEST] <atomnuker> I think what's happening is the per-sample changes from the algorithm settle around a frequency
[18:40:23 CEST] <durandal_1707> atomnuker: see anl branch on github
[18:53:20 CEST] <atomnuker> BBB: I don't think he responds to pings on this channel, I think you need to pm him
[18:58:16 CEST] <BBB> hm...
[19:06:05 CEST] <JEEB> (32
[19:31:03 CEST] <j-b> BBB: yo (but not today)
[19:31:13 CEST] <BBB> ok
[19:31:54 CEST] <atomnuker> when then? when the spec hits 1.0?
[19:34:48 CEST] <JEEB> gagandeep: that looks nice ( ^_^)b
[19:35:09 CEST] <JEEB> good work with yer stuff, just make sure to check it against reference
[19:56:58 CEST] <gagandeep> fate?
[19:57:07 CEST] <gagandeep> yeah, will do that
[19:57:38 CEST] <durandal_1707> atomnuker: so have you looked it?
[19:57:41 CEST] <JEEB> no, I mean the reference decoder :) since I'm not sure if FATE tests non-working features, and FATE's references might be incorrect?
[19:59:05 CEST] <gagandeep> yeah, currently i will need to add the offset for lowpass decoding but that is also there for p frames, right now it looks nice, but is not completely accurate
[19:59:31 CEST] <gagandeep> though offset values are really small < 50
[20:12:23 CEST] <durandal_1707> so with FFT i would get O=NlogN instead of O=N^2 is that enough?
[20:50:05 CEST] <atomnuker> yep, that's much faster for high transform sizes
[20:51:01 CEST] <BBB> atomnuker: hm&
[20:51:53 CEST] <BBB> atomnuker: you know the reason :-p
[20:52:58 CEST] <durandal_1707> atomnuker: how much high sizes? 512-4096?
[20:54:51 CEST] <atomnuker> anything above small sizes (e.g. 128), N*N explodes very fast compared to N*log(N)
[20:55:39 CEST] <atomnuker> BBB: I don't actually, its something that whatever happens will have to end up public, might as well go public from the start
[21:06:59 CEST] <klaxa> if creating a thread fails, i should gracefully exit, correct? should this also impact already running threads and abort the whole program or only the operation that caused it?
[21:11:12 CEST] <JEEB> if threads fail that sounds pretty fatal
[21:12:25 CEST] <klaxa> well i mean i check the return value of pthread_create()
[21:12:33 CEST] <klaxa> and i have to do *something* with it :P
[21:15:22 CEST] <tmm1> in the context of a server, would be better to fail locally than blow up the entire process
[21:16:33 CEST] <klaxa> that would also be easier to implement as i don't have to communicate with other threads who's context is out of scope
[21:21:52 CEST] <cone-683> ffmpeg 03Aman Gupta 07master:64680fff3bcf: avformat/mpegts: rename variable to clarify meaning
[21:21:53 CEST] <cone-683> ffmpeg 03Aman Gupta 07master:fc2daf36f926: doc: remove AVStream private fields from APIchanges
[21:21:54 CEST] <cone-683> ffmpeg 03Aman Gupta 07master:70d25268c21c: avformat/mpegts: fix memory leak with merge_pmt_versions=1
[21:52:54 CEST] <atomnuker> lol, that camera motion patch
[21:53:20 CEST] <atomnuker> the spec is wtf
[22:20:48 CEST] <durandal_1707> atomnuker: first need to make it work without any convolution
[22:29:21 CEST] <kierank> durandal_1707: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/230353.html
[22:30:55 CEST] <durandal_1707> kierank: i didnt know that cfhd is deinterlacer
[22:31:07 CEST] <kierank> it isn't
[22:31:13 CEST] <kierank> I think he just made bad commit name
[22:32:31 CEST] <durandal_1707> it was, as JEEB would tell, sarcastic remark
[23:48:21 CEST] <cone-683> ffmpeg 03Mark Thompson 07master:ba7d1377e856: hwcontext: Add test for device creation and derivation
[00:00:00 CEST] --- Tue May 22 2018