On Fri, Aug 31, 2018 at 7:28 AM Rodger Combs <rodger.co...@gmail.com> wrote:
>
> We previously set pos to several bytes before the actual packet sync byte,
> which meant that seeking to pos relied on resync working, which can fail
> if there are 0x47 bytes in the additional data.
>
> The resync issue should probably also be fixed separately.
> ---
> libavformat/mpegts.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index a5cb17ac16..881708b42d 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2581,10 +2581,9 @@ static int handle_packet(MpegTSContext *ts, const
> uint8_t *packet)
>
> } else {
> int ret;
> - // Note: The position here points actually behind the current packet.
This comment still applies, which is why we substract the packet size
from the position. Probably shouldn't remove it.
> if (tss->type == MPEGTS_PES) {
> if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
> - pos - ts->raw_packet_size))
> < 0)
> + pos - TS_PACKET_SIZE)) < 0)
> return ret;
> }
> }
For the record, my code currently relies on AVPacket.pos pointing to
the actual start of BDAV packets from Blu-ray m2ts files so the
position lines up with the Blu-ray playlist metadata, which also has
positions for seamless clip changes etc.
I don't know how all the other cases work, but at least for BDAV the
current value is correct.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
