Hi all. Great news (at least for me, I don't know how many of you guys care about this... :-) ). After about a month of fighting against this ugly bug I've finally overcome it. It was indeed a MultiDec bug, in that it did not correctly set the flags in the PVA packet headers as well as the ones inside the PES headers. To get it simple, in a PVA file the audio PES packets contained in the audio stream are aligned to the starts of PVA container packets. There is a flag in each PVA packet header that tells whether a new PES packet starts there or not, so that one can tell if he has to parse the PES header. MultiDec simply did not set it for about half of the PES packets, which is why the audio stream ran about twice as fast as the video stream. Moreover, the same PES packets that are not signalled in the PVA headers do NOT contain valid PTS information, nonetheless the "PTS" PES header flag WAS SET. I must admit I did have to introduce quite a hack to get those files running, and I'll have to tidy up the code a little bit before I submit a patch (hopefully tonight or tomorrow). This message was just to let you know that we can soon remove the "BROKEN" from those PVA files... :-). So, Arpi was right about the part that the audio stream ran twice as fast: about half of the data was discarded!!! ah, I've already bought the 10 liters of cola I deserve to drink for those stoooooopid bugs that caused Dominik's problem. Sorry all. It was interesting though that his files ran file on my system even _before_ the patch, as I had told him. Anybody have an explanation for it ? Could it just be the different compiler? Cheers. Matteo