0.7.3 Branch

[s55]

Guys, theres some very wierd things happening on this branch on windows

100% solid cpu usage for 5%, 10fps. after around 5% cpu usage is 90~100 fps of 90 odd. Then its solid 100% cpu again, 10fps solid.


hbtest.exe -i "D:\VIDEO_TS" -o "C:\Documents and Settings\Scott\Desktop\test.mp
4" -t 2 -l 576 -w 720 -e ffmpeg -E faac --crop 0:0:0:0 -S 400 -B 128 -R 48000

ffmpeg is acting really wierd when encoding. Havnt done full testing yet though

[johnallen]

how is hb_thread_init implemented in the windows build? Are the thread priorities being used?

[s55]

i have no idea. Mirkwood might have a better idea.

I thought i'd just let u know that something changed and somethings causing very unusual encoding behavior.

Seems to mostly occur with ffmpeg, will test x264 /xvid tomorrow

[mirkwood]

after around 5% cpu usage is 90~100 fps of 90 odd.

I have no idea what you're saying here. Can you please try again without the typos?

[mirkwood]

I think I see what you're saying, my ffmpeg encode is goin at only 5fps to start, then goes up to 60fps, then goes way back down.

This was working fine recently, ffmpeg encodes would always go fast. So something in the new barrage of checkins has probably screwed it up, maybe a new contrib lib or some changes to libhb.

Can someone on a Mac please try this?

[s55]

what you said is what i tried to say

[prigaux]

Humm I saw this too, but only when outputing a mp4 file, no problems with .avi and .ogm.

Philippe

[s55]

Yeh. Avi seems ok

[ads@csl.com]

Guys, theres some very wierd things happening on this branch on windows

100% solid cpu usage for 5%, 10fps. after around 5% cpu usage is 90~100 fps of 90 odd. Then its solid 100% cpu again, 10fps solid.


hbtest.exe -i "D:\VIDEO_TS" -o "C:\Documents and Settings\Scott\Desktop\test.mp
4" -t 2 -l 576 -w 720 -e ffmpeg -E faac --crop 0:0:0:0 -S 400 -B 128 -R 48000

ffmpeg is acting really wierd when encoding. Havnt done full testing yet though

If it relies heavily on threading - and in particular preemption - windows is very poor at this. It tends to starve threads pretty severely. ie If you have 16 identical threads, you won't get anything like a even distribution of CPU. On a mac, you will.

[mirkwood]

prigaux, you're seeing this problem and you're using a Mac, right?

This happened after some contrib libs were upgraded, so I think it's related to one of those, but haven't looked into details.

[prigaux]

Well, no actually what I see on my mac is that ffmpeg start at say 15fps and then the threading delay adjust itself and the fps grow up to 140fps.

It don't seems to fall back to slower fps.

I was buzy on the pixelratio, I will try to understand why the MP4 hang at 100% and I would like to see if the hanging occur in the trunk too..

After that, the next test is to use the contrib from the trunk and see...

Philippe

[mirkwood]

If it relies heavily on threading - and in particular preemption - windows is very poor at this. It tends to starve threads pretty severely. ie If you have 16 identical threads, you won't get anything like a even distribution of CPU. On a mac, you will.

I don't think this is true at all. I'm not an expert in threading models on Windows and OSX, but I consulted with someone I know that's is much more involved with threading than.

What experience have you had that leads you to believe Windows is worse at balancing threads?

There's an article here that has some interesting information on threading performance on Mac OSX vs Linux, pointing to problems in OSX: http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=1

[prigaux]

Well, I did some testing the MP4 100% doesn't occur on the trunk.

It don't occur on trunk + contrib lib upgraded from 0.7.3 neither...

So there was some modification that cause the hanging in the libhb folder, I continue to investigate this...

Philippe

[ads@csl.com]

What experience have you had that leads you to believe Windows is worse at balancing threads?

My experience is the preemption is poor. Try this little testbed on Windows and Mac. Whats concerning is on windows, 1 thread gets run, the others are largely starved (they execute less loops). This is in line with my experience just using threads on windows so I wrote this little test which just confirmed it for me.

Adam

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <math.h>

#ifdef WIN32
#include <process.h>
typedef int pthread_t;
#define pthread_create(A,B,C,D)         _beginthread(C, 0, (void *)D);
#define pthread_exit(A)					_endthread()
#else
#include <pthread.h>
#endif

#define FALSE   0
#define TRUE	!FALSE
#define NUMTHREADS  64

/* a tight spinning loop */
#ifdef WIN32
void __cdecl
#else
void *
#endif
spinwork( void * lpParameter )
{
    int *running = (int *)lpParameter;
    float val = 1;
    int count = 0;

    while (*running)
    {
        val = (float)sqrt(val);
        count++;
    }

    fprintf(stderr, "%d loops\n", count);

    pthread_exit(0);
}

int 
main(int argc, char * argv[])
{
    int i;
    int running = TRUE;

    /* kick off a bunch of threads */
    for (i=0; i<NUMTHREADS; i++)
    {
        pthread_t athread;
        pthread_create(&athread, NULL, spinwork,(void *)&running);
    }

    fprintf(stderr,"threads running; waiting for <cr>\n");
    getchar();

    fprintf(stderr,"threads stats; waiting for <cr>\n");
    running = FALSE;
    getchar();

	return 0;
}

[prigaux]

Hi all,

I have created a new branch as the 0.7.3 seems to be screwed somehow and I needed to try the pixelratio with latest contrib a bit more confortable.

So if you wish, you can try the pixelratioworking branch this one is:
trunc + pixelratio+latest libs..

Philippe