[Ffmpeg-devel] Adding a file type, and VIC codecs

[Derek Piper]

Michael Niedermayer wrote:
> Hi
> 
> On Wed, Oct 18, 2006 at 02:28:21AM +0200, Derk-Jan Hartman wrote:
>> On 17-okt-2006, at 21:06, Michael Niedermayer wrote:
>>> On Tue, Oct 17, 2006 at 02:58:22PM -0400, Derek Piper wrote:
>>>> Michael Niedermayer wrote:
>>>>
>>>>>> 	Please let me know what the view is on adding VIC codecs.  
>>>>>> Obviously
>>>>>> they would be differentiated from the ffmpeg versions, e.g.  
>>>>>> 'vich261',
>>>>>> 'vich263'.
>>>>> what is the difference between vic-h26* and normal h26* ?
>>>> I guess that's the problem. I don't KNOW what the difference is, I
>>>> didn't write them. I only know they are not compatible based on  
>>>> trying
>>>> to decode one with the other. I was wondering if anyone on this  
>>>> list had
>>>> done anything with both of variants so that they might be able to  
>>>> shed
>>>> more light on it. It would probably mean a lot of trawling through  
>>>> code
>>>> looking for commonalities and seeing where they differ.
>>> could you provide some file / a dumped vic-h26* stream which is  
>>> playable
>>> by the VIC code but not by ffmpeg?
>>> (you can upload to ftp://upload.mplayerhq.hu)
>> One of the problems with H261 is that it's possible to have multiple  
>> video streams in one video bitstream. In teleconferencing clients  
>> these present itself as sections in the final video frame (a bit like  
>> a videowall matrix). The separate streams can come from multiple  
>> locations. ffmpeg currently has no support for this. I'm not sure if  
>> ffmpeg even COULD merge them into one frame, or alternatively split  
>> them into multiple tracks.
>>
>> If I watch VIC/RAT streams on the Mbone with VLC+ffmpeg, I can view  
>> some of these streams. It's just that all the frames of the different  
>> ES'es follow eachother in a rapid fashion, with different w x h  
>> dimensions creating a totally unviewable stream. So it can be done,  
> 
> well, this sounds like that a demuxer would be needed which splits these
> doesnt sound very hard if that spliting can be done easily?

	I don't have a problem with multiple video streams, since in AGVCR I 
just remove whatever RTP sources I don't want (or don't record them to 
start with). I had thought of a plan to incorporate voice-based 
'switching' of video streams in the editor of AGVCR, but then since H26* 
is packet based, the frame would not 'flip' nicely between sources 
anyway unless we updated all the blocks of the frame to the new one when 
it changes. Hmm.. something I need to look at some time.
	The file I was handing to ffmpeg only contained a single video stream 
from one original source, so there were issues like the one described by 
Derk-Jan (not that I think it was wrong to point out, it's a valid point).
	I need to contact the original author of the patch to ask him if he's 
okay with me uploading the code in an unfinished state before I upload 
an AGVCR file and the code to play it back to demonstrate the problem.

	Derek

-- 
Derek Piper - dcpiper at indiana.edu - (812) 856 0111
IRI 323, School of Informatics
Indiana University, Bloomington, Indiana