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

[burek]

[00:31:49 CEST] <mkver> jamrial, jkqxz: In mpeg2 both picture and slice header can contain additional information via extra_information_picture/extra_information/slice. cbs-mpeg2 currently only supports the latter of the two. If I were to add support for the former, should I rather use a macro or a function to avoid code duplication (or wouldn't you mind the duplication)?
[00:37:16 CEST] <jkqxz> Picking the extra_information block from slice_header into a separate function looks like it would work?
[00:39:39 CEST] <mkver> I would have to use string arguments and I'd add a separate structure for the extra_information related fields (in order not to deal with offsets directly), but I think it would work.
[00:46:11 CEST] <jkqxz> The string arguments to distinguish extra_information_picture from extra_information_slice?
[00:48:02 CEST] <mkver> Yes. And also for extra_bit_slice and extra_bit_picture.
[00:49:19 CEST] <jkqxz> See also <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cbs_h265_syntax_template.c;h=f279d283d9b221c0d99e0c063c2a211f194eff31;hb=HEAD#l61>.
[00:54:19 CEST] <mkver> So you say I should not care about these names being 100% identical to the spec?
[00:56:36 CEST] <jkqxz> It's nice if they are for anything anyone might ever want to search for in traces, but for something so rarely used it seems hard to argue for if it's annoying in the code.
[00:57:44 CEST] <mkver> Ok.
[00:57:45 CEST] <jkqxz> Hmm, I guess the string arguments are actually fine.  That H.265 function should probably be fixed to do that too.
[00:58:22 CEST] <mkver> Then I'll use them.
[00:59:11 CEST] <mkver> PS: frame_center_horizontal/vertical_offset are signed int16. I already made a patch.
[00:59:16 CEST] <jkqxz> Sounds like I don't mind at all between these.  Do whatever you prefer!
[01:00:15 CEST] <mkver> One of the cbs-mpeg2-fate tests actually contains a negative value.
[01:05:56 CEST] <jkqxz> Good catch.
[01:06:52 CEST] <jkqxz> Just seeing that in the sony-ct3 sample, I see the array subscripts for trace could be filled in in that function too.
[01:07:51 CEST] <mkver> That's also done in my patch.
[01:08:53 CEST] <jkqxz> :)
[01:12:52 CEST] <mkver> I see you have just sent the the patches to fix h264_redundant_pps.
[01:15:40 CEST] <mkver> Good. Just one thing: I changed my email from @googlemail.com to @gmail.com. These two are both google-email-addresses, but (to my surprise) they use different DMARC policies that mean that googlemail patches are no good.
[01:15:46 CEST] <cone-137> ffmpeg 03Fu Linjie 07master:154a730bdcae: lavc/vp9_superframe_bsf: avoid error messages in one line
[01:16:52 CEST] <mkver> The author of one of my earlier patches (18a851aca766ff8c7199c9e0c37d8fa642e41920) has been changed to "Andreas Rheinhardt via ffmpeg-devel" because of that.
[01:17:14 CEST] <mkver> Will you please make sure that this won't happen this time?
[01:17:32 CEST] <jkqxz> Sure.  Shall I change that existing one to your new address?
[01:17:50 CEST] <jkqxz> I mean, the one in the series I just sent.
[01:20:56 CEST] <mkver> Yes, that would be the best solution.
[01:23:37 CEST] <jkqxz> Ok, amended locally.
[01:30:26 CEST] <mkver> Is it really certain that a compiler mustn't add padding between elements the pointer to the bufer and the pointer to the AVBufferRef?
[01:31:39 CEST] <mkver> I thought that the only thing guaranteed is that non-bitfield members don't overlap and that elements defined earlier have a lower offset.
[01:35:24 CEST] <jkqxz> It's not strictly conforming to the C standard, but as far as I know all supported ABIs act sensibly.
[01:36:54 CEST] <jkqxz> I think it's a similar concession to pragmatism as av_freep(), though if you know of any cases which could actually go wrong them please do say.
[01:37:51 CEST] <mkver> Ok. FFmpeg uses some implicit assumptions that are fulfilled for some exotic systems anyway.
[01:38:58 CEST] <mkver> The C standard doesn't require that you get a valid NULL pointer if you overwrite (memset) a pointer to 0.
[01:39:15 CEST] <mkver> FFmpeg uses this all the time.
[01:45:19 CEST] <mkver> Should the buffer be padded?
[01:47:21 CEST] <jkqxz> I don't think so - the fixed-size cases defined in the tables always contain specific structures.
[01:48:14 CEST] <jkqxz> Dynamic ones like slice_data already have the padding and we copy the size.
[01:52:10 CEST] <mkver> I meant: Should the extra_information buffers be padded?
[01:52:24 CEST] <mkver> Your last comment can be read as "yes".
[01:56:00 CEST] <jkqxz> Yes.  The equivalent cases in other codecs (like SEI in H.26[45]) are.
[03:14:34 CEST] <mkver> jkqxz: I just remembered that a user has actually reported that h264_redundant_pps isn't working any more (ticket #7807). Can you add a "Fixes #7807" to my patch's commit message?
[03:37:11 CEST] <mkver> jkqxz: It is done. I'll probably send it to the ML tomorrow (after a few more tests), but you can already take a look: https://github.com/mkver/FFmpeg/commits/mpeg2-cbs
[03:37:54 CEST] <mkver> The last patch (regarding trailing zeroes) is currently not mergeable btw., as it currently breaks fate.
[03:39:43 CEST] <mkver> Good night.
[06:54:30 CEST] <cone-638> ffmpeg 03Xuewei Meng 07master:e45e6005ce6a: libavfilter/dnn_native: Add multiple padding methods in dnn native
[21:00:37 CEST] <Lynne> I hate the 8-point fft more than the 15-point or the 5-point one
[21:01:40 CEST] <Lynne> its just 6.5 avx adds and 1 mult, but the awkward shuffles bloat it so much
[00:00:00 CEST] --- Wed May 22 2019