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

[burek]

[02:48:31 CET] <atomnuker> bofh_: any news on the fft15 SIMD?
[04:53:33 CET] <cone-033> ffmpeg 03Martin Vignali 07master:31e722e9da0b: libavcodec/psd : add test for channel depth/channel count in bitmap mode
[04:53:33 CET] <cone-033> ffmpeg 03Martin Vignali 07master:1412e5a004ea: fate/psd : add test for bitmap and duotone
[06:08:41 CET] <cone-033> ffmpeg 03Carl Eugen Hoyos 07master:c723108e2555: lavf/matroskaenc: Do not write two CodecID elements for rawvideo.
[06:08:42 CET] <cone-033> ffmpeg 03Carl Eugen Hoyos 07master:935404923dcd: Cosmetics: Reindent after last commit.
[06:26:56 CET] <rcombs> ubitux: one for the subtitles wishlist: I have a format here that's basically "index file and a bunch of PNGs"
[06:28:08 CET] <rcombs> I guess I can define a decoder for that that's just the PNG decoder, but it reads some packet extradata and makes an AVSubtitle with the specified position
[06:28:21 CET] <rcombs> *side-data
[06:41:09 CET] <atomnuker> rcombs: so each png is a separate file?
[06:41:15 CET] <rcombs> yup
[06:41:40 CET] <rcombs> actually this is all distributed in a .zip but I'm comfortable telling anyone who wants lavf to read that without decompressing first to go fuck themselves
[10:41:51 CET] <ubitux> rcombs: i've heard of this with mmh mxf maybe
[10:50:36 CET] <wm4> PNG in what format?
[11:12:30 CET] <rcombs> wm4: literally PNG files
[11:16:34 CET] <wm4> png can decode to many pixel formats
[11:42:38 CET] <rcombs> wm4: ah, ffprobe says rgba
[15:41:48 CET] <cutesykitties> hello, may i ask a question about an issue i'm having using the libraries for ffmpeg in my app?
[15:42:53 CET] <RiCON> wrong channel, try #ffmpeg
[15:43:29 CET] <cutesykitties> okay
[16:45:59 CET] <faLUCE> Hello. How can I read from a v4l2 input with the libraries? For a file I can use:   av_file_map(input_filename, &buffer, &buffer_size, 0, NULL);   , but what for a live v4l2 device ?
[16:46:09 CET] <faLUCE> I have also:  avio_open2(&input, in_uri, AVIO_FLAG_READ, NULL, NULL))   <--- could I use this, instead?
[16:46:19 CET] <faLUCE> in_uri is a const char*  string, how can I specify a v4l2 input in this string?
[16:55:52 CET] <Sesse> faLUCE: #ffmpeg is the right place for this (cf. topic)
[16:58:26 CET] <cone-337> ffmpeg 03Paul B Mahol 07master:743052ec5bd6: avcodec/cinepakenc: remove CVID from long description
[19:50:49 CET] <durandal_170> can i include apache 2 license code in ffmpeg ?
[19:51:17 CET] <j-b> you can
[19:51:23 CET] <j-b> but it's not very nice
[19:51:29 CET] <j-b> it makes your code GPLv3 or LGPLv3
[19:59:01 CET] <Compn> durandal_170 : no problem , just make sure to put it in the configure under --enable-nongpl or whatever
[19:59:18 CET] <Compn> for the three people who compile --enable-gpl :P
[19:59:49 CET] <Compn> i guess maybe distros too, they wont like --enable-nonfree
[20:03:40 CET] <jamrial> Compn: compiling with --enable-gpl is pretty much a must, unless you only want internal decoders
[20:04:48 CET] <cone-337> ffmpeg 03Michael Bradshaw 07master:3ac46a0a6238: ffmpeg: Add -time_base option to hint the time base
[20:56:50 CET] <wbs> BBB: michaelni: do either of you have time to push the vp9/arm/aarch64 cherrypicks patchset I sent earlier this week?
[20:57:05 CET] <BBB> is it ok if I do it Monday?
[20:57:16 CET] <wbs> sure, that's ok with me
[20:58:34 CET] <wbs> BBB: fwiw, I've got 10/12 bit stuff pretty much done now; I'll wait a few more days to see if I think of something more about it, then I'll send those patches
[21:05:42 CET] <BBB> ok, cool
[21:11:48 CET] <JEEB> btw, is there still no way to use swscale with AVFrames? not that I'd want to use swscale :D
[21:12:16 CET] <JEEB> because the last I did you had to re-create the avframe after swscale'ing an image buffer
[21:12:39 CET] <michaelni> wbs, i can push the i assume 13 patches from 0109 23:15 if you want ?
[21:13:02 CET] <JEEB> also, props for whomever wrote https://trac.ffmpeg.org/wiki/swscale
[21:13:06 CET] <JEEB> I'm loving it <3
[21:13:36 CET] <wbs> michaelni: yes, that's the one I mean - thanks!
[21:14:04 CET] <michaelni> ok, will push in a few minutes
[21:23:05 CET] <BBB> JEEB: I wrote that
[21:36:18 CET] <cone-337> ffmpeg 03Janne Grunau 07master:62ea07d797c5: aarch64: vp9: use alternative returns in the core loop filter function
[21:36:19 CET] <cone-337> ffmpeg 03Janne Grunau 07master:cb220eeef9bf: aarch64: vp9: loop filter: replace 'orr; cbn?z' with 'adds; b.{eq,ne};
[21:36:20 CET] <cone-337> ffmpeg 03Janne Grunau 07master:a71cd8439fd3: arm: vp9itxfm: Simplify the stack alignment code
[21:36:21 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:a95e7de41dc3: aarch64: vp9itxfm: Use w3 instead of x3 for the int eob parameter
[21:36:22 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:4a5874ea8d0c: arm/aarch64: vp9itxfm: Fix indentation of macro arguments
[21:36:23 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:f69dd26df555: arm: vp9itxfm: Rename a macro parameter to fit better
[21:36:24 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:37cb224e3e65: aarch64: vp9itxfm: Don't repeatedly set x9 when nothing overwrites it
[21:36:25 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:ecd343aa1ffb: arm: vp9itxfm: Only reload the idct coeffs for the iadst_idct combination
[21:36:26 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:388f6e6715ff: arm: vp9itxfm: Skip empty slices in the first pass of idct_idct 16x16 and 32x32
[21:36:27 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:8b11a89c06b9: aarch64: vp9itxfm: Skip empty slices in the first pass of idct_idct 16x16 and 32x32
[21:36:28 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:656d910981b6: arm: vp9mc: Fix vertical alignment of operands
[21:36:29 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:02cfb9a16e6f: aarch64: vp9dsp: Fix vertical alignment in the init file
[21:36:30 CET] <cone-337> ffmpeg 03Martin Storsjö 07master:0ba018753549: aarch64: vp9mc: Fix a comment to refer to a register with the right name
[21:50:10 CET] <wbs> michaelni: thanks!
[21:51:23 CET] <wbs> BBB: in the vp9 loop filter, I guess it's implausible/impossible to have E == 255?
[21:51:52 CET] <BBB> I think theres more strict limits imposed in the bitstream, yes
[21:52:05 CET] <BBB> I forgot what they are exactly, but should be trivial to calculate from the E/I calculations in vp9.c
[21:52:15 CET] <BBB> I can look it up if you really need to know
[21:52:19 CET] <BBB> will take a few minutes or so
[21:52:34 CET] <wbs> nah, it's probably ok then - I see that libvpx does an optimization in their asm that seems to assume this
[21:58:14 CET] <wm4> JEEB: I have a 3 year old patch for sws+avframe
[21:59:04 CET] <wm4> BBB: sws actually intensively uses avoption
[21:59:40 CET] <BBB> wm4: that doesnt mean its great
[22:00:04 CET] <BBB> it just means somebody took the effort of converting the sws internal enums etc. into an avoptions struct
[22:00:08 CET] <wm4> no, I dislike avoption-centric APIs
[22:00:21 CET] <BBB> avoptions is great for some people
[22:00:28 CET] <BBB> we offer it, along with a generic C api
[22:00:33 CET] <BBB> and you can choose which one you use
[22:00:34 CET] <wm4> ffmpeg.c people
[22:00:36 CET] <BBB> but both need to be sensible
[22:00:45 CET] <BBB> no, no
[22:00:52 CET] <BBB> avoptions also makes sense as an introspection layer
[22:00:52 CET] <wm4> they don't need to write frontend code for those
[22:00:55 CET] <BBB> think gstreamer or so
[22:01:04 CET] <wm4> eww
[22:01:11 CET] <wm4> generic genericness
[22:01:46 CET] <BBB> look, some people are into that
[22:01:51 CET] <BBB> were not here to tell whos evil or not
[22:02:06 CET] <kierank> problem is the avoptions stuff is never documented
[22:02:10 CET] <BBB> were here to write a layer of stuff that can be used regardless of your level of evilness according to some authority
[22:02:11 CET] <kierank> we only have .h documentation
[22:03:30 CET] <JEEB> more like .c
[22:03:44 CET] <JEEB> because the avoptions are defined in each decoder/component
[22:03:51 CET] <wbs> BBB: hmm, if you can spare some time to look at what it can be theoretically, that'd be appreciated - it's nested a few layers too deep to find the max easily by reading the code for me. empirically, the largest value I found was 187, in the sintel clip. and that's not all that far from 255
[22:03:55 CET] <JEEB> and then maybe mentioned in the docs
[22:06:58 CET] <kierank> JEEB: yeah
[22:07:03 CET] <kierank> to use normal structs you can look in the .h
[22:07:12 CET] <kierank> but avoptions you actually need to dig into the source code
[22:07:14 CET] <kierank> so it's not a real api
[22:07:17 CET] <kierank> which is why i hate it
[22:07:53 CET] <wm4> in theory they're documented in .texi or whatever that is
[22:07:58 CET] <wm4> of course never with types etc.
[22:08:13 CET] <wm4> feels like it's documented for ffmpeg.c use
[22:19:39 CET] <BBB> mblim_lut[lvl] = 2 * (lvl + 2) + limit
[22:19:42 CET] <BBB> (thats E)
[22:19:53 CET] <wbs> BBB: yep. so what are the max values of lvl and limit?
[22:20:32 CET] <BBB> lvl [0,63]
[22:20:53 CET] <BBB> and limit:
[22:20:54 CET] <BBB>             if (sharp > 0) {
[22:20:55 CET] <BBB>                 limit >>= (sharp + 3) >> 2;
[22:20:57 CET] <BBB>                 limit = FFMIN(limit, 9 - sharp);
[22:20:58 CET] <BBB>             }
[22:20:59 CET] <BBB>             limit = FFMAX(limit, 1);
[22:21:12 CET] <BBB> sharp [0,7]
[22:21:43 CET] <BBB> so limit >>= 0 or 1 or 2
[22:21:50 CET] <BBB> making limit still [0,63]
[22:22:00 CET] <BBB> and then still [0,63]
[22:22:09 CET] <BBB> so by that, limit is [1,63]
[22:22:22 CET] <BBB> making E 2*[0,63])+[1,63]
[22:22:36 CET] <BBB> so [1,3x63=189]
[22:22:43 CET] <wbs> ok, thanks - then it should indeed be safe
[22:22:59 CET] <wbs> if it could go >255, the mix2 functions would break anyway
[22:23:02 CET] <BBB> I is [1,63]
[22:23:19 CET] <BBB> right, I think that was based on the assumtion that it cant be
[22:24:24 CET] <wbs> BBB: the max is 2*([0,63] + 2) + [1,63], thus [5,193] actually (I think you missed the +2 part)
[22:24:27 CET] <wbs> but still safe yes
[22:24:48 CET] <BBB> uh yes youre right
[00:00:00 CET] --- Sun Jan 15 2017