[Ffmpeg-devel] MPEG-2 Acceleration Under Mac OS X - Can We Move This Forward?
John Dalgliesh
johnd
Tue Aug 29 10:33:42 CEST 2006
On Tue, 29 Aug 2006, Nigel Pearson wrote:
>
>> Also, is it possible to extend to functionality of the
>> code to allow decoding of other codecs than MPEG-2?
>
> Anything is possible (the GPU
> vendors talk about MPEG4 assist too),
> but I think that is very unlikely.
> From my understanding of it,
> Apple only uses HW assist for DVDs.
Yes I'm sure the GPU manufacturers would be quite happy to make an API
suited to MPEG4 for Apple, but since it's not in Apple's interests it's
very unlikely to happen. Apple want to sell more and faster computers.
Their latest computers don't have too much trouble with MPEG4 / H264 in
software so it becomes another reason to upgrade. The only reason we have
an MPEG2-on-GPU API is because the first Macs that could play DVDs really
really needed the help. (This is all IMHO of course.)
One thing that might be easily salvagable from the DVDVideo API is its
deinterlacing. Although this is not really a topic for ffmpeg.
Apart from that I fear it's too MPEG2-specific to be of use elsewhere. I
don't know much about the internals of codecs 'tho so maybe someone else
has a better idea. Here are the structures ffmpeg currently fills in:
---------------------------------------------------------------
typedef struct DVDV_Frame
{
int intra_vlc_format;
int alternate_scan;
} DVDV_Frame;
typedef struct DVDV_MBInfo
{
int16_t frwd_mv[2];
int16_t back_mv[2];
int16_t frwd_mv_field[2];
int16_t back_mv_field[2];
uint8_t field_select[4]; // 0/1 in order of mvs above
uint8_t mb_type; // |1 = frwd, |2 = back, |4 = use fields
uint8_t ildct; // 0/1
uint8_t num_coded_elts[6]; // for each block incl. dc
} DVDV_MBInfo;
typedef struct DVDV_DCTElt
{
uint8_t run_sub_one;
uint8_t unused;
uint16_t elt; // adjusted for first coded elt in block:
} DVDV_DCTElt; // intra sub 0x0400, else add 0x0400
typedef uint8_t DVDV_CPB;
---------------------------------------------------------------
Hopefully they are self-explanatory for those familiar with MPEG2. Do they
look like they could be adapted for use in other codecs to anyone?
{P^/
More information about the ffmpeg-devel
mailing list