Building Classroom: keeping feedback with the practice video

BR3AK is building Classroom for Breaking teachers and students. The intended workflow is straightforward: submit a practice video, get feedback attached to the moment it concerns, then bring that feedback into the next practice.

This entry brings together the development and test records from September 8–9 and the decisions that followed. The local prototype has working flows. Direct uploads to Google Drive are unfinished, and we do not yet have learning results from a real class.

What we want to find out

One instruction during development set the priority: find out whether the features actually improve how students learn Breaking.

That gives the first trial a concrete sequence. A teacher sets a skill and demonstration. A student submits a video. The teacher marks what needs attention. The student reviews it and submits another attempt. Software can keep that record; whether the student understands the feedback and improves needs to be checked in practice.

We also discussed supporting multiple teachers and charging for the service later. Subscriptions are outside this trial’s scope. Whether teachers and students keep using it, and whether the feedback helps, need evidence first.

A separate project for classroom.br3ak.com

The initial request was to add a Classroom menu item to BR3AK. The teaching application became a separate project, intended for classroom.br3ak.com, with the brand site providing the entry point.

Classroom uses Next.js, Payload and Better Auth. Local development uses SQLite; separate Neon resources have been prepared for cloud data. It does not use Supabase. Classes, students, videos and reviews belong to the teaching project, so it can be maintained and deployed separately from the brand site.

The brand navigation now includes a Classroom link. An entry point does not mean the teaching service is finished. This article records development before the full teacher-and-student trial.

Testing the player with Breaking footage

The local player supports slow playback, A–B loops and buttons that move backward or forward by 1/30 second. Teachers can draw lines and arrows and save comments at a video time. Selecting a comment returns to that moment and displays the saved annotation.

The review page can also load a teacher’s demonstration alongside the submission. Each submission retains the demonstration version it was made against, so replacing a demonstration does not change the reference for earlier work. Movement start times can be aligned manually; automatic alignment is not implemented.

The September 8 tests used two publicly licensed videos: Demonstration of a 2-step by VincaniTV and 2000 Powermove by gennmajella, both listed under CC BY 3.0. These were test materials, not student submissions. Their use does not imply that the creators participated in a Classroom trial.

Each clip was encoded three ways, followed by 120 seeks in a local browser. For these two short clips, an analysis copy with roughly half-second keyframe intervals gave seek performance close to the version that encoded every frame independently, with smaller files. That supported the initial encoding choice. Phone recordings and longer submissions still need testing.

The tests also found a specific bug. After pausing and stepping forward three times, the old synchronization logic could leave the comparison video about 100 milliseconds behind. After the fix, the review page showed both videos at 0.099999 seconds.

The button label matters too. Moving 1/30 second does not guarantee moving one source frame. The 2-step source runs at about 23.976 fps, so the interface still calls this time stepping. The source-frame index has not been connected to the player, and we cannot call it precise frame stepping yet.

Moving storage toward the teacher’s Google Drive

The first version included an R2 upload and FFmpeg processing pipeline, tested with a local storage substitute. The direction then changed: students should select a video inside Classroom and upload it into the teacher’s existing paid Google Drive space.

That affects the whole video flow. Teachers need to authorize Drive. Classes need the right storage destination. Uploaded videos need processing, playback and access rules for teachers and students. Passing the earlier R2 tests cannot verify any of that Drive integration.

A quicker interim option was discussed: students could upload to Drive manually and paste a link into Classroom. It was rejected. Direct upload inside Classroom remains a requirement, and it is still unfinished work before the trial.

One QR code for the whole class

Joining a class changed too. The original invitation was tied to a student’s email and could be used once. The chosen flow is now a shared class QR code: scan, sign in, request admission and wait for the teacher’s approval.

The teacher interface can generate the code, enlarge it, download a PNG, copy the link, rotate it or disable it. Applying does not grant class access; approval creates membership. Local browser testing covered a test student applying, a teacher approving and the student receiving the entry link. The downloaded image was also decoded to check its destination.

LINE became the primary sign-in method. Development included creating a dedicated LINE Login channel, applying for email access and recording a successful LINE notification after scanning its login QR code with a phone. The trial scope was subsequently narrowed to prioritize LINE login and defer the email fallback.

These are two different QR flows. LINE’s code authenticates a desktop login. Classroom’s class code takes a student to a class application. Success with the first does not verify the second on the production domain and a student’s phone. A class code pointing to local localhost also cannot connect a student’s phone to the development computer.

Working code still needs a real practice session

The local version has class creation, skills and prerequisites, video submissions, timed annotations, teacher reviews, subsequent skill access after approval, and attendance records. Together they form a prototype. Code checks and operation tests establish that the tested flows work.

The next steps are to finish direct Drive uploads, connect sign-in and class QR codes to the production address, and complete submission, playback and review on real phones. A teacher-and-student trial should then retain successive submissions for the same skill alongside the teacher’s feedback.

We want to observe whether students can identify what the teacher wants changed, whether their next attempt responds to that feedback, and where teachers have to explain the interface repeatedly. Those are questions for the trial. There are no results to report yet.

The next Classroom entry should be able to describe where a direct upload succeeded or failed, and how one submission travelled from a student’s phone to the teacher’s review page. Until then, the effect on learning remains untested.

This entry is based on the development conversation, implementation notes, video measurements and shared class QR test records. Local validation is not presented as cloud acceptance, and test accounts are not presented as real teachers or students in a trial.