Database Info

[Feature Request] .ts file is not HW-accelerated but repacked to MKV is

Hello,
When I try to play .ts file (e.g. HBO HD movie) recorded using DVB-C set-top box, MXPlayer uses SW mode and playback looks like a slideshow.
So I have repacked the same movie to MKV container using mkvmerge and followed the advice from this forum to configure MXPlayer to use HW acceleration for video and SW mode using custom codec for audio (for AC3 decoding). Playback is perfectly smooth in this case, because MXPlayer uses HW acceleration.
The original TS file contains:
- H264 1080i PAL 50fps track
- 1st AC3 audio track
- 2nd AC3 audio track
- 1st DVB subtitle track
- 2nd DVB subtitle track
The repacked MKV file contains:
- the same H264 track (w/o recoding)
- the same 1st AC3 audio track (w/o recoding)
(mkvmerge cannot convert DVB subtitles, so in MKV file the subtitle track is missing)
I have the Acer Iconia A1 810 tablet.
Repacking to MKV is an option to play my recordings smoothly, but I'd like to play the original TS files from SMB share, because my archive is full of such TS files. Repacking is hard and slow and additionally it'd throwed the subtitles away.
Please, is it possible to modify MXPlayer so it can play also the TS files in HW accelerated mode?
Thank you in advance!

I doubt it, because the ts container can contain so much more incompatible formats and as you probably know, AC3 for instance is not hardware supported on most devices. You cant go and force hardware decoding for something that might-half-work, but you always have the option to select your decoder and try. I'm afraid you'll just have to accept that there's some things your hardware can't decode.

Note that the smooth playback is not a problem in my case. Repacked in MKV container, my hardware plays both the mentioned tracks (H264+AC3) smoothly.
What I ask the MXPlayer team for, is to enable the same MXPlayer behavior for the original TS container file containing the same tracks (H264/AC3).
In my opinion, the MKV container is the same case as the TS container. MKV file can also contain almost anything.
I've thought that the decision to use (or not to use) HW acceleration for a video track should come after a splitter, on the basis of the video format and should not be derived from a container file format.

Hmm, that is odd. Sorry I assumed the AC3 track would've been incompatible, as it is with many androids. I always thought MX Player did decide on HW acceleration independent of containers. I can only guess some track contained in the .ts is incompatible.
But have your tried forcing HW playback (or HW+) on the .ts file yet? You can select this in the top right while a video is playing.

I thought that HW support of different containers depended on the device. Not sure.
I would think that when you select HW, it not only passes the decoding, but also the container splitting, to the hardware, which is my guess at why HW won't support different containers since the hardware doesn't know how to split the container.
@bleu8888 could you provide some insight into this?

CDB-Man said:
I thought that HW support of different containers depended on the device. Not sure.
I would think that when you select HW, it not only passes the decoding, but also the container splitting, to the hardware, which is my guess at why HW won't support different containers since the hardware doesn't know how to split the container.
@bleu8888 could you provide some insight into this?
Click to expand...
Click to collapse
Thank you CDB-Man and Logic_ for your thoughts.
In MX Player, it is possible to use HW decoder for a video track in parallel (and in sync) with SW decoder for an audio track. That is why I hope, that a container-splitting can be done independently on choice which decoder will be used for the given track.

My understnading is that splitting is done by whatever is set as the video decoder in MX. Audio decoder just receives the audio stream from whatever splitter is used. It's not that SW audio runs "in parallel" with HW video per se; SW or HW audio just receives an audio stream from whatever is used as the container splitter.

Sorry, my previous post was probably somewhat misleading.
It was reaction to your post:
CDB-Man said:
I thought that HW support of different containers depended on the device. Not sure.
I would think that when you select HW, it not only passes the decoding, but also the container splitting, to the hardware, which is my guess at why HW won't support different containers since the hardware doesn't know how to split the container.
Click to expand...
Click to collapse
I wanted to say, that from the fact, that video can be independently decoded by HW and audio by SW, I presume, that splitting can also be done independently - by SW - while maintaining the players ability to pass video track decoding to HW.

Hi KodloN,
Did you try hw+ decoder? hw decoder is just stock decoder which has no chance to be improved at all.
If you it still does not work with hw+ decoder, please send me (to [email protected]) a sample .ts file that cannot be played with hw+ decoder.
Thanks

bleu8888 said:
Hi KodloN,
Did you try hw+ decoder? hw decoder is just stock decoder which has no chance to be improved at all.
If you it still does not work with hw+ decoder, please send me (to [email protected]) a sample .ts file that cannot be played with hw+ decoder.
Thanks
Click to expand...
Click to collapse
Hi bleu8888,
Yes, I've tried hw+ decoder, below are results:
1) The original TS file (HBO_HD recording)
SW decoder only. Trying to switch to HW or HW+ decoder falls back to SW with error message "Cannot play this video with H/W(+) decoder".
2) TS file in which the DVB subtitle track and the Czech audio track were removed (repacked by DVBViewer-TSPlayer)
HW+ decoder is functional, but playback is sluggish on my Acer Iconia Tab A1-810 (similar performance as SW decoder playback)
HW decoder cannot play this video.
3) MKV file created from the original TS file using mkvmerge
HW decoder is functional, perfect smooth playback
HW+ decoder cannot play this video
I will send you a link to all three files to the specified email.
Thank you in advance!

Hi,
Would you try latest test build from following link?
.ts hw+ playback is improved in this test build but I'm not sure your issue is fixed because this issue looks like happening only on MediaTek platforms and I do not have device having MediaTek playform.
(Please note that hw playback is not changed though)
https://sites.google.com/site/mxvpen/translation/test-build
BTW, DVB subtitle positioning issue is also fixed.
Feedback will be appreacited !
Thanks
KodloN said:
Hi bleu8888,
Yes, I've tried hw+ decoder, below are results:
1) The original TS file (HBO_HD recording)
SW decoder only. Trying to switch to HW or HW+ decoder falls back to SW with error message "Cannot play this video with H/W(+) decoder".
2) TS file in which the DVB subtitle track and the Czech audio track were removed (repacked by DVBViewer-TSPlayer)
HW+ decoder is functional, but playback is sluggish on my Acer Iconia Tab A1-810 (similar performance as SW decoder playback)
HW decoder cannot play this video.
3) MKV file created from the original TS file using mkvmerge
HW decoder is functional, perfect smooth playback
HW+ decoder cannot play this video
I will send you a link to all three files to the specified email.
Thank you in advance!
Click to expand...
Click to collapse

[Feature Request] MX Player needs a new option for network streams

My device is a Samsung Galaxy Tab S 8.4 using Lollipop 5.02
I use MX Player Pro for decoding RTP-Streams from the ip-tv platform t-Entertain in Germany. These RTP-Streams uses MPEG-4 AVC/MEG-4 part 10 Codec.
I also own a NAS containing all my videos. Streaming videos from NAS using HW+ Decoder to MX Player works fine. But videos from RTP-Streams to MX-Player
do not! The reason is: MPEG-4 AVC/MPEG-4 part 10 have to decode in software mode on my device! But both streams (Nas-Videos and RTP-Streams) come from network.
There is no option in MX Player to set NAS-Streams to HW+ and RTP-Streams to SW! A workaround will be to set both to SW. But this is not state of the art!
So please give MX Player an option, to set "network streams" separate to SW or HW+ mode.
Best regards to the developers and to the Forum
Andro Uno

Andro Uno said:
My device is a Samsung Galaxy Tab S 8.4 using Lollipop 5.02
I use MX Player Pro for decoding RTP-Streams from the ip-tv platform t-Entertain in Germany. These RTP-Streams uses MPEG-4 AVC/MEG-4 part 10 Codec.
I also own a NAS containing all my videos. Streaming videos from NAS using HW+ Decoder to MX Player works fine. But videos from RTP-Streams to MX-Player
do not! The reason is: MPEG-4 AVC/MPEG-4 part 10 have to decode in software mode on my device! But both streams (Nas-Videos and RTP-Streams) come from network.
There is no option in MX Player to set NAS-Streams to HW+ and RTP-Streams to SW! A workaround will be to set both to SW. But this is not state of the art!
So please give MX Player an option, to set "network streams" separate to SW or HW+ mode.
Best regards to the developers and to the Forum
Andro Uno
Click to expand...
Click to collapse
We will try adding option for selecting decoder based on network protocol.

+1
I need to work with my nas
Tnx

Is it working by now with the individual streams from http://iptv.blog/artikel/multicastadressliste/ ?
Or does MX Player even handle one of the playlists (more akin to DVB bouquets actually) provided there (FKA http://grinch.itg-em.de/entertain/downloads/playlist.php?ETV&xspf etc.).

[Q] Weird continuous back and forth seeking while streaming through HTTP

I have been knowing that MX Player stutters when playing some video file through HTTP streaming from a file manager app that converts SMB to HTTP, but not when playing the same file from local storage. I posted a question about that [Q]Stutters only while streaming (probably NOT the bandwidth issue).
I have been so annoyed by this problem, and tried to find out why. So, I created my own streaming application that launches MX Player or VLC Player. For some files, VLC had no problems but MX Player stuttered. The problem seems to be that MX Player is continuously making a lot of HTTP requests with back and forth ranges. For example, the requested ranges are like the following.
Range: bytes=0-
Range: bytes=308216864-
Range: bytes=36-
Range: bytes=31734357-
Range: bytes=555441-
Range: bytes=31734374-
Range: bytes=557632-
...and so on
Click to expand...
Click to collapse
MX Player sent about 400 range requests during about 15 seconds. These requests seem very unnecessary and caused CPU usage spike. I think the high CPU usage might be the cause of the stuttering. When the SMB to HTTP server was runing on my computer, not on the Android device, MX Player made the same amount of range requests but did not stutter. The HTTP server in either case is the same thing because I wrote it from scratch using Java.
VLC did not make these back and forth range requests for the same video file. VLC only made 3 range requests during the same period.
Please see the attached logs for full request/response details. I started playing the mp4 file from the beginning, and left it for about 15 seconds, and I did NOT manually seek the video.
Why is MX Player doing this?

A network stream over HTTPS seems only to be able to use the HW decoder.

A network stream over HTTPS seems only to be able to use the HW decoder. I noticed this with my own content, but I have put some files online to demonstrate the issue.
I put copies of Big Buck Bunny converted to x264 in an mp4 container and to HEVC in a matroska container on a webserver with both HTTP and HTTPS.
As I cannot post urls here, links to all files are available at https://box.7r.pm and can be streamed to a device to test.
Results of the streaming:
- HTTP and h264, mp4 > Plays fine and I can choose any decoder (HW, HW+ or SW).
- HTTPS and h264, mp4 > Plays fine but I cannot use anything but HW decoder ("HW+/SW decoder is not supported" error)
- HTTP and HEVC, mkv > Plays fine use HW+ or SW decoder (HW fails but expected outcome, no HEVC support)
- HTTPS and HEVC, mkv > Plays with no Video using HW decoder, attempt to switch fails ("HW+/SW decoder is not supported" error)
Device: Nexus 5 and Nexus 7
Version: 1.8.9 (ARMv7 NEON)
Now the file that is served is identical over HTTP and HTTPS, both file play correctly if downloaded to the device and played locally (the same as if over HTTP).
I could not find a bug report similar, but could not quite believe I was the first person to notice/be affected by this.
Any help?

thechriswalker said:
A network stream over HTTPS seems only to be able to use the HW decoder. I noticed this with my own content, but I have put some files online to demonstrate the issue.
I put copies of Big Buck Bunny converted to x264 in an mp4 container and to HEVC in a matroska container on a webserver with both HTTP and HTTPS.
As I cannot post urls here, links to all files are available at https://box.7r.pm and can be streamed to a device to test.
Results of the streaming:
- HTTP and h264, mp4 > Plays fine and I can choose any decoder (HW, HW+ or SW).
- HTTPS and h264, mp4 > Plays fine but I cannot use anything but HW decoder ("HW+/SW decoder is not supported" error)
- HTTP and HEVC, mkv > Plays fine use HW+ or SW decoder (HW fails but expected outcome, no HEVC support)
- HTTPS and HEVC, mkv > Plays with no Video using HW decoder, attempt to switch fails ("HW+/SW decoder is not supported" error)
Device: Nexus 5 and Nexus 7
Version: 1.8.9 (ARMv7 NEON)
Now the file that is served is identical over HTTP and HTTPS, both file play correctly if downloaded to the device and played locally (the same as if over HTTP).
I could not find a bug report similar, but could not quite believe I was the first person to notice/be affected by this.
Any help?
Click to expand...
Click to collapse
I have checked with another ffmpeg based popular Player. It's also having similar issue.
From MX Player logs, I have observed that ffmpeg throws "Unable to negotiate TLS/SSL connection". Probably the ffmpeg build used may not support the modern choppers used for encryption.
I have intimated the issue to the MX Player developer. Hope it will be fixed in the next version.
If it's possible Kindly keep the server up. It will be helpful for the developer to resolve the issue.
Sent from my SM-G900H using Tapatalk

Thanks, it is nice to have the problem validated at least - I never thought to try one step lower at the ffmpeg level. I'll keep the box online for the foreseeable future.

Low video quality unsing HW+ decoder

hi,
I have an Minix U9-H box (android 6.0) and when I play full HD streaming files from my ip tv provider using HW+ decoder, the video quality is poor. It's working fine with HW or SW decoder (The codec used by mx player is ARM V7 NEON).
I checked also in perfect player and when using HW+, it seems the player downgrade the video resolution to SD format.
Any clue ?
Chris

rusukof36 said:
hi,
I have an Minix U9-H box (android 6.0) and when I play full HD streaming files from my ip tv provider using HW+ decoder, the video quality is poor. It's working fine with HW or SW decoder (The codec used by mx player is ARM V7 NEON).
I checked also in perfect player and when using HW+, it seems the player downgrade the video resolution to SD format.
Any clue ?
Chris
Click to expand...
Click to collapse
It should be a bug in the system decoder. In HW+, MX Player passes the frames to the system decoders to directly decode. Probably, the resolution of the decoded frame might be low. We have encountered a similar issue in the past especially when the stream is interlaced. If it's the root cause, then it has to be fixed on the firmware. You will notice similar issues with all major video player apps which makes use of similar technology.

rusukof36 said:
hi,
I have an Minix U9-H box (android 6.0) and when I play full HD streaming files from my ip tv provider using HW+ decoder, the video quality is poor. It's working fine with HW or SW decoder (The codec used by mx player is ARM V7 NEON).
I checked also in perfect player and when using HW+, it seems the player downgrade the video resolution to SD format.
Any clue ?
Chris
Click to expand...
Click to collapse
HW and HW+ uses GPU for H.264 decoding. They performance much better from SW which uses CPU for decoding. HW can perform better than HW+ in most of the Cases, but there is a chance it does not work smoothly on many devices.

Same
Same problem. SW is better than HW and HW+. (Android tv 8.1 - Mibox 3s)

lighthousehn said:
Same problem. SW is better than HW and HW+. (Android tv 8.1 - Mibox 3s)
Click to expand...
Click to collapse
It may happen when the Hardware Accelerated Decoders implemented on the device itself is buggy. Can you please contact us with screenshots of the playback on HW/HW+ and SW along with a bug reported collected from MX right after playing the file? It will help us to confirm the same.

There is no error, just low quality. HW and HW+ is same. SW is good.
The problem only occurs when viewing iptv (multicast - udp), watching the file on the hard disk is ok

lighthousehn said:
There is no error, just low quality. HW and HW+ is same. SW is good.
The problem only occurs when viewing iptv (multicast - udp), watching the file on the hard disk is ok
Click to expand...
Click to collapse
It is one of the known issues on Xiaomi's TV boxes with Oreo and Nougat firmware. Based on our past investigation, it has been found that the hardware accelerated decoder's output resolution of the video frames is much lower than the actual frame size. As both HW and HW+ relies on the decoders shipped with the device, you can notice the issues on both. Request you to contact the device manufacturer so that they can fix the same on their firmware.
If it is possible, kindly share a link with us on PM or at [email protected] so that we can also escalate the same from our end.

I also tried on my phone (Mi Mix 2s - Android 9, MIUI 10) and it gave same results.
multicast links on private network, so you can not access it: https://textuploader.com/dlohs/raw

lighthousehn said:
I also tried on my phone (Mi Mix 2s - Android 9, MIUI 10) and it gave same results.
multicast links on private network, so you can not access it: https://textuploader.com/dlohs/raw
Click to expand...
Click to collapse
Can you please try any non-xiaomi device and check again? Can you also check whether it happens if you copy the stream to a file using FFmpeg? Without a sample clip or a link, we may not be able to seek the assistance of the Xiaomi team.

MXPlayer said:
Can you please try any non-xiaomi device and check again? Can you also check whether it happens if you copy the stream to a file using FFmpeg? Without a sample clip or a link, we may not be able to seek the assistance of the Xiaomi team.
Click to expand...
Click to collapse
I don't have a non-xiaomi device. These are sample files. I saved them with VLC
http://www.mediafire.com/file/71cnwgwzsgw674b/test.ts/file
https://www.mediafire.com/file/wjhcmec367uhwxr/test1.ts/file
Let me guess a bit: The format of the service provider is 1080i, this issue relates to the deinterlacing algorithm. With HW decoder, resolution halved.

maybe recode your video?