New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let Encode Handle HLS #3128
Let Encode Handle HLS #3128
Conversation
The internal code of the encode operation will now pick up HLS playlist but this is unfortunately not handles later in the code, causing the inspect operations to fail. This fixes the issue by looking out for HLS playlists, ensuring the file references in there are correct during inspection. This also changes the way inspections are run, switching from a sequential run on all files to running the inspection in parallel, like we do with the other operations. This shouldn't change the default behavior of the encode operations in any way.
Is this basically what the |
Looks like a trimmed version of The good looks and runs, but I'm having trouble reproducing the error that warranted this change in the first place? Do you have an example on how to test this? |
It's similar, but not exactly the same. This makes sure the references work after the files were put into a collection. This is now the same behavior you get when you run other code paths of the composer e.g.: Lines 2340 to 2346 in 57fcab3
I'll try to writing a short encoding example to reproduce this tomorrow. |
I promised an example. This isn't the best one, but should do to highlight the issue. profile.fast.http.name = fast processed mp4
profile.fast.http.input = visual
profile.fast.http.output = visual
profile.fast.http.suffix = .m3u8
profile.fast.http.ffmpeg.command = -i #{in.video.path} \
-filter_complex:v [0:v]scale=1280:-2,fps=30[vout0];[0:a]acopy[aout0] \
-map [aout0] \
-map [vout0] \
-force_key_frames:v:0 expr:eq(mod(n,60),0) \
-x264opts:v:0 rc-lookahead=60:keyint=120:min-keyint=60:no-open-gop=1 \
-preset:v:0 veryfast \
-pix_fmt:v:0 yuv420p \
-c:v:0 libx264 \
-maxrate:v 4900k \
-bufsize:v 4M \
-b:v:0 4500k \
-c:a:0 aac \
-b:a:0 128k \
-filter_complex:v [0:v]scale=640:-2,fps=30[vout1];[0:a]acopy[aout1] \
-map [aout1] \
-map [vout1] \
-force_key_frames:v:1 expr:eq(mod(n,60),0) \
-x264opts:v:1 rc-lookahead=60:keyint=120:min-keyint=60:no-open-gop=1 \
-preset:v:1 veryfast \
-pix_fmt:v:1 yuv420p \
-c:v:1 libx264 \
-maxrate:v:1 1320k \
-bufsize:v:1 1M \
-b:v:1 1200k \
-c:a:1 aac \
-b:a:1 64k \
-filter_complex:v [0:v]scale=320:-2,fps=15[vout2];[0:a]acopy[aout2] \
-map [aout2] \
-map [vout2] \
-force_key_frames:v:2 expr:eq(mod(n,30),0) \
-x264opts:v:2 rc-lookahead=30:keyint=60:min-keyint=30:no-open-gop=1 \
-preset:v:2 veryfast \
-pix_fmt:v:2 yuv420p \
-c:v:2 libx264 \
-minrate:v:2 90k \
-maxrate:v:2 110k \
-bufsize:v:2 100k \
-b:v:2 100k \
-c:a:2 aac \
-b:a:2 48k \
-var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" \
-hls_time 6 \
-flags +global_header+cgop \
-movflags +faststart \
-err_detect compliant \
-copyts \
-muxdelay 0 \
-hls_segment_type fmp4 \
-f hls \
-hls_list_size 0 \
-hls_playlist_type vod \
-hls_flags single_file+program_date_time+independent_segments+round_durations \
-hls_segment_filename #{out.dir}/#{out.name}_segment_%v.mp4 \
-master_pl_name #{out.name}-master.m3u8 \
#{out.dir}/#{out.name}_variant_%v#{out.suffix} |
I tested as you suggested but see the following error:
So the |
The |
The internal code of the encode operation will now pick up HLS playlist
but this is unfortunately not handles later in the code, causing the
inspect operations to fail. This fixes the issue by looking out for HLS
playlists, ensuring the file references in there are correct during
inspection.
This also changes the way inspections are run, switching from a
sequential run on all files to running the inspection in parallel, like
we do with the other operations.
This shouldn't change the default behavior of the encode operations in
any way.
Your pull request should…