Live streaming from PiCam


111 posts   Page 1 of 5   1, 2, 3, 4, 5
by Andy Armstrong » Sun Jun 02, 2013 9:15 am
Following on from this thread: h264: possible to force SPS/PPS per GOP? I now have a Pi streaming live to the net.

With any luck you should be able to see the live view from my window here:

http://newstream.hexten.net/picaster/

That's a 900kb/s 720p encode served using HLS. Setup is:

Pi Model B
Pi camera
mounted in a "high top" Pibow case (Pibow + longer screws + spacers + camera mounted on top plate)
Edimax Wifi dongle.

That's on my home broadband and is exposed to the internet on an IPv6 address.

Then there's a hosted box in Germany running a Varnish cache with this config:

Code: Select all
backend default {
  .host = "INSERT PI'S ADDRESS HERE";
  .port = "80";
}

sub vcl_fetch {
  if (req.url ~ "\.m3u8$") {
      set beresp.ttl = 2s;
  }
  if (req.url ~ "\.ts$") {
      set beresp.ttl = 1d;
  }
}


The Varnish caching layer means that the Raspberry Pi only has to serve each fragment at most once and if nobody's watching the stream there's no traffic at all.

The Pi is running a patched version of raspivid that allows the intra period to be set on the command line. Here's the patch. James accepted the patch so I guess it'll make it into a release fairly soon.

Here's the script the Pi's running:

Code: Select all
#!/bin/bash

base="/var/www"
stamp=$( date +%Y%m%d-%H%M%S )
session="live-$stamp"
fifo="live.fifo.h264"

set -x

# bootstrap
for f in www/*; do
  d="$base/$( basename "$f" )"
  [ -e "$d" ] || cp "$f" "$d"
done

mkdir -p "$session"

rm -f "$base/live" "live"
ln -s "$PWD/$session" "live"
ln -s "$PWD/$session" "$base/live"

rm -f "$fifo"
mkfifo "$fifo"

# cleanup
{
  while sleep 60; do
    find "$session" -type f -name '*.ts' -mmin +240 -print0 | xargs -r -0 rm
  done
} &

raspivid \
  -w 1280 -h 720 -fps 25 -g 100 \
  -t 0 -b 900000 -o - | psips > "$fifo" &

ffmpeg -y \
  -f h264 \
  -i "$fifo" \
  -c:v copy \
  -map 0:0 \
  -f segment \
  -segment_time 4 \
  -segment_format mpegts \
  -segment_list "$base/live.m3u8" \
  -segment_list_size 1800 \
  -segment_list_flags live \
  -segment_list_type m3u8 \
  "live/%08d.ts" < /dev/null

# vim:ts=2:sw=2:sts=2:et:ft=sh


The player is JWPlayer. The commercial version of JWP supports HLS on non-Apple devices - so it should play anywhere Flash is available in addition to iPhones and iPads.

I'm hoping to be able to push the bit rate up once BT upgrade my broadband this week.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by towolf » Sun Jun 02, 2013 10:43 am
The Flash part seems to work fairly well. When it’s playing it’s really smooth. It’s only buffering now and then and sometimes there’s a "404 on the m3u8" popup over in the jwplayer.

Are you doing your part to keep up the level of CCTV coverage in Britan, Andy? I saw a man picking his nose crossing the road there.

About this commercial JWPlayer thing. That means if I wanted to only set up one streaming system (i.e., HLS) I would have to come up with $9 a month for this? Put off by this I was looking around and found this promising looking module for nginx on GitHub

https://github.com/arut/nginx-rtmp-module

As far as I understand it I could feed this RTMP enhanced nginx server from an exec statement of "raspivid -o - | ffmpeg -i - -c:v -f flv rtmp://localhost/live/stream" and this module could do the PPS appending and HLS segmentation for me (obviating psips) in parallel to pushing out RTMP for clients. Of course that wouldn’t allow the easy proxying you’ve set up here.

One more thing, I’ve looked around in the MMAL headers and there’s a mention of an H264 variant to produce H264 Annex B and supposedly that makes analysing the stream easier (i.e., for psips)?

And wouldn’t this thread be better placed in the CSI camera forum?
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm
by BPK » Sun Jun 02, 2013 10:49 am
Thanks for sharing Andy this is ridiculously good - both in terms of the live stream quality and the use of such cheap and available technologies (both hardware - raspi and camera, and software ffmpeg etc) to effectively create an enterprise system that could handle huge scale.

Don't suppose you have any solutions for Android up your sleeve as it seems to not particularly (or at all) like HLS?
Barnaby Kent
http://www.pi-cars.com
Control your radio controlled car through your Raspberry Pi
Posts: 30
Joined: Mon Jun 04, 2012 10:12 am
Location: Bristol, United Kingdom
by Andy Armstrong » Sun Jun 02, 2013 10:52 am
I think the flakiness you're seeing is because there's not really enough headroom on my outgoing broadband.

And, yes, it's a pain that there's no free solution for HLS playback on Flash. It would be possible to add HLS support to OSMF - it currently supports Adobe's HDS format which is semantically very similar. It's kind of on my list - but then so are a lot of other things ;)

RTMP works well. I haven't used the nginx module but I've had some success with crtmpserver. This will stream to a local crtmpserver instance:

Code: Select all
#!/bin/bash

url="rtmp://localhost/live/pi"
fifo="live.fifo.h264"

rm -f "$fifo"
mkfifo "$fifo"

raspivid \
  -w 1280 -h 720 -fps 25 -g 100 \
  -t 0 -b 3000000 -o - | psips > "$fifo" &

ffmpeg -y \
  -f h264 \
  -i "$fifo" \
  -c:v copy \
  -map 0:0 \
  -f flv "$url"


And you can play it back by plugging an appropriate into this URL:

Code: Select all
http://osmf.org/dev/latest/debug.html?src=rtmp://RASPBERRY-PI-ADDRESS/live/pi


I'll be interested to hear how it goes with nginx.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by towolf » Sun Jun 02, 2013 10:57 am
Right, I’ve stumbled upon this nginx thing because there is no packaged crtmpserver for Arch Linux and since I’m already running nginx it would cut down on the number of running servers. And it does HLS in parallel. Seems nifty.
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm
by Andy Armstrong » Sun Jun 02, 2013 10:59 am
BPK wrote:Thanks for sharing Andy this is ridiculously good - both in terms of the live stream quality and the use of such cheap and available technologies (both hardware - raspi and camera, and software ffmpeg etc) to effectively create an enterprise system that could handle huge scale.


Yeah, the scale is only limited by the amount of bandwidth you're prepared to buy from content delivery networks - but there's no reason why you couldn't stream to millions of people if you wanted to :)

I love the inversion that you get with Raspberry Pi - it's ridiculously valuable because it's so inexpensive.

BPK wrote:Don't suppose you have any solutions for Android up your sleeve as it seems to not particularly (or at all) like HLS?


I've slightly lost track with what's happening on Android. It got a bit tricky when Flash support was dropped. Theoretically HLS will play - but I haven't got it to work yet. That's also on my list...
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by Andy Armstrong » Sun Jun 02, 2013 11:02 am
towolf wrote:Right, I’ve stumbled upon this nginx thing because there is no packaged crtmpserver for Arch Linux and since I’m already running nginx it would cut down on the number of running servers. And it does HLS in parallel. Seems nifty.


Sounds very good indeed. Please report how it goes.

crtmpserver is very easy to get going out of the box (basically install it and that's it) but I've seen jerky playback once you're a couple of hours into a stream that I can't attribute to any element in the chain apart from crtmpserver. Not sure it's the cause but a good alternative would be useful to know about.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by Andy Armstrong » Sun Jun 02, 2013 11:06 am
Here's the PiCam:

Image

The slice of PI/O was in there so I can hook up some buttons / leds - but I think I'm going to use a remote control instead.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by towolf » Sun Jun 02, 2013 11:13 am
So your m3u8 has 1800 entries with 4s segments giving 2 hours of backlog. But the JWPlayer doesn’t do seeking in the live stream does it? Kind of a downer.

And the HLS clients are supposed to only download byte ranges of the m3u8, i.e. they are not downloading the full 64 kilobytes every 4 seconds?
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm
by Andy Armstrong » Sun Jun 02, 2013 11:22 am
Seeking works on iOS devices. I'm not sure why it doesn't work on anything else - you're right, it should.

You can't make byte range requests for the m3u8 because as entries are dropped off the front the byte offset of everything changes. If it were append only that might work - but the entries actually rotate.

It might help to enable gzip encoding on the server - but I'm not sure if any of the HLS clients are able to accept gzipped payloads.

The other slightly subtle issue is that the m3u8 is only cacheable for 1/2 of a segment duration - any longer and clients won't see it change. That's in contrast to the fragments which can be cached indefinitely.

That means it's possible for more m3u8 traffic to come back to origin. It shouldn't be more than 2-3 requests per segment at most - but it can be a lot more if you misconfigure Varnish.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by towolf » Sun Jun 02, 2013 1:17 pm
Apple seems to recommend gzip compression on the webserver: https://developer.apple.com/library/ios ... aming.html

Also in the pantos spec they wrote: If the Playlist file is distributed by HTTP, the server SHOULD
support client requests to use "gzip" Content-Encoding.


I came up with the byte range request because ffplay seems to do that and throws errors if you restart the stream and hence reset the m3u8. You can put $sent_http_content_range into your nginx log_format and check the access.log. So it appears at least some clients reduce the m3u8 traffic by skipping over segments they already know about.
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm
by Andy Armstrong » Sun Jun 02, 2013 1:26 pm
towolf wrote:Apple seems to recommend gzip compression on the webserver: https://developer.apple.com/library/ios ... aming.html

Also in the pantos spec they wrote: If the Playlist file is distributed by HTTP, the server SHOULD
support client requests to use "gzip" Content-Encoding.



OK, well that's definitely worth doing then :)

towolf wrote:I came up with the byte range request because ffplay seems to do that and throws errors if you restart the stream and hence reset the m3u8. You can put $sent_http_content_range into your nginx log_format and check the access.log. So it appears at least some clients reduce the m3u8 traffic by skipping over segments they already know about.


I'd be interested to see which ranges of bytes they're requesting. I guess you could request a few hundred bytes at the start of the m3u8 to work out which segments had been dropped and then a few hundred at the end to get any new segments.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by mrlinux2u » Sun Jun 02, 2013 3:55 pm
@OP,

Can I ask what port you forwarded on your firewall, I tried this yesterday and no-one could access the stream.

Cheers

mrlinux2u
Posts: 187
Joined: Sat Sep 24, 2011 8:38 pm
by Andy Armstrong » Sun Jun 02, 2013 4:29 pm
mrlinux2u wrote:@OP,

Can I ask what port you forwarded on your firewall, I tried this yesterday and no-one could access the stream.

Cheers

mrlinux2u


In my case it's not a forwarded port - the Pi has an IPv6 address that's routed directly to the internet (using one of Hurricane Electric's IPv6 tunnels). The facade server is also IPv6 enabled and makes requests directly to the Pi's address.

I also had it running over an openvpn VPN - but that was understandably a little sluggish and didn't play too well.

If I was opening a port it'd be 80 - the Pi is serving chunks of video over http - so if it's running a web server on port 80 (I used nginx previously, Apache for this test) and you can see it from the public internet then you should be good to go.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by Andy Armstrong » Sun Jun 02, 2013 5:27 pm
The Varnish config I posted earlier has a problem with Apple devices - which seem to include a cookie with the requests for the m3u8 and fragments. That causes Varnish to treat the request as uncacheable. This config seems to work better:

Code: Select all
backend default {
  .host = "RASPBERRY PI'S ADDRESS";
  .port = "80";
}

sub vcl_recv {
  # Apple devices add a cookie which blows
  # the cache. So we delete it.
  if (req.url ~ "\.(m3u8|ts)$") {
    remove req.http.cookie;
  }
}

sub vcl_fetch {
  if (req.url ~ "\.m3u8$") {
      set beresp.ttl = 2s;
  }
  if (req.url ~ "\.ts$") {
      set beresp.ttl = 1d;
  }
}
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by mrlinux2u » Sun Jun 02, 2013 8:06 pm
Thanks for that, will give it a go :)

Andy Armstrong wrote:
mrlinux2u wrote:@OP,

Can I ask what port you forwarded on your firewall, I tried this yesterday and no-one could access the stream.

Cheers

mrlinux2u


In my case it's not a forwarded port - the Pi has an IPv6 address that's routed directly to the internet (using one of Hurricane Electric's IPv6 tunnels). The facade server is also IPv6 enabled and makes requests directly to the Pi's address.

I also had it running over an openvpn VPN - but that was understandably a little sluggish and didn't play too well.

If I was opening a port it'd be 80 - the Pi is serving chunks of video over http - so if it's running a web server on port 80 (I used nginx previously, Apache for this test) and you can see it from the public internet then you should be good to go.
Posts: 187
Joined: Sat Sep 24, 2011 8:38 pm
by ppumkin » Wed Jun 05, 2013 7:17 pm
This is not really live is it? It is still delayed by 4 seconds? As in if I only wanted to control a quadcopter on LAN I would still crash into my TV and only realise 4 seconds later...

What did the intra refresh period patch actually help achieve?
Posts: 82
Joined: Tue May 29, 2012 10:22 pm
by Andy Armstrong » Wed Jun 05, 2013 7:45 pm
ppumkin wrote:This is not really live is it? It is still delayed by 4 seconds? As in if I only wanted to control a quadcopter on LAN I would still crash into my TV and only realise 4 seconds later...


Well quite :)

As I mentioned on the original thread it's not suitable for any kind of real time control. It's "live" in the broadcast sense - there's necessarily a delay of at least two fragment durations. Currently it's actually running around 16-20s behind real time. Part of the delay is on the server side - you can't advertise a fragment in the m3u8 until it's completely encoded (arguably you could start serving the fragment as soon as it starts to be encoded - but then the encoding time is seen by the client as data transfer time - which misleads its adaptive switching engine) and part of it is due to the client which needs to have at least one fragment in the pipeline at any time to give it a buffer so it can ride out any transient network congestion.

ppumkin wrote:What did the intra refresh period patch actually help achieve?


In HTTP chunked streaming each fragment contains one or more complete gops and the fragments should ideally be of fixed duration - so you need to control the intra period to make sure you get an IDR frame every time you want to start a new fragment.

The fragments are individually completely playable to allow the player to switch between multiple bit rates - which allows it to adapt to the available bandwidth. In order to do that the fragment boundaries (and hence IDR frames) have to line up across all the bit rates - so the player can hop from one bit rate to another while still playing continuously. That's also the reason for piping the h264 stream through psips to add an SPS/PPS pair right before every IDR unit.

When you have a complete stack of bit rates it can do a very good job of adapting to a sustainable rate on any given connection (the profiles the BBC are using run from 64k (32k video, 32k audio) up to more than 2Mb/s in five steps) - that, and the general ease of serving it (because it's all just http - the only slightly tricky thing being making sure everything works with the very short ttls on the m3u8s) are the main advantages.

I'm only doing a single encode on the Pi - so you don't get that adaptive behaviour.

I wrote a bit more about how it works here: http://www.bbc.co.uk/blogs/bbcinternet/2011/06/wimbledon_hd_http_streaming_tr.html
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by ppumkin » Wed Jun 05, 2013 8:00 pm
Thanks for that detailed answer. I am really amazed at the quality of the streaming - just a bit bummed out that real life time is not possible out of the box.

I achieved 1 fps with pseudo mjpg at 720p with less than a second response and realised it is all because raspistill just cannot write a jpg faster than 1 second.(no matter what settings) Tweakin some settings got me about 2fps at 720fps pretty close to real time on LAN.

I managed to achieve 25fps with raspivid pipped into ffmpeg that spat out jpg's and used mjpg server- really bad quality picture and it was not smooth because ffmpeg does not use hardware jpeg encoding and the CPU usage was 100% - Tweaking setting would get a good compromise but bottlenecks just chomp up CPU rendering the Pi useless to anything else :(

Do you anticipate any native mjpg support in raspivid?
Posts: 82
Joined: Tue May 29, 2012 10:22 pm
by Andy Armstrong » Wed Jun 05, 2013 8:18 pm
ppumkin wrote:Thanks for that detailed answer. I am really amazed at the quality of the streaming - just a bit bummed out that real life time is not possible out of the box.


Yup - the Pi camera really is extremely impressive.

It should look better still when I can increase the bit rate from 900kb/s - currently limited by my home broadband up speed. BT are dragging fibre in tomorrow which should improve matters.

ppumkin wrote:I achieved 1 fps with pseudo mjpg at 720p with less than a second response and realised it is all because raspistill just cannot write a jpg faster than 1 second.(no matter what settings) Tweakin some settings got me about 2fps at 720fps pretty close to real time on LAN.

I managed to achieve 25fps with raspivid pipped into ffmpeg that spat out jpg's and used mjpg server- really bad quality picture and it was not smooth because ffmpeg does not use hardware jpeg encoding and the CPU usage was 100% - Tweaking setting would get a good compromise but bottlenecks just chomp up CPU rendering the Pi useless to anything else :(

Do you anticipate any native mjpg support in raspivid?


(raspivid isn't my baby - I just sent a patch that James kindly accepted)

Why mjpeg? If you want to get closer to real time I'd have a look at either streaming over UDP to VLC or using RTMP to a server running crtmpserver (for example) and then a Flash player (OSMF is good, open source, hackable). I did a bit of experimenting with RTMP last week and was getting what looked like sub 0.5s latency streaming RTMP from the Pi (in London) to a server in Germany and back - I didn't measure because that wasn't the main point of the test it but it was very impressive.

As long as you're not using B frames (haven't investigated whether the Pi even can - but it doesn't by default) h264 is capable of low latency. B frames do Bi-directional prediction so they require frames to be streamed out of order - which means that sometimes earlier frames can't be decoded until later frames have arrived. But, as I say, that's not an issue with Pi.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by ppumkin » Wed Jun 05, 2013 8:30 pm
Oh - I forgot to say that I am being anal and want to watch it via browser; My options...

a- Initially I thought dumping the h264 via http to a browser will work fine.. obviously not (yet):(
b- mjpg has support for almost any browser and most of devices. So I tried that but I got crushed with bottle neck with ffmpg :( and raspistill being dead slow at writing jpg's (not sure why -even to ram disk)
c- ditch all that fancy HTML5 and browser stuff and use VLC like you said and nc like in the very first post that I read using "raspivid -t 999999 -o – | nc [insert the IP address of the client] 5001"

Do you think there is any way to allow clients to watch this stream on a desktop browser? or mobile phone app like vlc? or a webcam app or something?
Posts: 82
Joined: Tue May 29, 2012 10:22 pm
by Andy Armstrong » Wed Jun 05, 2013 8:42 pm
ppumkin wrote:Oh - I forgot to say that I am being anal and want to watch it via browser; My options...

a- Initially I thought dumping the h264 via http to a browser will work fine.. obviously not (yet):(
b- mjpg has support for almost any browser and most of devices. So I tried that but I got crushed with bottle neck with ffmpg :( and raspistill being dead slow at writing jpg's (not sure why -even to ram disk)


I'm not much of an authority on which encoding formats the Pi is capable of - so far I've only experimented with h264 - but I wouldn't rule out the possibility that it can GPU encode mjpeg. If it can do jpeg it's not much of a stretch...

However mjpeg is a lot bulkier than h264 for an equivalent quality - so you may still run into an I/O bottleneck with mjpeg that you wouldn't encounter with h264.

But that's just speculation - someone who knows what they're talking about should probably comment ;)

ppumkin wrote:c- ditch all that fancy HTML5 and browser stuff and use VLC like you said and nc like in the very first post that I read using "raspivid -t 999999 -o – | nc [insert the IP address of the client] 5001"

Do you think there is any way to allow clients to watch this stream on a desktop browser? or mobile phone app like vlc? or a webcam app or something?


If you can live with using Flash RTMP is definitely an option. And OSMF is free software in every sense of the word. Flash is problematic on Android these days of course - iPlayer uses a second app to play video - built using Adobe Air which is, basically, how you smuggle a Flash runtime onto an Android device these days.

The only streaming format that's sanctioned for iOS devices is HLS - which means you're stuck with a bit of latency on them. You can minimise the latency by making the fragments as short as possible - but you sacrifice both resilience and bits (key frames are expensive).

Lots of devices like connected TVs support HLS now too - so if you can mitigate the latency to the point where you can live with it it covers a lot of bases.
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by ppumkin » Wed Jun 05, 2013 8:53 pm
Yes. mjpeg is just a bunch of jpegs that get pulled by the client by JavaScript, Java or some native implementation(but that is old school). As you say the Pi has build in hardware JPEG encoding so its just down to the implementation of it. I wish I could do it but I am not that clued up with what's happening in all that code.

I just tried the netcat thing and does not seem to work on my windows machine. I get about 75bytes buffer and it stops there.

Do you have any example how to stream UDP to VLC or the RMTP to crtmpserver?

Thank you so much for the help!
Posts: 82
Joined: Tue May 29, 2012 10:22 pm
by Andy Armstrong » Wed Jun 05, 2013 9:21 pm
ppumkin wrote:Yes. mjpeg is just a bunch of jpegs that get pulled by the client by JavaScript, Java or some native implementation(but that is old school). As you say the Pi has build in hardware JPEG encoding so its just down to the implementation of it. I wish I could do it but I am not that clued up with what's happening in all that code.

I just tried the netcat thing and does not seem to work on my windows machine. I get about 75bytes buffer and it stops there.


Don't have a Windows machine handy I'm afraid.

ppumkin wrote:Do you have any example how to stream UDP to VLC or the RMTP to crtmpserver?

Thank you so much for the help!


You're welcome!

For RTMP to crtmpserver I did this:

https://github.com/AndyA/pivid/blob/master/tools/flv-low.sh

(you can find all the scripts I've been playing with in that repository - http://newstream.hexten.net/picaster/ is currently running hls-low.sh)

Then on ernie.hexten.net (which is a Debian box - the same will work with Raspbian) I installed crtmpserver - it starts when you install it and, as far as I can remember, doesn't need any config for our purposes.

Then to can test the stream using OSMF like this:

http://osmf.org/dev/latest/debug.html?src=rtmp://ernie.hexten.net/live/rapi

You'll notice I've left the name of my server in there - which might be considered a little unwise - but having done that you're welcome to use it for a quick test if you like. If I see the bandwidth go through the roof I'll have to stop crtmpserver - but you should be good for a few concurrent playback sessions ;)

I don't have a working command line for UDP to VLC handy but based on this page I'd say that something like this should do the trick

Code: Select all
$ ffmpeg {whatever input options you need} -c copy -f mpegts udp:192.168.1.19:1234


You should be able to drop that in in place of the ffmpeg invocation in flv-low.sh.

You'd play it like this:

Image


Good luck!
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am
by ppumkin » Wed Jun 05, 2013 9:46 pm
I tried RTSP

Code: Select all
raspivid -o - -t 9999999 |cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/}' :demux=h264


and HTTP
Code: Select all
raspivid -o - -t 9999999 |cvlc -vvv stream:///dev/stdin --sout '#standard{access=http,mux=ts,dst=:8554}' :demux=h264


direct to VLC but I get some error.

I am running as the built in images user Pi, headless with no X. The camera LED goes read and I have permission to use raspivid. When i point my browser to the http setup a file starts to download. But VLC just wont read it.

I also tried the UDP settings you mentioned.. that just stays on a blank screen..

Code: Select all
main debug: adding item `rtsp://192.168.1.104:8554' ( rtsp://192.168.1.104:8554 )
qt4 debug: Adding a new MRL to recent ones: rtsp://192.168.1.104:8554
main debug: rebuilding array of current - root Playlist
main debug: rebuild done - 2 items, index 0
main debug: processing request item: rtsp://192.168.1.104:8554, node: null, skip: 0
main debug: resyncing on rtsp://192.168.1.104:8554
main debug: rtsp://192.168.1.104:8554 is at 1
main debug: starting playback of the new playlist item
main debug: resyncing on rtsp://192.168.1.104:8554
main debug: rtsp://192.168.1.104:8554 is at 1
main debug: creating new input thread
main debug: Creating an input for 'rtsp://192.168.1.104:8554'
qt4 debug: IM: Setting an input
main debug: using timeshift granularity of 50 MiB, in path 'C:\Users\Dell\AppData\Local\Temp'
main debug: `rtsp://192.168.1.104:8554' gives access `rtsp' demux `' path `192.168.1.104:8554'
main debug: creating demux: access='rtsp' demux='' location='192.168.1.104:8554' file='\\192.168.1.104:8554'
main debug: looking for access_demux module: 1 candidate
live555 debug: version 2012.12.18
main debug: no fetch required for (null) (art currently (null))
live555 debug: connection error 404
live555 error: Failed to connect with rtsp://192.168.1.104:8554
main debug: no access_demux module matching "rtsp" could be loaded
Posts: 82
Joined: Tue May 29, 2012 10:22 pm