Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CCSMB-14: Stereo television #29

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions Standards/CCSMB-14.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# *CCSMB 14:* Stereo television

*Author: @WindClan*
*Version: v1.0*
*Last updated: 2024-06-22*

## Both:
BIMG video should be at least 57x38 characters (resolution of a 3x3 monitor) and no more than 20 fps.

The only requirement for the video is that it can be decoded without hogging server resources

## Server:
Videos should either be in BIMG but other formats do not break compliance as long as they are marked in "type" to avoid issues with clients and there is an open-source encoder and decoder
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is too loose to even be considered a standard


an example of this would be [PBB](https://raw.githubusercontent.com/craftytv/pigutv/main/pbbconverter.py) which is supported in the example server

High framerate broadcasts in BIMG should only use the default CraftOS pallete or a static pallete that doesn't change

Each frame of video should have enough audio to last the entire frame and no more
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And how about it being shorter than the frame, is that compliant. Also, "should" shouldnt be used here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And how about it being shorter than the frame, is that compliant.

No, i forgot to mention that


Each packet sent from the server most have "protocol" set to "stereovideo"

Each packet should have metadata for the TV broadcast
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the available metadata fields and its types?


An optional feature that packets can have is subtitles by including a `subtitles` index in a frame

An example of a compliant server is [here](https://github.com/craftytv/television/tree/main/channel)

Example of a packet:
```lua
{
protocol = "stereovideo", -- Always stereo video
type = broadcastType, -- Image format (BIMG, etc.) SHOULD BE ALL LOWERCASE
audio = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to create "similar" protocols, consider looking at CCSMB-5's way of implementing channels,
audio[1] would be left,
audio[2] would be right,
audio[3-8] would be self assigned

left = leftbuffer, -- Decoded PCM, left channel
right = rightbuffer -- Decoded PCM, right channel
},
video = currentFrame, -- Either a frame of PBB or BIMG
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a default size or set of sizes? If so, which sizes.

subtitle = subtitle, --Subtitles is avaliable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about framerate, how fast should the video be played back? Should it be inferred from the size of the frame data? If so, which way?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Framerate is determined by how fast the packets are received
Ive tested with 20fps and 1fps

meta = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider renaming this to metadata

name = station, --TV station name
title = program, --What the name of the video is
owner = owner --Owner of the TV station
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternative channels? Should they be supported or should one broadcast always be limited to one channel

}
```

## Client:
Clients should be able to display BIMG and avoid incompatible formats to prevent any issues
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Should" again shouldnt be used here


Supporting formats other than BIMG does not break compliance as long as there is an open-source encoder and decoder
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted before, this seems too loose


Clients should be able to play stereo audio in-sync with the frames

Clients should be able to display subtitles by reading the "subtitles" metadata from each frame

Displaying metadata (ex. station and program) attached to broadcasts is optional

If the client supports multiple palletes, the client should be able to switch back to default pallete before changing broadcasts
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait so why is the single pallete limitation there then?


An example of a compliant client is [here](https://github.com/craftytv/television/tree/main/tuner)