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

[Michael Niedermayer]

On Sun, Apr 25, 2021 at 09:58:56PM +0200, Anton Khirnov wrote:
> 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).

I dont see an option in the mailman web interface to change the way the footer
is added. But i would be very happy if someone replies and tells me that
i missed something or any other fix. I imagine FFmpeg is not the first or
only project that hit this issue ...

thx


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210426/1cba16b5/attachment.sig>