This topic is actual for me also.
My application is capturing a live MPEG transport stream and saves its parts
to files.
It saves a user-defined program, consisting of 1 or 2 elementary streams,
according to the user-defined schedule.
My recent posts in this list are dedicated to this problem.


Luca Abeni wrote:
> 
> Michel Bardiaux wrote:
> [...]
>> On decoding, av_read_frame gives the timestamps as found, hence every 26
>> hours, the time apparently recycles (but contrary to Monopoly I don't get
>> €50 each time :-)).
>> 
>> So, apparently the burden of compensating for the rollover is left to the
>> user.
> 
> I am not sure if I fully understand the problem, here, but in my
> understanding
> there is not much to compensate: if pts_wrap_bits is 33, then the MPEG
> demuxer
> generates timestamps on 33 bits, and if you consider only 33 bits there
> should
> be no problem.
> 

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       
pkt.pts=18010,      pkt.dts=7210       
pkt.pts=10810,         pkt.dts=10810      
pkt.pts=14410,      pkt.dts=14410      
pkt.pts=28810,      pkt.dts=18010    
pkt.pts=21610,      pkt.dts=21610 
pkt.pts=25210,      pkt.dts=25210
pkt.pts=39610,      pkt.dts=28810

There are several elementary streams in the transport stream, these
timestamps are from the same elementary PID, other PIDs are discarded.

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.


-- 
View this message in context: 
http://www.nabble.com/How-to-handle-33-bits-rollover-in-MPEG--tp18282365p18314578.html
Sent from the libav-users mailing list archive at Nabble.com.

_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user

Reply via email to