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

[burek]

[00:00:16 CEST] <jamrial> what allocation?
[00:00:18 CEST] <jkqxz> Oh, it does.  The leb128() always ends on a zero byte, and the padding has to be zeroes.
[00:00:29 CEST] <jkqxz> Of the AV1OBU structures.
[00:01:31 CEST] <jamrial> that's an array of packets, each containing a pointer to the bitstream. i'm not allocating/memcpying the actual bitstream anywhere
[00:01:59 CEST] <jkqxz> Yeah, but the structures themselves aren't persistent anywhere are they?
[00:02:32 CEST] <jamrial> no, and much like h2645_parse they don't need to
[00:03:14 CEST] <jamrial> if i were to make it actually alloc and copy the data into each packet then the speed gains from using this split code would be gone
[00:03:21 CEST] <jamrial> using cbs would make more sense in that case
[00:06:10 CEST] <jamrial> pass it a packet, it parsers it and gives you a bunch of pointers to each described obu, including some basic info about each obu. you're then meant to do something with that data while it's valid
[00:06:47 CEST] <jamrial> the parser would just get the parameters it needs. cbs would copy it into its internal fragments
[00:08:03 CEST] <jamrial> it's like h2645_parse but without the emulation prevention, so there's no alloc/memcpy/escape overhead
[07:18:00 CEST] <cone-497> ffmpeg 03Steven Liu 07master:6fbfb20faf22: avformat/hls: remove redundant code
[08:20:44 CEST] <cone-497> ffmpeg 03Steven Liu 07master:4effd1c4a2c5: avformat/dashdec: Avoid multiple HTTP requests for initialization segment that is common among all representations
[08:33:01 CEST] <cone-497> ffmpeg 03Steven Liu 07master:36deec010cc8: avformat/hls: copy rw_timeout from parent to child AVIOContexts.
[08:33:02 CEST] <cone-497> ffmpeg 03Steven Liu 07master:6eaaad37f89e: Revert "avformat/dashdec: Avoid multiple HTTP requests for initialization segment that is common among all representations"
[08:33:53 CEST] <cone-497> ffmpeg 03Steven Liu 07master:0b3c1854cb98: Revert "avformat/hls: copy rw_timeout from parent to child AVIOContexts."
[08:43:57 CEST] <cone-497> ffmpeg 03sanilraut 07master:9e2b4c7ecc30: libavformat/dashdec: Avoid multiple HTTP requests for initialization segment that is common among all representations
[08:43:58 CEST] <cone-497> ffmpeg 03Richard Shaffer 07master:6a1be7561c87: avformat/hls: copy rw_timeout from parent to child AVIOContexts.
[08:43:59 CEST] <cone-497> ffmpeg 03Richard Shaffer 07master:c116221d90d6: avformat/hls: clean up duplicate option fields
[10:38:58 CEST] <thardin> why is there a gsoc task around ffserver if it has been dropped?
[10:40:45 CEST] <Chloe> thardin: it was dropped for technical reasons not because it wasnt wanted
[10:42:24 CEST] <thardin> ah. I thought obs had taken the place of it
[11:07:02 CEST] <BtbN> obs is not a server.
[11:07:23 CEST] <BtbN> Something like ffserver actually is kind of in demand. But ffserver was just a bunch of dead code.
[11:49:07 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:01ba52852d2a: avformat/dashenc: replacing 'min_seg_duration' with 'seg_duration'
[11:49:08 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:ab789e184c20: avformat/dashenc: segmentation at the configured segment duration rate
[11:49:09 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:51888c85d4c1: avformat/dashenc: writing average segment duration for @duration in template mode
[11:49:10 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:1263d9119867: avformat/dashenc: removed 'write_manifest' call from 'write_header'
[11:49:11 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:3e75057a1d70: avformat/dashenc: setting @availabilityStartTime when the first frame is ready
[11:49:12 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:990380367b07: avformat/dashenc: addition of @availabilityTimeOffset in MPD
[11:49:13 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:85ae55eca390: avformat/dashenc: logic to compute muxer overhead
[11:49:14 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:0c7bc7eb4789: avformat/dashenc: addition of muxer overhead in master playlist's bandwidth
[11:49:15 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:af6058d03b6f: avformat/dashenc: constructing MPD's bandwidth string locally
[11:49:16 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:2c51e33bc1e2: avformat/dashenc: addition of muxer overhead for @bandwidth param in MPD
[11:49:17 CEST] <cone-497> ffmpeg 03Vishwanath Dixit 07master:d10cefbfe50e: avformat/dashenc: addition of segment index correction logic
[12:41:34 CEST] <cone-497> ffmpeg 03Paul B Mahol 07master:2fc12f4971a7: avfilter: add lowshelf and highshelf filters
[16:30:47 CEST] <durandal_1707> what should i do next?
[16:31:17 CEST] <nevcairiel> take a nap, thats always a good choice
[16:32:02 CEST] <durandal_1707> a already nap 1/3 of lifetime
[16:42:05 CEST] <jamrial> durandal_1707: lavfi negotiation of the missing avframe fields, like color stuff
[16:59:54 CEST] <durandal_1707> jamrial: $$$$$$$$$$$$$$
[17:06:18 CEST] <durandal_1707> does anyone have samples with blocking artifacts?
[17:08:40 CEST] <atomnuker> just encode some low res jpegs at low bitrate
[18:36:40 CEST] <CounterPillow> or H.263
[20:11:44 CEST] <exastiken_> Hi.
[20:13:08 CEST] <exastiken_> I would like to make an openCL kernel for encoding a video with x265 library in ffmpeg
[20:15:48 CEST] <exastiken_> I know that the code currently uses x265_api_get to get an api structure, then uses that structure to run encode.
[20:18:21 CEST] <exastiken_> it uses x265_api_get in libx265_encode_init
[20:18:54 CEST] <exastiken_> then in libx265_encode_frame, it uses ctx->api->encoder_encode(ctx->encoder, &nal, &nnal, pic ? &x265pic : NULL, &x265pic_out);
[20:19:07 CEST] <exastiken_> with the ctx holding the x265 api
[20:19:16 CEST] <exastiken_> with the encoder_encode function from x265
[20:19:52 CEST] <exastiken_> how can I replace the encoder_encode function with my own?
[20:20:15 CEST] <nevcairiel> you should probably talking to the x265 encoder people
[20:20:35 CEST] <nevcairiel> but note that something like OpenCL is really not quite sutiable for complex encoding tasks like that
[20:20:59 CEST] <exastiken_> we'll be accelerating only a small portion of the encoding
[20:21:56 CEST] <exastiken_> also, I'm a bit confused with how to compile the doc/example for encoding video.
[20:33:36 CEST] <exastiken_> i've set up pkg-config and attempting make, but getting a lot of undefined references
[20:37:16 CEST] <atomnuker> BBB: do you think you can feed the av1 transforms 16-bit coeffs like vp9 for 8 bits?
[20:37:27 CEST] <BBB> yes
[20:38:08 CEST] <atomnuker> derf had some concerns that it *might* have been broken with the mess that we had to go through which was txmg
[20:38:33 CEST] <atomnuker> even for 64x64 transforms?
[20:39:10 CEST] <BBB> yes
[20:39:34 CEST] <BBB> and I agree daala_tx would have been fun, but hey, no use looking back now, right?
[20:39:36 CEST] <BBB> :-/
[20:40:26 CEST] <atomnuker> I still can't believe we have 64x64 transforms in av1, considering how long a few people had to fight for them to not have regressions but give gains
[20:41:55 CEST] <TD-Linux> I think they'll be useful in a real encoder too though.
[20:43:05 CEST] <atomnuker> maybe we shouldn't have cut 3/4 of the coeffs but relied on the encoder knowing when to signal eob
[20:43:48 CEST] <atomnuker> oh well, maybe it was done because some other parts of the code made the assumption of no more than 32x32's worth of coeffs
[20:47:00 CEST] <TD-Linux> it was to avoid huge transposes and scan tables
[20:48:23 CEST] <atomnuker> 4096 isn't huge, we could have limited the number of scan tables for 64x64 blocks
[21:01:33 CEST] <exastiken_> I'm currently working on the doc/examples, specifically encode_video. I've set PKG_CONFIG_PATH to /home/myuser/ffmpeg_build/lib/pkgconfig
[21:01:58 CEST] <exastiken_> with /home/myuser/ffmpegbuild being where ffmpeg is installed
[21:02:36 CEST] <exastiken_> can't seem to get the example to work
[21:02:42 CEST] <exastiken_> undefined references to libraries
[21:05:15 CEST] <BtbN> OpenCL for x265? That's not going to happen I'd say.
[21:06:12 CEST] <exastiken_> BtbN: what's the biggest issues?
[21:06:27 CEST] <BtbN> After how "successfull" that went for x264...
[21:06:33 CEST] <BtbN> GPUs are just not well suited for video encoding.
[21:06:53 CEST] <exastiken_> I'm working with FPGAs
[21:07:07 CEST] <BtbN> With OpenCL?
[21:07:24 CEST] <exastiken_> yes
[21:07:39 CEST] <BtbN> That sounds weird. OpenCL is designed for the parallelism of GPUs and similar devices after all.
[21:08:12 CEST] <exastiken_> we've got an intel compiler for OpenCL to work with FPGAs
[21:09:29 CEST] <BtbN> That won't change the design of the language though
[21:09:48 CEST] <BtbN> I can see someone writing an accelerator with VHDL or something. But OpenCL?
[21:12:12 CEST] <exastiken_> We'll be accelerating a small portion of the encoding.
[21:14:26 CEST] <cone-577> ffmpeg 03Timo Teräs 07release/4.0:de253343c151: ffprobe: report unavailable SAR correctly in stream info
[21:14:27 CEST] <cone-577> ffmpeg 03Timo Teräs 07release/4.0:ca85c3cd7d64: avformat/movenc: support writing iTunes cover image
[21:14:41 CEST] <cone-577> ffmpeg 03Timo Teräs 07master:c663dce031b3: ffprobe: report unavailable SAR correctly in stream info
[21:14:42 CEST] <cone-577> ffmpeg 03Timo Teräs 07master:9af71b326fda: avformat/movenc: support writing iTunes cover image
[21:19:53 CEST] <BtbN> That's exactly how OpenCL is used in x264
[21:20:04 CEST] <BtbN> and it's sometimes faster, sometimes slower than pure software
[21:20:19 CEST] <BtbN> and generally pretty useless due to that
[21:20:28 CEST] <BtbN> even if it's faster, it's so minimal it's barely worth it
[21:24:19 CEST] <exastiken_> even so, we'd still like to proceed with it.
[21:25:09 CEST] <exastiken_> Since we will be doing high level synthesis from the OpenCL code.
[21:30:35 CEST] <BBB> atomnuker: yeah the special things in tx64 are stupid, but agian, what do you do
[21:30:46 CEST] <BBB> and yes, tx64 should give gains on non-cif content
[21:31:01 CEST] <BBB> I still dont understand why the downscaling is also done for non-8bits/component
[21:31:05 CEST] <BBB> thats dumb
[21:31:06 CEST] <BBB> same for tx32
[21:31:22 CEST] <BBB> ¯\_(Ä)_/¯
[21:38:34 CEST] <BBB> you could also do the scaling same as hevc and always scale post-quant coefs to 15+sign bits, instead of these special rules where its imin(15, 12+log2(txsz/4))+sign
[21:38:52 CEST] <BBB> it wouldnt give any gains, but at least it would be consistent
[21:50:40 CEST] <atomnuker> not sure if what hevc does is better
[21:51:00 CEST] <atomnuker> sure its consistent but what if your dequant coeffs are huge?
[21:52:46 CEST] <atomnuker> which can happen if you use weird wavelet transforms
[22:04:10 CEST] <cone-577> ffmpeg 03Richard Shaffer 07master:9a8811f478db: libavformat/http: Fix memory leak in get_cookies.
[22:18:03 CEST] <BBB> but there is no wavelet in hevc
[22:18:11 CEST] <BBB> or av1
[22:18:27 CEST] <BBB> I mean I understand the theoretical concern, but I think in this particular case its not really an issue
[22:21:57 CEST] <atomnuker> yeah I guess
[22:23:17 CEST] <atomnuker> oh so hevc has an identical coeff range for all bitdepths?
[22:23:40 CEST] <atomnuker> after dequant
[22:24:30 CEST] <BBB> from what I recall, yes it does
[22:24:47 CEST] <BBB> it makes sense in a way, if you max at 15 anyway, why not always max at 15?
[22:25:18 CEST] <BBB> again, it obviously doesnt help quality, esp. given the shitty inverse transform precision in hevc
[22:25:26 CEST] <BBB> so their round trip error is pretty terrible already
[22:25:29 CEST] <BBB> but at least its consistent
[22:25:34 CEST] <BBB> txmg is a lot nicer that way
[22:25:50 CEST] <BBB> in terms of precision, I prefer vp9, but what can you do
[22:26:48 CEST] <TD-Linux> are you ready for 256x256 transforms in JEM
[22:28:04 CEST] <thardin> these larger transforms.. are they only ever used for flatter areas?
[22:28:32 CEST] <thardin> feels like one could get away with always truncating them
[22:28:41 CEST] <TD-Linux> yes, and that's why they do
[22:28:47 CEST] <thardin> cool
[22:29:20 CEST] <TD-Linux> they can also have utility in places in large evenly textured areas, where the truncation isn't so great, but that also isn't as common
[22:29:23 CEST] <nevcairiel> high-res anime or stuff like that may like it
[22:30:55 CEST] <BBB> Im not sure flat is the only part
[22:31:02 CEST] <BBB> you need spatially contiguous
[22:31:04 CEST] <BBB> so larger shapes
[22:31:10 CEST] <BBB> imagine that you have a cif image
[22:31:16 CEST] <BBB> and you upsample it to uhd (4k)
[22:31:29 CEST] <BBB> there is basically no high-frequency signal here, its all artificial
[22:31:30 CEST] <BBB> so
[22:31:37 CEST] <BBB> large transforms should be ideal
[22:31:42 CEST] <BBB> but that doesnt mean flat
[22:31:54 CEST] <BBB> just spatially contiguous
[22:32:23 CEST] <BBB> whether truncating is the right way to go; probably yes for compression purposes, it does make testing a little bit more annoying though :-/
[22:33:03 CEST] <BBB> 256x256 is pretty insane though, Im so not writing assembly for that :D
[22:37:10 CEST] <JEEB> TD-Linux: that reminds me of talking to that NHK JEM guy
[22:37:15 CEST] <jamrial> just wait for avx-2048
[22:37:27 CEST] <JEEB> "oh yea, we kept upping things to eleven. I think this is the last format where we'll still be able to do that"
[22:37:47 CEST] <JEEB> "more motion vector positions, bigger block sizes"
[22:49:54 CEST] <atomnuker> BBB: yeah, I'm banking on 64x64 transforms max for ffv2/daala
[22:50:32 CEST] <atomnuker> I don't think larger sized transforms make sense, not until 16kx8k videos become popular
[22:51:46 CEST] <atomnuker> here's a horrifying thought: they'll define extensions to codecs where for larger resolutions they use shallow wavelet transforms and encode each filter separately so they add up
[22:53:17 CEST] <atomnuker> I wonder why google didn't propose using wavelets for progressive coding of still images with av1
[22:55:58 CEST] <BBB> there was a proposal to do that for vp9
[22:56:04 CEST] <BBB> its a terrible idea
[22:56:23 CEST] <durandal_1707> no, its not
[22:57:02 CEST] <BBB> ok, so some people think its not
[22:58:40 CEST] <atomnuker> its alright as long as a _single_ packet contains everything needed for a single image
[22:59:23 CEST] <atomnuker> but OBU people would go "THIS SOUNDS LIKE A JOB FOR AN OBU, HERE WE COOOOOOOME" and then you get heif or something
[23:04:23 CEST] <atomnuker> actually I don't think there's a sane way to handle that without needing a new api
[23:04:38 CEST] <atomnuker> progressive encoding makes sense if you partically decode images
[23:05:14 CEST] <atomnuker> but if everything's in one packet you can't really easily split it up
[23:05:38 CEST] <TD-Linux> yeah you would need a new (libaom) api at minimum
[23:05:54 CEST] <TD-Linux> you can do progressive decode just with tile groups where you send one TG OBU at a time
[23:06:02 CEST] <TD-Linux> or you could do sub-TG progressive decode
[23:06:42 CEST] <BBB> are you suggesting people are seriously intending to use libaom for anything useful?
[23:06:59 CEST] <TD-Linux> yes
[23:07:10 CEST] <BBB> I thought the whole point of proposing new opensource decoders (from scratch) and rav1e was so that nobody would have to deal with that codebase?
[23:07:11 CEST] <TD-Linux> maybe
[23:07:32 CEST] <TD-Linux> BBB, ok sure, I mean people are going to have to use libaom for a little while until the alternatives are ready
[23:08:01 CEST] <TD-Linux> but my comments are valid about any other ABI as well. but currently I can only point to the libaom one.
[23:09:48 CEST] <durandal_1707> is libaom finally frozen?
[23:11:37 CEST] <TD-Linux> no
[23:11:48 CEST] <TD-Linux> it's slushy
[23:11:51 CEST] <atomnuker> durandal_1707: ask in a week + 1 day
[23:18:24 CEST] <sfan5> is libaom finally fast?
[23:18:56 CEST] <atomnuker> lol no
[23:24:43 CEST] <nevcairiel> hrm ever since I'm using a more recent build of avformat again I get reports of HLS demuxing being rather broken, did someone screw this up again
[23:25:02 CEST] <jamrial> nevcairiel: hls got a shitload of commits in the past weeks/months
[23:25:04 CEST] <jamrial> so yeah
[23:25:11 CEST] <durandal_1707> incompetent developers
[23:25:46 CEST] <jamrial> acutally not a shitload, just a lot
[23:26:03 CEST] <nevcairiel> it feels like this hls stuff is being written and reviewed in the same group of people without some real actual external review
[23:26:25 CEST] <jamrial> indeed
[23:28:08 CEST] <nevcairiel> i should probably try to reproduce it with ffmpeg CLI and see if i can bisect it
[23:28:18 CEST] <jamrial> nevcairiel: maybe tmm1 can help you debug this
[23:28:52 CEST] <nevcairiel> its people reporting pretty generic failures, like playing a twitch stream or something typically generic
[23:30:05 CEST] <exastiken_> I'm getting a fatal error with making the doc/examples
[23:30:17 CEST] <exastiken_> libavfilter/avf_showcqt.c:35:22: fatal error: ft2build.h: No such file or directory
[23:30:54 CEST] <jamrial> isn't that freetype2?
[23:32:46 CEST] <exastiken_> I guess?
[23:32:52 CEST] <exastiken_> but it's not in the makefiles
[00:00:00 CEST] --- Wed Apr 18 2018