[gst-devel] Header compression plugin

[Vasilis Liaskovitis]

Hi Nicolas,

On Thu, Jan 28, 2010 at 7:31 AM, Nicolas Hennion
<nicolashennion at gmail.com> 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
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>