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

[burek]

[00:08:56 CET] <taliho> :jamrial do the docs need an update for the export_side_data flag? 
[00:10:56 CET] <jamrial> taliho: yeah
[00:12:45 CET] <taliho> do you have any thoughts about the patch for exporting hevc motion vectors? 
[00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:be54da2117a6: avcodec/snappy: Sanity check bytestream2_get_levarint()
[00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:985d3666f672: avcodec/pcm: Fix invalid shift in pcm_decode_frame for LXF
[00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:6847e22c8c85: avcodec/wmavoice: sanity check block_align
[00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:38d375844487: avcodec/wmavoice: Fix rounding and integer anomalies in calc_input_response()
[00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:94ac2c757663: avcodec/8svx: Use av_assert1(0) instead of error message in unreachable code
[00:13:03 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:bfea054a75f1: avcodec/dca_lbr: Fix some error codes and error passing
[00:13:03 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:fd313d8cf836: avcodec/ralf: Fix integer overflow in apply_lpc()
[00:19:36 CET] <taliho> jamrial: do you think parts of hevc export motion vector patch belong in mpegutils.c? 
[00:22:33 CET] <jamrial> i can't say. i only replaced the flag, no idea if that's the correct place for the existing code
[00:23:16 CET] <jamrial> but mpegutils doesn't sound like the place for hevc related code
[00:26:28 CET] <taliho> ok, just feel sorry for the guy. he's pinged a few times
[01:36:52 CET] <BBB> taliho: in all honesty, I think hevc suffers from an utter lack of interest ("nobody cares")
[01:36:58 CET] <BBB> taliho: and this is a typical example of this
[01:37:30 CET] <BBB> it's funny, because hevc is supposed to be all the hype, but hype does not grow in a vacuum. nobody cares about yet another lossless screen codec, and nobody cares about hevc
[01:37:41 CET] <BBB> ¯\_(Ä)_/¯
[01:38:15 CET] <BBB> taliho: the best way for that patch to go in is for someone to take over long-term maintainership of hevc functionality in ffmpeg, and by that I really mean "work on it as a main project"
[01:38:23 CET] <BBB> (and for the long term)
[01:38:26 CET] <BBB> interested? :)
[02:09:06 CET] <kierank> tragedy of the commons
[08:22:52 CET] <cone-605> ffmpeg 03Tomas Härdin 07master:1c15111148b5: MAINTAINERS: Add myself as mxf* maintainer
[09:43:51 CET] <cone-605> ffmpeg 03Paul B Mahol 07master:6d5e9ed67cf0: avfilter/vf_xfade: move passthrough code before eof check
[09:43:52 CET] <cone-605> ffmpeg 03Paul B Mahol 07master:c4e29d0ba316: avfilter/vf_xfade_opencl: move passthrough code before eof check
[09:54:26 CET] <durandal_1707> darkapex: not all integer overflows have been fixed by your patch
[09:55:35 CET] <darkapex> durandal_1707: ok you can ignore that patch for now ill do more testing with undefined santize as well
[09:55:56 CET] <darkapex> do rest of the changes look ok?
[09:56:28 CET] <durandal_1707> darkapex: i'm talking only about integer one
[09:56:49 CET] <darkapex> ok ill try to send an update tonight
[10:02:48 CET] <durandal_1707> darkapex: ctx->dts = -avctx->frame_size; ----> why is that initialized this way? it seems pointless
[10:06:26 CET] <darkapex> durandal_1707: i am unsure about most of the code tbh. i did not touch what seemed to work when i was merging ramiro's original code. i can take a look if you think this might be causing the issues with the last few blocks not getting encoded.
[10:08:13 CET] <durandal_1707> darkapex: it have nothing to do with that
[10:08:41 CET] <durandal_1707> darkapex: look at your old changes, perhas you introduced this invalid items at first time
[10:09:27 CET] <darkapex> this was there in ramiro's original tree as well https://github.com/ramiropolla/mlpenc/blob/master/mlp/mlpenc.c#L570
[13:21:45 CET] <durandal_1707> Lynne: ok to push mlp stuff? its all experimental anyway, also apply mlp decoder patch?
[13:38:38 CET] <durandal_1707> darkapex: what about 20/24 mode?
[13:39:49 CET] <darkapex> durandal_1707: haven't tested that properly yet. i would guess it would still fail lossless checks as there is assumption in code at many places.
[13:40:05 CET] <darkapex> lets keep it disabled for now i would say
[13:41:31 CET] <darkapex> ill test it once i solve the unencoded last few samples issue
[13:41:48 CET] <durandal_1707> ok
[16:53:07 CET] <Lynne> durandal_1707: yeah, go ahead
[16:53:31 CET] <Lynne> you know more about the encoder than I do now anyway
[16:55:59 CET] <durandal_1707> i doubt that
[18:05:17 CET] <darkapex> durandal_1707: you are correct the dts code is completely useless. ctx->timestamp already holds the correct timestamp
[18:06:02 CET] <darkapex> ill check with the surcode decoder when i boot into windows, it should be able to play it though
[18:08:09 CET] <durandal_1707> darkapex: i just tell about negative for unsigned value
[18:08:33 CET] <darkapex> yeah i know but it is useless on top of that 
[18:10:44 CET] <Lynne> the whole thing is weird, it looks like its doing container-level work
[18:11:07 CET] <Lynne> and it calls access units frames
[18:11:31 CET] <Lynne> moreover, afq does all the work to set the pts/dts for you
[18:16:13 CET] <darkapex> yeah if i get time i will look at other encoders like flacenc and try to use newer util functions in mlpenc as well
[18:16:38 CET] <darkapex> the code is an absolute mess rn
[18:22:22 CET] <darkapex> ok i see ctx->dts is stored in the access unit header which is decoding time stamp. and ctx->timestamp is stored in restart header which is presentation timestamp
[18:22:30 CET] <darkapex> both are ignored by mlpdec.c
[18:22:48 CET] <darkapex> now question is if some weird dvd-a player or surcode ignore it as well
[18:23:17 CET] <durandal_1707> i'm just talking about invalid initialization
[18:23:20 CET] <darkapex> anyway ill just change dts to int64_t and cast it wherever
[18:23:22 CET] <darkapex> yeah
[18:23:34 CET] <darkapex> will do that i dont want things to explode in future due to this
[18:23:36 CET] <durandal_1707> look how dts looks from surcode encoder?
[18:23:52 CET] <darkapex> ok yeah that is an excellent idea will try
[18:24:02 CET] <durandal_1707> no point in casting, just initialize it to 0
[18:24:20 CET] <darkapex> then first access unit header will have wrong dts no?
[18:24:35 CET] <durandal_1707> how so?
[18:24:54 CET] <Lynne> darkapex: it rerolls back to 0 after 1<<16 frames, and the value in the bitstream is 16bit
[18:24:55 CET] <darkapex> right now the first dts going in the bitstream is unsigned cast of the initial value of dts..
[18:26:25 CET] <darkapex> Lynne: yeah right. does that mean that it does not matter if we start from 0 or -frame_size and any decoder should be able to take the first dts from bitstream as starting point?
[18:27:04 CET] <durandal_1707> look what surcode does
[18:27:14 CET] <darkapex> alright time too boot into window$
[18:46:59 CET] <durandal_1707> darkapex: i have encoded file, just dunno how to modify mlpdec
[18:48:03 CET] <darkapex> durandal_1707: i checked, surcode dts starts from 0 when logged in mlpdec and so does original mlpenc's. if i set dts = 0 it starts at 40 in the mlpdec logs which is weird
[18:48:14 CET] <darkapex> wait ill share the logging patch for mlpdec
[18:49:16 CET] <darkapex> https://pastebin.com/9xPpUfJJ
[18:54:46 CET] <durandal_1707> darkapex: hmm, than current code is fine, just need cast
[18:57:19 CET] <darkapex> durandal_1707: yeah i'll do that for now. 
[18:57:49 CET] <darkapex> also i think the last access unit is probably not written due to https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mlpenc.c#L2256
[18:58:10 CET] <darkapex> this might also solve the weird dts initialization as dts is written in access unit
[18:58:54 CET] <darkapex> note how it skips writing access unit a few lines below if data is not found. i am suspecting this is causing the last block to not get written but ill need to check more
[21:39:53 CET] <cone-711> ffmpeg 03Wonkap Jang 07master:b93098253ece: avcodec/libvpxenc: add VP9 temporal scalability encoding option
[21:59:39 CET] <cone-711> ffmpeg 03Marton Balint 07master:3cdc71348e03: avformat/dashenc: use AV_OPT_TYPE_DICT for http_opts
[22:04:32 CET] <durandal_1707> darkapex: https://0x0.st/izlr.patch
[22:05:44 CET] <durandal_1707> it fails to encode end frames in some cases, there are out memory access
[22:06:05 CET] <durandal_1707> use valgrind with -fsanitize=address
[22:06:21 CET] <durandal_1707> i mean and/or
[22:06:27 CET] <durandal_1707> not with
[23:22:52 CET] <BtbN> I uploaded a video with the testsrc test pattern to YouTube. And it got immediately copyright flagged and blocked worldwide
[23:22:54 CET] <BtbN> the hell
[23:23:12 CET] <BtbN> nothing else in there. Just 10 minutes of testsrc, no audio.
[23:23:25 CET] <cehoyos> michaelni: If you have time, please look at ticket 8508, a mov stsc regression
[23:24:29 CET] <jdarnley> BtbN: youtube all over
[23:24:58 CET] <BtbN> It doesn't even let me myself watch it...
[23:25:08 CET] <jdarnley> someone fed test footage into the copyright bot to claim it from others
[23:25:09 CET] <BtbN> and here I am wanting to test weird stutter issues
[23:25:18 CET] <jdarnley> happens with static too IIRC
[23:25:24 CET] <BtbN> Well, it's not even claimed. It's straight up shot down entirely.
[23:25:52 CET] <cone-711> ffmpeg 03Michael Kuron 07master:beab188c615d: doc: Fix typo for dvdsubdec
[23:59:50 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:eb64a5c6f949: avcodec/apedec: Fix integer overflows in predictor_decode_mono_3950()
[23:59:51 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:861183f2e655: avcodec/pngdec: Check amount decoded
[23:59:52 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:fb3855342b9e: avcodec/lagarith: Sanity check scale
[00:00:00 CET] --- Tue Feb  4 2020