Videos Download with NO sound?

[yogini]

Hi Mig, premium user here.

Trying to download opera stream, but the file downloaded has no sound. Trying to get the HLS 1280x720 HLS 4.1Mbps file.

https://www.metopera.org/ (please click on watch now nightly opera stream if link below expires).

File: https://players.brightcove.net/102076671001/ShNTDWXQ_default/index.html?videoId=6142430747001

Thank you.

 

[Wild Willy]

This is a bit tricky but I have found by trial & error that for some strange reason, the video & audio streams for these operas are listed as separate entries on the VDH menu.  I have indicated in the attached image which is which.  I got what you can see in the image WITHOUT even launching playback.  Unlike YouTube, these opera streams are visible to VDH without the usual necessity of at least starting the playback.  I don't know why all web sites can't be like this but, well, they're not.  It is a bit annoying that VDH can't report the detail of which is video only & which is audio only, & that we have to resort to trial & error to figure this stuff out.  But VDH is at the mercy of the Met's web site.  VDH reports what it is told, and it turns out that what the Met web site is telling VDH is deficient.  Complaints on this should be directed to the Met's webmaster, I suppose.  VDH certainly can't report what it isn't told.  In any case, go ahead & download both the variants I have indicated.  Then play them back in VLC.  How?  Enter VLC & press F1.  Then go visit their Wiki site.  They have instructions there on how to play multiple files synchronously.  First you cue up the video MP4 you downloaded.  Then you tell it to synchronously play the audio MP4 you downloaded.  The details are on their Wiki so any more detail here would be off topic for VDH.

I must add that I am most grateful the Met is doing this.  These opera performances are usually behind their paywall so I consider this a most generous gesture on their part.

[Wild Willy]

With a little more experimenting I've come to the conclusion you can't get the captions.  I tried launching the stream & then I clicked the little button to enable captions.  Then I launched a download in VDH which I let run until I had the first 500M of the download, about the first 23 minutes of the show.  While I was playing the stream, I looked at the network monitor in Firefox & the captions appear to be chunked.  Both the audio & video streams are HLS, which is to say they are chunked.  In the network monitor you get by clicking F12 & then selecting Network, you can see a little .vtt file coming in every so often.  So it looks like the captions are chunked as well, which is not surprising.  Although the stream was displaying the captions, the 500M test file I downloaded did not have the captions.  So it would be nice if somehow VDH would recognize that captions are being transmitted in a side file & included that in the download results.  Follow the VLC standard of naming the .vtt.  Take the file name part of the .vtt file as whatever you specify in the VDH file selection dialog, but take off the mp4 part (or whatever) & replace it with .vtt (or whatever).  You can't leave it to the user to tell you what type of side file it is.  I discovered that it was a .vtt by using the network monitor in the browser.  VDH should be able to detect that one of the various side file types is being transmitted & simply create the side file without getting any user input.  VDH should assume that if one of the dozens of various side file types is streaming in, the user must have enabled captions & just download them.  Typically, a caption side file is only a few K so we're not talking about a huge usage of bandwidth.  The service VDH would provide is to aggregate all the chunks of the side file into a single file, just like it already does with the various chunked video formats.  Jerome, please pass this suggestion along to Michel as a feature request.  Thanks.

[yogini]

Thanks so much for your detailed response WW. Through trial and error I too was able to download, separately, soundless video and audio only but couldn't figure out how to get them to play synchronously. Thanks so much again.

I agree. This is wonderful of the Met, who sadly just laid off its entire union staff yesterday and confirmed it will discontinue at least this season through May 2020. I suspect everyone will be holed up much longer.

One other note. The first two days, I had no problem downloading videos. Because demand was so huge, it appears the Met switched to a different streaming platform on the third, BRIGHTCOVE, which is where these problems began.

[MgFrobozz]

This seems to have happened when the Met shifted from akamai to brightcove.net.

Last night, when La Traviata was available, I ran some experiments in hand-extracting the streams. Brightcove is streaming by providing a top-level m3u8 file that appears to include a url for an m3u8 file for each of the bitrates available for adaptive bit-rate streaming. The top-level m3u8 also includes a url for the audio m3u8 and webtt (caption/text) m3u8.

I've attached the following (I've deleted all but the first 2 and last 2 segments in each, to keep the size down, but all the urls are the same except for the segment number):

• trav_top.m3u8: contains urls for all video, audio, and text m3u8 files, and associations between the video m3u8s and the audio/text m3u8s.
• trav_vid.m3u8: for the 1280x720 video stream, containing urls for segments 0..1026
• trav_aud.m3u8: for the audio stream, containing urls for segments 0..1035
• trav_text.m3u8: for the webvtt stream, containing urls for segments 0..342

I concatenated all the video into vid.ts, all the audio into aud.ts, and all the text into text.vtt, then ran ...

> ffmpeg \
  -i vid.ts \
  -i aud.ts \
  -i text.vtt \
  -c:v copy -c:a copy \
  -y \
  traviata.mp4
> MP4Box -add text.vtt traviata.mp4

(the above has been edited to produce mp4 instead of transport stream).

Traviata.mp4 size 4.4GB. Under either mplayer or ffplay, it plays the video and audio fine (a/v sync seems good), but I still can't get any subtitles/captions. All of the wevtt files look good, and have good captions. mediainfo reports that it contains a text tract (wvtt). When I run ffplay, it reports that the captions are there, but doesn't show anything. I also found a few bug reports on ffplay that indicated the same problem for other streams, so the file may be ok. If I play it from an html5 player, and add text.vtt as an extra track, then subtitles/captions are available.

I can't figure out how to post a video downloadhelper bug report for this; could someone let me know the site, or repost it there?

[MgFrobozz]

Hi, Yogini ...

Yes, the moved from akamai as their CDN on the first night (Carmen) to brightcove later in the week. It was a lot easier to download from akamai.

[XaRaF]

Had same problem and same trial & error process to establish which is which.

I'm pretty sure first two operas were as well using brightcove platform but with first one had no problems using tubeoffline website; second was bit troublesome as due to demand changes were made and had chapters but tubeoffline managed to grab it audio and video in one file. Sadly not so easy with last two ones so was glad to discover and succeed using VDH. Grabbing vtt would be a brilliant feature.

As for merging audio & video just made a success with VLC functions using info from here https://hhooww.com/add-audio-file-to-video-using-vlc-media-player/ had no problems using Convert function and selecting both keep original audio and video track in profile settings for conversion. Selecting 'Dump raw input' didn't work despite two separate files selected on prior screen.

[MgFrobozz]

I found the (subrip text) captions for Carmen: https://www.metopera.org/ondemand/imagelinks/subtitles/811357013533.srt (renamed to carmen.srt below).

The audio and video are no longer available, because the 20-hour limit has expired; I think they left them there in order to support the free preview of the Habanera ("L'amour est un oiseaux rebelle").

If you have an mp4, you can inject using "MP4Box -add 811357013533.srt carmen.mp4", or if you're using an html5 player, just add a track:

<video controls="" name="media">
    <source src="carmen.mp4" type="video/mp4">
    <track label="English" kind="subtitles"  srclang="en" 
        src="carmen.vtt"></track>
</video>

 

I later found that chrome's html5 player wouldn't play srt files, but would play webvtt files, so I ran this conversion to get a working system:

ffmpeg -i carmen.srt -c:s webvtt carmen.vtt

[Wild Willy]

MgFrobozz . . . You say you concatenated all the .vtt chunks into a single .vtt file.  How exactly did you do that?  I did manage to find the .m3u8 manifest file for the .vtt chunks for tonight's La Fille du Régiment but other than manually copy/pasting each URL into Firefox & then successively appending each file as I get it, I don't know how to do that concatenation.  And that seems like a ridiculously tedious manual process prone to all kinds of human errors (mine).  Plus when I do a copy/paste of one of those URLs, I don't get a chunk of .vtt file contents.  I get what looks like a header for a file, a single line of text, & it's not even a WEBVTT header.  I do realize that there is this long string of gibberish on the end of each URL that is meant as some sort of session ID that ties the stream to my session.  I also realize that string of gibberish has a shelf life of some unknown length.  Plus the stream will not be available after 6:30 PM New York time tonight.  (For some reason Fille is available for a few hours longer than the earlier ones this week.  Maybe that's to cover for the loss of a live radio broadcast today, although the originally scheduled live Cenerentola is being replaced by one from 2014/5/10, which happened to be a Live in HD show although that appears to be irrelevant.)

In any case, if I could get the whole .vtt file from the web site, I would just put it in the directory with the video I already have.  I've currently got a file named (I'm shortening it) Fille.mp4.  If I put a file named Fille.vtt into the same directory, VLC will recognize the match on the file name part & automatically display the captions from that file.  I know that's how it works for regular playback.  I'm assuming it will work the same when I'm playing the audio & video synchronously from 2 separate files, as I'm doing now.  I'm hoping VLC will still recognize the caption file & show the captions without my having to explicitly identify the file in VLC's multi-file dialog.  Mind you, there is a place for identifying a caption file in that dialog, but I'm hoping the name match will be enough.

[MgFrobozz]

Hi, Wild WIlly ...

In the text m3u8, all of the urls are the same except for the number after "segment" (eg, "segment0.vtt"). I looked at the first and last to get the number of segments, then ran the following script in a bash shell, replacing the segment number in the url with $i (the index number of the segment). The file traviata/text.vtt is the concatenated file. After I did this, in a slicketdit editor, I removed all of the lines "WEBVTT" and "X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0" except the two at the top of the file (some apps don't like having more than one declaration).

I doubt whether any of this will work now, because the 20-hour window to access traviata is expired: https://players.brightcove.net/102076671001/ShNTDWXQ_default/index.html?videoId=6142647008001 indicates "The Video Cloud video is not playable."

 

#!/bin/bash
base=traviata 
mkdir -p $base/text 
rm -f $base/text.vtt
# Copy vtt segments 0..342 to a file
for i in {0..342}
do
    # Fetch a copy of the segment:
    wget https://house-fastly-signed-us-east-1-prod.brightcovecdn.com/media/v1/hls/v4/clear/102076671001/75cb2d2d-58ac-4867-b0d2-d7f435fe4e0e/b77ee90d-f46f-4441-babd-8e006b5b2ee6/segment$i.vtt?fastly_token=NWU3NDljZDRfZWE4OWJmY2E0MWMxODA3MTljNTY5MWNiZTRiN2U1MTM1ODJhZDZmODA4MTczYjhlYzRkZTY4ZTg4YzM0OWU2Yl8vL2hvdXNlLWZhc3RseS1zaWduZWQtdXMtZWFzdC0xLXByb2QuYnJpZ2h0Y292ZWNkbi5jb20vbWVkaWEvdjEvaGxzL3Y0L2NsZWFyLzEwMjA3NjY3MTAwMS83NWNiMmQyZC01OGFjLTQ4NjctYjBkMi1kN2Y0MzVmZTRlMGUvYjc3ZWU5MGQtZjQ2Zi00NDQxLWJhYmQtOGUwMDZiNWIyZWU2Lw%3D%3D -O $base/text/$i.vtt
    # Concatenate it to the file text.vtt:
    cat $base/text/$i.vtt >> $base/text.vtt
done

[Wild Willy]

Never mind.  I figured it out.  Here's how.  I don't know if any of these steps are unnecessary but it's what I did.

First, go to the Met home page & hit F12 in Firefox.  It is important to have the monitor open BEFORE you visit the actual stream page.  Things you want to observe appear when you first open the page, & visiting the stream page first & then hitting F12 will miss some things.  After you've got the monitor open, then click the link that takes you to the page where the stream is located.

Actually, come to think of it, given what I'm about to say, it may not be so important to already have the monitor open.  But it's what I did.  In any case, when you first visit the stream page, before you even launch the stream, the monitor will show you that you have received 3 manifest files.  (See my attached image Fille#1.)  You can inspect anything in the monitor by just double clicking on it.  Firefox prompted me for what to do with the resulting file so I told it to open it in my Windows 7 text editor.  (I'm actually using a Notepad replacement but Notepad is fine.  Pick your favorite text editor.)  The first time I did this, Firefox was completely at a loss how to deal with this file so I went through the Windows dialog for supplying some application other than Firefox to handle the file.  This became a sticky setting & I don't have to go through the dialog every time, just tell it yes use the text editor again like last time.

Each of these manifest files contains a number of URLs.  Each of those URLs points to another manifest file.  I clicked through all the URLs in all 3 of these manifests & did NOT find one for the captions.  So I went ahead & launched playback.  Then I enabled the captions within the stream as it was playing.

Next, I looked in the monitor again.  Of course, bunches of new entries had been added because now I was receiving chunks of the stream.  I scrolled down through the monitor until I found another entry for a manifest file.  It's also identified as x-mpegurl in the Type column.  Hovering the mouse over that gives you the tooltip application/x-mpegurl as shown in my image Fille#1.  Double clicking through that let me inspect this later manifest.  I'm showing the first few lines of this later manifest in my image Fille#2.  This is the manifest we want.  The caption type being used in this case happens to be VTT.

Once you've discovered the manifest for the captions, you need to get the URL of the manifest.  Go back to the monitor & pop up the context menu on that entry by single clicking mouse button 2.  (See attached image Fille#3.)  Then select the Copy URL option.  This puts the URL of the manifest into your clipboard.  Next, paste that URL into a plain text file using your text editor.  You don't want to lose this URL so put it somewhere safe.

After asking my question last night, which I see now is a bit silly, I thought I might go look up the documentation on Ffmpeg.  (I wrote all of this before I saw that MgFrobozz had so graciously provided the above information.)  I read a bunch of bewildering stuff but I came away with just barely enough to do what I needed in this case.  We all have Ffmpeg because it's packaged with VDH.  To be more accurate, I believe it's actually packaged with the CoApp.  But since we are all using the CoApp (we are all using the CoApp, right?), we all have Ffmpeg.  The only tricky bit is finding it.  On my system, it's buried under Program Files on my boot partition.  Use a dir /s in a command window to find it.  The executable name is, unsurprisingly, ffmpeg.exe.  Once you've found it, copy/paste that file spec into the same file in front of the URL for the manifest that you saved above.  You're constructing a .bat file here, in case you were wondering where I'm going with this.

So the first (and only) line of our .bat file invokes Ffmpeg.  Since the executable is within a directory tree that includes Program Files, there's a big fat space in the middle of the path to the file.  So you're going to have to surround that part of the line with quotes.  The first argument in the invocation of Ffmpeg is -i.  The -i argument tells Ffmpeg where to get its input.  Its input is the manifest for the captions we pasted in before.

The last part of the puzzle is specifying the file on your system where you want Ffmpeg to place the captions.  The entire command looks like this:

ffmpeg -i URL targetfilename

On my system, it looks like this:

"C:\Program Files\net.downloadhelper.coapp\converter\build\win\64\ffmpeg.exe"
-i https://manifest.prod.boltdns.net/manifest/blahblahblah/rendition.m3u8?blahblahblah
"Q:\Opera\La Fille du Régiment Video 20080426.vtt"

The quotation marks are critical.  This won't work without them because of the spaces in the various file names.  Also, this is actually a single line.  I'm showing it folded here so you can see all the parts.  The parts are separated by a single space, not a line break.  I've shortened the URL to the manifest because it's long.  Plus the name you will see will be different, especially in the part after the question mark.

Now save this arcane load if gibberish into a single-line .bat file named whatever you please.  Then execute it.  A bunch of messages will flash by in the command window.  You can execute the .bat file by just double clicking it.  If you want to see the messages & read them at your leisure, first open a command window & execute your .bat file from there.  The .vtt caption file that Ffmpeg created for this opera was barely 52K.  Tiny.  It took only a few seconds for Ffmpeg to download it.

In an excess of snobbery, I have named my target file with an accented character.  This matches the name of the .mp4 file of the video stream I saved earlier.  The matching of the .vtt with the .mp4 satisfies a feature of VLC, as I mentioned above.  Ffmpeg did have a bit of trouble with the accented character.  The file name I got included what looked like a Greek capital theta in that position.  After the fact, I just renamed the file to put the accented e back in the file name & all was well after that.

As I suspected, I did not need to explicitly tell VLC about the caption file.  I just needed to tell VLC where the synchronous video & audio files are.  The simple existence of the .vtt file in the same directory with the .mp4 file got the captions to display.  Of course, it isn't until after Renée's introduction & after the overture that you actually see any captions.  But they do display.

One possible bonus of having the captions in a separate file like this is you can correct them if the urge takes you.  I doubt it will take me but it's possible there's a word here or there that might be misspelled.  For any sticklers, if you happen to understand the language of the opera, you might want to translate some line with different words.  That's easy to do.  Just edit the .vtt file like any other plain text file.  If you're going to do any extensive work on the captions, I would recommend getting a caption editing application.  You can search for them on Google.  One I have used in another context is called SubTitle Edit.  It's free & it is being actively developed.

Now, I gather Ffmpeg can also combine the video, audio, & captions into a single file.  I don't really care to do that.  I can play this back whenever I choose & I will see the action, hear the singing, & read the captions just fine with the 3 separate files.

This process should generalize to any future opera streams the Met will put up.  Since URLs will change, the instructions will change as well.  Just edit the .bat file to indicate the new URL & the new target file.

I hope this helps somebody.  And thanks to MgFrobozz for your participation.  Evidently you're running Linux.  I'm on Windows.  It's good to have all this variety.

[XaRaF]

Great tutorial Wild Willy!! Thank you so much! Worked like a charm! Let's hope they don't change anything for future operas.

Could you upload subtitles you acquired for La Fille du Régiment? With the method working and Carmen subtitles provided by MgFrobozz that would leave us missing out only on three operas from last week.

[MgFrobozz]

You can get subrip Carmen subtitles from:

https://www.metopera.org/ondemand/imagelinks/subtitles/811357013533.srt

[Wild Willy]

It's a small file so I'll put it here.  I may be violating some rule or law so I don't know if it will be allowed to stay up.  I guess that means grab it quick while it's here & don't be surprised if it gets removed.  MgFrobozz gave a link to a page on the Met's own web site so that must be legal.  All the captions are probably there somewhere but it looks like they've well & truly randomized their URL naming convention so good luck finding them.  Odd thing about MgFrobozz's link.  When you click it, you get an error.  You have to copy/paste the URL.  For some reason, the entire character string is not coded as a link.  Must be some quirk of Google Groups.

[XaRaF]

Got it, smashing!! Thank you once again Wild Willy and MgFrobozz!!

[MgFrobozz]

Since I'm in social isolation against COVID-19, I decided to use the time learn a new (to me) programming language (python) to script the download.

Given the url to the brightcove page (details below), the script prints progress information, then gives you a final .mp4 and .vtt file

I've attached the script (dnload_met_opera.py, which uses python3), and a doc file (dnload_met_opera.txt), which details what goes on with the download. The usage for the script is:

dnload_met_opera.ph url

where "url" is the page url from clicking "WATCH NOW" (currently, "https://players.brightcove.net/102076671001/ShNTDWXQ_default/index.html?videoId=6143710303001").

For automation, the key item was discovering that there was a json file that contains all of the information about the opera, including manifest file and subtitle urls.

[Bruce R]

I've been trying to follow Wild Willy's ffmpeg method on my Mac to download the subtitles.

I've found the manifest file for the opera I'm working on (Norma) and saved as a txt file.

I've got the URL for that manifest file.

I found ffmpeg ( /Applications/net.downloadhelper.coapp.app/Contents/MacOS/converter/build/mac/64/ffmpeg) and learned that it runs in Terminal.

And now I have no idea what to do next.

Any Mac user out there who could walk me through the process?

Thanks.

Bruce

[Bruce R]

How did you discover that 811357013533.srt is the subtitle file for Carmen?

If we had a list of these srt files, it would be great as vdh does a fine job with video and audio.

BTW, EmmGunn Tools - mp4 Tools (free) quickly merges the video and audio files, so you don't need to have VLC play two files at once.

[Wild Willy]

OK.  So this has happened 3 nights in a row now, which means it's not an accident.  The Met has changed their Brightcove player page for viewing the nightly opera video.  At first, the home page went straight to the player page.  Then they changed it so it went to a page that had 2 buttons: one for donating, one for going to the actual player page.  Now they've got the donation button on the player page so you don't have to go to a subsequent page.  What will we see next?

Anyway, that's not the problem.  Starting with Saturday night's Macbeth & continuing with last night's Norma & tonight's Aida, the video stream never ends.  Well, I don't know if it never ends because I have not let it run forever.  But from what I see, the Met isn't telling VDH OK, this is the end.

I've got a pretty slow connection so I like to check on my downloads every so often.  What I'm seeing is VDH says the download has reached 100%.  Up until Saturday, VDH (I guess the CoApp, really) would then terminate the download & float up the notification that your file such-and-such is now ready.  Starting Saturday, when it reaches 100%, the download keeps going.  Then all of a sudden oops, your download is now at 0% complete & the duration of the resulting file will now be exactly twice what we originally told you.  I have no reason to doubt that after downloading I don't know what, maybe the whole video stream again, it would do the same thing & continue on to download the thing a third time.  And so on forever.

But I've never let it get that far.  When VDH tells me it's got 100% of the file, I just let it go on for a bit, maybe a minute, and then I click the Stop Download button in the VDH progress menu.  This then almost immediately puts up the completion notification.  The MP4 I have at this point is the video stream, complete & correct, every last second of it.

I believe this is not a problem with VDH.  I believe the Met is sending out manifest files that deceive VDH into believing there's more to come.  This is not happening with the audio streams.  VDH downloads those & they cleanly reach completion.  But the video streams are causing a problem.  At least, they are for me.  I sure do wish Michel would take a peek at one of these free opera streams.  As far as I know, these things are not being hidden behind a wall that will tell you, "Sorry, this video is not available in your geographical region."  Everything I've read on this says the Met is doing this as a gift to the world so everybody should be able to access these things.  And they're free.  So maybe there's something weird the Met is doing.  If you can let YouTube yank your chain every time they frivolously change their format, I request that you allow the Metropolitan Opera to do the same.  Please look at the current opera stream, whatever is up when you go to look at it, & tell me what you conclude.

While I'm here, I'd like to describe some other odd things I've observed.  My maximum bandwidth is about 550,000 bytes per second.  I get this number from the Windows Resource Monitor, Network tab.  That's not bits per second or any number of K or M per second.  Straight bytes per second.  With these opera streams, my bandwidth usage seems to fluctuate around 500,000.  It never takes up my full bandwidth.  I don't know if the Met is throttling these streams, if VDH is doing something that stops it from using up all my available bandwidth, if my system has some sort of quirk.  I regularly see downloads using up my full bandwidth for other things.  These streams just refuse to do it.  What do you see?

When I use Firefox to download things without using VDH, Firefox allocates bandwidth to the various downloads using some strange formula.  Sometimes I'll see 2 concurrent downloads getting approximately 90K & 460K, about a 20/80 split.  Sometimes it will do 40/60.  If I've got 4 downloads going, typically one of them (no predicting which one) will get about 50% of the bandwidth & the other 3 will split the remainder equally.  As each download eventually completes, one of the remaining downloads then gets the lion's share of the freed up bandwidth, while the others plod along at their same snail's pace.  But when I'm doing such downloads, if I visit any web page, Firefox allocates some bandwidth to that page request & slows down the downloads until the page has loaded, which happens somewhat slower than normal, but still in a reasonable time.  When the page load completes, the downloads resume their bandwidth usage as before.  When I'm downloading one of these opera streams, the CoApp hangs onto its bandwidth allocation.  Nothing else causes it to give up a little to play nice.  Page loading reverts to the days of the 14.4K dial-up modem.  I basically don't do any other web surfing while one of these things is downloading.  Even checking E-mail (via something entirely outside Firefox) takes a ridiculously long time.  Surely there's something there worth looking into.  VDH/CoApp really ought to play nice with whatever else may come along to request bandwidth.

I have also noticed that if I try to download one of these operas with the video & audio streams in flight at the same time, the audio stream will get pretty much all of the bandwidth the CoApp is using.  The video stream will appear to be stalled.  Once the audio completes, the video picks up speed & I begin to see the target .part file being updated regularly.

Since these video streams are pretty large files, in the range of 3G to 4.5G so far, I'm prepared to see them take 2, 3, 4 hours to download.  But there are long periods during which the VDH menu shows no progress & the .part file does not get updated.  It tries my patience.  But patience is rewarded.  Every so often, activity does occur.  Sometimes it's only a minute or two of apparent idleness, sometimes it's as long as 20 minutes without any apparent activity, other than what I see in the Resource Monitor.  But when the 20 minutes elapse, it really makes up for lost time.  The VDH menu might go from telling me it has (I'm making up some numbers just to illustrate what happens) 14% of the download completed & the rest will take 6 hours & 27 minutes to complete, to 37% percent done & 2 hours 5 minutes to completion.  It will jump from 14% to 37% in a matter of about a minute.  I'm alerted to this happening by the case fans in my system suddenly speeding up, which is clearly audible.  My guess is that the various CoApp threads hang onto what they've got for a certain time, & then the CoApp commits the lot to the .part file all in a rush.  It's very bursty.  I'm curious why this works like this.  Is it because some complete chunks are received out of sequence, so they have to wait until the earlier chunks come in?  Or is it something else?

With these opera streams, the caption files are just a few K.  The largest one is the 74K for Don Carlo.  Tonight's Aida is the smallest one I have at 48K.  The audio files are all of a modest size.  They range from 158M for Barbiere to 243M for Aida.  The videos range from 2.81G for Pêcheurs to 4.45G for Don Carlo.

Until tonight.  After a little over an hour, the video stream reached 100%, then jumped to telling me it was twice the size it really was.  I did what I describe above & let it run for a bit before stopping it.  I thought, this can't be right.  This file took 1 hour 15 minutes to reach 100% & it's only 1.83G.  There is something seriously wrong here.  I'm going to have to run this download again.  But I loaded up the video & audio files for synchronous playback in VLC, fully expecting the thing to stop somewhere around 45 minutes when the whole thing is 2:52:02 according to the duration on the audio MP4.  Nope.  It's all there.  Every last second of it, from Isabel Leonard's introduction (she is such a babe) to the intermission interviews that have been relocated to the end of the broadcast.  With the captions on the performance itself.  I haven't watched the whole thing, just sampled it from start to end.  The file properties in Windows say it's 1280x720 resolution at 30 frames per second (actually 29.something fps).  The VLC properties say it's 1280x720 @ 30fps.  This is the same as all the previous operas.  It looks like they've cast some technospell over tonight's offering.  I will certainly appreciate if this is just the first of many that fall under this spell.

[Bruce R]

Would anyone have the subtitles to the Met

La Boheme

and

Die Meistersinger von Nürnberg ?

Thanks

[mig]

Regarding bandwidth usage weirdness, neither VDH nor i believe Firefox, does anything to control bandwidth allocation (it's called Quality of Service aka QoS). This is the way the TCP protocol (the network layer above IP) works. It may looks odd as equity between streams is not really respected, but quite often the usage of the bandwidth is determined by the server.

[Wild Willy]

So allocation of bandwidth is a weird thing.  I guess I don't have much choice but to live with it.

Continuing another idea here, tonight's Falstaff downloaded & terminated normally.  Whatever was going on this past weekend seems to have been cured.

Something I've noticed during these downloads is kind of scary.  As I described above, every so often a bunch of chunks get appended to the .part file in a flurry after several minutes of apparent inactivity.  (Would still like that explained.)  When this flurry of activity hits, all data transmission stops, sometimes for as long as a minute.  I just hold my breath, praying the download will resume, especially since we do not have a way of resuming an interrupted download from the point of failure (and are not likely to get one).  But after this heart-stopping delay, the download does successfully resume.  Why does this happen?  It isn't every time my case fans speed up, just on certain occasions.

[Wild Willy]

Oh.  Another thing.  Tonight's Falstaff resulted in a video file of size 2.80G with a duration of 2:21:47 & it took just shy of 2 hours to download.  Aida a couple of nights ago was 1.83G lasting 2:52:02 & it took 1.25 hours to download.  So despite being a half hour longer, the Aida file is much smaller.  I believe the difference is in the bit rates, which you can see in the Windows File Properties dialog on the Details tab.  I believe this is reflected in the Mbps rating that dispays in the VDH menu.  I'm not exactly sure why there has been this fluctuation.  For the first week of these free operas, the videos were marked as (I think) 4.1Mbps.  Then last week they were 3.somethingMbps.  Tonight's Flastaff is 3.3Mbps.  I wish I had paid more attention to what it said for Aida.  I would expect all of this to be reflected in the quality of the video image you would see in each opera, but the Aida looks just as good as all the others, even though none of them is a full 1920x1080, only 1280x720.  Still, VLC plays them full screen so it's just an interesting oddity.

[XaRaF]

As long as Met is maintaining 720p quality I'm not complaining but it was bit odd at the beginning. I'm having no problems downloading in latest Chrome despite website changes, vtt manifest is still there visible in network inspection. Only once or twice had a problem downloading audio track, usually it's the first entry in the plugin menu past the video streams, but on those occasions that one wasn't working luckily the second works without problems - no clear differences in quality but I'm tone def and didn't mark files to see if they are mono/stereo or what bitrate. 

Bruce R - Here's my collection of subtitles, sadly La Boheme, Il Trovatore and La Traviata are not from Met stream so definitely out of sync and highly likely not matched as it was before vtt method was established and it's something Plex plugin matched with the files, had no chance to sit with them
and see if any good or correct timings. As for merging mp4 worked out vlc and it does great job so far.

https://www.dropbox.com/sh/suill23esqril0b/AABl0yJ5xoCdRiXJmTZ1ryW9a?dl=0

[yogini]

Really appreciate your posting the subtitles. Thank you. Try as I might, I couldn't make technical sense of how to get them on my own!

On a somewhat related note, the Met now is offering "student streams" together with Zoom talks with the singers, study guides, coloring books and more for children, students, or opera lovers who wish to learn more. It's wonderful.

https://www.metopera.org/discover/education/free-student-streams/home/

In good health and happy opera-ing to everyone.

[Geevee]

Bless you.

[Erch]

Great stuff WW!

Thanks a lot everybody for your contribution.

I hadn't read this thread before so missed some of the stuff from the MOH free Nightly Opera Streams.

Specifically I am looking for:

• The audio for La Traviata
• The audio for Lucia di Lammermoor
• The audio for Il Barbiere di Siviglia
  
• The Spanish subtitles for the MOH operas streamed

Could anybody help in getting them?

Thanks in advance!

[Wild Willy]

You're welcome.  We opera lovers need to stick together.

For the audio streams, as I described above, my Internet connection isn't the fastest.  And I was talking there about my download speed.  My upload speed is a fraction of that, maybe 10% or 15%.  So I'm going to have to defer to others with better connections on that score.  As for captions, it is my understanding that only English captions are available with these streams.  When you hover your mouse over the litte CC box in the bottom right corner of the Brightcove player, the only option that appears is EN.  So you're going to have to translate the English captions yourself.  Or you might find a complete recording on CD.  Many complete recordings include massive booklets that often include the full libretto in the original language alongside translations.  The ones I've seen usually show Italian, English, German, & French versions, one of which is usually the language of the opera.  There may be Spanish-language versions of these booklets available in Spanish speaking countries.  I have no personal experience with that.  You could then get one of those free caption editing programs I've mentioned & create your own Spanish captions.  I believe there is a certain level of automated translation that comes as a feature of some of these software products, but I'd still go through the captions one by one & make sure the automated translation created intelligible Spanish.

On the subject of what happens when a video stream completes, it seems that I may have been a bit impatient.  I am still seeing that when the stream reaches the expected end, the VDH menu registers 100% complete.  A few moments later, the duration of the stream changes in the VDH menu, showing exactly double the actual duration.  The CoApp continues downloading something for about another 30 seconds.  I don't know what it's downloading & I don't know where it's putting it because the MP4.part file does not grow at this point.  After those 30 seconds, VDH pops up the notification that the MP4 is ready.  And it really is ready.  The part file has become an MP4 file & it is the complete opera.  But even after that, the CoApp continues to download something for another minute or two.  Again, I have no idea what it's downloading nor where this data is being stored.  But eventually, the CoApp decides it really doesn't have any more data to download & it stops.  So when I first reported this, it seems I was just not waiting long enough to see VDH take care of things on its own.  For you lucky folks with faster connections, all these things probably happen much quicker & perhaps you simply haven't observed them.  You probably have to catch the process when it's reaching something over 95% complete & stare at the VDH Running progress menu & don't blink because these things flash by rather quickly.

[Wild Willy]

I received this as a private E-mail but it probably should have been a post here instead.

> English subtitles are included but inactive when you're are in the streaming page. The URL includes
> a file named as a sequence of digits with the extension .srt
>
> For today's Boris Godunov opera, the URL for the English subtitles was:
> https://www.metopera.org/ondemand/imagelinks/subtitles/811357013939.srt
>
> I found that as soon a different language is selected for the subtitles, a new streaming object
> appears which is named as the file with the English subtitles with a language suffix.
>
> So for today's opera the URL for the Spanish subtitles was:
> https://www.metopera.org/ondemand/imagelinks/subtitles/811357013939.es.srt
>
> I downloaded them with the command:
> wget --no-check-certificate https://www.metopera.org/ondemand/imagelinks/subtitles/811357013939.es.srt

Interesting.  How did you discover this URL for Spanish captions?  Please explain in detail in a post here (not in a private E-mail) with screenshots so others can benefit.  I am guessing that since your URLs contain the qualifier "ondemand" that you are a subscriber to their for-pay service.  Is this correct?  I am not such a subscriber & in the streaming player I see, the only captions I can enable are English.  For tonight's opera, I discovered (using the technique I detailed above) that the manifest for tonight's Boris Godunov captions was this:

https://manifest.prod.boltdns.net/manifest/v1/hls/v4/clear/102076671001/1ae14ed8-5faa-464d-9e54-499597176a1e/6ee9e975-a4dd-437d-8600-b2c2c8def140/rendition.m3u8?fastly_token=gibberish

The part after the question mark is always gibberish.  It is a made-up token that is tied to your session with the player.  So everybody gets a different string there.  And even though I know what that was when I was downloading the opera, I went back just now & tried to use that URL to download the captions again.  It worked the first time I did it but it failed just now because it was valid hours ago & in the interim, I have closed my browser.  So it's timed out plus I've terminated my session.  I would have to go to the free download page again to generate a new gibberish string & then I could get the captions again.  Not happening, by the way.

The manifest file I did find hours ago contained pointers to 406 chunks, each of type vtt (not srt).  This eventually resulted in a .vtt file that contains 1,318 captions.  So they're delivered in chunks of 3 or 4 captions at a time.

I don't see anything that has to do with captions of type srt so I ask again, how did you discover the URL for them & are you a paying subscriber to their service?  Also, what languages are offered for captions when you stream these operas?

Separately, what is wget?  What operating system are you running?  I'm on Windows 7 & I don't believe I have ever seen anything on my system called wget.  Just to be sure, I opened a command session & did dir /s wget.exe on my boot partition & it told me "File not found."  So I'm quite curious about this thing.

[XaRaF]

We had srt link from MgFrogbozz and we didn't connect the dots.

In the first place I thought someone was monitoring network traffic while using Met mobile app On Demand to get it as in there we're able to select different language. We stick with free operas using main page but there's as well On Demand section on Met page, if we go there today then link for today's show is: https://www.metopera.org/season/on-demand/opera/?upc=811357013939

See anything familiar? ;)

And the video player here allows us to select different languages. From today's show it works for all but one - Portuguese - but in my case Met doesn't offer the second language I could benefit from so I'm happy with having English subtitles.

For some reason this method didn't work when I tried to grab English subtitles from the three shows I'm missing but worked out when activated 7-day free trial (Warning: remember kids to cancel it, will remain valid for 7 days, otherwise it'll renew automatically as per usual, link: http://www.metopera.org/account/manage-on-demand-subscription/Cancel/) and managed to grab subtitles for three missing shows replacing string of numbers in the srt link (uploaded to my dropbox folder), network inspection in latest Chrome wasn't showing vtt manifest and decided to not dig dipper to see if it's hidden somewhere else. Extra info: not every show will have subtitles in every language, for example La Bohema had only English subtitles. 

Now having cancelled 7-day free trial tho still active I'm unable to grab other language srt files from Met back catalogue so it might not be an universal method tho will be worth checking if it'll work for next free streams.

[Maximillium]

Re: "Separately, what is wget?  What operating system are you running?  I'm on Windows 7 & I don't believe I have ever seen anything on my system called wget.  Just to be sure, I opened a command session & did dir /s wget.exe on my boot partition & it told me "File not found."  So I'm quite curious about this thing."

checkout https://duckduckgo.com/?q=wget&t=ffsb&ia=web

Doesn't come with Winders, but seems to be available for Winders too.

[Erch]

It is true WW, I should have posted it instead of simply replying to your email. Sorry for that.

I discovered the Spanish subtitles using the Developer Tools (F12) bundled with my browser.

wget is a Linux command but you can have it in Windows by downloading and installing GNUWin32

If you have Windows 10 then you just need to setup the Windows Subsystem for Linux (WSL) and you would be able to run a Linux distribution inside Windows.

I will take some screenshots today to illustrate what I did.

BTW I am not a subscriber but just enjoying the free streaming from MOH

[Wild Willy]

Yes, I probably should have Googled it before asking my lazy question.  I have now located the PDF of the wget documentation & I've skimmed through it.  Seems like an alternative to ffmpeg but for general purpose use.  I may not bother with it since I have ffmpeg as part of VDH/CoApp & that's working well enough for me.  I am most curious to see how you get Met On Demand content when you are not a subscriber, not even on the 7-day free trial.