About the Iframes, i was thinking that manual moving the macroblocks around will be difficult if you don't have a lot of reference (i.e. if there aren't many features on the block).
Quote from: Axiom on 05/12/2014 06:10 amAbout the Iframes, i was thinking that manual moving the macroblocks around will be difficult if you don't have a lot of reference (i.e. if there aren't many features on the block).As it turns out, it appears that the dirty splash on liftoff has been a great help, as there are lots of small dirty smudges in each frame which provide reference features.
A version with the dirt spots numbered for better reference in conversationEdit: Added dirt group 14
Quote from: cscott on 05/12/2014 05:19 pmQuote from: Axiom on 05/12/2014 06:10 amAbout the Iframes, i was thinking that manual moving the macroblocks around will be difficult if you don't have a lot of reference (i.e. if there aren't many features on the block).As it turns out, it appears that the dirty splash on liftoff has been a great help, as there are lots of small dirty smudges in each frame which provide reference features.Yes, see my earlier post with an image annotated with 14 dirt spots that clear are on the lens. Quote from: Jakusb on 05/10/2014 11:51 pmA version with the dirt spots numbered for better reference in conversationEdit: Added dirt group 14
Hi guys,I have a bit of a mystery going on and it's holding me back from doing great stuff. Hopefully somebody else has an idea what is going on.This is essentially about how luminance/chrominance (errors) propagate. From what I understood so far each (macro)block propagates to its right (macro)block and to its bottom (macro)block. Luminance does it on a block (8x8pixel) basis while chrominance does it on a macroblock basis. So if you set macroblock 0,0 to "more red" the entire picture becomes that much "more red". Right?Now here is my mystery example.Take iframe 12 (try1) and enter 0:0:-1,13:24:72730 as mmb. It shows the bottom part of the picture and it looks quite nice.Now enter 0:0:-1,12:24:72687 and suddenly you see a luminosity error appearing far from the block we just changed. How is this possible??I suspect this has to do with the fact that the lower-right block of 24:26 is getting different input from above or left, but I don't understand why it could be so different from before. Maybe some kind of dc-clipping? (but there is no error log of that I think) Is this block reading the bits differently because it has different input? Because I always thought that the reading/meaning of the bits was not determined by the input.I'm confused by this.Regards,arnezami
./ffprobe try1.ts -show_frames > frames.txt
So this confused me for a while too. First off a block does not propagate to the left AND right. It is better to say that a given block propagates from EITHER the left OR the top block. Further, this is not defined in the file specifically. It is defined by comparing the block above, the block to the left, AND the block to the upper left. Based on the DC (brightness/color) of the blocks in these directions it PICKs which block to propagate from. Because of this when you adjust a value you can cause a given block to swap which block it inherits from.
Quote from: arnezami on 05/12/2014 08:52 amQuote from: wronkiew on 05/12/2014 07:16 amI've seen this too. Either the offending block is messed up in some way that propagates the error, or MPEG behaves badly when values are clipped. The problem seems to be worse on frames where the top row is missing. I attached an image that shows the path from the bad block to where it gets noticeably bad.Yeah. I'm starting to realize that it is even harder than I thought it would be. I wanted to create a "clean enviroment" for checking bad block propagation by starting at the end and working backward therefore avoiding the issue of having propagation from above and left.But this won't work if block propagation below and to the right is different when adding more blocks to the left and above.Hmmm. A rethink is required here.Thanks for that diff!Regards,arnezamiQuick thought from a quiet computer Geek in the audience.... Can Space X provide you with a good 30 sec chunk of video from the same setup so you can see what good video is supposed to look like? That would get you ground truth as to formatting etc. It would also give you the ability to selectively damage the bit stream to better understand propagation related errors.
Quote from: wronkiew on 05/12/2014 07:16 amI've seen this too. Either the offending block is messed up in some way that propagates the error, or MPEG behaves badly when values are clipped. The problem seems to be worse on frames where the top row is missing. I attached an image that shows the path from the bad block to where it gets noticeably bad.Yeah. I'm starting to realize that it is even harder than I thought it would be. I wanted to create a "clean enviroment" for checking bad block propagation by starting at the end and working backward therefore avoiding the issue of having propagation from above and left.But this won't work if block propagation below and to the right is different when adding more blocks to the left and above.Hmmm. A rethink is required here.Thanks for that diff!Regards,arnezami
I've seen this too. Either the offending block is messed up in some way that propagates the error, or MPEG behaves badly when values are clipped. The problem seems to be worse on frames where the top row is missing. I attached an image that shows the path from the bad block to where it gets noticeably bad.
Quote from: gospacex on 05/11/2014 04:46 pmParsing raw.ts using info from http://en.wikipedia.org/wiki/MPEG_transport_streamThe file consists of 188-byte ts-packets.1st byte is always 47.2 next bytes are 000<packetid13bits>, and apparentlythey are always 03e8 for non-null ts-packets and 1fff for null ts-packets.there are more than 2 PID values in the ts packets/ file
Parsing raw.ts using info from http://en.wikipedia.org/wiki/MPEG_transport_streamThe file consists of 188-byte ts-packets.1st byte is always 47.2 next bytes are 000<packetid13bits>, and apparentlythey are always 03e8 for non-null ts-packets and 1fff for null ts-packets.
Offtopic: An updated version of the sequence from video I-Frames that I posed some pages ago, now with the legs clearly moving!
Ok, I am done with my work on the headersattached you find a raw_edit1.ts where only the 15 I-Frame headers are changed (plus a few '47' bytes maybe), Also the one 188 byte block is reshifted by 4 bits to align it.The last XX XX was part of vbv_occupancy (1 marker bit and the frist 7 of the latter half of vbv_occupancy)According to michaelni, the actually value is not needed to extrace I-frames.CheersShanuson
Quote from: Shanuson on 05/12/2014 03:06 pmOk, I am done with my work on the headersattached you find a raw_edit1.ts where only the 15 I-Frame headers are changed (plus a few '47' bytes maybe), Also the one 188 byte block is reshifted by 4 bits to align it.The last XX XX was part of vbv_occupancy (1 marker bit and the frist 7 of the latter half of vbv_occupancy)According to michaelni, the actually value is not needed to extrace I-frames.CheersShanusonI tried it, some iframes appear to have extra data and are clearer, others are worse. iframe8 is missing, and I'm not sure if there are new iframes or not. Several of the frames have apparently significantly less errors though.
Quote from: Jakusb on 05/12/2014 06:21 pmQuote from: cscott on 05/12/2014 05:19 pmQuote from: Axiom on 05/12/2014 06:10 amAbout the Iframes, i was thinking that manual moving the macroblocks around will be difficult if you don't have a lot of reference (i.e. if there aren't many features on the block).As it turns out, it appears that the dirty splash on liftoff has been a great help, as there are lots of small dirty smudges in each frame which provide reference features.Yes, see my earlier post with an image annotated with 14 dirt spots that clear are on the lens. Quote from: Jakusb on 05/10/2014 11:51 pmA version with the dirt spots numbered for better reference in conversationEdit: Added dirt group 14Dont forget the one that is overlapping with part of the right leg. (wiki IF 5 shows a complete right leg)
Quote from: mlindner on 05/12/2014 09:11 pmQuote from: Shanuson on 05/12/2014 03:06 pmOk, I am done with my work on the headersattached you find a raw_edit1.ts where only the 15 I-Frame headers are changed (plus a few '47' bytes maybe), Also the one 188 byte block is reshifted by 4 bits to align it.The last XX XX was part of vbv_occupancy (1 marker bit and the frist 7 of the latter half of vbv_occupancy)According to michaelni, the actually value is not needed to extrace I-frames.CheersShanusonI tried it, some iframes appear to have extra data and are clearer, others are worse. iframe8 is missing, and I'm not sure if there are new iframes or not. Several of the frames have apparently significantly less errors though.Any idea yet how to proceed?Is it useful to add them to the online editor v2?I am getting pretty curious to see this potential new or improved data in actual images...
As soon as the work finishes on recovering the information, I guess some post processing can be done, namely noise filtering/smothering and some morphing to create intermediate frames!
Quote from: IRobot on 05/12/2014 09:19 pmAs soon as the work finishes on recovering the information, I guess some post processing can be done, namely noise filtering/smothering and some morphing to create intermediate frames!Already working on it. Want to help?
To find out how many different TS-PIDs exists, I counted all different "0x47xxxx" appearances in
This is even worse because this prediction direction even determines the scan order through the DCT table. So causing a block to swap which block it inherits from can cause the DCT scan order to become screwed up resulting in the pixels in the block to be transposed (mirrored and flipped vertically).
If only we could somehow get the legs in Iframe 4 resolved...I assume they should be just opened and slightly away from the stage. Or not
Quote from: wronkiew on 05/12/2014 09:56 pmQuote from: IRobot on 05/12/2014 09:19 pmAs soon as the work finishes on recovering the information, I guess some post processing can be done, namely noise filtering/smothering and some morphing to create intermediate frames!Already working on it. Want to help?A lot of work still needs to be done on iframes before that can be done.