[Live-devel] Broken data when streaming HEVC video

[Roland Aigner]

Okay, I gotta ask:
>> But the REAL solution to your problem - as I’ve noted many times on this mailing list - is this
I read your reply as "this is the proper way to do it". Why would you suggest to increase the buffer size AND do slicing at the same time? What is the point to having a bigger buffer when I configure the encoder to give me tiny NAL units anyways? I certainly don't understand, when it was meant to be read this way.

I do realize the problem that comes with fragmentation, but as I wrote, I am currently testing on *localhost*, so I don't know how there can be any packet loss. Also, with openRTSP as a client, specifying a higher buffer size, it does work right now -- *without* slicing. openRTSP gives me perfectly valid 265 files as streamed from my server implementation.

I'm currently trying to figure out what I'm doing differently than openRTSP. My client was based on the code of the testRTSPClient sample, so I added some code to DummySink, in order to write the received packages to disk in afterGettingFrame, prefixed with the 0x00000001 starting codes. What baffles me is, that this produces invalid files, just as my client. I cannot currently discover any difference to what the H265VideoFileSink does, which, as I said, seems to work, since openRTSP produces valid files. When I try to play back the invalid file with ffplay, I get this:

[file @ 0000000001c77080] Setting default whitelist 'file,crypto'
Probing mp3 score:1 size:2048
Probing mp3 score:1 size:4096
Probing mp3 score:1 size:8192
Probing mp3 score:1 size:16384
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000001c775c0] Format mov,mp4,m4a,3gp,3g2,mj2 detected only with low score of 1, misdetection possible!
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000001c775c0] type: 010c0140 '@?♀?' parent:'root' sz: -280100587175176 16 68386
    Last message repeated 1 times
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000001c775c0] moov atom not found
[AVIOContext @ 0000000001c80400] Statistics: 68386 bytes read, 0 seeks
test.mp4: Invalid data found when processing input

Again, I'm not sure how the output is any different from what H265VideoFileSink generates, apart from the SPropRecords header, which, to my experience isn't mandatory.

Does anybody have any ideas?

Thanks,
Roland


-----Ursprüngliche Nachricht-----
Von: live-devel [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Ross Finlayson
Gesendet: Donnerstag, 4. Mai 2017 13:45
An: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Betreff: Re: [Live-devel] Broken data when streaming HEVC video

> Just to be clear: the buffer sizes I have to increase are the OutPacketBuffer::maxSize on the server, prior to creating any RTPSinks, as well as the size of my own, user-created buffer in the client, the one I'm passing to FrameSource::getNextFrame in my MediaSink::continuePlaying overload, right?

Yes.


> Or is there something else?

Yes, the “something else” is that you also need to reconfigure your encoder to generate multiple ‘slice’ NAL units for each ‘key frame’, rather than generating each key frame as a single (~150000-byte) NAL unit.  This is not just a ‘hint’.  It’s not just something that you need to ‘look into’.  If you don’t do this, each of your key frames will take up about 1000 RTP packets.  If *any* of these packets gets lost, then you will not be able to deliver and render the key frame - at all!

If your network packet loss rate is just 0.1%, then this means that you can expect to deliver only about 37% (==0.999^1000) of your key frames.  Even if your network packet loss rate were just 0.01%, then you could expect to deliver only about 90% (==0.9999^1000) of your key frames.


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