Decode raw v210 streams

[ximmortal]

Summary of the bug:
I am trying to use ffmpeg to contain a raw v210 sequence of images in a container. I've tried mov and avi, but both create a video that seems to shift the image around in quadrants. Hopefully I am just using the wrong command line option. It seems to me that the v210 is more of a pixel format than a "codec" which may be why I am getting the unexpected results. When I specify -vcodec v210 on the input, I notice that the ffmpeg statistics show only 333 frames processed (of which is really 500). I think it is getting to 333 because it is trying to read a frame expecting 16-bit per component for 4:2:2 which would be 8294400 bytes per frame of a 1920x1080 image, a v210 frame should be 5529600 bytes per frame for a 1920x1080 image.

How to reproduce:

% ffmpeg -s 1920x1080 -vcodec v210 -i ../x264-snapshot-20121026-2245/1920x1080_ducks_v210.yuv -vcodec copy test.mov
ffmpeg version N-46081-g5f9cbad Copyright (c) 2000-2012 the FFmpeg developers
  built on Oct 27 2012 15:14:01 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  configuration: --prefix=/home/shane/Development/ffmpeg
  libavutil      52.  1.100 / 52.  1.100
  libavcodec     54. 69.100 / 54. 69.100
  libavformat    54. 35.100 / 54. 35.100
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 20.106 /  3. 20.106
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 16.100 /  0. 16.100
[rawvideo @ 0x1f08480] Estimating duration from bitrate, this may be inaccurate
Input #0, rawvideo, from '../1920x1080_ducks_v210.yuv':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: v210, yuv422p10le, 1920x1080, 25 tbr, 25 tbn, 25 tbc
File 'test.mov' already exists. Overwrite ? [y/N] y
Output #0, mov, to 'test.mov':
  Metadata:
    encoder         : Lavf54.35.100
    Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le, 1920x1080, q=2-31, 12800 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
Truncating packet of size 8294400 to 7948801ime=00:00:12.96 bitrate=1660800.0kbits/s    
frame=  334 fps= 18 q=-1.0 Lsize= 2700003kB time=00:00:13.32 bitrate=1660542.6kbits/s    
video:2700000kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.000123%

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Carl Eugen Hoyos]

Please provide a sample, see ​http://ffmpeg.org/bugreports.html or upload to ​http://www.datafilehost.com/ and post the link here.

[ximmortal]

Replying to cehoyos:

Please provide a sample, see ​http://ffmpeg.org/bugreports.html or upload to ​http://www.datafilehost.com/ and post the link here.

Here is a 10 frame sample, ​http://www.datafilehost.com/download-6342b0c8.html

[ximmortal]

MPEG4 compressed of unexpected output

[Carl Eugen Hoyos]

Raw v210 streams are currently not supported (and this is not a regression), the rawvideo demuxer only works for codec rawvideo. Raw v210 image files are supported though.

How was your sample produced? Which software outputs such streams?

[ximmortal]

Replying to cehoyos:

The sample is the same format created by HD-SDI capture hardware produced by BlackMagic and DeltaCast framebuffer configured for V210. This format is the same as described by Apple:

​https://developer.apple.com/quicktime/icefloe/dispatch019.html

What is the V210 format that ffmpeg is expecting? I also observed an v210x codec, what is that for? I noticed that you changed the priority to wish... if this isn't a bug, rather a confusion over the v210 format, I would be happy to supply a patch to support the Apple V210 specification.

[Elon Musk]

Possible solution: extend libavformat/rawvideodec.c to support uncompressed codecs. (EASY)

Prefered solution: v210 (and others) should be moved to swscale where they belong. (HARD)

[Carl Eugen Hoyos]

Replying to ximmortal:

Replying to cehoyos:

The sample is the same format created by HD-SDI capture hardware produced by BlackMagic and DeltaCast framebuffer configured for V210.

Do the cards provide single frames or continuous streams?
The reason I ask is: Is there a software (or hardware) that provides the stream as you uploaded it or did you concatenate the frames?

This format is the same as described by Apple:

And usually Apple formats are muxed in mov, or does QuickTime support the stream you uploaded?

​https://developer.apple.com/quicktime/icefloe/dispatch019.html

What is the V210 format that ffmpeg is expecting?

The v210 decoder expects exactly the format you uploaded (you can test by changing the frame size in the rawvideo demuxer to the value you posted originally), but FFmpeg has no demuxer for it. The reason is that so far only v210 in mov was provided.

I also observed an v210x codec, what is that for?

​ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_exports/SVT_YUV10_Exports_/

I noticed that you changed the priority to wish... if this isn't a bug, rather a confusion over the v210 format, I would be happy to supply a patch to support the Apple V210 specification.

It is a missing feature in FFmpeg, the missing feature is not the Apple v210 specification (that is implemented and works fine afaict), but the way the frames are just concatenated (instead of either provided in a real container like avi and mov or as single frames).

[ximmortal]

Replying to cehoyos:

Replying to ximmortal:

Replying to cehoyos:

The sample is the same format created by HD-SDI capture hardware produced by BlackMagic and DeltaCast framebuffer configured for V210.

Do the cards provide single frames or continuous streams?
The reason I ask is: Is there a software (or hardware) that provides the stream as you uploaded it or did you concatenate the frames?

First, thanks for giving this your attention!

The card(s) provide on a frame basis, the concatenation was done by writing each frame successively to a file. I think the confusion comes from the fact that I am using these cards under Linux, thus the accompanied software is either non-existent or leaves much to be desired... I imagine the software that accompanies these cards on Windows or Mac produce the contained samples in .mov etc.

This format is the same as described by Apple:

And usually Apple formats are muxed in mov, or does QuickTime support the stream you uploaded?

I doubt that QuickTime supports any RAW/uncontained formats, but like I said, I'm on Linux :)

​https://developer.apple.com/quicktime/icefloe/dispatch019.html

What is the V210 format that ffmpeg is expecting?

The v210 decoder expects exactly the format you uploaded (you can test by changing the frame size in the rawvideo demuxer to the value you posted originally), but FFmpeg has no demuxer for it. The reason is that so far only v210 in mov was provided.

I also observed an v210x codec, what is that for?

​ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_exports/SVT_YUV10_Exports_/

I noticed that you changed the priority to wish... if this isn't a bug, rather a confusion over the v210 format, I would be happy to supply a patch to support the Apple V210 specification.

It is a missing feature in FFmpeg, the missing feature is not the Apple v210 specification (that is implemented and works fine afaict), but the way the frames are just concatenated (instead of either provided in a real container like avi and mov or as single frames).

I suppose that I was expecting it to function the same way as providing a concatenated sequence of UYVY pixels only 8-bit 4:2:2 (-s 1920x1080 -f rawvideo -pix_fmt uyvy422 -i input.yuv -vcodec copy output.avi) respectively (-s 1920x1080 -f rawvideo -pix_fmt v210 -i input.yuv -vcodec copy output.avi). The important thing here is to avoid losing bit resolution, worst case should be to represent the 10 bits in 16 bit space.

[ximmortal]

Replying to richardpl:

Possible solution: extend libavformat/rawvideodec.c to support uncompressed codecs. (EASY)

Prefered solution: v210 (and others) should be moved to swscale where they belong. (HARD)

I'll take a shot at the "easy" approach... :) Yes, there are other formats that I don't think ffmpeg currently supports v216, etc. If you all need any more high bit samples to test with, let me know.

[Carl Eugen Hoyos]

Replying to ximmortal:

Replying to cehoyos:

Replying to ximmortal:

Replying to cehoyos:

The sample is the same format created by HD-SDI capture hardware produced by BlackMagic and DeltaCast framebuffer configured for V210.

Do the cards provide single frames or continuous streams?
The reason I ask is: Is there a software (or hardware) that provides the stream as you uploaded it or did you concatenate the frames?

The card(s) provide on a frame basis, the concatenation was done by writing each frame successively to a file.

Please don't do that, ffmpeg can read the individual frames if you name them accordingly (image0001, image0002, ...)

[Elon Musk]

Replying to ximmortal:

Replying to richardpl:

Possible solution: extend libavformat/rawvideodec.c to support uncompressed codecs. (EASY)

Prefered solution: v210 (and others) should be moved to swscale where they belong. (HARD)

I'll take a shot at the "easy" approach... :) Yes, there are other formats that I don't think ffmpeg currently supports v216, etc. If you all need any more high bit samples to test with, let me know.

Please open new bug report for each format that ffmpeg does not currently supports and also please provide samples by either uploading here or link to them.

[Carl Eugen Hoyos]

This works now with the following command line:

$ ffmpeg -f image2pipe -vcodec v210 -s 1920x1080 -frame_size 5529600 -i 1920x1080_ducks_v210.yuv

[Kieran Kunhya]

This is still a bug IMO because FFmpeg should be able to calculate the value of 5529600 or whatever it should for each combination of width/height in a v210(x) "demuxer".

[Kieran Kunhya]

Fixed in 480bad7c6d087d9cd10ae4ab7b4e12cb594aa4c5