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

[burek]

[01:07:53 CEST] <cone-209> ffmpeg 03James Almer 07master:9669c05baf37: avcodec/h264_sei: add namespace prefix to frame packingarrangement enum values
[01:37:49 CEST] <atomnuker> how do subdirectories (e.g. libavcodec/x86/ or arm or aarch64) get compiled?
[01:38:41 CEST] <atomnuker> I don't see a reference to the makefile or directory in which it is in any makefile or the configure script
[01:53:18 CEST] <iive> atomnuker: ffmpeg-source/Makefile:112  looks like the thing you are looking for
[02:54:35 CEST] <cone-424> ffmpeg 03Paras Chadha 07master:6ce4a635ed19: avformat/fitsenc: fill header line with spaces
[17:51:38 CEST] <kevinn__> Does anyone here know what type of compression algorithm FFmpeg uses to stream video?
[17:52:33 CEST] <durandal_1707> kevinn__: thare are many
[17:54:28 CEST] <kevinn__> I have been trying to implement a more or less live video streaming algorithm and the numbers are just not adding up. I was on the networking IRC and they suggested I come here. Basically I want to know how exactly FFmpeg makes the raw video bits so small that it can transfer over the internet quick enough to be considered streaming quality.
[17:54:53 CEST] <kevinn__> I have exhausted nearly every compression algorithm I can find on github and none of them compress quite well enough
[17:55:11 CEST] <kevinn__> I am using UDP and I also implemented a delta algorithm where only differences in the video are sent over
[17:55:42 CEST] <kevinn__> but the size of the buffers are still easily over a mega byte (almost 2) for each render cycle on a 1080p video
[17:56:00 CEST] <kevinn__> and I just can't send that much data so quickly
[17:56:51 CEST] <kevinn__> The only other things I am considering right now is just adding some latency (which really won't work because the video is live...) or to create like a cache database on the other end with "most common buffers"
[17:57:03 CEST] <iive> we do use standard video codecs. 
[17:57:04 CEST] <kevinn__> or something along those lines, so how does FFmpeg do it?
[17:57:22 CEST] <kevinn__> what does that mean?
[17:57:28 CEST] <kevinn__> like mp4?
[17:57:53 CEST] <kevinn__> Is there a way to convert my straight char buffers to an mp4 codec?
[17:58:13 CEST] <iive> e.g. H.264 also known as AVC or iso14496-10
[17:58:57 CEST] <iive> ffmpeg uses x264 library for encoding it.
[17:59:06 CEST] <iive> it's a separate project.
[17:59:34 CEST] <kevinn__> Yes I actually saw that, but I didn't really look into it much. Is this what you are talking about? https://github.com/cisco/openh264
[18:00:09 CEST] <wm4> kevinn__: you want to look into x264 and rate control, bitrate, vbv, etc.
[18:00:56 CEST] <kevinn__> wm4: so something like this? https://github.com/mirror/x264
[18:01:00 CEST] <iive> kevinn__:  not exactly. while the cisco codec does implement h264, it implements only the smallest subset possible.
[18:01:23 CEST] <iive> kevinn__: you are however free to use it, as they cover the patents for h264.
[18:02:05 CEST] <kevinn__> @iive: okay, would you suggest I use x264 like @wm4 suggested?
[18:02:19 CEST] <iive> kevinn__: depends what your needs are
[18:02:47 CEST] <kevinn__> I'm sorry to be a hassle here, but is there anywhere I can look to see what the pros and cons are of each?
[18:02:51 CEST] <iive> kevinn__: i guess you've tried lossless compression. video and audio compression is lossy
[18:03:20 CEST] <kevinn__> oh yes it is super important that the video is lossless
[18:03:28 CEST] <kevinn__> are both of these lossy compression?
[18:03:39 CEST] <wm4> kevinn__: ffmpeg can be built with x264 support
[18:03:50 CEST] <wm4> it'll be used by default when transcoding to h264
[18:03:59 CEST] <iive> kevinn__: why do you need video to be lossless?
[18:04:02 CEST] <wm4> but on this level these are #ffmpeg questions
[18:04:13 CEST] <wm4> oh, lossless changes everything
[18:04:26 CEST] <wm4> the answer is there's probably no such algorithm
[18:04:29 CEST] <iive> x264 does have lossless mode (qp=0)
[18:05:09 CEST] <kevinn__> @iive: well take things like your own desktop. if it rendered using lossy video wouldn't it just look bad?
[18:05:20 CEST] <iive> no
[18:05:28 CEST] <kevinn__> how so?
[18:05:34 CEST] <iive> you can get good quality at reasonable bitrate
[18:06:41 CEST] <kevinn__> okay, interesting. I never considered this. So since x264 supports both lossless and lossy I think that's the direction I want to go so I can tune it. But does it work on just a vanilla frame buffer?
[18:07:01 CEST] <kevinn__> Like can I just input a framebuffer of what the screen is and it'll return to me what to send to the client?
[18:08:30 CEST] <iive> it have development API, and it can be tuned for low latency.
[18:09:20 CEST] <kevinn__> I understand that, but does it support compressing vanilla buffers?
[18:09:34 CEST] <kevinn__> and will it return a buffer for me to send to the client?
[18:09:55 CEST] <iive> it gets image buffers and returns bitstream.
[18:11:00 CEST] <kevinn__> okay, btw thank you so much for your help here. So the link I provided above. Is all the information/files I need in there? Can I do everything I want with it?
[18:11:07 CEST] <kevinn__> https://github.com/mirror/x264
[18:11:08 CEST] <kevinn__> this one
[18:11:19 CEST] <kevinn__> or is there somewhere better I can reference?
[18:12:27 CEST] <jamrial> kevinn__: https://git.videolan.org/?p=x264.git
[18:13:52 CEST] <jamrial> also, check #x264dev
[18:14:16 CEST] <kevinn__> oh thank you so much!! Is that IRC pretty active?
[19:32:23 CEST] <BBB> jamrial: fwiw, I think I agree with carl here, if nan is difficult, lets just use dbl_max or dbl_min or so (assuming that works)
[19:51:56 CEST] <jamrial> BBB: just replied to that email. I'll not opose to that solution if it's prefered, but keep in mind that NAN not being usable here is apparently against the spec
[19:52:26 CEST] <BBB> I appreciate that, just trying to be pragmatic :)
[19:53:00 CEST] <BBB> Im wary of disabling random built-in/native components depending on the exact toolchain
[19:53:28 CEST] <BBB> its a very unideal situation, obviously
[19:54:31 CEST] <BBB> https://www.gnu.org/software/gnulib/manual/html_node/math_002eh.html NAN is not a compile time constant with some compilers
[19:55:52 CEST] <BBB> googling this issue leads to quite funny discsussions on this subject
[19:57:09 CEST] <jamrial> i don't really care what solution we use. i just want to fix netbsd and djgpp which have been broken for a month
[19:57:42 CEST] <jamrial> i tried replacing NAN with nan(""), and the results were mixed. Vittorio isn't even trying to fix it himself, and people suggest other solutions but don't send patches
[19:58:20 CEST] <BBB> I dont have djgpp or netbsd installed so I cant reproduce it
[19:58:59 CEST] <jamrial> ubitux has a djgpp toolchain and michaelni has netbsd
[19:59:29 CEST] <jamrial> michaelni is who tested my nan("") patch and found out it worked in some toolchains but broke others
[20:00:42 CEST] <BBB> I think its easier if we ask koda to fix it himself
[20:00:57 CEST] <BBB> a quick look suggests negative or large values are impossible for the param
[20:01:11 CEST] <BBB> in which case either any negative or large positive (dbl_max) can be used to signal "default"
[20:01:24 CEST] <BBB> but he knows that better than me so he can verify that
[20:02:22 CEST] <BBB> and yes that may mean it stayts broken for another month :(
[20:09:56 CEST] <BBB> jamrial: anyway, I dont want to ohld anything up so if nobody has better ideas just commit it I guess
[20:37:24 CEST] <jamrial> BBB: reimar just pointed vf_zscale does the same, and Vittorio is not going to bother with it, so i'll just push my patch until someone comes up with any other solution they prefer
[20:37:34 CEST] <BBB> sure
[20:41:00 CEST] <cone-464> ffmpeg 03James Almer 07master:4d390344ec38: configure: check if NAN can be used as a constant initializer
[21:42:27 CEST] <jkqxz> durandal_1707:  No comment on kmsgrab doc I wrote for you?  :(
[21:44:03 CEST] <jamrial> kierank: can you check the mpegts opus patch on the ml?
[21:44:34 CEST] <durandal_1707> jkqxz: how can i use it?
[21:55:44 CEST] <jkqxz> By reading it?
[21:57:35 CEST] <jkqxz> More seriously, I will push that series in a bit after "make check" finishes if there is nothing else to say about it.
[22:13:06 CEST] <jamrial> jkqxz: i tested it and at least trace_headers works as intended. so do the metadata ones i presume judging by the fate tests, but those just bypass the bitstream without changing anything
[22:13:25 CEST] <jamrial> can't test the vaapi changes
[22:13:34 CEST] <jamrial> overall it's a really neat feature
[22:15:08 CEST] <jamrial> i think eventually it should be made public, or at least shared between libs, to simplify the lavf hvcc parsing code
[22:15:20 CEST] <jkqxz> You can feed metadata straight into trace_headers to examine the result.
[22:15:56 CEST] <jkqxz> Being public locks down a huge amount of API.  I don't really want that.
[22:18:21 CEST] <jamrial> btw, that (or those) hevc mkv files with non spec complaint VUI apparently were made with divx's hevc encoder, and a mkvtoolnix version with early support for hevc
[22:18:39 CEST] <JEEB> oh, those files
[22:18:41 CEST] <jamrial> the extradata is not even hvcc, it's annexb. trace_headers bails out with it
[22:19:42 CEST] <jamrial> so they are not hevc or even matroska compliant :p
[22:22:00 CEST] <jkqxz> It should work on annexb extradata?  Though yeah, it will reject the VUI error.
[22:22:43 CEST] <cone-464> ffmpeg 03James Almer 07master:7bae17e37ab6: avcodec/extract_extradata: return an error when buffer allocation fails
[22:24:07 CEST] <jamrial> jkqxz: ff_h2645_packet_split (called by the filter) failed when checking the extradata, i think
[22:25:19 CEST] <jkqxz> Let me find the file and try.
[22:26:17 CEST] <jamrial> jkqxz: https://trac.ffmpeg.org/ticket/6644 firt attachment
[22:27:38 CEST] <cone-464> ffmpeg 03James Almer 07release/3.3:9f7042f9cd0f: avcodec/extract_extradata: return an error when buffer allocation fails
[22:31:26 CEST] <jkqxz> Er, what?  {0x0, 0x1, 0x60, 0x0, 0x0, 0x0, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x78, 0xf0, 0x0, 0xfc, 0xfd, 0xf8, 0xf8, 0x0, 0x0, 0x47, 0x3, 0x20, 0x0, 0x1, 0x0, 0x18, 0x40, 0x1, 0xc, 0x1}
[22:31:30 CEST] <jkqxz> This is not a thing.
[22:32:12 CEST] <jamrial> it is a non compliant file alright :p
[22:38:27 CEST] <jkqxz> I think it kindof works as HVCC if you ignore the first zero and then assume that the array count is missing as well.
[22:39:51 CEST] <jkqxz> So the 3 is the at position 22 is the NAL length byte, the 0x20 is SPS, 1 of the, 24 bytes long, etc.
[22:41:13 CEST] <jkqxz> ... why am I looking at this.  File sucks, delete it.
[22:41:25 CEST] <jamrial> haha
[23:33:02 CEST] <jkqxz> Heh.  kmsgrab -> vaapi encode runs fine at 60fps /in valgrind/.  Offload ftw!
[23:33:37 CEST] <atomnuker> make check completed?
[23:34:29 CEST] <jkqxz> A while ago, just making sure I haven't screwed something else up.
[23:37:53 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:9cb23cd9fe58: lavu: Add DRM hwcontext
[23:37:54 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:170c65335caa: hwcontext_vaapi: Add DRM to VAAPI mapping
[23:37:55 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:82342cead15b: lavc: Add flag to mark packets containing trusted input
[23:37:56 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:c8dea8192150: lavc: Add wrapped_avframe decoder
[23:37:57 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:52194f0bcb2b: lavd: Add KMS screen grabber
[23:37:58 CEST] <cone-464> ffmpeg 03Mark Thompson 07master:ec1573f879b1: doc/indevs: Document kmsgrab input device
[23:38:30 CEST] <thebombzen> oh man kmsgrab naisu
[23:49:03 CEST] <jamrial> jkqxz: new modules (de/encoders, de/muxers, in/outdevs, etc) bump minor, not micro
[23:52:43 CEST] <jkqxz> Huh.  I thought it was external API for minor, internal but with external effects for micro.
[23:53:27 CEST] <thebombzen> jkqxz: how does one compile in kmsgrab? I don't see --enable-kmsgrab in configure
[23:54:52 CEST] <jkqxz> You need --enable-libdrm, then it's an indev.
[23:55:41 CEST] <thebombzen> ah, okay
[23:56:56 CEST] <thebombzen> hm, I wonder if I can use nvenc with kmsgrab without hwdownloading
[23:57:02 CEST] <jkqxz> jamrial:  Docs seem to agree with me.  Maybe send a patch to update that if it's meant to be the policy?
[23:57:31 CEST] <nevcairiel> thebombzen: not unless someone invents drm to cuvid mapping
[23:57:35 CEST] <jkqxz> (I don't mind at all, but it should be clear.)
[23:57:57 CEST] <thebombzen> ah okay, "it could work, patches welcome"
[23:58:09 CEST] <nevcairiel> its unclear if it could work :)
[23:58:18 CEST] <nevcairiel> unless someone tries to make it work..
[23:58:23 CEST] <nevcairiel> hardware can be annoying with this stuff
[23:58:54 CEST] <jkqxz> I've no idea if it will even work at all on nvidia.  Even if it does, it might well have crazy tiling or just not be downloadable directly without assistance from some other API.
[23:59:32 CEST] <jamrial> jkqxz: where in the docs? in any case, it's what i've seen done all the time. just look at lavc/lavf/lavfi version.h history
[23:59:42 CEST] <jamrial> not that it matters much as long as something is bumped anyway
[00:00:00 CEST] --- Thu Sep 14 2017