Opened 5 years ago

Closed 2 years ago

#1869 closed enhancement (fixed)

Decode raw v210 streams

Reported by: ximmortal Owned by:
Priority: wish Component: avformat
Version: git-master Keywords: v210
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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.

Attachments (1)

test.mov (1.3 MB) - added by ximmortal 5 years ago.
MPEG4 compressed of unexpected output

Download all attachments as: .zip

Change History (15)

comment:1 follow-up: Changed 5 years ago by cehoyos

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

comment:2 in reply to: ↑ 1 Changed 5 years ago by 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

Changed 5 years ago by ximmortal

MPEG4 compressed of unexpected output

comment:3 Changed 5 years ago by cehoyos

  • Priority changed from normal to wish
  • Reproduced by developer set
  • Status changed from new to open
  • Summary changed from Create uncompressed v210 in any container to Decode raw v210 streams
  • Type changed from defect to enhancement

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?

comment:4 follow-up: Changed 5 years ago by cehoyos

  • Component changed from avcodec to avformat

comment:5 in reply to: ↑ 4 Changed 5 years ago by 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.

comment:6 follow-up: Changed 5 years ago by 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)

comment:7 follow-up: Changed 5 years ago by 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?

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).

comment:8 in reply to: ↑ 7 ; follow-up: Changed 5 years ago by 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.

comment:9 in reply to: ↑ 6 ; follow-up: Changed 5 years ago by 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.

comment:10 in reply to: ↑ 8 Changed 5 years ago by cehoyos

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, ...)

comment:11 in reply to: ↑ 9 Changed 5 years ago by richardpl

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.

comment:12 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed

This works now with the following command line:

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

comment:13 Changed 2 years ago by kierank

  • Resolution fixed deleted
  • Status changed from closed to reopened

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".

comment:14 Changed 2 years ago by kierank

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.