<snip>The next block of XXs is part of the Presentation Time Stamp PTShow to get the PTS is explained quite well here: http://dvd.sourceforge.net/dvdinfo/pes-hdr.htmlPTS: 21 01 xx xx xx. We can now decode the PTS of the good frames and define the PTS of the messed up ones.It is late again, my bed is calling. I will calculate the PTS tomorrow, also will work out that last xx xx.Here are the raw 5 byte PTS of the frames:IF00: 99 31 59 14 6C IF01: 21 01 61 23 EDIF02: 21 01 67 CE 5DIF03: 21 01 6F 78 CDIF04: 21 01 77 23 3D IF05: 21 01 7D CD ADIF06: 21 01 85 78 1DIF07: 21 01 8D 22 8DIF08: 21 01 93 CC FDIF09: 21 01 9B 77 6DIF10: 21 01 A3 21 DDIF11: 21 01 A9 CC 4DIF12: 21 01 B1 76 BDIF13: 21 01 B9 21 2DIF14: 21 01 BF CB 9DCheersShanuson
Ah ok. I think that can happen too: when the first macroblock thinks it has seen the 4 blocks but those stop-bits weren't all real stop-bits the next macroblock will pick-up the blocks from the previous macroblock. But then you would also expect some color-trouble because those would also be interpreted wrong I guess. I think Michael Niedermayer knows this better though.
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.
Yes. There were 5 times 56 bytes missing in the raw.ts. Very weird indeed.This was fixed (among other things) in the coerced.ts. I am not sure if it was fixed in the try1.ts.
Quote from: arnezami on 05/11/2014 05:12 pmYes. There were 5 times 56 bytes missing in the raw.ts. Very weird indeed.This was fixed (among other things) in the coerced.ts. I am not sure if it was fixed in the try1.ts.IIRC edited, coerced and try1 all had the 188byte packets aligned (except the 4bit thing)
Quote from: michaelni on 05/12/2014 12:43 amQuote from: arnezami on 05/11/2014 05:12 pmYes. There were 5 times 56 bytes missing in the raw.ts. Very weird indeed.This was fixed (among other things) in the coerced.ts. I am not sure if it was fixed in the try1.ts.IIRC edited, coerced and try1 all had the 188byte packets aligned (except the 4bit thing)Aligning is easy, and possibly not that useful.For one, it changes file offsets of ts-packets, making it harder for us to refer to the packets in speech.E.g. "packet at offset XYZ needs its header fixed this way" - offset XYZ in *which .ts file*?The hard part is repairing damaged headers, and subsequently, data.
cat raw.ts | tsalign | tsfix > fixed.ts
Wooow! I didn't realize this at first. But we have Michael Niedermayer in the house! One of the creators of ffmpeg itself.
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 because 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 I 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
Quote from: gospacex on 05/12/2014 12:53 amQuote from: michaelni on 05/12/2014 12:43 amQuote from: arnezami on 05/11/2014 05:12 pmYes. There were 5 times 56 bytes missing in the raw.ts. Very weird indeed.This was fixed (among other things) in the coerced.ts. I am not sure if it was fixed in the try1.ts.IIRC edited, coerced and try1 all had the 188byte packets aligned (except the 4bit thing)Aligning is easy, and possibly not that useful.For one, it changes file offsets of ts-packets, making it harder for us to refer to the packets in speech.E.g. "packet at offset XYZ needs its header fixed this way" - offset XYZ in *which .ts file*?The hard part is repairing damaged headers, and subsequently, data.Aligning is easy, but also critical. There is no way to decode misaligned data. Luckily for us, michaelni has already written code to do this automatically (tsalign.c).Referring to packet header locations is not that useful, as they are easily automatically repaired by the other program michaelni has written (tsfix.c). It's as simple as cat raw.ts | tsalign | tsfix > fixed.tsThe only hard part is repairing the data.
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: 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
Unfortunately, it is not that easy to automaticallyfix headers without damaging data even more.I think it's better to have the corrections explained (so that they can be cross-checked and tuned).For example, take edited.ts and coerced.ts. edited.ts has this sequence of packets:…Those six packets with headers has been auto-fixed to "nulls", subsequent packets have their seq fields renumbered. This destroyed some data which was there.We need to be more careful than that.
I encourage interested people to uncomment last line, run the program,look at raw.hex.diff, and suggest improvements to fix_data_packets() logic.