Hi Vladimir,
Vladimir Eremeev wrote:
[...]
> Here are the timestamps, which I have received, when my application was
> reading live MPEG TS:
> pkt.pts=8589902202, pkt.dts=8589902202
> pkt.pts=8589905802, pkt.dts=8589905802
> pkt.pts=8589920202, pkt.dts=8589909402
> pkt.pts=8589913002, pkt.dts=8589913002
> pkt.pts=8589916602, pkt.dts=8589916602
> pkt.pts=8589931002, pkt.dts=8589920202
> pkt.pts=8589923802, pkt.dts=8589923802
> pkt.pts=8589927402, pkt.dts=8589927402
> pkt.pts=7210, pkt.dts=-3590
> pkt.pts=10, pkt.dts=10
> pkt.pts=3610, pkt.dts=3610
[...]
So, av_read_frame() is returning timestamps on 33 bits
(if you interpret these timestamps with 33bit math, they
are all ok).
> These timestamps were received from the av_read_frame() function.
> If I leave these timestamps without changes and give them to the
> av_write_frame() function, then, at best, it complains about "non-monotone
> time stamps" and doesn't write any data after 33-bit rollover.
So, it seems that av_write_frame() wants timestamps on 64 bits?
In this case, I agree that there is a discrepancy between
av_read_frame() and av_write_frame(). As I said in the previous
email, I do not know which behaviour is correct (but I agree that
the two behaviours should be consistent).
What I wrote in my previous email is that I do not believe that the
bug (if there is a bug) is in the demuxer... It probably is in
libavformat/utils.c.
I suspect the problem could be in compute_pkt_fields() or truncate_ts().
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
