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

Reply via email to