Hi! Wolfram Gloger wrote:
>>Actually, that's not a crime. There's no requirement that MPEG audio >>frames are aligned inside PES packets (i.e. a frame header immediately >>follows the PES header). > > > Yes; I didn't state otherwise.. But your patch did ;) >>How often does the "skipping" message appear? Does it happen while the >>file is indexed or when it is exported? > > > It happens whenever the file is opened (no matter whether already > indexed or not) and repeats for some \approx 160 times, corresponding > to the skipping of an entire TS packet until the MPA header ist > found (in the next TS packet I assume). In that case, the stream is probably broken. > When it is exported, the problem with the timestamps shows up and > there are audible "skips". Did you try another (non-ffmpeg) muxer? >>>However, also the old ffmpeg version included with dvbcut appears to >>>have this "problem"; at least when the libavformat muxer is used there >>>are error messages about "non-monotonous timestamp" when such packets >>>are encountered. >>> >>>Did anyone else ever notice this? >> >>The "non-monotonous" message is not an indicator - the libavformat muxer >>(at least the included version) uses a wrong formula to calculate the >>timestamps (DTS, IIRC). > > > Could you perhaps elaborate so the DTS computation can be fixed? I will have to grep my mail archives for that. Stay tuned. [...] >>An "item" is always a PES packet, not an audio or video frame. Since >>your patch enforces an alignment that actually need not be there, you >>may end up with no audio at all. > > > That is indeed possible, yes, but only if there are _never_ packets > with an MPA header after the PES header (*). > > >>We already had a similar problem with >>Channel4 (UK) which transmits unaligned MPEG audio. > > > Was that (*) the case there? Exactly. >>I'm not sure if the input file is the problem in the first place. It may >>also be a bug in the version of ffmpeg you're using. Can you confirm >>that the stream is malformed, > > > No, I'm not in fact claiming the stream is malformed.. Well, if the stream is well-formed, then there's a bug in dvbcut that needs to be fixed. If it's not, I may consider adding a workaround - but only if it doesn't break anything else, including Channel4. > I am claiming that dvbcut passes un-framed audio data to libavcodec, > and that fails -- spectacularly with ffmpeg-current but I believe > it was never documented to work correctly and also silently goes > wrong with the old ffmpeg version in dvbcut. I guess I need a piece of the stream to work out the details. -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ DVBCUT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dvbcut-user
