[FFmpeg-devel] av_read_frame_flush

[Erik Van Grunderbeeck]

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

When the next vob you are going to get data from is going to have completely
different streams (restart timestamps, codecs, etc), with the same id's. The
use would be for the case below: 

1) user app flags streams as "to discard" after receiving signal from
control stream (vob/cell change), 

2) flushes the framereader with av_read_frame_flush(). 

All new streams then will get correct new start dts, etc. after they are
added and de-coding starts again.

I don't think this can be done with av_close_input_stream() (since that also
does a read_close()) and closes the context. I might be wrong?  

>> 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 
I will make all changes to ffmpeg and ffplay needed so that you can stream a
dvd straight to whatever container format is supported in ffmpeg.

>2. We like to be able to streamcopy the stuff (that is no decoder or
encoder
>   just storing in a new container)
That's going to be ok to, as long as the app get packets from the demuxer
giving some state information (ege cell/vob change).

>3. seeking can reset the end of stream stuff no matter how it is signaled
I am not sure I understand this one? 

There currently is an issue in my implementation because of the behavior of
the input stream after seeking. New packets can get introduced by the DVD
reader (ege seek to position x, the reader will send a packet saying "new
chapter" started). That conflicts with the packet reader who presumes that
the stream is complete in time (ie no changes will happen in the past).
Still looking at that. 

Erik