mirror of
https://github.com/imputnet/cobalt.git
synced 2026-05-22 14:24:23 -05:00
[GH-ISSUE #566] Video length is missing in old software after cobalt's live render #11617
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/cobalt#11617
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @wukko on GitHub (Jun 10, 2024).
Original GitHub issue: https://github.com/imputnet/cobalt/issues/566
why does this happen?
to preserve privacy and maintain efficiency, cobalt merges & streams videos with ffmpeg right away, without ever storing or caching anything on disk.
as result, final file length cannot be predicted, so it's missing from headers of some downloaded files.
what's affected?
this happens only when live rendering is used, most often with youtube videos. older software (vegas pro, windows media player, default players on lower end android devices) cannot generate file length, so it's either missing or shows up as some obnoxious number like 4294967295.
what can be done about it?
at the moment, this is not something that can be fixed, as it's the nature of live rendering process.
however, in most cases, the issue can be worked around by using modern software instead. for playback, vlc media player can be used instead. other (and most accessible) playback option is the built-in media player in any modern web browser.
you can also "fix" files with missing timestamp by remuxing them with ffmpeg:
if you know how to solve this issue in cobalt's rendering pipeline, feel free to make a pull request!
previous related issues
these issues were closed in favor of this one, as they all describe the same problem, but in different apps:
@ari-party commented on GitHub (Jun 12, 2024):
I tried to replicate the described issue but I was unable to.
I downloaded 3 of the latest Fireship videos and the same for @homedesign369.
All videos showed the correct duration from ffprobe's
input.duration.And I was able to play all videos with the playback bar correctly showing the duration with Windows Media Player.
Could you possibly expand on what platforms (e.g. YouTube) this issue occurs on? And possibly link the videos for future contributors? (I won't be contributing to this issue.)
@synzr commented on GitHub (Jul 12, 2024):
Try to download any YouTube video (ex. this one) in 1080p resolution and H.264 codec to replicate this issue.
YouTube stores complete (video with audio) versions in 360p and 720p resolutions and H.264 codec for compatibility.
@ihatespawn commented on GitHub (Jul 12, 2024):
tried the same thing on the video that you linked with the settings you provided and the same thing happens
@lostdusty commented on GitHub (Jul 12, 2024):
I have the same issue has they.
@ihatespawn commented on GitHub (Jul 21, 2024):
telegram shows 0:00
@ihatespawn commented on GitHub (Jul 28, 2024):
possible solution (for yt): since you know the approximate (thanks for reminding me) length of the video (because you check if it's <180 minutes), why don't just send the header with that information?
@synzr commented on GitHub (Jul 28, 2024):
youtube stores the only approximate duration in the video database. you can see how youtube player adds or takes away the second(s) of video after loading it.
in theory, the forcing of duration in container header can create new problems with compatibility.
@wukko commented on GitHub (Jul 28, 2024):
do you know the exact final bit length of a remuxed video?
@ghost commented on GitHub (Aug 11, 2024):
got this issue in vlc too, but only for videos in h264, not av1
video of me reproducing the issue: https://youtu.be/slYl9DraXEA
@ItsOpenSourceSoftware commented on GitHub (Aug 19, 2024):
I hope this gets fixed soon
@inventor7777 commented on GitHub (Aug 27, 2024):
I hope so too