Hi!
Wolfram Gloger wrote:
> I have found that your "patch #6" (from Aug 6th) disabled an
> "invalidation" of timestamps that prevents the serious "non monotonous
> timestamp" errors with the libavformat muxer (even the one included
> with dvbcut) -- just the hunk in question (*):
>
> --- dvbcut/src/streamdata.cpp 23 Mar 2006 23:41:53 -0000 1.2
> +++ dvbcut/src/streamdata.cpp 6 Aug 2006 00:09:20 -0000 1.3
> @@ -286,6 +286,7 @@
> }
> }
>
> +#if 0 // --mr
> if (type==streamtype::mpegaudio) {
> if (s>=2)
> if (data[0]==0xff && (data[1]&0xf0)==0xf0)
> @@ -304,6 +305,7 @@
> s-=ac3offset+2;
> flags|=STREAM_ITEM_FLAG_DATA_ALIGNMENT_INDICATOR;
> }
> +#endif
Yep. That was the workaround that was supposed to fix the timestamp
problem but killed audio on Channel4 recordings. It invalidated *all*
audio timestamps just because the frames were not aligned inside the PES
packets. Which is, of course, plain nonsense. A PTS refers to the first
presentation unit that begins within a PES packet - whether at the very
beginning or somewhere else.
Besides that, the code ignored the true meaning of the data alignment
indicator: If it's set, presentation units (in this case, audio frames)
are supposed to be aligned. If it's not set, they may be aligned or not.
But that's no reason to discard the timestamps.
> I have checked pristine dvbcut sources and added just one line of
> debugging:
>
> --- dvbcut-orig/src/mpgfile.cpp 2006-10-29 21:03:53.000000000 +0100
> +++ dvbcut-wg/src/mpgfile.cpp 2006-11-29 21:42:12.000000000 +0100
> @@ -578,6 +582,7 @@
>
> if (bytes>0) {
> pts_t pts=audiopts[a]-audiooffset[a];
> + fprintf(stderr, " astream%d bytes:%4d pts:%s\n", a, bytes,
> ptsstring(pts).c_str());
>
> mux.putpacket(audiostream(a),sd->getdata(),bytes,pts,pts,MUXER_FLAG_KEY);
>
> sd->discard(bytes);
>
> With the problematic stream, I get sth like:
>
> ========================================================================
> ...
> astream0 bytes: 192 pts:00:00:12.329/31
> astream0 bytes: 960 pts:00:00:12.353/31
> astream0 bytes: 576 pts:00:00:12.377/31
> astream0 bytes: 288 pts:00:00:12.401/31
> astream0 bytes: 288 pts:00:00:12.425/31
> astream0 bytes: 576 pts:00:00:12.449/31
> astream0 bytes: 576 pts:00:00:12.473/31
> astream0 bytes: 384 pts:00:00:12.497/31
> astream0 bytes: 768 pts:00:00:12.497/31
> error, non monotone timestamps 1124761 >= 1124761
> astream0 bytes: 576 pts:00:00:12.521/31
> astream0 bytes: 480 pts:00:00:12.545/31
> astream0 bytes: 672 pts:00:00:12.569/31
> astream0 bytes: 576 pts:00:00:12.593/31
> astream0 bytes: 576 pts:00:00:12.617/31
I see what you mean. But I need to analyze a piece of that stream in
order to find out what's wrong and how to fix it. I assume that
consecutive "items" carry identical timestamps, but that's impossible to
fix without knowing *why*.
--
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
