[mythtv] MythWeb flash and ffmpeg

[Michael T. Dean]

On 06/01/2007 12:52 PM, Chris Petersen wrote:
> Michael T. Dean wrote:
>   
>> When it reaches the end of the recording.  So, if you're doing a "Live"
>> recording, it will finish up as soon as the transcode catches up to
>> real-time.  If you're doing a 1-hour recording and watch only 5 minutes,
>> it will still transcode the rest of the show.
>>     
> Actually, it stops when apache tells the mythweb perl script managing
> things that the browser has browsed away.  If your browser has
> pipelining or connection pooling/caching enabled, it will keep
> connections open even after you browse away from the page, so ffmpeg
> will keep recording.

Are you sure you don't just have a very fast machine?

I've got Firefox 2.0.0.3 and have had network.http.pipelining and
network.http.proxy.pipelining set to false.

I even set network.http.version to 1.0 (which doesn't support Keep-Alive
connections) and get the same result.

And, if I close the browser (which better close all connections to the
server), it still finishes transcoding the entire show.

Even when I click the stop button on the player or keep browsing through
the rest of the MythWeb app, I get the same result--it transcodes to the
end of the recording.

The only way I've been able to make the process stop mid-recording is a)
kill it or b) shut down httpd (which kills it).

Started the transcode at 13:10 with HTTP 1.0/no pipelining, closed the
browser at 13:14 and did the grep at 13:20.  The show is a 720x480
MPEG-2 recording that's 36 minutes long and is being transcoded by an
Athlon XP 2000+.

$ ps -efw | grep ffmpeg
httpd    21684  1456  0 13:10 ?        00:00:00 sh -c /usr/bin/ffmpeg -y
-i /video/mythtv/recordings//1002_20070314205700.mpg -s 320x240 -r 24 -f
flv -ac 2 -ar 11025 -ab 64k -b 256k /dev/stdout 2>/dev/null
httpd    21685 21684 95 13:10 ?        00:09:27 /usr/bin/ffmpeg -y -i
/video/mythtv/recordings//1002_20070314205700.mpg -s 320x240 -r 24 -f
flv -ac 2 -ar 11025 -ab 64k -b 256k /dev/stdout
mtdean   21726 21662  0 13:20 pts/1    00:00:00 grep ffmpeg

It was finished by the next time I looked (at 13:22).

And here's a 2 hour 6 minute recording where playback/transcoding was
started at 13:25 with HTTP 1.0/no pipelining, browser was closed at
13:26 and I actually thought ahead and scripted a 1/min grep where the
final one showing the process was:

httpd    21742 18117  0 13:25 ?        00:00:00 sh -c /usr/bin/ffmpeg -y
-i /video/mythtv/recordings1//1006_20070523205700.mpg -s 320x240 -r 24
-f flv -ac 2 -ar 11025 -ab 64k -b 256k /dev/stdout 2>/dev/null
httpd    21743 21742 96 13:25 ?        00:39:00 /usr/bin/ffmpeg -y -i
/video/mythtv/recordings1//1006_20070523205700.mpg -s 320x240 -r 24 -f
flv -ac 2 -ar 11025 -ab 64k -b 256k /dev/stdout
mtdean   22039 21662  0 14:06 pts/1    00:00:00 grep ffmpeg

Which works out to about 39 minutes of transcoding, and--since the 36
minute show may have taken more than one minute but less than 2 minutes
longer than I showed--it seems to be the expected transcoding time based
on about 3.25 minutes of show transcoded per minute.

TTBOMK, the server never explicitly tells processes that the client is
no longer connected (nor kills processes when the client disconnects)
and the only way to detect it would be at the application level (i.e.
the Flash player causes something (JavaScript?) to send a new request to
the server when the stop button is clicked and the application kills the
process.  Or the application explicitly checks to see if writes have
become no-ops (or if the output file descriptor is unreadable, i.e.
closed) and the application kills the process.  The detection of no-op
writes or closed file descriptor may be a relatively-recent addition to
httpd, because the lack of it is what used to cause all those "Broken
pipe" messages in the logs."  I'm not sure exactly when it went in.
|||
|So, basically, AIUI, there's a "side-effect" of a disconnect that
causes the sockets feeding stdin and stdout to get disconnected. 
Apache's mod_perl exploits this side effect and sets a flag on buffer
flush when it detects a disconnected socket that can be accessed with
the Connection's aborted() method.  But, if writes are slow enough that
the buffer is flushed too infrequently, you can check for a disconnected
socket yourself by using fileno() and IO::Select to see if the output is
open.

If there's some httpd setting I'm missing, I'd love to hear about it. 
If not, this may or may not be worth fixing as--once we can store
multiple files per recording--we could just transcode it to disk so it's
there (local/remote issues ignored for now) for next time or autoexpired
after some interval.

Also, since it seems that ffmpeg is always going to quit on EOF (whether
used directly as now or indirectly through ffserver), as long as were
telling it to transcode a file, it won't be able to do LiveTV. 
Therefore, to add LiveTV support, we'd need to have an application that
feeds data to ffmpeg at some rate less than the rate at which the file
is growing.

While this could be done through MythWeb's code, it may make a lot more
sense to put that code in the backend (or just do the transcode directly
in the backend).  Since that change is likely to change the structure of
the command rather significantly, I'm all for the "live with it for a
while" approach.

Mike "AINAAOPE" (I Am Not An Apache Or Perl Expert) Dean