[FFmpeg-devel] Timestamp wrap issue with concatenating multiple assets to form a MPEG transport stream

[Callum Wilson]

Hi all,

Apologies if this is mailed to the wrong mailing list. I was considering libav-user but ffmpeg-devel seemed a better fit. If you have any suggestions on a better place to find help I would be grateful for the advice.

Some background:
I’m currently using ffmpeg to generate a MPEG transport stream from a playlist (over 26.5hrs worth) of video assets. With some assets this works fine, however, with others it does not. I’m having an issue with timestamp wrapping. Close to the max timestamp (~26.5hrs) the wrapping kicks in and gets it wrong creating negative timestamps in the output which then gets changed to last_timestamp + 1.

I’m using 3.2.4 (with some additions), however I have tested on 3.3.5 and issue still occurs.

I’m not asking anyone to fix this, however I will be raising a bug, but I would like some help with understanding some aspects of ffmpeg so that I can fix it myself.

Currently, I’m having a little trouble understanding the wrapping mechanism which is used.

As I understand it the concat demuxer (libavformat/concatdec.c) parses packets from the files. During parsing it calls update_wrap_reference() (libavformat/utils.c:726) which works out the wrapping point of the timestamps. This function only changes anything on the first call for each file as thereafter st->pts_wrap_reference != AV_NOPTS_VALUE which causes it to return.

This is where I get confused, update_wrap_reference() works out the wrapping reference to be 60s before the dts of the current packet (which is the first packet and in this asset the timestamps start at 0). This is calculated as -5400000.  Why do we do this? Why not work out the wrapping point exactly?

I am skipping the line “ref &= (1LL << st->pts_wrap_bits)-1;” as in this use case ref is always 0 and therefore stays 0.

When observing the wrapping of the packet at the fail point, I see that the pts_wrap_reference for the stream is no longer -5400000 but 60s before the max possible timestamp and the wrapping behaviour is set to subtract the offset. This results in a negative timestamp which, according to the docs (here<https://ffmpeg.org/doxygen/trunk/structAVStream.html#aeb3eeb80578432b07b73cb5951c07c5c>), is fine. However, this wrapped timestamp is never fixed to be a non-negative number at any subsequent point.

As well as the above, when I run gdb with ffmpeg and place a breakpoint in update_wrap_reference, the last call before the wrap issue does not set the wrap reference to the value it is in wrap_timestamp. I can see no other point in the code which sets the streams pts_wrap_reference (apart from copying other streams) so I’m not sure when this is getting set. Am I missing something?

Thanks,
Callum






Callum Wilson | Graduate Software Engineer | Exterity Ltd
tel: +44(0) 1383 828 250 | fax: +44 1383 824905
e: Callum.Wilson at exterity.com | w: www.exterity.com

[cid:image1e7c93.PNG at d5a73fe7.4c9cbf9f]<www.exterity.com>
[ISO9001]<http://www.exterity.com/iso9001>      [LinkedIn] <http://www.linkedin.com/company/exterity>   [Twitter] <http://www.twitter.com/exterity>     [YouTube] <http://www.youtube.com/user/exterityiptv>

Exterity is a leading provider of IP Video and Digital Signage solutions that helps organizations to harness the power of video to communicate, educate and entertain. Our end-to-end solutions enable you to take TV and video content directly from any source and manage its delivery, live or on demand, to any connected device via your existing network. For more information or to schedule a product demonstration, contact Exterity on +44(0)1383 828 250 or visit www.exterity.com

Legal Notice
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.

Exterity Limited is registered in Scotland under No. 225313 with its registered office at St Davids House, St Davids Drive, Dalgety Bay, KY11 9NB

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1e7c93.PNG
Type: image/png
Size: 19003 bytes
Desc: image1e7c93.PNG
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171204/c72c6863/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image20bc27.JPG
Type: image/jpeg
Size: 11399 bytes
Desc: image20bc27.JPG
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171204/c72c6863/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image2c58fc.PNG
Type: image/png
Size: 1501 bytes
Desc: image2c58fc.PNG
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171204/c72c6863/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagea9affa.PNG
Type: image/png
Size: 1598 bytes
Desc: imagea9affa.PNG
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171204/c72c6863/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image136314.PNG
Type: image/png
Size: 1188 bytes
Desc: image136314.PNG
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171204/c72c6863/attachment-0003.png>