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

[burek]

[01:29:44 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:ace837665362: avformat/matroskaenc: Avoid "for (int i" syntax for better compatibility
[01:53:26 CEST] <rcombs> what does that actually improve compatibility with
[01:54:46 CEST] <kierank> old compilers
[02:06:55 CEST] <wm4> (lol)
[02:12:59 CEST] <Shiz> oh for crying out
[02:33:06 CEST] <BBB> does anyone know if libav logs their irc somewhere?
[02:35:20 CEST] <Compn> wow a wild rtogni and i missed him :D
[02:43:30 CEST] <philipl> c89 forever!
[02:44:25 CEST] <philipl> The Hotel California of programming languages.
[02:45:37 CEST] <wm4> I want to see a supported compiler which doesn't do c99 decls
[02:45:56 CEST] <philipl> *mumble*dec alpha*mumble*?
[02:47:05 CEST] <philipl> michaelni: which build failed without that syntax change?
[02:49:00 CEST] <wm4> *drummroll*
[02:52:12 CEST] <jamrial> wow, we have fate clients with gcc 3.4
[02:55:12 CEST] <philipl> gcc 2.95 should be good enough for anyone.
[02:59:22 CEST] <Shiz> cygwin life
[03:04:52 CEST] <philipl> Ironically, gcc 2.95 is about the same age as c99.
[03:05:06 CEST] <michaelni> philipl, i just spoted it, i dont know which compilers would have failed. 
[03:06:16 CEST] <philipl> wouldn't you rather let it be and see who screams? And then tell them to choose from any of the compilers released in the last decade?
[03:07:02 CEST] <michaelni> well, i dont want to violate our coding rules to experiment around like this
[03:07:15 CEST] <Shiz> 'experiment'
[03:07:20 CEST] <Shiz> using 16 year old language features
[03:07:39 CEST] <philipl> I believe that's how old the coding rules are too.
[03:07:40 CEST] <philipl> But anyway.
[03:07:54 CEST] <philipl> That's fair enough.
[03:08:10 CEST] <philipl> I agree we should change the rules rather than ignore them.
[03:08:17 CEST] <michaelni> yes
[03:08:47 CEST] <michaelni> if this is not needed anymore it should be removed fro the rules
[03:15:56 CEST] <michaelni> or rather "i dont want to violate our coding rules to experiment around like this in a undeclared fashion. If its intended as a experiment to check if any compilers still have issues then it should be clearly declared to be there for this purpose"
[03:42:28 CEST] <BBB> peloverde: team at vidtechcon.com doesnt work :(
[07:56:07 CEST] <razzledazzle> why is the compiler not generating the ffmpeg binary? Following params have been set, http://pastie.org/private/ss1lsjaujwnkbpj7kvrxw
[09:06:11 CEST] <wm4> I sure wish we actually had coding standards
[10:10:35 CEST] <razzledazzle> really, what are the requirements for the ffmpeg cli program, it doesn't get built..
[10:15:51 CEST] <nevcairiel> you disable avfilter, that might be related
[10:16:41 CEST] <nevcairiel> and depending on what you want the cli to do, you also might need a few more extra filters
[10:16:46 CEST] <nevcairiel> at least scale is probably useful
[10:17:55 CEST] <razzledazzle> hmm.. I guess I might have to do some more tests, if only there were some message about the prequisites/dependencies
[10:19:17 CEST] <razzledazzle> trying for a very minimal executable binary for Android, just for the overlay filter, I'm not sure about the fundamentals :P
[10:20:07 CEST] <nevcairiel> just remove the --disable-avfilter, i think configure may automatically select the individual filters that the cli wants
[10:22:40 CEST] <razzledazzle> that's neat then
[10:23:05 CEST] <razzledazzle> thanks for some input :)
[10:26:32 CEST] <razzledazzle> nevcairiel: that worked! appreciate your help! :D
[11:08:51 CEST] <BtbN> philipl, according to https://developer.nvidia.com/nvidia-video-codec-sdk a gtx980 should work for hevc encoding
[11:09:57 CEST] <cone-384> ffmpeg 03wm4 07master:94c0df79c7e8: lavc: propagate hwaccel errors
[11:10:55 CEST] <nevcairiel> BtbN: oddly enough they put encoding into their media functionality before they finished decoding :D
[11:11:15 CEST] <nevcairiel> but yeah the 980 supports hevc encoding
[11:11:17 CEST] <nevcairiel> but not decoding
[11:12:35 CEST] <wm4> hm do we really like the "if ((ret = foo()) < 0) return ret;" idiom?
[11:16:01 CEST] <BtbN> nevcairiel, strange
[11:17:38 CEST] <ubitux> wm4: up to you
[11:21:04 CEST] <nevcairiel> i dont mind that particular structure, as long as careful placement of the braces is observed
[11:21:21 CEST] <nevcairiel> personally i probably would use two lines
[11:21:50 CEST] <wm4> I normally prefer two lines too
[11:22:05 CEST] <wm4> but ffmpeg code generally seems to prefer the idiom
[11:33:55 CEST] <ubitux> it really depends on who wrote the code
[11:34:50 CEST] <ubitux> see also 2f0f9a87d0e8d27ce6ad5b81134d01b9d2392cd1 :p
[11:36:36 CEST] <wm4> yeah I had that too yesterday
[11:36:44 CEST] <wm4> I wondered why the fuck my code didn't work
[12:04:58 CEST] <durandal_1707> ubitux: are now high freqs ok?
[12:57:12 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:a368920eefbf: avcodec/options: Silence deprecated warning about coded_frame
[12:57:13 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:cb5190bc9df3: avcodec/diracdec: Move reference to DiracFrame, avoid use of the deprecated field from AVFrame
[15:06:51 CEST] <cone-384> ffmpeg 03Paul B Mahol 07master:40ddbc87c5cd: avfilter/avf_showspectrum: use av_calloc()
[15:07:30 CEST] <ubitux> durandal_1707: looking at it
[15:17:03 CEST] <ubitux> durandal_1707: green & red reflects the increase & decrease from previous frames?
[15:18:40 CEST] <ubitux> what's the logic for the representation of high freqs btw? cropping or padding with zero?
[15:19:01 CEST] <ubitux> if you're cropping, maybe a vertical line (or gray rectangle of the unused part) would be welcome
[15:19:44 CEST] <ubitux> and magnitude for the first sample (and maybe last) is still wrong
[15:20:25 CEST] <ubitux> i got a high freq glitch once though (so not as common as previously)
[15:22:51 CEST] <durandal_1707> ubitux: its separate color for each channel
[15:23:01 CEST] <ubitux> oh, ok
[15:27:44 CEST] <cone-384> ffmpeg 03wm4 07master:8024002d408f: vc1dec: propagate error codes and return meaningful error codes
[16:08:14 CEST] <durandal_1707> ubitux: high freqs are not displayed if width is too small
[16:08:32 CEST] <ubitux> ok, cropping then, alright
[16:09:40 CEST] <durandal_1707> what you mean by magnitude of first sample is wrong?
[16:20:08 CEST] <ubitux> durandal_1707: what i told you yesterday; remember the transform is going to transform N samples into N/2+1 complex
[16:20:40 CEST] <ubitux> so from a size PoV, that results in N+2 output, which can fit into the source buffer (it's in-place transform)
[16:20:48 CEST] <ubitux> so to counter that there is a trick done
[16:21:08 CEST] <ubitux> the first complex has actually a complex value assumed to be 0, just like the last one
[16:21:29 CEST] <ubitux> as a result, the real part of the last complex sample is stored in place of the complex part of the first sample
[16:23:00 CEST] <ubitux> (which *can't* fit into the source buffer, sorry)
[16:26:09 CEST] <ubitux> am i clear enough?
[16:26:26 CEST] <ubitux> note that other fft filters are actually wrong in that regard too
[16:26:41 CEST] <ubitux> i initially added a comment for that in showspectrum but it was dropped
[16:26:48 CEST] <ubitux> s/comment/FIXME/
[16:27:13 CEST] <ubitux> we're not giving a good usage example of our api :)
[16:28:13 CEST] <ubitux> durandal_1707: btw, if you're interested in learning SIMD (i think i saw you talking about that the other day), you might be interested in ticket #3921
[16:36:32 CEST] <ubitux> durandal_1707: http://pastie.org/10333545 here is an example on how to deal with the MAGNITUDE thing
[17:10:59 CEST] <durandal_1707> ubitux: that bug report is too advanced to my skills
[17:11:15 CEST] <ubitux> well, you said you wanted to learn
[17:13:49 CEST] <philipl> BtbN: for encoding, yes.
[17:13:53 CEST] <philipl> Did I ever say otherwise?
[17:16:20 CEST] <BtbN> not too sure anymore, i expected it to be the same
[17:42:52 CEST] <cone-384> ffmpeg 03Niklesh 07master:2e7a684e7214: movtextdec.c: Add support for font names
[18:08:21 CEST] <durandal_1707> ubitux: but in smaller steps like adding simd to blend diff mode
[18:46:24 CEST] <haasn> How likely is it for ffmpeg to include AVX512 acceleration in libavcodec, once it gets released (in Skylake Xeon chips)? Also, how likely is it that AVX512 would offer any sort of tangible performance boost?
[18:47:11 CEST] <Daemon404> if someone writes it, and it's useful it will be included
[18:47:59 CEST] <nevcairiel> i think i heard the resident asm experts say that usefulness is going to be limited
[18:51:58 CEST] <kierank> haasn: there isn't much avx2 in libavcodec
[18:52:02 CEST] <kierank> let alone avx512
[18:57:15 CEST] <Compn> haasn : more likely if someone else writes it, less likely unless someone donates some brand new cpu+mobo to developers to work on it
[18:57:33 CEST] <Compn> cant really write code without the hardware to test and bench.
[18:57:56 CEST] <Compn> and yeah avx2 isnt even used much
[20:18:51 CEST] <BBB> haasn: codecs like vp9 and hevc will see greats benefits from avx512
[20:19:01 CEST] <BBB> great, I mean, significant, as much as avx2
[20:19:22 CEST] <nevcairiel> all i heard is that avx512 is not a straight evoluition of avx2, but much more specialized
[20:19:27 CEST] <BBB> haasn: as for avx2 not being used very much, thats expected; I mean, were an opensource project and most people here simply contribute whats useful for themselves; I have no use for avx2 since I have no avx2 machine
[20:19:30 CEST] <nevcairiel> which makes its usefulness kinda limited
[20:20:18 CEST] <BBB> but if someone would buy me a new machine and pay my rent, Id be happy to write avx512 or avx2 for libavcodec (hevc or vp9 or whatever)
[20:20:38 CEST] <BBB> arent people expecting a new skylake-based macbook pro 15 at the end of this year?
[20:20:43 CEST] <BBB> Id love to get one
[20:20:46 CEST] <haasn> Interesting
[20:21:03 CEST] <kierank> only the xeon skylake's have avx2
[20:21:06 CEST] <kierank> avx512
[20:21:07 CEST] <kierank> *
[20:21:08 CEST] <haasn> BBB: The skylake desktop CPUs (i7) etc. don't include AVX512
[20:21:14 CEST] <haasn> what kierank said
[20:21:22 CEST] <nevcairiel> which is why avx512 usefulness for decoding is probably limited
[20:21:23 CEST] <BBB> oh crap
[20:21:24 CEST] <BBB> well
[20:21:27 CEST] <nevcairiel> maybe encoders can use it more
[20:21:28 CEST] <BBB> then no avx512 from me for a while
[20:21:36 CEST] <nevcairiel> which often run on server hardware as well
[20:21:38 CEST] <haasn> Aren't Xeons better value than i7s either way?
[20:21:50 CEST] <kierank> depends
[20:21:53 CEST] <BBB> do xeons fit on laptops?
[20:22:00 CEST] <kierank> the e3-xeons are essentially i7's with ECC
[20:22:05 CEST] <kierank> and possibly more pcie lanes
[20:22:07 CEST] <haasn> kierank: and without the iGPU
[20:22:10 CEST] <kierank> yes
[20:22:16 CEST] <haasn> for cheaper
[20:22:20 CEST] <nevcairiel> they have xeons with gpu
[20:22:25 CEST] <kierank> yes but not many
[20:22:27 CEST] <nevcairiel> which can be useful if you want to access the transcoder
[20:22:56 CEST] <haasn> nevcairiel: from what I heard, it can still only do 8-bit AVC/HEVC/VP9, not 10-bit?
[20:23:05 CEST] <haasn> Which limits its usefulness kinda since all mainstream HEVC content is going to be 10 bit pretty much
[20:23:15 CEST] <haasn> (And VP9 is easy to decode)
[20:24:11 CEST] <BBB> (which hevc content :-p )
[20:25:41 CEST] <haasn> BBB: the japanese UHDTV recordings on nyaa.eu :p
[20:25:58 CEST] <haasn> (The ones that are so terrible in quality that x264 would be significantly better)
[20:26:06 CEST] <haasn> (At half the bitrate)
[20:26:07 CEST] <BBB> did you know theres around 10 vp8 streams on the internetz also?
[20:26:11 CEST] <BBB> like, whoa
[20:26:12 CEST] <BBB> omg
[20:26:59 CEST] <haasn> BBB: On a more serious note, next blu-ray spec uses HEVC and is planned to hit the market around christmas 2015
[20:27:11 CEST] <haasn> (Spec was finalized a month ago or so)
[20:27:30 CEST] <haasn> So we will quite likely be seeing some HEVC content pop not too far from now
[20:27:38 CEST] <BBB> meanwhile, the world is watching netflix and their shareprice is skyrocketing
[20:28:12 CEST] <BBB> I mean, you could say that hevc is being streamed by netflix to samsung tvs
[20:28:22 CEST] <BBB> thats actually somewhat modestly meaningful
[20:28:28 CEST] <BBB> (although the quality sucks)
[20:28:50 CEST] <BBB> sorry, I guess Im being overly negative
[20:29:09 CEST] <BBB> Ill let Daemon404 take it from here :-p
[20:29:56 CEST] <haasn> I understand your concern, but didn't you just claim that we simply care about what's useful for us? :p
[20:30:03 CEST] <haasn> I do not intend to watch netflix at any point in my life
[20:30:11 CEST] <haasn> But I fully intend to watch 4K blu-ray as soon as it hits the market
[20:30:19 CEST] <BBB> fair point, yes
[20:30:21 CEST] <haasn> So I care about HEVC quite some bit more than about netflix's low-bitrate garbage
[20:30:51 CEST] <haasn> not saying intel is making a bad choice, just saying that their iGPU's usefulness for *me* is limited :)
[20:31:11 CEST] <haasn> Although I did say mainstream HEVC content. I guess that's wrong
[20:31:17 CEST] <haasn> Mainstream is youtube and netflix, of course ;)
[20:31:44 CEST] <haasn> I meant mainstream more as in I can actually download and watch mainstream movies in HEVC
[20:34:42 CEST] <Daemon404> [19:28] <@BBB> thats actually somewhat modestly meaningful
[20:34:44 CEST] <Daemon404> you cant
[20:34:50 CEST] <Daemon404> it was a deal between samsung and netflix
[20:35:00 CEST] <Daemon404> netflix even came out and set it has 0 gains over h264
[20:35:04 CEST] <Daemon404> said*
[20:35:11 CEST] <Daemon404> (which is obvious to anyone with a brain cell)
[20:35:17 CEST] <Daemon404> the encoder they used, i mean.
[20:36:37 CEST] <Daemon404> i am not actually aware of any hevc encoder which beats x264 at bitrates suitable for transparency
[20:36:41 CEST] <Daemon404> in terms of grain retention etc
[20:36:44 CEST] <BBB> I didnt say it helped
[20:36:48 CEST] <BBB> I said they were streaming it
[20:36:54 CEST] <BBB> I also didnt say they wanted to stream it
[20:36:57 CEST] <Daemon404> to a super tiny amount of people
[20:36:59 CEST] <Daemon404> ;)
[20:37:00 CEST] <BBB> :-p
[20:37:36 CEST] <BBB> you should work at netflix
[20:37:43 CEST] <BBB> might actually make their service better
[20:37:51 CEST] <Daemon404> i know some smart people there
[20:37:58 CEST] <Daemon404> i hear its not so easy
[20:38:00 CEST] <BBB> and when did I become a netflix recruiter
[20:38:01 CEST] <Daemon404> too big at this point
[20:38:02 CEST] <BBB> blegh
[20:38:39 CEST] <Daemon404> BBB, youre a poor recruiter then
[20:38:52 CEST] <Daemon404> you didnt even say it was a disruptive bleeding edge company
[20:38:53 CEST] <Daemon404> or whatever
[20:39:08 CEST] <haasn> Daemon404: if you work at netflix, can you please add a feature that lets me download full movies as plain, non-DRM-protected files at blu-ray bitrates without requiring registration, payment or any sort of personally identifying information?
[20:39:10 CEST] <haasn> That would be pretty useful
[20:39:21 CEST] <Daemon404> i do not work at netflix
[20:39:39 CEST] <haasn> if you end up working at netflix*
[20:39:52 CEST] <Daemon404> 0% chance of that
[20:39:56 CEST] <Daemon404> i would never live in SF.
[20:39:58 CEST] <Daemon404> ;)
[20:40:37 CEST] <kierank> haasn: hahahahahahahahaha
[20:40:44 CEST] <kierank> you miss the entire point of netflix
[20:40:56 CEST] <Daemon404> click buttan -> stream convenience
[20:40:59 CEST] <Daemon404> nobody cares about dling
[20:41:04 CEST] <kierank> or DRM
[20:41:18 CEST] <haasn> kierank: I guess I do. I've never understood the point of netflix, it confuses me
[20:41:22 CEST] <haasn> Daemon404: but what if I want to rewatch it?
[20:41:28 CEST] <kierank> just watch it
[20:41:29 CEST] <haasn> Or watch it when I don't have an internet connection?
[20:41:29 CEST] <kierank> again
[20:41:32 CEST] <BBB> netflix allows me to watch stuff
[20:41:33 CEST] <haasn> Or watch it on an unstable internet connection?
[20:41:36 CEST] <BBB> that youtube doesnt have
[20:41:38 CEST] <Daemon404> haasn, youre not the majority of the oaying public
[20:41:38 CEST] <BBB> so its useful
[20:41:41 CEST] <BBB> like, Mad Men
[20:41:54 CEST] <Daemon404> kierank, i care insomuch as i cannot view HD versions of some stuff on my laptop
[20:41:57 CEST] <Daemon404> i have to use a tv or xbox
[20:42:01 CEST] <BBB> haasn: so lets say you read about Mad Men (or any series) on some website, how do you watch it?
[20:42:02 CEST] <kierank> on linux it does that
[20:42:02 CEST] <Daemon404> but that's all.
[20:42:04 CEST] <BBB> I netflix it
[20:42:08 CEST] <BBB> haasn: what do you do?
[20:42:13 CEST] <BBB> you dont watch it?
[20:42:18 CEST] <BBB> or you go to the video store?
[20:42:23 CEST] <BBB> or you get a cable subscription?
[20:42:23 CEST] <kierank> Daemon404: iplayer lets you download programmes
[20:42:32 CEST] <kierank> literally once I watched a programme on a plane
[20:42:34 CEST] <Daemon404> kierank, thats fine i pay a tv license
[20:42:50 CEST] <Daemon404> BBB, same thing most of us do
[20:42:51 CEST] <kierank> you don't need a tv licence to dl iplayer
[20:42:52 CEST] <Daemon404> piracy
[20:43:04 CEST] <Daemon404> most shows i want o watch i simply cant
[20:43:06 CEST] <Daemon404> 0 legal ways.
[20:43:31 CEST] <BBB> netflix
[20:43:38 CEST] <Daemon404> no.
[20:43:45 CEST] <BBB> means I dont have to go through 10 porn sites or 10 fake movies before I find what Im looking for
[20:43:48 CEST] <Daemon404> it's not on netflix in the uk.
[20:43:53 CEST] <BBB> poor you
[20:43:54 CEST] <Daemon404> and only 1 season of 10 is
[20:43:56 CEST] <Daemon404> etc
[20:44:03 CEST] <Daemon404> (in the us)
[20:44:11 CEST] <BBB> mad men?
[20:44:15 CEST] <haasn> BBB: I go on a torrent tracker and download the first episode
[20:44:18 CEST] <Daemon404> example here was Adventure Time
[20:44:19 CEST] <BBB> youre kidding me, I just started season 4
[20:44:22 CEST] <BBB> oh
[20:44:23 CEST] <Daemon404> but it can apply ot e.g. Helix
[20:44:40 CEST] <Daemon404> it's on prime and itunes.
[20:44:42 CEST] <BBB> I dont know that series, anyway, yeah, piracy is a good second option
[20:44:42 CEST] <Daemon404> in the USA only.
[20:44:45 CEST] <Daemon404> most stuff is USA only.
[20:44:50 CEST] <BBB> move here
[20:44:52 CEST] <BBB> :-p
[20:44:54 CEST] <BBB> its wonderful
[20:44:55 CEST] <Daemon404> id rather not.
[20:44:56 CEST] <BBB> they also pay better
[20:45:45 CEST] <Daemon404> i get USA pay anyway.
[20:47:08 CEST] <haasn> BBB: what's better for quality, the rips you can get off private torrent trackers or the stuff netflix streams?
[20:47:20 CEST] <haasn> I obsess over video quality :/
[20:47:21 CEST] <kierank> depends actually
[20:47:29 CEST] <Compn> torrent, always
[20:47:30 CEST] <BBB> I never compared
[20:47:33 CEST] <kierank> Compn: not true
[20:47:38 CEST] <kierank> there are places on the internet where people have compared
[20:47:40 CEST] <BBB> torrent is hard to find one thats not fake
[20:47:40 CEST] <haasn> Compn: Okay, so YIFY then? :p
[20:47:44 CEST] <kierank> it's a mixed bag
[20:47:50 CEST] <Compn> obviously netflix gets hd versions of films that arent released in hd anywhere else
[20:47:51 CEST] <BBB> theres so much fake crap within the mix
[20:47:55 CEST] <Compn> so in that case, netflix would have the higher quality
[20:48:05 CEST] <haasn> I don't watch TV shows, just movies from time to time. For movies you can generally find BD remuxes if you look hard enough
[20:48:06 CEST] <Compn> and someone has to screenrip it to put up on a torrent site...
[20:48:21 CEST] <Daemon404> lol screenrip
[20:48:22 CEST] <haasn> Compn: films that aren't released on blu-ray? Like what?
[20:48:32 CEST] <Daemon404> as if you cant just dump in-memory buffers
[20:48:33 CEST] <Compn> haasn : you said private torrent sites, yify is mostly public tracker garbage :P
[20:48:39 CEST] <haasn> (apart from older stuff)
[20:48:50 CEST] <Compn> haasn : movies from the "old times" pre-2000
[20:48:57 CEST] <haasn> Compn: Those exist in HD?
[20:49:01 CEST] <Compn> of course.
[20:49:05 CEST] <Compn> they were shot on film! 
[20:49:15 CEST] <Compn> film !!! 35mm! 70mm! delicious film. :(
[20:49:24 CEST] <Daemon404> and if youre lucky, the BD remasters will be DNR'd to hell
[20:49:27 CEST] <haasn> Compn: The ones that get remastered in HD usually get Blu-ray releases for the HD versions, don't they?
[20:49:28 CEST] <Daemon404> and look worse than the dvd
[20:49:51 CEST] <Compn> blurays are shit dnr colorcorrected , i dont own any bluray :)
[20:50:08 CEST] <Compn> haasn : sometimes hd releases, sometimes not.
[20:50:18 CEST] <Compn> sometimes they just air them on MGM HD or other HD-only movie channels
[20:50:41 CEST] <Compn> theres really no rhyme nor reason what films get dvd/bluray releases
[20:50:52 CEST] <Compn> some movies havent even been released again since vhs/laserdisc...
[20:51:12 CEST] <Compn> people hacking together workprints and vhs and vcds lol
[20:51:44 CEST] <Compn> and then crazy people with their own film reels and telecine machines doing their own 35mm rips
[20:52:17 CEST] <Compn> Jurassic Park 35MM Cinema DTS v1.0 
[20:52:21 CEST] <Compn> glorious...
[20:53:31 CEST] <kierank> film scanners are relatively cheap
[20:53:33 CEST] <kierank> £20k
[20:53:52 CEST] <philipl> usenet
[20:54:18 CEST] <Compn> or cheaper since film companies are going out of bidness... all you have to do is move a room-size machine that weighs a few thousand pounds
[20:54:52 CEST] <Daemon404> preferably a clean room
[20:55:01 CEST] <Daemon404> unless you want tasty dust on your scan
[20:55:27 CEST] <Compn> oh cool, someone posted the open-matte ver of jpark
[20:55:35 CEST] <Compn> thats what i was waiting for 
[20:55:41 CEST] <llogan> not Beastmaster?
[20:56:10 CEST] <llogan> "My friends call me Dar."
[20:56:43 CEST] <Compn> well this is a 35mm scan, beastmaster probably is low on the list of films to scan
[20:57:47 CEST] <Compn> haasn : i'm more of a video purist than a quality whore. i want the film as originally cut by the director , as originally colored by the cinematographer etc, as originally edited in theatrical release (or first cut).
[20:58:00 CEST] <kierank> the director didn't shoot open matte
[20:58:25 CEST] <Compn> true, but i like seeing more details in open matte
[20:58:44 CEST] <haasn> Compn: I want to see the actor's nose hairs :p
[21:02:57 CEST] <Compn> ah i guess the open matte wasnt posted yet :\
[21:07:42 CEST] <Compn> Daemon404 : oh i'll take all the dust, grime, cig burns, hairs in the gate. all that fun stuff. digital is so boring.
[21:15:45 CEST] <dericed> some film scanners have a wet film gate where the film is submerged in a liquid of similar viscosity so it prevents the light traveling through the film from being bent to make a scratch
[21:32:17 CEST] <Daemon404> dericed, is it dangerous to the physical film?
[21:33:33 CEST] <dericed> it's not generally considered dangerous, the machinery cleans it off gently after existing the gate. it is far easier to remove film scratches (dark shadow ones) with wetgate transfers than trying to clean that later digitally
[21:34:00 CEST] <dericed> when film shows white scratches, that's because the emulsion is scratch off and is a lot harder to resolve
[21:37:37 CEST] <Daemon404> interesting
[21:37:46 CEST] <Daemon404> i have some "rematsered" bds where you see terrible stuff
[21:37:49 CEST] <Daemon404> like actual hairs
[21:37:50 CEST] <Daemon404> on the film
[21:38:07 CEST] <Daemon404> and others where they just DNR'd the entire thing to hide any effecxts
[21:38:09 CEST] <Daemon404> makes me sad.
[21:39:41 CEST] <dericed> Daemon404: ya, there's a LOT of bad film transfers out there. I sent some films out to make 4K DPX file sets, then ran through ffmpeg to make ffv1 files. They look great.
[21:46:07 CEST] <kurosu> re avx2, hevc mc benefited around 5%, and I'd expect the same for correctly written transforms (hint: x265's is worse than an average sse2 version)
[21:46:40 CEST] <Daemon404> kurosu, i am not shocked by that (the last bit)
[21:46:41 CEST] <kurosu> other parts play a lesser role, so even with relative large improvements, they don't improve much anything
[21:49:09 CEST] <kurosu> I've been told x265 is not exactly the best encoder reference quality+speed-wise, but I don't know the status of the corresponding offering
[21:49:41 CEST] <Daemon404> x265 is the best of a bad showing
[21:49:44 CEST] <kurosu> best encoder reference, compared to some other encoders
[21:50:08 CEST] <Daemon404> from earlier:
[21:50:08 CEST] <Daemon404> [19:36] <@Daemon404> i am not actually aware of any hevc encoder which beats x264 at bitrates suitable for transparency
[21:50:11 CEST] <Daemon404> [19:36] <@Daemon404> in terms of grain retention etc
[21:50:17 CEST] <Daemon404> most i have tested cant even beat it at mid range rates
[21:50:50 CEST] <kurosu> and those would be?
[21:50:53 CEST] <Daemon404> the only one i cant test is ateme, since they wont give us the time of day
[21:50:59 CEST] <kurosu> ah
[21:51:43 CEST] <kurosu> that was the one I had in mind, actually
[21:52:07 CEST] <Daemon404> they dont seem interested in us
[21:52:39 CEST] <Daemon404> so i /care'd, since it isn't really feasible to distribute hevc yet anyway
[21:53:41 CEST] <kurosu> I think netflix evaluated it, but they prefer not having to pay for their encoders
[21:53:51 CEST] <Daemon404> that's a lie
[21:53:58 CEST] <Daemon404> cause netflix used vanguard for their hevc
[21:54:02 CEST] <kurosu> then I've been lied to, ok
[21:54:03 CEST] <Daemon404> not sure if they now dropped it
[21:54:33 CEST] <Daemon404> nothing else usable existed at the time iirc
[21:54:43 CEST] <Daemon404> i heard they always intended to dorp it
[21:55:03 CEST] <Daemon404> one of those 'first to market' sort of deals.
[21:56:18 CEST] <Daemon404> (i had predicted hevc will win... but with the 2 patent pools, and now a future MPEG-DASH patent pool.... eh... well see)
[21:56:23 CEST] Action: Daemon404 stops rambling
[21:58:37 CEST] <ubitux> gif master race
[22:13:00 CEST] <rcombs> Daemon404: apparently some devices can decode HEVC in 4K, and H.264 only up to 1080p
[22:13:19 CEST] <Daemon404> yes.... some
[22:15:31 CEST] <rcombs> come to think of it it's probably quite a lot of them
[22:15:46 CEST] <rcombs> since for 3840x2160 you need L5.1 at least
[22:15:49 CEST] <philipl> You keep the decoding blocks you already have if you can get away with it
[22:16:33 CEST] <Daemon404> rcombs, not enough stuff for a website to justify distributing it
[22:16:34 CEST] <Daemon404> imo
[22:17:46 CEST] <rcombs> and apparently despite putting together an HEVC decoder that I'd imagine has all the e.g. RAM requirements of an H.264 L5.2 one, they still leave the H.264 decoder capable of only, eh, 4.0 to 4.2, Main or High only
[22:18:04 CEST] <Daemon404> it's likely for marketing
[22:18:08 CEST] <Daemon404> push hevc because OMG RES
[22:18:13 CEST] <Daemon404> not because it's actually better right now
[22:18:14 CEST] <Daemon404> that
[22:18:19 CEST] <Daemon404> that si what netflix did*
[22:18:23 CEST] <rcombs> hurr
[22:19:18 CEST] <rcombs> I've been wondering how feasible a single H.264 frame would be as an image format, a la BPG
[22:19:41 CEST] <Daemon404> x264 has tune stillimage fyi
[22:19:42 CEST] <nevcairiel> didnt that exist
[22:23:07 CEST] <kierank> rcombs: I have wanted to do that for years
[22:23:17 CEST] <thardin> implement it, then megabytes of emscripten'd h264dec to decode it
[22:23:17 CEST] <kierank> but the browser mimetype mafia say h264 is for videos
[22:23:33 CEST] <rcombs> I'd imagine it performs better than JPEG
[22:23:48 CEST] <philipl> Can you put up a single frame in a <video> tag and get the right results?
[22:23:54 CEST] <philipl> especially with the gifv stuff to hide the controls
[22:24:10 CEST] <rcombs> <video> doesn't get controls by default anyway
[22:24:17 CEST] <philipl> so isn't that sufficient?
[22:24:21 CEST] <rcombs> depends
[22:24:42 CEST] <rcombs> a _lot_ of embedded stuff only lets you have one <video> in the DOM at once
[22:27:31 CEST] <rcombs> I was just imagining something involving feeding the <video> into a <canvas> and copying all the frames out and into wherever onscreen you need them, but then remembered a lot of these systems don't let you write from <video> to <canvas> either
[22:28:18 CEST] <rcombs> so it'd really only work in native software where you can actually handle the decoding and display yourself
[22:31:29 CEST] <philipl> Yeah, wouldn't surprise me.
[22:34:16 CEST] <rcombs> (or if you used megabytes of emscripten'd h264dec but ~slow~)
[22:36:20 CEST] <philipl> tasty.
[22:36:32 CEST] <philipl> Or server-side conversion to jpeg :-P
[22:37:00 CEST] Action: Daemon404 notes they already serve different images to different browsers
[22:37:04 CEST] <Daemon404> adding one more is hardly effort
[22:37:23 CEST] <Daemon404> h264 is very suboptimal on mobile full stop though
[22:37:31 CEST] <Daemon404> e.g. it will display the play icon over the image
[22:37:34 CEST] <Daemon404> on some
[22:37:40 CEST] <Daemon404> for images i mean
[22:38:23 CEST] <philipl> Maybe the gifv stuff would help with that.
[22:38:36 CEST] <Daemon404> gifv is just clever stuff
[22:38:43 CEST] <Daemon404> imgur serves gif to mobile by default
[22:38:47 CEST] <Daemon404> except in their app
[22:38:56 CEST] <Daemon404> it servers webm in some browsers too
[22:39:14 CEST] <Daemon404> (they in fact use ffmpeg)
[22:41:48 CEST] <philipl> what's the motivation here again?
[22:41:58 CEST] <philipl> Better still images on a little phone screen?
[22:42:30 CEST] <Daemon404> smaller files
[22:42:33 CEST] <Daemon404> imgur uses a lot of bw
[22:42:53 CEST] <Daemon404> usually the webm or h264 looks worse than the gif version...
[22:42:57 CEST] <Daemon404> but not always
[22:43:11 CEST] <nevcairiel> well its to be expected
[22:43:16 CEST] <philipl> They're usually transcoded from gif in those situations right?
[22:43:23 CEST] <nevcairiel> its a lossy compression which was created from the gif original
[22:43:35 CEST] <nevcairiel> so best you can do is "equal" visually
[22:43:42 CEST] <nevcairiel> but chances are, it may look slightly worse
[22:43:46 CEST] <nevcairiel> much, much smaller though
[22:44:30 CEST] <Daemon404> nevcairiel, the input is increasingly youtube videos and such
[22:44:37 CEST] <Daemon404> imgur has a tool for that
[22:44:44 CEST] <Daemon404> they still manage to look worse than the gif versions
[22:44:48 CEST] <nevcairiel> making a gif from actualy video content will usually look horrible though
[22:45:05 CEST] <nevcairiel> so unless they go youtube -> gif -> webm, it should probably look better
[22:46:10 CEST] <philipl> Clearly webp is the solution.
[22:48:07 CEST] <jamrial> for still images why not? already supported by webkit/blink browsers, so almost the entire mobile market and more than half the desktop market
[22:48:37 CEST] <Daemon404> jamrial, we serve webp to such
[22:48:41 CEST] <philipl> safari supports it?? Surely not.
[22:48:42 CEST] <ubitux> well at least with give you don't have chroma subsampling
[22:48:45 CEST] <ubitux> with gif*
[22:48:56 CEST] <philipl> 256 colours should be enough for anyone.
[22:48:57 CEST] <Daemon404> amazingly, sometimes webp looks much worse than similarly sized jpegs made with mozjpeg
[22:49:18 CEST] <ubitux> no need for a loop filter either, no blocks!
[22:49:54 CEST] <philipl> Truly the technology of the future.
[22:49:56 CEST] <ubitux> maybe daala should take inspiration in gif
[22:50:47 CEST] <philipl> Didn't fabrice, or someone, try to propose an h.264 still image format before bpg?
[23:21:42 CEST] <BBB> why do you want a still image format?
[23:22:04 CEST] <BBB> the problem is not proposing new image formats; the problem is convincing people to actually use it; jpeg has won that war
[23:22:12 CEST] <BBB> (see webp)
[23:22:14 CEST] <philipl> Yeah.
[23:22:29 CEST] <BBB> you cant beat the jpeg no patents, coverage everywhere factor
[23:22:37 CEST] <BBB> I mean, thats absolutely priceless
[23:22:41 CEST] <philipl> I don't know if rcombs was just curious or has a real need.
[23:22:48 CEST] <philipl> mpeg2 only has three years to go!
[23:23:20 CEST] <rcombs> I mean, JPEG sucks, and I'd love to see something that doesn't
[23:24:41 CEST] <thardin> just use Accept headers properly
[23:24:45 CEST] <kierank> well jpeg is doing quite well actually
[23:24:49 CEST] <thardin> then serve both
[23:25:12 CEST] <thardin> does webp support anything but 8-bit 4:2:0 yet?
[23:26:25 CEST] <philipl> Don't think so.
[23:26:35 CEST] <philipl> I assume a vp9 based webp could fix that.
[23:27:18 CEST] <haasn> BBB: What's wrong with webp?
[23:27:44 CEST] <BBB> technically? nothing
[23:27:51 CEST] <haasn> As far as I can tell, JPEG is only winning because browser vendors are blindly refusing to add support for any other image format, claiming JPEG already won as the only reason why
[23:27:56 CEST] <BBB> I mean, its vp8-based, but what can you do, thats what they had when they started it
[23:28:13 CEST] <haasn> For example, YouTube is already using WebP but eg. Mozilla simply refuses to support it, despite perfectly fine patches already being written, multiple times
[23:28:20 CEST] <BBB> also, google can use it for youtube thumbnails or stuff like that if browser supports it
[23:28:24 CEST] <haasn> yeah
[23:28:29 CEST] <BBB> exactly
[23:28:33 CEST] <BBB> mozilla has jpeg
[23:28:34 CEST] <thardin> I thought browser vendors were all about shoving everything and the kitchen sink in
[23:28:37 CEST] <BBB> they dont _need_ webp
[23:28:54 CEST] <haasn> thardin: nah, just proprietary botnet stuff like Pocket
[23:29:03 CEST] <thardin> Pocket?
[23:29:05 CEST] <haasn> not useful stuff like webp support or a video player that isn't garbage
[23:29:07 CEST] <BBB> thardin: it has rgb and lossless
[23:29:14 CEST] <BBB> thardin: but these are not vp8-based obviously
[23:30:01 CEST] <thardin> ah
[23:30:02 CEST] <haasn> thardin: Pocket is a proprietary service for storing your tabs and stuff; it used to be an addon but the mozilla devs decided to include it as part of the firefox source code in exchange for money
[23:30:22 CEST] <thardin> uhh.. that sounds.. fishy
[23:30:24 CEST] <haasn> (luckily, you can still disable it using about:config and/or patch it out again)
[23:30:31 CEST] <haasn> thardin: a lot of mozilla's post-eich decisions have been.. fishy
[23:30:31 CEST] <thardin> is it in iceweasel too?
[23:30:34 CEST] <haasn> doubtful
[23:30:44 CEST] <thardin> good
[23:30:47 CEST] <haasn> but I have no idea about how much iceweasel diverges from firefox
[23:30:55 CEST] <haasn> check for browser.pocket.* I guess
[23:31:22 CEST] <haasn> thardin: I have somewhere a list of like 20 hidden settings that you need to disable in a new firefox installation to get rid of all the tracking
[23:31:26 CEST] <thardin> typing pocket in about:config shows nothing
[23:31:26 CEST] <haasn> they've gotten just as bad as google
[23:31:53 CEST] <thardin> I've been pondering switching to a browser that plays well with yacy
[23:32:03 CEST] <Gramner> actually, they didn't even get paid to include it which makes it even more weird
[23:32:17 CEST] <haasn> I've been pondering forking Firefox and removing the stuff I don't want, but it seems like too much effort every time I try
[23:32:18 CEST] <thardin> since any centralized web search service inevitably becomes shit
[23:32:44 CEST] <haasn> thardin: My current favorite is searx, which you can self-host
[23:32:50 CEST] <haasn> (I use an instance hosted by lachs0r)
[23:33:11 CEST] <haasn> So it's sort of distributed, in that there's no clear central company that would benefit from you using their engine
[23:33:36 CEST] <haasn> But it's also just a glorified proxy, you don't crawl the web yourself
[23:34:01 CEST] <haasn> Its core is a computer program written in Java distributed on several hundred computers, as of September 2006, so-called YaCy-peers. Why does all this p2p stuff always end up being written in Java
[23:34:05 CEST] <haasn> Reminds me of Freenet
[23:34:07 CEST] <thardin> I kinda want to host a crawler so it produces a lot of clearnet chaff
[23:34:35 CEST] <haasn> Great concept but completely unusable because it runs on Java and consumes literally like 1GB of RAM just to bootstrap a connection; and idles at 10% CPU usage (no, seriously)
[23:35:13 CEST] <thardin> eh, java is alright
[23:37:00 CEST] <haasn> https://en.wikipedia.org/wiki/Yacy#Disadvantages meh
[23:37:04 CEST] <haasn> I'm sure there can be a better distributed search engine
[23:51:05 CEST] <debianuser> haasn: Heh. They didn't do it for money. People asked a lot about that in #firefox. They wanted to deliver some mobile-compatible reader, and they worked on their "Reader Mode", but still had a lot to do. So they thought "Pocket works, let's deliver firefox at least with Pocket support for now until we make our reader-mode better". :)
[23:55:04 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:ae413a48e642: avcodec/movtextdec: check that ftab has been allocated before dereferencing it
[23:55:50 CEST] <haasn> debianuser: I don't get it. Firefox is not a product. It's a free software project. They don't need to placate their users and keep their shareholders happy
[23:56:10 CEST] <haasn> If anything, pocket integration has caused more controversy and scared people away from firefox..
[00:00:00 CEST] --- Fri Aug  7 2015