negative DTS delays
Duncan Palmer
dpalmer at digisoft.tv
Sun Feb 22 17:25:30 PST 2015
AFAIK, h264 has no notion of CBR. You can achieve something similar by
correctly configuring the encoder.
On 22 February 2015 at 03:49, Nicolas Dufresne <
nicolas.dufresne at collabora.com> wrote:
>
> Le 2015-02-19 21:13, frankw a écrit :
>
>> I think in general I wonder: after such transcoding, is it CBR or VBR
>> transport stream being produced? and in terms of PCR, how valid is it
>> being
>> generated/inserted into the output stream?
>>
> If transcoding (unless you mean transmuxing) it will be VBR or CBR
> depending on how you have configured the encoder.
>
> If you have enabled B-Frame and are using x264enc in 1.4, the PTS/DTS
> delta will always be wrong. The reson is that in 1.4 we offset the DTS
> forward in order to avoid unsupported negative values but we leave the PTS
> untouched. This is very unfortunate behaviour which we are trying to fix in
> current development cycle.
>
> The delta being wrong does not affect Gst (same goes in VLC) as there is
> no synchronization of stream at decoder input. In fact, our decoders
> reorder the frames based on the sequences information found in the
> bitstream. Decoders simply run as fast as possible, and block when
> downstream is full/blocked.
>
> Nicolas
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150223/835825fc/attachment.html>
More information about the gstreamer-devel
mailing list