[Live-devel] H.264 in MPEG-2 TS streams roughly at the start

[Warren Young]

We've been using live555MediaServer with MPEG-2 A/V in TS files 
successfully for quite some time now, but we are now experimenting with 
H.264 in TS.  We've been unable to create files that stream as smoothly 
as our old MPEG-2 files.

Here is my latest ffmpeg command attempt:

ffmpeg -i original-mpeg2-version.ts -f mpegts -filter:v yadif \
        -s hd720 -vcodec libx264 -profile:v high -b:v 8M \
        -maxrate:v 15M -bufsize:v 12M -acodec ac3 -b:a 128k \
        -flags cgop -fflags genpts h264-test.ts

The result of that command is here, for your examination:

	http://etr-usa.com/live555/h264-test.ts

(8 Mbit/s ≈ 1 MByte/min.  File is 60 sec, 66 MB.)

Both VLC and our STB are unhappy playing this via RTSP.  (STB = The one 
we sent you months ago, Ross.)  For the first 30 seconds or so, playback 
speed is badly controlled, as though Live555 isn't sending packets out 
at the right rate.  After that, playback is mostly fine, though it does 
"blip" occasionally.  VLC plays the file just fine straight off the disk.

testMPEG2TransportStreamer exhibits the same stuttery playback symptom 
as live555MediaServer.  (Yes, latest version: 2012.09.06.)

Our ffmpeg build is up to date, too.  Our tests started with a build 
from a git pull taken back in May, but re-pulling and rebuilding both 
ffmpeg and libx264 didn't result in materially different files.

The -flags cgop (closed GOP) and -fflags genpts (regenerate PTS) options 
in the command above are desperation attempts, thinking maybe the 
problem is due to lack of some header or timing info.  Neither helped, 
in combination or separately.

That isn't surprising given that the .tsx file is nearly 4 MB.  If 
timing or headers were the problem, we'd see a small or empty .tsx file, 
wouldn't we?

Removing the .tsx file and restarting the RTSP server or RTP streamer 
doesn't change the symptom.

The yadif filter and 720p options are there purely because the original 
MPEG-2 TS file is 1080i @ 59.94, 19.4 Mbit/s.  Resizing and 
deinterlacing it is just part of our overall effort to get a smaller 
file, which also lead us to try switching to H.264.

The remaining flags in the ffmpeg command have to do with ensuring the 
resulting file fits comfortably within the STB's limits.  (HiP at 4.0) 
We've experimented with MP at 3.0 compliant encoding settings, with no 
effect on the symptom.  That tells us the problem isn't one of too much 
data for the network or STB.

We're taking a poorly-informed guess on the -bufsize parameter.  The 
MPEG decoder chip inside the STB doesn't have a publicly available 
datasheet, and the STB's manufacturer doesn't document the VBV limits, 
other than to say "HiP at 4.0".  That means up to a 25 Mbit buffer is 
legal, right?

We've tried values between 6M and 18M here.  The only effect we've seen 
is that if it gets too low, the stream won't play on the STB at all. 
So, we've lately been keeping the buffer to 1-2 seconds, changing the 
parameter to track the chosen average bit rate.

We don't see why the -bufsize parameter would affect anything, given 
that VLC also shows the symptom.  That suggests VBV limits have nothing 
to do with it, since VLC effectively has no VBV limits, right?

Googling didn't bring up any recommended ffmpeg encoding settings for 
Live555.

I haven't tried any of the standard ffmpeg presets, since those seem 
mainly aimed at low-spec cases, like Internet streaming or iPod video. 
Our usage scenario is LAN streaming from big RAIDs.  Our ideal, with 
this move to H.264, is to get solid-quality HD video in space equivalent 
to high-quality SD.  Say, 8-15 Mbit/s, 720p.  We're not shooting for 
Criterion Collection BluRay quality here, just solid HD a step or two 
above YouTube/NetFlix/Hulu class "HD".

I tell you all this in case it's our encoder settings causing the 
problem, so you can suggest changes that fit within our goals.  If the 
fix is XP at 2.0, we're not interested. :)