Hi all...
some positive news. But a small history first... Before H264, and
when media cleaner and the early days of the sorenson codec and other
codecs that were around, I used to set the frame size to exact
multiples of the macroblocks used by the encoder. - theory is simple,
the processing and data is based on x times macroblocks (or whatever
they are called) and for really low datarate compression (dial-up) you
did not want to waste any bandwidth by slipping into the next block...
so frame sizes like 176 x 112 were exact multiple of 16x16 macroblocks
I always thought that, though you may be wasting bandwidth and
processing by going away from exact multiples of 4x4 or 16x16, you
just sacrificed CODEC efficiency and it as just hidden padding. But
after much frustration, I tried the obvious and looked at my frame
sizes -
now 16:9 looks like a nice neat ratio at 480x270 (see below), & though
the width is a multiple of 4 & 16 the height definitely isn't!!!
Went really safe and made a frame at 464x256 - both numbers divisible
by 16 - whilst I can't for the life of me figure why this would have
any effect on the audio/video sync of H264 encoding out of Wirecast,
it did! Played with Data rates, packetization type etc - apart from a
little slippage as it bought itself into line, it stayed synced. -
Also did a local self test with the inbuilt streaming server, and also
a unicast reflection from a QTSS - still synced. Let the file play
over and over again for some time - still synced.
So the key item seems to be - if your frame size is not an exact
multiple of 16 in each direction when encoding from wirecast in H264
- the video loses sync with the audio. (Yes I tried multiple of 4, but
not with success, only x16 seemed to cure the sync problem) Now
there's more testing to be done, just to check whether long period
encodes suffer any gradual slippage depending on whether Quicktime or
H264 packetization is used, and I want to verify that it is all good
for multicast relays too (no reason why not) and also VLC
compatibility, but for now, I think this is the problem I have been
chasing for months.
I have also sent a report to Varasoft, as I don't have the s/ware
debugging expertise to determine whether this is a Quicktime "hidden
feature" or a Wirecast "hidden feature"
I wonder if this frame size issue has any pertinence to other people's
chasing of Audio-Video {H264} sync issues?
cheers :-)
-----------------------------------------------------------------------------------------------------------
> On 13/03/2008, at 2:48 AM, Gerbrand Oudenaarden - Engage! wrote:
> Hi, I can't currently reply extensively. But I do have similar problems with live streams.
> I encode using an intel mac mini with wirecast, streaming h264 (600 kbps) to a darwin streaming server on linux.
> The source is a switched PAL signal, interfaced via a Datavideo analogue to firewire/DV convertor.
> The sync problem becomes obvious after an hour or two, three.
> ciao,
> Gerbrand
<quote>
On Thu, Mar 6, 2008 at 3:53 PM, John Blyth wrote:
Hi all (I've sent a similar post to varasoft)
I'm wondering if others have had audio/video sync issues trying to
broadcast H264 with wirecast. When broadcasting a live stream,
multicast or automatic unicast to a QTSS server (for relaying) I
observe the following behaviour...
---------------------------------------------
Wirecast(WC) or QuicktimeBroadcaster(QTB)
* Mpeg4 encoding audio/video sync is fine (but video quality ordinary)
* QTB/H264 better video quality and sync stays solid & plays with VLC
* WC/H264 better video quality but video delayed w/r/t audio from a
few frames to 1/2 to 1 second depending on source material
* Using beta elgato turbo264 component reduces processor load (WC) but
sync problems still remain. (Beta turbo264 & QTB not compatible)
*** All the above encoded to 480x270(16:9) image/mpeg4 audio at
1.5Mbps total data rate
<snip> <snip>
It does seem to be a quirk of the process that wirecast is using to
encode the H264 files, as QTB does not exhibit the same behaviour.
Also the repeatable nature of the different delay times switching
sources within wirecast suggests to me it is tied up with encoding.
</quote>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Streaming-server-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/streaming-server-users/email@hidden
This email sent to email@hidden
