Duncan Webb wrote:
> Benjamin Zores wrote:
>
> A quick look on the mplayer svn, you have already implemented pvr://, is
> it finished? Cool if it works.
>
> There is a small bug in stream_pvr.c, line 805
> /* get current audio input */
> if (ioctl (pvr->dev_fd, VIDIOC_G_AUDIO, &vaudio) == 0)
> {
> vaudio.index = input; //#805
> if (ioctl (pvr->dev_fd, VIDIOC_ENUMAUDIO, &vaudio) < 0)
> {
> mp_msg (MSGT_OPEN, MSGL_ERR,
> "%s can't get ENUMAUDIO input %d (%s).\n", LOG_LEVEL_V4L2,
> input, strerror (errno));
> the vaudio structure has already been initialized and setting the index
> to input is not correct as is using the vin.index value.
>
> If my understanding of this message thread is correct the only way to
> get audio out of a PVR is to encode the audio as a mpeg stream and send
> it to /dev/video16.
>
> What I haven't tried but it would be interesting to know is can the
> Hauppauge Windows radio application send audio out of the card to the
> 9-pin din connector. It if can then there must be another way of sending
> audio streams through the card other than as a mpeg stream. Just a thought.
>
The trick is that the chip, for both input/output audio samples, uses 2
1024k buffers (and may be some sony serial format???, this I'm not sure
about, or just raw LPCM I'm guessing). they are the 2 channels and the
firmware does all the other work then places it in those buffers
real-time interactively. This is all really just registers and those
buffers, it's a pretty limited interface from what I've found, seems
they never really meant for PCM/YUV output or input actually, it all
hacks and the PCM input seems like it stretches the original design out
of bounds because of the buffer setup there. When really looking at how
the YUV is output, basically in the format the mpeg2 encoder likes not
something to display, and the PCM is done pretty oddly in the firmware
to output for encoding too. Also the PCM we can capture from input,
that's the firmware buffering the input samples into a group of PCM
buffers and making it available, that's even not a natural firmware
thing but us grabbing the mpeg2 encoders PCM buffer after it's done (so
we can't even input PCM to those for transcoding to mp2).
I've studied it, researched my information I've seen, dug deep as I
could, and it seems to amount to that the firmware has a very simple
audio routine saying write '1' here and I'll grab the audio and use it
or input the audio for output for both encoder/decoder units, the rest
of the entire firmware and that routine work in sync, you have to be in
the firmware from every angle I've looked at it, and also seems like
this is pretty well confirmed by engineers who worked on the chip too.
So you really can do every single combination of YUV in YUV out for
decoding(output) and encoding(input) (yes transcoding YUV to MPEG :) and
also PCM out for encoding(input). So no PCM in at all for decoding or
encoding, this is really the main reason transcoding won't work because
you can't input audio right, and control the Muxing either because of
that and the timing too.
Now the cx23418, I think they thought about all the extra possibilities
for it although they may never get implemented I am guessing (they also
already fixup the YUV in the firmware there since it's an ARM processor
that works compared to the Java ones on these older chips) one if it's
ever used by Hauppauge, you can imagine the amazing things it can do
since it's this chip actualized into perfection, yet with no team or
future besides Conexant replacing these chips with it and no one
exploring the advanced features unless Hauppauge uses it eventually and
we explore those (which I can help with since I made something similar
to the ivtv driver in compatibility work with it for them basically to
get all the v4l 1/2 stuff working, they were actually going to release
it open source eventually but it probably never even got used by anyone
besides the customers in Japan they had promised it to) (they had a
cx23417 decoder/encoder with a whole harddrive/computer/dvd system,
little computer basically all working off of this chip, for having a
super multimedia system, that was trashed when the old iCompression
engineers were laid off from Conexant :(
Thanks,
Chris
> Duncan
>
>> On Sun, 23 Jul 2006 23:28:53 +0200
>> Hans Verkuil <[EMAIL PROTECTED]> wrote:
>>
>>> n Sunday 23 July 2006 12:42, Benjamin Zores wrote:
>>>
>>>
>>>> On Wed, 12 Jul 2006 23:28:43 +0200
>>>>
>>>> Benjamin Zores <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>> On Wed, 12 Jul 2006 22:00:17 +0200
>>>>>
>>>>> Hans Verkuil <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>
>>>>>> The sound on the audio out of the PVR350 is output by the MPEG
>>>>>> decoder of the card. There is no way of feeding it a separate
>>>>>> audio uncompressed (or compressed for that matter) stream. You
>>>>>> give it a MPEG program stream (I'm not even sure if it can handle
>>>>>> a transport stream) and it will demultiplex and uncompress it and
>>>>>> put the audio on the audio out connector.
>>>>>>
>>>>>>
>>>>> Ok, btw, which formats are supported by the decoder ?
>>>>> MPEG PES only ?
>>>>>
>>>>> What about AC3, MPEG1 audio, MPEG2 audio or LPCM ?
>>>>>
>>>>>
>>>> Sorry to insist but same question again.
>>>> My ao/vo driver for MPlayer are almost working (fine for vo, ao needs
>>>> a bit more tweaking). Does the card supports h/w decoding of AC3/LPCM
>>>> ?
>>>>
>>>>
>>> I've never tested it but I'm 99% certain that it isn't supported. Only
>>> MPEG1/2 audio is supported.
>>>
>>>
>> That's also what i've feared.
>> I've tried sending nearly any combination of AC3/LPCM packets but none
>> seemed to be readable.
>> I now need to write an MPEG audio transcoder then.
>>
>>
>>
>>>> Can someone point me to decoder's specifications or properties ?
>>>>
>>>>
>>> The cx23415/6 driver is reversed engineered, no official datasheets are
>>> available. The reversed engineered documentation is available in the
>>> doc directory of the driver (you probably want the fw-decoder-api.txt
>>> file).
>>>
>>>
>> Well i wasn't looking for datasheet, just information on what the chip is
>> supposed to handle.
>> Anyhow, thanks a lot.
>>
>> Ben
>>
>>
>>
>
>
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
