Hello,
I am developing a custom VOIP application which use AMR-WB as the codec. I was reading QCOM documents saying it is possible to use the DSP as the vocoder to offload the task from the host CPU.
did any one try to use this option and can share any information, for example amix commands to set the mixer and how to choose codec type and bit rate?
Thanks
Related
Anyone else have an issue? I use Zoomplayer and I have ffdshow. I didn't know anything was left to not be playable!
Check what codec it wants with Gspot(http://www.headbands.com/gspot/)
For a player you can try MediaPlayerClassic(http://sourceforge.net/project/showfiles.php?group_id=82303&package_id=84358&release_id=403110) or get MPC included with a pretty robust codec pack CCCP(http://www.cccp-project.net/download.php?type=cccp)
As a last resort try VLC(http://www.videolan.org/vlc/) it plays pretty much anything, but not always in an optimized way
FFDShow can play TouchPro/Fuze videos, but it may not be configured to recognize the files by default.
GSpot reports video: MP4V, and audio: AMR.
Look under your start menu for the link to ffdshow config (eg: Start > Programs > ffdshow > ... or CCCP > Filters > ... if you use that pack)
Choose FFDShow Audio Decoder Configuration
→ Under the Codecs category, look for AMR and set Decoder to libavcodec.
Then choose FFDShow Video Decoder Configuration
→ Under the Codecs category, look for Other MPEG4 (you will see MP4V noted in the FourCC) and set Decoder to libavcodec
Close ZoomPlayer (or MPC, which I highly recommend), and reload. FFDShow will now properly decode and play the videos.
Man I hate the nightmare over which player to use. I used to use only MPC, but people told me it had inferior video quality and/or couldn't support 5.1.
If you're using the default video format (.mp4), here's a trick that will usually play the video on a PC using Quicktime.
Change the .mp4 file extension to .3gp.
In the advanced menu on the video camera, you can also change the capture format to H.263 and those files seem to play fine on my PC without any changes.
thehyecircus said:
Man I hate the nightmare over which player to use. I used to use only MPC, but people told me it had inferior video quality and/or couldn't support 5.1.
Click to expand...
Click to collapse
Technically MPC isn't a factor when it comes to video quality or support for additional features. Video/audio quality depends on the filters/decoders being used (such as ffdshow, coreavc, powerdvd, etc). Support for extra features comes from splitters (such as Haali Media Splitter, which will tell MPC how to read/playback different kinds of data in a file) and other kinds of filters (such as directvobsub for rendering subtitles).
MPC is pretty much just a GUI that lets you control all those splitters/filters. Without any splitters/filters, MPC is pretty useless, and the default filters would use (that are included in Windows) are indeed pretty low-quality. But ffdshow is one of the best quality decoders out there.
Just for reference, ZoomPlayer is also a good player which uses the same splitters/filters to play media files--it's just a matter of GUI preference. The CCCP package is popular because it includes both MPC and ZoomPlayer as well as the best (non-commercial) splitters and filters like Haali and ffdshow.
If you're interested in getting more information, this is a good start:
http://www.cccp-project.net/wiki/index.php?title=Media_Players
Hopefully this isn't too far off-topic
Is H.263 a poor video quality? I can open it with Media Player and I installed the CCCP, but it takes a while to open my original video file for some reason. And I'd rather never use Quicktime, in fact The CCCP site had me uninstall it. But anyway - does H.263 matter compared to MPEG4? What can I do to have my next video file not be such a pain?
"Choose FFDShow Audio Decoder Configuration
→ Under the Codecs category, look for AMR and set Decoder to libavcodec.
Then choose FFDShow Video Decoder Configuration
→ Under the Codecs category, look for Other MPEG4 (you will see MP4V noted in the FourCC) and set Decoder to libavcodec"
I am going to do that now. I would have done it before, but I did not have those files.
http://en.wikipedia.org/wiki/H.263
There's a lot of rude and ignorant posters on this site, aren't there? I went to the Wiki page first thing - and guess what, there's no information. So *gasp* I asked here. Directing me backwards won't help.
It's pretty complicated so I'll just try to keep it simple:
MP4V is just an identifier for MPEG-4 video. There's a lot of technical stuff behind MPEG-4 codecs concerning quality, but I would say it's safe to assume the Fuze/TouchPro uses just the simple profiles (optimized for handhelds). H.263 is quite simply just an older codec but is similarly intended for handhelds. MPEG-4 technically can offer much better quality, but the Fuze/TouchPro does not let you change the codec's internal settings (since it's built-in to the camera app and/or camera chip).
So whether one codec is better than the other isn't clear; you'll just have to test both modes and see which one you prefer (but at 320x240, I doubt the difference will be very noticable). If the quality is almost the same, the other significant factor is that one codec may produce smaller files.
Hope that helps.
I am developing my application, where voice should be recorded for later playback. According to official Android DevGuide I use AMR-NB encodec (only one available), but recorded sound quality is nightmare...
So my question - is this possible to encode sound using other (better) codecs, eg. FLAC or Vorbis?
Moreover, I am not native code developer - only android, so please explain me... Is this a problem to port LAME or full Vorbis to Android? I suppose yes, because nobody did not do it.
I would think the problem encoding to FLAC would be two-fold, one processing (slow little old things these phones are), and two storage.
It may be better (if voice is your target) to look into Speex, which is a variant of Vorbis/Flac designed for voice. Perhaps the person who ported FLAC to Android could help pursue this?
Check here.
Thanks for reply...
And what about Lame - also OS codec for mp3?
So , am I right, that speex encoding is supported in Android? May I ask for advice how to use it?
I looked for speex... I think it is not supported in Android.
Speex encoding would not be natively supported by Android, neither is FLAC or MP3. The reason I suggested Speex is because it is open-source and royalty free, it also has a smaller footprint and might be less cpu intensive. Either option will require libraries to be ported in order to provide the encoding/decoding function. Speex would also be easier than MP3 because the native Vorbis libraries might be easily adopted to allow Speex playback.
Hi,
I searched a lot now - but I could not find a correct answer.
Does CM13 support the MP3 Codec for A2DP? I read that up until I think CM11 you could enable the MP3 codec in a config file in /etc/bluetooth/.
But since the BT Stack got changed (I think in KitKat?) this config file does not exist anymore and I could not find a way to configure anything.
I even looked at the code and as far as I could understand, there is a default codec, which is always used (probably SBC).
I increased the verbosity for bluetooth and looked at the logs and they let me think that only the SBC Codec is used:
Code:
01-05 16:50:01.253 3308 3364 W bt_btif : bta_av_getcap_results max bitpool length received for SBC is out of range.Clamping the codec bitpool configuration from 250 to 53
How can I change the codec to mp3 (or aac) and what is the best method to really know which codec is used on CM12/CM13?
Thanks for your answers in advance.
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.
Please add audio normalisation or dynamic range compression feature in mx player.
I think it is an essential feature
[email protected] said:
Please add audio normalisation or dynamic range compression feature in mx player.
I think it is an essential feature
Click to expand...
Click to collapse
Thanks for your valuable feedback. MX Player currently uses android audiofx engine which doesn't support such advanced audio effects. However, we will explore the possibilities of supporting more audio filters in the future and will do our best to make that possible if found viable.