[linuxtv-softmpeg] Re: softmpeg plugin and vesafb

[Michael Hunold <hunold@convergence.de>]

Hello Bryce,

On 05/27/04 19:28, Bryce Nichols wrote:
> I have been playing with libsoftmpeg for several days now, trying to
> achieve smooth playback of 30 frames per second video.  All the values are
> hardcoded for PAL format, so I changed everything I thought would matter
> for the new frame rate.
> I provided in src/internal.h a define called FRAME_DELAY.  It shouldbe
> set to the number of milliseconds between frames for the video source 
> you
> want to play.  For PAL, it's 40, for NTSC, it's 33.3 (repeating), but
> since it's used as an integer everywhere, I set it to 33.  This will
> throw
> off the av sync code probably, so maybe something more elaborate needs
> to
> be done.

Yes, support for non-PAL frame rates is missing completely. If you have 
the time, it would be cool if you could work on making libsoftmpeg 
format independent, ie. put all stuff together in a structure and use 
function pointers to call the necessary functions.

> I also noticed that the softmpeg_decoder_process_ts_data wants a number of
> bytes divisible by 188.  I'm using a hauppauge pvr350 to hardware encode
> mpeg video, and reading from it simply does not give a number of bytes
> divisible by 188.  So I hacked in something that keeps any spare bytes for
> the next read.  I don't know if the problem I saw here is legitimate or
> not.  Maybe the dvb cards always provide 188 byte chunks when you read
> from them??
Yes they do, but that shouldn't matter - my code is broken, I admit. As 
you already described, you should buffer the rest of non-188 bytes 
chunks and look if it can be used for the next chunk of data.

Do you mind to prepare send me a patch?

> I also wrote some crappy code for converting the YCrCb frames to RGB.
> It could be done a lot better, but it is enough to let me see some frames
> of video.  I think that Intel has some nice pages on so called YUV to RGB
> colorspace conversion that could be used as a basis for software
> conversion routines.  My first instinct would be to rip off the code that
> Xine uses for this, but that would taint the LGPL license of libsoftmpeg.
> The best approach (I think), is to find public domain code, or LGPL code
> that does colorspace conversion.  I don't intend to mess with this aspect
> much more because it's pointless if you have hardware support.
IMO libavcodec has already colorspace conversion code. I'm pretty sure 
that we can hijack the code from there.

> I've diffed my cvs checkout for anyone who wants to see the changes I've
> made.  I was planning on getting further before releasing anything, but
> since it may help someone right away, I will provide what I have so far.
>
> See http://www.bnichols.org/tmp_patches/
>
> There is the cvs diff there, and a new file yuv2rgb.h that should go in
> the src/ directory of the libsoftmpeg source.  It provides lookup tables
> that my code for the YCrCb to RGB conversion uses.
Ah, ok. I'll leave it up to the vesafb users to hack it in, but I'm 
willing to accept patches.

> I don't guarantee anything about my changes to the code.  I have not
> achieved smooth playback yet, not even just for audio.  For some reason I
> have not determined yet, the audio buffer consistently underflows for me.
> There does seem to be a problem in how the delay is calculated when the
> audio buffer gets to large.  I'm looking into it.
Please try to patch FusionSound with the new patch from CVS. The old 
patch applied to the wrong part of the source because of recent changes 
to FusionSound.

> Later,
> Bryce
CU
Michael.


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