The speed may also have to do with the fact that it's supposed to be random - They have no reason to believe you're some smuggler just because the random selector picked you out. You're most likely just some tourist.
Had the selection been on who looks the most suspicious in the eyes of some middle-manager customs officer, the staff better find some drugs or they will have proven their boss wrong, so it'll take a lot longer to search your bags.
Yeah well, that's what happened here. VLC was put on a site called www.torrentportal.com, and this likely has something to do with it ending up on the list from HBO.
A surprising amount of (mostly windows) users have been brainwashed to believe that all software and culture is by illegal to share. Free software is just some unknown crap, likely communist propaganda. If you have to download software from a warez site, it must be good quality software.
Yeah, this "Linus" or whatever that nobody heard of and never amounted to anything important is probably just some minor manager trying to work his way up the chain. I bet he'll never manage to make something. Now tell me, who's the true genius sitting behind Linus?
Except this is not IBM or Oracle. These people are not hired by Linus. It's not a private company, secrecy and private emails from the boss to the coworkers are better left to redhat and IBM who actually hires the people that Linus is sometimes shaming.
This still does not make it legal. Like how you can kill someone by hitting him in the head with a wooden stick while wearing rubber gloves, then later burn the stick and the gloves. Voila, no one will ever know.
Actually, someone in the government who hires an asshole to also work for the government do undermine the credibility of the government, thus reducing its power and in the end weakens the state, so yes, it wouldn't be that far fetched.
Look, if someone does something to me, I know it to have happened. I have all the right in the world to shame him. I have no idea how the f... you get this to require substantial external evidence. She's not writing a wikipedia article.
But video can easily be made to run in parallel simply by encoding several frames at once.
That idea with the 3D voxel blob is something I've been thinking about for doing simultaneous frame rate and resolution conversion between interlaced source and destination video formats. Sadly I still haven't managed to start coding on that. Maybe it will fail for the same reason that the video encoder failed.:/
Originally, the blocks used in the JPEG image coder was put there to make sure that you could stream-encode images using reasonably cheap silicon back in the eighties.
Your idea is nonsense. Whatever the reason for blocks in JPEG, video codecs NEED blocks. Full stop. Motion prediction/estimation/compensation/vectors works on the block level.
[...]
H.264 introduced 8x8 and 4x4 macroblocks, in addition to the standard 16x16 macroblock, because the motion vectors on smaller blocks allows it to eliminate more temporal redundancy. VP9 is adopting larger macroblock sizes as well, but that really only helps on a small amount of HD content.
You're sort of contradicting yourself here. You're saying that blocks are necessary. Then you're saying that fixed-size blocks are bad, because you get a better result when you discard the actual encoder block size and impose a motion vector granularity that is better tailored to the data in question. So why not simply decouple the encoder and motion estimators and let the motion estimator run with a dynamic size, maybe even without a square/rectangle restriction. Maybe the motion estimators could then be further improved if they weren't stuck with those sizes.
I simply don't agree that the quantizer/decimator must be limited to a given block size just because the motion estimator algorithm wants to use blocks to predict motion.
No other source than having tried it myself for a project that didn't have the memory restrictions or hardware, but severe code space restrictions, and simply running the DCT on the whole image and quantizing and encoding the results with huffman/arithmetics gave a visually more pleasant result with a resulting smaller filesize. Original research I guess.
I'm a bit worried about the big focus on "blocks" for such a video codec. Originally, the blocks used in the JPEG image coder was put there to make sure that you could stream-encode images using reasonably cheap silicon back in the eighties. No one really wants the blocks, they were a necessary limitation. Using the same algorithm as JPEG but removing the blocks gives a serious quality boost.
This codec will never run on hardware that can't handle more than 16 x 16 pixels at once. The lowest specs that will encode these frames will be hand-held cameras, which will have more than enough ram to buffer at least two full frames, and use a small FPGA for encoding/decoding. Everything else will be decoded by a GPU directly to the framebuffer, and likely encoded by the same GPU. Even server farms have these for processing media.
There's also no issue with streaming as far as I know. Both DCT and Wavelet based coders can packetize the important bits in a frame first, and the less important bit later, so that a slow connection can still decode a degraded image even if not all bits are received. This without splitting the image into blocks.
Yeah, at least a lot of my friends seem to have switched to 3G/4G for their at-home internet connection. Meanwhile, I switched to 100/100 fiber. Gotta keep the ratio up you know.
So what if you go to a website and it's serving javascript with an embedded and encrypted child porn jpeg? You should stop browsing the internet because it could happen, and then you'll go to jail.
It must be difficult living in such perpetual fear.
Yeah, that's kind of my point. It pisses off a lot of people who I'd like to be pissed off. Would be even more awesome if it were a single 1.7TB file, but I guess that's unlikely.
Slashdot Mirror
The speed may also have to do with the fact that it's supposed to be random - They have no reason to believe you're some smuggler just because the random selector picked you out. You're most likely just some tourist.
Had the selection been on who looks the most suspicious in the eyes of some middle-manager customs officer, the staff better find some drugs or they will have proven their boss wrong, so it'll take a lot longer to search your bags.
It might also have issues with things "lost in translation", but that's just a guess, I know nothing about it.
So put VLC on a warez site. Problem solved! :-)
Yeah well, that's what happened here. VLC was put on a site called www.torrentportal.com, and this likely has something to do with it ending up on the list from HBO.
A surprising amount of (mostly windows) users have been brainwashed to believe that all software and culture is by illegal to share. Free software is just some unknown crap, likely communist propaganda. If you have to download software from a warez site, it must be good quality software.
Yeah, this "Linus" or whatever that nobody heard of and never amounted to anything important is probably just some minor manager trying to work his way up the chain. I bet he'll never manage to make something. Now tell me, who's the true genius sitting behind Linus?
Except this is not IBM or Oracle. These people are not hired by Linus. It's not a private company, secrecy and private emails from the boss to the coworkers are better left to redhat and IBM who actually hires the people that Linus is sometimes shaming.
I'd argue that Windows 98SE would fit in between somewhere. Otherwise I fully agree. :)
It's actually Eric Raymond's own distro: http://geekz.co.uk/lovesraymond/archive/gun-linux
Or telnet if you're an old nostalgic computer geek.
That's not the point of the law. The point is to be able to taxate the losses so that the state gets its cut. One could say it's a "stupidity tax".
This still does not make it legal. Like how you can kill someone by hitting him in the head with a wooden stick while wearing rubber gloves, then later burn the stick and the gloves. Voila, no one will ever know.
It does, because a lot of other merchants sell things at a fixed USD rate.
This is also bullshit, as all calculations makes every transactions more secure. It's not "wasting" anything just to make it slower.
Why? I've read a lot of articles here on slashdot over the past years about the US accusing China for snooping.
Isn't it fair when it's exposed that the US does the same on an even larger scale, for China to mention this hypocrisy?
Actually, someone in the government who hires an asshole to also work for the government do undermine the credibility of the government, thus reducing its power and in the end weakens the state, so yes, it wouldn't be that far fetched.
Look, if someone does something to me, I know it to have happened. I have all the right in the world to shame him. I have no idea how the f... you get this to require substantial external evidence. She's not writing a wikipedia article.
Yeah, but starting fresh is what this codec is supposed to be all about, hence my "worries" about the block-thought.
But video can easily be made to run in parallel simply by encoding several frames at once.
That idea with the 3D voxel blob is something I've been thinking about for doing simultaneous frame rate and resolution conversion between interlaced source and destination video formats. Sadly I still haven't managed to start coding on that. Maybe it will fail for the same reason that the video encoder failed. :/
Your idea is nonsense. Whatever the reason for blocks in JPEG, video codecs NEED blocks. Full stop. Motion prediction/estimation/compensation/vectors works on the block level. [...] H.264 introduced 8x8 and 4x4 macroblocks, in addition to the standard 16x16 macroblock, because the motion vectors on smaller blocks allows it to eliminate more temporal redundancy. VP9 is adopting larger macroblock sizes as well, but that really only helps on a small amount of HD content.
You're sort of contradicting yourself here. You're saying that blocks are necessary. Then you're saying that fixed-size blocks are bad, because you get a better result when you discard the actual encoder block size and impose a motion vector granularity that is better tailored to the data in question. So why not simply decouple the encoder and motion estimators and let the motion estimator run with a dynamic size, maybe even without a square/rectangle restriction. Maybe the motion estimators could then be further improved if they weren't stuck with those sizes.
I simply don't agree that the quantizer/decimator must be limited to a given block size just because the motion estimator algorithm wants to use blocks to predict motion.
No other source than having tried it myself for a project that didn't have the memory restrictions or hardware, but severe code space restrictions, and simply running the DCT on the whole image and quantizing and encoding the results with huffman/arithmetics gave a visually more pleasant result with a resulting smaller filesize. Original research I guess.
I'm a bit worried about the big focus on "blocks" for such a video codec. Originally, the blocks used in the JPEG image coder was put there to make sure that you could stream-encode images using reasonably cheap silicon back in the eighties. No one really wants the blocks, they were a necessary limitation. Using the same algorithm as JPEG but removing the blocks gives a serious quality boost.
This codec will never run on hardware that can't handle more than 16 x 16 pixels at once. The lowest specs that will encode these frames will be hand-held cameras, which will have more than enough ram to buffer at least two full frames, and use a small FPGA for encoding/decoding. Everything else will be decoded by a GPU directly to the framebuffer, and likely encoded by the same GPU. Even server farms have these for processing media.
There's also no issue with streaming as far as I know. Both DCT and Wavelet based coders can packetize the important bits in a frame first, and the less important bit later, so that a slow connection can still decode a degraded image even if not all bits are received. This without splitting the image into blocks.
Yeah, at least a lot of my friends seem to have switched to 3G/4G for their at-home internet connection. Meanwhile, I switched to 100/100 fiber. Gotta keep the ratio up you know.
So what if you go to a website and it's serving javascript with an embedded and encrypted child porn jpeg? You should stop browsing the internet because it could happen, and then you'll go to jail.
It must be difficult living in such perpetual fear.
Or how easy it is to fall out of or off the vehicle in an accident.
Yeah, that's kind of my point. It pisses off a lot of people who I'd like to be pissed off. Would be even more awesome if it were a single 1.7TB file, but I guess that's unlikely.