As long as the object that you feed to your "H264VideoRTPSink" is a
"H264VideoStreamFramer" - or a subclass thereof - everything should work OK.
But rather than writing your own subclass of "H264VideoStreamFramer", why not
just use the "H264VideoStreamDiscreteFramer" subclass that we have alread
o: LIVE555 Streaming Media - development & use
,
Date: 2013-04-03 14:54
Subject:Re: [Live-devel] H264VideoRTPSink type cast issue
Sent by:live-devel-boun...@ns.live555.com
I recently updated to the latest version of the library (March 23rd
> I recently updated to the latest version of the library (March 23rd 2013
> version) but I came across a new issue with H264VideoRTPSink. In the
> function doSpecialFrameHandling there is "specific" type cast of the frame
> source to H264VideoStreamFramer
>
That's correct. That code has been
Hi there,
I recently updated to the latest version of the library (March 23rd 2013
version) but I came across a new issue with H264VideoRTPSink. In the
function doSpecialFrameHandling there is "specific" type cast of the frame
source to H264VideoStreamFramer but since my source is not this clas
OK, this will get changed in the next release of the software.
--
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
Apologies,
Of course I meant to ask to make H264VideoRTPSink::auxSDPLine protected
instead of private. In both cases it should be virtual.
Stuart
On 8/6/09 11:23 AM, "Stuart Rawling" wrote:
> Could we make the auxSDPLine() function of H264VideoRTPSink protected instead
> of virtual?
-
Hi Ross,
Could we make the auxSDPLine() function of H264VideoRTPSink protected
instead of virtual? This way subclasses do not have to re implement the
contents of the H264VideoRTPSink::auxSDPLine() if they which to just extend
what is already generated in the parent class. This would be consiste
