I'm sorry Thomas, I didn't listen or read your first email thoroughly
enough:
you don't have a CAM at all. Manu told that the CAM support is still on
the TODO list.
Thus the problem might be elsewhere than on stream encryption.
I think that the problem is "just a sound problem".
Because sound doesn't work under Windows either, I expect
that the cause might be with sound playing. Does the sound work at all?
If not, maybe you have to install a sound driver into Windows or move
the old style
analog loudspeaker plug on the rear of the computer into the green slot
(See your computer manual, please).
On Linux you can configure sound by running
system-config-sound as root on RedHat based computers.
Sound device detection should work so that KDE or Gnome is able to
play CD or make some other noise.
If KDE or Gnome is able to make noise, there should be only software
problems
to tackle down: I expect that the DVB card works well because you get
the picture :)
Here is aother problem solving path
to figure out where the problem is located (a DVB problem or with
motherboard sound side
problem):
Please first record some channel a bit under Linux with full TS
recording mode (with Kaffeine for example).
Then play the recorded file from the command line:
mplayer <filename.m2t>
For me it reports that it found the _mp3 audio codec_ and thus the sound
playing works:
===============================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 224.0 kbit/14.58% (ratio: 28000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
===============================================================
Test next the following:
mplayer -vid 5 <filename.m2t>
This time the video should be disabled because there is no such video
ID, but the sound should play.
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A:30827.6 ( 8:33:47.5) of 535.3 (08:55.2) 1.1%
If you got this "A: ... 1.1%", the DVB card sound input is OK. The problem
is on general Linux sound.
If you get the following from mplayer:
TS_PARSE: COULDN'T SYNC
NO VIDEO! NO AUDIO! NO SUBS (yet)!
Here the problem was with filename.m2t replay ( maybe not with DVB card,
but a codec or some similar driver is missing causing mplayer to fail.
If "A: ... 1.1%" works, and Gnome or KDE give some noise, you have still
some problem places:
DVB output selection: I had to make KDE sound server "suspend" after
being idle one second so
that it leaves space for Kaffeine or Mplayer. I adjusted the setting via
kcontrol application.
If you use Gnome, there might be some other adjustment.
With USB hearings I had to use system-config-sound and put the USB stuff
as "default".
Then after a reboot it worked.
Manu Abraham kirjoitti:
Marko Ristola wrote:
Hi Manu and Thomas,
I did some testing with encrypted channels,
because I haven't played with them before.
I did figure out some information that might help further.
I used my card and stored an encrypted channel a while.
I don't have an external CAM on the card.
ie using FTA mode. The stored stream is scrambled.
Storing went fine. It seems to me, that Kaffeine stored
the whole TS stream as I requested. This should mean
that both audio and video streams are on the TS.
File sizes suggest that also.
With a channel that had both encrypted sound and video,
I used ffmpeg to dump out stream information:
#ffmpeg -i MAX.doc_\ Vuosituhannen\ historia.m2t -dump MAX.output.ts >&
MAX.world.log
Input #0, mpegts, from 'MAX.doc_ Vuosituhannen historia.m2t':
Duration: N/A, bitrate: N/A
Stream #0.0[0x130]: Video: mpeg2video, 90000.00 fps(r)
Stream #0.1[0x230](fin): Audio: mp3
Stream #0.2[0x430](fin): Subtitle: dvbsub
picture size invalid (0x0)
-- END OF MAX.world.log --
So ffmpeg didn't get out any sound or video stream packets.
naturally, otherwise no meaning for scrambling by the provider
I used ffmpeg to dump out stream information on an encrypted video
stream with unencrypted sound:
Input #0, mpegts, from '../Canal+ Film 3-20070412-171818.m2t':
Duration: 00:00:46.9, start: 30818.352633, bitrate: 2916 kb/s
Stream #0.0[0x206]: Video: mpeg2video, 90000.00 fps(r)
Stream #0.1[0x298](swe): Audio: mp2, 48000 Hz, stereo, 256 kb/s
picture size invalid (0x0)
-- END OF log Canal+ log file --
So ffmpeg seems not to be able to parse input streams that has at least
one encrypted stream.
However I could listen the Canal+ sound without the picture with mplayer
(and originally with Kaffeine).
Here is the nonworking case from above (both video and audio encrypted)
with mplayer:
Playing MAX.doc_ Vuosituhannen historia.m2t.
TS file format detected.
TS_PARSE: COULDN'T SYNC
NO VIDEO! NO AUDIO! NO SUBS (yet)!
No stream found.
Here is the working sound with nonavailable video with mplayer:
Playing Canal+ Film 3-20070412-171818.m2t.
TS file format detected.
NO VIDEO! AUDIO MPA(pid=664) NO SUBS (yet)! PROGRAM N. 1000
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
So I conclude that because video works but sound does not work under
Windows,
with Thomas, CAM does decrypt the video stream correctly, but does not
decrypt audio
packets correctly or not at all and thus only the video stream is
decrypted and shown.
The hardware parts that are related to the decryption, are CAM module
and the paper card.
Maybe the paper card is only partly functional? If that has one or more
nonfunctional
secret key, only audio might become or stay garbage. Thomas could take
the paper card away
and put it back. Sound might work then. Thomas could take the paper card
into
a shop where the service provider could verify that it works properly
there.
I think that the CAM is properly attached, because video decryption works.
??
Unfortunately I understood from his first email that he would have a CAM,
even though he didn't write that on his email when I read it again.
Do you know of advances on the remote control?
Do you Manu agree? I assume here that the CAM decryption is done while
receiving
and not while displaying and CAM doesn't need much assistance in the
process.
Currently the CI slot (the PCMCIA slot on the mantis) is not supported
yet. It needs more work on it. Needs some more information from the chip
manufacturer as the chip is not documented at all.
Manu
Marko
_______________________________________________
linux-dvb mailing list
[EMAIL PROTECTED]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
