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

[burek]

[00:04:54 CEST] <ubitux> http://pastie.org/pastes/10192548/text :(
[00:05:03 CEST] <ubitux> generating broken samples is going to be more tricky than expected
[00:05:59 CEST] <wm4> simple... use ffmpeg
[00:06:02 CEST] Action: wm4 hides
[00:06:34 CEST] <ubitux> yes, but unfortunately ffmpeg is going to "fix" other things :)
[00:07:08 CEST] <ubitux> with the c interface i should be able to do what i want but it's probably faster to hack mkvmerge
[00:10:52 CEST] <ubitux> wth menuetos is still maintained
[00:10:59 CEST] <ubitux> and it seems the guy is starting to write codecs
[00:11:17 CEST] <ubitux> http://www.menuetos.net/mplayer.htm
[00:11:18 CEST] <ubitux> :D
[00:12:10 CEST] <wm4> nice
[00:12:26 CEST] <wm4> bleeding edge tech
[00:12:33 CEST] <ubitux> > MPlayer copyright (c) 2009-2014 Ville Turjanmaa and Akos Mogyorosi
[00:12:35 CEST] <ubitux> nice name
[00:13:06 CEST] <wm4> sue them
[00:13:31 CEST] <ubitux> not my war
[00:14:03 CEST] Action: rcombs conscripts ubitux 
[00:22:34 CEST] <ubitux> @_@
[00:23:43 CEST] <ubitux> > Subtitles are not supported unless included to the picture.
[00:23:45 CEST] <ubitux> lol
[00:23:53 CEST] <ubitux> "Subtitles are not supported unless they are not subtitles"
[00:27:04 CEST] <ubitux> http://www.menuetos.net/syscall.txt funny syscalls
[00:27:17 CEST] <ubitux> like, 143 or 150
[00:39:57 CEST] <wm4> well it's menuetos
[00:40:32 CEST] <wm4> holy shit, a gzip syscall
[00:40:48 CEST] <wm4> looking at this might make you stupid, be careful
[00:41:19 CEST] <wm4> fft syscall...
[00:42:40 CEST] <ubitux> :)
[00:57:42 CEST] <cone-592> ffmpeg 03Michael Niedermayer 07master:8e3b1f259e56: avfilter/buffersink: return EOF if closed link in av_buffersink_get_frame_flags()
[00:57:43 CEST] <cone-592> ffmpeg 03Michael Niedermayer 07master:b87dd7f82d4d: ffmpeg: only apply last picture flush code at EOF
[01:09:57 CEST] <cone-592> ffmpeg 03Michael Niedermayer 07release/2.6:dd9789ab6d75: avformat/mov: Print reason of loci parsing failure
[01:09:58 CEST] <cone-592> ffmpeg 03Michael Niedermayer 07release/2.6:b58cbb07bca4: avformat/mov: Fix parsing short loci
[01:56:04 CEST] <cone-592> ffmpeg 03Michael Niedermayer 07master:488383afd127: avformat/avidec: add mp2 to the list of exceptions instead of generally treating dshow_block_align==1 special
[03:05:06 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07master:38f5a266eed1: lavc/flacdec: Sanitize FLACSTREAMINFO usage.
[03:05:07 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07master:e609cfd697f8: lavc/flac: Fix encoding and decoding with high lpc.
[03:05:08 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07master:1eda55510ae5: lavc/qdrw: Fix overwrite when reading invalid Quickdraw images.
[03:05:09 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07master:caa41d1e4c96: lavf/mov: Tell users about the use_absolute_path option.
[03:05:10 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07master:4d8bd60ac68d: lavc/vc1: Set color_range for gray decoding.
[03:05:11 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07master:101f26e75800: lavc/h263: Set color_range for gray decoding.
[03:05:12 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07master:2608f1186391: lavf/wav: Print an error if files >4G are written.
[03:05:13 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07master:2acc06565321: lavf/wav: Read files >4G if no smaller filesize was written.
[03:24:50 CEST] <cone-592> ffmpeg 03Michael Niedermayer 07release/2.6:af5917698bd4: avformat/avidec: add mp2 to the list of exceptions instead of generally treating dshow_block_align==1 special
[03:48:13 CEST] <cone-592> ffmpeg 03Carl Eugen Hoyos 07n2.6.3:HEAD: lavf/wav: Read files >4G if no smaller filesize was written.
[07:22:47 CEST] <yvear> what is the preferred way to submit a patch?
[07:29:52 CEST] <jamrial> ffmpeg-devel mailing list using git send-email, or if you can't make it work, git format-patch and the resulting file attached to the email
[07:32:33 CEST] <yvear> jamrial, hmm, could you please link something describing how?
[07:33:27 CEST] <jamrial> just google git send-email. there are several tutorials
[07:44:04 CEST] <yvear> ok, thanks. I was just looking at the contributing docs and I don't think I'll do all that to move only 1 line haha. somebody will do this one eventually
[10:49:57 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07master:70c0433525bc: lavc: Print a warning if gray decoding was requested but not enabled.
[10:56:40 CEST] <siretart> klar
[13:02:00 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07master:ee8c18387d02: lavf/mpeg: Do not detect unknown audio in Hikvision streams as alaw.
[13:02:01 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07master:83356cf6cceb: lavc/vc1: Never decode vc1 as gray if gray decoding was not enabled.
[13:02:02 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07release/2.0:ac81fbba7415: lavfi/fade: Do not overread input buffer. (cherry picked from commit ab3ff19f08b7a83e320c39ab066f289c242b8030)
[13:02:03 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07release/2.1:819889e73764: lavfi/fade: Do not overread input buffer. (cherry picked from commit ab3ff19f08b7a83e320c39ab066f289c242b8030)
[13:02:04 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07release/2.2:4a620243b961: lavfi/fade: Do not overread input buffer. (cherry picked from commit ab3ff19f08b7a83e320c39ab066f289c242b8030)
[13:02:05 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07release/2.3:ac4126decd33: lavfi/fade: Do not overread input buffer. (cherry picked from commit ab3ff19f08b7a83e320c39ab066f289c242b8030)
[13:02:06 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07release/2.4:09764c9909bf: lavfi/fade: Do not overread input buffer. (cherry picked from commit ab3ff19f08b7a83e320c39ab066f289c242b8030)
[13:02:07 CEST] <cone-708> ffmpeg 03Carl Eugen Hoyos 07release/2.5:836a66eeb05c: lavfi/fade: Do not overread input buffer. (cherry picked from commit ab3ff19f08b7a83e320c39ab066f289c242b8030)
[14:04:27 CEST] <cone-708> ffmpeg 03Michael Niedermayer 07master:b6fcb2bb6db1: avcodec/flacdec: Attempt to auto-detect old buggy flac
[17:04:03 CEST] <lordkrondor> who
[17:23:41 CEST] <cone-708> ffmpeg 03MrBoogs 07master:8fd01b4a794c: avformat/hlsenc: Add hls flag for rounding m3u8 durations to whole numbers, problems with floats on some devices
[17:23:42 CEST] <cone-708> ffmpeg 03MrBoogs 07master:572a8292cbde: avformat/hlsenc: Add hls flag for starting a playlist with  a discontinuity on startup
[17:23:43 CEST] <cone-708> ffmpeg 03MrBoogs 07master:4f2fcac290af: avformat/hlsenc: do not append an endlist tag when the stream ends
[17:52:51 CEST] <Daemon404> thats a great "name"
[17:56:49 CEST] <nevcairiel> where did these commits even come from, i dont remember them on the ml
[17:57:07 CEST] <nevcairiel> anonymous people have push rights now? =P
[17:58:23 CEST] <Daemon404> probably direct to michael
[17:58:27 CEST] <wm4> something "beautiful" for ubitux: http://privatepaste.com/cf57fec59c
[17:58:50 CEST] <wm4> the <E8> etc. are from the 8 bit codepage encoding
[17:59:13 CEST] <Daemon404> ive never seven seen that
[17:59:16 CEST] <Daemon404> looks nonstandard
[17:59:22 CEST] <Daemon404> as in subrip (teh origin of srt) would not load it
[18:01:00 CEST] <wm4> haha
[18:01:03 CEST] <wm4> "standard"
[18:01:06 CEST] <Daemon404> ;)
[18:01:14 CEST] <Daemon404> i know the pain
[18:01:20 CEST] <nevcairiel> unicode, its hard
[18:01:22 CEST] <Daemon404> i am/have written a subtitle parsing library and service
[18:01:29 CEST] <Daemon404> charset encoding is The Worst
[18:01:36 CEST] <wm4> the best is that the subtitle was distributed as a zip file, with a bunch of srt files in it... with TAG and NoTAG variations
[18:01:39 CEST] <Daemon404> it's simply impossible to detect it properly 100% of the time
[18:01:49 CEST] <Daemon404> (im using ICU myself)
[18:01:49 CEST] <nevcairiel> so instead lets encode it in some weird way as ascii entities? :p
[18:01:52 CEST] <Daemon404> :D
[18:01:58 CEST] <Daemon404> nevcairiel, .ass is pretty bad too
[18:02:01 CEST] <Daemon404> it has e.g. \fe
[18:02:07 CEST] <Daemon404> which can do multiple encodings PER SUBTITLE
[18:02:18 CEST] <wm4> (nobody uses this)
[18:02:23 CEST] <Daemon404> thats a lie
[18:02:27 CEST] <Daemon404> fansubbers do
[18:02:29 CEST] <nevcairiel> whoever thought that was a good idea should be removed from the timeline
[18:02:33 CEST] <Daemon404> in fact i used it extensively
[18:02:38 CEST] <Daemon404> in order to get japanese fonts to work
[18:02:44 CEST] <Daemon404> (8 years ago)
[18:02:44 CEST] Action: Daemon404 runs
[18:02:55 CEST] <wm4> thanks
[18:03:04 CEST] <Compn> lol
[18:03:16 CEST] <Daemon404> wm4, anything i can do to help.
[18:03:52 CEST] <wm4> invent time travel and try out to grandfather paradox
[18:04:12 CEST] <wm4> actually, just remove anyone who is responsible for ASS
[18:04:38 CEST] <wm4> that's the hard part - inventing time travel should be the easy one
[18:05:03 CEST] <Daemon404> if i go back in time and murder AMZ, aegisub will never be born
[18:05:10 CEST] <Daemon404> thus preventing a lot of lolASS
[18:05:17 CEST] <nevcairiel> it could get worse
[18:05:19 CEST] <nevcairiel> you never know
[18:05:32 CEST] <Daemon404> it has
[18:05:35 CEST] <Daemon404> webvtt has embedded css
[18:05:39 CEST] <Daemon404> you need webkit.
[18:05:41 CEST] <Daemon404> (to render)
[18:05:54 CEST] <wm4> multimedia is basically neverending pain
[18:06:05 CEST] <Daemon404> quote saved
[18:06:08 CEST] <nevcairiel> well, from a design standpoint i can kinda understand it, its a subtitle format for videos distributed in the web in a browser, which presumably has a css engine, so why not use that tech
[18:06:25 CEST] <nevcairiel> of course anyone not using a browser is majorly screwed
[18:06:28 CEST] <Daemon404> nevcairiel, they were pushing for it in broadcast too
[18:06:32 CEST] <Daemon404> no, really.
[18:06:39 CEST] <wm4> modern TVs have web browsers
[18:06:39 CEST] <Daemon404> everybody laughed at them of course
[18:06:46 CEST] <Daemon404> wm4, LALALALALALAL NOT LISTENING
[18:07:21 CEST] <Plorkyeran> people who work on web things generally can't comprehend the idea of an application not having an embedded html rendering engine
[18:08:20 CEST] <Daemon404> i suppose
[18:08:50 CEST] <Daemon404> these are the same people who thought it would be great to write an code editor that uses webkit to render e.g. syntax hilighting
[18:09:03 CEST] <Daemon404> im sure that isnt slow at all to do that much DOM crap for large source files
[18:09:53 CEST] <Mavrik> also, "real-time" and "fast" are very stretchable terms in world of JS hackery
[18:12:05 CEST] <nevcairiel> Daemon404: the "Atom" editor is based on html tech using chromium, and Microsofts Visual Studio Code is based on that, and it works quite nicely (and fast)
[18:12:58 CEST] <Daemon404> the only time i tried atom is destroyed my i7
[18:13:03 CEST] <Daemon404> for a decent sized c file
[18:13:43 CEST] Action: Daemon404 runs out for lunch
[18:25:54 CEST] <kierank> oh yeah atom was sooo slow
[18:26:11 CEST] <kierank> some people see everything through a web browser
[18:28:00 CEST] <JEEBsv> my coworker at the previous place used atom for a moment, and it kind of worked and had vim keybindings... but I think he moved back to his usual tools
[18:53:29 CEST] <Compn> >reads bellard, every time
[18:53:56 CEST] <Compn> i hate doing anything inside a web browser. its always laggy and i feel as if it will crash at any second
[18:54:10 CEST] <Compn> but i guess thats more of a complaint of javascript
[18:55:24 CEST] <wm4> what browser are you using that it always crashes?
[18:55:28 CEST] <wm4> let me guess, IE6
[19:08:14 CEST] <wm4> Compn: why do you encourage the use of the awful mplayer wine wrapper to use win32 codecs, instead of e.g. encouraging sponsoring the development of a proper decoder? (or whatever is needed)
[19:28:47 CEST] <Compn> wm4 : i've tested all browsers and most crash in one way or the other.
[19:28:57 CEST] <Compn> cept the classics like lynx / links :P
[19:30:21 CEST] <Compn> wm4 : having the decoder working on linux allows devs to reverse engineer , or at least test the samples. i always encourage people to implement codecs in ffmpeg, but i lack the ability to program- so i cant do it. 
[19:31:47 CEST] <Compn> wm4 :  what i can do is get the file working on linux in another open source project (mplayer). this allows the user, who needs this feature now - not in some future time, to finish his work. in the future when ffmpeg gets the feature, he can easily switch back to using it and drop mplayer.
[19:33:13 CEST] <Compn> should i be looking for specifications and other open source libs that handle g729 ? yes, i already have dug a bunch up. i'll post them to the bug report when i get some time and look to see if any of them decode the stereo sample we have 
[19:33:19 CEST] <nevcairiel> more importantly, keep this off the ffmpeg ML :P
[19:33:51 CEST] Action: Compn wonders why people are so upset just reading the name "mplayer"
[19:34:58 CEST] <wm4> it isn't necessarily the name "mplayer" - there are lots of things to get upset about
[19:36:45 CEST] <Compn> not to mention how most of the RE'd codecs were RE'd using mplayer loader
[19:37:15 CEST] <Compn> not that mplayer loader is any good 
[19:37:41 CEST] <cone-708> ffmpeg 03Michael Niedermayer 07master:c720b9ce9850: avcodec/golomb: get_ur_golomb_jpegls: Fix reading huge k values
[19:37:42 CEST] <cone-708> ffmpeg 03Michael Niedermayer 07master:14c4b2515836: avcodec/golomb: fix reading huge signed rice golomb values
[19:38:05 CEST] <Compn> nevcairiel : you realize that i spend a lot of time sending users to various open source projects to fix their problems, right ?
[19:38:46 CEST] <Compn> its not like ffmpeg is some kind of game where our project is best and we should ban anyone talking about other projects :P
[19:39:06 CEST] <Compn> we are part of a community , like it or not. 
[19:39:11 CEST] <Compn> but yeah it shouldnt be on -devel :P
[19:39:38 CEST] <Compn> that was hopefully my last mail on that thread
[19:40:06 CEST] <Compn> of course "mplayer trolling" also encourages devs to fix it just so i shut up about mplayer 
[19:40:37 CEST] <Compn> but thats secret reverse-psychology idea and it shouldnt be abused...
[19:40:39 CEST] <thardin> the productive kind of trolling
[19:40:59 CEST] <thardin> works in industry too
[19:41:03 CEST] <Compn> i bet carl is working hard on it right now :P
[19:42:50 CEST] <Compn> wm4 : you know i send a lot of people to mpv too...
[19:42:59 CEST] <Compn> when they are in #mplayer asking about features
[19:43:12 CEST] <wm4> not sure if I want mplayer users
[19:43:45 CEST] <wm4> they tend to attempt to use old features that are left over from mplayer etc.
[19:43:49 CEST] <Compn> well the last  guy was mplayer2 user
[19:47:50 CEST] <Compn> but hey if my mplayer talk is bugging anyone , i'll stop it
[19:47:52 CEST] <Compn> sorry guys
[19:48:00 CEST] <Compn> i dont mean to antagonize you nevcairiel / wm4 and others
[19:48:52 CEST] <wm4> Compn: the bad part about this mplayer thing is that you encourage users to use a really bad solution (binary loader with wine code from 1999, literally), instead of fixing it in ffmpeg
[19:50:11 CEST] <Compn> i took the option of "just use whatever works" long ago.
[19:50:49 CEST] <Compn> i'm not sure how i could encourage users to fix it in ffmpeg. ask them to donate bounty money ?
[19:51:04 CEST] <wm4> that's a good question
[19:51:19 CEST] <Compn> i mean you could do that too, i think you are subscribed
[19:51:23 CEST] <wm4> asking to provide samples etc. was a good move though
[19:51:35 CEST] <wm4> I have no clue though
[19:51:58 CEST] <Compn> no clue about what ? how to encourage codec development ?
[19:52:08 CEST] <wm4> that too
[19:53:07 CEST] <Compn> i dont even know the best way. it all seems magic to me. sometimes patches drop out of the sky, sometimes specs are written from RE'd stuff for years on multimedia.cx wiki... its not predictable
[19:53:52 CEST] <Compn> generally after i get a solution to the problem, then thats a good time to ask for donations :)
[19:54:54 CEST] <Compn> i remember when people are asked about codec bounties, no one can come up with an estimate of how much they should offer
[19:55:15 CEST] <Compn> do we follow the gsoc prices? $2500 or $5000 ?
[19:55:30 CEST] <Compn> is it a simple one line fix? 
[19:55:49 CEST] <Compn> are any codec devs even free to work on it ?
[19:56:33 CEST] <Compn> then theres codec devs who prefer to work on video coding because audio codecs are completely different
[19:57:22 CEST] <Compn> so are audio codecs higher bounty? :P
[19:57:51 CEST] <Compn> would a wrapper around another opensource c lib be preferable until native can be grinded out
[19:58:19 CEST] <Compn> thought we all hated wrapper libs
[20:59:29 CEST] <ubitux> wm4: you make me sad, but it doesn't surprise me
[21:02:48 CEST] <wm4> ubitux: so I think what's needed is... emulating vsfilter
[21:02:56 CEST] <wm4> which supports a bunch of subtitle formats at once
[21:03:00 CEST] <wm4> and even MIXING them
[21:03:20 CEST] <wm4> though, reasonably, libass would have to
[21:04:55 CEST] <philipl> Speaking of hating wrapper libs - that libyami discussion with the Intel guys fizzled out back in Jaunary. But I don't see how ffmpeg benefits from refusing to use it. It seems clear that Intel is pushing libyami as their way of exposing vaapi to consumers and we're not going to see accelerated encoding support (or for that matter accelerated decoding for anything not currently in ffmpeg already) any
[21:05:01 CEST] <philipl>  other way.
[21:05:35 CEST] <philipl> If Intel's prepared to do the work and maintain it, that seems unambiguously better than having old unmaintained code that isn't keeping up with the new hardare capabilities.
[21:16:29 CEST] <BtbN> philipl, isn't vaapi accelerated decoding already part of the ffmpeg cli tool?
[21:16:56 CEST] <BtbN> Or is it only implemented for vdpau?
[21:17:31 CEST] <wm4> philipl: the posted patch was basically low quality
[21:18:25 CEST] <philipl> BtbN: I don't believe it's useful because it needs the magic surface format stuff that's tied to the presentation  application using ffmpeg. same as vdpau
[21:18:40 CEST] <philipl> The libyami thing supported using dma_bufs to read back frames
[21:19:10 CEST] <BtbN> libyami is just a wrapper around libva
[21:19:15 CEST] <philipl> wm4: I don't doubt it but I believe they'd improve it if we provided feedback and said that we'd accept a sufficiently well written implementation
[21:19:24 CEST] <BtbN> everything yami supports is also supported via libva, but with a much more painfull api.
[21:19:44 CEST] <BtbN> But instead of fixing libva, they add another wrapper around it...
[21:19:57 CEST] <wm4> ffmpeg's low level API is also somewhat more flexible
[21:20:06 CEST] <philipl> That's absolutely true, but if they're ponying up resources, they get to say what work they do.
[21:20:19 CEST] <wm4> and I don't really remember, but I think the libyami patch didn't even return opaque surfaces
[21:20:30 CEST] <wm4> (i.e. useless)
[21:20:31 CEST] <philipl> The choice isn't between a better or a worse implementation, it's between maintained support and no support at all.
[21:20:54 CEST] <philipl> wm4: I think the goal included supporting read-back of usable surfaces with dma_buf.
[21:21:00 CEST] <BtbN> libva is maintained. It's just a pain to use. Otherwise i'd already have implemented an encoder for ffmpeg with it.
[21:21:14 CEST] <wm4> philipl: call me when this dma_buf crap actually works
[21:21:24 CEST] <philipl> Isn't that the point though? It's so terribl that you didn't do it. :-)
[21:21:24 CEST] <wm4> that's also a big problem with Intel
[21:21:36 CEST] <wm4> they produce lots of APIs etc., but it's all half done
[21:21:47 CEST] <wm4> some stuff never seems to work and then gets phased out
[21:21:56 CEST] <wm4> like the horrendous opengl interop
[21:22:05 CEST] <philipl> wm4: dma_buf is fundamental tech in the graphics stack, so it works in certain cases. I know that the ffmpeg case isn't one of the original primary ones, of course.
[21:22:20 CEST] <BtbN> I did implemement a working libva based encoder, for vlc though. But i doesn't support B frames, contains nearly 1000 lines of boilerplate code that should be in libva instead, and isn't polished enough for ffmpeg.
[21:22:22 CEST] <philipl> There's a lot to critisize - I wish they'd used vdpau.
[21:22:42 CEST] <BtbN> vdpau doesn't support encoding though
[21:22:47 CEST] <philipl> completely true.
[21:22:53 CEST] <BtbN> And i think they are actualy working on vdpau support?
[21:23:11 CEST] <philipl> I've heard vague mumbling about that over the years, but no real evidence from an Intel person.
[21:23:51 CEST] <BtbN> As bad as nvidia is, nvenc is what an API for a hardware encoder should look like.
[21:23:52 CEST] <philipl> It's a shame nvidia didn't try and do a generic encoding API. nvenc is easy to work with but useless for real produces due to the confused licencing. No one else will adopt it.
[21:24:02 CEST] <philipl> exactly.
[21:24:26 CEST] <BtbN> The annoying thing is, on windows intel has a realy good API for it. QSV is very similar to nvenc.
[21:24:41 CEST] <philipl> Right. But Intel has a firewall between their linux and windows teams.
[21:24:44 CEST] <philipl> Nothing is shared.
[21:25:45 CEST] <philipl> I should try and harass nvidia more about the stupid header licensing.
[21:25:54 CEST] <philipl> The handbrake guys would actually support nvenc if that got fixed.
[21:26:33 CEST] <BtbN> Someone would have to re-engineer the header. But no idea how to do that without running into license issues.
[21:27:01 CEST] <BtbN> The api is intentionaly designed to be hard to reverse engineer.
[21:27:17 CEST] <philipl> I could believe that.
[21:27:37 CEST] <philipl> I feel like they ought to be open to sticking a sensible licence on the header - that's got zero magic in it.
[21:27:40 CEST] <BtbN> The nvenc library exports just one function. You call that with a struct and a version number, and it fills the struct with the actual api functions.
[21:27:57 CEST] <philipl> Without that, there's no practical way to consume it in free/open source apps.
[21:28:35 CEST] <philipl> I'm sure there's not internal compatibility argument behind that. It avoids them having to worry about link time compatibility with a conventional library.
[21:28:38 CEST] <BtbN> Unless you just don't care about the license. Which seems to be what nvidia expects you to do. They just have it in place because their lawyers told them to be safe.
[21:29:00 CEST] <BtbN> Well, CUDA just has versioned symbols.
[21:29:00 CEST] <philipl> Indeed.
[21:29:07 CEST] <philipl> Different teams, I imagine.
[21:29:26 CEST] <philipl> They come up with their own link strategy and having varying degrees of open-source awareness.
[21:29:29 CEST] <BtbN> Not realy, nvenc is tied into CUDA
[21:29:48 CEST] <philipl> It may not be on the inside.
[21:30:06 CEST] <philipl> As it's dedicated hardware, I can easily imagine dedicated people too.
[21:30:32 CEST] <philipl> Gotta run. Anyway, mostly idle thought on the yami stuff.
[21:30:34 CEST] <BtbN> The last time i contacted the nvidia support about issues with nvenc, i got told i need a license key for nvenc to work at all, and that's the source of my issues...
[21:30:47 CEST] <philipl> I've got a 960 arriving next week so I can work on the h.265 vdpau stuff.
[21:30:55 CEST] <BtbN> That was after they removed the license key stuff from the API.
[21:31:06 CEST] <philipl> yeah. No one ones what anyone else is doing.
[21:31:57 CEST] <BtbN> I'm still waiting for a maxwell GT card, so i can affort something with h265 support
[22:46:12 CEST] <nevcairiel> they have been pretty quiet on the low-end front, maybe on computex or e3
[22:47:00 CEST] <BtbN> Even kepler GT cards are quire rare
[22:47:07 CEST] <BtbN> *t
[22:47:26 CEST] <nevcairiel> its a boring market, most people just use iGPUs in the low-ends
[22:47:52 CEST] <BtbN> Tried that for a while, got annoyed by intels linux support, and got a nvidia GT
[22:48:06 CEST] <nevcairiel> whats the point of a 920 or so if it doesnt even beat the intel or amd iGPUs that every single CPU comes with anyway
[22:48:46 CEST] <BtbN> It supports vdpau, high quality deinterlacing and scaling, nvenc
[22:59:26 CEST] <JEEBsv> well the decoding part in intel iGPUs is pretty good
[22:59:46 CEST] <JEEBsv> they at some point took the lead in AVC decoding speed IIRC
[23:00:10 CEST] <JEEBsv> and haswell+ the encoder has really been some of the best available
[23:01:49 CEST] <nevcairiel> its unfortunate that intel has been dragging their feet with full hevc decoding
[23:01:59 CEST] <nevcairiel> i hope skylake actually has it
[23:07:01 CEST] <BtbN> JEEBsv, yes, the hardware intel has it realy good. It's the software side on linux that's terrible.
[23:07:08 CEST] <JEEBsv> sure
[23:07:09 CEST] <BtbN> On Windows it works fine.
[23:07:38 CEST] <JEEBsv> although if intel actually keep supporting their wrapper that might actually bring more features in regarding that
[23:07:45 CEST] <thardin> i
[23:07:51 CEST] <JEEBsv> (also I will never be able to read libyami with a straight face)
[23:07:54 CEST] <BtbN> I don't get why they don't just fix libva.
[23:07:56 CEST] <JEEBsv> libdarkness
[23:09:00 CEST] <nevcairiel> the MediaSDK stuff on windows sucks too, it has so many bugs ... but at least decoding you can do through DXVA2 and avoid that wrapper = p
[23:09:59 CEST] <JEEBsv> yup
[23:10:08 CEST] <JEEBsv> since they (more or less) fixed their DXVA2
[23:10:18 CEST] <JEEBsv> or everyone just added workarounds
[23:10:19 CEST] <JEEBsv> >_>
[23:10:30 CEST] <nevcairiel> MediaSDK decoding goes through DXVA2 anyway, so its just a useless layer of bugs
[23:11:08 CEST] <nevcairiel> the only "useful" feature it has is decoding of formats that DXVA2 doesnt have a spec for, like VP8 and JPEG, which are presumably hw accelerated
[23:11:26 CEST] <JEEBsv> yeah
[23:11:37 CEST] <nevcairiel> (I use useful loosely)
[23:11:47 CEST] <JEEBsv> basically QS API just used dxva2 in a way that wouldn't blow up with intel
[23:12:06 CEST] <JEEBsv> and if you did stuff somewhat similarly you'd get the same or better result >_>
[23:12:25 CEST] <nevcairiel> i thought about removing the MediaSDK/QS decoder in my project at some point, since people just read "Intel QuickSync" and think they need to use it, but its far more buggy than the DXVA2 decoder...
[23:12:36 CEST] <nevcairiel> but people would whine 
[23:14:30 CEST] <nevcairiel> btw JEEBsv, you have the P2415Q, do you not?
[23:14:37 CEST] <JEEBsv> yeah, I do
[23:14:53 CEST] <nevcairiel> does its displayport implementation suck as much as the P2715Qs?
[23:15:26 CEST] <JEEBsv> it probably does, I had to actually take out the power cord for it to start taking in picture from DP
[23:15:44 CEST] <JEEBsv> although I haven't had issues after that, no sleep mode problems
[23:15:48 CEST] <nevcairiel> my window positions and desktop icons constantly scramble themself  when it goes to sleep
[23:15:54 CEST] <JEEBsv> oh
[23:15:56 CEST] <JEEBsv> yes
[23:16:08 CEST] <nevcairiel> its driving me crazy
[23:16:15 CEST] <kierank> http://download.das-werkstatt.com/pb/fsfe/presentations/2015/the_ffv1_story.pdf
[23:16:17 CEST] <JEEBsv> it for whatever reason seems to rescale them to the old screen size that I used to have
[23:16:41 CEST] <JEEBsv> I used to have a 1280x1024 screen before and it's probably something like that that it scales shit to
[23:16:48 CEST] <JEEBsv> it's /quite/ irritating
[23:16:57 CEST] <nevcairiel> i wonder if i should re-install windows to get it to fix that
[23:17:10 CEST] <nevcairiel> or figure out whichj settings to clear
[23:17:16 CEST] <JEEBsv> yeah :|
[23:17:28 CEST] <JEEBsv> if you find anything regarding that stuff feel free to ping
[23:17:36 CEST] <nevcairiel> i got a tiny app now that can save icon position and restore them whenever it happens =p
[23:19:47 CEST] <nevcairiel> kierank: i thought that was going to be about FFV1, but it turned into a praise-hymn about free software <.<
[23:22:18 CEST] <JEEBsv> yeah, not too much about ffv1 itself
[23:22:54 CEST] <JEEBsv> but yeah, this is the same as the "white papers" companies have on successful uses of their stuff
[23:22:57 CEST] <nevcairiel> JEEBsv: i read somewhere that this might be a "problem" with the DP implementation in either the screen or the GPU, that its initializing the screen in a "safe" resolution first and only then switching to 4K, and someone reported that it stopped for him after updating his AMD GPU drivers, but that was one case, so it might be coincedence..
[23:23:13 CEST] <JEEBsv> yeah :/
[23:23:45 CEST] <JEEBsv> it definitely sounds like something like that since all of the windows get moved to top left and to a smaller size
[23:24:15 CEST] <nevcairiel> i should bother DELL support about it, but it would probably be a waste of my time
[00:00:00 CEST] --- Mon May 18 2015