FYI, I have now installed a new version of the "LIVE555 Streaming Media" code
that updates "H264VideoStreamFramer" to improve the test for whether or not the
current NAL unit ends an access unit. (As a consequence, it fixes the bug with
emulation bytes that you noted.)
Thanks again for the rep
Could you post (on a web site, unless it's small) an example of a ".264"
file that causes this problem for you? I'd like to use it for testing.
Let me know if the following link works for you:
https://www.dropbox.com/s/s365ky5hqhko1x0/H264_Problem_sample_10sec.264
It's a 10 second snippet
> Fair enough. I’m looking forward to the upcoming releases.
> Until then I will keep the hack that strips the emulation bytes to get rid of
> the erroneous ‘end of access units’ it was producing and thus delaying the
> video stream.
Could you post (on a web site, unless it's small) an example o
As you noted, our "analyze_slice_header()" function doesn't check
for/remove 'emulation prevention' bytes in VCL NAL units (the ones that
have slice headers). That's probably OK, because we call
"analyze_slice_header()" only in certain cases, to check the parameters
of the 'current' and 'next' NAL
> I am curious if someone could shed some light on the following assumption in
> the live555 code:
>
> liveMedia/H264VideoStreamFramer.cpp:524: // Note: We assume that there aren't
> any 'emulation prevention' bytes here to worry about...
What this means is that we 'hope' that there aren't any
Hi all,
I am curious if someone could shed some light on the following
assumption in the live555 code:
liveMedia/H264VideoStreamFramer.cpp:524: // Note: We assume that there
aren't any 'emulation prevention' bytes here to worry about...
In our application we're noticing that our frame s
