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

[burek]

[00:08:00 CEST] <jkqxz> tmm1:  Different window size?
[00:09:30 CEST] <tmm1> yea that seems like the only change
[00:09:48 CEST] <tmm1> i'll try forcing the old value to see if that helps
[00:13:32 CEST] <jkqxz> The old code would overflow the window size value, which is why it's come out so different.  6000k * 1000 > 2^32.
[00:19:56 CEST] <tmm1> ahh ok, i was wondering why the math didn't make any sense
[00:22:39 CEST] <tmm1> jkqxz: so you think its the driver that's broken and the random overflowed calculation before just happened to work?
[00:23:57 CEST] <tmm1> the other difference i see is that .ICQ_quality_factor is passed now when it wasn't before
[00:25:46 CEST] <tmm1> actually i bet that's it.. its getting clipped to 1 which would explain the low quality
[00:40:14 CEST] <tmm1> no luck removing that or setting window size to what it was being calculated as before
[00:40:30 CEST] <tmm1> afaict the rc params being passed in are identical but the behavior is still different
[01:35:02 CEST] <cone-701> ffmpeg 03Michael Niedermayer 07master:86d13e95e760: doc/fate: Document how to request samples upload access
[03:22:11 CEST] <Chagall> are all pre-release commit hashes in APIchanges just xxxxxxxxxx?
[03:30:02 CEST] <Chagall> hope I did it right
[03:31:45 CEST] <jamrial> Chagall: the xs are just a placeholder since the hashes aren't known until committed, of course
[03:32:03 CEST] <jamrial> they are usually replaced at the time of a release
[03:32:11 CEST] <Chagall> I thought so :)
[07:00:59 CEST] <Compnno> jkqxz,  asukhanov_, hehe the only program i know that uses libavformat's debug motion vectors is fast5, a video forensics tool
[10:21:39 CEST] <cone-353> ffmpeg 03Carl Eugen Hoyos 07release/4.1:02537719538b: lavc/tableprint_vlc: Remove avpriv_request_sample() from included files.
[10:42:30 CEST] <philipl> BtbN: I'll take a look at the nvdec reconfigure stuff next week to see if can be used for this multi-resolution stuff.
[10:56:02 CEST] <nevcairiel> there needs to be proper internal API support for this first
[10:56:10 CEST] <nevcairiel> the patches on the ML all try to do  it cheap and hackish
[11:27:31 CEST] <BtbN> What patches now? I'm not seeing anything nvdec on the ML
[11:27:48 CEST] <nevcairiel> not for nvdec, the general resolution change thing
[11:28:14 CEST] <nevcairiel> because right now you get no chance to handle it on hwaccel level because the framework will always just re-create stuff
[11:30:40 CEST] <BtbN> I mean, that works
[11:30:55 CEST] <BtbN> And re-creating nvdec should be relatively cheap
[11:31:08 CEST] <BtbN> The expensive stuff needs to be re-created anyway if the res changes
[11:31:20 CEST] <nevcairiel> the point of this vp9  nonsense is that its supposed to carry reference frames over the res change boundary
[11:31:26 CEST] <nevcairiel> someone was drunk when designing that shit
[11:31:52 CEST] <BtbN> What patch even is this? I'm not seeing anything about that in the last weeks of ML backlog
[11:35:40 CEST] <kurosu> Lynne / asukhanov_ / lotharkript: went over quickly the latest specs - I'm not happy about what I've commented (and I hope it brushes nobody the wrong way), but I don't see myself having another 30 minutes for it in the foreseeable future
[11:36:37 CEST] <kurosu> also, maybe I'm overly "litigious"/process-obsessed, but this discussion really needs time to crystallize
[11:37:19 CEST] <kurosu> this isn't an internal ffmpeg thingie, but something several users may have use of, so a wider audience is needed
[11:37:52 CEST] <kurosu> eg please post that to the ffmpeg-devel thread
[11:38:29 CEST] <kurosu> (I would recommend any other medium, like the actual ffmpeg user mailing list, but that's already overboard)
[11:44:42 CEST] <durandal_1707> Lynne: i fixed 16 mlp for me, except last frame encoding
[13:30:36 CEST] <mkver> If a function does not take ownership of a packet, it means that the packet must be untouched when the function returned as if the packet was const? It does not only apply to the packet's data, right?
[13:31:47 CEST] <Lynne> it can't change a packet if the packet has been ref'd elsewhere
[13:34:48 CEST] <mkver> And if the packet is not refcounted?
[13:37:47 CEST] <Lynne> then modifying it is okay beause everything else made a copy of it
[13:40:19 CEST] <mkver> So even if a function does not take ownership of a packet, one needs to have a spare copy of the packet (in case it's not refcounted) in order not to loose the pointer to the data because the packet may be modified?
[13:40:40 CEST] <mkver> That's a strange definition of "not taking ownership".
[13:41:00 CEST] <nevcairiel> i think you are confusing yourself and everyone else by talking in weird abstracts
[13:41:28 CEST] <mkver> Ok, I have issues with av_write_frame.
[13:43:00 CEST] <nevcairiel> "taking ownership" is usually only related to who is responsible for freeing the packet ultimately
[13:43:55 CEST] <mkver> It's documentation says that this function does not take ownership of the packet fed to it. And contrary to av_interleaved_write_frame it does not directly unref the packet fed to it. But it nevertheless modifies the packet: It modifies the timestamps; it modifies the packet's data (if there is an automatically added bsf).
[13:47:36 CEST] <mkver> If there is an automatically added bsf and the packet was refcounted and writable, the only reference to the original data will be lost.
[13:48:13 CEST] <nevcairiel> if its refcounted and no other references exist, noone else seemed to care about the data
[13:50:30 CEST] <nevcairiel> how else would you indicate to it that an in-place modification is ok? Any change to that would result in forceful data copies
[13:55:59 CEST] <mkver> The caller might care about the data. He might want to reuse the data for other purposes, thinking that he will get his data back. After all, he thinks he still owns it.
[13:57:42 CEST] <mkver> The problem with the caller receiving his data back can be solved by creating a new reference to the data like in https://github.com/mkver/FFmpeg/commit/4f7c39e344cf2aa0293354535ea09fdd9dbcbabe
[14:01:25 CEST] <nevcairiel> and that'll make in-place bsfs impossible
[14:01:46 CEST] <nevcairiel> free free to document the actual behavior, but changing it will be a hard sell
[14:04:18 CEST] <mkver> Yes, I know. But I thought that this is exactly what not transferring ownership means.
[14:04:46 CEST] <nevcairiel> ownership in reality only means that you still have to free it after
[14:05:54 CEST] <mkver> For you, it is just about the responsibility to free data; and I thought it encompassed even the possibility of getting it back (in unmodified form).
[14:08:08 CEST] <mkver> The good news is that the rest of the patchset does not depend on it; so I'll just send it with the expectation that this patch will not get applied.
[15:18:02 CEST] <Lynne> durandal_1707: your patch is the same as one of jai's patches from last month
[15:18:58 CEST] <durandal_1707> Lynne: yes, but his broke other stuff before it
[15:19:15 CEST] <durandal_1707> try it than we can talk
[15:42:20 CEST] <philipl> BtbN: https://trac.ffmpeg.org/ticket/8068 with links to patches.
[15:43:17 CEST] <philipl> vp9 allows for resolution changes on non-key frames. As nevcairiel says - crazy shit.
[15:45:30 CEST] <Lynne> durandal_1707: nope, doesn't fix issues
[15:45:40 CEST] <Lynne> it works about the same as jai's patch
[15:59:38 CEST] <durandal_1707> its certainly better than before
[16:00:59 CEST] <durandal_1707> and im doing 16bit
[16:05:03 CEST] <kurosu> vel0city: I wager your mails not having "Nick" as author/in the From: field are sent through git send-email ?
[16:05:28 CEST] <kurosu> maybe msmtp or some email sender ("MUA"?) is misconfigured
[16:05:56 CEST] <kurosu> Looking at 01/14, I see " Lossless JPEGs encoded in DNGs are commonly bayer-encoded"
[16:06:55 CEST] <kurosu> then I interpret the following as always interpreting such cases as bayer? even if you say "commonly" ?
[16:07:22 CEST] <kurosu> isn't there anything else that can make you infer this is absolutely the case ?
[16:07:52 CEST] <kurosu> note: I may have to read all of the patchset, which I very likely won't
[16:08:58 CEST] <Lynne> durandal_1707: the frame queue is used, it sets packet pts
[16:13:21 CEST] <durandal_1707> Lynne: what a waste of resouces for that casd
[16:14:03 CEST] <Lynne> well, no, that's all the afq does, it keeps track of input samples -> output samples to set pts
[16:38:27 CEST] <durandal_1707> Lynne: well my patch is correct and previous state and leaks is not
[16:45:38 CEST] <Lynne> yes, go ahead and apply it
[16:55:56 CEST] <vel0city> kurosu: That code should not be there... I must have messed up rebasing or something. I will look into it.
[17:04:23 CEST] <vel0city> not sure about the author matter, sendemail.from is my email. should it be something else?
[17:11:42 CEST] <vel0city> yeah it should be my actual name - I see. fixed
[17:22:40 CEST] <vel0city> kusosu: I remember now, it wasn't a git mess-up, I just decided to improve that code in an ensuing commit instead of rebasing it on the first one. If you look at 09/14 the assumption you mentioned is eliminated
[17:23:24 CEST] <vel0city> I can change it if it's important
[17:24:45 CEST] <vel0city> there are no known tests/files that break afaik, that's why I didn't do it in the first place
[17:32:47 CEST] <vel0city> hm no, the one I pushed still looks messed up. will push a fix in a bit
[17:43:34 CEST] <vel0city> here: https://github.com/VelocityRa/FFmpeg/commit/6a461ef5c90fcc71f5b30f3aaf2153691c8125fe not pushing to ML yet, I will do so when I fix an unrelated regression
[18:32:34 CEST] <vel0city> v12 sent. tell me if there's a better way to update revisions other than pushing all 14 commits every time. iirc I've asked and there isn't
[18:36:15 CEST] <J_Darnley> Make commits with --fixup?
[18:36:52 CEST] <J_Darnley> Then before pushing to origin do `git rebase origin/master -i --autosquash
[18:37:20 CEST] <J_Darnley> But I guess we don't want to se those on the ML anyway
[19:15:50 CEST] <vel0city> J_Darnley: I know how to do it with git, my question was about the ML. Say, if I update one of the commits, ie. "v11 02/14". Can I only send "v12 02/14" or do I have to send everything like I'm doing now? as far as I've been told, I have to re-send everything.
[20:14:04 CEST] <J_Darnley> vel0city: ah I see
[20:23:55 CEST] <roxlu> hi, someone around who has experience with the Intel Media Sdk on Linux? I'm looking into the library and wondering why they have these #ifdefs here https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/decode/h264/src/mfx_h264_dec_decode.cpp#L295 
[20:25:45 CEST] <BtbN> Because stuff is unsupported on Linux
[20:28:13 CEST] <roxlu> BtbN: thanks, yeah I thought that, but that ifdef that I linked would mean software based decoding is not supported; but strangely I'm asking for a hardware decoder
[20:28:48 CEST] <BtbN> Why are you even bothering with QSV on Linux?
[20:29:12 CEST] <roxlu> BtbN: what would you recommend otherwise?
[20:29:18 CEST] <BtbN> vaapi
[20:29:32 CEST] <BtbN> Which Linux-QSV is just a wrapper around anyway
[20:30:36 CEST] <roxlu> yeah that's what I thought, but using QSV would means that I can use the same api on Win/Linux
[20:31:53 CEST] <BtbN> QSV on Linux is just a mess
[20:32:05 CEST] <roxlu> what I don't understand yet, is why https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/decode/h264/src/mfx_h264_dec_decode.cpp#L257 return MFX_PLATFORM_SOFTWARE
[20:32:16 CEST] <roxlu> yeah ... it seems like it :) 
[20:34:40 CEST] <roxlu> BtbN: do you like the VA-API more? (is the api actually cleaner?)
[20:35:14 CEST] <BtbN> No, it's horrible. But it's one pointless wrapper less
[20:35:22 CEST] <BtbN> And it's actually well maintained and tested
[20:35:28 CEST] <roxlu> hehe yeah 
[20:36:42 CEST] <roxlu> do you know about an h264 decode example? 
[20:42:47 CEST] <BtbN> ffmpeg -hwaccel vaapi -i somefile.mp4 ...
[20:43:28 CEST] <roxlu> ok thanks
[20:50:55 CEST] <roxlu> :C http://01org.github.io/libva_master_doxygen/ 
[20:56:15 CEST] <durandal_1707> its very calm, everybody hacking something
[20:57:42 CEST] Action: roxlu trying to start with vaapi
[21:00:13 CEST] <roxlu> if anyone knows a guide / readme that shows the steps involved that we be awesome :) 
[21:37:43 CEST] <kierank> durandal_1707: it because you are not talking
[21:37:45 CEST] <kierank> everyone is cal
[21:37:46 CEST] <kierank> m
[22:07:44 CEST] <durandal_1707> calm
[22:43:10 CEST] <roxlu> ok, so the VAAPI talks about profiles and entrypoints. which vainfo also shows: https://gist.github.com/roxlu/563fed3a152e843dc52169429dbe6891
[22:43:59 CEST] <roxlu> my understanding is that the profile + entry-point (VLD, IDCT) as basically the capabilities
[22:44:16 CEST] <roxlu> but... for decoding should I use the VLD entry point? 
[22:44:46 CEST] Action: roxlu is aware that these aren't 100% ffmpeg specific questions
[00:00:00 CEST] --- Sat Aug 10 2019