Hi!
Wolfram Gloger wrote:
>>Hmm... `bytes' is the distance between two items, and should be an
>>integer multiple of the frame size.
>
>
> But items also include the (sometime) non-aligned PES packet headers;
> these are not deleted in audio_addpts. For those, the distance is
> arbitrary, see the log output below.
Well, the fix would be to ignore (or replace) those items.
I guess that's what you had in mind?
>>>By debugging :-) I noticed audio frames were written with size
>>>1184 even though 576 should have been the size always.
>>
>>Is it always 1184, or does the value differ?
>
>
> Ok, I have just applied
>
> --- dvbcut-orig/src/mpgfile.cpp~ Sun May 27 17:24:25 2007
> +++ dvbcut-orig/src/mpgfile.cpp Mon May 28 12:15:51 2007
> @@ -619,6 +619,7 @@
> if (bytes>0)
> {
> pts_t pts=audiopts[a]-audiooffset[a];
> + fprintf(stderr, "mux.put audio %d %lld\n", bytes, pts);
>
> mux.putpacket(audiostream(a),sd->getdata(),bytes,pts,pts,MUXER_FLAG_KEY);
>
> sd->discard(bytes);
>
> and I append the output for otherwise unchanged dvbcut-35
> for a stream with unaligned audio.
I agree that the output looks pretty bad.
[...]
> I have two separate problems, but the one with false positive from
> mpaframe() happens very rarely, and is handled by my patch.
And what's the other one?
>>I think that should be handled inside the caller, i.e. audio_addpts().
>>Actually, the whole syncing business should be handled there. ac3frame()
>>and mpaframe() should just return the size of the frame, or 0 if there
>>is no valid header.
>
>
> Yes! That is exactly what my patch does.
The original code did that as well. It just was less picky (which may or
may not be a Good Thing (tm)).
>>There is, by the way, an indicator for the most likely next position:
>>`bufferposition'. But there is also another bug: If audio_addpts() finds
>>a valid frame, it will insert a new item. But it's not an item for the
>>frame itself because `bufferposition' has already been updated and
>>points *after* the frame just checked. :-(
>
>
> Yes! That is why I changed the {mpa,ac3}frame calling so this
> can be handled correctly (in a followup patch).
I see. Then I should probably look at the complete picture.
[...]
>>Hmm. Doesn't that mean that your patch has no effect at all? Or, vice
>>versa, that the original code worked fine even when there were sync
>>problems now and then?
>
>
> The patch just fixes the very rare false positive from mpaframe. It
> doesn't solve the sync problem. I think I'll post my current complete
> patch in another thread so maybe everything becomes clearer.
Okay, I'll have a look at it. I just noticed that you already sent the
patch.
After quite a bit of testing, I got the impression that the first patch
doesn't change anything. I exported a number of files, but the result
was still the same.
I'm curious whether the second patch will have any positive effect e.g.
on Ralph's picky DVD player... Ralph, can you please try it out?
--
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
