[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [livid-dev] oms release
* arthur dent <bs_2048@hotmail.com> [20010201 11:00]:
> hi yoann,
>
> >- inclusion of the latest mpeg2dec ?
>
> if we NEED that for syncing, we should use the latest
> mpeg2dec, if not ... do the port after the release.
>
I just happened to be trying to put the latest mpeg2dec code into OMS
last night. It was very hard and I didn't get it to work. There's a
bunch of changes that just don't work together well... or at least I
couldn't figure it out last night. I think the open and close sequences
are different between OMS and mpeg2dec and OMS is trying to support
runtime changing of parameters like output size. Then the headers are
all screwed up! Plus the mpeg2dec-vo and oms-vo APIs are different.
Yuck.
The only way to keep this managable is to start using some OO style
rather than copy&edit style. If OMS needs some extra data (like that
user_data parameter) then create a oms_mpeg2dec_t struct with mpeg2dec_t
element in it. And then wrap the mpeg2dec API in OMS specific
functions. Much easier to update (or in the funture just link to)
mpeg2dec that way.
The video drivers are more difficult. There is added functionality like
overlays. I'm sure we can work with walken to provide the proper hooks
if needed so that we can reuse the mpeg2dec/libvo drivers and just have
OMS wrappers for them that add some functionality... not reimplement it
all.
I think sync may need some support from mpeg2dec? Don't we need
timestamps on the output? We either need to do stream parsing in OMS
and just feed a frame at a time to libmpeg2 with OMS determined
timestamps or have libmpeg2 add timestamps that the display calls can
access? Or am I just confused? ;)
Anyway... I'll try and put some more time into this. May be hard to
start up again after getting so upset at the code last night. ;)
-dave
--
David I. Lehn <dlehn@vt.edu> | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA