[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