Video Temporal Grounding

1.1 Introduction and Problem Statement

Video temporal grounding represents a fundamental challenge in computer vision and natural language processing, where the objective is to localize specific temporal segments within a video based on natural language queries. Given an untrimmed video and a textual description of an activity, the task requires the model to predict precise start and end timestamps that correspond to when the described event occurs in the video. This problem has significant applications in video retrieval, video summarization, human-computer interaction, and automated video editing systems. The complexity of this task stems from several factors. First, it requires understanding both visual content from video frames and semantic meaning from natural language descriptions. Second, the model must establish fine-grained temporal alignments between textual descriptions and visual events occurring at specific time intervals. Third, videos contain multiple concurrent or sequential activities, making it challenging to isolate the exact temporal boundaries of a single described event. Fourth, natural language descriptions can vary significantly in specificity, from broad activity descriptions to precise action sequences, requiring the model to handle diverse levels of semantic granularity. Traditional approaches to video understanding typically focus on either video classification (assigning labels to entire videos) or action recognition (detecting predefined action categories). However, temporal grounding demands a more sophisticated understanding that goes beyond simple categorization. The model must not only recognize what activity is happening but also determine exactly when it occurs within the video timeline. This temporal localization aspect makes the problem significantly more challenging than standard video classification tasks.

1.2 Project Architecture Overview

Our implementation addresses the temporal grounding problem through a multi-modal deep learning architecture that combines state-of-the-art visual and textual encoders with cross-modal fusion mechanisms. The system architecture consists of five primary components working in concert to achieve accurate temporal predictions.

Component 1: Video Encoder

The first component is the video encoder, which processes input video frames and extracts spatiotemporal features. We employ the Swin Transformer architecture, a hierarchical vision transformer that has demonstrated superior performance on various computer vision tasks. The Swin Transformer processes video frames through a series of shifted window attention mechanisms, capturing both local and global visual patterns while maintaining computational efficiency. For memory optimization in our constrained training environment, we utilize the Swin-Tiny variant, which balances model capacity with computational requirements.

Component 2: Text Encoder

The second component is the text encoder, responsible for converting natural language queries into semantic embeddings. We leverage BERT (Bidirectional Encoder Representations from Transformers), a pre-trained language model that has revolutionized natural language understanding tasks. BERT's bidirectional attention mechanism allows it to capture contextual relationships between words in both forward and backward directions, producing rich semantic representations of the query text.

Component 3: Projection Layers

The third component consists of projection layers that align the video and text features into a common embedding space. Since the Swin Transformer and BERT produce features in different dimensional spaces (768 dimensions for Swin-Tiny and 768 for BERT-base), we employ learned linear projections to map both modalities into a shared hidden dimension. This alignment is crucial for enabling effective cross-modal interaction in subsequent layers.

Component 4: Cross-Modal Fusion Module

The fourth component is the cross-modal fusion module, implemented as a transformer encoder that processes concatenated video and text features. This module employs multi-head self-attention mechanisms to model complex interactions between visual and textual information. The attention mechanism allows the model to identify which video frames are most relevant to specific words in the query, and conversely, which words best describe particular temporal segments.

Component 5: Temporal Grounding Head

The fifth and final component is the temporal grounding head, which predicts the start and end timestamps of the target event. This module processes the fused multi-modal features through a series of fully connected layers, ultimately producing two continuous values representing normalized temporal boundaries. The predictions are constrained to ensure logical consistency (start time must precede end time) and are normalized to the [0, 1] range to handle videos of varying durations.

1.3 Dataset Preparation and Annotation Processing

The foundation of any machine learning system lies in the quality and structure of its training data. Our project utilizes the Charades dataset, a large-scale dataset specifically designed for activity understanding in videos. It contains over 1,000 videos depicting everyday household activities, each annotated with multiple temporal segments corresponding to different actions. The initial data preparation phase involves parsing annotations from CSV files into a structured JSON format suitable for training. Original Charades annotations are provided in a compact CSV format where each row represents a video, and temporal annotations are encoded in a semicolon-separated action-timestamp format. For example, "c092 11.90 21.20;c147 0.00 12.60" indicates two activities with their respective start and end times. Our CSV parsing process performs several critical functions. First, it scans the video directory to enumerate all available videos, ensuring only existing videos are processed. Second, it loads training and testing CSV files using pandas, automatically detecting delimiters to ensure robust parsing. Third, the parser implements an action-to-description mapping system, converting Charades action codes (e.g., 'c092' for 'Cooking something') into human-readable descriptions for model training. Fourth, the parser extracts video duration information by calculating the length based on frame count and frame rate, enabling normalization of timestamps to relative positions (0 to 1). Fifth, the system creates a train-validation-test split with no data leakage by combining and shuffling annotations with a fixed seed, then splitting 70% training, 15% validation, and 15% testing at the video level. The output of this data preparation phase is three JSON files, each containing video annotations. Each annotation object includes the video ID, duration in seconds, and a list of temporal segments with their corresponding natural language descriptions. This structured format enables efficient data loading during training and provides a clear interface between the data processing pipeline and the model architecture.

1.4 Environmental Setup and Dependencies

The project requires a carefully orchestrated set of software dependencies to function correctly. The first cell in our implementation handles the installation of packages that are not pre-installed in the Kaggle environment. While Kaggle provides many common deep learning libraries by default (PyTorch, transformers, OpenCV, pandas), specialized packages like timm (PyTorch Image Models) and einops (tensor manipulation utilities) must be installed explicitly. The timm library provides access to state-of-the-art computer vision models, including our Swin Transformer implementation. It offers pre-trained weights that have been trained on large-scale image datasets like ImageNet, giving our model a strong initialization point that significantly accelerates convergence and improves final performance. The einops library provides elegant tensor manipulation operations that make complex reshaping and dimension rearrangements more readable and less error-prone. The second cell imports all necessary libraries and sets up the computational environment. We configure the device (GPU or CPU) for computation, with automatic detection of CUDA availability. GPU acceleration is essential for this project, as training on CPU would take prohibitively long. We also set random seeds for PyTorch, NumPy, and CUDA operations to ensure reproducibility across different runs. This reproducibility is crucial for scientific validity and debugging purposes. Additionally, we configure warning filters and logging levels to suppress unnecessary output from TensorFlow (which may be present in the environment) and other libraries. This cleanup improves the readability of training logs and makes it easier to identify genuine errors or important messages during execution. The setup phase concludes with a confirmation message indicating successful initialization, providing users with immediate feedback that the environment is correctly configured and ready for training.

2.1 Hyperparameter Configuration and Model Settings

Cell 3 establishes the comprehensive configuration framework that governs all aspects of model architecture, training procedures, and data processing. This centralized configuration approach follows software engineering best practices, making the system more maintainable and enabling systematic hyperparameter exploration. The configuration is encapsulated in a Config class that serves as a single source of truth for all experimental parameters. The path configuration specifies the locations of video files and annotation JSON files. For Kaggle deployment, these paths point to the /kaggle/input/ directory for read-only data and /kaggle/working/ for generated annotations. This separation between input data and generated files aligns with Kaggle's file system architecture, where input datasets are mounted as read-only volumes while the working directory provides writable storage for outputs and checkpoints. Video processing parameters determine how raw video files are converted into tensor representations suitable for neural network processing. The num_frames parameter, set to 8, specifies how many frames are sampled from each video. This value represents a critical trade-off: more frames provide richer temporal information and better capture activity dynamics, but they also increase memory consumption and computational cost proportionally. Eight frames proved to be an optimal balance for our hardware constraints (Kaggle's T4 GPU with 15GB memory) while still capturing sufficient temporal context for activity recognition. The img_size parameter of 224x224 pixels matches the input dimensions expected by the Swin Transformer architecture. This resolution is standard in computer vision and represents another balance between detail preservation and computational efficiency. Higher resolutions would capture finer visual details but would dramatically increase memory requirements and processing time. The fps parameter of 4 frames per second indicates the sampling rate for video processing, though in practice we use uniform sampling across the video duration rather than strict FPS-based sampling. Model architecture parameters define the structure and capacity of the neural network. The video_embed_dim and text_embed_dim of 768 dimensions reflect the output dimensions of Swin-Tiny and BERT-base respectively. These pre-trained models have fixed output dimensions that we must accommodate. The hidden_dim of 256 represents a significant compression from the original 768 dimensions, serving two purposes: reducing memory consumption and forcing the model to learn more compact, generalizable representations. The num_heads parameter of 8 specifies the number of attention heads in the cross-modal fusion transformer. Multi-head attention allows the model to attend to different aspects of the input simultaneously, with each head potentially specializing in different types of visual-textual correspondences. Eight heads provide sufficient diversity while keeping computational costs manageable. The num_layers parameter of 2 determines the depth of the transformer encoder used for fusion. Deeper networks can model more complex relationships but are also more prone to overfitting and require more data and training time. Training parameters control the optimization process. The batch_size of 2 is deliberately small, constrained by GPU memory limitations. With frozen encoders and optimized data loading, we can process two video-query pairs simultaneously. Larger batch sizes would provide more stable gradient estimates and potentially faster convergence, but would exceed our memory budget. The num_epochs of 50 provides sufficient iterations for the model to converge while avoiding excessive training time. The learning_rate of 1e-4 is a conservative choice that promotes stable training, while the weight_decay of 1e-5 provides modest L2 regularization to prevent overfitting. Loss function weights (lambda_iou and lambda_l1) determine the relative importance of different loss components. Setting both to 1.0 treats the Extended IoU loss and L1 regression loss as equally important. These weights could be tuned based on validation performance, but equal weighting provides a reasonable starting point. The max_text_len of 32 tokens limits the length of text queries processed by BERT, sufficient for the typically concise action descriptions in the Charades dataset.

2.2 Video Loading and Preprocessing Pipeline

Cell 4 implements the critical video loading and preprocessing functions that transform raw video files into tensor representations suitable for neural network processing. The load_video function is the workhorse of this cell, handling all aspects of video reading, frame extraction, and temporal sampling. The function begins by opening the video file using OpenCV's VideoCapture interface, which provides a robust cross-platform API for video I/O operations. After successfully opening the video, it queries metadata including total frame count, frames per second, and computes the video duration. This duration information is essential for normalizing timestamp predictions and is returned alongside the frame data. Frame sampling employs a uniform temporal sampling strategy designed to capture the full temporal extent of the video while maintaining a fixed number of frames. If the video contains fewer frames than requested (a rare edge case), the function pads by repeating the final frame. For typical videos with more frames than needed, it uses NumPy's linspace function to compute evenly spaced frame indices across the video's duration. This uniform sampling ensures that the model receives temporal coverage of the entire video regardless of its length. For each selected frame index, the function seeks to the appropriate position in the video and reads the frame. OpenCV reads frames in BGR color format, which we immediately convert to RGB to match the expected input format of the Swin Transformer (trained on RGB images). Each frame is then resized to 224x224 pixels using bilinear interpolation, maintaining aspect ratio by center-cropping if necessary. This resizing is a lossy operation that discards some visual information, but it's necessary to meet the input requirements of the pre-trained vision transformer. Error handling is implemented throughout the frame reading loop. If a particular frame cannot be read (due to video corruption or seeking errors), the function falls back to using the previous valid frame. This graceful degradation ensures that the training pipeline doesn't crash due to minor video file issues, which are not uncommon in large-scale datasets. If no valid frames can be read at all, the function generates a black frame as a last resort, allowing training to continue even with problematic video files. The get_transform function creates the image preprocessing pipeline required to convert raw pixel values into the normalized tensor format expected by neural networks. This pipeline is implemented using PyTorch's torchvision.transforms module, which provides efficient, GPU-compatible image transformations. The pipeline first converts NumPy arrays to PIL images, then to PyTorch tensors, and finally applies ImageNet normalization statistics (mean and standard deviation for each color channel). This normalization is crucial because the Swin Transformer was pre-trained on ImageNet data that was normalized in this way, and using different normalization would severely degrade performance.

2.3 Dataset Implementation and Batch Construction

Cell 5 defines the CharadesDataset class, a PyTorch Dataset subclass that encapsulates all logic for loading, processing, and serving data samples during training. This class follows PyTorch's dataset API conventions, implementing the required __len__ and __getitem__ methods that enable seamless integration with PyTorch's DataLoader for efficient batching and multi-threaded data loading. The constructor performs several initialization tasks. It stores references to essential components including the video directory path, BERT tokenizer, configuration object, and image transformation pipeline. It then loads the annotation JSON file and flattens its structure to create a list where each element represents a single (video, query, timestamp) tuple. This flattening is necessary because the JSON file is organized by video, with each video containing multiple annotations, but we want to train on individual query instances. The flattening process expands videos with multiple annotations into multiple training samples. The __len__ method simply returns the number of samples, enabling PyTorch's DataLoader to determine how many batches to create per epoch. The __getitem__ method implements the core data loading logic executed for each sample. Given an index, it retrieves the corresponding sample metadata, constructs the video file path, and loads the video frames using the previously defined load_video function. Each frame is then transformed using the image preprocessing pipeline, and the results are stacked into a 4D tensor with shape (num_frames, channels, height, width). Text processing involves tokenizing the natural language query using the BERT tokenizer. The tokenizer converts the text string into a sequence of token IDs, with special tokens ([CLS] at the start, [SEP] at the end) that BERT requires. Padding is applied to ensure all sequences have the same length (max_text_len), and attention masks are generated to indicate which positions contain real tokens versus padding. This attention mask is crucial for the transformer's attention mechanism to ignore padding tokens. Timestamp normalization is a critical preprocessing step. The raw timestamps in the annotations are in absolute seconds, but we need to normalize them to the [0, 1] range to make them independent of video duration. This normalization is achieved by dividing both start and end times by the video's duration. Normalized timestamps enable the model to learn temporal localization in a scale-invariant manner, improving generalization across videos of different lengths. The method returns a dictionary containing all processed data: the video tensor, tokenized text (input_ids and attention_mask), normalized timestamps, original duration (for evaluation), video ID, and the original sentence. This dictionary structure provides flexibility and clarity, making it easy to access specific data elements during training and debugging. The inclusion of metadata like video_id and sentence is particularly useful for qualitative analysis and error investigation during model development.

3.1 Video Encoder: Swin Transformer Implementation

Cell 6 implements the VideoEncoder class, which serves as the visual feature extraction backbone of our temporal grounding system. The architecture is built upon the Swin Transformer, a hierarchical vision transformer that has demonstrated state-of-the-art performance across various computer vision benchmarks. Unlike traditional convolutional neural networks, transformers process images as sequences of patches and employ self-attention mechanisms to model long-range dependencies. The constructor initializes a Swin-Tiny model using the timm library's create_model function with pretrained=True, loading weights trained on ImageNet. These pre-trained weights encode general visual knowledge learned from millions of images, providing our model with a strong initialization that dramatically accelerates training and improves final performance. The Swin-Tiny variant was specifically chosen for its balance between model capacity (28 million parameters) and memory efficiency, making it suitable for training on consumer-grade GPUs. We remove the original classification head by replacing it with an Identity layer, as we don't need ImageNet class predictions. The Swin-Tiny model outputs feature vectors of dimension 768, which we project to our chosen hidden dimension. Critically, we freeze all Swin Transformer parameters by setting requires_grad=False for all weights. This freezing strategy serves multiple purposes: it dramatically reduces memory consumption during backpropagation (as we don't need to store activations for frozen layers), prevents catastrophic forgetting of the pre-trained features, and reduces the number of trainable parameters to prevent overfitting on our relatively small dataset. The forward method processes batches of video frames through several transformation steps. Input videos arrive with shape (batch_size, num_frames, channels, height, width), where each video is represented as a sequence of RGB frames. We reshape this 5D tensor into a 4D tensor by merging the batch and frame dimensions, resulting in (batch_size × num_frames, channels, height, width). This reshaping allows us to process all frames from all videos in a single batch through the Swin Transformer, which expects 4D input. The Swin Transformer processes frames through its forward_features method rather than the standard forward method. This distinction is important: forward_features returns spatial feature maps before global pooling, while forward applies pooling and classification. Since we need frame-level features, we use forward_features. The output shape depends on the internal architecture of Swin-Tiny and may be 3D (batch, num_patches, channels) or 4D (batch, height, width, channels). To handle this variability, we implement adaptive pooling logic. If the output is 4D spatial features, we permute dimensions and apply mean pooling across spatial dimensions to obtain a single feature vector per frame. If the output is already 3D (pre-pooled), we apply mean pooling across the patch dimension. This flexibility ensures our code works correctly regardless of the specific Swin implementation details. The torch.no_grad() context manager around the Swin forward pass further reduces memory usage by preventing gradient computation for frozen parameters. Finally, we apply a learned linear projection to map the 768-dimensional Swin features to our hidden dimension of 256. This projection layer is trainable (not frozen) and serves multiple purposes: dimension reduction for memory efficiency, learned adaptation of pre-trained features to our specific task, and alignment with the text feature dimension for cross-modal fusion. The output is reshaped back to separate batch and frame dimensions, yielding (batch_size, num_frames, hidden_dim).

3.2 Text Encoder: BERT-based Language Understanding

Cell 7 implements the TextEncoder class, responsible for converting natural language queries into semantic vector representations. We employ BERT (Bidirectional Encoder Representations from Transformers), a transformer-based language model that has revolutionized natural language processing through its powerful contextualized word representations. The constructor loads the pre-trained BERT-base-uncased model from Hugging Face's transformers library. The "uncased" variant treats all text as lowercase, reducing vocabulary size and improving generalization for casual text. BERT-base contains 12 transformer layers, 768 hidden dimensions, and 110 million parameters, making it substantially larger than our visual encoder. Like the Swin Transformer, we freeze all BERT parameters to leverage pre-trained linguistic knowledge while avoiding overfitting and reducing memory requirements. The forward method processes tokenized text through BERT's layers. Input consists of token IDs (integer indices into BERT's vocabulary) and attention masks (binary masks indicating real tokens versus padding). BERT's architecture includes positional embeddings (encoding token positions), token embeddings (encoding token identities), and segment embeddings (for sentence pair tasks, unused here). These embeddings sum to form the input to BERT's transformer layers. BERT processes input through 12 layers of multi-head self-attention and feed-forward networks. Each attention layer computes relationships between all pairs of tokens in the sequence, allowing the model to capture complex linguistic phenomena like anaphora resolution, semantic role labeling, and compositional meaning. The bidirectional nature of attention (tokens attend to both preceding and following tokens) enables richer representations than left-to-right language models. The method returns two types of outputs: sequence-level embeddings (one vector per token) and a pooled sentence-level embedding (single vector for the entire query). The sequence output has shape (batch_size, max_length, 768) and captures word-level semantics useful for fine-grained alignment with video frames. The pooled output, derived from the [CLS] token's final hidden state, provides a holistic sentence representation useful for high-level matching. Both outputs pass through a trainable linear projection that maps from BERT's 768 dimensions to our hidden dimension of 256. This projection serves similar purposes as the video projection: dimension reduction, task-specific adaptation, and alignment with video features. The torch.no_grad() context around BERT's forward pass prevents gradient computation, reducing memory usage by approximately 60% compared to fine-tuning BERT.

3.3 Cross-Modal Fusion Through Transformer Architecture

Cell 8 implements the CrossModalFusion module, arguably the most critical component for temporal grounding as it establishes correspondences between visual content and textual descriptions. This module employs a transformer encoder to process concatenated video and text features, enabling attention-based interaction between modalities. The constructor creates a transformer encoder using PyTorch's nn.TransformerEncoder with configurable depth (num_layers) and attention heads (num_heads). We use 2 layers and 8 attention heads, providing sufficient model capacity while maintaining computational efficiency. Each transformer layer consists of multi-head self-attention followed by position-wise feed-forward networks, with residual connections and layer normalization promoting training stability. The key innovation is processing concatenated video and text features jointly. We concatenate features along the sequence dimension, creating a unified sequence of length (num_frames + text_length). This concatenation allows the transformer's self-attention mechanism to compute attention weights between all pairs of video frames and text tokens, enabling the model to learn which frames correspond to which words. Positional encoding is crucial for transformers, which otherwise have no notion of sequence order. Our PositionalEncoding class implements the sinusoidal encoding scheme from "Attention is All You Need." This encoding adds position-dependent patterns to the input features, allowing the model to distinguish between different temporal positions in the video and different word positions in the query. The dropout applied to positional encodings provides additional regularization. The forward method handles attention masking carefully. For text tokens, we use the attention_mask provided by BERT's tokenizer, which marks padding tokens. For video frames, we create an all-ones mask since all frames are valid (no padding). The combined mask ensures that attention computations ignore padding tokens, preventing the model from learning spurious patterns from padding. The mask is converted to PyTorch's expected format where True indicates positions to ignore. The transformer encoder processes the unified sequence through multiple layers of self-attention. In each layer, the multi-head attention mechanism computes attention weights between all pairs of elements (frames and tokens). These attention patterns implicitly learn alignments: which video frames are relevant for each word, and which words best describe each temporal segment. The output maintains the same shape as the input, (batch_size, num_frames + text_length, hidden_dim), with each position's representation informed by all other positions through attention.

3.4 Temporal Grounding Head and Timestamp Prediction

Cell 9 implements the TemporalGroundingHead, the final module that converts fused multi-modal features into concrete temporal predictions. This component faces the challenge of mapping high-dimensional feature representations to two scalar values (start and end times) that must satisfy temporal constraints. The architecture employs a multi-layer perceptron (MLP) with progressive dimensionality reduction. The first linear layer maps from hidden_dim to itself, allowing the network to learn complex non-linear transformations of the fused features. ReLU activation introduces non-linearity, enabling the model to learn complex decision boundaries. Dropout provides regularization by randomly zeroing activations during training, preventing overfitting. The second layer reduces dimensionality to hidden_dim/2, creating a bottleneck that forces the model to compress information into a more compact representation. This compression can improve generalization by preventing the model from memorizing training examples. Another ReLU and dropout follow, maintaining non-linearity and regularization. The final layer projects to dimension 2, producing raw timestamp predictions. A sigmoid activation constrains predictions to the [0, 1] range, ensuring they represent valid normalized timestamps. However, sigmoid alone doesn't guarantee temporal ordering (start before end). To enforce this constraint, we implement explicit logic that computes minimum and maximum of the two predictions, ensuring the output always respects start ≤ end. This hard constraint prevents the model from making logically inconsistent predictions. The forward method implements temporal pooling before prediction. Rather than using the entire fused sequence, we extract only the video portion (first num_frames elements) and apply mean pooling across frames. This pooling aggregates temporal information into a single vector that represents the video holistically. Global pooling has proven effective for temporal localization tasks, as it allows the model to consider the full temporal context when predicting boundaries. The complete prediction pipeline thus follows: fused multi-modal features → extract video features → global average pooling → MLP with bottleneck → sigmoid activation → temporal ordering constraint → normalized timestamps. This architecture balances expressiveness (through non-linear transformations) with constraints (through activation functions and explicit ordering logic), producing predictions that are both accurate and logically valid.

4.1 Complete Model Integration and Forward Pass

Cell 10 implements the VideoTemporalGroundingModel class, which integrates all previously defined components into a unified end-to-end architecture. This top-level class orchestrates the flow of data through the entire pipeline, from raw video frames and text to final timestamp predictions. The constructor initializes all sub-modules with appropriate configurations. The video encoder (Swin Transformer) and text encoder (BERT) are created with their projection layers to map features to the common hidden dimension. The cross-modal fusion transformer is instantiated with the specified number of layers and attention heads. Finally, the temporal grounding head is created with knowledge of the expected input dimension and number of frames. All components are stored as module attributes, allowing PyTorch to automatically track parameters and handle device placement. The forward method implements the complete inference pipeline. It begins by processing video input through the video encoder, which extracts frame-level features and projects them to the hidden dimension. Simultaneously, text input passes through the BERT encoder and its projection layer, producing token-level semantic embeddings. Both encoders operate independently at this stage, with no interaction between modalities. Cross-modal fusion occurs next, where video and text features are concatenated and processed through the transformer encoder. This stage is critical for establishing correspondences between visual content and textual descriptions. The transformer's self-attention mechanism computes relevance scores between all pairs of video frames and text tokens, allowing the model to identify which frames correspond to which words. Through multiple transformer layers, these correspondences become increasingly refined, capturing complex semantic alignments. The fused features then pass to the temporal grounding head, which aggregates information through global pooling and predicts normalized timestamps via the MLP. The entire forward pass is differentiable, enabling end-to-end training through backpropagation. During training, gradients flow backward from the loss function through all components, with frozen encoder weights remaining unchanged while projection layers, fusion transformer, and grounding head adapt to minimize prediction error.

4.2 Extended IoU Loss and Evaluation Metrics

Cell 11 implements the loss functions that guide model optimization. The choice of loss function is crucial for temporal grounding, as it directly influences what the model learns to optimize. We employ Extended Intersection over Union (EIoU) loss, specifically designed for temporal localization tasks. The calculate_iou function computes intersection over union between predicted and ground truth temporal intervals. IoU is defined as the ratio of intersection length to union length, measuring the overlap between predicted and true temporal segments. For perfect predictions, IoU equals 1.0; for non-overlapping predictions, IoU equals 0.0. Values between 0 and 1 indicate partial overlap, with higher values representing better localization. Computing IoU involves several steps. First, we find the intersection by taking the maximum of start times and minimum of end times. If the result is invalid (intersection end before intersection start), we clamp to zero indicating no overlap. Second, we compute the union as the sum of both interval lengths minus their intersection (to avoid double-counting overlap). Finally, IoU is calculated as intersection divided by union, with a small epsilon added to the denominator to prevent division by zero. The eiou_loss function extends standard IoU loss with additional penalty terms. Pure IoU loss (1 - IoU) provides a good measure of temporal overlap but can suffer from gradient issues when predictions have zero overlap with ground truth. EIoU addresses this by adding two supplementary losses: center distance penalty and width difference penalty. The center distance penalty encourages predicted intervals to have centers near the ground truth center, even when there's no overlap. This provides useful gradient signal when predictions are far from the target, helping the model converge from poor initializations. The width difference penalty encourages predicted intervals to have similar duration to ground truth, preventing the model from predicting excessively long or short intervals to game the IoU metric. The compute_loss function combines EIoU loss with L1 (mean absolute error) loss. L1 loss provides direct supervision on the timestamp values themselves, complementing the interval-based EIoU loss. The combination of losses addresses different aspects of temporal localization: EIoU focuses on interval overlap while L1 focuses on exact timestamp accuracy. Weighted combination (via lambda_iou and lambda_l1) allows balancing these objectives during training.

4.3 Training Loop Implementation and Epoch Processing

Cell 12 implements the core training and validation procedures that drive model learning. The train_epoch function encapsulates the logic for a single training epoch, processing all training batches and updating model parameters based on computed gradients. The training loop iterates over batches provided by the DataLoader, which handles shuffling, batching, and multi-threaded data loading. For each batch, we transfer data to the GPU device for efficient computation. The model forward pass computes predictions given the current weights. The compute_loss function evaluates how well these predictions match ground truth, producing loss values that quantify prediction quality. Backpropagation begins with optimizer.zero_grad(), which resets accumulated gradients from the previous iteration. We then call loss.backward(), which computes gradients of the loss with respect to all trainable parameters through automatic differentiation. PyTorch's autograd system traces all operations performed during the forward pass and applies the chain rule in reverse order to compute gradients. Gradient clipping prevents exploding gradients, a common issue in deep networks where gradient magnitudes can grow exponentially through many layers. We clip gradients to a maximum norm of 1.0, scaling them down proportionally if they exceed this threshold. This clipping stabilizes training and prevents occasional extreme updates that could destabilize the optimization process. The optimizer.step() call updates model parameters using the computed gradients. We use AdamW (Adam with decoupled weight decay), an adaptive learning rate optimizer that maintains per-parameter learning rates based on gradient history. AdamW's adaptive rates help navigate complex loss landscapes efficiently, converging faster than simple SGD while being more robust to hyperparameter choices. After each batch, we accumulate loss statistics for monitoring and clear GPU memory to prevent memory leaks. The progress bar updates in real-time, providing immediate feedback on training progress and loss values. At epoch end, we compute and return average losses across all batches, enabling tracking of training curves over time. The validate function implements similar logic for validation data, with key differences. We set the model to eval mode (disabling dropout and batch normalization training behavior) and wrap computations in torch.no_grad() to disable gradient computation, reducing memory usage. We also compute IoU metrics for evaluation, providing additional insight beyond loss values. Validation occurs after each training epoch, allowing us to monitor generalization performance and detect overfitting.

4.4 Model Initialization and Optimization Configuration

Cell 13 brings together all components for training initialization. It creates dataset instances for training and validation splits, instantiates DataLoader objects with appropriate batching and multi-threading settings, and initializes the model architecture. The use of persistent_workers in DataLoader keeps data loading processes alive between epochs, reducing the overhead of process spawning. We initialize the complete VideoTemporalGroundingModel and move it to the GPU device. The model's parameters are then counted and reported, distinguishing between total parameters (including frozen encoders) and trainable parameters (only projection layers, fusion transformer, and grounding head). This distinction is important for understanding model capacity and memory requirements. The AdamW optimizer is configured with learning rate 1e-4 and weight decay 1e-5. The learning rate represents the step size for parameter updates and must be carefully chosen: too large causes instability and divergence, too small causes slow convergence. Weight decay provides L2 regularization, adding a penalty term proportional to parameter magnitudes to the loss function. This encourages the model to prefer simpler solutions (smaller weights), improving generalization. We also configure a learning rate scheduler (ReduceLROnPlateau) that monitors validation loss and reduces the learning rate when progress stalls. This adaptive learning rate helps overcome plateaus where the model stops improving: reducing the learning rate allows finer-grained updates that can navigate difficult regions of the loss landscape. The scheduler's patience parameter (5 epochs) determines how long to wait before reducing the rate, preventing premature reductions from temporary fluctuations.

4.5 Main Training Loop and Checkpoint Management

Cell 14 implements the main training loop that orchestrates the entire training process across multiple epochs. This loop serves as the central control flow, coordinating training epochs, validation evaluations, learning rate adjustments, and model checkpointing. The training loop initializes a history dictionary to track all metrics across epochs, enabling post-training analysis and visualization. We also initialize best validation loss tracking for checkpoint management: we save the model only when it achieves better validation performance than all previous epochs, ensuring we preserve the best-performing version. Each epoch begins with a status message indicating progress. We then execute one complete training epoch by calling train_epoch, which processes all training batches and updates model weights. Upon completion, we evaluate on validation data via the validate function, computing validation loss and IoU metrics without updating weights. The learning rate scheduler examines validation loss and potentially reduces the learning rate if progress has stalled. All computed metrics (training and validation losses, IoU scores) are appended to the history dictionary and printed for monitoring. We implement comprehensive checkpointing that saves not only model weights but also optimizer state, scheduler state, configuration, and training history. This complete checkpoint enables full training resumption if interrupted, critical for long-running experiments on systems with time limits. Best model checkpointing compares current validation loss to the historical minimum. If the current epoch achieves the best validation performance seen so far, we save a checkpoint and update the best loss tracker. This strategy ensures we preserve the model's best state, even if later epochs overfit and achieve worse validation performance. Additionally, we implement periodic checkpointing every 5 epochs regardless of performance, providing fallback recovery points if the system crashes. Memory management is crucial for long training runs. After each epoch, we explicitly call torch.cuda.empty_cache() to clear unused GPU memory, preventing gradual memory accumulation from tensor fragmentation. We also track and display elapsed time, helping users estimate remaining training time and plan resource usage. The training loop concludes by reporting total training time and best validation loss, providing summary statistics for the complete training run.

5.1 Training Progress Visualization and Convergence Analysis

Cell 15 implements comprehensive visualization of training dynamics through matplotlib plotting. Understanding training behavior is crucial for diagnosing issues, validating convergence, and making informed decisions about hyperparameter tuning. The plot_training_history function creates a multi-panel figure that captures different aspects of the learning process. The first panel displays training and validation loss curves over epochs. These curves are the primary indicators of model learning and generalization. Ideally, both curves should decrease monotonically, with training loss lower than validation loss due to the model seeing training data during optimization. The gap between curves indicates overfitting severity: larger gaps suggest the model is memorizing training data rather than learning generalizable patterns. In our case, with frozen encoders and limited trainable parameters, this gap remains modest, indicating healthy generalization. The second panel shows EIoU loss specifically, separating this component from the total loss. EIoU loss captures temporal localization quality directly, making it particularly interpretable for our task. Monitoring EIoU separately from total loss helps diagnose whether improvements come from better interval overlap or from the L1 component. If EIoU decreases while total loss stagnates, it suggests the L1 term is hindering optimization, potentially warranting rebalancing of loss weights. The third panel displays L1 loss evolution, showing how precisely the model predicts exact timestamp values. L1 loss provides complementary information to EIoU: a model might achieve high IoU while being slightly off in absolute timestamps, or achieve low L1 error while producing poorly overlapping intervals. Monitoring both components ensures we optimize for the right objective balance. The fourth panel plots validation IoU (the inverse of IoU loss), directly measuring prediction quality in the [0, 1] range where 1.0 represents perfect overlap. This metric is more intuitive than loss values and directly corresponds to the evaluation metric used in temporal grounding benchmarks. Stable or increasing validation IoU indicates the model is learning meaningful temporal localization patterns rather than overfitting to training data. The visualization is saved at high resolution (300 DPI) for publication quality, enabling inclusion in research papers or technical reports. The function also prints summary statistics including final metrics and best values, providing quantitative assessment alongside qualitative visual analysis. These combined insights enable informed decisions about training continuation, hyperparameter adjustment, or architecture modifications.

5.2 Inference Pipeline and Timestamp Prediction

Cell 16 implements the inference machinery for applying the trained model to new video-query pairs. The predict_temporal_grounding function encapsulates the complete prediction pipeline, from loading raw data to producing interpretable timestamp predictions. The function begins by setting the model to evaluation mode, which disables training-specific behaviors like dropout. It then loads and preprocesses the video using the same pipeline employed during training, ensuring consistency in data representation. Each frame undergoes transformation (resize, normalization) to match the expected input format. The video tensor is augmented with a batch dimension (changing from 3D to 4D) since the model expects batched input even for single predictions. Text processing follows an identical pattern: the query is tokenized using BERT's tokenizer with the same padding and truncation settings used during training. Consistency in preprocessing is crucial; any deviation would create a distribution shift between training and inference data, degrading performance. The tokenized text and attention mask are transferred to GPU and batched appropriately. The actual prediction occurs within a torch.no_grad() context, which disables gradient computation. Since we're not training during inference, gradient computation would waste memory and time. The model's forward pass processes video and text through all components (encoders, projection, fusion, grounding head), ultimately producing normalized timestamp predictions in the [0, 1] range. Denormalization converts relative timestamps back to absolute seconds by multiplying with video duration. This conversion is necessary because models operate on normalized values (for scale invariance) but users need interpretable absolute times. The function returns both start and end times in seconds along with total video duration, providing complete temporal localization information. The run_inference_example wrapper function demonstrates practical usage, handling file path construction, model checkpoint loading, and result formatting. It provides a convenient interface for testing the model on specific videos, useful for qualitative evaluation and demonstration purposes. The function prints formatted results showing video metadata, query text, and predicted timestamps in human-readable format.

5.3 Comprehensive Test Set Evaluation and Metrics

Cell 17 implements rigorous evaluation on the held-out test set, computing multiple metrics that characterize model performance from different perspectives. The evaluate_on_test_set function processes all test samples and aggregates predictions for statistical analysis. The evaluation loop processes test data in batches for efficiency, following the same batching strategy as training. For each batch, predictions are generated and compared against ground truth timestamps. IoU is computed for every sample, measuring temporal overlap quality. The function also stores raw predictions and targets in seconds (after denormalization), enabling detailed error analysis beyond aggregate metrics. Multiple evaluation metrics provide complementary insights. Mean IoU represents average overlap quality across all test samples, with values closer to 1.0 indicating better performance. However, mean IoU alone can be misleading if the distribution is skewed. We also compute recall at different IoU thresholds (R@0.3, R@0.5, R@0.7), measuring the proportion of samples achieving at least the specified IoU. Recall@0.3 (30% overlap) represents a lenient criterion, achieved by most reasonable predictions. Recall@0.5 (50% overlap) is a more stringent standard often used in temporal action localization benchmarks. Recall@0.7 (70% overlap) demands high precision and is challenging to achieve consistently. These recall metrics provide insight into the distribution of prediction quality: a model with high R@0.3 but low R@0.7 makes reasonable but imprecise predictions, while high R@0.7 indicates very accurate localization. The evaluation also stores per-sample results (IoU values, predictions, targets) for detailed analysis. This granular data enables investigating failure modes, identifying difficult query types, and understanding model behavior on edge cases. We can sort samples by IoU to examine the best and worst predictions, helping diagnose systematic errors. After completing evaluation, the function prints comprehensive results including sample count, mean IoU, and recall at all thresholds. These metrics are standard in temporal grounding literature, enabling direct comparison with published baselines and state-of-the-art methods. The returned dictionary contains all metrics and raw data for further analysis and visualization.

5.4 Model Serialization and Deployment

Cell 19 implements model saving functionality essential for preserving trained models and enabling deployment. The save_complete_model function creates comprehensive checkpoints containing all information needed to reconstruct the trained system. The checkpoint includes model weights (state_dict containing all parameter values), configuration object (specifying architecture and hyperparameters), and metadata like epoch number and validation metrics. This complete specification enables loading the model in different environments or scripts without requiring access to the original training code. The model architecture string is also saved for documentation purposes, though it's not strictly necessary for reconstruction. We save the model to Kaggle's working directory (/kaggle/working/) which persists after notebook execution and can be downloaded. The tokenizer is saved separately using Hugging Face's save_pretrained method, preserving vocabulary files and tokenization configuration. This separation is necessary because the tokenizer is not a PyTorch module and requires different serialization. Training history and test results are saved as pickle files, preserving Python objects (lists, dictionaries, NumPy arrays) with their exact structure. These auxiliary files enable recreating plots and analyses without rerunning training or evaluation. The complete saved artifacts constitute a reproducible research package that can be shared with others or used for deployment.

5.5 Model Loading and Production Deployment

Cell 20 implements the model loading procedure for inference in production or continuation of development. The load_model_for_inference function reconstructs a trained model from saved checkpoints, enabling application to new data. The loading process begins by reading the checkpoint file with weights_only=False to allow loading custom Python objects (the Config class). We extract the configuration object and use it to instantiate a fresh model instance with identical architecture. The saved state_dict (parameter values) is then loaded into this architecture, restoring the trained weights exactly. The model is placed on the appropriate device (GPU if available, CPU otherwise) and set to evaluation mode. This mode configuration disables dropout and sets batch normalization to use running statistics rather than batch statistics, ensuring consistent predictions. The tokenizer is loaded from its saved directory, restoring vocabulary and tokenization rules. The function returns the model, tokenizer, and configuration as a tuple, providing all components needed for inference. This clean interface enables easy integration into applications or services. Example usage demonstrates loading the model and running predictions, showing the complete workflow from saved checkpoint to timestamp predictions. This model loading capability is essential for practical deployment. Rather than retraining for every prediction, we train once and save the result, then load the trained model as needed for inference. This pattern enables efficient production systems where model training and inference are separated, potentially running on different infrastructure with different resource profiles.

6.1 Comprehensive Dataset Analysis and Statistics

Cells 21 implements exhaustive dataset visualization that provides deep insights into data characteristics, distributions, and potential biases. Understanding dataset properties is fundamental to interpreting model behavior and diagnosing performance issues. The visualization encompasses twelve distinct analytical perspectives, each revealing different aspects of the data. The first component presents a statistics table summarizing key metrics across train, validation, and test splits. This table includes video counts, annotation counts, and average video durations, providing an overview of dataset scale and composition. The split distribution is crucial: we verify that the 70-15-15 train-validation-test ratio is maintained and that all splits have sufficient samples for reliable training and evaluation. Video duration distribution histograms reveal the temporal characteristics of our dataset. Most videos in Charades fall within the 25-35 second range, with some variation. This relatively narrow duration range simplifies the temporal grounding problem compared to datasets with extreme duration variance. However, it also means our model may not generalize well to significantly shorter or longer videos, a limitation to consider for deployment. Event duration distributions show how long activities typically last within videos. This analysis reveals that most annotated activities span 5-15 seconds, though some extend to the full video duration. Understanding event duration statistics helps interpret model predictions: if the model consistently predicts very short or very long intervals, it may be biased by training data statistics rather than learning true temporal boundaries. Query length distributions analyze the textual descriptions provided in annotations. Most queries contain 3-7 words, representing concise action descriptions typical of the Charades dataset. This relatively uniform query length simplifies the text encoding problem, as BERT doesn't need to handle extreme length variation. However, it also means our model may struggle with more detailed or verbose natural language queries in real-world applications. Events per video distribution shows that videos contain multiple annotated activities, typically 5-10 per video. This multiplicity reflects the naturalistic nature of Charades videos, which capture extended sequences of household activities. For our training setup, each annotation is treated as an independent sample, meaning the same video appears multiple times in the dataset with different queries targeting different temporal segments. The cumulative distribution functions provide complementary views of duration and event length statistics. These curves show what fraction of samples fall below any given threshold, useful for understanding distribution tails and identifying outliers. Steep sections indicate concentration of samples, while gradual sections indicate sparse coverage of particular value ranges. Box plots by split verify that train, validation, and test sets have similar statistical properties. Significant differences between splits could indicate problematic data splitting that introduces bias. Our analysis confirms that all splits have comparable distributions, validating our random splitting procedure and ensuring that validation and test performance will generalize to similar data. Event coverage ratio analysis examines what fraction of video duration is occupied by annotated events. High coverage ratios indicate that most of the video contains relevant activity, while low ratios suggest sparse events within longer videos. This metric influences the difficulty of temporal grounding: higher coverage makes random guessing more likely to overlap with truth, while lower coverage requires more precise localization.

6.2 Detailed Prediction Analysis and Error Characterization

Cell 22 implements sophisticated analysis of model predictions, moving beyond simple accuracy metrics to understand prediction patterns, error modes, and performance characteristics. This analysis employs twelve different visualization and statistical techniques to thoroughly characterize model behavior. IoU distribution histograms reveal the spread of prediction quality across test samples. A model with consistently good predictions shows a distribution concentrated near high IoU values, while a struggling model exhibits wide spread across the [0, 1] range. Our analysis shows modal IoU around 0.3-0.35, indicating reasonable but not exceptional performance, with a tail extending to both lower and higher values. Cumulative IoU distributions show what fraction of predictions achieve at least a given IoU threshold. This view is directly connected to recall metrics: the cumulative distribution value at threshold t equals recall@t. The curve's steepness indicates prediction consistency: steep curves mean most predictions cluster around similar IoU values, while gradual curves indicate high variance in prediction quality. Recall curves across continuous IoU thresholds provide a comprehensive view of model performance beyond the discrete R@0.3, R@0.5, R@0.7 metrics reported during training. These curves show exactly how recall degrades as we increase the required overlap threshold, revealing whether performance drop-off is gradual (indicating consistent predictions at varying precision levels) or sharp (indicating a threshold effect where many predictions just barely pass certain IoU values). The performance metrics table summarizes key statistics: mean IoU, median IoU, standard deviation, and recall at various thresholds. Median IoU is particularly informative as it's robust to outliers, providing a better sense of "typical" performance than mean IoU when the distribution is skewed. Standard deviation quantifies prediction consistency: lower values indicate more reliable, predictable performance. Start and end time error distributions characterize prediction biases. Systematic bias toward predicting starts too early (negative error) or too late (positive error) indicates specific failure modes. Similarly, end time errors reveal whether the model tends to terminate predictions prematurely or extend them too long. Our analysis shows relatively centered error distributions, indicating no strong systematic bias, though the spread indicates substantial prediction variance. Predicted versus true duration scatter plots reveal whether the model accurately estimates event lengths. Points along the diagonal indicate correct duration prediction regardless of absolute timing, while deviation from the diagonal shows duration estimation errors. Color-coding by IoU helps identify whether duration errors correlate with overall prediction quality. Error versus IoU scatter plots investigate whether certain types of errors predict overall performance. High total error (sum of start and end errors) should correlate with low IoU, and indeed we observe this negative relationship. However, the scatter in this relationship indicates that absolute error and IoU measure somewhat different aspects of prediction quality. IoU percentile analysis provides detailed distribution quantiles, going beyond mean and median to characterize the full distribution shape. The 10th, 25th, 50th, 75th, 90th, 95th, and 99th percentiles reveal how performance varies from worst to best predictions, helping identify whether poor performance is limited to a small fraction of difficult samples or widespread across the dataset. Best versus worst prediction visualization provides qualitative comparison of model successes and failures. By visualizing the highest and lowest IoU predictions with their temporal intervals, we can identify patterns in what makes samples easy or difficult. This analysis often reveals that failures occur on ambiguous queries or videos with multiple similar activities.

6.3 Sample-Level Prediction Visualization with Video Frames

Cell 23 implements detailed visualization of individual predictions, combining quantitative metrics with qualitative visual assessment. This cell creates comprehensive multi-panel figures showing video frames, prediction timelines, and detailed metrics for selected test samples. For each visualized sample, we extract three representative frames from different temporal positions in the video. These frames are denormalized from the preprocessed tensor format back to displayable RGB images, reversing the ImageNet normalization applied during preprocessing. Frame selection at 1/3, 2/3, and end positions provides temporal coverage of the video content, helping assess whether predicted boundaries align with visual activity patterns. Timeline visualizations show predicted and ground truth intervals as colored rectangles on a normalized time axis. Green rectangles indicate ground truth while blue rectangles show predictions. The degree of overlap between rectangles directly corresponds to IoU: complete overlap produces IoU=1.0, no overlap produces IoU=0.0, and partial overlap produces intermediate values. This visualization makes IoU immediately interpretable through visual overlap. Detailed information panels accompany each visualization, showing video ID, textual query, video duration, ground truth timestamps, predicted timestamps, and error metrics. This comprehensive metadata enables thorough understanding of model behavior on each sample. By examining multiple samples spanning the IoU distribution, we gain insight into what distinguishes successful from unsuccessful predictions. The visualization focuses on interpretability, using clear labeling, color coding, and layout to maximize information density while maintaining readability. High-resolution output (300 DPI) ensures publication quality for inclusion in papers or presentations. The ability to generate these visualizations programmatically for any test sample enables rapid qualitative analysis during model development.

6.4 Comparative Analysis and Benchmarking

Cell 24 implements rigorous comparison of our model against baselines and reference methods, providing context for interpreting absolute performance numbers. Comparison is essential because raw metrics like "IoU=0.32" are difficult to interpret without knowing whether this represents strong, mediocre, or poor performance for the task. We compare against several baseline approaches. Random baseline selects random temporal intervals as predictions, achieving IoU around 0.15 purely by chance given the event coverage statistics of our dataset. Center baseline predicts a fixed interval centered in the video, achieving IoU around 0.20 by exploiting the bias that many events occur near video centers. These baselines establish lower bounds: any learned model must exceed these trivial strategies to demonstrate actual learning. We also compare against typical performance ranges for different model classes. Lightweight models with limited capacity typically achieve IoU around 0.35, representing the performance ceiling for constrained architectures. State-of-the-art methods employing large pre-trained models and extensive compute achieve IoU around 0.45-0.50 on Charades-style data. Our model achieves IoU around 0.31-0.34, placing it above trivial baselines but below more sophisticated approaches. The visualization includes performance-versus-complexity scatter plots that show the tradeoff between model capacity and accuracy. Our frozen-encoder approach occupies a favorable position: much higher efficiency than full models but comparable performance to other lightweight approaches. This analysis justifies our architectural choices given the computational constraints. Potential improvement analysis projects expected performance gains from various enhancements. Unfreezing encoders could improve IoU by 25-35% based on literature results, though at the cost of 3-4× longer training time and higher memory requirements. Increasing model capacity (more layers, larger hidden dimensions) offers more modest improvements of 10-15%. This analysis guides future development priorities.

6.5 Attention Visualization and Interpretability Analysis

Cell 25 implements visualization of internal model representations, providing insight into what the model learns and how it makes decisions. Understanding model internals is crucial for debugging, improving architectures, and building trust in predictions. Video and text feature heatmaps show the learned representations after encoding and projection. These visualizations reveal whether features exhibit structure and variation or appear random and uninformative. Structured patterns indicate the model extracts meaningful representations, while random-looking features suggest learning difficulties or insufficient capacity. Cross-modal attention visualization shows similarity between video frames and text tokens, computed as dot product between normalized feature vectors. High similarity indicates the model associates particular frames with particular words, suggesting it has learned meaningful video-text alignments. Attention patterns should show diagonal structure (temporal alignment between query word order and activity occurrence) or block structure (multiple frames attending to activity-describing words). Temporal attention visualization shows which video frames receive highest importance for prediction, computed from feature magnitudes in the fused representation. Frames corresponding to ground truth intervals should show elevated importance if the model correctly identifies relevant temporal regions. By comparing attention patterns between successful and unsuccessful predictions, we can diagnose whether failures stem from attention to wrong time regions or from insufficient feature discrimination.

6.6 Comprehensive Project Summary and Documentation

Cell 26 generates a complete project report combining all previous analyses into a single comprehensive document. This report serves as complete documentation of the methodology, results, and findings, suitable for archival or presentation purposes. The summary includes architecture diagrams, configuration specifications, dataset statistics, training curves, evaluation metrics, comparison with baselines, key findings, identified strengths and limitations, and recommendations for future work. This comprehensive documentation ensures the project can be understood, reproduced, and built upon by others or by the original authors returning after time away. The report is structured logically, progressing from problem formulation through methodology, results, and conclusions. Visual elements (plots, tables, diagrams) are integrated throughout to complement textual descriptions. High-resolution rendering ensures the document is publication-ready for inclusion in research papers, technical reports, or presentations. This final cell represents the culmination of the entire workflow, transforming a collection of code, data, and experiments into a cohesive narrative that communicates insights and contributions clearly. The systematic methodology documented across all cells enables reproducible research and provides a template for similar temporal grounding projects.