[FFmpeg-trac] #2224(undetermined:new): HLS output using b-frames has crazy initial timestamps
FFmpeg
trac at avcodec.org
Mon Apr 1 17:36:06 CEST 2013
#2224: HLS output using b-frames has crazy initial timestamps
-------------------------------------+-------------------------------------
Reporter: nealzebub | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: unspecified | undetermined
Keywords: libx264 | Resolution:
mpegts hls | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by nealzebub):
I do not know if Wowza output produces Warnings in Validator, but I
suspect not, since that is why they implemented the 10-second timestamp
offset in version 3.5+. I also suspect that they offset by 10 seconds to
avoid the following two mediastreamvalidator issues reported.
1. Error - due to a negative timestamps, which is interpreted as a really
high value. Validator reports decreasing timestamps. If the the first
PTS is zero, then the first DTS is probably less than zero.
2. Warning - Validator, for some reason, is unable to read frames with a
timestamp of zero.
To be clear, a stream produced by FFmpeg using -avoid_negative_ts 1 can
produce #2, the warning.
Looking at the Wowza forums, it reads that Wowza was resistant to setting
the offset in February 2012. Then, in November 2012, the builds have the
offset by default.
I re-quote the Wowza thread from Sept 2012:
"
Below is the comment from one of the staff at Apple @baleighsdad:
However, I'm not sure where Wowza got their information; I don't recommend
using a 0 PTS in the first segment, and have said many times that this
isn't a good idea. Our own tools using a starting PTS of the equivalent of
10 seconds, to avoid wrap."
"
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2224#comment:8>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list