How to refactor code to turn HTTP trigger to a Blob Trigger?

I had some spare time, and despite using Azure Functions for more than a year now, never had the chance to implement an actual BlobTrigger. So I thought I'd share my tiny core 3.0 test implementation, and add an overkill answer as a supplement to @Bryan Lewis' correct answer.

If you want to test this before launching on Azure, you should first make sure you have Azure Storage Emulator. If you have Visual Studio 2019, it should already be installed. If you have VS19 but it's not installed, you should open the Visual Studio Installer and modify your VS19 installation. Under "Individual Components", you should be able to find "Azure Storage Emulator". If you don't have VS19, you can get it here.

Next I'd recommend downloading Azure Storage Explorer from here. If the emulator is running and you didn't change the default ports for the Storage Emulator you should be able to find a default entry under Local & Attached > Storage Accounts > (Emulator - Default ports).

Using the Storage Explorer, you can expand "Blob Containers". Right click "Blob Containers", and choose to "Create Blob Container", and give it a name. For my example I named it "youtube-files". I also created another container calling it "youtube-files-descriptions".

Now for the actual function. I gave myself the liberty to do this with dependency injection (I just dread the static chaos). For this you'll have to include the NuGet package Microsoft.Azure.Functions.Extensions and Microsoft.Extensions.DependencyInjection.

Startup
We register our services and what-not here. I'll add an InternalYoutubeService (named as such to not confuse it with the one supplied by the Goodle APIs). You can read more about DI and Azure functions here.

// Notice that the assembly definition comes before the namespace
[assembly: FunctionsStartup(typeof(FunctionApp1.Startup))]
namespace FunctionApp1
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            // You can of course change service lifetime as needed
            builder.Services.AddTransient<IInternalYoutubeService, InternalYoutubeService>();
        }
    }
}

BlobFunction
You don't have to add/register classes containing any azure functions, they're handled automagically. Notice the difference between BlobTrigger and Blob. BlobTrigger dictates that it is only when files are uploaded into the "youtube-files" container that the function actually triggers; simultaneously it will look up a blob in the "youtube-files-descriptions" container for a file with the same filename as the incoming one from the BlobTrigger, but with a "-description" suffix and only if it is using ".txt" extension. If the blob is not found, it will return null, and the bound string description will be null. You can find the different availing bindings here. The link will generally speaking tell you what you need to know about the BlobTrigger and Blob attribute.

[StorageAccount("AzureWebJobsStorage")]
public class BlobFunction
{
    private readonly IInternalYoutubeService _YoutubeService;
    private readonly ILogger _Logger;

    // We inject the YoutubeService    
    public BlobFunction(IInternalYoutubeService youtubeService, ILogger<BlobFunction> logger)
    {
        _YoutubeService = youtubeService;
        _Logger = logger;
    }

    [FunctionName("Function1")]
    public async Task Run(
        [BlobTrigger("youtube-files/{filename}.{extension}")] Stream blob,
        [Blob("youtube-files-descriptions/{filename}-description.txt")] string description,
        string filename,
        string extension)
    {
        switch (extension)
        {
            case "mp4":
                await _YoutubeService.UploadVideo(blob, filename, description, "Some tag", "Another tag", "An awesome tag");
                break;

            case "mp3":
                await _YoutubeService.UploadAudio(blob, filename, description);
                break;

            default:
                _Logger.LogInformation($"{filename}.{extension} not handled");
                break;
        }
    }
}

YoutubeService
Will contain the logic that'll handle the actual authentication (the OAuth2 you're using) and the upload of the file. You can refer to @Bryan Lewis' answer in terms of how to use the incoming Stream. We could store our credentials in our function app's configuration and inject the IConfiguration interface, which allows us to access the values by supplying the value's key defined in the configuration. This way you avoid hardcoding any credentials in your code. I have omitted the YouTube-specific upload logic, as I have no experience with the library you're using, but it should be simple enough to migrate the logic to the service.

public interface IInternalYoutubeService
{
    Task UploadVideo(Stream stream, string title, string description, params string[] tags);
    Task UploadAudio(Stream stream, string title, string description, params string[] tags);
}

internal class InternalYoutubeService : IInternalYoutubeService
{
    private readonly IConfiguration _Configuration;
    private readonly ILogger _Logger;

    public InternalYoutubeService(IConfiguration configuration, ILogger<InternalYoutubeService> logger)
    {
        _Configuration = configuration;
        _Logger = logger;
    }

    public async Task UploadAudio(Stream stream, string title, string description, params string[] tags)
    {
        _Logger.LogInformation($"{_Configuration["YoutubeAccountName"]}");
        _Logger.LogInformation($"{_Configuration["YoutubeAccountPass"]}");
        _Logger.LogInformation($"Bytes: {stream.Length} - {title} - {description} - {string.Join(", ", tags)}");
    }

    public async Task UploadVideo(Stream stream, string title, string description, params string[] tags)
    {
        _Logger.LogInformation($"{_Configuration["YoutubeAccountName"]}");
        _Logger.LogInformation($"{_Configuration["YoutubeAccountPass"]}");
        _Logger.LogInformation($"Bytes: {stream.Length} - {title} - {description} - {string.Join(", ", tags)}");
    }
}

local.settings.json
You'd of course put these values into your function app's configuration on Azure Portal, except the storage string, when you're done testing locally.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "YoutubeAccountName": "MyAccountName",
    "YoutubeAccountPass": "MySecretPassword"
  }
}

Testing
I'm testing with a simple text file, "Test File-description.txt", containing the text "This is a sample description.". I also have a ~5MB MP3 file, "Test File.mp3". I start by drag-n-dropping my text file into the "youtube-files-descriptions" container, followed by drag-n-dropping the "Test File.mp3" file into the "youtube-files" container. The function is not triggered by uploading the text file; it's not 'till I upload "Test File.mp3" that the function triggers. I see the following lines logged:

Executing 'Function1' (Reason='New blob detected: youtube-files/Test File.mp3', Id=50a50657-a9bb-41a5-a7d5-2adb84477f69)
MyAccountName
MySecretPassword
Bytes: 5065849 - Test File - This is a sample description. -
Executed 'Function1' (Succeeded, Id=50a50657-a9bb-41a5-a7d5-2adb84477f69)