I just thought i would share this, as it's been bugging me on Miui that the Google Assistant didn't always speak results like what is the weather forecast.
https://support.google.com/websearch/forum/AAAAgtjJeM4MwaLxKImwEc/?hl=en
change the value of mm.enable.qcom_parser in build.prop to 245389 (3183219 as mentioned in the article is for another device that supports different codecs) fixes the issue as mentioned in the google bug report for the Xiaomi a1.
I've attached a magisk module that is a modified Camera2 api enabler script. It enables Camera 2 api, adjusts noise cancelation to fluencepro, adds EIS entry for Google camera and turns off noise cancellation for voice recordings
Edit: modified Magisk package to the value @Stoffl_ calculated, 245389, for the mido. Thanks
Thanks, will try this as the TalkBack issue has bugged me for a while.
A better explaination of what is happening - based on that information we can probably work out the right number for the Redmi Note 4x to disable the ogg hardware codec until its updated - The above number may be correct, but we probably just need to get the original number, and just change the bit for Ogg to off for the moment.
http://en.miui.com/forum.php?mod=viewthread&tid=1465017&page=2#pid21050310
21#
01:04, Jan-10-2018 | From PC |
This post was edited by Theliel at 18:09, Jan-09-2018
Is not exactly in that way.
In first instance, the issue is only present in qualcom SoC (not Mediatek) Nougat, Oreo work fine.
In second place, qcom_parser number is a mask, representing all supported codecs directly in hardware (not software). Each SoC support different codecs.
For Mi4c:
Codecs: DivX DivXHD AVI AC3 ASF AAC QCP DTS 3G2 MP2TS
mm.enable.qcom_parser=3379827
3379827 = 1100111001001001110011
Each bit represent a codec, if you set a bit to 1, you enable hw support to that codec. A more simpe example, imagine only 3 codecs and in the exact order: mp3 ogg acc
111 enable all codecs = 7
001 enable only aac = 1
101 enable mp3 and aac, disable ogg = 5
You can't use the same value to each device, because each device support a different array of codecs. The real issue is only with qcom hw lib/codec ogg (container, real codec is opus), that is the audio returned by google. Devices without hw support of ogg or with ogg disabled, work fine in most Nougat.
In my investigations, ogg is placed in 15th position in most of all qcom devices.
So, for default Mi4c:
3379827 = 1100111001001001110011 | Work fine, hw is not used anyway, not supported
Default Mi6 Nougat:
1048575 = 11111111111111111111 | Dont Work
1032191 = 11111011111111111111 | Work perfecly
If you force all devices to 3183219 (for example), yes, you are disabling ogg bit, but you are disabling a lot of other codecs too, is not recommended, not a solution.
The real solution is a newer driver/codec to solve hw codec. Temporal fix is ONLY flip ogg bit to disable hw support and use only software, without touching the others bits. Each device, have a different hw arraw codec, so you shouldn't use the same value to all, is a big mistake
Click to expand...
Click to collapse
So..if I understand this correctly...
My Redmi Note 4X Global on Global stable Rom 9.0.5.0 build.prop has currently the following values
Code:
#codecs:(PARSER_)AAC AC3 AMR_NB AMR_WB ASF AVI DTS FLV 3GP 3G2 MKV MP2PS MP2TS MP3 OGG QCP WAV FLAC AIFF APE
mm.enable.qcom_parser=261773
261773 decimal = 111111111010001101 in binary
According to the post above and the comments in my build prop bit 15 should be Ogg support.
111111111010001101 means Ogg is enabled
So the correct value to disable Ogg HW support would be 111111111010000101 = 261765
Correct ?
Hmmm .... this is very interesting - but also probably error prone. With SlimROM v1.17, I have this "mm.enable.qcom_parser=1048575" (i.e., 1111 1111 1111 1111 1111). It seems that everything is turned on! But it is not clear what one will be disabling if any alteration is made.
Turns out the bits should be read from right to left, whoops.
http://en.miui.com/forum.php?mod=redirect&goto=findpost&ptid=1465017&pid=21367895
And the starting zero bits aren't counted, which would explain why number of codecs and bits didn't match up in my example.
I'm now using 229005 and so far google assistant talkback is working.
*edit*
I had the dumb and counted wrong
111011111010001101 = 245389 is working, weather and time talkback functional!!
Only OGG hardware encoding should be disabled, everything else is should be on default rom setting.
Related
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
Hi there,
Every time I play a Music Video, The decoder always defaults to HW even though I checked the setting for HW+ to be used for local files in the Decoder settings. I always have to manually change the decoder to HW+ from HW with each mp4 that's played . Am I missing something? That's what the setting is for right?
Asus Transformer TF101
Thanks in Advance!
Could just be a temporary caching thing. Try this:
1. As you've already done, Settings -> Decoder -> HW+ local
2. finish playback of all files
3. Menu -> Exit
4. Clear the app cache
See what happens after that. I had similar issues before, and it was a caching thing.
Aeroplane said:
Hi there,
Every time I play a Music Video, The decoder always defaults to HW even though I checked the setting for HW+ to be used for local files in the Decoder settings. I always have to manually change the decoder to HW+ from HW with each mp4 that's played . Am I missing something? That's what the setting is for right?
Asus Transformer TF101
Thanks in Advance!
Click to expand...
Click to collapse
As @CDB-Man said
1. Hope you have enabled H/W+ Decoder & H/W+ Decoder (Local)
2. If you have paused the video earlier with other decoders, the last decoder used for that particular video is saved in activity status. So, when it asks to resume you have to start over rather than resume. Your video will be played in HW+.
3.Else simply clearing the activity records by clicking clear history on Settings 》 General will reset status (Not # for all videos & your video will be played in HW+.
Sent from my Galaxy S5 using Tapatalk
CDB-Man said:
Could just be a temporary caching thing. Try this:
1. As you've already done, Settings -> Decoder -> HW+ local
2. finish playback of all files
3. Menu -> Exit
4. Clear the app cache
See what happens after that. I had similar issues before, and it was a caching thing.
Click to expand...
Click to collapse
I did exactly that, playing from within MX player but it didn't work. I cleared the cache in the Main Settings of my device.
And it doesn't work either even playing it from my folder using X-plore or Total Commander. I also cleared the cache including the file manager in the Main Settings.
Could you post a mediainfo dump on the file? I'm thinking it may be an issue with it picking up on encode data. This is weird as per what you say, the video does play in HW+ mode after you manually change it.
CDB-Man said:
Could just be a temporary caching thing. Try this:
1. As you've already done, Settings -> Decoder -> HW+ local
2. finish playback of all files
3. Menu -> Exit
4. Clear the app cache
See what happens after that. I had similar issues before, and it was a caching thing.
Click to expand...
Click to collapse
ktsamy said:
As @CDB-Man said
1. Hope you have enabled H/W+ Decoder & H/W+ Decoder (Local)
2. If you have paused the video earlier with other decoders, the last decoder used for that particular video is saved in activity status. So, when it asks to resume you have to start over rather than resume. Your video will be played in HW+.
3.Else simply clearing the activity records by clicking clear history on Settings 》 General will reset status (Not # for all videos & your video will be played in HW+.
Sent from my Galaxy S5 using Tapatalk
Click to expand...
Click to collapse
Sorry no joy. Then I also cleared all the caches in Settings->General then Quit , cleared cache again from Main Settings then entered MXplayer and still no joy. Sorry.
Hmmmm....
CDB-Man said:
Could you post a mediainfo dump on the file? I'm thinking it may be an issue with it picking up on encode data. This is weird as per what you say, the video does play in HW+ mode after you manually change it.
Click to expand...
Click to collapse
I'm sorry for the delay. It took time looking for an appropriate video to extract the MI from, as a consequence, I had to download another video for this, this video is no different from my videos in that the problem also applied to it when I played it :
General
Complete name: /mnt/sdcard/Music/FREE Outro Template! wmv File_low.flv
Format: Flash Video
File size: 633 KiB
Duration: 20s 187ms
Overall bit rate: 257 Kbps
VideoCount: 1
AudioCount: 1
Duration: 20187
OverallBitRate: 255391
httphostheader: r1---sn-o097zuez.googlevideo.com
Video_Format_List: Sorenson Spark
Video_Format_WithHint_List: Sorenson Spark
Video_Codec_List: Sorenson H263
Audio_Format_List: MPEG Audio
Audio_Format_WithHint_List: MPEG Audio (MP3)
Audio_Codec_List: MPEG-2 Audio layer 3
Video
Format: Sorenson Spark
Codec ID: 2
Bit rate: 174 Kbps
Width: 426 pixels
Height: 240 pixels
Display aspect ratio: 16:9
Bit depth: 8 bits
Width: 426
Height: 240
BitRate: 183451
FrameRate: 29.970
FrameRate_Mode: CFR
Duration: 20220
Audio
Format: MPEG Audio
Format version: Version 2
Format profile: Layer 3
Mode: Joint stereo
Mode extension: MS Stereo
Codec ID: 2
Codec ID/Hint: MP3
Duration: 20s 186ms
Bit rate: 64.0 Kbps
Channel(s): 2 channels
Sampling rate: 22.05 KHz
Compression mode: Lossy
Stream size: 158 KiB (25%)
BitRate: 64389 / 64000 / 64000 / 64000 / 64000
BitRate_Mode/String: Constant / Constant
Duration: 20297
END
2. On the manual shifting to HW+ while the video is in play, I was happy enough that the video does not anymore revert to the start position like before Thanks for that Dev !
Thank you for taking the time to look into a minor quibble. Please take your time don't let me disturb you both in this thread.
> Video
> Format: Sorenson Spark
My only guess is that this might be the issue. I could be wrong, but I think i remember the developer mentioning somewhere that it tries to let the hardware select a decoder first. Anyways, @bleu8888 could you take a look?
Aeroplane said:
I'm sorry for the delay. It took time looking for an appropriate video to extract the MI from, as a consequence, I had to download another video for this, this video is no different from my videos in that the problem also applied to it when I played it :
General
Complete name: /mnt/sdcard/Music/FREE Outro Template! wmv File_low.flv
Format: Flash Video
File size: 633 KiB
Duration: 20s 187ms
Overall bit rate: 257 Kbps
VideoCount: 1
AudioCount: 1
Duration: 20187
OverallBitRate: 255391
httphostheader: r1---sn-o097zuez.googlevideo.com
Video_Format_List: Sorenson Spark
Video_Format_WithHint_List: Sorenson Spark
Video_Codec_List: Sorenson H263
Audio_Format_List: MPEG Audio
Audio_Format_WithHint_List: MPEG Audio (MP3)
Audio_Codec_List: MPEG-2 Audio layer 3
Video
Format: Sorenson Spark
Codec ID: 2
Bit rate: 174 Kbps
Width: 426 pixels
Height: 240 pixels
Display aspect ratio: 16:9
Bit depth: 8 bits
Width: 426
Height: 240
BitRate: 183451
FrameRate: 29.970
FrameRate_Mode: CFR
Duration: 20220
Audio
Format: MPEG Audio
Format version: Version 2
Format profile: Layer 3
Mode: Joint stereo
Mode extension: MS Stereo
Codec ID: 2
Codec ID/Hint: MP3
Duration: 20s 186ms
Bit rate: 64.0 Kbps
Channel(s): 2 channels
Sampling rate: 22.05 KHz
Compression mode: Lossy
Stream size: 158 KiB (25%)
BitRate: 64389 / 64000 / 64000 / 64000 / 64000
BitRate_Mode/String: Constant / Constant
Duration: 20297
END
Click to expand...
Click to collapse
CDB-Man said:
> Video
> Format: Sorenson Spark
My only guess is that this might be the issue. I could be wrong, but I think i remember the developer mentioning somewhere that it tries to let the hardware select a decoder first. Anyways, @bleu8888 could you take a look?
Click to expand...
Click to collapse
It's a very old codec.
It's a implementation of h263 to use it in a flash container. It was used in flash player v6 & v7. But, I am not sure why it's automatically switches to HW.
Can you upload or share a sample video link?
So that I can test.
Sent from my Galaxy S5 using Tapatalk
Hi there,
Here it is.
Thanks again for taking the time to look into this.
Aeroplane said:
Hi there,
Here it is.
Thanks again for taking the time to look into this.
Click to expand...
Click to collapse
The media info you have posted earlier was having Sorenson Spark h263 video in mp4 container.
The attcahed video is AVC/h264 in mp4 container.
I have tested the file you have attached. But, After enabling HW+ decoder It directly plays in HW+ in my test.
There is no problem with MX Player. Your are doing something wrong while following the instructions.
Are you trying to play the file from network share/ SMB share?
If it so , Then you have to enable HW+ Decoder (Network) too.
If you are not then Open Settings >> General >> Clear History
Enable HW+ Decoder (Local) from Settings >> Decoder
Then Try again.
LIST -> SCAN -> File Extensions
ktsamy said:
The media info you have posted earlier was having Sorenson Spark h263 video in mp4 container.
The attcahed video is AVC/h264 in mp4 container.
I have tested the file you have attached. But, After enabling HW+ decoder It directly plays in HW+ in my test.
There is no problem with MX Player. Your are doing something wrong while following the instructions.
Are you trying to play the file from network share/ SMB share?
If it so , Then you have to enable HW+ Decoder (Network) too.
If you are not then Open Settings >> General >> Clear History
Enable HW+ Decoder (Local) from Settings >> Decoder
Then Try again.
Click to expand...
Click to collapse
I went through the whole SETTINGS, one configurable setting after another and this time realized that there was another way, a more specific way, to configure the codec to be used, for a particular type of file extension. Which means we can configure the type of codec to be used (whether HW, HW+, or SW) for any specific file extension (mp4, wmv, flv, or any and every file extension) in SETTINGS -> LIST -> SCAN -> FILE EXTENSION. I believe this "more specific" setting overrides SETTINGS -> DECODER -> HARDWARE DECODER and SOFTWARE DECODER which are more general configurable settings.
And this explains why no matter how I change the DECODER settings to use HW+ codec for my local files, MXplayer still plays the music video using HW. Because the first time I ever used MXplayer I already configured MXplayer to use HW codec for all mp4 files in SETTINGS -> LIST -> SCAN -> FILE EXTENSION. Its been almost 3 years using MXplayer that it has slipped my mind. This setting by the way, though not really located deep in the underbelly of SETTINGS, is quite a bit off from the DECODER Settings.
Kindly accept my apologies for all this. My tail is down between my legs in shame And I also felt I needed to post this for the thread to go full-circle, and who knows?, a satisfied but wondering MXplayer user might come onto this thread and say "Eureka !". It is still a valid and useful thread I believe.
Thank you both !
Benjamin
You are definitely right that most people would not even think to go there.
I just wondered about some of my videos not being played by the HW decoder. I figured out the issue must lay upon the codec, so I thought I do some research, since some HD Videos are going well with the HW decoder.
I would be really glad if someone can actually give me some advices how to convert the videos and which codec I should use for the best outcome.
The SW decoder is such a batterie consuming beast, I wish all videos could make use of the HW decoder.
Which converter are you using?
Try using basic convertion. You can reduce bightness so battery can extend a little bit.
About supported codecs:
HW decoder should support all codecs that are supported by your device. The best (and most common) codec is AVC (H.264), it's supported by your device for sure. It's the only codec worth caring about (for now).
However this doesn't end at codecs, because codecs have profiles and levels. Basically they are set of restrictions (like "to be able to play this video you need to be able to do this"). They are needed to ensure that if decoder supports particular profile/level, then it would be able to play any video with that (or lower) profile/level.
I believe that your device should support at least High Profile L4.1, which means that it should be able to play most H.264 videos.
However there's one special case - videos that use High 10 Profile (hi10p, 10 bit depth). It's commonly used on anime sources, becauses it preserves gradients well. There're no hardware decoders that support it.
Unfortunately manufactures usually are very vague about codecs/profiles/level support ("1080p HD video" is all what qualcomm says, lol), so you should test by yourself to find it out.
The first thing you need to do if you want to know why you can or can't play some video using h/w decoder is to check it's codec, profile and level (using MediaInfo or any other similar tool, usually media players have it built-in).
About conversion:
Try Handbrake, by default it should produce files playable by your device (no need to touch presets). You can play with "x264 Preset" to control speed/size and Quality to control quality/size.
Converting with Handbrake into x264 mp4 would be the most universally acceptable format for all devices, and work with HW decoding.
That should be no problem with your stock Nexus 4.
Hi Devs,
I have custom codecs installed in my MX player and I have no issues playing local files with aac audio. But when I play a hls stream with aac audio, the sound is disabled by default. In order to enable the sound I should manually open sound menu and tick the checkbox of "use software decoder" and select the audio steam. As this doesn't happen for local files I believe it should be a bug. Let me know if you need any more info.
Regards
Edit : I checked again and noticed my local file audio codec is AC-3 and network steam codec is AAC. So they are not having the same audio codec. May be the problem is AAC audio codec. My device is nexus 10 running stock android lollipop.
I'm having this same problem (with version 1.7.33, could not make 1.7.34 work) both with local (SD) and network (NAS) versions of the same files. All audio will work however if I turn the S/W audio decoder switch on. See my thread about the problem here: http://forum.xda-developers.com/apps/mx-player/aac-h-decoder-version-1-7-33-t2955189 .
My problem with AAC (streamed from a NAS) has been solved with published version 1.7.34 without the need of any special setting, thanks to devs for fixing it!
The problem has been resolved for me as well Thanks devs.
I have problem with more encoded Opus track in MKV container with MX Player Pro (tested with Android 5 and 6)
one example with problem: OPUS 224Kbps VBR
( another without problem to compare: Opus 192Kbps VBR )
I not know english word to explain audio effect.. it's a vibrate each 2sec for less 0.5sec.
I not reproduce the problem if enable HW OPUS audio codec (but HW not support 5.1).
No problem on MPC-HC or VLC with PC.
I reproduce the same probleme with KODI on Android 5
I add this new MKV test file with x264 video (not all device can read x265 for test)
MKV x264-OPUS 224kbps VBR
-VLC can read without problem on Windows and Android (but not found other player can read without problem this x264 mkv)
baudav said:
I have problem with more encoded Opus track in MKV container with MX Player Pro (tested with Android 5 and 6)
one example with problem: OPUS 224Kbps VBR
( another without problem to compare: Opus 192Kbps VBR )
I not know english word to explain audio effect.. it's a vibrate each 2sec for less 0.5sec.
I not reproduce the problem if enable HW OPUS audio codec (but HW not support 5.1).
No problem on MPC-HC or VLC with PC.
I reproduce the same probleme with KODI on Android 5
Click to expand...
Click to collapse
It looks like a FFmpeg side issue & the latest version also has issues. That's why the issue is there with KODI.
Probably VLC might have implemented some workarounds.
The issue is forwarded to our developer team & they are looking into the issue.
baudav said:
I have problem with more encoded Opus track in MKV container with MX Player Pro (tested with Android 5 and 6)
one example with problem: OPUS 224Kbps VBR
( another without problem to compare: Opus 192Kbps VBR )
I not know english word to explain audio effect.. it's a vibrate each 2sec for less 0.5sec.
I not reproduce the problem if enable HW OPUS audio codec (but HW not support 5.1).
No problem on MPC-HC or VLC with PC.
I reproduce the same probleme with KODI on Android 5
Click to expand...
Click to collapse
It looks like a bug on mkvmerge or ffmpeg.
We will add a workaround on the next version which can be enabled optionally.
Hi,
for the update
- https://github.com/mbunkus/mkvtoolnix/issues/2099
- https://trac.ffmpeg.org/ticket/4178
after extract opus track with ffmpeg, and add it with ffmpeg, it's GOOD.
I not understand all word in explanation, but initial opus track is not very good (even if reading has no problem)
If mxplayer can read without problem it's good; but if I correct my file it's better.
baudav said:
Hi,
for the update
- https://github.com/mbunkus/mkvtoolnix/issues/2099
- https://trac.ffmpeg.org/ticket/4178
after extract opus track with ffmpeg, and add it with ffmpeg, it's GOOD.
I not understand all word in explanation, but initial opus track is not very good (even if reading has no problem)
If mxplayer can read without problem it's good; but if I correct my file it's better.
Click to expand...
Click to collapse
We will add a workaround for this. But, it is not supposed to be used for all audio tracks. So, it will be made as optional.