Hi again!
Wolfram Gloger wrote:
>>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.
This code really is confusing. And sometimes wrong.
I don't understand how dvbcut can actually encounter so many unaligned
frames at all. audio_addpts() operates on a single buffer that
(theoretically, i.e. if the file isn't damaged) contains a number of
consecutive frames, plus maybe a partial frame at the beginning and at
the end. And once it's in sync, it should stay in sync. Advancing to the
next item should not have any effect as long as `bufferposition' (the
index into the buffer) isn't updated as well.
By the way, how do you detect the sync failures? And how often do they
happen?
> 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.
Well, if they're unaligned, all of them usually are. The question is how
often dvbcut will run out of sync. Probably not with every single frame
or (PES) packet. Maybe once with every call to audio_addpts()?
>>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!
Actually, testing for `pos+2>=len' at that point was a bug. It should
have been `pos > len' because mpaframe updated pos to point at the end
of the frame (or even further). Therefore, it is possible that pos==len
and ptsplus!=0 if frames are aligned.
But you're right - after re-indenting the code I noticed that
{ac3,mpa}frame() will only return 0 when they reach the end of the buffer.
>>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),
I could also argue that you can't claim a frame being invalid just
because it's not followed by another 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?
It should. Actually, it should be in sync as well. But it isn't :-(
I guess we're currently barking at the wrong tree. The fact that
audio_addpts() obviously doesn't keep sync is not the fault auf
{ac3,mpa}frame(). It's the fault of audio_addpts(), or the functions
calling it, i.e. mpgfile::savempg() and mpgfile::playaudio(). You
probably can forget about the latter because it calls audio_addpts()
only once.
> I tested with several streams and can't see any change in behaviour.
How did you verify that - compare the output files?
--
Michael "Tired" Riepe <[EMAIL PROTECTED]>
X-Tired: Each morning I get up I die a little
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dvbcut-user
