Fri Jun 19 14:21:38 CEST 2009
On Fri, Jun 19, 2009 at 03:04:36AM +0200, Erik Van Grunderbeeck wrote:
> av_read_frame_flush() is now defined static in libavformat/utils.c. Would
> there be any objection on making it public part of api?
in what cases is it neccessary for an user app to call it?
> Second question;
> For the DVD reading I am doing I need to find a way to flush (and remove)
> streams from the context once a new vob/cell starts. The best way I found to
> come up with this is "flag" the stream for removal, when a dvd vob
> transition is dedected in the client api. This way, when the demuxer finds a
> stream with the same id it can check if it needs to keep it, or just free
> the old stream and replace it with the new one. It's I think the path with
> the least (or no) impact on the current end-user functionality. Any feedback
> on this? It would involve adding a "flag" member to the AVStream structure.
Either way, please keep in mind that
1. We like to be able to also transcode the stuff
2. We like to be able to streamcopy the stuff (that is no decoder or encoder
just storing in a new container)
3. seeking can reset the end of stream stuff no matter how it is signaled
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel