[Live-devel] H264DiscreteFramer from custom source

Wed Nov 9 03:17:31 PST 2011

Thanks Ross.  The stream seems to be sending ok now, but I'm having
some problems receiving.  For as far as I can tell the stream appears
to be correctly formatted, but neither VLC or OpenRTSP is able to
create valid output from it.

I'm pretty confident that the frames are encoded correctly, if I use a
non-discrete framer with the startcodes attached, VLC can display the
stream (but it's inefficient, dropping frames and the frameloader
buffer keeps getting truncated here), anyway from the FAQ & to my
knowledge the discrete framer is correct.

I've put an avi of the stream here:

http://www.cs.nott.ac.uk/~jzn/live/test.avi

Which was generated using the command line:

openRTSP.exe -4 -w 256 -h 64 -f 30 -d 10 rtsp://.... > test.avi

I've also got a wireshark trace that was able to interpret the H264
stream (using an RTP filter & setting H264 protocol from preferences),
here the NAL type order is shown as:

SPS (7)
PPS (8)
IDR Picture (5)
 (6 packets)
Slice (1)
Slice (1)
....

And in the footer of this e-mail there's a VLC log, it seems to buffer
twice, but doesn't show any errors or display anything.  Do you have
any pointers for me?  Realise this is a tricky one, but are there any
'common' or likely causes of these problems?  Happy to provide
whatever extra information might be helpful.

Thanks again,
James

main debug: processing request item rtsp://127.0.0.1:49990/CamBlend
node Playlist skip 0
main debug: resyncing on rtsp://127.0.0.1:49990/CamBlend
main debug: rtsp://127.0.0.1:49990/CamBlend is at 2
main debug: starting new item
main debug: creating new input thread
main debug: Creating an input for 'rtsp://127.0.0.1:49990/CamBlend'
main debug: thread (input) created at priority 1 (../.././src/input/input.c:220)
main debug: thread started
main debug: using timeshift granularity of 50 MiB
main debug: using timeshift path 'C:\Users\jzn\AppData\Local\Temp'
main debug: `rtsp://127.0.0.1:49990/CamBlend' gives access `rtsp'
demux `' path `127.0.0.1:49990/CamBlend'
main debug: creating demux: access='rtsp' demux=''
path='127.0.0.1:49990/CamBlend'
main debug: looking for access_demux module: 1 candidate
live555 debug: RTP subsession 'video/H264'
qt4 debug: IM: Setting an input
main debug: selecting program id=0
live555 debug: setup start: 0.000000 stop:0.000000
live555 debug: We have a timeout of 60 seconds
live555 debug: spawned timeout thread
live555 debug: play start: 0.000000 stop:0.000000
main debug: using access_demux module "live555"
main debug: TIMER module_need() : 27.000 ms - Total 27.000 ms / 1
intvls (Avg 27.000 ms)
main debug: looking for decoder module: 34 candidates
avcodec debug: libavcodec already initialized
avcodec debug: trying to use direct rendering
avcodec debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) started
main debug: using decoder module "avcodec"
main debug: TIMER module_need() : 1.000 ms - Total 1.000 ms / 1 intvls
(Avg 1.000 ms)
main debug: looking for packetizer module: 21 candidates
main debug: using packetizer module "packetizer_h264"
main debug: TIMER module_need() : 0.000 ms - Total 0.000 ms / 1 intvls
(Avg 0.000 ms)
main debug: thread (decoder) created at priority 0
(../.././src/input/decoder.c:301)
main debug: thread started
main debug: looking for meta reader module: 2 candidates
lua debug: Trying Lua scripts in \\keats\rapg$\jzn\Application
Data\vlc\lua\meta\reader
lua debug: Trying Lua scripts in C:\Program Files (x86)\vlc\lua\meta\reader
lua debug: Trying Lua playlist script C:\Program Files
(x86)\vlc\lua\meta\reader\filename.lua
main debug: no meta reader module matching "any" could be loaded
main debug: TIMER module_need() : 4.000 ms - Total 4.000 ms / 1 intvls
(Avg 4.000 ms)
main debug: `rtsp://127.0.0.1:49990/CamBlend' successfully opened
main debug: Buffering 0%
packetizer_h264 debug: found NAL_SPS (sps_id=0)
main debug: Buffering 1%
packetizer_h264 debug: found NAL_PPS (pps_id=0 sps_id=0)
main debug: Buffering 4%
main debug: Buffering 7%
main debug: Buffering 9%
main debug: Buffering 12%
main debug: Buffering 15%
main debug: Buffering 17%
main debug: Buffering 20%
main debug: Buffering 22%
main debug: Buffering 25%
main debug: Buffering 28%
main debug: Buffering 30%
main debug: Buffering 33%
main debug: Buffering 36%
main debug: Buffering 38%
main debug: Buffering 41%
main debug: Buffering 43%
main debug: Buffering 46%
main debug: Buffering 49%
main debug: Buffering 51%
main debug: Buffering 54%
main debug: Buffering 56%
main debug: Buffering 59%
main debug: Buffering 62%
main debug: Buffering 64%
main debug: Buffering 67%
main debug: Buffering 69%
main debug: Buffering 72%
main debug: Buffering 75%
main debug: Buffering 77%
main debug: Buffering 80%
main debug: Buffering 82%
main debug: Buffering 85%
main debug: Buffering 88%
main debug: Buffering 90%
main debug: Buffering 93%
main debug: Buffering 96%
main debug: Buffering 98%
main debug: Stream buffering done (1217 ms in 1218 ms)
main debug: Decoder buffering done in 0 ms
live555 debug: tk->rtpSource->hasBeenSynchronizedUsingRTCP()
main debug: ES_OUT_RESET_PCR called
main debug: Buffering 0%
main debug: Buffering 2%
main debug: Buffering 5%
main debug: Buffering 7%
main debug: Buffering 10%
main debug: Buffering 13%
main debug: Buffering 15%
main debug: Buffering 18%
main debug: Buffering 20%
main debug: Buffering 23%
main debug: Buffering 26%
main debug: Buffering 28%
main debug: Buffering 31%
main debug: Buffering 33%
main debug: Buffering 36%
main debug: Buffering 39%
main debug: Buffering 41%
main debug: Buffering 44%
main debug: Buffering 47%
main debug: Buffering 49%
main debug: Buffering 52%
main debug: Buffering 54%
main debug: Buffering 57%
main debug: Buffering 60%
main debug: Buffering 62%
main debug: Buffering 65%
main debug: Buffering 68%
main debug: Buffering 70%
main debug: Buffering 73%
main debug: Buffering 75%
main debug: Buffering 78%
main debug: Buffering 81%
main debug: Buffering 83%
main debug: Buffering 86%
main debug: Buffering 89%
main debug: Buffering 91%
main debug: Buffering 94%
main debug: Buffering 97%
main debug: Buffering 99%
main debug: Stream buffering done (1227 ms in 1227 ms)
main debug: Decoder buffering done in 0 ms

On Tue, Nov 8, 2011 at 4:37 PM, Ross Finlayson <finlayson at live555.com> wrote:
> Should I schedule a deliverFrame (and FramedSource::afterGetting( ..)
> for each NAL, i.e. making a queue of NALs and repeatedly scheduling
> deliverFrame in order to send a single frame.
>
> Yes, a "H264VideoStreamDiscreteFramer" expects to be fed one NAL unit at a
> time - *not* one frame at a time.
> In fact, this is especially important for SPS and PPS NAL units, because
> the "H264VideoStreamDiscreteFramer" code recognizes and saves a copy of
> those NAL units (for use in the stream's SDP 'config' string).
> If you can, try to make the SPS and PPS NAL units the first NAL units that
> come from your encoder, for each new stream.  This is not essential (as long
> as SPS and PPS NAL units appear eventually), but it will make the server
> more efficient.
>
> 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
>
>