> 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 there for many years, so the fact that it
is an issue for you only with this new release of the code suggests that you
probably had made improper modifications to whatever version of the code you
were using before.
> but since my source is not this class, my code now crashes.
>
That should not be happening, because if if you try to call "getPlaying()" on a
"H264VideoRTPSink" with an object that is *not* a "H264VideoStreamFramer", you
should never get to that code, because the previous call to
"sourceIsCompatibleWithUs()" on line 70 of "MediaSink.cpp" should have returned
False. (This is because "H264VideoRTPSink" reimplements the
"sourceIsCompatibleWithUs()" virtual function to return True only if the source
object is a "H264VideoStreamFramer".) So this suggests that you are *still*
making changes to the supplied source code. Please stop doing this, if you
want to get support on this mailing list!
See:
http://www.live555.com/liveMedia/faq.html#modifying-and-extending
The bottom line is that the object that feeds into a "H264VideoRTPSink" *must*
be a "H264VideoStreamFramer", or a subclass of this. The solution is simple:
Create a "H264VideoStreamDiscreteFramer" (note, *not* a
"H264VideoStreamFramer") object in front of your source object (i.e., in front
of the object that delivers discrete H.264 NAL units - presumably from an
encoder).
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
