• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 521 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DM365 & H.264 Issues

John Anderson
Genius 5240 points

After being away from the DM365 for a while and coming back I'm having problems with H.264.  Here's the lowdown....

I had H.264 encoding, streaming RTP, and playing back live streaming video with VideoLan Client when using the 2.10.00.13 DVSDK.

Now I am using the 2.10.01.18 DVSDK and I cannot get Venc1_create call to succeed.  Using DMAI_DEBUG=2 I see the call fails with a XDM_SETPARAMS error status.

The original code that ran unde the 2.10.00.13 sdk now fails after recompiling for the 2.10.01.18 sdk.  If I hadn't already had this working I would be thinking it'solely my stupidity, but something must be up.  It was pretty easy getting this working the first time because I just took the encodedecode demo and gave it a workover for H.264 and added RTP/RTSP.

What's got me wondering is that the doc for the H.264 encoder uses a IH264VENC_Params and IH264VENC_DynamicParams, where the demo and my initial version uses VIDENC1_Params and VIDENC1_DynamicParams.  Now I wonder which is the correct data structure to use?  I've switched to using the IH264VENC specific structures and loaded them with the appropriate defaults, but I still get the same XDM_SETPARAMS error.  So my two questions are....

1) Should I continue to use the generic VIDENC1_xxx structures or use the codec specific ones in the call to Venc1_xxxx?  I do have to cast them as the generic version for the compile to succeed.

2) Is there anything that is common knowledge as to why code that works from 2.10.00.13 would now fail under 2.10.01.18.

 

Thanks, John

  • 0
    Genius 5240 points

    OK, now I've figured out what was different.  In my application I was setting interFrameInterval to 30.  This is the number of B frame interleaved and should be zero for now.  The number 30 is not valid and was apparently ignored by the H264 codec in the earlier DVSDK.

    Now the same application that worked in the earlier SDK is crashing with an alignment error.  Oh well, back to the drawing board.

  • 0
    TI__Mastermind 19985 points

    Hi John,

    John Anderson said:

    What's got me wondering is that the doc for the H.264 encoder uses a IH264VENC_Params and IH264VENC_DynamicParams, where the demo and my initial version uses VIDENC1_Params and VIDENC1_DynamicParams.  Now I wonder which is the correct data structure to use?  I've switched to using the IH264VENC specific structures and loaded them with the appropriate defaults, but I still get the same XDM_SETPARAMS error.  So my two questions are....

    IH264VENC_xxxx are codec specific structures. If you look at the structure definition, you can make out that it includes the generic structure VIDENC1_xxxx. Codec specific structures allow you to have much more control on specific codecs as compared to the generic parameters.

    As you said, you would need to typecast the IH264VENC_xxxx structure to VIDENC1_xxxx structure before passing them to XDM_SETPARAMS IOCTL.

    BTW, if you tell us the extendedErrorCode that comes in the output of XDM_SETPARAMS, we can try to find out the exact parameter that has gone wrong. It might be some parameter that is not correctly set or is not supposed to be set.

    In DVSDK 2.10.00.13, you were always using the VIDENC1_xxxx generic parameters and hence codec would used have its default for the specific parameters, so it might be working.

    Regards,

    Anshuman

  • 0 in reply to Anshuman Saxena
    TI__Genius 17205 points

    Just a few quick links relevant to Anshuman's post...

    Anshuman Saxena said:
    IH264VENC_xxxx are codec specific structures. If you look at the structure definition, you can make out that it includes the generic structure VIDENC1_xxxx. Codec specific structures allow you to have much more control on specific codecs as compared to the generic parameters.

    The 'extended structs' feature of XDM is described here - Extending data structures in XDM.

    Anshuman Saxena said:
    BTW, if you tell us the extendedErrorCode that comes in the output of XDM_SETPARAMS, we can try to find out the exact parameter that has gone wrong. It might be some parameter that is not correctly set or is not supposed to be set.

    A description of the extendedError can be found here - How do I decode extendedError.

    Chris

  • 0 in reply to Chris Ring
    Genius 5240 points

    That's for the comments.  As mentioned the offending parameter turned out to be interFrameInterval.  I mistakenly took this to mean distance between I frames, and the earlier SDK ignored my wrong value.

    Although not specifically answered I'm assuming that the codec specific structures are not required.  I'm using the codec specific structures in my code now simply because I've already put them trying to solve this problem.

    Also I managed to fix the alignment trap and subsequent bus error and app crash.  I had cast a char* to a long * in order to more easily search for start codes.  It's streaming H.264 again.  Thanks for the help.  Especially those links that Chris posted.  I did not know how to find the extended codes.

     

    John