[FFmpeg-devel] [PATCH] lavdevice: SDL Audio Playback

[Michael Niedermayer]

On Mon, Dec 14, 2009 at 01:19:24AM +0100, Michael Niedermayer wrote:
> On Sun, Dec 13, 2009 at 07:44:27PM +0100, Ivo wrote:
> > On Wednesday 09 December 2009, 22:50:30, Michael Niedermayer wrote:
> > > On Tue, Dec 08, 2009 at 02:56:48PM +0100, Ivo wrote:
> [...]
> > > would be the obvious thing to do
> > > the alternative would be to wait until AVFilters support audio and then
> > > implement audio out as an audio filter
> > >
> > > > Video out formats should have functions
> > > > like draw_osd, get_buffer (for direct rendering) and flip_page. If
> > > > write_packet is used/defined to write full frames, something like
> > > > draw_slice would be useful too. Both video and audio out formats need a
> > > > control function to control for example hardware treble/bass/volume/pan
> > > > or hardware chroma/luma/saturation etc.. Also, a function to capture
> > > > events (IR remote control, keypresses, mouse movements) and send them
> > > > back to the application would be useful too. Perhaps by calling a user
> > > > supplied callback function that processes the event.
> > >
> > > You seem to be thinking of writing video out based on the muxer API, this
> > > is an option for sure. But maybe avfilters are more appropriate as they
> > > already have direct rendering & slice support. Also control commands
> > > could be easily intercepted by a brightness changing filter when the
> > > hardware doesnt support it.
> > >
> > > but above all, we need ffplay updated for whichever system is choosen or
> > > we wont have a player to test anything ...
> > 
> > Yes, the next step after SDL audio and video out would have been to update 
> > ffplay. But before first we need to decide whether we want to further 
> > implement audio out as muxers, which would make it logical to implement 
> > video out as muxers too, so they both can be used without having a lavfi 
> > dependency. To have muxers at the end of a filter chain could be done 
> > similarly to mplayer, i.e. by creating vf_vo and af_ao filters. (or maybe 
> > even vf/af_muxer).
> > 
> > Or, as you said, we could move over all audio out to lavfi and implement 
> > video out there too. I'm not sure if that's a good idea though as it 
> > creates an extra dependency and logically lavdevice audio/video in should 
> > be filters/generators too, no?
> 
> My gut feeling says something close to filters is better than (de)muxers.
> But we have no audio filter code yet ...

so i guess implementing audio as (de)muxers is the only option, just keep
in mind that this stuff should be moved over to the filter system once it
can handle audio.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091214/d7b64bee/attachment.pgp>