21.07.11 23:34, Dan Dennedy написав(ла):
> 2011/7/19 Maksym Veremeyenko<ve...@m1stereo.tv>:
>> Hi,
>>
>> in my previous message about audio buffer overflow i did not noticed about
>> possible reason.
>>
>> IMHO one of reasons is too high priority of melted. That cause decklink
>> callback delayed if avformat producer has higher activity.
>
> The priority boosting is kind of a legacy thing when we were using
> BlueFish444 for SDI output and letting threads inherit scheduling
> priority and class - basically trying to make the process and all of
> its threads the same higher priority.
that could be good for Bluefish driver. that depends on driver
structure. Hence rising up priority to highest level makes impossible to
prioritize required thread - all inherited threads has highest priority.
>
>> To avoid it i prepared patch (*0001-change-priority-on-demand.patch*) that
>> enable maximum priority if it required by argument from command line, also
>> that makes possible to setup priority higher then default.
>>
>> After changing priority to default value no overrun happens.
>
> good, but I wonder if we should completely drop the priority-setting
> in melted.
i would leave it configurable as i proposed in a patch - at least it
makes possible to make a melted process i bit higher priority over xorg
for example...
moreover i would like to makes more experiments with ionice code to
makes a io priority higher over other smbd for example...
>> So next step was to increase a decklink callback thread priority over other
>> threads in MLT - *0005-rise-DriverNotificationThreadFunction-priority.patch*
>> - that could give additional benefits on decklink hardware control timings.
>
> Do you think this should this be controlled by a property? For example,
> if (mlt_property_get_int(properties, "priority")< -20)
>
this patch trying to increase a priority of internal Decklink callback
thread:
#0 DeckLinkConsumer::ScheduledFrameCompleted (this=0x80a61d0,
completedFrame=0xb642a398, completed=0)
at consumer_decklink.cpp:436
#1 0x02473753 in
CDeckLinkOutput::outputFrameCompletionCallback(unsigned int, char) ()
from /usr/lib/libDeckLinkAPI.so
#2 0x024533b3 in CDeckLink::DriverNotificationThreadFunction(void*) ()
from /usr/lib/libDeckLinkAPI.so
#3 0x00163e99 in start_thread () from /lib/libpthread.so.0
#4 0x00250d2e in clone () from /lib/libc.so.6
priority of this thread could be inherited from priority of
initialization code, so another possible solution is:
1. save current thread priority>
2. set new priority from mlt_property_get_int(properties, "priority")
3. init decklink
4. restore origin prio
what do you thing about this?
--
________________________________________
Maksym Veremeyenko
------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
