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

Offline mvpel

  • Full Member
  • ****
  • Posts: 1124
  • New Hampshire
  • Liked: 1295
  • Likes Given: 1686
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1200 on: 05/31/2014 03:32 AM »
I wonder if we could get one of these for the next flight, to replace the pizza pan...

The Moon Gets Broadband Wireless Connection
Quote
The Lunar Laser Communication Demonstration (LLCD) transmitted over 384,633 kilometers between here and the moon at a download rate of 622 megabits per second. They also sent data from Earth to the moon at 19.44 megabits per second. Thatís 4,800 times faster than the best radio frequency uplink ever used.

"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline MarsInMyLifetime

  • Full Member
  • **
  • Posts: 278
  • Austin, TX
    • Light of Day
  • Liked: 132
  • Likes Given: 137
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1201 on: 05/31/2014 05:02 AM »
Nah, he got exactly the branding he was hoping for by using his low-cost, MacGuyverish patch antenna to get proof of this landing's success. That corrupted stream with its "can do" back story is turning into a company legacy that will pay off for years down the road. They'll improve their game as they go, but on that stormy day, a million dollar cat toy would not have been the right tool for the job.
Don

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1202 on: 05/31/2014 08:49 AM »
Ok, the first part of this is done. Unfortunately in PNG format the zip file is 85 MB, so trying to auto-upload it to the wiki is probably pushing it. No pun intended. Instead, I put it on Google Drive at this url:

https://drive.google.com/file/d/0B_wTAwfYg03FQ3p2UVlkZE9MckU/edit?usp=sharing

Also on BTSync at B76OWSNRL5HWE47N7SHT4ZIX2B3B63IXT

This is ~250 frames in PNG format generated by scraping the wiki and then running it through ffmpeg. Why is this useful? Well, you can turn these into a movie file with this command:

ffmpeg -y -start_number 40 -i landing_base_set/frame-%03d.png -c:v libx264 -r 15 -pix_fmt yuv420p out.mp4

Also, you can run a batch process on these images to do post-processing or add annotations.

The zip archive will be regenerated every hour if the wiki has seen any updates.

Don't suppose you can also put a video somewhere on google drive too? If so I can probably automate pushing it to youtube or something.

This is done. The video is here:

http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_base_set.mp4

Whenever it is regenerated your URL will get a POST.

I added SwissCheese's title card. Frames 161-200 and 281-283 now come from the fixed .ts files.

I have noticed some block bugs that aren't showing on the wiki, which might be because my copy of the split .ts files is out of date. Do you have a newer set of split (i + 19p) files?

Online Shanuson

  • Full Member
  • **
  • Posts: 293
  • Liked: 197
  • Likes Given: 600
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1203 on: 05/31/2014 09:11 AM »
I think he is using the one i send him, which is the same as the last one i uploaded here

Ok, the first part of this is done. Unfortunately in PNG format the zip file is 85 MB, so trying to auto-upload it to the wiki is probably pushing it. No pun intended. Instead, I put it on Google Drive at this url:

https://drive.google.com/file/d/0B_wTAwfYg03FQ3p2UVlkZE9MckU/edit?usp=sharing

Also on BTSync at B76OWSNRL5HWE47N7SHT4ZIX2B3B63IXT

This is ~250 frames in PNG format generated by scraping the wiki and then running it through ffmpeg. Why is this useful? Well, you can turn these into a movie file with this command:

ffmpeg -y -start_number 40 -i landing_base_set/frame-%03d.png -c:v libx264 -r 15 -pix_fmt yuv420p out.mp4

Also, you can run a batch process on these images to do post-processing or add annotations.

The zip archive will be regenerated every hour if the wiki has seen any updates.

Don't suppose you can also put a video somewhere on google drive too? If so I can probably automate pushing it to youtube or something.

This is done. The video is here:

http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_base_set.mp4

Whenever it is regenerated your URL will get a POST.

I added SwissCheese's title card. Frames 161-200 and 281-283 now come from the fixed .ts files.

I have noticed some block bugs that aren't showing on the wiki, which might be because my copy of the split .ts files is out of date. Do you have a newer set of split (i + 19p) files?

Right the videos end up here: https://www.youtube.com/spacexlandingrestore

Hopefully it all works :D

« Last Edit: 05/31/2014 09:28 AM by IainCole »

Offline arnezami

  • Full Member
  • **
  • Posts: 284
  • Liked: 262
  • Likes Given: 346
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1205 on: 05/31/2014 10:16 AM »
This is done. The video is here:

http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_base_set.mp4

Whenever it is regenerated your URL will get a POST.

I added SwissCheese's title card. Frames 161-200 and 281-283 now come from the fixed .ts files.

I have noticed some block bugs that aren't showing on the wiki, which might be because my copy of the split .ts files is out of date. Do you have a newer set of split (i + 19p) files?
Cool  8)

I was just wondering though. Sometimes we put real comments combined with actuall mmbs in the wiki like this: (see: frame 63)

Quote
25:1:44861,41:1:-3,
38:4:9585,16:16:-3,
0:18:45141,18:27:-3,
43:27:68567,11:28:-3,
17:28:70673,7:29:-3,
8:29:71924,43:29:-3
unsure about the bottom part (btw
43:29:-3 is needed for next frame)

How do you make sure you extract the correct mmb from something like this? Should we adhere to some kind of format? Or should we not post comments at the place we post mmbs?

Regards,

arnezami

This is done. The video is here:

http://adama.nocdirect.com/~wronkiew/spx_crs3/landing_base_set.mp4

Whenever it is regenerated your URL will get a POST.

I added SwissCheese's title card. Frames 161-200 and 281-283 now come from the fixed .ts files.

I have noticed some block bugs that aren't showing on the wiki, which might be because my copy of the split .ts files is out of date. Do you have a newer set of split (i + 19p) files?
Cool  8)

I was just wondering though. Sometimes we put real comments combined with actuall mmbs in the wiki like this: (see: frame 63)

Quote
25:1:44861,41:1:-3,
38:4:9585,16:16:-3,
0:18:45141,18:27:-3,
43:27:68567,11:28:-3,
17:28:70673,7:29:-3,
8:29:71924,43:29:-3
unsure about the bottom part (btw
43:29:-3 is needed for next frame)

How do you make sure you extract the correct mmb from something like this? Should we adhere to some kind of format? Or should we not post comments at the place we post mmbs?

Regards,

arnezami

Perhaps keeping this file https://github.com/IainCole/SpaceXVideoApp2/blob/master/data.json up to date based off the wiki might be useful, for 2 reasons, it gives us a solid data structure for MMBs so that people can use it to generate videos without having to parse the wiki. Also the online editor will take those values as defaults so people don't have to copy everything across from the wiki to work on one part of a segment.



Offline arnezami

  • Full Member
  • **
  • Posts: 284
  • Liked: 262
  • Likes Given: 346
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1207 on: 05/31/2014 12:14 PM »
Hi guys,

I've been busy trying to let the decoder output the bits and their interpretation of all the (macro)block parts. And I think I have succeeded. I still need to clean it up and make it compatible/configurable with the existing codebase. But I wanted to share some details so others (mainly @IainCole) can already start thinking/working on an extention of the online tool. Also for others to get used to the idea.

I think it will bring us to the next level.  8)

Here is the output of the extra log: (the stream of bits was a bit too wide for the forum so I put a newline in it)

Quote
BITLOG:000:00:00:cbpc:550:551:0
BITLOG:000:00:00:ac_pred:551:552:1
BITLOG:000:00:00:cbpy:552:554:15

BITLOG:000:00:00:dc_lum0_size:554:557:4
BITLOG:000:00:00:dc_lum0_level:557:561:-13
BITLOG:000:00:00:dct561:578:0:3:-6
BITLOG:000:00:00:dct578:585:1:1:-1

BITLOG:000:00:00:dc_lum1_size:585:588:4
BITLOG:000:00:00:dc_lum1_level:588:592:8
BITLOG:000:00:00:dct592:602:1:12:-1
BITLOG:000:00:00:dc_lum2_size:602:604:1
BITLOG:000:00:00:dc_lum2_level:604:605:-1
BITLOG:000:00:00:dct605:608:0:0:1
BITLOG:000:00:00:dct608:614:0:2:-1
BITLOG:000:00:00:dct614:619:0:1:-1
BITLOG:000:00:00:dct619:649:0:29:1
BITLOG:000:00:00:dct649:659:1:14:-1

BITLOG:000:00:00:dc_lum3_size:659:661:1
BITLOG:000:00:00:dc_lum3_level:661:662:-1
BITLOG:000:00:00:dct662:667:1:0:-1
BITLOG:000:00:00:dc_chrom4_size:667:671:4
BITLOG:000:00:00:dc_chrom4_level:671:675:13
BITLOG:000:00:00:dc_chrom5_size:675:678:3
BITLOG:000:00:00:dc_chrom5_level:678:681:-7

BITLOG:000:00:00:bits:550:681:11110010010000001100001101110011111001100000001001111101
000101111110100000111100111101000000000001100001000111100111100011101001000


What you can see here is the bit-by-bit decoding of the first macroblock of frame 181.

Red: These are the macroblock header parts: mainly cbpc, ac_pred and cbpy.
Blue: These are the DC-values: the size (in bits) of the level and the level itself. Bitflips here are very damaging and easily fixed! This is on a block-level: 16x16px or 8x8px.
Green: These are the DCT values. This is basically sub-block information. So sub-16x16 or sub-8x8 data.

Purple: these are the actual bits in the macroblock. The red/blue/green parts above it are encoded by these bits. Each log-line contains it's start and end position. So they can easily be matched with these purple bits (by the editor I mean ;)).

I've been thinking of the easiest way to incorporate this into the online editor. What I'm thinking of is the following:

* When you double-click on a macro-block an additional (large) area becomes visible to the right side of the editor. If you have a wide monitor there should be plenty of room there.
* In the backround the application calls the server/ffmpeg with an additional command with the double-clicked macroblock x,y as argument (exact syntax still to-be-determined). This gives back the normal log plus the log shown above (if needed you could also omit the usual pos/size log). However it only gives BITLOG lines for the macroblock clicked and a few following it. So it logs only what you want to know.
* The extra log gives all bits for a macroblock (purple here). The application recognizes the BITLOG and for each part (red/blue/green) it creates a <span> with the corresponding bits (from purple) in it. It adds a "tittle" containing the corresponding BITLOG-line (without the "BITLOG:000:00:00:" part). So if you hover your mouse over it it will show you the meaning of the bits. It also colors the spans according to their type (red/blue/green). It puts these spans next to each other. And for every macroblock there is a break.

So you would get something like this:

Quote
        <div>
            <span class="red" title="cbpc:550:551:0">1</span>
            <span class="red" title="ac_pred:551:552:1">1</span>
            <span class="red" title="cbpy:552:554:15">11</span>
            <span class="blue" title="dc_lum0_size:554:557:4">001</span>
            <span class="blue" title="dc_lum0_level:557:561:-13">0010</span>
            <span class="green" title="dct561:578:0:3:-6">00000110000110111</span>
            <span class="green" title="dct578:585:1:1:-1">0011111</span>
            <span class="blue" title="dc_lum1_size:585:588:4">001</span>
            <span class="blue" title="dc_lum1_level:588:592:8">1000</span>
        <div>
   

Resulting in this:



You can then hover those strings of colored bits and see what they represent. If something is off (for example a DC is way too high) you can now see which bits are responsible for that. Ideally you want to be able to click on those bits to flip them (that's not for a first version I think). And it would also be nice  to see the macroblock (2x-4x larger than original) left next to the string of bits. So you can see the effect. But just having this information is already very revealing I think. It will help bitflipping a lot already.

I'm still working on this but let me know if you have ideas/suggestions.

Regards,

arnezami
« Last Edit: 05/31/2014 01:30 PM by arnezami »

Looks interesting, is there still a restriction on the number of bitflip operations? I seem to remember there was a max of 8 at some point

Offline arnezami

  • Full Member
  • **
  • Posts: 284
  • Liked: 262
  • Likes Given: 346
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1209 on: 05/31/2014 01:23 PM »
Perhaps keeping this file https://github.com/IainCole/SpaceXVideoApp2/blob/master/data.json up to date based off the wiki might be useful, for 2 reasons, it gives us a solid data structure for MMBs so that people can use it to generate videos without having to parse the wiki. Also the online editor will take those values as defaults so people don't have to copy everything across from the wiki to work on one part of a segment.
I think keeping an up-to-date file in a central place is a good idea.

But I'm not sure how to keep up with all the updates on the wiki. If you could somehow show the differences between the .json and the wiki that would be great. Then you can edit the .json if needed.

Alternatively you could have a centralized database with a little web-app around it where you can enter/edit mmbs.

Not sure what would work best.

[edit] As to your question about the possible restriction of bitflips: I dont know, will have to look into that.
« Last Edit: 05/31/2014 01:28 PM by arnezami »

Offline SwissCheese

  • Full Member
  • *
  • Posts: 165
  • Liked: 250
  • Likes Given: 94
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1210 on: 05/31/2014 04:00 PM »
Hi guys,

Important note to everyone using the wiki/online editor: the online editor has been updated lately. This means you have to use -3s instead of -1s for P-frames. Just keep that in mind.

I am currently replacing all -1s with -3s for all P-frames on the wiki and re-uploading all those images. Again. :o

Regards,

arnezami

PS. The -1s are actually causing the gray "bands" in the picture...

The online editor gives a correct image with the -3 but does not seem to update the macroblock information and errors. Is it on purpose?

Can you give me a specific example of what isn't working and what you expect to see?

Just take any p-frame with errors, and write 0:0:-3 (should discard the whole frame) the yellow squares stay and the information on top of the frame still shows the discarded information.

(difficult to write from a mobile phone)

That seems to be what's coming back from the log :/ Dunno if it's specific to the online editor?

Quialiss found out that explicitly writing 0:0:66 (first macroblock) solved this issue. Does someone have an idea about what's causing this?

Offline moralec


Alternatively you could have a centralized database with a little web-app around it where you can enter/edit mmbs.

Wow, I like this idea. The way we are sharing codes is really suboptimal. However,  we should really avoid building yet another system. What if:
- we start by creating a database in a server to store all current MMB codes.
- we then could use the existing online tool to read and write to the dataset. I'm thinking about save and load MMB code buttons.  8)
- In order to simplify the wiki update process, we could add  small widgets in each table/row to display the latest MMB code from this server.
- we could even go beyond, and have an export image to wiki button in the online tool, that saves the file as framenumber.jpg in the wiki site, overwriting previous image files and thus directly updating the table

If we go in this direction, the wiki will become a place to monitor progress (to see what frames are fixed, partially fixed or untouched), and only a few of us would require to do edits. All the real interaction of the people working with frames, in turn, will happen via the online tool :).

I doesn't seem like rocket science, but it does seem like a lot of work specially on the online tool side (we don't want you to hate us Iaincole). Ideas? Any of our silent readers is up to the challenge of contributing on this task?
« Last Edit: 05/31/2014 05:08 PM by moralec »

Offline arnezami

  • Full Member
  • **
  • Posts: 284
  • Liked: 262
  • Likes Given: 346
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1212 on: 05/31/2014 05:21 PM »
Hi guys,

Here is the source code for logging macroblock data on a bit-level. :)

The new command is:

Quote
-mb_bitlog <framenr>:<mb_x>:<mb_y>:<nr_of_mbs_to_log>

So for example the following command will log the macroblock data from frame 0 (first frame in file), from macroblock 3,10 to macroblock 23,10:

Quote
-mb_bitlog 0:3:10:20

These files are contained in the zip file that is attached:

libavcodec/options_table.h
libavcodec/avcodec.h
libavcodec/h263dec.c
libavcodec/mpeg4videodec.c

I used the latest version and changed those files so if you have the latest version (with the "bruteforcing"-addition) then you should be fine.

For further explanation of what this does go here and here.

I might write a more thorough explanation of what all the parts in the macroblocks are (as far as I understand them now) if there is a need for that. And which tables you probably need (from the MPEG4 spec) in order to put this to better use. But you should already be able to get quite a bit information out of this.

Good luck and have fun!

Regards,

arnezami

@IainCole: if you have any trouble please let me know.
« Last Edit: 05/31/2014 06:19 PM by arnezami »

Offline cartman

  • Full Member
  • ****
  • Posts: 506
  • Greece
  • Liked: 487
  • Likes Given: 2594
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1213 on: 05/31/2014 05:58 PM »
Ok, so i'm a linux guy with web servers and the works, and would like to help. First of all, i would like to help with recovering the video. Is there an updated guide of where to start? should i use arnezami's latest build?

Offline arnezami

  • Full Member
  • **
  • Posts: 284
  • Liked: 262
  • Likes Given: 346
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1214 on: 05/31/2014 06:10 PM »
Ok, so i'm a linux guy with web servers and the works, and would like to help. First of all, i would like to help with recovering the video. Is there an updated guide of where to start? should i use arnezami's latest build?
On the wiki there is a section calls "Work in Progress " which has an "ACTIVE" part which contains two links: one to a tutorial one to where we post our results.

There is also a "Reconstruction Tools" section in the wiki. The two top links (one for P-frames one for I-frames) go to the online editors. There you can try to fix the frames.

You don't need my latest addition to the ffmpeg-tool to help for now. What we are developing is for making the online tools more powerful.

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1215 on: 05/31/2014 07:25 PM »
Cool  8)

I was just wondering though. Sometimes we put real comments combined with actuall mmbs in the wiki like this: (see: frame 63)

Quote
25:1:44861,41:1:-3,
38:4:9585,16:16:-3,
0:18:45141,18:27:-3,
43:27:68567,11:28:-3,
17:28:70673,7:29:-3,
8:29:71924,43:29:-3
unsure about the bottom part (btw
43:29:-3 is needed for next frame)

How do you make sure you extract the correct mmb from something like this? Should we adhere to some kind of format? Or should we not post comments at the place we post mmbs?

Regards,

arnezami

Yes, that line would have messed up the scraper, which is why I had not transitioned it yet. I think I will simplify the parsing so it panics and sends me an email when it sees something like that instead of trying to send it to ffmpeg. Part 4 is fixed now. I moved frame 63's instructions to a text file, and the auto-build uses rawfinal for that segment.

Would it help if I had it upload the generated segment mmbs to the wiki?

Youtube video exports seem to be running along nicely :) https://www.youtube.com/user/spacexlandingrestore

Offline cscott

  • Senior Member
  • *****
  • Posts: 2949
  • Liked: 2054
  • Likes Given: 664
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1217 on: 05/31/2014 08:01 PM »
Yes, that line would have messed up the scraper, which is why I had not transitioned it yet. I think I will

Can you just use a regexp to ignore any lines that don't match the expected format?  Then it should be straightforward to add whatever sort of comment you like, so long as it's obvious isn't not a valid option.

Offline maschnitz

  • Member
  • Posts: 3
  • Liked: 0
  • Likes Given: 11
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1218 on: 05/31/2014 08:04 PM »
I doesn't seem like rocket science, but it does seem like a lot of work specially on the online tool side (we don't want you to hate us Iaincole). Ideas?

VCSes - version control systems - are really good at moralec's database problem. One idea is to shoehorn this into a VCS by using a VCS as storage.

Here's one way to do that: force MMB lists into a VCS friendly format, by
a) breaking up the MMBs into one per line [VCSes tend to work best on whole lines at a time] and
b) sort the MMBs into a standard sort order, most likely the raster order most folks are already used to.  [EDIT: I guess this isn't strictly necessary, but may make IainCole's life easier]
c) Then you need to always check in and out of the VCS via something that understands the format. IainCole's website, or some other website, for example, would be the only entity with access to the VCS. This website would be responsible for parsing raw MMBs, and providing the MMBs back in a ffmpeg-friendly format.
d) Ideally this file format would have comments to allow for notes and simple alternatives. The VCS would be responsible for full 'branches' [git/mercurial is good for this].

And then a flat file format might come in handy in other ways.

There are other ways: you could use raw RCS diffs to manage things; you could find a diff program that's really good at big long lines (most aren't); you can code up the delta checking by hand; you can simply store all the MMBs ever in groups, normalized in the database, for users to sort out; etc.
« Last Edit: 05/31/2014 08:10 PM by maschnitz »

Offline wronkiew

  • Full Member
  • *
  • Posts: 186
  • 34.502327, -116.971697
  • Liked: 105
  • Likes Given: 125
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1219 on: 05/31/2014 08:04 PM »
Youtube video exports seem to be running along nicely :) https://www.youtube.com/user/spacexlandingrestore

Oh, right, in the new version 0:0:-3 skips a pframe, not 0:0:-1.

Tags: