Hi,
>But your patch did ;)
Ok, the comments were perhaps slightly misleading -- "invalid" didn't
refer to the stream but to the framing into "items".
>>>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.
I have verified that it happens with the included ffmpeg version, too,
one just has to enable debugging output:
mpegaudiodec.c:2525 dprintf("skip %x\n", header);
and this will trigger many times when opening the stream. But I now
believe _that_ is no serious problem, see below..
>Did you try another (non-ffmpeg) muxer?
Yes, with the dvbcut muxer there are no error messages but the audio
framing is strange in any case, see the "byte counts" below..
>> Was that (*) the case there?
>
>Exactly.
Oops, I see. My patch clearly isn't good enough then.
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
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
...
astream0 bytes: 288 pts:00:01:08.945/31
astream0 bytes: 864 pts:00:01:08.969/31
astream0 bytes: 576 pts:00:01:09.041/31
astream0 bytes: 384 pts:00:01:09.065/31
astream0 bytes: 768 pts:00:01:09.041/31
error, non monotone timestamps 6215881 >= 6213721
astream0 bytes: 576 pts:00:01:09.065/31
error, non monotone timestamps 6215881 >= 6215881
astream0 bytes: 480 pts:00:01:09.089/31
astream0 bytes: 672 pts:00:01:09.113/31
astream0 bytes: 576 pts:00:01:09.137/31
========================================================================
Note the strange variation in packet sizes!
Now with just the above hunk (*) from your "patch #6" reverted:
========================================================================
astream0 bytes: 576 pts:00:00:12.329/31
astream0 bytes: 576 pts:00:00:12.353/31
astream0 bytes: 576 pts:00:00:12.377/31
astream0 bytes: 576 pts:00:00:12.401/31
astream0 bytes: 576 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: 576 pts:00:00:12.497/31
astream0 bytes: 576 pts:00:00:12.521/31
astream0 bytes: 576 pts:00:00:12.545/31
astream0 bytes: 576 pts:00:00:12.569/31
astream0 bytes: 576 pts:00:00:12.593/31
astream0 bytes: 576 pts:00:00:12.617/31
...
astream0 bytes: 576 pts:00:01:08.945/31
astream0 bytes: 576 pts:00:01:08.969/31
astream0 bytes: 576 pts:00:01:08.993/31
astream0 bytes: 576 pts:00:01:09.017/31
astream0 bytes: 576 pts:00:01:09.041/31
astream0 bytes: 576 pts:00:01:09.065/31
astream0 bytes: 576 pts:00:01:09.089/31
astream0 bytes: 576 pts:00:01:09.113/31
astream0 bytes: 576 pts:00:01:09.137/31
astream0 bytes: 576 pts:00:01:09.161/31
========================================================================
And everything seems fine..
Can you explain why you commented _out_ the PTS invalidation?
Sorry for the long mail, but I hope everything is clearer now.
Regards,
Wolfram.
-------------------------------------------------------------------------
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
