Re: Problem with Layer 2 and 3 files in same obs RTP stream

2001-03-08 Thread Marty Schoch

Ross is against using RTP Payload 14 at all though,
and with good reason.  An mp3 frame is not an ADU
because of the bit reservoir, so losing one packet
means you could lose a few frames.  And that is still
assuming one frame per packet.  So unless you are
interleaving, which also is non-trivial in Payload 14,
relatively minor packet loss will make the stream
sound terrible.

We turn off the bit reservoir when we make mp3's for our
stream, enforce one frame per packet, and hope to do
some sort of staggering/interleaving soon.

But Ross has also come up with a nice solution, see

http://www.live.com/rtp-mp3/rtp-mp3.txt

He also has LGPL code to implement this, anybody
want to hack this into obs?

[EMAIL PROTECTED] wrote:
> 
> Apologies for not responding to this sooner. My freeamp-dev mail was
> going into the wrong folder and I never spotted it.
> 
> On 26 Feb, Dave Chapman wrote:
> > On Monday 26 February 2001 02:46, Marty Schoch wrote:
> >> A more complicated solution would be to modify Obseqium to set
> >> the Market bit in the RTP header when it's about to change format.
> >> Then just have the player reconfigure the decoder when it
> >> detects the Market bit in the stream.
> 
> That's what I wanted to do in the first place, but then Ross Finlayson
> advised me against it. I forget what his reasoning was. The obs side of
> things is not hard -- its the FreeAmp side that is harder to solve.
> 
> > Whenever this bit is set, Freeamp should assume that the audio type (layer,
> > bitrate, whatever) has changed, and reconfigure itself appropriately.  It
> > could also reset it's own time display to zero (if people want that - I do).
> >
> > Do people agree?
> 
> Agreed. I'll see what I can do.
> 
> --ruaok Freezerburn! All else is only icing. -- Soul Coughing
> 
> Robert Kaye   --[EMAIL PROTECTED]   --   http://www.mayhem-chaos.net
> 
> ___
> [EMAIL PROTECTED]
> http://www.freeamp.org/mailman/listinfo/freeamp-dev

-- 
Marty Schoch
<[EMAIL PROTECTED]>
Join the I-Force
Download the MCT Player
http://www.on-the-i.com
___
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev



Re: Problem with Layer 2 and 3 files in same obs RTP stream

2001-03-06 Thread rob

Apologies for not responding to this sooner. My freeamp-dev mail was
going into the wrong folder and I never spotted it.

On 26 Feb, Dave Chapman wrote:
> On Monday 26 February 2001 02:46, Marty Schoch wrote:
>> A more complicated solution would be to modify Obseqium to set
>> the Market bit in the RTP header when it's about to change format.
>> Then just have the player reconfigure the decoder when it
>> detects the Market bit in the stream.

That's what I wanted to do in the first place, but then Ross Finlayson
advised me against it. I forget what his reasoning was. The obs side of
things is not hard -- its the FreeAmp side that is harder to solve.

> Whenever this bit is set, Freeamp should assume that the audio type (layer, 
> bitrate, whatever) has changed, and reconfigure itself appropriately.  It 
> could also reset it's own time display to zero (if people want that - I do).
> 
> Do people agree?

Agreed. I'll see what I can do.


--ruaok Freezerburn! All else is only icing. -- Soul Coughing

Robert Kaye   --[EMAIL PROTECTED]   --   http://www.mayhem-chaos.net

___
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev



Re: Problem with Layer 2 and 3 files in same obs RTP stream

2001-02-26 Thread Dave Chapman

On Monday 26 February 2001 02:46, Marty Schoch wrote:
> I may be wrong on some of the specifics but this is what
> I've found.  I've successfully gotten FreeAmp to switch
> between multiple bitrate mp3s.
>
> The problem really is that the pipeline is setup based on
> the first few frames of data received.  It would be
> possible to signal the change through RTP, but I believe
> all mpeg audio uses the static payload type 14.
>

That's correct.

> So, you could have the code check each packet for it's format,
> but I think I tried that once, and the overhead was way too high.
>
> A more complicated solution would be to modify Obseqium to set
> the Market bit in the RTP header when it's about to change format.
> Then just have the player reconfigure the decoder when it
> detects the Market bit in the stream.
>

This seems an appropriate way to do it.  I quote from RFC2250:

[2.1 RTP header usage]

M bit:  Set to 1 whenever the timestamp is discontinuous
  (such as might happen when a sender switches from one data
  source to another). This allows the receiver and any
  intervening RTP mixers or translators that are synchronizing
  to the flow to ignore the difference between this timestamp
  and any previous timestamp in their clock phase detectors.

Does either Obsequiem or Freeamp currently use this bit?  

Whenever this bit is set, Freeamp should assume that the audio type (layer, 
bitrate, whatever) has changed, and reconfigure itself appropriately.  It 
could also reset it's own time display to zero (if people want that - I do).

Do people agree?

Regards,

Dave Chapman.
___
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev



Re: Problem with Layer 2 and 3 files in same obs RTP stream

2001-02-25 Thread Marty Schoch

I may be wrong on some of the specifics but this is what
I've found.  I've successfully gotten FreeAmp to switch
between multiple bitrate mp3s.

The problem really is that the pipeline is setup based on
the first few frames of data received.  It would be
possible to signal the change through RTP, but I believe
all mpeg audio uses the static payload type 14.

So, you could have the code check each packet for it's format,
but I think I tried that once, and the overhead was way too high.

A more complicated solution would be to modify Obseqium to set
the Market bit in the RTP header when it's about to change format.
Then just have the player reconfigure the decoder when it 
detects the Market bit in the stream.

Anyone else have suggestions.

Dave Chapman wrote:
> 
> Hello,
> 
> I'm not sure if this problem is bug in Freeamp, Obsequiem or a limitation of
> the RTP protocol.  Hopefully someone on this list can help.
> 
> I'm using Obsequeium (v0.3.0 - Debian x86) and Freeamp (2.0.7 - Win98).  My
> Obs database consists of a mixture of MP3 and MP2 (iMpeg 1, Layer II) files.
> The mp2 files (is that the correct name) are direct recordings from Digital
> Satellite radio broadcasts (which broadcast using layer 2 audio - I don't
> perform any re-encoding on the stream).
> 
> Individually, the mp2 and mp3 files stream and play fine using Obsequiem and
> Freeamp.  However, when the two different formats are mixed in the playlist,
> Freeamp doesn't seem to recognise the change in format.  Playing an mp2 file
> after an mp3 file gives silence, and playing mp3 after mp2 gives garbled
> sound.
> 
> In both cases, pressing stop and play in Freeamp fixes the problem and the
> audio is perfect again.
> 
> Can anyone suggest where the problem lies?
> 
> Best wishes,
> 
> Dave.
> ___
> [EMAIL PROTECTED]
> http://www.freeamp.org/mailman/listinfo/freeamp-dev
___
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev



Problem with Layer 2 and 3 files in same obs RTP stream

2001-02-25 Thread Dave Chapman

Hello,

I'm not sure if this problem is bug in Freeamp, Obsequiem or a limitation of 
the RTP protocol.  Hopefully someone on this list can help.

I'm using Obsequeium (v0.3.0 - Debian x86) and Freeamp (2.0.7 - Win98).  My 
Obs database consists of a mixture of MP3 and MP2 (iMpeg 1, Layer II) files.  
The mp2 files (is that the correct name) are direct recordings from Digital 
Satellite radio broadcasts (which broadcast using layer 2 audio - I don't 
perform any re-encoding on the stream).

Individually, the mp2 and mp3 files stream and play fine using Obsequiem and 
Freeamp.  However, when the two different formats are mixed in the playlist, 
Freeamp doesn't seem to recognise the change in format.  Playing an mp2 file 
after an mp3 file gives silence, and playing mp3 after mp2 gives garbled 
sound.

In both cases, pressing stop and play in Freeamp fixes the problem and the 
audio is perfect again.

Can anyone suggest where the problem lies?  

Best wishes,

Dave.
___
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev