-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multicast stream get stuck with no error #11040
Comments
Hi @OrenMe,
It might not be straightforward to provide assistance without any input data for us to replicate and evaluate. If you're unable to share bug reports or test content publicly, please send them to [email protected] using a subject in the format "Issue #1234" ("#1234" is replaced with your issue number). Please also update this issue to indicate you've done this. |
Hi @rohitjoins , how can I share a multicast stream with you? You need access to the multicast network which requires physical access. |
Hi @OrenMe, Can you repeat your experiments using the demo app and share with us a bug-report. We will be able to get some information from there. |
Hi @rohitjoins, I sent bugreport while playing multicast to email [email protected]. |
thanks for my team mate @tomasgarba for providing additional info! @rohitjoins does this help to investigate? |
@rohitjoins do you have ability to run locally multicast? I am using this method let me know if you need ts example via email |
@tonihei if you could please have a look at the bug report we sent today via mail |
I can provide some additional logs. While zapping to another channel those are two logs when we get stuck: multicast-zapping-2023-04-13-2.txt Maybe this is our issue: AudioFlinger audioserver W createTrack_l(): mismatch between requested flags (00000008) |
Hello @rohitjoins @christosts We have analyzed two sessions that play properly and with stuck. We have found two different behavior of the initialization audio. The main issue on the “problematic” behavior is that the selected Audio track is being stopped/crashed after zapping which mainly effect the whole service to crash. This is mainly explains the change in Audio settings processing/modification by the decoder. Shown by the logs the process structure been made by the player:
We assume It can be related to not well a re-initialization player on decoder layer on zapping. The Player doesn't fully realize the previous channel and starts to initialize the new channel. The mentioned logs are attached: The archive contains two sessions:
|
While I try to replicate your setup, it sounds like there is an issue with the audio decoder Just for clarification, did you try playing the files that you sent to us locally in a playlist on this device? Did you observe any issue with the audio decoder? If there was an issue, that would point to a problem on the device. Otherwise, there may be something in the way the video is transported over UDP, or the player extracts the UDP stream. Either way, that would require more investigation. In the meantime, can you tweak your app to use a custom MediaCodecAudioRenderer that always creates a new codec when there is a stream switch? You need to override MediaCodecAudioRenderer.canReuseCodec(). This is how to achieve this: DefaultRenderersFactory renderersFactory = new DefaultRenderersFactory(context.getApplicationContext()) {
@Override
protected void buildAudioRenderers(Context context,
@ExtensionRendererMode int extensionRendererMode, MediaCodecSelector mediaCodecSelector,
boolean enableDecoderFallback, AudioSink audioSink, Handler eventHandler,
AudioRendererEventListener eventListener, ArrayList<Renderer> out) {
out.add(new MediaCodecAudioRenderer(
context,
getCodecAdapterFactory(),
mediaCodecSelector,
enableDecoderFallback,
eventHandler,
eventListener,
audioSink){
@Override
protected DecoderReuseEvaluation canReuseCodec(MediaCodecInfo codecInfo, Format oldFormat,
Format newFormat) {
return new DecoderReuseEvaluation(
codecInfo.name,
oldFormat,
newFormat,
REUSE_RESULT_NO,
DecoderReuseEvaluation.DISCARD_REASON_APP_OVERRIDE);
}
});
}
};
ExoPlayer exoPlayer = new ExoPlayer.Builder(context, renderersFactory).build(); |
[I accidentally closed the issue, it's open now] |
Hi @christosts I've tried your suggestion and set custom rendersFactory and I override canReuseCodec function and double-check while running in debug mode that code stop at this line. Unfortunately I was still able to reproduce stuck issue. Sending logs while zapping https://www.dropbox.com/t/J3durrCVfwWng1dq |
I'm streaming the ts files provided to us with ffmpeg on mac (version |
We have been sharing a few logs but everything done lately is with exoplayer demo app. |
@christosts
The full is attached. The stuck sessions has been started: Filtered logs of proper session:
Filtered logs of stuck session:
Full logs: |
@christosts some additional findings, @tomasgarba ran additional test following negative mediaPos for the audio comment by @maxmashnitsky and we see that if we see negative position and we seek to 0 playback is unstuck. |
I found this which might be relevant #10887 |
There is a change you're hitting androidx/media#291 So far I have not been able to repro the bug and in your issue description you mentioned this is observed on a Smartlabs device. Have you been able to reproduce on a different device? androidx/media#291 is a bug in the library and should be triggered on different devices. If you only see the issue on the Smartlabs then it's not it. |
We are also reproducing it on ZTE device so it might be this issue. Is there a way to validate this so I can let you know if it is same? We can try to update the threshold as described and check. |
@tonihei in order to verify whether this issue is dup of androidx/media#291, is it sufficient to change the threshold in MediaCodecAudioRenderer to some large(r) value? |
I'm adding additional analysis:
It sounds like this is similar and we might see here that there should be some stopping condition to overcome this. One simple solution we have now is to seek ahead which probably just locks to another part of the stream which has a shorter drift which is under what exoplayer sees as possible to overcome, or just in line with available codec buffer capability. |
@christosts I see androidx/media#291 has been resolved, can I assume this should solve this issue as well? |
I can't definitely say. Can you repeat you tests with the latest Media3 version? The linked commits were not included in the ExoPlayer project and went into Media3 only. |
We are planning to run the tests soon as part of the upgrade to media 3. |
@tonihei do the fix in androidx/media#291 make the player robust of any discrepancy between the audio and video timestamps? |
Yes, but it's impossible to say if it helps with this issue without trying it out :) If someone here can reproduce the issue, please try again with the 1.2.0 release that includes the fixes for androidx/media#291. |
Thanks, we are planning to do so hopefully by EOW and will update here |
ExoPlayer Version
2.18.3
Devices that reproduce the issue
Smartlabs
Devices that do not reproduce the issue
NA
Reproducible in the demo app?
Yes
Reproduction steps
play a multicsat stream when connected to a multicast supported network
same streams sometimes get stuck and sometimes work when switching between them
Expected result
Stream starts playing
Actual result
Stream is stuck randomly after it worked previously, meaning, we played it, changed to other streams and came back to this one and suddenly it is stuck
We observed in the logs errors from codec
OMX.amlogic.avc.decoder.awesome2
We tried to troubleshoot the issue - we excluded
c2.android.aac.decoder
codec and it actually helped to eliminate the issue, streams stopped getting stuck, but this is not a viable solution cause it is on account of having no audio due to excluding of codec.Side note - also surprisingly, removing the codec helped make the streams loading time a lot faster.
here are some strange lines from logs if multicast is not loaded:
what I can see is that by default native buffer info is w:640, h:480 and then some errors while setting resolution:
and then
Media
The stream is multicast and can only be tested on multicast network, so can't share working example
Bug Report
adb bugreport
to [email protected] after filing this issue.The text was updated successfully, but these errors were encountered: