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.

[Wild Willy]

I tried going to the Met home page then the On Demand page.  They have a link there labelled "nightly stream" but when I click it, I get a page that appears to be only excerpts from La Rondine.  The player that loads up shows a clip that is only a couple of minutes long.  Whatever.  I'm happy with the nightly streams that do not go through the Met On Demand pathway.

[Erch]

This is an step-by-step guide describing what I do to locate and download the English and Spanish subtitles of the Met operas:

1. Point your browser to the launch page
   
2. Press F12 to toggle your browser developer tools on
3. Find out the URL for the English subtitles
   
4. Select the Spanish subtitles
   
5. Find out the URL for the Spanish subtitles
   
6. Download the desired subtitles from a Linux terminal or Windows Subsystem for Linux (WSL) session
   
7. Transfer the downloaded subtitles to the appropriate location. Windows users can access WSL folders by pointing Windows Explorer to \\wsl$ as shown below:
   

Hope this help you folks

[Wild Willy]

I am wondering now how I could be so slow on the uptake about this.  Anyway, in the hopes I will illuminate some things, here is a short tutorial on the pieces I was not understanding.

[XaRaF]

Erch - Thanks! Just had a look in Chrome and surprised I didn't see it writing yesterday post. Under Chrome there's a slight difference with the type column but entering srt in search box in the Network Inspection helps. In Windows there's no need for wget as you can open direct srt link in the browser and for example in Chrome select menu More tools -> Save page as or use Ctrl+S - it'll save as .txt so simply rename extension.

Wen't back to On Demand back catalogue and I'm just surprised that for example with past Aida show they don't stick with one ISO format for other languages and Swedish and Russian are as three letters swe and rus while others are only two letters. Despite that they all keep the same string of numbers so I have no idea why I wasn't able to access them yesterday.

Wild Willy - huge thanks for the tip about audio+video mp4 from this player!! I didn't even tried it yesterday playing around assuming it'll be the same result or worse seeing different player with chapters selection. Definitely saves me the hassle of playing merge with VLC  and the audio track seems to be a bit better quality than the one downloaded separately. On top of that while merging two files I noticed once or twice the end result was out of sync by a millisecond for whatever reason, no settings changed, especially noticeable during the introduction part. At least it shouldn't cause a headache during the aria parts.

Great work guys!

[Hans-Willi Schneider]

Hello ,
Please do not tell to me more.
I do not know, how I set me to the
video-downloadhelper...@googlegroups.com.
I have no Time and no knowledge!
Thanks and please, stop any e-mails
for hwschne...@gmail.com and genhu...@gmail.com .
Sincerely
H.W.Schneider

[Hans-Willi Schneider]

[Erch]

XaRaF - You're right and it is easier and faster. Just copy the URL and paste it on a new browser tab and you get the subtitles which just need to Save As. This works on both, Linux & Windows computers.

My preferred browser is Firefox and it is even easier to open any item from the DevTools by Right-Clicking on it and select the Open in a New Tab option as shown below:

BTW may be studying the JavaScript code for the Brightcove could suggest VDH how to deal with the unusual streaming segmentation and playback.

The URL to the code is:  https://www.metopera.org/MOoD/player/dist/bcgs_met_player-2.1.14.js

[Wild Willy]

Erch, if you just double click the entry in the DevTools list, that entry will open in a new tab.

Hans-Willi, you are receiving E-mails from Google, not any of us individually.  You are receiving these E-mails because your settings in this group specify that you want to receive these messages.  You need to change your settings.  There's a My Settings button in the upper right corner of every Google Groups post.  Hover your mouse over the button & a tooltip will float up labelling the button.  You need to click that, then click the "Membership and email settings" selection.  That's under the My Settings button.  There is also a plain Settings button as well, but that's not the one you want.

[Erch]

Sure, WW!

But  2 mouse-clicks = 2 mouse-clicks

Isn't it?

I guess you cannot argue about personal preferences  ;-)

All roads lead to Rome!

[Erch]

Looking more in depth I found some curiosities:

• As per the parameter name, it seems Met is using the Universal Product Code (barcode) to uniquely identify their Opera streamings.
• There is a relationship between the upc appearing in the launch page and the subtitles URLs as shown below:
  Launch page: https://www.metopera.org/season/on-demand/opera/?upc=811357012420
  English subtitles: https://www.metopera.org/ondemand/imagelinks/subtitles/811357012420.srt
  Spanish subtitles: https://www.metopera.org/ondemand/imagelinks/subtitles/811357012420.es.srt

BTW have you realized that the first name of several great opera composers start with the letter G?

• Giuseppe Verdi
• Giacomo Puccini
• Georges Bizet
• Gaetano Donizetti
• Gioachino Rossini

So you know, If your first name start with G then may be you could consider becoming an opera composer. :-)

Good luck with that!

[Wild Willy]

George Gershwin (TWO Gs!)

George Frederick Handel (or Georg Friedrich, depending on where you live)

Charles Gounod (so it's his last name, close enough)

Osvaldo Golijov (I have actually attended an opera by this guy)

Christoph Willibald Gluck

Gee, I wonder if there are more . . .

[Wild Willy]

Then there's Michel Gutierrez but I think he's a bit busy with other projects at the moment.  Surely he'll produce an opera before he's done.

[Wild Willy]

This business of having to guess & discover things by trial & error has been bugging me.  So I've made an attempt to try to understand what's going on here & eliminate as much guesswork as I can.  I know it's probably a mistake to apply logic to the situation but logic is the only tool I have.  Is this stuff correct?  I don't know.  Maybe somebody with actual knowledge & experience in this area can look at what I've written here & correct whatever mistakes I've made.  But here goes.

I have labelled the attached images CCS01, CCS02, etc. in honor of Cio-Cio-San.  Also, I have attached the images instead of embedding them inline within these posts so you can click them & view them full size.

I visit the Met home page (image CCS01), hit F12 to open the Firefox Developer Tools window, & set it to the Network Monitor.  As I've mentioned before, you need the Monitor open before you visit the nightly stream page because some things come up right away as soon as you open the nightly stream page & we want to see those.  If you wait until after you go to the nightly stream page to hit F12, it will be too late.  I continue to use the direct link off the home page, as opposed to the stream available in the Met On Demand area, for a few reasons.  First, I like having the audio separate from the video for these operas.  It allows for the possibility of perhaps loading one of these operas up on my iPod.  I think there's a way of doing that with iTunes.  That's the desktop application, not the store.  I would do this so I could listen to an opera while I'm working out at the gym.  You do remember gyms, right?  May they reopen some day.  Also, I can play the audio without watching the video if that urge takes me.  Second, I like having the captions in their own .vtt file.  This lets me edit them since the .vtt file is just a plain text file so you can edit them in any text editor, like Notepad.  I have found a very few spelling errors in the captions.  I have also found several unreadable characters in the captions for some of these operas.  They display in VLC as little diamonds with a question mark inside.  Mostly, these are dashes at the start of a line of dialog.  Sometimes they're ellipses.  A few times they've been simply incorrect punctuation that I ended up replacing with a colon or comma or even a period.  So I'm still using the simple streaming page.

I click the "Watch Now" button on the home page.  That takes me to the nightly stream page (image CCS02).  After a moment, 3 manifest files appear in the Monitor.  How do I know they're manifest files?  I hover the mouse over the entry & a tool tip hovers up showing the URL of the file.  The image shows only the tool tip for the first one but the other 2 are also manifests.  Buried in the middle of this particularly ugly URL you'll find the notation .m3u8.  (You can also see .m3u8 without hovering the mouse but I'm trying to be complete here.)  This obeys the standard naming convention for manifest files.  This appears to be the only accepted convention governing manifest files.  I Googled manifest files a couple of weeks ago & discovered there is no international standard governing the content of manifest files.  This makes what Michel has done to make VDH work as much as it does a truly remarkable effort.  This is the first manifest file so I would guess that it must be an important manifest.  This makes me want to look inside it to see what I can figure out.

To look inside that manifest, I double click that entry in the Monitor.  This opens a new blank browser tab & pops up a dialog box (image CCS03).  I have gone through this step before so some things are already in place.  But the important one is that I have not checked the box to "Do this automatically."  This dialog is Firefox's way of asking me every time what it should do with the file.  If you have not done this before, you need to drop down the selection box to choose an application to handle this manifest file (image CCS04).  When you click "Other..." in the selection box, it launches another dialog (image CCS05).  You should see a few applications listed here, not necessarily the same ones I'm getting on my system.  I happen to be using a replacement for Notepad called Metapad.  But Notepad works just fine.  What we want here is a text editor because a manifest file is just a plain text file & all we're trying to do here is look inside it.  Once you've selected your text editor, this action will be preselected on every manifest file you try to look at from now on.  You will be able to simply hit Enter when you get the dialog box in image CCS04.  That is what I did.  It launched Metapad & from there, I saved the manifest file so I could post it here (text file CCS06).

Now, I'm going to be extracting pieces of the manifest file to describe what I believe each piece means.  To see where I'm getting things from, you should have text file CCS06 open in the text editor on your system so you can read along with me.  Also, the URLs are extremely ugly & unwieldy.  To simplify things, I will replace the actual URLs with symbolic names URL01, URL02, etc.  The detail of the URL is not important.  Besides, as I've said before, a portion of these URLs contains a token made up of random gibberish that associates things with my playback session.  If you tried to use the URLs in text file CCS06, they wouldn't work.  The idea is to realize there is a URL in a particular place in the manifest file & understand what it points to.

Each entry of the manifest file appears to begin with the string #EXT-X-.  I'm going to be putting forward my best guesses of what each entry means & how it relates to the other entries.  If I'm wrong, do please correct me.

Entry #1 of the manifest file is this:

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0",NAME="en (Main)",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="URL01"

I think there's some significant items here.  TYPE=AUDIO probably means this is a descriptor for one of the audio streams.  GROUP-ID="audio-0" gives this entry a name that other entries can refer back to.  URL01 contains .m3u8.  In fact the URL in every entry in this manifest file contains .m3u8.  That means this manifest is a sort of master manifest, pointing to other manifests.  You can copy/paste each URL out of this manifest into your browser to see what those other manifests look like.  I won't be cluttering up this discussion with all of that, but it would be an educational exercise for you.  Of course, you'd have to visit the nightly stream page yourself to get a manifest that has URLs that would actually work for you.  So this first entry in this master manifest points to what looks to be one of the audio streams.  Which one?  I have my guesses which I will outline as I go along.  I will say that URL01 points to a manifest that consistes of a list of .ts URLs, so whatever it is, that lower level manifest appears to describe one of the streams, probably an MP4.

Entry #2 in manifest CCS06 is this:

#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subtitles-0",NAME="EN",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="URL02"

Note the TYPE=SUBTITLES here.  Doesn't take much thinking to jump to the conclusion that this must be telling us where the subtitles are. (Or captions, to use the VLC terminology.)  We've got GROUP-ID="subtitles-0" to give this entry a name.  Visiting URL02 in the browser did, in fact, show me the manifest listing all the .vtt chunks.  So it's not necessary to launch playback of the opera to find the subtitles.  That is very good to know.

Entry #3 in manifest CCS06 is this:

#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=1038400,CODECS="mp4a.40.2,avc1.42001e",RESOLUTION=640x360,AUDIO="audio-0",CLOSED-CAPTIONS=NONE,SUBTITLES="subtitles-0"
URL03

I'm a little perplexed by the fact that URL03 here is not specified as URI="URL03" similar to the other entries.  But there it is.  Nonetheless, it's pretty clear from several things in this entry that this must be the descriptor for the video stream at resolution 640x360.  Note the AUDIO="audio-0" specification.  I believe this is referring back to Entry #1 in this manifest, where it says GROUP-ID="audio-0".  I believe this is telling us that Entry #1 points to the audio stream that synchs up with the video stream described in Entry #3.  URL03 does point to another manifest that lists .ts chunks, which I would guess again is an MP4.  Note also the SUBTITLES="subtitles-0" reference back to the GROUP-ID="subtitles-0" part of Entry #2, the entry for the subtitles.  The specification BANDWIDTH=1038400 is interesting.  That number is not quite 1M.  Keep that number in mind for a bit.  I'll come back to it.

Entry #4 in manifest CCS06 is this:

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-1",NAME="en (Main)",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="URL04"

This looks a lot like Entry #1 except the GROUP-ID is "audio-1" instead of "audio-0".  So my best guess is this is a different audio stream.  Once again, URL04 points to a manifest containing .ts entries, so that is probably another MP4.

Entry #5 in manifest CCS06 is this:

#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=343200,CODECS="mp4a.40.2,avc1.42000d",RESOLUTION=320x180,AUDIO="audio-1",CLOSED-CAPTIONS=NONE,SUBTITLES="subtitles-0"
URL05

This must be the descriptor for the resolution 320x180 video stream.  AUDIO="audio-1" in this entry refers back to GROUP-ID="audio-1" in Entry #4, connecting this video stream to that audio stream.  We've got the reference back to the subtitles.  BANDWIDTH=343200 works out to about 335K.  URL05 points to a manifest with .ts entries.  All the rest of the URLs in this manifest also point to manifests of .ts chunks.

Entry #6 in manifest CCS06 is this:

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-2",NAME="en (Main)",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="URL06"

So here's a third audio stream named "audio-2".

Entry #7 in manifest CCS06 is this:

#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=635800,CODECS="mp4a.40.2,avc1.420015",RESOLUTION=480x270,AUDIO="audio-2",CLOSED-CAPTIONS=NONE,SUBTITLES="subtitles-0"
URL07

Must be the resolution 480x270 video stream using the "audio-2" audio stream in Entry #6.  BANDWIDTH=635800 is about 621K.  Unsurprisingly, this shares "subtitles-0" with all the other streams.  Duh.  There are only English subtitles available on this nightly stream page.

Entry #8 in manifest CCS06 is this:

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-3",NAME="en (Main)",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="URL08"

A fourth audio stream named "audio-3".

Entry #9 in manifest CCS06 is this:

#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=1879900,CODECS="mp4a.40.2,avc1.4d001e",RESOLUTION=768x432,AUDIO="audio-3",CLOSED-CAPTIONS=NONE,SUBTITLES="subtitles-0"
URL9

The resolution 768x432 video stream using the "audio-3" audio stream in Entry #8.  Shares the same subtitles as all the others.  BANDWIDTH=1879900 is about 1.80M.

Entry #10 in manifest CCS06 is this:

#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=3441900,CODECS="mp4a.40.2,avc1.4d001f",RESOLUTION=1280x720,AUDIO="audio-3",CLOSED-CAPTIONS=NONE,SUBTITLES="subtitles-0"
URL10

The resolution 1280x720 stream sharing the "audio-3" audio stream with the video stream in Entry #9.  Same subtitles.  BANDWIDTH=3441900 is about 3.28M.

This is the last entry in the master manifest.

We've got 4 audio streams & 5 video streams.  Look at what VDH recognizes (image CCS07).  VDH appears to have recognized all 5 of the video streams.  Compare the Mbps ratings in the VDH menu against the numbers provided by the BANDWIDTH values in the entries in the master manifest.  I came up with my numbers by dividing by 1,024, which is of course 1K.  Or dividing by 1Kx1K for the larger BANDWIDTH values.  It looks like VDH may not be dividing the numbers correctly, dividing by either 1,000 or 1,000,000, and then rounding pretty liberally.  I'm a computer geek.  I expect these things to be relative to powers of 2.  I guess that's just not the way things are done with streaming media.  It may be that VDH is getting these numbers from a source other than the manifest.  I just don't know.  Also, the highest resolution variant is being displayed in the VDH menu with a duration that is double the truth.  Plus 1 second.  Now that's weird.  You'll note that certain entries in the manifest have a NAME= parameter & that value appears in some of the VDH variant names.  I'm talking about the "EN (MAIN)" indications that appear on the VDH menu.  You can see in the manifest where those are coming from.  Interesting that the manifest shows "en" in lower case but VDH has changed it to upper case.

But there's only 1 audio stream listed.  Which one?  Why not all 4?  Plus it shows the erroneous double duration.  Well, I haven't launched playback yet.  Once I do that, VDH recognizes more things (image CCS08).  The list is now long enough that I have to scroll it.  The 5 video streams are still there, unchanged, in the part of the VDH menu that is scrolled out of sight.  But now there's 5 audio streams, not 4.  But one of them is the double duration stream that was already listed.  The new entries appear to be the correct audio streams.  But which is which?  Which audio stream goes with which video stream?  Would downloading the double length streams stop after the correct duration of 2:26:50?

(As an aside, I am reminded once again that the VDH menu chops off the controls at the bottom when it gets long enough to scroll.  I have been trying to shame Michel into fixing this bug for 2 years.  When will we get this fixed?  How much complaining is it going to take?)

So, following this analysis, I'm going to beef up my 1-line script that I described upthread here.  I'm going to boost it to 3 lines, each invoking ffmpeg.  The 3 lines will get, respectively, the captions, the audio, & the video.  It looks something like this:

ffmpeg -i URL02 Opera.vtt
ffmpeg -i URL08 Audio.mp4
ffmpeg -i URL10 Video.mp4

That shows the essential parts.  I do the files in this order because the captions take less than a minute, the audio anywhere from 15 to 25 minutes, & the video at least 2 hours if not 3.  On my slow connection, remember.  I have chosen the URLs for the manifests that describe the highest resolution video stream & its associated audio stream.  I don't have to guess via the VDH menu.  The manifest tells me exactly which audio stream goes with that video stream.  My actual script is a little more elaborate, allowing me to capture some logging information.  Here is the full script as I am executing it:

"C:\Program Files\net.downloadhelper.coapp\converter\build\win\64\ffmpeg.exe" -i https://manifest.prod.boltdns.net/manifest/v1/hls/v4/clear/102076671001/f0688e1b-7452-4124-9d7d-c03cf41117a5/a561c6fb-6016-4438-9075-17efaa836f3f/rendition.m3u8?fastly_token=NWU5YjgyMWZfNmYyYjQ2ZjFhOGM3ODMxOWYyZjM0MDJlMWIwNmRkZDlmOTY2MDA0NmIwMTQzZDA4N2QzMzJmNThkN2UzZDBkOQ%3D%3D "Q:\Opera\Madama Butterfly Video 20090307.vtt" 1>"Q:\Opera\Get Opera.Err" 2>"Q:\Opera\Get Opera.Log"
"C:\Program Files\net.downloadhelper.coapp\converter\build\win\64\ffmpeg.exe" -i https://manifest.prod.boltdns.net/manifest/v1/hls/v4/clear/102076671001/f0688e1b-7452-4124-9d7d-c03cf41117a5/a8d6efa6-91bb-4d6f-acaa-b90fe619371c/10s/rendition.m3u8?fastly_token=NWU5YjgyMWZfMTFjYTJkZDkyNzQzMDQ2MzJlMWY5YmY3YzI0MGQxNDMyN2RkM2U5ZDA1NGQ5YjUyMzFjYWUxYTMzMjlhNjM1MQ%3D%3D "Q:\Opera\Madama Butterfly Audio 20090307.mp4" 1>>"Q:\Opera\Get Opera.Err" 2>>"Q:\Opera\Get Opera.Log"
"C:\Program Files\net.downloadhelper.coapp\converter\build\win\64\ffmpeg.exe" -i https://manifest.prod.boltdns.net/manifest/v1/hls/v4/clear/102076671001/f0688e1b-7452-4124-9d7d-c03cf41117a5/77682e8a-b7d1-49c9-88af-e2acfbd663d4/10s/rendition.m3u8?fastly_token=NWU5YjgyMWZfZGFlYTY3NTUwNjNlODZjMDQ1YmRlYzllZTQ4Njc3YWQxNGNhNzEwYzllNmE4NTUyZjIxNGE0NTVhODZmNjg3Mw%3D%3D "Q:\Opera\Madama Butterfly Video 20090307.mp4" 1>>"Q:\Opera\Get Opera.Err" 2>>"Q:\Opera\Get Opera.Log"
exit

Now, this isn't perfect.  It worked well enough to download the captions & the audio stream.  But for some reason the third command to download the video failed on me after running apparently correctly for about 10 minutes.  After that, it simply stopped reading the stream even though ffmpeg showed as active in the Task Manager.  It happened twice in rapid succession so I reverted to using VDH to download that part of the opera.  There may be some odd parameter I'm not specifying.  I also noted that the download was using only about half my bandwidth.  I feel like I'm really close.  I may investigate wget if I feel really motivated.  For now, at least I know how to figure out how to match the right audio stream with the highest resolution video stream.

I also would like to know what is the significance of an entry that starts with #EXT-X-MEDIA: as opposed to #EXT-X-STREAM-INF:.  Given the lack of standards, I can't say whether this sort of thing occurs on other web sites.  For all I know, it's all unique to the Brightcove player.

Or somebody will read this & tell me something that will get me over this obstacle.

[Geevee]

Here's what I do now, based on all the wonderful info in this thread. This has worked for Butterfly yesterday and Lecouvreur today.

1. Go to the metopera menu, pick Season, then On Demand. This gets me to a page that has a Watch Now button

2. I click on the watch now button, and get to a page that has a player that seems to be for a preview, with scene selection at the side, and the UPC in the URL. BUT, If I invoke VLC the on this page, I get a download for the entire opera.

3. Then I put the the subtitle URL that Erch figured out: https://www.metopera.org/ondemand/imagelinks/subtitles/811357012420.srt , into a new tab, and substitute today's UPC

4. Now I have the subtitles in a browser window, Select all, put them into a notepad windowe, save as the appropriate srt file, and I'm done.

Easypeasy.

[Geevee]

Not "invoke VLC", "invioke VDH" dammit.

And the file I get is combined audio and video.

[Wild Willy]

Geevee, you know you can edit an existing post to correct typos like that.  Look at the upper right corner of your post.  Not the whole page, just your post.  There's a button with a drop down arrow that you can click.  It opens a menu on which one of the selections is Edit.  Then you can fix up your post & resave it.  You'll note there's a notation at the bottom right of any edited post saying that the post has been edited.  Several posts in this thread, including some of mine, show this notation.

I tried to get tonight's Der Rosenkavalier using my beefed up script.  It grabbed the captions & the audio stream just fine.  But a few dozen chunks into the video stream, it failed.  Oddly, ffmpeg didn't actually terminate so my script thought it was still running.  I had to hit Ctrl+c in the command window.  I had to hit it twice for some reason.  Usually, it takes hitting Ctrl+c only once to interrupt a script but for some reason, this needed 2 tries.  This seems to be something particular to ffmpeg.  The error message showing in my log says "Unable to read from socket."  Now, when the interruption occurs, there is unwritten data being held by ffmpeg.  I hope hitting Ctrl+c gets ffmpeg to write the rest of whatever it hadn't written.  I don't know if that's true, just a hope.  I say that because I can't really tell whether the socket failure message was part of the stuff ffmpeg had not yet written or if my hitting Ctrl+c triggered that message.  In any case, my technique seems completely unable to get the video stream after successfully getting both the captions & the full audio stream.

Out of curiosity, I wanted to get all the other audio streams described in tonight's manifest.  I wanted to see if there was any difference in the audio properties of the resulting mp4, specifically the bit rate & the sample rate.  I'm assuming these are indicators of the quality of the audio.  I used a variant of my command script to attempt it.  Even though I had already successfully used ffmpeg directly to get what I believe is the audio stream associated with the 1280x720 video stream, my attempts to get the other 3 streams using ffmpeg directly all failed.  Once again, this was after getting a few dozen chunks of the file.  The Resource Monitor showed me that data transmission had simply stopped.  Unsurprisingly, the lights stopped flashing on my DSL box, too.  But all was not lost.  After retrieving 2 chunks of a stream, any stream, ffmpeg logs a bunch of messages reporting the expected duration of the stream & a bunch of other stuff I don't understand.  One of the things it shows is the audio quality.  In all 3 failed cases, it showed a bit rate of 128kbps & a sample rate of 48kHz.  This matches what I got in the audio stream I did manage to download completely.  I expected that the audio quality for the lower resolution videos would be proportionately worse.  But that does not appear to be the case.  So it probably doesn't matter which audio stream you select out of the VDH menu for one of these operas.  I say that because somebody mentioned that the audio from the Met On Demand page seemed better to him.  I'm saying that is probably just a perception & not reality.  Nevertheless, I'd be curious to know what the audio properties are of tonight's opera from the On Demand page.

Since the download of one of these video streams takes me over 2 hours -- probably over 3 tonight since the thing is nearly 4 hours long -- I have not yet started it.  But I will do that as soon as I post this.  Just for comparison, the captions (98.2K) tonight took less than 1 minute & the audio stream (212M) took 14 minutes.  I'm expecting the video will give a file size of something approaching 5G, hence my expectation it will take rather longer than some of the other operas.

[XaRaF]

Wild Willy - Can't help with your scripts and trying to get all the streams - my know-how is limited to following tutorials ;) I did mention audio being better from On Demand page after checking the numbers in file details - I mentioned I'm tone def so wasn't going to rely on my ears. Having faster fiber, tho without premium in VDH, I just downloaded today's show and as you can see there are differences both in audio and video quality and what VDH is reporting as available depending which page you have open. I won't cry over quality of the past shows downloaded from the main page but since finding out the On Demand page gives better files I'll stick to it.

[Geevee]

Thanks for the info about editing, Willy --- as well as for the other things I've learned from you in this thread.

I was inspired yesterday to try to get the Vienna posts, since I learned how to use ffmpeg from this thread. I had given up since neither VDH nor chrome's Stream Recorder worked there.I figured out which m3u8's to use and started three CMD sessions per your descriptions.

I discovered that the download would stop for random periods but would eventually resume. The subs downloaded quickly, the video took 8 hours, and the audio is 2/3 complete now after 18 hours. I'm hoping to get a complete 1080p Capriccio eventually.

[Wild Willy]

XaRaF Thanks for the comparisons.  It seems that the On Demand video & audio may be a hair better.  Plus you got a 192Kbps audio stream off the regular page.  I didn't see one like that.  Weird.

Geevee Vienna posts?  What are you referring to?  On these opera streams, VDH stops downloading every so often.  This seems to be related to it "catching up" with downloaded chunks.  It will go along for 20 minutes, half an hour, longer without updating the .part file.  The progress in the Running (blue dot) menu will not change.  Then it starts updating the .part file & the file size increases while the VDH progress will leap 10, 20, 30 percentage points in a matter of seconds or a minute.  My CPU fans speed up during this catch-up process.  But then the download resumes.  I wish that had happened when I was trying to download with ffmpeg directly.  I left it sit one time for 10 minutes & nothing happened.  Not only was there no data transmission but there was no file activity.  Strangely, when I'm trying to get one of these videos with ffmpeg, my CPU fans are running at higher than usual speed continuously.  Not surprising, given that my CPU is pegged near 100%.  Maybe that's why they call it ffmPEG.  That doesn't happen with the captions or the audio stream, which also happen to use a much higher percentage of my bandwidth, whereas the video download uses only a small fraction of my bandwidth   During one of VDH's catch-up phases, my CPU usage seems to be around 10%-12%, which doesn't seem all that high, but I guess it's enough to get my CPU fans excited.  Using ffmpeg on the video stream, after a few minutes everything just stops & I get that message about failure to read from socket, which seems like it might be fatal, indicating that no amount of waiting is going to see a resumption of the download.  I've looked for a retry parameter on ffmpeg but I haven't found one . . . yet.

18 hours?  Wow, that's long.

[Erch]

You can go directly to the nightly stream page, open the DevTools, set it to Network Monitor and reload the page (F5).

That's what I have been doing!

[Geevee]

The Vienna Staatsoper is also streaming. Capriccio yesterday, L'Italiana today. After the Capriccio audio stream from there stopped for an hour at 3/4 complete, I gave up. Had a brainstorm, got a version of ffmpeg from videohelp.com and downloaded the complete audio in 1/2 hour. No stops and starts. I guess the VDH ffmpeg has a lot of VDH-specific parameters. L'Italiana audio and English subs are already complete.  The video is chugging along. Couldn't have known where to start without you and the gang.

[Erch]

Very good Geevee!

Adding a .xx after the upc, where xx is the two-letter code of the desired language would get you the corresponding subtitles file if available:

https://www.metopera.org/ondemand/imagelinks/subtitles/811357012420.es.srt  for Spanish subtitles

https://www.metopera.org/ondemand/imagelinks/subtitles/811357012420.fr.srt  for French subtitles

an so on.

BTW no need for notepad or any other text editor simply File/Save Page As...

[Wild Willy]

Yes, we are much stronger working together than toiling alone (despite social distancing).  Brainstorms are good.  I need to have them more often.  I just Googled ffmpeg, then clicked the link for download on the Google results page.  This took me to the ffmpeg web site where they had a link to some place where somebody posted a Windows 64-bit build, apparently voluntarily.  Kind soul.  That page is https://ffmpeg.zeranoe.com/builds/.  I appear to have gotten an ffmpeg that was built earlier today.  As a test, I am currently in the process of downloading the video portion of tonight's Elektra, one I saw in a theatre the day it was performed.  At the moment, my log says it has just downloaded segment 180, which is around 30 minutes into the video (ffmpeg logs this information), which is way more than I've ever managed to get in my recent failed attempts.  Elektra is a relatively short opera.  This MP4 will last 01:52:02.55, according to the ffmpeg report after the second segment.  That's much shorter than any of the other free streams we've gotten in the past couple of weeks.  That will still probably take around 2 hours at this rate for me to get it all.  This ffmpeg has reached an equilibrium of about 20%-30% of my CPU, with the associated sustained blowing of my case fans.  Better than the 100% I had been seeing with VDH's captive ffmpeg.  It's also pretty much saturating my bandwidth, not quite but close, also significantly better than VDH's captive ffmpeg.  Plus it appears to be more flexible in giving up bandwidth if you happen to want to visit some random web page while the download continues.  This all leads me to suggest Michel use a new ffmpeg when he makes his next build of VDH/CoApp.  I don't know if he simply uses fancy-ass parameters we plebes wouldn't understand or if he has additionally gone into the open source code & made some customizations unique to VDH.  Those customizations would probably make whatever he did a bit more of an effort to port to any new version of ffmpeg.  Using VDH's captive ffmpeg, it identifies itself as ffmpeg version N-91146-gfe84f70819-vdhcoapp, which leads me to believe Michel has modified the open source.  Using the build I just got, it identifies itself as ffmpeg version git-2020-04-20-cacdac8.

Italiana is an opera I rather like.  I think I'll get that one.  Thanks.

All of which is to say THANK YOU!  Thank you for having your brainstorm, Geevee.

[Bruce R]

Thanks to all working together to figure this out.

Geevee, could you outline your process with the Vienna State Opera streams? It seems somewhat different than the Met.

Thank you

If there are other Mac users on this thread who have questions about the Met process, I will try to help.

Bruce

[Wild Willy]

Oops.  The Staatsoper is a 30-day free trial & then you have to cancel or they'll start charging you.  In Euros, which will ding me for additional foreign currency fees on my credit card.  I'm leery of these free trial things that want my credit card number anyway.  No thanks.

[Geevee]

Use Firefox. it suppresses the popup to ask you to log in, and you go straight to the watch now free.

[Erch]

Guys,

Not sure if you are aware of the fact that since last week the issue with VDH not downloading the sound is gone and VDH is working flawlessly.

This is what I have been doing and just did today:

1. Point my browser to the Met Nightly Opera Streams page
   https://www.metopera.org/user-information/nightly-met-opera-streams/
2. Click on the link to today's opera (i.e.Elektra) to open the player's page
   https://www.metopera.org/season/on-demand/opera/?upc=811357018477
3. Open VDH and select the desired stream
   
4. Open a new browser tab and typing the appropriate URL for the English subtitles
   https://www.metopera.org/ondemand/imagelinks/subtitles/811357018477.srt
5. File/Save Page As... to save the English subtitles file
   
6. Open a new browser tab and typing the appropriate URL for the Spanish subtitles
   https://www.metopera.org/ondemand/imagelinks/subtitles/811357018477.es.srt
7. File/Save Page As... to save the Spanish subtitles file
   

I know the research has been interesting but kind of there is no need anymore for walking the tricky path

[Wild Willy]

I must be kind of thick because I'm not getting it.  I go to the Staatsoper page (image #1).  I tab to the FREE button.  For some reason, clicking that with my mouse does nothing.  The page doesn't recognize my mouse.  Very weird.  So then I hit Enter on the FREE button.  This pops up a "redirecting" message for just a moment (image #2).  Then it lands me on a login page (image #3) from which I cannot escape.  And yes, this is Firefox.  And yes, I have it set to block popups (image #4) & my Exceptions list is empty.  What's your magic spell?

[Geevee]

I think it's Adblock. I have two versions of Chrome, one with Adblock, one without. I only get to the Login page in the one without Adblock.

[Geevee]

OK hope I got all the steps. I am doing this on a Windows desktop running Win10 Home x64.

1. Get a current version of ffmpeg. I got mine (version 4.2.2 from Jan 2020) from here: https://www.videohelp.com/software/ffmpeg

2. Unzip it into a convenient folder.

3. I made 3 BAT files in Notepad, one for audio, one for video, one for subs. I am attaching them. The ones I have attached will download the current offering (L'Italiana in Algeri).  We can't upload BAT files here, so I changed the extension to txt. You'll have to change it back.
The contents of each file follow

4. audio.bat : "E:\ffmpeg-4.2.2-win64-static\bin\ffmpeg.exe" -i https://live.performa.intio.tv/media/255ff6b4-6f55-482c-afbc-6f10dcf597ec/hls_audio_13_96_25.m3u8 -vcodec copy -acodec copy -bsf:a aac_adtstoasc  "e:\LItaliana Vienna\LItaliana.audio.mp4

5. video.bat :"E:\ffmpeg-4.2.2-win64-static\bin\ffmpeg.exe" -i https://live.performa.intio.tv/media/255ff6b4-6f55-482c-afbc-6f10dcf597ec/hls_video_6_7800_25.m3u8  -vcodec copy -acodec copy -bsf:a aac_adtstoasc -timeout 500 "e:\litaliana vienna\litaliana.video.mp4"

6. subs.bat : "E:\ffmpeg-4.2.2-win64-static\bin\ffmpeg.exe" -i https://live.performa.intio.tv/media/255ff6b4-6f55-482c-afbc-6f10dcf597ec/subs-eng.m3u8  -vcodec copy -acodec copy -bsf:a aac_adtstoasc -timeout 500 "e:\litaliana vienna\litaliana.srt"

7. save each file into the folder where you will put the opera. Edit them to account for your file structure: where you put the ffmpeg, where you want the output file to go. Edit in notepad (NOT wordpad or any other fancy editor --- you need a dumb editor for this)

8. Open a CMD window, so you can follow the progress. Navigate to the folder which contains the batch files. Type video.bat and hit enter The download should take off. You can open a cmd window for each file and run all three concurrently

8a. Use VLC to combine the video and audio. File menu; Open multiple files, add the video, click on Show more options, add the audio file to be played simultaneously, select Convert in the dropdown box, give the combined file a name. Wait for VLC to combine. This will take a long time. it's bu=y far the longest part of the process.

9. For the Staatsoper's next offering, go to the watch now page (Apparently you have to have adblock active to avoid creating an account). Before starting the opera. use the F12 key to open the Developer tools (most conveniently, have them open on the righthand side of the screen).

10. Now start the opera, select your preferred subtitle language, and pause the download. You will see a lot of the segments that have been sent, but you are only interested in the .m3u8 ones, so you enter m3u8 into the filter field.

11. Right-click on the video m3u8, click on copy, then click on copy URL. Edit the BAT file, paste the URL into it, change the output file name, and save the BAT file. Click on it in a CMD window to download the video.

12. do the same for the audio and subs.

I'm attaching copies of the BAT files for L'Italiana, a screenshot of the CMD window, and a screenshot of the Vienna download page with the relevant bits of ther developer tools marked.

It looks like a lot of work but each step is prerty simple.

[Wild Willy]

I don't have Adblocker specifically but I did disable my advertising defense.  I still couldn't get to the live stream.  You are starting at www.staatsoperlive.com, correct?

No matter.  Since you so kindly provided the URLs of the 3 relevant manifests in your attachments, I just used those.  My .Bat script looks like this:

"G:\ffmpeg\ffmpeg-20200420-cacdac8-win64-static\bin\ffmpeg.exe" -i https://live.performa.intio.tv/media/255ff6b4-6f55-482c-afbc-6f10dcf597ec/subs-eng.m3u8 "Q:\Opera\L'Italiana in Algeri Video 20170408.srt" 1>"Q:\Opera\Get Opera.Err" 2>"Q:\Opera\Get Opera.Log"
"G:\ffmpeg\ffmpeg-20200420-cacdac8-win64-static\bin\ffmpeg.exe" -i https://live.performa.intio.tv/media/255ff6b4-6f55-482c-afbc-6f10dcf597ec/hls_audio_13_96_25.m3u8 "Q:\Opera\L'Italiana in Algeri Audio 20170408.mp4" 1>>"Q:\Opera\Get Opera.Err" 2>>"Q:\Opera\Get Opera.Log"
"G:\ffmpeg\ffmpeg-20200420-cacdac8-win64-static\bin\ffmpeg.exe" -i https://live.performa.intio.tv/media/255ff6b4-6f55-482c-afbc-6f10dcf597ec/hls_video_6_7800_25.m3u8 "Q:\Opera\L'Italiana in Algeri Video 20170408.mp4" 1>>"Q:\Opera\Get Opera.Err" 2>>"Q:\Opera\Get Opera.Log"
exit

No need to open a command window, no need to change directories, none of that.  Just 3 lines, 3 invocations of ffmpeg.  Things look like there's more lines here because of line folding.  But it's only 3 lines, plus exit to terminate the script.  Also, I don't use any parameters for ffmpeg.  Where did you get the ones you used?  You'll note I have spaces in my file names, and even an apostrophe.  I was surprised recently to learn that apostrophe is actually a valid character in file names.  Go figure.

Also, my script captures the output log that ffmpeg generates.  That lets you peruse the ffmpeg output at your leisure.  You are not forced to try to read things as they fly by in a command session window.  You can open the log file while ffmpeg is running.  Just don't save the file.  If you want to see progress, just reopen the file.  It will be longer each time you open it.

The subtitle manifest points off to a stream manifest in which each chunk has a URL that ends in .vtt.  Highly irregular.  The chunks are in fact in .srt format.  There were 1,527 chunks resulting in 2,196 individual captions.  Many of them take up 3 lines, which is in violation of a standard common on this side of the Atlantic which limits captions to 2 lines.  Whatever.  That's the way that is & so be it.  I will be loading these captions up into my caption editor & converting the file to .vtt.  I prefer .vtt format because it is simpler.  Also, the download speed for the captions was ATROCIOUS!  Under 4,000 bytes per second.  That's even worse than an old dial-up modem.  I needed to pay close attention to it because I was sure the download had failed, it was so slow.  But it did eventually complete.  I can't say how long the download took because the file is not created until after the last caption chunk is read, so I don't have created & last modified times to compare.  The created & last modified times are the same.  Unfortunately, ffmpeg does not time stamp any of its log entries so there's no help there.  I think it took about 10 minutes to download a file that is only 172K.

After the slow download of the captions, I was expecting the audio stream to take forever, maybe 10 hours.  Nope.  141MB file got downloaded in 10 minutes.  File properties report a bit rate of 128kbps, sample rate of 48kHz, & 2-channel stereo.  I have not yet loaded that up into VLC to sample it.  The duration reported in the ffmpeg log & the duration reported by Windows for the MP4 file agree on 02:32:36.12.  The audio stream consisted of 1,527 chunks, matching the caption stream.  That's not really necessary.  I think they chopped up the captions to match the audio stream, which is a lot more than they really needed to.  Maybe if they didn't chop it up that much, ffmpeg could have gotten a better usage of bandwidth & it wouldn't have taken so long to download.  The Met's captions typically come flying in at under a minute.  I figured out for one of their operas that they average 3-4 captions per chunk.  Even at only 3 captions per chunk, that would cut the number of chunks in the Staatsoper caption stream in half.

As I write this, the download of the video stream is in progress.  It's saturating my bandwidth, which is a good thing.  As slow as my connection is, I want downloads to use every last bit of what I can get.  According to ffmpeg, this is a full resolution of 1920x1080 at 25fps.  At the moment, it appears to be working on chunk #159, which is about 15.5 minutes into the stream.  This one may take a couple of hours.  I suspect this one will also come in at 1,527 chunks.  I could go read the stream manifest but I don't want to take bandwidth away from this download.  The CPU usage by ffmpeg during this last part of the download seems to be hovering between 10% & 20%.  That's less than I observed for Elektra earlier.

[Wild Willy]

Michel, you may think this thread has veered far off topic, that we're just a bunch of crazy opera fans geeking out on our favorite art form.  You may think we're even explaining to the world how to use something else besides VDH to do our downloads.  You would be wrong.

You need to see deeper into what we're discussing here.  We're saying there's things we want to do that we think VDH should be doing.  We're using ffmpeg to get things done that VDH can't do.  But doesn't VDH use ffmpeg?  I suppose I should ask doesn't the Companion Application use ffmpeg?  Ffmpeg is a tool you're already using.  The things we're trying to do really ought to be built into VDH/CoApp.

I did a deep dive into a manifest file served up by the Metropolitan Opera web site.  Read it carefully.  It's upthread here.  I was making a lot of guesses.  If I guessed wrong, do correct me.  But it seems to me that the master manifest for any of these free nightly opera streams on the Met web site follows a specific pattern.  The caption .vtt file is clearly identified in the manifest.  The relation between certain audio streams & certain video streams is clearly identified in the manifest.  VDH should be creating a menu that says this audio stream goes with this video stream.  The information is in the manifest.  You should be using it.

Further, I have discovered that ffmpeg reports whether a stream is audio+video, audio without video, or video without audio.  It appears to do this after reading 2 or 3 chunks of a media stream.  Either you should be capturing ffmpeg's information, or you should have VDH, well, maybe it's the CoApp, speculatively read the first 2 or 3 chunks of every stream you can find from the master manifest & identify audio+video, audio without video, & video without audio in the VDH menu.  And of course, captions, too.  I see ffmpeg doing it.  VDH should do it as well.

It seems that after reading the first 2 or 3 chunks of a stream, ffmpeg can say what the duration of the stream is, even for caption files.  You should be putting this duration information into EVERY entry in the VDH menu.  As things stand now, you aren't doing this.  There's really no excuse.  Every stream apparently contains this information in its first 2 or 3 chunks.  You need to be putting this information into the VDH menu.  Maybe you can defer collecting this information until the user actually opens the VDH menu.  No sense in collecting it if the user isn't going to use VDH.  I would see no harm in opening the VDH menu & seeing the message, "Collecting media information, please stand by."  After a few moments, you would then present us with all the information we would need to make an intelligent selection.

Oh but sometimes VDH doesn't get that information until you actually launch playback of a stream.  That's understood.  There's no standard to how web sites present their content.  The Met gives us a pretty good manifest just by visiting their player page.  Apparently, other sites aren't so helpful.  I gather YouTube isn't too helpful.  I'm not saying you should attempt to launch a playback simply so you can populate the VDH menu.  But you should be using what you get as soon as you get it.

Oh but the Met is a special case.  YouTube is a special case.  Has that stopped you from jumping through hoops to make it work?  And next week, who knows what frivolous, irresponsible changes YouTube will foist on the world?  And you will jump through their hoops again as you have always done.  Let me point out that for as long as we are all in quarantine, the Metropolitan Opera has become a global resource.  They are offering one opera stream every night, free, to the world, without geographic restriction, without making you sign up for a free trial, without even making you logon.  Every night.  For free.  For as long as they will be prohibited from mounting productions on their stage.  This makes them easily at least the peer of YouTube if not their superior, & worthy of your customizing VDH/CoApp to make it work properly with the Met's offerings.

But even if you do customize VDH/CoApp for the Met, my suspicion is that support for captions, dealing with separate video & audio streams, and the other issues we've been discussing here will in fact turn out to generalize to many more sites than just the Met.  Other users in other threads have reported issues with separate video & audio streams.  What you do for the Met will most likely work on many more web sites.  Other users in other threads have raised the issue of captions.  Again, whatever custom changes you might make for the Met will likely turn out to be not so customized.  Can you say that about anything you've done for YouTube?  Moreover, the Met is unlikely to make large changes to their protocols.  Can you say that about YouTube?

So don't make the mistake of dismissing the discussion in this thread as a fringe group idly whiling away their time on obscure subjects.  This thread is dealing with things that you should be working to incorporate into VDH/CoApp.

[Wild Willy]

Converting the Italiana .srt to .vtt uncovered the fact that there are only 1,280 captions, not the 2,196 in the original .srt.  First, there's a very large number of lines in the .srt that read simply

WEBVTT

I haven't completed my download of the video yet so I haven't been able to test what the original .srt caption file causes VLC to do with these captions.  A proper .vtt file begins with a line like that but it's supposed to be the only line like that.  I guess that must be acceptable in a .srt file but I just don't know.  In any case, I manually removed those lines in a mass find/replace before doing the caption conversion.  The conversion then eliminated a rather large number of captions that consisted of just this:

\h

I have no idea what that's supposed to display as a caption.  Anyway, the conversion removed them, including a sequence of about 75 of them that appeared to cover the time at the end of the show when the singers are taking their curtain calls & the audience is applauding.  Come on.  You don't need captions for that.

There were still maybe 8 or 10 captions left that contained simply this:

...

I ditched those.  So the 172K .srt file became a 124K .vtt file.  As I've been saying, I prefer .vtt captions.

Oops.  My video download appears to have failed after 4 hours at time index 02:03:47.12.  That's disappointing.  The full length is supposedly 02:32:36.12, so I apparently am missing the last 29 minutes or so of the opera.  I'll have to look into that & see what I can figure out.  Probably nothing.  I'll just have to try again.  The stream is available for the next 3 days so I have time to retry.

[Wild Willy]

It seems I received a corrupt packet & that caused ffmpeg to just quit.  That could be caused by any number of things, including line noise, I suppose.  I've attached the tail end of the log I've gotten.  Maybe this will tell something to somebody who understands these things.  There's probably nothing I can do but try again.  The 2.87G partial MP4 of the video won't play in VLC.  Like I'm surprised.  I'm not retrying now.  Maybe I'll set it to download while I'm sleeping.

[XaRaF]

Erch - if you check earlier messages from 16th you'll notice Wild Willy made us aware of the fact ;) Just started re-downloading some of the shows, making most of the 7-day free trial on met, as the files are bit better quality coming from the On Demand page and it'll fix those few rare issues I had with merge results being slightly out of sync for whatever reason.

And as for subtitles, as I've said earlier, met is not consistent in using only two letter ISO for naming the srt files. So far looks like they stick to es for Spanish but Swedish is three swe and so is Portuguese prt and already seen Russian being as ru and rus plus some operas are with English CC (Closes Captions) and those srt are with engcc. I guess it's always best to check On Demand page of each opera to see what language is available and confirm file name using browser DevTools inspecting network traffic when changing subtitle options in the opera player.

Geevee - thanks for the info on Staatoper, once out of the lockdown I'll have to invest in new server hard drives just for the operas. And who would've guessed by sitting at home I'll become less of an uncultured swine ;)

[Erch]

XaRaF - You're right about your previous comment about Met inconsistency in naming the subtitles files. I guess I simply missed it

However as per suggestion, I have re-read the whole thread from Apr 16th on, without finding any post from WW about the issue with VDH downloading only the video with no audio. Could you please, point out to the exact WW post you referred?

Thanks!

[XaRaF]

I was referring to the fact that WW already pointed out in his slide #4 that On Demand page gives us complete mp4 audio+video https://groups.google.com/d/msg/video-downloadhelper-q-and-a/8V2cRB-bcK4/0ORb7PoqBgAJ

Don't worry about that, there's plenty of information flowing in this thread already and it's easy to miss stuff.

[Geevee]

Willy, unless you specifically tell ffmpg NOT to re-encode video and audio, it will take the time to do so. That's why your download is at

speed=0.496x, i.e. almost double the play time.

the patameters -vcodec copy -acodec copy -bsf:a aac_adtstoasc force ffmpeg to just use whatever codecs it gets. I had speed=3.xxx (i.e. three times faster than play time) for my download because of that.

Also, you can download the three file simultaneously if you issue the three commands separately.

[mig]

Maybe this helps: VDH 7.4.0a1 is the latest beta version for Firefox and is now online from http://www.downloadhelper.net/firefox/betas

This version includes a new tool to merge an audio and a video file into a single audio+video file.

The feature is available from the main panel (along with Convert local files, Analyze page, ...) and can also be invoked from the context menu (right-click) Video DownloadHelper > Aggregate local audio and video files.

[Wild Willy]

Thanks, Michel!  I've installed it.  I will probably use the audio+video merge in many instances but for these operas, for the reasons I've mentioned a couple of times, I rather like having the audio & video separate.  But what about what I said about VDH recognizing that audio & video are separated?  What about VDH associating the audio & video streams when the manifest contains enough information to make that association?  I'm not saying VDH should automatically merge the audio & video, just list them in a way that makes it clear audio x goes with video x.  With these opera streams, all the video streams are listed first in descending order of resolution.  And there's no indication they are video-only streams on the VDH menu, which there should be.  After all of those, all the audio streams are listed in an order that we can only guess at . . . unless we're willing to look inside the manifest ourselves, and even then, I can't figure out which entry in the manifest matches up with which entry on the VDH menu.  (Well, I would guess you list them in the order in which they appear in the manifest, but that's only a guess.)  Plus, the audio-only streams aren't actually labelled audio-only, which they should be.  I say VDH ought to be helping us out here.  And the other things I suggested?

Geevee, thanks for that.  I have looked at the documentation that comes with ffmpeg (the version I got) & it's the typical Unix-lover's style of documentation.  If you already know pretty much what the thing is all about, then it's great.  If you're not a regular at this club & you try to enter through the front door, the bouncer is there to block your way.  I have looked high & low for anything that explains what to do if a stream is interrupted.  How do you resume it from the point of failure?  I've got the log ffmpeg generates.  I can tell to the fraction of a second how much of the stream has successfully downloaded.  I've found a parameter (I'm not going back to find it again) that will accept that number as its value when you invoke ffmpeg.  But I can't find a way of telling it to start there & append the remainder of the stream on the back of the output file I already have.  All I have found in Google searches is questions from people who are constructing videos & have a problem that interrupts that process.  Nobody seems to have the problem of an interrupted download when all you're doing is pulling a stream into a file.  And it is utterly counterintuitive to me that ffmpeg would do anything to the file if I haven't asked for it.  I'm not . . . what do they call it? . . . transcoding or remuxing or anything else.  I'm just taking a stream & putting it into a file.  Why would they go & process that in any way when I haven't asked for that?  It would be nice if there were introductory documentation on USAGE.  For beginners.  Not dummies.  How I hate that whole concept of "Fill-in-the-blank for Dummies."  That's just insulting.  I'm not a dummy.  There's just something I don't know.  If you can't explain it, then you don't really understand it no matter how much you think you do.  The proof that anybody really understands something is that they can explain it to someone who does not.  The Unix world seems to be filled with people who are incapable of explaining anything so I conclude . . . well, it should be obvious what I conclude.  They seem determined to prevent beginners from becoming experts.  They want to keep the knowledge to themselves to preserve their own sense of self-importance.  It's the primary reason I have always stayed away from all flavors of Unix.  You already have to understand it in depth before any of the documentation makes any sense to you.  I certainly have no excessive love for Windows.  I used to be an OS/2 diehard.  It was the best OS for PCs ever.  It was like System/390 for the PC, which was great for me because I'm a mainframe guy from way back.  But when IBM abandoned OS/2, so did I.  I just got tired of swimming against the current with it.  New hardware would come out & it wouldn't be supported on OS/2 until a year or two later, if at all.  And all the new online streaming protocols (and by "new" I'm talking about the state of affairs 15-20 years ago) were simply not usable on OS/2.  So I wouldn't say I love Windows & that's keeping me off Unix.  No, it's the kind of attitude embodied in the ffmpeg documentation that's keeping me off Unix.

I will forthwith put your parameters onto my invocations of ffmpeg & let you know what I see.  As for letting all 3 commands run at the same time, that's just not worth trying on my slow connection.  They would just compete with each other for my paltry bandwidth & in the end, the total time would still be the same as what I get by running them one after the other.  If the day ever comes when I actually have a fast connection here, then yes, it would make sense to run them simultaneously.  But at the moment, it makes no sense for me.

[Wild Willy]

Well, Geevee, your advice is correct & incorrect.  Let me get the incorrect out of the way first.  I specified exactly what you recommended & it seemed to have no effect.  So I cancelled the download of the video for Italiana & went to the documentation I have, which sucks, as I've just said.  But I did manage to figure out that -acodec & -vcodec for you are actually -codec:a & -codec:v for me.  I think this is due to our not having the same build of ffmpeg.  I got mine off the ffmpeg site, more or less.  In any case, there is another way of coding this parameter that reads

-codec: copy

which works for both audio & video.  And anything else, although I'm not sure what else might be possible.  As for your -bsf:a parameter, what I read made me think it's probably not relevant to what we're doing here so I've left it off for the moment.  We'll see if I manage to get an MP4 that VLC likes out of this attempt.

The speed I'm seeing -- it's reported on practically every line being logged by ffmpeg -- is still only around 0.5.  Hey.  I've got a stinking slow connection.  I am not going to see a download coming in at 3 times the speed of playback.  It's just that slow.  It's not going to happen.

However, here's where you were correct.  My case fans are not blowing up a hurricane & ffmpeg is using approximately 0% of my CPU.  The download is flying along . . . well, that's relative, of course, given nothing on my connection exactly flies.  But it is flying along in my frame of reference.  It's using pretty much all my available bandwidth.  What I'm seeing logged looks just like what was logged last night in the download that failed with the corrupt packet.  But it isn't beating the hell out of my CPU.  So the copy thing is indeed preventing whatever unnecessary transcoding was happening before, and for that, I thank you.  I'm expecting this download will take upwards of 4 hours, same as last night.  The transcoding was something my CPU was doing, but that had no impact on the speed of data transmission on my Internet connection.  Data transmission takes no CPU.  The fact that my CPU was being stressed would not have caused any sort of slowdown on my connection, so the fact that my CPU is now mostly idle still has no effect on my download speed.  It's slow & that's how it's going to be for now.

Stay tuned.

Meanwhile, I'm still not able to get into the Staatsoper streams myself.  What URL are you getting the stream off of?  The image you posted didn't show the URL.

[Geevee]

These guys claim that there is a flag for dropping corrupt input packets: https://stackoverflow.com/questions/61091012/corrupt-input-packet-in-stream-1-error-in-ffmpeg

"You can tell ffmpeg to drop corrupt packets i.e.

ffmpeg -fflags +discardcorrupt -i myvideo.mp4 -c copy output.ts

With version 4, required bitstream filters are automatically applied."

Their example is not HLS streaming, so it may not work for you.

It wasn't documented in the FFMpeg documentation I've been puzzling over https://ffmpeg.org/ffmpeg.html

so I looked some more and found it in an even more detailed ffmpeg documentation where it is documented https://www.ffmpeg.org/ffmpeg-formats.htm

With most of this ffmpeg documentation, I have no idea what they are talking about because I've never encountered any of the concepts.

Also, today'sVienna  ballet won't play for me. I get to the player and it won't take off. I get a sentry entry on the network tab that says "event rejected due to rate limits"

[Wild Willy]

My download of the video of the Staatsoper Italiana finally completed after 6 hours & 12 minutes.  I tried to interfere with its bandwidth as little as I could & it still took that long.  Clearly, my corrupted packet the other night was a transient failure.  I need to see if I can squeeze the ffmpeg documentation to see if there's some sort of parameters that will make the thing retry something when it encounters an error.  I don't hold out much hope.  I'm not even very optmistic about finding any help via Google.  A quick scroll through the ffmpeg log for this download showed the speed holding around 0.5.

In any case, file properties are telling me its size is 8.31G, resolution 1920x1080, 25fps, data rate 7794kbps, total bit rate 7794kbps.  It gives a very pretty image on playback.  As I suspected, the video stream consisted of 1,527 chunks, same as both the captions & the audio stream.  Compare that with tonight's Met Tosca: captions=283 chunks, audio=856 chunks, video=848 chunks.  I am guessing that somebody over there encoding their broadcasts for online viewing doesn't totally grasp the underlying concepts.  Not that I do, but this looks to me like they tried to make all 3 streams the same number of chunks, probably taking the video as the target & forcing the audio & captions to fit that.  As you can see from the Met content, that should not be something you strive for.

VLC plays the video with synchronous audio just fine & displays the srt captions correctly.  I've looked a bit more closely at those captions & there are several odd things in there.  They have a lot of repeated captions, and that's not just about how opera lyrics are often repeated.  If they want a caption to appear on the screen for, let's say, 6 seconds, they've got 4 consecutive captions covering 1.5 seconds each back to back.  That's not necessary.  You can just define one caption & give it a duration of 6 seconds.  They also have a lot of empty captions covering stretches of various durations.  This is totally unnecessary.  It just takes up space in the caption file while no caption displays in VLC.  Captions do not have to be defined for every single second of video.  The worst offense in this category is the 75 empty captions at the end of the file that cover the curtain calls & the end credits.  You don't see any captions displayed on the screen because those captions are all empty.  Such a waste on every level.

My conversion of the srt to vtt is a complete disaster, at least for VLC.  Almost every caption shows the string WEBVTT as the last line of the caption.  I suspect this has something to do with there being a lot of 3-line captions.  I mentioned upthread that over here, a standard for captions is 2 lines.  Two-line captions in my converted vtt do display correctly, but the rest of the captions are actually 4 lines long because this extraneous WEBVTT caption is being appended to the caption.  This appears to be something VLC is doing because those lines are most definitely not in the converted file.  The caption conversion application I use converted the srt to vtt without a problem.  The video player it uses internally is not VLC but MPV.  In that application, MPV displays the vtt captions correctly.  But I don't see a way to tell either the caption app or MPV how to play a separate audio track synchronously, like VLC does.  The app can use VLC but the developer recommended I use MPV for caption work because it offers better granularity in controlling the placement & duration of captions.  I quickly checked the VLC support forum to see if there might have been another report of problems with long captions but I didn't see anything.  Bottom line is I'm going to trash my attempt at converting this srt to vtt.  The srt captions as supplied by the Staatsoper work, despite the odd things I discovered, & I'm not going to waste any further time on this.

Meanwhile, tonight's Met Tosca came in without a hitch.  The captions blasted in quickly, as usual, in about 15 seconds.  The audio took 9 minutes, which is also about what I've been seeing with earlier operas.  The video took 1 hour & 43 minutes to download.  This opera video has a duration of 2:21:37.  The Staatsoper Italiana has a duration of 2:32:36, only 11 minutes longer.  But it took over 6 hours to download compared to under 2 hours for the other.  Why?  The Italiana is 1920x1080.  The Tosca is 1280x720.  The Italiana MP4 video file is 8.31G.  The Tosca file is 2.95G.  Just as a curiosity, the speed reported in the ffmpeg log for the Tosca audio was consistently about 17.2.  For the video, it was 1.36.  This sounds about right.  When I try to stream 1920x1080 content from other sites, it's impossible to watch.  The player buffers up a few seconds & then plays it.  But it exhausts the buffer long before the next buffer gets filled.  So playback for me at this high resolution goes like 3 seconds of viewing, 30 seconds waiting, 3 seconds of viewing, 30 seconds waiting, etc.  Better to just download & view offline.  But 1280x720 seems to be within the capacity of my bandwidth.  So it's not a huge surprise that the Met streams are likely to show speeds over 1 while the Staatsoper streams won't come close to that.

I downloaded tonight's Tosca successfully on the first try using ffmpeg.  The only parameter I supplied was -codec: copy, as I discussed upthread.  The -bsf:a parameter appears to be unnecessary, as I suspected.  I will have to encounter a problem that makes me suspect I should try -bsf:a before I add it.

Very strangely, the file properties on this Tosca video are empty.  It does not show duration, resolution, frame rate, nor the other things.  But the file plays fine in VLC, synchronously with the audio & with captions, right to the last second.  There's no error reported in the ffmpeg log & my script terminated normally.  The stream characteristics are reported in the ffmpeg log.  The VLC properties do appear to be missing some information, but this doesn't stop the file from playing properly.  I don't know what could have happened.  I guess coming days will reveal if this was a one-time glitch or if it's the first in a trend.

Geevee, dropping corrupt packets is most definitely not what I want to do.  I want to get the uncorrupted version.  Retrying is what I want, not dropping.  The first piece of doc you referred to is actually packaged up with the ffmpeg I installed so I have that locally on my hard drive.  The second URL you provided gives me a page not found.  But I do have a piece of documentation with the name ffmpeg-formats.  I also have something called ffmpeg-all, & the -fflags parameter is documented there.  If you'll pardon my exaggeration when I say, "documented."  Still, like I say, dropping corrupt packets is not what I want.  I had already searched through several of these doc HTMLs (they're in HTML format in this package) the other day for the string "corrupt" & got no joy.  I think, in addition to our not having encountered the relevant concepts, the documentation is intentionally impenetrable, as I ranted on about earlier.  As for your ballet, that sounds like a temporary problem.  I would try it again to see if you might hit a time when their servers might be less busy.  Plus you've got 3 days to get each of these things so there's never any rush, unlike the Met things, which are up for only 1 day.  Still, I'm mystified how you're getting into the free Staatsoper streams.  I can't find a way in.

[Wild Willy]

Brainstorm alert!  You've inspired me Geevee.  I've managed to have a brainstorm.  This caption thing was, of course, bugging me.  I have the two MP4 files for Italiana in a directory that includes both the original Staatsoper .srt file as well as my .vtt conversion of the .srt file.  When I tested the captions earlier, I explicitly told VLC to first use the srt captions, then the vtt captions then back & forth as I was trying to figure out what was going on.  Nothing made any sense.  Why would VLC show this WEBVTT caption when my .vtt file contained that exactly once, on the very first line, then not again, which is how a proper .vtt file is supposed to be?

But then I remembered something I had already commented on here upthread.  I said above that it looked weird that the .srt file contained a lot of lines that read WEBVTT.

Brainstorm.

Both caption files exist in the same directory.  Despite my explicitly choosing one or the other in VLC, maybe it wasn't working properly.  So I tested again, without telling VLC anything about captions.  But I changed the name of my .vtt file to .xtt, leaving the .srt file as is.  Poof.  The srt captions now show completely screwed up captions.  All those lines that I thought were weird now actually show up as captions in VLC, with many captions being 4 lines long.  And then there's the captions I thought were empty because they clearly should have been empty.  Turns out they're not empty.  The srt file causes them to display.

So I had it backwards.  The original .srt file from Staatsoper is actually the one that is a disaster.  My .vtt file that I originally thought was a disaster is in fact beautiful.  It corrects the errors in the .srt file.  I haven't bothered to coalesce the duplicate captions so a single caption just lasts longer.  I think my caption editing app might actually do that for me if I ask it but it's more an aesthetic & technical challenge at this point.  The .vtt works fine the way I have it, despite its inefficiencies.  I have renamed the original Staatsoper caption file to .xrt so VLC won't find it.

The bug appears to be in VLC.  If you've got more than one caption file that meets the criteria for VLC to find the file automatically, VLC finds them all & tries to display the captions from all the files simultaneously.  Actually, on further experimentation, it appears it's not quite that simple.  But I think you just need to be safe & make sure there's only 1 caption file in the directory where VLC will find it automatically.  Make sure any alternate caption files have names that VLC will skip over.

So.  Geevee.  Have you watched Italiana yet?  How do the captions look to you?  I haven't actually watched the whole thing yet myself, just sampled it enough to investigate this caption thing.  Do tell me what you see.

Also, tonight's Tosca captions appear to have a lot of those undisplayable characters that VLC shows as diamonds with question marks.  Anybody else seeing this?

[XaRaF]

I no longer have Staatsoper Italiana vtt on my hard drive but I found them really messy with WEBVTT lines added at the end of each timestamp in my copy, could have been an ffmpeg issue? Will see if tonight's show will have subtitles and how they'll be saved on the hard drive.

Don't see any problems with Tosca srt directly from met, what's the timestamps of those 'diamonds'? I'd check encoding in your subtitle file and settings in VLC, Tosca srt directly from met page has Windows 1252 encoding and I have the same in VLC settings and work's fine.

[Bruce R]

Yes, I had about 60 of those replacement characters in both my vtt & srt files for Tosca. I wonder what character is unable to be properly recognized? Does the correct character show up when the opera is played directly on the Met site or is the diamond with question mark displayed there too?

[Geevee]

Willy, try downloading vtt directly when you download subtitles. The Vienna original is vtt, so if you change the extension of the subtitle output file to vtt, you avoid the translation to srt and get the original vtt subtitles.

I used srt in my download because I was unfamiliar with vtt when I started.

PS I discovered just now that the Met also provides vtt subtitles. Just change the extension on the URL to vtt.

PPS attached the downloaded Vienna vtt file for your convenience. It has WEBVTT all over it also.

PPPS It seems I have an account at the Staatsoper. I've never paid them anything though. When I click on the account icon, it welcomes me back using my email name.

I go to staatsoperlive.com. I get a webpage that immediately flips to another one that has a button that says FREE. If I use a new browser (Microsoft Edge beta) I get the logon screen when I click on FREE.

[Geevee]

Bruce,

When I download the Met subtitles as srt, I get the diamond. When I download them as vtt, I get a dash.Example:

53
00:13:57,104 --> 00:14:02,676
–Why did you lock the door?
–The sacristan asked me to.

I guess srt is passé in operaworld.

[XaRaF]

Bizarre thing about Tosca - I downloaded subtitles from On Demand page (https://www.metopera.org/ondemand/imagelinks/subtitles/811357019337.srt) srt file is playing fine in any player I test and so is good when playing on the On Demand website. But when I play Tosca from the main page of the met (https://metoperafree.brightcove.services/?videoId=6150401683001) I get the diamonds on that 53 timestamp for example. I wonder if that is caused by brightcove player on that page changing stream and coding for the subtitles.

Definitely something dodgy that brightcove player is doing with the subtitles on the main met page. Just grabbed the vtt using the bat file and m3u8 manifest and the file is encoded in UTF-8 and the text editor is already unable to properly display the dash, tried checking if any other encoding will display it properly but scrolling through entire list was unable to find any that would work. I guess for subtitles I'd recommend sticking with the On Demand page as source.

[yogini]

Wow this worked great. Thank you! Try as I might I just don't understand all the technical FFMPEG discussion everyone is having, but this made sense and worked for me. And another kind soul is updating the dropbox account nightly with the latest *.srt subtitle files. Thanks to everyone.

[Wild Willy]

XaRaF: I just used Geevee's manifests to get Italiana.  I have not been able to get to their streams without going through their logon which requires a free trial signup & they'll ask for your credit card, so I haven't signed up, and I am unable to play their streams myself.  The manifests he offered included one that got a .srt caption file so that's all I've got.  But it sounds like the .vtt you found included the same damage as the .srt I got.  For the Tosca captions, I've already edited my copy of the .vtt & removed the undisplayable characters.  But most of them were on captions that included lines from 2 singers at the same time.  Here's a couple of examples:

00:11:38.465 --> 00:11:41.802
00:13:57.104 --> 00:14:00.000
00:16:14.341 --> 00:16:17.578

Oh.  Wait.  Let me get them again.  It takes only a couple of seconds.  OK.  Here's some examples that are not meant to be simply dashes at the start of a line:

34:53.327 --> 34:56.663
43:46.159 --> 43:53.033
55:28.428 --> 55:30.000

I've got Windows-1252 turned on in VLC.  Thing is, my caption editor also displays them as little diamonds with a question mark.  If your VLC doesn't display the weird character, open the caption file with Notepad (or equivalent) & find those captions.  Maybe the characters will show as something weird there.  When I open the captions in a text editor, the weird characters show up as a 3-character sequence: a lower case i with an umlaut, an upside down question mark, & the fraction 1/2 squashed into a single character.  For me, it's a simple matter of doing a find on the sequence & replacing it.  But since they don't all show up as the leading character on a line, you can't just do a global find/replace.  For the ones that start a line, you probably can, but not for the others.  You have to decide individually what to do with those.  I replaced one with an elipsis & another with a colon.  This is not a problem with every opera, only some.  Some of these captions have come with the dashes to start lines already coded as dashes.  It seems to be something that is chosen by whoever does the captions for any individual opera.

Bruce R: Thanks for commenting.  I'm glad I'm not the only one seeing this.  I just skipped to the first example I gave XaRaF above (at 11:38.465) & yes, it shows as a diamond with question mark in the online player.  That is, the online player you get directly off the main page.  The On Demand player displays the characters as dashes.  (It took me a while to get to it since those streams are chopped up & you can't just go directly to a given time index.  You have to add up the times of the segments, something I didn't realize until after I had started playing the stream.  This particular instance is at offset 58 seconds into segment 5.)

Geevee: Everybody seems to be getting something different.  I don't use the On Demand version so all I find is the .vtt captions & mine have the undisplayable character.  But the example you show is in srt format.  The tipoff is the sequence number at the start of the caption.  Are you sure you've got things the right way around?

XaRaF: Thank you for confirming what I see in the main free stream player.  I think the problem is not in the player since I get the same thing with VLC offline.  I think the problem is in the .vtt file.  I haven't downloaded the .srt file but Bruce has & he says the undisplayable characters were there as well.  But they appear to play fine online in the On Demand player.  I'm guessing that they code the captions initially in srt format to work with the On Demand player, then just convert them to .vtt for the other player, not realizing the On Demand player uses some sort of different technology from the regular player.  But when I click MB2 on the On Demand player, it gives a menu with 2 selections that are not active.  However, the second selection says "About Brightcove" so it seems the On Demand player is Brightcove, same as the main free stream page.  But I guess the On Demand player uses some other parameters that let it interpret the diamond/question mark characters.  I don't know.  I'm guessing.

Geevee: The fact that you have an account with Staatsoper explains things for me.  You are getting to things because of that that I can't.  You should keep an eye on your credit card to see if they start charging you when your 30-day free trial is up.  I would hope they give you some sort of warning that day when you try to logon.

[XaRaF]

WW - www.staatsoperlive.com doesn't require connecting payment with your account, I set up mine yesterday just by providing an e-mail account and a password. Account creation after clicking the 'Free' button on the staatsoperlive wen't through: https://www.culturall.com/ticket/ists/new_user.mc?process_mode=normal&new_user=1 When it comes to shows from there I'm using bat ffmpeg solution for vtt, it's messy again for tonight show, and VLC stream option to save both m3u8 manifests as one mp4 file; tonight's show took under 50min and ended up being 12.8GB.

As for Tosca - I have no errors with srt downloaded form the direct link using Met On Demand page and player and using DevTool network inspection to grab. VLC, Media Player Classic-BE or text editor shows 'dash' as it should be. Symbols of 'diamonds' were displayed if I grabbed Tosca vtt using ffmpeg and m3u8 manifest. How or why two players are having different subtitles is beyond me, I guess something to do with one player being more simplistic and not offering language change and the other having chapter sidebar. You can grab srt files from my dropbox folder I mentioned earlier (https://www.dropbox.com/sh/suill23esqril0b/AABl0yJ5xoCdRiXJmTZ1ryW9a?dl=0).

Vtt of tonight's shows grabbed with ffmpeg and m3u8 is without diamonds, used copy/paste for search from Tosca vtt, but I'm not saying the file is perfect as haven't scrolled through it completely. And it's encoded in Windows-1252 this time.

Bonus info for those interested: VDH is capable to grab ANY opera from back catalogue on Met On Demand page without you having to be logged on to your Met account. The player will be covered by paywall screen asking for starting 7-day free trial or rental option but VDH is seeing the streams and grabbing them without problems. Same goes for visibility of direct link to srt file if you have DevTools opened on Network tab, or you'll refresh the page with the player. This way lacks option to check what languages are available but having link for english srt you can shoot in dark adding two/three letters for other languages.

[Wild Willy]

Here's a little advanced math for you.  XaRaF=Genius!  (Remember, ! means factorial.)  There were 2 operas from the first week of this free streaming period that I missed but I really wanted: Il Trovatore & Carmen.  I am now downloading the Trovatore as we speak.  VDH is telling me it will be done in 2.5 hours.  I note that VDH is reporting this one as 9.4Mbps.  That is more than double the other streams we've been getting.  I'll be curious to see what file properties I get on this one.

I already got the .vtt captions using instructions upthread here.  Funny characters are in this .vtt.  But since I got them by simply supplying the URL in a Firefox tab, I think the funny characters all got translated to simple question marks when I did the copy/paste.  It was a simple task to find the captions that consisted of 2 lines from 2 singers: find on "linebreak?" as the search string in the text editor.  But embedded among the file were 2 instances of question marks that are not legitimately terminating questions.  They're at 00:06:14.308 --> 00:06:23.150 & 01:22:03.757 --> 01:22:08.529.  I replaced both of them with simple commas.  Amazing how many of the lyrics are questions in this one.

Carmen will be next.  Les Contes d'Hoffmann will have to wait.

As for Staatsoper, that's good to know.  I just assumed they would prompt for a credit card.  Most other deals like this do.  I may look into doing this myself now if there's something I care to get.  And 50 minutes for a file of 12.8G?  Not for me, sadly.  That sounds like a 12 hour download for me.  But I'm not complaining.  If it's something worth getting, I'd happily do it.

[XaRaF]

Thanks! ;) I

'll check the vtt tomorrow, just signing off for today in this timezone but quick heads up about the file size knowing your slow internet speed. Il Trovatore (2015) is 4.26GB and Carmen (2010) 4.46GB unless it was the Carmen (2019) then it'll be 4.61GB as a complete mp4 file with top quality from VDH.

See you chaps in the morning!

[Wild Willy]

Thanks, XaRaF.  4G is about a 2-hour download for me, maybe a little longer.  Short in comparison to the Staatsoper things.  The Carmen I want is the one from a few years ago with Elina Garanca & Roberto Alagna.  That was the first one on the Met site for free a couple of weeks ago.

[Geevee]

WOW. Thank you so much for sharing how to access the Met. I'm off to work on the back catalog.

[Wild Willy]

I got the .vtt for Carmen while Trovatore is still downloading.  This time, instead of doing copy/paste from the browser into the text editor, I just did a Save directly from the browser.  There don't appear to be any funny characters in this one.  There's just a handful of captions that contain lines from 2 singers & they show leading dashes correctly.  There's even a bunch of accented characters (Don José) but they're fine.  I've noticed funny characters for accented characters on other occasions.  There's no predicting when a caption file will have any of these funny characters.

[Wild Willy]

The video MP4 of tonight's Hoffmann came in fine & it plays fine, looks fine, everything fine.  But like Tosca the night before, the MP4 file properties on the details tab are empty.  No duration, resolution, etc.  So the absence of the file properties appears to be a side effect of ffmpeg.  Weird thing is the audio MP4 of tonight's Hoffmann, also downloaded via ffmpeg, has audio properties on the details tab of the file properties.  Very odd.  As an experiment, I ran VDH convert with a target file type of MP4 (4Mb).  I don't know what the 4Mb does but I thought it's higher than the other MP4 target types so let's see.  I didn't convert to a target type of MP4 + AAC because this is a video with no audio track.

The original without properties is size 3.50G.  The converted file is size 4.68G.  It does have video properties now:
Duration 2:49:56
Resolution 1280x720
Data rate 3944kbps
Total bit rate 3944kbps
Frame rate  29fps

The ffmpeg log says the audio stream is duration 02:49:57.10 & the video stream is duration 02:49:56.95.  I say that's pretty close to the same duration.  It is odd, though, that the converted file says 2:49:56.  Looks like that was a truncation instead of a rounding.

The bit rates in the converted file are actually rather high for our operas.  Most of the streams have come in just under 3,000 with a couple being around 3,500.  So this is really high.  According to the ffmpeg log, the original has a bit rate of just under 3,000.  This is something that is reported in the log for every single frame, of which there are apparently 305,603.  Well, not every frame, but it looks like most frames are logged.  So I'm wondering why the bit rates are so much higher in the converted file.  I don't believe the number.  The source isn't that high so converting it can't invent quality that isn't there in the source.

The frame rate is another number that is truncated.  The actual speed is just a hair under 30fps.  All videos are like this.  The audio section of the details tab is, of course, empty.

Playing the original video MP4 in VLC back to back with the converted one shows no video quality difference I can discern.  This is what I expected.  Both video files synch up just fine with the audio MP4, & the captions look fine.  But after running a conversion for about half an hour during which my CPU usage bounced around between about 50% & 70%, I can't tell what I gained that takes up an extra 1.18G.  I can't believe a few file properties occupy that much space.  This experiment tells me it's not worth doing.  I am more interested in the fact that the opera plays correctly & looks good.  So the video MP4 has no file properties showing the usual information.  I can live with that.

[XaRaF]

WW - took me a moment but figured it out, I was talking about vtt for tonight's Hoffman and you gave timestamps for Il Trovatore ;) No issues there in srt file from On Demand page. Copy/paste to text editor rather than Save as? How barbaric ;) I know you prefer vtt but I'd suggest grabbing srt from On Demand since they come without encoding errors so far and simply converting (for example with https://gotranscript.com/subtitle-converter) Either way it's still a text file with different format for timestamp (comma instead of period) and vtt's html5 coding is not present in operas subtitles apart from rare <italics> which srt interprets fine. But that just my take on it.

Can't help with differences from ffmpeg results to what VDH is grabbing as a complete mp4. Bitrate is bit high tho not much than some 1080p in x264 compression. Have you checked the staatsoperlive files? I'm seeing twice as much which gives me idea that whoever was tasked with preparing the streams is either doing overkill in one department and messing others ie vtt files. On top of that: what's your audio track numbers from staatsoperlive? I'm seeing 93kbps tho stereo and 48.000 kHz sampling. So it's all over the place.

No problems here with missing file properties in Details tab but I keep using VDH, it happened whit staatsoperlive files but after a while when checked again it was there so I put it down to the system inspecting the files and taking sweet time with it.

On a different subject, came across this info: https://www.cordcuttersnews.com/new-free-broadway-on-demand-streaming-service-is-launching-next-month something to look forward to tho I'm not familiar at all with what BroadwayHD is offering but never enough of culture and entertainment ;) And we would have quite a range covered with Met and Vienna operas with some ballet plus there's weekly free stream from London National Theatre if one want's stage plays https://www.youtube.com/user/ntdiscovertheatre

[Wild Willy]

I have only Italiana from Staatsoper.  The audio MP4 properties show length (duration) 2:32:36, 128kbps, 48kHz. 2-channel.  The video MP4 properties show kength (duration) 2:32:36, resolution 1920x1080, data rate 7794kbps, total bit rate 7794kbps, frame rate 25fps.  These are 2 separate files.  I'm not sure we can directly compare the bit rates on the Staatsoper videos to the bit rates on the Met videos.  The Staatsoper video I have is 1920x1080.  All the Met videos so far are 1280x720.  1920x1080 content I've seen from other sites usually has bit rates in the 6,000 to 7,000 range, occasionally up to 10,000, but that's for video+audio files, whereas the Met video files I have are all video only.  So again, that's probably not comparable.

When I first started using ffmpeg to download operas, I had no parameters on ffmpeg.  When I added -codec: copy, this lowered ffmpeg's CPU usage to near 0 during the downloads but the video files started not having properties, while the audio files continue to have properties.  Odd thing about that.  In the audio files, there are properties on the details tab that I can edit & put in whatever I want.  Things like Title, Subtitle, Tags, Comments, etc.  In these video files with no duration, resolution, etc. showing, I can't edit those same items.  It's like the properties section of the file is write protected.  Or maybe it isn't even there.  In the video files I got with ffmpeg when I supplied no parameters, I can edit those properties.  This probably agrees with the result I got doing that one conversion I tried.  Whatever ffmpeg does when I don't tell it -codec: copy is probably the same thing I got when I told VDH to do a conversion.  I would suspect that VDH is just calling ffmpeg for that function.  So there's something about transcoding that generates a file with more properties than one that isn't transcoded.

But like I say, the absence of the properties appears to have no effect on the quality of the video image that VLC plays, plus the file is significantly smaller.  So I can live without those things.

[Wild Willy]

This message is targeted at Michel.

It's been quiet here for a few days.  Time to make some noise.  This business of the file properties is bugging me.  I've attached an image showing the properties from 3 files.  The one for the video of La Fille du Régiment I downloaded with VDH.  As you can see, there are video properties included.  Also, when I hover the mouse over the Tags property, it hovers up a field into which I could type something if I wanted.  There's other properties on this tab that would also take typed input if I so chose.  Compare this to the properties of the video of Anna Bolena.  This is one I downloaded with ffmpeg directly.  As I explained above, my ffmpeg invocation looks like this:

ffmpeg parms1 -i URLofManifest parms2 target.mp4

Plus some redirects to capture the ffmpeg logging in a file.  In addition, when I hover the mouse over Tags (or any of the other possible user modifiable fields), the text entry box does not appear.  It's as if the file isn't simply missing resolution, bit rates, frame rate.  It's as if it doesn't have any properties at all.

Then there's the properties of the audio file of Anna Bolena.  I downloaded it with ffmpeg directly as well, using the same basic ffmpeg invocation.  It's got audio properties.  It would also permit me to enter values in the various other fields.

So I have a question for you, Michel.  Why is this?  What is the CoApp telling ffmpeg to do that gets it to create video properties?  In case it's relevant, what I'm showing above for parms1 is:

-protocol_whitelist file,crypto,data,https,tls,tcp

This is something I stumbled upon in offering advice to somebody in another thread.  For parms2 I've got this:

-codec: copy

And I emphasize again, these are the parameters I have for both the audio download & the video download.  So it's completely baffling to me that one has properties & the other doesn't.

I have Googled this issue but all I find is discussions of how to write title, rating, comments, etc.  Those properties are of utterly no interest to me.  I want the video properties to show at least the resolution.  I see in the ffmpeg log that it knows the resolution, the bit rate, the frame rate.  The file plays fine in VLC so it's finding that information in the file.  Why isn't ffmpeg putting it in the properties?  What are you doing in VDH to get that to happen?

I've also tried looking in the ffmpeg documentation.  I won't repeat everything I said above about that.  I'll just say that their documentation is utterly incomprehensible to me.

You might say well then just use VDH.  No.  Not happening.  VDH does not support captions.  VDH also does not clearly identify the streams that are video without audio & audio without video.  VDH also does not indicate which audio streams go with which video streams.  As I detailed above, all of this information, ALL OF IT, including the manifest for the captions, is described in the master manifest for the nightly free opera download.  Maybe other sites don't have all of these things in their manifests but the Met does.  Therefore VDH should be using this information & making it easy for us to get access to it.  Until VDH can do all these things, I'll be using ffmpeg to get these operas.  As soon as you put these features into VDH, I'll go back to using VDH.  In the meantime, I'm asking for a hint on how to get the properties on the videos.

[Geevee]

Willy,

I think you should try the -map_metadata flag. Here's the example in the ffmpeg documentation:

"For example to copy metadata from the first stream of the input file to global metadata of the output file:

ffmpeg -i in.ogg -map_metadata 0:s:0 out.mp3

"

[Geevee]

OKWilly,  since you have that slow connection, I thought I'd try a test. I downloaded the Met Anna Bolena three ways, using this ffmpeg command:

"E:\ffmpeg-4.2.2-win64-static\bin\ffmpeg.exe" -i https://manifest.prod.boltdns.net/etcetera  -vcodec copy -acodec copy -bsf:a aac_adtstoasc -timeout 500 "e:\test\rendition2.mp4"

varying the m3u8 files and the output file name. I got the m3u8s from the inspector in Firefox (master, rendition, rendition)

Downloading using the master m3u8, I got a merged video+audio file.

Downloading the first rendition m3u8, I got just video.

Downloading the second rendition m3u8, I got the audio.

The third rendition m3u8 is the english subtitles, so irrelevant.

I cannot duplicate your results. Attached are the properties for the three downloaded mp4s.

EDIT: and then I downloaded the Maria Stuarda video with your version of the -c copy parameter and still got properties in the details tab.

[Wild Willy]

Geevee, you are once again an inspiration.  I didn't do tonight's Maria Stuarda properly so I have no video properties on the file.  I've looked at the documentation for -map_metadata several times over the past few days, even before you mentioned it.  I don't know what's special about tonight.  Maybe the fact that you suggested it made me concentrate harder.  Maybe I'm just fresher tonight.  Maybe I've read that section so many times it's finally starting to make sense to me.  Which should have you praying for me.  In any case, I think I see how that might help.  I'll try it properly tomorrow night.

Meanwhile, I had the thought of trying to experiment with something small.  (Thanks for your experiment, by the way.)  See, these are single-stream mp4 files.  The audio-only files get their properties no problem.  The video-only files don't, at least, not for me.  So I wondered what would happen on a combined audio+video stream.  Where can I find short videos?  Pornhub, of course.  So I picked a stream at random because it was under 1 minute long & downloaded it.  I tried with no -map_metadata parameter & the file got full video & audio properties.  It had the curious resolution of 2584x1080 so even in full screen, VLC played it in letterbox format.  Maybe that was the point.  I then added -map_metadata, trying several different values with it on multiple tests, & the file came in with full properties every time.  Makes me think -map_metadata is not really a necessary parameter.

I note that in the ffmpeg log, I'm seeing this under information for output files:

Metadata:
  encoder         : Lavf58.42.100

This is for the audio-only streams, the video-only streams, & even for the caption streams.  Maybe this is relevant.  Here's what I'm seeing in the ffmpeg log following the first 2 stream segments of tonight's video stream:

Input #0, hls, from 'https://manifest.prod.boltdns.net/manifest/v1/hls/v4/clear/102076671001/021896c7-8708-4df4-99ac-98374834ee98/7dcff148-cf1a-40bd-8083-7974dfea72c1/10s/rendition.m3u8?fastly_token=NWVhOTMwMWFfMDBmMjU2NzVjZTI0ZGNlZTIwMjk1NjBiMjQ1Y2I5OGY2NzUyNjAyMDdlZWJjOThlNWRhMzk0ODZkZDBlZGVhYQDD':
  Duration: 02:41:01.22, start: 0.066733, bitrate: 0 kb/s
  Program 0
    Metadata:
      variant_bitrate : 0
    Stream #0:0: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Metadata:
      variant_bitrate : 0
Output #0, mp4, to 'Q:\Opera\Maria Stuarda Video 20130119.mp4':
  Metadata:
    encoder         : Lavf58.42.100
    Stream #0:0: Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
    Metadata:
      variant_bitrate : 0
Stream mapping:
  Stream #0:0 -> #0:0 (copy)

This is what I see on every opera.  It's also a lot like what I see with the audio streams every night, except that section reports things relevant to an audio file.  So it seems that ffmpeg is certainly aware of the resolution & frame rate at least.  I don't understand a lot of the other things I see here but I do recognize those 2 things.  I don't know why it's not writing those things into the properties for the video output file.

So I'm beginning to think I'm seeing something unique here.  It could be related to Windows 7 but I think that's unlikely.  It's more likely, although still pretty unlikely, that there's something weird going on with my system.  I still come back to the fact that the audio only streams are getting audio file properties, and audio+video streams get both video & audio file properties.  They're all mp4 files.  I do give them all .mp4 as their file extension.  What could possibly be preventing video-only mp4 files from getting full file properties?

[Geevee]

Willy, looking at my Stuarda download, the only difference I see is in the metadata encoder:

  Metadata:
    encoder         : Lavf58.29.100

Here's my command again:

E:\test>"E:\ffmpeg-4.2.2-win64-static\bin\ffmpeg.exe" -i https://manifest.prod.boltdns.net/manifest/v1/hls/v4/clear/102076671001/021896c7-8708-4df4-99ac-98374834ee98/7dcff148-cf1a-40bd-8083-7974dfea72c1/10s/rendition.m3u8?fastly_token=NWVhOTU1ZWFfNmYyNDVlZjEyNGMwOWYyNWJmYmJmMDAyODcwMzI4Y2RiMGViMjZiMzlkYTU3YjI0OWY4NzYwMjVhOGUwMmQ2NgDD  -c copy  "e:\test\willystuarda.mp4"

Here are the version numbers of ffmpeg's libraries:

  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100

and here's ffmpeg's gonna-do documentation complete:

[hls @ 0000025dd5aa9000] Skip ('#EXT-X-VERSION:3')
[hls @ 0000025dd5aa9000] Opening 'https://house-fastly-signed-us-east-1-prod.brightcovecdn.com/media/v1/hls/v4/clear/102076671001/021896c7-8708-4df4-99ac-98374834ee98/7dcff148-cf1a-40bd-8083-7974dfea72c1/5x/segment0.ts?fastly_token=NWVhOTU1YTNfNWVjNWUxMTYwYmY5YzZmZTQ4NTIyMmQxNjI5NjRkZDRkYjg4MjIwZDdjMWZlZTQ1MjI3Y2Q0ZTE0M2EwYmIwYV8vL2hvdXNlLWZhc3RseS1zaWduZWQtdXMtZWFzdC0xLXByb2QuYnJpZ2h0Y292ZWNkbi5jb20vbWVkaWEvdjEvaGxzL3Y0L2NsZWFyLzEwMjA3NjY3MTAwMS8wMjE4OTZjNy04NzA4LTRkZjQtOTlhYy05ODM3NDgzNGVlOTgvN2RjZmYxNDgtY2YxYS00MGJkLTgwODMtNzk3NGRmZWE3MmMxLw%3D%3D' for reading
[hls @ 0000025dd5aa9000] Opening 'https://house-fastly-signed-us-east-1-prod.brightcovecdn.com/media/v1/hls/v4/clear/102076671001/021896c7-8708-4df4-99ac-98374834ee98/7dcff148-cf1a-40bd-8083-7974dfea72c1/5x/segment1.ts?fastly_token=NWVhOTU1YTNfNWVjNWUxMTYwYmY5YzZmZTQ4NTIyMmQxNjI5NjRkZDRkYjg4MjIwZDdjMWZlZTQ1MjI3Y2Q0ZTE0M2EwYmIwYV8vL2hvdXNlLWZhc3RseS1zaWduZWQtdXMtZWFzdC0xLXByb2QuYnJpZ2h0Y292ZWNkbi5jb20vbWVkaWEvdjEvaGxzL3Y0L2NsZWFyLzEwMjA3NjY3MTAwMS8wMjE4OTZjNy04NzA4LTRkZjQtOTlhYy05ODM3NDgzNGVlOTgvN2RjZmYxNDgtY2YxYS00MGJkLTgwODMtNzk3NGRmZWE3MmMxLw%3D%3D' for reading
Input #0, hls, from 'https://manifest.prod.boltdns.net/manifest/v1/hls/v4/clear/102076671001/021896c7-8708-4df4-99ac-98374834ee98/7dcff148-cf1a-40bd-8083-7974dfea72c1/10s/rendition.m3u8?fastly_token=NWVhOTU1ZWFfNmYyNDVlZjEyNGMwOWYyNWJmYmJmMDAyODcwMzI4Y2RiMGViMjZiMzlkYTU3YjI0OWY4NzYwMjVhOGUwMmQ2NgDD':

  Duration: 02:41:01.22, start: 0.066733, bitrate: 0 kb/s
  Program 0
    Metadata:
      variant_bitrate : 0
    Stream #0:0: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Metadata:
      variant_bitrate : 0

Output #0, mp4, to 'e:\test\willystuarda.mp4':
  Metadata:
    encoder         : Lavf58.29.100

    Stream #0:0: Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
    Metadata:
      variant_bitrate : 0
Stream mapping:
  Stream #0:0 -> #0:0 (copy)

Press [q] to stop, [?] for help

I'm running windows 10 64bit. I suppose it's possible that the OS or the OS-specific ffmpeg act differently.

For me, this is wholly theoretical. I've come to realize that the combined mp4 exposed on the on-demand pages must be the source for the daily brightcove encoding, so I  get one step closer to the original when I download from there. As Erch pointed out upthread, the entire catalog is available for download via this method, not just today's streaming offering. Just scroll down on the page to get all the offerings. When the nag screen appears. the Met has already sent the m3u8 for the mp4, and VDH has grabbed it. So you can ignore the nag and download via VDH. Then use Erch's UPC code trick to get the subtitles.

So I've been ignoring the daily stream and just downloading what I like from the season catalog.

[RichardLUX]

Thank you very much! I just tried concatenating vtt files with ffmpeg and it worked like charm, and the video i am downloading separately with another ffmpeg process.
Roberto Devereux was not on the drive list that was posted before, therefore I had to crack it.
What I did not get, that someone could see srt file in network tab, but in this free screening I have not noticed any of them.
So, anyway, I am so excited that it worked! Just a pity I missed so many operas, especially Wagner, when I could save just video, not sound, and did not explore the problem in timely manner. Well, lesson learnt!
P.S. I use "Subtitle edit" to (auto)translate/correct the subtitles. Highly recommend, if there are no other languages available.

Thanks again!