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

[burek]

[00:02:18 CEST] <BtbN> sounds like a good ticket, without even opening it
[00:02:55 CEST] <BtbN> yep
[00:05:48 CEST] <iive> no -dev ?
[00:06:09 CEST] <BtbN> ffmpeg with fdk enables is non-free and non-redistributable.
[00:06:16 CEST] <BtbN> So apt-get won't download it
[00:06:28 CEST] <BtbN> At least it shouldn't.
[00:06:33 CEST] <BtbN> I know on some distros it still does.
[00:06:54 CEST] <BtbN> nevcairiel, don't even need to create any libva shim
[00:07:00 CEST] <BtbN> at least it does get that one right
[00:07:03 CEST] <iive> oh, i thought configure is the one that does not recognize fdk
[00:07:21 CEST] <wm4> BtbN: referring to va trace support?
[00:07:24 CEST] <BtbN> That's one hell of a trace log though
[00:07:24 CEST] <BtbN> yes
[00:07:33 CEST] <BtbN> 5 seconds of decoding with gst
[00:07:38 CEST] <BtbN> 4GB of trace log
[00:07:41 CEST] <nevcairiel> haha
[00:07:55 CEST] <nevcairiel> did it dump the entire bitstream buffers in there too?
[00:07:57 CEST] <iive> :O
[00:08:01 CEST] <BtbN> yes, base64 encoded
[00:08:13 CEST] <BtbN> multiple times aparently
[00:08:18 CEST] <wm4> actually sounds pretty nice
[00:08:25 CEST] <wm4> I hope there's a way to replay a log too
[00:08:31 CEST] <nevcairiel> my dxva shim has that as an optional mode, but i turned that off by default since thats just soo much data
[00:08:54 CEST] <BtbN> ah, you can get rid of the actual bitstream data
[00:08:57 CEST] <BtbN> that looks more usefull
[00:09:10 CEST] <BtbN> https://bpaste.net/show/2c628a7147cd
[00:09:21 CEST] <BtbN> that's from gst
[00:11:07 CEST] <BtbN> And that ffmpeg via mpv: https://bpaste.net/show/806c332a414c
[00:12:17 CEST] <nevcairiel> you're sending empty scaling lists, that can probably be optimized
[00:12:28 CEST] <nevcairiel> and slice_data_byte_offset  is one too big :D
[00:12:35 CEST] <BtbN> nah, it varies
[00:12:40 CEST] <BtbN> the difference
[00:13:01 CEST] <BtbN> second frame is 14 vs. 16
[00:13:14 CEST] <nevcairiel> maybe there actually are emulation bytes in those headers
[00:13:43 CEST] <BtbN> ffmpeg has allways 1 or 2 bytes too much
[00:14:30 CEST] <nevcairiel> every escape adds one byte
[00:14:48 CEST] <nevcairiel> because it escapes a double zero as 00 00 03
[00:14:51 CEST] <BtbN> the scaling lists are broken though
[00:14:57 CEST] <BtbN> the tracer thinks it's h264
[00:15:20 CEST] <nevcairiel> should just not send any if not required
[00:15:32 CEST] <nevcairiel> gst doesnt seem t o
[00:16:26 CEST] <BtbN> I guess i only need to send the entire buffer if scaling_list_enable_flag is enabled?
[00:16:32 CEST] <nevcairiel> yes
[00:17:38 CEST] <nevcairiel> your column_width_minus1 and row_height_minus1 seem to be screwed up
[00:18:32 CEST] <nevcairiel> everything else looks fine, sans the byte offset
[00:18:57 CEST] <BtbN> the logic for the scaling lists is also screwed
[00:19:04 CEST] <BtbN> i missed there's one in both sps and pps
[00:19:18 CEST] <nevcairiel> that was broken in dxva for a while too
[00:19:24 CEST] <nevcairiel> took me a while to understand how it works
[00:20:04 CEST] <nevcairiel> and collocated_from_l0_flag is wrong .. whatever that is
[00:20:55 CEST] <BtbN> https://github.com/gbeauchesne/gstreamer-vaapi/blob/master/gst-libs/gst/vaapi/gstvaapidecoder_h265.c#L1220
[00:21:01 CEST] <BtbN> I'll shamelessly use that logic.
[00:22:20 CEST] <philipl> BtbN: do you need to handle start codes properly? vdpau needs you prepend start codes to the slices when submitting them (which ffmpeg strips off). It's trivial but I wonder what vaapi wants
[00:22:47 CEST] <BtbN> That's handled by the common vaapi code
[00:22:51 CEST] <BtbN> and i hope it does it correctly
[00:22:51 CEST] <nevcairiel> that looks more complex than what i do
[00:43:34 CEST] <cone-614> ffmpeg 03Ganesh Ajjanagadde 07master:060102389e57: configure: do not fork off grep subprocess in probe_cc
[00:48:28 CEST] <BtbN> Soo, most of that stuff should be sorted out now. Except for the offset
[00:48:46 CEST] <BtbN> And not sure about the col/row width/height
[00:54:05 CEST] <philipl> Why's that tricky? It was straight forward for vdpau
[00:55:31 CEST] <BtbN> Looks right now
[00:55:38 CEST] <BtbN> the buffer just wasn't zero initialized for some reason
[00:55:44 CEST] <BtbN> that's where the garbage came from
[00:56:21 CEST] <BtbN> It's https://bpaste.net/show/2c628a7147cd (gst) vs. https://bpaste.net/show/9485a5e009be (mpv+ffmpeg) now.
[00:56:28 CEST] <BtbN> It's getting harder to spot differences
[00:57:24 CEST] <philipl> and yet. So hard coding the offset doesn't get you even one frame?
[00:57:43 CEST] <BtbN> It's not hardcoded. I just adjusted the offset so the first frame is right.
[00:57:55 CEST] <philipl> So you do see the first frame?
[00:58:02 CEST] <BtbN> I'm getting clean nothing now
[00:58:12 CEST] <philipl> is the first frame all black :-)
[00:58:16 CEST] <philipl> in the source
[00:58:25 CEST] <BtbN> nothing == what was there on the screen before
[00:58:27 CEST] <BtbN> not black
[00:58:32 CEST] <philipl> ah.
[01:00:14 CEST] <BtbN> Hm, i got an idea for a horrible hack.
[01:00:31 CEST] <BtbN> It seems like the offset is + 1 for I slices. And + 0 for the other ones.
[01:01:11 CEST] <philipl> haha.
[01:02:12 CEST] <BtbN> slice_param->slice_data_byte_offset = (get_bits_count(&h->HEVClc->gb) + 7) / 8 + ((sh->slice_type == I_SLICE) ? 1 : 0);
[01:02:19 CEST] <BtbN> totaly reasonable.
[01:08:49 CEST] <philipl> works for > 0 sample files: ship it.
[01:22:14 CEST] <BtbN> yes!
[01:22:24 CEST] <BtbN> that actualy makes it do _something_
[01:25:48 CEST] <philipl> something visually recognisable?
[01:26:50 CEST] <philipl> gstreamer has added native nvenc support. I wonder how they are interpreting the licence situation.
[01:27:42 CEST] <BtbN> Yes, definitely.
[01:27:49 CEST] <BtbN> No idea how to show it though
[01:28:00 CEST] <BtbN> wm4, any way for mpv to dump the decoded stream?
[01:28:00 CEST] <philipl> how to show it? Take a screenshot?
[01:31:12 CEST] <BtbN> A screenshot wouldn't be too usefull i think
[01:33:11 CEST] <philipl> Time to write ffmpeg_vaapi.c :-)
[01:33:28 CEST] <BtbN> Nah
[01:33:41 CEST] <BtbN> Pointing my phone at the screen will have to do for now
[01:34:01 CEST] <BtbN> not enough power to live-encode the screen
[01:35:22 CEST] <BtbN> I can't spot any differences in the parameters anymore though
[01:35:51 CEST] <philipl> Are the bytes actually the same, being submitted?
[01:36:05 CEST] <philipl> Might still be not offset right due to ffmpeg pre-processing stuff
[01:37:09 CEST] <BtbN> It definitely is right, the results are too good for it to be wrong
[01:40:47 CEST] <wm4> BtbN: --vo=image
[01:41:24 CEST] <wm4> or maybe --vo=image:format=png
[01:41:47 CEST] <wm4> also, with ffmpeg_vaapi.c I'd wait until the new API (hopefully) comes into existence
[01:42:06 CEST] <BtbN> It's already merged?
[01:42:12 CEST] <BtbN> Or is there more in the works?
[01:43:13 CEST] <wm4> there were some initial patches, but it'll probably take a while
[01:43:51 CEST] <wm4> apparently the plan is to include surface allocation in lavc tool, so it's significant
[01:47:06 CEST] <wm4> maybe ask gb whether it's worth writing a ffmpeg_vaapi.c now
[01:47:48 CEST] <philipl> Try and get him to volunteer :-)
[01:47:54 CEST] <philipl> Definitely the most qualified person.
[01:47:58 CEST] <BtbN> https://btbn.de/files/screencap_comp.mkv
[01:48:30 CEST] <philipl> Did you encode it with hevc? :-)
[01:48:36 CEST] <BtbN> no
[01:52:01 CEST] <philipl> interesting.
[01:52:13 CEST] <philipl> Does the file use tiles?
[01:52:25 CEST] <BtbN> no idea
[01:52:28 CEST] <philipl> But I assume your tiling params are all the same.
[01:53:27 CEST] <philipl> You should still double check the buffers being submitted are actually the same bytes and same buffer size in both cases.
[01:53:30 CEST] <philipl> Just make sure.
[01:53:44 CEST] <wm4> I love how broken video looks
[01:53:59 CEST] <BtbN> the buffer sizes are same, they are included in the parameter set
[01:54:37 CEST] <philipl> so just a question of the bytes themselves
[01:55:11 CEST] <BtbN> I'll do a new trace, maybe i'm missing something
[01:55:32 CEST] <philipl> You're certainly getting close.
[01:59:41 CEST] <BtbN> https://btbn.de/files/va_trace.log.gst https://btbn.de/files/va_trace.log.ffmpeg
[02:00:57 CEST] <BtbN> It's amazing that this byte offset calculation is so reliable
[02:01:07 CEST] <BtbN> it's correct on all my sample files
[02:02:02 CEST] <BtbN> wait, no. It's not.
[02:02:04 CEST] <BtbN> hmm
[02:02:18 CEST] <BtbN> So then it might actualy be the only thing that's still missing
[02:03:46 CEST] <BtbN> yes, if i'm not completely mistaken, it's 100% identical, except for that offset
[02:23:25 CEST] <llogan> i don't understand that ticket
[03:04:10 CEST] <cone-614> ffmpeg 03Lukasz Marek 07master:d39a9b01e285: lavf/file: implement directory listing callbacks
[03:04:11 CEST] <cone-614> ffmpeg 03Mariusz SzczepaDczyk 07master:1f4c62e84e58: lavf/file: check for dirent.h support
[03:31:14 CEST] <philipl> BtbN: so close!
[03:31:53 CEST] <philipl> might have to implement that offset tracker i suggested.
[05:29:00 CEST] <Timothy_Gu> BtbN: for the first frame gst has five_minus_max_num_merge_cand = 0 but ffmpeg has 5
[05:29:06 CEST] <Timothy_Gu> does that matter
[05:29:07 CEST] <Timothy_Gu> ?
[10:30:33 CEST] <durandal_1707> rewiew vstack and hstack please!
[10:34:29 CEST] <wm4> durandal_1707: I question why they're needed at all... in an ideal world, there'd be a single video mixer filter, which can recombine and relayout inputs in arbitrary ways, and hstack/vstack would be simple functions setting up this filter... but maybe I'm thinking too far ahead here
[10:49:33 CEST] <BtbN> Timothy_Gu, I'll check that, thanks.
[10:51:50 CEST] <nevcairiel> could probably build some evil hackery to manually go through the raw bitstream, keeping track of how many escapes you find until the byte count matches what you think it should be
[10:52:46 CEST] <nevcairiel> what I dont understand however ... why does the gst code subtract the number of emulation bytes? I thought it would need to add them? o.o
[10:53:57 CEST] <nevcairiel> ok reading the docs again, it seems the emulation bytes are of no consequence
[10:54:01 CEST] <nevcairiel> there must be something else wrong
[10:54:31 CEST] <durandal_1707> wm4: how would syntax look like?
[10:58:15 CEST] <wm4> durandal_1707: it'd require a scripting language
[11:03:55 CEST] <nevcairiel> BtbN: after re-checking the vaapi spec and our code, theoretically just get_bits_count(&h->HEVClc->gb) should give you the correct value, but thats obviously not working
[11:06:47 CEST] <durandal_1707> wm4: same filters are in avisynth and vapoursynth, just longer name
[11:11:20 CEST] <BtbN> nevcairiel, even if the value is diffrent from what gst passes for the same data?
[11:12:06 CEST] <nevcairiel> obviously its "wrong" somehow, but the spec says its wants the number of bytes without emulation prevention, nal unit header and slice header
[11:12:09 CEST] <nevcairiel> which this would be..
[11:14:59 CEST] <nevcairiel> if i look at your latest dumps, the first frame is one too big, which i would account for your +1 condition t here
[11:15:41 CEST] <BtbN> Yeah. I don't think i ever tried + 0 since i fixed all the other stuff.
[11:16:42 CEST] <nevcairiel> just from the parsing code in hevc.c, it should just be the rounded get_bit_count thingy .. no guarantees however =p
[11:17:41 CEST] <BtbN> So, + 7 ) / 8, like i'm doing right now? Or some other rounding?
[11:17:48 CEST] <nevcairiel> yea
[11:17:58 CEST] <nevcairiel> just that
[11:19:02 CEST] <nevcairiel> the gb context gets created right on the start of the NAL, then the 16 bits nal unit header get read, and all of the slice header, at the point the slice hwaccel is called, it sits right before the slice data, which would be the next thing it would parse if it wouldnt use hwaccel
[11:19:16 CEST] <nevcairiel> so in theory, that should be exactly what it wants
[11:23:10 CEST] <BtbN> It's also interesting that five_minus_max_num_merge is indeed wrong for the first frame. Assuming gst gets it right. But right for all later frames.
[11:23:31 CEST] <BtbN> slice_param->five_minus_max_num_merge_cand = 5 - sh->max_num_merge_cand;
[11:23:36 CEST] <BtbN> seems right to me
[11:23:54 CEST] <BtbN> also from looking how it's parsed, this should be right
[11:24:29 CEST] <nevcairiel> sh->max_num_merge_cand = 5 - get_ue_golomb_long(gb);
[11:24:46 CEST] <nevcairiel> the value would appear to already be "5 - max_num_merge_cand", wouldnt it
[11:25:29 CEST] <BtbN> No, the get_ue_golomb_long(gb) returns the value "five_minus_max_num_merge_cand"
[11:25:38 CEST] <BtbN> 5 - five_minus_max_num_merge_cand == max_num_merge_cand
[11:26:37 CEST] <nevcairiel> hm right
[11:26:40 CEST] <nevcairiel> my head is still asleep
[11:27:12 CEST] <nevcairiel> max_num_merge_cand is only set on  B/P slices though
[11:27:40 CEST] <BtbN> Oh, so i should just set it to 0 when it's an I slice
[11:27:45 CEST] <nevcairiel> dunno
[11:27:46 CEST] <nevcairiel> maybe?
[11:27:47 CEST] <nevcairiel> :D
[11:28:10 CEST] <nevcairiel> ideally the accelerator shouldnt even look at the value if its an I slice and differences wouldnt matter
[11:29:27 CEST] <BtbN> It's vaapi.
[11:30:28 CEST] <nevcairiel> 5 is an invalid value in any case, it should be 0-4 for the valid range (so the resulting max_num_merge_cand is 1-5)
[11:33:54 CEST] <BtbN> Just noticed, all this stuff doesn't show up in the trace dump: https://github.com/BtbN/FFmpeg/blob/vaapi_hevc/libavcodec/vaapi_hevc.c#L405
[11:34:41 CEST] <BtbN> could also be a source for distortion
[11:36:00 CEST] <nevcairiel> reading of those is slightly complex, so it may not be exactly the values it expects
[11:36:53 CEST] <nevcairiel> because luma_weight_l0 is not delta_luma_weight_l0
[11:37:00 CEST] <nevcairiel> it gets computed based on delta_luma_weight_l0
[11:37:17 CEST] <nevcairiel> s->sh.luma_weight_l0[i] = (1 << s->sh.luma_log2_weight_denom) + delta_luma_weight_l0;
[11:37:23 CEST] <nevcairiel> seems reversible, though
[11:49:32 CEST] <cone-292> ffmpeg 03Mariusz SzczepaDczyk 07n2.4.11:HEAD: lavf/file: check for dirent.h support
[11:55:27 CEST] <BtbN> nevcairiel, it's almost good now.
[11:56:08 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/b021c4bf577453c74bd2d41e2367d44ae0dedebf
[11:56:24 CEST] <BtbN> this did the trick. So aparently that single value can't be that unimportant.
[12:05:07 CEST] <nevcairiel> so the weightings were not a big problem so far?
[12:06:11 CEST] <BtbN> No idea. The distortion that's left could very well come from the still not 100% correct offset
[12:06:29 CEST] <BtbN> https://bpaste.net/show/8975bbe7080c (gst) vs. https://bpaste.net/show/bdf0c23cdf21 (ffmpeg)
[12:07:12 CEST] <nevcairiel> its very few frames, so that should be possible to spot the differences
[12:08:05 CEST] <BtbN> But adding an offset based on some magic flags beeing set doesn't seem like a good solution
[12:08:51 CEST] <cone-292> ffmpeg 03Carl Eugen Hoyos 07master:91619d195b37: lavf/dnxhd: Autodetect more valid files.
[12:09:58 CEST] <nevcairiel> there is a byte_alignment struct which is always at least one bit, which we dont seem to read here
[12:13:11 CEST] <cone-292> ffmpeg 03Paul B Mahol 07master:1b1c4030ea86: fate: add tests for vectorscope filter
[12:14:09 CEST] <nevcairiel> although i wonder why that wouldnt be a problem with software decoding then =p
[12:20:17 CEST] <nevcairiel> i think that may explain it, what you could do is always add +1 to the bit_size before doing the +7 / 8 dance
[12:20:28 CEST] <nevcairiel> because there is one bit of the byte_alignment struct always present
[12:20:37 CEST] <nevcairiel> no idea where the software decoder handles that though
[12:20:39 CEST] <nevcairiel> couldnt find it
[12:20:48 CEST] <BtbN> Strange. Is it allways exactly one bit?
[12:20:58 CEST] <nevcairiel> no
[12:21:02 CEST] <nevcairiel> its at least one bit
[12:21:09 CEST] <nevcairiel> and then x bits until its byte alignment
[12:21:23 CEST] <BtbN> so + 1 + 7 should allways do the trick
[12:21:51 CEST] <nevcairiel> not sure why they did it that way, and not just only add bits when alignment is needed
[12:22:25 CEST] <nevcairiel> http://lists.freedesktop.org/archives/gstreamer-commits/2015-April/086692.html
[12:22:30 CEST] <nevcairiel> they do that too :p
[12:22:50 CEST] <nevcairiel> now i'm really curious where the ffmpeg decoder handles these
[12:23:10 CEST] <BtbN> Maybe it doesn't, and just happens to work because of some coincidence
[12:26:37 CEST] <BtbN> yes, that did the trick. Decodes flawlessly now. Awesome.
[12:28:12 CEST] <nevcairiel> apparently the alignment is processed in the cabac init
[12:28:15 CEST] <nevcairiel> how annoying
[12:28:47 CEST] <nevcairiel>     skip_bits(gb, 1);
[12:28:47 CEST] <nevcairiel>     align_get_bits(gb);
[12:28:51 CEST] <nevcairiel> looks suspicious =p
[12:29:17 CEST] <nevcairiel> should add a comment why its +1 in your code then
[12:29:52 CEST] <BtbN> The 4K sample fails to decode though. Propably too much for the hardware
[12:31:12 CEST] <nevcairiel> what kind of cpu is it?
[12:31:24 CEST] <nevcairiel> skylakes hardware decoder should do 4k
[12:32:07 CEST] <BtbN> Pentium N3700
[12:32:43 CEST] <nevcairiel> oh its an atom
[12:33:04 CEST] <nevcairiel> no clue about their hardware decoding capabilities
[12:33:05 CEST] <BtbN> It's a NUC
[12:33:19 CEST] <nevcairiel> they have i5 NUCs as well, so yeah
[12:33:26 CEST] <BtbN> Not for Baytrail
[12:33:29 CEST] <BtbN> yet
[12:33:59 CEST] <BtbN> hm, gst playbin plays the 4K sample perfectly fine
[12:34:20 CEST] <nevcairiel> trace time!
[12:34:22 CEST] <nevcairiel> ;)
[12:35:17 CEST] <nevcairiel> may just use another feature that you still have a bug in
[12:35:22 CEST] <nevcairiel> say, like, scaling lists
[12:36:38 CEST] <BtbN> yeah, propably some feature the smaller samples didn't use
[12:37:12 CEST] <nevcairiel> man github is slow today
[12:37:28 CEST] <BtbN> yes, it just hang for a minute while pushing
[12:42:36 CEST] <BtbN> I also still wonder if there's a better, more efficient, way to do this: https://github.com/BtbN/FFmpeg/blob/vaapi_hevc/libavcodec/vaapi_hevc.c#L69
[12:42:47 CEST] <BtbN> iterating over the rps lists doesn't seem ideal.
[12:51:59 CEST] <BtbN> parameters for the 4K clip are 100% the same from gst and ffmpeg
[12:59:26 CEST] <BtbN> No idea why the 4K clip is failing, i think it's unlikely that it's caused by the hevc parameters
[13:00:43 CEST] <BtbN> mpv with --hwdec=vaapi-copy gets it done
[13:00:53 CEST] <BtbN> but at 7 fps
[13:01:12 CEST] <nevcairiel> so the decode works, just the direct rendering fails?
[13:01:17 CEST] <BtbN> aparently
[13:01:27 CEST] <nevcairiel> well thats good then
[13:01:30 CEST] <nevcairiel> your job is done =p
[13:01:59 CEST] <BtbN> both kodi and mpv fail at it though
[13:02:12 CEST] <BtbN> gst playbin works flawlessly
[13:02:15 CEST] <nevcairiel> does 4k h264 work?
[13:02:23 CEST] <nevcairiel> otherwise its just a 4k rendering problem
[13:02:26 CEST] <BtbN> no idea, i don't have a sample for that. One second
[13:05:04 CEST] <BtbN> amazing sample server there, kodi
[13:05:09 CEST] <BtbN> 100kB/s
[13:06:08 CEST] <wm4> BtbN: for mpv, you can try --hwdec=vaapi-copy if you didn't already (just copies back the data to CPU)
[13:06:31 CEST] <BtbN> <BtbN> mpv with --hwdec=vaapi-copy gets it done
[13:06:36 CEST] <wm4> oh ok
[13:06:51 CEST] <BtbN> But way too slow obviously
[13:07:18 CEST] <nevcairiel> BtbN: if kodi is way slow, this should be much faster, since i host that, http://xhmikosr.1f0.de/samples/2160p/CrowdRun/CrowdRun_2160p50.x264.CRF25.mkv
[13:07:26 CEST] <wm4> try --vo=vaapi too (but probably won't help)
[13:08:10 CEST] <BtbN> vo=vaapi just gives a black screen
[13:08:28 CEST] <BtbN> and drops a lot(propably all) of frames
[13:08:34 CEST] <wm4> fun
[13:08:51 CEST] <BtbN> the h264 4K sample plays fine with vo=vaapi
[13:09:13 CEST] <nevcairiel> weird
[13:09:47 CEST] <wm4> maybe it has something to do with surface allocation?
[13:10:12 CEST] <cone-292> ffmpeg 03Michael Niedermayer 07master:d65b9114f35c: avformat/file: Check for lstat() instead of dirent.h
[13:12:24 CEST] <BtbN> https://btbn.de/files/va_trace.log.bbb.gst.txt https://btbn.de/files/va_trace.log.bbb.ffmpeg.txt
[13:12:42 CEST] <BtbN> Looks 100% identical to me. At least regarding the pic and slice params
[13:14:08 CEST] <BtbN> fatal: unable to access 'https://github.com/BtbN/FFmpeg.git/': Failed to connect to github.com port 443: Connection timed out
[13:14:10 CEST] <BtbN> gj github
[13:14:32 CEST] <BtbN> oh, DDoS Attack
[13:15:46 CEST] <nevcairiel> you create twice as many surfaces
[13:15:51 CEST] <nevcairiel> for some reason
[13:16:16 CEST] <nevcairiel> 9 vs 22
[13:16:24 CEST] <nevcairiel> maybe it runs out of memory?
[13:17:12 CEST] <BtbN> very possible
[13:17:27 CEST] <BtbN> the amount of surfaces created isn't decided by ffmpeg though
[13:17:44 CEST] <BtbN> 22 4K surfaces is quite a bit of memory
[13:18:05 CEST] <nevcairiel> well not that much
[13:18:07 CEST] <nevcairiel> 300mb or so
[13:18:12 CEST] <wm4> vaapi requires all surfaces to be allocated in advance
[13:18:31 CEST] <wm4> although in practice most drivers don't require this at all
[13:18:36 CEST] <wm4> (or well, the Intel driver doesn't)
[13:20:08 CEST] <wm4> BtbN: maybe this this on mpv http://sprunge.us/PSgi
[13:20:18 CEST] <BtbN> kodi re-allocates them on the go if it runs out at runtime
[13:21:17 CEST] <wm4> yep that's probably the most reasonable way, but possibly also a bit fishy due to the interaction with lavc
[13:24:49 CEST] <wm4> is this issue still going on
[13:34:14 CEST] <BtbN> wm4, how does the vaapi renderer work? Is it using the glx interop, or some other interface?
[13:34:16 CEST] <BtbN> in mpv
[13:35:05 CEST] <wm4> --vo=vaapi uses the "native" video output API which barely works (vaPutSurface on a X11 window)
[13:35:37 CEST] <wm4> --vo=opengl currently uses X11/OpenGL interop, which uses vaPutSurface on a pixmap, which is mapped as OpenGL texture
[13:36:05 CEST] <wm4> and --hwdec=vaapi-copy just uses vaGetImage()
[13:36:54 CEST] <wm4> or maybe it accesses it directly via vaDeriveImage() (it's confusing)
[13:37:19 CEST] <wm4> gst might use the newer EGL interop API (but I'm not sure how new that API is - I think kodi recently gained support for it)
[13:37:44 CEST] <cone-292> ffmpeg 03Carl Eugen Hoyos 07master:83a508cda511: lavf/segment: Fix memleak.
[13:38:58 CEST] <BtbN> kodi also uses EGL
[13:39:03 CEST] <BtbN> and also fails to play the 4K sample
[13:39:27 CEST] <wm4> so the question is what does GST use
[13:39:42 CEST] <wm4> (doesn't sound like it's necessarily easy to answer)
[13:52:56 CEST] <BtbN> for fritsch, 4K playback works fine. With the same sample i am testing, on a lower end CPU/GPU.
[13:53:27 CEST] <wm4> different drivers?
[13:53:38 CEST] <BtbN> We're both using libva 1.6.0
[13:53:39 CEST] <wm4> same kodi version?
[13:53:58 CEST] <BtbN> But at least it's not a problem with the ffmpeg code.
[13:54:02 CEST] <BtbN> So i can send the patch
[13:54:03 CEST] <nevcairiel> the actual gpu driver may have a bigger influence than  libva
[13:54:25 CEST] <BtbN> We're both using some 4.1 kernel
[13:54:30 CEST] <BtbN> there shouldn't be much of a difference
[13:55:04 CEST] <BtbN> https://dl.dropboxusercontent.com/u/55728161/2015-08-25-135242_1920x1080_scrot.png
[14:06:45 CEST] <BtbN> Great, my desktop can't git send-email for some reason.
[14:11:02 CEST] <Compn> you set git up with your email  and email server ?
[14:11:13 CEST] <BtbN> yes
[14:11:27 CEST] <Compn> gave git permission in the firewall to send email
[14:11:32 CEST] <BtbN> same config as on my other PCs
[14:11:34 CEST] <BtbN> where it works
[14:11:46 CEST] <BtbN> I get some strange SSL errors
[14:11:58 CEST] <Compn> does your sendmail have ssl ?
[14:12:02 CEST] <BtbN> sure
[14:12:03 CEST] <Compn> computer time set correctly
[14:12:12 CEST] <BtbN> git directly does smtp
[14:12:17 CEST] <BtbN> no local sendmail involved
[14:12:29 CEST] <Compn> i mean, your git has ssl correct
[14:12:33 CEST] <Compn> finding the libs correctly
[14:12:42 CEST] <Compn> strace on git send email
[14:12:44 CEST] <BtbN> yes, i get some errors from openssl
[14:12:50 CEST] <Compn> probably update openslsl
[14:13:24 CEST] <BtbN> https://bpaste.net/show/e1be41827258
[14:13:59 CEST] <BtbN> My HTPC with the same git and openssl versions could send the mail just fine
[14:15:17 CEST] <Compn> you can resolve the mail server from that desktop box ?
[14:16:37 CEST] <Ping> I have a question about making a custom build of FFmpeg... Am I in the right place, or should I go to #ffmpeg? 
[14:16:53 CEST] <BtbN> Yes, thunderbird works fine here.
[14:17:02 CEST] <BtbN> Just something strange going on with perl and ssl
[14:17:40 CEST] <Compn> Ping : you should ask in #ffmpeg unless you are developing some new code for this project...
[14:17:52 CEST] <Ping> Will do. Thank you
[14:29:32 CEST] <nevcairiel> BtbN: the weighting table still seems wrong judging from the code and the comments in the va header, but apparently nothing really cares about that? maybe fate would fail, if we had a vaapi ffmpeg module to test it =p
[14:30:37 CEST] <BtbN> https://dl.dropboxusercontent.com/u/46848344/hevc/birds_1080p_24fps_h265.mkv might expose that
[14:30:44 CEST] <BtbN> it has its colors entirely broken
[14:30:53 CEST] <BtbN> but gst refuses to play the file at all, so maybe it's just broken
[14:31:01 CEST] <BtbN> ffplay plays it fine
[14:32:51 CEST] <BtbN> nevcairiel, you mean the delta_luma_weight_l0 stuff, right?
[14:32:56 CEST] <nevcairiel> yes
[14:33:07 CEST] <BtbN> For some reason in ffmpeg those are int16 and have 16 fields
[14:33:20 CEST] <BtbN> in libva they are int8 and have 15 fields
[14:34:21 CEST] <nevcairiel> the values stored in the slice header are processed, so it may as well be the reason it needs more space to store them
[14:36:25 CEST] <BtbN> Hm, i could just add some fields in the hevc headers to store the original values. Or reverse the processing it does on them.
[14:36:49 CEST] <nevcairiel> reversing the delta luma weight should be trivial
[14:37:07 CEST] <nevcairiel> the only complex part is the chroma offsets
[14:37:17 CEST] <nevcairiel> but the va header doesnt want the syntax element there
[14:37:24 CEST] <nevcairiel> it wants some processed value
[14:37:30 CEST] <nevcairiel> need to check hevc spec what that is
[14:38:49 CEST] <BtbN> it seems to only matter for P/B slices again
[14:39:03 CEST] <nevcairiel> yeah its for prediciton
[14:39:10 CEST] <BtbN> only B even
[14:40:07 CEST] <nevcairiel> chroma_offset_l0  seems to perfectly map to the ChromaOffsetL0 element from the hevc spec
[14:40:11 CEST] <nevcairiel> so thats easy
[14:40:59 CEST] <nevcairiel> just compute the delta_luma/chroma_weight by subtracting the shifted denominator, and take the offsets as is
[14:58:26 CEST] <cone-292> ffmpeg 03Vesselin Bontchev 07master:4cd1d2314bee: avformat/aa: use correct format specifier in sscanf
[15:27:59 CEST] <BtbN> that made it better, but still not 100% correct.
[15:28:53 CEST] <BtbN> oh, i spot a typo
[15:29:58 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/5a002ad4b6787f3cd335f7450b0a0eaec6b3380f ..
[15:30:21 CEST] <nevcairiel> heh
[15:33:00 CEST] <nevcairiel> too much copypasta for lunch
[16:01:17 CEST] <ubitux> libavutil/avutil.h:#define FF_QP2LAMBDA 118 ///< factor to convert from H.263 QP to lambda
[16:01:19 CEST] <ubitux> mmmh
[16:01:38 CEST] <ubitux> and when using qscale cli option, ost->enc_ctx->global_quality = FF_QP2LAMBDA * qscale;
[16:02:07 CEST] <Daemon404> as if that option ever made sense
[16:02:09 CEST] <ubitux> sounds like a weird value
[16:02:22 CEST] <ubitux> i wonder what's the range of qscale for... typically jpeg :p
[16:02:38 CEST] <ubitux> anyway, i guess 0 or 10 will do
[16:06:10 CEST] <ubitux> it seems -qscale:v 0 has an effect even though there is a qscale >= 0 check 
[16:06:16 CEST] Action: ubitux confused again
[16:09:55 CEST] <ubitux> oh my bad, >= 0, brain is off
[16:18:55 CEST] <ubitux> mmh quality is set per frame& would be funny to make a filter to play with the frame quality
[16:19:08 CEST] <ubitux> so we can make a sinusoidal quality encode or that sort of stuff
[16:22:32 CEST] <ubitux> > quality (between 1 (good) and FF_LAMBDA_MAX (bad))
[16:22:39 CEST] <ubitux> (in avutil/frame.h)
[16:22:44 CEST] <ubitux> shouldn't it start at 0?
[16:23:13 CEST] <ubitux> damn another weird scale
[16:23:22 CEST] <wm4> trollol
[16:23:28 CEST] <ubitux> in_picture->quality = enc->global_quality;
[16:23:42 CEST] <ubitux> nice conversion from 0-118 to 1-32767
[16:24:36 CEST] <ubitux> no wonder people are still trying to use -sameq
[16:25:05 CEST] <BtbN> nevcairiel, something is still not quite right. I'm not sure if this file is just broken(gst refuses to play it at all), or there's something wrong.
[16:26:39 CEST] <BtbN> I also wonder... should I just put a large #if VA_CHECK_VERSION(0,38,0) around the entire vaapi_hevc file, or do some configure checks?
[16:26:47 CEST] <ubitux> wm4: how do you set the quality of the jpg you save in mpv?
[16:26:58 CEST] <ubitux> (screenshot feature)
[16:27:04 CEST] <ubitux> assuming you use lavc
[16:27:36 CEST] <wm4> no, using libjpeg
[16:27:43 CEST] <ubitux> ok
[16:27:44 CEST] <wm4> because I could never figure out how to get good quality
[16:27:56 CEST] <ubitux> :D
[16:28:20 CEST] <ubitux> i think it's doable
[16:28:26 CEST] <ubitux> just need to figure out how&
[16:28:26 CEST] <wm4> yeah, I'm sure lavc could output good quality with enough tuning
[16:28:37 CEST] <ubitux> just need to find the scale
[16:28:43 CEST] <ubitux> and which flags to set
[16:28:46 CEST] <ubitux> and which fields
[16:29:35 CEST] <ubitux> the global_quality option seems to affect a bunch of encoders, but generally libs, i see nothing in native mjpeg or whatever
[16:30:05 CEST] <ubitux> i need to check if the encoder is using frame->quality, to which scale, and if it needs the QSCALE flag
[16:30:15 CEST] <ubitux> adventure times
[16:30:31 CEST] <Daemon404> come on get your friends
[16:31:06 CEST] <ubitux> i think i found something
[16:31:12 CEST] <ubitux> but i don't think you wanna see it
[16:33:00 CEST] <wm4> is it a monster?
[16:33:19 CEST] <ubitux> i'd like to show you but videolan.org is down (hi jb)
[16:33:27 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git ’ 504 Gateway Time-out
[16:34:16 CEST] <ubitux> wm4: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpegvideo_enc.c#L1326
[16:34:33 CEST] <wm4> wut
[16:34:43 CEST] <ubitux> i think it's around here
[16:34:54 CEST] <ubitux> but maybe not
[16:35:11 CEST] <ubitux> it's a b/p heuristic so..
[16:35:17 CEST] <wm4> you mean the quality calculations? (the commented emms_c() is scary too though)
[16:35:20 CEST] <ubitux> maybe somewhere else
[16:35:54 CEST] <Daemon404> wm4, the old "keep putting emms in places until it works" routine
[16:38:54 CEST] <j-b> ubitux: https://git.videolan.org/?p=ffmpeg.git;a=summary this is not 504 here
[16:39:11 CEST] <ubitux> j-b: seems to be back
[16:39:16 CEST] <ubitux> it wasn't working a few minutes ago
[16:39:32 CEST] <Daemon404> it timed out for me a few mins ago
[16:40:23 CEST] <ubitux> if we don't set the qscale flag, it looks like it's going to call ff_rate_estimate_qscale() (which you don't want)
[16:41:28 CEST] <ubitux> but i still don't see where the frame->quality is taken into account
[16:41:34 CEST] <ubitux> anyway, whatever
[16:44:27 CEST] <ubitux> wm4: ok so, afaict
[16:44:31 CEST] <philipl> BtbN: so you're good now?
[16:44:37 CEST] <ubitux> you just set (AV_)CODEC_FLAG_QSCALE encoder flag
[16:44:52 CEST] <ubitux> and then the frame->quality seems to be taken into account (0 by default)
[16:46:06 CEST] <wm4> *shrug*
[16:46:11 CEST] <wm4> I could play with it later
[16:46:49 CEST] <ubitux> now don't ask me the range, but i would guess it's 0 - FF_LAMBDA_MAX
[16:47:22 CEST] <ubitux> it seems there is a debate in the code about clipping the quality or whatever
[16:47:25 CEST] <ubitux> i didn't dig any further
[16:48:19 CEST] <ubitux> (might not be a mjpeg path)
[17:01:08 CEST] <BtbN> philipl, nearly. There's still a problem with this sample clip: https://dl.dropboxusercontent.com/u/46848344/hevc/birds_1080p_24fps_h265.mkv
[17:01:13 CEST] <BtbN> something is off with the colors
[17:01:33 CEST] <BtbN> The parameters aren't trace logged, so i'll have to manualy make sure they are right.
[17:01:42 CEST] <BtbN> But i have to leave now, will check tomorrow.
[17:06:46 CEST] <philipl> BtbN: congrats all the same. Good progress.
[18:07:37 CEST] <wm4> libavcodec/libavcodec.so: undefined reference to `ff_lpc_init'
[18:07:37 CEST] <wm4> libavcodec/libavcodec.so: undefined reference to `ff_lpc_end'
[18:08:07 CEST] <wm4> why would this happen?
[18:12:00 CEST] <durandal_1707> what flags you used for configure?
[18:15:13 CEST] <Daemon404> LTO?
[18:17:24 CEST] <wm4> too many... I'll strip them down
[18:19:51 CEST] <Daemon404> i played the configure game earlier today
[18:20:04 CEST] <Daemon404> cause i always forget --enable-debug does not fully enable debugging
[18:20:15 CEST] <Daemon404> you neeed --optflags=-O0 and --disable-stripping too
[18:23:21 CEST] <wm4> I'm not trying to debug, just fixing an hilariously long configure line someone else created
[18:25:26 CEST] <Daemon404> --enable-libeverything
[18:25:34 CEST] <Daemon404> because you totally need an mp3 encoder for what tyoure doing
[18:25:39 CEST] <Daemon404> this is why i hate our wiki for building
[18:25:45 CEST] <Daemon404> it enables ALL the external libs
[18:25:47 CEST] <Daemon404> quite pointlessly
[18:26:17 CEST] <wm4> full cargo cult
[18:26:40 CEST] <Daemon404> DID YOU SAY SAMEQ?
[18:27:18 CEST] <durandal_1707> thats long gone...
[18:27:27 CEST] <Daemon404> yes, but it embodies ffmpeg so well
[18:27:32 CEST] <Daemon404> WRT cargo culting
[18:45:50 CEST] <jamrial> Daemon404: debug is enabled by default. you're supposed to use --enable-debug=LEVEL if you want to add a custom -g argument
[18:45:55 CEST] <jamrial> and --disable-stripping is only needed if you're installing
[18:46:00 CEST] <Daemon404> i know.
[18:46:01 CEST] <Daemon404> and i am.
[18:46:08 CEST] <Daemon404> and -O0 is still needed to get vals
[18:46:12 CEST] <Daemon404> enablign debug still uses O2
[18:46:14 CEST] <Daemon404> or w/e
[18:46:31 CEST] <jamrial> there's --disable-optimizations for that
[18:46:36 CEST] <jamrial> but i think sets it to -O1
[18:46:53 CEST] <Daemon404> yep
[18:47:46 CEST] <nevcairiel> does it even build with O0, i figured it w ould disable DCE as well
[18:48:40 CEST] <Daemon404> it does
[18:48:50 CEST] <Daemon404> because it passes some flag to enable DCE i think
[18:51:24 CEST] <jamrial> wm4: looks like the aac encoder needs lpc but the dependency is not in configure
[18:51:39 CEST] <wm4> jamrial: oh, I'll look into writing a patch
[18:57:58 CEST] <wm4> this was trivial
[19:36:26 CEST] <cone-111> ffmpeg 03Henrik Gramner 07master:33a58d7bf40f: checkasm: Fix floating point arguments on 64-bit Windows
[19:50:50 CEST] <cone-111> ffmpeg 03wm4 07master:94a4be85a1fc: configure: aac encoder requires lpc
[19:52:06 CEST] <cone-111> ffmpeg 03Stephan Holljes 07master:4f860848abf1: lavf/http: Fix parsing http request data to not read over '\0'.
[20:18:49 CEST] <durandal_1707> oh, noes
[20:35:13 CEST] <Compn> ubitux : people want to use sameq because they just want a normal bitrate default, or the same bitrate as input file.
[20:35:20 CEST] <Compn> what people want is -samebitrate :P
[20:35:25 CEST] Action: Compn hides under rock
[20:35:39 CEST] <ubitux> no they're looking for a lossless convert
[20:35:42 CEST] <ubitux> "same quality"
[20:35:50 CEST] <nevcairiel> why would you convert when the end result is the same
[20:35:53 CEST] <Compn> that is being too literal
[20:36:06 CEST] <Compn> imo
[20:37:10 CEST] <llogan> durandal_1707: dumb nit: "this filter is faster then" s/then/than
[20:53:43 CEST] <BBB> Compn: youre joking right>
[20:57:33 CEST] <Compn> what
[20:57:50 CEST] Action: Compn always jokes
[20:58:00 CEST] <Compn> or /me always serious
[20:58:04 CEST] <Compn> never can tell.
[20:58:28 CEST] <Compn> but yes, if people have 700mb avi, they want 700mb mp4 coming out :P
[20:58:32 CEST] <gnafu> If you've ever been seriously, I certainly couldn't tell.
[20:58:34 CEST] <gnafu> ;-D
[21:00:26 CEST] <BBB> Compn: about baptiste being leader
[21:02:22 CEST] <Compn> one of the oldest developers of ffmpeg being leader, no i was not joking
[21:03:38 CEST] <nevcairiel> maybe you should suggest someone actually involved in ffmpeg development the last couple years
[21:03:53 CEST] <nevcairiel> thats like saying you want fabrice to come back and do it
[21:04:07 CEST] <Compn> baptiste works with merges from ffmpeg in his fork , ffmbc
[21:04:16 CEST] <llogan> that's nice...
[21:04:30 CEST] <Compn> which he has maintained for longer than libav has existed
[21:05:00 CEST] <llogan> ...too bad we can't look at any git history or merge back or get reciprocal patches
[21:05:10 CEST] <Compn> just because you do not like gpl2 does not make it less of an open source project.
[21:05:26 CEST] <llogan> i don't care what the license is.
[21:05:29 CEST] <Timothy_Gu> it's dead
[21:06:06 CEST] <BBB> Compn: its a bad idea
[21:06:23 CEST] <Compn> so is cherry picking 4 years of patches
[21:06:26 CEST] <BBB> theres a world of people more suitable as leader than him
[21:06:36 CEST] <BBB> thats called a strawman argument
[21:07:04 CEST] <Compn> i didnt say it was a good idea :P
[21:07:20 CEST] <BBB> bpatiste is not a suitable leader, assuming we need one at all
[21:07:25 CEST] <Compn> fair enough
[21:07:29 CEST] <nevcairiel> so you would suggest ideas which you think are bad?
[21:07:30 CEST] <Compn> whats your plan BBB
[21:08:06 CEST] <Compn> nevcairiel : like i said, i do not speak for the project, just my opinion.
[21:08:10 CEST] <durandal_1707> supreme leader
[21:08:15 CEST] Action: Compn hails supreme leader
[21:08:16 CEST] <wm4> I should not eat so much popcorn
[21:08:25 CEST] <Compn> wm4 : are you coming to vdd?
[21:08:25 CEST] <BBB> yeah, kim jong il is not a bad idea
[21:08:43 CEST] <BBB> anyway, Ive discussed ideas on the ML, I think a merge is a pretty good idea
[21:09:20 CEST] <wm4> Compn: most likely not
[21:09:38 CEST] <Compn> wm4 : i think i was only asking because of the mystery :P
[21:10:21 CEST] <wm4> what mystery
[21:10:26 CEST] <iive> btw, VDD passed, haven't it?
[21:10:32 CEST] <Compn> iive : sept 19-20
[21:10:39 CEST] <Compn> iive : you coming ?
[21:10:42 CEST] <iive> oh, september...
[21:11:07 CEST] <Compn> mr xvmc maintainer 
[21:11:38 CEST] <iive> well, it's kind of deprecated ...
[21:15:08 CEST] <Compn> might be too late to register :P
[21:34:30 CEST] <BBB> Compn: its never too late to register
[21:51:08 CEST] <BBB> Compn: or are you afraid I will eat you?
[21:51:15 CEST] <BBB> Compn: show up! have fun! Ill buy you a beer
[21:51:22 CEST] <BBB> Compn: Ill buy you two if that helps
[21:51:30 CEST] <iive> and lemon
[21:52:19 CEST] <BBB> sure
[21:52:27 CEST] <llogan> lemon in beer? blasphemy
[21:52:29 CEST] <BBB> wm4: offer stands for you also
[21:52:34 CEST] <BBB> llogan: white beer has that sometimes
[21:52:38 CEST] <BBB> like hoegaerden or blue moon
[21:52:47 CEST] <BBB> (can have orange also)
[21:52:49 CEST] <BBB> or leffe blond
[21:52:52 CEST] <iive> no, lemon for baking him, before eating ;)
[21:52:57 CEST] <BBB> oh
[21:52:58 CEST] <BBB> hm
[21:53:01 CEST] <llogan> yeah, i brew my own, but i sitll don't like it in my beer
[21:53:03 CEST] <BBB> can I have pepper?
[21:53:11 CEST] <BBB> llogan: oh goody, cool
[21:53:22 CEST] <BBB> bring some
[21:53:49 CEST] <llogan> i can't go this year...but by next time mayne i'll have a still going
[21:54:03 CEST] <llogan> shhhhh! the revenuers!
[21:55:00 CEST] <Daemon404> weissbier is best beer
[21:55:40 CEST] <llogan> i had a gose recently. very different
[21:55:41 CEST] <BBB> Daemon404: witbier! its belgium
[21:56:12 CEST] <Daemon404> BBB, ive had german weissbier with lemon 
[21:56:18 CEST] <Daemon404> but yes generally belgian
[21:56:46 CEST] <BBB> hm...
[21:56:48 CEST] <wm4> there are different types of beer?
[21:56:51 CEST] <BBB> maybe I should try
[21:56:52 CEST] <durandal_1707> Why vdd is always in France....
[21:56:58 CEST] <BBB> durandal_1707: jb is french
[21:57:04 CEST] <Daemon404> almos tall of vlc is
[21:57:07 CEST] <Daemon404> and they pay.
[21:57:15 CEST] <nevcairiel> also not always, i think it was in ireland two years or so ago
[21:57:22 CEST] <Daemon404> last year
[21:57:38 CEST] <j-b> durandal_1707: it was not last year.
[21:57:46 CEST] <j-b> durandal_1707: and it's in Berlin next year.
[21:57:50 CEST] <Daemon404> :O
[21:57:54 CEST] <Daemon404> great
[21:57:55 CEST] <llogan> that's the one i should have gone too. of course i would have died of liver poisoning
[21:58:03 CEST] <llogan> (dublin)
[21:58:20 CEST] <j-b> 2 years ago was Paris, 1 year ago was Dublin, this year is Paris, next Berlin. And then, VDD stops
[21:58:30 CEST] <Daemon404> because you resign?
[21:58:30 CEST] <j-b> durandal_1707: tbh, it costs a LOT of money to fly everyone.
[21:58:43 CEST] <j-b> durandal_1707: and so far, we have > 100 people coming
[21:58:52 CEST] <Daemon404> i'd come even if vlc didn't pay, fwiw
[21:59:00 CEST] <nevcairiel> you cant go to germany, its stealing my last excuses for going
[21:59:14 CEST] <nevcairiel> or not going for that matter
[21:59:19 CEST] <j-b> Daemon404: vlc does not pay. VideoLAN does.
[21:59:27 CEST] <Daemon404> j-b, sorry for conflating the two
[21:59:53 CEST] <nevcairiel> vlc = video lan charity
[21:59:54 CEST] <nevcairiel> =p
[21:59:54 CEST] <j-b> Daemon404: you owe me one beer :)
[22:00:15 CEST] <j-b> nevcairiel: nooooo! VLC means Video Leaking Client or Very Large Cat
[22:00:27 CEST] <Daemon404> j-b, ;)
[22:00:32 CEST] <BBB> ok so we need to arrange money for jb to keep videolan funded
[22:00:43 CEST] <BBB> challenge accepted!
[22:00:46 CEST] <j-b> Daemon404: I won't resign, but I have bigger plans.
[22:00:56 CEST] <Daemon404> j-b, i see
[22:01:00 CEST] <j-b> I hope VDD will be no longer necessary
[22:01:01 CEST] <Daemon404> i can fathom a vague guess
[22:01:03 CEST] <llogan> let's siphon the $15 we have to help
[22:01:25 CEST] <Daemon404> llogan, better put it through a ffmtech vote
[22:01:26 CEST] Action: Daemon404 runs
[22:01:44 CEST] <durandal_1707> vlc os?
[22:01:51 CEST] <j-b> durandal_1707: please no.
[22:01:57 CEST] <wm4> j-b: so what's the purpose of VDD?
[22:02:12 CEST] <j-b> durandal_1707: we receive one mail per day, suggesting that.
[22:02:16 CEST] <Daemon404> durandal_1707, see: https://trac.videolan.org/vlc/ticket/35
[22:02:33 CEST] <j-b> durandal_1707: also VLC PDF reader, VLC browser and the usual: why can't VLC play ppt?
[22:02:59 CEST] <Daemon404> a lot of users upload ppt and fail... so they convert to go2meeting or whatever
[22:03:01 CEST] <j-b> wm4: forcing us nerds to actually speak to each other, and show we're not as pathetic as we seem.
[22:03:04 CEST] <wm4> libavcodec/pptdec.c no problem
[22:03:05 CEST] <Daemon404> maybe i should just add ppt support.
[22:03:13 CEST] <j-b> uh
[22:03:16 CEST] <j-b> that's not possible
[22:03:27 CEST] <Daemon404> sure it is. office has a COM api.
[22:03:42 CEST] Action: j-b is scared
[22:03:48 CEST] <Daemon404> you should be
[22:03:53 CEST] <j-b> I am
[22:03:56 CEST] <j-b> I really am
[22:04:17 CEST] <Daemon404> you are lucky libreoffice is too much of a mess to have something akin to liblibreoffice
[22:04:24 CEST] <Daemon404> otherwise people would send patches to ffmpeg to add it
[22:04:28 CEST] <Daemon404> i guarantee
[22:04:45 CEST] <j-b> liblibreoffice?
[22:05:13 CEST] <Daemon404> (afaict there is no way to easily use it as a format lib)
[22:05:35 CEST] <j-b> webodf.js with v8?
[22:06:00 CEST] <Daemon404> i hope thats not really a thing
[22:07:09 CEST] <j-b> it is
[22:07:16 CEST] <Daemon404> D:
[22:07:45 CEST] <wm4> why not reuse webvtt support
[22:07:49 CEST] <wm4> you need a browser for that
[22:07:58 CEST] <wm4> and I'm sure there's a webapp (or two) which render ppt
[22:08:24 CEST] <wm4> (I wonder if I'll go to hell for this joke?)
[22:08:25 CEST] <Daemon404> thats stupid, wm4
[22:08:32 CEST] <Daemon404> why would we use a browser kit
[22:08:35 CEST] <Daemon404> wen we can write our own
[22:08:46 CEST] <wm4> libavbrowser, alright
[22:09:00 CEST] <Daemon404> then i can finally use ffplay to browser
[22:09:04 CEST] <Daemon404> s/r$//
[22:09:31 CEST] <wm4> btw. SDL just closed all SDL 1 bugs as WONTFIX
[22:09:43 CEST] <wm4> time for ffplay to change to SDL2?
[22:11:17 CEST] <durandal_1707> patch welcome :)
[22:11:41 CEST] <Daemon404> git rm ffplay.c && git commit -m "Fix ffplay"
[22:12:20 CEST] <durandal_1707> I should merge mpv as ffplay
[22:12:57 CEST] <wm4> do it like gstreamer and create the player as a filter pipeline
[23:04:39 CEST] <philipl> I don't understand how anyone would find ffplay useful.
[23:06:07 CEST] <BBB> it can seek
[23:25:11 CEST] <nevcairiel> i occasionally use it for testing, but most of the time i'm just not since i cba to setup sdl for building it
[23:37:08 CEST] <llogan> i use it because i'm a lazy bitch and i dont really watch anything on the computorb
[23:37:28 CEST] <llogan> sorry, lazy bastard
[00:00:00 CEST] --- Wed Aug 26 2015