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

Sat Feb 4 03:05:04 EET 2017

[00:01:31 CET] <cone-017> ffmpeg 03Aman Gupta 07master:037bb4021c0b: avfilter/scale: refactor common code for scaling height/width expressions
[00:25:56 CET] <tmm1> jkqxz: is there a plan for how to make vf_scale_qsv work (similar to the hwupload hack for vaapi)
[00:28:49 CET] <cone-017> ffmpeg 03Michael Niedermayer 07master:ad7a3f5294c6: avcodec/utils: Fix memleak with subtitles and sidedata
[00:35:03 CET] <jkqxz> tmm1:  The plan is to merge from libav, since it all works properly there.  The main blocker is the delayed filter setup stuff, though there might be other issues we don't know about yet.
[00:37:44 CET] <tmm1> ah ok, i'll look and see how they did it
[00:38:06 CET] <tmm1> are you planning to merge the vappi deinterlacer patches soon too?
[00:38:07 CET] <jkqxz> If you are planning to do any more with vaapi or qsv, then you probably want to look at libav to avoid duplicating anything.
[00:39:27 CET] <jkqxz> Yeah, I'll get around to it again soon.  (That series got blocked by weird webp abuse of the VP8 decoder making tests fail.)
[00:40:23 CET] <tmm1> great
[00:42:19 CET] <jkqxz> There is also a load of VAAPI encode queued up to merge (10-bit H.265, MPEG-2, VP8, improved setup; VP9 is pending on the libav ML and will follow too).
[00:45:09 CET] <tmm1> exciting stuff
[00:47:12 CET] <tmm1> i've been testing on a variety of devices and it works great
[00:48:32 CET] <tmm1> apart from a weird issue on a 3.10 kernel where encoding speed is several times slower compared to a 3.12 kernel on the same cpu
[00:50:11 CET] <jamrial> jkqxz: can't ac7bfd69678f3966e38debdb27f4bde94dc0345c be merged already for that matter? It was skipped because of some missing code that's afaik now committed
[00:50:38 CET] <cone-017> ffmpeg 03Aman Gupta 07master:3606602f1137: avutil/hwcontext_vaapi: fix SEGV in vaTerminate when vaInitialize fails
[00:51:31 CET] <jkqxz> ^ :)  Thanks for noticing that one.
[00:52:41 CET] <jkqxz> I'm not sure anyone will care about kernels that old nowadays...
[00:53:51 CET] <jkqxz> jamrial:  Yes.  It wouldn't be usable in ffmpeg.c, but that isn't really a dependency.
[01:14:09 CET] <tmm1> wow i've been missing all the fun on libav-devel
[01:14:22 CET] <tmm1> "vaapi_encode: Fix GOP sizing" i noticed this bug too
[02:16:08 CET] <atomnuker> bofh_: did you get stuck on the fft15 asm?
[02:16:52 CET] <atomnuker> (opus encoder's on the ML if you care to try your luck at a faster pvq search)
[03:34:08 CET] <cone-017> ffmpeg 03Michael Niedermayer 07master:39afd0482fde: avcodec/ituh263dec: Implement U263s interpretation of H.263 B frames
[04:29:40 CET] <bofh_> atomnuker: I just glanced at the PVQ search and my first thought on the if (K) { block (ie most of it) was "this is basically just a Cholesky decomposition with a really weird inner product, and we're using it to solve a QP (which makes sense if it's a full RD minimization as that's just a QP you get from applying Lagrange multipliers)
[04:30:30 CET] <bofh_> the good news is this means you can probably do it a lot faster with cleverness, the bad news is that's hard.
[04:32:20 CET] <bofh_> I am curious how much worse the distortion gets if you replace the sqrtf with an inline rcpss + a single Newton iteration
[04:33:27 CET] <bofh_> (putting the + FLT_MIN into the sqrt first). since that div+sqrt is almost certainly very costly.
[04:34:46 CET] <bofh_> (rcpss gives iirc 11(?) bits of precision, so it should agree with 1/sqrtf(x) to 2ULPs at worst)
[06:16:00 CET] <bofh_> ...and by rcpss I obviously actually mean rsqrtss, hurr.
[09:42:57 CET] <nevcairiel> this entire matroska reference block thing is weird, what would ever even use it
[09:43:07 CET] <nevcairiel> with modern codecs and multiple refs its impossible anyway
[09:45:47 CET] <TD-Linux> it might have been inspired by ogg granulepos, but it's too underdefined to be used in that way
[09:46:36 CET] <TD-Linux> also you can specify multiple of them
[09:46:57 CET] <TD-Linux> might be good to survey if any existing implementations actually read it and propose deprecating it if ont
[09:53:25 CET] <wm4> TD-Linux: indeed
[09:53:53 CET] <wm4> for what's it worth, the mplayer/mpv mkv demuxer also always checked the value for 0
[12:26:18 CET] <atomnuker> bofh_: rcpss give enough precision, its what libopus uses
[12:28:25 CET] <atomnuker> you can't really be cleverer than libopus though, someone has put their blood and sweat into making it as fast as possible for the last 8 or so years
[12:29:41 CET] <atomnuker> the only different solution I heard was to use qsort to sort the pulses after preprojection since the distribution is likely arranged like that afterwards
[12:29:48 CET] <atomnuker> but that's not simdable
[12:56:17 CET] <durandal_1707> anyone likes midequalizer filter?
[13:41:09 CET] <JEEB> grmbl grmbl
[13:43:07 CET] <JEEB> was testing the sub2video thing and ended up with a corner case in which something gets initiated incorrectly
[13:53:00 CET] <JEEB> will have to try to create a sample that makes this happen, but I bet it's lack of initialization on the subtitle track (no packets or something) when the filter chain was created https://kuroko.fushizen.eu/screenshots/sub2video/mpv-shot0002.png
[13:54:07 CET] <JEEB> also I remember someone mentioning asm sections and lower case
[13:54:15 CET] <JEEB> 7abdd02 * asm: Consistently uppercase SECTION markers
[13:54:26 CET] <JEEB> ^seemingly got fixed @ the other side
[14:44:35 CET] <bofh_> atomnuker: such a search really isn't very SIMDable in the first place nearest I can tell, apart from the easy loops at the start
[14:44:53 CET] <bofh_> let me look at libopus's impl...
[14:56:02 CET] <bofh_> okay, so first off, I was right, this is a tesselation of a unit polytope
[14:56:57 CET] <bofh_> secondly, THEY ACTUALLY FIND THE CLOSED FORM FOR THE OPTIMAL SOLUTION AND IT'S SOME TERRIBLE THING INVOLVING THE GAUSS HYPERGEOMETRIC FUNCTION 2F1(m;n;2;2)??!??!?
[14:57:06 CET] <bofh_> https://people.xiph.org/~tterribe/notes/cwrs.html
[14:58:15 CET] <bofh_> okay, yeah, there is no way to be more clever than that. that was one step *further* than what I was proposing.
[14:58:35 CET] <bofh_> I hadn't even considered that as a possibility.
[15:01:54 CET] <atomnuker> bofh_: that's the indexization code
[15:02:23 CET] <atomnuker> its irrelevant to the pvq search
[15:02:45 CET] <cone-618> ffmpeg 03Clément BSsch 07master:f7a7ea716865: doc: add a lexicon
[15:05:56 CET] <bofh_> atomnuker: it's not quite, since U(n,m) is a function of V(n,m), and it seems like it's very simple because of how things are sorted? it just goes up dimension and splits in half when needed nearest I can tell?
[15:08:08 CET] <atomnuker> yes, when the cost goes above 32 its split in half and again if its still above, but that's all beside the point
[15:09:03 CET] <atomnuker> all I'm trying to do is make the pvq search function faster
[15:09:32 CET] <atomnuker> emphasis on "function", not "coding process"
[15:12:11 CET] <bofh_> well then I'd start with trying av_always_inline float fast_invsqrtf_x86(float x) { float y; __asm__ __volatile__("rsqrtss %1, %0\n\t" :"=x"(y) :"x"(x)); return 0.5f * y * (3.0f - (x * y * y)); } and seeing how much that helps, since you said it's enough precision
[15:13:24 CET] <bofh_> (also I'm not sure qsort would help there. a radix sort might, though, if it can be used).
[15:18:30 CET] <atomnuker> well, libopus does avoid the sqrt in the C version
[15:18:57 CET] <atomnuker> in fact they avoid computing the distortion over every single index in the first place
[15:54:52 CET] <Compn> how about dng support as a qualification task or maybe even gsoc project? https://trac.ffmpeg.org/ticket/4364
[15:55:14 CET] <Compn> BBB , kierank, wm4 ^ 
[15:55:22 CET] <nevcairiel> supporting raw images is a maintenance nightmare, just use libraw
[15:56:06 CET] <Compn> qual task to add libraw into ffmpeg ?
[15:56:16 CET] <Compn> wrapper that is
[15:58:59 CET] <Compn> nevcairiel ?
[15:59:21 CET] <BBB> Compn: find a mentor? :)
[15:59:38 CET] <BBB> Compn: Im not particularly interested in mentoring video non-codecs, theyre kind of boring
[15:59:45 CET] <BBB> Compn: didnt vittorio have a special itch for that kind of stuff?
[16:01:24 CET] <Compn> i dont recall
[16:01:26 CET] <Compn> someone did
[16:01:39 CET] <Compn> maybe i just want to bait durandal_1707 into doing it :D
[16:03:21 CET] <BBB> haha that may actually be a good idea ;)
[16:42:08 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:4535861ef828: avformat/options_table: Set the default maximum number of streams to 1000
[16:42:09 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:198c8924c609: avformat/utils: Print verbose error message if stream count exceeds max_streams
[16:42:10 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:c4b36ccd0291: avutil/random_seed: Improve get_generic_seed() with higher precission clock()
[16:42:11 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:a0b7a3c8aaa8: avutil/random_seed: Reduce the time needed on systems with very low precission clock()
[16:42:12 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:72d5addc0bea: avcodec/mjpegdec: Check for rgb before flipping
[16:42:13 CET] <cone-618> ffmpeg 03Tobias Rapp 07release/3.0:a6639334df63: avformat/avidec: skip odml master index chunks in avi_sync
[16:42:14 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:99c78466ff27: avcodec/pngdec: Fix off by 1 size in decode_zbuf()
[16:42:15 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:02323b1d025c: avcodec/mjpegdec: Check remaining bitstream in ljpeg_decode_yuv_scan()
[16:42:16 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:3e03d12c8352: avcodec/vp56: Check for the bitstream end, pass error codes on
[16:42:17 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:cfbab858094b: avcodec/utils: correct align value for interplay
[16:42:18 CET] <cone-618> ffmpeg 03Frank Liberato 07release/3.0:44eaff5e6d65: avformat/flacdec: Check avio_read result when reading flac block header.
[16:42:19 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:a71d22d84daf: avcodec/mjpegdec: Check for for the bitstream end in mjpeg_decode_scan_progressive_ac()
[17:31:33 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/3.0:dfca37f0e513: Update for 3.0.6
[17:44:54 CET] <wm4> lol this cinepak guy is continuing with this environment variable nonsense
[17:45:43 CET] <wm4> by now he should pretty much have understood that this is not wanted, but he proposes to extend it to all decoders or something
[17:46:33 CET] <kierank> wm4: to play devils advocate he is kinda right about this part:
[17:46:34 CET] <kierank> The choice depends
[17:46:34 CET] <kierank> among others e.g. on how fast swscaler is on the particular hardware
[17:46:34 CET] <kierank> (use it or not?)
[17:46:51 CET] <kierank> but then again ffmpeg isn't the place for stupidly riced cinepak
[17:47:13 CET] <wm4> uh no
[17:47:35 CET] <wm4> ffmpeg.c is incredibly low level, so it's a given that you could add an option to it that influences get_format behavior
[17:48:07 CET] <wm4> (or anything else that influences the processing chain)
[17:48:41 CET] <wm4> and plain API users need their own logic to build an efficient processing chain
[17:52:06 CET] <nevcairiel> the key problem is that the user interaction just doesnt belong into avcodec
[17:52:23 CET] <wm4> yes
[17:52:33 CET] <nevcairiel> put it into whatever application he uses and implement get_format API there
[17:52:42 CET] <nevcairiel> now if that application is ffmpeg.c, tough look
[17:52:45 CET] <nevcairiel> write your own =p
[17:53:28 CET] <wm4> for ffmpeg.c, it'd be yet another obscure option that can be used to tweak performance and that nobody uses
[17:54:47 CET] <wm4> is there even a simple codec that supports multiple get_format (unrelated to hwaccel)?
[17:54:54 CET] <nevcairiel> nah
[17:54:58 CET] <nevcairiel> its only used for hwaccel
[17:55:14 CET] <wm4> for audio there's reques_sample_fmt which is supported by a handful of codecs
[17:55:17 CET] <nevcairiel> not sure it would even work, it may stop probing on the first nonhw format
[17:55:45 CET] <nevcairiel> but the guy isnt going to do that anyway, so might as well roll with that
[17:56:04 CET] <wm4> 8bps.c supports get_format with multiple sw formats
[17:56:15 CET] <wm4> (only one I found)
[17:56:20 CET] <nevcairiel> really?
[17:56:29 CET] <wm4> yes
[17:56:41 CET] <wm4> can select between BGR24 and GBR32
[17:56:46 CET] <nevcairiel> i wonder if you can even use that somehow through ffmpeg.c
[17:56:50 CET] <wm4> err 0RGB32
[17:57:05 CET] <wm4> doesn't look like
[17:57:10 CET] <jkqxz> No full video codec can really implement it because the frames you decode are also the reference frames, so any other answer is meaningless.
[17:57:37 CET] <wm4> but cinepak is a serious codec, as we know by now
[17:57:39 CET] <jkqxz> Something intra-only could do it, I guess.  Maybe JPEG could downsample automatically for you when you get a 4:2:2 JPEG?  That might be useful in some cases.
[17:57:51 CET] <wm4> jpeg has lowres
[17:58:05 CET] <wm4> which lets you decode it at 1/2 or 1/4 resolution
[17:58:14 CET] <wm4> I think it's also supposed to work for mpeg
[17:58:16 CET] <jkqxz> Yeah, that's basically the same thing.
[17:58:20 CET] <wm4> (Libav dropped this)
[18:05:00 CET] <wm4> pretty weird... get_format was added for mpeg decoding (long before hwaccel was a thing), but it supported only 1 pixfmt at the commit it was introduced, and it still supports only 1 pixfmt in the current git tree
[19:02:45 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:7d169ba1d882: lavf/isom: Support DTS Express in mov.
[19:16:59 CET] <durandal_1707> what you guys have on your todo list ?
[19:18:43 CET] <atomnuker> figure out how to adjust the stride of the forward mdct15, its the only thing keeping me from pushing the encoder
[19:19:54 CET] <atomnuker> it starts from the middle and casts the output as complex which makes it complicated, I should probably handle it as floats
[20:02:30 CET] <cone-618> ffmpeg 03Paul B Mahol 07master:207fa224a0f7: avcodec/mpc8: use init_get_bits8()
[20:13:28 CET] <BBB> I guess Im done with cinepak for the day ...
[20:15:04 CET] <jamrial> at this point you can all ignore this guy. his code isn't going to hit git master anyway
[20:18:03 CET] <BBB> I was trying to be nice and helpful
[20:18:16 CET] <BBB> BUT YOU DONT UNDERSTAND! ITS IMPORTANT! AND SPECIAL!
[20:18:20 CET] <BBB> TRUST ME!"
[20:18:25 CET] <BBB> ..
[20:19:12 CET] <cone-618> ffmpeg 03Paul B Mahol 07master:6a6e20bfdf6a: avcodec/mpc7: return meaningful error values
[20:19:13 CET] <cone-618> ffmpeg 03Paul B Mahol 07master:f09afb4a90b2: avcodec/mpc7: use init_get_bits8()
[20:21:52 CET] <wm4> jamrial: too late
[20:22:55 CET] <durandal_1707> michaelni: do not try to push that cinepak patches
[20:23:51 CET] <wm4> I don't think that's necessary to say at this point
[20:28:10 CET] <ubitux> the hell is this patch
[20:28:35 CET] <jamrial> mini swscale inside a fringe decoder or something
[20:29:00 CET] <BBB> yeah that patch had some issues
[20:30:20 CET] <ubitux> "mini" c-only swscale inside a decoder with pix fmt controlled by priv option or env
[20:30:24 CET] <ubitux> did i miss something?
[20:30:35 CET] <wm4> no, that's it
[20:30:44 CET] <ubitux> is there something good to take out of it?
[20:31:17 CET] <wm4> I'd say lose the env var, use get_format, reduce the number of pixfmts, and the patch is at least not a negative contribution to ffmpeg
[20:31:30 CET] <wm4> but then again, cinepak? wtf
[20:31:47 CET] <wm4> he claims it's the most efficient codec for his use-case
[20:31:55 CET] <wm4> whatever it is that involves 16 bit rgb output
[20:32:07 CET] <philipl> It's the best codec. Trust me, I know codecs. We've got the best codecs.
[20:32:26 CET] <ubitux> he seems to care about environment though
[20:33:13 CET] <ubitux> anyway, any progress on qsv or ffmpeg filter refactor?
[20:33:23 CET] <wm4> not here
[20:33:42 CET] <wm4> I guess I could actually try looking into it next week
[20:33:53 CET] <wm4> although I'm not looking particularly forward to it
[20:36:12 CET] <ubitux> what's tricky about qsv? do we really have a complex merge effort or it could be summarized by a code dump from libav?
[20:36:22 CET] <ubitux> we have mpeg4 or something like this iirc?
[20:38:21 CET] <cone-618> ffmpeg 03Paul B Mahol 07master:7ecdc03ea3da: avcodec/xsubdec: use init_get_bits8()
[20:38:22 CET] <cone-618> ffmpeg 03Paul B Mahol 07master:2b707018bca8: avcodec/metasound: use init_get_bits8()
[20:38:23 CET] <cone-618> ffmpeg 03Paul B Mahol 07master:c331be21c48a: avcodec/ivi: use init_get_bits8()
[20:39:13 CET] <wm4> nevcairiel probably knows best
[20:39:31 CET] <wm4> or maybe jkqxz 
[20:40:02 CET] <nevcairiel> qsv should be easy, not sure how much it interacts with the filter thing
[20:41:17 CET] <jkqxz> qsv should be straightforward.  Preserving compatibility is annoying (options are subtly different), but changes should merge without real difficulty.
[20:42:52 CET] <jkqxz> If you feel it's blocking anything, just paste the changes in as-is and if anything breaks I can try to fix up later.  (It was broken for months last year and noone cared, after all.)
[20:43:51 CET] <jkqxz> The filter thing just makes it some stuff impossible to test in ffmpeg.c without hackery.
[20:46:02 CET] <ubitux> so the ffmpeg filter refactor should go in first?
[20:55:07 CET] <jkqxz> Probably doesn't really matter?  Without it qsv only works by hackery anyway, and further stuff won't really change that (10-bit won't work, but that doesn't really matter because it never has before now either).
[21:26:25 CET] <philipl> jkqxz: any movement on the device context api change?
[21:31:56 CET] <jkqxz> philipl:  <https://lists.libav.org/pipermail/libav-devel/2017-February/082094.html> is current; still waiting for any more thoughts from elenril.
[21:33:44 CET] <jkqxz> I would have liked to leave in hw_device_ctx being able to be set/changed later, but in the end there isn't really a proper use case for it (despite it happening to be what ffmpeg/avconv does at the moment).  It also complicates the API definition a lot, so it was dropped.
[21:37:39 CET] <philipl> K.
[22:06:16 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:3edbc2408b69: avfilter/vf_ciescope: Free out AVFrame on error
[22:06:17 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:15b2c37d5e11: avfilter/vf_deshake: Free out AVFrame on error
[22:06:18 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:21a07ac191ad: avfilter/vf_fieldhint: Free out AVFrame on error
[22:06:19 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:19f567208cff: avfilter/vf_perspective: Free out AVFrame on error
[22:06:20 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:c347b286995a: avfilter/vf_unsharp: Free out AVFrame on error
[22:11:49 CET] <Compn> some dvr using ffmpeg to decode modified mpeg4 ? wonder where the source is... :)
[23:16:36 CET] <cone-618> ffmpeg 03Werner Robitza 07master:8addd56554eb: doc: clarify option on looping infinitely in movie filter
[23:17:58 CET] <michaelni> atomnuker, you fixed CID1363964 in 000eb01a7d14ee635bd0e554ea92e05feb8cf685 but coverity still claims the issue is there. if coverity is wrong please mark it as false positive
[23:45:04 CET] <atomnuker> michaelni: marked it as false positive
[23:45:29 CET] <atomnuker> michaelni: wasn't there a truehd coverity issue?
[23:47:03 CET] <michaelni> theres a mlpenc issue 1396239
[23:53:02 CET] <jkqxz> tmm1:  Can you build libva with debug enabled to clarify exactly what is failing there?
[23:53:27 CET] <jkqxz> I'm thinking it's right to revert, and that my issue is unrelated.
[00:00:00 CET] --- Sat Feb  4 2017