{"id":"7880d400-9c76-4d1e-b1b9-e51ff8b8f08c","arxiv_id":"2412.07889","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A scalable streaming system for event cameras based on Media over QUIC trades a small accuracy drop for low latency by letting receivers drop data tracks.","lead":"This paper shows that a vision system for event cameras, which record pixel brightness changes instead of frames, can tolerate heavy data loss, and proposes a streaming method that drops parts of the event stream to meet tight latency goals. The work matters because it could let low-power cameras send data to remote GPU servers for real-time object detection without losing much accuracy.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 5 ms and 50 ms latency 'targets' are supported only by mean latency; the reported maximum latencies in the headline configurations exceed the target by 18x–190x, so the central low-latency claim is not actually established.","rationale":"The reader's weakest assumption concerned external validity of the simulated network, but the more immediate and load-bearing problem is internal: even within the reported simulation, the headline latency targets are only met on average. The paper's own tables show max latencies far above the nominal targets in the very configurations used to support the abstract claims, and no percentile statistics are given. Since the motivating application is low-latency real-time vision, a mean latency below 5 ms is not sufficient evidence for 'meeting a 5 ms end-to-end latency target.' This concern is concrete and testable from data the authors already possess, and it does not depend on any assumption about real-world networks. The verdict remains CONDITIONAL because the issue is addressable by reporting tail metrics and by restating the claim precisely; it does not by itself invalidate the proposed system, but it does mean the central claim as currently worded is unsupported. I therefore disagree with the reader's identification of the weakest assumption, while keeping the same overall verdict.","tokens_in":15539,"tokens_out":5318,"duration_ms":55254,"concrete_test":"Re-run the strict and relaxed experiments with per-window end-to-end latency logging (timestamp at publisher send versus receiver reconstruction) on the 10-video dataset, and report p50, p95, p99, maximum, and the fraction of 50 ms windows exceeding the nominal target for every (B, N) row in Tables 2 and 3. Focus on the headline rows B=100/N=10 (5 ms target) and B=100/N=5 (50 ms target). If p99 exceeds 5 ms or 50 ms respectively, the headline claim must be downgraded from 'meets a latency target' to 'achieves a target on average'; if p99 is below the target, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim rests on treating a target latency as if it were met, but the reported metric is the mean. In the configuration with the best strict-target mAP (Table 2, B=100 Mbit/s, N=10), mean latency is 3.5 ms while the maximum is 91.1 ms; the N=5 configurations at 50 and 100 Mbit/s have maxima of 108.2 and 85.5 ms. For the relaxed target (Table 3, B=100, N=5), mean latency is 32.5 ms but the maximum is 190.6 ms, and the B=25 row has a maximum of 8349.9 ms. The paper itself notes that 'our maximum latency often exceeds the threshold' (§5.5), yet the abstract and §5.4 state that the system 'can meet' a 5 ms target and 'maintain' sub-4 ms latency. For low-latency real-time vision, the relevant quantity is a tail quantile (e.g., p95, p99, or worst case), not the mean. The track selection algorithm (§5.2) adjusts chunk size by ±20% based on the last measured latency and subscribes to new tracks one at a time with handshake delays, so it plausibly controls average behavior but has no mechanism to bound the tail. The reader's simulation-fidelity concern is an external-validity issue; the tail-latency issue is internal, because the headline latency claim is unsupported by the paper's own reported data.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript presents a systems study of lossy, receiver-driven adaptive streaming for event-camera data targeting low-latency object detection. The authors first evaluate the resilience of the RVT detector to event loss on ten eTraM videos, finding modest mAP degradation even at high loss. They then partition the event stream into complementary MoQ tracks with two strategies and propose a receiver-side algorithm that adjusts chunk size and track subscriptions from measured latency. On a simulated single-relay network with tc/tbf bandwidth limits, the headline results are an average mAP reduction of 0.36 at a 5 ms mean-latency target and 0.19 at a 50 ms target. The paper also reports that lossy streaming occasionally improves detection accuracy.","tokens_in":15878,"tokens_out":7873,"duration_ms":76223,"significance":"This is a worthwhile first systems contribution, and it is clearly scoped as an initial evaluation rather than a full deployment study. The testbed (10 real videos, Dockerized moq-rs relay, tc/tbf shaping, RVT detector) is concrete and reproducible in principle, and the experiments directly measure the latency/mAP tradeoff that the proposed protocol claims to control. The observation of detector resilience and even accuracy improvement under high event loss is interesting for the event-vision community. However, the central latency claim is currently not established because the reported evidence uses means and ignores tail latency, and the evaluation is limited to a single simulated topology. The core ideas are defensible, so these issues are fixable within scope.","major_comments":[{"comment":"The claim that the system 'can meet' a 5 ms (or 50 ms) end-to-end latency target is supported only by mean latency, not by a latency guarantee. In Table 2, the configuration with the best strict-target mAP (B=100 Mbps, N=10) has mean latency 3.5 ms but maximum 91.1 ms; the N=5 rows at 50 and 100 Mbps have means of 2.8 and 1.3 ms but maxima of 108.2 and 85.5 ms. In Table 3, the relaxed-target configuration at 100 Mbps has mean 32.5 ms and maximum 190.6 ms, and the 25 Mbps row has a maximum of 8349.9 ms. Section 5.5 itself states that 'our maximum latency often exceeds the threshold,' so the abstract and conclusion should not state that the latency target is met. Please report tail quantiles (p95/p99 or worst-case per configuration) and either redefine the target as a percentile or restrict the claims to what the data support.","section":"Abstract, Sec. 5.4, Sec. 5.5, Tables 2-3, Conclusion"},{"comment":"The adaptation algorithm has no mechanism for bounding the latency tail. It reactively adjusts the chunk size by ±20% based on the last measured latency, adds one new track at a time after a subscription handshake, and unsubscribes only after a spike has already occurred. The measured maxima (e.g., 190.6 ms under a 50 ms target) are consistent with this reactive design. The paper should analyze the tail behavior explicitly, for example by plotting the per-time-window latency distribution and by stress-testing the algorithm with bursty source rates or abrupt bandwidth changes, rather than relying on means over the full video.","section":"Sec. 5.2, Sec. 5.5"},{"comment":"The evaluation is limited to a simulated network: pre-recorded videos are replayed with inserted timing delays through one Dockerized MoQ relay under tc/tbf shaping. This setup does not include real network delay, jitter, loss, or multi-relay topologies, even though the claimed application (smart-city streaming) would operate on such networks. The track-desynchronization behavior that drives the algorithm could differ under real network conditions. I ask for at least one validation with an emulator that injects realistic delay/jitter/loss (e.g., netem) or a clear statement limiting all conclusions to the simulated single-relay setting.","section":"Sec. 5.3, Sec. 3, Sec. 6"}],"minor_comments":[{"comment":"Reporting only means across 10 videos hides the spread; please add per-configuration standard deviations or per-video results, and state how many repetitions (if any) were run for each configuration.","section":"Tables 2-3"},{"comment":"The sensitivity analysis that selects E=250 and E=2500 is not reported; please include the sensitivity curves and state whether E was chosen on the same test videos used for the final evaluation.","section":"Secs. 5.4-5.5"},{"comment":"The conclusion that temporal event distribution is not a major factor rests on only two bandwidth levels (25 and 50 Mbps); consider acknowledging this limitation or testing across the full bandwidth range.","section":"Sec. 4"},{"comment":"The 'up to a 26-second increase in average latency' for the even-partitioning strategy is stated without measurement details; please provide the experiment that produced this number.","section":"Sec. 5.1"},{"comment":"The explanation for mAP improvement under high loss as 'noise filtering' is plausible but post hoc; a controlled experiment with synthetic noise events would make that interpretation more convincing.","section":"Sec. 5.5"},{"comment":"The paper states that source code will be released upon publication; please confirm availability or provide a reproducibility appendix, since the systems claims depend on exact relay and timing behavior.","section":"Sec. 5.3"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is within scope for a systems-oriented venue and the related work is adequately positioned. The main issue to watch is the gap between the headline latency claim and the reported maxima; if the authors rework the evaluation around tail metrics and qualify the simulation scope, the paper could be suitable for publication. There are no evident novelty-disclosure concerns."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read it. The novel piece is real: first evaluation of receiver-driven rate adaptation for raw event-camera data over Media over QUIC, and the finding that RVT tolerates end-weighted loss better than even loss is useful for anyone building event streaming. The bucket-based track partitioning with sequential event assignment is simple and sensible, and the desynchronization observation (more tracks hurting throughput) is a genuine systems insight. Credit where due: 10 videos, a Dockerized MoQ relay, tc/tbf throttling, and a state-of-the-art detector is a reasonable first evaluation.\n\nThe soft spot is internal, not just about simulation fidelity. The paper's central claim is that the system \"can meet\" a 5 ms latency target with mAP drop 0.36 and a 50 ms target with drop 0.19. But the reported metric is the mean. In the best strict configuration (Table 2, B=100, N=10), mean latency is 3.5 ms and maximum is 91.1 ms. For the relaxed target (B=100, N=5), mean is 32.5 ms and maximum is 190.6 ms; at B=25 the maximum is 8.3 seconds. The paper itself concedes \"our maximum latency often exceeds the threshold\" (§5.5), yet the abstract and intro say \"can meet.\" For low-latency real-time vision, tail latency is the relevant quantity. This is not a minor wording issue; it undercuts the headline claim as stated. The algorithm adjusts chunk size by ±20% based on the last latency sample, so it controls the average but has no mechanism to bound the tail.\n\nAlso minor: no error bars or per-video variance anywhere, best configurations are selected via sensitivity analysis, and code is promised only upon publication. The simulation fidelity is a real external-validity concern but secondary to the tail-latency issue.\n\nWho is this for: event-vision and multimedia streaming researchers, especially people building edge-to-server pipelines. It deserves a serious referee, but the authors need to redo the latency analysis as tail quantiles and revise the claims before acceptance.","headline":"A solid first systems study of receiver-driven rate adaptation for event streams, but the headline latency claim rests on means while the reported maxima exceed the targets.","tokens_in":16390,"tokens_out":1486,"would_cite":true,"duration_ms":14445,"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":"The paper shows that latency-driven track dropping lets event-camera streams meet a 5 ms latency target with only a 0.36 mAP drop on object detection.","keywords":["event camera","dynamic vision sensor","streaming","rate adaptation","Media over QUIC","object detection","recurrent vision transformer","latency"],"falsifier":"Run the identical track-selection system with a live event camera transmitting over a real network, using the same test scenes, and measure end-to-end latency and object detection mAP under matching bandwidth limits; if the 5 ms target cannot be met with an mAP reduction around 0.36 at 100 Mbps, the simulated-network assumption is falsified.","tokens_in":15361,"feed_emoji":"⚡","tokens_out":7633,"duration_ms":66083,"temperature":0.7,"pith_summary":"The paper argues that event-based camera streams, which record asynchronous brightness changes rather than frames, can be transmitted over a rate-adaptive streaming system without sacrificing much object-detection accuracy. It first shows that a recurrent vision transformer for object detection withstands heavy event loss, losing only 0.17 mAP when 64.9% of events are discarded. It then partitions each time window of events into multiple complementary tracks carried over Media over QUIC, and has the receiver subscribe or unsubscribe tracks to hold end-to-end latency at a target. With a 5 ms target on a simulated small network, average mAP drops only 0.36; with a 50 ms target it drops 0.19. A reader should care because this suggests low-power event cameras can offload heavy vision computation to remote servers while keeping real-time response.","feed_headline":"Event streams hit 5 ms latency with small accuracy loss","feed_subtitle":"Receiver-driven track dropping keeps the object detection mAP loss under 0.4.","key_machinery":"The carrying mechanism is a two-part design: a bucket-based event partitioning scheme and a latency-driven track selection algorithm. For each 50 ms window, events are divided sequentially across N tracks, with each track carrying at most E events per window, so reconstruction is a simple concatenation. The receiver measures the time between a track's send time and reconstruction, and if the latency exceeds the target L it reduces the chunk size by 20%, which maps to dropping one or more track subscriptions; if latency is below target, it increases the chunk size and subscribes to more tracks. Because the tracks are complementary, the receiver's subscription count directly sets the received event rate, and thus trades accuracy against latency. The other key ingredient is the demonstration that the detection model tolerates lossy event streams, which makes the dropped-track regime viable.","core_discovery":"The central claim is that receiver-driven rate adaptation of raw event data is feasible and effective: even with dramatic data loss, object detection degrades gracefully, so a streaming system can drop data to meet latency targets. The authors establish this by first measuring the loss tolerance of a recurrent vision transformer on a traffic-monitoring event dataset, then building a multi-track streaming system where the receiver adjusts the number of subscribed tracks based on measured chunk latency. They report that with a 5 ms end-to-end latency target and sufficient bandwidth, mean latency stays under 4 ms with an average mAP reduction of 0.36, and with a relaxed 50 ms target the average mAP reduction drops to 0.19. The paper also observes that lossy streaming sometimes outperforms the lossless baseline because event dropping can act as a noise filter when the camera's pixel sensitivity is high.","pith_inferences":["On a real network, the relay desynchronization observed in simulation—where higher track counts sometimes underperform—is likely to become more pronounced, so the paper's track-count tradeoff may shift and deserves a live-network evaluation.","The bucket partitioning ignores event semantics; a track-selection scheme that weights tracks by spatial or temporal importance could push the latency/accuracy tradeoff further than uniform buckets.","The claimed noise-filter effect implies that adaptive streaming could be combined with application-level event-rate normalization, potentially making detection accuracy more robust across cameras with different pixel sensitivities.","The 20% multiplicative chunk-size step is a simple controller; a controller using a moving average of received data rate, which the paper itself suggests, could eliminate the observed latency thrashing at relaxed targets."],"forward_implications":["Event cameras can be deployed on low-power edge devices while heavy object-detection inference runs on remote servers, as long as the network can carry a latency-adaptive subset of the event stream.","Receiver-driven rate adaptation, not just sender-side compression, is a viable tool for event-based vision, and the same track-selection algorithm can be applied to other real-time event-based applications.","For multi-consumer setups, one relay can serve both a low-latency application receiving few tracks and an archival server subscribing to all tracks, since Media over QUIC supports multiple receivers with different subscriptions.","With a relaxed 50 ms latency target, the system achieves an mAP reduction as low as 0.19, suggesting that high-accuracy event-based detection does not require lossless full-rate transmission.","Lossy streaming can sometimes improve detection accuracy relative to the lossless stream, because dropping events can normalize event-count distributions and act as noise filtering, which motivates rate-normalization research."],"supporting_citations":[{"why":"It supplies the recurrent vision transformer model used to measure detection mAP under event loss.","marker":"[26]"},{"why":"It provides the traffic-monitoring event dataset and the reference model weights used in all experiments.","marker":"[65]"},{"why":"It provides the Media over QUIC publisher, subscriber, and relay implementation used in the streaming system.","marker":"[33]"},{"why":"It supplies the description of Media over QUIC as a low-latency streaming protocol with tracks and relay-based adaptation.","marker":"[28]"},{"why":"It explains event-camera pixel-sensitivity feedback control, used to interpret the noise-filter effect and variable event rates.","marker":"[17]"},{"why":"It surveys event-based vision and DVS event representation, providing the formal definition of events and the context for why streaming is needed.","marker":"[22]"}],"fun_headline_variants":["Event vision streams at 5 ms with tiny mAP drop","Receiver-driven event streaming keeps vision loss under 0.4","Scalable event streaming cuts latency, not accuracy","Drop event streams for speed, keep object detection sharp","Event-based video streams hit 5 ms latency, mAP dips slightly"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The results depend on the simulated network—pre-recorded event videos replayed through a single Dockerized Media over QUIC relay with traffic-control bandwidth limits—faithfully reproducing the latency, jitter, and relay desynchronization of a real event-camera streaming deployment; if real networks desynchronize tracks differently, the track-selection algorithm's latency/accuracy tradeoff could be worse.","fun_headline_variants_meta":{"raw":{"variants":["Event vision streams at 5 ms with tiny mAP drop","Receiver-driven event streaming keeps vision loss under 0.4","Scalable event streaming cuts latency, not accuracy","Drop event streams for speed, keep object detection sharp","Event-based video streams hit 5 ms latency, mAP dips slightly"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000305,"raw_usage":{"total_tokens":1758,"prompt_tokens":963,"completion_tokens":795,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":579,"completion_tokens_details":{"reasoning_tokens":712}},"tokens_in":579,"tokens_out":795,"duration_ms":7058,"temperature":1.0,"reasoning_tokens":712,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T18:25:57.469963+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the identical track-selection system with a live event camera transmitting over a real network, using the same test scenes, and measure end-to-end latency and object detection mAP under matching bandwidth limits; if the 5 ms target cannot be met with an mAP reduction around 0.36 at 100 Mbps, the simulated-network assumption is falsified.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It provides the traffic-monitoring event dataset and the reference model weights used in all experiments."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It provides the Media over QUIC publisher, subscriber, and relay implementation used in the streaming system."},{"cited_title":"Erinc, and Ali C","cited_arxiv_id":null,"evidence_quote":"It supplies the description of Media over QUIC as a low-latency streaming protocol with tracks and relay-based adaptation."},{"cited_title":"Davison, Jörg Conradt, Kostas Daniilidis, and Davide Scaramuzza","cited_arxiv_id":null,"evidence_quote":"It surveys event-based vision and DVS event representation, providing the formal definition of events and the context for why streaming is needed."}],"review_version":1}