After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796540 - x264enc destroying pts
x264enc destroying pts
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
1.14.1
Other All
: Normal major
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-06-08 08:29 UTC by Andy S
Modified: 2018-06-08 11:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andy S 2018-06-08 08:29:57 UTC
If I run 
gst-launch-1.0 videotestsrc is-live=true do-timestamp=true num-buffers=1 ! 
video/x-raw ! identity silent=false name=first ! x264enc ! video/x-h264 ! 
identity name=second silent=false !  fakesink -v 

then the dts and pts are changed and reset by the x264enc. I don't think 
this is correct as I would have thought that the pts should stay the same. 

The output of identity "first" is: 
******* (first:sink) (115200 bytes, dts: 0:00:00.011741158, pts: 
0:00:00.005870579, duration: 0:00:00.033333333 

The output of identity "second" which is post x264enc is: 
******* (second:sink) (5795 bytes, dts: 1000:00:00.000000000, pts: 
1000:00:00.000000000, duration: 0:00:00.033333333 

I've looked at other encoders and they keep the pts as you would expect.
Comment 1 Tim-Philipp Müller 2018-06-08 09:36:37 UTC
pts/dts values don't have any meaning in themselves, they only make sense in connection with the GstSegment that goes with them. x264enc will also adjust the GstSegment accordingly to make sure the frames don't end up shifted despite the timestamp offset.

This is needed to handle negative dts properly, see bug #731351.

So this is intentional.
Comment 2 Andy S 2018-06-08 10:38:26 UTC
Thanks Tim - I didn't realise that. So how do I sync 2 x264enc streams from different machines? If one is encoded with zerolatency and the other not, they don't sync correctly - they're around a second out.
Comment 4 Andy S 2018-06-08 11:01:06 UTC
Thanks again Tim. But if both machines have synced ntp clocks, but start at different absolute times, using rtpbin to send to a central machine, should not the remote rtpbin automatically collect and reassemble using rtcp-sync-send-time=false. 

I realise this is probably not the place to have this discussion but I've had no response on the gstreamer-devel mails.
Comment 5 Tim-Philipp Müller 2018-06-08 11:13:43 UTC
Indeed, this is not really the place for that, sorry :)

You might find some useful info in this talk:

https://gstconf.ubicast.tv/videos/synchronised-multi-room-media-playback-and-distributed-live-media-processing-and-mixing-with-gstreamer/