[FFmpeg-devel] [PATCH] lavdevice: SDL Audio Playback
Mon Dec 14 01:32:55 CET 2009
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel