Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SPS PPS IDR frame in Streaming from Encoder 1.00 on DM6467

Dear Expert,

I was using 264 ENCODER 1.00 on DM6467. My player is VLC.

with the help of some threads on this forum, I am able to insert periodic SPS PPS and IDR frames in my stream.

If VLC is opened before the start of UDP streaming, video can be displayed on VLC.

but if VLC is opened at somewhere in the UDP streaming, the video can never be displayed. In elecard eye viewer, period SPS, PPS and IDR frames can be found.

Can anyone help on this? is this a configuration problem of is VLC or SPS PPS and IDR frame insertion wrong?

attached is my 264 video.

1641.idrSample6.zip

thanks for your help.

  • Hello Vincent,

    Here is some advice from my experience, TI probably knows a bit more :)

    Do you generate the SPS/PPS by hand and insert it into the stream or are you letting the encoder provided do that?  If you are manually generating them did you confirm in StreamEye, later SPS/PPS are the same as the very first SPS/PPS that was automatically generated?  I found manually generating the header very tricky and it took many tests before I had all the bits lined up correctly.

    Basically, I also remember that until VLC got an SPS/PPS header it would do nothing.  Then we found that there was some issues with frame rate and buffering due to the receiving the header late.  Also, the standard header provided with the encoder does not have any information about the frame rate.  This means VLC is assuming 30 frames/s.  So if you are delayed in getting the header and then you are not going at 30 fps it could take some time for VLC to catch up. 

    In the end, I had the encoder generate a header for me once and I stored it away to be attached to every frame I sent out via UDP.   The IDR frames I inserted at a much slower rate (every 80 frames or so).  Increasing or decreasing this interval did not seem to effect the playback on VLC.

  • Hi Brandy,

    thanks for your reply.

    I let the encoder provide the sps/pps. After certain dark days, my code worked now.

    I found some TI documents really confusing. I'm using encoder 1.00. In this release note, nothing was mentioned as to sps/pps header. In 1.20 release note, it says sps/pps frame can be inserted. But this frame only contains header. I guess this applies to 1.00 release as well. To my surprise, in encoder 1.00, sps and pps frames are added to the stream with IDR frame, if you write code as

    dynParams->forceFrame = IVIDEO_IDR_FRAME;
    dynParams->generateHeader = XDM_GENERATE_HEADER;
    

    With this code, SPS/PPS and IDR frames can be inserted periodically. SPS/PPS frames are the same as the 1st SPS/PPS.

    how do you attach the sps/pps frame?  do  you do this on dsp or you record SPS/PPS frame on the player side then copy this at DSP? With manual insertion, does frame rate issue happen as well?

    btw, I don't know why only 264 encoder1.00 works on my project. encoder1.20 never worked. do you have any idea on this?

    thanks.

  • Ahh yes, sorry, I didn't realize that that wasn't clear to you.  When you ask it to generate a header, it only generates the header.  I can confirm that for the 1.20 encoder.

    Since I wanted to add the fixed frame rate data to the SPS header, I had to add a few bits which extended the size of the header.  So what I do is I always a bit conveluded.

    First I generate my header, store it and record its size.  (My header has SPS, PPS and UID data in it.  The SPS contains the extra fields to declare a fixed frame rate such as 3Hz or whatever, the PPS is unchanged and UID is a user defined message).

    Then I generate an encoder header and record its size only.  No need to store it once I was sure my headers were working.

    Then if the frame was an IDR frame, I can tell where the imagery started based on the size and ignore the encoder's header.

    In my setup I just stream a raw encode stream (no Transport Stream wrapping or anything).  So when I send the message I first send my headers and then send the encoded frame.

    All of the code is contained on the ARM in the application that is controlling the DSP/codec server/engine.  I did not bother to rebuild the codec to try to make it do my own header.  This was easier.

    I am not sure why the 1.20 would not work.  It is happy in my application.  Perhaps there is a compatibility issue with your codec engine and server.  I know that I once tried to upgrade my codec engine and found a great many issues with my application and eventually just gave up.  I would definitely try to post that question under an other post.  I thought that the 1.20 was vastly improved over 1.00 but I could be mistaken.  I use Codec Engine 2.25.05.16, Codec Server 1.00.00.10 which contains H264 encoder v 1.20.02

    Let me know if there is anything else.