Quote from: dorkmo on 05/03/2014 09:37 pmawesome stuff.to comment on the content of what can be seen so far, it looks to me like the legs both came out a little bit. then only the left leg progressed, then stopped. then the right leg extended fully. then finally the left leg extended fully.i wonder if thats typical of whats been seen in testingAre you serious? I don't see how you could have possibly seen such detail from any version of the video so far. SpaceX has the actual flight data of all these systems and they say the legs deployed correctly as hoped. I'm gonna go with that.
awesome stuff.to comment on the content of what can be seen so far, it looks to me like the legs both came out a little bit. then only the left leg progressed, then stopped. then the right leg extended fully. then finally the left leg extended fully.i wonder if thats typical of whats been seen in testing
<snip>
I wonder if we reach a point from where some data alignment becomes impossible to correctly to determine. In that case, would it be possible to generate a couple of hundred of thousands of combinations, generate a result image for each, put them on a web server and allow the community to evaluate them visually?
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.
Quote from: mlindner on 05/05/2014 05:22 amQuote 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.Very interesting! If that's true than that would probably help greatly in (semi-)automating this process! Because I had almost given up on that. So I'm very interested in an explanation of how this actually works.Regards,arnezami[edit] When I look at my log though I almost do not see any of the same length of bitsizes per block. So I don't think macroblocks have any sort of fixed sizes.
Bits to be stuffed Stuffing Codeword1 02 013 0114 01115 011116 0111117 01111118 01111111
Quote from: arnezami on 05/05/2014 06:18 amQuote from: mlindner on 05/05/2014 05:22 amQuote 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.Very interesting! If that's true than that would probably help greatly in (semi-)automating this process! Because I had almost given up on that. So I'm very interested in an explanation of how this actually works.Regards,arnezami[edit] When I look at my log though I almost do not see any of the same length of bitsizes per block. So I don't think macroblocks have any sort of fixed sizes.The MPEG 4 spec has the algorithm that allows you to parse the elementary visual bit stream, which can be of varying bit length, however the sequence_end_code x000001B7 is always byte aligned with defined stuffing bit codes preceding the end code depending on the number of bits required. The sequence start codes are also similarly byte aligned.QuoteBits to be stuffed Stuffing Codeword1 02 013 0114 01115 011116 0111117 01111118 01111111
I'm anxious to assist any way that I can. I've got the custom ffmpeg built and installed (from the github link). I'm a good engineer and programmer but I know next to nothing about MPEG or graphics in general.I guess I'm confused about what I'm supposed to do now. What do I give ffmpeg and what should I expect to get out? Do I need to download the video or iframes from somewhere? If so, I don't want to repair what you guys have already repaired. How are you guys staying in sync? Is there any coordination going on?Would it be more productive for me to wait until I can assist in a more brute force fashion? By that I mean using my eyeballs rather than my engineering skills.
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.
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.
Quote from: Digitalchromakey on 05/05/2014 07:09 amQuote from: arnezami on 05/05/2014 06:18 amQuote from: mlindner on 05/05/2014 05:22 amQuote 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.Very interesting! If that's true than that would probably help greatly in (semi-)automating this process! Because I had almost given up on that. So I'm very interested in an explanation of how this actually works.Regards,arnezami[edit] When I look at my log though I almost do not see any of the same length of bitsizes per block. So I don't think macroblocks have any sort of fixed sizes.The MPEG 4 spec has the algorithm that allows you to parse the elementary visual bit stream, which can be of varying bit length, however the sequence_end_code x000001B7 is always byte aligned with defined stuffing bit codes preceding the end code depending on the number of bits required. The sequence start codes are also similarly byte aligned.QuoteBits to be stuffed Stuffing Codeword1 02 013 0114 01115 011116 0111117 01111118 01111111A link to the spec section in question?