[FFmpeg-user] avoid pixelated dvb-t
juan carlos Rebate
nerus492 at gmail.com
Tue Dec 8 00:41:18 CET 2015
yes the transmission is wireless
2015-12-08 0:33 GMT+01:00 Andy Furniss <adf.lists at gmail.com>:
> Moritz Barsnick wrote:
>> Did you originally write "the console does not display errors"????
>> On Mon, Dec 07, 2015 at 23:56:09 +0100, juan carlos Rebate wrote:
>>> [h264 @ 0000000006290940] Found reference and non-reference fields
>>> in the same frame, which is not implemented. Update your FFmpeg
>>> version to the newest one from Git. If the problem still occurs, it
>>> means that your file has a feature which has not been implemented.
>>> [h264 @ 0000000006290940] If you want to help, upload a sample of
>>> this file to ftp://upload.ffmpeg.org/incoming/ and contact the
>>> ffmpeg-devel mailing list. (ffmpeg-devel at ffmpeg.org)
>> Unless someone disagrees, this here is the description of your
> Yea could be, though transport streams at the start/with packet loss do
> spew a lot of noise. I can't be sure I've seen that massage exactly, but
> have seen "upload sample" many times on streams that are fundamentally
> playable once they get going or have a loss free run.
>> If you want to capture this as a file, you probably have to do
>> something like:
>> $ ffmpeg -i rtp://22.214.171.124:8208 -map 0:v -c copy -t 10 dump.ts
> This has got me wondering - is it possible with ffmpeg to dump "raw"
> without remuxing. I don't know if it would work with rtp but maybe
> mplayer -dumpstream
> would make a better sample as the original transport stream continuity
> counters/PCRs would be intact and would show up any packet loss.
> Is wireless involved here?
> udpxy was mentioned, I tried that many years ago and it was useless in my
> test - maybe it's better now.
>> (Even more valuable information was at the top of your output,
>> probably scrolled out of screen?)
> It would be good to see the start = stop the player quickly.
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
More information about the ffmpeg-user