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

[burek]

[02:10:20 CEST] <cone-411> ffmpeg 03Avi Halachmi (:avih) 07release/4.0:42355d12dbfd: configure: speed up flatten_extralibs_wrapper()
[02:10:20 CEST] <cone-411> ffmpeg 03Avi Halachmi (:avih) 07release/4.0:df6e929e8934: configure: speed up print_enabled_components()
[02:10:20 CEST] <cone-411> ffmpeg 03Avi Halachmi (:avih) 07release/4.0:a634da282b7c: configure: speed up check_deps()
[02:10:20 CEST] <cone-411> ffmpeg 03Avi Halachmi (:avih) 07release/4.0:3fb09dba40b0: configure: <fflib>_deps: validate, reduce sensitivity
[12:21:26 CEST] <j-b> durandal_1707: koda: https://wiki.videolan.org/Bounties/
[12:25:48 CEST] <durandal_1707> j-b: it is AGM2 not AG2M and there are variants from AGM0 to AGM8
[12:26:20 CEST] <j-b> ok
[12:29:36 CEST] <j-b> durandal_1707: anything else?
[12:29:51 CEST] <atomnuker> there's no sum listed for either AACE or xHE-AAC
[12:30:36 CEST] <j-b> atomnuker: that's a good point. Because I have NO clue.
[12:30:56 CEST] <j-b> let me ask around
[12:30:58 CEST] <kierank> I guess there's opus fec in ffmpeg
[12:31:00 CEST] <kierank> that's a bounty
[12:31:11 CEST] <durandal_1707> j-b: i will do AGM2 and AGM3 (AGM3 for free, because you are very very evil)
[12:31:32 CEST] <j-b> I am evil, sure. But Why?
[12:32:05 CEST] <durandal_1707> why you are evil? how do i know?
[12:32:40 CEST] <j-b> You told me I was
[12:32:45 CEST] <j-b> there must be a good reason
[12:34:39 CEST] <atomnuker> afaik xhe-aac's getting used in india now, got no idea about aace (!= aac-eld)
[12:36:04 CEST] <atomnuker> I only know about that from a youtube video with 50 views of some guy using gnuradio to feed the demodulated data into a torn apart radio
[12:37:00 CEST] <kierank> atomnuker: ah for DRM radio
[12:37:48 CEST] <kierank> I might be able to receive that with a coathanger and sdr
[12:38:30 CEST] <atomnuker> https://www.youtube.com/watch?v=CPu0ZODJ2tA
[12:39:11 CEST] <kierank> lol
[14:09:10 CEST] <January> michaelni: https://0x0.st/s3YD.nal as fate/h264/crew_cif.nal please. I've updated the test to work on 32bit now as well (was a pain to get multilib working but I probably could have just looked at the code and found the bug...)
[14:09:44 CEST] <JEEB> I think the extension .264 or so could be better for those?
[14:09:55 CEST] <JEEB> (since I think lavf picks that up)
[14:10:37 CEST] <January> JEEB: it's not quite .264, it's got NALU sizes before each NALU
[14:12:48 CEST] <JEEB> oh
[14:12:51 CEST] <JEEB> so it's not Annex B
[14:13:10 CEST] <JEEB> do we even support that? oh, I guess it's for the API test :)
[14:14:17 CEST] <nevcairiel> as a raw file thats not supported
[14:14:24 CEST] <nevcairiel> its really quite invalid
[14:24:40 CEST] <michaelni> January, i think ive already uploaded this one
[14:25:03 CEST] <January> oh right thanks
[15:19:30 CEST] <JEEB> another fun case of ffmpeg.c's timestamp fixing breaking apart :)
[16:14:01 CEST] <cone-296> ffmpeg 03Derek Buitenhuis 07master:b1504e7796a4: h264_slice: Copy the value of x264_build before calling h264_slice_header_init during thread init
[16:16:31 CEST] <atomnuker> jamrial: btw there's a todo in matroskadec.c on line 2424 about av1, is that still valid?
[16:18:12 CEST] <jamrial> yes. i was waiting for the decoder to land before doing that, since changing what we export as extradata would affect how it's parsed
[16:19:03 CEST] <jamrial> but i guess we could do it in time for ffmpeg 4.1
[16:19:07 CEST] <jamrial> only cbs av1 needs to be adapted
[16:20:01 CEST] <atomnuker> we got that merged already though
[16:22:10 CEST] <jamrial> it's a simple change
[16:28:22 CEST] <philipl> BtbN, nevcairiel: So do we actually have an issue with the new pix fmts?
[16:29:06 CEST] <philipl> Should we remove P010 for Carl?...
[16:31:17 CEST] <nevcairiel> P010 is at least a rather common format, and we don't have P012 and still somehow manage to deal with 12-bit video. In an ideal world you could just use a few formats that describe the data layout and additional metadata that describes the finer details
[16:31:20 CEST] <kierank> the naming is super confusing the on the pixel formats
[16:41:21 CEST] <philipl> kierank: I have no attachment to the names (but note I did get them the wrong way round in the patch and I've switched it locally). I'll take any suggestions.
[16:41:56 CEST] <philipl> I'm also happy to just use 444P16 and call it a day. I just don't want a situation where it ends up being 'solve this big problem before you can make your small change'
[16:47:30 CEST] <atomnuker> 444p16 isn't even an option
[16:47:42 CEST] <atomnuker> for when you have p010 but with lsb padding
[16:48:32 CEST] <nevcairiel> p010 always has lsb padding
[16:48:41 CEST] <nevcairiel> this is about a new 444 format
[16:49:52 CEST] <atomnuker> eh? well damn, I was right after all, that's why I must have left it in hwcontext_vulkan
[17:08:21 CEST] <philipl> nevcairiel: So where does this leave us? Yes, in an ideal world, we'd do things differently, but that's a task as big as yuvj which is still ongoing. So the only short term options are fudge it and just use YUV444P16 with no bit depth information or add the new pix fmts. Before Carl showed up it seemed we all agreed that pix fmts were acceptable, even if not great. Is that still the position?
[17:11:40 CEST] <atomnuker> I'd rather have the new pixfmts, bits per sample isn't acceptable as there's no such field in avframes and it doesn't describe where the padding would be anyway
[17:14:19 CEST] <nevcairiel> you could define that anyway
[17:14:24 CEST] <nevcairiel> just like with audio
[17:14:31 CEST] <nevcairiel> we shove 20 and 24 bit in S32 and have bitdepth to go with that
[17:14:47 CEST] <nevcairiel> padding is a lways LSB, which means you can interpret that as 32-bit audio if you wanted to, and it would sound fine
[17:14:53 CEST] <nevcairiel> knowing the actual bitdepth is only a small advantage
[17:15:15 CEST] <nevcairiel> its not like this is a new concept, we already have that, just not for video
[17:15:33 CEST] <atomnuker> yeah, I guess
[17:28:30 CEST] <BtbN> Wasn't YUVJ even un-deprecated? Because nobody could reasonably fix the alternative in due time?
[17:29:47 CEST] <BtbN> There is such a big wave of changes neccesary to not get the bit depth from the pix_fmts, I really see the pix_fmts as the only option right now. The alternative is a massive patchset by itself that would take months to polish
[17:29:53 CEST] <atomnuker> nope, its still deprecated
[18:37:29 CEST] <durandal_1707> all thanks to your tremendous help!
[18:40:58 CEST] <atomnuker> we've been trying to get you to resubmit your patches, the current ones from february had a bug afaik which you solved
[18:41:05 CEST] <atomnuker> but you didn't resubmit them
[18:46:49 CEST] <durandal_1707> why anybody listen to Carl? he is  irrelevant
[18:49:32 CEST] <kierank> durandal_1707: he is leader
[18:50:07 CEST] <durandal_1707> no, he is f* word
[18:52:33 CEST] <j-b> atomnuker: any other idea for Bounties?
[18:53:58 CEST] <durandal_1707> add lottery... channces are bigger to get more cash
[18:54:13 CEST] <j-b> if you need more cash, ask Youtube.
[19:07:47 CEST] <atomnuker> can't think of anything, I'm no expert on obscure one-off audio codecs which became popular enough for a bounty
[19:08:51 CEST] <durandal_1707> j-b: so no VLC lottery? :(
[19:09:01 CEST] <j-b> atomnuker: 
[19:09:05 CEST] <j-b> atomnuker: thx
[19:09:12 CEST] <j-b> durandal_1707: I wish I had more money
[19:09:37 CEST] <kierank> durandal_1707: ask j-b for saturn v rocket
[19:09:45 CEST] <durandal_1707> lol
[19:09:51 CEST] <j-b> that, I can provide.
[19:10:06 CEST] <durandal_1707> one, filled with air?
[19:12:59 CEST] <atomnuker> no, helium, that's what it used to pressurize tanks
[19:24:12 CEST] <philipl> So who's going to tell Carl that we're happy adding new pix fmts?
[19:25:59 CEST] <durandal_1707> j-b: do you have any other agm2 sample, beside one i uploaded?
[20:23:02 CEST] <durandal_1707> if i do vertical flip of block before dct, how should zigzag pattern look like? so I do not need to do extra vertical flip again with idct?
[20:52:43 CEST] <durandal_1707> nobody is (I)DCT expert here?
[20:54:48 CEST] <atomnuker> not sure, this isn't as trivial as transposing is
[20:55:25 CEST] <atomnuker> what are you trying to do which requires you to undo a flip in the spatial domain?
[20:56:54 CEST] <durandal_1707> atomnuker: codec is encoded videos vertically flipped
[20:57:52 CEST] <jkqxz> You want something like negating all coefficients in even rows, I think?  (With standard even-size DCT and nothing funny going on.)
[20:58:33 CEST] <durandal_1707> dct 8x8 blocks
[20:58:38 CEST] <atomnuker> pretty sure that would affect horizontal coeffs as well
[21:01:45 CEST] <jkqxz> Yeah.  That gets the vertical right, but messes with the horizontal.
[21:02:09 CEST] <atomnuker> apparently its just a matrix multiply by diag(1, -1, 1, -1, 1, -1, 1, -1)
[21:02:12 CEST] <atomnuker> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.603.7187&rep=rep1&type=pdf
[21:04:10 CEST] <atomnuker> so for a vertical flip you do K*X and for a horizontal you do X*K, where K is that diag matrix
[21:18:59 CEST] <durandal_1707> atomnuker: you are genius
[21:19:21 CEST] <durandal_1707> jkqxz: it is odd rows
[21:20:45 CEST] <JEEB> :)
[21:43:36 CEST] <atomnuker> durandal_1707: if they're encoding stuff flipped you also need to swap the blocks vertically, right?
[21:46:51 CEST] <durandal_1707> atomnuker: yes
[21:48:55 CEST] <atomnuker> I guess they wanted to make encoding fast so rather than doing it there they signal it for the decoder to do
[21:54:50 CEST] <cone-878> ffmpeg 03Marton Balint 07master:4db291d76422: avfilter/f_cue: always check the return value of ff_inlink_consume_frame
[21:54:50 CEST] <cone-878> ffmpeg 03Marton Balint 07master:6e6ecdf44d62: ffmpeg: check return value of avcodec_parameters_from_context
[21:54:50 CEST] <cone-878> ffmpeg 03Marton Balint 07master:d6a1f711bcd1: avfilter/af_asetnsamples: do not leak frame on ENOMEM
[22:50:40 CEST] <cone-878> ffmpeg 03Carl Eugen Hoyos 07master:f85fa100db7d: lavf/ftp: Remove an unneeded forward declaration.
[00:00:00 CEST] --- Wed Oct 10 2018