Re: Support for ertflix.gr

493 views
Skip to first unread message
Message has been deleted

Wild Willy

unread,
Jan 28, 2022, 11:25:30 PM1/28/22
to Video Download Helper Google Group
I can confirm this. However, there is another way you can download content from this
site. Have a look over here:

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

Look for the reference to an alternative technique that might work when VDH fails to
download content from a given site. I tried that technique on your site & was successful
in downloading the video that appears at the top of the page whose URL you gave. It
turns out this site offers its content in DASH format in a way that VDH does not
recognize. So depending on how desperate you are & on how confident you are in your
technical abilities, you can download content from this site using the alternative
technique. Confident. You have to be confident. Don't tell me you're not technical.
Everybody here was technical enough to get a computer. Everybody here was technical
enough to install a web browser. Everybody here was technical enough to install VDH.
Everybody here was technical enough to figure out how to post in this forum. That means
you are technical enough to read instructions & follow them. So if you really want to
download content from this Greek site, you will read the instructions, follow them, and
succeed in downloading content from ertflix.gr.

The video at the top of the page you gave appears to be named BOTANA. The title (I
assume it's the title) below the video says, "Βότανα καρποί της γης." Since I don't
speak Greek, I put that into Google Translate & found out that it means, "Herbs fruits of
the earth." My download speed was a little over 1 million bytes per second. That's
about twice as good as YouTube at its best but not overwhelmingly fast. It took about 20
minutes to get this video which was of size 951M & duration 30:45. When I looked at the
DASH manifest, I saw that there were 5 video tracks available for this item at various
resolutions, the highest being 1920x1080. There were 2 of 1920x1080 with different bit
rates. I chose the higher bit rate. There were also 5 audio tracks available, an
unusually wide selection. These all had sampling rates of 48kHz but they had a range of
bit rates. Once again, I chose the one with the highest bit rate.

Even without the help of Google Translate, I think I would have figured out that this
video had something to do with botanical subjects. The video picture was of quite good
quality & the audio track was very good stereo, something that was apparent only when
music was playing, which was not all that much, but did include "Roundabout" by Yes over
the closing credits. It seemed to me like the audio & video were well in synch. If I
actually spoke the language, I could be more confident about that, but it didn't seem
like I needed to use the VLC controls for synching audio with video. The sound of the
voices seemed to match the lips moving. I didn't actually watch it all the way through,
just skipped through it, sampling it at intervals. It appeared to be all there & there
were no problems playing it in VLC.

I am running Windows 7 64-bit, Firefox 96.0.3 64-bit, licensed VDH 7.6.3a1 beta, CoApp
1.6.3, ffmpeg from ffmpeg.org dated 2021/7/11.
Message has been deleted

Wild Willy

unread,
Jan 29, 2022, 8:01:06 PM1/29/22
to Video Download Helper Google Group
Yes, that's the right thread. I would recommend you read the whole thread all the way to
the bottom, clicking out to the other threads mentioned there as well. Do all your
reading before you try to do what's described there. You use ffmpeg to do the download.
VLC plays no part in the download. It's just the video player you would use after the
download completes. There would be no small pieces that would need to be assembled into
a larger whole. You just let ffmpeg do all the work for you.

None of this changes the fact that VDH is unable to get this content. Michel has posted
on here that DASH streams come in 2 flavors. He says VDH can process the flavor that
does not appear on ertflix. He said the flavor that does appear on ertflix is not all
that common. I'm coming to the conclusion that it's a lot more prevalent than he
believes. The more reports we get on here of DASH streams with .mpd manifests, the more
likely it is he will add the necessary support to VDH sooner than he's anticipating at
the moment. You can find Michel's comment over here (under his usual ID of mig):

https://groups.google.com/g/video-downloadhelper-q-and-a/c/yj0X6iZxBVo
Message has been deleted

Wild Willy

unread,
Feb 12, 2022, 9:12:34 PM2/12/22
to Video Download Helper Google Group

Excellent news! Thank you for going to the trouble of reporting your experience. I'm
very pleased you are able to use my technique to get your content. However, unless your
results differ from mine, you did not get the highest quality result. I ran ffprobe on
the DASH manifest you supplied. I did this BEFORE I ran ffmpeg to do any downloading.
Here is what I got:

___________________________________________________________________________________
Input #0, dash, from
'https://mediaserve.ert.gr/bpk-vod/vodext/default/mousiko-kouti-mitsotakhs/mousiko-kouti-mitsotakhs/index.mpd':
Duration: 01:48:37.00, start: 0.000000, bitrate: 0 kb/s
Program 0
Stream #0:0: Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc, bt709), 640x360 [SAR
1:1 DAR 16:9], 527 kb/s, 600 fps, 25 tbr, 600 tbn (default)
Metadata:
variant_bitrate : 499952
id : video=499952
Stream #0:1: Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc, bt709), 768x432 [SAR
1:1 DAR 16:9], 1055 kb/s, 600 fps, 25 tbr, 600 tbn (default)
Metadata:
variant_bitrate : 1000100
id : video=1000100
Stream #0:2: Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1280x720 [SAR
1:1 DAR 16:9], 2099 kb/s, 600 fps, 25 tbr, 600 tbn (default)
Metadata:
variant_bitrate : 2000194
id : video=2000194
Stream #0:3: Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1920x1080
[SAR 1:1 DAR 16:9], 3201 kb/s, 600 fps, 25 tbr, 600 tbn (default)
Metadata:
variant_bitrate : 3000383
id : video=3000383
Stream #0:4: Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1920x1080
[SAR 1:1 DAR 16:9], 4207 kb/s, 600 fps, 25 tbr, 600 tbn (default)
Metadata:
variant_bitrate : 4000626
id : video=4000626
Stream #0:5: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s
(default)
Metadata:
variant_bitrate : 96000
id : audio=96000
Stream #0:6: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
(default)
Metadata:
variant_bitrate : 128000
id : audio=128000
Stream #0:7: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 192 kb/s
(default)
Metadata:
variant_bitrate : 192000
id : audio=192000
Stream #0:8: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 255 kb/s
(default)
Metadata:
variant_bitrate : 256000
id : audio=256000
Stream #0:9: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 319 kb/s
(default)
Metadata:
variant_bitrate : 320000
id : audio=320000
___________________________________________________________________________________

There are 2 streams here of 1920x1080 resolution: #0:3, #0:4. Stream #0:3 shows a bit
rate of 3201 kb/s. Stream #0:4 shows a bit rate of 4207 kb/s. This means stream #0:4 is
the higher quality one. All the video streams show 600 fps as their frame rate, which I
question, and which did turn out to be untrue, which is a bit of a mystery to me. So
much for the video streams. For the audio, clearly stream #0:9 is the best one at 319
kb/s.

When I simply gave the whole manifest to ffmpeg the way you did, it told me it did this:

___________________________________________________________________________________
Stream mapping:
Stream #0:3 -> #0:0 (copy)
Stream #0:5 -> #0:1 (copy)
___________________________________________________________________________________

In other words, it did not automatically choose the highest quality items on offer. It
did choose the highest resolution, but it chose the first of the 2 instances of that
highest resolution. The second one was better. For the audio, it just chose the first
audio stream on offer without looking at the various qualities. The file I got by doing
it your way looked like this to ffprobe:

___________________________________________________________________________________
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Q:\VDH Testing\Greek Test #1.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf59.4.100
Duration: 01:48:37.24, start: 0.000000, bitrate: 3101 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709),
1920x1080 [SAR 1:1 DAR 16:9], 3000 kb/s, 25 fps, 25 tbr, 19200 tbn (default)
Metadata:
handler_name : VideoHandler
vendor_id : [0][0][0][0]
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s
(default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
___________________________________________________________________________________

Note the correction to 25 fps, not 600 fps. That's just weird. I can't explain that.
At least the result is playable. Another thing I can't explain is how the bit rate shown
when I ffprobe the manifest does not match the bit rate shown when I ffprobe the result.
They're kind of close but not exactly the same.

You needed to do it like this:

ffmpeg -i
"https://mediaserve.ert.gr/bpk-vod/vodext/default/mousiko-kouti-mitsotakhs/mousiko-kouti-mitsotakhs/index.mpd"
-map 0:4 -map 0:9 -c copy mousiko-kouti-mitsotakhs.mp4

Doing it like this gave me this result:

___________________________________________________________________________________

Stream mapping:
Stream #0:4 -> #0:0 (copy)
Stream #0:9 -> #0:1 (copy)


Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Q:\VDH Testing\Greek Test #2.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf59.4.100
Duration: 01:48:37.24, start: 0.000000, bitrate: 4326 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709),
1920x1080 [SAR 1:1 DAR 16:9], 4000 kb/s, 25 fps, 25 tbr, 19200 tbn (default)
Metadata:
handler_name : VideoHandler
vendor_id : [0][0][0][0]
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 319 kb/s
(default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
___________________________________________________________________________________

The first file was 2.35G & the second 3.28G. It is no surprise that the second one is
bigger, although both are the exact same duration. I've attached the 2 Properties
windows for the 2 files for you to compare.

You always need to look at the ffprobe output beforehand & select the streams yourself.
The default choices made by ffmpeg will certainly work, but they are clearly not always
the optimal choices. In your case, the focus here is on a music performance. You
definitely want the best quality audio they're offering. I might have been better able
to hear a significant difference in the quality of audio if this were, let's say, a
symphony preformance, which generally would have a wider dynamic range than a pop music
performance like this one. I have to admit the audio sounded OK in both files. I was
able to see a small difference in the quality of the video between the 2 files. I had to
work hard to find any difference. I finally did notice a difference in the sharpness of
the image when I looked closely at the bare arms of the female singer. It was slight but
noticeable. You might consider redoing your download. My 2 downloads took 13 minutes
each. For some reason, I was getting a slightly higher download speed on the second one.
Another mystery.
Properties.jpg
Reply all
Reply to author
Forward
0 new messages