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

[burek]

[01:15:45 CET] <cone-703> ffmpeg 03Steinar H. Gunderson 07master:08b098169be0: speedhq: fix out-of-bounds write
[02:18:18 CET] <atomnuker> how did VP8 get away with only supporting bt601 when it was released?
[02:18:44 CET] <atomnuker> granted, browsers still assumed everything was 601 back 7 or 8 years ago
[02:29:47 CET] <BBB> atomnuker: its just a bit in the header, I think they didnt really think about it very much
[02:30:12 CET] <BBB> atomnuker: dont forget vp9 doesnt do much better, people released the vpcc atom afterwards to basically do what hevc/h264 do in the vps/sps
[02:30:19 CET] <BBB> (vpcc as part of iso/mp4)
[02:30:38 CET] <BBB> and then theres compatible fields for webm/matroska also
[02:33:34 CET] <TD-Linux> err vp9 has color fields in the bitstream I thought
[02:34:55 CET] <TD-Linux> yeah it has a colorspace flag in the uncompressed header
[02:46:28 CET] <BBB> TD-Linux: yes it does, but its not as extensive as the vps/sps fields in h264/hevc
[02:46:43 CET] <TD-Linux> indeed.
[02:46:57 CET] <BBB> TD-Linux: the vpcc atom in is/mp4 or the colorspace fields in the webm/matroska header are more extensive and compare feature-wise to the hevc/h264 vps/sps fields
[02:51:27 CET] <BBB> atomnuker: so uhm& about that opus encoder
[02:51:35 CET] <BBB> atomnuker: how does it compare to libopus? :)
[02:52:15 CET] <BBB> in terms of whatever metric audio people use, in terms of psychoacaustics or hydrogenaudio scores, etc. etc.
[02:52:16 CET] <atomnuker> right there in the commit message, worse on speed and worse on quality, but probably faster if you put the libopus pvq search in
[02:52:45 CET] <BBB> so whats so special about your pvq search that you added something thats both slower and worse?
[02:53:01 CET] <BBB> is it a placeholder for something awesome?
[02:53:04 CET] <atomnuker> no, the pvq search gives identical results, its just slower
[02:53:11 CET] <BBB> oh I see
[02:53:24 CET] <BBB> so which part makes it worse than libopus?
[02:54:19 CET] <atomnuker> the libopus one does rounding only if N > (K >> 1) and instead of looping over the vector and measuring deviation it just looks at the max num/den pair
[02:54:40 CET] <atomnuker> it doesn't do the pitch prefilter and it doesn't know when to put transients in
[02:55:09 CET] <atomnuker> that's what makes it worse than libopus at the lowest complexity
[02:55:32 CET] <atomnuker> (though I'm not sure libopus enables the pitch prefilter or does transients at the lowest complexity)
[02:56:07 CET] <atomnuker> (it should still do transients maybe, it has a cheap time domain detector)
[02:57:25 CET] <atomnuker> btw whatever new pvq search I come up with has to produce better or identical results, else its a very steep slope towards lower quality
[02:58:27 CET] <atomnuker> the pvq search algorithm is such a simple problem yet doing it efficiently is difficult
[02:59:43 CET] <atomnuker> but hey, if I think of something better, it'll by extension make libopus, daala and av1 better
[03:02:29 CET] <BBB> \o/
[03:02:39 CET] <BBB> so whats your goal with the encoder?
[03:03:10 CET] <BBB> not to be an ass, but most encoders in ffmpeg appear to primarily serve as window dressing, that is, theyre not very useful outside the obligatory checkmark in some kind of feature list
[03:03:33 CET] <BBB> are you intending to make it better than opus at the same speed, or faster than opus for the same quality?
[03:03:41 CET] <BBB> or more ootimized for psychoacaustics?
[03:03:46 CET] <BBB> or something else?
[03:08:34 CET] <atomnuker> just quality, that's all
[03:13:10 CET] <atomnuker> ffmpeg has some pretty good audio encoders which are definitely being used outside of padding feature lists
[03:14:43 CET] <atomnuker> the ac3 encoder is very good, all the lossless one are amongst the best and fastest, plenty of speech codecs too
[03:15:26 CET] <atomnuker> the mp2 encoder is decent as well
[03:16:24 CET] <atomnuker> the only ones which I can kind of say are cool but kinda pad feature lists are the realaudio 14.4k encoder, the roq quake dpcm encoder and the comfortnoise generator
[03:17:54 CET] <atomnuker> the real audio one is pretty good considering the bitrate but is kinda beat by the g. family of codecs
[08:22:10 CET] <wm4> this seems awfully, awfully familiar https://github.com/rockchip-linux/mpp/blob/rk3288_linux/inc/mpp_frame.h#L115
[08:33:23 CET] <wm4> xD https://github.com/rockchip-linux/mpp/blob/rk3288_linux/mpp/base/inc/mpp_frame_impl.h#L79
[09:18:41 CET] <JEEB> wm4: lol
[09:45:18 CET] <durandal_1707> wm4: omg wtf
[09:45:58 CET] <cone-857> ffmpeg 03Carl Eugen Hoyos 07master:ac0863146b44: ffmpeg: Add a missing line break when requesting a sample.
[10:52:34 CET] <ubitux> we'll need to merge 0cef06df somehow for 9064777dbb
[10:53:00 CET] <ubitux> oh mmh or maybe not
[10:54:17 CET] <ubitux> yeah forget this
[10:54:25 CET] <nevcairiel> we cant merge the mc test without merging their mc changes =p
[10:54:52 CET] <ubitux> yeah i was under the impression it was reusing some hevc test file introduced there
[11:17:04 CET] <cone-857> ffmpeg 03Vittorio Giovara 07master:ed9b2a5178d7: mov: Rework the check for invalid indexes in stsc
[11:17:05 CET] <cone-857> ffmpeg 03Matthieu Bouron 07master:d30870cc7303: Merge commit 'ed9b2a5178d7a7c5a95694da3a808af327f36aff'
[11:17:13 CET] <mateo`> ubitux: here you go
[11:17:16 CET] <ubitux> thx
[11:23:09 CET] <cone-857> ffmpeg 03Martin Storsjö 07master:6f9e34baea4f: arm: Check for support for the .fpu directive
[11:23:10 CET] <cone-857> ffmpeg 03Clément BSsch 07master:a0860b0a388d: Merge commit '6f9e34baea4f6f484392e4e67f606a0835d07b73'
[11:27:58 CET] <cone-857> ffmpeg 03Martin Storsjö 07master:f637046d3134: libavutil: Always use some GCC style attributes on clang
[11:27:59 CET] <cone-857> ffmpeg 03Clément BSsch 07master:55b2cfa921c3: Merge commit 'f637046d3134a331e4b5a7243ac3dfb92735b8a5'
[11:28:56 CET] <cone-857> ffmpeg 03Vittorio Giovara 07master:6135c3b61e08: Revert "avprobe: Zero the allocated avio buffer memory"
[11:28:57 CET] <cone-857> ffmpeg 03Clément BSsch 07master:5e013586bf9a: Merge commit '6135c3b61e084be93c0876cecd06f4e764f961c0'
[11:35:55 CET] <cone-857> ffmpeg 03Hendrik Leppkes 07master:7f549b8338ed: riff: don't overwrite bps from WAVEFORMATEX if EXTENSIBLE doesn't contain that data.
[11:35:57 CET] <cone-857> ffmpeg 03Clément BSsch 07master:f47540523741: Merge commit '7f549b8338ed3775fec4bf10421ff5744e5866dd'
[11:41:00 CET] <cone-857> ffmpeg 03Alexandra Hájková 07master:9064777dbb33: checkasm: add HEVC test for testing IDCT DC
[11:41:01 CET] <cone-857> ffmpeg 03Clément BSsch 07master:92cb9a386932: Merge commit '9064777dbb335ab4809ae09e3fdcc0245f925cdc'
[11:45:08 CET] <ubitux> qsv commits are incoming
[11:45:26 CET] <ubitux> after the next one
[11:45:31 CET] <ubitux> who wants to work on them?
[11:47:51 CET] <ubitux> any opinion on b0f36a0043 btw? it seems we have quite a different logic here
[11:48:03 CET] <ubitux> like, we indeed auto insert setpts
[11:48:22 CET] <ubitux> but the configure input video filter does actually set a framerate
[11:48:31 CET] <wm4> sounds like a skip
[11:48:36 CET] <ubitux> so are we actually already handling cfr and could drop the setpts?
[11:48:49 CET] <ubitux> wm4: well, maybe it's fixing something
[11:48:53 CET] <ubitux> maybe we don't need the setpts
[11:48:59 CET] <ubitux> who knows
[11:49:15 CET] <ubitux> also,
[11:49:18 CET] <ubitux> we lack:
[11:49:20 CET] <ubitux> - QSV scaling filter (62c58c5)
[11:49:22 CET] <ubitux> - ffmpeg.c filter init decoupling (3e265ca,a3a0230,d2e56cf,94ebf55)
[11:49:27 CET] <jkqxz> I can do qsv, but I don't have anything to test 10-bit stuff so that would just be a blind merge and assume it works.
[11:49:56 CET] <ubitux> jkqxz: we need the 2 items i just quoted from doc/libav-merge.txt first
[11:49:58 CET] <jkqxz> Also the filter init decoupling is becoming kindof fatal to sensible hardware setup.
[11:50:06 CET] <jkqxz> cuvid is also a bundle of hacks because of it.
[11:50:09 CET] <ubitux> then we can move on with the next commits
[11:50:16 CET] <ubitux> so we're at a new blocker now
[11:50:35 CET] <ubitux> ETA: 851 commits
[11:50:40 CET] <nevcairiel> the scaling filter can probably just be ported
[11:50:43 CET] <ubitux> (+5)
[11:50:47 CET] <jkqxz> QSV scaling filter is trivial, that was only skipped because it wasn't testable in ffmpeg.c.
[11:50:50 CET] <jkqxz> Yeah.
[11:51:05 CET] <ubitux> i'll leave the merge work for now then
[11:51:13 CET] <ubitux> hf... and thanks
[11:51:47 CET] <nevcairiel> why is the ffmpeg.c thing a blocker right now anyway
[11:51:54 CET] <jkqxz> nevcairiel:  You looked at the filter setup before I think?  How far did that get before you gave up?
[11:51:56 CET] <rcombs> mmmmmm, yum
[11:52:37 CET] <ubitux> nevcairiel: not exactly a blocker but we don't have the filter decoupling thing which might be problematic, and we have special cfr logic as well
[11:52:54 CET] <ubitux> so while not blocking, it's better to wait for a more in-sync state
[11:52:58 CET] <nevcairiel> "merging" that is basically a rewrite of ffmpeg.c =p
[11:53:00 CET] <ubitux> which we need anyway for the next commits
[11:55:35 CET] <wm4> <ubitux> - ffmpeg.c filter init decoupling (3e265ca,a3a0230,d2e56cf,94ebf55) <- I'll do this myself if nobody else does before me
[11:55:39 CET] <jkqxz> I'm happy to have a go at filter setup, but if I get stuck with a load of fate tests which have subtle changes to timing/ordering and we aren't allowed to modify then I will lose the will to live.
[11:55:42 CET] <wm4> because that one is causing me significant pain
[11:56:04 CET] <ubitux> feel free to, but wasn't it related to qsv somehow?
[11:56:22 CET] <jkqxz> Not really, it affects all hardware decoders.
[11:56:26 CET] <wm4> not sure, the current qsv code is completely ass
[11:56:32 CET] <wm4> so maybe it would regress it temporarily
[11:56:33 CET] <jkqxz> qsv just happened to be the one which was most stupid.
[11:58:36 CET] <jkqxz> I don't think there is anything to regress.  The current hacks are only sufficient to make trivial transcode work, and that would be fine after merging.
[12:03:50 CET] <wm4> all the better
[12:13:48 CET] <nevcairiel> since I initially tried to merge that, the dataflow in lavfi changed again, maybe that makes it easier or harder
[12:14:00 CET] <nevcairiel> but last time i tried, lavfi had some dumb dataflow issues
[12:14:11 CET] <rcombs> has lavfi ever not had those
[12:14:37 CET] <nevcairiel> like, to get a proper output format, you need to pump data through, but in the case of audio, i need to set the output framesize i want before doing that ... but to know that, i need to know the output format, so i can init the encoder
[12:15:06 CET] <nevcairiel> libav solved that by simply having a drain function that you tell how many samples you want, but ffmpeg doesnt like that function for some reason
[12:15:39 CET] <BtbN> jkqxz, doesn't the hwdevice_ctx also need the second patch(patch 6/6 in the original series)?
[12:15:44 CET] <BtbN> to ffmpeg.c
[12:18:31 CET] <wm4> nevcairiel: the lavfi API didn't change
[12:18:40 CET] <nevcairiel> not the API, but the internal behavior
[12:18:50 CET] <wm4> (except that deprecation which wants you to use accessors which are not in Libav)
[12:19:25 CET] <jkqxz> BtbN:  That's only the patch to lavc - being clear about the semantics there is the first thing to do.
[12:20:13 CET] <jkqxz> Also I killed the device-on-open2-only use-case in that one, which I didn't mean to.
[12:20:42 CET] <JEEB> hmm, demuxers currently use packet side data for updates, but those are stream-specific, right?
[12:20:43 CET] <jkqxz> Needs a new version.
[12:21:19 CET] <JEEB> what if I want to tell that "input stream situation changed, check your usage"
[12:21:31 CET] <nevcairiel> you can't
[12:21:39 CET] <JEEB> well yes
[12:22:05 CET] <JEEB> just saying that if I added it to random side data it would be a bad idea
[15:03:28 CET] <BBB> philipl: I remember something about carl wanting us to use yuv4nnP16 for 10/12 bits formats, while settings bits_per_sample, I dont remember if that was to pack 10/12bit content in LSB or MSB, I think it was MSB
[15:03:39 CET] <BBB> philipl: maybe that can be used here instead of adding an additional new pix_fmt?
[15:49:24 CET] <cone-399> ffmpeg 03Michael Niedermayer 07master:61f70416f854: avcodec/dca_lbr: Fix off by 1 error in freq check
[15:52:08 CET] <BBB> Compn: ping
[15:53:08 CET] <Compn> yeS?
[15:54:20 CET] <BBB> Compn: if its so important that samples remain private, why not have a login for ffmpeg incoming uploads similar to what vlc already has?
[15:54:44 CET] <BBB> Compn: that sounds like an incredibly easy way to address carls concern
[15:54:54 CET] <BBB> and since vlc already does it, it cant be that complicated
[15:56:39 CET] <Compn> vlc does it by ssh access, so i'd rather not do it like that
[15:56:58 CET] <Compn> be easier just to tell people to select vlc and type private in the filename...
[15:57:03 CET] <Compn> if they want to upload private sample
[15:57:51 CET] <BBB> so you can choose if its private or not?
[15:57:54 CET] <BBB> or is it always private?
[15:58:28 CET] <Compn> right now it looks like samples uploaded , when selected vlc, is always private
[15:58:55 CET] <Compn> its been like that since day one
[15:59:00 CET] <Compn> so i assume it continues into future
[15:59:09 CET] <Compn> we used to have an http login , but now its ssh
[16:01:01 CET] <wm4> IMO uploads should be private only if the uploader specifically decides so
[16:01:11 CET] <wm4> getting samples if they require a login is a pain
[16:01:19 CET] <Compn> right
[16:01:22 CET] <iive> no
[16:01:25 CET] <Compn> so my workaround is how to do it 
[16:01:30 CET] <Compn> public sample > click ffmpeg and upload
[16:01:36 CET] <Compn> private sample > click vlc and upload
[16:01:38 CET] <iive> uploads must be privite, unless specified otherwise
[16:02:17 CET] <iive> have in mind some of them contain copyrighted materials,
[16:02:24 CET] <Compn> idgaf about copyright :D
[16:02:34 CET] <Compn> this is for research purposes 
[16:02:59 CET] <iive> well, the researchers do have passwords
[16:03:10 CET] <wm4> unless this turns into a piracy hotspot I see no problem
[16:03:12 CET] <iive> you do not want this service to be abused, do you?
[16:03:28 CET] <wm4> if someone sees his rights violated he can always contact the webmaster
[16:03:36 CET] <BtbN> The uploaded samples definitely should not be publicly accessible
[16:03:46 CET] <BtbN> Otherwise someone could abuse it to share illegal shit
[16:03:49 CET] <Compn> i notified j-b about abuse potential
[16:03:51 CET] <wm4> iive: well why would it... pirates use torrents, facebook, or wikipedia for such things
[16:03:55 CET] <Compn> did not get response...
[16:04:24 CET] <iive> torrents are often filtered by ISP
[16:04:36 CET] <iive> this is why download sites are so popular.
[16:05:06 CET] <iive> wikipedia is very strict about licenses
[16:05:56 CET] <wm4> are wikipedia uploads private at first?
[16:06:20 CET] <iive> no idea about facebook, but i think they are into freebooting, aka streaming from their own.
[16:07:29 CET] <iive> i've never seen anything pirated on wikipedia.
[16:07:55 CET] <durandal_1707> i see pirated knowledge
[16:08:09 CET] <iive> even in articles about tv shows you can rarely see pictures from them.
[16:09:15 CET] <Compn> wikipedia goes to great lengths to check copyright of uploaded images
[16:09:27 CET] <Compn> mostly a guy who asks if it has copyright heh
[16:09:58 CET] <BtbN> sounds like a full time job for Wikipedia
[16:09:59 CET] <wm4> the samples are just files for testing
[16:10:25 CET] <wm4> and also the uploader makes them already public, right?
[16:20:08 CET] <iive> i don't get the point of the last question.
[16:27:51 CET] <Chloe> do we really need to worry about this? Add something underneath the upload button which says something similar to 'by uploading you are stating that you are able to and allow ffmpeg to host this file for testing purposes'
[16:28:04 CET] <Chloe> how about adding*
[16:32:52 CET] <wm4> Chloe: agreed
[16:33:08 CET] <wm4> but I guess the webmaster or whoever maintains this should decide
[16:33:19 CET] <Compn> where in ffmpeg docs do we mentions samples are private ?
[16:33:23 CET] <Compn> this sounds like unwritten rule.
[16:33:39 CET] <Chloe> samples shouldnt be private if at all possible anyway
[16:33:52 CET] <Chloe> (that's sorta the point of having public samples)
[17:05:47 CET] <BBB> is that cinepak dude on irc?
[17:05:52 CET] <philipl> BBB: That would require a bunch of work all over the place. I'd just stop mapping this nvenc format to anything on the ffmpeg side.
[17:08:15 CET] <atomnuker> BBB: no, but someone better respond to him nicely before I call him an idiot
[17:09:45 CET] <BBB> dont call him an idiot
[17:09:55 CET] <BBB> I think what hes trying to do might make sense, just in a different way
[17:11:27 CET] <wm4> it's a performance hack
[17:12:22 CET] <nevcairiel> who even cares about cinepak, not to mention crap like rgb545 output
[17:12:44 CET] <nevcairiel> 565 or whatever its called
[17:13:57 CET] <nevcairiel> anyway it should definitely not start including ugly hacks for some niche use-cases
[17:14:38 CET] <wm4> 565 is 16 bit per pixels, which he mentioned specifically as a performance gain
[17:14:48 CET] <wm4> so he probably likes that one
[17:15:50 CET] <nevcairiel> why does his original mail say 20% and the latest mail claims "twice"?
[17:15:52 CET] <j-b> but what is the data in?
[17:19:39 CET] <durandal_1707> pure black
[17:20:01 CET] <cone-399> ffmpeg 03addr-see-the-website at aetey.se 07master:712ad6b66109: libavcodec/cinepakenc.c: comments cleanup (contents)
[17:20:15 CET] <j-b> no name?
[17:20:52 CET] <wm4> you didn't know that "Addr" is a popular swedish given name
[17:20:54 CET] <wm4> ?
[17:21:15 CET] <michaelni> j-b, i asked the author, and that author value was intended by him
[17:21:52 CET] <durandal_1707> we should disallow such contributions
[17:22:26 CET] <wm4> durandal_1707: how do we know yours is your real name
[17:23:13 CET] <michaelni> durandal_1707, we could, if people want, we may loose some contributions though
[17:23:52 CET] <durandal_1707> wm4: because im handsome and cool in rl
[17:31:02 CET] <kierank> wm4: he shouldn't be doing rgb->yuv in adecoder
[17:31:06 CET] <kierank> that's ridiculous
[17:31:20 CET] <nevcairiel> isnt that what wm4 said on the ml basically
[17:31:50 CET] <kierank> ah just now
[17:31:50 CET] <kierank> ok good
[17:32:09 CET] <wm4> I really wonder what he needs a fast cinepak decoder for
[17:32:13 CET] <wm4> and 16 bit RGB output
[17:32:16 CET] <kierank> CINEPAK_OUTPUT_FORMAT_OVERRIDE
[17:32:17 CET] <kierank> wtf
[17:32:28 CET] <wm4> yeah...
[17:32:42 CET] <nevcairiel> sounds like something from 20 decades ago
[17:32:51 CET] <nevcairiel> old-ass systems which need micro-optimizations for silly formats
[17:32:56 CET] <nevcairiel> 2 decades, 20 years
[17:32:59 CET] <nevcairiel> i got confused
[17:35:08 CET] <durandal_1707> buy him faster machine
[17:35:20 CET] <nevcairiel> it feels like some specific hack for one specific use-case that noone else is ever going to benefit from
[17:35:50 CET] <wm4> indeed
[17:36:11 CET] <jkqxz> I could just about believe it for decoding straight into a framebuffer on some embedded thing.
[17:36:13 CET] <wm4> but if you said that he'd immediately go into the defense etc.
[17:36:16 CET] <jkqxz> But yes, crazy-specific use-case.
[17:41:44 CET] <nevcairiel> he said something about mmx enabled cpu, so if its embedded then its probably some super old  system
[17:49:41 CET] <atomnuker> michaelni: some of our best contributors choose to remain anonymous
[17:50:13 CET] <atomnuker> they're the real selfless heroes
[17:50:45 CET] <RiCON> there wouldn't be a dts-hd decoder
[17:51:18 CET] <atomnuker> we wouldn't know elvis fucking presley was alive and doing multimedia stuff
[17:51:29 CET] <nevcairiel> everyone gotta have a hobby
[17:52:25 CET] <atomnuker> absolutely, and in case you've sold your soul to your employer you still gotta do what you love, even if its illegal (but unenforcable)
[17:52:45 CET] <wm4> atomnuker: like Elvis Presley?
[17:53:45 CET] <atomnuker> dunno what sort of a hole he was into, but he might have been a selfless hero instead of being stuck in a hole
[17:54:04 CET] <j-b> pseudonym and anonyms are different
[17:54:44 CET] <atomnuker> well there's no problem then, git forces you to use pseudonyms, no matter how weird they might be
[17:55:15 CET] <atomnuker> <%DROP TABLES = $STUDENTS>, e.g.
[17:56:42 CET] <kierank> atomnuker: https://beta.companieshouse.gov.uk/company/10542519
[17:56:48 CET] <kierank> that's an official company registration
[17:57:17 CET] <wm4> nice
[18:04:24 CET] <atomnuker> kierank: heh, MYVIHDEO was also a company name
[18:04:32 CET] <kierank> funny that
[18:10:13 CET] <iive> atomnuker: https://xkcd.com/327/ ?
[19:40:10 CET] <wm4> jkqxz: remind me, how does hardware store 10 bit formats?
[19:40:15 CET] <wm4> because https://patchwork.linuxtv.org/patch/38911/
[19:41:28 CET] <nevcairiel> Who knows how hardware stores it, but the P010 format is specified how Daniel Stone elaborates, a 16-bit format with 6 zeros.
[19:41:52 CET] <JEEB> yup
[19:42:32 CET] <wm4> nevcairiel: sure, but the problem is that this developer wants an actually packed format
[19:42:36 CET] <wm4> and wants P010 to mean this
[19:42:40 CET] <nevcairiel> then dont call  it P010
[19:42:43 CET] <nevcairiel> because thats just wrong
[19:43:12 CET] <wm4> I don't disagree
[19:44:41 CET] <wm4> anyway, the question is whether e.g. Intel hw plays weird MMU tricks here or so
[19:44:48 CET] <wm4> (I feel reminded of this tiled mess)
[19:45:11 CET] <jkqxz> Not inside pixels.
[19:45:37 CET] <jkqxz> The real format in memory is a 16-bit element with the low six bits zero.
[19:45:57 CET] <wm4> ok I guess a bit-twiddling MMU would have been way too far out there
[19:46:04 CET] <jkqxz> What order those elements are in may be harder to work out, though...
[19:52:16 CET] <JEEB> hmm
[19:52:39 CET] <JEEB> when new streams appear in input lavf_context->streams gets updated as well?
[19:52:56 CET] <nevcairiel> usually
[19:53:16 CET] <JEEB> alright
[19:53:20 CET] <kierank> jkqxz: a bit crap that it forces you to do chroma upsampling their way
[19:57:29 CET] <jkqxz> kierank:  ?
[19:57:39 CET] <kierank> from your 4:4:4 patch
[19:57:47 CET] <kierank> is that only for 4:4:4 video or for all video?
[19:59:12 CET] <jkqxz> I think you have incorrect IRC nick <-> person mapping.
[19:59:43 CET] <nevcairiel> better flush the table and start fresh
[19:59:45 CET] <kierank> whoops maybe
[19:59:49 CET] <kierank> my iommu is busted
[21:15:57 CET] <philipl> kierank: are you talking about my nvenc patch?
[21:16:05 CET] <kierank> yes
[21:20:25 CET] <cone-017> ffmpeg 03James Almer 07master:ab5c4d006da0: x86/vp8dsp: add ff_vp8_idct_dc_add_sse2
[21:26:27 CET] <philipl> This seems to be a surprisingly confusing topic.
[21:26:35 CET] <philipl> The hardware doesn't support >10bit inputs.
[21:26:56 CET] <philipl> Today, we present that the hardware's YUV444P10 input format is YUV444P16. This leads to undesirable results.
[21:26:59 CET] <philipl> This is not a surprise.
[21:27:02 CET] <philipl> s/present/pretend/
[21:54:41 CET] <cone-017> ffmpeg 03James Almer 07master:c8467abbadab: x86/rv34dsp: add ff_rv34_idct_dc_add_sse2
[00:00:00 CET] --- Fri Feb  3 2017