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

burek burek021 at gmail.com
Wed Oct 31 03:05:03 EET 2018


[03:14:06 CET] <cone-150> ffmpeg 03Michael Niedermayer 07master:0fb83b4c91d5: avcodec/vp56: Add vpX_rac_is_end() to check for the end of input
[03:14:07 CET] <cone-150> ffmpeg 03Michael Niedermayer 07master:78862488f852: avcodec/vp9: Check in decode_tiles() if there is data remaining
[04:13:58 CET] <cone-150> ffmpeg 03Charles Liu 07master:3d1b7954933b: avformat/hlsenc: fix the duration of m4s segment is unusually smaller than expected.
[04:13:59 CET] <cone-150> ffmpeg 03Charles Liu 07master:e9dbd62cb5f1: avformat/hlsenc.c: fix memory leak in fmp4 mode.
[04:14:00 CET] <cone-150> ffmpeg 03Charles Liu 07master:2365f47bf51a: avformat/hlsenc.c: remove the useless variable fmp4_init_mode.
[04:14:01 CET] <cone-150> ffmpeg 03Charles Liu 07master:76b8e42c1f04: avformat/hlsenc.c: the size of init.mp4 is zero.
[04:14:02 CET] <cone-150> ffmpeg 03Charles Liu 07master:1ff4bd59dfce: avformat/hlsenc.c: fix the output's duration smaller than input's in sub-range mode.
[05:17:42 CET] <slavanap> Hi! Is there a simple guide for developing image filters for ffmpeg?
[06:18:27 CET] <cone-150> ffmpeg 03Jun Zhao 07master:903f2beafc7c: lavc/decode: Fix the error number report if av_image_fill_pointers fail.
[06:18:28 CET] <cone-150> ffmpeg 03Jun Zhao 07master:f3bcb9c16a42: lavu/frame: Add error report if av_image_fill_pointers fail.
[07:12:02 CET] <cone-150> ffmpeg 03James Zern 07master:32d021cfa652: avcodec/libvpxdec: fix setting auto threads
[10:10:33 CET] <superware> any idea why avio_open2(&_output_ctx->pb, "rtsp://127.0.0.1:8854/live.sdp", AVIO_FLAG_WRITE, null, null) fails with -1330794744?
[10:12:45 CET] <funman> #define AVERROR_PROTOCOL_NOT_FOUND FFERRTAG(0xF8,'P','R','O') ///< Protocol not found
[10:14:57 CET] <superware> I'm using FFmpeg 4.0.1, shouldn't RTSP be supported? I tried calling av_register_all, avdevice_register_all and avformat_network_init (even if deprecated)
[10:16:32 CET] <nevcairiel> maybe it wasnt compiled in
[10:30:15 CET] <superware> nevcairiel: ok, if I try "rtp://127.0.0.1:1234" instead rtsp then avio_open2 is successful, but then av_interleaved_write_frame(_output_ctx, pkt) fails catastrophically by writing protected memory..
[11:54:22 CET] <atomnuker> BBB: what's with the videolan gitlab being more nazi than a gestapo officer?
[11:54:34 CET] <BBB> huh what?
[11:54:43 CET] <BBB> thats a little harsh
[11:54:57 CET] <BBB> can you be more specific?
[11:55:01 CET] <atomnuker> logs me out after 2 days, 2fa required, have to dig my phone out, find out it has no battery, 2fa doesn't work, have to resync time to google servers
[11:55:20 CET] <j-b> there are numerous 2fa apps for cli and so on
[11:55:24 CET] <BBB> lol
[11:55:41 CET] <BBB> ok, sorry, I dont know about that specifically, but I actually think the focus on security is a good thing
[11:55:53 CET] <BBB> yes, phone being out of juice is annoying
[11:56:21 CET] <j-b> it's just normal TOTP
[11:57:02 CET] <durandal_1707> atomnuker: if it were only videolan gitlab....
[11:57:07 CET] <atomnuker> security's fine, just forbid web pushing and make everyone do git pull <repo>; git push using ssh, as a bonus this gets rid of merge commits
[11:57:52 CET] <atomnuker> (to master branches anyway)
[11:59:33 CET] <tguillem> getting rid of merge commits is not a gitlab bug, we do it on purpose. Linear master branch vs branch with merge commit. We did a choice, both are fine.
[11:59:58 CET] <atomnuker> no, merge commits suck is what I meant
[12:00:11 CET] <tguillem> I logged once to gitalib, put my .ssh key on it, and don't have to relog to pull/push
[12:01:02 CET] <atomnuker> well but you do have to relog to make prs editable by maintainers (which I do very clearly remember doing last time)
[12:01:15 CET] <atomnuker> and you have to be logged in to make a pr or post a comment
[12:01:33 CET] <j-b> This is a configuration for each project, nothing to do with gitlab
[12:01:38 CET] <j-b> Maintainers can push directly
[12:02:44 CET] <atomnuker> BBB: "Allow commits from members who can merge to the target branch." <- it was ticked when I opened the webpage
[12:08:33 CET] <BBB> atomnuker: huh, weird& I couldnt rebase it
[12:09:15 CET] <BBB> Fast-forward merge is not possible. To merge this request, first rebase locally.
[12:09:22 CET] <BBB> maybe there is a merge conflict?
[12:09:26 CET] <BBB> can you rebase?
[12:40:19 CET] <atomnuker> ah, yes, forgot about that commit, rebased
[15:22:23 CET] <nevcairiel> whats the latest easiest method to activate the automatic hwaccel decoding? Set a hwdevice context and stuff just magically starts working?
[15:22:50 CET] <nevcairiel> docs seem a bit lacking =p
[16:10:14 CET] <dualz> So I wanted to be able to change inputs at run-time, so i figured I'd make a filter for it that accepts commands via zmq 
[16:10:44 CET] <dualz> I copied the movie filter and used that as a base, named my filter inputswap
[16:11:47 CET] <dualz> I added the "swap" command to the filter
[16:11:50 CET] <dualz> https://gist.github.com/ryanmarin/a4bb8d3d2241b827cff4611e3deca503
[16:12:34 CET] <dualz> now it's supposed to close the current input and open a new one 
[16:13:00 CET] <dualz> from my log output it looks like it opens the new input fine
[16:13:33 CET] <dualz> but I get a segfault
[16:15:45 CET] <dualz> https://gist.github.com/ryanmarin/a960a2d36bbb1af744f95969915f5ea6
[16:16:58 CET] <dualz> any insight as to what's going on would be appreciated 
[16:20:38 CET] <BtbN> I highly doubt the filter graph can be changed at runtime
[16:21:09 CET] <BtbN> Also, use the ffmpeg native filter command framework, pulling in another complex library for that won't find very enthusisastic reception
[16:21:46 CET] <thardin> changing filters kind of implies nle, for which ffmpeg is woefully unsuited
[16:22:04 CET] <thardin> ah, at run-time even. whooh
[16:22:21 CET] <thardin> wait this is what OBS is for
[16:25:46 CET] <dualz> I've been trying to wrap my brain on how to go about this, basically here's the problem space
[16:27:10 CET] <dualz> I have an RTMP server that ingests rtmp://live/cam_1,2,3,4
[16:27:54 CET] <dualz> at the beginning of the stream perhaps only cam 1 is connected
[16:28:28 CET] <dualz> and it's not a few moments in, until cam 2 connects
[16:28:57 CET] <dualz> but the stream started already with just one cam connected 
[16:30:29 CET] <dualz> The user has the ability to change scenes, add overlays etc (which I can at runtime with zmq)
[16:31:14 CET] <thardin> still sounds like an OBS job
[16:31:14 CET] <dualz> if they go to a scene that shows cam 2
[16:32:01 CET] <dualz> i'd like it to be test bars around their input
[16:38:49 CET] <dualz> I don't think I'm explaining it right if it sounds like an OBS job
[17:37:50 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/a797f404882cea58a8c039b65aa50a1ac7e1b9fc
[17:37:53 CET] <philipl> A change from nvidia.
[17:39:09 CET] <nevcairiel> who even still  uses vdpau if you can use nvdec?
[17:40:44 CET] <JEEB> some people seem to be holding to it for some reason
[17:41:52 CET] <j-b> old distro?
[17:42:39 CET] <atomnuker> the worst are people who still use vdpau with the vaapi backend wrapper it has
[17:43:43 CET] <atomnuker> those that use vaapi with the vdpau wrapper it has are maybe just as bad
[17:56:07 CET] <philipl> I don't understand what nvidia are up to. Clearly people don't talk to each other.
[17:56:20 CET] <nevcairiel> its a company, they never do
[17:56:26 CET] <philipl> They've got a vdpau maintainer (the guy who wrote this patch) but his remit is clearly just rearranging deckchairs.
[17:57:12 CET] <philipl> He's trying to fix the fact that interlacing is built into the GL interop spec, which I guess is nice, but no movement on adding the missing decoder formats or removing the GLX dependency.
[17:58:59 CET] <philipl> but anyway, that patch is fair enough and I want to apply it.
[17:59:21 CET] <philipl> Poor guy put a bunch of effort into fixing the underlying driver bug, so it's the least I can do :-)
[19:36:44 CET] <BtbN> philipl, well, it's something I guess
[19:37:05 CET] <BtbN> The patch looks sensible to me
[19:37:34 CET] <BtbN> I'd maybe also change the log message, to indicate that it works in recent drivers, but otherwise, simple enough
[19:49:29 CET] <philipl> Ok. I will adjust and then push
[19:57:42 CET] <BtbN> I'm not aware of being the maintainer for anything vdpau? Not sure who has to "officially" okay that, but I doubt it's an issue.
[19:58:15 CET] <BtbN> Also... the commit message says "Have been addressed in Nvidia driver releases 384.59 and 410.66"
[19:58:25 CET] <BtbN> But the check only checks 410
[19:58:32 CET] <nevcairiel> it talks about two distinct issues
[19:59:14 CET] <nevcairiel> issues (1) and (2) have been fixed in drivers A and B respectively
[20:41:57 CET] <atomnuker> well I'm glad intel added vpsllvw to do variable shifts so now you don't have to hack around using pmulhsrw
[20:42:16 CET] <atomnuker> but its avx512, and no one has avx512 yet
[20:42:42 CET] <durandal_1707> how so?
[20:43:37 CET] <atomnuker> well they change chipsets every time they feel like it, new CPUs are much more expensive for not much gain and you usually can't upgrade a laptop's cpu
[20:44:59 CET] <durandal_1707> buy new laptop, you have a well paid job
[20:46:03 CET] <atomnuker> I'd rather get a big machine, with a new amd gpu
[20:58:35 CET] <atomnuker> AAARgh pmulhsrw you betray me
[20:59:20 CET] <BtbN> Do any intel CPUs outside of their Xeons have it at all yet?
[20:59:25 CET] <atomnuker> cdf probabilities are between (1 << 14) and (1 << 15), and the shifting pmulhsrw trick only works for numbers less than 1 << 14
[20:59:36 CET] <BtbN> Also, AMD GPUs sadly all aren't that great
[21:00:17 CET] <atomnuker> I know, they're slower and more expensive, but they do work with wayland
[21:01:06 CET] <philipl> BtbN: apparently I am listed as a maintainer. I guess I asked you out of habit :-)
[21:01:10 CET] <philipl> It is nvidia related after all.
[21:02:00 CET] <philipl> jkqxz: (or anyone else who knows). Has AMD officially gone all in on vaapi vs vdpau?
[21:06:38 CET] <BtbN> philipl, I think it depends on the driver in use
[21:06:45 CET] <BtbN> iirc they also have a proprietary API?
[21:06:56 CET] <BtbN> for decoding I mean
[21:07:01 CET] <BtbN> I'm aware of amf
[21:07:39 CET] <JEEB> philipl: they have VAAPI support officially
[21:07:55 CET] <JEEB> and they even seemed to have what was required for interop (no RAM copying needed) with opengl
[21:08:00 CET] <JEEB> added into vaapi
[21:08:05 CET] <JEEB> so they definitely are in the vaapi camp
[21:08:09 CET] <JEEB> (if you're talking about AMD)
[21:08:37 CET] <JEEB> and with windows they support dxva2 and d3d11, which means that their AMF thingamajig then can receive the surfaces received from those hwdecs
[22:01:41 CET] <philipl> JEEB: the amf guy was around last week trying to get some traction on reviewing and merging his last set of changes.
[22:01:50 CET] <philipl> Seemed a thoroughly thankless task.
[22:56:32 CET] <durandal_1707> what you guys think about adding bayer 10/12/14 formats support to swscale?, in similar way how is currently done, also changing 16bit bayer to output 16bit format
[23:00:41 CET] <jamrial> if some codec can output that, then sure
[23:01:16 CET] <durandal_1707> MLV and TIFF have it
[23:04:16 CET] <atomnuker> sounds fine
[23:18:22 CET] <cone-547> ffmpeg 03Werner Robitza 07master:ad5ca1fb72fc: doc/hls: fix grammar for HLS options
[23:20:42 CET] <durandal_1707> so you are ok that for bayer to any other pixel format - it goes to rgb first and than to that format?
[23:22:16 CET] <nevcairiel> sure, bayer is basically gimped rgb
[23:51:19 CET] <BBB> atomnuker: feel like addressing the 2 comments on the MR?
[23:52:26 CET] <atomnuker> BBB: I did that yesterday, didn't I?
[23:52:33 CET] <BBB> theres 2 more
[23:52:47 CET] <atomnuker> oh, right
[23:57:18 CET] <atomnuker> k done
[23:58:08 CET] <atomnuker> the (-(cdf[i] - 32768)) >> rate; thing was because that's what my simd code does, and I thought it'd be easier for compilers
[23:58:17 CET] <atomnuker> to vectorize
[23:58:26 CET] <atomnuker> though I don't think it made any difference
[23:59:15 CET] <atomnuker> after all, its a load (to load 32768 in a reg per iteration) vs a mult (by -1 and using 32768 x 8 in an always loaded reg)
[23:59:52 CET] <atomnuker> I gave up on the idea to iterate and just always do all 16 max cdf symbols at a time with 256bit regs
[00:00:00 CET] --- Wed Oct 31 2018


More information about the Ffmpeg-devel-irc mailing list