I'm currently working on my static mosaic setup as a nice basic use of snowmix, i.e. no effects transitions or (to start with) no text or overlays.
I'm currently setting up my version of the "basic" ini used in the tutorials. I've hit a snag when trying to add my feeds geometry.
My cameras output at a 4:3 1280x960 with 25fps. I think I have translated this correctly in my ini file, but snowmix throws errors at me. Any ideas why it thinks my width isn't valid?
ini file: https://gist.github.com/solexious/9976943
snowmix errors: https://gist.github.com/solexious/9976953
You seem to have CSS turned off.
Please don't fill out this field.
You have set your system geometry to 1024x576, but your feeds are 1280x960. Currently Snowmix has the limitation that no feed can have a geometry larger than the system geometry.
You see these errors:
MSG: Invalid width value: 1280
System geometry is 1024 for width
MSG: Invalid number of parameters: "feed geometry 2 1280 960 "
Setting the geometry failed.
MSG: Unable to read file."../frames/dead-704x576.bgra"
The size of the file does not match the geometry. Technically the feed has a size of 0x0 since setting the geometry failed. It's a bug/feature that it claims to be unable to read the file. When you change the system geometry to 1280x960, it will still fail as the file is for a 704x576 geometry.
MSG: Invalid number of parameters: "feed idle 2 100 ../frames/dead-704x576.bgra "
The command failed for the mentioned reasons.
If you want to make a test picture frame for 1280x960, you can use the script in the frames directory. You may have to edit the script to change gst-launch to gst-launch-0.10.
It will create a file called newframe_1280x960.bgra you can rename to dead-1280x960.bgra if you want to use that name.
You have set Pixel Aspect Ratio or PAR of the feeds to 4:3. This means that you want the each pixel to be displayed as 4 by 3 unitless instead of 1 by 1 unitless. This means that your 1280x960 are to be displayed with square pixels as 4*1280/3 x 960 = 1706x960. This is probably not what you want.
PAR is intended for sources that has been generated with non square pixels, but can also be used to change the displayed aspect ratio of feeds when displayed.
Please note that Pixel Aspect Ratio is not the same as aspect ratio of a display.
Let me give you an example.
Old fashion Standard Definition (SD) Television had for PAL 576 lines and a display aspect ratio of 4:3. If you were using square pixels, the geometry would be 4*576/3 x 576 = 768x576 pixels. However to save bandwidth quite often video was recorded with 704x576 pixels where the Pixel Aspect Ratio would be 12:11. So each of the non square pixel would cover 12/11 of a square pixel, which 1+1/11 pixel. 12*704/11 = 768 square pixels. That was a way to reduce bandwidth. Got it?
So what are you tring to do? Is your material encoed with non square pixels? Or are you trying to stretch the displayed feeds? Or what?
Note that PAR only have effect if you are using stack to overlay feeds. If you are overlaying virtual feeds or shape based feeds, you can scale x and y independently to achieve any displayed aspect ratio you desire. One note though, if you are using the Snowmix library scenes.slib to display feeds, PAR will be taken into account when calculating scaling for x and y.
Yep, I noticed my mistake while trying to align the feeds on the screen.
I thought that par just took information rather than effected the video stream, and as my camera aspect ratio is 4:3 I set it there. I've since commented it out in my new post and problem :)
So now you know the difference between PAR and DAR.
I think sf may have swallowed my reply to this. Apologies if this double posts.
I had thought that par just passed the aspect ratio of the feed to snowmix rather than was used to alter it and as my feeds come in at 4:3 ratio I set it to this.
I worked out my mistake when trying to align the feeds on the screen and noticed their aspect ratios had been changed. I fixed this before my latest post below.
Thanks so much for a speed helpful reply as ever!
Thanks for the tip about generating a new test picture, will get this sorted now.
I've got all my feeds setup with the correct size, shifted to the correct place and with nice dead screens.
When I start up the connection to the first feeds camera everything goes well, it shows up still for a second while gstreamer buffers the rtsp stream then starts to play.
But for the other feeds they show up as a still frame for as long as I set the time out with "feed idle" then switch back to the idle image. I'm not sure why.
I'm using a modified version of input2feed for each feed (just a different ip address for each one's SRC) and they work to pipe in feeds for the basic demo, but they don't seem to work correctly here. Any ideas why? The pipelines setup in the input2feed's don't give me any errors.
ini file: https://gist.github.com/solexious/9979345
snowmix output: https://gist.github.com/solexious/9979379
example mod'd input2feed: https://gist.github.com/solexious/9979387
p.s. Is it ok to start up the input2feeds and create the pipelines before snowmix starts?
pps. I've noticed while copying errors that feed 1 will always work fine, and some times 1 or 2 of the others may as well
Are you saying that you have defined a number of feeds and that you have a single script that fetch video through RTSP and feeds it to one of the defined feeds?
And are you saying you can start one of the streams and it works well, but any further streams stall/block/disconnect or whatever?
Does it work if you stream to any of the feed or JUST feed 1?
When you start more than one stream, are the streams getting the video from the same source ?
Can you modify your pipeline to send it to autovideosink and autoaudiosink and make it work.
Try to be more precise and detailed when describing what you do. Try to document it all and document it all so the reader can repeat exactly what you do. Think of it as documenting a lab-report. The current level of precise documentation is close to an F.
So it is insufficient to say "when I start more". Document exactly how you do it and what you do. Scripts, parameters and many more details.
No, you should start Snowmix before the input pipeline. because the script tries to read geometry, frame rate, audio rate, channels etc from Snowmix before seting up a pipeline.
Dont know what you mean by '..noticed while copying errors that feed ..'
My apologies, I do tend to ramble, let me try and word this better.
My current setup:
I have 5 different IP cameras and all are connected to via rtsp
I have 1 script for each camera (total 5 scripts) that connect over rtsp and sinks it to its own feed (eg /tmp/feed1-control-pipe) (the script is a copy of the input2feed script pointing at the ip address of the camera it should control) This is an example of the script I use to start up camera one as feed one (./input2feed1 1) https://gist.github.com/solexious/9979387
I start up snowmix using this ini file: https://gist.github.com/solexious/9979345
I use the ./av_output2screen script to view snowmix
I then start all of my feeds running, i.e. ./input2feed1 1 ./input2feed2 2 etc all in their own terminals.
The feeds will always show up on snowmix's output in the correct place for a moment and then either stay and work correctly, or default back to the idle image. It seems that this can happen to any feeds regardless of what camera or feed they are feeding to. Its doesn't seem to matter how many feeds are already connected correctly, or if a feed has worked before.
If I preform all of these actions, but use the ini file you provide for the basic_feeds example all of the feeds work correctly and show up in snowmix as expected. (apart from feed 5 as there is no feed 5 in the basic_feeds demo)
I hope this is clearer.
Apology accepted. Sorry to act as a school master, but it was needed. ;-)
You say if you are using your ini file, then your streams sometimes or always stops, but if you are using the basic_feeds ini file, then it works? Is this correct?
If that is the case, then copy the basic_feeds ini file to a new file called basic_feeds_no_audio and then in this file comment out the last line where the audio is included. Then try to run it with this new file and see if it works. If it doesn't work with your own ini file, it shouldn't work with this new one either. If it doesn't, then we know your pipeline stalls because of audio not being handled.
Let me know the result.
"You say if you are using your ini file, then your streams sometimes or always stops, but if you are using the basic_feeds ini file, then it works? Is this correct?"
That's correct, but I forgot to mention that I have made one change to the basic_feeds ini and that is to remove the audio include.
So I have already made the change you suggest :)
For what its worth, if I start snowmix with just the basis ini (so none of the animation or text is added) the feeds still load correctly and play.
Okay so if you are using the basis file, then it works, except you only have 4 feeds. Then the solution is to copy the basis to basis-new. Then you change one line at a time in this file to match your own ini and then check that it still works.
First you change the system geometry to 1280x960 and see if it works.
Then you add feed 5 line by line and check for each line, then you change each of the other feeds line by line and make a check inbetween to see it works. Eventually you either end up with everything is working, or you identify the line makes your setup stop working. When you have found when it stops working, you post here with ini files. One that work and one that doesn't work and the two files should only differ by one line.
Hard and tedious work, but that is the only sure way to go forward.
I guess I knew this would be the case but hoped not to have to ;)
I will do this and see how it goes. Thanks again for your help, I owe you many beverages or similar for your help.
I didn't expect to find something so quickly, but the first failure happened when I changed feed 1's geometry to the actual feed size of the camera.
So I worked from top to bottom changing the basis ini file:
Changed the system geometry: (and everything still worked)
system geometry 1280 960 ARGB
Changed the frame rate to the same as my cameras: (and everything still worked)
system frame rate 25
But then I changed the geometry of the feed to the same as the camera outputs, that's when I started getting the same error (image comes up for a few seconds then goes back to the idle image) (I also set the idle image to the correct size for the new feed geometry) :
feed add 1 Feed #1
feed geometry 1 1280 960
feed live 1
feed idle 1 100 ../frames/dead-1280x960.bgra
A link to the whole ini file (including the edit that broke my setup): https://gist.github.com/solexious/9982779
So it seems something to do with setting the feeds geometry, is there a maximum size that snowmix can take or other thing that could be causing this?
So carrying on trying to modify it, feed one will start working normally again if I change the ini file from
feed geometry 1 1280 960
feed geometry 1 1279 960
or if I make the width anything less than 1280.
Will continue to fault find :)
This doesn't seem to be strictly true, I have since had some of my video not starting correctly errors with 1279 960 feed geometry, but it seems the closer I get to 1280 960 the more likely thing will break. Leaving it at the basis default feed geometry of 704x576 has never produced an error so far.
So on a hunch I thought I would go back to the input2feed script and see if I could think of anything there.
I wondered if it could be something to do with the shmsize, so I doubled it:
This seems to have fixed the problem and I can now run all of my camera feeds at the 1280x960 and have them show up in snowmix correctly each time.
Would changing shm-size sound like a reasonable cause and fix for this? I just guessed at doubling it, would you recommend a different size?
I did a very happy dance around my office when it started working :)
t makes sense. In your case, where it does not work, you are not scaling down. However due to changes in GStreamer 1.2.x, the pipeline freezes if it doesn't have enough frames. Enough frames is decides by the shmsize.
In not yet released 0.4.4, I set the shmsize to this
shmsize=`echo "$feed_width * $feed_height * 4 * 11"|bc`
That's 11 frames. in your case its 12809604*11 = 54067200.
So just change the line with SHMSIZE= to
SHMSIZE='shm-size='`echo "$feed_width * $feed_height * 4 * 11"|bc`
That should fix it.
Sign up for the SourceForge newsletter: