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-boun...@ns.live555.com] Im Auftrag von Ross
Finlayson
Gesendet: Donnerstag, 4. Mai 2017 13:45
An: LIVE555 Streaming Media - development & use <live-de...@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@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
