Wowza Community

What is ltc and atc and should it be 0

I have a simple SWF that records video and plays it back via rtmp. Every once in a while ( 1 in a 100 ) the recorded video will playback the first frame and then freeze. I can not find a reason for this. The only thing I could find is a log entry that has “send: size:##### ltc:0 atc:0” for the x-comment value. It seems when ever the playback does not work ltc and atc are 0. Any other time there are numeric values.

What is ltc and atc and should they be 0? Is this the heart of the problem.

Thanks

This is most likely the result of network problems on the encoder side during the recording. That is a very low failure rate to try to debug. Let us know if you can replicate the problem. What is the file size of these recordings?

Richard

My guess is that it is caused by network problems on the encoder side.

Are you using StreamType “default” following the Wowza VideoRecording example? Try using Application.xml /StreamType “live-record”, then you only need to publish one stream, and that might fix the occurrence.

Richard

I’m not sure if it makes a difference, or is a factor in this issue, but the VideoRecording example works with StreamType “default”. The installer doesn’t even create a /conf/videorecording/Application.xml, because it is using the /conf/Application.xml

Richard

Scott,

This is most likely an issue with the incoming stream. There is probably not a configuration fix for this. You can look at an incoming stream to see if packets are arriving as expect, or not:

https://www.wowza.com/docs/how-to-use-imediastreamactionnotify2-to-monitor-live-streams-modulestreamwatchdog

Richard

I don’t recall you mentioning that it was all local, I guess I missed that. I’m sure you will track it down, that should make it easier.

Richard

Richard,

Thanks for getting back quickly. Yes it is a very low failure rate to debug. It has been a challenge to even create it. But if you keep at it, it does occur. Do you know what the “send: size:##### ltc:0 atc:0” comment means in the log?

The recordings in my testing are fairly short. A few seconds. So they are around 100 kB. I was guessing that we are running into a race condition because playback does not work, but the FLV is properly created on the server. I have downloaded it and it plays fine in Adobe Media Player.

I just did a test and discovered that even though the FLV is created, if I try to play it back via RTMP I see the entry in the log with ltc:0 and atc:0 and I just see the first frame in the player.

A quick rundown of the code.

  • There are two NetStreams one for recording and one for playback connected to the same server.

  • On stopping the recording process I wait to make sure the recording netstream’s buffer is empty and then I close it.

  • Upon receiving “NetStream.Unpublish.Success” I initialize a new recording netstream and begin playback on the newly created video.

Yes, I am using the Wowza VideoRecording example application. The StreamType was “record”. I changed it to “live-record” and it is still having a problem.

I have been trying things with my swf. I originally was connecting to “videorecording” for recording and playback. I switched playback to “vod” to reduce the factors with the “videorecording” application. I also looked at the AS3 videorecording.fla and noticed it used nsPublish.publish(“null”) to end recording. I was using close(). I played around with those and still had the problem.

I finally went back to look at the FLVs that were problematic. I noticed that the duration value in the metadata was incorrect. My videos were a few seconds long and the duration values were much higher, for example ~60 seconds.

I have version 2.1.2 installed and I do have Application.xml in each of the /conf/“application”/ folders. I did a diff and the only difference between the /conf/Application.xml and /conf/videorecording/Application.xml is the StreamType.

Richard,

I spent more time trying just about any combination and it all comes down to the duration not being set correctly. It will occur on the tenth recording or on the first. I can’t seem to find a configuration that fixes the issue.

Scott

Richard,

Wow… I could have network issues on just a local network. This is just testing from one computer to another within a local network. I will try out the stream watch dog module. Thanks

Scott

I didn’t. The original symptoms showed up on our live and qa instances. I then moved to try and recreate the issue on my local instance. I will let you know what I find.