Re: [Mvpmc-devel] Can ffmpeg handle commercial skipping?

[Chase D. <cha...@gm...>]

On Feb 19, 2009, at 2:03 PM, Tom Metro wrote:
> stuart wrote:
>> Does anyone know what ffmpeg will do if / when the myth-back-end  
>> skips
>> around in the video (i.e. commercial skipping)?
>>
>> I was under the impression commercial skipping was not usable through
>> VLC for this reason (VLC can not handle interrupted video streams).
>
> It sounds like you're imaging an architecture where you've replaced  
> the
> video file with a something like a named pipe being feed by a
> transcoding tool, and the MythTV back-end is still operating on the  
> pipe
> as if it was a regular file, attempting to seek to arbitrary points.
>
> I don't know how Chase implemented his proxy, but if I was  
> intercepting
> MythTV protocol commands to feed a client an alternate stream, I'd  
> also
> intercept the commands that relate to navigating within the video, and
> perform the equivalent action.
>
> (As far as I know, all navigation actions, including commercial
> skipping, are driven by the front-end, and thus would appear as MythTV
> protocol commands.)
>
> Given that transcoding seems to be happening via any arbitrary  
> external
> tool, it's pretty safe to assume that isn't how it is currently
> implemented, but perhaps it could be without too much additional  
> effort.
> It would require developing a driver that is tightly coupled to the
> chosen transcoding tool. The one for VLC, for example, could use VLC's
> API for navigation around the video. For ffmpeg you'd probably have to
> kill and restart the process with a frame offset command line  
> option, or
> some such.


I am not quite sure what all you are saying here, so I'll try to recap  
and you can let me know if I am off base.

I believe you are assuming that when a frontend requests a video  
stream from MTP that MTP is transcoding the backend recording file  
itself. However, this would only work if MTP were only proxying to the  
server it is on, or you do some network file share magic.

Instead, when a frontend requests a video stream from MTP, MTP  
requests the stream on behalf of the frontend, but then the data  
connection for the stream is cut between the backend and frontend. At  
this point, MTP inserts itself as the middle man. It independently  
fills a buffer inside MTP with the video stream from the backend. This  
buffer is fed to the transcoding process as it is ready. The  
transcoding process spits out the new video stream and MTP stores it  
into a second buffer. As the frontend requests blocks of the  
transcoded video stream, MTP sends it data from this second buffer.

This works fine so far, but I haven't go to the point where I have  
tested seeking around yet. What probably needs to happen when you seek  
is that MTP flushes both buffers when is proxies the seek request from  
the frontend to the backend. This is probably the biggest thing  
missing in the current implementation. Of course, the current  
implementation won't exactly fail, you'll just have to wait for the  
currently buffered stream to move its way through the system before  
you see the seek you requested.