HLS Video capture laggy issue

[XX]

I found the HLS video captured is laggy when played with Windows default video player, but no issue in VLC player. Seems the video download in ".TS" was converted to mp4 after download. The issue was the mp4 generated does not have the correct tbn. With simple ffprobe test, I noticed the tbn was kept the same as ts container which is 90k, and this caused the issue mentioned above. When ts file converted to mp4 container, shouldn't the tbn changed as well?

I manually changed the tbn, and the issue is gone. I have no idea what is the mechanism used for the video convert, can you please look into the issue please?

Thanks

[mjs]

Mig the developer has said there is an issue when downloading HLS stream to mp4 but still leaves it the default way to download.

What is tbn ?  and how did you change it to correct issue ?

Just so you know there is a setting HLS as M2TS which doesn't produce a laggy video. I looked at a ffprobe of a m2ts file and it has the same

90k tbn. Maybe the m2ts container format is almost identical to the ts format so the downloaded file plays without the stuttering.

--

A vdh user

[Wild Willy]

Can we have a URL? And if it's one of those "there's dozens of them," just give us a
couple.

[XX]

What is tbn:

https://superuser.com/questions/1362410/what-is-fps-tbr-tbn-tbc-in-ffmpeg

To change tbn of a laggy video, I did:

 ffmpeg -i D:\test.mp4 -t 60 -video_track_timescale 18500 D:\test.mp4

And the issue was gone.

And for URL, try this as example:

https://docs.flowplayer.com/tools/stream-tester

I found that If the video is downloaded and saved as ts or m2ts, you can always use ffmpeg to covert to mp4 which automatically takes care of the tbn, thus no issues.

Thanks for reply.

[Wild Willy]

Before I did anything with VDH, I opened the Network Monitor to see what was there.
There was an HLS master manifest named playlist.m3u8. But it was not of the expected
type x-mpegurl. It was, rather, vnd.apple.mpegurl. I have encountered this often enough
that I believe it is a very frequent second choice for the type of the master manifest.

Anyway, I pumped that manifest through ffprobe & got the results you can see in the
attached file ffprobe.txt. You can see 3 Programs there, each with a video Stream & an
audio Stream. The 3 video Streams are of various resolutions. The audio Stream (note
the singular) is the same one in each Program. This is the sort of structure that has
always caused VDH to claim that the video & audio are separate & it has forced you to do
2 downloads in VDH, one for video, another for audio. Then you either play the 2 tracks
synchronously in VLC or you can merge the 2 tracks into a single file (in this case, MP4)
with either the VDH merging tool or ffmpeg.

I had every intention of downloading the highest resolution variant (happens to be
1280x720 here) with ffmpeg. But before I did that, I looked at the VDH menu. See
attached image #01. There were 6 variants marked audio only that were rather small, all
around 70K. These were pretty obviously of no interest. Then there were 3 variants
showing resolutions matching what you can see in the ffprobe report. Then one variant
not showing a resolution. Box typical of VDH giving you separate video & audio. I
downloaded the video & the audio with VDH. The video came in without an error. The
audio failed with the MP2T error that indicates I should be downloading with HLS as M2TS
enabled in the VDH settings. The audio download left just a part file of size 1K in the
target directory. Of course, VLC refused to play it. The video MP4 played but every few
seconds there was a hitch in the video. It jerked. You called it laggy. This isn't
really descriptive for me. The video seemed to skip a frame or 2 every few seconds. It
looked jerky. Lag to me refers to audio lagging video or video lagging audio. That's
not what was going on here. I didn't even have a usable audio track yet. The video was
jerky.

So then I changed the VDH setting to enable HLS as M2TS. For good measure, I also
reloaded the extension just to wipe the slate clean & start over. I had to reload the
page twice before VDH gave me the menu you can see in attached image #02. VDH
successfully downloaded this video as an M2TS file, as expected. It played in VLC
without the skips & jerks. VDH also downloaded the audio M2TS, which played fine in VLC.
So I had a silent video that looked good & a sound track that had no video. Typically,
you can play these synchronously in VLC. But VLC didn't like these 2 as synchronous
tracks. Played synchronously, it just played the audio & ignored the video.

So clearly I wanted to merge the 2 files. Attached file Merge log 1.txt shows how I did
that. You can see some ominous error messages in that log. Indeed, the merged file was
another silent video.

At this point, I figured I could probably extract the raw video & audio tracks from the 2
files & merge those. But honestly, the path of least resistance at this point was to
just download the thing with ffmpeg. That would avoid all this silliness with HLS as
M2TS & merging & whatnot. Just get the thing with ffmpeg. That's what you can see in
attached file Stream tester (ffmpeg) mp4 Log.txt. No skips & jerks, video & audio in a
single file from the outset so no merging, extracting, adjusting, nothing. Perfect in
one step.

I think your focus on tbn is a red herring. You can see in all of these logs that tbn,
when it is mentioned at all, is always 90K. What you've done is way more complicated
than what it has to be. Just get the thing with ffmpeg & be done with it.

[XX]

Thanks for your work Willy, and correct me with my issue description. "lagging" may not be the best way to describe a frame drop issue.

I downloaded the ts file from .m3u8 and re-encoded with h.264 then compared to the VDH generated one, the tbn seems to the only difference. It's the reason I made the post. I am aware I can use ffmpeg and get the job done. I just want to share what I found with my limited knowladge that may or may not be helpful to improve the VDH.

Thanks for your input.

[Wild Willy]

You're digging too deep. Yes, the stream manifest is a bunch of .ts chunks. But you're
skipping the benefits of ffprobe. You can see in both the ffprobe report & the ffmpeg
log that I posted that the streams are already h264. By downloading the .ts stream, you
are avoiding what ffmpeg does for you. What did you use to download the stream of
chunks? It couldn't have been ffmpeg because ffmpeg downloads the .ts chunks & creates
an mp4. Even if you were to use -map to isolate a single track out of the master
manifest, ffmpeg would still download an mp4. What tool did you use to get the raw
stream without it ending up as mp4?

I don't think anything is converted from ts to mp4. Ffprobe recognizes the variants as
mp4. The chunks being .ts is not really interesting. Most videos I've downloaded with
ffmpeg show the chunks are .ts. So it's kind of a side issue.

The tbn thing seems like a side issue as well.

The problem with VDH is the thing I mentioned above. When there is any kind of sharing
of audio tracks, like we have here, VDH completely misinterprets the master manifest.
Master manifest. You were looking at the stream manifest. This is too low a level. You
need to be looking at the master manifest. I've raised this issue with Michel & he
apparently is well aware of it. Is he doing anything about it? I certainly hope so but
I don't have any inside information. I'm just another user like most of us posting here.
My discussion with Michel is here:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/vZaB8PRM2U0

[mjs]

I've made an interesting discovery on this and you might have been looking at the wrong parameter in tbn. The more important parameter is tbr.

I did several downloads in both mp4 and m2ts in VDH. I terminated the downloads early so they're a few minutes each.

I also used ffmpeg on some downloads.

The mp4 files from VDH have a tbr number higher to the fps number while the m2ts files have a tbr number matching the fps.

Files downloaded with ffmpeg also have the tbr value the same as fps.

You can also ffprobe any master manifest and see that the tbr value is the same as fps.