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
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
Quote from: arnezami on 05/03/2014 09:17 pmHi 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,arnezamiThat 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.
./ffmpeg -i coerced.ts -vcodec copy -an -f image2 frame%d.mpg4-img
This would split the mpeg-ts into 1 file per frame, each containing just the mpeg4-es data, no mpeg-ts anymore
In your current directory there is now a new ffmpeg fileYou 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 macroblocks2) "-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.pngIn 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!
Hi Guys,iframe2 is starting to become alive! 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?
Quote from: mlindner on 05/04/2014 09:35 pmAwesome!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 Hihi this is fun! [edit] Forgot it again. I did: "-mmb 0:0:10020" here.
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
Ive put arnezamis changes on github:(with some simplifications to the implementation, and very basic docs from mlindner)should be easier to download that wayhttps://github.com/michaelni/FFmpeg/tree/spacexdebug1
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