Ross, Thanks for the pointers. I agree that the system is complex, and unfortunately, given the constraints, I think it has to be.
Anyway, if you care, I narrowed down the problem to the difference (probably in my use or understanding) between the MPEG4VideoStreamFramer and the MPEG4VideoStreamDiscreteFramer. I was previously using the MPEG4VideoStreamFramer because my client was concatenating RTP packets to achieve a desired file size. Using this setup, VLC kept complaining about "picture is too late to be displayed". I modified the code to have the client only write out single RTP packets which I believe will be single MPEG4 frames, and I substituted the MPEG4VideoStreamFramer for the MPEG4VideoStreamDiscreteFramer and everything works wonderfully now. I noticed there were a few comments of "HACK ####" in the MPEG4VideoStreamFramer around setting of the fPictureEndMarker. Is this something that was intended to be fixed? Thanks again, Randy On Sat, Sep 3, 2016 at 1:59 AM, Ross Finlayson <finlay...@live555.com> wrote: > > The current setup is using an Axis camera as device A that is pointed to > a digital clock that can display seconds. It is streaming MPEG4-ES data, > so I am using the MPEG4VideoFileServerMediaSubsession (with the exception > that I am passing in my ByteStreamFolderSource instead of the > ByteStreamSource). When I connect to C via VLC, the video plays but > several seconds into the video, the frames start to get choppy and > occasionally I will see the seconds on the clock go backwards and then jump > forwards. > > > > Is the reason for this choppy video because the Live555 RTSP server does > not have access to the correct time stamp information and/or SDP metadata? > > I don’t know enough about your (IMHO, excessively complex) custom > application to know for sure what’s going on. However, if you’re seeing > video that’s several seconds in the past, then it must be because that > video got delivered to server “C” out of order - somehow. (Either that, or > else server “C” is streaming the data out of order (e.g., due to a file > name ordering bug).) > > But again, the complexity of your custom application far exceeds what I > can meaningfully answer on this mailing list ‘for free’. > > > 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 > -- Randy Scheifele Applied Technology 847-576-4176
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
