[Live-devel] Buggy mpeg4 stream and timestamps

[Jeff Shanab]

I have been having a tough time with an IP camera that serves out MPEG4.
I have dug into the headers and all that bit parseing and I think I understand why the timestamps are messed up.
It has no "Group Of Video Object Plane" headers, but that is ok, they are "optional"
But the vop_time_increment rolls over and the modulo_time_base is ALWAYS 0. :(

My question is about the if condition in MPEG4VideoStreamParser::parseVideoObjectPlane() that handles these kinds of "buggy" mpeg 4 streams.

It reads:

...
    } else {
      if (newTotalTicks < fPrevNewTotalTicks && vop_coding_type != 2/*B*/
      && modulo_time_base == 0 && vop_time_increment == 0 && !fJustSawTimeCode) {
    // This is another kind of buggy MPEG-4 video stream, in which
    // "vop_time_increment" wraps around, but without
    // "modulo_time_base" changing (or just having had a new time code).
    // Overcome this by pretending that "vop_time_increment" *did* wrap around:
#ifdef DEBUG
    fprintf(stderr, "Buggy MPEG-4 video stream: \"vop_time_increment\" wrapped around, but without \"modulo_time_base\" changing!\n");
#endif
    ++fSecondsSinceLastTimeCode;
    newTotalTicks += vop_time_increment_resolution;

...

In my case vop_time_increment is never (or very rarely) exactly 0. It is usually a number below 100. Also the ticks case is never true.
When I add a last_vop_time_increment variable and change the test I can get it to execute this code with improved results.
...
if ((vop_time_increment - last_vop_time_increment_ < 0) && vop_coding_type != 2/*B*/
      && modulo_time_base == 0 && !fJustSawTimeCode_)
...

It still has a negative jump in the timestamps, but they are at least now very predictable and patterned.

Is MPEG4 just that way? Messy group of non-compliant streams?

  Jeff Shanab, Manager, Software Engineering
  D 630.633.4515  | C 630.453.7764 | F 630.633.4815  |  jshanab at smartwire.com
[Description: Description: Description: Description: cid:706AA5FB-B29A-4B95-B275-FE31EE559CF0 at hsd1.il.comcast.net.]<http://www.smartwire.com/>
  [Description: Description: Description: Description: Description: Description: Description: sig4] <https://twitter.com/#!/WindyCityWire>   [Description: Description: Description: Description: Description: Description: Description: sig3] <http://www.youtube.com/user/WindyCityWire>   [Description: Description: Description: Description: Description: Description: Description: sig2] <https://www.facebook.com/pages/Windy-City-Wire/270745609656461>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120211/7e2fb087/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 7675 bytes
Desc: image001.gif
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120211/7e2fb087/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1494 bytes
Desc: image002.gif
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120211/7e2fb087/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 1470 bytes
Desc: image003.gif
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120211/7e2fb087/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.gif
Type: image/gif
Size: 1506 bytes
Desc: image004.gif
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120211/7e2fb087/attachment-0007.gif>