RTSP Server test-launch question

[Joel Holdsworth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tim,

Thanks for your hints. I compiled GStreamer 1.3.2 and plugins from
source, and this fixed this issue and a couple of others.

But now I have a new problem!

I'm trying to connect to  a CCTV video encoding device on the LAN via
RTSP. But since the upgrade rtspsrc has become nearly unusable.

So doing this...

gst-launch-0.10 rtspsrc location=rtsp://192.168.1.51:8554/ufirststream !
application/x-r tp,payload=96 ! rtph264depay ! decodebin ! autovideosink

...works 10 times out of 10, but doing this...

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.51:8554/ufirststream !
application/x-r tp,payload=96 ! rtph264depay ! decodebin ! autovideosink

...only works 2 times in 10. I put in the payload=96 filter, because
there is some bundled metadata that I wanted to make sure was being
discarded.

The RTSP session gets set up, and I can see many incoming UDP RTP
packets in wireshark, but these are never being played. Mostly the video
window never appears.

I tried tweaking the parameters a little, and so far the only parameter
I've found that makes any difference is setting drop-on-latency=true,
which sets gives me a corrupted mess at ~1FPS.

The encoder device uses live555 as it's RTSP server, and it works
reliably via VLC.

Perhaps there's some issue with the device's RTSP server implementation,
but arguably GStreamer should be tolerant of it.

Any hints about the best way to track down the issue?

Thanks
Joel


On 29/05/14 16:18, Tim Müller wrote:
> On Thu, 2014-05-29 at 14:16 +0100, Joel Holdsworth wrote:
>
> Hi Joel,
>
>> I'm trying to set up an RTSP server which plays the video stream
>> directly from a file. I've been experimenting with test-launch:
>>
>> ./test-launch "( filesrc location=/home/joel/Downloads/ToS-4k-1920.mov !
>> qtdemux ! h264parse ! rtph264pay name=pay0 pt=96 )"
>>
>> ./test-launch "( filesrc
>> location=/home/joel/Downloads/Sintel.2010.1080p.mkv ! matroskademux !
>> h264parse ! rtph264pay name=pay0 pt=96 )"
>>
>> I either case the pipeline fails to start correctly when vlc connects.
>> Looking at the debug output, it seems to be having trouble connecting
>> the demux element to the h264parse element. Is there meant to be some
>> other element in there?
>
> No, that looks like it should work, assuming the video is actually H.264
> (although there's no need to have an h264parse before the rtph264pay
> payloader, the payloader should accept all variants of parsed h264
> data).
>
>> Weirdly everything works fine if I do this:
>>
>> gst-launch filesrc location=/home/joel/Downloads/Sintel.2010.1080p.mkv !
>> matroskademux ! h264parse ! decodebin ! autovideosink
>>
>> ...no problem connecting the demux to the h264parse elements.
>>
>> This was all done with gstreamer 0.10 series, which is what was
>> available packaged in Ubuntu 13.10. Should I try gstreamer 1.0 series?
>> What's the most convenient way to get this without messing up my
>> distro's other gstreamer apps?
>
> Yes, you should definitely use the 1.0 series.
>
> I have tried this with git master (1.3.x):
>
>  ~/gst/master/gst-rtsp-server/examples$ ./test-uri file:///path/foo.mkv
> or
>  ~/gst/master/gst-rtsp-server/examples$ ./test-uri file:///path/foo.mp4
>
> and
>
>  $ gst-play-1.0 rtsp://127.0.0.1:8554/test
>
> and that works beautifully.
>
> (Using gst-play from 1.2 I had some problems though, it didn't actually
> start playing, didn't investigate why, looked like it didn't receive any
> data for some reason).
>
> Cheers
>  -Tim
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTiGOtAAoJECNPIH+lv1ju3OMP/18mrBmWys1EV42ZKS/fc1Do
GKAIF6LLMdsstb6NPxKXnetWMezr+YIC7emmqmDb6A3o7jggb5ly5bE8uNCYFK2l
VOUP6MccNu9gyNeUZyAGsjnXGZHQl/CNIKVtPSANcwhHtlDd8rKJAXVCMgTJkcAo
IW2yDae31goLahjzbiW1UCgDZLLQ2u0g5emlllIfc9GSWZqX8xRpt7fGwshuJycz
sa17JNFjQMdFcF2fmVkaE2uqfyqlmycrsZ83/NzQBBorDGODJuHDMRnUl31P+ywl
NOgSsYMo60QjIrv/l/f6a4KmMcfLELy5bVFEzIbK44rmzydHPgJNaBFxRAU892Td
KN2ob1/7baXdevo3l+r70IrW+hrGyofPcO/NhCA7xIdcnuth0GZw72gF2Tiv6/EJ
Uez8+I8ji8TrT0EnVoehnoFf9hG9CstVQEvvvFoYw8M48eWdvYQxujaicAK0dRP7
u1uMP6Ed9Ox9kAk9Pjv4BHjQi2RQRBZbGEZZdWay/rDw35jHAWGUeRUE7sk++h/4
3v2znLD791Sm0s7V+l876Zooff7u1SCl+BEXGUrG3cgOYW0X1BOn1SWbot1xr5h+
FC2VCVD3sH40VyzoRnyQJYhnhR3ucIoAzrmLw8r8X4HZ0X7R+EYRu/k0eEi4ZvCZ
BfTde5jnk4w0pUlRqQzX
=Rgyy
-----END PGP SIGNATURE-----