Ross,
Thank you for clarification. I do see your point about aborting the client side
right away (you were correct about this being a client app), however,
considering other possible causes (temporary packet loss? some other momentary
hiccup on the LAN?), I prefer to keep session closure (e.
> Okay, let me try being more specific:
>
> 1) The application streams RTSP H264 video.
By “streams”, do you mean transmits, or receives?
If you mean “transmits”, then what is generating the H.264 video? Is it coming
from a file, or from a device (that the OS treats as a file)?
If you mean
Okay, let me try being more specific:
1) The application streams RTSP H264 video.
2) The source is a stock source created by the stack while initializing H264
RTP stream for RTSP session. Not subclassing for it at all. A very rudimentary
“do-nothing” sink is subclassed from MediaSink. The o
> Have been seeing some errors, where if a timeout occurs in getNextFrame, the
> next getNextFrame call will result in an abort() call (due to
> fIsCurrentlyAwaitingData being set).
What object is this? Is this a subclass of “FramedSource” that you have
written yourself - e.g., to deliver data
Hi,
Have been seeing some errors, where if a timeout occurs in getNextFrame, the
next getNextFrame call will result in an abort() call (due to
fIsCurrentlyAwaitingData being set).
What is the proper behavior in this case:
1) Don’t call getNextFrame again, this source is tainted (don’t belie
