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

[burek]

[00:24:54 CET] <cone-599> ffmpeg 03Robert Nagy 07master:856b7cae9f40: avfilter/vf_idet: added more YUVA formats to idet query_formats
[08:32:54 CET] <mindfreeze> hey
[11:14:13 CET] <wm4> jkqxz: can you ack my vdpau patch?
[11:57:58 CET] <wm4>     char *recommended_encoder_configuration;
[11:58:02 CET] <wm4> was this for ffserver?
[11:58:09 CET] <wm4> we should probably deprecate this field
[12:04:07 CET] <RiCON> wm4: seems it was for ffm https://github.com/FFmpeg/FFmpeg/commit/6690d4c3f53bd46144f3c13afcc77bcca3f7bb0b
[12:05:55 CET] <wm4> yeah
[12:06:49 CET] <wm4> it's without any use now
[12:17:55 CET] <jkqxz> wm4:  Done.
[12:19:59 CET] <wm4> thanks
[12:23:12 CET] <wm4> I think the changed if you pointed out is different
[12:25:12 CET] <jkqxz> How so?
[12:25:28 CET] <wm4> I replied
[12:25:29 CET] <jkqxz> Both should be set iff the loop finds a usable sw_format.
[12:26:39 CET] <wm4> it checks only the static const array for that
[12:26:50 CET] <wm4> so it's not affected by the dynamic capability check
[12:27:41 CET] <wm4> so that would mean it allows creating the framesctx even though the associated chroma format might not be supported by the vdpau impl
[12:28:17 CET] <jkqxz> Ohright, priv->pix_fmts could be a list containing only NONE.
[12:29:10 CET] <jkqxz> Then yes, use your way.
[12:29:14 CET] <wm4> (also btw.: technically speaking it'd be of course legal that a chroma format is supported while no transfer formats for that format exist, but that would be more code, and not worthwhile anyway)
[12:29:17 CET] <jkqxz> (Email still hasn't turned up.)
[12:29:52 CET] <jkqxz> Maybe it could be used with the postproc stuff even if it can't be transferred directly?
[12:30:16 CET] <jkqxz> Though given the expected number of implementations this probably isn't very useful to consider.
[12:30:22 CET] <wm4> theoretically, but yes
[12:30:35 CET] <wm4> I'd need to load another function pointer etc.
[12:39:12 CET] <cone-407> ffmpeg 03wm4 07master:43e1ccfea186: http: cosmetics: reformat reconnect check for better readability
[12:39:13 CET] <cone-407> ffmpeg 03wm4 07master:cbbb2067341d: hwcontext_vdpau: implement av_hwdevice_get_hwframe_constraints()
[14:54:50 CET] <atomnuker> jkqxz: could you take a look at https://github.com/atomnuker/FFmpeg/blob/exp_vulkan/libavutil/hwcontext_vulkan.c ?
[14:55:35 CET] <atomnuker> there's something wrong with the way I set valid sw formats in constraints and vulkan_transfer_get_formats
[14:56:17 CET] <atomnuker> so I end up with ctx->sw_format == 0 in vulkan_pool_alloc() and don't know how big the buffer I allocate should be
[15:47:36 CET] <JEEB> woah, that's quite some changes in those forks of FFmpeg, libass, mpv :D
[15:47:58 CET] <bencoh> ?
[15:48:04 CET] <JEEB> (I love it how the guy decided that fixing MPEG-TS timestamps in FFmpeg was too hard and added support for the MPEG-TS timestamp overderp in libass)
[15:48:29 CET] <JEEB> bencoh: https://trac.ffmpeg.org/ticket/5893#comment:3
[15:48:51 CET] <JEEB> someone hacked around to make things work for him for Japanese broadcasts :)
[15:48:58 CET] <bencoh> "those fork" referring to the last comment?
[15:49:09 CET] <JEEB> yes
[15:49:18 CET] <JEEB> the repos under 0p1pp1
[15:49:24 CET] <JEEB> ffmpeg,libass,mpv
[15:49:50 CET] <bencoh> I don't see the mpv one, but yeah
[15:49:54 CET] <JEEB> https://github.com/0p1pp1/mpv/commits/isdb-0.25
[15:50:02 CET] <bencoh> ah
[15:50:10 CET] <JEEB> it was linked in the libass README
[15:50:21 CET] <bencoh> isdb support is actually a good thing :)
[15:50:41 CET] <atomnuker> " support PTS rollover in MPEG-TS " <- a commit in libass
[15:50:43 CET] <JEEB> yes
[15:50:48 CET] <bencoh> :))
[15:50:48 CET] <atomnuker> ah, yes, libass is the proper place for this
[15:51:01 CET] <JEEB> as I noted, the guy decided that it was E_TOO_MUCH_EFFORT to fix the timestamps in the mpegts demux ;)
[15:51:10 CET] <bencoh> like JEEB said he probably gave up on fixing it in ffmpeg :)
[15:51:39 CET] <nevcairiel> ffmpeg even handles simple cases of single rollovers these days
[15:51:42 CET] <JEEB> there were some people here who also fought for being able to access the "original timestamps" in the mpegts demuxer
[15:52:14 CET] <JEEB> although I brought up the "fix it with an option" thing which seemed to resonate with some of those people (too bad we don't have multiple timestamp fields)
[15:52:15 CET] <wm4> probably because they knew libavformat would get it wrong
[15:52:19 CET] <wm4> (as usual)
[15:52:28 CET] <atomnuker> ...there are people here who think mpegts is the best and only solution for streaming
[15:52:39 CET] <JEEB> my idea was to just rip the thing from upipe or so
[15:52:41 CET] <wm4> lavf utils.c has so much timestamp shit and most of it is probably subtly or fully broken :)
[15:52:45 CET] <JEEB> yes
[15:52:46 CET] <wm4> (or unnecessary)
[15:52:46 CET] <bencoh> I wonder why he actually had to fix it while DVB subtitles work, though
[15:52:57 CET] <atomnuker> complete with 188 byte packets giving huge overhead and timestamps with insufficient bits (e.g. less than 64)
[15:52:58 CET] <JEEB> I bet DVB subs also fsck off
[15:53:04 CET] <bencoh> maybe
[15:53:19 CET] <JEEB> it's just that a lot of API clients try to unfsck the timestamps that lavf gives them, among other things
[15:53:42 CET] <bencoh> atomnuker: well, mpegts is a good solution for streaming
[15:53:58 CET] <atomnuker> no it isn't, you just say it is because its muh indistry sstaandard
[15:54:00 CET] <JEEB> for its time it was, by now the main part is that the 188 byte limitation is derp'd
[15:54:20 CET] <JEEB> something as dynamic (things can appear/disappear dynamically) and no static packet sizes would be better
[15:54:29 CET] <nevcairiel> there are no other good solutions for streaming, all other containers have not been designed for streaming, and they only hack-jobed it in afterwards because it was cool
[15:54:41 CET] <bencoh> nevcairiel: exactly
[15:54:51 CET] <nevcairiel> mp4 for streaming? dont make me laugh, its the worst hack ever
[15:55:10 CET] <bencoh> matroska does a better job than mp4, but still
[15:55:45 CET] <atomnuker> nevcairiel: rtp approached something okay because its simple, but then its fucking ruined by this clock crap
[15:56:00 CET] <nevcairiel> doesnt rtp basically stream mpegts
[15:56:10 CET] <wm4> I wonder why they perpetuate this fragmented streaming bullshit
[15:56:21 CET] <nevcairiel> wm4: easy to cache on cdns
[15:56:36 CET] <wm4> just make your CDN output concatenated fragments
[15:56:37 CET] <atomnuker> nevcairiel: not necessarily, you can put uncompressed over it (rfc4175), opus packets, etc.
[15:56:54 CET] <JEEB> nevcairiel: yet they're trying to push it to MMTP
[15:56:57 CET] <wm4> or fix your cdn infrastructure, instead of forcing everyone else to deal with complex hacks
[15:57:03 CET] <bencoh> rtp doesn't do much (and doesn't give you much either) though
[15:57:16 CET] <atomnuker> wm4: I think the main reason is streaming providers want instant quality changes
[15:57:28 CET] <bencoh> it just helps with reordering/dejittering at most
[15:57:28 CET] <atomnuker> which is why they started putting hacks in codecs
[15:57:41 CET] <nevcairiel> streaming providers preferably want the user to only directly interact with dumb web caches
[15:57:42 CET] <atomnuker> with reference picture scaling, quasi keyframes
[15:57:44 CET] <nevcairiel> not smart servers
[15:57:47 CET] <nevcairiel> because thats cheaper
[15:57:59 CET] <nevcairiel> so they need to distribute something that "easy" and requires no server logic
[15:58:04 CET] <bencoh> cheaper and easier to scale yeah
[15:58:06 CET] <nevcairiel> let the client figure it out
[15:58:23 CET] <JEEB> yea
[15:58:34 CET] <wm4> as usual with webshit
[15:58:42 CET] <nevcairiel> performance-wise its fine, its not like its expensive to do this client-side, its just complicated
[15:58:43 CET] <JEEB> the whole move from RTSP to HTTP was because they wanted dumb HTTP cache infra to be reused for streaming
[16:01:15 CET] <nevcairiel> (not that RTSP/RTP ever was fully reliable in avformat, it sucks for all things web streaming in my experience)
[16:01:30 CET] <JEEB> yea
[16:01:41 CET] <JEEB> (raw) UDP only works better because it makes its own thread
[16:02:02 CET] <nevcairiel> the thread definitely helps, before that it had so much packet loss
[16:02:04 CET] <JEEB> I was just noting in general since RTSP for a while was a thing
[16:02:16 CET] <JEEB> which streaming providers used with symbian etc
[16:02:28 CET] <JEEB> (in during someone having symbian C++ development PTSD)
[19:20:14 CET] <jkqxz> atomnuker:  Some of this stuff looks like it should be exposed directly.
[19:20:18 CET] <jkqxz> I think mem_type_flags should just be a member of AVVulkanFramesContext (and use the guess it if not set).
[19:20:24 CET] <jkqxz> The queue somehow as well.
[19:20:46 CET] <atomnuker> I just realized AV_PIX_FMT_YUV420P Is 0
[19:20:55 CET] <wm4> haha
[19:21:09 CET] <atomnuker> but the question now is why is yuv420p picked
[19:21:10 CET] <wm4> I suggested changing AV_PIX_FMT_NONE to 0, but it wasn't very popular
[19:21:29 CET] <atomnuker> when I'm sending yuv444p
[19:22:04 CET] <jkqxz> A load of the members of AVVkImage aren't used at all in the hwcontext, which feels wrong.
[19:22:44 CET] <jkqxz> And I'm not sure buffers want to be there at all.  The external function is a pretty evil API/ABI fix.
[19:23:24 CET] <atomnuker> hm, you might be right, maybe api users/filters ought to make image views themselves
[19:23:36 CET] <atomnuker> so to interpret whatever's in the images as they like
[19:24:00 CET] <atomnuker> I'm rewriting avvkimages atm so I'll commit something new soon
[19:25:13 CET] <atomnuker> do you have any ideas why the order of pix_fmts in get_constraints changes what sw_format is set to? if I set what I want first I get what I shold when I allocate frames
[19:25:14 CET] <jkqxz> Can you add a comment exactly what AV_PIX_FMT_VULKAN actually contains?  It's not immediately obvious.
[19:26:35 CET] <atomnuker> yep will do, its kinda clever, the planes are directly mapped to the data pointers, and the avvkframe struct is contained in the avbufferref
[19:26:36 CET] <jkqxz> What sw_format is set to in hwupload?
[19:26:56 CET] <atomnuker> -vf scale=dst_format=yuv444p,hwupload,hwdownload,format=yuv444p
[19:27:07 CET] <atomnuker> OH
[19:27:27 CET] <jkqxz> Isn't that just libavfilter format negotiation messing everything up?
[19:27:38 CET] <atomnuker> nvm, I thought I had to set format for hwupload, nvm
[19:27:55 CET] <atomnuker> jkqxz: not sure
[19:28:15 CET] <atomnuker> it works for other hwcontexts
[19:28:33 CET] <jkqxz> The stuff which comes out of get_hwframe_constraints is just returned directly by query_formats.
[19:28:41 CET] <nevcairiel> most others dont deal in a variety of software formats
[19:29:40 CET] <jkqxz> OpenCL does, but that has supports pretty much everything so anything sane works without conversion.
[19:30:28 CET] <jkqxz> I can't try this right now, I'll have a look in a bit.
[19:31:01 CET] <atomnuker> thanks
[19:33:07 CET] <durandal_1707> why everything starts perfect and ends pos?
[19:36:31 CET] <atomnuker> wm4: wouldn't making AV_PIX_FMT_NONE==0 break the api/abi?
[19:36:52 CET] <atomnuker> since programs assume negative pix fmts are invalid
[19:36:58 CET] <wm4> ABI yes, API, debatable
[19:37:15 CET] <wm4> ffmpeg code tends to use fmt<0 to check for NONE, which is fucking dumb
[19:37:57 CET] <durandal_1707> in the begining was yuv420p
[19:41:53 CET] <atomnuker> then came yuvj420p and was immediately deprecated
[19:42:16 CET] <durandal_1707> really?
[19:42:19 CET] <durandal_1707> lol
[19:44:07 CET] <wm4> who will remove that POS
[19:44:21 CET] <durandal_1707> you
[19:45:32 CET] <durandal_1707> how will format negotiation work if color range field is added?
[19:46:29 CET] <atomnuker> the same, only color range is attempted to be preserved, I would think
[19:46:39 CET] <wm4> I have no idea how format negotiation works in lavfi (I only knows it's a fucking PITA for API users)
[19:46:56 CET] <durandal_1707> also players like ffplay that want yuv will need to imsert filter
[20:00:59 CET] <cone-906> ffmpeg 03Michael Niedermayer 07master:a1f38c75893c: avcodec/ac3dec_fixed: Fix integer overflow in scale_coefs()
[20:01:00 CET] <cone-906> ffmpeg 03Michael Niedermayer 07master:6887e4124347: avcodec/jpeg2000: Check sum of sizes of band->prec before allocating
[20:01:01 CET] <cone-906> ffmpeg 03Michael Niedermayer 07master:83e34ae3c2b3: avcodec/wavpack: Fix integer overflows in wv_unpack_stereo / mono
[20:03:42 CET] <durandal_1707> Chloe: what happened to that registering removal?
[20:17:49 CET] <Chloe> durandal_1707: im doing it this week (now actually), rebasing is hard I guess
[20:26:36 CET] <feliwir> hey everyone. I am currently working on an opensource project reimplementing a couple of EA games. Related to this: the EA muxer and Vp6 encoder missing in FFMPEG. If i were to add those at somepoint would sth like this be accepted into upstream?
[20:26:41 CET] <feliwir> I am not sure because vp6 is a fairly old format
[20:27:04 CET] <feliwir> The current decoder was written by Aurelian Jacobs back in 2008 or sth like that
[20:27:12 CET] <durandal_1707> we have stupid cinepak encoder...
[20:27:14 CET] <JEEB> feliwir: to be honest both muxers and encoders have to be specifically requested by the API client
[20:27:30 CET] <JEEB> so encoders and muxers are IMHO less problematic than decoders and demuxers which can end up being probed
[20:28:38 CET] <feliwir> JEEB, so i can just start implementing and when they work they'll get accepted? :D
[20:29:54 CET] <atomnuker> yep
[20:30:30 CET] <atomnuker> though before you go and write mv search take a look at the one we already have
[20:31:33 CET] <atomnuker> not sure what the dcts in vp6 are like but I bet they share some forward/bwd code too, but anyway that's down the line
[20:33:14 CET] <feliwir> there is some shared vpX code iirc. But will probably not start in the very near future
[21:44:45 CET] <thardin> hum, avio_read() does not consider getting fewer bytes than requested to be an error right?
[21:45:34 CET] <thardin> ooh ffio_read_size
[23:06:21 CET] <jkqxz> atomnuker:  Is the device index fixed?  The name is pretty unwieldy, and will be a huge pain if it ever contains some separator characters.
[23:06:46 CET] <atomnuker> device index?
[23:06:57 CET] <atomnuker> I only handle device names
[23:07:34 CET] <jkqxz> [AVHWDeviceContext @ 0x555b831ccec0]     0: AMD RADV POLARIS11 (LLVM 3.9.1) (discrete)
[23:07:37 CET] <jkqxz> [AVHWDeviceContext @ 0x555b831ccec0]     1: Intel(R) HD Graphics (Coffeelake 3x8 GT2) (integrated)
[23:07:38 CET] <atomnuker> there's code to handle device=NULL where it'll try to pick the most useful card (prefers discrete to integrated to virtual)
[23:07:53 CET] <jkqxz> Names are not fun ^
[23:08:03 CET] <jkqxz> Do any other drivers give more helpful ones?
[23:09:01 CET] <nevcairiel> names are indeed no fun, without copy paste you're mostly screwed, a stable index would be nice
[23:09:02 CET] <jkqxz> It fails to create on the Polaris 11 with "Device creation failure = VK_ERROR_EXTENSION_NOT_PRESENT".  The Coffee Lake does work.
[23:13:39 CET] <atomnuker> jkqxz: yep, pushed a fix, no extensions needed now
[23:13:44 CET] <atomnuker> should run now
[23:14:40 CET] <atomnuker> here's a command line example if you need one: "./ffmpeg_g -vulkan_device "Intel(R) HD Graphics 520 (Skylake GT2),extensions=VK_EXT_debug_report" -i example -vf scale=dst_format=yuv444p,hwupload,hwdownload,format=yuv444p -f null -"
[23:14:52 CET] <jkqxz> Wrt your -vf scale... thing above, lavfi is screwing you because dst_format on the scale filter does not change what it sees in query_formats.
[23:15:04 CET] <jkqxz> Just use "format=yuv444p" instead to get further.
[23:15:09 CET] <jkqxz> Yeah, that one.
[23:15:30 CET] <atomnuker> put that where?
[23:15:39 CET] <jkqxz> -vf 'format=yuv444p,hwupload,hwdownload,format=yuv444p'
[23:15:40 CET] <atomnuker> oh nvm
[23:15:45 CET] <nevcairiel> why do you have a format call in there twice anyway, shouldnt it still be 444p at the end anyway
[23:15:51 CET] <jkqxz> Now hwupload is complaining at me.
[23:15:55 CET] <atomnuker> I fudged it for you, look in get_costraints
[23:16:13 CET] <atomnuker> I commented out the code which enabled reporting all supported sw_formats
[23:16:43 CET] <jkqxz> nevcairiel:  hwdownload can't determine the download format at query_formats type, so you need to force it in the following link if it isn't expected to match.
[23:16:52 CET] <jkqxz> *query_formats time
[23:17:25 CET] <atomnuker> if you comment "constraints->valid_sw_formats[count++] = AV_PIX_FMT_YUV444P;" and uncomment the loop above and try my command line it'll fail
[23:17:31 CET] <jkqxz> (It can't see hw_frames_ctx-~>sw_format
[23:17:34 CET] <jkqxz> (
[23:19:04 CET] <jkqxz> Hmm.  My mapped frame doesn't have any pointers, so av_frame_copy() into it fails.
[23:19:39 CET] <atomnuker> that's odd, any failures?
[23:20:02 CET] <jkqxz> All looks happy before that point.
[23:20:28 CET] <atomnuker> are you using the amd? try it on intel
[23:20:49 CET] <jkqxz> That's the Intel.
[23:21:01 CET] <jkqxz> Rebuilding with your extension change now to try AMD.
[23:22:15 CET] <jkqxz> The AMD gets "Failed to map image memory = VK_ERROR_MEMORY_MAP_FAILED".
[23:22:42 CET] <jkqxz> Aha, the Intel works in this version, though.
[23:24:17 CET] <jkqxz> Having the image mapped at all times looks very suspicious.
[23:25:41 CET] <atomnuker> the spec doesn't warn about any penalty for doing so and I didn't see any for mpv's old vo_vulkan, but that'll be an easy change to make
[23:26:36 CET] <atomnuker> can you post full vulkaninfo somewhere?
[23:28:33 CET] <jkqxz> <https://0x0.st/sNgK.txt>
[23:34:40 CET] <atomnuker> that's kinda an old version of vulkan, I have 1.0.65 here, also isn't llvm 3.9.1 quite old?
[23:35:02 CET] <atomnuker> can't see why it would fail on amd though, maybe I broke something, will try to debug later
[23:35:42 CET] <jkqxz> Hmm.  The vulkan headers are probably whatever is in Debian?  The ICDs are Mesa from an hour ago.
[23:36:56 CET] <jkqxz> What devices do you have to test on?
[23:38:04 CET] <atomnuker> 2 absolute monsters: an intel 520 and, believe it or not, an intel 530... just need to reinstall an os on that thing
[23:38:10 CET] <atomnuker> (read: 2 toy gpus)
[23:40:00 CET] <atomnuker> but anyway the issue is figuring out the weirdness with valid_sw_formats in get_constraints
[23:40:11 CET] <jkqxz> Isn't it what I said above?
[23:40:38 CET] <atomnuker> "@jkqxz | (It can't see hw_frames_ctx-~>sw_format" ?
[23:41:51 CET] <jkqxz> That's hwdownload.  I mean "lavfi is screwing you because dst_format on the scale filter does not change what it sees in query_formats".
[23:42:31 CET] <jkqxz> ./ffmpeg_g -y -init_hw_device 'vulkan=p11:AMD RADV POLARIS11 (LLVM 3.9.1)' -init_hw_device 'vulkan=cl:Intel(R) HD Graphics (Coffeelake 3x8 GT2)' -i test.mp4 -an -filter_hw_device cl -vf 'format=yuv444p,hwupload,hwdownload,format=yuv444p' -f null -
[23:42:48 CET] <jkqxz> Works for me with right thing uncommented in get_constraints.
[23:43:55 CET] <atomnuker> oh, I see, it works now
[23:44:49 CET] <atomnuker> it probably crashes on the amd because of the ycbcr formats, let me push a fix which ought to make it work in a min
[23:44:50 CET] <jkqxz> The hwcontext behaviour is all correct, just lavfi.
[23:47:23 CET] <atomnuker> k, pushed something that ought to make amd work
[23:47:52 CET] <atomnuker> (thinking maybe I should drop ycbcr formats and just use base vulkan formats)
[23:49:09 CET] <jkqxz> Same MEMORY_MAP_FAILED.
[23:50:03 CET] <atomnuker> hmm
[23:50:14 CET] <atomnuker> also if I try "-vf format=yuv420p,hwupload,hwdownload,format=yuv420p" it fails with invalid hwdownload format
[23:52:15 CET] <atomnuker> (also can you post the printouts after "GPU listing:"? maybe the heuristics pick inadequate memory_type and queue_family
[23:52:20 CET] <atomnuker> (on the amd)
[23:53:15 CET] <jkqxz> yuv420p fails because of your check "if (hwfc->sw_format)" in vulkan_transfer_get_formats().
[23:53:25 CET] <jkqxz> (yuv420p is zero, so false.)
[23:54:25 CET] <jkqxz> Or the later one.  Something there.  The result is that it's not in the transfer formats list, so hwdownload rejects it.
[23:55:41 CET] <jkqxz> <https://0x0.st/sNgQ.txt>
[00:00:00 CET] --- Tue Jan 16 2018