also from what i can recall, the yuv you get from the encoder may not be valid yuv to feed to the output side.
i think it's more meant to work on the output from a software decoder (aka yv12).
Notes from my PVR-350 YUV (0.2.0-rc3) experiences ....
1. The YUV from the card (/dev/video32) is not YUV420 (YV12) but rather Hauppauge's HM12 macroblock format. It requires a routine to manipulate it into YUV420. Not hard, but it has to be done before doing anything useful with the frame.
2. The card delivers a complete YUV frame (518400 bytes) for each video frame. You'll need some fast reads to get the whole frame in time. poll()/select() loops don't really help, as you do not have any indication (that I can see) of which byte is the first byte of the frame.
3. So far, parallel reading from both /dev/video0 and /dev/video32 is problematic ... it seems to get "stuck". No errors, but the read() from /dev/video32 blocks. Which also seems to slow everything else down, too. Not sure why this is yet, but it limits the uses of the YUV output.
4. When /dev/video32 is opened, sometimes the top 1/4 to 1/3 of the frame seems to be "off" by some number of bytes. Meaning ... the YUV is the top portion is scrambled, but gets "corrected" later in the frame. Perhaps this is an alignment problem ... or some bytes are transposed. Sending an ioctl() to change the channel, for example, fixes the problem. This doesn't happen on every open(), but will occur on the initial open() of /dev/video32.
5. When the driver throws a "stealing buffer" error, it would be better to drop the whole frame rather than trying to send a complete buffer whilst attempting to get memory. When this error occurs, the driver slows down, and all output from the card is affected.
6. Being able to shove the YUV back into card for output through the video out would be a lot better than trying to encode MPEG2 video/audio and writing to /dev/video16. The CPU required to do the encoding limits what I can do with my applications. ;) Writing a short audio delay to compensate for the video processing wouldn't be too difficult.
7. The stability of using either /dev/video0 OR /dev/video32 is excellent. The applications I wrote have no problems with these devices. As I said in #3 above, using both simultaneously doesn't seem to work. I use 'mplayer' on /dev/video0 and my app on /dev/video32. The app also reads from /dev/video24 (PCM audio). The audio never seems to be affected.
As always, excellent work.
Regards, Paul
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
ivtv-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
