GNOME Bugzilla – Bug 688357
mpegtsmux : Incorrect PTS and missing DTS using x264enc
Last modified: 2012-11-18 22:15:56 UTC
Created attachment 229018 [details] Frames timing I am using x264 for a bit now and I have noticed that inside the stream the PTS timings are not correct for B and P frames. When you take a closer look at the stream, you notice that the B-Frames and P-Frames times are following each other in the PTS. But it shouldn't. In fact the B-Frames times should be slightly before its' previous P-Frame time. Also, the DTS are missing in every frames for a stream encoded by x264enc. (Enclosed is a screenshot of the B and P-frames PTS times in a stream encoded by x264enc v1.0.1.) By the way the rule for a DTS is not exactly the same than for a PTS. Because B and P frames timing are supposed to be following. Also, this problem result of a non smooth video when you try to run it on any video player, because it's dropping b-frames with incorrect timing value. However, when you deactivate the b-frames, it becomes smooth. I tried to run x264enc version 0.10.19 and the PTS is correct, but the DTS was still not present. Regards.
What you are analyzing is the result of x264enc ! mpegtsmux or so, right? I'm wondering if it's the encoder that doesn't signal pts/dts correctly on buffers, or if it's the TS muxer messing those up and/or not putting them in the stream properly (I think there are/were some bugs related to this for the TS muxer).
Bug #687806 might be relevant/related.
Yes what I have analyzed at first was the result of x264enc ! h264parse ! mpegtsmux. After your answer, I tried 3 things: - Analyze the data directly after x264enc (or at least try), - Try another mpegts muxer, - Try an AVI muxer. When I try to look with an hex editor to the content of the file that x264enc output, I can't find or recognize any startcode like 00 00 01 (PES, PTS or DTS). When I try avimux_mpegts (even if he is not recommanded), he display this error: libav :0:: Application provided invalid, non monotonically increasing dts to muxer in stream 0: 861242 >= 858239 libav :0:: H.264 bitstream malformed, no startcode found, use -vbsf h264_mp4toannexb When I try the AVI muxer (avimux) and I play the file in VLC, it's smooth. But I don't know how AVI works in comparaison with TS streams. Usually it's the encoder job to add the timestamps. But in this case I am not sure if it's x264enc who forgets them or if it's mpegtsmux who is messing them. Regards.
Couple of comments: - best muxer here is probably (hopefully!) qtmux/mp4mux. It should handle dts/pts well. - avimux is not really suitable for H.264 and likely won't work well (but probably can be made to work better, just not a good test case) - there's no need for an h264parse element after x264enc. It should (hopefully) work without. - x264enc may output either AVC or byte-stream format. It should negotiate the right stream format automatically with the downstream element/muxer. If you just do x264enc ! filesink, it looks like it will output AVC, which has no such start codes. You can force bystream by doing x264enc ! video/x-h264,stream-format=byte-stream ! filesink ... - check the DTS/PTS on the buffers x264enc outputs, see e.g.: .. x264enc ! fakesink -v - avmux* demuxers are not in good shape, and I would be surprised if they handled dts/pts at all yet. It does not look like they use the dts on the buffers at first glance.
Sorry, that should have read: Check the DTS/PTS on buffers like this: .. x264enc ! fakesink silent=false -v
Thank you for your answer. I thus tried to check the DTS/PTS using "fakesink" and they are in the stream and correct. It means that the problem comes from "mpegtsmux" element by deduction. Do you agree on that ? By the way I am using h264parse to connect x264enc to mpegtsmux (since Gstreamer 1.0 only). Otherwise I have this error displayed during the whole process: (gst-launch-1.0:13722): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `mini_object->refcount > 0' failed Regards.
That's an issue that's been fixed in 1.0.2, see bug #686327 . Yes, I agree that the implication is that the problem is with the muxer, moving the bug there then. I think this may be a duplicate of bug #687806 , which should be fixed by the upcoming 1.0.3.
You are right, bug #687806 is exactly my problem. Thank you then, now I know I have to wait for the upcoming version of mpegtsmux.
*** This bug has been marked as a duplicate of bug 687806 ***