Author Topic: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread  (Read 1201697 times)

Offline grythumn

  • Full Member
  • **
  • Posts: 243
  • Liked: 167
  • Likes Given: 246
For windows, Media Player Classic Homecinema or VLC are the standard applications. I usually have better luck with MPC for hardware acceleration (not important for this particular case.)

-R C

Offline Digitalchromakey

  • Member
  • Posts: 23
  • Phuket
  • Liked: 5
  • Likes Given: 2
here are two videos which where transcoded with a modified FFmpeg.
The modifications force the decoder to continue decoding frames even once errors where detected, this should show more parts of the frames at the expense of also significnatly more random damaged and ugly looking blocks.
Also motion compensation and error concealment where disabled, the way neither correct nor incorrect parts of previous frames would leak in the current frame.
Overall the video certainly is less pleasing to watch that way but it should contain more information for analysis and be easier to make sense of if someone wants to analize it frame by frame

The first is based on raw.ts, the second is based on the coerced.ts file from Jarred which was posted here
https://ffmpeg.org/~michael/space-x-video/raw.ts-nomc-ignoreerr.mkv
and
https://ffmpeg.org/~michael/space-x-video/Jared-coerced.ts-nomc-ignoreerr.mkv
The second transport stream above which is based on Jared's coerced ts with motion vectors and error concealment turned off, does make very interesting viewing on a frame by frame basis. There are several fixed features in each frame that we know are spatially invariant on a frame by frame basis - the legs, the first stage edges. the real time read out display and to an extent the rocket plume.

Looking on a frame by frame basis you can clearly see the edges for the legs, often as (a) cohesive block(s), but located in clearly the wrong frame position.

It should be possible, but incredible tedious for someone wit the right tools to manually reverse engineer a transport stream, using these measurable, known fixed special errors as frame by frame variable special offsets and moving all the associated data (including motion vectors, etc) within these clearly defined mislocated blocks over to their known correct spacial position in a reverse engineered transport stream.

Offline Carreidas 160

  • Full Member
  • *
  • Posts: 170
  • Liked: 4
  • Likes Given: 0
I'm neither a video encoding/decoding expert nor qualified rocket engineer but...

Is there a way to clean up a noisy video signal using genetic algorithms?

I.e. randomly keep switching bits (turn 0s into 1s) in parts of the signal that are known to be corrupt, and see whether these variations clean up the picture or not? And subsequently lock the bits that improve quality?

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Hi guys,

Litte update.

I have been making some progress. I can now tell the codec to skip bad macroblocks (16x16 pixel blocks). And I can tell it when to start the next good macroblock and where its data source begins (on a bit-level).

As a proof of concept I have taken the coerced.ts and from that basicly recreated the I-frame SpaceX released earlier. See the attached image. (btw I haven't spend time to repair the lower part of the image)

The difference is that with this I can "fix" the output of an I-frame without actually fixing the data itself. I "just" have to say what blocks are "bad" and where the new "good" block begins (bit wise). The latter is also very time consuming right now. But I have some ideas that maybe everybody can help. Maybe.

Regards,

arnezami

Offline dorkmo

  • Full Member
  • ****
  • Posts: 710
  • Liked: 338
  • Likes Given: 848
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

Offline Adaptation

  • Full Member
  • *
  • Posts: 160
  • Liked: 40
  • Likes Given: 38
Hi guys,

Litte update.

I have been making some progress. I can now tell the codec to skip bad macroblocks (16x16 pixel blocks). And I can tell it when to start the next good macroblock and where its data source begins (on a bit-level).

As a proof of concept I have taken the coerced.ts and from that basicly recreated the I-frame SpaceX released earlier. See the attached image. (btw I haven't spend time to repair the lower part of the image)

The difference is that with this I can "fix" the output of an I-frame without actually fixing the data itself. I "just" have to say what blocks are "bad" and where the new "good" block begins (bit wise). The latter is also very time consuming right now. But I have some ideas that maybe everybody can help. Maybe.

Regards,

arnezami

That is really freakin good work.  Would you mind sharing your latest .ts and a little more on how you are determining which blocks are good and bad.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Hi guys,

Litte update.

I have been making some progress. I can now tell the codec to skip bad macroblocks (16x16 pixel blocks). And I can tell it when to start the next good macroblock and where its data source begins (on a bit-level).

As a proof of concept I have taken the coerced.ts and from that basicly recreated the I-frame SpaceX released earlier. See the attached image. (btw I haven't spend time to repair the lower part of the image)

The difference is that with this I can "fix" the output of an I-frame without actually fixing the data itself. I "just" have to say what blocks are "bad" and where the new "good" block begins (bit wise). The latter is also very time consuming right now. But I have some ideas that maybe everybody can help. Maybe.

Regards,

arnezami

That is really freakin good work.  Would you mind sharing your latest .ts and a little more on how you are determining which blocks are good and bad.

Hi Adaptation,

I have not changed any .ts lately. The coerced.ts file from Jared is pretty good for now.

What I'm doing is changing the behavior of the decoder itself: libavcodecs/h263dec.c to be more exact. Thats the code that loops through the macroblocks. The code that actually decodes the bits themselves is also very important: libavcodec/ituh263dec.c. Although I don't change it.

There are essentially two ways I'm determining whether a macroblock is bad: either ffmpeg gives an error like "Error in MB: " or I see it visually. That's basicly it.

What is a good block and more importantly where its starts in the datastream is much harder to derermine. This is because these blocks have a variable length and nowhere does it say how long they are (it usually varies from 30 to ~150 bits, but sometimes its a couple hundred bits). This is for I-frames btw: the frames that are basically independent pictures in the stream and require no other frames to be decoded. There are 13 I-frames in the file btw. We have seen only two partials, so there is a lot to be discovered still.

Anyway, this is the real challenge: figuring out the starting positions of the good macroblocks after a few bad ones. And maybe we can all collaborate here. Maybe. But for now what I have tried to do is simply let the codec iterate through lot of starting positions for a block and decode from there, and if there is no error it assumes it is ok. Semi-automated trial and error essentially.

This however doesn't always work: sometimes there is no error but clearly the block (visually) isn't correct. But when trying all kinds of random starting positions another block (later in the stream) will become visible (albeit in the wrong position as already discussed in this thread). Since I log all the bit-positions of all the macroblocks I can now determine what the starting position (bit-wise) is of that block. Then I "tell" (aka hack) the codec to read that block earlier when it is supposed to be shown.

But for now I hack this in the code and I want to make this a little bit more user friendly.

Hope that answers your questions.

Regards,

arnezami
« Last Edit: 05/04/2014 05:33 am by arnezami »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Hi guys,

Here is an overview of the I-frames in the file:

#Position in fileSize in bytesFrame numbermp4-img linkimage linkCurrent state
0~254956n/an/anot extracted yet, transport stream issue?
18478801667333iframe_1.zip0% (gray)
211466121103953iframe_2.zipiframe_2.png10%
31207712892757iframe_3.zip0% (gray)
414462841653673iframe_4.zip0% (gray)
517448281709493iframe_5.zip0% (gray)
6205427629622113iframe_6.zip0% (gray)
7264196415064150iframe_7.zipiframe_7.png15%
8294088420428169iframe_8.zipiframe_8.png45% - 60%
9323942815730188iframe_9.zipiframe_9.png15%
10353797210009207iframe_10.zipiframe_10.png10%
11384065214113227iframe_11.zip0% (gray)
12413581212169246iframe_12.zip0% (gray)

Some explanation about this table:

The column "Position in file" means the position (in bytes) in the coerced.ts file. So where it's data (according to ffmpeg) begins. "Size in bytes" is the size according to ffmpeg. "Frame number" is the frame number according to ffmpeg. All based on the current coerced.ts file. Note that iframe_0 hasn't been extracted yet and several iframes don't give any output at the moment (just blank grey).

For each I-Frame I've also attached an .mp4-img file and a .png picture produced by the standard ffmpeg.

The mp4-img files were produced like this: (tip from michaelni)

Quote
./ffmpeg -i coerced.ts -vcodec copy -an -f image2 frame%d.mpg4-img

In his words:

Quote
This would split the mpeg-ts into 1 file per frame, each containing just the mpeg4-es data, no mpeg-ts anymore

This is going to be useful so we can target 1 I-frame at the time. I'm currently working on a slightly altered ffmpeg version (and some scripts) with which you can manipulate multiple macroblock positions, and semi-automatically iterate over many bit-positions in order to find a "good" block. That way anyone can help recover these images. But I still have a lot more work to do before that happens ;).

Regards,

arnezami

[edit] You need to add the option "-s:0 704x480" to ffmpeg if you want it to accept an .mp4-img file as input.
« Last Edit: 05/04/2014 09:43 am by arnezami »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Hi guys,

I've created a way so that everybody (with some basic linux skills) can help restoring these I-frames.

[edit]Attached is one file: install.txt. It contains instructions on how to install this adapted version of ffmpeg.

Here is the last part of the install.txt:

Quote
In your current directory there is now a new ffmpeg file
You can now use this new ffmpeg with additional options, namely:

1) "-debug mb_pos_size" : this enables logging of the x, y, bitposition and bitsize of the decoded macroblocks
2) "-mmb x1:y1:bitpos1,x2:y2:bitpos2" : with this you can overrule the bitposition of multiple macroblocks (so they start at the correct data)
3) "-err_detect ignore_err" : this makes sure decoding doesn't stop if there are errors (mainly due to the bad alignment of data) (this change was done by Michael Niedermayer)

Example usage:
./ffmpeg -mmb 07:14:17233,19:14:57914 -debug mb_pos_size -err_detect ignore_err -s:0 704:480 -i iframe_8.mpg4-img -f image2 img-%03d.png

In the above example we do serveral things:

- Since the macroblock at x:7 y:14 is defect we overrule its datapoint with a block at 17233. The data of this block is chosen because it contains almost no data (only 30 bits) which ensures that when put here it won't affect neighbouring blocks too much. It's a "silent" block if you will, which doesn't create too much noise.
- We have found out (after experimenting and examining the log) that a specific part of the left leg of the stage begins at bitposition 57914. Since we know where to place it (x:19 y:14) we assign this block to that datapoiint.
- We use "iframe_8.mpg4-img" as the source (see the forum, there is a list of all I-frames, http://forum.nasaspaceflight.com/index.php?topic=34597.msg1193316#msg1193316) but therefore we need to add the option "-s:0 704:480", otherwise ffmpeg cant determine the size of the video
- the option "-f image2 img-%03d.png" makes sure that the I-frame is being exported as a lossless png (the %03d is not needed when there is only one frame in the source)
- In the resulting .png you can see that the I-frame looks pretty good already!

Good luck and have fun!

Regards,
arnezami

PS. If you have any questions (or it doens't work somehow) please let me know.
PPS. Because the forum doesn't let me upload a tar.gz file I had to double compress it with zip. Sorry.

[edit] New install.txt uploaded because I used an odd version of ffmpeg which could screw up your own.
[edit] Even newer install.txt since we now have it on git! Thanks mlindner!
« Last Edit: 05/06/2014 05:13 am by arnezami »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Hi Guys,

iframe2 is starting to become alive!  ;D

No legs deployed!

btw I did a trick to make this work, because of that everything is sort of shifted up.

Have fun!

arnezami

@mlindner: I have responded to you in a pm.

[edit] almost forgot, I did this: "-mmb 40:03:11229,42:03:11229,42:05:19620"
« Last Edit: 05/04/2014 08:04 pm by arnezami »

Offline mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
Hi Guys,

iframe2 is starting to become alive!  ;D

No legs deployed!

btw I did a trick to make this work, because of that everything is sort of shifted up.

Have fun!

arnezami

@mlindner: I have responded to you in a pm.

[edit] almost forgot, I did this: "-mmb 40:03:11229,42:03:11229,42:05:19620"

Awesome!

What does your code do when it skips a block?
« Last Edit: 05/04/2014 09:37 pm by mlindner »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Awesome!

What does your code do when it skips a block?
Blocks are not really skipped as such, they are on-the-fly given a different point where they retrieve their data. So if a blocks' data would normally be corrupt I just tell it to look for different data (from a block earlier or later). And with a later block I point it its proper data point again. Therefore avoiding the corrupt data of one block affecting other blocks.

My newest strategy is to turn use detect_err = ignore, and look for blocks that seem to contain visual data (rocket structure and such). And then (by counting x and y on my screen) determining the x and y of that block, look at the log and see the bit position. Then set block x:0 y:0 to that bitposition! That works great for finding real data parts. :)

Btw. Attached is a tantalizing very sketchy version of iframe11...

Can anyone confirm this is AFTER landing? Because SpaceX might be interested in this. Be careful though looks can be deceiving with this much noise. But do I see an intact fuselage? And a leg? Or is it artefact?

Ooh and there is the timestamp :P

Hihi this is fun! :)


[edit] Forgot it again. I did: "-mmb 0:0:10020" here.
« Last Edit: 05/04/2014 10:01 pm by arnezami »

Offline mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
Awesome!

What does your code do when it skips a block?
Blocks are not really skipped as such, they are on-the-fly given a different point where they retrieve their data. So if a blocks' data would normally be corrupt I just tell it to look for different data (from a block earlier or later). And with a later block I point it its proper data point again. Therefore avoiding the corrupt data of one block affecting other blocks.

My newest strategy is to turn use detect_err = ignore, and look for blocks that seem to contain visual data (rocket structure and such). And then (by counting x and y on my screen) determining the x and y of that block, look at the log and see the bit position. Then set block x:0 y:0 to that bitposition! That works great for finding real data parts. :)

Btw. Attached is a tantalizing very sketchy version of iframe11...

Can anyone confirm this is AFTER landing? Because SpaceX might be interested in this. Be careful though looks can be deceiving with this much noise. But do I see an intact fuselage? And a leg? Or is it artefact?

Ooh and there is the timestamp :P

Hihi this is fun! :)


[edit] Forgot it again. I did: "-mmb 0:0:10020" here.

Arnezami, now that we have (and are getting more) partially good I-frames, how do we apply these same changes to the video so that the following frames can reference them properly?

Also I don't understand your description of what you do with blocks. So when it uses "different data" is it using data from other blocks or possibly just finds the correct location of its own data?
« Last Edit: 05/04/2014 11:11 pm by mlindner »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0
The mp4-img files were produced like this: (tip from michaelni)

Quote
./ffmpeg -i coerced.ts -vcodec copy -an -f image2 frame%d.mpg4-img

Its possible to extract a few more frames at the start with
./ffmpeg -i coerced.ts -vcodec copy -an -copyinkf  -f image2 frame%d.mpg4-img
They are not keyframes though

Offline michaelni

  • Member
  • Posts: 28
  • Liked: 23
  • Likes Given: 0
Ive put arnezamis changes on github:
(with some simplifications to the implementation, and very basic docs from mlindner)

should be easier to download that way

https://github.com/michaelni/FFmpeg/tree/spacexdebug1

Offline mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
Ive put arnezamis changes on github:
(with some simplifications to the implementation, and very basic docs from mlindner)

should be easier to download that way

https://github.com/michaelni/FFmpeg/tree/spacexdebug1

Just a correction, the docs are from arnezami. I only put them up in an initial github tree which michaelni merged changes from.
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
@mlindner: I can confirm the steps your new install.txt work. I've added it to my original post and removed the .zip file.

Thanks mlindner!
« Last Edit: 05/05/2014 03:00 am by arnezami »

Offline grythumn

  • Full Member
  • **
  • Posts: 243
  • Liked: 167
  • Likes Given: 246
Couple of notes:

1) This compiles (slowly) and runs fine under cygwin, so windows people can get in on the fun too.
2) When you replace a bad MMB with a small one, it keeps going from that point in the bitstream. You need to restart the stream of the next good MMB at its original point in the bitstream or the picture looks much worse and you get ghosts.

Original  error:
[mpeg4 @ 0x8001af20] MB pos/size: 0 19:04:15480 73
[mpeg4 @ 0x8001af20] MB pos/size: 0 20:04:15553 209
[mpeg4 @ 0x8001af20] ac-tex damaged at 21 4
[mpeg4 @ 0x8001af20] MB pos/size: -1 21:04:15762 73
[mpeg4 @ 0x8001af20] Error at MB: 201
[mpeg4 @ 0x8001af20] illegal dc vlc
[mpeg4 @ 0x8001af20] MB pos/size: -1 22:04:15835 10
[mpeg4 @ 0x8001af20] Error at MB: 202
[mpeg4 @ 0x8001af20] I cbpc damaged at 23 4
[mpeg4 @ 0x8001af20] MB pos/size: -1 23:04:15845 6
[mpeg4 @ 0x8001af20] Error at MB: 203
[mpeg4 @ 0x8001af20] MB pos/size: 0 24:04:15851 78
[mpeg4 @ 0x8001af20] MB pos/size: 0 25:04:15929 96

 ./ffmpeg -mmb 21:04:3656 -debug mb_pos_size -err_detect ignore_err -s:0 704:480 -i iframe_9.mpg4-img -f image2 img-%03d.png
[mpeg4 @ 0x80022240] MB pos/size: 0 19:04:15480 73
[mpeg4 @ 0x80022240] MB pos/size: 0 20:04:15553 209
[mpeg4 @ 0x80022240] MB pos/size: 0 21:04:10340 22
[mpeg4 @ 0x80022240] MB pos/size: 0 22:04:10362 22
[mpeg4 @ 0x80022240] MB pos/size: 0 23:04:10384 23
[mpeg4 @ 0x80022240] MB pos/size: 0 24:04:10407 102
[mpeg4 @ 0x80022240] MB pos/size: 0 25:04:10509 226


 ./ffmpeg -mmb 21:04:3656,24:04:15851 -debug mb_pos_size -err_detect ignore_err -s:0 704:480 -i iframe_9.mpg4-img -f image2 img-%03d.png
[mpeg4 @ 0x80022460] MB pos/size: 0 19:04:15480 73
[mpeg4 @ 0x80022460] MB pos/size: 0 20:04:15553 209
[mpeg4 @ 0x80022460] MB pos/size: 0 21:04:3656 22
[mpeg4 @ 0x80022460] MB pos/size: 0 22:04:3678 22
[mpeg4 @ 0x80022460] MB pos/size: 0 23:04:3700 22
[mpeg4 @ 0x80022460] MB pos/size: 0 24:04:15851 78
[mpeg4 @ 0x80022460] MB pos/size: 0 25:04:15929 96

Offline mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
Couple of notes:

1) This compiles (slowly) and runs fine under cygwin, so windows people can get in on the fun too.
2) When you replace a bad MMB with a small one, it keeps going from that point in the bitstream. You need to restart the stream of the next good MMB at its original point in the bitstream or the picture looks much worse and you get ghosts.

Original  error:
[mpeg4 @ 0x8001af20] MB pos/size: 0 19:04:15480 73
[mpeg4 @ 0x8001af20] MB pos/size: 0 20:04:15553 209
[mpeg4 @ 0x8001af20] ac-tex damaged at 21 4
[mpeg4 @ 0x8001af20] MB pos/size: -1 21:04:15762 73
[mpeg4 @ 0x8001af20] Error at MB: 201
[mpeg4 @ 0x8001af20] illegal dc vlc
[mpeg4 @ 0x8001af20] MB pos/size: -1 22:04:15835 10
[mpeg4 @ 0x8001af20] Error at MB: 202
[mpeg4 @ 0x8001af20] I cbpc damaged at 23 4
[mpeg4 @ 0x8001af20] MB pos/size: -1 23:04:15845 6
[mpeg4 @ 0x8001af20] Error at MB: 203
[mpeg4 @ 0x8001af20] MB pos/size: 0 24:04:15851 78
[mpeg4 @ 0x8001af20] MB pos/size: 0 25:04:15929 96

 ./ffmpeg -mmb 21:04:3656 -debug mb_pos_size -err_detect ignore_err -s:0 704:480 -i iframe_9.mpg4-img -f image2 img-%03d.png
[mpeg4 @ 0x80022240] MB pos/size: 0 19:04:15480 73
[mpeg4 @ 0x80022240] MB pos/size: 0 20:04:15553 209
[mpeg4 @ 0x80022240] MB pos/size: 0 21:04:10340 22
[mpeg4 @ 0x80022240] MB pos/size: 0 22:04:10362 22
[mpeg4 @ 0x80022240] MB pos/size: 0 23:04:10384 23
[mpeg4 @ 0x80022240] MB pos/size: 0 24:04:10407 102
[mpeg4 @ 0x80022240] MB pos/size: 0 25:04:10509 226


 ./ffmpeg -mmb 21:04:3656,24:04:15851 -debug mb_pos_size -err_detect ignore_err -s:0 704:480 -i iframe_9.mpg4-img -f image2 img-%03d.png
[mpeg4 @ 0x80022460] MB pos/size: 0 19:04:15480 73
[mpeg4 @ 0x80022460] MB pos/size: 0 20:04:15553 209
[mpeg4 @ 0x80022460] MB pos/size: 0 21:04:3656 22
[mpeg4 @ 0x80022460] MB pos/size: 0 22:04:3678 22
[mpeg4 @ 0x80022460] MB pos/size: 0 23:04:3700 22
[mpeg4 @ 0x80022460] MB pos/size: 0 24:04:15851 78
[mpeg4 @ 0x80022460] MB pos/size: 0 25:04:15929 96

Yeah took me a bit to realize that too. It's somewhat intentional as the errors may come in a string and also because a given block is dependent on the previous block for its start location. So if you replace a block with a different block then the start location of the next block is obviously wrong so its useful to let it continue along and wrap back to the same data to possibly "hit" the data at a better bit position.

Edit: attached my best try at iframe 8 thus far here. mmb setting 08:14:17233,11:14:56840 Also we need to get these iframes as perfect as possible as every other following frame references them for their own data. Afterwards we might get a pretty good looking video.
« Last Edit: 05/05/2014 04:07 am by mlindner »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Offline mlindner

  • Software Engineer
  • Senior Member
  • *****
  • Posts: 2908
  • Space Capitalist
  • Silicon Valley, CA
  • Liked: 2204
  • Likes Given: 818
It seems like the errors aren't all that common, but they're pretty uniformly spread around and it appears that SpaceX didn't encode the mpeg4 with lots of the settings that could detect and correct for errors that are built into the mpeg4 format.

Mpeg4 is a self-referential format meaning nearly every piece of data depends on some other piece of data and errors will propagate through the system as they accumulate until you have garbage referencing garbage. Those are all fixed when you hit an I-frame (what we're working on fixing), but there's very few I-frames, only 13, in the whole video that everything else references. When we fix these errors, they will still accumulate but they'll accumulate slower so things may become more recognizable.
« Last Edit: 05/05/2014 04:45 am by mlindner »
LEO is the ocean, not an island (let alone a continent). We create cruise liners to ride the oceans, not artificial islands in the middle of them. We need a physical place, which has physical resources, to make our future out there.

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1