-
Hi,
(this build error has already been signaled on this forum, but not seems to have been addressed yet)
There is an inconsistency in src/main.cc which makes mp3blaster-3.2.3 not build with the --with-pth option (and no other), with the following error :
main.cc: In function ‘int main(int, char**, char**)’:
main.cc:5401: error: ‘struct main(int, char**, char**)::_tmp’ has no...
2007-02-24 15:36:27 UTC in Mp3blaster
-
Ok, it's more like a typo...
It is in 0.5.0, and CVS.
In FindBestMatch() only, not in FindBestMatchSubp(), which looks correct.
libdirac_motionest/block_match.cpp, lines 267-292:
for (size_t lnum=0 ; lnum<cand_list.size() ; ++lnum )
{
cand_mv = cand_list[lnum][0];
cand_costs.mvcost = GetVar( mv_prediction , cand_mv );
// See whether we need to...
2004-12-22 10:18:45 UTC in Dirac
-
Well, it seems clever.
On a different topic: I would have a suggestion, or a question, about the subpixel ME.
There is the reference frame, a block B in the current frame, the mv with pixel accuracy.
Then only the reference frame is upsampled.
Since the block B is never upsampled, the matching is done at pixel accuracy, through a linear interpolation.
In other words: the upsampled picture...
2004-12-15 01:54:53 UTC in Dirac
-
Hi,
> which is 278, which needs more than 8 bits. This is
> because the sum of the +ve coefficients is 280, not
> 140, as the filter is symmetric. Problem!
Yes, you're right.
> So what I'd suggest is that the intermediate values are
> clipped to 16 bits (or 18 if you're working with 10-bit
> video) before doing the bitshift back down to 8 (or 10)
> bits.
2004-12-09 16:02:55 UTC in Dirac
-
Sure.
However, the bandwidth available on the RAM blocks on the Virtex II is limited. In particular, it is easy to read 4*8 or 4*9 bits a a time. But reading 4*10 bits at a time is a hassle.
Indeed, the blocks have I/O ports that are 36 bits wide. If I want to optimize a little the throughput of the design, I do *not* want to read 10-bit values...
Cheers,
/er.
P.S. BTW, see my...
2004-12-08 14:27:16 UTC in Dirac
-
Hi,
>18 bits are only used for temporary values in the up- or down-conversion,
>so there's no need to store video on RAM at 18 bits, I wouldn't think. Eg,
>for you calculate things like
>
>(coeff1*sample1 + coeff2*sample2 + ..) >>8
>
>where the coefficient is an 8-bit number and the samples are 10-bit video,
>so the result is a 10-bit value again, and it's...
2004-12-08 14:11:22 UTC in Dirac
-
Hi,
In the software, when you perform the downsampling (or the upsampling), you keep 4 extra bits of information after each step (see StageI_* in downconvert.h). Ending with values on 18 bits for the 1:8 data.
Mainly because of bandwidth constraints with the RAM blocks on the FPGA, I would like to keep the pixel values on 8 bits -- e.g. removing the least significant bits. What kind of...
2004-12-06 17:58:45 UTC in Dirac
-
[both in CVS and 0.4.3]
From line 73:
sum += (OldImage[((y-1)>=0)?(y-1):0][x] + OldImage[y+2][x])*StageI_II;
sum += (OldImage[((y-2)>=0)?(y-1):0][x] + OldImage[y+3][x])*StageI_III;
sum += (OldImage[((y-3)>=0)?(y-1):0][x] + OldImage[y+4][x])*StageI_IV;
sum += (OldImage[((y-4)>=0)?(y-1):0][x] + OldImage[y+5][x])*StageI_V;.
2004-11-16 12:32:55 UTC in Dirac
-
Yes, hierarchical ME is quite tricky to do in hardware. But correctly done, I believe it will be possible to do it efficiently. More efficiently, that is, than a fully parallelized version in which you would work block by block, independently from each other. The "area" taken by the motion estimator on the fpga might be reduced this way.
Moreover, we are more interested in...
2004-10-29 00:53:31 UTC in Dirac
-
[This thread started with an email in which I told Dirac's development team that I was willing to implement Dirac in hardware---here is the follow-up]
Hello,
I've been looking at the code and the documentation (in that order---the latter is actually quite good, nice job there) for a while now, and I would say that implementing Dirac is kind of an interesting challenge.
I am mostly...
2004-10-28 20:04:35 UTC in Dirac
