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

[burek]

[00:05:34 CEST] <thardin> there we go, 208542 is not a legal frame size in D-10
[00:17:20 CEST] <thardin> more parsing/grammar related errors, woo
[02:23:28 CEST] <philipl> BtbN: on that cc trac ticket. I assume he's not using -hwaccel_output_format so isn't doing full transcode and gets poor performance.
[02:24:30 CEST] <cone-647> ffmpeg 03Chip Kerchner 07master:3a557c5d88b7: lsws/ppc/yuv2rgb_altivec: Replace vec_lvsl/vec_perm with vec_xl
[04:49:41 CEST] <cone-647> ffmpeg 03Zhong Li 07master:8cd96e13eea8: fate: add a case for ticket #3229
[11:38:48 CEST] <thardin> mrrr, mixing indentation and functional changes
[11:39:42 CEST] <nevcairiel> get a diff viewer that doesnt suck :D
[11:43:50 CEST] <thardin> let's see if I can configure kompare
[11:46:23 CEST] <BtbN> philipl, in his original h264_cuvid pastes it's using software-nv12 as well.
[11:58:39 CEST] <philipl> all kinds of suboptimal then.
[12:10:56 CEST] <BtbN> But I thought we fixed the nvdec software-path being slow compared to cuvid
[12:11:16 CEST] <thardin> so looking at #3077, the muxer expects 49999840 bps for NTSC
[12:11:40 CEST] <thardin> but it should really be 49999840,16 bps
[12:12:16 CEST] <thardin> else you obviously won't get every frame to be 208541 bytes
[12:12:40 CEST] <kierank> thardin: in x264 we hack it to produce the exact frame size
[12:12:49 CEST] <kierank> for this kind of condition
[12:13:01 CEST] <thardin> kierank: lavc should have an option for strict cbr
[12:13:22 CEST] <thardin> this isn't the only place where people want this
[12:13:38 CEST] <kierank> the /1001 thing will still be a problem
[12:13:52 CEST] <thardin> not if I want 49999840.16 bps
[12:14:09 CEST] <thardin> or, 208541 bytes per frame as the spec says
[12:14:11 CEST] <kierank> not sure how you can signal that
[12:14:21 CEST] <thardin> you don't
[12:14:26 CEST] <thardin> mxf doesn't have bit rate signalling at all, I think
[12:15:12 CEST] <thardin> hm, it does for the mpegvideodescriptor. but that's of course only informative
[12:15:30 CEST] <kierank> I mean signal that to lavc
[12:15:42 CEST] <thardin> a flag should do it
[12:16:06 CEST] <thardin> I looked at the rate control stuff a while back, got horrified, and immediately stopped looking
[12:16:49 CEST] <thardin> d-10 doesn't actually require strict cbr tho, it's just that baptiste removed the code in the muxer that added padding and whatnot
[12:17:08 CEST] <thardin> at least not cbr on the essence stream
[12:17:20 CEST] <nevcairiel> mpeg2 has a special option to set the framesize iirc, opposed to the overall bitrate
[12:17:28 CEST] <nevcairiel> i think i used it once to make strict dvd compatible video
[12:18:49 CEST] <thardin> -rc_eq maybe?
[12:19:20 CEST] <nevcairiel> maybe i'm also misremembering
[12:23:28 CEST] <thardin> doesn't seem to help
[12:26:33 CEST] <philipl> BtbN: I can't try his command line just yet. Won't be back with nvidia access for a couple of days
[16:40:00 CEST] <cone-792> ffmpeg 03Nicolas George 07master:2b4c1a0f3cdb: tools/aviocat: add verbose mode.
[16:40:01 CEST] <cone-792> ffmpeg 03Nicolas George 07master:6e1a2dc11236: lavf/aviobuf: make AVSEEK_SIZE usable from outside.
[16:40:02 CEST] <cone-792> ffmpeg 03Nicolas George 07master:3add65e052cf: lavf/concat: implement FFSEEK_SIZE.
[16:40:03 CEST] <cone-792> ffmpeg 03Andreas Rheinhardt 07master:de010d229a18: libavformat/subfile: Fix SEEK_CUR and SEEK_END seeking
[17:53:53 CEST] <zandam> hello
[17:54:19 CEST] <zandam> I have a scenario with multiple video source, from different ip cameras, and foreach video input I have to make multiple video processings: a live stream, a recording and one or more opencv elaborations. 
[18:25:53 CEST] <BtbN> https://devtalk.nvidia.com/default/topic/1060977 nice
[18:27:14 CEST] <durandal_1707> nobody cares for corporate blackbox stuff
[18:27:28 CEST] <BtbN> "Fixed the cuvidParseVideoData API in the NVCUVID driver to correctly propagate errors returned by the PFNVIDSEQUENCECALLBACK callback function to the application."
[18:27:34 CEST] <BtbN> that only took them... 2 years? 3 years?
[18:27:37 CEST] <BtbN> philipl, ^
[18:32:05 CEST] <BtbN> They also FINALLY implemented dynamic per-application render offloading
[20:27:24 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:021f29506b49: avcodec/hevcdec: Check delta_luma_weight_l0/1
[20:27:25 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:8f92eb05e063: avcodec/4xm: Check for end of input in decode_p_block()
[20:27:26 CEST] <cone-792> ffmpeg 03gxw 07master:a3e572d96fd1: avutil/mips: refine msa macros CLIP_*.
[20:27:27 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:db78bc1297eb: avcodec/vp56: Consider the alpha start as end of the prior header
[20:27:28 CEST] <cone-792> ffmpeg 03Lars Kiesow 07master:74d4bc0fa0e0: libavfilter/vf_scale: Ensure scaled video is divisible by n
[20:27:29 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:1e2e47e34811: tools/target_dec_fuzzer: Print max_pixels and iterations at the end
[21:15:47 CEST] <TekuConcept> When adding new hardware acceleration support, how do I update the configuration to link with the external library?
[21:17:30 CEST] <TekuConcept> Everything compiles just fine, but I am getting linker errors. ffbuild/config.sh shows that my lib is not added as a linker dependency to avcodec
[21:25:11 CEST] <Lynne> check_pkg_config will automatically add c/ldflags if its detected
[21:25:20 CEST] <Lynne> what are you adding support for?
[21:27:08 CEST] <TekuConcept> h264 aml hardware acceleration
[21:28:05 CEST] <TekuConcept> I manually compiled and installed libamcodec so I don't think pkg_config is going to be very useful here
[21:35:44 CEST] <Lynne> enabled libwavpack        && require libwavpack wavpack/wavpack.h WavpackOpenFileOutput  -lwavpack
[21:36:02 CEST] <Lynne> or just copy https://github.com/LongChair/FFmpeg/commit/90735fcbc47fae185ed59f63a9e0350c77ed9c8e
[21:38:23 CEST] <TekuConcept> The implementation in that repository is broken, but that is where I got the sources. I fixed up all the broken code and now just have linker issues. I'll give "require libamcodec" a try.
[21:38:59 CEST] <Lynne> yes, that code is low quality and hacky
[22:29:15 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:fbbc8ba67f19: avcodec/diracdec: Check that slices are fewer than pixels
[22:29:16 CEST] <cone-792> ffmpeg 03Michael Niedermayer 07master:52939a2c5772: avcodec/indeo2: Check remaining input more often
[22:43:16 CEST] <Lynne> amd's working on a vulkan hwardware decoding extension
[22:43:50 CEST] <Lynne> bets on how that will turn out will not be accepted, its just not profitable
[22:44:06 CEST] <BtbN> Isn't Nvidia working on that as well?
[22:44:18 CEST] <BtbN> Would be about time. One API for all OS, except Apples walled garden.
[22:46:25 CEST] <Lynne> that's the intention, but I can't imagine it working well across all platforms, and there will be android specific hacks because android
[22:47:23 CEST] <Lynne> an ideal api would accept something like host-mapped memory with relaxed alignment requirements so you could zero-copy decode from slices onto images
[22:47:41 CEST] <Lynne> or at least single copy with an intermediary buffer
[22:49:23 CEST] <Lynne> but the only way to have any agreement between everyone would be a single "give me a decode context, give me a whole frame packet, and I'll parse and decode it"
[23:06:09 CEST] <TekuConcept> I'm back! require passes (initially I was using check_lib, which also passed), but the lib is still not added to the dependency list; thoughts?
[23:07:15 CEST] <TekuConcept> where would ${name}_extralibs be appended to avcodec's list?
[23:13:57 CEST] <BradleyS> speaking of vulkan, anyone taking a look at https://patchwork.ffmpeg.org/patch/14319/
[23:40:12 CEST] <durandal_1707> nope
[23:47:34 CEST] <BradleyS> and then he dips, classic
[00:00:00 CEST] --- Wed Aug 14 2019