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

Offline corrodedNut

  • Full Member
  • ****
  • Posts: 1542
  • Liked: 216
  • Likes Given: 133
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1340 on: 06/03/2014 10:18 pm »
Oh I do like the idea behind this:

https://www.youtube.com/channel/UCyZDgyJBYz3OXD3JbDJzNww

That is a great one stop page to see the progress over time.

I suggest that you include this link in the OP, thanks!

Offline Quialiss

  • Member
  • Posts: 75
  • Liked: 82
  • Likes Given: 29
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1341 on: 06/03/2014 11:04 pm »
Revelation for the p frames in part 10 -- the ones with the big gray areas that shouldn't be.

-3 completely ignores a block.  It also clears chroma and luma, like -2, so subsequent blocks don't inherit it.  This isn't terribly noticeable in most p frames because there aren't a lot of non-movement blocks.  Except in part 10.  Part 10, the camera is being overexposed by that big blast of steam and the rest of the frame gets dark, changing the whole frame on a regular basis. 

We stopped using -1 in p frames because it made gray blocks.  It only does that if the blocks that are being blanked with -1 have nothing to inherit from, aka movement blocks. 

Test frame 185, take a look at it in the editor, pick it apart. 

X:19164:80,5:7:-1,23:7:-3,24:7:-1,27:7:-3,29:7:-1,3:8:21583:5:0:0:0:0:0,5:8:21693:0:-5:0:0:0:0, 6:8:21763:-10:0:0:0:0:0,8:8:21872:0:5:0:0:0:0,17:11:-3,35:11:37109,28:12:39566,35:12:40350, 8:13:-1:0:0:-10:0:0:0,9:13:-1,16:13:-3,28:13:43161,32:13:43824,15:14:45251:20:0:0:0:0:0, 6:16:52992,0:19:-3,39:19:70393,38:20:-3,42:20:75770,38:22:-3,17:23:84384,10:28:-3

compared to

X:19164:80,5:7:-3,3:8:21583,17:11:-3,35:11:37109,28:12:39566,35:12:40350,8:13:-3, 28:13:43161,32:13:43824,0:19:-3,39:19:70393,38:20:-3,42:20:75770,38:22:-3,17:23:84384,10:28:-3



I need to sleep now.   :)


Offline mhenderson

  • Member
  • Posts: 71
  • USA
  • Liked: 101
  • Likes Given: 18
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1342 on: 06/04/2014 12:14 am »
Revelation for the p frames in part 10 -- the ones with the big gray areas that shouldn't be.

-3 completely ignores a block.  It also clears chroma and luma, like -2, so subsequent blocks don't inherit it.  This isn't terribly noticeable in most p frames because there aren't a lot of non-movement blocks.  Except in part 10.  Part 10, the camera is being overexposed by that big blast of steam and the rest of the frame gets dark, changing the whole frame on a regular basis. 

We stopped using -1 in p frames because it made gray blocks.  It only does that if the blocks that are being blanked with -1 have nothing to inherit from, aka movement blocks. 

Test frame 185, take a look at it in the editor, pick it apart. 

X:19164:80,5:7:-1,23:7:-3,24:7:-1,27:7:-3,29:7:-1,3:8:21583:5:0:0:0:0:0,5:8:21693:0:-5:0:0:0:0, 6:8:21763:-10:0:0:0:0:0,8:8:21872:0:5:0:0:0:0,17:11:-3,35:11:37109,28:12:39566,35:12:40350, 8:13:-1:0:0:-10:0:0:0,9:13:-1,16:13:-3,28:13:43161,32:13:43824,15:14:45251:20:0:0:0:0:0, 6:16:52992,0:19:-3,39:19:70393,38:20:-3,42:20:75770,38:22:-3,17:23:84384,10:28:-3

compared to

X:19164:80,5:7:-3,3:8:21583,17:11:-3,35:11:37109,28:12:39566,35:12:40350,8:13:-3, 28:13:43161,32:13:43824,0:19:-3,39:19:70393,38:20:-3,42:20:75770,38:22:-3,17:23:84384,10:28:-3



I need to sleep now.   :)

In P frames, the interpreter seems to use the contents of 43:29 as the filler for a good fraction of the scattered blocks. One strategy is to give 43:29 a neutral color, such as the color of water (43:29:0:0:0:0:12:-6.

Offline SwissCheese

  • Full Member
  • *
  • Posts: 166
  • Liked: 256
  • Likes Given: 107
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1343 on: 06/04/2014 12:51 am »
Oh I do like the idea behind this:

https://www.youtube.com/channel/UCyZDgyJBYz3OXD3JbDJzNww

That is a great one stop page to see the progress over time.

I agree it is awesome. Of course I will beg for more :-) ... It would be sweet to have a slow motion (3 fps?) copy running immediately after the 15 fps video.

It doesn't have all the latest corrections (parts 3, 4, 5, 13, 14 still come from previous version) but here it is with nominal framerate and with 3 frames per second. It's getting really nice!

Edit: it was the wrong quote... changed to the good one :)
« Last Edit: 06/04/2014 01:10 am by SwissCheese »

Offline JohnKiel

  • Member
  • Posts: 15
  • United States
  • Liked: 10
  • Likes Given: 0
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1344 on: 06/04/2014 01:22 am »
I'll host any files this project needs, or even any daemon as long as I don't have to jump through flaming hoops to get it running on a CentOS 5 system(or systems).  Primary circuit is a 90th percentile 10g line that usually sees less than 75Mbps of it's 1Gbps monthly commit, so LOTS of free bandwidth(something like 250TB/mo) is sitting around right now.

Hit me with a PM anytime.

Thanks Req,  I've sent you a PM.

All the spreadsheets should now be pointing to my image proxy script.  Seems to be running alright, but I notice some strange caching issues that  could be related to he script timing out (current host doesn't let me adjust the timeout).

Changes to MMBs may not show up in the images immediately.  Give it a little time, refresh your browser, etc.

After I finish cleaning the script up, I'll upload it somewhere.  Maybe the git for SpaceXVideoApp2 is the best place for it?

Just wanted to publicly acknowledge Req for hosting, and assistance in migrating, the image proxy script used for automatically displaying up-to-date images on the new "Frames" Spreadsheets.

Thanks again Req!

Offline meekGee

  • Senior Member
  • *****
  • Posts: 14166
  • N. California
  • Liked: 14053
  • Likes Given: 1392
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1345 on: 06/04/2014 04:01 am »
Keep in mind, there are THOUSANDS of bits in each frame, so a 'long' MMB (in this case 129 commands) is still a very SMALL portion of the data contained there-in.

That's EXACTLY the distinction between a repair and a retouch.

When you repair, a small number of changes result in a large improvements, since the original data that is assumed to still exist in the frame becomes ungarbled.

Once it takes one bit command to "fix" one pixel, then you're 100% retouching it.

Seems to me you're safely in "repair" territory.
« Last Edit: 06/04/2014 04:30 am by meekGee »
ABCD - Always Be Counting Down

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1346 on: 06/04/2014 04:28 am »
Hi guys,

I think it would be really cool to include a repair-video of at least one iframe (but probably several) in the final video compilation. This is similar to the one from Quialiss.



But instead of just showing the luma/chroma fixes, start with the original (corrupted) iframe, then add one corrected position at a time and then show the luma/chroma fixes one at-a-time. Then I think any John Doe will understand it. (i can probably make a script that creates such a repair-video for any iframe). I think this would also work very well for an article (edited by Chris) explaining the way we repaired it and how things went chronologically.

Since the repair of the iframe 14 was so well received I will try frame 15. Its the last part of the video people will see, so I will try to make it look good. Don't get your hopes up though, this one is a toughy. ;)

Btw the reason why the repair mmb's for frame 14 (and probably also 15) are quite large is they have one or several complete "horizontal bars" of -1s" in them. This effectively removes all inherited data from the top, which you have to restore for (almost) every macroblock just below it. It's very tedious work, but in the end it's rewarding :).

Regards,

arnezami

« Last Edit: 06/04/2014 04:34 am by arnezami »

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1347 on: 06/04/2014 05:20 am »
Oh I do like the idea behind this:

https://www.youtube.com/channel/UCyZDgyJBYz3OXD3JbDJzNww

That is a great one stop page to see the progress over time.

I agree it is awesome. Of course I will beg for more :-) ... It would be sweet to have a slow motion (3 fps?) copy running immediately after the 15 fps video.

It doesn't have all the latest corrections (parts 3, 4, 5, 13, 14 still come from previous version) but here it is with nominal framerate and with 3 frames per second. It's getting really nice!

Edit: it was the wrong quote... changed to the good one :)
Hi,

Nice videos SwissCheese!  8)

I would love to see the latest corrections in it :).

As for the automated videos: it looks nice but usually a video compiled/released by hand (usually by SwissCheese) looks quite a lot better. When looking at it a little bit more closely I think there are still a few issues:

1) It doesn't remove frames (as in 0:0:-3) that have not been touched yet. For example frames 42-60. They are still unrepaired and should not be put into the video yet.
2) It doesn't seem to make a distinction between "no changes needed" and "lets forget this one". I think.
3) In the video from 19:35:08 through 19:35:10 there seems to be no movement even though frames 121-140 have been repaired.
4) We have no feedback when we haven't filled in an mmb correctly on the wiki (for example added a comment that effectively disables the frame). This would be very useful. Since you can then debug the problem.
5) Is the automated video still based on the wiki or on the spreadsheet now?

This list might not be complete but maybe somebody can take a look at it.

Regards,

arnezami

PS. I think it would be a good idea to add a "comments"-column to the wiki. The mmb-column would strictly be used for making the (automated) video (and might contain 0:0:-3) while the comments-column might contain comments and/or mmbs which aren't good enough yet to put into the video.
« Last Edit: 06/04/2014 05:30 am by arnezami »

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 #1348 on: 06/04/2014 07:15 am »
Hi,

Nice videos SwissCheese!  8)

I would love to see the latest corrections in it :).

As for the automated videos: it looks nice but usually a video compiled/released by hand (usually by SwissCheese) looks quite a lot better. When looking at it a little bit more closely I think there are still a few issues:

1) It doesn't remove frames (as in 0:0:-3) that have not been touched yet. For example frames 42-60. They are still unrepaired and should not be put into the video yet.
2) It doesn't seem to make a distinction between "no changes needed" and "lets forget this one". I think.
3) In the video from 19:35:08 through 19:35:10 there seems to be no movement even though frames 121-140 have been repaired.
4) We have no feedback when we haven't filled in an mmb correctly on the wiki (for example added a comment that effectively disables the frame). This would be very useful. Since you can then debug the problem.
5) Is the automated video still based on the wiki or on the spreadsheet now?

This list might not be complete but maybe somebody can take a look at it.

Regards,

arnezami

PS. I think it would be a good idea to add a "comments"-column to the wiki. The mmb-column would strictly be used for making the (automated) video (and might contain 0:0:-3) while the comments-column might contain comments and/or mmbs which aren't good enough yet to put into the video.

1. A first pass was made on these with the fixed_edit8.ts files. I've been moving all the segments over to the final .ts files as good i-frames are posted. Which, it looks like we have for parts 3-15 now.

2. Yes, this was a bug. Thanks for catching that.

3. 121 did not have an i-frame until recently. I'll move it over to the final.ts file.

4. I will start auto-posting the mmbs to the wiki so they can be compared against the work pages. (Some of this might not get done until tomorrow)

5. Based on the wiki. I took a look at basing it on the spreadsheets, but I noticed problems with some of the frames, for example 266 and 267 are different in the spreadsheet and the wiki, and the fixes on the wiki are better. Which are we considering canonical?

Offline arnezami

  • Full Member
  • **
  • Posts: 285
  • Liked: 267
  • Likes Given: 378
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1349 on: 06/04/2014 07:21 am »
Wiki is leading.

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 #1350 on: 06/04/2014 08:05 am »
The autobuilt video is updated with fixes.

Should we look into easing the transitions between segments? For example you can see in pframes 122-140 the block update images are lighter than the iframe and a slightly different color. Then iframe 141 comes along and it matches the preceding pframes but not iframe 121. Is there a global brightness/chroma adjustment we could apply to the entire iframe?

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 #1351 on: 06/04/2014 08:08 am »
Oh I do like the idea behind this:

https://www.youtube.com/channel/UCyZDgyJBYz3OXD3JbDJzNww

That is a great one stop page to see the progress over time.

One thing I've noticed is that the channel is putting out 'updated' videos at a really high rate... it tends to over-saturate the 'cool' effect of watching it develop.

So while a few builds a day is cool up front, perhaps it is worthwhile to delete or archive all but one video per day every couple days.  That way someone who goes there can truly appreciate the evolution of the video from initial to final form without being inundated by small deltas.

I'd be happy to add an alternate build, perhaps daily? IainCole, are you able to handle a second video update post?

Offline lgjy98d

  • Member
  • Posts: 10
  • Liked: 6
  • Likes Given: 0
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1352 on: 06/04/2014 08:33 am »
Unfortunately, it looks like the MMBs can create an image request URL that's larger than the ~2KB Google Sheet's IMAGE function can manage.

A bit ironic considering the editor had to be modified to deal with the long MMBs.  It still works for all the individual p frames though, which is great!

I'm tinkering with a work-around.  Basically a proxy that allows a much shorter URL to request the image.  Currently sorting out how to cache and respond with 304's to avoid quickly using up the paltry 10GB/month I get on my chosen host. (If anyone with more bandwidth is willing to host the simple php image proxy script once I'm done, let me know.)

I'll host any files this project needs, or even any daemon as long as I don't have to jump through flaming hoops to get it running on a CentOS 5 system(or systems).  Primary circuit is a 90th percentile 10g line that usually sees less than 75Mbps of it's 1Gbps monthly commit, so LOTS of free bandwidth(something like 250TB/mo) is sitting around right now.

Hit me with a PM anytime.

Thanks Req,  I've sent you a PM.

All the spreadsheets should now be pointing to my image proxy script.  Seems to be running alright, but I notice some strange caching issues that  could be related to he script timing out (current host doesn't let me adjust the timeout).

Changes to MMBs may not show up in the images immediately.  Give it a little time, refresh your browser, etc.

After I finish cleaning the script up, I'll upload it somewhere.  Maybe the git for SpaceXVideoApp2 is the best place for it?

Google Spreadsheets are doing all the best to limit the Slashdot DOS effect by extensively caching data. For instance the spreadsheet is published at regular intervals but they can be even up to 5 minutes. I.e. the JSON feed from spreadsheet is often late, thus you cannot immediately get changes you do in spreadsheet via json feed.

Another "fix" Google is employing is caching any external data, i.e. when you pull the image with IMAGE function the request most probably passes the proxy, and unless there is a change in URL parameter to IMAGE function every time, you'll be geting cached image that Google fetched some time ago. This lets google limit its DOS effect on resources lined in the spreadsheet (i.e. it doesn't matter how many visitor spreadsheet gets).

Hope this explains delays in image update frequency if images are being proxied via external system. The cumulative delay here can be up to 10 minutes, that is not too bad, considering the fact that image and all subsequent frames are updated automatically without any extra manual work (frame generation, upload to wiki, updating wiki referencing it, etc.)

Offline Jester

  • Administrator
  • Senior Member
  • *****
  • Posts: 7980
  • Earth
  • Liked: 6540
  • Likes Given: 157
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1353 on: 06/04/2014 01:09 pm »
Unfortunately, it looks like the MMBs can create an image request URL that's larger than the ~2KB Google Sheet's IMAGE function can manage.

A bit ironic considering the editor had to be modified to deal with the long MMBs.  It still works for all the individual p frames though, which is great!

I'm tinkering with a work-around.  Basically a proxy that allows a much shorter URL to request the image.  Currently sorting out how to cache and respond with 304's to avoid quickly using up the paltry 10GB/month I get on my chosen host. (If anyone with more bandwidth is willing to host the simple php image proxy script once I'm done, let me know.)

I'll host any files this project needs, or even any daemon as long as I don't have to jump through flaming hoops to get it running on a CentOS 5 system(or systems).  Primary circuit is a 90th percentile 10g line that usually sees less than 75Mbps of it's 1Gbps monthly commit, so LOTS of free bandwidth(something like 250TB/mo) is sitting around right now.

Hit me with a PM anytime.

Thanks Req,  I've sent you a PM.

All the spreadsheets should now be pointing to my image proxy script.  Seems to be running alright, but I notice some strange caching issues that  could be related to he script timing out (current host doesn't let me adjust the timeout).

Changes to MMBs may not show up in the images immediately.  Give it a little time, refresh your browser, etc.

After I finish cleaning the script up, I'll upload it somewhere.  Maybe the git for SpaceXVideoApp2 is the best place for it?

Google Spreadsheets are doing all the best to limit the Slashdot DOS effect by extensively caching data. For instance the spreadsheet is published at regular intervals but they can be even up to 5 minutes. I.e. the JSON feed from spreadsheet is often late, thus you cannot immediately get changes you do in spreadsheet via json feed.

Another "fix" Google is employing is caching any external data, i.e. when you pull the image with IMAGE function the request most probably passes the proxy, and unless there is a change in URL parameter to IMAGE function every time, you'll be geting cached image that Google fetched some time ago. This lets google limit its DOS effect on resources lined in the spreadsheet (i.e. it doesn't matter how many visitor spreadsheet gets).

Hope this explains delays in image update frequency if images are being proxied via external system. The cumulative delay here can be up to 10 minutes, that is not too bad, considering the fact that image and all subsequent frames are updated automatically without any extra manual work (frame generation, upload to wiki, updating wiki referencing it, etc.)

Solution to try and by-pass this (if this is really needed) is to automatically add ?unique-id-here to the URL param, I use this myself for some L2 websites I run to make sure the user doesn't get an outdated cached page when I update something.
Just my 2c.

Offline JohnKiel

  • Member
  • Posts: 15
  • United States
  • Liked: 10
  • Likes Given: 0
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1354 on: 06/04/2014 02:05 pm »
Google Spreadsheets are doing all the best to limit the Slashdot DOS effect by extensively caching data. For instance the spreadsheet is published at regular intervals but they can be even up to 5 minutes. I.e. the JSON feed from spreadsheet is often late, thus you cannot immediately get changes you do in spreadsheet via json feed.

Another "fix" Google is employing is caching any external data, i.e. when you pull the image with IMAGE function the request most probably passes the proxy, and unless there is a change in URL parameter to IMAGE function every time, you'll be geting cached image that Google fetched some time ago. This lets google limit its DOS effect on resources lined in the spreadsheet (i.e. it doesn't matter how many visitor spreadsheet gets).

Hope this explains delays in image update frequency if images are being proxied via external system. The cumulative delay here can be up to 10 minutes, that is not too bad, considering the fact that image and all subsequent frames are updated automatically without any extra manual work (frame generation, upload to wiki, updating wiki referencing it, etc.)

Yes, lots of caching and proxies involved with the image requests -- plenty of places for delays.  I believe the request currently goes through something like: Google Sheets -> Client browser -> Google's proxy -> My "proxy" script (spxi) -> IainCole's image generator (image server).

The "strange caching" issue I was running into appeared to be related to spxi timing out in some cases, and Google's proxy caching that error result, displaying no image in the sheet.  Now that it's on a faster and less restrictive server, that seems to be less of an issue.  Also, now that spxi has more bandwidth headroom, I've adjusted the Cache-control header so hopefully Google's proxy won't cache stale images for too long.

Once Google Sheets saves an MMB the json response seems to follow suit relatively quickly, however spxi will cache requests from the sheet for 10 seconds to avoid having to refresh it for every image request.  In addition, spxi will cache results from the image server, only requesting new image data if it detects that the MMBs have changed.

Unfortunately, changes to MMBs will require refreshing the sheet to see the change in the images.  Even if we append a hash of the MMBs to the sheet's image URL to trigger a new request on image change, the change in MMB likely won't be available to spxi until after it's saved and spxi's sheet cache expires.

In all, I think it's working well enough.

Offline JohnKiel

  • Member
  • Posts: 15
  • United States
  • Liked: 10
  • Likes Given: 0
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1355 on: 06/04/2014 02:12 pm »
Solution to try and by-pass this (if this is really needed) is to automatically add ?unique-id-here to the URL param, I use this myself for some L2 websites I run to make sure the user doesn't get an outdated cached page when I update something.
Just my 2c.

Yes, this would force an image refresh for every sheet load, and could be accomplished by appending NOW() to the URL, but I'd like to avoid it if possible.

Offline CuddlyRocket

Gwynne Shotwell is giving a speech at the moment to the Atlantic Council in Washington DC. She had a video about the accomplishments of SpaceX and it used a clip of the repaired video!

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 #1357 on: 06/04/2014 02:51 pm »
Solution to try and by-pass this (if this is really needed) is to automatically add ?unique-id-here to the URL param, I use this myself for some L2 websites I run to make sure the user doesn't get an outdated cached page when I update something.
Just my 2c.

Yes, this would force an image refresh for every sheet load, and could be accomplished by appending NOW() to the URL, but I'd like to avoid it if possible.

You could add a hash of the mmb to the URL.

Offline JohnKiel

  • Member
  • Posts: 15
  • United States
  • Liked: 10
  • Likes Given: 0
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1358 on: 06/04/2014 03:13 pm »
You could add a hash of the mmb to the URL.

The problem is that the MMBs used to create the hash in the URL may not match the MMBs the proxy script (spxi) sees when it pulls json for the sheet.  If a user changes the MMB, the sheet will request a new image immediately, but the sheet doesn't immediately save the changed MMB to Google's servers, so spxi will return images for the wrong MMB.

I suppose spxi could calculate a hash the same way as the spreadsheet (no simple native functions in google sheets for hashing, so we'd have to get creative), and if they don't match, loop for a bit, pulling new json for the sheet, trying its best to get updated data in the allotted amount of time;  But there's no guarantee it would ever return the correct image;  It could be some time before spxi actually sees the changed MMB.

That said, it's probably better than nothing.
« Last Edit: 06/04/2014 03:17 pm by JohnKiel »

Offline lgjy98d

  • Member
  • Posts: 10
  • Liked: 6
  • Likes Given: 0
Re: SpaceX Falcon 9 v1.1 CRS-3 Splashdown Video Repair Task Thread
« Reply #1359 on: 06/04/2014 04:11 pm »
You could add a hash of the mmb to the URL.

The problem is that the MMBs used to create the hash in the URL may not match the MMBs the proxy script (spxi) sees when it pulls json for the sheet.  If a user changes the MMB, the sheet will request a new image immediately, but the sheet doesn't immediately save the changed MMB to Google's servers, so spxi will return images for the wrong MMB.

I suppose spxi could calculate a hash the same way as the spreadsheet (no simple native functions in google sheets for hashing, so we'd have to get creative), and if they don't match, loop for a bit, pulling new json for the sheet, trying its best to get updated data in the allotted amount of time;  But there's no guarantee it would ever return the correct image;  It could be some time before spxi actually sees the changed MMB.

That said, it's probably better than nothing.
I'd say that Google Spreadsheet is no way replacement for online editor, but is good enough representation of state of the repair efforts that reduces amount of manual wiki page editing.

I.e. with Spreadsheets the workflow is:
* use data from spreadsheet cell (either manually copying data out and use in standalone ffmpeg, or automatically with online editor "Load Frame MMBs From Sheet" function)
* improve it until satisfied with the result
* paste updated MMBs back into spreadsheet

Frames images in the Spreadsheet should update automatically after 5-10 minutes, freeing one time to share accomplishments with this forum.

BTW, I've inserted widget embedding "latest" video of spacexlandingrestore channel in http://spacexlanding.wikispaces.com/raw_final_fixedMMB page. Should it be placed on frontpage?

Tags:
 

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