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

[Michael Niedermayer]

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 ...


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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/7a49239a/attachment.pgp>