• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 418 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.

DM355 Implementing Video Playback Seek Forward & Reverse

SteveG10854
Intellectual 510 points

I'm looking for a bit of advice on use of the VIDDEC2_process for decoding video.

My application is based upon the 'decode' demo app.

I've added features so I can record directly into MPEG4 or AVI container format, where during recording the encoded frames are packaged into and stored as MPEG/AVI atoms. My playback works fine by extracting the frames from the MPEG4/AVI file and passing them through VIDDEC2_process.

My problem is in implementing a video seek forward and seek reverse feature, where the user can playback at say double or quad speed in forwards or reverse.

Because of the MPEG4/AVI packaging I know exactly the location and size of each frame on disk so I can pick and choose which frames I read for playing back.

For seek forward I believe I can't just simply skip and ignore few frames from the file before passing one to the decoder, because the decoder will remember the previous frame it had, and if some frames are skipped before presenting it with another frame, those missing frames will screw up the decode (ie. decoder works on the differences between proper consecutive frames). So during forward seek I therefore have to pass each frame to the decoder whether it needs it or not, but reading and decoding lots of superfluous frames takes a while. I tried just skipping frames and I quickly get a multicoloured splat on the display.

The frames were stored during recording directly from the encoder, so there are no synch frames (ie. full unencoded frames, apart from the one at the start of the recorded file). Do I need to implement synch frames every so often in the recorded file, or is there a way to make the VIDDEC2_process resynch itself and deal with incoming 'missing' frames?

For reverse seek this looks even more difficult, as the frames are stored in order of time and changes between one frame to the next. I think I can't simply grab a frame and send it to the decoder, then grab the *previous* frame and send this to the decoder and so on... or can I?

Many thanks

  • 0
    TI__Mastermind 37340 points

    I cannot recall the specifics of the MPEG4 standard, but if there is a way you can extract the 'frame-type' information (I, B, or P), you can skip all frames until you hit the first I-frame (this frame-type should not have dependancies on other frames with regards to decoding).  Maybe you only want to decode I-frames when doing seek forward or backward, this would certainly simplify things.

  • 0
    TI__Mastermind 37340 points

    ok, doing a little more digging into this, when you encode the file using our MPEG4 encoder, one of the arguments you get back along with the encoded video buffer is the frametype, (VIDDEC_OutArgs.encodedFrameType ).  you would need to save this information, at least for I-frames, and then implement your algorithm.

  • 0 in reply to Juan Gonzales
    Intellectual 510 points

    I've got the search working.

    There is a dynamic parameter called 'intraFrameInterval' in the encoder configuration which tells the encoder to insert I-Frames and how often. I set this to 25 (being PAL) so an I-Frame is inserted every second.

    My search functions align themselves to looking at frames appearing on a multiple of 25. I have a framecount maintained during playback which I either round up or down to nearest multiple of 25, and during search I skip 25 frames back or forth from this point at varying rates.

    This works fine for recording and playback on using my app on TI hardware but will need I-Frame locations embedding into the MP4 files if they are to be played on other systems, eg. a PC.

    Thanks for giving me the clue by mentioning the encodedFrameType and using I-Frames for seeking.