Some mp3 audio streams are not recognized

146 views
Skip to first unread message

Radovan Markes

unread,
Dec 30, 2021, 6:20:09 AM12/30/21
to Video DownloadHelper Q&A

Wild Willy

unread,
Dec 30, 2021, 11:59:00 PM12/30/21
to Video DownloadHelper Q&A
This is a very weird case.  When you first visit your first page, video #2 is selected.  I didn't play it.  I started by playing #1.  Then . . .

#01.png
#02.png
#03.png

Now you want to run ffprobe.  This is part of ffmpeg.  Go look over here:

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

You will find instructions there on how to get ffmpeg, which will get you ffprobe at the same time.  You would also do well to read that whole thread.  It shows details I am not going to go into here.  Especially look for the discussion of DASH.

Once you have ffprobe, you will want to execute this command:

ffprobe "https://croaod.cz/stream/3297a0c6-0046-49a3-bcd3-56bc554a5e61.m4a/manifest.mpd"

The URL in that command is what you will paste out of the system clipboard.  This happens to be the URL I got when I visited the site.  You might get a URL that is a bit different.  I don't know.  It's just important that you follow these instructions exactly.  You will get a URL.  That's the only important thing.  Create an ffprobe command by pasting the URL you copied from the Network Monitor, as I show in the images above.  Executing this ffprobe command will generate this output:

_____________________________________________________________________________________

Input #0, dash, from 'https://croaod.cz/stream/3297a0c6-0046-49a3-bcd3-56bc554a5e61.m4a/manifest.mpd':
  Metadata:
    Title           : 32/61/3297a0c6-0046-49a3-bcd3-56bc554a5e61.m4a
  Duration: 00:13:03.00, start: 0.000000, bitrate: 0 kb/s
  Program 0
  Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 194 kb/s (default)
    Metadata:
      variant_bitrate : 194207
      id              : p0aa0br194207

_____________________________________________________________________________________

There's actually more output above this part but you can ignore that.  This is the important part.  The line that starts "Input #0" shows that this is a DASH stream.  It also shows the URL of the .mpd file.  A couple of lines below that, you see the duration is 13:03.  This proves this is information about video #2.  Then a couple of lines below that, notice that this file is an MP4, not an MP3.  Video #1 is an MP3.  Video #2 is an MP4.  Actually, it's MP4a, but that's basically the same thing.  That's weird, but that's what's on the web site.  VDH can't do anything about that.  Normally, VDH can download MP4 files but this web site is not presenting it in a normal way.  So VDH doesn't see it.  The appearance of a .mpd file in the Network Monitor means Video #2 is a DASH stream.  For some reason, VDH is not recognizing this.  Video #1 is not a DASH stream but video #2 is.  Why did the web site do this?  You should ask their webmaster.  It is very inconsistent of them to have done this.  But this is what they have done.  This appears to be confusing VDH.

This is what ffprobe has determined for us so far.  Video #2 is a DASH stream.  It has just one component (the one labeled Stream #0:0 above), it is in MP4 format, & it is audio only.

Now that you have ffmpeg, you can download this video.  Execute this command:

ffmpeg -i "https://croaod.cz/stream/3297a0c6-0046-49a3-bcd3-56bc554a5e61.m4a/manifest.mpd" "name a file on your system here.mp4"

I don't know how your files are arranged so you're going to have to supply the name of a file on your system.  On my system, I did it like this:

ffmpeg -i "https://croaod.cz/stream/3297a0c6-0046-49a3-bcd3-56bc554a5e61.m4a/manifest.mpd" "Q:\VDH Testing\Video #2.mp4"

This should give you output that looks like this:

_____________________________________________________________________________________

Input #0, dash, from 'https://croaod.cz/stream/3297a0c6-0046-49a3-bcd3-56bc554a5e61.m4a/manifest.mpd':
  Metadata:
    Title           : 32/61/3297a0c6-0046-49a3-bcd3-56bc554a5e61.m4a
  Duration: 00:13:03.00, start: 0.000000, bitrate: 0 kb/s
  Program 0
  Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 194 kb/s (default)
    Metadata:
      variant_bitrate : 194207
      id              : p0aa0br194207
Stream mapping:
  Stream #0:0 -> #0:0 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mp4, to 'Q:\VDH Testing\Video #2.mp4':
  Metadata:
    Title           : 32/61/3297a0c6-0046-49a3-bcd3-56bc554a5e61.m4a
    encoder         : Lavf59.4.100
  Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
    Metadata:
      variant_bitrate : 194207
      id              : p0aa0br194207
      encoder         : Lavc59.3.101 aac
size=   12778kB time=00:13:03.38 bitrate= 133.6kbits/s speed=6.94x
video:0kB audio:12442kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.698636%
[aac @ 00000000047b1740] Qavg: 698.440

_____________________________________________________________________________________

There's more output that appears before this but you can ignore it.  This is the important part.  Here you can see the results of the download.

#04.png

It plays fine in VLC.  At least, I assume it plays fine.  I don't understand the language being spoken.

You can take the same approach for video #3 on this web page.  You can take the same approach for the videos that give you problems on your other web page.

On sites that offer HLS objects, you'll often find manifest files, files whose extension is .m3u8.  It appears that on sites that offer DASH objects, they have .mpd files instead of manifests.  It appears to me that .m3u8 and .mpd files perform the same functions.  It's handy that ffmpeg handles them both quite nicely.

To sum up, the web site presents its content in 2 very different ways & that's weird.  This seems to be causing problems for VDH.  Is this a bug?  That's a question for Michel.  For the time being, I'm giving you a fairly easy way to get your videos.  This may just be a workaround until Michel comes up with a solution.

mig

unread,
Dec 31, 2021, 12:27:28 PM12/31/21
to Video DownloadHelper Q&A
Wild Willy  is, again, very right. In this sample page, https://vltava.rozhlas.cz/josef-svatek-povesti-z-doby-karla-iv-vypraveni-zurnalisty-a-spisovatele-z-jeho-8642145#dil=2?player=on%23player , we would have expected the 3 audio media to be implemented the same way, but the site creator decided otherwise: first link is a direct mp3 document, the other 2 are streamed using the DASH protocol.

DASH uses a mechanism similar to HLS (another streaming protocol much more common on the Web) where a manifest document describes the audio/video chunks that constitute the media (here the song). The thing is that DASH manifests can exist in 2 formats JSON and XML. VDH supports JSON DASH manifests, but for XML manifests, it only supports them in the case of YouTube media.

There is no good technical reason for that, it's only that we never encountered, before now, that situation. So, no use case, no code.

The use case you provided has been recorded and at some point, we will make the necessary modifications in the VDH code to handle that case. However, since this use of a streaming protocol is quite seldom, this won't be a priority in the development.

Many thanks for reporting the issue and to Willy for providing a workaround.

Radovan Markes

unread,
Jan 2, 2022, 7:07:57 AM1/2/22
to Video DownloadHelper Q&A
Many thanks for the explanation and for the detailed instructions on how to work around this.
It works!

I look forward to the new version of VDH with XML manifests support ;)

The links I provided as an example are only temporary. Here is a link that might be permanent: https://vltava.rozhlas.cz/radio-dada-s-vladivojnou-la-chia-8588857

Thanks again!
Radovan
Dne pátek 31. prosince 2021 v 18:27:28 UTC+1 uživatel mig napsal:
Reply all
Reply to author
Forward
0 new messages