问题标签 [exynos]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
android - 几秒钟后 WebRTC 远程视频冻结
在 android 和 iOs 之间调用时使用 SurfaceViewRenderer 显示远程视频轨道时遇到问题（android <-> android 和 ios<->ios 也可以）
Android 上的远程视频视图将在几秒钟后冻结，但音频仍然有效（iOS 没问题）。
可能是iOS的H264编解码器导致的问题，但是我按照最新的code进行decode和encode PeerConnection，所以还是卡在这里。
下面是我的代码：
创建PeerConnectionFactory：
解码和编码
SDP 内容
更新 我们找到了这个问题的原因，由于未知的原因，在 Android 端接收到的数据变低并且不再上升，这就是为什么视频被冻结
以下是视频冻结时收到的日期值
但我不知道为什么会这样
有人对我的问题有建议吗？任何回应将不胜感激。
android - Play store更新问题64位处理器（32位模式）
在 google play store 64 位应用程序要求之后，我更新了 gradle 文件中的 abi 过滤器。我在 64 位智能手机中测试了应用程序，我没有遇到任何问题。我上传应用商店。一段时间后，我得到了三星智能手机用户的一些回应。他们说我不会更新应用程序谷歌游戏商店，即使我的手机是新的。（设备三星 sm-a710f 和 sm-j530f。）
我搜索了两个设备处理器。他们有 64 位处理器，也有三星 exynos 处理器。最后一件事，我找到了 sm-a710f 设备并安装了 aida64。我在处理器标签中看到 64 位 armv8-a（32 位模式）。
总结，有没有人因为 armv8-a (32-bit mode) 的原因不更新应用程序？或者有没有人经历过这种情况？
谢谢。
flutter - 颤振与 exynos cpu/gpu 有问题吗？
我正在编写一个简单的应用程序，它有一个堆栈，背景是移动动画，前面是简单的文本字段。在调试模式下的模拟器上，该应用程序比在我的 Galaxy J6 上运行更流畅。UI 帧为 3-4 毫秒，但 GPU 线程平均显示 23-25 毫秒和 30-48 fps。
我看到另一个关于 exynos cpu 问题的帖子，但由于一些声誉问题，我无法在那里发表评论。我还检查了耀斑示例并运行了企鹅动画，它的响应式 UI 比我的要差，但 GPU 正在努力工作。
一个建议？
这是我的颤振医生：
android - 与采用 h264 的 Exynos 设备相比，Snapdragon 设备的解码延迟更高
我观察到对于相同价格范围内的设备，基于 Snapdragon 的解码器可以比基于 Exynos 的解码器具有更高的解码延迟。这在解码 H264 流时，SPS 中的值“pic_order_cnt_type”设置为 0 而不是 2 时最为明显。我想知道您是否也观察到这种行为以及是否有任何解决方法（我已经在这里打开了一个问题但目前没有回应）
一些技术细节：
我已经构建了一个简单的示例应用程序，它使用 AMediaCodec 来解码 h264 流。它将“解码延迟”作为测试结果上传到 Firestore 数据库。代码
以下是 Pixel 4（使用 snapdragon 解码器）和三星 Galaxy Note 9（使用 exynos 解码器）上不同 h264 流的解码延迟比较：
| 像素 4 | 银河注 9 |
|---|---|
 |
 |
如您所见，对于名为 jetson/h264/2/test.h264 的视频，snapdragon 设备的解码时间比三星设备高约 21 倍。此流的 pic_order_cnt_type==0。然而，在其他流上，解码时间的差异是微不足道的。（他们都使用 pic_order_cnt_type==2）
决定骁龙解码器是否进入“低延迟解码路径”的主要参数似乎是上面提到的 pic_order_cnt_type 值。如果我正确理解 h264 规范，如果此值设置为 2 图片重新排序是不可能的（没有缓冲帧）。如果设置为 0，图片重新排序是可能的，但编码器不必使用。但是，snapdragon 解码器并没有区分“可能”和“编码器实际使用”，导致解码延迟差异很大。
我能够通过在将比特流发送到解码器之前对其进行操作来减少 snapdragon 的解码延迟（添加带有 num_reorder_frames=0 和 max_dec_frame_buffering=0 的 VUI），但它永远不会导致 0 个缓冲帧，只会产生更少的缓冲帧。
android - E/ExynosCameraNode 中的这个错误是什么？
我在 Android Studio 中使用带有三星 S10+ 的相机 2 拍摄和保存照片的过程中发现了一个错误。
安卓版本：11
内核版本：4.14。113-22340597
而且...这是错误结果
E/ExynosCameraNode: [CAM(0)][FLITE]-(m_dqBuf[1660]):exynos_v4l2_dqbuf(fd:29) 失败 (-1)
E/ExynosCameraMCPipe: [CAM(0)][PIPE_3AA]-(m_getBuffer[2118]):node(FLITE)->getBuffer() 失败, index(-2), frameCount(7), ret(-1)
E/ExynosCameraFrame: [CAM(-1)][]-(setSrcBuf[3233]):无效缓冲区状态(3)
E/ExynosCameraFrame: [CAM(0)][]-(setSrcBuffer[273]): 无法设置 src 缓冲区，ret(-38)
E/ExynosCameraMCPipe: [CAM(0)][PIPE_3AA]-(m_getBuffer[2154]):0's setSrcBuffer fail, fCount(7), pipe(5), ret(-38)
E/IndicatorGardenAlgorithmBasicCutout: NOT MATCH !!!! resourceHeight:108, cutoutHeight:107 ([IndicatorGardenInputProperty] Rotation(0-0,90-1,180-2,270-3)0, Density:2.625, ScreenWidthSize:1080, CoverSidePadding:0, mIndicatorGardenCenterOffset:11, mCameraCutoutCropSize:0, mGardenPaddingStart:21 , mIndicatorCornerPadding:56, mCameraSidePadding:25, mCameraTopMargin:24, DpCutout:DisplayCutout{insets=Rect(0, 107 - 0, 0) 瀑布=Insets{left=0, top=0, right=0, bottom=0} boundingRect ={Bounds=[矩形(0, 0 - 0, 0), 矩形(836, 0 - 1080, 107), 矩形(0, 0 - 0, 0), 矩形(0, 0 - 0, 0)]} })