Re: yuv4mpeg API audio extensions

Hallo

> I've been contemplating the limitation of the yuv4mpeg stream format, in
> respect of its lack of audio support.
Is there a special reason why you want audio support in the yuv2mpeg 
stream ?

> It's occurred to me that (at least in theory) audio interleaving support
> could be added easily to the yuv4mpeg stream format, by having every nth
> frame be specially tagged, and containing raw audio data instead of
> video data.
> 
> For example, consider a PAL 4:2:0 frame, where the Y plane is 414270
> bytes long. Each frame has a time duration of 40ms (@25fps).
That is a common value. The mjpegtools can have a lot of different 
framerates, when you have a source a video from a digitalcamera 
recording at 15fps. And yuvfps can change the framerate.
That information is stored in the y4m_stream_info_t.

> If audio is sampled at 44100 samples/sec, as 16-bit stereo, then 40ms
> worth of audio would require 44100/25 * 4 bytes, which is 7056 bytes.
 >
> Therefore, with a specially tagged yuv4mpeg frame, the Y plane of 414270
> bytes could accommodate enough raw audio data to correspond to 58 video
> frames.
> 
> If the Cb and Cr planes are also used for stashing audio data, then you
> could store enough audio data for the duration of 86 video frames.
> 
> I'm willing to work on some patches to the mjpegtools yuv4mpeg api to
> add support for audio muxing/demuxing.
How would that change the audio applications (lav2wav and mp2enc)

> How does this idea sit with the mjpegtools community? I can implement
> this idea totally within my application layer (so it doesn't require
> yuv4mpeg api changes), or we can talk about how the API could be
> extended so as to cause minimal or zero breakage to existing apps.
 From a point of view you need to the the change y4m_write_frame, 
y4m_read_frame in a way that the audio data can be present.
So you would need to extend the stream info (y4m_stream_info_t).

Would it be possible to pass the Audio data along when you just use the 
y4m_read/write_frame. Well on a 2nd thought that does not seem possible.
So that means to me you would have to change every program that it 
passed the audio along. And understands the new data.

Or you just extend the y4m* functions with a 
y4m_read/write_frame_with_audio to get the audio. So no other program 
needs to be changed but does not pass audio through.

> Does this idea find some resonance among the mjpegtools developer
> community, or does it horrify, or something in between?
No problem at all.
I would be happy if you could provide some more information why you want 
to do it. And how, basically I have not problem with extending things.

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: [email protected]
www: http://www.lysator.liu.se/~gz/bernhard

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/