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 740564 - x264enc: Need to compensate the forward shift done while adressing negative DTS
x264enc: Need to compensate the forward shift done while adressing negative DTS
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-11-22 23:01 UTC by Nicolas Dufresne (ndufresne)
Modified: 2014-11-23 16:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Nicolas Dufresne (ndufresne) 2014-11-22 23:01:21 UTC 
Right now we forward shift the DTS/PTS in present of negative DTS. This will result in video being slightly late. We need to compensate this. I think the way forward is by changing the segment accordingly.
Comment 1 Tim-Philipp Müller 2014-11-23 14:48:42 UTC 
I have just re-opened bug #731351 which introduce that.

I think the issue here is more general than x264enc, and there's bug #740575 for that, so can we close this?
Comment 2 Nicolas Dufresne (ndufresne) 2014-11-23 15:41:56 UTC 
By opening this bug, and closing the other one, I was trying to split things up a little. Trying to fix the entire world of B-Frame all at once has been a failure.

My general opinion is that if we can get 1 encoder to do things right, then we can start thinking of adding APIs forever. This bug was to split the issue. Before 731351, the DTS was basically being shift with different offset on different frame and often DTS would be bigger then PTS. Now the DTS/PTS offset is kept correctly, the offset does not change randomly. The issue is that DTS is made to fit the segment, which may cause a small AV desync. I think opening this bug was the right thing to do, as it's a different issue. If we can propose a fix in x264 and at least 1 of the muxers, I think we will be able to generalize. But before that, generalizing will result in more API errors.
Comment 3 Tim-Philipp Müller 2014-11-23 15:58:13 UTC 
It's not a "small AV desync", and it's a systematic problem.

I re-opened the other one because I think this needs to be reverted.

And IMHO we should not fiddle with this more in x264 until we have general agreement about the right solution forward.
Comment 4 Nicolas Dufresne (ndufresne) 2014-11-23 16:40:15 UTC 
Fine, your call. Note that reverting means that thing will fail rather then work with between 0 to 2 frames of de-synchronization. The patch was along the path of what is being proposed globally. My goal was to validate before generalizing.