[Feature Request] Optimization of Youtube Audio about eternaljukebox HOT 3 CLOSED

Hi, thanks for the suggestion!
I modified the code so that such a substitution is possible, however I was unable to notice any significant difference. The file sizes were virtually identical, and both formats used very similar CPU percentages, in some cases MP3s were actually less strenuous.

Unless there's more to it than changing mp3 to m4a, I'm not sure if this works as well as you might think.
None the less, I've made the appropriate changes in the source code for you to try it out and see, and I'd be interested to hear if you're able to drop the usage!

from eternaljukebox.

tl;dr you need the -f m4a flag whether doing mp3 or m4a
try changing in yt.sh
'youtube-dl $1 --audio-format $3 -x -o $2 --max-filesize 10m'
to
'youtube-dl $1 -f m4a --audio-format $3 -x -o $2.$3 --max-filesize 10m'
then omit the next 3 lines that call ffmpeg in yt.sh, they are causing the extra CPU usage with an extra transcode. The output of the youtube-dl call should be sufficient.
Also note that output is now $2.$3, need to include the extension. $2.%(ext)s would also work
I will attempt to deconstruct what is happening:

If m4a was requested (via --audio-format $3), youtube-dl will call ffmpeg to properly repackage it without the 3 second transcode (this is what we want)
If mp3 was requested for testing purposes via the --audioformat $3 , ffmpeg will be called by youtube-dl to do the transcode from the dash m4a to mp3 (extra 3 seconds).

The key issue here is that yt.sh is still calling a full reencode, which on my PC takes an extra 3 seconds vs remuxing which takes basically 0.
I did a couple tests just using command line arguments.

The key problem under the m4a situation ,
line2 in yt.sh
ffmpeg -i $2 "$2.done.$3"
Even if youtube-dl downloaded in m4a, a reencode still occured. AAC is harder to encode than mp3, so the strenuous results you described make sense.

First downloaded .m4a with youtube-dl, then tried a similar argument to line 2.
Abridged output from ffmpeg conversion to same file
C:\Users\Benjamin>ffmpeg -i "beep.m4a" "beep2.m4a"
ffmpeg version 2.8.4 Copyright (c) 2000-2015 the FFmpeg developers
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'beep.m4a':
Metadata:
major_brand : M4A
minor_version : 512
compatible_brands: isomiso2
encoder : Lavf56.40.101
Duration: 00:03:53.42, start: 0.036281, bitrate: 129 kb/s
Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
Metadata:
handler_name : SoundHandler
Output #0, ipod, to 'beep2.m4a':
Metadata:
major_brand : M4A
minor_version : 512
compatible_brands: isomiso2
encoder : Lavf56.40.101
Stream #0:0(und): Audio: aac (libvo_aacenc) (mp4a / 0x6134706D), 44100 Hz, stereo, s16, 128 kb/s (default)
Metadata:
handler_name : SoundHandler
encoder : Lavc56.60.100 libvo_aacenc
Stream mapping:
Stream #0:0 -> #0:0 (aac (native) -> aac (libvo_aacenc))
Press [q] to stop, [?] for help
size= 3688kB time=00:03:53.44 bitrate= 129.4kbits/s
video:0kB audio:3648kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.097594%

This took my PC nearly 3 seconds to complete, even though they are the same format, as there is an unintentional reencode step occurring with the ffmpeg command. When doing .m4a mode, maybe skip the last 3 lines.

I found, given your parameters
youtube-dl $1 --audio-format $3 -x -o $2 --max-filesize 10m

that the webm format would be auto selected by youtube-dl. This is due to the following format listing of the average video
249 webm audio only DASH audio 55k , opus @ 50k, 1.35MiB
250 webm audio only DASH audio 72k , opus @ 70k, 1.79MiB
171 webm audio only DASH audio 125k , vorbis@128k, 3.38MiB
140 m4a audio only DASH audio 128k , m4a_dash container, mp4a.40.2@128k (44100Hz), 3.54MiB
251 webm audio only DASH audio 136k , opus @160k, 3.55MiB

Webm at 136k is beating m4a at 128k. However, any difference is negligible especially after a reencode.
This causes the apparent necessity of a manual call to ffmpeg in line 2 to convert from webm as demonstrated below
C:\Users\Benjamin>youtube-dl -x -k --max-filesize 10m --audio-format mp3 https://www.youtube.com/watch?v=gPn2zgck5dY
[youtube] gPn2zgck5dY: Downloading webpage
[youtube] gPn2zgck5dY: Downloading video info webpage
[youtube] gPn2zgck5dY: Extracting video information
[youtube] gPn2zgck5dY: Downloading MPD manifest
WARNING: Requested formats are incompatible for merge and will be merged into mkv.
[download] Resuming download at byte 5212656
[download] File is larger than max-filesize (109246331 bytes > 10485760 bytes). Aborting.
[download] Destination: Beep Beep Im a Sheep Instrumental-The Living Tombstone ft LilDeuceDeuce,TomSka & BlackGryph0n-gPn2zgck5dY.f251.webm
[download] 100% of 3.55MiB in 00:17

With the -f m4a flag, we skip the webM formats and go directly for m4a which doesn't require transcode
Notice the 2nd to last line, only a container correction is performed
C:\Users\Benjamin>youtube-dl -x -f m4a --max-filesize 10m --audio-format m4a https://www.youtube.com/watch?v=gPn2zgck5dY
[youtube] gPn2zgck5dY: Downloading webpage
[youtube] gPn2zgck5dY: Downloading video info webpage
[youtube] gPn2zgck5dY: Extracting video information
[youtube] gPn2zgck5dY: Downloading MPD manifest
[download] Destination: Beep Beep Im a Sheep Instrumental-The Living Tombstone ft LilDeuceDeuce,TomSka & BlackGryph0n-gPn2zgck5dY.m4a
[download] 100% of 3.54MiB in 00:18
[ffmpeg] Correcting container in "Beep Beep Im a Sheep Instrumental-The Living Tombstone ft LilDeuceDeuce,TomSka & BlackGryph0n-gPn2zgck5dY.m4a"
[ffmpeg] Post-process file Beep Beep Im a Sheep Instrumental-The Living Tombstone ft LilDeuceDeuce,TomSka & BlackGryph0n-gPn2zgck5dY.m4a exists, skipping

This results in the m4a file at the end

Now, if mp3 was for some reason requested, the -f m4a addition still should work
Note, however, the last line, this is a 3 second transcode from m4a to mp3 by youtube-dl's call to ffmpeg.
C:\Users\Benjamin>youtube-dl -x -k -f m4a --max-filesize 10m --audio-format mp3 https://www.youtube.com/watch?v=gPn2zgck5dY
[download] Beep Beep Im a Sheep Instrumental-The Living Tombstone ft LilDeuceDeuce,TomSka & BlackGryph0n-gPn2zgck5dY.m4a has already been downloaded
[download] 100% of 3.53MiB
[ffmpeg] Correcting container in "Beep Beep Im a Sheep Instrumental-The Living Tombstone ft LilDeuceDeuce,TomSka & BlackGryph0n-gPn2zgck5dY.m4a"
[ffmpeg] Destination: Beep Beep Im a Sheep Instrumental-The Living Tombstone ft LilDeuceDeuce,TomSka & BlackGryph0n-gPn2zgck5dY.mp3

This results with an transcoded .mp3, but I think this is unnecessary if m4a is working correctly. The only reason I could think of to use mp3 is for some browser compatibility issue, but I don't think there is any real problem.

As youtube-dl handles ffmpeg now, your extra calls to it in yt.sh are unnecessary I think.

from eternaljukebox.

Thanks for the writeup, including the -f m4a seems to have made a difference.
The reason for the additional lines previously was due to a bug where files weren't being encoded properly, I assume due to the missing --audio-format parameter. I've added it in and it seems to be working, as well as being returned across browsers. Thank you!

from eternaljukebox.