[linux-dvb] Re: AW: VDR 0.80pre8, current CVS OSD problems

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Ralph Metzler wrote:
> 
> Klaus Schmidinger writes:
>  > I'm currently thinking: would it be possible to rearrange the audio/video
>  > packets in VDR when recording, so that these audio underruns would no longer
>  > occur? That way we might be able to get back the OSD memory.
>  >
>  > The idea is that the overall timing of the a/v packets must be ok, since
>  > it works when viewing the live broadcast. During the several conversions
>  > on the way to the recording file the packaging apparently gets changed in a way
>  > that there are too many video packets in a row and the next audio packet comes
>  > too late (please correct me if I'm wrong here). So the whole problem would
> 
> Viewing the live broadcast works because the firmware(ROM)/RTSL
> offers a mechanism which uses an overflow buffer in DRAM (as opposed
> to the SDRAM where the normal buffers, OSD, etc. have to be).
> This overflow buffer (if configured) is automatically used when the
> video buffer is full. Data is DMAed to/from the buffer as needed.
> Without this normal TV watching also does not work correctly with the
> increased OSD memory.

But "normal watching" used to work just fine for the past year or so, and
I don't think that the OSD memory has been _increased_ since then. So what
has changed that caused normal viewing to suddenly fail?

> This mechanism is only implemented for the "watching mode" and
> hidden somewhere inside the black box made up of firmware ROM and
> binary only TI libraries.
> 
>  > appear to be solvable if VDR would hold back the video packets just long enough
>  > until the next audio packet arrives, and then deliver several of the video packets,
>  > then the audio packet, and then more video packets - and then start all over again.
>  > The overall error can't accumulate, since in long term viewing the a/v timing
>  > must be ok.
>  >
>  > I hope I'm making some sense here and would appreciate any comments on this idea.
>  >
>  > What I would need to learn about is, if I have a sequence of a/v packets, like
>  >
>  >   V V V V V V V A V V V V V
>  >
>  > which should actually be stored as
>  >
>  >   V V V V V A V V V V V V V
>  >
>  > (note that the A packet moved a little to the front): how can I tell where to
>  > insert the audio packet? Any ideas?
> 
> By looking at the PTS.
> But exactly those channels which make problems also are the ones with
> very long times between video PTS.

So am I to understand that there is absolutely nothing that can be done( apart from
giving up the OSD altogether)? I remember a while ago (when the driver
still caused that picture "jerking" effect) we were told that this could only
be fixed by remuxing the stream in the application. Now that effect is gone,
apparently the driver now delivers better data.

What exactly do you mean by "very long times between video PTS"?
doesn't every frame have a PTS of its own, and isn't the time between
two frames exactly 1/25s?

Assuming I look at these video and audio PTS values, do you think that
there is a chance I could reorder the packets in a way that would result
in no buffer problems? Or is this technically impossible?

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.