Audio/Video conversation

[jack_ut]

Thank you for your answer, now it's all clear, you're great

[kakaroto]

of course I am! lol, j/k, you're welcome!

[jones]

I get the aMSN svn version, and I find the SDP messages contain the following line.
"a=x-caps:34 65537:352:288:15.0:256000:1;131074:176:144:15.0:180000:1\r\n"
I guess that 352:288 is resolution, 15.0 is fps, and 256000 is bitrate.
But I don't understand the other parameters.
What does the first parameter(65537) and the last parameter(1) mean?
Is the first parameter a codec profile ID? If yes, how does WLM specify the profile ID in a video streaming? Is it can be changed adaptively?
Thank you.

p.s. My English is not good, sorry about that.

[kakaroto]

Hi jones,
welcome to the forums! some quite good questions there, however, why not take the time to say hi, and tell me a bit more about you and what you're doing? (yes, i'm a very curious person!). I'd like to know what you need this information for? What are you trying to achieve exaclty? Are you writing your own client too ?
anyways, the x-caps attribute was copied the same as what WLM sends, I also don't know about the first and last arguments, it looks more like a bit field (first one is shifted left by 1 compared to the 176x144 one). Amyways, there's no open source implementation of a H263 or msvc1 codec.. the ffmpeg implementation of h263 seems to be incompatible with WLM...
If you find a solution, please let me know! Thanks!

[jones]

Hi kakaroto,
Thank you for your answer.
Yes, I trying to do the video call with WLM2009, and I find solution to solve the ffmpeg issue.
I observe the packets that generate from farsight2 will be fragment in IP layer.
And I trying to set the argument "rtp-payload-size" of ffenc_h263, then it works.... :twisted:
Just set the argument(rtp-payload-size) to the size that smaller than MTU - headers. ex: smaller than 1300.
But the farsight2 does not have the API to set the argument of encoder, or do I miss something?
I set the argument by modify the farsight2 now.
Although it can work well, but I don't know the root cause of this issue, does every packet need to contain the rtp and h263 headers?

Now we have another issue, new p2p protocol of WLM2009.......

[kakaroto]

humm... you stil didn't tell me what client you're working on :p
anyways, I tried that, I tried quite a lot of stuff, I modified gst-ffmpeg directly, it didn't work... I also modified ffmpeg so it can send an event on each GOB so the payloader can correctly packetize it without adding the GOB header, like WLM does, but it still didn't work...
I even tried making the frame  all fit into one single packet but WLM still refused it. I also tried modifying WLM a little to make it accept a bigger MTU, but it still didn't work. So no, something different is wrong. Also, the max payload size should be 1024, not 1300, that's what WLM uses (look at their assembly code).
by the way, ffmpeg has a bug with the rtp-payload-size, even if you set it, it doesn't respect it.. if you want less than 1024, you should set that property to 500 or 600.
Anyways, you said "then it works", I guess you meant "Then it should work", right? were you ever able to make it work correctly some way or another using ffenc_h263? I'd really like to see that!

[jones]

I am trying to let pidgin can do the video call and other features with WLM2009....
It's my mistake. Because I don't have webcam, so I use the videotestsrc instead of v4l2src, and it works with WLM when I set the rtp-payload-size only.
When I find the webcam and use v4l2src to do the video call, and it failed......
But finally it works again. :twisted:
I enable the property "do-timestamp" of v4l2src, and the WLM can see the video of my webcam, but it performance not so good, the video will stop frequently.
And then I look for the difference of v4l2src and videotestsrc. I find out the frame rate of v4l2src and videotestsrc is different, so I add a videorate to source as following (v4l2src -- videorate -- fsrtpconference), and set the frame rate to 30, and the performance looks better. I don't know why....
But the parameters still need to be refine.

[kakaroto]

what :| that's not normal, I spent weeks on that, and I modified ffmpeg, gstreamer and all sorts of stuff and i couldn't find the problem! So you're saying that the rtp-payload-size was the only problem? damn! What WLM did you test it with? was it on Win XP? because I had a windows Vista to test with and maybe the behavior is different in Vista... And yes, I was also using videotestsrc (and I tested with a few different paterns in videotestsrc and I tested with a real cam too)
anyways, thanks for the info, i'll try again now!
By the way, do NOT use videorate, it will just duplicate all your buffers which is very bad considering you are in a live pipeline! The reception was very good for me, but I don't know about sending... I suggest you come talk to us in #farsight, maybe we'll be able to help!
By the way, maybe what made it work for you was different, maybe something in the SIP... could you compare what you do with what aMSN does and see if there's a difference? or allow me to test your code, where can I find it ?
Thanks!

[flomar34]

Hello,

Just to give you some news about my problems with audio call and MSNP18

With the last release.

Amsn didn't freeze anymore when i want't to try an audio call

with amsn => wlm9
and
wlm9 => amsn i can start an audio call but it hang up in the 4 or 5 seconds

the only difference is, as you said, with amsn => wlm9 it starts the audio with the video (before hanging up)

Thanks for all    

[kakaroto]

@flomar34: sorry if i didn't answer you, I found the bug last week that caused it to not work, and its fixed in SVN... it should now work correctly with sending/receiving the audio or video call with MSNP18. Just make sure you use the latest releases of farsight (0.0. and libnice (0.0.6).

@jones: I'm still waiting for more info from you!!!! I'm really stuck and I would gladly accept any help you could give me! Please contact me!

[jones]

Sorry for the later reply.
The WLM that I test the video call is in XP, and I will try this in Vista later. Does that depend on the os?
I will try to use the aMSN to do the video call as soon as I can, and find the different. And then I will told you the result later.
Now in my implementation, I use the following send bin.
(v4l2src -(video/x-raw-yuv)- videorate -(video/x-raw-yuv,framerate=15/1)- videoscale -(video/x-raw-yuv,width=352,height=288)- ffmpegcolorspace) ---- fsrtpconference
and set the "do-timestamp" = true of v4l2src,  "rtp-payload-size" = 256 of ffenc_h263.
I know the videorate is just duplicate the frame but if we don't set the frame rate, the videotestsrc will generate a high bitrate data about 1MB/s...

[kakaroto]

Ok jones, thanks, I'll have a look! By the way, I also tested with win XP and it made no difference, so I don't think it depends on the os!
I will try to use the same pipeline as you and see if it helps, although I doubt it.. we'll see!
If you could provide me with the source code of what you did, so i can do my own sniffing and see what difference there is, I should be able to figure it out hopefully.. It will allow me to work much much faster too...
By the way, you said you patched farsight, can we get the patch? maybe what you changed in farsight is what helped it work... Are you also using the normal gstreamer versions or did you patch the h263 payloader or something like that?
Could you also give me a list of what exact version of gstreamer, gst-plugins-base/good/bad/ugly/farsight and which version of farsight/libnice you are using ? Maybe the versions are different and I should try with the same versions as you...
Thanks!

[flomar34]

Hi,

Just to finish with this .
With the same version of amsn svn i've update to ffarsight2 0.0.9 and gst-plugins-farsight 0.12.11

When vista wml9 ask for a video call, amsn accept it and it works nicely
(video and audio)

Thanks a lot.
Maybe i shoult by a webcam now  

[kakaroto]

flomar34! wait, what?! ok, I know that audio should work, and I know that video reception should work, but you're saying video and audio work nicely, are you saying in both directions? Or is WLM not receiving anything? Because it shouldn't be receiving anything (while we send but WLM refuses to show the cam)...
and if you have no webcam, it's ok, because right now amsn sends a virtual webcam (basically just a pattern image) for testing purposes...
please be clear on what exactly worked! Thanks!

[flomar34]

I have no webcam so of course wlm receive no video (désolé pour la fausse joie)

It's just that i recieve both video and audio (tres fluide).

And amsn didn't hang up anymore as i said yesterday