Which means that if the worms can't feel pain, your experiment must have failed =)
Kermos
@Kermos
Best posts made by Kermos
-
RE: Worms feel no pain...
Latest posts made by Kermos
-
RE: USB WTF
@immibis said:
You mention below that the processor can put the data directly into memory, so maybe this is faster?
Only if you use the processor's own USB hardware.
@immibis said:
But would be full speed for anything else involving USB xor NAND. Not all USB transfers involve NAND, not all NAND access involves USB.
Not really because while the USB chip can and does receive at high-speed, it now has to transfer it at a fraction of the speed to the processor via the EMI bus after it receives it. The NAND transfers only make this even worse and the majority of USB usage is data transfer to/from NAND.
-
USB WTF
Working on some new firmware for an embedded device and came across something interesting...
The processor it uses has built-in fullspeed capable USB support. Attached to the processor, via the EMI bus, is a bunch of NAND memory. Now with the timings tweaked as fast as I can get them, and the fact that the bus to the NAND is only 8 bits wide, I can get ~944kb/second of data. So that comes out roughly to 7.5mbit/second which is perfectly within the scope of full-speed USB.
Now what did the guy who designed the hardware do? On the same EMI bus that the NAND is on, he attached a 3rd party USB chip with 480mbit high-speed support.
1. This is a 98MHz processor, it can't process that much incoming data.
2. As previously stated, its on the SAME bus as the NAND. So to those who don't do much hardware, there are chip select lines which determine what chip the bus currently talks to. So I can talk to the USB chip ----> OR <---- the NAND chip. Not both at the same time. Meaning that my effective bandwith, for each chip in a USB->NAND data transfer has just been cut in half.
3. Instead of the processor simply placing incoming data in the background into memory buffers and notifying me via an interrupt when the data is arrived, leaving valuable CPU processing time for other tasks, I now have to *manually* read the data from the USB chip (which takes CPU cycles) into system RAM, then transfer it to the NAND effectively cutting my bandwidth on the EMI bus in half.So the end result is, I have a frigging 480 MBit USB connection with an effective data rate of less than half full-speed plus the added CPU overhead. *sigh*
The things people do sometimes just...amaze me. Utterly amaze me.
-
RE: How to initialize a boolean
Well, while we are discussing booleans, just found this gem in our production code:
[code]
if(response == 1) return true;
else return false;
[/code]I wanna cry.<FONT size=2>
</FONT> -
RE: Relationship WTF
@galgorah said:
@spamcourt said:
I've moved the thread to general discussion.Maybe this shouldn't be in "Side Bar" WTF at all.
OP, It sounds like she wants to talk more about it before actually breaking up. I don't really see the point in not talking to her unless you absolutely feel that the relationship is a waste of time for both of you. She may have some ideas, or ways to work out issues, that you may not have thought of. talk to her but don't be afraid to hold your ground if you still feel the same way afterwards. You may even end up with a good friend after this is all said and done.
Oh and if its any consolation. I had an hour and a half phone call with my ex from 5 years ago last night... She needed photos from a club night I shot to prove her friends innocense to the police. ie if he was there he couldn't have done it.This isn't the first time things have headed this way and at this point in time, naw, there is no sense in persuing things any further. We were briefly broken up two months ago and have had several near-break ups since then, and plenty of talks like the above as you suggested. I'd be happy to be friends with her though, but time will tell if that'll happen.
-
RE: Relationship WTF
@derula said:
Maybe you would have had your one-year anniversary, and she was planning something for that date... like proposing marriage...
Yet again, nope. Only been together a few months. No anniversary of any kind (no birthday either, we met on her birthday).
-
RE: Relationship WTF
@PJH said:
Or perhaps more interestingly, why? Was there some occasion you were supposed to attend together?
Naw, nothing like that at all. Nothing to attend together.
-
Relationship WTF
I've encountered plenty of rather interesting and crazy things in the dating world over the past few years but, this one today I think tops it all.
Last night I broke up with my now ex-g/f. Just a few issues that long-term weren't resolvable. Today, I get a message from her asking if I could postone the breakup until the weekend.
Erm, seriously, how does one "postpone a breakup?" I mean, wtf? I don't even know what to respond to that...
-
RE: Real-time video encoding on limited hardware
@tster said:
@Kermos said:
I'm already doing exactly that and it is what had stabilized me into the 500ish kb/second range.
Since I'm only using 16 bit RGB on the target, I can drop off the lower 2 bits on the YCC data without noticable loss in quality. That allows me to use the lower 2 bits for other information. So in my case, when I see 6 0's (completely unchanged 2x2 block), I send a 0x01 in its place.
Thanks :)
Hmm, I'd have to actually look at example data to try and figure out specific ways to compress it more. One idea would be if there are lots of low numbers (pixels changing color only slightly) then change those numbers to 0 up to a certain tolerance and then send the change after it.
For instance:
if a pixel has {1000, 1002, 1005, 1007, 1007, 1006, 1009, 100B, 100D, 1040}
and your tolerance is 10 send:
{1000, 0x6, B, 0, 35}
I've considered this, but so far not tried it due to the fact that it increases my complexity on the encoder.
Right now, after computing the deltas, I can simply take incoming camera frame and assign it to the reference frame to use the next time around. If I start using tolerances as you're describing, I can no longer do that as the reference frame will no longer match the receiver. I now, have to explicitly perform the same operation on every byte that the client does in order for my reference frame to match.
Also, there is another issue.
Huffman coding that encodes only 1 byte at a time, can at best not compress at a ratio better than 8:1 as at best, given the shortest key of 1 bit, you can't but more than 8 items in a byte. If the value for the 1 bit key is 1 byte in size, then that means you can't stuff more than 8 bytes into 1 byte.
Applying that to my data means:
1 frame in YCC420 is 115200 bytes, that means the best 100% most optimal compression (assuming all bytes had the same value) would be 14400 bytes the way things are right now. That times 30 frames a second is roughly ~421kb/second. I'm currently at around 500 so I'm really close to that.
I've tried applying run-length encoding prior to the huffman coding but it doesn't help much and the above reason explains why. So for that reason, I'm really focusing right now on expanding my huffman encoder to look at more than 1 byte at a time. It's almost working, but I seem to have some bug in there somewhere that's causing occasional data corruption I gotta find. :)
-
RE: Real-time video encoding on limited hardware
I'm already doing exactly that and it is what had stabilized me into the 500ish kb/second range.
Since I'm only using 16 bit RGB on the target, I can drop off the lower 2 bits on the YCC data without noticable loss in quality. That allows me to use the lower 2 bits for other information. So in my case, when I see 6 0's (completely unchanged 2x2 block), I send a 0x01 in its place.
Thanks :)
-
RE: Real-time video encoding on limited hardware
@arty said:
Just out of curiosity, I tried jpeg-ing some frames after doing a simple frame difference with a base "I" frame. The scheme is, we take a frame and encode it normally, then the next 7 frames have each component of each pixel as 128 + (me / 2) - (base / 2). This saves about 10% in the jpeg in my test at Q=30. Not much, but not bad IMO for just subtraction. Maybe this kind of idea will help?
Thing is Q=30 = utterly horrid. I tried jpeg at Q=30 and that still chewed around 1 meg/second bandwidth while looking utterly horrible in quality. Even a 10% saving with your method I would still be lightyears off the goal.
What I ended up implementing was, instead of encoding the frame, I encode the *differences* between the frames. Which, on the first frame, is the actual frame (since the initial reference buffer is cleared to 0).
On all subsequent frames, I only transmit the delta between the reference and the new frame. That gives me a very tight set of values, usually in the 10-20 different value range, that I can compress very nicely with huffman coding. After some additional optimizations, such as identifying 2x2 pixel blocks that did not change between frames (easy to do now, no mem compares needed anymore, just count 0s) this dropped me around 500kb/second range. However, I am still 8-10 times larger what a 512kbit outbound connection could handle.
About the only remaining idea I've got is to feed the huffman coding with 2x2 pixel blocks instead of byte values and encode those instead. Seems that out of 19200 blocks per frame, I generally only have rougly ~3000 unique changes. I'll have to try how that would compress. However, there still is the issue that the value/frequency pairs that I have to transmit along for the receive to be able to reconstruct the tree now take an excessive amount of space. Need 8 bytes each (6 bytes per 2x2 pixel block, 2 bytes sufficient for frequency), so that is ~703kb overhead per second. That's more than my entire compressed data right now on a byte level!
The only way around that I see is to, generate the dictionary, transmit it to the client, and then use this same dictionary for all future transmissions as well. For blocks that have no match, just compress on a byte level instead. Update dictionaries if I start getting too many misses.
In the end though, no idea if that'll be efficient enough. Will need to try and test.