Am Fri, 9 Jan 2009 07:12:29 -0500 schrieb Graham Royston <[email protected]>:
> On Fri, 9 Jan 2009 12:26:44 +0100 > Carsten Meier <[email protected]> wrote: > > > Am Thu, 8 Jan 2009 23:04:52 -0500 > > schrieb Graham Royston <[email protected]>: > > > > > Hello Mike, > > > > > > With regards to our conversation about retrieving the YUV/PCM > > > information from the PVRUSB2, I've discovered some additional > > > information that I suspect you will find useful. It is as follows: > > > > > > To reiterate, the commands to pull the information is as follows. > > > They can be sent one at a time, for audio/video only, or one > > > immediately after another for both. > > > // Start sending PCM (instead of sending 0x14 for MPEG) > > > pvr2_encoder_vcmd(hdw,CX2341X_ENC_START_CAPTURE,2,0x01,0x12); > > > > > > // Start sending YUV > > > pvr2_encoder_vcmd(hdw,CX2341X_ENC_START_CAPTURE,2,0x01,0x11); > > > > > > > > > The stream consists of audio and video frames, in no particular > > > order. The audio "frames" are 0x1200 bytes in length (not > > > including the header), the video frames are 0x7E900 in length, > > > and every video frame is followed by some miscellaneous > > > information of 0x120C in length (Something to do with VBI, > > > maybe?). Though, changes in the video resolution or audio bitrate > > > are likely to change those values. > > > > > > To describe better than I can do in words, I've attached some code > > > for demuxing the streams. It's ugly, but it works. With it, I've > > > been able to play the captured audio and video, albeit with some > > > caveats, described below. > > > Note: It sometimes fails to find the audio header, which makes it > > > not possible to demux the stream. I intended to fix this, but it's > > > getting down to the last minute, and I'm quite sure you're capable > > > of figuring it out. The point is really only to convey the format > > > of the stream. Usage: > > > cat /dev/video0 > captured (CTRL-C, eventually) > > > pvr_demux captured audio_out.raw video_out.yuv > > > > > > PCM Format: > > > The data is RAW PCM. It appears to be 16-bit, big-endian, but I'm > > > not certain of the frequency. It could possibly be controlled > > > using the same methods as for the MPEG data. Not knowing, or as > > > of yet being able to guess the frequency, the audio is clearly > > > there, but it is distorted (high/low pitched, too fast/slow). > > > > > > YUV format: > > > The extracted stream can be played in mplayer using the following > > > command: > > > mplayer -rawvideo w=720:h=480:format=hm12 -demuxer rawvideo > > > video.yuv > > > > > > However, if I use format=hm12, the picture is fuzzy, but not > > > distorted, and the colours are wrong. If I use format=iyuv, the > > > colours are correct, but the picture is distorted. I'm guessing > > > that the colourspace conversion of which you spoke used by the > > > ivtv guys would correct this. > > > > > > > > > I hope that is of some assistance. I'd be glad to help out with > > > testing, or anything else that may be necessary. > > > > > > Thanks, > > > Graham > > > > Hi, > > > > do I understand it correctly in that it is possible to get > > uncompressed, raw video and audio data from the pvrusb2? Can it be > > requested from userspace by the normal VIDIOC_S_FMT ioctl? > > > > Thanks, > > Carsten > > Good Day, > > It is possible, but not from userspace at the moment, as it is not > implemented by the driver. It requires that the driver be patched to > send different commands and to not look for an MPEG header. My patch > to do so is a quick hack for testing purposes, and is not suitable for > distribution. Also, I don't know if this is possible on all devices > and firmware, but it works on my own (24xxx). > > Thanks, > Graham It would be very cool if such a feature is available. Then I can decode PAL-Plus signals in software and encode it with Dirac without loss of quality. I'm looking forward... :) Carsten _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
