On Wed, 13 Sep 2006 00:48:07 JST
[EMAIL PROTECTED] (Andrew Church) wrote:

> >Since we're talking about src/* content, feel free to comment/blame me
> >about new framebuffer code recently committed by myself.
> 
>      Okay, if you insist ;)  I was working on getting the tests in
> newtest.pl to pass again, and noticed that the "free" index and video_buf
> pointer in vframe_list_t are getting out of sync (the current code will
> output a "BUG" warning every time you start transcoding and fix the
> problem on its own).  Do you have any idea where that might be happening?

Yes I have a clue (see my very last commit). :)
I think that pops out from a misinterpretation of mine of
vframe_list_t.free field meaning.
I thought the meaning was exactly the opposite of truth :)

After a bit of thinking, the correct interpretation should be:
'free' field is the index of buffer that DOES NOT have the 'real'
video frame data  in the pair of buffers that vframe_list_t
carries (so it has 0/1 possible values).

example:
it's always safe to do

(having something like video_operation(source_buffer, dest_buffer))

as follows

vframe_list_t vf;
/* ... */
video_operation(vf.video_buf_Y[!vf.free], vf.video_buf_Y[vf.free]);
/* ... */
vf.free = !vf.free; /* that efficiently 'swaps' buffer [indexes].

I hope my english is good enough to express my thought here :)

If I'm right, my very last commit will fix this issue.

> >   * --keep_asr is now disabled, as the code implementing it is broken (it
> >>      doesn't interact properly with other options).  If you need to keep
> >>      the same aspect ratio, calculate the appropriate values manually.
> >
> >Maybe that should be reintroduced for 1.1.0? I'll take a look later to
> >figure out what's wrong (I've a very few clues right now :) ).
>      I don't know; I'd tend more toward dropping it completely, both
> because there's really no way to get it working (that I can think of)
> without making the interactions with -j -Z -Y etc. very confusing--
> remember all the trouble we had with export profiles doing the same
> thing?--and also because you can already use e.g. -Z 352x or -Z x288 to
> maintain aspect ratio when zooming, so there doesn't seem to be too much
> need for --keep_asr in the first place.

Mostly agree; I don't agree completely (yet) because I've not yet take a
look at the code :)

>      I'm pretty sure you're right about what it was supposed to do, but
> since libtc didn't pay it any attention it wasn't really meaningful. ;)
> It might still be a good idea to implement a switch like that, but that
> can be re-added after the code to handle it is in place, rather than
> trying to drag around old code that wasn't designed for it.

Fixing this should'nt be too much work, I'll append this task at the (very)
end of my TODO list :)

Best regards,

-- 
Francesco Romani - Ikitt ['people always complain, no matther what you do']
IM contact    : (email first, Antispam default deny!) icq://27-83-87-867
known bugs    : http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase
tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!)

Reply via email to