can someone please explain to me why spacex still hasn't released the footage they got from their airplane? Why are they being so secretive about it? I mean seeing is believing so why not just release the footage and prove to everyone in the world they really accomplished such an unprecedented feat?I mean they did actually record it from their airplane right?
2) Is it sensible to use this way to have ffmpeg run under windows? http://www.wikihow.com/Install-FFmpeg-on-Windows
I asked Doug Ellison, the JPL guy who did the MSL descent video, if he had any tips.@danieljphilo:@doug_ellison They're trying to improve the SpaceX first stage landing video at http://nasaspaceflight.com Any tips? http://forum.nasaspaceflight.com/index.php?topic=34597.135 …@doug_ellison:@danieljphilo Nope. Beyond my skills.
Quote from: mlindner on 05/05/2014 10:00 amWe'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.Is it really just a matter of finding a suitable stand-in for corrupt macroblocks? Maybe the process is not so bad then!But I was looking at iframe 11. Macroblock 0:0 is valid (not corrupt) as reported by the debug info, but somebody replaced it anyway (with 5:0 I think) and it greatly improved the image.(Maybe I am mistaken. Maybe iframe 11 0:0 is corrupt. I would check but I'm not on my home computer right now.)
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.
OK, I double-checked and macroblock 0:0 is indeed valid:[mpeg4 @ 0x80062980] MB pos/size: 0 00:00:10020 128[mpeg4 @ 0x80062980] MB pos/size: -1 01:00:10148 102[mpeg4 @ 0x80062980] Error at MB: 1[mpeg4 @ 0x80062980] MB pos/size: 0 02:00:10250 109[mpeg4 @ 0x80062980] I cbpy damaged at 3 0[mpeg4 @ 0x80062980] MB pos/size: -1 03:00:10359 4[mpeg4 @ 0x80062980] Error at MB: 3[mpeg4 @ 0x80062980] I cbpc damaged at 4 0[mpeg4 @ 0x80062980] MB pos/size: -1 04:00:10363 6[mpeg4 @ 0x80062980] Error at MB: 4[mpeg4 @ 0x80062980] MB pos/size: 0 05:00:10369 102[mpeg4 @ 0x80062980] MB pos/size: 0 06:00:10471 64[mpeg4 @ 0x80062980] MB pos/size: 0 07:00:10535 92[mpeg4 @ 0x80062980] MB pos/size: 0 08:00:10627 52[mpeg4 @ 0x80062980] MB pos/size: 0 09:00:10679 64So should I "simply" find suitable stand-ins for corrupt macroblocks? Should I replace (some) valid macroblocks? Both?
I think I found a way to detect the beginning of macroblocks! They seem to have a fixed 11-bit macroblock_escape code (0000000100b) followed by an 1-11 bit macroblock_address_increment!
macroblock_escape -- The macroblock_escape is a fixed bit-string ‘0000 0001 000’ which is used when the difference between macroblock_address and previous_macroblock_address is greater than 33. It causes the value of macroblock_address_increment to be 33 greater than the value that will be decoded by subsequent macroblock_escape and the macroblock_address_increment codewords.
Quote from: arnezami on 05/05/2014 06:25 pmI think I found a way to detect the beginning of macroblocks! They seem to have a fixed 11-bit macroblock_escape code (0000000100b) followed by an 1-11 bit macroblock_address_increment!Sorry, the macroblock_escape won't help for decoding I-frames, because:Quote from: MPEG-2_Video_IS.doc section 6.3.17 Macroblockmacroblock_escape -- The macroblock_escape is a fixed bit-string ‘0000 0001 000’ which is used when the difference between macroblock_address and previous_macroblock_address is greater than 33. It causes the value of macroblock_address_increment to be 33 greater than the value that will be decoded by subsequent macroblock_escape and the macroblock_address_increment codewords.In an I-frame all macroblocks are typically coded (i.e. not skipped, "There shall be no skipped macroblocks in I-pictures except [...]" at the end of section 6.3.7) so there will be no occurrences of macroblock_escape. However, in I-frames the immediately following macroblock_address_increment code should encode a value of 1 which are coded as the bitstream bits 0000 0101 01 (from Table B-1 --- Variable length codes for macroblock_address_increment).This is still 10 bits of constant data, hope that helps.I haven't looked at the actual bitstreams (yet); are slices start codes not used? This would make it easier to restart part-way through a frame.By the way, for background: I have some amount of MPEG experience but it's not at the macroblock level. However, I do know how to read the bitstream syntax specs.
If I read it correctly there are no fixed end-codes of a block or marcoblock, but I only jump through the document.