Are you solved the problem? Can anyone help, we have the same issue.
Acknowledged...I think we will try to see if we can reproduce this in-house/
I guess we know what the problem is.
AMS allows max 10 stsd entries in an MP4 while recording which means you cannot change properties such as bitrate/ frame rate more than that count.
This is what is happening when using the setQuality() call on publisher.
My suggestion would be to create separate MP4 files since we know that it cannot record more than 10 entries.
Another and better alternative is to use the bandwidth detection feature of AMS and stick to one quality settings rather than changing it on the fly n number of times.
bandwidth detection is documented here Adobe Flash Media Server 4.5 * Detecting bandwidth
Where does that limitation comes from? First time I hear about it! So you are saying that when we are publishing / recording a mp4 (f4v as well?) file, we mustn't use setQuality more that 10 times? By the way, what does "stsd" stands for?
Also, is there other manipulations like this that can have the same effect? For instance, attaching or detaching a microphone from the stream while the video is still publishing? Because we had random problems with the recording of h264 streams and we still are unable to find what is the source of the problem...
stsd stands for sample descriptor entries in an MP4 file. The limitation is on AMS end. thing is you need to allocate certain memory for these entries at start of recording and hence you need to be aware of the total entries you want to support.
10 seems like a good number and had worked well for customers. Ideally people setup MBR streams rather than changing the quality parameters.
bitrate, frames, video size are few parameters that i am aware can lead to multiple stsd entries.
Thanks for quick reply! Do you have any documentation on this? Say I would like to allocate more memory in order to be able to support more stsd, how do I proceed and how many more entries will I be able to make? Our problem is that we use this feature in a meeting that can last up to many hours. If the stream is published during that period, it is possible that the publisher stops the audio or video at times so it's a bit unpredictable. We would like to know more about those concerns and thus be able to come up with a solution.
So just to be sure, if I ran pasted in the max stsd, I would get an NetStream.Record.NoAccess, the record would stop and I have no more info on that?
In case the stsd entries are full you will see something like "no Space left in the stsd box" in the error logs. I would suggest to avoid this error by determining the bandwidth and then sticking to that for rest of the meeting rather than changing the quality throughout the duration of the meeting.
And for the problem where the publisher stops the audio or video, i dont think that would lead to the above error. I guess you are mixing two different problems here.
Ok but then, why could that be your answer? The problem is stated as "Stream records for sometime and then gives Stream.Record.NoAccess"?! So basically, you're saying that the stsd has nothing to do with that error? Don't mean to be rude, just to get an answer to this problem!! Thanks!
There could be multiple reasons for the record no access error and stsd entries full is one of them as reported and referenced in the original question.
From the referenced thread,
2011-09-21 11:27:59 726 (e)2611178 Error from libmp4.so: No Space left in the stsd box. - 2011-09-21 11:27:59 726 (e)2611423 Failed to record vc_live/upload/recorded/ab91a04be0d3669bdf80d645b6413362db69a09f.mp4 (Unknown Error). -
stsd entries in mp4 file in AMS can be modified by chaning config in server.xml vide <Mp4><Recording><MaxDataSampleDescriptions>...the current default is 10 and can be changed to any suitable value.