Open agrathwohl opened 2 months ago
Yeah, that's true. I can confirm that. It was like that in previous versions of Peertube too
Also I want mention another thing that is not really related to this, but affects quality of encoded videos: https://github.com/Chocobozzz/PeerTube/issues/6539
I have found that the problem is resolved if you replace the uploaded file in the video's "Update" page. It can even be the same exact file that was originally uploaded. I can't quite figure out why replacing the video file makes the runners behave properly so far, but I will keep digging.
Hi,
PeerTube doesn't use the original file in transcoding. But it's weird that you have so low quality when using the remote runner :thinking: Do you have the same issue if you use local transcoding?
Can you retry to upload this video using remote runners and debug logs so we can see what file is picked up?
Hi,
PeerTube doesn't use the original file in transcoding. But it's weird that you have so low quality when using the remote runner 🤔 Do you have the same issue if you use local transcoding?
Can you retry to upload this video using remote runners and debug logs so we can see what file is picked up?
When I retried the transcode on the local instance, it sourced a file that was about 3 Mbps, 1080p and at the original uploaded constant frame rate of 24 FPS. So no, I cannot seem to recreate this on local.
Thanks, can you retry with the runner using the --verbose
CLI arg so we can see which file the runner is downloading?
Ping @agrathwohl
Ping @agrathwohl
Hi @Chocobozzz I apologize for my delayed reply. I just started a new job and had to put this on the backburner for a little bit. I will be able to try the --verbose
CLI argument in a couple of days.
Describe the current behavior
When peertube runners are enabled for VOD transcoding on my 6.3.0 peertube instance, requesting a "Run HLS transcodes" from the videos Overview page causes the peertube runner to download a low quality version of the uploaded video file. This results in the 1080p version in the resulting HLS manifest to have very poor visual quality.
In this screenshot you will see that the 1080p version available for this uploaded video is only a little bit bigger than the 720p, but it should of course be around double the file size.
On a video that was uploaded to my peertube instance prior to 6.3.0, the 1080p version would typically be 2x the 720p file size. This video was the video uploaded prior to the ones that began showing this issue. It was when I was running 6.2.1:
You can see that the input file is low quality when running
mediainfo
on the file downloaded by the peertube-runner node when requesting the 1080p transcode:Whereas, the actual uploaded original video's mediainfo output is:
Steps to reproduce
Describe the expected behavior
I would instead expect the peertube runners to always download the original source file to use as the FFmpeg input, since this will produce the best quality results. Is there a way to do this in 6.3.0? If not I would personally label the current behavior as a bug, but if this is the intentional I would then be curious if there's documentation on how to prevent this lower quality version from being downloaded, in favor of the originally uploaded file stored on S3?
Additional information
PeerTube instance:
4.4.2-0ubuntu0.22.04.1
PeerTube Runner version:
0.0.21