FFV1 encodes incorrectly reported as Progressive, is actually interlaced

[Killer3737]

I'm encoding a few lossless capture files in various formats (HuffYUV, UTVideo, Uncompressed) to FFV1 for archive purposes. They are all interlaced, verified by loading the clips in AvsPMod and applying separatefields(), unique frames on each step. It's also easy to see visually, with all the combing. Some are TFF, some BFF, but all 100% interlaced, captured from VHS mostly.

This is the input I use for FFV1 (This for a TFF source, hence -top 1):

ffmpeg -i "INPUT" -c:a flac -compression_level 12 -c:v ffv1 -level 3 -threads 8 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 -top 1 -flags +ilme+ildct "OUTPUT"

On this output, mediainfo reports it as Progressive

Scan type : Progressive
Compression mode : Lossless
Writing library : Lavc57.106.101 ffv1
Default : Yes
Forced : No
coder_type : Range Coder
MaxSlicesCount : 24
ErrorDetectionType : Per slice

as does ffprobe

Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv422p(progressive), 720x576, 25 fps, 25 tbr, 1k tbn, 1k tbc (default)

However loading the ouput again in Avspmod, it is still interlaced TFF, which is obviously what I want. So whilst this isn't a problem in terms of the actual video output, given that these are archive files that may be used 10-20 years down the line, and perhaps by someone else, I'd prefer to avoid the confusion and have the output file correctly identify itself as Interlaced.

Anyone know why it's not correctly reported as interlaced?

[JVRaines]

FFmpeg assumes your video is progressive unless you tell it otherwise. What format are you muxing into?

[Killer3737]

FFmpeg assumes your video is progressive unless you tell it otherwise. What format are you muxing into?

Indeed, which is why I included the -top 1 -flags +ilme+ildct arguments. Is that not enough? Mux format was MKV.

[jagabo]

I don't think FFV1 supports interlace flagging. I used that command line on an interlaced YUY2 source and the resulting MKV file was flagged progressive. But the since YUY2 doesn't subsample chroma vertically it doesn't matter. You can treat the video as interlaced down the line and it works fine. Changing the command line to use libx264 instead of ffv1 gave a video that was flagged interlaced (MBAFF, TFF) and was properly encoded.

[Killer3737]

I don't think FFV1 supports interlace flagging. I used that command line on an interlaced YUY2 source and the resulting MKV file was flagged progressive. But the since YUY2 doesn't subsample chroma vertically it doesn't matter. You can treat the video as interlaced down the line and it works fine. Changing the command line to use libx264 instead of ffv1 gave a video that was flagged interlaced (MBAFF, TFF) and was properly encoded.

It does appear that way, which seems strange for what is supposed to be an archive codec, lots of archive footage is going to be interlaced. As I say looking at the output it is still interlaced, but it may confuse someone down the line if everything reports it to be progressive, sadly not everyone properly analyses footage before editing it.

[richardpl]

FFV1 flags interlaced videos in version 3. You must used older version.

[JVRaines]

FFV1 flags interlaced videos in version 3. You must used older version.

Can you provide an example? I'm using V3 and I can't force it to set an interlace flag.

[Killer3737]

FFV1 flags interlaced videos in version 3. You must used older version.

-c:v ffv1 -level 3

Was in my input.

[richardpl]

Then your input is not flagged as interlaced. ildct/ilme flags does not make sense as FFV1 does not use (I)DCT or motion estimation at all.
Try to mark your input as interlaced.

[Killer3737]

Then your input is not flagged as interlaced. ildct/ilme flags does not make sense as FFV1 does not use (I)DCT or motion estimation at all.
Try to mark your input as interlaced.

Ok, how would you change my input then?

ffmpeg -i "INPUT" -c:a flac -compression_level 12 -c:v ffv1 -level 3 -threads 8 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 -top 1 -flags +ilme+ildct "OUTPUT"

Does the -top 1 flag need to go right after the input file?

[jagabo]

Richardpl is correct. I just tried it with an interlaced DV AVI file and an interlaced MPEG 2 file. MediaInfo reported the output MKV files as interlaced with the correct field order.

ffmpeg.exe -i "DVInterlaced.avi" -c:v ffv1 -level 3 "DVInterlaced.mkv"
ffmpeg.exe -i "interlaced.m2v" -c:v ffv1 -level 3 "interlaced.mkv"

I checked the resulting files and there were no problems with the interlacing.

I tried with an AviSynth script as input (interlaced YUY2 output) but ffmpeg didn't recognize that as interlaced. I wasn't able to figure out how to convince it that source was interlaced.

[richardpl]

Does the -top 1 flag need to go right after the input file?

Before input file.

[Killer3737]

Richardpl is correct. I just tried it with an interlaced DV AVI file and an interlaced MPEG 2 file. MediaInfo reported the output MKV files as interlaced with the correct field order.

ffmpeg.exe -i "DVInterlaced.avi" -c:v ffv1 -level 3 "DVInterlaced.mkv"
ffmpeg.exe -i "interlaced.m2v" -c:v ffv1 -level 3 "interlaced.mkv"

I checked the resulting files and there were no problems with the interlacing.

I tried with an AviSynth script as input (interlaced YUY2 output) but ffmpeg didn't recognize that as interlaced. I wasn't able to figure out how to convince it that source was interlaced.

Yeah, I'm finding the same. Other interlaced input is recognised but not my lossless captures, which are UtVideo YUV422 or HuffYUV YUV422 interlaced.

I think unless I can find a solution where these are correctly marked as interlaced I'll just leave them in those formats for now. I was only encoding them to FFV1 because it's open source and theoretically more future proof than HuffYUV or UtVideo.

[poisondeathray]

ffv1 supports AR flagging too (since these are VHS caps , -aspect 4:3 is probably appropriate) .



For some types of inputs (like avs for example) flagging before the -i doesn't work for some reason

=> The clunky workaround for this used to be piping ffmpeg to ffmpeg, flagging the 1st instance . I don't know if there is a more elegant solution these days

You'd have to feed audio using a second -i and using -map, since a yuv4mpegpipe only carries 1 video stream (no audio)

eg. (assuming avs carries audio, but you can replace with whatever)

ffmpeg -i input.avs -top 1 -f yuv4mpegpipe - | ffmpeg -i - -i input.avs -map 0:0 -map 1:1 -c:v ffv1 -threads 8 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 -c:a flac -compression_level 12 -aspect 4:3 output.mkv

If you check with ffmpeg/ffprobe or mediainfo, you will see interlace and AR is preserved




It might be more "future proof" at least in terms of open source tools, but unfortunately compatibility is still very low with other "professional" programs like NLE's etc...

[Killer3737]

ffv1 supports AR flagging too (since these are VHS caps , -aspect 4:3 is probably appropriate) .



For some types of inputs (like avs for example) flagging before the -i doesn't work for some reason

=> The clunky workaround for this used to be piping ffmpeg to ffmpeg, flagging the 1st instance . I don't know if there is a more elegant solution these days

You'd have to feed audio using a second -i and using -map, since a yuv4mpegpipe only carries 1 video stream (no audio)

eg. (assuming avs carries audio, but you can replace with whatever)

ffmpeg -i input.avs -top 1 -f yuv4mpegpipe - | ffmpeg -i - -i input.avs -map 0:0 -map 1:1 -c:v ffv1 -threads 8 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 -c:a flac -compression_level 12 -aspect 4:3 output.mkv

If you check with ffmpeg/ffprobe or mediainfo, you will see interlace and AR is preserved




It might be more "future proof" at least in terms of open source tools, but unfortunately compatibility is still very low with other "professional" programs like NLE's etc...

No joy for me with that one, output is a green mess and still reported as progressive.

Here is a sample if you/anyone wants to try it and get an output recognised as interlaced.

123MB, YUV422 UtVideo Interlaced.
https://mega.nz/#!Flxz1bTZ!0iR3rf92e7OQK3OlFrH8NFWWprzzOnaqyaAA6BxSbow

[poisondeathray]

No joy for me with that one, output is a green mess and still reported as progressive.

Here is a sample if you/anyone wants to try it and get an output recognised as interlaced.

123MB, YUV422 UtVideo Interlaced.
https://mega.nz/#!Flxz1bTZ!0iR3rf92e7OQK3OlFrH8NFWWprzzOnaqyaAA6BxSbow

works ok here

Video
ID : 1
Format : FFV1
Format version : Version 3.4
Format settings, GOP : N=1
Codec ID : V_MS/VFW/FOURCC / FFV1
Duration : 15 s 0 ms
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossless
Writing library : Lavc58.22.101 ffv1
Default : Yes
Forced : No
coder_type : Range Coder
MaxSlicesCount : 24
ErrorDetectionType : Per slice

Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 14 s 994 ms
Bit rate mode : Variable
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Writing library : Lavc58.22.101 flac
Default : Yes
Forced : No

ffprobe excerpt

Stream #0:0, 1, 1/1000: Video: ffv1, 1 reference frame (FFV1 / 0x31564646),
yuv422p(top coded first (swapped)), 720x576, 0/1, SAR 16:15 DAR 4:3, 25 fps, 25
tbr, 1k tbn, 1k tbc (default)

[Killer3737]

Hmm strange, must be an issue my end then. To confirm, this was your input for that file?

ffmpeg -i sample.avi -top 1 -f yuv4mpegpipe - | ffmpeg -i - -i sample.avi -map 0:0 -map 1:1 -c:v ffv1 -threads 8 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 -c:a flac -compression_level 12 -aspect 4:3 out.mkv

When I use that I get this error in ffmpeg (v. 4.0.2)

Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
pipe:: Invalid data found when processing input

And the output looks like this

https://forum.videohelp.com/images/imgfiles/hE8NQVv.jpg

[poisondeathray]

commandline looks the same unless there was a typo somewhere

this is what I used exactly (copy/paste)

ffmpeg -i sample.avi -top 1 -f yuv4mpegpipe - | ffmpeg -i - -i sample.avi -map 0:0 -map 1:1 -c:v ffv1 -threads 8 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 -c:a flac -compression_level 12 -aspect 4:3 output.mkv

Maybe update your ffmpeg ? I used zeranoe's windows build , maybe a few weeks old. Maybe your ffmpeg binary wasn't compiled with updated utvideo library ?

It plays ok with ffplay, other media players

[Killer3737]

commandline looks the same unless there was a typo somewhere

this is what I used exactly (copy/paste)

ffmpeg -i sample.avi -top 1 -f yuv4mpegpipe - | ffmpeg -i - -i sample.avi -map 0:0 -map 1:1 -c:v ffv1 -threads 8 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 -c:a flac -compression_level 12 -aspect 4:3 output.mkv

Maybe update your ffmpeg ? I used zeranoe's windows build , maybe a few weeks old. Maybe your ffmpeg binary wasn't compiled with updated utvideo library ?

It plays ok with ffplay, other media players

I updated ffmpeg to the latest from zeranoe. With the release build, 4.0.2 I still got the progressive labelled output and the lav version was older:

Scan type : Progressive
Compression mode : Lossless
Writing library : Lavc58.18.100 ffv1

With the latest nightly, I do get the same as you, interlaced and Lav version Lavc58.24.101, but the output still looks like that, with the error messages.

I'll have to do some investigating to see what my personal issue is, but thanks for giving the general solution.

[poisondeathray]

With the latest nightly, I do get the same as you, interlaced and Lav version Lavc58.24.101, but the output still looks like that, with the error messages.

Green output ? in ffplay too ? Not all players/decoders support ffv1 1.3 . Check the output in some updated players with updated decoders too. Recent ffplay should decode ok

do you still get the pipe error ?

I get the thread_queue message too (not the pipe error) , but shouldn't affect the actual output, just the processing speed .

[JVRaines]

Yeah, I'm finding the same. Other interlaced input is recognised but not my lossless captures, which are UtVideo YUV422 or HuffYUV YUV422 interlaced.

This is my experience as well. My Lagarith/AVI captures do not carry an interlace flag so the FFV1/MKV output does not, either. It appears that FFmpeg only passes through the input flag and provides no way to force it for this codec.

[Killer3737]

With the latest nightly, I do get the same as you, interlaced and Lav version Lavc58.24.101, but the output still looks like that, with the error messages.

Green output ? in ffplay too ? Not all players/decoders support ffv1 1.3 . Check the output in some updated players with updated decoders too. Recent ffplay should decode ok

do you still get the pipe error ?

I get the thread_queue message too (not the pipe error) , but shouldn't affect the actual output, just the processing speed .

Yeah, green, and still the pipe error. It wasn't green when doing it directly, only with your pipe workaround. Definitely an encode issue, because the size/bitrate is smaller.

[poisondeathray]

Are you calling the correct ffmpeg version ?

Try specifying explicit path to the ffmpeg.exe binary.

(The version I used was Aug11 - ffmpeg-20180811-00ae349-win64-static.zip)

[Killer3737]

Are you calling the correct ffmpeg version ?

Try specifying explicit path to the ffmpeg.exe binary.

(The version I used was Aug11 - ffmpeg-20180811-00ae349-win64-static.zip)

Yep, it's in my PATH, the latest nightly. Here is the entire output:

ffmpeg version N-91666-g70d2bab80b Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180813
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
libavutil 56. 19.100 / 56. 19.100
libavcodec 58. 24.101 / 58. 24.101
libavformat 58. 17.103 / 58. 17.103
libavdevice 58. 4.101 / 58. 4.101
libavfilter 7. 26.100 / 7. 26.100
libswscale 5. 2.100 / 5. 2.100
libswresample 3. 2.100 / 3. 2.100
libpostproc 55. 2.100 / 55. 2.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avi, from 'sample.avi':
Metadata:
encoder : Lavf56.19.100
Duration: 00:00:15.00, start: 0.000000, bitrate: 69004 kb/s
Stream #0:0: Video: utvideo (ULY2 / 0x32594C55), yuv422p(bt470bg/unknown/unknown), 720x576, 67629 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (utvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf58.17.103
Stream #0:0: Video: wrapped_avframe, yuv422p(top first), 720x576, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc58.24.101 wrapped_avframe
frame= 375 fps=200 q=-0.0 Lsize= 303752kB time=00:00:15.00 bitrate=165889.2kbits/s speed=8.02x
video:196kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 154647.406250%
ffmpeg version N-91666-g70d2bab80b Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180813
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
libavutil 56. 19.100 / 56. 19.100
libavcodec 58. 24.101 / 58. 24.101
libavformat 58. 17.103 / 58. 17.103
libavdevice 58. 4.101 / 58. 4.101
libavfilter 7. 26.100 / 7. 26.100
libswscale 5. 2.100 / 5. 2.100
libswresample 3. 2.100 / 3. 2.100
libpostproc 55. 2.100 / 55. 2.100
Input #0, yuv4mpegpipe, from 'pipe:':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (Y42B / 0x42323459), yuv422p(top first), 720x576, 25 fps, 25 tbr, 25 tbn, 25 tbc
Guessed Channel Layout for Input Stream #1.1 : stereo
Input #1, avi, from 'sample.avi':
Metadata:
encoder : Lavf56.19.100
Duration: 00:00:15.00, start: 0.000000, bitrate: 69004 kb/s
Stream #1:0: Video: utvideo (ULY2 / 0x32594C55), yuv422p(bt470bg/unknown/unknown), 720x576, 67629 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream #1:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Stream #1:1 -> #0:1 (pcm_s16le (native) -> flac (native))
Output #0, matroska, to 'output.mkv':
Metadata:
encoder : Lavf58.17.103
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv422p(top coded first (swapped)), 720x576 [SAR 16:15 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 1k tbn, 25 tbc
Metadata:
encoder : Lavc58.24.101 ffv1
Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo, s16, 128 kb/s
Metadata:
encoder : Lavc58.24.101 flac
[yuv4mpegpipe @ 000001617dc9b640] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
pipe:: Invalid data found when processing input=00:00:13.92 bitrate=52394.1kbits/s speed=3.45x
frame= 375 fps= 86 q=-0.0 Lsize= 98806kB time=00:00:14.99 bitrate=53982.6kbits/s speed=3.43x
video:97430kB audio:1355kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.020879%

[poisondeathray]

<edit>
Mine is 121MB. no pipe error. Weird

F:\_DOWNLOADS\sample>ffmpeg -i sample.avi -top 1 -f yuv4mpegpipe - | ffmpeg -i -
 -i sample.avi -map 0:0 -map 1:1 -c:v ffv1 -threads 8 -coder 1 -context 1 -g 1 -
slices 24 -slicecrc 1 -c:a flac -compression_level 12 -aspect 4:3 output.mkv -y
ffmpeg version N-91594-g00ae3498bf Copyright (c) 2000-2018 the FFmpeg developers

  built with gcc 7.3.1 (GCC) 20180812
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfi
g --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-lib
freetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amr
wb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --
enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-l
ibwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --
enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --en
able-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --en
able-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --e
nable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enab
le-avisynth
  libavutil      56. 19.100 / 56. 19.100
  libavcodec     58. 22.101 / 58. 22.101
  libavformat    58. 17.101 / 58. 17.101
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 26.100 /  7. 26.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avi, from 'sample.avi':
ffmpeg version N-91594-g00ae3498bf  Metadata:
 Copyright (c) 2000-2018 the FFmpeg developers    encoder         :
Lavf56.19.10  built with gcc 7.3.1 (GCC) 20180812
0  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconf
ig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-li
bfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-am
rwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy -
-enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-
libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 -
-enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --e
nable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --e
nable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --
enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --ena
ble-avisynth

  libavutil      56. 19.100 / 56. 19.100  Duration:
00:00:15.0  libavcodec     58. 22.101 / 58. 22.1010
, start:  libavformat    58. 17.101 / 58. 17.101
0.000000  libavdevice    58.  4.101 / 58.  4.101
, bitrate:  libavfilter     7. 26.100 /  7. 26.100
69004 kb/s  libswscale      5.  2.100 /  5.  2.100

    Stream #0:0: Video: utvideo (ULY2 / 0x32594C55), yuv422p(bt470bg/unknown/unk
nown), 720x576, 67629 kb/  libswresample   3.  2.100 /  3.  2.100s,
25 fps,   libpostproc    55.  2.100 / 55.  2.10025 tbr,
25 tbn, 25 tbc
    Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16
, 1536 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (utvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to 'pipe:':
  Metadata:
    encoder         : Lavf58.17.101
    Stream #0:0: Video: wrapped_avframe, yuv422p(top first), 720x576, q=2-31, 20
0 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.22.101 wrapped_avframe
Input #0, yuv4mpegpipe, from 'pipe:':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (Y42B / 0x42323459), yuv422p(top first), 720x57
6, 25 fps, 25 tbr, 25 tbn, 25 tbc
Guessed Channel Layout for Input Stream #1.1 : stereo
Input #1, avi, from 'sample.avi':
  Metadata:
    encoder         : Lavf56.19.100
  Duration: 00:00:15.00, start: 0.000000, bitrate: 69004 kb/s
    Stream #1:0: Video: utvideo (ULY2 / 0x32594C55), yuv422p(bt470bg/unknown/unk
nown), 720x576, 67629 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
    Stream #1:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16
, 1536 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
  Stream #1:1 -> #0:1 (pcm_s16le (native) -> flac (native))
Output #0, matroska, to 'output.mkv':
  Metadata:
    encoder         : Lavf58.17.101
    Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv422p(top coded first (swapp
ed)), 720x576 [SAR 16:15 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 1k tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.22.101 ffv1
    Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo, s16,
 128 kb/s
    Metadata:
      encoder         : Lavc58.22.101 flac
[yuv4mpegpipe @ 00000031cd5fbec0] Thread message queue blocking; consider raisin
g the thread_queue_size option (current value: 8)
frame=   13 fps=0.0 q=-0.0 size=   10530kB time=00:00:00.52 bitrate=165890.0kbit
frame=    7 fps=0.0 q=-0.0 size=    2234kB time=00:00:00.38 bitrate=47665.1kbits
frame=   51 fps= 51 q=-0.0 size=   41310kB time=00:00:02.04 bitrate=165889.4kbit
frame=   47 fps= 46 q=-0.0 size=   16017kB time=00:00:01.92 bitrate=68337.7kbits
frame=   94 fps= 63 q=-0.0 size=   76141kB time=00:00:03.76 bitrate=165889.3kbit
frame=   93 fps= 61 q=-0.0 size=   30872kB time=00:00:03.74 bitrate=67549.5kbits
frame=  147 fps= 73 q=-0.0 size=  119071kB time=00:00:05.88 bitrate=165889.3kbit
frame=  146 fps= 72 q=-0.0 size=   46323kB time=00:00:05.85 bitrate=64801.1kbits
frame=  175 fps= 70 q=-0.0 size=  141751kB time=00:00:07.00 bitrate=165889.3kbit
frame=  174 fps= 69 q=-0.0 size=   54450kB time=00:00:07.00 bitrate=63649.4kbits
frame=  227 fps= 76 q=-0.0 size=  183871kB time=00:00:09.08 bitrate=165889.2kbit
frame=  225 fps= 75 q=-0.0 size=   70288kB time=00:00:09.02 bitrate=63807.7kbits
frame=  275 fps= 79 q=-0.0 size=  222752kB time=00:00:11.00 bitrate=165889.2kbit
frame=  272 fps= 77 q=-0.0 size=   86658kB time=00:00:10.94 bitrate=64866.5kbits
frame=  318 fps= 79 q=-0.0 size=  257582kB time=00:00:12.72 bitrate=165889.2kbit
frame=  314 fps= 78 q=-0.0 size=  100826kB time=00:00:12.57 bitrate=65678.1kbits
frame=  356 fps= 79 q=-0.0 size=  288362kB time=00:00:14.24 bitrate=165889.2kbit
frame=  352 fps= 78 q=-0.0 size=  115165kB time=00:00:14.11 bitrate=66852.9kbits
frame=  375 fps= 79 q=-0.0 Lsize=  303752kB time=00:00:15.00 bitrate=165889.2kbi
ts/s speed=3.16x
video:196kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing o
verhead: 154647.406250%
frame=  375 fps= 78 q=-0.0 Lsize=  124589kB time=00:00:14.99 bitrate=68069.2kbit
s/s speed=3.13x
video:123213kB audio:1355kB subtitle:0kB other streams:0kB global headers:0kB mu
xing overhead: 0.016563%

[poisondeathray]

Not sure what' s going on, but check the pipe output in ffplay - is it "green" for you ?

ffmpeg -i sample.avi -top 1 -f yuv4mpegpipe - | ffplay -i -

[Killer3737]

EDIT:

Heh, well this was ridiculously stupid. I'd been running all of these through powershell, I thought to try old Command Prompt instead and hey presto, it's fine.

[poisondeathray]

EDIT:

Heh, well this was ridiculously stupid. I'd been running all of these through powershell, I thought to try old Command Prompt instead and hey presto, it's fine.

Just curious - Why would that make a difference in powershell ?

[Killer3737]

EDIT:

Heh, well this was ridiculously stupid. I'd been running all of these through powershell, I thought to try old Command Prompt instead and hey presto, it's fine.

Just curious - Why would that make a difference in powershell ?

I have no idea. Either my machine is really borked, or Windows being Windows I guess.

[JVRaines]

Thank you for this, poisondeathray! I was concerned that the pipe might change video data but I ran framemd5 comparisons on a plain MKV and a piped MKV and they are video-identical.