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

[burek]

[00:24:17 CEST] <iive> Chloe: well, my distro still doesn't ship sdl2.
[00:24:31 CEST] <Chloe> which is that?
[00:25:29 CEST] <Chloe> and, that's kinda sad. As I said, it's been deprecated for 4 years now. That should be long enough for any distro to ship it
[00:25:51 CEST] <BtbN> A lot of stuff still depends on sdl1, and very few applications shipped by distros use sdl2
[00:26:13 CEST] <BtbN> No point holding back ffmpeg because of that
[00:26:28 CEST] <BtbN> ffmpeg is a big enough library/application that it might motivate them to include sdl2
[00:28:30 CEST] <JEEB> even debian wheeze (7) has backports with sdl2
[00:28:35 CEST] <JEEB> *wheezy
[00:28:38 CEST] <JEEB> https://packages.debian.org/wheezy-backports/libsdl2-dev
[00:28:44 CEST] <JEEB> and that's quite old by now
[00:28:59 CEST] <JEEB> or wait... don't tell me that's the latest still .-.
[00:29:32 CEST] <Chloe> it's the current stable
[00:29:54 CEST] <JEEB> that said, it's not like they're gonna push that FFmpeg version up that they have
[00:30:18 CEST] <JEEB> and as it is in backports already it means that the next release will have it in standard repos
[00:30:52 CEST] <Chloe> oh wait, no, wheezy is the old stable
[00:31:30 CEST] <JEEB> yeah, jessie is out
[00:31:58 CEST] <JEEB> and yeh, standard jessie repos have sdl2 https://packages.debian.org/jessie/libsdl2-dev
[00:40:09 CEST] <cone-357> ffmpeg 03Paul B Mahol 07master:140a0485d377: avfilter/vf_overlay: split blend_image into functions for each overlay format
[00:40:10 CEST] <cone-357> ffmpeg 03Paul B Mahol 07master:97297fb1446f: avfilter/vf_overlay: inline yuv output formats
[00:54:54 CEST] <iive> Chloe: slackware
[00:58:31 CEST] <Chloe> iive: couldn't you just make a package for slackware (or install it from source)?
[00:58:56 CEST] <iive> Chloe: that's what i did, to get steam games working.
[00:59:44 CEST] <Chloe> I also suspect that most other people running slackware will be able to compile it themselves as well
[01:01:22 CEST] <JEEB> lol, slackware seems to have even gotten onto SDL's wiki
[01:01:50 CEST] <JEEB> oh wait, that seems to be an older thing :<
[01:01:55 CEST] <JEEB> https://wiki.libsdl.org/FAQLinux#I.27m_running_Mandrake_or_Slackware_and_applications_can.27t_find_SDL.21
[01:03:49 CEST] <BtbN> philipl, I can't even install the CUDA 8 SDK.
[01:04:02 CEST] <BtbN> My GPU is unsupported!
[01:09:08 CEST] <iive> would nvidia support vulkan?
[01:09:23 CEST] <BtbN> what do you mean?
[01:09:35 CEST] <JEEB> eh, they already have vulkan support in most of their drivers :P
[01:09:37 CEST] <BtbN> Their driver supported vulkan from day one
[01:11:21 CEST] <iive> nice. but vulkan was about the 3d stuff, what about the one for computations? hda?
[01:13:49 CEST] <BtbN> OpenCL?
[01:14:17 CEST] <iive> i've heard that CUDA is usually faster than OpenCL, so I was wondering if the new api's would get closer to it.
[01:14:34 CEST] <BtbN> CUDA is faster because nvidia wants it to be faster.
[01:14:51 CEST] <BtbN> No actual technical reason for that.
[01:15:18 CEST] <iive> you mean, they intentionally don't optimize their OpenCL ?
[01:15:22 CEST] <BtbN> yes
[01:15:42 CEST] <nevcairiel> CUDA is faster because it translates OpenCL to CUDA, and thats just not a very efficient thing to do
[01:16:08 CEST] <BtbN> Their OpenCL is also stuck at 1.2, while 2.0+ already exists
[01:17:15 CEST] <BtbN> Kind of wanted to test CUDA on Pascal, but I can't install the damn SDK, because it does a "GPU support check", and Pascal is too recent, it doesn't know about it...
[01:18:31 CEST] <iive> like the prince of persia game(s) that complain from my cpu, not been pentium.........
[01:21:33 CEST] <BtbN> I just extracted the installer with 7zip and got all the stuff I wanted
[01:21:57 CEST] <BtbN> windows is horribly annoying with its lack of an rpath
[01:29:30 CEST] <philipl> BtbN: https://developer.nvidia.com/ffmpeg
[01:29:32 CEST] <philipl> You ever read that.
[01:29:45 CEST] <philipl> Do we have the capabilities that their filters offer?
[01:30:26 CEST] <BtbN> there's scale_npp
[01:31:07 CEST] <philipl> So that's basically a yes.
[01:31:27 CEST] <BtbN> They implemented it using a pre-compiled cuda-binary which they added to the ffmpeg tree
[01:31:32 CEST] <BtbN> Instead of libnpp
[01:31:37 CEST] <philipl> scary
[01:31:49 CEST] <BtbN> The only difference is the multi-resolution output
[01:31:57 CEST] <BtbN> Well, that's how I'd add cuda-based filters as well
[01:32:06 CEST] <BtbN> Saves you from depending on nvcc for building
[01:32:36 CEST] <philipl> fair enough
[01:32:46 CEST] <BtbN> http://developer.download.nvidia.com/compute/redist/ffmpeg/1511-patch/FFMPEG-with-NVIDIA-Acceleration-on-Ubuntu_UG_v01.pdf
[01:32:49 CEST] <BtbN> page 19
[01:32:59 CEST] <BtbN> I'm not sure if I'd even want to have that in ffmpeg.
[01:33:25 CEST] <BtbN> could just easily add a tee filter in complex, and create multiple scale_npp
[01:33:30 CEST] <philipl> I can see how it's useful in specific situations, but yeah.
[01:33:39 CEST] <philipl> I'd figure you'd want to solve that at the filter graph level.
[01:34:01 CEST] <BtbN> it should even be possible allready
[01:34:11 CEST] <BtbN> Not sure if the tee filter can handle cuda frames though
[01:34:19 CEST] <BtbN> But it should?
[01:34:30 CEST] <philipl> As long as it's just passing them through, you'd hope so.
[01:35:06 CEST] <BtbN> it will be slightly less efficient, as scale_npp does weird stuff with uninterlaving, scaling, reinterleacing NV12
[01:35:53 CEST] <BtbN> philipl, also, do you remember yuv420p being weird for nvenc? Aparently you have to /2 the stride for the U/V planes. And I don't remember ever seing that documented anywhere.
[01:36:33 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1301 the generic case works for all formats, except yuv420p
[01:36:47 CEST] <philipl> I don't remember anything like that, but I forget things easily.
[01:37:13 CEST] <BtbN> Yes, I ran into that while converting the mess of manual copying
[01:38:09 CEST] <philipl> BtbN: unrelated, but I'm reminded. You went to the trouble of implementing dynamic loading for nvenc but not for cuvid.
[01:38:23 CEST] <philipl> Arguably, you could use the funny headers from the video sdk and dynamic load for cuvid too.
[01:38:41 CEST] <BtbN> cuvid needs the full cuda headers
[01:38:44 CEST] <BtbN> nvenc doesn't.
[01:38:56 CEST] <BtbN> so you need the cuda sdk anyway
[01:39:08 CEST] <philipl> true.
[01:39:33 CEST] <BtbN> nvenc does need a very minimal part of the cuda sdk, but it just dyn-loads that as well
[01:39:59 CEST] <BtbN> But expanding on that would end in a mess, ultimately re-implementing large parts of the cuda.h in ffmpeg, so it was decided against it
[01:40:08 CEST] <philipl> cuvid 'only' needs another half dozen symbols, I think.
[01:40:37 CEST] <philipl> I'm just thinking if we did that plus the video sdk headers for nvcuvid and cuviddec, you could avoid headers with weird licences.
[01:42:01 CEST] <BtbN> I'm also not so sure about the cuda and npp libraries qualifying as system libraries for the GPL
[01:42:28 CEST] <cone-357> ffmpeg 03Alex Converse 07master:09317e3e06d7: ivfenc: Add VPX codec tags.
[01:42:33 CEST] <philipl> Well, libcuda and libnvcuvid come with the driver, and so they are in the same bucket as the encoder library for nvenc.
[01:42:36 CEST] <BtbN> libnpp definitely doesn't.
[01:42:40 CEST] <philipl> Yeah, that's harder
[01:59:02 CEST] <Chloe> ffserver isn't already deprecated?
[02:06:07 CEST] <nevcairiel> it kind of is, it'll just flat out stop w orking on the next major bump, as it relies on deprecated code thats going away
[14:00:31 CEST] <Steven_> Hello?
[14:01:13 CEST] <Steven_> michaelni here?
[14:01:48 CEST] <JEEB> every now and then
[14:09:21 CEST] <michaelni> Steven_, yes
[14:10:50 CEST] <Steven_> I saw you asked some question for output_ts_offset
[14:10:59 CEST] <Steven_> and response the maillist
[14:12:27 CEST] <Steven_> i think ,initial_offset is useful for muxer segment if use API, it's same function with output_ts_offset, because the output_ts_offset can set the start_time start_pts 
[14:14:23 CEST] <Steven_> i did not see the talk context here, missed the talk ,i usually use mail, irc little :-)
[15:10:29 CEST] <michaelni> Steven_, ive replied on ml, did just now see your reply on IRC
[15:11:00 CEST] <Steven_> :-D
[15:11:39 CEST] <Steven_> Sorry, my English is very poor, i'm learning English hard.
[15:12:03 CEST] <iive> it's good enough.
[15:12:27 CEST] <michaelni> well, i do have difficulty understanding Steven_ sometimes :(
[15:12:49 CEST] <Steven_> :-(
[15:14:28 CEST] <michaelni> why do you say its usefull for API use ? i see no difference betwen API and command line output_ts_offset and initial_offset can both be set by API as well as command line
[15:14:32 CEST] <Steven_> you mean the output_ts_offset is no need?
[15:16:38 CEST] <Steven_> if just use format segment, av_opt_set(AvFormatContext(segment)->priv_data, "initial_offset", "20"); is useful
[15:17:56 CEST] <michaelni> yes but its similar for  output_ts_offset with API, or both with command line
[15:18:54 CEST] <Steven_> yes
[15:19:02 CEST] <Steven_> you are right
[15:31:32 CEST] <Steven_> ilove11ven åì`(mÞ
[15:31:44 CEST] <ilove11ven> yes
[15:33:09 CEST] <ilove11ven> you send some patches in the mailing list, i see
[15:34:23 CEST] <Steven_> Interested in ffmpeg :-)
[15:41:35 CEST] <ilove11ven> very nice multimedia framework
[15:45:17 CEST] <Steven_> do you have wechat?
[15:45:53 CEST] <ilove11ven> yes
[15:51:30 CEST] <ilove11ven> you did some work about http-based streaming. though familiar with both mov and mpeg-ts,  i am not familiar with either dash or hls. Their intrinsic latency is unacceptable in video surveillance.
[15:54:23 CEST] <Steven_> of course, if low latency, HangZhou have dahua and hikvision they are using rtsp, but the protocol is not friendly for terminal, users must install software or other plugin.
[15:54:47 CEST] <Steven_> i always using rtmp http+flv
[15:55:07 CEST] <ilove11ven> hello from hikvision
[15:56:01 CEST] <Steven_> latency between 0.7 to 3s 
[15:57:48 CEST] <Steven_> this latency than hikv, but enough for douyutv,pandatv, and use webrtc for connect mic
[15:59:32 CEST] <ilove11ven> webrtc should be of low latency, because they use rtp/avpf. do you have tested it?
[16:00:19 CEST] <Steven_> no, but my guys have using it
[16:00:30 CEST] <ilove11ven> what about its latency
[16:00:56 CEST] <Steven_> very low, and better for sound
[16:01:27 CEST] <ilove11ven> add my wechat
[16:15:22 CEST] <ubitux> durandal_17: wanna start testing nlmeans?
[16:15:57 CEST] <Chloe> how is ffmpeg -i t.mov -c:v ffv1 -c:a aac -f fifo -fifo_format mov -map 0:v fifo.mov & mpv fifo.mov 'nowhere near the same functionality' as the sdl outdev?
[16:16:43 CEST] <ubitux> fifo with mov, is that possible?
[16:16:57 CEST] <Chloe> works for me(tm)
[16:17:52 CEST] <Chloe> I mean, it was also just an example, I was just saying that using a fifo and a video player is an alternative
[16:18:33 CEST] <ubitux> does it work?
[16:18:52 CEST] <Chloe> like I said, it seems to work, feel free to try it
[16:19:04 CEST] <Chloe> I'd like to know if it works for others as well
[16:19:08 CEST] <ubitux> i would tempted to say that it doesn't work well depending on the output
[16:19:16 CEST] <ubitux> you might also be pushing remotely or something
[16:19:29 CEST] <ubitux> but still want to follow what you're encoding
[16:19:55 CEST] <Chloe> you can still do that with the fifo
[16:20:07 CEST] <Chloe> just have multiple outputs
[16:20:33 CEST] <Chloe> I wonder if you could even just use a rawvideo fifo
[16:20:40 CEST] <ubitux> but requires a muxing and roundtrip to HD right?
[16:21:27 CEST] <Chloe> I guess
[16:23:49 CEST] <Chloe> hmph. Looks like I'm not going to get off making a PoC that SDL2 wont work
[16:51:38 CEST] <durandal_1707> ubitux: yes
[16:56:14 CEST] <ubitux> durandal_1707: github/ubitux/nlmeans
[16:57:11 CEST] <durandal_1707> ubitux: what remains to be done?
[16:58:13 CEST] <ubitux> (large) borders are not processed, not yet any threading, no simd (can be done later), probably overly complex integrals given that i don't even use the borders, no settings granularity between luma and chroma (can be done later), documentation 
[16:58:36 CEST] <ubitux> otherwise it's kind of usable if you don't mind the borders
[16:58:41 CEST] <ubitux> afk for a while
[17:02:48 CEST] <Chloe> well apparently my sdl2 outdev works now
[17:03:19 CEST] <Chloe> so that's nice
[17:58:43 CEST] <durandal117> ubitux: default sigma 1 blurs imho too much, cant it be less that 1?
[18:12:13 CEST] <durandal117> Chloe: why avfilter out of sdl2?
[18:12:43 CEST] <Chloe> durandal117: so you can view part way down a filter graph
[18:13:15 CEST] <durandal117> what?
[18:13:42 CEST] <Chloe> so you can see the output in the middle of a filtergraph
[18:46:44 CEST] <Chloe> durandal117: does that sound OK? or not really practical?
[18:49:53 CEST] <durandal117> Chloe: how would it work?
[18:52:16 CEST] <Chloe> I'm not really sure, I've never worked with lavfi, I know you're quite good with it, so I was wondering if you thought it was possible. The idea I had was that itd create an sdl window and then just write avpackets to the window and the filter output
[18:52:34 CEST] <Chloe> obviously this would only work for certain pixel formats
[18:56:47 CEST] <durandal117> Chloe: each filter instance would create own window?
[18:56:49 CEST] <jkqxz> The idea there being to have something like "ffmpeg ... -i input -vf foo=42,bar=9001,sdl_preview ... output", such that you get a live preview of the images somewhere in the filter chain?  (Most obviously at the end, as in that example, to see what will actually be encoded.)
[18:57:14 CEST] <Chloe> durandal117: yep
[18:57:36 CEST] <Chloe> jkqxz: yes, except if you want a final output using the outdev would probably make more sense
[18:58:58 CEST] <durandal117> its very interesting idea, could it be made more generice, so it outputs AVFrames to apps that could support it
[19:00:37 CEST] <Chloe> would be helpful in dev as well, so you can see the before and after for filters
[19:01:47 CEST] <JEEB> I'm just not sure if a lot of such stuff should be in FFmpeg itself
[19:02:16 CEST] <JEEB> the interface could take in decoded samples of course, but I would probably do it in a separate application that handles the whole rendering part
[19:05:07 CEST] <Chloe> Well yes, I'd prefer if there wasnt an SDL output thing within lavfi or lavd, but it looks like others dont want to remove it without a replacement. A filter which outputs decoded samples could be useful though
[19:16:28 CEST] <ubitux> durandal117: not sure; try maybe to increase WEIGHT_LUT_SIZE
[19:20:23 CEST] <ubitux> i'm going to fix the borders now
[19:20:31 CEST] <ubitux> and do most of the remaining stuff
[19:29:34 CEST] <ubitux> Chloe: with lavfi you can create a sink at any time and send it to your device
[19:31:05 CEST] <ubitux> -lavfi "filter1, split=2 [a][b]; [a] filter2 [c]" -map '[b]' -f sdl ... -map '[c]' -f mp4 ...
[19:32:02 CEST] <Chloe> ah! nice, no need for a sdl filter then
[19:33:17 CEST] <JEEB> yup
[19:33:41 CEST] <Chloe> could someone test if my sdl2 outdev works on a OS other than OSX
[19:35:56 CEST] <durandal117> ubitux: do you have some ref implementation with which you can compare output?
[19:36:24 CEST] <ubitux> mmh you can maybe try ipol.im, but i haven't tested yet
[19:36:30 CEST] <ubitux> http://www.ipol.im/pub/art/2011/bcm_nlm/
[19:38:24 CEST] <ubitux> Chloe: works for me
[19:38:32 CEST] <ubitux> but http://sprunge.us/UMXM + http://sprunge.us/VZhE
[19:39:40 CEST] <ubitux> (is it really sdl2?)
[19:39:57 CEST] <Chloe> ugh, should be
[19:40:05 CEST] <Chloe> I wrote this patch a while ago
[19:40:10 CEST] <Chloe> I dont get the latter warning with osx clang, and unfortunatly gcc doesnt work on OSX anymore due to system headers, so thanks.
[19:40:25 CEST] <ubitux> you're including the same header as sdl1
[19:40:34 CEST] <Chloe> yep, that's fine
[19:40:39 CEST] <Chloe> sdl2-config will fix this
[19:40:58 CEST] <ubitux> not really
[19:41:07 CEST] <Chloe> hmm?
[19:41:19 CEST] <ubitux> because that file is likely compiled with the flags from sdl-config as well
[19:41:27 CEST] <Chloe> it wont be
[19:41:39 CEST] <Chloe> if sdl2 is enabled then sdl is disabled
[19:41:49 CEST] <Chloe> (or it should be)
[19:42:22 CEST] <ubitux> mmh, ok
[19:43:02 CEST] <ubitux> so they didn't change the namespace?
[19:43:23 CEST] <Chloe> well it's including SDL2/sdl.h rather than SDL/sdl.h
[19:43:39 CEST] <ubitux> so anyway, i can't build ffplay anymore :(
[19:43:41 CEST] <durandal117> ubitux: i compared with tnlmeans and for sigma 1 image should not be so much smoothed
[19:43:53 CEST] <ubitux> durandal117: ok
[19:43:55 CEST] <durandal117> highter sigmas give useless output imho
[19:43:58 CEST] <Chloe> ubitux: yes, you'll need to disable sdl2 to build ffplay. 
[19:44:44 CEST] <ubitux> durandal117: ok
[19:44:51 CEST] <ubitux> i need sigma=4 for my test
[19:44:59 CEST] <ubitux> so didn't realize
[19:45:11 CEST] <Chloe> the ffplay maintainer had an SDL2 patch for ffplay, which I guess they'd just need to rebase (or I could but I dont have a copy of it)
[19:46:08 CEST] <Chloe> found it, https://github.com/cus/ffplay/tree/sdl2
[19:46:34 CEST] <Chloe> only 6444 commits behind >.<
[19:56:38 CEST] <durandal117> ubitux: tnlmeans have paramter that controls bluring, if i set it to very high 4 I get similar results
[19:58:53 CEST] <ubitux> cool, ok :)
[19:59:20 CEST] <ubitux> are they fast?
[20:06:59 CEST] <durandal117> ubitux: 4 times faster, 0.2 fps vs 0.8 fps
[20:08:46 CEST] <durandal117> ubitux: do you have an idea how to control blurring?
[20:31:08 CEST] <fritsch> Short development related questions. Some users had the idea to use flac encoder on DTS Wavs.
[20:31:13 CEST] <fritsch> What should one do with those? :-)
[20:31:30 CEST] <fritsch> Example: https://drive.google.com/file/d/0B1hx8qBTZtX5bExhMXJMaGtGNGc/view?usp=sharing
[20:32:06 CEST] <fritsch> it decodes totall fine to 16bit iec dts, but the moment audio processing does not know the content, sw volume and especially non capable DTS devices just will output noise
[20:32:20 CEST] <fritsch> open for good ideas :-)
[20:32:39 CEST] <fritsch> vlc, mpv, mplayer, all of them nicely output noise.
[20:35:56 CEST] <Chloe> ubitux: there's no rush really
[20:36:34 CEST] <Chloe> there wont really be any deprecation time either, as ffplay can either be sdl1 or sdl2
[20:37:18 CEST] <Chloe> I'll also update my other patches to remove the opengl and sdl1 outdevs instead of deprecating them
[20:38:09 CEST] <Chloe> or I could keep them as deprecated, and keep change sdl2 to be the default.
[20:38:11 CEST] <Chloe> what do you think?
[20:44:45 CEST] <ubitux> i think it's better to work incrementally :)
[20:45:32 CEST] <nevcairiel> fritsch: tell them to diaf rather quickly =p
[21:05:04 CEST] <wm4> what does that mean, flac encoder on dts wavs
[21:05:34 CEST] <wm4> dts wavs = .wav files with DTS data? (lavf probably can properly play them, not sure)
[21:06:33 CEST] <JEEB> yeah, it's a perverted thing that gained support for some reason
[21:06:39 CEST] <JEEB> I think it might be just PCM bitstreaming as-is?
[21:06:45 CEST] <JEEB> never cared enough to check
[21:07:01 CEST] <nevcairiel> pretty much DTS wavs which someone thought wo uld be a good idea to compress as flac
[21:07:07 CEST] <nevcairiel> so its DTS-in-FLAC
[21:07:16 CEST] <wm4> wait, flac encode the dts data?
[21:07:19 CEST] <durandal117> ubitux: increasing WEIGHTS_LUT_SIZE helps, this could be configurable
[21:07:23 CEST] <JEEB> ...
[21:07:24 CEST] <nevcairiel> yes
[21:07:31 CEST] <JEEB> you w0t m8t
[21:07:36 CEST] <JEEB> is all I can say
[21:07:38 CEST] <nevcairiel> for some reason thats a recurring idiocy
[21:07:41 CEST] <wm4> fritsch: use the kodi funds or whatever you have to hire a hitman?
[21:08:24 CEST] <durandal117> reference flac encoder does this?
[21:08:39 CEST] <nevcairiel> the encoder just thinks its wav data
[21:09:00 CEST] <wm4> yes, so decoding it reproduces the spdif-framed data
[21:09:14 CEST] <wm4> which an A/V receiver will pick up as passed-through DTS
[21:09:33 CEST] <wm4> it's perverse and illustrates what giant PITA multimedia is
[21:15:20 CEST] <rcombs> wm4: haven't I told you this story
[21:15:33 CEST] <rcombs> someone requested DTS-in-FLAC support in PMS a while back
[21:15:55 CEST] <rcombs> first time I ever told a user with a media-format handling request to shove off
[21:15:58 CEST] Action: JEEB facepalms even harder
[21:16:15 CEST] <wm4> heh
[21:16:51 CEST] <wm4> I wonder if DTS-in-IEC-in-FLAC is smaller than just DTS
[21:16:53 CEST] <rcombs> fritsch: I'd recommend telling the user to fuck off
[21:17:12 CEST] <rcombs> wm4: keep in mind it's almost certainly DTS-CD-sourced DTS
[21:17:20 CEST] <rcombs> which means every 14 bits are padded to 16
[21:17:20 CEST] <iive> and I wonder if flac manages to compress the .wav at all
[21:17:44 CEST] <wm4> oh god
[21:18:23 CEST] <rcombs> somebody decided to stick DTS on CDs, and that the best way to do that would be to make it identical to Red Book CDDA in every way
[21:18:35 CEST] <rcombs> someone else went "won't that destroy speakers if played on a regular CDDA player"
[21:18:42 CEST] <rcombs> and instead of rethinking their life choices, they added padding
[21:19:31 CEST] <wm4> so the higher bits are unset = noise played at lower volume?
[21:19:56 CEST] <rcombs> well, sign-extended
[21:19:59 CEST] <rcombs> but yeah
[21:20:04 CEST] <nevcairiel> thats why its 14-bits, so its not full volume
[21:20:39 CEST] <rcombs> also I'm told the reason people have stuck that in FLAC is because you can tag FLAC
[21:20:50 CEST] <JEEB> lol
[21:21:20 CEST] <rcombs> I think WAV can do all the same tagging stuff but I guess people had software that already worked with FLAC and went "problem solved"
[21:21:27 CEST] <rcombs> (20 more problems created)
[21:21:37 CEST] <nevcairiel> wav taking varies wildly
[21:21:47 CEST] <rcombs> fortunately those people are so insane I'm perfectly comfortable telling them to fuck off with their awful format
[21:21:50 CEST] <nevcairiel> some shove a id3 in there, some try to use the native tags
[21:25:54 CEST] <iive> so flac manages to actually compress the dts, because it uses 14 out of 16 bits... genius
[21:27:21 CEST] <rcombs> also for some reason people decided that players should handle the 14->16 conversion
[21:27:27 CEST] <rcombs> instead of ripping software
[21:27:42 CEST] <rcombs> for the sake of being able to use CDDA ripping tools
[21:28:46 CEST] <JEEB> lol
[21:29:26 CEST] <wm4> so A/V receivers understand 14-bit DTS?
[21:29:57 CEST] <iive> probably, because they are made to get the format from cd directly
[21:30:20 CEST] Action: rcombs shrugs
[21:32:17 CEST] <iive> btw, does this apply to dts only? aka is there the same thing with ac3/51/dd ?
[21:32:22 CEST] <wm4> in theory it would be easily possible to support this format by adding extra probing-via-decoding to libavformat/utils.c
[21:32:38 CEST] <wm4> and having a decoder which chains the flac and dts decoders
[21:34:01 CEST] <rcombs> iive: afaik this only exists in DTS
[21:34:10 CEST] <rcombs> mostly because people never crammed AC3 in CDDA
[21:34:26 CEST] <rcombs> wm4: pls no
[21:34:31 CEST] <rcombs> don't encourage them
[21:35:16 CEST] <wm4> satan wills it
[21:35:53 CEST] <durandal117> it's bug
[21:36:32 CEST] <fritsch> rcombs: am I allowed to cite you?
[21:36:37 CEST] <rcombs> sure
[21:36:45 CEST] <rcombs> "fuck you" -- rcombs 2016
[21:36:55 CEST] <fritsch> wm4: I want to cite your hitman statement, too :-)
[21:37:06 CEST] <iive> i think ffmpeg should be able to unpack the mess and write proper dts.
[21:37:22 CEST] <rcombs> iive: why tho
[21:38:13 CEST] <iive> in order to fix the files..
[21:38:56 CEST] <iive> well, is there a bitstream filter that can unpack the 14bit dts?
[21:41:31 CEST] <rcombs> the decoder handles it
[21:42:22 CEST] <iive> that's not the point. The steam could be 1/7 smaller.
[21:42:40 CEST] <rcombs> as does the DTS raw demuxer
[21:43:00 CEST] <fritsch> I really don't to start interpreting decoded flac content
[21:43:07 CEST] <fritsch> and search for dts preambles in there ...
[21:43:11 CEST] <fritsch> and I won't do that
[21:43:25 CEST] <fritsch> it worked by luck, but now we had a call to sws_set_compensation in there
[21:43:33 CEST] <fritsch> and yeah :-) that "broke" it
[21:43:41 CEST] <iive> rcombs: but the dts raw demuxer won't be used for .wav file?
[21:44:03 CEST] <rcombs> iive: either decode, or demux to raw and remux from there
[21:44:12 CEST] <rcombs> this is such a ridiculous edge case for stupid files
[21:44:16 CEST] <JEEB> also this reminds me of a capture card file format that I've been poking which was used to capture DTV in Japan before people could nicely get the MPEG-TS
[21:44:28 CEST] <JEEB> so you had captured video and bitstreamed AAC
[21:44:47 CEST] <JEEB> and then you have the game capture footage that actually contains "normal" PCM there
[21:45:06 CEST] <JEEB> fixing one is simple, getting both to work is... welp
[21:46:26 CEST] <iive> rcombs: so if i ever get this flac, i'd have to decode it first to .wav, then stream copy it to raw.dts and then stream copy it again to whatever i want. 
[21:46:50 CEST] <rcombs> iive: decode to raw stereo PCM
[21:47:04 CEST] <rcombs> rename to .dts
[21:47:14 CEST] <rcombs> (or don't, since lavf doesn't care about extensions anyway)
[21:47:18 CEST] <fritsch> iive: better don't decode it - and only play it without touching it on AVRs
[21:47:19 CEST] <durandal117> just listen noise
[21:47:37 CEST] <fritsch> funny sidenote: you can disable all passthrough special handling, if your "decoder output chain" is bitperfect
[21:47:41 CEST] <fritsch> it will signal DTS to your AVR
[21:47:50 CEST] <fritsch> and this is the only bug - we from kodi accept - from this user :-)
[21:48:02 CEST] <fritsch> we should not call sws_set_compensation if it's not needed
[21:50:39 CEST] <wm4> fritsch: feel free to, but don't let the press know
[21:50:57 CEST] <fritsch> hehe
[21:51:02 CEST] <fritsch> press: phoronix? :-)
[21:51:26 CEST] <fritsch> it has one good thing
[21:51:29 CEST] <wm4> what if the user is a certain 0 pointer
[21:51:35 CEST] <fritsch> we will keep that file and test our "bit perfectness" in the future
[21:51:50 CEST] <fritsch> wm4: i don't care
[21:51:56 CEST] <fritsch> shit in, shit out
[21:52:06 CEST] <fritsch> but he found a bug in our audio decoding -> output chain
[21:52:15 CEST] <fritsch> that's good and this bug we accept
[21:52:31 CEST] <fritsch> I rather write the decoder to log out: Sorry, you did it wrong ...
[21:54:15 CEST] <rcombs> (certain 0 pointer?)
[21:54:47 CEST] <fritsch> the only 0 pointer I know is the systemd author (he has this web domain) and has certainly nothing to do with that flac file
[21:55:13 CEST] <fritsch> http://0pointer.net/blog/
[21:56:02 CEST] <rcombs> 0x0.st?
[21:56:31 CEST] <rcombs> does lachs0r collect stupid audio now
[21:58:22 CEST] <ubitux> durandal117: or i need to find a way to scale it more intelligibly
[21:59:36 CEST] <wm4> someone once made a joke to hire a hitman because of systemd or something
[21:59:52 CEST] <fritsch> that was no joke - and that was sad in that regard
[22:00:10 CEST] <fritsch> i did not find it funny at all
[22:23:08 CEST] <durandal117> can i get useful results with gprof and shared build?
[22:56:08 CEST] <Chloe> durandal117: switch indentation is case is the same level as the switch, right?
[22:59:38 CEST] <durandal117> Chloe: yes
[23:01:54 CEST] <Chloe> durandal117: ok I've fixed the indentation
[23:03:59 CEST] <durandal117> Chloe: great
[23:07:02 CEST] <Chloe> does anyone know if sdl2 would need -mconsole with mingw?
[23:08:48 CEST] <Chloe> hmm, looking at the other patch's email, probably? I guess it's the same
[23:11:06 CEST] <nevcairiel> sdl is kinda annoying because its pkgconfig file adds -mwin which makes stdout/stderr go away, yeah
[23:11:11 CEST] <nevcairiel> so if sdl2 still does that
[23:13:02 CEST] <Chloe> what happens if it doesnt add -mwin? would -mconsole affect it?
[23:13:33 CEST] <nevcairiel> console should be the default if nothing is specified
[23:14:50 CEST] <Chloe> hopefully v6 will be ok ¯\_(Ä)_/¯ 
[23:21:44 CEST] <cone-727> ffmpeg 03Michael Niedermayer 07master:cb114ed46406: avformat/mux: implement AVFMT_FLAG_SHORTEST
[00:00:00 CEST] --- Mon Sep 12 2016