[vdr] Re: Still pictures with latest CVS driver

[Andreas Schultz <aschultz@cs.uni-magdeburg.de>]

Hi,

Klaus Schmidinger wrote:

> Stefan Huelswitt wrote:
> 
>>On 24 Nov 2001 Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote:
>>
>>
>>>Unfortunately I still have no idea why VDR can't display still
>>>pictures with recent CVS diver versions, although Ralph insists
>>>that the I-frames they use _can_ be displayed (and he proved that
>>>to me by sending me such a frame, so I have to accept that from
>>>his point of view the driver's 'play_iframe()' function _is_
>>>working).
>>>
>>And what is the difference between your iframes and Ralph's?
>>
> 
> I wish I knew ;-)
> 
> I have uploaded the files
> 
>   ftp://ftp.cadsoft.de/pub/etc/cim.mpg
>   ftp://ftp.cadsoft.de/pub/etc/kls.mpg
>   ftp://ftp.cadsoft.de/pub/etc/play_still.c
> 
> The first one contains Ralph's I-frame (@Ralph: I hope it's ok with you
> that I have uploaded this file?!), the second one is one of VDR's I-frames,
> and the third one is a small example program that takes the name of a file
> and displays the I-frame in that file as a still picture (I also got this one
> from Ralph). Interestingly, with the unpatched driver cim.mpg works, but kls.mpg
> doesn't. If you apply my patch to dvb.c, kls.mpg works (and IIRC cim.mpg doesn't
> work any more, but I'm not sure about that).
> 
> If anybody can find out what prevents kls.mpg from being displayed, I'd appreciate
> any hints. BTW: kls.mpg may contain sequences with many subsequent 0x00 bytes.
> These are former AC3 audio packets that have been erase by overwriting them with 0x00.
> AFAIK there may be any number of 0x00 bytes in an MPEG stream, so this shouldn't
> make a difference.


Sorry no solution, but some observations.

play_iframe() tries to fill a 400kb buffer by repeating the I-frame n+1 
times (n = 400000/size of the frame). It does so by extracting only 
parts of the frame, that contain video data. Your change effects IMHO 
only some tail fragments of the I-frame, but could lead to the buffer 
filling faster.

It could be, that due to you 0x00 fills and some apparent stuffing bytes 
in your frame, you never reach the magic fill level. This might be fixed 
by using "n=MIN_IFRAME/len+2;" in dvb.c.



    Andreas

 
> Klaus
>