On Sat, 13 Jun 2009 03:18:11 -0400, Baptiste Coudurier
<baptiste.coudur...@gmail.com> wrote:
On 6/12/2009 11:55 PM, Michael Conrad wrote:
Well, libavformat likes to seek around and even close and reopen the
stream a few times during av_find_stream_info... which is very
unfortunate.
FYI it only seeks for MPEG PS and MPEG TS AFAIK to retrieve last pts and
get duration.
It closes and reopen the stream only when stream is not seekable.
However if you think not doing that is better and more efficient, I
think it would be possible to change it. Can you explain the problem you
experience or what you would like to do ?
I wish it would read the data once (from my custom URLProtocol) and then
re-use that data until codec detection finishes.
My source is a DVB capture device, so it is impossible to seek, but if I
set "treaming" mode then it needs more packets and it takes longer to
acquire enough for detection. So, I pretend it is a file, and implement
my own caching inside my URLProtocol. Once detection finished, I set a
flag which tells the dvb-reading thread to throw away the cache, so that
playback starts with fresh packets.
I guess it wasn't really that hard, but there are lots of unnecessary
copies from my buffers into the ByteIOContext buffer which could be
avoided if libav were holding that data internally.
slightly OT:
I know that optimal buffer usage can be a bit tricky when you've got
multiple layers of code accessing them, so for one of my personal projects
I've been writing a library that has reference counted buffers, "virtual
buffers" (composed of segments of other buffers), a "buffered stream"
which acts as a sliding buffer which reads from a data source and discards
portions that you no longer need, and the ability for multiple buffered
streams to read from the same data source. It will eventually be
thread-safe, too. My goal was to allow zero-copy designs while still
being friendly to work with. Would this be something libav developers
might want to incorperate? (it isn't finished yet, but I'd love an
additional reason to work on it)
--
Michael Conrad
IntelliTree Solutions llc.
513-552-6362
mcon...@intellitree.com
_______________________________________________
libav-user mailing list
libav-user@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
