0

My issue is the next: I know MediaFormat.KEY_I_FRAME_INTERVAL is the interval in seconds (Integer) where the I-Frame is going to appear.

So if i give the value to 1, and my frame rate is 15, then the GOP size is going to be 15, and if the frame rate is 30, the GOP size is going to be 30.

So, being in the situation that the parameter MediaFormat.KEY_I_FRAME_INTERVAL is one integer (not being able to give the value 0.5 to be the gopsize 15 frames using a framerate of 30), Is there any solution to configure it to an specific GOP size?

javiaf
  • 117
  • 1
  • 3
  • 12

1 Answers1

3

As you note in the question, the key frames appear every KEY_I_FRAME_INTERVAL * KEY_FRAME_RATE frames. So if you want a GOP size of 15, specify an interval of 1 and a frame rate of 15, and then just send it video at 30fps.

This begs the question: what effect does lying about the frame rate have on the codec's ability to meet the bit-rate target? I know that some devices adjust the quality based on the presentation time stamps rather than a fixed notion of frames per second, which would allow everything to work out fine. It appears that not all devices work this way however.

Unfortunately, MediaCodec doesn't provide a more flexible way to specify the GOP size.

Community
  • 1
  • 1
fadden
  • 51,356
  • 5
  • 116
  • 166
  • KEY_I_FRAME_INTERVAL set 1, and KEY_FRAME_RATE set 30, how long a key frame? – Crossle Song Jan 31 '15 at 06:22
  • 1
    Key frames are generated automatically by the encoder at regular intervals. These settings determine what that interval is. – fadden Jan 31 '15 at 06:27
  • Is there an upper limit to what KEY_I_FRAME_INTERVAL can be set to? – Dean Wild Oct 01 '15 at 16:19
  • @DeanWild: I expect I-frame interval limitations would be codec-specific. Possibly hardware-specific if a particular device can't keep up with making every frame an I-frame. I don't know if there's a need for a limit in the other direction; presumably you could get away with only having one at the start of the stream if random access didn't matter. – fadden Oct 01 '15 at 16:39
  • @fadden having a single start I-frame is indeed my goal. Working on a VOIP application which runs over TCP and we want to squeeze as much quality out of our bitrate as possible. It seems there is an upper limit being imposed somewhere - setting the KEY_I_FRAME_INTERVAL to a negative number or an arbitrary high number (10000) caused a codec initialisation failure. Setting it to something high but sensible (tried various values: 60 up to 600) seems to work fine on my devices so far using H264. – Dean Wild Oct 02 '15 at 09:42
  • 2
    UDP is usually a better choice than TCP for real-time streaming -- one waylaid packet and you'll be frozen waiting for retransmit. UDP lets you drop the occasional packet, which will be fatal for a stream with no I-frames, but merely glitchy for a stream with I-frames. I don't know what your network "weather" will be like; if you have a very reliable but limited-speed connection this concern may not matter. Many codecs are good at dealing with partial / missing data, but you can't make something from nothing. – fadden Oct 02 '15 at 16:12