[Michael Rampe]

Where did -crf 22 come from? That wasn’t in your previous command line. This is another rate control method. Try to remove it as you are already using -b and -bt as a rate control method.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

Sorry for the delay.

I would try a process of elimination to work out why it is stopping. I do not entirely understand the commandline you are using.

You are setting the frame rate to 30fps but only getting 6fps encode. What is the frame rate of the source? Can you live with 15fps?

You seem to be setting all of the x264 flags manually. Libx264 presets are excellent and should be your first thing to try instead of manually setting all of the libx264 flags. There are many to choose from and some do work in realtime. Start with ultrafast and keep upping the quality until it stops being realtime. This should get rid of the dropped frames. (ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo)

Take out the -sameq flag. This is a rate control method that may be overriding the other rate control methods you are employing. also setting -bufsize and -maxrate will give you a CBR file which is not desirable as it is the lowest quality. (VBR is highest quality) Maybe try just -b 100k and -bt 100k and leave out the rest except change -qmax to 51. Your encode is maxing out at q=30 and still not giving you the desired 100k. libx264 has a q range of 1-51 unlike other codecs which have a range of 1-31.

Take out -pass 1. This is only needed for two pass encoding and writes a log file. This log file will become very large over time and may be causing your problem.

Finally, you are encoding an x264 stream to a transport stream container. I think you need the -vbsf h264_mp4toannexb for this. Not entirely sure if it is needed for a streaming source but I have had to use it when repacking h264 into a transport stream container to make it play properly.

Anyway, try some of these things and see if your problem persists.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

[nayan kapadia] “Is there any other way to solve this problem?”

Possibly with a bit more info….

[nayan kapadia] “after some time”

How much time? Is it regular or irregular?

Are you getting any reported errors? Please paste the command line you are using as well as the text output from FFmpeg.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

Hi John,

I used svn to get the latest version.

$ svn co https://ffprobe.svn.sourceforge.net/svnroot/ffprobe/trunk ffprobe

This pulled down SVN-R92 of FFprobe.

Not sure about any issues specific to windows but this version definitely does support the -show_frames option.

I am also currently working on a real-time encoding analyser with live graph using the -vstats option in FFmpeg. Worth looking into.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

[Björn Lundin] ”
Yes, you are correct. I started the thread with
‘I have a FireDTV tv card that records SD and HD tv.
This is conneted to a Mythtv server’
But I should have been more clear.
Yes, the file is indeed a dvb-t recording from Denmark, eventhough
I’m, swedish. (I live close to denmark)”

Sorry but it has been a long week but it is the weekend now;-) (that should let you work out where I am from).

Basically, I think all your issues are being caused by the truncated stream you are getting from the source (starting on B-frame as identified earlier.) Sync issues in the picture stream can most definitely cause problems with playing back the associated audio stream and trying to mux a broken stream with another stream will always lead to issues. Trying to fix these issues after the fact is also problematic.

So you have a “card” connected to the server. I looked into both devices you mentioned.
https://www.digital-everywhere.com/en/alcms/index.php?sid=1190404664
https://www.mythtv.org/
Which one is dumping the file you are using (straight from the FireDTV or from the MythTV DVR)?. Have you tried to disconnect the server to capture locally only ie. Connect the box to your computer. Are you on linux, Windows or OSX?

Supposedly, FFmpeg can capture from firewire (I have never tried it).

From man FFmpeg:
“Audio/Video grab options

-vc channel
Set video grab channel (DV1394 only).

-tvstd standard
Set television standard (NTSC, PAL (SECAM)).

-isync
Synchronize read on input.”

I also read somewhere that adding the -dv1394 flag enables this but again not tested.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

Sorry, I thought that was one of the failed outputs;-)

[Björn Lundin]
“Program 1
Stream #0.0[0x907]: Video: h264, yuv420p, 1280×720 [PAR 1:1 DAR 16:9], 50 tbr, 90k tbn, 100 tbc
Stream #0.1[0x91f](dan): Subtitle: dvbsub
Stream #0.2[0x920](dan): Subtitle: dvbsub”

FFmpeg cannot see ANY audio streams. The “dvbsub” streams indicate to me that this file came from a television broadcast. This explains how you have a file starting on the B-frame.

(DVB=digital video broadcasting and is the standard in most non-USA countries for digital television broadcast.) I am assuming you are in a PAL European country (possibly Denmark) due to the file info you have posted which uses the DVB standard. A DVB transport stream can contain multiple video streams, multiple audio streams, subtitles, EPG and other information. Very tricky to work with.

I cannot help with this using FFmpeg.

[Björn Lundin] “I’m willing to try just about anything…”

If it is indeed DVB broadcasts you are capturing, get yourself a cheap USB DVB decoder which will allow you to capture the file in a proper way to your computer. Google: “USB DVB tuner”. There are lots of devices on the market for this. You can then use FFmpeg if required to make it into a suitable format for your PS3.

Sorry I cannot be more helpful.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

Try an intermediate step since it is streaming.

stream —> file —> encode

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

Hi Björn,

Sorry for the delay…. been learning to #bash recently which has taken up some time. Highly recommended for automating FFmpeg.

[Björn Lundin] So, by using
mplayer -ao pcm -vc null -vo null filename.mpg
I get a file audiodump.wav
Which i convert to audiodump.aac with this command
faac -q 100 -c 44100 -b 192 –mpeg-vers 4 audiodump.wav
ffmpeg -f h264 -i raw.264 -vcodec copy -i audiodump.aac -acodec libfaac out.mp4

Why not use FFMpeg for all of this? What is the source?
Not much experience using mencoder but keep it simple unless you really need complex. Can you please post the source info?

$ ffmpeg -i ORIGINAL_FILE_NAME

[Björn Lundin] “[h264 @ 0x888c970]non-existing PPS referenced
[h264 @ 0x888c970]B picture before any references, skipping
[h264 @ 0x888c970]decode_slice_header error
[h264 @ 0x888c970]no frame!
[h264 @ 0x888c970]number of reference frames exceeds max (probably corrupt input), discarding one”

You cannot start on a B-frame! It seems your input to FFmpeg is truncated. (B stands for bidirectional and are thus related to frames on both sides)

[Björn Lundin] “[h264 @ 0x888c970]decode_slice_header error
[h264 @ 0x888c970]no frame!
[h264 @ 0x888c970]number of reference frames exceeds max (probably corrupt input), discarding one”

This looks REALLY bad;-)

Why not use intermediate container instead of raw streams? You could use mp4 for video and maybe mp3 or ac3 for audio. The time base in the header of the container might help get rid of some of the nasty frame errors you have been getting but might not work without an intermediate step to fix the malformed stream header.

Instead of:
$ ffmpeg -f h264 -i raw.264 -vcodec copy -i audiodump.aac -acodec libfaac out.mp4

…try:
$ ffmpeg -i raw.mp4 -i audiodump.aac -map 0:0 -map 1:0 -vcodec copy -acodec copy out.mp4

The .mpg format/codec with the “-same q” flag is excellent for an intermediate at very near lossless transcoding.

Finally, upgrade your FFmpeg. Due to the nature of FFmpeg’s development adhering to a stable trunk when in SVN version, it is safe to assume that the latest version will probably have less bugs and more functionality.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

Haven’t looked into this specific use but have been using named pipes for another project so I will look into it now.

Basically what worked for me is:

First create the named pipe with the proper extension:
$ mkfifo fifo.y4m

Then run both processes at once:
$ x264 –quiet –crf 18 -o video.264 fifo.y4m & \
ffmpeg -i funny_bubbles.mov -pix_fmt yuv420p -an \
-f yuv4mpegpipe – > fifo.y4m fifo.y4m < /dev/null Then remove the fifo: $ rm fifo.y4m You could also write a simple *sh script to do them all at once. Good luck. Michael "half-way to world domination A.K.A. the belligerent blue bike shed"

[Michael Rampe]

looks like s atream mapping problem.

[Björn Lundin] “ffmpeg -f h264 -i raw.264 -vcodec copy -i raw.aac -acodec faac out.mp4”

Can you post the command line result of FFmpeg?

Also, can you use FFmpeg to report on the original .ts:
ffmpeg -i yourfile.ts

There is a good chance FFmpeg will handle the whole process.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”