> WHAT? Just a while ago I realized I'm passing H.264 encoded buffers to
> H264VideoStreamFramer, which is perhaps doubly encoding them to H.264 again.
>
> Am I accidentally H.264 encoding twice? Does the original
> ByteStreamFileSource fed to H264VideoStreamFramer feed raw buffers to
> H264V
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
> the problem with sockets applies for Windows CE as well. Find attached a
> patch that defines READ_FROM_FILES_SYNCHRONOUSLY when compiled for WinCE.
I'm puzzled why nobody has mentioned this before. But unless someone objects,
this change will be included in the next release of the software.
Hey,
the problem with sockets applies for Windows CE as well. Find attached a patch
that defines READ_FROM_FILES_SYNCHRONOUSLY when compiled for WinCE.
Regards
Simon
InputFile.hh.patch
Description: InputFile.hh.patch
___
live-devel mailing list
live-
> My problem is that the "Framer" reports most of the frames' duration as
> "0.0", and as a result 'uSecondsToGo' in the RTPSink is always 0, and the
> frames are sent out too fast.
That's strange. The "MPEG2TransportStreamFramer" class should be scanning the
"PTS" (timestamps) in the incoming
