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

[burek]

[03:28:29 CEST] <philipl> BtbN: Replicated bob as a cuda kernel. now the yadif can begin :-)
[06:28:26 CEST] <philipl> BtbN: And I think I have a working cuda yadif. Looks visually identical, and I mostly understand the logic :-P
[11:27:23 CEST] <cone-636> ffmpeg 03Martin Vignali 07master:997f03cd7eb9: avfilter/setparams : update filter description
[11:27:23 CEST] <cone-636> ffmpeg 03Martin Vignali 07master:cfdbefdd90b0: avfilter/setfield, setrange : set color property to auto
[11:27:23 CEST] <cone-636> ffmpeg 03Martin Vignali 07master:6953ff714fb6: avfilter/setparams : fix colorspace option
[12:52:53 CEST] <BtbN> philipl, interesting. yadif isn't the best, but certainly enough for most uses.
[12:53:06 CEST] <BtbN> I'd still like to access nvidias adaptive algorithm from CUDA...
[12:53:37 CEST] <BtbN> Or, just use cuvid as a filter, like the API clearly intends, but nvidia never followed up on it
[13:11:23 CEST] <cone-636> ffmpeg 03Jun Zhao 07master:cc82402ed399: lavf/vc1test: fix vc1test can't probe some RCV file.
[13:11:24 CEST] <cone-636> ffmpeg 03Jun Zhao 07master:18fce29d8f1b: lavf/vc1test: add rcv to vc1test demuxer extensions
[14:14:52 CEST] <nevcairiel> the split filter probably needs to forward hardware contexts to its output pads
[14:20:32 CEST] <durandal_1707> who is "oromit" ?
[14:38:23 CEST] <durandal_1707> who is watching 360 videos a lot?
[14:39:18 CEST] <BtbN> read it backwards
[14:40:50 CEST] <nevcairiel> does anyone durandal_1707? :p
[14:41:25 CEST] <BtbN> Isn't the porn industry the only one making larger use of it?
[14:41:34 CEST] <JEEB> vimeo seems to have a bunch of them
[14:41:49 CEST] <JEEB> but yea I'm not sure if even standard VLC supports them?
[14:43:02 CEST] <JEEB> and if you have a lack of players that really means that not many people are going to watch them. I think youtube's collection of them is probably the largest and the youtube js player will be the most used player :P
[14:46:14 CEST] <BtbN> Hm, I don't understand why the split filter doesn't just work for hwframes
[14:46:50 CEST] <BtbN> It really is just av_frame_clone as a filter, which is just a helper that calls av_frame_ref, which is used for frames in various hw filters already
[15:48:35 CEST] <durandal_1707> should i name 360 filter vr360? it would convert between popular 360 projections
[15:50:52 CEST] <iive> vr implies it works with steroscopy, aka could be used for vr headset
[15:51:04 CEST] <iive> is that the case?
[15:53:36 CEST] <BtbN> In a true 360° video you can create stereoscopy for any angle I guess
[15:56:50 CEST] <iive> i thought it is harder, because the image is flat
[15:57:54 CEST] <nevcairiel> just being a 360 video doesnt automatially make for proper stereo
[15:58:35 CEST] <durandal_1707> filter name can not start with number, so simply naming it 360 is no go.
[15:58:36 CEST] <nevcairiel> you can probably fake it by varying angles slightly for each eye, but if you think about looking at the inside of a sphere, its different if you have one central camera,  or two slightly offset cameras (ie. eyes)
[16:00:57 CEST] <atomnuker> yeah, even if you used 2 360 cameras you'd have 2 perespectives where there's depth
[16:04:34 CEST] <durandal_1707> thanks for great help, filter name would be "Perigon_360_UltimateReality"
[16:06:24 CEST] <durandal_1707> it must be better & faster than that facebook filter, to be succesfull
[16:07:42 CEST] <durandal_1707> why i do not get any feedback? this is important subject! humanity future depends on it!
[16:07:59 CEST] <nevcairiel> if our future depends on  360 video, then kill me now
[16:21:35 CEST] <January> how would I make sure that a test is only run with threading enabled *and* h264 decoding enabled?
[16:26:53 CEST] <philipl> BtbN: I learned this working on the yadif thing. Even if your filter's frame management logic is hwframe safe, you still need to init an hwframes_ctx for the outlink for it to work.
[16:27:28 CEST] <durandal_1707> January: HAVE_THREADS ?
[16:27:41 CEST] <philipl> So I had to write my own set up code for the links but the core frame logic is literally the same - I just replaced the filter() function. I want to refactor yadif to actual share, rather than copy, that code.
[16:28:00 CEST] <atomnuker> philipl: you can ref your input context in case you can do it in-place, though afaik jkqxz had some concerns about inplace hw filters
[16:28:25 CEST] <January> durandal_1707: I meant to prevent the test from running at all, but I guess that is a way to fix it as well
[16:30:12 CEST] <philipl> atomnuker: You mean modifying the frames in place? That's fair. Not applicable in my particular case, and modification of frame content doesn't work on the nvdec mapped frames, but obviously there are other scenarios where it could be done.
[16:31:04 CEST] <durandal_1707> does future vulkan filter allow loading custom shaders?
[16:56:05 CEST] <atomnuker> yeah, if I write a filter for it
[16:56:27 CEST] <atomnuker> for compute shaders it'll be very easy, as all current filter shaders are compute
[16:56:36 CEST] <BtbN> philipl, you should be able to just call make_writable on CUDA frames
[16:56:54 CEST] <atomnuker> for 3d (pixel+vertex) the renderpass abstraction functions will need to be extended
[16:56:58 CEST] <BtbN> that will do the right thing, even with the mapped cuvid frames
[17:00:43 CEST] <philipl> BtbN: good to know
[18:08:26 CEST] <ePirat> BtbN, btw I saw you had a repo with the decklink sdk headers
[18:08:44 CEST] <BtbN> Needed them for the coverity builds
[18:08:53 CEST] <ePirat> BtbN, maybe this is useful to you https://github.com/ePirat/decklink-sdk
[18:09:06 CEST] <ePirat> especially in case you care about diffs between versions and such
[18:15:14 CEST] <BtbN> I only wanted something to make ffmpeg build again after the minimum version got bumped
[19:20:23 CEST] <durandal_1707> michaelni: when will new release be made?
[20:05:00 CEST] <michaelni> durandal_1707, when i have time and after as many regressions as possible have been fixed. I just looked at fate and there are quite a few machines with failures. So before thinking of doing a new release i have to look into why some of these fail, i just spoted one that looks like theres something wrong with one of my boxes
[20:40:06 CEST] <tmm1> jkqxz: can we commit those cbs fixes
[21:43:38 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07master:b737317a8813: avcodec/mpeg4videodec: Fix typo in sprite delta check
[21:50:16 CEST] <thebombzen> michaelni: I attached an updated version of my streamcopy patch (with no newline issues). Should I start a new thread on the mailing list with git-send-email? 
[21:52:01 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/10739/
[21:52:03 CEST] <JEEB> looks good to me
[21:52:13 CEST] <JEEB> at least patchwork grokked it
[21:52:24 CEST] <JEEB> (not a review, just that it seems to have been received proper)
[23:32:33 CEST] <mateo`> jamrial: hello, it looks like 662558f985f50834eebe82d6b6854c66f33ab320 introduced a regression on the mediacodec decoders. The decoder ends up receiving the bitstream in the hvcC form (for hevc) and not annex-b. The underlying bsf seems initialized twice, first time, everything is fine, second time it beleives the bitstream is already annex-b because of the newly replaced extradata (now in annex-b
[23:32:35 CEST] <mateo`> form).
[23:35:00 CEST] <mateo`> jamrial: any ideas on how to fix that ? I haven't found yet why the bsf is initialized twice (maybe because of avformat_find_stream_info() which opens a decoder)
[23:35:23 CEST] <jamrial> mateo`: yeah, it's most likely that
[23:36:13 CEST] <jamrial> and no, not really, but this commit brought other issues as well so might as well just revert it
[23:36:55 CEST] <jamrial> everything is written expecting extradata to not be altered by libavcodec during decoding. even the doxy
[23:37:42 CEST] <jamrial> which even before this change was already wrong, but only on a few decoders instead of all of them like the above commit is doing
[23:39:09 CEST] <mateo`> ok ...
[23:41:57 CEST] <mateo`> so what is the plan ? revert for now or something else ?
[23:43:48 CEST] <jamrial> revert for now, imo. will send an email first
[23:44:23 CEST] <mateo`> ok
[23:44:27 CEST] <mateo`> thanks
[23:55:05 CEST] <BtbN> isn't that a different commit?
[23:55:24 CEST] <BtbN> The one on the list is f631c328e680a3dd491936b92f69970c20cdcfc7, according to the initial mail
[23:56:06 CEST] <BtbN> hm, f631c3 doesn't even exist
[23:57:09 CEST] <nevcairiel> both exist and do the same thing
[23:57:10 CEST] <nevcairiel> dont ask me
[23:57:20 CEST] <BtbN> git.videoland.org doesn't know about it at least
[23:57:21 CEST] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f631c328e680a3dd491936b92f69970c20cdcfc7 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=662558f985f50834eebe82d6b6854c66f33ab320
[23:57:25 CEST] <BtbN> -d
[23:57:47 CEST] <BtbN> what
[23:57:53 CEST] <BtbN> I guess once is merged from libav?
[23:58:06 CEST] <nevcairiel> no thats not how merges look
[23:58:16 CEST] <JEEB> yea the merge sources also stay
[23:58:25 CEST] <JEEB> so if it's not in history then it's just not there
[23:58:48 CEST] <JEEB> oh, both exist?
[23:59:51 CEST] <nevcairiel> hm apparently one is from libav
[00:00:00 CEST] --- Tue Oct 23 2018