[FFmpeg-trac] #3545(avformat:closed): Unsupported pix_fmts in avi rawvideo are written without any warning

FFmpeg trac at avcodec.org
Sat Apr 12 14:06:22 CEST 2014

#3545: Unsupported pix_fmts in avi rawvideo are written without any warning
             Reporter:  peter_b     |                    Owner:
                 Type:  defect      |                   Status:  closed
             Priority:  minor       |                Component:  avformat
              Version:  git-master  |               Resolution:  fixed
             Keywords:  avi mov     |               Blocked By:
             Blocking:              |  Reproduced by developer:  1
Analyzed by developer:  0           |

Comment (by cehoyos):

 Replying to [comment:6 peter_b]:
 > I see that for <=8bit, that depending on the output pix_fmt, a different
 FOURCC is automatically set when using rawvideo as codec. Since ffmpeg
 chooses the right FOURCC for <=8bit rawvideo,

 Only a (very) small set of <=8bit rawvideo work in avi, just try rgb24.

 > wouldn't it work to choose, for example fourcc=V210 for
 pix_fmt=yuv422p10le, etc?

 V210 != rawvideo (at least from the FFmpeg pov which is the one relevant
 for this ticket)
 This is fundamental to understand why this ticket cannot be "fixed" the
 way you hope...

 > [http://msdn.microsoft.com/en-
 us/library/windows/desktop/bb970578(v=vs.85).aspx#fourcc_codes On MSDN,
 there are FOURCCs listed for YUV 10 & 16bit]:
 > ||= FOURCC =||= Description =||
 > || P016 || Planar, 4:2:0, 16-bit. ||
 > || P010 || Planar, 4:2:0, 10-bit. ||
 > || P216 || Planar, 4:2:2, 16-bit. ||
 > || P210 || Planar, 4:2:2, 10-bit. ||
 > || Y216 || Packed, 4:2:2, 16-bit. ||
 > || Y210 || Packed, 4:2:2, 10-bit. ||
 > || Y416 || Packed, 4:4:4, 16-bit. ||
 > || Y410 || Packed, 4:4:4, 10-bit. ||

 If you can provide an avi sample for one of them that works with (vanilla)
 WMP, I will implement it.
 (I tried once and WMP did not like the files, rereading the link I agree
 it should work.)

 Please note that (for example) H.264 supports more colour spaces than the
 one listed on MSDN, so even if this gets implemented, there will still be
 files that you cannot archive like this,

 One more thing that is probably important for this discussion: FFmpeg's
 avi muxer handles large files badly, see various tickets on this tracker.
 Or in other words: If you really want to go the avi path (instead of the
 out-of-the-box working ffv1+audio+nut) then you will have to invest not
 just testing but also implementation time (the issues are known).

Ticket URL: <https://trac.ffmpeg.org/ticket/3545#comment:7>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list