I agree, that is really quite incredible! Has anyone looked yet at the motion vectors in the P-frames? It looks like there's some improvement to be had there still.
Great progress guys!! Almost all frames have now been fixed...Just to check: Is anybody working on Parts 1 and 2? Those are the only ones that remain untouched.... It looks like we are getting closer to the limits of the MMB approach. Any new ideas on how to continue moving forward? I'm guessing that princess and others are still working on the triple bit flips... any help you guys need with that? Or what other things we should begin consider? Traditional Image correction? Interpolation of frames?By the way, looking at the latest video I think we are going to need to add the clock fixes for frames 168-180. In the latest you tube version, the clock stays at 19:35:8 for two seconds and then jumps to 19:35:10 (Check from 0:07 to 0:10 in the video)
Yes, the the clock **could** be completely "fixed" to be visually smoothed. Be aware that would introduce the possibility of small errors. When all is said and done, I support @Wronkiew's judgement on this issue.
An argument could be made for using the clock in the TS header (@princess mentioned it, I think) to map frames to a timestamp. That TS counter is not an extrapolation; it is hard evidence - just not from visual MB information.
Quote from: mhenderson on 06/17/2014 04:59 pmYes, the the clock **could** be completely "fixed" to be visually smoothed. Be aware that would introduce the possibility of small errors. When all is said and done, I support @Wronkiew's judgement on this issue.This is another test case for automatic triple flip detection. I wish I had more time to work on this myself! But here we have a fairly good idea of exactly what the clock should look like, so it should be possible to turn loose an automatic tool that looked for the best set of triple flips that gives the expected output.
An argument could be made for using the clock in the TS header (@princess mentioned it, I think) to map frames to a timestamp. That TS counter is not an extrapolation; it is hard evidence - just not from visual MB information.Yes, the the clock **could** be completely "fixed" to be visually smoothed. Be aware that would introduce the possibility of small errors. When all is said and done, I support @Wronkiew's judgement on this issue.
mmb autoconversion works now for i frames that have been converted to p frames. Conversion can introduce problems occasionally e.g. in iframe 81 a string of blocks looked good in the original, but bad after conversion, my guess is they may contain an imperceptible error and therefore don't convert correctly, this in turn caused dc issues. As proof of concept I submit iframe 281 converted to p frame. The method worked well with little effort for this one because the blank region was already set to -2. Blocks set to -3 will behave like -2 blocks for the subsequent mbs i.e. they provide no inheritance which is both good and bad - they shouldn't cause propagating errors, but the dc's for subsequent blocks would need to be added manually. This would be much easier in the online editor.IainCole, would it be possible to put these frames into the online editor so others could take a crack at setting blocks to -3 and filling the blanks in iframes? Lot of dc work is needed for this.
You want me to do what?
Quote from: IainCole on 06/17/2014 08:43 pmYou want me to do what?Add iframes converted to pframes to the online editor so mmbs for them could be better edited. They are mpg4-img files, which I would provide. Not sure how your setup works currently.edit: They should probably be separate from the main final_fixed.ts frames like there used to be several selecable ts versions earlier. Would that be possible?
The p-frame editor was build to handle only 1 TS set, but I can add alternative frames into the frameset
mmb autoconversion works now for i frames that have been converted to p frames. Conversion can introduce problems occasionally e.g. in iframe 81 a string of blocks looked good in the original, but bad after conversion, my guess is they may contain an imperceptible error and therefore don't convert correctly, this in turn caused dc issues. As proof of concept I submit iframe 281 converted to p frame. The method worked well with little effort for this one because the blank region was already set to -2. Blocks set to -3 will behave like -2 blocks for the subsequent mbs i.e. they provide no inheritance which is both good and bad - they shouldn't cause propagating errors, but the dc's for subsequent blocks would need to be added manually. This would be much easier in the online editor.IainCole, would it be possible to put these frames into the online editor so others could take a crack at setting blocks to -3 and filling the blanks in iframes? Lot of dc work is needed for this. Edit: gif not animating, so zip it must be.Edit2: I'll also add a png of the actual frame 281.
Quote from: saliva_sweet on 06/17/2014 08:40 pmmmb autoconversion works now for i frames that have been converted to p frames. Conversion can introduce problems occasionally e.g. in iframe 81 a string of blocks looked good in the original, but bad after conversion, my guess is they may contain an imperceptible error and therefore don't convert correctly, this in turn caused dc issues. As proof of concept I submit iframe 281 converted to p frame. The method worked well with little effort for this one because the blank region was already set to -2. Blocks set to -3 will behave like -2 blocks for the subsequent mbs i.e. they provide no inheritance which is both good and bad - they shouldn't cause propagating errors, but the dc's for subsequent blocks would need to be added manually. This would be much easier in the online editor.IainCole, would it be possible to put these frames into the online editor so others could take a crack at setting blocks to -3 and filling the blanks in iframes? Lot of dc work is needed for this. Edit: gif not animating, so zip it must be.Edit2: I'll also add a png of the actual frame 281.Could you explain what you did with more details? Did you modify the program (h263dec.c)? I don't really understand...
And what about the frames following the one you converted? Do they also inherit the data?