[FFmpeg-trac] #2202(FFmpeg:open): -vcodec huffyuv and a .mov container produces colorful static
FFmpeg
trac at avcodec.org
Mon Jan 28 13:18:44 CET 2013
#2202: -vcodec huffyuv and a .mov container produces colorful static
-------------------------------------+-------------------------------------
Reporter: ulatekh | Owner:
Type: defect | Status: open
Priority: important | Component: FFmpeg
Version: git-master | Resolution:
Keywords: mov huffyuv | Blocked By:
ffvhuff regression | Reproduced by developer: 1
Blocking: |
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by nichot20):
Replying to [comment:6 cehoyos]:
> Replying to [comment:5 ulatekh]:
> > I eventually found three pixel formats that worked with raw video in a
.mov container -- rgb24, uyvy422, and rgb565. But ffmpeg would generate
files with other pixel formats, and then those files couldn't be decoded.
This is unhelpful and unproductive.
>
> This is correct and definitely a bug.
> But it is completely orthogonal to this regression.
> (I would expect that yuyv422, several 32bit rgb formats, gray16be and
rgb48be also work, if not this should be reported.)
Agreed! My issue is that since, AFAIK, only ffmpeg supports huffman in a
mov wrapper what should the behaviour be? I have looked at an example I
created from a uyvy422 source and the moov atom structure looks correct,
therefore do we regard the decoder as having an issue with mov's that
contain a valid fiel atom, or do we regard adding this atom in a huffman
codec context to be inappropriate? MY gut feeling is that the decoder
shouldn't barf when presented with a valid set of atoms.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2202#comment:7>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list