On 30/11/2014 01:45, Christophe Gisquet wrote:
Most of the code is actually not mine but originated from "Direct264":
http://forum.doom9.org/showthread.php?t=152419
https://svn.code.sf.net/p/direct264/code/Patches/
Therefore I've tried to split as best as possible the code I have added.
There are 3 controversial parts in this patch set:
- the BSF API change (fixing it is out of my league/time budget)
- the filter doing in-place filtering (?)
- the level of validation for this new filter
I've only tested the cropping feature, and validating that the rest
works tenuous. Anyway, cropping is unfortunately not at all well
supported:
- VLC 2.1.5 (Windows) either crashes or outputs garbage
- DXVA on some Intel core gets top/left cropping completely wrong
(0,0 but something valid for bottom/right seems to be OK)
- ffmpeg-based decoders (e.g. mplayer) are OK
It is possible the implementation is incorrect but it was written
following the specs.
I don't really understand this patchset nor the usecase for it.
While of course it's technically possible to change the SPS, it's a
VeryBadIdea to so. Especially if you are targetting cropping (which is
fixed in VLC 2.2 btw), you *never ever* have to ignore it, but use it to
crop the picture correctly, as it's a mandatory part in the H264
specifications. If your use case is non-spec compliant, then you already
have a CODEC_FLAG for that, which does not modifies the bitstream.
All other uses cases seem workaround for broken encoders/decoders, it'd
be better to fix those instead.
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel