[FFmpeg-devel] [PATCH 05/12] fate-ts-small-demux: convert to ffprobe

[Anton Khirnov]

Quoting Michael Niedermayer (2021-04-25 21:28:42)
> On Sun, Apr 25, 2021 at 04:12:41PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2021-04-25 11:29:56)
> > > On Sun, Apr 25, 2021 at 09:03:13AM +0200, Anton Khirnov wrote:
> > > > It can handle side data cleanly.
> > > [....]
> > > > +stream|index=0|codec_name=h264|profile=578|codec_type=video|codec_tag_string=[27][0][0][0]|codec_tag=0x001b|width=82|height=144|coded_width=82|coded_height=144|closed_captions=0|has_b_frames=0|sample_aspect_ratio=1:1|display_aspect_ratio=41:72|pix_fmt=yuv420p|level=10|color_range=unknown|color_space=unknown|color_transfer=unknown|color_primaries=unknown|chroma_location=left|field_order=progressive|refs=1|is_avc=false|nal_length_size=0|id=0x100|r_frame_rate=15/1|avg_frame_rate=15/1|time_base=1/90000|start_pts=126000|start_time=1.400000|duration_ts=444000|duration=4.933333|bit_rate=N/A|max_bit_rate=N/A|bits_per_raw_sample=8|nb_frames=N/A|nb_read_frames=N/A|nb_read_packets=74|extradata_hash=CRC32:e62cae27|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_th
> > > >  umbnails=0|disposition:captions=0|disposition:descriptions=0|disposition:metadata=0|disposition:dependent=0|disposition:still_image=0
> > > > +format|filename=h264small.ts|nb_streams=1|nb_programs=1|format_name=mpegts|start_time=1.400000|duration=4.933333|size=16544|bit_rate=26828|probe_score=50
> > > 
> > > It seems something is cuttning long lines
> > 
> > The email arrives correctly when I send it directly to myself, so I
> > assume the ML is mangling things. Didn't something similar happen to
> > James recently?
> 
> yes, is this a new issue with the servers mail setup or did we just not
> have so long lines previously ?
> 
> the length seems truncated around 1000 and smtp_line_length_limit has a
> default of around that. RFC 5321 also doesnt allow longer lines so iam
> not sure if bumping that limit up is the correct thing to do (if its that
> what truncates it)
> 
> Iam not a mail expert, but naively to me this looks like the
> sender should use base64 or some other encoding if a long line is
> encountered

The original mail was sent as 'quoted-printable' with "soft" line breaks
([1], section 6.7 (5)) with the actual "physical" lines in the file
wrapped to 76 characters as per RFC.

The mail that arrived from the list was '7bit', where the line length is
indeed limited to 998 characters ([2], section 2.1.1). So it seems
likely that the code that adds the mailing list footer is responsible.
IMO it should be configured to always add the footer as a separate MIME
part rather than mangling the original message body (if it's possible).

[1] https://tools.ietf.org/html/rfc2045
[2] https://tools.ietf.org/html/rfc2822

-- 
Anton Khirnov