[Libav-user] av_read_frame returns packets with AV_NOPTS_VALUE

[Paul B Mahol]

On 5/12/18, Yurii Monakov <monakov.y at gmail.com> wrote:
> Hi, FFmpeg users!
>
> I'm developing a stream recording application. So it takes arbitrary stream
> and records it in chunks of approx 20 minutes, splitting input stream at
> key frame boundaries.
>
> I'm using this stream for testing purposes (recording only video stream):
> http://bitmovin-a.akamaihd.net/content/playhouse-vr/m3u8s/105560.m3u8
> It initializes properly and first packets, including first key frame, are
> good. I save them with output context without any problem.
>
> But when next key frames arrive their PTS/DTS are set to AV_NOPTS_VALUE.
> av_interleaved_write_frame function expectedly complains about it and
> produces garbled videos. This is strange, because av_read_frame function
> states that
>
>  * pkt->pts, pkt->dts and pkt->duration are always set to correct
>  * values in AVStream.time_base units (and guessed if the format cannot
>  * provide them).
>
> I've tried to open this stream by ffmpeg with '-fdebug t' option and it
> also shows key frame packets  without PTS:
>
> $ ffmpeg -fdebug ts -i
> http://bitmovin-a.akamaihd.net/content/playhouse-vr/m3u8s/105560.m3u8 -an
> -f null
> ...
> [hls,applehttp @ 0xe004e0] ff_read_packet stream=1, pts=NOPTS, dts=NOPTS,
> size=464722, duration=3003, flags=1
> [hls,applehttp @ 0xe004e0] read_frame_internal stream=1, pts=NOPTS,
> dts=NOPTS, size=464722, duration=3003, flags=1
> [hls,applehttp @ 0xe004e0] ff_read_packet stream=1, pts=1099098,
> dts=1084083, size=223452, duration=3003, flags=0
> [hls,applehttp @ 0xe004e0] read_frame_internal stream=1, pts=1099098,
> dts=1084083, size=223452, duration=3003, flags=0
> ...
> As you can see, PTS/DTS are missing only in key frame (flags=1).
>
> Remuxing this stream to mp4 with ffmpeg gives no artifacts on the video and
> no errors are shown in the output. So it fixes PTS/DTS somehow to maintain
> their sequence.
>
> Now I simply keep track of previous packet PTS/DTS values and alter them
> according to duration. But this approach can handle only PTS/DTS loss only
> in presence of duration (which is not reliable also).
>
> So, what is the best way to fix input stream PTS/DTS returned from
> av_read_frame?
>
> Yurii
>

Looks like the bug that should be reported.