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

[burek]

[03:59:06 CEST] <cone-253> ffmpeg 03Raphaël Zumer 07master:eeb1c515a867: avformat/ivfenc: Comment the length field encoding process
[03:59:06 CEST] <cone-253> ffmpeg 03Raphaël Zumer 07master:d3807467b258: avformat/ivfenc: Change the length fields to 32 bits
[03:59:06 CEST] <cone-253> ffmpeg 03Raphaël Zumer 07master:9d92403add22: avformat/ivfdec: Change the length field to 32 bits
[05:27:39 CEST] <cone-253> ffmpeg 03Zhong Li 07master:949a1b3e2f75: lavc/qsv: remove vaapi device free function
[05:27:40 CEST] <cone-253> ffmpeg 03Linjie Fu 07master:5345965b3f08: lavc/qsvdec: Add GPU-accelerated memory copy support
[09:35:48 CEST] <cone-920> ffmpeg 03Paul B Mahol 07master:29327794b0be: doc/filters: mention rubberband supported commands
[09:35:48 CEST] <cone-920> ffmpeg 03Paul B Mahol 07master:24b6e968a216: doc/filters: document atempo command
[09:57:22 CEST] <cone-920> ffmpeg 03Paul B Mahol 07master:1ebac3cda9f4: avfilter/af_adelay: fix buggy behaviour
[11:31:23 CEST] <durandal_1707> its bollocks when I reply with "gonna apply set ASAP!", usual suspect appears
[11:35:41 CEST] <durandal_1707> THIS IS IT, I HAD ENOUGH OF YOU GUYS
[11:36:19 CEST] <BtbN> I can't tell anymore if he's trolling or not...
[11:36:27 CEST] <j-b> I'm going to call "Nicolas" without looking at the ml
[11:36:34 CEST] Action: j-b opens mutt
[11:36:55 CEST] <j-b> \o/
[11:37:28 CEST] <thardin> API changes do need a bit of discussion before being pusehd
[11:38:50 CEST] <BtbN> It is a _very_ minimal API change, but getting mad if more than 24h of review time are requested if also a bit over the top.
[11:39:23 CEST] <thardin> myeah
[11:39:41 CEST] <j-b> Well, that's why you need a development policy
[11:41:18 CEST] <BtbN> Not really, you need people who don't jump at each other over every little disagreement, and this would be resolved within two mails.
[11:42:29 CEST] <j-b> And that never happens
[11:42:47 CEST] <j-b> since 10y+ I've been around, it never happens
[11:43:26 CEST] <j-b> You need guidelines, to say "you need to wait 1w for API changes"
[11:47:01 CEST] <thardin> guidelines only get you so far if the actual problem is toxic people
[11:54:29 CEST] <j-b> No, because you can tell them: "this is the policy" and they don't storm out
[11:54:54 CEST] <j-b> API changes require 1week review, makes it that Paul wouldn't get pissed here, for example
[12:01:33 CEST] <nevcairiel> if you cant request an extension for a day or so because you are busy right now without someone getting mad, policys dont help at all
[12:03:12 CEST] <nevcairiel> paul always likes to play the victim card, but he is the source of  many problems himself
[12:05:47 CEST] <BtbN> On an unrelated note, I would really welcome a switch to something that's not the ML. Though I'm also not too much a fan of Gitlab. My primary experience with Gitlab involves horrible code with security issues, that's slow and laggy and with an unintuitive UI on top.
[12:06:38 CEST] <BtbN> I really like GitHubs UI. Would be nice if they had a variant to self-host.
[12:06:40 CEST] <nevcairiel> I don't mind the UI, but I find Gitlab slow. Everytime I open a dav1d MR, it takes half a minute for all the content to load
[12:07:11 CEST] <BtbN> Yeah, something in Gitlab is horribly inefficient
[12:07:31 CEST] <BtbN> We have an instance at work, with maybe 20 users in total, so usually only a single user hitting the server.
[12:07:34 CEST] <BtbN> And it still is slow
[12:09:52 CEST] <j-b> > Such interpretation is not in documentation.
[12:09:56 CEST] <j-b> And there you go.
[12:11:54 CEST] <nevcairiel> there is actually some timings in the documentation, which states a "reasonable timeframe" for "small patches" is at least 3 days.
[12:12:51 CEST] <nevcairiel> there is also a clause that people can ask for more time
[12:51:37 CEST] <durandal_1707> michaelni: could you review my patches, at least I deserve that because of how much your patches I had reviewed, also do not forget to apologize to Lynne 
[13:34:28 CEST] <Lynne> I think nicholas's issue is he's dictatorially maintaining a whole library
[13:34:44 CEST] <Lynne> and blocking whatever he sees that he doesn't like
[13:35:46 CEST] <Lynne> yet he hasn't written anything recently, what he wrote were mostly framework-side patches year(s?) ago, and durandal_1707 does most the work on lavfi that isn't hardware-related
[13:43:11 CEST] <Lynne> I do like the patch btw, it makes variable parameters far easier for filters last I looked at trying to add some to vulkan, but its not up to me :/
[13:44:33 CEST] <nevcairiel> The patch wasnt even rejected, it was only said that it needs a review
[13:44:42 CEST] <nevcairiel> and more time should be allowed for that
[13:45:47 CEST] <Lynne> I know right? he didn't ask for review specifically though, I think he just looked up the rules because they were in his favor now and decided to quote them
[13:46:17 CEST] <nevcairiel> I do agree with him however that there is no need to rush an addition to the public api after only a day
[13:47:54 CEST] <BtbN> Is this even public API?
[13:48:07 CEST] <nevcairiel> of course, opt.h is an installed header
[13:48:23 CEST] <BtbN> But it's only ever used in internal filters and codecs?
[13:49:11 CEST] <nevcairiel> its an installed header, therefor its public API. Anyone could be using our opt system if they wanted to
[13:49:34 CEST] <BtbN> Certainly not of this flag though, since the function evaluating it is not public.
[13:50:39 CEST] <nevcairiel> maybe thats a good argument for not even having it in public API if its useless in there, and thus t he patch should change
[13:51:44 CEST] <BtbN> All that stuff can't really be used outside of ffmpeg, can it? So while the header is public, it's not really part of the normal API.
[16:35:06 CEST] <Mystnom> Hi, I have a scenario where I might need to remove an element from the begin position of a dynamic array, I see av_dynarray_add_nofree which adds element to dynamic array, is there any util available to remove element from dynamic array
[16:38:00 CEST] <durandal_1707> Mystnom: if this is about developing FFmpeg itself, welcome to channel, otherwise you better ask on #ffmpeg
[16:38:26 CEST] <Mystnom> Yes its about developing a new filter in FFmpeg
[16:39:36 CEST] <durandal_1707> i'm afraid you will need to implement own structure and algorithm to handle that, depends what stuff will those arrays hold
[16:42:46 CEST] <Mystnom> Thanks, will work on it. Just wanted to be sure there is no util already available within FFmpeg
[16:43:41 CEST] <durandal_1707> depends what array will hold, and also you gonna use queue, stack or something completely different
[16:44:31 CEST] <durandal_1707> for example libavfilter/af_dynaudnorm.c implements queue for its stuff
[16:44:58 CEST] <durandal_1707> there is also audio fifo, for storing fifo of audio samples
[16:45:51 CEST] <durandal_1707> other filters works on few items, so they just use memmove with simle array
[16:45:58 CEST] <durandal_1707> *simple
[17:26:08 CEST] <BtbN> That dude is still going...
[18:30:13 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:3d262f9f326f: avfilter/af_anlms: increase max limit for mu
[19:05:06 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:1cdb7c583984: doc/filters: add more examples for afftfilt
[19:14:07 CEST] <Lynne> michaelni: are you ignoring me or hoping I would go away?
[19:22:06 CEST] <jamrial> Lynne: stop it. you're not achieving anything by harassing someone to get an apology out of them
[19:22:59 CEST] <jamrial> you're just proving Compn right, acting in such an obsessed way
[20:12:27 CEST] <tmm1> hm h264_metadata_bsf is corrupting one of my samples in some subtle way
[20:15:51 CEST] <tmm1> http://0x0.st/zwnW.png
[20:21:15 CEST] <jamrial> tmm1: post the sample if you can and command line that reproduces it
[20:26:20 CEST] <tmm1> jamrial: https://gist.github.com/tmm1/5737a57ea6b398d3e8d3cad4f12ebb49
[20:31:06 CEST] <tmm1> maybe h264_analyze is lying to me?
[20:31:47 CEST] <tmm1> still strange that one byte is missing
[20:34:54 CEST] <kepstin> iirc there's some variable length, optional, or filler fields in the h264 initialization data, so it's entirely possible to change the length without changing the meaning.
[20:35:42 CEST] <kepstin> 1 byte difference is kinda odd tho
[20:36:19 CEST] <tmm1> it also says the I slice nal starts with 0x800000 instead of 0x000000
[20:37:00 CEST] <tmm1> i noticed this after some android hardware decoder was choking on input if h264_metadata_bsf existed in the pipeline
[20:39:35 CEST] <Lynne> jamrial: you think its all my fault too, probably
[20:40:23 CEST] <Lynne> and you're okay with this dictatorship as long as you're on the right side too
[20:40:34 CEST] <durandal_1707> Lynne: its not your fault, did you got angry mails?
[20:40:36 CEST] <jamrial> tmm1: the 0x80 is the last byte of the previous nal, the itut t35 sei
[20:41:35 CEST] <jamrial> your sample then starts a new nal with 00 00 00 01 (zero_byte + start_code_prefix_one_3bytes), while the bsf changes that to 00 00 01 (start_code_prefix_one_3bytes)
[20:42:49 CEST] <jamrial> the spec apparently says the former must only happen with nals of type sps/pps, or in the very first nal of an access unit
[20:50:44 CEST] <jamrial> Lynne: i'm seeing a pretty one sided outrage
[20:51:07 CEST] <jamrial> i don't even know what pissed you so much from michael, but "ignored me" is in no way a justification for your reaction
[20:52:15 CEST] <durandal_1707> Lynne thinks his patches are no longer welcomed
[20:52:59 CEST] <jamrial> that's obviously not true
[21:01:02 CEST] <tmm1> hmm, so i guess this android decoder expects the extra 0 byte like it originally exists
[21:01:14 CEST] <tmm1> and removing it confuses h264_bitstream as well
[21:10:31 CEST] <tmm1> i'm trying to find the part of the spec that says sps/pps or start of access unit
[21:12:10 CEST] <tmm1> ah B.1.2
[21:35:11 CEST] <Lynne> durandal_1707: *her patches
[21:45:36 CEST] <durandal_1707> i told michaelni to apologize but i failed miserably
[21:46:37 CEST] <interester> and ... 
[21:47:35 CEST] <interester> guys, tell me please why I can't write onthe channel ffmpeg? I'm getting message "#ffmpeg Cannot send to nick/channel"
[21:48:41 CEST] <durandal_1707> interester: need to register nick
[21:48:58 CEST] <durandal_1707> because of spam, channel is limited
[21:50:52 CEST] <interester> @durandal_1707: thank you, but can you tell me where I can do this? 
[21:51:26 CEST] <durandal_1707> google for: registed nick on irc freenode
[21:51:31 CEST] <durandal_1707> *register
[21:51:38 CEST] <interester> :) thanks a lot
[22:12:13 CEST] <oldfriend83> I'm registered username, but still can't write on your channel ffmpeg, any thoughts? 
[22:21:27 CEST] <jamrial> you're not identified. you need to do run the "/msg NickServ identify" command
[22:21:35 CEST] <jamrial> you should have gotten the notice from NickServ about it when you logged in after registering your name
[22:28:22 CEST] <oldfriend83> I'm registered via mIRC, God knows where was that message 
[22:41:09 CEST] <oldfriend83> Ok, I got this "oldfriend83 has now been verified." BUT! yun't believe, I'm still can't write there anything 
[22:42:00 CEST] <BtbN> You are not logged in, no.
[22:51:09 CEST] <tmm1> is there any alternative to h264bitstream that's better maintained?
[22:51:20 CEST] <oldfriend83> BtbN: I'm still not logged in, right? 
[22:51:44 CEST] <BtbN> Just check your whois
[22:51:56 CEST] <BtbN> NickServ will also clearly tell you if you successfully identified
[22:53:55 CEST] <oldfriend83> as I undersand identification and logging in atre different thing? 
[22:54:11 CEST] <oldfriend83> *things
[22:56:39 CEST] <oldfriend83> Ok, tell me please where and how do I log in? 
[22:57:03 CEST] <BtbN> Just read the NickServ help.
[22:57:39 CEST] <philipl> BtbN: did you look at that cuviddec chroma patch? I didn't quite get what problem it was solving
[23:01:52 CEST] <BtbN> It appears to query the chroma format of the video and pass it to the caps check.
[23:02:07 CEST] <BtbN> Just so it can bail out early if cuvid does not support 422 or 444 I guess?
[23:03:36 CEST] <BtbN> The patch seems fine to me generally, it just seems odd that the capability check for 8 bit is plain removed. I'm not aware of any format where 10 or 12 bit decoding is supported, but 8 bit isn't.
[23:11:19 CEST] <tmm1> ok if i add an extra zero_byte in front of every H264_NAL_SLICE then the diff is less noisy, and I see that 5 bytes are missing from the contents of every slice
[23:21:35 CEST] <jamrial> tmm1: sure, but you shouldn't need to. that decoder choking on it is misbehaving
[23:30:04 CEST] <tmm1> yea but i need a workaround until the vendor fixes their decoder. i suppose i could just not modify the bitstream since all i'm using h264_metadata is for extracting 
[23:31:10 CEST] <jamrial> tmm1: just change the relevant code in cbs_h2645_assemble_fragment() cbs_h2645.c locally to always write the zero_byte
[23:34:38 CEST] <tmm1> right that's what i did, now i'm comparing the diff again because some bytes are still different and its still not playing
[23:34:54 CEST] <tmm1> so that extra zero_byte doesn't matter, its something else 
[23:35:17 CEST] <mkver> Maybe cabac zero bytes at the end of the slices that get dropped?
[23:36:04 CEST] <tmm1> yep, comparing hexdump shows bytes missing at the end of the slice data
[23:36:14 CEST] <mkver> (Sorry, I am not privy to the start of your conversation, so that could have already been ruled out.)
[23:36:33 CEST] <tmm1> where are those removed?
[23:36:44 CEST] <mkver> At the end of the NAL slices.
[23:37:03 CEST] <tmm1> i see a "Deleted trailing zeros from slice data" in cbs_h264_read_nal_unit but that code isn't triggering
[23:37:41 CEST] <mkver> It's deleted in cbs_h2645_fragment_add_nals
[23:39:48 CEST] <tmm1> thanks
[00:00:00 CEST] --- Thu Oct 10 2019