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

[burek]

[00:02:29 CET] <BtbN> https://community.amd.com/community/gaming/blog/2017/03/13/amd-ryzen-community-update?sf62107357=1 AMD please... "Specifically, the AMD Ryzen" 7 1700X and 1800X carry a +20°C offset between the tCTL° (reported) temperature and the actual Tj° temperature. In the short term, users of the AMD Ryzen" 1700X and 1800X can simply subtract 20°C to determine the true junction temperature of their processor."
[00:02:53 CET] <BtbN> They could at least have made their software substract that again
[00:03:04 CET] <BtbN> countless people are desperately trying to fix their cooling
[00:04:40 CET] <iive> LOL
[00:05:21 CET] <nevcairiel> the entire page is full of "our stuff works fine, re-write your software" =p
[00:05:22 CET] <JEEB> :D
[00:05:57 CET] <BtbN> Well, except for the weird temperature, which is explained by that, I didn't have any issues with the CPU itself
[00:06:02 CET] <BtbN> Only the Mainboard behaves weird
[00:06:13 CET] <BtbN> Do one wrong setting, and you have to perform some voodoo to make it boot again
[00:06:20 CET] <BtbN> Clear CMOS does not clear the CMOS all the time
[00:06:28 CET] <nevcairiel> everyone has been blaming performance issues on the scheduling, and amd just says "its fine", guess they need a new rumor
[00:06:40 CET] <BtbN> There are no performance issues
[00:06:53 CET] <BtbN> A CPU with slightly worse IPS, on a lower clock, is bound to be slower.
[00:07:03 CET] <nevcairiel> tell that to everyone else
[00:07:04 CET] <BtbN> It performs exactly as I'd have expected.
[00:07:16 CET] <BtbN> *IPC
[00:07:50 CET] <BtbN> Lets just hope they push the 4 core variant to 4GHz+ on stock settings
[00:07:56 CET] <nevcairiel> I mean, just days ago your claimed that there were issues yourself
[00:07:57 CET] <nevcairiel> :)
[00:07:59 CET] <BtbN> A 3.6GHz Quad Core will have a hard time otherwise
[00:08:07 CET] <BtbN> Performance issues?
[00:08:16 CET] <nevcairiel> its a cpu, what else can there be
[00:08:23 CET] <BtbN> Way too high temperature
[00:08:28 CET] <nevcairiel> [22:05:46] <BtbN> Windows still has massive issues with the NUMA like architecture of Ryzen
[00:08:28 CET] <nevcairiel> [22:05:55] <BtbN> And with the asymetric SMT
[00:08:28 CET] <BtbN> which is explained by the CPU adding 20°
[00:08:31 CET] <nevcairiel> thats what i meant ^
[00:08:43 CET] <nevcairiel> AMD says all is fine, apparently
[00:08:50 CET] <BtbN> ah, that
[00:09:04 CET] <BtbN> Yeah, the Ryzen 8 core is basically two 4 core CPUs in a NUMA-Like setup
[00:09:16 CET] <BtbN> so migrating threads between the first 4 cores to the last 4 ones is slow
[00:09:46 CET] <BtbN> OS scheduler does not seem to address that yet
[00:09:51 CET] <BtbN> But under full load it doesn't matter
[00:10:00 CET] <nevcairiel> seems like a dumb design if you make the bus between those so slow that its noticeable
[00:10:24 CET] <iive> BtbN: NUMA on a single core?!
[00:10:36 CET] <iive> i mean, sincle CPU die
[00:10:38 CET] <nevcairiel> that AMD page still claims all is fine with scheduling
[00:11:08 CET] <BtbN> Probably only time will tell what actual performance there is to gain by scheduler-patches
[00:11:24 CET] <nevcairiel> its because the two core complexes don't fully share the caches
[00:12:24 CET] <nevcairiel> L3 cache is local to a core-complex (ie. a 4 core unit)
[00:13:00 CET] <nevcairiel> while intel cpus have a central shared L3 for all cores
[00:13:49 CET] <iive> is l3 the closest to cpu or the one further?
[00:13:56 CET] <BtbN> L1 is closest
[00:13:57 CET] <nevcairiel> l3 is the furthest
[00:14:01 CET] <iive> i think l1 should be closest
[00:14:13 CET] <nevcairiel> L1 and L2 are linked to one core only, though
[00:14:19 CET] <BtbN> http://valid.x86.fr/hqdvq3
[00:14:47 CET] <BtbN> shows the Caches in the screenshot
[00:14:48 CET] <nevcairiel> L3 is typically the only cache shared between cores
[00:15:01 CET] <BtbN> Yeah, it has 2x8192kB
[00:15:07 CET] <nevcairiel> but on ryzen its only shared between half the cores
[00:15:11 CET] <BtbN> so 8MB for each 4 core cluster
[00:15:25 CET] <iive> so, 8 core version is actually 2xCPU(4cores) that run in NUMA?
[00:15:32 CET] <BtbN> Not actual NUMA
[00:15:46 CET] <BtbN> But if a thread gets migrated accross the clusters, the L3 cache is lost/need to ge moved
[00:15:51 CET] <BtbN> *be
[00:16:07 CET] <iive> maybe that's the problem. actual numa cares care of such migrations.
[00:16:17 CET] <BtbN> Windows is not good at actual NUMA
[00:16:18 CET] <iive> btw, do you have numa enabled in the kernel?
[00:16:40 CET] <BtbN> No idea what microsoft enables in their Kernel
[00:16:52 CET] <iive> BtbN: you don't run linux?
[00:16:56 CET] <BtbN> no
[00:17:04 CET] <iive> sorry, for assuming that.
[00:18:14 CET] <iive> at least in the past, microsoft enabled different kernels, depending on the cpu during installation.
[00:18:31 CET] <iive> no idea if they are unified now, or if they allow change after install.
[00:18:43 CET] <nevcairiel> there are ways to change, but its tricky
[00:18:46 CET] <BtbN> They only need to slightly change scheduler policy
[00:18:57 CET] <nevcairiel> but AMD said its fine
[00:18:57 CET] <nevcairiel> :p
[00:19:07 CET] <iive> no
[00:19:08 CET] <BtbN> It tends to move threads around on single-core loads
[00:19:21 CET] <BtbN> So they need to teach it to only do that on the same cluster
[00:20:55 CET] <iive> what flavor of windows are you running? desktop, server ?
[00:20:59 CET] <BtbN> 10
[00:21:19 CET] <BtbN> Not going to touch 8/8.1
[00:21:23 CET] <BtbN> And Win7 is a nightmare
[00:21:41 CET] <BtbN> Spent an entire day installing Win7 on a friends new 1700X system
[00:22:06 CET] <BtbN> need to splitstream the USB drivers into the installer. Otherwise you have no mouse and keyboard
[00:22:29 CET] <iive> ?
[00:22:32 CET] <nevcairiel> you can usually cheat by putting the mainboard into legacy usb mode
[00:22:36 CET] <BtbN> No
[00:22:42 CET] <nevcairiel> at least on intel boards that option exists
[00:22:48 CET] <BtbN> The AM4 platform has no EHCI mode anymore
[00:22:57 CET] <BtbN> everything, even the USB2 controlers, run via XHCI
[00:23:03 CET] <nevcairiel> seems like a silly idea to strip that
[00:23:13 CET] <BtbN> It's normal, the Kaby Lake platform does the same
[00:23:24 CET] <BtbN> You have the same issues installing Win7 there
[00:23:31 CET] <iive> win7 needs another service pack
[00:23:41 CET] <BtbN> Microsoft wants it to die
[00:23:42 CET] <nevcairiel> my Z170  board at least still had the uefi option to enable legacy usb
[00:23:45 CET] <BtbN> so not going to happen
[00:23:47 CET] <rcombs> does anyone have a DTS-HD sample that actually requires 8-channel SPDIF bandwidth?
[00:24:04 CET] <BtbN> You can enable legacy USB, but it has no effect on stuff booted in UEFI mode
[00:24:09 CET] <iive> yeh, but i'm not touching 8 or 10.
[00:24:13 CET] <BtbN> And to install on an NVMe drive, you are bount to use UEFI boot
[00:24:22 CET] <BtbN> *bound
[00:26:21 CET] <iive> what is nvme drive? non volatile memory? ssd ? flash? NAND/NOR ?
[00:27:38 CET] <nevcairiel> NVMe drives are PCIe based SSDs
[00:28:35 CET] <iive> do they allow directly mapping NAND memory into address space?
[00:29:14 CET] <nevcairiel> rcombs: i dont know about needing full bandwidth, but there is really no point, its either SPDIF which is limited to non-HD formats anyway, or its HDMI, which supports full bandwidth either way
[00:29:35 CET] <wm4> "Is there someone trying to upgrade the crystalhd code? This device is old, but is still useful. I hope I'm not the only one using it."
[00:29:43 CET] <wm4> I'm afraid that might be the case...
[00:30:01 CET] <rcombs> nevcairiel: in theory SPDIF is limited to non-HD-only, but some HD bitstreams fit anyway
[00:30:24 CET] <rcombs> nevcairiel: and some fit in 6 channels but not 8, and some devices support 6-channel output bandwidth but not 8-channel over HDMI for whatever reason
[00:30:25 CET] <wm4> <rcombs> does anyone have a DTS-HD sample that actually requires 8-channel SPDIF bandwidth? <- I thought all dts-hd does
[00:30:46 CET] <nevcairiel> rcombs: screw special device hacks, call it a day
[00:30:57 CET] <nevcairiel> support full HDMI specs, and not some cheap crap that implements them wrong
[00:31:01 CET] <wm4> and I never heard about using 6 channels for that
[00:31:17 CET] <nevcairiel> me neither
[00:31:17 CET] <rcombs> lavf has code for it in spdifenc
[00:31:19 CET] <iive> wm4: the rule is, for everybody who complains there are 9 that do not.
[00:31:22 CET] <nevcairiel> DTS-HD always transmit from 8ch 192khz  for me
[00:32:00 CET] <wm4> the lavf cares only about output bitrate
[00:32:08 CET] <wm4> which you adjust via dtshd_rate
[00:32:08 CET] <rcombs> see spdif_header_dts4
[00:32:35 CET] <rcombs> if you get packets too big then it strips to core
[00:32:38 CET] <nevcairiel> i always set dtshd_rate to 768000 to get it into mode 4
[00:32:49 CET] <wm4> me too
[00:33:57 CET] <nevcairiel> the only thing i keep getting reports of not working reliably is E-AC3
[00:34:09 CET] <nevcairiel> but all hardware i have it works on, so :(
[00:35:02 CET] <wm4> I got reports that passing dts-core via 8 spdif channels doesn't always work, so I need to know the dts profile
[00:35:06 CET] <wm4> which is slightly annoying
[00:35:12 CET] <nevcairiel> yeah i do that too
[00:35:29 CET] <nevcairiel> switch into non-HD mode for core streams
[00:35:33 CET] <rcombs> macOS is whacky about it
[00:35:39 CET] <rcombs> on like the Mac Mini
[00:35:45 CET] <nevcairiel> its mac, its hardly a good multimedia os
[00:35:46 CET] <wm4> and last but not least, fuck spdif passthrough and HDMI, it's all horrid consumer garbage
[00:35:58 CET] <nevcairiel> indeed
[00:36:06 CET] <rcombs> and apparently the Roku will refuse to passthrough DTS iff the MKV-specified channel count is > 6
[00:36:15 CET] <wm4> lol
[00:36:26 CET] <rcombs> but if you give it a DTS-HD stream with 8 channels, but propedit the mkv to say 6 channels, it works
[00:36:27 CET] <nevcairiel> I don't use it myself, but people kept pestering me and the lavf spdifenc did all the hard work, soo
[00:36:38 CET] <nevcairiel> roku is crap hardware, did noone tell you? :)
[00:36:42 CET] <rcombs> I know
[00:36:44 CET] <nevcairiel> it has all sorts of such funny things in it
[00:36:46 CET] <rcombs> but ~users~
[00:36:58 CET] <rcombs> so I want to find out if it blows up if you give it a stream with too-high a bitrate
[00:37:14 CET] <rcombs> spdifenc comment says      * This generally only happens if the caller is cramming a Master     * Audio stream into 192kHz IEC 60958 (which may or may not fit). */
[00:37:36 CET] <nevcairiel> in my tests trying to use any other output configuration didnt really work at all
[00:37:39 CET] <rcombs> Roku has HDMI out but I guess sorta pretends it's SPDIF optical/coax?
[00:37:53 CET] <nevcairiel> but then i only work with windows, and not some crazy STBs running who-knows-what
[00:38:02 CET] <rcombs> maybe because it thinks you might be using a SPDIF passthrough out on the TV
[00:38:10 CET] <rcombs> or, remind me, what bandwidth does HDMI ARC have
[00:38:20 CET] <nevcairiel> basic spdif i think
[00:38:25 CET] <nevcairiel> it gets HD support in HDMI 2.1
[00:39:04 CET] <rcombs> thought so
[00:39:18 CET] <rcombs> oh lol
[00:39:34 CET] <rcombs> apparently if you give Roku an 8-channel file pretending to be 6, it strips it to the core bitstream
[00:39:55 CET] <nevcairiel> at least its consistent about failing
[00:40:26 CET] <rcombs> but if you give it 8 that's honest about being 8 then on some models it plays silent audio, and on some models it refuses to play
[00:40:40 CET] <rcombs> despite apparently being entirely capable of stripping to core when it needs to
[00:40:42 CET] <rcombs> wtf even
[00:41:06 CET] <rcombs> well I guess I'll use the dts_core bsf and fix it to set the channel count in codecpar
[00:41:21 CET] <rcombs> by looking at the input channel layout and masking out the channels that aren't in core
[00:41:59 CET] <nevcairiel> The worst i get exposed to is having to deal with DLNA capabilities of all those crappy STBs, and luckily thats not really my area, a colleague mostly deals with that
[00:43:37 CET] <wm4> well, a player should not read those matroska headers in the first place for dts
[00:43:54 CET] <Compn> dnla is such a major pita
[00:44:00 CET] <nevcairiel> its one of those things thats just not specified
[00:44:02 CET] <rcombs> DLNA is so bad
[00:44:12 CET] <nevcairiel> clearly a coded bitstream takes precedence over some container info
[00:44:17 CET] <Compn> how can it be worse to setup than ftp server :\
[00:44:31 CET] <nevcairiel> but then crazy people try to use container info to augment bitstream info
[00:45:05 CET] <nevcairiel> is specifying 6 channels in the container for a 8 channel audio  then "audio cropping"? :D
[00:49:23 CET] <wm4> well, a DTS decoder could of course downmix the audio to 6 channels, or something
[00:49:30 CET] <wm4> (whatever it does)
[00:50:03 CET] <nevcairiel> well with DTS thats even a acceptable solution since commercial DTS encodes often have downmix coefficients
[00:50:46 CET] <wm4> (are there non-commercial DTS encodes)
[00:51:02 CET] <nevcairiel> probably not
[00:51:07 CET] <rcombs> isn't it often that the core is the 6-channel downmix, and then xch/xxch/whatever adds the back channels and replaces the side ones?
[00:51:17 CET] <nevcairiel> but some people steal the dts encoder and then probably dont use it right
[00:51:26 CET] <rcombs> or am I thinking of the blu-ray eac3/ac3 thing
[00:51:36 CET] <nevcairiel> nah dts works similar
[00:51:49 CET] <wm4> is it as horrible as mixed ac3/eac3
[00:52:53 CET] <nevcairiel> in case of lossless DTS-HD MA: decode the core, un-downmix the 6ch with some coefficients, decode residuals from the XLL extensions to generate lossless
[00:53:28 CET] <rcombs> ah, so it doesn't actually _replace_ the channels so much as& augment them, I guess
[00:53:37 CET] <nevcairiel> yeah
[00:53:37 CET] <rcombs> DTS is all about dat matrix coding
[00:53:45 CET] <nevcairiel> the bluray ac3/eac3 thing is worse
[00:53:53 CET] <nevcairiel> actually encodes 10 channels just to throw away 2
[00:54:12 CET] <nevcairiel> luckily its super rare
[00:54:27 CET] <nevcairiel> havent had a request for that in ages
[00:54:33 CET] <rcombs> same
[00:54:55 CET] <rcombs> isn't DTS core like, 6-band ADPCM or something
[00:55:01 CET] <rcombs> something trivial
[00:55:10 CET] <nevcairiel> its some form of adpcm iirc
[00:55:19 CET] <nevcairiel> with extra shit on top
[00:55:22 CET] <rcombs> no real psy or anything?
[00:55:35 CET] <rcombs> I guess that makes it easy to do residual coding at least
[00:55:46 CET] <wm4> imagine blurays would ship cinepak, but highly patented and obfuscated
[00:56:00 CET] <rcombs> lolcinepakman
[00:56:13 CET] <nevcairiel> core dts is definitely not the most advanced format, which is why its base bitrates are also so high
[00:56:16 CET] <iive> BtbN: do you have some nice article, where they explain how did they finally got Instructions per Cycle count that is closer to intel?
[00:56:26 CET] <nevcairiel> you know how ac3 goes to 640kbps,  and dts core to 1.5mbps
[00:56:59 CET] <rcombs> yup
[00:57:05 CET] <rcombs> "just throw more bits at it"
[00:57:15 CET] <rcombs> and then people claim DTS is better because it has a higher max rate
[00:57:22 CET] <TD-Linux> wm4, they would also ship indeo and bink to be "fair"
[00:57:23 CET] <rcombs> (not saying AC3 isn't shit)
[00:57:30 CET] <nevcairiel> yeah
[00:57:48 CET] <nevcairiel> Just today I had some guy asking about our choice of aac bitrate for stereo audio encodes in video transcoding
[00:58:10 CET] <nevcairiel> he was like, my source has 320kbps mp3, why do you only use 224kbps, thats going to sound terrible
[00:58:20 CET] <nevcairiel> 224kbps for aac stereo is outrageously high, but ok
[00:58:54 CET] <rcombs> max is 258kbps at 48kHz
[00:58:59 CET] <rcombs> so couldn't do 320 even if you wanted to
[00:59:20 CET] <rcombs> lol mp3 with video, though
[00:59:27 CET] <rcombs> what is this, 2002
[00:59:30 CET] <nevcairiel> probably
[00:59:39 CET] <wm4> used to be really common with xvid
[00:59:39 CET] <nevcairiel> i mean, old videos exist of course
[00:59:51 CET] <rcombs> sure
[00:59:57 CET] <wm4> though no idea what rates they used
[01:00:03 CET] <rcombs> y'know I still get people complaining about weird AVI shit
[01:00:05 CET] <nevcairiel> 128 for stereo probably =p
[01:00:12 CET] <rcombs> with MPEG-4 Part 2 and MP3 audio
[01:00:19 CET] <rcombs> apparently people are still making those
[01:00:22 CET] <rcombs> fuck if I know why
[01:00:31 CET] <nevcairiel> what do scene SD encodes uses these days
[01:00:35 CET] <rcombs> that
[01:00:40 CET] <JEEB> I think the rules did add AVC
[01:00:50 CET] <JEEB> but yea, still you see MPEG-4 Part 2
[01:00:50 CET] <rcombs> yeah it's allowed and some people do it
[01:00:56 CET] <rcombs> but part 2 encodes are still common
[01:01:04 CET] <nevcairiel> just call it xvid, will ya  =p
[01:01:21 CET] <rcombs> these are the same people who split an mkv into a bunch of rars and then put them in a torrent, though
[01:01:27 CET] <rcombs> I shouldn't expect competency
[01:02:28 CET] <wm4> they do that?
[01:02:34 CET] <wm4> I thought it was for FTPs or some shit
[01:02:36 CET] <nevcairiel> not sure thats the same people d oing the encodes
[01:02:44 CET] <nevcairiel> the splits are usually for ftp or newsgroups
[01:02:44 CET] <jamrial> 1kbps xvid and 128kb mp3 is the most early 2000 you can get
[01:02:51 CET] <nevcairiel> its the idiot users that torrent this then
[01:03:00 CET] <rcombs> yeah, it goes up on FTP, but then people post the rars on usenet and torrent sites
[01:03:00 CET] <jamrial> 1000kbps, sorry
[01:03:02 CET] <iive> i think that they distribute the rars via ftp, and then put the files on torrents
[01:03:20 CET] <rcombs> dunno why they rar to begin with, though
[01:03:40 CET] <iive> because rar does crc and recovery via RS
[01:03:52 CET] <iive> also, to redownload just parts of it.
[01:03:59 CET] <iive> i mean... you can't trust sha1
[01:04:07 CET] <iive> ;)
[01:04:24 CET] <nevcairiel> newsgroups need some kind of splitting, since the entire thing wasnt really designed for binaries =p
[01:04:25 CET] <jamrial> par2
[01:04:35 CET] <jamrial> not rar recovery
[01:05:07 CET] <rcombs> good old "we're using a protocol that's objectively terrible for what we're using it for"
[01:05:16 CET] <rcombs> that doesn't make sense for FTP though
[01:05:21 CET] <rcombs> (also, lolftp)
[01:05:26 CET] <nevcairiel> i just tested some random SD encode and its actually a mkv with h264 and aac lc
[01:05:33 CET] <rcombs> oh, storytime
[01:05:47 CET] <jamrial> nevcairiel: one of the so called "bdrip"?
[01:05:53 CET] <nevcairiel> no, broadcast
[01:05:59 CET] <rcombs> so I once was given access to a shared FTP server to grab a file
[01:06:07 CET] <jamrial> ah
[01:06:40 CET] <iive> btw, i do still see xvids, and it is usually the smaller than the h264 releases.
[01:06:41 CET] <jamrial> blu ray rips at dvd resolution are distributed as "bdrip" or something like that
[01:06:42 CET] <iive> I guess that some people still have xvid only players.
[01:07:06 CET] <rcombs> server was in France, and like half the users in the US
[01:07:06 CET] <rcombs> one of the admins actually advised me to download a specific FTP client
[01:07:07 CET] <rcombs> that opens several connections and downloads a segment of the file on each one
[01:07:07 CET] <rcombs> because they were getting really low speeds on each connection, but in aggregate they were fast
[01:07:21 CET] <nevcairiel> everyone used to have those t hings back in the day, wonder why allowing more bandwidth on one connection was so hard
[01:07:28 CET] <rcombs> and I'm like "wtf you people are idiots"
[01:07:32 CET] <rcombs> nevcairiel: it was never actually hard
[01:07:41 CET] <rcombs> nevcairiel: you just need to increase your server's TCP send buffer size
[01:07:49 CET] <rcombs> to allow more packets in-flight at once
[01:08:03 CET] <iive> nevcairiel: to do load balancing.
[01:08:05 CET] <rcombs> that's how you deal with long (high-latency) fat (high-bandwidth) networks
[01:08:19 CET] <rcombs> so I told them to do that and whaddayaknow suddenly single-connection transfers are fast
[01:08:27 CET] <nevcairiel> jamrial: run of the mill HDTV encode, but i guess both types may still exist, some may still do the old-style encodes
[01:08:32 CET] <jamrial> iive: what i'm starting to see are hevc releases at half the size the h264 ones. and those i checked looked worse
[01:08:44 CET] <rcombs> but people invented whole workarounds (like using multiple connections) because they didn't know that was the solution
[01:08:45 CET] <iive> i mean, you do not want one T1 user to take over your small ftp server.
[01:08:56 CET] <nevcairiel> thats because hevc cant realistically deliver half the size at  same quality
[01:08:57 CET] <iive> jamrial: yes, megusta or something like that
[01:09:19 CET] <nevcairiel> not with any current encoders, anyway
[01:09:39 CET] <iive> it can
[01:09:45 CET] <nevcairiel> 30-25% less *maybe* if you do 10-bit encodes
[01:09:45 CET] <iive> but it takes a lot more time
[01:09:47 CET] <rcombs> maybe one day there'll be an HEVC encoder built by anime nerds
[01:10:11 CET] <iive> well, x264 was build by anime nerds
[01:10:17 CET] <rcombs> HEVC might realistically be dramatically better than H264 if the H264 encoder is shitty
[01:10:27 CET] <nevcairiel> even with all the time in the world, you cant get x265 to spit out a say  720p or 1080p encode at half the size and the same quality
[01:10:28 CET] <rcombs> maybe it's better for hardware, I dunno
[01:10:33 CET] <rcombs> iive: exactly
[01:10:34 CET] <nevcairiel> .. as a x264 encode
[01:10:40 CET] <rcombs> x265 is MCW people
[01:10:54 CET] <nevcairiel> (and i'm not talking anime content :p)
[01:11:01 CET] <nevcairiel> animes are easy anyway
[01:11:02 CET] <wm4> h265 is still a patent mine field
[01:11:06 CET] <nevcairiel> grainy live action is hard
[01:11:29 CET] <iive> grain is artifical
[01:11:33 CET] <iive> remove it :D
[01:11:42 CET] <rcombs> I'm just generalizing about anime nerds being good at actually improving visual quality instead of lolPSNR
[01:13:17 CET] <nevcairiel> the thing about hevc is that some of its coding tools just tend to blur rather then produce blocking artifacts or other visible artifacts
[01:13:27 CET] <JEEB> yeh
[01:13:33 CET] <nevcairiel> and many sheeple just accept lack-of-artifacts as a good image
[01:13:35 CET] <iive> well, loopfilter should do the same
[01:13:37 CET] <rcombs> nevcairiel: 03.2
[01:13:39 CET] <nevcairiel> nevermind lack of sharpness
[01:13:50 CET] <nevcairiel> rcombs: its a factor of hevc itself, not necessarily encoder
[01:14:10 CET] <iive> and h265 does have 32x32 dct? doesn't it?
[01:14:11 CET] <JEEB> yea, it's a set of coding tools that really optimizes for that blurriness fact
[01:14:15 CET] <JEEB> *factor
[01:14:27 CET] <rcombs> nevcairiel: doesn't blurring help PSNR though
[01:14:32 CET] <JEEB> yes
[01:14:44 CET] <nevcairiel> incidentally, some of the artifacts in h264 can "fake" sharp detail
[01:14:50 CET] <iive> you mean, blur before encoding?
[01:14:55 CET] <TD-Linux> iive, yes, compared to 8x8 max of h.264 high profile
[01:14:59 CET] <TD-Linux> (and 4x4 of bluray h.264)
[01:15:06 CET] <TD-Linux> that's where the majority of the gains came from.
[01:15:12 CET] <JEEB> wait what
[01:15:14 CET] <nevcairiel> so a h264 encode with slight artifacting can a ppear sharper when the artifacts are in the right spot :D
[01:15:26 CET] <JEEB> oh right
[01:15:48 CET] <rcombs> given how blurry everything turns out, it seems like both the codec design and the encoders were designed to optimize for PSNR
[01:15:53 CET] <JEEB> nevcairiel: psy-* in x264 tried to utilize that
[01:15:55 CET] <rcombs> does that seem inaccurate?
[01:16:00 CET] <JEEB> rcombs: no
[01:16:08 CET] <JEEB> you can go look at JCT-VC documents
[01:16:13 CET] <JEEB> regarding metrics utilized
[01:16:28 CET] <TD-Linux> rcombs, they literally search through all possible modes and choose the one with the best PSNR inside the encoder
[01:17:02 CET] <rcombs> maybe one day AV1 will save us
[01:17:02 CET] <rcombs> (that's the new meme codec, right?)
[01:17:02 CET] <rcombs> (daala is the old meme)
[01:17:02 CET] <nevcairiel> the x265 people always claim that they dont optimize for metrics, but if the standard itself tends to go that way there is maybe only so much they can do
[01:17:20 CET] <TD-Linux> rcombs, yes I'm literally a paid shill for it :^)
[01:17:30 CET] <iive> the standard shoulde define only the decoder, not the encoder
[01:17:35 CET] <wm4> just use vp9 lol
[01:17:39 CET] <rcombs> who pays people to shill for HEVC
[01:17:43 CET] <TD-Linux> iive, it does, but there's also a reference encoder
[01:17:45 CET] <rcombs> MCW? MPEG-LA members?
[01:17:46 CET] <JEEB> also it then starts making sense that disabling new tools in x265 starts making funky results
[01:17:58 CET] <rcombs> lolvp9
[01:18:00 CET] <jamrial> rcombs: av1 is a mix of all the meme codecs
[01:18:07 CET] <rcombs> jamrial: dank
[01:18:17 CET] <JEEB> I still remember being surprised by the cisco dude
[01:18:20 CET] <JEEB> at VDD'15
[01:18:21 CET] <rcombs> bringing together all the best memes
[01:18:32 CET] <JEEB> > cisco > people @ VDD
[01:18:35 CET] <JEEB> woah.jaypeg
[01:18:53 CET] <wm4> were those openh264 people or what
[01:19:00 CET] <JEEB> no
[01:19:01 CET] <JEEB> thor
[01:19:06 CET] <wm4> oh
[01:19:10 CET] <rcombs> lolopenh264 as well
[01:19:12 CET] <JEEB> as meme codecs were being talked of
[01:19:20 CET] <rcombs> I appreciate the effort tho
[01:19:26 CET] <JEEB> yea
[01:19:31 CET] <wm4> what effort
[01:19:41 CET] <iive> is openh264 the baseline codec that cisco released with payed patents?
[01:19:50 CET] <TD-Linux> yes
[01:19:59 CET] <iive> thanks obama!
[01:20:13 CET] <nevcairiel> a codec like av1 will never fully replace the mpeg codec category however, for web sure, but broadcast and optical media? not seeing it
[01:20:19 CET] <wm4> thanks trump for the h265 patent situation?
[01:20:24 CET] <TD-Linux> because broadcast tv is the future :^)
[01:20:42 CET] <nevcairiel> the way content providers are moving, internet streaming certainly  isnt either =p
[01:20:44 CET] <nevcairiel> or noone told them
[01:21:20 CET] <TD-Linux> but yeah there's no point to target optical media (a slice of that lucrative bluray 4k market!)
[01:21:26 CET] <jamrial> nevcairiel: is bluray uhd even remotely success right now to think about a successor?
[01:21:33 CET] <iive> wm4: i think obama made a patent reform at the start of his first term. nothing major. But I was just joking.
[01:21:46 CET] <nevcairiel> jamrial: still too new to draw a ny conclusions, i guess
[01:22:06 CET] <rcombs> up until the election things were looking like software patents as a concept might get thrown out in court
[01:22:13 CET] <rcombs> I'm less optimistic now
[01:23:00 CET] <iive> rcombs: hey, be more optimistic, maybe no patent laywer would survive the atomic armagedon :D
[01:23:16 CET] <nevcairiel> jamrial: but optical discs are on a decline anyway, and i guess more people still buy  DVDs then normal Blu-rays, so what can you do
[01:23:46 CET] <iive> talking aobut dvd and br sales
[01:23:50 CET] <wm4> iive: you bet patent lawyers would be on the list of people who get to survive in secret government bunkers
[01:23:51 CET] <jamrial> was going to say, the "looks and sounds good enough" mentality for even low quality streaming or even dvd are playing against new optical formats
[01:23:55 CET] <iive> netflix are working on their encoder.
[01:25:07 CET] <nevcairiel> if only the big content makers could be convinced to open up just a tiny bit to get their stuff on netflix (et al) sooner, and ideally in more regions of the world
[01:25:40 CET] <nevcairiel> sucks to live in a country where all content is dubbed, it also means our local netflix variant does not carry any content thats not been dubbed yet, even if we want to watch it in english
[01:26:14 CET] <iive> well, at least netflix went global.
[01:26:28 CET] <iive> things will fall into place with time.
[01:26:28 CET] <wm4> fortunately piracy still exists
[01:26:42 CET] <jamrial> iive: if only their full library also went global
[01:27:10 CET] <nevcairiel> interestingly in a few days amazon launches a new series globally that was produced in germany
[01:27:14 CET] <nevcairiel> wonder if its any good
[01:27:27 CET] <iive> jamrial: "their" library did. but not the things that they licensed from others. iirc
[01:27:44 CET] <iive> nevcairiel: is uve bow invovled?
[01:27:58 CET] <nevcairiel> no
[01:28:06 CET] <iive> then it might be good :D
[01:28:28 CET] <iive> what's the name of the series?
[01:28:38 CET] <nevcairiel> You Are Wanted
[01:29:02 CET] <nevcairiel> no clue if its any good, only saw like half a trailer
[01:30:10 CET] <nevcairiel> launches globally on amazon video on friday
[01:30:10 CET] <kierank> TD-Linux: 12:15 AM <TD-Linux> (and 4x4 of bluray h.264)
[01:30:20 CET] <kierank> blu-ray allows 8x8
[01:30:27 CET] <JEEB> yup
[01:30:33 CET] <JEEB> high profile as usual
[01:30:46 CET] <JEEB> I think it had some b-frame limits?
[01:30:56 CET] <kierank> some weird open gop yes
[01:30:58 CET] <kierank> and b-pyramid
[01:30:59 CET] <TD-Linux> kierank, I thought it was Main
[01:31:09 CET] <JEEB> nope
[01:31:11 CET] <kierank> maybe for some of the SD stuff but HD was high
[01:31:22 CET] <kierank> in fact iirc it was blu-ray that put High in
[01:31:24 CET] <TD-Linux> ah okay.
[01:31:56 CET] <nevcairiel> JEEB: max 3 b frames
[01:32:23 CET] <nevcairiel> and bpyramid strict
[01:32:31 CET] <JEEB> yup
[01:32:47 CET] <iive> nevcairiel: the trailer doesn't grab me... looks kind of cliche - a hacker destroys their life
[01:33:20 CET] <nevcairiel> i have amazon prime anyway, so i'll give it a look when its out, can judge then
[01:34:13 CET] <nevcairiel> (i had it for free shipping and never canceled it when they piled more features on top :p)
[01:35:09 CET] <iive> nevcairiel: have you watched "black mirror"?
[01:35:22 CET] <nevcairiel> no
[01:35:32 CET] <iive> highly recommended.
[01:35:41 CET] <nevcairiel> has pretty good ratings i see, maybe i should try it
[01:35:43 CET] <iive> also very depressing.
[01:36:01 CET] <iive> don't watch more than one per day.
[01:36:12 CET] <kierank> i wonder if they censored man in the high castle for germany
[01:37:05 CET] <nevcairiel> in movies or tv its usually fine to show these things
[01:37:09 CET] <JEEB> oh
[01:37:17 CET] <nevcairiel> for some reason games however cannot
[01:37:20 CET] <JEEB> yea
[01:37:27 CET] <kierank> what about castle wolfenstein?
[01:37:27 CET] <JEEB> that I remembered being NG
[01:37:30 CET] <kierank> did that just not exit
[01:37:34 CET] <kierank> -st
[01:38:21 CET] <JEEB> the new order did get released there
[01:38:26 CET] <JEEB> https://www.youtube.com/watch?v=1hK4Px4O8aE
[01:38:41 CET] <nevcairiel> the original as well, but it was modified
[01:39:15 CET] <nevcairiel> no swastikas and other insignias, highly reduced violence levels
[01:39:44 CET] <nevcairiel> and the story was slightly rewritten so you fight some cult and not the nazis
[01:40:13 CET] <jamrial> hydra :p
[01:41:15 CET] <nevcairiel> but yeah they do a lot of effort for games, while movies often get away just fine
[01:48:16 CET] <BBB> wbs: have your patches been applied?
[01:50:38 CET] <nevcairiel> the big arm set? that came through here on saturday
[02:25:56 CET] <cone-003> ffmpeg 03Michael Niedermayer 07master:a557ae8d52ce: avcodec/h264_direct: Fix runtime error: signed integer overflow: 2147483647 - -14133 cannot be represented in type 'int'
[02:25:56 CET] <cone-003> ffmpeg 03Michael Niedermayer 07master:1467143a6ebf: avcodec/wavpack: Fix runtime error: shift exponent 137 is too large for 32-bit type 'int'
[02:25:56 CET] <cone-003> ffmpeg 03Michael Niedermayer 07master:acdacb108d98: avcodec/targa: Skip hflip on blank images
[02:25:56 CET] <cone-003> ffmpeg 03Michael Niedermayer 07master:7cebc5a9ccba: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[02:50:32 CET] <rcombs> lol just found out libmad is a thing
[02:50:41 CET] <rcombs> that people think is "better quality" than lavc's mp3 decoder
[02:54:15 CET] <jkqxz> Fixed point <3
[02:54:22 CET] <jkqxz> (Floating point <2.9999999992793472)
[02:56:05 CET] <rcombs> well lavc has fixed-point
[02:57:01 CET] <rcombs> and MP3 isn't bitexact
[02:57:15 CET] <rcombs> also they spit out 24-bit 'cause ¯\_(Ä)_/¯
[03:01:10 CET] <jkqxz> Huh, so it does.  (I only remember that as the point of libmad.)
[03:05:02 CET] <wm4> 3 bytes per sample or padded?
[03:07:09 CET] <rcombs> dunno, presumably padded though
[03:16:37 CET] <cone-003> ffmpeg 03Steven Liu 07master:d3ce067e7687: avformat/hlsenc: fix ticket 6231
[03:25:02 CET] <BBB> rcombs: VLC devs keep saying that very loudly&
[03:25:23 CET] <BBB> nevcairiel: youre right, I missed that
[03:25:28 CET] <BBB> wbs: nevermind
[03:25:33 CET] <rcombs> what do they claim it is, 16- instead of 32-bit intermediates in lavc's fixed-point decoder?
[03:25:43 CET] <rcombs> (i.e. inaudible?)
[03:26:15 CET] <BBB> rcombs: I have no friggin clue, Im a video dev ;)
[03:26:37 CET] <BBB> rcombs: I once broken the wmavoice decoder and couldnt hear the difference (I actually tested it and thought it sounded fine)
[03:27:01 CET] <rcombs> >wmavoice
[03:27:03 CET] <BBB> since then I use wave analyzers to test audio decoder changes, since my ears are useless for that sort of stuff
[03:27:29 CET] <BBB> I agree wmavoice is garbage, but thats a different issue ;)
[03:36:02 CET] <philipl> so ffplay was never ported to the new decode api?
[03:39:58 CET] <wm4> apparently not
[03:40:55 CET] <philipl> git rm ffplay.c
[03:40:55 CET] <wm4> I still have a patch for ffprobe
[03:41:05 CET] <wm4> should send it
[03:42:40 CET] <philipl> Might as well.
[03:42:53 CET] <philipl> Does libav have an avplay or did they nuke it? Presumably they ported it if they still have it.
[03:44:50 CET] <wm4> seems like they haven't converted it
[03:45:01 CET] <wm4> maybe ask the ffplay maintainer
[03:45:44 CET] <philipl> heh.
[03:52:00 CET] <jamrial> poke marton. he ported ffplay to codecpar in a heartbeat when asked
[03:52:11 CET] <jamrial> out of all the tools, ffplay has the least hacks. or none
[04:12:37 CET] <philipl> Ok, will do
[04:13:05 CET] <philipl> Is he on IRC? I don't think so
[10:40:13 CET] <mateo`> mmm looking at the crystalhd thread, i wonder, is the new decoding api (send_packet/receive_frame) now mandatory ?
[10:42:31 CET] <nevcairiel> its mandatory if the encoder or decoder you try to use only implements it
[10:42:55 CET] <nevcairiel> but crystalhd is the only so far that does not implement the old api, afaik
[10:44:07 CET] <mateo`> ok
[10:45:59 CET] <mateo`> porting the mediacodec decoder to the new api is still on my todo though
[11:12:52 CET] <cone-655> ffmpeg 03Steven Liu 07master:4e3cc4bdd8ac: avformat/flvenc: flx flvflags no_metadata bug
[11:46:23 CET] <BtbN> mateo`, for cuvid I just implemented a wrapper, so it supports both. But the new API is "native" for it.
[14:37:21 CET] <wm4> mateo`, nevcairiel: Libav have a change that makes it possible to use the new API from the old one, to some degree
[14:38:52 CET] <nevcairiel> did they really add that
[14:39:01 CET] <nevcairiel> guess my voting against that every chance i had didnt help
[14:39:13 CET] <nevcairiel> its just going to cause trouble
[14:40:16 CET] <wm4> yes they really did that
[14:40:20 CET] <wm4> plus they rewrote everything
[14:40:29 CET] <nevcairiel> its the libav way
[19:08:26 CET] <durandal_1707> michaelni: the mpegvideo code is unparsable, is there another codec like scpr regarding frame handling?
[20:06:44 CET] <uau> ffmpeg supports platforms with size_t less than 32 bits? that sounds really implausible
[20:07:53 CET] <uau> that would pretty much require that int is less than 32 bits too, or else trying to malloc int-sized areas could silently wrap around the requested size to a smaller value
[20:09:08 CET] <wm4> uau: indeed
[20:24:46 CET] <durandal_1707> who is responsible for allowing ssim spam on devel ml?
[20:27:49 CET] <wm4> that's allowed, AFAIK
[20:28:22 CET] <durandal_1707> promoting company x?
[20:31:30 CET] <wm4> posting job offers
[20:37:52 CET] <kierank> not sure it's a bit vague
[20:37:56 CET] <kierank> should I troll it back
[21:26:29 CET] <jamrial> uau: we should probably remove the freedos/opendos checks from configure then
[21:27:39 CET] <wm4> apart from WTF, are you sure those don't use 32 bit mode
[21:30:30 CET] <jamrial> not really sure, but a google search gave me that impression
[21:31:03 CET] <wbs> the dos instances on fate, at least the ones I've seen, are djgpp, which is 32 bit mode
[21:31:29 CET] <jamrial> size_t is only guaranteed to be at least 16 bits by the standard, but if it's not in those two targets then i guess it's not a problem for us
[21:32:33 CET] <wbs> it's most certainly not a problem on those targets, no
[21:33:04 CET] <wm4> the max image size on such a system would be 256x256 even at pal8
[21:37:46 CET] <uau> jamrial: yes the standard minimum size is only 16 bits (like it is for ints), but there is plenty of code in ffmpeg which requires ints larger than 32767
[21:38:34 CET] <uau> it's obvious that many things would fail on such a platform, and i would be quite surprised if you were able to run ffmpeg usefully at all
[21:51:09 CET] <uau> jamrial: about your latest mail, your "types defined in the standard for this exact scenario" claim is false
[21:51:28 CET] <uau> the "scenario" only requires the type to be large enough to store the minimum required range of values
[21:51:50 CET] <uau> it's quite normal to use int to store variables which are never above 100
[21:52:33 CET] <jamrial> but that's mostly because it's native (aka usually fastest) type
[21:52:39 CET] <uau> do you claim it "makes no sense" to do that instead of using either char or int8_t/uint8_t?
[21:53:32 CET] <uau> if you accept the "native" argument, doesn't int / unsigned int fit the case here? (as in practice ffmpeg requires those to be at least 32 bits too)
[21:53:47 CET] <jamrial> for many arrays we do use uint_8 for such values
[21:54:47 CET] <uau> yes it is more common for arrays with lots of entries to use minimal types to reduce size
[21:58:57 CET] <faLUCE> I still believe that the decision of separating the ADTS header from the AAC encoder, in ffmpeg 3.2,  is a wrong decision. ADTS works only with AAC, then there's no reason for decoupling them. And in order to write a playable AAC file you have to mux it, which increases complexity of the code. Why don't  you do a regression in the source code of libav?
[21:59:19 CET] <jamrial> uau: from that pov i agree "makes no sense" was not the best way to put it. pointless would work better i guess
[22:05:05 CET] <SpeakerToMeat> Good evening. Sorry to interrupt your day, but I just wanted to come and thank you all profussely for the work you do on ffmpeg and for the marvelous tool you've created in it.
[22:10:37 CET] <philipl> curious.
[22:23:30 CET] <atomnuker> wm4: weren't you going to push the side packet stuff on monday?
[22:33:45 CET] <wm4> yes
[22:38:41 CET] <cone-255> ffmpeg 03Katherine Nagels 07master:b2206475b459: doc/filters: Add colourspace values for colormatrix filter
[22:50:32 CET] <cone-255> ffmpeg 03Michael Niedermayer 07master:0728d9a28106: avcodec/pictordec: Fix runtime error: left shift of 805306368 by 2 places cannot be represented in type 'int'
[22:50:33 CET] <cone-255> ffmpeg 03Michael Niedermayer 07master:108b02e5471c: avcodec/tiff: Check for multiple geo key directories
[22:50:34 CET] <cone-255> ffmpeg 03Michael Niedermayer 07master:8ebed703f153: avcodec/mpegaudiodec_template: Make l3_unscale() work with e=0
[23:02:11 CET] <cone-255> ffmpeg 03Alexander Strasser 07master:6693d57e99d9: lavf/avio: Remove unnecessary escaping of ' in string literals
[23:02:12 CET] <cone-255> ffmpeg 03Alexander Strasser 07master:a70d5e259364: lavf/avio: Be more explicit in logging white/black list matches
[23:08:30 CET] <wm4> philipl: I've played with nvidia+vdpau9hevc for a while
[23:08:56 CET] <philipl> anything interesting?
[23:08:56 CET] <wm4> nvidia+vdpau+hevc and mapping them as textures in GL
[23:09:03 CET] <philipl> broken?
[23:09:13 CET] <wm4> yes
[23:09:22 CET] <wm4> so as you know the first two textures contain the first and second luma fields
[23:09:41 CET] <wm4> because originally the GL interop wanted to make bob deint simple, or something absurd
[23:10:09 CET] <wm4> so in theory, the first textures contains all even lines, and the second all odd lines
[23:10:26 CET] <wm4> but with hevc... the first textures contains the top half of the image, and the second texture the bottom half
[23:10:29 CET] <wm4> WELL DONE NVIDIA
[23:10:31 CET] <philipl> yep.
[23:10:41 CET] <philipl> and is it exact? or is there a dead space in the middle due to alignment?
[23:10:45 CET] <wm4> but I didn't get it to work because there's some weird offset
[23:10:47 CET] <philipl> that happens with the read-back api
[23:10:51 CET] <wm4> heh
[23:10:53 CET] <philipl> ah. there you go
[23:10:54 CET] <wm4> that's probably it
[23:11:17 CET] <wm4> I didn't go as far as writing complex code to save the texture to png (and apitrace doesn't work), so I'm still confused
[23:11:38 CET] <wm4> but seriously how do they get this so wrong, and why don't they just add a way to map textures as single frame?
[23:12:25 CET] <philipl> Up until hevc, hardware produced fields, so they made the api use fields.
[23:12:39 CET] <philipl> With hevc, they need to explicitly split the fields and didn't do it consistently
[23:12:52 CET] <wm4> they didn't even get the most basic thing...
[23:14:55 CET] <wm4> so the only thing that works is using the video mixer
[23:15:05 CET] <wm4> for which they have a test program on github (how ironic)
[23:15:44 CET] <iive> there is no way to get a whole frame?!
[23:16:06 CET] <wm4> their shit is just randomly broken
[23:16:15 CET] <iive> btw, mpeg4-2 (asp) also doesn't support field pictures, only interlaced mb.
[23:16:28 CET] <wm4> some amazing incompetence (I mean couldn't they at least be honest and disable hevc in vdpau completely?)
[23:17:01 CET] <iive> ha...  ha... the PR department would kill them
[23:18:39 CET] <iive> wm4: if you have a way, report it as bug. hevc is not the first format that doesn't support field pictures.
[23:20:22 CET] <wm4> I'm sure they know this
[23:20:30 CET] <wm4> and I'm not sure why you're talking about field pictures
[23:21:18 CET] <iive> first and second luma fields ?
[23:22:11 CET] <iive> aren't chroma fields also separated?
[23:22:13 CET] <wm4> all video is represented as fields, doesn't matter if the codec supports or uses them
[23:22:14 CET] <wm4> yes
[23:27:02 CET] <jkqxz> The AMD guy on the Mesa list had patches for H.265 Main10 with VDPAU, but he gave up on it when noone replied and there was nothing to test with (because it's all broken on Nvidia so noone enables it).
[23:27:15 CET] <jkqxz> Maybe if you made it all work on AMD then Nvidia might pay more attention?
[23:27:35 CET] <wm4> doesn't libva work for AMD?
[23:28:31 CET] <jkqxz> Yes, though not yet for passing the surfaces to display.
[23:30:44 CET] <jkqxz> <https://lists.freedesktop.org/archives/mesa-dev/2017-March/147152.html>
[23:32:02 CET] <nevcairiel> kaveri doesnt have hevc 10bit decode hardware, are they running this through 8-bit again and calling it supported
[23:32:07 CET] <wm4> jkqxz: the dmabuf thing is missing?
[23:33:01 CET] <jkqxz> I don't know about Kaveri.  The VAAPI stuff all works properly for me on Polaris.
[23:34:24 CET] <jkqxz> wm4:  Yes.
[23:44:39 CET] <cone-255> ffmpeg 03wm4 07master:55eab1733b9e: ffmpeg, ffprobe: don't "merge" side data into packet data by default
[23:47:17 CET] <rcombs> jkqxz: (decode-only, I take it?)
[23:47:25 CET] <philipl> wm4: It's worse. Remember the first driver release with hevc support was broken like this in the mixer too.
[23:47:56 CET] <philipl> I managed to communicate directly with the vdpau engineer about it and he got it fixed (but didn't fix GL or read-back API)
[23:48:33 CET] <wm4> philipl: they have a vdpau engineer?
[23:48:41 CET] <philipl> Not anymore. He works for my company now. Whoops.
[23:48:47 CET] <wm4> lol
[23:49:22 CET] <jamrial> wm4: those gapless fate changes look weird. why an empty line, or why no separator between side_data and the packet duration?
[23:49:34 CET] <wm4> jamrial: I have no idea
[23:49:35 CET] <jamrial> looks like it could be a ffprobe bug
[23:53:53 CET] <jkqxz> rcombs:  Yes, decode-only.  There isn't any encode beyond barely-usable H.264.
[23:54:09 CET] <rcombs> and they use OMX for that, right
[23:54:28 CET] <nevcairiel> i hear the AMD encode SDK on windows is also rather impossible to work with
[23:56:08 CET] <nevcairiel> (this https://github.com/GPUOpen-LibrariesAndSDKs/AMF)
[23:57:14 CET] <Fenrirthviti> nevcairiel: not quite impossible, we have someone from the OBS community team who built a very workable encoder there
[23:57:45 CET] <nevcairiel> impossible means you want to kill yourself while working on it, not that its impoossible to actually produce some kind-of working code
[23:58:01 CET] <Fenrirthviti> Oh, well yeah he's basically suicidal all the time these days :)
[00:00:00 CET] --- Wed Mar 15 2017