Another way of doing this is to say to a block: don't "listen" to your left block, instead "listen" to the left "block" of 0,0 (initial state I guess). I believe these things are called "predictions" in mepg-4.
Quote from: Okie_Steve on 05/07/2014 11:10 pmQuote from: mlindner on 05/07/2014 04:20 pmEvery block has 6 sub-blocks, 4 luma blocks (brightness) and 2 chroma blocks (color). The 4 luma blocks are the 4 squares in a block you often see. Both color blocks cover the entire block and are two different color planes. https://en.wikipedia.org/wiki/YUV There are 4 Y blocks and 1 U and 1 V block. Each one of those sub blocks references either the block above it or the block to the left of it (they all don't have to reference the same block). Which block they reference is determined on-the-fly (not hardcoded) so if a block is screwed up then it could cause blocks that would reference it, to not reference it or vice versa.Hmmm, I suspect that color is not really important here, has anyone tried stripping/ignoring the chroma information and just generated "black & white"? The human visual system is *MUCH* more sensitive to intensity then color which is part of why the chroma is sampled at half (or less) of luma in most cases.The data is there regardless, why not get it for free while we're at it?
Quote from: mlindner on 05/07/2014 04:20 pmEvery block has 6 sub-blocks, 4 luma blocks (brightness) and 2 chroma blocks (color). The 4 luma blocks are the 4 squares in a block you often see. Both color blocks cover the entire block and are two different color planes. https://en.wikipedia.org/wiki/YUV There are 4 Y blocks and 1 U and 1 V block. Each one of those sub blocks references either the block above it or the block to the left of it (they all don't have to reference the same block). Which block they reference is determined on-the-fly (not hardcoded) so if a block is screwed up then it could cause blocks that would reference it, to not reference it or vice versa.Hmmm, I suspect that color is not really important here, has anyone tried stripping/ignoring the chroma information and just generated "black & white"? The human visual system is *MUCH* more sensitive to intensity then color which is part of why the chroma is sampled at half (or less) of luma in most cases.
Every block has 6 sub-blocks, 4 luma blocks (brightness) and 2 chroma blocks (color). The 4 luma blocks are the 4 squares in a block you often see. Both color blocks cover the entire block and are two different color planes. https://en.wikipedia.org/wiki/YUV There are 4 Y blocks and 1 U and 1 V block. Each one of those sub blocks references either the block above it or the block to the left of it (they all don't have to reference the same block). Which block they reference is determined on-the-fly (not hardcoded) so if a block is screwed up then it could cause blocks that would reference it, to not reference it or vice versa.
Quote from: mlindner on 05/07/2014 11:16 pmQuote from: Okie_Steve on 05/07/2014 11:10 pmQuote from: mlindner on 05/07/2014 04:20 pmEvery block has 6 sub-blocks, 4 luma blocks (brightness) and 2 chroma blocks (color). The 4 luma blocks are the 4 squares in a block you often see. Both color blocks cover the entire block and are two different color planes. https://en.wikipedia.org/wiki/YUV There are 4 Y blocks and 1 U and 1 V block. Each one of those sub blocks references either the block above it or the block to the left of it (they all don't have to reference the same block). Which block they reference is determined on-the-fly (not hardcoded) so if a block is screwed up then it could cause blocks that would reference it, to not reference it or vice versa.Hmmm, I suspect that color is not really important here, has anyone tried stripping/ignoring the chroma information and just generated "black & white"? The human visual system is *MUCH* more sensitive to intensity then color which is part of why the chroma is sampled at half (or less) of luma in most cases.The data is there regardless, why not get it for free while we're at it?Because approximately half of the bit stream is chroma information and hence half of the errors needing to be dealt with. Given the way errors cascade color is probably just a distraction in this case.
Frame 3 is disgusting I can't do anything with it (disclaimer: I have no idea what I'm doing)
Quote from: Asmegin on 05/08/2014 02:36 amFrame 3 is disgusting I can't do anything with it (disclaimer: I have no idea what I'm doing)Agreed. It seems to be totally random noise.
Frame 9, cleaned up some single-bit errors up top.20:04:-1,24:04:16023,X:16410:01,16:5:-1,17:05:18692,X:19903:1,X:27244:1,1:15:-1,3:16:79127,41:19:-1,8:20:96220,15:04:16023
Quote from: grythumn on 05/07/2014 06:45 pmFrame 9, cleaned up some single-bit errors up top.20:04:-1,24:04:16023,X:16410:01,16:5:-1,17:05:18692,X:19903:1,X:27244:1,1:15:-1,3:16:79127,41:19:-1,8:20:96220,15:04:16023More cleanup on iframe 9. I am less convinced now that the odd shapes on the right leg are bugged bits. They seem to be consistent across multiple blocks and sub-blocks.X:19164:10,X:32551:80,X:32743:1,20:04:-1,24:04:16023,X:16410:01,16:5:-1,17:05:18692,X:19903:1,X:27244:1,24:08:-1,25:08:32410,1:15:-1,3:16:79127,41:19:-1,8:20:96220,15:04:16023
I was about to suggest that depending on the altitude at that moment, which you could probably estimate knowing the time interval between iframes 9 and 10, perhaps the apparent distortion of the center portion of the right leg could be a splash of brightly-illuminated water between the camera and the leg.But then after looking at the emerging details of frames 7 and 8, I'm beginning to fear your suspicions may be correct that they are not bugged bits but rather a big gnarly dent in the leg. Maybe a chunk of muddy ice smashed into it in just the wrong way?Looking at the image of the freshly-installed legs it's hard to picture how something like that could have happened, but then again I've seen the heartbreaking proof of what a mere chunk of foam can do to composite structures with my own eyes down at the USSRC in in Huntsville. I fervently hope that the meticulous grooming of the iframes you guys are doing will prove this notion wrong. Keep up the utterly amazing, amazing work! You guys deserve medals!
It would be interesting to see if we can determine if the part of the leg is still on the rocket body (that would confirm the hypothesis).
I suspect what happened is that one of the bolts attaching the leg to the rocket did not let loose. So that part of the leg snapped off and is still attached to the body of the rocket.
I suspect what happened is that one of the bolts attaching the leg to the rocket did not let loose. So that part of the leg snapped off and is still attached to the body of the rocket. This event is somewhere in this video!
Quote from: wronkiew on 05/08/2014 03:21 amQuote from: Asmegin on 05/08/2014 02:36 amFrame 3 is disgusting I can't do anything with it (disclaimer: I have no idea what I'm doing)Agreed. It seems to be totally random noise.yeah i think its just the fact that it has so few bytes, its got 8927. while the best picture so far (iframe8) has 20428. i think its interesting that iframe 6 has the at most 29622 but so far looks just as garbled as others. might be the one with most room for improvement?
But then after looking at the emerging details of frames 7 and 8, I'm beginning to fear your suspicions may be correct that they are not bugged bits but rather a big gnarly dent in the leg.