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

[burek]

[00:03] <cone-229> ffmpeg.git 03Luca Barbato 07master:5c79d2e12d13: avconv: Do not divide by zero
[00:03] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:f2387152bcdc: Merge commit '5c79d2e12d13959fc6aed92d102c25194a06de05'
[00:38] <cone-229> ffmpeg.git 03Vittorio Giovara 07master:f777504f6402: h264: Lower bound check for slice offsets
[00:38] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:de7b50e9cde7: Merge remote-tracking branch 'qatar/master'
[00:38] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:0ad8f73f137d: avcodec: fix dxva2 & vaapi after removing the +52 offset from the loop filter parameters
[00:38] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:76dd01ecd4ed: avcodec/h264: fix sign error
[01:09] <llogan> trac is having issues
[01:13] <BtbN> sounds familiar.
[01:18] <J_Darnley> oops.  I forgot I uninstalled git
[01:43] <BBB> nevcairiel: did you do the last x264/vp8 encode (so we have an exact same-quality encode for all 3)?
[04:42] <cone-866> ffmpeg.git 03Michael Niedermayer 07master:1b872de8f49e: avformat/movenc: check that the input timestamps are within the range that can be stored in mov
[04:42] <cone-866> ffmpeg.git 03Michael Niedermayer 07master:20fa3fb93d0f: avformat/movenc: assert that get_cluster_duration() value is valid
[10:26] <nevcairiel> BBB: i'll do them now, was out yesterday
[12:03] <t355u5> Trac detected an internal error:
[12:03] <t355u5> OperationalError: database is locked
[12:03] <t355u5> Is there an ETA when this will be resolved?
[12:24] <ubitux> yeah that database lock sucks a bit
[12:24] <ubitux> also, sqlite; really?
[12:36] <Xeta> Anyone here had opportunity to look at my ticket for reading/applying replaygain tags? https://trac.ffmpeg.org/ticket/3398
[12:37] <wm4> Xeta: Libav has a patch, I expect it will be applied, and then ffmpeg will merge it
[12:38] <aca> I have been looking at the licensing of FFmpeg and noticed that 4 files (compat/avisynth/avisynth_c.h, compat/avisynth/avxsynth_c.h, libavfilter/vf_colormatrix.c, libavcodec/libzvbi-teletextdec.c) refer to an old FSF address. Please update that to: 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
[12:39] <wm4> as if anyone is ever going to use the address
[12:39] <aca> It just produces unnecessary warnings.
[12:40] <wm4> where?
[12:40] <aca> lintian complained, after I copied the paragraph to debian/copyright.
[12:46] <Xeta> +wm4 ah great i filed a ticket there as well and have been bugging them about it
[12:48] <wm4> yeah, bugging both projects leads to double success chance
[12:51] <Xeta> Heh ok, i was scared it would lower it
[12:51] <Xeta> How often do you guys import libav patches?
[12:52] <ubitux> wm4: that pngenc code looks weird
[12:52] <ubitux> it's doing a diff on size
[12:52] <wm4> Xeta: ffmpeg merges _everything_ Libav does
[12:52] <ubitux> and copying only bpp
[12:53] <ubitux> btw, also reproducible without mmx
[12:53] <ubitux> (so C code)
[12:53] <ubitux> and with just -pred 3
[12:53] <ubitux> so, valgrind ./ffmpeg_g -cpuflags -mmx -f lavfi -i testsrc -pred 3 -y out.png
[12:53] <wm4> ah, I thought it was some weird asm stuff
[12:54] <ubitux> (and -frames:v 1)
[12:54] <ubitux> valgrind ./ffmpeg_g -cpuflags none -f lavfi -i testsrc -pred 3 -frames:v 1 -y out.png
[12:56] <wm4> well it's still somewhere in dsputil.c
[12:56] <ubitux> code from original commit (4a5b619df74ea6a5d476fc4f91cbb98b5aa5098a)
[12:56] <wm4> (scary file)
[12:56] <ubitux> wm4: doesn't the caller look weird to you?
[12:57] <wm4> *shrug*
[12:57] <ubitux> i'd say diff_bytes should be called with bpp
[12:57] <ubitux> and not size
[12:57] <Xeta> Heh ok +wm4
[12:57] <ubitux> but not sure
[12:57] <ubitux> well, probably wrong
[12:59] <wm4> it would be better if anything there would document what it actually does
[13:02] <ubitux> maybe that's simply because src-bpp if src is beginning of buffer
[13:02] <ubitux> oh well.
[13:02] <ubitux> wm4: that's not a problem in the diff func
[13:03] <ubitux> doing a 1-to-1 dummy diff leads to an invalid read anyway
[13:03] <wm4> seems size is in pixels, and bpp the pixel size
[13:11] <ubitux> http://www.w3.org/TR/PNG-Filters.html
[13:13] <ubitux> ok fixed
[13:13] <ubitux> wm4: 
[13:13] <ubitux> -        dsp->diff_bytes(dst, src, src-bpp, size);
[13:13] <ubitux> +        dsp->diff_bytes(dst+bpp, src+bpp, src, size-bpp);
[13:14] <ubitux> will make a proper commit eventually
[13:14] <wm4> thanks :D
[13:14] <wm4> and the old code still produced correct results?
[13:15] <ubitux> yes
[13:15] <ubitux> it was overwriting the uninitialized based computed data
[13:15] <ubitux> (see following memcpy)
[14:05] <cone-449> ffmpeg.git 03Diego Biurrun 07master:dc9e05e279cb: libvorbis: Give consistent names to all functions, structs, and defines
[14:05] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:6e6386777128: Merge remote-tracking branch 'qatar/master'
[14:17] <ubitux> http://b.pkh.me/0001-avcodec-pngenc-fix-invalid-read-in-sub-filter.patch
[14:17] <ubitux> opinion?
[14:18] <ubitux> oh well, ml.
[14:45] <ubitux> mmh
[14:45] <ubitux> isn't there a 1-frame delay bug in overlay filter?
[14:46] <ubitux> ah, i guess that's a pts issue thing again
[14:49] <ubitux> BBB: ./ffplay -f lavfi -i "movie=/tmp/etv5k-vp9-b5000.webm [a]; movie=/tmp/etv5k-x264-b10000.mkv, crop=iw/2:x=iw/2 [b]; [a][b] overlay=w"
[14:49] <ubitux> i'm trying to compare like this but... timestamps are not handled the same in both format
[14:49] <ubitux> so it's causing some weird jumps
[14:56] <wm4> dump the timestamps with ffprobe?
[14:56] <wm4> and hope it's not some CODEC_ID_H264 shit in utils.c
[14:56] <ubitux> i just need to set the correct setpts after each movie=..
[14:58] <ubitux> wm4: carl is probably complaining about the missing sample
[14:58] <ubitux> you should use tests/lena.pnm or some random source filter when possible
[14:59] <ubitux> so we can be sure it's not related to the input
[14:59] <wm4> yeah, I should have used testsrc or so
[15:02] <ubitux> oh wait
[15:02] <ubitux> i have a lot of NOPTS with the webm file
[15:03] <ubitux> sounds like some libvpx derping
[15:05] <ubitux> mmh wait
[15:05] <ubitux> derp, it's movie device related
[15:11] <plepere> hmm... i'm doing a patch for ffmpeg to integrate my ASM. it works in one of our branches, but the fate doesn't work in mine. :/
[15:12] <BBB> ubitux: maybe the parser isn't filling in timestamps?
[15:12] <BBB> (vp9_parser.c)
[15:12] <BBB> I don't know how that stuff works
[15:13] <ubitux> mmh
[15:13] <BBB> what does etv stand for?
[15:13] <ubitux> enter the void
[15:14] <ubitux> (name of the movie)
[15:14] <Compnn> plepere : does fate pass without your patch ?
[15:15] <ubitux> ./ffplay -f lavfi -i "movie=/tmp/etv5k-vp9-b5000.webm, setpts=N/(25*TB) [a]; movie=/tmp/etv5k-x264-b10000.mkv, setpts=N/(25*TB), crop=iw/2:x=iw/2 [b]; [a][b] overlay=w, drawbox=iw/2:0:2:color=red at 0.5"
[15:15] <plepere> Compnn, my 8-tap filter works, but my 4-tap doesn't
[15:15] <ubitux> ok so this works
[15:15] <ubitux> BBB: if yoiu want to try ^
[15:15] <ubitux> to compare
[15:16] <BBB> so ffvp9 timestamps are screwy?
[15:17] <plepere> Compn, but I can enable it all on another branch and the fate passes, so I don't think it's a bug in my ASM
[15:17] <ubitux> BBB: yeah when using movie it seems
[15:17] <Compn> plepere : think its miscompile ?
[15:17] <ubitux> BBB: anyway, it seems the plane scene has grain uglier with x264
[15:17] <ubitux> and it's visible
[15:18] <BBB> ok so ssim score was slightly higher with vp9, and this confirms it indeed looks a little better right? so that's good then
[15:18] <plepere> Compn, what's miscompile ? (sorry)
[15:18] <BBB> the metric isn't completely lying
[15:20] <Compn> plepere : gcc bug 
[15:20] <Compn> or yasm bug, i guess :)
[15:20] <BBB> unlikely
[15:21] <plepere> Compn, I think it's unlikely, since it's working on another branch of ffmpeg. (just not the one I want it to)
[15:21] <ubitux> BBB: ./ffmpeg -i /tmp/etv5k-vp9-b5000.webm -i /tmp/etv5k-x264-b10000.mkv -lavfi "[1:0] crop=iw/2:x=iw/2 [b]; [0:0][b] overlay=w, drawbox=iw/2:0:2:color=red at 0.5" -ss 10 -frames:v 1 -y test.png
[15:28] <plepere> if all my ASM was wrong, I'd say to myself that I did something wrong in the linking, but it's only the 4-tap...
[15:30] <Compn> what branch works ?
[15:30] <Compn> what version is it, i mean
[15:32] <plepere> it's our own branch, but it's based on the current master from ffmpeg
[15:33] <plepere> https://github.com/OpenHEVC/FFmpeg : hevc_optimized works, feb_patch does not work
[15:33] <plepere> but feb_patch has only the ASM-related changes, and not all the other stuff (intrinsics and whatnot)
[15:51] <plepere> nvm, I'm an idiot
[15:52] <BBB> plepere: do you have a link to the code?
[15:53] <plepere> BBB : I've resolved my issue
[15:53] <BBB> lol
[15:53] <plepere> I didn't see that the filters table changed from one version to another.
[15:53] <plepere> therefore : I'm an idiot
[15:53] <BBB> wel that's kinda harsh
[15:53] <BBB> stuff happens
[15:54] <plepere> more often than not. :)
[15:55] <plepere> the great news is that now the branch is ready.
[15:55] <plepere> so.... now that I have that, how do I submit a patch for review ?
[15:55] <ubitux> git format-patch or git send-email
[15:58] <plepere> ok, so to whom should I send the .patches ?
[15:59] <plepere> oh and it put different .patch for each local commit. is it possible to put everything together ?
[15:59] <ubitux> ffmpeg-devel at ffmpeg.org
[15:59] <ubitux> rebase & squash them
[15:59] <ubitux> not familiar with git i suppose?
[15:59] <plepere> I'm just using the base functions
[16:00] <ubitux> go into master, git pull, go into your work branch, git rebase -i master
[16:00] <plepere> ok
[16:00] <ubitux> your editor spawn, replace the "pick" into squash/fixup/edit depending on what you want to do (see help at the bottom)
[16:01] <plepere> so all but last, I replace pick by squash.
[16:02] <ubitux> i personnally like to do fixup instead, and edit the message commit of the first one
[16:02] <ubitux> works fine with squash ofc
[16:04] <plepere> hmm, git says I'm not on any branch after rebase.
[16:05] <ubitux> did you do "edit"?
[16:05] <kurosu_> rebase --continue ? rebase --abort if you fear to break something? or were you cherry-picking ?
[16:06] <ubitux> what timeline did you do?
[16:06] <ubitux> you're probably in the middle of the rebase because of conflicts or edit
[16:08] <plepere> meh, I've got to go. I've sent my multiple patch files, I'll see this later if it's not accepted. :)
[16:08] <plepere> see you, and thanks for your help
[16:13] <Compn> git is so user unfriendly
[16:14] <ubitux> it's like saying "c pointers are so user unfriendly"
[16:14] <Compn> ehe
[16:14] Action: Compn trolls and runs
[16:14] <j-b> Compn: it's that what you do all the time?
[16:15] <Compn> hey, i helped plepere solve his own problem 
[16:16] <Compn> thats all people need sometimes, someone to talk to while they solve it themselves
[16:16] <Compn> its like 'placebo support'
[16:17] <wm4> but now that you said that it's placebo, it's not going to work anymore
[16:43] <iive> wm4: actually studies show that placebo works, even when the people who take it know it is placebo.
[16:44] <iive> on the other side, there is some chemical, that when injected, suppresses the effect of placebo completely.
[17:14] <wm4> ubitux: I think after all, this couldn't have caused a crash, since it's unlikely that the first bytes before a memory allocation are not mapped
[17:30] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:a0f8e6ad67b0: tests/tiny_ssim: drop isatty() support
[17:31] <ubitux> :(
[17:31] <ubitux> should have been isatty(1) anyway
[17:31] <BBB> it's ok, it was kind of silly, you can just tr \r to \n
[17:53] <ubitux> still no one to write/port a hqx-like filter?
[17:54] <rcombs> wm4: keep in mind how erratic this is, though
[17:54] <rcombs> wm4: it crashes on very rare occasion, and while it's unlikely, there's certainly a chance that a few bytes before an allocation won't be mapped
[17:55] <wm4> rcombs: maybe you could check whether a huge memalign() (like what av_malloc() does) starts on a page boundary with no page mapped before it?
[17:55] <nevcairiel> a couple bytes before an allocation could be part of control data, ie. if you use the memalign hack, it would store its info there
[17:56] <wm4> this happens on OSX
[17:56] <wm4> I think it uses native memalign there
[17:56] <wm4> but even then, memalign would most likely store its own header just before start of the allocation
[18:58] <cone-449> ffmpeg.git 03Carl Eugen Hoyos 07master:1f7e9be0b034: Only complain about missing frame rate for video streams.
[18:58] <cone-449> ffmpeg.git 03Carl Eugen Hoyos 07master:f5fe6a4f79fa: Do not warn about missing start time for unknown streams.
[18:58] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:c8f3c3a5794d: Merge remote-tracking branch 'cehoyos/master'
[19:49] <llogan> why did x265 choose cmake and mercurial?
[19:53] <nevcairiel> obviously the answer is "because the developer liked it"
[19:53] <nevcairiel> seems like a silly question :p
[19:53] <Daemon404> and because msvc support is easier
[19:53] <Daemon404> and all their devs use msvc
[19:53] <Daemon404> and their ead dev is also one of the leads on mercurial
[19:53] <Daemon404> so shockingly, they picked mercurial
[19:53] <nevcairiel> that goes for cmake maybe, not mercurial though :p
[19:53] <nevcairiel> vs2013 has a git client even!
[19:53] <Daemon404> muggs is the hg lead
[19:54] <Daemon404> windows installer is even signed by him
[19:54] <Daemon404> ;P
[19:54] <JEEB> tortoisehg maintainer
[19:54] <llogan> Daemon404: that explains it then
[19:54] <Daemon404> i dont like hg
[19:54] <Daemon404> but i use git-hg to bridge it
[19:54] <Daemon404> so im fine
[19:54] <llogan> * dont like hg
[19:54] <JEEB> there's an official git mirror IIRC
[19:54] <JEEB> and the build system IIRC supports it, too
[19:55] <nevcairiel> i always get confused when i try to use hg
[19:55] <JEEB> yeah
[19:55] <nevcairiel> its commands are very confusing
[19:55] <JEEB> prunedtree hates git tho :<
[19:55] <JEEB> which is sad
[19:56] <Daemon404> [18:54] < JEEB> there's an official git mirror IIRC
[19:56] <Daemon404> months out of date
[19:56] <JEEB> :<
[19:56] <Daemon404> nevcairiel, git-hg is in the official git git repo
[19:56] <Daemon404> use it if you can
[19:57] <nevcairiel> dont think msysgit comes with git-hg
[19:57] <JEEB> it's a script so you don't really need a special binary methinks
[19:57] <nevcairiel> but i need mercurial :p
[19:57] <JEEB> yes
[19:58] <Daemon404> which is easy on windows
[19:58] <Daemon404> unlike git
[19:58] <JEEB> I grabbed x's build which happened to have it without installers and bundled python
[19:58] <nevcairiel> never considered git to be hard
[19:58] <nevcairiel> well if you dont like CLI maybe
[19:59] <Daemon404> same
[19:59] <Daemon404> hg really confuses me
[19:59] <Daemon404> i once tried to do something liek rebase in it
[19:59] <Daemon404> i gave up and cloend a new repo
[19:59] <Daemon404> and patch -p1 <
[19:59] <nevcairiel> it doesnt have rebase
[19:59] <JEEB> enable all the extensions!
[19:59] <wm4> Daemon404: here too...
[19:59] <JEEB> it does come with hg core, but it's all disabled by default
[19:59] <wm4> but everyone says hg has a nicer interface
[19:59] <nevcairiel> they consider changing history a sin, or something
[19:59] <Daemon404> wm4, it looks amateur to me
[19:59] <JEEB> which is what tortoisehg overrides
[19:59] <Daemon404> the el output is e.g. all lower case
[19:59] <JEEB> it basically enables a whole shitload of stuff
[20:00] <Daemon404> help*
[20:00] <Daemon404> no love given at all
[20:00] <JEEB> because hg is much less usable without them
[20:00] <JEEB> *shrug*
[20:00] <Daemon404> the crappy help / lowercase stuff makes it look like a hacked together thing to me
[20:42] <tbarletz> Will it make sense to add support for different DRM solutions into ffmpeg?
[20:42] <tbarletz> e.g. Widevine or SecureMedia
[20:43] <BtbN> drm in an open sourcep project? Sounds like a horrible idea.
[20:43] <BtbN> or even in a closed source project
[20:43] <BtbN> it's allways a horrible idea.
[20:44] <JEEB> I think he mostly means decryption
[20:44] <tbarletz> Well, perhaps we can provide drm-specific implementaion, using externally linked libraries (via the provider's SDK)
[20:44] <BtbN> those are most likely not gpl compatible
[20:44] <tbarletz> And then have general decryption methods to use
[20:45] <tbarletz> i.e., HLS chuncks that are encrypted with SecureMedia -> use SDK to get clear control word -> decrypt -> save to file (or whatever)
[20:46] <BtbN> i'm pretty sure that isn't allowed by the drm license
[20:46] <BtbN> they'll only give you access to the SDK, under an NDA, if you sign not to make it possible to bypass it
[20:46] <tbarletz> The proprietary libraries will not be provided with ffmpeg
[20:46] <tbarletz> Just the code that uses it
[20:47] <tbarletz> Are you saying that even the interface is not public?
[20:47] <BtbN> would be quite pointless if it was
[20:47] <BtbN> drm is just huge security by obscurity
[20:48] <tbarletz> Well, I thought that the binaries are the secret part
[20:48] <JEEB> the API and libs are
[20:48] <JEEB> the loaded up libraries of course have to be public
[20:48] <JEEB> since the end-user has to deal with them
[20:50] <BtbN> if you could just load up the lib, and decrypt the video and save it to disk, the drm system would be extremely pointless
[20:51] <tbarletz> Well, in the case of SecureMedia, the encryption system is a server accessed in a protected environment, AFAIK
[20:51] <tbarletz> So you can't just get the clear control word if you don't have access to it
[20:58] <cone-449> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:84cdd2fd80ac: qcelpdec: break some too-long lines
[20:58] <cone-449> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:b295bce14813: qcelp: grammar
[21:04] <wm4> heh, what a underhanded way to add precise seeking to ffmpeg
[21:08] <rcombs> it was merged in from libav, wasn't it?
[21:08] <wm4> rcombs: no, I was referring to the patches on ffmpeg-devel
[21:10] <rcombs> oh, I can't handle mailing lists
[21:11] <Daemon404> wut?
[21:11] <Daemon404> will you go into the fetal position?
[21:11] <wm4> mailing lists are a must for interaction with some projects, including ffmpeg/libav
[21:11] <Daemon404> and a  good chunk of the FOSS world
[21:12] <JEEB> Daemon404, can you add experimentality to the 4:4:4 patch?
[21:13] <BtbN> well, specialy sending patches via mail seems strange to me
[21:13] <rcombs> ^ yeah
[21:13] <JEEB> Daemon404, as in, that you need -strict experimental
[21:13] <JEEB> to actually use 4:4:4
[21:13] <wm4> BtbN: git does that for you
[21:13] <wm4> with git send-email
[21:13] <JEEB> because range extensions aren't finished yet
[21:13] <Compn> wm4 : people can pass patches via pastebins if they want here
[21:13] <Daemon404> JEEB, why
[21:13] <wm4> it's pretty convenient, even more convenient than github pull requests
[21:13] <BtbN> if you have a working mailserver on your system, and your system is linux...
[21:13] <Compn> just most get ignored
[21:13] <Compn> also trac patches work too
[21:14] <rcombs> I find PRs more convenient by far
[21:14] <Compn> PR ?
[21:14] <Daemon404> JEEB, if x265 doesnt mark it as experiment *in their lib*, im not going to
[21:14] <wm4> BtbN: you don't need to run a mail server
[21:14] <rcombs> pull requests
[21:14] <Compn> ah
[21:14] <Daemon404> it's not my responsibility.
[21:14] <cone-449> ffmpeg.git 03Philip de Nier 07master:a9099e04026f: mxf: Add uncompressed 422 8-bit rawvideo UL
[21:14] <BtbN> wm4: last time i tried it it wanted a working sendmail
[21:14] <JEEB> eh
[21:14] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:f93bd82ee6bc: Merge commit 'a9099e04026f300924ac363fa6f8aef912677d90'
[21:14] <rcombs> or even just having a git branch somewhere that I can checkout, diff, review, and merge
[21:14] <wm4> BtbN: that's a possible configuration
[21:14] <Daemon404> [20:14] < rcombs> pull requests <-- so your one of those young guys who cant remember anything before github or git existed
[21:14] <nevcairiel> does it actually encode in 4:4:4 or just support 4:4:4 input and downconverts itself?
[21:14] <Daemon404> or perhaps live in SV
[21:14] Action: Daemon404 runs
[21:14] <BtbN> wm4: not on windows.
[21:14] <Daemon404> nevcairiel, it encodes in 4444
[21:14] <BtbN> and not on a desktop machine
[21:14] <rcombs> Daemon404: too young, yeah
[21:14] <JEEB> nevcairiel, it actually encodes 4:4:4
[21:15] <JEEB> according to whatever draft version
[21:15] <BtbN> i also don't see anything wrong with the linux kernel pull-request model.
[21:15] <BtbN> They also use a ML, but just send a repo url to pull from
[21:15] <JEEB> Daemon404, x265 is fucking dumb with that and that we can't do anything about, it doesn't mean that you have to fall to their level, though :P
[21:15] <Daemon404> rcombs, anyway, you should follow what a project uses if you want to contribute
[21:15] <nevcairiel> then you should really add a experimental gate there, as the bitstream isn't even finalized yet AFAIK
[21:15] <JEEB> it isn't
[21:15] <rcombs> Daemon404: sure
[21:15] <JEEB> they're still working on it
[21:16] <cone-449> ffmpeg.git 03Tomas Härdin 07master:c416b5cdf117: mxf: Add DNxHD UL
[21:16] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:9aa59a9ce6aa: Merge remote-tracking branch 'qatar/master'
[21:16] <rcombs> Daemon404: fortunately, the projects I contribute to largely take Git branch-based PRs
[21:16] <Daemon404> PRs on github lack some thinsg MLs provide
[21:16] <Daemon404> it's not a 1:1 tradeoff
[21:16] <BtbN> what do they lack? I can't think of anything
[21:17] <rcombs> I know I've read a long rant from torvalds about them being useless
[21:18] <Daemon404> BtbN, multiple revisions of single patches are handled very poorly
[21:18] <Daemon404> especially historically archivig said revisions
[21:18] <Daemon404> and yes that is useful
[21:18] <rcombs> that's a valid point
[21:19] <wm4> github could handle this correctly easily (if they wanted to)
[21:19] <rcombs> maybe they should provide an option to archive the previous state of a branch when you force-push, and attach it to any currently-open PR
[21:19] Action: rcombs puts in a feature request
[21:19] <wm4> the main downside of github is javascript everywhere, and that it's a single point of failure
[21:20] <Daemon404> yes
[21:20] <Daemon404> large patchsets *cripple* my browser
[21:20] <Daemon404> even on an i7
[21:22] <Compn> firefox ?
[21:23] <Compn> youtube changed the javascript there, its 100% cpu to do anything for me now.
[21:23] <Compn> using mobile versions of yahoo mail and gmail. wonder if i can user-agent my way around the mobile ver of youtube
[21:24] <rcombs> you don't even have to iirc; just go to m.youtube.com
[21:24] <rcombs> erm, nope
[21:25] <rcombs> yeah, m.youtube.com redirects, but if you use an iOS UA it'll load the mobile version just fine
[21:25] <Compn> less js ? :)
[21:26] <rcombs> how are we measuring it?
[21:26] <Compn> faster loading time
[21:27] <wm4> so when will there be a github mobile version?
[21:27] <rcombs> bit faster here, but not by a lot
[21:27] <rcombs> wm4: there already is
[21:27] <Compn> is there a github extension or app to speed things up ?
[21:28] <rcombs> there are desktop apps for Windows and OSX
[21:32] <Daemon404> JEEB, seems i misunderstood you
[21:32] <Daemon404> i though you wanted 4:4:4 experimental because x265 was buggy
[21:33] <Daemon404> i didnt realize it was in draft
[21:33] <JEEB> I literally linked you this today http://up-cat.net/p/220d1e34
[21:33] <JEEB> :V
[21:33] <wm4> hevc doesn't have 4:4:4 yet?
[21:33] <Daemon404> lost in the noise
[21:34] <JEEB> wm4, they're still optimizing it and friends
[21:34] <JEEB> range extensions will contain 4:2:2 and 4:4:4
[21:34] <JEEB> as well as >10bit
[21:34] <JEEB> it already passed DIS, so they're now working on to finish it and get it through FDIS
[21:35] <Daemon404> btw
[21:35] <JEEB> when it gets into DIS and x265 gets updated to more or less create complying byte streams
[21:35] <JEEB> *FDIS
[21:35] <Daemon404> markign shit experimental didnt stop anyone before
[21:35] <Daemon404> ;)
[21:35] <JEEB> yes
[21:35] <JEEB> but it at least adds an extra barrier
[21:38] <Daemon404> more like it lets me yell at people if they report problems
[21:39] <JEEB> yes
[21:39] <JEEB> that too
[22:30] <Compn> kierank : you were the one who had the kickstarter account right? indiegogo got back to me, they "usually dont delete banking info" . veeeeeeeery secure.
[22:34] <kierank> Compn: yes
[22:39] <Daemon404> Compn, there must be some sort of laws...
[22:40] <Compn> Daemon404 : yes, the banking laws say these idiot companies have to keep banking info for like 10 years 
[22:40] <Compn> to catch the bad drug dealers (who the banks are working with)
[22:42] <JEEB> reminds me of startssl being in israel
[22:42] <JEEB> if you buy a certificate from them where you actually confirm your identity
[22:42] <JEEB> they will keep it for at least 7 years
[22:42] <JEEB> because of israel data retention laws
[22:44] <Daemon404> JEEB, good thing i didnt confirm jack
[22:44] <JEEB> yes, the free certs don't need that
[23:45] <rcombs> wow, github actually got back to me very quickly on that feature request, with more than a canned response
[23:46] <Compn> they made the javascript quicker ?
[23:46] <Compn> ehe
[23:46] <rcombs> I got a standard "glad to receive your suggestion, we'll consider it", but also a suggestion that you could put the previous HEAD in a comment on a PR to keep track of previous versions of a branch if you're force-pushing after making changes
[23:47] <Daemon404> rcombs, that still makes seeing old comments kind of meh
[23:47] <Daemon404> less nice than just looking at gmane or a mailan archiv
[23:47] <Daemon404> ee
[23:47] <rcombs> yeah, optimally they'd keep around line notes and such
[23:48] <nevcairiel> if you still have a reference to the revision, the line notes would still be there at least
[23:48] <Daemon404> im not sure, but i think if the user deletes their fork, you lose the history anway
[23:48] <Daemon404> and it will be impossible to enforce such things
[00:00] --- Sat Feb 22 2014