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.wil...@exterity.com | w: www.exterity.com

[cid:image1e7c93.PNG@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
______________________________________________________________________
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to