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

Thu Feb 8 03:05:04 EET 2018

[00:14:04 CET] <cone-205> ffmpeg 03James Almer 07master:8885a29e5dc8: avformat/Makefile: fix fifo and fifo_test muxer build objects
[01:20:13 CET] <Compn> wow
[01:20:20 CET] <Compn> http://blog.chiariglione.org/wp-content/uploads/2018/01/HEVC.jpg
[01:20:23 CET] <Compn> nightmare fuel
[01:32:37 CET] <philipl> Compn: The blog post is amusing. The end of innovation!
[01:34:08 CET] <Compn> philipl : its very amusing.
[01:34:25 CET] <Compn> too bad no ffmpeg mentions :(
[01:36:08 CET] <Compn> his graph at the end seems BS too
[01:36:21 CET] <Compn> vcds were 4x smaller than mpeg2 :P
[01:36:24 CET] <Compn> dvds that is
[01:36:26 CET] Action: Compn runs
[01:36:45 CET] <philipl> heh
[01:37:59 CET] <philipl> jya: Well, I got it working after much tediousness. The problem was that the NVImage code assumes the data it's given is contiguous, which in this case it's not. The two planes are separate allocations. After fixing that assumption, it worked. But of course, it ends up being higher CPU consumption than software for vp9. Hah.
[01:38:44 CET] <philipl> I suspect because it's doing the NV12->I420 conversion/copy
[01:39:07 CET] <philipl> So there's a one copy penalty and then it's a non-trivial copy on top of that.
[01:39:33 CET] <philipl> Might be doing two extra copies for all I know. There's a copy when creating an NVImage and then another on the way out
[01:45:08 CET] <philipl> jya: could move it to doing the conversion immediately in SetData to elide a copy. Of course, at that point NVImage isn't really an NVImage, but just a regular image that knows how to convert NV12 when being initialised.
[02:13:33 CET] <BBB> Compn: the blog post is about standardization and monetization thereof through the patent process
[02:13:45 CET] <BBB> Compn: it doesnt really intersect with ffmpeg in any way
[02:14:19 CET] <BBB> Compn: (well, and how aom broke it)
[02:14:50 CET] <Compn> it dances around the issue of open source and open video coding
[02:17:21 CET] <BBB> open video is aom
[02:17:32 CET] <BBB> open source is orthogonal to mpegla/aom
[02:18:00 CET] <BBB> the iso process is open source, and mpegla doesnt care as long as you pay them somehow
[02:18:13 CET] <Compn> fair enough
[02:18:30 CET] <BBB> to say that ffmpeg has to be mentioned is kind of like insisting that shell is mentioned when we talk about oil
[02:18:35 CET] <BBB> :-p
[02:20:47 CET] <Compn> i like it when ffmpeg is mentioned :P
[02:22:07 CET] <BBB> me too ;)
[02:22:36 CET] <BBB> Ill write a blog post sometime soon and be sure to mention ffmpeg
[02:22:40 CET] <c3r1c3-Win> Well it doesn't hurt to mention Shell... or Carl's Jr.
[02:23:15 CET] <Compn> cia using ffmpeg in secret spy tool heh
[02:23:47 CET] Action: Compn reading old news
[02:26:31 CET] <BBB> I guess everyone uses ffmpeg somehow?
[02:26:35 CET] <BBB> its quite widespread nowadays
[02:31:39 CET] <Chloe> Pretty sure everyone uses ffmpeg
[02:32:20 CET] <Chloe> If they use chrome, Firefox, Kodi or VLC (which I would assume covers the majority)
[02:40:07 CET] <klaxa> even if not directly then indirectly
[02:54:19 CET] <philipl> jya: whelp. I got rid of the extra copy and still clearly using more CPU than software :-)
[02:54:33 CET] <philipl> Of course, the pixel format conversion is still happening
[02:59:30 CET] <SortaCore> that yuvj stuff is tripping me up
[02:59:48 CET] <SortaCore> is it equivlaent to setting color_range to jpeg and switching to yuv equivalent?
[03:00:26 CET] <SortaCore> out of all the codecs only libx264 is accepting yuvj420p
[03:00:42 CET] <SortaCore> (h264_qsv, h264_nvenc, libopenh264 all reject)
[03:12:18 CET] <cone-205> ffmpeg 03James Almer 07master:f7aacf4ab765: avformat/mov: add VP8 codec support
[03:44:01 CET] <cone-205> ffmpeg 03James Almer 07master:36c85d6e773d: api: add missing version bumps and APIChanges entries
[03:49:31 CET] <cone-205> ffmpeg 03James Almer 07master:e8323c42c19f: doc/APIChanges: fix lavu version numbers in a few recent entries
[04:31:26 CET] <cone-205> ffmpeg 03James Almer 07master:8318bf175135: avformat/fifo_test: remove network.h include
[07:32:12 CET] <rcombs> tmm1: *poke*
[08:57:25 CET] <jya> philipl: our shaders still need rgb, so there's a conversion happening.. 
[08:57:51 CET] <jya> but I had similar result in the past (though with vaapi), I only spent a couple of hours on it and didn't investigate much
[08:58:14 CET] <jya> without opengl being the default rendering engine on linux, there wasn't much point anyway... 
[08:58:25 CET] <jya> linux uses the basic rgb compositor, it's awful
[09:45:30 CET] <slasktrat> Hi. I've updated an one year old, unclosed ticket (http://trac.ffmpeg.org/ticket/6165) do I need to send a notification somewhere?
[09:46:12 CET] <slasktrat> Uploaded sample and should make it very easy to reproduce
[09:57:19 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #104: [WIP] Metadata (06master...06Metadata) 02https://git.io/vAfOw
[10:25:50 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #105: JPEG2000-RCT exception clarification (06master...06Background) 02https://git.io/vAfsG
[11:00:28 CET] <Chloe> wm4: any idea how I should conditionally include fifo_test? I think marton suggested a configure flag but wouldnt this then require a custom flag just to test fate
[11:18:05 CET] <Chloe> Also I guess I should be deprecating .next within the components after the lavfi patch
[11:38:58 CET] <wm4> Chloe: hm no idea, that's nasty
[11:40:16 CET] <jkqxz> The next links aren't user-visible, just delete them immediately.  There's no reason for them to continue to exist.
[11:47:21 CET] <atomnuker> jkqxz: can you check out http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/224942.html
[11:51:28 CET] <jkqxz> I replied to that five minutes ago.
[11:51:34 CET] <jkqxz> How did you even generate the files there?
[11:53:01 CET] <nevcairiel> maybe he did an in-tree build
[11:58:16 CET] <jkqxz> Oh, huh.  That is possible, isn't it.
[12:03:55 CET] <Chloe> jkqxz: ok, well I cant remove them until FF_API_NEXT is removed, cause the compat code needs it still
[12:05:05 CET] <jkqxz> Isn't it easily rewritten to not use them?
[12:05:26 CET] <jkqxz> Still, even if they stay you don't need to do anything now because they aren't user-visible.
[12:26:21 CET] <cone-875> ffmpeg 03Rostislav Pehlivanov 07master:33d632d40e14: lavfi: add a gitignore file for OpenCL compiled kernels
[12:33:07 CET] <wm4> libswresample/soxr_resample.c:46: undefined reference to `soxr_io_spec'
[12:33:15 CET] <wm4> why does linking so suxsr fail now
[12:35:41 CET] <wm4> and only when running fate
[12:35:57 CET] <wm4> when building tests/checkasm/checkasm
[12:36:01 CET] Action: wm4 just disable suxsr
[12:42:53 CET] <cone-875> ffmpeg 03Richard Shaffer 07master:651d5f963921: avformat/hls: Support metadata updates from subdemuxers
[13:43:19 CET] <Chloe> is anyone able to look at/push '[PATCH] cmdutils: fix finding next codec for id'? Currently `-codecs` is broken in master.
[13:47:20 CET] <JEEB> I will take a look at if if no-one else does when I finish work
[17:12:57 CET] <philipl> jya: ah well
[17:13:06 CET] <philipl> BtbN: so yeah, it really doesn't help today.
[17:15:07 CET] <jya> philipl: have you looked at a profile to see where the time is spent?
[17:15:27 CET] <jya> firefox has a built-in profiler now.. that will help
[17:16:29 CET] <jya> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler 
[17:16:52 CET] <jya> it's quite easy, there's an extension you need to install, and from there it's pretty much self-explanatory
[17:16:54 CET] <philipl> jya: I haven't, but given how isolated the change is, there's only things going on that weren't there before - the copy back to system memory and then the NV12->I420 conversion.
[17:17:03 CET] <jya> if you start with e10s disabled, that helps too
[17:17:12 CET] <jya> cause profiling across multiprocess is a pain
[17:17:53 CET] <jya> nv12->i420 shouldn't take much time... there's a libyuv function to do that that is SSE accelerated
[17:18:01 CET] <jya> oh, did you enable GL rendering?
[17:18:06 CET] <philipl> I didn't.
[17:18:27 CET] <JEEB> also there's libp2p which I think had some SIMD as well for various packing types
[17:18:30 CET] <jya> you need to, otherwise there's so much time spent in the compositor it's hard for anything else to be of relevance
[17:18:35 CET] <philipl> ah
[17:18:42 CET] <JEEB> https://github.com/sekrit-twc/libp2p
[17:18:50 CET] <nevcairiel> If you wanted to truely optimize things, you could do the conversion during the readback, that comes practically for free then, but of course  you need custom readback then =p
[17:18:59 CET] <jya> JEEB: libyuv is in firefox tree, trying to keep the changes small
[17:18:59 CET] <JEEB> :)
[17:19:03 CET] <JEEB> jya: right
[17:19:05 CET] <philipl> JEEB: the thing firefox uses has avx2. Seems up to date.
[17:19:10 CET] <JEEB> alright
[17:19:40 CET] <philipl> nevcairiel: Yeah. I elided one copy that way but that was on the system side already
[17:19:54 CET] <philipl> The original code path was read-back -> copy -> copy -> convert -> copy
[17:19:59 CET] <jya> philipl: in about:config , set layers.acceleration.force-enabled to true
[17:20:00 CET] <jya> restart
[17:20:28 CET] <jya> philipl: indeed, we already copy the content coming out from ffmpeg
[17:20:48 CET] <nevcairiel> that seems something worthy of getting rid of
[17:20:53 CET] <jya> with out of process compositing, it becomes almost impossible to refcount those memory blob
[17:21:20 CET] <atomnuker> JEEB: stop trying to flog that thing, its useless
[17:21:34 CET] <JEEB> atomnuker: ok, if it's useless then it's useless
[17:21:55 CET] <jya> on windows and mac we do reduce the amount of copy, what we do is directly upload the yuv buffer into either an IOSurface (mac) or a IMF image (windows)
[17:21:58 CET] <JEEB> it seemed to have some SIMD and since zimg wasn't completely useless I thought that would be similar :P
[17:22:27 CET] <atomnuker> well it turns out we have some simd too
[17:22:39 CET] <JEEB> yea but then why does nevcairiel write his own SIMD?
[17:22:46 CET] <JEEB> (´4@)
[17:22:54 CET] <nevcairiel> because sws is the spawn of the devil
[17:22:59 CET] <atomnuker> and I'll believe something is faster than c:v v210  when I see it
[17:23:15 CET] <JEEB> yea but we're dealing with NV12 here
[17:23:17 CET] <JEEB> not V210
[17:23:20 CET] <nevcairiel> noone wants v210 anyway
[17:23:30 CET] <JEEB> other than broadcasters
[17:23:45 CET] <JEEB> hw packing formats ahoy
[17:40:30 CET] <philipl> jya: even with GL compositing turned on, it's still easy to see CPU is lower with software. I also can't get the profiler to show any of the ffmpeg/nvimage calls
[17:42:35 CET] <atomnuker> philipl: did firefox really do that many copies per frame?
[17:43:00 CET] <philipl> atomnuker: It does a lot.
[17:44:52 CET] <philipl> AVFrame -> copied to Image -> converted to I420 -> converted to RGB and then who knows how many times after that
[17:46:40 CET] <philipl> I combined the first copy and the I420 conversion but CPU is stil noticeably higher than software
[18:42:26 CET] <jya> philipl: shouldn't be more than 2 copies.
[18:42:46 CET] <jya> one copy from FFmpeg AVFrame to create an Image
[18:42:58 CET] <jya> and the copy from Image to the OpenGL surface
[19:40:57 CET] <feliwir> i just got a warning: "avcodec_copy_context is obsolet"
[19:41:08 CET] <feliwir> do i not need to copy the codec_ctx anymore?
[19:42:03 CET] <nevcairiel> there is no good reason to ever copy a context
[19:44:00 CET] <feliwir> nevcairiel, http://dranger.com/ffmpeg/tutorial01.html
[19:44:08 CET] <feliwir> "Note that we must not use the AVCodecContext from the video stream directly! So we have to use avcodec_copy_context() to copy the context to a new location (after allocating memory for it, of course). "
[19:44:21 CET] <nevcairiel> those guides are probably a decade old by now, if not more
[19:44:29 CET] <feliwir> updated in 2015
[19:44:33 CET] <feliwir> it says that on the first page
[19:44:53 CET] <feliwir> so i can use the original context without worries for decoding?
[19:44:59 CET] <nevcairiel> no.
[19:45:07 CET] <feliwir> uhm?
[19:45:25 CET] <nevcairiel> there is no original context anymore (well there is, but its deprecated)
[19:45:30 CET] <feliwir> didn't you just say that there isn't a good reason to copy a context
[19:45:40 CET] <nevcairiel> there is more options then copying a context
[19:45:44 CET] <nevcairiel> you could create a new one =p
[19:45:56 CET] <nevcairiel> you should read the official examples
[19:46:23 CET] <wm4> avcodec_copy_context() should not be used
[19:46:26 CET] <wm4> it's pretty broken
[19:46:57 CET] <feliwir> nevcairiel, where can i find the official "small examples". And please don't link me to ffplay :D
[19:47:13 CET] <wm4> ah I see it's properly deprecated
[19:47:20 CET] <wm4> so at least that warns the user
[19:47:31 CET] <wm4> feliwir: there are none, all examples are either non-official, or broken, or both
[19:47:42 CET] <feliwir> https://github.com/feliwir/arda/blob/master/src/video/video.cpp#L145 i guess those parts are pretty wrong then? It always used to work, but i want to use the correct way
[19:47:51 CET] <feliwir> wm4, guessed so tbh 
[19:48:01 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/demuxing_decoding.c;h=b1a216abb4cb72f448b4fe215d0ab3692be72a1e;hb=HEAD should be mostly ok
[19:48:35 CET] <nevcairiel> well it still uses the old decode api, but at least not the old context =p
[19:49:11 CET] <feliwir> i already use the new decode api in the link above
[19:49:21 CET] <feliwir> i guess i must just use avcodec_parameters_to_context instead of context copy
[19:51:34 CET] <feliwir> lol, the parameter order was changed for avcodec_parameters_to_context
[19:51:48 CET] <feliwir> the vlc example has it the wrong way round
[19:52:29 CET] <wm4> I doubt that ever happened
[19:55:19 CET] <feliwir> that's my signature: "int avcodec_parameters_from_context(AVCodecParameters* par, AVCodecContext* codec)"
[19:55:38 CET] <feliwir> this is the VLC usage: "avcodec_parameters_to_context(*dec_ctx, st->codecpar))"
[19:55:41 CET] <nevcairiel> thats from, not  to
[19:55:52 CET] <nevcairiel> it always goes (destination, source)
[19:55:56 CET] <feliwir> what a bummer -.-
[19:56:18 CET] <feliwir> my bad :D
[20:14:42 CET] <uartie> av_register_all just got deprecated... is there an example on how to change user code to new api?
[20:15:21 CET] <uartie> documentation seems to still use av_register_all
[20:17:24 CET] <jkqxz> Just don't call it.
[20:17:44 CET] <uartie> thanks
[20:42:27 CET] <Chloe> Guess I should update the docs too huh.
[20:43:07 CET] <cone-875> ffmpeg 03James Almer 07master:cf666651b499: avformat: fix stream_segment muxer build dependencies
[20:45:03 CET] <jkqxz> I just sent a patch to remove the (non-lavfi) register functions from the examples.
[20:45:18 CET] <Chloe> jkqxz: can you take a look at `cmdutils: fix finding next codec for id`?
[20:45:29 CET] <jkqxz> Sure.
[20:46:32 CET] <Chloe> `-codecs` in ffmpeg is currently broken, this is a fix for that (most of the cmdutils code should probably be rewritten, but I'd rather put out a quick fix for something which is actually broken than leave it too long)
[20:46:48 CET] <jkqxz> Right, it currently ends up in a loop.
[20:46:52 CET] <Chloe> yes
[20:47:31 CET] <Chloe> if you could push it too (if you think it's ok), that'd be nice. 
[20:50:06 CET] <jkqxz> It doesn't work.
[20:50:16 CET] <jkqxz> That strcmp() isn't doing the right thing.
[20:50:47 CET] <Chloe> it's not?
[20:50:48 CET] <jkqxz> I think you need to check for the thing after prev in iteration order?  That is, find prev, then find the next one.
[20:51:50 CET] <jkqxz> " DEV.LS h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_v4l2m2m ) (encoders: libx264 libx264rgb nvenc nvenc_h264 )"
[20:51:55 CET] <jkqxz> I have more H.264 encoders than that.
[20:52:34 CET] <jkqxz> The list is not in strcmp() order, so once you've found one you only look for ones after it in the alphabet.
[20:53:15 CET] <jkqxz> Hence you find libx264, then skip over all the h264_foo (amf, vaapi, v4l2m2m) because they're < "l", then find the deprecated nvenc names because they are > "l".
[20:58:48 CET] <cone-875> ffmpeg 03James Almer 07master:9d8fb095e6f8: doc/APIchanges: fix a recent depreacted function name
[21:06:42 CET] <cone-875> ffmpeg 03James Almer 07master:3f0a41367eb9: doc/APIchanges: mention a few more recently introduced and deprecated functions
[21:31:00 CET] <rcombs> tmm1: ping
[21:59:22 CET] <Chloe> jkqxz: https://0x0.st/scjy.patch how does this look
[22:08:45 CET] <Chloe> mmh, i dont know how reply-to works in my client, I set the header but it didnt seem to work
[00:00:00 CET] --- Thu Feb  8 2018