> Given that, why doesn't the sink take full ownership of the source object
> once you pass it to startPlaying()?
Because it doesn't :-) That design decision was made (I think; it's been well
over a decade now) because 'sources' and 'sinks' are different kinds of object.
In principle, many di
On 1/30/2014 17:44, Ross Finlayson wrote:
I haven't seen this at all with the unmodified
"testMPEGTransportStreamer" code - which is what you should be using to
test this.
My point in asking is to learn why behavior changes when you change that
one aspect of the existing code.
At that time,
I haven't seen this at all with the unmodified "testMPEGTransportStreamer" code
- which is what you should be using to test this. The call to
Medium::close(videoSource);
in the "afterPlaying()" function (line 133) does, indeed, cause the
"ByteStreamFileSource" object (and its underlying
In an attempt to reduce the number of global variables in
testMPEG2TransportStreamer.cpp, I made videoSource a local variable in
play(), then said
Medium::close(videoSink->source());
in afterPlaying().
This appears to work, but if you watch the FD count, it goes up by one
per pass throug
