Open Ajmalnk1836 opened 3 months ago
This error is a generic error when device has been disconnected (by the server, connection lost,...), so it is not easy to debug each case.
As pointed in one of your linked issue, reducing the video bitrate could be a solution.
Instead of VideoConfig.defaultBitrate()
, use VideoConfig(bitrate: 1000000) // in bps
.
When this issue happened, after that mobile got frozen and crashed. It's due to being unable to disconnect by the server side, i think. But how we can resolve this crashing/frozen issue, its fine stopping the stream Instead of crashing/ frozen replay would be appreciated, Thank you
Could you provide the log trace?
Sure,
I/ (21871): Format changed : {max-bitrate=2000000, crop-right=719, level=512, mime=video/avc, profile=8, bitrate=2000000, priority=0, intra-refresh-period=0, color-standard=1, csd-1=java.nio.HeapByteBuffer[pos=0 lim=8 cap=8], color-transfer=3, crop-bottom=1279, prepend-sps-pps-to-idr-frames=0, crop-left=0, width=720, bitrate-mode=1, color-range=2, crop-top=0, frame-rate=30, height=1280, csd-0=java.nio.HeapByteBuffer[pos=0 lim=21 cap=21]}
E/rtmpdroid(21871): WriteN, RTMP send error 104 (12 bytes)
E/rtmpdroid(21871): WriteN, RTMP send error 32 (71 bytes)
E/rtmpdroid(21871): WriteN, RTMP send error 9 (42 bytes)
E/RtmpProducer(21871): Error while writing packet to socket
E/RtmpProducer(21871): java.net.SocketException: Connection error
E/RtmpProducer(21871): at video.api.rtmpdroid.Rtmp.write(Rtmp.kt:139)
E/RtmpProducer(21871): at io.github.thibaultbee.streampack.ext.rtmp.internal.endpoints.RtmpProducer.write(RtmpProducer.kt:94)
E/RtmpProducer(21871): at io.github.thibaultbee.streampack.streamers.bases.BaseStreamer$muxListener$1.onOutputFrame(BaseStreamer.kt:132)
E/RtmpProducer(21871): at io.github.thibaultbee.streampack.internal.muxers.flv.FlvMuxer.encode(FlvMuxer.kt:77)
E/RtmpProducer(21871): at io.github.thibaultbee.streampack.streamers.bases.BaseStreamer$videoEncoderListener$1.onOutputFrame(BaseStreamer.kt:120)
E/RtmpProducer(21871): at io.github.thibaultbee.streampack.internal.encoders.MediaCodecEncoder$encoderCallback$1.onOutputBufferAvailable(MediaCodecEncoder.kt:109)
E/RtmpProducer(21871): at android.media.MediaCodec$EventHandler.handleCallback(MediaCodec.java:1845)
E/RtmpProducer(21871): at android.media.MediaCodec$EventHandler.handleMessage(MediaCodec.java:1743
```)
These are logs I'm getting when this issue happened. The problem is we cannot stop the stream, it's getting frozen. It's happening in an example project also.
Is this log from your emulated Pixel 6 (Android 12) from the example? Does it happen when the stream is starting?
I just tested with a emulated Pixel 6 (Android 12), I don't reproduce this issue.
The issue occurs intermittently during streaming, without a consistent time frame. It can appear after 10 minutes of streaming or sometimes after 20 minutes. I am currently unable to determine the root cause of the problem. is It might be related to the media server ? I am using the Antimedia server.
Ok, These info were missing in your description.
In that case, reducing resolution will help you to have longer live.
Version
v1.2.0
Which operating systems have you used?
Environment that reproduces the issue
Google Pixel 6 (Android 12) ATEX M5
Is it reproducible in the example application?
Yes
RTMP Server
rtmp://broadcast.api.video/s
Reproduction steps
Configured same as example application,
Expected result
The RTMP server could receive the video stream correctly without any interruption.
Actual result
Start stream worked successfully without any interruption, but after some time, middle of streaming time, disconnect event was reported after seconds, throwing errors like 'RTMP send error #39 (54 bytes),RTMP send error #9 (42 bytes)', also phone got freezed, The same issue I had faced in the example application. Since two weeks ago, I have been facing this issue. I could not get what the actual root cause of this issue is. It could be better if someone provided the solution. Thanks The error looks like this:
Additional context
Relevant logs output
No response