[Ffmpeg-devel] ffmpeg & postprocess_internal.h (colorspace issue)

Kris A. Wotipka kris
Mon Jul 25 01:16:20 CEST 2005


> 
>>now.  I am still trying to figure out the -pix_fmt yuvj420p is all
>>about.  
> 
> AFAIK this means yuv420p colorspace, but with the standard luma range 
> (16-234). 

To be honest, this line really helped me because it put me on the track 
of YUV.  No one had ever suggested that I need to take this route 
before.  I am wondering if the "p" is for "Progressive" or "PAL".  If I 
remember right, it was decoding in the PAL format when I used it.  Never 
the less, I have some things to try out and will leave the developers 
alone for a while.

It seems that on every forum, people are more interested in 
"bootlegging" DVD so the colorspace (or luma) issue is never addressed. 
  For me it a huge issue because, the volunteers are starting to produce 
programs with some being created in a YUV (NTSC) format and some in a 
digital (RGB) format.  If it were just text, then I could have them keep 
the RGB values within legal NTSC limits.  However, when they source with 
DV and then mix some DVD video that was orgionally NTSC composite, well, 
you can start to see my issues.

It looks like Mplayer/Mencoder might provide some of what I need but I 
have got to get the process down to a point where it is a shell script 
since the volunteers are not likely to learn bash much less C.

> 
> 
>>I am having a hard time finding docs on it.  From what I am am 
>>seeing, this throws it into PAL.  Are there some docs hidden somewhere
>>that are additional to the ones that come with ffmpeg / or man ffmpeg.
>>
>>Also, I am trying to figure out the compile sequence for this.  Should I
>>compile the libpostproc then libavcodec then ffmpeg or if I make changes
>>say to something in libavcodec do I need to recompile ffmpeg.
> 
> 
> Perhaps. If the proposed commandline didn't do what you need, you can
> stick to transcode or try mplayer/mencoder as mentioned before. 
> mplayer/mencoder has an extensive documentation and an exhaustive man page.
> 
Read through it last night.  Going to print it out and mark it up.  I 
have had marginal success with transcode but always had a/v sync issues 
when I tried to remux the streams.  If there was a flag for transcode 
that would keep it from splitting the streams in the first place, I must 
have missed it somewhere.  Trust me though it was not for lack of trying.




> 
>>thanks again
>>
>>kw
> 
> 
> no problem
> bye
> Denes
> 





More information about the ffmpeg-devel mailing list