JyotsnaT / xuggle

Automatically exported from code.google.com/p/xuggle
0 stars 0 forks source link

queryStreamMetaData with stream index arg #120

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Currently queryStreamMetaData either reads all stream metadata or reads 
metadata for whatever packets have been read (depending on how you call 
IContainer.open).  Doing it the latter way is more flexible, but it leads to 
having to cache packets during setup (for example, I modified Converter.java 
to support non-blocking IContainer.open and ended up having to cache 
packets).

Can we have an alternate queryStreamMetaData that takes a stream index?  It 
would read ahead only until it finds a packet for the stream in question, 
meanwhile caching them internally for getNextPacket (like it currently does 
when it gets meta-data for all streams).  If the stream index matches a 
packet that's already been read, then it queryStreamMetaData wouldn't read 
ahead at all.  This is a kind of middle-ground between the all or nothing 
queryStreamMetaData we currently have.

This is what I'm currently doing in my modified Converter.java that's very 
similar to what I'm describing:

private void queryStreamMetaData(IContainer container, int streamIndex) {
    int currStreamIndex= -1;        
    IPacket iPacket;

    /**
     * If we've already read a packet of this stream then just return
     */
    if (seenStreams.contains(streamIndex)) {
        return;
    }

    /**
     * Read (and cache!) packets until we see one for the stream we we're 
interested in.
     */
    while (currStreamIndex != streamIndex && (iPacket= 
makeAndReadNextPacket(container)) != null) {
        cachedPackets.add(iPacket);
        currStreamIndex= iPacket.getStreamIndex();

        seenStreams.add(currStreamIndex);
    }
}

Original issue reported on code.google.com by paleozogt on 13 May 2009 at 11:28

GoogleCodeExporter commented 9 years ago
Hi there,

So We think we understand this request, but at the moment we're not going to 
add it.
 You can implement the same functionality in your code.

If we get more input on this, we'll consider it -- but a general case solution 
would
require some significant testing.

Original comment by art.cla...@gmail.com on 15 Jun 2009 at 7:45

GoogleCodeExporter commented 9 years ago
Not going to happen; moving to WontFix list.

Original comment by art.cla...@gmail.com on 16 Jan 2010 at 2:59