Possible to restrict an addon (ffmpeg.exe) fo a file type?

[klaus2]

I tried to use XnviewMP win 0.81 as a browser for video files on windows 7 x64.
I don't want to install any additional codec packs, and normally i don't need them at all
(my player media player classic home cinema has it's own builtin decoders).
Problem:
+ Nearly all works very fine, eg. I have thumbnals and a good preview or MP4 files
- However. i have no thumbnails for FLV files (whereas those are previewed very fine!)
Possible solution:
to use ffmpeg.exe placed beyond the addon subdirectory (AddOn\ffmped\ffmpex.exe)
That basically works.
Drawback:
Now, all video files (eg. all MP4 files too) appear to be processed by ffmpeg.exe,
which noticeably slows down the creation of thumbnails - the xnviewmp builtin decoder
appears to be much faster than using the ffmpex.exe within 'AddOns'.
So my question:
is it possible to tell XnviewMP to use a certain addon (here: ffmpeg.exe)
for a specific file type resp. extension only (here: .flv), but not for others
(becuase for those others XnviewMP itself behaves better) ?

[XnTriq]

Please check out MP's latest beta and the newly introduced UI-less setting, klaus2.

[klaus2]

Hm, i tried the beta and the minimalistic ini file showm within the thread mentioned ( Mon Jul 18, 2016 2:45 pm ),
but i cannot see any different behaviour.
(however i see a certain difference using videoMode=true vs. false -===> no previews (without regard of
having the AddOn ffmpeg.exe or not).
After each test i removed the thumbs.db for cleanup.
XnTriy, what did you exactly expect using the test case mentioned? FLV zhumbnailed wihout a need of ffmpeg.exe?

[XnTriq]

Thanks for your tests, klaus2.

XnTriy, what did you exactly expect using the test case mentioned? FLV zhumbnailed wihout a need of ffmpeg.exe?

Starting with v0.80, MP is using QtAV which – in turn – is based on ffmpeg.

Currently i test a component based on ffmpeg librairies to avoid all video playing problems.

This version use now QtAV (based on ffmpeg) for video playing, no more need to install video codec.
If you have problem, you can go back by changing

Code: Select all

videoMode=true

I was wondering if MP might go into some kind of “fall-back mode” and maybe use \AddOn\ffmpeg.exe instead of \QtAV.dll if videoMode is set to true, but let's wait for Pierre's answer to your question.

is it possible to tell XnviewMP to use a certain addon (here: ffmpeg.exe) for a specific file type resp. extension only (here: .flv), but not for others (becuase for those others XnviewMP itself behaves better) ?

[klaus2]

XnTriq, thanks!
I feel that the builtin ffmeg adoption is basically able to deal with FLV files (as they are previewed and played very fine!).
I fell as well that probably the thumbs are not created using that capability, but maybe?? picked up from the
windows exploer (here, they are appearing as the system icon attached to the file extension .flv. I need to underline
that i don't want use additional codec packs. Quite expectedly, within the Windows explorer, those system icons are used
as thumbs as well (as there is no specific codec installed), in difference to the thumbs for MP4 files. Same like using XnviewMP.
Using an addon exe for the flv files would be quite good for me, but it should not catch the processing of thumbnails for
ALL video file types. Can XnviewMP do an IF-branch here?).

[klaus2]

Hi XnTriq:
No thumbs for AVI files either (without codec pack).
For WMV files they are fine.
With AddOn\ffmpeg\ffmpeg.exe i have both . but the cost is an overall slowdown of the thumbnail creation.
I think thumbs for the common video file types AVI and FLV should be available with builtin means without codec packs.
What do you think?

[XnTriq]

Sorry for the delay, klaus2.

Using an addon exe for the flv files would be quite good for me, but it should not catch the processing of thumbnails for ALL video file types. Can XnviewMP do an IF-branch here?).

I think thumbs for the common video file types AVI and FLV should be available with builtin means without codec packs.
What do you think?

I absolutely agree, but I don't know if that's feasible. Pierre?

[Erixx haxx]

Hello:

Just my opinion, but you're better off to install and use a codec pack. everything use them. Win media player, Win explorer, all use them.

-When you use installed codec packs then other software can share the same codec. ( If Programed with windows open api ). It works on a merit system to pick the better one.
-When you use built in codec, then each different software has to have its own codecs and can't share with other software.

There is a trade off for either way you go, but if you get a well known pack you'll have less worries latter on.
If Mp is using win api (I Think so), and your not seeing thumbs inside win explorer. Then you won't see them inside MP, unless you use ffmpeg or get codec's.

[klaus2]

Hi!
I think there are pros and cons about codec packs. Oftenly there are known to cause trouble.
And who will decide which one to use? Cution, they are deep into the system.
Personally i don't need them. For playing there are good specialists (MPC-HC), for cutting also (Avidemux),
and for browsing MP is really fine with video, except the thumbs for FLV and AVI, although MP has it's
own code to read them very good; so it should not need those codec pack at all ....
--
For test i installed K-Lite, and now i have the thumbs within Win Explorer (which i don't care about),.
... but all thumbs within MP are lost now! But i don't want to raise config issues about k-lite here.
I deinstalled the pack again (and got the MP thumbs back, except flv and avi ...).
-
If thumbs for some video file types are not suppoerted, but the ffmpeg.exe is able to handle them,
why not calling this Addon ONLY for files for which the thumbs are missing ??

[Erixx haxx]

Hello:

For test i installed K-Lite, and now i have the thumbs within Win Explorer (which i don't care about),.
... but all thumbs within MP are lost now!

Then you did something wrong here. Maybe a restart or setting in MP. or wrong x32 / x64 bit version codec pack

although MP has it's own code to read them very good;

Mp was using windows api, (codec packs) But something changed here in the last 2 versions that I haven't read about yet. (QTAV)
I'm using current 0.82 beta and codec pack and get all thumbs. Nothing has changed for me.

The big thing for me is when using built in codecs they all mostly written by the dev and view and playback different. Also when you run across software written to use
the windows api then you need to install the codec packs anyways.

[klaus2]

HI Erixx haxx,
again, there are pros and cons. Who will decide what is the right pack? the right version? and who is guilty in the case of trouble?
And, beyond this thumb issue i have none needs for those packs, for none application. Most media specific apps come with their own builtin decoders. I like that. There are diverse opinions/preferences about that around.
The pack was 64 bit and installed by default, nothing special. What might have been done wrong here?
The thumbs within Explorer (don't cara about) showed up immediately.
-
Did a retest using the pack and need to correct myself:
MP 64bit version 0.81 did show up the thumbs indeed.
MP 32bit version 0.81 (didn't retest with the betas) lost all thumbs (except for WMV).
MP was each time restarted and the thumbs.db cleaned resp. removed before.
(i'm quite sure that somebody will say that one must not use the 32bit version on 64bit wiendows. Normally that works!)
-
Btw, did a aheck with the older version 0.72 /without codec pack), and there was no different behaviour (no thumbs for flv and avi).
I have a question about that: for MP4 files, how the current MP version retrieves thumbs? Using it's builtin code resp. a ffmpeg adoption?
If yes: can it detect if a thumb can be retrieved or not? If yes, can it call the Addon ffmpeg.exe only if this thumb is not available?

[xnview]

XnView try with directShow to retrieve the thumb, and if ffmpeg.exe exists use it

[klaus2]

Does it know whether the call to DirectShow fails, resp. returns a system icon instead of a real thumb?

[xnview]

Does it know whether the call to DirectShow fails, resp. returns a system icon instead of a real thumb?

you have ffmpeg.exe in Addon folder?

[klaus2]

Yes Pierre, exactly as AddOn\ffmpeg\ffmpeg.exe (location and name are relevant, otherwise it is not called).

-Meanwhile, as i'm very interested in performance and so now focused on this issue, i did a performance test. You might be interested in the results:
Wini 7 x64, XnviewMP 0.81 64bit, "codec pack" = k-lite 12.30 basic, contains 32 and 64 bit
Testcase: 100 files (mostly mp4, some flv) , 5 gb in total within one directory
Runtime for the creation of thumbs:
-- using AddOn/ffmpeg/ffmpeg.exe: 25 secs ====> __when codec pack is installed__
-- using codec pack: 15 secs
-- using AddOn/ffmpeg/ffmpeg.exe: 14 secs - ====> __when codec pack is NOT installed__
-- MP native = without pack, without ffmpeg.exe: 9-10 secs ....Very very fine!! but no flv thumbs
-
Drastic!! My conclusions are:
1. Using ffmpeg.exe when the codec pack is installed, is a performance killer
2. From the performance point of view, you have no loss when using ffmpeg.exe instead of the codec pack;
the recent version is even slightly faster.
3. The absolute Winner is XnviewMP itself without using codec pack. The speed diff is impressive!
-
This leads me back to my original question:
for to keep the speed of thumb createkion, can MP determine a failure of the call of DirectShow
and invoke ffmpeg,exe (if it exists) only in the case of such a failure (system icon instead of thumb)?
If not: suggestion: spend an optional key like: "use_addon_ffmpeg_for_types=flv,avi" or similar.