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

[burek]

[02:03:25 CET] <kierank> durandal_1707: https://github.com/kierank/ffmpeg-cfhd
[03:20:38 CET] <cone-133> ffmpeg 03Jean Delvare 07master:47b2ba987872: avfilter/vf_delogo: change the definition of logo_x2 and logo_y2
[03:59:42 CET] <cone-133> ffmpeg 03Janne Grunau 07master:2dba0407fdb8: avcodec/arm64: fix inverted register order in transpose_4x4H
[10:42:59 CET] <cone-872> ffmpeg 03Matthieu Bouron 07master:c2ad24832139: swscale/arm/yuv2rgb: simplify process_16px_* macro call
[10:52:51 CET] <cone-872> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:532a28338305: ffserver: unify exit path from build_feed_streams()
[10:52:51 CET] <cone-872> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:4ba148a6ea2c: ffserver: refactor build_file_streams()
[10:52:52 CET] <cone-872> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:ae2ed20b5912: ffserver: refactor build_feed_streams()
[12:32:33 CET] <cone-872> ffmpeg 03Andreas Cadhalpun 07master:9f82506c7987: nutdec: only copy the header if it exists
[14:27:31 CET] <cone-872> ffmpeg 03Marton Balint 07master:c413d9e6356e: ffplay: remove existing AVPicture usage
[14:29:38 CET] <cone-872> ffmpeg 03Andreas Cadhalpun 07master:9d38f06d05ef: xwddec: prevent overflow of lsize * avctx->height
[15:13:15 CET] <BtbN> huh, there's a travis control file in the ffmpeg git?
[15:14:00 CET] <J_Darnley> Perhaps it was committed by accident?  (Not that I know what one of those is)
[15:16:05 CET] <atomnuker> it's origin seems to be libav
[15:16:39 CET] <atomnuker> nevcairiel merged it on the 7th of september
[15:17:48 CET] <atomnuker> oh wait, seeems to be older, 6bcd3e0599 did that on the 13th of August
[15:18:35 CET] <atomnuker> "It is useful to support a future staging branch and to have an automated consistency check on github pull requests."
[17:59:07 CET] <cone-872> ffmpeg 03Andreas Cadhalpun 07master:ce10f572c12b: nutdec: reject negative value_len in read_sm_data
[18:42:13 CET] <cone-872> ffmpeg 03Ganesh Ajjanagadde 07master:def3c83e1b85: lavc/aacsbr: sbr_dequant optimization
[18:42:14 CET] <cone-872> ffmpeg 03Ganesh Ajjanagadde 07master:641cb77f501a: lavfi/vf_idet: replace round and cast by lrint
[18:42:15 CET] <cone-872> ffmpeg 03Ganesh Ajjanagadde 07master:18bc3dc7681c: lavf/hlsenc: replace round by lrint
[18:42:16 CET] <cone-872> ffmpeg 03Ganesh Ajjanagadde 07master:425c0685f245: lavfi/vf_cropdetect: replace round by lrint
[18:42:17 CET] <cone-872> ffmpeg 03Ganesh Ajjanagadde 07master:5484cbe9f765: lavfi/vsrc_mandelbrot: replace round by lrint
[18:42:18 CET] <cone-872> ffmpeg 03Ganesh Ajjanagadde 07master:0dd8a3d71e2c: lavu/intmath: add faster clz support
[19:31:29 CET] <cone-872> ffmpeg 03Paul B Mahol 07master:ebe1ca01d153: avfilter/vf_stereo3d: add interleave columns input support
[19:43:16 CET] <durandal_1707> ubitux: send nlmeans patch?
[20:18:57 CET] <BtbN> So, time for VAAPI VP9.
[20:23:00 CET] <fritsch> :-)
[20:23:05 CET] <fritsch> got a Broxton already?
[20:23:11 CET] <BtbN> No
[20:23:21 CET] <fritsch> so blind implementing?
[20:23:21 CET] <BtbN> But the hybrid driver claims it's supported
[20:23:28 CET] <fritsch> ah! right
[20:23:50 CET] <durandal_1707> can I add soundtouch wrapper in our code?
[20:25:01 CET] <kierank> durandal_1707: any comments on cfhd code?
[20:26:18 CET] <durandal_1707> I just looked at it, and saw that you just started :/
[20:31:06 CET] <kierank> well there's a working bitstream parser
[20:31:10 CET] <kierank> and coeff unpack
[20:31:12 CET] <kierank> just transform left
[20:32:16 CET] <durandal_1707> isn't that the most complicated?
[20:33:51 CET] <kierank> depends how much can be reused
[20:44:03 CET] <cone-872> ffmpeg 03Michael Niedermayer 07master:2d2b41d16996: avcodec/ffv1enc: Fix 2 pass mode with the default rc table
[20:47:13 CET] <Daemon404> ffv1 has 2pass?
[20:49:12 CET] <durandal_1707> Long time
[20:50:18 CET] <Daemon404> to what end?
[20:50:38 CET] <Daemon404> better p-frames?
[20:51:49 CET] <nevcairiel> even lossless codecs need frame type decisions
[20:51:59 CET] <nevcairiel> if they have an inter mode
[20:52:43 CET] <Daemon404> i cant imagine youd want to use such a long keyframe interval in a lossless codec (for sekign reasons)
[20:52:54 CET] <Daemon404> in which case 2oass wouldnt be much better than lookahead
[21:15:38 CET] <BtbN> Is there any documentation on that DXVA_PicParams_VP9::wFormatAndPictureInfoFlags variable? I'd like to know which bit is which
[21:16:18 CET] <BtbN> The only thing I found on google is this: http://pastebin.com/MWxuy7wx
[21:16:27 CET] <nevcairiel> No, i guessed it all
[21:16:27 CET] <nevcairiel> :D
[21:17:27 CET] <nevcairiel> https://www.microsoft.com/en-us/download/details.aspx?id=49188
[21:17:31 CET] <nevcairiel> you should work on your google-fu
[21:17:57 CET] <BtbN> It's not in the normal MSDN?
[21:18:21 CET] <nevcairiel> the dxva specs are all downloadable documents, not online documented
[21:18:50 CET] <nevcairiel> since they have a somewhat formal character for hardware vendors as well
[21:24:27 CET] <BtbN> This is just one huge "What does VAAPI mean by this and why did they rename it" again
[21:24:41 CET] <BtbN> At least they commented some of it
[21:25:08 CET] <fritsch> hehe
[21:25:12 CET] <fritsch> perhaps libyami helps a bit
[21:25:18 CET] <fritsch> to see the mapping
[21:25:56 CET] <fritsch> https://github.com/01org/libyami/blob/master/decoder/vaapidecoder_vp9.cpp#L133
[21:52:47 CET] <BtbN> Does VP9 even support multiple slices?
[21:53:18 CET] <BtbN> Looking at the code in vp9.c, it's impossible.
[21:57:41 CET] <ubitux> durandal_1707: no, i only have a very naive implementation (as in: not usable), i'm currently studying the different way of optimizing
[21:58:07 CET] <ubitux> are you in a hurry?
[21:59:14 CET] <durandal_1707> no, is quality usable?
[21:59:38 CET] <durandal_1707> If yes, push optimize later
[22:02:18 CET] <ubitux> it's too slow to be usable
[22:02:35 CET] <ubitux> understand minutes for a frame on a high end computer
[22:03:38 CET] <durandal_1707> ooo
[22:04:06 CET] <ubitux> just give me some time
[22:04:18 CET] <ubitux> it's an interesting problem, i don't want to rush it
[22:05:58 CET] <BtbN> So... that should be it. Less exciting than expected.
[22:07:37 CET] <fritsch> BtbN: does it work?
[22:07:48 CET] <BtbN> No idea, there is no player that supports it yet.
[22:07:59 CET] <BtbN> But I'm done setting everything VAAPI wants.
[22:08:29 CET] <fritsch> kodi changes are minimal for it
[22:08:35 CET] <fritsch> one moment
[22:09:05 CET] <BtbN> Yes, making those right now, about to PR them
[22:09:48 CET] <fritsch> add an VA_CHECK_VERSION(0,38,1) or something?
[22:10:03 CET] <BtbN> That should be the version for it, yes
[22:10:04 CET] <cone-872> ffmpeg 03Matthieu Bouron 07master:e0dc22b99e85: swscale/arm/yuv2rgb: disable neon if accurate_rnd is enabled
[22:10:05 CET] <cone-872> ffmpeg 03Matthieu Bouron 07master:b32a42295ad7: swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb,rgba,abgr,bgra}_neon_{16,32}
[22:10:16 CET] <fritsch> yeah - I started the moment you said player is missing
[22:10:20 CET] <fritsch> but will await your PR
[22:10:37 CET] <fritsch> if all goes well: 5 lines
[22:13:56 CET] <BtbN> https://github.com/BtbN/xbmc/commit/a73eace63bd509d5cf88785437ceac544f0ac2b2 that should be it
[22:14:13 CET] <fritsch> jep
[22:14:15 CET] <fritsch> :-)
[22:15:09 CET] <BBB> BtbN: vp9 has tiles but not slices
[22:17:23 CET] <fritsch> BtbN: where did you get the libcmrt libs for linux?
[22:17:37 CET] <BtbN> same github account
[22:17:41 CET] <BtbN> as the driver itself
[22:17:53 CET] <fritsch> thx found it
[22:19:33 CET] <cone-872> ffmpeg 03Michael Niedermayer 07master:b92b4775a0d0: avcodec/h264_refs: Fix long_idx check
[22:27:16 CET] <fritsch> I only see: VAProfileVP8Version0_3 on my braswell btbn
[22:27:35 CET] <fritsch> scratch that - I know why :-)
[22:27:45 CET] <BtbN> https://bpaste.net/show/d5c0864b9dec
[22:33:14 CET] <fritsch> does it work in kodi?
[22:33:58 CET] <BtbN> Kodi is building
[22:34:41 CET] <BtbN> ~30 minutes left
[22:47:42 CET] <fritsch> BtbN: i don't get the hybrid driver picked up ... anything you need in environment?
[22:47:46 CET] <cone-872> ffmpeg 03Paul B Mahol 07master:7caf381a95d4: avfilter/af_dynaudnorm: use av_malloc_array()
[22:48:01 CET] <fritsch> http://paste.ubuntu.com/14106818/
[22:48:38 CET] <BtbN> I'd guess your libva version is too old.
[22:48:43 CET] <fritsch> nope 1.6.2
[22:48:52 CET] <BtbN> It's not 0.38.1
[22:49:07 CET] <fritsch> it is
[22:49:27 CET] <fritsch> i don't get the codec profiles by the hybrid driver
[22:49:42 CET] <BtbN> I didn't do anything for it
[22:49:55 CET] <BtbN> try LIBVA_DRIVER_NAME=hybrid vainfo
[22:50:14 CET] <fritsch> there it is
[22:50:41 CET] <fritsch> i thought somehow libva would do that automatically http://paste.ubuntu.com/14106862/
[22:51:17 CET] <cone-872> ffmpeg 03James Almer 07master:0f520e489a65: avcodec/Makefile: add missing dep for g723_1 encoder
[22:51:40 CET] <BtbN> It does, if your libva and specialy the intel-driver is recent enough
[22:51:57 CET] <fritsch> 1.6.2 from two days ago
[22:52:10 CET] <BtbN> Too old propably
[22:52:12 CET] <fritsch> hehe
[22:52:15 CET] <BtbN> I'm using git master of both
[22:54:10 CET] <fritsch> let's see
[22:55:32 CET] <fritsch> BtbN: nope
[22:56:16 CET] <BtbN> Keep in mind that it's the libva-intel-driver which chain-loads the hybrid driver. You need the latest one of that, too
[22:56:21 CET] <fritsch> jep
[22:56:27 CET] <fritsch> i need to specify the hybrid dir
[22:56:37 CET] <fritsch> err --enable-hybrid-codec
[22:56:39 CET] <fritsch> default is no
[22:57:46 CET] <BtbN> oh, right. I added that.
[22:57:50 CET] <fritsch> now it works
[22:57:51 CET] <fritsch> :-)
[22:57:52 CET] <fritsch> hehe
[23:07:14 CET] <cone-872> ffmpeg 03Ganesh Ajjanagadde 07master:062e3e23824b: lavu/libm: add copysign hack
[23:08:48 CET] <BtbN> Hm, I'm missing VP9 media samples :D
[23:09:33 CET] <Daemon404> youtube.com
[23:11:00 CET] <BtbN> A 4K60 sample propably wasn't the best idea
[23:11:14 CET] <fritsch> hehe
[23:11:21 CET] <jamrial> use youtube-dl to get some 1080p vp9 samples. try popular videos like movie trailers
[23:11:24 CET] <fritsch> transcode it? to 1080p60?
[23:11:32 CET] <BtbN> It plays, looks fine
[23:11:35 CET] <BtbN> but at like 2FPS
[23:11:35 CET] <fritsch> nice
[23:11:50 CET] <fritsch> checked that hw accel is used?
[23:12:11 CET] <BtbN> yes, it plays fine if it's disabled
[23:12:15 CET] <fritsch> hehe
[23:12:21 CET] <fritsch> that's what I assumed
[23:12:28 CET] <Daemon404> hw'accel'
[23:12:35 CET] <fritsch> that hybrid stuff is not really 4k uhd 60p ready
[23:15:07 CET] <BtbN> yes, a 1078p sample plays perfectly fine
[23:15:25 CET] <fritsch> you got a link?
[23:15:36 CET] <BtbN> https://www.youtube.com/watch?v=0vrdgDdPApQ
[23:15:45 CET] <BtbN> the 1078p VP9 version
[23:15:56 CET] <fritsch> 1078p
[23:16:15 CET] <J_Darnley> noice
[23:16:18 CET] <BtbN> No idea what's the matter with that, but that's the resolution
[23:16:41 CET] <fritsch> dump question - which tool did you use to download?
[23:16:44 CET] <fritsch> youtubedownloader?
[23:17:10 CET] <BtbN> youtube-dl
[23:17:27 CET] <BtbN> youtube-dl -f 248 "https://www.youtube.com/watch?v=0vrdgDdPApQ"
[23:17:35 CET] <fritsch> working
[23:17:39 CET] <fritsch> thx
[23:19:13 CET] <BtbN> Seems to be only 30 fps though
[23:20:58 CET] <fritsch> 23.976
[23:21:02 CET] <fritsch> says mediainfo
[23:21:34 CET] <BtbN> Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1920x1080, SAR 1:1 DAR 16:9, 60 fps
[23:21:37 CET] <BtbN> that should be better
[23:21:47 CET] <fritsch> yeah - which one to download?
[23:22:44 CET] <jamrial> BtbN: youtube-dl -f 303 https://www.youtube.com/watch?v=MGyaR2sSBkA
[23:23:32 CET] <jamrial> that's vp9 1080p 60fps. footage from the new Battlefront game using some graphics mods
[23:26:00 CET] <BtbN> I can't spot any problems, decodes perfectly.
[23:26:11 CET] <BtbN> smooth playback, notably lower CPU usage
[23:26:16 CET] <jamrial> try -f 308 for 1440p, see how it runs with the hwaccel
[23:26:28 CET] <jamrial> or -f 315 for 4k
[23:26:39 CET] <BtbN> 4K dies
[23:26:46 CET] <BtbN> less than 1 FPS
[23:29:19 CET] <jamrial> a haswell can play the 1440p version above with BBB's decoder and CPU usage is like 30%
[23:29:31 CET] <BBB> 1 thread?
[23:29:46 CET] <jamrial> don't think so. used mpc-hc
[23:29:48 CET] <jamrial> decoding with ffmpeg i get >200fps
[23:29:57 CET] <BBB> thats probably multiple threads yes
[23:30:04 CET] <BBB> note we dont have any avx2 yet
[23:30:10 CET] <jamrial> yeah, that one is
[23:30:15 CET] <jamrial> we do. i added some :p
[23:30:16 CET] <BBB> if anyone wants to sponsor me a macbook pro wih haswell :D
[23:30:21 CET] <BBB> thats true
[23:30:25 CET] <BBB> but idct is missing
[23:30:29 CET] <jamrial> yeah
[23:30:32 CET] <BBB> loopfilter also
[23:30:39 CET] <BBB> idct would be very helpful
[23:30:43 CET] <nevcairiel> avx2 seems overrated for performance
[23:31:03 CET] <BBB> I tohught it helped in some cases?
[23:31:05 CET] <jamrial> i assume mpc-hc was multithreaded, but since it was only decoding 60fps it barely taxed the cpu
[23:31:26 CET] <nevcairiel> yes, in some, but its hard to judge due to all the sillyness with it
[23:31:34 CET] <JEEB> the issue with avx2 is that IIRC it downclocks the CPU with some things
[23:31:43 CET] <nevcairiel> the split lane thing, and the power requirement that downlocks the cpu slightly
[23:31:57 CET] <JEEB> right, that was it
[23:32:08 CET] <TD-Linux> how is avx2 overrated? it's twice the throughput!
[23:33:01 CET] <TD-Linux> maybe for older codecs with really small block sizes...
[23:33:06 CET] <jamrial> having twice the throughput than SSE code is not always great
[23:33:32 CET] <nevcairiel> the point is, that double throughput comes at a cast
[23:33:37 CET] <nevcairiel> cost*
[23:34:00 CET] <jamrial> for example, the sao_edge functions i wrote went from like 700k cycles to like 20k with ssse3
[23:34:02 CET] <atomnuker> JEEB: do skywells still do downclocking?
[23:34:09 CET] <jamrial> avx2 made that 10k
[23:34:12 CET] <nevcairiel> x265 ran into that blindly, just made avx2 variants of everything that could use the bigger regs, and then the overall process became slower :D
[23:34:30 CET] <jamrial> at that point, halving the cycle count of the ssse3 version is negligible
[23:35:20 CET] <TD-Linux> jamrial, well vs non vectorized code yes :)
[23:36:06 CET] <BBB> nevcairiel: well, wait, but the splitlane is just a coding thing
[23:36:17 CET] <BBB> nevcairiel: I mean, if you code an idct correctly, it has no effect on performance
[23:36:26 CET] <nevcairiel> sure, but it makes some things not 1:1 double size and hooray
[23:36:32 CET] <BBB> right
[23:36:59 CET] <BtbN> The 1440p sample is lagging badly
[23:37:45 CET] <JEEB> atomnuker: I don't have a skylake yet :)
[23:37:46 CET] <BtbN> I'd guess ~10-15 FPS
[23:37:53 CET] <JEEB> only a broadwell laptop for my new job
[23:37:54 CET] <BtbN> 4K is at like 2FPS
[23:38:10 CET] <BtbN> 1080p60 plays perfectly though
[23:39:10 CET] <BtbN> Great, it killed the GPU
[23:39:17 CET] <JEEB> rip
[23:39:27 CET] <BtbN> Screen is black, dmesg complains
[23:39:31 CET] Action: TD-Linux wonders if the real purpose of the hybrid decoder is to tick a spec box
[23:39:42 CET] <nevcairiel> at that steep speed loss, it sounds like you just OOM'ed the GPU
[23:39:59 CET] <BtbN> There's no VRAM on intel though
[23:40:04 CET] <BtbN> It just uses the system RAM
[23:40:15 CET] <nevcairiel> it should still reserve a maximum limit iirc
[23:40:23 CET] <BtbN> And HEVC 4K60 plays perfectly on that one
[23:40:26 CET] <nevcairiel> also, how much did you put into that braswell
[23:40:31 CET] <BtbN> 8GB
[23:40:39 CET] <TD-Linux> right but userspace allocations still shouldn't be much slower I think
[23:40:44 CET] <BtbN> The reserved portion you can set in your BIOS is entirely unused
[23:40:52 CET] <BtbN> I set that to the minimum, 32MB, as it's just plain wasted.
[23:40:54 CET] <BtbN> It does nothing
[23:41:06 CET] <TD-Linux> BtbN, 8bit HEVC? IIRC 8bit HEVC is not hybrid
[23:41:23 CET] <BtbN> yes, but it uses the same amount of GPU RAM, if not more.
[23:42:21 CET] <TD-Linux> also Youtube 4k VP9 streams are tiled IIRC, so it's a mystery
[23:42:38 CET] <BtbN> Well, i have set all flags VAAPI wants, it works, so I guess all ffmpeg can do about it. Should work better on a non-hybrid platform.
[23:42:43 CET] <BtbN> To the ML with it
[23:46:32 CET] <BtbN> Actualy had to reboot to revive any kind of graphical output
[23:49:36 CET] <BtbN> That didn't take nearly as long as I expected though.
[23:49:46 CET] <nevcairiel> i did all the hard work :(
[23:50:13 CET] <BtbN> VAAPI doesn't want nearly as many stuff as DXVA2
[23:50:56 CET] <BtbN> Not like HEVC, where it wants basicaly every single possible parameter.
[23:51:36 CET] <nevcairiel> the way dxva2 vp9 works, it could realistically not ask for a single parameter, since it gets the full buffer anyway and could parse it all from the bitstream if it wanted o
[23:52:04 CET] <BtbN> Well, isn't it the same for VAAPI?
[23:52:15 CET] <nevcairiel> i dunno
[23:52:17 CET] <nevcairiel> probably
[23:52:31 CET] <BtbN> This gets a lot more ridicoulous when it comes to Encoding
[23:52:42 CET] <BtbN> You have to pass all the parameters to VAAPI via structs
[23:53:07 CET] <BtbN> But you also have to generate the NAL bitstream, with those parameters in it, and then pass that bitstream buffer to VAAPI, so it can put it in front of the encoded data.
[23:53:24 CET] <BtbN> All that while VAAPI contains code to generate the bitstream, it just doesn't.
[23:54:19 CET] <iive> BtbN: why don't you change that in vaapi?
[23:54:37 CET] <BtbN> Because it would change the way the API works.
[23:54:53 CET] <iive> so what...
[23:54:55 CET] <cone-872> ffmpeg 03Michael Niedermayer 07master:70f13abb4f9a: avcodec/mpeg4videodec: also for empty partitioned slices
[23:55:15 CET] <BtbN> I don't think that would be accepted.
[23:55:28 CET] <iive> BtbN: you can at least ask them...
[23:55:39 CET] <BtbN> I did, multiple times.
[23:55:43 CET] <iive> i'm sure the api could be extended in a sane way.
[23:55:56 CET] <BtbN> There's no interest to do so.
[23:56:09 CET] <BtbN> It works, somehow. So they are done with it and move on.
[23:56:27 CET] <iive> BtbN: the question is more... are they opposed to it, or just that they don't want to do it themselves.
[23:56:49 CET] <BtbN> I got insulted when I asked them about that particular issue, so i guess they strongly oppose it.
[23:57:03 CET] <fritsch> who is "they"?
[23:57:16 CET] <BtbN> Some people in intel-gfx
[23:57:31 CET] <fritsch> you got a link?
[23:57:39 CET] <BtbN> That's way too long ago
[23:58:34 CET] <iive> intel developers are... meh..
[23:58:49 CET] <iive> their 2D drivers are always having same problems...
[23:59:06 CET] <iive> they haven't moved to gallium for opengl...
[23:59:14 CET] <fritsch> their 2d driver maintainer is a nice guy and helps activel solving those issues
[23:59:22 CET] <BtbN> Well, you don't just move to gallium with an existing code base.
[23:59:33 CET] <fritsch> last time I installed him a testing rig - so that he could remote reproduce and fix the problem
[23:59:45 CET] <iive> BtbN: other drivers did that...
[23:59:58 CET] <BtbN> Because they were in for a rewrite from scratch anyway
[00:00:00 CET] --- Sun Dec 20 2015