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

[burek]

[00:02:50 CET] <rcombs> atomnuker: is copy still an actual copy (vs just a passthrough)?
[00:03:46 CET] <jamrial> michaelni: do i merge 8965e2af92 or noop it?
[00:03:54 CET] <jamrial> we're zeroing the whole buffer rather than the padding after a commit of yours
[00:04:04 CET] <atomnuker> rcombs: its "create an image, copy input image to new image, output new image" thing which is meant to also detile images, so its an actual gpu copy
[00:04:30 CET] <jamrial> zeroing the padding only may be slightly faster with big packets
[00:05:32 CET] <atomnuker> also my old mpv vo_vulkan code works well, thank you very much, it passes validation layers, its nvidia's drivers which made people's systems crash
[00:05:33 CET] <rcombs> interesting
[00:08:25 CET] <Compn> wm4 : some people in #videolan were having trouble with hdr playback, i told them to try mpv , and mpv worked where vlc crashed. so congrats, you beat vlc :) (this was on win10 btw)
[00:09:06 CET] <Compn> source was 4k h265 satellite stream 
[00:10:22 CET] <atomnuker> how do people with nvidia live with the inconvenience of having malfunctioning but fast graphics? everywhere I'm seeing tearing, in whatever API is used, its horrible
[00:10:47 CET] <Compn> atomnuker : what desktop environment are you using ?
[00:10:53 CET] <Compn> any compositing ?
[00:11:14 CET] <BtbN> On my Laptop I have Intel. It's malfunctioning and dirt slow.
[00:11:14 CET] <Compn> that was known to cause tearing in the past
[00:11:44 CET] <Compn> yea the choice is nvidia or amd still i think
[00:12:16 CET] <BtbN> AMD is in an even more sorry state in terms of video hwaccel right now
[00:14:57 CET] <jamrial> amd is slow. like 80fps decoding a 1080p h264 stream
[00:15:41 CET] <Compn> atomnuker : which card manf do you prefer?
[00:15:44 CET] <jamrial> with ffmpeg -hwaccel dxva2 or d3d11va
[00:15:46 CET] <jkqxz> AMD playback with VAAPI is perfect with Mesa 18.1 *, libva 2.1 * and mpv 0.28!
[00:15:56 CET] <jkqxz> (* Not yet released.)
[00:16:50 CET] <jkqxz> And it could have been trivially fixed ages ago if anyone at AMD actually cared.  Hmph.
[00:17:25 CET] <c3r1c3-Win> jkqxz: Is your name really Xaymar? ;-)
[00:18:05 CET] <Compn> if nvidia really cared they could fix their contracts and release whatever video card specs and api secrets so people could actually write code without guessing ...
[00:18:10 CET] <jkqxz> ?  No.
[00:18:48 CET] <atomnuker> Compn: AMD, always have had dedicated AMD/Ati cards except for a Riva TNT2
[00:18:50 CET] <c3r1c3-Win> jkqxz: I ask because that's almost verbatim what Xaymar (creator of the OBS AMF encoder) says.
[00:20:11 CET] <jkqxz> Well, that actually required AMD to do most of it because that stuff is all proprietary.
[00:20:48 CET] <jkqxz> But yes, AMD spent a long time doing nothing useful with video stuff.
[00:21:07 CET] <wm4> jkqxz: sad if they don't care... I thought it was Intel/libva who didn't
[00:21:19 CET] <atomnuker> I remember buying an 4870 in 2009, what a machine that was, needed 2 6-pin external power connectors and ripped through stalker clear sky at 1280x1024 with 60fps
[00:21:26 CET] <wm4> also death to vdpau
[00:21:34 CET] <j-b> jkqxz: that's a good news.
[00:21:52 CET] <jkqxz> There was some vague moaning about VAAPI but as far as I can tell they never actually talked to libva people to fix it at all.
[00:22:25 CET] <wm4> that mesa/libva thing would probably make it instantly work with kodi and vlc too
[00:23:13 CET] <jkqxz> Kodi are already implementing it, at least.
[00:23:13 CET] <BtbN> Kinda sad that the worst of all APIs seems to have won
[00:23:57 CET] <wm4> vdpau could have been salvaged
[00:24:23 CET] <BtbN> vdpau is not in any kind of broken state. They just stopped developing new stuff
[00:25:09 CET] <wm4> because everyone stopped caring about it
[00:26:16 CET] <BtbN> because vaapi is easier to work with for drivers devs
[00:26:21 CET] <BtbN> but a nightmare for non driver devs
[00:27:50 CET] <cone-428> ffmpeg 03Muhammad Faiz 07master:b7d476b1384f: fate/libavcodec: add codec_desc test
[00:33:21 CET] <jkqxz> That's basicallly true of all hardware video APIs, though.  If there is exactly one implementation then maybe you can puzzle through it because the authors will have done the right thing for that hardware, but once there is more than one you just need the source code because they all end up doing subtly different things in stupid ways.
[00:36:06 CET] <jkqxz> Well, with the alternative that you have an API made by a non-hardware third-party (*cough* microsoft *cough*), who then force the hardware vendors to act at least slightly consistently in implementing it.
[01:56:21 CET] <michaelni> jamrial, i would tend to suggest to leave it as it is unless there is some advantage like speed.
[02:18:06 CET] <cone-428> ffmpeg 03Muhammad Faiz 07n3.4.2:HEAD: fate/libavcodec: add codec_desc test
[02:42:53 CET] <jamrial> michaelni: it'll leave it as is then
[02:46:23 CET] <cone-428> ffmpeg 03Zhong Li 07master:6829a079444e: qsvdec: Relax the surface vs coded dimension check
[02:46:24 CET] <cone-428> ffmpeg 03James Almer 07master:87faeb1e685e: Merge commit '6829a079444e10818a847e153121fb458cc5c0a8'
[02:48:12 CET] <cone-428> ffmpeg 03Sean McGovern 07master:5085f25ace1e: vc1: skip motion compensation when data for last picture is invalid
[02:48:13 CET] <cone-428> ffmpeg 03Martin Storsjö 07master:8965e2af921e: avpacket: Initialize the allocated padding area in side data
[02:48:14 CET] <cone-428> ffmpeg 03James Almer 07master:d0f098a5e0ba: Merge commit '5085f25ace1e74846a0de3369bedd0e22d1a1bdc'
[02:48:15 CET] <cone-428> ffmpeg 03James Almer 07master:6c59f05c74d8: Merge commit '8965e2af921ec5926b26d5ae466ee4104bb5262b'
[02:55:05 CET] <cone-428> ffmpeg 03Jun Zhao 07master:96e476cc9d41: hwcontext: Fix documentation for av_hwdevice_ctx_alloc()
[02:55:06 CET] <cone-428> ffmpeg 03Mark Thompson 07master:2eb396b175e5: hwcontext: Fix memory leak on derived frame allocation failure
[02:55:07 CET] <cone-428> ffmpeg 03James Almer 07master:cb2205863b95: Merge commit '96e476cc9d414e248692c773d9dce736662572b8'
[02:55:08 CET] <cone-428> ffmpeg 03James Almer 07master:0a320f7e7a9b: Merge commit '2eb396b175e55e515aa6a13c5b1789a2a18d3935'
[03:02:29 CET] <cone-428> ffmpeg 03Diego Biurrun 07master:bca41545b371: configure: Group code that sets the license string with licensing checks
[03:02:30 CET] <cone-428> ffmpeg 03James Almer 07master:8a15ad8a175c: Merge commit 'bca41545b371efc34e38d1fa8bb12dba8b614da0'
[03:09:42 CET] <cone-428> ffmpeg 03Diego Biurrun 07master:4cf84e254ae7: Drop some unnecessary config.h #includes
[03:09:43 CET] <cone-428> ffmpeg 03James Almer 07master:35347e7e9b27: Merge commit '4cf84e254ae75b524e1cacae499a97d7cc9e5906'
[03:15:47 CET] <cone-428> ffmpeg 03Diego Biurrun 07master:38434a9ff5b9: configure: Simplify restrict keyword handling
[03:15:48 CET] <cone-428> ffmpeg 03James Almer 07master:c1c720d5279a: Merge commit '38434a9ff5b9a1a048f32c1c7e2a9519cf12f8ba'
[03:20:32 CET] <cone-428> ffmpeg 03Diego Biurrun 07master:fd36cf6bf652: configure: Factorize check_64_bit()
[03:20:33 CET] <cone-428> ffmpeg 03James Almer 07master:4961ddfd3563: Merge commit 'fd36cf6bf6524247a8ff6788c028836fe7d9fd20'
[03:23:47 CET] <jamrial> jkqxz: cleared the merge backlog up to right before your recent push
[11:50:49 CET] <cone-204> ffmpeg 03Rostislav Pehlivanov 07master:50945482a75c: h264_idct: enable unmacro on newer NASM versions
[15:24:59 CET] <KGB> [13FFV1] 15dericed opened pull request #106: grammar/wording updates (06master...06sentence-fix) 02https://git.io/vAmlO
[15:28:47 CET] <KGB> [13FFV1] 15dericed opened pull request #107: bump to version 02/00 (06master...06version-bump) 02https://git.io/vAml7
[15:30:53 CET] <cone-204> ffmpeg 03James Almer 07master:192ea5bb77a7: avformat/Makefile: use individual dependencies for librtmp protocols
[19:20:26 CET] <atomnuker> good news! ffmpeg got accepted for gsoc - https://summerofcode.withgoogle.com/organizations/5270265626361856/
[19:21:28 CET] <JEEB> btw, one qual. task idea: converting mpegvideo parser to get_bits
[19:21:36 CET] <JEEB> dull but useful
[19:21:50 CET] <nevcairiel> useful for?
[19:22:13 CET] <durandal_1707> atomnuker: sad
[19:23:00 CET] <JEEB> nevcairiel: with the short looks I had the bit-banging isn't too readable at parts
[19:28:55 CET] <durandal_1707> im still waiting for vulkan
[19:46:27 CET] <durandal_1707> and atrac9
[19:46:38 CET] <durandal_1707> and adenoise
[19:46:57 CET] <durandal_1707> and godot
[19:50:50 CET] <atomnuker> godot?
[19:52:12 CET] <durandal_1707> have you read it? its book
[19:52:24 CET] <atomnuker> wasn't that the game engine which screamed at libogg for doing per-frame allocations (which it didn't really) so they decided not to support opus
[20:06:06 CET] <TD-Linux> yes, I recall they had some very optimistic views on what "real time" meant on pc hardware
[20:14:17 CET] <atomnuker> durandal_1707: btw got a gpu with vulkan support?
[20:14:40 CET] <durandal_1707> atomnuker: broadwell?
[20:15:01 CET] <durandal_1707> intel integrated gpu
[20:15:20 CET] <atomnuker> yeah, you've got vulkan
[21:09:09 CET] <feliwir> hm, Does anyone have contact with Aurelian Jacoubs? I didn't get an answer for my mail to him
[21:09:48 CET] <feliwir> also how do i disable libconv,zlib and and libwinpthreads for the Mingw build on windows? I only have 5 codecs enabled which all don't need any of these
[21:10:52 CET] <JEEB> --disable-autodetect is useful
[21:11:05 CET] <JEEB> it will keep threading enabled, but it shouldn
[21:11:11 CET] <JEEB> n't utilize any pthreads lib
[21:11:18 CET] <JEEB> but rather windows threading APIs
[21:13:49 CET] <jkqxz> JEEB:  <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cbs_mpeg2_syntax_template.c;h=90dde26aedc7a26fe3e04b42c7087146705ec1ab;hb=HEAD#l184>.  Better?
[21:14:29 CET] <JEEB> lookin' good. I remember you coding that stuff
[21:14:55 CET] <jkqxz> (Though I guess you were thinking of something between that and the current code.)
[21:15:24 CET] <JEEB> I just happened to look at the parser the other day as some patches were posted :)
[21:15:50 CET] <JEEB> https://github.com/jeeb/ffmpeg/commit/7a1f36707558277ea393049ce4d992d0e531f003 etc
[21:19:30 CET] <feliwir> thanks JEEB. Will that also disable zlib/libiconv?
[21:19:36 CET] <JEEB> yes
[21:19:55 CET] <JEEB> I specifically enable zlib in my builds
[21:20:20 CET] <feliwir> Is there any benefit of having zlib?
[21:20:26 CET] <feliwir> (when just having a tiny ffmpeg)
[21:20:27 CET] <JEEB> PNG encoder, for example
[21:20:43 CET] <JEEB> I don't remember anything else right out of the gates
[21:21:04 CET] <feliwir> i don't have png enabled
[21:21:40 CET] <JEEB> basically, if something you try to enable requires zlib it will most likely honk at you
[21:21:53 CET] <JEEB> anyways, disable-autodetect is IMHO a generally good baseline
[21:27:44 CET] <feliwir> JEEB, it still wants libwinpthread
[21:28:58 CET] <JEEB> then your mingw toolchain is dumb
[21:29:10 CET] <JEEB> since FFmpeg itself uses winthreads
[21:29:14 CET] <JEEB> not winpthreads
[21:30:05 CET] <feliwir> it's msys2
[21:30:44 CET] <JEEB> anyways, see if you can see both a winpthreads.a and a .dll.a in your toolchain
[21:30:47 CET] <JEEB> if you have both
[21:30:55 CET] <JEEB> move the .dll.a somewhere else
[21:31:03 CET] <JEEB> that way the toolchain will not be able to link it shared
[21:31:19 CET] <JEEB> because you're going to have the dependency in any case, but that way it's at least static :P
[21:31:30 CET] <RiCON> --enable-w32threads is already default, unless --disable-autodetect disables it
[21:31:38 CET] <JEEB> it doesn't
[21:31:56 CET] <JEEB> it's probably just the toolchain's compiler always linking against pthreads
[21:32:00 CET] <JEEB> for C11 threads
[21:32:14 CET] <JEEB> which is a dep you can't remove, but you can make it static at least
[21:33:30 CET] <RiCON> maybe he's using -mthreads
[21:34:16 CET] <RiCON> hm no, probably unrelated
[21:39:55 CET] <nevcairiel> i've never seen ffmpeg link to that library unless you specificall use --enable-pthreads
[21:41:05 CET] <JEEB> it's most likely just his compiler with C11 support and shared lib available
[21:41:10 CET] <JEEB> *C11 threads
[21:45:39 CET] <jamrial> feliwir: if you're using msys2's gcc package, then afaik you can't avoid having winpthreads linked, even if you use w32threads for ffmpeg
[21:45:53 CET] <jamrial> you'll have to use another toolchain
[21:48:04 CET] <jamrial> try nevcairiel's from https://files.1f0.de/mingw/
[21:53:45 CET] <feliwir> jamrial, well one library is okay i guess
[21:55:00 CET] <RiCON> mingw gcc should work fine too, only libvmaf and libzvbi require pthreads afaik
[22:17:06 CET] <cone-037> ffmpeg 03Richard Shaffer 07master:e023334661e6: libavformat/aac: Parse ID3 tags between ADTS frames.
[22:17:07 CET] <cone-037> ffmpeg 03Richard Shaffer 07master:81d1e1e5094b: fate: add aac id3v2 demux test
[22:35:52 CET] <atomnuker> so drm has a DRM_IOCTL_AGP_INFO ioctl which takes in a struct drm_agp_info which contains PCI vendor and device IDs
[22:36:49 CET] <atomnuker> I bet someone's regretting thinking AGP will be the interface people will use for the next 30 years
[22:39:58 CET] <BtbN> isn't that just never been renamed because no point to break compat over that?
[22:41:42 CET] <atomnuker> yep
[22:42:06 CET] <atomnuker> also why are DRM_FORMATS in reverse order than how they're actually laid out
[22:42:37 CET] <atomnuker> drm ARGB is vulkan/vaapi/everything BGRA, etc.
[22:51:14 CET] <cone-037> ffmpeg 03Carl Eugen Hoyos 07master:d401ba6b3d86: lavf/matroskaenc: Force the minimum value for -reserve_index_space to 2.
[22:59:24 CET] <feliwir> RiCON, i am not using those
[22:59:27 CET] <feliwir> as far as i am aware
[22:59:55 CET] <RiCON> you'd need to hide all .dll.a like JEEB said to make sure
[23:00:06 CET] <RiCON> or just use nevcairiel's mingw, which is static-only
[23:03:16 CET] <jamrial> doesn't using --extra-cflags="-static" prevent linking to .dll.a libraries?
[23:04:30 CET] <RiCON> jamrial: not enough, last time i tried
[23:04:44 CET] <RiCON> only -Wl,-Bstatic actually forces linking to .a
[23:05:30 CET] <sfan5> -static e.g. doesn't prevent it from dynamically linking libgcc and libstdc++ IIRC
[23:14:12 CET] <jkqxz> jamrial:  Did you stop there because you thought there should be more discussion here, or can I merge the next set directly?
[23:15:45 CET] <jamrial> jkqxz: no, stopped there since you authored them, so you're better suited to merge them :p
[23:16:10 CET] <jkqxz> Ok, sure.  I'll do it now :)
[23:16:41 CET] <jamrial> but yeah, wanted to get rid of the configure stuff in the backlog so you could get to these right away
[23:21:08 CET] <cone-037> ffmpeg 03Mark Thompson 07master:5b145290df29: lavc: Add support for increasing hardware frame pool sizes
[23:21:09 CET] <cone-037> ffmpeg 03Mark Thompson 07master:d23fff0d8a0e: Merge commit '5b145290df2998a9836a93eb925289c6c8b63af0'
[23:22:52 CET] <cone-037> ffmpeg 03Mark Thompson 07master:cad739dace55: lavc: Add per-thread surfaces in get_hw_frame_parameters()
[23:22:53 CET] <cone-037> ffmpeg 03Mark Thompson 07master:9471122a1b5d: Merge commit 'cad739dace55e3446ef7180de688173cd19fb000'
[23:27:57 CET] <18VADBOYX> [13FFV1] 15michaelni closed pull request #71: add iana considerations section (06master...06iana-considerations) 02https://git.io/vHi4n
[23:27:58 CET] <7YSAAHUFA> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vAYuG
[23:27:58 CET] <7YSAAHUFA> 13FFV1/06master 144b664e7 15Dave Rice: add iana considerations and media type definition section...
[23:28:50 CET] <cone-037> ffmpeg 03Mark Thompson 07master:6d86cef06ba3: lavfi: Add support for increasing hardware frame pool sizes
[23:28:51 CET] <cone-037> ffmpeg 03Mark Thompson 07master:bcab11a1a23d: Merge commit '6d86cef06ba36c0ed591e14a2382e9630059fc5d'
[23:50:00 CET] <cone-037> ffmpeg 03Mark Thompson 07master:b128be1748f3: vf_*_vaapi: Support increasing hardware frame pool size
[23:50:01 CET] <cone-037> ffmpeg 03Mark Thompson 07master:b4fca397dd40: Merge commit 'b128be1748f3920a14a98307265df5f2d3433e1d'
[23:51:36 CET] <jkqxz> Noticed the API test break, will fix in a moment.
[23:54:40 CET] <cone-037> ffmpeg 03Mark Thompson 07master:a5ed07940c69: fate: Fix fate-api reference files after AVCodecContext change
[23:55:47 CET] <cone-037> ffmpeg 03Mark Thompson 07master:e4cdef00263d: vf_scale_qsv: Support increasing hardware frame pool size
[23:55:48 CET] <cone-037> ffmpeg 03Mark Thompson 07master:6e050e0085b3: Merge commit 'e4cdef00263dc8b3c8de9d34ceacd00dc68979c0'
[23:56:23 CET] <cone-037> ffmpeg 03Mark Thompson 07master:c6bc18bc121e: vf_hwupload/hwmap: Support setting a fixed pool size
[23:56:23 CET] <cone-037> ffmpeg 03Mark Thompson 07master:b668a1c8b35d: Merge commit 'c6bc18bc121ea66df715123c59f7ef9542c0914a'
[23:59:39 CET] <cone-037> ffmpeg 03Mark Thompson 07master:caecb85014fc: hwcontext: Perform usual initialisation on derived device contexts
[23:59:40 CET] <cone-037> ffmpeg 03Mark Thompson 07master:cfff6d1f777c: Merge commit 'caecb85014fc81f8734560a150073627eedab78c'
[00:00:00 CET] --- Tue Feb 13 2018