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

burek burek021 at gmail.com
Mon Jul 3 03:05:04 EEST 2017


[00:00:02 CEST] <nevcairiel> (unless you count USB slots on power outlets :p)
[00:01:01 CEST] <rcombs> how long until we get in-wall USB-C supplies that actually put out a decent amount of power
[00:01:09 CEST] <iive> well, with DC you still have same problem with Voltage and Current.
[00:01:10 CEST] <rcombs> (inb4 never because heat dissipation problems)
[00:01:39 CEST] <nevcairiel> dont know about C, but there are in-wall outlets with USB-A connectors, not sure how much power they provide tho
[00:01:47 CEST] <rcombs> not a whole lot
[00:01:51 CEST] <rcombs> 10~20W tops
[00:02:00 CEST] <rcombs> I want 87
[00:02:14 CEST] <iive> have in mind, 20W on 5V is 4A
[00:02:45 CEST] <atomnuker> the cables are the issue IMO
[00:02:48 CEST] <BtbN> USB-C increases the voltage for power-delivery
[00:02:49 CEST] <rcombs> yeah, that's why USB-C does higher voltages
[00:02:56 CEST] <nevcairiel> not sure what latest gen quick charge is rated at, however keep in mind that those high-power chargers do take a toll on the batteries
[00:03:09 CEST] <BtbN> USB-C does 100W max, at 20V
[00:03:29 CEST] <rcombs> i.e. up to 5A
[00:03:41 CEST] <rcombs> (the cable indicates its max current)
[00:04:46 CEST] <wm4> wow that's high
[00:49:48 CEST] <kierank> BtbN: usb-c pd
[00:49:49 CEST] <kierank> yes
[00:50:09 CEST] <kierank> 10:58 PM <"atomnuker> DC is scary as fuck and I'm not touching it
[00:50:10 CEST] <kierank> yes
[00:50:12 CEST] <kierank> dc is fucking scary
[00:50:16 CEST] <kierank> ac throws you off
[00:50:20 CEST] <kierank> dc you stick to it
[01:44:08 CEST] <iive> electricity makes your muscles contract, dc or ac.  If you grab a power wire you are stuck to it.
[01:46:12 CEST] <atomnuker> yes, but the latter also expands any contracted muscles every 1/2 period
[01:46:31 CEST] <iive> no expanding
[01:48:01 CEST] <iive> muscles only contract and relax.
[01:49:35 CEST] <iive> that's why you have different muscle groups for closing your fingers and "expanding" them.
[01:50:06 CEST] <iive> and these for closing are stringer and will win.
[01:54:40 CEST] <iive> so as safety tip, if you absolutely must touch a metal part that might be under power, touch it with the outside of your hand.
[03:07:42 CEST] <iive> n8 ppl
[03:10:33 CEST] <DHE> atomnuker: muscles only pull. the "squeeze" muscles in your hand are stronger than the "release" muscles so you squeeze. AC will just cycle squeeze<->relax
[07:18:58 CEST] <LongChair> wm4, jkqxz: here is my proposal https://github.com/LongChair/FFmpeg/blob/rockchip-new/libavutil/hwcontext_drm.h
[12:09:00 CEST] <wm4> LongChair: does it really need multiple FDs for a single layer?
[12:21:14 CEST] <LongChair> not for rockchip, but most of the primitives for EGL & DRM have an fd array. so i believe it could be used
[12:21:53 CEST] <LongChair> theorically i think you could maybe have an fd for each layer planes ... with offset = 0 
[12:24:20 CEST] <LongChair> for EGL CreateImageKHR uses attributes, and you could have several FDs in there ... and drmModeAddFB2 also has and array of fds / offsets / pitches
[12:25:14 CEST] <LongChair> in rk implementation the nv12 decoder output only has one fd with different offsets for planes, but iirc v4L2 decoder could have one gd per plane
[12:25:37 CEST] <LongChair> so just wanted to play it safe as it doesn't add a lot of overhead :)
[12:38:09 CEST] <wm4> so why distinguish between layers and planes again?
[13:00:07 CEST] <LongChair> because if we just keeps planes it doesn't make it handy to group planes by formats to build the strides & offsets
[13:00:53 CEST] <LongChair> basically with nv12 usual format you would have one layer and multiple offsets / strides that would become a texture or a drm layer
[13:01:20 CEST] <LongChair> with vaapi, you would have 2 layers with different format each that would become 2 textures 
[13:01:44 CEST] <LongChair> each layer would have zero offset and one stride
[13:02:04 CEST] <LongChair> in the end a layer becomes a texture for egl or a drm layer
[13:02:47 CEST] <LongChair> if we don't handle that in the frame to group them, then we'll have to do it in renderer, and that would add overhead
[13:04:12 CEST] <LongChair> several layers is not useful for drm as drm can only cope with a dingle format data 
[13:04:24 CEST] <LongChair> but it does for EGL / vaapi afaik
[13:04:37 CEST] <LongChair> this is what mpv renderer would look like https://github.com/LongChair/mpv/blob/9e8564950ba4360a6c015d434cf994d296ca4407/video/out/opengl/hwdec_drmprime_egl.c
[13:05:50 CEST] <jkqxz> Is this the same as the nested-structures version we had a while ago?  (Except with multiple arrays rather than an array of structures.)
[13:07:15 CEST] <jkqxz> I'm not convinced that multiple objects in a layer is meaningful.  The whole point is that it's a single DRM_FORMAT_foo instance, and that must be within a single object.
[13:08:58 CEST] <jkqxz> I think that would look better as nested structures rather than the arrays.  Also I think it should have an nb_planes element, because valid/invalid values there are not clear.
[13:09:53 CEST] <wm4> fine...
[13:11:26 CEST] <jkqxz> wm4:  It was mainly you that didn't like the nested structures, IIRC.
[13:11:36 CEST] <wm4> yes
[13:27:07 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #74: len - 1 is unsigned (06master...06len) 02https://git.io/vQ0Xc
[15:41:41 CEST] <KGB> [13FFV1] 15michaelni closed pull request #56: Improvement of context and quantization tables paragraphs (06master...06context) 02https://git.io/vSQ3j
[15:58:40 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vQ0Sj
[15:58:40 CEST] <KGB> 13FFV1/06master 1445e70a0 15Jérôme Martinez: len - 1 is unsigned...
[16:16:11 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #75: Move of sample names to a dedicated paragraph (06master...06Sample) 02https://git.io/vQ0HU
[16:20:32 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #76: Restrictions section is a top level section (06master...06Restrictions) 02https://git.io/vQ0H4
[16:35:18 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #77: White space for forcing carriage return in a paragraph (06master...06Markdown) 02https://git.io/vQ0Qm
[17:34:36 CEST] <cone-397> ffmpeg 03Paul B Mahol 07master:c8853568b177: avcodec/alsdec: call correct function for multi-channel coding
[18:10:40 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vQ0FR
[18:10:40 CEST] <KGB> 13FFV1/06master 14a45be46 15Jérôme Martinez: Move of sample names to a dedicated paragraph
[18:13:01 CEST] <KGB> [13FFV1] 15michaelni closed pull request #76: Restrictions section is a top level section (06master...06Restrictions) 02https://git.io/vQ0H4
[20:37:39 CEST] <KGB> [13FFV1] 15michaelni closed pull request #73: update to version 03 (06master...06update-to-version-03) 02https://git.io/vQBV4
[21:41:51 CEST] <TMM> I'm trying to make an ffmpeg trac account but something appears to be wrong
[21:42:08 CEST] <TMM> it seems to be hanging on the post to register_ffmpeg_two
[21:43:05 CEST] <TMM> nvm, it eventually went through, took several minutes though
[23:36:31 CEST] <KGB> [13FFV1] 15michaelni tagged 06draft-ietf-cellar-03 at 06master: 02https://git.io/vQELr
[23:44:53 CEST] <KGB> [13FFV1] 15dericed opened pull request #78: escape underscore (06master...06fix-subscript-in-quant_tables) 02https://git.io/vQEtI
[23:53:56 CEST] <KGB> [13FFV1] 15dericed opened pull request #79: bump to wg doc version 00 (06master...06bump-to-wg-doc-00) 02https://git.io/vQEtM
[23:57:16 CEST] <KGB> [13FFV1] 15michaelni 04deleted 06draft-ietf-cellar-03 at 143b6a14d: 02https://git.io/vQEtj
[00:00:00 CEST] --- Mon Jul  3 2017


More information about the Ffmpeg-devel-irc mailing list