Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: VDR developer version 1.3.14
On Friday 29 Oct 2004 14:16, Klaus Schmidinger wrote:
> Laurence Abbott wrote:
> > Hmmm...I'm starting to think that the new buffer-handling routines are
> > mores sensitive to artifacts in the signal due to weather, etc.
>
> I don't think that the changes to the buffer handling could cause this.
> However, I did refurbish the code in cRemux that detects frame borders
> (and thus picture types). Maybe I broke something in there...
That's probably what I actually meant :-s
Just looking through remux.c now. Do you have any good URLs for info on these
DVB streams so I can see what it is doing?
> > I've found the //#define DEBUGRINGBUFFERS bit in ringbuffer.h but I'm
> > not really sure what the output means to try to debug this!
>
> This prints a visual display of all ringbuffers, which is rather
> helpful when testing buffer handling.
What should this output be like, ideally? At present, it spews out many lines,
i.e. several screens full, to start with, with the head and tail pointers
generally moving progressively to the right:
0 >-------------------------------------------- -1 -1 Transfer
1 >-------------------------------------------- -1 -1 Result
2 -<>------------------------------------------ 11280 188 TS
0 ------<*>------------------------------------ 188 55084 Transfer
1 ------->------------------------------------- 2048 5906 Result
2 --------->----------------------------------- 11280 188 TS
0 -------->------------------------------------ 188 55460 Transfer
1 ---------------->---------------------------- 2048 4096 Result
2 --------->----------------------------------- 10716 188 TS
0 -------->------------------------------------ 188 55460 Transfer
1 ---------------->---------------------------- 2048 4096 Result
2 --------->----------------------------------- 10716 188 TS
0 -------->------------------------------------ 188 55460 Transfer
1 ---------------->---------------------------- 2048 4096 Result
2 ---------<>---------------------------------- 11280 188 TS
etc.
After a while it will sit there for several minutes without outputting any
more lines before spewing out another large number of lines before settling
again. (I'm assuming that this is real and not some bizarre buffering of
stdout!). Similar things are seen during record and playback, e.g.:
0 --------------------------------<>----------- 188 54708 Recorder
1 ----------------------------------<********>- 2048 4096 Result
2 -------------------------------------<>------ 10528 188 TS
0 ------------------------------------->------- 188 54896 Recorder
1 ----------------------------------<*********> 2048 18432 Result
2 ---->---------------------------------------- 11468 188 TS
0 ----------------------------------------->--- 188 55084 Recorder
1 ------------------------<*********>---------- 2048 2048 Result
2 --------------<>----------------------------- 11092 188 TS
0 <>------------------------------------------- 188 54896 Recorder
1 -------------------------<********>---------- 2048 14336 Result
2 -------------------------<>------------------ 10528 188 TS
0 ----->--------------------------------------- 188 54708 Recorder
1 -------------------------<********>---------- 2048 2048 Result
2 ------------------------------------->------- 10528 188 TS
0 ---------<>---------------------------------- 188 54896 Recorder
1 -------------------------<********>---------- 2048 16679 Result
2 --->----------------------------------------- 11468 188 TS
0 -------------->------------------------------ 188 54708 Recorder
1 -------------------------<********>---------- 2048 2048 Result
2 --------------<>----------------------------- 11280 188 TS
(Are the *s bad?!)
Is this the expected bahaviour, or should it just output one set on going ot
transfer, playback, or record?
Cheers,
Laz
Home |
Main Index |
Thread Index