Evan Hisey wrote:
> Duncan-
> The mplayer version should be fine, just that the systems I compile
> on do not have the xvid or lame libraries. I just compile a version
> mplayer with the minimal set of extra libraries I can. Every library I
> have to add is one more I will have to keep updated. Most of the
> problems I have encountered seem to relate to changes between 1.6.2
> and 1.7.3 default settings
>
> output from command :
>>>> v.snapshot('/mnt/freevo/09-07_13_00_Tales_From_the_Darkside_-_I_Can_t_Help_Saying_Goodbye.avi')
> no imagefile found
> /root/.freevo/vfs/mnt/freevo/09-07_13_00_Tales_From_the_Darkside_-_I_Can_t_Help_Saying_Goodbye.avi.raw.tmp
>
> No errors and there is nothing in /root/.freevo/vfs/mnt/freevo/
Okay I wonder if you have png support in mplayer?
The thumbnail is generated by:
mplayer -nosound -vo png -frames 8 -ss 50 -zoom
/freevo/09-07_13_00_Tales_From_the_Darkside_-_I_Can_t_Help_Saying_Goodbye.avi
The number after the ss is calculates as 10% of the size of the file.
> If freevo is going to require mplayer built with extra library's
> beyond what mplayer provides, then those are going to need to be
> listed as required on the Freevo source and dependency pages. Has the
> thumbnail code changed from the 1.6.2 release? Or rather does it
> expect different mplayer options?
Yes it seems to need more than just libavcodec exactly what depends on
the hardware.
The thumbnails code hasn't changed at all for quite a while, basically
the change from mmpython to kaa.metadata.
Duncan
> On 9/7/07, Duncan Webb <[EMAIL PROTECTED]> wrote:
>> Evan Hisey wrote:
>>> I am unable to get the thumbnails to show up for show in 1.7.3. I am
>>> attempting debug the problem.Showing up in the log is:
>>> no imagefile found
>>> /root/.freevo/vfs/mnt/freevo/08-05_19_00_Human_Weapon_-_Eskrima.mpeg.raw.tmp
>>>
>>> while the files listed in /root/.freevo/vfs/mnt/freevo/ all end in
>>> .fxd.raw. It appears that freevo is looking for the wrong files when
>>> looking for thumbnails.
>> I doubt that this is happening. The recordserver creates an image with:
>> vfs.getoverlay(prog.filename + '.raw.tmp'
>> and videothumb read it with vfs.getoverlay(videofile + '.raw') and a bit
>> later on appends a ".tmp". With the same function vfs.getoverlay you
>> _should_ get the same path. And if it was other people would have
>> reported it by now, hopefully.
>>
>> How big are your thumbnails, they should be 182790 bytes. I wonder if
>> your version of mplayer is not okay from the other messages about
>> -lameopts and -xvidopts.
>>
>>
>> try this:
>> freevo prompt
>> import util.videothumb as v
>> v.snapshot('/path/to/video')
>> ^D
>>
>> you should have a .raw.tmp file somewhere /root/.freevo/vfs/path/to/video.
>>
>> Duncan
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Freevo-devel mailing list
>> Freevo-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freevo-devel
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Freevo-devel mailing list
> Freevo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freevo-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
