On 12/25/05, Geoffrey Hausheer <[EMAIL PROTECTED]> wrote: > Basically, what I'm calling the 'big hammer', is some code that kicks > in when all other hope is lost. It just throws away all timestamps in > the file, and uses its internal running count. From then on, there is > no attempt to keep AV in sync anymore. This happens when the PTS > jumps by more than 20 frames at once. After that, it is unreasonable > to try to fill in the empty frames. If this only happens to the > video, but not to the audio, the stream is broken, and there's not > much we can do. The 'big hammer' is better than nothing. However, if > all streams have the same (or similar) jump at the same time, we can > just reset the offset and move on. This is what I need to code. > Unfortunately, because audio and video are processed independently, it > isn't that easy to detect this case. I'll need to think about the > best way to do it. I'll let you know after I come up with a > reasonable fix.
Geoff, thank you very much for r8381 ;) This one fixed almost all my A/V issues. All my transcoded files lose 40% of data and are perfectly synchronous :D Great! The only small issue I still have are some green frames on every cut point. Is it a known issue? Here's a small (1MB) transcoded file with a cut point at the beginning: http://130.83.206.1/~egger/temp/temp.mpg Thanks again, Adam _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
