GNOME Bugzilla – Bug 771138
mxf: buffer pts aren't used
Last modified: 2018-11-03 13:55:16 UTC
Noticed when generating images with imperfect PTS, that when they get into the mxf stream with perfect PTS derived from the frame rate. Expected result: original PTS are stored in the MXF stream. Illustration: following generates a stream of ~ 3 fps declared as 30 fps, in mp4 and mxf. The mysrc element is a quick & dirty element that takes stuff from stdin and sends it with arbitrary caps (based off videotestsrc). while true; do dd if=/dev/zero bs=3145728 count=1; sleep 0.3; done | gst-launch-1.0 --verbose --no-fault mysrc ! video/x-raw,format=I420,width=2048,height=1024,framerate=30/1 ! identity silent=0 ! vaapih264enc ! h264parse ! mp4mux fragment-duration=1000 trak-timescale=100000 ! filesink location=pouet.mp4 while true; do dd if=/dev/zero bs=3145728 count=1; sleep 0.3; done | gst-launch-1.0 --verbose --no-fault mysrc ! video/x-raw,format=I420,width=2048,height=1024,framerate=30/1 ! identity silent=0 ! vaapih264enc ! h264parse ! mxfmux ! filesink location=pouet.mxf The stream is then checked: gst-launch-1.0 --verbose --no-fault filesrc location=pouet.mp4 ! qtdemux ! identity silent=0 ! fakesink gst-launch-1.0 --verbose --no-fault filesrc location=pouet.mxf ! mxfdemux ! identity silent=0 ! fakesink mp4 says: /GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (240 bytes, dts: 0:00:00.018040000, pts: 0:00:00.018040000, duration: 0:00:00.309880000, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fb5880033a0 /GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (239 bytes, dts: 0:00:00.327920000, pts: 0:00:00.327920000, duration: 0:00:00.309060000, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fb588003180 mxf says: /GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (240 bytes, dts: 0:00:00.033333333, pts: 0:00:00.033333333, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 00004000 tag-memory ) 0x7f379c003340 /GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (239 bytes, dts: 0:00:00.066666666, pts: 0:00:00.066666666, duration: 0:00:00.033333334, offset: -1, offset_end: -1, flags: 00004000 tag-memory ) 0x7f379c003560 I didn't check the file to see if the mux or demux is the issue.
That's correct, but also somewhat a limitation of the MXF format. It assumes a regular frame rate (edit unit rate). You probably want to use another container format, or convert your stream to a constant framerate (with videorate) first.
We could however store PTSs inside MXF, and probably should do that. But the above still applies then.
Thank you Sebastian, Sorry, I didn't know that MXF had this limitation. I just grabbed a container that could store RGBA raw buffers, and observed this curious limitation. You can close the issue if desired, or elaborate on how you suggest to store PTS (special KLV track? is there a de-facto standard way to do it?). Regards,
There's a way to associate timestamps with edit units via the index table segments, and also via system items at the beginning of the generic container edit units. Nonetheless this doesn't get rid of the requirement that the framerate is ~constant. You could use Matroska, AVI or MOV as a container probably.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/424.