> Delivery-Date: Sun, 27 May 2007 17:00:50 +0200
> Received-SPF: pass (mxeu11: domain of lists.sourceforge.net designates
> 66.35.250.225 as permitted sender) client-ip=66.35.250.225; [EMAIL
> PROTECTED]; helo=lists-outbound.sourceforge.net;
Hi,
> Yep. That's why there is the "sync" code. After a while, the program
> should "lock" to the correct position automatically.
Sorry, I don't follow. Whenever an unaligned "item" is encountered
(through
it=nx;
++nx;
pts=it->headerpts();
) at the end of the loop, the situation I described can
happen again.
I agree it wouldn't be a problem if the situation only occurred once
at the start of the stream, but we have already seem that for some
streams unaligned packets happen regularly.
> That will work fine in a perfect world where no transmission errors occur.
>
> I noticed that you drop out of the loop in audio_addpts() (line 182 in
> your version) when framesize == 0. Doesn't that mean that a single
> missing frame header will stop audio pts processing prematurely?
Indeed, that is a perhaps a mistake -- maybe I should have posted the
complete patch which I have in mind -- but I believe that doesn't
change anything compared to the original version, see below.
> I agree that the for loop seems to terminate immediately and should be
> removed. But what about the rest of the code? It used to be executed
> whenever there was a frame synchronization problem. With your patch,
> it's only executed once at the beginning of the outer (while) loop
> because you deleted the assignment "needsync=true" later on (line 182 in
> revision 35) and decided to leave the loop instead.
Yes that is perhaps a mistake. But consider the original code.
How can needsync=true come about?
Only if ptsplus==0, and that means that mpaframe() or
ac3frame() has returned 0. And I can see no way of that
happening without pos+2>=len, which means that the condition
if (pos+2>=len)
break;
in audio_addpts() would already have left the loop!
> Besides that, your code will never return the length of the last frame
> that begins in the buffer because {ac3,mpa}frame() can't access the
> following frame header.
True (and I would argue you cannot be certain that what follows really
is a valid frame), but I thought that the buffer shifts through the
file with only the already framed data being discarded, so when
audio_addpts is called _again_ the last frame (which is now the first
frame) will be detected just fine?
> But what happens if the frames are aligned?
Sorry, I don't understand that question.
> I'm afraid you opened a big can of worms here.
I tested with several streams and can't see any change in behaviour.
Can you?
Regards,
Wolfram
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
DVBCUT-user mailing list
DVBCUT-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dvbcut-user
