Opened 14 months ago

Last modified 14 months ago

#10577 new enhancement

add support for ay10 pixel format

Reported by: micolous Owned by:
Priority: normal Component: swscale
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by micolous)

ay10 is used by a bunch of ATEM video switchers for still image frames. It's a bit-packed (non-planar) variant of yuva422p10 (similar to y210?), where every two pixels are stored in two big-endian uint32s, with 4:2:2 subsampling:

(msb)2_ 10A 10U 10Y(lsb) (msb)2_ 10A 10V 10Y(lsb)

I will attach a sample frame to this ticket once created.

The frames don't come in any proper container format – but they are normally transferred with run-length encoding. I've unrolled the attached frame and compressed it in a more "traditional" format.

The naming is just what their software calls it. I don't work for Blackmagic Design, so I don't have any insight or influence into that. :)

I've attempted to write a patch for this (it's currently broken), which I'll also attach. Unfortunately, git send-email doesn't seem to work with OAuth2-authenticated IMAP/SMTP servers – it relies on application-specific passwords, which are an unacceptably-large security hole for 2023. :)

Attachments (4)

atem-colourbars5.expanded.bz2 (4.7 KB ) - added by micolous 14 months ago.
ay10 sample frame, 1920x1080 in (presumably) BT709 colour space
atem-colourbars5.expanded.png (28.3 KB ) - added by micolous 14 months ago.
PNG rendering of colourbars, crushed to 8bpp RGBA
0001-swscale-output-add-support-for-AY10BE-AY10LE-pixel-f.patch (8.1 KB ) - added by micolous 14 months ago.
0001-swscale-output-add-support-for-AY10BE-AY10LE-pixel-v2.patch (11.3 KB ) - added by micolous 14 months ago.

Download all attachments as: .zip

Change History (8)

by micolous, 14 months ago

ay10 sample frame, 1920x1080 in (presumably) BT709 colour space

by micolous, 14 months ago

PNG rendering of colourbars, crushed to 8bpp RGBA

comment:1 by micolous, 14 months ago

Attached PNG rendering was produced with that patch and:

ffmpeg -f rawvideo -pixel_format ay10be -colorspace bt709 -video_size 1920x1080 -i atem-colourbars5.expanded -pix_fmt rgba atem-colourbars5.'%03d'.png

Unfortunately, it appears my patch is broken for the reverse conversion. There's probably something I've missed:

% ./ffmpeg -i /tmp/atem-colourbars5.expanded.png -f rawvideo -pix_fmt ay10be -colorspace bt709 /tmp/atem-colourbars5.redux
ffmpeg version N-112139-g95b5c81729 Copyright (c) 2000-2023 the FFmpeg developers
  built with Apple clang version 15.0.0 (clang-1500.0.40.1)
  configuration:
  libavutil      58. 25.100 / 58. 25.100
  libavcodec     60. 26.100 / 60. 26.100
  libavformat    60. 13.100 / 60. 13.100
  libavdevice    60.  2.101 / 60.  2.101
  libavfilter     9. 11.100 /  9. 11.100
  libswscale      7.  3.100 /  7.  3.100
  libswresample   4. 11.100 /  4. 11.100
Input #0, png_pipe, from '/tmp/atem-colourbars5.expanded.png':
  Duration: N/A, bitrate: N/A
  Stream #0:0: Video: png, rgba(pc, gbr/unknown/unknown), 1920x1080, 25 fps, 25 tbr, 25 tbn
File '/tmp/atem-colourbars5.redux' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> rawvideo (native))
Press [q] to stop, [?] for help
zsh: segmentation fault  ./ffmpeg -i /tmp/atem-colourbars5.expanded.png -f rawvideo -pix_fmt ay10be
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000000000000
    frame #1: 0x000000010105bb38 ffmpeg`___lldb_unnamed_symbol23068 + 472
    frame #2: 0x000000010102ed71 ffmpeg`___lldb_unnamed_symbol22944 + 2801
    frame #3: 0x000000010102c771 ffmpeg`___lldb_unnamed_symbol22933 + 2129
    frame #4: 0x000000010102cc76 ffmpeg`ff_sws_slice_worker + 326
    frame #5: 0x00000001010c2e75 ffmpeg`avpriv_slicethread_execute + 245
    frame #6: 0x000000010102be1b ffmpeg`sws_receive_slice + 219
    frame #7: 0x000000010102cabb ffmpeg`sws_scale_frame + 171
    frame #8: 0x00000001002bdc17 ffmpeg`___lldb_unnamed_symbol12640 + 1639
    frame #9: 0x00000001000f47ef ffmpeg`ff_filter_activate + 1039
    frame #10: 0x00000001000f9a48 ffmpeg`av_buffersrc_add_frame_flags + 808
    frame #11: 0x0000000100010d67 ffmpeg`ifilter_send_frame + 839
    frame #12: 0x000000010000276f ffmpeg`dec_packet + 399
    frame #13: 0x000000010002b88d ffmpeg`___lldb_unnamed_symbol10166 + 61
    frame #14: 0x000000010002a532 ffmpeg`main + 4018
    frame #15: 0x00007ff80dd9341f dyld`start + 1903

There's probably "something obvious" I'm missing here.

comment:2 by micolous, 14 months ago

Description: modified (diff)

comment:3 by Balling, 14 months ago

We also still need NV61.

comment:4 by micolous, 14 months ago

I figured out what was wrong with my patch: I didn't implement the output format converter in ff_sws_init_output_funcs. I've uploaded a new version of the patch (v2), so this now appears to round-trip correctly with an ay10be raw frame:

ffmpeg -i /tmp/atem-colourbars5.expanded.png -f rawvideo -pix_fmt ay10be -colorspace bt709 /tmp/atem-colourbars5.redux
ffmpeg -f rawvideo -pixel_format ay10be -colorspace bt709 -video_size 1920x1080 -i /tmp/atem-colourbars5.redux -pix_fmt rgba /tmp/atem-colourbars-redux.'%03d'.png

ay10le also seems to round-trip correctly, and generates a different file.

Images with alpha channels appear to also work correctly.

Note: See TracTickets for help on using tickets.