Hello Panagiotis,

> On May 3, 2019, at 4:50 AM, Panagiotis Malakoudis <malak...@gmail.com> wrote:
> As I mentioned in ticket http://trac.ffmpeg.org/ticket/7876 this is
> not my code, I just adapted it for current git. It is also very old
> code (back from 2012), probably it fitted OK back then. This code
> fixes this specific issue reported in the ticket. If it breaks other
> things, then of course it can't be commited. Still there is a need for
> a fix for the reported issue in the ticket, as it is you can't
> transcode with -copyts above 26,5 hours, it fails after that.

For what it’s worth, this is a pretty difficult problem, and not one exclusive 
to -copyts.  I had to put a bunch of code in the demux to support the TS 
wraparound for use with the decklink output, which supports a 90KHz clock but 
the value is 64-bits, so the output doesn’t expect it to jump back to zero 
after hitting the 33-bit limit.

Also, at least in my case, the existing wraparound code that was there works 
exactly once - even in cases where it worked as expected it would properly 
handle the wraparound after 26.5 hours, but then fail after 53 hours.

The approach I took was to track the PTS values as they approached 2^33, and 
then have a separate wraparound count such that the values coming out of the 
demux keep incrementing past the 33-bit limit.  This works well for the TS 
output case as well, since the output will simply truncate the lower 33-bits 
and it will continue working as it was before.  But, as Michael suggested, it 
almost certainly breaks seeking.  While my use cases don’t rely on seeking 
since I’m doing 24x7 decoding of realtime TS streams, such prevents my patches 
from being accepted upstream as well.

I’ve got no easy answers to this one - having TS streams longer than 26.5 hours 
and expecting seeking to work properly seem like they are not compatible 


Devin Heitmueller - LTN Global Communications
ffmpeg-devel mailing list

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to