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

[burek]

[02:00:51 CET] <cone-191> ffmpeg 03James Almer 07master:13f2b6dc720b: fate/cbs: update the two film grain cbs_av1 tests
[02:24:18 CET] <cone-191> ffmpeg 03Andriy Gelman 07release/4.2:0493699813cc: lavc/cbs_h2645: Fix incorrect max size of nalu unit
[02:24:18 CET] <cone-191> ffmpeg 03Fei Wang 07release/4.2:69abae318a7e: avcodec/cbs_av1: avoid reading trailing bits when obu type is OBU_TILE_LIST
[02:24:19 CET] <cone-191> ffmpeg 03James Almer 07release/4.2:d3fef1a3bd9f: avcodec/cbs_av1: fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
[02:35:53 CET] <mkver> James, I think you have forgotten to backport my recent Matroska demuxer patch.
[09:49:21 CET] <JEEB> was there a simple way to dump certain type of side data packets out?
[09:49:36 CET] <JEEB> trying to get an overview of how a US closed caption packet looks
[09:50:13 CET] <JEEB> the thing you stick into side data and then it gets put into a NAL unit or so
[09:59:24 CET] <kierank> JEEB: vf showinfo
[10:01:18 CET] <linjie> Hi, "If you need a sample uploaded send a mail to samples-request."
[10:02:47 CET] <linjie> someone may have asked, what's the address of "samples-request"
[10:05:00 CET] <linjie> sample-request at ffmpeg.org?
[10:26:04 CET] <JEEB> kierank: that just outputs how big it is... I guess I'll just write a simple C app that dumps it
[10:26:15 CET] <JEEB> > side data - A/53 closed captions (60 bytes)
[10:26:41 CET] <kierank> ah
[10:27:12 CET] <JEEB> just trying to get a feeling of how a basic text packet would look in it
[10:31:07 CET] <kierank> I think that's a whole can of worms
[10:31:34 CET] <nevcairiel> you can look at the spec, even wikipedia has a simple rundown of the packet layout
[10:31:37 CET] <nevcairiel> its not very "text"
[10:34:57 CET] <cone-001> ffmpeg 03Martin Storsjö 07master:b85dcd8586e2: fate: Fix dependencies to sample files to use local paths
[10:34:57 CET] <cone-001> ffmpeg 03Martin Storsjö 07master:e9bb1410e475: fate: Fix use of target_path/target_samples
[10:34:57 CET] <cone-001> ffmpeg 03Martin Storsjö 07master:29f8d4e9477c: rtsp: Use AVERROR() with errno.h error codes for error returns
[10:41:03 CET] <rcombs> JEEB: if you'd like I can send you some .scc files
[10:41:29 CET] <rcombs> (SMPTE timecodes + hex representation of the A/53 packets)
[15:28:39 CET] <durandal_1707> i'm desperate, can not find solution for 8x4 idct scan table
[15:29:45 CET] <Lynne> well the dc should remain in the same position, its a start
[15:30:09 CET] <durandal_1707> so, 15! combinations?
[15:30:11 CET] <BBB> durandal_1707: can you provide a test?
[15:30:30 CET] <BBB> like, give me a sequence of integers read from the bitstream in order of occurence in the bitstream
[15:30:36 CET] <BBB> and the output of the 2x4x4 idct
[15:32:37 CET] <durandal_1707> output of idct is hard to get, i need to use debugger and set breakpoints to read it
[15:34:00 CET] <BBB> it would help a lot to know the output
[15:34:51 CET] <BBB> (and input)
[15:35:33 CET] <durandal_1707> thing is for 8x8 transform they use zigzag but with down direction, and our is with right direction, and i get correct output using our zigzag
[15:38:37 CET] <BBB> it's just transposed
[15:38:42 CET] <BBB> because our idct is transposed
[15:38:46 CET] <BBB> (it makes simd easier)
[15:38:58 CET] <BBB> I cna explain but you probably don't want to know :)
[15:39:08 CET] <BBB> so with 8x4, it'd be the same thing, o we just don't transpose our idct
[15:39:12 CET] <BBB> it's not too different really
[15:39:56 CET] <durandal_1707> i use their 8 idct and 4 idct with their permutation and still get incorrect results
[15:40:48 CET] <durandal_1707> when i used our 8 row idct i got bunch of overflows
[15:40:56 CET] <durandal_1707> integer idct*
[15:41:53 CET] <durandal_1707> i could fetch output of idct, but i'm still unsure what idct they use
[15:42:19 CET] <durandal_1707> because codepath diverge for opencl/cuda and pure CPU code
[15:45:02 CET] <BBB> let's start wih input and output
[15:45:08 CET] <BBB> I already have disassembly from you earlier
[16:38:34 CET] <cone-947> ffmpeg 03James Almer 07master:aedffc0b220b: avcodec/mlp_parser: mark sync frames as key frames
[16:38:34 CET] <cone-947> ffmpeg 03Yuki Tsuchiya 07master:610473b9679b: lavc/codec_desc: introduce AV_CODEC_PROP_INTRA_ONLY flag to audio codec
[16:38:34 CET] <cone-947> ffmpeg 03Yuki Tsuchiya 07master:30047b6a571d: lavc: add MPEG-H 3D Audio codec id
[16:38:34 CET] <cone-947> ffmpeg 03Yuki Tsuchiya 07master:632b8298b709: lavf/isom: support for demuxing and remuxing of MPEG-H 3D Audio in MP4
[16:38:34 CET] <cone-947> ffmpeg 03James Almer 07master:6467a159979f: Changelog: add entry about MPEG-H 3D Audio support in mp4
[16:38:34 CET] <cone-947> ffmpeg 03Yuki Tsuchiya 07master:0ceed513d563: lavf/movenc: cosmetics
[16:39:55 CET] <JEEB> :)
[16:40:08 CET] <JEEB> nice stuff
[16:40:43 CET] <JEEB> jamrial: thanks.
[16:40:49 CET] <JEEB> now to see if we can get a decoder :P
[16:44:28 CET] <durandal_1707> why was changelog changed? please revert ASAP!
[16:44:28 CET] <cone-947> ffmpeg 03Linjie Fu 07master:8446318502bf: lavc/qsvenc: add Tiles encode support for HEVC
[16:44:29 CET] <cone-947> ffmpeg 03Zhong Li 07master:a87b5d5e8c94: lavc/x265: set preferred_transfer_characteristics for HLG
[17:12:39 CET] <mkver> durandal_1707: Your mvha decoder contains a unused-but-set variable.
[17:18:06 CET] <durandal_1707> mkver: where?
[17:18:49 CET] <mkver> size in decode_frame
[17:19:29 CET] <mkver> Seems that the packet data contain a redundant size field, but you used pkt->size instead.
[17:21:30 CET] <durandal_1707> it should be checked and used so it is not bigger than packet size
[17:23:58 CET] <mkver> Then do it.
[17:53:43 CET] <durandal_1707> mkver: feel free to do it, since i'm busy with other stuff
[17:56:12 CET] <jamrial> durandal_1707: you could fix it when you have the time
[17:56:21 CET] <durandal_1707> BBB: the only app that i can debug sucessfully uses lowres, so its not useful
[17:56:27 CET] <durandal_1707> jamrial: i never have time
[18:56:33 CET] <BBB> durandal_1707: can still be useful
[18:56:38 CET] <BBB> it's merely downsampled, right?
[18:57:20 CET] <durandal_1707> BBB: you couldnt belive it, i GUESSED it!
[18:57:41 CET] <BBB> the table?
[18:57:43 CET] <durandal_1707> yes
[18:57:52 CET] <BBB> thumbs-up-smiley !
[18:58:01 CET] <BBB> 👍
[18:58:10 CET] <BBB> good job
[18:58:15 CET] <BBB> so ... it's really an idct8?
[18:58:18 CET] <BBB> that is so weird
[18:59:01 CET] <durandal_1707> pseuedo chroma is idct8x4, pseudo Y is idct8x8
[18:59:45 CET] <BBB> so weird
[18:59:46 CET] <BBB> ok
[18:59:48 CET] <BBB> well, good job
[19:02:17 CET] <Lynne> told you, now go and get a lottery ticket
[19:17:57 CET] <durandal_1707> still need to figure out how they get RGB out of this
[19:24:18 CET] <Lynne> its not yuv?
[19:27:22 CET] <durandal_1707> nope
[19:30:44 CET] <Lynne> nice
[19:39:58 CET] <cone-947> ffmpeg 03Andreas Rheinhardt 07master:56ce2ad2cccf: avformat/mov: Use ff_alloc_extradata for dvdsub extradata
[19:39:59 CET] <cone-947> ffmpeg 03Andreas Rheinhardt 07master:2e328a8a38e0: avformat/apngdec: Make sure that extradata is zero-padded
[19:40:00 CET] <cone-947> ffmpeg 03Andreas Rheinhardt 07master:c1d300f83a00: avformat/apngdec: Don't free extradata manually
[19:40:01 CET] <cone-947> ffmpeg 03Andreas Rheinhardt 07master:cb88cdf7730e: avformat/rtpdec_hevc: Don't reimplement ff_alloc_extradata
[19:40:02 CET] <cone-947> ffmpeg 03Andreas Rheinhardt 07master:c1e439d7e9ab: avformat: Forward errors where possible
[19:40:03 CET] <cone-947> ffmpeg 03Andreas Rheinhardt 07master:82d61a9ce3e2: avformat: Don't free old extradata before ff_alloc/get_extradata
[19:40:04 CET] <cone-947> ffmpeg 03Linjie Fu 07master:bffb9326b6b3: lavc/mips: simplify the switch code
[19:40:04 CET] <cone-947> ffmpeg 03Linjie Fu 07master:7aef2f59b518: lavc/utils.c: fix code indentations
[19:40:06 CET] <cone-947> ffmpeg 03Michael Niedermayer 07master:ab3044368f3f: avcodec/v210dec: move the stride read after its fully initialized
[20:52:13 CET] <thardin> boy what a fun ticket
[20:54:03 CET] <thardin> it struck me how absolutely impossible it would be to seek to the middle of an MXF, in terms of presentation (material) timestamps
[20:54:56 CET] <thardin> one doesn't really know where the indexes are located
[21:02:59 CET] <JEEB> yup
[22:40:13 CET] <cone-529> ffmpeg 03Michael Niedermayer 07master:9d1f7870a9de: avfilter: Fix type in av_log for random_seed in cellauto and life
[22:57:14 CET] <cone-529> ffmpeg 03Martin Storsjö 07master:f58bda642d6d: checkasm: af_afir: Use a dynamic tolerance depending on values
[00:00:00 CET] --- Fri Dec 13 2019