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

[burek]

[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