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

[burek]

[07:55:18 CEST] <gagandeep> kierank: fixed that stuff, made a noob mistake, back to work
[08:10:53 CEST] <cone-828> ffmpeg 03Karthick Jeyapal 07master:2efdbf736798: avformat/dashenc: Added option for Segment file format
[08:10:53 CEST] <cone-828> ffmpeg 03Karthick Jeyapal 07master:ebf85d319087: avformat/dashenc: Added a warning for incorrect segment name extension
[08:34:53 CEST] <hanna> atomnuker: I still wonder if there's a better way to upload RGB textures than my texel storage buffer hacks
[08:35:25 CEST] <hanna> Specifically, on devices where RGB textures are wholly unsupported
[08:35:32 CEST] <hanna> I know ANV has them to an extent, but e.g. RADV doesn't at all
[08:40:02 CEST] <atomnuker> huh, what devices don't support rgb textures?
[08:53:06 CEST] <atomnuker> hanna: were you talking about yuv textures?
[08:59:40 CEST] <hanna> no, plain old RGB
[08:59:41 CEST] <hanna> e.g. rgb24
[08:59:51 CEST] <JEEB> RGBA vs RGB, basically
[08:59:53 CEST] <hanna> atomnuker: all discrete GPUs don't, essentially
[08:59:57 CEST] <hanna> intel iGPU supports them to a limited extent
[09:00:14 CEST] <hanna> (only supports sampling from them, but not e.g. rendering to them or using them in compute shaders)
[09:05:02 CEST] <atomnuker> what use do you have for plain rgb textures? would they be any faster
[09:05:37 CEST] <hanna> atomnuker: consider a user opening an rgb file
[09:05:40 CEST] <hanna> like a png
[09:05:55 CEST] <hanna> I want to avoid a software conversion pass the likes of swscale
[09:06:23 CEST] <hanna> what I'm doing currently in libplacebo is doing the conversion from rgb to rgb24 on the GPU (using compute shaders)
[09:08:33 CEST] <atomnuker> that sounds reasonable
[09:09:10 CEST] <hanna> but this solution involves a lot of moving parts
[09:09:31 CEST] <atomnuker> yeah, sounds annoying if you want to ensure you never load overlapping parts in each workgroup
[09:10:28 CEST] <atomnuker> ok, how about this
[09:10:46 CEST] <atomnuker> you load the texture into memory and you map it to 3 1d images
[09:10:53 CEST] <atomnuker> each with a different stride
[09:11:01 CEST] <hanna> you can't put a stride on the texel size
[09:11:04 CEST] <hanna> (typically)
[09:11:30 CEST] <hanna> or am I misunderstanding?
[09:12:18 CEST] <atomnuker> oh, right, you can't
[09:12:59 CEST] <atomnuker> well, you could
[09:13:02 CEST] <atomnuker> if the image was 2d
[09:13:29 CEST] <atomnuker> you'd map the same memory to 3 images again and tweak the width until you get the right offset
[09:14:16 CEST] <atomnuker> should work on nvidia, I think they don't care about alignment of stride at all
[09:15:18 CEST] <hanna> I'm still not sure what you mean
[09:15:34 CEST] <hanna> also the stride has alignment requirements
[09:16:11 CEST] <atomnuker> on nvidia the requirements were "1"
[09:16:27 CEST] <hanna> bufferRowLength has to be a multiple of the texel size, the vulkan spec requires this
[09:16:38 CEST] <hanna> (in fact it has to be a multiple of the compressed block size for compressed texture formats)
[09:17:06 CEST] <atomnuker> that's for buffers
[09:17:34 CEST] <hanna> then I'm confused as to what you're talking about
[09:17:47 CEST] <hanna> copying from a buffer to an image is the ultimate goal here
[09:18:53 CEST] <atomnuker> basically, if it were possible, you'd create 3 images, each with a width==stride of 3, and map the same vkdevicememory to them but with a different offset
[09:19:14 CEST] <atomnuker> the vkdevicememory would be linear, you'd just map it and copy the texture directly
[09:19:28 CEST] <atomnuker> or you could use the awesome host mapping extension and skip copying it
[09:20:24 CEST] <atomnuker> then each of the components would be available as a different vkimage
[09:21:42 CEST] <atomnuker> this is all assuming that the implementation is merciful and VkSubresourceLayout.rowPitch isn't aligned
[09:27:01 CEST] <atomnuker> or if the compiler isn't merciful and demands a stride of 4, you could handle this in chunks of 5x(rgb)
[09:27:27 CEST] <atomnuker> since every 12 components the pattern repeats and 12 is a multiple of 4
[09:34:37 CEST] <hanna> Okay, I can see how that might work (given the assumptions) - but it has a shortcoming which is the same issue I have with texel buffers (potentially even worse)
[09:35:02 CEST] <hanna> Say I'm uploading a 1000x1000 image. Since you want the offset of 3 encoded as the width of the 2D image, you're using the height to cover the full amount of pixels in the original
[09:35:17 CEST] <hanna> so essentially you want a 2D texture that has dimensions 1x1000000
[09:35:42 CEST] <hanna> This exceeds the practical maxImageDimension2D (which is e.g. 16K for me)
[09:35:53 CEST] <hanna> To work around this you'd need to split those 1 million pixels up into 16K slices
[09:35:59 CEST] <hanna> And that's the same thing I'm trying to avoid, which the texel buffer case also requires
[09:36:09 CEST] <hanna> (Because texel buffers can also have size limitations)
[09:36:28 CEST] <hanna> (Fortunately the texel buffers on e.g. my end the limit is 134217728 on a texel buffer)
[09:44:14 CEST] <atomnuker> welp, what I would do which would work would be to host map the image to a buffer (or copy it) and work it in chunks of whatever I find is most efficient
[12:16:56 CEST] <gagandeep> kierank: about indentation, if i add an if statement that covers the existing code, should i indent the existing code in the patch i send with new code
[12:17:25 CEST] <gagandeep> i think this was also being discussed in my previous mail, so i sent an indented mail with new code
[12:18:07 CEST] <gagandeep> also i am now reading all the 17 subbands and just need to apply the inverses, and some minor stuff
[12:19:07 CEST] <jdarnley> Usually we prefer whitespace and indentation changes to be done in seprate patches.
[12:19:37 CEST] <jdarnley> Especially if you are just sticking if(){...} around a block.
[12:21:16 CEST] <gagandeep> ok
[12:21:51 CEST] <gagandeep> so i should send the indentation in a later patch, in the same mail? or a new one
[12:23:03 CEST] <jdarnley> Use git-send-email and/or git-format-patch and send all your changes as one thread to the mailing list.
[12:23:23 CEST] <jdarnley> If you need to do your own email then you may attach all the patches to one email.
[12:24:10 CEST] <gagandeep> ok
[12:24:14 CEST] <gagandeep> thanks
[12:25:17 CEST] <jdarnley> https://ffmpeg.org/developer.html#Submitting-patches-1
[12:25:27 CEST] <jdarnley> That ^ covers it
[12:32:08 CEST] <nevcairiel> we should really get rid of that stupid policy
[12:32:21 CEST] <nevcairiel> only carl really likes that because he doesnt have a proper patch viewer that can just ignore whitespace changes
[12:33:40 CEST] <jdarnley> I rather like it.  It means I don't have to do something special to ignore whitespace changes.
[12:33:58 CEST] <nevcairiel> except you have to do something special when authoring patches
[12:34:00 CEST] <nevcairiel> which is far worse
[12:34:05 CEST] <jdarnley> Not to mention I don't know how to get Thunderbird to do that.
[12:34:09 CEST] <JEEB> btw, I got a confirmation during my sleep that https://patchwork.ffmpeg.org/patch/9114/ indeed fixes sftp for a user, so if someone else can say if that looks OK it can be merged and back-ported to release/4.0 (I can do that after $dayjob, but that's still some hours off)
[12:34:19 CEST] <nevcairiel> its basically in my genes to auto-indent any blocks i create
[12:34:25 CEST] <nevcairiel> and some editors i use even do that for me
[12:34:43 CEST] <JEEB> jdarnley: I usually get patches through patchwork because my clients are awful with patches
[12:35:03 CEST] <JEEB> so I can `curl -L "https://patchwork.ffmpeg.org/patch/9114/mbox/" | git am`
[12:35:08 CEST] <JEEB> for example
[12:35:22 CEST] <JEEB> so when I am looking at the patch it is already in git
[12:35:35 CEST] <JEEB> (well I can take a basic look in patchwork or so)
[12:36:45 CEST] <durandal_1707> atomnuker: looks like filter also filters out high frequencies like breath, they appears like noise
[13:01:32 CEST] <cone-828> ffmpeg 03Jun Zhao 07master:90acf168a6e2: cmdutils: print missing caps in print_codec().
[13:01:33 CEST] <cone-828> ffmpeg 03Jun Zhao 07master:81b77e7bf16a: cmdutils: dump supported hardware devices in print_codec()
[13:14:42 CEST] <jdarnley> Well, that is disapponting.  My simd quant doesn't make the encoder any faster.
[13:15:04 CEST] <jdarnley> Even when I took the time to use intrinsics and linine it all.
[13:15:07 CEST] <nevcairiel> is the quant itself faster if you  measure it targeted?
[13:15:40 CEST] <jdarnley> Hm.  I'd have to cut it out and so some specific testing.
[13:23:31 CEST] <jdarnley> Wow.  How does perf think pabsd is so slow?
[13:23:51 CEST] <jdarnley> Rather how does it think I spend so much time on it?
[13:24:48 CEST] <jdarnley> I was expecting the 2 pmuludq to be a bigger penalty
[13:53:15 CEST] <kierank> jdarnley: I would do the transforms
[13:53:22 CEST] <ubitux> jdarnley: perf is misaligning instruction for me
[13:53:44 CEST] <ubitux> and if you see a memory load or write above it's probably where the cost is
[13:54:05 CEST] <jdarnley> I will and I do
[13:55:46 CEST] <ubitux> jdarnley: https://bugzilla.kernel.org/show_bug.cgi?id=196205
[13:55:53 CEST] <ubitux> that kind of shit ^
[13:56:06 CEST] <ubitux> happens on all platforms
[13:56:20 CEST] <ubitux> maybe i'm jsut misinterpreting thing, but since the instruction itself is marked in red...
[13:56:34 CEST] <jdarnley> That's rather obvious.  3 movs then some register only instructions
[13:57:12 CEST] <ubitux> yes that's rather obvious
[13:57:26 CEST] <ubitux> ...obvious there is a bug in how the timing are represented
[13:59:03 CEST] <kierank> jdarnley: I think we tried simding quant before
[13:59:07 CEST] <kierank> It doesn't help
[14:05:49 CEST] <kierank> gagandeep: personally I don't care about this whitespacing thing
[14:16:26 CEST] <kierank> gagandeep: what are you working on currently
[14:22:22 CEST] <gagandeep> kierank: i think i should have progressive ip working by tomorrow, fingers crossed
[14:22:43 CEST] <kierank> ok, you'll have a challenge with threading I think
[14:22:54 CEST] <gagandeep> i am also thinking the same
[14:23:43 CEST] <kierank> gagandeep: might need to maintain a fork on github
[14:23:53 CEST] <kierank> and develop features on that with threads off
[14:24:10 CEST] <kierank> and then we can discuss with people who understand the frame thread code better than me
[14:27:38 CEST] <gagandeep> ok, i'll discuss what to do next once i get this running
[14:29:19 CEST] <kierank> gagandeep: does the mountain sample work?
[14:31:36 CEST] <kierank> we might have to use the mplayer binary loader to play that
[14:33:10 CEST] <gagandeep> kierank: with the mountain sample, some tag problem is there, right now it fails some tests you have placed in cfhd
[14:33:26 CEST] <kierank> which tag
[14:33:37 CEST] <gagandeep> allocated width and allocated height
[14:33:46 CEST] <gagandeep> haven't analysed it more yet
[14:33:49 CEST] <kierank> ok, might need changing
[14:34:02 CEST] <kierank> gagandeep: can you make a github tree
[14:34:51 CEST] <gagandeep> just need to post this repo i am working on github?
[14:35:08 CEST] <kierank> yes
[14:35:19 CEST] <gagandeep> k, will do that
[14:35:29 CEST] <kierank> durandal_1707: do any codecs have threaded transform?
[14:38:32 CEST] <kierank> gagandeep: problem with mountain sample is that it is a "cut" avi file with no index
[14:38:43 CEST] <kierank> so that's why cineformsdk doesn't support it
[14:38:49 CEST] <kierank> but ffmpeg can try to fix
[14:39:59 CEST] <durandal_1707> kierank: ?
[14:40:08 CEST] <kierank> durandal_1707: do any codecs do threaded transform
[14:40:27 CEST] <kierank> where transform is decomposed into sub transforms
[14:40:37 CEST] <kierank> gagandeep will most likely have to do this for cineform
[14:54:48 CEST] <durandal_1707> kierank: 2
[14:55:18 CEST] <kierank> I guess also threaded coefficient unpack
[14:56:42 CEST] <durandal_1707> with slice threading?
[14:58:09 CEST] <kierank> it doesn't have slices
[14:59:04 CEST] <durandal_1707> but does it have code where slice threading could be used, like for loops...
[14:59:08 CEST] <kierank> no
[14:59:17 CEST] <kierank> slices imply independently decodable regions
[14:59:38 CEST] <kierank> cineform has parts of the bitstream which can be threaded (coefficients and transforms) but not slices
[15:03:29 CEST] <durandal_1707> well, look how much time is spent on that before writting threading for that
[15:03:49 CEST] <kierank> well simd for transform first of course
[15:12:07 CEST] <kierank> gagandeep: http://www.cinemartin.com/cinec/_Sample_Videos/Gopro_Cineform/cymono1HD.avi
[15:12:09 CEST] <kierank> download that sample
[15:12:16 CEST] <kierank> will be useful during optimisation work later in gsoc
[15:16:23 CEST] <durandal_1707> shit, can not download matlab code files from shady site, need to pay them little fortune
[15:33:06 CEST] <kierank> gagandeep: did you download file
[15:34:35 CEST] <gagandeep> downloading it, internet is slow in the place i am working
[15:34:55 CEST] <kierank> I had to download using lftp threaded mode
[15:34:58 CEST] <kierank> such a big file
[15:35:31 CEST] <gagandeep> damn, i don't know so many ftp modes, i am downloading using chrome
[15:35:50 CEST] <Compn> lftp? haha never heard of it
[15:36:17 CEST] <Compn> i'm stuck in the past with ncftp
[15:36:22 CEST] <Compn> maybe time to switcheroo
[15:36:28 CEST] <gagandeep> +1
[15:38:02 CEST] <Compn> hah it does fxp too, havent used that in years
[15:38:40 CEST] <JEEB> lftp is probably the least bad FTP client for terminal
[15:39:06 CEST] <JEEB> for stuff like ssh I usually poke over with rsync -rP FROM TO
[15:40:24 CEST] <kierank> lftp
[15:40:33 CEST] <kierank> pget -n 10 http://www.cinemartin.com/cinec/_Sample_Videos/Gopro_Cineform/cymono1HD.avi
[15:40:40 CEST] <kierank> and it will download with 10 threads
[15:40:52 CEST] <JEEB> yup
[15:40:59 CEST] <durandal_1707> try this product: https://github.com/richardpl/ncdm and be like a PRO
[15:41:18 CEST] <JEEB> I used to utilize that (pget) when synchronizing data between my Japan box and Europe
[15:41:33 CEST] <JEEB> just because I couldn't get more than 300kbps over a single connection
[15:41:50 CEST] <JEEB> but the line was much better on both sides so just threading it tended to help
[16:56:03 CEST] <durandal_1707> atomnuker: is opus noise reduction merged into main tree?
[19:00:50 CEST] <gagandeep> kierank: how do i keep the decoded data of second frame for displaying it in next frame
[19:01:24 CEST] <gagandeep> in one run of cfhd.c i think second frame data is lost
[19:01:51 CEST] <gagandeep> because both frames bands are streamed with first frame data
[19:03:06 CEST] <kierank> gagandeep: av_frame_ref
[19:04:35 CEST] <kierank> gagandeep: and you store it in your global context
[19:06:15 CEST] <gagandeep> ok
[19:06:30 CEST] <kierank> is it only decoded data you need?
[19:06:33 CEST] <kierank> you don't need coefficients?
[19:09:09 CEST] <gagandeep> i should be able to decode the band data and get the frames, that seems simple and what do you mean by coefficients
[19:09:28 CEST] <kierank> the coefficients are the data which does into the inverse wavelet transform
[19:09:45 CEST] <kierank> goes*
[19:09:51 CEST] <kierank> but if you need the pixel data then ok
[19:09:53 CEST] <gagandeep> well coefficients are overwritten after inverse
[19:10:05 CEST] <kierank> yes
[19:10:24 CEST] <gagandeep> so it's pointless anyways, and i don't think i need them later
[19:10:33 CEST] <kierank> ok
[19:10:34 CEST] <gagandeep> there are only 2 frames used for temporal
[19:10:47 CEST] <gagandeep> and then it repeats
[19:10:51 CEST] <kierank> i find it a bit strange that it uses pixel data but i don't know exactly what it's doing anyway
[19:10:59 CEST] <kierank> so carry on
[19:11:11 CEST] <gagandeep> what do you mean by pixel data
[19:11:17 CEST] <gagandeep> the final one
[19:11:20 CEST] <kierank> the data from the reconstructed first frame
[19:11:36 CEST] <kierank> I would have thought it maybe uses coefficients from the first frame
[19:11:39 CEST] <kierank> to decode the p frame
[19:12:06 CEST] <gagandeep> for temporal transform it is using coefficients of both frames, so you are right
[19:12:36 CEST] <gagandeep> two lowpasses are passed through temporal to get a new lowpass and highpass band
[19:12:37 CEST] <kierank> so you may have to remove some of the inplace transformations
[19:13:38 CEST] <kierank> gagandeep: btw you may want to fix tag=71
[19:14:10 CEST] <kierank> I think that part is wrong, it's all done in tag 72
[19:14:53 CEST] <gagandeep> ok, will see
[19:20:40 CEST] <kierank> gagandeep: also for the new samples you should add fate tests https://trac.ffmpeg.org/wiki/FATE/AddingATest
[19:21:26 CEST] <kierank> gagandeep: also at some point you need to check bitexactness with cineformsdk
[19:22:57 CEST] <gagandeep> yeah, just let me finish this pframe thing first
[19:23:02 CEST] <kierank> ok
[19:27:18 CEST] <kierank> I will add to your github issues
[19:27:53 CEST] <kierank> ah no I can't :)
[19:28:21 CEST] <gagandeep> yeah, just let me, i need to fork ffmpeg then connect it with my local branch
[19:28:52 CEST] <gagandeep> i haven't done that yet and will ask for help later
[19:29:11 CEST] <gagandeep> more like i don't know how, but right now got my hands full
[19:32:56 CEST] <kierank> ok
[19:33:01 CEST] <kierank> no problem, p-frames is the big problem
[19:33:05 CEST] <kierank> the other issues are small
[19:34:34 CEST] <cone-828> ffmpeg 03Jan Ekström 07master:26892c761539: lavf/libssh: translate a read of 0 to EOF
[19:35:20 CEST] <cone-828> ffmpeg 03Jan Ekström 07release/4.0:c8b57d4333b1: lavf/libssh: translate a read of 0 to EOF
[19:43:49 CEST] <atomnuker> durandal_1707: yes, use whicever one is newer
[19:58:33 CEST] <kierank> j-b: what codecs are too slow?
[20:44:22 CEST] <durandal_1707> atomnuker: have you tried anlmeans ?
[23:10:21 CEST] <atomnuker> klaxa: I can't wait for the audio-only support
[23:10:34 CEST] <atomnuker> icecast is unwieldy and archaic at this point
[23:11:26 CEST] <klaxa> well the patch is on the ML, i think i still have some race-conditions (with more than 1 thread sometimes two threads try to write at the same time) and in very rare cases a segment gets skipped even with one writing thread
[23:11:49 CEST] <nevcairiel> how do you implement metadata updates if you plan to replace icecast?
[23:11:59 CEST] <klaxa> yeah i was just wondering that as well
[23:12:36 CEST] <klaxa> i suppose doing icy-metadata is not impossible
[23:12:55 CEST] <klaxa> iirc it's just a variable length segment every X bytes?
[23:13:02 CEST] <klaxa> with the length specified in the header
[23:13:46 CEST] <nevcairiel> the header basically specifies the distance between headers, yea
[23:14:22 CEST] <klaxa> but that would not work with hls/dash streams i guess?
[23:14:44 CEST] <atomnuker> it would if you make a new segment I think?
[23:14:48 CEST] <nevcairiel> guess it could if its implemented on a low enough level
[23:14:51 CEST] <nevcairiel> but it would be ugly
[23:16:20 CEST] <atomnuker> for ogg streaming you'd use the annoying chaining feature which we partly support (vorbis only)
[23:17:22 CEST] <klaxa> hmm... looking at my code, every segment is given the metadata for each stream and the whole file, not sure if it is automatically updated? i also haven't tried a stream with changing metadata
[23:18:08 CEST] <cone-045> ffmpeg 03Michael Niedermayer 07master:42f40d36b74e: avcodec/allcodecs: Provide empty codec_list in allcodecs when ossfuzz is used
[23:22:05 CEST] <klaxa> hmm doesn't seem to show any metadata with an icy-metadata compatible stream as an input
[23:46:18 CEST] <cone-045> ffmpeg 03Jerome Borsboom 07master:c0402e1e30c2: avcodec/vc1: fix mquant calculation for interlace field pictures
[23:52:02 CEST] <cone-045> ffmpeg 03Jerome Borsboom 07master:8a4dbd3e9fd1: avcodec/vc1: store zero MVs for all blocks in a MB
[00:00:00 CEST] --- Tue May 29 2018