[Live-devel] One-frame delay in h264 streaming app

Алексей Алексеевич Карнаухов karnaukhov at physics.msu.ru
Wed Apr 9 08:18:36 PDT 2014


Thanks,
I follow your recommendation and now I get almost zero delay.
Problem was when I tried to use ..DiscreteFramer, I`ve got a lot of those
errors about "MPEG start code found...", even if I use annex_b=0 flag in
x264 settings. Only when I truncate first 4 bytes of every NAL unit all
begins to work.
And again, stakoverflow saved my time... I dont pretend on first rate
skills)
http://stackoverflow.com/questions/19427576/live555-x264-stream-live-source-based-on-testondemandrtspserver


2014-04-07 22:11 GMT+04:00 Ross Finlayson <finlayson at live555.com>:

> I`m implementing low-latency h264 rtsp source. Based on this code
>
> http://stackoverflow.com/questions/13863673/how-to-write-a-live555-framedsource-to-allow-me-to-stream-h-264-live
>
>
> Oh please!  Only second-rate programmers use 'stackoverflow.com'.
>
> The proper web site for documentation on the "LIVE555 Streaming Media"
> code is <http://www.live555.com/>.  In particular, you should read
> http://www.live555.com/liveMedia/faq.html#liveInput
> and
> http://www.live555.com/liveMedia/faq.html#liveInput-unicast
>
>
> I wrote subclass of FramedSource and able to watch this stream in my
> client app. But even if I put 1 frame per second setting in x264 codec, I
> have exactly one frame-delayed data in my client. This delay is 100% on
> server side, because MultiFramedRTPSink::sendPacketIfNecessary() sending
> compressed data of previous frame (i just compare first several bytes of
> data in fOutBuf with those I wrote in fTo).
>
>
> I haven't looked at your code in detail, but you should note that once a
> H.264 NAL unit is delivered to the downstream
> "H264VideoStreamDiscreteFramer" object (using
> "FramedSource::afterGetting()"), this delivery will take place immediately.
>  Similarly, the delivery from the "H264VideoStreamDiscreteFramer" to *its*
> downstream object - a "H264VideoRTPSink" - will also take place
> immediately.  There is no '1 frame (NAL unit) delay'.
>
> (Note also that for H.264 video streaming, because you are delivering
> discrete NAL units (i.e., one at a time), your NAL unit source class *must*
> feed into a "H264VideoStreamDiscreteFramer" object (*not* a
> "H264VideoStreamFramer"), and each NAL unit that's delivered *must not*
> begin with a 0x00000001 'start code'.)
>
>
>     nextTask() = envir().taskScheduler().scheduleDelayedTask(0,
>                 (TaskFunc*)FramedSource::afterGetting, this);
>
>
> Because your code will already be returning to the event loop immediately
> afterwards, note that you can simplify this to
> FramedSource::afterGetting(this);
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140409/4a5c94fe/attachment-0001.html>


More information about the live-devel mailing list