On Tuesday 18 Apr 2006 12:33, Mark Adams wrote:
> > so I get a few jerks and A-V sync isn't as good as
> > it should be. I've started looking into this again now...
>
> The A-V sync suffers a little because triple-buffering introduces a
> noticable delay into the video so the audio becomes noticably early.
> I'm a xine-lib user and surprisingly there seems to be no way to
> account for this using any config option. What's needed is a
> corresponding audio delay.
It seems worse on certain channels with a higher bitrate so I was putting
most of it down to a high CPU load.
> As for your jerks, can't help there -- my video is jerk-free.
I think it's mainly down to the CPU usage: this box sits at about 80% a
lot of the time, although it might improve if I played about with the
priorities of certain threads.
> > Currently, softdevice uses libavcodec to do the actual MPEG2
> > decoding. What I was hoping for was a simple slot-in solution where I
> > just pass the relevant MPEG2 data to a different library, retrieve
> > the decoded frames, and leave softdevice to display them using
> > DirectFB.
>
> I'm not sure it works like this: I think you feed data to the hardware
> decoder and it puts the result directly into video memory. What you
> need is for this to be represented by a DirectFB surface so that you
> can then flip it out to a display layer. I've only spent a small
> amount of time looking into this though, so I may be wrong.
Hmmm...what I was hoping was to be able to create a hardware equivalent of
avcodec_decode_video() so I could just slot it into softdevice and let
that handle all of the A-V sync, transferring to framebuffer, flipping,
etc.
Then again, if all I need to do is work out where the pictures go, I
should be able to send the data to my function, which feeds it into the
decoder, and then make sure it flips the right thing at the right time!
This might actually simplify things but it wouldn't be easy to do as a
separate library!
> > mtest: not fully built this yet because it requires a patch to
> > DirectFB. It seems to need /dev/cle266vgaio which linux-viafb from
> > DirectFB doesn't provide.
>
> You shouldn't need that if you're using the DirectFB viafb module:
> cle266vgaio just allows user-space code to access the video registers:
> the framebuffer driver does that too.
Yes: it is using it to mmap from it:
fd = open("/dev/cle266vgaio", O_RDWR | O_SYNC, 0);
if (fd < 0) {
fprintf(stderr, "Could not open /dev/cle266vgaio.\n");
return -ENODEV;
}
hwregs = mmap(NULL, 0x1000000,
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if ((int) hwregs == -1) {
fprintf(stderr, "Could not mmap /dev/cle266vgaio.\n");
close(fd);
return -EBUSY;
}
I'll see if I can work out the equivalent for viafb (not really done any
driver programming yet!).
> > Now, I'm not totally sure whether the data can be read back from the
> > decoder or whether it goes directly to a framebuffer from there,
> > somehow!
>
> I think it goes directly into video memory.
>
> > Has anyone made any more progress with this or am I starting from
> > scratch?
>
> Not as far as I know.
Well, I'll see what I can do. mtest is definitely the best place for
reference. This reads a video file and plays it back through the MPEG
decoder and DirectFB. One thing I will need to work out is what I need to
do to the data before feeding it into the decoder. Again, clode
inspection of both softdevice (I think this gets fed PES packets) and
mtest. I think the MPEG decoder needs feeding slices rather than packets.
Cheers,
Laz
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
