[vdr] Re: vdr at dbox2

[Carsten Koch <Carsten.Koch@icem.com>]

Andreas Oberritter wrote:
...
> While TS playback has been tested quite well with Neutrino (and Enigma
> now, too), PES playback using audio0 and video0 has not. Keeping the
> stuff in sync is very hard.
That matches my observation.


> This will never happen with a properly muxed TS where audio and video
> pes packets can be transmitted "simultaneously" because of the small and
> fixed TS packet size.
I know very little about all that, but I did notice that the data
currently produced by VDR can be played back or otherwise processed
only by very few programs such as mplayer and pvastrumento.
So I guess it might be a big step forward to move to a better format
again. There has already been the move from AV_PES to PES in the past.
I wonder how Klaus would feel about that?

Of course, I have half a TB of VDR recordings in PES and even if
VDR would record in TS from now on, I would still not be able to
play the old recordings back properly.


> a value which makes it try to synchronize a/v. The dbox2 drivers do this
> once after AUDIO_PLAY. You could try to set up a kernel timer which
> tries that regulary, but I think this won't help if the input stream is
> not ok.
I see.
That's why stopping/restarting the playback sometimes helps a little.


> Gdb needs too much memory. Use gdbserver:
> https://tuxbox.org/forum/viewtopic.php?t=22195
Thanks for the hint, I'll try that out.



> > 3) The DVB driver on the dbox does not provide the necessary functions
> >    for any of the trick modes (Fast Forward, Fast Reverse, Slow Motion).
>
> They never will for two reasons:
> a) The decoder does not support either of these features.
Of course it would be nice to have hardware support for these,
but is that the only chance?
I mean, obviously the software can control the sequence of
frames sent to the controller, so at least for FF/FR it could
send only I-frames or only every Nth I frame.

Regarding slow motion I do not know. I guess it will not yield
the desired results to replicate P- or B- frames?  ;-)
However, slow motion by replicating I-frames often enough
may be better than nothing.

If I had enough time, I would try that all out inside VDR.


> b) The network interface is too slow for real fast forward.
Are you sure? I have never calculated that.
Note that VDR does know the file offsets of all I-frames
(that information is stored in the index.vdr file), so it
would only have to read I-frame data over the network for FF/FR.
How big is a typical I-frame?
At 10 Mbit/s and 25 I-frames per second the theoretical
maximum size would be < 50 kilobytes.
If I-frames can get larger than that, one might play back
every (Nth) I-frame twice.
Does any of that sound realistic to you?


> >   I will offer my current version of the patch to the tuxbox folks.
>
> Thanks.
I'll send you my current version via private mail.

Carsten.


--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.