Argh. I have some MPEG-2/MPEG-4 experience, and had a go at fixing the file too. Sadly, it's no better than the version SpaceX posted, in terms of useable frames and recognizable objects in the frame. I think there's just too much lost data (and the I-frames made up too much of the missing data) to get much back. But I'd love to be wrong!The order and detail of my efforts was: * Identify discontinuities in the file -- where 0x47 sync bytes jumped offset. Unlike the SpaceX file (which apparently removed data), I added 0xFFs to pad the data to align the next identifiable packet to a 188 byte multiple. * Identify the different PIDs in the file. There were the usual suspects: 0x0000 (PAT: Program Allocation Table), 0x0020 (PMT: Program Map Table referenced by the PAT), 0x03e8 (PES video stream, referenced by the PMT), and 0x1fff (padding packets to align the transport stream bit clock with the Program Clock Reference). * Identify video PES streams by start code and ID (0x000001e0). I created a template packet that looked like this (hex): 47 43 e8 3_ 07 10 00 __ __ __ __ __ 00 00 01 E0 00 00 81 80 07 I tested each packet against this template, computing the Hamming distance and printing out packets below 23 bits difference. This showed me all the likely PES headers, which I could examine and repair. The five "__" bytes contain the Program Clock Reference value for that point in the transport stream. The PCR advances at 90kHz, with a 300-count fraction/extension that advances at 27MHz. In this file, the PCR advances at multiples of 6006 (decimal) or 66.733 milliseconds. I managed to recover 276 PCR values, and the time stamps span 318 frames (at 6006 PCR counts per frame) or 21.221 seconds. For PCR values that were not multiples of 6006, but were clearly close or off by one or two flipped bits, I flipped them back (hex file editor) to get the interval right. * I also normalized the Presentation Time Stamp (PTS) values, which appear to lag the PCR of the packet by exactly 10000 counts (111.111 milliseconds). I used the PCR and PTS intervals to cross-check values (looking for multiples of 6006 in the PCR and a difference of +10000 between the PCR and PTS) and fixed anything that was out of sorts. * I identified all transport stream packets as being either PAT, PMT, video, or padding, and coerced bit errors in the header to have the correct sync byte (0x47) and flags (turning off the transport stream error indicator, transport priority, and scrambling bits. I used the continuity counter value to tell whether successive packets might actually be the same PID (usually 0x3e8, video). Based on all this information, I coerced PIDs to the most likely value, and turned any obviously junk packets into padding (null) packets. I fixed up the continuity counter on the packets of each PID so they were incrementing without gaps. * I then dug into the MPEG-4 visual object sequence and visual object structures. I saw damage on some of the bits that described the dimensions of the image frame, which were causing VLC and ffmpeg some consternation. So I normalized those.At this point, I ran out of time. I have a lot of other projects I should be working on. So I share all this in hopes others can build on this, or point out a fatal flaw in my approach and improve on it.Here's the file I've hand-edited to correct all the PCR and PTS timing issues I could find:edited.tsAnd here's that file run through a script to coerce the transport stream headers into more sensible values (which might or might not actually be an improvement):coerced.tsGood luck! And I hope SpaceX gets better weather and position for their RF link on the next launch. Being a software radio nerd, I can appreciate the challenges they face catching several megabits of data from an object they don't want to be too close to when it comes down. - Jared
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 frameThe first is based on raw.ts, the second is based on the coerced.ts file from Jarred which was posted herehttps://ffmpeg.org/~michael/space-x-video/raw.ts-nomc-ignoreerr.mkvandhttps://ffmpeg.org/~michael/space-x-video/Jared-coerced.ts-nomc-ignoreerr.mkv
Hope we can work together to figure this out. I like your approach though. Currently I'm focusing on the I-frames and altering the decoder to give me more information about what is wrong with certain (macro)blocks. But I've seen the decoder source code for the first time today, while you may know it by heart.
Nice work. The following frames from the raw.ts where quite interesting because they clearly show the time stamp in the lower left corner. There are a lot frames with clearly visible last numbers of time stamps.MECO was around 19:28:19landing video started at 19:35:03 - 1s or solanding video ended at 19:35:19In every frame there is 19:35 in the lower left corner with the exact same pixels. For scam-analysis a known plain text would help for sure
https://ffmpeg.org/~michael/space-x-video/raw.ts-tunedec.mkvhttps://ffmpeg.org/~michael/space-x-video/Jared-edited.ts-tunedec.mkvhttps://ffmpeg.org/~michael/space-x-video/Jared-coerced.ts-tunedec.mkv
Won't play for me with either Windows Media Player or DivX. What software can I use to play it?
Quote from: michaelni on 05/02/2014 03:59 pmhttps://ffmpeg.org/~michael/space-x-video/raw.ts-tunedec.mkvhttps://ffmpeg.org/~michael/space-x-video/Jared-edited.ts-tunedec.mkvhttps://ffmpeg.org/~michael/space-x-video/Jared-coerced.ts-tunedec.mkvWon't play for me with either Windows Media Player or DivX. What software can I use to play it?
Quote from: Marams on 05/02/2014 08:02 pmNice work. The following frames from the raw.ts where quite interesting because they clearly show the time stamp in the lower left corner. There are a lot frames with clearly visible last numbers of time stamps.MECO was around 19:28:19landing video started at 19:35:03 - 1s or solanding video ended at 19:35:19In every frame there is 19:35 in the lower left corner with the exact same pixels. For scam-analysis a known plain text would help for sure Great find!!
Xine on a linux box works as well. I believe you can download a version of xine for Windows ...
Just download VLC player. It saves downloading all them dodgy codec packs.If VLC can't play it then forget it...