GNOME Bugzilla – Bug 606672
MPEG4 ASP file captured from Axis 213 PTZ IP Camera stops decoding after 1:40 m:s when the captured video is actually ~5:00 m:s.
Last modified: 2017-07-17 18:29:22 UTC
See https://core.fluendo.com/gstreamer/trac/ticket/234 for specifics. The Fluendo support engineers told me to file a bug report against GStreamer since the defective component appeared to be mpeg4videoparser. The links to the files indicated in the Fluendo problem report to duplicate the error condition are still valid.
MPlayer (ffmpeg) and VLC (ffmpeg) play this streams correctly.
Actually ffmpeg does not play them correctly, it is the Elecard MPEG 4 player that plays them correctly.
mpeg4videoparse does not seem to parse the timestamps and ffmpeg just interpollates timestamps using a framerate of 100/1.
Wim: Thanks for looking into this. The longer of the two MPEG4 ASP captures from the Axis 213 PTZ Camera seems to be exhibiting this problem according to Axis tech support... 4.35.1:C03 Corrected a bug which could result in two MPEG-4 frames having the same timestamp. ...which is fixed by this firmware release... http://www.axis.com/ftp/pub_soft/cam_srv/cam_213/service_release/4_35_1/ GStreamer does not seem to have a problem with MPEG4 ASP streams delivered by the Axis 213 PTZ Camera after the firmware update. The longer capture file that I provided was captured from this camera. However, the other file was captured from a different camera (webcam utilizing ffmpeg MPEG4 ASP encoder) and it still causes problems for GStreamer. We use GStreamer + Fluendo + Totem in our mediaports, so if you do not have time to pursue the ffmpeg MPEG4 ASP encoder stream problem then it is O.K. I don't want to needlessly waste your time. ;-) Best Regards, Rob Krakora
If some streams work then it's likely because of luck. If the timestamp increment matches the framerate, things work fine. The real problem here is that the timestamps of the stream are currently ignored, so that needs fixing.
Wim: O.K. If you need any more test streams please let me know. I have also notice that playbin2 does not automatically place mpeg4videoparse in the pipeline when I try to make use of it to play an MPEG4 ASP file/stream. I have to explicitly build the pipeline and include it in order to be able to have the MPEG4 ASP file/stream decoded by the Fluendo or ffmpeg codec. Best Regards, Rob Krakora
making playbin2 plug the right parser is not too hard (we need to add the parsed=false on the typefind caps and parsed=true on the ffmpeg decoder, or plug a parser in ffmpeg). It might be tricky to do that in a way so that things don't break.
Wim: If you need some help, I am glad to be of service. I can take a look at the timestamp problem. I love GStreamer by the way... Best Regards, Rob Krakora
Wim: I am using the Fluendo MPEG4 ASP codec. Would this not mean that their codec would need the modification so that the proper parser was placed in the pipeline (i.e. mpeg4videoparse). Best Regards, Rob krakora
This is a raw MPEG-4 program stream with a time_increment_resolution of 100, and no fixed frame rate. Instead, it has internal "timestamps" in units of the time_increment_resolution. One bug related to this report was that mpeg4videoparse read the time_increment_resolution of 100 and put framerate=100/1 in the caps, ignoring the fixed_vop_rate=false flag. This was fixed in f33344ab0c. Another bug is that ffdec_mpeg4 apparently does the same thing, and/or doesn't listen to the internal time increments, and timestamps buffers at a framerate of 100/1. I don't have the Fluendo decoder, so I can't comment. The Entropy Wave decoder gets time timestamps correct, but gets the duration wrong, with or without the fixed mpeg4videoparse. However, the broken mpeg4videoparse breaks ewmpeg4dec, too. (Yet another reason why I dislike parser elements. Broken parsers break working decoders.)
Does anyone still have the file linked to in the TRAC bug?
Robert, ping
(In reply to comment #13) > Robert, ping Been a while on this. I first entered this bug in TRAC? Since this bug was filed, Fluendo has done some work to incorperate parsing in to their decoder plugins. In fact, I am using the hardware accelerated video plugins for NVIDIA and ATI now (past two years). I believe that the AXIS camera is working well with them in GStreamer 0.10. I have not tested on GStreamer 1.0 yet. I am still doing regression testing on GStreamer 1.0 + Fluendo GStreamer 1.0 Codecs with webcams, security cameras and A/V streams that work well with GStreamer 0.10 + Fluendo GStreamer 0.10 Codecs. Right now, I am stuck on an apparent bug with C920 webcam and uvch264src plugin on GStreamer 1.0. I was going to test the Axis cameras next. Maybe I will just file the bug against uvch264src and move on the testing the Axis cameras.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!