discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: usrp_tv_rcv issues


From: Nathanael Nerode
Subject: [Discuss-gnuradio] Re: usrp_tv_rcv issues
Date: Fri, 18 Aug 2006 20:25:15 -0400
User-agent: KNode/0.10.2

Martin Dvh wrote:

> Nathanael Nerode wrote:
>> Matteo Campanella wrote:
>> 
>> 
>>>Hello folks, here there is an interesting piece about the nice
>>>usrp_tx_rcv and the status of the art as of now.
>>>I am sending it to the list with the consensus of Martin.
>> 
>> <snip>
>> 
>>>>A needed add-on is also color-decoding, color-video-sink and
>>>>audio-decoding.
>>>>Audio-decoding should be straight-forward because it is just a variation
>>>>on FM-radio (for PAL-TV)
>>>>The problem is that you need the full 6Mhz bandwidth to get the color
>>>>and audio sub-carriers and for most PC-s this is too much for realtime
>>>>decoding.
>> 
>> Is it perhaps possible to implement some of the decoding in the USRP, so
>> as
>> not to clog the PC's CPU?  Perhaps a specialized daughterboard?
> Although possible, it is not the first thing to persue.
> (premature optimization)
Right.  :-)

> Lets first get it to work in software non-realtime.

Actually.... personally, I'd be completely 100% satisfied with that (since
the primary application which interests me is digital archival of analog
tape material).   But the analog input is always realtime.  So the software
has to be realtime "enough" to capture all the vital information, digitize
it,  and write it to the hard disk, without throwing any of it away.

I think I misunderstood.  Perhaps the signal can already be digitized in
real time, preserving *all* the necessary information (luminance, color,
sound, etc.) in sufficiently high resolution -- and it's *only* the
decoding to an RGB signal which is too much for realtime?  I assumed that
a 'dumb' digitization without separately analyzing the subcarriers would
either lose too much information to be any good, or would require too much
bandwidth to fit over USB -- but perhaps I was wrong.

If the digitized signal actually already contains all the necessary data....
you could set up something which just dumped the data stream to a file, and
then work on translating the file in non-real-time to a standard video file
format with a plain userland program.  :-)  That I actually might be able
to help with the coding of.  :-)

> Then optimize the software
> optimize algorithms, parameters
>         convert to a single block, remove unneeded copying
> use simd (mmx, sse, 3dnow) optimizations
> Optionally convert to gpgpu code (I have done this before, this can give
> you big wins) 

> Or do processing in the fpga. 

That's actually the sort of thing I was thinking of: it would reduce the
bandwidth going over USB.

-- 
Nathanael Nerode  <address@hidden>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...





reply via email to

[Prev in Thread] Current Thread [Next in Thread]