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

[burek]

[00:04:49 CET] <BBB> kierank: in my limited experience with the broken concept of vp8 alt-ref frames, Ive found that ffplay does sometimes behave weirdly if timestamps of the files are not 100% proper, maybe related to that? ffmpeg ignores that, mostly
[00:06:05 CET] <nevcairiel> how would it messing up with timestamps cause the decoder to suddenly misbehave
[00:06:44 CET] <cone-320> ffmpeg 03Jun Zhao 07master:dfdeed5a2c8f: lavfi: VAAPI VPP common infrastructure.
[00:06:45 CET] <cone-320> ffmpeg 03Jun Zhao 07master:19214f005140: lavfi: use common VAAPI VPP infrastructure for vf_scale_vaapi.
[00:06:46 CET] <cone-320> ffmpeg 03Jun Zhao 07master:92704c480e81: lavfi: use common VAAPI VPP infrastructure for vf_deinterlace_vaapi.
[00:06:46 CET] <kierank> yeah, I haven't touched any timestamp code
[00:06:47 CET] <cone-320> ffmpeg 03Jun Zhao 07master:fcf5eae4bf24: lavfi: add ProcAmp (color balance) VAAPI video filter.
[00:06:48 CET] <cone-320> ffmpeg 03Jun Zhao 07master:9bba10c174c8: lavfi: add denoise and sharpness VAAPI video filters.
[00:06:49 CET] <cone-320> ffmpeg 03Mark Thompson 07master:bda5ad305e90: v4l2_m2m: Fix free of the wrong pointer in an error path
[00:06:52 CET] <kierank> nor can I reproduce what carl sees locally
[00:08:03 CET] <wm4> I'd definitely say that it's the responsibility of the reporter to dig deeper if the dev can't reproduce any issue and has made an effort trying to reproduce it
[00:18:21 CET] <atomnuker> jkqxz: had a chance to test hwcontext_vulkan?
[00:33:05 CET] <jkqxz> BtbN:  ldts
[00:33:58 CET] <jkqxz> Though I assume you mean that pointer-free thing I just fixed (I did introduce it, after all).
[00:34:06 CET] <jkqxz> atomnuker:  Just looking at it now.
[00:34:43 CET] <jkqxz> VK_ERROR_NOT_PERMITTED_EXT doesn't exist in my headers.
[00:35:09 CET] <jkqxz> So I guess either that needs some ifdefs or configure needs to check for some version?
[00:36:43 CET] <jkqxz> The rgb24 upload/download sequence works.
[00:38:11 CET] <jkqxz> (On radv.)
[00:39:09 CET] <atomnuker> awesome, can you print dedicated_alloc_req.prefersDedicatedAllocation + dedicated_alloc_req.requiresDedicatedAllocation after pfn_vkGetImageMemoryRequirements2KHR
[00:39:34 CET] <atomnuker> curious to see if it works, your vulkaninfo did say radv supports that extension
[00:40:24 CET] <jkqxz> [AVHWFramesContext @ 0x55bde7e3fb40] dedicated_alloc_req.prefersDedicatedAllocation = 0
[00:40:27 CET] <jkqxz> [AVHWFramesContext @ 0x55bde7e3fb40] dedicated_alloc_req.requiresDedicatedAllocation = 0
[00:43:30 CET] <wm4> I thought vulkan doesn't support rgb24 for most things
[02:58:18 CET] <cone-320> ffmpeg 03James Almer 07master:388a0f7869a8: avcodec/mpeg12dec: fix preprocessor check for mpeg1_nvdec hwaccel
[05:03:20 CET] <Compn> reviewing ml mod queue
[05:03:26 CET] <Compn> since llogan is afk for a week or two
[05:03:27 CET] <Compn> Subject:	A New Form Of Cat To Human Communication
[05:03:35 CET] <Compn> spam subject lines are getting interesting !
[05:03:45 CET] <Compn> i do wish to know about this new form of cat to human communication.
[05:11:11 CET] <Compn> mod queue cleared
[05:20:25 CET] <atomnuker> reminds me of https://0x0.st/sq_V.webm
[05:51:28 CET] <Compn> bug seems familiar ....
[05:53:25 CET] <atomnuker> peloverde: https://trac.ffmpeg.org/ticket/6974
[09:00:36 CET] <nevcairiel> sounds like an encoding thing to me, is the in-band pce not repeated or something like that?
[09:03:06 CET] <nevcairiel> or more importantly, does it support writing in-band pce for adts usage at all?
[09:06:32 CET] <nevcairiel> .. apparently the adts muxer writes the in-band pce data, but it only does it once, that should probably be repeated instead
[09:07:10 CET] <Taemojitsu_> Can someone test something for me? I think ffplay and ffmpeg now limit fps to screen refresh rate, but would like to confirm it isn't some window manager setting
[09:07:38 CET] <nevcairiel> ffplay may do that, but ffmpeg most certainly doesnt, it has no display
[09:08:30 CET] <Taemojitsu_> I see it with 'ffmpeg -filter_complex color=black:r=120 -f opengl -', it's limited to my screen refresh rate of ~60
[09:09:18 CET] <Taemojitsu_> I don't know if it's always worked like this, but I'm sure that in the past ffplay would speed up videos faster than refresh rate if it fell behind with -noframedrop
[09:11:14 CET] <Taemojitsu_> I request that someone test ffplay, such as with 'ffmpeg -filter_complex color=black:r=120 -t 10 black.mp4' then 'ffplay -noframedrop black.mp4', and see if it's limited to refresh rate due the video falling behind (M-V increasing)
[09:11:51 CET] <nevcairiel> You should probably go to #ffmpeg, this channel is for development of ffmpeg, not support
[09:12:32 CET] <Taemojitsu_> I'm trying to get confirmation of a bug before I file a bug report, which is unfortunately all I can do since I don't know any programming languages
[09:13:01 CET] <Taemojitsu_> I did try #ffmpeg, no responses.
[09:13:09 CET] <nevcairiel> then wait
[09:13:17 CET] <nevcairiel> this channel is not appropriate for such requests
[13:16:43 CET] <CoreX> is there anyway to get this sorted because we really dont want to update to ffmpeg 3.* as we have stuff on ffmpeg 2.* that we need https://pastebin.com/raw/E0wCaj6J
[13:17:10 CET] <CoreX> better yet what can be done to use newer x264 with ffmpeg
[13:17:16 CET] <CoreX> ffmpeg 2.*
[13:21:29 CET] <JEEB> this channel is for the development of FFmpeg, not development with FFmpeg - so your questions would be correct on #ffmpeg
[13:22:53 CET] <nevcairiel> old ffmpeg, old libraries
[13:22:58 CET] <nevcairiel> you should update everything together
[13:23:38 CET] <nevcairiel> or stick to versions you know that work
[13:26:14 CET] <nevcairiel> presumably 2.8 is still maintained however, so maybe such a patch will make it to its next release
[13:26:34 CET] <nevcairiel> nevertheless, expecting an old branch to work with much newer libraries is always going to get you into trouble
[13:37:19 CET] <CoreX> trying ffmpeg.2.8.13 now if not working then i will just stick with old versions for abit
[15:49:24 CET] <durandal_1707> help: missing ideas what to do next
[15:54:14 CET] <BBB> write a native av1 decoder
[15:54:21 CET] <BBB> write an av1 encoder
[15:56:00 CET] <durandal_1707> something thats not that
[15:57:16 CET] <jkqxz> Add AV1 support to AVI muxer/demuxer, because the name.
[15:57:33 CET] <wm4> reserve that for apil 1st
[15:57:37 CET] <wm4> april even
[15:58:01 CET] <nevcairiel> i'm sure someone will do that anyway
[15:58:09 CET] <wm4> av1 in flv!
[15:58:11 CET] <nevcairiel> does av1 have b frames?
[15:58:19 CET] <nevcairiel> if not, its proably trivial to put it into avi anyway
[15:58:35 CET] <wm4> that sounds like a question nobody involved is allowed to answer
[15:58:47 CET] <nevcairiel> or more accurately, does it have re-ordering?
[15:59:08 CET] <nevcairiel> vp9 could probably go into avi without too many problems
[15:59:25 CET] <nevcairiel> not that i have ever seen that
[16:02:12 CET] <Gramner> add a powerpoint muxer!
[16:03:46 CET] <atomnuker> durandal_1707: ilbc decoder
[16:05:12 CET] <kierank> nevcairiel: no
[16:05:15 CET] <kierank> wm4: the spec is on github
[16:05:20 CET] <kierank> https://github.com/AOMediaCodec/av1-spec
[16:05:38 CET] <wm4> oh so it was done with a spec from the start, neat
[16:05:40 CET] <JEEB> wm4: funny enough someone mentioned they'd want to hack AV1 in FLV for RTMP
[16:05:53 CET] <JEEB> "so that people don't have to change their infra" :<
[16:06:23 CET] <JEEB> although at least they noted that they might want to get the identifier also agreed by adobe
[16:06:29 CET] <JEEB> so it's at the very least official
[16:07:23 CET] <nevcairiel> JEEB: good luck with that, adobe didnt even add hevc
[16:07:33 CET] <JEEB> yea
[16:07:41 CET] <JEEB> I know that won't happen because it didn't happen with HEVC
[16:08:10 CET] <JEEB> but at least it was better than with those certain people and not even trying to have it ratified by adobe
[16:08:29 CET] <atomnuker> wm4: lol no, the spec will be complete and valid quite some time after the bitstream freeze and then after the hard bitstream freeze
[16:08:39 CET] <wm4> aw
[16:09:40 CET] Action: wm4 stares at huge constant tables in C
[16:09:51 CET] <wm4> better than formatting it informally I guess
[16:14:58 CET] <atomnuker> don't look at av1/common/quant_common.c if you're afraid of big tables
[16:15:15 CET] <atomnuker> ~15000 lines of dense, packed to 80cols tables
[16:15:52 CET] <bencoh> could as well ship that as a blob ...
[16:16:09 CET] <atomnuker> not sure how much of that is needed or can be generated at the start/runtime
[16:17:11 CET] <ldts> jkqxz: thanks!. btw what is CID? (RE: fixes CID #142.7821 and #142.7822) I couldnt find any reference in bug tracker.
[16:17:22 CET] <atomnuker> I wonder whether the adaptable zigzag code switched to using static tables or if they're still done on runtime
[16:17:57 CET] <atomnuker> ironically the latter is quite expensive to do in hardware yet it was accepted iirc
[16:18:09 CET] <jkqxz> ldts:  Coverity ids.
[16:18:48 CET] <ldts> ah ..ok googling the documentation now (didnt know we run Coverity)
[16:18:49 CET] <jkqxz> You should probably get access to that.  Not sure who is an admin that can add you, though?
[16:19:04 CET] <jkqxz> Someone here...
[16:20:47 CET] <ldts> ah I can see coverage.ffmpeg.org. ok will find out about getting access.
[16:21:19 CET] <wm4> atomnuker: how much KB stripped binary code is that?
[16:21:47 CET] <wm4> jkqxz: probably michaelni 
[16:33:13 CET] <atomnuker> wm4: 428k unstripped, 424k stripped
[16:33:37 CET] <wm4> for the tables, or including other stuff?
[16:34:54 CET] <atomnuker> the entire file which only has the tables
[16:35:04 CET] <atomnuker> but that's not the biggest object file, not by far
[16:35:35 CET] <atomnuker> 3.9M    ./CMakeFiles/aom_dsp_encoder.dir/aom_dsp/variance.c.o
[16:35:56 CET] <atomnuker> 3.7M stripped
[16:37:00 CET] <ldts> wm4: jkqxz: going  to push (my first) your fix to v4l2_get_pts on 32 bit ABI
[16:37:12 CET] <atomnuker> though its only 1500 lines it has several functions for each block size, including rectangular
[16:37:59 CET] <wm4> ldts: fine with me
[16:38:18 CET] <wm4> ldts: btw. is there any reason why the kernel API uses timeval for PTS and not just a 64 bit value?
[16:38:56 CET] <ldts> I dont know, seems to be historical
[16:40:12 CET] <ldts> I'll come back to you if I find out its origin
[16:40:37 CET] <durandal_1707> atomnuker: i already did ilbc, but cant finish it, too much effort
[16:41:33 CET] <atomnuker> what's left to finish it? I think daddesio might be interested, he's into voice codecs
[16:42:16 CET] <wm4> ldts: I'd guess it's something about the API returning wallclock timestamps for media capture uses...
[16:42:31 CET] <jamrial> kierank: so the av1 bitstream is frozen then?
[16:42:39 CET] <daddesio> hiya
[16:42:55 CET] <durandal_1707> i told here numerous times  i wrote it and nobody gives a crap
[16:44:11 CET] <atomnuker> first time I'm hearing there's been an attempt at a native ilbc decoder
[16:55:14 CET] <daddesio> durandal_1707: what's left to finish it? :P
[16:58:50 CET] <durandal_1707> daddesio: rewrite several percent of lines
[17:20:54 CET] <ldts> wm4: jkqxz: so I am supposed to have write/push access to git://source.ffmpeg.org/ffmpeg? - no specific port/credentials needed?
[17:21:50 CET] <wm4> ldts: did you give your ssh key to anyone? if not, then unlikely
[17:22:11 CET] <ldts> yes, to michaelni 
[17:22:35 CET] <wm4> then you probably can push
[17:22:54 CET] <ldts> just dry-run returns access denied (so was wondering if that is the right repo)
[17:24:29 CET] <wm4> I use git at source.ffmpeg.org:ffmpeg as push URL, but I think that's equivalent to yours
[17:25:57 CET] <ldts> um that is probably what it is 
[17:25:58 CET] <ldts> let me try that
[17:27:10 CET] <ldts> yeah that is better. thanks!
[17:27:35 CET] <cone-355> ffmpeg 03Mark Thompson 07master:2e96f5278095: v4l2_m2m: Fix integer overflow in timestamp handling
[17:27:47 CET] <wm4> ah, wouldn't have thought that it makes a difference
[17:28:49 CET] <ldts> that is probably gitolite doing some validation (and I need to push as git user I guess)
[17:35:12 CET] <kierank> jamrial: iiuc no
[17:35:15 CET] <kierank> but soft freeze
[17:43:53 CET] <atomnuker> jkqxz: what do you think should be made public from hwcontext_vulkan's private device context? I think you said it should pretty much all be public
[17:57:06 CET] <durandal_1707> someone forgot to bump minor of lavfi numerous times
[18:02:14 CET] <jamrial> durandal_1707: just bump minor once now. the last filter addition was two commits ago after all
[18:02:46 CET] <durandal_1707> not me
[19:33:39 CET] <vrd> Hello everyone, I'm Vishal , and want to contribute to ffmpeg's works :) Could anyone please tell me which mentored projects are still available for grabs , in terms of the qualifying tasks?Thanks in advance !:D
[19:41:59 CET] <omerjerk> Please go through the list of tasks at - http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018
[19:46:20 CET] <vrd> Thank you for the reply :) I had looked at the list of projects a while ago, but was wondering if any of these tasks have been resolved, since I am quite late to the scene...
[19:46:35 CET] <klaxa> are you?
[19:47:12 CET] <vrd> :D If you put it that way...
[19:47:41 CET] <klaxa> i have been following the ML and i haven't seen anyone claim anything so far, i might be wrong though, so maybe search the ML archive for gsoc or something similar
[19:48:04 CET] <klaxa> tbh, i was also thinking of participating again this year
[19:48:34 CET] <klaxa> but i'm also not even enrolled in my master's program yet :V
[19:49:00 CET] <klaxa> but i will be during the summer
[19:49:25 CET] <vrd> Okay...:D Well I wish you all the best in that voyage! 
[19:51:48 CET] <vrd> BTW, ML is  for 'Mailing List' right? :D 
[19:52:15 CET] <klaxa> yes
[19:53:17 CET] <vrd> Thanks ! :)
[20:24:50 CET] <omerjerk> Feel free to ask in the mailing list in case of any doubts.
[20:26:35 CET] <BtbN> Do we have any samples with h264 video and resolution changes?
[20:26:52 CET] <nevcairiel> yes, there even is a fate test for that
[20:26:57 CET] <nevcairiel> so a sample is in fate
[20:27:19 CET] <nevcairiel> http://fate-suite.ffmpeg.org/h264/reinit-large_420_8-to-small_420_8.h264
[20:34:35 CET] <BtbN> you can do res changes in raw h264?
[20:35:20 CET] <BtbN> yeah, that indead breaks on any kind of hw chain
[20:35:43 CET] <BtbN> Because it wants to insert a vf_scale on the re-init
[20:35:55 CET] <BtbN> And I don't understand why it doesn't try to do so on the initial filter chain
[20:36:28 CET] <BtbN> I mean, fixing it trying to insert that scaler is easy. But I suspect something else is going on.
[20:37:26 CET] <BtbN> Maybe we should make up a fake hwaccel format, that is actually all software, just so the hw stuff can be tested with fate?
[20:48:03 CET] <wm4> maybe it needs to drain the old filter chain on format changes
[20:49:35 CET] <BtbN> It seems to be building an entirely new chain
[20:49:38 CET] <BtbN> and it fails while doing so
[20:49:47 CET] <BtbN> because it inserta a vf_scale into it
[20:53:21 CET] <BtbN> this code in ffmpeg.c is a mess
[20:54:02 CET] <wm4> I don't think ffmpeg.c inserts vf_scale, only libavfilter, but dunno
[20:54:04 CET] <wm4> and sure, it's a mess
[20:54:08 CET] <BtbN> it does
[20:54:53 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg_filter.c;h=877fd670e622ac8490d5c5a067d512b1976da62f;hb=HEAD#l464
[20:55:03 CET] <BtbN> and it's exactly that which is failing
[20:55:22 CET] <BtbN> This google-fork has it changed like that: https://github.com/fuchsia-mirror/third_party-ffmpeg/blob/master/ffmpeg_filter.c#L463
[20:55:26 CET] <BtbN> which seems sensible to me
[20:55:42 CET] <BtbN> but I'd like to understand why it only runs into that on runtime-res-changes. It looks to me like that should always explode
[20:58:32 CET] <nevcairiel> the google fork doesnt have it changed, its just old
[20:58:35 CET] <nevcairiel> thats how it used to look
[20:59:07 CET] <nevcairiel> the reason is of course that encoders dont support res changes
[20:59:15 CET] <nevcairiel> so you have to retain a fixed output size
[21:02:29 CET] <BtbN> oh, so it indeed is there intentional
[21:03:13 CET] <BtbN> So I guess this needs logic for every possible hw format to insert a scaler...
[21:03:31 CET] <BtbN> Or res changes are plain not supported for hwaccel
[21:05:59 CET] <BtbN> For nvdec/cuvid, adding hwdownload and format=nv12 to the end of the chain solves the issue
[21:06:41 CET] <jkqxz> Not supported in general.  It's the hwcontext information changing that is the real problem - you end up needing to recreate everything.
[21:06:50 CET] <BtbN> I guess in a more general sense, the logic should be extended to only insert a scaler if the resolution actually changed, and not just is set in general
[21:07:06 CET] <BtbN> then just having your own scale filter in the filter chain, so the output res is fixed to begin with, won't cause you any issues
[21:08:01 CET] <BtbN> cause in this limited case, just commenting out the auto-inseted scaler works just fine
[21:08:02 CET] <jkqxz> Some components would be able to keep the same output hardware context and therefore avoid the need to reconfigure everything after that point, but that runs into inflexibility in reconfiguring libavfilter.
[21:08:14 CET] <BtbN> but there's a scale_npp in the chain that always outputs the same res
[21:09:03 CET] <BtbN> Why would the hwcontext need re-configuration?
[21:09:10 CET] <BtbN> Only a potential hw_frames_ctx would
[21:09:38 CET] <jkqxz> hw_frames_context holds the hardware context information about a link.
[21:09:58 CET] <jkqxz> If you change it, you need to reconfigure the thing on the other end of that link.
[21:10:15 CET] <BtbN> Isn't it only a hw device ctx?
[21:10:24 CET] <jkqxz> And we don't have the infrastructure to do that in any sane way, so "not supported" is the only general answer.
[21:28:48 CET] <wm4> wouln't fixing that require inserting hwdec specific scale filters
[21:29:02 CET] <nevcairiel> among other things
[21:29:04 CET] <wm4> I mean there's no reason why an encoder couldn't change the hwframes ctx, or is there
[21:29:17 CET] <wm4> as long as it uses the same device
[21:29:19 CET] <nevcairiel> i wonder why encoders want a hwframes ctx anyway
[21:29:27 CET] <nevcairiel> most dont even access it beyond the device inside of it
[21:29:40 CET] <wm4> because that's how hwdec AVFrames work
[21:29:56 CET] <nevcairiel> why couldnt it work with a device ctx instead
[21:30:21 CET] <wm4> dunno, it might need the surface size or sw_format for example
[21:31:15 CET] <nevcairiel> take nvenc for example, it doesnt access anything of the frames ctx except getting to the device ctx
[21:32:02 CET] <wm4> doesn't matter, the invariant for cuda frames is that they have a frames context set
[21:32:22 CET] <nevcairiel> doesnt have to be cuda frames, nvenc takes d3d11 as well
[21:33:31 CET] <nevcairiel> in practice this is giving me some headaches, I have an external source of d3d11 frames that I want to encode, and I cant really make a fully functional hwframes ctx, because I cant let it allocate the frames for me
[21:33:48 CET] <nevcairiel> now in practice i can basically create an empty hwframes ctx and because nvenc never touches it, stuff doesnt break
[21:33:51 CET] <nevcairiel> but its just ugly
[21:34:31 CET] <wm4> I think that's how it's supposed to work
[21:34:51 CET] <wm4> personally I'd probably prefer if AVFrame.data[0] just pointed to s truct containing all info
[21:35:08 CET] <wm4> instead of weirdly attaching a frame pool to the AVFrame
[21:36:20 CET] <nevcairiel> so basically, this hwframes thing doesnt really consider wrapping external frames
[21:36:54 CET] <wm4> depends how you look at it
[21:37:22 CET] <nevcairiel> creating a hwframes context and manually creating an AVBufferPool just to have it empty is just awkward
[21:37:57 CET] <wm4> I don't think you have to create an AVBufferPool (the hwframes code might do that internally, sure)
[21:38:22 CET] <nevcairiel> wouldnt it allocate frames then?
[21:38:29 CET] <nevcairiel> not that it really hurts to do that, but its just ugly
[21:39:45 CET] <wm4> no, if you don't set an initial pool size it won't
[21:40:10 CET] <wm4> (although merely creating a vaapi hwframes context will create and destroy a small "test" surface to probe some properties)
[21:41:09 CET] <wm4> (well, "small" - it allocates one according to the frame size fields)
[21:42:22 CET] <nevcairiel> i should probably just test if this works. Sending a faux hwframes context through avfilter if scaling is required and/or to nvenc
[21:42:28 CET] <nevcairiel> also i should finish the d3d11 vpp filter
[21:44:22 CET] <nevcairiel> silly people complaining that downscaling UHD in software is too slow :)
[22:08:47 CET] <BtbN> nevcairiel, wm4, at least nvenc only uses the hw_frames_ctx to get the CUDA context. And it works perfectly fine with only a hw_device_ctx.
[22:09:31 CET] <BtbN> The scale filters have their own hw_frames_ctx inside of them anyway
[22:09:54 CET] <BtbN> So the frames that reach the encoder would actually come from the same frames context
[22:10:15 CET] <BtbN> I don't think ffmpeg.c should insert hw specific filters
[22:10:31 CET] <BtbN> but it should not try to insert an sw filter into a chain that can't possibly support it.
[22:11:02 CET] <BtbN> It's then up to the user to have a filter graph that supports res changes, like any of the scale filters manually in them
[22:11:52 CET] <wm4> ffmpeg.c can't know if vf_scale supports hw, but I guess it can assume that it doesn't
[22:12:29 CET] <BtbN> it could check its input formats for the one it has at hand
[22:48:30 CET] <peloverde> atomnuker: ADTS muxer should take a header_rate AVOption TS muxer and segment muxer should set it according to some magic when nesting
[22:48:38 CET] <peloverde> if we ever get an SBR encoder similar is needed
[22:53:05 CET] <peloverde> Though that probably breaks stuff if there are already multiple PCEs in the stream and they vary
[22:54:11 CET] <peloverde> aac transport layering is a debacle
[22:54:19 CET] <peloverde> how does segmenting avc hander header changes?
[00:00:00 CET] --- Tue Jan 23 2018