You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the report and the ffprobe output, that made the size problem easy to find.
Size. The app took the size from the decoder's output buffer, which is padded to the decoder's alignment, and not from the visible picture (the crop rectangle):
H.264 1080p showed as 1920×1088 (16-line macroblocks). This happens on every device.
On your device the H.265 decoder pads the width as well, so 1920×1080 became 2304×1088. The single view also fitted the picture to that size, so the picture was probably squeezed horizontally (2.12:1 instead of 16:9).
The fix is in #167: the size now comes from the crop rectangle. I'll post here when the build is released.
Higher resolution does not start. This is probably a separate problem. Could you tell us:
Which device is it (model, Android version)? The menu next to Exit shows the app version.
Which stream does not start: resolution, codec, fps (ffprobe output like above)?
What the screen shows: an error text, a black picture, or the status?
If possible, http://<device>:8085/stats.json and http://<device>:8085/log while it fails (check that no password is in the log).
The output-buffer width 2304 suggests the decoder aligns to a large block size, so its resolution limit can also be lower than expected. stats.json lists the decoders and the frame rate each one supports at 1080p.
Also, H.264 showed out_fps: 12 while the camera sends 25. Did the H.264 picture look jerky?
The size fix is released in v2.04 (#167). On our test box 1080p streams now show as 1920×1080 (H.264 and H.265, before: 1920×1088), and 720p as 1280×720. On your device the H.265 stream should show as 1920×1080 instead of 2304×1088, and the single view should keep its 16:9 shape.
Could you check it, and send the details asked above for the higher resolution that does not start?
Thanks, the log helped. When the app connects to the 2304×1296 stream, OMX.rk.video_decoder.avc starts and allocates its buffers but never outputs a frame, while 1080p from the same camera plays. So it isn't a size-detection problem but a decoder setup one: the app configures the decoder for a small picture and lets it learn the real size from the stream, and this Rockchip decoder apparently doesn't grow beyond 1080p that way.
There's a test build that tells the decoder the largest picture it supports up front (single view only):
Could you try 2304×1296 in H.264 and H.265 with it? If it still doesn't play, please attach http://<device>:8085/log again. With this build it should have a line Decoder OMX.rk.video_decoder.…: pictures up to ….
Activity
compot-dev commentedon Oct 14, 2026
Thanks for the report and the ffprobe output, that made the size problem easy to find.
Size. The app took the size from the decoder's output buffer, which is padded to the decoder's alignment, and not from the visible picture (the crop rectangle):
The fix is in #167: the size now comes from the crop rectangle. I'll post here when the build is released.
Higher resolution does not start. This is probably a separate problem. Could you tell us:
http://<device>:8085/stats.jsonandhttp://<device>:8085/logwhile it fails (check that no password is in the log).The output-buffer width 2304 suggests the decoder aligns to a large block size, so its resolution limit can also be lower than expected.
stats.jsonlists the decoders and the frame rate each one supports at 1080p.Also, H.264 showed
out_fps: 12while the camera sends 25. Did the H.264 picture look jerky?Merge pull request #167 from OpenIPC/fix/visible-size-166
compot-dev commentedon Oct 14, 2026
The size fix is released in v2.04 (#167). On our test box 1080p streams now show as 1920×1080 (H.264 and H.265, before: 1920×1088), and 720p as 1280×720. On your device the H.265 stream should show as 1920×1080 instead of 2304×1088, and the single view should keep its 16:9 shape.
Could you check it, and send the details asked above for the higher resolution that does not start?
fix: picture size from the decoder's crop rectangle, not the padded b…
Merge pull request #167 from OpenIPC/fix/visible-size-166
sansarus commentedon Oct 16, 2026
1080p show correct size and fps.
bigger - stil not work ("version": "2.13")
Stream #0:0: Video: hevc (Main), yuvj420p(pc, bt709), 2304x1296, 25 fps, 25 tbr, 90k tbn, 25 tbc
Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 2304x1296, 25 fps, 25 tbr, 90k tbn, 50 tbc
stats.json see codec change but not recognize resolution (decoder show freeze image since 1080p )
log.txt
compot-dev commentedon Oct 16, 2026
Thanks, the log helped. When the app connects to the 2304×1296 stream,
OMX.rk.video_decoder.avcstarts and allocates its buffers but never outputs a frame, while 1080p from the same camera plays. So it isn't a size-detection problem but a decoder setup one: the app configures the decoder for a small picture and lets it learn the real size from the stream, and this Rockchip decoder apparently doesn't grow beyond 1080p that way.There's a test build that tells the decoder the largest picture it supports up front (single view only):
APK: https://github.com/OpenIPC/decoder/releases/download/hy300-166-test1/decoder-hy300-test1.apk
(version 2.14,
6dd18a2; it installs over 2.13 and keeps the settings)Could you try 2304×1296 in H.264 and H.265 with it? If it still doesn't play, please attach
http://<device>:8085/logagain. With this build it should have a lineDecoder OMX.rk.video_decoder.…: pictures up to ….