[Live-devel] Frames are corrupted

[Vikram Singh]

Thank you ross and chris. It works !! J

 

From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of
Ross Finlayson
Sent: Thursday, May 01, 2014 10:57 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Frames are corrupted

 

 

On May 1, 2014, at 9:58 AM, Vikram Singh <vikram at vizexperts.com> wrote:





Hi ross,

I am not able to get SPS and PPS units from the encoder.

I am using CUDA Video Encode library which has a function NVGetSPSPPS().

[...]

 

Sorry I am not getting the detailed documentation for the function
NVGetSPSPPS(). Please help me.

 

"NVGetSPSPPS()" is not a function in our code, so I don't know why you're
asking here.  Why don't you ask whoever provided you the "CUDA Video Encode
library"?

 

 

However...





NVGetSPSPPS() returns  a buffer to SPS and PPS.

The problem is that I don't have the formatting for this buffer so that I
could separate SPS and PPS units from each other.

 

In my case this buffer is

 

               00 24 67 4d 40 1e f6 04 00 83 7f e0 00 80 00 62 00 00 07 d2
00 01 d4 c1 c0 00 00 27 a1 20 00 02 62 5a 17 79 70 50 00 04 68 ee 3c 80

 

It seems quite clear that the encoding is:

            Sequence of:

                        2-byte 'length' (in big-endian order)

                        'length' bytes, containing the NAL unit (without a
preceding 'start code')

 

 

 According to my assumption 
 
                   00 00 00 01 67 4d 40 1e f6 04 00 83 7f e0 00 80 00 62 00
00 07 d2 00 01 d4 c1 c0 00 00 27 a1 20 00 02 62 5a 17 79 70 50 00 04 ==> sps
And            00 00 00 01 68 ee 3c 80 ==> pps

 

Not quite, because it seems clear that the "00 24" is a length field (i.e.,
0x0024 == 36 decimal).  Therefore SPS is

            67 4d 40 1e f6 04 00 83 7f e0 00 80 00 62 00 00 07 d2 00 01 d4
c1 c0 00 00 27 a1 20 00 02 62 5a 17 79 70 50

then the next two bytes - 00 04 - are also a length field (therefore, *not*
part of the NAL unti), so PPS is

            68 ee 3c 80

 

You should therefore pass these two NAL units - without start codes - as
parameters to

            H264VideoRTPSink::createNew()

This will be the second form of "H264VideoRTPSink::createNew()" - i.e., the
form that has the signature

            static H264VideoRTPSink* createNew(UsageEnvironment& env,
Groupsock* RTPgs, unsigned char rtpPayloadFormat,
                                                            u_int8_t const*
sps, unsigned spsSize,

                                                            u_int8_t const*
pps, unsigned ppsSize,
                                                            unsigned
profile_level_id);

 

Note that you also need to pass a "profile_level_id" parameter.  This is
actually a flaw in the code, because you can generate this parameter from
the 2nd through 4th bytes of the SPS NAL unit.  (I.e., this parameter
shouldn't be needed.)  So, in your case, the "profile_level_id" parameter
would be

            0x4d401e

 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140502/1e3566a8/attachment-0001.html>