Thanks, that did take me a tiny step further. I'm now creating an RTPSink in
createNewRTPSink just like you suggested, and an instance of my custom Opus
encoder source in createNewStreamSource. However, when I connect with my client
via an RTSPClient, I get a 404 returned.
Sending requ
tomatically just like
for H264/5 video and I would just have to use the right base classes.
Thanks,
Roland
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
ms* to do it's job. However, I still have the issue with the
broken I-frames at the very beginning (see other thread), so I'm suspicious of
every little detail...
Thanks,
Roland
-Ursprüngliche Nachricht-
Von: live-devel [mailto:live-devel-boun...@ns.live555.com] Im Auftrag von
y, 10 times in a row, then you get broken video files for hours. I
certainly don't get it.
Best,
Roland
[2] https://www.dropbox.com/s/od7014v3oqbsp1n/live555-streaming-2.zip?dl=0
-Ursprüngliche Nachricht-
Von: live-devel [mailto:live-devel-boun...@ns.live555.com] Im Auftrag von R
investigate. I'm afraid, I've got an extensive debugging session ahead of me,
I'll let you know when I get any findings. I was just hoping that somebody
could point me towards some nuance I may have missed.
Best,
Roland
-Ursprüngliche Nachricht-
Von: live-devel [mai
a 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
the issue is, then. Any hints on how I
could approach this would be highly appreciated, as I'm a bit clueless right
now.
Thanks,
Roland
-Ursprüngliche Nachricht-
Von: live-devel [mailto:live-devel-boun...@ns.live555.com] Im Auftrag von Ross
Finlayson
Gesendet: Mittwoch, 3. Mai 2017 20:
By the way: I'm using the most recent VLC version 2.2.4 and the 11-28-2016
live555 build of testProgs -- according to the changelog of the latest version,
there have been no code changes in related matters, so I think it's safe to say
I'm up to date.
Best,
Roland
-Ursprüng
ve555MediaServer to openRTSP (MPC replay).png").
Best,
Roland
[1] https://www.dropbox.com/s/6rp3dezkw5vxnx3/live555-streaming.zip?dl=0
-Ursprüngliche Nachricht-
Von: live-devel [mailto:live-devel-boun...@ns.live555.com] Im Auftrag von Ross
Finlayson
Gesendet: Mittwoch, 3. Mai 2017 13:
ading, but maybe I overlooked something. Anyways,
this doesn't seem to be solving the issue at hand, since I can reproduce the
error without using my own code at all.
Thanks,
Roland
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Okay, thanks. I thought the SPS would be related to SDP... But makes sense, I
just recently realized it's encoded in a NAL unit.
-Ursprüngliche Nachricht-
Von: live-devel [mailto:live-devel-boun...@ns.live555.com] Im Auftrag von Ross
Finlayson
Gesendet: Donnerstag, 23. März 2017 16:45
A
Hi,
I am trying to figure out how to get the frame width and height out of a H.264
stream and I'm having some difficulties understanding how to decode a SPS.
On the FAQ section on live555.com I found the following:
"If you are receiving H.264 video data, there is one more thing that you have
t
t supposed to be aware of the streaming code.
Is there a place within the live555 classes where this would have to go?
Another question: is there a way of figuring out that the connection was
lost/closed? Currently, my session keeps sending forever, as I couldn't find
out how
e. I'm not
sure if this is the way it's supposed to work.
Is there a sample or documentation somewhere?
Thanks,
Roland
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
ence however,
the community there it is much more responsive then at most mailing lists. Not
in case of live555 I must say, so thanks again for the great support!
@H264VideoStreamDiscreteFramer: got it!
Best,
Roland
___
live-devel mailing list
live-d
m data delivered by encoders such as
NvEnc/x264 by myself?
Thanks,
Roland
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
stRTPSClient alike. Why is that?
Thanks,
Roland
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
> Is there any reference or commonly cited material about how these values
are calculated?
"The RTP timestamp represents the sampling instant of the first octet of
data in the frame. It starts from a random initial value and increments at a
media-dependent rate."
>From "RTP, Audio and Video
k. Once you hit breakpoints, inspect variables
and try to understand if the values stored in them make sense or not.
I'll leave it to someone with RTSP experience to troubleshoot the other side
of the equation (what's sitting at 239.255.42.42?)...
Roland
From: [EMAIL PROTECTED]
[ma
uch either. Not only do they contain bars that
span the entire Y-axis, they also suffer from severe redraw issues, once you
zoom in on some spots... I tend to look mostly at the list of packets and
then use "Jump To" to further inspect the packets in the main window.
roland
Fr
tep, the linker will resolve the references
and look for compiled code for Foo(), which is either in another object
file, or in a library (which is just a 'zip' of a bunch of object files).
cu
roland
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Melvin_Raj
Sent: Tuesd
esolved symbols. e.g. class "Locale" is defined
in "liveMedia\Locale.cpp"...
cu
Roland
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Melvin_Raj
Sent: Tuesday, August 05, 2008 3:04 AM
To: live-devel@lists.live555.com
Subject: [Live-devel] Help with link error
* sending... E.g. it turns out that my
source was sending flawless audio, but the video stream had corrupted
packets every now and then...
Roland
PS: One way to rule out the "mash-together" theory could be to have a look
at the big P-frame with a hex-editor. Look for sequences
>As for approach to deal with it. I simply have NO idea Roland... The
>problem is that it basically affects all data between (in your sample
>208 and 212) to go "bad" which is quite a large gap of course. I you
>have a briljant idea, i'll welcome it :D
I'm ta
f PresentationTime goes
backwards by this much? I've been trying to come up with all sorts
of explanations and the only ones that makes sense to me is that NTP
time of SR packets is not necessarily PresentationTime (sustained by
wording in my book and RFC), the other one that the server
imple
Audio RTP at 62.0 (8.0 seconds elapsed)
SR for Video: NTP+16.1: Video RTP at 105.0 (7.9 seconds elapsed)
-> Video is drifting by 0.1 seconds behind, accelerate playback
Does that make sense?
Thanks for reading this far
Roland
___
live-devel mailing l
26 matches
Mail list logo
