Open LPSTREAM* method in splitter

[GoogleCodeExporter]

Describe the issue you're having:

I would like to play files from ZIP-7ZIP-RAR archives or ISO files. Currently 
the splitter offers a method to load a file path. There is no support for a 
stream. This essentially impedes such a use of the splitter.

How can the issue be reproduced? Sample File?

It is not an issue but a usability problem.

What version of the product are you using? In which Player?

0.51 custom player written in C#

Please provide any additional information below.

It would be very cool if the splitter had a method similar to this:

STDMETHODIMP CLAVSplitter::Load(LPSTREAM *pStream, LPCOLESTR pszFileExtension, 
const AM_MEDIA_TYPE * pmt)

And then use the pStream instead of creating one from filename. Here I 
suggested using a stirng for extension since this helps choosing the demuxer. 
It would probably need changes to demoxers to use a stream too.

But the usability of LAV would increase greatly.

Original issue reported on code.google.com by marino.simic@gmail.com on 28 Apr 2012 at 10:18

[GoogleCodeExporter]

Just as a note: C# can use LPSTREAM with the interop type ComTypes.IStream

Original comment by marino.simic@gmail.com on 28 Apr 2012 at 10:21

[GoogleCodeExporter]

I have no plans to support any non-standard data handling/opening functions.

If you want to interface any odd source, i suggest you write a small source 
filter that implements the IAsyncReader interface, that way there is a 
well-defined way to interface with any sort of DirectShow splitters.

Original comment by h.lepp...@gmail.com on 29 Apr 2012 at 6:08

• Changed state: WontFix
• Added labels: Component-DirectShow, Filter-Splitter, Type-Enhancement, Usability
• Removed labels: Type-Defect

[GoogleCodeExporter]

Even if it is done it would be a non transparent way of doing it with 
performance penalties.

For example if decompression is done in C# the filter would need a LPSTREAM as 
input to read and it should fill media samples to deliver to the next filter. 
This already defeats "general purpose" since it is not a filesource filter 
anyway and cannot be used by any player that does not know how to feed it.

However I've looked a bit through the source and it seems that this is a 
limitation of ffmpeg and this is why the filename is passed around instead of 
opening a file stream at the start of Open(string filename).

So I see that this would be a complete mess to do.

That is unfortunate :(

Original comment by marino.simic@gmail.com on 29 Apr 2012 at 10:52

[GoogleCodeExporter]

LAV only needs a small subset of the IAsyncReader to function, basically 
SyncRead and Length. Writing a thin wrapper around whatever source you have and 
providing those two functions should be easy.

Its a pull-mode filter, it just acts as an abstraction around file I/O, and 
since LAV at least doesn't need the actual "async" I/O, the implementation 
should be easy enough.

Original comment by h.lepp...@gmail.com on 29 Apr 2012 at 12:03

[GoogleCodeExporter]

I managed to code something that can enter the filter graph in c#.

But I am not able to connect it to the LavSplitter.

I dont know what to do in these methods:

 public int EnumMediaTypes(out IEnumMediaTypes ppEnum)

and

 public int Connect(IPin pReceivePin, AMMediaType pmt)

Anxy help apreciated!

Original comment by marino.simic@gmail.com on 29 Apr 2012 at 8:56