[Live-devel] Starting Frames are corrupted

[Jeff Shanab]

The first of the 3 images looks like the information has been truncated, at
least on the luminence plane but with all grey it is not certain. The first
frame in full color pictures from earlier email, the one of a cube and
pyrimid is definitely truncated. With the decoders I've used, when the
decoder runs out of info it just maintains the same value for the pixels.

There is also damage within the image So there is more going on incorrectly
here than just truncated information. Have you checked your YUV flavor?
they have different layouts and memory usage.

Also when I copied my own data in i was re-educated on how types effect
copying. SO double check your data moving for "overlap" make sure you are
indeed copying bytes in order and not any overlap, byte order, or type
promotion to wider types!


On Tue, Jun 24, 2014 at 6:38 AM, Vikram Singh <vikram at vizexperts.com> wrote:

> On a further note :
>
>
>
> -        I was testing the same file with wowza streaming server and I
> did not find any glitches at the start.
>
>
>
> -        But the same file when I am streaming with directly downloaded
> file testH264VideoStreamer.exe provided in the testprogs of live555 library,
>
> the stream starting was very noisy as shown in the links from previous
> emails.
>
>
>
> -        I also found the same starting frame issues with Darwin
> streaming server when I was streaming with the same file.
>
>
>
> -        And I am sure the files I am testing with are not corrupted.
>
>
>
> -vikram singh
>
>
>
> *From:* live-devel [mailto:live-devel-bounces at ns.live555.com] *On Behalf
> Of *Vikram Singh
> *Sent:* Friday, June 20, 2014 7:58 PM
> *To:* 'LIVE555 Streaming Media - development & use'
> *Subject:* Re: [Live-devel] Starting Frames are corrupted
>
>
>
> Hi ross,
>
>
>
> Please ignore my previous mail. I was sent accidently.
>
>
>
> Just for testing purpose, I have reduced my streaming video size to
> 100*100 px size.
>
> By reducing the size I want to avoid the scenario where on the client side
> there is truncation of data, due to buffer overflow in the starting.
>
> This buffer overflow was assumed because the client had no idea about
> server frame size and initialized a default size to the buffer that
> receives data.
>
> Even then I have the problem of corrupt frames in the starting.
>
>
>
> Can there be any other case because of which this initial corruption of
> frames is happening.
>
>
>
> An another observation is when I had incorrect OutPacketBuffer::maxSize initialized
> to it, the frame rendered were like this
>
>
> https://drive.google.com/file/d/0B9yXmUZbfI7_OWJiblZta1hXYWM/edit?usp=sharing
>
> i.e the frame would bleed to the bottom and that symbolizes the truncation
> of frame.
>
>
>
> Instead the corruption was something like this
>
> https://docs.google.com/file/d/0B9yXmUZbfI7_YUxEb1ltZ2pwa3M/edit
>
>
>
> and after some time it would clear up like this
>
> https://docs.google.com/file/d/0B9yXmUZbfI7_VW9uU2NWU041SkE/edit
>
>
>
> So can there be any other issue that is causing this problem.
>
> -vikram
>
>
>
> *From:* live-devel [mailto:live-devel-bounces at ns.live555.com] *On Behalf
> Of *Ross Finlayson
> *Sent:* Wednesday, June 18, 2014 11:13 PM
> *To:* LIVE555 Streaming Media - development & use
> *Subject:* Re: [Live-devel] Starting Frames are corrupted
>
>
>
> I am having --  unsigned OutPacketBuffer::maxSize = 900000;  in
> mediaSink.cpp
>
> If I decrease the maxSize then the frames I get are truncated.
>
>
>
> OK, there are two separate buffer sizes that you need to concern yourself
> with.
>
>
>
> "OutPacketBuffer::maxSize" is the buffer size that is used - by your
> server - when *transmitting* NAL units.  You must set it to be at least as
> large as your largest NAL unit.  Otherwise you will see (in 'stderr') error
> messages about needing to increase "OutPacketBuffer::maxSize".
>
>
>
> The receiving application - in your case VLC - must also have sufficient
> buffer space to be able to reassemble the incoming RTP packets into a
> complete NAL unit.  That is what I referred to in my previous email message.
>
>
>
> In any case, 900000 bytes is an *insanely large* NAL unit (I-frame) size!!
>  A NAL unit this large will get fragmented into *60* RTP packets, and *all*
> of these RTP packets must be received by the receiving application,
> otherwise the entire frame will be unrenderable.  This is why it's much
> better to reconfigure your encoder so that it breaks up large I-frames into
> smaller 'slice' NAL units.
>
>
>
>
>
>  Can you please specify how to decrease the nal unit size without
> decreasing the value of maxSize.
>
>
>
> You mean "how to decrease the nal unit size without *increasing* the value
> of maxSize"?  Once again, you need to reconfigure your encoder to break
> up large I-frames into smaller 'slice' NAL units.
>
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140624/d476cc89/attachment.html>