headers
Ross Finlayson | 1 Feb 2011 17:05
Favicon

Re: Simple Filter leading to a CODEC

>This is a brand new codec, so I'll need to specify an RTP payload 
>for that.  It's for low bitrate high packet loss networks, and works 
>off of single frame encoding, because a dropped iFrame is not 
>desirable.

OK, let us know when you've submitted an Internet Draft that 
describes your proposed RTP payload format, and then I'll help you 
implement it using the "LIVE555 Streaming Media" libraries.  (This 
implementation would be (at least) a subclass of "MultiFramedRTPSink" 
(for sending RTP), and a subclass of "MultiFramedRTPSource" (for 
receiving RTP).)

(It's going to be interesting to see how you come up with a 
single-frame video encoding that's also low-bitrate, because those 
two usually don't go together.)
--

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Permalink | Reply |
headers
Brian Michalk | 1 Feb 2011 17:25

Re: Simple Filter leading to a CODEC


On 2/1/2011 10:05 AM, Ross Finlayson wrote:
>> This is a brand new codec, so I'll need to specify an RTP payload for 
>> that.  It's for low bitrate high packet loss networks, and works off 
>> of single frame encoding, because a dropped iFrame is not desirable.
>
> OK, let us know when you've submitted an Internet Draft that describes 
> your proposed RTP payload format, and then I'll help you implement it 
> using the "LIVE555 Streaming Media" libraries.  (This implementation 
> would be (at least) a subclass of "MultiFramedRTPSink" (for sending 
> RTP), and a subclass of "MultiFramedRTPSource" (for receiving RTP).)
>
> (It's going to be interesting to see how you come up with a 
> single-frame video encoding that's also low-bitrate, because those two 
> usually don't go together.)

Thanks.  Actually, my problem right now is not with RTP at all, it's 
with how to access the picture frames to implement the codec.  I was 
wanting to know the "best" way to go about tinkering with the video.  My 
thought was to take the MPEG2 sources and modify those, but perhaps 
there is a better way?  That's why I laid out the simple goal of 
modifying the Y plane.  Once I get there, I am confident that the rest 
will be fairly straightforward.
Permalink | Reply |
headers
Ross Finlayson | 1 Feb 2011 17:34
Favicon

Re: Simple Filter leading to a CODEC

>Thanks.  Actually, my problem right now is not with RTP at all, it's 
>with how to access the picture frames to implement the codec.

If you want to do this using our library, then you would write your 
own 'filter' class - i.e., a subclass of "FramedFilter" - for 
encoding each frame.  In particular, your "FramedFilter" subclass 
would implement the virtual function "doGetNextFrame()".

I suggest that you start by taking a look at our implementation of 
the "uLawFromPCMAudioSource" class, because that's the closest thing 
that we have in our library to a 'codec'.
--

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Permalink | Reply |
headers
Ross Finlayson | 1 Feb 2011 17:34
Favicon

Re: Simple Filter leading to a CODEC

>Thanks.  Actually, my problem right now is not with RTP at all, it's 
>with how to access the picture frames to implement the codec.

If you want to do this using our library, then you would write your 
own 'filter' class - i.e., a subclass of "FramedFilter" - for 
encoding each frame.  In particular, your "FramedFilter" subclass 
would implement the virtual function "doGetNextFrame()".

I suggest that you start by taking a look at our implementation of 
the "uLawFromPCMAudioSource" class, because that's the closest thing 
that we have in our library to a 'codec'.
--

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Permalink | Reply |
headers
Brian Michalk | 1 Feb 2011 17:25

Re: Simple Filter leading to a CODEC


On 2/1/2011 10:05 AM, Ross Finlayson wrote:
>> This is a brand new codec, so I'll need to specify an RTP payload for 
>> that.  It's for low bitrate high packet loss networks, and works off 
>> of single frame encoding, because a dropped iFrame is not desirable.
>
> OK, let us know when you've submitted an Internet Draft that describes 
> your proposed RTP payload format, and then I'll help you implement it 
> using the "LIVE555 Streaming Media" libraries.  (This implementation 
> would be (at least) a subclass of "MultiFramedRTPSink" (for sending 
> RTP), and a subclass of "MultiFramedRTPSource" (for receiving RTP).)
>
> (It's going to be interesting to see how you come up with a 
> single-frame video encoding that's also low-bitrate, because those two 
> usually don't go together.)

Thanks.  Actually, my problem right now is not with RTP at all, it's 
with how to access the picture frames to implement the codec.  I was 
wanting to know the "best" way to go about tinkering with the video.  My 
thought was to take the MPEG2 sources and modify those, but perhaps 
there is a better way?  That's why I laid out the simple goal of 
modifying the Y plane.  Once I get there, I am confident that the rest 
will be fairly straightforward.
Permalink | Reply |

Gmane