From: Vasilis L. <vli...@gm...> - 2010-01-29 06:12:28
|
Hi Nicolas, On Thu, Jan 28, 2010 at 7:31 AM, Nicolas Hennion <nic...@gm...> wrote: > Hi Vasilis, nice to find a person interrested by this challenge ! > > To be honest, i am not a ROHC specialist too... But what i understand from > this protocol is that it will be able to compress the IP, UDP (or TCP) and > RTP header. In your pipeline exemple, you write: > > sender / compressor: > # gst-launch filesrc location="packets.pcap" ! rohccomp ! udpsink > receiver / decompressor: > # gst-launch udpsrc ! rohcdecomp ! filesink location = > "packets_otherside.txt" > > In this exemple, the header compression is done before the UDP > encapsulation, only the RTP hrader will be compressed and not the UDP. I right, my example only did compression for the encapsulated pcap frames, not for the UDP frames. Both the examples I 've seen in the source code deal with compressing headers of packets that are later encapsulated by another packet flow > think that the best way to implement the ROHC is to fork the udpsink and > udpsrc by addind a new tag (rohc="false|true"). > sender / compressor: > # gst-launch filesrc location="packets.pcap" ! udpsink rohc="true" > receiver / decompressor: > # gst-launch udpsrc rohc="false" ! filesink location = > "packets_otherside.txt" > > Any comments ? I assume you mean that in your example pipeline would compress the whole udp flow. Actually this is a question for the rohc library developers: Since the library is a userspace implementation, can we compress headers for the entire packet flow? I think there would be at least one packet flow being created in the normal kernel stack, and we need some kernel mechanism e.g. a module to handle the compression of headers for that network flow within the networking code. So my question is: can we compress the whole network flow from startpoint to endpoint? Without a kernel module, I think we 'd always leave some uncompressed frames on the table. Perhaps there is a way to directly access all header flow with libpcap and CONFIG_PACKET_MMAP=y ( a kernel option)? But I am not sure if this needs to be exposed in a gstreamer element. Currently udpsink and udpsrc just use regular sockets for the packet flow, no pcap capabilities are exposed are far as I know. Apart from that, I think It should be possible to implement the rohc compression / decompression with an element derived from udpsrc/udpsink, is that what you mean by forking? The rohc=true/false setting would be a property of the element. Actually I am not clear on why you used "rohc=true" in your compressor and "rohc=false" in the decompressor. DId you mean to say that the properties of the element are "rohc=compress" and "rohc=decompress"? In short, this pipeline makes sense in theory. But as I mentioned udpsrc/udpsink use normal sockets to receive/transmit datagrams and I don't know if we can have the full header information available for compression at this layer. I apologize if I am missing something obvious in the librohc implementation comments & suggestions are very welcome. thanks, - Vasilis > > Nicolas > > ---- > Ce n'est pas l'appareil qui prend la photo. > Ce sont les yeux, le coeur, le ventre, tout ça... > -+- Jacques-Henri Lartigue -+- > ---- > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > |