Hi Adam!

Yes, MP3 Files (audio files in general!) are indexed for each frame. In 
MP3 terms, this means that you have an index point (consisting of a 
timestamp and byte offset) every couple dozen of samples. So, yes for 
most online things this can be considered "excessive".

If you want a quick fix for this and don't care about seeking precision, 
you can hack MP3Reader so that it only indexes ever x amount of frames. 
This is basically a 3 line hack which could help you patch it until we 
have something better. I see there's some other people addressing the 
same issues i've been working on, so maybe we'll collaborate to get 
something really smooth. You can mess around in FLVReader.java to 
achieve that i believe.

Adam wrote:
> On Wed, Aug 08, 2007 at 10:52:12AM -0700, Niels Joubert wrote:
>   
>> at this point in time, your 
>> best bet is to connect, and wait until the index file is built (it keeps 
>> building even if the client gets disconnected) and connect again if the 
>> index file is done building. Look at the changing filesize on disk of 
>> the index to see when it's done.
>>     
>
> Hummm. Looks like that's not going to do the trick. It's still
> taking an age to open the stream even when the index file
> (that the .meta, right?) is fully built. And furthermore runs
> out of memory as it does so:
>   
>>> "pool-3-thread-3:(org.red5.server.messaging.InMemoryPullPullPipe.pullMessage)
>>>  exception when pulling message from provider:
>>> java.lang.OutOfMemoryError: Java heap space
>>>       
>
> I see that in video files the timestamp between each entry
> in the index is around 1800 'timestamps'  long but for the
> audio-only file it's closer to 50. Which means the 
> audio-only index file is practically as long as the
> audio file itself, about sixty times longer than the
> video-incuded streams. Seems like massive overkill.
>
> Is there some way to reduce the number of keyframes in
> an audio-only index? The keyFrameInterval property only
> exists for a camera object, not a microphone object, so
> that won't work. And I guess ideally it's a post-recording
> operation anyway. Perhaps there's some patch I can make
> to Red5's indexing procedures to change that?
>
> Thanks,
>
>       Adam...........
>
>
> _______________________________________________
> Red5 mailing list
> [email protected]
> http://osflash.org/mailman/listinfo/red5_osflash.org
>   


_______________________________________________
Red5 mailing list
[email protected]
http://osflash.org/mailman/listinfo/red5_osflash.org

Reply via email to