<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I've got this working now, I think my problem was conceptually
treating the byte stream as a series of frames instead of as a
continuous stream.<br>
<br>
Having looked at the ByteStreamMemoryBufferSource class it makes a
lot more sense now.<br>
<br>
<div class="moz-cite-prefix">On 03/11/2015 10:10 AM, Robert Smith
wrote:<br>
</div>
<blockquote cite="mid:55000684.3060003@cognitec.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Firstly apologies for the multiple posts.<br>
<br>
The platform is a TI DaVinci DM8148 using TI's HDVICP2 video
encoder hardware. As far as I can tell the encoder is capable of
outputting discrete NALU's but we are only able to use the encoder
via an OpenMAX API which doesn't expose this behaviour.. it's
frustrating!.<br>
<br>
The encoder provides discrete 'frames' which consist of a buffer
of concatenated NALU's prepended with the start codes.<br>
<br>
Now that I think about it, If the H264VideoFramer is expecting to
read X bytes from a continuous stream, I should be able to give it
only part of the 'frame' that I receive from the encoder? I'll try
this and see how it works.<br>
<br>
Btw, On our other systems we use the Intel IPP H264 encoder and
the Intel Media SDK encoder, I'm not as familiar with them but I
understand that they also don't output discrete NALU's so I
thought this was common amongst encoders.<br>
<br>
<br>
Regarding slices, I can configure the encoder to encode a frame as
multiple slices based either on a maximum slice size or number of
MB's per slice but we're using GStreamer as one of our clients and
I get a lot of image corruption with multiple slices enabled.<br>
<br>
I haven't had time to look into the problem deeper but using a
single slice was a quick and easy solution.<br>
<br>
Thanks,<br>
<br>
Robert Smith.<br>
<br>
<div class="moz-cite-prefix">On 03/10/2015 01:49 AM, Ross
Finlayson wrote:<br>
</div>
<blockquote
cite="mid:C3686A3F-6D98-4502-BBD8-C8BE762C3C0F@live555.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<blockquote type="cite" class="">
<div class="">The encoder unfortunately only supplies frames
in Annex B byte stream format requiring the frames to be
parsed.</div>
</blockquote>
<div><br class="">
</div>
Are you sure about this? (Often, hardware encoders have
firmware upgrades available.)</div>
<div><br class="">
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class=""> Previously I was using my own class to
identify the NAL unit's in conjunction with the
H264VideoDiscreteFramer which worked fine but it's heavy
on the CPU. So I've been trying to use the H264VideoFramer
and just pass the full frames in which works ok and is
faster than my solution except that I'm seeing a lot of
truncated frames.<br class="">
<br class="">
Having looked into the code it appears to be caused by the
behaviour of the StreamParser class; specifically the
ensureValidBytes1() method which calls getNextFrame() on
my source with maxSize = BANK_SIZE - fTotNumValidBytes.
The method switches banks to ensure that the larger of
numBytesNeeded or the input sources maxFrameSize() will
fit.<br class="">
<br class="">
I can 'fix' the problem by increasing BANK_SIZE and
implementing maxFrameSize() on my source but I'm not
totally happy with this solution because I would prefer
not to modify the library source and I'm just guessing for
the maxFrameSize() value.<br class="">
<br class="">
I was wondering whether it's possible to return a partial
frame from my video source?</div>
</blockquote>
<div><br class="">
</div>
Yes, but not in the way that you might think :-) A H.264
encoder actually delivers “NAL units”. “NAL units” are what
actually get parsed by our code, and packed into RTP packets.</div>
<div><br class="">
</div>
<div>Often, a “NAL unit” is a complete frame. It is possible,
however, for a ‘key frame’ to be split up - by your encoder -
into multiple ‘slice’ NAL units. For datagram streaming
(e.g., over RTP), it is *much* better to have your key frames
broken up into multiple ‘slice’ NAL units, than to have the
key frame be a single, large NAL unit - which is what you have
now. This is especially true if your key frames are
exceptionally large: ~150000 bytes or larger, which appears to
be the case for you, because you are hitting the BANK_SIZE
limit (which was deliberately set to be larger than
realistically needed).</div>
<div><br class="">
</div>
<div>Note that a 150000 byte key frame NAL unit will get
transmitted as more than 1000 RTP packets (datagrams). (Our
code automatically handles the required fragmentation.) If
*any* of these 1000 packets gets lost in transit, then the
entire key frame will be undeliverable.</div>
<div><br class="">
</div>
<div>If, instead, your encoder delivers each key frame as
multiple ‘slice’ NAL units, then your streaming will be much
more resilient to network packet loss.</div>
<div><br class="">
</div>
<div>So, your first task should be to check whether your
encoder:</div>
<div>1/ can be reconfigured to deliver discrete frames, rather
than a stream with each NAL unit prepended by a 0x00 0x00 0x00
0x01 ‘start code’, and</div>
<div>2/ can be reconfigured to deliver key frames as multiple
‘slice’ NAL units, rather than as a single (ridiculously
large) NAL unit.</div>
<br class="">
<br class="">
<div apple-content-edited="true" class=""> <span
class="Apple-style-span" style="border-collapse: separate;
color: rgb(0, 0, 0); font-family: Helvetica; font-style:
normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; "><span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0);
font-family: Helvetica; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align: -webkit-auto;
text-indent: 0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; ">Ross Finlayson<br class="">
Live Networks, Inc.<br class="">
<a moz-do-not-send="true" href="http://www.live555.com/"
class="">http://www.live555.com/</a></span></span> </div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
live-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
live-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<a class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>