gmane.comp.telephony.farsight.devel

Snooping

Chockalingam Alagappan — 2013-05-08T12:14:05

Can i use the farstream API only for snooping
i.e i want to extract the RTP data of a conference without being an active
particpant on the conference.

Chockalingam Alagappan | Senior Consultant , Engineering
GlobalLogic
P +91.080.4157.6163  M +91.994.540.5810  S chock.gl
www.globallogic.com
 <http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt
_______________________________________________
Farstream-devel mailing list
Farstream-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW< at >public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/farstream-devel

ANNOUNCE: Farstream 0.2.3

Olivier Crête — 2013-04-16T01:54:42

Tarball:
http://freedesktop.org/software/farstream/releases/farstream/farstream-0.2.3.tar.gz
Signature:
http://freedesktop.org/software/farstream/releases/farstream/farstream-0.2.3.tar.gz.asc


- Use generic marshallers
- Fix building by gold linker (Emanuele Aina)
- Fix leaks, found by Havard Graff and others
- Fix building with automake 1.13 (Nuno Araujo)
- Lower PulseAudio latencies (Arun Raghavan)
- Fix codec intersection
- Add API to make the API be introspection accessible, fixing the Python example
- Use GSocket and other win32 portability improvements

bitrate adapter & rtp header extensions

David Spangle — 2013-04-02T23:30:01

im working on a client that id like the bitrate adapter and tfrc to be a
part of, but im having trouble getting it off the ground.  my client is
currently using telepathy-gabble (google) as my backend account in
telepathy.  my first guess was to undo the change made on 2011-10-03 to
"disable tfrc from default config".  even after doing that, i can put debug
code in farstream to see that the rtp header extensions arent being
generated or read from the conference.  is there anything else on a general
scale i need to do that im missing to make sure the tfrc code runs?  also,
i am running two of my clients that have that change uncommented out so it
shouldnt be that one end has them enabled while the other does not, which
would probably not pass negotiation.

thanks,
david spangle
_______________________________________________
Farstream-devel mailing list
Farstream-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW< at >public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/farstream-devel

Re: debugging

Olivier Crête — 2013-03-30T15:07:05

Hello, 

Farstream uses the GStreamer debugging system, so you can make it print additional information by setting the GST_DEBUG environment variable appropriately, something like this should give you lots of information :

GST_DEBUG=*rtp*:6,

I also find it useful to run Wireshark or tcpdump to find out if packets are actually being transmitted, to know if it's a problem on the sender or on the receiver side. 

Olivier

Yann Leboulanger <asterix-TwsxHVO2N2RAfugRpC6u6w< at >public.gmane.org> wrote:

debugging

Yann Leboulanger — 2013-03-30T13:29:41

Hi,

I'd like to know if there is a way to get some debug information when 
using farstream. Sometimes there are problem connecting users, like 
described here:
https://trac.gajim.org/ticket/6117

XML seems to be ok, and the rest is done inside farstream / gstreamer.

So is there a way we can have information from farstream and/or 
gstreamer to understand what's going on?

Thanks for your help,

Re: Windows executable fails to load fsrtpconference and other plugins

Olivier Crête — 2013-03-27T21:21:42

I'm really not a Windows person, so I have no idea how this stuff works.


I can prepare a patch and then you can test if that helps.


aMsn uses Farstream on Linux, Windows, Mac, but the last release still
uses GStreamer 0.10, and don't expect a new release as Microsoft are
shutting down the servers. For the basic functionality, you can try wit
the command line in examples/command-line

Re: Windows executable fails to load fsrtpconference and other plugins

Conrad Poelman — 2013-03-27T20:09:15

Hi Olivier,

Thanks for the quick reply.

On Wed, Mar 27, 2013 at 11:34 AM, Olivier Crête <olivier.crete< at >collabora.com

Yes, I and probably many others have a longstanding hatred of the Windows
LoadLibrary interface. A module can fail to load for a dozen different
reasons and Windows just reports error 126 - "The module could not be
found." Missing dependent DLLs are the most common problem, but also if a
static DLL initialization of the library or any of its dependencies fails
(e.g. I believe something analogous to throwing a C++ exception in a static
constructor?), Windows refuses to load the DLL and reports the same error.

I guess I'll just try a fully clean build, copying all gstreamer plugins to
~/.gstreamer-1.0, etc. If you think of any other ideas please let me know.


Also thank you for your comments on
https://bugs.freedesktop.org/show_bug.cgi?id=62793 - I'll definitely save
myself some shm trouble by using:

configure --with-transmitter-plugins=nice,rawudp,multicast

As you can probably tell I ha

Re: Windows executable fails to load fsrtpconference and other plugins

Olivier Crête — 2013-03-27T17:34:43

Hi,

On Wed, 2013-03-27 at 01:28 -0600, Conrad Poelman wrote:

Thanks for this, I added a couple comments there.


The important ones for pidgin are: fsrtpconference, fsrtcpfilter, and
fsvideoanyrate.


My guess is that the Windows DLL loader is not happy, there must be some
way to debug that ?

Also, Depencency Walker will not give you all dependencies, as you also
need some other gstreamer plugins, like the codecs, etc. You may want to
just try with adding all of the gstreamer plugins, not just a subset.
But you're not even getting there in this log.

Windows executable fails to load fsrtpconference and other plugins

Conrad Poelman — 2013-03-27T07:28:29

As you may know the Pidgin IM client uses gstreamer and farstream on Linux,
but that capability hasn't been implemented on Windows. The Pidgin IM
client uses a MinGW build system with some specialized build instructions
at https://developer.pidgin.im/wiki/BuildingWinPidgin. I'm attempting to
get gstreamer/farstream working in Pidgin on Windows.

After a lot of effort, I got things to compile and start up by:

   - Making some MinGW build tweaks to farstream itself, described at
   https://bugs.freedesktop.org/show_bug.cgi?id=62793
   - Downloading precompiled binaries for gstreamer 1.1.0.1, glib 2.32,
   GTK+ 2.24, etc. as described at
   http://pidgin.10357.n7.nabble.com/Video-Voice-on-Windows-progress-fails-to-load-fsrtpconference-plugin-td125410.html.
   (Note that I've since rebuilt libnice 0.1.4 from scratch just fine under
   MinGW using a pregenerated ./configure.)

With GST_DEBUG set to '*:9', as Pidgin starts up I can see that some
plugins are loaded just fine and others fail. It looks like:

   - *

Re: GObject.Parameter

Yann Leboulanger — 2013-01-12T20:36:25

Hi,

Thanks for your effort in solving that issue.

I rebuilt gobjects with those 3 patches, and rebuilt gir1.2-farstream 
with this patch, and here is what I get when I try to call:

stream.set_transmitter('nice', ('controlling-mode', 
self.session.weinitiate, 'debug', False))

Traceback (most recent call last):
[...]
   File "/home/asterix/gajim_gi/src/common/jingle_rtp.py", line 98, in 
setup_stream
     self.p2pstream.set_transmitter('nice', ('controlling-mode', 
self.session.weinitiate, 'debug', False))
   File "/usr/lib/python3/dist-packages/gi/types.py", line 47, in function
     return info.invoke(*args, **kwargs)
TypeError: Item 0: argument self: Expected GObject.Parameter, but got str

so no real progress ... if I built everything correctly.

Re: GObject.Parameter

Olivier Crête — 2013-01-12T00:50:17

Hello,

The whole GObject Introspection thing is a bit of a disaster.

I added some APIs to try to make it work, but I can't properly test it
because I can't get make install to work on pygobject, and yes, you need
to patch it.

So first, apply the patches to pygobject from these bugs:
https://bugzilla.gnome.org/show_bug.cgi?id=684062
https://bugzilla.gnome.org/show_bug.cgi?id=684060
https://bugzilla.gnome.org/show_bug.cgi?id=684059

Then, try the new API in this branch:

http://cgit.collabora.com/git/user/tester/farstream.git/log/?h=gi-fixes

The API is fs_stream_set_transmitter_ht() and it takes the transmitter
parameters as a GHashTable, see the python example for how to use it...

I'm eager to hear about your progress

Olivier

On Thu, 2013-01-10 at 20:39 +0100, Yann Leboulanger wrote:

Re: GObject.Parameter

Yann Leboulanger — 2013-01-10T19:39:24

Hi,

Is there any news about this issue? Any plan to have a way to use this 
function via introspection?

Thanks,

regarding G722 usage in farsight2/farstream

B U J J I — 2012-02-27T13:56:13

hi all,
i am trying to use g722 codecs in farsight application. i have got few
problems while running examples/gui .
first is negotiation problem because it accepts 1 channel date so that is
fixed with channel=1.

next is when i am running it in farsight2 example voice is breaking. but
naturally its working very fine. i am putting those pipelines here.

sender:
gst-launch-0.10 -v alsasrc ! 'audio/x-raw-int,channels=1,rate=16000' !
ffenc_g722 bitrate=64000 ! rtpg722pay ! udpsink port=5000 host=127.0.0.1  -v

receiver:
gst-launch-0.10 udpsrc port=5000 caps="application/x-rtp,
media=(string)audio, clock-rate=(int)8000, encoding-name=(string)G722,
encoding-params=(string)1, channels=(int)1, payload=(int)96" ! rtpg722depay
! ffdec_g722 ! alsasink sync=false -v

these pipelines are working absolutely fine.

But in farsight2 i am not able to use G722 why ? i have tried setting
different params but no luck.

can anybody help me ?


Thanks,
Bujji
_______________________________________________
Farstream-devel mailing

Re: farsight-send-profile for h264

B U J J I — 2011-11-15T05:23:44

hi Oliver,

thanks for your reply.

As you suggested i have tried different ways but i was not successful.

so I tried changing the code(simple-call.c) using
farsight-send-profile and farsight-recv-profile like below ( i have
attached full code simple-call.c for video with these changes)

*  fs_codec_add_optional_parameter (pref_codec, "farsight-recv-profile",
      "rtph264depay ! ffdec_h264 ");
  fs_codec_add_optional_parameter (pref_codec, "farsight-send-profile",
      "  rtph264pay ");*

*
*

but that is also not working as the problem is same old. my source is
h264 and fssession expects yuv.

I guess this should work atleast.

I want fsrtpconference session should be able to use pre encoded data.

could you please help me to solve this.


thanks,

bujji
Olivier Crête <olivier.crete< at >...> writes:


------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________

Re: farsight-send-profile for h264

Olivier Crête — 2011-11-11T17:42:55

Hi,

On Fri, 2011-11-11 at 22:58 +0530, B U J J I wrote:


This isn't officially supported yet, but you can make it work.


This should work. Not that if you are using farstream, it is
farstream-send/recv-profile.

You can even do this in theory:
farstream-send-profile=rtph264pay 


This isn't enforced yet, but will be once we make an official way to
support pre-encoded data (and non-decoded output) without having to play
with profiles.

Mailing list move

Olivier Crête — 2011-11-11T17:37:53

Hi,

To go with renaming of the project to Farstream, I will be moving the
mailing list to freedesktop.

So the new name will be farstream-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW< at >public.gmane.org

I'll also be renaming the farsight-commits mailing list to
farstream-commits, but this one is already on freedesktop.

You don't have to do anything except updating your filters as I'll move
the subscriber list over.

farsight-send-profile for h264

B U J J I — 2011-11-11T17:28:37

hi all,

I am trying using farsight2(farstream) for my videoconferencing application.
I ran the examples from examples/gui its working fine for different codecs.

But I my camera gives encoded(h264 encoded) so I don't want decode it back
to yuv and use it in the farsight2.

And i see in some forums that  if we use 'farsight-send-profile'  and
'farsight-send-profile'
 we can make it to use our own encoder and decoder in configuration files.

so tried added below lines in gst/fsrtpconference/default-codec-preferences
compiled and installed. (and i have changed for capture  *v4l2src !
video/x-h264*  in fs2-gui.py too )

[H264]
farsight-send-profile=identity ! rtph264pay
farsight-recv-profile=rtph264depay ! ffdec_h264

but that didn't work for me.

I see that FsRtpSession expects video/raw-yuv, (or ) video/raw-rgb, (
or ) video/raw-gray
but i am giving video/x-h264.

Can you guys suggest me how can I use my camera(h264 encoded) for farsigt2.

Thanks,
Bujji
--------------------------------------------------------

ANNOUNCE: Farsight2 0.0.31

Olivier Crête — 2011-10-10T21:09:24

The "THEORA IS BACK" release

Tarball:
http://farsight.freedesktop.org/releases/farsight2/farsight2-0.0.31.tar.gz
Signature:
http://farsight.freedesktop.org/releases/farsight2/farsight2-0.0.31.tar.gz.asc

- Restore Theora functionality that I broke in 0.0.31
- Merged experimental TCP-Friendly Rate Control (TFRC) module, disabled by default
- Support for requesting keyframes on packet loss
- Disables regular keyframes if keyframe requests are supported to ensure smoother streaming

Re: Receiving audio and video streams on the sameport

Auer, Andreas — 2011-10-07T17:07:45

Hi, 

yes, you are right. If the sequence number is continous across all streams it would be hard to find lost frames and so on. But I think demuxing only based on the SSRC wouldn't solve the problem with the sequence numbers at all. I think it would be necessary to give each RTP stream its own continous sequence numbering. 

BTW, the system where I should integrate the new conferencing software is using a proprietary streaming protocol based on RTP. And it uses only one port, one SSRC but different sequence numbers for the audio and video streams.

The transmitter part of farsight looks quite complicated. So, I'm currently thinking about using the RtpBin element (and the others) directly.

Cheers,
Andreas

-----Ursprüngliche Nachricht-----
Von: Olivier Crête [mailto:olivier.crete-ZGY8ohtN/8qB+jHODAdFcQ< at >public.gmane.org]
Gesendet: Fr 07.10.2011 15:46
An: Auer, Andreas
Cc: farsight-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
Betreff: Re: AW: [Farsight-devel] Receiving audio and video streams on

Re: Receiving audio and video streams on the same port

Olivier Crête — 2011-10-07T13:46:48

Hi,

On Fri, 2011-10-07 at 09:27 +0200, Auer, Andreas wrote:

No, multiplexing baed on the payload type is a terrible idea.. Because
the sequence numbers are continous across all payload types, so it makes
it very painful to find discontinuities after you've split it.

The better way to multiplex is by SSRC, but that mean you must decide
the SSRCs in advance and negotiate them, which standard SIP doesn't do.


Yes, if you do it correctly, you only need to change the transmitter
architecture to be able to demultiplex the stream before feeding it into
rtpbin.

Olivier

Re: Receiving audio and video streams on the sameport

Auer, Andreas — 2011-10-07T07:27:56

Hi,

thanks for the answer. Wouldn't it be possible to demux the RTP streams 
with the payload type of the RTP header? I think there is also this rtpptdemux
element.

Just to be sure, only the current transmitter architecture prevents the use 
of the same port!? I guess, the RTP elements (bin, session, source, ...) would 
allow the use of the same UDP port if the RTP streams are demuxed before they
are sent to the gstrtpbin. Is this correct?

Thanks,
Andreas


-----Ursprüngliche Nachricht-----
Von: Olivier Crête [mailto:olivier.crete-ZGY8ohtN/8qB+jHODAdFcQ< at >public.gmane.org]
Gesendet: Do 06.10.2011 16:59
An: Auer, Andreas
Cc: farsight-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
Betreff: Re: [Farsight-devel] Receiving audio and video streams on the same port
 
Hi,

On Thu, 2011-10-06 at 13:41 +0200, Auer, Andreas wrote:

Short answer: currently, no

Longer answer: How do you demux the audio and video if they are on the
same port? Make it work would mean changing the transmitter architecture
a bit