Re: [Live-devel] Regarding the start code handling in h264

2014-05-31 Thread Ross Finlayson
> But in the second case, even if I din't parse the data, and every nalu is > started with start code, but live555 worked correctly. You *might* be able to stream the second type of data by passing it to a "H264VideoStreamFramer" (rather than a "H264VideoStreamDiscreteFramer"). I don't recomme

Re: [Live-devel] Regarding the start code handling in h264

2014-05-30 Thread Tony
But in the second case, even if I din't parse the data, and every nalu is started with start code, but live555 worked correctly. The h264 data client recieved doesn't have start code. So live555 has removed them? At 2014-05-29 09:42:15, "Ross Finlayson" wrote: In each case - because your

Re: [Live-devel] Regarding the start code handling in h264

2014-05-28 Thread Ross Finlayson
In each case - because your input source is H.264 video - your input source object (i.e., your subclass of "FramedSource") must deliver NAL units - *without* any 'start code' - one at a time to a "H264VideoStreamDiscreteFramer" (*not* a "H264VideoStreamFramer"). >One is living video, other

[Live-devel] Regarding the start code handling in h264

2014-05-27 Thread Tony
Hi Ross, My system has two type rtsp stream. One is living video, other device transfer their h264 data to my system, I copied them to one queue, and the framed source would get one sample every time, these sample is h264 nalu, and isn't add start code (0x00,0x00,0x00,0x01). Other is