Quote from: moralec on 05/15/2014 10:07 pmLooks amazing. But what .ts are you using? I´m getting something slightly differnt on edit8Edit5. The last one in the online editor. It's a useful tool. It was the same in edit5 and try1 so I assumed it would be the same in edit8 too. I'll check edit8.Edit: I got the same thing from edit8. The one posted here: http://forum.nasaspaceflight.com/index.php?topic=34597.msg1198706#msg1198706
Looks amazing. But what .ts are you using? I´m getting something slightly differnt on edit8
Am I the only one thinking some of the frames currently look very Turneresque?!
I'm getting a bulish version on the online editor... no idea why
The updated version displaying the MB type and the motion vectors is in attachment, it was based on the latest version of Arnezami. I hope it does not introduce any bug I also tried to rebuild frames +/- "as the encoder does" with some basic matlab code, the problem is that many P-frames are highly corrupted... but it worked not too badly for frames 169 (I-frame), 171 and 172.I don't know if it's a good idea to go this way, but I was stuck trying to repair P-frames: as soon as I touched them (tried to correct them with matlab), they would not be used during the video encoding (even when simply reading and rewriting a frame, without changing anything).Btw some P-frames like 171 or 176 have issues in their first data bytes or at the end of the header (bytes 4/5/6), I don't really know, and are not converted to PNG, a copy/paste of these bytes from a valid frame solves the issue.
...I was stuck trying to repair P-frames:...
The only big problem is that the mmb will get quite big. We would need some kind of script that assembles all the mmb's of the frames and calls ffmpeg with that long mmb.
Quote from: SwissCheese on 05/17/2014 11:34 amThe updated version displaying the MB type and the motion vectors is in attachment, it was based on the latest version of Arnezami. I hope it does not introduce any bug I also tried to rebuild frames +/- "as the encoder does" with some basic matlab code, the problem is that many P-frames are highly corrupted... but it worked not too badly for frames 169 (I-frame), 171 and 172.I don't know if it's a good idea to go this way, but I was stuck trying to repair P-frames: as soon as I touched them (tried to correct them with matlab), they would not be used during the video encoding (even when simply reading and rewriting a frame, without changing anything).Btw some P-frames like 171 or 176 have issues in their first data bytes or at the end of the header (bytes 4/5/6), I don't really know, and are not converted to PNG, a copy/paste of these bytes from a valid frame solves the issue.Cool! And interesting. The engine is just igniting! Regarding the P-frames: I think it would be a good idea to extend the -mmb syntax with a framenumber.So you would have something like this:-mmb FRAME168:16:04:37259,23:02:73229=FRAME169:01:01:2342,34:02:-1 etc.Something like that.That way you can give it either the complete .ts or a .ts that starts with an I-frame until the P-frame you are actually working on. It would run through all the frames changing their macroblocks. And the P-frame you're interested in will inherit all the fixes (and errors of course) that have preceded it.The only big problem is that the mmb will get quite big. We would need some kind of script that assembles all the mmb's of the frames and calls ffmpeg with that long mmb.Good idea?Regards,arnezami
-mmb FRAME0:16:04:37259,23:02:73229=FRAME1:01:01:2342,34:02:-1
Quote from: SwissCheese on 05/17/2014 11:34 amThe updated version displaying the MB type and the motion vectors is in attachment, it was based on the latest version of Arnezami. I hope it does not introduce any bug I also tried to rebuild frames +/- "as the encoder does" with some basic matlab code, the problem is that many P-frames are highly corrupted... but it worked not too badly for frames 169 (I-frame), 171 and 172.I don't know if it's a good idea to go this way, but I was stuck trying to repair P-frames: as soon as I touched them (tried to correct them with matlab), they would not be used during the video encoding (even when simply reading and rewriting a frame, without changing anything).Btw some P-frames like 171 or 176 have issues in their first data bytes or at the end of the header (bytes 4/5/6), I don't really know, and are not converted to PNG, a copy/paste of these bytes from a valid frame solves the issue.Cool! And interesting. The engine is just igniting!
Quote from: arnezami on 05/17/2014 12:01 pmQuote from: SwissCheese on 05/17/2014 11:34 amThe updated version displaying the MB type and the motion vectors is in attachment, it was based on the latest version of Arnezami. I hope it does not introduce any bug I also tried to rebuild frames +/- "as the encoder does" with some basic matlab code, the problem is that many P-frames are highly corrupted... but it worked not too badly for frames 169 (I-frame), 171 and 172.I don't know if it's a good idea to go this way, but I was stuck trying to repair P-frames: as soon as I touched them (tried to correct them with matlab), they would not be used during the video encoding (even when simply reading and rewriting a frame, without changing anything).Btw some P-frames like 171 or 176 have issues in their first data bytes or at the end of the header (bytes 4/5/6), I don't really know, and are not converted to PNG, a copy/paste of these bytes from a valid frame solves the issue.Cool! And interesting. The engine is just igniting! Regarding the P-frames: I think it would be a good idea to extend the -mmb syntax with a framenumber.So you would have something like this:-mmb FRAME168:16:04:37259,23:02:73229=FRAME169:01:01:2342,34:02:-1 etc.Something like that.That way you can give it either the complete .ts or a .ts that starts with an I-frame until the P-frame you are actually working on. It would run through all the frames changing their macroblocks. And the P-frame you're interested in will inherit all the fixes (and errors of course) that have preceded it.The only big problem is that the mmb will get quite big. We would need some kind of script that assembles all the mmb's of the frames and calls ffmpeg with that long mmb.Good idea?Regards,arnezamiHi guys,I've extended the mmb-syntax so it can now handle multiple frames at the time. See the above quote.The syntax is: Quote-mmb FRAME0:16:04:37259,23:02:73229=FRAME1:01:01:2342,34:02:-1Note the '=' sign!The old syntax still works on files with one frame in it.I've also incorporated SwissCheese' logging (and changed back the && into & )I haven't actually tested it with a file with multiple frames in it. But it *should* work. Let me know![edit] Important: the frame numbers should be the frame numbers in your file. If you use a file with say 3 frames in it their frame numbers should be 0, 1 and 2. So not 168, 169, 170 in that case. Should I add the frame number in the log too? Not sure.Regards,arnezami
Quote from: arnezami on 05/17/2014 12:01 pmQuote from: SwissCheese on 05/17/2014 11:34 amThe updated version displaying the MB type and the motion vectors is in attachment, it was based on the latest version of Arnezami. I hope it does not introduce any bug I also tried to rebuild frames +/- "as the encoder does" with some basic matlab code, the problem is that many P-frames are highly corrupted... but it worked not too badly for frames 169 (I-frame), 171 and 172.I don't know if it's a good idea to go this way, but I was stuck trying to repair P-frames: as soon as I touched them (tried to correct them with matlab), they would not be used during the video encoding (even when simply reading and rewriting a frame, without changing anything).Btw some P-frames like 171 or 176 have issues in their first data bytes or at the end of the header (bytes 4/5/6), I don't really know, and are not converted to PNG, a copy/paste of these bytes from a valid frame solves the issue.Cool! And interesting. The engine is just igniting! Inspiring work SwissCheese! this is Amazing! Yet another piece of the puzzle (engine ignition) has been uncovered.The idea of using matlab sounds good to me. I think we should accept that some of the frames of the video are beyond recovery. Considering this, a good approach could be to be to deconstruct the video frame by frame recovering as many usable frames as possible, and then reconstruct it back again keeping only the good frames, to then interpolate (like the guys on the curiosity landing did) in order to obtain a decent dynamic video.My guess is the p-frames immediately after a fixed iframe will be the best looking, as only some macro blocks should have changed..... but as the sequence continues moving forward, the subsequent frames will start to accumulate errors and they will look worse and worse. That is, naturally, until the video gets to the next iframe that has been manually fixed.For how many frames did you apply the process? Could you the same technique for the frames after of after 72 or 209 (which could show leg deployment and touchdown)? do you thing my hyphotesis of constant deterioration will hold?Edit: On other news, I tried to apply your very long mmb code for frame 92 (the frame formally known as iframe # 5) to the newest version (the one obtained from edit5.ts) and unfortunately is not working anymore. AS you where the main author, maybe you will be able to figure out what has changed. I'm guessing a small adjustment should be sufficient to get that frame visible again! It could also be a problem on how the code was pasted in the forum: I believe this happened to Saliva_sweet