New beta with new co app. Just some feedback.

[mjs]

I've tried out the new beta along with the new co app, it works a lot better for HLS streams.

I see  a ffmpeg process now when using quick side download & side download.

Wasn't this held back because of licensing ?

But I guess this is what has fixed audio / video sync issues. That leads into another big problem which is fixed in stuttery video for mp4 files. The resulting mp4 file is smooth and free of the judder. Now I don't have to suggest to use M2TS.

But it seems the download can't be terminated early when using quick side download or side download. No file is generated.

The side downloading also works for Twitter videos.

One issue, embedded YouTube video doesn't seem to be detected https://www.reddit.com/r/videos/

[jcv...@gmail.com]

Thanks for the feedback.

jerome

[Paul Rouget]

On Wednesday, October 4, 2023 at 2:25:36 PM UTC+8 mjs wrote:

I've tried out the new beta along with the new co app, it works a lot better for HLS streams.

I see  a ffmpeg process now when using quick side download & side download.

Wasn't this held back because of licensing ?

It was. But that was solved (OpenSSL v3 allowed linking with ffmpeg).

 

But it seems the download can't be terminated early when using quick side download or side download. No file is generated.

You mean, if you stop the download there is no file generated?

 

One issue, embedded YouTube video doesn't seem to be detected https://www.reddit.com/r/videos/

Noted. Thanks.

 

[mig]

On Wednesday, October 4, 2023 at 8:25:36 AM UTC+2 mjs wrote:

Wasn't this held back because of licensing ?

Yes, but the library that blocked the feature, openssl, changed its licensing model, so we could move on with compiling the coapp under GPL license.

 

One issue, embedded YouTube video doesn't seem to be detected https://www.reddit.com/r/videos/

Do you detect (and download) the video from this page: http://courierchess.com/ ?

[mjs]

> You mean, if you stop the download there is no file generated?

Correct, ffprobe reports on the file :

[mov,mp4,m4a,3gp,3g2,mj2 @ 000001e71784ad00] moov atom not found
Nature_and_Us - A History through Art episode 1 - video Dail-1.mp4: Invalid data found when processing input

[mjs]

> Do you detect (and download) the video from this page: http://courierchess.com/ ?

Yes that one is detected, seems on the reddit link no videos detected.

Here is another example not detected : https://torrentfreak.com/top-10-most-torrented-pirated-movies/

[Wild Willy]

On the subject of terminating downloads, I have always found that if you click the Stop
button on the VDH status menu, sometimes you get a usable file, sometimes you don't.
It's always been like that. But if you're using ffmpeg now, the Stop button should not
get you to simply kill ffmpeg. You need to send it q. When I have been using ffmpeg to
download something, I can type q in the command window & it will stop the download. I
don't even have to follow the q with Enter. Just type q & a few moments later, ffmpeg
stops & leaves you with a file you can play. Is that what you are doing inside VDH now?
Or should I say, inside the CoApp?

Just out of curiosity, mjs. Have you tried to repair the file that is missing the moov
atom? I have wanted to try that but I haven't encountered a situation like this since we
learned about the respeeding trick. I would try to copy the damaged file to a raw file,
then try to copy that into a new file & see if ffmpeg figures out what to do with it. I
don't know if you have to create raw files of each track or if you can just copy the
entire file to a raw file. I think you can just copy the whole file but that's not what
we've done in the respeed cases. So I was hoping to try it some day. Maybe you can try
it on your damaged file.

[mjs]

I don't know if the file can be fixed with the moov atom not found. It didn't have any metadata that I could see and I ended up deleting it.

I forgot to mention, with the side downloading it now shows downloading speed in kb/s while the file is downloading.

[Wild Willy]

I don't know that it would work, either. I would like to try it but I am working with
Paul to get me up to a new CoApp. I'm sure you've seen the other thread. You apparently
have a case at hand. Do your download again & stop it after let's say a minute. If it
is missing its moov atom, great. See if ffmpeg will create a raw file from it. It is my
understanding that generating a raw file is equivalent to ffmpeg ignoring any metadata,
no matter whether it's missing or damaged. And if that works, see if it will create an
mp4 from the raw file. It's the same steps as what we did in the respeed cases. Well,
maybe minus the -r parameter. Or if you can get a frame rate from VDH's Hit Details on
the thing, so much the better.

[mjs]

I tried to do the video extraction on another file, it comes up with the same error message of the moov atom not found.

There is simply no video information in the file.

[John Kennedy]

This new beta and what? Official?

Em qua., 4 de out. de 2023 às 07:27, mjs <matt...@gmail.com> escreveu:

I tried to do the video extraction on another file, it comes up with the same error message of the moov atom not found.

There is simply no video information in the file.

--
You received this message because you are subscribed to the Google Groups "Video DownloadHelper Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email to video-downloadhelper...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/video-downloadhelper-q-and-a/bd8bca10-222e-4f3d-bf99-bf2fac1e7e13n%40googlegroups.com.

[mig]

It's there: https://downloadhelper.net/firefox/betas

[mig]

On Wednesday, October 4, 2023 at 8:25:36 AM UTC+2 mjs wrote:

One issue, embedded YouTube video doesn't seem to be detected https://www.reddit.com/r/videos/

That was a case we never encountered before, that's what betas are for. The fix will be in the next release. Thanks for noticing and reporting.

[mjs]

With the side downloading in the new coapp  it looks like the timed_id3 data is omitted. I don't think it was a big issue but anyway it's one

less thing to worry about.

[mjs]

Embedded YouTube works with 8.1.0.0a5 + companion app 2.0.4 , play has to be started first for it to be detected.

On side downloading it shows kbits/s , I assumed this was download speed. It might instead be the bitrate for the video.

[mig]

On side downloading it shows kbits/s , I assumed this was download speed. It might instead be the bitrate for the video.

I think you are right. I remove this bitrate mention.

[mjs]

It looks like the problem of separate video and audio is solved as I tried on arte.tv and it had sound. However these are marked as ADP

along with writing a watermark. A lot of users will be pleased to find no more missing sound.

[mjs]

Example image :

[Wild Willy]

Right. They didn't really pay any attention to the alleged "separate" video & audio
issue. They just started using ffmpeg, which never had the problem. Ditto for timed_ID3
data. Using ffmpeg just automatically ignores timed_ID3 data & always has. The trick is
that different web sites like to use different ways of presenting the manifests.
Sometimes, as we've seen many times, there's either a .m3u8 or a .mpd coming in & there's
no issue finding it. That's why Arte now works. They always presented an HLS master
manifest in a straightforward way. Problem was the sharing of the audio tracks. Ffmpeg
has never had a problem with that so that's why it now works. But sometimes the
information is buried in a json & that's not always easy to find. That's when our
improvising in the "too fast" thread has come into play. I don't know to what extent
Michel & Paul can program for those off-the-wall situations, like Vimeo. But they've got
plenty of YouTube-specific code in the product so maybe it's not too much to expect
they'll do the same for Vimeo. Then there's Udemy & Hotmart, for which we've never
managed to convince a paying member of either of those sites to play with us. Maybe the
new VDH will work there without any further fuss. We would need to hear from a paying
member of each of those sites to know for certain. The fact that they're sites behind
paywalls does make it impossible for the guys to investigate those sites. Then there's
the handful of Japanese adult sites that periodically get reported here. I looked at one
just yesterday & I have to say I couldn't figure out how to make it work. I did find a
master manifest but it appeared to be for one of the secondary items on the page. Plus
it looked like a livestream. I downloaded 5 minutes of something with ffmpeg using a
manifest I found but it turned out to be something other than the primary video on the
page. I couldn't find anything relevant that would let me download the primary item on
the page. I think if VDH supports popular sites like YouTube & Vimeo, as well as any
site that just offers its master manifest straight up, that should be good enough.
Michel has never claimed VDH would support every site & I would back him if he said about
any given site that he would not be spending any time on it.

[mjs]

With 8.1.0.0a5 + companion app 2.0.5 , it detects media on this Udemy video :

https://www.udemy.com/course/getting-started-in-photoshop/

But when using side downloading it fails with an error:

GrabInfo: Cannot get info from on</grabInfo/<@moz-extension://92f0d542-7517-4769-9d1d-4ce5c548a85b/background/main.js:29:88140

If it can work for a preview video then it may also work on other videos from Udemy.

[Wild Willy]

That one is kind of baffling. I did not get the same results as you. But I think there
are 2 major differences in our setups. First off, I'm still running Windows 7. That
means I have a different CoApp 2.0.5 from yours. Then I am not running with HLS as M2TS
enabled. When I visited the URL you gave, VDH recognized nothing. I had to hit play on
the 1:44 course preview to get anything in the VDH menu. I stopped playback after a
couple of seconds. All I got was a bunch of short MP2T variants. None of them offered
the "side" option. I didn't even try to download any of them. Dropping back to the
Network Monitor then reloading the page gave me nothing I could use. Letting the preview
play for a couple of seconds gave some additional entries in the Network Monitor.
Curiously, there were no MP4s in there, only mp2t fragments. But there was an HLS master
manifest, as you can see in attached image #01. I ran ffprobe on it, which report is
attached. There are no shared audio Streams & no Timed_ID3 data, things that have caused
problems for VDH in the past. I used the ffprobe information to download the item with
ffmpeg, which log is also attached. The thing played just fine in VLC.

I should point out that my invocation of ffmpeg includes -fflags +discardcorrupt. This
is something I routinely use on all my ffmpeg downloads. It turns out it's a good thing
I use that because a rather surprisingly large number of corrupt packets for such a short
video got sent to me. Despite that, the resulting video played fine. I didn't inspect
it in detail, just skimmed through it. Maybe there are visible artifacts of the missing
packets in there. I'm not sufficiently motivated to look at it that closely. But this
does prompt me to suggest that however the CoApp invokes ffmpeg, it should drop corrupt
packets. Users are not interested in having downloads terminate early due to corrupt
packets. It's no big deal to just drop corrupt packets & the result is usually playable.
So the CoApp should always drop corrupt packets. This should NOT be a user option. This
should just be the way it works.

I don't know why VDH would not have recognized the manifest you can see in my image. Its
file name actually contains .m3u8. The file type is one of the standard types, which I
specifically made sure is visible in the attached image. This one is a puzzler for me.
I have to assume it will be a piece of cake for Paul to figure out.

[mjs]

On the main Firefox extension I have M2TS enabled but on the beta it is off. What I saw was all the resolutions in the menu in the beta extension.

But fails immediately after clicking download.

[Wild Willy]

It strikes me as a bit weird that the VDH menu (for you, anyway) would be populated with
the usual array of variants but then get the failure to get info error once you launch
the download. Isn't it necessary to get info on the video in order to populate the VDH
menu? How can you get info one moment & a few moments later fail to get info?

Unless . . . the error isn't actually a failure to get info. Maybe the first corrupt
packet caused the download to fail but the error message isn't reflecting the true error.
I am, of course, just guessing. But if I've guessed right, that just reinforces what I
said above about corrupt packets. The CoApp should ignore corrupt packets, no
exceptions, no user option for that. Period. It's also weird that VDH would fail to get
info that is readily available in the Network Monitor where I was able to get the
necessary info manually. VDH is not getting the info for me & it's not generating any
errors. This has to be a Windows 7 issue.