[Libav-user] pts/dts validation

[Jake Eastwood]

I have been coding my 'ffmpeg streaming project' for more than two years
now, but still don't have full idea what changes happen with pts/dts. Every
realization has edge cases when it won't work.

I do sometimes remuxing, sometimes transcoding. And 'pts' for me is very
significant:
1) It represents the real time of stream working, like 2d3h35m24s. It
impacts on my archive start and end boundaries. Which gives me subproblems:
1-1) packets show me that there is (start_pts_1 -> pts_end_1) working time,
but frames give different numbers (start_pts_1 -> pts_end_2). So only start
time matches. Maybe a few frame duration less (or more?), but maybe it will
accumulate to bigger divergence.
2) I have some events happening during streaming. And I should be able to
find a frame with specific 'pts' in my archive. Problems:
2-1) I have a paradox piece of code. I get pts of AVFrame and search for in
the remuxing base archive, which boundaries are found on pts of source
packets. But archive is not a single blob, but a bunch of small parts, so I
believe there could be cases when I miss the right part.

For now I have a big misunderstanding which broke my logic:
I start decoding not from the start, only when I need it. I want to check
decoder frames right after I get them, to be sure I can use it further at
muxer. And sometimes the decoder starts to return frames with 'pts' <
'pkt_dts'. Why and what should I do with it?
Example:
source pts/dts: 255600/255600 decoded pts/dts 252000 255600 type: P
source pts/dts: 259200/259200 decoded pts/dts 255600 259200 type: P
source pts/dts: 262800/262800 decoded pts/dts 259200 262800 type: P
source pts/dts: 266400/266400 decoded pts/dts 262800 266400 type: P

пн, 4 июл. 2022 г. в 13:26, Strahinja Radman <dr.strashni at gmail.com>:

>
>
> On 4. 7. 2022., at 08:04, Jake Eastwood <cheloveck2.0 at gmail.com> wrote:
>
> How should I validate pts/dts after demuxing and then after decoding?
>
> For me it is significant to have valid pts all the time for days and
> possibly weeks of continuous streaming.
>
> After demuxing I check:
> 1) dts <= pts
> 2) prev_packet_dts < next_packet_pts
> 3) I also discard packets with AV_NOPTS_VALUE and wait for packets with
> proper pts, because I don't know video duration at this case.
> * pts of packets can be not increasing because of I-P-B frames
> Is it all right?
>
> What about decoded AVFrames?
> 1) Should 'pts' be increasing all the time?
> 2) Why at some point 'pts' could lag behind 'dts'?
> 3) Why pict_type is a parameter of AVFrame? Should be at AVPacket,
> because AVPacket is a compressed frame, not the opposite?
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/libav-user
>
> To unsubscribe, visit link above, or email
> libav-user-request at ffmpeg.org with subject "unsubscribe”.
>
>
>
> Hello Jake,
>
> PTS is a time when frame is presented to you, while DTS is a time when
> AVPacket is decoded into a frame so other AVFrames (P/B) can possibly be
> reconstructed using information from that AVFrame. PTS cannot be less then
> DTS, but it can be the same. Packets cannot be presented before they are
> decoded. Its possible that DTS has a negative value, which makes no
> difference in decoding.
>
> But its not clear, at least for me, what exactly are you hoping to achieve
> by validating if they are correct or not, is there a specific player issue
> that you are experiencing? Players usually handle invalid PTS information
> by creating them using framerate of the video. Attempting to do this by
> yourself can be very tricky especially when you do it for days or months.
> For example it can introduce audio sync issues.
>
> Kind regards,
> Strahinja
>
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/libav-user
>
> To unsubscribe, visit link above, or email
> libav-user-request at ffmpeg.org with subject "unsubscribe".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20220704/f14dac2a/attachment.htm>