-->>Setup and usage<<--          
About Icaros
(03-03-2012, 12:55 PM)ganon Wrote:  Just a quick question. If I have the shark 007 codec pack installed do I still need to install Icarus for thumbnailing...?

No, it is included in the pack and can be accessed from the Config TAB.
To activate it, the app needs to be ran once as an Administrator.
Hi Xanashi,

I don't know how exactly your current implementation works internally or what you have planned for the upcoming version, but here are some suggestions that might help improve Icaros.

* Don't use the DirectShow graph builder, but instead manually construct a graph that contains LAV splitter and decoder. Look at the source code of GrahStudioNext if you are unsure on how to do that.
* The LAV filters have an API that allows you to programmatically override its settings. Those settings apply to the current session only and don't have any effect on the settings used for normal playback. Use this API to enable all formats in the splitter and decoder.
* Use a NULL renderer for all non-video streams. Could possibly avoid audio related problems, and might also be a bit more efficient.

Doing the above should give a stable and predictable solution, since it will always only uses LAV Filters.
It also provides more flexibility to people for normal playback. The only requirement is that LAV Filters is installed. It does not actually need to be used for playback. People may freely disable any formats and use other filters.
Hi BitTech,

Thanks for the suggestions.
You've pretty much summarized, what Icaros currently does, except for a few deviations.

Icaros does manually create it's own graph, but the reason why it's not stringently using LAV's decoder only,
is because some filetypes simply performed the operation faster while using MS' own decoders.
Icaros also uses the NULL Renderer for all streams, as that was generally,
what was suggested online, when using the SampleGrabber interface.

I actually hadn't thought about using LAV's API to set the settings on a session by session basis. Great suggestion.

The above behaviour should really have been described in past tense,
as I have, from the next version, and onwards, completely dropped DirectShow and gone straight to the source instead.

As you can imagine, this will be beneficial in more than one way. Tongue

Nevertheless, your suggestions and feedback are still much appreciated. Thanks.
OS: Windows 7 Ultimate x64
Could you perhaps release a new intermediate version that uses the LAV API before you drop DirectShow? I think it will solve problems that people are having now due to formats being disabled in LAV.

Just curious, which MS decoders perform better? FYI, LAV now is capable of using the MS decoder for VC-1.
Also, what happens if an MS decoder is disabled? Will it fall back to using LAV?

I assume since you are using manual graph construction, that you only allow filters that you know work properly? So no problem anymore with Xvid codec?

(03-05-2012, 10:25 AM)BitTech Wrote:  Could you perhaps release a new intermediate version that uses the LAV API before you drop DirectShow? I think it will solve problems that people are having now due to formats being disabled in LAV.

There is really no reason to do that. My current internal build, with updated core, is almost ready for distribution.
If I had to implement the LAV API, I would have to write an interop wrapper first,
which would just postpone everything even further.

(03-05-2012, 10:25 AM)BitTech Wrote:  Just curious, which MS decoders perform better? FYI, LAV now is capable of using the MS decoder for VC-1.
Also, what happens if an MS decoder is disabled? Will it fall back to using LAV?

When I say "perform the operation faster", it was not related to playback.
Icaros only needs a single frame from every video; sometimes using less complex codecs are simply just faster at the extraction process.
And speed is kind of vital for a thumbnail provider.

And yes, it should indeed fallback.

(03-05-2012, 10:25 AM)BitTech Wrote:  I assume since you are using manual graph construction, that you only allow filters that you know work properly? So no problem anymore with Xvid codec?

Correct! No problems at all. ;-)
OS: Windows 7 Ultimate x64
There is a typo in the program main page. I think the intended word was Proprietary instead of propterty file types registered.

Will report my test findings later. Stay tuned :-).

Ok Results:

improved speed of thumbnail generation to mkv and ogm filetypes (windows explorer now whines less before it starts generation of the thumbnails).

improved generation of flv filetypes (faster, cleaner, and no need to refresh explorer).

further results will be posted.
OS: Windows 7 Utlimate x64 SP1 (Build 7601).
Codecs: Haali Splitter, LAV filters (latest), MPC-HC, madVR, Reclock.
How can we prevent explorer lockups with invalid mkv files? Even with a 4kb file explorer reads hundreds of megabytes. what is the problem here?

An example of an invalid mkv : http://dl.dropbox.com/u/57867163/13.7z
@cengizhan
Thanks for the sample ^^
There was a small rather stupid bug in the mkv property handler. It will be fixed by the next release.
Until then you can just disable the mkv property handler.

Do you have other files with similar issues?

@Paladin77
Nope, no typo. I think you misinterpreted the functionality of those controls. Smile
The mkv, ogm and flv checkboxes are used to enable/disable Explorer properties for those filetypes.
(like the ones found in this image)

Thanks for the great feedback, both of you.
OS: Windows 7 Ultimate x64
Not now. But i am sure that i will encounter with those files again because of explorer's bad behavior against broken files.
(03-09-2012, 02:25 AM)cengizhan Wrote:  Not now. But i am sure that i will encounter with those files again because of explorer's bad behavior against broken files.

Hopefully I can make Icaros amend this behavior for most files. ;-)
Be sure to post samples if you come across more of these troublesome files.
OS: Windows 7 Ultimate x64




Users browsing this thread: 4 Guest(s)