imputnet
Video length is missing in old software after cobalt's live render
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:
ffmpeg -i your_video_file_here.mp4 -c copy output_name_for_file.mp4
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:
- #94
- #204
- #255
- #345
- #348
- #374
- #420
- #483
- #564
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.)
I tried to replicate the described issue but I was unable to.
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.
tried the same thing on the video that you linked with the settings you provided and the same thing happens
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?
possible solution (for yt): since you know the length of the video (because you check if it's <180 minutes), why don't just send the header with that information?
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.
since you know the length of the video
do you know the exact final bit length of a remuxed video?
got this issue in vlc too, but only for videos in h264, not av1 video of me reproducing the issue: https://youtu.be/slYl9DraXEA
