On 10/20/05, Cory Papenfuss wrote: > So you're planning on padding and/or discarding mis-matched A and > V stream frames? Yes. Well, you can't discard audio frames, as that really disrupts the experience, though one possibility is to speed them up with pitch correction. If it is only 10-20 ms/sec it is unlikely you'll even here the difference.. The other option is to add remove frames in video (which is the option I'm currently using, because it is simple to impelement). The current problem I'm having is that while I can remove B-frames to speed up video (which I don't normally have to do), and this has a minimum impact on the bitrate, I can only insert I frames, which is causing overruns in the allowed bitrate (resulting in an SCR/PTS mismatch during muxing). The other problem with this is that I-frames don't happen very often (and since I'm not doing any encoding, I can only insert a duplicate I-frame next to an existing i-frame), so you need to insert longer delays, which are very noticable as stuttering video. Ideally, I could generate a P-frame with all motion-vectors zeroed out. This frame could be inserted after any I or P frame letting me smooth out the video slow-down, and would have a minimal impact on the video bitrate. It may not be quite as flexible though, and I haven't figured out how to code valid P-frames as yet, but this is likely my next avenue of attack.
> I still think a partial reconversion would be a great compromise. > ONLY reencode (even it's a full decode/reencode of an entire GOP) around > glitches in the stream or commercial cuts. Yes, this would be ideal, and I had planned on coding it back when I first did mpeg2trans (almost 2 years ago now), but it requires getting everything else working first, and I never had much luck ironing out the 1st wave of bugs. _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
