[Live-devel] playback only working to localhost

Sat Feb 6 10:39:24 PST 2010

Duh.  Thanks, Ross - after moving from Windows to Ubuntu for development I stupidly assumed they'd enable multicast in Ubuntu by default.

If anyone else should encounter this problem, the solution that worked for me was the following:

1) modify /etc/sysctl.d/10-network-security.conf, change the lines with rp_filter from =1 to =0
2) reboot to get interfaces to accept change
3) ip route add /sbin/ip route add 224.0.0.0/4 via (local IP of interface you wish to use for multicast)

Next question - My H264 framer is forwarding NALUs intact as they are received from the MainConcept AVC encoder, including the seek bytes.  VLC plays these streams just fine, but Wowza is complaining about missing NAL SPS and PPS.  My encoder's including them in the NALUs as best I can tell, and I've also sent a base64 encoded version of the sprop parameter set it returns.  Question being - should I be stripping seek or other information from the stream before scheduling afterGetting()? Here's the first 64 bytes of the first 10 frames I'm forwarding along:

Play this stream using the URL "rtsp://10.0.22.60:8554/testStream"
Hex dump of encoded frame #1:                                         
 >00000001 09100000 0001674D 40299652< ..........gM@).R 00000000
 >00A0173E 5C054200 0007D200 01D4C13B< ...>\.B........; 00000010
 >42C5B2C0 00000001 68EB7352 00000001< B.......h.sR.... 00000020
 >060001C0 010E3920 00800000 03009200< ......9 ........ 00000030
Frame received (#8) - No input signal detected
Hex dump of encoded frame #2:                                         
 >00000001 09300000 00010601 0E392004< .....0.......9 . 00000000
 >80000003 00920048 00000300 08800000< .......H........ 00000010
 >0001419A 0208F90D 8101D551 56FFD332< ..A........QV..2 00000020
 >3B02F545 B51776AB 91100FC5 CA4B896E< ;..E..v......K.n 00000030
Hex dump of encoded frame #3:                                         
 >00000001 09500000 00010601 0E392002< .....P.......9 . 00000000
 >80000003 00920028 00000300 08800000< .......(........ 00000010
 >0001419E 0404E846 5BFB8EC2 C9FE0D5E< ..A....F[......^ 00000020
 >912F74D4 EFA00EB6 126EDA0C FEA40BFA< ./t......n...... 00000030
Hex dump of encoded frame #4:                                         
 >00000001 09500000 00010601 0E392001< .....P.......9 . 00000000
 >80000003 00920018 00000300 08800000< ................ 00000010
 >0001019E 0602EC8E B7494088 6D7BD8E6< .........I at .m{.. 00000020
 >D3AAFD3D D0F0847B C7199583 DA699D38< ...=...{.....i.8 00000030
Hex dump of encoded frame #5:                                         
 >00000001 09500000 00010601 0E392003< .....P.......9 . 00000000
 >80000003 00920038 00000300 08800000< .......8........ 00000010
 >0001019E 0606D323 ADFFF7F7 1DCC2A30< .......#......*0 00000020
 >33B9C988 E70F4810 3E587C53 0FE90A5F< 3.....H.>X|S..._ 00000030
Hex dump of encoded frame #6:                                         
 >00000001 09300000 00010601 0E392008< .....0.......9 . 00000000
 >80000003 00920088 00000300 08800000< ................ 00000010
 >0001419A 06106968 980AB7B8 43AB5383< ..A...ih....C.S. 00000020
 >1A7B9B71 E5A5CFBD 374D794E 0BD6EE05< .{.q....7MyN.... 00000030
Hex dump of encoded frame #7:                                         
 >00000001 09500000 00010601 0E392006< .....P.......9 . 00000000
 >80000003 00920068 00000300 08800000< .......h........ 00000010
 >0001419E 080CD312 5B526E28 05D11E92< ..A.....[Rn(.... 00000020
 >53247477 D10764BE D89FDA34 45B25DBC< S$tw..d....4E.]. 00000030
Hex dump of encoded frame #8:                                         
 >00000001 09500000 00010601 0E392005< .....P.......9 . 00000000
 >80000003 00920058 00000300 08800000< .......X........ 00000010
 >0001019E 0A0AEC9A DFEA3C3F AFEF2A74< ..........<?..*t 00000020
 >F5AC8829 C9B9F240 B67E4A69 5E0E120E< ...)... at .~Ji^... 00000030
Hex dump of encoded frame #9:                                         
 >00000001 09500000 00010601 0E392007< .....P.......9 . 00000000
 >80000003 00920078 00000300 08800000< .......x........ 00000010
 >0001019E 0A0ED326 B7491077 D24C5CAA< .......&.I.w.L\. 00000020
 >52367469 48112559 A9ADA262 DE73A277< R6tiH.%Y...b.s.w 00000030
Hex dump of encoded frame #10:                                         
 >00000001 09300000 00010601 0E39200C< .....0.......9 . 00000000
 >80000003 009200C8 00000300 08800000< ................ 00000010
 >0001419A 0A186968 9809EDFF D27D98D4< ..A...ih.....}.. 00000020
 >F727D185 127EEB7E 521D1AF1 AFF726FF< .'...~.~R.....&. 00000030

The parameter set as I encode and report it:

a=fmtp:96 packetization-mode=1;profile-level-id=000041;sprop-parameter-sets=AWdNQCmWUgCgFz5cBUIAAAfSAAHUwTtCxbLAAAAAAWjrc1I=

Thanks again for both the source and your support of a protocol that's not the easiest to grapple with, Ross.

Cheers,
-t

On Feb 6, 2010, at 2:16 AM, Ross Finlayson wrote:

>> I'm attempting to feed an H.264 stream from a live capture and encoder application we've written into Wowza 2 via live.  I've managed to create a custom H264VideoStreamFramer (STH264VideoStreamFramer ) and DeviceSource (STMCVSource) that successfully forwards frames from our encoder (MainConcept) to vlc or openRTSP via localhost, but when I connect to the same instance from any other machine on the same subnet (whether directly attached to the NIC or through a switch) openRTSP on that client doesn't actually capture any frames after setting up the stream.
> 
> The fact that the (multicast) packets get delivered to "openRTSP" when it's running on the same host, but not when it's running on another host, suggests that the problem is with your network interface.  In particular, you should make sure that that multicast is configured properly for your network interface - i.e., make sure you have a route for 224.0.0/4 on that interface.
> 
> -- 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel