4

I am getting the following warning message when executing ffmpeg:

[mp4 @ 00000000025c00a0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 00000000025c00a0] pts has no value

The message appears when converting H264 elementary stream into mp4 video file.

I am using ffmpeg version: ffmpeg-3.3.2-win64

I tried executing the following code, to check if it's a problem in my H264 stream:

ffmpeg -f lavfi -i testsrc -t 3 -r 10 -pix_fmt yuv420p -c:v libx264 test.264
ffmpeg -r 10 -i test.264 -vcodec copy test.mp4

The code creates H264 synthetic video stream using ffmpeg, and then converts the stream into mp4.

Since the stream is created by ffmpeg, there is no reason for it not to contain required Timestamps.

Is it a bug in ffmpeg?
Is there some king of flag I missed when creating the synthetic H264 stream?
Does H264 elementary supposed to contain Timestamps?

1 Answer 1

4

Since the stream is created by ffmpeg, there is no reason for it not to contain required Timestamps.

Except that raw H.264 bitstreams do not have timestamps.

This change was introduced a while ago, and according to what I see, it simply doesn't consider the use case of muxing elementary streams that cannot have timestamps.

This works:

MP4Box -add test.264 -fps 10 test-out.mp4

My thinking was that specifying input framerate (-r ... -i ...) would be sufficient to make that error disappear, since it is supposed to generate timestamps, but apparently it does not help in this case. It might be a bug, but I may be missing something more obscure.

An alternative was suggested by Eugen Rieck in a comment below:

ffmpeg -i test.264 -c copy test.avi
ffmpeg -i test.avi -c copy test.mp4
7
  • apparently it does not help in this case --> looks related to trac.ffmpeg.org/ticket/502#comment:21
    – Gyan
    Jul 6, 2017 at 15:41
  • 1
    @slhck Elementary streams cannot have timestamps, so I can safely ignore the warning message. Thank you for your answer.
    – Rotem
    Jul 6, 2017 at 17:17
  • 1
    @Rotem Sure! It's just that it should work with the -r parameter as an input option. Perhaps I'll file another bug report.
    – slhck
    Jul 7, 2017 at 9:22
  • 1
    Are there any updates on this or the bug report? I just tried setting -r in a current version of ffmpeg and it still gives the same error for H.264 elementary streams. Aug 27, 2018 at 8:07
  • 1
    I know this is an old question but since it is asked so often: An unlikely improvement in FFmpeg has given a workaround: Raw h.264 to AVI works fine and has all the timestamp magic, AVI to MP4 works fine as well. So if you are comfortable with 2 muxes, you are covered. This also avoids MP4Box's quirks (such as droping big parts of a raw bitsream as "not referenced") Nov 5, 2018 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.