Quote from: mlindner on 05/05/2014 07:07 amI need some "truth" data. Do we have any camera views from any other video that shows what the lower portion of the image (the rocket itself) looks like at all? I'm trying to figure out something remarkable about it so I can tell one block from another.I need to order a bunch of puzzle pieces. Each has numbers on the bottom that need to be in order, they are perfectly square, varying flat white and there are either too few pieces or too many pieces and I need to either make some new ones or throw some away.There are images from the rocketcam in this threadhttp://forum.nasaspaceflight.com/index.php?topic=34502.105However, I think these are actually taken from 2nd stage (higher up in the stack, slightly different angle) and a camera on the 1st stage was used only for this landing footage, so the image is not entirely same. You'd still get some idea as to what the rocket body looks like.I do agree that it would probably help if SpaceX would release at least a couple of frames from the 1st stage camera from higher up. Reportedly they have good video of the braking burns but chose not to release it, perhaps to keep their secret sauce secret.
I need some "truth" data. Do we have any camera views from any other video that shows what the lower portion of the image (the rocket itself) looks like at all? I'm trying to figure out something remarkable about it so I can tell one block from another.I need to order a bunch of puzzle pieces. Each has numbers on the bottom that need to be in order, they are perfectly square, varying flat white and there are either too few pieces or too many pieces and I need to either make some new ones or throw some away.
I think I understand what's going on now.There are 44 * 30 macroblocks in the picture. ffmpeg is dumping the x-y locations of the macroblocks, and the byte offset and byte size of each macroblock.E.g.,[mpeg4 @ 0x60007a520] MB pos/size: 0 30:00:12347 104[mpeg4 @ 0x60007a520] MB pos/size: 0 31:00:12451 53[mpeg4 @ 0x60007a520] MB pos/size: 0 32:00:12504 91[mpeg4 @ 0x60007a520] MB pos/size: 0 33:00:12595 116[mpeg4 @ 0x60007a520] MB pos/size: 0 34:00:12711 77[mpeg4 @ 0x60007a520] MB pos/size: 0 35:00:12788 133[mpeg4 @ 0x60007a520] MB pos/size: 0 36:00:12921 73[mpeg4 @ 0x60007a520] MB pos/size: 0 37:00:12994 95[mpeg4 @ 0x60007a520] MB pos/size: 0 38:00:13089 110[mpeg4 @ 0x60007a520] ac-tex damaged at 39 0[mpeg4 @ 0x60007a520] MB pos/size: -1 39:00:13199 7The fields are:[mpeg4 @ 0x60007a520] MB pos/size: return-code x:y:offset size]You guys are manually looking at the picture, picking out a familiar macroblock and placing it at the correct x-y location using the -mmb override. When a macroblock is placed at the correct x-y location, it might also make other macroblocks snap in to place. Then you repeat for another macroblock.A return code of -1 means ffmpeg couldn't decode the macroblock. 0 means success, but it doesn't necessarily mean the macroblock is in the correct x-y location.Is that all correct?
Since there are only 12 iframes, does that mean there are only 12 images in the entire video?
Na, I need an image from the lower camera. Preferably during retroburn or something, but any time works.
Absolutely in awe of what's being achieved here. I had heard before that videos with errors still contained a lot of usable information but I had no idea it could be retrieved to this extent. I had visions of having to reconstruct entire frames by moving blocks around like a puzzle and guessing if they were in the right place.Absolutely fantastic work being done here!One more thing, Elon mentioned fan sourcing helped restore video footage before. Does any one know of any examples?
Quote from: fatdeeman on 05/05/2014 12:53 pmAbsolutely in awe of what's being achieved here. I had heard before that videos with errors still contained a lot of usable information but I had no idea it could be retrieved to this extent. I had visions of having to reconstruct entire frames by moving blocks around like a puzzle and guessing if they were in the right place.Absolutely fantastic work being done here!One more thing, Elon mentioned fan sourcing helped restore video footage before. Does any one know of any examples?+1 to being amazed. I wish I could help, but I literally have no idea what you guys are talking about As for the video, it's possible he was referencing the Mars Curiosity Landing video which was amazing after someone took 4 weeks to fix it:
We're not placing macroblocks at the correct locations as is replacing corrupted macroblocks with blocks from _elsewhere_ in the image. Every macroblock in the image is a reference+changes to either the block directly above it or the block directly to the left (this choice is made when the video stream is created). If you replace a macroblock with another block that has "roughly" the same "+changes" as the actual block then the created block will look roughly like the original and blocks that reference it will look roughly how they are supposed to.In some cases where things are too messed up we look for a macroblock that has changes that we know should be at a specific location (the legs) and forcibly put it there. That doesn't fix any previous blocks, but as you mention it often makes other blocks that follow it snap into place. Ideally after you put that block in place you should work backwards (right to left, bottom to top) toward the other bad blocks trying to replace those as well while maintaining the same "block address" of the block you fixed.Everything else is correct.
I also want to say how amazed I am at the effort and progress being made with this video.Having said that, I thought I'd toss in my $0.02 as a retired IT project manager of 38 years. I often found that the developers working for me would get so caught up developing their code that they has no time to see the bigger picture...that's where I came in as PM..So,having said that, I'm wondering if anyone is aware of any other efforts on any other space related sites, photo or video sites or for that matter, even at SpaceX, to answer Elon's call to arms to fix up this video...I'm just thinking that it would be sad to have all this great effort wasted because some where else, someone else has already done this work.....
Perhaps the folks who assisted in the cleaned up Curiosity video could be contacted for 'lessons learned' on that video? ... Or even assist on this one if they were interested.
Quote from: swervin on 05/05/2014 05:48 pmPerhaps the folks who assisted in the cleaned up Curiosity video could be contacted for 'lessons learned' on that video? ... Or even assist on this one if they were interested.The Curiosity video is a completely different scenario. No cleanup of re-interpretation of missing data was needed - and if it was, not anywhere near this level.The real achievement of the Curiosity video was the smooth frame interpolation from still frames to create the illusion of a full frame rate video.
Quote from: arnezami on 05/05/2014 04:53 am<snip>arnezami I've been talking to michaelni a lot today in learning how to do this process and I think your concept of "end markers" is off. Every block has a pre-defined size which is determined by its format. When a block is mis-interpreted then the size automatically becomes wrong and the block "eats" extra bits from the next block or misses bits from its block shoving them into the next block. Occasionally these errors cancel each other out (because there is a small finite number of block types and sizes) and the streaming is "resynced" to the proper block ordering so you get a string of correct blocks. You often don't see this resync because after its resynced the blocks are still referencing all the previous corrupted blocks. This is why after you fix one block suddenly lots more blocks become readable IMO.If michaelni could comment though that would probably clear more things up.Edit: The key difference that matters from your explanation is that changing the start position of a block can _increase_ or _decrease_ how far away the stop position is for that block because of how the block is interpreted.
<snip>