Splitter SetRate Negative

[franknatoli]

How exactly does a splitter behave after being called with SetRate with argument negative one? I observe that it does run backward, but it lurches backward by I-frame then forward by intermediate B and P frames.

For example, here is the information returned by VideoData::GetTime function after Splitter::SetRate is set to negative one:

2009-05-26 21:07:10.700 41.786
2009-05-26 21:07:10.730 41.819
2009-05-26 21:07:10.750 41.853
2009-05-26 21:07:10.780 41.886
2009-05-26 21:07:10.800 41.919
2009-05-26 21:07:10.810 41.953
2009-05-26 21:07:10.860 41.986
2009-05-26 21:07:10.890 42.019
2009-05-26 21:07:10.921 42.053
2009-05-26 21:07:10.941 42.086
2009-05-26 21:07:10.961 42.120
2009-05-26 21:07:10.991 42.153
2009-05-26 21:07:11.011 42.186
2009-05-26 21:07:11.041 42.220

2009-05-26 21:07:11.061 41.319
2009-05-26 21:07:11.091 41.352
2009-05-26 21:07:11.111 41.385
2009-05-26 21:07:11.141 41.419
2009-05-26 21:07:11.161 41.452
2009-05-26 21:07:11.181 41.486
2009-05-26 21:07:11.211 41.519
2009-05-26 21:07:11.241 41.552
2009-05-26 21:07:11.251 41.586
2009-05-26 21:07:11.291 41.619
2009-05-26 21:07:11.321 41.652
2009-05-26 21:07:11.341 41.686
2009-05-26 21:07:11.371 41.719
2009-05-26 21:07:11.391 41.753

2009-05-26 21:07:11.431 40.852
2009-05-26 21:07:11.451 40.885
2009-05-26 21:07:11.481 40.918
2009-05-26 21:07:11.501 40.952
2009-05-26 21:07:11.521 40.985
2009-05-26 21:07:11.551 41.018
2009-05-26 21:07:11.571 41.052
2009-05-26 21:07:11.602 41.085
2009-05-26 21:07:11.622 41.119
2009-05-26 21:07:11.652 41.152
2009-05-26 21:07:11.672 41.185
2009-05-26 21:07:11.702 41.219
2009-05-26 21:07:11.712 41.252
2009-05-26 21:07:11.752 41.285

The above shows a date+time stamp followed by GetTime information. Note that GetTime increases for fourteen frames, not coincidentally the number of frames between MPEG-2 I-frames, then lurches backward approximately one half second from the previous I-frame. Is this in fact how the splitter is intended to run? The result is awful. The user sees forward motion, then a jump backward, then more forward motion, then another jump backward, incrementally reversing, but also presenting a visually terrible forward/backward flipping.

I don't suppose there's any way to get nice, simple, reverse playback?

Thanks.

[franknatoli]

It appears that the above is how IPP is intended to perform.

umc_manual.pdf, page 4-441, table 4-96, "predefined ranges of playback rate values", reveals that the SetRate argument is not a multiplier, even though it is a signed floating point number. It is apparently a code, with one meaning for MPEG2/MPEG4 and another meaning for H264. The codes are too complex to summarize. Take a look at the table in the document.