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

[burek]

[00:02:07 CEST] <durandal_1707> michaelni: the retry counter breaks multiple pages tiffs?
[00:03:54 CEST] <michaelni> durandal_1707, do you have a sample it breaks ? it worked with all files i tried but i did not try all files on this planet obviously
[00:09:29 CEST] <durandal_1707> sample can be created with fcpx i think, if you follow path of page extraction, your patch breaks it
[00:13:38 CEST] <durandal_1707> https://www.nightprogrammer.org/development/multipage-tiff-example-download-test-image-file/
[00:14:13 CEST] <durandal_1707> searched, first result pop ups
[00:14:31 CEST] <durandal_1707> cant check, only tomorrow
[00:50:07 CEST] <Lynne> oh, so that qp api patch is from google, now it makes sense
[01:01:37 CEST] <Lynne> I'll assume they've just learned about adaptive quantization, all the analyzers suck, so obviously they've hacked up ffmpeg, but in google spirit of cooperation they want to upstream their hacks
[01:02:12 CEST] <kierank> there used to be (imo) quite clean support for qp extraction
[01:03:39 CEST] <Lynne> I hope they go beyond debugging and actually start using adaptive quantization in their encoders, they're decades behind x264 in many ways
[01:05:22 CEST] <kierank> Lynne: I would guess they want qp reuse for fast transcoding
[01:05:23 CEST] <kierank> or the likes
[01:08:14 CEST] <Lynne> how would that help? it shouldn't impact performance much for any decent encoder
[01:08:28 CEST] <kierank> like super fast transcoding
[01:08:44 CEST] <kierank> skip qp decision step
[01:08:55 CEST] <kierank> or maybe that have some magic things they do with the qp data
[01:10:02 CEST] <Lynne> the majority of time spent during vp9 or av1 encoding for most encoders atm is for block mode selection
[01:12:48 CEST] <Lynne> I also thought they'd abstract aq into some separate library to signal some codec generic pseudo block importance to encoders, and while it'd be the google way, doesn't sound likely
[01:13:20 CEST] <kierank> Lynne: maybe just ask the guy
[01:14:18 CEST] <jkqxz> The reponse to cropping appears to be that they just want block QPs and don't care which pixels they actually correspond to in the output.  I guess that means they're discarding the pixels, so it's purely some sort of analysis case.
[01:28:27 CEST] <juandl> jkqxz: Indeed, it is for analysis
[01:29:10 CEST] <juandl> I'm available to answer all the questions I can
[01:38:37 CEST] <jkqxz> That seems like you don't actually want to run the decoder at all, then?
[01:44:58 CEST] <juandl> The frame is decoded and the data structure proposed in the patch is stored as an array in AVFrameSideData
[01:54:43 CEST] <lotharkript> they tried to follow the same type of structure as the MV one.
[01:55:22 CEST] <lotharkript> he is trying to make it generic enough
[01:56:33 CEST] <jkqxz> But you've said you don't want to include information to work out which block in the side data actually corresponds to a given pixel in the frame.
[01:56:49 CEST] <lotharkript> i think they will need this. I can talk to them.
[01:57:14 CEST] <lotharkript> they will need the pixel
[02:04:19 CEST] <lotharkript> they are trying to replace FF_API_FRAME_QP with something similiar with AV_FRAME_DATA_MOTION_VECTORS as FF_API_FRAME_QP is being deprecated.
[02:06:19 CEST] <lotharkript> i confirm with some of them. They do need the pixel associated with the QP.
[02:08:19 CEST] <juandl> Yes, the purpose was to emulate the MV struct and make it generic enough
[02:09:59 CEST] <lotharkript> so the question is: (i think) If the decoder has some notion of cropping, but you already store the pixel for the one to be cropped, what to do with the data?
[02:13:40 CEST] <lotharkript> jkqxz: don't we have the problem already for MV? I'm not sure we are removing block from the AV_FRAME_DATA_MOTION_VECTORS after cropping
[02:20:54 CEST] <lotharkript> will it be ok, if they offset the pixel based on the crop value, so the first pixel may have a coordinate of -20, -20 for example ?
[02:36:52 CEST] <juandl> Alright, we had not considered cropping yet, but yes the origin (0, 0) used as reference for x and y in AVQuantizationParams has to match the "visible" frame, not the coded frame. So the coordinates can have negative values to represent pixels outside the frame.
[02:38:58 CEST] <Compnn> >h264 cropping
[02:39:01 CEST] <Compnn> yikes :D
[02:41:55 CEST] <tmm1> jkqxz: when you get a moment can you peek at http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247758.html. i think my patch is incomplete and seems to be affecting video quality
[02:42:41 CEST] <juandl> About the codec dependent parts of the data structure, should this implementation be moved to avcodec? I have the idea that only encoders/decoders should go in avcodec and that a patch like this belongs more to avutil, despite the codec dependency. 
[07:43:27 CEST] <durandal_1707> michaelni: are you autistic? i gave you link above to tiff file, and then you reply as you have none
[07:43:53 CEST] <durandal_1707> im deeply dissapointed
[07:46:07 CEST] <durandal_1707> nah, just ignorant, not autistic
[07:46:08 CEST] <michaelni> durandal_1707, please stop these insults, there where 2 files on the page which ffmpeg does not support and some link to software needing a windows machiene
[07:49:08 CEST] <durandal_1707> how it is not supported? what ffmpeg gives you as output?
[08:02:18 CEST] <michaelni> "[tiff @ 0x7f17b40025c0] JPEG compression is not implemented. ..." maybe it is possible to use these files somehow to test anyway but yesterday before going to sleep in the 30sec i had available i didnt find a way
[08:07:41 CEST] <michaelni> yes with modified source code these can probably be used
[09:56:28 CEST] <Compnn> durandal_1707, you need to stop with the name calling and insults
[09:56:57 CEST] <Compnn> no one here finds it funny
[09:57:05 CEST] <Compnn> it makes you look childish or unstable
[09:58:42 CEST] <durandal_1707> im not talking with former mplayer devs
[09:59:24 CEST] <Compnn> i'm a current mplayer dev.
[10:11:42 CEST] <rcombs> durandal_1707: I agree, that wasn't cool
[10:12:48 CEST] <rcombs> particularly using neuroatypicality as an insult
[10:15:27 CEST] <durandal_1707> he looks only his business
[10:25:21 CEST] <durandal_1707> but looks you all love your leader so much, that you can not see real problems at all
[10:27:39 CEST] <rcombs> this isn't anything personal, that's just a really shitty insult
[10:30:50 CEST] <durandal_1707> oh, this really become personal long ago
[10:36:29 CEST] <rcombs> I mean on my part
[10:37:21 CEST] <rcombs> I don't particularly care about your beef here, just keep unrelated minority groups out of it
[10:49:33 CEST] <kurosu> looking at the "extract QP" thingy, why are quantization implementation details exposed in a header?
[10:50:41 CEST] <kurosu> are all those {y,uv}x{ac,dc} actually varying per block or per segment (I think it is the case for VP9, not AV1)
[10:51:17 CEST] <kurosu> I mean, mpeg codecs also have chroma qp for one, and this dc/ac business is akin to quantization matrices
[10:51:43 CEST] <kurosu> that seems mostly tailored to the vp* familly
[10:53:11 CEST] <kurosu> I find this design ugly/easily broken, but then nobody is going to invest much more time to improve it
[10:56:26 CEST] <durandal_1707> exact reason why it should not be applied
[10:57:12 CEST] <kurosu> I have only read the first psot, mind you
[10:58:22 CEST] <kurosu> Inlining patches (instead of attaching it) makes it very difficult to look for the latest patch version (patchwork maybe?)
[11:01:37 CEST] <kurosu> I'm not against applying some refined versions (even if still vp*-centric), it just appears to require a lot of work to adapt it later, and not have people complain about how that broke API/ABI/their use of it
[11:35:34 CEST] <kurosu> ok, I guess I'm late to the discussion anyway, so...
[11:36:33 CEST] <nevcairiel> as long as its not commited yet, just comment on the ML
[11:37:09 CEST] <nevcairiel> better to adress it now then have something with very limited functionality in public API
[11:50:06 CEST] <jkqxz> Yeah, I'm still quite sceptical there.  The definition feels specific enough that it's likely to result in noone else ever using it.  Given that, it might as well stay in a private google tree.
[11:51:46 CEST] <jkqxz> (My comments so far have mainly been trying to work out what their definition actually is.)
[12:20:38 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:5e829262a6a6: lavf/hls: add http_seekable option for HTTP partial requests
[12:20:39 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:6f6769f3ec50: lavf/showinfo: support mastering display sidedata
[12:20:40 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:e282b7ed7bf8: lavf/showinfo: use error level when get invalid sidedata
[12:20:41 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:e512d893bfcf: examples/encode_video: only add sequence end code for mpeg1/2 video
[12:20:42 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:e317c255f651: doc/ffmpeg: Document dts_error_threshold option
[13:23:21 CEST] <J_Darnley> Is there is single AVX2 instrcution to interleave words from 2 registers across the lane boundary?
[13:23:39 CEST] <J_Darnley> punpcklwd is split on the boundary
[13:23:57 CEST] <J_Darnley> I don't think there is
[13:24:11 CEST] <J_Darnley> So I'll have to do some more shuffling, maybe
[13:24:51 CEST] <J_Darnley> oh, maybe I can abuse zero-extend...
[14:24:33 CEST] <vel0city> how do I find/generate a FATE test file? I want "tests/data/fate/tiff-fax-g3s"
[14:24:42 CEST] <vel0city> I looked at the ftp server with the test files but it's not there
[14:26:34 CEST] <nevcairiel> files in tests/data are typically generated
[14:27:19 CEST] <mkver> If I'm not mistaken, that file gets generated by the tiff-fax-g3s fate test.
[14:27:31 CEST] <mkver> So you would have to make fate-tiff-fax-g3s
[14:33:30 CEST] <vel0city> "fate-tiff-fax-g3s requires external samples and SAMPLES not specified"
[14:33:43 CEST] <vel0city> it's generated but it still wants a source file I assume?
[14:34:03 CEST] <vel0city> do I need to get the sample suite?
[14:35:53 CEST] <mkver> Yes.
[14:37:28 CEST] <vel0city> hm alright, thanks
[14:38:33 CEST] <mkver> More exactly, this test runs framecrc on $(TARGET_SAMPLES)/CCITT_fax/G31DS.TIF, so at least this sample is required.
[14:39:39 CEST] <vel0city> I cool I'll just get that then, thanks
[15:20:22 CEST] <durandal_1707> vel0city: use rsync to get that tiff file
[15:28:10 CEST] <vel0city> @durandal_1707 I got it yeah, regression is fixed now
[15:33:15 CEST] <durandal_1707> note @ is not part of my nick, its just mark for irc operators
[15:34:58 CEST] <kierank> durandal_1707: mark of leader
[15:35:14 CEST] <vel0city> durandal_1707: ah, I know it is but I still thought it's used when replying
[15:38:20 CEST] <durandal_1707> when you use @ i will not get notified at all that you sent me something
[15:38:35 CEST] <vel0city> I see
[15:43:24 CEST] <kurosu> vel0city: most irc clients (even web-based ones) have auto-completion, where by  typing the start of a nick, hitting "tab" completes it according to the channel user list
[16:03:27 CEST] <gnafu> durandal_1707: You don't have your IRC client configured to highlight you even when someone mentions your name?
[16:03:37 CEST] <vel0city> kurosu: didn't know that, thanks
[16:03:47 CEST] Action: gnafu has it so even if "gnafu" shows up in the middle of a line, it will notify him.
[16:05:24 CEST] <durandal_1707> even with "junkgnafujunk" sorry if that is not political correct
[16:05:29 CEST] <kurosu> yeah, I bet a lot of clients do that, but then you sometimes foolishly peek in your teen years a very frequent word, and get highlighted for plenty of things
[16:05:49 CEST] <gnafu> durandal_1707: Yep :-P.
[16:05:50 CEST] <kurosu> like if I would talk about the Big Buck Bunny sequence (and BBB were here)
[16:06:13 CEST] <vel0city> eh, I have it enabled for "velocity" too and I barely get any false positives
[16:06:30 CEST] <gnafu> kurosu: It was something I had to configure, if I recall correctly (it was years ago now).  It's an extra line in my Irssi config file.
[16:06:39 CEST] <vel0city> and I'm in 20 chans (most not very active though)
[16:06:53 CEST] <gnafu> But "gnafu" is uncommon enough that I am probably the thing being referred to
[16:06:56 CEST] <gnafu> .
[16:43:23 CEST] <vel0city> should I be changing a MJpegDecodeContext from tiff.c? the header/struct is already included
[16:43:51 CEST] <vel0city> there are alternatives for what I want to do but this is the less hackier one
[16:44:09 CEST] <vel0city> a MJpegDecodeContext *field
[16:45:17 CEST] <durandal_1707> michaelni: for tiff pages patch, couldnt check that offsets are strictly increasing? 
[16:46:12 CEST] <durandal_1707> if not, it would be strange and illogical
[16:55:03 CEST] <michaelni> durandal_1707, i thought so too but then i do not want to break files just because the offsets go the other direction. 
[16:59:11 CEST] <durandal_1707> need to check tiff specs
[17:12:16 CEST] <durandal_1707> just check for increasing order and otherwise ask for sample?
[17:12:41 CEST] <durandal_1707> vel0city: what you think?
[18:28:54 CEST] <lotharkript> nevcairiel: regarding the AQ patch, could you please comment on what you would like to see it done. I think they are fine to work on. But it seems there are too many opinion on what it should be doing.
[18:29:42 CEST] <nevcairiel> what patch is that?
[18:29:49 CEST] <lotharkript> The QP i meant
[18:30:17 CEST] <lotharkript> the intern is willing to work with the ffmpeg community to have the feature approve by all of you
[18:30:31 CEST] <lotharkript> he even post it a design doc.
[18:30:52 CEST] <lotharkript> he just need some guidance from the community to what it should be
[18:31:37 CEST] <lotharkript> FF_API_FRAME_QP is going to be deprecated. And they just want to offer an alternative to it
[18:31:50 CEST] <lotharkript> the same way the MV was done.
[18:32:30 CEST] <lotharkript> nevcairiel: will you be willing to have a chat with them directly? instead of exchanging email?
[18:33:25 CEST] <nevcairiel> I've not had a single involvement with that patch, I think you must be looking for someone else
[18:34:44 CEST] <lotharkript> sorry, maybe it is jkqxz ?
[18:34:58 CEST] <lotharkript> who should be the correct contact to talk about the QP patch?
[18:35:28 CEST] <durandal_1707> talk with Lynne and michaelni
[18:37:00 CEST] <lotharkript> it looks like also kurosu and jkqxz have some comment or suggestion..
[18:37:16 CEST] <lotharkript> if Lynne is ok with the design, will it be some problem with other?
[18:38:31 CEST] <durandal_1707> where is design?
[18:38:45 CEST] <michaelni> if others are ok with it, sure iam ok with it too
[19:15:09 CEST] <michaelni> durandal_1707, i can check for increasing order but iam not sure the spec requires this. the only text about order i found is "Subsequent images, such as reduced-resolution images, may be in any order in the TIFF file."
[19:16:16 CEST] <durandal_1707> yes, but ifd offset order is something else
[19:16:57 CEST] <michaelni> yes
[19:17:30 CEST] <michaelni> but did you find something in the spec that requires it to be only increasing ?
[19:17:42 CEST] <durandal_1707> the stupid spec just mentions that decoder do not need to check for loops
[19:17:52 CEST] <michaelni> yes i saw that too
[19:18:49 CEST] <michaelni> well if you prefer to check for increasing then ill do that, just saying it would be more robust to not require it
[19:19:23 CEST] <durandal_1707> just add request for sample
[19:19:39 CEST] <michaelni> yes of course
[19:19:49 CEST] <michaelni> thx
[19:20:03 CEST] <durandal_1707> so we can know application that writes such files,  so we can make jokes about it
[19:24:39 CEST] <durandal_1707> vel0city: i think accessing mjpegcontext may make sense, but us usual people tend to respond only when they see actual patch
[19:25:11 CEST] <vel0city> durandal_1707: ok
[20:03:08 CEST] <asukhanov> Design doc for Extract QP changes: https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit The design was inspired by AVMotionVector. Juan wanted to make it work for any video codec,that's why he ended up having qp_arr - the list of quanization parameters per block, since codecs like vp9 and av1 provide tools to set different QP for Y/U/V blocks and per AC/DC coefficients. 
[20:06:42 CEST] <nevcairiel> "for any video codec" and "codec specific things" seems like a contradiction
[20:07:55 CEST] <asukhanov> I would like to ask for ffmpeg community help with guidance on API. What would be the best way for him to move forward with this feature given that he has limited time left in his internship?
[20:10:01 CEST] <asukhanov> <nevcairiel>, fair point. How would you suggest to modify AVQuantizationParams to resolve this contradiction given that codecs have different number of quantization parameters and some other code needs to distinguish them in AVQuantizationParams? 
[20:11:11 CEST] <kurosu> jkqxz / lotharkript / asukhanov:  yeah, I'm sorry to be a pain to eg an intern, or anybody in fact, about this - I didn't comment publicly (except here) because I can't spend much of my time on this (I'm mostly inactive nowadays)
[20:11:55 CEST] <lotharkript> kurosu: no worry.. they just want to do the right thing,
[20:11:59 CEST] <kurosu> the issue to me is that each codec has its own way of expressing things, and the user has to know what the data means to make any use of it
[20:13:55 CEST] <kurosu> restating my opinion: I'm concerned to have in a header so many details about one specific quantization scheme
[20:14:05 CEST] <lotharkript> kurosu: any idea how we can avoid this?
[20:14:13 CEST] <asukhanov> no problems, kurosu. I think what can help Juan at this point is comments from ffmpeg community members that 1) all other members agree with, so he does not need to go back and forth with his patches 2) are expressed as simple action times for him (use data struct X instead of data struct Y, etc) 
[20:14:37 CEST] <kurosu> I'm not an API designer, but a very low level guy (like some of your guys)
[20:14:41 CEST] <kurosu> *yo
[20:14:43 CEST] <kurosu> *you
[20:15:33 CEST] <kurosu> I'd say you need to export the size of the per-unit quantization info (be it per block or anything) and have it flat, and have it versioned maybe ? (in case someone wants to add something)
[20:15:35 CEST] <asukhanov> I'm Juan's intern host, Juan is also in this chat. we are open to work on addressing your comments and value your feedback. Thank you
[20:15:42 CEST] <lotharkript> the problem is that even within one codec, the QP has different meaning. Should we then try to normlize the QP? or specify which QP schema it is?
[20:15:43 CEST] <jkqxz> I feel like the first question to ask is who the intended users are and whether it's actually sensible to include it in FFmpeg.
[20:15:44 CEST] <kurosu> but that's maybe over-engineering nobody thought about
[20:16:11 CEST] <jkqxz> What you've said so far suggests you are developing a single analysis tool, which might well be better served by using your own branch.
[20:16:31 CEST] <lotharkript> we want to replace FF_API_FRAME_QP
[20:16:38 CEST] <lotharkript> as FF_API_FRAME_QP will be deprecated
[20:16:49 CEST] <jkqxz> Locking down a specific API in FFmpeg will make development of an external tool harder, not easier.
[20:16:52 CEST] <kurosu> well, exporting QP info is a very thought-after feature - I think I have  seen the same being asked for hevc
[20:17:02 CEST] <jkqxz> And it's not clear who the others users are.
[20:17:44 CEST] <lotharkript> it was done for MV and vf_codecview.c will be one user
[20:20:14 CEST] <asukhanov> To us, extracting Quantization parameter has been the same type of feature as extracting motion vectors. My team needs this feature for our analysis tool, I'm working on rate control and I need QP for debug/analysis. Other teams I talked to also expressed interested in this feature. Having this feature implemented in a local branch is inconvenient, since our teams using different repositories and syncing these branches with 
[20:20:14 CEST] <asukhanov> upstreams becomes less trivial 
[20:20:49 CEST] <jkqxz> And who actually uses the motion vectors?  It doesn't appear to be supported for any codecs that people actually use nowadays.
[20:21:19 CEST] <asukhanov> I hope it answers you question regarding intended users
[20:25:19 CEST] <asukhanov> <kurosu>, regarding having the quantization info flat and versioned, do you mind going to Juan's design doc and leaving a proposed data structure in a form of Google doc comment so we could see what exactly you mean? This chat might be hard to use for code. We also can create a separate google doc document that everybody can modify
[20:26:12 CEST] <durandal_1707> whats wrong to make another project that exactly this just for codecs you want?
[20:29:23 CEST] <asukhanov> I just created a document which everybody can contribute to: https://docs.google.com/document/d/1IxQqvYyjsaGiC5KzYCRl0hlAwKix7I7zvaq1Pc2-3BI/edit 
[20:30:35 CEST] <lotharkript> durandal_1707: are you saying that even the MV should not have been in ffmpeg? we use to have QP, see https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors  will be nice to continue to support it..
[20:31:27 CEST] <asukhanov> durandal_1707, do you mean not using ffmpeg at all? If so, our team already uses ffmpeg/ffprobe to analys video streams (psnr/ssim computation, frame size extraction). ffmpeg has h264, vp9 and (I believe av1) decoders, so it was natural for us to consider extending ffmpeg to extract QP for us. 
[20:34:50 CEST] <durandal_1707> for av1 decoders qp and mv extraction you need to ask somebody else
[20:35:34 CEST] <durandal_1707> as you already know ffmpeg does not have native decoders for av1
[20:43:26 CEST] <Dmitri_Ovch> Hi! i reuploaded a patch with linux support for AMF/VCE (https://patchwork.ffmpeg.org/patch/14319/). Could you please review?
[20:44:02 CEST] <asukhanov> It's good to know that, it was suggested to work on H264/VP9 and leave AV1 out for now.
[20:47:13 CEST] <durandal_1707> well, at least one FFmpeg dev wants full solution that does not need lot of drastic changes
[20:51:49 CEST] <durandal_1707> after each update, dunno if his willimg to write structures
[21:12:50 CEST] <kurosu> asukhanov: sorry 9pm here, and I actually can't spend enough time on ffmpeg in the foreseeable future
[21:13:32 CEST] <kurosu> I just happened to restart a conversation earlier today
[21:18:54 CEST] <tmm1> trac is missing 4.2 in the version dropdown
[21:24:58 CEST] <jkqxz> tmm1:  Wrt A/53 in VAAPI, I think I'd prefer having the structures in CBS.
[21:25:05 CEST] <jkqxz> I haven't looked at that patch in a long time, though.
[21:25:51 CEST] <jkqxz> Wrt that bug you just raised, it's the general auto-insert-swscale case.  See the suggested "autoscale" option discussion on the ML recently.
[21:29:14 CEST] <tmm1> ah, thanks for that pointer. i'll try this autoscale patch
[21:29:54 CEST] <tmm1> the a/53 vaapi patch is quite small, and re-uses the same H264RawSEIUserDataRegistered struct that the cbs uses as well
[21:31:54 CEST] <tmm1> i can try reviving that a/53 cbs misc patchset, i do think that's worth merging
[21:32:32 CEST] <tmm1> jkqxz: can you help me understand what needs to happen for force_key_frames in vaapi. can i simply bring back the logic that used to be in vaapi_encode_truncate_gop()
[21:38:09 CEST] <jkqxz> I'm looking at that now.
[21:41:23 CEST] <jkqxz> Losing that is a rather stupid error on my part.  I actually remember testing its interaction with all the tricky H.264 reference picture stuff, so I'm not sure how I then managed to lose it completely.
[21:50:59 CEST] <durandal_1707> which encoder should be done next?
[21:52:56 CEST] <jkqxz> tmm1:  What is going wrong with your patch for you?  It looks right to me, and I don't see any problems from a small amount of testing.
[21:53:00 CEST] <michaelni> tmm1, added 4.2, should be there now
[21:54:56 CEST] <durandal_1707> michaelni: update topic in #ffmpeg ?
[21:55:36 CEST] <tmm1> jkqxz: the video quality got significantly worse
[21:55:36 CEST] <michaelni> durandal_1707, done, thanks
[21:56:25 CEST] <taliho>  /join #ffmpeg
[21:56:41 CEST] <tmm1> i thought maybe input_order had to be reset too, or maybe references had to be updated like the old truncate_gop method used to do
[21:56:58 CEST] <jkqxz> tmm1:  With RC enabled on some particular driver and platform?
[21:58:30 CEST] <jkqxz> The old truncate_gop method existed because the code tried to decide in advance what the structure was going to be then find frames to fill it, so it had to mess around with references if the structure changed.
[21:59:10 CEST] <jkqxz> The current code only decides what a frame is going to be when it actually has it, so it never needs to modify the references after the fact.
[22:02:45 CEST] <tmm1> hmm okay that makes sense. i'm using vbr and comparing quality on 4.0 vs 4.2+patch, so let me bisect a bit more and see if its a unrelated regression
[22:07:19 CEST] <jamrial> durandal_1707: improve or fix dts/truehd encoders
[22:08:28 CEST] <kierank> durandal_1707: third prores encoder
[22:08:41 CEST] <durandal_1707> buhaha
[22:11:28 CEST] <durandal_1707> i will try to look again to truehd/mlp as it is lossless and easier to deal with
[22:29:11 CEST] <Lynne> durandal_1707: start from the 5-part mlp patchset from last month, they fix things somewhat
[22:29:45 CEST] <Lynne> use 24 bit encoding too, then crackling happens more often
[22:31:01 CEST] <durandal_1707> is 16bit mlp encoder working fine?
[22:33:24 CEST] <Lynne> nope, crackles (checksum fails), but less often
[22:35:54 CEST] <Lynne> feed it actual content, so music and such, sine waves and white noise are encoded fine
[22:59:01 CEST] <tmm1> jkqxz: it looks like i'm only getting a 300kbps stream even though I configured VBR at 3mbps https://paste.ubuntu.com/p/9tkZQKWQV5/
[23:00:25 CEST] <tmm1> same behavior in ffmpeg 4.1, but ffmpeg 4.0 works
[23:08:10 CEST] <jkqxz> What about with iHD?
[23:08:17 CEST] <jkqxz> There are weird RC problems in the Intel drivers.
[23:12:00 CEST] <tmm1> cbr works as expected, only vbr seems broken
[23:15:27 CEST] <tmm1> i'll try switching from i965 to iHD and see what happens
[23:15:39 CEST] <tmm1> i did try using the latest i965 with ffmpeg 4.0 and that combination still works
[23:17:44 CEST] <jkqxz> The older version makes different choices about how it sets up the VBR parameters.
[23:19:40 CEST] <tmm1> i don't really understand the difference between i965 and iHD
[23:19:55 CEST] <durandal_1707> Lynne: spotted already huge memory leak
[23:21:30 CEST] <Lynne> where? it does a per-frame alloc but frees them unconditionally
[23:27:10 CEST] <durandal_1707> Lynne: apply_filter
[23:27:33 CEST] <durandal_1707> when it returns -1
[23:27:58 CEST] <durandal_1707> also encoder work internally with 24bit data
[23:28:24 CEST] <durandal_1707> thus making check in this function invalid
[23:28:58 CEST] <durandal_1707> this was student first and wrong committ
[23:30:02 CEST] <durandal_1707> you cant teach student complicated things with student zero previous experience
[23:31:01 CEST] <Lynne> most of the work wasn't done by a student though
[23:32:00 CEST] <durandal_1707> yes, but still understanding is required
[23:38:14 CEST] <durandal_1707> i dunno how much leaks are trigerred
[23:46:57 CEST] <tmm1> jkqxz: so if i match the rc_params i should be able to replicate the old behavior?
[23:47:08 CEST] <tmm1> trying to compare the values being sent to va now.. https://paste.ubuntu.com/p/M3cwVk4J8v/
[00:00:00 CEST] --- Fri Aug  9 2019