Re: [FFmpeg-user] Set MPEG-2 interlace flag without re-encoding

2022-05-09 Thread Nicolas Gaullier
>Envoyé : vendredi 6 mai 2022 20:20
>À : ffmpeg-user@ffmpeg.org
>Objet : [FFmpeg-user] Set MPEG-2 interlace flag without re-encoding
>
>I have an MPEG-2 video which is progressive but marked as interlaced, so video 
>players try to deinterlace it and ruin the quality. Is there a way to fix the 
>interlace flag without re-encoding the video and causing quality loss?
>
>Thanks,
>Alex

In a general manner, I would say no.
In case your content is exclusively frame-encoded, you might try to set the 
progressive_frame flag (currently, there is no bsf filter for that in ffmpeg) 
and hope your player take it into account: this is not absolutely impossible 
but far from obvious.
Note that if you reencode, you might consider processing the chroma in between 
(convert to 4:2:2 back and forth) since the vertical sampling filtering is 
affected.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Set MPEG-2 interlace flag without re-encoding

2022-05-12 Thread Nicolas Gaullier
>On 5/9/22 2:44 AM, Nicolas Gaullier wrote:
>> Note that if you reencode, you might consider processing the chroma in 
>> between (convert to 4:2:2 back and forth) since the vertical sampling 
>> filtering is affected.
>
>What does this mean? I only have basic knowledge of how video compression 
>works so I don't understand what you're talking about.
>
>Thanks,
>Alex

I suppose your file is a common distribution format, so 4:2:0. This implies a 
vertical filtering of the chroma and vertical processing with interlaced scan 
is always very picky.
I have not experienced this myself, maybe someone could comment how to handle 
this with care in a qualified filter graph; I think converting to 4:2:2 back 
and forth (weaving in 4:2:2) without precautions may be sufficient though.
But well, now, sincerely, compared to the interlacing artefacts you noticed, 
the difference here should be very subtle, especially if the original content 
does not show high vertical frequencies in the chroma. This is why I said you 
"might" consider processing the chroma, I don't think of it as a requirement. 
Comparing visually the results of the two workflows and checking the 
differences would be very interesting.

For more information on this subject, you can look at : 
https://www.cockam.com/vidbug2.htm
The artefacts reported there concern progressive-encoded content decoded as 
interlaced, this is more dramatic but clearly it is NOT your case.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Changing scan type (progressive<->interlaced) without reencoding.

2022-12-06 Thread Nicolas Gaullier
>As the title says, is this at all possible? My concern is mostly with mpeg2 
>and h264 that have content of one type but encoded/marked as another.
In a general manner, amongst other things, interlaced encoding involves 
interlaced DCT, so this is not possible because it is not a simple "mark".
In some very limited scenarios, it is possible to tag interlaced content as 
progressive-segmented frame (PsF). Take mpeg2/h264: I have never seen any 
implementation (neither encoder or decoder) of the flags that actually allow to 
mark progressive content, so PsF is pure theory here. So today, for example, 
only "progressive sequence" mpeg2 is considered progressive : you have to 
transcode.

>Most notably content that has progressive video but stored interlaced.
"encoded" rather than "stored", but yes, it is indeed very commonplace.
Nevertheless, be very very carefull, it is also very very commonplace to have 
interlaced branding/finishing on progressive content, so it can end up with  1 
hours of pure progressive content with 3x period of 10s where an interlaced 
title appear or disappear in a corner... This is why deinterlacing filters are 
both so useful and so tricky.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Repeatable resolution issue exporting mxfs, 1080p is coming out as 1088p

2023-03-06 Thread Nicolas Gaullier
>Hahaa! Thanks for the help everyone! I will log it as a bug tomorrow!
>
>Thanks
>Will

Logging this will certainly help - I have not found the trac #, maybe you 
haven't done it yet.
For information, earlier this year, on January, a patch was reviewed and would 
have fixed your issue - if it was applied.
https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305659.html
This affects also DV and more recently FFV1 which was the target of the patch.
For information, these things are much trickier than it appears, there are 
interoperability concerns etc., so things are moving slowly and user inputs are 
welcome.
See for example
https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305764.html

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] DVCPro50 MXF

2023-03-06 Thread Nicolas Gaullier
>Hi people, hope you are all good.
>
>I am using ffmpeg 5.1.2
>
>I am trying to make a DVCPro50 in a MXF wrapper but I am getting some odd 
>results.
>If I start by trying to make it a DV wrapper it’s still giving me some 
>problems. 
>For example, I choose -target pal-dv50 and it looks like it’s encoding at the 
>desired bitrate of 50mbps.
>
>ffmpeg -I source.mxf -target pal-dv50 -aspect 16:9 output.dv
>frame= 1375 fps=151 q=-0.0 size=  385280kB time=00:00:55.16 
>bitrate=57219.2kbits/s speed=6.07x   
>
>But when I check the file using media info or ffprobe it shows as 25mbps.

It seems you use both ffmpeg and ffprobe but when posting here you dumped the 
output of another tool (mediainfo I guess).

See 
https://ffmpeg.org/mailing-list-faq.html#What-type-of-questions-can-I-ask_003f
"We cannot provide help for scripts and/or third-party tools."
https://ffmpeg.org/mailing-list-faq.html#What-are-the-rules-and-the-proper-etiquette_003f

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] ffprobe duration difference between 5.1.3 and 6.0.

2023-10-30 Thread Nicolas Gaullier
>ffprobe duration difference between 5.1.3 and 6.0.
>
>I'd like to know if this is an expected behavior change

Yes, this is an expected change,
take a look at this unambiguous commit:
https://github.com/FFmpeg/FFmpeg/commit/836b8001c924deb9263b0f5b7c74ccfaab1f4fdc

Note that your sample has an edit list which truncates the available (stts) 
duration to 1s,
but other durations in the file (mvhd/mdhd/tkhd) are set to longer values - 
which is wrong (according to 14496-12).

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Difference between i-frames and key frames

2023-10-30 Thread Nicolas Gaullier
>> On 07-10-2023 17:20, Ulf Zibis wrote:
>>> Hi,
>>>
>>> what is the difference between i-frames and key frames?
>>>
>>> And how many other frames are between i-frames or key frames in mp4 
>>> files, created with ffmpeg and with default settings?
>>>
>>> -Ulf
>> In mp4 containers I-frames are key frames.>
>
>That is not correct. Via ffprobe, I have seen I-frames that were not marked 
>'key_frame=1'.

Firstly, the definition of what a key frame is may depend on contexts and on 
peoples,
it is often a source of headaches.
If you take a look at 
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_parser.c
You can see that properly signaled recovery points are tagged as keyframes,
which means you don't need an I-frame to make a keyframe (some low latency 
encoders make use of this).
And you can also see that kind of things:
// heuristic to detect non marked keyframes
if (p->ps.sps->ref_frame_count <= 1 && p->ps.pps->ref_count[0] <= 1 
&& s->pict_type == AV_PICTURE_TYPE_I)
s->key_frame = 1;
as indeed, an I frame is not always a keyframe (long term references may be 
required later for further processing).

And, at the end, sorry for not answering your question ;)

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] MXF file using mpeg2video in a windows environment

2023-12-14 Thread Nicolas Gaullier
>Is it possible to use the codec mpeg2Video in a Windows environment?
>Do I need to install anything additional to use it?
Any platform, any cpu, the mpeg2 encoder is part of libavcodec which is part of 
ffmpeg, so any non-specific (with no explicit disabling) build includes it.
You can actually check it and get "inline help" of you current build this 
simple way:
ffmpeg -h encoder=mpeg2video

>Format:Mpeg Video
>GOP:15
>Bitrate:50M
Look for an xdcamhd preset on the web, you'll find plenty. Have to take care of 
progressive vs. interlaced.
For example:
https://trac.ffmpeg.org/ticket/7168
https://github.com/mltframework/mlt/blob/master/presets/consumer/avformat/XDCAM-HD422
Note that:
- I recommend you NOT to use 420 as I experienced severe artefacts in this 
configuration, due to the reduced buffer size (420 chroma=>MP@ML)
- I recommend you NOT to use lmin/lmax as I experienced severe quality 
regression some years ago, and old command lines are no more valid currently 
(in my experience)
(- in case you target xdcamhd for real, you have to be very careful on the 
reduced sony bufsize at least; and you will not be 100% conformant anyway)

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Calculating VMAF of single videos.

2023-12-18 Thread Nicolas Gaullier
>ffmpeg -timedemo nameofdemo -viddump video.mp4
>
>The problem is 'I don't have any source material, i.e rawvideo etc'.
>
>So, how to calculate VMAF of a single video ?

What you can get here is support for ffmpeg and its libs, see ffmpeg.org.
Your so-called "ffmpeg" build here appears to include components that are not 
part of the project, so you have to ask support to the right place, to the 
right project where it belongs.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Calculating VMAF of single videos.

2023-12-18 Thread Nicolas Gaullier
>oops sorry:
>
>dsda-doom.exe -timedemo nameofdemo -viddump video.mp4
>
>this was the command sorry for the mistake.

It seems you don't read my answer : you won't get any support here.
Also top posting has to be avoided here, see 
https://ffmpeg.org/contact.html#MailingLists

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] MXF file using mpeg2video in a windows environment

2023-12-18 Thread Nicolas Gaullier
>Thanks for answering!
>I read the article and did some trial and error, but it didn't work.
>What I'm currently trying to do is create a broadcast commercial using ffmpeg.
>I did two things but they didn't work.
>irst, I transferred the MXF file to the XDCOM XDS-PD200, but it was not 
>displayed.
>Second, I used Sony MXF format checking tool which can check MXF files, but it 
>showed an error message.
>>https://www.sony.jp/xdcam/support/download/pwa_mc1.html
>
>When I check the MXF file generated using the code below, I get the error 
>message "The MXF metadata contains an unspecified value".
>Please advise as I don't know what is wrong.
>
>%~dp0ffmpeg\ffmpeg.exe -i temp\temp2.mxf -i temp\narr3.wav -i temp\narr3.wav 
>-i temp\silent.wav -i temp\silent.wav -i temp\silent.wav -i temp\silent.wav -i 
>temp\silent.wav -i temp\silent.wav -c:a pcm_s24le -ar
>48000 -map 0:V -map 1:0 -map 2:0 -map 3:0 -map 4:0 -map 5:0 -map 6:0 -map
>7:0 -map 8:0 -vf
>copy,il=l=d:c=d,colorspace=fast=1:all=bt709:format=yuv422p:ispace=bt709:itrc=bt709:iprimaries=bt709,il=l=i:c=i,fps=29.970,setfield=tff,setdar=dar=16/9,setsar=sar=1
>-field_order tt -top 1 -flags +ildct+ilme -alternate_scan 1 -g 15 -timecode
>00:59:45:00 -c:v mpeg2video -r 29.97 -pix_fmt yuv422p -aspect 16:9 
>-color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -non_linear_quant 
>1 -dc 11 -intra_vlc 1 -qmin 1 -lmin "1*QP2LAMBDA" -qmax
>28 -lmax "56*QP2LAMBDA" -b:v 5000 -minrate 5000 -maxrate 5000 
>-minrate 5000 -bufsize 17825792 -bf 2 -metadata creation_time=now -vtag 
>xd5c -intra_matrix
>8,17,17,19,17,19,21,21,21,21,21,21,23,22,23,24,24,24,24,24,24,24,25,25,25,26,26,26,29,29,29,26,26,26,25,25,27,27,28,29,29,29,31,32,32,31,31,30,30,33,33,34,34,34,38,38,37,37,43,43,44,50,50,58
>-inter_matrix
>16,17,17,18,18,18,19,19,19,19,20,20,20,20,20,21,21,21,21,21,21,22,22,22,22,22,22,22,23,23,23,23,23,23,23,23,24,24,24,25,24,24,24,25,26,26,26,26,25,27,27,27,27,27,28,28,28,28,30,30,30,31,31,33
>-f mxf -y output/output.MXF
>
>silent.wav is a sileent file.
>According to the commercial import standard, there is a rule that channel 3 to 
>8 must be silent.

Please avoid top posting, see https://ffmpeg.org/contact.html#MailingLists
I cannot use the sony soft as I don't read Japanese (the gui can be set in 
English, but not the error messages!).
First remember about my (very personal) doubts/warnings about lmin/lmax: 
carefully check the video quality you get - if it looks fine to you, keep it, 
but otherwise you might need to drop that part of the command line despite it 
seems required for straight sony conformance.
Concerning mxf itself, ffmpeg's output is fine for most usages, but for 
sensible cases or when interop is tricky, you may consider bmxtranswrap as a 
final pass : this is a pretty commonplace broadcast scenario, as implemented in 
ffastrans for example.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] FFmpeg default processing(invisible processing)

2023-12-19 Thread Nicolas Gaullier
>> On 19 Dec 2023, at 17:16, Erik Dobberkau  wrote:
>> 
>>> 
>>> Trust me, this command (besides audio parsing, depending on sources) 
>>> has made thousands of broadcast compliant files over here, where 
>>> XDCAM is also mandatory.
>>> 
>> 
>> Does that mean the issue mentioned here:
>> https://www.mail-archive.com/ffmpeg-user@ffmpeg.org/msg26313.html 
>>  (and its 
>> follow-up messages) is not an issue anymore?
>
>No clue, only thing I know is that the stupid broadcasters over here accept 
>files created as I showed Bouke ___

Each broadcaster has its own requirements. They can be very vague or very 
specific. They can be justified, "fair" or they can be fictional.
They can be thoroughly checked by a QC system upstream, or only lately by 
simply checking if Image and Sound pops up.
There is definetely no universal "standard expectation".
Only thing is, when using native sony hardware, the file will be played out - 
or not, but this is a very rare use case.
Nowadays, most of the times, broadcasters ask for sony XDCAMHD but only require 
MPEG2-50 for real. But even so, you can face a "Baton dans les roues" (sorry 
for the poor French joke) : the enforced checks are often not related to the 
real world needs.
MXF interop should not be a big deal, but the xdcamhd essence can be, depending 
on your broadcaster expectations.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Unresolved concatenation and subtitle problems

2023-12-28 Thread Nicolas Gaullier
> When ffmpeg's '-vf showinfo' and ffprobe's '-show_streams' disagree, which 
> should I trust?

You should usually trust both, but their meanings are different.
showinfo is a filter, so apply to a running filter graph, I don't think this 
information could be very helpful for your use case.
show_streams will give you some start_time/duration using the same core 
components (avformat_find_stream_info) as the concat demuxer, which actually 
can help.
Another option is to use a kind of "plain raw dump" and guess 
start_time/duration by yourself. This can be achieved with an ffmpeg -copyts -c 
copy -f framecrc -
Note that in some cases, it might happen that the real "first pts" comes before 
the ff reported start_time. And in that case, you will see mpv (based on ff) 
play your file at a point that is earlier than the start_time reported by ff.
So, be careful, these start_time/duration things are often much trickier than 
they look like.

It seems you want to join segments without reencoding.
First, you have to take care of the available features of your output muxer : 
an mp4 is more powerful to handle stream discontinuities than an mpegts format.
And there are two things to consider:
- "timestamp joining" : care about start/end points; but also, if your input 
audio/video is not aligned/locked (any usual compressed audio codec), you will 
have to reencode audio at least if you want to avoid a hole (or overlap) in the 
timeline.
- keyframes : open-gop is not editable with a straight stream copy if you don't 
allow some overlap; and you would certainly experience some difficulties to 
handle this overlap in a muxer

So many things, very dependent on your exact files and workflow.
At the end, if you encounter an issue, try to reproduce it on short segments to 
document a case in trac, with a very exhaustive report and corresponding media 
samples.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Having a hard time getting good results with mpeg2video

2024-01-09 Thread Nicolas Gaullier
>De : ffmpeg-user  De la part de MGislv via 
>ffmpeg-user
>The command used:
>`ffmpeg -i image.jpg -i audiofile.wav -f dvd -muxrate 10080k -packetsize
>2048 -pix_fmt yuv420p -r 24000/1001 -codec:v mpeg2video -g 18 -b:v 9800k 
>-maxrate:v 9800k -minrate:v 9800k -bufsize:v 1835008 -vf 
>"scale=720:576:flags=lanczos:force_original_aspect_ratio=decrease,pad=720:576:(ow-iw)/2:(oh-ih)/2"
> 
>-codec:a pcm_dvd output.mpg`

Your output is not conformant, it contains only one video frame...
>ffmpeg -h demuxer=image2
Use "-loop 1" as an input option for example.

Also see
>ffmpeg -h encoder=mpeg2video
When encoding still pictures, encoding B frames should help, try -b_strategy 2

If you intend your dvd to be fully conformant and playable by a hardware 
device, do not go up to the limits : that will certainly get you to full big 
real blocking artefacts this time!
I have no fresh experience with it, but something like 6 Mb/s seems more 
reasonable.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Faster ffprobe-based detection of open GOP h264 ?

2024-01-11 Thread Nicolas Gaullier
>De : ffmpeg-user  De la part de Andrew 
>Randrianasulu
>
>But as  it was said in forum post above - ffprobe  a bit slow, few minutes for 
>whole video, eating one cpu core completely.
>
>Is there faster way to get this info ?
Closed vs open gop is usually a local "keyframe" matter. It is not clear to me 
what is your intent : do you want to make sure 100% of the keyframes are closed 
gop ?
If so, you have to parse the stream, so indeed, it takes a long time. I don't 
think there is another option. MP4 muxer only has the global "keyframe" info. 
With quicktime/mpeg2 you would have gotten stss/stps = closed/open gop 
distinction, but it is not your use case.
Only one thing: as you noticed using MediaInfo, when encoding with libx264, 
there is an SEI describing the encoding parameters and you can get the 
"open_gop" field.
If you get a very fresh (less than 2 weeks) ffmpeg build, there is an option to 
display this with the showinfo filter:
ffmpeg -i xxx.mp4 -vf showinfo=udu_sei_as_ascii=1 -frames 1 -f null null

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Stream copy of mxf format is weird

2024-01-30 Thread Nicolas Gaullier
>De : ffmpeg-user  De la part de Syehoon Kim
>(...)
>But, I found that the new stream copied mxf file suffers from non-monotonous 
>dts problem.
>What I found is that dts is duplicated every 3 frames.
>
>The command I used is as follows:
>  ffmpeg -i (original_mxf).mxf -codec copy (stream_copied).mxf Interestingly, 
> if I convert the weird mxf output file to another format such as mov, or avi, 
> it works well.

It is not very clear to me, but it seems you only inspected the output and not 
the input.
To start with, here is something you can try to quickly check dts/pts of your 
mxf input:
ffmpeg -I input.mxf  -map v -c copy -f framecrc -
You can also directly decode to void to check some non-monotonous errors: 
ffmpeg -i input.mxf -f null null
You can also play your input file with mpv keeping an eye on the console output 
messages.
You can also dump your input mxf structure with dedicated tools (bmx, mxflib).
It is not very widespread or well-known, but timestamp issues DO happen in the 
mxf wrapper itself.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Stream copy of mxf format is weird

2024-01-30 Thread Nicolas Gaullier
>De : ffmpeg-user  De la part de Syehoon Kim
>
>I think there is nothing wrong with the original input file.
Can you check with -c copy, I mean exactly ffmpeg -i input.mxf  -map v -c copy 
-f framecrc -
If your input has B frames, you should be able to distinguish the dts and pts 
columns.

>Like you said, maybe it is due to the defect of the mxf wrapper.
>Thank you for notifying about mxf wrapper's timestamp issue.
>Kim Syehoon
Well, I was talking about the mxf wrapper in a general manner, not ffmpeg's 
implementation.
But anything might happen.
Can you share a sample of your input (it would be required for trac anyway) ?
Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Stream copy of mxf format is weird

2024-01-30 Thread Nicolas Gaullier
>De : ffmpeg-user  De la part de Syehoon Kim
>
>Of course I can. Below is the URL from the company(SBS) where I work.
>In case it causes an http 500 error, just refresh it.
>>https://megamail.sbs.co.kr:8443/xmegaAttach/BigFileDown.file?type=attachDown&fileName=Clip0003.MXF&fileIndex=K3YpOVEsvZg5eTu3mmTNF6F52kcPSl68poeFOYkO71k%3D
>
>If you don't like it, maybe I can share it with Google Drive below, or 
>something.
>https://drive.google.com/file/d/14y95vS_tIAO9xtxnFbX-5xh32p1nrADQ/view?usp=sharing
>
>Please check it out.
>Sincerely,
>Kim Syehoon

Ok, this is AVC long gop.
The essence stream copy works fine - binary match.
But the index metadata is lost: your input is actually correct as you said, the 
index table is VBR with video tagged posTableIndex=-1 to apply temporal 
reordering.
The output is not, video has posTableIndex=0 (and temporalOffsets = 0), so no 
reordering, so bad.
A trac ticket already exists:
https://trac.ffmpeg.org/ticket/9315
Maybe you can add some words there to complete the description of the issue.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] h264_mp4toannexb does not store a proper frame-rate.

2024-02-08 Thread Nicolas Gaullier
>De : ffmpeg-user  De la part de Wodzu
>Objet : [FFmpeg-user] h264_mp4toannexb does not store a proper frame-rate.
>
>Hi,   I have an mp4 file, that I want to convert to Annex B. The file 
>properties are:     Duration: 01:59:59.97, start: 0.00, bitrate: 1221 kb/s 
>     Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc, 
>>bt470bg/bt470bg/smpte170m), 1280x720, 1221 kb/s
>
>15 fps, 15 tbr, 15360 tbn, 60 tbc (default)
>
>I am converting to Annex B this way:   ffmpeg -i file.mp4 -vcodec copy 
> -vbsf h264_mp4toannexb -an output_file.264   After running >ffprobe on the 
> output_file.264:     Duration: N/A, bitrate: N/A      Stream #0:0: Video: 
> h264 (Main), yuvj420p(pc, bt470bg/bt470bg/smpte170m, progressive), 1280x720,
>
30 fps, 30 tbr, 1200k tbn, 60 tbc

>As you can see, the duration information has been lost
This is expected for an elementary stream; a muxer is required to gain instant 
access to such a value. Otherwise, the full elementary stream has to be parsed 
from end to end which means some delay and performance issues.

>and fps is now 30 fps. It it possible to retain the original FPS?   Cheers,   
>Bruce
Probing an elementary stream is usually the best way, the most reliable to get 
such a value. I think it is correct here.
I think your MP4 input looks suspicious with "15 fps / 60 tbc".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with 
subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] ffprobe can’t show ts file information

2024-02-20 Thread Nicolas Gaullier
>De : ffmpeg-user  De la part de Zhengrong Zang
>
>I have some ts files that can be played by Chrome without any problems.
>I got nothing when I run ffprobe 001.ts as below: 
>[png @ 01e9016fe940] inflate returned error -3 Input #0, png_pipe, from 
>'001.ts':

png/png_pipe: this is detected as a png picture
Don't trust the file extension, it is not a ts file, maybe a bizarre 
animated-png derived video format, but anyway it seems it is not supported as a 
decoding error is reported.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] ffprobe can’t show ts file information

2024-02-20 Thread Nicolas Gaullier
>Check bug ticket #10874, this is a video file and can be played by QuickTime 
>Player.
>
>Mike
>
>> 2024/02/20 22:37、Nicolas Gaullier のメール:
>> 
>> 
>>> 
>>> De : ffmpeg-user  De la part de 
>>> Zhengrong Zang
>>> 
>>> I have some ts files that can be played by Chrome without any problems.
>>> I got nothing when I run ffprobe 001.ts as below:
>>> [png @ 01e9016fe940] inflate returned error -3 Input #0, png_pipe, from 
>>> '001.ts':
>> 
>> png/png_pipe: this is detected as a png picture Don't trust the file 
>> extension, it is not a ts file, maybe a bizarre animated-png derived video 
>> format, but anyway it seems it is not supported as a decoding error is 
>> reported.
>> 
>> Nicolas

I am afraid your file is simply corrupt. In this case, indeed, each decoder has 
its own strategy.
Here, the format is that broken (a PNG header with an mpegts content), that you 
can't reasonably expect things to go on smoothly.
The standard mechanism in ffmpeg is such a case is to force the input format 
(mpegts is byte-seekable with sync words all along) - if you know what your are 
doing, this is a possibility:
ffmpeg -f mpegts -I 001.ts

If you think your file is valid and wants your ticket to be processed, you may 
need to give some references either to some standards or just simply describe 
how you get this file: how to (re)produce it.

Nicolas
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] ffprobe can’t show ts file information

2024-02-22 Thread Nicolas Gaullier
>De : ffmpeg-user  De la part de Zhengrong Zang
>Envoyé : mercredi 21 février 2024 01:53
>À : FFmpeg user questions 
>Objet : Re: [FFmpeg-user] ffprobe can’t show ts file information
>
>I am not sure if they are corrupt, is there such special mpegts format? Those 
>ts files were downloaded from a movie and drama provider that provide huge 
>amount videos, at the moment, I found two types ts file, one is with this >png 
>header, one is as below:
>Input #0, mpegts, from '001.ts':
>  Duration: 00:00:12.04, start: 0.038000, bitrate: 942 kb/s
>  Program 1
>  Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, 
> bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn
>  Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 
> stereo, fltp, 97 kb/s
>
I really think the file is corrupted (or cheated by a proprietary "extension").

>Thanks for your suggestion!
>I want to concat them to mp4, I use command for normal mpegts, ffmpeg -i 
>'concat:01.ts|02.ts|03.ts|' -c copy -bsf:a aac_adtstoasc 01.mp4
>
>for this special mpegts format, can I use command as below?
>ffmpeg -f mpegts -i 'concat:01.ts|02.ts|03.ts|' -c copy -bsf:a aac_adtstoasc 
>01.mp4
>
>Mike

You can try. I think the -f mpegts will allow to overcome the PNG header of 
01.ts if present. For the following 02.ts, 03.ts etc. in the presence of 
garbage (PNG header) the decoder should resync but it might raise some issues 
(maybe packet corruption flags etc.). Best thing is to test your use case in a 
worst-case-scenario (add the PNG header to all of your ts files to corrupt them 
by hand).

Nicolas

Note: do not top-post on this list (see ML usage).
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".