Le samedi 23 septembre 2017 à 17:49 +0200, Mailing List SVR a écrit :
> Hi,
>
> I need to handle an rtmp stream from a wowza server, it outputs cts
> like
> this:
>
> 1) 0
> 2) -4719
> 3) -4799
> 4) -4759
>
> and so on until the cts return positive,
>
> this obvioulsy cause big trouble to flvdemux that outputs something
> like
> this:
>
> gstflvdemux.c:1638:gst_flv_demux_parse_tag_video:<flvdemux0> dts 0
> pts
> 4294962577 cts -4719
>
> I'm able to make a patch but I need some directions, we can:
>
> 1) add a fixed offset to cts to ensure that generated pts are always
> positive
> 2) we can just reset cts to 0 if negative since this happens only
> for
> some buffers at the beginning of the stream
> 3) any other ideas?
Thanks for spotting, this integer overflow definitely need fixing, it
will stall the pipeline for good.
As you shown in the bug report (bug 787795), GStreamer and FFPEG agree
that a negtive PTS (unlike DTS) are completely invalid, so whatever we
do is a workaround.
The best workaround will be the one that maintains audio/video
synchronization over time, but that we can't really guess. According to
FLV spec:
cts = PTS - DTS
Or "the composition offset from the decoding time". A negative CTS
would mean the PTS is before DTS. As this is just impossible, I think I
would opt for 2), since using a fixed offset forward would result in
PTS < DTS, which will eventually cause issues elsewhere. That being
said, I would give a closer look at the result, specially the resulting
combination of DTS/PTS to validate the "fix" result in a valid stream.
For sure, it won't be worst then what we have now. Another option is to
leave the PTS as blank (none), but that can cause other issues of
course.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
