[linuxtv-softmpeg] libsoftmpeg bug

[Bryce Nichols <bryce@bnichols.org>]

I found a problem in libsoftmpeg concerning handling of PES data. In the
softmpeg.c file, the header_length value is only read if the PTS or DTS
flags are set.  Before I changed this, I had a lot of issues with the
video.

Here's my CVS diff:

Index: softmpeg.c
===================================================================
RCS file: /cvs/linuxtv/libsoftmpeg/src/softmpeg.c,v
retrieving revision 1.34
diff -r1.34 softmpeg.c
402a403,404
>               header_length += buf[8];
>
409,410d410
<                       header_length += buf[8];
<


I am working on many changes to libsoftmpeg.  After I've done more testing
and cleaned up my code a bit, I will post a patch.  Significant changes
include new AV sync code that relies less on the video refresh rate for
synchronization, auto adaptation to the frame rate of the video material
(so it just works automatically for either PAL or NTSC formats but with
the option to force a particular rate or specify various methods of
determining the frame rate), and spelling and formatting corrections.  I
also plan to make it easy to play back either TS or PS material.  I have
now achieved smooth video with nice AV sync when playing the mpeg2 PS
coming out of a PVR350 card.

I would really like to hear more comments from users having issues with AV
sync or skips in audio or video so I can explore what other issues may
need to be addressed.  Also, if there are any particular issues that
anyone needs help with, let me know, as I may have fixes I could share
even though I'm not ready to release a full patch yet.

As someone said earlier, libavcodec does have software colorspace
conversion routines (namely, the img_convert function).  It should not be
very hard to make use of these to allow playback to DirectFB RGB surfaces
(whether the routines are fast enough, I don't know).  I may eventually
get around to changing from my own hacked-together conversion routines to
using libavcodec for this, but it's not my first priority.  I hope someone
else can work on this.

Lastly, for anyone trying to use libsoftmpeg without hardware acceleration
for stretch blitting, I have found that stretch blitting is quite slow for
my setup (SiS 315 series video chipset), requiring more than 1/30 of a
second, making smooth video impossible.  Some of the DirectFB video
buffering strategy settings can have a huge affect on timing too, so make
sure you have these settings correct for your situation.  I've been using:

depth=16
pixelformat=RGB16
window-surface-policy=systemonly
desktop-buffer-mode=frontonly

with good results as far as drawing speed goes.

To deal with the slow stretch-blitting until I get a CLE266 chipset, I am
using the DirectFB Blit function instead, and just keeping the window the
same size as the video material.  Here's the patch:

Index: src/v_directfb.c
===================================================================
RCS file: /cvs/linuxtv/libsoftmpeg/src/v_directfb.c,v
retrieving revision 1.5
diff -r1.5 v_directfb.c
311c311,313
<       data->window_surface->StretchBlit(data->window_surface,
data->video_surface, NULL, &rect);
---
> //    data->window_surface->StretchBlit(data->window_surface,
data->video_surface, NULL, &rect);
>   data->window_surface->Blit(data->window_surface, data->video_surface,
>                                &rect, 0, 0);

Cheers

--Bryce