headers
John Brown | 1 Nov 2006 04:03
Picon
Favicon

Re: Mplayer + fontconfig + M$Win

John Brown wrote:
>
>
>>Victor Farias wrote:
>>
>>John Brown wrote:
>>
>>>I will try it as soon as I get home. Do you know why fontconfig, etc. 
>>>have to be shared libraries?
>>
>>It was the only way I could find to compile MPlayer with fontconfig 
>>support under Windows.
>>
>Actually, I succeeded in compiling fontconfig as a static library. It
>seemd that it was not working because:
>
>1) Although MPlayer's configure detected fontconfig,
>#undef HAVE_FONTCONFIG was in config.h. I changed it to
>#define HAVE_FONTCONFIG and I had to manually set
>FONTCONFIG_LIB = -lfontconfig -lexpat -lfreetype -lz
>
>2) I used the wrong command line. I left out the -fontconfig.
>
>So now everything works, except that there is a long delay
>each time that I run MPlayer. The link that you posted says
>something about this, so I will look into it when I get home.

If anyone is interested, this was because of a problem in fc-cache.
access(dir, W_OK) returned that it did not have write access
to the Windows font directory, which was not true, so it did not
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan | 1 Nov 2006 08:26
Picon

Re: Mplayer + fontconfig + M$Win

Thanks a lot :)

 >John Brown wrote:
Permalink | Reply | 0 comments |
headers
Nico Sabbi | 1 Nov 2006 09:33
Picon

Re: udp blockiness

Niklas Fondberg wrote:

>When using mplayer to view UDP MPEG2-TS content the video is macro
>blocky.
>The same stream MPEG2-TS plays fine from harddrive. 
>Could anyone point me in any direction?
>
>Niklas
>
>  
>

try to dump the stream received from udp and compare it to the original.
BTW, in svn I fixed several bugs that did negatively affect demuxing mpeg-ts
Permalink | Reply | 14 comments |
headers
Nico Sabbi | 1 Nov 2006 09:36
Picon

Re: Mplayer bug with several files

The Wanderer wrote:

>
> That might be a reasonable perspective, but it doesn't seem appropriate
> to give the same response in that situation as when the report is on a
> version more than a year old (which has happened - 1.0pre7try2 turned 1
> on August 26th). I'd agree with the use of "stone-age" in that case, and
> probably even in the case of 1.0pre8 (released June 11th), but a week
> and a half is not in the same category of ancient - no matter how fast
> and heavy the development has been in that period. (And, as a long-time
> lurker and sometime poster (and occasional contributor) on the
> development mailing lists, I can say that it doesn't look that much more
> fast-paced around here than usual.)
>

if you read -cvslog you will find a lot of patches committed between rc1 
and now
that fixed a lot of bugs
Permalink | Reply | 1 comment |
headers
Nico Sabbi | 1 Nov 2006 09:36
Picon

Re: Mplayer bug with several files

Alexandr Orlov wrote:

>Great, thank you very much! It works perfectly!
>
>P.S. Is this patch safe for other type of videos, not MPEG-TS?
>
>  
>
?? no
Permalink | Reply | 0 comments |
headers
Niklas Fondberg | 1 Nov 2006 09:54

Re: udp blockiness

I've tried to dump the stream and although I can't compare it exactly
because of the connectionless udp protocol I can view the stream without
errors from harddisk.

I will try the svn version.

I wondering if it has something to do with the streams being MPEG2-TS at
around 6-8Mbit/s and the buffer before the demuxer is not large
enough...

Niklas

On Wed, 2006-11-01 at 09:33 +0100, Nico Sabbi wrote:
> Niklas Fondberg wrote:
> 
> >When using mplayer to view UDP MPEG2-TS content the video is macro
> >blocky.
> >The same stream MPEG2-TS plays fine from harddrive. 
> >Could anyone point me in any direction?
> >
> >Niklas
> >
> >  
> >
> 
> try to dump the stream received from udp and compare it to the original.
> BTW, in svn I fixed several bugs that did negatively affect demuxing mpeg-ts
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users <at> mplayerhq.hu
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeremy Hansen | 1 Nov 2006 10:21
Picon

Re: Failed in Playing WMA file

> I can play WMA under PC, but I can't play WMA under uclinux of blackfin.
> I think that it is not related with version. Anyone has some idea on this.

Did you install the binary codecs? Also if you compiled mplayer as 64
bit, it cannot use the binary codecs. It is best to compile mplayer as
32 bit so you can use all the codecs.

Jeremy
Permalink | Reply | 0 comments |
headers
Jeremy Hansen | 1 Nov 2006 10:23
Picon

Re: udp blockiness

> I wondering if it has something to do with the streams being MPEG2-TS at
> around 6-8Mbit/s and the buffer before the demuxer is not large
> enough...

If it is the buffer, try setting a cache size.

Jeremy
Permalink | Reply | 0 comments |
headers
Nico Sabbi | 1 Nov 2006 10:36
Picon

Re: udp blockiness

Niklas Fondberg wrote:

>I've tried to dump the stream and although I can't compare it exactly
>because of the connectionless udp protocol I can view the stream without
>errors from harddisk.
>
>I will try the svn version.
>
>I wondering if it has something to do with the streams being MPEG2-TS at
>around 6-8Mbit/s and the buffer before the demuxer is not large
>enough...
>
>  
>
no.
Please, don't top post
Permalink | Reply | 2 comments |
headers
Niklas Fondberg | 1 Nov 2006 10:41

Re: udp blockiness

On Wed, 2006-11-01 at 10:36 +0100, Nico Sabbi wrote:
> Niklas Fondberg wrote:
> no.
> Please, don't top post

What do you mean???
Permalink | Reply | 1 comment |

Gmane