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

[burek]

[00:09:45 CET] <Chloe[m]> is there a better way of encoding data using huffman coding than: count the frequency of sequences, sort, make a binary tree, then encode data?
[00:10:36 CET] <Chloe[m]> maybe a way to incrementally build the tree while counting?
[00:12:41 CET] <jya> DHE: big bunny will do.. thanks for pointing that one out
[00:15:19 CET] <atomnuker> Chloe[m]: better? as in faster?
[00:16:13 CET] <kierank> Chloe[m]: arithmetic coding
[00:16:27 CET] <kierank> oh you mean encoding faster with huffman
[00:16:29 CET] <kierank> ignore me
[00:17:18 CET] <Chloe[m]> atomnuker: yeah
[00:20:12 CET] <atomnuker> hardcode the huffman table with whatever sequence occurs the most often?
[00:30:16 CET] <Chloe[m]> I was wondering if the method I described is the only way to do it without cheating :P
[00:31:55 CET] <iive> Chloe[m]:  cavlc ?
[00:33:43 CET] <cone-642> ffmpeg 03Carl Eugen Hoyos 07master:b1367f7e5e67: lavc/dpx: Support GRAY12 colourspace.
[00:34:44 CET] <Chloe[m]> iive: was just wondering about huffman, haven't started looking at anything else yet
[00:35:19 CET] <iive> what you ask sounds like dynamic huffman, aka rebuilding the tree after each symbol encoded.
[00:35:51 CET] <iive> or rather, just moving a branch.
[01:47:21 CET] <cone-642> ffmpeg 03Simon Thelen 07master:cd5da01daab7: doc/ffmpeg: add documentation for the disposition option
[02:14:53 CET] <cone-642> ffmpeg 03Kyle Swanson 07master:83b6b434fffc: lavfi/ebur128: use ff_ prefix
[02:38:11 CET] <cone-642> ffmpeg 03Dmitry Kalinkin 07master:dc23e359ef70: lavc/audiotoolboxdec: fix OSX SDK detection
[03:35:10 CET] <jamrial_> ubitux: your fate clients haven't run in almost two days
[08:45:25 CET] <cone-856> ffmpeg 03Rodger Combs 07master:f8e3ebde56e8: lavf/mux: don't warn about missing timestamps on attached pictures
[10:06:16 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:7c55fac7dfa8: fate: Add test for webp
[10:06:17 CET] <cone-856> ffmpeg 03Luca Barbato 07master:fe6e5cbea7db: ffv1: Remove version 2 and mark version 3 as non-experimental
[10:06:18 CET] <cone-856> ffmpeg 03Luca Barbato 07master:3c08b7bc761b: ffv1: Report additional bitstream information in verbose mode
[10:06:19 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:8ef6ba69c7f2: Merge commit '7c55fac7dfa8bad9644dea5d03309da30be69563'
[10:06:20 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:5a45f4d2b74b: Merge commit 'fe6e5cbea7dbd5d2c67d79b5570e26debb70e95b'
[10:06:21 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:a81b9c60125f: Merge commit '3c08b7bc761b6411f55db68189721638dde2c46a'
[10:15:30 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:8c929037ec75: build: Add a new component for H.264 parsing code
[10:15:31 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:575e8d11f1eb: Merge commit '8c929037ec75fbe9f367e0a31ee34839e92de481'
[10:29:28 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:3f1b5ca22ec3: lavu/pixfmt: Add GRAY10
[10:33:54 CET] <JEEB> heh,/28
[10:35:46 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:b5177c7051d1: lsws: Add GRAY10 conversion.
[10:38:08 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:0674d1938ef3: lavc/hevc_ps: Use correct pix_fmt for 10bit 4:0:0.
[10:44:39 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:fe27792fd779: build: Move ff_mpeg12_frame_rate_tab to a separate file
[10:44:40 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:9b4cc0f35c81: Merge commit 'fe27792fd779ac4cdd5e57be5f6f488483c307b2'
[10:51:12 CET] <cone-856> ffmpeg 03Martin Storsjö 07master:67cb2c0f73ec: checkasm: hevc: Iterate over features first, then over bitdepths
[10:51:13 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:cd70ffaac8b7: Merge commit '67cb2c0f73ec08bdcecd675c1ffe25c3a5b26ef2'
[11:33:05 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:e72d6fa08a3c: build: Move MP2 muxer declaration away from MP3 muxer code
[11:33:06 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:a0bc6b51d4f6: Merge commit 'e72d6fa08a3c1876109149401753a8d2c736d418'
[12:02:41 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:326d9116936a: build: Drop unnecessary libavcodec <-> libavformat object dependencies
[12:02:42 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:444e65299ba5: Merge commit '326d9116936ab61d13ac4142b49c7337daf7c4c0'
[12:16:19 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:eeb6849cedac: rle: K&R formatting cosmetics
[12:16:20 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:25004c7e6eaa: Merge commit 'eeb6849cedac099d41feb482da581f4059c63ca7'
[12:22:43 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:d8f3b0fb5846: targaenc: Move size check to initialization function
[12:22:44 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:bbd0ebfd8357: Merge commit 'd8f3b0fb584677d4882e3a2d7c28f8b15c7319f5'
[12:35:19 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:9f732e4c9962: tiffenc: Check av_pix_fmt_desc_get() return value
[12:35:20 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:6c445990e641: tiffenc: Check zlib support for deflate option during initialization
[12:35:21 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:bebab21176c1: Merge commit '9f732e4c996243c1e57c2bbbec6c8b94c37a7a22'
[12:35:22 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:985bc8b49683: Merge commit '6c445990e64124ad64c79423dfd3764520648c89'
[12:42:00 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:029cf99c5166: mov: Save number of stsd elements after stream extradata allocation
[12:42:01 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:d8ffdefbdce1: Merge commit '029cf99c5166b36f33381cd8ebfa5f1f1f463d1f'
[12:42:13 CET] <nevcairiel> that concludes the month of june. only a "few" more to go
[13:33:50 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:9648ce2a1895: lavf/Makefile: Fix rule for the data muxer.
[14:04:21 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:be3e807c8fad: oggparseopus: export pre-skip
[14:04:22 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:06136275e59c: Merge commit 'be3e807c8fad1f82766c083073e44396799f155b'
[14:25:01 CET] <ElAngelo> hi
[14:25:11 CET] <ElAngelo> if i would file a bug with a demo video 
[14:25:27 CET] <JEEB> that's usually called a sample
[14:25:36 CET] <ElAngelo> are there any licenses or legalities on that sample?
[14:25:53 CET] <JEEB> depends on a lot of things :P
[14:26:22 CET] <ElAngelo> quoting my client: And regarding sharing the file to ffmpeg team, they mentioned that they are not familiar with this organization and enquired is there assurance that these would not be misused?
[14:28:41 CET] <durandal_1707> what bug  is this about? 
[14:29:09 CET] <ElAngelo> i have a mov with a av1up stream that i can't get to play/re encode with ffmpeg
[14:29:38 CET] <ElAngelo> plays just fine with mplayer if i specify -demuxer mov
[14:29:41 CET] <JEEB> I think there are ways of providing samples in a more limited fashion, but generally (if only possible) you create a sample file that doesn't contain real content
[14:29:51 CET] <JEEB> or that's so short it doesn't matter
[14:30:17 CET] <ElAngelo> i guess i could try to only take the first few seconds
[14:30:32 CET] <ElAngelo> well
[14:30:40 CET] <ElAngelo> the only thing i can actually do is use dd
[14:30:48 CET] <ElAngelo> and cut off a couple of MB
[14:30:57 CET] <ElAngelo> but not sure how well this would work as a sample
[14:31:02 CET] <ElAngelo> ?
[14:31:20 CET] <JEEB> does the same thing happen?
[14:31:23 CET] <JEEB> that's the main thing
[14:31:30 CET] <JEEB> if you can replicate the thing that you think is a bug
[14:31:55 CET] <durandal_1707> For mov that usually not possible to use dd 
[14:32:10 CET] <JEEB> unless the index is in the beginning of course
[14:32:42 CET] <durandal_1707> correct 
[14:33:38 CET] <ElAngelo> nah it doesn't work
[14:33:54 CET] <ElAngelo> even mplayer now reports the file as broken
[14:34:55 CET] <jamrial> try qt-faststart maybe
[14:37:51 CET] <ElAngelo> problem is i can't re-encode the video with ffmpeg
[14:38:14 CET] <ElAngelo> and if i do with mplayer/mencoder, the problem goes away
[14:43:20 CET] <ubitux> ElAngelo: jamrial is suggesting to run qt-faststart on your sample, then make a dd cut
[14:43:32 CET] <ElAngelo> ah
[14:43:39 CET] <JEEB> that moves the index to the beginning
[14:43:43 CET] <ubitux> qt-faststart doesn't use ffmpeg api to move things around, it's a braindead memsearch cut & move 
[14:44:53 CET] <ubitux> jamrial: btw, my fate stuff was stalled in an infinite loop in the ddebug instance on segment thing, it should be fixed
[14:45:33 CET] <jamrial> ubitux: cool
[14:45:46 CET] <ubitux> at least i restarted it and it doesn't block anymore :p
[14:46:35 CET] <jamrial> haha
[14:47:11 CET] <jamrial> wonder if it was because -DEBUG -DTRACE makes ffmpeg log an absurd amount of debug lines
[14:49:52 CET] <jamrial> ubitux: you could also update it. you haven't run pacman on it for almost a year it seems, seeing how it's still at gcc 5.3
[14:50:08 CET] <nevcairiel> jamrial: since you've been poking mkv for a bit - the current merge i'm working on causes ffmpeg to always write audio bitdepth into mkv files on streamcopy (just because it now sets par->format all the time), even if its kinda pointless info like 32-bit on lossy float codecs, thoughts?  just accept it as fact and move on?
[14:50:17 CET] <ubitux> jamrial: yeah right, but i'm still trying to figure out the bitrot thing&
[14:50:28 CET] <ubitux> and i don't want to mix multiple parameters in
[14:50:46 CET] <ubitux> i recently swapped the active drive since i got bitrot with the previous one
[14:51:08 CET] <ubitux> if i don't get any more bitrot with that other drive active only i'll move on
[14:51:13 CET] <ubitux> but it's too early yet :)
[14:51:19 CET] <jamrial> ubitux: ah ok
[14:51:51 CET] <jamrial> nevcairiel: yeah, merge it as is. if needed that can be changed afterwards, but not as part of an avconv.c/ffmpeg.c merge
[14:54:46 CET] <nevcairiel> if you were encoding it would probably write that today anyway, so its  likely just more consistent
[15:07:19 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:b55566db4c51: avconv: use avcodec_parameters_copy() with streamcopy
[15:07:20 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:166f2c52ace4: Merge commit 'b55566db4c51d920a6496455bb30a608e5a50a41'
[15:08:29 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:b7c5f885233a: pixfmt: add P010 pixel format
[15:08:30 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:8fee823fe8fb: Merge commit 'b7c5f885233a7b8692140c920d9f43220dc830d9'
[15:09:47 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:e78e5b735fd5: swscale: add P010 input support
[15:09:48 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:d4509495bfa2: Merge commit 'e78e5b735fd559bc7aa3f5a01e9c8d37dc2ec6d8'
[15:15:32 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:2ef87815fec0: hwcontext_dxva2: add support for p010
[15:15:32 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:3dfe97a841fe: Merge commit '2ef87815fec059504370ae3050cc243a53553915'
[15:17:12 CET] <cone-856> ffmpeg 03Mark Thompson 07master:4926fa9a4aa0: hwcontext_vaapi: Add driver quirks to the hwdevice
[15:17:13 CET] <cone-856> ffmpeg 03Mark Thompson 07master:221ffca6314e: vaapi_encode: Respect driver quirks around buffer destruction
[15:17:14 CET] <cone-856> ffmpeg 03Mark Thompson 07master:582d4211e000: vf_scale_vaapi: Respect driver quirks around buffer destruction
[15:17:15 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:6ace05beec17: Merge commit '4926fa9a4aa03f3b751f52e900b9efb87fea0591'
[15:17:16 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:190254f8810f: Merge commit '221ffca6314ed3ba9d38464ea50cd85251c04e74'
[15:17:17 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:745a44ee6130: Merge commit '582d4211e00015b68626f77ce4af53161e2b1713'
[15:18:42 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:40f74dc87acb: matroskadec: export CodecDelay
[15:18:43 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:15352568132c: Merge commit '40f74dc87acb3f5bbb51f273790a4a7a64201b16'
[15:18:56 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:d20c11897522: hwcontext_qsv: add support for p010
[15:18:57 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:e122a725fbe9: Merge commit 'd20c118975220a0256027d1c2410bade94b8534d'
[15:20:26 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:536bb17e9659: qsvdec: make ff_qsv_map_pixfmt() return a MFX fourcc as well
[15:20:27 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:ce320cf1c4da: qsvdec: use the same mfxFrameInfo for allocating frames that was passed to DECODE_Init
[15:20:28 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:92736c74fb16: qsvdec: add support for P010 (10-bit 420) decoding
[15:20:29 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:924e2ecd2b7d: qsvdec: when a frames ctx is supplied, use its frame dimensions
[15:20:30 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:1bc6cdf2fcbd: Merge commit '536bb17e9659c5ed7576a218d4085cdd6d5742fa'
[15:20:30 CET] <trn> /\\/go
[15:20:31 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:220e77391552: Merge commit 'ce320cf1c4daab3e2e3726ed7d2e879d10f7b991'
[15:20:32 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:3c81fa9a9c5f: Merge commit '92736c74fb1633e36f7134a880422a9b7db14d3f'
[15:20:33 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:68b0d7e0be66: Merge commit '924e2ecd2b7d51cca60c79351ef16b04dd4245c3'
[15:21:31 CET] <cone-856> ffmpeg 03Martin Storsjö 07master:dc08bbf63a21: vp8dsp: Clarify the first dimension of the mc function tables
[15:21:32 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:5a447edd475a: Merge commit 'dc08bbf63a217c839aa4c143f2a1d0b7e2e6d997'
[15:22:00 CET] <cone-856> ffmpeg 03Martin Storsjö 07master:e8b96a77010d: arm: Fix a typo in a comment
[15:22:01 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:51f5542c776a: Merge commit 'e8b96a77010dd62624c3c65c357d7ae3b397ceaa'
[15:29:39 CET] <cone-856> ffmpeg 03Martin Storsjö 07master:f8d17d539570: checkasm: Add tests for vp8dsp
[15:29:40 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:47f75839e499: Merge commit 'f8d17d53957056c053a46f9320fa7ae6fe1479a5'
[17:00:17 CET] <ubitux> note: i'm not going to the internal debate with Nicolas for much longer so anyone caring should probably take over
[17:00:26 CET] <ubitux> to continue*
[17:05:43 CET] <JEEB> Y
[17:15:05 CET] <nevcairiel> any discussions with him are generally always pointless, he has zero capability for compromise
[17:15:41 CET] <nevcairiel> should adopt his style of arguments and just go "Rejected." as well
[17:32:12 CET] <iive> ubitux: what do you mean by bitrot on hdd? if data is corrupted, then it will give io errors. If not it is most likely that the host has sent the data wrong, aka RAM error.
[17:32:54 CET] <ubitux> iive: there is no IO error
[17:33:08 CET] <ubitux> the data bitroting is also already written
[17:33:23 CET] <ubitux> so there is no reason it would change even with a RAM issue (IMO, but could be)
[17:33:48 CET] <ubitux> basically: some FATE samples randomly get bit flips
[17:34:00 CET] <ubitux> (and probably other files)
[17:34:20 CET] <ubitux> now i'm assuming a firmware issue in one of the disk
[17:34:33 CET] <nevcairiel> data stored on hdds can most definiteily bitrot without being read or written, but its usually very rare and for you it happens all the time
[17:35:01 CET] <microchip_> nevcairiel: wrong chan, try #ffmpeg :p
[17:35:01 CET] <atomnuker> rotational velocidensity's making our lossy fate samples fail!
[17:35:21 CET] <ubitux> nevcairiel: "all the time" maybe not, but often yes
[17:35:32 CET] <ubitux> at some point it was one or two detected a week
[17:35:34 CET] <iive> data is protected with RS sums
[17:35:56 CET] <ubitux> it went down a lot when removing one disk from the raid, but it still happened
[17:35:56 CET] <microchip_> ubitux: often? i've never seen it here
[17:36:03 CET] <ubitux> so now i'm on the second disk
[17:36:03 CET] <microchip_> ubitux: doesn't mean much, tho ;)
[17:36:06 CET] <iive> so you must get io errors
[17:36:15 CET] <ubitux> microchip_: try grep 'ubitux.*bitflip'
[17:36:20 CET] <ubitux> iive: no i don't
[17:36:33 CET] <microchip_> k
[17:36:37 CET] <ubitux> for now my biggest hypothesis is a buggy hd firmware
[17:36:59 CET] <microchip_> ubitux: hope you don't use seagate :p
[17:37:08 CET] <iive> ubitux: also is it 1 time thing, or when it goes bad, it stays bad?
[17:37:13 CET] <ubitux> microchip_: one is a seagate, the other is a WD
[17:37:18 CET] <ubitux> microchip_: so yeah, the 2 worst in the world
[17:37:24 CET] <microchip_> heh
[17:37:33 CET] <microchip_> hitachi! ftw i guess
[17:37:38 CET] <ubitux> iive: file stays bitflipped
[17:37:54 CET] <nevcairiel> isnt hitachi wd now
[17:37:56 CET] <ubitux> (and because fate rsync doesn't check file integrity the file is not corrected)
[17:38:12 CET] <microchip_> nevcairiel: it is, but they operate on their own, afaik
[17:38:45 CET] <nevcairiel> i think they mostly merged in 2015 or so
[17:39:42 CET] <iive> ubitux: does it change files that have been working?
[17:39:52 CET] <ubitux> yes
[18:06:20 CET] <iive> ubitux: this is very strange, as i said, raw data on hdd is written using RS checksums so it will detect errors. while in theory it is possible that there is damage that somehow produces working checksum, it's not possible for this to happen all the time.
[18:06:40 CET] <ubitux> but it does
[18:06:52 CET] <ubitux> hence the suggestion that the HD firmware is buggy
[18:06:55 CET] <iive> it could only mean that something is overwriting data.
[18:07:14 CET] <iive> have you chacked how much data is changed. aka one bit or whole sector?
[18:07:29 CET] <ubitux> i haven't, only per-file
[18:07:37 CET] <nevcairiel> bitflips on physical drives do happen, or why else would anyone ever bother to implement extra checksums in the file system if the hdd itself does all the work :D
[18:08:14 CET] <phh> actually, I think only btrfs (and perhaps zfs?) has data checksum
[18:08:26 CET] <phh> and it's optional
[18:08:30 CET] <iive> nevcairiel: but bitflips that remain undetected and does not produce ioerrors... is like winning every lotery game.
[18:09:22 CET] <iive> it might be possible that a sector is written in the wrong location
[18:09:39 CET] <nevcairiel> thats why the specified read error rate of hdds is usually something like 10^14 or so
[18:09:58 CET] <nevcairiel> and from what we have seen, it was single bits, in some cases ascii chars turned into another
[18:11:19 CET] <iive> i wonder if hdds write individual sectors or whole track at once
[18:11:59 CET] <iive> if it is the later, then the hdd would read the track and write it again. during this process it could flip bits.
[18:13:55 CET] <iive> ubitux: btw, what filesystem is used and is there llvm?
[18:20:00 CET] <ubitux> iive: ext4, no llvm
[19:17:08 CET] <cone-856> ffmpeg 03James Almer 07master:2d9433ded9a8: doc/codecs.texi: add new and missing color related options
[20:32:39 CET] <llogan> michaelni: do you know the subject of auto generated docs discussion? I have absolutely no memory of this.
[20:32:52 CET] <nevcairiel> me neither
[20:34:10 CET] <michaelni> its long ago, i dont remember the subject
[21:01:07 CET] <michaelni> llogan, nevcairiel maybe it was this: "[FFmpeg-devel] [PATCH 1/2] doc: do not generate doc/avoptions_(codecs|formats).texi"
[21:04:01 CET] <llogan> thanks
[21:13:48 CET] <llogan> lazy man question: does the Libav auto gen docs allow for manual additions?
[21:25:54 CET] <michaelni> i dont remember any manual intervention support but i didnt touch the tool for a long time ...
[22:03:13 CET] <cone-856> ffmpeg 03Martin Vignali 07master:d0d6902444ea: doc/filters: add metadata information for blackframe
[22:58:12 CET] <cone-856> ffmpeg 03Andreas Cadhalpun 07master:0edd569466eb: softfloat: handle -INT_MAX correctly
[23:35:17 CET] <jkqxz> nevcairiel:  Could mesa be doing something naughty with the slices there?  That sample really does work with both VAAPI and VDPAU on mesa.  (On Intel, I get output that looks like only one slice of three or four decoded.)
[23:35:36 CET] <nevcairiel> maybe it just parses the start codes in the bitstream buffer
[23:35:40 CET] <nevcairiel> it gets all slices in one slice buffer
[23:35:41 CET] <jkqxz> I assume a person with an Intel email address can't possibly be testing on only non-Intel...
[23:35:42 CET] <nevcairiel> so its possible
[23:47:55 CET] <jkqxz> Fun.
[23:48:28 CET] <jkqxz> Your dxva2 is Nvidia there?
[23:48:52 CET] <nevcairiel> yes
[23:49:14 CET] <nevcairiel> but the dxva2 vc1 code isnt even setup to receive multiple slices, i'm trying if i can make it work
[00:00:00 CET] --- Tue Nov 15 2016