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

[burek]

[00:00:01 CET] <jkqxz> Can you try adding 'format=rgba' before each of the hwuploads?
[00:00:14 CET] <jkqxz> (That will make it combine everything into one plane, so only run on one plane.)
[00:01:11 CET] <jkqxz> wm4:  Using it for what?
[00:03:59 CET] <wm4> jkqxz: I mean in mpv, so I can use opencl filter output directly
[00:04:32 CET] <wm4> GL support in libavfilter would probably still be full of known problems
[00:05:32 CET] <nevcairiel> GL is too peculiar for that, it would be full of limitations
[00:05:46 CET] <jkqxz> The interop is only one-way (gl->opencl), so you have fun getting the output buffers into the filter.
[00:05:58 CET] <wm4> jkqxz: well shit
[00:06:20 CET] <wm4> could probably use a gpu memcpy?
[00:06:24 CET] <wm4> cuda interop also does that
[00:06:37 CET] <jkqxz> (See the hwmap "reverse" option, which is dubious hackery to make it work in lavfi.)
[00:08:04 CET] <wm4> yeah, but I'd prefer not
[00:08:22 CET] <jkqxz> GPU memcpy should work though, yeah.
[00:12:33 CET] <durandal_1707> the ffserver docs havent been removed from site
[00:12:43 CET] <wm4> is there something yet that tells the API user which hw device ctx exactly a filter needs?
[00:13:25 CET] <jkqxz> Which type?  Currently, the name of the filter...
[00:14:05 CET] <rcombs> would be nice not to have to duplicate as much code across multiple implementations of the same filter
[00:14:05 CET] <jkqxz> There aren't currently any filters which can take different types (other than the generic hw* ones), so there didn't seem much point in adding special API for it yet.
[00:14:24 CET] <rcombs> like, scale_vaapi currently doesn't support as much stuff as scale
[00:14:28 CET] <wm4> jkqxz: AVHWDeviceType
[00:14:44 CET] <rcombs> in particular I recently was informed it doesn't handle SAR-setting at all
[00:15:00 CET] <wm4> mpv has a list of device ctxes that are available, so it has to guess which one to give to the filter#
[00:16:06 CET] <rcombs> hmm
[00:16:12 CET] <rcombs> are BSFs still 1:1 in terms of streams
[00:16:22 CET] <rcombs> like, a BSF must have exactly 1 input and 1 output
[00:16:46 CET] <nevcairiel> yes
[00:16:55 CET] <nevcairiel> why would you have a bsf do anything else
[00:17:14 CET] <rcombs> I need to make a closed-captions-extract bsf
[00:17:27 CET] <nevcairiel> that will be terrible anyway because reordering
[00:17:32 CET] <rcombs> tell me about it
[00:18:11 CET] <wm4> iv mpv I'm going to turn everything into filters, wish me good luck
[00:18:41 CET] <nevcairiel> i might even use something like that though, piping decoder output back to a CC decoder is rather annoying in directshow
[00:18:55 CET] <nevcairiel> would be easier if the source could just expose them
[00:19:04 CET] <rcombs> I can't do that because I need this to work without a full decode
[00:19:28 CET] <nevcairiel> invent a faux hwaccel that does nothing :)
[00:19:55 CET] <nevcairiel> decoding without decoding!
[00:20:43 CET] <rcombs> that& seems awful, but goes along the lines of something that would be nice (exposing the reorder part of the decoder separately from the actual decompression)
[00:22:58 CET] <wm4> nevcairiel: clever idea
[00:23:14 CET] <wm4> you can get all the metadata without that much overhead
[00:23:33 CET] <wm4> maybe that would be a way to get something like this internally
[00:23:37 CET] <rcombs> like, the hwaccel API doesn't quite fit well with videotoolbox
[00:23:40 CET] <wm4> without having to expose a dummy hwaccel
[00:24:16 CET] <atomnuker> wm4: so mpv's going full directshow?
[00:24:28 CET] <rcombs> honestly all this should be in the parser imo
[00:24:41 CET] <wm4> atomnuker: yes, and gstreamer and upipe (except not, it's nothing that complex)
[00:25:23 CET] <nevcairiel> what would the parser do with reordering, it basically only has two purposes, assemble frames for the decoder, and parse basic bitstream info out - and most dont even do the second thing
[00:25:50 CET] <rcombs> well I want them to do the second thing more
[00:26:12 CET] <rcombs> and iirc the h264 parser already exposes enough to do reordering
[00:26:30 CET] <rcombs> like, it constructs a pts from the reorder data and dts
[00:26:50 CET] <nevcairiel> more accurately it assembles the POC
[00:27:00 CET] <wm4> wasn't a BSF to reconstruct dts something jkqxz wanted to do?
[00:30:11 CET] <rcombs> but yeah, I'd like to expose 708 subtitles as an AVStream produced within lavf
[00:31:12 CET] <kierank> rcombs: how?
[00:31:15 CET] <nevcairiel> that seems unlikely to actually happen
[00:31:23 CET] <kierank> imagine if 708 appears when you're encoding to mp4
[00:31:29 CET] <kierank> how can you make a stream appear from nowhere
[00:31:43 CET] <rcombs> *demuxing
[00:31:50 CET] <rcombs> or do you mean if they show up halfway through
[00:31:54 CET] <kierank> yes
[00:32:07 CET] <nevcairiel> we support creating streams on the fly, but most consumers wouldnt actually process them then
[00:32:49 CET] <rcombs> alternately, a decoder that takes [H264, MPEG2, HEVC] as input and just decodes the subtitles
[00:33:53 CET] <kierank> already possible i think with that lavfi hack
[00:34:42 CET] <rcombs> gotta decode the video, though
[00:35:15 CET] <nevcairiel> maybe you should just convince whatever ultimately decodes the video to make CC appear
[00:35:47 CET] <rcombs> tell that to purportedly-smart TVs
[00:35:59 CET] <rcombs> and web browsers
[00:36:05 CET] <nevcairiel> you would think smart TVs know how to handle CC
[00:36:18 CET] <rcombs> you would, wouldn't you
[00:36:25 CET] <nevcairiel> isnt that even a legal requirement in the US
[00:36:27 CET] <rcombs> that's what you get for thinking
[00:36:36 CET] <rcombs> yeah, in OTA
[00:36:46 CET] <rcombs> not in streaming video
[00:37:18 CET] <nevcairiel> its fascinating how different sources of things make TVs do so extremely different things
[00:39:05 CET] <nevcairiel> like the actual TV stuff goes through an entirely different decoder
[00:39:11 CET] <nevcairiel> you would think they would be smarter then that
[00:39:24 CET] <rcombs> so I guess the least-effort way to do this would be to add an hwaccel that does nothing, yeah
[00:39:37 CET] <nevcairiel> thats an easy hack at least
[00:39:44 CET] <rcombs> and then put the result through some lavfi thing
[00:39:49 CET] <rcombs> though that would require subtitles in lavfi
[00:39:54 CET] <kierank> 11:39:05 PM <"nevcairiel> like the actual TV stuff goes through an entirely different decoder
[00:39:58 CET] <kierank> yes, that part needs to work
[00:40:07 CET] <kierank> nobody cares about the usb sticks and webcast crap :)
[00:40:18 CET] <nevcairiel> except all the users
[00:40:35 CET] <nevcairiel> maybe not usb sticks, but web stuff is growing so much
[00:40:45 CET] <kierank> then they should get people who understand video to write these stacks, not html5/js engineers
[00:42:27 CET] <nevcairiel> panasonic wanted to recruit me some years ago, i forget what technologies they looked at though, might have been web shittery as well, i still worked in that back then
[00:44:03 CET] <nevcairiel> oh yeah was web stuff, found the  old mails
[00:44:20 CET] <kierank> every smart tv i've tried has been buggy as hell
[00:44:26 CET] <kierank> except the broadcast stuff has worked
[00:44:29 CET] <kierank> the web stuff crashed galore
[00:45:00 CET] <atomnuker> ^^ +1
[00:45:13 CET] <nevcairiel> I dont use any of the built-in tv features other then the ability to show a picture  from HDMI
[00:45:21 CET] <nevcairiel> so cant really say either way
[00:48:22 CET] <wm4> how can software be this bad
[00:48:41 CET] <atomnuker> hardware is worse :)
[00:49:03 CET] <nevcairiel> mostly because cheap web developers grow on trees and good developers are expensive
[00:50:03 CET] <atomnuker> do we have something in the configure script/tools to convert binary to ascii bytes?
[00:50:44 CET] <nevcairiel> doesnt the cuda stuff do something like that to compile filters
[00:50:48 CET] <rcombs> in configure?
[00:51:15 CET] <nevcairiel> oh no it just wraps and escapes some long string in a C string
[00:53:14 CET] <galan> I would like to develop an app similar to transcoding.c, compile it on both Linux & Mac, with full debugging ability, and using shared libraries. I have a new, clean MBP. What would yield the best dev environment? Should I even try installing ffmpeg from a package, like Brew or Macports? Or should I compile everything myself? I'm still fairly new at compiling for Linux (but have done ffmpeg on Linux a few times), so I appreciate 
[01:14:42 CET] <KGB> [13FFV1] 15michaelni pushed 2 new commits to 06master: 02https://git.io/vNsrw
[01:14:42 CET] <KGB> 13FFV1/06master 141d2744d 15Dave Rice: use rfc/pdf syntax in initial_state_delta
[01:14:42 CET] <KGB> 13FFV1/06master 1467efbaa 15Dave Rice: change sequential lines to paragraphs...
[03:37:47 CET] <cone-898> ffmpeg 03James Almer 07release/3.2:24c49e0b4229: changelog: update after previous commit
[03:39:00 CET] <jamrial> michaelni: please make sure to include the commits i pushed to the branch when you tag 3.2.10
[03:46:44 CET] <cone-898> ffmpeg 03James Almer 07master:6e80079a2840: avcodec: increase AV_INPUT_BUFFER_PADDING_SIZE to 64
[03:47:32 CET] <atomnuker> awesome, who'll be the first to find a place zmm regs won't slow everything down?
[03:54:44 CET] <jamrial> vp9 mc
[11:26:36 CET] <thardin> docker + FATE, y/n? considering setting something up
[12:54:18 CET] <cone-826> ffmpeg 03Jun Zhao 07master:9b955eece610: examples/vaapi_encode: Remove redundancy check when free context.
[12:54:19 CET] <cone-826> ffmpeg 03Jörn Heusipp 07master:a571a2a65abe: avformat/libopenmpt: Fix mixed code and declarations
[12:54:20 CET] <cone-826> ffmpeg 03Jörn Heusipp 07master:8b1b25a86f1b: avformat/libopenmpt: Update to libopenmpt 0.3 API
[12:54:21 CET] <cone-826> ffmpeg 03Harald Gaechter 07master:43e510d66887: avdevice/gdigrab: Fix screen size and mouse position calculations on hi-DPI screens
[12:54:22 CET] <cone-826> ffmpeg 03Jérôme Martinez 07master:58e16a4f4b70: avcodec/ffv1enc: mark RGB48 support as non-experimental
[12:54:23 CET] <cone-826> ffmpeg 03Richard Shaffer 07master:9147c0975533: avformat/http: fix memory leak in parse_cookie.
[14:35:05 CET] <BBB> in the same way that C used to do 64bit math emulation for 32bit, is there a 128 bit math emulation available for 64bit archs? (as integrated part of the language)
[14:36:16 CET] <jdarnley> None immediately spring to mind
[14:36:45 CET] <jdarnley> I think some of the "scripted" languages do have big integers
[14:37:58 CET] <atomnuker> gcc apparently supports 128bit nums
[14:38:33 CET] <atomnuker> but what do you need them for? 64 bits already offers universe ending range for counting anything
[14:41:28 CET] <BBB> very large bitmasks
[14:41:41 CET] <BBB> I know I can just use 2 uint64_ts, but whats the fun in that
[14:41:56 CET] <atomnuker> true
[14:42:16 CET] <BBB> did you know a 64bit integer only contains 64 bits? what if I want 96!
[14:42:33 CET] <BBB> if strings were limited to 64 characters length, people would probably get upset
[14:43:34 CET] <atomnuker> you could write some inline asm to use vector regs as bitmasks
[15:32:08 CET] <durandal_1707> so which gsoc 2017 project have actually been fully integrated into master?
[15:35:38 CET] <jamrial> vmaf, vorbis encoder improvements, vp9 tile threading (i think that was gsoc)
[15:36:18 CET] <jamrial> also fits decoder and encoder
[15:36:42 CET] <jamrial> no idea if the rest made it in
[15:39:07 CET] <durandal_1707> there is bunch of vmaf filters that didnt get in
[15:59:32 CET] <atomnuker> no, the vorbis encoder still has 7 patches outstanding
[16:00:16 CET] <atomnuker> the first 3 apply fine but the rest are invalid (something went wrong with git patch), so I'd need to go over them line by line and recreate them
[16:03:58 CET] <atomnuker> I wish there was an av_dict_get_int too
[16:18:21 CET] <KGB> [13FFV1] 15dericed opened pull request #99: add code of conduct (06master...06code-of-conduct) 02https://git.io/vNGXt
[16:53:26 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vNGyG
[16:53:26 CET] <KGB> 13FFV1/06master 140051547 15Dave Rice: add code of conduct
[19:30:46 CET] <klaxa> huh, looks like i messed up that one on the ML, sorry, i'm bad with email
[20:23:05 CET] <atomnuker> jkqxz: do you think I could import kms images directly into vulkan with the external_memory_fd extension?
[20:23:59 CET] <atomnuker> I could probably use vulkan to detile them without having to go through vaapi and end up with horrid chroma
[20:26:13 CET] <atomnuker> (because https://0x0.st/sNaO.png is what I usually end up with)
[22:00:22 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #100: [WIP] Add RGGB (Bayer) color space and YDgCoCg-R transformation (06master...06RGGB) 02https://git.io/vNZsl
[23:35:51 CET] <cone-163> ffmpeg 03Michael Niedermayer 07master:7dbbb75ee32f: avcodec/arm/sbrdsp_neon: Use a free register instead of putting 2 things in one
[23:35:52 CET] <cone-163> ffmpeg 03Michael Niedermayer 07master:2cd718a4c52f: avcodec/opus: Add {} over multiline if() body
[23:35:52 CET] <cone-163> ffmpeg 03Michael Niedermayer 07master:860d991fcd71: avcodec/utils: Avoid hardcoding duplicated types in sizeof()
[23:52:55 CET] <cone-163> ffmpeg 03Marton Balint 07master:0c31a3876d9a: avfilter/vf_framerate: simplify filter
[00:00:00 CET] --- Sat Jan 13 2018