Peter Rabbitson wrote:
Hello!
I am having trouble finding info on how to properly control color
reproduction, both in terms of "reference manual" and in terms of
"best practice guides". If I missed a resource neatly explaining
everything I am confused about below, please do not hesitate to
"RTFM
Marcel Grandemange wrote:
Evening
I sincerely hope someone can assist me with the following case. I
have the command below which is intended to monitor a rtmp stream and
look for silence within the stream. It takes the rtmp stream plays it
for 30 seconds and looks for 1 second of silence within
Bogdan Mariesan wrote:
Hi Andy,
Sorry for the fuss, my email client added the http part... that was
not intended there.
OK, maybe from an ffmpeg users pov it would be best to test on a lan
without the hole punching code just to see if that part works.
On the client side I am using Java to ru
Bogdan Mariesan wrote:
Hi everyone,
I am trying to achieve a *P2P *connection via *UDP *and for that I'm
following the wiki guide.
On my server I am using:
*ffmpeg -f dshow -video_size 640x360 -rtbufsize 702000k -framerate 30 -i
video="Integrated Camera":audio="Microphone (5- Logitech USB Head
PSPunch wrote:
On 2016/04/08 5:04, Andy Furniss wrote:
Why do you need to make interlaced from progressive?
Excuse me to jump in. For example, when encoding for BD I need to
make the choice between 1080i to retain resolution, or 720p for ease
of handling. (Although I never had to used FFmpeg
Anatol wrote:
Andy,
U don't see 'weightp' warning, because I have 'weightp=0' at the end of the
'x264opts' list in my "monster" command line (its sometimes a fun to be a
monster ...).
Oh OK
The results with ffmpeg3 are the same (for monster and simple cmd-lines).
In all cases the x264 gets th
by output from libx264 like -
...
[libx264 @ 0x30125a0] interlace + weightp is not implemented
...
I don't see that in your output (it's informational, not an error).
On Wed, Apr 6, 2016 at 9:23 PM, Andy Furniss wrote:
Anatol wrote:
The idet results are of an output file.
The sourc
Anatol wrote:
The idet results are of an output file.
The source is progressive.
I don't have the command line of the sample file.
I am aware that those are unrelated issues, but thanks for the clear
expatiation, it helped me to understand it better.
I'll try the 'interlace' filter, but skip the
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
Another issue = your command line won't work (unless it's just me!)
with current ffmpeg as something changed to do with wrapped avframe.
The command line works fine afaict.
Oops I misread yuv as y4m.
It's reminded
zhuhb wrote:
The command is as follows:
ffmpeg -i BlowingBubbles_416x240_50_qp23.265 -vcodec rawvideo
-pix_fmt yuv420p BlowingBubbles_416x240_50_qp23_y.yuv
The console output is as follows:
ffmpeg version N-79000-g66edd86 Copyright (c) 2000-2016 the FFmpeg develope
Sreenath BH wrote:
On 3/8/16, Moritz Barsnick wrote:
If you want the same profiles and levels, you will need to request them
explicitly.
The same thing goes for the quality: libx264 defaults to crf=23, I
don't know about nvenc. Furthermore, encoders can trade off quality (or
size) for conver
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
I think it's just that ffmpeg cli has got strict
again WRT the silly situation that vdpau info reports
level 4.1 for my h/w.
(Which is of course completely absurd: A transcoding CLI
should never refuse to use a hardware decoder
Andy Furniss wrote:
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
IIRC vdpau doesn't even go up to level 5.2 but before
below merge it worked for me.
Now it just silently falls back to s/w while still
throwing the threads warning.
Please open a new ticket providing
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
IIRC vdpau doesn't even go up to level 5.2 but before
below merge it worked for me.
Now it just silently falls back to s/w while still
throwing the threads warning.
Please open a new ticket providing as much information
as pos
Andy Furniss wrote:
IIRC vdpau doesn't even go up to level 5.2 but before below merge it
worked for me.
Now it just silently falls back to s/w while still throwing the threads
warning.
I say it's 5.2 but I'll have to find/make 5.1 later to confirm it's not
just failing
IIRC vdpau doesn't even go up to level 5.2 but before below merge it
worked for me.
Now it just silently falls back to s/w while still throwing the threads
warning.
I say it's 5.2 but I'll have to find/make 5.1 later to confirm it's not
just failing on UHD.
commit 6b706ce85fa56564986211b99d34e2
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
I know I can work round with -vsync 0, but it seems odd
that 50/60 fps elemental streams have this issue, even
with no sound.
I don't know if this is the issue here, but please
remember that h264 timestamps are generally an i
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
I notice that with 422 or 444 encoding and preset ultrafast the
dimensions of video are changed as seen by ffmpeg 1080 -> 1072.
This is ticket #4980, please note that this is a decoder bug.
(The encoded file is ok.)
Ahh, thanks
I know I can work round with -vsync 0, but it seems odd that 50/60 fps
elemental streams have this issue, even with no sound.
It doesn't seem to happen with containers or 25/30 fps so I guess it's
just some accuracy thing.
Initially noticed testing with 50fps y4m -> hevc -> y4m = extra frame.
+
Encoding 1920x1080 with libx265 1.9 8bit build.
I notice that with 422 or 444 encoding and preset ultrafast the
dimensions of video are changed as seen by ffmpeg 1080 -> 1072.
Initially I guesses min CU size 16 was involved as it's 8 with other
presets that don't have this issue, but then it's 16
Jayram Moorkanikara Nageswaran wrote:
Adding bitrate produced the same error as mentioned before.
Is there a quick way to check if ffmpeg, QSV and MFX have been properly
configured is working correctly ?
Sadly, the internal error "Error initializing an internal MFX session"
does'nt say much abo
Jayram Moorkanikara Nageswaran wrote:
Hi,
My current system:
***
OS: Ubuntu Linux 14.04 with 3.14.5-MSSr6 #1 SMP.
Hardware: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
***
1) I managed to complete the detailed instruction for installing intel
media sdk on generic Linux OS.
I followed the instruct
Dave Rice wrote:
I know mediainfo can probe more than ffmpeg in certain cases - but
I consider interlaced/field order to be quite fundamental and
expected there to be a way to see it that I was missing.
I'm guessing here, but I suspect that MediaInfo may be reporting
interlacement information
Andy Furniss wrote:
Moritz Barsnick wrote:
https://ffmpeg.org/faq.html#Interlaced-video-looks-very-bad-when-encoded-with-ffmpeg_002c-what-is-wrong_003f
Scan type: Interlaced
Original scan type : Progressive
Scan type, store method
Anatol wrote:
Following php func might help u:
private static function checkForScanType($ffmpegBin, $srcFileName,
$frames=1000)
{
/*
[Parsed_idet_0 @ 00331de0] Single frame detection: TFF:1 BFF:96
Progressive:2 Undetermined:1
[Parsed_idet_0 @ 00331de0] Multi frame detection: TFF:
Moritz Barsnick wrote:
Hi Andy,
On Thu, Feb 18, 2016 at 12:07:44 +, Andy Furniss wrote:
Just idle messing around, wanted to make an interlaced prores just to
see how players/deinterlacers handled it.
Disclaimer: I know very little about interlace stuff.
I know the command is "
Just idle messing around, wanted to make an interlaced prores just to
see how players/deinterlacers handled it.
Below is just a shortened example - also tried some variants + prores_ks
/hq.
My commands all fail in the sense that that ffprobe -show_frames doesn't
show interlaced.
What I
Dave Rice wrote:
On Feb 7, 2016, at 4:57 PM, Andy Furniss wrote:
Dave Rice wrote:
On Feb 7, 2016, at 1:42 PM, Paul B Mahol
wrote:
On 2/5/16, Paul B Mahol wrote: On 2/5/16,
Dave Rice wrote: Hi all, I am having trouble
creating an mpeg2video output that conforms to 16-235 broadcast
Dave Rice wrote:
On Feb 7, 2016, at 1:42 PM, Paul B Mahol
wrote:
On 2/5/16, Paul B Mahol wrote: On 2/5/16,
Dave Rice wrote: Hi all, I am having trouble
creating an mpeg2video output that conforms to 16-235 broadcast
range. I'd like to find a way to have an input which is
yuv420p but has l
Roman wrote:
Hi,
I've seen many times people asking/forcing not to top-post to the
list... So here I've got a question.. Why ?
It's a mailing list, not just a conversation between two people.
When you ask multiple questions different people may answer different
parts, which may spawn sub thr
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
ffmpeg -loglevel debug -i snk-420i.y4m -vf scale=interl=1
ffmpeg.png
Do you understand this message to add the missing options?
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/181474/focus=181547
Hmm
I wouldn'
Carl Eugen Hoyos wrote:
Carl Eugen Hoyos ag.or.at> writes:
Andy Furniss gmail.com> writes:
ffmpeg -loglevel debug -i snk-420i.y4m -vf scale=interl=1
ffmpeg.png
Do you understand this message to add the missing options?
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/181474
Paul B Mahol wrote:
On 1/27/16, Andy Furniss wrote:
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
mplayer -ss 11.2 -frames 3 -demuxer lavf -noaspect -vf
ilpack,scale -vo png ~/snooker-short.ts
First convert the input file losslessly to something I-frame only
(like ffv1), t
Paul B Mahol wrote:
On 1/27/16, Andy Furniss wrote:
I notice in the web help -
https://www.ffmpeg.org/ffmpeg-filters.html#toc-zscale
That there are several options at the end that don't appear in ffmpeg -h
full.
Earlier I tried the [o]hsub/vsub so I know they are unrecognised -
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
mplayer -ss 11.2 -frames 3 -demuxer lavf -noaspect
-vf ilpack,scale -vo png ~/snooker-short.ts
First convert the input file losslessly to something
I-frame only (like ffv1), then testing will get (much)
easier.
Yea was in progr
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
Another observation - if I grab (xwd) a frame produced
by mplayer + ilpack then it looks better than the both
the interlaced in my screenshot - it's as good as the
best looking (progressive + flags) one without the
chroma field
Andy Furniss wrote:
One thing that is curious if I convert to 422 interlace aware no
flags then to rgb it looks better that going straight to rgb. flags
will still make it better on the second conversion.
Another observation - if I grab (xwd) a frame produced by mplayer +
ilpack then it looks
Paul B Mahol wrote:
On 1/26/16, Andy Furniss wrote:
Andy Furniss wrote:
Here's the assert - after seeing swscale in the first test I tried
format=rgb24 ...
use copy filter before zscale filter.
Anyway using y4m is wrong as it doesnt have frame metadata as
primaries,matrix coefficient
Andy Furniss wrote:
Here's the assert - after seeing swscale in the first test I tried
format=rgb24 ...
ffmpeg -loglevel debug -i snk-422i-flags.y4m -vf zscale,format=rgb24
zimg-422.png
ffmpeg version N-78059-g2e31434 Copyright (c) 2000-2016 the FFmpeg
developers
built with gcc 5.3.0
Paul B Mahol wrote:
On 1/26/16, Andy Furniss wrote:
Paul B Mahol wrote:
On 1/26/16, Andy Furniss wrote:
Maybe there is some way - or maybe not, I thought I would ask
before doing my usual ffmpeg game of trying many many
options/variants in the hope that eventually something will work
Andy Furniss wrote:
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
After reminding my self recently just how bad ffmpeg yuv -> rgb
can look with interlaced
Command line, complete, uncut console output and a sample missing.
It's too soon really I am still thinking a
Paul B Mahol wrote:
On 1/26/16, Andy Furniss wrote:
Maybe there is some way - or maybe not, I thought I would ask
before doing my usual ffmpeg game of trying many many
options/variants in the hope that eventually something will work
:-)
ffmpeg -i yuv -vf zscale,format=gbrp out.png
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
After reminding my self recently just how bad ffmpeg yuv -> rgb can
look with interlaced
Command line, complete, uncut console output and a sample missing.
It's too soon really I am still thinking about it but until I ge
Moritz Barsnick wrote:
On Tue, Jan 26, 2016 at 15:43:45 +, Andy Furniss wrote:
Is it possible via ffmpeg with libzimg to convert yuv -> rgb or is
zscale just for scaling and the Colorspace bits not
implemented/need some different filter?
From looking at the code, it seems to
After reminding my self recently just how bad ffmpeg yuv -> rgb can look
with interlaced (without using extra flags). I wanted to try something
else -
Is it possible via ffmpeg with libzimg to convert yuv -> rgb or is
zscale just for scaling and the Colorspace bits not implemented/need
some diffe
Christoph Gerstbauer wrote:
As we know it is possible to detect field orders with ffmpeg:
ffmpeg -i -vf idet -f rawvideo -y NUL
Example Output:
[Parsed_idet_0 @ 003ea220] Single frame detection: TFF:0 BFF:153
Progressive:0 Undetermined:0 [Parsed_idet_0 @ 003ea220] Multi frame
detection: TFF:0
Christian Johannesen wrote:
On Monday, January 25, 2016, Andy Furniss
If you don't have access to better/"real" masters I don't think
you can get good results from this.
What produced this file with height 486?
The file was captured as 720x486 29.97 fps interlac
Andy Furniss wrote:
Andy Furniss wrote:
Carl Eugen Hoyos wrote:
Christian Johannesen gmail.com> writes:
ffmpeg.exe -r 3/1001 -i
D:\media\test_720x486i_dotcrawl.mov
Please remove the input option -r unless you know exactly what
you are doing.
-filter_complex [0:0]crop=704:480:
Andy Furniss wrote:
Carl Eugen Hoyos wrote:
Christian Johannesen gmail.com> writes:
ffmpeg.exe -r 3/1001 -i D:\media\test_720x486i_dotcrawl.mov
Please remove the input option -r unless you know exactly what you
are doing.
-filter_complex [0:0]crop=704:480:8:6,pullup
Input
Carl Eugen Hoyos wrote:
Christian Johannesen gmail.com> writes:
ffmpeg.exe -r 3/1001 -i D:\media\test_720x486i_dotcrawl.mov
Please remove the input option -r unless you know exactly what you
are doing.
-filter_complex [0:0]crop=704:480:8:6,pullup
Input on ticket is 4:2:0 and you can
Roger Pack wrote:
Hello. I'm trying to understand how MPEG mapping terminology works.
Given this type of input:
$ ffmpeg -i INPUT
...
Input #0, mpegts, from 'INPUT':
Duration: N/A, start: 22159.226833, bitrate: N/A
Program 1346
Metadata:
service_name: 7TWO
service_p
Jim Worrall wrote:
On 2016 Jan 6, at 4:04 AM, Andy Furniss
wrote: I guess superfast hides the gain of the first pass. I am not
sure I would want to encode with it using 3M ABR - which is quite
low, but then libx265 is quite slow.
Normally I use ‘medium', or now ‘slow' because I
Matthew Adams wrote:
Andy,
The changes were not due to Google Drive. They were due to Google Photos.
If you allow Google Photos to store photos & vidoes at their prescribed
fidelity (whatever that is), they'll let you store an unlimited amount of
photos. If you want to store them unchanged, th
Jim Worrall wrote:
On 2016 Jan 5, at 6:06 PM, Andy Furniss wrote:
I would double check your command line(s) - if they seem OK paste it/them along
with the full output(s).
You are so right. I had pass=1 twice (I’m going to hide under
a rock now). Now I get:
x265 [info]: tools: rd=2 psy
Moritz Barsnick wrote:
On Tue, Jan 05, 2016 at 13:30:07 -0600, Matthew Adams wrote:
I pulled the files off of the iPhone using iExplorer, a nice little
tool to get at the iOS filesystem.
Hmm. Something tells me this isn't the raw video as it comes from
your device, but it was manipulated by Go
Jim Worrall wrote:
On 2016 Jan 5, at 5:17 PM, Andy Furniss wrote:
I snipped some other "evidence" in my last post.
If you want to check outputs between the two ways look at the last
lines of the larger block of x265 [info].
with ffmpeg the last 2 lines of both pass 1 and 2 are th
Matthew Adams wrote:
On Tue, Jan 5, 2016 at 3:07 PM, Moritz Barsnick
wrote:
Anyway, it should be possible to convert those to something sane.
As Carl Eugen mentions: What's your goal?
My goal is to convert these videos a fixed, relatively standard (30
fps? 60 fps?) frame rate while retainin
Jim Worrall wrote:
On 2016 Jan 5, at 4:28 PM, Andy Furniss wrote:
Jim Worrall wrote:
On 2016 Jan 5, at 3:13 PM, Jim Worrall
wrote:
Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as
slow as pass 2. As expected he result is worse as well.
Uh-oh, I thought that’s what was
Jim Worrall wrote:
On 2016 Jan 5, at 3:13 PM, Jim Worrall
wrote:
Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as
slow as pass 2. As expected he result is worse as well.
Uh-oh, I thought that’s what was supposed to happen (except for the
worse result part). I thought libx2
Jim Worrall wrote:
Yes, that's probably it.
Maybe you could try below to see if the original shows 709 -
ffmpeg -analyzeduration 100M -probesize 100M -i original.m2ts
FWIW I just noticed another issue - using pass 1 and pass 2 via ffmpeg doesn't
work for libx265.
It does work if you use it v
Jim Worrall wrote:
Ouch, did the new file show as 709 with
ffmpeg -i newfile.mkv
I can't reproduce this one myself x265-params seems to work.
If for some reason the newfile didn't get flagged as 709 then it could be
possible to get brighter with different colours in a scene.
Yes. The ORIGI
Jim Worrall wrote:
I’m not really looking for perfection, just don’t want the transcodes to be
darker on any device.
So my testing has shown, for both libx264 and libx265, the problem is
solved (meaning the pngs come out with the same luminosity, which
is good enough for me) either of two ways,
Jim Worrall wrote:
Strange, unless there is something in the pngs that causes a
different viewer to produce different output.
I looked again (display from ancient imagemagic) and can't see any
difference - psnr/ssim agree.
The pngs are not the same md5sum wise
OK - you’re definitely getting
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
I think it's because the master is flagged as rec709 but the yuv
and I guess hevc aren't.
While this is at least likely (sorry for my original comment, I don't
know what I looked at), the source code seems to disagree
Andy Furniss wrote:
Andy Furniss wrote:
Strange, unless there is something in the pngs that causes a
different viewer to produce different output.
I looked again (display from ancient imagemagic) and can't see any
difference - psnr/ssim agree.
The pngs are not the same md5sum wise
m
Andy Furniss wrote:
Strange, unless there is something in the pngs that causes a
different viewer to produce different output.
I looked again (display from ancient imagemagic) and can't see any
difference - psnr/ssim agree.
The pngs are not the same md5sum wise
md5sum frame1-yuv-70
Jim Worrall wrote:
It seems ffmpeg swscale/png honors the 709 for the master.
testing -
ffmpeg -i in.mkv -vframes 1 frame1-master.png
ffmpeg -i in.mkv -vframes 1 -vcodec rawvideo -f rawvideo frame1-master.yuv
ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i frame1-master.yuv
frame1-yuv
Jim Worrall wrote:
On 2016 Jan 4, at 1:33 PM, Carl Eugen Hoyos
wrote:
How did you produce the screenshots?
ffmpeg -i in.mkv -vf fps=1/6 %03din.png
I do see that one of the png files you uploaded is lighter but when
I look at the 91st frame of the file you uploaded, it is darker
here with M
Moritz Barsnick wrote:
On Fri, Jan 01, 2016 at 19:25:59 +, Andy Furniss wrote:
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
(adts) files is way out with current ffplay, mpv and mplayer.
I opened ticket #5117, thank you for the report!
Thanks, Ignore what I said about
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
Doesn't affect ffmpeg -ss but interactive seeking on very large aac
It does afaict.
(adts) files is way out with current ffplay, mpv and mplayer.
I opened ticket #5117, thank you for the report!
Thanks, Ignore what I sa
Andy Furniss wrote:
Looks like it could be (full bisect log below).
avpacket: Replace av_free_packet with av_packet_unref
I now suspect this bisect is useless!
Stupid idea trying to start from a tag, I have working ffplay far more
recently than that commit
Andy Furniss wrote:
Doesn't affect ffmpeg -ss but interactive seeking on very large aac
(adts) files is way out with current ffplay, mpv and mplayer.
Pressing "up" to skip forward a minute ends up at 1:37:xx on one
sample.
Making the samples smaller reduces the effect so it woul
Doesn't affect ffmpeg -ss but interactive seeking on very large aac
(adts) files is way out with current ffplay, mpv and mplayer.
Pressing "up" to skip forward a minute ends up at 1:37:xx on one sample.
Making the samples smaller reduces the effect so it wouldn't be seen on
a "normal" length sam
Budge wrote:
[aac @ 0xa62d80] Error decoding AAC frame header.
[aac @ 0xa61800] Estimating duration from bitrate, this may be inaccurate
Input #0, aac, from
'Composer_of_the_Week_-_Carl_Philipp_Emmanuel_Bach_1714-1788_1._The_Belligerent_Flautist.mp3':
Metadata:
encoder : Lavf53.2
Carl Eugen Hoyos wrote:
Andy Furniss gmail.com> writes:
http://www.demo-uhd3d.com
Some of them seem to have other issues - but then they are
experimental I guess and I don't know whether it's worth reporting
them.
Please do report the issues here!
OK there's the
The HDR sample below does play but floods output killing perf.
http://www.demo-uhd3d.com/files/uhd4k/Samsung_SUHD_Picture_Quality%20Demo_Nano_Crystal%20Display_UK-Version.mp4
This is 700meg and won't cut with dd.
The issue still exists with a smaller sample made with
ffmpeg -c copy -t 5
https
tarun singhal wrote:
It seems i have created a confusion here...By "ffmpeg supporting HDR
encoding" I meant wether ffmpeg can convert any random video to a
4K HDR encoded content. I have already tested 4K and it works fine
but its this "HDR" piece thats troubling me and I havent even found
a pr
juan carlos Rebate wrote:
use windows therefore these commands are not valid ffmpeg version
N-77137-gff6dd58
OK, maybe something like wireshark could do it and be told to capture
full packets and save to pcap file format.
Are there any windows players that can play the stream?
juan carlos Rebate wrote:
dump.ts attached file here in the mail
I am not sure whether such a short dump is any use (I am just a user) or
whether the remuxing will hide/cover up issues.
I played around with rtp using ffmpeg to stream and it does seem easy to
confuse players - but then my sourc
juan carlos Rebate wrote:
yes the transmission is wireless
I would test with a cable - it could just be packet loss that is messing
up the stream.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
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 @ 06290940] Found reference and non-reference fields
in the same frame, which is not implemented. Update your FFmpeg
version
juan carlos Rebate wrote:
formatting options in Gmail are disabled,I disable html format and
posting top but still appears,thereon to the console as I said
before it is not error,I can not copy the playback screen,the console
does not display errors, pixelated reproduction is just that
Paste ev
juan carlos Rebate wrote:
I need help to remove pixelated, as I said in previous posts the RTP
address corresponds to a TV channel when loading the ffplay appears
pixelated as if coded gray
You are still top posting. Post underneath any replies like this.
You won't get any help unless you do w
juan carlos Rebate wrote:
I used the VLC player and the player ffplay both with the same
result. the -infbuf command does not work, you get the same result
Please don't top post on this list.
So is this anything to do with ffmpeg?
You don't give details of what is sending the stream. You say
juan carlos Rebate wrote:
the entered command is ffplay -i rtp/239.0.0.73:8208 wait a few
seconds and the image appears pixelated gray. I have also tried using
udpxy to convert multicast traffic in unicast traffic getting the
same result
Does it happen with a different player?
With mplayer/mpv
Peter B. wrote:
Dear all,
For archiving purposes, TV shows are recorded - coming in as MPEG-TS
stream (H.264/AAC).
I've encountered a problem with a file:
- In some players (e.g. VLC) audio plays fine at the beginning, but is
mute when the actual program starts.
- It "seems" that the audio samp
MrNice wrote:
On 26/11/15 11:38, MrNice wrote:
Hi,
When I run the command
./ffmpeg -debug 1 -f pulse -ar 44100 -ac 2 -channel_layout stereo
-thread_queue_size 1024 -i alsa_input.pci-_00_14.2.analog-stereo -f
v4l2 -use_wallclock_as_timestamps 1 -itsoffset 1.70 -channel 1
-video_size 720x5
Reindl Harald wrote:
Am 16.11.2015 um 00:38 schrieb James Darnley:
On 2015-11-15 22:13, Andy Furniss wrote:
I shall have to remember to check gmail spam though as I would never
have seen this if no one replied.
Yes, mu fault as gmail is bloody useless for mailing lists.
FYI the filter
James Darnley wrote:
On 2015-11-15 22:13, Andy Furniss wrote:
I shall have to remember to check gmail spam though as I would never
have seen this if no one replied.
Yes, mu fault as gmail is bloody useless for mailing lists.
FYI the filter feature of Gmail lets you make messages skip the
philippe.tor...@laposte.net wrote:
Hi,
I've used ffmpeg to make a movie from a sequence of png But, even
with x264 lossless ffmpeg, i get a video on youtube with noticable
artefact (the ugly square of cos discrete)
Maybe seeing this artifact and the source would be more use than saying
"the ug
Marwan Daar wrote:
On 11/11/2015 11:52 AM, Andy Furniss wrote:
Just because you are using 10bit the result of playing will still
be 8 bit as that's what most computer screens are.
This doesn't mean that 10 bit yuv is pointless as X bit rgb -> 8
bit yuv and back looses loads of c
Marwan Daar wrote:
On 11/11/2015 10:18 AM, Andy Furniss wrote:
Possibly because it did work but every video player by default
will assume limited range for yuv so stretch and not display
anything above/below the video levels. It will also be pot luck
whether by default you will get to see 10
Marwan Daar wrote:
I tried the scale command with the 10 bit build, but no luck.
Resulting video was one uniform color rather than 8 distinct bars.
Possibly because it did work but every video player by default will
assume limited range for yuv so stretch and not display anything
above/below th
MrNice wrote:
May I ask for another favour? Could you have a look at this thread
http://ffmpeg-users.933282.n4.nabble.com/Application-provided-invalid-non-monotonically-increasing-dts-to-muxer-in-stream-td4672326.html
I have seen that but have no idea what the issue is.
Related to this issue
MrNice wrote:
However with x264 encoder and -flags +ilme+ildct output is
[libx264 @ 0x2940600] interlace + weightp is not implemented [libx264
@ 0x2940600] using mv_range_thread = 24 [libx264 @ 0x2940600] using
SAR=16/15 [libx264 @ 0x2940600] using cpu capabilities: MMX2 SSE2Fast
SSSE3 SSE4.2 A
MrNice wrote:
On 02/11/15 10:26, MrNice wrote:
I had a closer look on what I did previously. With FFV1, option
-flags +ilme+ildct do nothing. Debug see it but do nothing => I'll
remove it Moreover, documentation says: Apply interlaced motion
estimation, Use interlaced DCT (MPEG-2 and MPEG-4 o
MrNice wrote:
Carl Eugen said on Dec 19, 2012: "To the best of my knowledge, only
visual inspection tells you, ..."
Yes or idet as you have found which also gives the field dominance info
you need. Without idet, to find tff/bff you would need to deinterlace
with say yadif=1 while setting domi
Carl Eugen Hoyos wrote:
MrNice iol.ie> writes:
When I capture some video with the CL ./ffmpeg -debug 1 -f v4l2 -ts
mono2abs -channel 1 -video_size 720x576 -pix_fmt yuyv422
-thread_queue_size 512 -i /dev/video0 -c:v ffv1 -level 3 -g 1
-aspect 4:3 -pix_fmt yuv422p /Store3/Test/t_`date
+%Y%m%d_%H
Andy Furniss wrote:
MrNice wrote:
To confirm I have an interlaced USB video, I tried
./ffmpeg -debug 1 -f v4l2 -ts mono2abs -channel 1 -video_size
720x576 -pix_fmt yuyv422 -thread_queue_size 512 -i /dev/video0
-c:v libx264 -preset slow -qp 0 -flags +ilme+ildct -aspect 4:3
-pix_fmt yuv422p
MrNice wrote:
To confirm I have an interlaced USB video, I tried
./ffmpeg -debug 1 -f v4l2 -ts mono2abs -channel 1 -video_size
720x576 -pix_fmt yuyv422 -thread_queue_size 512 -i /dev/video0 -c:v
libx264 -preset slow -qp 0 -flags +ilme+ildct -aspect 4:3 -pix_fmt
yuv422p
This doesn't confirm v4
101 - 200 of 255 matches
Mail list logo
