On Mon, 2009-01-12 at 13:18 +0100, Georg Martius wrote:
> Hi,
> I think there is a better way to deal with it. Why not having a FIFO at each
> edge of the tree. Each node runs in its thread and basically asks the
> upstream FIFO(s) for a frame and processes it and stores it in the downstream
>
Hi,
On Sunday 11 January 2009, Francesco Romani wrote:
> I do agree completely.
> I've thought a bit more on this subject, and quickly come out with the
> following: a low-hanging fruit *seems to be* to use double buffering for
> work buffers:
>
> typedef struct tcprocessingnode_ TCProcessingNode;
On Sun, 2009-01-11 at 19:40 +, Andrew Church wrote:
> >Sounds good.
> >So, I volunteer for maintining the legacy code (the current src/*
> >stuff).
>
> Then I guess I'm tapped for the new code, huh? (: Well, I'll see how
> my work schedule looks, but I should be able to contribute something,
>Sounds good.
>So, I volunteer for maintining the legacy code (the current src/*
>stuff).
Then I guess I'm tapped for the new code, huh? (: Well, I'll see how
my work schedule looks, but I should be able to contribute something,
at least. Plus it looks like fun to try. (:
>One of the constraint
On Sun, 2009-01-11 at 00:08 +, Andrew Church wrote:
> >Since we're talking about radical changes, and since there is a
> >repository change in sight, what I'm proposing (and what I *really* like
> >to do) is to do a fresh start.
>
> I'm absolutely in favor of that, and agree that it's probably
>Since we're talking about radical changes, and since there is a
>repository change in sight, what I'm proposing (and what I *really* like
>to do) is to do a fresh start.
I'm absolutely in favor of that, and agree that it's probably needed
anyway. I try not to think about how many headaches trans
On Sat, 2009-01-10 at 16:14 +0100, Georg Martius wrote:
> Hi again,
>
> I just realized that I confused the terms here. Please replace "Processing
> Node" by "Processor Item" in my previous email.
> Sorry!
In facts, I found "Processing Node" is a better name than "Processor
Item" :)
Bests,
--
On Sat, 2009-01-10 at 12:13 +0100, Georg Martius wrote:
> Hi Francesco,
>
> You know that I am rather new to transcode so please keep this in mind when
> reading my comments ;-)
It's good to hear something new :)
> I just want to say that I like the idea to have a sequence of processing
> node
Hi again,
I just realized that I confused the terms here. Please replace "Processing
Node" by "Processor Item" in my previous email.
Sorry!
Georg
On Saturday 10 January 2009, Georg Martius wrote:
> Hi Francesco,
>
> You know that I am rather new to transcode so please keep this in mind
Hi Francesco,
You know that I am rather new to transcode so please keep this in mind when
reading my comments ;-)
I just want to say that I like the idea to have a sequence of processing nodes
with little streams between each node.
I would like to add that also the properties structures have to
On Wed, 2009-01-07 at 10:39 +, Andrew Church wrote:
> I think you're misunderstanding my approach. It's not an issue of
> "more" or "less" frames; I want to treat the two streams of frames as
> entirely separate, so filters are free to add, delete, reorder, delay
> (as with smartyuv and such),
>On Wed, 2009-01-07 at 19:48 +0100, Francesco Romani wrote:
>> On Wed, 2009-01-07 at 10:39 +, Andrew Church wrote:
>> > >What we essentially need is a safe way for a filter _plugin_ (while I
>> > >was referring to the core part handling the filtering) to deliver N
>> > >*more* (cloned) frames t
On Wed, 2009-01-07 at 19:48 +0100, Francesco Romani wrote:
> On Wed, 2009-01-07 at 10:39 +, Andrew Church wrote:
> > >What we essentially need is a safe way for a filter _plugin_ (while I
> > >was referring to the core part handling the filtering) to deliver N
> > >*more* (cloned) frames to the
On Wed, 2009-01-07 at 10:39 +, Andrew Church wrote:
> >What we essentially need is a safe way for a filter _plugin_ (while I
> >was referring to the core part handling the filtering) to deliver N
> >*more* (cloned) frames to the core, right?
>
> I think you're misunderstanding my approach.
U
>What we essentially need is a safe way for a filter _plugin_ (while I
>was referring to the core part handling the filtering) to deliver N
>*more* (cloned) frames to the core, right?
I think you're misunderstanding my approach. It's not an issue of "more"
or "less" frames; I want to treat the tw
On Tue, 2009-01-06 at 18:07 +0100, Francesco Romani wrote:
> On Tue, 2009-01-06 at 23:14 +, Andrew Church wrote:
>
> > >like we already do?
> > >(our current code is not that different, see for example
> > >frame_threads.c , and vframe_reserve/vframe_push_next and their
> > >implementation)
>
On Tue, 2009-01-06 at 23:14 +, Andrew Church wrote:
> >like we already do?
> >(our current code is not that different, see for example
> >frame_threads.c , and vframe_reserve/vframe_push_next and their
> >implementation)
> >
> >In a nutshell, why can't just pass away the old frame recycling it
>Ok, understood, but why we can't just continue doing
>
>while (have_frames(MY_POOL_ID)) {
>FrameBuffer *frame = framebuffer_get(MY_POOL_ID);
>do_some_processing(frame);
>frame->id = my_frame_num++;
>framebuffer_put(frame, NEXT_POOL_ID); // the frame->status switch is
>
On Tue, 2009-01-06 at 21:34 +, Andrew Church wrote:
> >If I understood correctly, you're worried about the need to do a full
> >copy of a frame when it's cloned, given this new model, am I right?
>
> Not just for cloned frames, but for every frame in the resulting stream.
> Under the basic mod
>> What I think we can do is
>> have the wrapper for each module's process function return the frame
>> buffer to the free pool after the function returns, e.g.:
>>
>> tc_filter_process(ptr);
>> framebuffer_free(ptr);
>>
>> and have each module allocate a new frame buffer for each frame
On Tue, 2009-01-06 at 19:37 +, Andrew Church wrote:
> >Problem #1: Skipped Frames/holes into frame ID sequence.
> >
> >Problem #2: The handling of cloned frames.
> >--
>
> I just grabbed those and t
>Problem #1: Skipped Frames/holes into frame ID sequence.
>
>Problem #2: The handling of cloned frames.
>--
I just grabbed those and threw them together because I think they're two
sides of the same coi
Hi there.
1.1.0 is on the road again, so green light for HEAD hacking :)
I wrote down how the sliding window approach for the export buffer (cfr
"psu mode problem with 1.1" thread for the background) and in the end
the document was simple enough. I made a few tests (on paper) and
everything seem
23 matches
Mail list logo
