Could pframes be used to help fine tune iframes? If you start with a high quality iframe like 6, and then look for spots where the pframes indicate no change, could you simply carry the block from the good iframe forward (or backward) or does the compression in the iframe make that impractical?
My thought was to deal with what I presume is low-hanging fruit: blocks with no or virtually no change from one iframe to the next.
My thought was to deal with what I presume is low-hanging fruit: blocks with no or virtually no change from one iframe to the next. If there's no updates, does that reduce the pframe coding length enough that it'd be more likely to have dodged corruption?
Do P-frame blocks within a given frame propagate like I-frame blocks? Or is it strictly a diff from the same MB?If we can create fake P-frames with no change, then fill in the data changes one at a time, we might make faster progress. But if they are interdependent you'd need to guess C/L data for each which could get annoying fast (and give people creative license to make the video into whatever)
The online editor 2 will also have an updated version of those iframes for those that are using that tool.
So I was building the latest FFMpeg for windows from here https://github.com/michaelni/FFmpeg/tree/spacexdebug1I managed to actually get it working (yay for me) but when I was testing it I found that the output for the same image with no -mmb applied was different to the previous version of ffmpeg I was using.OLD: http://i.imgur.com/CeHOIrB.pngNEW: http://i.imgur.com/sMInZkY.pngThe output seems a bit cleaner but I don't know why it's different, if anyone knows why this is, or more importantly if it's actually expected and OK, then I'll deploy it to the Online Editor to include the latest functionality.
The output seems a bit cleaner but I don't know why it's different, if anyone knows why this is, or more importantly if it's actually expected and OK, then I'll deploy it to the Online Editor to include the latest functionality.
Only I ran the new ffmpeg on the old images not the new ones :/Anyway it's deployed, if it's wrong (I can't tell) I can revert easily enough.
Quote from: arnezami on 05/11/2014 12:50 pm@Michael Niedermayer:I've been investigating the possibility of automatically setting all L1,L2,L3,L4,C1,C2 values for all macroblocks for a frame. Basicly inputting an mmb and letting a script detect "bad lines" in the picture. Moving from the right-bottom corner to the upper-top. I'm starting to believe (using some extra logging and some manual experimentation) that this might actually be possible. If it does this would improve the quality of the frames quite dramatically and would save a lot of manual work!However there is one thing that I find difficult to do myself. And I think you might be able to help us. Instead of using this kind of setting:15:14:-1:0:-40:0:0:0:20where I replace the current macroblock with a blank one and change the DC values. But what I really want to do is this:15:14:57217:0:-40:0:0:0:20In other words: I want to keep the macroblock with its (structured) data as much as I can (at the very least the blocks in it which are set to 0 above) but change only the DC "starting" values. So not blanken it, but modifying it so these DC-values make sure propogation to other blocks works the same as now with -1 (therefore fixing the color and intensity of following blocks) but I also keep the current blocks inside the current macroblock.Is something like that possible?Regards,arnezamiHi guys,I've created a new feature that implements the above.Simply put you can now do something like this:15:14:57217:0:-40:0:0:0:20This will keep the macroblock (so not nullify it) bit it will change the DC values. With this you can really fix the lum/chrom issues in the current I-frames. Should have a big effect. I hope.[edit] Forgot: it now also logs the 6 DC values for each macroblock. Which can come in handy in combination with this new feature.Also you can do this now:15:14:57217:0:0:0:0:0:0:015:14:57217:0:0:0:0:0:0:63What this does is change direction from where a DC prediction are coming/inherited from: left or top. For each 1-bit in this number it tells it to get the DC-prediction from the top for a specific DC (4 x lum, 2 x chrom). A 0-bit means left. The number consists of 6 bit (hence max is 63). So in effect a 0 is all left, a 63 is all top. I don't know yet whether this feature is going to be very useful but it can't hurt.I've attached the 3 source files that were changed. If somebody can check if it doesn't conflict with the existing branch (and maybe test it) and then push it to github, that would be great. Its these files btw:libavcodec/mpegvideo.hlibavcodec/mpeg4video.hlibavcodec/h263dec.c[edit] Fixed a bug: when using -2 it would get stuck in that mode. zip re-uploaded.I need some sleep now Regards,arnezamiPS. I was also trying to make a reverse-macroblock finder of sorts. So instead of telling its starting bitposition you would tell it its ending bitposition (which would usually be a starting bitposition of a mb you already have). But I ran into a lot of issues. Even when you try all possible DC-directions it still won't find the right starting position. Even when I fake the right DC values left to the block. I'm not sure why yet. Probably something I don't understand yet. This part of the code is in there but its commented out. It was also extremely error-log-heavy...
@Michael Niedermayer:I've been investigating the possibility of automatically setting all L1,L2,L3,L4,C1,C2 values for all macroblocks for a frame. Basicly inputting an mmb and letting a script detect "bad lines" in the picture. Moving from the right-bottom corner to the upper-top. I'm starting to believe (using some extra logging and some manual experimentation) that this might actually be possible. If it does this would improve the quality of the frames quite dramatically and would save a lot of manual work!However there is one thing that I find difficult to do myself. And I think you might be able to help us. Instead of using this kind of setting:15:14:-1:0:-40:0:0:0:20where I replace the current macroblock with a blank one and change the DC values. But what I really want to do is this:15:14:57217:0:-40:0:0:0:20In other words: I want to keep the macroblock with its (structured) data as much as I can (at the very least the blocks in it which are set to 0 above) but change only the DC "starting" values. So not blanken it, but modifying it so these DC-values make sure propogation to other blocks works the same as now with -1 (therefore fixing the color and intensity of following blocks) but I also keep the current blocks inside the current macroblock.Is something like that possible?Regards,arnezami
Which bits of the log do you need? There's already quite a bit there above the image.As for auto adding pos, currently, because of the way it's built, that would end up adding a bunch of effectively useless parts to the mmb (i.e. if you just click around and don't actually do anything) There might be a way round this, I'll have a think tomorrow when I get back from work =)
Quote from: IainCole on 05/14/2014 10:20 pmWhich bits of the log do you need? There's already quite a bit there above the image.As for auto adding pos, currently, because of the way it's built, that would end up adding a bunch of effectively useless parts to the mmb (i.e. if you just click around and don't actually do anything) There might be a way round this, I'll have a think tomorrow when I get back from work =)I meant the scrolling image interpretation log below the image - can you position that to show the relevant block as maybe the third line in the window? And actually now you point out the line above the image (which I had been looking for and never found for some reason), that has the current position of the block anyway so it's fairly easy to cut and paste across.