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

[burek]

[00:21:43 CEST] <ars> Hello guys. I have problem. error while loading shared libraries: libva.so.1: cannot open shared object file: No such file or directory. Looks like it not linked statically. But i compile like: configure --enable-libmfx --enable-nonfree --enable-gpl --disable-shared --enable-static 
[00:23:18 CEST] <nevcairiel> those options controls what kind of ffmpeg libraries you build, not how things are linked in
[00:24:45 CEST] <ars> nevcairiel, how can make static build ? 
[00:25:09 CEST] <nevcairiel> static linking against libva is probably generally not possible
[00:25:39 CEST] <ars> :( ooo, thank you
[11:13:46 CEST] <ZeroWalker> trying to understand Bicubic, if i get things right, cubic means that it samples all the surrounding pixels of a a pixel, merge the values with that pixel, but there's a weight parameter that tells how much that center pixel should be prioritized
[11:17:26 CEST] <nevcairiel> simplified, cubic means it samples two data points in every direction, and bicubic means it does that in 2 dimensions (for 16 data points in total)
[11:18:36 CEST] <ZeroWalker> so it's a "cross" + , not every surrounding pixel "square"?
[11:19:20 CEST] <ZeroWalker> at least if i get every direction correctly. (x and y)
[11:19:46 CEST] <nevcairiel> for bicubic you take the 4x4 pixel grid around your desired point
[11:20:23 CEST] <ZeroWalker> hmm
[11:21:25 CEST] <ZeroWalker> feels a bit weird, so, if you don't have 4x4 pixels (near the edge), does it just make do with that it has?
[11:22:47 CEST] <nevcairiel> typical approach is just to just extend the edge (or clamp the index, but  thats the same result different implementation), so you just pretend that the last pixel row/col extends like that outwards
[11:23:23 CEST] <ZeroWalker> ah
[11:24:47 CEST] <ZeroWalker> hmm, but confused that it's 4x4, does it affect 4 pixels accordingly to the surrounding ones, or is it 1 pixels that's affected by all of those:s
[11:25:52 CEST] <nevcairiel> one pixel is created based on those 16 pixel
[11:26:04 CEST] <nevcairiel> with proper weighting based on its position, of course
[11:27:28 CEST] <ZeroWalker> okay then i get that part. hmm, didn't know the weightning was based on the position, thought it was constant, like "value the original pixel 75% and have 25% of the surrounding samples" or something
[11:32:54 CEST] <nevcairiel> what if you dont hit the position of an original pixel
[11:33:38 CEST] <nevcairiel> if you upscale by a variable factor, the grids wont match up
[11:34:01 CEST] <ZeroWalker> ah yeah was thinking about that
[11:34:57 CEST] <nevcairiel> if you do something simple like doubling the size, then stuff gets easier
[11:43:22 CEST] <ZeroWalker> yeah, hmm, where i am interested it's mostly varying
[12:53:06 CEST] <BtbN> I actually did a BIOS reset to default values. Still crashing. So it's not my RAM "OC" or anything I played around with too much
[12:53:14 CEST] <BtbN> now waiting for AMD to reply to me asking for a new CPU
[13:01:22 CEST] <wm4> just go and pick some intel GPU from a heap of discarded old computers /troll
[13:01:27 CEST] <wm4> *CPU
[13:04:49 CEST] <BtbN> Intel has nothing that remotely compares
[13:05:13 CEST] <BtbN> And Intel also had bad day-one batches of CPUs
[13:05:16 CEST] <BtbN> Broadwell was a disaster
[13:05:20 CEST] <wm4> I'm sure they do for $$$
[13:05:40 CEST] <BtbN> I won't pay 3x the money for a similar CPU from Intel, which then also uses twice as much power
[13:05:44 CEST] <wm4> but yeah Intel seems to be dropping the ball
[13:06:04 CEST] <BtbN> The i9 CPUs are a disaster
[13:06:11 CEST] <BtbN> if you want to actually use them, you are forced to delid them
[13:06:35 CEST] <BtbN> Threadripper is going to steamroll them in that segment
[13:07:03 CEST] <nevcairiel> thats not really a big problem if there is shops that sell them delidded with 2 year warranty =p
[13:07:10 CEST] <BtbN> for 1000$ you either get 10 overheating Intel cores, or 16 actually working Threadripper cores
[13:07:35 CEST] <BtbN> It just boggles my mind that intel cheaps out on soldering on the lid for a 1k$ CPU
[13:09:42 CEST] <wm4> CPUs have a lid?
[13:13:14 CEST] <J_Darnley> The metal heatspreader that is stuck over the bare silicon
[13:14:13 CEST] <J_Darnley> BtbN: Do you use unbuffered ECC ram with your Ryzen?  (A question unrelated to the crashing issues)
[13:14:42 CEST] <BtbN> My mainboard does not support ECC anyway
[13:14:49 CEST] <BtbN> It's not a RAM issue
[13:15:15 CEST] <BtbN> I can run the Prime95 RAM-Test for a full day, and it's perfectly happy
[13:15:23 CEST] <J_Darnley> I know.  It wasn't supposed to be related to the crashing issue
[13:15:36 CEST] <BtbN> but building gcc for a few minutes throws segfaults and invalid opcodes left and right
[13:15:39 CEST] <J_Darnley> I just wanted to know
[13:16:02 CEST] <BtbN> I heard reports of ECC actually working though
[13:16:10 CEST] <BtbN> but there is no fast ECC ram, and i don't overly care
[13:16:23 CEST] <BtbN> Ryzen really profits from running RAM at high clock rates
[13:16:31 CEST] <J_Darnley> Yes, there are sporadic reports from users and some talk of support from AMD.
[13:16:41 CEST] <BtbN> Ryzen does support ECC
[13:16:46 CEST] <BtbN> it just comes down to the mainboard
[13:16:57 CEST] <BtbN> There are some that actually support it
[13:17:07 CEST] <J_Darnley> A few motherboards claim to support ECC orr atleast a couple of ECC ram products
[13:17:24 CEST] <BtbN> you always have ECC for the CPU caches though, which is super nice
[13:28:59 CEST] <durandal_1707> how do one frame accurate seek with lavf?
[13:30:47 CEST] <nevcairiel> you dont
[13:32:47 CEST] <durandal_1707> nevcairiel: thats not very helpful
[13:32:56 CEST] <nevcairiel> but the truth
[13:33:17 CEST] <nevcairiel> lavf is not setup for that
[13:33:28 CEST] <durandal_1707> but mpv can
[13:33:52 CEST] <ubitux> you set the seek time and upper boundary to the ts, the lower to 0 (or intmin?)
[13:33:57 CEST] <ubitux> then you decode til your reach the ts
[13:34:35 CEST] <ubitux> (and then someone will tell you it won't work in case X, Y and Z at least)
[13:35:26 CEST] <ubitux> avformat_seek_file(ctx->fmt_ctx, -1, INT64_MIN, seek_to, seek_to, 0);
[13:35:29 CEST] <ubitux> i'm using this
[13:35:44 CEST] <ubitux> and decode til expected
[13:37:51 CEST] <wm4> accurate seek obviously requires you to skip decoded frames too until the target timestamp
[13:37:57 CEST] <wm4> also that seek API sucks
[14:21:25 CEST] <durandal_1707> how one can convert from pts to frame number?
[14:57:52 CEST] <BtbN> There's no direct conversion
[14:57:58 CEST] <BtbN> only way to get frame number is to actually count
[15:07:40 CEST] <djgl> Hi, I noticed that the libswscale yuv2rgb routines on x86 need stride/8 >= (width+7)/8. Otherwise they will drop pixels on the right. What is a safe stride value across all architectures?
[15:11:10 CEST] <jkqxz> The av_malloc alignment will always be sufficient.
[15:11:35 CEST] <atomnuker> BtbN: didn't you already order a new CPU?
[15:12:21 CEST] <djgl> jkqxz, it's not about the alignment of the buffer. It's about having more space than needed for the pixels in a line.
[15:13:03 CEST] <wm4> libav has a function to get the required alignment
[15:13:09 CEST] <wm4> not sure if it got ported to ffmpeg
[15:13:25 CEST] <jkqxz> For this purpose they are the same thing.
[15:14:14 CEST] <BtbN> atomnuker, a cheap intermediate-one
[15:14:21 CEST] <wm4> yeah, basically every first pixel of a line has to have the minimum alignment
[15:14:35 CEST] <wm4> which is normally achieved by aligning the start pointer and the line size
[15:14:47 CEST] <BtbN> I need a working PC. Not going to send them my CPU and then just not have a working PC for a month or however long they take
[15:15:04 CEST] <wm4> hardware problems suck
[15:15:08 CEST] <iive> BtbN: have you talked to the shop?
[15:16:19 CEST] <djgl> But it's not documented which alignment to use. The doc/examples/scaling_video.c example does it wrong and uses av_image_alloc(..., 1) for the output frame.
[15:16:56 CEST] <BtbN> iive, yes, but they have no idea about the issue at hand, and would probably just grab another random CPU off the shelf.
[15:17:05 CEST] <BtbN> And it would take way longer with them
[15:17:18 CEST] <BtbN> So going directly via AMD seems the better option
[15:17:31 CEST] <wm4> djgl: our examples are often buggy and bad
[15:17:49 CEST] <wm4> generally, all API functions expect aligned data, except if documented otherwise
[15:17:56 CEST] <BtbN> And the shop would most likely just forward the CPU to AMD first, and not give me anything until they confirm the issue
[15:18:28 CEST] <wm4> libswscale can revert to unoptimized code if alingment is not satisfied - not sure if this is documented - it probably should, because other APIs can just crash on unaligned data
[15:20:47 CEST] <djgl> As I said, on x86 it instead drops pixels.
[15:54:24 CEST] <beauty> If I know nginx server's bandwidth and every channel video's bitrate, could I get the maxnum supported video stream?
[17:30:41 CEST] <ZeroWalker> when you make or make install with mingw32, can you select a destination folder instead of it compiling in the same folder as the source
[17:32:34 CEST] <JEEB> most things let you configure a prefix
[17:32:52 CEST] <thebombzen> including ffmpeg
[17:32:54 CEST] <JEEB> autoconf and a lot of shell-script based things have a --prefix parameter
[17:33:01 CEST] <JEEB> yes, naturally :P
[17:33:05 CEST] <thebombzen> lol
[17:33:19 CEST] <JEEB> also the weird part is that he's talking about "compilation"
[17:33:26 CEST] <JEEB> never tried out-of-tree compilation?
[17:33:42 CEST] <ZeroWalker> well, probably worded it wrong
[17:33:43 CEST] <JEEB> and you shouldn't be using the headers and libraries from the build tree anyways, make install to a prefix and then utilize them from there
[17:33:52 CEST] <ZeroWalker> just meant that the .exe files end up in another folder
[17:34:16 CEST] <JEEB> --prefix and then binaries will go under <prefix>/bin and libraries under <prefix>/lib etc
[17:35:00 CEST] <ZeroWalker> ah
[18:27:26 CEST] <ZeroWalker> do you have to do anything special to make libx264 appear in pkg-config when configuring/compiling it?
[18:29:04 CEST] <JEEB> if your prefix is custom you have to override PKG_CONFIG_PATH (appends to the search path) or PKG_CONFIG_LIBDIR (clears the search path)
[18:29:35 CEST] <JEEB> latter is useful if you're building on, say, system with 64bit libraries in the default path and you want to build 32bit
[18:31:53 CEST] <ZeroWalker> hmm, i do use the the latter, will do some testing
[18:32:55 CEST] <JEEB> remember that it should be set to <prefix>/lib/pkgconfig
[18:33:01 CEST] <JEEB> not just <prefix>/lib
[18:33:12 CEST] <JEEB> also do check that you actually enabled the libraries with x264 :P
[18:33:21 CEST] <JEEB> (it defaults to command line encoder only)
[18:46:29 CEST] <ZeroWalker> well firstly i guess it might be good to actually be able to compile the thing, noticed it failed and my stuff were from a very old compilation i did -_--
[18:47:26 CEST] <ZeroWalker> i just get complains that no working C compiler can be found. I can compile with CC=cl, but it fails on some stuff later
[18:47:52 CEST] <ZeroWalker> not sure why it can't find any working c compiler. gcc --version shows: gcc.exe (Rev2, Built by MSYS2 project) 7.1.0
[18:48:41 CEST] <RiCON> you sure you installed and are using mingw gcc and not msys gcc?
[18:49:41 CEST] <ZeroWalker> well i would hope so, isn't Msys the CLI for it
[18:49:59 CEST] <RiCON> not necessarily
[18:50:18 CEST] <ZeroWalker> i got folders for mingw32 and mingw64 which does seem to have the compilers etc
[18:50:34 CEST] <RiCON> `which gcc` should return /mingw64/bin/gcc, not /usr/bin/gcc
[18:50:40 CEST] <ZeroWalker> ah
[18:50:55 CEST] <ZeroWalker>  /mingw32/bin/gcc
[18:51:23 CEST] <RiCON> check config.log then
[18:52:09 CEST] <RiCON> though this conversation is way offtopic, this is neither #ffmpeg nor #x264
[18:52:56 CEST] <ZeroWalker> oh, the plan is to just compile ffmpeg with it so thought it was ok, my bad
[18:56:22 CEST] <thebombzen> ZeroWalker: #ffmpeg-devel is for development of ffmpeg itself, not just compiling it or using it
[18:57:06 CEST] <ZeroWalker> does programming with the ffmpeg API count?
[18:57:38 CEST] <JEEB> no
[18:57:39 CEST] <thebombzen> "Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg" - the title
[18:57:42 CEST] <JEEB> that's #ffmpeg
[18:58:26 CEST] <ZeroWalker> ah, well thing is everytime i have asked there, it's always about the CLI, so thought it wasn't for API at all
[19:17:28 CEST] <durandal_1707> https://transfer.sh/CUFkZ/ffedit.png
[19:53:51 CEST] <durandal_1707> perhaps i should use libmpv
[20:09:41 CEST] <wm4> durandal_1707: I could make lavfi filters runtime changeable lol
[20:10:28 CEST] <durandal_1707> how?
[20:11:04 CEST] <wm4> I mean you could set it as option/property while video is loadd
[20:11:07 CEST] <wm4> *loaded
[20:28:27 CEST] <ubitux> durandal_1707: feel free to use sxplayer :p
[20:28:41 CEST] <ubitux> it has exact seek support
[20:28:45 CEST] <ubitux> it's monostream though
[20:28:59 CEST] <ubitux> (so you pick only video typically)
[20:29:11 CEST] <durandal_1707> sxplayer?
[20:29:23 CEST] <ubitux> https://github.com/stupeflix/sxplayer
[20:30:36 CEST] <ubitux> not sure it fits your needs
[20:34:38 CEST] Action: wm4 sees messy VT code
[20:56:33 CEST] <ubitux> wm4: yeah...
[20:56:56 CEST] <ubitux> could get rid of it if ffmpeg did support async
[20:57:09 CEST] <ubitux> which is not possible due to hwaccel model
[20:57:14 CEST] <ubitux> same story over again
[21:00:26 CEST] <wm4> should bring this up again in libav-devel
[21:00:31 CEST] <wm4> how do you handle reordering btw.?
[21:10:52 CEST] <ubitux> i use packet pts
[21:15:20 CEST] <wm4> that's almost the only thing that stops us from having a vt full stream decoder
[00:00:00 CEST] --- Sun Aug 13 2017