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

[Guo, Yejun]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of
> Alexander Strasser
> Sent: Sunday, April 28, 2019 11:29 PM
> 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
> 
> 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?

suppose num_cols = 3, see below, the spaces after 'c' is trimmed, while the spaces after 'e' is still there.

a<spaces>b<spaces>c
d<spaces>e<spaces>


> 
> 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" '
> 

yes, it works!

> 
> > 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".