Opened 9 months ago

Last modified 9 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 9 months ago.
ay10 sample frame, 1920x1080 in (presumably) BT709 colour space
atem-colourbars5.expanded.png (28.3 KB ) - added by micolous 9 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 9 months ago.
0001-swscale-output-add-support-for-AY10BE-AY10LE-pixel-v2.patch (11.3 KB ) - added by micolous 9 months ago.

Download all attachments as: .zip

Change History (8)

by micolous, 9 months ago

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

by micolous, 9 months ago

PNG rendering of colourbars, crushed to 8bpp RGBA

comment:1 by micolous, 9 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, 9 months ago

Description: modified (diff)

comment:3 by Balling, 9 months ago

We also still need NV61.

comment:4 by micolous, 9 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.