Re: [linux-dvb] DVB-H and dvbnet / MAC-broadcast address
Hi Thomas, On 4/2/07, Thomas Pinz [EMAIL PROTECTED] wrote: Did you extend the buffers in VLC ? No. The defaults for UDP/TCP are to small for the DVB-H timeslices. With Input/Codecs - Access modules - UDP/RTP - Caching value set to 1 ms, the interrupts will be gone. great, and most of the debug output is gone, the sound and video are clear now. I played around in my case the time slices come every 1.6 seconds, so even a value of 3000ms was fine - but of course the default value of 300ms was not sufficient. I did not know about that setting - I would have expected the buffer to be dynamic, adopting to the jitter of the data received... Thank you, Dietmar ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-H and dvbnet / MAC-broadcast address
Hi Nico, On 3/30/07, Nico Sabbi [EMAIL PROTECTED] wrote: (..) run $ ifconfig dvb0_0 ip/mask promisc up $ route add -net 224.0.0.0/4 dev dvb0_0 you shouldn't need to tamper with the MAC addresses. Thank you, with your help I finally succeeded. My idea to hack the destination address was not needed, it is fine to configure the interface to promiscous mode (option promisc ifconfig) as you suggested. I also learned that an outgoing route can have a specific meaning for incoming multicast traffic. But: After doing all this I could still not receive anything. It seems that some (I still do not know which) kernel-options have to be set. At least I could not decode anything with vlc when running on Knoppix 5.2 (a livecd based on Debian) but I succeeded with Fedora 6 (Kernel 2.6.20.1). I also did a short test with a Gentoo live-CD, but that distribution did not even detect the USB-stick, so did no go ahead with it. Any idea which kernel-options are needed? My guess is that some multicast-routing options or protocols would be required but are not set by default on some distributions. The current status is: I am able to receive DVB-H, all channels from the ongoing Vienna trial are in clear, so I can now receive ORF1,ORF2,ATV,ORF-Mobil,MTV,H3G1(aka 3Live), H3G2 (aka Urban TV) and the radio channels FM4, OE2W and OE3. There are a number decoding errors with interrupt the video/audio periodically, I am not sure if this is due to my weak signal, some problems in vlc or even problems on the encoder side. From time to time reception locks up (especially when I zap aroung by removing and adding the network interface attaching it to different PIDs), and for some reason I only stay locked when tzap is running, when it is stopped the USB stick looses lock after a few seconds. If I can find a more stable solution I would now like to record and/or stream the multicast streams on my local network so that I could receive all the channels an any PC. But for the time being I'm not that far. I've posted a short howto on my blog, just in case someone else is interested in receiving DVB-H: https://www.zlabinger.at/blog/2007/04/02/howto-receive-dvb-h-in-vienna Dietmar ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB-H and dvbnet / MAC-broadcast address
Hi, I am looking for help on receiving DVB-H. I get to the point where the encapsulated IP is attached to a network interface (as dvb0_0 using dvbnet -p portnr). At this stage I am able to dump the UDP-packets received using tcpdump. But I am not able to get that IP-multicast into VLC. I believe the problem is related to the fact that normally IP-multicast uses the Ethernet broadcast address (ff:ff...) while in dvb-h the destination mac is (partly) replaced by the dvb-h time slicing information . Therefore the traffic is only received by the network interface when it is in promiscuous mode (when using tcpdump), but not when a normal program (like vlc) is trying to get multicast frames out of it. My idea then was to modify dvbnet so that it replaces the broken ethernet destination (is contains timeslicing-infos) by ff:ff so that it goes through the network interface. But the actual code of dvbnet does actually not handle the received data, the only thing that program does is some ioctl(fd_net). Any idea who I could get the ethernet-multicast out even when the destination mac is wrong? Any idea how I could modify (the kernel) so that I could overwrite the faulty mac? I could not find any description on how to receive dvb-h on the web. The are some mailing on how to find SDP files, but that was not such a big thing (dvbsnoop -b pid ..). Thanks for help, Dietmar Some of my debug output: tzap service dvbsnoop 1140 dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/ SECT-Packet: 0001 PID: 1140 (0x0474), Length: 996 (0x03e4) Time received: Fri 2007-03-30 00:15:34.630 : 3e b3 e1 0d e1 c1 00 00 0c 80 00 00 45 00 03 d4 ...E... 0010: 68 70 00 00 07 11 d3 96 ac 16 05 0d e1 e1 e1 0d hp.. 0020: c0 12 04 4c 03 c0 dd f5 80 e0 5a 1e fa b3 d3 8d ...L..Z. (...) 03d0: 8e 91 da df 06 f9 42 54 2c 90 bf 5e 2a 7f f7 c0 ..BT,..^*... 03e0: 9c ee 8a fd PID: 1140 (0x0474) Guess table from table id... DSM-CC DATAGRAM-decoding Table_ID: 62 (0x3e) [= DSM-CC - private data section // DVB datagram] section_syntax_indicator: 1 (0x01) private_indicator: 0 (0x00) reserved_1: 3 (0x03) Section_length: 993 (0x03e1) MACaddrbyte/DevicdID 6: 13 (0x0d) MACaddrbyte/DeviceID 5: 225 (0xe1) reserved_2: 3 (0x03) payload_scrambling_control: 0 (0x00) [= unscrambled] address_scrambling_control: 0 (0x00) [= unscrambled] LLC_SNAP_flag: 0 (0x00) current_next_indicator: 1 (0x01) [= valid now] Section_number: 0 (0x00) Last_Section_number: 0 (0x00) MACaddrbyte/DeviceID 4: 12 (0x0c) MACaddrbyte/DeviceID 3: 128 (0x80) MACaddrbyte/DeviceID 2: 0 (0x00) MACaddrbyte/DeviceID 1: 0 (0x00) = MAC-Address/DeviceID: 00:00:80:0c:e1:0d IP_datagram_bytes : 45 00 03 d4 68 70 00 00 07 11 d3 96 ac 16 05 0d E...hp.. 0010: e1 e1 e1 0d c0 12 04 4c 03 c0 dd f5 80 e0 5a 1e ...L..Z. 0020: fa b3 d3 8d 00 00 01 e0 3c 41 8e 0c 0a 7e e3 7a A...~.z (..) -- dvbnet -p 1140 fconfig dvb0_0 up tcpdump --n -i dvb0_0 -s0 00:25:16.377328 IP 172.22.5.13.49172 225.225.225.13.1102: UDP, length 192 00:25:16.377575 IP 172.22.5.13.49172 225.225.225.13.1102: UDP, length 183 00:25:16.379331 IP 172.22.5.13.49170 225.225.225.13.1100: UDP, length 1472 --- some sdp (not related, from a different service): dvbsnoop 1201 (...) v=0 o=- 1284305069 1139040522 IN IP4 192.168.250.2 s=realtimeaudio c=IN IP4 226.226.0.2 a=control:* a=range:npt=0.0- a=ISMA-compliance:1,1.0,1 a=mpeg4-iod: data:application/mpeg4-iod;base64,AoEHAA///w///wN +AAFAYGRhdGE6YXBwbGljYXRpb24vbXBlZzQtb2QtYXU7YmFzZTY0LEFTb0JLQUtmQXlRRDZ BVUVEVUFWQUFZQUFBZ1RNQUFCdFlBR0VBQkVBQUNzUkFBQXJFUWdJQUFBQUFNPQQNAgUAAQA AAAYJAQAA m=audio 9030 RTP/AVP 101 b=AS:112 a=rtpmap:101 mpeg4-generic/44100/2 a=control:trackID=1000 a=fmtp:101 streamtype=5; profile-level-id=15; bitrate=112000; config=1210; sizelength=13; indexlength=3; indexdeltalength=3; profile=1; mode=AAC-hbr a=mpeg4-esid:1000 (...) vlc - thisservice.sdp ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
