[FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order

[Alexander Strasser]

On 2019-04-28 07:42 +0000, Guo, Yejun wrote:
> > -----Original Message-----
> > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of
> > Alexander Strasser
> > Sent: Sunday, April 28, 2019 9:18 AM
> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
> > decoder/encoder/filter/... names in alphabet order
> >
> >
> > What do you think about using awk instead of shell?
> >
> > I have 2 POC patches attached. It's probably not 100% correct yet,
> > but it kind of demonstrates what it would look like.
> >
> > The main advantage of using awk, is that it's more elegant and
> > shorter. It's probably also less risky, because it's more isolated,
> > e.g. as it was explained by avih, there is no widely supported way
> > for locals across shells. We already use awk in configure for
> > mandatory functions, so it's no new dependency.
> >
> > Please comment on the awk approach.
>

> I did some change to make it correct on ubuntu 16.04, but looks issue on windows mingw.
>
> print_in_columns() {
>     sort | tr '\n' ' ' | awk -v width="$ncols" '
>     {
>         #add int()
>         num_cols = int(width / 24); num_rows = int((NF + num_cols-1) / num_cols);

The added int() calls looks right.


>         y = x = 1;
>         for (i = 1; i <= NF; i++) {
>             if (y > num_rows) {
>                 y = 1; x++;
>             }
>             d[x,y] = $i;
>             y++;
>         }
>
> 		print width
> 		print num_cols
> 		print num_rows
> 		print NF
>
>         for (y = 1; y <= num_rows; y++) {
>             for (x = 1; x <= num_cols; x++) {
>                 # it does not work for the case that the last column is not fully filled
>                 #line = sprintf(x != num_cols ? "%s%-24s" : "%s%s", line, d[x,y]);
>                 line = sprintf("%s%-24s", line, d[x,y]);

You mean it doesn't work in the way that there will be trailing spaces
in the column before the last one which is partially empty, right?

But the output looked right and there were never trailing spaces in the
last column, right?

BTW I changed the algorithm here, because I thought it might be easier
to unterstand. I will also try the algorithm, you implemented in shell.


>             }
>             print line;
>             line = "";
>         }
>     }' | sed 's/ *$//'
> }
>
> on ubuntu 16.04, the output is:
> Enabled bsfs:
> 135
> 5
> 7
> 33
> aac_adtstoasc           extract_extradata       hevc_mp4toannexb        mpeg4_unpack_bframes    truehd_core
> av1_frame_split         filter_units            imx_dump_header         noise                   vp9_metadata
> av1_metadata            h264_metadata           mjpeg2jpeg              null                    vp9_raw_reorder
> chomp                   h264_mp4toannexb        mjpega_dump_header      prores_metadata         vp9_superframe
> dca_core                h264_redundant_pps      mov2textsub             remove_extradata        vp9_superframe_split
> dump_extradata          hapqa_extract           mp3_header_decompress   text2movsub
> eac3_core               hevc_metadata           mpeg2_metadata          trace_headers
>
> while on windows, the output is:
> Enabled bsfs:
> 72
> 3
> 11
> 33
>      noiseh264_redundant_pps
>           nullextract
>           prores_metadata
>        remove_extradatamp4toannexb
>         text2movsubdump_header
>              trace_headers
>      truehd_corepega_dump_header
>             vp9_metadata
>   vp9_raw_reorderader_decompress
>          vp9_superframea
>    vp9_superframe_splitames

Wild guess: CR LF line endings are emitted somewhere and the CRs stay in
the input. Your terminal resets the cursor to the start of the line when
interpreting the midline CRs.

Does it work if you extend the tr in print_in_columns like below?

     sort | tr '\r\n' '  ' | awk -v width="$ncols" '


> I did a quick check, but has not found the root cause yet.
>
>
> >
> > I'm not against the shell way, or a mixed approach, but before going
> > either way and pushing I would rather have some more testing;
> > especially on more exotic platforms.

Thanks for testing and looking into it!

  Alexander