[Ffmpeg-devel] watermark vhook and -vcodec copy

Rich Felker dalias
Wed Jun 29 06:53:07 CEST 2005


On Wed, Jun 29, 2005 at 12:10:22AM -0400, The Wanderer wrote:
> Rich Felker wrote:
> 
> >On Tue, Jun 28, 2005 at 06:56:20PM +0100, Chris wrote:
> >
> >>I have been playing around with vhooks and the watermark vhook by
> >>Marcus Engene is very impressive indeed. My intention is to use it
> >>to add a watermark for a set duration say 10 seconds, and it works
> >>well. I would like to be able to do this to ffmpeg runs where the
> >>-vcodec copy parameter is used but it is not working,
> >>unsurprisingly.
> >>
> >>Has anyone managed to get a vhook working for -vcodec copy? Is
> >>anyone interested in attempting it?
> >
> >No, this is complete and utter nonsense. Copying video frames and
> >modifying them are mutually exclusive.
> 
> It wasn't all that long ago (about three weeks, actuallly) that I had a
> conversation here with a person who was insisting that it should be
> possible to crop without decoding/re-encoding, i.e., with the same base
> behaviour as '-vcodec copy'; IIRC the discussion came about because he
> was surprised that MEncoder wasn't letting him do that. I believe he
> indicated that there is a program which can do it already, but which is
> compatible with fewer types of files than MPlayer/etc. is...

there is no such program..

> The reason I mention this is that, because of that last point, I'm
> curious as to whether or not this falls under the heading of "modifying"
> as it's defined in this context; it would seem unintuitive to me, but he
> made a fairly persuasive argument that since you are in fact duplicating
> the parts you want to keep and completely discarding everything else,
> it's still reasonable to call the behaviour "copying". I'm not sure
> there isn't a hole in that, but I'm not technically compentent enough to
> tell for certain.

this person was talking nonsense too. just because you're not keeping
the cropped edges does not mean the data you _are_ keeping does not
_depend_ on the data in the cropped areas. if a motion vector for the
block at 128,32 pulled data from 120,5 of the previous frame and you
cropped off the top 32 pixels, where the hell is that data supposed to
magically come from?!?

in certain cases it _is_ possible to crop without recompressing, e.g.
mjpeg with multiple-of-16 crop offsets. however this still is not a
framecopy operation. the definition of framecopy is a binary
byte-for-byte copy of the existing encoded frames with no knowledge of
the codec. alterring data without decompressing and recompressing it
requires intricate codec knowledge and is actually more difficult
(from a coding perspective, not a computational one) than just
recompressing.

rich






More information about the ffmpeg-devel mailing list