Problems with recording a 16:9 stream with VLC

[AndreasB]

My problem is as follows:

I have a Osprey 230 card which is capturing a stream which is sent in 16:9 aspect ratio, and I would like to record this as a 16:9 stream without letterboxing.

I can crop the image in the driver so it delivers only the actual video (the letterbox is added by the driver so that it can deliver a 4:3 stream), and VLC happily records this.

The problem is that VLC displays this as a 4:3 movie, even though the height vs width ratio its recorded in clearly is 16:9, and the recorded MPEG 4 stream, made with VLC, is shown as 16:9 in other players. (Such as QuickTime).

I have a small sample video available here: http://media.hiof.no/sndp2/test.mp4.

I have tried both searching these forums and google to find a way to ensure that the recording is played back as 16:9, but I have been unable to find any info on it.

[AndreasB]

Having experimentet a bit, and tried:

ffmpeg -i test.mp4 -aspect 16:9 test2.mp4

Which VLC will happily play as a 16:9 movie, it would seem that VLC is not setting the aspect-ratio MPEG4 flag.

Is there a specific command line option which can force this? I have tried
--crop=16:9 and --aspect-ratio=16:9.

[DJ]

1. QT doesn't recognize letterboxed videos.

2. While VLC does play the video in 4x3, DivX or XviD codecs for Direct Show will not play the video properly at all.

It appears that you have encoding issues rather than play issues.

[AndreasB]

Hmm, recording might be the problem:

The commandline used is:

Test1.mp4:

ffmpeg dshow:// :dshow-vdev="Osprey-230 Video Device 1" :dshow-adev="" :dshow-size="" :sout=#transcode{vcodec=mp4v,vb=1024,scale=1,acodec=mp4a,ab=192,channels=2}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst="C:\Documents and Settings\Administrator\Desktop\test1.mp4"}} :aspect-ratio=16:9 :crop=16:9

Test2.mp4

ffmpeg dshow:// :dshow-vdev="Osprey-230 Video Device 1" :dshow-adev="" :dshow-size="" :sout=#transcode{vcodec=mp4v,vb=1024,scale=1,acodec=mp4a,ab=192,channels=2}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst="C:\Documents and Settings\Administrator\Desktop\test1.mp4"}}

The Osprey card is giving out a 768x428 (yes, strange resolution, but it is 16:9 (I am cropping away the black letterboxes in the video driver atm).

[DJ]

Hmm! Seems more likely the resolution would fall in a common form. I agree 768 is odd but is divisible by 16 but the 428 is not and is unlikely the correct number. More likely is 432 which would be 1.78:1 and fall into the newer progressive formats for 16x9. Most newer programs complain when you make resolution cropping errors and you really should correct this even though it's only 4 lines.

You still haven't mentioned what the source formats are (and container if there is one) and if there are any errors in Messages. The source must play properly before transcodeing.

You could just provide a link to the manufactures website where the specifications exist and I will take a look and offer some suggestions or at very least point you in a direction that should yield some results.

BTW the commands for using crop in transcoding are:

--sout-transcode-croptop <integer>
Video crop (top)
Number of pixels to crop at the top of the
video.
--sout-transcode-cropleft <integer>
Video crop (left)
Number of pixels to crop at the left of the
video.
--sout-transcode-cropbottom <integer>
Video crop (bottom)
Number of pixels to crop at the bottom of the
video.
--sout-transcode-cropright <integer>
Video crop (right)
Number of pixels to crop at the right of the
video.

[AndreasB]

Hmm! Seems more likely the resolution would fall in a common form. I agree 768 is odd but is divisible by 16 but the 428 is not and is unlikely the correct number. More likely is 432 which would be 1.78:1 and fall into the newer progressive formats for 16x9. Most newer programs complain when you make resolution cropping errors and you really should correct this even though it's only 4 lines.

Thanks, I have tried that, but I get tiny, but noticable black above and beyond after cropping when using anything but 428, most likely the video signal being fed to the composite which is the culprit there.

You still haven't mentioned what the source formats are (and container if there is one) and if there are any errors in Messages. The source must play properly before transcodeing.

The source is raw video from the Osprey 230 card. It is fed with a composite video source which is widescreen.

You could just provide a link to the manufactures website where the specifications exist and I will take a look and offer some suggestions or at very least point you in a direction that should yield some results.

You can find the specs here: http://www.viewcast.com/pages.asp?page=osprey-230

BTW the commands for using crop in transcoding are:
(snip)
Number of pixels to crop at the right of the
video.

Thanks, I'll play around with that today

[DJ]

Both the description and specifications are quite thin for a professional card in this price range. While the card and hardware features look the part, there is no description of the software and capabilities. For example a professional is not particularly interested in an AVI capture output. They want to be able to work in MPEG 2 (some would rather work in the raw output), specially in these resolutions which also isn't mentioned, nor is the output format. Offering a variety of formats for a variety of users would mean a wider audience for the product.

The other thing is the seeming non standard resolution (kinda between the DVD and 480p, but not quite right in the aspect ratio). What is a professional to do with this, specially without some options that are also not mentioned on any level. Perhaps the source has a bearing on the resolution and aspect ratio? But I would expect some kind of correction into standard sizes via the software (more than just a crop function).

If I went this route for my Sony cam, I would want to work in the raw state for my editor or at very least m2v and deal with the audio separately. Of which formats are also not mentioned. In this way I can maintain quality of the original shoot. Working in AVI means I must convert to another format and this generally means loss of quality.

I didn't take any time to read about their streaming solution and perhaps the choice of AVI and the term professional may mean a product geared to ITs wanting to capture video for streaming servers and yet the resolution and aspect ratio still seem strange for this purpose.

OK! On to VLC. Open you capture device and press ctrl i then go to the Advanced info... tab. Post that here.

Assuming raw video there are not many options that will provide a compatible end result. The most likely is DivX 3 with MP3 in a ASF container. This will show up as MPEG43 with MP3 audio in WMP or any Direct Show player and or editor.

The last time I tried the transcode crop options they didn't work because they weren't finished. But a move to finish all the filters has taken place for 0.8.6 in preparation for 0.9.0. I don't believe the autocrop is finished.

My experience with VLC is that it reads the header for all formats correctly. This includes aspect ratio.

Hope all of this is helpful

[AndreasB]

Hope you had a nice weekend

Now, back to advanced info tab (Uncropped, when cropped in driver it was the resolution above):

Codec: I420
Language:
Type: Video
Resolution: 768x576
Frame rate: 25.00000

For some reason I need to select a 4:3 aspect ratio resolution when capturing 16:9 video, and then crop away the letterbox (which is added by the driver when there is no video there.), at least that is what the vendor website states.

As for correctly reading the header for all formats correctly, that is my experience for VLC as well. Now I just need it to set the aspect ratio flag to 16:9.

Thanks for all your help thus far.

I have uploaded an uncropped mpeg4 capture,
as well as what I get when I check the dump raw input checkbox in dump to file.

Uncropped MPEG4
Raw output

[DJ]

I420 is a chroma format and considered raw video no audio and this is what I would expect in a raw dump.

Your test 5 is showing up as yuv420p -> bgr24 and under DirectX 768x576 Planar YV12. This sounds correct for a 4x3 progressive scan considering the source.

There is an oddity in VLC as 2 video streams are being shown, but only 1 is available. Perhaps something about how the header for the file is being written?? There are no errors being shown in messages, so you are getting a good encode.

QT is showing the borders (rather unusual) and the reporting appears correct.

In examining the crop with my editor the aspect ratio does indeed appear to be 768x432 but the video is not centered on screen. so instead of 72 lines off the top and bottom it ends up as 72 lines off the top and 76 lines off the bottom. I would venture a guess that the top is correct and the bottom is in error in the driver and the real aspect ratio is 768x432 or 1.78:1. Personally I would have preferred a 480p rather than this non-standard. An auto crop shows the real resolution as 768x458 which is 70 lines off the top and 74 lines off the bottom. This mode should be reading the driver. In my mind the error here is clearly the driver and the aspect ratio is in error. However, my editor does make the correction to 768x432 and centers the video.

My editor would not open the raw video and I'm not real surprised at this, nor would I expect different results. I generally work in 480p or 720p M2v of which the editor happily accepts and then transcode the end result to the format and container of choice.

[AndreasB]

Originally the project I am working on was based on a 4:3 aspect video source, where the Osprey 230/210 series of cards work very well.

Unfortunately I cannot change the hardware at this stage, as I need to get the service up and running ASAP, so I think I shall have to just capture the image as 4:3 and then re-process it later with ffmpeg to crop it down to 16:9 aspect video.

(Its part of a fully automated system which captures the video records of meetings of Norwegian parliament, takes the transcripts of those meetings, and cuts the video so that you can view individual speakers, where VLC is used by us to capture the realtime footage.)

Just for interest I dug up an alternate recording from the video source, captured by our Hauppauge Win-TV PVR 250 MPEG2 hardware encoder card (cheap, but works), but the video appears similar there.

Recording from alternate machine: Clicky!

(At least to me, network layer and code logic is my fields of work, not video codecs themselves )

Edit: Almost forgot the most important thing of all, a great thanks for your help

[DJ]

This one is 320x240 and shows a rather normal 2 line error for NTSC video. So it corrects to 320x178 instead of 320x176 while maintaining the 1.78:1 using 320x178.