From: Jonathan K. <jko...@gr...> - 2003-03-08 02:31:20
|
> A basic problem here is that MPEG2 isn't "frame" based, but GOP (Group of > Pictures) based. If I understand things right, you get one full frame and a > bunch of deltas relative to the last delta. (I *think* we get one GOP per > DMA, but I could be wrong). > > BTW, there are two types of deltas: forward and reverse. If you don't have > the rev deltas, then going backwards becomes computationally expensive. > > I don't think that ioctl is supportable with the MPEG2 streams (perhaps the > MPEG1 stream type). MPEG2 is actually sort of frame based. You get a sync frame (I frame) to start each GOP. You then get P frames (deltas from the GOP's I frame) and B frames (deltas from the GOP's I frame and the most recently encountered P frame) to round out the rest of the GOP. In display order, they're drawn IBBPBBPBBP. In encoded order, however, they appear as IPBBPBBPBB (you have to have the future P frame to be able to calculate the B's reverse delta). The card most likely gives 32k or 64k chunks per DMA (that's how all the cards I've used hand out the data). Also, as a general rule, GOP's are 15 frames long, which (with NTSC), gives 2 GOPs per second. If you were receiving a GOP per DMA, you be moving half your bitrate per call, and you'd only get 2 or so per second. Back to how MPEG2 is frame based. There are headers for each frame (00 00 01 00, IIRC). It's fairly easy to parse out these codes, but with the frame reordering, you wouldn't be getting 0, 1, 2, 3, 4, 5, 6, 7, 8, 9..., you'd get 0, 3, 1, 2, 6, 4, 5, 9, 7, 8..., which means that getting a frame at a time doesn't really help you out much, because you're not always supposed to display the frame you just grabbed. I hope that answers more questions that it causes. Jon |