Hi Ross, finally we found that the problem was a global variable that both video and audio framed source access to retrieve the pointer to the codified memory. We solved this. The original problem of the mp3 streaming was solved returning my FramedSource subclass.
Thanks for your help it was very useful for us! 2016-04-20 17:51 GMT-03:00 Ross Finlayson <finlay...@live555.com>: > > I copy below two links of the test which I have done. Maybe you have a > better idea of what kind of mistake we are doing. > > > > > https://drive.google.com/file/d/0B0rFtoVWa4g0VWFNb3luYUhoMmM/view?usp=sharing > > > > > https://drive.google.com/file/d/0B0rFtoVWa4g0MzZDLXFjUEZFdW8/view?usp=sharing > > OK, but do you have the names of these files backwards? It’s the > “test1_withVideo.mp3” file that plays perfectly, but the > “test2_withoutVideo.mp3” file that plays badly (it’s missing MP3 frames). > I presume (based on your earlier emails) that the file names should be the > other way round?? > > In any case, I’m pretty sure that the problem arises from the way that you > are *capturing* your MP3 audio, not in the way that you are *streaming* > it. You can easily test this by modifying your “FramedSource” subclass - > for capturing MP3 audio - to write the encoded MP3 audio data into a > separate file at the same time that you are copying it to the downstream > LIVE555 object. Then try playing this file. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
