Quote from: arnezami on 05/12/2014 06:42 pmHi guys,I just noticed that there are no B-frames in the file. Only I-frames and P-frames.Quote./ffprobe try1.ts -show_frames > frames.txtNot sure yet what the implications are yet. Hopefully it will get easier that way.Regards,arnezamiThat is very fortunate happenstance. P frames will only have compound errors from any damage from the frames before them in the sequence. B frames would have compound errors from both before and after them in the sequence.
Hi guys,I just noticed that there are no B-frames in the file. Only I-frames and P-frames.Quote./ffprobe try1.ts -show_frames > frames.txtNot sure yet what the implications are yet. Hopefully it will get easier that way.Regards,arnezami
./ffprobe try1.ts -show_frames > frames.txt
Quote from: saliva_sweet on 05/12/2014 11:28 pmQuote from: mlindner on 05/12/2014 11:11 pmGoing to port my iframe8 changes to this new iframe8.How do you do that?Apparently the new and the old iframe8 are byte identical. Was hoping some of the issues would be fixed, but apparently not.
Quote from: mlindner on 05/12/2014 11:11 pmGoing to port my iframe8 changes to this new iframe8.How do you do that?
Going to port my iframe8 changes to this new iframe8.
Quote from: Shanuson on 05/12/2014 07:06 pmTo find out how many different TS-PIDs exists, I counted all different "0x47xxxx" appearances in raw_edit1.ts:This are all which occured 20 times or more:20 471be820 4733e821 470fe825 4703e963 47470374 47402081 474000269 4743e84968 471fff15016 4703e8I think the first 4 are permutations of the last ones by bitflips.4743e8 and 4703e8 have the same PID,When one checks where 474703 is found, one sees that the next byte is E8. So the first 47 is the last byte of a previous packet, and therefore 474703 is not part of a TS-header. So we end up with only 4 PIDs (13 bit long):0x0000, 0x0020, 0x03E8,0x1FFF Each PID has its own continuity counter, which should help deciding which packet is which. With some different flagbits we end with the following TS-headers:0x4740001W0x4740201X0x4703E81Y, 0x4703E83Y and 0x4743E83Y0x471FFF1Zwith the 4 different counters W,X,Y,ZFor completeness, I counted PIDs by absolute bit position in the raw.ts, here are the top 50:PID HEX COUNT 1000 x03E8 15592 -- Video 8191 x1FFF 5070 -- Null packet 0 x0000 84 32 x0020 755096 x13E8 49 -- 1 bit off from 10001001 x03E9 48 -- 1 bit off from 1000 904 x0388 40 -- 2 bit off from 10007144 x1BE8 30 -- 2 bit off from 1000 984 x03D8 29 -- 2 bit off from 10001003 x03EB 29 -- 1 bit off from 1000 616 x0268 283048 x0BE8 281512 x05E8 272000 x07D0 27 996 x03E4 261008 x03F0 261002 x03EA 254095 x0FFF 24 500 x01F4 231006 x03EE 234072 x0FE8 238190 x1FFE 23 808 x0328 191004 x03EC 19 992 x03E0 17 232 x00E8 16 488 x01E8 16 968 x03C8 161016 x03F8 162024 x07E8 166120 x17E8 15 872 x0368 14 936 x03A8 144000 x0FA0 14 680 x02A8 13 744 x02E8 131005 x03ED 132047 x07FF 132536 x09E8 128167 x1FE7 118189 x1FFD 117807 x1E7F 10 840 x0348 95119 x13FF 97423 x1CFF 98095 x1F9F 98127 x1FBF 98185 x1FF9 9 125 x007D 8 994 x03E2 8All 1650 are in the attached csv.I think your 4-PID theory is correct.
To find out how many different TS-PIDs exists, I counted all different "0x47xxxx" appearances in raw_edit1.ts:This are all which occured 20 times or more:20 471be820 4733e821 470fe825 4703e963 47470374 47402081 474000269 4743e84968 471fff15016 4703e8I think the first 4 are permutations of the last ones by bitflips.4743e8 and 4703e8 have the same PID,When one checks where 474703 is found, one sees that the next byte is E8. So the first 47 is the last byte of a previous packet, and therefore 474703 is not part of a TS-header. So we end up with only 4 PIDs (13 bit long):0x0000, 0x0020, 0x03E8,0x1FFF Each PID has its own continuity counter, which should help deciding which packet is which. With some different flagbits we end with the following TS-headers:0x4740001W0x4740201X0x4703E81Y, 0x4703E83Y and 0x4743E83Y0x471FFF1Zwith the 4 different counters W,X,Y,Z
PID HEX COUNT 1000 x03E8 15592 -- Video 8191 x1FFF 5070 -- Null packet 0 x0000 84 32 x0020 755096 x13E8 49 -- 1 bit off from 10001001 x03E9 48 -- 1 bit off from 1000 904 x0388 40 -- 2 bit off from 10007144 x1BE8 30 -- 2 bit off from 1000 984 x03D8 29 -- 2 bit off from 10001003 x03EB 29 -- 1 bit off from 1000 616 x0268 283048 x0BE8 281512 x05E8 272000 x07D0 27 996 x03E4 261008 x03F0 261002 x03EA 254095 x0FFF 24 500 x01F4 231006 x03EE 234072 x0FE8 238190 x1FFE 23 808 x0328 191004 x03EC 19 992 x03E0 17 232 x00E8 16 488 x01E8 16 968 x03C8 161016 x03F8 162024 x07E8 166120 x17E8 15 872 x0368 14 936 x03A8 144000 x0FA0 14 680 x02A8 13 744 x02E8 131005 x03ED 132047 x07FF 132536 x09E8 128167 x1FE7 118189 x1FFD 117807 x1E7F 10 840 x0348 95119 x13FF 97423 x1CFF 98095 x1F9F 98127 x1FBF 98185 x1FF9 9 125 x007D 8 994 x03E2 8
Offtopic: An updated version of the sequence from video I-Frames that I posed some pages ago, now with the legs clearly moving!
last four packets above are heavily corrupted - header is completelyunrecognizable, but they *must be* data packets, otherwise seq numbersdon't match: there is 8,9,a,b,c,d,e,f,0,1 sequence before them,and below the same sequence continues: 6,7,8,9,...So these four packets above *have to be* 2,3,4,5,and since seq numbers are counting independently for different PIDs,they must be data packets.
Careful with this assumption - the continuity counter/sequence number is just 4 bits. It is not special nor immune to noise than any other four bits in the header or data. Yes, including it in the match will increase the chances of getting the right PID, but it's not a magic bullet in itself.
As you see, every packet can be identified in this example, despitesome headers being shot to hell.
@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
Quote from: Adaptation on 05/13/2014 02:01 amQuote from: arnezami on 05/12/2014 06:42 pmHi guys,I just noticed that there are no B-frames in the file. Only I-frames and P-frames.Quote./ffprobe try1.ts -show_frames > frames.txtNot sure yet what the implications are yet. Hopefully it will get easier that way.Regards,arnezamiThat is very fortunate happenstance. P frames will only have compound errors from any damage from the frames before them in the sequence. B frames would have compound errors from both before and after them in the sequence. Not really that 'fortunate' - there are very few if any real time encoders of the sort that would be used here that use B-frames. They need to encode in near real time, which means basing frames on frames that haven't yet appeared doesn't really work. B-frames tends to work best when doing offline encoding. It does give a better compression ratio, but is more computationally expensive.
Quote from: theshadow27 on 05/13/2014 01:12 pmCareful with this assumption - the continuity counter/sequence number is just 4 bits. It is not special nor immune to noise than any other four bits in the header or data. Yes, including it in the match will increase the chances of getting the right PID, but it's not a magic bullet in itself.I don't think he's trying to say that, but rather merely pointing out that there's a second dimension from which the correct header can be derived, kind of like a macroblock referring to the one above or to the left. There's only four PIDs in the stream, and only two which occur frequently (0x03e8 and 0x1fff), so even with a completely trashed header like 0x5060F71, pulling these known quantities together you can figure out with a very high level of confidence that it's supposed to be 0x4703E814.Of course, it might be 0x34, not 0x14, if it's an adaptation packet, but there's also context available to figure that out too - such as if the next byte after the header is greater than 184 (0xB8) since that would mean the adaptation field is longer than the rest of the packet and so either that byte is wrong or the 0x34 should be 0x14.Now whether the likely completely trashed payload that goes with that completely trashed header will be of any use is another question, but at least we have the payload.Of course this doesn't help much if you go too far beyond 16 packets in either direction (3008 bytes), but I don't think we've seen that much contiguous unrecognizable data anywhere in the transport stream.
I am trying to recreate the full movie using the I-frames, a few "nice-looking" P-frames and fill the rest with empty P-frames. How can I convert a png into a P-frame? Or should I create the empty P-frames differently?For the I-frames, I use for example:ffmpeg -i frame_131.png -s 704x480 -aspect 22:15 -f image2 -r 44999/3003 frame131.mpg4-img
Quote from: JamesH on 05/13/2014 08:45 amQuote from: Adaptation on 05/13/2014 02:01 amQuote from: arnezami on 05/12/2014 06:42 pmHi guys,I just noticed that there are no B-frames in the file. Only I-frames and P-frames.Quote./ffprobe try1.ts -show_frames > frames.txtNot sure yet what the implications are yet. Hopefully it will get easier that way.Regards,arnezamiThat is very fortunate happenstance. P frames will only have compound errors from any damage from the frames before them in the sequence. B frames would have compound errors from both before and after them in the sequence. Not really that 'fortunate' - there are very few if any real time encoders of the sort that would be used here that use B-frames. They need to encode in near real time, which means basing frames on frames that haven't yet appeared doesn't really work. B-frames tends to work best when doing offline encoding. It does give a better compression ratio, but is more computationally expensive.I am trying to recreate the full movie using the I-frames, a few "nice-looking" P-frames and fill the rest with empty P-frames. How can I convert a png into a P-frame? Or should I create the empty P-frames differently?For the I-frames, I use for example:ffmpeg -i frame_131.png -s 704x480 -aspect 22:15 -f image2 -r 44999/3003 frame131.mpg4-img
Quote from: SwissCheese on 05/13/2014 05:28 pmQuote from: JamesH on 05/13/2014 08:45 amQuote from: Adaptation on 05/13/2014 02:01 amQuote from: arnezami on 05/12/2014 06:42 pmHi guys,I just noticed that there are no B-frames in the file. Only I-frames and P-frames.Quote./ffprobe try1.ts -show_frames > frames.txtNot sure yet what the implications are yet. Hopefully it will get easier that way.Regards,arnezamiThat is very fortunate happenstance. P frames will only have compound errors from any damage from the frames before them in the sequence. B frames would have compound errors from both before and after them in the sequence. Not really that 'fortunate' - there are very few if any real time encoders of the sort that would be used here that use B-frames. They need to encode in near real time, which means basing frames on frames that haven't yet appeared doesn't really work. B-frames tends to work best when doing offline encoding. It does give a better compression ratio, but is more computationally expensive.I am trying to recreate the full movie using the I-frames, a few "nice-looking" P-frames and fill the rest with empty P-frames. How can I convert a png into a P-frame? Or should I create the empty P-frames differently?For the I-frames, I use for example:ffmpeg -i frame_131.png -s 704x480 -aspect 22:15 -f image2 -r 44999/3003 frame131.mpg4-imgHow does it look with just the iframes? care to join us in the IRC channel?