Shoutcast Stream Played on Android Phones : Low Quality - android-mediaplayer

I have a mediaplayer service inside my app . It can play Shoutcast Streams. I am selling my app to different customers who have different quality and formats of broadcast.
My own radio can be played without a problem which has the following properties:
Server Status: Stream is currently up but requires registration in the SHOUTcast Directory.
Listeners are allowed and the stream will act like it is private until resolved.
Stream Status: Stream is up at 96 kbps with 4 of 500 listeners
Listener Peak: 26
Average Listen Time: 27 minutes 2 seconds
Stream Name: **** Fm
Content Type: audio/mpeg
Stream Genre(s): Music
However, today I experienced a very interesting issue . One of my customers said the quality of the sound coming from the main speaker is too bad. I checked it on my phone and it really was bad. Interestingly , when you plug in a headset, the quality turns out to be how it should normally be. One more interesting thing is that the stream is played without a problem on tablets' speakers.
The customer's Shoutcast Server has the following properties:
Server Status: Stream is currently up and private
Stream Status: Stream is up at 96 kbps with 0 of 300 listeners
Stream Name:
Content Type: audio/mpeg
Stream Genre(s): Misc
What could be the source of the problem ? Is there a way to solve it?

Related

WebRtc stream without loss of quality

My web application records video streams on the server side using webRtc and kurento media server. Its just writing the raw stream received from the client to disk. But I was faced with the fact that the quality of the video falls dramatically. All because of codecs and compression. Is it possible to send video without compression at all? The number of FPS is not important to me. 5 FPS for my purpose is pretty enough. The main criterion is 100% quality, or close to it. How to achieve this? Is there any codec that compresses without loss of video quality?
Server side of my app is written in Spring java

Trouble with RTMP ingest chunk stream

I am trying to build my own client RTMP library for an app that I am working on. So far everything has gone pretty successfully in that I am able to connect to the RTMP server negotiate the handshake and then send all the necessary packets (FCPublish Publish ETC) then from the server i get the onStatus message of NetStream.Publish.Start which means that I have successfully got the server to allow me to start publishing my live video broadcast. Wireshark also confirms that the information (/Data packetizing) is correct as it shows up correctly there also.
Now for where I am having some trouble is RTMP Chunking, going off the Adobe RTMP Specification on page 17 & 18 shows an example of how a message is chunked. From this example I can see that it is broken down based on the chunk size (128 bytes). For me the chunk size gets negotiated in the initial connect and exchange which is always 4096 bytes. So for when I am exchanging video data that is larger than 4096 bytes I need to chunk the message down sending the RTMP packetHeader combined with the first 4096 bytes of data then sending a small RTMP header which is 0xc4 (0xc0 | packetHeaderType (0x04)) combined with 4096 bytes of video data until the full packet specified by the header has been sent. Then a new frame comes in and the same process is repeated.
By checking other RTMP client example written in different languages this seems to be what they are all doing. Unfortunately the ingest server that I am trying to stream to is not picking up the broadcast video data, they dont close the connection on my they just never show video or any sign that the video is right. Wireshark shows that after the video atom packet is sent most packets sent are Unknown (0x0) for a little bit and then they will switch into Video Data and will sort of flip flop between showing Unknown (0x0) and Video Data. However if I restrict my payload max size to 20000 bytes Wireshark shows everything as Video Data. Obviously the ingest server will not show video in this situation as i am removing chunks of data for it to be only 20k bytes.
Trying to figure out what is going wrong I started another xcode project that allows me to spoof a RTMP server on my Lan so that I can see what the data looks like from libRTMP IOS as it comes into the server. Also with libRTMP I can make it log the packets it sends and they seem to inject the byte 0xc4 even 128 bytes even tho I have sent the Change Chunk size message as the server. When I try to replicate this in my RTMP client Library by just using a 128 chunk size even tho it has been set to 4096 bytes the server will close my connection on me. However if change libRTMP to try to go to the live RTMP server it still prints out within LibRTMP that it is sending packets in a chunk size of 128. And the server seems to be accepting it as video is showing up. When I do look at the data coming in on my RTMP server I can see that it is all their.
Anyone have any idea what could be going on?
While I haven't worked specifically with RTMP, I have worked with RTSP/RTP/RTCP pretty extensively, so, based on that experience and the bruises I picked up along the way, here are some random, possibly-applicable tips that might help/things to look for that might be causing an issue:
Does your video encoding match what you're telling the server? In other words, if your video is encoded as H.264, is that what you're specifying to the server?
Does the data match the container format that the server is expecting? For example, if the server expects to receive an MPEG-4 movie (.m4v) file but you're sending only an encoded MPEG-4 (.mp4) stream, you'll need to encapsulate the MPEG-4 video stream into an MPEG-4 movie container. Conversely, if the server is expecting only a single MPEG-4 video stream but you're sending an encapsulated MPEG-4 Movie, you'll need to de-mux the MPEG-4 stream out of its container and send only that content.
Have you taken into account the MTU of your transmission medium? Regardless of chunk size, getting an MTU mismatch between the client and server can be hard to debug (and is possibly why you're getting some packets listed as "Unknown" type and others as "Video Data" type). Much of this will be taken care of with most OS' built-in Segmentation-and-Reassembly (SAR) infrastructure so long as the MTU is consistent, but in cases where you have to do your own SAR logic it's very easy to get this wrong.
Have you tried capturing traffic in Wireshark with libRTMP iOS and your own client and comparing the packets side by side? Sometimes a "reference" packet trace can be invaluable in finding that one little bit (or many) that didn't originally seem important.
Good luck!

rtmp vod, how to play multiple video files(mp4 or flv) continuously using simplertmp client

as the title shows, is there any methods I can use to play multiple videos continuously using simple rtmp client(my rtmp server is wowza)? Here is the way I think:
when the first video is about to be finished,open a new thread to send a new createStream command and a new play command and get the video rtmp packet and put them into a buffer list, when the first video is finished, then play the video rtmp in the buffer list..
Can this way be available or are there any other recommended methods to achieve it? Any suggestion will be appreciated, thanks!
While the functionality is not built-in, Wowza does have a module called StreamPublisher to allow you to implement a server-side type of playlist. The source code for the module is available on GitHub. A scheduled playlist of multiple VOD files is streamed as a live stream, similar to a TV broadcast.

Stopping own audio in stream

I am trying to implement video chat in my application with webrtc.
I am attaching the stream via this:
getUserMedia(
{
// Permissions to request
video: true,
audio: true
},
function (stream) {
I am passing that stream to remote client via webrtc.
I am able to see both the videos on my screen (mine as well as of client).
The issue I am getting is that I am getting my own voice too in the stream which I don't want. I want the audio of other party only.
Can you let me know what can be the issue?
Did you add the "muted" attribute to your local video tag as follow :
<video muted="true" ... >
Try setting echoCancellation flag to true on your constraints.
4.3.5 MediaTrackSupportedConstraints
W3.org
Media Capture and Streams
When one or more audio streams is being played in the processes of
various microphones, it is often desirable to attempt to remove the
sound being played from the input signals recorded by the microphones.
This is referred to as echo cancellation. There are cases where it is
not needed and it is desirable to turn it off so that no audio
artifacts are introduced. This allows applications to control this
behavior.

NAudio decode stream of bytes

Hi
I am using the NAudio library at http://naudio.codeplex.com/
I have this hardware made by some manufacturer which claims to send
audio with the following characteristics.
aLaw 8khz, AUD:11,0,3336,0
Not sure what it all means at this stage.
I received bunch of bytes from this device when a user speaks into the
equipment.
Hence I am constantly recieving a stream of bytes at particular times
At this stage I have been unable to decode the audio so I can hear
what is spoken into the device with my headphones.
I have tried writing the audio to a file doing code like
FWaveFileWriter = new WaveFileWriter("C:\Test4.wav",
WaveFormat.CreateALawFormat(8000, 1));
And have been unable to playback the sound using the sample demo apps.
I have tried similar code from
http://naudio.codeplex.com/Thread/View.aspx?ThreadId=231245 and
http://naudio.codeplex.com/Thread/View.aspx?ThreadId=83270
and still have not been able to achieve much.
Any information is appreciated.
Thanks
Allen
If you are definitely receiving raw a-law audio (mono 8kHz) then your code to create a WAV file should work correctly and result in a file that can play in Windows Media Player.
I suspect that maybe your incoming byte stream is wrapped in some other kind of protocol. I'm afraid I don't know what "AUD:11,0,3336,0" means, but that might be a place to start investigating. Do you hear anything intelligible at all when you play back the file?