[Ffmpeg-devel] Adding a file type, and VIC codecs
Wed Oct 18 16:08:05 CEST 2006
Michael Niedermayer wrote:
> 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.
>>>>>> they would be differentiated from the ffmpeg versions, e.g.
>>>>> 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
>>>> 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
>>>> more light on it. It would probably mean a lot of trawling through
>>>> looking for commonalities and seeing where they differ.
>>> could you provide some file / a dumped vic-h26* stream which is
>>> 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 Piper - dcpiper at indiana.edu - (812) 856 0111
IRI 323, School of Informatics
Indiana University, Bloomington, Indiana
More information about the ffmpeg-devel