Frame rate changed without changeing timestamps

[FishB8]

I used to be able to force change in framerate by doing the following:

% ffmpeg -f $input-device -i input -r 30/1 ... output

The indev that I'm capturing from gets video at 60fps, and this used to force the frame-rate down to 30 (by dropping every other frame) before streaming.

However now, while it says the output is 30fps, the encoded timestamps seem to be stamped like they would be for 60fps. So the streamer / player says the steam it's receiving is 60 fps, so the audio and video drift wildly out of sync quite quickly when viewing rtp/rtsp streams.

Trying to force is by doing:

% ffmpeg -r 60/1 -f $input-device -i input -r 30/1 ... output

results in an error "Option framerate not found" similar to #926

My setup is a bit complicated with several apps connected with pipes, but it worked ~6 months ago. I've updated my system this week and it no longer works with ffmpeg 0.11.1

decklink device -> bmdcapture -> ffpeg (scaling and encoding) -> vlc (simultaneous RTP-Mulitcast & RTSP)

I also tried patching ffmpeg to interface with the decklink directly to see if cutting bmdcapture out the pipeline would help, but problem is still the same.

Actual commands used:

with bmdcapture

bmdcapture -c 2 -s 16 -m 16 -V 4 -A 1 -F nut -f pipe:1 | ffmpeg -re -i - -s 640x320 -r 30/1 -acodec libaacplus -ab 64k -vcodec libx264 -pix_fmt yuv420p -aspect 16:9 -vprofile high -preset slow -crf 22.0 -trellis 2 -threads 8 -f nut - | cvlc - --sout '#duplicate{dst=rtp{mux=ts{use-key-frames},sdp=rtsp://@:8554/teststream},dst=rtp{mux=ts{use-key-frames},dst=224.2.0.1,port=5004,ttl=16,sdp=sap://,name=teststream}}'

without bmdcapture:

ffmpeg -re -f decklink -input_format 16 -i "" -s 640x360 -r 30/1 -pix_fmt yuv420p -vcodec libx264 -vprofile high -preset slow -trellis 2 -crf 22 -acodec libaacplus -ab 64k -f nut - | cvlc - --sout '#duplicate{dst=rtp{mux=ts{use-key-frames},sdp=rtsp://@:8554/livestream},dst=rtp{mux=ts{use-key-frames},dst=224.2.0.1,port=5004,ttl=16,sdp=sap://,name=livestream}}'

Used in conjunction with VLC version 2.0.2 as the actual stream server (no transcoding, just transmuxing) and as the client as well.

[FishB8]

Forgot to mention, that I can confirm that if I capture at 1920x1080@30000/1001 or 1920x1080@30 (where I'm no longer trying to drop every other frame) that everything works fine.

And, I have looked at some other options, but most of those seem to be for changing framerate while also changing play length. (Perhaps I'm wrong about this?)

[Carl Eugen Hoyos]

Please provide complete, uncut console output together with your command line.

And please test current git head.

[FishB8]

I redirected stderr output to a log file. (So that vlc output isn't mixed in)

See attached encode.log

Will work on getting a git build put together.

[FishB8]

stderr output for ~5 sec encoding

[Carl Eugen Hoyos]

What happens if you output to a file? Does it play in-sync, or does it show problems (with ffmpeg, ffplay or MPlayer)?

[FishB8]

When I output to a file and play it back, it is recognized as 30 fps, but the video and audio are still quickly drifting apart.

[FishB8]

I won't be able to test a git build until next tuesday or wednesday.

[FishB8]

Ok, I can confirm now that after building from git the problem is no longer present.

I was testing the stream using a Mac with VLC, which was updated from 2.0.2 to 2.0.3. Supposedly there were fixes for some issues with the mac that may have contributed to the problem, but I have no motivation to see if that was actually part of the problem now that it's working.

Feel free to close, unless you would like more info.

Thanks.

[FishB8]

Ok scratch that last comment. I think I figured out what is going on.

If on my decklink capture card, I am capturing from the analog audio input everything works fine. However if I source the audio from the audio embedded with the video source (HDMI or SDI) then that's when the problems occur when trying to cut the frame rate.

Perhaps the time stamping is done differently that causes problems? Would it be helpful to provide dumps of raw video/audio in the nut format, and compare to see what is different between the two? (would be big files)

I'm not too familiar with the nut format, but is there some sort of optional sync locking between audio and video streams that would cause this type of problem with trying to change the framerate?

[FishB8]

After taking some raw samples I think I might be seeing what's causing the problem.

After capturing samples from both audio capture modes, and looking at the packets it seems that the audio duration of the packets is very different from the embedded source.

Running ffprobe -show_packets I can see that the audio packets from the analog source are the same length as the video packets: duration_time=0.016667

The video packets from the embedded source are unchanged, but the audio packets are different: duration_time=0.015312 (duration 735 vs 800 from the analog source)

The audio packets from the analog source seem to be interleaved one to one with the video packets, but the audio packets from the embedded source occasionally double up. (probably to make up the duration difference)

The question is if ffmpeg is incorrectly handling the audio when the packets durations are different than video durations, or if the capture code is not handling embedded sources correctly.

I can provide the two samples, but each are about 10 seconds long which comes out to 1.1G each. :P