Timecode in the h264 encoder?

[jwatte]

I'm recording on a Raspberry Pi 2 using a cut-down version of RaspiVid, and playing back on a Windows machine after transferring over the network (using scp when done -- not streaming.)

When I play back a h264 file that I have created on Raspberry Pi (using a Pi2, with Jesse) on VLC on Windows (latest version) the VLC time bar shows 00:00 on both the left and right sides. I can't get it to show how far into the movie it is currently displaying.
Is there something that should be in the H264 file to tell players like VLC where in time they are? And, if so, what can I do at the MMAL API level to insert such information?

Btw: These recordings typically aren't cleanly terminated; the signal to stop is "power was lost."

[jamesh]

H264 bitstreams do not contain frame rate or timecode information. That stuff is added by putting the bitstream in a 'container' such as MP4 or MKV. You can use avconv to do this. Google will find out the mechanism.

[6by9]

Better to ask these questions in the Camera subforum - it's been answered there multiple times.

Raspivid is saving an H264 elementary stream, and those have no timestamps as timestamps are generally stored in a container (MP4. AVI, MOV, MKV, etc) instead.
Use avconv or equivalent to multiplex the raw stream into a container. Something like:

Code: Select all

avconv -framerate 30-i my_video.h264 -c:v copy my_video2.mp4

(Just beaten to it by James!)

[jamesh]

NINJA'D!!!!

[drgeoff]

H264 bitstreams do not contain frame rate or timecode information..

Not completely true.

They can contain frame rate info. If timing_info_present_flag is 1.

Eg.

Code: Select all

timing_info_present_flag : 1
  num_units_in_tick : 100
  time_scale : 5994
  fixed_frame_rate_flag : 1

[jwatte]

Thanks for the pointers!

I'll go spelunking and see if it's possible to write the timecode/format while writing the raw stream, or whether I need to do this offline after the fact.

[jamesh]

Thanks for the pointers!

I'll go spelunking and see if it's possible to write the timecode/format while writing the raw stream, or whether I need to do this offline after the fact.

Since I've never heard of the above, I think it's unlikely that it is supported. Will double check with one of the guys who worked on the encoder, he's an H264 expert. If he comes in to work!

[6by9]

H264 bitstreams do not contain frame rate or timecode information..

Not completely true.

They can contain frame rate info. If timing_info_present_flag is 1.

Eg.

Code: Select all

timing_info_present_flag : 1
  num_units_in_tick : 100
  time_scale : 5994
  fixed_frame_rate_flag : 1

https://github.com/raspberrypi/firmware/issues/245
MMAL_PARAMETER_VIDEO_ENCODE_SPS_TIMING / OMX_IndexParamBrcmVideoAVCSPSTimingEnable exist and should then include the timing info in the headers. It's not enabled by default as I don't know the full implications of it, and there are too many Pi's out there to potentially break with a change like that.

NB That is only a nominal frame rate, not timestamps.

Will double check with one of the guys who worked on the encoder, he's an H264 expert.

(Now trying to remember which of the codec guys is at your place. I lost my tame codec expert a good while back, and the Pi Towers one isn't around.)

[jwatte]

Meanwhile, I've spelunked a little more, and the libavformat library comes with a sample program that reads a H.264 file in and writes a MP4 file out.
That program can be hacked-at and bashed into the RaspiVid-mini I'm using until it uses that library to create and write the file, rather than just fwrite().
It's one more copy step of data, but the data rate is kind-of low (the point of compression!) so that'll probably be OK.

The one possible restriction would be that the buffers received from the codec need to be "full frames" or something akin to it.
Is that what I receive from the codec? What is each buffer? Does it ever bundle multiple frames into a single buffer?

[6by9]

The one possible restriction would be that the buffers received from the codec need to be "full frames" or something akin to it.
Is that what I receive from the codec? What is each buffer? Does it ever bundle multiple frames into a single buffer?

You'll never get more than one frame encoded into one buffer.

There are situations where a single frame could be split into multiple buffers.
One is at when the codec wraps around the internal FIFO (2MB IIRC), but can be avoided with MMAL_PARAMETER_MINIMISE_FRAGMENTATION.
The second is if the buffer isn't large enough to store an entire frame. So I can predict the next question of "how big then". There isn't a simple answer. The codec sets a QP value for the frame based on past history, and if that is way off due to a scene change happening at that point, then the output frame is big. Based on previous experience, allow 768kB for 1080P, 384kB for <=720P. (This has been discussed previously on the Camera subforum).

[jwatte]

That's good information, too!

This has been discussed previously on the Camera subforum

I find that when I try to search the forum, I get a whole lot of talk about how to use motion/raspicam/whatever built-in tools, and very little about the underlying code and API to access it.

In the best of worlds, there would be an API section about MMAL with a "concepts" discussion, a "howto" section, and a reference for each of the functions and each of the constants/parameters.

And ponies would have wings