[Libav-user] pts/dts validation

[Strahinja Radman]

> On 4. 7. 2022., at 10:52, Jake Eastwood <cheloveck2.0 at gmail.com> wrote:
> 
> 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
> 

AVFrame doesnt have DTS information, it can only be shown at a specific time (PTS). So after decoding you dont have DTS information anymore as its not relevant. 

Maybe it would be best if you tried FFmpeg’s way of generating timestamps. Look at the ffmpeg.c code in github. Try to use their logic in order to generate PTS and DTS info. That way you will not be battling with decoder which sometimes out of the blue returns invalid PTS/DTS information. 

One more possible solution would be to save the last good decoded timestamps and fill in the void that decoder is giving you. This has worked for me in the past. You can calculate all of these things before the stream starts. 

Decoder wants to decode from I frame or it wants to start from the beginning of the GOP sequence. 

Kind regards,
Strahinja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20220704/16415d6e/attachment.htm>