Author Response (Reviewer JeCQ) (2/N)

Q2: Currently, the VideoShield method can hide 512 bits. What is the upper limit for watermark capacity?

A2: Thank you for your question. The upper limit for watermark capacity in VideoShield is primarily constrained by the video’s resolution (h,w), frame count (f), and the coefficients used ($k_{f}, k_{c}, k_{h}, k_{w}$) in the embedding process as given by the formula: $(f / k_f) * (c / k_c) * (h / k_h) * (w / k_w)$.

• Theoretically, the capacity can be increased when using higher resolution, more frames, or smaller coefficients.
• In practical use, the upper limit is constrained by the trade-off between watermark capacity and robustness when the resolution and frame count are fixed. The number of embedded watermark bits can be flexibly adjusted by modifying the coefficient $k_{f}, k_{c}, k_{h}, k_{w}$. However, as the watermark capacity increases, robustness may decline due to the added complexity of embedding more bits.
• Therefore, while there is no strict upper limit, the capacity should be carefully adjusted to balance robustness and the characteristics of the video.
• Finally, in practical scenarios, 512 bits is actually quite large and sufficient to distinguish different users.

Author Response (Reviewer JeCQ) (1/N)

Dear Reviewer WfUe, thank you very much for your careful review of our paper and thoughtful comments. We are encouraged by your positive comments on the excellent contributions, novelty, and strong generalization capabilities of VideoShield, along with the clear presentation and good soundness of the paper. We hope the following responses can help clarify potential misunderstandings and alleviate your concerns.

W1: The threshold and hyperparameter settings in the method section are mostly the result of manual searches. The authors may consider exploring how these thresholds could be adaptively searched in the future.

A1: Thank you for your valuable suggestion.

• We agree that adaptively searching for thresholds could enhance the flexibility and performance of the method. A feasible approach would be to create a small test set of videos and define a target tamper localization performance metric. Using this metric, grid search could be employed to iteratively optimize the relevant thresholds until the desired performance is achieved.
• However, due to time and resource constraints, we are unable to provide large-scale experimental results for this approach at this time. We appreciate your insightful suggestion and plan to explore this direction in future work.

Q1: In Table 1 and other tables, the metric "Video quality" is mentioned. How is it specifically calculated? The authors mentioned it is the average of a series of metrics; if possible, could you provide the specific values for each metric?

A1: Thank you for your question. We have provided the calculation details in Appendix D.1 (due to space constraints, we do not list them here) and the specific values for each metric in the Table below. As shown in the Table, the watermarking method with post-processing causes more significant degradation to the videos in terms of Dynamic Degree and Imaging Quality. However, for Background Consistency and Motion Smoothness, videos with post-processing sometimes show a slight increase in range. We believe this is due to the watermark embedding introducing some blurring to the video, resulting in better smoothness, which leads to a slight “anomalous” increase in continuity metrics.

Table: Specific metric values for video quality assessment.

Author Response (Reviewer WfUe)

Dear Reviewer WfUe, thank you very much for your careful review of our paper and thoughtful comments. We are encouraged by your positive comments on filling the research gap in watermarking diffusion-based video generation models, reducing computational overhead, and providing a clear presentation of the paper. We hope the following responses can help clarify potential misunderstandings and alleviate your concerns.

W1: The innovation presented in this paper is moderate. It extends Gaussian Shading from images to videos and further explores its potential as a fragile watermark.

A1: Thank you for your feedback and we do understand your cocnerns. However, we respectfully argue that our VideoShield is not a straightforward extension of Gaussian Shading (GS) to the video modality. The distinct contributions of our work are outlined as follows:

1. The Core Role of Template Bits.

• Template bits form the cornerstone of our framework, a concept entirely absent in GS. These bits establish a seamless, training-free connection between watermark embedding, extraction, and tamper localization.
• Furthermore, template bits are highly versatile, applicable to both images and videos, and adaptable to other modalities. This plug-and-play capability paves the way for multifunctional watermarking solutions, making the framework flexible and widely applicable.

2. GS as One Implementation Method Among Others.

• While GS provides one method to implement template bits, it is not the only option. For example, PRC [1] also serves as an alternative implementation.
• Specifically, PRC employs pseudorandom error-correcting code (PRC) to transform watermark bits into pseudo-random bits that correspond one-to-one with the content. These pseudo-random bits can then be used as template bits. PRC further combines the absolute values of randomly sampled Gaussian noise with the signs of the template bits, embedding the watermark effectively.

3. Innovations in the Video Modality.

• Our work introduces the novel concept of temporal tamper localization, addressing challenges that traditional methods cannot resolve.
• Additionally, leveraging the unique characteristics of video data, we propose two innovative techniques, Hierarchical Spatial-Temporal Refinement and Partial Threshold Binarization, which substantially enhance the robustness of spatial tamper localization.
• These contributions close critical gaps in tamper localization for video modalities, setting a foundation for more robust and versatile watermarking frameworks.

References

1. An undetectable watermark for generative image models. arXiv preprint arXiv:2410.07369, 2024.

W2: The presentation of the text has significant issues, particularly in Section 3.4, "TAMPER LOCALIZATION."

A2: Thank you for your detailed and constructive feedback. We have made the necessary adjustments according to your suggestions:

• We have revised the notation and standardized the matrix subscripts for better clarity, with the changes highlighted in red in the revised PDF the first time they appear in the main text.
• Figure 7 has been moved to the main text (it is now Figure 2) to improve reader comprehension.
• Additionally, we have resolved the overlap between Table 1 and the Datasets section.

We hope these revisions enhance the clarity and readability of the paper.

W3: The paper does not demonstrate the accuracy of the watermark after spatial tampering.

A3: Thank you for your insightful comment. To address your concern, we have conducted additional experiments that confirm the watermark remains effectively extractable with near 100% accuracy, even after the video undergoes spatial tampering. The results of these experiments are provided below. We hope this clarifies the robustness of the watermark in such scenarios.

Table: Performance of watermark extraction on the tampered videos.

Author Response (Reviewer g7Rd)

Dear Reviewer g7Rd, thank you very much for your careful review of our paper and thoughtful comments. We are encouraged by your positive comments on the interest of the topic, the clear presentation and organization of the paper, the abundance of convincing experiments, and the good contributions. We hope the following responses can help clarify potential misunderstandings and alleviate your concerns.

W1: Typesetting needs to be improved, such as keeping the same or similar text size of the table as the text, no overlapping between table and text.

A1: Thank you for your feedback. We have made the necessary adjustments in the revised PDF to ensure consistent text size in the tables and prevent any overlap with the text. We hope these changes address your concerns.

Q1: The framework looks heavy, how about the computational overload? The relationship with "Gaussian Shading" needs to be further clarified.

A1: Thank you for your question.

We have provided the computational overload in the Table below. From the Table, we have:

• The primary GPU memory usage and runtime overhead are concentrated in the DDIM Inversion stage.
• However, as shown in the table for step = 10 and step = 25, reducing the number of inversion steps can significantly decrease the runtime, with only a slight sacrifice in performance as shown in Table 11 of the paper.
• We also provide an analysis of potential speed-up methods for the inversion process in Appendix E.6.

Table: Computational overhead of VideoShield in terms of GPU memory usage and runtime, evaluated on a single NVIDIA RTX A6000 GPU (49 GB) in FP16 mode. The average runtime of different stages is reported based on 50 generated videos, with the batch size set to 1. “Step” refers to the inversion step, while “Watermark,” “Spatial,” and “Temporal” indicate the average runtime of watermark extraction, spatial tamper localization, and temporal tamper localization, respectively. (s) indicates the runtime in seconds.

As for the relationship with "Gaussian Shading", in fact, VideoShield is not a straightforward extension of Gaussian Shading (GS) to the video modality. The distinct contributions of our work are outlined as follows:

1. The Core Role of Template Bits.

• Template bits form the cornerstone of our framework, a concept entirely absent in GS. These bits establish a seamless, training-free connection between watermark embedding, extraction, and tamper localization.
• Furthermore, template bits are highly versatile, applicable to both images and videos, and adaptable to other modalities. This plug-and-play capability paves the way for multifunctional watermarking solutions, making the framework flexible and widely applicable.

2. GS as One Implementation Method Among Others.

• While GS provides one method to implement template bits, it is not the only option. For example, PRC [1] also serves as an alternative implementation.
• Specifically, PRC employs pseudorandom error-correcting code (PRC) to transform watermark bits into pseudo-random bits that correspond one-to-one with the content. These pseudo-random bits can then be used as template bits. PRC further combines the absolute values of randomly sampled Gaussian noise with the signs of the template bits, embedding the watermark effectively.

3. Innovations in the Video Modality.

• Our work introduces the novel concept of temporal tamper localization, addressing challenges that traditional methods cannot resolve.
• Additionally, leveraging the unique characteristics of video data, we propose two innovative techniques, Hierarchical Spatial-Temporal Refinement and Partial Threshold Binarization, which substantially enhance the robustness of spatial tamper localization.
• These contributions close the critical gaps in tamper localization for video modalities, setting a foundation for more robust and versatile watermarking frameworks.

References

1. An undetectable watermark for generative image models. arXiv preprint arXiv:2410.07369, 2024.

Author Response (Reviewer RSGi) (2/N)

References For 1/N

1. Scalable watermarking for identifying large language model outputs. Nature, 2024. https://doi.org/10.1038/s41586-024-08025-4
2. Gaussian Shading: Provable Performance-Lossless Image Watermarking for Diffusion Models. CVPR, 2024.
3. Enhancing Biosecurity with Watermarked Protein Design[J]. bioRxiv, 2024.
4. https://www.reuters.com/technology/artificial-intelligence/openai-supports-california-ai-bill-requiring-watermarking-synthetic-content-2024-08-26
5. https://www.europarl.europa.eu/topics/en/article/20230601STO93804/eu-ai-act-first-regulation-on-artificial-intelligence
6. https://www.pbs.org/newshour/politics/new-bipartisan-bill-would-require-labeling-of-ai-generated-videos-and-audio

W3: It would be more suitable to compare the approach with other proactive tamper detection methods.

A3: Thank you for your feedback.

• As the second paper you mentioned is not open-source, we conduct comprehensive experiments to compare VideoShield with EditGuard, the recently open-sourced (after our submission) proactive tamper localization model known for its exceptional performance.
• Our evaluation covers both videos and images generated by various models. Specifically, we use the default spatial tamper method, Crop&Drop, to create 200 tampered videos for each video generation model and 500 tampered images for each image generation model.
• As shown in the Table below, VideoShield outperforms EditGuard on five models, with the exception of SVD and I2VGen. The relatively lower performance on SVD, in particular, is discussed in Appendix G.3, where we attribute this to the quality of the generated content. Most importantly, as EditGuard is designed for image modality, it fails for temporal tamper localization.

Table: Comparison of spatial tamper localization performance between VideoShield and EditGuard on videos and images generated by various models. SD stands for Stable Diffusion. The table presents the average values of five metrics: F1, Precision, Recall, AUC, and IoU.

W4: There are formatting issues: the bottom line of Table 1 overlaps with the text below, and the font size in Table 3 is too small, making it difficult for readers to follow.

A4: Thank you for pointing out the formatting issues. We have addressed these concerns in the revised version of the PDF, where the overlap in Table 1 and the font size issue in Table 3 have been corrected. We hope the revised version resolves these problems, and we appreciate your attention to detail.

Author Response (Reviewer RSGi) (1/N)

Dear Reviewer RSGi, thank you very much for your careful review of our paper and thoughtful comments. We are encouraged by your positive comments on the novelty of the proposed framework and the well-written structure of the paper. We hope the following responses can help clarify potential misunderstandings and alleviate your concerns.

W1&W2: The proposed model may not entirely align with watermarking application scenarios, where verifiers typically can extract watermark information without needing the original video or the bit template directly from the video creator. Does this mean that a unique random number needs to be set for each video? It’s unclear whether the primary goal of this approach is to protect the model itself or the generated videos.

A: Thank you for these insightful comments!

• These questions pertain to the scenario of watermark verification, the number of used keys, and the target of protection for the common in-generation watermarking strategy. It seems there might be some misunderstandings regarding the in-generation watermarking paradigm. To clarify them, we will first outline the general characteristics or use cases of in-generation watermarking methods. Then, we will address the three questions.
• Existing in-generation watermarking methods, designed for various modalities (e.g., text [1], images [2], proteins [3], etc.), share the following common characteristics:
  1. Protection of content generated by closed-source models.
     • These watermarking methods are designed for closed-source models, where users do not have access to the content generation process. Instead, the model owner (e.g., the platform providing the model service) can intervene in this process to embed watermarks.
     • The ultimate goal is to protect the generated content, with its copyright belonging to the model owner. This approach aligns with the requirements of recent relevant regulations [4][5][6].
  2. Watermark verification is performed by the model owner.
     • As described in characteristic 1, the model owner, being the party responsible for embedding the watermark, has access to all necessary information (e.g., keys, model parameters) required for verification. Therefore, only the model owner can verify the watermark, safeguarding their copyright over the generated content.
     • If a legitimate third party wishes to verify the watermark, they must collaborate with the model owner and obtain the necessary embedding information.
  3. Keys are typically used for watermark embedding, but not for every piece of content. Most existing in-generation watermarking methods rely on keys during embedding. The model owner generally follows one of two scenarios when setting up keys:
     • For multi-bit watermarks, a single key related to the model is used to embed the watermark, with detection focusing solely on the watermark bits themselves for traceability.
     • For zero-bit watermarks, a unique key is assigned to each user, allowing the key to serve as a traceable identifier for content-generation users.

Based on these common characteristics, we provide answers to your three questions as follows:

• Q1: The proposed model may not entirely align with watermarking application scenarios, where verifiers typically can extract watermark information without needing the original video or the bit template directly from the video creator.

  • As outlined in characteristic 2, legitimate third verifiers must obtain template bits from the model owner to conduct watermark verification, which is different from the traditional watermarking application scenarios you mentioned.

• Q2: Does this mean that a unique random number needs to be set for each video?

  • As noted in characteristic 3, it is not necessary to assign a unique key or nonce (random number) to every generated video. Since we embed multi-bit watermarks, the model owner only needs to set a single key and nonce (collectively referred to as a “key”) for one video generation model.
  • This does not compromise the diversity of generated videos. Even if the same key and watermark bits result in identical template bits, the truncated Gaussian sampling (as described in Equation 1 of the paper) produces unique Gaussian noise. Furthermore, the inherent randomness in the sampling process and the different initial Gaussian noise ensure that even videos generated with the same prompt will exhibit diversity.

• Q3: It’s unclear whether the primary goal of this approach is to protect the model itself or the generated videos.

  • As mentioned in characteristic 1, VideoShield is designed to protect video content generated by closed-source models.

Dear Reviewer,

We hope our responses to your comments have sufficiently addressed your concerns. Currently, your score places the paper below the acceptance threshold, but we believe VideoShield has the potential to meet the standard for publication. If you feel the rebuttal resolves your initial concerns, we kindly ask you to consider adjusting your score accordingly.

Please don’t hesitate to reach out if further clarification is needed. Thank you again for your time and effort!

Author Response (Reviewer Jpgb) (2/N)

W2&Q2: Can the author share the computational performance of VideoShield, especially regarding the running time of different video resolutions or models?

A2: Thank you for your question. We appreciate your interest in the computational performance of VideoShield. We have provided the computational cost in the Table below, including the running time for different video resolutions and models. From the Table, we have:

• The primary GPU memory usage and runtime overhead are concentrated in the DDIM Inversion stage.
• However, as shown in the table for step = 10 and step = 25, reducing the number of inversion steps can significantly decrease the runtime, with only a slight sacrifice in performance as shown in Table 11 of the paper.
• We also provide an analysis of potential speed-up methods for the inversion process in Appendix E.7.

We hope this addresses your concern, and we are happy to provide further clarifications if needed.

Table: Computational overhead of VideoShield in terms of GPU memory usage and runtime, evaluated on a single NVIDIA RTX A6000 GPU (49 GB) in FP16 mode. The average runtime of different stages is reported based on 50 generated videos, with the batch size set to 1. “Step” refers to the inversion step, while “Watermark,” “Spatial,” and “Temporal” indicate the average runtime of watermark extraction, spatial tamper localization, and temporal tamper localization, respectively. (s) indicates the runtime in seconds.

Author Response (Reviewer Jpgb) (4/N)

W4&Q4: Does the performance of VideoShield still vary due to resolution or model complexity? If so, can the author provide more insights or data on these factors?

A4: Thank you for your thoughtful question.

1. For resolution, since ZeroScope is trained on videos of various resolutions, we choose it to generate videos at different resolutions for this analysis. As shown in the Table below, VideoShield’s spatial tamper localization performance improves as the resolution increases. We believe this is because higher video resolutions capture more details and provide better quality, allowing the template bits to be better integrated into the generated video. This, in turn, enhances the inversion accuracy, leading to improved spatial tamper localization performance.
2. For model complexity, a common measure is the number of parameters. To explore this, one would need models of the same type (e.g., T2V) with similar architectures but different parameter counts. The T2V models used in our work have 1.83B parameters, while the I2V models are around 2.3B. Currently, we are unable to find any open-source models that meet this specific requirement. Therefore, we have not been able to explore this relationship in our current study. However, this is indeed an interesting direction for future work, and we appreciate your valuable suggestion!

Table: Performance on videos generated by ZeroScope with different resolutions.

W5&Q5: Can VideoShield adapt to image tampering localization?

A5: Thank you for your question. We appreciate your interest in extending VideoShield to image tampering localization.

• As discussed in Section 3.4, under “Spatial tamper localization on images generated by T2I models”, we have already presented relevant results, which you might have overlooked.
• Additionally, we have provided a comparison in Appendix E.6 with EditGuard, a state-of-the-art open-source method for proactive image tamper localization. Our method demonstrates superior performance, further confirming its versatility and effectiveness. We hope this addresses your concern and welcome any further questions.

For your convenience, we provide the results in the Table below.

Table: Comparison of image spatial tamper localization performance between VideoShield and EditGuard on images generated by various models. SD stands for Stable Diffusion. The table presents the average values of five metrics: F1, Precision, Recall, AUC, and IoU.

Q6: Is the watermark capacity of 6 512 bits suitable for all video resolutions, or is the number of bits that can be embedded flexible based on the characteristics of the video?

A6: The number of embedded watermark bits can be flexibly adjusted based on video characteristics. The number of embedded bits is determined by $(f / k_f) * (c / k_c) * (h / k_h) * (w / k_w)$, leading to two possible scenarios:

1. If the coefficient $k_{f}, k_{c}, k_{h}, k_{w}$ is fixed, the number of embedded watermark bits increases with the video resolution and the number of frames.
2. If the video resolution and frame count are fixed, the number of embedded watermark bits can be flexibly adjusted by modifying the coefficient $k_{f}, k_{c}, k_{h}, k_{w}$. However, this introduces a trade-off between watermark extraction robustness and watermark capacity. A larger coefficient means each watermark bit is repeated more times before being embedded into the Gaussian noise, making it determined by more video pixels. This increases fault tolerance, thereby enhancing robustness.

Q7: Placing visual content in the main text seems better.

A7: Thank you for the suggestion. We agree that placing visual content in the main text can enhance clarity.

• To address this, we have included the comparison of spatial tampering localization results between VideoShield and baselines (Figure 5), as well as the illustration of the temporal tamper localization process (Figure 2), in the main text, as we consider these two figures particularly important.
• Due to space constraints, we were unable to include additional visual content in the main text but have provided comprehensive supplementary visualizations in the Appendix.

We hope this strikes a balance and welcome further suggestions.

Author Response (Reviewer Jpgb) (3/N)

W3&Q3: Will the author consider testing the robustness of VideoShield under other types of distortion, such as extreme video compression, frame rate variations, or color adjustments?

A3: Thank you for your insightful question.

1. For frame rate variations, there are two scenarios:
   • Altering the playback duration without changing the number of frames. In this scenario, VideoShield’s performance remains unaffected as the tested frames are not altered.
   • Modifying the number of frames through frame insertion or deletion while keeping the playback duration unchanged. This essentially corresponds to temporal tampering, and we have already included the localization accuracy for Frame Insert and Drop in Table 2 in the revised PDF.
2. For video compression, the results are shown in the Table below (CRF). The typical CRF (Constant Rate Factor) range is 18–28, where 18 corresponds to higher video quality and 28 to lower quality.
   • The results show that only under extreme compression conditions (CRF > 28) do the watermark extraction and localization performance for both MS and SVD start to degrade significantly. However, at this point, the video quality is already severely degraded, making the performance drop acceptable.
   • Besides, adjusting the threshold substantially improves spatial localization performance.
3. For color adjustments, the results are shown in the Table below (Hue). VideoShield shows strong robustness, maintaining high performance in both watermark extraction and tamper localization.

Overall, VideoShield demonstrates good robustness, making it suitable for most real-world scenarios. We hope this addresses your concerns and are happy to provide further clarifications if needed.

Table: Performance under more spatial distortions. CRF represents different compression factors of H.264. As discussed in Section 3.5, 'w/o' refers to using $t_{wm}$ and $t_{orig}$ derived from the clean watermarked videos, while 'w/' indicates that various distortions are introduced during the distribution testing, leading to adjustments in $t_{wm}$ and $t_{orig}$. Hue=0.5 is the max factor we can configure.

Author Response (Reviewer Jpgb) (1/N)

Dear Reviewer Jpgb, thank you very much for your careful review of our paper and thoughtful comments. We are encouraged by your positive comments on the novelty of VideoShield, its significant contributions to the explored field, the rigorous and comprehensive description of the technical methods, the well-organized structure of the paper, the extensive experimental evaluation, and the thorough analysis of various scenarios. We hope the following responses can help clarify potential misunderstandings and alleviate your concerns.

W1&Q1: Can the author provide more comparative details on how VideoShield compares to other watermarking frameworks or post-processing methods in terms of tamper localization accuracy and robustness?

A1: Thank you for the valuable feedback. We appreciate the opportunity to clarify the comparative aspects of our work.

1. Watermarking Methods Comparison.
   • Currently, there are no in-generation video watermarking methods available for direct comparison. The only available post-processing video watermarking framework is RivaGAN, which has been included as a baseline in Table 1. For the other comparison baselines, we adopted famous and state-of-the-art image watermarking methods, and we leveraged these methods to embed the same watermark bits in each frame of the video, and then conduct relevant tests accordingly.
   • The robustness of the watermarking methods is visualized in Figure 7 (in the revised PDF) under different distortions. The specific configurations of different distortions are in Watermark extraction section of Appendix D.5:
     • We consider the following distortions: three video distortions—MPEG-4, Frame Average ($N=3$), and Frame Swap ($p=0.25$)—and eight image distortions applied to each video frame: Gaussian Noise ($\sigma=0.1$), Gaussian Blur ($r=4$), Median Blur ($k=7$), Salt and Pepper Noise ($p=0.1$), Random Crop ($0.5$), Random Drop ($0.5$), Resize ($0.3$), and Brightness ($\text{factor}=6$).
   • Besides, we have provided the additional specific robustness evaluation results in Appendix E.2, which demonstrate that our VideoShield outperforms all baseline watermarking methods in terms of robustness.
2. Temporal Tamper Localization Comparison.
   • To the best of our knowledge, we are the first to introduce the task of temporal tamper localization, there is currently no established baseline for comparison in this area.
3. Spatial Tamper Localization Comparison.
   • To the best of our knowledge, there are no open-source video tamper localization methods available for direct comparison. At the time of this work, there were also no open-source proactive image tamper localization methods suitable for comparison, so we resorted to open-source passive image tamper localization methods. We selected several of the most effective methods for comparison, with the results presented in Table 3 of the revision.
   • Additionally, in the revised PDF, we have included a comparison with the recently open-sourced state-of-the-art method, EditGuard, which is an proactive image tamper localization approach. VideoShield outperforms EditGuard on videos or images generated by five out of the seven models. The detailed comparison results are in the Table below and further analysis can be found in Appendix E.6.

Table: Comparison of spatial tamper localization performance between VideoShield and EditGuard on videos and images generated by various models. SD stands for Stable Diffusion. The table presents the average values of five metrics: F1, Precision, Recall, AUC, and IoU.

I appreciate and acknowledge the author's emphasis on this work and the effort put into this response, and I will maintain my current rating.

Author Response (Reviewer YUmj) (2/N)

W4: Figure 2 provides only abbreviations in the legend

A4: Thank you for pointing this out!

• In our paper,
  • GA stands for Gather and Average.
  • PTB stands for Partial Threshold Binarization.
  • R stands for Repeat.
• In response, we have revised the legend of Figure 2 (Figure 3 in the revision) in the revised PDF by replacing the abbreviations with their full terms for better clarity.

W5: Over all paper, formulas and tables seem to have decreased font. Moreover, some tables overlap the text (e.g. Table1). This may be a reason for a possible desk rejection.

A5: Thank you for pointing this out! In response, we have adjusted the font size of the formulas and tables in the revised PDF, and have corrected the space between the tables and the text to ensure better readability.

Q1: Results from Table 1 shows that the proposed method is only marginally better than RivaGAN w/o real images conditioning. Did you check RivaGAN with the same setup as the last row?

A1: Thank you for pointing this out and we do understand your concern.

• In the same setup (w/ real images), RivaGAN achieves a Video Quality score of 0.865, which is on par with our method, as shown in the Table below.
• In fact, RivaGAN is a post-processing video watermarking method, which results in relatively high fidelity. However, besides Video Quality, watermark embedding capacity and robustness are two other important metrics to measure watermarking's performance. As shown in the Table below, its watermark embedding capacity (Bit Length) and robustness (Bit Accuracy (adv)) are inferior to those of VideoShield.

Table: Comparison of RivaGAN and our VideoShield on videos generated by SVD conditioned on real images. “Bit Accuracy (adv)” refers to the average bit accuracy under various distortions, indicating robustness.

Q2: Why do you compare only to SVD in Table 2?

A2: Thank you for this insightful question!

• Here might be some potential misunderstandings
  • SVD stands for 'Stable Video Diffusion' (instead of 'Singular Value Decomposition').
  • SVD is not a baseline for comparison. It is representative of the Image-to-Video (I2V) model used to generate the videos, which are used to evaluate the temporal tamper localization.
• Table 2 presents the results for temporal tamper localization. Specifically, we include the performance on videos generated by our two default video generation models: the Text-to-Video (T2V) model, MS, and the Image-to-Video (I2V) model, SVD. Our VideoShield achieves temporal tamper localization accuracies of 1.000 and 0.936 on videos generated by MS and SVD, respectively, demonstrating its outstanding performance.
• To the best of our knoledge, we are the first to evaluate temporal teamper localization on generated video, so there are no existing baselines for direct comparison. We are very willing to incorporate more comparison for suitable methods if you can kindly provide more details.
• To ensure clarity, we have presented the results of VideoShield (including watermarking and tamper localization) applied to videos generated by SVD conditioned on real images in a separate Table 4 in the revised PDF.

Q3: Subjective comparison is required in this work, can you provide one?

A3: Thank you for this constructive suggestion!

• We further conduct a user study to perform a subjective comparison of video quality. We randomly select 10 videos from each of the 200 videos generated by MS and SVD. After watermarking these videos by different methods, we distribute the watermarked videos to 24 distinct users with the instruction: “Please choose the video that you consider to have the highest quality, based on Subject Consistency, Background Consistency, Motion Smoothness, Dynamic Degree, and Imaging Quality.”
• The results are shown in the table below. As observed, VideoShield receives the most votes for both MS and SVD, i.e., VideoShield achieves the best video quality, followed closely by RivaGAN with a slight gap, while MBRS also garners relatively high votes. Conversely, CIN, PIMoG, and SepMark receive very few votes, indicating more significant visible degradation in video quality.

Table: Subjective comparison results.

Author Response (Reviewer YUmj) (1/N)

Dear Reviewer YUmj, thank you very much for your careful review of our paper and thoughtful comments. We are encouraged by your positive comments on the novelty and practicality of VideoShield. We hope the following responses can help clarify potential misunderstandings and alleviate your concerns.

W1: Notation $T_{temp}$ for a threshold in tampering is a bit confusing, considering $T_{p}$ is a tensor.

A1: Thank you for this suggestion!

• We acknowledge that the current notation $T_{temp}$ may cause confusion, especially since $T_p$ is a tensor.
• To address this, we have revised $T_{temp}$ to $t_{temp}$, along with changing $T_{wm}$ to $t_{wm}$ and $T_{orig}$ to $t_{orig}$ in the revised PDF.

These changes are highlighted in red the first time they appear, for your convenience, to clearly reflect the scalar nature of these terms.

W2: No introduction for chacha20

A2: Thank you for pointing it out! We have added the introduction below for ChaCha20 in Section 2.3 of the revised PDF and highlighted the changes in blue for your convenience:

• ChaCha20 is a stream cipher that takes a 256-bit key, a 96-bit nonce, and plaintext as input to produce a pseudo-random ciphertext as output. The algorithm generates a keystream that is XORed with the plaintext for encryption.

We hope this addition clarifies the context.

W3: No formula for calculating video quality is given

A3: Thank you for pointing this out! Due to space limitations in the initial submission, we did not include the formula for calculating video quality.

• We have now added the formulas in Appendix D.1 of the revised PDF for your reference.
• We also present the formulas below for your convenience:
  • Subject Consistency. Subject Consistency is acquired by calculating the DINO [2] feature similarity across frames:

$

S_{\text{subject}} = \frac{1}{T - 1} \sum_{t=2}^{T} \frac{1}{2} \left( \langle d_1 \cdot d_t \rangle + \langle d_{t-1} \cdot d_t \rangle \right),

$

where $d_{i}$ is the DINO image feature of the $i^{th}$ frame, normalized to unit length, and $\langle \cdot \rangle$ is the dot product operation for calculating cosine similarity. * Background Consistency. Background Consistency evaluates the temporal consistency of the background scenes by calculating CLIP [3] feature similarity across frames:

$

S_{\text{background}} = \frac{1}{T - 1} \sum_{t=2}^{T} \frac{1}{2} \left( \langle c_1 \cdot c_t \rangle + \langle c_{t-1} \cdot c_t \rangle \right),

$

where $c_{i}$ represents the CLIP image feature of the $i^{th}$ frame, normalized to unit length. * Motion Smoothness. Motion Smoothness is evaluated by the frame-by-frame motion prior to video frame interpolation models [4]. Specifically, given a generated video consisting of frames $[f_0, f_1, f_2, f_3, f_4, ..., f_{2n-2}, f_{2n-1}, f_{2n}]$, the odd-number frames are manually dropped to obtain a lower-frame-rate video $[f_0, f_2, f_4, ..., f_{2n-2}, f_{2n}]$, and video frame interpolation [4] is used to infer the dropped frames [ f̂_1, f̂_3, ..., f̂_(2n-1) ]. Then the Mean Absolute Error (MAE) between the reconstructed frames and the original dropped frames is computed and normalized into $[0, 1]$, with a larger number implying smoother motion. * Dynamic Degree. Dynamic Degree is designed to assess the extent to which models tend to generate non-static videos. RAFT [5] is used to estimate optical flow strengths between consecutive frames of a generated video. Then the average of the largest 5% optical flows (considering the movement of small objects in the video) is taken as the basis to determine whether the video is static. The final dynamic degree score is calculated by measuring the proportion of non-static videos generated by the model. * Imaging Quality. Imaging Quality is measured by the MUSIQ [6] image quality predictor trained on the SPAQ [7] dataset, which is capable of handling variable-sized aspect ratios and resolutions. The frame-wise score is linearly normalized to [0, 1] by dividing 100, and the final score is then calculated by averaging the frame-wise scores across the entire video sequence.

References

1. Vbench: Comprehensive benchmark suite for video generative models. CVPR, 2024.
2. Emerging properties in self-supervised vision transformers. ICCV, 2021.
3. Learning transferable visual models from natural language supervision. ICML, 2021.
4. Amt: All-pairs multi-field transforms for efficient frame interpolation. CVPR, 2023.
5. Raft: Recurrent all-pairs field transforms for optical flow. ECCV, 2020.
6. Musiq: Multi-scale image quality transformer. ICCV, 2021.
7. Perceptual quality assessment of smartphone photography. CVPR, 2020.