[FFmpeg-trac] #2224(avformat:closed): HLS output using b-frames has crazy initial timestamps
FFmpeg
trac at avcodec.org
Thu Jul 11 01:08:01 CEST 2013
#2224: HLS output using b-frames has crazy initial timestamps
-------------------------------------+-------------------------------------
Reporter: nealzebub | Owner:
Type: enhancement | Status: closed
Priority: normal | Component: avformat
Version: unspecified | Resolution: fixed
Keywords: libx264 | Blocked By:
mpegts hls segment | Reproduced by developer: 0
Blocking: |
Analyzed by developer: 1 |
-------------------------------------+-------------------------------------
Changes (by saste):
* status: new => closed
* type: defect => enhancement
* component: undetermined => avformat
* keywords: libx264 mpegts hls => libx264 mpegts hls segment
* analyzed: 0 => 1
* resolution: => fixed
Comment:
Replying to [comment:8 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 commit
19ea08a11a8ea31797b509bf66a06c2f9e463d60
Should be addressed in:
{{{
Author: Stefano Sabatini <stefasab at gmail.com>
Date: Fri Jul 5 14:28:38 2013 +0200
lavf/segment: add initial_offset option
Should address trac ticket #2224.
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."
}}}
This requires the explicit use of the -initial_offset option, this can't
be made the default since segment is a generic segment, and adding by
default an arbitrary offset seems wrong.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2224#comment:9>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list