swscale compile time width (VOF/VOFW) should be higher
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| ffmpeg (Ubuntu) |
Low
|
Unassigned |
Bug Description
Binary package hint: ffmpeg
In mencoder and gstreamer using ffvideoscale report:
...
swScaler: Compile-time maximum width is 2048 change VOF/VOFW and recompile
...
It would be nice if the maximum width could be set at least to 4096.
The use-case where this is needed is scaling a series of large jpeg images to construct a video.
Thanx
Reinhard Tartler (siretart) wrote : | #1 |
Changed in ffmpeg (Ubuntu): | |
importance: | Undecided → Low |
status: | New → Confirmed |
summary: |
- swscale compile time width restriction should be higher + swscale compile time width (VOF/VOFW) should be higher |
andrey.filippov (andrey-elphel) wrote : | #2 |
Increase of this limit (as in upstream) is very important for Elphel project, I put my comments in the other bug thread -
https:/
Andrey
Launchpad Janitor (janitor) wrote : | #3 |
This bug was fixed in the package ffmpeg - 4:0.5+svn200907
---------------
ffmpeg (4:0.5+
[ Reinhard Tartler ]
* Make arguments of av_set_pts_info() unsigned.
* update debian/changelog
* use patch for issue1245 from git.ffmpeg.org
* Support constant-quant encoding for libtheora, LP: #356322
* increase swscale compile time width (VOF/VOFW), LP: #443264
[ Loïc Minier ]
* Update config for karmic's armel toolchain.
* Enable neon flavour; LP: #383240.
* Update NEON confflags to assume v7 and VFP.
* Add backported NEON patches from ffmpeg trunk; see debian/
* Pass proper --cpu and --extra-flags on armel.
* Pass -fPIC -DPIC to neon pass.
-- Loic Minier <email address hidden> Tue, 13 Oct 2009 23:56:04 +0200
Changed in ffmpeg (Ubuntu): | |
status: | Confirmed → Fix Released |
Indeed, upstream has committed the attached patch. It probably makes sense to apply it to our branch then.
I still wonder if this change affects the ABI, though...