Hi!
Sven Over wrote:
First: as I said in my last posting, I could reproduce a segfault when working
on streams from German public TV stations. I could track it down to an oddity
in the timestamps in the original streams. In contrast to the streams I used
before, here the MPEG audio frames (smallest unit of audio, 1152 samples) are
sometimes placed accross packet boundaries. This should not be a problem, my
stream parser does not rely on audio PES packets always starting with an
audio frame (although they do, on MTV2), but the audio packets on ARD that
start amidst MPEG audio frames bear wrong timestamps, slightly off from the
correct ones. This caused quite some trouble, because for DVBCUT the
timestamps were not in sequence anymore. From my point of view, this is a
violation of the ISO standard, as PTS should represent the time of
presentation of the first MPEG audio frame commencing in the packet.
That's what it says, right. But it only applies to PTS (in PES packet
headers), not to PCR (in TS adaptation fields) or SCR (in PS pack
headers). That's likely to confuse people - maybe they mixed it up? Or
wrongly re-calculated the PTS from the SCR/PCR.
Anyway,
I changed DVBCUT such that timestamps of audio packets are ignored when the
"data alignment indicator" is not set, that is, if the packet does not begin
with a beginning of an audio frame.
The question is whether or not the data alignment indicator is more
trustworthy. If the timestamps are wrong, it might be wrong as well. :(
Besides that, my (draft) version of the standard says: "When set to a
value of '0' it is not defined whether any such alignment occurs or
not." That is, a braindead^Wsimple encoder might align data but always
set the data alignment indicator to '0'. In that case, dvbcut wouldn't
find any valid timestamps at all in that stream.
The best solution probably would be to silently correct the PTS.
Second: regarding the negative time codes displayed by DVBCUT. I found that
some TV stations (Kabel 1, in my example) only have 32 bit timestamps. The
timestamp fields in MPEG2 streams comprise 33 bits. However, here only 32
bits are used, such that 2^32-1 is followed by 0, not by 2^32. This happens
approximately every 13 1/4 hours. If you use all 33 bits, unique timestamps
last 26 1/2 hours. This is fixed as well, DVBCUT regards 0 now as 2^32 when
it follows values close to 2^32.
Oh well. I consider that a standard violation, too.
I'm seriously thinking about a "stream rectifier" that detects all these
quirks and corrects them if possible.
--
Michael "Tired" Riepe <[EMAIL PROTECTED]>
X-Tired: Each morning I get up I die a little
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
DVBCUT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dvbcut-user
