[openbeos] Re: Clipboard format standards for video and audio

> > [Cross-posted from interface kit list]
> > Everyone,
> > 
> > I am currently working on a section of the human interface 
> > guidelines 
> > concerning how to use the system clipboard and some standardized 
> > ways 
> > of passing data from one application to another. While there are 
> > established standards for image and text data, there isn't anything 
> > that I know of for audio and video. How should audio and video be 
> > stored? Then again, *should* it be possible to pass video via the 
> > clipboard? Thoughts?
> > 
> 
> A/V data can grow big quite fast, but nothing stops you from making a 
> temp file and passing a ref instead in the BMessage.
That's what I figured -- more than a few frames worth resulting in a 
temp file + passed entry_ref. One question down, one to go. :^)

Assuming that a few frames are stored in the clipboard, how should they 
be stored?  The "standardized" means of sticking a BBitmap on the 
clipboard means storing its size, color space, bitmap flags, bytes per 
row, a class field, and the image data itself. Should they follow the 
same kind of general format as attaching a BBitmap, using field indexes 
to access each frame? In case I'm not clear on this, I mean the 
PrintToStream output looking something like this:

BMessage: what =  (0x0, or 0)
    entry          class, type='CSTR', c=1, size=7, data[0]: "BVideo"
    entry         _frame, type='RECT', c=1, size=16, data[0]: 
BRect(l:0.0, t:0.0, r:319.0, b:239.0)
    entry    _framecount, type='LONG', c=1, size= 4, data[0]: 0x5 (5, 
'')
    entry       _bmflags, type='LONG', c=1, size= 4, data[0]: 0x0 (0, 
'')
    entry      _rowbytes, type='LONG', c=1, size= 4, data[0]: 0xa00 
(2560, '')
    entry          _data, type='RAWT', c=5, size=13, 0x000000: 
63,78,64,66,67,6c,78,64,66,66,67,6c,00           'cxdfglxdffgl.   '
    entry    be:location, type='BPNT', c=1, size= 8, data[0]: 
BPoint(x:0.0, y:0.0)

Being that the stats for each frame don't change, the only field where 
there is multiple instances is the _data field, where the image data 
for each frame is kept. Is this a good way to store it or is there a 
better way which utilizes the Media Kit itself. I'm not familiar enough 
with the Media Kit to be able to confidently make decisions like this, 
so I'm asking all of you.

The same thing goes with audio data. What about something like this?

BMessage: what =  (0x0, or 0)
    entry          class, type='CSTR', c=1, size=7, data[0]: "BAudio"
    entry    _framecount, type='LONG', c=1, size= 4, data[0]: 0x4 (4, 
'')
    entry    _framebytes, type='LONG', c=1, size= 4, data[0]: 0xa00 
(2560, '')
    entry          _data, type='RAWT', c=4, size=2560, 0x000000: 
63,78,64,66,67,6c,78,64,66,66,67,6c,00           'cxdfglxdffgl.   '
    entry        _signed, type='BOOL', c=1, size= 1, data[0]: 1
    entry        _stereo, type='BOOL', c=1, size= 1, data[0]: 1

This is merely the number of audio frames, the number of bytes in a 
frame (is this even necessary?), the actual data, and a couple flags 
(signed vs unsigned, stereo vs mono). Is there a better way or is this 
a good general-purpose means of exchanging audio data? Any comments or 
suggestions would be highly appreciated.

--DarkWyrm

Other related posts: