[00:02:01 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07master:5d0b69f3b7e5: avcodec/jpeg2000dec: Fix h/vden typo [00:50:37 CEST] <atomnuker> michaelni: take a look at CID1415718, this looks alot like a false positive but I'm not sure [00:51:49 CEST] <atomnuker> nevermind, its not [00:56:18 CEST] <cone-864> ffmpeg 03Rostislav Pehlivanov 07master:133dafe24fc7: pngdec: fix potential memory leak [00:57:55 CEST] <atomnuker> COVERITY YOU PIECE OF SHIT [00:58:18 CEST] <atomnuker> last commit fixes CID1415718, not the one in the comment [00:59:01 CEST] <atomnuker> whoever designed the interface can burn in their own special excel-styled hell [01:00:45 CEST] <atomnuker> going on their crappy website is 99.9% of the work one has to do to mark a bug as fixed [01:02:23 CEST] <atomnuker> if they didn't have email notifications I wouldn't be able to fix anything because seeing all issues at once is impossible [01:03:56 CEST] <atomnuker> I did it once I think, I think I had to prove riemann's hypothesis and then once I viewed all I had to be brainwashed to forget the solution [01:26:43 CEST] <BBB> lol [01:26:52 CEST] <BBB> atomnuker: calm down dude [01:26:56 CEST] <BBB> theres worse things in the world [01:27:04 CEST] <BBB> I know thats a poor mans defense [01:27:06 CEST] <BBB> but its okay [02:26:45 CEST] <philipl> jkqxz: Care to comment on the thread with Yogenda (nvidia guy) about automatically adding hwupload to a filter chain? [02:44:59 CEST] <atomnuker> I'm trying to benchmark vgatherqps [02:45:10 CEST] <atomnuker> vgatherqps m3, [inq+m5], m15 <- how does addressing work here? [02:45:24 CEST] <atomnuker> do I fill m5 with indices [03:07:57 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07master:296debd213bd: avcodec/dnxhddec: Move mb height check out of non hr branch [03:52:25 CEST] <cone-864> ffmpeg 03Vodyannikov Aleksandr 07release/3.3:20c440edbc89: avcodec/cfhd: Fix decoding regression due to height check [03:52:26 CEST] <cone-864> ffmpeg 03Brice Waegeneire 07release/3.3:4627033a236c: doc/filters: typo in frei0r [03:52:27 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:f10252e47d81: avcodec/dirac_vlc: Fix undefined shift [03:52:28 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:a930db5c8299: avcodec/aacdec_fixed: fix: left shift of negative value -1 [03:52:29 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:b44a3cd06e22: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20() [03:52:30 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:b120685dcae9: avcodec/ylc: Fix shift overflow [03:52:31 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:a9081b36f4d2: avformat/oggparsecelt: Do not re-allocate os->private [03:52:32 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:2f75ebe24a77: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2 [03:52:33 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:47c0626ec721: avcodec/dnxhddec: Move mb height check out of non hr branch [04:19:29 CEST] <atomnuker> ...why does x86asm not warn about missing RETs [04:23:48 CEST] <jamrial> how would it? [04:28:00 CEST] <atomnuker> good point [04:55:44 CEST] <FishPencil_> I'm curious why Clément BSsch (ubitux) rewrote the nlmeans filter when Dirk Farin had already written one https://github.com/farindk/ffmpeg [04:57:50 CEST] <jamrial> was that ever sent to the ml? [04:59:16 CEST] <FishPencil_> I don't think so, but it's GPL so why not just bring it in [04:59:58 CEST] <jamrial> well, if it was never sent to the ml, there was no way to know it was written at all [05:00:13 CEST] <jamrial> and the current filter in the tree is lgpl [05:00:27 CEST] <FishPencil_> I see [05:02:33 CEST] <FishPencil_> ubitux: just reading the code, it doesn't look like it handles multiple images across threads? [05:47:07 CEST] <FishPencil_> Is there any better quality denoising algorthm than NLMeans (in FFmpeg or not). [05:50:25 CEST] <atomnuker> dctdnoiz, hqdn3d, owdenoise, vaguedenoiser, atadenoise [05:51:05 CEST] <atomnuker> no idea which one is the best, but I bet they all have their pros and cons for a given source [05:56:48 CEST] <FishPencil_> atomnuker: There's a lot to suggest that nlmeans is the best quality denoiser, as slow as it is. It's getting older now though, so I'm curious if there's anything new/better [07:45:11 CEST] <ubitux> FishPencil_: hi [07:45:37 CEST] <ubitux> FishPencil_: nlmeans supports slice threading; there is no such thing as frame filtering with lavfi currently [07:46:48 CEST] <ubitux> reasons for writing one: Dirk Farin never submitted the patch, LGPL vs GPL, and i wanted to understand how that filter worked [07:47:46 CEST] <ubitux> i need to write some SIMD for the integral at some point, but feel free to compare speed and efficiency [07:50:13 CEST] <ubitux> atomnuker: pretty sure nlmeans is one of the best; dctdnoiz is more an experiment, hqdn3d and owdenoise mostly target real time [07:50:34 CEST] <ubitux> can't comment on the other two, but nlmeans is a reference [07:50:58 CEST] <ubitux> most "new gen" filters rely on nlmeans logic one way or another [07:57:46 CEST] <ubitux> you may want to check removegrain and nnedi though [07:58:08 CEST] <ubitux> wait no, nnedi is not a denoiser [07:58:16 CEST] <ubitux> which one i had in mind... [07:58:29 CEST] <ubitux> well, whatever [07:58:35 CEST] <atomnuker> nlmeans is spatial domain, interest = lost [07:59:24 CEST] <ubitux> it can be extended to time domain [07:59:35 CEST] <atomnuker> yeah but not the frequency domain [08:00:16 CEST] <ubitux> as long as it's more efficient, who cares? :) [08:02:40 CEST] <atomnuker> dctdnoiz looks great, I should play with it some day [08:03:53 CEST] <ubitux> it's just one of those slow bluring filters ;) [08:05:10 CEST] <ubitux> atomnuker: you may be interested in https://github.com/ubitux/dct [08:05:52 CEST] <ubitux> (that's the code used to generate the dctdnoiz code) [08:06:30 CEST] <atomnuker> heh, the daala guys made one too though theirs is fixed-point [08:06:56 CEST] <ubitux> yeah, it should be made fixed point now ;) [08:07:10 CEST] <ubitux> so we can at least test it with fate properly [08:09:37 CEST] <atomnuker> why are intel not improving the horizontal functions [08:09:54 CEST] <atomnuker> I want an haddsubps/hsubaddps [08:10:15 CEST] <nevcairiel> probably because their use is very limited, and implementation complex [08:10:57 CEST] <atomnuker> butterflies are very common :/ [08:11:51 CEST] <stevenliu> Clément is ubitux? [08:15:10 CEST] <stevenliu> the edc43c571d in libav is return AVERROR(EIO) in ffmpeg is AVERROR(EINVAL) , dose ffmpeg must use EIO? i think the EINVAL maybe better [08:15:43 CEST] <stevenliu> or ffmpeg must copy or merge all things from libav? [08:19:06 CEST] <nevcairiel> it doesnt have to be exactly the same, if we can improve something we should [08:36:35 CEST] <ubitux> stevenliu: you need to reference the 5caaa3a49e76b084ff8a9840d541bad64d96d7f7 hash in your commit description [08:36:40 CEST] <ubitux> because that's what matters [08:46:51 CEST] <stevenliu> Then, What should i do next step? [08:47:38 CEST] <stevenliu> modify the return AVERROR(EINVAL); to return AVERROR(EIO); ? [08:47:45 CEST] <stevenliu> and fix the documentation? [08:56:26 CEST] <cone-028> ffmpeg 03Tobias Rapp 07master:60008c0fe94b: fate: update pixfmt_best test to check for endianness [09:16:06 CEST] <stevenliu> ubitux: Can you give me some express point? about next step? [09:17:00 CEST] <stevenliu> the options has implement at hlsenc of ffmpeg. [11:49:09 CEST] <j-b> Any good samples to test 601 or 709? [11:54:27 CEST] <ubitux> smptebars and smptehdbars? [11:54:38 CEST] <ubitux> (source filters) [11:58:28 CEST] <J_Darnley> atomnuker: I have (yet another) question about vc2. It is specific this time. [11:58:49 CEST] <J_Darnley> ... just a mo [12:00:00 CEST] <atomnuker> ment? [12:00:33 CEST] <J_Darnley> yes [12:00:36 CEST] <J_Darnley> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vc2enc_dwt.c#L166 [12:00:49 CEST] <J_Darnley> Is this line handling the edge of the picture? [12:01:56 CEST] <atomnuker> it looks like it does [12:02:26 CEST] <J_Darnley> Okay, thank you. [12:03:03 CEST] <ubitux> j-b: ffmpeg -lavfi smptehdbars=d=5 -y -c:v libx264 -pix_fmt yuv444p -colorspace bt709 -color_trc bt709 /tmp/bt709.mkv [12:03:06 CEST] <ubitux> maybe? [12:04:36 CEST] <ubitux> then smptebars, bt470bg etc, i guess [12:05:11 CEST] <J_Darnley> atomnuker: do you also think that the next line (just under "lifting stange 1") is handling the other edge? [12:05:18 CEST] <J_Darnley> *stage [12:06:34 CEST] <atomnuker> yeah, looks like that ones does the left side of the image [12:09:47 CEST] <J_Darnley> thank you again [12:09:52 CEST] <stevenliu> ubitux: [12:10:27 CEST] <ubitux> stevenliu: sorry, missed your messages [12:10:30 CEST] <ubitux> just a sec [12:10:37 CEST] <stevenliu> :-) [12:14:36 CEST] <ubitux> stevenliu: AVERROR(EIO) may be better [12:14:39 CEST] <ubitux> what do you think? [12:14:54 CEST] <ubitux> about the doc, it seems the options are documented [12:15:05 CEST] <ubitux> i'm not familiar with hlsenc: you are maintaining that code [12:15:20 CEST] <ubitux> so if you think it has everything from libav, that's good [12:15:25 CEST] <ubitux> just reference the hashes in the commit [12:15:37 CEST] <ubitux> so typically, you reference 5caaa3a49e76b084ff8a9840d541bad64d96d7f7 [12:18:15 CEST] <stevenliu> I think it maybe invalid with openssl, so that is EINVAL, then i have not modify it to EIO, i think EIO maybe a fatal error, for example file broke or device broke, Let me check the suggestion, do you mean i need add one line in the commit comment: reference the commit id: 5caaa3a49e76b084ff8a9840d541bad64d96d7f7 [12:18:53 CEST] <ubitux> yes [12:19:23 CEST] <stevenliu> Thank you, i modify the patch :D [12:19:23 CEST] <ubitux> just "See 5caaa3a49e76b084ff8a9840d541bad64d96d7f7." should be enough [12:19:29 CEST] <stevenliu> ok [14:25:20 CEST] <FishPencil_> ubitux: BM3D is another high quality one, but it's implementations are limited due to licensing I believe [15:24:40 CEST] <cone-932> ffmpeg 03Paul B Mahol 07master:9835ee60da31: avcodec/dnxhdenc: enable frame threading [19:23:00 CEST] <cone-932> ffmpeg 03James Almer 07master:9f449227a3ad: doc/APIChanges: add missing entry for ICC Profile side data type. [21:28:45 CEST] <tdjones> I'm having serious difficulty on detminging the cause of clipping in the vorbis encoder. Making it more difficult for the encoder to switch frame types seems to have no effect [21:29:44 CEST] <tdjones> determining* [21:30:42 CEST] <tdjones> I can remove most of the clicking at normal quality levels, but once I drop the quality, it quickly gets much worse [21:39:36 CEST] <atomnuker> tdjones: actually maybe I was wrong and it wasn't transient->nontransient switching which was the issue [21:39:58 CEST] <atomnuker> well it was, but to solve it correctly you wouldn't need to do limiting yourself [21:40:20 CEST] <atomnuker> rather the rate control system should based on the rate determine if a transient is possible [21:40:32 CEST] <atomnuker> since you have to spend more bits on making a transient sound better [21:41:03 CEST] <atomnuker> because long frames just have more pre-echo which sounds better than clicking [21:41:56 CEST] <tdjones> I had a suspicion that vbr would have a greater impact on reducing it [21:42:28 CEST] <atomnuker> tdjones: I just remembered the vorbis encoder has no rate control and needs -q:a so vbr mode only [21:42:40 CEST] <atomnuker> you'll have a ton of actual fun implementing a rate control system [21:42:50 CEST] <atomnuker> start by having a lambda value first [21:43:00 CEST] <atomnuker> where the lambda value starts off as 1.0f during init [21:43:29 CEST] <atomnuker> and for every frame you multiply it by the ratio of bits_used / ideal_bits [21:44:07 CEST] <atomnuker> where ideal_bits is the bitrate divided by the (samplerate divided by the frame_size in samples) [21:44:31 CEST] <atomnuker> if you were to encode with ideal bits you'd nail the rate exactly [21:44:51 CEST] <atomnuker> so what happens is the lambda values goes up (or its supposed to go up) if you undershoot the rate [21:44:58 CEST] <atomnuker> and go down if you overshoot the rate [21:45:20 CEST] <atomnuker> and you plug the lambda value as the rate multiplier into your search and quantization [21:45:48 CEST] <atomnuker> and if everything works correctly it'll on average maintain the rate specified [21:46:50 CEST] <tdjones> Yeah, I've tried to follow the bit rate managing in libvorbis, but I then remember how much xiph enjoyed obfuscating any non-trivial code [21:46:57 CEST] <JEEB> :D [21:47:11 CEST] <atomnuker> look at how s->lambda is set in aacenc.c [21:47:58 CEST] <tdjones> I'll take a look. [21:47:59 CEST] <atomnuker> the ratio there is clipped between 0.9 and 1.1 but I don't think that does much good [21:48:51 CEST] <atomnuker> its there to prevent huge variations and allow the rate to play a little but as it is the aac encoder keeps its rate extremely constrained [21:51:22 CEST] <tdjones> Well, I have a patch the supports mono streams, and a patch for some clip avoidance. Should I resubmit the transient patches with the changes suggested on the mailing list and follow that up with these couple patches? [21:52:03 CEST] <atomnuker> the first patch was fine, just resubmit that one [21:52:14 CEST] <tdjones> I almost have support for 5.1 streams, I just need to fix some of the channel muxing problems that I've had with the mapping configurations [21:52:14 CEST] <atomnuker> (with the nits I had) [21:52:53 CEST] <atomnuker> 5.1 would be nice but its in no way a priority and would probably complicate things [21:53:07 CEST] <atomnuker> (that apart I've never seen a 5.1 vorbis file anywhere) [21:54:52 CEST] <tdjones> I mean it should work for any file with LFE. I'll put it on the back-burner for now [21:57:46 CEST] <tdjones> Did you also want me to move codebooks to vorbis_data.c? I had mentioned that they are only used in the encoder, so I wasn't sure what the convention was for that. [21:58:35 CEST] <atomnuker> yep [21:59:06 CEST] <atomnuker> actually, how many total lines of tables does the encoder use? [21:59:25 CEST] <atomnuker> (encoder only tables that is, which the decoder doesn't need) [22:00:11 CEST] <tdjones> The decoder doesn't use pre-built tables at all afaik. [22:00:21 CEST] <tdjones> It only pulls tables from the header of the bit stream [22:00:50 CEST] <atomnuker> oh you're right [22:01:30 CEST] <atomnuker> damn, in that case its fine to have a separate encoder-only tables file [22:02:46 CEST] <tdjones> ok [22:02:47 CEST] <atomnuker> tdjones: btw did you know there was a proprietary tool to re-entropy encoder vorbis files by scanning it and making optimal tables up [22:03:04 CEST] <atomnuker> 10 years ago though, and it only gave like 3% IIRC [22:04:09 CEST] <tdjones> I did not know that. I know that you can train new codebooks in libvorbis if you flag for it at compile-time, but I've never tried it. [23:22:21 CEST] <cone-936> ffmpeg 03Wan-Teh Chang 07master:8c3b329da21a: avcodec/h264_slice: don't sync default_ref[] between threads. [23:22:21 CEST] <cone-936> ffmpeg 03Wan-Teh Chang 07master:58fbcf885d97: pthread_frame: revert 2e664b9c1e73c80aab91070c1eb7676f04bdd12d. [00:00:00 CEST] --- Fri Jul 28 2017