{"id":"e88c175d-4630-4e00-8580-854b01cb6cc9","arxiv_id":"2508.08765","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"A framework estimates social networks' compression settings from a few uploaded videos and reproduces those artifacts locally, so deepfake detectors can be fine-tuned without direct platform access.","lead":"The paper introduces a tool that copies how YouTube, Facebook, and BlueSky compress videos, using just a small batch of uploaded clips. It lets researchers create realistic compressed deepfake training videos locally, without paying for platform APIs.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Missing negative control: the paper never compares EMU fine-tuning against generic H.264 re-encoding, so the estimated platform parameters in Eqs. (1)-(4) are not shown to be load-bearing.","rationale":"The reader's weakest_assumption centers on whether a single H.264 re-encode with averaged CRF generalizes across codecs and content-adaptive rate control. I agree that is a real modeling risk, but the more immediate threat to the central claim is the absence of a negative control: the experiments show EMU beats no fine-tuning, yet never test whether generic compression would do equally well. Without that comparison, 'matches degradation patterns' is not established even for H.264 platforms. I therefore consider the paper's contribution plausible and its protocol well designed, but the load-bearing inference needs an additional control and a direct artifact fidelity metric. The NT/YouTube gap in Fig. 2b further weakens the parity claim. These concerns leave the conditional verdict intact rather than forcing rejection; the authors should add the negative control and report error bars. This is a partial agreement with the reader because the reader identified a different weak spot, though both point to the need for more rigorous validation.","tokens_in":10605,"tokens_out":4475,"duration_ms":53323,"concrete_test":"In the Sec. 4.1 protocol, add a negative-control training condition: re-encode FF++ videos to the same output resolutions with H.264 at a fixed CRF (e.g., 28) or a per-video random CRF, without using any platform-estimated parameters. Fine-tune DenseNet, InceptionNet, XceptionNet, and ResNet-50 on these generic-compression videos and evaluate on the real Facebook/YouTube shared test sets. If the generic baseline reaches within 1–2 points of EMU TNR/TPR, then the parameter-estimation module is not load-bearing and the central claim is unsupported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim — that SNVSE's emulated data 'closely matches the degradation patterns of real uploads' and serves as a drop-in replacement for actual shared media — is supported only by fine-tuned detector TPR/TNR in Sec. 4.1 / Fig. 2. There is no direct fidelity check between emulated and shared videos, and no baseline against generic compression. Any H.264 re-encode at matched resolution introduces blocking and ringing artifacts that a deepfake detector could latch onto; if a fixed-CRF or random-CRF re-encode yields the same TNR recovery, then the two-parameter platform model of Eqs. (3)-(4) is not what drives the reported improvement. The NT/YouTube gap in Fig. 2b is a secondary symptom: EMU is consistently below S for that class, contradicting the 'comparable' claim without verification of the thresholding hypothesis. The paper's own Sec. 5 also concedes that frame rate and pixel format are not estimated, so the emulator covers only a subset of encoding decisions.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes SNVSE, a framework that emulates social-network video compression for deepfake detection. From a small set of paired original/shared videos, it estimates a per-video CRF by matching the bitrate of an H.264 re-encode to the shared video (Eq. 1), stores input/output resolution and CRF triplets (Eq. 2), and for new videos selects an output resolution by nearest match and a CRF by averaging over the database for that resolution (Eqs. 3-4). The emulated videos are then used to fine-tune four CNN detectors on FF++ data, and the paper reports TPR/TNR on test videos shared via Facebook, YouTube, and BlueSky in 2021 and 2025. The main claims are that the emulated videos closely match real platform degradation and that fine-tuning on emulated videos gives performance comparable to fine-tuning on actually shared videos. A bootstrap ablation suggests that at least 30 shared videos per resolution are needed for stable CRF estimates.","tokens_in":10837,"tokens_out":4588,"duration_ms":51893,"significance":"If the central claim is established, the framework is practically valuable: it would allow scalable generation of platform-like compressed training data without API access, and the code release is a concrete contribution. The evaluation design is partially sound in that CRF parameters are estimated from validation videos and tested on a held-out test set, so the setup is not circular. The extension to 2025 platform versions and BlueSky is a useful generalization check. However, the evidence currently falls short of the fidelity claim: there is no direct comparison of emulated versus shared video quality, and no baseline against generic H.264 re-encoding, which is necessary to show that the estimated platform parameters, rather than compression in general, drive the observed recovery.","major_comments":[{"comment":"The experimental protocol compares NS, S, and EMU fine-tuning but never compares against generic H.264 re-encoding at matched resolutions. Since an emulated video is exactly an H.264 re-encode with a resolution change and a CRF taken from [21,50], any compression pipeline could introduce artifacts that a detector latches onto. If a fixed-CRF or random-CRF re-encode produces the same TNR recovery, then the platform-specific parameter estimation in Eqs. (1)-(4) is not load-bearing. Please add this negative control and report whether the two-parameter model outperforms it.","section":"Sec. 4.1, Fig. 2"},{"comment":"The abstract's claim that emulated data 'closely matches the degradation patterns of real uploads' is not directly measured anywhere in the paper. Section 4.1 reports only downstream detector TPR and TNR; there is no PSNR/SSIM comparison, no bitrate or artifact-distribution analysis, and no visual or forensic-feature comparison between emulated and shared videos. Task-level equivalence is a necessary condition, but it does not by itself establish fidelity of the degradation patterns. Please add a direct fidelity check or soften the claim.","section":"Abstract; Sec. 4.1"},{"comment":"The 'comparable performance' claim rests on point estimates without error bars or significance tests, and one cell directly contradicts it: for NeuralTextures on YouTube, EMU TNR is consistently below S TNR across all four detectors. The paper attributes this to sub-optimal thresholding but provides no verification. Please provide confidence intervals or error bars, and either verify the thresholding explanation or restrict the claim to the cells where it holds.","section":"Fig. 2b, Sec. 4.1"}],"minor_comments":[{"comment":"If no CRF in [21,50] satisfies the bitrate constraint, the minimization in Eq. (1) is over an empty set; please define the fallback behavior explicitly.","section":"Eq. (1)"},{"comment":"The text says the 2025 results are 'consistent' with Section 4.1, but the Facebook and YouTube cells are based on only 50 validation videos per class and show visible gaps; please qualify this statement and note the reduced statistical power.","section":"Sec. 4.2, Fig. 3"},{"comment":"Frame rate and pixel format are said in Section 5 to be future work, but this limitation should be stated in Section 3.1 where the encoding parameters are defined, since the emulator currently covers only a subset of encoding decisions.","section":"Sec. 3.1 and Sec. 5"},{"comment":"The references for DenseNet, InceptionNet, and XceptionNet are application papers rather than the original architecture papers; please cite the original sources.","section":"References [16, 17, 19]"},{"comment":"The fine-tuning procedure is described only as following [23]; please report the learning rate, number of epochs, batch size, and any data augmentation used, even if they match the prior work, to make the experiments reproducible without consulting the previous paper.","section":"Sec. 4"}],"recommendation":"major_revision","confidential_remarks":"The paper fits the workshop scope and the code release is a strength. The main issue is that the central claim needs a generic-compression baseline and direct fidelity metrics; both are obtainable within the manuscript's scope. The related-work and experimental protocol lean heavily on the authors' own prior studies, which is understandable but makes a crisp novelty statement relative to those works especially important."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nQuick take: this is a solid, practical contribution that should get reviewed. The paper builds the first video-specific social-network compression emulator, estimates CRF and output resolution from a few dozen uploaded videos, and shows that fine-tuning detectors on emulated videos recovers most of the performance lost when real shared videos are used. That is a genuinely useful result for the forensic deepfake community.\n\nWhat's new: prior work did this for images (TrueFace, TrueFake), and Marcon et al. studied shared videos, but nobody proposed this kind of parameter-estimation pipeline for video. The method itself is simple—bitrate matching per video, averaged CRF per output resolution—which is a feature, not a flaw. The validation on 2025 uploads from Facebook, YouTube, and BlueSky, plus the bootstrap ablation on minimum videos per resolution, are the right kinds of evidence. The code link is a plus.\n\nWhere it's soft: the paper's headline claim is that emulated videos 'closely match degradation patterns of real uploads.' That is never directly tested. There is no PSNR/SSIM comparison or artifact-level analysis. Instead, the evidence is indirect: fine-tuned detector TPR/TNR. That's not nothing, but it lets the emulator off the hook—a detector can recover from any reasonable H.264 re-encode. You need a negative control: fine-tune on generic H.264 re-encodes with random or fixed CRF, and show the estimated platform parameters actually matter. Without that, the two-scalar model (resolution + average CRF) might not be load-bearing. The stress-test note is right. Also, the NT/YouTube gap is waved away as thresholding; that's a small unexplained inconsistency. And the main figures are point estimates without error bars; the 2025 experiments use only 50 shared videos for Facebook/YouTube, so variability could be substantial. The paper itself concedes frame rate and pixel format are not estimated, so it covers only part of the encoding pipeline.\n\nBottom line: the practical claim—you can train a decent detector without API access—is probably true. The scientific claim—that the emulator captures platform-specific compression—needs the negative control and direct fidelity measures. The paper deserves serious peer review. I'd ask the authors for those experiments in revision.","headline":"A useful, practical emulator that mostly delivers, but the missing generic-compression baseline leaves the platform-specific claim under-supported.","tokens_in":11357,"tokens_out":3546,"would_cite":true,"duration_ms":38191,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Detectors fine-tuned on locally emulated social-network compression match those trained on real platform uploads.","keywords":["video deepfake detection","social network compression","compression emulation","constant rate factor estimation","H.264 re-encoding","fine-tuning for robustness","multimedia forensics"],"falsifier":"Take a set of videos covering varied content, share them on platforms whose encoders use content-adaptive rate control or VP9/AV1, estimate CRFs with the paper's bitrate-matching rule, and compare detector true-negative rates after fine-tuning on SNVSE emulations versus on actual uploads; if the emulation fine-tuning falls measurably short on those platforms, the averaged-CRF model is the point of failure. The paper's own NeuralTextures/YouTube discrepancy in Fig. 2b is a candidate early signal for such a failure.","tokens_in":10418,"feed_emoji":"🎭","tokens_out":6258,"duration_ms":57970,"temperature":0.7,"pith_summary":"The paper argues that the gap between lab-trained deepfake detectors and real-world performance is mostly caused by the aggressive, proprietary compression that social networks apply to uploaded video, and that this compression can be reproduced locally without API access. To show this, it builds the Social Network Video Sharing Emulator (SNVSE), which estimates, from fewer than fifty uploaded videos per resolution, the output resolution and average constant-rate factor a platform applies, then re-encodes any local video with H.264 to match. On a standard face-manipulation benchmark, detectors fine-tuned on these emulated videos perform comparably to detectors fine-tuned on videos actually shared on Facebook, YouTube, and BlueSky, for both 2021-era and 2025-era platform pipelines. If correct, the result makes realistic deepfake training data cheap and API-free, and gives a practical way to keep detectors current as platforms change their encoders.","feed_headline":"Emulated compression trains deepfake detectors as well as real uploads","feed_subtitle":"Fewer than 50 uploaded videos per resolution yield local emulations that restore real-world detection accuracy.","key_machinery":"The central machinery is the two-module Social Network Video Sharing Emulator (SNVSE). A Parameters Estimation Module takes pairs of original and platform-shared videos and, for each pair, finds the smallest integer CRF in 21–50 whose H.264 re-encode at the shared video's resolution has bitrate at most that of the shared video, storing triplets (input resolution, output resolution, estimated CRF). An Encoding Emulation Module then maps any new video to the nearest stored input resolution, takes the output resolution from that entry, and re-encodes with the average CRF across entries sharing that output resolution. This reduces platform-specific transcoding to one resolution mapping plus one averaged CRF per output resolution, which is what makes large-scale local emulation tractable.","core_discovery":"The paper's central claim is that platform-specific social-network compression can be reduced to two scalar parameters—an output resolution and an average constant rate factor (CRF)—estimated from a small set of original/shared video pairs, and that re-encoding with those parameters reproduces the degradation that matters for deepfake detectors. The authors evaluate this on a standard face-manipulation dataset with real and fake videos shared on Facebook and YouTube in 2021 and on BlueSky, Facebook, and YouTube in 2025. They report that detectors fine-tuned on emulated videos recover most of the accuracy lost when testing on actual shared videos, and in most configurations match detectors fine-tuned on the true shared media. The one reported shortfall is the NeuralTextures manipulation on YouTube, where emulated fine-tuning improves true-negative rate less than shared fine-tuning does; the authors attribute this to fixed-threshold evaluation rather than to a failure of the emulator.","pith_inferences":["If a single averaged CRF per resolution is enough, the same parameter-estimation trick should extend to other codecs and to image sharing; platforms using VP9 or AV1, or content-adaptive rate control, are the natural stress test for the averaging assumption.","The framework implicitly predicts that a detector fine-tuned on emulated data from several platforms will generalize across platforms; that cross-platform generalization is not directly tested and would be a cheap extension.","One could use the emulator to quantify how much of the lab-to-real gap is compression alone versus other platform effects, such as watermarking, container changes, or audio re-encoding, by ablating which emulated factors are applied."],"forward_implications":["Fine-tuning on SNVSE-emulated videos restores most of the true-negative rate lost when a detector trained on unshared video meets Facebook- or YouTube-compressed fakes.","The framework needs fewer than fifty shared videos per resolution; the bootstrap ablation indicates at least thirty per resolution for stable CRF estimates.","Emulation transfers to current platform pipelines (2025 Facebook, YouTube, and BlueSky) as well as to the original 2021-era uploads.","Because emulation runs locally, any existing video dataset can be processed at scale without API quotas, sharing limits, or per-video costs.","Videos at resolutions absent from the database are handled by nearest-neighbor resolution matching plus averaged CRF, so coverage is not limited to the exact resolutions observed."],"supporting_citations":[{"why":"Supplies the shared-video dataset and the detector training/evaluation protocol that the experiments follow.","marker":"[23]"},{"why":"Provides the original face-manipulation video benchmark from which the real and fake videos are drawn.","marker":"[34]"},{"why":"Supplies the bootstrap resampling method used to establish the minimum number of shared videos per resolution for stable CRF estimation.","marker":"[40]"},{"why":"Establishes the precedent of estimating social-network compression parameters for images and motivates extending the approach to video.","marker":"[22]"},{"why":"Documents the compression-based performance gap for recent fake images on social platforms, motivating the video emulator.","marker":"[15]"},{"why":"Surveys media forensics on social platforms and frames platform compression as a core challenge the framework addresses.","marker":"[25]"},{"why":"Prior work on compressed deepfake video detection that defines the setting this framework targets.","marker":"[33]"}],"fun_headline_variants":["Two parameters emulate social compression for deepfake detection","Deepfake detectors match real uploads with emulated compression","Small sample of uploads yields platform-accurate deepfake training","Emulating social video compression fixes deepfake detector gap","Reduce social compression to two numbers for deepfake detection"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that re-encoding a video once with H.264 at a fixed quality setting and a changed resolution captures the visual degradation a platform's own transcoding produces, well enough that fine-tuning on those re-encoded videos transfers to actual platform uploads.","fun_headline_variants_meta":{"raw":{"variants":["Two parameters emulate social compression for deepfake detection","Deepfake detectors match real uploads with emulated compression","Small sample of uploads yields platform-accurate deepfake training","Emulating social video compression fixes deepfake detector gap","Reduce social compression to two numbers for deepfake detection"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000227,"raw_usage":{"total_tokens":1466,"prompt_tokens":932,"completion_tokens":534,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":548,"completion_tokens_details":{"reasoning_tokens":455}},"tokens_in":548,"tokens_out":534,"duration_ms":5906,"temperature":1.0,"reasoning_tokens":455,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T17:32:21.873206+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a set of videos covering varied content, share them on platforms whose encoders use content-adaptive rate control or VP9/AV1, estimate CRFs with the paper's bitrate-matching rule, and compare detector true-negative rates after fine-tuning on SNVSE emulations versus on actual uploads; if the emulation fine-tuning falls measurably short on those platforms, the averaged-CRF model is the point of failure. The paper's own NeuralTextures/YouTube discrepancy in Fig. 2b is a candidate early signal for such a failure.","supporting_citations":[{"cited_title":"Detection of manipulated face videos over social networks: A large-scale study,","cited_arxiv_id":null,"evidence_quote":"Supplies the shared-video dataset and the detector training/evaluation protocol that the experiments follow."},{"cited_title":"Face- Forensics++: Learning to Detect Manipulated Facial Images,","cited_arxiv_id":null,"evidence_quote":"Provides the original face-manipulation video benchmark from which the real and fake videos are drawn."},{"cited_title":"Bootstrap methods: another look at the jackknife,","cited_arxiv_id":null,"evidence_quote":"Supplies the bootstrap resampling method used to establish the minimum number of shared videos per resolution for stable CRF estimation."},{"cited_title":"TrueFace: a Dataset for the Detection of Synthetic Face Images from Social Networks,","cited_arxiv_id":null,"evidence_quote":"Establishes the precedent of estimating social-network compression parameters for images and motivates extending the approach to video."},{"cited_title":"Media forensics on social media platforms: a survey,","cited_arxiv_id":null,"evidence_quote":"Surveys media forensics on social platforms and frames platform compression as a core challenge the framework addresses."},{"cited_title":"Detecting compressed deepfake videos in social networks using frame-temporality two-stream convolutional network,","cited_arxiv_id":null,"evidence_quote":"Prior work on compressed deepfake video detection that defines the setting this framework targets."}],"review_version":2}