Chris,
I've gotten a very similar pipe thing working. Ross was invaluable in
helping. Here are two points you may need to recall, to finally get it
working properly.
This advice relates to using H.264. It may only partially relate to your
application.
1) You must make sure that you're sending
To Ross, I assume... You're so insightful and you always seem to nail it
on the head. Perhaps you can give me some guidance here again.
I got my named-pipe (actually I think it was an anonymous pipe) on Windows
working with good quality, from my video source software, through Live555,
and out to
Ross,
Thanks.
We got it working. You are correct about the bursty transmission. I'll
add your buffering comment to our work task list, to keep it in mind for
when we may need it in the future.
...
To assist others in figuring out their own problems, I'll mention that my
remote associate on th
We want our PC to send a video stream to an iPad, and we sometimes test by
sending to VLC over the local network.
The video stream gets into linked-in Live555 code via ByteStreamFileSource,
but in two different ways. One way is from a file on disk (File as File).
The other way is through a named
relates to
checkForAuxSDPLine1() function, which seems to be simply checking for
something to be OK. Then after it the real job starts. Thus the apparent
restart...
On Wed, Feb 20, 2013 at 11:22 AM, temp2...@forren.org
wrote:
> FYI, I've re-enabled tracing in H264VideoStreamParser::p
operly. So I'm trying to figure out where frame_num comes from and how
my live send of the same stream might be messed up...
Another other advice is greatly appreciated.
On Wed, Feb 20, 2013 at 9:34 AM, temp2...@forren.org wrote:
> I have a MF_H264_DeviceSource derived f
I have a MF_H264_DeviceSource derived from DeviceSource, being used
by H264VideoOnDemandServerMediaSubsession derived
from OnDemandServerMediaSubsession, from top level XXXOnDemandRTSPServer
derived from testOnDemandRTSPServer.
Viewing my output with VLC, the output is HORRIBLY RAGGED.
I took the
Ross,
Thanks. Cool... I figured out this exact same problem on my own yesterday,
perhaps 5 hours before your email. I got up in the middle of the night
tonight and implemented a fix. I just got it working... yeah!... and went
to email you back. Then I found your email. I was proud of myself f
Ross,
I apologize for offending you. It was not intended. A snafu led me around
from one piece of advice on the FAQ to following the trail I was following,
and I didn't realize there was other germane advice on the FAQ that I
missed. Meanwhile, my mod of the existing code was only a tentative
a
Ross,
Thanks for the advice.
I found MF_H264_DeviceSource::deliverFrame() as well as an old trace
statement I put in it back on my successful cobble. This is in fact the
"deep inside" I was looking for, albeit having been called back from deep
inside and now back in my code. The trace is coming
I've successfully cobbled some things together in the past, but in doing it
again this time it's not working.
I come to the point of wanting to trace the action that happens in response
to DeviceSource.cpp's signalNewFrameData() .
In detail, signalNewFrameData() does
this: ourScheduler->triggerEv
(((Jacob, please see Ross'es quoted email response further below. ABORT
the removal of double H.264...)))
Ross,
Thanks very much for this info. Will do.
Regarding your statement [your 'framer' object should then be fed into a
"H264VideoRTPSink" object, for streaming], please help me understand
Am I accidentally H.264 encoding twice? I have a monstrosity combination
of media foundation and live555. It manages to send IP video out, and VLC
receives it. But the quality is bad.
I have code that was a 555 test program, that I modified to make my own sub
thread. I have a MF_H264_DeviceSou
kBi = 3.51 Mbi uncompressed => 3.51 Mbi / 160
> kbi = 22,5 times.
>
> I suggest to render the stream for the luminance plane only (like old TV
> sets!!): if you get a good output, the problem is the way the renderer
> works on the U and V plane.
>
>
> Regards,
>
>
Thanks very much for your help, Ross.
BACKGROUND: (CLARIFICATION ONLY) Indeed I only have one thread calling
doEventLoop(). That's all I meant by my penultimate background sentence.
The last background sentence points out a separate thread for MF, that's
independent of Live555, and is in fact th
Please consider these two questions. Thanks very much.
BACKGROUND: I adapted testH264VideoStreamer.cpp and DeviceSouce.cpp/hpp so
that I could send a live video feed out over the network. I currently test
using VLC. I generate h.264 encoded frames using a Microsoft Media
Foundation (MF) back e
16 matches
Mail list logo
